Introducción a la Ingeniería de Software Diseño

2 Bibliografía An Integrated Approach to Software Engineering 3ed Springer Pankaj Jalote Capítulos 6 (no completo) y 7 Software Engineering 7ed Addison Wesley Ian Sommerville

3 Diseño Durante el diseño se refina la arquitectura El diseño es un “plano” de una solución para el sistema Diseño Orientado a Objetos y Diseño Orientado a Funciones

4 Objetivos El diseño de un sistema es correcto si un sistema construido de acuerdo a ese diseño satisface los requerimientos del sistema Pero el objetivo del diseño no es encontrar el diseño correcto sino  Encontrar el mejor diseño posible  dentro de las limitaciones impuestas por los requerimientos, el ambiente físico del sistema y el ambiente social donde el mismo va a operar ¿otras limitaciones?

5 El Diseño Debe Ser Un diseño claramente debe ser:  Verificable  Completo (implementa toda la especificación)  “Rastreable”. Se puede rastrear hacia los requerimientos que diseña (“traceable”) Sin embargo, las dos cosas más importantes concernientes a los diseñadores es que el diseño sea:  Eficiente  Simple  ¿Por qué? Estas dos propiedades están normalmente encontradas. Soluciones de compromiso. Y normalmente, ¿por cuál se inclinarían?

6 La Tarea de Diseño Crear un diseño simple y eficiente de un sistema “grande” puede ser una tarea extremadamente compleja  Actividad básicamente creativa  No puede reducirse a una serie de pasos a seguir  Sin embargo, se pueden dar guías Si se logra manejar la complejidad  Se reducen los costos del diseño  Se reduce la posibilidad de introducir defectos durante el diseño

7 Principios de Diseño Algunos principios de diseño a tener en cuenta:  Dividir y conquistar  Abstracción  Modularidad

8 Dividir y Conquistar Debido a la complejidad de los grandes problemas y las limitaciones de la mente humana estos no se pueden atacar como una unidad monolítica  Aplicar dividir y conquistar  Dividir en piezas que pueden ser “conquistadas” por separado. Sino se hizo una división poco inteligente Dividir en piezas con esta propiedad es una tarea compleja para el diseño de software

9 Dividir y Conquistar (2) Las piezas  Están relacionadas. Juntas forman el sistema  Entonces, existe comunicación y cooperación entre las mismas  Esto agrega complejidad, que surge de la propia partición  Cuando el costo de particionar sumado la complejidad agregada supera los ahorros logrados por particionar se debe detener el proceso

10 Dividir y Conquistar (3) ¿De qué sirve lograr la mayor cantidad de piezas independientes respecto a otras?

11 Abstracción Permite al diseñador considerar una componente a un cierto nivel de abstracción sin preocuparse por los detalles de implementación de dicha componente  Se describe el comportamiento exterior sin describir los detalles internos ¿Cómo se relaciona con el proceso de partición?

12 Modularidad Un sistema se considera modular si  El sistema consiste de componentes  y estas se pueden implementar separadamente  y el cambio en una tiene mínimos impactos en otras componentes La modularidad es donde se juntan la abstracción y la partición

Diseño Diseño Orientado a Objetos

14 Orientación a Objetos Clases y objetos Diagramas de clases Diagramas de interacción entre objetos Patrones de diseño Herencia, polimorfismo, sobrecarga de operadores Etc. Repasemos. ¿Qué me pueden decir de diseño OO? PROGRAMACIÓN 4 Se considera dado y conocido

15 Diseño en Relación a la Arquitectura de Software Preservar la arquitectura durante el diseño Diseño de componentes por distintos grupos de personas  ¿Qué hay que tener en cuenta? Diseño de casos de uso por distintos grupos de personas  ¿Qué hay que tener en cuenta?

16 Ventajas de Sistemas OO Un modelo OO representa bastante el domino del problema  Esto facilita el entendimiento del diseño Es más sencillo impactar cambios en los requerimientos (comparado con otros enfoques) Facilita la reutilización Se cree que este enfoque es más natural  Entonces, provee estructuras más ricas para pensar y poder hacer abstracciones

17 Conceptos de Diseño Tres conceptos claves para la calidad de un diseño (además de ser correcto, claro)  Acoplamiento (bajo)  Cohesión (alta)  Principio abierto-cerrado (cumplir con el principio)

18 Acoplamiento Captura la fuerza de interconexión entre módulos Cuánto más acoplados más dependientes entre si  Entonces, más difícil comprenderlos y modificarlos El grado de acoplamiento entre módulos depende de:  Cuánta información se necesita sobre el otro módulo para entenderlo  Y qué tan compleja  Y explícita es esta información La menor posible Simple Fácilmente visible o identificable

19 Tipos de Acoplamiento Interacción  Métodos de una clase que invocan a métodos de otra clase  La peor forma es si se interactúa con partes internas del método  La del “medio” es si se accede directamente a atributos del objeto  La menor es si se accede al método mediante intercambio de parámetros

20 Tipos de Acoplamientos (2) Componente  Una clase tiene variables de otra clase  Tres formas: Existe un atributo de la clase que es de otra clase Existe un método que recibe como parámetro otra clase Existe un método con una variable local de otra clase. Esta es la menos deseada Herencia

21 Cohesión Se focaliza en conocer porqué los elementos de un módulo están juntos en ese módulo El objetivo es tener en un mismo módulo elementos que están fuertemente vinculados  Entonces, módulos más fáciles de entender  y más fáciles de modificar

22 Tipos de Cohesión Sin entrar en mucho detalle Método  Más alta cohesión cuando el método implementa una única función claramente definida  y todas las sentencias contribuyen a esa función Clase  Se focaliza en porqué distintos atributos y métodos están en una misma clase  Una clase implementando un único concepto o abstracción  Y todos sus elementos contribuyendo a soportar ese concepto o abstracción

23 Tipos de Cohesión (2) Herencia  Se focaliza en conocer porqué las clases están agrupadas en una jerarquía  Se considera que la cohesión es baja si la jerarquía es usada sólo por reuso de código  y no existe una relación de generalización- especialización

24 Principio Abierto-Cerrado Objetivo (otra vez): promover la construcción de sistemas que sean fáciles de modificar Módulos abiertos para la extensión  El comportamiento puede ser extendido Módulos cerrados para la modificación  Extremo: cuando se hacen mejoras no es necesario tocar el código existente  La interfaz no debe cambiar y se debe asegurar que se mantiene el comportamiento

25 Principio Abierto-Cerrado (2) En OO el principio se puede alcanzar con un buen uso de la herencia  Este permite extender una clase sin modificar el código de esa clase ClienteImpresora 1 ClienteImpresora Impresora 1Impresora 2

26 UML – Diagrama de Clases Parte central del diseño Relación muy cercana con el código final  Herramientas que generan el esqueleto del código de forma automática Se evitan defectos propios de la conversión manual Se describen  Clases (nombre, atributos, métodos)  Asociaciones entre clases  Relaciones de herencia

27 UML – Diagrama de Clases (2)

28 UML – Secuencia y Colaboración Comportamiento dinámico del sistema Muestra las interacciones entre los objetos para cumplir con cierta funcionalidad (normalmente un Caso de Uso)

29 UML – Diagrama de Paquetes Permite agrupar otros elementos de UML Mecanismo de agrupación

30 UML - Componentes Piezas independientes Estas piezas es bueno que sean actualizables (upgradeable)

31 UML - Despliegue Qué hardware usan los distintos elementos de software Nodo – Algo que puede alojar (host) software  Se identifica con un cubo  Dos tipos Dispositivo – Representa hardware Ambiente de ejecución – Representa software que aloja otro software  Dentro se pone lo que se despliega en ese nodo  Nodos que se comunican se representa mediante líneas

32 UML – Despliegue (2)

33 Metodología de Diseño Existen varias  Siempre es una actividad creativa por lo que no es un conjunto de pasos que mágicamente produce un diseño Se asume que:  Durante el diseño de la arquitectura se partió el sistema en varios subsistemas  Se va a producir un diseño orientado a objetos Entonces, el problema que se ataca es cómo producir un diseño orientado a objetos de un subsistema

34 Metodología de Diseño (2) Un DOO completo es tal que en la fase de implementación sólo se agregan detalles  La mayoría de las clases y sus relaciones se identifican durante el diseño ¿Ustedes cómo diseñan?

35 Medidas de Diseños OO Algunas medidas para evaluar la calidad y complejidad de diseños OO S. R. Chidamber and C. F. Kemerer. A metrics suite for object-oriented design. IEEE Transactions on Software Engineering, June 1994

36 Medidas de Diseños OO (2)

37 Medidas de Diseños OO (3)

38 Medidas de Diseños OO (4) Estas métricas predicen de una manera “bastante” buena las clases con más defectos  Todas menos esta  Esto se presenta en: V. R. Basili, L. Briand, and W. L. Melo. A validation of object-oriented design metrics as quality indicators. IEEE Transactions on Software Engineering, Oct 1996.

39 Frameworks (Marcos de Trabajo) Abstracciones de mayor granularidad que los objetos Colección de clases abstractas y concretas Es un subsistema reusable y semi-completo  Que puede ser extendido un subsistema específico o una aplicación Forma de extensión  Escribir clases concretas de clases abstractas del Framework  Escribir métodos que serán llamados por eventos o estados reconocidos por el Framework (callbacks) Tienen asociada una curva de aprendizaje alta

40 Frameworks (2) biblioteca aplicación Framework Biblioteca de Clases biblioteca aplicación

41 Desarrollo Basado en Componentes Surgimiento a fines de los ’90  originado por el no cumplimiento de las expectativas de reutilización que había prometido el desarrollo OO, debido a: Clases demasiado detalladas, específicas y ligadas a las aplicaciones Muchas veces hacía necesario disponer del código fuente => dificultades en comercialización Visión de componente: proveedor de servicios  Entidad ejecutable e independiente  Publica la interfaz de servicios suministrados y las interacciones son a través de ésta  Generalmente también define interfaz de servicios que debe proveer el sistema que lo utiliza