Introduccion a UML Wilson Peláez Hernández

Presentación del tema: "Introduccion a UML Wilson Peláez Hernández"— Transcripción de la presentación:

1 Introduccion a UML Wilson Peláez Hernández

2 Introduccion a UML LOS CASOS DE USO

3 Contenido Introducción Antecedentes Los casos de uso
Concepto de Escenario Concepto de Actor Proceso para especificar un caso de uso Busqueda de actores Personal involucrado Especificación de un caso de uso Precondición Postcondición

4 Contenido Secuencia normal Secuencias alternas Otra información
Ejemplo: Sacar Dinero Actividades donde se usa los casos de uso Relación entre los casos de uso Relación de extensión Relación de inclusión Casos de uso abstractos Diagramas de los casos de uso

5 Contenido Notación Elementos de un diagrama
Modularización de los casos de uso Ventajas e los casos de uso Lecturas recomendadas Bibliografia

6 Introduccion a UML Introducción Los casos de uso son una técnica para especificar el comportamiento de un sistema. Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso expresa como alguien accede a este servicio. Los casos de uso ayudan a validar la arquitectura y verificar el sistema Los casos de uso son un mecanismo utilizado para descubrir y registrar los requisitos de una aplicación. Los casos de uso especifican un comportamiento deseado, no imponen como se llevará a cabo ese comportamiento. Un caso de uso representa un requisito funcional del sistema. Un caso de usa realiza cierto trabajo cuyo efecto es tangible. Los casos de uso son un mecanismo ampliamente utilizado para descubrir y registrar los requisitos especialmente funcionales de un sistema

7 Introduccion a UML Antecedentes Ivar Jacobson introdujo la idea de utilizar los casos de uso para describir los requisitos funcionales de un sistema. “Object-Oriented Software Enginieering: A use case driven approach Addison-Wesley” No estableció un formato concreto , ni un proceso detallado. Object-Oriented Software Enginieering: A use case driven approach Addison-Wesley

8 Antecedentes Un de los autores más influyentes hoy en dia en el manejo de los casos de uso es Alistair Cockburn. “Writing Effective Use Cases” Addison –Wessley Estableció la parte de qué son (deberían ser) y como escribirlos.

9 Introduccion a UML Los casos de uso Son requerimientos funcionales que describen de una manera detallada el comportamiento de un sistema con los distintos actores que interactúan con él. Es un documento que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. Un caso de uso capta una funcionalidad visible para el usuario. Describe la secuencia de eventos y acciones que se producen entre un Actor y un Sistema que interactúan para cumplir un objetivo.

10 Los casos de uso Es una descripción de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor. No definen todos los requerimientos, pero representan el hilo conductor que vincula a todos los requerimientos posibles –actuales y futuros- de una aplicación

11 Los casos de uso Una actitud clave en el trabajo con casos de uso es centrarse en la pregunta: “Cómo puedo, utilizando el sistema, proporcionar un valor observable al usuario, o cumplir sus objetivos” El concepto de caso de uso: trabaja con los requisitos centrandose en cómo puede un sistema añadir valor y cumplir los objetivos

12 Utilidad de los casos de uso

13 Introduccion a UML Concepto: Escenario Un escenario es una secuencia específica de acciones e interacciones entre los actores y el sistema objeto de estudio. Es una historia particular del uso de un sistema Escenario principal (caso de éxito – flujo común) Escenarios alternos ( casos de fallo – flujo alterno opcional) Un caso de uso es una colección de escenarios con éxito , considerando opciones alternas y fallos relacionados, que describe a los actores utilizando un sistema para satisfacer un objetivo

14 Escenario Un escenario es una secuencia de pasos, que puede ser de tres tipos: Una interacción entre actores Una válidación(normalmente a cargo del sistema) Un cambio de estado realizado por el sistema

15 Introduccion a UML Concepto : Actor El actor es una entidad externa del sistema que de alguna manera participa en la historia del caso de uso. Estimula al sistema con eventos de entrada o recibe algo de él. Un actor representa un “rol” en el sistema. Se pueden distinguir tres tipos de actores básicos: Actor Silencioso (pasivo) Actor Principal Actor Soporte Actor Silencioso: ES aquel que tiene un interés personal en el comportamiento del caso de uso, incluso si ninguna interactua directamente con el sistema. Acor Principal: Es aquel que invoca el sistema para lograr cierto objetivo. Actor de Soporte: Es aquel que proporciona un servicio al sistema.

16 Proceso para especificar un CU

17 Búsqueda de actores Quién esta interesado en un requerimiento concreto? Quién será beneficiario de la nueva funcionalidad? Quien proveerá, usará o eliminará la información? Qué usuarios actuarán con diferentes roles? Diferentes usuarios actuarán con el mismo rol? El sistema interactuará con otros sistemas?

18 Personal involucrado [Cockburn]:”En el caso de uso no sólo se debe identificar el actor principal, sino “otros” actores involucrados”. Esta lista sugiere y delimita que es lo que debe hacer el sistema, y a quién involucra. El sistema funciona siguiendo un contrato entre el personal involucrado,donde los casos de uso detallan la parte de comportamiento del sistema.

19 Especificación de un caso de uso
Introduccion a UML Especificación de un caso de uso Los casos de uso deben tener. Identificador Nombre Versión Autores Fuentes Breve descripción Importancia Dependencia Comentarios El nombre debe coincidir con el objetivo del actor principal.

20 Precondición Establece lo que siempre debe cumplirse antes de comenzar un escenario en el caso de uso. Condiciones que describen en que situación se debe encontrar el sistema y su entorno para poder comenzar el caso de uso. Las precondiciones no se prueban en el caso de uso. Un precondición, generalmente, implica otro caso de uso que se ha completado con éxito.

21 Postcondición Establece que debe cumplirse cuando el caso de uso se completa. Condiciones que describen en que situación debe quedar el sistema y su entorno una vez el caso de uso haya finalizado. La postcondición debería satisfacer las necesidades de todo el personal involucrado.

22 Secuencia normal Denominado tambien flujo básico o escenario principal. Secuencia de pasos (interacciones) entre los actores y el sistema que describen el camino de éxito típico que satisface los intereses del personal involucrado. Se recomienda que no incluya ninguna condición o bifurcación.

23 Secuencias alternas Indican todos los otros posibles escenarios tanto de éxito como de fracaso que se pueden dar en el proceso que cubre el caso de uso. Consideran las situaciones anómalas o de error que se pueden dar en el escenario principal. Un escenario alterno, esta formado por tres partes básicamente: Condición:Expresa la acción que provoca la situación excepcional Manejo:Describe la respuesta a la situación de excepción Terminación de la excepción: Indica si después del manejo de la excepción, el caso de uso continua o se cancela.

24 Otra información Frecuencia de realización:Indica la frecuencia con la que se espera se realice el caso de uso. Ayuda a identificar los casos de uso críticos. Realizaciones simultáneas: Indica cuantas instancias de casos de uso debe ser capaz de realizar el sistema en forma simultánea. Ayuda a identificar procesos que podrían afectar el rendimiento. Criticidad: Para un paso especifico o para todo el caso de uso, indica el tiempo máximo que puede tardar el sistema en completarla. Requisitos especiales

25 Ejemplo

26 Ejemplo

27 Actividades en donde se usan los casos de uso

28 Actividades en donde se usan los casos de uso

29 Actividades en donde se usan los casos de uso

30 Formato(plantillas) de los casos de uso
Introduccion a UML Formato(plantillas) de los casos de uso Los casos de uso se documentan con texto informal. Las plantillas permiten describir los casos de uso de una manera homogénea, ordenada y estructurada. Pueden expresarse con diferentes grados de detalle, dependiendo de este se pueden clasificar: Formato de alto nivel (breve) Formato expandido (completo) Existen varias plantillas para los caos de uso ,

31 Formato de alto nivel Describe un proceso muy brevemente.
Caso de uso: Nombre del caso de uso Actores: Lista de actores que participan Tipo: (pirmario-secundario-opcional) Descripción: bla bla bla bla

32 Ejemplo formato de alto nivel

33 Formato detallado Describe un proceso más en detalle, cuenta con una sección destinada al curso normal de los eventos, que los describe paso a paso. Incluye otras alternativas, puede especificar los errores o excepciones que provienen de los requisitos del usuario

34 Modelo Formato Detallado

35 Modelo Formato Detallado

36 Otro “estilo” del formato

37 Otro “estilo” de formato

38 Plantillas para casos de uso - Ejemplos

39 Relación entre los casos de uso
Dentro de la secuencia normal o alterna de un caso de uso se puede presentar la realización de otro caso de uso Se especifican dos tipos de relación: De extensión De inclusión Se establecen una relación de generalización Cuando un caso de uso comprende un grupo “comun” de casos de uso

40 Relaciones de extensión
Se utiliza para modelar la parte de un caso de uso que el usuario puede ver como opcional del sistema También se puede utilizar para modelar un subflujo separado que se ejecuta sólo bajo ciertas condiciones. Son un caso de uso en sí mismas. No necesariamente provienen de un error o excepción.

41 Relaciones de uso Una relación de inclusión significa que un caso de uso “base” incorpora explicitamente el comportamiento de otro caso de uso. Los casos “usados” son casos de uso El caso es usado siempre que el caso que lo usa es ejecutado.

42 Caso de uso “Abstracto”
Cuando se identifique una subsecuencia de pasos común a varios casos de uso y con la entidad suficiente, se puede extraer y considerar un caso de uso para ser extendido o incluido por otros casos de uso. Se considera abtracto porque no puede realizarce por sí mismo, sólo puede realizarce como parte de otro.

43 Diagrama de Casos de Uso
Los diagramas de casos de uso tienen por objeto permitir conocer rápidamente los actores externos del sistema, y las formas básicas en que lo utilizan. Explican un conjunto de casos de uso, normalmente agrupados por funcionalidad. Representan la relación entre actores y casos de uso. Describen la interacción de los actores con el sistema

44 Diagrama de Casos de Uso
Muestran la granularidad del sistema en piezas de funcionalidad reutilizables Muestran la interacción de los Actores con la funcionalidad del Sistema Organizan visualmente los requerimientos del usuario Permiten certificar contractualmente la funcionalidad Formalizan el mapa de procesos de negocio

45 Notación Procesar préstamo Caso de uso (Ovalo) Actores (Stick-Man)
Profesor Estudiante

46 Elementos de un diagrama de caso de uso
Un diagrama de casos de uso muestra un conjunto de casos de uso, actores y relaciones.

47 Modularización casos de uso
Los casos de uso se pueden organizar especificando relaciones de generalización, inclusión, y extensión entre ellos. Esta organización evita la redundancia y facilita su comprensión Permiten determinar comportamientos comunes, así como variantes.

48 Modularización casos de uso

49 Relacion de uso - extensión

50 Relaciones de uso - generalización

51 Ventajas de los Casos de Uso
Lenguaje de comunicación entre usuarios y desarrolladores Comprensión detallada de la funcionalidad del Sistema Acotación precisa de las habilitaciones de los usuarios Trazabilidad desde los requerimientos al código ejecutable

52 Ventajas de los Casos de Uso
Gestión de riesgo para gobernar la complejidad de un sistema Planificación de iteraciones para su implementación Estimación precisa del esfuerzo para su implementación Documentación orientada al usuario: Manual de Procedimientos

53 Conclusiones Trabajar con los casos de uso significa escribir texto, por tanto los diagramas y sus relaciones son secundarios. Los casos NO describen el funcionamiento interno del sistema, indican que debe hacer el sistema y no el como debe hacerlo.

54 Lecturas Recomendadas

55 Bibliografia El Lenguaje Unificado de Modelado UML –G. Booch- J. Rumbauhugh – I Jacobson. “UML Y PATRONES Introducción al Análisis y Diseño Orientado a Objetos” Craig Larman Universidad de Sevilla. Departamento de Lenguajes y Sistemas Informáticos.”Documentación Casos de Uso”

56 Fin