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