DISEO DE COMPONENTES

DE SOFTWARE *

NOTAS DEL CURSO

Ingeniera de Software I
DRA. MARIA DEL PILAR GMEZ GIL
INAOEP
* Resumen del captulo 10 de libro de
[Pressman 2010]

V:18-11-2008 (c) P. Gomez-Gil, INAOE. 2008- 1

2010
Componente
Bloque de construccin modular para software
de computadora
Una parte modular, entregable y reemplazable
de un sistema que encapsula su implementacin
y expone un conjunto de interfaces segn la
OMG Unified Modeling Language Specification
Se puede definir y usar componentes desde 3
puntos de vista:
Orientado a Objetos
Convencional
Relacionado a procesos
(c) P. Gomez-Gil, INAOE. 2008- 2
2010
Punto de vista orientado a objetos
Desde este punto de vista, un componente
contiene un conjunto de clases que
colaboran entre s.
El diseo de un componente implica
aadir a la definicin de clases en el
anlisis (dominio del problema)
informacin para su implementacin en
software.

(c) P. Gomez-Gil, INAOE. 2008- 3

2010
Ejemplo de elaboracin de un
componente de diseo

[Pressman 2005]
(c) P. Gomez-Gil, INAOE. 2008- 4
2010
Punto de vista convencional
Desde este punto de vista, un componente es un
elemento funcional de un programa que incluye
lgica de procesamiento, estructuras de datos
internas requeridas para implementar dicha
lgica y una interfaz que permite que el
componente sea invocado y que se le puedan
pasar datos.
Normalmente llamado mdulo

(c) P. Gomez-Gil, INAOE. 2008- 5

2010
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 funcin 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
(c) P. Gomez-Gil, INAOE. 2008- 6
2010
Punto de vista relacionado al
proceso
Reutiliza software
Cuando se desarrolla la arquitectura, se
escogen componentes o patrones de
diseo de un catlogo, los cuales fueron
creados para ser reutilizados

(c) P. Gomez-Gil, INAOE. 2008- 7

2010
Diseando componentes basados en
clases
Hay 4 principios bsicos de diseo que se
pueden aplicar:
Principio abierto-cerrado: Un componente
debe estar abierto a extensiones pero debe
estar cerrado para modificaciones. El/la
diseador(a) debe especificar el componente
de manera que puede extenderse sin
necesidad de hacer modificaciones internas al
cdigo.

(c) P. Gomez-Gil, INAOE. 2008- 8

2010
Diseando componentes basados en
clases (2)
Principio de substitucin de Liskov: Las subclases deben
ser sustituibles por sus clases bases. Cualquier clase
derivada de una clase base debe cumplir con cualquier
contrato implcito de la clase base con respecto a los
componentes que la usan. Un contrato es una
precondicin que debe ser verdadera antes de que el
componente use la clase base, y una post-condicin
debe ser verdadera despus de que el componente usa
la clase base.

(c) P. Gomez-Gil, INAOE. 2008- 9

2010
Diseando componentes
basados en clases (3)
Principio de dependencia de inversin: Se
debe depender de abstracciones, no de
eventos concretos
Principio de segregacin de interfaces:
Varias interfaces dependientes del cliente
son mejor que una interfaz de propsito
general

(c) P. Gomez-Gil, INAOE. 2008- 10

2010
Principios de empaquetado
Principio de equivalencia de liberacin y reuso:
La granularidad del reuso es la granularidad de
liberacin. Agrupar clases reusables en
paquetes que se puedan administrar y controlar
cuando una nueva versin se genere.
Principio de agrupamiento comn: Las clases
que cambian al mismo tiempo deben agruparse
Principio de reuso comn: Las clases que no se
reusan al mismo tiempo no deben agruparse

(c) P. Gomez-Gil, INAOE. 2008- 11

2010
Guas de diseo
Establecer convenciones para poner nombres
Utilice notacin de interfaces siempre que
pueda, dibjelas 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)

(c) P. Gomez-Gil, INAOE. 2008- 12

2010
Cohesin y acoplamiento
La cohesin implica que un componente o clase
encapsula solo atributos y operaciones que
estn altamente relacionados entre ellas y con la
clase. Se busca la mxima cohesin en una
clase
Acoplamiento es la medida cualitativa del grado
en que una clase est conectada con otra. Se
busca el mnimo acoplamiento entre clases

(c) P. Gomez-Gil, INAOE. 2008- 13

2010
Pasos para diseo de componentes
1. Identifique todas las clases de diseo que
correspondan al dominio del problema
2. Identifique todas las clases de diseo que
correspondan al dominio de la infraestructura (GUI,
sistemas operativos, administracin 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
(c) P. Gomez-Gil, INAOE. 2008- 14
2010
Pasos para diseo 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 liberacin (deployment) para dar
detalles adicionales de implementacin
7. Revise cada representacin de diseo de los
componentes y siempre considere alternativas

(c) P. Gomez-Gil, INAOE. 2008- 15

2010
Ejemplo de un diagrama de estados

[Pressman 2005]

(c) P. Gomez-Gil, INAOE. 2008- 16

2010
Diseando componentes
convencionales
Hay 3 estructuras bsicas: Secuencia, seleccin e
iteracin
Los diagramas de flujo son los predecesores de los
diagramas de actividades (ver figura 11.10)
Las tablas de decisin se utilizan para definir
procesos con una gran cantidad de condiciones y
acciones
Los lenguajes de diseo de programas (PDL)
tambin llamados ingles estructurado o
pseudocdigo permiten definir el detalle de un
algoritmo
(c) P. Gomez-Gil, INAOE. 2008- 17
2010
Ejemplo de una tabla de decisin

[Pressman 2005]
(c) P. Gomez-Gil, INAOE. 2008- 18
2010
Ejemplo de un pseudocdigo

[Pressman 2005]
(c) P. Gomez-Gil, INAOE. 2008- 19
2010