odeling, and especially UML, is becoming more and more important in software development. After you’ve participated in a number of software projects, you will realize that developers use models in different ways for different purposes.

In our book on Model Driven Architecture (Addison-Wesley) we defined six (0 through 5) Modeling Maturity Levels (MMLs) to characterize the role of modeling in a software project. In the following, we give you a quick overview of the different MMLs, followed by examples of models at each level. The awareness of the different MMLs enables you to make an assessment of your own modeling practice, and may trigger you to try to reach for a higher level.

MML 0: No Specification
At the lowest level, level 0, the specification of software is not written down. It is kept in the minds of the developers. This level is often used in non-professional environments by people who have just started programming. This level is also used by professional developers who write software for themselves, “Why write a specification, I know what I want!” In this type of development the specification is bound to change continuously. Whenever the developer has a new idea, it will be incorporated in the software.

The downside is that without a specification, software of a substantial size rapidly becomes hard to maintain. When it’s necessary to introduce new developers into the project, they need to reverse engineer the code in order to figure out how it works and what it does. Even when the original developer is still around, he or she often needs to go through the same process. After a certain amount of time, nobody can remember exactly why or how a certain detail is as it is.

The Mailer Example
When our oldest son was 11 years old, he became interested in programming and we bought him SuperLogo for Windows. This is a programming environment based on Logo, especially developed for children. After studying SuperLogo for several weeks he had programmed all the exercises in the book and needed a new challenge. He said, “I am going to build you a mail program.”

At that moment clearly the only thing he had was a specification at MML 0. He knew that he wanted to build a system that would allow all members of the family to send simple notes to each other, such as, “I am going shopping. See you in a hour.” Note that this was never written down, he only told us verbally, and proceeded to implement the program. It took him a couple of weeks, but in the end he managed to get a very simple, file-based, non-distributed mail system working.

Although our son only had an MML 0 level specification, we will use the program he conceived as example for the other MMLs as well. We will show you the specifications that could have been made for this system on each level. Because the system is so simple, we will be able to present the specifications in more detail.

MML 1: Textual Specification
At MML 1, the software is specified by a natural language text (be it English or Chinese or something else), written down in one or more documents. This is the starting level for professional software development. At this level the user/customer is able to read the specification and comment on it, which is good. Because the specification is in text, it is ambiguous by definition and different interpretations usually result in confusion (or worse) amongst the different people involved, which is bad.

Another problem at this level is the actuality of the specification. Once people start writing code, the specification is usually not updated. After a while, the specification becomes completely outdated and loses its value.

For example, the following might satisfy as a basic textual specification for the Mailer application:

Build a system that allows the users to send messages to each other with the following features:

• A user should be able to write a message and send it to another user.
• A user should be able to read messages that are addressed to him.
• The system should notify the user when the addressee does not exist.
• All users are known in advance (the members of our household). There is no need to add or remove users.

MML 2: Text with Models

Figure 1. The Specification on MML 2 of the Mailer: This is basically the same as the specification on MML 1. The text is enhanced with just one small diagram to show the main objects in the system.

At MML 2, a textual specification is enhanced with several models to show some of the main structures of the system. The models often take the form of diagrams, with UML being the de facto standard for expressing these. The models at MML 2 are usually at a high level, and show the main parts, components, or objects of the system under development.

With respect to MML 1, the specification is easier to grasp through the diagrams. They play the role of a high-level map to the textual parts of the specification. The specification is still mainly textual, and the diagrams are not very precise. Therefore, the disadvantages of MML 1 (ambiguous and quickly outdated specs) are still present.

The specification on MML 2 of the Mailer is basically the same as the one on MML 1. The text is enhanced with just one small diagram to show the main objects in the system (see Figure 1).

As you can see, the model gives some insight in how the system should be build, but details of the model are still lacking. There are no attributes/fields, operations/methods, etc.

MML 3: Models with Text
At MML 3, the specification of software is written down in one or more models. In addition to these models, natural language text is used to explain details, the background, and the motivation of the models, but the core of the specifications lies in the models.

Figure 2. MML 3?Models with Text: At this level, the model for the Mailer becomes more complete.

MML 3 is the first level where a model becomes a proper reflection of the software being built. The models are not just a roadmap for the reader, but show the structure of the actual code and are therefore good source code documentation. On the other hand, the transition of model to code is done mostly manually. This means that with the passage of time, after more and more changes, the models do not reflect the actual code anymore. The code is the thing that is polished until the customer is satisfied. The code is the thing that is changed when requirements change or bugs must be fixed. The code is the product. Keeping the models up-to-date is often considered to be unimportant and to time consuming, so after a while the once perfect source code documentation becomes useless.

Example
At this level, the model for the Mailer becomes more complete. There is a use case model, a class model, and a sequence diagram showing the user functionality, the structure of the system, and the way objects communicate to get the job done, respectively.

Figure 3. Another MML 3 Example

Figure 4. Variation on the MML 3 Model

MML 4: Precise Models
At MML 4 the specification of the software is written down in one or more models. Natural language can still be used to explain the background and motivation of the models, but it takes on the same role as comments in source code. If a number of models are used, the relationships between these models are clearly defined. For instance, a developer would know which models would be affected when he or she removes an operation/method from a UML class diagram.

At this level the models are precise enough to have a direct link with the actual code. For instance, a UML operation becomes a method in the code, with exactly the specified parameters and return type, and a UML attribute becomes a field with its get and set methods. Because of this direct link between models and code, it is possible to generate large portions of the code automatically. This is the level at which the OMG’s MDA or Model Driven Architecture is targeted.

Changes to the system are done in the models, after which the code is regenerated. In effect the models become part of the source code. This means that it is easy to keep models and code up-to-date. Furthermore, the direct translation from model to code facilitates agile, iterative, and incremental development.

The model is more than just code in pictures. The model contains abstractions that are equivalent to many lines of generated code. For instance, an association in a UML class diagram may have the multiplicity many (‘0..*’, ‘*’, ‘1..n’, or ‘0..n’). In the code this means that the field that implements this association will not only have the normal getter and setter methods but also add and remove methods. In fact, the simple diagram we showed at MML 2 implies that the generated code for the class Person has the following set of methods (we use the UML convention to write the type after the method and its parameters).

• getMessages(): Set(Message)
• setMessages(newMessages : Set(Message) ) : void
• addMessage(newMessage: Message) : void
• addMessages(newMessages : Set(Message) ) : void
• removeMessage(newMessage: Message) : void
• removeMessages(newMessages : Set(Message) ) : void

Furthermore, because the association is bidirectional, the generated code for the class Message will have a field representing this link, probably something like: private myPerson: Person. The implementation of the above methods will ensure that this field is set to the right value for all messages involved.

It is clear that this type of model is more difficult to develop, but the added value is that much of the code can be generated. And if there is no code generator available for your programming language, or for whatever reason, the developer will at least be able to work very fast, because it is so clear what needs to be done.

Example

Figure 5. The MML 4 Specification of the Mailer: This is the specification at MML 3 enhanced with precise information. Pre- and post-conditions are added to the different operations, to specify exactly what the operation must do. Use cases have pre- and post-conditions attached to them. The class diagram contains additional constraints to clarify what a correct model looks like.

The MML 4 specification of the Mailer is the specification at MML 3 enhanced with precise information. Pre- and post-conditions are added to the different operations, to specify exactly what the operation must do. Use cases have pre- and post-conditions attached to them. The class diagram contains additional constraints to clarify what a correct model looks like (see Figure 5).

In addition to this, several OCL expressions are used to make the class model more precise. We will explain OCL at length in a future DevX article.

context Mailbox::namederive: owner.name context Mailbox::receive(m : Message)post : messages->includes(m) context Mailbox::remove(m : Message)post : not messages->includes(m) context Mailbox::readMessage(m : Message)post : m.isNew = falsecontext Mailbox::findMessage(from : String) : Set(Message)body: message->select(m | m.fromName = from) context PostOffice::findMailBox(name : String)body: boxes->select(b : b.owner.name = name)->any() context PostOffice::createFailedMessage(from : String)post : result.isNew = true and result.toName = from and result.fromName = 'PostOffice' and result.content = 'Cannot deliver message, addressee unknown' context Message::isNewinit : true

Also at MML 4, the use case description is enhanced with pre- and post-conditions (see Figure 6).”

Figure 6. Use Case Description: The use case description is enhanced with pre- and post-conditions.

The sequence diagram is enhanced with the PostOffice class.

Figure 7. The Sequence Diagram: The sequence diagram is enhanced with the PostOffice class.

MML 5: Models Only
At MML 5 the models are precise and detailed enough to allow complete code generation. The code generators at this level have become as trustworthy as compilers, therefore no developer needs to even look at the generated code. It is as invisible as assembler code is today. In other words, the MML 5 is the modeling Valhalla.

Unfortunately, there are no modeling languages in which we can write MML 5 models. We cannot work at this level?yet. Currently we still need to hand code a lot of nitty gritty details. This is the reason why we do not give an example here. Only within specific and limited application domains there are languages and tools that can achieve this. Most notably different vendors selling their versions of ‘Executable UML’ provide solutions in the realtime domain.

The challenge for all of us working in this field is to reach this level. And we will, eventually, because the people who commission our software will become more and more demanding, until the point that we will not be able to hand code software. No matter how many people we put on the project and no matter how much time we have, the software of the future will be too complex. We can only battle this by taking software development to the next level of abstraction: models only.