El Conocimiento en Diseño Orientado a Objetos 1 y 2

El Conocimiento en Diseño Orientado a Objetos 1 y 2 Javier Garzás, Mario Piattini www.kybeleconsulting.com http://kybeleconsulting.blogspot.com/ 1 INTRODUCCIÓN En los últimos años se han incorporado importantes contribuciones al campo del diseño orientado a objetos (OO), proponiéndose técnicas de modelado, metodologías, patrones, métricas, etc., con el fin de facilitar la evolución y mejora del diseño software. De esta forma, hoy disponemos de elementos de conocimiento en diseño OO muy populares, como son los patrones y las refactorizaciones, junto con otros muchos menos conocidos pero igualmente importantes, como son principios, heurísticas, malos olores (bad smells), etc. Sin embargo, y a pesar de los más de 30 años de experiencia en tecnología de objetos, los beneficios prácticos de esta tecnología aún se cuestionan (Mansfield, 2005). En nuestra opinión, esto de debe en parte a que el conocimiento acumulado en diseño orientado a objetos (DOO) carece de suficiente estructura y clasificación. El conocimiento en DOO, no es fácilmente transmisible, accesible o disponible. Y el conocimiento sin organización es, en la mayoría de las ocasiones, conocimiento desaprovechado, por lo que seguir acumulando este tipo de conocimiento es un esfuerzo inútil, condenando a los profesionales del software a seguir resolviendo los mismos problemas, sin poder contar con las soluciones que ya han sido aportadas varios años antes. Y así en la actualidad observamos con frecuencia la pobre aplicación de patrones, principios, mejores prácticas, etc., desaprovechando esa importante cantidad de experiencia en las organizaciones de desarrollo software. Para resolver estos problemas hemos propuesto una ontología que organiza y estructura el conocimiento en diseño OO. 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 1 Esta obra está bajo una licencia de Creative Commons: Reconocimiento-No comercial-compartir bajo la misma licencia 2.5 España (ver http://creativecommons.org/licenses/by-nc-sa/2.5/es/) 2 Este artículo es un extracto de Garzás, J., & Piattini, M. (2007). An Ontology for Understanding and Applying Object-Oriented Design Knowledge. International Journal of Software Engineering and Knowledge Engineering (IJSEKE), 17(3). 1

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). Enfoque Uso General Comunicaciones Tecnología J2EE Tecnología.NET Tiempo real Integración Datos Programación paralela Referencia Gamma, E., et al. (1995), Design Patterns, Addison-Wesley Professional. Rising, L. (ed.), Design Patterns in Communications Software. SIGS, 2001. Broemmer, D. J2EE Best Practices. Java Design Patterns, Automation and Performance. Wiley, 2003. Metsker, S.J. Design Patterns C#. Addison- Wesley Professional, 2004. Powel Douglass, B. Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems. Addison-Wesley Professional, 2002. Hohpe, G. and Woolf, B. Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley Professional, 2003. Nock, C. Data Access Patterns: Database Interactions in Object-Oriented Applications. Addison-Wesley Pub Co, 2003. Mattson, T.G., Sanders, B.A. and Massingill, B.L. Patterns for Parallel Programming. Addison-Wesley Professional, 2004. Tabla 1. Conocimiento representativo 2

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. 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

Figura 1. Ontología del conocimiento en diseño orientado a objetos 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). 4

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. 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. 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. 5

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). 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. 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 6

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. 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. 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). 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. 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. Las cardinalidades son 0..n y 0..n. Hay conocimiento operativo atómico y que no está compuesto por otros. 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. 7

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. Las cardinalidades son 0..n y 0..n. 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. Las cardinalidades son 0..n y 0..n. 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 8

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 9

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. 6 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. 10