2013

Modelo de Casos de Uso

Ingeniera de Software II
Ingeniera en Diseo de Software Y Sistemas Computacionales

Larisa Jocelyn Antonio Martnez Universidad La Salle Oaxaca 01/05/2013

Qu es un modelo de caso de uso y de qu est conformado? Un modelo de caso de usos incluye los casos de uso que describen el comportamiento del sistema visto por sus usuarios finales, analistas, equipos de pruebas.

Elementos de UML Entidades Estructurales Comportamiento Agrupamiento Anotacin Relaciones Diagramas

Entidades estructurales Son los nombres de los modelos UML y representan fundamentalmente las partes estticas del modelo (conceptos o entidades materiales)

Caso de uso: descripcin de un conjunto de secuencias de acciones que ejecuta un sistema y que produce un resultado observable para un actor particular. Clase: descripcin (abstraccin lgica) de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Interfaz: coleccin de operaciones que especifican un servicio de una clase o componente. Ingeniera de Software Larisa Antonio Martnez Pgina 2

Colaboracin: define una interaccin y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos. Componente: parte modular del diseo del sistema que oculta su implementacin tras un conjunto de interfaces externas. Nodo: es un elemento fsico que existe en tiempo de ejecucin y representa un recurso computacional, que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento. Sirven para modelar la topologa del hardware sobre el que se ejecuta el sistema.

RELACIONES

MODELO DE CASOS DE USO Permite delimitar el sistema y las relaciones entre ste y su entorno. (Similar a los en el enfoque Estructurado) El cliente y el equipo de desarrollo conforman un importante conjunto de integrantes en un sistema. Sin embargo, existe otro integrante de crucial importancia: el usuario. Ni la idea esttica ni la dinmica mostrarn el comportamiento del sistema desde el punto de vista del usuario. Comprender tal punto de vista es clave para generar sistemas que sean tanto tiles como funcionales, esto es, que cumplan los requerimientos y que sea fcil de trabajar con ellos. Facilitan la comunicacin entre el analista y el usuario.

Ingeniera de Software Larisa Antonio Martnez

Pgina 3

ELEMENTOS DE UN DIAGRAMA DE CASOS DE USO

Caso de uso

Secuencia de acciones, incluyendo variantes, que puede realizar el sistema interaccionando con los actores del sistema Actor

Un conjunto coherente de roles que juegan los usuarios cuando interaccionan con los casos de uso. Cualquier cosa con comportamiento (Hardware, software, personas) Lmite del sistema (frontera)

Representa el lmite entre el sistema fsico y los actores que interaccionan con el sistema

RELACIONES EN UN DIAGRAMA DE CASOS DE USO

Asociacin

La participacin de un actor en un caso de uso la instancia de un actor se comunican con instancias de un caso de uso Generalizacin (es_un)

Relacin taxonmica entre un caso de uso ms general y otro ms especfico (tambin se aplica a actores) Dependencia <<extend>> el primero es una funcin opcional del

segundo (variacin o punto de extensin). Se utiliza cuando se tiene un caso de uso que es similar a otro pero que hace un poco ms. Ingeniera de Software Larisa Antonio Martnez Pgina 4

 <<include>> el primero hace una llamada obligatoria al segundo. Ocurre cuando se tiene una porcin de comportamiento que es similar en ms de un caso de uso y no se quiere copiar la descripcin de tal conducta. Utilcese extend cuando se describa una variacin de conducta normal Emplese include cuando se desee evitar repeticiones

Es ms importante realizar las descripciones de los casos de uso que el diagrama de casos de uso. Los casos de uso son documentos de texto Trabajar con los casos de uso significa escribir texto Los diagramas de casos de uso tienen que ser sencillos Ayudan a determinar el contexto, los lmites del sistema

Ingeniera de Software Larisa Antonio Martnez

Pgina 5

CUANDO USARLO?: Para identificar los requisitos funcionales del sistema y para identificar escenarios de prueba y el contexto o lmites Normalmente en las primeras etapas de desarrollo En metodologas dirigidas por casos de uso: Empezar por los casos de uso y derivar de ellos los modelos estructural y de comportamiento Y si no: Asegurarse que el modelo de casos de uso es consistente con los modelos estructurales y de comportamiento

PASOS:

Asegurarse que cada caso de uso describe una parte significativa del funcionamiento del sistema Evitar un nmero excesivo de casos de uso Un caso de uso no es un paso, operacin o actividad individual en un proceso Un caso de uso describe un proceso completo que incluye varios pasos (flujo de trabajo de la empresa) Los casos de uso deben ser simples, dado que podran cambiar con facilidad Los casos de uso tienen que ser entendibles tanto por desarrolladores software como por expertos del dominio Es una descripcin de alto nivel del sistema Evitar conceptos de diseo

IDENTIFICARLOS: A partir de los actores Qu actores? (relacionados con el sistema o organizacin) Quin necesita el sistema? Qu necesita el sistema para funcionar?: personal, hardware especializado, otros programas (software).

Ingeniera de Software Larisa Antonio Martnez

Pgina 6

Para cada actor, identificar los procesos que inician o en los que participan ponerle nombre Determinar lmites/frontera: qu es del sistema? Qu queda fuera? Qu espera recibir/obtener? A partir de los eventos Identificar los eventos externos a los que puede responder el sistema Relacionar los eventos con actores y casos de uso

TIPOS DE ACTORES: Primarios: interaccionan con el sistema para explotar su funcionalidad; trabajan directa y frecuentemente con el software. Secundarios: soporte del sistema para que los primarios puedan trabajar. Iniciadores: no utilizan directamente el sistema pero desencadenan el trabajo de otro actor. (No aparecen en UML pero si los consideran otros autores)

DESCUBRIMIENTOS: Determinar los lmites del sistema Es slo una aplicacin software, el hardware y la aplicacin como un todo? Lo utiliza ms de una persona o una organizacin completa? 2. Identificar los actores principales Quienes interactan con el sistema 3. Para cada actor, identificar sus objetivos como usuario Seguir flujos en la empresa: dinero, informacin, 4. Definir los casos de uso que satisfagan los objetivos de usuario Nombrar los casos de uso con un verbo

Ingeniera de Software Larisa Antonio Martnez

Pgina 7

Las entrevistas con el cliente inician el proceso Estas entrevistas producirn diagramas de clases Obtendremos la base de conocimiento para el dominio del sistema, esto es, el rea del cliente. Ahora se est en condiciones de poder hablar con el usuario Las entrevistas con el usuario empiezan con la terminologa del dominio, aunque debern alternarse hacia la terminologa de los usuarios Estas entrevistas desvelarn a los actores y casos de uso de alto nivel que descubrirn los requerimientos funcionales en trminos generales Esta informacin tambin permitir establecer los lmites y mbito del sistema Entrevistas posteriores con el usuario Permitirn profundizar en los requerimientos, lo que dar lugar a casos de uso que mostrarn los escenarios y las secuencias detalladamente

ENTREVISTAS POSTERIORES CON EL USUARIO Esto podra resultar en otros casos de uso que satisfagan las relaciones de inclusin y extensin.

Ingeniera de Software Larisa Antonio Martnez

Pgina 8

En esta fase es importante confiar en la compresin del dominio a partir de los diagramas de clase Si no se comprende adecuadamente el dominio se podran crear demasiados casos de uso y demasiados detalles, lo cual obstaculizara la labor de diseo.

Ejemplo:

CENTROS HOSPITALARIOS Un cierto hospital necesita organizar la asignacin de guardias de sus mdicos en sus diferentes centros hospitalarios mediante una aplicacin informtica. Para ello asigna a un analista el diseo del sistema utilizando la notacin UML. Un mdico jefe tiene asignada la funcin de Planificador de guardias y debe tener en cuenta los mdicos disponibles, las guardias que debe cubrir y algunas incompatibilidades como asignaciones de tareas de ms alta prioridad. Por otra parte, los datos de todos los mdicos los mantiene un Supervisor, encargado de mantener esta informacin: altas, bajas, cambios de datos, etc. Existe tambin un Administrador del sistema que se encarga de la asignacin y revocacin de permisos a los planificadores. Se desea, asimismo, disponer de una funcin estadstica que permita generar listados informativos. Dado que varios planificadores de guardias pueden trabajar en paralelo, se quiere que se actualicen automticamente las estadsticas que vea cada uno cada vez que haya un cambio por parte de cualquiera de ellos. Asimismo, cada planificador puede editar y modificar planes de guardias. Se pide realizar el Diagrama de Casos de Uso de la aplicacin. Realizar una descripcin textual de los casos de uso y actores contemplados.

Diagrama de casos de uso CENTROS HOSPITALARIOS Solucin: Los casos de uso son: Gestionar Mdicos: dar de alta, de baja y cambio de datos a todos los mdicos de cada centro hospitalario. Ingeniera de Software Larisa Antonio Martnez Pgina 9

Gestionar Estadsticas: actualizar las Estadsticas y presentarlas a los usuarios de la aplicacin cuando lo soliciten. Editar Planes: asignar los mdicos disponibles a las guardias previstas. Gestionar Planes: creacin y borrado de planes, apertura y cierre de planes ya creados, edicin e impresin (por ello se incluye al anterior Editar Planes) Gestionar Usuarios: gestionar las cuentas de los planificadores de guardias autorizados, creando usuarios y asignndoles una palabra clave. Los actores son: Supervisor: empleado administrativo que trabaja con datos confidenciales y que tiene que tener permisos especiales de acceso a datos restringidos. Planificador: encargado de la asignacin de guardias teniendo en cuenta la restricciones introducidas previamente en el sistema por el Supervisor Administrador: responsable de la asignacin de cuentas de acceso y de asegurar la confidencialidad y la integridad de la informacin del sistema.

Ingeniera de Software Larisa Antonio Martnez

Pgina 10

Ingeniera de Software Larisa Antonio Martnez

Pgina 11

Ingeniera de Software Larisa Antonio Martnez

Pgina 12