UML- RUP

Ing. Prof. Mansilla Luciano Damián

 PROCESO DE DESARROLLO
• Define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo

• No existe un proceso de software universal. Las características de cada proyecto

(equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable
Rational Unified Process (RUP)
• Pruebas funcionales
• Pruebas de desempeño
• Gestión de requisitos
• Gestión de cambios y configuración
• Ingeniería de Negocio
• Ingeniería de datos
• Diseño de interfaces
Características Esenciales - RUP
• Proceso Dirigido por los Casos de Uso.
• Proceso Iterativo e Incremental.
• Proceso Centrado en la Arquitectura.
UML-RUP
UML-RUP
Dirigido por casos de uso
• Capturar, definir y
• Validar los casos de uso
• Realizar los casos de uso
• Verificar que se satisfacen
los casos de uso
UML-RUP
Dirigido por casos de uso
UML-RUP
Iterativo e Incremental
• El ciclo de vida iterativo se basa en la evolución de prototipos
ejecutables que se muestran a los usuarios y clientes.
• En el ciclo de vida iterativo a cada iteración se reproduce el ciclo
de vida en cascada a menor escala
• Los objetivos de una iteración se establecen en función de la
evaluación de las iteraciones precedentes
UML-RUP
Iterativo e Incremental
 UML-RUP
Centrado en la arquitectura

•Arquitectura de un sistema es la organización o estructura de sus

partes más relevantes.
•Una arquitectura ejecutable es una implementación parcial del
sistema, construida para demostrar algunas funciones y
propiedades.
•RUP establece refinamientos sucesivos de una arquitectura
ejecutable, construida como un prototipo evolutivo
UML-RUP
UML-RUP
•Claves en el desarrollo de Sistemas de Información
Notación
Ej: UML

Herramientas
Proceso
Ej: Enterprise
Ej: RUP
Architecht
UML-CASOS DE USO
 CAPTURA DE
REQUERIMIENTOS
¿Qué son los Requerimientos/requisitos?
• Los requerimientos definen los servicios que el sistema
ha de proporcionar y establecen restricciones sobre el
funcionamiento del sistema.
• Son descripciones de cómo ha de comportarse el
sistema, información del dominio de la aplicación,
restricciones sobre la operación del sistema, o
especificaciones de una propiedad o atributo del
sistema.
 Captura de Requerimientos
• Se define al proceso de descubrir o averiguar, normalmente bajo situaciones
complejas, lo que será construido.

Clasificación de requerimientos:
• Funcionales (lo que el sistema debe hacer)
• No Funcionales (restricciones de las funcionalidades o del sistema)
UML - CASO DE USO
Paso Resultado

Listar los requerimientos Lista de características

candidatos

Entender el contexto del sistema Modelo de Negocios o Modelo de

Dominio

Capturar los requerimientos Modelo de Casos de uso

funcionales.

Capturar los Requerimientos No- Requerimientos Suplementarios o

Funcionales casos de uso individuales
(Requerimientos Especiales)
UML - CASO DE USO
Listar los requerimientos candidatos
Lista de características, la cual es utilizada para planear el trabajo.
Grupo de ideas (que pueden ser aportadas, por usuario, clientes, analistas y
desarrolladores).
Cada característica tiene un nombre corto y una breve explicación
Se los puede caracterizar por
• Estatus (Ej., propuesto, aprobado, incorporado o validado)
• Costo estimado de implementación
• Prioridad (Ej. critico, importante o auxiliar )
• Nivel de riesgo asociado en la implementación de características
UML - CASO DE USO
Entender el contexto del sistema
Entender el vocabulario del entorno -> Glosario
Modelo de Conceptos del contexto -> Objetos de Dominio
Dominio Relaciones entre obj. ->Diag de clases
Realizado por expertos

Identificar los objetos de dominio

Modelo de participantes del negocio.
Negocio Modelo de Dominio
Identificar los procesos y establecer la
competencia de cada proceso (quien
debe hacerlo, que debe hacer, etc.)
Actores y C.U. de Negocio
UML - CASO DE USO
Requerimientos Funcionales
Misión modelo del Modelo de Casos de usos
1. Comunicar, describir y verificar el conjunto de requerimientos y reglas de
negocio que expresan la funcionalidad y el valor de un sistema para los actores
que interactúan con el.
2. Compartir un lenguaje común entre todos los agentes involucrados en el
desarrollo del sistema.
3. Organizar la complejidad de un sistema para una mejor comprensión de su
naturaleza y dinámica.
UML - CASO DE USO
Requerimientos No Funcionales
• Estos requerimientos especifican las propiedades del sistema, tales como entorno
y constantes de implementación, rendimiento, dependencia de plataformas,
mantenimiento, extensibilidad, etc.
• Clasificación:
• De interfaz
• Físico
• Constantes de Diseño
• Constantes de Implementación
DIAGRAMA DE CASOS DE USO
UML - CASO DE USO
• “Un caso de uso es una forma o patrón o ejemplo concreto
de utilización, un escenario que comienza con algún usuario
del sistema que inicia alguna transacción o secuencia de
eventos interrelacionados” (Ivar Jacobson, 1992)
• El diagrama de un caso de uso muestra la interacción entre
casos de uso y actores. Nos permite representar las
funcionalidades del sistema, desde el punto de vista del
usuario
 UML - CASO DE USO
Elementos
• Actor: conjunto coherente de roles que los
usuarios de los casos de uso desempeñan
cuando interactúan con ellos
• Caso de Uso: una secuencia de acciones,
incluyendo las variantes, que un sistema (u
otra entidad) puede realizar, interactuando
con los actores del sistema
• Límite del sistema: Representa los límites
entre el sistema físico y los actores que
interaccionan con el sistema físico
 UML - CASO DE USO
Elementos
• Asociación: la participación de un actor en un caso
de uso
• Extend: relación de extensión de un caso de uso a
otro, especificando como el comportamiento de
caso de uso extendido puede ser insertado en el
comportamiento del caso de uso base
• Include: relación entre casos de uso. Especifica
como el comportamiento del caso de uso incluido
es insertado en el caso de uso base
• Generalización: Una relación taxonómica entre un
caso de uso general y un caso de uso especifico
 UML - CASO DE USO
Elementos
• Asociación: la participación de un actor en un caso
de uso
• Extend: relación de extensión de un caso de uso a
otro, especificando como el comportamiento de
caso de uso extendido puede ser insertado en el
comportamiento del caso de uso base
• Include: relación entre casos de uso. Especifica
como el comportamiento del caso de uso incluido
es insertado en el caso de uso base
• Generalización: Una relación taxonómica entre un
caso de uso general y un caso de uso especifico
ACTORES
UML - CASO DE USO
• Es una agrupación uniforme de personas, procesos o máquinas
que interactúan con el sistema, subsistema o clase (representa
un rol)
• Externos al sistema -> Delimitan el sistema
• Pueden representar:
• o Un rol que un usuario puede desempeñar con relación al
sistema.
• o Una entidad externa tal como otro sistema o base de datos
que reside fuera del sistema (actores no Humanos).
UML - CASO DE USO
¿Como identificar los actores?
¿Quién está interesado en un requerimiento concreto ?
¿Quién será beneficiario de la nueva funcionalidad ?
¿Quién proveerá, usará y/o retirará, información ?
¿Quién dará soporte y administrará el sistema ?
¿Usará el sistema un recurso externo (ej BD externas) ?
¿Un usuario actuará con diferentes roles ?
¿Diferentes usuarios actuarán con un mismo rol ?
¿Interaccionará el nuevo sistema con un sistema antiguo ?
UML - CASO DE USO
Identificar los Actores No-Humanos
• En UML, los usuarios finales humanos no son los únicos actores en el sistema.
• El termino actor también incluye cualquier cosa que provea información o
produzca eventos directamente en el sistema.
• Estos actores pueden ser tanto otros sistemas o subsistemas, bases de datos,
hardware, y dispositivos físicos.
UML - CASO DE USO
CASOS DE USO
UML - CASO DE USO
Un escenario
• Es una secuencia de pasos para lograr una meta
• Cada paso en el escenario es una submeta (puede ser otro caso de uso o una
acción de más bajo nivel)
• Un escenario es una instancia de un caso de uso es un flujo a través de un caso de
uso.
• Primarios: Flujo normal - la forma en la que el sistema debiese funcionar
• Secundarios: Excepciones al escenario primario
UML - CASO DE USO
Definición Formal
• Un caso de uso es un tipo de clasificador que representa
una unidad coherente de funcionalidad provista por un
sistema, un subsistema o una clase que se manifiesta
como una secuencia de mensajes intercambiados entre
el sistema (subsistema, clase) y uno o más interactores
externos (llamados actores) junto a las acciones
realizadas por el sistema. (subsistema, clase)
UML - CASO DE USO
• Agrupa una familia de escenarios de uso según un criterio funcional
• Se caracteriza por la meta que el actor primario tiene sobre las
responsabilidades del sistema y muestra como ésta puede conseguirse (o
no conseguirse).
• Describen tanto lo que hace el actor como lo que hace el sistema cuando
interactúa con él
• El énfasis está puesto en la interacción.
• La colección de todos los casos de uso (Diagrama de Casos de Uso) define
todo el comportamiento del sistema. El conjunto de objetivos alcanzables
por los actores.
UML - CASO DE USO
Relación entre Casos de uso
Los Casos de Uso de pueden relacionarse con otros, existen 4 maneras
(dependencias)
Mediante de pre y post condiciones (un caso puede habilitar a un segundo), esto no
se especifica gráficamente (no es necesario)
UML provee 3 estereotipos de dependencias (que permiten estructurar y factorizar
los Casos de Uso)
UML - CASO DE USO
Granularidad de Casos de Uso
Nivel de descomposición de un Caso de Uso principal en Casos de Uso secundarios:
1. <<Include>> CU secundarios que se utilizan de manera sistemática.
2. <<Extend>> CU secundarios que se utilizan de manera opcional cuando se
cumplen ciertas condiciones.
3. <<Generalización>> CU secundarios que son especializaciones de otro UC con
alguna variación concreta.

• No hay un grado de granularidad recomendado, cada uno trabajará con el grado de

granularidad con que se sienta más cómodo.
UML - CASO DE USO
Relación <<include>>
El comportamiento únicamente puede ser factorizado en un caso de uso separado si es compartido por dos o más
casos de uso.

Relación <<extend>>
Se utiliza para extender de forma condicionada el comportamiento de un caso de uso existente.

Es una forma de añadir comportamiento a un caso de uso sin modificarlo.

Relación Generalización
El caso de uso general puede ser únicamente una descripción, los flujos se especifican en los casos de uso
especializados.

Es posible agregar comportamiento al caso de uso hijo añadiendo pasos a la secuencia de comportamiento
heredada del padre, así como declarando relaciones de extensión y de inclusión para el hijo.
UML - CASO DE USO
<<extend>> versus <<include>>
• Son constructores similares, por lo que cuándo usar uno u otro puede no estar
claro.
• Utilizar la relación <<extend>> para especificar comportamiento excepcional,
opcional o que ocurra raramente.
• Utilizar la relación <<include>> para el comportamiento que sea compartido por
dos o más casos de uso, evitar la factorización de actividades simples.
UML - CASO DE USO
Crear demasiados casos de uso
• La fragmentación excesiva de la especificación del sistema puede conducir a una
especificación confusa. (por ejemplo sacar muchos include y extends)
• No es siempre necesario estructurar el modelo de casos de uso en términos de
casos incluidos, extendidos, etc.
• Evitar demasiado casos de uso que trabajan sobre clases menores (ABMC/CRUD)
• Las descripciones de casos de Uso son demasiado cortas y simples