MODULE 13:
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Visualizing ScenariosUML offers three diagrams for describing
use cases and interactions in detail:◦activity diagram◦interaction diagrams:
sequence diagram communication (collaboration) diagram
Interaction diagrams focus on the objects and methods and are used in design.
Activity diagrams are used to document the overall flow and are used in analysis.
13-2
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Sequence DiagramsA sequence diagram emphasizes
the sequence of steps for a particular system transaction or use-case scenario.
Sequence diagrams are frequently enhanced by scripts.
The scripts are refinements of the scenario traces made during analysis.
13-3
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Using Sequence DiagramsUse sequence diagrams to:
◦document designs of methods and use cases
◦document existing code◦document debug traces
13-4
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Sequence Diagram Example
13-5
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
MethodsTwo definitions:
◦A method is a function or transformation that may be applied to objects. (Rumbaugh)
◦A method is an action that one object performs upon another in order to elicit a response. (Booch)
All objects of a class possess the same set of methods (interface).
13-6
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Alternative TermsDifferent methodologies use
various terms to describe methods:◦service◦operation◦responsibility◦member function
13-7
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Method ExamplesSome simple examples of methods
are:◦Scheduler: addEvent, removeEvent◦Account: payInterest, withdraw◦Investor: getName, changeAddress◦Portfolio: computeValue
Methods that don't change the object are called accessors, whereas modifiers change the state of the object.
13-8
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
SignatureThe signature of a method
contains:◦the method name◦the type of its arguments
The signature is part of a C++ or Java function’s prototype.
The concept of signature is important to polymorphism.
13-9
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
PolymorphismTwo definitions:
◦Polymorphism is the ability of two or more classes to respond to the same message, each in its own way. (Wirfs-Brock)
◦Polymorphism means that the sender of a message does not need to know the receiving object’s type. (Jacobson)
13-10
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Defining MethodsThere are two approaches:
◦look at each class and define the methods that the class could use
◦look at how the class is used in specific use-case scenarios and assign each step to a method of a class; if no class can take on the responsibility, define a new class
To understand what a class does, you must understand how it is being used.13-11
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Guidelines for MethodsA well-designed method should:
◦carry out a single activity◦have a meaningful name (e.g.
getBalance, computeValue, addItem)◦avoid input flags◦take few or no parameters◦not switch on the value of an
attribute
13-12
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Categories of ClassesA software architecture contains
several categories of classes:◦Business Entity Classes◦User Interface Classes◦Support and Data Structure Classes◦Device Encapsulation Classes◦Proxy and Wrapper Classes◦Controller Classes
13-13
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Encapsulating Use CasesClasses in a software architecture
should be as independent as possible to increase the stability of the system.
Use case flow is contained within Controller or Agent classes.
Each use case is represented by one or more controller classes.
Controllers encapsulate business process.
13-14
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Controller FrameworkApp
UI
Actor
Event Managerevent
SalesRecorder
OrderPlacer
...
Object Space
item
inventory
customer...
......
This is the well-known Model-View-Controller (MVC) framework for designing modern service-oriented applications, including web applications (e.g., JSF, Rails)
13-15
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Naming Controller Classes Use case controller classes should be named based
on the use cases they represent:◦ Use Case Names:
Record Sales Generate Monthly Report
◦ Controller Names: SalesRecorder MonthlyReportGenerator
Each time a particular use case must be carried out, a corresponding controller object is instantiated and a method of that controller object is invoked.
The controller should delegate its work to the domain objects; it should regulate the flow of control, but not do any work.
13-16
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Creating a Sequence DiagramDecide on the perspective:
◦use case◦computational process◦operation
Define the start of the sequence diagram:◦actor◦controller◦start activity
13-17
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Sequence Diagram for a Use Case
Cashie r
Record Sale
Cashier
(from Actors)
SalesRecorder
or
13-18
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Sequence Diagram for a Method
Sale
StartStart
calcTotal()
13-19
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Showing Object Interactions
Sale 1.. *SaleItem
thePrice= getPrice()
13-20
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Showing LoopsSale 1.. *SaleItem
StartStart
loop
calcTotal()
getPrice() :double
13-21
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Showing Alternate FlowsSale 1.. *SaleItem
alt
[numItems > 0]
[else]
thePrice= getPrice()
13-22
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Communication DiagramsA communication diagram
emphasizes links between objects and data flow along those links.
Communication diagrams do not have an associated script and have a more relaxed layout.
Communication diagrams were called collaboration diagrams in UML 1.4.
13-23
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Communication Diagram Example
13-24
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Data Flows
Data Flow Tokens
13-25
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Iterations and ConditionsIterations and conditional operations
can be visually indicated with '*' and '[…]' adornments.
13-26
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Indicating Object Creation
13-27
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Message Icon AdornmentsThe message icon can be
adorned to indicate the synchronization mechanism:
simple
synchronous
balking
timeout
asynchronous
13-28
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Examples of Message Semantics
13-29
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Sequence Diagram Example
13-30
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
Module ReviewIn this module we learned that:
◦sequence diagrams illustrate the detailed message passing between objects
13-31
Principles of Information Systems Analysis & Design Design © 2009 by Dr. Martin Schedlbauer
References Kratochvil, M., & McGibbon, B. (2003). UML xtra-
light: How to Specify Your Software Requirements. Cambridge University Press.◦ A short book on UML that keeps to the essentials. Explains
how to get from use cases to requirements and how to model the requirements with use case, activity, class, and state diagrams.
Fowler, M. (2004). UML Distilled, 3rd Edition. Addison-Wesley Pearson.◦ A great reference book on UML that’s just detailed enough
and not too confusing. Contains an explanation of all UML diagrams and is more geared towards developers.
Object Management Group (2007). UML Specification with UML Activity Diagrams. www.omg.org.
13-32