Channels ▼

Questioning Model-Driven Architecture

The Agile Newsletter: Questioning Model-Driven Architecture

Welcome to the Agile Modeling newsletter, edited by Software Development Senior Contributing Editor Scott W. Ambler. This monthly e-mail newsletter is a free service for subscribers to Software Development magazine and SD Online. If you do not wish to receive this newsletter, please follow the unsubscribe directions at the bottom of this message.

The Jolts! The best products! The lights! The glamor! The music was catchy, the patter snappy, the jokes ... well, hey, the best products! And the winners are:

>>>Upcoming NetSeminar: Model-Driven Architecture Examined

The editors of Software Development bring you a one-hour audio NetSeminar on June 4, 2003 on the topic of Model-Driven Architecture. Speakers will include industry experts; Editor in Chief Alexandra Weber Morales will moderate. Watch this space and www.sdmagazine.comfor registration information.

>>>Questioning Model-Driven Architecture

MDA has a long way to go, but it's likely to motivate some interesting innovations in the modeling tool market-innovations that we can all benefit from.

I'm often asked how I reconcile Agile Modeling (AM) with the Object Management Group (OMG)'s Model-Driven Architecture (MDA). My answer is that the two approaches are orthogonal--you can use each separately or together. Granted, I suspect that many people who are pro-MDA are also pro-BDUF (Big Design Up-Front), but that doesn't have to be the case. In fact, I advise the pro-MDA crowd to embrace iterative and incremental development as much as they can.

MDA separates the specification of system functionality from the specification of its implementation on a specific technology platform. In short, it defines guidelines for structuring specifications expressed as models. MDA promotes an approach wherein a single model specifying system functionality can be realized on multiple platforms through auxiliary mapping standards, or through point mappings to specific platforms. It also supports the concept of explicitly relating the models of different applications, enabling integration, interoper- ability and supporting system evolution as platform technologies come and go.

MDA is based on the idea that a system or component can be modeled via two categories of models: Platform Independent Models (PIMs) and Platform Specific Models (PSMs). PIMs are further divided into Computation Independent Business Models (CIBMs) and Platform Independent Component Models (PICMs). As the name implies, PIMs don't take technology-specific considerations into account--a concept equivalent to logical models in the structured methodologies and essential models in usage-centered techniques. CIBMs represent the business requirements and processes that the system or component supports, and PICMs are used to model the logical business components (also called domain components). PSMs bring technology issues into account and are effectively transformations of PIMs to reflect platform-specific considerations.

MDA is part of a collection of modeling-oriented standards from the OMG. These standards include:

XML Metadata Interchange (XMI), a standard interchange mechanism used between various tools, repositories and middleware.

Unified Modeling Language (UML), an industry-standard definition for object-oriented and component-based modeling artifacts. Version 2.0 of the UML will be released this Spring.

Common Warehouse Metamodel (CWM), the OMG data warehouse standard.

Meta Object Facility (MOF), which provides the standard modeling and interchange constructs that are used in the MDA.

MDA has four primary strengths:

1. It defines a coarse separation of views. When you're modeling, it's important to consider issues such as "what should the system do" and "what processes should the system support" without worrying about how it will support them. This freedom from worry enables you to consider a wide range of options. You can also find benefit in considering the logical domain architecture separately from the physical implementation architecture, because the logical architecture changes much slower than

the underlying technologies, allowing you to reuse your logical model as the system evolves over time.

2. It defines a viable strategy for system integration. MDA's explicit support for modeling relationships between systems/components can help to ease system integration; hence promoting greater levels of reuse in your organization. Legacy integration is a significant issue for most Software Development efforts.

3. It may motivate a new breed of modeling tools. The separation of views offers the potential for tools that automatically generate the "next model down," in particular PSMs from PIMs, based on automated mappings.

4. It may support tool integration. Part of the OMG's overall vision is to provide a set of standards for tool vendors to follow and thereby support integration of those tools.

Although MDA is promising, you should be aware of several potential challenges:

1. It doesn't appeal to developers. When was the last time you heard a programmer say "I'd really like to work on an MDA project"? When was the last time you bumped into a programmer who even knew what MDA was? MDA might appeal to academics, standard wonks and "professional modelers" who haven't written a line of code in years, but that's about it. If members of the OMG want to improve the state of modeling in the industry, they should work on real-world techniques that developers actually need, promote a more agile approach to architecture, and find ways to teach developers skills they can actually use in the real world. MDA doesn't fit into any of these categories.

2. There are other competing, and arguably better, strategies for system integration. The OMG isn't the only organization working on the issue of system integration. Viable alternatives include Web services, which developers understand and are actually eager to work with (unlike the MDA), and Common Object Request Broker Architecture (CORBA), another OMG standard. Luckily for MDA, developers need tools and techniques to understand the interfaces to Web services and CORBA objects--tasks for which MDA may be well suited.

3. The wunder-tools will prove elusive. The idea that you can (mostly) automate the creation of platform-specific models from your platform- independent models is theoretically sound, and we're seeing this happen in niche technical environments. However, I doubt that we'll see it in multiplatform, mainstream tools because the plethora of constantly evolving platforms will force tool vendors to choose a subset.

4. Tool integration will also prove elusive. Each tool vendor will support MDA in its own way, if they support it at all--something I call the "CORBA syndrome." The CORBA vision was great, and many vendors claimed to support it, but they implemented their own version of the specifications. Everyone talked a good game but easy integration proved elusive.

5. It requires a formidable skillset. MDA's underlying premise is that developers have significant modeling skills. Although this is a wonderful vision, it is realistic for a very small percentage of developers.

6. It's too closely coupled to the UML and its problems. Unfortunately, UML isn't complete ( ), and therefore MDA rests on a wobbly foundation. The members of the OMG should get the foundation in place first and then define the missing models from the UML. They're getting ahead of themselves with MDA.

7. There is a bias toward object and component-based technologies. Because MDA is based on the UML, and the UML is used to model object-and component-based systems, there is an underlying assumption that components will be your underlying building blocks.

8. Is MDA compliancy just a check box? I recently ran across a process definition project in which one of the high-level acceptance criteria was to ensure that the resulting process was "MDA compliant." The client didn't really know what that meant, but they knew it was important because several CASE tool vendors had told them so. Yikes.

I believe that the MDA vision is a good one. However, many other grand visions have never lived up to expectations. I'm not convinced that the MDA vision differs substantially from the integrated-CASE tool vision of the 1980s, and that vision clearly failed. The good news? MDA is likely to motivate some interesting innovations in the modeling tool market- innovations that we can all benefit from.

>>>Recently on the Agile Modeling Mailing List

Traveling Light
I began a thread with the observation that it's much harder for specialists than generalizing specialists to travel light. Because specialists are narrowly focused, they're more likely to overly invest time in the artifacts that they're familiar with, and less likely to choose the best artifact to capture information with. A generalizing specialist--someone with one or more specialties as well as general knowledge of and experience in the entire software lifecycle--is more likely to capture information in one place. For example, a team comprising a business analyst specialist, a data modeling specialist, several programming specialists and a test specialist is likely to capture a single business rule in their requirements document, their data model, their source code, and their tests. A team comprising generalizing specialists may capture a business rule only in tests and the source code. Because generalizing specialists have the ability to work with a wide range of artifacts, they can always access the information as long as it's been captured. Specialists don't have this option,so they must capture it in an artifact they understand (as do all the other specialists on the team).

UML Data Modeling
One topic that keeps popping up on the list is that of extending the UML to support a data model. Some people on the list believe that current data modeling techniques, including Object Role Modeling (ORM), are sufficient, and that we don't need yet another notation. Others believe that a UML data model may help to bring data-oriented techniques into the object community, something that is sorely needed, as most projects use both object and relational technologies together. This topic is related to MDA, as it's reasonable for developers to map their object schemas to their data schemas in an MDA-compliant manner.

CRCs and Wikis
One person asked about capturing the information contained in a Class Responsibility Collaborator (CRC) model in a Wiki instead of a collection of index cards. Many people disagreed with this idea because the value of CRC modeling is derived from the index cards--they're easy to work with, inexpensive, nonthreatening and inclusive. However, using index cards isn't an option when the team is spread out over several locations and needs to share the information.

>>>Recommended Online Resources:

Agile Alliance Home Page.
This is the best starting point for anyone interested in learning more about agile Software Development.

Agile Architecture.
This article explores how to take an agile approach to architectural modeling.

Agile Enterprise Architecture. article describes agile techniques and philosophies for enterprise architects.

Agile Modeling Mailing List.

Agile Modeling Training Resources.

Data Modeling 101.
Describes the fundamentals of data modeling, skills that every developer should have, and discusses how to take an evolutionary approach to data modeling that reflects the realities of agile Software Development.

Isn't That Special?
This column explores the challenges that specialists pose to productivity and argues that the most effective software developers strive to be generalizing specialists.

Mapping Objects to Relational Databases.
This page summarizes my most recent and most extensive writings on this topic.

Model Driven Architecture (MDA). Object Management Group, is the official MDA spec.

Model Driven Architecture (MDA) FAQ.

Object Role Modeling Home Page.
Describes the ORM diagramming technique.

Software For Use: A Practical Guide to the Models and Methods of Usage-Centered Design. Constantine, L.L., and Lockwood, L. A. D., 1999, New York: ACM Press.,4096,0201924781,00.html

UML Data Modeling Profile.
One of several unofficial profiles, arguably the most comprehensive to date, for data modeling with the UML.

Wiki Home Page.
The primary site for Wiki technology. Home Page.
Online tips and techniques for creating better software diagrams.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.