Types of Diagrams
• Structural Diagrams – focus on static UML Sequence Diagrams aspects of the software system – Class, Object, Component, Deployment
Eileen Kraemer • Behavioral Diagrams – focus on dynamic aspects of the software system CSE 335 – Use-case, Interaction, State Chart, Activity Michigan State University
Structural Diagrams Behavioral Diagram
• Class Diagram – set of classes and their • Use Case Diagram – high-level behaviors of the relationships. Describes interface to the class system, user goals, external entities: actors (set of operations describing services) • Sequence Diagram – focus on time ordering of • Object Diagram – set of objects (class messages instances) and their relationships • Collaboration Diagram – focus on structural • Component Diagram – logical groupings of organization of objects and messages elements and their relationships • State Chart Diagram – event driven state • Deployment Diagram - set of computational changes of system resources (nodes) that host each component. • Activity Diagram – flow of control between activities
Use Case Diagrams Use Case Diagrams
• Describes a set of sequences. • Each sequence represents the interactions of things outside the system (actors) with the system itself (and key abstractions) • Use cases represent the functional requirements of the system (non- functional requirements must be given elsewhere)
1 Use case Actor A Use Case • Each use case has a descriptive name • Actors have a name An Actor • Describes what a system does but not • An actor is a set of roles that users of use how it does it. cases play when interacting with the • Use case names must be unique within a system given package • They are external entities • Examples: withdraw money, process loan • They may be external an system or DB • Examples: Customer, Loan officer
What is a Use Case Example
• Use case captures some user-visible Point of Sale Terminal functionality • Granularity of functionality depends on the Buy Item level of detail in your model • Each use case achieves a discrete goal Log in
for the user Cashier Customer • Use Cases are generated through requirements elicitation Refund a Purchase
Extend and Include Example (generalization)
«extends» Credit Card Validation Invalid Date
Perform Card Transaction Change Time or Date
Retail Institution «include» Customer Process Customer Bills «inherits» Clock Reconcile «inherits» Transaction Select an Option
User «include» Individual Custumer Manage Customer Account Finacial Institution Display Hightest and Lowest Corporate Custumer
2 Refining the Object Model
• Modeling Behavior • Typically, only very simplistic object models can be directly derived from use cases. • Sequence Diagrams • A better understanding of the behavior of each use case is necessary (i.e., analysis) • Use interaction diagrams to specify and detail the behavior of use cases • This helps to identify and refine key abstractions and relationships • Operations, attributes, and messages are also identified during this process
Interaction Diagrams Sequence Diagrams
• There is one (or more) Interaction diagram per use case • X-axis is objects – Represent a sequence of interactions – Object that initiates interaction is left most – Made up of objects, links, and messages – Object to the right are increasingly more subordinate • Sequence diagrams – Models flow of control by time ordering • Y-axis is time – Emphasizes passing messages wrt time – Messages sent and received are ordered by time – Shows simple iteration and branching • Object life lines represent the existence over a • Collaboration diagrams period of time – Models flow of control by organization – Structural relationships among instances in the interaction • Activation (double line) is the execution of the – Shows complex iteration and branching procedure.
Example UML Sequence Message Passing Diagram
• Send – sends a signal (message) to an c:client p:planningAssistant object <
calculateRoute() • Stereotypes send – <
3 Example S:Caller :swtich R:Caller
liftReceiver
S : sampler WD : sensors WS : sensors Temp : sensors Hum : sensors setDialtone dialDigit(d) Every 1/60 sec.
routeCall(S,R)
Every 0.5 sec. <
connect
connect connect
Mail System access mailbox Mail System (2)
retrieve a message
«extends»
owner change greeting retrieve a message Reach an extension
«uses» set password add a mailbox «uses»
Administrator delete a message
remove a mailbox delete a message caller owner Leave a message set a user's password Leave a message caller
Mail System Objects Access Mailbox recorder : inputReader sys : mailbox
: owner
• Caller, owner, administrator dial(8888)
checkForInput
• Mailbox, extension, password, greeting promptForExtension dial(dddd)
• Message, message list ext:=getExtension() create() • Mail system ext : extension verifyExtension • Input reader/device lookup(ext:extension)
Notify
4 Leave a message MailSystem inputReader 1 recorder : inputReader sys : mailbox +verifyExtension() +getExtension() : extension -promptForExtension() +getMessage() : message : caller 1 -Administrator -promptForMessage() +dial() -notifyDone() +hangup() adminMailbox +checkForInput() dial(dddd) 1 +talk()
ext:=getExtension() * -Users create ext : extension mailbox
verifyExtension +lookup(in mailbox : extension) +saveMessage(in mess : message) promptForMessage talk() 1 1 1
getMessage 2 create() extension messageList hangup mes : message +create()
* lookup(ext) 1 saveMessage(mes) message
+create()
Properties of Sequence Collaboration Diagrams Diagrams • Initiator is leftmost object (boundary • Emphasizes the organization of the object) objects that participate in an interaction • Next is typically a control object • Classifier roles • Then comes entity objects • Association • Messages, flow, and sequencing
Example Collaboration Diagram Leave a Message
1: dial 2: checkforInput() 3: dial 4: ext:=getExtension() 6: talk 7: mess:=getMessage() Request(order, customer) 2: cost:=researce(order) inputReader MailSystem orderTaker TicketDB ) (ext kup ) Loo ess 5: e(m sav st) 8: erco tom er) cus tom bit( (cus : de edit 3 kCr CreditBureau hec 1: c
mailbox
5 Summary (Interaction Collaboration vs Sequence Diagrams) • The two diagrams really show the same • Well structured interaction diagrams: information – Is focused on communicating one aspect of a system’s dynamics • Collaboration diagrams show more static – Contains only those elements that are essential to structure (however, class diagrams are understanding – Is not so minimalistic that it misinforms the reader better at this) about the semantics that are important • Sequence diagrams clearly highlight the • Diagrams should have meaningful names orderings and very useful for multi-tasking • Layout diagram to minimize line crossings • Use branching sparingly (leave for activity dia)
State Diagrams State Diagram Features
• Finite state machines (i.e., automata, • Event – something that happens at a specific Mealy/Moore, state transition) point • Used to describe the behavior of one object (or – Alarm goes off sometimes an operator) for a number of • Condition – something that has a duration scenarios that affect the object – Alarm is on • They are not good for showing interaction between objects (use interaction diagrams) – Fuel level is low • Only use when the behavior of a object is • State – an abstraction of the attributes and complex and more detail is needed relationships of an object (or system) – The fuel tank is in a too low level when the fuel level is below level x for n seconds
Example: on/off Switch Using guards and actions
recieveOrder [amount<25] Waiting Process trigger event guard order / FlipSwitch recieveOrder [amount>25] approve / debitAccount()
on off action / FlipSwitch Confirm reject credit Cancel order
6