Transcript Diagramas de Estados

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
Secuencia
Diagramas de
Colaboración
Diagramas de
Casos de Uso
Diagramas
de Clases
Diagramas
de Objetos
Modelo del
Sistema
Diagramas de
Estados
Diagramas de
Componentes
Diagramas de
Actividades
Diagramas de
Despliegue
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.
2.
3.
4.
Modelar las funciones del sistema.
Encontrar e identificar los objetos del negocio.
Organizar los objetos e identificar sus relaciones.
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
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.
4. Al terminar de introducir los productos, el
Cajero indica al TPDV que se concluyó la
captura de productos.
6. El Cajero indica el total al Cliente.
Respuesta del sistema
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.
5. Calcula y presenta el total de la venta.
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.
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.
12. El Cliente se marcha con los artículos
comprados.
9. Muestra al cliente la diferencia. Genera un
recibo.
11. Registra la venta concluida.
Cursos alternativos
· Línea 2: introducción del identificador inválido.
·
Línea 7: el cliente no tenía suficiente dinero.
Indicar error.
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
Diagrama de Contexto – Sistema de Servicio
al Cliente
Accounts
Receivable
Promotion
Club
Member
Member Order
Member
Credit
Status
Warehouse
Potential
Member
various Inquiry Reponses
New Subscription
Member
Services
Subscription Offer
System
Subscription Renewal
Revised Packing Order
New Promotion
Subscription Program
various Sales Reports
various
Promotion Reports
various Subscription Reports
Past
Member
Resubscription Offer
various Member
Reports
Member
Services
Marketing
Department
Paso 1:
Identificar Actores y Casos de Usos
Actor
Potential
Member
Club
Member
Club
Member
Club
Member
Club
Member
Club
Member
Past
Member
Marketing
Use Case Name
SUBMIT NEW
SUBSCRIPTION
PLACE NEW MEMBER
ORDER
MAKE ACCOUNT INQUIRY
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.
MAKE PURCHASE INQUIRY (90-day time limit)
Club member inquires about his/her purchase history.
MAINTAIN MEMBER ORDER(three-year time limit)
Club member wants to revise an order or cancel an order.
SUBMIT CHANGE OF
Club member changes address.
ADDRESS
(including e-mail and privacy code)
SUBMIT
Past member rejoins the club by resubscribing.
RESUBSCRIPTION
SUBMIT NEW MEMBER
SUBSCRIPTION PROGRAM Marketing establishes a new membership resubscription plan to entice
new members.
Marketing SUBMIT PAST MEMBER
Marketing establishes a new membership resubscription plan to lure
RESUBSCRIPTION
back former members.
PROGRAM
Marketing SUBMIT NEW PROMOTION
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.)
Time
GENERATE QUARTERLY
Print quarterly promotion analysis report.
PROMOTION ANALYSIS
Time
GENERATE QUARTERLY
Print annual sales analysis report.
SALES ANALYSIS
Time
GENERATE QUARTERLY
Print annual membership analysis report.
MEMBERSHIP ANALYSIS
Time
GENERATE ANNUAL SALES
Print annual sales analysis report.
ANALYSIS
Time
GENERATE ANNUAL
Print annual membership analysis report.
MEMBERSHIP ANALYSIS
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
1
Referencia a los requerimientos con los cuales está relacionado.
2
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.
3
Cursos alternativos que describen excepciones al curso común del evento.
4
Precondición que describe el estado en que debe estar el sistema para que se
ejecute el caso del uso.
5
Poscondición que describe el estado en que queda el sistema después de que
se ejecuta el caso del uso.
6
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.
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
Calcular Subtotal e
Impuestos Pedido
Generar Orden de
Despacho
«extends»
«extends»
Completar Pedido
Cliente Nuevo
«uses»
Revisar Dirección
«uses»
Solicitar Cambio
de Dirección
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>>
<<include>>
Caso de Uso Origen
Caso de Uso Destino
Casos de Uso – Relaciones
 Extensión
– El Caso de Uso origen extiende el
comportamiento del Caso de Uso destino
<<extend>>
Caso de Uso Origen
Caso de Uso Destino
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.
2.
3.
4.
Modelar las funciones del sistema.
Encontrar e identificar los objetos del negocio.
Organizar los objetos e identificar sus relaciones.
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
REASON
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
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
x
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
Resultados
del Análisis
PROPOSED OBJECT LIST
CLUB MEMBER
MEMBER ORDER
MEMBER ORDERED PRODUCT
PAST MEMBER
PAYMENT
POTENTIAL MEMBER
PRODUCT
TRANSACTION
-- PLUS -AGREEMENT
AUDIO TITLE
GAME TITLE
PROMOTION
MERCHANDISE
RETURN
TITLE
VIDEO TITLE
Actividades Generales delAnálisis Orientado
Objeto
1.
2.
3.
4.
Modelar las funciones del sistema.
Encontrar e identificar los objetos del negocio.
Organizar los objetos e identificar sus relaciones.
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
(a)
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
(b)
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
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.
Book
ISBN
type
title
copyright
Open()
Close()
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)
Alumno A
Alumno B
Clase Profesor
(subtipo)
Alumno C
Profesor A
Profesor B
Generalización/Especialización en UML
Person
last name
first name
birth date
gender
walk()
jump()
talk()
sleep()
eat()
etc.()
Puntas de flechas
indican relación de
generalización/especialización
Student
Teacher
GPA
classification
rank
enroll()
displayGPA()
lecture()
Relaciones entre clases de objetos
 Es una asociación natural de negocios que existe
entre una o más clases de objetos.
Places
Customer
0..*
Order
Multiplicidad
 Define como varias instancias de una clase de
objetos puede ser asociada con una sola instancia
de otra clase de objetos.
Notación de Multiplicidad en UML
UML
Multiplicity Multiplicity
Notation
Exactly 1
Zero or one
Zero or
more
One or more
Specific
range
Association with Multiplicity
1
Employee
or
leave blank
Employee
0..1
Employee
0..*
Customer
Works for
1
Works for
Department
Department
Has
0..1
Makes
0..*
Spouse
Payment
or
*
Customer
1..*
University
7..9
Team
Makes
*
Offers
1..*
Has
scheduled 7..9
Payment
Association
Meaning
An employee
works for one
and only one
department.
An employee has
either one or no
spouse.
A customer can
make no payment
up to many
payments.
Course
A university
offers at least 1
course up to
many courses.
Game
A team has either
7, 8, or 9 games
scheduled
Ejemplo en UML de una relación de agregación
compuesta
Book
1
Cover
0..1
Table of
Contents
1..*
Chapter
0..1
Index
1..*
Page
0..*
Paragraph
1..*
Word
Diamante sólido indica
relación de agregación
compuesta
Ejemplo en UML de una relación de agregación
compartida
Team
0..*
0..*
Player
Diamante hueco indica
una relación de
agregación compartida
Mensaje
 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.
MENSAJE
SOLICITADO
(contiene nombre del método solicitado y
los atributos requeridos por la clase ORDER)
Customer
display order status
of order 23161
Order
order number
order date
order status
etc.
add order
modify order
delete order
display status
etc.
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
Diagrama de Clases del Sistema de
Servicio a Clientes
Member
Member-Number
Member-Name
Member-Status
Member-Street-Address
Member-PO-Box
Member-City
Member-State
Member-Zip-Code
persistent
<<actor>>
Potential Member
persistent
Product
Product-Number
UPCQuantity-In-Stock
Product-Type
1
Suggested-Retail-Price
Default-Unit-Price
Current-Special-Unit-Price
Current-Month-Units-Sold
Current-Year-Units-Sold
Total-Lifetime-Units-Sold
Sold as
0..*
Has
purchased
0..*
Member Ordered Product
Quantity-Ordered
QuantityQuantity-Backordered
Shipped
Purchase-Unit-Price
Credits-Earned
1
<<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 1..*
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
1
persistent
persistent
0..*
Promotion
Promotion-Number
Promotion-Release-Date
0..1
Promotion-Status
Promotion-Type
1
Generate
s
0..*
0..*
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
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
persistent
Transaction
Transaction-Reference-Number
Transaction-Date
Transaction-Type
Transaction-Description
Transation-Amount
Places
persistent
persistent
Audio Tilte
Artist
Audio-Category
Audio-Sub-Category
Number-Of-Units-In-Package
Audio-Media-Code
Content-Advisory-Code
Conduct
s
1
persistent
1..*
Title
Title-Of-Work
Title-Cover
1..*
Catalog-Description
Copyright-Date
Feature
Entertainment-Company
s
Credit-Value
binds
1
Sells
Merchandise
Merchandise-Name
Merchandise-Description
Merchandise-Type
Unit-of-Measure
Agreement
Agreement-Number
Agreement-Expire-Date
Agreement-Active-Date
Fulfillment-Period
Required-Number-Of-Credits
persistent
0..*
persistent
persistent
<<actor>>
Past Member
Expiration-Date
Game Title
Manufacturer
Game-Category
Game-Sub-Category
Game-Platform
Game-Media-Type
Number-Of-Players
Parent-Advisory-Code
persistent
Return
persistent
Actividades Generales del Análisis
Orientado Objeto
1.
2.
3.
4.
Modelar las funciones del sistema.
Encontrar e identificar los objetos del negocio.
Organizar los objetos e identificar sus relaciones.
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.
Ejemplo de Estados de un Objeto
 Posibles “estados” del Trasbordador Espacial
“Despegue"
estado
"PRE-LANZAMIENTO"
estado
“VUELO"
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
Estado inicial
descolgar auricular
Estado
Ocioso
Transición
Activo
colgar auricular
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
introducirProducto
EnEsperadelaVenta
introducirProducto
Evento del sistema
(externo)
IntroduciendoProductos
terminarVenta
EnEsperadelPago
efectuarPago
Diagrama de estados
del Sistema de Servicio a Clientes
Order Backordered
Not all product
available
Member Order
initial state
Order submitted
Product received
In Process
Order pending awaiting payment or additional member information
Pending
Response received from member
Order released
to the warehouse
Order ReleasedOrder filled by the warehouse Order Filled
Order shipped to club member
Order rejected based on Member's past history
Order Shipped
Order Invoiced Invoice sent to member for payment
Final payment received
Order Closed
Member Order final
state
Member order archived after 90 days
Member Order final
state
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.
Diagrama de Actividades
Route to
Manager
Input Request
Evaluate
Need
Check
Budget
[budget]
[need]
[no need]
[no budget
Disapprove
Request
Approve
Request
Route to
Purchasing Agent
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
Sistema como
caja negra
Actor
:Sistema
: Cajero
1: introducir Producto(CUP, cantidad)
2: terminarVenta()
3: efectuarPago(monto)
Evento del sistema
Inicia una operación de
sistema
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
Diagrama de Secuencia
an Order
Processor
a Club
Member
a Member
Order
a Member
Ordered Product
verify member
(member number)
display member information
update address
(address)
select new order
enter item (product number)
create item
validate item
a Product
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.
jugar()
:Jugador
1:r1:= lanzar()
2:r2:= lanzar()
d1:Dado
d2:Dado
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:
mensaje1()
1: mensaje2()
2: mensaje3()
Instancia1 : ClaseA
Instancia2 : ClaseB
 Los diagramas de secuencia describen las
interacciones en una especie de formato de cerca o
muro:
Instancia1 :
ClaseA
mensaje1()
Instancia2 :
ClaseB
mensaje2()
mensaje3()
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).
Diagrama de Componentes
Drawing Library
Client Source Code
Comment
Comment
(drawing.dll)
dependency
(client.exe)
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.
Diagrama de Despliegue
Client Workstation
HP Kayak XU-400
Application Server Compaq PIII 500
TCP/IP
SAP R/3
Comment
Client Source Code
Comment
(client.exe)
TCP/IP
Database Server Compaq PIII 500
Oracle 8
Comment