Responding to Kohoutek...

>i have read a lot of MDA related materials and articles and i think i
>have some theoretical knowledge which should help me to develop 'Hello,
>world!' in MDA. But where to start and what development environment
>should i choose to build models, use transformations and finaly generate
>some working code? By the term 'development environment' i mean set of
>probably various cooperating tools supporting modeling, transformations,
>compilers, editors, models and metamodels repositories, application
>server etc. (not necessarily all-in-one tools).
>
>

Let's take a step back. There are two fundamental approaches to
software construction, both supported by MDA. In traditional OO
software development (for example) one advances:

Requirements -> OOA -> OOD -> OOP -> Executable

Each node to the left of Executable is a specification for the solution
to the immediate right. Conversely, each node to the right of
Requirements is a solution for the specification on it immediate left.
So everybody in the middle is schizophrenically both a specification and
a solution. For traditional development (known as "elaboration"), the
value was added at each '->' by the developer. That value was the
addition of greater detail to address more specific issues. The
addition of detail gradually reduced the level of abstraction of the
specifications/solutions as one moved to the right.

The modern elaboration approach is epitomized by "round-trip" tools like
Together that provide fairly seamless migration between development
phases as well as providing automated support for things like version
control. Such tools effectively migrate solutions one the left to be a
starting point for adding value on the right. But the developer still
has to manually provide the grunt work of adding detail at each transition.

MDA supports this construction paradigm primarily at the tool interface
level. It allows one to use different tools (e.g., a UML drawing tool
for OOA and OOD vs. a language sensitive text editor for OOP)
seamlessly. More important, the tools can provide some migration of the
models themselves (e.g., generating header files and body stubs for OOP
models from the OOD models as a starting point). That's because MDa
provides a semantic meta-model for each phase that allows one to convert
unambiguously between models (e.g., OOA/D vs. OOPL code). Thus
standards like XMI are crucial to MDA because they allow plug & play
tools to communicate across the development stages.

The second major approach is "translation", which dates from the early
'80s (though the technology didn't mature for general computing until
the late '90s because of engineering complexities). In translation one
takes an OOA model and converts it directly into either an OOP model
(OOPL code) or an Executable). The key is that the transformation
process is automated so all the developer needs to do is create the OOA
model. (One also needs a transformation engine for the particular
computing environment that knows how to optimize the conversion of any
OOA model in that environment.) Because the process of OOD and OOP are
automated, there is no need for separate stages in the development.

In both approaches the Requirements Model is a CIM and the OOA Model is
a PIM in MDA terms. The OOD/P Models are both PSMs of different flavors
(e.g., strategic views vs. tactical views). (The Executable is
technically not a model because it executes as-is, but any intermediate
object libraries, etc. would be models because they require address
relocation during loading to become executable.) In addition, in both
approaches one has transformation engines that convert one model
representation to another. One also have the supporting MDa artifacts
like Transformation Models and Marking Models to support the
transformation process.

However, the value added by the transformation engine in a translation
context is much greater. That's because it essentially provides full
code generation. Since that code generation is from an OOA Model, which
only resolves functional requirements, the transformation engine must
automate and optimize the resolution of nonfunctional requirements.
That's nontrivial and explains why translation transformation engines
are so pricey and took so long to mature. Nonetheless, though
translation predates MDA, UML, and even OMG, the mapping into MDA is
actually pretty easy and MDa has provided very valuable
standardization. (Traditionally, translation tools were monolithic and
proprietary combinations of drawing tool, model simulator, code
generator and 3GL compiler, but that is changing to a more specialized
plug & play paradigm with MDA.)

So...

>My idea was that there will be available some general PIM (UML) to PSM
>(for example EJB) mappings (model-to-model transformations) and then
>also mappings from that specific PSM (EJB) to Java code deployable to
>application server. Those two mappings could be eventualy from different
>providers (vendors). That`s how it should work in the future, right? Of
>course there has to be standards (metamodels) which those mappings use,
>in this case the both vendors should share same metamodel for PSM.
>Is there such environment where i can use existing mappings and thus
>find the path from my PIM to running application or i have to create
>everything by myself (models, PIM -> PSM -> Code mappings)?
>
>

There are several translation tools on the market that will do it for
you for common environments. For example, PathMATE will produce C, C++,
or Java code directly from the PIM and will use whatever infrastructure
libraries are available in the process. (It will also generate MS Word
documentation of the models.) However, you still need to provides a
definition of nonfunctional requirements (primarily as pass-through tags
on model elements, which is a form of Marking Model). Everything else
will Just Work for any supported platform. [As a bonus you can even
validate your PIM before committing to production code. B-)
Translationists traditionally execute the same test suite for functional
requirements against the model that they execute against the final
product. Just the test harness changes.]

However, for elaboration things are not quite so easy. The round-trip
tools do very limited code generation. That means that any access of
infrastructures like EJB will have to be provided directly in OOPL code
that you provide for body stubs. (Depending on the tool there are
usually high level abstractions that one can invoke that may hide a lot
of the infrastructure grunt work (e.g., so you don't have to construct
SQL strings manually), but one still needs to explicitly write code
around those abstractions.

IOW, MDA is pretty much hidden in the elaboration approaches by the
tools themselves. The Marking and Transformation Models are there to
assist doing things like creating headers and body stubs from OOD
Models, but they come with the tool and the user normally doesn't see
them. In particular, any optimization transformation rules and policies
will have to be applied by the developer. [This is not quite true for
hybrid tools like Rhapsody that support both translation and
elaboration; such tools are capable of providing "smarter" body stubs
along the continuum. Note, though, that as round-trip tools become more
sophisticated they are moving more towards translation.]

BTW, like the translation tools, many of the round-trip tools like
Together were around before MDA. As a result, like translation tools,
they tended to be monolithic and proprietary, which is partly why the
Marking and Transformation models are often hidden and unavailable.

>It would be great if you could point me for example to some tutorial or
>guide which refers to working example of trivial application developed
>with MDA.
>
>I am currently using Borland Together Architect 2006 which has
>model-to-model and model-to-text (eg. code generation) capabilities.
>Problem is that there are no big examples or even predefined general
>transformations. I know this is not the right forum to ask for support
>about Borland Togegher but maybe you could comment that with words like:
>there are no such things as predefined general mappings in Together yet
>freely available or get another tool/environment or there are such
>mappings available but only for Together community etc.
>
>MDA theory is sweet and i want to make the move from books to real
>development based upon MDA. I know that this kind of development employs
>various specialists for different parts of MDA and it is not the 'one
>man show' but how can one become a specialist in some area of MDA? What
>should he do, which environment should he select according to his
>specialization and what data (models, metamodels, transformations)
>should he push into those tools to start working on it and become a part
>of system engineering based upon MDA?
>
>

In the end I think MDA is really a tool issue. MDA gets reflected in
the development IDE and the amount of automation. That's true of both
elaboration and translation. IOW, MDA's effects on your daily work are
not about what you do or how you do it during software construction.
Their effects are indirect in the way the development IDE is constructed
and how the tools make life more efficient for the developer. For
example, in an advanced IDE like Eclipse, the whole thing is constructed
around MDA principles but the individual developer creating an
application is unlikely to be aware of that.

--

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

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