Reusabilidad_y_Desarrollo_Orientado_a_Ob

Vista previa del material en texto

II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 1
Reusabilidad y Desarrollo Orientado a Objetos
Jose Luis Fernández Sánchez
jlfdez@ingor.etsii.upm.es
Resumen
Las experiencias de la industria en reusabilidad del software, demuestran que esta no depende
específicamente de aspectos tecnológicos sino de aquellos organizativos y de motivación. No
obstante las tecnologías pueden ayudar al respecto. Se describe como la orientación a objetos
contribuye en los diferentes niveles de reutilización: bibliotecas de clases, patrones de diseño y
arquitecturas.
1.¿Garantiza la Orientación a Objetos la Reutilización del Software?
Lograr niveles aceptables de reutilización en el desarrollo software no es básicamente un
problema de las tecnologías en uso aunque estas puedan ayudar al respecto, no representan la
condición necesaria ni la suficiente. A pesar de ello un estudio realizado en la industria
norteamericana en 1994 por Valley Forge Information Services, indicaba que la reutilización es
el objetivo principal de las organizaciones que eligieron la orientación a objetos , 35% de los
encuestados.
En primer lugar hay que separar lo que se entiende por reutilización individual o oportunista de la
reutilización a nivel empresa o sistemática.
La reutilizacion a nivel individual o de pequeños grupos de desarrollo no es en realidad nada
nuevo y desde siempre los programadores han realizado corta- pega de trozos de código para
ahorrarse trabajo de programación. En otros casos se han utilizado bibliotecas de rutinas,
principalmente matemáticas que han dado buenos resultados pero sin lograr el objetivo principal
de la reutilización, la disminución substancial de los costes de desarrollo y mantenimiento, y la
mejora de los tiempos de desarrollo.
Para lograr de una manera efectiva los anteriores objetivos es necesario un planteamiento a
nivel de empresa de reutilización sistemática. La reutilización sistemática se basa en un
conocimiento y modelización del dominio de aplicación de interés para la empresa o sus clientes,
sea este el financiero, control de procesos industriales , gestión de red o aviónica. Para la
realización de la modelización del dominio del problema se utilizan técnicas de análisis de
dominio, algunas de ellas se basan en los principios de adquisición y representación del
conocimiento desarrollados dentro de la Inteligencia Artificial, otras utilizan principios parecidos a
los del análisis de sistemas donde hay mucha experiencia en la industria. La biblioteconomía,
como se verá posteriormente ha sido también muy útil. La obtención de la representación del
dominio en el ámbito del problema , lleva a la búsqueda de soluciones de éste. Se desarrollan
entonces arquitecturas de referencia que permiten desarrollar implementaciones de aplicaciones
en el ámbito del dominio de la aplicación. Estas arquitecturas de referencia se pueden apoyar en
bibliotecas de programas sean estas rutinas o clases dependiendo de las metodologías de
desarrollo software que se utilicen.
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 2
Experiencias de la industria [Griss 95] indican que los tres principales factores que llevan al
éxito en la reutilización no son tecnológicos sino organizativos:
• Soporte de la dirección. Las decisiones en la utilización de procesos de desarrollo
software comunes, herramientas, y lenguajes , así como las inversiones en formación
, construcción de activos reutilizables y adaptación de la organización son inviables
sin un apoyo explícito de la alta dirección.
• Cambios en la organización. La reutilización sistemática conlleva la división del
personal de desarrollo en dos grupos principales con funciones distintas. El grupo de
Ingeniería de Dominio, que construye los activos reutilizables, sean estos modelos del
dominio, bibliotecas, arquitecturas o generadores de aplicaciones, y el grupo de
Ingeniería de Aplicación, que construye aplicaciones con los activos reutilizables
existentes en la organización.
• Cambios en el personal. La formación y los incentivos son útiles para cambiar
prácticas habituales en el personal y disminuir la desconfianza en la utilización de
código desarrollado por otros como parte del suyo propio.
Por consiguiente los mayores beneficios se obtendrán de la unión de factores organizativos (
personal y procesos) y tecnológicos ( orientación a objetos), tal como se muestra en la figura 1 .
En esto se puede afirmar que no hay diferencias substanciales con los principios que rigen la
mejora del desarrollo software.
 Figura 1. Aspectos que Influyen en la Reutilización
No es el objetivo de este artículo describir en detalle los aspectos no tecnológicos que
contribuyen a la reutilización a pesar de que se ha indicado que su importancia es fundamental
en el éxito de ésta.
El objetivo del artículo es el de presentar como los aspectos tecnológicos ligados a la orientación
a objetos pueden ayudar en cierta medida a la mejora de la reutilización en una organización .
Proceso
Ingeniería de Dominio
Economía
Organización
Cultura
Incentivos
Arquitectura
Infrastructura
Formación
Documentación
Estándares
“Legos”
Reutilización Orientación a Objetos
Metodologias de
Analisis y Diseño OO
Encapsulamiento
Herencia
Bibliotecas de Clases
Arquitecturas OO
Clases de Negocio
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 3
Experiencias en el desarrollo de bibliotecas de componentes reutilizables siguiendo los principios
de la orientación a objetos [Fernández 91] son ilustrativas al efecto.
En el resto del artículo se planteará en primer lugar los niveles de reutilización que pueden existir
en una organización haciendo especial hincapié en las diferencias tecnológicas que existen entre
éstos.
Otros aspectos a tratar en posteriores secciones están relacionados con las soluciones técnicas
concretas que nos ofrece la orientación a objetos y que son de utilización creciente en la
industria. Estas son las bibliotecas de clases, los patrones de diseño y las arquitecturas. Se
describirán sus características y comentaran sus ventajas.
2.Niveles de Reutilización.
La adopción de reutilización en una organización ha de seguir una evolución incremental donde
se parte de soluciones tecnológicas mas simples como las bibliotecas de clases a
soluciones de mayor complejidad como son las arquitecturas de referencia.
Griss propone un modelo de evolución incremental en la adopción de la reutilización por una
organización que conlleva cinco etapas [Griss 95]. Este modelo es independiente de la
utilización de orientación a objetos aunque se puede adaptar bien a esta tecnología. Las cinco
etapas en la evolución de la reutilización son:
1. Corta-Pega. En esta primera etapa o fase de la evolución, la organización trata de
disminuir los tiempos de desarrollo mediante la clonación de trozos de código.
Aunque es una solución a primera vista, los problemas aparecen en el mantenimiento,
pues a la hora de realizar cambios hay que ser consciente de todos los sitios en el
código donde estos aplican. Es un problema típico de la gestión de configuración.
2. Caja Negra. En la reutilización de caja negra se identifican componentes software
de uso común en la organización. Se garantiza que existe un original único de ellas.
La utilización de bibliotecas y taxonomías de clasificación puede ayudar en esta fase
de la evolución de la organización.
3. Activos Reutilizables. En esta fase la organización considera otros activos
reutilizables distintos del código. Entre estos destacan principalmente los
procedimientos de prueba, las especificaciones, ficheros de ayuda, herramientas y
otros. Con esta aproximación se incrementa la reutilización en las diversas fases del
ciclo de vida del software , no solo en la fase de implementación como ocurría
especialmente en la fase de Caja Negra. La experiencia en el proyecto Bibliotecade
Componentes Ada [Fernández 91], de crear los procedimientos de prueba como
activos reutilizables es ilustrativa al respecto.
4. Arquitecturas. En esta fase se generan componentes reutilizables, que podrían ser
los anteriores, y una arquitectura software que los aglutina , permitiendo desarrollar
aplicaciones en un dominio especifico de negocio, sea este financiero, control de
tráfico aéreo , gestión de red u otros. Una experiencia significativa al respecto es la
arquitectura software de aviónica desarrollada con contrato del Ministerio de
Defensa de los Estados Unidos [Tracz 95]. Las guías para la creación de
arquitecturas de referencia o especificas de dominio de este proyecto pueden ser
utilizadas en dominios de aplicación diferentes.
5. Reutilización sistemática. La reutilización sistemática en una organización se basa
en la estandarización de los activos reutilizables y los procesos para producirlos, la
creación de una infraestructura para la producción de estos activos y los mecanismos
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 4
organizativos adecuados para facilitar la reutilización de estos. La separación del
personal en grupo de ingeniería de dominio ,o responsable de crear y mantener los
activos reutilizables y el grupo de ingeniería de aplicación, responsable de utilizarlos,
es un aspecto fundamental en esta fase.
3.Reutilización con Orientación a Objetos
Las anteriores consideraciones indicaban que la reutilización no depende esencialmente de
aspectos tecnológicos sino también de los organizativos y otros. No obstante la orientación a
objetos ofrece un conjunto de particularidades que facilitan el desarrollo de la reusabilidad. En
esta sección se describen tres niveles de reutilizacion desde el punto de vista arquitectónico que
pueden ser llevados a cabo teniendo en cuenta los principios de la orientación a objetos. Estos
niveles son las bibliotecas de clases, los patrones de diseño y las arquitecturas. Se plantearan
que significan cada uno de ellos y que aspectos se tendrían en cuenta en su construcción.
3.1 Bibliotecas de Clases
En términos generales se define una biblioteca de clases como una colección de componentes
reutilizables relativas a un dominio de aplicación o independientes de dominio que sirven como
elementos constructivos de aplicaciones .
En principio las bibliotecas de clases más utilizadas son independientes del dominio de aplicación
y suelen ser suministradas por los fabricantes de compiladores o por terceros. Ejemplos del
último caso son las bibliotecas de tipos abstractos de datos donde se ofrecen abstracciones
estructurales de tipo pilas, colas, listas, bolsas, anillos etc [Booch 94].
Bibliotecas de clases específicas de dominio también existen. Existen en dominios diferentes
como los financieros, investigación operativa, control de tráfico aéreo o comunicaciones.
Nuestra experiencia previa se centró en el dominio de navegación de aviones [Fernández 91] y
ejecutivos de tiempo real [Puente 92].
Booch [Booch 94]define las propiedades que debería tener una biblioteca de clases para facilitar
su reutilización:
• Completa. La biblioteca de clases debe proporcionar familias de clases que tengan
un interfaz común pero posibilitando diferentes implementaciones.
• Adaptable. Todos los aspectos específicos de la plataforma deben estar identificados
y aislados.
• Eficiente. Se debe buscar la eficiencia en compilación, permitiendo el fácil
ensamblaje de los componentes y en ejecución, haciendo una optima utilización de las
características del lenguaje.
• Segura respecto a los tipos. Permitiendo que las suposiciones estáticas respecto al
comportamiento de una clase puedan reforzarse por el sistema de compilación.
• Simple. La biblioteca debe usar una organización clara y consistente que facilite la
identificación y selección de clases concretas.
• Extensible. Se ha de admitir la adición de nuevas clases.
El modelo de objetos se basa en cuatro principios fundamentales y tres secundarios, estos
últimos no son esenciales al modelo de objetos [Booch 96].
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 5
Los principios fundamentales son : Abstracción, encapsulamiento, modularidad y jerarquía. Los
principios secundarios son tipificación, concurrencia y persistencia.
El creador de una biblioteca de clases tiene que tener en cuenta como son soportados estos
principios en el lenguaje de programación utilizado y en función de ello definir una estrategia
para implementar los aspectos variables del dominio en las diferentes clases.
Los puntos de variabilidad de los componentes son aquellos aspectos que denotan
particularidades que distinguen a las aplicaciones dentro del dominio. Se pueden utilizar diversas
técnicas de la orientación a objetos para permitir la implementación de la variabilidad en los
componentes. Las técnicas posibles son:
• Especialización. Utilizando los mecanismos de herencia soportados por el lenguaje.
• Extensión. Utilizando la composición de componentes .
• Parametrización. Esta técnica permite definir un tipo sin especificar todos los otros
tipos que este usa. Los tipos no especificados son suministrados como parámetros en
el punto de uso.
La herencia permite definir la implementación de una clase en términos de otra. Esta
reutilización se le suele denominar de “caja blanca” porque permite que las interioridades de los
ancestros sean conocidas por sus descendientes. La herencia se define estáticamente en tiempo
de compilación y es relativamente fácil de aplicar. La herencia tiene el inconveniente que en
cierta medida no cumple el principio de encapsulamiento, por lo que ha de ser utilizada con
precaución.
La composición es una alternativa a la herencia . En la composición se obtiene una nueva
funcionalidad ensamblando o componiendo objetos. Esto requiere que los objetos tengan bien
definidas sus interfaces. Se suele conocer como reutilización de “caja negra” porque los objetos
no conocen los detalles internos de los otros. La composición se puede realizar en tiempo de
ejecución.
Si se favorece la composición sobre la herencia se pueden tener en la biblioteca de clases,
jerarquías de clases más pequeñas y fáciles de manejar.
Gamma et al. [Gamma 95], definen la delegación como la forma de permitir que la composición
sea tan poderosa para la reutilización como la herencia. En la delegación , dos objetos están
involucrados en manejar una misma petición. Un objeto receptor y un delegado. El receptor se
pasa a si mismo al delegado para permitir que la operación del delegado se refiera al receptor.
Por ejemplo, en la figura 2, la clase ventana puede reutilizar la conducta de rectángulo
manteniendo un ejemplar de rectángulo y delegando la conducta específica de rectángulo a ella.
Es decir, en vez que la ventana sea un rectángulo, se tiene que la ventana rectangular envía las
peticiones al ejemplar de rectángulo con lo que no tiene que heredar esas operaciones.
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 6
 Figura 2. Uso de la Delegación
La principal ventaja de la delegación es que permitiría cambiar la conducta de la ventana en
tiempo de ejecución. Por ejemplo una ventana se haría circular simplemente remplazando el
objeto rectángulo por un objeto circulo , suponiendo que ambos tuvieran el mismo tipo.
Los tipos parametrizados, también conocidos como genéricos (Ada ,Eiffel) o plantillas (C++) ,
permiten definir un tipo sin especificar todos los tipos que éste usa. Estos serán suministrados
como parámetros en el punto de instanciación . Los cambios son realizados por tanto en tiempo
de compilación.
Los tipos parametrizados se utilizan especialmente para implementar tipos abstractos de datos :
pilas, colas, anillos , bolsas y otros que permiten almacenar distintos tipos de elementos según
sean instanciados entiempo de compilación.
La figura 3, muestra un ejemplo presentado por Booch [Booch 94], que muestra como se puede
combinar la herencia y tipos parametrizados para construir una cola de mensajes de correo
electrónico.
La figura 3 describe un diseño de una aplicación para ordenar mensajes de correo electrónico
por orden de llegada y prioridad. Para lo cual se utiliza una biblioteca de clases, plantillas en C++,
donde se encuentran los tipos abstractos cola y cola con prioridades, esta última es un
descendiente del anterior. Se crea un ejemplar de cola con prioridades para manejar mensajes .
Un descendiente de éste es el componente para gestionar mensajes de correo que se ha
realizado para cubrir los requisitos de la aplicación.
Ventana
Area()
Rectangulo
Area()
Altura
Anchura
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 7
 Figura 3. Uso de Biblioteca de Clases
Otro concepto de utilización en la orientación a objetos es el polimorfismo . El polimorfismo
consiste en dar el mismo nombre a servicios implementados en diferentes objetos, estos servicios
pueden implementarse diferentemente pero producirán el mismo tipo de resultados. Se utiliza el
polimorfismo cuando se quiere enviar el mismo mensaje a diferentes objetos sin saber el objeto
específico al que se le esta enviando el mensaje. Existen diversas formas de polimorfismo:
• Ad Hoc. Es la sobrecarga de operadores, donde una función es llamada basándose
en su firma definida como la lista de tipos de argumentos en su lista de parámetros.
• Puro. Una clase es subclase de otra. Las funciones disponibles en la superclase
pueden usarse en la subclase. Se puede tener distinta implementación de la función
en la subclase. La función a utilizar se determina dinámicamente en tiempo de
ejecución. esto se conoce como ligadura dinámica y se consigue en C++ con el uso
de funciones virtuales . En Ada 95 la utilización de objetos etiquetados consigue
efectos similares.
Estudios de Deutsch indican que el polimorfismo puro no se necesita del orden del 85% de las
ocasiones, con lo que el paso de mensajes puede reducirse a simples llamadas a procedimiento
[Deutsch 83].
3.1.1 Clasificación de Clases
Un aspecto no específico de la orientación a objetos pero de interés para la reutilización es la
clasificación de las clases pertenecientes a una biblioteca de clases. Estas clasificaciones son
más necesarias según sea el tamaño de la biblioteca de clases, es decir cuando se habla de más
de cien clases no es fácil localizar la clase que se necesita en un momento determinado. Como
este problema ya existía en las bibliotecas, las soluciones más ampliamente difundidas en la
industria software se han tomado de la biblioteconomía.
Mensaje
Cola_Mensajes
_Prioridad
Mensaje
Cola_Correo
Elemento
Cola_Prioridad
Elemento
Cola
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 8
Los esquemas de clasificación de componentes software reutilizables que serían también
aplicados a las clases son básicamente dos:
• Enumerativos. Donde se descompone el dominio en clases cada vez más
específicas y restringiendo a la vez el número de ramas de los árboles así creados.
Estas descomposiciones pueden basarse en una taxonomía conceptual, similar a la
clasificación decimal utilizada en biblioteconomia, o en la descomposición de los
sistemas.
• Por Facetas. Se basa en la síntesis y no en la descomposición del dominio. Las
facetas, cuyo uso proviene también de la biblioteconomía, permiten clasificar una
clase escogiendo el término adecuado para cada una de las facetas que mejor
describa la clase en cuestión.
Los esquemas enumerativos se basan en jerarquías de las clases o componentes relacionadas
con niveles de abstracción, relevancia del dominio, atributos de la clase o técnicas de creación
de ejemplares.
Las facetas se pueden considerar como dimensiones, perspectivas o vistas de un dominio
particular. Para desarrollar un sistema de clasificación por facetas, Prieto-Diaz [Prieto 88]
sugiere tener en cuenta dos aspectos: funcionalidad del componente y entorno en donde realiza
su función. Esto lleva a un conjunto de seis facetas para describir un componente:
• Función
• Objeto
• Medio
• Tipo de Sistema
• Área Funcional
• Tipo de Negocio
Pueden ocurrir problemas de asignación de términos a las facetas o con el manejo de sinónimos,
que llevan a la construcción de tesauros de términos. Se utilizan también los grafos de distancia
conceptual para soportar una medida objetiva de la similitud conceptual entre los términos de una
faceta.
3.2 Patrones de Diseño
La utilización de patrones no es una actividad exclusiva del desarrollo software, precisamente ha
sido una practica habitual en multitud de disciplinas siendo su utilización en el desarrollo
software más bien reciente.
En términos generales se puede definir un patrón como una forma realizada, original, aceptada o
propuesta para su imitación: algo dispuesto como ejemplo a ser copiado o utilizado como
arquetipo .
Muchas de las actividades humanas utilizan patrones de diversas maneras. En música y
literatura, un patrón es una estructura coherente de diseño de una pieza musical o de un libro. En
arte es la composición o plan de trabajo de una representación plástica. En arquitectura, un
patrón es un diseño o estilo arquitectónico.
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 9
En psicología, un patrón es un mecanismo que es básico para la operación mental, ayudando a la
persona a procesar los estímulos con rapidez. En la lingüística, un patrón es la forma en que
pequeñas unidades del lenguaje se agrupan en unidades mayores.
En confección, un patrón es un modelo que se repite extensivamente en la confección de
prendas de vestir. En aeronáutica, un patrón podría ser el conjunto de maniobras que realiza una
aeronave en la aproximación y aterrizaje en un aeropuerto.
En el software desarrollado con las metodologías de orientación a objetos, se considera un
patrón de diseño software a la descripción de un conjunto de objetos y clases que se
comunican entre si y que pueden ser adaptados para resolver un problema de diseño general en
un contexto particular.
En general, un patrón de diseño tiene cuatro elementos esenciales:
• Nombre. Es la identificación que se puede utilizar para etiquetar un problema de diseño, su
solución y consecuencias. El nombre de los patrones , es de gran importancia pues formará
parte del vocabulario del dominio de reutilización y nos permitirá trabajar a niveles superiores
de abstracción.
• Problema. Describe cuando se puede aplicar el patrón. Se explica el problema a resolver y
su contexto. Se pueden describir problemas específicos de diseño tales como la
representación de algoritmos como objetos. A veces el problema incluirá una lista de las
condiciones que se deben cumplir para que tenga sentido aplicar el correspondiente patrón de
diseño.
• Solución. Describe los elementos que conforman el diseño en cuestión, incluyendo sus
relaciones, responsabilidades y colaboraciones. La solución no describe un diseño particular y
concreto o una implementación, dado que un patrón es como una plantilla que puede ser
aplicada en situaciones diversas. Por consiguiente, un patrón suministra una descripción
abstracta de un problema de diseño y como una agrupación de elementos constructivos (
clases y objetos) lo resuelven.
• Consecuencias. Estas representan las alternativas y resultados de aplicar el patrón. Aunque
a veces en las descripciones de diseños se obvian las consecuencias, éstas son críticas para
evaluar las alternativas y para determinar los costes y beneficios derivados de aplicar un
patrón. En el desarrollo de sistemas, las consecuencias suelen estar ligadas a alternativas en
tamaño o prestaciones. También se tienen en cuenta aspectos de lenguaje e implementación.
Impacto en la portabilidad, flexibilidado escalabilidad del sistema.
Se pueden organizar los patrones según familias de patrones relacionados . La clasificación
facilita la búsqueda del patrón más adecuado así como su comprensión . Gamma clasifica los
patrones según dos criterios fundamentales: su propósito y su alcance [Gamma 95].
El propósito refleja lo que realiza el patrón . Los patrones pueden tener propósito de creación,
estructural o de conducta. Los patrones con propósito de creación conllevan el proceso de
creación de objetos. Los patrones estructurales tratan de la composición de clases u objetos.
Los patrones de conducta describen las formas en que las clases u objetos interactuan o
distribuyen responsabilidades.
El alcance indica si el patrón aplica principalmente a clases u objetos. Los patrones de clases
tratan de relaciones entre clases y sus subclases. Estas relaciones se establecen a través de la
relación de herencia, por consiguiente son estáticas y definidas en tiempo de compilación. Los
patrones de objetos tratan de relaciones entre objetos que pueden ser cambiadas en tiempo de
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 10
ejecución y son más dinámicas. Casi todos los patrones utilizan la herencia de alguna forma.
Pero son los patrones de clases los que se focalizan en las relaciones de clase.
Los patrones con propósito de creación y alcance de clase difieren parte de la creación de
objetos a subclases mientras que los patrones con propósito de creación y alcance de objeto
difieren ésta a otros objetos. Los patrones estructurales y alcance de clase utilizan la herencia
para componer clases, mientras que los patrones estructurales y alcance de objeto describen
formas de ensamblado de objetos. Los patrones de conducta con alcance de clase utilizan
herencia para describir algoritmos y flujos de control mientras que los patrones de conducta con
alcance de objeto describen como un grupo de objetos cooperan para realizar una actividad que
un objeto no puede realizar por sí solo.
La tabla 1 muestra la clasificación propuesta por Gamma de algunos de los patrones más
utilizados actualmente [Gamma 95]
Creación Estructural De Conducta
Clase Método de
Fabricación
Adaptador
(clases)
Interprete
Plantilla
Objeto Fábrica Adaptador
(objetos)
Cadena de
Responsabilidad
Constructor Puente Comando
Prototipo Composición Iterador
Singleton Decorador Intermediario
Fachada Observador
Flyweight Estado
Apoderado Estrategia
Visitante
Memoria
 Tabla 1. Clasificación de Patrones de Diseño
Como ejemplo de patrón de diseño se mostrará el patrón intermediario.
Patrón Intermediario
• Este patrón define un objeto que encapsula como un conjunto de objetos interaccionan. El
intermediario facilita el acoplamiento mínimo, evitando que los objetos participantes se tengan
que referenciar entre ellos explícitamente , con lo que se permite variar su interacción
independientemente. Los objetos participantes solo conocen al intermediario.
• El desarrollo orientado a objetos potencia el reparto de conducta entre objetos. Tal reparto
puede resultar en una arquitectura donde existen múltiples conexiones entre los objetos. En el
peor de los casos cada objeto debería conocer a todos los demás. Esto dificulta la
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 11
reutilización. Se puede evitar esta situación, encapsulando la conducta colectiva en un objeto
llamado intermediario. Un intermediario es responsable de controlar y coordinar las
interacciones de un grupo de objetos. Esto puede ser útil como se verá en el ejemplo de
interacciones entre elementos gráficos.
• La estructura del patrón siguiendo la notación OMT para el diagrama de clases es como
sigue:
 Figura 4. Patrón Intermediario
• Un ejemplo de utilización de este patrón es la implementación de cajas de dialogo en una
interfaz gráfica . Una caja de dialogo utiliza una ventana para presentar una colección de
elementos gráficos tales como botones, menús o campos de entrada. Frecuentemente
existen dependencias entre los elementos gráficos en el dialogo. Por ejemplo un botón
esta inhabilitado cuando cierto campo de entrada esta vacío. Seleccionando una entrada
de una lista de opciones llamada una caja tipo lista podría cambiar los contenidos de un
campo de entrada. Se puede encapsular esta conducta en un intermediario, llamado en el
ejemplo Director_Dialogo.
Es importante resaltar los siguientes aspectos:
• Cada objeto de las clases participantes es decir los objetos gráficos de tipo List_Box
o Entry _Field solo conoce a su intermediario concreto .
• Siempre que un objeto gráfico requiera comunicarse con otro ha de hacerlo a través
de su intermediario (Director_Dialogo).
Intermediario Compañero
utiliza
Compañero_1
Intermediario_Concreto
conoce Compañero_N
conoce
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 12
 Figura 5. Ejemplo del Patrón Intermediario
3.3 Arquitecturas
Las arquitecturas o “frameworks” definen un conjunto de elementos constructivos software que
se pueden utilizar, extender o adaptar para la realización de aplicaciones informáticas
específicas.
La construcción de compiladores fue una de las primeros dominios donde se han realizado
arquitecturas. Otros han sido las interfaces gráficas. Actualmente se están desarrollando
arquitecturas en otros dominios como el financiero, avionica o multimedia.
La arquitectura describe la estructura global de un sistema es decir la partición de éste en clases
y objetos, la asignación de responsabilidades, la colaboración entre los objetos, y el flujo de
control. La arquitectura captura las decisiones de diseño que son comunes al dominio de la
aplicación. Las arquitecturas enfatizan la reutilización a nivel de diseño en vez de a nivel de
código.
Las arquitecturas se diferencian de los patrones en una serie de aspectos:
• Los patrones de diseño son más abstractos que las arquitecturas. Las arquitecturas
están implementadas en código, lo que solo ocurre con los ejemplos concretos de los
patrones. Los patrones se implementan cada vez que se utilizan.
• Los patrones son más reducidos que las arquitecturas, algunos autores les denominan
microarquitecturas. Una arquitectura puede contener varios patrones, lo contrario en
cambio no es cierto.
• Los patrones son menos especializados que las arquitecturas. Las arquitecturas
tienen siempre un dominio específico de aplicación, en cambio los patrones pueden
ser aplicados en diversos dominios.
Las arquitecturas han de tener una serie de propiedades para favorecer su reutilización:
• Ser Completa. La arquitectura debe soportar las características necesitadas por los
ingenieros de las aplicaciones y suministrar implementaciones siempre que sea
posible.
• Ser Flexible. Las abstracciones podrán ser utilizadas en diversos contextos.
Usuario_Pantalla
Director_Dialogo
Director_Dialogo_F
Widget
List_Box Entry_Field
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 13
• Ser Extensible. Los ingenieros de las aplicaciones podrán fácilmente aumentar o
modificar la funcionalidad suministrada. Se suministraran los mecanismos de
adaptación que permitan modificar la conducta de la arquitectura por herencia o
composición.
• Ser Inteligible. Las interfaces con otros subsistemas están claras y la arquitectura
está bien documentada y sigue estándares de diseño y codificación.
• Tener aisladas las dependencias de plataforma. Normalmente se utilizaran clases
intermediarias para conseguir tal efecto.
El dominio de solución que una arquitectura resuelve puede ser el de funciones de aplicación,
funciones de dominio o funciones de soporte.
Las arquitecturas de aplicación conllevan la implementación de una rebanada horizontal de la
funcionalidadde un sistema. Ejemplos de estas arquitecturas son aquellas para resolver las
interfaces gráficas de un sistema.
Las arquitecturas de dominio conllevan la implementación de la solución a los requisitos de un
dominio determinado de aplicación. Conllevan por consiguiente la implementación de una
rebanada vertical de funcionalidad. Ejemplos de estas arquitecturas se encuentran en dominios
financieros, de avionica o control de procesos industriales.
Las arquitecturas de soporte suministran los servicios a nivel de sistema tales como aquellos de
acceso a ficheros, soporte a computación distribuida o manejadores de dispositivo.
Un ejemplo sencillo de arquitectura sería una para construir diagramas de barras con sistema de
ejes y escalas. la arquitectura suministra características específicas que el ingeniero de
aplicación puede utilizar directamente y una estructura que puede ser extendida por herencia o
composición .
Al utilizar la arquitectura, el ingeniero de aplicación dispone los elementos gráficos necesarios y
un gráfico estándar. Cuando el usuario llama a Grafico_Estandar::Dibujar, Dibujar se llama para
cada elemento gráfico y el gráfico y todos sus elementos son dibujados. se puede también
cambiar el aspecto del gráfico llamando por ejemplo a Ejes::Poner_Color.
Para extender la arquitectura, los ingenieros de aplicaciones derivan nuevos elementos gráficos
de Elemento_Gráfico o una de sus subclases.
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 14
 Figura 6. Arquitectura para Construir Gráficos
4. Conclusión
Aunque la orientación a objetos no es ni condición necesaria ni suficiente para obtener
beneficios de la reutilización, puede contribuir a ésta.
Existen diversos niveles donde la orientación a objetos puede contribuir en la adopción de la
reutilización por una organización. Estos son las bibliotecas de clases, los patrones de diseño y
las arquitecturas.
No siempre los aspectos más novedosos o complejos de los lenguajes de programación, como
puede ser la herencia múltiple o la ligadura dinámica son los que mejor contribuyen a la
reutilización. La conjunción de los principios básicos de la ingeniería software con la
implementación adecuada de las variabilidades de un dominio de aplicación ha dado
frecuentemente mejores resultados. Los trabajos en curso en patrones de diseño y arquitecturas
de referencia son muy esperanzados al respecto.
5. Referencias
[Booch 94] G. Booch
 Designing an Application Framework
 Dr. Dobb´s Journal, February 1994
Grafico_Estandar
Dibujar
Adoptar_Elemento
Elemento_Huerfano
Crear_Iterador_Elementos
Elemento_Grafico
Dibujar_en_Grafico
Barra Ejes Escala Etiqueta
Dibujar_en_Grafico
Adoptar_Valores
Valores_Huerfanos
Obtener_Atributos
Poner_Atributos
Dibujar_en_Gráfico
Obtener_Color
Poner_Color
Dibujar_en_Grafico
Obtener_Atributos
Poner_Atributos
Dibujar_en_Grafico
Obtener_Atributos
Poner_Atributos
Posicionar_Etiqueta
Obtener_Rango
 II Jornada de Orientación a Objetos,ATI, Madrid Noviembre 1996 15
[Booch 96] G. Booch
 Análisis y Diseño Orientado a Objetos.
 Diaz de Santos, Madrid, 1996.
[Deutsch 83] P. Deutsch
 Efficient Implementation of the Smalltalk-80 System.
 Proceedings of the 11th Annual ACM Symposium on the Principles of
 Programming Languages.1988.
[Fernández 91] J.L. Fernández y J.A. de la Puente
 Constructing a Pilot Library of Components for Avionic Systems.
 Ada-Europe International Conference. Athens 1991.
[Gamma 95] E. Gamma, R. Helm, R. Johnson y J. Vlissides
 Design Patterns. Elements of Reusable Object-Oriented Software.
 Addison Wesley, Reading MA , 1995.
[Griss 95] M.L. Griss y M. Wosser
 Making Reuse Work at Hewlett-Packard
 IEEE Software January 1995.
[Prieto 88] R. Prieto-Diaz y G.A. Jones
 Breathing New Life into Old Software
 Softwre Reuse: Emerging Technology. IEEE 1988.
[Puente 92] J.A. de la Puente, J. Zamorano, A. Alonso y J. L. Fernández
 Reusable Executives for Hard Real-Time Systems in Ada.
 11th Ada-Europe International Conference, Zandvoort 1992.
[Tracz 95] W. Tracz
 Confessions of a Used Program Salesman. Institutionalizing Software
 Reuse.
 Addison-Wesley. Reading, MA, 1995.