Desarrollo de Software

Con UML
Construcción de una casa para “pipo”

Puede hacerlo una sola persona

Requiere:
Modelado mínimo
Proceso simple
Herramientas simples
Construcción de una casa

Construida eficientemente y en un tiempo

razonable por un equipo
Requiere:
Modelado
Proceso bien definido
Herramientas más sofisticadas
Claves en Desarrollo de SI

Notación

Herramientas Proceso
Abstracción - Modelado Visual (MV)

“El modelado captura las

partes esenciales del sistema”

Orden

Item

envío

Proceso de Negocios

Sistema Computacional
MV para definir la Arquitectura del SW
Interfaz de Usuario
(Php,
Java, ..)
Lógica del Negocio
(Php, Java, ..)

Servidor de BDs
(C++ & SQL, ..)

“Modelar el sistema independientemente

del lenguaje de implementación”
¿Qué es UML?
 UML = Unified Modeling Language
 Un lenguaje de propósito general para el
modelado orientado a objetos
 Documento “OMG Unified Modeling Language
Specification”
 UML combina notaciones provenientes desde:
• Modelado Orientado a Objetos
• Modelado de Datos
• Modelado de Componentes
• Modelado de Flujos de Trabajo (Workflows)
Situación de Partida
 Diversos métodos y técnicas OO, con muchos aspectos
en común pero utilizando distintas notaciones
 Inconvenientes para el aprendizaje, aplicación,
construcción y uso de herramientas, etc.
 Pugna entre distintos enfoques (y correspondientes
gurús)

Establecer una notación estándar

UML “aglutina” enfoques OO
Rumbaugh
Booch Jacobson

Odell
Meyer
Pre- and Post-conditions

Shlaer-Mellor UML
Object life cycles
Harel
State Charts
Gamma et. al.
Frameworks, patterns,
notes
Embly Wirfs-Brock
Singleton classes Responsabilities
Fusion
Operation descriptions,
message numbering
Modelos y Diagramas
 Un modelo captura una vista de un sistema del mundo
real. Es una abstracción de dicho sistema, considerando
un cierto propósito. Así, el modelo describe
completamente aquellos aspectos del sistema que son
relevantes al propósito del modelo, y a un apropiado nivel
de detalle.

 Diagrama: una representación gráfica de una colección

de elementos de modelado, a menudo dibujada como un
grafo con vértices conectados por arcos
... Modelos y Diagramas
 Un proceso de desarrollo de software debe ofrecer un conjunto
de modelos que permitan expresar el producto desde cada una
de las perspectivas de interés

 El código fuente del sistema es el modelo más detallado del

sistema (y además es ejecutable). Sin embargo, se requieren
otros modelos ...

 Cada modelo es completo desde su punto de vista del sistema,

sin embargo, existen relaciones de trazabilidad entre los
diferentes modelos
... Diagramas de 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
Paquetes en UML
 Los paquetes ofrecen un mecanismo general para
la organización de los modelos/subsistemas
agrupando elementos de modelado

 Se representan gráficamente como:

Nombre de
paquete
… Paquetes en UML
 Cada paquete corresponde a un submodelo
(subsistema) del modelo (sistema)

 Un paquete puede contener otros paquetes, sin

límite de anidamiento pero cada elemento
pertenece a (está definido en) sólo un paquete

 Una clase de un paquete puede aparecer en

otro paquete por la importación a través de una
relación de dependencia entre paquetes
 … Paquetes en UML
 Todas las clases no son
necesariamente visibles desde el
exterior del paquete, es decir,
un paquete encapsula a la vez
que agrupa

 El operador “::” permite

designar una clase definida en
un contexto distinto del actual
… Paquetes en UML
Diagrama de Casos de Uso

 Casos de Uso es una técnica para capturar

información de cómo un sistema o negocio
trabaja, o de cómo se desea que trabaje

 No pertenece estrictamente al enfoque

orientado a objeto, es una técnica para captura
de requisitos
Modelado de Casos de Uso
 Un caso de uso especifica un comportamiento
deseado del sistema.
 Representan los requisitos funcionales del
sistema.
“Un caso de uso especifica un conjunto de
secuencias de acciones, incluyendo
variantes, que el sistema puede ejecutar y
que produce un resultado observable de
valor para un particular actor.”
(Definición en UML)

 Describen qué hace el sistema, no cómo lo

hace.
Modelado de Casos de Uso
 Partes de un caso de uso (cdu)
• Conjunto de secuencias de acciones; cada secuencia
representa un posible comportamiento del sistema
• Actores, roles que pueden jugar los usuarios
• Variantes: versiones especializadas, un cdu que extiende a
otro o un cdu que incluye a otro
• Un caso de uso realiza un trabajo tangible.
Ejemplo de Caso de Uso
actor caso de uso

Gestionar Préstamos
Responsable
Prestamos

asociación
Actores
Un actor representa un conjunto coherente
de roles que juegan los usuarios de los casos
de uso al interaccionar con el sistema.
 Roles jugados por personas, dispositivos, u
otros sistemas.
 El tiempo puede ser un actor (“procesos
iniciados automáticamente por el sistema”).
 No forman parte del sistema.
Actores
 Un usuario puede jugar diferentes roles.
 En la realización de un caso de uso pueden
intervenir diferentes actores.
 Un actor puede intervenir en varios casos de uso.
 Identificar casos de uso mediante actores y
eventos externos.
 Un actor necesita el caso de uso y/o participa en
él.
Actores
 Dos tipos de actores:
• Principal:
Requiere al sistema el cumplimiento de un objetivo.

• Secundarios:
El sistema necesita de ellos para satisfacer un
objetivo.
Escenarios y Casos de Uso
 Un caso de uso describe un conjunto de
secuencias de interacciones entre actores y el
sistema (escenarios): flujo principal y flujos
alternativos o excepcionales.
 Un escenario es una instancia de un caso de uso
 Un escenario es una historia particular de uso
de un sistema.
 Escenarios principales vs. Escenarios
secundarios
Propiedades de los casos de
uso
 Son iniciados por un actor con un objetivo en
mente y es completado con éxito cuando el
sistema lo satisface.
 Puede incluir secuencias alternativas que llevan
al éxito y fracaso en la consecución del
objetivo.
 El sistema es considerado como una “caja
negra” y las interacciones se perciben desde
fuera.
 El conjunto completo de casos de uso especifica
todas las posibles formas de usar el sistema,
esto es el comportamiento requerido.
Descripción de un caso de uso
 Son documentos de texto, no son
diagramas.
• El modelado de casos de uso consiste en escribir
texto, no en dibujar diagramas.
 Describir el flujo de eventos
• Texto estructurado informal
• Texto estructurado formal (plantillas)
• Pseudocódigo
• Notaciones gráficas: diagramas de secuencia

 Debe ser legible y comprensible para un usuario

no experto.
 Debe indicar: actores, flujos principal y
excepcionales.
Diagrama de un caso de uso
 Descripción de un caso de
uso: textual
Realizar Venta (en un Terminal de Punto de Venta o
TPV)

Actor Principal: Cajero

Flujo Principal: Un cliente llega al TPV con un conjunto de
artículos. El Cajero registra los artículos y se genera un ticket. El cliente
paga en efectivo y recoge los artículos.

1. El cliente llega al TPV con los artículos.

2. El cajero registra el identificador de cada artículo.
3. El sistema obtiene el precio de cada artículo y añade la información a
la transacción de venta.
4. Al acabar el cajero indica la finalización de la introducción de
artículos.
 Descripción de un caso de
uso: textual
Realizar Venta (en un Terminal de Punto de Venta o
TPV)
5. El sistema calcula el total de la compra y lo muestra.
6. El cajero le dice al cliente el total.
7. El cliente realiza el pago.
8. El cajero registra la cantidad de dinero recibida.
9. El sistema muestra la cantidad a retornar al cliente y genera un recibo.
10. El cajero deposita el dinero recibido y saca la cantidad a devolver que
entrega al cliente junto al ticket de compra.
11. El sistema almacena la compra completada.
12. El cliente recoge los artículos comprados.
Descripción de un caso de
uso: gráfica
Realizar Venta

Diagrama de secuencia

:Sistema

: Cajero
crearNuevaVenta()

* introducirItem(cod,cantidad)

finalizarVenta()

hacerPago(cantidad)
Ejemplo diagrama de casos de uso

Reservar Libro Prestamo Revista

Profesor

Prestamo Libro Devolver Revista

Socio

Devolver Libro Actualizar Catalogo

Bibliotecario

Extender Prestamo
Consultar Socio
Casos de uso y Colaboraciones
 Con un caso de uso se describe un
comportamiento esperado del sistema, pero no
se especifica cómo se implementa.
 Una caso de uso se implementa a través de una
colaboración:
“Sociedad de clases y otros elementos que
colaborarán para realizar el comportamiento
expresado en un caso de uso”
 Una colaboración tiene una parte estática
(diagramas de clases) y una parte dinámica
(diagramas de secuencia).
Casos de uso y Colaboraciones
caso de uso

colaboración
Hacer Pedido

Gestión Pedidos
realización
 Organización de Casos de uso
 Tres tipos de relaciones:
• Generalización
• Un cdu hereda el comportamiento y significado de
otro.
• Inclusión
• Un cdu base incorpora explícitamente el
comportamiento de otro en algún lugar de su
secuencia.
• Extensión
• Un cdu base incorpora implícitamente el
comportamiento de otro cdu en el lugar especificado
indirectamente por este otro cdu.
 Ejemplo
Extensión
«extend» Hacer Pedido
Hacer Pedido Urgente
(establecer
prioridad)

«include»
Comprobar clave
Inclusión
Validar Usuario
Generalización

«include»
Seguir Pedido Examinar retina
Relación de inclusión
 Permite factorizar un comportamiento en un
caso de uso aparte y evitar repetir un mismo
flujo en diferentes casos de uso.
 Ejemplo:
Hacer Pedido:
Obtener y verificar el número de
pedido;
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
…
Relación de extensión
 El caso de uso base incluye una serie de
puntos de extensión.
 Sirve para modelar:
• la parte opcional del sistema, o
• un subflujo que sólo se ejecuta bajo ciertas
condiciones.
 Relación de extensión
 Ejemplo:

Hacer Pedido:
Incluir “Validar usuario”;
Recoger los ítem del pedido del
usuario;
Establecer prioridad: punto de
extensión
Enviar pedido para ser procesado según
la prioridad.
Obtención de casos de uso
1) Identificar los usuarios del sistema.
2) Encontrar todos los roles que juegan los
usuarios y que son relevantes al sistema.
3) Para cada rol identificar todas las formas
(objetivos) de interactuar con el sistema.
4) Crea un caso de uso por cada objetivo.
5) Estructurar los casos de uso.
6) Revisar y validar con el usuario.
Casos de Uso: Construcción
 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?
… Casos de Uso: Construcción
 La descripción del Caso de Uso comprende:
• el inicio: cuándo y qué actor lo produce?
• el fin: cuándo se produce y qué valor devuelve?
• la interacción actor-caso de uso: qué mensajes
intercambian ambos?
• objetivo del caso de uso: ¿qué lleva a cabo o
intenta?
• cronología y origen de las interacciones
• repeticiones de comportamiento: ¿qué
operaciones son iteradas?
• situaciones opcionales: ¿qué ejecuciones
alternativas se presentan en el caso de uso?
Ejemplos

Verificar Situación del Cliente

Supervisor

Preparar Catálogo
Administrativo Sistema
Inventario

Tipos de Venta
… Ejemplos
En el paquete tipos de venta:

Venta Normal

Venta en Rebajas
Vendedor

Venta en Ofertas
… Ejemplos

Solicitar Préstamo
Cliente

[Tarjeta Caducada]

<<extend>>

Solicitar Nueva Tarjeta

… Ejemplos

<<include>>
Reintegro Cuenta Corriente

Cliente Verificar Operación

<<include>>

Reintegro Cuenta de Crédito