Universidad de San Carlos de Guatemala Facultad de Ingeniera Escuela de Ingeniera en Ciencias y Sistemas

REUTILIZACIN DEL SOFTWARE, METODOLOGAS Y APLICACIONES MS FRECUENTES

Carlos Estuardo Figueroa Santiago Asesorado por el Ing. Calixto Raul Monzon Prez

Guatemala, mayo de 2010

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA

FACULTAD DE INGENIERA

REUTILIZACIN DEL SOFTWARE, METODOLOGAS Y APLICACIONES MS FRECUENTES

TRABAJO DE GRADUACIN PRESENTADO A LA JUNTA DIRECTIVA DE LA FACULTAD DE INGENIERA POR:

CARLOS ESTUARDO FIGUEROA SANTIAGO

ASESORADO POR EL ING. CALIXTO RAUL MONZON PREZ

AL CONFERRSELE EL TTULO DE

INGENIERO EN CIENCIAS Y SISTEMAS

GUATEMALA, MAYO DE 2010

UNIVERSIDAD DE SAN CARLOS DE GUATEMALA FACULTAD DE INGENIERA

NMINA DE JUNTA DIRECTIVA

DECANO VOCAL I VOCAL II VOCAL III VOCAL IV VOCAL V SECRETARIA Ing. Murphy Olympo Paiz Recinos Inga. Glenda Patricia Garca Soria Inga. Alba Maritza Guerrero de Lpez Ing. Miguel Angel Dvila Caldern Br. Luis Pedro Ortz de Len Agr. Jos Alfredo Ortz Herincx Inga. Marcia Ivnne Vliz Vargas

TRIBUNAL QUE PRACTIC EL EXAMEN PRIVADO

DECANO EXAMINADOR EXAMINADOR EXAMINADOR SECRETARIA Ing. Murphy Olympo Paiz Recinos Ing. Juan Alvaro Daz Ardavn Ing. Pedro Pablo Hernandez Ramrez Ing. Ludwing Federico Altan Sac Inga. Marcia Ivnne Vliz Vargas

DEDICATORIA A:
DIOS Y A LA VIRGEN MARA Por haberme dado una vida llena de bendiciones y por haberme permitido llegar a este momento de mi vida. MIS PADRES Dr. Carlos Alfredo Figueroa Ramirez y de forma especial a mi mam Licda. Mara Asenneth Santiago de Figueroa. MIS HERMANOS Francisco Alfredo y Mara Asenet de los Angeles, por su apoyo y cario. MIS SOBRINOS Y CUADOS Nahbi Magdiel, Iram Didier y Silvia, por su cario y dulzura. MIS ABUELAS Angelina Ramirez de Figueroa (q.e.p.d) y Delia Paniagua de Gudiel, por sus oraciones en el cielo y en la tierra. MI FAMILIA Abuelos, tos, tas, primos y dems familia por su apoyo y cario. MIS AMIGOS Por su amistad, compaerismo y tantos momentos compartidos.

AGRADECIMIENTOS A:
DIOS Y A LA VIRGEN MARA Por darme la vida, por saberme guiar por el buen camino, por no abandonarme, por permitirme llegar a este da y alcanzar este objetivo en mi vida. MIS PADRES Dr. Carlos Alfredo Figueroa Ramirez con su ejemplo, alegra y sabidura; y muy especialmente a mi mam Licda. Mara Asenneth Santiago de Figueroa, por formar valores y principios y mostrarme con su entereza, dedicacin, esfuerzo y amor que son unas personas maravillosas, una bendicin de Dios para m. MI ASESOR Ing. Calixto Monzon, por su apoyo, tiempo, experiencia profesional y paciencia en revisar este trabajo de graduacin. LA UNIVERSIDAD DE SAN CARLOS DE GUATEMALA Por albergarme en su seno como estudiante. LA FACULTAD DE INGENIERA Por brindarme los conocimientos necesarios para graduarme como ingeniero. PUEBLO DE GUATEMALA Al cual los estudiantes y profesionales de la Universidad de San Carlos nos debemos.

NDICE GENERAL
NDICE DE ILUSTRACIONES....................... VII GLOSARIO........................................................................................................ IX RESUMEN...................................................................................................... XVII OBJETIVOS ................................................................................................... XIX INTRODUCCIN............................................................................................. XXI 1 MARCO TERICO: CONCEPTOS BSICOS DE LA REUTILIZACIN.. 1 1.1 Beneficios de la reutilizacin . 1 1.1.1 Tiempo . 1 1.1.2 Calidad .... 1 1.1.3 Estandarizacin . 2 1.2 Barreras a la reutilizacin .. 2 1.2.1 Elaboracin, administracin y uso de componentes reutilizables . 3 1.2.2 Gastos al comenzar ...... 3 1.2.3 Reto a los mtodos tradicionales de ingeniera de software .. 4 1.3 Reutilizacin prctica de software 4 1.3.1 Prcticas de desarrollo con reutilizacin ... 5 1.3.1.1 Tecnologas orientadas a objetos ..... 5 1.3.1.2 Desarrollando con reutilizacin reutilizacin oportunista.. 6 1.3.1.3 Desarrollando con reutilizacin: reutilizacin sistemtica.. 7 1.3.2 Prcticas sin desarrollo con reutilizacin del producto ... 8 2 INGENIERA DE DOMINIOS........ 9 2.1 Dominio . 9 2.1.1 Definicin de dominio ... 9 2.1.2 Relacin entre dominios y aplicaciones ... 11 2.1.3 Dominios verticales y horizontales 11 2.2 Ingeniera de dominios e ingeniera de aplicacin.. 12 I

2.3 Anlisis del dominio, diseo del dominio e implementacin del dominio ...... 14 2.3.1 Anlisis del dominio ....... 14 2.3.2 Diseo del dominio .. 19 2.3.3 Implementacin del dominio .. 20 2.4 Distincin de trminos relacionados . 21 2.4.1 Lnea de producto ... 21 2.4.2 Ingeniera de requerimientos . 21 2.4.3 Ingeniera de reutilizacin... 22 2.4.4 Arquitecturas de software especficas de dominio . 23 2.4.5 Arquitectura de referencia ......... 23 2.5 Mtodos de ingeniera de dominios ......... 24 2.6 Ingeniera de dominios y metodologas orientadas al anlisis y diseo orientados a objetos (OOA/D) ....... 27 2.6.1 Defectos en los mtodos OOA/D existentes .. 27 2.6.2 Metodologas OOA/D apoyando a la ingeniera de dominios .. 28 2.7 Problemas emergentes ... 32 3 PRINCIPIOS DEL ANLISIS Y DISEO ORIENTADO AL OBJETO PARA REUTILIZACIN....... 35 3.1 El principio de abierto/cerrado ....... 35 3.1.1 Polimorfismo dinmico.... ... 36 3.1.2 Polimorfismo esttico .. 39 3.1.3 Metas arquitectnicas del PAC ..... 40 3.2 El principio de sustitucin de Liskov ..... 40 3.2.1 El dilema del crculo / elipse ...... 41 3.2.2 Diseo por contrato .... 45 3.3 El principio de inversin de dependencia ........ 45 3.3.1 Mitigando fuerzas ........ 47 3.3.2 Creacin del objeto ..... 48

II

3.4 El principio de separacin de la interfaz ...... 48 3.4.1 Qu significa especfico del cliente? ..... 50 3.4.2 Cambiando interfaces ..... 50 3.5 El principio de equivalencia reutilizacin/publicacin......... 51 3.6 El principio de cierre comn ... 52 3.7 El principio de reutilizacin comn .... 52 3.7.1 Tensin entre los principios de cohesin de paquetes ..... 53 3.8 El principio de dependencia acclica . 54 3.8.1 Un ciclo se introduce ... 55 3.8.2 Quebrando un ciclo ........ 57 3.9 El principio de las dependencias estables ... 59 3.9.1 Estabilidad ........ 60 3.9.2 Mtricas de estabilidad ... 61 3.9.3 Fundamento ..... 62 3.10 El principio de las abstracciones estables .... 63 3.10.1 Mtricas de abstraccin ....... 64 3.10.2 La grfica de I versus A ....... 65 3.10.3 Mtricas de distancia .... 67 4 MTODOS DE REUTILIZACIN DE SOFTWARE ......... 69 4.1 Mtodos generativos de reutilizacin ....... 69 4.1.1 Sistemas basados en lenguaje ..... 70 4.1.2 Generadores de aplicacin .... 71 4.1.3 Sistemas transformacionales . 72 4.2 Mtodos composicionales de reutilizacin .. 73 4.2.1 Reutilizacin dentro de la metodologa orientada a objetos . 82 4.2.2 Reusabilidad de objetos . 83 4.2.3 Reutilizacin de clases ... 83 4.2.4 Reutilizacin en el mundo .. 86 4.2.5 Marcos de trabajo de aplicacin ... 87

III

4.2.6 Patrones de diseo . 89 5 EJEMPLOS DE REUTILIZACIN COMPOSICIONAL CON PATRONES DE DISEO EN PHP........ 93 5.1 Uso del patrn de diseo observer ...... 93 5.1.1 El problema ...... 93 5.1.2 La solucin ...... 94 5.1.3 Cdigo de ejemplo ..... 94 5.1.4 Explicacin del ejemplo ...... 97 5.2 Uso del patrn de diseo factory ... 99 5.2.1 El problema ...... 99 5.2.2 La solucin ....... 99 5.2.3 Cdigo de ejemplo ........ 100 5.2.4 Explicacin del ejemplo ........... 105 5.3 Uso del patrn strategy ............... 106 5.3.1 El problema ........ 107 5.3.2 La solucin ......... 107 5.3.3 Cdigo de ejemplo ........ 108 5.3.4 Explicacin del ejemplo .... 112 5.4 Uso del patrn de diseo adapter .. 113 5.4.1 El problema .....113 5.4.2 La solucin ......113 5.4.3 Cdigo de ejemplo .....114 5.4.4 Explicacin del ejemplo .....119 5.5 Uso del patrn de diseo singleton ........ 120 5.5.1 El problema .... 121 5.5.2 La solucin 121 5.5.3 Cdigo de ejemplo ... 121 5.5.4 Segundo ejemplo ..... 124 5.5.5 Explicacin del segundo ejemplo ..... 125

IV

CONCLUSIONES . 127 RECOMENDACIONES ....... 129 BIBLIOGRAFA .... 131

VI

NDICE DE ILUSTRACIONES
FIGURAS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Logueo cerrado para modificacin Esquema de principio de sustitucin de Liskov Dilema del crculo y el elipse Declaracin del elipse Estructura de dependencia de una arquitectura procedural Estructura de dependencia de una arquitectura orientada a objetos Servicio grande con interfaces integradas Interfaces separadas Red de paquetes acclicos Un ciclo ha sido agregado Ciclo quebrado Otra tcnica X es un paquete estable Y es un paquete inestable Violacin del principio de dependencias estables Grfica de A versus I Dnde debera ir X en la grfica A vs I? ListaClientes y su ListaSuscripcion con bitcora agregada Las clases Registro y FabricaRegistro Relacin entre objetos ElegidorCarro, MedidorCarro y Carro El adaptador situado entre la grfica y los datos UML para el singleton manejador de base de datos 47 49 50 55 56 58 59 60 61 63 65 66 96 101 108 115 122 39 38 42 43 46

VII

TABLA I Documento de elementos 16

VIII

GLOSARIO
ADA:1

Ada es un lenguaje de programacin estructurado y fuertemente tipado de forma esttica que fue diseado por Jean Ichbiah de CII Honeywell Bull por encargo del Departamento de Defensa de los Estados Unidos. Es un lenguaje multipropsito, orientado a objetos y concurrente, pudiendo llegar desde la facilidad de Pascal hasta la flexibilidad de C++.

API:2

Application Programming Interface. Una interfaz de programacin de aplicaciones o API (del ingls) es el conjunto de funciones y procedimientos (o mtodos, en la programacin orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstraccin. Usados generalmente en las bibliotecas.

CCM:

CORBA Component Model. Modelo de componentes CORBA, es una especificacin para crear del lado del servidor aplicaciones escalables, neutrales al lenguaje, transaccionales, multiusuario y seguras a nivel de empresas.

COM:3

Component Object Model. Es una plataforma de Microsoft para componentes de software introducida por dicha empresa en 1993. Esta plataforma es utilizada para permitir la comunicacin entre procesos y la creacin dinmica de objetos, en cualquier lenguaje de programacin que soporte dicha tecnologa. El trmino COM

1 2

http://es.wikipedia.org/wiki/Ada_%28lenguaje_de_programaci%C3%B3n%29 http://es.wikipedia.org/wiki/Interfaz_de_programaci%C3%B3n_de_aplicaciones 3 http://es.wikipedia.org/wiki/Component_Object_Model

IX

es a menudo usado en el mundo del desarrollo de software como un trmino que abarca las tecnologas OLE, OLE Automation, ActiveX, COM+ y DCOM. Si bien COM fue introducido en 1993, Microsoft no hizo nfasis en el nombre COM hasta 1997. CORBA:4 Common Object Request Broker Architecture. Arquitectura comn de intermediarios en peticiones a objetos, es un estndar que establece una plataforma de desarrollo de sistemas distribuidos facilitando la invocacin de mtodos remotos bajo un paradigma orientado a objetos. CORBA se puede considerar como un formato de documentacin legible por la mquina, similar a un archivo de cabeceras, pero con ms informacin. DAGAR: Domain Architecture-based Generation for Ada Reuse.

Generacin de dominio basada en arquitectura para reutilizacin de ADA, es un proceso desarrollado por el equipo de Loral Defense Systems-East STARS. DAGAR es un proceso repetible y documentado acompaado por herramientas, incluye el desarrollo de una arquitectura de dominio, implementacin de activos dentro de la arquitectura, y aplicacin del dominio a travs de la seleccin de activos para una aplicacin particular. FeatuRSEB: Featured Reuse-driven Software Engineering Business. Es un

proceso basado en casos de uso para desarrollo de sistemas grandes de compaas, como una combinacin de RSEB y FODA para identificar los problemas especficos de la familia de sistemas. FeatuRSEB defini casos de uso ampliados en la fase de ingeniera de requerimientos. Con un punto de variacin en los
4

http://es.wikipedia.org/wiki/CORBA

casos de uso, FeatuRSEB modela opciones de diferente comportamiento. Despus de la fase de modelado el desarrollador tiene que seleccionar el comportamiento necesario para obtener una instancia vlida del modelo. FODA: Feature-Oriented Domain Anlisis. Anlisis de dominio orientado a las caractersticas, es un mtodo de anlisis de dominio que se enfoca en las caractersticas de los sistemas del dominio. Una caracterstica es, de acuerdo a FODA, un aspecto, cualidad, o rasgo de un sistema que es visible al usuario final. La transmisin de una auto (automtico o manual) es un ejemplo de una caracterstica. FORM : Feature-Oriented Reuse Method. Mtodo de reutilizacin

orientado a las caractersticas, es un mtodo sistemtico que busca y captura cosas en comn y diferencias de aplicaciones en un dominio en trminos de caractersticas y utilizando los resultados de los anlisis para desarrollar arquitecturas de dominios y componentes. El modelo que captura las cosas en comn y las diferencias es llamado modelo de caractersticas y es usado para apoyar tanto a la ingeniera de artefactos reutilizables de dominio como al desarrollo de aplicaciones que usan los artefactos de dominio. Una vez que un dominio es descrito y explicado en trminos de unidades comunes y diferentes de computacin, son utilizados para construir diferentes configuraciones factibles de arquitecturas reutilizables.

XI

GLITTER:

Es

un

sistema

transformacional

que

codifica

en

reglas

transformacionales decisiones que un desarrollador de software ha hecho durante sus aplicaciones. JIAWG: The Joint Integrated Avionics Working Group. Grupo de trabajo conjunto integrado de aviacin es un esfuerzo ordenado por el congreso de EEUU que ha sido formado para coordinar tecnologa, compartir datos, reducir duplicacin y resolver problemas comunes de los componentes. JODA: JIAWG Oriented Domain Anaysis. Es un mtodo que es utilizado por el JIAWG para el anlisis del dominio. Este mtodo est basado en el anlisis orientado a objetos y la notacin definida por Coad y Yourdon, las cuales son referidas como Coad Yourdon Object Oriented Anlisis (CYOOA). Este mtodo adiciona ciertas extensiones ya que la notacin original est hecha para la construccin de un nico sistema. CYOOA fue mejorada para validar y demostrar la efectividad de tcnicas orientadas a objetos para soportar el anlisis de dominio. MDA:5 Model-Driven Architecture. La arquitectura dirigida por modelos es un acercamiento al diseo de software, propuesto y patrocinado por el Object Managemente Group. MDA se ha concebido para dar soporte a la ingeniera dirigida a modelos de los sistemas software. MDA es una arquitectura que proporciona un conjunto de guas para estructurar especificaciones expresadas como modelos.
5

http://es.wikipedia.org/wiki/Model_Driven_Architecture

XII

OMG:6

Object Management Group. Grupo de gestin de objetos, es un consorcio dedicado al cuidado y el establecimiento de diversos estndares de tecnologas orientadas a objetos, tales como UML, XMI, CORBA. Es una organizacin sin nimo de lucro que promueve el uso de tecnologa orientada a objetos mediante guas y especificaciones para las mismas. El grupo est formado por compaas y organizaciones de software como: Packard (HP), IBM, Sun Microsystems, Apple Computer. Hewlett-

OOram:

Object Oriented Role Analysis Method. Mtodo de anlisis de roles orientado a objetos es un mtodo, basado en el concepto de rol, para ejecutar modelado orientado a objetos. OOram es el precursor del Lenguaje Unificado de Modelado (UML). OOram fue originalmente desarrollado por Trygve Reenskaug (1996), un profesor de la Universidad de Oslo y el fundador de la compaa noruega de informtica Taskon.

PADDLE:

Es un sistema transformacional que guarda una historia de desarrollo como una secuencia de transformaciones aplicadas.

PHP:7

PHP es un lenguaje de programacin interpretado, diseado originalmente para la creacin de pginas web dinmicas. Es usado principalmente en interpretacin del lado del servidor pero actualmente puede ser utilizado desde una interfaz de lnea de comandos o en la creacin de otros tipos de programas incluyendo aplicaciones con interfaz grfica usando las bibliotecas

6 7

http://es.wikipedia.org/wiki/Object_Management_Group http://es.wikipedia.org/wiki/PHP

XIII

Qt o GTK+. PHP es un acrnimo recursivo que significa PHP Hypertext Pre-processor (inicialmente PHP Tools, o, Personal Home Page Tools). REBOOT: REuse Based on Object-Oriented Techniques. Reutilizacin basada en tcnicas orientadas a objetos, es proyecto cuyos objetivos son estudiar, desarrollar y diseminar metodologas avanzadas para desarrollo de software dirigidas a reutilizacin y orientadas a objetos con nfasis en reutilizacin planificada. El proyecto ha desarrollado dos modelos (desarrollo para reutilizacin y desarrollo con reutilizacin) que incorporan actividades especficas de reutilizacin en todas las fases del ciclo de vida de desarrollo, y un conjunto de herramientas (en entorno REBOOT) que respalda estos dos modelos y ayuda a una organizacin a administrar una librera de componentes reutilizables. Estos modelos y el entorno son fuertemente dependientes de la definicin que se tenga de componente reutilizable. RSEB: Reuse-Driven Software Engineering Business. Negocio de ingeniera de software dirigido por reutilizacin, es un proceso de reutilizacin sistemtico dirigido por casos de uso: la arquitectura y los sistemas reutilizables son primero descritos por medio de casos de uso y entonces transformados en modelos de objetos que son fcilmente rastreables a estos caso de uso. SETL: Lenguaje SET, es un lenguaje de programacin de muy alto nivel basada en la teora matemtica de conjuntos. Originalmente fue desarrollada por Jack Schwartsz en el Instituto Courant de

XIV

Ciencias Matemticas de la NYU a finales de los sesentas. SETL provee dos tipos de datos bsicos agregados: conjuntos no ordenados y secuencias (posteriormente tambin llamados tuplas). Los elementos de conjuntos y tuplas pueden ser de cualquier tipo arbitrario, incluyendo conjuntos y tuplas en s. UML:8 Unified Modeling Language. El lenguaje unificado de modelado es el lenguaje de modelado de sistemas de software ms conocido y utilizado en la actualidad; est respaldado por el OMG (Object Management Group). Es un lenguaje grfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un estndar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programacin, esquemas de bases de datos y componentes reutilizables. Es importante resaltar que UML es un "lenguaje" para especificar y no para describir mtodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que est descrito el modelo. VHLL: Very High-Level Programming Language. Lenguaje de

programacin de muy alto nivel, es un lenguaje con un muy alto nivel de abstraccin usado de forma primaria como una herramienta de productividad de programador profesional. Estos lenguajes usualmente estn limitados a una aplicacin muy especfica, propsito, o tipo de tarea. Debido a esta limitacin de
8

http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado

XV

campo, es posible que utilicen sintaxis que nunca es utilizada en otros lenguajes de programacin, tal como el la sintaxis directa en ingls. Por esta razn, los VHLL son a menudo referidos como lenguajes de programacin orientados a objetivos.

XVI

RESUMEN

La reutilizacin de software es el proceso de implementar o actualizar sistemas de software utilizando activos del mismo. Aunque al principio podra pensarse que un activo de software es simplemente otro trmino para cdigo fuente, ste no es el caso. Los activos de software o componentes incluyen todos los productos derivados del mismo, desde requerimientos y propuestas, especificaciones y diseos a manuales y juegos de prueba. Cualquier cosa que sea producto de un esfuerzo de desarrollo de software potencialmente puede ser reutilizada. Un buen proceso de software facilita el incremento de la productividad, calidad y confiabilidad, y el decremento de los costos y tiempo de implementacin. Una inversin inicial es requerida para empezar un proceso de reutilizacin de software, pero tal inversin se paga por s sola en unas pocas reutilizaciones. A corto plazo, el desarrollo de un proceso de reutilizacin y repositorio produce una base de conocimiento que mejora en calidad despus de cada reutilizacin, minimizando el monto de trabajo de desarrollo requerido para futuros proyectos y reduciendo el riesgo. En este trabajo de graduacin se presentan las ventajas de la reutilizacin, se desarrolla el concepto de los diferentes tipo de reutilizacin, la ingeniera de dominios aplicada a la reutilizacin de software, los principios del anlisis y diseo orientado al objeto para la reutilizacin, las metodologas de reutilizacin de software. Para mostrar la reutilizacin con un ejemplo del mtodo composicional de reutilizacin se definen ejemplos de patrones de diseo utilizado en php en diferentes escenarios de aplicacin.

XVII

XVIII

OBJETIVOS
General 1 Comparar los distintos tipos de metodologas de reutilizacin de software que actualmente se conocen y utilizan en proyectos informticos. 2 Evaluar las ventajas y desventajas de cada uno de ellos para poder de esta manera tener un criterio que se pueda usar a la hora de aplicar alguna metodologa especfica. Especficos: 1. Conocer distintas metodologas visualizando su implicacin en la calidad, costo y productividad del software. 2. Conocer el anlisis y diseo orientado al objeto para reutilizacin. 3. Evaluar los requisitos que son necesarios para llevar a cabo adecuadamente cada una de las clases de mtodos de reutilizacin. 4. Evaluar la aplicacin prctica de las metodologas de reutilizacin de software en proyectos informticos, por medio de la aplicacin de patrones para php.

XIX

XX

INTRODUCCIN
Hoy en da se busca la produccin de sistemas software de calidad de forma gil, eficiente y sistemtica. A menudo se dice que el desarrollo de software es una combinacin de arte y ciencia por lo que se han dirigido muchos esfuerzos de investigacin y desarrollo en la bsqueda de tcnicas, metodologas, herramientas y procedimientos que ayuden a mejorar el desarrollo de dichos sistemas. La reutilizacin de software es una excelente manera de ahorrar costos y esfuerzos de desarrollo y cuando se implementa cumpliendo los propsitos y correctamente, la reutilizacin puede ahorrar tiempo y dinero. Los beneficios de la reutilizacin de componentes y activos de software han atrado la atencin de un nmero considerable de empresas encargadas de desarrollar sistemas de software. Por este motivo, ha surgido recientemente un inters por crear y utilizar modelos de procesos para desarrollo de software que contemplen la reutilizacin. Aunque el concepto de reutilizacin no es nuevo, recientemente ha emergido, como elemento central de este, el concepto de componente de software reutilizable. Las caractersticas de los componentes de software reutilizables han obligado a crear nuevos modelos de desarrollo de software basados en la reutilizacin. Estos procesos buscan la solucin a un problema. Esta solucin no es nica, es por esto que los mtodos deben ir evolucionando y adaptndose a las nuevas necesidades de los diferentes tipos de usuarios y los nuevos conceptos de la Ingeniera de Software. Otra de las deficiencias encontradas en los mtodos basados en la reutilizacin es que no especifican de forma detallada el ciclo de vida de un componente de software reutilizable. Estos mtodos se centran en la reutilizacin del componente y no en su desarrollo individual.

XXI

En este trabajo se presentar una visin general de las metodologas de reutilizacin ms utilizadas, los casos para los cuales son tomadas en cuenta, y una serie de ejemplos prcticos de aplicacin de metodologa composicional con patrones de diseo en lenguaje php.

XXII

MARCO TERICO: CONCEPTOS BSICOS DE REUTILIZACIN

La reutilizacin es uno de los conceptos ms simples y antiguos en la programacin, y es algo que a menudo no es muy utilizado. Cuando se implementa cumpliendo los propsitos y correctamente, la reutilizacin puede ahorrar tiempo y dinero, a la vez que hace un inventario de activos de software reutilizables y valiosos. 1.1 Beneficios de la reutilizacin 1.1.1 Tiempo y costo La reutilizacin de software es una excelente manera de ahorrar costos y esfuerzos de desarrollo. De forma ideal, el tiempo de desarrollo es reducido debido a que los componentes reutilizables relevantes pueden ser aplicables al proyecto dado en un marco de tiempo menor que redesarrollar desde cero. Como el tiempo y costo de desarrollo tienen una correlacin positiva, reducir los tiempos de desarrollo trae un ahorro en los costos del proyecto. Esto puede llevar a proyectos y productos ms baratos, y ms utilidades a la organizacin. El tiempo del producto al mercado puede ser reducido, dando una ventaja competitiva. 1.1.2 Calidad Cualquier optimizacin, refactorizacin y pruebas hechas en

componentes reutilizables ya han sido completados. Todas las lecciones aprendidas al producir el componente estn implcitamente incluidas dentro de 1

esto

son

automticamente

llevadas

al

siguiente

proyecto.

Consecuentemente, los proyectos desarrollados son de una mayor calidad. Las organizaciones pueden esperar un incremento cuantitativo en la calidad del software. La reutilizacin efectiva puede reducir la densidad de defectos de 5 a 10 veces. Es ms, debido a los ahorros en tiempo, los desarrolladores pueden invertir el mismo en el software nuevo que necesita ser producido, incrementando potencialmente su calidad o cualidades. 1.1.3 Estandarizacin Los componentes dentro de un dominio dado (rea de aplicacin), requieren cierta clase de estandarizacin para hacerlos compatibles con otros componentes. Esto puede llevar a hacer estndares de interfaces de componentes, as como de cdigo y documentacin. Estas entidades animan a mejores prcticas de desarrollo. 1.2 Barreras a la reutilizacin Con todos los beneficios de la reutilizacin de software efectiva, habra que preguntarse: por qu la reutilizacin de software no es una prctica comn en la ingeniera de software? La reutilizacin de software no es una idea nueva, as que no es cuestin de simplemente esperar para que la tecnologa sea explotada. En cambio hay muchas razones clave por las cuales la reutilizacin no ha ganado una popularidad ms amplia.

1.2.1

Elaboracin, reutilizables

administracin

uso

de

componentes

La entidad esencial en la reutilizacin de software es el componente reutilizable. Pero hay muchas complejidades asociadas con el desarrollo de estos elementos. Los componentes tienen que ser genricos en su naturaleza para ser reutilizados en mltiples sistemas (o mltiples momentos en el mismo sistema). Muchos componentes requerirn de alguna clase de generalizacin a travs de la cual la mayora de lgica especfica de aplicacin es removida y reemplazada con ms funcionalidad de todo propsito. Pero cun general es demasiado general? Si un componente es hecho demasiado general, una larga porcin de ste requerir desarrollo cuando sea reutilizado, reduciendo de esta manera el beneficio de ahorro de tiempo de la reutilizacin. Por otro lado, si un componente es hecho demasiado especfico, su reusabilidad puede reducirse considerablemente, anulando el propsito de la reutilizacin. Adems, los componentes de software necesitan ser capaces de trabajar con otros. Esto origina problemas con interfaces entre los mismos. dominio de aplicacin dado. 1.2.2 Gastos al comenzar Habr un costo inicial en la organizacin por empezar a implementar una metodologa de reutilizacin de software dentro del desarrollo. Los costos potenciales son las modificaciones a los procesos de desarrollo, empleo de personal para manejar la prctica, la generacin y administracin de un 3 Las interfaces necesitan ser estandarizadas entre componentes dentro de un

repositorio de componentes. La gerencia necesitara ser convencida que cualquier gasto ser justificado en el camino. 1.2.3 Reto a los mtodos tradicionales de ingeniera de software Convencionalmente, el software ha sido construido de requerimientos desde cero. Sin embargo, la reutilizacin de software propone un cambio de Generalmente, en lugar de ser paradigma de la ingeniera de software.

desarrollado desde cero, el software es ensamblado desde activos reutilizables. La razn por la que sta es una barrera a la reutilizacin de software efectiva, es porque la idea se desva grandemente de la norma, y puede encontrar resistencia tcnica inmediata. esfuerzos en perfeccionar y, El desarrollo a travs de la reutilizacin de software no es en lo que la industria ha estado poniendo sus consecuentemente, la asistencia general y herramientas que den soporte a la reutilizacin pueden ser escasas. Adems, hay cuestiones personales donde la gente puede sentir que la idea es demasiado buena para ser verdad. Adicionalmente, se requieren cambios en la manera en que los desarrolladores se enfocan en los proyectos. Esto puede no ser de la satisfaccin de aquellos quienes tienen sentimientos negativos por la reutilizacin de software, o quienes estn contra cambios extremos en las prcticas de desarrollo. 1.3 Reutilizacin prctica de software Hay muchas metodologas para poner en prctica la reutilizacin de software. Desde la reutilizacin de cdigo ad hoc, a prcticas de reutilizacin 4

repetible, donde la reutilizacin es dentro de un proyecto o en mltiples proyectos. stos pueden ser resumidos dentro de dos categoras generales: Prcticas de reutilizacin con desarrollo Prcticas de reutilizacin sin desarrollo. 1.3.1 Prcticas de desarrollo con reutilizacin La reutilizacin de software es ms comnmente referida dentro del contexto de reutilizacin durante el desarrollo. Hay muchos enfoques hacia la reutilizacin de software durante el desarrollo. Entre ellos: 1.3.1.1 Tecnologas orientadas a objetos Un concepto clave en las tecnologas de objetos es la idea de objeto. Los objetos caracterizan el dominio del problema, cada uno teniendo atributos y comportamientos especficos. Los objetos son manipulados con una coleccin de funciones y se comunican unas con otras utilizando un protocolo de mensajes, y estn organizados dentro de clases y subclases. Un objeto encapsula la data y el proceso que es aplicado a la data. Esta importante caracterstica hace posible clases de objetos a ser construidas e inherentemente llevan a libreras de clases reutilizables y objetos. Adems, las tecnologas orientadas a objetos tambin brindan herencia. La herencia significa que un objeto puede heredar uno o ms atributos de otros objetos en su jerarqua. De esta manera reutilizar objetos a travs de adaptacin. La capacidad de reutilizar objetos ms all de un simple sistema, significa que la 5

reutilizacin orientada

a objetos es posible para reutilizacin interna en un

proyecto, as como para reutilizacin a travs de mltiples proyectos. Ejemplos de tecnologas de objetos comerciales establecidas son: OMG/ CORBA Microsoft COM Componentes Sun JavaBean

Tecnologas de componentes emergentes incluyen: Marcos de Trabajo Microsoft .NET Sun Enterprise JavaBeans (EJB) Corba Component Model (CCM)

Pocas organizaciones han adoptado mtodos orientados a objetos como su metodologa primaria. Esto, debido a que la escalabilidad hizo estas tecnologas indeseables para reutilizacin. Sin embargo, los objetos permiten componentes a gran escala en lugar de solamente funciones para reutilizacin. De esta manera, mientras un lenguaje de programacin orientado a objetos puede ser parte de las capacidades de reutilizacin de una organizacin, es slo un elemento de un programa ms grande y no debera ser utilizado por s slo. 1.3.1.2 Desarrollando con reutilizacin, reutilizacin

oportunista En una organizacin de desarrollo que practica reutilizacin oportunista, sta es ad hoc, cuando la oportunidad para reutilizacin se presenta por s 6

misma, es explotada. Por ejemplo, si una organizacin estuviera construyendo un sistema, y encuentra que durante el diseo o desarrollo, se podra ahorrar tiempo debido a que uno de sus subsistemas puede heredar las propiedades de otro, entonces esa organizacin est practicando reutilizacin oportunista. Queda bastante claro que tal clase de desarrollo est bastante diseminada, por lo que muchas organizaciones estn practicando inadvertidamente una forma de reutilizacin de software, aunque a travs del uso de tecnologas orientadas a objetos, o a travs de buenas prcticas de desarrollo. En trminos de cambio organizacional, no es necesario mayor trabajo para implementar la reutilizacin oportunista, debido a que recae en previsin y coincidencia. Esta clase de reutilizacin no afecta los procesos de desarrollo, as que es bastante barato de implementar dentro de una organizacin. El lado negativo, es que la reutilizacin oportunista no permitir que la capacidad de reutilizacin sea predeciblemente repetible debido a su naturaleza ad hoc.

1.3.1.3

Desarrollando

con

reutilizacin:

reutilizacin

sistemtica La reutilizacin sistemtica est enfocada al dominio. Se basa en un

proceso repetible, y de manera primaria relacionada con la reutilizacin de los artefactos del ciclo de vida de ms alto nivel, tales como: requerimientos, diseos y subsistemas. La idea detrs de la reutilizacin sistemtica de software es que la reutilizacin no debera ser ad hoc, sino debera ser implementada dentro de la organizacin como parte del desarrollo de procesos. Contrastando directamente con la reutilizacin oportunista donde la reutilizacin no es parte del proceso. 7

Un concepto clave de reutilizacin sistemtica es el dominio. Un dominio se refiere a un conjunto de sistemas cuyas propiedades comunes lo hacen ventajoso para estudiarlo y organizar estas propiedades dentro de una coleccin de componentes reutilizables, los cuales pueden ser entonces utilizados para construir sistemas en el dominio. 1.3.2 Prcticas de reutilizacin sin desarrollo con reutilizacin del producto Hay otras clases de reutilizacin en relacin con el desarrollo de software. Uno de estos tipos es la reutilizacin del producto, la que se refiere a la reutilizacin de un sistema entero. Esencialmente, en vez de construir un sistema especfico para un slo cliente, se construye un sistema ms general que puede ser utilizado por muchos clientes. El ejemplo ms obvio de reutilizacin de producto son los sistemas operativos para PC de escritorio en el mundo, tales como los productos Windows de Microsoft. configuraciones de hardware. En este caso, el software est construido para que sea capaz de ejecutarse sobre mltiples Sustituyendo el desarrollo de un sistema operativo para cada cliente. Esencialmente, el software es de hecho reutilizado a travs de su implementacin genrica.

INGENIERA DE DOMINIOS

Existen diversas definiciones para ingeniera de dominios, las cuales tienen como denominador comn, el propsito de la ingeniera de dominios: proveer reutilizacin entre aplicaciones diferentes (una familia de aplicaciones). La ingeniera de dominios es un proceso automtico para proveer una arquitectura esencial comn para estas aplicaciones. Esto puede ser aplicado a sistemas existentes y a sistemas nuevos. De esta manera, la ingeniera de dominios abarca el anlisis de aplicaciones existentes o de los conceptos de un rea de problema. 2.1 Dominio 2.1.1 Definicin de dominio Un dominio puede ser definido como un conjunto de problemas o funciones que las aplicaciones de tal dominio pueden resolver. dominio puede ser utilizado asocindolo de diversas maneras: rea de negocios Coleccin de problemas (dominio de problemas) Coleccin de aplicaciones (dominio de soluciones) rea de conocimiento con terminologa comn El trmino

Para determinar un dominio existen varios criterios. La vista puede ser enfocada en describir lo que est dentro del dominio, cules son los lmites del dominio, o qu est afuera del dominio.

El primer caso, describe los elementos que constituyen el dominio, o bien, identifica otros dominios, que juntos forman el dominio actual (los dominios pueden tener subdominios). El segundo caso, describe las reglas de inclusin y exclusin. El tercer caso, como tambin el primero, pueden ser representados por estructura y diagramas de contexto. Sin embargo, los lmites del dominio no son necesariamente fciles de encontrar. Esto puede ser debido a la inexperiencia del analista de dominios y a los dominios que usa, o a los dominios que proveen servicios a otros dominios. Los dominios pueden ser considerados al menos desde dos puntos de vista: Primero, como se consider en un contexto orientado a objetos, un dominio puede ser visto como mundo real. Este enfoque se concentra en el fenmeno y sus procesos. Los requerimientos de diferentes aplicaciones no son tomadas en cuenta. De manera que esta clase de ingeniera de dominios es bastante similar al modelado conceptual, y cubre los primeros dos puntos de la lista previa. El modelo de dominio, derivado de esta alternativa, es altamente reutilizable, porque los conceptos de un rea de problema son bastantes estables. stos no varan necesariamente, aunque los requerimientos de los sistemas cambian. El otro modo de considerar un dominio, es verlo como un conjunto de sistemas. Este punto de vista se concentra en familia de aplicaciones. El dominio es delimitado de acuerdo a las similitudes entre las aplicaciones. De este modo, este enfoque cubre el tercer punto de la lista previa. Esta ltima alternativa es ms cercana a la ingeniera de 10

lnea de producto, mientras que la anterior, se ingeniera de un slo sistema. 2.1.2 Relacin entre dominios y aplicaciones

ajusta tambin a

Las aplicaciones pueden pertenecer a varios dominios. Por ejemplo, una aplicacin concerniente a prcticas bancarias distribuidas, cubre al menos los siguientes dominios: Prcticas bancarias, sistemas de informacin comerciales de bancos, administracin de flujos de trabajo, interfaces de usuario, sistemas de administracin de bases de datos y administracin de red. Adems, las aplicaciones no necesariamente cubren un dominio completo o varios dominios enteros. Por el contrario, varios dominios pueden ser dispersos bajo una aplicacin. Si la funcionalidad del dominio es cubierta por un slo subsistema en un sistema, el dominio es llamado encapsulado. Por el contrario, si la funcionalidad del dominio est dispersa a travs de varios subsistemas de un sistema, ese dominio se dice que es distribuido. Los dominios distribuidos tambin pueden ser llamadas difusos. 2.1.3 Dominios verticales y horizontales

Los dominios pueden ser divididos en verticales y horizontales. En los dominios verticales, los sistemas de software son clasificados de acuerdo al rea de negocios. Tales sistemas son, por ejemplo, sistemas de reservacin de aerolneas, sistemas de registros mdicos, sistemas de administracin de portafolio, procesamiento de rdenes, y administracin de inventarios. 11

En los dominios horizontales,

partes de un sistema de software son

clasificadas de acuerdo a su funcionalidad. Ejemplos son: sistemas de bases de datos, libreras contenedoras, sistemas de flujos de trabajo, libreras GUI (interfaces de grficas de usuario) y libreras de cdigo numricas. Los dominios verticales son dominios de sistemas, mientras que los dominios horizontales son dominios de partes de sistemas. Cuando se aplica la ingeniera de dominios a un dominio vertical, el resultado puede ser software reutilizable, el que se puede presentar como una forma de marco de trabajo y componentes reutilizables. En el caso de sistemas horizontales, la ingeniera de dominios puede producir componentes reutilizables. Como en el caso de dominios distribuidos, tambin los dominios horizontales son encontrados ms tpicamente en sistemas heredados. Sin embargo, sistemas grandes o complejos puede estar dispersos sobre varios dominios, an desde el principio. Los dominios laterales son dominios horizontales en un nivel de subsistema, y de esta forma, tambin pueden ser llamados dominios de componentes. stos corresponden a un conjunto de componentes fuertemente relacionados (o activos bases), que pueden pertenecer a varios sistemas como sus subsistemas. 2.2 Ingeniera de dominios e ingeniera de aplicacin Para hacer posible la ingeniera de lnea de productos, una convencin bien aceptada es dividir el proceso de ingeniera en dos diferentes procesos: ingeniera de dominios e ingeniera de aplicacin. Estos procesos pueden ser seguidos en paralelo.

12

A la ingeniera de dominios tambin se le conoce como ingeniera para reutilizacin; y la de aplicacin puede ser llamada ingeniera con reutilizacin. El propsito de la ingeniera de dominios es proveer los activos reutilizables esenciales que son explotados durante la ingeniera de aplicacin cuando se ensamblan o personalizan aplicaciones individuales. De esta forma, estas fases son tambin llamadas ingeniera de activos e ingeniera de productos, o desarrollo de activos esenciales y desarrollo de producto, respectivamente. Los subprocesos de ingeniera de dominios y la ingeniera de aplicacin corresponden uno con otro. Las fases de ingeniera de dominios se concentran en el diseo e implementacin de la arquitectura principal. Las fases de ingeniera de aplicacin son llamadas ingeniera de requerimientos, diseo anlisis e integracin y pruebas. La ingeniera de dominios puede tambin ser comparada con la ingeniera de software convencional. El anlisis de requerimientos corresponde al anlisis de dominio de tal manera que el anlisis de requerimientos produce requerimientos para un slo sistema, mientras que el anlisis de dominios produce requerimientos reutilizables configurables para una familia de sistemas. De forma similar, el diseo de sistemas busca el diseo de un slo sistema; mientras que el diseo de dominio, se concentra en el diseo reutilizable para una clase de sistemas y un plan de produccin. Finalmente, la implementacin de sistemas despliega nicamente un sistema, mientras la implementacin del dominio produce componentes reutilizables, arquitectura esencial, y procesos de produccin.

13

2.3 Anlisis del dominio, diseo del dominio e implementacin del dominio La ingeniera de dominios frecuentemente es dividida en tres fases: anlisis de dominio, diseo de dominio, e implementacin de dominio. Sin embargo, algunas referencias, por ejemplo, dividen la ingeniera de dominios en dos partes llamadas anlisis de dominios e implementacin de dominios. En este caso, el anlisis de dominios cubre tambin tareas del diseo de dominios. En la literatura, los trminos concernientes a las fases han sido utilizados inconsistentemente. Por ejemplo, la ingeniera de dominios y el anlisis de dominios dominios. 2.3.1 Anlisis del dominio El concepto de anlisis de dominio se utiliza para denotar el dominio de problema de una familia de aplicaciones. El trmino correspondiente para sistemas simples es anlisis de sistemas. El anlisis de dominio est asociado con la reutilizacin. Su propsito es capturar la informacin involucrada con el dominio a ser reutilizado en desarrollar aplicaciones futuras en el mismo dominio. Sin embargo, el anlisis de dominios no est necesariamente restringido a la ingeniera de lnea de producto; en cambio, puede ser utilizada en el contexto de ingeniera de un slo sistema tambin. La salida de un anlisis de dominio es el modelo de dominio. Tratando de encontrar los elementos ms comunes de varios modelos de dominios, los ingredientes del modelo de dominio puede ser esbozado como sigue: han sido utilizados intercambindolos. No obstante, ms recientemente el anlisis de dominio es establecido como parte de ingeniera de

14

Alcance del dominio (definicin de dominio, anlisis de contexto) Anlisis de elementos comunes Diccionario de dominio (lxico de dominio) Notaciones (modelado de concepto, representacin de concepto) Ingeniera de requerimientos (modelado de caractersticas)

En la lista de arriba el primer trmino despus de cada inciso denota el trmino utilizado en este trabajo, mientras el parntesis encierra los trminos alternativos para el mismo concepto. Una breve descripcin es dada para trmino de la siguiente manera: Alcance del dominio busca los lmites del dominio. Esta actividad da ejemplos de las aplicaciones pertenecientes al dominio; as como ejemplos de tales aplicaciones que estn afuera del dominio. Adems, da las reglas de exclusin e inclusin. Ntese que el alcance puede ser dividido en alcance del dominio, alcance de lnea de producto, y alcance de activos. El alcance de dominios est asociado con la ingeniera de dominios. El alcance de lnea de producto identifica los requerimientos y productos que deberan pertenecer a cierta lnea de productos. El alcance de activos identifica los activos reutilizables esenciales. Anlisis de elementos comunes considera los elementos comunes y variaciones de la aplicacin en el dominio. Estudia los requerimientos y propiedades de las aplicaciones y los conceptos en el dominio. El anlisis de elementos comunes produce un documento de elementos .

15

Tabla I. Documento de elementos Visin general Definiciones Un conjunto estndar de trminos tcnicos Elementos comunes Variaciones Parmetros Asuntos Escenarios Una lista estructurada de suposiciones que son verdaderas para cada miembro de la familia Una lista estructura de suposiciones acerca de cmo los miembros de la familia difieren Una lista de parmetros que refine las variabilidades, aadiendo Un registro de decisiones y alternativas importantes. Ejemplos usados en describir elementos comunes y variabilidades de variacin un rango de valores y vinculando tiempo a cada uno Descripcin del dominio y su relacin con otros dominios

Diccionario de dominio provee y define los trminos concernientes al dominio. Su propsito es establecer comunicacin entre los desarrolladores y otros participantes del proyecto de forma ms fcil y precisa. El diccionario de dominio puede ser parte del documento de elementos comunes. Notaciones proveen una manera uniforme de representar los conceptos utilizados en el modelado de dominio. Ejemplos de tales notaciones son diagramas de objetos, diagramas de transicin de estados, entidad-relacin, y diagramas de flujo. Es razonable utilizar tal notacin que es familiar para la mayora de los participantes del proyecto. Algunas notaciones se supone que describan un sistema, y por lo tanto, pueden ser llamadas notaciones de nivel de sistema. No es fcil o an deseado, 16

utilizar estas notaciones para describir los conceptos de nivel de dominio. Por ejemplo, UML (lenguaje unificado de modelado) puede ser utilizado para describir variabilidades dentro de un slo sistema. Sin embargo, de acuerdo a algunos autores, podra ser confuso de utilizar (o expandir) las mismas notaciones para describir tambin variabilidades entre sistemas. De esta manera las notaciones familiares y nuevas tienen sus ventajas y desventajas. Por un lado, las notaciones familiares y sus extensiones son fciles de aprender; por otro lado, pueden conducir a malentendidos si son utilizados en situaciones inapropiadas o niveles abstractos. Escoger una notacin es una importante decisin porque stas tienen un rol clave en proveer comprensin de un sistema o un dominio. Ingeniera de requerimientos conlleva reunir, definir, documentar, verificar, y administrar los requerimientos que especifican las aplicaciones en el dominio. En el contexto de lnea de producto, el propsito es reutilizar y configurar los requerimientos entre aplicaciones individuales. Tales requerimientos pueden tambin ser llamadas caractersticas. Una caracterstica puede tambin ser definida como una cualidad del sistema que es visible al usuario final, o tambin puede involucrar cualidades que son relevantes a algunos participantes del proyecto (no necesariamente visibles). Las caractersticas pueden ser representadas por modelos que tambin dicen cules combinaciones de stas son significativas. Los modelos de caractersticas proveen notaciones para diferentes clases de caractersticas tales como las que son parecidas al FODA, es decir, caractersticas mandatarias, opcionales y alternativas. Sin embargo, estos tres tipos de caractersticas no son siempre adecuadas. Por ejemplo, de caractersticas alternativas se puede seleccionar exactamente una. En algunas situaciones, debera ser posible escoger cualquier nmero de caractersticas de un conjunto 17

dado. Adems de diferentes clases de caractersticas, los modelos pueden dar una forma de presentar restricciones entre caractersticas o bases lgicas para seleccionarlas. Adems de la lista dada de tareas concernientes al modelo de dominios, el anlisis de dominio comprende la reunin de informacin de diferentes fuentes tales como diversos documentos expertos de dominio. Adems, puede cubrir clusterizacin, abstraccin, clasificacin, y generalizacin de conceptos de dominios. El anlisis de dominio es diferente para aplicaciones diferentes y para dominios diferentes. Por ejemplo, sistemas interactivos pueden requerir casos de uso y escenarios. As mismo, la aplicacin centrada en datos puede ser ms fcilmente descrita por diagramas entidad-relacin o diagramas de objetos. Propiedades especiales tales como soporte en tiempo real, distribucin y tolerancia a fallos pueden requerir tcnicas especiales de modelado. Propiedades peculiares a cierta organizacin pueden tener

requerimientos adicionales. Es importante notar que, el anlisis de dominio puede tambin ser llamado modelado de dominio referente a la salida del modelo de dominio. Adicionalmente, hay otras inconsistencias en la terminologa y en los contenidos de las subreas concernientes al anlisis de dominio. En este trabajo que usa la divisin ms comn de subreas, el alcance de dominio es una parte del anlisis de dominio. Sin embargo, el alcance de dominio y anlisis de dominio pueden ser representados como partes de la ingeniera de dominios. Adems, se seguir el estudio de la propuesta que sigue la teora que el alcance de dominio y la ingeniera de requerimientos son partes del anlisis de dominio. Sin embargo, el alcance de dominio puede ser considerado como parte de la ingeniera de requerimientos, que en cambio, pertenece al anlisis de dominio.

18

2.3.2

Diseo del dominio

Diseo de dominio significa perfilar la arquitectura esencial para una familia de aplicaciones. Esto abarca la seleccin del estilo de arquitectura. As, la arquitectura comn bajo el diseo debera ser representada usando diferentes vistas. La arquitectura esencial debera tambin proveer variabilidad entre aplicaciones. En esta fase, se decide cmo habilitar esta variabilidad o configurabilidad. De acuerdo a los modelos de caractersticas y documentos de elementos comunes, tambin se debera seleccionar cuales componentes o elementos (tales como requerimientos), son datos en la arquitectura principal y cules elementos son implementados como variaciones de aplicaciones individuales. El diseo de dominio produce tambin un plan de produccin que dice cmo la aplicacin concreta puede ser derivada de la arquitectura principal y desde los componentes reutilizables. El plan de produccin comprende las descripciones de los sistemas con sus interfases para cada cliente, directrices para el proceso de ensamblaje de los componentes, y directrices para administrar las solicitudes de cambios de los clientes. El proceso de ensamblaje puede ser manual, semi-automtico, o automtico. El diseo de dominio puede estar envuelto en evaluar la arquitectura esencial, analizar la misma contra sus requerimientos de calidad para revelar riesgos potenciales concernientes a la arquitectura. Hay diferentes opiniones del momento ms adecuado para evaluar una arquitectura. Una arquitectura debera ser evaluada en una etapa temprana del desarrollo de una arquitectura de lnea de producto, debido a que mientras ms pronto los problemas son detectados ms fciles son de resolver. De esta manera, tan pronto como los

19

artefactos son evaluados, debera ser verificado cun bien la arquitectura cumple los requerimientos. La composicin y otras acciones para proveer aplicaciones finales pueden requerir herramientas especiales que son destacadas en la fase de diseo. Un entorno constituido de tales herramientas puede ser llamado un entorno de ingeniera de aplicacin. 2.3.3 Implementacin del dominio

La implementacin del dominio cubre la implementacin de la arquitectura, componentes, y herramientas diseadas en la fase previa. sta abarca, por ejemplo, escribir documentacin e implementar lenguajes y generadores especficos de dominio. El propsito de la ingeniera de dominios es producir activos reutilizables que son implementados en esta fase. De esta manera, el resultado de toda la fase de ingeniera de dominios comprende componentes, modelos de caractersticas, modelos de anlisis y diseo, patrones, marcos de trabajo, lenguajes especficos de dominio, planes de produccin y generadores. Es relevante hacer notar que la ingeniera de dominios es un proceso continuo. El conocimiento concerniente al dominio debera ser mantenido y actualizado todo el tiempo de acuerdo a la nueva experiencia, alcance, ensanchamiento, y nuevas tendencias. Adems, la ingeniera de dominios debera adaptarse de acuerdo a la retroalimentacin de la ingeniera de aplicacin. De esta manera, el modelo de dominio nunca puede ser completado, podra siempre ser refinado para ser ms exacto. Adems, el modelo de dominio usualmente contiene alguna clase de compromiso acerca de diferentes y quizs inconsistentes puntos de vista de varios expertos. 20

2.4 Distincin de trminos relacionados 2.4.1 Lnea de producto Los trminos dominio y lnea de producto son muy cercanos uno con otro. Sin embargo, la diferencia es que un dominio consiste en elementos conceptuales, mientras una lnea de producto comprende productos concretos o aplicaciones a ser desarrolladas. Es ms, estos trminos pueden ser considerados para referirse al mismo nivel de abstraccin, pero trminos diferentes son pretendidos para audiencia diferente. Personal tcnico (desarrolladores de software) entienden y usan el trmino dominio, mientras que para administradores, es ms fcil hablar acerca de lneas de producto, porque es ms parecido a trminos de negocios o mercadeo. 2.4.2 Ingeniera de requerimientos La ingeniera de requerimientos puede ser dividida en subtareas tales como licitacin de requerimientos para descubrir y entender las necesidades del usuario; anlisis de requerimientos para refinar las necesidades del usuario; verificacin de requerimientos para asegurarse que los requerimientos del sistema estn completos, correctos y consistentes; y administracin de requerimientos para calendarizar y coordinar las actividades anteriores concernientes a requerimientos. Sin embargo, como en el anlisis de dominio e ingeniera de dominios, tambin el anlisis de requerimientos y la ingeniera de requerimientos son a veces utilizados intercambindolos. Ntese que el anlisis de requerimientos para un sistema simple corresponde al anlisis de dominio para una familia de sistemas. Complementariamente, la ingeniera de requerimientos es una parte de 21

documento de elementos comunes, y tiene una cercana conexin a las caractersticas. Aunque el anlisis de requerimientos puede ser considerado como anlisis de dominios para sistemas simples, tambin est en relacin con familias de sistemas. En la ingeniera de lnea de productos, los requerimientos de ingeniera concernientes a toda la lnea de producto deberan ser manejados separadamente de los requerimientos individuales de cada sistema. De esta manera, las arquitecturas de lnea de producto consideran los requerimientos desde el punto de vista de productos de familias y sistemas simples. De hecho, aplicar la ingeniera a los requerimientos comunes define los elementos comunes, mientras que los requerimientos individuales se concentran en las variabilidades. Esta es la explicacin de por qu la ingeniera de requerimientos est conectada por un lado, con el anlisis de elementos comunes; por el otro, significa mucho, tanto para la ingeniera de dominios como para sistemas simples. 2.4.3 Ingeniera de reutilizacin La ingeniera de reutilizacin significa la identificacin de partes reutilizables en el software y cambiar el software para hacerlo ms reutilizable. Tareas involucradas en la ingeniera de reutilizacin son: recuperacin de objetos, identificacin de tipos de datos abstractos y componentes reutilizables, y la construccin de libreras de los componentes identificados. De esta forma, el aspecto de reutilizacin en la ingeniera de reutilizacin est concentrado en software existente. Para enfatizar an ms el aspecto heredado, se puede usar para el mismo propsito, un trmino muy cercano, reingeniera de reutilizacin y 22

extraer componentes reutilizables de software existente y colectarlo en repositorios. Ambos trminos (ingeniera de la reutilizacin y reingeniera de la reutilizacin) estn asociados con promover la reutilizacin del software existente. La ingeniera de dominios en cambio, trata con el software existente y con el nuevo desarrollado. De esta manera, la ingeniera de reutilizacin puede ser considerada como parte de la ingeniera de dominio. 2.4.4 Arquitecturas de software especficas de dominio La ingeniera de dominios es el proceso de desarrollar e implementar la arquitectura de software especfica de dominio. Una arquitectura de software especfica de dominio (DSSA por sus siglas en ingls) es una arquitectura para un dominio especfico, sin embargo, debera ser todava general para soportar varias aplicaciones del dominio. Un DSSA consiste de requerimientos comunes y el proceso para refinarlo. De este modo, un DSSA denota en mucho, lo mismo que una arquitectura de lnea de producto. 2.4.5 Arquitecturas de referencia

Una arquitectura de referencia es una arquitectura de software para una familia de sistemas de aplicacin. El resultado de refinar o instanciar una arquitectura de referencia es una arquitectura de aplicacin. De esta manera, una arquitectura de referencia corresponde a una arquitectura esencial comn; y una arquitectura de aplicacin corresponde a la arquitectura de una aplicacin individual en terminologa de lnea de producto.

23

Cuando se comparan DSSA y arquitecturas de referencia, los DSSAs de hecho, se concentran en el proceso en cmo proveer las caractersticas comunes y variables, y cmo derivar las arquitecturas finales para cada aplicacin. Las arquitecturas de referencia y arquitecturas de aplicacin, en cambio, denotan las arquitecturas y artefactos actuales. Sin embargo, las DSSAs y las arquitecturas de referencia tienen una cercana conexin una con la otra. Un DSSA es un proceso para desarrollar una arquitectura de referencia para generar aplicaciones dentro de un domino particular. 2.5 Mtodos de ingeniera de dominios La mayora de los mtodos se han concentrado originalmente en ingeniera de dominios. Ms tarde, han sido extendidos o conectados a otros mtodos para cubrir todo el proceso de ingeniera de lnea de producto. FODA (anlisis de dominio orientado a las caractersticas), considera las caractersticas de aplicaciones similares en un dominio. Las caractersticas son capacidades de las aplicaciones consideradas desde el punto de vista del usuario final. stas cubren aspectos comunes y variables entre sistemas relacionados. Estn divididas en mandatarias (o comunes), alternativas y caractersticas opcionales. FODA incluyen diferentes anlisis tales como anlisis de requerimientos y anlisis de caractersticas. Esto produce un modelo de dominio cubriendo las diferencias entre aplicaciones relacionadas. FODA es actualmente, una parte del enfoque basado en modelo de la ingeniera de dominios. Este enfoque cubre la ingeniera de dominios y la ingeniera de aplicacin. La parte de ingeniera de dominios consiste en anlisis de dominio, diseo de dominio, e implementacin de dominio.

24

Adicionalmente, FODA est ms extendido dentro de FORM (mtodo de reutilizacin orientado a la caracterstica por sus siglas en ingls), para incluir tambin diseo de software y fases de implementacin. FORM cubre el anlisis de caractersticas de dominio y utiliza estas caractersticas para desarrollar artefactos reutilizables de dominio. La ODM (organizacin de modelado de dominio) principalmente, se concentra en la ingeniera de dominio sistemas heredados. Sin embargo, puede ser aplicado a los requerimientos para nuevos sistemas. ODM es ajustable y configurable, y puede ser integrado con otras tecnologas de ingeniera de software. Esto combina diferentes artefactos tales como requerimientos, diseo, cdigo, y procesos de varios sistemas heredados dentro de activos reutilizables comunes. ODM tiene soporte de DAGAR (Generacin basada en arquitectura para reutilizacin en Ada, por sus siglas en ingls). El proceso DAGAR no cubre modelado de dominio. De esta manera, aplica ODM u otros mtodos para este propsito. En lugar de esto, el proceso DAGAR incluye actividades para ingeniera de dominios e ingeniera de aplicacin. El negocio de ingeniera de software conducida por reutilizacin (Reusedriven Software Engineering Business), RSEB es un mtodo de reutilizacin sistemtico y conducido por modelo. Se compone de conjuntos de aplicaciones relacionados desde conjuntos de componentes reutilizables. RSEB utiliza UML para especificar sistemas de aplicaciones, sistemas de componentes reutilizables y arquitecturas en capas. Las variabilidades entre sistemas estn expresadas con puntos de variacin y variantes aadidas. RSEB caracterizado, conecta caractersticas (desde FODA) con RSEB. De hecho, FODA y RSEB tienen mucho en comn. Ambos son mtodos conducidos por modelo proveyendo varios modelos correspondiendo a los diferentes puntos de vista del dominio. 25

De esta forma, son compatibles unos con otros. PuLSE (ingeniera de software de lnea de producto, por sus siglas en ingles), divide el ciclo de vida de lnea de producto en tres partes. En la fase de inicializacin, PuLSE es personalizada para ajustarse a la aplicacin particular. La adaptacin es afectada por la naturaleza del dominio, la estructura del proyecto, el contexto organizacional, y los objetivos de la reutilizacin. En la segunda fase, la infraestructura de lnea de producto es construida. Este paso incluye el alcance, modelado y arquitectura de la lnea de producto. En la tercera fase, la infraestructura de lnea de producto es utilizada para hacer productos individuales. Esto comprende instanciar el modelo de lnea de producto y la arquitectura. Cada una de estas fases est asociada con la evolucin de la infraestructura de lnea de producto. Cada fase debera considerar cambiar requerimientos y cambiar conceptos dentro del domino. PuLSE tiene varios componentes. PuLSE-DSSA (PuLSE arquitectura especfica de dominio), por ejemplo, desarrolla una arquitectura especfica de dominio basada en el modelo de lnea de producto. Como otros ejemplos, PuLSE-Eco se concentra en alcance econmico, y PuLSE-EM en evolucin y administracin. El proceso FAST, abstraccin, especificacin y traduccin orientada a la familia, por sus siglas en ingls, cubre el proceso de ingeniera de lnea de producto completo. Sin embargo, divide la ingeniera de dominios en dos partes: anlisis de dominios e implementacin de dominio. De esta forma, los problemas que involucran el diseo de dominio son considerados en la fase de anlisis de dominio. FAST provee gua sistemtica para cada paso durante la ingeniera de lnea de producto. Estos pasos pueden ser seguidos como transiciones entre estados. FAST tambin describe cules artefactos son producidos en cada fase. 26

2.6

Ingeniera de dominios y metodologas orientadas al anlisis y

diseo orientados a objetos (OOA/D) 2.6.1 Defectos en los mtodos OOA/D existentes Los mtodos de anlisis y diseo orientado a Objetos (OOA/D), son ampliamente utilizados en la ingeniera de software. No obstante, stos principalmente se concentran en anlisis y diseo de sistemas simples. La orientacin a objetos fue primeramente pensada para traer reutilizacin de forma inherente, con todo, hoy en da es reconocido que para poder hacer reutilizacin, se tiene que invertir y planear de antemano. La reutilizacin est conectada a la orientacin a objetos, al menos en la forma de marcos de trabajo y patrones diseo. Un marco de trabajo comprende un diseo abstracto del cual varias aplicaciones pueden ser instanciadas. Un patrn de diseo, en cambio provee una solucin (diseo) para problemas recurrentes. Sin embargo, OOA/Ds no tienen soporte para reutilizacin, y no son guas en disear familias de aplicaciones. Los problemas de los mtodos OOA/D han sido listados como sigue a continuacin: No hay distincin entre ingeniera de dominios e ingeniera de aplicacin. No hay fase de alcance de dominio. No hay diferenciacin entre la variabilidad de modelado dentro de un aplicacin y entre varias aplicaciones. Sin medios independientes de implementacin de variabilidad de modelado.

27

Para resolver el problema de reutilizacin en OOA/Ds, hay varias propuestas. La primera alternativa es actualizar los mtodos de ingeniera de dominios ms antiguos. Por ejemplo, el anlisis y diseo estructurado utilizado en FODA, puede ser reemplazado con mtodos OOA/D. Segundo, los mtodos de ingeniera de dominios personalizables pueden ser especializados en una direccin orientada a objetos. Por ejemplo, en ODM, un mtodo de ingeniera de sistemas puede ser dado como un parmetro. Tercero, los mtodos OOA/D pueden ser extendidos con los conceptos de ingeniera de dominios. Por ejemplo, RSEB, est basado en notacin de modelado orientada a objetos. La cuarta alternativa es integrar mtodos existentes. Por ejemplo, FeatuRSEB es desarrollado desde FODA y RSEB, la anterior ingeniera de dominios de aplicacin y los conceptos posteriores orientados a objetos. 2.6.2 Metodologas OOA/D apoyando a la ingeniera de dominios OOram (anlisis de roles y modelado orientado a objetos, Object Oriented role analysis and modeling) es un mtodo OOA/D que tambin enfatiza la ingeniera de dominios. OOram no cree en una sola metodologa; en lugar de esto, es un mtodo genrico que provee un marco de trabajo para crear una variedad de metodologas. Los sistemas de software reales son tpicamente muy largos y complejos. De esta forma, OOram colecta objetos teniendo una meta comn al mismo grupo llamado colaboracin. Adicionalmente, diferentes puntos de vista son dados para entender el sistema ms fcilmente. Como los OOA/D se concentran en la dimensin de clase, OOram enfatiza la dimensin de modelo de rol. El modelo de rol colecciona objetos colaboradores juntos de acuerdo a su meta comn. La meta define un rea de concernencia. Un rol describe un objeto y su responsabilidad de lograr la meta 28

en el rea de concernencia. Los modelos de roles pueden ser relacionados jerrquicamente entre ellos como un modelo de roles base y un modelo de roles derivado. Las colaboraciones son conectadas a marcos de trabajo y patrones de diseo. Un diseo de marco de trabajo puede ser representado como una composicin de colaboraciones. Adems, las colaboraciones pueden ser instancias de patrones de diseo. OOram identifica los siguientes tres procesos para logar la meta dada. Primero, el proceso de creacin de modelo se concentra en la creacin de un modelo para un cierto fenmeno. Son ejemplos: crear un modelo de roles, ejecutar sntesis de modelo de roles, y crear especificaciones de objetos. Segundo, el proceso de desarrollo de sistemas cubre el tpico ciclo de vida del software, desde la especificacin de las necesidades del usuario hasta la instalacin y mantenimiento del sistema. Tercero, el proceso de construccin de activos reutilizables es necesitado en la continua produccin de varios sistemas cercanamente relacionados. Crear un sistema es principalmente configurar y reutilizar componentes robustos y probados. Puede ser necesario, para completar el sistema, aadir unos pocos nuevos componentes. Adems de OOram, JODA (anlisis de dominio orientado a objetos JIAWG por sus siglas en ingls) - donde JIAWG (Joint Integrated Avionics Working Group) significa grupo de trabajo integrado de aviacin por sus siglas en ingls integra anlisis de dominio con anlisis orientado a objetos (OOA). El anlisis de dominio provee un modelo de dominio para ser utilizado en producir elementos reutilizables especialmente requerimientos reutilizables; mientras OOA trae las tcnicas de anlisis de objetos y notaciones. Los objetos son ms estables que las funciones. Aunque la operabilidad de un objeto puede cambiar, el objeto en s mismo permanece ms a menudo. 29

sta es la razn por la que los mtodos OOA/D son preferidos a los mtodos funcionales. JODA divide el proceso de anlisis de dominio en tres fases: Preparacin de dominio. Definicin de dominio. Modelado de dominio. El modelado de dominio es extendido desde OOA, y consiste de tres pasos. Primero, el historial de vida del objeto y la respuesta de estados-eventos son examinados. Este paso es derivado directamente desde el OOA, y comprende la identificacin de objetos, definicin de atributos y servicios, y encontrar las relaciones entre objetos. Segundo, escenarios de dominios son identificados, definidos y simulados. En esta fase, el comportamiento de los objetos es identificado para proveer servicios a los usuarios y otros sistemas. Tercero, los objetos son abstrados y agrupados para habilitar la reutilizacin. Por ejemplo, si hay instancias repetidas de problemas similares tales como el procesamiento de muchos formatos de mensajes, los problemas son analizados para encontrar una abstraccin para cubrir todos los casos. As mismo, esta fase identifica elementos comunes y variabilidades tales como interfases estables con implementaciones variables. Por ejemplo, interfases de controladores de dispositivos para paquetes grficos pueden ser similares, aunque las implementaciones varen de acuerdo a las capacidades del dispositivo. Los tres pasos son iterados y el modelo de dominio resultante es revisado y actualizado tanto como el modelo es lo suficientemente exacto para definir el dominio. Como un tercer ejemplo de mtodos conectando orientacin a objetos e ingeniera de dominios, es considerado FeatuRSEB. Como se mencion 30

anteriormente FeatuRSEB es desarrollada desde FODA y RSEB. FeatuRSEB conecta casos de uso de RSEB y caractersticas de FODA entre ellos. El modelo de caso de uso es orientado al usuario, mientras que el modelo de caractersticas es orientado al reutilizador. El anterior provee una descripcin de lo que los sistemas en el dominio hacen. El siguiente, en cambio, muestra cul funcionalidad puede ser seleccionada cuando se aplica la ingeniera a nuevos sistemas en el dominio. FeatuRSEB analiza varios sistemas ejemplares, encuentra sus

elementos comunes y variabilidades, y produce un modelo de caractersticas. El proceso de construccin del modelo de caractersticas puede ser dividido en cuatro pasos: Primero, modelos de casos de uso individuales y ejemplares son fusionados dentro de un modelo de casos de uso de domino (o familia de modelos de caso de uso). Las diferencias son expresadas utilizando puntos de variacin. El modelo es formado de tal manera que los ejemplares originales pueden ser rastreados. Segundo, un modelo de caractersticas inicial es creado. Las caractersticas funcionales son derivadas del modelo de casos de uso de dominio. Caractersticas mandatarias y opcionales son identificadas de acuerdo a su frecuencia de ocurrencia en sistemas ejemplares. Las caractersticas identificadas son descompuestas en subcaractersticas. El modelo de casos de uso de dominio puede contener varios puntos de variacin. Las caractersticas correspondientes a tales puntos de variacin son divididas en subcaractersticas. Las subcaractersticas derivadas son rastreadas atrs hasta sus ocurrencias en el modelo de casos de uso de dominio.

31

El tercer paso aade caractersticas arquitectnicas al modelo de caractersticas. En lugar de la funcin especfica, las caractersticas arquitectnicas se relacionan a la estructura del sistema y configuracin. Finalmente el cuarto paso aade caractersticas de implementacin al modelo de caractersticas. 2.7 Problemas emergentes Como conclusin se renen los problemas emergentes concernientes a la

ingeniera de dominios. Sin embargo, los problemas listados no son necesariamente problemas de investigacin: Terminologa no establecida Es principalmente debida a la inmadurez del rea de investigacin. Ingeniera de dominio incompleta Significa que el modelado de dominio nunca puede ser completado; en cambio, el modelo puede ser siempre hecho ms exacto. Adems, el conocimiento del dominio de diferentes fuentes puede ser inconsistente entre ellos. Dominios distribuidos Estn tpicamente asociados con la ingeniera de dominios de aplicaciones existentes, es decir aspectos de reingeniera.

32

Dominios traslapados Son debidos a las dificultades en determinar los lmites del dominio o en dividir dominios en subdominios. Falta de soporte para ingeniera de dominios en tcnicas de modelado de objetos bien aceptadas Es debido a la inmadurez del rea de investigacin de la ingeniera de dominios y a la creencia que la orientacin a objetos inherentemente hace aplicaciones reutilizables. El ltimo problema es probablemente el ms severo de los arriba mencionados. En adicin, para las tcnicas de modelado de objetos, las deficiencias similares conciernen al lenguaje de modelado UML. Este no tiene soporte ingeniera de dominios tampoco. Sin embargo, la tcnica concerniente a MDA (Model-Driven Architecture, arquitectura conducida por modelo por sus siglas en ingls) que est basada en UML, puede proveer soporte a la ingeniera de dominios tambin. De esta forma, este tpico es un sujeto importante de futuras investigaciones.

33

34

3 PRINCIPIOS DEL ANLISIS Y DISEO ORIENTADO AL OBJETO PARA REUTILIZACIN

Todas las nociones que se refieren al diseo orientado al objeto se expresan en lo que Robert C. Martin llama los principios del DOO. Estos principios son: 1. El principio de abierto/cerrado. 2. El principio de sustitucin de Liskov. 3. El principio de inversin de dependencia. 4. El principio de separacin de la interfaz. 5. El principio de equivalencia reutilizacin/publicacin. 6. El principio de cierre comn. 7. El principio de reutilizacin comn. 8. El principio de dependencia acclica. 9. El principio de las dependencias estables. 10. El principio de las abstracciones estables. 3.1. El principio de abierto/cerrado (PAC) De todos los principios del diseo orientado al objeto, este es el ms importante. Simplemente significa lo siguiente: se deberan escribir los mdulos de tal manera que se puedan extender, sin tener que recurrir a ellos para ser modificados. En otras palabras, se desea que sean capaces de cambiar lo que hacen sin cambiar el cdigo fuente de los mismos. Esto podra sonar contradictorio, pero hay varias tcnicas para lograr el PAC (principio abierto/cerrado) en larga escala. Una de stas tcnicas est basada

35

en la abstraccin. De hecho la abstraccin es la clave del PAC. A continuacin algunas de estas prcticas son descritas. 3.1.1 Poliformismo dinmico

Considrese el siguiente cdigo en C++: struct Modem { enum Type {Guatemala, Salvador, Honduras) type; }; struct Guatemala { Modem::Type type; // modem relacionado a Guatemala }; struct Salvador { Modem::Type type; // modem relacionado al Salvador }; struct Honduras { Modem::Type type; // modem relacionado a Honduras }; void Logueo(Modem& m, string& pno, string& usuario, string& password) { if (m.type == Modem::Guatemala) 36

MarcaGuatemala((Guatemala&)m, pno); else if (m.type == Modem::Salvador) MarcaSalvador((Salvador&)m, pno); else if (m.type == Modem::Honduras) MarcaHonduras((Honduras&)m, pno) } En este ejemplo la funcin debe ser cambiada cada vez que un tipo de modem es aadido al software. Lo que es peor, ya que cada diferente tipo de modem depende de la enumeracin Modem::Type, cada modem debe ser recompilado cada vez que un nuevo tipo de modem es aadido. Por supuesto, este no es el peor atributo de esta clase de diseo. Los programas que son diseados de esta manera tienden a ser inundados de sentencias similares del tipo if/else or switch . Cada vez que cualquier cosa necesita ser hecha al modem, una sentencia if/else o switch se necesitar para seleccionar las funciones apropiadas a usar. Cuando nuevos modems son aadidos, o las polticas de los modems cambian, el cdigo debe ser revisado para todas estas sentencias de seleccin, y cada uno debe ser modificado apropiadamente. Lo que es peor, los programadores pueden utilizar optimizaciones locales que esconden la estructura de las sentencias de seleccin. Por ejemplo, podra ser que la funcin es exactamente la misma para los modems de Guatemala y Salvador. De esta manera se podra ver cdigo como el siguiente: if (modem.type == Modem::Guatemala) EnviaGuatemala((Guatemala&)modem, c); else EnvaSalvador((Salvador&)modem, c);

37

Claramente, tales estructuras hacen que el sistema sea mucho ms difcil de mantener y son muy propensos al error. Como ejemplo del PAC considrese la figura 1. Aqu la funcin Loguea depende solo de la interface Modem. Un modem adicional no causar que la funcin Loguea cambie. De esta manera, se ha hecho un mdulo que puede ser extendido con nuevos mdulos sin requerir modificacin, vase el siguiente cdigo: // Logueo ha sido cerrado para modificacin class Modem { public: virtual void Marcar(const string& pno) = 0; virtual void Enviar(char) = 0; virtual char Recibir() = 0; virtual void Colgar() = 0; }; void Logueo(Modem& m, string& pno, string& usuario, string& password) { m.Marcar(pno); }

38

Figura 1. Logueo cerrado para modificacin

3.1.2. Polimorfismo esttico Otra tcnica para estar conforme al PAC es a travs del uso de plantillas genricas. El siguiente cdigo muestra cmo se hace esto. La funcin Loguea puede ser extendida con muchos diferentes tipos de modems sin requerir modificacin. // Loguea es cerrado para modificacin a travs de poliformismo esttico template <typename MODEM> void Loguea(MODEM& m, string& pno, string& usuario, string& password) { m.Marca(pno); }

39

3.1.3 Metas arquitectnicas del PAC Al utilizar estas tcnicas para estar conformes al PAC, se pueden hacer mdulos que son extensibles, sin ser cambiados. Esto significa que, con una pequea previsin, se pueden aadir nuevas caractersticas al cdigo existente sin cambiarlo y solo agregando nuevo cdigo. An si el PAC no puede ser completamente conseguido, an parcialmente puede lograr dramticas mejoras en la estructura de la aplicacin. Es siempre mejor si los cambios no se propagan en el cdigo que actualmente existe. Si no se tiene que cambiar el cdigo que funciona, probablemente no se tendr que quebrar. 3.2 El principio de sustitucin de Liskov (PSL) Este principio fue acuado por Barbara Liskov en su trabajo acerca de la abstraccin de datos y teora de tipos. Tambin se deriva del concepto de diseo por contrato (Design by Contract, DBC) de Bertrand Meyer. El concepto, como se representa en la figura 2 establece que las clases derivadas deberan ser sustituibles por sus clases base. Esto es que un usuario de una clase base debera de continuar funcionando apropiadamente si un derivado de esa clase base le es pasada. Figura 2. Esquema de principio de sustitucin de Liskov.

40

En otras palabras, si alguna funcin de usuario toma un argumento sobre el tipo Base como se muestra en el siguiente cdigo, debera ser legal pasar una instancia del Derivado a esa funcin. // Ejemplo de Usuario, Base y Derivado void Usuario(Base& b); Derivado d; Usuario(d); Esto podra parecer obvio, pero hay sutilezas que necesitan ser consideradas. El ejemplo cannico es el del circulo/elipse. 3.2.1 El dilema del crculo/elipse: Como sabemos de matemtica, un crculo es solamente una forma degenerada de una elipse. Todos los crculos son elipses con centros coincidentes. Esta es una relacin que tienta a modelar crculos y elipses utilizando herencia como se muestra en la figura 3.

41

Figura 3. Dilema del crculo y el elipse

Mientras esto satisface el modelo conceptual, existen ciertas dificultades. Una mirada ms cercana a la declaracin de Elipse en la figura 4 empieza a exponerlo. Ntese que la elipse tiene tres elementos de datos. Los primeros dos son los centros, y el ltimo es la longitud del eje mayor. Si el crculo hereda del elipse, entonces tambin heredar estas variables de datos. Esto es desafortunado, ya que el crculo realmente solo necesita dos elementos de datos, un punto de centro y un radio.

42

Figura 4. Declaracin del elipse

An, si ignoramos el ligero exceso en el espacio, se puede hacer que un crculo se comporte apropiadamente al obviar el mtodo ponerCentros() para asegurarse que ambos centros son mantenidos con el mismo valor. Vase en el siguiente cdigo, de esta manera, el foco actuar como el centro del crculo y el eje mayor ser su dimetro. // manteniendo la coincidencia de centros de crculo void Circulo::ponerCentros(const Punto& a, const Punto& b) { suCentroA = a; suCentroB = a; } Ciertamente el modelo que se ha hecho es consistente en s mismo. Una instancia de Circulo obedecer todas las reglas de un circulo. No hay nada que se pueda hacer para violar esas reglas. De la misma manera para Elipse. Las dos clases forman un modelo muy bien consistente, an si Circulo tiene 43

demasiados elementos de datos. Sin embargo, Circulo y Elipse no viven solos en un universo por s mismos. Ellos cohabitan ese universo con muchas otras entidades, y proveen sus interfaces pblicas a esas entidades. Esas interfaces implican un contrato. El contrato puede no ser explcitamente establecido, pero est all sin embargo. Por ejemplo, usuarios de Elipse tienen el derecho de esperar el que sea correcto el siguiente fragmento de cdigo: void f(Elipse& e) { Punto a(-1,0); Punto b(1,0); e.ponerCentros(a,b); e.ponerEjeMayor(3); assert(e.tomarCentroA() == a); assert(e.tomarCentroB() == b); assert(e.tomarEjeMayor() == 3); } En este caso se espera que la funcin trabaje con un Elipse. De esta forma, se espera que ponga los centros, un eje mayor y entonces verifique que han sido apropiadamente configurados. Si se pasa una instancia de Elipse a esta funcin, ser bastante afortunado. Sin embargo, si se pasa una instancia de Circulo dentro de la funcin, fallar. Si se fuera a hacer el contrato de Elipse explcitamente, se vera una post condicin en ponerCentros() que garantizara que los valores de entrada son copiados a las variables miembros, y que la variable del eje mayor fue dejada sin cambio. Claramente Circulo viola esta garanta porque ignora la segunda variable de entrada de ponerCentros().

44

3.2.2 Diseo por contrato Reformulando el PSL, se puede decir que para que sea sustituible, el contrato de la clase base debe ser honrado por la clase derivada. Ya que Circulo no honra el contrato implicado por Elipse no es sustituible y viola el PSL. Para establecer el contrato de un mtodo, se declara lo que debe ser verdadero antes que el mtodo sea llamado. Esta es llamada la precondicin. Si la precondicin falla, el resultado del mtodo es indefinido, y el mtodo no debe ser llamado. Tambin se declara que las garantas del mtodo sern ciertas una vez que ha sido completado. Esta es llamada la post condicin. Un mtodo que falla en su post condicin no debera retornar resultados. Reformulando el PSL una vez mas, esta vez en trminos de los contratos, una clase derivada es sustituible por su clase base si: Sus precondiciones no son ms fuertes que el mtodo de clase base. Sus post condiciones no son ms dbiles que el mtodo de clase base. O en otras palabras, los mtodos derivados no deberan esperar ms y no proveer menos. 3.3 El principio de inversin de dependencia (PID) Si el principio abierto/cerrado establece el objetivo de la arquitectura orientada a objetos, el DIP establece el mecanismo primario. La inversin de dependencia es la estrategia de depender de interfaces o funciones abstractas y clases, en lugar de hacerlo en funciones concretas y clases. Este principio es la fuerza habilitadora detrs del diseo de componentes, COM, EJB, CORBA etc.

45

El diseo procedural exhibe una clase particular de estructura de dependencia. Como se muestra en la figura 5, esta estructura comienza arriba y baja hacia los detalles. Los mdulos de alto nivel dependen los mdulos de nivel ms bajo, los cuales dependen de mdulos de nivel an ms bajo, etc.. Una pequea reflexin expondr esta dependencia como intrnsecamente dbil. Los mdulos de alto nivel tratan con las polticas de alto nivel de la aplicacin. A estas polticas generalmente les importan poco los detalles que las implementan. Por qu entonces, deben estos mdulos de alto nivel depender directamente de esos mdulos de implementacin?. Una arquitectura orientada a objetos muestra una muy diferente estructura de dependencia, una en la cual la mayora de dependencia apunta hacia abstracciones. Es ms, los mdulos que contienen implementacin detallada no son ms de los que dependen, en lugar de eso, ellos dependen de abstracciones. De esta forma, la dependencia entre ellos ha sido invertida. Vase la figura 6. Figura 5. Estructura de dependencia de una arquitectura procedural

46

Figura 6. Estructura de dependencia de una arquitectura orientada a objetos

Claramente tal restriccin es draconiana y hay circunstancias mitigantes, pero tanto como sea posible el principio debe ser seguido. La razn es simple, las cosas concretas cambian mucho y las cosas abstractas mucho menos frecuentemente. Es ms, las abstracciones son puntos de bisagra, representan los lugares donde el diseo puede ser torcido o extendido, sin modificarse (principio abierto/cerrado). Objetos como COM refuerzan este principio, al menos entre

componentes. La nica parte visible de un componente COM es su interfase abstracta. De este modo, en COM, hay poco escape del PID. 3.3.1 Mitigando fuerzas Una motivacin detrs del PID es prevenir de depender de mdulos voltiles. El PID asume que cualquier cosa concreta es voltil. Mientras esto es frecuentemente as, especialmente en desarrollo temprano, hay excepciones. 47

Por ejemplo, la librera estndar string.h en C es muy concreta, pero no es voltil para nada. Supeditada en un entorno de string ANSI, no es perjudicial. De la misma manera, se han probado mdulos que son concretos, pero voltiles, y al estar supeditados a ellos no es tan malo. Ya que estos probablemente no cambiarn, no es probable que inyecten volatilidad al diseo. Pero hay que tener cuidado, sin embargo que una dependencia de string.h se podra tornar muy fea cuando los requerimientos del proyecto fuercen a cambiar a caracteres UNICODE. La no volatilidad no es un reemplazo para la propiedad de sustitucin en una interfase abstracta. 3.3.2 Creacin del objeto Uno de los lugares ms comunes donde el diseo depende de clases concretas en cuando esos diseos hacen instancias. Por definicin, no se pueden hacer instancias de clases abstractas. De esta manera, para hacer una instancia se debe depender de una clase abstracta. La creacin de instancias puede ocurrir a travs de la arquitectura del diseo, de esta forma, puede parecer que no hay escape y que la arquitectura completa estar llena con dependencias de clases concretas. Sin embargo, existe una solucin elegante a este problema llamado AbstractFactory, el cual es un patrn de diseo. 3.4 El principio de separacin de la interfaz (PSI) El PSI es otro de las tecnologas habilitadoras que soportan

substracciones de componentes tales como COM. Sin esto, los componentes y clases seran mucho menos tiles y portables. La esencia del principio es bastante simple. Si se tiene una clase que tiene varios clientes, en lugar de cargar la clase con todos los mtodos que el cliente necesita, se hacen

48

interfaces especficas para cada cliente y se multiplica la herencia de ellos en la clase. La figura 7 muestra una clase con muchos clientes, y una larga interfaz para servir a todos ellos. Ntese que cualquier cambio que es hecho a uno de los mtodos que el clienteA llama, ClienteB y ClienteC pueden ser afectados. Puede ser necesario recompilar y volver a desplegarlos, esto es desafortunado. Figura 7. Servicio grande con interfaces integradas

Una mejor tcnica es mostrada en la figura 8.

Los mtodos necesitados

por cada cliente son puestos en interfaces especiales que son especficas a esos clientes. Esas interfaces son mltiplemente heredadas por la clase Servicio, e implementadas all. Si la interfaz para ClienteA necesita cambiar, ClienteB y ClienteC permanecern sin ser afectados. No tendrn que recompilarse ni volverse a desplegar.

49

3.4.1 Qu significa especfico del cliente?| El PSI no recomienda que cada clase que use un servicio tenga su propia interfaz de clase especial que el servicio debe heredar. Si ese fuera el caso, el servicio debera depender de todos y cada uno de los clientes de una forma bizarra y nada saludable. En cambio, los clientes deberan ser categorizados por su tipo, y las interfaces para tipo de cliente deberan ser hechas. Si dos o ms diferentes tipos de clientes necesitan del mismo mtodo, este mtodo debera ser aadido a ambas de sus interfaces. Esto no es perjudicial ni confuso para el cliente. Figura 8. Interfaces separadas

3.4.2 Cambiando Interfaces Cuando las aplicaciones orientadas a objetos son mantenidas, las interfaces a clase existen y componentes a menudo cambian. Hay veces cuando estos cambios tienen un gran impacto y fuerzan la recompilacin y 50

distribucin de una gran parte de la aplicacin. Este impacto puede ser mitigado al aadir nuevas interfaces a objetos existentes en lugar de cambiar la interfaz existente. Los clientes de la vieja interfaz que desean acceder mtodos de la nueva, pueden consultar el objeto para esa interfaz como se muestra en el siguiente cdigo: void Cliente(Servicio* s) { if (NuevoServicio* ns = dynamic_cast<NuevoServicio*>(s)) { // use la interfaz del Nuevo servicio } } Como con todos los principios, se debe tener cuidado para no hacer trabajo innecesario. Quien espera por una clase con cientos de diferentes interfaces, algunas separadas por cliente y otras separadas por versin, de hecho debera estar aterrado. 3.5 El principio de equivalencia reutilizacin/publicacin (PERP) Un elemento reutilizable, ya sea un componente, una clase o un conjunto de clases, no puede ser reutilizado a menos que sea administrado por un sistema de publicacin de alguna clase. Los usuarios no querrn utilizar el elemento si son forzados a actualizar cada vez que autor lo cambia. De esta forma, aunque el autor haya publicado una nueva versin de su elemento reutilizable, debe estar anuente a dar soporte y mantener versiones anteriores mientras sus clientes van por el lento camino de estar listo para actualizar. De esta forma, los clientes rehusarn a reutilizar un elemento a menos que el autor 51

prometa mantener un rastro de nmero de versiones, y mantener antiguas versiones por un tiempo. Por consiguiente, un criterio para agrupar clases dentro de paquetes es reutilizacin. Ya que los paquetes son la unidad de la publicacin, ellos son tambin la unidad de reutilizacin. Por lo tanto, los arquitectos haran bien en agrupar clases reutilizables dentro de paquetes. 3.6 El principio de cierre comn (PCC) Un proyecto de desarrollo grande es subdivido dentro de una gran red de paquetes interrelacionados. El trabajo para administrar, probar y publicar esos paquetes no es trivial. Mientras ms paquetes cambien en cualquier publicacin dada, mayor ser el trabajo para reconstruir, probar y distribuir la publicacin. Por tanto sera deseable minimizar el nmero de paquetes que son cambiados en cualquier ciclo de publicacin dado del producto. Para lograr esto, se agrupan juntas clases que se cree que trabajarn juntas. Esto requiere cierto grado de previsin ya que se debe anticipar las clases de cambios que habr probablemente. An as, cuando se agrupan clases que cambian juntas dentro de los mismos paquetes, entonces el impacto del paquete de publicacin a publicacin ser minimizado. 3.7 El principio de reutilizacin comn (PRC) Una dependencia de un paquete es una dependencia de cualquier cosa dentro del paquete. Cuando un paquete cambia, y su nmero de publicacin es afectado, todos los clientes de ese paquete deben verificar que trabajan con el nuevo paquete, an si nada de lo que usaban dentro del paquete cambi. Frecuentemente se experimenta esto cuando un vendedor de sistema operativo publica uno nuevo. Se tendr que actualizar tarde o temprano, debido 52

a que el vendedor no dar soporte a la versin anterior por siempre. As que aunque nada de inters para nosotros cambi en la nueva publicacin, se debe hacer el esfuerzo de actualizar y revalidar. Lo mismo ocurre con paquetes si las clases que no son usadas juntas son agrupadas. Los cambios a una clase que no interesa todava forzarn una nueva publicacin del paquete, y an causarn que se tenga que ir al esfuerzo de actualizar y revalidar. 3.7.1 Tensin entre los principios de cohesin de paquetes Esos tres principios son mutuamente exclusivos. No pueden ser satisfechos simultneamente. Esto es debido a que cada principio beneficia a diferente grupo de gente. El Principio de equivalencia reutilizacin / publicacin y el principio de reutilizacin comn hacen la vida fcil a los reutilizadores, en tanto que el principio de cierre comn hace la vida ms fcil a los mantenedores. El PCC se esfuerza para hacer paquetes tan grandes como sea posible. Despus de todo, si todas las clases viven en un solo paquete, entonces solo un paquete cambiar siempre. El PRC trata de hacer paquetes muy pequeos. Afortunadamente los paquetes no estn escritos en piedra. De hecho, es la naturaleza de los paquetes cambiar y modificarse durante el curso del desarrollo. Temprano en un proyecto, los arquitectos pueden preparar la estructura de paquetes de tal manera que el PCC domine y el desarrollo y mantenimiento sea ayudado. Ms tarde, en tanto la arquitectura se estabiliza, los arquitectos pueden refactorizar la estructura de paquetes para maximizar el principio de equivalencia reutilizacin / publicacin y el principio de cierre comn para reutilizadores externos.

53

3.8 El principio de dependencia acclica (PDA) Ya que los paquetes son los grnulos de una publicacin, tambin tienden a enfocarse en el personal. Los ingenieros tpicamente trabajan en un solo paquete en lugar de trabajar en docenas. Esta tendencia es amplificada por los principios de cohesin de paquetes, ya que tienen a agrupar juntos esas clases que estn relacionadas. De esta forma, los ingenieros encontrarn que sus cambios son dirigidos a unos pocos paquetes. Una vez que estos cambios son hechos, se pueden publicar esos cambios al resto del proyecto. Antes que se pueda hacer esta publicacin, sin embargo, se debe probar que el paquete funciona. Para hacer eso, se debe compilar y construir con todos los paquetes de los que depende. Con un poco de suerte este nmero es pequeo. Considrese la figura 9. Se puede reconocer que hay unas fallas en la arquitectura. El PID parece haber sido abandonado y junto con l el PAC. El GUI depende directamente del paquete de comunicaciones y aparentemente es responsable de transportar datos al paquete de anlisis

54

Figura 9. Red de paquetes acclicos

An

as,

se

utilizar

esta

estructura

para

algunos

ejemplos.

Considrese qu se requerira para publicar el paquete Protocolo. Los ingenieros tendran que construirlo con la ltima publicacin del paquete ErrorComunicaciones, y correr sus pruebas. Protocolo no tiene otras dependencias, as que ningn otro paquete es necesario. puede probar y publicar con un mnimo de trabajo. 3.8.1 Un ciclo se introduce Pero ahora supongamos que hay un ingeniero trabajando en el paquete ErrorComunicaciones. Ha decidido que necesita desplegar un mensaje en la pantalla. Ya que la pantalla es controlado por el GUI, enva un mensaje a uno Esto es bueno, se

55

de los objetos GUI para tener el mensaje en pantalla. Esto significa que ha hecho a ErrorComunicaciones dependiente de GUI, vase la figura 10. Figura 10. Un ciclo ha sido agregado

Ahora qu ocurre cuando quienes estn trabajando en Protocolo desean publicar su paquete. Tienen que construir su juego de pruebas con ErrorComunicaciones, GUI, Comunicaciones, ControlModem, Anlisis y BaseDatos, esto es claramente desastroso. La carga de trabajo de los ingenieros ha sido incrementada de forma aberrante, debido a una sola pequea dependencia que se fue de control. Esto significa que alguien necesita estar vigilando la estructura de dependencia del paquete con regularidad y quebrar ciclos donde aparezcan. De otra manera las dependencias transitivas entre mdulos causarn que cada mdulo dependa de los otros mdulos. 56

3.8.2

Quebrando un ciclo

Los ciclos pueden ser quebrados de dos maneras. La primera involucra hacer un nuevo paquete, y la segunda hace uso del principio de inversin de dependencia y el principio de separacin de la interfaz. La figura 11 muestra cmo quebrar el ciclo al agregar un nuevo paquete. Las clases que ErrorComunicaciones necesitaba son sacadas de GUI y puestas en un nuevo paquete llamado AdministradorMensajes. Ambos GUI y ErrorComunicaciones estn hechos para depender de este nuevo paquete.

57

Figura 11. Ciclo quebrado

Este es un ejemplo de cmo la estructura de paquete tiende a cambiar durante el desarrollo. Nuevos paquetes vienen, y las clases se mueven de antiguos paquetes a nuevos paquetes para quebrar ciclos. La figura 12 muestra una imagen antes y despus de la otra tcnica para quebrar ciclos. Aqu se ven dos paquetes que estn unidos por un ciclo. La clase A depende de la clase X y la clase Y depende de la clase B. Se quiebra el ciclo al invertir la dependencia entre Y y B. Esto es hecho al aadir una nueva interfaz, BY a B. Esta interfaz tiene todos los mtodos que necesita Y. Y usa esta interfaz y B la implementa. 58

Ntese la colocacin de POR. Est situado en el paquete con la clase que lo usa. Este es un patrn que se ver repetido a lo largo de los casos de estudio que tratan con paquetes. Las interfaces son muy a menudo incluidas dentro del paquete que las usa, en lugar del paquete que las implementa. Figura 12. Otra tcnica

3.9 El principio de las dependencias estables (PDE) Aunque este parece ser un principio obvio, hay algo que se puede decir acerca de esto. La estabilidad no siempre es bien entendida.

59

3.9.1 Estabilidad Qu se entiende por estabilidad? Mantener un centavo sobre su lado. Estar estable en esa posicin? Posiblemente muchos dirn que no. Sin embargo, a menos que sea cambiado, permanecer en esa posicin por un muy largo tiempo. De esta forma, la estabilidad no tiene nada que ver directamente con la frecuencia del cambio. El centavo no est cambiando, pero es difcil pensar que est estable. La estabilidad est relacionada con la cantidad de trabajo requerida para hacer un cambio. El centavo no es estable porque requiere muy poco trabajo para volcarlo. Por otro lado, una mesa es muy estable debido a que toma un considerable esfuerzo darle vuelta. Cmo se relaciona esto con el software? Hay muchos factores que hacen a un paquete de software difcil de cambiar. Su tamao, complejidad, claridad, etc.. Se van a ignorar todos esos factores y se va a hacer enfoque en algo diferente. Un camino seguro para hacer que un paquete de software sea difcil de cambiar, es hacer que muchos otros paquetes de software dependan de l. Un paquete con muchas dependencias entrantes es muy estable debido a que requiere de gran trabajo para conciliar cualquier cambio con todos los paquetes dependientes. Figura 13. X es un paquete estable

60

La figura 13 muestra a X, un paquete estable. Este paquete tiene otros tres dependientes de l, y por lo tanto tiene tres buenas razones para no cambiar. Se puede decir que es responsable de esos tres paquetes. Por otro lado, X no depende de nada, as que no tiene influencia externa para cambiar. Se dice que es independiente. La figura 14 muestra un paquete muy inestable. Y no tiene otros paquetes que dependen de l, se puede decir que no es responsable. Y tambin tiene tres paquetes de los cuales depende, as que los cambios pueden venir de esas tres fuentes externas. Se dice que Y es dependiente. Figura 14. Y es inestable

3.9.2 Mtricas de estabilidad Se puede calcular la estabilidad de un paquete utilizando un tro de simples mtricas.

61

Ca

Acoplamiento aferente. La cantidad de clases fuera del paquete que dependen de clases dentro del paquete, es decir dependencias entrantes.

Ce

Acoplamiento eferente. La cantidad de clases fuera del paquete de las cuales las clases dentro del paquete dependen, es decir dependencias salientes.

Inestabilidad. I = [0,1].

Ce Ca + Ce

esta es una mtrica que tiene un rango

Si no hay dependencias salientes, entonces I ser 0 y el paquete es estable. Si no hay dependencias entrantes entonces I ser 1 y el paquete es inestable. Ahora se puede expresar este principio de otra manera: Depender de paquetes cuya mtrica I es menor que la propia. 3.9.3 Fundamento Debera ser todo el software estable? Uno de los atributos ms importantes del software bien diseado es que sea fcil de cambiar. El software que es flexible en la presencia de requerimientos cambiantes es tenido por bueno. Aunque tal software es inestable por definicin. De hecho, se deseara que porciones del software fueran inestables. Se desea que ciertos mdulos sean fciles de cambiar para que cuando los requerimientos cambien de rumbo, el diseo puede responder con facilidad. La figura 15 muestra cmo el PDE puede ser violado. Flexible es un paquete que se pretende que sea fcil de cambiar. Se desea que Flexible sea inestable. Sin embargo, algunos ingenieros, trabajando en el paquete llamado Estable, pusieron una dependencia en Flexible. Esto viola el principio de 62

dependencias estables, ya que la mtrica I para Estable es mucho menor que la mtrica I para Flexible. Como resultado, Flexible ya no ser ms fcil de cambiar. Un cambio a Flexible forzar a tratar con Estable y todas sus dependencias. Figura 15. Violacin del principio de dependencias estables

3.10 El principio de las abstracciones estables (PAS) Al hacer una aplicacin se puede prever la estructura de paquetes como un conjunto de paquetes interconectados con unos inestables arriba, y paquetes estables abajo. En esta visin, todas las dependencias apuntan hacia abajo. Aquellos paquetes que estn arriba son inestables y flexibles. Pero aquellos abajo son muy difciles de cambiar. Esto lleva a un dilema: se desean paquetes en el sistema que son difciles de cambiar? Claramente, mientras ms paquetes hayan que son difciles de cambiar, menos flexible ser el diseo total. Sin embargo hay una laguna sobre la cual podemos avanzar. Los paquetes altamente estables debajo de la red de dependencia pueden ser muy 63

difciles de cambiar, pero de acuerdo al principio abierto/cerrado no tienen que ser difciles de extender. Si los paquetes estables al final son altamente abstractos, pueden ser fcilmente extendidos. Esto significa que es posible componer la aplicacin de paquetes inestables que son fciles de cambiar, y paquetes estables son fciles de extender. De esta manera el principio de las abstracciones estables es una reafirmacin del principio de inversin de dependencia. Esto establece que los paquetes que son los ms dependientes (estables) deberan tambin ser los ms abstractos. Pero, cmo se mide la abstraccin? 3.10.1 Mtricas de abstraccin Se pueden derivar otro tro de mtricas para ayudar a calcular la abstraccin. Nc Na Nmero de clases en el paquete. Nmero de clases abstractas en el paquete. Hay que recordar que una clase abstracta es una clase con al menos una interfaz pura, y no puede ser instanciada. A Abstraccin. A= Na . Nc La mtrica A tiene un rango de [0,1] tal como la mtrica I. El valor de A como 0 significa que el paquete no contiene clases abstractas. Un valor de 1 significa que el paquete no contiene ms que clases abstractas.

64

3.10.2 La grfica de I versus A El principio de abstracciones estables puede ser ahora reafirmado en trminos de las mtricas de A e I: I debera incrementarse tanto que A decrece. Esto es, que los paquetes concretos deberan ser inestables mientras que los paquetes abstractos deberan ser estables. Esto se puede trazar grficamente en la grfica A versus I de la figura 16. Figura 16. Grfica de A versus I

Parece claro que los paquetes deberan aparecer en alguno de los dos lados de la figura 16. Aquellos en la parte de arriba a la izquierda son completamente abstractos y muy estables. Aquellos en la parte abajo a la derecha son completamente concretos y muy inestables. Esta es justa la manera que se desean. 17? dnde debera ir? Sin embargo, qu hay del paquete X en la figura

65

Figura 17. Dnde debera ir X en la grfica A vs I?

Se puede determinar donde se desea el Paquete X, al ver a donde no se desea que vaya. La esquina superior derecha de la la grfica AI representa paquetes que son altamente abstractos y de los que nadie depende. Esta es la zona de inutilidad. Ciertamente no se desea que X est en esa zona. Por el otro lado, el punto de ms abajo a la izquierda de la grfica representa paquetes que son concretos y tienen cantidades de dependencias entrantes. Este punto representa el peor caso para un paquete. Ya que los elementos all son concretos, no pueden ser extendidos en la forma en que las entidades abstractas pueden; y ya que tienen montones de dependencias entrantes, el cambio puede ser muy doloroso. Esta es la zona de dolor, y ciertamente no se desea que el paquete est en esa zona. Maximizando la distancia entre estas dos zonas nos da una lnea llamada la secuencia principal. Sera deseable que los paquetes estuvieran situados en esta lnea lo ms posible. Una posicin en esta lnea significa que el paquete es abstracto en proporcin a sus dependencias entrantes y es concreto en proporcin a sus dependencias salientes. En otras palabras, las clases en tal paquete estn conforme el principio de inversin de dependencia.

66

3.10.3

Mtricas de distancia

Esto es un juego de mtricas ms para examinar. Dados los valores A e I de cualquier paquete, se busca saber cun lejos el paquete est de la secuencia principal. D Distancia. D = |A + I 1| 2 D Distancia normalizada. D = |A + I 1|. Esta mtrica es mucho Esta tiene un rango de [0,~0.707].

ms conveniente que D ya que el rango es de [0,1]. Cero indica que el paquete es directamente sobre la secuencia principal. 1 indica que el paquete est tan lejos como es posible de la secuencia principal. Estas mtricas miden la arquitectura orientada a objetos. Son imperfectas y depender de ellas como el nico indicador de una arquitectura fuerte sera imprudente. Sin embargo, pueden ser y han sido, usadas para ayudar a medir la estructura de dependencia de una aplicacin.

67

68

MTODOS DE REUTILIZACIN DE SOFTWARE

El desarrollo de software ha sido dividido tradicionalmente en fases tales como anlisis, diseo, implementacin, pruebas, mantenimiento y diferentes ciclos de vida han sido propuestos para ayudar a manejar la dificultad de los procesos de desarrollo de software. El desarrollo de software es un proceso consistente de una secuencia de pasos parcialmente ordenados partiendo de especificaciones ms o menos formales que llevan eventualmente a un cdigo ejecutable. Cada paso en este proceso es una transformacin de una descripcin de un problema en un nivel i dentro de un problema de nivel i + 1. Con este punto de vista de desarrollo de software, los mtodos de reutilizacin pueden ser divididos en dos grupos: Mtodos generativos: los cuales se concentran en reutilizar las transformaciones de descripciones de problemas y Mtodos composicionales: los cuales se concentran en reutilizar las descripciones de problemas como bloques de construccin para el desarrollo de software en curso 4.1 Mtodos generativos de reutilizacin Los mtodos generativos de reutilizacin automatizan una parte del desarrollo de software, es decir, algunas de las transformaciones diseadas y ejecutadas durante el desarrollo de software. La idea de enfoques generativos es muy similar a aquella de programacin automtica, una especificacin formal de alto nivel debera ser compilada dentro de una implementacin. Sin embargo, mientras la programacin automtica trata de automatizar el 69

desarrollo de software desde la especificacin a la implementacin. La reutilizacin generativa en cambio deja el objetivo el automatizar la secuencia completa de transformaciones durante el proceso de desarrollo de software o el dominio de aplicacin es estrechado. Existen tres enfoques de reutilizacin que son generativos por naturaleza: 1) Sistemas basados en lenguaje. 2) Generadores de aplicacin. 3) Sistemas transformacionales. 4.1.1 Sistemas basados en lenguaje Los sistemas basados en lenguajes son tambin conocidos como Lenguajes Ejecutables de Especificacin o lenguajes de muy alto nivel (VHLLs). Usan generalmente modelos matemticos tales como una teora de conjuntos, o ecuaciones restrictivas que abarcan patrones reutilizables en un lenguaje de alto nivel. El problema con los VHLL es que tienen la ventaja de ser aplicables generalmente al desarrollo de software pero la brecha semntica entre la abstraccin matemtica utilizada en el modelo y el desarrollo de software es an muy grande. SETL (SET language) es un VHLL de amplio espectro basado en la teora de conjuntos. Los tipos de datos en el lenguaje son ya sea tipos atmicos (entero, reales o valores booleanos) o tipos de datos compuestos (conjuntos o tuplas). Las operaciones de conjuntos unin, interseccin, diferencia y elevacin de conjuntos, as como los iteradores de conjuntos estn definidos en el lenguaje. Un mapa enlaza los elementos en el dominio a aquellos en el rango. 70

MODEL Es una restriccin declarativa basada en VHLL resolviendo simultneamente una coleccin de ecuaciones restrictivas. El lenguaje contiene construcciones para declaracin de datos y ecuaciones de consistencia. Un compilador ejecuta un anlisis para determinar si las ecuaciones de consistencia pueden ser satisfechas y para encontrar el orden de cmputos que asignarn valores consistentes a los objetos de datos. El compilador MODEL chequea la completitud y consistencia de las especificaciones. 4.1.2 Generadores de aplicacin Los generadores de aplicacin automatizan el proceso de desarrollo completo en un dominio de aplicacin muy estrecho. Un generador de aplicacin es una herramienta que toma especificaciones de entrada y produce programas ejecutables como salida. Las especificaciones son tpicamente abstracciones de alto nivel en un dominio de aplicacin especfico. Construir un generador de aplicacin es difcil, y requiere identificar los dominios apropiados, definir los lmites del dominio y el modelo computacional subyacente para el dominio de aplicacin, para definir partes variantes e invariantes de una familia de aplicacin, para definir el mtodo de especificacin de entrada y definir productos generados por el generador de aplicacin. Para construir un generador de aplicacin se requiere no slo un ntimo conocimiento del dominio de aplicacin, sino tambin el dominio debe ser estrecho, bien entendido, con tecnologa que cambie lentamente.

71

4.1.3 Sistemas transformacionales Los sistemas transformacionales no automatizan completamente el proceso de desarrollo de software. La asistencia al desarrollador de software es necesaria para seleccionar entre transformaciones aplicables. Con sistemas transformacionales, el software es desarrollado en dos fases. Primero, el comportamiento semntico de un sistema de software es descrito en un lenguaje de especificacin y seguidamente, las transformaciones guiadas por el usuario son aplicadas a la especificacin. Paddle es un sistema transformacional que guarda una historia de desarrollo como una secuencia de transformaciones aplicadas. Paddle provee el programa, es decir, la estructura de la secuencia de transformaciones necesarias para implementar alguna aplicacin. Las decisiones de diseo que llevan a escribir el programa no son guardadas, as que las transformaciones son difciles de entender y modificar. Glitter durante sus es un sistema transformacional Para seleccionar que de codifica una en reglas de

transformacionales decisiones que un desarrollador de software ha hecho aplicaciones. coleccin transformaciones reutilizables, ha sido utilizada tecnologa de sistemas expertos. Las reglas abarcan conocimiento experto acerca de cmo cumplir metas durante transformaciones de programas. Cada regla consiste de una meta, estrategias y una parte de seleccin racional. Glitter automatiza tanto del proceso de transformacin como es posible. Si las estrategias son incompletas o la seleccin racional falla, el sistema pide al desarrollador de software por gua.

72

4.2 Mtodos composicionales de reutilizacin La reutilizacin composicional es la forma ms comn de reutilizacin de software. Est basada en reutilizar componentes de desarrollos de software anteriores como los bloques de construccin para un nuevo desarrollo de software. Los componentes guardados en libreras reutilizables pueden contener cualquier unidad que es de valor potencial para un reutilizador, tales como cdigo fuente, subsistemas, datos de prueba, documentacin de usuario, diseo, plan de desarrollo, arquitectura, instrucciones de instalacin, etc.. Cuando se considera un modelo transformacional de desarrollo de software los componentes reutilizados con equivalentes a descripciones de problemas a uno de los niveles durante el proceso de desarrollo de software. La idea principal detrs de este enfoque reutilizacin de cualquier componente de software previamente desarrollado- es sencilla pero hay muchas dificultades potenciales con su aplicacin. Para discutir las partes cruciales de la reutilizacin composicional ms precisamente, los siguientes aspectos de este enfoque de reutilizacin de software son tomados en cuenta: Identificacin de componentes reutilizables. Descripcin de componentes. Recuperacin de componentes reutilizables. Adaptacin de los componentes a necesidades especficas. Integracin de componentes dentro del software desarrollado actualmente. Identificacin. La identificacin de partes reutilizables es el primer paso hacia la reutilizacin de software sistemtica y efectiva. Prever las futuras 73

oportunidades de reutilizacin es difcil. Requiere experiencia en desarrollo. Tambin, sin embargo es necesario conocimiento de dominio obtenido en la base de anlisis de dominio. Muchos aspectos deben ser considerados cuando las unidades reutilizables son consideradas. Entre estas estn:

Granularidad. La granularidad (tambin llamada tamao) de un componente es importante. Mientras mas grande sea el componente reutilizable, ms grande ser la mejora en productividad de reutilizacin. Pero una unidad reutilizable ms grande involucra muchas funciones que pueden hacer del componente ms difcil de reutilizar debido a que su funcionalidad compleja puede no encajar exactamente dentro de la que se requiere. Categoras. Un componente reutilizable puede ser cualquier producto intermedio del proceso de desarrollo de software, es decir, no solo cdigo fuente sino tambin diseo, especificaciones, requerimientos, pruebas, documentacin. Mientras ms temprano sea en el proceso de desarrollo de software, ms alto ser el nivel de reutilizacin. Generalidad. Generalmente, los componentes independientes de aplicacin que pueden ser aplicados a un amplio rango de dominios de aplicacin se supone que son reutilizados ms frecuentemente, pero tienden a ser ms difciles de reutilizar debido a la generalidad que ofrecen. Est todava muy lejos de aclarar qu es lo que debera ser un

componente reutilizable y cmo identificarlo. Ms que ser capaces de 74

reconocer componentes reutilizables desde el principio, su identificacin y construccin incremental parecen ser el camino que la reutilizacin de software debe tomar. Descripcin: La descripcin de componentes facilita el entendimiento de la

funcionalidad de los componentes. Una buena descripcin de componentes debera expresar qu hace un componente sin saber cmo lo hace. Adems de ser abstracto, una descripcin de componente debera ser clara, no ambigua y entendible. Tambin, debera la descripcin de una amplia variedad de componentes reutilizables. En la comunidad de reutilizacin de software, dos enfoques a la descripcin de componentes pueden ser vistos: Modelos de componentes. Un modelo de componente es una descripcin abstracta para los componentes en un dominio dado que representa todos los atributos que un componente reutilizable debera tener. Hay un esfuerzo por encontrar un modelo aceptado en general. Hasta ahora el modelo de referencia 3C ha recibido mayor aceptacin. El modelo 3C distingue distintos aspectos de un componente reutilizable, su concepto por ejemplo, una descripcin abstrada de la funcionalidad que el componente de software provee, su contenido, por ejemplo, una implementacin que dice cmo el componente logra la funcionalidad descrita en su concepto; y su contexto que describe la relacin del componente con otros sobre los cuales depende. El modelo de componentes REBOOT (REuse Based on ObjectOriented Techniques, reutilizacin basada en tcnicas de orientadas a objetos por sus siglas en ingls), est basada en una clasificacin de facetas. Cuatro facetas particularmente relevantes para reutilizar han 75

sido propuestas: abstraccin, operaciones, operandos, y dependencias. Cada faceta puede tener un nmero arbitrario de trminos dentro de su vocabulario restringido. Un componente puede ser considerado como una combinacin de los trminos dentro de sus facetas. Lenguajes de descripcin de componentes. Ya sea al nivel de implementacin o al nivel de diseo, estos lenguajes tratan de capturar los atributos esenciales de los componentes. La meta de un lenguaje de descripcin de componentes es proveer semntica de la funcionalidad de los componentes. De hecho, hay dos principales enfoques a especificaciones formales: uno algebraico y un enfoque basado en modelo. Una especificacin formal algebraica describe interfaces sintcticas por medio de nombres y firmas para todas las operaciones de componentes y declara las relaciones entre las operaciones. Una especificacin formal basada en modelo define precondiciones y poscondiciones para cada operacin. Recuperacin: Las libreras reutilizables pueden crecer hasta una gran coleccin de componentes. Para que no se convierta en medio de solo escritura, deben estar bien organizados. En particular, mtodos para recuperacin de componentes que codificaran descripcin abstracta de componentes y los emparejaran con los requerimientos del reutilizador deben ser agregados a la librera. Librera y ciencias de la informacin. Hay dos grupos de mtodos utilizados en la librera y ciencia de la informacin: uno que usa un vocabulario controlado, por ejemplo, enumerado, clasificacin de faceta y

76

valor de atributos, y el otro que no restringe vocabulario, llamado tambin recuperacin libre de texto. La clasificacin enumerada usa descripciones cortas, usualmente descripciones metafricas de una palabra para romper mbitos en clases mutuamente exclusivas que forman una estructura jerrquica. Esto solo es posible en bien entendidos, dominios de aplicacin estrechos con abstracciones de una palabra que abarcan una gran cantidad de conocimiento de dominio de tal manera que pueden ser universalmente entendidos. La clasificacin provee un mtodo natural de bsqueda cuando el dominio es bien analizado y existen categoras jerrquicas exclusivas. Una desventaja de la clasificacin enumerada es la dificultad conectada con cambiarla. La clasificacin multifacetada organiza trminos de un mbito dentro de facetas. El desarrollo de facetas es cumplido identificando vocabulario importante en un dominio y agrupando trminos dentro de facetas. La clasificacin de valor de atributos usa un conjunto de atributos y sus valores para describir un componente en la librera. Es similar a la clasificacin de facetas porque usa atributos y valores como la clasificacin de facetas utiliza facetas y valores. Las diferencias son que los valores de atributos no estn restringidos a tener valores predefinidos como tienen las facetas y no hay lmite en el nmero de atributos utilizados para descripcin de componentes. El enfoque de vocabulario controlado tiene una desventaja que los vocabularios del

77

reutilizador y el desarrollador pueden diferir. Usualmente, un tesauro de sinnimos es provedo para eliminar esta diversidad. La recuperacin libre de texto est basada en lenguaje natural. La representacin textual del componente es utilizada como una descripcin de componente. Una ventaja de la recuperacin libre de texto es que no se requiere codificacin y consultas en lenguaje natural son fciles de formular debido a la cercana al reutilizador. Pero la ambigedad del lenguaje natural, falta de completitud e inconsistencia hacen la recuperacin de componentes menos precisa. Recuperacin basada en conocimiento. La recuperacin basada en conocimiento usa varias clases de razonamiento la nueva consulta con una antigua o que coincide la consulta con los componentes. Estos mtodos necesitan una base de conocimiento para el dominio de aplicacin y para las decisiones tomadas. Estos requieren ms recursos humanos especialmente para el desarrollo de la base de conocimiento pero tienen un potencial para ser ms poderosas porque capturan consultas y componentes semnticos. Recuperacin basada en hipertexto. La recuperacin basada en hipertexto organiza informacin no lineal dentro de una red de nodos y enlaces. Un reutilizador puede acceder la informacin guardada navegando a lo largo de los enlaces. Para disear una red de hipertexto se requiere estudiar el dominio de aplicacin cuidadosamente y encontrar un conjunto ptimo de relaciones. Puede tambin ser difcil aadir un nuevo componente debido a que requiere estudiar exhaustivamente los vnculos entre los nuevos componentes y los antiguos. Los hipertextos son fciles de usar y pueden llevar al componente correcto rpidamente. Pero el utilizador puede tambin perderse durante la navegacin o alguna informacin puede an ser 78

inaccesible debido a la ruta que ha escogido el cual no tiene enlace a la informacin requerida. Recuperacin basada en especificacin. Los enfoques basados en especificacin usan descripciones formales de los componentes como base para el ordenamiento parcial de los componentes en la librera. Estos componentes difieren mayormente en la expresividad del lenguaje de especificacin y tambin en cun completamente toman ventaja del lenguaje de especificacin. Algunos hacen uso de signos de componentes solamente, por ejemplo, interfaces sintcticas; los otros manejan tambin las semnticas de especificaciones No existe acuerdo acerca de cul mtodo de recuperacin es el ms adecuado. Un simple mtodo de recuperacin no es suficiente para encontrar todos los componentes relevantes para una consulta de bsqueda dada. Diferentes usuarios individuales prefieren y son ms exitosos con diferentes mtodos. Ninguno de los mtodos soporta el entendimiento de los componentes ms que moderadamente. Inventar mtodos de recuperacin que se ajusten mejor para componentes reutilizables permanece como un reto. Formulacin de consultas. Es otro importante asunto en el mtodo de recuperacin. Aqu, la indisposicin del recuperador de formular largas y precisas consultas debera ser tomada en cuenta. El reutilizador preferira una formulacin de consultas interactiva donde un sistema ayude a definir el query. El hecho que el reutilizador a menudo no es capaz de formular completamente su consulta al principio del proceso de recuperacin es acentuado hacia fuera y la construccin incremental de consultas es propuesta. Tambin debera ser considerada una recuperacin aproximada

79

o relajada. Siempre que una coincidencia exacta falle, los componentes que son ms cercanas a los requerimientos deberan ser recuperados Adaptacin..Una de las caractersticas bsicas de un componente reutilizable es su generalidad. Este acto es llamado adaptacin de componentes o especializacin. La adaptacin de componentes puede ser hecha usando diferentes tcnicas: o Substitucin de parmetros. La parametrizacin permite construir componentes genricos, por ejemplo componentes con parmetros que son adaptados a necesidades especficas poniendo valores a sus parmetros. o Herencia. La herencia es un mecanismo que permite aadir nuevas propiedades a clases existentes (rasgos substanciales del paradigma orientado a objetos). Este es un ejemplo de programacin incremental cuando las subclases son definidas al establecer cmo difieren de las existentes. o Modificaciones. Las modificaciones de un cdigo de componente es una reutilizacin de caja blanca que requiere entender todos los detalles de la implementacin. Tambin, esta tcnica puede invalidar la correccin del componente original. Integracin. Para desarrollar un componente para reutilizacin y

subsecuentemente reutilizar el componente, no solo el componente, sino tambin su relacin con otros componentes debe ser bien entendido. La efectividad de la reutilizacin depende altamente de la manera en que esos componentes son combinados. Hay no solo un nmero de diversas entidades 80

de software componibles tales como funciones, clases , plantillas, mdulos, procesos, pero consecuentemente tambin un nmero de estilos de componentes componentes. ellos. La manera ms comn de describir la integracin de componentes es usar lenguajes de interconexin de componentes. Los lenguajes de interconexin de mdulos describen los mdulos en trminos de operaciones exportadas que un mdulo implementa y operaciones importadas que un modelo usa. Los mdulos son ensamblados dentro de un sistema interconectndolos a travs de exportaciones e importaciones. Los lenguajes declarativos son sugeridos en ser usados para describir la interconexin de componentes. Estandarizando ciertos mecanismos para interaccin de componentes, los lenguajes declarativos pueden ser utilizados para describir los modos en que los componentes estn conectados. La principal ventaja es que las interacciones de los componentes no necesitan ser descritas en detalle y solo relaciones entre componentes son establecidas. Adems, los lenguajes declarativos pueden ser invertibles, de tal manera que las mismas relaciones pueden ser interpretadas de distintas maneras. Hasta ahora la mayor parte del nfasis ha sido puesto y solo una pequea parte en cmo estn compuestos. Ms investigacin es necesaria en cmo componer software desde elementos computacionales. Una gran cantidad de trabajo reciente ha sido hecho en reas tales como lenguajes de interfaz de mdulos, marcos de trabajo especficos de dominio, y arquitecturas de software. En particular, la arquitectura de software como descripcin de alto nivel de 81 para combinar los sistemas suponen de software diferentes desde formas estos de Diferentes estilos

empaquetamiento de componentes y diferentes clases de interacciones entre

cmo sistemas especficos estn compuestos desde estos componentes has sido reconocido como un aspecto crtico del diseo de cualquier sistema de software ms grande y ha ganado significativa atencin recientemente. 4.2.1 Reutilizacin dentro de la metodologa orientada a objetos

Recientemente, muchos investigadores y practicantes del rea de reutilizacin de software dedicaron su atencin al desarrollo de software orientado a objetos. Se cree que los lenguajes orientados a objetos facilitan el desarrollo de software que puede ser reutilizado. Aqu recientemente un fuerte mpetu pudo ser observado en el desarrollo y rpida dispersin del lenguaje de programacin Java. Existen de hecho diferentes niveles de reutilizacin ofrecidos en el desarrollo de software orientado a objetos. Los objetos y clases son unidades reutilizables bsicas. Pero ellos solos no pueden ser suficientes para una reutilizacin efectiva. No solo los componentes por s mismos sino la manera en que esos componentes son combinados afectan a la reutilizacin de software significativamente. De hecho, las metodologas orientadas a objetos dieron origen a marcos de trabajo de aplicacin, y ms recientemente, patrones de diseo para construccin de aplicaciones orientadas a objetos. Los patrones de diseo comunican soluciones a problemas de diseo recurrentes en el desarrollo OO. Ambos, marcos de trabajo y patrones elevan la reutilizacin a un nivel ms alto debido especialmente a que dan soporte a la reutilizacin de diseo. Mientras es probablemente justo decir que ya sea la afirmacin de que la orientacin a objetos fomenta la reutilizacin es justificado permanece al menos por algn tiempo por ser visto, puede ser establecido por ahora que ha habido 82

ms progreso substancial logrado en buscar conceptos y formas que permitan expresar diseo estndar de software dentro de la metodologa orientada a objetos. 4.2.2 Reusabilidad de objetos La unidad fundamental en el desarrollo orientado a objetos es el objeto. Los conceptos bsicos envueltos en la nocin de objeto son abstraccin de datos, ocultamiento de informacin y encapsulacin. Los objetos son definidos en trminos de tipos de dato abstracto donde cada tipo define tambin un conjunto de mtodos. Un objeto tiene su estado interno (dato) y sus operaciones (mtodos). El nico medio en que otros objetos interactan con un objeto es a travs del envo de mensajes (solicitudes). Las siguientes caractersticas de un objeto fomentan su reusabilidad: o Objetos separan la interfaz de la implementacin. o Los objetos a menudo se acercan mucho a la realidad. o Objetos vienen en distintos tamaos y niveles de abstraccin. o Los objetos viven completamente durante el desarrollo de software. 4.2.3 Reutilizacin de clases La clase es una plantilla comn para objetos similares. La clase define la interfaz tambin como el comportamiento de un conjunto de objetos. Los objetos instanciados de una clase ejecutan mtodos comunes y comparten estructura comn mientras que cada objeto dentro de una clase retiene sus propios estados.

83

Los lenguajes de programacin OO usualmente ofrecen una librera de clases predefinidas. Las clases en la librera estn relacionadas a travs de relacin de herencia. La herencia tiene dos posibles usos: o Instanciacin hace un objeto especfico desde una plantilla de clase al poner valores a variables definidas en la clase. Esto es el por qu los objetos algunas veces son llamados instancias de la clase. Cuando un objeto es hecho, sus datos internos son aprovisionados de acuerdo a la estructura de la clase y las operaciones de la clase estn relacionadas con esos datos. Muchos objetos pueden ser hechos instanciando la misma clase. o Subclaseado permite la derivacin de nuevas clases al modificar las clases existentes, por ejemplo, al establecer cmo difieren de estas. El subclaseado involucra dos tipos de relaciones entre clase y subclase: Especializacin: la especializacin aade nueva funcionalidad a las subclases. Esto retiene la semntica de la interfaz, por ejemplo, una subclase de la interfaz es un subtipo de su interfaz de superclase. Omisin: la omisin puede refinar, redefinir, o an esconder la funcionalidad de los padres. Redefinir y esconder rompe la semntica de la interfaz. Los beneficios de la reutilizacin de clases incluyen menos cdigo a desarrollar, menos cdigo a mantener, y no tener que redisear los mismos elementos repetidamente. La herencia hace ms fcil incluir cdigo existente 84

extendiendo las clases originales y aadiendo nuevas. Pero la herencia permite tambin permite redefinicin y ocultamiento que podra tener efectos dainos sobre la reutilizacin. Tales usos diversos del mismo mecanismo de herencia causa dificultades en la reutilizacin de clases. Un mecanismo til que la herencia permite es definir clases abstractas. Una clase abstracta no tiene implementacin para sus mtodos, as que no puede ser instanciado. Una clase abstracta define una interfaz comn para sus subclases mientras que las definiciones concretas son dejadas a la subclase en s misma. Esto ayuda a definir familias de clases intercambiables con interfaz comn. Las clases abstractas hacen las libreras de clases orientadas a objetos ms reutilizables y fciles de entender. El mecanismo que las clases abstractas proveen es uno de los ms importantes: las clases deberan ser derivadas desde superclases abstractas tan a menudo como fuera posible y todas las subclases de una clase abstracta deberan solo aadir o refinar pero no omitir operaciones de la clase padre. Entonces, todas las clases pueden responder a la interfaz idntica, es decir todos son subtipos de la misma clase abstracta. Tambin las diferentes vistas de un implementador y un reutilizador que pueden causar diversidad en la jerarqua de clases deberan ser sealadas. Un implementador est mayormente involucrado con la rpida derivacin de una nueva implementacin de clase desde las existentes. Un reutilizador est ms interesado en la herencia de interfaz que dice cuando una clase puede ser utilizada en lugar de otra. Otra fuente de potenciales dificultades es que las libreras de clases de pueden volver vastas. Reutilizar clases desde tal jerarqua puede ser una 85

laboriosa tarea que consume tiempo. Es necesario mirar a los nombres de clases, a los nombres de mtodos, o en el peor de los casos a la implementacin de mtodos para investigar oportunidades de reutilizacin. La herencia es una reutilizacin de caja blanca que requiere que todo lo interno de una clase padre sea visible a su subclase. El ambiente OO usualmente facilita la reutilizacin por medio de la visualizacin de la estructura de jerarqua de clases y dando soporte a una fcil navegacin de clases. 4.2.4 Reutilizacin en el mundo La Internet, una coleccin de redes de rpido crecimiento, y la World Wide Web, un sistema de comunicacin e informacin de hipertexto, dieron origen a no solo a nuevas maneras de comunicacin entre la gente sino tambin cambiaron la industria del software significativamente. La internet y la web ltimamente requieren nuevos enfoques al desarrollo de software. La habilidad de correr sobre plataformas heterogneas y distribuidas es la necesidad para todos los futuros sistemas de software. Al tener tal plataforma independiente de software, la reutilizacin se incrementa en una tasa significativa. No es necesaria ms reescritura especfica de cdigo. La misma pieza de software es reutilizada a lo largo de una amplia variedad de sistemas de computacin, plataformas de hardware y sistemas operativos. Java, ha sido designado para hacer uso completo de los avances en redes distribuidas. Java es un lenguaje que trae una nueva dimensin a la reutilizacin de software tambin. Sin duda, la caracterstica clave de Java que ayuda a la reutilizacin de software es su genuina orientacin orientada a objetos. Pero Java introduce capacidades adicionales que soportan la reutilizacin: 86

o Java es arquitectura neutral. El cdigo de Java es capaz de correr en cualquier plataforma que tenga el Java runtime environment. Con Java, la capacidad de reutilizacin es aumentada al tener una simple aplicacin que es inmediatamente utilizable en mltiples plataformas. o Java es portable. La especificacin de lenguaje de Java define comportamiento estndar aplicado a los tipos de datos a travs de plataformas heterogneas. La reutilizacin es mejorada debido a que la implementacin no es ms dependiente del hardware. o Java es dinmico y robusto. Enlace dinmico de clases en tiempo de corrida y chequeo de estructuras de datos en tiempos de compilacin y corrida causan que Java pueda ser reutilizado sin recompilacin an si el entorno ha cambiado. Hay otra caracterstica de Java que debera ser tomada en cuenta, el cdigo de Java puede ser una parte ejecutable de un documento Web. Java applets, por ejemplo, pequeas aplicaciones que son bajadas directamente de pginas web, traen riqueza, interactividad, y mejoran la entrega de la informacin a las paginas Web. A travs de internet, la reutilizacin es fomentada a lo largo del mundo. 4.2.5 Marcos de trabajo de aplicacin

Un marco de trabajo es un diseo reutilizable para soluciones de problemas en algn particular dominio de problema. Un marco de trabajo de aplicacin orientado a objetos es un conjunto de clases que tomadas juntas representan un abstraccin o esqueleto parametrizado de una arquitectura. 87

Los marcos de trabajo agrupan clases, objetos, y relaciones juntas para construir una aplicacin especfica. Un marco de trabajo es una arquitectura de software genrica junto con un conjunto de componentes de software genricos que pueden ser utilizados para realizar arquitectura de software especfica. Un marco de trabajo OO de un conjunto de clases abstractas y concretas que se comunican extensivamente a travs de mensajes. Un marco de trabajo ideal debera proveer todas las clases concretas desde las cuales nuevas aplicaciones deberan ser compuestas en su librera de clases. En el desarrollo de software real basado en marcos de trabajo, algunas de las clases especficas de aplicacin deben ser construidas. Son tpicamente derivadas al subclasear desde clases abstractas provedas en el marco de trabajo. Aqu, las clases abstractas representan partes variables del marco de trabajo que son configuradas de acuerdo a las necesidades especficas de una aplicacin . Hay muchos diferentes marcos de trabajo OO disponibles. Entre ellos, uno de los mejor conocidos es el Model-View-Controller (MVC) construido en el sistema Smalltalk-80. MVC es un marco de trabajo de interfaz de usuario que provee una arquitectura uniforme para aplicaciones interactivas. Una vista de clase abstracta convierte algunos aspectos interesantes del modelo a una forma visible. Un modelo en si mismo entra y actualiza la aplicacin. Disear un marco de trabajo requiere un anlisis minucioso de dominio as como experiencia de distintos proyecto. Los asuntos ms crticos en disear un marco de trabajo es conseguir su flexibilidad, es decir, fcil adaptacin a todas las aplicaciones en el dominio, y su extensibilidad, es decir, la habilidad de cubrir todas las aplicaciones en el dominio. Tambin, es necesaria una baja sensibilidad a la evolucin del dominio.

88

Nuevas aplicaciones pueden ser construidas ms rpido cuando los marcos de trabajo son reutilizados. Cada marco de trabajo logra su funcionalidad por medio de una cooperacin de componentes. Entender y administrar un simple componente puede volverse ms difcil porque esto depende de sus relaciones con otros componentes tambin. Aparte de esto los marcos de trabajo proveen soluciones marco al problema que puede no necesariamente encajar en el problema. 4.2.6 Patrones de diseo Los patrones de diseo introducen un nuevo mecanismo para expresar conocimiento de diseo que experiment el uso de desarrolladores sobre distintas aplicaciones. Cada patrn de diseo sistemticamente identifica, nombres y explica un recurrente problema de diseo y presenta buenas y elegantes soluciones a esto. El patrn de diseo es una microarquitectura, un pequea agrupacin de clases describiendo responsabilidades de partes elementales as como las relaciones y colaboraciones entre ellos. Los patrones son construidos por observacin y al reunir experiencia durante el desarrollo de muchas aplicaciones orientadas a objetos. Una plantilla de patrn involucra: Patrn: nombre, sinnimos, descripcin de una sentencia, ttulo, alias. Intencin: meta, motivo. Aplicabilidad: contexto, ejemplos. Consecuencias: la situacin final, resultados. Restricciones: interdependencias, fuerzas, factores que afectan. Resolucin: estructuras, acciones.

89

Implementacin: fragmentos de cdigo, preocupaciones prcticas para estar al tanto. Aplicaciones: usos conocidos. Riesgos: indicaciones de potenciales dificultades en el uso. Patrones relacionados: referencias a otros patrones. La plantilla uniforme utilizada para la descripcin de patrones los hace

fciles de aprender, comparar y utilizar. Cada patrn explica una solucin a un problema exhaustivamente de tal manera que ninguna informacin esencial es perdida para los lectores. La descripcin de patrones utiliza una plantilla la cual es una estructura de atributos. La plantilla contiene cuatro elementos esenciales: un nombre de patrn, un problema, una solucin y consecuencias. Diagramas de clases, diagramas de objetos y diagramas de interaccin son utilizados para ilustraciones de problemas. Adems de notaciones grficas, lenguaje natural describe decisiones, alternativas, ejemplos, y productos que llevan al patrn de diseo propuesto. Los patrones dividen las soluciones en sus partes elementales las cuales pueden ser ms tarde recombinadas y reutilizadas. Los patrones describen minuciosamente una sola solucin atmica. Las descripciones de las combinaciones se pueden simplificar debido a que se pueden referir a los patrones ya descritos y guardados. Los marcos de trabajo de aplicacin y los patrones de diseo son a menudo confundidos. Las principales diferencias entre marcos de trabajo y patrones son:

90

Los patrones de diseo son ms abstractos que los marcos de trabajo. Los marcos de trabajo pueden ser plasmados en cdigo, pero slo ejemplos de patrones pueden ser plasmados en cdigo. Los patrones de diseo son elementos arquitectnicos ms pequeos que los marcos de trabajo. Un marco de trabajo tpico contiene varios patrones de diseo, pero el contrario nunca es cierto. Los patrones de diseo son menos especializados que los marcos de trabajo. Los marcos de trabajo siempre tienen un dominio de aplicacin particular. Por el contrario, los patrones de diseo pueden ser utilizados independientemente de una aplicacin.

Los patrones ocurren fuera de los metodologas orientadas a objetos tambin. Los patrones de diseo varan en su granularidad y nivel de abstraccin. Los patrones pueden abstraer un anlisis, un diseo o un proceso. Los patrones podran ser organizados en familias de patrones relacionados para que el reutilizador pueda aprenderlos encontrarlos ms fcilmente. Cuando se coleccionan patrones, la manera de categorizar patrones en una coleccin debera ser propuesta tambin.

91

92

EJEMPLOS DE REUTILIZACIN COMPOSICIONAL CON PATRONES DE DISEO EN PHP

Para ejecutar los ejemplos en este trabajo de graduacin se utiliz el

webserver PHP Wamp en versin 2.0. Tambin se utiliz la herramienta Dreamweaver en su versin CS3 para correr los ejemplos, as como la herramienta opensource en java UMLET versin 10.3 para realizar los diagramas UML en los ejemplos. 5.1 Uso del patrn de diseo observer Parte de la expresividad de la programacin orientada a objetos es la habilidad de construir redes complejas de interconexiones entre objetos. Vinculados juntos, los objetos pueden intercambiar servicios e informacin. A menudo, se desea que los objetos puedan comunicarse cuando un objeto cambia. Pero por muchas razones, se puede preferir no quemar el cdigo de las lneas de comunicacin. Quizs se desea formar y reformar las conexiones para responder a condiciones en la aplicacin o tal vez simplemente se desea refactorizar el cdigo de comunicacin para evitar interdependencias entre clases. 5.1.1 El problema Cmo se puede alertar (potencialmente) a muchos objetos cuando un cierto estado del objeto cambia? Hay algn esquema dinmico, alguno que permita interconexiones entrantes y salientes al ejecutarse algn script?

93

5.1.2 La solucin El patrn observer permite a los objetos expresar inters en el estado de otro objeto y provee un mecanismo para el observado, o el sujeto de contactar a todos sus observadores, los clientes cuando su estado cambia. El observer es una colaboracin entre una clase observable (el sujeto) y una o ms clases observadoras (los clientes). La clase observable permite a los observadores registrarse con l. Entonces, siempre que el estado del objeto observable cambia, todos los observadores registrados son notificados. El patrn observador separa al sujeto del cliente, dejando a cada observador tomar su propia accin en respuesta al cambio. (El patrn observador es tambin conocido como publicar/subscribir, la cual es una metfora valida para la interaccin entre los objetos en el patrn.) El patrn observador es flexible y extensible. La carga de saber qu clases desean seguir la informacin del estado del observable y cmo cada una de estas clases tiene la intencin de usar la informacin, es removida de la clase observable en s misma. Adicionalmente, un observer puede registrar o quitar el registro en cualquier momento, si es apropiado. Se puede tambin definir mltiple clase observer concreta, permitiendo un comportamiento variado en la aplicacin. 5.1.3 Cdigo de ejemplo Un ejemplo clsico es el cdigo en un dialogo observando el estado de un checkbox. Al checkbox no le importa si est siendo observando por un objeto o por cientos. Simplemente enva un mensaje cuando cambia de estado. De la misma forma, al dilogo no le importa cmo el checkbox es implementado, slo 94

se interesa acerca del estado de la caja y acerca de ser notificado cuando el estado cambia. En este ejemplo, se demostrar el patrn observer al preparar una lista de clientes observable. Este objeto representa una tabla de base de datos de clientes. El objecto ListaClientes enviar notificaciones cuando nuevos clientes sean aadidos. El objeto utiliza un objeto ListaSuscripcion para implementar la observabiidad. Los objetos que escuchan son una instancia de ListaSuscripcion que otros objetos pueden utilizar para registrarse a s mismos con ListaClientes. Los objetos que escuchan usan el mtodo agregar() para aadirse a s mismos a la lista y ListaClientes utiliza el mtodo invocar() para enviar un mensaje a los que escuchan. No importa si no hay quienes escuchan, o si hay cientos de ellos. Lo especial aqu es que los objetos que escuchan no tienen interaccin directa o dependencia de ListaClientes, los que escuchan son aislados de los clientes por la clase ListaSuscripcion. En el presente ejemplo habr solo un escuchador. Un objeto bitcora que despliega cualquier mensaje de ListaClientes a la consola. La relacin entre los objetos es mostrada en la figura 18

95

Figura 18. ListaClientes y su ListaSuscripcion con bitcora agregada

//EjemploObserver.php <?php // CLASE BITACORA class Bitacora { public function mensaje( $enviador, $TipoMensaje, $datos ) { print $TipoMensaje." - ".$datos."\n"; } } class ListaSuscripcion { var $lista = array(); public function agregar( $objeto, $metodo ) { $this->lista []= array( $objeto, $metodo );} public function invocar() { // OBTIENE LA LISTA DE ARGUMENTOS DE LA FUNCION $args = func_get_args(); 96

foreach( $this->lista as $l ) // LLAMA A LA FUNCION DE USUARIO CON MATRIZ } DE PARAMETROS { call_user_func_array( $l, $args ); } } class ListaClientes { public $escuchadores; public function ListaClientes() { $this->escuchadores = new ListaSuscripcion();} public function agregarUsuario( $usuario ) {$this->escuchadores->invocar( $this, "agregar", "$usuario" );} } $l = new Bitacora(); $cl = new ListaClientes(); $cl->escuchadores->agregar( $l, 'mensaje' ); $cl->agregarUsuario( "starbuck" ); ?>

5.1.4 Explicacin del ejemplo Al correr el cdigo php el resultado es el siguiente agregar - starbuck 97

El cdigo primero hace una bitcora y lista de clientes. Posteriormente, la bitcora se suscribe a la lista de clientes utilizando el mtodo agregar(). El paso final es agregar un usuario a la lista de clientes. La adicin del cliente dispara un mensaje al escuchador en este caso, la bitcora que despliega el mensaje acerca de la adicin del cliente. Debera ser fcil extender este cdigo ya sea para hacer algn aprovisionamiento de cliente basado en la adicin de cliente o para enviar algn correo, ambos sin cambiar el cdigo en ListaClientes. Esto es aflojar el acoplamiento, y es la razn por la que el patrn observer es tan importante. Existen innumerables usos para el patrn observer en el desarrollo de software. Los sistemas basados en ventanas usan patrones observer y los llaman eventos. Compaas como Tibco manejan su modelo de negocios entero va el patrn observer, conectando grandes sistemas de negocios como recursos humanos y planilla. Sistemas de base de datos usan un patrn observer y llaman a cdigo que escuchan eventos de triggers. Estos triggers son activados cuando ciertos tipos de registros son cambiados en la base de datos. Un enfoque con patrn observer es tambin til siempre que se piense que un cambio de estado es relevante pero no se entiende para quin ser relevante; se pueden codificar los escuchadores ms tarde y no atarlos al objeto que ser observado. Un potencial error con el patrn observer es el ciclo infinito. Esto puede suceder cuando elementos que observan un sistema pueden tambin alterar tal sistema. Por ejemplo, un combo desplegable altera un valor y muestra la estructura de datos acerca de l. Esa estructura de datos entonces notifica al combo desplegable que el valor ha cambiado, con lo cual el combo cambia su valor para coincidir, solo para enviar otra notificacin a la estructura de datos, y 98

as sucesivamente. La forma ms fcil de resolver este problema es codificar el combo de tal manera que se prevenga la recursin. Esto simplemente ignorara un mensaje de la estructura de datos si est actualmente en medio de notificar a la estructura de datos acerca de un nuevo valor. 5.2 Uso del patrn de diseo factory En la programacin orientada a objetos, la forma ms comn de hacer un objeto es con el operador new, el constructor de lenguaje para tal fin. Pero en algunos casos new puede ser problemtico. Por ejemplo, al hacer muchas clases de objetos requiere una serie de pasos: se podra necesitar computar o traer la configuracin inicial del objeto; o se habra que tener que escoger a cul instanciar de muchas clases; o quizs se tiene que hacer un lote de otros objetos que ayuden antes de hacer el objeto que se necesita. En esos casos new es un proceso ms que una operacin, un diente de una rueda de maquinaria. 5.2.1 El problema

Cmo se puede hacer tales objetos complejos fcil y convenientemente, sin programar copiando y pegando. 5.2.2 La solucin Hacer un factory, una funcin o mtodo de clase para fabricar nuevos objetos. Para entender el valor de un factory, pinsese en el diferencia entre $connexion =& new MySqlConnection($usuario, $password, $basedatos);

99

.Disperso a lo largo del cdigo, y la ms concisa.. $connexion =& hacer_conexion(); El ltimo pedazo de cdigo centraliza el mismo para hacer una conexin a base de datos en la fbrica o factory hacer_conexion(), y siguiendo la analoga anterior, transforma el proceso de hacer una conexin de base de datos a una simple operacin, una operacin justo como new. El patrn factory inyecta inteligencia a la creacin del objeto. Encapsula la creacin de un objeto y retorna el nuevo objeto al que lo llam. Se necesita cambiar la estructura de un objeto y cmo es creado. Solo hay que ir al factory del objeto y cambiar el cdigo una vez. El patrn factory es tan til porque es fundacional, es decir, que aparece una vez y otra vez en muchos otros patrones y aplicaciones. 5.2.3 Cdigo de ejemplo El patrn abstracto factory es la mquina expendedora de los patrones de diseo. Se solicita lo que se desea, y como una mquina expendedora vende un objeto basado en el criterio. El valor es que se puede cambiar qu tipos de objetos son creados a travs del sistema al solamente alterar el factory. En este ejemplo el factory hace objetos Registro, donde cada registro tiene un ID, un nombre y un apellido. La relacin entre clase se muestra en la figura 19.

100

Figura 19. Las clases Registro y FabricaRegistro

No hay manera para forzar estrictamente que solo el factory pueda hacer objetos de un tipo particular en PHP. Pero si se usa el factory lo suficientemente a menudo, las ingenieros que copian y pegan el cdigo terminarn usando el factory, se convertir rpidamente la forma de facto de hacer diferentes tipos de objeto. El cdigo <?php class Registro { 101

public $id = null; public $nombre = null; public $apellido = null; public function __construct( $id, $nombre, $apellido ) { $this->id = $id; $this->nombre = $nombre; $this->apellido = $apellido; } } class RegistroLocal extends Registro { public $direccion1 = null; public $ direccion2 = null; public $ciudad = null; public $estado = null; public $zip = null; public function __construct( $id, $nombre, $apellido, $direccion1, $ direccion2, $ciudad, $estado, $zip ) { parent::__construct( $id, $nombre, $apellido ); $this->direccion1 = $direccion1; $this-> direccion2 = $addr2 direccion2 $this->ciudad = $ciudad; $this->estado = $estado; $this->zip = $zip; 102

} } class RegistroForaneo extends Registro { public $direccion1 = null; public $direccion1 = null; public $ciudad = null; public $estado = null; public $postal = null; public $pais = null; public function __construct( $id, $nombre, $apellido, $direccion1, $direccion2, $ciudad, $estado, $postal, $pais ) { parent::__construct( $id, $nombre, $apellido ); $this-> direccion1= $direccion1; $this-> direccion2= $direccion2; $this->ciudad = $ciudad; $this-> estado = $estado; $this-> postal = $postal; $this-> pais = $pais; } } class FabricaRegistro {

103

public static function hacerRegistro( $id, $nombre, $apellido, $direccion1, $direccion2, $ciudad, $estado, $postal, $pais ) { if ( strlen( $pais ) > 0 && $pais != "USA" ) return new RegistroForaneo( $id, $nombre, $apellido, $direccion1, $direccion2, $ciudad, $estado, $postal, $pais ); else return new RegistroLocal( $id, $nombre, $apellido, $direccion1, $ direccion2, $ciudad, $estado, $postal ); } } function leerRegistros() { $registros = array(); $registros []= FabricaRegistro::hacerRegistro( 1, "Jack", "Herrington", "4250 San Jaquin Dr.", "", "Los Angeles", "CA", "90210", "" ); $records []=FabricaRegistro:: hacerRegistro ( 1, "Megan", "Cunningham", "2220 Toorak Rd.", "", "Toorak", "VIC", "3121", "Australia" ); return $records; } $registros = leerRegistros(); foreach( $registros as $r ) { 104

$clase = new ReflectionClass( $r ); print $clase->getName()." - ".$r->id." - ".$r->nombre." - ".$r>apellido."\n"; } ?> 5.2.4 Explicacin del ejemplo La primera seccin del cdigo implementa la clase base Registro, as como las clases derivada RegistroLocal y RegistroForaneo. Estas son envoltorios de datos bastante simples. Entonces la clase factory puede construir ya sea un RegistroLocal o un RegistroForaneo dependiendo de la data que se le pase. El cdigo de prueba aadido al final del script aade unos pocos registros, y entonces imprime su tipo junto con algo de sus datos. Al corrrer el script de una pgina php guardada como EjemploFactory.php se obtiene el siguiente resultado: RegistroLocal - 1 - Jack - Herrington RegistroForaneo - 1 - Megan Cunningham Se puede utilizar el patron abstract factory en una aplicacin PHP de base de datos de diferentes maneras: Creacin de objetos de bases de datos: la factory provee cualquiera de los tipos asociados con las diferentes tablas en la base de datos. Creacin de objetos portable: la factory provee una cantidad de

objetos diferentes dependiendo ya sea del tipo de sistema operativo el cdigo se correo o las diferentes bases de datos que la aplicacin tiene adjunta. 105

Creacin por estndar: la aplicacin soporta varios estndares de formato de archivo y usa la factory para hacer un objeto apropiado para el tipo de archivo dado. Los lectores de archivo pueden registrarse a s mismos con el factory para aadir soporte sin tener que cambiar a cualquiera de los clientes. Despus de utilizar los patrones por un tiempo, se puede desarrollar un sentido de cundo es sensato utilizar un tipo particular de patrn. Se podra utilizar este patrn cuando se est haciendo un feo lote de construcciones con varios tipos de objetos. Se encontrar que si se necesita cambiar los tipos de objetos que son creado, o cmo ellos son creados, se tendr mucho cdigo para cambiar. Si se usa un factory, se necesitar cambiar esa creacin de objeto en un solo lugar. 5.3 Uso del patrn de diseo strategy Cuando se desarrolla cdigo orientado a objetos, se necesita a veces que un objeto cambie su comportamiento ligeramente basado en circunstancias. Por ejemplo, un men podra presentarse a s mismo horizontal o verticalmente dependiendo de la preferencia de diseo de un usuario, o un pedido podra calcular impuesto sobre ventas de forma diferente basado en la direccin de envo del cliente. Una tpica implementacin de un objeto como Menu tiene mtodos para agregar(), eliminar() y reemplazar() elementos de men, setear() el estilo, y mostrar() a s mismo. No importa qu clase de men se quiera hacer, los mens ofrecen una interfase consistente; solo los algoritmos internos de uno o ms mtodos -al menos mostrar(), por ejemplo- difieren. Pero, qu sucede digamos, cuando el nmero de estilos de mens se expande?, o en el caso del pedido, qu ocurre cuando departamento, estado y las reglas extranjeras de 106

impuestos son tomadas en cuenta? Si muchos mtodos tienen instrucciones case para casos especiales, una simple encapsulacin de otro caso pronto resulta complicada, difcil de leer y difcil de mantener. 5.3.1 El problema Cmo se puede cambiar la implementacin interna de un objeto fcilmente, escogiendo una implementacin para utilizar a la vez que el script es ejecutado, en lugar de cuando es escrito?. Cmo se puede codificar un conjunto de implementaciones que sean fcil de mantener y extender? 5.3.2 La solucin

Cuando una clase abarca mltiples implementaciones y una instancia puede dinmicamente escoger cualquiera de esas implementaciones, se usa el patrn strategy para separar el objeto de sus algoritmos. O, para ponerlo ms simple, strategy. El patrn strategy es muy poderoso debido a que la idea esencial del mismo es el pincipio orientado a objetos del polimorfismo. Hay claros ejemplos del patrn strategy fuera del dominio de la programacin. Si necesito ir de la casa al trabajo en la maana, pueden escoger entre varias estrategias: puedo manejar mi carro, tomar el bus, ir en bicicleta o volar en helicptero. Cada estrategia tiene los mismos resultados pero usa recursos de forma diferente, y la opcin de la estrategia depende del tiempo consumido, la disponibilidad de recursos particulares (como tener un vehculo) y la conveniencia de cada si los mtodos de una clase utilizan instrucciones case constantemente, es un buen candidato para refactorizar dentro del patrn

107

mtodo. Una buena estrategia en un da puede ser una pobre estrategia al siguiente, as que la opcin de la estrategia tiene que se hecha dinmicamente. 5.3.3 Cdigo de ejemplo

En este ejemplo, se utilizar un carro. Este cdigo recomendar un carro basado en algunos criterios de bsqueda. En este caso, se darn especificaciones para un carro ideal y se dejar que el cdigo traiga el carro que ms cercanamente coincide con las expectativas deseadas. El valor del patrn strategy es que se puede alterar el cdigo de comparacin de carro independientemente de la seleccin del mismo. En la figura 12 se muestra el UML. El objeto ElegidorCarro usa un objeto MedidorCarro para comparar cada carro con el modelo ideal. Entonces, el mejor carro es retornado al cliente. Figura 20. Relacin entre objetos ElegidorCarro, MedidorCarro y Carro

108

Cdigo <?php // class Carrro { public $nombre; public $velocidad; public $apariencia; public $millas; public function Carro( $nombre, $velocidad, $apariencia, $millas ) { $this->nombre = $nombre; $this->velocidad = $velocidad; $this->apariencia = $apariencia; $this->millas = $millas; } } class MedidorCarro { private function diff( $a, $b ) { return abs( $a - $b ); } public function medida( $a, $b ) { $d = 0; 109

$d += $this->diff( $a->velocidad, $b->velocidad); $d += $this->diff( $a->apariencia, $b-> apariencia); $d += $this->diff( $a->millas, $b-> millas); return ( 0 - $d ); } } class ElegidorCarro { private $ideal; private $alg; function ElegidorCarro( $ideal, $alg ) { $this->ideal = $ideal; $this->alg = $alg; } public function elegir( $lista ) { $minrank = null; $encontrado = null; $alg = $this->alg; foreach( $lista as $carro ) { $rank = $alg->medida( $this->ideal, $carro ); if ( !isset( $minrank ) ) $minrank = $rank; if ( $rank >= $minrank ) 110

{ $minrank = $rank; $encontrado= $car; } } return $encontrado; } } function llevarCarro( $carro ) { $lista = array(); $ lista [ ]= new Carro( "zippy", 90, 30, 10 ); $ lista [ ]= new Carro( "mom'n'pop", 45, 30, 55 ); $ lista [ ]= new Carro( "beauty", 40, 90, 10 ); $ lista [ ]= new Carro( "enviro", 40, 40, 90 ); $cw = new MedidorCarro(); $cc = new ElegidorCarro( $car, $cw ); $encontrado = $cc->elegir( $lista ); echo( $encontrado->name."\n" ); } llevarCarro( new Carro( "ideal", 80, 40, 10 ) ); llevarCarro ( new Carro( "ideal", 40, 90, 10 ) ); ?>

111

5.3.4 Explicacin del ejemplo Comenzando desde el principio del archive, se define la clase Carro, la cual guarda el nombre del mismo y las mtricas de velocidad, apariencia y millas. Cada una est calificada de 0 a 100 (para hacer el clculo fcil). Entonces viene la clase MedidorCarro, la cual compara dos carros y regresa una mtrica de comparacin. Finalmente, est la clase ElegidorCarro, la cual usa una clase MedidorCarro para seleccionar el mejor carro basado en algunos criterios de entrada. La funcin llevarCarro() hace un conjunto de carros y entonces usa una clase ElegidorCarro para tomar el carro de la lista que mejor se ajusta al criterio (pasado va otro objeto Carro). Al correr el cdigo de PHP de prueba guardado como

EjemploStrategy.php se obtiene el siguiente resultado: % php strategy.php zippy beauty La salida muestra que el carro recomendado si se desea velocidad es el zippi, una buena aproximacin. El carro recomendado si se desea algo ms sexi es l carro beauty. El cdigo que deduce que un carro es una buena eleccin est totalmente abstrado del cdigo que atraviesa la lista de carros y trae uno de esa lista. Se puede cambiar el algoritmo que mide un cierto carro independientemente del cdigo que lo trae el cual es el carro correcto de la lista medida. Por ejemplo, se pueden agregar carros que le han interesado recientemente o que se han posedo en el pasado dentro del algoritmo de 112

medicin. O se puede cambiar el cdigo de llevarCarro para seleccionar los tres mejores y proveer una eleccin entre ellos. 5.4 Uso del patrn de diseo adapter Las interfaces cambian. Es un simple y perenne hecho que los programadores tienen que aceptar y lidiar. Los vendedores cambian su cdigo; las libreras de sistema son revisadas; y los lenguajes de programacin y sus libreras evolucionan. 5.4.1 El problema Cmo se puede proteger a s mismo de cambios en el API de libreras externas que se utilizan?. Si se escribe una librera, se puede proveer un medio para permitir a usuarios existentes actualizarse suavemente, an si se ha cambiado el API?. Cmo se puede cambiar la interfase de un objeto para que se ajuste mejor a las necesidades? 5.4.2 La solucin El patrn adapter provee una interfase diferente a un objeto. Se puede utilizar adapter para realizar una interfase familiar a un objeto diferente, evitando el fastidio de actualizar o refactorizar el cdigo cliente. Hay que considerar qu ocurre cuando el API de la librera de un tercero cambia. Se podra solamente morder el polvo y cambiar todo el cdigo cliente, pero a menudo no es tan simple. Se podra estar trabajando en un nuevo proyecto que requiere las caractersticas de la nueva versin de la librera, pero ya tiene actualmente docenas de antiguas aplicaciones legadas que funcionan 113

bien con la versin previa de la librera. Probablemente no se podra justificar el uso de la nueva caracterstica si la actualizacin significa tocar el cdigo cliente para todas las otras aplicaciones tambin. 5.4.3 Cdigo de ejemplo

Se utilizar una clase adaptador para transferir datos entre dos mdulos cuando no se quiere cambiar el API de cualquiera de ellos. Algunas veces se tiene que obtener datos de dos objetos, cada uno de los cuales utiliza un formato diferente de datos. Cambiar uno o ambos objetos simplemente no es una opcin debido a que se tendr que hacer toda clase de otros cambios en el resto del cdigo. Una solucin a este problema es utilizar una clase adaptador. Un adaptador es una clase que entiende ambos lados de la barrera de transferencia de datos y adapta un objeto para hablar con otro. El adaptador demostrado en este ejemplo adapta datos de un objeto de base de datos en data usable por medio de un motor de texto y grfico. La figura 21 muestra al AdaptadorRegistroGrafico situado entre el TextoGrafico en la izquierda y la ListaRegistros en la derecha. El objeto TextoGrafico especifica muy bien el formato que espera para datos utilizando una clase abstracta llamada OrigenDatosTextoGrafico. La ListaRegistros es una clase contenedora que tiene una lista de registros, donde cada registro contiene un nombre, edad y salario.

114

Figura 21. El adaptador situado entre la grfica y los datos

Para este ejemplo, se desea una grfica de los salarios. El trabajo del adaptador es tomar datos de ListaRegistros y convertirlos en una forma ajustable para TextoGrafico al cambiar los datos dentro de un objeto DatosOrigenTextoGrafico.

El cdigo <?php abstract class OrigenDatosTextoGrafico { abstract function ObtenerConteo(); abstract function ObtenerNombre( $fila ); abstract function ObtenerValor( $fila ); } class TextoGrafico 115

{ private $data; private $dmin; private $dmax; public function TextoGrafico( $data ) { $this->data = $data; } protected function CalcularMinMax() { $this->dmin = 100000; $this->dmax = -100000; for( $r = 0; $r < $this->data->ObtenerConteo(); $r++ ) { $v = $this->data->ObtenerValor( $r ); if ( $v < $this->dmin ) { $this->dmin = $v; } if ( $v > $this->dmax ) { $this->dmax = $v; } } } public function desplegar() { $this->CalcularMinMax(); $ratio = 40 / ( $this->dmax - $this->dmin ); for( $r = 0; $r < $this->data->obtenerConteo(); $r++ ) { $n = $this->data->ObtenerNombre( $r ); $v = $this->data->ObtenerValor( $r ); 116

$s = ( $v - $this->dmin ) * $ratio; echo( sprintf( "%10s : ", $n ) ); for( $st = 0; $st < $s; $st++ ) { echo("*"); } echo( "\n" ); } } } class Registro { public $nombre; public $edad; public $salario; public function Registro( $nombre, $edad, $salario ) { $this->nombre = $nombre; $this->edad = $edad; $this->salario = $salario; } } class ListaRegistros { private $registros = array(); public function ListaRegistros() { $this->registros []= new Registro( "Jimmy", 23, 26000 ); $this-> registros []= new Registro ( "Betty", 24, 29000 ); 117

$this-> registros []= new Registro ( "Sally", 28, 42000 ); $this-> registros []= new Registro ( "Jerry", 28, 120000 ); $this-> registros []= new Registro ( "George", 43, 204000 ); } public function ObtenerRegistros() { return $this->registros; } } class AdaptadorRegistroGrafico extends OrigenDatosTextoGrafico { private $registros; public function AdaptadorRegistroGrafico( $rl ) { $this->registros = $rl->ObtenerRegistros(); } public function ObtenerConteo( ) { return count( $this->registros ); } public function ObtenerNombre( $fila ) { return $this->registros[ $fila ]->nombre; } public function ObtenerValor( $fila ) { 118

return $this->registros[ $fila ]->salario; } } $rl = new ListaRegistros(); $ga = new AdaptadorRegistroGrafico( $rl ); $tg = new TextoGrafico( $ga ); $tg->desplegar(); ?> 5.4.4 Explicacin del ejemplo La porcin superior del archivo es dedicado al grfico. Esta porcin define la clase abstracta OrigenDatosTextoGrafica as como tambin la clase TextoGrafica. TextoGrafica utiliza un OrigenDatosTextoGrafica para referenciar los datos. La seccin media define el Registro y la ListaRegistros, la cual guarda los datos a ser graficados. La tercera seccin define el AdaptadorRegistroGrafico, el cual adapta la ListaRegistros a un origen utilizable por la grfica. El cdigo al final primero hace una ListaRegistros y entonces hace el adaptador y el TextoGrafico, con una referencia al adaptador. La grfica despliega los datos al leer los datos del adaptador. Al correr al cdigo guardado como EjemploAdapter.php se obtiene el siguiente resultado: % php adapter.php Jimmy : 119

Betty : * Sally : **** Jerry : ********************** George : **************************************** El final de debajo de la escala es Jimmi, y el mximo el George. La grfica automticamente lo escala de tal manera que Jimmy es mostrado sin estrellas (mnimo), y George con 40 estrellas (el mximo). Ms importante, por supuesto, este cdigo manej la conversin de datos sin problema, y sin hacer desastres con el cdigo interno de la clase Registro. Se puede usar un adapter siempre que se tengan dos APIS que necesiten trabajar juntos, cambiar cualquiera de esos APIS no es una opcin. 5.5 Uso del patrn singleton En casi cada programa orientado a objetos, hay usualmente uno o dos recursos que son creados una vez y compartidos durante la aplicacin entera. Por ejemplo una conexin a base de datos en una aplicacin e-commerce es uno de tales recursos: es inicializada cuando la aplicacin se lanza, es utilizada para efectuar todas las transacciones y es finalmente desconectada y destruida cuando el programa termina. En el cdigo, no hay necesidad de llamar a una conexin de base de datos a cada momento; es fastidioso y muy ineficiente. En lugar de eso, el cdigo puede simplemente reutilizar la conexin que ya ha sido establecido. El reto entonces es cmo se refiere a la conexin (o a cualquier otro nico recurso perenne, tal como un archivo abierto o una cola). y donde

120

5.5.1 El problema Cmo se puede asegurar que una instancia de una clase particular es exclusiva (es siempre la sola instancia de esa clase) aunque tambin sea fcilmente accesible?. 5.5.2 La solucin Por supuesto, una variable global es una solucin obvia, pero tambin es una caja de pandora (el dicho el buen juicio viene de la experiencia, pero la experiencia usualmente viene de un pobre juicio viene a la mente). Cualquier porcin del cdigo puede modificar una variable global, causando sin fin de depuraciones que se agravan, cualquier cantidad de problemas inesperados. En otras palabras el estado de una variable global es siempre cuestionable. Cuando se necesita una instancia exclusiva de una clase particular, se usa el patrn acertadamente llamado singleton. Una clase basada en el patrn singleton instancia e inicializa apropiadamente una instancia de la clase y provee acceso al mismo objeto exacto, tpicamente a travs de un mtodo esttico. 5.5.3 Cdigo de ejemplo Un singleton, como se dijo antes, es un objeto que tiene solo una instancia a cualquier momento en el sistema. Un gran ejemplo de un potencial singleton es una manejador de base de datos. Para cada instancia del intrprete de PHP, debera haber solo un manejador de base de datos. Este ejemplo implemente tal como una configuracin, una versin de singleton de un manejador de base de datos.

121

Figura 22. El singleton de base de datos

Es bastante simple, el objeto contiene el manejador de base de datos y tiene dos mtodos. El primero es el constructor, el cual es privado para asegurarse que nadie afuera de clase pueda crear el objeto. Tambin contiene un mtodo esttico llamada obtenerManejador que retorna el manejador de base de datos. Cdigo: <?php require( 'DB.php' ); class Database { private $dbh; private function Database() { $dsn = 'mysql://root:password@localhost/test'; $this->dbh =& DB::Connect( $dsn, array() ); if (PEAR::isError($this->dbh)) { die($this->dbh->getMessage()); }

122

} public static function obtenerManejador() { static $db = null; if ( !isset($db) ) $db = new Database(); return $db->dbh; } } echo( Database::obtenerManejador ()."\n" ); echo( Database:: obtenerManejador ()."\n" ); echo( Database:: obtenerManejador ()."\n" ); ?> Este simple singleton tiene un constructor que entra en la base de datos y un mtodo esttico que accesa y crea un objeto si no ha sido creado ya retornando el manejador de base de datos de tal objeto. Si se usa este mtodo para obtener manejadores de base de datos, se puede descansar tranquilo asegurado que se conectar a la base de datos una sola vez por pgina que trae datos. Al correr el script en el navegador, se obtiene lo siguiente: Object id #2 Object id #2 Object id #2 Esto demuestra que las mltiples llamadas al mtodo esttico obtenerManejador() estn retornando el mismo objeto una y otra vez. Esto 123

significa que cada vez que la llamada fue hecha, el objeto Database, y por lo tanto el manejador de base de datos, fue utilizado. 5.5.4 Segundo ejemplo Manejadores de bases de datos son una cosa, pero, qu acerca de algo ms completo?. En este ejemplo se probar una lista compartida de estados, como se muestra en el siguiente cdigo: <?php class ListaEstados { private $estados = array(); private function ListaEstados() { } public function agregarEstado( $estado ) { $this-> estados[]= $estado; } public function obtenerEstados() { return $this-> estados; } public static function instance() { 124

static $estados = null; if ( !isset($estados) ) $estados = new ListaEstados(); return $estados; } } ListaEstados::instance()->agregarEstado( "Florida" ); var_dump( ListaEstados::instance()->obtenerEstados( ) ); ListaEstados::instance()->agregarEstado( "Kentucky" ); var_dump( ListaEstados::instance()->obtenerEstados( ) ); ?> 5.5.5 Explicacin del segundo ejemplo Este cdigo hace una clase singleton, ListaEstados, la cual contiene una lista de estados. Se pueden agregar estados a la lista, as como obtener un listado de los estados. Para acceder a la sola instancia compartida de este objeto, se tiene que usar el mtodo esttico instante() (en lugar de hacer una instancia directamente). Al correr el script en el navegador da el siguiente resultado: % php singleton2.php array(1) { [0]=> string(7) "Florida" } array(2) { [0]=> 125

string(7) "Florida" [1]=> string(8) "Kentucky" } El primer volcado de variable muestra que justamente el primer estado, Florida, est en la lista. El segundo volcado muestra la adicin de Kentucky al objeto compartido. Algunos autores son vacilantes a la hora de recomendar el patrn singleton demasiado por considerar est sobreutilizado, al observar cdigos que tienen unos rodeos bastante feos para lidiar con objetos singleton, lo cual refleja que el patrn singleton est siendo utilizado incorrectamente. Si se estn tomando pasos significativos para trabajar con un singleton, podra no ser un uso apropiado del patrn.

126

CONCLUSIONES
1. La identificacin, descripcin, recuperacin, adaptacin e integracin de activos de software son todos asuntos importantes. Lograr algn progreso en cualquiera de ellos ser un paso hacia la reutilizacin efectiva. 2. El rea completa de la reutilizacin de software es ms amplia: no slo abarca diseo, sino el ciclo de vida completo y no slo relaciona el diseo con la reutilizacin, sino tambin diseo para la reutilizacin. 3. El slo uso de tecnologas orientadas a objetos no darn una reutilizacin de software efectiva. Las tecnologas son slo una pequea parte de las prcticas de reutilizacin, y si se adoptan lenguajes de programacin orientados a objetos (ej. Java), sin implementar otros pasos involucrados en un programa de reutilizacin quedarn decepcionados. 4. Con catlogos de soluciones tpicas, metodologas estandarizadas, lenguajes, etc., se es testigo de una disciplina emergente de ingeniera; y los prospectos de esto son bastantes promisorios, a pesar de la longitud del camino que todava queda. 5. La situacin hoy en da con los patrones de diseo orientados a objetos es que ya existen catlogos. Usarlos y aplicarlos no parece ser una tarea fcil. Los patrones pueden ser difcilmente entendidos completamente en la primera lectura. Un diseador tendr que referirse a ellos una vez y otra vez.

127

6.

Ser capaz de aplicar un patrn exitosamente requiere conocimiento acerca del patrn, comprenderlo y examinarlo. Despus de eso, los patrones de diseo pueden ser aplicados repetidamente por analoga.

7.

Los recientes esfuerzos en torno a la reutilizacin deberan ser considerados pasos en la direccin correcta. Si la disciplina de desarrollo de software es para cambiar de arte a ingeniera, entonces la reutilizacin de software es definitivamente uno de los mayores factores influenciando el cambio.

128

RECOMENDACIONES

1. Proponer un formalismo para representacin de patrones de diseo, marcos de trabajo y arquitecturas de software que serviran primariamente para recuperarlos y aplicarlos en diseo de software. 2. Investigar y desarrollar herramientas que apoyaran al usuario en recuperar y aplicar patrones de diseo, marcos y arquitecturas de software en diseo de software. 3. En el caso de los patrones de diseo se recomienda adaptar el patrn de diseo al problema y no el problema al patrn de diseo. 4. Investigar las posibilidades de incorporar patrones de diseo, marcos de trabajo y arquitecturas de software dentro de un lenguaje de diseo/implementacin.

129

130

BIBLIOGRAFA
1. Buschmann Frank y otros. Pattern-Oriented Software Architecture: ASystem of Patterns. Wiley, 1996. 2. Clements Paul y Northrop Linda. Software Product Lines: Practices and Patterns. Addison-Wesley, 2002. 3. Gamma E. y otros. Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley,1995. 4. 5. Herrington Jack, PHP Hacks. O'Reilly, 2005. Jacobson Ivar, Griss Martin y Jonsson Patrik. Software Reuse: Architecture, Process and Organization for Business Success. AddisonWesley, 1997. 6. Sweat Jason E., php|architects Guide to PHP Design Patterns. Tabini & Associates, 2005. Marco

BIBLIOGRAFA ELECTRNICA

7.

Mller Hausi A.. Understanding software systems using reverse engineering technologies research and practice (tutorial). En la 18 Conferencia Internacional de Ingeniera de Software (ICSE-18), Berlin, Alemania, Marzo 1996. Disponible en : http://www.rigi.csc.uvic.ca/UVicRevTut/UVicRevTut.html.

131

8.

IEEE Computer Society. Software Reuse: A Standards Based Guide. Disponible en lnea en: http://www.computer.org/cspress/catalog/bp00874.htm

9.

Software

Engineering

Institute,

Carnegie-Mellon

University.

DomainEngineering: A Model-Based Approach, Enero 2000. Disponible en: http://www.sei.cmu.edu/domain-engineering/. 10. Software Engineering Institute, Carnegie-Mellon University. Domain Engineering and Domain Analysis, Septiembre 2000. Disponible en lnea en: http://www.sei.cmu.edu/str/descriptions/deda-body.html. 11. http://www.objectmentor.com/resources/publishedArticles.html

132