Below you can find the top 10 posts (based on traffic) of this year and a full blog summary shortly describing each post of 2008.

Top 10 posts

According to the stats these are the top ten posts on my blog:

• MDA, Model Driven Architecture, basic concepts
• Model Driven Engineering
• Architecture, a definition (not from this year, but still popular)
• Architecture requirements for Service-Oriented Business Applications
• Combining general purpose languages and domain specific languages for Model Driven Engineering 
• SOA and Human Interaction (not from this year, but still popular)
• MDA and Model Transformation 
• OSGi quick start 
• SOA and Service Identification (not from this year, but still popular)

I just want to give a recent post special attention because it’s a first attempt to bridge my interest in both enterprise architecture and model driven engineering: The place of Architecture in Model-Driven Engineering.

By the way, I didn’t take the time of publishing into account when looking at the statistics. So, articles posted more recently are less likely to show up in the top 10, unless they are very popular.

Blog summary for 2008

January

• Model Driven Architecture (MDA) special interest group on LinkedIn: I started a special interest group for MDA on LinkedIn. Until now over 1500 members have joined this group. You can still join today!
• MDA, Model Driven Architecture, basic concepts: post explaining the basic concepts of MDA as defined by the OMG.
• SOA Approach to Integration: book review.

February

• MDA and Model Transformation: overview of model transformation approaches and a way to classify them.

March

• Model Driven Engineering: post introducing Model Driven Engineering (MDE) as a broader concept as MDA. James Taylor had a nice follow-up article explaining how MDE shouldn’t only focus on developer productivity, because the model that should drive the engineering is a business model, not a technical one.

April

• Spring time…: changed the whole appearance of my blog. If you have suggestions for improvement please feel free to contact me.
• Combining general purpose languages and domain specific languages for Model Driven Engineering: this article explains the notion of model, metamodel, and modeling language. It also shows how ontological and linguistic metamodeling can be combined for defining DSLs (Domain-Specific Languages). This is shown with an example process modeling DSL. InfoQ picked up the article with this summary.

May

• Architecture requirements for Service-Oriented Business Applications: primer on Service-Oriented Architecture (SOA). The first part of the article explains the project types to execute when moving to a SOA and it argues why a SOA is needed if you want to integrate processes. The second part goes into detail about service-oriented development (programming model, service types, implementation and standards). Recently Nick Malik recommended the article in this blog post, thanks Nick!
• Model Driven Experience: announcing the first Dutch symposium on Model Driven Development practices. I’m looking forward to the 2009 edition!

June

• Quality in Model-Driven SOBA development: article explaining how an MDE approach for Service-Oriented Business Applications (SOBA) asks for specific approaches to ensure the quality of the resulting system. Model validation, model checking, and model-based testing are described.
• MDA MDD MDE MDSD MDSE: help!: just a fun post on the confusion in MD* abbreviations.

July

• OSGi quick start: just as the title says, a quick start if you want to start with OSGi.
• SOA Ontology: my comments on SOA Ontology Draft 2.0 published that day by The Open Group. InfoQ included the post in their news item on this draft.
• 8 Reasons Why Model-Driven Approaches (will) Fail: post announcing my article (with the same title) on InfoQ. The article was introduced on InfoQ by Jean-Jacques Dubray in this news item.

August

• DSL and MDE, necessary assets for Model-Driven approaches: article explaining what Domain-Specific Languages are, why you should use them, and how they can should be combined with MDE.
• DSL in the context of UML and GPL: my reaction on a post of Steven Kelly, which was a reaction on a post of Cameron Skinner explaining Microsofts view on DSLs and UML. This post is my contribution to  the DSL vs UML debate. InfoQ picked up the discussion with this item.

September

• The structure of Domain-Specific Languages: post explaining how the structure of DSLs can differ in two different ways. An intermediate DSL can be a way to handle the complexity of using multiple DSLs with different structures.
• MoDELS '08: post announcing the MoDELS ’08 conference.

October
Posts covering the MoDELS ’08 conference:

• MoDELS '08: MDE is a hot topic
• MoDELS '08: Abstraction, the neglected side of modeling
• MoDELS '08: Domain-Specific Modeling
• MoDELS '08: Composition and Analysis of Behavorial Models 
• MoDELS '08: The objects and Arrows of Computational Design 
• MoDELS '08: Metamodeling and Modularity 
• MoDELS'08: Panel discussion on the past & future of MDD

November

• Domain-Specific Modeling needs multi-models: article explaining the concept ‘multi-model’. It is a more detailed explanation of the combination of MDE with DSLs.
• The place of Architecture in Model-Driven Engineering: a first attempt to bridge my interest in both enterprise architecture and model driven engineering. This article explains what role architecture plays (or can play) in MDE.

December

• If Programming Languages were <T>: just a referrer to a fun post on the comparison of programming languages with religions, cars, boats, women, girlfriends, subcultures, mixed drinks, music, rock bands, art, languages, and Christmas songs.
• And of course this post.

With the recent popularity of the comparison between PLs and Religions, I thought it'd be mildly amusing to see what other comparisons were out there on the intarweb. Here's the list for the meme that I collected of If Programming Languages were ...

Maybe we can extend the lists with idea's about Modeling Languages or other Domain-Specific Languages... any suggestions?

MOP is also part of the broader Model Driven Engineering picture and intends to complement it, not change it, not replace it.

He adds the notion of metamodel to both the problem and the solution space. I like his views and triggered by them I was thinking how to fit the notion of architecture in the Model-Driven Engineering picture. So, what's the place of architecture in MDE?

Figure 1 - Mapping between problem space and solution space

Let's start with a picture, Figure 1, from a previous post on the concepts of MDE. I'd like to combine this view with some of my previous articles on architecture, enterprise engineering, and the economic value of architecture. I think the place of architecture in Model-Driven Engineering is as visualized in Figure 2 (below). It's a first concept, but I think the essence is clear. Architecture plays an important role in both the problem and the solution space.

In the problem domain enterprise architecture guides the design of an enterprise based on the strategy of the enterprise. Enterprise architecture is prescriptive and is formulated using principles [1]. Enterprise architecture principles are based on the goals and policies of an organization and guide the design of the organization/enterprise. A design of an enterprise can be formulated using enterprise ontology, which provides a conceptual model of the enterprise that is coherent, comprehensive, consistent, and concise, and that only shows the essence of the operation of an enterprise [2].

Based on the design of the enterprise business components can be identified. Business components ‘directly model and implement the business logic, rules and constraints that are typical, recurrent and comprehensive notions characterizing a domain or business area' [3]. I see a business components as an implementation of a part of the enterprise design, specified in terms of the problem domain (i.e. functional models / models of the problem space, specified in domain-specific abstractions).

Figure 2 - Architecture and MDE

The transformation from functional models (in the problem domain) to executable models (in the solution domain) should be organized in such a way that the resulting artifacts conform to the technical architecture. The technical architecture also guides the behavior of the model interpreter or the transformation of the models into source code.

From an architectural perspective Model-Driven Engineering gives a lot of opportunities. Using properly defined metamodels with additional constraints ensures that the models are guaranteed to conform to the architecture. Due to the automatic generation of source code or the direct interpretation of the models (I favor the last option, but that's another discussion ;), the resulting system also fully conforms to the defined architecture.

--------------------------
[1] J. A. P. Hoogervorst. Enterprise Governance & Architectuur - Corporate, IT en enterprise governance in samenhangend perspectief. Sdu Uitgevers bv, Den Haag, 2007.

[2] Jan L. G. Dietz. Enterprise Ontology. Springer-Verlag, Berlin Heidelberg, 2006.

[3] F. Barbier and C Atkinson. Business Component-Based Software Engineering, chapter Business Components, pages 1-26. Kluwer Academic Publishers Group, 2003.

When talking about different kind of models, people mostly think about models on different abstraction levels. For example the PIMs and PSMs of the Model-Driven Architecture ( MDA ). In such cases the idea is to move from the problem to the solution space by refining high level models into lower levels models, until an executable model (can be expressed in a programming language) is created. I like to use the term refining instead of transforming, because in most cases additional information is needed (e.g. a business process model expressed in BPMN, modeled from a user perspective, can't be transformed into an executable model without adding information).

However, to accurately abstract complex systems one monolithic model in one modeling language isn't sufficient. Besides the abstract/concrete dimension sketched above, we need the concept of multi-models.

Multi-modeling

In literature multi-modeling is defined as the act of combining diverse models, which can be done in two ways [Brooks et al., 2008]:

• Hierarchical multi-modeling: hierarchical compositions of distinct modeling styles are combined to take advantage of the unique capabilities and expressiveness of the distinct modeling styles.
• Multi-view modeling: distinct and separate models of the same system are constructed to model different aspects of the system.

Multi-model challenges

If I refer to multi-modeling I mean multi-view modeling as defined above. While in multi-modeling a complete system is described using multiple interdependent DSMs, the integration of these DSMs is needed to synthesize the described system. This poses several research challenges [Denton et al., 2008]:

• Capturing multi-model interdependencies: as the number of models, the complexity of their interactions, and/or the size of the system being modeled increases, it becomes extremely difficult to manually keep track of the interdependencies.
• Maintaining multi-model consistency: to reach multi-model consistency, model changes must be propagated in order with respect to their interdependencies. While multiple modelers must be allowed to change their models simultaneously, the propagation of changes must be performed across compatible versions of the various models.
• Semantic precision of inter-model data exchange: while the different models in a multi-model are interdependent it is necessary that they share or exchange data. The semantics of the data must be precisely known and understood by all models participating in the exchange. This requires that the models either be described in languages derived from the same metamodel, or that experts specify the relationships between elements of disparate metamodels.

Solutions in literature

In literature, several solutions to the problem of multi-model integration have been proposed:

Name-based references. Warmer and Kleppe [Warmer and Kleppe, 2008] suggest to connect models by referencing model elements by name from within other models. The drawback of this solution is that all semantics are delegated to the code generator, i.e. the actual integration happens at code level. On the model level it isn't visible how two model elements are semantically related.

Weaving models. A model weaver allows to define and visualize correspondendences between elements in different models using an extensible weaving metamodel. The references between model elements are kept outside the models. This approach has two disadvantages, first the weaving model can only express the semantics of the links, it does not actually define the meaning of the corresponding language constructs. Second, a model weaver usually connect pairs of models and thus is not suited for an integration of a large number of DSLs [Brauer and Lochmann, 2007].

Model mappings. Mappings, or transformations, between models can be seen as models themselves, which describe the relationship between elements from the source and target model and allow to validate inter-model consistency constraints. However, a mapping specification expresses semantics of different DSL elements only implicitly and does not assign an explicit meaning to each language construct [Brauer and Lochmann, 2007].

Common upper ontology. Bruer and Lochmann [Brauer and Lochmann, 2007] stipulate that language integration must be based on ontological foundations, guided by a common upper ontology for software modeling languages. This allows to reuse fundamental relationships, constraints, and axioms when integrating a new DSL. The core idea of their approach is to address the insufficiencies of the previously mentioned approaches by using a semantic model connector, see Figure 1. Only the elements required for a semantic connection between participating models are mapped to ontology in the semantic connector. In other words: the interfaces of the different models are connected by mapping the elements of the metamodel (describing the DSL in which the model is expressed) to an ontology.

As we see, current scientific research is focusing on integrating Domain-Specific Models (DSMs) specified in different DSLs on an ontological level. If we can tackle that problem adding new DSLs to a modeling space becomes much easier. However, just integrating DSMs on a syntactical level as proposed in the first approach (name-based references) does already a great job in making life a lot easier. With good tool support, a system can be successfully modeled using multiple DSMs specified in different DSLs, thereby gaining all the advantages of Domain-Specific Languages.

Structuring the modeling space

Besides researching how to integrate multiple DSMs defined in different DSLs, it is also important to structure the modeling space. As stated in a previous article this can be done using multiple modeling dimensions, for example the ones shown in Table 1.

Examples of models for the dimensions presented in Table 1 are:

• A Computation Independent Model (CIM) of the workflows of the order entry part of the software artifact aimed at a domain expert.
• A Platform Independent Model (PIM) of the data of the back-end administration part of the software artifact aimed at a domain expert.
• A Platform Specific Model (PSM) of the security of the customer portal part of the software artifact aimed at a programmer.

Looking at the example dimensions in Table 1 we see that the first dimension (abstract / concrete) is the one in which refinements and transformations take place. The other dimensions in this case are used to structure the modeling space at each of these abstraction levels. So, at each abstraction level (for example: CIM, PIM and PSM) we have a multi-model, consisting of models for each subject area and within a subject area a model for each system aspect.

Conclusion

Model-Driven Engineering needs:

• A process to come from a model of the problem space (i.e. a business model) to a model of the solution space (i.e. an executable model of a software system). Such a process usually consists of several steps with models at different abstraction levels. Higher level models are refined until the executable model level has been reached. We can call this part of MDE the abstract-concrete dimension of the modeling space.
• Multi-models. In real-life we have to deal with business problems leading to large and complex software systems. As explained in this article such systems need multiple Domain-Specific Models specified in different Domain-Specific Languages to reach the right level of abstraction. Each model described in the previous bullet point in practice is a multi-model. 
• Domain-Specific Languages. For each model a notation is needed as much as possible tailored to the domain expert who's going to specify that model. We've explained (in this and previous articles) how the modeling space can be structured to determine the needed DSLs.

-----------------------

J. B. Warmer and A. G. Kleppe. Building a flexible software factory using partial domain specific models. In Sixth OOPSLA Workshop onDomain-Specific Modeling (DSM'06), Portland, Oregon, USA, pages 15-22, Jyvaskyla, October 2006. University of Jyvaskyla.

Christopher Brooks, Thomas Huining Feng, Edward A. Lee, and Reinhard von Hanxleden. Multimodeling: A preliminary case study. Technical Report UCB/EECS-2008-7, EECS Department, University of California, Berkeley, Jan 2008.

Trip Denton, Edward Jones, Srini Srinivasan, Ken Owens, and Richard W. Buskens. Naomi - an experimental platform for multi-modeling. In Krzysztof Czarnecki, Ileana Ober, Jean-Michel Bruel, Axel Uhl, and Markus Völter, editors, Model Driven Engineering Languages and Systems, 11th International Conference, MoDELS 2008, Toulouse, France, September 28 - October 3, 2008. Proceedings, volume 5301 of Lecture Notes in Computer Science, pages 143-157. Springer, 2008.

Matthias Bräuer and Henrik Lochmann. Towards semantic integration of multiple domain-specific languages using ontological foundations. In Fourth International Workshop on Software Language Engineering, Nashville, USA, Grenoble, France, October 2007. megaplanet.org.

• Richard M. Soley, Chariman and CEO, Object Management Group, USA
• Jeff Kramer, Professor of Distributed Computing, Dean of the Faculty of Engineering, Imperial College, UK
• Bran Selic, Retired IBM Distinguished Engineer, Canada
• Grady Booch, IBM Fellow and Chief Scientist, IBM Rational, USA
• Patrick Farail, Airbus, France

To give you an idea of the ambiance I'll start by listing some quotes from this panel discussion, the question to you: who has pronounced each one?

1. UML is the worst modeling language except for all the others.
2. The difference between terrorists and modeling experts: you can negotiate with terrorists.
3. Java is not a bad Lisp, if it were not for the lack of parentheses.
4. UML is both a blessing and a curse.
5. An UML tool has a far more complex interface than a modern aircraft cockpit.

The panelists did all receive the opportunity to start with a seven minute explanation of their view on the past and future of MDD. That was really educational, let's just not talk about the seven minutes time limit...

Grady Booch

Bran Selic

Bran did use the term Model-Based Software Engineering (MBSE) (another abbreviation to add to my collection) instead of Model-Driven Engineering. His reason: models don't drive anything, they're just part of the process.

In principle MBSE is an approach to software development in which computer-based models play an indispensable role. Models can be refined continuously until the application is fully specified, i.e. the model becomes the system it was modeling. The two proven ideas of MBSE are

• Abstraction (the realm of modeling languages)
• Automation (the realm of tools)

According to Bran the two major successes of MBSE are:

1. Executable modeling languages and supporting tools, which have increased productivity and quality (proven in industry). For example executable UML.
2. Standardization of UML. This process raised the awareness of MBSE in the greater community.

The question Bran asks whether we need a language aimed at design, analysis and documentation, an executable language, or a language supporting both. He thinks MBSE can only successfully be done using viable executable models. For him it is no question that Domain-Specific Languages (DSLs) are the way to go.

Bran sees a maturity model for MBSE with a movement in the last phases from a model-centric approach to a model-only approach. He closes his speech with the remark that maybe the current generation of MBSE will not be the winner/survivor.

Richard Soley

Looking at the past Richard mentions that the OMG has moved from distributed computing standards to modeling standards. The OMG is now active in more than 80 vertical markets in which they are very successful because they start from a modeling perspective instead of starting from a programming perspective (as they did with UML).

According to Richard the most important thing to recognize is that we have to deal with people, even more than with technology. People are used to tool, languages, etc. and they often don't change that in an easy way. Even if the notation of languages is the same, people want to have languages which (they think) are specialized to their needs. Richard gives the example of BPMN. Although the UML has models looking a lot like BPMN, most people prefer BPMN.

Richard also explains why he sees directly executable models as the future. If you specify a system using some language, which will be transformed in some other executable language, there often is a difference in computational models between these languages. In debugging such a system you need to understand both computational models AND the transformation. If we directly execute the model we can debug at the model level. Richard needs a language which means something by itself, without a lot of transformations. He compares a visual model which is transformed into code with C macro's.

Patrick Farail

Patrick did give a nice overview of the past and future of Model-Driven Engineering within Airbus. However, I think it's a bit to specialized to repeat it at this place.

Jeff Kramer

Jeff only had three adds to the previous speakers:

• Don't underestimate the adoption of Models, MDD, MDE, MDA, etc. into Software Engineering. There really is some adoption. Of course quality is still an important issue, but Jeff states that the industry should demand for that. Unless they do so, it won't become any better.
• Don't forget software architecture. Architecture Description Languages (ADL) are almost not used in industry.
• UML is both a blessing and a curse. It's great to have a common language, but in research we shouldn't only focus on UML parts. He recalls his keynote on abstraction, we have to ensure that models fit their purpose. Models must support and encourage experimentation.

Q&A

Why the presumption that models are pictures and not text? Fortran was mentioned as a textual modeling language. This triggered a long discussion on graphical versus textual languages. I'll list some remarks of the panel members.

Richard: if you design something, do you draw boxes and lines or write Fortran? Graphical languages are more expressive, and we can use them, we don't have terminals anymore.

Bran: but we need expertise on graphical/visual syntax. We have no theory behind and now we just model how we like it.

Jeff: the structure of languages isn't the most important point. It's about finding the right abstraction. The purpose of a model is to reason, argue, and discover new facts.

Bran: a language can be both graphical and textual at the same time. Writing is sometimes easier in text, but other models, like a hierarchical state machine are very difficult to express using a textual language.

Robert: graphical doesn't automatically mean visual!

Another discussion was about tools. Some panel members indicate that usability is a problem. Most tools are build for developers themselves and not for the users. Tool developers are too much thinking in computer science terms. The result: most of the time users are busy learning the tool, fight against it, and it will cost years to become an expert in a certain tool. Why not learn from the user, i.e. build a model of the user using expert systems and game theory.

Some issues:

• How to handle transformations? If components have their own transformations, the transformations of the combined components can be significantly different.
• Semantics are important, structural composition only isn't enough.

Interfaces and Metainterfaces for Models and Metamodels

At the first day of MoDELS '08 the subject of multi-modeling was already touched. This presentation was also focused on this subject, but from a whole different angle. The research group analyzed two software projects, one of them was Apache Open for Business (OFBiz) which consist of 17 different XML based DSLs. They came up with the following observations:

• Extensive use of soft references (links between elements of different DSLs).
• Developers report:
  • Inconsistency among XML nodes.
  • Hard to evolve without errors.
  • No proper tool support.

The researchers came up with the idea to define explicit interfaces between the XML DSLs. They did mine the existing systems to automatically detect the soft references. Based on that information they automatically generated the interfaces between the DSLs. The interfaces are defined using XPath expressions.

The advantage of this approach is that interfaces can be detected in an automatic way. Once detected the interfaces are explicit and can be used in evolving the system.

• Design: steps to take to create an artifact.
• Synthesis: the evaluation of these steps to produce the actual output / artifact.

Don sees two important complementary notions in this field: Model-Driven Engineering (MDE) and Software Product Lines (SPL). MDE is about using high-level models to specify software and transforming them into low-level artifacts, while SPL is about software families. In SPL we know the problems and the solutions, we just want to automate the construction of these solutions. In short: MDE can be seen as a general paradigm for program synthesis while SPL can be seen as a domain-specific paradigm for program synthesis.

Background

Definitions

An object is a domain of points, its instances. This holds for all technological spaces, by example: a meta model is a domain of models, an XSD is a domain of XML files, and so on. This perspective on objects can be visualized using cones. In this universe of cones recursion exists (think about the UML meta model structure).

An arrow is a mapping / function / transformation / morphism between objects. Don further formalizes this definition to:

• Arrow: map between objects.
• Transformation: MDE implementation of an arrow.
• Tool: non-MDE implementation of an arrow.

A category is a collection of objects and arrows. A category has the following properties:

• Arrows are composable.
• Composition is associative.
• For each object an identity arrow exist (visualized by an arrow having the same object as input and output).

In literature other names for categories exist, like toolchain diagrams or megamodels.

Multiple arrows can have the same input, meaning that an object is transformed into different other objects. Multiple arrows can also have the same output, meaning that an output is constructed via different transformation from different objects.

If we look at a chain of objects connected with arrows, we can express the output as a multiplication of the transformation functions. So, the output can be described as an expression.

Software Product Lines

As said before an SPL is a set of similar programs (a family), which are defined by features and related by features. Don gives an example of a base program B1 which can be transformed (add code / add a feature) into a second program B2, and so on.

Combined with the previous definitions of objects and arrows, an SPL can be seen as a set of programs related with arrows, each arrow representing a feature. Reasoning along in the same way a program design can be seen as a chain of arrows and thus be described as an expression. We can also deduct that a program can have multiple designs. The last observation is that an SPL is a category.

Model-Driven Software Product Lines

A Model-Driven Software Product Line (MDSPL) is a combination of MDE and SPL. In this combination commuting diagrams arise. Commuting diagrams are the foundational idea of categories. The key property of a commuting diagram is that all paths from one object to another yield equivalent results.

Don adds one extra key concept to the definitions given above: operators. Operators are transformation to transformation mappings, i.e. a mapping from one arrow to another arrow.

Commuting diagrams enable verification and optimization of program design. Program design can be verified by relating different paths to each other using operators. Optimization of program design can be done by choosing different paths.

Conclusions

According to Don the main challenge of these techniques is to find domains were there are different ways to implement the same functionality. If so, commuting diagrams occurs and program design can be verified and/or optimized.

Don's main advice: do not only focus on models, that's just a part of the picture. You also have to focus on transformations and operators.

I'm aware of the fact that it is difficult to grasp the idea's of Don's keynote without any pictures. For a full understanding of the subject I recommend to read his paper. I like his fundamental view on MDE and I can see how we can benefit from these ideas. However, actually using his ideas in practice will be quite a challenge.

The presentation was focused on scenario integration, i.e. integrate two sequence diagrams. In principle four steps are needed to perform model integration:

• Formalization: not every modeling language is formal enough to perform integration operations on.
• Specifying view correspondence: specify the overlap between the models by providing a span.
• Merge: execute a "pushout" operation on the span (see category theory).
• Normalization: try to remove redundant elements, etc.

Behavioral Modeling and Composition of Object Slices using Event Observation

A well-known software modularity dilemma is that of crosscutting concerns. While in traditional programming approaches this can be solved using Aspect-Oriented Programming (AOP), when handling crosscutting concerns in behavioral models you'll need Aspect-Oriented Modeling (AOM). AOM comes in two flavors:

• (offline) transformation: we have a base model and separately defined aspects. These are transformed into one new model, which is executed.
• (online) composition: the aspects are not included in the base model, but executed separately. At runtime the base models and aspects are ‘composed'.

In the first approach you need full insight in the models and aspects (white box). In the second approach interfaces can be used, so you don't have to have full insight in the ‘other' models (black box).

The presented solution for (online) composition was based on observation (using probes, event based) rather than explicit communication between the base model and aspects. For technical details I recommend to read the paper.

WebWorkFlow

The WebWorkFlow DSL was presented by Zef Hemel from the Delft University of Technology. This Object-Oriented Workflow Modeling Language for Web Applications is an extension of WebDSL.  Why another workflow language besides BPEL, YAWL or Petri Nets? According to Zef these languages have the following drawbacks:

• They do not describe full applications.
• They are separated languages, and thus not nicely integrated with other languages needed to model a full application.
• They ignore the user interface aspects.
• It's all or nothing.

The 3 main design principles of WebWorkflow are:

• Linguistic integration.
• Abstraction layers (from concise to more verbose: process expressions, procedural workflow, WebDSL). 
• Full application generation.

WebDSL already contains a data model, UI and access control module, which are all specified using textual DSLs. On top of that the WebWorkFlow module has been build.

Zef demonstrated how to define a workflow using the WebWorkFlow language. I'm not going into details, I think the documentation of WebDSL will be updated soon.

WebWorkFlow supports quite a lot of the workflow patterns defined in literature.

TCL: Train Control Language

Andreas Svendsen did show a nice application of Domain-Specific Languages. He, his collegues, and some domain experts did define a graphical language for train controlling. The language includes line segments, signals, stillers, switches, track circuits, etc. and is defined using an EMF meta model. The graphical editor was constructed using GMF. Using MOFscript source code for PLC's is generated.

Andreas states the following experiences:

• It is import to involve domain experts in the process and to exchange domain knowlegde.
• It is quite a challenge to transform models into an already existing framework.
• Some manual code updates were needed in specific situations.
• They still make use of the V-model, because the system has safety critical constraints.

In their future work their going to focus on variability modeling for creating variations on values and structure. He refers to the paper Adding Standardized Variability to Domain Specific Language I didn't have time to read this paper, so you have to do it with the link ;)

NAOMI: An experimental platform for Multi-Modeling

Edward Jones from Lockheed Martin Advanced Technology Labratories did show NAOMI, a platform for Multi-Modeling. Multi-Modeling is about having different DSLs for different system aspects. Edward identifies the following key challenges in multi-modeling:

• Multi-model interdependencies (you'll need change propagation (see point 3 of the linked article)).
• Multi-model consistency (how to identify inconsistencies and how to fix them? How to allow independent simultanous model changes with distributed teams?).
• Semantic precision of inter-model data exchange (do DSMLs need to share the same meta model?)

Edward demonstrated NAOMI, which in principle provides an infrastructure for managing multiple models with interfaces among them. Some addressed challenges:

• Consistency management (using 4 types of consistency: attribute, constraint, model attributes and project integrity).
• Change propagation (orchestrated and distributed).
• Version control system (multi-model repository management, multi-model time machine, etc.).
• Multi-model visualization (dependency graphs, etc.).

I did like his approach in explicitly focusing on the interfaces between DSLs and solving the multi-model issues. I also liked his example, showing the possibilities of multi-model management. He did show how a project budget model (in Excel) uses information from technical models as input, all managed by NAOMI. Of course the real advantage is in other scenario's, but it was just a funny example which I didn't expect.

They've planned to make NAOMI open source... I'm waiting...

In principle abstraction consist of two elements:

• Simplify and focus (removing details)
• Generalisation (core or essence)

Jeff gives a nice example of the London underground map. In 1930 the underground lines are visualized according to the actual curves and distances of the lines. However, the map isn't easy to read. In 1932 Harry Beck came up with the first schematic image map, which just shows the essence, e.g. the underground lines and stations, without showing the curves and real distances. Nowadays each public transfer map uses this way of abstraction. One important thing: you have to mind the gap with reality. It's not a map of London, distances between stations can be much longer than visualized (so don't try to walk without looking at a real map). The message: fit for purpose.

Why is abstraction important in Software Engineering? Just because software is abstract. All kind of activities in Software Engineering have to deal with abstraction. For example:

• Requirements: elicit critical aspects of the real world, neglect the irrelevant.
• Design: avoid unnessary implementation constraints. Design is often done using abstract syntax or abstract machines.
• Programming: use data abstraction, classes, and so on.

Is it possible to teach abstraction?

Jeff cites Jean Piaget, which defines four stages of cognitive development. The 4th stage, which is usually from 12 years old to adult, is called 'formal operational thought'. In this phase man learns to think abstractly, systematically and hypothetically. The bad news is that only 30%-35% of adults will develop the ability for abstract thought. The question is, can we teach abstraction and thereby give the other 65% also some ability for abstract thought? Or can we just improve it?

Although abstract thinking is key to software engineering, no courses on abstraction are given at university. However, each course in software engineering studies uses abstract thinking. So, abstraction is essential, but is thaught indirectly.

According to Jeff it can be ensured that students can make use (or understand) abstraction, by

• Teaching enough mathematics,
• Teaching (formal) modelling and analysis.

He goes something deeper into modelling, with some definitions. If you're interested in the fundamentals of modelling and meta modelling, just read the first part of my article on Combining GPLs and DSLs for Model Driven Engineering.

He concludes that teaching abstraction works for understanding abstract models. However, producing a model is still difficult, unless you're part of the lucky 35%.

Conclusion

If we want the best Software Engineers we have to teach abstraction. Teaching abstraction in an indirect way works quite well, however, making it more explicit will help in understanding the essence and making the knowlegde transferrable among domains. Besides teaching abstraction it is important to test formal operational thinking, put in another way: we have to test whether someone has the ability to think abstractly. Jeff is researching the possibility for such a test. 

The article The camel has two humps came into my mind when listening to Jeff. This article describes the ability to learn programming and points out that programming teaching is useless for those who are bound to fail and pointless for those who are certain to succeed.