Re: Is MDA working for real enterprise projects?

From: H. S. Lahman (h.lahman_at_verizon.net)
Date: 01/08/05 

Date: Fri, 07 Jan 2005 23:44:04 GMT

Responding to DD...

> What continues to puzzle me, is that I have seen visual code generation
> tools come and go since the 1980's when I started in the IT industry, and
> I'm not sure what is special about MDA compared to these. Is it just
> incremental changes like standardization, or a new theoretical insight into
> OOA/D?

I would say it is about standardization and IDEs or frameworks that
allow various tools to plug & play. There is really not much in MDA
that could be construed as a major breakthrough in OO theory.

In fact, MDA is intended to be a much broader notion than OO development
or even software development. [FWIW, one of my problems with the recent
direction OMG is taking UML is that it is serving too many masters. UML
was originally intended to be just an OOA/D notation. However, OMG is
using it as a base for a lot more (e.g., Data Modeling, Business
Modeling, Requirements Modeling, etc.) However, to make it serve those
additional masters it has to be tweaked and enhanced. The result is
getting so big and complex that it is tough to use for any single purpose.]

>
> When you put the code into the model (more detailed semantics, action
> language), essentially this becomes a programming platform in itself,
> similar to Java with the once promised "write once, run anywhere."

For a model to be executable one has to have an unambiguous description
of dynamics. Activity Diagrams and Statecharts were not adequate to
describe detailed behaviors; for one thing they are really geared to a
larger scale than individual methods. So in UML v1.5 a big hole was
filled by providing an execution meta-model that could be used to
implement abstract action languages for describing what goes on within
methods.

However, the tricky part is to make sure that the AAL is sufficiently
abstract so that it is consistent with the rest of the OOA or OOD model.
  It really doesn't matter whether it is graphical like SDL or
text-based (though I prefer text based at the level individual methods;
graphics are great for the Big Picture but they tend to clutter when
down in the muddy details). Maintaining that level of abstraction makes
the solution model a true 4GL.

One of the implementation-level decisions one needs to make is the
selection of the correct language. One of the nice things about using a
4GL is that selecting the best language is no longer a decision driven
by the developer skill level at hand. If one only deals with the 4GL
solution, one can select the 3GL based on performance, etc. without
worrying about maintainability and complexity.

That is the basic idea behind the pure translation tools that do full
code generation from OOA models. One gets analysis reuse because the
OOA model can be translated without change into any language or
development environment (e.g., .NET vs. J2EE/EJB). This allows true
"write once, run anywhere" portability that is independent of OS,
language, and computing technologies de jour.

One gets design reuse because the transformation engine can translate
any OOA model for its particular computing environment. IOW, the
optimization for nonfunctional requirements is tailored for the
particular computing environment by the transformation engine. Better
yet economies of scale apply because the builders of the transformation
engine concentrate all the computing environment expertise, which leaves
the application developer free to deal with the customer's functional
requirements without any distractions.

>
> I like some parts of MDA, but when I see code mixed into the models, for
> some reason I can't explain, my experience tells me something isn't right
> with that. It reminds me of the WSIWYG web page editors that generate a
> tangle of HTML that becomes harder to maintain.

The key is that the code in the models, whether graphical of text-based,
is abstract in the same way as the rest of the OOA/D. Generally the
AALs have a whole lot less code than the resulting OOPL sources. You
only have to maintain generated in a round-trip environment where the
AAL is just a 3GL and the developer makes changes directly to the 3GL
code. That's because the code isn't really being generated; the
developer is just writing it in a different tool than emacs or the
language IDE.

In a translation environment with full code generation one very, very
rarely ever has to look at the generated code. (Usually only in an
R-T/E environment where one is also debugging the hardware.) Any
changes are made to the models and the affected 3GL code is regenerated.
  The models are also fully executable, so one does all one's debugging
in a model-level simulator rather than a 3GL IDE. [It is SOP to run
exactly the same test suite for functional requirements against the
models that one runs against the final executable. The only thing that
changes is the test harness.]

<unabashed plug>
bottom line: if you use a translation tool with a true AAL, then you
never have to maintain the generated code, so it doesn't matter what it
looks like. The entire application development is in a 4GL. You are
also dealing with an application solution that is focused purely on
functional requirements. And the model representation, including AAL
code, is still at least an order of magnitude more compact than than the
final 3GL source product.
</unabashed plug>

*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH

Relevant Pages