UML
Overview
UML Overview
1
UNIFIED Modeling Language
OMG adopted UML in November 1997 as the standard for
object-oriented modeling

Combines commonly accepted concepts from many OO
methods


Seamless from requirements to deployment

Applicable to any domain
Language and platform independent


Usable with any development process
UML Overview
2
Unified MODELING Language
All engineering disciplines have adopted modeling
techniques

Allows to capture the important aspects of a system while
omiting the rest

Model is easier to use than final system

Help all software systems stakeholders understand what
the system will be and what are the possible options
available

UML Overview
3
Unified Modeling LANGUAGE
Language for:
Visualizing: Graphical models with precise semantics
Specifying: Models are precise, unambigous and
complete to capture all important Analysis, Design, and
Implementation decisions.
Constructing: Models can be directly connected to
programming languages, allowing forward and reverse
engineering
Documenting: Diagrams capture all pieces of
information collected by development team, allowing to
share and communicate the embedded knowledge.
UML Overview
4
UML Bird’s Eye View
• Building Blocks:

Things: abstractions, main concepts in a model

Relationships: tie the things together

Diagrams: group interesting collections of things
UML Overview
5
UML in a Nutshell

Static Structure
Dynamic Behavior

Model Management

Extensibility Constructs

UML Overview
6
Diagrams in the UML
•
•
•
•
•
•
•
•
•
Class diagram
Object diagram
Use case diagram
Sequence diagram
Collaboration diagram
Statechart diagram
Activity diagram
Component diagram
Deployment diagram
UML Overview
7
Things in the UML
• Structural Things (7)
static part of a model, conceptual or physical
elements

nouns of UML Models
• Behavioral Things (2)


dynamic parts of models
verb, representing behavior over time and space
• Grouping Things (1)

Organizational parts of models, decomposition element
• Annotational Things (1)

explanatory parts of models, comments about other
elements

UML Overview
8
Behavioral Modeling



Use Cases / Use Cases Diagrams
Interactions / Interaction Diagrams
Activity Diagrams
UML Overview
9
Use Cases


Description of a set of sequences of actions, that a
system performs to yield an observable result to an enduser
Categories of interactions between the system to be built
and external actors

Identify high-level services provided by the system

Specify the behavior of a system

Popularized by Ivar Jacobson with Objectory

Have been adopted by or have influenced many methods
(eg. OMT, Fusion, Booch)
UML Overview
10
Use Cases (cont.)



Can be applied to whole system as well as part of system
such as a subsystem or a class
Sources of integration tests and system tests
May have variants: specialized use cases or extension of
use cases.

Do not specify any implementation detail

Main communication tool with end-user

Each use case must have a name (simple or path name)
UML Overview
11
Actors

Objects outside the system which play a particular role

Represent the user(s) of the system

Interact with the system through use cases

May participate in more than one use case


May or may not be represented as a class or object in the
object model
Also known as agents (Jacobson)
UML Overview
12
UML Use Case
Graphical Representation
Storage depot system
Delivery
Collection
Clerk
Status
Storage
Use case
Manager
Actor
UML Overview
13
Why Modeling Use Cases



Use Case model describes WHAT the system will do at a
high-level
User focus
- Capture requirements from user's perspective.
- Users are involved.
Goal is to scope the project and give the application some
structure
-Use Cases are the unit of estimation
-Uses Cases are smallest unit of delivery
-One way of estimating the percentage of requirements
captured.
-Prioritizing use cases for "phased delivery" according to
user's immediate needs.
-Better way of estimating the percentage of requirements
completed during development
UML Overview
14
Benefits of use cases






Good way to start identifying objects from scenarios.
Test plan can be immediately generated based on use
cases.
Easier user validation.
Helps technical writers in structuring the overall work on
the users manuals at an early stage.
Better traceability throughout the system development
process.
Quality of the software is improved by identifying the
exception scenarios earlier in the development process.
UML Overview
15
Problems with use cases





What is the right granularity
What is a correct Use Case
Explosion of different scenarios
Focus on functions, with potential for functional
decomposition
Too often too informal
UML Overview
16
Use Cases and Scenarios




Scenario is a specific sequence of actions
Scenario is one instance of a Use Case
Typically many scenarios correspond to one Use Case
Example:
Use Case = Hire Employee

Scenarios
- Hire at Job Fair
- Hire through newspaper ad
- Hire from internal promotion
- Hire Temp

UML Overview
17
Use Cases and Collaborations







Use Case captures WHAT the system does
Use Cases do not specifies HOW the System does it
Development effort is aimed at implementing the use
cases by creating a society of classes working together
These interacting classes are modeled using
Collaborations
A Collaboration is the realization of a Use Case
A Collaboration represents how responsibilities are
distributed across objects
A Collaboration has a Static and a Dynamic aspect
UML Overview
18
Organizing Use Cases
Relationships: Generalization, Include (Use) and Extend
Generalization:
–
Like for Classes
Include:
- Use: Contains another complete use-case
Extend:
- Extends another use-case
- used for optional separate flow (exception)
Beware:
- Over-use of extends = functional decomposition
- Rumbaugh says Use = aggregation and Extend =
inheritance
UML Overview
19
Hints and Tips
•
•
•
•
•
Each Use Case should represent a single, identifiable and
reasonably atomic part of the behavior of the system
Factors Common Behavior by pulling such behavior from
other use cases that it includes
Factors variants by pushing such behavior into other use
cases that extend it
Describe flow of vents clearly enough for anyone to easily
understand it
Each Use Case is described by a number of scenarios that
specify the normal and variants
UML Overview
20
Use Case Diagrams





system is represented by a large rectangle
uses cases are represented as ellipses within the
system rectangle
actors are represented as stick figure outside the system
an arrow connects the initiating actor to the use case
(ending at the use case)
other participating actors are joined by arrows
terminating at the actor
UML Overview
21
Banking System Use Case Diagram
open_account
Cash
Dispenser
withdraw_cash
Customer
clear_checks
Clerk
loan_application
Manager
get_report
UML Overview
Loan Officer
22
Use Case Identification Steps
•Determine the boundary of the system
- consider system as a single “black box” object
•Identify who is going to be using the system directly - e.g.
hitting keys on the keyboard. These are the Actors
- start by considering physical object
- an individual object may play several roles
•Choose One of these Actors and determine the fundamental
ways in which each actor uses the system
- each of these is a use case
- must be enumerable
- for each of those Use Cases decide on the most usual course
when that Actor is using the system. What normally happens. This
is the basic course
UML Overview
23
Use Case Identification Steps (2)
•
Describe it as "Actor does something, system does
something. Actor does something, system does
something." but keep it at a high level.

do not mention any GUI specifics
only describe things that the system does that the actor
would be aware of and conversely you only describe what the
actor does that the system would be aware of.

do not worry about the alternate paths (extends) or common
courses (uses) - Yet 
•
Review each Use Case descriptions against the
descriptions of the other Use Cases.
• Once basic course is OK, consider the alternates and
add those as extending use cases.
UML Overview
24
Use Case Identification Steps (3)
• Good way of getting started with Use Case modelling.
• Once started and comfortable with this process, next
step:
understand the trade-offs that can be made

simplicity versus "completeness"

putting too much in is the most common mistake.

UML Overview
25
Use Case Textual Descriptions
OPEN_ACCOUN
T
- a clerk requests the system to create a new
account
WITHDRAW_CASH
- a customer requests the system to withdraw a
specified amount of money from a specified
account
CLEAR_CHECKS
- a clerk instructs the system to update all accounts
according to specified transactions including checks
LOAN_APPLICATION - a customer files a loan application
GET_REPORT
- a manager or loan officer requests a report of the
days transactions from the system
UML Overview
26
Use Cases Diagram Hint and Tips
•
•
•
•
•
Put all the Use Cases that describe one aspect of the
system together
Contains only those use cases and actors essential to
understanding that aspect
Diagram should be named to communicate its purpose
Minimize crossing lines
Don’t draw too many use cases or too many
relationships in one diagram
UML Overview
27
UML
Basic Structural Modeling
UML Overview
28
Basic Structural Modeling
• Classes

Attributes, Operations, Responsibilities
• Relationships
Dependency, Generalization, Association, Role,
Multiplicity, Aggregation

• Common Mechanisms
Specifications, Adornments, Common Divisions,
Extensibility Mechanisms

• Diagrams

Class , Object , Component , Deployment Dagrams
UML Overview
29
Classes

Most important building block of any object-oriented system

Description of a set of Objects

Implements one or more interfaces

Abstraction of the entities existing in the problem domain
Planet
Astronaut
Shuttle::Astronaut
simple names
path names
UML Overview
30
Attributes

named properties of classes that describe a range of
values

represent some property of the thing being modeled

each attribute has one value for each object


listed in the attribute compartment underneath the name
box
normally no need for an explicit “ID” attribute
Mission
Shuttle
weight : Integer
age : Integer
status: enum = on-ground
start : Date
end : Date
cost : Dollars
UML Overview
31
Operations




implementation of a service that can be requested from
any object of the class
what you can do to/with an object
are listed in an additional box underneath the attribute
box
SYNTAX- name (arg1 : type, arg2 : type ...) : result
Shuttle
start_engines()
stop_engines()
fuel_level() : integer
launch(t:time)
UML Overview
32
Organizing Attributes and Operations
• Ellided
• Empty compartment

drawing an empty compartment makes no statement
about the absence of attributes or operations
• Prefix groups with Stereotypes to


group together attributes / operations with common
characteristics
represent a metaclassification of the attributes /
operations
UML Overview
33
Responsibility
• Contract or obligation of a class
• Starting point for modeling a class
• Responsibilities are translated into a set of attributes
and operations
• Free-form text, in separate compartment at the bottom
of the class
Shuttle
Responsibilities
-- Carry astronauts
and payload to low
orbit space
UML Overview
34
Other Features
• When need to separate the implementation of a
class from its specification, use Interface
• Advanced features such as

attribute or operation visibility

language-specific features
• Common pre-specified classes modeled with

active classes

components

nodes
UML Overview
35
Modeling Classes
• What is a Class?
• Where do I find a Class?
• Where do I find Attributes?
• What the difference between a Class and an Attribute?
• How do I set responsibilities within Classes ?
UML Overview
36
Hints and Tips
• Classes should map to relevant abstraction in
problem (and solution) domain
• Embodies small set of well defined responsibilities
• Understandable and simple, yet extensible and
adaptable
• Contain only the relevant properties
UML Overview
37
Relationships
•
•
•
•
•
Connection among things
How Classes are related to one another
(Almost) As important as Classes
Ways things collaborate
Three main type:

Dependencies

Generalizations

Associations
UML Overview
38
Dependency
• Using Relationships
• A Change in one thing may affect the other thing
that uses it.
• Most often between a class that uses another clas
as a parameter to an operation
Shuttle
Engine
start_engines()
stop_engines()
fuel_level() : integer
launch(t:time)
UML Overview
39
Generalization
• Relationship which organizes classes based on their
similarities and differences
• Relationship between a general thing (the
superclass) and a more specific thing (the subclass)
• sometimes called “is-a-kind-of” or “is-a” relationship
• Child is substitutable for the parent
• Child inherit properties of parent
• corresponds to inheritance in object-oriented
languages
• NOTATION 
an arrow whose head is next to the specialization
Spacecraft
Shuttle
UML Overview
40
Subclasses



inherit the attributes, operations and associations of
their superclass(es)
must obey all semantic restrictions of their
superclass(es)
can override the implementation of an operation
vehicle
size
speed
water vehicle
draft
land vehicle
wheels
UML Overview
41
Ancestors/Descendants


the terms ancestor and descendant refer to
generalization across multiple levels.
an instance of a class is simultaneously an instance
(transitively) of all its ancestors
fruit
...
...
apple
cox
granny smiths
UML Overview
42
Associations

describe a group of links with common structure and
semantics

are to links what classes are to objects

can have a different name in each direction
Person
Employs
Works-for
Organization
Works-for
Dan Goldin
NASA
Bill Gates
Microsoft
John Smith
Rockwell
...
UML Overview
...
43
Associations Continued

defined solely by the classes which they connect

associations are not part of the participating classes

associations should not be modelled by attributes
Astronaut
Mission
assigned_to : string
Astronaut
Assigned_to
WRONG
full_name : string
Mission
full_name : string
UML Overview
RIGHT
44
Roles



correspond to one end of an association
each end of an association may be assigned a role
which serves as its unique identifier
provide a way of traversing a binary association from
one object to a set of related objects

represent a form of specialization

are written next to the association line
Astronaut
0..*
conducts
0..*
Experiment
mission-specialist
UML Overview
45
Multiplicity


the number of instances of one class that may be
related to an instance of another
constrains the number of links between objects
1
1..*
Class
exactly one
0..*
Class
mandatory (one or more)
Class
many (zero or more)
0..1
Class
optional (zero or one)
2..4, 6..8
Class
numerically specified
UML Overview
46
Aggregation

a special form of association between a whole and its
parts

relates an assembly class to its component classes

is transitive but not symmetric (commutative)

depicted by a diamond at the assembly end

two kinds physical
- a part cannot be in more than one
“whole”
catalog
- a part can be in several “wholes”
UML Overview
47
Aggregation Examples
Document
Crew
1..*
1..*
*
4..6
Sentence
Space Center
1..*
Word
Astronaut
2
Shuttle
*
3
1..*
Wings
Engines
Building
UML Overview
48
Aggregation Example - Graphical interface
Window
*
Pane
TitleBar
0..2
ScrollBar
Border
2
Close Button
Title
Arrow
UML Overview
Indicator
49
Aggregation - Tree-like Notation
Window
*
Pane
TitleBar
0..2
ScrollBar
Border
2
Close Button
Title
Arrow
UML Overview
Indicator
50
Lab Work on UML - Part 1
• Review Use Case Development Process from
Rational Unified Process

Use Case Finding

Use Case Details
• Develop Use Case Model using Rational Rose
• Develop Use Case Specification Document
UML Overview
51
Lab Work on UML - Part 2
• Review Class Diagram Development Process from
Rational Unified Process
• Develop Class Model using Rational Rose
UML Overview
52
Descargar

Unified Method : Class Diagrams