Presentaci

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

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

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

4
Documentos de entrada y salida

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

5
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,

6
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

7
Diagrama de clase (I)

• Conceptos
• Asociaciones
• Atributos
• Operaciones
• Generalización
• Reglas de restricción

8
Diagrama de clase (II)
9
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.

10
Diagrama de clase (IV) clasificación múltiple
11
Diagrama de clase (V) clasificación dinámica
12
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.

13
Diagrama de clase (VII) interfaces y clases
abstractas
14
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

15
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)

16
Diagrama de secuencia

• Conceptos
• Procesos concurrentes
• Activaciones

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

18
Diagrama de paquetes

• Poco más se puede decir.

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

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

• Concepto
• Swimlanes

22
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

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

24
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)

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

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

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

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

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

30
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).

31
Ejemplo de actividades
32
Patrones de Diseño
33
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.

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