670 likes | 904 Views
6. Basic Behavioral Modeling. Interactions. Overview. Interactions Roles Links Messages Actions Sequences Modeling flows of control. Creating well-structured algorithms. Terms & Concepts.
E N D
6. Basic Behavioral Modeling Interactions
Overview • Interactions • Roles • Links • Messages • Actions • Sequences • Modeling flows of control. • Creating well-structured algorithms. CS6359 Chapter 15
Terms & Concepts • Interaction—behavior that comprises a set of messages exchanged among a set of objects within a context to accomplish a purpose. • Message—specification of a communication between objects that conveys information with the expectation that activity will ensue. CS6359 Chapter 15
Interactions • Static representation of objects working to complete some action. • Introduce messages between objects and classes. • Invocation of an operation. • Construction or destruction of an object. • Models flow of control within an operation. • Identify how messages are dispatched across time. • Focus on the structural relationships among objects involved in an interaction. CS6359 Chapter 15
Interactions (cont’d) • Properties of well-structured interactions • Efficient • Simple • Adaptable • Understandable CS6359 Chapter 15
Objects & Roles • Objects within an interaction • Concrete—something from the real world. • Prototypical—representative instance of something from the real world. • Collaborations use strictly prototypical things. • Prototypical instances of interfaces and abstract types are valid. • Can be identified from class diagrams. CS6359 Chapter 15
Person + setCompensation( s : Salary ) + assign( d : Department ) … Links • Semantic connection among objects. • An instance of an association or dependency. • Provide a passage for messages. Company 1..* * employee employer anonymous object message assign( development ) p : Person : Company link named object CS6359 Chapter 15
Link Existence • Model operation needed to create link. • Adorn end of link with stereotype. • Association • Self • Global • Local • Parameter CS6359 Chapter 15
Messages • Directed line near link. • Name of operation that must be defined on target. message sequence number 1.1 : getLastCheckpoint( ) 1 : getPositionAtTime( t ) t : AirTrafficPlanner p : FlightPlan link object CS6359 Chapter 15
Modeling Actions • Call*—invokes an operation on an object. • Return—returns a value to the caller. • Send*—sends a signal to an object. • Create—creates an object. • Destroy—destroys an object. *Essentially the same, but send implies an event notification or control flow between objects. CS6359 Chapter 15
Actions Depicted object c : Client p : PlanningAgent create <<create>> : TicketAgent setItenerary( i ) actual parameter calculateRoute() return value return call on self route destroy <<destroy>> X send notify() CS6359 Chapter 15
Sequencing • A stream of messages where actions are delegated forms a sequence. • The beginning of each sequence is rooted in some process or thread. • Each thread defines a distinct flow of control. • Messages are ordered in sequence by time. • Represented by a sequence number followed by a colon. CS6359 Chapter 15
Procedural Sequencing • Most common. • Each message within the same operation is numbered sequentially. • Nested messages are prefixed with the sequence number of the invoking operation. • Rendered with filled solid arrow. CS6359 Chapter 15
Flat sequencing • InfrequentNot recommended for most situations. • Each message is numbered sequentially in order of timing. • Shows progression of control. • Rendered with stick arrowhead. CS6359 Chapter 15
Sequencing Depicted • Procedural Sequence • Flat Sequence message sequence number 2 : clickAt( p ) 2.2 : putRecentPick( l ) :View c : Controller :Cache 2.1 : l = findAt( p ) nested of control message sequence number sequence number 1 : liftHandset() 2 : assertCall() c : Caller :Telephone :Exchange flat flow of control CS6359 Chapter 15
Thread Identification • Message sequence number prefixed with thread identifier. • Helps distinguish multiple threads of control. • Consider coloring messages to match threads. CS6359 Chapter 15
Creation & Destruction • Adorn with constraints. • new • destroyed • transient 1 : <<create>> 2.3 : update( p ) 4 : <<destroy>> c : Controller {transient} CS6359 Chapter 15
Representing Interactions • Sequence diagram • Emphasizes time ordering of messages. • Depicts the lifeline of objects. • Collaboration diagram • Emphasizes structural organization. • Potentially easier to model complex interactions. CS6359 Chapter 15
Modeling Flow of Control (steps) • Set the context for the interaction. • Set the stage by identifying participating objects. • If emphasizing the structural organization, identify related links. • Specify the messages that pass from object to object in time order. CS6359 Chapter 15
Flow of Control by Time p : StockQuotePublisher s1 : StockQuoteSubscriber s2 : StockQuoteSubscriber attach(s1) attach(s2) notify() update() getState() update() getState() CS6359 Chapter 15
Flow of Control by Organization s1 : StockQuoteSubscriber 4 : update() 3 : notify() 1 : attach(s1) 6 : getState() p : StockQuotePublisher 5 : update() 2 : attach(s2) 7 : getState() s2 : StockQuoteSubscriber CS6359 Chapter 15
Hints & Tips • A well-formed interaction. • Encompasses only the objects that work together to carry out some behavior bigger than the sum of the elements. • Has a clear context. • Optimally balances time and resources. • Promotes adaptability since operations may be likely to change. • Understandable CS6359 Chapter 15
Hints & Tips (cont’d) • Depicting interactions. • Choose an emphasis for the interaction. • Show only the object properties that are important in its context. • Show the message properties that are important in its context. CS6359 Chapter 15
Summary • Interactions • Roles • Links • Messages • Actions • Sequences • Modeling flow of control. CS6359 Chapter 15
6. Basic Behavioral Modeling Use Case Diagrams
Overview • Use cases • Include • Extend • Actors • Modeling behavior of an element. • Realizing use cases with collaborations. • Modeling the context of a system. • Modeling the requirements of a system. • Testing from use cases. CS6359 Chapter 16
Use Case Definition • …User Guide • Description of a set of sequences of actions that a system performs to yield an observable result of value to an actor. • Object-oriented Software Engineering; Jacobson, ‘92 • Narrative document that describes the sequences of events of an actor using a system to complete a process. CS6359 Chapter 16
Use Cases • Defines “what” without specifying “how”! • Specify desired behavior. • Promotes communication among: • End users • Domain experts • Architects • Developers • Information Modelers CS6359 Chapter 16
Use Cases (cont’d) • Represents a set of functional requirements on a system. • Achieve a tangible amount of work. • Provide a starting point for test cases. use case actor Process loan name LoanOfficer CS6359 Chapter 16
Actor • Coherent set of roles that users assume when interacting with a system. • Human or automated systems. • Represents an individual interacting with the system in a specific way. • Live outside the system. • Connected to use cases through associations. automated system <<stereotype>> CS6359 Chapter 16
Use Cases and Flow of EventsTypical Course of Events • Usually described in informal text or formal structured text. • Visualized in interaction diagrams; commonly system sequence diagram. • Exceptional flows or variations depicted separately. • Identifies when the use case begins and ends. CS6359 Chapter 16
Use Cases and Scenarios • Scenarios describe a particular sequence through a use case. • Real or prototypical values are used. • Each sequence defines a set of system operations. • System operation: • System level function. • A single interaction between an actor and the system. CS6359 Chapter 16
Use Cases and Collaborations • Collaboration—a society of classes and other elements that work together to implement the behavior of a use case. • Realization of a use case. realization collaboration Place order Order management use case CS6359 Chapter 16
Organizing Use Cases • Use packages. • Factor common behavior through relationships. • Generalization • Extend • Include CS6359 Chapter 16
Generalized Use Case • Child inherits behavior and meaning from parent. • Child may be substituted any place for a parent. • Rendered same as class generalization. CS6359 Chapter 16
Use Case Inclusion • Base use case explicitly incorporates the behavior of another use case. • The included use case cannot stand alone. • Example of delegation. • Rendered as a stereotyped dependency. CS6359 Chapter 16
Extending a Use Case • Base use case incorporates the behavior of another use case. • The extending use case indicates where the extended behavior occurs in the base use case. • Base use case only extended through extension points. • Used to model optional behavior. • Rendered as a stereotyped dependency. CS6359 Chapter 16
Use Case Organization Example extension point extension <<extend>> (set priority) Place order Extension points: set priority Place rush order <<include>> Check password inclusion Validate user Track order <<include>> generalization Retinal scan CS6359 Chapter 16
Example (cont’d) Track Order Main flow of control : Obtain and verify the order number. Include (Validate user). For each part in the order, query its status, then report back to the user. Place Order Main flow of control: Include (Validate user). Collect the user’s order items. (set priority). Submit the order for processing. CS6359 Chapter 16
Modeling the Behavior of an Element • Element could represent • The system as a whole. • A subsystem. • An individual class. • Important reasons: • Allows domain experts to specify external view to sufficient details for developers to continue. • Provides a means for developers to approach and understand an element. • Provides a basis for testing. CS6359 Chapter 16
Modeling Behavior (steps) • Identify actors that interact with the element. • Organize actors by generalized and more specialized roles. • Consider the primary ways actors interact with the element. • Consider the exceptional ways actors interact with an element. • Organize the behaviors as use cases. CS6359 Chapter 16
Hints & Tips on Use Cases • Well structured use case: • Names a single, identifiable and atomic behavior. • Factors common behavior through inclusion. • Factors variants by pushing behavior through extension. • Describes the flow of events such that a non-technical person can follow. • Clarified by a minimal set of scenarios that specify the normal and variant semantics. CS6359 Chapter 16
Hints & Tips on Use Cases (cont’d) • Depicting a use case: • Show only the use cases that are important to understand the behavior in a particular context. • Show only the actors related to those use cases. CS6359 Chapter 16
Use Case Diagrams • Use case diagram—diagram that shows a set of use cases and actors and their relationships. • Used to visualize the behavior of a system. • Allows users to comprehend the interactions with the system. CS6359 Chapter 16
actor Place phone call Place conference call «extend» extension Receive phone call Receive additional call Cellular Network «extend» use case Use scheduler system boundary Cellular Telephone association Use Case Diagram (an example) CS6359 Chapter 16
Use Case Diagram Contents • Use cases • Actors • Relationships • Dependencies • Generalizations • Associations • Notes and constraints CS6359 Chapter 16
Common Uses • Model the context of a system. • Identifying the system border. • Defining what is inside the system. • Defining what is outside the system. • Model the requirements of a system. • What the system should do. • Independent of how the system will do it! CS6359 Chapter 16
Modeling the System Context • Identify the actors that surround the system. • Which groups need help from the system. • Which groups are needed to execute system functions. • Which groups interact with external hardware. • Which groups perform secondary functions. • Organize actors using generalization if appropriate. • Use stereotypes for actors to aid understanding. • Populate a use case diagram with actors and associate with system use cases. CS6359 Chapter 16
Customer Credit Card Validation System Perform card transaction Process customer bill Retail Institution Reconcile transactions Manage customer account Corporate Customer Context Example CS6359 Chapter 16
Modeling System Requirements • Establish the system context. • Consider the behavior that each actor expects from the system. • Name common behaviors as use cases. • Factor common behavior; extensions, inclusions, and generalizations. • Model the actors, use cases, and relationships into a use case diagram. • Adorn with notes for non-functional requirements. CS6359 Chapter 16