Unified Modeling Language

(UML)

Troy Mockenhaupt

Chi-Hang ( Alex) Lin

Pejman ( PJ ) Yedidsion
 Overview
 Definition
 History
 Behavior Diagrams
 Interaction Diagrams
 Structural Diagrams
 Tools
 Effect on Software Engineering
 Definition
 A standard language for specifying, visualizing,
and constructing software artifacts
 Non-restrictive
 Expressive and visual modeling language
 Independent of language and process
 History
 First modeling languages emerge 1970s
 “method wars” of the 1990s
 Methods began merging techniques
 1994 – Booch and Rumbaugh unify Booch and
Object Modeling Technique
 1995-1996 Jacobson incorporates OOSE
methods – term UML is coined
 1997 – Object Management Group (OMG)
accepted UML as standard
 History (cont.)
 UML 2.0 adopted in 2005
 2.1.1 and 2.1.2 in 2007 ( never formally
released )
 UML 2.2 in 2009
 UML 2.3 in 2010
 UML 2.4.1 2011
 UML 1.x vs 2.x
1.x vs 2.x Significant changes

1.x 2.x

Activity Diagram Specialized form of Increasing the scope

State Diagrams of usage

Package Diagram Insufficient for large Added

models

Component Diagram No port and Added

connectors

Timing Diagram No syntax for timing Added

purposes
 Behavior Diagrams
● Activity Diagram (basic program flow & capture decision points)
● Use Case Diagram (model user/system interactions)
● State Machine Diagram (“run state” of a model when it executes)
 Activity Diagram
● Shows the overall flow of control
● Comprises: choice, iteration, and concurrency
● Business and operational step-by-step
workflows of components in a system
● A form of flowchart that has capability to
express concurrency
● Graphical representations of workflows of
stepwise activities and actions
 Activity Diagram (cont.)
● Similar to state machine diagrams
● Business process modeling
● Object-oriented equivalent of flow charts and
data flow diagrams from structured
development
Activity Diagram (cont.)
 Use Case Diagram
● Interaction of users with the system
● Contains different types of users and the
various ways they interact with the system
● Depicts Actors and their goals represented as
use cases, as well as any dependencies among
those use cases
o Actors - entities external to the system
 Use Case Diagram (cont.)
● A use case typically includes:
o Name and Description
o Requirements (formal functional requirements)
o Constraints (condition or restriction)
o Scenarios (formal description of the flow of events)
o Scenario diagrams (specific sequence of events between the system
and the external actors)

o Additional information (case specific)

 Use Case Diagram (cont.)
● Not a standalone model, but one that can be used
in conjunction with other models
● Outline general behavior, therefore use case
diagram should “focus on business goals rather than
system goals”
● Not a technical outline of functionality, but
provides the business reasoning and outcomes of the
system
Use Case Diagram (cont.)
 State Machine Diagram
● Nodes denote states
● Connectors denote state transitions
● Behavioral state machines
o used to model the behavior of individual entities

● Protocol state machines

o used to express usage protocols
 State Machine Diagram (cont.)
● Organize the way a device, computer program,
or other (often technical) process works--always
in exactly one of a number of possible states
● Overcome some of the limitations of traditional
finite-state machines
● Support actions that depend on both the state
of the system and the triggering event
 State Machine Diagram (cont.)
● Initial &Final States

● Transitions

● State Actions
State Machine Diagram (cont.)
 Interaction Diagrams
 Communication Diagram
 Interaction Overview Diagram
 Sequence Diagram
 Timing Diagram
 Communication Diagram
 Interactions between objects in terms of
sequenced messages
 Combination of info from Class, Sequence, and
Use Case Diagrams
 Free-form arrangement of objects
 Chronological numbered labeling
 Similar to Sequence diagrams with focus on
element interaction
Communication Diagram (cont.)
 Interaction Overview Diagram
 Visualize control flow with nodes
 Frames of interaction diagrams
 Interaction diagrams are building blocks
 Deconstruct complex scenarios
 Activity diagram – initial, join, fork, decision,
merge, and final
 Interaction occurrences and elements
Interaction Overview Diagram(cont.)
 Sequence Diagram
 Detailed flow for use case realization
 Two-Dimensional
 Object instances and interactions
 Interaction order
 Sequence of object interactions
 Object lifelines
Sequence Diagram (cont.)
 Timing Diagram
 Explore behavior of one or more objects during
a given time period
 Similar to sequence diagram with axes reversed
 Concise and Robust notation
 Timing Diagram (cont.)
 Concise Notation
Timing Diagram (cont.)
 Structural Diagram
● Class Diagram
● Object Diagram
● Composite Structure Diagram
● Component Diagram
● Package Diagram
● Deployment Diagram
● Profile Diagram
 Class Diagram
● Define Classes Diagram

● Introduce Class Diagram

1. Notations

● Relationships between classes

 Class Diagram (cont.)
● Class Diagram describes set of classes,
interfaces and their relationships
● Class Diagram Notations:
1. Class Name
2. Properties of the classes with data types
3. Method names with data types
4. Visibility: +, #, ~, - (in the order of visibility)
5. Static members
Class Diagram (cont.)
 Class Diagram (cont.)
● Dependency – A class needs to know about another class
● Association – A class contains the reference of an object to
another class
● Aggregation – A class owns another class
● Composition – A class is made of other classes
● Inheritance – A class is a type of another class
● Constraints –
1. Invariants – must always be true
2. Pre conditions – check before execution
3. Post conditions – checked after execution
● Abstract Classes – Generic class, leaves implementation for
sub classes
● Interfaces – Defines methods which must be implemented
Class Diagram (cont.)
Relationships between classes
Class Diagram (cont.)
 Object Diagram
● Define Object Diagram:
1. Bringing classes to life
2. Demonstrates an instance of a class at a particular point of time

● Introduce Object Diagram Properties / Syntax:

1. Object, Object:Class, :Class
2. Links (Association)
3. Notes, Note connector
4. Use Object Constraint Language (OCL)
Object Diagram (cont.)
 Composite Structure Diagram
● Define Composite Diagram
1. How objects create a big picture
2. How objects work together to achieve goals

● Deficiency of Class Diagram

● Introduce Composite Diagram
● Class Diagram V.S. Composite Diagram
Composite Structure Diagram
(cont.)
Composite Structure Diagram
(cont.)
 Component Diagram
● Define Component Diagram
1. Shows key components of a system
2. High-level picture of a system
3. Manage complexity and dependencies
4. Manageable, reusable and swappable
5. Good candidates are frequently used functionality: logger, XML parser,
and shopping carts
 Component Diagram (cont.)
● Introduce Component Diagram
1. Components
2. Interfaces
a. Provider interfaces (ball) on the left
b. Required interfaces (socket) on the right

3. Dependencies and Inheritance

a. Model dependencies from left to right
b. Place child components below parent component
c. Components should only depend on interfaces
Component Diagram (cont.)
A simple e-commerce system
 Package Diagram
● Define Package Diagram:
1. Organize most UML elements
2. Manage dependencies among packages
3. Package related elements into groups
 Package Diagram (cont.)
● Manage dependencies among packages
1. Avoid too many dependencies
2. Avoid cycles
 Package Diagram (cont.)
Package related elements into groups:
Package Diagram with Use Cases
 Deployment Diagram
● Define Deployment Diagram: Demonstrates the
physical deployment of artifacts on nodes
● Introduce Deployment Diagram
1. Artifact – physical files that execute or used by software, e.g. .exe, .jar,
.dlls, .java, .cpp, .xml, .txt
2. Node – hardware or software resources that can host software or
related files, e.g. server, disk drives, OS, web server, application server
3. Device Node – physical resource (hardware) with processing capability
4. Execution environment– web server, application server, OS

● When to use Deployment Diagrams?

Deployment Diagram (cont.)
Early stage
Deployment Diagram (cont.)
Late stage
 Profile Diagram
● Define Profile Diagram: Customizes UML for a
specific platform
● Introduce Profile Diagram:
1. Stereotypes – indicates a special usage
2. Tagged Values – additional information about the stereotype
3. Constraints

● Why Profile Diagram? Plug-ins, OMG profiles

 UML Tools
● Software applications that support some or all
of the notations and semantics
● Types of Functionality supported:
● Diagramming - creating and editing
● Round-trip engineering:
 Code generation- derives from the diagrams part or all of the source
code for the software system

 Reverse engineering- reads program source code as input and derives

model data and corresponding graphical UML diagrams
 UML Tools (cont.)
● Limitations:
o UML diagrams lack the detail that is needed to
contain the same information as is covered with the
program source
o Source code often has more detailed information
than in design diagrams
● Future use and development of tools
 UML Tools (cont.)
● Examples of current UML modeling tools:
 IBM Rational Rose, ArgoUML, BOUML, Dia, Enterprise
Architect, MagicDraw UML, Modelio, PowerDesigner,
Rational Rhapsody, Rational Software Architect, StarUML,
and Umbrello

● Examples of development environments

offering UML modeling tools:
 Eclipse (also includes reverse engineering architecture),
NetBeans, and Visual Studio
UML Tools (cont.)
 Effect on Software Engineering
 Improve communication with all
stakeholders
 Useful for communicating designs
 A thinking aid during design phase
 Independent of programming languages
 Reduce development and maintenance cost
 Great tool for training new developers
 Standardization allows for advancement of
tools and concepts
 Effect on Software Engineering
(cont.)
 Can over complicate development process if
not used properly
 Can get bogged down in notation and details
 Can over complicate and over lengthen design
documents
 Relatively significant learning curve to fully
master
 Review
 Defined UML
 Provided a History
 Covered Behavior Diagrams, Interaction
Diagrams, and Structural Diagrams
 Introduced some UML Tools
 Discussed the Effect on Software
Engineering
Unified Modeling Language
(UML)

THE END