Stefan Siegl wrote:
Hello group,
My question is about the Metafacades. I read the documentation (at
http://andromda.org/andromda-metafacades/) and hope I understood it
correctly. It would be really nice if you could have a look here and tell me
if I got it right.
1. The given model is read by AndroMDA
2. The model is inserted into a MOF repository (default is MDR). Depending
on the format of the modelling language the information of the given model
is stored in a specific MOF module (the metamodel). If AndroMDA receives a
model based on UML 1.4, the information would be contained in the MOF
package "UML1.4".
3. The access to the information provided by MOF is done using the JMI
(MOF -> Java) mapping (this is then the object-oriented representation of
the metamodel).
4. Now the templates can use the metamodel to access the information
5. If additional information (e.g. helper methods) are needed, it would be
cumbersome (and redundant) to add them within the template code. That's why
the idea came up to add these methods to the metamodel and thus allow the
templates to use them as if they would be part of the model they read.
6. As the metamodel classes cannot be extended (due to the problem that MDR
creates the metamodel at runtime), facades are introduced hiding the used
metamodel and allow adding methods. The templates will refer to the facade
when querying for information of the model and thus additional functionality
can be added to the facades without the need to change/extend the "real"
metamodel.
7. As the metafacades also abstract the metamodel, a change to another
metamodel is not a problem as only the delegation would be changed within
the facade (e.g. UML 1.4 -> UML 2.0 - the facade would then point to the
metamodel of UML 2.0).
A thing I did not understand was how the "UML common metafacade" and the UML
metafacades (shown on the third picture at
http://andromda.org/andromda-metafacades/) come into play. Somehow the UML
common seems to abstract UML in general and abstract the specifics of each
UML release from user-defined metafacades. Does that also mean that we
always use the UML common metafacade if no other (self-defined) metafacade
is specified? So a metafacade of a cardridge would then be able to define
"cartridge-specific" helper methods without having to "pollute" the "core
metafacade" with helper functionality, right?
Not sure I quite understand the question, however cartridge metafacades
extend the base UML metafacades to provide any cartridge specific
functionaliy. Was that what you were asking?
Thanks a lot for your time and effort helping me out :)
Stefan
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Andromda-user mailing list
Andromda-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/andromda-user
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Andromda-user mailing list
Andromda-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/andromda-user
