Desarrollo Aplicaciones RUP UML

Desarrollo de Aplicaciones con RUP y UML
Guía Teórica desarrollada por el profesor del curso:
Ing. Jorge Nolasco Valenzuela

¿Qué es RUP?
Es una metodología
RUP es un proceso de desarrollo de software que forma
disciplinada de asignar tareas y responsabilidades en una
empresa de desarrollo (quién hace qué, cuándo y cómo).
¿Qué es UML? ( versión 2.3 )
UML tiene por objetivo ser un lenguaje de modelado de
proposito general.
No tiene propietario y esta basado en el común acuerdo de la
gran parte de la comunidad informática.
¿Qué es Rational Rose?
Es una Herramienta ( versión 7.0 )
I. RATIONALI. RATIONAL UNIFIED PROCESSUNIFIED PROCESS

Flujos de Trabajo
de Ingeniería
Flujos de Trabajo
de Apoyo
II. FASES PRINCIPALES DEL CICLO DE VIDAII. FASES PRINCIPALES DEL CICLO DE VIDA
ITERATIVO E INCREMENTALITERATIVO E INCREMENTAL

El proceso puede describirse en dos dimensiones, o a lo
largo de dos ejes:
El eje horizontal representa tiempo y muestra el
aspecto dinámico del proceso, expresado en términos de
ciclos, fases, iteraciones, y metas.
El eje vertical representa el aspecto estático del
proceso; como está descrito en términos de actividades,
artefactos, trabajadores y flujos de trabajo.
III. ESTRUCTURA DEL RUPIII. ESTRUCTURA DEL RUP

¿Qué es UML?¿Qué es UML?
 UML = Unified Modeling Language
 Un lenguaje de propósito general para el
modelado orientado a objetos
 UML combina notaciones provenientes desde:
 Modelado Orientado a Objetos ( mejora la
captura de requerimientos)
 Modelado de Datos ( base de datos )
 Modelado de Componentes ( piezas de
software )

El Lenguaje Unificado de Modelado es un lenguaje gráfico
para visualizar, especificar, construir y documentar los
artefactos de un sistema con gran cantidad de software.
UML proporciona una forma estándar de escribir los planos de
un sistema, cubriendo tanto las cosas conceptuales, tales como
procesos del negocio y funciones del sistema, como las cosas
concretas, tales como las clases escritas en un lenguaje de
programación específico, esquemas de bases de datos y
componentes software reutilizables.
¿Qué es UML?¿Qué es UML?

UML AGLUTINA ENFOQUES OOUML AGLUTINA ENFOQUES OO
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-Brock
Fusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions,
message numbering
Singleton classes
Frameworks, patterns,
notes
Object life cycles

¿POR QUÉ MODELAMOS?¿POR QUÉ MODELAMOS?
• Construimos modelos para: comunicar, visualizar y controlar la
arquitectura, comprender mejor el sistema y para controlar los
riesgos.
• La importancia de modelar
• Principios del modelado
• Modelado orientado a objetos

codigo
nombre
dni
fechaIngreso
telefono
direccion
cargo
sueldo
MODELO DE DATOS
Entidad : Empleado
MODELO DE OBJETOS
Clase : Empleado
Persona
Empleado
Direccion
Telefono
Cargo
ATOMIZACION
HOMOGENEIZACION
ENTE CON DATOS HETEROGENEOS ENTES CON DATOS HOMOGENEOS
COMPONENTES
REUTILIZABLES
UNIFORMIZACION
¿POR QUÉ MODELAMOS?¿POR QUÉ MODELAMOS?

LA IMPORTANCIA DE MODELARLA IMPORTANCIA DE MODELAR
• ¿Qué es un modelo? Un modelo es una simplificación de la realidad.
• ¿Por qué modelamos? Construimos modelos para comprender mejor el
sistema que estamos desarrollando.
• A través del modelado conseguimos: visualizar cómo es, especificar la
estructura o el comportamiento, guías para la construcción,
documentar.
•Construimos modelos de sistemas complejos porque no podemos
comprender en sistema en su totalidad.
•Construimos La palabra clave aquí es “formal”. En realidad, incluso en
el proyecto más simple los desarrolladores hacen algo de modelado, si
bien muy informalmente.

PRINCIPIOS DEL MODELADOPRINCIPIOS DEL MODELADO
• Primero:Primero: La elección de qué modelos crear tiene una profunda
influencia sobre cómo se acomete un problema y cómo se da
forma a una solución
• Segundo:Segundo: Todo modelo puede ser expresado a diferentes niveles
de precisión.
• Tercero:Tercero: Los mejores modelos están ligados a la realidad.
• Cuarto:Cuarto: Un único modelo no es suficiente. Cualquier sistema no
trivial se aborda mejor a través de un pequeño conjunto de
modelos casi independientes.

MModeladoodelado OOrientada arientada a OObjetosbjetos
Caracteriza la estructura estática de los objetos, en términos de grupos de
objetos análogos (clases), la herencia y relaciones de importancia con otros
objetos.
Pasos para el modelamiento:
1ro. Identificación de objetos y clases:
 Cosas tangibles, concretas; e intangibles.
 Funciones desempeñadas por personas u otros.
 Incidencias, ocurrencias y eventos que suceden.
 Interacciones “transacciones”.
Ej. Compra (comprador, vendedor y producto comprado).

2do. Identificación de atributos:
 ¿ Qué características posee cada objeto?
 ¿Qué información se necesita conocer, proposito de una
entidad?
3ro. Identificación de Relacionamiento:
 Relaciones
 Multiplicidad o cardinalidad.
MMODELADOODELADO OORIENTADA ARIENTADA A OOBJETOSBJETOS

Business modeling results can be used as
input to system development.
BUSINESS MODELING AND SYSTEMBUSINESS MODELING AND SYSTEM
DEVELOPMENTDEVELOPMENT
Business Modeling
Use-Case
Model
Business
Object Model
System Development
Use-Case
Model
Design
Model
Implementation
Model
Test
Model
Deployment
Model
Analysis
Model

MODELO DE DESARROLLO OO ITERATIVO EMODELO DE DESARROLLO OO ITERATIVO E
INCREMENTALINCREMENTAL
ANALISIS OO
DISEÑO OO
IMPLEMENTACION OO
INTEGRACION OON VECES
Clases
y
Objetos
MOD. NEG. OO

CICLO DE VIDA DE LOS PROYECTOSCICLO DE VIDA DE LOS PROYECTOS
“Iteración” se refiere a un paso en el ciclo de vida, formado por un
conjunto de actividades, con un plan y criterios de evaluación, que
acaba en una versión.
Una iteración resulta en un “incremento” o crecimiento del proyecto
general.
El Proceso de Desarrollo de Software Unificado sugiere que se itere
a través del ciclo produciendo actualizaciones incrementales.
Cada incremento mejora, corrige y se construye sobre los
incrementos previos.

En cada iteración se deben hacer las siguientes actividades:
Seleccionar y analizar los casos de uso relevantes
Crear un diseño utilizando la arquitectura elegida
Implementar el diseño en componentes
Verificar que los componentes satisfacen los casos de uso
Cuando una iteración alcanza sus objetivos, se procede con la
siguiente iteración
CICLO DE VIDA DE LOS PROYECTOSCICLO DE VIDA DE LOS PROYECTOS

• Fases
– Iniciación: la idea inicial se lleva al punto de estar suficientemente
bien fundamentada para garantizar la entrada en la fase de
elaboración.
– Elaboración: se definen la visión del producto y su arquitectura.
Se expresan con claridad los requisitos del sistema, se priorizan se
usan para producir una base arquitectónica
– Construcción: el software se lleva desde una base arquitectónica
ejecutable hasta su disponibilidad para los usuarios.
– Transición: el software es puesto en manos de los usuarios, se
erradican errores y se añaden
características nuevas.
• Cada fase contiene una o más iteraciones
FASES PRINCIPALES DEL CICLO DE VIDAFASES PRINCIPALES DEL CICLO DE VIDA

Rational
Unified
Process
El proceso para
desarrollo de Software

Rational Unified Process (RUP)
• Captura varias de las mejores prácticas en el desarrollo
moderno de software en una forma que es aplicable
para un amplio rango de proyectos y organizaciones.
• Es una guía de cómo utilizar de manera efectiva UML.
• Provee a cada miembro de un equipo un fácil acceso a
una base de conocimiento con guías, plantillas y
herramientas para todas las actividades críticas de
desarrollo.
• Crea y mantiene modelos, en lugar de enfocarse en la
producción de una gran cantidad de papeles de
documentación.

Estructura de RUP Cont.
Administración
Ambiente
Modelación de Negocios
Implementación
Prueba
Análisis y Diseño
Iteración(es)
Preliminar
Iter.
#1
Fases
Flujos de Trabajo de Procesos
Iteraciones
Flujos de Trabajo de Soporte
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Implantación
Admin. Configuración
Requerimientos
Elaboración TransiciónInicio Construcción
Contenido

Flujos de Trabajo y Modelos
OK
OK
Fail
Realized By
Implemented
By
Verified By
Implementation
Model
Test ModelDesign Model
Use-Case
Model
Modelos
Disciplinas Test
Implemen-
tation
Analysis &
Design
Requirements
Business Use-
Case Model
Business
Modeling
Business
Object Model
BBB
B
Realized
By
Automated
By

Administración
Ambiente
Modelación de Negocios
Implementación
Prueba
Análisis y Diseño
Iteración(es)
Preliminar
Iter.
#1
Fases
Flujos de Trabajo de Procesos
Iteraciones
Flujos de Trabajo de Soporte
Iter.
#2
Iter.
#n
Iter.
#n+1
Iter.
#n+2
Iter.
#m
Iter.
#m+1
Implantación
Admin. Configuración
Requerimientos
Elaboración TransiciónInicio Construcción
Workflow de
Iteración
El Proceso Unificado

Modelo del Negocio
Objetivo:
Comprender el conjunto de procesos de negocio
que tienen lugar dentro de una empresa, como
paso previo a establecer los requisitos del sistema
a desarrollar.
¿Cómo consigue la empresa sus objetivos?
Reingeniería.

Como ...?
• Identificar y delimitar los procesos de negocio
según los objetivos de la organización.
• Definir un caso de uso del negocio para cada
proceso del negocio, utilizando un diagrama de
casos de uso del negocio para mostrar el contexto
y los límites de la organización bajo estudio.
• Identificar los roles implicados en los diferentes
procesos del negocio y describirlos en un diagrama
de roles.

Propósito
• El modelo del negocio “no implica” que se hagan
cambios en la forma como se hace el negocio.
Simplemente es una técnica para documentar
visualmente lo que su negocio hace.
• Comprender los problemas actuales de la
organización y su impacto.

Propósito
• Comprender la estructura y la dinámica de la
organización para la que se desarrolla el proyecto.
• Asegurar que los clientes, usuarios finales y
desarrolladores tengan un entendimiento común de la
organización. Visión compartida.
• Obtener, de forma preliminar, los requerimientos del
sistema que necesita la organización.

• El modelo del negocio es una técnica que
permite responder algunas preguntas críticas:
¿Cómo sabe usted que ha identificado todos los
casos de uso del sistema (funcionalidades del
sistema).?
¿Qué hacen los trabajadores (usuarios) antes de
usar el sistema?
¿Qué valor del negocio brinda el sistema?
¿Cuál es el sistema de negocio (proceso) que el
sistema computarizado apoya?
Propósito

Propósito
• ¿Cómo aseguramos que el sistema tendrá valor si no
entendemos como, quién y en que circunstancias se
usará?
• Para asegurar que estamos construyendo soluciones
orientadas al cliente (es decir sistemas de información
que satisfacen a nuestros clientes) no debemos pasar
por alto:
– El ambiente en el que estos sistemas trabajarán,
– Los roles y responsabilidades de los empleados
que usan el sistema,
– Las "cosas" que son manejadas por el negocio,

Beneficios
• Uno de los grandes beneficios de modelar el
negocio es mejorar la obtención de requisitos del
sistema, requisitos que conducirán a la creación de
sistemas de información que realmente encajen en
la organización y sean usados por usuarios finales.

Problema
• Un problema que frecuentemente se produce la
dificultad para que los analistas del negocio
comuniquen sus resultados eficazmente a los
participantes del equipo.
• Dicho problema se puede resolver usando el UML.

Modelado del Negocio
• Artefactos del modelo del negocio
Modelo de Casos de
Uso del Negocio
Especificación de
Casos de Uso del
Negocio
Modelo de Objetos
del Negocio
Glosario de
Términos
Visión
Actores del
Negocio
Casos de Uso
del Negocio
Trabajadores
del Negocio
Entidades del
Negocio

Notación UML Para el Modelo
del Negocio
Icono Nombre UML Definición
Actor del
Negocio
Alguien o Algo, fuera del negocio que
interactúa con el negocio.
Trabajador del
Negocio
Rol o conjunto de roles dentro del negocio.
Un trabajador del negocio interactúa con
otros trabajadores del negocio y manipula
entidades del negocio.
Entidad del
Negocio
una "cosa" manipulada o usada por
trabajadores del negocio.
Caso de uso del
negocio
Una sucesión de acciones que un negocio
ejecuta para producir un resultado de valor
observable a un actor de negocio particular.
(En este caso, sinónimo de proceso del
negocio)

Diagramas UML (M. Negocio)
• Cada diagrama de UML proporciona una vista
diferente del negocio:
– Diagramas de casos de uso describen el contexto del
negocio.
– Diagramas de actividad describen las conductas en el
negocio, o el flujo de trabajo del negocio.
– Diagramas de clase que describen la estructura
estática del negocio.
– Diagramas de interacción describen la interacción
dinámica entre los empleados y las cosas que ellos
manipulan.

Actores del Negocio
Mundo ExteriorMundo Exterior
OrganizaciónOrganización
NegocioNegocio

Actores del Negocio
• ¿Dónde encontrar a los actores del negocio?
– Clientes.
– Socios.
– Proveedores.
– Autoridades.
– Entidades legales y reguladoras.
– Sucursales.
– Dueños e inversionistas
– Sistemas informáticos fuera del negocio con los que
se interactúa.
– Otras partes de la organización.

Actores del Negocio
• La lista de los actores del negocio se realiza
especificando:
– Nombre del actor:
• Debe dar idea clara de la función que realiza o
desempeña.
• Sustantivo con letra inicial mayúscula.
– Descripción:
• Describir la función que realiza fuera del negocio y
la responsabilidad que tiene para el negocio.

Trabajador del Negocio
NegocioNegocio

• ¿Dónde encontrar trabajadores del negocio?
– Roles dentro del negocio.
– Personas que ejecutan los proceso o actividades del
negocio.
– Hardware o sistemas informáticos dentro del negocio
con los que se intercambia información directamente.

• La lista de los trabajadores del negocio se realiza
especificando:
– Nombre del trabajador:
desempeña.
– Descripción:
• Describe la función que realiza dentro del negocio
y su responsabilidad.

Caso del Uso del Negocio
NegocioNegocio

• ¿Dónde encontrar casos de uso del negocio?
– Principales procesos del negocio.
– Servicios principales para el cliente.
– Procesos de servicio a otras entidades.

• La lista de los casos del negocio se realiza
especificando:
– Nombre del caso de uso:
• Debe dar idea clara de las acciones a realizar.
• Se concibe desde el punto de vista del actor.
• Debe ser un verbo o una frase verbal en infinitivo.
– Descripción:
• Se indica el objetivo fundamental del caso de uso

Entidad del Negocio
NegocioNegocio

Entidad del Negocio
• Una entidad del negocio (business entity) representa a
un conjunto de información con propiedades,
comportamiento y semántica similares y que es
manipulado o manejado por trabajadores del negocio.
• Ejemplo:
– Factura.
– Solicitud de pago.
– Tarjeta de crédito.
Factura

Entidad del Negocio
• ¿Dónde encontrar entidades del negocio?
– Áreas, departamentos, direcciones.
– Objetos físicos.
– Transacciones.
– Personas.
– Sistemas externos.
– Organizaciones.
– Socios.

Entidad del Negocio
• La lista de las entidades del negocio se realiza
especificando:
– Nombre de la entidad:
desempeña.
– Descripción:
• Describir la función que realiza dentro del negocio.

Diagrama de Casos de uso
del Negocio
• Un diagrama de Casos de Uso del negocio representa
visualmente la interacción entre los servicios primarios
(casos del uso del negocio) que su negocio proporciona
y aquellos a quienes los servicios se proporcionan (los
actores del negocio).

Diagramas de clase (objetos)
• Los diagramas de clase del negocio documentan la
estructura interior del negocio.
• Cada clase en este diagrama o representa a un
trabajador del negocio (el empleado del negocio) o a
una entidad del negocio (una 'cosa' que el negocio
manipula).

D. Objetos “Caso Cuentas”
Individual Indistinta
Conjunta
Boleta incripción
Documento Indentidad
Tarjeta de Ahorro
Cuenta
Especialista en Cuentas
(fromActores y Trabajadores)
verifica
verifica
Genera
Abre

Los diagramas de casos de
uso representan, en sus
dos versiones, diferentes
conceptos:
Los casos de uso de
negocio representan los
procesos del negocio que
son usados por los roles
del negocio.
los casos de uso de
sistema describen un
sistema desde el punto de
vista del usuario.
Diagrama de Casos de Uso
Programar entrega
Despachador
Programar entrega
DespachadorDespachador
Caso de Uso de Negocio
Caso de Uso de Sistema
Atender Reservas
Cliente
Atender Bar

“Caso Salsa Dance”
Lea y analice con detenimiento el caso de estudio propuesto y elabore los siguientes diagramas:
Diagrama CUN
Actores del negocio
Diagrama
Modelo de objeto de Negocio
Trabajadores del negocio
Entidades del negocio
Diagrama
Caso de estudio Academia de Baile “Salsa Dance”
La academia de baile “Salsa Dance” ofrece a sus clientes lecciones privadas y por grupos. Se dan lecciones privadas
todo el día, y las lecciones por grupo se ofrecen en las noches. Los estudiantes que reciben lecciones privadas
algunas veces provienen de lecciones en grupo y los grupos también se pueden haber formado por estudiantes que
han tomado lecciones privadas, en este momento no se puede determinar que cambio es mas frecuente pero no se
han venido incrementando, lo que mas preocupa a la academia es que después de tres cambios un cliente
normalmente abandona la academia.
La academia está interesada en determinar las razones por las que un estudiante pasa entre lecciones de grupo a
privadas y viceversa, para ello cada vez que un estudiante que esta recibiendo un tipo de lección decide cambiar a
otro tipo, se le toma un cuestionario.
La academia emplea dos tipos de instructores de tiempo completo y por horas, de los últimos se debe tener su
disponibilidad horaria. Los instructores son asignados a lecciones privadas como a lecciones por grupo
indistintamente.
Además de las lecciones, la academia auspicia dos noches en la semana de concursos de baile. El propósito de los
concursos es dar a los estudiantes un lugar para que practiquen sus habilidades y también para buscar nuevos
valores.
A la academia le gustaría desarrollar un sistema de información para registrar a los estudiantes y las clases que han
tomado y registrar los resultados de los cuestionarios que son tomados cada vez que un estudiante cambia de tipo de
lección. Los administradores también desearían saber cuántos y cuáles tipos de lecciones ha enseñado cada
instructor. Finalmente, es deseable registrar los concursos en los que ha participado cada estudiante y el puesto
obtenido.

MODELADO DEL NEGOCIO
“Caso Salsa Dance”
I. Evaluar la organización
Organización:
Nombre de la Organización : Escuela Salsa Dance
II. Modelo de Casos de Uso del Negocio
1. Lista de los actores del negocio
Cliente
Estudiante
2. Lista de los casos de uso del negocio
Inscribir
Dar Lecciones
Programar Horario
Cambiar Modalidad
Concursar
Encuestar
3. Diagrama de casos de uso del negocio
( Rational Rose )

MODELADO DEL NEGOCIO “Caso Salsa Dance”

Ver / ocultar documentación
o Ir a diagramas de clase, de interacción, de componentes, de estado, de despliegue, de caso de uso. Al
activar estos botones se muestra una lista con los diagramas del tipo correspondiente, para seleccionar cuál
se quiere visualizar.
o Ir al diagrama padre
o Ir al diagrama anterior
o Aumentar zoom, disminuir zoom
o Ajustar a ventana, deshacer ajustar
o Ayuda general

Esta ventana tiene los
siguientes componentes:
• “Browser”: muestra
de forma jerárquica
todos los elementos
de los modelos de un
proyecto.
Documentación: muestra
texto asociado al elemento
seleccionado. Permite
también modificar ese texto.
• “Log”: muestra mensajes
sobre errores, progreso de
tareas, etc.
• Diagramas: cada diagrama
se muestra con una ventana
diferente. Las ventanas de
diagrama cuentan con un
botón “overview”, que
permite desplazarse
rápidamente por el
contenido de diagramas

Ahora continuamos
creando
los casos de uso de negocio :
Inscribir
Dar Lecciones
Programar Horario
Cambiar Modalidad
Concursar
Encuestar
Para ello debemos crear un
p
a
q
u
e
t
e
donde crearemos los casos de

Ahora continuamos
creando los casos de uso de
negocio :
Inscribir
Dar Lecciones
Programar Horario
Cambiar Modalidad
Concursar
Encuestar
Comenzamos creando el
primer caso de uso de negocio
para ello seguimos los pasos a
la derecha

Ahora crearemos los caso
de
uso de negocia que faltan
crear de la manera anterior :
Dar
Lecciones
Programar
Horario
Cambiar
Modalidad
Concursar
Encuestar

1.- Proceso de
Negocio Inscribir
2.- Objetivo Selección de Candidatos mas adecuados para la
academia
3.- Actores
Postulante , secretaria
4.- Precondiciones
divulgar lecciones que ofrece la Academia
5.- Flujos
1.- Recepción de Documentos
2.- Si documentación esta conforme
2.1- Llenado de ficha de inscripción
2.2.- Elegir Horario
2.3.-Pago de Inscripción
2.4 Llenado de Boleta de Pago
2.5 Entrega de Boleta al Postulante
3.- de lo contrario
3.1 No conforme
6.- Pos condiciones
Informe de fecha de Inicio de Clases
7.- Excepciones
No exista Vacante
Reclutamiento directo por el área vacante

Para especificar cada caso de uso deberíamos de tomar en consideración los
siguientes aspectos:
1.Interacciones. Mencionar la participación del actor primario y la de cada actor secundario desde que inicia el caso de
uso hasta que termina.
Eventos. Indicar cada uno de los eventos que ocurren durante el caso de uso (consulta de datos, capturas, cálculos,
etc.)
Nivel de detalle. Los casos de uso y sus especificaciones son la base del contrato que establecemos con nuestro
cliente, por lo que debemos de buscar especificarlo al máximo detalle. Recuerda que entre más sepamos de la
funcionalidad del sistema más precisas serán las estimaciones de nuestro plan de trabajo.
Escenarios. Un caso de uso muestra diferentes escenarios posibles y no una sola forma de ejecutarlo. Debemos de
explicar cada uno de esos escenarios, mediante un flujo principal y sus diferentes flujos alternos y excepcionales.
Claridad y Enfoque de Usuario. Busca claridad en la explicación de los casos de uso utilizando la jerga de negocio a la
hora de redactarlo sin mencionar detalles técnicos a los que no está acostumbrado. Sobre todo te interesa poder validar
con éste que lo documentado en las espceificaciones de los casos de uso es lo que requiere para su sistema, así que si
no los entiende no cumplirán su propósito principal.
Durante los cursos y consultoría que impartimos a los analistas, les pido que me “platiquen” de qué se trata el caso de
uso solicitado por su cliente, y después escribimos eso mismo en las especificaciones, generalmente logramos así un
documento más claro que cuando lo escriben directamente sin platicarlo. La experiencia me dice que, por lo menos en
sistemas, la gente explica mejor las cosas oralmente que de forma escrita.
2.Generalmente se recomiendan varios elementos adicionales para documentar los casos de uso. Pero, puedo
asegurarte que la esencia es lo mencionado anteriormente. Pero, a continuación se mencionan algunos de esos
elementos extras con los que puedes complementar la plantilla para documentar tus especificaciones de casos de uso.
3.Propósito. Si comienzas por este punto se te facilitará definir los pasos más relevantes para ejecutar el caso de uso.
4.Precondiciones. Son las condiciones que se deben de cumplir en el sistema antes de iniciarlo. El estado en que se
debe encontrar el sistema antes de ejecutarlo. (Ej: Algún catálogo debe estar actualizado, debe estar en conexión con
otro sistema, el usuario debe estar conectado con cierto perfil específico)
5.Postcondiciones. Te indica como queda el sistema después de ejecutar el caso de uso. Imagina que eres un tester y
quieres comprobar si alguien acaba de ejecutar el caso de uso. ¿Qué cosas buscarías en el sistema? Seguramente
datos nuevos, modificados, eliminados o la posibilidad de elegir nuevas opciones en el sistema.
6.Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso especificado.
7.Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una relación de <<extend>>.

Una entidad del negocio
(business entity) representa
a un conjunto de información
con propiedades,
comportamiento y semántica
similares y que es
manipulado o manejado por
trabajadores del negocio.
Ejemplo:
Factura.
Solicitud de pago.
Tarjeta de crédito.
¿Dónde encontrar entidades
del negocio?
Áreas, departamentos,
direcciones.
Objetos físicos.
Transacciones.
Personas.
Sistemas externos.
Organizaciones.
Socios.

Capítulo N°4
Aplicación de los Casos de
Uso

TEMAS
• Diagramas de Casos de Uso de Sistema
– Relación de Generalización
– Relación Incluye
– Relación Extiende
– Especificación de casos de uso
– Prototipos

 Es una relación de Herencia
 Puede ocurrir entre actores o entre casos de uso
Representación Gráfica
 Mediante una línea sólida con cabeza de
flecha hueca
 Apunta desde el Hijo hacia el Padre
Relación de Generalización

Actor 2 es el padre de Actor 1 Caso Uso 2 es el padre de Caso Uso 1
Relación de Generalización

Entre Actores
En una empresa comercial, el Supervisor de Ventas realiza
las funciones de cualquier vendedor, pero además
supervisa a otros vendedores.
Muestre los actores y la relación entre ellos
Ejemplos de Generalización

Hacer Pedido
____________
Establecer Prioridad
Seguir Pedido Validar Usuario
Examinar Retina
Comprobar clave
Hacer Pedido
Urgente
«inherits»
«inherits»
«include»
«extends»
«include»
Uc Casos de Uso

Realizar llamada
telefónica
Realizar llamada
nacional
Cliente
Realizar llamada
internacional
(Entre Casos de Uso)

(Entre Casos de Uso)
Realizar orden
Realizar orden
por teléfono
Cliente
Realizar orden
por internet
Usuario

Relación Incluye
 Es una relación de dependencia (para CU)
 Factoriza comportamientos comunes para no repetir la definición
 Los casos de uso “factorizados” pueden ser utilizados por otros
Casos de Uso
 Estereotipado: <<includes>>
 Apunta desde el CU base hacia el
CU incluido
Uc Casos de Uso
Caso de uso
incluido
Caso de Uso Base
«include»

Relación Incluye
 Caso Uso 1 debe también incluir el comportamiento
especificado por el Caso Uso 2
 Cada que se use el caso de uso 1, siempre se utilizará el
caso de uso 2
<<include>>

Ejemplo Relación Incluye
En un sistema de ventas de una Ferretería tenemos los Casos de uso
Registrar Pedido y Consultar Estado de Documento en ambos casos
es necesario Validar Cliente.
Muestre los casos de uso y sus relaciones
Registrar
Pedido
Consultar
Estado Doc
Validar
Cliente
<<include>>
<<include>>

• Venta de productos y
compra de insumos en
un supermercado.
• Las acciones para
“Realizar movimiento
de producto” en
kardex puede
separarse en un caso
de uso
Realizar venta
de producto
Realizar movimiento
de producto
<<include>>
Cajero
Realizar compra
de insumos
Comprador
<<include>>
Ejemplo Relación Incluye

Relación Extiende
 Es una relación de dependencia (para CU)
 Se ejecuta el CU base pero bajo ciertas condiciones
 Estereotipado: <<extend>>
 Apunta desde el CU extendido hacia el
CU base.

Relación Entiende
<<extend>>
 Caso Uso 2 puede ser extendida por el comportamiento
especificado por el Caso Uso 1
 El CU1, será ejecutado cuando al ser ejecutado el CU2, se
den las condiciones que activen el CU1

Ejemplo Relación Entiende
En un sistema de ventas de una Ferretería tenemos el caso de Uso
Enviar Orden y se podrá Enviar Orden Parcial cuando falte algún
producto en sus almacenes.
Muestre los casos de uso y sus relaciones

Desarrollo Aplicaciones RUP UML

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Desarrollo Aplicaciones RUP UML

Similar a Desarrollo Aplicaciones RUP UML (20)

Desarrollo Aplicaciones RUP UML

Notas del editor