Introduction to the

Unified Modeling
Language

OOP
Software Engineering Major
Universidad de las Fuerzas Armadas-ESPE
Computer Science Department
Jorge Edison Lascano
Based on the slides of Dr. Stephen Clyde, Utah State University
Unified Modeling Language

š UML is an object-oriented modeling language (or

more precisely, a collection of modeling languages)
that is
š expressive
š semi-formal
š capable of supporting incremental development
š Elements can be hidden
š Certain elements can be left incomplete
š Inconsistencies can exist
š process independent
š UML can be used with a variety software development
process models
š Customizable and extensible
A Brief Timeline for OO and UML

š 60’s
š Birth of initial OO ideas
š 70’s
š Nurturing of OO ideas
š Introduction of a few more OO Programming Languages
š 80’s
š Maturing of fundamental OO concepts
š Emergence of more OOPLs
š OOPLs gain widespread use
A Brief Timeline for OO and UML

§ 90’s
š The Method Wars
š Efforts to unify concepts
š Introduction and standardization of UML
š Emergency of next-generation ideas, like Patterns
š Current
š Widespread use of UML
š Widespread use of Full-Life-Cycle development tools
UML Building Blocks

š Modeling Elements
Student
š Scoping
š Structural major: String
gpa: Real
š Behavioral
standing: String
š Organizational Contacts
š Annotational add(Course)
drop(Course)
š Extension
-- Handle a registration in
š Diagrams that
communicate ideas using courses
the modeling elements See Fig. 2 for Registered 0..*
š Modeling Elements are more details Student
is in
like words.
Role
š Diagrams are like 0..*
sentences or paragraphs Graduate Course
š Models are like whole Course
papers or books
Modeling Elements
Modeling Elements are building blocks for
constructing conceptual descriptions of systems

š Definition and Scope ! Behavioral Things

š Use Cases – Messages
– States
š Automation Boundaries – Transitions
š Structural – Events
š Objects ! Organizational Things
š Classes – Packages
š Relations – Views
š Interfaces ! Annotation
š Components – Comments
š Nodes – Specifications
š Extension
š Templates
š Stereotypes *Note that this is not a complete list
UML Diagrams

š Use Case Diagrams

š Class Diagrams
š Object Diagrams
š Interaction Diagrams
š Sequence Diagrams
š Communication Diagrams
š State Charts (enhanced State Machines)
š Activity Diagrams
š Component Diagrams
š Deployment Diagrams

*Note that this is not a complete list

Views

š A view is a set of diagrams that describe one aspect of a

system or describe the system from a given perspective
š Views are like the chapters of a book
š Some common views:
š Use-case view
š Logical view
š Implementation view
š Process view
š Deployment view
Views and Methods

š The construction and ultimate value of a view is that it is closely

tie to the process used to create the view.
š The process imposes a certain perspective on the modeling
activity
š To understand a view, one needs to know the intended
perspective
Three Software-Engineering
Modeling Perspectives

š Analysis – for understanding

š The objects represented in the models are real-world objects
š Models focus on problem-domains concepts
š They describe systems as they are

š Specification / High-level Design – for solving

problems, scoping, and planning
š The models include both real-world and software objects
š The models show automation boundaries
š The models describe what the system is to become

š Implementation – for construction

š The objects in the models are mostly software objects
š The models focus on solution-oriented concepts
š The models describe what the software system is or will be
 Analysis Perspective
Student
name
major
GPA
š Classes are sets of objects standing
interests

š Classes may include attributes

-- The set of students
and operations, but more know the registration
importantly their intents are system

defined by responsibilities Registered 0..*

Student is in
š Relationships are set of links *..0

between objects Course

name
š Components relate to the
problem domain -- The set of possible
courses
Specification Perspective
StudentR

name
major
GPA š Classes define abstraction
standing boundaries and encapsulations for
interests
software objects
-- The set of students know the
registration system

StudentS

name: String
major: String
GPA: real
standing: Scode
add(Course)
drop(Course)
-- Software representation of students;
support registration in courses
Implementation Perspective
StudentDialogBox Student
major: String
create()
GPA: Real
doDataExchange()
standing: String
onDelete()
onInsert() add(Course)
onOK() drop(Course)
-- Interact with user to add -- Handle a registration in
drop courses courses
0..1

1
Course
callNumber: Integer
CourseList department
number
-- Display a dynamic list section
courses title
Implementation Perspective
CObject

š Classes can represent software

components in frameworks,
CCmdTarget libraries, or external systems

CWnd

CDialog CListBox

0..1 1
StudentDialogBox CourseList

-- Interact with user to add -- Display a dynamic list

drop courses courses
Software Development
Activities

š Regardless of the process, a software development project typical

includes:
š Requirements capture and analysis
š Design
š Implementation
š Deployment
š We’ll refer to these as primary software development activities
Software Development
Activities

! We accomplish the core software development

activities, at least in part, by:
š Managing people & resources (i.e., planning, tracking, reporting,
etc.)
š Conceptual Modeling ***
š Coding ***
š Testing ***
š Documenting *
š Managing work artifacts (i.e., configuration management) *
! We refer to these as pervasive or cross-cutting
software development activities

*** -- Primary focus of this course

** -- Secondary focus of this course
* -- Lightly covered in this course
Types of Diagrams

š Structural Diagrams
š Class Diagrams
š Object Diagrams
š Component Diagrams
š Deployment Diagrams
š Behavioral Diagrams
š Use Case Diagrams
š Sequence Diagrams
š Collaboration Diagrams
š Statechart Diagrams
š Activity Diagrams
 Types of Diagrams

¨ show classes, interfaces,

š Structural Diagrams
collaborations, and their
š Class Diagrams relationships
š Object Diagrams ¨ commonly found in OO modeling
languages
š Component Diagrams ¨ used to illustrate static design
š Deployment Diagrams views
š Behavioral Diagrams ¨ can be used to illustrate a static
process view of a system
š Use Case Diagrams
š Sequence Diagrams
š Collaboration
Diagrams
š State chart Diagrams
š Activity Diagrams
 Types of Diagrams

š Structural Diagrams ¨ show objects and their

relationships
š Class Diagrams ¨ used to illustrate static
š Object Diagrams snapshots of class instances
¨ address the static design view
š Component Diagrams of static process view of a
š Deployment Diagrams system
š Behavioral Diagrams ¨ differ from class diagram in
that they show individual real
š Use Case Diagrams or prototypical cases
š Sequence Diagrams
š Collaboration Diagrams
š State chart Diagrams
š Activity Diagrams
Types of Diagrams
š Structural Diagrams ¨ show components and their
š Class Diagrams relationships
¨ used to illustrate static
š Object Diagrams implementation views of a
š Component Diagrams system
¨ related to class diagrams in that
š Deployment Diagrams a component typically maps to
š Behavioral Diagrams one or more classes, interfaces
or collaborations
š Use Case Diagrams
š Sequence Diagrams
š Collaboration Diagrams
š State chart Diagrams
š Activity Diagrams
Types of Diagrams

š Structural Diagrams ¨ show nodes and their

relationships
š Class Diagrams ¨ used to illustrate static
š Object Diagrams deployment views of an
architecture
š Component Diagrams ¨ related to component diagrams
š Deployment Diagrams in that a node typically encloses
one or more components
š Behavioral Diagrams

š Use Case Diagrams

š Sequence Diagrams
š Collaboration Diagrams
š State chart Diagrams
š Activity Diagrams
 Types of Diagrams
š Structural Diagrams ¨ show use cases and actors
š Class Diagrams ¨ used to illustrate use case views
of a system
š Object Diagrams
¨ help organize and model the
š Component Diagrams behavior of a system

š Deployment Diagrams
š Behavioral Diagrams

š Use Case Diagrams

š Sequence Diagrams
š Collaboration Diagrams
š State chart Diagrams
š Activity Diagrams
Types of Diagrams

š Structural Diagrams ¨ are interaction diagrams that

emphasize the time ordering
š Class Diagrams of messages
¨ show object and the
š Object Diagrams messages that they send or
š Component Diagrams receive
¨ include objects that are
š Deployment Diagrams named or anonymous
š Behavioral Diagrams ¨ used to illustrate dynamic
specific or design views of a
š Use Case Diagrams system
š Sequence Diagrams
š Collaboration Diagrams
š State chart Diagrams
Types of Diagrams
¨ are interaction diagrams that
š Structural Diagrams emphasize the structural
š Class Diagrams organization of
communicating objects
š Object Diagrams
¨ show objects, links among
š Component
Diagrams those objects, and
messages
š Deployment
Diagrams ¨ include objects are are
named or anonymous
š Behavioral Diagrams
¨ used to illustrate dynamic
š Use Case Diagrams views of a system
š Sequence Diagrams
š Collaboration
Diagrams
š State chart Diagrams
š Activity Diagrams
Types of Diagrams

š Structural Diagrams
¨ show state machines consisting
of states, transitions, events, and
š Class Diagrams activities
š Object Diagrams ¨ emphasize event-ordered
behavior
š Component Diagrams
¨ used to model behavior of
š Deployment Diagrams objects in terms of classes,
š Behavioral Diagrams interfaces, or collaborations
¨ used preliminary in design and
š Use Case Diagrams
implementation views
š Sequence Diagrams
š Collaboration Diagrams
š State chart Diagrams
š Activity Diagrams
Types of Diagrams

¨ show flow of activities within a

š Structural Diagrams system, their typical ordering
(sequential or branching), and
š Class Diagrams the object that act or are acted
š Object Diagrams upon
š Component Diagrams ¨ emphasize flow of control
¨ used to illustrate dynamic
š Deployment Diagrams
specification and design views
š Behavioral Diagrams
of a system
š Use Case Diagrams
š Sequence Diagrams
š Collaboration
Diagrams
š State chart Diagrams
š Activity Diagrams
More on Views

š Views are collections of diagrams that

describe a system from a certain
perspective, e.g.
š Use-case view
š Logical view
š Implementation view
š Process view
š Deployment view
š Note that you’ll see a wide variation in the
prescribed view across different methods or in
different textbooks
Modeling Systems From
Different Views

š Decide which views you need to best complete the software

engineering process
š For example, a group calendar system may require all the views
mentioned earlier
š For each view, decide which types of diagrams you need to
capture the essential details
š For example, use case, class, and activity diagrams may make up your
Use Case View
Modeling Systems From
Different Views

š Decide which diagrams you want to place under change control

(configuration management)
 Modeling Different Levels of
Abstraction

š Different development activities and discussions require different

levels of abstraction
š Two ways to model different levels of abstraction:
š using diagrams with different levels of detail from the same model
š creating models at different levels of abstraction, but can be traced
from one to another
Modeling Complex Views

š First, explore ways of expressing the information at a higher level of

abstraction that is still meaningful but reduces complexity
š Consider grouping some of the elements in packages or in higher
level collaborations
š Use notes and color as visual cues
š Print the view in its entirety, hang it on a (very) large wall, step back,
and look for patterns
Hints and Tips

š Remember that the purpose of diagrams is not have pretty

pictures, but to visualize, specify, construct, and document, and
most importantly COMMUNICATE
š Not all diagrams are meant to be preserved
š Avoid extraneous or redundant diagrams
š Don’t oversimplify
š Keep a balance between the structural and behavioral diagrams
Hints and Tips

š Give each diagram a meaningful name that clearly expresses its

intent
š Keep your diagrams organized
š Lay out its elements to minimize lines that cross
š Organize its elements spatially so things that are semantically close are
laid out physically close
š Group them into packages according to view
š Don’t obsess over the format of a diagram
š Let tools help you
Some Interesting UML Modeling
Questions

š How do we discover objects or classes?

š When should we focus on problem-domain
objects, solution-domain objects, or
environment objects?
š How can we keep the different perspectives
straight?
š Should each perspective be captured by a
different model or can they all be managed
in one model?
š How much detail should you put in a
diagram, a view, or a model?
More UML Modeling Questions

š How should you distribute responsibilities among classes?

š What happens when classes get too big, i.e. inadequate
distribution?
š What happens when classes are too small, i.e. too fine of grain
distribution?
š What happens when there are a lot of dependency relationships
between classes, i.e., inappropriate or ad hoc distribution?
WHAT IS NEXT…

Use Cases