IESTP "Víctor Raúl Haya de la Torre"

1. Ing. CIP Fabián Silva Alvarado
DEL MODELO DE NEGOCIOS
AL MODELO DEL SISTEMA
TEMA:
Ing. CIP Jorge Pariasca León
Jpariasca.blogspot.pe

2. Introducción
Una vez que hemos logrado interpretar la forma de trabajo de
la empresa, nos dedicaremos a tratar de automatizar la mayor
cantidad de procesos posibles, para ello tengamos en cuenta lo
siguiente:

3. Funcionalidad del Sistema:
Use Case Diagram.
• La vista de casos de uso captura el comportamiento de un
sistema, de un subsistema, o de una clase, tal como se
muestra a un usuario exterior.
• Reparte la funcionalidad del sistema en transacciones
significativas para los actores-usuarios ideales de un
sistema.
• Las piezas de funcionalidad interactiva se llaman casos de
uso.
• Un caso de uso describe una interacción con los actores
como secuencia de mensajes entre el sistema y uno o más
actores.

4. Use case Diagram
El término actor incluye a los seres humanos, así como a
otros sistemas informáticos y procesos.

5. Diagrama de Casos de Uso

6. • Concebidos por I. Jacobson - Objectory/OOSE
(Jacobson, 92)
• Presentes en casi cualquier nuevo método de
desarrollo de software.
• Incluidos en UML y Métrica 3.
Actor A
Caso de Uso A
Diagrama de Casos de Uso

7. • Proporciona credibilidad en una etapa inicial del desarrollo
del sistema
• Asegura una comprensión mutua de los requisitos
• Quién interactuará con el sistema y qué deberá hacer el
sistema
• Qué interfaz deberá tener el sistema.
• Que se hayan capturado todos los requerimientos
• Que los desarrolladores hayan entendido los requerimientos
Diagramas de Casos de Uso
Usados Para Verificar
Usados Para Comunicarse con el Usuario Final y
el Experto de Dominio
Usados Para Identificar

8. • Los Casos de Uso (Ivar Jacobson) describen bajo la
forma de acciones y reacciones el comportamiento
de un sistema desde el p.d.v. del usuario
• Permiten definir los límites del sistema y las
relaciones entre el sistema y el entorno
• Los Casos de Uso son descripciones de la
funcionalidad del sistema independientes de la
implementación
• Comparación con respecto a los Diagramas de Flujo
de Datos del Enfoque Estructurado
… Casos de uso

9. • Ejemplo:
Actor A
Caso de Uso A
Actor B
Caso de Uso B
… Casos de Uso

10. • Roles que presentan los usuarios cuando
interactúan con el sistema.
• Un actor es una idealización de una persona externa, de
un proceso, o de una cosa que interactúa con un
sistema, un subsistema, o una clase.
• Un actor caracteriza las interacciones que los usuarios
exteriores pueden tener con el sistema.
Casos de uso : Actores
Actor A
Caso de Uso A

11. • La misma persona física puede interpretar varios papeles
como actores distintos (generalización)
• El nombre del actor describe el papel desempeñado.
• Se pueden clasificar en:
 Principales: roles que usan el sistema
 Secundarios: roles alternos o administran el
sistema.
 Material externo: dispositivos materiales
imprescindibles que forman parte del ámbito de la
aplicación y deben ser utilizados
 Otros sistemas: sistemas con los que el sistema
interactúa
… Casos de uso : Actores

12. … Casos de uso : Actores
• Inician la ejecución de los casos de uso.
• No tienen que ser personas necesariamente.
• Un mismo rol puede ser jugado por más de un
usuario.
• Un usuario puede jugar más de un rol.
Actor A
Caso de Uso A

13. … Casos de uso : Actores
• Generalización de actores, se pueden generalizar roles
de actores mediante una relacion de generalización, Ejm.
Administración
Contador Administrador
Terminalista
Cajero Ventanilla

14. ¿Cómo identificar Actores?
Ing. CIP. Ronald Flores Flores

15. • 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
Casos de uso desde UML

16. CASO DE USO: Relaciones
Un caso de uso es
una descripción
lógica de una
parte de
funcionalidad del
sistema.
Un caso de uso
puede participar
en varias
relaciones con
otros casos de
uso, además de
poderse asociar
con actores.

17. • UML define cuatro tipos de relación en los
Diagramas de Casos de Uso:
 Comunicación
Actor
Caso de Uso
Casos de uso : Relaciones

18.  Ejemplo: Comunicacion
Casos de uso : Relaciones

19.  Inclusión : una instancia del Caso de Uso
origen incluye también el comportamiento
descrito por el Caso de Uso destino
<<include>> reemplazó al denominado <<uses>>
Caso de Uso Origen Caso de Uso Destino
<<include>>
Casos de uso : Relaciones

20.  Ejemplo <<include>>
Casos de uso : Relaciones

21.  Ejemplo <<include>>:
Casos de uso : Relaciones

22.  Extensión : el Caso de Uso origen extiende el
comportamiento del Caso de Uso destino
Caso de Uso Origen Caso de Uso Destino
<<extend>>
Casos de uso : Relaciones

23. Solicitar Nueva Tarjeta
Cliente
Solicitar Préstamo
<<extend>>
[Tarjeta Caducada]
 Ejemplo <<extend>>:
Casos de uso : Relaciones

24.  Ejemplo <<include>> y <<extend>>:
Identificación
Transferencia en Internet
Cliente
Transferencia
<<include>>
<<extend>>
Casos de uso : Relaciones

25.  Generalización: el Caso de Uso origen hereda
la especificación del Caso de Uso destino y
posiblemente la modifica y/o amplía, aunque
este nos sea muy aplicable
Caso de Uso Hijo Caso de Uso Padre
Casos de uso : Relaciones

26.  Ejemplo Generalización:
Casos de uso : Relaciones

27. Diagramas de Casos de Uso: Ejemplo
Caso de Uso
Sistema de Venta
Genera VentaVendedor
Consulta de Producto
Informe de Venta
Administrador

28. Diagramas de Casos de Uso: Ejemplo
Vendedor
(from Use Case View)
Genera Venta
(from Use Case View)
Acepta o cancela consulta
Vista e Impresión del comprobante
Definir Tipo de comprobante
Verifica Cliente
Ingresa o retira Producto
Crear Crédito Número de cuotas y monto de
pago
<<extend>>
<<include>>
<<include>>
<<include>>
<<extend>>
<<extend>>
<<include>>

29.  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

30.  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?
Casos de uso : Construcción

31.  Cuando un modelo de casos de uso se
completa entonces dicho modelo es
presentado y discutido con usuarios y
clientes
 Los usuarios deben validar que el modelo
encaja perfectamente en sus necesidades
y que les ofrece la funcionalidad deseada
Casos de uso : Construcción

32. Casos de uso : Test
 Los casos de uso permiten realizar dos tipos de test:
verificación y validación
 Verificar significa confirmar que el sistema se desarrolla
correctamente
 Validar asegura que el sistema bajo desarrollo es el que el
usuario realmente quiere

33. ¿Como identificar Casos de Uso?
Ing. CIP. Ronald Flores Flores

35. Ventajas de los Casos de Uso
1. Lenguaje de comunicación entre usuarios y desarrolladores.
2. Comprensión detallada de la funcionalidad del sistema.
3. Acotación precisa de las habilidades de los usuarios.
4. Gestión de riesgo más eficiente para gobernar la complejidad.
5. Estimación más exacta para determinar tiempo, recursos y
prioridades en la dosificación de esfuerzo de desarrollo.
6. Mayor control para mantener las sucesivas revisiones de los
programas.
7. Certificación contractual cliente-desarrollador.
8. Documentación orientada al usuario: help, manual de
procedimientos, reglas del negocio.
9. Documentación orientada al administrador del sistema:
soporte de mantenimiento.

36. Conclusión
¿Qué se considera un actor?
 Podemos preguntarnos
¿Porqué se construye el sistema?
 Los actores “ganan valor” con la ejecución
del caso de uso (actor primario del caso de
uso)
 O pueden sólo “participar” en él (actores
secundarios del caso de uso)

37. Conclusión
¿Casos de Uso o funciones?
 Capturan una función visible para el usuario.
 Consiguen un objetivo para el usuario del sistema.
 Caso de uso : Breve descripción en lenguaje natural

38. Los Casos de Uso son una idea maravillosa
que ha sido generalmente complicada. El
verdadero truco para los Casos de Uso es
mantenerlos simples.
Rober C. Martin.

40. Rational Rose y su Organización

41. Rational Rose y su Organización
La Vista de casos de uso
La Vista Lógica
La vista de componentes
La vista del Deployment

42. La Vista de casos de uso (USE
CASE)
 La Vista USE CASE hace posible la comprensión y
usabilidad del sistema.
 Esta vista muestra a los actores y casos de uso con sus
interacciones.
 Los diagramas en esta vista son los DIAGRAMAS DE
CASOS DE USO, DIAGRAMAS DE SECUENCIA Y LOS
DIAGRAMAS DE COLABORACION.

43. La Vista Lógica
 La vista lógica del sistema nos permite mostrar
los requerimientos funcionales del sistema.
 Esta vista muestra las clases y sus relaciones
estáticas y establece la naturaleza dinámica de
las clases.
 Los diagramas en esta vista son DIAGRAMAS DE
CLASE Y DIAGRAMAS DE ACTIVIDAD Y ESTADO.

44. La vista de componentes
 Esta vista muestra la organización del software del
sistema.
 Contiene información acerca del software los ejecutables
y los componentes de librerías para el sistema.
 Contiene los DIAGRAMAS DE COMPONENTES.

45. La vista del Deployment
 Esta vista direcciona la configuración de los nodos de
procesamiento run -time y los componentes, procesos y
objetos incluidos en ellos.
 Esta vista contiene solamente el DIAGRAMA DE
DEPLOYMENT.

47. PREGUNTAS