Model Driven Inside

Last week the second Dutch Model Driven Experience conference was held in Amsterdam. The goal of this conference is to stimulate the use of Model Driven Development (MDD) techniques and practices. The program was centered around practical experiences and “lessons learned”.

Two main approaches

In principle two main approaches were presented by different companies. The first approach is that of a tool vendor delivering a model driven software factory which can directly be used by business engineers to build their application using high-level modeling languages. Examples of exposing vendors are Verum, Thinkwise, Novulo, and Mendix.

The second approach is that of a company building their own model driven software factory using DSL tools. With these tools it is possible to design and develop Domain-Specific Languages (DSLs) which can be combined into a model driven software factory. An example of such a project, build by Ordina, is Mod4J, build with openArchitectureWare and recently published as an open source project.

Most companies presenting their efforts emphasized that this approach is perfect for flexibility: you can change the DSLs yourself. This approach also enables to build more specific DSLs aimed at a problem domain (e.g. insurance, pension). These DSLs are often referred to as vertical DSLs. However, almost all companies also mentioned that it is sometimes difficult to get resources to work on the model driven software factory. You’ll need initial effort, i.e. the costs come before the reward. It is even more difficult to maintain the model driven software factory and to translate project-specific efforts into the generic factory thereby continuously evolving the model driven software factory. So, if the model driven software factory only is a tool to help with the main business (and thus isn’t your main business itself), it can be difficult to construct a convincing business case for the upper management.

Panel discussion

The Model Driven Experience did conclude with a panel discussion answering the questions of the audience. Attendees could also submit written questions during the conference. I was part of the expert panel, together with Jos Warmer, Wim Bast, and Michel Chaudron. I think it was an interesting session with lots of good questions.

I want to show you three of the question with some pointers to answers, to give you an idea of the topics. One of the question was about the business case for building your own model driven software factory. The discussion covered the roles needed in model driven engineering and the activities involved in building a model driven software factory. In essence the question is to buy or to build. It depend on your specific needs what to choose.

Another question was: how to design a DSL? The answer depends a bit on the situation. A possible way to design a DSL is to take existing code bases for a certain type of application and analyze them. The parts of the code common for each application, i.e. the commonalities, can be part of a generic framework. The variable parts need to be covered by the DSL. However, if you want to tailor your DSL to domain experts it can better to take a more iterative approach, with close involvement of the domain experts. In this case concepts of Domain-Driven Design can be used in DSL design.

The last question which I think is interesting to mention is if it is possible to add the requirements phase to model driven development to make it even more easy to build software. The first remarks of the panel were on the fact that if you are going to use requirements to drive the development process, the requirements need to be in a formal format. This means that you still need analytical skills to create the first model. The other option is to accept informal models as first step in the model driven development process. These models are connected to formal models to enable the tracing from high-level requirements and business models to more technical, formal models and back. An example of such an approach is the integration of Bizzdesign and Mendix.

Roald Kruit, CTO of Mendix, pitching the integration of Mendix with Bizzdesign during the Model Driven Experience

For the 2nd time in history, the Model Driven Experience will take place, this year on June 4th, 2009.

I was there last year, on the 1st edition, and I remember there being a lot of energy and new ideas in the room. As Model-driven Development and MDA is gaining more popularity, and more importantly, more proof of its added value, I expect this year’s edition to be even more interesting.

Driving force behind the Model Driven Experience event is Maarten Steen, researcher at Novay. When asked for his expectations for this years event, he says he expects to get a mixed audience of practitioners, business, researchers and vendors.

Register Now. Early birds get a discount before May 15.

Last month, Jordi Cabot launched a new portal, fully dedicated to model-driven development. When asked to describe the goal of his blog, Jordi explains:

“The goal of this portal is to explore and discuss /when/, /where/ and /how/ modeling and modeling languages (and when NOT) can improve the current software development practice. I hope to involve both researchers and practitioners in this discussion. Some of the technologies/methods/notations that will be covered in this portal are UML, Model-Driven Development (MDD), Model-Driven Architecture (MDA), OCL, model-transformations,…”

He motivates:

“Basically, I’d like to approach modeling to the practitioners to see how the work we do as researchers in software engineering can have an impact on their day-to-day work. Most of the time I’ve the feeling that we live in completely different worlds. To try to achieve this, the portal will provide model-based content and services and the “Software Modeling.”

Go visit @ http://modeling-languages.com

Many discussions on the nature and implementation of DSLs these days tend to gravitate towards Ruby. The syntax and grammar of Ruby just allows the formulation of DSLs in a manner that other languages don’t. Jamis Buck (of Rails fame) has a short write-up of his experience writing DSLs in Ruby.

http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

John K. Waters of Application Development Trends covers CA´s move to enter the MDD arena.

CA’s latest release of its Plex rapid application development environment now lets developers model and generate Microsoft .NET-based services based on Windows Communication Foundation (WCF).

Plex is a multiplatform, model-driven development (MDD) environment that includes architectural and design objects known as patterns, which can reduce the need to code repeatable elements in applications. Islandia, N.Y.-based CA, a supplier of IT management software, announced its latest version, Plex 6.1, on Tuesday. (…)

A growing number of vendors, large and small, are offering MDD tools and frameworks, including IBM (with its acquisition of Telelogic), Intelliun, and Mendix. For its part, CA offers four MDD tools: Plex; 2E; Gen, a dev environment for high-performance business applications; and Aion Business Rules Expert, a rules-based application development tool.

Other improvements to the Plex 6.1 release include easy viewing and documenting of group model updates, improved APIs for extending the Plex environment programmatically, and IPv6 support. More information on Plex can be accessed at CA’s site here.

At http://www.agilemodeling.com/, Scott W. Ambler introduces us to the concept of Agile Modeling (AM) or Agile MDD.

In Scott’s words,

As the name implies, AMDD is the agile version of Model Driven Development (MDD). MDD is an approach to software development where extensive models are created before source code is written. A primary example of MDD is the Object Management Group (OMG)’s Model Driven Architecture (MDA) standard. With MDD a serial approach to development is often taken, MDD is quite popular with traditionalists, although as the RUP/EUP shows it is possible to take an iterative approach with MDD. The difference with AMDD is that instead of creating extensive models before writing source code you instead create agile models which are just barely good enough that drive your overall development efforts. AMDD is a critical strategy for scaling agile software development beyond the small, co-located team approach that we saw during the first stage of agile adoption.

More information can be found on his website : http://www.agilemodeling.com/.

Enterprise Component has a collection of whitepapers relating to SOA and MDA that is bound to be relevant to many of you. Some of the papers are in DOC format, but that should hardly be a barrier. Enterprise Component is a member of http://www.modeldriven.org/.

Take a look at their whitepapers at,
http://www.enterprise-component.com/whitepapers.shtml

UML seems to be a polarizing factor in the software development debates. The Learning LISP blog chimes in with observations on the lack of added value UML brings to the design and development process.

UML is applying an abstraction at the wrong end of the problem. It is primarily used to sketch object models for inferior languages. As such, it tends to explode into incomprehensible patterns of accidental complexity in order to accommodate the various “design patterns” that are used work around the lack of essential language features.

Read the full article : Why UML Fails to Add Value to the Design and Development Process.

Peter Friese attended the Model Driven Software Development Today conference and posted a recap with overviews, items and a good deal of images. If you weren’t able to attend, this provides a good overview of what you missed out on.

http://www.peterfriese.de/mdsd-today-2008-recap/

We have by now a solid 50 plus years of collective experience in the development of commercial-purpose software. Though the field has yet to reach the maturity of traditional engineering disciplines, a few things have become very clear in this relatively short time.

First of all, software development is inherently time-consuming and error prone. If nothing else, the amount of time invested in automated and manual testing infrastructures, methodologies and feedback-cycles should make this
obvious.

Secondly, large code-bases require experts to both maintain and expand them. Investment in a code-base therefore requires a long-term commitment from the company developing and supporting it. (Primarily in the form of acquiring and retaining in-house expertise).

Thirdly, any code-base that goes unmaintained for a long time will become unmanageable. The degree to which this happens depends on many factors, but include obsolescence of the technology used to build it, lack of experts that
still understand the technology and the loss of domain knowledge required to make competent decisions regarding the code-base.

These are general observations, but I have yet to encounter anyone who will disagree with them.

With these observations in mind, making sound decisions about the selection of technologies for development is hard.

Luckily we already have the means to start tackling these problems. They are standards and protocols. (A protocol is a standard, but is usually used to refer to a standard that defines dynamic or interactive behavior). In addition, the use of standards automatically enforces another aspect, namely abstraction.

Abstraction is crucial to the development of any system (software-based or otherwise). It allows us to build on work already done and provides us with a means of enforcing structured communications between discrete components of a
system. On the networking side we have the TCP/IP suite of protocols that power the Internet. On the more general software development side we use this generic functionality to provide e-mail, web traffic, instant-messaging, Voice over IP and many more applications without regard to the underlying network implementations. The functionality is simply there.

Let me repeat that for a moment. The functionality is simply there. We have managed to unify global communications across programming languages, hardware architectures and network varieties. Proprietary protocols notwithstanding, we have a global infrastructure that services billions of people every day.

This is a fairly impressive achievement. So why do the majority of large-scale commercial development efforts fail?

In my opinion a factor that contributes to this mess is the confusion of software development with application development.

Software decisions are hard-coded and static, but application decisions have to be flexible and dynamic. The two are not compatible.

Application development, on the other hand, is behavioral. Both can be boiled down to decision trees, but their nature is completely different.

The solution to this problem is to dis-entangle the two and view software as a construct that will accept formally defined behavior (in the form of configuration or DSLs) on the one hand and on the other provide an environment
for non-programmers to model the desired behavior of a system.

This is, in essence, what Model Driven Development (MDD) is about. Separating business logic from code-base logic. That code-base logic can go down many levels is a given, but business logic is multi-layered too and this presents a
different set of problems.

Any technology stack that facilitates this separation should, however, allow for custom transformation of the behavior at a high level and at the same time allow for extensibility at a low level.

High-level transformations are primarily important for integration with external systems (e.g. XML mappings), while low-level extensions (which require actual programming) should focus on logic that is not captured directly by the modeling environment.

These considerations aside, MDD provides a new level of abstraction whereby applications can be created and changed in near real-time by analysts that understand business requirements, but have no background in software
development.

To make this work, analysts have to be presented with a modeling environment in which they can directly dictate this logic, instead of going through intermediary parties. And this environment has to couple modeling with execution so decisions can be evaluated in real-time.

MDD tooling provides us with the structure to think about processes and business continuity instead of software instructions. This is a radical change from the traditional approach because it views business architectures from the top down.

From a business development perspective, MDD tooling and architecture allows one to stop thinking about software development risks and instead focus on application development. This area is still time-consuming, but low on risk. The high resource consumption is now focused on elements that are within an analyst’s control… rather than the vagaries of some software development team.

Mostly, MDD gives us a new way of thinking about existing problems. We have accumulated a vast knowledge base of how not to do things and MDD presents us with a new pattern for mapping old structures.