ICS 125: Practical UML
Overview
- What is UML?
- Why use UML?
- One Model, Many Diagrams
- Use Case Diagrams
- Class Diagrams > Classes, Attributes, and Operations
- Class Diagrams > Relations
- State Diagrams > States and Transitions
- State Diagrams > Composite and Parallel States
- Sequence Diagrams
- Component and Deployment Diagrams
What is UML?
- UML is the Unified Modeling Language
- Unifies previous object oriented design notations
- Unifies several aspects of requirements and design
- Unifies several phases of development
- UML covers four main aspects of requirements and design:
- Use cases: Use case and activity diagrams
- Structural: Class diagrams with packages, classes, and relations
- Behavioral: State machines, sequence diagrams, collaboration diagrams
- Architectural: component and deployment diagrams
- UML covers several phases of development:
- Requirements: Use cases, analysis models
- Design: Class diagrams, state machines, deployment, etc.
- Implementation: Code generation and reverse engineering
Why use UML?
- You need a design notation to express your design
- It's the winning OOAD standard notation. The others are gone.
- It's good to stick with a standard that other people will understand
- UML is pretty easy to get started with, and it is pretty powerful
- There are many UML tools available
- Diagrams only: Visio, Dia, etc.
- UML Models and Diagrams: ArgoUML, Rational Rose, Together ControlCenter, etc.
One Model, Many Diagrams
- When you start to learn UML, you focus on the diagrams
- But, the diagrams are just visual representations of an underlying model
- Different diagrams are just different views into that model
- The model is formal enough to allow code generation and analysis
- The model is formally defined by a meta-model
Use Case Diagrams
- Use case: Oval with name
- Generalization: white triangle arrowhead
- Extends: dashed line with arrowhead <<extends>>
- Actor: Stick figure with name
- Generalization: white triangle arrowhead
- System boundary: box with name, optional
Class Diagrams > Classes, Attributes, and Operations
- Class: box with three sections (name, attributes, operations)
- Attributes and Operations are optional
- Abstract classes have italic names
- Attribute: [visibility] name [: type [= initial-value]]
- Operation: [visibility] name [(arg [:type] ...)] [: type]
- Interface: box with two sections
Class Diagrams > Relations
- Generalization: class to superclass: solid line with white arrowhead
- Realization: class to interface: dashed line with white arrowhead
- Relations: solid line with label in middle
- Optional name on each ends of line
- Multiplicity on ends: 1, 0..1, 0..*, *, 1..*, X..Y
- Navigability on ends: arrowhead
- Aggregation on ends: white diamond or black diamond or none
State Diagrams > States and Transitions
- State: Rounded rectangle with name
- State: optional actions on entry, internal transitions, and on exit
- Transition: solid line with arrowhead
- Transition: [event] [ [condition] ] [ / action ]
State Diagrams > Composite and Parallel States
- Composite state: Big rounded rectangle with other states inside
- Can have own internal start and final states
- Transitions into composite state go to internal start state
- Transitions out of composite state go from every internal state
- Concurrent composite states: Big rounded rectangle divided by dashed lines
- One current state in each section
Sequence Diagrams
- Actor or Instance at top of each column
- Long vertical dashed line is the object "lifeline"
- Time is downward on the page
- Messages / procedure calls are arrows between lifelines
Component and Deployment Diagrams
- Component: box with bump-outs
- Each component contains a set of classes
- Components can expose some interfaces, keep everything else private
- Components can depend on the interfaces of other components
- Dependency: dashed line with arrowhead
- Node / Machine: 3D box
- Communications link: solid line between nodes
sample use cases templateexample software testing plan templateProject plan template