Agile Modelling Architecture

MDA/EA Forum 2009MDA/EA Forum 2009

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,”


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


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


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


Code vs Model, state machine


Code vs Model

[omissis]

try{

if (System.getSecurityManager() == null) {

System.setSecurityManager(new RMISecurityManager());

}

} catch {/*tech Error handling*/}

try {

PowerService service = (PowerService) Naming.lookup("rmi://" + serverIp+ "/PowerService");

} catch {/*tech Error handling*/}

try {

System.transactionMon(IN, context);

context=service.doSomething(contex, 123);

System.transactionMon(OUT, context);

} catch {/* tech and behavioral error handling*/}

[omissis]

sd Class Model

Service:PowerServiceReqT ype:M yRequester

doSom eth ing(context, 123)


Demystifying modelling approach► Models do not execute

► False, many solutions exists► Models generate slow code

► False: depends only on quality of the transformations

► It's a heavy weight approach► False, it depends on the

development process: adopt shorter cycles

► False: ”Divide et impera” vertically (functional components), horizontally (tiers), cross cutting concerns

► The generated code is messy and hard to be read► Meaningless: there is no

need to look at the code

► No MDA projects are in productions► False: there are many, check

the OMG web page, ask here around

► No MDA development tools are available:► False: check OMG web page

or ask here around► MDA is only for embedded

systems:► False: check the OMG web

site for success stories► UML is very large:

► True: but there is no need to use all of it's semantics. There are other languages


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


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


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


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...


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...

Documents

Agile Modelling Architecture