Welcome!

You are reading the premier issue of the Pathfinder Beacon, Pathfinder Solutions' occasional newsletter on Model Driven Architecture. Our goal is to be just what you need - NOT another e-mail advertisement masquerading as news. In each issue we'll cover topics related to MDA in a brief format that we hope you'll find entertaining and informative.

Enjoy!

The Editor

Feature Article

What Does a Good MDA Model Look Like? (Part 1)
Greg Eakman, PhD
Pathfinder Fellow

On a recent consulting job for a Department of Defense program that uses Model Driven Architecture (MDA), the director of the program asked, "What does good look like? How do I know it when I see it?" He could have asked this question about anything - it's hard to answer even for things we are familiar with, like cars and toasters. Often our best response is intuitive: "I know it when I see it." Unschooled intuition does not help us much when we evaluate MDA models. Intuition must be developed.

For MDA models and for software in general, we don't have quantitative measures to judge quality. In that sense the measures are arguable and subjective. Still, we can identify the qualities that make an MDA model good, and use them to evaluate our work.

Models are simplifications of reality made for the purpose of understanding and answering questions about the real world. Like other theoretical constructs, MDA models define their own standards of success. If they answer the questions they are meant to answer, or solve the problems they are meant to solve, they work. If a model fails to meet its own purposes, it doesn't work.

Modeling with a purpose, then, is critical. Each domain in an MDA model needs a written description that states why it exists. All of the diagrams developed for the domain are oriented toward that purpose. Models designed with their own purposes constantly in mind turn out to be of good quality. A model with a sure sense of itself is appropriately:

• Abstract

• Detailed

• Precise

• Complete

Successful models are also consistent, understandable, and maintainable.

Let's take a brief look at each of these qualities:

Level of Abstraction
The model must separate the concerns of the system being developed. This separation includes subject matter domain separation and separation of the platform from the application model. Improper abstractions lead to very complex class diagrams and behavioral models.

Detail
Models remove detail from the actual thing being modeled. If the wrong details are removed, the model is not useful for gaining understanding. The detail left in must be accurate enough to help engineers answer the specific questions they have posed. Early models of a car may focus on the styling and aesthetics of the body, for example, but leave out details of weight and engine size.

Precision
As indicated above, the precision in a model reflects the requirements of the modeled object or system. The measurements required for aerodynamic analysis of a car body, for example, must be quite accurate. Modelers might be interested in changes of a millimeter or less.

Completeness
MDA models must be complete with respect to system requirements, subject matter, and operational scenarios. If they address these areas well, they contain enough information to answer the questions for which they are built.

Consistency
MDA modeling tools support the creation of syntactically consistent models. The models themselves must be consistent from the point of view of the application. For example, two different components must work together to complete a given task, but inconsistent views will lead to integration problems. MDA models must also be consistent with models and documents outside of the MDA process, including software requirements, other architectural models, and test procedures.

Understandability
Modeling is a great step up from code in terms of understandability. It's possible, however, to create models that do not communicate their intent to reviewers, maintainers, or testers. Thoughtful naming of model elements and complete descriptions in the documentation are critical to understandability.

Maintainability
Systems and software have a long lifetime, much longer than an individual developer's role in a project. Military systems are in the field for 20-40 years. Business software written in the 1970s was updated to handle the year 2000. Models must be flexible to the variations of the real world and in the face of changing requirements.

Conclusion
Models simplify reality in order to achieve well defined purposes. If an MDA model meets the requirements that it sets for itself, we call it good. In follow-on articles, I'll explore these concepts further. These investigations include some handy tools for evaluation, such as anti-patterns, quality indicators, and rules of thumb. These tools often uncover violations of the measures I've summarized here, and suggest ways to fix them.

Interesting Links

The following is a list of web sources of interest to the MDA community:

http://www.omg.org
The web site of the Object Management Group, an open membership, not-for-profit consortium that produces and maintains computer industry specifications for interoperable enterprise applications, including Model Driven Architecture.

http://www.eclipse.org
Eclipse.org is the website of the Eclipse Foundation. Eclipse is an open platform for tool integration built by an open community of tool providers. Operating under an open source paradigm, with a common public license that provides royalty free source code and world wide redistribution rights, the eclipse platform provides tool developers with ultimate flexibility and control over their software technology.