Model Driven Architecture
Model Driven ArchitectureSomething being touted by the ObjectManagementGroup - see: http://www.omg.org/mda/.
According to the OMG:
MDA provides an open, vendor-neutral approach to the challenge of interoperability, building upon and leveraging the value of OMG's established modeling standards: Unified Modeling Language (UML); Meta-Object Facility (MOF); and Common Warehouse Meta-model (CWM).
Anyone know anything about this? Is it:
I suggest reading this : http://www.jot.fm/issues/issue_2003_01/column1 -- PhilJones (and maybe this : http://www-106.ibm.com/developerworks/rational/library/3100.html)
Interpretation and clarifications from major technology vendors
from Microsoft
Middleware Interoperability challenges
from ???
My bet is on the second. What I know is that in thousands of pages of specs, they've not been able to construct a proper, consistent, well-defined and relevant model. MDA? That sounds cool, but excuse me, where's the model? -- CostinCozianu
Don't understand the last question. The model is what you design in your UML tool ... Did I miss a point?? --DirkDetering
UML is thousands pages of specs turned into colorful charts. Consistency is not checked, no formal reasoning occurs (at least without extra tools), so it doesn't feel like modeling. From DesigningVsModeling: A good model makes correct assertions.-- DexenDeVries
Any so-called "standard" that goes over a certain threshold with regards to number of pages, should be regarded as suspicious to begin with. The perfect example of elegant and useful standard is the RevisedReportOnAlgorithmicLanguageScheme). Compared to it, OMG standards look like an abomination.
The basic idea is that your architect will build some kind of completely abstract UML model describing your problem and it's solution. Then your tools will automagically convert this into any and all distributed systems (from .Net to J2EE to Corba). Or at the very least generate stubs that you can fill in with your business logic. It's meant to simplify life by removing all the platform dependent parts from your model and increasing the amount of benefit you can get from code-generation. I'm less than convinced.--AdewaleOshineye
I bought the book. IMO, it's JustAnotherProgrammingLanguage.
The last paragraph is slightly too simplifying in my mind. MDA is not directly related to distributed systems nor to generation of stubs. This is only the current practice because the producers of code generators saw their chance to jump on this train (hum, german metapher?) and the OMG is willing to put the MDA-logo on every product which more or less fits into the concept (just a marketing strategy). And as the need to describe a software system in abstract models and to generate big bunches of code is normally met in bigger enterprise oriented products, you will meet the requirement to generate a distributed system automatically. So if a tool vendor wants to sell a product, he will say "MDA-conform" and will explain that by using examples commonly known by his clients. That is today: "We generate EJB or CORBA".
The basic principle behind MDA is to abstract your model from the platform to describe a general solution for your domain problems, independently from the concrete way to implement it in a specific platform. This is: you model an Entity class as an abstract description of a Domain Model or Business Model entity. Transforming this semantic to a specific platform (e.g. EJB) then can lead to a set of Classes building that entity (e.g. an EntityBean). But, well, the semantic stays the same.
What the tools have to do is transform a more abstract model to a more specific model by adding/changing specific information derived from annotations in the more abstract model. Currently this is interpreted as doing "code generation", as, indeed, code is only another form of a model beside a UML repository. But conceptionally they should convert one UML model into another UML model (i.e.: a class stereotyped as <<Entity>> in the abstract model should be shown as classes stereotyped <<EJBEntityHomeInterface>> <<EJBRemoteInterface>> and <<EJBImplementation>> in an EJB specific model (not code!)).
Is this just a re-invention/re-marketing of the translation approach of ShlaerMellor??
One phrase that really clarified the intent behind this for me is "ReusableDomainModels?". The idea being that all our applications in a particular domain should use one and only domain model rather than having to re-create that model for every application.
Hmm, what is the scope of "our" in this case? A whole industry? A whole company? A whole division of a company? Department, team?
This may initially be a limitation due to the immaturity of the tools, but I'm concerned about the potential for increased ArchitectsPlayGolf. If an architect defines a model in an MDA tool and the Platform Independent Model is converted to a Platform Specific Model, how happy are they going to be when I bring it back to them saying I've added some classes here, refactored some complexity here, etc. I'm trying to keep an open mind on the basis that I might have some aha! insight, but it isn't happening at the moment. --JamesAbley
ArchitectsPlayGolf ?? Well, seems to be a very theoretical view to the problem. In practice it aren't the architects which create models and all other people (except the dumb business-rule-coder) are superfluous. In practice the architects create solutions for general problems (how do we implement security? how does our batcher meet the requirements? how ...). The business in fact is analysed by OO-Analysts which create an analysis model. The designer now creates design models using a given UML-Profile (yes indeed, JustAnotherProgrammingLanguage), more detailed and annotated than the OOA, for further transformation. That transformation is done by generators. So the architect keeps making general concepts, the programmer (now called designer) keeps making concrete solutions, but now by using a much more abstract language than before ...
What it really looks like today: A modern form of generative programming, a more abstract language, fast development in some way, immediate graphical documentation of the application, and a new buzzword.
In practice it is a boon and a bane at the same time, especially when looking at the abilities of actual tools (and the impossibility to change them during project time, when seeing that the competitor of your current tool provider just implemented some necessary features in the meantime) or the experience of actual developers.
It has a great potential indeed, especially when we as developers not only take the user role but become creative of what additional tools or features or process changes we would need to make it really work.
It is really exciting to form this approach during daily practice, design the processes, create the design language and generator tools, write a suitable framework for that a.s.o. But it can become a pain to be dependent on others doing this, while trying to realise the requirements of the customers (and sometimes have the imagination that things would be faster when directly writing the code instead of the models first ...) .
Indeed there *is* actually the new task in a project to create and maintain a Design Language and UML-Profiles, to define how the models have to be transformed to code.
And that's it: Instead of simply using a language and compiler and focus on the business, a software house applying MDA today has the task to maintain its own project specific language and "compiler" too. Standardisation and Proprietary at the same time, now in a new form.
(Well: Companies like SAP, Baan a.s.o. have proprietary programming languages. But imagine companies like them, saying: We are conform to the standard as we all use curly braces) --DirkDetering
EditText of this page
(last edited March 9, 2011)
or FindPage with title or text search