Introduccin a la Ingeniera de Software

Diseo

Bibliografa
An Integrated Approach to Software Engineering 3ed Springer Pankaj Jalote Captulos 6 (no completo) y 7 Software Engineering 7ed Addison Wesley Ian Sommerville

Diseo
Durante el diseo se refina la arquitectura El diseo es un plano de una solucin para el sistema Diseo Orientado a Objetos y Diseo Orientado a Funciones

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

El Diseo Debe Ser

Un diseo claramente debe ser:
Verificable Completo (implementa toda la especificacin) Rastreable. Se puede rastrear hacia los requerimientos que disea (traceable)

Sin embargo, las dos cosas ms importantes concernientes a los diseadores es que el diseo sea:
Eficiente Simple Por qu?
Estas dos propiedades estn normalmente encontradas. Soluciones de compromiso. Y normalmente, por cul se inclinaran?
5

La Tarea de Diseo
Crear un diseo simple y eficiente de un sistema grande puede ser una tarea extremadamente compleja
Actividad bsicamente creativa No puede reducirse a una serie de pasos a seguir Sin embargo, se pueden dar guas

Si se logra manejar la complejidad

Se reducen los costos del diseo Se reduce la posibilidad de introducir defectos durante el diseo
6

Principios de Diseo
Algunos principios de diseo a tener en cuenta:
Dividir y conquistar Abstraccin

Modularidad

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 monoltica
Aplicar dividir y conquistar Dividir en piezas que pueden ser conquistadas por separado. Sino se hizo una divisin poco inteligente

Dividir en piezas con esta propiedad es una tarea compleja para el diseo de software
8

Dividir y Conquistar (2)

Las piezas
Estn relacionadas. Juntas forman el sistema Entonces, existe comunicacin y cooperacin entre las mismas Esto agrega complejidad, que surge de la propia particin Cuando el costo de particionar sumado la complejidad agregada supera los ahorros logrados por particionar se debe detener el proceso

Dividir y Conquistar (3)

De qu sirve lograr la mayor cantidad de piezas independientes respecto a otras?

10

Abstraccin
Permite al diseador considerar una componente a un cierto nivel de abstraccin sin preocuparse por los detalles de implementacin de dicha componente
Se describe el comportamiento exterior sin describir los detalles internos

Cmo se relaciona con el proceso de particin?

11

Modularidad
Un sistema se considera modular si
El sistema consiste de componentes y estas se pueden implementar separadamente y el cambio en una tiene mnimos impactos en otras componentes

La modularidad es donde se juntan la abstraccin y la particin

12

Diseo
Diseo Orientado a Objetos

Orientacin a Objetos
Clases y objetos Diagramas de clases Diagramas de interaccin entre objetos Patrones de diseo Herencia, polimorfismo, sobrecarga de operadores Etc.

PROGRAMACIN 4

Se considera dado y conocido

Repasemos. Qu me pueden decir de diseo OO?
14

Diseo en Relacin a la Arquitectura de Software

Preservar la arquitectura durante el diseo Diseo de componentes por distintos grupos de personas
Qu hay que tener en cuenta?

Diseo de casos de uso por distintos grupos de personas

Qu hay que tener en cuenta?

15

Ventajas de Sistemas OO
Un modelo OO representa bastante el domino del problema
Esto facilita el entendimiento del diseo

Es ms sencillo impactar cambios en los requerimientos (comparado con otros enfoques) Facilita la reutilizacin Se cree que este enfoque es ms natural
Entonces, provee estructuras ms ricas para pensar y poder hacer abstracciones

16

Conceptos de Diseo
Tres conceptos claves para la calidad de un diseo (adems de ser correcto, claro)
Acoplamiento (bajo) Cohesin (alta) Principio abierto-cerrado (cumplir con el principio)

17

Acoplamiento
Captura la fuerza de interconexin entre mdulos Cunto ms acoplados ms dependientes entre si
Entonces, ms difcil comprenderlos y modificarlos

El grado de acoplamiento entre mdulos depende de:

Cunta informacin se necesita sobre el otro mdulo para entenderlo La menor posible Y qu tan compleja Simple Y explcita es esta informacin Fcilmente visible o
identificable
18

Tipos de Acoplamiento
Interaccin
Mtodos de una clase que invocan a mtodos de otra clase La peor forma es si se interacta con partes internas del mtodo La del medio es si se accede directamente a atributos del objeto La menor es si se accede al mtodo mediante intercambio de parmetros

19

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 mtodo que recibe como parmetro otra clase Existe un mtodo con una variable local de otra clase. Esta es la menos deseada

Herencia

20

Cohesin
Se focaliza en conocer porqu los elementos de un mdulo estn juntos en ese mdulo El objetivo es tener en un mismo mdulo elementos que estn fuertemente vinculados
Entonces, mdulos ms fciles de entender y ms fciles de modificar

21

Tipos de Cohesin
Sin entrar en mucho detalle Mtodo
Ms alta cohesin cuando el mtodo implementa una nica funcin claramente definida y todas las sentencias contribuyen a esa funcin

Clase
Se focaliza en porqu distintos atributos y mtodos estn en una misma clase Una clase implementando un nico concepto o abstraccin Y todos sus elementos contribuyendo a soportar ese concepto o abstraccin
22

Tipos de Cohesin (2)

Herencia
Se focaliza en conocer porqu las clases estn agrupadas en una jerarqua Se considera que la cohesin es baja si la jerarqua es usada slo por reuso de cdigo y no existe una relacin de generalizacinespecializacin

23

Principio Abierto-Cerrado
Objetivo (otra vez): promover la construccin de sistemas que sean fciles de modificar Mdulos abiertos para la extensin
El comportamiento puede ser extendido

Mdulos cerrados para la modificacin

Extremo: cuando se hacen mejoras no es necesario tocar el cdigo existente La interfaz no debe cambiar y se debe asegurar que se mantiene el comportamiento
24

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 cdigo de esa clase

Cliente Cliente Impresora 1

Impresora

Impresora 1

Impresora 2

25

UML Diagrama de Clases

Parte central del diseo Relacin muy cercana con el cdigo final
Herramientas que generan el esqueleto del cdigo de forma automtica
Se evitan defectos propios de la conversin manual

Se describen
Clases (nombre, atributos, mtodos) Asociaciones entre clases Relaciones de herencia

26

UML Diagrama de Clases (2)

27

UML Secuencia y Colaboracin

Comportamiento dinmico del sistema Muestra las interacciones entre los objetos para cumplir con cierta funcionalidad (normalmente un Caso de Uso)

28

UML Diagrama de Paquetes

Permite agrupar otros elementos de UML Mecanismo de agrupacin

29

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

30

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 ejecucin Representa software que aloja otro software

Dentro se pone lo que se despliega en ese nodo Nodos que se comunican se representa mediante lneas
31

UML Despliegue (2)

32

Metodologa de Diseo
Existen varias
Siempre es una actividad creativa por lo que no es un conjunto de pasos que mgicamente produce un diseo

Se asume que:
Durante el diseo de la arquitectura se parti el sistema en varios subsistemas Se va a producir un diseo orientado a objetos

Entonces, el problema que se ataca es cmo producir un diseo orientado a objetos de un subsistema
33

Metodologa de Diseo (2)

Un DOO completo es tal que en la fase de implementacin slo se agregan detalles
La mayora de las clases y sus relaciones se identifican durante el diseo

Ustedes cmo disean?

34

Medidas de Diseos OO
Algunas medidas para evaluar la calidad y complejidad de diseos OO

S. R. Chidamber and C. F. Kemerer. A metrics suite for object-oriented design. IEEE Transactions on Software Engineering, June 1994 35

Medidas de Diseos OO (2)

36

Medidas de Diseos OO (3)

37

Medidas de Diseos OO (4)

Estas mtricas predicen de una manera bastante buena las clases con ms 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.
38

Frameworks (Marcos de Trabajo)

Abstracciones de mayor granularidad que los objetos Coleccin de clases abstractas y concretas Es un subsistema reusable y semi-completo
Que puede ser extendido un subsistema especfico o una aplicacin

Forma de extensin
Escribir clases concretas de clases abstractas del Framework Escribir mtodos que sern llamados por eventos o estados reconocidos por el Framework (callbacks)

Tienen asociada una curva de aprendizaje alta

39

Frameworks (2)
aplicacin biblioteca Framework

aplicacin

biblioteca Biblioteca de Clases

40

Desarrollo Basado en Componentes

Surgimiento a fines de los 90
originado por el no cumplimiento de las expectativas de reutilizacin que haba prometido el desarrollo OO, debido a: Clases demasiado detalladas, especficas y ligadas a las aplicaciones Muchas veces haca necesario disponer del cdigo fuente => dificultades en comercializacin

Visin de componente: proveedor de servicios

Entidad ejecutable e independiente Publica la interfaz de servicios suministrados y las interacciones son a travs de sta Generalmente tambin define interfaz de servicios que debe proveer el sistema que lo utiliza
41