2. Model Driven Architecture
► Conceived and sponsored by the OMG
► It's about a IT discipline to use models to automate the
construction of applications (freely rephrased from the MDA
User Guide)
► Yes, but what is a model?
► Definition: “a simplified
representation of a system
or phenomenon,”
MDA/EA Forum 2009
3. The Code is a Model
► It represents high level logical structure
► “Repeat until” or “JNE x00ef, x003F” ?
► It hides irrelevant details
► Which processors is there beneath?
► Code has always about abstraction:
► Machine code -> Assembly -> 3GL -> OO -> Java ->
WSDL->UML->RuleML->XBRL.. and still proceeding
MDA/EA Forum 2009
4. A Model is a Code
► Services can be represented by a model
► WSDL, language classes..
► Applications can be represented by models
► UI, services, components, data model, object model,
deployment...
► A Model can be run now
► Action semantics, BPMN, OCL
► OCL is code .. or is it a model?
► There are many commercial tools outside there (and
here too) which this capability
► Models can be checked and transformed … as code
► Models can be tested and debugged … as code
MDA/EA Forum 2009
5. Models in Electronics
► Models in electronics
► Testable before built
► Decoupled from electronic
components
► Store the solution as an asset
• Assets beyond technology
► The value or repeatable tasks
► Reusable across different
technologies
► Scale across technology generations
Nathalie Moreno and Antonio VallecilloUniversidad
de Málaga
MDA/EA Forum 2009
7. Code vs Model
[omissis]
try{
if (System.getSecurityManager() == null) {
System.setSecurityManager(new RMISecurityManager());
sd Class Model
}
} catch {/*tech Error handling*/} ReqT ype:M yRequester S ervice:PowerService
try {
PowerService service = (PowerService) Naming.lookup("rmi://" + serverIp+ "/PowerService");
} catch {/*tech Error handling*/}
doSom ething(context, 123)
try {
System.transactionMon(IN, context);
context=service.doSomething(contex, 123);
System.transactionMon(OUT, context);
} catch {/* tech and behavioral error handling*/}
[omissis]
MDA/EA Forum 2009
8. Demystifying modelling approach
► Models do not execute ► No MDA projects are in
► False, many solutions exists productions
► Models generate slow code
► False: there are many, check
the OMG web page, ask here
► False: depends only on quality
around
of the transformations
► No MDA development tools are
► It's a heavy weight approach
available:
► False, it depends on the ► False: check OMG web page
development process: adopt
or ask here around
shorter cycles
► MDA is only for embedded
► False: ”Divide et impera”
systems:
vertically (functional
components), horizontally
► False: check the OMG web
(tiers), cross cutting concerns site for success stories
► The generated code is messy and ► UML is very large:
hard to be read ► True: but there is no need to
► Meaningless: there is no use all of it's semantics. There
need to look at the code are other languages Forum 2009
MDA/EA
9. Why this general scepticism?
► It due to the mindset of IT software practitioners, it's a matter of:
► Different Viewpoint on the development
► Different Habits
► Late Maturity
► No Confidentiality
► Not enough Experience
► Q: "If I do not see a code I feel uncomfortable"
► A: “Have you ever seen the ASM generated by the C++
compiler? No, right? But you still feel comfortable, and you don't
debate the quality of the generated code, how comes?
► There shall be no difference if the generated application has not
introduced any bug and it's adequately fast
MDA/EA Forum 2009
10.
11.
12. Agility
► Adjective: “quick and well-coordinated in movement”
► Quick: be light, do not have unnecessary load
► Well-coordinated: well connected and in-sync
► [..close collaboration between the programmer team and
business experts; face-to-face communication (as more
efficient than written documentation); frequent delivery
of new deployable business value..]
► Quick, assumes the iteration process to be short and lite
► Coordinated: assumes parts are well connected and in
sync
► How to be agile depends on local capabilities and skills,
it's a relative term
MDA/EA Forum 2009
13. Agility in Modelling
► Focus on capturing and fulfilling the functional specifications
as a runnable application
► In MDA, technicalities can be tuned afterwards
► Do not search for the optimal technical architecture right
from the beginning, accept compromises "the optimum is the
killer of good"
► Short deployment cycles
► Feedbacks have be incorporated back into models quickly
► Three weeks for an iteration
► New requirement are welcome, but trace them
► Avoid round-trip code<->model, it jeopardizes the agility
► Go for a consistent and integrated MDA tool, avoid spaghetti
frameworks
MDA/EA Forum 2009
14. What to keep in mind
► Model life cycle management
► Models has to drive the development
►From requirement to execution in a traced continuum
► What can be done with code has to be, and CAN be done with
models as well
► Debugging
► Testing
► Validation
► Execution
► Versioning
►Deployment
► Models are your assets
► Take good care of them
► There is a price to pay... MDA/EA Forum 2009
15.
16.
17.
18. Hurdles
► DO NOT UNDERSTIMATE THE IMPORTANCE OF A
SOUND FUNCTIONAL MODEL
► If a model is a code ...
► ...be careful in defining your functional reference
model, you could soon fall under a messy functional
model: aka “Spaghetti Model”
► 100% models interoperability across MDA tools is yet to
be a "default"
► An old story: as for C++ compilers
► Re-think the organization of the software re-factory:
► People, Processes, Tools
► Bootstrapping the software factory...
MDA/EA Forum 2009
