sesion 5 - diagramas de caso de uso

1

Sesión 5 : Análisis con Casos de Uso

Ing. Luis Piedra Rubio

[email protected]

[email protected]

2

Sesión 5Ingeniería de SoftwareEn esta Sesión :

Contenido de la Sesión

Modelo de Caso de Uso.

Relaciones entre Casos de Uso.

Reconocer un Caso de uso con una documentación Casos de Uso

Actividades

• Modelo de Caso de Uso.• Relaciones entre Casos de Uso.• Reconocer un Caso de uso con

una documentación Casos de Uso

3

Sesión 5Ingeniería de Software

Qué es un Qué es un Modelo de Casos de UsoModelo de Casos de Uso??





Actividades

4


1.- Modelo de Casos de Uso

Recientemente adquirí una máquina de fax. Cuando fui a comprarla, en un almacén de venta de equipo de equipo para oficinas, encontré una enorme gama de opciones. Cómo hice para decidirme por una en particular? Me pregunté exactamente qué es lo que deseaba hacer con una maquina fax. Qué características deseaba? Cuáles funciones necesitaba que tuviera? Deseaba utilizar papel como digitador? Tendría que enviar faxes a tal velocidad que necesitara una función de marcado rápido? Querría utilizar la máquina de fax para diferenciar entre una llamada telefónica y un fax entrante?





Actividades

5



• Todos seguimos un procedimiento como éste cuando realizamos una compra que no sea impulsiva.

• Lo que hacemos es seguir un tipo de análisis del caso de uso; nos preguntamos cómo utilizaremos el producto o sistema que queremos comprar, de modo que podamos obtener algo que cumpla con nuestra necesidades.

• Lo importante es saber cuáles son esos requerimientos.





Actividades

6



• Imaginese al caso de uso como una colección de situaciones respecto al uso de un sistema.

• Cada escenario describe una secuencia de eventos.

• Cada secuencia se inicia por una persona, otro sistema, una parte del hardware o por el paso del tiempo.

• A las entidades que inician secuencias se les conoce como actores. El resultado de la secuencia debe ser algo utilizable ya sea por el actor que la inició o por otro actor.

Abstraerse: Contenido de la Sesión




Actividades

7



El caso de usocaso de uso es una excelente herramienta para estimular a que los usuarios potenciales hablen, de un sistema, desde sus propios puntos de vista





Actividades

8



El propósito primario del modelo Caso de uso es

comunicar las funciones y el comportamiento del

sistema al cliente o al usuario final.





Actividades

9



Los casos usos son usados para:

Comunicarse con el usuario final y el experto del dominio:

•Proporciona credibilidad en una etapa inicial del desarrollo del sistema•Asegura una comprensión mutua de los requisitos





Actividades

10



Los casos usos son usados para:

Identificar:•Quién interactuará con el sistema y qué deberá hacer el sistema•Qué interfaz deberá tener el sistema

Verificar:•Que se capturan todos los requisitos•Que los desarrolladores hayan entendido los requisitos





Actividades

11



El modelo de los Casos de Uso comprende:Casos de usoLos actoresEl sistema





Actividades

12


Casos de Uso.

Componentes del Modelo de Caso de Uso


Es una imagen de una funcionalidad del sistema, la cual es disparada en respuesta de la estimulación de una actor externo.





Actividades

13


Casos de Uso.



Modela un diálogo entre los actores y el sistemaEs iniciado por un actor para invocar una cierta funcionalidad en el sistemaEs un flujo de eventos completos y significativosTomados al mismo tiempo, todos los casos de uso constituyen todas las formas posibles de ocupar el sistema





Actividades

14


Actor:



Un actor es un agente, alguien o algo que solicita un servicio al sistema o actúa como catalizador para que ocurra algo





Actividades

15


Actor:



Los actores no son parte del sistema, ellos representan roles que un usuario del sistema puede desempeñar.Un actor puede intercambiar activamente la información con el sistema. Un actor puede ser un recipiente pasivo de la información. Un actor puede representar a un humano, una máquina u otro sistema





Actividades

16

Sesión 5Ingeniería de SoftwareUtilidad del Modelo de Casos de Uso


Los diagramas de casos de uso se emplean para modelar la vista de casos de uso estática de un sistema. Esta vista cubre el comportamiento del sistema (los servicios visibles externamente que proporciona el sistema en el contexto de su entorno).





Actividades

17

Sesión 5Ingeniería de SoftwareEjemplo: Modelo de Casos de Uso


Verificar Situación

Vendedor

Realizar Venta

Secretaria

Preparar Catálogo

Supervisor

Cliente

Establecer Crédito





Actividades

18

Sesión 5Ingeniería de SoftwareUtilidad del Modelo de Casos de Uso


Normalmente se emplearán los diagramas de casos de uso en una de las formas siguientes:

Para modelar el contexto de un sistema. Implica dibujar una línea alrededor de todo el sistema y asegurar qué actores quedan fuera del sistema e interactúan con él

Para modelar los requisitos de un sistema . Implica especificar qué debería hacer el sistema (desde un punto de vista externo), independientemente de cómo se haga. Aquí se emplearán los diagramas de casos de uso, para especificar el comportamiento deseado del sistema.





Actividades

19

Sesión 5Ingeniería de SoftwareModelado del contexto de un sistema


Dado un sistema, algunos elementos se encuentran dentro de él y otros fuera. Los elementos de un sistema son responsables de llevar a cabo el comportamiento que esperan los elementos externos. Todos estos elementos externos que interactúan con el sistema constituyen su contexto. Este contexto define el entorno en el que reside el sistema.





Actividades

20


Modelado del contexto de un sistema


La decisión sobre qué incluir como actores es importante, porque al hacer eso se especifica un tipo de cosas que interactúan con el sistema. La decisión sobre que no incluir es igualmente importante, porque restringe el entorno para que sólo incluya aquellos actores necesarios en la vida del sistema.





Actividades

21




Para modelar el contexto de un sistema es necesario:

Identificar los actores en torno al sistema.Organizar los actores similares en jerarquías de generalización / especialización.Proporcionar un estereotipo para cada uno de esos actores, si así se ayuda a entender el sistema.Introducir esos actores en un diagrama de casos de uso y especificar las vías de comunicación de cada actor con cada uno de los casos de uso del sistema.





Actividades

22




Ejemplo: Contexto de un sistema de validación de tarjetas de crédito.





Actividades

23


Modelado de los requisitos de un sistema


Al construir un sistema, es importante que al comenzar exista un acuerdo sobre qué debería hacer el sistema, aunque, con toda seguridad, la comprensión de los requisitos evolucionará conforme se vaya implementando el sistema de manera iterativa e incremental.





Actividades

24




Cuando se enuncian los requisitos de un sistema se está estableciendo un contrato entre los elementos externos al sistema y el propio sistema, que establece lo que se espera que haga el sistema. La mayoría de las veces no importa cómo lo hace, sólo importa que hace.





Actividades

25




Los requisitos se pueden expresar de varias formas, desde texto sin estructurar hasta expresiones en lenguaje formal, y en cualquier otra forma intermedia. La mayoría de los requisitos funcionales de un sistema, si no todos, se pueden expresar con casos de uso, y los diagramas de casos de uso de UML son fundamentales para manejar esos requisitos.





Actividades

26

Sesión 5Ingeniería de SoftwareModelado de los requisitos de un sistema


Para modelar los requisitos de un sistema es importante

Establecer el contexto del sistema, identificando los actores a su alrededor.Considerar el comportamiento que cada actor requiere del sistema.Nombrar esos comportamientos comunes como casos de uso.Factorizar el comportamiento común en nuevos casos de uso que puedan ser utilizados por otros.Organizar esos casos de uso con notas que enuncien los requisitos no funcionales; puede que haya que asociar varias de esas notas al sistema global.





Actividades

27

Sesión 5Ingeniería de SoftwareModelado de los requisitos de un sistema


Aunque en el siguiente ejemplo se omite las relaciones entre los actores y los casos de uso, añade casos de uso adicionales que son invisibles para el cliente normal, aunque son comportamientos fundamentales del sistema.





Actividades

28

Sesión 5Ingeniería de SoftwareIdentificación, definición de actores del sistema

y sus relaciones


El actor representa un rol, no es un usuario individual del sistema. Los actores tienen importancia particular cuando se configura el sistema para usuarios diferentes.

Encontrando Actores Contenido de la Sesión




Actividades

29


y sus relaciones


Un actor puede:Solamente introducir información al sistemaSolamente recibir información del sistemaIntroducir y recibir información hacia y del sistema.





Actividades

30

Sesión 5Ingeniería de SoftwareIdentificación, definición de actores del sistema y

sus relaciones


La misma persona física puede interpretar varios papeles como actores distintos. El nombre del actor describe el papel desempeñado. La determinación de los actores permite delimitar el alcance del sistema de manera progresiva .





Actividades

31


Identificación, definición de actores del sistema y sus relaciones






Actividades

32


y sus relaciones


Categorías de 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 utilizados.Otros sistemas: Sistemas con los que el sistema interactúa, tras localizar los actores, procede a describirlos.





Actividades

33


y sus relaciones


Relaciones entre actores Contenido de la Sesión




Actividades

34


y sus relaciones


Documentación de los actores

Una breve descripción de cada actor debe ser añadida al modelo. La descripción debería identificar al rol que el actor juega en su interacción con el sistema.

Por ejemplo si se identificó un actor que se llama Cliente. Una descripción de tal actor sería:

Un cliente es aquella persona que adquiere un producto en la compañía.





Actividades

35


y sus relaciones


Preguntas útiles ¿Quién está interesado en cierto requisito?¿Dónde en la organización se utiliza el sistema?¿Quién proveerá, utilizará y eliminará del sistema esta información?¿Quién utilizará esta función?¿Quién le dará soporte y mantenimiento al sistema?¿Usa el sistema un recurso externo?¿Qué actores necesita el caso de uso?¿Un actor desempeña varios roles?





Actividades

36

Sesión 5Ingeniería de SoftwareIdentificación y fuentes de Información para

Casos de uso


Encontrando Casos de Uso ¿Cuáles son las tareas de este actor?¿El actor, creará, guardará, cambiará, eliminará o leerá la información en el sistema?¿Cuál caso de uso creará, guardará, cambiará, eliminará o leerá esta información?¿Necesitará el actor informar al sistema sobre cambios externos e imprevistos? ¿Es necesario que el actor esté informado sobre ciertas ocurrencias en el sistema?¿Le proporciona una correcta secuencia el sistema a las tareas?¿Cuáles casos de uso le darán soporte y mantenimiento al sistema?¿Pueden todos los requerimientos funcionales ser realizados por los casos de uso?





Actividades

37

Sesión 5Ingeniería de SoftwareIdentificación y fuentes de Información

para Casos de uso


Fuentes de Información para Casos de Uso

Especificaciones del sistema / Manifestación del problemaLiteratura relevante del dominio Entrevistas con expertos del dominioConocimiento personal del dominioLegado del sistema





Actividades

38


2.- 2.- Relaciones entre Relaciones entre Casos de uso y Casos de uso y

ActoresActores





Actividades

39


2.- Relaciones entre Casos de Uso y Actores:

La participación de un actor en el Use Case.

Por ejemplo, las instancias de los caos de uso que se comunican entre si. Esta es la única relación entre los actores y los Use cases.

Asociación: Contenido de la Sesión




Actividades

40



Uses: (<<Uses>>)

Se establece cuando la utilización o asociación con el segundo caso de uso necesita ocurrir obligatoriamente dentro de su flujo básico.





Actividades

41


2.- Relaciones entre Casos de Uso y Actores:Extension: <<extends>>

Se establece cuando la utilización o asociación con el segundo caso de uso ocurre opcionalmente bajo la ocurrencia solo de ciertas condiciones





Actividades

42



Use relaciones extends cuando escriba una variación de una conducta normal (casos especiales, condiciones de borde, otras utilizaciones).Use relaciones uses para evitar repeticiones de casos de uso ya realizados (conjuntos de conductas más pequeñas o generalizaciones).

Tips en las relaciones entre Casos de Uso Contenido de la Sesión




Actividades

43


3.- Detallar un caso de 3.- Detallar un caso de uso con una uso con una

Documentación Documentación Casos de UsoCasos de Uso





Actividades

44


Se toma como punto de partida la descripción elaborada en la actividad “Encontrar Actores y Casos de Uso.

El objetivo principal de detallar un CU es describir completamente su flujo de sucesos, incluyendo cómo comienza, termina e interactúa con los actores.

3.- Documentación de Casos de Uso





Actividades

45


Para detallar el flujo se necesitará las descripciones textuales y diagramas.






Actividades

46

Sesión 5Ingeniería de SoftwareFlujo típico de acciones a través de un Caso de Uso


La instancia del CU se inicia y pasa a un estado de comienzo.

El caso de uso es invocado por un mensaje de un actor.

Transita a otro estado realizando una secuencia de acciones (cálculos, selección de camino, mensajes de salida, etc.)

Queda a la espera (en el nuevo estado) de otro mensaje externo.

Es invocado (otra vez) por un nuevo mensaje ......

Termina la instancia del CU





Actividades

47


Flujo típico de acciones a través de un Caso de Uso


El camino elegido como básico debe ser el camino normal, el más habitual u obvio para el actor.

Tanto el camino básico como los alternativos deben describirse textualmente en una sección de la Descripción del CU.





Actividades

48


Flujo típico de acciones a través de un Caso de Uso


Los caminos alternativos, desviaciones o excepciones pueden ocurrir porque:

El actor puede elegir entre diferentes caminos. Si está implicado más de un actor, las acciones

de uno de ellos pueden influenciar el camino de las acciones de los otros.

El sistema puede detectar entradas erróneas de los actores:

Alguna falla en el funcionamiento de alguno de los recursos del sistema, por lo que éste no puede efectuar su trabajo de modo adecuado.





Actividades

49

Sesión 5Ingeniería de SoftwarePre y post condiciones


Son estados del sistema de los que el usuario puede darse cuenta.

Una precondición es una restricción para que el CU comience, no es el evento inicial.

Una precondición de un CU no se aplica a subflujos individuales, sino a todo el CU





Actividades

50

Sesión 5Ingeniería de SoftwareAtributos de los Casos de Uso


Representan los valores que una instancia de CU utiliza y manipula

Los atributos de los CU pueden usarse como base para encontrar clases y atributos en las fases de análisis y diseño

Ejemplo:Los atributos del CU Activar Proyectos pueden ser:El id del proyecto, El presupuesto asignado,Las fechas de inicio y fin planificadas





Actividades

51



Escriba oraciones cortas, concisas Evite adverbios como muy, casi, mejor que,

bastante, etc. Emplee correctamente los signos de puntuación. Evite usar oraciones compuestas. Describa el flujo, no sólo el propósito del CU. Describa sólo el flujo del CU, evite mencionar

eventos que corresponden a otros CU que pudieran ejecutarse en paralelo.

No mencione actores que no intervienen en el CU Si el orden de los eventos no es fijo, esta

característica debe ser explícita. Emplee lenguaje simple y claro.

Tips para detallar los Casos de Uso Contenido de la Sesión




Actividades

52



¿Quién Lee la Documentación de Casos de Uso?

Clientes, aprueban lo que debe hacer el sistemaUsuarios, obtienen comprensión del sistema Desarrolladores del Sistema, documentan el comportamiento del sistemaRevisores, examinan el flujo de eventosAnalistas del Sistema (Diseñadores), proveen la base para un análisis y diseño“Probador” del Sistema, usado como base para casos de pruebaLíder de Proyecto, provee entradas para el planeamiento de proyectosEscritor Técnico, base para escribir la guía del usuario





Actividades

53


Actividad:Plantilla para un documento de caso de uso





Actividades

54


Actividad:Creación Diagrama de Casos de Uso





Actividades

55


Representar el diagrama de casos de uso para un sistema PAC (Pago Automático de Cuentas)

Actividad: Contenido de la Sesión




Actividades

56


Ejemplo: Desarrollo de un diagrama de Casos de Uso

Veamos un ejemplo sencillo:

Representar el diagrama de casos de uso para un sistema PAC (Pago Automático de Cuentas) de una nueva empresa Internet llamada Págate.com.pe





Actividades

57



En la primera entrevista con ejecutivos de la empresa podemos obtener:

Los clientes que utilizan el sistema son usuarios registrados.Si un cliente desea ser usuario debe registrarse en nuestro sistema ingresando sus datos personales.Para el pago de una cuenta, se consulta el saldo al sistema de consulta de Transbank.





Actividades

58



En estas pocas líneas (que en general no son más de 5 a 10 minutos de conversación) ya podemos identificar a los actores y algunos de los objetivos. Veamos:

Usuario: Persona realCliente: Persona real. Puede ser el mismo usuario (ES un usuario)Transbank: Sistema Informático de Consulta de Saldos (SICS)

Actores





Actividades

59



Todos los casos de uso tratan de funcionalidades requeridas externamente (no internamente).

Si el SICS necesita de una transacción para procesar el cargo a la cuenta corriente o a la tarjeta de crédito, ese se convierte en un requerimiento que se debe satisfacer.Veamos como identificar los casos de uso del ejemplo de Págate.com.pe. Tomando el mismo enunciado, listemos primero los objetivos de usuario por actor a satisfacer:

Casos de Uso





Actividades

60



Usuario: Registra como Cliente

Cliente: Administra de Cuentas Administra Medios de Pagos Paga de Cuentas

Transbank: Realiza Transferencia

Casos de Uso

Con esto ya conocemos los objetivos de los actores





Actividades

61



Casos de Uso: dibujemos nuestro primer caso de uso:

Al ver este diagrama, es claro notar que, al mostrárselo a un no especialista informático se entienden las interacciones que tendrá el sistema con el exterior, aún cuando no posea ninguna especificación de software detrás.





Actividades

62



Casos de Uso

Pero ¿satisface lo que el software realmente hará al final?.

La respuesta es que tal vez no, porque es solo una comprensión de los objetivos que se deben cumplir para que el software sea exitoso.

Tal vez existan muchos casos de uso que no hemos considerado, y que cumplirán un rol importante, pero eso lo iremos refinando a través del proceso de desarrollo.





Actividades

63



Uses y Extends:

En nuestro ejemplo, podemos identificar estas relaciones. Contenido de la Sesión




Actividades

64



En el caso de un extend podemos ver la situación cuando Transbank rechaza la transacción por falta de fondos.

En tanto, la relación de use aparece cuando para realizar un pago, debe ingresarse un medio de pago y además realizar la transacción con Transbank

Uses y Extends:





Actividades

65


Resumen

Los casos de Uso ayudan a definir la descripción de requerimientos funcionales en términos de requerimientos facilitando su comprensión por parte de los usuarios. Una vez concluida la fase de encontrar los Casos de Uso del Sistema, se inicia la fase de Análisis del Dominio.





Actividades

66


Caso Práctico : Reservas de HotelDesarrollar el Diagrama de Caso de Uso de

Negocio

Actividad en Clase No. 4 Contenido de la Sesión




Actividades

sesion 5 - diagramas de caso de uso

Documents