introducción a la ingeniería

Vista previa del material en texto

Introducción a la Ingeniería de 
Software
Diseño
• Software Engineering 7ed 
Addison Wesley
Ian Sommerville
2
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
3
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?
4
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 
para 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?
5
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 (o técnicas)
• Si se logra manejar la complejidad
� Se reducen los costos del diseño
� Se reduce la posibilidad de introducir defectos 
durante el diseño
6
Principios de Diseño
• Algunos principios de diseño a tener en cuenta:
� Dividir y conquistar ( D&C)
� Abstracción
� Modularidad
7
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
8
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
9
Dividir y Conquistar (3)
• ¿De qué sirve lograr la mayor cantidad de 
piezas independientes respecto a otras?
10
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?
11
Modularidad
• Un sistema se considera modular si
� El sistema consiste de componentes
� se pueden implementar por separado
� el cambio en una tiene mínimo impacto en otras 
componentes
• La modularidad es donde se juntan la 
abstracción y la partición
Diseño
Diseño Orientado a Objetos
13
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.
Se considera dado y conocido
14
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?
15
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
� Provee estructuras que son útiles para pensar y 
poder hacer abstracciones
16
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)
Abierto a la extensión pero cerrado a la modificación. 
Información coherente y relacionada a la clase
Menor impacto en modificaciones
La idea es tenerlos claros para usarlos, poder “medirlos” y 
saber como se afecta cada factor de calidad.
17
Acoplamiento
• Captura la fuerza de interconexión entre 
módulos
• Cuánto más acoplados más dependientes entre 
sí
� 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
� Qué tan compleja 
� Y explícita es esta información
La menor posible
Simple
Fácilmente visible o 
identificable
18
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
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 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
20
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
21
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
22
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
23
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
24
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
25
UML – Diagrama de Clases (2)
26
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)
27
UML – Diagrama de Paquetes
• Permite agrupar otros elementos de UML
• Mecanismo de agrupación
28
UML - Componentes
• Piezas independientes
• Estas piezas es bueno que sean actualizables 
(upgradeable)
29
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
30
UML – Despliegue (2)
31
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
32
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
• ¿Siempre se hace un diseño completo?
� Ventajas..
� Desventajas..
33
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
34
Medidas de Diseños OO (2)
• Estas métricas y otras predicen de una manera 
“bastante” buena las clases con más defectos
� 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.
35
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
36
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
• A 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