Post on 29-Jan-2016
transcript
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