module 13:

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


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


Using Sequence DiagramsUse sequence diagrams to:

◦document designs of methods and use cases

◦document existing code◦document debug traces

13-4


Sequence Diagram Example

13-5


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


Alternative TermsDifferent methodologies use

various terms to describe methods:◦service◦operation◦responsibility◦member function

13-7


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


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


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


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


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


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


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


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


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


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


Sequence Diagram for a Use Case

Cashie r

Record Sale

Cashier

(from Actors)

SalesRecorder

or

13-18


Sequence Diagram for a Method

Sale

StartStart

calcTotal()

13-19


Showing Object Interactions

Sale 1.. *SaleItem

thePrice= getPrice()

13-20


Showing LoopsSale 1.. *SaleItem

StartStart

loop

calcTotal()

getPrice() :double

13-21


Showing Alternate FlowsSale 1.. *SaleItem

alt

[numItems > 0]

[else]

thePrice= getPrice()

13-22


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


Communication Diagram Example

13-24


Data Flows

Data Flow Tokens

13-25


Iterations and ConditionsIterations and conditional operations

can be visually indicated with '*' and '[…]' adornments.

13-26


Indicating Object Creation

13-27


Message Icon AdornmentsThe message icon can be

adorned to indicate the synchronization mechanism:

simple

synchronous

balking

timeout

asynchronous

13-28


Examples of Message Semantics

13-29


Sequence Diagram Example

13-30


Module ReviewIn this module we learned that:

◦sequence diagrams illustrate the detailed message passing between objects

13-31


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

module 13:

Documents

collaboration diagrams

sequence of steps

sequence of messages

activity diagrams

kinds of diagrams

collaborations diagrams

martin schedlbauer scripts

class methods