Slides - People Server at UNCW - University of North Carolina

advertisement
CSC 550
Overview of the Unified
Modeling Language
Devon M. Simmonds
(UML)
Devon M. Simmonds
Devon M. Simmonds
Computer Science Department, CSC550
Slides obtained from a variety of sources
1
1
Outline
• Introduction to UML
• UML diagrams
– Static/structural diagram types
•
•
•
•
Class diagrams
Object diagrams
Package diagrams
Component diagrams
– Dynamic/behavioral diagram types
•
•
•
•
Devon M. Simmonds
Computer Science Department, CSC550
Use cases
Sequence diagrams
Activity diagrams
State diagrams
2
2
Introduction to UML
• To understand software development – you
must understand the Software Lifecycle.
Software Design
• To maximize
software
lifecycle
benefits,
Requirements Analysis
Implementation
software
must
be
engineered.
Systems Engineering
• Engineering software means, among other Testing
things, shifting from code-centric toDeployment
driven
development.
Evolution
Devon M. Simmonds
Computer Science Department, CSC550
3
Making engineering a ModelDriven Discipline
• Requires a modeling language
– Data Flow Diagrams
– Petri Nets
– Unified Modeling Language (UML)
Devon M. Simmonds
Computer Science Department, CSC550
4
Characteristics of Useful Models
• Abstract
– Emphasize important aspects while removing irrelevant ones
• Understandable
– Expressed in a form that is readily understood by observers
• Accurate
– Faithfully represents the modeled system
• Predictive
– Can be used to answer questions about the modeled system
• Inexpensive
– Much cheaper to construct and study than the modeled system
Devon M. Simmonds
Computer Science Department, CSC550
5
5
The Remarkable Thing About Software
“Software has the rare property that it allows
us to directly evolve models into full-fledged
implementations without changing the
engineering medium, tools, or methods!” Bran Selic
• The model evolves into the system it models
Devon M. Simmonds
Computer Science Department, CSC550
6
6
The Unified Modeling Language
• The UML is a standard diagramming language to
visualize the results of analysis and design.
• UML is a tool
– Learning how to create high-quality models is not equivalent
to learning the UML
– UML is simply a language for expressing models
• The UML is not
– a process or methodology
– an object-oriented analysis and design technique
– a modeling technique
Devon M. Simmonds
Computer Science Department, CSC550
7
7
UML Goals
• Define an easy-to-learn but semantically rich visual modeling
language
• Unify the Booch, OMT, and Objectory modeling languages
• Include ideas from other modeling languages
• Incorporate industry best practices
• Address contemporary software development issues
– scale, distribution, concurrency, executability, etc.
• Provide flexibility for applying different processes
Devon M. Simmonds
Computer Science Department, CSC550
8
8
UML 2.2 Diagram Types
Devon M. Simmonds
Computer Science Department, CSC550
9
9
UML 2.2 Diagram Types
•
•
•
•
•
•
•
•
•
•
Class diagrams
Object diagrams
Component diagrams
Deployment diagrams
Package diagrams
Use case diagrams
Activity diagrams
State machines
Sequence diagrams
etc. 14 types altogether
Devon M. Simmonds
Computer Science Department, CSC550
LINK
UML Specification
10
10
Devon M. Simmonds
Computer Science Department, CSC550
11
11
What is a class?
• A class is a description of a set of objects
that share the same properties
– attributes
– Operations


UML class
Java class
public class Student {
String id;
Address addr;
int graduate (String semester)
Student
Id:Integer
addr:String
graduate(semester:String:int
}
Devon M. Simmonds
Computer Science Department, CSC550
12
What is a class?
• A class is a description of a set of objects
that share the same properties
– attributes
– Operations

Java class

Name
public class Student {
attributes
int id;
String addr;
int graduate (String semester) operations
Class compartments
Student
Id:Integer
addr:String
graduate(semester:String:int
}
Devon M. Simmonds
Computer Science Department, CSC550
13
Structure of a class
• A class has the following structure:
– Name compartment (mandatory)
– Attributes compartment (optional)
– Operations compartment (optional)
• Every class must have a distinguishing
name.
– An object is an instance of a class
– An object of a class must have values
associated with each attribute of the class
Student
Id:Integer
addr:String
graduate(semester:String):int
johnWayne:Student
Id = 2007
addr = “Wild Wild West”
Devon M. Simmonds
Computer Science Department, CSC550
14
Class Notation
name
attributes
operations
Rectangle
Rectangle
height
width
attributes
operations
Rectangle
getArea
resize
Rectangle
height
width
getArea
resize
Devon M. Simmonds
Computer Science Department, CSC550
15
Operations
• An operation is a procedure defined in a class.
• Each operation has a signature and a specification of its
behavior.
– Signature: operation name, a list of argument types and the result
type.
• operationName(parameterName: parameterType …): returnType
– Specification is expressed in terms of pre-and postconditions (the
Object Constraint Language is used for this purpose)
– A method is the implementation of an operation.
Devon M. Simmonds
Computer Science Department, CSC550
16
Attribute & Operations Visibility
ITEM
public
private
protected
package
MEANING
+
#
~
Student
-Id:Integer
-addr:String
+graduate(semester:String):int
Devon M. Simmonds
Computer Science Department, CSC550
17
What is a Class Diagram?
• A class diagram describes a structure of
classes
• Key Question: What are the objects of
interest in the problem/solution space?
– their properties (in terms of attributes and
operations)?
– their relationships?
Devon M. Simmonds
Computer Science Department, CSC550
18
Class Diagram Relationships
• Association
– Aggregation/composition
• Generalization
• Dependency
Devon M. Simmonds
Computer Science Department, CSC550
19
Associations
• Associations represent conceptual relationships
among problem concepts or classes.
• Association properties include
– Multiplicity
– Role
– Constraints
Devon M. Simmonds
Computer Science Department, CSC550
20
Associations
-"direction reading arrow"
-it has no meaning except to indicate direction of
reading the association label
-often excluded
Employee 1
works-for4
1
Company
multiplicity
Association name
Devon M. Simmonds
Computer Science Department, CSC550
21
Multiplicity
*
Student
zero or more;
"many"
Customer
1..*
1..40
Student
one or more
0..1
Rents 6
Student
one to forty
*
5
3, 5, 8
Student
exactly five
Student
exactly three,
five or eight
One instance of a
Customer may be renting
zero or more Videos.
One instance of a Video
may be being rented by
zero or one Customers.
Video
Devon M. Simmonds
Computer Science Department, CSC550
22
Association Multiplicity Examples
Secretary
Person
*
0,3..8
1..**
*
Manager
BoardOfDirectors
Devon M. Simmonds
Computer Science Department, CSC550
23
Association Roles
• When a class is part of an association it plays a role in the relationship.
• You can name the role that a class plays in an association by placing the name
at the class’s association end.
• Formally, a class role is the set of objects that are linked via the association.
class roles
project leader
Person
1
1..*
project member
managed
project
0..1
assigned
project
Project
*
Devon M. Simmonds
Computer Science Department, CSC550
24
Reflexive associations
– It is possible for an association to connect a class to
itself
successor
* Course
*
*
isMutuallyExclusiveWith
*
prerequisite
– Let’s build a class diagram for CSC courses using
this model
Devon M. Simmonds
Computer Science Department, CSC550
25
Class Diagram Nomenclature
• Concepts, objects, instances, links, …
Devon M. Simmonds
Computer Science Department, CSC550
26
An example of a Class Diagram
description of problem concepts
0..1
Rents4
Customer
address
name
phoneNumber
*
VideoStore
Rents-from 4
*
1
address
name
phoneNumber
1..2
HeadOffice
Video
Stocks4
1
*
ID
*branchOffice
The above is part of a domain model for a video rental system
Devon M. Simmonds
Computer Science Department, CSC550
27
Objects and Links
• An object is an instance of a class
• A link is an instance of an association
0..1
Rents4
Customer
address
name
phoneNumber
*
VideoStore
Rents-from 4
*
1
address
name
phoneNumber
1..2
HeadOffice
Video
Stocks4
1
*
ID
*branchOffice
• Can you draw a valid object diagram for this
class diagram?
Devon M. Simmonds
Computer Science Department, CSC550
28
Association: Model to Implementation
Student
*
istakenby
4
Course
enrolls
Class Student {
Course enrolls[4];
}
Class Course {
Student istakenby[];
}
Devon M. Simmonds
Computer Science Department, CSC550
29
29
In-Class Exercise: Associations &
Multiplicities
• Create a class diagram reflecting concepts in a
family system that includes: parents, children,
houses, cars, etc.
Devon M. Simmonds
Computer Science Department, CSC550
30
Aggregation
• Aggregation is a special form of association
– reflect whole-part relationships
• The whole delegates responsibilities to its parts
– the parts are subordinate to the whole
– This is unlike associations in which classes have
equal status
Devon M. Simmonds
Computer Science Department, CSC550
31
UML Forms of Aggregation
• Composition (strong aggregation)
– parts are existent-dependent on the whole
– parts are generated at the same time, before, or after
the whole is created (depending on cardinality at
whole end) and parts are deleted before or at the
same time the whole dies
– multiplicity at whole end must be 1 or 0..1
• (weak) Aggregation
Devon M. Simmonds
Computer Science Department, CSC550
32
Composition – black diamond notation
Window
1
1
scrollbar
Slider
2
1
title
1
Header
body
1
Panel
Composition should be used to express a relationship where
the behavior of Part instances is undefined without being
related to an instance of the Whole. And, conversely, the
behavior of the Whole is ill-defined or incomplete if one or
more of the Part instances are undefined.
Devon M. Simmonds
Computer Science Department, CSC550
33
OO Relationships: Aggregation
Aggregation: expresses a relationship among instances
of related classes. It is a specific kind of ContainerContainee relationship.
Bag
Apples
Milk
It expresses a relationship where an instance of the
Container-class has the responsibility to hold and maintain
instances of each Containee-class that have been created
outside the auspices of the Container-class.
Aggregation should be used to express a more informal
relationship than composition expresses. That is, it is an
appropriate relationship where the Container and its
Containees can be manipulated independently.
[From Dr.David A. Workman]
Devon M. Simmonds
Computer Science Department, CSC550
34
34
Generalization/Specialization
• A generalization (or specialization) is a
relationship between a general concept and
its specializations.
– Objects of specializations can be used anywhere
an object of a generalization is expected (but not
vice versa).
• Example: Polygon and Ellipse are
specializations of Shape
Devon M. Simmonds
Computer Science Department, CSC550
35
Shape
Generalization
Polygon

Ellipse
Spline
Separate Target Style
. ..
Rendering Generalizations

Generalization is rendered as a solid directed line
Shape
with a large open arrowhead.
Shared Target Style


Arrowhead points towards generalization
A discriminator can be used to identify the nature of
specializations
Polygon
Ellipse
Spline
...
Devon M. Simmonds
Computer Science Department, CSC550
36
Generalization
Vehicle
venue
power
power
{overlapping}
WindPowered
Vehicle
Truck
venue
MotorPowered
Vehicle
{overlapping}
Land
Vehicle
Water
Vehicle
Sailboat
Fig. 3-48, UML Notation Guide
Devon M. Simmonds
Computer Science Department, CSC550
37
Devon M. Simmonds
Computer Science Department, CSC550
38
38
In-Class Exercise
• Create a class diagram using the problem description below.
–
A school video library tracking system is to be developed. Videos can be
scientific, religious or general. General videos are classified as miscellaneous,
sports or entertainment. Students and professors can belong to research groups. A
research group must have at least 2 professors. Every student must belong to
some research group. Professors that belong to a research group are called
research professors. Research professors do not teach courses every semester.
Each semester, a student must register for at least one course offered by a
professor in his research group. A student cannot register for courses outside the
subject areas of the research groups in his academic department. A research
group can consist of members with various subject area interests. However,
subject areas are only classified as an area of interest for the group if at least two
members have interest in the area. In general, professors can check out any
number of videos, however, visiting professors can check out at most seven
videos. Unlike regular professors, visiting professors can check out videos for the
duration of only two weeks. Students can check out any number of religious
videos and at most 2 scientific videos. Students can check out only scientific
videos in the subject areas represented in their research groups.
Devon M. Simmonds
Computer Science Department, CSC550
39
Devon M. Simmonds
Computer Science Department, CSC550
40
40
UML Packages
• A package is rendered as a tabbed folder
• A package is a collection of model elements
• A package owns its model elements
– destruction of the package results in destruction of the model elements
– relationship between a model element and its package is a composition
Domain
Shape
Production
SalesPoint
Client
Order Processing
Fill Order
Name in “box”
Ship Order
Name in tab
Use of membership
41
41
symbol
Devon M. Simmonds
Computer Science Department, CSC550
41
Packages as a namespace
Domain
Production
Sales
+Client
OrderProcessing
Fill
Order
Ship
Order
• A package defines a namespace
– A model element belongs to at most one package
– Model elements can be referenced outside of the packages they are
defined in, package1::class1::etc.
• Domain::OrderProcessing::Fill
– These are examples of qualified names.
– A package can contain other packages
• Domain::Production
– Package elements may have public or private visibility only.
Devon M. Simmonds
Computer Science Department, CSC550
42
42
42
Example: package with subpackages
Domain
Core/Misc
Payments
Products
Sales
Authorization
Transactions
Devon M. Simmonds
Computer Science Department, CSC550
43
43
43
Details of Payments Package
Payments
Authorizes-payments-of
1
Payment
1..*
AuthorizationService
Core::Store
ServiceContract
amount
merchantID
Paid-by
1
1
Credit
Payment
CashPayment
amountTendered
Check
Payment
* * *
Check
Authorized-by
1
*
*
address
name
phoneNumber
Check
Authorization
Service
Credit
Authorization
Service
1
Authorized-by
Logs 4
Establishescredit-for 
1
Accounts
Receivable
Establishesidentity-for 
1
1
CreditCard
DriversLicense
expiryDate
number
number
1
1
1
Sales::Customer
Domain::Payments::Payment
Computer Science Department, CSC550
Identifies
- CheckPayments have
CheckPaymentReplies
1
Abused-by4
Devon M. Simmonds
Authorization Transactions::
PaymentAuthorizationReply
- CreditPayments have
CreditPaymentReplies
44
44
Packages of a Business System
Customer Care
Accounts Receivable
Order Processing
Marketing
Package can have dependencies on other packages
Devon M. Simmonds
Computer Science Department, CSC550
45
45
Dependencies in UML
• A dependency is a client-server relationship
between model elements.
• A dependency is shown as a dashed arrow
between two model elements.
– The server is at the arrowhead.
– The arrow may be labeled with an optional
stereotype.
Devon M. Simmonds
Computer Science Department, CSC550
46
46
Dependencies Notation in UML
Devon M. Simmonds
Computer Science Department, CSC550
47
47
Devon M. Simmonds
Computer Science Department, CSC550
48
48
Interfaces in UML
• An interface is a named collection of operations
that represent the services provided by a class or
component.
• Interfaces do not typically have attributes.
• Interfaces do not provide implementations for
their operations.
Devon M. Simmonds
Computer Science Department, CSC550
49
49
Example of an interface
Interface
operation1( ) : Type1
operation2( ) : Type2
operation3( ) : Type3
operation4( ) : Type4
operation5( ) : Type5
Devon M. Simmonds
Computer Science Department, CSC550
50
50
UML Notation for Interfaces
Usage Dependency
Realization Dependency
• An interface may be identified using the <<interface>> keyword
preceding the name of the interface.
• Classes that use the interface can have two types of relationships or
dependencies
– Interface realization
– Usage
Devon M. Simmonds
Computer Science Department, CSC550
51
51
UML Notation for Interfaces
Usage
Interface Realization
• Interface realization means ProximitySensor implements the operations
defined by ISensor.
– ISensor is called a provided interface for ProximitySensor.
• Interface usage means TheAlarm uses the operations defined by
ISensor.
– ISensor is called a requiredinterface for TheAlarm.
Devon M. Simmonds
Computer Science Department, CSC550
52
52
Interfaces: Dependency
Provided Interface
Realization Dependency
Devon M. Simmonds
Computer Science Department, CSC550
Required Interface
Usage Dependency
53
53
Interfaces: Dependency
“Ball-and-socket” notation
Required Interface
Usage Dependency
Provided Interface
Realization Dependency
ISensor
Devon M. Simmonds
Computer Science Department, CSC550
54
54
UML packages - core concepts
Construct
Description
Package
A grouping of model elements.
Import
A dependency indicating that the public
contents of the target package are added to
the namespace of the source package.
Access
A dependency indicating that the public
contents of the target package are available
in the namespace of the source package.
Merge
A dependency indicating that the public
contents of the target package are added to
the namespace of the source package.
Devon M. Simmonds
Computer Science Department, CSC550
Syntax
Name
«import»
«access»
«merge»
55
55
Devon M. Simmonds
Computer Science Department, CSC550
56
56
Devon M. Simmonds
Computer Science Department, CSC550
57
57
Component definitions
• Szyperski:
– A software component is a binary units of independent production,
acquisition and deployment that interact to form a functioning system
– A software component is a unit of composition with contractually
specified interfaces and explicit context dependencies only. A software
component can be deployed independently and is subject to
composition by third-parties.
• Councill and Heinmann:
– A software component is a software element that conforms to a
component model and can be independently deployed and composed
without modification according to a composition standard.
Devon M. Simmonds
Computer Science Department, CSC550
58
COMPONENT NOTATION

A component is shown as a rectangle


Labelled with a stereotype <<component>>
Optionally, in the right hand corner a
component icon can be displayed


A component icon is a rectangle with two
smaller rectangles jutting out from the left-hand
side
This symbol is a visual stereotype
Devon M. Simmonds
Computer Science Department, CSC550
59
Component ELEMENTS
• A component can have
– Interfaces
An interface represents a declaration of a set of
operations and obligations
– Usage dependencies
A usage dependency is relationship which one element
requires another element for its full implementation
– Ports
Port represents an interaction point between a component
and its environment
– Connectors
• Connect two components
• Connect the external contract of a component to the
internal structure
Devon M. Simmonds
Computer Science Department, CSC550
60
INTERFACE
• May be shown using a rectangle
symbol with a keyword
<<interface>> preceding the name
• For displaying the full signature,
the interface rectangle can be
expanded to show details

Can be
 Provided
 Required
Devon M. Simmonds
Computer Science Department, CSC550
61
INTERFACE
• A provided interface
– Characterize services that the
component offers to its environment
– Is modeled using a ball, labelled with
the name, attached by a solid line to the
component

A required interface



Characterize services that the component expects from its
environment
Is modeled using a socket, labelled with the name, attached by a
solid line to the component
In UML 1.x were modeled using a dashed arrow
Devon M. Simmonds
Computer Science Department, CSC550
62
INTERFACE
• Where two components/classes provide and require
the same interface, these two notations may be
combined


The ball-and-socket notation hint at that interface in
question serves to mediate interactions between the two
components
If an interface is shown using the rectangle symbol, we can
use an alternative notation, using dependency arrows
Devon M. Simmonds
Computer Science Department, CSC550
63
DEPENDENCIES

Components can be
connected by usage
dependencies
• Usage Dependency
– A usage dependency is relationship which one
element requires another element for its full
implementation
– Is a dependency in which the client requires the
presence of the supplier
– Is shown as dashed arrow with a <<use>> keyword
– The arrowhead point from the dependent
component to the one of which it is dependent
Devon M. Simmonds
Computer Science Department, CSC550
64
PORT




Specifies a distinct interaction point
 Between that component and its environment
 Between that component and its internal parts
Is shown as a small square symbol
Ports can be named, and the name is
placed near the square symbol
Is associated with the interfaces that
specify the nature of the interactions that
may occur over a port
Devon M. Simmonds
Computer Science Department, CSC550
65
PORT
• Ports can support unidirectional communication or
bi-directional communication

If there are multiple interfaces
associated with a port, these
interfaces may be listed with the
interface icon, separated by a
commas
Devon M. Simmonds
Computer Science Department, CSC550
66
PORT
– All interactions of a component with its
environment are achieved through a port
– The internals are fully isolated from the
environment
– This allows such a component to be used in any
context that satisfies the constraints specified by
its ports
– Ports are not defined in UML 1.x
Devon M. Simmonds
Computer Science Department, CSC550
67
EXTERNAL VIEW

A component have an external view and an internal view
• An external view (or black box
view) shows publicly visible
properties and operations


An external view of a component is
by means of interface symbols
sticking out of the component box
The interface can be listed in the
compartment of a component box
Devon M. Simmonds
Computer Science Department, CSC550
68
INTERNAL VIEW
• An internal, or white box
view of a component is
where the realizing
classes/components are
nested within the
component shape

Realization is a relationship between two set of
model elements
 One represents a specification
 The other represent an implementation of the
latter
Devon M. Simmonds
Computer Science Department, CSC550
69
INTERNAL VIEW
• The internal class that realize the
behavior of a component may be
displayed in an additional
compartment


Compartments can also be used to
display parts, connectors or
implementation artifacts
An artifact is the specification of a
phisycal piece of information
Devon M. Simmonds
Computer Science Department, CSC550
70
INTERNAL VIEW

Components can be built recursively
Devon M. Simmonds
Computer Science Department, CSC550
71
Devon M. Simmonds
Computer Science Department, CSC550
72
72
In-Class Exercise
• Create a component diagram using the problem description below.
Identify required and provided interfaces and list the methods
signatures.
–
A school video library tracking system is to be developed. Videos can be
scientific, religious or general. General videos are classified as miscellaneous,
sports or entertainment. Students and professors can belong to research groups. A
research group must have at least 2 professors. Every student must belong to
some research group. Professors that belong to a research group are called
research professors. Research professors do not teach courses every semester.
Each semester, a student must register for at least one course offered by a
professor in his research group. A student cannot register for courses outside the
subject areas of the research groups in his academic department. A research
group can consist of members with various subject area interests. However,
subject areas are only classified as an area of interest for the group if at least two
members have interest in the area. In general, professors can check out any
number of videos, however, visiting professors can check out at most seven
videos. Unlike regular professors, visiting professors can check out videos for the
duration of only two weeks. Students can check out any number of religious
videos and at most 2 scientific videos. Students can check out only scientific
videos in the subject areas represented in their research groups.
Devon M. Simmonds
Computer Science Department, CSC550
73
Devon M. Simmonds
Computer Science Department, CSC550
74
74
DEPLOYMENT DIAGRAMS

There is a strong link between components diagrams and
deployment diagrams
• Deployment diagrams
– Show the physical relationship between hardware
and software in a system
– Hardware elements:
• Computers (clients, servers)
• Embedded processors
• Devices (sensors, peripherals)
– Are used to show the nodes where software
components reside in the run-time system
Devon M. Simmonds
Computer Science Department, CSC550
75
DEPLOYMENT DIAGRAMS

Deployment diagram
 Contains nodes and connections
 A node usually represent a piece of hardware in the
system


A connection depicts the
communication path used by
the hardware to
communicate
Usually indicates the method
such as TCP/IP
Devon M. Simmonds
Computer Science Department, CSC550
76
DEPLOYMENT DIAGRAMS


Deployment diagrams
contain artifact
An artifact
 Is the specification of a
phisycal piece of
information
 Ex: source files, binary
executable files, table in a
database system,….
 An artifact defined by the
user represents a
concrete element in the
physical world
Devon M. Simmonds
Computer Science Department, CSC550
77
DEPLOYMENT DIAGRAMS
• An artifact manifest one or more model elements
• A <<manifestation>> is the concrete physical of one
or more model elements by an artifact
• This model element often is a component

A manifestation is notated
as a dashed line with an
open arrow-head labeled
with the keyword
<<manifest>>
Devon M. Simmonds
Computer Science Department, CSC550
78
DEPLOYMENT DIAGRAMS
Devon M. Simmonds
Computer Science Department, CSC550
79
Devon M. Simmonds
Computer Science Department, CSC550
80
80
Use Cases

A use case is the specification of a set of
actions performed by a system, which yields
an observable result that is, typically, of
value for one or more actors or other
stakeholders of the system – UML Specification
Devon M. Simmonds
Computer Science Department, CSC550
81
81
Use Case Diagram Example
Online HR System
Locate
Employees
Update
Employee
Profile
Manager
{if currentMonth = Oct.}
Update Benefits
Employee
Healthcare Plan System
{readOnly}
Access Travel
System
Access Pay
Records

Insurance Plan System
UML 2.0 Use Case Terminology

A use case describes interactions between users (clients) and a subject

At the requirements level the subject is the system under development
 E.g. a system, a subsystem in a system, or a class
Devon M. Simmonds
Computer Science Department, CSC550
82
82
Online HR System: Update Benefits Use
Case
Actors
: employee, healthcare plan system, insurance plan system
Precondition:
Employee has logged on to the system and selected ‘update benefits’
option

Basic

course
System displays employee account
System asks employee to select medical plan type; include Update
Medical Plan.

System asks employee to select dental plan type; include Update
Dental Plan.
 …
 System asks user to select benefits options: benefit options
 reimbursement option selected: Elect Reimbursement for
Healthcare
 stock option selected: Elect Stock Purchase
83

Devon M. Simmonds
Computer Science Department, CSC550
83
Use Cases in UML: Core Elements
Construct Description
use case
actor
A sequence of actions, including
variants, that a system (or other
entity) can perform, interacting with
actors of the system.
A role played by an entity that
interacts with the subject (e.g.,
system, subsystem, class).
Syntax
UseCaseName
ActorName
System/sub Represents the boundary between
ject
the subject and the actors who
boundary
interact with the subject.
Subject
Devon M. Simmonds
Computer Science Department, CSC550
The system under consideration to which the use
cases apply, e.g. system, subsystem or class.
84
84
Depicting actors
NextGen
Process Sale
...
«system»
Payment
Authorization
Service
Payment
Authorization
Service
«actor»
Payment
Authorization
Service
Some UML alternatives to
illustrate external actors that
are other computer systems.
The class box style can be
used for any actor, computer or
human. Using it for computer
actors provides visual
distinction.
Payment
Authorization
Service
Devon M. Simmonds
Computer Science Department, CSC550
85
85
Actors & Use Case Diagrams
system boundary
communication
NextGen POS
Process Sale
Customer
Payment
Authorization
Service
alternate
notation for
a computer
system actor
Handle Returns
actor
«actor»
Tax Calculator
Cashier
Cash In
«actor»
Accounting
System
Analyze Activity
«actor»
HR System
Manager
«actor»
Sales Activity
System
Manage Security
System
Administrator
Manage Users
use case
...
Devon M. Simmonds
Computer Science Department, CSC550
86
86
Two-Column Use Case Example
Actor Inputs
System Response
1. Customer submits identification 2. If customer is authenticated,
information
then request rental items
3. Customer submits items to be
rented
4. Display calculated price.
5.
6. Inform customer that
payments is authorized
Customer pays.
Item Rental Use Case
Devon M. Simmonds
Computer Science Department, CSC550
87
87
Use Case Modeling: Core Relationships
Construct
Description
association
The participation of an actor in a use
case. i.e., instance of an actor and
instances of a use case communicate
with each other.
A taxonomic relationship between a
more general use case and a more
specific use case.
A relationship from an extension use
case to a base use case, specifying
how the behavior for the extension
use case augments (subject to
conditions in the extension) the
behavior defined for the base use
case. The base use case does not
depend on the extension use case.
Compare: include.
a relationship from a base use case to
an inclusion use case, specifying how
the behavior for the base use case
contains the behavior defined for the
inclusion use case. The base use
case depends on the inclusion use
case. Compare: extend.
generalization
extend
include
Devon M. Simmonds
Computer Science Department, CSC550
Syntax
<<extend>>
<<include>>
88
88
Devon M. Simmonds
Computer Science Department, CSC550
89
89
In-Class Use Case Exercise
• Create a use case diagram using the problem description below. Create
a detailed use case for one use case from the diagram.
–
A school video library tracking system is to be developed. Videos can be
scientific, religious or general. General videos are classified as miscellaneous,
sports or entertainment. Students and professors can belong to research groups. A
research group must have at least 2 professors. Every student must belong to
some research group. Professors that belong to a research group are called
research professors. Research professors do not teach courses every semester.
Each semester, a student must register for at least one course offered by a
professor in his research group. A student cannot register for courses outside the
subject areas of the research groups in his academic department. A research
group can consist of members with various subject area interests. However,
subject areas are only classified as an area of interest for the group if at least two
members have interest in the area. In general, professors can check out any
number of videos, however, visiting professors can check out at most seven
videos. Unlike regular professors, visiting professors can check out videos for the
duration of only two weeks. Students can check out any number of religious
videos and at most 2 scientific videos. Students can check out only scientific
videos in the subject areas represented in their research groups.
Devon M. Simmonds
Computer Science Department, CSC550
90
Devon M. Simmonds
Computer Science Department, CSC550
91
91
Overview
• A sequence diagram Models sequential logic, an
ordered sequence of interactions between objects
– Interaction/sequence diagrams allow one to view only
the parts of a system involved in accomplishing use case
goals.
Devon M. Simmonds
Computer Science Department, CSC550
92
92
A class diagram for
Registration Application
Course
getPrerequisite
*
1
Student
* Registration *
CourseSection
requestToRegister
addToRegistrationList
a
1
Student
1
addToSchedule
hasPassedCourse
Diagram shows structure not behaviour.
Devon M. Simmonds
Computer Science Department, CSC550
93
93
Sequence diagrams
:CourseSection
requestToRegister
<<create>>
:Student
:Registration
addToRegistrationList
addToSchedule
•A sequence diagram shows the sequence of messages exchanged by the set
of objects performing a certain task
– The objects are arranged horizontally across the diagram.
– An actor that initiates the interaction is often shown on the left.
– The vertical dimension represents time.
– A vertical line, called a lifeline, is attached to each object or actor.
– The lifeline becomes a broad box, called an activation box during the live
activation period.
– A message is represented as an arrow between activation boxes of the
sender and receiver.
• A message is labelled and can have an argument list and a return value.
Devon M. Simmonds
Computer Science Department, CSC550
94
94
Sequence Diagram: basic constructs
object symbol
lifeline
objectName : Class
other:Type
message
m1()
name (…)
activation
new (…)
: Class
delete
return
Devon M. Simmonds
Computer Science Department, CSC550
create
95
95
Different kinds of arrows
Procedure
call or other kind of
nested flow of control
Synchronous -
Return
Asynchronous, flat
flow
Devon M. Simmonds
Computer Science Department, CSC550
96
96
Extended sequence diagram example
GUI
requestToRegister()
:CourseSection
aStudent:
Student
requestToRegister(aStudent)
:Course
prereq :=
hasPrerequisite:= hasPassedCourse(prereq)
getPrerequisite()
[hasPrerequisite]<<create>>
:Registration
addToRegistrationList()
Devon M. Simmonds
Computer Science Department, CSC550
addToSchedule()
97
97
A more complex Sequence Diagram
(UML 2.0)
Frame and Name
sd GoHomeSetup
Lifeline is an object
:ServiceUser
ref
:ServiceBase
ref SB_GoHomeSetup
:ServiceTerminal
Authorization
sd Authorization
Interaction Occurrence
opt
:ServiceBase
ref SB_Authorization
:ServiceUser
ref
Combined Fragment
FindLocation
:ServiceTerminal
Code
OK
SetHome
OnWeb
OK
Plain asynchronous
message
Devon M. Simmonds
Computer Science Department, CSC550
SetInvocationTime
SetTransportPreferences
98
98
Combined Fragment
Devon M. Simmonds
Computer Science Department, CSC550
99
99
Combined fragment interaction operators
• Alternatives (alt)
– choice of behaviors – at most one will execute
– depends on the value of the guard (“else” guard supported)
• Option (opt)
– Special case of alternative
• Break (break)
– Represents an alternative that is executed instead of the
remainder of the fragment (like a break in a loop)
• Parallel (par)
– Concurrent (interleaved) sub-scenarios
• Negative (neg)
– Identifies sequences that must not occur
Devon M. Simmonds
Computer Science Department, CSC550
100
100
Combined fragment interaction operators
• Critical Region (region)
– Traces cannot be interleaved with events on any of
the participating lifelines
• Loop (loop)
– Optional guard: [<min>, <max>, <Booleanexpression>]
– No guard means no specified limit
Devon M. Simmonds
Computer Science Department, CSC550
101
101
Local variables:money transfer sequence
diagram
Local variables
Devon M. Simmonds
Computer Science Department, CSC550
102
102
• Create a sequence diagram for withdrawing
money from an account
– When withdrawing money from his account, John
inserts his card and inputs his password. He then
selects the account from which to withdraw money
and enters the amount of money to withdraw. He
then collects his money and receipt.
Devon M. Simmonds
Computer Science Department, CSC550
103
103
Devon M. Simmonds
Computer Science Department, CSC550
104
104
State Models
• A state model specifies the life histories of objects in
terms of the sequences of operations that can occur in
response to external stimuli.
– For example, a state model can describe how an object
responds to a request to invoke one of its methods.
• A state model consists of state diagrams that each
describes how an object responds to external stimuli.
• A state diagram describes behavior in terms of
sequences of states that an object can go through in
response to events.
Devon M. Simmonds
Computer Science Department, CSC550
105
105
Simple Example: Telephone Object
initial state
state
Idle
event
lift receiver/ get dial
tone
Activity that is
performed during
transition: it
executes
instantaneously
Devon M. Simmonds
Computer Science Department, CSC550
caller hangs up /
disconnect
Active
•When the object is created, it moves into
the Idle state.
•If a “lift receiver” event is received the
object moves from the Idle to the Active
state. During the transition the “get dial
tone” activity is executed.
•If a “caller hangs up” event occurs when
in Active state, the object moves to the
Idle state and the “disconnect” activity is
performed during the transition.
106
106
Basic UML State Diagram
“top” state
Initial
state
State
top
Event
Ready
Transition
stop /ctr := 0
Final
state
Devon M. Simmonds
Computer Science Department, CSC550
Done
Activity
stop
107
107
Guards
• Conditional execution of transitions
– guards (Boolean predicates) must be side-effect free
bid [value < 100] /reject
bid [value >= 200] /sell
Happy
Selling
bid [(value >= 100) & (value < 200)] /sell
Unhappy
Devon M. Simmonds
Computer Science Department, CSC550
108
108
Event Types
•
ChangeEvent: Occurs when a condition expressed as a boolean expression
becomes true.
– when condition
• Examples: when(temperature > 80); when(balance < 0)
•
SignalEvent: Occurs when an signal is sent or received, where a signal is a
one-way transmission of information from one object to a target object.
– Event(param1,param2,…)
• Examples: lift receiver; hang-up telephone
•
TimeEvent: Passage of a specific period of time after a designated event, or
an occurrence of a specified time instance.
– Passage of time since entry to current state - after (time period) , e.g., after (10
secs), after (5 secs since exit of state A)
– Occurrence of a time instance – when(due-date=Feb 28, 2005, 11pm)
Devon M. Simmonds
Computer Science Department, CSC550
109
109
Active Objects and State Diagrams
If object is in the created state and a start event occurs, it sends a method
invocation event (request to invoke ready()) to the object named master
and moves to state ready.
anActiveObject
#currentEvent : Eventpoll/defer
created
start
+ start ( )
+ poll ( )
+ stop ( )
start/^master.ready()
ready
ready
stop/
poll/^master.ack()
Devon M. Simmonds
Computer Science Department, CSC550
110
110
Active Objects: Dynamic Semantics
ActiveObject:
Run-to-completion model:
•Events are queued
•An object processes events in a queue one at a time.
•An object cannot suspend handling of an event to handle
another event
Devon M. Simmonds
Computer Science Department, CSC550
111
111
The Run-to-Completion Model
• A high priority event for (another) active object will
preempt an active object that is handling a low-priority
event on a uniprocessor
Event is queued
because object is
handling the lo event
Active1
Active2
lo
hi
hi
Object, Active1, has
its activity suspended
so that the Active2
object can respond to
hi
Devon M. Simmonds
Computer Science Department, CSC550
112
112
Devon M. Simmonds
Computer Science Department, CSC550
113
113
State Representations
StateName
activity
executed when
state is entered
activity
executed when
event occurs
while in state
Devon M. Simmonds
Computer Science Department, CSC550
activity
executed when
state is exited
StateName
Att1 : Attrib1
entry/action
exit/action
event/action
activity
executed while
in state
do/action
114
114
State Syntax - Submachines
Dispense cash: Cash Dispenser
• State name:submachine
– submachine is the name of a (nested) state machine that has an
initial and final state.
– Execution of the nested machine begins in the initial state.
– When final state of the nested machine is reached then the exit
action of the parent state is executed (if it exists).
Devon M. Simmonds
Computer Science Department, CSC550
115
115
UML 2.0: Entry/Exit Points
• Encapsulation of submachines
ReadAmountSM
abort
selectAmount
definition of
exit point
otherAmount
amount
EnterAmount
abort
aborted
ok
again
Devon M. Simmonds
Computer Science Department, CSC550
definition of
entry point
116
116
Entry/Exit Points: Usage
ATM
VerifyCard
use of
exit point
acceptCard
outOfService
OutOfService
ReadAmount :
ReadAmountSM
aborted
again
rejectTransaction
use of
entry point
Devon M. Simmonds
Computer Science Department, CSC550
VerifyTransaction
releaseCard
ReleaseCard
117
117
Deferred Events
• Events can be retained if they do not trigger a transition
– The event is put to the top of the queue; it must be handled in
the next event handling cycle
LampOff
Deferred event
entry/lamp.off()
off/defer
off/
on/
LampOn
entry/lamp.on()
Devon M. Simmonds
Computer Science Department, CSC550
118
118
Order of Actions: Complex Case
• Same approach as for the simple case
S1
exit/exS1
S2
entry/enS2
initS2
S11
exit/exS11
E/actE
S21
entry/enS21
Actions execution sequence:
exS11  exS1  actE  enS2  initS2  enS21
Devon M. Simmonds
Computer Science Department, CSC550
119
119
• Create a state diagram for
managing student information
in a university setting.
Devon M. Simmonds
Computer Science Department, CSC550
120
120
Devon M. Simmonds
Computer Science Department, CSC550
121
121
Workflow modelling
is done typically done
during System
Engineering and
requirements analysis
Devon M. Simmonds
Computer Science Department, CSC550
122
Workflow Modeling
• Workflow modeling is performed by:
– Gathering data using interviews, etc.
– Analyzing the information
– Modeling the information using an activity diagram.
Devon M. Simmonds
Computer Science Department, CSC550
123
123
Activity Models:
describing business work flows
Devon M. Simmonds
Activity diagram of an order processing system
Computer Science Department, CSC550
124
124
Activity Models
An Activity diagram
Join
Fork
Decision node
Merge node

An activity is a structure of actions containing:



Initial node
Action nodes – may have incoming and outgoing activity
edges representing data flow or control flow
Object nodes – represents artifacts produced by actions
Control nodes – used to manage and order action and
object nodes.
Devon M. Simmonds
Computer Science Department, CSC550
Flow final node
Activity final node
125
125
Activity Diagrams:
describing business work flows
Devon M. Simmonds
Activity diagram of an order processing system
Computer Science Department, CSC550
126
126
Activity Diagrams: actions with constraints
Format of Actions
Devon M. Simmonds
Computer Science Department, CSC550
An Example
127
127
Accept/Request Signals
Accept signal indicating cancellation of an order
Acceptance of the signal invoke the cancellation behavior
Action is enabled on entry on the activity containing it.







Request signal sent after an order is processed
Activity waits to receive a payment confirmed signal.
When confirmation is received, the order is shipped
Acceptance of payment confirmed signal is enabled only
after request for payment is sent.
Devon M. Simmonds
Computer Science Department, CSC550
128
128
Edges
OR
Example of an edge with a name
Devon M. Simmonds
Computer Science Department, CSC550
129
129
Edges with Weights
Cricket team example
Proposal bids example
Devon M. Simmonds
Computer Science Department, CSC550
130
130
Activity Models: activity notation
An activity is a structure of actions
Devon M. Simmonds
Computer Science Department, CSC550
131
131
Modeling activities
An activity is a structure of actions
Devon M. Simmonds
Computer Science Department, CSC550
132
132
Another example
[else]
Devon M. Simmonds
Computer Science Department, CSC550
133
133
Expanding Activities
OR
Expanding an activity / invoking an activity with nodes and edges.
Devon M. Simmonds
Computer Science Department, CSC550
134
134
Expanding activities
Activity expanded
Devon M. Simmonds
Computer Science Department, CSC550
135
135
Connectors
Devon M. Simmonds
Computer Science Department, CSC550
136
136
Activity Final Nodes vs. Flow Final Nodes
Devon M. Simmonds
Computer Science Department, CSC550
137
137
Partitions/Swimlanes
Devon M. Simmonds
Computer Science Department, CSC550
138
138
Partitions using annotations
Devon M. Simmonds
Computer Science Department, CSC550
139
139
Dimensional partitions
Devon M. Simmonds
Computer Science Department, CSC550
140
140
Timers
Devon M. Simmonds
Computer Science Department, CSC550
141
141
Interrupts
Devon M. Simmonds
Computer Science Department, CSC550
142
142
Input/Output pins
A pin represent an input or output data node
Devon M. Simmonds
Computer Science Department, CSC550
143
143
Exceptions
Devon M. Simmonds
Computer Science Department, CSC550
144
144
• Develop an Activity Diagram
for requesting money from an
ATM machine.
Devon M. Simmonds
Computer Science Department, CSC550
145
145
Summary
• UML diagrams
– Static/structural diagram types
•
•
•
•
Class diagrams
Object diagrams
Package diagrams
Component diagrams
– Dynamic/behavioral diagram types
•
•
•
•
Use cases
Sequence diagrams
Activity diagrams
State diagrams
Devon M. Simmonds
Computer Science Department, CSC550
146
CSC550, Devon M. Simmonds, Computer Science Department, University of North Carolina Wilmington
Q u
e s
t i
o n
???????????????
s ?
CSC550 ……
Devon M. Simmonds
Computer Science Department, CSC550
The End
147
•
State
Model
exercise
Complete state machine for a student information system.
award [accepted] /
Applicant
reapply
Accepted
register
award [rejected]
Registered
register
addCourse
unregistered
Rejected
Inactive
program-completed
Active
Graduate
addCourse
reapply
program-terminated
after: one semester
Dismissed
no-reapplication
no-reapplication
award-presented
Devon M. Simmonds
Computer Science Department, CSC550
148
148
Download