27 March

UML: Unified Modeling Language

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

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

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

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

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

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

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?

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)

References

www.uml.org Fowler, UML Distilled, Addison-

Wesley 3rd edition, 2004, covers 2.0 Short Good summary charts on inside

covers

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

Use case

Class

Object

Sequence

CollaborationStatechart

Activity

Component

Deployment

Classification of Diagram TypesDiagram 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

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

Example of Use Case

Use Case Extensions

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

Example of Use Case

Example of Use Case

(customer name)

Use Case Usage

determining features (requirements)

basis for communicating with clients

generating test cases

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

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

Class Diagram Example

Object Diagrams

object diagram: instantiates class diagram

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

Example Sequence Diagram

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

Example Collaboration Diagram

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

Example of Statechart Diagram

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

Example of Activity Diagram

And…

Component Diagram software components, interfaces, and

dependencies Deployment Diagram

Nodes, communication links, and components

Example of Component Diagram

Example of Deployment Diagram

                                                                                                   

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

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

How would you use these different tools?