Transcript UML Diagram

UML Diagrams
(Unified Modeling Language)
C.Thomas Wu.Introduction to O-O
Programming
UML Diagram Introduction
Graphical notations are useful and straightforward in displaying information about a
system design.
Three gurus Booch, Rumbaugh, and
Jacobson developed the UML diagrams
C.Thomas Wu.Introduction to O-O
Programming
UML
• Models various aspects of software
development for OO systems
• Includes several types of diagrams
– Class
– Use Case
– Collaboration
– Sequence
– State
– Activity
C.Thomas Wu.Introduction to O-O
Programming
Class Diagrams (are static)
• Are one of the most significant diagram of the
UML diagrams used by software developers
• Are used to create logical models of the
computer-based systems
• Show data members, methods, and the static
relationships between the classes that are used
to build the system. The relationships are also
called associations
C.Thomas Wu.Introduction to O-O
Programming
Basic UML Class and Object Diagram
Person
Explanations:
Class Name
-firstName
-lastName
-age
Private Data Members (named
property of a class usually a
noun)
(- symbol)
+Person()
+Person( firstName,
lastName, age)
+getFirstName():String
+setFirstName(firstName:String): void
+getLastName():String
+setLastName(lastName:String): void
+getAge(): int
+setAge(age:int): void
#anyMethod():void
+getNumberofObjects():int
Constructors default and
non-default
Public Methods (+symbol)
(usually a verb)
Protected Methods (# symbol)
Static Methods (+ symbol and
underlined)
C.Thomas Wu.Introduction to O-O
Programming
Class Diagrams - Data Types and Parameters
• Sometimes the data type of attributes and
parameters, and return types are not
shown on the class diagram.
• If you see just the aMethodName(), don’t
assume that there is no parameters for the
method. Sometimes they are omitted to
save space.
C.Thomas Wu.Introduction to O-O
Programming
Class Diagram for Premiere Products
Database - Source: Adamski and Pratt
Class Diagram with Constraints
Source: Pratt and Adamski
Class Diagram with a
1. Generalization (super class) and a
2. Specialization (subclass) with a
Constraint
Source: Pratt and Adamski
Building a Specification Model
• The OO way of modeling reality does not
try to organize all of reality
• We usually try to model only the relevant
features of a specific application domain
select a manageable domain
• One way of bounding the domain is to
use Use Cases
• The main purpose of use case modeling
is to understand the external behavior of
the system. The later stages will be easier
if up-front requirements are clear and
unambiguous
C.Thomas Wu.Introduction to O-O
Programming
One of the values of use cases is that they ease
the discussions between stakeholders and
analysts/developers.
They are usually written using business terms
known to the majority of the stakeholders
C.Thomas Wu.Introduction to O-O
Programming
Use Cases
• Uses cases capture the functional
requirements and the business-value
propositions of a proposed system -along
with its high-level processes needed to
achieve these specific value propositions
• A used case is a generic description of an
entire transaction involving several
objects (Lee and Tepfenhart)
C.Thomas Wu.Introduction to O-O
Programming
Building a Specification Model
• A use case:
– Specifies a sequence of actions, including variants,
that a system performs and that yields an
observable result of value to an actor (Jacobson,
Booch, Rumbaugh)
– Is a description of all the possible sequences of
interactions among the system and one or more
actors in response to some initial stimulus by one of
the actors (Rumbaugh)
– Is a collection of possible sequences of interactions
between the system under discussion and its
external actors, related to a particular goal
(Cockburn) C.Thomas Wu.Introduction to O-O
Programming
Use Cases
• Uses cases are concerned with the actors and
the sequences of interactions between them
• Some important concepts include:
– The goal - the business value to the user(s)
– The system - the application with all the
hardware that will be used by the “users”
– An actor – external entity that interacts with
the system -represented by a labeled stick
figures
– Use case – describes an interaction that
achieves a goal for an actor
– Use-case bundle – a collection of used
cases that are highly correlated with some
activity or organizing
business
element
C.Thomas Wu.Introduction
to O-O
Programming
Use Cases
Programmers use Use Cases to develop test
plans
• The Goal
– use cases describe in a formal way how a computer
system works from an external view
– to capture a scenario that completes to some point
the business value of the user’s view
– To model the system functional requirements
• The System
– Usually viewed as a “black-box” system -the user
cannot see the system inner workings. The user
verifies that the system behaves the way it is
suppose to no matter how it is built.
C.Thomas Wu.Introduction to O-O
Programming
Use Cases –Information Captured
• The Actors
– Uses cases divide the world into two parts: the
system and the users (actors)
– Actors are a way of classifying system users who
share a set of common interactions to achieve a
goal
– An actor represents an external entity that can
initiate actions or receive requests from the system
– A specific user is an instance of an actor
– The set of requests/responses from/to the actors
represents the system boundaries
C.Thomas Wu.Introduction to O-O
Programming
Use Cases
• Use Case and Scenario
– A use case describes a system in terms of
sequences of interactions between various actors
and the system
– A scenario is a short narrative that outlines a
sequence of requests and responses between a
user and the system –what happens next
– A scenario describes how a user will use the system
to achieve a goal
– A use case is the generalized form of a family of
scenarios
– A scenario is a specific instance of a use case
C.Thomas Wu.Introduction to O-O
Programming
Use Cases
• The Use Case describes
– The pre-conditions that must exist for the
used case to be successfully invoked
– The post-conditions that define the state of
the system after the use case is concluded
– Detailed business logic that is performed
(non-technology-dependent)
– Business exceptions that can occur
required data not location, computations
aborted
– Business constraints that apply to the
system when reacting to a specific user
request –resource
allocation not available
C.Thomas Wu.Introduction to O-O
Programming
Use Cases
• To effectively capture the functional aspects of
a system the description of the system must be
kept at a consistent level of abstraction
• To successfully develop use cases we must
know the dimension of the functional
description we are trying to capture
• These dimensions include:
– High-level and low-level
– Primary and secondary
– Essential and concrete
Richard C. Lee and William M.
Tepfenhart
Use Cases
• High-level functional descriptions
– Provide general and brief descriptions of the
essence of the business values provided by
the system- No concern of how to achieve
the business values
• Low-level functional descriptions
– Provide details showing the exact order of
activities, tasks, or alternatives
Richard C. Lee and William M.
Tepfenhart
Use Cases
• Primary functions
– Describe the essential functionality provided to the
user – the reason the system exists
• Secondary functions
– Deal with rare and exceptional cases –necessary to
deliver a robust system
• Essential functions
– Describe business solutions that are independent of
implementation (Hardware and software -black-box
implementation is done in total ignorance of how the
object was constructed)
• Concrete functions
– Describe use cases that are design dependent
(clear-box)
Richard C. Lee and William M.
Tepfenhart
High-level, primary, essential use case diagram
Course Registration System
Register
Student
Drop Course
Add Course
Cancel Course
Admin
Delete Course
Richard C. Lee and William M.
Tepfenhart
Prof
Template for Documenting Use Cases – Textual Description
Description:
A one or two sentence
description of the use
case – a descriptive
name
Actors
Identifies the actors
participating in the use
case
Includes
Identifies the use cases
included in it
Extends
Identifies the use cases
that it may extend
Pre-Conditions
Identifies the conditions
that must be met to
invoke this use case
Richard C. Lee and William M.
Tepfenhart
Template for Documenting Use Cases – Textual Description
Details
Identifies the details of the use
case
Post-Conditions
Identifies the conditions that are
assured to hold at the
conclusion of the use case
Exceptions
Identifies any exceptions that
might arise in the execution of
this use case
Constraints
Identifies any constraints that
might apply
Variants
Identifies any variations that
might hold for the use case
Comments
Provides any additional info that
Might be important in this use
case
Richard C. Lee and William M.
Tepfenhart
The Vending Machine Class Diagram
1
Merchant
money
product
buys
*
Customer
Coin Box
1 owns 1
money
money
Coin
requestProduct()
rejectCoin()
removeMoney()
addProduct()
1
1
1
supplier
* *
insertCoint()
receiveProduct()
Bad
Coin
Dispenser
1
1
product
1 0..*
dispenseProduct()
reject Request()
C.Thomas Wu.Introduction to O-O
Programming
Product
Apple
Juice
The Vending Machine System Use Case Diagram
Add
product
Merchant
Remove
Coins
Receive
product
Request
product
Customer
<<extends>>
Rejected
C.Thomas Wu.Introduction to O-O
Coin
Programming
A link that displays
exactly how an optional
actor interact with an
exception
Sequence Diagrams
•
Model system behavior (methods) for use cases by showing the
necessary class interactions. Shows the time ordering of a sequence of
method calls.
•
They show how the user (actor) communicates with the system to complete
the job.
•
The events modeled in the diagram are external events started by an actor.
•
The actors and objects are placed horizontally across the top of the
diagram.
•
The vertical lines called a lifeline is attached to each actor or object. The
lifeline becomes an activation box to depict the live activation period of
the object or actor.
•
A message is represented using an arrow labeled with a message. The
message may hold an argument list and a return type.
•
Dashed arrows may be used to indicate object flow. If an object’s ends
during the execution of the use case an X is placed at the bottom of its
lifeline.
C.Thomas Wu.Introduction to O-O
Programming
The Vending Machine System Sequence Diagram
Coin Box
Dispenser
Customer
insertCoin()
requestProduct()
rejectRequest()
rejectCoin()
Product
C.Thomas Wu.Introduction to O-O
Programming
See the skeleton code to use for the Vending Machine System
sequence diagram:
Vending Machine Sequence UML Diagram Skeleton Code.doc
Stored on the M: drive …in the UML folder.
C.Thomas Wu.Introduction to O-O
Programming
Collaboration Diagrams
Show the message passing structure of the system. The emphasis is on the
roles of the objects as they work together to complete a system function. They
can be used to display parts of a design pattern and they are helpful for
verifying class diagrams
2. requestProduct
1. SendCoin
:Coin Box
Customer
:Dispenser
4. returnCoin
3. rejectRequest
Return coin collaboration
diagram
C.Thomas Wu.Introduction to O-O
Programming
Collaboration Diagrams
Product delivery collaboration diagram
2
.
2. requestProduct
e
1. SendCoin
:Coin Box
Customer
3. deliverProduct
C.Thomas Wu.Introduction to O-O
Programming
:Dispenser
State Diagram
Describes the behavior (method) of a system, subsystem, or an individual object. The
system state is determined by the values assigned to object’s data members. A
system’s current state is only changed by a new event..
State diagrams display changes that affect the system behavior or its object data
members when an external factor triggers an event..
Wait for Coin
insert coin
Check Coin
bad coin
good coin
Check Dispenser
no product
product available
Dispense Product
C.Thomas Wu.Introduction to O-O
Programming
Return Coin
Activity Diagram
Display the work flow of an object. They are similar
to state diagrams
See Activity Diagram.doc
C.Thomas Wu.Introduction to O-O
Programming