Introducción a la Ingeniería de Software

Diseño

2

Bibliografía• An Integrated Approach to Software Engineering 3ed

SpringerPankaj JaloteCapítulos 6 (no completo) y 7

• Software Engineering 7ed Addison WesleyIan 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

Cliente Impresora 1

Cliente Impresora

Impresora 1 Impresora 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