uml slides softgozar

1

USC - Center for Software Engineering

USC

C S E

UML Overview

Alexander Egyed

CSCI 612

March, 1999

Based in parts on ‘UML Distilled’ from Martin Fowler


USC

C S E

• UML Views• Diagrams

– Use Case Diagrams– Class Diagrams– Interaction Diagrams– Package Diagrams– State Diagrams– Activity Diagrams– Deployment Diagrams

• Some Conclusions

Outline

2


USC

C S E

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 tofunctional decomposition

- New Concepts such as Inheritance, Polymorphism,Data/Behavior Encapsulation, etc.

Modeling and UML


USC

C S E

OMT(Rumbaugh and

others)

Booch

UML0.8

OOSE(Jacobson and

others)

UML0.9

UML1.1

(OMG Standard)

UML1.3

(beta)

1995 1996 1997

1999

UML History

3


USC

C S E UML 1.1 OMG Standard

UML is a language for specifying, constructing, anddocumenting 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 asDigital, HP, IBM, Oracle, Microsoft, Unisys, and others


USC

C S E

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)

UML 1.1 OMG Standard

4


USC

C S E Views in UML

Prototype andSimulation

Interface(Dialog)

Classes andObjects

Interaction

Deployment

State Transition

Requirements

Physical Data

Implementation

Analysis

Architecting andHigh-Level Design

Low-Level Design

Analysis

Architecting and High-Level Design

Low-Level Design

Data FlowUse Cases and


USC

C S E

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

Components and Connectors

5


USC

C S E




Outline


USC

C S E Use-Case Diagrams

- Capture those parts of the system that are visible tothe outside (e.g. users or other systems).

- A use case is usually about a concrete goal or taskfrom the user’s point of view

- Use-Cases may give no feedback in terms ofcomplexity or system decomposition

=> mainly an analysis method.

6


USC

C S E

administrative staff

Prescribe Treatment

doctor

patient database

nurse

facilities databaseSchedule Resourcesdietician

kitchenOrder Meals

Discharge Patient

Admit Patient File<<uses>>

<<uses>>

Procedure Fails

Track Treatment Procedures

<<extends>>

Use-Case Diagram

HumanActor

SystemActor

Use-Case

Stereotype(between guillemots)


USC

C S E




Outline

7


USC

C S E Class Diagrams

- Describe the static relationship of classes in a system.These relationship must always be true.

- Classes often represent physical or otherwise tangibleentities but this must not always be true, either.

- Classes are probably the most misunderstood andmisused elements in OO design.

Frequently used Connectors:- Associations- Aggregation- Generalization


USC

C S E

CheckingAccount

CollegeAccount

CurrentAccountPBAAccount

SavingsAccount

Area Branch

1..*1..*

BankCard

Customer

1

0..1

1

0..1

has

Accoun t

0..*1 0..*1

Is at

1..*1..*

1..*1..*

1..*

1..*

1..*

1..*

Transaction

1

1..*

1

1..*

Is at

11..* 11..*

1

1..*

1

1..* Posts

Class

GeneralizationAggregation

Association

Class Diagram

8


USC

C S E Class Diagrams

Classes are usually the most central OO developmentelements since they reflect the actual implementation theclosest -> 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

C S E

Vis it R e cord

a dm is s io n da tere le a s e d a teroom n um be rm e dica tion ste s ts s ch e du le d

Bill

Me dica l S ta ff Admin S ta ff Ope ra tio ns S ta ff

Ope ra ting R oom

P h a rm a cy

Kitche nEm e rg e ncy R o om

La bo ra to ry

Me dica l His to ry

d ia gn os tic in fote s t re s u ltsX-ra ys

P a tie n t

na m ea ddre s sS S NOins ura nce in fo

a dm it p a tie n t()d is ch a rge pa tie n t()

S ta ff

Hos p ita l

Fa cilitie s

Do m a in Mode ls s how re a l-world o b je cts a nd the re la tion s h ip s b e twe e n the m

Domain Classes

9


USC

C S E

Visit Record

admission daterelease dateroom numbermedicationstests scheduled

Hospital

0..*

1..1

0..*

1..1

Access

Medical History

diagnostic infotest resultsX-rays

Patient

nameaddressSSNOinsurance info

admit patient()discharge patient()

1..11..1 1..11..1

Bill

Account

statusamount

create()modify()delete()

1..1

0..*0..*

1..1

Design Classes

Pre:{amount=0}


USC

C S E

nvo_WindowManager

CheckUnsavedData()OpenWindow()

w_ExceptionHandling

ExceptionHandlingSelection()

w_Logon

Open()cb_OK-Click()

nvo_SecurityManager

CheckAccess()

nvo_SessionManager

GetUserID()GetSubSystem()

CheckConnectionStatus()

nvo_SystemManager

CheckAccess()GetSubSystem()CheckConnectionStatus()SetSubSystem()RaiseException()HandleException()

-iu_SecurityManager

-iu_SessionManagernvo_ExceptionManager

RaiseException()

LogException()

-iu_ExceptionManager

dso_Exception

+idso_

Account

statusamount

create()modify()delete()

Visit Record

admission daterelease dateroom numbermedicationstests scheduled

Patient

nameaddressSSNOinsurance info

admit patient()discharge patient()

1..1

1..1

1..1

1..1

Medical History

diagnostic infotest resultsX-rays

w_HospitalWindow

Open()SetAccess()CheckUnsavedData()

Implementation Classes

10


USC

C S E Advanced Concepts in Classes

- Constraint Rules: e.g. Precondition {Amount = 0}. Alsouseful to model post conditions and invariants (Design byContract)

- Multiple Classifications

Fe m a le

Ma le

P e rs on

P a tie nt

Docto r

Nurs e

The ra p is t

S u rg e o n

Docto r

pa tie n tro le

s e x

{mandatory}


USC


- Dynamic Classifications

- Aggregation and Composition: Aggregation is the part-ofrelationship. Easy? Consider: Employee part-of Company,Engine part-of Car, etc. Sounds right but may not be true!

Fe m a le

Ma le

P e rs o n

s e x

Ma na ge r

En g in e e r

S a le s m a n

J o b

<<static>>

<<dynamic>>

C ircle

S tyle

P o in t(fro m a wt)

P o lygon(from a wt)

Instance of Point belongs to only one object and it dies with it

Aggregation

Composition

11


USC


- Derived Associations and Attributes- Interfaces and Abstract Classes

(generalization vs. realization)

- 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?

Person

date-of-birth/ age

Window

toFront()toBack()

<<abstract>>

PC Window

X11

Mac

MyApp

realize


USC


- Qualified Associations

- Association Classes

Order Product Order Line

am ount : Num ber0..1

line item

0..1

Is categorized by

Order used to Product to identify Order Line

Employment

period

Person Company

0..10..*

employer

0..* 0..1

Competency

Person Skills

0..*0..* 0..*0..*

Implies only one instance of Employmentper Association of Person and Company

=> Person employed by samecompany at different times?

12


USC


- Parameterized Class

- Instantiated Class, Utility Class, Meta-Class, ...- Visibility (public, private, protected)

- Object Diagrams?

Employee EmployeeSet

<<bind>>

<Employee>

Set

insert()rem ove()

T


USC

C S E




Outline

13


USC

C S E Interaction Diagrams

- Describe how groups of objects interact with each other.Interaction diagram show the behavior of objects during aparticular time or time frame.

- On a conceptual level, interaction diagrams may show thecollaboration of use cases and conceptual classes ->things the user and customer can relate to.

- On a specification and implementation level the focus ison the collaboration of the software system components.

Two basic types- Sequence Diagrams- Collaboration Diagrams


USC

C S E Sequence Diagram

: Lease

: Set Point Schedule Item

: Section : Building Owner

Schedule In Effect

Create Lease

add zone to sectionsearch

* [for all points]

Object

Message/Call

[lease exists] Delete Lease

...

Object Dies

Object is Born

Return

Iteration

Conditions

14


USC

C S E Concurrent Processes and Activations

a Transaction

a second Transaction Checker

new

all done?

beValid

new

ok

ok

new

a TransactionCoordinator

a first Transaction Checker

new

all done?

AsynchronousMessage

Other ProcessingSuppressed

Object deletesitself

SynchronousMessage


USC

C S E Concurrent Processes and Activations

a Transaction

a second Transaction Checker

new

beInvalid

new

fails

new

a TransactionCoordinator

a first Transaction Checker

new

all done?

Object is killed

Kill other checkers

15


USC

C S E

Order Entry Window

Order

Macal lan l ine : Order Line Macallan stock : Stock Item

Delivery Item Reorder Item

1: prepare()

2: * [for all order lines]: prepare()

3: hasStock := check()4: [hasStock]: remove()

5: needsReorder := needToReorder()

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

Object

Message Sequence Number

Collaboration Diagram


USC

C S E Interactions Diagrams

Sequence Diagrams:-> easy to see the sequence of event happeningCollaboration Diagrams:-> easy to see static connection (configuration) of objects

- Diagrams emphasize simplicity. It is easy to create and tounderstand them as long as the process depicted issequential in nature (one use case).

- Both types of interaction diagrams tend to becomeawkward when conditions and loops are used (moregeneralized behavior).

- Conditional behavior is best represented throughseparate diagrams.

16


USC

C S E




Outline


USC

C S E Package Diagrams

- Helps in breaking down large software system intosmaller pieces.

- Before OO, functional decomposition used to separatebehavioral decomposition from data decomposition. Thislead to a system decomposition which is incompatiblewith OO since here behavior and data cannot beseparated.

- With OO, both forms of decompositions were merged and,thus, packages are really just a grouping mechanism forclasses.

- Relationships between packages are similar to those ofclasses, however, package interrelationships shoulddecrease coupling and increase cohesion.

17


USC

C S E

Order CaptureUI

AWT Mailing List UI

Mai ling L ist Applicat ion

CustomersOrders

Order Capture Application

Package Diagram

Package(like Modules)

Dependency


USC

C S E

Order CaptureUI

AWT Mailing List UI

Mailing List Application

Order Capture Application

Domain

Database Interface

<<abstract>>Comm on M oney DateRange

Oracle Interface

Sybase Interface

Orders Cus tom ers

Hierarchy

Generalization

Package Diagram

Packages are selfcontained entities likemodules. Coupling shouldbe minimized.

This makes themparticularly usefulfor testing and testscenarios (e.g.sequence diagrams)

18


USC

C S E




Outline


USC

C S E State Diagrams

State Diagrams have been around for a long time, evenbefore OO. They are very useful in presenting what statesan object/class may go through in its lifetime.

Thus, in OO a state diagram represent the life of a singleclass or object. This is necessary because state diagramsare a non-OO design technique. Using state diagrams inOO on a system level may yield a functional systemdecomposition 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.

19


USC

C S E

Checking

do: check item

Dispatc hing

do: initiate delivery

Delivered

Waiting

[ Not all items checked ] / get next

/ get first item[ Al l i tem s checked && all

it ems available ]

[ All items checked &&some items not in stock ]

It em Received[ som e items not in stock ]

Item Received[ all it ems available ]

Delivered

State Diagram

Start

Self-TransitionTransition

State

Activity


USC

C S E State Diagram and Superstate

Delivered

Active

Checking

do: check item

Dispatching


Waiting

Cancelled

Checking

do: check item

[ Not all items checked ] / get next

Dispatching


[ All items checked && all items available ]

DeliveredWaiting

[ All items checked &&some item s not in

stock ]

Item Received[ some items not in stock ]

Item Received[ al l items available ]

/ get first item

cancelled

SuperstateState Diagram for Order Class

20


USC

C S E

Authorizing

do: check payment

Authorized

Delivered

Rejected

[ payment not OK ]

[ payment OK ]

Another State Diagram

How do we represent previousstate diagram and current onetogether?

Another State Diagram for Order Class


USC

C S E

Waiting

Chec king Dispatching

Authorizing Authorized

Cancelled

Deli vered

Rejected

Waiting

Chec king Dispatching

Authorizing Authorized

Concurrent State Diagram

Careful not to make a single class too complexe.g. break up the class into Dispatching and Authorizing.

21


USC

C S E




Outline


USC

C S E Activity Diagrams

Activity Diagrams are the newest addition to UML and theyare also unique in that they did not exist before. ActivityDiagrams merge concepts from Event Diagrams, SDLstate modeling, and Petri nets.

Activity Diagrams appear like enriched state diagrams,however, the meaning of components and connectors arenot quite the same.

Activity diagrams cause a functional system breakdownand must be handled carefully. Nevertheless, throughtheir emphasis on activities (like operators in classes), aOO interpretation of activity diagrams is much easier.

22


USC

C S E

ReceiveOrder

AuthorizePayment

Check LineItem

CancelOrder

* [for each lineitem on order]

[failed]

Assign toOrder

[in stock]

ReorderItem

[need to reorder][stock assignment to

all line items andpayment authorized]

[succeeded]

DispatchOrder

Activity Diagram

Synchronization

Multiple Trigger

Condition

Activity


USC

C S E

ReceiveOrder

AuthorizePayment

Check LineItemCancel

Order

* [for each lineitem on order]

[failed]

Assign toOrder

[in stock]

ReorderItem

[need to reorder]

[stock assignment toall line items and

payment authorized]

[succeeded]

DispatchOrder

ChooseOutstandingOrder Items

AssignGoods to

Order

ReceiveSupply

AddRemainder

to Stock

[all outstandingorder items filled]

* [for eachchosen order

item]

OrderProcessing

Finance

StockManager

Categorized Activity Diagram

23


USC

C S E




Outline


USC

C S E Deployment Diagrams

Deployment Diagrams show the physical dependenciesbetween software and hardware components.

- Nodes represent computational units- Components represent packages (subsystems) and- Connectors represent communication paths.

24


USC

C S E

fid s

a p pfra m e

s cre e n

reporting

a s s a y

u s e r

d bc on ne ct

DB In te r fa ce

Ora cle

Unit Server

Windows PC

Deployment Diagram


USC

C S E




Outline

25


USC

C S E 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

C S E The UML Meta-Model

Dynamic Structure

Static Structure

UML Structure

Meta-UML Structure

Objects

Sequence Calls

StateClass

Package

???

Meta-Meta Model

Meta Model

Model

User Objects

26


USC

C S E Simplified UML Meta-Model

ModelModelElementname : St ring

Association AssocEndmultiplicity : Mul tiplicityaggregation : {none, aggregate,

Class

Interface

Featurevisibility : {public, private, protected}

Operat iondir : {require, provide}

Attributetype : TypeExpr

Constraintbody : Uninterpreted

Stereotype

Note: All classes are subclasses of Mod-elElement (except ModelElement itself). Thisrelationship is not shown.

2..*

0..*

0..*

0..*

0..*

0..*

1..*

0..*1..*

0..*

Parametertype : TypeExprkind : {in, out , inout, return}

0..*

LinkEnd0..*

instance

StateMachine

TaggedValuevalue : Uninterpreted

Transition1..*

State

CompositeState

0..1

1..*

0..*source

0..*

targe t

0..*

Event

CallEvent Operation0..1

0..*0..1

0..1

0..1 0..1

0..10..1

{ordere d}

top

0..*

0..*

{ordered}

0..1

0..1

0..1

0..*

0..1

0..1

Simplified UML Meta Model (adapted from [26])


USC

C S E

- UML notation is not very complex but there are manysubtleties in interpreting things.

- UML is not well suited for precision (too manyambiguities).

- 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

Conclusions

uml slides softgozar

Documents