UML

José Vargas Mery
Diagramas UML
 UML ofrece cinco grupos diferentes de diagramas
para modelar un sistema
– Casos de Uso
– Estructura
– Estado
– Comportamiento
– Implementación
Diagramas UML
Diagramas de
Casos de Uso
Diagramas
de Clases
Diagramas
de Objetos
Diagramas de
Colaboración
Diagramas de
Secuencia
Diagramas de
Estados
Diagramas de
Actividades
Diagramas de
Despliegue
Diagramas de
Componentes
Modelo del
Sistema
Diagramas UML
 Casos de Uso
– Diagramas de Casos de
Uso

 Estructura
– Diagramas de Clases
– Diagramas de Objetos

 Estado
– Diagramas de Estados
– Diagramas de
Actividades
 Comportamiento
– Diagramas de Secuencia
– Diagramas de
Colaboración

 Implementación
– Diagramas de
Componentes
– Diagramas de
Despliegue
Actividades Generales del análisis Orientado Objeto
1. Modelar las funciones del sistema.
2. Encontrar e identificar los objetos del negocio.
3. Organizar los objetos e identificar sus relaciones.
4. Modelar el comportamiento de los objetos.
Modelación de Casos de Uso
 Modelación de las funciones de un sistema en términos de los
eventos del negocio, quién los inicia, y cómo responde el
sistema a ellos.
Caso de Uso
 Secuencia de pasos o actividades relacionadas por
su comportamiento (un escenario), tanto
automatizadas como manuales, que tienen como fin
completar una única tarea del negocio.

 Notación en UML
Comprar productos
Actor
 Representa cualquier cosa que necesita interactuar
con el sistema para intercambiar información.
 Un actor es un usuario del sistema, un rol, que puede
ser tanto una persona como un sistema externo.
 En un caso de uso, hay un actor que inicia la acción
y, posiblemente, otros actores participantes.

 Notación en UML
Cajero
Casos de Uso - ejemplo
 El siguiente caso de uso de alto nivel describe el proceso de
comprar artículos en una tienda cuando se emplea una terminal
en el punto de venta.
Caso de uso: Comprar productos
Actores: Cliente, Cajero
Tipo: Primario
Descripción: Un Cliente llega a la caja registradora con los artículos
que comprará. El Cajero registra los artículos y cobra el
importe. Al terminar la operación, el Cliente se marcha
con los artículos comprados.
Cursos de Eventos
 Curso normal de los eventos
– Describe en detalles la interacción entre los
actores y el sistema.
– Un aspecto esencial es que explica la secuencia
más común de los eventos; no incluye situaciones
alternativas.

 Curso alternativo de los eventos
– Describe importantes opciones o excepciones que
pueden presentarse en relación con el curso
normal.
– Si son complejas, se pueden expandir y convertir
en otros casos de uso.
Curso Normal de Eventos
Acción de los actores Respuesta del sistema
1. Este caso de uso comienza cuando un
Cliente llega a una caja TPDV (Terminal
de Punto de Ventas) con productos que
desea comprar.
2. El Cajero registra la identificación de cada
producto.
Si hay varios productos de una misma
categoría, el Cajero también puede introducir
la cantidad.
3. Determina el precio del producto e
incorpora a la transacción actual la
información correspondiente.
Se presentan la descripción y el precio del
producto actual.
4. Al terminar de introducir los productos, el
Cajero indica al TPDV que se concluyó la
captura de productos.
5. Calcula y presenta el total de la venta.
6. El Cajero indica el total al Cliente.
Curso Normal de Eventos
7. El Cliente efectúa el pago en efectivo – el
“efectivo ofrecido” – posiblemente mayor
que el total de la venta.
8. El Cajero registra la cantidad de efectivo
recibida.
9. Muestra al cliente la diferencia. Genera un
recibo.
10. El Cajero deposita el efectivo recibido y
extrae el cambio de pago.
El Cajero le da al Cliente el cambio y el
recibo impreso.
11. Registra la venta concluida.
12. El Cliente se marcha con los artículos
comprados.
Cursos alternativos
·
Línea 2: introducción del identificador inválido. Indicar error.
·
Línea 7: el cliente no tenía suficiente dinero. Cancelar la transacción de venta.
Casos de Uso – Eventos Temporales
 Evento temporal
– Es un evento del sistema que es gatillado por el
paso del tiempo.
– El actor del caso de uso de un evento temporal es
el tiempo.
Beneficios de la Modelación de Casos de Uso
 Base para identificar objetos y sus relaciones
y responsabilidades de alto nivel.
 Visualizar el comportamiento del sistema
desde el punto de vista de una persona
externa.
 Herramienta eficaz para validar requisitos.
 Herramienta eficaz de comunicación.
 Base para un plan de prueba.
 Base para un manual de usuario.
Proceso de Modelación de Casos de Uso
 Paso 1: Identificar Actores y Casos de Uso
 Paso 2: Construir un Diagrama de Casos de Uso
 Paso 3: Documentar el Curso Normal del Caso de
Uso
 Paso 4: Definir Caso de Uso de Análisis
Member
Services
System
Marketing
Department
Potential
Member
Club
Member
Warehouse
Accounts
Receivable
Past
Member
Member
Services
various Inquiry Reponses
various Sales Reports
various
Promotion Reports
Subscription Offer
Member Order
New Subscription
Promotion
Subscription Renewal
Resubscription Offer
various Member
Reports
various Subscription Reports
Subscription Program
New Promotion
Revised Packing Order
Member
Credit
Status
Diagrama de Contexto – Sistema de Servicio
al Cliente
Actor
Potential
Member
Club
Member
Club
Member
Club
Member
Club
Member
Club
Member
Past
Member
Marketing

Marketing


Marketing



Time

Time

Time

Time

Time
Use Case Name
SUBMIT NEW
SUBSCRIPTION
PLACE NEW MEMBER
ORDER
MAKE ACCOUNT INQUIRY

MAKE PURCHASE INQUIRY

MAINTAIN MEMBER ORDER

SUBMIT CHANGE OF
ADDRESS
SUBMIT
RESUBSCRIPTION
SUBMIT NEW MEMBER
SUBSCRIPTION PROGRAM
SUBMIT PAST MEMBER
RESUBSCRIPTION
PROGRAM
SUBMIT NEW PROMOTION



GENERATE QUARTERLY
PROMOTION ANALYSIS
GENERATE QUARTERLY
SALES ANALYSIS
GENERATE QUARTERLY
MEMBERSHIP ANALYSIS
GENERATE ANNUAL SALES
ANALYSIS
GENERATE ANNUAL
MEMBERSHIP ANALYSIS
Use Case Description
Potential member joins the club by subscribing. (“Take anu 12 CDs for
one penny and agree to buy 4 more at regular club prices within two
years.”)
Club member places order.

Club member wants to examine his or her account history.
(90-day time limit)
Club member inquires about his/her purchase history.
(three-year time limit)
Club member wants to revise an order or cancel an order.

Club member changes address.
(including e-mail and privacy code)
Past member rejoins the club by resubscribing.

Marketing establishes a new membership resubscription plan to entice
new members.
Marketing establishes a new membership resubscription plan to lure
back former members.

Marketing initiates a promotion.
(Note: A promotion features specific titles, usually new, that company
is trying to sell at a special price. These promotions are integrated into
a catalog sent (or communicated) to all members.)
Print quarterly promotion analysis report.

Print annual sales analysis report.

Print annual membership analysis report.

Print annual sales analysis report.

Print annual membership analysis report.
Paso 1:
Identificar Actores y Casos de Usos
Paso 2:
Construir un Diagrama de Casos de Usos
Paso 3:
Documentar curso normal del caso de uso
Paso 3:
Documentar curso normal del caso de uso
Paso 3:
Documentar curso normal del caso de uso
Referencia a los requerimientos con los cuales está relacionado.

El curso común del evento que describe los pasos principales del caso del
uso, desde cuando comienza hasta cuando termina la interacción con el actor.

Cursos alternativos que describen excepciones al curso común del evento.

Precondición que describe el estado en que debe estar el sistema para que se
ejecute el caso del uso.

Poscondición que describe el estado en que queda el sistema después de que
se ejecuta el caso del uso.

Supuestos, que incluye cualquier tópico no relacionado con el comportamiento
del caso de uso, tales como rendimiento o seguridad, que está asociado al
caso de uso. En general, son aspectos que son difíciles de modelar dentro del
curso de eventos del caso de uso.
1
2
3
4
5
6
Tipos de Casos de Usos
 Caso de Uso de Extensión
– Amplía la funcionalidad (curso normal) de un
cierto caso de uso.
– Un caso de uso de extensión puede ser invocado
solamente por el caso del uso que está
ampliando.

 Caso de Uso Abstracto
– Contiene los cursos normales que son comunes a
dos o más casos de uso originales.
– Un caso de uso abstracto reduce redundancia y
promueve la reutilización.
Representación usando la notación de UML
Generar Orden de
Despacho
Calcular Subtotal e
Impuestos Pedido
Completar Pedido
Cliente Nuevo
Revisar Dirección
Solicitar Cambio
de Dirección
«extends» «extends»
«uses»
«uses»
Casos de Uso – Relaciones
 UML define tres tipos de relación en los Diagramas
de Casos de Uso

 Comunicación
Actor
Caso de Uso
Casos de Uso – Relaciones
 Inclusión
– Una instancia del Caso de Uso origen incluye
también el comportamiento descrito por el Caso
de Uso destino

<<include>> es equivalente a <<uses>>
Caso de Uso Origen Caso de Uso Destino
<<include>>
Casos de Uso – Relaciones
 Extensión
– El Caso de Uso origen extiende el
comportamiento del Caso de Uso destino
Caso de Uso Origen Caso de Uso Destino
<<extend>>
Paso 4:
Definir Caso de Uso de Análisis
Paso 4:
Definir Caso de Uso de Análisis
Actividades Generales del Análisis Orientado
Objeto
1. Modelar las funciones del sistema.
2. Encontrar e identificar los objetos del negocio.
3. Organizar los objetos e identificar sus relaciones.
4. Modelar el comportamiento de los objetos.
Encontrar e Identificar Objetos del Negocio
 Paso 1: Encontrar objetos potenciales
– Subrayar (o destacar) los sustantivos del caso de
uso
 Paso 2: Seleccionar los objetos propuestos
– Quitar los sustantivos que representan:
• Sinónimos
• Sustantivos fuera del alcance del sistema
• Sustantivos que son roles que no tienen un
comportamiento único o que son externos
• Sustantivos confusos que necesitan ser
reenfocados
• Sustantivos que son en realidad acciones o
cualidades
Caso de uso con Sustantivos Subrayados
Caso de uso con Sustantivos Subrayados
Objetos Potenciales
 Extraídos desde
el caso de uso

 Análisis de
Objetos Potenciales
POTENTIAL OBJECT LIST
Accounts Receivable Department
Amount Due
Club Member
Credit Card Information
Credit Problem Notice
Credit Status
File
Marketing Department
Member Address
Member Order
Member Phone Number
Member Services Department
Member Services System
Order
Order Confirmation Notice
Order Sales Tax
Order Status
Order Subtotal
Ordered Product
Ordered Product Information
Ordered Product Quantity
Past Member
Payments
Potential Member
Product
Product Inventory
Product Number
Street Address
Transaction
Warehouse
Warehouse Packing Order
POTENTIAL OBJECT LIST
Accounts Receivable Department
Amount Due
Club Member
Credit Card Information
Credit Problem Notice
Credit Status
File
Marketing Department
Member Address
Member Order
Member Phone Number
Member Services Department
Member Services System
Order
Order Confirmation Notice
Order Sales Tax
Order Status
Order Subtotal
Ordered Product
Ordered Product Information
Ordered Product Quantity
Past Member
Payments
Potential Member
Product
Product Inventory
Product Number
Street Address
Transaction
Warehouse
Warehouse Packing Order
Not relevant for current project
Attribute of “MEMBER ORDER”

Type of “MEMBER”

Attribute of “MEMBER”

Potential Interface item to be addressed in object-oriented design
Attribute of “MEMBER”

Not relevant for current project

Not relevant for current project
Attribute of “MEMBER”

“MEMBER ORDER”

Attribute of “MEMBER”

Not relevant for current project

Not relevant for current project

Another name for “MEMBER ORDER”

Potential Interface item to be addressed in object-oriented design
Attribute of “MEMBER ORDER”

Attribute of “MEMBER ORDER”

Attribute of “MEMBER ORDER”

“MEMBER ORDERED PRODUCT”

Unclear noun

Attribute of “MEMBER ORDERED PRODUCT”
Type of “MEMBER”

Type of “TRANSACTION”

Type of “MEMBER”

“PRODUCT”

Attribute of “PRODUCT”

Attribute of “PRODUCT”

Attribute of “MEMBER”

“TRANSACTION”

Not relevant for current project

Potential Interface item to be addressed in object-oriented design
REASON
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
Resultados
del Análisis
PROPOSED OBJECT LIST
CLUB MEMBER

MEMBER ORDER
MEMBER ORDERED PRODUCT
PAST MEMBER
PAYMENT
POTENTIAL MEMBER
PRODUCT
TRANSACTION
AGREEMENT
AUDIO TITLE
MERCHANDISE
GAME TITLE
PROMOTION
RETURN
TITLE
VIDEO TITLE
-- PLUS --
Actividades Generales delAnálisis Orientado
Objeto
1. Modelar las funciones del sistema.
2. Encontrar e identificar los objetos del negocio.
3. Organizar los objetos e identificar sus relaciones.
4. Modelar el comportamiento de los objetos.
Diagramas que muestran la estructura del
sistema
 Diagrama de clases
– Muestra las clases de objetos de las que está
compuesto el sistema, así como las relaciones
que existen entre ellos.

 Diagrama de objetos
– Similar al anterior, pero muestra instancias
individuales de cada clases.
Objetos, Atributos, e Instancias
 Objeto
– Es algo (persona, lugar, cosa, o evento) que es
visto, tocado, o percibido de alguna manera, y
sobre el cual los usuarios almacenan datos y le
asocian un cierto comportamiento.
 Atributos
– Datos que representan características de interés
de un objeto.
 Instancia
– Una instancia (o instancia de un objeto) está
formada por los valores para cada uno de los
atributos que describen un objeto específico.
Objetos, Atributos, e Instancias
412209: Customer
customer number = 412209
last name = Bentley
first name = Lonnie
home phone = 317-463-9593
street = 2625 Darwin Dr.
city = West Lafayette
state = Indiana
zip code = 47906
etc.
0256101329: Book
ISBN = 0256101329
type = textbook
title = Systems Analysis & Design Methods
copyright = 1996
0256102219: Book
ISBN = 0256102219
type = workbook
title = Projects and Cases to Accompany SADM
copyright = 1996
(a)
(b)
Método
 Se entiende por comportamiento a todo aquello que
el objeto pueda hacer y que corresponde a funciones
que actúan sobre los datos (atributos) del objeto.

 En el contexto de orientación a objetos, se utiliza el
concepto de método (o servicio) para referirse al
comportamiento de un objeto.
Encapsulación
 Es la agrupación de varios elementos en una unidad.

 Los atributos y métodos se encapsulan en el objeto.
La única forma de acceder a los atributos de un
objeto es a través de sus métodos.
Clases de Objetos
 Es un conjunto de
objetos que tienen en
común los mismos
atributos y el mismo
comportamiento.

 Las clases también se
denominan clases de
objetos.
Open()
Close()
ISBN
type
title
copyright
Book
Customer
customer number
last name
first name
home phone
street
city
state
zip code
etc.
changeAddress()
Herencia
 Describe el mecanismo mediante el cual los atributos
y/o métodos definidos para una clase de objetos
puede ser heredado o reutilizado por otra clase de
objetos.

 Generalización/Especialización
– Es una técnica donde los atributos y métodos que
son comunes a varios tipos de clases de objetos
se agrupan en su propia clase, llamada supertipo.
Los atributos y métodos de la clase de objetos
supertipo son heredados a las clases de objetos
originales.
Supertipos y Subtipos
 Clase Supertipo
– Es una clase de objetos cuyas instancias
almacenan atributos que son comunes a una o
más clases subtipos.

 Clase Subtipo
– Es una clase de objetos cuyas instancias heredan
algunos atributos comunes de una clase
supertipo, y luego agregan otros atributos que son
únicos para las instancias del subtipo.
Supertipos y Subtipos
Clase Persona
(supertipo)
Clase Alumno
(subtipo)
Clase Profesor
(subtipo)
Alumno A Alumno B Alumno C Profesor A Profesor B
Generalización/Especialización en UML
walk()
jump()
talk()
sleep()
eat()
etc.()
last name
first name
birth date
gender
Person
enroll()
displayGPA()
GPA
classification
Student
lecture()
rank
Teacher
Puntas de flechas
indican relación de
generalización/especialización
Relaciones entre clases de objetos
 Es una asociación natural de negocios que existe
entre una o más clases de objetos.
0..*
Customer Order
Places
Multiplicidad
 Define como varias instancias de una clase de
objetos puede ser asociada con una sola instancia
de otra clase de objetos.
Multiplicity Multiplicity
Works for
0..1 Has
0..*
Makes
UML
Notation
Association with Multiplicity
Association
Meaning
Exactly 1
1

or

leave blank
Department Employee
1
Works for
Department Employee
An employee
works for one
and only one
department.
Zero or one 0..1
Spouse Employee
An employee has
either one or no
spouse.
Zero or
more
0..*

or

*

Payment Customer
Payment Customer
Makes *
A customer can
make no payment
up to many
payments.
One or more 1..*
Course University
Offers
1..*
A u niversity
offers at least 1
course up to
many courses.
Specific
range
7..9 Game Team
7..9
Has
scheduled A team has either
7, 8, or 9 games
scheduled
Notación de Multiplicidad en UML
Book
Cover
Table of
Contents
Chapter Index
Page
Paragraph
Word
1 1..* 0..1 0..1
1..*
0..*
1..*
Diamante sólido indica
relación de agregación
compuesta
Ejemplo en UML de una relación de agregación
compuesta
Team
Player
0..*
0..*
Diamante hueco indica
una relación de
agregación compartida
Ejemplo en UML de una relación de agregación
compartida
Mensaje
Customer
add order
modify order
delete order
display status
etc.
order number
order date
order status
etc.
Order
display order status
of order 23161
MENSAJE
SOLICITADO
(contiene nombre del método solicitado y
los atributos requeridos por la clase ORDER)
 Se pasa un mensaje cuando un objeto invoca uno o
más métodos de otro objeto para requerir
información o producir una acción.
Construcción de un Diagrama de Clases
 Paso 1: Identificar Asociaciones y Multiplicidad
– Subrayar (o destacar) los sustantivos del caso de
uso
 Paso 2: Identificar relaciones de Generalización
/Especialización
 Paso 3: Identificar relaciones de Agregación
 Paso 4: Preparar el diagrama de Clases
<<actor>>
Club Member
Member-Date-Of-Last-Order
Member-Daytime-Phone-Number
Member-Credit-Card-Expire-Date
Member-Credit-Card-Number
Member-Credit-Card-Type
Member-Balance-Due
Member-Bonus-Balance-Available
Audio-Category-Preference
Audio-Media-Preference
Date-Enrolled
Email-Address
Game-Category-Preference
Game-Media-Preference
Number-Of-Credits-Earned
Privacy-Code
Video-Category-Preference
Video-Media-Preference
persistent
Member Order
Order-Number
Order-Creation-Date
Order-Fill-Date
Shipping-Address-Name
Shipping-Street-Address
Shipping-City
Shipping-State
Shipping-Zip-Code
Shipping-Instructions
Order-Sub-Total
Order-Sales-Tax
Order-Shipping-Method
Order-Shipping-&-Handling-Cost
Order-Status
Order-Prepaid-Amount
Order-Prepayment-Method
persistent
Product
Product-Number
UPC-
Quantity-In-Stock
Product-Type
Suggested-Retail-Price
Default-Unit-Price
Current-Special-Unit-Price
Current-Month-Units-Sold
Current-Year-Units-Sold
Total-Lifetime-Units-Sold
persistent
Video Title
Producer
Director
Video-Category
Video-Sub-Category
Closed-Captioned
Language
Running-Time
Video-Media-Type
Video-Encoding
Screen-Aspect
MPA-Rating-Code
persistent
Audio Tilte
Artist
Audio-Category
Audio-Sub-Category
Number-Of-Units-In-Package
Audio-Media-Code
Content-Advisory-Code
persistent
Transaction
Transaction-Reference-Number
Transaction-Date
Transaction-Type
Transaction-Description
Transation-Amount
persistent
Member
Member-Number
Member-Name
Member-Status
Member-Street-Address
Member-PO-Box
Member-City
Member-State
Member-Zip-Code
persistent
Agreement
Agreement-Number
Agreement-Expire-Date
Agreement-Active-Date
Fulfillment-Period
Required-Number-Of-Credits
persistent
Game Title
Manufacturer
Game-Category
Game-Sub-Category
Game-Platform
Game-Media-Type
Number-Of-Players
Parent-Advisory-Code
persistent
Title
Title-Of-Work
Title-Cover
Catalog-Description
Copyright-Date
Entertainment-Company
Credit-Value
persistent
Member Ordered Product
Quantity-Ordered
Quantity-
Shipped
Quantity-Backordered
Purchase-Unit-Price
Credits-Earned
persistent
Merchandise
Merchandise-Name
Merchandise-Description
Merchandise-Type
Unit-of-Measure
persistent
Promotion
Promotion-Number
Promotion-Release-Date
Promotion-Status
Promotion-Type
persistent
<<actor>>
Potential Member
persistent
<<actor>>
Past Member
Expiration-Date
persistent
Return
persistent
1..*
1
binds
1
0..*
Conduct
s
1
0..*
Has
purchased
0..1
0..*
Generate
s
0..*
1..*
Feature
s
1
0..*
Sold as
0..*
1
Places
1
1..*
Sells
Diagrama de Clases del Sistema de
Servicio a Clientes
Actividades Generales del Análisis
Orientado Objeto
1. Modelar las funciones del sistema.
2. Encontrar e identificar los objetos del negocio.
3. Organizar los objetos e identificar sus relaciones.
4. Modelar el comportamiento de los objetos.
Diagramas que describen el estado de los
objetos
 Diagramas de Estados
– Los diagramas de estados se utilizan para
modelar el comportamiento dinámico de un objeto
particular.
– Ilustran el ciclo de vida de un objeto – los varios
estados que un objeto puede asumir y los eventos
que causan la transición del objeto de un estado a
otro.


estado
"PRE-LANZAMIENTO"
estado
“VUELO"
“Despegue"
Ejemplo de Estados de un Objeto
 Posibles “estados” del Trasbordador Espacial
Diagrama de estados
 Modela el ciclo de vida de un solo objeto.
 Representa los diversos estados que un objeto
puede tener, los eventos que hacen que el objeto
cambie de estado en el tiempo, y las reglas que
gobiernan la transición del objeto entre los estados.
 Especifica de qué estado de un objeto es posible la
transición a otro estado.
 Los diagramas de estados no son requeridos para
todos los objetos. Típicamente, un diagrama de
estados se construye solamente para aquellos
objetos que tienen estados claramente identificables
y un comportamiento complejo.
Diagrama de estados – teléfono
Ocioso
Activo
descolgar auricular
colgar auricular
Estado
Estado inicial
Transición
Evento
Diagrama de estados – casos de uso
 Una aplicación útil de este tipo de diagramas
consiste en describir la secuencia permitida de
eventos externos que reconoce y maneja un sistema
dentro del contexto de un caso de uso.

 Es útil para describir el orden legal de los eventos
externos.
Diagrama de estados – casos de uso
 Ejemplos:
– En el caso Comprar Productos de la aplicación del
punto de venta, no está permitido efectuar la
operación efectuarPagoConTarjeta mientras no
haya ocurrido el evento terminarVenta.

– En el caso Procesar Documento en un procesador
de texto, no está permitido efectuar la operación
Guardar en Archivo mientras no haya ocurrido el
evento Crear Archivo Nuevo o Abrir Archivo.
Diagrama de estados – comprar
productos
EnEsperadelaVenta
EnEsperadelPago
efectuarPago
Evento del sistema
( externo)
IntroduciendoProductos
introducirProducto
terminarVenta
introducirProducto
Order Shipped
Order Released Order Filled
Order Invoiced
Pending In Process
Order Backordered
Order Closed
Member Order final
state
Member Order final
state
Member Order
initial state
Order pending awaiting payment or additional member information
Order rejected based on Member's past history
Member order archived after 90 days
Invoice sent to member for payment
Response received from member
Order released
to the warehouse
Order shipped to club member
Order filled by the warehouse
Not all product
available
Final payment received
Order submitted
Product received

Diagrama de estados
del Sistema de Servicio a Clientes
Diagramas que describen el estado de los
objetos
 Diagramas de Actividades
– Los diagramas de actividades se utilizan para
representar gráficamente el flujo secuencial de
actividades de un proceso de negocios o un caso
de uso.
– También pueden ser utilizados para modelar las
acciones que serán realizadas cuando una
operación se está ejecutando así como los
resultados de dichas acciones.
Input Request
Route to
Manager
Evaluate
Need
Check
Budget
[need]
[budget]
[no need] [no budget
Disapprove
Request
Approve
Request
Route to
Purchasing Agent
Diagrama de Actividades
Diagramas que describen el
comportamiento de los objetos
 Diagramas de Secuencia
– Los diagramas de secuencia representan
gráficamente cómo los objetos interactúan entre sí
vía mensajes en la ejecución un caso de uso.

– Ilustran cómo se envían y reciben los mensajes
entre los objetos y en qué secuencia.

Eventos y operaciones del sistema
 Evento del sistema
– Es un hecho externo que un actor realiza y
produce una entrada al sistema.

 Operación del sistema
– Es una acción que el sistema ejecuta en
respuesta a una evento del sistema.

 Los eventos de un sistema (y sus operaciones
asociadas) deben expresarse en el nivel de propósito
y no en el nivel del medio físico de entrada o de
elementos de la interfaz.
Eventos y operaciones del sistema (2)
 Ejemplo:
– Cuando un cajero genera un evento
introducirProducto, causa la ejecución de la
operación introducirProducto.

 El nombre del evento y de la operación son
idénticos; la distinción reside en que el
evento es el estímulo y la operación es la
repuesta (lo mismo sucede con los mensajes
y los métodos).
Registro de las operaciones de un
sistema
 Para determinar el conjunto de operaciones
requeridas del sistema se identifican sus eventos.

 Cuando se utilizan parámetros, las operaciones son
las siguientes:
– IntroducirProducto(CUP, Cantidad)
– TerminarVenta()
– EfectuarPago(monto)
Diagrama de Secuencia – Comprar
Productos
 Identificar eventos del sistema:
– Primero debemos determinar los actores que
interactúan directamente con el sistema de
software.
– El cliente interactúa con el cajero, pero no
directamente con el sistema TPDV; esto sólo lo
hace el cajero.
– Por tanto, el cliente no es un generador de
eventos del sistema, sólo el cajero lo es.
Diagrama de Secuencia – Comprar Productos
 Curso normal de los eventos en el caso Comprar
Productos
: Cajero
:Sistema
1: introducir Producto(CUP, cantidad)
2: terminarVenta()
3: efectuarPago(monto)
Sistema como
caja negra
Evento del sistema
Inicia una operación de
sistema
Actor
Diagrama de Secuencia
 También mejora la claridad si el nombre de un
evento del sistema comienza con un verbo (agregar,
introducir, terminar, efectuar), ya que recalca que los
eventos están orientados a comandos.

– Así, terminarVenta es preferible a OprimaTeclaEnter porque
capta mejor el propósito de la operación: mantiene un
carácter abstracto y no se pronuncia respecto a las
decisiones de diseño sobre cuál interfaz sirve para capturar
el evento del sistema.
Diagrama de Secuencia
 En cuanto a expresar las operaciones en el nivel de
propósito, se debe tratar de alcanzar el nivel más alto
o la meta final para asignar nombre a la operación.
Por ejemplo, respecto a la operación que captura el
pago:
– IntroducirImporteOfrecido(monto) – deficiente
– IntroducirPago(monto) – mejor
– EfectuarPago –mejor aún
a Product
a Member
Order
a Member
Ordered Product
an Order
Processor
a Club
Member
display member information
validate item
create item
enter item (product number)
select new order
update address
(address)
verify member
(member number)
Diagrama de Secuencia
Diagrama de Secuencia
 Los diagramas de secuencia se utilizan para modelar
la lógica de los escenarios de uso.
– Un escenario de uso es la descripción de una
manera potencial en que se utilizará el sistema.

 Los diagramas de secuencia modelan de una
manera visual el flujo de la lógica dentro de un
sistema, permitiendo tanto documentar como validar
la lógica subyacente.

 Se utilizan tanto para el análisis como para el diseño.
Diagrama de Secuencia
 La lógica de un escenario de uso puede describir:

– Un caso de uso; la lógica descrita por el curso
normal de los eventos o una porción de éste, más
unos o más escenarios alternativos.

– Parte de un caso de uso, quizás un curso
alternativo.

– Un conjunto de paso con la lógica contenida en
varios casos de uso.
• Por ejemplo, un alumno se inscribe en la universidad y
además se inscribe inmediatamente en tres cursos.
Diagrama de Secuencia
Elementos de un Diagrama de Secuencia
 Los rectángulos en la parte superior del diagrama representan
objetos, clases, actores, o casos de uso.

 Objetos y Clases
– Dado que es posible enviar mensajes tanto a objetos como
a clases, tiene sentido incluir tanto a objetos como a clases
en los diagramas de secuencia.
• Los objetos responden a los mensajes a través de la
llamada a una operación.
• Las clases lo hacen a través de la llamada a una
operación estática.

 Actores
– Los actores inician y tienen una participación activa en los
escenarios de uso.
Elementos de un Diagrama de Secuencia
 Para los objetos, clases y actores se utilizan
etiquetas estándar en el formato UML:

 Objetos: “nombre:NombreDeLaClase”
– Donde “nombre” es opcional (los objetos a los que
no se les da un nombre en el diagrama se llaman
objetos anónimos).

 Clases: “NombreDeLaClase”

 Actores: “NombreActor”
Elementos de un Diagrama de Secuencia
 Ejemplo:
Cliente
Elementos de un Diagrama de Secuencia
 Las líneas discontinuas que cuelgan de los
rectángulos se llaman líneas de vida del objeto, y
representan la vida del objeto durante el escenario
que está siendo modelado.

 Los rectángulos largos y finos en las líneas de vida
son rectángulos de invocación a métodos, e indican
que operación se debe ejecutar en el objeto/clase
que está recibiendo el mensaje.
Elementos de un Diagrama de Secuencia
 La "X" en la parte inferior de un rectángulo de
invocación es una convención de UML para indicar
que un objeto ha sido eliminado de la memoria,
típicamente como resultado de recibir un mensaje
con el estereotipo <<destroy>>.

 Los mensajes se indican como flechas etiquetadas
– Cuando el emisor y el receptor de un mensaje es un objeto
o una clase, la etiqueta corresponde al método que se
invocará como respuesta al mensaje.
– Si el emisor o el receptor es un actor humano entonces el
mensaje se etiqueta con un texto breve que describe la
información que está siendo comunicada.
Diagramas que describen el
comportamiento de los objetos
 Diagramas de Colaboración
– Los diagramas de colaboración son similares a los
diagramas de secuencia, pero no se centran en la
sincronización o "secuencia" de mensajes, si no
que presentan la interacción (o colaboración)
entre los objetos en un formato de red.
Diagrama de Colaboración
 El diseño orientado a objetos tiene por objetivo
definir las especificaciones lógicas del software que
cumplan con los requisitos funcionales.

 Un paso esencial en esta fase es la asignación de
responsabilidades entre los objetos y mostrar como
interactúan a través de mensajes.

 El diagrama de colaboración presenta el flujo de
mensajes entre las instancias y la invocación de
métodos.

Diagrama de Colaboración – juego de
dados
 La figura muestra gráficamente los elementos
esenciales del juego, enviando mensajes a las
instancias de las clases Jugador y Dado.

:Jugador d1:Dado
jugar()
1:r1:= lanzar()
d2:Dado
2:r2:= lanzar()
Diagramas de Colaboración y de
Secuencia
 Los diagramas de colaboración describen las
interacciones entre los objetos en un formato de
grafo o red:



 Los diagramas de secuencia describen las
interacciones en una especie de formato de cerca o
muro:

Instancia1 : ClaseA Instancia2 : ClaseB
1: mensaje2() 2: mensaje3() mensaje1()
Instancia1 :
ClaseA
Instancia2 :
ClaseB
mensaje2()
mensaje3()
mensaje1()
Diagramas que describen la
implementación de los objetos
 Diagramas de Componentes
– Los diagramas componentes se utilizan para
representar gráficamente la arquitectura física del
sistema. Pueden ser utilizados para demostrar
cómo el código de programación se divide en
módulos (o componentes).

Client Source Code
Comment
(client.exe)
Drawing Library
Comment
(drawing.dll)
dependency
Diagrama de Componentes
Diagramas que describen la
implementación de los objetos
 Diagramas de Despliegue
– Los diagramas del despliegue describen la
arquitectura física del hardware y software en el
sistema. Representan las componentes de
software, los procesadores, y los dispositivos que
forman la arquitectura del sistema.
Application Server -
Compaq PIII 500
Client Workstation
HP Kayak XU-400
Database Server -
Compaq PIII 500
SAP R/3
Comment
Client Source Code
Comment
(client.exe)
Oracle 8
Comment
TCP/IP
TCP/IP
Diagrama de Despliegue