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

Click here to load reader

Post on 10-Mar-2020




0 download

Embed Size (px)


  • 1

    14 February 2010

    Juha-Pekka Tolvanen

    Domain-Specific Modeling, Model-Driven Architecture

    © 2010MetaCase 2


    � 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




    Finished product

    Code visualization



    Finished product




    Finished product

    Separate model &




    Finished product




    Finished product

    Model 2Model n



    Finished product




  • © 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


  • © 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


    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




  • © 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


    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; }

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


    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

View more