knowledge-kitchen / course-notes

class: center, middle # UML Diagrams Standardized ways of diagramming software systems. --- # Agenda 1. [Overview](#overview) 2. [Best practices](#best-practices) 3. [Classes](#classes) 4. [Use Cases](#use-cases) 5. [Activities](#activities) 6. [Sequences](#sequences) 7. [State Charts](#state-charts) 8. [Conclusions](#conclusions) --- name: overview # Overview -- ## Concept Primitive, standardized, easy-to-draw diagrams to quickly communicate software _structure_ and _behavior_. --- template: overview ## Types of diagrams UML (Unified Modeling Language) provides for many types of diagrams, divided into two categories: | Structural | Behavioral | | :------------------ | :--------------------- | | Class diagrams | Activity diagrams | | Package diagrams | Sequence diagrams | | Object diagrams | Use case diagrams | | Component diagrams | State diagrams | | Deployment diagrams | Communication diagrams | | | Interaction diagrams | | | Timing diagrams | --- template: overview name: book ## Types of diagrams We will explore just a few diagram types for example. The book, "[The Elements of UML Style](http://bit.ly/se-elements-of-uml-style)", by Scott W. Ambler is a good reference for more - we have pulled some key insights from it here. --- name: best-practices # Best Practices -- ## Overview Regardless of which diagram type, following best practices keeps diagrams understandable and avoids common pitfalls. - Avoid crossed lines - Avoid diagonal and curved lines - Use consistent sizes - Flow from top-to-bottom, left-to-right --- template: best-practices ## Avoid crossed lines Don't do this:  --- template: best-practices ## Avoid crossed lines Do this:  --- template: best-practices ## Avoid diagonal and curved lines. Don't do this:  --- template: best-practices ## Avoid diagonal and curved lines. Do this:  --- template: best-practices ## Use consistent sizes Don't do this:  --- template: best-practices ## Use consistent sizes Do this:  --- template: best-practices ## Flow top-to-bottom, left-to-right Don't do this:  --- template: best-practices ## Flow top-to-bottom, left-to-right Do this:  --- name: classes # Classes -- ## Concept Used to display the attributes, methods, and interactions of object-oriented classes in code. --- template: classes ## One Class A single class:  --- template: classes ## Multiple Classes Relationships among classes, plus annotations, in a casual style:  --- name: use-cases # Use Cases -- ## Concept Used to indicate interactions between actors and the system. --- template: use-cases ## Single actor A single actor, a single system:  --- template: use-cases ## Multiple actors Multiple actors, multiple systems:  -- Read more about the use of [use cases in requirements engineering](../requirements-engineering#use-cases). --- name: activities # Activities -- ## Concept Flow charts often used to document a complex operation, the logic of one or more use cases, or any other process. --- template: activities ## Example 1  -- From [The Elements of UML Style](#book): > In [this figure], you can see that the business process forks into two parallel streams, one where the person attends a presentation and another where he or she signs up and pays for courses. The process forks -- the person performs these activities -- and when both streams are complete, the process continues from there (in this case it simply ends). --- template: activities ## Shapes The basic shapes in an activity diagram are: -- - **solid circle** (start) and **solid circle with offset outline** (end) -- - **rounded rectangle** indicating a step in the activity (i.e. an action or activity undertaken by either the user or the system) -- - **rhombus/diamond** indicating a decision point (i.e. any step that would require if/elif/else logic to determine what to do next in the flow). -- - **thick bar** indicating two or more sub-activities that are executed in parallel and must all conclude before moving on to the next step in the greater flow. The first bar from whence two or more sub-activities spawn is called a "fork", and the second bar, where those sub-activities converge, is called a "join". -- - **arrows** connecting these shapes to indicate the flow of control --- name: sequences # Sequences -- ## Concept Used to validate and work out the logic and completeness of a certain scenario, often a use case or a part of a use case. These show the entire sequence of messages sent among the objects and systems involved in the scenario. --- template: sequences ## Example  --- name: state-charts # State Charts -- ## Concept Indicate the dynamic behavior of an entity based on its response to events, showing how the entity reacts to various events based on its current state. - Only useful when behavior changes significantly based on internal state of the object. --- template: state-charts ## Example A seminar, partial lifecycle:  --- template: state-charts ## Example A seminar, complete lifecycle:  --- name: conclusions # Conclusions Thank you. Bye.