INGENERIA DE SOFWARE 2

1. DISEÑO DE COMPONENTES DE
SOFTWARE *
Ingeniería de Software II
1

2. Componente
 Bloque de construcción modular para software
de computadora
 “Una parte modular, entregable y reemplazable
de un sistema que encapsula su implementación
y expone un conjunto de interfaces” según la
OMG Unified Modeling Language Specification
 Se puede definir y usar componentes desde 3
puntos de vista:
 Orientado a Objetos
 “Convencional”
 Relacionado a procesos
2

3. Punto de vista orientado a
objetos
 Desde este punto de vista, un componente contiene un
conjunto de clases que colaboran entre sí.
 El diseño de un componente implica añadir a la
definición de clases en el análisis (dominio del
problema) información para su implementación en
software.
3

4. Ejemplo de elaboración de un
componente de diseño
4
[Pressman 2005]

5. Punto de vista
“convencional”
 Desde este punto de vista, un
componente es un elemento funcional
de un programa que incluye lógica de
procesamiento, estructuras de datos
internas requeridas para implementar
dicha lógica y una interfaz que
permite que el componente sea
invocado y que se le puedan pasar
datos.
 Normalmente llamado “módulo”
5

6. Roles de un componente
“convencional”
 Componente de control: Coordina el llamado a otros
componentes del dominio del problema
 Componente del dominio del problema: implementa una
función completa o parcial que es requerida por el
usuario
 Componente de infraestructura: responsable de las
funciones que apoyan el procesamiento requerido en el
dominio del problema
 Utilizan cartas de estructura para describir sistemas
6

7. Punto de vista relacionado al
proceso
 Reutiliza software
 Cuando se desarrolla la arquitectura, se escogen
componentes o patrones de diseño de un catálogo, los
cuales fueron creados para ser reutilizados
7

8. Diseñando componentes
basados en clases
 Hay 4 principios básicos de diseño que se pueden
aplicar:
 Principio “abierto-cerrado”: Un componente debe estar
abierto a extensiones pero debe estar cerrado para
modificaciones. El/la diseñador(a) debe especificar el
componente de manera que puede extenderse sin
necesidad de hacer modificaciones internas al código.
8

9. Diseñando componentes
basados en clases (2)
 Principio de substitución de Liskov: Las
subclases deben ser sustituibles por sus clases
bases. Cualquier clase derivada de una clase
base debe cumplir con cualquier contrato
implícito de la clase base con respecto a los
componentes que la usan. Un “contrato” es
una precondición que debe ser verdadera
antes de que el componente use la clase
base, y una post-condición debe ser
verdadera después de que el componente usa
la clase base.
9

10. Diseñando componentes
basados en clases (3)
 Principio de dependencia de inversión: “Se debe
depender de abstracciones, no de eventos concretos”
 Principio de segregación de interfaces: “Varias
interfaces dependientes del cliente son mejor que una
interfaz de propósito general”
10

11. Principios de empaquetado
 Principio de equivalencia de liberación y
reuso: “La granularidad del reuso es la
granularidad de liberación.” Agrupar
clases reusables en paquetes que se
puedan administrar y controlar cuando
una nueva versión se genere.
 Principio de agrupamiento común: “Las
clases que cambian al mismo tiempo
deben agruparse”
 Principio de reuso común: “Las clases que
no se reusan al mismo tiempo no deben
agruparse”
11

12. Guías de diseño
 Establecer convenciones para poner
nombres
 Utilice notación de interfaces siempre
que pueda, dibújelas en el lazo
izquierdo de los diagramas y solo las
que sean relevantes
 Modele las dependencias de izquierda
a derecha y la herencia de abajo
(clase derivada) hacia arriba (clase
base)
12

13. Cohesión y acoplamiento
 La cohesión implica que un
componente o clase encapsula solo
atributos y operaciones que están
altamente relacionados entre ellas y
con la clase. Se busca la máxima
cohesión en una clase
 Acoplamiento es la medida cualitativa
del grado en que una clase está
conectada con otra. Se busca el
mínimo acoplamiento entre clases
(c) P. Gomez-Gil, INAOE. 208-2010 13

14. Pasos para diseño de
componentes
1. Identifique todas las clases de diseño que correspondan al
dominio del problema
2. Identifique todas las clases de diseño que correspondan al
dominio de la infraestructura (GUI, sistemas operativos,
administración de datos etc.)
3. Elabore todas las clases que no provienen de clases
reusadas
a) Especifique detalles de los mensajes entre clases que
colaboran
b) Identifique las interfaces de cada componente
c) Elabore atributos y defina tipos de datos y estructuras de
datos requeridas para implementarlas
d) Describa el flujo de procesamiento de cada componente en
detalle
14

15. Pasos para diseño de
componentes (2)
4. Describa fuentes de datos persistentes
(bases de datos y archivos) e identifique las
clases requeridas para manipularlos
5. Desarrolle y elabore representaciones del
comportamiento de una clase o componente
(diagramas de estados)
6. Elabore diagramas de liberación
(deployment) para dar detalles adicionales
de implementación
7. Revise cada representación de diseño de los
componentes y siempre considere
alternativas
15

16. Ejemplo de un diagrama de
estados
16
[Pressman 2005]

17. Diseñando componentes
“convencionales”
 Hay 3 estructuras básicas: Secuencia,
selección e iteración
 Los diagramas de flujo son los predecesores
de los diagramas de actividades (ver figura
11.10)
 Las tablas de decisión se utilizan para definir
procesos con una gran cantidad de
condiciones y acciones
 Los lenguajes de diseño de programas (PDL)
también llamados ingles estructurado o
pseudocódigo permiten definir el detalle de
un algoritmo
17

18. Ejemplo de una tabla de
decisión
18
[Pressman 2005]

19. Ejemplo de un pseudocódigo
19
[Pressman 2005]