Executable and Translatable UML

Home , Activity diagram, Event (UML), Executable UML, Sequence diagram, State diagram

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

Analysts create …print them out… … then the developers “high-level” look at the models application and write the models… production code

These models are Coding adds this independent of the “design detail” implementation technology

But once …we shouldn’t something is in have to manually a machine reinterpret it representation… (“elaborate it”) into another.

The analyst’s diagrams Keeping the diagrams The rework introduces don’t have to be complete, in sync with the code development errors and correct, or consistent models is a daunting task. obscures analyst errors

But once …we shouldn’t something is in Because have to manually a machine elaboration reinterpret it representation… (“elaborate it”) is stupid! into another.

The Ant appears courtesy of Leon Starr, Executable UML

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…

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

What’s the problem? UML Models Executable UML elements Executable UML behavior The Repository Model Compiler Concepts How model compilers work MDA

“The Unified Modeling Language is a language for specifying, constructing, visualizing, and documenting artifacts of a software-intensive system” —The UML Summary ®

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

Describing Modeling Documenting a problem a solution software “Requirements” “Analysis” “Design”

Just because these use the same notation (UML) doesn’t mean these are the same problem.

The software design does not follow from the model of the The models are more than problem just the observable behavior to the user

doBilling( ) : BillingGroup Customer name : PersonalName Open Account address : MailingAddress phone : TelephoneNumber billGroup( ) customerID : CustomerIDNumber : Timer billingComplete( )

is the responsibility of 1 R1 : BillingRun is responsible for 1..* Suspend Account Account Customer Service Collection Agent number : CardAccountNumber Rep / currentBalance : Money Call Delinquent Customer actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed prepareStatement( ) transactionDate : Date interestRate : Percent on accumulates / netAmount : Money 1 R3 0..* notes : FreeformText open() dueDateReached( ) suspend( ) approve() reinstate( ) Close Account suspend() is current presents 0..* presentation of : Statement : Account reinstate() R12 close() 1 directs billing of 0..* Produce Bills for Group R5 Timer R2 is billed as part of 1 BillingGroup applyPayment( ) groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber Submit Charge presented to 1 customer as 0..1 appears on receivePayment( ) doBilling() Statement billingComplete() / statementDate : Date : Payment is an actual billing of 1 minimumAmountDue : Money Merchant paymentDueDate : Date R4 prepareStatement() is actually billed as 0..* Receive Payment applyPayment() Billing Clerk BillingRun dueDateReached() : Billing Clerk Issue Credit billingDate : Date noPaymentDue()

billGroup() Use Case Diagram allBillsProduced() Class Diagram Collaboration Diagram C1 C2 Open Account prepareStatement( statementDate ) : Payment : Statement : Billing Clerk : Timer C3 Statement Prepared

receivePayment( ) applyPayment( ) Pay Bill applyPayment( transaction ) noPaymentDue Component Diagram dueDateReached Paid On Payment No Payment dueDateReached( ) Time Past Due Due ignored Branch applyPayment( transaction ) Close Account HQ Paid Late

Branch Activity Diagram State Diagram Sequence Diagram Remote

Deployment Diagram Each diagram is well-defined, but how do they fit together?

What’s the problem? UML Models Executable UML elements Executable UML behavior The Repository Model Compiler Concepts How model compilers work MDA

Describing Modeling Documenting a problem a solution software “Requirements” “Analysis” “Design”

Customer name : PersonalName address : MailingAddress phone : TelephoneNumber customerID : CustomerIDNumber

is the responsibility of 1 R1 is responsible for 1..* A profile defines how these Account number : CardAccountNumber / currentBalance : Money actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed transactionDate : Date interestRate : Percent on accumulates / netAmount : Money diagrams represent models 1 R3 0..* notes : FreeformText open() approve() suspend() is current presents 0..* presentation of reinstate() R12 close() 1 directs billing of 0..* R2 R5 is billed as part of 1 BillingGroup groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber presented to 1 customer as 0..1 appears on doBilling() Statement billingComplete() / statementDate : Date is an actual billing of 1 minimumAmountDue : Money paymentDueDate : Date R4 prepareStatement() is actually billed as 0..* applyPayment() BillingRun dueDateReached() billingDate : Date noPaymentDue()

billGroup() allBillsProduced() Information Model (things in the problem and how they are related) prepareStatement( statementDate )

Statement Prepared

applyPayment( transaction ) noPaymentDue dueDateReached

Paid On Payment No Payment Time Past Due Due

applyPayment( transaction )

Paid Late

State Model (lifecycle of an instance of a class)

Customer doBilling( ) name : PersonalName address : MailingAddress : BillingGroup phone : TelephoneNumber customerID : CustomerIDNumber

1 is the responsibility of billGroup( ) R1 : Timer billingComplete( ) is responsible for 1..* It also defines a set of diagrams Account number : CardAccountNumber : BillingRun / currentBalance : Money actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed transactionDate : Date interestRate : Percent on accumulates / netAmount : Money that are derived from 1 R3 0..* notes : FreeformText open() approve() prepareStatement( ) suspend() is current presents 0..* presentation of reinstate() R12 dueDateReached( ) close() 1 suspend( ) directs billing of 0..* the basic models reinstate( ) : Statement : Account R2 R5 is billed as part of 1 BillingGroup groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber presented to 1 customer as 0..1 appears on applyPayment( ) doBilling() Statement billingComplete() / statementDate : Date is an actual billing of 1 minimumAmountDue : Money receivePayment( ) paymentDueDate : Date R4 prepareStatement() : Payment is actually billed as 0..* applyPayment() BillingRun dueDateReached() billingDate : Date noPaymentDue() billGroup() : Billing Clerk allBillsProduced() Information Model Object Communication Model (things in the problem (summary of object interactions) and how they are related) prepareStatement( statementDate )

Statement Prepared

: Payment : Statement applyPayment( transaction ) noPaymentDue : Billing Clerk : Timer dueDateReached receivePayment( ) Paid On Payment No Payment applyPayment( ) Time Past Due Due

applyPayment( transaction ) dueDateReached( ) Paid Late ignored State Model (lifecycle of an instance of a class) Execution Trace (system behavior under one scenario)

Customer Class name : PersonalName address : MailingAddress phone : TelephoneNumber abstraction of common characteristics customerID : CustomerIDNumber

is the responsibility of 1 and common behavior R1 is responsible for 1..* Account number : CardAccountNumber Attribute / currentBalance : Money actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed transactionDate : Date abstraction of a single interestRate : Percent on accumulates / netAmount : Money R3 notes : FreeformText open() 1 0..* characteristic of a class approve() suspend() is current presents 0..* presentation of reinstate() R12 close() 1 directs billing of 0..* derived attribute R2 R5 is billed as part of 1 BillingGroup groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber presented to 1 customer as 0..1 appears on doBilling() Statement billingComplete() / statementDate : Date is an actual billing of 1 minimumAmountDue : Money Association paymentDueDate : Date R4 prepareStatement() is actually billed as 0..* abstraction of a relationship applyPayment() BillingRun dueDateReached() billingDate : Date noPaymentDue() between classes

billGroup() allBillsProduced() Event association class received by the object’s state machine

Statement initial pseudostate

prepareStatement( statementDate )

Statement Prepared State a stage in the lifecycle applyPayment( transaction ) noPaymentDue dueDateReached

Paid On Payment No Payment Time Past Due Due Event applyPayment( transaction ) abstraction of a single Paid Late signal received by the state machine Transition abstraction of a progression from state to state

Each state has a procedure executed upon entry to the state

prepareStatement( statementDate ) Statement Prepared Statement Prepared

applyPayment( transaction ) noPaymentDue dueDateReached ?

Paid On Payment No Payment Time Past Due Due

applyPayment( transaction )

Paid Late

Actions specify what happens in the state procedure

Need to express the semantics of the

Statement Prepared problem domain - in pseudocode ? - in Java itself? - in a Java-esque syntax? - in a flowchart? - in a dataflow diagram? - in pipes-and-filters?

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

“the statement” what does “post” mean? You talkin’ to me? You wanna post that transaction to me?

Statement Prepared Binds the model to a entry/ particular query = “SELECT * FROM TBL_TRANS, … implementation set rst=CurrentDB().open(query) while not rst.EOF rst.Edit rst(“R5StatementPtr”) = statementID Requires other rst.Update non-application rst.MoveNext wend decisions to be made rst.Close at the same time (Microsoft Visual Basic…sort of)

Pseudocode is not executable

Statement Prepared 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

UML (pre – 1.5) did not have a formalism for actions Statement Prepared Precise Action Semantics specification ? supplements the UML - functional/dataflow- based - established the executable profile - essential for executability

Integrated into UML 1.5 Fundamental actions on UML elements (classes, associations, …) Foundations for writing Precise Action Semantics for UML processing in an executable model - in the problem domain - does not presume an implementation

Why not just design an action language? - Highly political Language Language Language A B C - Many vendors had some proprietary (but not fully compliant) action languages. Uniform Action Semantics - Syntax issues would obscure semantic issues First define a uniform semantics

TALL Several different foreach transaction in self->Account->Transaction[not .isBilled] tool-specific languages self->Transaction := transaction; endfor; First step is to make all action-semantics compliant OAL Syntax is secondary foreach transaction related by self->Account[R12]->Transaction[R3] where not selected.isBilled relate transaction to self across R5; end for;

Specify the logic for each state’s action.

Statement Prepared

entry/ Statement Prepared foreach transaction related by self->Account[R12]->Transaction[R3] where not selected.isBilled relate transaction to self across R5; end for;

Account number : CardAccountNumber {I} / currentBalance : Money actualCreditLimit : Money requestedCreditLimit : Money interestRate : Percent

open() approve() suspend() reinstate() currentBalance = 0; close() foreach transaction related by self->Transaction[R3] select many accounts from instances of Account currentBalance = currentBalance + where selected.number == self.number; transaction.netAmount; return ((cardinality accounts) == 1); end for;

Derived Attribute Constraint

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 Transaction requestedCreditLimit : Money is processed transactionDate : Date interestRate : Percent on accumulates / netAmount : Money R3 notes : FreeformText open() 1 0..* approve() suspend() is current presents 0..* presentation of reinstate() R12 close() 1 directs billing of 0..* R2 R5 is billed as part of 1 prepareStatement( statementDate ) BillingGroup groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber Statement Prepared presented to 1 Statement Prepared customer as 0..1 appears on doBilling() Statement billingComplete() / statementDate : Date is an actual billing of 1 minimumAmountDue : Money paymentDueDate : Date entry/ R4 noPaymentDue prepareStatement() applyPayment( transaction ) is actually billed as 0..* applyPayment() BillingRun dueDateReached() dueDateReached foreach transaction related by billingDate : Date noPaymentDue() Paid On Payment No Payment self->Account[R12]->Transaction[R3] billGroup() Past Due Due allBillsProduced() Time where not selected.isBilled applyPayment( transaction ) relate transaction to self across R5; Classes Paid Late end for;

Lifecycle of Statement Statement Prepared state procedure

What’s the problem? UML models Executable UML elements Executable UML behavior The repository Model compiler concepts How model compilers work MDA

An executable model operates on instances.

Account number : CardAccountNumber number currentBalance actualCredit requestedCredit interestRate / currentBalance : Money Limit Limit actualCreditLimit : Money requestedCreditLimit : Money interestRate : Percent 231552343 110.23 5000 5000 14%

open() 897899934 0.00 8000 10000 12% approve() suspend() 789978994 3423.32 3500 5000 18% reinstate() close()

Statement statementDate minimumAmountDue paymentDueDate / statementDate : Date minimumAmountDue : Money 5/10/2003 10.00 6/1/2003 paymentDueDate : Date

prepareStatement() 6/1/2003 0.00 6/21/2003 applyPayment() dueDateReached() 6/2/2003 68.00 6/21/2003 noPaymentDue()

An executable model operates on instances.

Statement / statementDate : Date prepareStatement( statementDate ) minimumAmountDue : Money paymentDueDate : Date Statement Prepared prepareStatement() applyPayment() dueDateReached dueDateReached() applyPayment( transaction ) noPaymentDue noPaymentDue()

Paid On Payment No Payment Time Past Due Due prepareStatement( statementDate )

a pplyPaym ent ( tr ansa ction ) Statement Prepared

Paid Late

dueDateReached prepareStatement( statementDate ) applyPayment( transaction ) noPaymentDue Statement Prepared Paid On Payment No Payment statement A Time Past Due Due

a pplyPaym ent ( tr ansa ction ) dueDateReached applyPayment( transaction ) noPaymentDue Paid Late Paid On Payment No Payment Time Past Due Due statement B applyPayment( transaction ) Paid Late

statement C

prepareStatement( statementDate ) The lifecycle model Statement Prepared prescribes execution dueDateReached applyPay ment ( tr ans action ) noPaymentDue

Paid On Payment No Payment Time Past Due Due applyPayment( transaction ) When the customer’s payment is Paid Late received, the statement transitions to the next statement and executes actions.

prepareStatement( statementDate )

Statement Prepared

dueDateReached applyPay ment ( tr ans action ) noPaymentDue

Paid On Payment No Payment Time Past Due Due

applyPayment( transaction )

Paid Late

The model executes in response to signals from: - the outside, prepareStatement( statementDate ) Statement Prepared

- timers applyPayment( transaction ) noPaymentDue (delayed events) dueDateReached

Paid On Payment No Payment Time Past Due Due - other instances as they execute applyPayment( transaction ) Paid Late

All instances execute concurrently.

Paid On Payment No Payment Time Past Due Due prepareStatement( statementDate )

a pplyPaym ent ( tr ansa ction ) Statement Prepared

Paid Late

dueDateReached prepareStatement( statementDate ) applyPayment( transaction ) noPaymentDue Statement Prepared Paid On Payment No Payment statement A Time Past Due Due

a pplyPaym ent ( tr ansa ction ) dueDateReached applyPayment( transaction ) noPaymentDue Paid Late Paid On Payment No Payment Time Past Due Due statement B applyPayment( transaction ) Paid Late

statement C

prepareStatement( statementDate )

Statement Prepared receivePayment( accountNumber, date, amount )

Received dueDateReached applyPay ment ( tr ans action ) noPaymentDue

Paid On Payment No Payment Time Past Due Due checkCleared a pplyPaym ent ( tr ansa ction )

Accepted before Paid Late

prepareStatement( statementDate )

Statement Prepared

dueDateReached applyPay ment ( tr ans action ) noPaymentDue

Paid On Payment No Payment Time Past Due Due

applyPayment( transaction ) after Paid Late

Multiple events may be received.

prepareStatement( statementDate )

Statement Prepared receivePayment( accountNumber, date, amount )

Billing Clerk Received dueDateReached applyPay ment ( tr ans action ) noPaymentDue

Paid On Payment No Payment Time Past Due Due checkCleared a pplyPaym ent ( tr ansa ction )

Accepted Paid Late

Concurrent events can produce different outcomes

: Payment : Statement : Account : Billing Clerk : Timer

: Payment : Statement : Account : Billing Clerk : Timer dueDateReached( ) suspend( )

receivePayment( ) applyPayment( )

receivePayment( ) applyPayment( ) dueDateReached( ) reinstate( )

ignored

Two outcomes if the payment is received as the due date passes

Test models in the development environment Check the models just like code

What’s the problem? UML models Executable UML elements Executable UML behavior The repository Model compiler concepts How model compilers work MDA

Compilation requires that the models be available in a metamodel-based model repository Model Repository

The repository holds the developers’ models.

Customer name : PersonalName address : MailingAddress phone : TelephoneNumber prepareStatement( statementDate ) customerID : CustomerIDNumber

is the responsibility of 1 Statement Prepared R1 is responsible for 1..* Account number : CardAccountNumber noPaymentDue / currentBalance : Money applyPayment( transaction ) actualCreditLimit : Money Transaction requestedCreditLimit : Money is processed dueDateReached transactionDate : Date interestRate : Percent on accumulates / netAmount : Money 1 R3 0..*notes : FreeformText No Payment open() Paid On Payment approve() Time Past Due Due suspend() is current presents 0..* presentation of reinstate() R12 close() 1 directs billing of 0..* applyPayment( transaction ) R2 R5 Statement Prepared is billed as part of 1 Paid Late BillingGroup groupNumber : BillingGroupNumber is currently billingDay : BillingDayNumber presented to 1 customer as 0..1 appears on doBilling() Statement entry/ billingComplete() / statementDate : Date is an actual billing of 1 minimumAmountDue : Money paymentDueDate : Date foreach transaction related by R4 prepareStatement() is actually billed as 0..* applyPayment() self->Account[R12]->Transaction[R3] BillingRun dueDateReached() billingDate : Date noPaymentDue() where not selected.isBilled billGroup() allBillsProduced() relate transaction to self across R5; end for; Model Repository

<> Domain {1,Domain} <> AssociationConstraint name : string {I} {308,AssociationConst} description : DescriptionString OOA * 1 1 instances are subject to belongs belongs to to of R124 AssociationEnd R121 {109,AssociationEnd}

* defines 1 restricts values of associationNumber : integer{I,I2,R110} classNumber : integer {I,R110} OOA Association phrase : string {I2} {108,Association} multiplicity : integer associationNumber : integer {I} * R110 1 name : string {I2} participates formalizes description : DescriptionString in

R109 is formalized 0,1 by AbstractClass {112,AbstractClass}1R119 1..* Generalization AssociationClass 1..* relates {106,Generalization} {115,AssociationClass} classNumber : integer{I,R118} superclass is Class must be subclassed discriminator : string {I} R111 R118 isComplete : boolean 0,1R125 1 {101,Class} according to is is classNumber : integer {I} ConcreteClass name : string {I2} {disjoint, {113,ConcreteClass} abbreviation : string {I3} complete} * description : DescriptionString classNumber : integer{I,R118} * is a specialization of defines Transformer *1R122 {114,Transformer} 1..* R115 is synchronously name : string synchronously modifies subclasses are modified by 1 1 restricts values of is a Specialization characteristic {107,Specialization} of <> R123 R103 ClassConstraint * {307,ClassConstraint} instances are subject to characteristics are * abstracted as <> Attribute Datatype {102,Attribute} {2,Datatype} name : string R102 name : string {I} description : DescriptionString * 1 description : DescriptionString defines is of type type of

1 return type is R104 {disjoint, complete} R120 = R105+R104+R102 * defines return type of BaseAttribute DerivedAttribute AttributeFormula {103,BaseAttribute} {104,DerivedAttribute} {105,AttributeFormula}

11R105 computes value is value of computed by

Just like an application model, the metamodel has instances.

classID name description

100 Customer A Customer is any individual or business… 101 Account An account represents a customer’s financial… 102 BillingGroup A set of accounts that are all billed periodically…

classID stateID stateName

101 1 NewAccount

101 2 In Good Standing

101 3 Suspended

101 4 Closed

Modeling tools create instances in the repository

classID name description

100 Customer A Customer is any individual or business… 101 Account An account represents a customer’s financial… 102 BillingGroup A set of accounts that are all billed periodically… 103 Statement A statement is a periodic preparation of the …

What’s the problem? UML models Executable UML elements Executable UML behavior The repository Model compiler concepts How model compilers work MDA

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

…a program that creates code from models…

Analysts create models

Model Compiler produces a running system

Developers program the rules

…something that makes models executable…

Analysts create models

Model Compiler produces a running system

Developers program the rules

…it’s a model compiler.

Analysts create models

Model Compiler produces a running system

Developers program the rules

politically Libraries, Legacy, incorrect and Hand-Written cartoon Code

Executable Models

Generator Software System

Concurrency and A model compiler reads sequentialization Multi-processing executable UML models and multi-tasking and creates a system with certain dimensions

Persistence

Data Data structuring organization

Financial system • Highly distributed • Concurrent • Transaction-safe with rollback • Persistence with rollback • J2EE (Java + EJB) Embedded system • Single task • No operating system • Optimized data access and storage •C Telecommunication system Simulation system • Highly distributed • Mostly synchronous • Asynchronous •Few tasks • Limited persistence • Special-purpose capability language “Import” •C++

What’s the problem? UML models Executable UML elements Executable UML behavior The repository Model compiler concepts How model compilers work MDA

Libraries, Legacy, and Hand-Written Code

Executable Models

Generator Software System

.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 Execution Engine Translation rules interpreted by a A limited set of reusable generator against the repository components sufficient to execute Executable UML

Archetypes traverse the repository and... classID name description 100 Customer A Customer is any individual or business…

101 Account An account representsclassID a customer’sstateID financial… stateName 102 BillingGroup A set of accounts that are all billed periodically… 101 1 NewAccount 101 2 In Good Standing 101 3 Suspended 101 4 Closed

… output text.

Archetypes direct the generation of text. Placeholder introduced by ${...}

.Function Class text (which happens Class ${Class.name} : to be C++) 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

The archetype language produces text. .select many stateS related to instances of class->[R13]StateChart ->[R14]State where (isFinal == False) public: public: enum states_e enum states_e { NO_STATE = 0 , { NO_STATE = 0 , .for each state in stateS NewAccount , InGoodStanding , .if ( not last stateS ) Suspended , ${state.Name } , NUM_STATES = Closed .else }; NUM_STATES = ${state.Name} .endif .endfor };

Design-time assignment of different archetypes to distinct elements in the model

Separate from the model and the archetypes

“Uniformity != Rigidity”

What’s the problem? UML models Executable UML elements Executable UML behavior The repository Model compilers Model compiler concepts How model compilers work MDA

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

Entry tools: BridgePoint®, Rose®, others Verification tools: 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.

Design time composability - protects IP

The models are a valuable corporate resource that are true business models— they describe the business, not the software.

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.

Design time composability - protects IP - allows IP to be mapped to multiple implementations - enables a market in IP in software We can sell “Billing” models that can run on many platforms and support many different businesses.

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.

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