2. Tipos de conocimiento en diseño OO

Hoy en día, si deseamos conocer o usar la experiencia práctica de otros expertos en diseño debemos estar listos para afrontar un trabajo difícil. Una breve revisión de la bibliografía existente relacionada con conocimiento en diseño nos mostrará cientos de referencias y decenas de términos, como patrones, principios, refactorizaciones, heurísticas, lecciones aprendidas, prácticas, experiencias, malos olores, etc.

La tabla 1 muestra sólo un pequeño ejemplo del conocimiento en DOO asociado a tecnologías específicas como .NET o J2EE, o asociado a dominios particulares, como integración, tiempo real, datos, etc. En resumen, nos enfrentamos a gran una confusión, donde cada experto expone sus aportaciones al conocimiento de manera particular, y donde raramente el conocimiento está relacionado, por lo que es muy difícil transmitir y explotar este conocimiento en proyectos reales.

Una ontología puede ayudar a facilitar la asimilación del conocimiento en diseño, ya que describe el conocimiento de un dominio de forma general y proporciona un entendimiento común. Una ontología estructura y unifica el conocimiento acumulado, y puede predecir el desarrollo de áreas futuras – como la tabla periódica predijo la existencia de algunos elementos décadas antes de que estos fueran aislados (Glass & Vessey, 1995). Por consiguiente, es beneficioso poder disponer de una ontología para estructurar y unificar el conocimiento en DOO (figura 1).

Tabla 1. Conocimiento representativo.

3. Ontología del DOO

La construcción de la ontología propuesta se ha basado en el proceso Helix-Spindle (Kishore, Zhang, & Ramesh, 2004). La primera versión se centró en las relaciones entre patrones y reglas (Garzás & Piattini, 2005). Como resultado de esta versión se desarrolló la segunda versión enfocada en una descripción global del conocimiento general en diseños OO (Garzás & Piattini, 2005). La tercera versión (que presentamos en este artículo), está enfocada en una descripción integral y completa del conocimiento en diseño OO, incluyendo conocimiento de uso general, en dominios concretos y para tecnologías específicas.

3.1 . Entidades del conocimiento en diseño de micro arquitecturas OO

Los elementos del conocimiento en DOO pueden estar organizados en grupos, basados en sus características similares. Y aunque existen muchos términos asociados al conocimiento en DOO (como por ejemplo patrones, heurísticas, etc.) hemos podido observar que todos ellos pueden ubicarse dentro de dos grupos principales: conocimiento declarativo u operativo.

3.1.1. Conocimiento declarativo

Los elementos declarativos son conceptos que describen qué hacer con un problema, y elementos como las heurísticas, patrones, malos olores, mejores prácticas, etc., se sitúan dentro de este grupo. No obstante, estos elementos declarativos pueden tener carácter u objetivos diferentes. Aun cuando grupos de patrones como los de (Gamma, Helm, Johnson, & Vlissides, 1995) son bien conocidos y de aplicación general en todos los diseños, en proyectos reales necesitaremos usar otro conocimiento más particular e igualmente importante (por ejemplo patrones para tecnología J2EE o principios de la tecnología .Net) o conocimiento asociado a un dominio concreto (por ejemplo patrones de tiempo real o principios de integración). De esta forma, el conocimiento declarativo puede ser descompuesto en tres subcategorías: general, tecnológico y dominio.

Figura 1. Ontología del conocimiento en diseño orientado a objetos

Por otro lado, aunque hay numerosa terminología diferente, términos como heurística, malo olor, mejor práctica, principio, etc., tienen una estructura general que coincide con la de una regla, donde frente a una condición ofrecen una recomendación, con lo que podemos agruparlos de forma unificada dentro del término regla. Conviene insistir en que las reglas son diferentes a los patrones, ya que las reglas están más basadas en el uso del lenguaje natural (el cual puede ser ambiguo), los patrones están más formalizados que las reglas y la descripción de los patrones es siempre más amplia.
En resumen, los elementos declarativos pueden estar divididos en tres grupos de conocimiento, general, tecnológico y dominio, y cada uno de estos, a su vez, en reglas y patrones (ver Figura 1).

3.1.2 Conocimiento operativo

Los elementos operativos acumulan conocimiento referente a operaciones o procesos que permiten realizar cambios en diseños. Las refactorizaciones (transformación parametrizada de un programa preservando su funcionalidad (Opdyke, 1992)) de diseño se ubican dentro de este grupo.

3.2. Atributos del conocimiento en diseño de micro arquitecturas

Para completar la descripción de las entidades nos centramos en sus atributos. Para ello nos hemos basado en las secciones que el catálogo de (Gamma et al., 1995) utiliza para describir un patrón. Según esto observamos como todos los elementos del conocimiento tienen un nombre, propósito, también conocido como, motivación, aplicabilidad, consecuencias y usos conocidos (ver Figura 1). Y de forma más particular situamos en el conocimiento declarativo el atributo participantes (clases y/u objetos participantes en el patrón o regla y sus responsabilidades) y colaboraciones. Otros atributos interesantes son estructura representando la solución en un patrón, y recomendación para reglas. El conocimiento operativo contiene el atributo ejemplo de diseño y las refactorizaciones el de mecánica, nombre tomado del catálogo de refactorizaciones de (Fowler, Beck, Brant, Opdyke, & Roberts, 1999).

3.3. Relaciones entre el conocimiento de diseño

Por otro lado, entre los elementos del conocimiento existen diversas relaciones, difíciles de apreciar sin una clara división de los mismos. Tomando en consideración que los elementos del conocimiento en diseño pueden estar organizados en dos entidades principales, conocimiento declarativo y operativo, y que el conocimiento declarativo puede estar organizado en conocimiento general, tecnológico y de dominio, donde cada uno de estos, a su vez, se descompone en reglas y patrones, podemos encontrar las siguientes relaciones.

3.3.1. Relaciones entre conocimiento declarativo y operativo

Las refactorizaciones almacenan conocimiento sobre cómo introducir elementos en diseños de una forma controlada y el conocimiento declarativo (Reglas y Patrones) es introducido en el diseño por conocimiento operativo (refactorización). En este caso, podemos decir que: el conocimiento declarativo es introducido por conocimiento operativo.

Cardinalidades
Las cardinalidades de la relación entre el conocimiento operativo y declarativo son 0..n y 1..n. El conocimiento declarativo debe estar asociado a uno o más elementos del conocimiento operativo (1..n), (no tiene sentido que existan elementos declarativos que no puedan ser introducidos en un diseño), y el conocimiento operativo puede estar implicado por ninguno o muchos elementos del conocimiento declarativo.

Ejemplos
Refactorizaciones como “Replace Type Code with State/Strategy” o “Form Template Method” (Fowler et al., 1999) se centran en la introducción de patrones. Más aún, observamos que las reglas pueden ser introducidas en el diseño por medio de refactorizaciones, así, por ejemplo, la regla de “Dependency Inversion” (Martin, 1996) propone insertar una entidad abstracta dentro de un diseño, la cual se introduce mediante refactorizaciones.

3.3.2. Relaciones entre reglas y patrones

Como hemos dicho, el conocimiento declarativo está descompuesto en conocimiento general, de dominio y tecnológico, y, a su vez, cada uno de estos en reglas y patrones. En cualquier caso, entre cada par regla – patrón hay dos clases de relaciones: las reglas implican patrones y los patrones cumplen las reglas.

Figura 2. Ejemplo de relaciones entre el conocimiento

Reglas implican patrones

A menudo, cuando introducimos una regla obtenemos un nuevo diseño, el cual necesita un patrón. Podemos observar esta relación entre reglas y patrones para las tres clases de conocimiento declarativo (general, dominio y tecnológico) Podemos decir que: aplicar una regla implica el uso de un patrón (ver figura 2).

Cardinalidades
Las cardinalidades de esta relación son 0..n y 0..n. No todas las reglas implican la introducción de un patrón (un ejemplo de ello es la aplicación de reglas que trabajan a nivel interno de un módulo) y no todos los patrones están implicados por reglas.

Ejemplos
En el conocimiento declarativo de carácter general, un ejemplo es la regla de “Dependency Inversion” (Martin, 1996), que introduce un elemento abstracto que a su vez necesita un patrón creacional (Gamma et al., 1995) para crear instancias y objetos asociados en la nueva situación. Reglas de dominios específicos como las reglas de tiempo real implican el uso de patrones de tiempo real, ejemplo es la regla de “If it is too complex to permit a static allocation of object and it cannot deal with dynamic memory allocation then use a pool allocation” que implica el uso de “Pool Allocation (real time) Pattern” (Powel Douglass, 2002). En el conocimiento tecnológico, podemos ver reglas de J2EE que implican el uso de patrones J2EE. Por ejemplo, (Alur, Malks, & Crupi, 2003) presenta una lista de “requisitos comunes” o “motivaciones” (otra forma de nombrar las reglas de conocimiento en diseño) que implican a uno o más patrones J2EE. En esta lista podemos ver como la regla de “If you have a lot of entity beans then reduce number of entity beans and improve manageability” o la regla de “If you have entity bean to entity bean remote relationships then reduce or eliminate these remote relationships” implican el uso de “Composite Entity (J2EE) Pattern”.

Patrones que cumplen Reglas

El objetivo de aplicar reglas de diseño es aumentar la calidad del diseño. Las reglas de diseño son elementos que podemos encontrar dentro de micro arquitecturas de calidad. Los patrones son micro arquitecturas de calidad, probadas por la experiencia, con lo que tiene sentido decir que los patrones de diseño cumplen reglas de diseño. En este caso: los patrones cumplen reglas.

Cardinalidades
Las cardinalidades en esta relación son 0..n y 0..n. No todas las reglas son cumplidas en un patrón de diseño, y un patrón de diseño puede cumplir cero o muchas reglas.

Ejemplos
Muchos patrones, tales como Observer, State (Gamma et al., 1995), etc., cumplen varias reglas, entre otras la regla de “Dependency Inversion” (Martin, 1996).

Relaciones entre patrones
Todas las entidades patrón (patrones generales, de dominio y tecnológicos) tienen una relación reflexiva, esto es: aplicar un patrón implica el uso de otro patrón (ver figura 2).

Cardinalidades
Las cardinalidades de aplicar un patrón implica el uso de otro Patrón son 0..n y 0..n. No todos los patrones implican otro patrón y no todos los patrones están implicados por patrones.

Ejemplos
En patrones comunes un ejemplo es el mapa de relaciones entre patrones presentado por (Gamma et al., 1995). Para patrones tecnológicos podemos ver como “EJB Home Factory (J2EE) Pattern” implica el uso de “Service Locator (J2EE) Pattern” (Marinescu, 2002). Y en patrones de dominio podemos ver como “Critical Section (real time) Pattern” implica el uso de “Concurrency (real time) Pattern” (Powel Douglass, 2002).

3.3.3. Relaciones entre conocimiento operativo

Las entidades del conocimiento operativo tienen una relación reflexiva de composición, esto es: un elemento del conocimiento operativo está compuesto de otros.

Cardinalidades
Las cardinalidades son 0..n y 0..n. Hay conocimiento operativo atómico y que no está compuesto por otros.

Ejemplos
Pueden encontrarse en los catálogos de refactorizaciones como el de (Fowler et al., 1999), donde, por ejemplo, la refactorización "Extract Method" es usada por otras refactorizaciones, pero no usa a otras.

3.3.4. Relaciones entre patrones comunes, dominio y tecnológicos

Los patrones comunes son de uso general en todos los diseños, y tanto los patrones de dominio como los tecnológicos pueden implicar el uso de patrones comunes (ver figuras 1 y 2).

Los patrones de dominio implican el uso de patrones generales

Muchos patrones de dominio implican el uso de patrones generales.

Cardinalidades
Las cardinalidades son 0..n y 0..n.

Ejemplos
Patrones de dominio como los de tiempo real implican el uso de patrones generales. Por ejemplo, podemos ver como “Pool Allocation Pattern” (Powel Douglass, 2002), una aproximación para gestionar la asignación de memoria, puede ser usado con “Abstract Factory (common) Pattern” (Gamma et al., 1995) para proveerle operatividad en diferentes entornos.

Patrones tecnológicos implican el uso de patrones generales

Adicionalmente, muchos patrones tecnológicos implican el uso de patrones generales.

Cardinalidades
Las cardinalidades son 0..n y 0..n.

Ejemplos
El patrón “J2EE Command” (Marinescu, 2002) implica el uso de “Command Pattern” (Gamma et al., 1995); “J2EE Home Factory” (Marinescu, 2002) o “Client Side EJB Interaction” implican el uso de “Abstract Factory Pattern” (Gamma et al., 1995); y “Session Facade” (Marinescu, 2002) implica a “Facade Pattern” (Gamma et al., 1995).

4. Mejora del diseño OO usando la ontología propuesta

Las ontologías pueden ser aplicadas en una amplia variedad de contextos con varios propósitos, de forma general pueden ser usadas para mejorar la comunicación entre humanos y máquinas, para lograr interoperabilidad, mejorar procesos y la calidad de un sistema de software (Jasper & Uschold, 1999). De manera más específica, pensamos que la ontología propuesta puede ser útil en diferentes áreas:

4.1. Formación y comunicación

Frecuentemente los conceptos asociados al conocimiento en diseño OO se expresan usando un vocabulario poco familiar o en un formato poco accesible. La ontología proporciona una terminología general, proporcionando comprensión, eliminando la barrera creada por distintos vocabularios y aproximaciones, y eliminando ambigüedades. También se puede facilitar la formación en DOO usando una ontología y catalogando el conocimiento de forma unificada en base a la ontología (como resultado de la ontología hemos desarrollado un catálogo unificado o reglas de conocimiento (Garzás & Piattini, 2005))

4.2. Nexo de unión del conocimiento en DOO

La ontología puede ser usada como punto común entre distintos métodos OO, lenguajes OO, herramientas software OO, etc. Los beneficios de esta aproximación incluyen interoperabilidad y mejor uso de los recursos del conocimiento.

4.3. Reutilización del conocimiento

La ontología propone una codificación sistemática para las entidades del conocimiento en DOO, sus atributos y sus relaciones. Esta representación forma un bloque de construcción común a para una gran variedad de diseños.

4.4. Adquisición y búsqueda del conocimiento

La ontología puede ser usada como meta-datos en un repositorio de conocimiento de diseño. Los beneficios de esta aproximación son un acceso más rápido y eficiente al conocimiento en diseño.

4.5. Mejora del diseño y mantenimiento

Los elementos que forman la ontología son elementos de calidad contrastada, por lo que pueden ayudar a identificar requisitos y definir especificaciones de diseño. Los sistemas basados en la ontología pueden mejorar la documentación y reducir los costes de mantenimiento, particularmente combinando la ontología de diseño OO con otras propuestas para el mantenimiento (Ruiz, A, Piattini, & Garcia, 2004).

4.6. Dar soporte a la toma de decisiones

Los razonamientos que llevan a crear un determinado diseño (design rationale (DR) en terminología inglesa) son las decisiones realizadas durante el proceso de diseño, las razones subyacentes, su justificación, alternativas consideradas, etc. (Lee, 1997). Desafortunadamente estas decisiones no se suelen recoger, haciendo muy difícil entender con posterioridad las razones de una determinada solución (IEEE/EIA, 1998). El conocimiento OO puede ser asociado al registro razonamientos, apoyando así las decisiones tomadas.

5. Conclusiones

Hoy en día la comunidad dedicada al diseño OO dispone de una gran cantidad y variedad de conocimiento práctico acumulado, pero desafortunadamente los mismos problemas de diseño siguen repitiéndose una y otra vez en proyectos reales. Y es que, en nuestra opinión, no se ha investigado suficientemente en cómo usar el conocimiento disponible en DOO. En este artículo proponemos una ontología que permite organizar el conocimiento tanto declarativo como operativo de DOO, ya sea general, tecnológico o de dominio. Esta ontología pretende mejorar el DOO aportando ventajas en la formación de los ingenieros de software, en la explotación del conocimiento y en el registro de las decisiones tomadas durante el DOO.

Referencias

Alur, D., Malks, D., & Crupi, J. (2003). Core J2EE™ Patterns: Best Practices and Design Strategies (Second Edition ed.): Prentice Hall

Fowler, M., Beck, K., Brant, J., Opdyke, W., & Roberts, D. (1999). Refactoring: Improving the Design of Existing Code (1st edition ed.): Addison-Wesley Professional.

Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Design Patterns: Addison-Wesley Professional.

Garzás, J., & Piattini, M. (2005). An ontology for micro-architectural design knowledge. IEEE Software Magazine, 22(2), 28-33.

Glass, R. L., & Vessey, I. (1995). Contemporary Application - Domain Taxonomies. IEEE Software, 12(4), 63-76.

IEEE/EIA. (1998). IEEE/EIA 12207.1-1997. IEEE/EIA Guide Industry Implementation of International Standard ISO/IEC 12207 Standard for Information Technology—Software life cycle processes. Life cycle data: Institute of Electrical and Electronics Engineers, Inc.

Jasper, R., & Uschold, M. (1999). A Framework for Understanding and Classifying Ontology Applications. Paper presented at the Twelfth Workshop on Knowledge Acquisition Modeling and Management KAW'99, Canada.

Kishore, R., Zhang, H., & Ramesh, R. (2004). A Helix-Spindle Model for Ontological Engineering. Communications of the ACM, 47(2).

Lee, J. (1997). Design Rationale Systems: Understanding the Issues. IEEE Expert: Intelligent Systems and Their Applications, 12(3), 78-85.

Mansfield, R. (2005). OOP Is Much Better in Theory Than in Practice, devx.com.

Marinescu, F. (2002). EJB Design Patterns. Advanced Patterns, Processes and Idioms: John Wiley and Sons.

Martin, R. C. (1996). The dependency inversion principle. C++ Report, 8(6), 61-66.

Opdyke, W. (1992). Refactoring Object Oriented Frameworks. Illinois, Urbana-Champain.

Powel Douglass, B. (2002). Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems: Addison-Wesley Professional.

Ruiz, F., A, V., Piattini, M., & Garcia, F. (2004). An ontology for the management of software maintenance projects. International Journal of Software Engineering and Knowledge, 14(3), 323-349.

Histórico

Abril 07: Primera publicación

Esta obra está bajo una licencia de Creative Commons.