Sie sind auf Seite 1von 42

UML (Use Case and

Activity Diagrams)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 1


What is UML?

 Unified Modeling Language


• OMG Standard, Object Management Group
• Based on work from Booch, Rumbaugh, Jacobson
 UML is a modeling language to express and
design documents, software
• Particularly useful for OO design
• Not a process, but some have been proposed
using UML
• Independent of implementation language

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 2


Why use UML?
 Open Standard, Graphical notation for
• Specifying, visualizing, constructing, and documenting
software systems
 Language can be used from general initial design to
very specific detailed design across the entire
software development lifecycle
 Increase understanding/communication of product to
customers and developers
 Support for diverse application areas
 Support for UML in many software packages today
(e.g. Rational, plugins for popular IDE’s like NetBeans,
Eclipse, ArgoUML, etc.)
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 3
Brief History of UML
 Inundated with methodologies in early 90’s
 Booch, Jacobson, Yourden, Rumbaugh
 Booch, Jacobson merged methods 1994
 Rumbaugh joined 1995
 1997 UML 1.1 from OMG includes input from
others, e.g. Yourden
 UML v2.0 current version

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 4


Systems, Models and Views
 A model is an abstraction describing a subset of a
system
 A view depicts selected aspects of a model
 A notation is a set of graphical or textual rules
for depicting views
 Views and models of a single system may overlap
each other
 Examples:
• System: Aircraft
• Models: Flight simulator, scale model
• Views: All blueprints, electrical wiring, fuel system
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 5
UML Models, Views, Diagrams
 UML is a multi-diagrammatic language
• Each diagram is a view into a model
• Diagram presented from the aspect of a particular
stakeholder
• Provides a partial representation of the system
• Is semantically consistent with other views

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 6


UML Models, Views, Diagrams

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 7


Use Cases

 What is a Use Case


 A formal way of representing how a
business system interacts with its
environment
 Illustrates the activities that are
performed by the users of the system
 A scenario-based technique in the UML
 A sequence of actions a system performs that
yields a valuable result for a particular actor.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 8


Use Case Symbols

Use Case
 Actor

Boundary

 Connection

Include relationship
<<include>>

Extend relationship

<<extend>>

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 9


Use Case Analysis

 What is an Actor?
• A user or outside system that interacts
with the system being designed in order to
obtain some value from that interaction
 Use Cases describe scenarios that describe
the interaction between users of the system
(the actor) and the system itself.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 10


Actors

 An Actor is outside or external the


system.
 It can be a:
• Human
• Peripheral device (hardware)
• External system or subsystem
• Time or time-based event
 Represented by stick figure

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 11


Questions for Identifying People
Actors
 Who is interested in the scenario/system?
 Where in the organization is the
scenario/system be used?
 Who will benefit from the use of the
scenario/system?
 Who will supply the scenario/system with this
information, use this information, and remove
this information?
 Does one person play several different roles?
 Do several people play the same role?
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 12
Use Cases
A use case represents a class of functionality
provided by the system as an event flow.

A use case consists of:


 Unique name
 Participating actors
PurchaseTicket
 Entry conditions
 Flow of events
 Exit conditions
 Special requirements
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 13
Use Cases

 Use case diagrams describe what a system


does from the standpoint of an external
observer. The emphasis is on what a system
does rather than how.

 Use case diagrams are closely connected to


scenarios.
 A scenario is an example of what happens
when someone interacts with the system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 14


Use Case Diagram: Example
 Name: Purchase ticket  Event flow:
 Participating actor: 1. Passenger selects the
Passenger number of zones to be
traveled.
Entry condition:
2. Distributor displays

• Passenger standing in the amount due.


front of ticket
3. Passenger inserts
distributor.
money, of at least the
• Passenger has sufficient
amount due.
money to purchase
ticket. 4. Distributor returns
change.
 Exit condition:
5. Distributor issues
• Passenger has ticket.
©Ian Sommerville 2004 ticket.
Software Engineering, 7th edition. Chapter 4 Slide 15
Use Case Components
 The use case has three components.
 The use case task referred to as the use case
that represents a feature needed in a
software system.
 The actor(s) who trigger the use case to
activate.
 The communication line to show how the actors
communicate with the use case.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 16


Use-Case Diagram: Example

A use case diagram is a collection of actors, use cases, and


their communications. Software Engineering, 7th edition. Chapter 4
©Ian Sommerville 2004 Slide 17
Use Case Diagram

 Other Types of Relationships for Use


Cases

• Generalization
• Include
• Extend

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 18


Components of Use Case Diagram

 Generalization Relationship
• Represented by a line and a hollow arrow
• From child to parent

Child use case Parent use case

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 19


Use Case Diagram

 Include Relationship
• Represents the inclusion of the
functionality of one use case within
another
• Arrow is drawn from the base use case to
the used use case
• Write << include >> above arrowhead line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 20


Use Case Diagram

 Extend relationship
• Represents the extension of the use
case to include optional functionality
• Arrow is drawn from the extension use
case to the base use case
• Write << extend >> above arrowhead
line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 21


Example of Relationships

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 22


Use Case Template
Use Case ID:
Use Case Name:
Created By: Last Updated By:
Date Created: Date Last Updated:

Actor:
Description:
Preconditions:
Postconditions:
Priority:
Frequency of Use:
Normal Course of Events:
Alternative Courses:
Exceptions:
Includes:
Special Requirements:
Assumptions:
Notes and Issues:
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 23
Use Case for ATM system

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 24


Activity Diagram

 Activity Diagrams consist of activities, states


and transitions between activities and states
 Activity Diagrams describe
• how activities are coordinated to provide a
service
• the events needed to achieve some operation
• how the events in a single use case relate to one
another
• how a collection of use cases coordinate to create
a workflow for an organization
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 25
Activity Diagram Vs Use Case Diagram
 Use case diagrams are useful at very early phase of
product development where requirements collection is
in progress,
 It is required to identify different use cases and
establish the relation between actors and use cases.
 Activity diagrams are used in much later stage of
product development where it is required to
represent flow of activities involved in a
process/scenario.
 Where an activity is a particular operation of the
system.

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 26


Activity Diagram Vs Use Case Diagram
 The purpose of activity diagram is similar to flow
chart, but activity diagrams are much more richer in
syntax than flow chart.
 Use case diagram looks at the system being developed
as a BLACK BOX and addresses WHAT the system
does and how it interacts with OUTSIDE
systems/actors.
 The activity diagram looks at the system being
developed as a WHITE BOX,
 and addresses HOW the system does the things
described in the use case diagram and shows how the
elements INSIDE the system interact with each
other as well as with the external systems/actors.
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 27
Activity Diagram
 Model business workflows
 Identify candidate use cases, through the
examination of business workflows
 Identify pre- and post-conditions for use
cases
 Model workflows between/within use cases
 Model complex workflows in operations on
objects
 Model in detail complex activities in a high
level activity diagram
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 28
Notation

2. Transition

Activity1()c Activity2()

1. Activities

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 29


Notation - 2

[x>0]
[x>0]

Activity1()c
[x=0] [x=0]
[x<0] [x<0]

3. Decision Diamond

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 30


Notation - 3

4.1 Synch. Bar (Join) 4.2 Splitting Bar (Fork)

{AND}
{OR}
{XOR}

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 31


Notation - 3

Start Marker Stop Marker

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 32


Notation - 4

Developers Testers Markers

Swimlane Swimlane Swimlane

Application/Department/Group/Role Boundaries

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 33


Example: Business Level Activity Diagram of the Library

member Librarian

[borrower]
Find book on shelf

[returning]
[returner]
Wait in queue
[borrowing]

Record return Put book back of shelf

Record borrowing

Prepare for next


member

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 34


Forking and Joining

 Use a synchronization bar to specify


the forking and joining of parallel flows
of control
 A synchronization bar is rendered as a
thick horizontal or vertical line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 35


Fork
 A fork may have one incoming transitions and
two or more outgoing transitions
• each transition represents an independent
flow of control
• conceptually, the activities of each of
outgoing transitions are concurrent
• either truly concurrent (multiple nodes)
• or sequential yet interleaved (one node)

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 36


Join

 A join may have two or more incoming


transitions and one outgoing transition
• above the join, the activities associated with
each of these paths continues in parallel
• at the join, the concurrent flows synchronize
• each waits until all incoming flows have reached
the join, at which point one flow of control
continues on below the join

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 37


Fork

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 38


Activity Diagram:

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 39


Swimlanes
 A swimlane specifies a locus of activities
 To partition the activity states on an activity
diagram into groups
• each group representing the business
organization responsible for those activities
• each group is called a swimlane
 Each swimlane is divided from its neighbor by a
vertical solid line

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 40


Swimlanes
 Each swimlane has a name unique within its
diagram
 Each swimlane may represent some real-
world entity
 Each swimlane may be implemented by one or
more classes
 Every activity belongs to exactly one
swimlane, but transitions may cross lanes

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 41


Activity Diagram

©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 4 Slide 42