UML Slides Softgozar

USC
CSE
USC - Center for Software Engineering
UML Overview
Based in parts on ‘UML Distilled’ from Martin Fowler
Alexander Egyed
CSCI 612
March, 1999
USC
CSE Outline
• UML Views
• Diagrams
– Use Case Diagrams
– Class Diagrams
– Interaction Diagrams
– Package Diagrams
– State Diagrams
– Activity Diagrams
– Deployment Diagrams
• Some Conclusions
1
USC
CSE Modeling and UML
Why Modeling?
- Programs become more complex
- Failures more costly
- Edit-and-Compile cycle not very efficient
Why New Models for OO?

- Paradigm shift from Functional Oriented Design to
Object-Oriented Design => functional modeling leads to
functional decomposition
- New Concepts such as Inheritance, Polymorphism,
Data/Behavior Encapsulation, etc.
USC
CSE UML History
OMT 1995 1996 1997

(Rumbaugh and
others)
UML UML UML
0.8 0.9 1.1
(OMG Standard)
Booch
OOSE UML
(Jacobson and 1.3
others) (beta)
1999
2
USC
CSE UML 1.1 OMG Standard
UML is a language for specifying, constructing, and

documenting software systems:
- General Purpose Modeling Language
- Merges Modeling Element from Booch, Rumbaugh,
Jacobson and others
- Object-Oriented Analysis and Design
- Graphical Notation supporting numerous diagrams
- Extensible Notation (Stereotypes)
- Extensible Semantics (Object Constraint Language)
UML is backed by numerous software producers such as

Digital, HP, IBM, Oracle, Microsoft, Unisys, and others
USC
CSE UML 1.1 OMG Standard
However, ...
- Semantics often ambiguous (only the UML Notation
Meta-Model well defined)
- As of yet there is no tool that supports all of UML (not
even Rational Rose)
- Uses both OO and functional development concepts
Nevertheless, ...
- Common model eases communication and interaction
- More precise meaning (semantics) can be added
(customized)
3
USC
CSE Views in UML
Analysis Prototype and Interface

Simulation (Dialog)
Requirements
Use Cases and

Interaction
Data Flow
Classes and
Deployment Physical Data
Objects
Architecting and
High-Level Design
Analysis State Transition Implementation
Architecting and High-Level Design

Low-Level Design Low-Level Design
USC
CSE Components and Connectors
Components:
- Classes, Objects, and Packages
- States and Activities
- Actors and Use-Cases
Connectors:
- Basically three types: Communication (control and data),
Containment, Attachment
- Restricted in what types of components they link
- First class citizens
4
USC
CSE Outline
• UML Views
• Diagrams
– Class Diagrams
– State Diagrams
USC
CSE Use-Case Diagrams
- Capture those parts of the system that are visible to

the outside (e.g. users or other systems).
- A use case is usually about a concrete goal or task
from the user’s point of view
- Use-Cases may give no feedback in terms of
complexity or system decomposition
=> mainly an analysis method.
5
USC
CSE Use-Case Diagram Stereotype
(between guillemots)
<<uses>>
Admit Patient <<uses>> File
administrative staff
Discharge Patient
patient database
Human
Actor
doctor System
Prescribe Treatment
Actor
<<extends>>
Procedure Fails
nurse
Track Treatment Procedures
Schedule Resources facilities database

dietician
Order Meals kitchen Use-Case
USC
CSE Outline
• UML Views
• Diagrams
– Class Diagrams
– State Diagrams
6
USC
CSE Class Diagrams
- Describe the static relationship of classes in a system.

These relationship must always be true.
- Classes often represent physical or otherwise tangible
entities but this must not always be true, either.
- Classes are probably the most misunderstood and
misused elements in OO design.
Frequently used Connectors:

- Associations
- Aggregation
- Generalization
USC
CSE Class Diagram
Association
Trans action 1..* 1 Cus tom er
1..* 1..* 1
1..* Posts has
Is at
1 1..*
1 Is at 0..1
Area Branch Accoun t BankCard
1..*
1..* 1 0..* 1..*
Aggregation Savings Account

CheckingAccount Generalization
CollegeAccount
PBAAccount
CurrentAccount
Class
7
USC
CSE Class Diagrams
Classes are usually the most central OO development

elements since they reflect the actual implementation the
closest -> this may have negative side effects.
Need to distinguish three types of classes:

- Conceptual Classes: Should capture domain entities with
no regard to the actual implementation.
- Design Classes: Should capture design entities without
overly committing to implementation details
- Implementation Classes: Should capture the physical
model (e.g. strongly influenced by programming language)
USC
CSE Domain Classes
P a tie n t
Do m a in Mo d e ls s h o w re a l-wo rld na m e
o b je cts a n d th e re la tio n s h ip s a d d re s s
b e twe e n th e m Ho s p ita l S S NO
in s u ra n ce in fo
S ta ff a d m it p a tie n t()
Vis it R e co rd d is ch a rg e p a tie n t()
a d m is s io n d a te
re le a s e d a te
ro o m n u m b e r
m e d ica tio n s
te s ts s ch e d u le d
Me d ica l S ta ff Ad m in S ta ff Op e ra tio n s S ta ff Me d ica l His to ry

Fa cilitie s
d ia g n o s tic in fo
te s t re s u lts
Bill X-ra ys
Op e ra tin g R o o m
La b o ra to ry
P h a rm a cy
Em e rg e n cy R o o m
Kitch e n
8
USC
CSE Design Classes
Patient
Visit Record
name
admission date
address
release date
SSNO
room number
insurance info
medications 1..1 1..1
tests scheduled
admit patient()
0..* discharge patient()
Account
status Medical History
1..1 1..1 amount diagnostic info
Bill
test results
0..* create() X-rays
modify()
Hospital delete()
Access
Pre:{amount=0}
USC
CSE Implementation Classes
nvo_SystemManager
nvo_SecurityManager
dso_Exception
CheckAccess()
GetSubSystem() -iu_SecurityManager CheckAccess()
CheckConnectionStatus() +idso_
SetSubSystem() nvo_WindowManager
RaiseException()
HandleException() CheckUnsavedData()
-iu_ExceptionManager
nvo_ExceptionManager OpenWindow()
-iu_SessionManager nvo_SessionManager
RaiseException()
GetUserID()
LogException()
GetSubSystem()
CheckConnectionStatus()
w_Logon
Account
Patient Medical History Open()
status
name diagnostic info cb_OK-Click()
amount
address test results
create() SSNO X-rays
modify() insurance info
delete()
admit patient()
discharge patient()
1..1
Visit Record w_ExceptionHandling
admission date 1..1
w_HospitalWindow
release date ExceptionHandlingSelection()
room number
medications Open()
tests scheduled SetAccess()
CheckUnsavedData()
9
USC
CSE Advanced Concepts in Classes
- Constraint Rules: e.g. Precondition {Amount = 0}. Also

useful to model post conditions and invariants (Design by
Contract)
- Multiple Classifications Do cto r S u rg e o n
Fe m a le
P e rs o n Th e ra p is t Do cto r
Ma le sex
{mandatory}
ro le
p a tie n t
Nu r s e
P a tie nt
USC
Ma n a g e r
- Dynamic Classifications
Fe m a le <<dynamic>>
Job
En g in e e r
P e rs o n
Ma le sex
<<static>> S a le s m a n
- Aggregation and Composition: Aggregation is the part-of

relationship. Easy? Consider: Employee part-of Company,
Engine part-of Car, etc. Sounds right but may not be true!
P o in t Composition
(fro m a wt)
C ircle P o lyg o n
(fro m a wt)
S tyle
Instance of Point belongs to only one
object and it dies with it
Aggregation
10
USC
Person
- Derived Associations and Attributes date-of-birth
/ age
- Interfaces and Abstract Classes
PC W indow
(generalization vs. realization)
<<abstract>>
W indow X11
MyApp
toFront()
toBack() Mac
realize
- Reference Classes vs. Value Classes

=> not all classes are equal
(many customers, one date)
- Classification vs. Generalization (is-a is dangerous)
1) Peter is-a Doctor; 2) Doctor is-a Employee;
3) Doctor is-a Profession => Peter is-a Profession?
USC
- Qualified Associations Order used to Product to identify Order Line

Order Product line item Order Line
0..1 am ount : Num ber
Is categorized by
- Association Classes
Pe rson empl oyer Comp any Person Skills
0..* 0..1 0..* 0..*
Empl oyment Co mpet ency

period
Implies only one instance of Employment
per Association of Person and Company
=> Person employed by same
company at different times?
11
USC
T
- Parameterized Class Set
insert()
rem ove()
<Employee>
<<bind>>
Employee EmployeeSet
- Instantiated Class, Utility Class, Meta-Class, ...

- Visibility (public, private, protected)
- Object Diagrams?
USC
CSE Outline
• UML Views
• Diagrams
– Class Diagrams
– State Diagrams
12
USC
CSE Interaction Diagrams
- Describe how groups of objects interact with each other.

Interaction diagram show the behavior of objects during a
particular time or time frame.
- On a conceptual level, interaction diagrams may show the
collaboration of use cases and conceptual classes ->
things the user and customer can relate to.
- On a specification and implementation level the focus is
on the collaboration of the software system components.
Two basic types
- Sequence Diagrams
- Collaboration Diagrams
USC
CSE Sequence Diagram
: Section
Object
: Building Owner
Message/Call
add zone to section
search
Object is Born
Create Lease : Lease
: Set Point Schedule
* [for all points] Item
Schedule In Effect
...
[lease exists] Delete Lease
Iteration
Return Object Dies

Conditions
13
USC
CSE Concurrent Processes and Activations
new a Transaction
Synchronous
Message Other Processing
a Transaction
new
Coordinator Suppressed
a first Transaction
new
Checker
a second
new Transaction Checker
all done?
ok
all done?
Asynchronous
Message
ok
beValid
Object deletes
itself
USC
CSE Concurrent Processes and Activations
new a Transaction
a Transaction
new
Coordinator
a first Transaction
new
Checker
a second
new Transaction Checker
all done?
fails
Kill other checkers
beInvalid
Object is killed
14
USC
CSE Collaboration Diagram
Order Entry W indow Object
Message Sequence Number

1: prepare()
Order
5 : needsReord er := needToR eorder()
2: * [for all order lines]: prepare()
3: hasStock := check()
4: [hasStock]: remove()
Macal lan l in e : O rder Line Macallan stock : Stock Item
7: [hasStoc k]: new 6: [needsReorder]: new
Delivery Item Reorder Item
USC
CSE Interactions Diagrams
Sequence Diagrams:
-> easy to see the sequence of event happening
Collaboration Diagrams:
-> easy to see static connection (configuration) of objects
- Diagrams emphasize simplicity. It is easy to create and to

understand them as long as the process depicted is
sequential in nature (one use case).
- Both types of interaction diagrams tend to become
awkward when conditions and loops are used (more
generalized behavior).
- Conditional behavior is best represented through
separate diagrams.
15
USC
CSE Outline
• UML Views
• Diagrams
– Class Diagrams
– State Diagrams
USC
CSE Package Diagrams
- Helps in breaking down large software system into

smaller pieces.
- Before OO, functional decomposition used to separate
behavioral decomposition from data decomposition. This
lead to a system decomposition which is incompatible
with OO since here behavior and data cannot be
separated.
- With OO, both forms of decompositions were merged and,
thus, packages are really just a grouping mechanism for
classes.
- Relationships between packages are similar to those of
classes, however, package interrelationships should
decrease coupling and increase cohesion.
16
USC
CSE Package Diagram
Order Capture AW T Mailing List UI

UI
Package
(like Modules)
Order Capture Mai ling L ist
Appli cation Dependency
Applicat ion
Orders Customers
USC
CSE Package Diagram
USC -Orde
Center for Software Engineering
r Capture AW T Mailing List UI
UI
Packages are self

contained entities like
modules. Coupling should
Order Capture Mailing List
Application Hierarchy Application
be minimized.
This makes them

particularly useful
Domain
for testing and test
Or ders Cus tom ers scenarios (e.g.
sequence diagrams)
Oracle Interface
Comm on M oney
DateRange
<<abstract>> Generalization
Database
Interface
Sybase
Interface
17
USC
CSE Outline
• UML Views
• Diagrams
– Class Diagrams
– State Diagrams
USC
CSE State Diagrams
State Diagrams have been around for a long time, even

before OO. They are very useful in presenting what states
an object/class may go through in its lifetime.
Thus, in OO a state diagram represent the life of a single
class or object. This is necessary because state diagrams
are a non-OO design technique. Using state diagrams in
OO on a system level may yield a functional system
decomposition and not an OO one.
=> use state diagrams only with classes
=> If used on a higher level (e.g. to describe use cases) be
careful when using its decomposition during design.
18
USC
CSE State Diagram
Self-Transition
Transition
Start [ Not all items checked ] / get next
Activity
[ Al l i tem s ch ecked && all

/ get first item Checking it ems avail able ] Di spatc hing
do: check item do: initiate delivery
It em Received[ som e
items not in stock ]
[ All items checked &&
some items not in stock ] De li vered
Item Received[ all
it ems avail able ]
W aiting
Delivered
State
USC
CSE State Diagram and Superstate
Superstate
State Diagram for Order Class
Active
[ Not all items checked ] / get next
[ All items checked && all

/ get first item Checking items available ] Dispatching
do: check item do: initiate delivery
Item Received[ some
items not in stock ]
[ All items checked &&
some item s n ot in
stock ]
It em Received[ al l
items available ] Delivered
W aiting
cancelled
Cancelled Delivered
19
USC
CSE Another State Diagram
Another State Diagram for

Order Class
[ payment not OK ]
Authorizing
do : check payme nt
[ payment OK ]
Rejected
Aut horized
How do we represent previous

state diagram and current one
together?
Delivered
USC
CSE Concurrent State Diagram
Cancelled
W aiting
Chec king Dispatching
Deli vered
Authorizing Authorized
Rejected
Careful not to make a single class too complex

e.g. break up the class into Dispatching and Authorizing.
20
USC
CSE Outline
• UML Views
• Diagrams
– Class Diagrams
– State Diagrams
USC
CSE Activity Diagrams
Activity Diagrams are the newest addition to UML and they

are also unique in that they did not exist before. Activity
Diagrams merge concepts from Event Diagrams, SDL
state modeling, and Petri nets.
Activity Diagrams appear like enriched state diagrams,
however, the meaning of components and connectors are
not quite the same.
Activity diagrams cause a functional system breakdown
and must be handled carefully. Nevertheless, through
their emphasis on activities (like operators in classes), a
OO interpretation of activity diagrams is much easier.
21
USC
CSE Activity Diagram
Receive
Order
Synchronization
Activity
* [for each line
item on order]
Cancel [failed] Authorize Check Line

Order Payment Item
Multiple Trigger
[in stock]
[succeeded] Assign to
Condition Order
[need to reorder]
[stock assignment to
all line items and
payment authorized] Reorder
Item
Dispatch
Order
USC
CSE Categorized Activity Diagram
Receive
Order Order Receive
Finance Supply
Processing
* [for each line
item on order]
Stock
Choose
Outstanding
Manager
[failed] Check Line Order Items
Authorize Cancel Item
* [for each
Payment Order [in stock] chosen order
item]
Assign
Assign to
Goods to
[succeeded] Order
Order
[all outstanding
[stock assignment to order items filled]
all line items and
payment authorized] [need to reorder]
Reorder
Item Add
Dispatch
Remainder
Order
to Stock
22
USC
CSE Outline
• UML Views
• Diagrams
– Class Diagrams
– State Diagrams
USC
CSE Deployment Diagrams
Deployment Diagrams show the physical dependencies

between software and hardware components.
- Nodes represent computational units
- Components represent packages (subsystems) and
- Connectors represent communication paths.
23
USC
CSE Deployment Diagram
Windows PC
s cre e n us e r
Unit Server
DB In te r fa ce
fid s
a p p fra m e
d b c on n e c t
Ora cle
as s ay
r e p o rting
USC
CSE Outline
• UML Views
• Diagrams
– Class Diagrams
– State Diagrams
24
USC
CSE Extending UML
Use Stereotypes to
- extend the notation of UML
- specialize the meaning of modeling elements
Use Object Constraint Language to

- extend the semantics of UML
- add additional constraints to modeling elements
=> extend to redefine

=> extend to specialize
USC
CSE The UML Meta-Model
Meta-Meta Model Meta-UML Structure
??? Meta Model UML Structure
Class Model Static Structure

State
Package
Objects
User Objects Dynamic Structure
Sequence Calls
25
USC
CSE Simplified UML Meta-Model
Association {ordere d} 2..* Ass ocEnd

multiplicity : Mul tipli cit y instance
LinkEnd
0..* aggregation : {none, aggregat e, 0..*
Feat ure 0..*
visibility : {public, private, protected} Class
0..1
0..1 0..1
StateMachine 0..*
0..* 1..* Transition 0..1 Event
0..* Int erface 0..1
Attribute Operat ion 0..1 0..1 0..* 0..*
type : TypeExpr dir : {require, provide} top 0..*
0..1 sour ce CallEvent 0..1 Operati on
1..* State
targe t
0..* {ordere d} 0..1
Parameter
type : TypeExpr CompositeState
kind : {in, out , inout, return} 0..1
0..*
TaggedValue Stereot ype
value : Unint erpreted 0..* 0..1
Note: All classes are subclasses of Mod- 0..*
elElement (except ModelElement itself). This 0..1
0..*
relationship is not shown. M odel
0..* Constraint
1..* ModelElement body : Uninterpreted
name : St ring 1..* 0..*
Simplified UML Meta Model (adapted from [26])
USC
CSE Conclusions
- UML notation is not very complex but there are many

subtleties in interpreting things.
- UML is not well suited for precision (too many
ambiguities).
- Nevertheless, UML is sufficient in modeling many (most)
things. Often there is no need for strong formalism.
=> use UML during general development process

=> use something else (e.g. ADLs) when it is less suited
26

UML Slides Softgozar

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

UML Slides Softgozar

Caricato da

Copyright:

Formati disponibili

USC

Why New Models for OO?

OMT 1995 1996 1997

UML is a language for specifying, constructing, and

UML is backed by numerous software producers such as

Analysis Prototype and Interface

Use Cases and

Architecting and High-Level Design

- Capture those parts of the system that are visible to

=> mainly an analysis method.

Admit Patient <<uses>> File

Schedule Resources facilities database

Order Meals kitchen Use-Case

- Describe the static relationship of classes in a system.

Frequently used Connectors:

Aggregation Savings Account

Classes are usually the most central OO development

Need to distinguish three types of classes:

Me d ica l S ta ff Ad m in S ta ff Op e ra tio n s S ta ff Me d ica l His to ry

- Constraint Rules: e.g. Precondition {Amount = 0}. Also

- Aggregation and Composition: Aggregation is the part-of

- Reference Classes vs. Value Classes

- Qualified Associations Order used to Product to identify Order Line

Empl oyment Co mpet ency

- Instantiated Class, Utility Class, Meta-Class, ...

- Describe how groups of objects interact with each other.

Return Object Dies

Kill other checkers

Order Entry W indow Object

Message Sequence Number

7: [hasStoc k]: new 6: [needsReorder]: new

Delivery Item Reorder Item

- Diagrams emphasize simplicity. It is easy to create and to

- Helps in breaking down large software system into

Order Capture AW T Mailing List UI

Packages are self

This makes them

State Diagrams have been around for a long time, even

[ Al l i tem s ch ecked && all

[ All items checked && all

Another State Diagram for

How do we represent previous

Chec king Dispatching

Careful not to make a single class too complex

Activity Diagrams are the newest addition to UML and they

Cancel [failed] Authorize Check Line

Deployment Diagrams show the physical dependencies

Use Object Constraint Language to

=> extend to redefine

Meta-Meta Model Meta-UML Structure

??? Meta Model UML Structure

Class Model Static Structure

Association {ordere d} 2..* Ass ocEnd

Simplified UML Meta Model (adapted from [26])

- UML notation is not very complex but there are many

=> use UML during general development process

Potrebbero piacerti anche