• Author / Uploaded
• Alexander Mendoza

• Categories
• Caso de uso
• Ingeniería de software
• Informática
• Tecnología
• Ingeniería de Sistemas

Citation preview

DIAGRAMAS DE CASOS DE USO Los Diagramas de Casos de Uso son utilizados en la fase de Determinación de Requerimientos para especificar requisitos funcionales del software a desarrollar desde la perspectiva del usuario y lo que el sistema ha de hacer para satisfacer las peticiones de estos usuarios. Los diagramas de caso de uso modelan: 1. 2. 3. 4. 5. 6. 7.

Los actores del sistema. Las relaciones entre actores. Los casos de uso. Las relaciones entre casos de uso. Las relaciones de comunicación entre actores y casos de uso. Los límites del sistema. El refinamiento o descomposición de los casos de uso.

Los Diagramas de Caos de Uso presentan la siguiente forma general:

Figura 1. Forma general de un Diagrama de Casos de Uso

Actor (Stakeholder) Es utilizado para representar el rol que objetos o entes externos, de una misma clase, juegan cuando interactúan con el sistema.

Un actor puede ser una persona interesada, un dispositivo u otro sistema con comportamiento. El aspecto clave es que los actores constituyen todo aquello que es externo al sistema que se está desarrollando. No se refiere a un individuo particular, sino a una clase de individuos que tienen un rol común. Representan a entes externos al sistema, que intercambian datos y señales (se comunican) con el sistema. Es un clasificador y no una ocurrencia. Representan papeles ejecutados por personas (o dispositivos) cuando el sistema está en operación. Se representa mediante una figura humana. Esta representación sirve tanto para actores que son personas como para otro tipo de actores. Un actor no es un usuario, para acentuar la diferencia entre un actor y un usuario podemos pensar que un actor es como una clase que se define por la descripción de su comportamiento. Por otro lado, un usuario puede desempeñar varios papeles, es decir, puede actuar como actores diferentes. Existen dos (02) tipos de actores: Actores primarios: • Interactúan para lograr el funcionamiento requerido del sistema a fin de alcanzar el objetivo propuesto. • Trabajan directamente con el software Actores secundarios: • Dan soporte al sistema de tal forma que los actores primarios puedan hacer su trabajo. Por ejemplo el administrador del sistema, que crea los nombres de usuario y claves de acceso. Relaciones entre actores. Se pueden establecer relaciones de generalización entre actores. Un rol general puede ser heredado por uno o más roles específicos. Ejemplo.

Figura 2. Relaciones entre Actores

En este caso, tanto Alumno Nuevo como Alumno Regular desempeñan el rol de Alumnos, sin embargo, se diferencian en que el Alumno Nuevo no puede solicitar constancias de estudios o notas, mientras que el Alumno Regular si puede hacerlo. Casos de Uso. Un caso de uso puede ser entendido como la secuencia de transacciones que se realiza en un diálogo con el sistema, y que se encuentra relacionado con su comportamiento. Cada caso de uso constituye una secuencia completa de mensajes que especifica la secuencia de interacción entre un actor y el sistema. De lo anterior podemos decir que un caso de uso es una secuencia de transacciones relacionadas, ejecutadas por uno o más actores y el sistema en un diálogo determinado. La colección de todos los casos de uso relacionados en un sistema especifica las maneras en que se puede utilizar el sistema. En general para los casos de uso tenemos que: • Expresan una unidad coherente de funcionalidad requerida por el sistema. • Aportan una descripción acerca de cómo el sistema será usado. • El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. • Se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. Relaciones entre Actores y Casos de Uso Los actores se relacionan con los casos de uso mediante asociaciones. Una asociación modela la COMUNICACIÓN bidireccional entre un actor y un caso de uso y puede darse de las siguientes formas: • Envío de señales (Ejemplo, activación del caso de uso)

•

Envío de datos e información.

Esta relación es representada simplemente por una línea recta que se extiende de la figura del actor hacia el ovalo del caso de uso. Relaciones entre Casos de Uso. Los casos de uso se asocian entre si utilizando tres tipos de relaciones: • Relación de Generalización. • Relaciones de Inclusión. • Relaciones de Extensión. Relación de Generalización Una generalización indica que un caso de uso (ovalo) es un caso especial de otro caso, en otros términos, representa una relación padre-hijo, donde el hijo puede ser suplido directamente por el padre en cualquier momento, es decir, que el caso de uso hijo hereda y añade propiedades al caso de uso padre. Esta relación es representado por una línea con flecha que se extiende del caso de uso hijo hacia el caso de uso padre (general). Modela las relaciones en las cuales el comportamiento de un caso de uso general (padre) es heredado por uno o más casos de uso especializados (hijos). Ejemplo:

Figura 3. Relaciones de Generalización

Relación de Inclusión. Una Relación de Inclusión es utilizada para indicar que un caso de uso (ovalo) depende de otro caso de uso para activar su funcionalidad (ejecutarse), dicho

de otra manera, significa que la funcionalidad de determinado caso se requiere para realizar las tareas de otro. Implica OBLIGATORIEDAD del caso de uso de inclusión, es decir, el caso de uso base realizará sus tareas si y sólo si el caso de uso de inclusión realiza las suyas primero. Es representada por una línea punteada con flecha y el comentario que se extiende del caso de uso base hacia el caso de uso de inclusión. Modelan relaciones en las cuales uno o más casos de uso INCLUYEN (usan) el comportamiento de un caso de uso en común. Son utilizados para compartir comportamiento común entre varios casos de uso. Ejemplos:

Figura 4. Relaciones de Inclusión

Relación de Extensión Una extensión representa una variación de un caso de uso a otro, aunque similar a una generalización, una extensión representa una dependencia especifica, mientras una generalización no implica que los casos de uso dependen uno del otro. Esta relación es representada por una línea punteada con flecha y el comentario que se origina del caso de uso base hacia el caso de uso de extensión.

Modelan relaciones en las cuales un caso de uso base incluye el comportamiento de un caso de uso extendido en uno o más puntos de su flujo de eventos. Estos puntos se denominan puntos de extensión y tienen asociada una condición que determina cuando el caso de uso extendido es invocado por el caso de uso base, es decir, el caso de uso extendido se activa cuando se cumple la condición. Se usan también para modelar el comportamiento EXCEPCIONAL del caso de uso base. Ejemplos:

Figura 5. Relaciones de Extensión.

Reglas para elaborar los Diagramas de Caso de Uso. • Cada actor y caso de uso deben tener un nombre único. • Los actores deben tener nombres representativos que indiquen el rol que desempeña el actor al interactuar con el sistema. • Los nombres de un caso de uso deben indicar acción y debe ser claro y conciso. • Los casos de uso de un diagrama deben estar todos a un mismo nivel de abstracción. • Evite el cruce de líneas. • Evite tener demasiados casos de uso en un mismo diagrama. En la medida de lo posible utilice la regla del 7± 2, la cual establece que el número apropiado de casos de uso por diagrama debe estar en el rango 5 a 9. • Evite el uso complejo de relaciones de extensión e inclusión. No más de tres niveles de relaciones consecutivas.

Descripción textual de los Casos de Uso. Cada uno de los casos de uso que aparecen en el Diagrama tiene asociado un flujo de eventos que indica el orden en que sus acciones se ejecutan, este flujo establece los detalles de la comunicación entre el caso de uso y sus actores. Los flujos de eventos se describen separadamente usando DESCRIPCIONES TEXTUALES de casos de uso., las cuales deben comprender: • Flujo de eventos principal (flujo feliz), los cuales muestran la secuencia de mensajes más importantes facilitando la comprensión del caso de uso que está siendo descrito. • Flujo de eventos alternativos, que describen las variantes sobre la secuencia básica de mensajes de un caso de uso y los posibles errores que puedan surgir durante su ejecución. Reglas para la Descripción Textual de los Casos de Uso.

•

1. Narrar el flujo de eventos usando VOZ ACTIVA, en tiempo presente y desde la perspectiva del actor. Evite el uso de voz pasiva. - La clave es introducida por el usuario. - La clave es validada por el sistema. • Prefiera el uso de voz activa - El usuario introduce la clave. - El sistema valida la clave. 2. Exprese cada paso del flujo usando la forma llamada y respuesta, es decir, el texto debe reflejar el hecho de que el actor hace algo y el sistema responde a la solicitud del actor. • El [actor] hace [esto] y el sistema hace [aquello]. 3. El caso de uso que se describe DEBE expresar un solo requisito funcional, aunque pueden haber uno o más requisitos no funcionales o pseudo-requerimientos asociados al requerimiento funcional descrito. 4. Establezca el contexto inicial del actor • Especifique la ubicación del actor en el contexto de la interfaz de usuario del sistema.  Ejemplo: El cliente introduce la clave de acceso en la ventana de acceso al inicio del sistema 5. Asegúrese que el caso de uso produzca un resultado visible y de valor para el actor. 6. Establezca todos los posibles flujos alternativos al flujo principal. La siguiente planilla, no permitirá describir textualmente cada caso de uso.

CASO DE USO: > Actores participantes: > Interesados y Objetivos: > Condiciones de Entrada:

Condiciones de Salida: > Flujo de Eventos Principal (Escenario Principal de éxito):

…

Flujos Alternativos: > Requerimientos Especiales: > Variaciones Tecnológicas: > Frecuencia de Ocurrencia: > Observaciones: >

Figura 6. Plantilla para la Descripción Textual de los Casos de Uso.

Pasos para construir un Diagrama de Casos de Uso. 1. 2. 3. 4.

Identificar los límites del sistema. Identificar los actores. Para cada actor, identificar sus objetivos. Definir casos de uso que satisfagan sus objetivos.

Referencias Bibliográficas Pressman, Roger. Ingeniería de Software. Un enfoque práctico. Sexta Edición. McGrawHill. México. 1997. Schmuller, Joseph. Aprendiendo UML en 24 horas. Prentice Hall. México.

De Amescua Seco, Antonio y otros. Análisis y diseño estructurado y orientado a objetos de sistema informáticos. McGrawHill. Madrid. 2003. http://www.clikear.com/manuales/uml/diagramascasouso.aspx http://www.osmosislatina.com/lenguajes/uml/casos.htm Este material fue recopilado por el Prof. Rafael Matos, para los alumnos del curso de Ingeniería de Software II, de la Universidad Politécnica del Oeste Mariscal Sucre (UPOMS).