domain-specific modeling, model-driven · pdf file dsm: domain-specific modeling captures...

1

14 February 2010

Juha-Pekka Tolvanen

Domain-Specific Modeling, Model-Driven Architecture

© 2010MetaCase 2

Outline

� Why Model-Driven Development?

� What is Domain-Specific Modeling?

� What is Model Driven Architecture?

� Examples and experiences from the industry

� How to define own languages and generators

� Q&A

© 2010MetaCase 3

Why modeling?

� Complex

– overwhelming amount of detail

– many levels of change

– different views

� Uncertain

– why to change

– what to change

– how to change?

� Contextual and contingent

– past history

– development group

– domain

– technology

© 2010MetaCase 4

Modeling procedures

� Requirements – effectivity (effectiveness) – efficiency – completeness – consistency – accuracy

– well-defined products – determinism – relevance – formalisability – communicable – reducing complexity – stepwise – integrated

© 2010MetaCase 5

How productivity has improved?

� "The entire history of software engineering is that of the rise in levels of abstraction"

� Newer programming languages have not increased productivity

� UML and visualization of code have not increased productivity

� Abstraction of development can

be still raised when move from solution domain to problem domain

– Inside one company, product family, business area etc.

© 2010MetaCase 6

How do we use models?

� Model alone should be sufficient in most cases

– No need to look at code

Code

Model

DSM/DSL

Finished product

Code visualization

Code

'Model'

Finished product

Roundtrip

Code

'Model'

Finished product

Separate model &

code

Code

Model

Finished product

MDA®

Code

Model

Finished product

Model 2Model n

CASE

Code

Finished product

Model

?

?

© 2010MetaCase 7

Reverse engineering?

1011 0011 ...

MOV CX, AX ...

CRichText& mtmBody = iMtm->Body(); ...

?

?

?

1011 0011

© 2010MetaCase 8

Types of models

� State models � Data models � Process models � Object models � Interaction models � Flow models � Use Case models � Collaboration models � Component models � Deployment models � etc.

© 2010MetaCase 9

Use Case models

© 2010MetaCase 10

Data models

© 2010MetaCase 11

Object models

© 2010MetaCase 12

Data flow models

© 2010MetaCase 13

Process models

© 2010MetaCase 14

BPMN

© 2010MetaCase 15

State models

© 2010MetaCase 16

Domain Idea

Finished Product

S o lv e p ro b le m i n d o m a in t e rm

s

Assembler Map to code, implement

UML Model Map to UML

Generate, Add bodies

Domain Framework

Domain Model

Generates codeNo need

to map!

Code Map to code, implement

Modeling domain vs. modeling code

CIM

PIM

PSM

© 2010MetaCase 17

Pedagogical example: Let’s design a mobile app for event registration ...

© 2010MetaCase 18

How would you design and implement the application?

� Prototyping (to finalize or throw away)?

� Start with making test cases (Test-Driven Dev)?

� Make design models and then implement?

� Model and generate (all) code?

� ...or something else?

– Agile modeling, Feature Driven Development, eXtreme Proramming, Domain-Driven Design...?

� The selection of the suitable approach depends on a number of contingencies!

– There is no single best approach…

– …but several good principles: DRY, KISS, avoid copying, low coupling & high cohesion, modularization

© 2010MetaCase 19

Traditional way: some modeling and then coding

� Step1: User view

© 2010MetaCase 20

Development with UML...

� Step2: Describe static structure

Can we apply here generators to

produce the code?

© 2010MetaCase 21

Visualizing code

� Modeling anti-pattern from code generation point of view: 1 symbol => 1 keyword

public class Alarm extends Thread {

String name; boolean localTimeAwareness; String alarmState; int sleeptime; static final int dayMs; Master master; AbstractWatchApplication alarmApplication; volatile boolean isLive=false;

public Alarm(String alarmName, boolean aware, public void run() public void stopAlarm()

}

© 2010MetaCase 22

Development with UML...

� Step3: Specify interaction

© 2010MetaCase 23

Development with UML...

� Step 4: Logic

+ user navigation

+ behavior

+ exceptions

+ etc.

+ In steps 5...N

Can we apply here model-to-model transformation?

© 2010MetaCase 24

Development with UML+code

� And finally we start coding! – Implement the functions, access to APIs, remember the

exceptions, architectural rules, UI guidelines etc.

– ... and throw models away as they are not anymore in sync

...

void CGDSMSAppUi::CmdSendL() // Show notification { iEikonEnv->InfoWinL(_L("Confirmation"),_

L("SMS is in draft folder")); SendMessageL();

}

TBool CGDSMSAppUi::SendMessageL() // Sending SMS Message { TMsvEntry msvEntry = iMtm->Entry().Entry();

CRichText& mtmBody = iMtm->Body(); mtmBody.Reset(); mtmBody.InsertL(0, smsNum(16400)); SetScheduledSendingStateL(msvEntry);

} ...

TMsvEntry msvEntry = entry->Entry();

// first we create a new mtm to handle this message (in case our own mtm is in use) CBaseMtm* smsMtm = iMtmReg->NewMtmL(msvEntry.iMtm); smsMtm->SwitchCurrentEntryL(aEntryId);

smsMtm->LoadMessageL(); // load the message

if (smsMtm->Body().Read(0,4).Compare(KGDSMSTag)==0) // message is targeted to us { // Now we process the message iEikonEnv->InfoMsg(smsMtm->Body().Read(0,4)); // this will flash our message text in the upper right corner of the

screen

returnVal = ETrue;

/* As a change to the previous version of GDSMS, the message will not be deleted right after reading it. Instead all messages that have been read by this app will be deleted from the Inbox when this app is closed. See DeleteMessagesFromInboxL().

*/ }

// release allocated memory delete smsMtm;

CleanupStack::Pop(); // entry delete entry;

return returnVal; }

/* -----------------------------------------------------------------------------

CGDSMSAppUi::DeleteMessagesFromInboxL()

This method reads the Inbox and deletes all GDSM messages that are invisible.

----------------------------------------------------------------------------- */ void CGDSMSAppUi::DeleteMessagesFromInboxL()

{ // information to the user iEikonEnv->InfoMsg(_L("Deleting messages from Inbox."));

// then delete message from inbox, first take a handle to Inbox... TMsvSelectionOrdering sort;

sort.SetShowInvisibleEntries(ETrue); // we want to handle also the invisible entries // Take a handle to the Inbox entry

CMsvEntry* parentEntry = CMsvEntry::NewL(*iSession, KMsvGlobalInBoxIndexEntryId, sort); CleanupStack::PushL(parentEntry);

CMsvEntrySelection* entries = parentEntry->ChildrenL(); // A selection of all the entries of the Inbox CleanupStack::PushL(entries);

C+ +

© 2010MetaCase 25

Domain-Specific Modeling solution

© 2010MetaCase 26

after running the generator...

© 2010MetaCase 27

DSM: Domain-Specific Modeling

� Captures domain knowledge (as opposed to code)

– Raise abstraction from implementation world

– Uses domain abstractions

– Applies domain concepts and rules as modeling constructs

– Narrow down the design space

– Focus on single range of products

� Uses generators to produce the code

– Generator is Domain-Specific

– Generate just the code needed from models • Efficient full code

• No manual coding afterwards

• No reason for round-tripping

– Generator links to existing primitives/components/platform services etc.

© 2010MetaCase 28

MDA: Model Driven Architecture

� Hard to pin down: all things to all men

� Strong lock-in to OMG (standards: XMI, OCL, QVT ...)

– Initially "you must use UML"

– But later, in MDA manifesto, Booch et al. say: "The full value of MDA is only achieved when the modelling concepts map directly to domain concepts rather than computer technology concepts"

– Now: "you can have any language you like, as long as it's like UML" – only allowed to build languages with MOF

� Schism into two schools of thought:

– Elaborationist (OMG): Model a bit, transform, edit transformed models, generate, edit generated code • Compu