27 March

1
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
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?

8
What UML Is and Isnt

• 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)

9
References

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

10
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

11
Classification of Diagram Types
Diagram Static/Dynamic Phase
Use case Dynamic Requirements
Class Static Design
Object Static Design
Sequence Dynamic Design
Collaboration Dynamic Design
Statechart Dynamic Design
Activity Dynamic Design
Component Static Code
Deployment Static Deploy
12
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

13
Example of Use Case
14
Use Case Extensions

• Dotted lines show dependencies between
  procedures
• Includes (subroutine)
• Extends (variation)

15
Example of Use Case
16
Example of Use Case
(customer name)
17
Use Case Usage

• determining features (requirements)
• basis for communicating with clients
• generating test cases

18
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

19
Class Relationships

• association
• 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

20
Class Diagram Example
21
Object Diagrams

• object diagram instantiates
  class diagram

22
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

23
Example Sequence Diagram
24
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

25
Example Collaboration Diagram
26
Benefits? Tradeoffs?
27
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 /)

28
Example of Statechart Diagram
29
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

30
Example of Activity Diagram
31
And

• Component Diagram
• software components, interfaces, and dependencies
• Deployment Diagram
• Nodes, communication links, and components

32
Example of Component Diagram


33
Example of Deployment Diagram

                                                                                                   

34
(No Transcript)
35
Pitfalls of UML

• can feel like youve 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 cant be described in UML, its not
  relevant
• UML designed without user input