Paradigma OO

UML Diagramas

1
 CLAVES EN DESARROLLO DE SI

Notación

Herramientas Proceso

UNPSJB - 2005 Ingeniería de Software - Clase 6 2

ABSTRACCIÓN - MODELADO VISUAL (MV)

“El modelado captura las

partes esenciales del sistema”

Orden

Item

envío

Proceso de Negocios

Sistema Computacional
3
 REFLEXIONES RESPECTO DE SITUACIÓN ACTUAL
DE DESARROLLO DE SI

Análisis Diseño Implementación

DFDs DEs
Enfoque Entornos de
Estructurado E-R Programación
Modelo Visual
Diagramas de Casos de Uso Relacional
Diagramas de Actividad
Diagramas de Secuencia
Diagramas de Colaboración d Modelo
Relacional !! Bases de Datos
(Objeto-)
Enfoque OO Diagrama de Clases
Relacionales
Diagrama de Estados
Diagramas de Actividad

UNPSJB - 2005 Ingeniería de Software - Clase 6 4

 ... DIAGRAMAS DE UMLwww.dsic.upv.es/~uml

Los diagramas expresan gráficamente partes de un modelo

State
State
Use Case Diagramas de
Diagrams
Use Case Diagrams State
Use Case Diagramas de
Diagrams Clases State
Use Case Diagrams Diagramas de
Diagrams
Diagramas de
Diagrams Casos de Uso Diagrams
Diagrams Objetos
Secuencia

Scenario State
Scenario State
Diagramas de
Diagrams Diagramas de
Diagrams
Diagrams Diagrams
Colaboración Modelo Componentes

Scenario Component
Scenario Component
Diagramas
Diagrams de
Diagramas de
Diagrams Diagrams
Diagrams Distribución
Estados Diagramas de
Actividad
UNPSJB - 2005 Ingeniería de Software - Clase 6 5
 ... ORGANIZACIÓN DE MODELOS
www.dsic.upv.es/~uml

Propuesta de Rational Unified Process (RUP)

 M. de Casos de Uso del Negocio (Business Use-Case Model)
 M. de Objetos del Negocio (Business Object Model)
 M. de Casos de Uso (Use-Case Model)
 M. de Análisis (Analysis Model)
 M. de Diseño (Design Model)
 M. de Despliegue (Deployment Model)
 M. de Datos (Data Model)
 M. de Implementación (Implementation Model)
 M. de Pruebas (Test Model)

UNPSJB - 2005 Ingeniería de Software - Clase 6 6

 DIAGRAMAS DE CASOS
DE USO

UNPSJB - 2005 Ingeniería de Software - Clase 6 7

 DIAGRAMA DE CASOS DE USO

 Casos de Uso es una

técnica para capturar
información de cómo un
sistema o negocio Verificar Situación del Cliente
trabaja, o de cómo se Supervisor

desea que trabaje

 No pertenece
estrictamente al enfoque
orientado a objeto, es Administrativo
Preparar Catálogo
Sistema
una técnica para captura Inventario

de requisitos
Tipos de Venta

8
 … CASOS DE USO www.dsic.upv.es/~uml

 Los Casos de Uso cubren la

carencia existente en
métodos previos (OMT,
Booch) en cuanto a la
determinación de requisitos
 Los Casos de Uso particionan Caso de Uso A
el conjunto de necesidades Actor A

atendiendo a la categoría de
usuarios que participan en el
mismo
 Están basado en el lenguaje Caso de Uso B
Actor B
natural, es decir, es
accesible por los usuarios

UNPSJB - 2005 Ingeniería de Software - Clase 6 9

 … CASOS DE USO

 Actores:
 Principales: personas que usan el sistema
 Secundarios: personas que mantienen o administran el sistema
 Material externo: dispositivos materiales imprescindibles que
forman parte del ámbito de la aplicación y deben ser util izados
 Otros sistemas: sistemas con los que el sistema interactúa
 La misma persona física puede interpretar varios papeles
como actores distintos
 El nombre del actor describe el papel desempeñado

10
 … CASOS DE USO

 Los Casos de Uso se determinan observando y

precisando, actor por actor, las secuencias de
interacción, los escenarios, desde el punto de vista
del usuario
 Un escenario es una instancia de un caso de uso
 Los casos de uso intervienen durante todo el ciclo
de vida. El proceso de desarrollo estará dirigido
por los casos de uso

UNPSJB - 2005 Ingeniería de Software - Clase 6 11

 … EJEMPLOS

<<include>>
Reintegro Cuenta Corriente

Cliente Verificar Operación

<<include>>

Reintegro Cuenta de Crédito

UNPSJB - 2005 Ingeniería de Software - Clase 6 12

 CASOS DE USO: RELACIONES
www.dsic.upv.es/~uml

Generalización entre actores:

Organización de actores mediante descripciones abstractas
compartidas por otras descripciones de actores más específicos
Generalización entre casos de uso:
Casos de uso más específicos heredarían la descripción de
casos de uso más genéricos, añadiendo una descripción
complementaria
Relación de asociación entre actores y casos de uso:
Comunicación existente entre ambos
Relación de extensión: Factoriza un caso de uso en nuevos casos
de uso que extienden o amplían su comportamiento
extend A extiende a B
A B A puede conllevar B

Relación de inclusión: Expresa que un caso de uso incluye

comportamiento de otros casos de uso como parte de su propio
comportamiento
include A usa a B
A B A siempre ejecuta B
13
 CASOS DE USO: RELACIONES
www.dsic.upv.es/~uml

 UML define cuatro  Inclusión : una instancia

del Caso de Uso origen
tipos de relación en incluye también el
los Diagramas de comportamiento
descrito por el Caso de
Casos de Uso: Uso destino
 Comunicación
<<include>>

Caso de Uso Origen Caso de Uso Destino

 <<include>> reemplazó
al denominado
Caso de Uso
Actor <<uses>>

UNPSJB - 2005 Ingeniería de Software - Clase 6 14

 … CASOS DE USO: RELACIONES
www.dsic.upv.es/~uml

 Extensión : el Caso de  Herencia : el Caso de

Uso origen extiende el Uso origen hereda la
comportamiento del especificación del
Caso de Uso destino Caso de Uso destino y
posiblemente la
modifica y/o amplía

<<extend>>

Caso de Uso Origen Caso de Uso Destino

Caso de Uso Hijo Caso de Uso Padre

UNPSJB - 2005 Ingeniería de Software - Clase 6 15

 … CASOS DE USO: RELACIONES
www.dsic.upv.es/~uml

 Ejemplo:

Identificación
<<include>>

Transferencia
Cliente

<<extend>>

Transferencia en Internet

16
 Relación de inclusión
Ejemplo
• Casos de uso que tienen una parte común en sus
funcionalidades.
<<include>>

Pagar un servicio
por Internet
Usuario
<<include>> Verificar
permiso
Chequear pagos
realizados
 Relación de inclusión
Ejemplo
• Se observa una relativa independencia en una parte del
flujo de trabajo que se describe, aún cuando no se
reutilice. De ese subproceso solo interesa el resultado.

<<include>>

Pagar un servicio
por Internet
Usuario
Redefinir deuda
pendiente
 Relación de extensión
Ejemplo
• Comportamiento opcional.
<<extend>>
Enviar e-mail a
superior
<<extend>>
Analizar
Especialista discrepancias
del banco
Resolver
discrepancia
 Relación de extensión
Ejemplo
• Comportamiento que es ejecutado solamente bajo
ciertas condiciones.

<<extend>>

Pagar un servicio
por Internet
Especialista
del banco Buscar cuentas
alternativas
 Relación de extensión
Ejemplo
• Flujos distintos y diferentes que pueden ejecutarse
sobre la base de la selección del actor.

<<extend>>

Chequear pagos
realizados
Usuario
Reportar
discrepancias
 … CASOS DE USO: RELACIONES
www.dsic.upv.es/~uml

 Ejemplo:

22
 CASOS DE USO: CONSTRUCCIÓN
www.dsic.upv.es/~uml

 Un caso de uso debe ser simple, inteligible, claro y conciso

 Generalmente hay pocos actores asociados a cada Caso de
Uso
 Preguntas clave:
 ¿cuáles son las tareas del actor?
 ¿qué información crea, guarda, modifica, destruye o lee el actor?
 ¿debe el actor notificar al sistema los cambios externos?
 ¿debe el sistema informar al actor de los cambios internos?

UNPSJB - 2005 Ingeniería de Software - Clase 6 23

DESCRIPCIÓN TEXTUAL DE LOS CASOS DE
USO

 nombre del caso del uso del negocio

 actores
 propósito
 resumen
 flujo de trabajo
- Básico (normal)
- Curso Alterno
 otras secciones
 Prioridad
 Mejoras
 Cliente Atender pedido
Nombre Atender pedido
Actores CLIENTE
Propósito Analizar viabilidad del Pedido del Cliente y ordenar su producción.
Resumen: El caso de uso se inicia cuando el Cliente envía una orden de pedido de productos. El proceso da curso al pedido,
analizando la posibilidad de satisfacerlo. El caso de uso finaliza cuando se le comunica al cliente el resultado final del análisis de su
pedido.
CURSO NORMAL DE EVENTOS
Acción del actor Respuesta del proceso de negocio
1. El Cliente envía una orden de 2.El Usuario recibe el pedido del cliente por teléfono o correo ordinario de la empresa.
pedido que incluye fecha de 3.El Usuario revisa el pedido, comienza su procesamiento, y lo envía al Jefe Técnico.
solicitud, datos del cliente y 4.El Jefe Técnico analiza la viabilidad de cada producto pedido por separado:
productos solicitados. Si el producto pedido está en Catálogo, se acepta su fabricación.
5. El Jefe Técnico informa al Usuario la aceptación o rechazo de cada producto.
Si el pedido o parte de éste es aceptado pasar a 6
Si el pedido es rechazado pasar a 8
6.El Jefe Técnico crea una orden de trabajo para cada producto del pedido, a partir de la plantilla
de fabricación y las envían al Jefe de Producción, quedando pendiente su lanzamiento.
7. El Jefe de Producción planifica la producción de las órdenes de trabajo recibidas.
8. El Usuario informa al cliente.

9. El Cliente recibe la
comunicación del resultado final
del análisis del pedido.
 Cliente Atender pedido

CURSOS ALTERNOS
En la línea 4 Si el producto no está en catálogo se considera Producto Especial y el Jefe Técnico estudia
su posible producción:
Si es viable, se acepta la fabricación del Producto Especial. Ver Sección Aceptar
Producto Especial
Si no es viable, no se fabrica el Producto Especial. Ver Sección Rechazar Producto
Especial

Prioridad Alta
Mejoras Establecer, además, la comunicación con el usuario a través de correo electrónico y vía
Internet.
El Jefe de producción colocará las órdenes de producción en una cola y automáticamente
se planificará la producción de la semana según las capacidades de las líneas y los pedidos
pendientes.

Otras secciones
Sección Aceptar Producto Especial
1.El Jefe Técnico incluye el Producto Especial en Catálogo
2.El Jefe Técnico diseña la Carta Tecnológica del Producto Especial.

Sección Rechazar Producto Especial

1.El Jefe Técnico incluye el Producto Especial en
Registro de Productos Especiales Rechazados,
indicando las causas del rechazo.