Executable and Translatable UML. Stephen J. Mellor Marc J. Balcer

Executable and Translatable UML Stephen J. Mellor Marc J. Balcer

Contents What s the problem? UML Models Executable UML elements Executable UML behavior The Repository Model Compiler Concepts How model compilers work MDA 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 2

What s the Problem? Analysts create high-level application models print them out then the developers look at the models and write the production code These models are independent of the implementation technology Coding adds this design detail 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 3

What s the Problem? But once something is in a machine representation we shouldn t have to manually reinterpret it ( elaborate it ) into another. The analyst s diagrams don t have to be complete, correct, or consistent models Keeping the diagrams in sync with the code is a daunting task. The rework introduces development errors and obscures analyst errors 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 4

What s the Problem? But once something is in a machine representation Because elaboration is stupid! we shouldn t have to manually reinterpret it ( elaborate it ) into another. The Ant appears courtesy of Leon Starr, Executable UML 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 5

Executable Models Analysts create executable models test those executable models and compile the models to produce a running system Developers buy, build, or adapt a model compiler for a software architecture map model elements to the architecture 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 6

Executable Models The analyst s models must be complete, correct, and consistent and the models are verifiable. The process always moves forward there s no editing of the translated code, no round-tripping, no reverse-engineering, no getting out of sync. The software deign decisions are formalized in the mappings and translation archetypes 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 7

What s UML? The Unified Modeling Language is a language for specifying, constructing, visualizing, and documenting artifacts of a software-intensive system The UML Summary 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 9

What s UML? Common notation for OOA / OOD Goal was to eliminate the notation wars One notation for many purposes Very large Concept of profiles for different uses 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 10

UML in Practice Just because these use the same notation (UML) doesn t mean these are the same problem. The models are more than just the observable behavior to the user The software design does not follow from the model of the problem 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 12

Notation Semantics Open Account Customer name : PersonalName address : MailingAddress phone : TelephoneNumber customerid : CustomerIDNumber : Timer dobilling( ) : BillingGroup billingcomplete( ) billgroup( ) Customer Service Rep Merchant C1 Suspend Account Close Account Submit Charge Issue Credit C2 Collection Agent Timer Billing Clerk Use Case Diagram Call Delinquent Customer Produce Bills for Group Receive Payment is the responsibility of 1 R1 is responsible for 1..* Account number : CardAccountNumber / currentbalance : Money actualcreditlimit : Money Transaction requestedcreditlimit : Money is processed transactiondate : Date interestrate : Percent on accumulates / netamount : Money notes : FreeformText open() 1 R3 0..* approve() suspend() is current presents 0..* reinstate() presentation of R12 close() 1 directs billing of 0..* R2 R5 is billed as part of 1 BillingGroup groupnumber : BillingGroupNumber is currently billingday : BillingDayNumber presented to appears on 1 customer as 0..1 dobilling() Statement billingcomplete() / statementdate : Date is an actual billing of 1 minimumamountdue : Money paymentduedate : Date R4 is actually billed as preparestatement() 0..* applypayment() BillingRun duedatereached() billingdate : Date nopaymentdue() billgroup() allbillsproduced() Class Diagram : Billing Clerk duedatereached( ) applypayment( ) receivepayment( ) : BillingRun : Statement : Payment preparestatement( ) suspend( ) reinstate( ) : Account Collaboration Diagram C3 Open Account preparestatement( statementdate ) Statement Prepared : Billing Clerk : Timer : Payment : Statement Component Diagram HQ Branch Pay Bill Close Account applypayment( transaction ) nopaymentdue duedatereached Paid On Time Payment Past Due applypayment( transaction ) Paid Late No Payment Due receivepayment( ) duedatereached( ) applypayment( ) ignored Remote Branch Activity Diagram State Diagram Sequence Diagram Deployment Diagram Each diagram is well-defined, but how do they fit together? 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 13

UML Profiles Customer name : PersonalName address : MailingAddress phone : TelephoneNumber customerid : CustomerIDNumber is the responsibility of 1 R1 is responsible for 1..* Account number : CardAccountNumber / currentbalance : Money actualcreditlimit : Money requestedcreditlimit : Money interestrate : Percent open() approve() suspend() reinstate() close() directs billing of 0..* R2 is billed as part of 1 BillingGroup groupnumber : BillingGroupNumber billingday : BillingDayNumber dobilling() billingcomplete() is an actual billing of 1 R4 is actually billed as 0..* BillingRun billingdate : Date is processed Transaction on accumulates transactiondate : Date / netamount : Money 1 R3 0..* notes : FreeformText is current presents 0..* presentation of R12 1 R5 is currently presented to appears on 1 customer as 0..1 Statement / statementdate : Date minimumamountdue : Money paymentduedate : Date preparestatement() applypayment() duedatereached() nopaymentdue() A profile defines how these diagrams represent models billgroup() allbillsproduced() Information Model (things in the problem and how they are related) preparestatement( statementdate ) Statement Prepared applypayment( transaction ) nopaymentdue duedatereached Paid On Time Payment Past Due applypayment( transaction ) Paid Late No Payment Due State Model (lifecycle of an instance of a class) 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 16

UML Profiles Customer name : PersonalName address : MailingAddress phone : TelephoneNumber customerid : CustomerIDNumber is the responsibility of 1 R1 is responsible for 1..* Account number : CardAccountNumber / currentbalance : Money actualcreditlimit : Money requestedcreditlimit : Money interestrate : Percent open() approve() suspend() reinstate() close() directs billing of 0..* R2 is billed as part of 1 BillingGroup groupnumber : BillingGroupNumber billingday : BillingDayNumber dobilling() billingcomplete() is an actual billing of 1 R4 is actually billed as 0..* BillingRun billingdate : Date billgroup() allbillsproduced() is processed Transaction on accumulates transactiondate : Date / netamount : Money 1 R3 0..* notes : FreeformText 1 is current presentation of presents 0..* R5 is currently presented to appears on 1 customer as 0..1 Statement / statementdate : Date minimumamountdue : Money paymentduedate : Date preparestatement() applypayment() duedatereached() nopaymentdue() Information Model (things in the problem and how they are related) R12 It also defines a set of diagrams that are derived from the basic models preparestatement( statementdate ) Statement Prepared : Timer : Billing Clerk dobilling( ) billingcomplete( ) duedatereached( ) applypayment( ) receivepayment( ) : BillingGroup : BillingRun : Statement : Payment billgroup( ) preparestatement( ) suspend( ) reinstate( ) : Account Object Communication Model (summary of object interactions) applypayment( transaction ) nopaymentdue duedatereached Paid On Time Payment Past Due applypayment( transaction ) Paid Late No Payment Due : Billing Clerk : Timer receivepayment( ) : Payment : Statement applypayment( ) duedatereached( ) ignored State Model (lifecycle of an instance of a class) Execution Trace (system behavior under one scenario) 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 17

Classes Customer name : PersonalName address : MailingAddress phone : TelephoneNumber customerid : CustomerIDNumber is the responsibility of 1 R1 is responsible for 1..* Account number : CardAccountNumber / currentbalance : Money actualcreditlimit : Money requestedcreditlimit : Money interestrate : Percent open() approve() suspend() reinstate() close() directs billing of 0..* R2 is billed as part of 1 BillingGroup groupnumber : BillingGroupNumber billingday : BillingDayNumber dobilling() billingcomplete() is an actual billing of 1 R4 is actually billed as 0..* BillingRun billingdate : Date is processed Transaction on accumulates transactiondate : Date / netamount : Money 1 R3 0..* notes : FreeformText is current presentation of 1 R12 is currently presented to customer as 0..1 appears on 1 Statement / statementdate : Date minimumamountdue : Money paymentduedate : Date preparestatement() applypayment() duedatereached() nopaymentdue() Class abstraction of common characteristics and common behavior presents 0..* R5 Attribute abstraction of a single characteristic of a class derived attribute Association abstraction of a relationship between classes billgroup() allbillsproduced() Event received by the object s state machine association class 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 18

Lifecycles Statement initial pseudostate preparestatement( statementdate ) Statement Prepared applypayment( transaction ) nopaymentdue duedatereached State a stage in the lifecycle Paid On Time Payment Past Due applypayment( transaction ) Paid Late No Payment Due Event abstraction of a single signal received by the state machine Transition abstraction of a progression from state to state 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 19

State Procedure & Actions Each state has a procedure executed upon entry to the state preparestatement( statementdate ) Statement Prepared Statement Prepared applypayment( transaction ) nopaymentdue duedatereached? Paid On Time Payment Past Due No Payment Due applypayment( transaction ) Paid Late Actions specify what happens in the state procedure 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 20

Expressing Actions Statement Prepared? Need to express the semantics of the problem domain - in pseudocode - in Java itself? - in a Java-esque syntax? - in a flowchart? - in a dataflow diagram? - in pipes-and-filters? 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 21

Why not pseudocode? in the world or belonging to this customer? Statement Prepared how do we know? entry/ for each transaction not yet billed post that transaction to the statement what does post mean? the statement You talkin to me? You wanna post that transaction to me? 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 22

Why not 3GL code? Statement Prepared entry/ query = SELECT * FROM TBL_TRANS, set rst=currentdb().open(query) while not rst.eof rst.edit rst( R5StatementPtr ) = statementid rst.update rst.movenext wend rst.close (Microsoft Visual Basic sort of) Binds the model to a particular implementation Requires other non-application decisions to be made at the same time 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 23

What to do about actions? Statement Prepared? Pseudocode is not executable 3GLs bind model to a particular architecture We want to write - from a problem perspective - in terms of the model - not presuming a specific implementation 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 24

What about actions? Statement Prepared? UML (pre 1.5) did not have a formalism for actions Precise Action Semantics specification supplements the UML - functional/dataflowbased - established the executable profile - essential for executability 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 25

UML Action Semantics Precise Action Semantics for UML Integrated into UML 1.5 Fundamental actions on UML elements (classes, associations, ) Foundations for writing processing in an executable model - in the problem domain - does not presume an implementation 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 26

Semantics, not Language Language A Language B Language C Uniform Action Semantics Why not just design an action language? - Highly political - Many vendors had some proprietary (but not fully compliant) action languages. - Syntax issues would obscure semantic issues First define a uniform semantics 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 27

Action Languages TALL foreach transaction in self->account->transaction[not.isbilled] self->transaction := transaction; endfor; OAL foreach transaction related by self->account[r12]->transaction[r3] where not selected.isbilled relate transaction to self across R5; end for; Several different tool-specific languages First step is to make all action-semantics compliant Syntax is secondary 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 28

Actions Specify the logic for each state s action. Statement Prepared Statement Prepared entry/ foreach transaction related by self->account[r12]->transaction[r3] where not selected.isbilled relate transaction to self across R5; end for; 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 29

Actions Other Uses Account number : CardAccountNumber {I} / currentbalance : Money actualcreditlimit : Money requestedcreditlimit : Money interestrate : Percent currentbalance = 0; foreach transaction related by self->transaction[r3] currentbalance = currentbalance + transaction.netamount; end for; Derived Attribute open() approve() suspend() reinstate() close() select many accounts from instances of Account where selected.number == self.number; return ((cardinality accounts) == 1); Constraint 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 30

An Executable Model Customer name : PersonalName address : MailingAddress phone : TelephoneNumber customerid : CustomerIDNumber is the responsibility of 1 R1 is responsible for 1..* Account number : CardAccountNumber / currentbalance : Money actualcreditlimit : Money requestedcreditlimit : Money interestrate : Percent open() approve() suspend() reinstate() close() directs billing of 0..* R2 is billed as part of 1 BillingGroup groupnumber : BillingGroupNumber billingday : BillingDayNumber dobilling() billingcomplete() is an actual billing of 1 R4 is actually billed as 0..* BillingRun billingdate : Date billgroup() allbillsproduced() is processed Transaction on accumulates transactiondate : Date / netamount : Money 1 R3 0..* notes : FreeformText is current presentation of 1 Classes R12 presents 0..* R5 is currently presented to appears on 1 customer as 0..1 Statement / statementdate : Date minimumamountdue : Money paymentduedate : Date preparestatement() applypayment() duedatereached() nopaymentdue() Paid On Time preparestatement( statementdate ) Statement Prepared applypayment( transaction ) nopaymentdue duedatereached Payment Past Due applypayment( transaction ) Paid Late No Payment Due Statement Prepared entry/ foreach transaction related by self->account[r12]->transaction[r3] where not selected.isbilled relate transaction to self across R5; end for; Lifecycle of Statement Statement Prepared state procedure 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 31

Table of contents What s the problem? UML models Executable UML elements Executable UML behavior The repository Model compiler concepts How model compilers work MDA 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 32

Instances An executable model operates on instances. Account number : CardAccountNumber / currentbalance : Money actualcreditlimit : Money requestedcreditlimit : Money interestrate : Percent number 231552343 currentbalance 110.23 actualcredit Limit 5000 requestedcredit Limit 5000 interestrate 14% open() approve() suspend() reinstate() close() 897899934 789978994 0.00 3423.32 8000 3500 10000 5000 12% 18% Statement / statementdate : Date minimumamountdue : Money paymentduedate : Date statementdate 5/10/2003 minimumamountdue 10.00 paymentduedate 6/1/2003 preparestatement() applypayment() duedatereached() nopaymentdue() 6/1/2003 6/2/2003 0.00 68.00 6/21/2003 6/21/2003 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 33

Instances An executable model operates on instances. preparestatement( statementdate ) Statement Prepared duedatereached applypayment( transaction ) nopaymentdue Statement / statementdate : Date minimumamountdue : Money paymentduedate : Date preparestatement() applypayment() duedatereached() nopaymentdue() Paid On Time Payment Past Due No Payment Due preparestatement( statementdate ) applypayment( transaction ) Statement Prepared Paid Late statement A Paid On Time duedatereached applypayment( transaction ) nopaymentdue Payment Past Due No Payment Due preparestatement( statementdate ) Statement Prepared statement B applypayment( transaction ) Paid Late Paid On Time duedatereached applypayment( transaction ) nopaymentdue Payment Past Due applypayment( transaction ) Paid Late No Payment Due statement C 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 34

Execution preparestatement( statementdate ) Statement Prepared duedatereached applypayment ( transaction ) nopaymentdue The lifecycle model prescribes execution Paid On Time Payment Past Due No Payment Due applypayment( transaction ) Paid Late When the customer s payment is received, the statement transitions to the next statement and executes actions. preparestatement( statementdate ) Statement Prepared duedatereached applypayment ( transaction ) nopaymentdue Paid On Time Payment Past Due No Payment Due applypayment( transaction ) Paid Late 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 35

Executing the Model The model executes in response to signals from: - the outside, - timers (delayed events) preparestatement( statementdate ) Statement Prepared applypayment( transaction ) nopaymentdue duedatereached - other instances as they execute Paid On Time Payment Past Due applypayment( transaction ) No Payment Due Paid Late 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 36

Concurrent Execution All instances execute concurrently. preparestatement( statementdate ) Statement Prepared duedatereached applypayment( transaction ) nopaymentdue Statement / statementdate : Date minimumamountdue : Money paymentduedate : Date preparestatement() applypayment() duedatereached() nopaymentdue() Paid On Time Payment Past Due No Payment Due preparestatement( statementdate ) applypayment( transaction ) Statement Prepared Paid Late statement A Paid On Time duedatereached applypayment( transaction ) nopaymentdue Payment Past Due No Payment Due preparestatement( statementdate ) Statement Prepared statement B applypayment( transaction ) Paid Late Paid On Time duedatereached applypayment( transaction ) nopaymentdue Payment Past Due applypayment( transaction ) Paid Late No Payment Due statement C 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 37

Communication preparestatement( statementdate ) receivepayment( accountnumber, date, amount ) Statement Prepared Received duedatereached applypayment( transaction ) nopaymentdue checkcleared Accepted Paid On Time before Payment Past Due applypayment( transaction ) Paid Late No Payment Due preparestatement( statementdate ) Statement Prepared duedatereached applypayment( transaction ) nopaymentdue Paid On Time Payment Past Due No Payment Due after applypayment( transaction ) Paid Late 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 38

Concurrent Execution Multiple events may be received. preparestatement( statementdate ) receivepayment( accountnumber, date, amount ) Statement Prepared Billing Clerk Received duedatereached applypayment( transaction ) nopaymentdue checkcleared Paid On Time Payment Past Due applypayment( transaction ) No Payment Due Accepted Paid Late 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 39

Concurrent Execution Concurrent events can produce different outcomes : Billing Clerk : Timer : Payment : Statement : Account : Billing Clerk : Timer : Payment : Statement : Account duedatereached( ) suspend( ) receivepayment( ) applypayment( ) duedatereached( ) receivepayment( ) applypayment( ) reinstate( ) ignored Two outcomes if the payment is received as the due date passes 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 40

Model Repository The repository holds the developers models. Customer name : PersonalName address : MailingAddress phone : TelephoneNumber customerid : CustomerIDNumber is the responsibility of 1 R1 is responsible for 1..* Account number : CardAccountNumber / currentbalance : Money actualcreditlimit : Money requestedcreditlimit : Money interestrate : Percent open() approve() suspend() reinstate() close() directs billing of 0..* R2 is billed as part of 1 BillingGroup groupnumber : BillingGroupNumber billingday : BillingDayNumber dobilling() billingcomplete() is an actual billing of 1 R4 is actually billed as 0..* BillingRun billingdate : Date billgroup() allbillsproduced() is processed Transaction on accumulates transactiondate : Date / netamount : Money 1 R3 0..* notes : FreeformText is current presentation of 1 R12 presents 0..* R5 is currently presented to appears on 1 customer as 0..1 Statement / statementdate : Date minimumamountdue : Money paymentduedate : Date preparestatement() applypayment() duedatereached() nopaymentdue() Paid On Time preparestatement( statementdate ) Statement Prepared applypayment( transaction ) nopaymentdue duedatereached Payment Past Due applypayment( transaction ) Paid Late Model Repository No Payment Due Statement Prepared entry/ foreach transaction related by self->account[r12]->transaction[r3] where not selected.isbilled relate transaction to self across R5; end for; 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 44

Metamodel <<Imported>> Domain {1,Domain} name : string {I} description : DescriptionString 1 belongs to 1 belongs to R121 * defines * instances are subject to R124 <<Imported>> AssociationConstraint {308,AssociationConst} 1 restricts values of Association {108,Association} associationnumber : integer {I} * R110 1 name : string {I2} participates formalizes description : DescriptionString in AssociationEnd {109,AssociationEnd} associationnumber : integer {I,I2,R110} classnumber : integer {I,R110} phrase : string {I2} multiplicity : integer OOA of OOA R111 R109 is formalized 0,1 by AssociationClass {115,AssociationClass} Transformer * 1 {114,Transformer} name : string is synchronously modified by <<Imported>> ClassConstraint {307,ClassConstraint} 1..* relates Class 0,1 R125 1 {101,Class} R118 is is classnumber : integer {I} name : string {I2} {disjoint, abbreviation : string {I3} complete} * description : DescriptionString defines R122 synchronously 1..* modifies subclasses are 1 1 restricts values of is a characteristic of R123 * R103 instances are subject to characteristics are * abstracted as Attribute {102,Attribute} name : string description : DescriptionString * defines type of AbstractClass {112,AbstractClass} 1 R119 1..* classnumber : integer{i,r118} superclass is must be subclassed discriminator : string according iscomplete : boolean to R102 ConcreteClass {113,ConcreteClass} classnumber : integer{i,r118} R115 Specialization {107,Specialization} <<Imported>> Datatype {2,Datatype} name : string {I} 1 description : DescriptionString is of type Generalization {106,Generalization} * is a specialization of {I} R104 BaseAttribute {103,BaseAttribute} {disjoint, complete} DerivedAttribute {104,DerivedAttribute} 1 R105 1 computes value of 1 return type is R120 = R105+R104+R102 * defines return type of AttributeFormula {105,AttributeFormula} value is computed by 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 45

Metamodel Instances Just like an application model, the metamodel has instances. classid name description 100 101 102 Customer Account BillingGroup A Customer is any individual or business An account represents a customer s financial A set of accounts that are all billed periodically classid stateid statename 101 101 101 101 1 2 3 4 NewAccount In Good Standing Suspended Closed 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 46

Repository Instances Modeling tools create instances in the repository classid name description 100 101 102 103 Customer Account BillingGroup Statement A Customer is any individual or business An account represents a customer s financial A set of accounts that are all billed periodically A statement is a periodic preparation of the 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 47

Model Compiler A model compiler is the automated embodiment of how to turn a model into software under a set of rules. Analysts create models Model Compiler produces a running system Developers program the rules 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 49

Model Compiler a program that creates code from models Analysts create models Model Compiler produces a running system Developers program the rules 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 50

Model Compiler something that makes models executable Analysts create models Model Compiler produces a running system Developers program the rules 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 51

The Big Picture Libraries, Legacy, and Hand-Written Code politically incorrect cartoon Executable Models Generator Software System Archetypes and Mappings Execution Engine Model Compiler 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 53

Model Compiler Multi-processing and multi-tasking Concurrency and sequentialization A model compiler reads executable UML models and creates a system with certain dimensions Persistence Data structuring Data organization 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 54

Examples Financial system Highly distributed Concurrent Transaction-safe with rollback Persistence with rollback J2EE (Java + EJB) Telecommunication system Highly distributed Asynchronous Limited persistence capability C++ Embedded system Single task No operating system Optimized data access and storage C Simulation system Mostly synchronous Few tasks Special-purpose language Import 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 55

The Big Picture Libraries, Legacy, and Hand-Written Code Executable Models Generator Software System Archetypes and Mappings Execution Engine Model Compiler 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 57

Model Compiler.Function Class Class ${Class.name} : public ActiveInstance { private:.invoke PrivateDataMember( Class ) };.Function PrivateDataMember.param Class Class.select many PDM from instances of Attribute related to Class.for each PrivateDataMember ${PDM.Type} ${PDM.Name};.endfor Archetypes Translation rules interpreted by a generator against the repository Execution Engine A limited set of reusable components sufficient to execute Executable UML 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 58

Archetypes Archetypes traverse the repository and... classid name description 100 101 102 Customer Account BillingGroup A Customer is any individual or business An account represents classid a customer s stateid financial statename A set of accounts that are all billed periodically 101 1 NewAccount 101 101 101 2 3 4 In Good Standing Suspended Closed output text. 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 59

Archetypes Archetypes direct the generation of text..function Class Class ${Class.name} : public ActiveInstance { private:.invoke PrivateDataMember( Class ) }; Placeholder introduced by ${...} text (which happens to be C++).Function PrivateDataMember.param Class Class.select many PDM from instances of Attribute related to Class.for each PrivateDataMember ${PDM.Type} ${PDM.Name};.endfor 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 60

Example The archetype language produces text..select many states related to instances of class->[r13]statechart ->[R14]State where (isfinal == False) public: enum states_e { NO_STATE = 0,.for each state in states.if ( not last states ) ${state.name },.else NUM_STATES = ${state.name}.endif.endfor }; public: enum states_e { NO_STATE = 0, NewAccount, InGoodStanding, Suspended, NUM_STATES = Closed }; 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 61

Mappings Design-time assignment of different archetypes to distinct elements in the model Separate from the model and the archetypes Uniformity!= Rigidity 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 62

Table of contents What s the problem? UML models Executable UML elements Executable UML behavior The repository Model compilers Model compiler concepts How model compilers work MDA 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 63

Model Driven Architecture A standard for software development using formal, executable and compilable system specifications Standards should be based on executable UML including the Action Semantics. Interchange can be managed using XML 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 64

Executable UML Entry tools: Verification tools: BridgePoint, Rose, others T-Vec, S/R, COSPAN A B C D Exec. UML Common Semantics XML P Q R S Model Compilers turn Executable UML models into systems. 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 65

Building a Market Design time composability - protects IP The models are a valuable corporate resource that are true business models they describe the business, not the software. 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 66

Building a Market Design time composability - protects IP - allows IP to be mapped to multiple implementations Just because we move to a new software platform doesn t mean that we need to recreate the rules of the bank. 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 67

Building a Market We can sell Billing models that can run on many platforms and support many different businesses. Design time composability - protects IP - allows IP to be mapped to multiple implementations - enables a market in IP in software 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 68

The Future Executable UML enables a market in model compilers. Application experts build models. -.select the appropriate model compiler, and -.compile the model. Each model compiler targets a specific software platform. 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 69

Conclusion Executable UML, using archetypes to direct the generation, enables: - early error detection through verification - reuse of the execution engine - faster performance tuning - faster integration - faster, cheaper retargeting 2003 Stephen J. Mellor and Marc J. Balcer All Rights Reserved 70