Análisis y Diseño de Sistemas
UNIVERSIDAD CATÓLICA DE SANTA MARÍA PROGRAMA PROFESIONAL DE INGENIERÍA DE SISTEMAS
SESIÓN 05
UML Diagramas de Casos de Uso I OBJETIVOS o
Demuestra, explica y exhibe el uso de metodologías, técnicas y herramientas para el Análisis Orientado a Objetos.
II TEMAS A TRATAR
El Lenguaje Unificado de Modelado (UML)
Diagramas de Casos de Uso
III MARCO TEORICO EL LENGUAJE UNIFICADO DE MODELADO (UML) En todas las disciplinas de la Ingeniería se hace evidente la importancia de los modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir, estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en este momento cuando los diseñadores del modelo deben investigar los requerimientos del producto terminado y dichos requerimientos pueden incluir áreas tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo es dividido en un número de vistas, cada una de las cuales describe un aspecto específico del producto o sistema en construcción. El modelado sirve no solamente para los grandes sistemas, aún en aplicaciones de pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que entre más grande y más complejo es el sistema, más importante es el papel de que juega el modelado por una simple razón: "El hombre hace modelos de sistemas complejos porque no puede entenderlos en su totalidad". UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.
Los principales beneficios de UML son:
Mejores tiempos totales de desarrollo (de 50 % o más). Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos. Establecer conceptos y artefactos ejecutables. Encaminar el desarrollo desarrollo del escalamiento escalamiento en sistemas complejos de misión crítica. Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas. Mejor soporte a la planeación y al control de proyectos.
Sesión no05
Análisis y Diseño de Sistemas
Alta reutilización y minimización de costos.
UML, ¿Método o Lenguaje de Modelado? UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método. Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelo - los símbolos utilizados en los modelos - y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas.
Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:
Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos. Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema. Vista de Componentes: Muestra la organización de los componentes de código. Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente. Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.
Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve
tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.
Símbolos o Elementos de modelo:
Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y gen eralización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.
Reglas o Mecanismos generales:
Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o p roceso específico, organización o usuario.
Sesión no05
Análisis y Diseño de Sistemas UML está compuesto por los siguientes diagramas:
Área
Estructural
Dinámica
Vista
Diagramas
Conceptos Principales
Vista Estática
Diagrama Clases
Vista de Casos de Uso
Diagramas de Casos de Uso
Caso de Uso, Actor, asociación, extensión, generalización.
Vista de Implementación
Diagramas de Componentes
Componente, interfaz, dependencia, realización.
Vista de Despliegue
Diagramas Despliegue
de
Nodo, componente, dependencia, localización.
Vista de Estados de máquina
Diagramas Estados
de
Estado, acción.
Vista de actividad
Diagramas Actividad
de
Estado, actividad, transición, determinación, división, unión.
Vista de interacción
Diagramas Secuencia
de
Interacción, objeto, mensaje, activación.
Diagramas Colaboración
de
Colaboración, interacción, rol de colaboración, mensaje.
de
Paquete, modelo.
Administración o Gestión de modelo
Vista de Gestión de modelo
Diagramas Clases
Extensión de UML
Todas
Todos
de
Clase, asociación, generalización, dependencia, realización, interfaz.
evento,
transición,
subsistema,
Restricción, estereotipo, valores, etiquetados.
Diagramas de Casos de Uso Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje. Es un a técnica para captura de requisitos.
Los Casos de Uso (Ivar Jacobson) describen bajo la forma de acciones y reacciones el comportamiento de un sistema desde el punto de vista 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. Los Casos de Uso cubren la carencia existente en métodos previos (OMT, Booch) en cuanto a la determinación de requisitos.
Sesión no05
Análisis y Diseño de Sistemas
Los Casos de Uso particionan el conjunto de necesidades atendiendo a la categoría de usuarios que participan en el mismo. Están basados en el lenguaje natural, es decir, es accesible por los usuarios.
Actores Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan con el sistema que estamos construyendo de la misma forma. Por ejemplo, para una empresa que recibe pedidos en forma telefónica, todos los operadores que reciban pedidos y los ingresen en un sistema de ventas, si pueden hacer las mismas cosas con el sistema, son considerados un único actor: Empleado de Ventas. Los actores son externos al sistema que vamos a desarrollar. Por lo tanto, al identificar actores estamos empezando a delimitar el sistema, y a definir su alcance. Definir el alcance del sistema debe ser el primer objetivo de todo analista, ya que un proyecto sin alcance definido nunca podrá alcanzar sus objetivos. Es importante tener clara la diferencia entre usuario y actor. Un actor es una clase de rol, mientras que un usuario es una persona que, cuando usa el sistema, asume un rol. De esta forma, un usuario puede acceder al sistema como distintos actores. La forma más simple de entender esto es pensar en perfiles de usuario de un sistema operativo. Una misma persona puede acceder al sistema con distintos perfiles, que le permiten hacer cosas distintas. Los perfiles son en este caso equivalentes a los actores. Otro sistema que interactúa con el sistema que estamos construyendo también es un actor. Por ejemplo, si nuestro sistema deberá generar asientos contables para ser procesados por el sistema de contabilidad, este último sistema será un actor, que usa los servicios de nuestro sistema. También puede ocurrir que el actor sea una máquina, en el caso en que el software controle sus movimientos, o sea operado por una máquina. Por ejemplo, si estamos construyendo un sistema para mover el brazo de un robot, el hardware del robot será un actor, asumiendo que dentro de nuestro sistema están las rutinas de bajo nivel que controlan al hardware. Los actores se representan con dibujos simplificados de personas, llamados en inglés “stick man” (hombres de palo)
Tenemos los siguientes 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.
La misma persona física puede interpretar varios papeles como actores distintos, el nombre del actor describe el papel desempeñado. 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. Los casos de uso intervienen durante todo el ciclo de vida. El proceso de desarrollo estará dirigido por los casos de uso. Un escenario es una instancia de un caso de uso.
Definiciones Básicas Un caso de uso es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento, ese actor, junto con otros actores, intercambian datos o control con el sistema, participando de ese caso de uso. El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objeto o entidad del sistema que es afectado por el caso. Gráficamente, los casos de uso se representan con un óvalo, con el nombre del caso en su interior.
Sesión no05
Análisis y Diseño de Sistemas
Es importante notar que el nombre del caso siempre está expresado desde el punto de vista del actor y no desde el punto de vista del sistema. Por eso el segundo caso de uso se llama Recibiendo información de pedidos y no Generando información de pedidos. Los casos de uso tienen las siguientes características: 1) Están expresados desde el punto de vista del actor. 2) Se documentan con texto informal. 3) Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis está puesto en la interacción. 4) Son iniciados por un único actor. 5) Están acotados al uso de una determinada funcionalidad –claramente diferenciada – del sistema. El último punto es tal vez el más difícil de definir. Uno podría, después de todo, decir que todo sistema tiene un único caso de uso Usando el Sistema. Sin embargo, la especificación resultante sería de poco utilidad para entenderlo; sería como implementar un gran sistema escribiendo un único programa. La pregunta importante es: ¿Qué es una “funcionalidad claramente diferenciada”? Por ejemplo, ¿ingresar pedidos es un caso de uso y autorizarlos es otro? ¿Cancelar los pedidos, es otro caso de uso, o es parte del caso de uso referido al ingreso de pedidos? Si bien se pueden encontrar argumentos válidos para cualquiera de las dos alternativas, en principio la respuesta a todas estas preguntas es que son todos casos de uso distintos. Lamentablemente, si en la programación los criterios para dividir la funcionalidad en programas suelen ser difusos, los criterios para dividir la funcionalidad de un sistema en casos de uso son aún más difusos, y por esto se hace importante usar el sentido común en estas decisiones En principio podríamos decir que la regla general es: una función del sistema es un caso de uso si se debe indicar explícitamente al sistema que uno quiere acceder a esa función. Por ejemplo, si uno quiere dar de alta un pedido, accederá a la funcionalidad de alta de pedidos del sistema. Sin embargo, si uno quiere dar de alta un campo del pedido, no debe indicar al sistema que quiere acceder a esa función. Dar de alta un campo de un pedido es una función que forma parte de un caso de uso mayor: dar de alta un pedido. Esta regla, si bien puede ser útil, no debe seguirse al pie de la letra, ya que se puede prestar a confusiones. Por ejemplo, supongamos que uno quiere especificar un sistema en el cual los usuarios pueden ver un pedido, y tienen disponibles funciones para ver el siguiente pedido, el anterior, el último y el primero. El actor debe indicar al sistema que quiere acceder a cada una de esas funciones, y según nuestra regla serían todas ellas casos de uso distintos. Sin embargo, en esta situación es mucho más práctico definir un único caso de uso navegando pedidos, que especificarlos todos como casos de uso distintos. Cuando pensamos en el grado de detalle de la división de los casos de uso también resulta útil imaginar que uno está escribiendo el manual del usuario del sistema.
Sesión no05
Análisis y Diseño de Sistemas
Notación para modelo de Casos de Uso
Descripción de los Casos de Uso Los casos de uso se documentan con texto informal. En general, se usa una lista numerada de los pasos que sigue el actor para interactuar con el sistema. A continuación se muestra una parte simplificada de la descripción del caso de uso “Ingresando Pedido”.
Caso de Uso: Ingresando Pedido. Actor: Empleado de Ventas. 1) El cliente se comunica con la oficina de ventas, e informa su número de cliente 2) El oficial de ventas ingresa el número de cliente en el sistema 3) El sistema obtiene la información básica sobre el cliente 4) El cliente informa el producto que quiere comprar, indicando la cantidad 5) El sistema obtiene la información sobre el producto solicitado, y confirma su disponibilidad. 6) Se repite el paso 4) hasta que el cliente no informa más productos 7) ...
Al describir los casos de uso aparece una de sus principales limitaciones. Supongamos que queremos describir un sistema en el cual la interacción con el usuario es muy simple: ingresa un conjunto básico de datos, y con esos datos el sistema realiza una gran cantidad de cálculos, aplicando complejas fórmulas. ¿Cómo hago con un caso de uso para especificar el comportamiento interno del sistema, si su comportamiento no es trivial? La respuesta es que los casos de uso son muy limitados para lograr este objetivo, ya que se basan en el uso de texto informal. Por lo tanto, deberemos usar una nueva notación para especificar este comportamiento interno, algo equivalente a los diagramas de flujo de datos del análisis estructurado. En UML se propone usar una notación llamada “Diagrama de Actividad”, el moderno heredero del diagrama de flujo, o “flowchart”. Otra de las limitaciones de los casos de uso es que no hay una sintaxis clara para indicar, dentro de la descripción del caso, las decisiones e iteraciones. De esta forma, es común que en las descripciones de los casos se deba recurrir a frases como “Se repite el paso X hasta que ocurre C”, o “Si ocurre C se pasa al paso X”. En estas situaciones lo importante no es la forma en la que se expresan las condiciones e iteraciones, sino hacerlo de una forma consistente. Si la descripción del caso fuera muy compleja, es conveniente usar notaciones gráficas, por ejemplo los diagramas de actividad.
Alternativas Durante la ejecución de un caso de uso, suelen aparecer errores o excepciones. Por ejemplo, mientras se ingresa un pedido, el cliente puede solicitar un producto que está discontinuado. El sistema deberá en este caso informar esta situación al empleado que ingresa el pedido. Esas desviaciones del curso normal del caso de uso se llaman alternativas. Las alternativas tienen las siguientes características: 1) Representan un error o excepción en el curso normal del caso de uso. 2) No tienen sentido por sí mismas, fuera del contexto del caso de uso en el que ocurren. Si bien en la bibliografía las alternativas se documentan al final del caso de uso, la experiencia demuestra que resulta útil documentar los casos en tablas, mostrando el curso principal en la primera columna, y las alternativas en una segunda columna, como lo muestra el siguiente ejemplo:
Sesión no05
Análisis y Diseño de Sistemas
De esta forma, es mucho más simple ver en qué parte del caso de uso puede ocurrir la excepción, y se mantiene la ventaja de poder leer de corrido el curso normal.
Modularizar los Casos de Uso A continuación, se muestra cómo se organiza una especificación que utiliza casos de uso para evitar redundancia (duplicación innecesaria de información) y facilitar su comprensión
Relaciones de Extensión Muchas veces, la funcionalidad de un caso de uso incluye un conjunto de pasos que ocurren sólo en algunas oportunidades. Supongamos que estamos especificando un sistema en el cual los clientes pueden ingresar pedidos interactivamente, y que dentro de la funcionalidad del ingreso de pedidos el usuario puede solicitar al sistema que le haga una presentación sobre los nuevos productos disponibles, sus características y sus precios. En este caso, tengo una excepción dentro del caso de uso Ingresando Pedido. La excepción consiste en interrumpir el caso de uso y pasar a ejecutar el caso de uso Revisando Presentación de Nuevos Productos.
En este caso decimos que el caso de uso Revisando Presentación de Nuevos Productos extiende el caso de uso Ingresando pedido y se representa por una línea de trazos desde el caso que ‘extiende a’ al caso que es ‘extendido’. Las extensiones tienen las siguien tes características: 1) Representan una parte de la funcionalidad del caso que no siempre ocurre. 2) Son un caso de uso en sí mismas. 3) No necesariamente provienen de un error o excepción. En su libro, Jacobson ejemplifica los casos de uso con ir a cenar a un restaurant. Para él, tomar café después de cenar es un ejemplo de una extensión. La pregunta que surge claramente es ¿cuál es la diferencia entre una alternativa y una extensión? La respuesta puede derivarse de las características de cada uno: · Una extensión es un caso de uso en sí mismo, mientras que una alternativa no. · Una alternativa es un error o excepción, mientras que una extensión puede no serlo.
Sesión no05
Análisis y Diseño de Sistemas Como regla aproximada podemos pensar que si algo opcional debe ser expresado con más de un paso, seguramente es una extensión y no una alternativa.
Relaciones de Inclusión Cuando decimos que un caso de uso incluye a otro indicamos que siempre lo necesita. Se puede incluir una relación entre dos casos de uso de tipo “include” si se desea especificar comportamiento común en dos o más casos de uso. Se representa como se muestra a continuación
Las ventajas de esta asociación son:
Las descripciones de los casos de uso son más cortas y se entienden mejor. La identificación de funcionalidad común puede ayudar a descubrir el posible uso de componentes ya existentes en la implementación.
Las desventajas son:
La inclusión de estas relaciones hace que los diagramas sean más difícil de leer, sobre todo para los clientes.
Relaciones de Herencia En un diagrama de casos de uso también pueden mostrarse generalizaciones (relaciones de herencia) para mostrar que diferentes elementos están relacionados como tipos de otros. Son aplicables a actores o casos de uso, pero para estos últimos la semántica es muy similar a las relaciones “extend”. Para los casos de uso, una relación entre dos casos de uso es aquél donde el triángulo apunta al caso de uso general y el otro extremo de la línea es un tipo especial del caso de uso general (también conocido como una especialización). El tipo especial del caso de uso general, contiene todos los pasos del escenario del caso de uso general más el escenario del caso de uso específico.
Sesión no05
Análisis y Diseño de Sistemas Lím ite s d el Sis tem a Resulta útil dibujar los límites del sistema cuando se pretende hacer un diagrama de casos de uso para parte del sistema.
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?
IV
EJERCICIOS 01. Se desea desarrollar un sistema de e ncuentros virtuales (parecido a un chat). Realizar el Diagrama de Casos de Uso Cuando se conecta al servidor, un usuario puede entrar o salir de un encuentro. Cada encuentro tiene un manager. El manager es el usuario que ha planificado el encuentro (el nombre del encuentro, la agenda del encuentro y el moderador del encuentro). Cada encuentro puede tener también un moderador designado por el manager. La misión del moderador es asignar los turnos de palabra para que los usuarios hablen. El moderador también podrá dar por concluido el encuentro en cualquier momento. En cualquier momento un usuario puede consultar el estado del sistema, por ejemplo los encuentros planeados y su información
02. Gestión de fincas e inmuebles Una empresa gestiona un conjunto de inmuebles, que administra en calidad de propietaria. Cada inmueble puede ser bien un local (local comercial, oficinas, etc.), un piso o bien un edificio que a su vez tiene pisos y locales. Como el número de inmuebles que la empresa gestiona no es un número fijo, la empresa propietaria exige que la aplicación permita tanto introducir inmuebles nuevos, así como darlos de baja, modificarlos y consultarlos. Asimismo, que una empresa administre un edificio determinado no implica que gestione todos sus pisos y locales, por lo que la aplicación también deberá permitir introducir nuevos pisos o locales, darlos de baja, modificarlos y hacer consultas sobre ellos. Cualquier persona que tenga una nómina, un aval bancario, un contrato de trabajo o venga avalado por otra persona puede alquilar el edificio completo o alguno de los pisos o locales que no estén ya alquilados, y posteriormente desalquilarlo. Por ello, deberán poder darse de alta, si son nuevos inquilinos, con sus datos correspondientes (nombre, DNI, edad, sexo, ...), poder modificarlos, darlos de baja, consultarlos, etc. Para la realización de cualquiera de estas operaciones es necesaria la identificación por parte del inquilino.
Sesión no05
Análisis y Diseño de Sistemas 03. Gestión de citas y diagnósticos Un hospital funciona con un sistema de cita previa. Cada vez que un paciente pide cita, puede solicitarla él mismo vía web, por teléfono o personándose en el centro hospitalario. En los dos últimos casos será atendido por un administrativo. Independientemente de cómo se pida la cita, el sistema le asigna un día, una hora y su médico de cabecera. Para guardar esta información se utiliza un listado con el Número de la Seguridad Social (NSS) del paciente, su nombre, apellidos, teléfono para comunicarle cualquier cambio en el día, hora y número de colegiado de su médico de cabecera. Una vez que llega a la consulta, el médico tiene un historial (datos personales, fecha de visitas, diagnóstico o visita a otros médicos especialistas) y le indica un diagnóstico con su correspondiente tratamiento. Si es enfermedad común, el paciente puede recibir el tratamiento en casa y, si no lo es, debe ir al especialista. Si le manda al especialista, se tendrá en cuenta que hay muchos especialistas, según el problema presentado, y que de nuevo se pedirá cita previa (igual que para el de cabecera). Cuando llega el día, el paciente visita el especialista y éste realiza un diagnóstico que se anota en su ficha de diagnóstico, identificando al paciente, al médico general que lo envió a su consulta, el diagnóstico y el tratamiento que se le va a aplicar. En el tratamiento pueden ser necesaria la intervención de una o varias operaciones, que serán realizadas por el médico especialista, así como radiografías, ecografías, inyecciones, etc., que van a ser realizadas por distintas personas no médicas del hospital: ATS, técnicos, auxiliares, etc. Se sabe que en el hospital los médicos van identificados por su número de colegiado y el resto del personal por su número de registro personal.
VI
BIBLIOGRAFIA Y REFERENCIAS Roger S. Pressman 2010. Ingeniería de Software: Un Enfoque Práctico. Séptima Edición: Mac Graw Hill, 2010. ISBN: 978-607-15-0314-3. Ian Sommerville 2005.Sommerville, I. 2002. Ingeniería de Software. 6° Edición. s.l. : Addison-Wesley, 2002. Sommerville, Ian. 2005. Ingeniería de Software. Séptima Edición. Madrid: Pearson Educación, 2005. pág. 712. ISBN: 84-7829-074-5. IEEE Computer Society. 2004. Guide to the Software Engineering Body of Knowledge. SWEBOK. [En línea] 2004. IEEE.1993.IEEE Recomended Practice for Software Requeriments Specificacitons. Institute of Electronical and Electronics Engineers, 1993. IEEE/ANSI Standard 830-1993
Sesión no05
