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

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


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

Documentos de entrada: 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


Diagrama de clase (V): clasificación dinámica


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

VISA Authority Authorized

ID Check ID Clear

Cancelled

Delivered

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: 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: 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.

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

Documents

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