The document discusses Model Driven Architecture (MDA), which uses models to automate application construction. It defines a model as a simplified representation of a system or phenomenon. Code is considered a type of model that represents logical structure and hides implementation details through different levels of abstraction. Models can represent applications, services, and be executed in the same way code can through tools that support capabilities like model checking, transformation, testing, and debugging. Successful adoption of MDA depends on factors like development process, tool integration, and model lifecycle management.

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

6. Code vs Model, state machine
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

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

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