1. UML: Unified Modeling Language
27 March
UML: Unified Modeling Language

2. Software Engineering Elaborated Steps
Concept
Requirements
Architecture
Design
Implementation
Unit test
Integration
System test
Maintenance

3. What is UML? software blueprint language: common vocabulary
for analysts, designers, and programmers
not for the customer
applicable to object-oriented problem solving
begins with the construction of a model
models consist of objects
interact by sending messages
attributes: things they know
behaviors or operations: things they can do
state
Also used for business processes

4. Modeling Review Based on abstraction
looking only at relevant information
hiding details
Multiple views
as orthogonal as possible
each view has information that
is unique
appears in other views
common information is consistent

5. Modeling Languages and Processes
Language: syntax
usually graphical
used to express design
Process: steps to take to create a design
Many processes, not a lot of agreement
General consensus has built around UML as a language

6. UML History Three well received models in early 90s
Grady Booch (Rational), Object Oriented Analysis and Design
Jim Rumbaugh (GE), Object Modeling Technique
Ivar Jacobson (Ericsson), Object Oriented Software Engineering
By ’95, all three “amigos” were working for Rational (acquired by IBM in 2002)
OMG adopted UML in ’97
Version 2.0 completed in 2004

7. OMG Model Oriented Architecture
UML - graphical language for visualizing, specifying, constructing, artifacts
MOF - integration framework for metadata and data
Specification to translate MOF model to text artifacts
Query language …
CWM - semantic context for interchange of metadata

8. Why Study UML? software engineering cultural literacy
useful tool
natural model for design
lots of good tools
Rational generates C++ and Java code
Some people expect tools to generate code
good for prototyping
good for development?
Would this be good or bad?

9. What UML Is and Isn’t Syntax only Standardized
Language and tool independent
Generic enough to be
Usable in lots of environments
And leaving you lots of space to misuse it
Extendable through “stereotypes”
New symbols built up from basic ones
Used to develop a business process model
Not a process (there is a companion one)

10. References www.uml.org Fowler, UML Distilled, Addison-Wesley
3rd edition, 2004, covers 2.0
Short
Good summary charts on inside covers

11. UML Views: Diagram Types
Use Case – outside view (scenarios)
Class – classes and relationships among them
Object – instances instead of classes
Sequence – how and when objects interact through messages
Collaboration – how objects interact through roles
Statechart – object behaviors as reflected through states (single class)
Activity – flow diagram covering multiple classes and their interactions
Component – analogous to class but for code module
Deployment – physical configuration of system nodes and their communication

12. Component
Use case
Sequence
Deployment
Activity
Class
Object
Collaboration
Statechart

13. Classification of Diagram Types
Static/Dynamic
Phase
Use case
Dynamic
Requirements
Class
Static
Design
Object
Sequence
Collaboration
Statechart
Activity
Component
Code
Deployment
Deploy

14. Use Case Diagram Defines the outside view Elements
Actors (stick figures): anything outside the system that interacts with it
Use cases (ovals): procedures by which the actor interacts with the system
Solid lines: indicate how actors interact

15. Example of Use Case

16. Use Case Extensions Dotted lines: show dependencies between procedures
Includes (subroutine)
Extends (variation)

17. Example of Use Case

18. Example of Use Case
(customer name)

19. Use Case Usage determining features (requirements)
basis for communicating with clients
generating test cases

20. Class Diagrams
Static structure of the system. What interacts, but not what happens.
Class notation is a rectangle divided into three parts
class name (abstract classes are in italics)
attributes
operations

21. Class Relationships association aggregation generalization
relationship between instances of the two classes
may have a role name to clarify the nature of the association
link connecting two classes
navigability arrow shows which direction the association can be traversed or queried. Also shows ownership
No arrow means bidirectional
multiplicity of an association end is the number of possible instances of the class associated with a single instance of the other end
0..1 zero or one instance
n . . m n to m instances
0..*  or  * no limit on the number of instances (including none)
1 exactly one instance
1..* at least one instance
aggregation
association in which one class belongs to a collection
diamond end pointing to the part containing the whole.
generalization
inheritance link indicating one class is a superclass of the other

22. Class Diagram Example

23. Object Diagrams
object diagram: instantiates class diagram

24. Sequence Diagram Interactions between objects Elements
Objects (oblong boxes or actors)
Box implies creation
Messages (solid lines for calls, dotted for replies): interactions between objects
May include iterations and conditions
Object lifelines (dotted lines): life time of object
Activation bar (vertical oblong box on lifeline): thread of control for synchronous systems

25. Example Sequence Diagram

26. Collaboration Diagram
Alternative to sequence diagram
Loses timing information
Relative sequence may be added with order numbers
Focus on object roles instead of the times that messages are sent
Object roles are the vertices and messages are the connecting links

27. Example Collaboration Diagram

28. Statechart Diagram Often used in real-time embedded systems
Shows the order in which incoming calls normally occur
Elements
States (oblong boxes): stable states; includes actions in second segment
Transitions (solid arrows): possible change states
Events (text on arrow before /): event that causes the transition
Conditions ([ ] after Event): qualifies event
Actions (text on arrow after /)

29. Example of Statechart Diagram

30. Activity Diagram General purpose flowchart Elements
Active states (oblongs with rounded corners): what is done
Transitions (arrows): represent a thread of activity.
Conditions (in [ ] on transitions)
Decisions (diamonds)
Swimlanes (vertical lines the length of the diagram): allow activities to be assigned to objects.
Synch States (solid lines) split or merge transitions

31. Example of Activity Diagram

32. And… Component Diagram Deployment Diagram
software components, interfaces, and dependencies
Deployment Diagram
Nodes, communication links, and components

33. Example of Component Diagram

34. Example of Deployment Diagram
                                                                                                   

35. Pitfalls of UML
can feel like you’ve accomplished more than design because there are tools and artifacts
need to know when to stop designing
variant of analysis paralysis

36. Symptoms of UML Fever (Bell, Queue, March 2005)
expecting more from UML than it was ever intended to do (performance, fault tolerance)
taking UML to too detailed a level
UML products become most of the milestones
UML syntax discussions dominate design brainstorming sessions
“if it can’t be described in UML, it’s not relevant”
UML designed without user input

37. How would you use these different tools?