UMLThe Unified Modeling Language

A Practical IntroductionAl-Ayham SalehAl-Ayham Saleh

Aleppo University

22-11-2003

UML Diagrams• Use Case diagrams

• Class diagrams

• Object diagrams

• Sequence diagrams

• Collaboration diagrams

• State chart diagrams

• Activity diagrams

• Component diagrams

• Deployment diagrams

Object Diagrams• Useful when you model

reflexive associations• Represent Data, or

samples of data• Object Diagrams are

static

person

0..n

11

0..n+childen

GrandFather2 : personGrandFather1 : person GrandMother1 : person GrandMother2 : person

Father : person Mother : person

Kid : personUnderline means an object

Sequence Diagrams• Detail how operations are carried out

• Dynamic Diagrams

• Organized according to time– The time progresses as you go down the page – The objects involved in the operation are listed from

left to right according to when they take part in the message sequence.

• Create a sequence diagram for each scenario

Sequence Diagrams : Customer

: Order

: item

: payment

1. CreateOrder

2. request

3. addToOrder(:item)

4. Checkout4.1. CreatePayment

4.1.1. GetPaymentInfo

4.1.1.1. PaymentInfo

4.1.1.1.1. Success

4.3. Order Result

4.2. Save or decline

Sequence Diagrams• Sequence diagrams show how instance

exchange messages.

• An instance can be:– An object, not a class– An actor

Sequence Diagrams• Messages can be Simple

– One object sends a message to a passive object– The sender does not care what happens to the

message– Useful when the recipient can not be controlled

Sequence Diagrams• Messages can be Synchronous

– The sender sends the message– The recipient accepts the message, and notifies the

sender with a message result.– The sender accepts the message result.

• If the sender does not accept the message result, then the whole operation will not continue.

• Synchronous messages are useful to represent procedure calls or modal dialogs.

Sequence Diagrams• Messages can be Asynchronous

– The sender sends the message– The sender does not wait for the return of the

message, it immediately continues execution.– The recipient may or may not send a reply.

• Asynchronous messages are useful to model– Multithreading– Windows hooks– Windows sub-classing– Exception Handling– Modeless dialogs

Sequence Diagrams• Messages can be Timeouts

– The sender sends the message– The sender awaits for the return of the message for

some time.– Execution continues when the recipient replies, or

after the timeout period if the recipient does not reply

– The recipient may or may not send a reply.

• Timeout messages are useful to model– System Calls– Cross-component calls

Sequence Diagrams• Messages can be Return messages

– Results of procedure calls

Sequence Diagrams• Messages can be Constructors

– The message creates the recipient

: Customer

: Order1. Create

Sequence Diagrams• Messages can be Destructors

– The message destroys the recipient

: Customer

: Order1. Create

2. Destroy

Sequence Diagrams• Messages have sequence numbers

– The numbers represent the order of interaction

: Customer

: Order1. Create

2. Destroy

Sequence Diagrams• Messages have sequence numbers

– Sequence number can be hierarchical

: Customer

: Item

: store

1. Create

1.1. CheckStock

1.1.1. Yes

Sequence Diagrams• Messages have a specific format

[Condition] Sequence Number. Return value := MessageName(Arguments)

[Condition] Sequence Number. Return value := MessageName(Arguments)*[iteration]

When to use Sequence Diagrams• To specify how instances interact

• To show what happens before the other

• To show the relationships/dependencies between interactions

• To clarify each object requirements for all the possible scenarios of the system

Effective Sequence Diagrams• Use only instances and actors

• Concentrate on actions, not on instance static details

• Imaging as much real time scenarios as you can, and model them

• Keep in mind that a programmer will read your design, so make it as clear as possible.

Collaboration Diagrams• Represent Object roles in a scenario of

interactions

• Are synonymous to sequence diagrams

• Use the same message formats

Collaboration Diagrams

: Customer

: Order

: item

: payment

4.2. Save or decline

4.1.1. GetPaymentInfo

4.1.1.1. PaymentInfo

1. CreateOrder3. addToOrder(:item)

4. Checkout

4.3. Order Result

2. request

4.1. CreatePayment

4.1.1.1.1. Success

Collaboration Diagrams• Used to understand the structure of a scenario

• Used to concentrate on what happens to each instance as a whole.

• Can be converted to sequence scenarios

Static Modeling• Diagrams

– Use Case Diagrams– Class Diagrams– Object Diagrams

• Represent a static view of the system

• Represent what happens, and who participates

Interaction Modeling• Diagrams

– Sequence Diagrams– Collaboration Diagrams

• Represent how things happen– Conditions– Flow of interactions– Flow of events– Flow of information

Workshop• Expand the previous workshop with the

necessary interaction models– Collaboration diagrams for each scenario– Sequence diagram for each scenario