8.- flujo de diseño justo n. hidalgo sanz departamento de ingenierÍa informÁtica
TRANSCRIPT
![Page 1: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/1.jpg)
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
![Page 2: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/2.jpg)
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
![Page 3: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/3.jpg)
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.
![Page 4: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/4.jpg)
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.
![Page 5: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/5.jpg)
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”, …
![Page 6: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/6.jpg)
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
![Page 7: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/7.jpg)
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
![Page 8: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/8.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (II)
![Page 9: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/9.jpg)
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.
![Page 10: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/10.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (IV): clasificación múltiple
![Page 11: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/11.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (V): clasificación dinámica
![Page 12: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/12.jpg)
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”.
![Page 13: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/13.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de clase (VII): interfaces y clases abstractas
![Page 14: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/14.jpg)
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
![Page 15: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/15.jpg)
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)
![Page 16: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/16.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de secuencia
Conceptos: Procesos concurrentes Activaciones
![Page 17: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/17.jpg)
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.
![Page 18: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/18.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de paquetes
Poco más se puede decir.
![Page 19: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/19.jpg)
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.
![Page 20: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/20.jpg)
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
![Page 21: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/21.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Diagrama de actividad
Concepto: Swimlanes
![Page 22: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/22.jpg)
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
![Page 23: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/23.jpg)
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.
![Page 24: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/24.jpg)
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)
![Page 25: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/25.jpg)
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.
![Page 26: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/26.jpg)
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.
![Page 27: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/27.jpg)
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.
![Page 28: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/28.jpg)
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.
![Page 29: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/29.jpg)
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.
![Page 30: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/30.jpg)
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).
![Page 31: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/31.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Ejemplo de actividades
![Page 32: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/32.jpg)
Escuela Politécnica Superior de IngenieríaDepartamento de Ingeniería Informática (DII)
Patrones de Diseño
![Page 33: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/33.jpg)
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.
![Page 34: 8.- Flujo de Diseño Justo N. Hidalgo Sanz DEPARTAMENTO DE INGENIERÍA INFORMÁTICA](https://reader036.vdocuments.pub/reader036/viewer/2022070417/5665b4281a28abb57c8f9d66/html5/thumbnails/34.jpg)
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.