Universidad de Valladolid Arquitectura de software dinmica basada en reflexin Carlos Enrique Cuesta Quintero 2002

Tesis de Doctorado

Facultad: E. T. S. Informtica Director: Dr. Pablo de la Fuente Redondo UniversidaddeValladolidDepartamentodeInform atica(ATC,CCIA,LSI)ArquitecturadeSoftwareDin amicaBasadaenReexi onTesisDoctoralD.CarlosEnriqueCuestaQuinteroDirector:Dr. PablodelaFuenteRedondoJuliode2002A PilarAgradecimientosAunque es casi un t opico,no por ello es menos cierto que un trabajo de tesis implica siemprea muchsimas mas personas que su autor. En mi caso, puedo decir que el apoyo y conanza detodas esas personas ha resultado determinante para que esta tesis llegase a buen termino.Sonmuchaslascontribucionesqueherecibido, deunmodouotro; esimposiblerecordarahoratodasellas. Peroaunas, noquierodejardedarlasgraciasaalgunaspersonascuyaaportaci on ha sido para m especialmente importante:Ante todo, a Pablo, por su apoyo incondicional, su innita paciencia, su interes, su aperturade ideas, sus buenos consejos y su integridad y calidad como cientco y como persona. Tambien,porhabermedirigido hacia untemaque hallegado aapasionarme,yporconarenqueseracapaz de llevarlo a buen termino; ha sido para m un verdadero honor trabajar a su lado.AManolo, quesinpretenderlomehaimpulsadosiempreahacertodoaquelloqueyoenunprincipionocreaposible, yqueharesueltosiempremisdudasmasprofundas, amenudosimplementehaciendolapreguntaprecisaodiciendolapalabraadecuada. Tambien, porsusentido del humor, por su animo constante y por ser un magnco compa nero.A mis padres y hermanas, en especial, por su apoyo a lo largo de todos estos a nos, y a misdos familias, en general, por su paciencia, conanza y animo.A mis amigos, todos ellos, y en especial a Alberto, Blas, Carlos, Chema, David, Diego, Julio,Juan Carlos,Oscar, Rosa y Santiago, que han seguido ah, todo el tiempo, esperando a que yoterminase de una vez, siempre dispuestos a ofrecer su apoyo.A todos los miembros de los grupos de investigaci on Arco y Grinbd, delArea de Lenguajesy Sistemas Inform aticos, en especial, y del Departamento de Inform atica, en general, por todaslas veces que me han echado una mano, en especial en estos ultimos meses.Y, porsupuesto, aPilar, quehaestadosiempreami lado, dentroyfueradeestatesis,entodasycadaunadelasetapasymomentosdesudesarrollo. Sondemasiadaslascosasquetengoqueagradecerle, tantoenel planohumano, comoenel cientcoyacademico. Escompletamente cierto que no tengo palabras para darle las gracias; sin ella, simplemente, no lohubiera conseguido.A todos, de nuevo, gracias.vIndiceGeneralDedicatoria iiiAgradecimientos vI Introducci onyObjetivos 11 Introducci on 31.1 Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Estructura de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5II ArquitecturadeSoftwareDin amica 92 ArquitecturadeSoftware 112.1 Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.2 Denici on de Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . . . . 112.3 Relevancia de la Arquitectura de Software . . . . . . . . . . . . . . . . . . . . . . 132.4 Conceptos Fundamentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4.1 Lenguajes de Descripci on de Arquitectura. . . . . . . . . . . . . . . . . . 162.4.2 Componente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.3 Conector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.4 Puerto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.4.5 Estilo Arquitect onico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.6 Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5 Conclusi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 ArquitecturadeSoftwareDinamica 273.1 Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.2 Arquitectura de Software Din amica . . . . . . . . . . . . . . . . . . . . . . . . . . 283.3 Tipos de Dinamismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.4 Reconguraci on Din amica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.4.1 Tipos de Reconguraci on . . . . . . . . . . . . . . . . . . . . . . . . . . . 31vii3.4.2 Operaciones Basicas de Reconguraci on . . . . . . . . . . . . . . . . . . . 323.5 Clasicaci on: por Origen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.6 Sistemas Cl asicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.1 Conic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343.6.2 Durra . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353.7 Basados enAlgebras de Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.7.1 Wright Din amico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373.7.2 Darwin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393.7.3 Leda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.7.4 Derivados deAcme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44Armani . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45HotAcme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453.7.5 AML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.8 Basados en Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.8.1 Rapide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 483.8.2 C2 (C2sadel) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 503.9 Basados en Grafos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 533.9.1 Precedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Gram aticas-: Garp. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Teora Sint actica de Dean & Cordy . . . . . . . . . . . . . . . . . . . . . . 54Aproximaciones de Holt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.9.2 Gram aticas de Le Metayer . . . . . . . . . . . . . . . . . . . . . . . . . . . 543.9.3 Hipergrafos de Hirsch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56Modelo Inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57Modelo de Mosaicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 583.9.4 Modelo Categ orico de Wermelinger. . . . . . . . . . . . . . . . . . . . . . 603.10Modelos Qumicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.10.1 Precedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 623.10.2 DobleCham de Wermelinger . . . . . . . . . . . . . . . . . . . . . . . . . 633.11Coordinaci on Dirigida por Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . 643.11.1 El Modelo Linda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 653.11.2 Los Sistemas PoliS y MobiS. . . . . . . . . . . . . . . . . . . . . . . . . . 673.12Coordinaci on Dirigida por Control . . . . . . . . . . . . . . . . . . . . . . . . . . 683.12.1 El ModeloIwim: Manifold . . . . . . . . . . . . . . . . . . . . . . . . . . 683.13Otros Lenguajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.13.1 Logica de Reescritura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 703.13.2 El Modelo de Actores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 713.14Modelos de Dinamismo Arquitect onico. . . . . . . . . . . . . . . . . . . . . . . . 723.15Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75III Reexi on 774 ElConceptodeReexi on 794.1 Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 794.1.1 Denici on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804.2 El Problema de la Autorreferencia . . . . . . . . . . . . . . . . . . . . . . . . . . 814.2.1 Meta-Programaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844.3 Conceptos Fundamentales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.3.1 Hip otesis de Reexi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 864.3.2 Reicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 874.3.3 Arquitectura de Meta-Nivel . . . . . . . . . . . . . . . . . . . . . . . . . . 89Protocolo de Meta-Objeto. . . . . . . . . . . . . . . . . . . . . . . . . . . 904.3.4 Meta-Espacio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 914.4 Clasicaciones de la Reexi on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 924.4.1 Por Efecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 934.4.2 Por Tiempo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.5 Reexi on y Orientaci on al Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . 944.5.1 Modelos Reexivos de Objetos . . . . . . . . . . . . . . . . . . . . . . . . 954.6 Reexi on Aplicada: Envolventes y Aspectos . . . . . . . . . . . . . . . . . . . . . 974.7 Reexi on y Arquitectura de Software. . . . . . . . . . . . . . . . . . . . . . . . . 984.8 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103IV ArquitecturadeSoftwareDin amicamedianteReexi on 1055 ElModeloMarmol 1075.1 Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1075.2 Arquitectura de Software Din amica con Reexi on . . . . . . . . . . . . . . . . . . 1085.3 Marmol: Modelo Informal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1105.4 Sobre el Concepto de Nombre. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1125.5 Marmol: Modelo Formal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1145.5.1 Modelo Arquitect onico General () . . . . . . . . . . . . . . . . . . . . . 115Conceptos Basicos (Primitivos) . . . . . . . . . . . . . . . . . . . . . . . . 116Dimensi on Vertical: Composici on. . . . . . . . . . . . . . . . . . . . . . . 117Dimensi on Horizontal: Interacci on . . . . . . . . . . . . . . . . . . . . . . 124Sistema de Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1315.5.2 ModeloMarmol General (M) . . . . . . . . . . . . . . . . . . . . . . . . 1475.5.3 ModeloMarmol Restringido (). . . . . . . . . . . . . . . . . . . . . . 1625.6 Conclusi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1646 ElLenguajePiLar: Sintaxis 1676.1 Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1676.2 Visi on General del Lenguaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1696.2.1 El Concepto de Componente . . . . . . . . . . . . . . . . . . . . . . . . . 1706.3 Lenguaje Estructural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726.4 Declaraci on de Componente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1726.4.1 Declaraci on de Interfaz . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746.4.2 Declaraci on de Instancia. . . . . . . . . . . . . . . . . . . . . . . . . . . . 1756.4.3 Declaraci on de Conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . 1756.4.4 Reicaciones y Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . 1766.4.5 Estructuras Sint acticas Adicionales . . . . . . . . . . . . . . . . . . . . . . 177Alternativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Iteraci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177Parametrizaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178Recursi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1786.5 Reicaci on: Reexi on Arquitect onica. . . . . . . . . . . . . . . . . . . . . . . . . 1796.5.1 Anotaciones de Meta-Nivel . . . . . . . . . . . . . . . . . . . . . . . . . . 1816.6 Lenguaje Din amico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1836.6.1 Por que no calculo-? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1856.7 Estructura de una Restricci on. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1866.7.1 Canales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1866.7.2 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876.7.3 Procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1876.8 Constructores de Proceso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1886.8.1 Regla deAmbito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906.8.2 Replicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1906.9 Acciones Elementales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1916.10Comandos Reexivos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936.10.1 Operandos Reexivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946.10.2 Operadores Din amicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1966.10.3 Operadores Reexivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1976.11Conectores de Nivel Meta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1996.12Extensiones Especcas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2026.12.1 Soporte para Envolventes . . . . . . . . . . . . . . . . . . . . . . . . . . . 2036.13Conclusi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2067 ElLenguajePiLar: Sem antica 2097.1 Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2097.2 Sem antica Intuitiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2107.2.1 Concepto Sem antico Basico . . . . . . . . . . . . . . . . . . . . . . . . . . 2107.2.2 Discusi on: sobre las Sem anticas Algebraicas. . . . . . . . . . . . . . . . . 2117.2.3 Componentes como Procesos Abstractos. . . . . . . . . . . . . . . . . . . 2147.2.4 Conceptos Arquitect onicos dePiLar . . . . . . . . . . . . . . . . . . . . . 217Puertos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Conexiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2227.2.5 Intuici on para un Proceso Reexivo . . . . . . . . . . . . . . . . . . . . . 2237.3 Sem antica de los Aspectos Estructurales . . . . . . . . . . . . . . . . . . . . . . . 2367.3.1 Puerto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2367.3.2 Componentes (Instancias) . . . . . . . . . . . . . . . . . . . . . . . . . . . 2397.3.3 Reicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2447.3.4 Componentes en el Nivel Meta . . . . . . . . . . . . . . . . . . . . . . . . 2467.3.5 Conexi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254Conexi on Jer arquica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2597.3.6 Estructuras Sint acticas Adicionales . . . . . . . . . . . . . . . . . . . . . . 260Conjuntos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260Estructura Alternativa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Bucles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262Nota sobre Componentes Recursivos y Parametricos . . . . . . . . . . . . 2637.4 Sem antica de los Aspectos Din amicos . . . . . . . . . . . . . . . . . . . . . . . . 2647.4.1 Sobre la Notaci on Sem antica . . . . . . . . . . . . . . . . . . . . . . . . . 2657.4.2 Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Canales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2667.4.3 Procesos: Constructores . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Replicaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266Recursi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2687.4.4 Primitivas de Comunicaci on. . . . . . . . . . . . . . . . . . . . . . . . . . 2687.4.5 Primitivas Din amicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2707.4.6 Primitivas Reexivas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Operandos Reexivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273Operadores Reexivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2757.5 Extensi on: Envolventes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2797.5.1 Puerto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2797.6 Conclusi on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2818 ArquitecturaDinamicaenPiLar 2838.1 Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2838.2 Ejemplo de la Gasolinera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2848.2.1 Variante: una Gasolinera Din amica . . . . . . . . . . . . . . . . . . . . . . 2868.3 Un Sistema Cliente/Servidor [2[3]-tier . . . . . . . . . . . . . . . . . . . . . . . . 2888.4 Ejemplo de Los Fil osofos Evolutivos . . . . . . . . . . . . . . . . . . . . . . . . . 2908.5 El Modelo Linda: Espacios de Tuplas . . . . . . . . . . . . . . . . . . . . . . . . 2968.6 Sistema con Componentes Envolventes. . . . . . . . . . . . . . . . . . . . . . . . 2998.7 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303V Conclusiones 3059 ConclusionesyTrabajoFuturo 3079.1 Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3079.2 Lneas de Trabajo Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309Bibliografa 314VI Apendices 353AGram aticadePiLar 355BSintaxisdelC alculo- 363B.1 El Calculo- . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366CDialectodelC alculo- 371C.1 Versi on del Calculo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371C.2 Extensiones Gramaticales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374C.2.1 Estructura Alternativa. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375C.2.2 Composici on Secuencial . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375C.3 Tipos Basicos de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376C.3.1 Booleanos [Bool] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376C.3.2 Enteros [Int] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 377C.3.3 Cadenas [String] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378C.4 Tipos Abstractos de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379C.4.1 Tuplas y Vectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379C.4.2 Registros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380C.4.3 Pares . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382C.4.4 Listas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Listas Nombradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Notaci on Abreviada para Listas . . . . . . . . . . . . . . . . . . . . . . . . 389C.5 Notaci on de Tipos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392DDenicionesSem anticasAuxiliares 395D.1 Bucles: Iteradores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395D.1.1 Sobre Listas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396D.1.2 Sobre Listas Nombradas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397D.1.3 Sobre Rangos de Enteros . . . . . . . . . . . . . . . . . . . . . . . . . . . 397D.2 Concatenaci on de Listas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398D.3 Conversi on de Enumeraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398D.3.1 De Listas a Vectores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399D.3.2 De Vectores a Listas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399IndicedeTablas4.1 Metaprogramaci on: Clasicaci on de Rideau (adaptada) . . . . . . . . . . . . . . 856.1 Constructores Basicos (Algebraicos) . . . . . . . . . . . . . . . . . . . . . . . . . 1886.2 Constructores Avanzados (Algortmicos) . . . . . . . . . . . . . . . . . . . . . . . 1896.3 Acciones Elementales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1916.4 Operaciones sobre Conjuntos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1936.5 Operandos Reexivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1946.6 Operadores Din amicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1966.7 Operadores Reexivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1976.8 Soporte para Envolventes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204B.1 Gram atica del Calculo- Poli adico . . . . . . . . . . . . . . . . . . . . . . . . . . 368C.1 Operaciones de Listas: Denici on Abreviada. . . . . . . . . . . . . . . . . . . . . 390C.2 Operaciones de Listas Nombradas: Denici on Abreviada. . . . . . . . . . . . . . 391xiiiIndicedeFiguras2.1 Hitos en Arquitectura de Software (19892002) . . . . . . . . . . . . . . . . . . . 142.2 Taxonoma de Estilos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3 Evoluci on de Vistas en el Modelo 4+1 de Kruchten. . . . . . . . . . . . . . . . . 243.1 El cl asico Sistema de Monitorizaci on de Pacientes . . . . . . . . . . . . . . . . . . 353.2 Estructura b asica de un componente (tarea) en Durra . . . . . . . . . . . . . . . 363.3 Fragmento de un Congurorde Wright Din amico. . . . . . . . . . . . . . . . . . 383.4 Una Tubera Extensible enarwin . . . . . . . . . . . . . . . . . . . . . . . . . . 403.5 Establecimiento de un Enlacearwin en calculo- . . . . . . . . . . . . . . . . . 423.6 Un Sistema Cliente-Servidor con Equilibrio de Carga enLeda . . . . . . . . . . 433.7 Descripci on del Estilo C2 como un kind deAml . . . . . . . . . . . . . . . . . . . 473.8 El Problema de los Productores-Consumidores en Rapide . . . . . . . . . . . . . 493.9 Una conguraci on sencilla enC2sadel . . . . . . . . . . . . . . . . . . . . . . . 513.10Arquitectura Cliente-Servidor de Le Metayer . . . . . . . . . . . . . . . . . . . . 553.11Arquitectura Cliente-Servidor como Multiconjunto . . . . . . . . . . . . . . . . . 553.12Denici on del Coordinador para el Ejemplo Anterior . . . . . . . . . . . . . . . . 563.13Una Regla de Producci on de Grafos . . . . . . . . . . . . . . . . . . . . . . . . . 573.14Una Transformaci on en Notaci on- Doble . . . . . . . . . . . . . . . . . . . . . . 593.15Aplicaci on de una Producci on de Grafo sobreG . . . . . . . . . . . . . . . . . . . 603.16Un Conector Binario para ProgramasCommUnity . . . . . . . . . . . . . . . . 613.17Un Conector Binario entre los ComponentesP1 yP2. . . . . . . . . . . . . . . . 613.18Reconguraci on por Superposici on . . . . . . . . . . . . . . . . . . . . . . . . . . 613.19 Chams de Creaci on y de Evoluci on para el Estilo Clt/Srv/Mgr . . . . . . . . . . 643.20Descripci on de un Sistema Recongurable en Manifold. . . . . . . . . . . . . . . 693.21Modelos de Dinamismo enAdls . . . . . . . . . . . . . . . . . . . . . . . . . . . 723.22Congurador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.23Espacio Com un. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 733.24Control Externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.25Or aculo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 743.26Componente Mixto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 753.27Conector Mixto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 754.1 Modelo de Reexi on en Dos Niveles . . . . . . . . . . . . . . . . . . . . . . . . . 884.2 Tipos de Reexi on seg un el Efecto . . . . . . . . . . . . . . . . . . . . . . . . . . 93xvIndice de Figuras4.3 Modelos de Reexi on Orientada al Objeto. . . . . . . . . . . . . . . . . . . . . . 955.1 Correspondencia entre Arquetipos e Instancias . . . . . . . . . . . . . . . . . . . 1456.1 Esquema de un Componente en TiLar . . . . . . . . . . . . . . . . . . . . . . . . 1736.2 Filtro-Tubera: Iterativo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1776.3 Filtro-Tubera: Recursivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1776.4 Componente Innitamente Recursivo Ilegtimo . . . . . . . . . . . . . . . . . . 1786.5 Esquema de una Restricci on en TiLar . . . . . . . . . . . . . . . . . . . . . . . . 1867.1 Estructura Cu adruple de una Instancia Reicada . . . . . . . . . . . . . . . . . . 2297.2 Reicaciones de un Meta-Componente . . . . . . . . . . . . . . . . . . . . . . . . 2307.3 Reicaciones sobre un mismo Avatar . . . . . . . . . . . . . . . . . . . . . . . . . 2317.4 Reicaci on M ultiple para un Proceso con , = 2. . . . . . . . . . . . . . . . . . . 2337.5 Estructura Interna de un Puerto TiLar . . . . . . . . . . . . . . . . . . . . . . . 2377.6 Estructura Interna de un Componente TiLar . . . . . . . . . . . . . . . . . . . . 2407.7 Dualidad de un Componente Reexivo. . . . . . . . . . . . . . . . . . . . . . . . 2457.8 Estructura de un Meta-Componente . . . . . . . . . . . . . . . . . . . . . . . . . 2467.9 Dependencias entre Procesos sobre Componentes . . . . . . . . . . . . . . . . . . 2487.10Estructura Interna de una Conexi on TiLar . . . . . . . . . . . . . . . . . . . . . 2558.1 Sistema de la Gasolinera. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2848.2 La Gasolinera, versi on Din amica . . . . . . . . . . . . . . . . . . . . . . . . . . . 2878.3 Sistema Cliente/Servidor (2[3)-tier . . . . . . . . . . . . . . . . . . . . . . . . . . 2898.4 Denici on Inicial y Etapas Din amicas del Ejemplo . . . . . . . . . . . . . . . . . 2908.5 El Problema de los Fil osofos Comiendo: Enfoque Est atico . . . . . . . . . . . . . 2918.6 Los Fil osofos Apresurados: Enfoque Recursivo . . . . . . . . . . . . . . . . . . . 2928.7 Los Fil osofos Apresurados, versi on Evolutiva . . . . . . . . . . . . . . . . . . . . 2948.8 Los Fil osofos Apresurados, versi on Evolutiva (simplicada) . . . . . . . . . . . . 2958.9 Modelo de Espacio de Tuplas: una descripci on en TiLar. . . . . . . . . . . . . . 2978.10Representaci on Gr aca del Modelo de Espacio de Tuplas . . . . . . . . . . . . . . 2988.11Envolvente con Protocolo Explcito en TiLar . . . . . . . . . . . . . . . . . . . . 3008.12Envolvente con Protocolo Implcito en TiLar . . . . . . . . . . . . . . . . . . . . 3028.13Entradas Base Ligadas por Meta . . . . . . . . . . . . . . . . . . . . . . . . . . . 303A.1 Tabla de Equivalencias Lexicas en TiLar . . . . . . . . . . . . . . . . . . . . . . 361B.1 El Calculo- y los Calculos Nominales . . . . . . . . . . . . . . . . . . . . . . . . 365xviParteIIntroduccionyObjetivos1Captulo1Introduccion1.1 Introducci onLa complejidad y tama no de los sistemas software se ha incrementado de manera espectacularen los ultimos a nos. Su dise no y desarrollo ha pasado de una concepci on monoltica y uniforme auna visi on hetereogenea y distribuida. Esto ha puesto de maniesto la relevancia de un estudioespecco de la estructura del software, un aspecto que ha ido adquiriendo importancia de maneraprogresiva, y que ha dado lugar a la denici on de su propio campo de estudio.Se denomina Arquitectura de Software a la parte de la Ingeniera de Software que se dedica alestudio, an alisis y descripci on de esta estructura que recibe, tambien, el nombre de arquitecturade software. Se trata, en denitiva, de formalizar el esquema global de un sistema, poniendo elenfasis en el estudio de las interacciones entre sus elementos b asicos, denominados componentes.Todosistema, acualquiernivel degranularidad, puedeversecomounacomposici ondetaleselementos; por tanto, todo sistema tendr a una arquitectura.Tradicionalmente,elestudio delaarquitectura desoftwaresehacentradoensusaspectosest aticos, estoes, enladescripci onyan alisisdeestructurasinalterables. Sinembargo, exis-tensistemas, a unmascomplejos, enlosquelaestructuraevolucionaalolargodeltiempo, amenudo siguiendo patrones preestablecidos. Cuando estos patrones no son aleatorios, sino queest an predenidos, son una parte integral de la arquitectura, como lo son las propias relacionesestructurales. Se dice entonces que se tiene una arquitectura din amica.El estudiodearquitecturasdin amicasesunaspectoparticularmentecomplejo, yaquelaestructura suele ser, precisamente, el marco de referencia en el que se apoyan las descripciones dedinamismo. Esto ha hecho que se trate de un aspecto normalmente poco tratado; sin embargo,estonohadehacerpensarquesuimportanciaesmenor. Porel contrario, existeunbuenn umero de sistemas abiertos, distribuidos, adaptativos, evolutivos que no pueden ser descritosde manera adecuada sin una especicaci on din amica.Las distintas propuestas para la descripci on de Arquitectura de Software Din amica utilizanaproximacionesmuydiferentesalproblema. Aunquehayalgunosenfoquesquemuestranunaversatilidad notable, la mayora de ellos tienen una serie de limitaciones importantes, y en generalsolo han conseguido alcanzar su objetivo de manera parcial.En este trabajo se plantea si existe alg un concepto unicador, que permita plantear la des-31. Introducci oncripci on de dinamismo arquitect onico desde una perspectiva com un. De este modo, se podranreuniryrecogerlasaportacionesdelasdistintaspropuestasexistentes, integr andolasenunmodelouniforme. Espresumiblequeunmodelodeestetiposuperaralaslimitacionesdelosdistintos enfoques particulares, dando una mejor soluci on al problema.Enestatesissesugierequeeseconceptoexiste, yesel deReexi on. LaReexi onsede-necomolacapacidaddeunsistema(computacional)pararazonaryactuarsobresmismo,proporcionando una forma controlada de auto-modicaci on, basada en solidos fundamentos for-males. SehaaplicadoenunagranvariedadderamasdelaInform atica,desdelaInteligenciaArticial a los Sistemas Operativos, pasando especialmente por los Lenguajes de Programaci on.Sin embargo, apenas se ha utilizado en la Arquitectura de Software, que por tanto carece de unaperspectiva adecuada de esta noci on.Ysinembargo, unaarquitecturadin amicaes, por denici on, reexiva. Enefecto: unaarquitectura esuna descripci onde una estructura yaspectos de sucomportamiento,mientrasqueunaarquitecturadin amicaesaquellaquecambiayevoluciona, eincluyeunadescripci onde los patrones que dirigen este cambio. En denitiva, una parte de la estructura descrita est aindicando el modo en que cambia esta misma estructura: es decir, una arquitectura din amica semodica a s misma, y es por tanto reexiva.Noobstante,elconceptodereexi onesmasgenerico,ymaniestaunaestructurapropia,que puede ser a su vez formalizada. As pues, se plantea que la Arquitectura de Software puedeser ampliada con los conceptos adecuados, de modo que sea capaz de describir una estructurareexiva de manera organizada. Puesto que una arquitectura din amica es de hecho una estruc-turareexiva, seasumequeunmodeloarquitect onicoconreexi onseraunmarcoadecuadopara la descripci on de cualquier tipo de dinamismo.Lahip otesisdetrabajodeestatesises, portanto, quelaintroducci ondeReexi onenlaArquitectura de Software proporciona un marco unicado para la descripci on de Dinamismo. Lademostraci on de esta hip otesis constituye el objetivo global de esta tesis. Este ser a acometidomediante la consecuci on de una serie de objetivos parciales, que se enumeran a continuaci on.1.2 ObjetivosCon el n de mostrar que la introducci on de Reexi on en la Arquitectura de Software conduce aldinamismo, se desarrollar a un trabajo en cinco etapas, cuya estructura se describe a continuaci on:En primer lugar, se har a un estudio general del campo de la Arquitectura de Software Di-n amica. Esto incluye una denici on de sus conceptos fundamentales, as como una revisi ondetallada de los distintos enfoques existentes. A lo largo de este estudio se identicar an lasestructuras inherentes a dichos enfoques, que son las que conducen a la descripci on de di-namismo. De este modo, se obtendr a una denici on de los distintos modelos de dinamismoexistentes, independiente de las aproximaciones parciales utilizadas.Ensegundolugar, sehar aunarevisi ongeneral delasnocionesestructurales implicadasenel conceptodeReexi on. Seextraer an, deentreestas, aquellas queseconsiderenrelevantes en el contexto de la Arquitectura de Software, teniendo en cuenta los resultadosdel punto anterior. La introducci on de estas nociones en un esquema general permitir a la41. Introducci onelaboraci on de un modelo arquitect onico reexivo, denominado Marmol, que se construir acon independencia de cualquier lenguaje o modelo existente, con el n de ser totalmentegeneral. De este modo, las conclusiones de este punto podran ser posteriormente aplicadasa cualquier Adl particular, con independencia de las conclusiones del resto de este trabajo.El modelo ser a denido en terminos de teora de conjuntos y de relaciones; de este modoselograr ahacerunadescripci onpuramenteestructural, elaboradasobreunformalismototalmente independiente de cualquier enfoque particular.Entercerlugar, sehadeconsiderarqueel modeloanteriorsoloproporcionalainfraes-tructurapara una descripci on, pero de hecho no permite realizarla. Para llegar hasta esepunto, es necesario aplicar el modelo sobre un lenguaje concreto. En lugar de utilizar unlenguajepreexistente, queyatuvieraunaorientaci onparticular, sehapreferidoutilizarunlenguajenuevo, especcamentedise nadocomounAdlreexivo, al quesehadadoelnombrede TiLar. Laconjunci ondeestelenguajeyelmodeloanteriorproporcionanya un marco reexivo para la descripci on arquitect onica, en el que basar el estudio de lahip otesisdepartida. Noobstante, estelenguajeser adise nadodesdeunpuntodevistagenerico, ampliando de este modo su aplicabilidad.Encuartolugar, sehadeacometerunaformalizaci oncompletadel lenguajedise nado.Esto cumple dos funciones principales: en primer lugar,da una denici on precisa de susnociones, estructurasb asicaseinstrucciones, conloqueel lenguajequedadescritosinninguna ambig uedad. En segundo lugar,se demuestra que el lenguaje no solo puede serconcebido, sinoquepuedeserdehechollevadoalapr actica, eimplementadosobreuncontexto no reexivo. El sistema formal elegido para su formalizaci on ha sido el calculo-tipado polim orco, convenientemente adaptado al contexto de uso. Sobre este calculo, sepretende obtener un correlato formal de cada una de las nociones utilizadas en el dise nodel lenguaje, comprobando adem as que en efecto se ha elaborado un sistema reexivo, encuyo interior se puede realizar la descripci on de dinamismo.Finalmente, secomprobar alaaplicabilidaddel sistemaelaborado, estoes, lacapacidadde TiLar paraacometerladescripci ondearquitecturasdesoftware, yenparticularladearquitecturasdin amicas. Deestemodoseobtendr aunaperspectivadelaverdaderautilidad del esquema modelo, lenguaje y semantica, que permita, en terminos generales,determinar la bondad de la hip otesis de partida.En este punto, se habr a demostrado, al menos, que un enfoque reexivo de la Arquitectura deSoftware proporciona un entorno apto para la descripci on de dinamismo, y que la construcci ony utilizaci on de dicho entorno es en efecto posible.1.3 EstructuradelaTesisEstetrabajodetesisseestructuraennuevecaptulos, agrupadosencincopartes, ycuatroapendices. El esquema se organiza de modo que se parte de los aspectos mas genericos, y se vanconcretando poco a poco los mas especcos.51. Introducci onLa primera parte, Introducci on, consta unicamente de un captulo, este mismo. En el se intro-duce brevemente el contexto general de esta tesis, centr andolo en el problema de la descripci ondearquitectura din amica,ysugiriendo lahip otesisdequeesteproblema puede seracometidomediante la introducci on de nociones reexivas.La segunda parte, ArquitecturadeSoftwareDin amica, consta de dos captulos. El primerode ellos es una introducci on parcial a la Arquitectura de Software, cuyo objetivo es proporcionaruncontextoadecuadoparael restodelaexposici on. Deestemodo, sedeneel campoyseresalta su importancia, para luego centrarse en sus aspectos descriptivos. Por n, se revisan concierto detalle sus conceptos fundamentales; la mayora de ellos ser an utilizados con frecuencia alo largo de los captulos restantes.El captulo tres se centra ya especcamente en la cuesti on de la descripci on de dinamismoen la Arquitectura de Software. Consiste, en realidad, en una revisi on global de este aspecto laArquitecturaDin amica, quenosolosit uaaestetrabajoenuncontexto, sinoqueresultadeinteres en s mismo. Se considera el problema, se justica su interes, y se pone en relaci on conel termino vinculado de Reconguraci on Din amica, que dene un contexto a partir del cual seenumeranlasoperacionesfundamentalesdeldinamismo. Sepasaentoncesahacerunestudiodetallado de los distintos lenguajes y enfoques utilizados en la literatura para la descripci on dearquitecturasdin amicas. Enunaprimeraetapa, estosenfoquesseclasicanseg unsuorigenconceptual; posteriormente, se identican siete modelos b asicos de dinamismo arquitect onico, yse los relaciona con los lenguaje examinados con anterioridad.La tercera parte, Reexi on, consta unicamente de un captulo, el cuarto. Su objetivo es tansolodarunabreveperspectivaglobaldelconceptodeReexi onysusderivados, conelndeestablecerunabaseadecuadadelaqueluegoextraerlasnocionesqueser anintegradasenuncontexto arquitect onico. Tras considerar brevemente el problema general de la autorreferencia,ycontrastar sus diferencias conel conceptodemeta-programaci on, sepasanadetallar susprincipales nociones derivadas, en particular la de reicaci on. Se hace tambien especial enfasisenlosdistintostiposdeReexi on, ysedescribeel modelodecapasdecebolla, unodesususos mas importantes. Finalmente, se examinan las combinaciones existentes entre Reexi on yArquitectura de Software, de nuevo con el n de situar a este trabajo en contexto.Lacuartaparte, ArquitecturaDin amicamedianteReexi on, constadecuatrocaptulos, yconstituye el verdadero n ucleo de este trabajo. En el captulo quinto se justica la aproximaci onreexiva a la descripci on de arquitecturas din amicas mediante una comparaci on con los modelosidenticadosenelcaptulotres. Apartirde esta, seidenticanlasnocionesreexivasqueseconsiderandeutilidadenel contextodelaArquitecturadeSoftware, yseelaboraconellasunmodelodedescripci onarquitect onicadenominadoglobalmenteMarmol. De estesehaceprimero una exposici on informal, que se completa despues con una denici on formal, hecha enterminos de teora de conjuntos y relaciones.Esta se divide en tres etapas: en la primera ()se hace una denici on de los conceptos b asicos de la Arquitectura de Software en terminos derelaciones. Enlasegunda(M), seintroducenlasnocionesreexivas, integr andolasconlasanteriores. Finalmente, en la tercera () se realiza un colapso entre las relaciones de reicaci ony tipado, con el n de simplicar la especicaci on de reexi on estructural.En el sexto captulo se toman los conceptos b asicos deMarmol desde una perspectiva lin-g ustica,con el n de mostrar su verdadero impacto en la descripci on arquitect onica. De estemodo se elabora el lenguaje TiLar, concebido especcamente como unAdl reexivo, pero de61. Introducci onprop osito general. El captulo se dedica esencialmente a describir su sintaxis, identicando losdossublenguajesdelosquesecomponeEstructuralyDin amico, ascomocadaunadesusestructuras de control. Se hace especial hincapie en la visi on ling ustica del concepto de reica-ci on, y se justica el enfoque algebraico utilizado en la elaboraci on del Lenguaje Din amico. Unavez descrito el lenguaje b asico, se discute en detalle el modo en que la reicaci on de conexionesdalugaralaconcepci ondeconectoresdenivel meta. Finalmente, sedescribeunaextensi onespecca del lenguaje que proporciona un soporte para la denici on de envolventes.Enel septimocaptulo, seproporcionaunasemanticaformal para TiLar enterminosdeuna variante del calculo-. Se justica la elecci on de este calculo,y se esbozan algunas de lasconsecuencias que tendr a el enfoque reexivo sobre este. Tras una discusi on sobre los problemasderivados de la denici on de otros Adls algebraicos, se justica el nivel de abstracci on utilizado,ysepasaadescribircondetallelaestructuraqueadquierenlasnocionesdel lenguajedesdeunaperspectivasemantica; enparticular, el complejoesquemaderivadodeladenici ondeprocesos reexivos. A partir de aqu, se denen formalmente todos los conceptos del LenguajeEstructural ytodosloscomandosdel LenguajeDin amico, dandounatraducci oncompletayconsistente de TiLar, que demuestra su viabilidad.Enel captulooctavoseexaminan, alaluzdetodoloanterior, unaseriedeejemplosdeaplicaci onde TiLar, conel dobleobjetivodemostrar el modoenquepuedeser usado, ydemostrar su potencia y versatilidad. Tras un ejemplo inicial anecd otico,que hace patente susimplicidad en condiciones normales, se examinan una serie de casos particularmente interesanteso conictivos.Finalmente, la quinta parte, Conclusiones, consta de un unico captulo, el noveno. En estese recogen las conclusiones del trabajo realizado, y se sugieren varias lneas de trabajo futuro, atraves de las cuales se podran aclarar algunos de los aspectos menos tratados de esta tesis, ascomo ampliar en gran medida su posible campo de aplicaci on.Todos los captulos est an fuertemente interrelacionados, y dan en conjunto una visi on com-pletadel campo, ydel enfoqueutilizado. Aunquelaaportaci onesencial deestetrabajodetesisseconcentraenlapartecuartayespecialmenteenloscaptuloscinco, seisysiete, elrazonamiento global se extiende y justica en la totalidad del mismo.Por su parte, los cuatro Apendices se ocupan de una serie de aspectos particulares relacio-nados con puntos concretos de este trabajo de tesis, cuyo tratamiento detallado en un contextoparticular hubiera resultado excesivo.El Apendice A incluye una especicaci on completa de la gram atica formal del lenguaje TiLarennotaci onEbnf, quecomplementaaladenici oninformal del Captulo6. Secomentanbrevemente algunos aspectos de la misma, incluyendo ciertos detalles de la fase lexica.El Apendice B hace una introducci on somera a los conceptos b asicos de un c alculo nominal,centr andose de manera clara en el calculo-, principal formalismo utilizado en este trabajo, quees tambien el mas importante de todos ellos. Se proporciona tambien una breve descripci on desu sintaxis, as como una semantica intuitiva.El ApendiceCdescribeel dialectoconcretodel calculo-tipadoqueseutilizaenlasde-niciones formales del Captulo7, al quesedenominaabreviadamentecalculo- . Setrata,especcamente, de una variante poli adica, sncrona, de primer orden, tipada, polim orca y noextendida, inspiradadirectamenteenel calculo-polim orcodeTurner[Tur96]. A estesele71. Introducci ona nade, adem as, un soporte b asico para tipos de datos primitivos y una sintaxis especca parapares, registros y listas, as como un tipo din amico (Dyn).Finalmente, el ApendiceDdescribeunaseriededenicionesauxiliares, desarrolladasenterminosdel calculo- , quecompletanalgunasdelasdenicionessemanticasdel Captulo7.Seconsidera quenotienen entidad sucienteparaserdescritas comoparte dellenguaje,peroalgunas de ellas ser an, no obstante, muy habituales.8ParteIIArquitecturadeSoftwareDinamica9Captulo2ArquitecturadeSoftware2.1 Introducci onLa Arquitectura de Software es la parte de la Ingeniera de Software que se ocupa de la descripci onyeltratamientodelaestructura deunsistemacomounaseriedecomponentes,conelndeorganizar adecuadamente los distintos subsistemas, y permitir la integraci on de diferentes gruposde desarrollo en el mismo proyecto. Habitualmente se la vincula con la fase de Dise no, aunqueestedetallenoesestrictamentenecesario[MT98]; suprincipalobjetivoeshacer enfasisenlaimportanciadeladescripci onestructural delossistemassoftware, unaspectobienconocidopero habitualmente poco tratado.Inclusohoy, conladisciplinarelativamenteestablecidaperoa unjoven, noesposibledaruna denici on o descripci on de Arquitectura de Software que resulte completa, o cuando menossucientementeintegradora. Hay, noobstante, uncorpusconceptualcom un, entornoalcualexiste cierto grado de consenso. Por ello,lo que se hace en este Captulo es proporcionar unabreveintroducci onalosconceptosfundamentalesdel campo, centradaexclusivamenteenlosaspectos ling usticosde la Descripci on Arquitect onica.Este Captulo, por tanto, no pretende ser una revisi on del campo, ni dar un resumen adecuadode las distintas aproximaciones que lo componen; este aspecto es ya cubierto, por otra parte, poruna serie de artculos generales sobre el tema [Per97, Sar97, Gar00, MT00, Sha01], as como porla creciente bibliografa disponible [SG96, BCK98, HNS00, JRvdL00, MM00, Bos00]. Su unicoobjetivoesproporcionarunamnimabaseconceptual, as comounanomenclaturaunicada,que sirva de apoyo al resto de esta tesis. As pues, en las secciones siguientes unicamente se har auna denici ongeneral delcampo,sese nalar asurelevancia,ysedesarrollar anbrevementesusnociones principales. Se dar a entonces por concluido este Captulo, para entrar ya a considerarel problema especco tratado en esta tesis, esto es, la descripci on de dinamismo (3).2.2 Denici ondeArquitecturadeSoftwareEl signicadointuitivodelaexpresi onArquitecturadeSoftwareresulta, engeneral, bastanteclaro. Tal vez por ello, no existe una denici on unica y aceptada de la misma; distintos autoresutilizandistintasdeniciones,seg unel enfasisquequieranhacerendistintospuntos. Esmuy112. ArquitecturadeSoftwarehabitual,dehecho,citarvariasdeellasdemanerasimult anea,conelndeproporcionarunavisi on de conjunto. En la misma lnea, en esta secci on se mencionan las dos probablemente mascompletas, y luego se discuten brevemente otras aproximaciones.La denici on siguiente tiene la ventaja de ser breve y concisa, y es sin lugar a dudas la masutilizada en la literatura:Laarquitecturadesoftware est a compuesta por la estructura de los componentesde un programa o sistema, sus interrelaciones, y los principios y reglas que gobiernansu dise no y evoluci on a lo largo del tiempo.David Garlan y Dewayne Perry [GP95]Aunqueesincompleta, pocoexplcitayenparteambigua, resultaserunadenici ongeneral,abierta, noexcluyente, ampliayexible. Tambienesunicadora, enel sentidoqueesv alidatantoparalavisi ondescriptivarepresentadaporGarlancomoparalavisi ondeprocesorepresentadaporPerry. Enconclusi on, eshabitualmenteaceptadacomounmnimocom undenominador. De hecho, la denici on proporcionada en la Pr actica Recomendada sobre Arqui-tectura de Software de la IEEE [AWG99] no es sino una versi on mas imprecisa de esta.La denici on siguiente fue propuesta con anterioridad, y resulta mucho mas detallada, aunqueno es, en sentido estricto, una denici on de arquitectura de software, sino una justicaci on delenfoque, que incluye la formulaci on de sus objetivos:M as all adelos algoritmos yestructuras dedatos delacomputaci on, el dise noy especicaci on de la estructura global del sistemaemergecomounnuevotipodeproblema. Losdetallesestructuralesincluyenlaorganizaci ongeneral ylaestructura de control global; los protocolos de comunicaci on, sincronizaci on y accesoadatos; laasignaci ondefuncionalidadaloselementosdedise no; ladistribuci onfsica;lacomposici ondeloselementosdedise no;suescalabilidadylosaspectosderendimiento; y la selecci on entre alternativas de dise no.David Garlan y Mary Shaw [GS93]Lociertoesqueestaenumeraci ondelimitaadecuadamentelosaspectosdeinteresdeunadescripci on arquitect onica. Sin embargo, no ha de ser considerada en un sentido estricto, ya quemuchos de ellos solo han sido considerados de manera parcial en los desarrollos existentes.En resumen, siempre que se dene Arquitectura de Software se tiende a identicar la noci on deestructura, reriendose tanto a su concepci on como a su especicaci on. Sin embargo, la expresi onno es utilizada unicamente en ese sentido, sino que a medida que se desarrolla el campo se hanpodido identicar al menos cuatro signicados diferentes, todos ellos interrelacionados, a saber:ArquitecturacomoProducto.Esteesel signicadoporexcelencia, yal quesereerenlasdenicionesproporcionadas. Enestesentido, laarquitecturaesel conjuntoformadopor la organizaci on, la estructura y la infraestructura de un sistema software. Desde estaperspectiva, interesa ante todo su descripci on, evaluaci on y an alisis.ArquitecturacomoProceso. Habitualmenteseconsideraqueelprocesoarquitect onicoseconstituye como el principal interes del campo. En este sentido, se hace referencia tanto122. ArquitecturadeSoftwareal metodo a seguir para deducir la arquitectura de un sistema, existente o no, como a laelaboraci on de una metodologa de desarrollo que considere explcitamente el impacto dela arquitectura de software [Kru95].ArquitecturacomoCampodeEstudio. Enlos ultimosa nos, el estudiodelaestructuradel softwarehallegadoaseruninteresens mismo, hastael puntodequecomienzaaaparecercomounadisciplinapropia. Enestesentido, sedebenconsiderartantolosestudios especcos existentes, como toda una serie de aspectos fuertemente relacionados,queabarcandesdelosmetodosformales, constituidosenherramientab asica, hastalospatrones de dise no, cuyo objetivo, origen e inspiraci on es similar.ArquitecturacomoProfesi on. Aunque este ultimo aspecto es muy discutible, lo cierto esque con cierta frecuencia comienza a aparecer la gura del arquitecto de software, denidocomo el rol encargado de dise nar y mantener la descripci on de la arquitectura, por lo queimplcitamenteesel queproporcionalavisi onintegral del producto. Seestablece, portanto, como una gura clave en el proceso de desarrollo.Enestatesis,elterminoseconsiderafundamentalmenteenelprimersentido,ydentrodeestesehaceespecial enfasisenlosaspectosdedescripci on, particularmentedesdeunpuntodevistaling ustico. Estaelecci onvienedeterminadaporlaconvicci ondequesolocuandosealcance un nivel de descripci on lo sucientemente preciso, se podr an concretar los objetivos dela Arquitectura de Software. De otro modo, el an alisis requerido no es posible, y la informaci onobtenida durante el proceso se pierde en gran medida.2.3 RelevanciadelaArquitecturadeSoftwareAlgunos autores, y en particular Mary Shaw [Sha80, Sha90], consideran que el actual enfasis enArquitectura de Software es una consecuencia l ogica de la evoluci on en el desarrollo de sistemassoftware, que siempre ha tendido a elevar el nivel de abstracci on utilizado. Shaw identica ciclosdeaproximadamentedieza nos, enlosqueel conceptob asicodel campohaidocambiando,adquiriendo una forma progresivamente mas abstracta: de la instrucci on a la funci on, luego almodulo,ypornalobjeto. Enestavisi on,lafaseactualsecorrespondeprecisamenteconlaArquitectura de Software, y su noci on fundamental es la de componente arquitect onico (2.4.2).Es obvio, por otra parte, que en los ultimos a nos la importancia del campo y su difusi on hancrecidodemaneraconsiderable. EnlaFigura2.1delap agina14puedeverseunacronologaaproximada de los principales hitos del campo, as como de los grandes proyectos nanciadosque han inuido de manera decisiva en su evoluci on.Elpuntodepartidaelegidoparaestacronologahasido1989, fechaenlaquecomenz oadifundirseel artculoseminal deDewaynePerryyAlexanderWolf, posteriormentepublicadocomo[PW92], yquesueleconsiderarsecomoel principiodel actual augeenArquitecturadeSoftware. No obstante, pueden citarse precedentes mucho mas antiguos: de hecho, en ocasionesalgunosautoressehanremontadohastalostrabajosinicialesdeDavidParnas[Par72] sobreencapsulamiento, aunque probablemente esto sea excesivo.En la Figura puede verse con claridad como la actividad en el campo ha crecido de maneraconsiderable alolargodela ultima decada,alcanzandosumaximaexpresi onenelcambiode132. ArquitecturadeSoftwareESPRIT CABERNET21987DARPA Arcadia1984ESPRIT CABERNET1Perry & Wolf1989Garlan & ShawIMSA93ISOTAS93IWSSD7(Booch93)1993Tesis: JustoISAW2ARESI(UML)IMSA96Tesis: AbdAllahTesis: DellarocasLibro: Shaw & Garlan Radicals3RMODPEDCS (Lake Placid)COORDINATION96Libro: GoV POSARadicals1Tesis: CheungTesis: HofmeisterGarlan & PerryShaw: Conector(16)ICSE94(OMT)(OOSE)IMSA91Libro: Jazayeri et alCOORDINATION00TOG/MCC ADML v1IEEE RP1471WWISA SAJ v0Libro: Schmidt POSAGarlan: RoadmapARESIIISA2000(22)ICSE00ISAW4SPLC1Tesis: PryceTesis: HoekTesis: CanalTesis: UngureanuPH SA SeriesLibro: MowbrayLibro: PutmanLibro: BoschCOORDINATION97Perry: ICSE97ESEC/FSE97Tesis: AllenTesis: FossaTesis: CraneRadicals4IMSA97WICSA02COORDINATION02SA2002GigaWorld IT 2002SPLC2(24)ICSE02Libro: Clements et alFOCLASA02ACM/IFIP CD2002Tesis: GacekTesis: Carzaniga(Libro: Szyperski)Libro: Bass et al.UMLROOMARESIINOSA98WCSAISAW3Radicals5Shaw: ProspectsTesis: DulayTesis: LaneWDSSAISAW1 (IWASS)IEEE TSE 21(4)(Libro: GoF)Radicals2IMSA95Dagstuhl WorkshopIEEE APG/AWGKruchten "4+1"ESPRIT COORDINAESPRIT ITHACAFNRS CAOFNRS ISCFMITI MSAESPRIT C3DSESPRIT REXESPRIT ARESEEF Summer School (Turku)Libro: Aksit SACTWICSA01SA2001Shaw: ICSE01Libro: SewellLibro: DikelWWISA SABoK CharterPerry & WolfIMSA92Tesis: EndlerTesis: K. NgCMU CS"AoSS"(21)ICSE99NOSA99WWISACatalysisKruchten: RUPCOORDINATION99ECOOP99WPLALibro: DonohoeLibro: Hofmeister et al.Tesis: EgyedTesis: DeLineTesis: AstleyTesis: PaulaTesis: SchneiderTesis: VallecilloTesis: GiannakopoulouTesis: MoazamiGoudarziTesis: WermelingerTesis: MedvidovicWICSA1IFIP WG 2.10ECOOP99OOAEUSC CS612USAF/DARPA STARSDARPA EDCS2004199920001998200120021995199419961992199119971990Figura 2.1: La Arquitectura de Software en el Tiempo: Hitos y Proyectos142. ArquitecturadeSoftwaremilenio. No debe pensarse, sin embargo, que este impulso ha remitido en los ultimos dos a nos;muy por el contrario, lo que ocurre es que la Arquitectura de Software se ha integrado plenamenteenlaIngenieradeSoftware, yqueapenasexisteforogeneral enel quenosehayanincluidotrabajos relacionados con el campo. El mejor ejemplo es la propia Conferencia Internacional deIngenieradeSoftware(Icse), quehatratadoel temadeunamaneraespecial enlos ultimoscuatroa nos. Por otraparte, laconsolidaci ondeunaconferenciaespecca, laConferenciaIFIP sobre Arquitectura de Software (Wicsa) hace cada vez menos necesaria la dispersi on enreuniones de menor envergadura.Conviene resaltar el papel de los proyectos nanciados, en particular en los Estados Unidos,donde el maximo impulsor ha sido sin duda la investigaci on militar. El proyecto Stars (SoftwareTechnology for Adaptable, Reliable Systems), tal vez uno de los que mayor inuencia ha tenidoen la Ingeniera de Software en general, fue tambien el que introdujo el concepto de arquitecturadesoftware, ylacausaoriginal del interesdelaindustriaenel mismo. Unaveznalizadoeste, sus conclusiones dieron lugar a otro proyecto, el Programa EDCS (Evolutionary Design ofComplex Systems), especcamente centrado en el concepto de arquitectura, y en el que participaunenormen umerodeempresasyuniversidades. Suobjetivoesplantearunanuevavisi ondelossistemassoftwarecomplejoscomoentidadessometidasacontinuoscambios; elpapeldelaarquitectura en este contexto es el de servir como elemento unicador.La Arquitectura de Software tambien ha conocido una aceptaci on plena,tanto en el planocientco como en el industrial. La IEEE inici o en 1995 un proceso de estandarizaci on [EHIP+96]de las ideas del campo, que cristalizaron en 2000 con la elaboraci on de la Pr actica RecomendadaRP-1471[AWG99]. Porotraparte, el OpenGrouphapublicadolaprimeraversi ondeunanorma para la descripci on arquitect onica, denominadaAdml, con base en XML. No obstante,el detalle mas signicativo es sin duda la constituci on de un grupo de trabajo especco dentrode la IFIP, concretamente el WG 2.10, que reune a algunas de las guras mas importantes delcampo, tanto del mundo academico como del industrial.No se ha de dejar de mencionar, siquiera desde un punto de vista anecd otico, la fundaci ondel InstitutoMundial deArquitectosdeSoftware(Wwisa)[Sew00], quepretendeconsolidarla visi on de la Arquitectura de Software como profesi on, y en el que participan tambien cierton umero de personalidades vinculadas al Dise no de Software, tales como Grady Booch, PhilippeKruchten, Tom Mowbray, Ian Graham o Terry Winograd.2.4 ConceptosFundamentalesAlolargodeestasecci on, serevisar anlosconceptosfundamentalesdel campo, conel ndeproporcionar unavisi ondeconjuntorazonable, quesirvacomounabaseadecuadaparalacomprensi on de los captulos posteriores.Comoyasehadicho, estarevisi onsecentra unicamenteenlos aspectos dedescripci onarquitect onica, por lo que el principal interes es el estudio de los distintos lenguajes utilizadosparaesteprop osito, conocidoscomoLenguajesdeDescripci ondeArquitecturaoAdls. Lascaractersticas que los denen son tambien brevemente discutidas en este apartado.Desdeel puntodevistaling ustico, unaarquitecturadesoftwarevienedeterminadaporlos componenteselementos b asicos caracterizados por una interfazsegmentada en puertos y152. ArquitecturadeSoftwareconectoresquelaconstituyen,ascomoporunaseriedeconexionesoenlacesespeccos,quedenen la uni on de todos ellos formando una estructura. A esta estructura se le da el nombredeconguraci on, ysueleconsiderarseinsertadaenunajerarqua, independientementedesugranularidad. Ocasionalmente,la conguraci on no se describe de manera monoltica,sino quese estructura en diferentes vistas,cada una de las cuales se concentra en un aspecto diferente.Cuando lo que interesa no es obtener una conguraci on concreta, sino los patrones genericos quedenen a una familia de sistemas,se habla de estilosarquitect onicos[CFBS98]. En denitiva,es la denici on de todos estos aspectos la que determina una visi on concreta de la Arquitecturade Software; a este n se dedicar an los apartados siguientes.2.4.1 LenguajesdeDescripci ondeArquitecturaSe dene un Lenguaje de Descripci on de Arquitectura (Architecture Description Language, o Adl)como una notaci on que permite una descripci on y an alisis preciso de las propiedades observablesdeunaarquitecturadesoftware, dandosoporteadistintosestilosarquitect onicosadiferentesniveles de abstracci on [Sch99].Lanecesidaddeutilizarunanotaci onespeccaparalaespecicaci onarquitect onica, quepermita separar con claridad los aspectos vinculados a la estructura del resto de los detalles deldesarrollo, ha sido identicada casi desde el principio. Esto no signica, no obstante, que todolenguaje que haga una descripci on especca de la estructura sea propiamente unAdl. En lasetapasinicialesdedesarrollodelcampo, hanrecibidoestadenominaci on[Cle96]todotipodelenguajes,desde sistemas puramente formales,hasta lenguajes de especicaci on algebraica,deprogramaci on concurrente o de denici on de interfaces. En particular, ha resultado confusa surelaci on con otros lenguajes especcos de dominio, como los Lenguajes de Conguraci on y deInterconexi on de M odulos (Mils), algunos de los cuales han evolucionado posteriormente hastallegar a ser autenticosAdls (3.7.2).Conelndeclaricar lasituaci on,ShawyGarlan [SG94]enunciaron lasseispropiedadesque, seg un su punto de vista, debe tener todoAdl:Composici on. El lenguaje debe ser tal que el arquitecto podr a dividir un sistema com-plejo en partes mas peque nas, de manera jer arquica, o construir un sistema a partir de loselementos que lo constituyen.Abstracci on. La arquitectura expresa una abstracci on que permite identicar a los dis-tintoselementosenunaestructuradealtonivel, as comosupapel enlamisma. Estaabstracci on es especca, y se diferencia de otras utilizadas en el desarrollo.Reutilizaci on. Un objetivo fundamental de la especicaci on arquitect onica es hacer po-sible la reutilizaci on posterior de componentes, conectores, estilos y arquitecturas, inclusoen un contexto diferente a aquel en el que fueron denidos.Conguraci on.El lenguaje debe separar con claridad la descripci on de elementos indivi-duales y de la de las estructuras elementos compuestos en las que estos participen. ParaMedvidovic [MT00], esta es la caracterstica fundamental que distingue a unAdl.162. ArquitecturadeSoftwareHetereogeneidad. El Adlhadeserindependientedellenguajeenqueseimplementecada uno de los componentes que manipula; y debe dise narse de modo que pueda combinarpatrones arquitect onicos diferentes en un unico sistema complejo.An alisis.La descripci on arquitect onica debe poder ser analizada, de modo que se puedandeterminar sus propiedades con independencia de una implementaci on concreta, as comovericarlasdespuesdecualquiermodicaci on. Estosuelevincularseal usodemetodosformales, que permitan una denici on sin ambig uedad semantica.Enrealidad, lamayoradelos Adls existentes carecendealgunadeestas propiedades,incluyendo a los denidos por los propios Garlan y Shaw;pero, tomada en un sentido amplio,esta caracterizaci on resulta suciente para delimitar con claridad que es lo que no constituye unAdl propiamente dicho, a pesar del parecido que pueda mostrar en otros aspectos.Por otra parte, Nenad Medvidovic [MT00] ha elaborado, con base en esta enumeraci on, unmarco de comparaci on y clasicaci on deAdls, que permite realizar una verdadera taxonoma.El marcoesmuy detallado,eincluyeuna gran variedad depuntos,demodo que sepuede es-tructuraradecuadamentecualquierpropuestaexistente. Tambienseidenticanqueaspectosseconsideranesencialesparadeterminarqueunlenguajees, efectivamente, unAdl: concre-tamente, la estructuraci on en componentes, la especicaci on de conectores, la denici on de susinterfaces, y, sobretodo, ladescripci onexplcitadelasconguracionescompuestasportodosellos.A pesar de todo lo dicho, en los ultimos a nos ha habido cierta tendencia a intentar expresaruna arquitectura de software utilizando notaciones de prop osito general,sobre todoUml y sucombinaci on conRoom [SR98]. M as todava, el Proceso Unicado de Rational [Kru99] se basaenunusointensivodearquitecturasdescritasmedianteUml, einclusoexisteunapropuestacompleta[HNS00] paralaadaptaci onde Umlaesteprop osito. Noobstante, yaunqueescierto de los mecanismos de estereotipos permiten una modicaci on de la notaci on est andar mascercana a las necesidades del campo, debe de reconocerse con Medvidovic y Rosenblum [MR99]que este enfoque resulta, en terminos generales, contraintuitivo e inadecuado.2.4.2 ComponenteEl concepto fundamental de la Arquitectura de Software es el de componente. Esto se reere, enterminos globales,a cada una de las partes o unidadesdecomposici onpor denici on en lasque se subdivide la funcionalidad de un sistema, y cuya uni on da lugar al sistema completo. Ensusentidomasgenerico,puedehacerreferenciaacualquiertipodeelementoestructural,estoes, integrado en una estructura; y es precisamente con este signicado con el que habitualmentese le utiliza en la Arquitectura de Software.El terminodecomponente noselimitaalaarquitectura, sinoqueesdehechoutilizadoenm ultiplescampos delaIngenieradeSoftwaredesdelapropuestarealizadapor DouglasMcIlroy [McI69] en la celebre conferencia de laOtan en Garmisch-Patenkirchen. En realidad,su connotaci on mas habitual hace referencia mas bien a aspectos de implementaci on, vinculadosa los estudios de Desarrollo Basado en Componentes. Lo cierto es que, en todo caso, el terminosueleiracompa nadodeciertaconfusi on: aunqueexisteciertoconsensoentornoaunaideaintuitiva, resultamuydifcil obtener unadenici onsatisfactoria[BDH+98]. Ni siquieralos172. ArquitecturadeSoftwaredistintos intentos por proporcionar una descripci on formal del concepto [Bro96] han tenido unexito claro, de modo que el signicado preciso de la noci on es a un un tanto difuso.No obstante, la siguiente denici on ha alcanzado cierta popularidad y se considera com un-mente aceptada:Uncomponenteesunaunidaddecomposici ondeaplicacionessoftware, queposeeunconjuntodeinterfacesyunconjuntoderequisitos,yquehadepoderserdesa-rrollado, adquirido, incorporadoal sistemaycompuestoconotroscomponentesdeforma independiente, en tiempo y espacio.Clemens Szyperski [Szy98]Aunque se sustenta, de nuevo, en aspectos de implementaci on, lo cierto es que es lo bastantegeneral como para ser aplicada a cualquiera de los contextos en los que la palabra es normalmenteutilizada, incluyendo a la Arquitectura de Software. Desde este punto de vista, un componente espor tanto una parte de la arquitectura fuertemente encapsulada y con un interfaz bien denido,que se concibe con independencia del resto del sistema, y que se integra en el mismo mediantemecanismos de composici on e interacci on.En realidad, lo unico en lo que est an de acuerdo todos los autores es en que un componenteha de presentar una interfaz denida al resto del sistema, en la que se indica que proporciona y,habitualmente, tambien lo que necesita. Desde este punto de vista, un componente es, pr actica-mente por denici on, una caja negra, en la que el encapsulamiento llega a ser incluso mas rgidoque en el concepto de objeto. Esto se aplica por igual a los componentes de implementaci on, deespecicaci on y arquitect onicos.En el contexto del desarrollo de componentes,las ventajas de tal grado de encapsulamien-toseapor abstracci on, por seguridadopor motivos comercialessoninnegables; perolasposibilidades deadaptaci onquedan limitadas,demodoque sehacenecesario elusodeenvol-ventes [Hol93], adaptadores o mediadores [GHJV94] (ver secci on 4.6). Ese papel ha sido asumidoen Arquitectura de Software, normalmente, mediante el uso de conectores desarrollados espec-camente para la ocasi on. Por ello, no es extra no que cada vez mas autores propongan un cambioen este sentido, de modo que todo componente conste de una interfaz privilegiada que permitaalg un tipo de acceso, con grados relativos de seguridad, a detalles internos. Esto dene lo quese ha dado en llamar una caja gris [BW97], un concepto ya propuesto con anterioridad para laOrientaci on al Objeto [KLM+97, HL95].De hecho, la propuesta para la descripci on arquitect onica que se presenta en esta tesis puedeenmarcarse en esta lnea. Aunque el objetivo de la introducci on de Reexi on en el modelo comose ver a en el Captulo 5 es facilitar la descripci on de dinamismo, debe de tenerse en cuenta quelos esquemas reexivos suponen, precisamente, la especicaci on de un interfaz privilegiado paralos elementos situados en el meta-nivel. De este modo, se obtendr a la denici on de componentescomo una caja gris, como un simple efecto secundario de la incorporaci on de Reexi on.2.4.3 ConectorEl concepto de conector procede principalmente de los trabajos de Mary Shaw [SG96], a partirde su experiencia en Unicon [SDK+95a]. En un celebre artculo [Sha94], propuso considerar por182. ArquitecturadeSoftwareseparadolasabstraccionesrelativasalafuncionalidad(el componente)yasuinteracci on(elconector). Deestemodo, serealizaunaclaraseparaci ondeintereses, quepermiteampliarelnivel de abstracci on y aumentar la modularidad del sistema.Sinembargo, loqueseproponenoessimplementedisponerdedostiposdecomponentes,sinodedistinguirdoselementosdiferenciados, confuncionesmuydispares. Loscomponentesnormales elementos de computaci on realizan una tarea sin preocuparse de como se relacionancon el resto del sistema; por su parte, los elementos e interacci on, denominados conectores, sonlos que se encargan de resolver todas las cuestiones relativas a la comunicaci on de los primeros.Shaw insiste en que los conectores deben ser considerados como elementos de primera clase, quetienen signicado porsmismos. Esto quiere decir que noser andenidos enfunci onde otroselementos,nidise nadosespeccamenteparauncomponente,sinoquepodr anserextradosyconsiderados en otro contexto.Laformamas sencilladever aunconector es comolaencarnaci ondeunprotocolodecomunicaci on, entendido en su sentido mas amplio. En general, cualquier articio o artefactoquepermitacomunicarseadosomaselementosesunconector. Porejemplo, lallamadadeprocedimiento es un tipo cl asico de conector.Noobstante, ladenici ondelconceptosuponequehaydostiposdevnculoentrelosdis-tintoselementosdeunadescripci onarquitect onica: porunaparte,elpropio conector expresala interacci on existente entre varios componentes; pero por otra, esto exige establecer, a su vez,el tipodeenlacequerelacionaacadacomponenteconunconectordeterminado: esteenlacerecibe normalmente el nombre de adjunci ono attachment(3.7.1, 3.7.3, 3.8.2). Sin embargo,a lo largo de esta tesis le denominaremos simplemente conexi on, termino que consideramos masintuitivo y menos forzado, y cercano a su uso convencional en espa nol1.Es importante se nalar que existen ciertas diferencias de matiz en cuanto al uso de la palabraconector. Podra decirse, incluso, que se utiliza con dos sentidos diferentes, aunque relacionados.Porunaparte, sueleentendersequelapropuestaoriginal deShawexigeladenici ondeunnuevotipodeelemento, an alogoauncomponente, yquesedescribedelmodoindicado. Sinembargo, tambiensepuedemencionarlapalabraconector, demodogeneral, comohaciendoreferencia a cualquier interacci on explcita entre dos componentes, lo que incluye a los bindingsdearwin(3.7.2)oalasconexionesdeRapide(3.8.1). Estees, porejemplo, elsentidoenque lo usa Medvidovic en [MT00],cuando se nala que la denici on de conectores es uno de losrasgos que caracterizan a unAdl (2.4.1). Sin embargo, en pro de la claridad, en esta tesis seutilizar a la palabra unicamente en el primer sentido, es decir, como elemento de primera clase,haciendo siempre una distinci on explcita entre conectory conexi on.Incluso en su forma mas b asica, esto es, cuando se los considera como simples conexiones, laenumeraci on de enlaces o asociaciones explcitas entre los elementos de un sistema proporcionaunadescripci on,siquieraparcial,desuestructura; esdecir,desuarquitectura. Puededecirsecon Medvidovic [MT00], pues, que por el mero hecho de disponer de una noci on de conector, unlenguaje ya est a reforzando su capacidad para especicar conguraciones, lo que constituye latarea principal de cualquier Adl. De hecho, uno de los primeros trabajos sobre Rapide [LVM95],unodeloslenguajesconunmodelodeconexi onmassimple,demuestrasinembargoqueesta1Eningles,delmismomodo,preferimoselterminom asgeneraldebinding,utilizadoenalgunoslenguajessinconectores,comoarwin,aunqueestalvezm ascercanoaaspectosformalesodeimplementaci on.192. ArquitecturadeSoftwarecaracterstica, pors sola, resultasucienteparadistinguirconclaridadunAdldeunlen-guajeorientadoalobjetoconvencional. Talvez, sugerirlaposibilidaddeunaconfusi onentreestos dos tipos de lenguajes resulte ahora extra no; sin embargo, y debido al enfasis que amboshacenenelconceptodeencapsulaci on,esteesunpuntoquefueampliamentedebatidoensumomento [Cle96], e incluso reaparece, todava hoy, de manera ocasional.Ha de tenerse en cuenta que se puede ver a los conectores de dos maneras, a menudo antag o-nicas, pero que no tienen por que serlo: como una especicaci on, o como una simple implemen-taci on. El mejor ejemplo de lo primero son los conectores de Wright (3.7.1), mientras que losde Unicon son un adecuado ejemplo de lo segundo. En un lugar intermedio podran situarse losde C2 (3.8.2). Para Wright, los conectores son ante todo especicaciones que indican que es loque se espera de un componente en una interacci on dada. Es decir, se trata ante todo de indicarel papel de cada uno de los componentes en cada uno de los protocolos; si la especicaci on delconector se corresponde con las de los componentes, se puede vericar la correcci on del sistema.ParaUnicon, encambio, unconectornoesmasqueunaimplementaci ondeunprotocolo; suobjetivoes, antetodo, evitarqueel dise nadordel componentetengaquepreocuparsedelosaspectos de interacci on. Por tanto, se plantea como un elemento reutilizable que puede ser co-nectado a un componente en un momento dado, y se encarga desde ese momento de realizar lasinteracciones apropiadas.Nikunj Mehta[MMP00] hahechounestudioexhaustivodetodoaquelloquehasidooesconsideradounconector; aunqueesel principiodeunataxonomaquesehaceclaramentenecesaria, noconstituyemasqueuntrabajopreliminar, ylamentablementenoparecehabertenidocontinuidad. Noobstante, untrabajodeestetipo, completamentedesarrollado, ser aimprescindible para que el concepto puede llegar a alcanzar todo su potencial. Eventualmente,se espera que una comprensi on adecuada de la naturaleza del conector permita la denici on de unalgebra de conectores, que permita su combinaci on, permitiendo la descripci on de interaccionesa un mas elaboradas, en las que se ha elevado el nivel de abstracci on. Los conectores as obtenidosson los que han sido llamados conectores de orden superior[Gar98]; aunque en los ultimos a nosha habido cierto progreso en esta lnea [SG01, LWF01], todava est a en sus etapas iniciales, y esa un poco mas que una idea.Debetenerseencuentaqueel propioconceptodeconectorest aendiscusi on. Aunquesetratadeunaideageneralizadayesaceptadademaneracom un, notodoslosautoresest anplenamenteconvencidosdesunecesidad. Algunos, entrelosquedestacaJeKramer, opinanque la existencia de los conectores distorsiona la naturaleza compositiva de una arquitectura desoftware, quequedaafectadademaneranegativa. Ciertamente, mientrasquelacomposici onde dos elementos de estructura similar dos componentes resulta f acil de expresar, sea formaloinformalmente, esclaroquelaintroducci ondeunsegundotipodeelementoel conectorcomplica la situaci on. Nosetrata simplemente deuna yuxtaposici onde funcionalidades,sinoque ha de considerarse el tipo de composici on que dene el conector. Existe adem as toda unaserie de problemas derivados, como es la diferencia precisa entre componente y conector, o cu al esla naturaleza exacta de un compuesto intermedio, en el que alguno de los extremos o roles deun conector quedase libre. Se ha argumentado que un componente de interacci on, concebidodemaneraequivalenteaunconector, perodenidodeformaan alogaaotroscomponentes,mantienelasposibilidadesdereutilizaci onsinperderlacomposici on. Aunqueestorechazalaposibilidad que lo consideraba como una abstracci on b asica,no contradice explcitamente a la202. ArquitecturadeSoftwarepropuesta de Shaw: el mero hecho de plantear la diferencia entre las dimensiones de composici one interacci ones ya importante, y constituye su verdadera esencia.Endenitiva, lanoci ondeconectorsehaconvertidoenunodelosrasgosdenitoriosdelcampo: seacomouncomponenteespecco,comounaconexi oncompleja,ocomonoci onporpropio derecho, aparecer a siempre, de alg un modo, en toda descripci on arquitect onica.2.4.4 PuertoEl concepto de puerto es cercano al de conector, pero no debe ser confundido con este bajo ning unconcepto. Se denomina con este nombre a cada uno de los puntos por los que un componentepuede realizar cualquier tipo de interacci on; dicho de otro modo, es cada uno de los fragmentosen los que se segmentael interfaz de un componente.En denitiva, hace referencia a un punto de entrada o de salida de la caja negra que es, dehecho, el componente. Distintos autores lo ven y denominan de distinto modo, y la analoga queimplcitamente se establece no es identica en todos los casos. As, si el componente se ve comounobjeto,unpuertodeniraunmetodo; mientrasquesisevecomounproceso,setieneuncanaldemensajes. Hadetenerseencuenta, sinembargo, quelospuertosdeuncomponentenosoloexpresanlosserviciosque esteoferta, sinotambienlosrequisitosqueprecisa; estoes,aquellas condiciones que necesita que cumpla el entorno para funcionar correctamente. Por todoello, la analoga con los metodos de un objeto es simple, pero peligrosa.Lospuertossehandenominadodedistintosmodosendistintoslenguajes; as, enWrightsellamanpuertos enloscomponentes, peroroles enlosconectores, mientrasqueenUniconreciben el nombre de jugadores. En arwin se conocan inicialmente como puertos, para despuespasarallamarsenombresdeinterfaz, demaneraconsistenteconsusemanticaencalculo-.Actualmente conocen como portales, un nombre que expresa total neutralidad respecto del signode la interacci on: es decir, pueden ser de entrada o de salida.Habitualmente los puertos se agrupan deniendo una interfaz; en algunos lenguajes se per-mite, incluso, que denan mas de una. Incluso en algunos sistemas se asume que el puerto est asubestructuradoenvariospuntosdeentrada, yportantosedenetodo elcomounainterfazcompleta.Ese es el caso, por ejemplo, de Koala [vOvdLKM00].Enloslenguajesquecarecendeconectores,elconceptodepuertoesa unmasimportante.En la segunda versi on dearwin (3.7.2),por ejemplo, los puertos est an fuertemente tipados,demodoqueel tipoexpresasuposiblecomportamiento. Lacomplejidadpuedellegarhastatal puntoquelos niveles deabstracci onresultenconfusos. As, por ejemplo, enUniconelmecanismo de Rpc es un conector, mientras que en arwin esto dene simplemente el tipo portdeunportal. Algoan alogosucedeconlosmecanismosdedifusi ondeeventosyeltipoeventde un puerto. Adem as, los portales dearwin son moviles, pueden separarse del componente eincluso representarlo de manera remota como un proxy, lo que supone una funci on habitualmentereservada ya no a un conector, sino incluso a un componente.En todo caso, su denici on es un aspecto fundamental, ya que congura la naturaleza externade los componentes, lo que a su vez condiciona la estructura de la arquitectura.212. ArquitecturadeSoftware2.4.5 EstiloArquitect onicoLanoci ondeestiloesotrodelosconceptosfundamentalesdelaArquitecturadeSoftware, yposiblementeel masimportantedetodosellos. Tienetantodeaspiraci oncomoderealidad,yel futurodel campodependedelaformaquellegueatomardenitivamente. Describeyproporciona las propiedades b asicas de una arquitectura, y tambien es el encargado de imponerlos lmites a su evoluci on, lo que lo relaciona estrechamente con el dinamismo arquitect onico.Sedenominaconguraci on, siguiendolanomenclaturadeGarlan, alaarquitecturadesoftware de un sistema concreto, esto es, a la estructura especca constituida por unos compo-nentesyconectoresdeterminados. Porcontraposici on, sedenominaestiloarquitect onicoacada uno de los patrones genericos que pueden identicarse en un grupo de sistemas relaciona-dos [CFBS99]. Es decir, una conguraci on es una instancia concreta de un estilo. Este concepto,conserelmasoriginaldelcampo, lorelacionadirectamenteconelestudiodelospatronesdedise no.Esta no es su unica coincidencia:ambos nacen de la analoga con la Arquitectura cl asica,y en especial con los trabajos de Christopher Alexander [Ale81, AIS+80, Lea94]En general, se puede denir estilo arquitect onico como la descripci on de una familia de siste-mas en terminos de un patr on de organizaci on estructural [Gar95, SG95]. M as especcamente,la especicaci on de un estilo dene:Un vocabulario de tipos de componentes y conectores de los que se dispone.Un conjunto de restricciones sobre el modo en que estos pueden ser combinados.Opcionalmente,unmodelosem anticoquedetermine comosepuedendeducirlaspro-piedades globales del sistema a partir de las propiedades de cada uno de sus elementos.Existeunconsensogeneralizadoenlaideadequecualquierdescripci onrazonabledeestilosarquitect onicossehadebasarenlacombinaci ondeestoselementos; masa un: unicamenteenellos. Sinembargo, ningunadelaspropuestasconcretasactualesparecesersatisfactoria,o mostrar suciente expresividad como para capturar de manera adecuada la idea intuitiva deestilo. El unico lenguaje que ha intentado la denici on de estilos con un enfoque generalista hasido Wright [All97]. Sin embargo, sus estilos est an todava a demasiado bajo nivel, acerc andosedemasiado a la noci on de conguraci on. De manera an aloga, Padl intenta describir simplementeun concepto intermedio, al que denomina, con poca fortuna, tipo arquitect onico. Otros lenguajes,como Aesop [GAO94] oAsdl [RS96] resultan a un mas limitados.Aunque todava no existe un metodo satisfactorio para describir estilos en ning un lenguaje,se han realizado intentos diversos que, en alguna medida, parecen ir bien encaminados. Todosestos enfoques, de alg un modo, se aproximan al objetivo:Mediante unaarquitecturaabierta, esto es, un fragmento de una arquitectura que ha deser completada para dar lugar a un sistema completo;esto dene una gran parte de suspropiedadesyproporcionaimplcitamenteunestilo. Esto,denuevo, puedeconsiderarseen relaci on tanto con los patrones de dise no como con los frameworks[Bos98].Medianteunaarquitecturaconceptual, esdecir, unaseriedeideasyabstraccionesquedenen el vocabulario b asico del sistema, y sus relaciones [Ran99].222. ArquitecturadeSoftwareMediante unagram aticadegrafos, considerando a la arquitectura como un grafo. Este esun enfoque mas limitado de lo que parece, ya que restringe en exceso el rango de sistemasposibles. Existen, no obstante, diferentes aproximaciones (3.9).Mediante la denici on de unasrestriccionesl ogicas que indican las caractersticas b asicasquelaarquitecturahademantenerentodomomento. Esel caso, porejemplo, delosestilos de Wright [All97].Estilo Arquitect onico___Sistemas de Flujo de Datos___Secuenciales por LotesFiltro/TuberaSistemas de Control Cl asicoSistemas de Llamada-Respuesta___Arbol de M odulos (Subrutina)Sistemas Orientados a ObjetosCapas Jer arquicasCliente-ServidorComponentes Independientes_Procesos ComunicantesSistemas de EventosM aquinas Virtuales_InterpretesSistemas Basados en ReglasRepositorios___Bases de DatosSistemas de HipertextoPizarrasFigura 2.2: Taxonoma de Estilos, adaptada de [SG95]Aunque el soporte ling ustico no est a a un claro, el estudio de los estilos ha sido acometidodesdeunpuntodevistainformal, ysehanidenticadounbuenn umerodeellos, as comoalgunasdesuscaractersticasmassignicativas. Noseentrar aaquacomentarlosendetalle;no obstante, en la Figura 2.2 se incluye una taxonoma preliminar, con el n de mostrar el tipode conceptos que se manipulan en este contexto.No se profundizar a mas aqu en este concepto,ni en sus relaciones con otras nociones cer-canas, talescomoladelneadeproducto[JRvdL00] oladefamiliadesistemas. Aunquesetrata de uno de los aspectos mas interesantes y fundamentales de la Arquitectura de Software,su relaci on con la descripci on de arquitectura din amica, que constituye el tema principal de estatesis, es mas bien indirecta. En este sentido, lo unico que hace es restringirlas posibilidades deevoluci on, imponiendo lmites. No obstante, es un tema que apenas ha sido estudiado, salvo demodo marginal (3.9.2, 3.9.3), y todava est a pendiente de recibir un tratamiento adecuado.2.4.6 VistaLa noci on de vistas, aunque fue mencionada por los primeros autores del campo, ha sido la ultimaen ser propuesta de manera explcita,y su exito ha sido inmediato, ya que,por ejemplo,es el unico aspecto obligatorio en la Pr actica Recomendada RP-1471 sobre Arquitectura de Softwarede la IEEE [AWG99], que adopta explcitamente un enfoque multi-vista de la Arquitectura deSoftware.232. ArquitecturadeSoftwareEl concepto de vistase limita a se nalar la posibilidad de que una arquitectura de softwarepuedaexaminarsedesdediferentesperspectivasliteralmente, puntosdevista, demodoquecada una de estas arquitecturas parciales constituye una vista. Luego, la visi on completa delsistema seadquiere por combinaci on de todas ellas. Se mantiene,de nuevo,la met afora de laarquitectura cl asica, por analoga con los distintos planos de un mismo edicio.El conceptonoasumequeel Adlutilizadohayadetenerunsoportedem ultiplesvistas:habitualmente, seasumequesetienenvarias descripciones del mismosistema, tpicamenteenel mismolenguaje, ylavisi onglobal seobtienedemodopuramenteheurstico. Lociertoesquening unlenguajeexistentehadenidounsoporteexplcitoparavistas; el tratamientohasidosiempremuyinformal, porloqueestesoporteresultaramuyconveniente. Admite,adem as, una interesante analoga con la denominada separaci on de intereses avanzada, esto es,la generalizaci on de laAop (4.6),traducida en conceptos parcialmente sin onimos como el desujeto, dimensi on o aspecto.Los primeros en sugerir un enfoque multi-vista fueron los propios Perry y Wolf, que ya desdeel principio[PW92] identicaronqueunaarquitecturahabradetenerunavistadeujosdedatos, otra de control, y otra de uso de recursos. Las tres consisten, por tanto, en enfoques muytradicionales,cercanosinclusoalosdesarrolloscontempor aneosenmetodologasorientadasalobjeto, comoOmt [RBP+91] o Booch93 [Boo96].Sin embargo, sin duda la propuesta mas difundida es el denominado Modelo 4+1de PhilippeKruchten, que fue dise nado especcamente dentro del contexto de la Arquitectura de Softwa-re[Kru95], perohasidoposteriormentepopularizadoporsuadaptaci onaUmlysudifusi ondentro del campo de la orientaci on al objeto. La Figura 2.3 muestra el modo en que el modelofue modicado para obtener una correspondencia mas directa conUml.Vista Logica Vista LogicaVista de Procesos Vista de ProcesosVista de Desarrollo Vista de Implementaci onVista Fsica Vista de DespliegueVista de Escenarios Vista de Caso de UsoFigura 2.3: Evoluci on de Vistas en el Modelo 4+1 de KruchtenAunqueesunaspectoquenoser aconsiderado alolargodeestatesis,nodebedejarsedese nalarquelacombinaci ondeReexi onenunAdlcreaunainfraestructuraparticularmenteadecuadaparaeltratamientodem ultiples vistas. Obviamente,laidenticaci ondelospuntoscomunes los puntos deuni ondelaAopseharaenbaseacomponentes concretos, ylainuencia de las distintas vistas puede expresarse mediante reicaciones sobre estos puntos. Deeste modo, la combinaci on se producira por simple combinaci on paralela, con un metodo similara la propuesta de Andrews [And01] para los fundamentos de laAop. No obstante, este enfoquerequiere un estudio mas detallado, y ser a considerado como trabajo futuro.242. ArquitecturadeSoftware2.5 Conclusi onComo ha podido verse en este mismo captulo, el campo de estudio de la Arquitectura de Soft-ware se ha extendido de manera considerable en los ultimos a nos, a la par que su importanciaa continuado creciendo. Aqu se han revisado apenas algunos de sus conceptos fundamentales,desdeel puntodevistadeladescripci onarquitect onica, conel ndeproporcionarunabaseadecuada para la comprensi on de captulos posteriores. Algunas nociones,como la de compo-nente, conector o puerto ser an decisivas; otras, como la de estilo o vista, ser an solo mencionadasde manera general, ya que no se relacionan directamente con los objetivos de esta tesis.Una vez se ha proporcionado una mnima introducci on al campo, la exposici on se centrar aya en la problem atica principal a acometer en esta tesis, esto es, la especicaci on de dinamismoen la Arquitectura de Software, y la unicaci on de las distintas aproximaciones a este problema,con base en el concepto de reexi on.25Captulo3ArquitecturadeSoftwareDinamicaTratar de entender [la estructura de ejecuci on de un programa ]a partir de [la estructura de su c odigo ] es comotratar de entender el dinamismo de los ecosistemas vivosa partir de la taxonoma est atica de plantas y animales, y viceversa.ErichGamma[GHJ+95b]3.1 Introducci onEn este Captulo se proporciona un estudio general sobre la Arquitectura de Software Din amicao, parasermasexactos, sobrelosdistintosenfoquesutilizadosporaquellosAdlsdotadosdecapacidades din amicas. Existen al menos dos motivos de importancia para incluir aqu un estudiode estas caractersticas. En primer lugar, como ya se ha comentado en la Introducci on (1), laespecicaci on de dinamismo es uno de los objetivos primarios de esta tesis, y el interes principalduranteel dise nodel lenguaje TiLar (6), si biennoel unico. Ensegundolugar, resultaoportunorealizar dichoestudiodebidoal hechodeque, hastalafecha, noexistaningunosimilar. Las revisiones existentes del campo se reducan a breves recensiones en algunos artculosapenas[Med96a, OT98], otrabajospropioscomo[CFBSB00, CFBSB01], yres umenesenalgunastesisdoctorales[Cra97,MG99,Med99,Pry00,Wer99],normalmenteincompletos. Enrealidad, el tratamiento mas amplio si bien no el mas extenso disponible se limitaba a los cincop arrafos dedicados al tema en las secciones 4.3.7 y 4.4.6 de la conocida clasicaci on deAdls deMedvidovic [MT00]. En resumen, una revisi on detallada del campo era a un necesaria.Sepretendequelarevisi onincluidaenesteCaptulosealosucientementecompleta; noobstante, esto no quiere decir que se incluya en ella todo lenguaje que haya armado ser un Adldin amico. De hecho, interesa hacer un tratamiento lo mas preciso posible, realmente centrado enel dominio arquitect onico; por tanto, se evitar a en gran medida discutir todos aquellos lenguajesque no puedan considerarse un autenticoAdl; en este sentido se utilizar a un criterio bastanteabierto, aunque se tendr an en cuenta los criterios establecidos por Medvidovic.En particular, se dejar an de considerar todas aquellas aproximaciones a la Arquitectura deSoftwareDin amicaquenodenenunacontrapartidaling ustica, yaquelloslenguajesquesebasan unicamenteenlaexistenciadeunaimplementaci onconcreta. Estoexcluyeaunbuen273. ArquitecturadeSoftwareDinamican umero de lenguajes de composici on y conguraci on, y tambien a los Lenguajes de Descripci onde Interfaces (Idls), entre los que merece especial menci on el deCorba.Noobstante, alolargodeestecaptulosecomentar anbrevementealgunosLenguajesdeInterconexi ondeM odulos(Mils), comoConicoDurra; peronoseconsideranecesariohaceruna revisi on detallada de todos ellos, ya que, de nuevo, no se trata de Adls propiamente dichos.Porestemotivonoseentranadetallaralgunossistemasindudablementeinteresantes, yquemuestran cierto grado de dinamismo, tales como Gerel [EW92, End94],