Aali's blog : Model-driven software engineering, Tampere, Finland, 9-11.8.2006

Model-driven software engineering, Tampere, Finland, 9-11.8.2006

Edit: added the link to my ppt file

Last week I had the pleasure of attending (and also speaking at) a very high-quality event about model-driven software engineering. The main speakers were world-class experts on modeling, namely Bran Selic (distinguished engineer at IBM Rational) and Thomas Kühne (professor at Technical University of Darmstadt, Germany). The event was technically organised by the University of Jyväskylä and professor Kai Koskimies from Tampere University of Technology. The official page for the event is at http://www.jyu.fi/it/laitokset/cs/en/infwest/seminars/modeldriven_se.

My presentation can be downloaded here (7,5 MB ppt file).

Here is an overview of the event as I experienced it.

General

The presentations consisted of roughly three parts: Bran discussed UML/MDA/OMG -related topics, Thomas discussed mainly topics related to research work on modeling and I talked about Software Factories approach on modeling.

Motivation

The event started off with an introduction and motivation talk by both Bran and Thomas. The basic motivation for modeling is to raise the level of abstraction in software engineering. The problem that we as an industry are trying to solve is the miserable state of our profession, ie the problem of so many real world projects failing in one way or the other. Of course this is caused by potentially many different reasons, not nearly all of them related to the actual software engineering work. But for software engineering, modeling is generally seen as one potential technique to make it better.

Bran noted that modeling is an area of computer science that is not yet at the same scientific level as eg compiler technology has been for a long time. Sound formal theory is something that is inevitably needed. Only about 5-8% of the software industry currently use modeling in real life projects and only a fraction of those use modeling as more than just a documentation aid (like generating code, config information, guiding management tools etc). So, clearly there is something wrong, but what is it? Why is modeling not used more if it promises to solve at least a part of a major problem?

Understanding what existing code does when executed is like mentally playing the compiler, which is not an easy task. Writing code is a fragile task, even a single error can cause tremendous losses. If writing code by hand is so risky, we need to find a way to avoid writing repetitive and routine code alltogether and try to move on from current tools to a higher level of abstraction (ie modeling)!

But, life with models is not so easy either: designing good modeling languages is not an easy task, tool integration currently leaves a lot to desire for and what do we do about all of the existing code that's out there?

Of course, the OMG approach to modeling means using UML (Unified Modeling Language) and MDA (Model Driven Architecture) as the basis.

A few notes from Bran's presentations:

There is no MDA standard, it is "just" OMG initiative.
Profiles aim to offer a way to implement domain specificness in UML
Using PSMs (Platform Specific Model) does not mean that PIM (Platform Independent Model) is platform ignorant but rather platform independent (eg you cannot successfully design a spacecraft control software without taking into account the communication delay between controller and the spacecraft)
PIM/PSM story is generally over simplified - it is not straightforward
Vitruvius has written an excellent series of books (Ten books on architecture) on 1st century BC that have very relevant content for software architecture as well
Mathematics is an excellent foundation for developing and honing abstraction skills

Thomas continued by stating that as we take more and more a modeling approach to software engineering the more code degenerates to only a derived artifact that is not interesting in itself and should not be touched. The models are the important artifact (in UML, it means PIM). The idea is that we reuse solutions produced by experts rather than write all the code from scratch, thus avoiding errors caused by writing dull repetitive code. We had a lot of discussion on what exactly is a model. While there were lots of requirements, one main requirement is that a model needs to be usable for a particular purpose. It usually includes hiding irrelevant details so that the relevant aspects are more readily available.

Bran was very much in the favor of executable models. Somebody (who's name escapes me) had said that "nonexecutable models are like cars without engines". In addition to just executability, you typically also need controllability (to be able start/stop/pause etc), observability (statistics etc) and partial execution (able to execute only parts and even incomplete models). If the model is not executable there may easily be hidden inconsistency or incompleteness that is hard to reveal just by looking at the model. A typical example here is telecom standards that are just documents (a lot of them!) that need to be refined when they are implemented the first time. Being able to show the famous "Hello world" demo is tremendously important since it gives the "it works" experience.

So, what keeps us from modeling? A key finding is that fear of paying too much performance penalty should not stop you from modeling. Typically the penalty is something in the order of -5% to 15% (yes, sometimes it can be faster). One important obstacle is also that the culture is not yet ready for MDD. If you further analyze the reasons the following can be identified:

immature tools
lack of formal theory
modeling language design is hard, very little guidelines etc
investment effort
lack of expertise
amount of legacy code and not sure how to deal with it

These are more or less objective reasons, subjective ones include lack of awareness (people just don't know about it) and cultural issues. I might add that also one issue is that developers think that they lose control when they are forced to work on a higher abstraction level that is defined by someone else. This is an old issue that always comes up when the level of abstraction is raised, just look at the difference between Java and assembler - (nearly) nobody complains that they are not able to get the same level of control with Java as they get with assembler!

Anyway, (according to Bran) there are a lot of interesting research topics in the area of modeling, including:

Theory of modeling language design (abstract syntax, semantics, notation, specialization, domain-specific languages etc)
Theory of model transformations
Model analysis
Model synthesis
Automation/tooling support

UML and modeling

Bran presented several sessions on UML/MDA and Thomas on modeling theory such as abstraction in general, types, instances and classification (including his own research on "Deep Instantiation"). UML 2.1 is the current version. It includes the core language and optional language units. In order to verify compliance with the spec, there are 4 levels of compliance (L0-L3) with 2 possible dimensions. Alltogether (with all dimension variations) that makes 16 possible compliance steps (which is way too much in my opinion to be useful). MDA is defined as being the umbrella term that contains all of the relevant standards to support model-driven development. This includes UML and MOF (Meta Object Facility).

One note that caught my attention from Bran was that in the beginning he didn't expect UML to be all that popular as it currently is, he thought the world would want a more domain-specific approach to modeling. Turned out that the world needed a consolidation of the multitiude of different modeling languages available at that time. After all, the U in UML stands for "unified".

Another note from Thomas was that it is important to distinguish generalization (eg inheritance in OO) from classification (different levels of metalanguages). A couple of sanity checks that imply generalization:

do we want instances of the lower concept to be regarded as instances of the higher concept?
do we want attributes in the higher concept to become attributes in the lower concept?

A famous example was discussed showing a pipe and french writing (translated in english): This is not a pipe. The idea is that while it shows a pipe, it really is not a pipe, but rather a picture of a pipe. It demonstrates the difference between a model and the real artifact.

Software Factories

My presentation (about 1,5 hrs) covered the surface on Software Factories idea and it's modeling approach which is all about domain-specific languages. I also had two copies of the book available for interested people to dive deeper. The basic ideas in software factories are the following:

it recognizes the fact that real world software engineering involves lots of other tools and techniques than modeling
models have many more uses than just documentation and transformation, such as referencing other models, tracing, estimating impact of changes, consistency validation etc
Software factories are specific to a specific domain and use domain-specific abstractions (such as viewpoints/modeling languages, diagram types, process) that are defined by the domain expert(s)
it supports product line engineering, separating common and variable features
it is typically useful only when there are more than one solution to be built on the same domain so that the initial effort pays off
it is based on a "factory schema" which organizes around relevant views of the product line architecture

Visual Studio 2005 Team Edition for Software Architects ("Team Architect" among friends) also include early versions of DSLs for modeling .NET -based SOA-style applications. While they are not yet based on DSL Tools, they very much reflect on the idea we have in DSL Tools as well.

I also showed a very short demo on what the DSL Tools (April CTP) functionality looks like in Visual Studio. We should have the RTM release on DSL Tools within a month or so.

Similarities between MDA and Software Factories include:

both use models and mappings between them to build applications
both recognize the value of using models for automation

Differences include (Software Factories view):

real world projects involve several viewpoints that are domain-specific and many of them are better supported using not only models but also patterns, samples, templates etc
there are a lot of other forms of automation besides transformation
Software Factories focus on software product line, not one off development

Domain-specific Modeling Languages (DSMLs)

Bran talked about how to achieve domain-specificness in the UML world. First of all, when it comes to designing languages, there are lot of requirements for successful languages like technical validity, expressiveness, efficiency, familiarity etc. Of course the main reason for using a domain-specific language is expressiveness: you can get exactly the features you want for the task at hand without resorting to generalizations. In UML world, there are two possibilities to achieve domain-specificness:

heavyweight extension (removing/replacing/adding parts from/to UML)
lightweight refinement (using profiles)

In both cases UML remains as the base language, which may not always be the right choice. For practical reasons, when transforming models it is important to utilize inrementality for achieving performance.

Miscellaneous

A lot of the motivation parts are, if not identical, very close to the messaging we have around Software Factories. That's not very surprising, as the general problem we are trying to solve is or course the same.

Bran and Thomas had a chat about formality. Bran said (and I totally agree) that formality is a matter of how deep you want to go. There is always the informality somewhere if you go deep enough, ie the basic elements of formality must always be explained in freeform language. Thomas did not quite agree with this, but I might have missed the conclusion if there was any.

DSL Tools do not have (yet) a declarative way of expressing constraints. It has a validation framework that allows defining validation rules, but currentl it has to be done by writing code (typically C#). This is a bit odd since Steve Cook, who works at the DSL Tools team at Microsoft, is the moral father of OCL (Object Constraint Language), see this.

Many of the public people in the modeling area know each other very well. Bran knows Jack Greenfield very well (Jack, the father of Software Factories, was Bran's manager at Rational), Steve Cook [MS], Alan Cameron Wills [MS] and Juha-Pekka Tolvanen [Metacase] are also active part of the "family" of people who influence a great deal of where modeling is going.

Summary

Automating software engineering and modeling as a technique seems indeed to be at the center of attention of many software engineers nowadays. Also several major software companies (IBM and Microsoft included) are putting considerable effort on making it effective and useful in day-to-day engineering. This particular event was extremely good on explaining both the motivation and the current state of the art.