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 13 Modelo Funcional Metodologías Orientadas a Objetos Lic. María Mercedes Vitturini [mvitturi@cs.uns.edu.ar] 1er. CUATRIMESTRE 2006 Modelo Funcional El Modelo Funcional describe los cálculos dentro de un sistema. El Modelo de Objetos describe a quién le pasa... El Modelo Dinámico describe cuándo pasa... El Modelo Funcional describe qué pasa... El MF especifica el significado de las operaciones del MO, y de las acciones y actividades del MD. También especifica el significado de las restricciones del MO. Análisis y Diseño de Sistemas - Clase 13 2 Diagrama de Flujos de Datos En un DFD no se muestra información de control. Ejemplo: La hora en que se debe ejecutar el proceso. Decisiones entre caminos alternativos. Contiene procesos que transforman datos, flujos de datos que transportan datos, objetos actores que producen y consumen datos y objetos almacenamiento de datos que mantienen pasivamente datos. Análisis y Diseño de Sistemas - Clase 13 3 Diagramas de Flujos de Datos El Modelo Funcional esta formado por múltiples Diagramas de Flujos de Datos (DFD). Un DFD muestra las relaciones funcionales de los valores calculados por un sistema, incluyendo los valores de entrada (input), valores de salida (output) y de los valores almacenados. Un DFD es un grafo que muestra el flujo de los valores de los datos, desde su fuente en objetos, a través de procesos que los transforman a sus destinos, en otros objetos. Análisis y Diseño de Sistemas - Clase 13 4 Diagrama de Flujo de Datos - Componentes Procesos: transforman los datos. Flujos de Datos: cañerías por donde fluyen los datos Objetos actores: objetos que producen o consumen los datos. Actor dato x Proceso P1 Almacenamientos: objetos que almacenan pasivamente. almacenamiento Análisis y Diseño de Sistemas - Clase 13 5 DFD - Procesos Proceso P1 Los procesos transforman los valores de los datos de entrada a valores de datos de salida. Los procesos se dibujan con una elipse con un nombre. El nombre debe ser descriptivo de la transformación que realiza. Los procesos tienen un número fijo de flujos de entrada y salida. Los flujos de entrada y salida de un proceso se pueden nombrar para mostrar su rol en el cálculo. Estos flujos transportan información de un determinado tipo. Análisis y Diseño de Sistemas - Clase 13 6 Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 1

2 DFD - Procesos El DFD muestra el patrón de flujos de entrada y salida. También se debe especificar el cálculo. La especificación depende del tipo de proceso: Un proceso de alto nivel puede ser expandido en procesos de menor nivel o DFD de próximo nivel. Los procesos atómicos deben ser descriptos en lenguaje natural, pseudo-código, relaciones matemáticas, etc. Los procesos son implementados como métodos (o fragmentos de métodos) de operaciones de clases. Ejemplos de Procesos dividendo divisor Calcular División Entera elemento cociente resto Calcular Peso TABLA PERIÓDICA peso atómico Análisis y Diseño de Sistemas - Clase 13 7 Análisis y Diseño de Sistemas - Clase 13 8 DFD - Flujos de Datos Los flujos de datos conectan la salida de un objeto o proceso a la entrada de un objeto o proceso. Representan un valor intermedio dentro de un cálculo. El valor no se modifica por el flujo. Notación: nombre El mismo flujo a distintos consumidores dato x Ejemplos Flujos de Datos hh:mm hh mm Mostrar Hora Mostrar Minutos ventana Maximizar Ventana Un dato agregado a distintos componentes apellido_nombre apellido nombre Análisis y Diseño de Sistemas - Clase 13 9 Desplazar Ventan Análisis y Diseño de Sistemas - Clase Actores Actor Un actor es un objeto activo que conduce el grafo de flujo de datos produciendo o consumiendo valores. Los actores están apoyados en los límites del diagrama. Dado que terminan el diagrama como fuentes o receptores de los datos, también se los llama terminadores. Las flechas entre el actor y el diagrama representan las entradas y salidas del sistema. Almacenamiento de Datos Un almacenamiento de datos es un objeto pasivo dentro del DFD que almacena datos para su uso posterior. A diferencia de un actor, no genera ninguna operación por sí mismo. Sólo responde a los requerimientos de almacenar o acceder a datos. Permite que los datos sean accedidos en distinto orden en el que fueron generados. Notación: almacenamiento almacenamiento Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 2

3 Almacenamiento de Datos... Las flechas (flujos) de entrada indican escritura, información u operaciones que modifican los datos almacenados. Esto incluye agregar elementos, modificar valores o eliminar elementos. almacenamiento Las flechas (flujos) de salida indican lectura, información que se extrae del almacenamiento. Incluye recuperar un valor completo o alguna componente. almacenamiento Análisis y Diseño de Sistemas - Clase Diagramas de Flujo Anidados El DFD es útil para mostrar funcionalidad de alto nivel de un sistema y partirlo en unidades funcionales más pequeñas. Un proceso se puede expandir en un nuevo diagrama. Esto puede incluir almacenamientos que no se mostraban en un nivel superior. Los diagramas pueden ser anidados a cualquier profundidad. El conjunto completo forma un árbol. El anidamiento de los diagramas termina en funciones simples. Estas funciones se deben especificar como operaciones. Análisis y Diseño de Sistemas - Clase Ejemplo Ejemplo DFD Registrar Reserva Análisis y Diseño de Sistemas - Clase DFD Anidado Registrar Reserva Análisis y Diseño de Sistemas - Clase Flujos de control El DFD muestra posibles caminos. No muestra cuál es el ejecutado, ni orden de ejecución. Muchas veces, una decisión afecta la ejecución de una o más funciones. Esto es útil marcarlo en el modelo funcional con un flujo de control. Flujo de control: es un valor booleano que afecta si un proceso es evaluado. No es un valor de input al proceso, en sí mismo. Notación: Ejercicio Propuesto Construir DFD para el proceso Cerrar Pedido del problema de restaurante. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 3

4 Especificar Operaciones Los procesos de menor nivel son operaciones implementadas en los objetos. Cada operación debe ser especificada usando: Funciones matemáticas Tablas de valores de entrada/salida Ecuaciones, que especifican salidas en término de entradas. Condiciones pre-post Tablas de decisión Pseudo-código Lenguaje natural La especificación de una operación incluye la signatura y la transformación. Análisis y Diseño de Sistemas - Clase Especificar Operaciones Operaciones triviales: son las de acceso a almacenamientos. Leen o graban valores de atributos y links. Las operaciones triviales no se especifican. Se debe decidir si son públicas o privadas. Las operaciones no triviales pueden ser: Consultas. Acciones. Actividades. Análisis y Diseño de Sistemas - Clase Especificar Operaciones Consultas: No tienen efectos en el estado visible del objeto. Generalmente, se especifican con ecuaciones en términos de otros atributos, y no requieren componentes de control. Especificar Operaciones Acciones: Es una transformación que tiene efectos colaterales en el objeto destino, o en otros objetos alcanzados por el objeto destino. No tienen duración en el tiempo. Se pueden definir en términos de pre y post condiciones de estados (antes y después de ejecutar la acción). Otra forma de especificación puede ser mediante una ecuación o proveyendo el algoritmo. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Especificar Operaciones Actividades: Es una operación sobre o de un objeto que tiene duración en el tiempo. Inherentemente, tiene efectos colaterales (debido a su duración en el tiempo). Los detalles de una actividad se especifican en el modelo dinámico y funcional. Una actividad es más que una transformación. Análisis y Diseño de Sistemas - Clase Relaciones entre los modelos El modelo funcional muestra qué se debe hacer. Cada proceso es implementado por un método en algún objeto. El modelo dinámico muestra la secuencia en la cual suceden las operaciones. Las secuencias son implementadas como una secuencia, bucle, o secuencia alternativa de sentencias dentro de algún método. Los procesos en el modelo funcional corresponden a operaciones o partes de operaciones (métodos) en el modelo de objetos. Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 4

5 Modelo Funcional - Guías Se construye luego del MO y del MD Guía para su elaboración: 1. Identificar los valores de entrada y salida. 2. Construir el Diagrama de Flujo de Datos mostrando las relaciones funcionales. 3. Describir las funciones (qué hace y no cómo). 4. Identificar restricciones. 5. Especificar criterios de optimización. Metodología OO Resumen de las Metodologías Análisis y Diseño de Sistemas - Clase El Paradigma Orientado a Objetos Las tecnologías OO llevan a reutilizar. La reutilización de componentes de software lleva a desarrollos más rápidos y de mayor calidad. El software OO es más fácil de mantener gracias a su estructura poco acoplada. Los sistemas OO son más fáciles de adaptar y favorecen la escalabilidad. Análisis y Diseño de Sistemas - Clase El Paradigma Orientado a Objetos Se identifica con un modelo de proceso evolutivo acoplado con un enfoque que fomenta la reutilización de componentes. Consiste en: 1. Identificar clases candidatas. 2. Buscar clases en la biblioteca. 3. Extraer nuevas clases, si existen. 4. Desarrollar clases si no existen. 5. Añadir las nuevas clases a la biblioteca. 6. Construir n-ésima iteración del sistema. Análisis y Diseño de Sistemas - Clase Un modelo de proceso OO Análisis Orientado a Objetos Identificar clases candidatas Construir la n- ésima iteración del sistema Buscar clase en biblioteca Extraer nuevas clases si existen Para construir un modelo de análisis se necesitan seguir los siguientes principios: Modelar el dominio de la información. Describir las funciones. Representar el comportamiento. Dividir modelos para mostrar más detalles. Los modelos iniciales representan la esencia, y los modelos finales los detalles de implementación. Añadir las nuevas clases a la biblioteca Desarrollar las clases si no existen Análisis OO Diseño OO Programación OO Pruebas OO El propósito del AOO es definir las clases (las relaciones y el comportamiento) relevantes al problema. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 5

6 Análisis Orientado a Objetos La popularidad de las tecnologías de objetos han generado decenas de métodos de AOO. Cada metodología propone: Un proceso para el análisis de un producto o sistema. Un conjunto de modelos que evoluciona. Una notación, que permite al desarrollador crear cada modelo de manera consistente. Principales Metodologías OO Metodologías más conocidas Booch Coad - Yourdon Jacobson Rumbaugh Wirfs-Brock El proceso unificado (Booch Jacobson Rumbaugh) Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Método de Booch Abarca un micro-proceso de desarrollo y un macro-proceso de desarrollo. El nivel micro define un conjunto de tareas de análisis que se reaplican en cada etapa en el macro proceso. Por esto, mantiene un enfoque evolutivo. El Micro-Proceso Especificar interfaces e implementación entre clase y objetos Identificar clases y objetos Identificar relaciones entre clases y objetos Identificar semántica de clases y objetos Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Método de Booch El microproceso Identificar clases y objetos: Proponer objetos candidatos del dominio. Establecer los límites del problema. Identificar escenarios significativos. Definir atributos y operaciones para cada clase. Identificar la semántica de clases y objetos: Establecer el comportamiento. Seleccionar y analizar escenarios. Asignar responsabilidades para alcanzar el comportamiento deseado. Análisis y Diseño de Sistemas - Clase Método de Booch El microproceso Identificar relaciones entre clases: Producir diagramas para lo producido en pasos anteriores. Definir jerarquías adecuadas. Crear agrupamientos basados en clases. Implementar clases y objetos (complementar el modelo de análisis). Crear representaciones tangibles de las abstracciones. Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 6

7 El Macro-Proceso Gestionar la evolución tras la entrega (mantenimiento) Establecer los requisitos básicos Desplegar la implementación (evolución) Desarrollar un modelo del comportamiento deseado (análisis) Crear una arquitectura (diseño) Método de Booch El macroproceso Sirve como marco de referencia para controlar el micro-proceso. Se centra en el riesgo y la visión arquitectónica, elementos que afectan a la calidad y puntualidad. Dicta actividades para medir el riesgo. Incluye prácticas de gestión del software. Interesa a la dirección del equipo de desarrollo. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Método de Coad y Yourdon Se lo considera el método más sencillo de aprender. La notación es simple y las reglas para desarrollar el modelo son evidentes. Pasos: Identificar objetos usando el criterio qué buscar. Definir una estructura de generalizaciónespecialización. Definir una estructura de todo-parte. Identificar temas (componentes de subsistemas). Definir atributos. Método de Jacobson También llamado ISOO (Ingeniería de Software Orientada a Objetos). Es una versión simplificada de Objectory (método patentado por Jacobson). Se diferencia de otros métodos por la importancia que le da los casos de usos. Caso de uso: una descripción o escenario que describe cómo el usuario interactúa con el producto o sistema. Definir servicios. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Método de Jacobson Pasos de la metodología. Identificar usuarios y sus responsabilidades globales. Construir el modelo de requisitos: Definir los actores y sus responsabilidades. Identificar los casos de uso para cada actor. Preparar una visión inicial de los objetos del sistema y sus relaciones. Revisar el modelo usando los casos de uso como escenarios, para determinar su validez. Análisis y Diseño de Sistemas - Clase Método de Jacobson Construir el modelo de análisis: Identificar objetos de interfaz, usando información del tipo actor-interacción. Crear vistas estructurales de los objetos de interfaz. Representar el comportamiento del objeto. Aislar subsistemas y modelos para cada uno. Revisar el modelo usando los casos de uso como escenarios, para determinar su validez. Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 7

8 Método de Rumbaugh Rumbaugh y sus colegas desarrollaron OMT (Object Modelling Techniques) Crea tres modelos del análisis: Modelo de objetos: representación de objetos, clases, jerarquías, y relaciones. Modelo dinámico: representación del comportamiento del sistema y los objetos. Modelo funcional: representación del flujo de información a través del D.F.D. Método de Rumbaugh Desarrollar una declaración del ámbito del problema. Desarrollar un modelo de objetos: Identificar clases relevantes al problema. Definir atributos y asociaciones. Definir enlaces de objetos. Organizar las clases de objetos usando herencia. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Método de Rumbaugh Desarrollar un modelo dinámico: Preparar escenarios. Definir eventos y desarrollar una traza de eventos para cada escenario. Construir un diagrama de traza de eventos. Desarrollar un diagrama de estados. Revisar el comportamiento para comprobar consistencia y completitud. Método de Rumbaugh Desarrollar un modelo funcional: Identificar entradas y salidas. Usar diagramas de flujo para representar transformaciones del flujo. Desarrollar especificaciones de proceso para cada función. Especificar criterios de restricciones y optimización. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Método de Wirfs-Brock No hace distinción clara entre el análisis y el diseño. Las tareas propuestas son: Evaluar la especificación del cliente. Usar un análisis gramatical para extraer las clases candidatas de la especificación. Agrupar las clases en un intento de determinar superclases. Definir responsabilidades para cada clase. Asignar responsabilidades a cada clase. Identificar relaciones entre clases. Método de Wirfs-Brock Las tareas propuestas son (continuación): Definir colaboraciones entre clases basándose en sus responsabilidades. Construir representaciones jerárquicas de clases para mostrar relaciones de herencia. Construir un grafo de colaboraciones para el sistema. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 8

9 Análisis OO Aunque la terminología y etapas del proceso de cada uno de los métodos OO presentados difieren, los procesos generales son los mismos. Para realizar un AOO un ingeniero de SW debería seguir los siguientes pasos: Pasos Generales de AOO 1. Obtener los requisitos del cliente para el sistema. 2. Identificar escenarios o casos de uso. 3. Seleccionar clases y objetos usando requisitos básicos como guías. 4. Identificar atributos y operaciones para cada objeto del sistema. 5. Definir estructuras y jerarquías que organicen las clases. 6. Construir un modelo objeto-relación. 7. Construir un modelo objeto-comportamiento. 8. Revisar el modelo de análisis OO en relación a los casos de uso / escenarios. Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Proceso Unificado Un proceso o método de desarrollo deberá: Proporcionar una guía para ordenar las actividades de un equipo. Dirigir las tareas de cada desarrollador por separado, y del equipo como un todo. Especificar los artefactos que deben desarrollarse. Ofrecer criterios para el control y la medición de los productos y actividades del proyecto. Proceso Unificado El Proceso Unificado (PU) es un proceso de desarrollo de software. El Proceso Unificado está basado en componentes. El sistema está formado por componentes de software interconectadas vía interfaces. Componente: es una unidad de entrega independiente (parte física y reemplazable de un sistema) que provee cierta funcionalidad a través de interfaces. Interface: es un conjunto de operaciones que son utilizadas para especificar un servicio de una clase o de un componente Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Proceso Unificado El PU utiliza UML como lenguaje de especificación. Características distintivas del PU: Dirigido por casos de uso Centrado en la arquitectura Iterativo e incremental Dirigido por casos de uso Caso de Uso: es un fragmento de funcionalidad del sistema que le entrega al usuario un resultado importante. Los casos de uso representan los requisitos funcionales. Una especificación funcional contesta a la pregunta: Qué debe hacer el sistema? La estrategia de casos de uso le agrega...para cada usuario? Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 9

10 Dirigido por casos de uso Los casos de uso en este caso, guían el proceso de desarrollo (diseño, implementación y prueba), esto es, proveen el hilo conductor del desarrollo. Dirigido por CU: significa que el proceso avanza a través de una serie de flujos de trabajo que parten de los casos de uso. Los CU se desarrollan simultáneamente con la arquitectura del sistema. Los CU guían la arquitectura, y la arquitectura influye en la selección de los CU. Análisis y Diseño de Sistemas - Clase Centrado en la arquitectura La arquitectura se describe mediante diferentes vistas del sistema en construcción. Se ve influida por otros factores como: Plataforma en la que debe funcionar el software (sistema operativo, DBMS, protocolos de comunicación, etc) Bloques de construcción reusables, Sistemas legados, Requerimientos no funcionales,... Cada producto tiene una función y una forma. La función corresponde al caso de uso, y la forma a la arquitectura Análisis y Diseño de Sistemas - Clase Iterativo e Incremental Es práctico dividir el trabajo de desarrollo en partes más pequeñas o mini-proyectos. Cada mini-proyecto es una iteración que resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo. Los incrementos al crecimiento del producto. Para una efectividad máxima, las iteraciones deben ser controladas. Es decir, seleccionarse y ejecutarse de manera planificada. Análisis y Diseño de Sistemas - Clase Iterativo e Incremental En cada iteración: Los desarrolladores identifican y especifican los CU relevantes. Crean un diseño utilizando la arquitectura como guía. Implementan el diseño mediante componentes. Verifican que los componentes satisfacen los casos de uso. Si una iteración cumple con los objetivos, el desarrollo continua con la siguiente. Caso contrario, se deben revisar sus decisiones previas y probar con un nuevo enfoque. Análisis y Diseño de Sistemas - Clase Iterativo e Incremental Beneficios: Reduce los costos de los riesgos, a los costos de un solo incremento. La iteración controlada reduce el riesgo de no sacar al mercado el producto en el calendario previsto. Acelera el ritmo del esfuerzo de desarrollo. Reconoce la realidad de que los requerimientos del usuario no pueden definirse totalmente al inicio. La CV del proceso Unificado Nacimiento Iteración #1 V 1 V 2 V 3 V m Ciclo 1 Ciclo 2 Ciclo 3... Ciclo m La vida de un proceso consta de ciclos desde su nacimiento hasta su muerte Inicio Elaboración Construcción Iteración #2 Un ciclo con sus fases e iteraciones tiempo Iteración #n -1 Muerte Transición Iteración #n Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 10

11 El producto Cada ciclo produce una nueva versión del sistema y cada versión es un producto preparado para su entrega. El producto terminado no solo debe ajustarse a las necesidades del usuario, sino también a las del equipo de desarrollo. El producto terminado debe incluir: Componentes ejecutables. Casos de uso, especificaciones y casos de prueba. Modelos de la arquitectura. Modelos del Proceso Unificado Análisis y Diseño de Sistemas - Clase Análisis y Diseño de Sistemas - Clase Temas de la clase de hoy Modelo Funcional Elementos. Relación del MF con los otros modelos (MD y MO) Bibliografía Object Oriented Modeling and Design James Rumbaugh. Capítulo 6. Análisis Orientado a Objeto. Metodologías más conocidas Booch, Coad, Yourdon, Jacobson,Rumbaugh, Wirfs-Brock. El Método Unificado Bibliografía: Ingeniería de Software Un enfoque práctico Roger Pressman - Capítulo 21. El Proceso Unificado de Desarrollo de Software Jacobson, Booch, Rumbaugh Capítulo 1 Análisis y Diseño de Sistemas - Clase Temas de la clase de hoy Análisis Orientado a Objeto. Metodologías más conocidas Booch, Coad, Yourdon, Jacobson,Rumbaugh, Wirfs- Brock El Método Unificado. Bibliografía: Ingeniería de Software Un enfoque práctico RogerPressman - Capítulo 21. El Proceso Unificado de Desarrollo de Software Jacobson, Booch, Rumbaugh Capítulo 1. Análisis y Diseño de Sistemas - Clase Estas transparencias proveen sólo una referencia a los temas. Para su estudio debe remitirse a la bibliografía. 11