Relationship between MDE, MDD and MDA (and also MBE)
Jordi Cabot
and MDD?
To me, MDE is a superset of MDD and MDD a superset of MDA (see the
picture here: http://modeling-languages.com/blog/content/visual-relationship-between-mdamdd-and-mde
).
Do you agree? Is that simple?
Also, it is not so clear to me where to relate model-based engineering
with the previuos three concepts. I'm inclined to think that MBE is a
lighter version of MDE (MBE would be a process where models are used
even if they do not "drive" the development)
Jordi
--
Software modeling languages portal: http://modeling-languages.com
Software modeling blog: http://modeling-languages.com/blog
Personal Home page: http://jordicabot.com
H. S. Lahman
> What is the relationship between the model-driven initiatives: MDE,MDA
> and MDD?
>
MDE is as pretty nebulous. It is primarily focused on the /processes
/used to develop software, rather than on design and implementation of
specific applications. IOW, it is Software Engineering applied to a
development environment where the design techniques and supporting tools
are based on using models. So it deals with things like version control,
review processes, defect prevention, and whatnot that need to be
tailored around model-driven design.
For example, adopting translation (full code generation from OOA models)
is a major sea change for an organization because everything from
configuration management to testing is affected. The changes to the
organization's basic development processes would come under MDE.
Alas, MDD is also pretty vague and depends on who you talk to. (Some
people have the second D as Design while others have it as Development.)
I originally learned it as an umbrella for any software construction
approach where design was done using modeling techniques (i.e., the
second D is Design). IOW, it was on the opposite end of the development
spectrum from the OOP-based Agile processes like XP and Scrum. In any
event MDD differs from MDE in that it deals with the way software design
itself is done for specific applications. Thus is it more methodological
and is manifested in the various OOA/D books.
I think the usage of MDD, though, is ambiguous since some authors seem
to include a lot of process issues (i.e., the authors where the second D
is Development). FWIW, I think the distinction between development
process (MDE) and design methodology (MDD) is a useful one to preserve.
And it has an aesthetic appeal since there is a nice symmetry.
However, recently it seems to have been co-opted by the DSL people to
mean just design using graphical DSLs. IOW, they view MDD as designing
software using a graphical DSL.
MDA is a quite separate thing. MDA provides a semantic standard for
modeling notations that allows one to unambiguously migrate from one
model representation to another. Thus under MDA one views requirements
specifications, OOA models, OOD models, and OOPL programs as all being
models of the final, concrete executable. (MDA is more general than OO
development, though.) What MDA provides is a semantic infrastructure
that allows one to move information from one model to another in a
rigorous fashion when the models represent the same thing. IOW, MDA
allows one to transform one model representation into another. Thus we
can have something like
req meta <----> OOA meta <----> OOD meta <-----> OOPL meta
model model model model
| | | |
| | | |
V V V V
SRS <------> OOA model <-----> OOD model <-----> 3GL program
CIM PIM PSM PSM
MDA introduces meta models to capture notation semantics rigorously for
each model representation. (For OOA and OOD models, one uses largely
overlapping subsets of UML for both, which makes things a lot easier.)
That provides a mapping to particular syntactic elements in the
notation. But since the meta models are rigorously defined, that allows
syntactic elements in one notation to be unambiguously mapped into
syntactic elements of different notations through their meta models --
essentially allowing at least some degree of cross-compilation between
models.
MDA is of primary interest to tool vendors. Thus round trip tools depend
on MDA to standardize migration back and forth between UML models and
OOPL code. Similarly, MDA has standardized the way that full code
generators work for translation tools that create executables directly
from OOA models. For example, XMI's adoption under MDA has greatly
facilitated seamless integration of drawing tools with things like coed
generators and documentation tools.
MDA provides a lot of other semantic infrastructure for such migration,
such as the notion of Marking Models and Transformation models that
formalize the mappings between different meta models. MDA has also
indirectly formalized the notion of 4GLs and 5GLs based on computing
space dependence. Thus requirements models are Computation-Independent
Models and OOA models are Platform-Independent Models, while OOD models
and 3GL programs are Platform-Specific Models. Thus an OOA model (PIM in
MDA terms) is a true 4GL when UML is combined with an abstract action
language for specifying methods. Similarly, a rigorous SRS (CIM) becomes
a 5GL because it depends solely on the problem domain and is completely
independent of computation. (IOW, the PIMs are still dependent on things
like set and graph theory that map specifically into computation
solutions but they are independent of particular computing environments.)
So MDA is really pretty orthogonal to both MDE and MDD.
> Also, it is not so clear to me where to relate model-based engineering
> with the previuos three concepts. I'm inclined to think that MBE is a
> lighter version of MDE (MBE would be a process where models are used
> even if they do not "drive" the development)
>
Possibly. But if one buys into the process orientation, I don't think
there is much value in that distinction. Engineering processes need to
be rigorous, unambiguous, and repeatable. So either you use models to
design and have an infrastructure to support using them or you don't.
IOW, if a shop /sometimes /uses models, then their process is probably
closer to alchemy than engineering.
--
Life is the only flaw in an otherwise perfect nonexistence
-- Schopenhauer
H. S. Lahman
H.la...@verizon.net
software blog: http://pathfinderpeople.blogs.com/hslahman/index.html