3: Modeling Behavior with UML Sequence Diagrams

Transcription

1 Outline UML Design Supplement 3: Modeling Behavior with UML Sequence Diagrams Introduction Basic notation Alternating paths Modularity Slide adapted from Eran Toch s lecture series Specification and Analysis of Information Systems Spring Modeling Process Why to Model Behavior? Phase Actions Outcome Initiation Raising a business need Business documents Requirements Interviewing stakeholders, exploring the system environment Organized documentation Specification Analyze the engineering aspect of the system, building system concepts Formal specification Design Implementation Testing & Integration Maintenance Define architecture, components, data types, algorithms Program, build, unit-testing, integrate, documentation Integrate all components, verification, validation, installation, guidance Bug fixes, modifications, adaptation Formal Specification Testable system Testing results, Working sys System versions How do we use the SMS Server interface? What is the order of executing the operations? sendmessage, getstatus, Resend? getstatus, sendmessage, checkformessages? When do we use resend? 3 4

2 Behavioral Modeling Behavior Modeling Sequence Diagrams Activity Diagrams State Diagrams Checkout Manager message: create Add to cart Order In process Where are people coming from? Where are they going? How do they move from one space to the other? Order message: change status Inventory * We will not talk about collaboration diagrams [problem] Notify User Check availability [okay] Supply Order supplied 5 6 Outline Introduction Basic elements Alternating paths Modularity Building a Sequence Diagrams Sequence diagrams capture the use-case behavior using the foundation of the classes. Class A Use Case 1 Use Case 2 Class B Class C Class D Use Case 3 therefore Sequence = Objects + messages 7 8

3 Sequence Diagrams Object Control A simple sequence diagram: Diagram Name activation (focus of control) Life line sd Product Buying customer! display() getprice() p : Product! : ShooppingCart! addproduct (p)! checkout ()! message objects user! Return Message operate() Messages to self obj1 : Class1! foo()! do ( )! obj2 : Class2! create ( )! Object Destruction Object Creation : Class3! Illustration 9 10 Corresponding Class Diagram Sequences and Use-Cases customer! display() getprice() p : Product! : ShooppingCart! addproduct (p)! Notice that a dependency exists whenever messages are passed between instances of the class Dependencies can be overridden by associations, aggregations etc. checkout ()! create ( )! : Order! Illustration Visible part Hidden part 11 12

4 Full Message Attributes Different Kinds of Messages [sequence-expression] [return-value :=] [message-name] [(argument-list)] Synchronous Message C3.1: res := getlocation (fig) asynchronous Message sequence number return value message name argument list Return Message Synchronous & Asynchronous Messages Outline Nested Flow! teller! : Order! : Article! getvalue! price! Asynchronous Flow! appl! err handl! alarm! unknown! ring! Introduction Basic elements Alternating paths Modularity setid! log! Example Example Price need to be finished, before teller can do another operation (getname) Ring is executed, while the control flow is returned to err handle and appl 15 16

5 Flow Constructs Options If! Else! Loop! Repeat! msg : Message : Database opt [msg.status=confirmed] archive(msg) Fragment Condition Jump! When we tell a scenario, which types of alternatives do we need? Do something... Example Used for modeling simple optional blocks. Has one operand; no "else" guard Alternatives Loops msg : Message : Database : Admin Condition alt [msg.status=confirmed] archive(msg) [msg.status=error] notify(msg.getid()) Alternative Fragment group Loop Fragment : OS : Folder : File loop [for each Folder] Display() loop Else condition (optional) [else] wait() Execution regions. At most one will execute. Condition Nested Loop Fragment [for each File] Display() 19 20

6 Breaks Examples of Guards break : User : User Manager : Policy [ islooged] islooged = login(name,pass) addbadlogin(name) If the condition is met, the break fragment is executed, and the reminder of the sequence is ignored [for each Object] [5] [i=1..5] [status = okay] No guard means an infinite loop Do something Do something Handy in model exception handling Outline Modularity Introduction Basic elements Alternating paths Modularity We need ways to create modular scenarios 23 24

7 Referencing a diagram Referenced Diagram : User : User Manager : Policy Diagram name sd Login Handling : User Manager : UserAccount login(name,pass) ref Login Handling(user,pass) : bool Input message login(name,pass) loop [for each UserAccount] cname = getusenamer() Do something Do something Reference Gate Output message true opt [cname = name] isinsystem(true) false Parallel Fragments Critical Fragment : User providedetails( ) : Checkout Handler : Shipping Handler : Transaction Handler the region is treated atomically by the enclosing fragment (i.e. parallel fragment) No other operations can interfere while a critical region is executed performcheckout() par Ship(address,products) chargemoney(cc,sum) 27 28

8 Summary! Behavior Modeling Sequence models interaction! Language Objects + lifeline Messages! Alternations Loops Alternatives! Modularity Referencing Parallel 29