DEPARTAMENTO DE INGENIERÍA INFORMÁTICA 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA

Contenidos Introducción Artefactos Diagramas UML a utilizar Actividades de Diseño

Introducción Modelado del sistema de manera que cumpla todos los requerimientos para: Adquirir una comprensión exhaustiva de todos los términos del proyecto. Requerimientos funcionales Requerimientos no funcionales -eficiencia, lenguajes de programación, etc.- Punto de partida para la implementación (abstracción). Descomposición del trabajo de implementación en piezas más manejables y posiblemente de manera concurrente. Obtención de interfaces entre los diferentes subsistemas lo más pronto posible. Crear una abstracción final de la aplicación. Los detalles pueden cambiar, la estructura no.

Documentos de entrada y salida Modelo de casos de uso. Documento de análisis. Documentos de salida: Documento de diseño.

Artefactos: clases de diseño Abstracción de una clase o construcción similar en la implementación del sistema. Se especifican los atributos que después se implementarán. Se especifica la visibilidad de esos atributos. Las relaciones entre las diferentes clases. Métodos que tiene esa clase con sus argumentos, valores de retorno y excepciones. Puede haber detalles que se dejen para el flujo de implementación. Se utiliza el concepto de “estereotipo”, que da información adicional sobre la clase: “form”, “user control”, “interface”, …

Diagramas UML a utilizar Diagrama de clase Diagramas de interacción Diagrama de secuencia Diagrama de colaboración Diagrama de paquetes Diagrama de estado Diagrama de actividad

Diagrama de clase (I) Conceptos: Asociaciones Atributos Operaciones Generalización Reglas de restricción

Diagrama de clase (II)

Diagrama de clase (III) Conceptos: Estereotipos. Clasificación múltiple y dinámica. Agregación y composición. Interfaces y clases abstractas. Roles multivaluados. Concepto “frozen”. Clasificación y generalización. Asociaciones cualificadas. Visibilidad.

Diagrama de clase (IV): clasificación múltiple Clasificación múltiple: permitir que un objeto pueda tener muchos tipos diferentes, sin especificar la definición de esos tipos para todas las combinaciones posibles. En el ejemplo se ve cómo una persona puede ser {female, patient, physioterapist} ó {male, family doctor}

Diagrama de clase (V): clasificación dinámica Esto permite a los objetos cambiar su tipo dentro de la estructura. Útil para el modelado conceptual. Se basa en la misma idea de los patrones de comportamiento -utilización de una misma interfaz con diferentes implementaciones de manera que una variación de estado implica una variación de comportamiento sin variación de interfaz-.

Diagrama de clase (VI): agregación y composición Agregación: relación “parte-de”. No hay consenso entre los gurús. Composición: el objeto “parte” sólo puede pertenecer a un “todo”.

Diagrama de clase (VII): interfaces y clases abstractas

Diagrama de clases (VIII): clasificación y generalización 1. Justo es Profesor 2. Los Profesores son Personas 3. Las Personas son Animales 4. Profesor es un Trabajo 1 y 2: Justo es una Persona 2 y 3: Los Profesores son Animales 1 y 4: Justo es un Trabajo ¿¿¿¿???? Clasificación: un objeto es una instancia de un tipo. 1, 2 Generalización: un tipo es un subtipo de otro quizá 2, 3, 4

Diagrama de clases (y IX): visibilidad Básicamente: public: visibilidad absoluta private: visibilidad sólo en la propia clase. Protected: visibilidad en la propia clase y subclases. Desgraciadamente, diferentes lenguajes utilizan definiciones diferentes para cada concepto: C++ Smalltalk Java (añade package visibility)

Diagrama de secuencia Conceptos: Procesos concurrentes Activaciones

Diagrama de colaboración: comparación con d. secuencia Redundancia: el d. Secuencia enfatiza la secuencia de acontecimientos. Colaboración: indica la conexión estática entre objetos. Comportamiento condicional: Es mejor separar diagramas para cada escenario. Existe mucha sintaxis adicional para ambos diagramas, pero no se aconseja su utilización a menos que sea necesario, ya que lo importante de estos diagramas es aclarar.

Diagrama de paquetes Poco más se puede decir.

Diagrama de estados (I) Recordemos: se utilizan para describir el comportamiento de un objeto dentro de varios casos de uso. Conceptos: Estados concurrentes. El objeto no debe tener muchos estados concurrentes; si es así, puede merecer la pena dividir el objeto en varios.

Diagrama de estados (y II): autorización de pagos Cancelled VISA Authority Authorized Delivered ID Check ID Clear ID Call Police

Diagrama de actividad Concepto: Swimlanes

Actividades de diseño Diseño de la arquitectura Diseño de un caso de uso Diseño de una clase Diseño de un subsistema

Actividad: Diseño de la arquitectura (I) Actividad realizada por el arquitecto. Proceso de definición de la colección de componentes del sistema y sus interfaces, para determinar el marco de referencia que guiará la construcción del sistema. Identificar nodos y sus configuraciones de red. Identificar la arquitectura hardware y de comunicaciones. Identificar subsistemas y sus interfaces Los paquetes de análisis y de servicio identificados en análisis pueden ser una buena guía para identificar subsistemas. Identificar el software de “middleware” y básico del sistema. Cuidado: no escoger soluciones excesivamente cerradas. Dependencias entre subsistemas.

Actividad: Diseño de la Arquitectura (y II) Identificar las clases de diseño relevantes arquitecturalmente La mayoría de las clases de diseño aparecerán al diseñar casos de uso. Es útil identificar al comienzo de esta fase las más obvias. Identificar Mecanismos Genéricos de Diseño Temas genéricos como: persistencia, distribución transparente de objetos, características de seguridad, detección y recuperación de errores y manejo de transacciones. Identificar “colaboraciones genéricas”: especificar una manera genérica de resolver un cierto tipo de situación que se presenta de manera recurrente en los casos de uso (generalmente: clases abstractas)

Actividad: Diseño de un caso de uso (I) Actividad desarrollada por el ingeniero de casos de uso. Los objetivos de diseñar un caso de uso son: Identificar las clases y subsistemas de diseño cuyas instancias son necesarias para realizar el caso de uso. Distribuir el comportamiento del caso de uso entre las clases o subsistemas de diseño. Definir requerimientos en las operaciones e interfaces de las clases y subsistemas. Capturar los requerimientos de implementación para el caso de uso.

Actividad: Diseño de un caso de uso (y II) Identificar clases y/o subsistemas de diseño Describir interacciones de los objetos de diseño y cómo se distribuyen la realización del caso de uso Puede realizarse si se ve necesario utilizando diagramas de secuencia. En este caso el nivel de detalle es total, ya que se detallan los mensajes entre objetos mediante invocaciones de operaciones de las interfaces de dichos objetos. Los diagramas de secuencia pueden complementarse con una descripción textual.

Actividad: Diseño de una clase (I) Actividad llevada a cabo por el ingeniero de componentes. Incluye diseñar: Operaciones (métodos) Atributos Relaciones en las que participa Sus estados. Dependencias con los mecanismos genéricos de diseño (persistencia, transacciones, seguridad, etc.) Requerimientos relevantes para su implementación. Asegurarse de que proporciona los interfaces que debe.

Actividad: Diseño de una clase (II) Delinear la clase de diseño Diseñar clases de interfaz es dependiente en la tecnología concreta a utilizar para su implementación. Diseñar clases entidad puede requerir implementar mecanismos de persistencia a Bases de datos, etc. Al diseñar clases de control debe tenerse en cuenta: Posible distribución de las tareas Eficiencia. Operaciones transaccionales. Identificar operaciones Las operaciones de una clase deben soportar todos sus roles en las diferentes realizaciones de casos de uso.

Actividad: Diseño de una clase (y III) Identificar atributos Identificar asociaciones y agregaciones Las interacciones de la clase con otras en las realizaciones de casos de uso a menudo requerirán relaciones entre dichas clases. Hay que tratar de minimizar las relaciones pero también de construir estructuras de navegabilidad entre clases que sea eficiente. Describir métodos Indicar el algoritmo a utilizar o dar indicaciones sobre el mismo. Describir estados Si se considera necesario, puede hacerse un diagrama de estados.

Actividad: Diseño de un subsistema Actividad desarrollada por el ingeniero de componentes. Objetivos: Asegurarse de que el subsistema es tan independiente como es posible de otros (mantener las dependencias entre subsistemas) Asegurarse de que proporciona las interfaces correctas (las suficientes para realizar todos sus roles en todos los casos de uso en los que participa). Asegurarse de que realiza correctamente sus operaciones (ver que las clases contenidas en el subsistema pueden realizar las operaciones del interfaz del subsistema).

Ejemplo de actividades

Patrones de Diseño

Métricas de diseño Cohesión: Acoplamiento: Medida de la relación funcional de los elementos de un módulo. Objetivo: alto grado de cohesión: Menor coste de programación Mayor calidad del proyectco. Acoplamiento: Medida de la interconexión entre los módulos de un programa. Objetivo: bajo acoplamiento: Minimización del efecto onda. Minimización del riesgo al cambiar un módulo por otro. Facilitar el entendimiento.

Bibliografía Libros: Enlaces: The Unified Modeling Language User Guide. Booch, G., Rumbaugh, J., Jacobson, I. Rational Software Corporation. Ed. Addison-Wesley. ISBN: Design Patterns. Elements of Reusable Object-Oriented Software. Gamma, E., Helm, R., Johnson, R., Vlissides, J. Ed. Addison-Wesley. ISBN: Enlaces: www.martinfowler.com http://www.cs.wustl.edu/~schmidt/patterns.html: página de Douglas C. Schmidt sobre patrones.