Tài liệu Sequence diagrams - software design methodology

Sequence Diagrams Software Design Methodology Outline Introduction „ Basic notation „ Alternating paths „ Modularity „ 2 Modeling Process Phase Actions Outcome Business documents Initiation Raising a business need Requirements Interviewing stakeholders, exploring the Organized documentation system environment Specification Analyze the engineering aspect of the system, building system concepts Formal specification Design Define architecture, components, data types, algorithms Formal Specification Implementation Program, build, unit-testing, integrate, documentation Testable system Testing & Integration Integrate all components, verification, validation, installation, guidance Testing results, Working sys Maintenance Bug fixes, modifications, adaptation System versions 3 Why to Model Behavior? „ 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? 4 Behavioral Modeling „ „ „ Where are people coming from? Where are they going? How do they move from one space to the other? 5 Behavior Modeling Sequence Diagrams Activity Diagrams Checkout Manager Order Add to cart message: create In process Check availability Order message: change status State Diagrams [problem] supplied [okay] Inventory Notify User Supply Order * We will not talk about collaboration diagrams 6 Building a Sequence Diagrams Sequence diagrams capture the use-case behavior using the foundation of the Use Case 1 Class C classes. Class A Use Case 3 Use Case 2 Class D Class B therefore Sequence = Objects + messages 7 Sequence Diagrams „ A simple sequence diagram: objects sd Product Buying Diagram Name p : Product : ShooppingCart customer display() message getPrice() activation (focus of control) addProduct (p) checkout () Life line 8 Object Control obj1 : Class1 obj2 : Class2 user Object Creation operate() do (…) create (…) : Class3 Return Message foo() Messages to self Object Destruction Illustration 9 Corresponding Class Diagram Notice that a dependency exists whenever messages are passed between instances of the class Dependencies can be overridden by associations, aggregations etc. Illustration 10 Sequences and Use-Cases p : Product : ShooppingCart customer display() getPrice() addProduct (p) checkout () create (…) : Order Visible part Hidden part 11 Full Message Attributes [sequence-expression] [return-value :=] [message-name] [(argument-list)] C3.1: res := getLocation (fig) sequence number message name argument list return value 12 Different Kinds of Messages Synchronous Message asynchronous Message Return Message 13 Synchronous & Asynchronous Messages Nested Flow teller : Order Asynchronous Flow : Article getValue appl err handl alarm unknown ring price setID log Example Price need to be finished, before teller can do another operation (getName) Example Ring is executed, while the control flow is returned to err handle and appl 14 Outline Introduction „ Basic elements „ Alternating paths „ Modularity „ 15 Flow Constructs If Loop ElseRepeat Jump When we tell a scenario, which types of alternatives do we need? 16 Options msg : Message : Database Fragment opt [msg.status=confirmed] Condition archive(msg) Do something... Used for modeling simple optional blocks. Has one operand; no "else" guard. Example 17 Alternatives msg : Message : Database : Admin alt [msg.status=confirmed] archive(msg) Alternative Fragment group Condition [msg.status=error] notify(msg.getID()) [else] wait() Else condition (optional) Execution regions. At most one will execute. 18 Loops : OS : Folder : File loop Loop Fragment [for each Folder] Display() loop [for each File] Display() Condition Nested Loop Fragment 19 Breaks : User : User Manager : Policy isLooged = login(name,pass) If the condition is met, the break fragment is executed, and the reminder of the sequence is ignored break [¬isLooged] addBadLogin(name) Do something… Do something … Handy in model exception handling 20