1 / 24

UML The Unified Modeling Language A Practical Introduction

UML The Unified Modeling Language A Practical Introduction. Al-Ayham Saleh. Al-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

conroy
Télécharger la présentation

UML The Unified Modeling Language A Practical Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UMLThe Unified Modeling LanguageA Practical Introduction Al-Ayham Saleh Al-Ayham Saleh Aleppo University 22-11-2003

  2. UML Diagrams • Use Case diagrams • Class diagrams • Object diagrams • Sequence diagrams • Collaboration diagrams • State chart diagrams • Activity diagrams • Component diagrams • Deployment diagrams

  3. Object Diagrams • Useful when you model reflexive associations • Represent Data, or samples of data • Object Diagrams are static Underline means an object

  4. 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

  5. Sequence Diagrams

  6. Sequence Diagrams • Sequence diagrams show how instance exchange messages. • An instance can be: • An object, not a class • An actor

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

  8. 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.

  9. 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

  10. 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

  11. Sequence Diagrams • Messages can be Return messages • Results of procedure calls

  12. Sequence Diagrams • Messages can be Constructors • The message creates the recipient

  13. Sequence Diagrams • Messages can be Destructors • The message destroys the recipient

  14. Sequence Diagrams • Messages have sequence numbers • The numbers represent the order of interaction

  15. Sequence Diagrams • Messages have sequence numbers • Sequence number can be hierarchical

  16. Sequence Diagrams • Messages have a specific format [Condition] Sequence Number. Return value := MessageName(Arguments) *[iteration] [Condition] Sequence Number. Return value := MessageName(Arguments)

  17. 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

  18. 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.

  19. Collaboration Diagrams • Represent Object roles in a scenario of interactions • Are synonymous to sequence diagrams • Use the same message formats

  20. Collaboration Diagrams

  21. 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

  22. Static Modeling • Diagrams • Use Case Diagrams • Class Diagrams • Object Diagrams • Represent a static view of the system • Represent what happens, and who participates

  23. Interaction Modeling • Diagrams • Sequence Diagrams • Collaboration Diagrams • Represent how things happen • Conditions • Flow of interactions • Flow of events • Flow of information

  24. Workshop • Expand the previous workshop with the necessary interaction models • Collaboration diagrams for each scenario • Sequence diagram for each scenario

More Related