1 / 77

Executable UML (xUML)

K E N N E D Y C A R T E R. Executable UML (xUML). An Online Tutorial. Kennedy Carter Ltd. ( http://www.kc.com ). V2.3. Contents. The Need for xUML The Notational Subset The xUML Process The xUML Action Language System Generation from xUML Models An xUML Case Study Summary

vanna-eaton
Download Presentation

Executable UML (xUML)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. K E N N E D Y C A R T E R Executable UML (xUML) An Online Tutorial Kennedy Carter Ltd. (http://www.kc.com) V2.3

  2. Contents • The Need for xUML • The Notational Subset • The xUML Process • The xUML Action Language • System Generation from xUML Models • An xUML Case Study • Summary Click on a subject or just use the down and up arrow keys to browse through the tutorial

  3. Executable UML The Need for xUML

  4. Action CreateAction Terminate Action ReturnAction CallAction Uninterpreted Action DestroyAction SendAction Why is the the UML 1.4 not executable ? • It is incomplete • UML describes a system in, broadly, two ways: • by specifying the desired results (use cases, sequence diagrams) • by specifying the software that, when executed, will produce the desired results (classes, associations, operations, state machines) • The latter specification of behaviour is the basis for implementing the system, but is missing key ingredients: • the implementation of operations (methods) are specified only by a “language dependent” text string • the actions associated with state machines (and methods) are specified either by a text string, or by using the “action” part of the UML

  5. Action Specifications in UML 1.4 • Cannot be attached to methods and cannot therefore be used to specify operations • Do not cover the full range of information required to model real behaviour • No conditional logic • Do not deal with internal data within an Action Sequence • Cannot describe reading and writing of attributes • Cannot describe manipulation and navigation of associations • Cannot describe parallel behaviour • Not related to the UML type model • Do not have fully defined semantics ..... were intended only as a place holder for future UML development

  6. Transaction Completed/ if is_aborted then return Transaction in Progress Transaction Complete entry/ log transaction Why is the current UML not executable ? • It is big • UML was conceived as a Universal as well as Unified modelling language • UML covers many development paradigms • Synchronous and asynchronous behaviour • State dependent and stateless behaviour • Mealy state machines and Moore state machines • Flat state models and Harel state charts • Abstract analysis modelling and code specific design modelling • Language specific modelling and abstract modelling • Sometimes the breadth of coverage can lead to ambiguity... I have absolutely no idea because that combination of behaviour is undefined! • e.g. what happens if you execute a “return” in a transition action • stimulated by “call” (synchronous) event ?

  7. Actions and the UML • In 1994 Kennedy Carter created the Action Specification Language, which operates at the same level of abstraction as UML……but embodies the precision to allow models to be executed and consequently supports translation of the models into any language. • The OMG has recognised the need for a full action specification in the UML • In November 1998 the OMG issued a Request for Proposals on Precise Action Semantics for the UML • Kennedy Carter is a key participant in the main submitting consortium … …and is confident that ASL will be compliant with the emerging standard. • The proposal was submitted in August 2000 and is supported by …

  8. xUML UML V1.4 Precisely Defined Action Semantics - Semantically Weak Elements + = What is xUML? • xUML is • an executable version of the UML, with… • clearly defined simple model structure • a precise semantics for actions, which will be incorporated into the UML standard • a compliant action specification language • an accompanying process • a proven development process, oriented towards… • executable modelling • large-scale reuse • pattern based design

  9. Statements User Interface Patient Admin Resource Alloc 1:op selects admit in patient 1:dialogue ok hit 2:admit in patient 2: 3:assign bed 3:find a suitable bed 4:bed assigned 4:if bed available then 5:confirm admission 5: confirm admission 6:display dialogue 6: display “success” dialogue U log incident AdmitIn Patient 7: log admission details 8:reject admission 8:else reject admission 9:display dialogue 9: display “failure” dialogue Why an Executable UML ? • Measurable Deliverables • Models that execute tests correctly • Can be delivered in phases with progressive integration • Use case by use case • Class group by class group • Early Verification • Requirements can be validated before extensive system design and coding This supports iterative and incremental development An executable model can be developed and tested even if it supports only a single use case Groups of classes at the collaboration, subsystem, package or domain level can be modelled and executed

  10. Runway Aircraft R9 0..1 0..1 is_ allocated_to deallocate() clearedRunway() # obtain an instance handle for # the runway we just landed on theRunway = this -> R9.”is_allocated_to” # remove the association unlink this R9 theRunway # tell the runway that aircraft has landed [] = deallocate[] on theRunway Why an Executable UML ? • Improves the quality of the modelling • Models can be judged not just on subjective criteria, but on whether they exhibit the desired behaviour and thus meet requirements Does this identify the correct runway to deallocate ? • Focused analyst objective • The aim is to build models that execute correctly • Avoids “analysis paralysis” • Reviews criteria are objective and therefore more useful

  11. GenericContainer GenericClass 0..* 1 HashTable LinkedList BoundedArray <TypicalClass> Why an Executable UML ? • A solid specification • Supports multiple development teams • Well defined models mean well defined interfaces • Easier Transition to Design and Code • No ambiguity in the models - the models have a single clear interpretation • Design can be specified using abstract patterns ..... eliminates maintenance problems due to redundant analysis and design models • Supports extensive code generation if desired • Lack of ambiguity means automatic code generation will deliver functionally correct code

  12. Why an Executable UML ? • and finally ..... It’s more fun ! • Analysts see the results of their efforts more rapidly and have more confidence that what they are doing is correct • Managers get more confidence that progress is being made

  13. Executable UML The Notational Subset

  14. Design aims of UML • The designers of UML did not intend that developers would use all of the formalism at any one time • Rather, they intended it to support a particular paradigm for a particular type of development “It’s like being a cook. You have to know how to use virtually all of the possible ingredients. Just not all at the same time.” Jim Rumbaugh, 1999 ...... Executable UML involves choosing the correct ingredients

  15. Hospital System Domain Chart Patient Administration Class Model Bed State Model Bed Patient ward name bed no bed type patient no name date of birth Bed Available Patient Administration entry/ # find old patient is using 1 old_patient = this -> R1 # remove link to old patient is being used by unlink this R1 old_patient 0..1 In Patient Out Patient Location Tracking is being used by B3:bed_assigned_ B4:bed_ patient no name date of birth patient no next visit date to_patient unassigned Resource Allocation Bed Unavailable entry/ # find new patient User Interface new_patient = find-only In_Patient where \ patient_no = new_patient_no # create link to patient link this R1 new_patient What is executable UML ? • The primary models The class diagram is part of the static model and captures the key abstractions and associations within a domain. It is the foundation of the domain model. • Each domain encapsulates the models that describe a single subject matter area. Domains will be focused on various subject matters in the system such as : • The customer viewpoint • Generic services • Hardware control • Each domain remains independent of other domains and they are connected using Bridges. • A set of execution rules dealing with • Assumptions about when asynchronous messages are responded to • Order of message processing • Interruption of processing • Parallel execution The state chart captures the dynamic behaviour of the active classes.

  16. Hospital System Use Cases Admit In Patient Domain Sequence Diagram Admit In Patient Object Sequence Diagram AdmitOut Patient Statements User Interface Patient Admin Resource Alloc 1:op selects admit in patient 1:dialogue ok hit 2:admit in patient 2: 3:assign bed 3:find a suitable bed 4:bed assigned 4:if bed available then 5:confirm admission 5: confirm admission 6:display dialogue 6: display “success” dialogue U log incident 7: log admission details 8:reject admission 8:else reject admission 9:display dialogue 9: display “failure” dialogue AdmitIn Patient Administrator What is executable UML ? Within each domain an object level sequence diagram shows how the use case will be realised by the interaction between objects. The lifelines on the sequence diagram correspond to objects. The interactions between objects serve to indicate which operations a class must provide and the messages to be sent from on class to another. • Supported by …. Use cases provide an informal description of required behaviour from a user’s perspective. The domain level sequence diagram shows how a use case is realised by the cooperation of the various domains in the system. The lifelines on the sequence diagram correspond to domains. The interactions between domains serve to indicate which services a domain must provide, which services a domain requires of other domains and specifies the bridge requirements.

  17. Operations Domains Classes hopNegotiated this.currentState = ‘journeyComplete’ Train currentSpeed timerId currentState States hopNegotiated finalHopNegotiated TrainManagement 0..1 2. Waiting For Next Hop entry/ nextHop = this -> R2 generate TIM10:setAbsoluteTimer \ generate timeToNegotiateNextHop () at \ nextHop.startTime to this R2 1 Hop Hardware Interface startDate endDate distanceCovered currentState negotiateHop accelCurvePerformed finalAccelCurvePerformed timeToNegotiateNextHop (trainId) hopNegotiated (trainId) 3. Negotiating Hop entry/ nextHop = this -> R2 generate H1:negotiateHop() to nextHop xUML has no Hierarchical Notations - Just Model Layers

  18. Executable UML The xUML Process in Outline

  19. An Elaborative Development Process Changes that result from iterative development must somehow be applied to the analysis documents, the design documents and to the final code. large team of technology experts Require- ments Analyse these never stop changing Of course, with any type of development, the exact requirements are almost never known upfront. This means that some iteration must be performed until the final solution is achieved. Analysis Document manually in months or years Design • “high level” • informal • no completion criteria Design Document Implement application pollutedby technology The analysis document is then quickly abandoned and becomes out of date. Reverse engineering (round trip) tools are usually successful only at keeping the design and code in step • idiosyncratic components • obsolete documentation Software System With elaborative development, the iteration must often include execution of (sections of) the implemented code.

  20. An Alternative View Design is about the specifying the mapping from the implementation independent view in the analysis model to the implementation dependent view in the design model and implementation. This can be done class by class or more systematically. Design Analysis to Design Mapping Require- ments Analyse Such Iteration can be perfomed on parts of the analysis model (single use cases), class groups or the whole model Design to Implementation Mapping Apply the Analysis to Design Mapping Analysis Model The design model can also be developed with iterative development and, if required, this can be done before the application analysis is started. This is because the design captures patterns for implementing any xUML model A good analysis model is a specification of required behaviour. Executable analysis models are suitable for mapping to design and implementation Iteration can be achieved directly at this level because the analysis models are precise enough to be executed and subjected to actual tests. Design Model Apply the Design to Implementation Mapping If the mappings are systematic then this view becomes optional This is produced by applying the mappings to the analysis model. The analysis model and the mappings are maintained and the code isn’t. Software System Iteration can be also be achieved at this level in the same way as elaborative development, if required.

  21. An Alternative View - Developed Design Combine the two mappings as they are applied sequentially.These can be captured as Design Patterns Analysis to Implementation Mapping Require- ments Analyse Analysis Model This can be done manually or, with a code generator, automatically Apply the Analysis to Implementation Mapping Automatic code generation means that Iteration can be achieved at this level without any model getting out of step. This is because changes are made either to the design or to the analysis models (depending on the nature of the change) and the system is then regenerated. Software System

  22. Objectives of the xUML Process • The primary objectives of a development process based on xUML are: Objective Achieved by... Promote large-scale reuse by keeping separate concerns separate throughout Partition the system into domains Shorten development times by maximising the scope for concurrent development of different parts of the system Analyse the domains concurrently Reduce cost of defect removal by testing at the earliest opportunity Build executable analysis models Improve code quality by formalising systematic design patterns Formalise a fully-specified abstract design model Reduce coding and maintenance costs by generating a system composed of software units that have uniform quality and structure Automate the application of the abstract design rules

  23. small team of technology experts small teams of application experts Analyse Design complete, precise & testable the “software architecture” xUML Model Design Patterns automatically in minutes or hours Implement Software System xUML Based Development

  24. FORMALISE ABSTRACT DESIGN MODEL Select or develop suitable patterns and mechanisms (Build/Buy xUML compiler) ANALYSE NEW DOMAINS Build Static Model Build Dynamic Models Specify Actions Model domain use cases Execute and debug xUML models PRODUCE TARGET CODE Apply design patterns to xUML models (manually or automatically) Perform target testing VALIDATE ANALYSIS Execute domain use cases Execute system use cases Overview of the xUML Process SPECIFY DOMAINS Identify new/reused domains Model system use cases The xUML process can be summarised as:

  25. Executable UML The xUML Process Steps

  26. The xUML Process Steps • What’s the process for developing executable models ? • No process is linear so this section illustrates only the steps that are taken, not necessarily the precise ordering • The process can be tailored • Iteration takes place within and across the steps • The phases are: • Preparation or Inception Phase • Establish requirements and scope • Modelling or Elaboration Phase • Development of application analysis models • Development of abstract design models • Construction Phase • Manual or automatic application of absract design rules to application models • This section of the tutorial describes the general principles of the Preparation and Modelling Phases. The application of Modelling to abstract design and the automatic execution of the construction phase is described later.

  27. Hospital System Domain Chart Patient Administration Class Model Hospital System Use Cases Admit In Patient Domain Sequence Diagram Bed Patient ward name bed no bed type patient no name date of birth Patient Administration AdmitOut Patient is using 1 Statements User Interface Patient Admin Resource Alloc 1:op selects admit in patient 1:dialogue ok hit is being used by 2:admit in patient 0..1 2: 3:assign bed 3:find a suitable bed 4:bed assigned In Patient Out Patient 4:if bed available then Location Tracking is being used by 5:confirm admission 5: confirm admission patient no name date of birth patient no next visit date 6:display dialogue 6: display “success” dialogue Resource Allocation U log incident 7: log admission details 8:reject admission 8:else reject admission 9:display dialogue 9: display “failure” dialogue AdmitIn Patient Administrator User Interface Preparation or Inception Phase Capture requirements with use cases Partition system into domains Identify domain interactions Produce first-cut class diagram for each domain to be modelled

  28. The Preparation of Inception Phase • Preparation or Inception Phase aim is to: • scope the project • engineer the requirements • partition the system into domains • identify new, reused or COTS domains • produce first cut class and interaction diagrams for new domains • consider system and software architecture issues • identify key risks • produce size and cost estimates • This phase does not produce any executable models but provides the foundation for the next phase

  29. Patient Admin to Resource Alloc Bridge Patient Administration Admit In Patient Bed Bed Class Object Sequence Diagram State Chart PatientAdmin <<RequiredInterface>> Patient Admin wardName Bed Available assignBed bedNo entry/ bedType Bed # find old patient old_patient = this -> R1 isOccupied # remove link to old patient PatientAdmin <<BridgeClass>> unlink this R1 old_patient CheckAvailability() B3:bed_assigned_ B4:bed_ to_patient unassigned assignBed Bed Unavailable $USE Resource Allocation Generate allocateResource freeBed = find-one Bed where\ isOccupied = FALSE entry/ # find new patient new_patient = find-only In_Patient where \ patient_no = new_patient_no Resource Allocation <<ProvidedInterface>> # create link to patient Resource Allocation link this R1 new_patient allocateResource Modelling or Elaboration Phase Produce the interaction diagram Develop state charts for classes and specify actions using an action language Add operations to classes and specify them using an action language Specify bridges between domains

  30. Modelling or Elaboration Phase • Executable modelling is ideal for iterative and incremental development • Each iteration takes this form: • Select a scenario from a use case (starting with the primary ones) • Update the domain interaction diagram if necessary • For each domain involved: • Produce the class collaboration diagram • Produce state models for the classes • Update the class diagram as required • Add operations to the classes • Specify the operations and state actions with an action language • Specify initial conditions and test methods with an action language • Specify the provided and required interface of the domain • Build the domain model • Simulate the scenario through the domain • Specify the the bridges which connect the domains • Build the multi-domain model • Simulate the scenario through all involved domains

  31. 1. Capture Requirements 2. Partition into Domains 3. Define Domain Interfaces Patient Administration Admit In Patient Bed Static Model Object Sequence Diagram State Chart Bed Available entry/ Bed Patient # find old patient old_patient = this -> R1 ward name patient no bed no name bed type date of birth # remove link to old patient unlink this R1 old_patient is using 1 B3:bed_assigned_ B4:bed_ to_patient unassigned is being used by 0..1 In Patient Out Patient Bed Unavailable is being patient no patient no used by entry/ name next visit date date of birth # find new patient new_patient = find-only In_Patient where \ patient_no = new_patient_no # create link to patient link this R1 new_patient 4. Specify Classes 5. Define Class Interfaces 6. Specify Behaviour The xUML Process Overview

  32. Executable UML The xUML Action Language

  33. The Action Specification Language • A key component of xUML is the Action Language • This section provides a broad summary of the capabilities of ASL , supported by some examples.

  34. Actions, for state-dependent behaviour OPERATION: checkAccountbalance CLASS: Account INPUTS: OUTPUT: if this.balance < 0 then generate overdrawn() to this else generate accountOk() to this endif AC1:createAccount (custId,openingBalance) 1 CREATING Account # create a new account with a unique id and the specified opening balance newAccount = create unique Account with balance = openingBalance Operations, for state independent behaviour # assign today's date to the 'dateOpened' attribute today= current-date newAccount.dateOpened = today # get the handle of the owning customer instance owningCustomer = find-only Customer where custId = custId # link the new account via relationship R1 to the owning customer link newAccount R1 owningCustomer Scenarios, for simulation and system initialisation BRIDGE Banking:informOfExceededOverdraftLimit CLASS: Account INPUTS: OUTPUTS: counterpartDisplayRecord = this -> CPR1 $USE UI [] = DR7:highlightRecord[] on counterpartDisplayRecord $ENDUSE account_1 = create Account with accountId = 32 & \ dateOpened = 2000.10.31 & \ balance = 22504.96 & \ currentState = ‘inGoodStanding’ customer_1 = create unique Customer with ... link account_1 R1 customer_1 ... Bridges, for mapping to other domains Action Specification Language is used for…

  35. Account Instances account id date opened balance owner id current state 32 1996.10.31 22,504.96 462 inGoodStanding 33 1993.11.05 -5,427.75 216 frozen an instance handle is a reference to a specific instance an optional identifier is a set of one or more attributes whose values uniquely distinguish each instance myAccount = find-only Account where accountId=33 Instance Manipulation Instances are manipulated using instance handles is owned by Customer custId custAddress currentState Account accountId dateOpened balance ownerId currentState owns 1 R1 1..* In many contexts, a special instance handle named “this” is always available which contains the instance handle of the instance that is executing the current action.

  36. is owned by Customer custId custAddress currentState Account accountId dateOpened balance ownerId currentState owns 1 1..* R1 Account Instances account id date opened balance owner id current state 32 1996.10.31 22,504.96 462 inGoodStanding 33 1993.11.05 -5,427.75 216 frozen Association Manipulation Associations are manipulated using association primitives So, to navigate from this instance of Account to the owning customer, do not do this... theOwnerId = this.owner_id owningCustomer = find-only Customer where custId = theOwnerId do this instead... owningCustomer = this -> R1

  37. Specifying Actions • The Action Specification Language provides a process modelling formalism that can be used to specify all the processing in a domain. • The most common ASL constructs allow the analyst to: • Create a New Class Instance • Assign Attribute Values • Obtain an Instance Handle • Create an Association Instance • Navigate to a Related Instance • Delete an Association Instance • Navigate to a Set of Instances • Determine if a Set is Empty • Send a Signal Event • Delete a Class Instance

  38. Object Diagram is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account Creating a New Class Instance • The creation operation for Account includes a create statement. OPERATION: createAccount INPUTS: owningCustomer: Customer, openingBalance: Real OUTPUTS: newAccount: Account # create a new account with a unique id & the specified opening balance newAccount = create unique Account with balance = openingBalance # assign today's date to the 'dateOpened' attribute today = current-date newAccount.dateOpened = today # link the new account via relationship R1 to the owning customer link newAccount R1 owningCustomer “openingBalance” is an input parameter to this operation “balance” is an attribute of the Account class “create unique” provides an arbitrary identifier value, use “create” to define specific identifying attributes “newAccount” is an instance handle new Account instance created with arbitrary unique integer value assigned to' accountId' by the architecture “Account” is a class name

  39. OPERATION: createAccount INPUTS: owningCustomer: Customer, openingBalance: Real OUTPUTS: newAccount: Account # create a new account with a unique id & the specified opening balance newAccount = create unique Account with balance = openingBalance # assign today's date to the 'dateOpened' attribute today = current-date newAccount.dateOpened = today # link the new account via relationship R1 to the owning customer link newAccount R1 owningCustomer Object Diagram myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account Assigning Attribute Values • Any action may assign local variables and attribute values... “current-date” is a pre-defined ASL feature which returns the current date This assignment would have more appropriately been made as part of the 'create' statement “=“ is the assignment operator “newAccount” is an instance handle “today” is a local variable which is declared by first use the 'dateOpened' attribute is assigned the value returned by the operation 'current_date' “dateOpened” is an attribute name is owned by

  40. Creating an Association Instance • The analyst specifies when and how association instances are created... OPERATION: createAccount INPUTS: owningCustomer: Customer, openingBalance: Real OUTPUTS: newAccount: Account # create a new account with a unique id & the specified opening balance newAccount = create unique Account with balance = openingBalance # assign today's date to the 'dateOpened' attribute today = current-date newAccount.dateOpened = today # link the new account via relationship R1 to the owning customer link newAccount R1 owningCustomer In this case, the class diagram states the policy that each instance of Account is owned by exactly one instance of Customer. The ASL enforces this policy by creating an instance of association R1 whenever an instance of Account is created. “newAccount” is an instance handle “owningCustomer” is an instance handle “link” is an ASL keyword which links two instances through a specifed association a new instance of R1 is created, linking the new account instance to the owning customer instance found earlier “R1” identifies the association Object Diagram myCustomer : Customer is owned by Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account

  41. Navigating to a Related Instance • It is possible to navigate from one instance to another instance by specifying: • 1. the starting instance, and • 2. the association to navigate. deleteAccount() Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this AC6:delete_account (accountId) This line can be read as “The owningCustomer can be found by navigating from this through R1” The ASL keyword 'this' refers to the instance handle of the instance associated with the state machine or instance-based operation executing the current action. “owningCustomer” is the single instance handle that results from the navigation to the “1” end of an association Object Diagram 3. to obtain the handle of the related Customer instance is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 2. navigate the R1 association instance... 1 R1 1..* myAccount : Account 1. starting from 'this' Account instance...

  42. Deleting a Association Instance • The analyst specify when association instances are deleted... In this case, the analyst is about to delete an instance of Account. Prior to this, the dying Account instance must be unlinked from all of its related instances. deleteAccount() Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this “this” is the ASL keyword that represents the instance executing the state machine “unlink” is the ASL keyword which removes the link between two associated instances “owningCustomer” is an instance handle “R1” identifies the association Object Diagram ‘now I'm a dangling customer!’ is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns the R1 association instance linking this Account instance and the owning Customer instance is deleted ‘goodbye, world’ 1 R1 1..* myAccount : Account

  43. Navigating to a Set of Instances • Navigate to a set of related instances by specifying: • 1. the starting instance, and • 2. the association to navigate. deleteAccount() Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this In this case, since the analyst is navigating to the “many” end of an association, the navigation will deliver a set of (zero or more) Account instances. The {} symbols are used denote a set. Object Diagram 1. starting from the owning Customer instance is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 2. navigate the R1 association instances (there are none in this scenario) 1 R1 1..* myAccount : Account 3. to obtain a set of Account instance handles (an empty set in this scenario)

  44. Determining if a Set is Empty • The cardinality of a set can be determined using the 'countof' function... deleteAccount() In this case, the analyst wishes to determine if the Account instance that is about to die is the last instance owned by the owning Customer instance. If so, then the multiplicity of the association requires that the owning Customer instance be deleted, since it is now related to zero instances of Account. Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this if then else endif is an ASL control logic construct “countof” is an ASL keyword that returns the number of instances of the specified set Object Diagram ‘I've got a feeling I won't last much longer’ is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account ‘I know how you feel’

  45. Sending a Signal Event • It is possible to send an event to a specified instance of a class in the same domain using the “generate...to” construct... deleteAccount() Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this “to” is an ASL keyword that denotes that the signal is sent to the specified instance. “to” must always be followed by a valid instance handle “deleteCustomer” is the signal name Here, the signal carries no supplemental data, hence the empty parameter list denoted by (). Signal parameters are comma separated if there are any. “generate” is an ASL keyword that denotes a signal send the signal 'deleteCustomer’ is sent to the specified instance of Customer Object Diagram is owned by myCustomer : Customer Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account

  46. Deleting a Class Instance • The 'delete' statement is used to delete a specified instance... deleteAccount() Deleting Account # navigate from this account instance to the owning customer instance owningCustomer = this -> R1 # unlink this instance from the owning customer via R1 unlink this R1 owningCustomer # find the set of all other account instances owned by that customer {otherOwnedAccounts} = owningCustomer -> R1 # if there are no other owned accounts for this customer, then # send a deletion event to the customer instance if countof {otherOwnedAccounts} = 0 then generate deleteCustomer() to owningCustomer endif # delete this instance of account delete this In this case, the state is terminal, and therefore this instance of Account must be deleted. “delete” is an ASL keyword the Account instance for this state machine has been deleted. This is guaranteed to have been deleted by the time this action completes. the Customer instance has been deleted as a result of the deletion event to the owning Customer's state machine (NOTE: it cannot be guaranteed that this event has been processed yet) Object Diagram is owned by Customer custId {I-=1} custAddress currentState Account accountId {I=1} dateOpened balance ownerId {R=1} currentState owns 1 R1 1..* myAccount : Account ‘I was right!’

  47. Executable UML System Generation from xUML Models

  48. Scheduler xUML Timer Queues Signal Communication Software Design Model – The Elements To implement a software design model, we will construct: • A class model of the abstract software design. • Design Patterns (archetypes). • Code Patterns in the target language. • Mapping rules from xUML. • A tagging scheme. • Mechanisms….

  49. Domain is part of contains is aninstance of has Class Object defines behaviour of holdsattributefor holdsattributevaluesfor is executing for has has State Model State Machine Instance StaticxUML RuntimexUML processesevents for holds code for events areprocessed by CodeAssembly RuntimeExecution code is held in Type of Process Actual Process canexecute attributevalues areheld in isexecuting attributesare held in Data Structure Data Area isspecifiedby can beexecutedby specifies c is server for isrunningin is located on is accessed via Type of Processor Actual Processor is specified by specifies Abstract Design Model Class Diagram Associations that span the quadrants define characteristics of the architecture such as distribution, threading and queuing policies This quadrant is the meta model for an executing xUML model at runtime and likewise it doesn’t change. It is a static model of the xUML virtual machine. This quadrant is the meta model for the xUML model elements and consequently it doesn’t change. This is a greatly simplified version! This quadrant captures the properties of the software build. It may be very simple in some projects. This quadrant captures the target software runtime view. It must meet the requirements of the xUML virtual machine. The classes in this quadrant will depend on the type of system being built, eg real time embedded or information system.

  50. C++ Code Archetype Design Archetype class Class<ClassName> { public: <returnType1> <operationName1>(); <returnType2> <operationName2>(); //………. private: static char *className; static char *classKeyLetter; //……. <attribute1Type> <attributeName1>; <attribute2Type> <attributeName2>; <attribute3Type> <attributeName3>; <attribute4Type> <attributeName4>; //……. }; {allClasses} = find-all Class for eachClass in {allClasses} do # create a class called Class<ClassName> # with the attributes of Class as static items {theAttributes} = eachClass -> R1 for eachAttribute in {theAttributes} do # create a private member data item # corresponding to the attribute # with type eachAttribute.dataType endfor endfor <ClassName> <attributeName1>:<attribute1Type> <attributeName2>:<attribute2Type> <attributeName3>:<attribute3Type> <attributeName4>:<attribute4Type> … <operationName1>():<returnType1> <operationName2>():<returnType2> … Mapping Rules expressed in ASL Archetypal Design and Code Patterns This is a UML class which describes a design pattern which can be applied to each class in the analysis model. It can be used to show how attributes and operations from the analysis classes will map into the design and also how instances will be contained, how associations will be realised, etc. Expressing the design model in the form of patterns keeps it free from application specific concepts and therefore easier to maintain. This is a code version (C++ in this example) of the design pattern. The actual code is created by substituting the corresponding elements of the analysis model into the places denoted by the <> delimiters. Clearly substitution of this form is mechanical and therefore amenable to automatic code generation if desired. This is a meta level description which defines how the elements of the analysis model will be mapped into the target code. It is defined using ASL

More Related