10.

2 Diseo de Componentes Basados en clase

Cuando se escoge un enfoque de ingeniera orientado al software, el diseo en el nivel
de componentes se centra en la elaboracin de clases especificas del dominio del
problema y en el refinamiento de las clases de infraestructura contenidas en el modelo
de requerimientos, La descripcin detallada de los atributos, operaciones e interfaces
que emplean dichas clases es el detalle de diseo que se requiere como precursor de la
actividad de construccin.
Principios bsicos del diseo
Hay cuatro principios bsicos que son aplicables al diseo en el nivel de componentes y
que han sido aceptados para la aplicacin de la ingeniera del software orientada a
objetos.
- Principio Abierto-Cerrado (PAC)
Debe especificarse el componente en forma tal que permita extenderlo sin necesidad
de hacerle modificaciones internas es decir a nivel del cdigo o de la lgica.
Para lograr esto, se crean abstracciones que sirven como bfer entre la funcionalidad
que sea probable extender y la clase de diseo en s.
- Principio de Sustitucin de Liskov (PSL)
Este principio de diseo, originalmente propuesto por Barba Liskov, sugiere que en
un componente que use una clase de base debe funcionar bien si una clase derivada
de la clase base pasa al componente. PSL demanda que cualquier clase derivada de
una clase de base debe respetar cualquier contrato implcito entre la clase de base y
los componentes que la usan.
- Principio de Inversin de la Dependencia (PID)
Las abstracciones son el lugar en el que es posible ampliar un diseo sin muchas
dificultades, entre ms dependa un componente de otros componentes concretos ms
difcil ser ampliarlo.
- Principio de Segregacin de la Interfaz (PSI)
Es mejor tener muchas interfaces especificas del cliente que una sola de propsito
general.
Hay muchas instancias en las que mltiples componentes del clientes usan las
operaciones que provee una clase servidor, El PSI sugiere que debe crearse una
interfaz especializada y dedicada que atienda a cada categora principal de clientes
en las que solo deben especificarse aquellas operaciones que sean relevantes para
una categora particular de clientes.
- Principio de Equivalencia de la liberacin de la Reutilizacin (PER)
Cuando las clases o componentes se disean para ser reutilizables, existe un contrato
implcito que se establece entre el desarrollador de la entidad reutilizable y las
personas que la emplean.
- Principio de cierre comn (PCC)
Las clases deben empacarse en forma cohesiva, es decir, cuando las clases se
agrupan como parte de un diseo, deben estar dirigidas a la misma rea de funciones
o comportamiento.

- Principio de la reutilizacin comn (PRC)

Cuando cambia una o ms clases dentro de un paquete, cambia el nmero de
liberacin del paquete. Entonces, todas las dems clases o paquetes que permanecen
en el paquete que cambi deben actualizarse con la liberacin ms reciente y
someterse a pruebas a fin de garantizar que la nueva versin opera sin problemas.
Lineamientos de diseo en el nivel de componentes
Se aplican lineamientos prcticos a los componentes, a sus interfaces y a las
caractersticas de dependencia y herencia que tengan algn efecto en el diseo
resultante.
Componentes: Deben establecerse convenciones para dar nombre a los componentes
que se especifique que forman parte del modelo arquitectnico, para luego mejorarlos y
elaborarlos como parte del modelo en el nivel de componentes.
Interfaces: as interfaces dan informacin importante sobre la comunicacin y la
colaboracin, sin embargo, la representacin sin restricciones de las interfaces tiende a
complicar los diagramas de componentes.
Dependencias y Herencia: Para tener una mejor legibilidad, es buena idea modelar las
dependencias de izquierda a derecha y la herencia de abajo hacia arriba.
Cohesin
La cohesin implica que un componente o clase slo contiene atributos y operaciones
que se relacionan de cerca uno con el otro y con la clase o componente en s.
Funcional: Lo tienen sobre todo las operaciones, este nivel de cohesin ocurre cuando
un componente realiza un clculo y luego devuelve el resultado.
De Capa: Lo tienen los paquetes, componentes y clases; este tipo de cohesin ocurre
cuando una capa ms alta accede a los servicios de otra ms baja, pero esta no tiene
acceso a las superiores.
De Comunicacin: Todas las operaciones que acceden a los mismos datos se definen
dentro de una clase. En genera, tales clases se centran nicamente en los datos en
cuestin, acceden a ellos y los guardan.
Acoplamiento
El acoplamiento es la medicin cualitativa del grado en el que las clases se conectan una
con otra. Conforme las clases (y componentes) se hacen ms interdependientes, el
acoplamiento crece.
-

Acoplamiento de Contenido
Acoplamiento Comn
Acoplamiento del Control
Acoplamiento de Molde
Acoplamiento de Datos
Acoplamiento de Rutina de Llamada

Acoplamiento de tipo de uso

Acoplamiento de inclusin o importacin
Acoplamiento Externo.