Análisis y Diseño de Sistemas

Transcripción

1 Análisis y Diseño de Sistemas Dpto. Ciencias e Ingeniería de la Computación Universidad Nacional del Sur Clase 6 Modelo de Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] 1er. CUATRIMESTRE 2006 Repaso La extracción de los requerimientos incluye la comprensión de lo que los clientes y usuarios esperan que haga el sistema. Los requerimientos deben ser especificados y documentados y revisados. Los requerimientos pueden clasificarse en: Requerimientos Funcionales. Requerimientos No Funcionales. Análisis y Diseño de Sistemas - Clase 6 2 Metodologías de Desarrollo Existen distintas metodologías para encarar el desarrollo de un sistema. En este curso se estudian: Metodologías Orientadas a Objetos. El Proceso Unificado de Desarrollo de Software (Rumbaugh, Booch, Jacobson) Metodología OMT (J. Rumbaugh) Metodologías Estructuradas. Metodología de Eduard Yourdon. Metodología Rigurosa/Formales Método RAISE. Metodología Orientado a Objetos Objetivo: desarrollar una serie de modelos que describan el software para satisfacer los requisitos definidos por el cliente y los usuarios. Un enfoque unificado de modelado siguiendo la metodología Orientada a Objetos propuesta por: G. Booch, J.Rumbaugh y I. Jacobson: Proceso de Unificado de Desarrollo de Software Lenguaje de Modelado Unificado (UML) UML permite expresar un modelo de análisis con notación de modelado formada por reglas sintácticas y semánticas. Análisis y Diseño de Sistemas - Clase 6 3 Análisis y Diseño de Sistemas - Clase 6 4 UML Unifica las ideas de los métodos más reconocidos de Ingeniería de Software Orientada a Objetos. Objetivos: Modelar sistemas siguiendo el enfoque OO. Cubrir diferentes tipos y tamaños de sistemas. Crear un lenguaje de modelado que pueda ser utilizado por personas y máquinas. UML es un lenguaje que sirve para visualizar, especificar, construir y documentar sistemas. Vistas de un Sistema Los modelos representan distintas vistas de un problema: Vista del usuario: representa un sistema (producto) desde la vista del usuario (actor). Se modela con casos de uso. Vista estructural: modela la estructura estática (clases, objetos y relaciones). Vista del comportamiento: representa los aspectos dinámicos o de comporta-miento del sistema. Muestra las interac-ciones entre los elementos estructurales. Análisis y Diseño de Sistemas - Clase 6 5 Análisis y Diseño de Sistemas - Clase 6 6 1

2 Vistas de un sistema Vista de implementación: representa cómo van a ser implementados los aspectos estructurales y de comportamiento. Vista del entorno: aspectos estructurales y de comportamiento en el que el sistema a implementar se representa. Modelo de Casos de Uso (MCU) Todos los caso de uso juntos constituyen el Modelo de Caso de Uso que describe la funcionalidad total del sistema Análisis y Diseño de Sistemas - Clase 6 7 Requerimientos Funcionales El mayor esfuerzo de requerimientos es desarrollar un modelo del sistema a construir: Utilizar casos de uso. Los casos de uso se emplean para capturar el comportamiento deseado del sistema. Los requerimientos funcionales están naturalmente estructurados como casos de uso. Requerimientos Funcionales y 1. Identificar los actores que interactúan con el sistema. Actor: Personas u otros sistemas que serán orígenes o destinos de la información que consumirá o producirá el sistema a desarrollar. 2. Identificar los casos de uso asociados a los actores Describir los pasos de cada caso de uso y posibles excepciones. Análisis y Diseño de Sistemas - Clase 6 9 Análisis y Diseño de Sistemas - Clase 6 10 (CU) Los CU se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar cómo se va a implementar. Modelan el comportamiento de un elemento que puede ser un sistema, subsistema o una clase, desde el punto de vista del usuario. Pueden representarse a diferentes niveles de abstracción. Se crean con la captura de requerimientos, evolucionan y se usan durante todo el proceso: guían el proceso de desarrollo. Objetivos. Definir los requisitos funcionales y operativos del sistema, diseñando un escenario de uso acordado entre el usuario final y el equipo de desarrollo. Proporcionar una descripción clara y sin ambigüedades para el diseño. Proporcionar la base para la validación de las pruebas. Análisis y Diseño de Sistemas - Clase 6 11 Análisis y Diseño de Sistemas - Clase

3 UML y el Modelo de Casos de Usos UML provee el Modelo de para representar la vista del sistema que se corresponde con la vista del usuario. En UML la representación visual de los casos de uso es el diagrama de casos de uso. Las últimas tendencias de ingeniería de software orientadas a objetos hablan del Proceso Unificado, dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental. Terminología UML Trabajador: representa una posición que se puede asignar a una persona o equipo en una organización de desarrollo de software. Para cada trabajador se especifican las responsabilidades y habilidades requeridas. Artefacto: es un término general para cualquier clase de descripción o información creada, producida, cambiada o usada por los trabajadores cuando trabajan con el sistema. Por ejemplo: un modelo, un elemento del modelo, etc. El principal artefacto usado en la captura de requerimientos es el modelo de casos de uso (MCU). Análisis y Diseño de Sistemas - Clase 6 13 Análisis y Diseño de Sistemas - Clase 6 14 Trabajadores y Artefactos y Trabajadores Trabajador: Analista de Sistemas Analista Busca actores y CU Estructura el MCU Es responsable de... Arquitecto Prioriza CU Artefacto: Modelo de Casos de Uso Actores Glosario Análisis y Diseño de Sistemas - Clase 6 15 Especificador de CU Diseñador de Interfaces Detalla un CU Prototipea Interface Usuario Análisis y Diseño de Sistemas - Clase 6 16 Modelo de (MCU) El modelo de casos de uso utiliza tres elementos básicos: Actores, para modelar los diferentes roles que los elementos externos al sistema pueden representar. Casos de uso, para representar todo aquello que el actor ha de poder realizar en el sistema. Relaciones, que asocian a los elementos anteriores. El modelo se completa con la descripción de casos de uso, esto es, la especificación de los comportamientos de los casos de uso. Análisis y Diseño de Sistemas - Clase 6 17 Actores El MCU describe lo que hace el sistema para cada tipo de usuario. Cada uno de éstos se representa mediante uno o más actores. Un actor puede representar a una persona física, otro sistema, un dispositivo. Representan a terceros fuera del sistema que colaboran con él. Un actor es como una clase, que se define por la descripción de su comportamiento. Un usuario puede desempeñar varios papeles (roles), esto es, puede actuar como diferentes actores Análisis y Diseño de Sistemas - Clase

4 Actores La definición de actores, sirve para definir el contexto externo del sistema, esto es, delimitar los elementos que se encuentran fuera y dentro del sistema. Un actor juega un rol para cada caso de uso en el que colabora. Cada vez que un usuario concreto interactúa con el sistema, la instancia correspondiente de ese actor está jugando ese rol. Una instancia de un actor es un usuario específico interactuando con el sistema. Actores s Actores de un sistema bancario: cliente Cajero, cliente, gerente, sistema de tarjetas electrónicas, etc. Actores en un sistema de bibliotecas: Socio, empleado de atención al público, empleado catalogador del material, etc. Actores de un sistema de facturación: Cajero, sistema de stock, sistemas de tarjetas, etc. Análisis y Diseño de Sistemas - Clase 6 19 Análisis y Diseño de Sistemas - Clase 6 20 Representan las formas en la que los actores interactúan con el sistema. Los CU son trozos de funcionalidad que el sistema ofrece para agregar un resultado de valor a sus actores. Un CU constituye una secuencia completa de mensajes, y que especifica la interacción que tiene lugar entre un actor y el sistema. El diagrama de casos de uso se acompaña con la especificación o descripción de los CU incluye: La descripción de la secuencia básica o comportamiento normal, a través de la secuencia de mensajes más importantes. Las variantes o secuencias alternativas de mensajes (por ejemplo los posibles errores). Normalmente, un CU tiene una única secuencia básica y uno o más secuencias alternativas. Análisis y Diseño de Sistemas - Clase 6 21 Análisis y Diseño de Sistemas - Clase 6 22 Descripción INFORMAL: CU Enviar Mail Secuencia básica armar el mensaje y enviarlo al servidor de correo para que lo distribuya a los destinatarios. Algunos caminos o secuencias alternativas podrían ser: No existe el destinatario. El mensaje debe ser enviado con alta prioridad. El remitente decide cancelar el procedimiento antes de enviar el Descripción de CU El comportamiento de un caso de uso se puede especificar describiendo un flujo de eventos en forma textual: descripción del caso de uso. La descripción debe ser clara para que alguien ajeno al equipo de desarrollo lo entienda. Se debe incluir: cómo y cuándo empieza y se acaba el caso de uso, cuándo interactúa con actores y qué objetos se intercambian, el flujo básico y los flujos alternativos. Análisis mensaje. y Diseño de Sistemas - Clase 6 23 Análisis y Diseño de Sistemas - Clase

5 En UML, una descripción de CU puede incluir: Diagrama de estados: especifica el ciclo de vida de las instancias del CU, en términos de estados y transiciones entre estados. Diagrama de actividades: describe el ciclo de vida en más detalle describiendo secuencia de acciones que ocurren en las transiciones. Diagramas de colaboración y de secuencia: describen la interacción entre una instancia del actor y una instancia del caso de uso. Análisis y Diseño de Sistemas - Clase 6 25 Una instancia de un CU, es la ejecución particular de un CU. Cuando se ejecuta una instancia de un CU, se ejecuta una secuencia de acciones, como se especifica en el CU y siguiendo uno de los posibles caminos del CU. Múltiples caminos son posibles, y pueden ser muy similares. Son las alternativas de secuencias de acción para el caso de uso. Análisis y Diseño de Sistemas - Clase 6 26 Para el CU Extraer Dinero de un ATM Instancia #1: María ingresa su PIN, solicita extraer $100, obtiene el dinero. Instancia #2: Juan ingresa su PIN, solicita extraer $400, se rechaza la transacción por falta de fondos. cliente Extraer Dinero ATM Análisis y Diseño de Sistemas - Clase 6 27 Los casos de uso poseen atributos. Los atributos representan los valores que una instancia de un CU utiliza y maneja durante la ejecución. : en el CU de Extraer Dinero, PIN, Número de cuenta, Importe de la extracción. Las instancias de los CU, no interactúan entre sí. Se piensa en las instancias de los CU como atómicas, es decir, que se ejecutan completamente o no, pero sin interferencias. Los conflictos entre la ejecución de distintos CU simultáneamente se resuelven en la etapa de diseño. Análisis y Diseño de Sistemas - Clase 6 28 Relaciones Las relaciones identifican la comunicación que existe entre: Actores distintos. Casos de uso distintos. Actores-. Las relaciones pueden ser: Generalización Extensión. Inclusión. Actores y Los actores se comunican con los casos de uso. Una asociación entre un actor y un caso de uso indica que ese actor usa el CU, sea ingresándole información o consumiendo los datos que provee el CU. La asociación entre actores y CU se representa en el diagrama de casos de uso mediante una línea llena. Análisis y Diseño de Sistemas - Clase 6 29 Análisis y Diseño de Sistemas - Clase

6 Organización de CU Los CU se pueden organizar especificando relaciones de generalización, inclusión y extensión entre ellos. Estas relaciones sirven para: Factorizar el comportamiento común, extrayendo ese comportamiento común de los CU en que se incluye. Factorizar variantes, poniendo ese comportamiento en otros CU que lo extienden. Organización de CU - Generalización La generalización puede existir entre CU. Significa que el CU hijo hereda el comportamiento y el significado del CU padre. Tanto el padre como el hijo pueden tener instancias concretas. La generalización entre CU se representa por una línea continua con una punta de flecha vacía. Análisis y Diseño de Sistemas - Clase 6 31 Análisis y Diseño de Sistemas - Clase 6 32 Generalización de CU : los CU s Obtener Parámetros, Obtener Parámetros desde Archivo, Obtener Parámetros desde Pantalla. Organización entre CU - Inclusión La relación de inclusión significa que un CU base incorpora explícitamente el comportamiento de otro CU. Sirve para evitar describir el mismo flujo de eventos repetidas veces. Una relación de inclusión se representa como una dependencia estereotipada con la palabra <<include>>. En la descripción del CU base se debe indicar el punto donde se realiza la inclusión. Análisis y Diseño de Sistemas - Clase 6 33 Análisis y Diseño de Sistemas - Clase 6 34 Organización de CU - Extensión Una relación de extensión entre CU s significa que un CU base incorpora implícitamente el comportamiento de otro CU. La extensión puede verse como que CU que extiende incorpora su comportamiento en el CU base. Una relación de extensión se representa como una dependencia estereotipada con la palabra <<extend>>. Análisis y Diseño de Sistemas - Clase 6 35 Análisis y Diseño de Sistemas - Clase

7 Organización de CU - Extensión La relación de extensión sirve para: Modelar la parte de comportamiento que se ve como opcional. Modelar un subflujo separado que se ejecuta sólo bajo determinadas condiciones. Modelar varios subflujos que se pueden insertar en un punto dado. Organización de CU - Generalización de Actores Generalización entre actores: organiza a los distintos actores, indicando que una descripción abstracta del actor, que es compartida y aumentada por una o más descripciones específicas. : cliente Cliente minorista Cliente mayorista Análisis y Diseño de Sistemas - Clase 6 37 Análisis y Diseño de Sistemas - Clase 6 38 Organización de CU Paquetes Cuando el número de CU es considerable como para manejarlos en un único diagrama, UML propone agruparlos en paquetes. Cada paquete puede contener otros paquetes o varios CU. Descripción de CU - Plantilla Nombre: provee una identificación única. Resumen: describe en una o dos oraciones las interacciones que ocurrirán en el CU. Curso Básico de Eventos: describe los pasos que los actores y el sistema deberán realizar para lograr el objetivo del CU. Representa el camino correcto. Caminos Alternativos: muestra los caminos no tan comunes que se necesitan. Incluyen situaciones en las que se requiere un procesamiento especial. Análisis y Diseño de Sistemas - Clase 6 39 Análisis y Diseño de Sistemas - Clase 6 40 Descripción de CU Plantilla También puede incluir: Puntos de Extensión: muestra el paso en que el CU puede extenderse, y el CU que lo realiza. Precondiciones y Poscondiciones. Reglas de negocio relacionadas: Autor: responsable de la especificación. Fecha: de creación/actualización. Cómo estructurar la descripción Elegir un camino básico completo desde el estado inicial hasta el estado final y describirlo. Describir el resto de los caminos como alternativas o desviaciones del camino básico. Algunas veces las desviaciones son tan sencillas que se incluyen dentro del camino básico (definir políticas). Análisis y Diseño de Sistemas - Clase 6 41 Análisis y Diseño de Sistemas - Clase

8 Cómo estructurar la descripción Las alternativas surgen de: El actor puede elegir distintos caminos Si hay más de un actor involucrado en el CU, las acciones de uno influyen en el camino de acciones del otro. El sistema detecta entrada de datos (inputs) erróneas del actor. Algún recurso del sistema puede estar funcionando mal. El camino básico debería ser el camino normal. Análisis y Diseño de Sistemas - Clase 6 43 Descripción de CU Según la metodología que sigue el Proceso Unificado de Desarrollo de Software, los casos de uso son documentos que participan en todo el proceso del software. El modelo de CU evoluciona junto con el proyecto. Los primeros diagramas de CU, maduran a lo largo del proyecto en la medida que se tiene más conocimiento del problema. Lo mismo ocurre con la descripción (niveles de abstracción). Es importante definir convenciones. Análisis y Diseño de Sistemas - Clase 6 44 CU Extraer dinero de ATM. Curso básico de eventos: El cliente ingresa su clave personal y el importe a extraer. El sistema valida los datos y le entrega el dinero, comprobante y tarjeta. Caminos Alternativos: La clave es incorrecta. El cajero no tiene dinero. El importe no es válido. Análisis y Diseño de Sistemas - Clase 6 45 Nombre: Extraer dinero de un ATM. Resumen: Un cliente extrae dinero de un ATM. Curso Básico de Eventos: 1. El cliente ingresa su clave personal. 2. El sistema valida la clave. 3. El cliente ingresa el importe a extraer. 4. El cliente confirma la operación 5. El sistema valida la operación. 6. El sistema entrega el dinero. 7. El sistema entrega el comprobante de la operación. 8. El sistema entrega la tarjeta. 9. Finalizar. Caminos alternativos: 2.1 La clave es incorrecta. Si el cliente se equivocó menos de tres veces Volver a 1 Sino Quitar tarjeta. Continúa en El cliente cancela la operación. Continúa en La cuenta no tiene dinero suficiente. Informar al cliente. Continúa en El cajero no cuenta con dinero. Informar al cliente. Continúa en 8. E J E M P L O Análisis y Diseño de Sistemas - Clase 6 46 Descripción del CU Extraer dinero ATM Los casos de uso sirven para: Definir el alcance o contexto de problema, determinar el contexto y que parte queda fuera del sistema. Definir la vista de la arquitectura de un sistema, para planificar iteraciones y priorizar casos de uso. Como herramienta de comunicación con los trabajadores del negocio. Temas de la clase de hoy Vistas de un sistema. Casos de uso Utilidad y componentes. UML y el Modelo de casos de uso. Diagrama de y Descripción de. Bibliografía El Proceso Unificado de Desarrollo de Software. Jacobson, Booch, Rumbaugh - Capítulo 7. El Lenguaje Unificado de Modelado. Booch, Jacobson, Rumbaugh - Capítulos 16 y 17. Análisis y Diseño de Sistemas - Clase 6 47 Análisis y Diseño de Sistemas - Clase