UNIDAD I FUNDAMENTOS DE LA INGENIERÌA DEL SW Tema 7 : Modelo de Casos de Uso Asignatura: Ingeniería del Software Titulación: Ingenieríaia en Informática Profesor: Ing. Irma López Moreno DIAGRAMA DE CASOS DE USOS El Diagrama de casos de uso representa la forma en como un cliente (llamado en UML actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso). ¿QUÉ ES UML? Es el Lenguaje Estándar para: Visualizar Especificar Construir y, Documentar los planos del Sw. (Fue desarrollado por la OMG Object Management Group) Características de UML -Proporciona el lenguaje (notación técnica) -Permite expresar requisitos y pruebas -Permite modelar actividades, procesos versiones El Object Management Group (OMG) Consorcio sin fines de lucro formado en 1989 , dedicado estudio y establecimiento de estándares de tecnologías orientadas a objetos, tales UML XMI CORBA BPMN Promueve el uso de tecnología orientada a Objetos. Desarrolla guías y especificaciones normadas. UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo. Permite soportar metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación Diagramas de Casos de Uso con UML Un factor clave al definir casos de uso es que no especifica su implementación. Éste define como debería comportarse un Sistema de Gestión y como interactúan los usuarios con el sistema. Los casosde uso especifican un comportamiento deseado, no imponen como se llevara a cabo ese comportamiento. Lo más importante es que se permite que los usuarios finales y los expertos del dominio se comuniquen con lo desarrolladores sin entrar en detalles. Permiten centrarse en las cuestiones más importantes para el usuario final. UN DIAGRAMA DE CASOSDE USO DE LOS SIGUIENTES ELEMENTOS: CONSTA Actor Casos de Uso Relaciones de uso, herencia y comunicación o asociación. Define la forma como los actores y casos de uso colaboran entre sí ELEMENTOS DE UN DIAGRAMA DE CASOS DE USOS actor Caso de uso asociación permite asociar objetos que colaboran entre sí. Una asociación entre un actor y un caso de uso, indica que el actor y el caso de uso se comunican entre sí, y cada uno puede enviar y recibir mensajes Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema. Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local. RELACIONES ENTRE ACTORES •Los actores en UML son clases con el estereotipo <<actor>> y tienen un estereotipo icono estándar. -El nombre de la clase es el nombre del actor. – Una clase actor puede tener atributos y comportamiento. – Los actores pueden tener las mismas relaciones que las clases. •Cuando varios actores, como parte de sus papeles, también representan un papel más generalizado, se describe mediante una relación de generalización. – El comportamiento del papel general se describe en una superclase actor. Los actores especializados heredan el comportamiento de la superclase y extienden ese comportamiento de algún modo. Actor:= class <<cliente> > atributos <<Agente de seguros>> métodos <<cliente por teléfono>> <<cliente en persona>> ES UNA OPERACIÓN/TAREA ESPECÍFICA QUE SE REALIZA TRAS UNA ORDEN DE ALGÚN AGENTE EXTERNO, SEA DESDE UNA PETICIÓN DE UN ACTOR O BIEN DESDE LA INVOCACIÓN DESDE OTRO CASO DE USO. Asociación entre C.U y C.U Asociación entre Actor y C.U Gestión de Mnto. De libros Encargado <<primario>> Gestión de Préstamos Gestión de fechas Relación de inclusión Relación por extensión asociación Préstamos a investigadores préstamos a estudiantes Flujo de eventos Principal: Obtener y Verificar el libro pedido. include (Gestión de fechas). Gestión de Préstamos C.U. DESTINO Gestión de fechas Verificar que el libro pedido esté disponible. C.U. origen La relación de inclusión se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento común en un caso de uso aparte (que será incluido por un caso de uso base). Una relación de inclusión se representa como una dependencia, estereotipada con include ó uses. Validar usuario Usuari o Alertas de mensaje Buscando datos del producto Selecciona café <<GERENTE>> <<Secundario>> pedido <<empleado>> <<primario>> Obtener reportes de ventas por producto RELACIONES DE HERENCIA (ESPECIALIZACIÓN/GENERALIZACIÓN) Indica que una clase (clase derivada) hereda los métodos y atributos especificados por una clase (clase base), por lo cual una clase derivada además de tener sus propios métodos y atributos, podrá acceder a las características y atributos visibles de su clase base. Persona Alumno Especialización Profesor Generalización (relación es_un) La herencia es uno de los conceptos fundamentales de la programación orientada a objetos, en la que una clase «recoge» todos los atributos y operaciones de la clase de la que es heredera, y puede alterar/modificar algunos de ellos, así como añadir más atributos y operaciones propias. En UML, una asociación de generalización entre dos clases, coloca a estas en una jerarquía que representa el concepto de herencia de una clase derivada de la clase base Representación en UML de una Generalización En el Diagrama de Clases (Modelo Estático) CLASE BASE CLASE DERIVADA En el Diagrama de Casos de Uso (Modelo de Comportamiento MAS DETALLES DE LAS ASOCIACIONES Asociación Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una línea simple. Dependencia o Instanciación Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada. Generalización Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores). extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características). uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica. De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar. SISTEMA DE GESTIÓN DE BIBLIOTECAS Lecto r Estudiant e Jef e Investigado r Diagrama de modelado de contexto del sistema a través del Diagrama de casos de uso. También llamado Modelo de Comportamiento del sistema o modelo de casos de uso. Modelado de los Requisitos de un Sistema Para modelar los requisitos de un sistema: • Hay que identificar el contexto del sistema, identificando los actores a su alrededor . (Fuente: Booch, Jacobson, Rumbaugh) • Hay que considerar el comportamiento que cada actor espera del sistema o requiere que éste le proporcione. • Hay que nombrar esos comportamientos comunes como casos de uso. • Hay que factorizar el comportamiento común en nuevos casos de uso que puedan ser utilizados por otros; hay que factorizar el comportamiento variante en nuevos casos de uso que extiendan los flujos principales. • Hay que modelar esos casos de uso, actores y relaciones en un diagrama de casos de uso. • Construir los Diccionarios de actores y diccionario de casos de uso para el documento ERS DICCIONARIO DE ACTORES Actor Nombre de Actor Director plantel Administrador de Control de Estudio Docente Representante Descripción Actor Realiza consultas de notas, Imprime constancia de inscripción, constancia de estudio Se encarga de llenar y editar la base de datos con información del docente, alumnos Inserta las notas de los alumnos dependiendo las secciones, lapso y asignatura que dicte Realiza solicitud de constancia de estudio Tipología Rol Primario Consulta de notas e Imprime Constancias. Primario RegistrarDatos del docente y alumno Primario Secundario Insertar notas de los alumnos Imprime Constancias DICCIONARIO DE CASOS DE USO Caso de Uso Nombre del caso de uso Descripción Actor Validación registro Consulta de notas Se encarga de la validación y autenticación del usuario Se encarga de efectuar consultas de notas ed estudiantes así como de registrar notas por parte del docente Genera reportes se docentes activos y/o jubilados Impresión docentes Realiza inscripción de estudiantes inscripción DICCIONARIO DE CASOS DE USO Nombre del caso de uso Actores que intervienen en el C.U Descripción C.U Ejemplos de DICCIONARIO DE C.U Nombre Nombre Clase Descripcion Descatributos Autenticación Docentes, Administrador, Director Permite validar los accesos permitidos al sistema Eventos Actor Eventos Sistema Introduce usuario El Sistema habilita la base de Introduce Contraseña datos Valida usuario y contraseña Genera alerta en caso de error Si tiene acceso le establece los niveles de acceso Flujo Principal En caso de no existir usuario y clave Invoca método de generación de error Alternativa Precondición Pos condición Presunción Tiene que existir la clave y la contraseña La interfaz tiene que estar habilitada Usuario validado La base de datos para verificar está disponible. Diccionario de Clases Nombre de la clase Descripción Atributos Nombre Tipo Longitud Descripción Visibilidad Métodos Nombre Descripción Parámetros Visibilidad
