UML The Unified Modeling Language A Practical Introduction Al-Ayham Saleh Aleppo University

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

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

Sequence Diagrams Messages can be Destructors –The message destroys the recipient

Sequence Diagrams Messages have sequence numbers –The numbers represent the order of interaction

Sequence Diagrams Messages have sequence numbers –Sequence number can be hierarchical

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

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