8.- flujo de diseño justo n. hidalgo sanz departamento de ingenierÍa informÁtica
TRANSCRIPT
8.- Flujo de Diseño8.- Flujo de DiseñoJusto N. Hidalgo SanzJusto N. Hidalgo Sanz
DEPARTAMENTO DE INGENIERÍA DEPARTAMENTO DE INGENIERÍA INFORMÁTICAINFORMÁTICA
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Contenidos
Introducción Artefactos Diagramas UML a utilizar Actividades de Diseño
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Documentos de entrada y salida
Documentos de entrada: Modelo de casos de uso. Documento de análisis.
Documentos de salida: Documento de diseño.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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”, …
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (I)
Conceptos: Asociaciones Atributos Operaciones Generalización Reglas de restricción
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (II)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (IV): clasificación múltiple
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (V): clasificación dinámica
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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”.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (VII): interfaces y clases abstractas
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de secuencia
Conceptos: Procesos concurrentes Activaciones
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de paquetes
Poco más se puede decir.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de estados (y II): autorización de pagos
VISA Authority Authorized
ID Check ID Clear
Cancelled
Delivered
ID Call Police
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de actividad
Concepto: Swimlanes
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
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).
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Ejemplo de actividades
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Patrones de Diseño
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Métricas de diseño
Cohesión: 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.
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Bibliografía
Libros: 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.