ANÁLISIS Y DISEÑO DE SISTEMAS

Transcripción

1 ANÁLISIS Y DISEÑO DE SISTEMAS Clase XVIII: Modelo Dinámico Diagramas de Actividades Primer Cuatrimestre 2013 Diagrama de Actividades (DA) Un grafo o diagrama de actividad (DA) es un tipo especial de máquina de estados que muestra la secuencia de etapas que se emplean en un proceso que representa un algoritmo o flujo de trabajo. El DA muestra flujos de control. Es otro tipo de modelo para representar gráficamente la dinámica de una actividad del sistema. Mg. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] Dpto. Cs. e Ing. de la Computación Universidad Nacional del Sur Recordamos! Los DA también son una técnica para especificar CU. 2 Diagramas de Actividad Los DA también heredan características de la familia de diagramas de flujo (DFD) y se utilizan para representar paso a paso el flujo de control. A diferencia de los diagramas de flujo tradicionales muestran tanto flujo de control secuencial como flujos de control concurrente. Son un tipo de diagrama útil para el modelado de procesos que involucran varios objetos, inclusive procesos de negocio. Diagrama de Actividades (DA) En un DA los estados o actividades representan a acciones o sub-actividades y las transiciones en general se disparan automáticamente al completar la actividad. El objetivo de un DA es mostrar el flujo de procesamiento interno. DA vs. DE DA la mayoría de los eventos representan completar una acción interna. Los DE en general los eventos son asincrónicos. 3 4 Ejemplo - Diagrama de Actividad Empleado Depósito Procesar Orden Pedido DA para Procesar Orden de Pedido DA: Componentes En el diseño de un diagrama de actividades se pueden uno o más de encontrar los siguientes elementos: Estados (que se dividen en de actividad o estados de acción). Transiciones. Objetos. Decisiones o Bifurcaciones. Divisiones concurrentes. Uniones concurrentes

2 Estados Estado Estados Acción: No se descomponen, esto es, son atómicos. No pueden ser interrumpidos por eventos. Su duración es insignificante. Estados Actividad De ser necesario se pueden descomponer, representando su actividad en otro diagrama. Pueden recibir interrupciones. Tienen duración en el tiempo. Ambos usan la misma representación en el diagrama Notación - Ejemplos Estados de Acción CalcularTotal Contador : = contador + 1 IncrementarContador Estados de Actividad ProcesarFactura(f) Solicitar_Registración Entry/ ResetearTiempoEspera 7 8 Estados de Acción y Actividad En un DA al ingresar a un estado de acción o de actividad, simplemente se ejecuta la acción o la actividad. Al terminar la ejecución, el control pasa al siguiente estado. Solo en estados de actividad, como en los estados del DE, pueden asignarse eventos de entrada, salida o eventos aleatorios. Transiciones Una transición es el flujo que muestra el camino de un estado al próximo estado. La transición semánticamente tiene el mismo significado que en el diagrama de estados. Los diagramas de actividad no requieren de eventos que dispare la transición (transiciones ). La transición ocurre porque terminó la ejecución del estado actual y así se pasa al próximo Transiciones Decisión [else] [condición] Leer usuario Leer clave Transiciones automáticas Transiciones con condición Las decisiones especifican caminos alternativos elegidos según el valor de una condición de guarda. Las condiciones de guarda se encierran entre [ ]. Una condición válida es la condición else. Una decisión tiene un flujo de entrada y dos o más flujos de salida, cada uno acompañado de una condición de guarda. [ datos incorrectos ] Informar Error Las condiciones se evalúan y se pasa al próximo estado que satisface la condición. 11 [ datos correctos ] Estado Final: Usuario Registrado DA Registrar_Usuario La decisión en DA está bien construida si las condiciones de guarda son disjuntas y completas. 12 2

3 ATM - Decisión Estado inicial Decisión Flujos Concurrentes Las organizaciones y los sistemas pueden realizar más de una actividad al mismo tiempo: concurrencia. Elementos para representar concurrencia: División: después de una actividad se puede dividir el procesamiento en varias actividades independientes. Marca el inicio de actividades concurrentes. Unión: si antes de pasar a la próxima actividad se requiere que dos o más actividades previas hayan concluido. Marca el fin de actividades concurrentes. La representación gráfica es una barra de sincronización. Estado final División y Unión La división tiene un flujo de entrada y dos o más flujos de salida. La unión tiene dos o más flujos de entrada y un flujo de salida. El flujo de salida de una unión se dispara cuando se completaron todos los flujos de entrada a dicha unión. Flujos Concurrentes DA Proceso de desarrollo de un software (incompleto) ImplementarM1 DividirMódulos DefinirInterfases ImplementarM2 TestearIntegración ImplementarM Diagramas de Actividad RECORDAMOS: Uno de los usos del DA es como herramienta para especificar casos de uso. En este sentido su uso tiene que ver con reflejar el flujo del CU Ejemplo: Supongamos que se desea especificar el un caso de uso Actualizar Entidad. Leer NovedadesEntidad [ datos no validos ] [ datos válidos ] [ es_alta ] [ existe entidad ] [ no existe entidad ] [ baja o modificacion ] [ es_baja ] [ es_modificacion ] [ es_alta ] Borrar Entidad Modificar Entidad Agregar Entidad Grabar Modificaciones Informar Error

4 Estado inicial. Otros elementos Estado final: marca el final de todos los flujos de ejecución. Pueden existir varios estados finales. Inicial Estructuración del DA Para que un DA no resulte demasiado complejo se puede estructurar usando estados anidados. Notación: subactividad_anidada Final de flujo: marca el punto final del flujo. El resto de los flujos siguen su ejecución Final Final de Flujo Subactividades Actividades expandidas Terminar proceso tarjeta no válida Introducir importe Leer Tarjeta [ importe no disponible ] Terminar Proceso tarjeta no válida [ tarjeta no válida ] [ tarjeta válida ] Mensaje Tarjeta Inválida Entregar Tarjeta [ importe disponible ] Introducir importe Estados Anidados Ingresar clave Ingresar importe Introducir clave [ 3er código invalido ] [ 3er. clave incorrecta ] [ 1er. o 2da. clave incorrecta ] [ código válido ] [ clave correcta ] Introducir Clave Calles (Swimlanes) En un DA se pueden identificar secciones o calles que agrupen actividades que tienen algo en común. Se utilizan para modelar flujos de trabajo de procesos. Al dividir las actividades en grupos, cada grupo representa una parte de la organización responsable de las actividades. Cada grupo se denomina calle. Las calles tiene un nombre único en el diagrama. Siempre las actividades pertenecen a una única calle y las transiciones permiten cruzar de calle. Ejemplo Proceso Venta de pasajes aéreos

5 Calles + concurrencia Hay actividades concurrentes si: un proceso se inicia en varios puntos (actividades concurrentes desde el inicio) o, sino se debe indicar explícitamente el punto donde se inicia la concurrencia con un flujo de división. Las calles son una alternativa de representación interesante para representar flujos de trabajo concurrente. Referencias a objetos El flujo de control de un DA también se pueden involucrar objetos: Ciertas actividades producen instancias de clases. Ciertas actividades modifican uno o más atributos de una instancia. Es posible incluir los objetos implicados en un diagrama de actividades colocándolos en el diagrama y conectándolos a una actividad con una dependencia. De cada objeto se determina la clase a la que pertenece y un estado que refleje su situación Ejemplo Leer NovedadesEntidad Usos del Diagrama de Actividad Objetos 27 [ datos no validos ] [ datos válidos ] [ es_alta ] [ existe entidad ] [ no existe entidad ] [ baja o modificacion ] [ es_baja ] [ es_modificacion ] [ es_alta ] Borrar Entidad Modificar Entidad Agregar Entidad Entidad [eliminado] Entidad [modificada] Entidad [nueva] Grabar Modificaciones Informar Error Los diagramas de actividades normalmente se utilizan en dos formas: Para modelar una operación: Como diagramas de flujos y para especificar detalles de la operación. Usan estados de acción, flujos de control y referencia a objetos. Para modelar flujos de trabajo: Hacen hincapié en las actividades tal como son vistas por los actores. Resaltan flujos de trabajo y procesos de negocio. Destacan el uso de calles. 28 Ejemplo DA Flujo de Trabajo De: DA A: BPMN BPMN Business Process Modeling Notation (Notación para el Modelado de Procesos de Negocio) es una notación gráfica estandarizada para modelado de procesos de negocio, en formato de flujo de trabajo (workflow) (OMG) Características BPMN es un estándar internacional. BPMN es independiente de cualquier metodología de modelado de procesos. BPMN permite modelar los procesos manera unificada y estandarizada permitiendo un entendimiento a todas las personas de una organización. AyDS Clase 17- MMV

6 BPMN Notación Eventos BMPN - Ejemplo Guía para la elaboración del modelo dinámico Una propuesta para diseñar diagramas de secuencia, colaboración, estados y actividades 33 El modelo dinámico (MD) modela los aspectos del sistema relacionados con el tiempo y los cambios que se producen. Los principales elementos del MD son: Eventos, que representan estímulos externos. Estados, que representan valores de los objetos. Interacciones, relaciones entre los objetos para realizar una tarea de interés. Incluye el envío de mensajes Actividades, cálculos que demandan un tiempo de ejecución. Acciones, cálculos atómicos. 35 El Modelo Dinámico Elaboración del Modelo Dinámico La construcción del modelo dinámico comienza identificando los eventos o estímulos que causan cambios y los estados por los que pasa el sistema. Pasos a seguir: 1. Preparar escenarios de diálogos asociados a los casos de uso: identificar caminos básicos y alternativos. 2. Identificar el comportamiento del sistema. 3. Construir diagramas de actividades para flujo mostrar flujos de control. 4. Preparar diagramas de secuencia para cada escenario. 5. Construir diagramas de estado para objetos con comportamiento. 36 6

7 Preparar Escenarios Identificar diálogos entre usuarios y el sistema Diagramas de Secuencias del Sistema. Considerar primero los escenarios para casos normales (camino básico). Luego considerar casos especiales (errores, condiciones límites, cancelar, pedido de ayuda). Examinar los escenarios para identificar eventos externos: señales, interrupciones, etc. Distinguir aquellos eventos que afectan el flujo de control. Interacción entre objetos Las interacciones entre objetos se modelan usando Diagramas de Secuencias o de Comunicación. Estos diagramas destacan el intercambio de mensajes y las operaciones requeridas a los objetos. Los diagramas de secuencia resaltan el orden temporal, mientras que los diagramas de comunicación las colaboraciones entres ellos. Existe un diagrama de secuencia/comunicación por escenario, esto es, estos diagramas modelan el intercambio de mensajes para una ejecución particular Diagramas de Estado Los Diagramas de Estados se construyen para cada tipo de elemento con comportamiento significativo. En estos diagramas se muestran los eventos que los objetos de la clase envían y/o reciben. Para la clase a modelar se identifican clases de eventos y estados y luego se modela el patrón de comportamiento. Un Diagrama de Estados cubre todos los escenarios por los que puede pasar un objeto del tipo que modela. Diagrama de Actividades Los diagramas de actividades se usan para representan flujos de control de una actividad. Modelan patrones de flujo para la actividad. Los DA evolucionaron en Modelos de Proceso de Negocio (BPM).Un BPM modela flujos de trabajo de un negocio (workflow). Los DA a mayor nivel de detalle modelan los flujos control de una operación Balanceo entre el Modelo Estático y el Modelo Dinámico La estructura del MD está relacionada y restringida por el MO. Un objeto puede tener distintos estados a lo largo del tiempo, pero no puede pertenecer a distintas clases (preserva identidad). Diferencias internas entre objetos se modelan como clases distintas en el MO. Mientras que diferencias temporales se modelan apropiadamente como estados distintos de la misma clase en el MD. Si dos objetos se intercambian mensajes en el modelo dinámico, en el modelo estático deben estar relacionados. Resumen de las Metodologías Vistas Las metodologías proveen una aproximación segura para resolver un problema, preseleccionando los métodos y técnicas a ser usadas. 41 7

8 Principios de Ingeniería de Software Principios enunciados generales y abstractos que describen las propiedades deseables de los procesos y productos de software. Para aplicar los principios se requieren; Métodos: guías generales que gobiernan la ejecución de alguna actividad. Son aproximaciones rigurosas, semánticas y disciplinadas. Técnicas: guías más técnicas y mecánicas que los métodos. Principios de Ingeniería de Software... Las metodologías proveen una aproximación segura para resolver un problema, preseleccionando los métodos y técnicas a ser usadas. Metodología = métodos + técnicas Herramientas: son desarrolladas para soportar la aplicación de técnicas, métodos y metodologías Ingeniería de Software - Principios Herramientas Metodología Métodos y Técnicas Principios de IS Análisis Estructurado También se lo conoce como análisis clásico. Surge alrededor de los 70. Los investigadores (principales De Marco, Yourdon) buscaron y desarrollaron una notación gráfica para representar datos y procesos de transformación. El método propuesto se centraba en aplicaciones para sistemas de información y no proporciona una notación adecuada para aspectos de control y comportamiento de los problemas Funcionalidad Datos Comportamiento Modelos de Análisis Estructurado Diagrama de Flujo de Datos Descripción Estructurada de Procesos. Diagrama Entidad-Relación Modelo Relacional Normalización Diagrama de transición de estados. Especificación de control Diccio nario de Datos Análisis Orientado a Objetos Si bien su gestación es anterior, triunfan alrededor de los 90 junto con los lenguajes OO. Se basa en identificar objetos y atributos, clases y miembros, todos y partes. Durante el análisis: Se modela el dominio de información, se describe la función, se representa el comportamiento. Se divide en vista del usuario, de estructura o datos y de comportamiento. Los modelos evolucionan para mostrar mayor nivel de detalle. Los modelos se refinan durante el ciclo de vida del producto a desarrollar hasta la implementación

9 Modelos de Análisis OO Temas de la Clase de Hoy De dominio Análisis Detallado y Diseño Vista del Usuario: diagrama de casos de uso y descripción informal. Vista de Datos: conceptos de negocio. Vista de Comportamiento: escenarios y secuencia del sistema. Vista funcional: evolución del diagrama de casos de uso usando include y extend, descripciones rigurosas (tablas, idioma estructurado, diagramas de actividad) Vista de datos: diagrama de clases del dominio, diagrama de objetos, clases del diseño. Vista del comportamiento: escenarios, diagramas de secuencia, de colaboración, de estados y actividad. Glosario Dicciona rio de Datos Modelo Dinámico Diagrama de actividades: repaso, calles y referencias a objetos. Revisión general del modelo dinámico. Ingeniería de Software Revisión de los estilos de análisis clásico y orientado a objetos. Bibliografía The Unified Modeling Language Booch, Rumbaugh & Jacobson. Object Oriented Modeling and Design with UML Capítulo 5, 6 y 7. Fundamentals of Software Engineering C. Ghezzy. Capítulo 7. Ingeniería del Software Un enfoque Práctico. R. Pressman