Lenguaje de Descripcion de Arquitecturas LDA: La arquitectura de Software, tras conocer sus requerimiento, se decide a elegir su estrategia y a articular los patrones que se usan, se supone que debería modelar las características del sistema, aplicando una convención gráfica o algún lenguaje avanzado de alto nivel de abstracción.
Esto se remontan a los lenguajes de interconexión de módulos (MIL) de la década de1970, pero se han comenzado a desarrollar con su denominación actual a partir de 1992 o 1993.Definición: ADL-Lenguaje descriptivo de modelado arquitectónico de software que se focaliza en la estructura de alto nivel de la aplicación antes que en los detalles de implementación de sus módulos concretos. Su abreviatura es ADL.
Lenguajes:
Acme - Armani
Acme se define como una herramienta capaz de soportar el mapeo de especificaciones
arquitectónicas entre diferentes ADLs, o en otras palabras, como un lenguaje de intercambio de arquitectura. No es entonces un ADL en sentido estricto, aunque la literatura de referencia acostumbra tratarlo como tal. De hecho, posee numerosas prestaciones que también son propias de los ADLs. En su sitio oficial se reconoce que como ADL no es necesariamente apto para cualquier clase de sistemas, al mismo tiempo que se destaca su capacidad de describir con facilidad sistemas “relativamente simples”.
La motivación fundamental de Acme es el intercambio entre arquitecturas e integración de ADLs. Garlan considera que Acme es un lenguaje de 10 descripción arquitectónica de segunda generación; podría decirse que es de segundo orden: un metalenguaje, una lingua franca para el entendimiento de dos o más ADLs, incluido Acme mismo. Con el tiempo, sin embargo, la dimensión metalingüística de Acme fue perdiendo prioridad y los desarrollos actuales profundizan su capacidad intrínseca como ADL puro.
Acme soporta la definición de cuatro tipos de arquitectura: la estructura (organización de un sistema epartes constituyentes); las propiedades de interés (información que permite razonar sobre el comportamiento local o global, tanto funcional como no funcional); las restricciones (lineamientos sobre la posibilidad del cambio en el tiempo); los tipos y estilos. La estructura se define utilizando siete tipos de entidades: componentes, conectores, sistemas, puertos, roles, representaciones y rep-mapas (mapas de representación).
Componentes – Representan elementos computacionales y almacenamientos de un sistema. Como se verá en el ejemplo, un componente se define siempre dentro de una familia.
Interfaces – Todos los ADLs conocidos soportan la especificación de interfaces para sus componentes. En Acme cada componente puede tener múltiples interfaces. Igual que en Aesop y Wright los puntos de interfaz se llaman puertos (ports). Los puertos pueden definir interfaces tanto simples como complejas, desde una signatura de procedimiento hasta una colección de rutinas a ser invocadas en cierto orden, o un evento de multicast.
Conectores – En su ejemplar estudio de los ADLs existentes, Medvidovic (1996) llama a los lenguajes que modelan sus conectores como entidades de primera clase lenguajes de configuración explícitos, en oposición a los lenguajes de configuración in-line. Acme pertenece a la primera clase, igual que Wright y UniCon. Los conectores representan interacciones entre componentes. Los conectores también tienen interfaces que están definidas por un conjunto de roles. Los conectores binarios son los más sencillos: el invocador y el invocado de un conector RPC, la lectura y la escritura de un conector de tubería, el remitente y el receptor de un conector de paso de mensajes.
Semántica – Muchos lenguajes de tipo ADL no modelan la semántica de los componentes más allá de sus interfaces. En este sentido, Acme sólo soporta cierta clase de información semántica en listas de propiedades. Estas propiedades no se interpretan, y sólo existen a efectos de documentación.
Estilos – Acme posee manejo intensivo de familias o estilos. Esta capacidad está construida naturalmente como una jerarquía de propiedades correspondientes a tipos. Acme considera, en efecto, tres clase de tipos: tipos de propiedades, tipos estructurales y estilos. Así como los tipos estructurales representan conjuntos de elementos estructurales, una familia o estilo representa un conjunto de sistemas. Una familia Acme se define especificando tres elementos de juicio: un conjunto de tipos de propiedades y tipos estructurales, un conjunto de restricciones y una estructura por defecto, que prescribe el conjunto mínimo de instancias que debe aparecer en cualquier sistema de la familia. El uso del término “familia” con preferencia a “estilo” recupera una idea de uno de los precursores tempranos de la arquitectura de software, David Parnas
Armani se constituyó en un lenguaje de tipo ADL, especializado en la descripción de la estructura de un sistema y su evolución en el tiempo. Es un lenguaje puramente declarativo que describe la estructura del sistema y las restricciones a respetar, pero no hace referencia alguna a la generación del sistema o a la verificación de sus propiedades no funcionales o de consistencia. De alguna manera, la naturaleza de Armani captura también el expertise de los diseñadores, señalando su vinculación con la práctica de los patrones arquitectónicos, en este caso patrones de diseño. Armani se basa en siete entidades para describir las instancias del diseño: componentes, conectores, puertos, roles, sistemas, representaciones y propiedades. Para capturar las experiencias y tipos de elementos de diseño, tipos de propiedades, invariantes de diseño, heurísticas, análisis y estilos arquitectónicos. La sección denotacional de Armani tiene un aire de familia con la sintaxis de cláusulas de Horn en lenguaje Prolog.
ADML
Como hubiera sido de esperarse ante la generalización del desarrollo en la era del Web,
ADML (Architecture Description Markup Language) constituye un intento de estandarizar la descripción de arquitecturas en base a XML. Está siendo promovido desde el año 2000 por The Open Group y fue desarrollado originalmente en MCC.
Como quiera que sea, ADML agrega al mundo de los ADLs una forma de representación basada en estándares de la industria, de modo que ésta pueda ser leída por cualquier parser de XML. En ambientes Windows el parser primario y el serializador de XML se instala con Microsoft Internet Explorer de la versión 4 en adelante, y todas las aplicaciones de Office, así como SQL Server, poseen soporte nativo de XML y por lo tanto del lenguaje arquitectónico de markup. El Framework .NET de Microsoft incluye además clases (xmlreader, xmlwriter) que hacen que implementar tratamiento de documentos ADML, xADL, xArch y sus variantes resulte relativamente trivial.
En consonancia con la expansión de Internet, ADML permite también definir vínculos con bjetos externos a la arquitectura (fundamentación racional, diseños, componentes, etcétera), así como interactuar con diversos repositorios de industria, tales como las especificaciones de OASIS relativas a esquemas para SWIFT, IFX, OFX/OFE, BIPS, OTP, OMF, HL7, osettaNet o similares.
ADML constituye además un tronco del que depende una cantidad de especificaciones más puntuales. Mientras ADML todavía reposaba en DTD (Document Type Definition), una sintaxis de metadata que ahora se estima obsoleta, las especificaciones más nuevas implementan esquemas extensibles de XML. La más relevante tal vez sea xADL (a pronunciar como “zaydal”), desarrollado por la Universidad de California en Irvine, que define XML Schemas Para la descripción de familias arquitectónicas, o sea estilos.
AESOP
El nombre oficial es Aesop Software Architecture Design Environment Generator. Se ha desarrollado como parte del proyecto ABLE de la Universidad Carnegie Mellon, cuyo objetivo es la exploración de las bases formales de la arquitectura de software, el desarrollo del concepto de estilo arquitectónico y la producción de herramientas útiles a la arquitectura, de las cuales Aesop es precisamente la más relevante. La elaboración formal del proyecto ABLE, por otro lado, ha resultado en el lenguaje Wright, que en este estudio se trata separadamente. Uno de los mejores documentos sobre Aesop es el ensayo de David Garlan, Robert Allen y John Ockerbloom que explora el uso de estilos en el diseño arquitectónico.
La definición también oficial de Aesop es “una herramienta para construir ambientes de diseño de software basada en principios de arquitectura”. El ambiente de desarrollo de Aesop System se basa en el estilo de tubería y filtros propio de UNIX. Un diseño en Aesop requiere manejar toda una jerarquía de lenguajes específicos, y en particular FAM Command Language (FCL, a pronunciar como “fickle”), que a su vez es una extensión de TCL orientada a soportar modelado arquitectónico. FCL es una combinación de TCL y C densamente orientada a objetos. En lo que respecta al manejo de métodos de análisis de tiempo real, Aesop implementa EDF (Earliest Deadline First).
ArTek
ArTek fue desarrollado por Teknowledge. Se lo conoce también como ARDEC/Teknowledge Architecture Description Language. En opinión de Medvidovic no es un genuino ADL, por cuanto la configuración es modelada implícitamente mediante información de interconexión que se distribuye entre la definición de los componentes individuales y los conectores. En este sentido, aunque pueda no ser un ADL en sentido estricto, se le reconoce la capacidad de modelar ciertos aspectos de una arquitectura. De todas maneras, es reconocidamente un lenguaje específico de dominio y siempre fue presentado como un caso testigo de generación de un modelo a partir de una instancia particular de uso.Disponibilidad de plataforma – Hoy en día ArTek no se encuentra disponible en ningún
sitio y para ninguna plataforma.
C2 (C2 SADL, C2SADEL, xArch, xADL)
C2 o Chiron-2 no es estrictamente un ADL sino un estilo de arquitectura de software que se ha impuesto como estándar en el modelado de sistemas que requieren intensivamente pasaje de mensajes y que suelen poseer una interfaz gráfica dominante. C2 SADL (Simulation Architecture Description Language) es un ADL que permite describir arquitecturas en estilo C2. C2SADEL es otra variante; la herramienta de modelado canónica de este último es DRADEL (Development of Robust Architectures using a Description and Evolution Language). Llegado el momento del auge de XML, surge primero xArch y luego xADL, de los que ya se ha tratado en el apartado correspondiente a ADML y sus 19 derivaciones, pero sin hacer referencia a su conformidad con C2, que en los hechos ha sido enfatizado cada vez menos. Otra variante, SADL a secas, denota Structural Architecture Description Language; fue promovido alguna vez por SRI, pero no parece gozar hoy de buena salud.
CHAM
CHAM (Chemical Abstract Machine) no es estrictamente un ADL, aunque algunos autores, en particular Inverardi y Wolf [BB92] aplicaron CHAM para describir la arquitectura de un compilador. Se argumenta, en efecto, que CHAM proporciona una base útil para la descripción de una arquitectura debido a su capacidad de componer especificaciones paralas partes y describir explícitamente las reglas de composición. Sin embargo, la formalización mediante CHAM es idiosincrática y (por así decirlo) hecha a mano, de modo que no hay criterios claros para analizar la consistencia y la completitud de las descripciones de configuración. Convendrá contar entonces con alguna herramienta de verificación.
CHAM es una técnica de especificación basada en álgebra de procesos que utiliza como fundamento teórico los sistemas de rescritura de términos para capturar la conducta comunicativa de los componentes arquitectónicos. El modelo de CHAM reposa en una metáfora química en la cual la conducta de una arquitectura se especifica definiendo molé-culas y soluciones de moléculas. Las moléculas constituyen los componentes básicos, mientras que las soluciones son multiconjuntos de moléculas que definen los estados de una CHAM. Una especificación CHAM también contiene reglas de transformación que dictan las formas en que pueden evolucionar las soluciones (o sea, en que pueden cambiar los estados). En un momento dado, se puede aplicar un número arbitrario de reglas a una solución, siempre que no entren en conflicto. De esta forma es posible modelar conductas paralelas, ejecutando transformaciones en paralelo. Cuando se aplica más de una regla a una molécula o conjunto, CHAM efectúa una decisión no determinista, escogiendo alguna de las reglas definidas.
Darwin
Darwin es un lenguaje de descripción arquitectónica desarrollado por Jeff Magee y Jeff Kramer [MEDK95, MK96]. Darwin describe un tipo de componente mediante una interfaz consistente en una colección de servicios que son ya sea provistos (declarados por ese componente) o requeridos (o sea, que se espera ocurran en el entorno). Las configuraciones se desarrollan instanciando las declaraciones de componentes y estableciendo vínculos entre ambas clases de servicios.Darwin soporta la descripción de arquitecturas que se reconfiguran dinámicamente a través de dos construcciones: instanciación tardía [lazy] y construcciones dinámicas explícitas. Utilizando instanciación laxa, se describe una configuración y se instancian componentes sólo en la medida en que los servicios que ellos provean sean utilizados por otros componentes. La estructura dinámica explícita, en cambio, se realiza mediante constructos de configuración imperativos. De este modo, la declaración de configuración deviene un programa que se ejecuta en tiempo de ejecución, antes que una declaración estática de la estructura.
Jacal
Es un lenguaje de descripción de arquitecturas de software de propósito general creado en la Universidad de Buenos Aires, por un grupo de investigación del Departamento de Computación de la Facultad de Ciencias Exactas y Naturales. Objetivo principal – El objetivo principal de Jacal es lo que actualmente se denomina “animación” de arquitecturas. Esto es, poder visualizar una simulación de cómo se comportaría en la práctica un sistema basado en la arquitectura que se ha representado. Más allá de este objetivo principal, el diseño de Jacal contempla otras características deseables en un ADL, como por ejemplo contar con una representación gráfica que permita a simple vista transmitir la arquitectura del sistema, sin necesidad de recurrir a información adicional. Para este fin, se cuenta con un conjunto predefinido (extensible) de conectores, cada uno con una representación distinta. LILEANNA
Al igual que en el caso de ArTek, en opinión de Medvidovic LILEANNA no es un genuino ADL, por cuanto la configuración es modelizada implícitamente mediante información de interconexión que se distribuye entre la definición de los componentes individuales y los conectores. En este sentido, aunque pueda no ser un ADL en sentido estricto, se le reconoce la capacidad de modelizar ciertos aspectos de una arquitectura.LILEANNA es, visto como ADL, estructural y sintácticamente distinto a todos los demás. De hecho, es oficialmente un lenguaje de interconexión de módulos (MIL), basado en expresiones de módulo propias de la programación parametrizada. Un MIL se puede utilizar descriptivamente, para especificar y analizar un diseño determinado, o constructivamente, para generar un nuevo sistema en base a módulos preexistentes, ejecutando el diseño. Típicamente, la programación parametrizada presupone la disponibilidad de dos clases de bibliotecas, que contienen respectivamente expresiones de módulo (que describen sistemas en términos de interconexiones de módulos) y grafos de módulo (que describen módulos y relaciones entre ellos, y que pueden incluir código u otros objetos de software).
LILEANNA es un ADL (o más estrictamente un MIL) que utiliza el lenguaje Ada para la implementación y Anna para la especificación. Fue desarrollado como parte del proyecto DSSA ADAGE, patrocinado por ARPA. La implementación fue llevada a cabo por Will 30 Tracz de Loral Federal Systems y se utilizó para producir software de navegación de helicópteros.
MetaH/AADL
Así como LILEANNA es un ADL ligado a desarrollos que guardan relación específica con helicópteros, MetaH modela arquitecturas en los dominios de guía, navegación y control (GN&C) y en el diseño aeronáutico. Aunque en su origen estuvo ligado 31 estrechamente a un dominio, los requerimientos imperantes obligaron a implementar recursos susceptibles de extrapolarse productivamente a la tecnología de ADLs de propósito general. AADL (Avionics Architecture Description Language) está basado en la estructura textual de MetaH. Aunque comparte las mismas siglas, no debe confudirse este AADL con Axiomatic Architecture Description Language, una iniciativa algo más antigua que se refiere al diseño arquitectónico físico de computadoras paralelas.
Objetivo principal – MetaH ha sido diseñado para garantizar la puesta en marcha, la confiabilidad y la seguridad de los sistemas modelados, y también considera la disponibilidad y las propiedades de los recursos de hardware. Soporte de lenguajes – MetaH está exclusivamente ligado a desarrollos hechos en Ada en el dominio de referencia. Disponibilidad de plataforma – Para trabajar con MetaH en ambientes Windows, Honeywell proporciona un MetaH Graphical Editor implementado en DoME, que provee un conjunto extenso de herramientas visuales y de edición de texto.
Rapide
Se puede caracterizar como un lenguaje de descripción de sistemas de propósito general que permite modelar interfaces de componentes y su conducta observable. Sería tanto un ADL como un lenguaje de simulación. La estructura de Rapide es sumamente compleja, y en realidad articula cinco lenguajes: el lenguaje de tipos describe las interfaces de los componentes; el lenguaje de arquitectura describe el flujo de eventos entre componentes; el lenguaje de especificación describe restricciones abstractas para la conducta de los componentes; el lenguaje ejecutable describe módulos ejecutables; y el lenguaje de patrones describe patrones de los eventos. Los diversos sub-lenguajes comparten la misma visibilidad, scoping y reglas de denominación, así como un único modelo de ejecución.UML - De OMT al Modelado OO
UML forma parte del repertorio conocido como lenguajes semi-formales de modelado. Esta variedad de herramientas se remonta a una larga tradición que arrancó a mediados de la década de 1970 con PSL/PSA, SADT y el análisis estructurado. Alrededor de 1990 aparecieron los primeros lenguajes de especificación orientados a objeto propuestos por Grady Booch, Peter Coad, Edward Yourdon y James Rumbaugh. A instancias de Rumbaugh, Booch e Ivar Jacobson, finalmente, estos lenguajes se orientaron hacia lo que es hoy UML (Unified Modeling Language), que superaba la incapacidad de los primeros lenguajes de especificación OO para modelar aspectos dinámicos y de comportamiento de un sistema introduciendo la noción de casos de uso. De hecho, UML surgió de la convergencia de los métodos de Booch orientados a comportamiento, la Object Modeling Technique (OMT) de Rumbaugh y el OOSE/Objectory de Jacobson, así como de otras tecnologías tales como los gráficos de estado de Jarel, los patrones de documentación de Gamma y otros formalismos.UniCon
UniCon (Universal Connector Support) es un ADL desarrollado por Mary Shaw y otros [SDK+95]. Proporciona una herramienta de diseño para construir configuraciones ejecutables basadas en tipos de componentes, implementaciones y “conexiones expertas” que soportan tipos particulares de conectores. UniCon se asemeja a Darwin en la medida en que proporciona herramientas para desarrollar configuraciones ejecutables de caja negra y posee un número fijo de tipos de interacción, pero el modelo de conectores de ambos ADLs es distinto. Oficialmente se define como un ADL cuyo foco apunta a soportar la variedad de partes y estilos que se encuentra en la vida real y en la construcción de sistemas a partir de sus descripciones arquitectónicas. UniCon es el ADL propio del proyecto Vitruvius, cuyo objetivo es elucidar un nivel de abstracción de modo tal que se pueda capturar, organizar y tornar disponible la experiencia colectiva exitosa de los arquitectos de software.Wright
Se puede caracterizar sucintamente como una herramienta de formalización de conexiones arquitectónicas. Ha sido desarrollado por la Escuela de Ciencias Informáticas de la Universidad Carnegie Mellon, como parte del proyecto mayor ABLE. Este proyecto a su vez se articula en dos iniciativas: la producción de una herramienta de diseño, que ha sido Aesop, y una especificación formal de descripción de arquitecturas, que es propiamente Wright. Objetivo principal – Wright es probablemente la herramienta más acorde con criterios académicos de métodos formales. Su objetivo declarado es la integración de una metodología formal con una descripción arquitectónica y la aplicación de procesos formales tales como álgebras de proceso y refinamiento de procesos a una verificación automatizada de las propiedades de las arquitecturas de software.Modelo Comunicacional:
Un ejemplo de paradigma comúnmente aceptado sería el modelo estándar de la física. Los métodos científicos permitirían a los científicos ortodoxos investigar muchos fenómenos que pueden resultar contradictorios o contrastantes con el modelo estándar. Sin embargo es mucho más difícil obtener consenso para los mismos, en proporción a la divergencia de los principios aceptados del modelo estándar que tales experimentos examinarían.
Los modelos paradigmáticos son modelos metafísicos y epistemológicos, que proporcionan el "contexto" en que se forman los diferentes modelos teóricos y teorías de un nivel inferior, presentando las directrices generales de agrupamiento de las diferentes teorías. También se puede definir como "Un patrón o modelo”
Es un modelo matemático en las ciencias de la computación que requiere extensos recursos computacionales para estudiar el comportamiento de un sistema complejo por medio de la simulación por computadora. En lugar de derivar una solución analítica matemática para el problema, la experimentación es hecha con el modelo cambiando los parámetros del sistema en la computadora, y se estudian las diferencias en el resultado de los experimentos.
Ejemplos de modelos computacionales comunes son modelos de el pronóstico del tiempo, modelos del Earth Simulator, modelos de simulador de vuelo, modelos desplegamiento molecular de proteínas, y modelos de red neural.
Modelos Comunes:
Pronóstico del tiempo:
Es la aplicación de tecnología y de ciencia para predecir el estado de la atmósfera para un período futuro y una localidad o región dada.
Earth simulator:
Es un superordenador desarrollado por las agencias Japonesas Nasda, utilizado principalmente en simulaciones climáticas y de convección en el interior terrestre.
Hasta finales del año 2003, ostentó el título de superordenador más rápido del mundo, con una capacitad computacional de más de 35 Teraflops.
Simulador de Vuelo:
Es un sistema que intenta replicar, o simular, la experiencia de volar una aeronave de la forma más precisa y realista posible. Los diferentes tipos de simuladores de vuelo van desde videojuegos hasta réplicas de cabinas en tamaño real montadas en accionadores hidráulicos (o electromecánicos), controlados por sistemas modernos computarizados.
Plegamiento de Proteínas:
Es el proceso por el que una proteína alcanza su estructura tridimensional. La función biológica de una proteína depende de su correcto plegamiento. Si una proteína no se pliega correctamente será no funcional y, por lo tanto, no será capaz de cumplir su función biológica.
Red neural:
son un paradigma de aprendizaje y procesamiento automático inspirado en la forma en que funciona el sistema nervioso de los animales. Se trata de un sistema de interconexión de neuronas que colaboran entre sí para producir un estímulo de salida.
Paradigmas de modelados:
Los paradigmas pueden ser descritos desde una perspectiva estructural. Operan en diferentes niveles: macro, meso y micro de la estructura paradigmática. Los niveles direccionan mejor la estructura fundamental de los paradigmas, y no tanto su categorización cronológica o histórica, ni su uso etimológico;
Nivel Macro: Se requiere conocer la respuesta a "qué puede ser entendido". La pregunta es: ¿Puede asumirse en realidad que la esencia de las cosas ideales puede ser comprendida, como en la teoría de las ideas de Platón y Aristóteles? ¿Tras la aproximación a lo esencial de estos dos filósofos no es posible inferir que "las mismas cosas se revelan como son, según se analiza en la ontología fundamental de Heidegger? La suposición que hacemos al contestar estas preguntas nos predispone a una determinada forma de encarar el proceso de conocimiento.
Nivel meso: La cuestión es determinar cómo el nivel macro influencia y transforma la teoría del conocimiento resultante: ¿El hombre es capaz solamente de un limitado conocimiento deductivo, o está abierto a un entendimiento inductivo y comprehensivo del universo? ¿Si el hombre es capaz de un conocimiento inductivo, dónde se origina éste? La respuesta en el nivel macro es fundamental para esta suposición. Todos los esfuerzos filosóficos, desde antes de Sócrates, tienden al esencialismo.
Nivel micro: Aquí la consecuente percepción de los dos niveles precedentes, contestando las preguntas sobre qué hay en el universo y cómo éste puede ser comprendido, se pone en práctica. ¿La praxis se construye sobre múltiples normas de conducta o consiste en un encuentro abierto y fundamental con el universo según las diferentes formas de percepción? Las diferentes percepciones constituyen la "conciencia afectiva". El conocimiento previo y actual de la percepción está limitado a las categorías esenciales, mientras que la conciencia afectiva es por naturaleza abierta, ilimitada, inductiva y no restringida por el sentido de la percepción.
Patrones de Diseño:
Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.
Un patrón de diseño resulta ser una solución a un problema de diseño. Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.
Los patrones de diseño pretenden:
Ø Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
Ø Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
Ø Formalizar un vocabulario común entre diseñadores.
Ø Estandarizar el modo en que se realiza el diseño.
Ø Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.
Asimismo, no pretenden:
Ø Imponer ciertas alternativas de diseño frente a otras.
Ø Eliminar la creatividad inherente al proceso de diseño.
No es obligatorio utilizar los patrones, solo es aconsejable en el caso de tener el mismo problema o similar que soluciona el patrón, siempre teniendo en cuenta que en un caso particular puede no ser aplicable. "Abusar o forzar el uso de los patrones puede ser un error".
Algunos patrones de diseño habituales son:
Patrones creacionales:
· Object Pool: Se obtienen objetos nuevos a través de la clonación. Utilizado cuando el costo de crear una clase es mayor que el de clonarla. Especialmente con objetos muy complejos. El proceso de clonación se inicia instanciando un tipo de objeto de la clase que queremos clonar.
· Abstract Factory (fábrica abstracta): Permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre sí y haciendo transparente el tipo de familia concreta que se esté usando.
· Builder (constructor virtual): Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto.
· Factory Method (método de fabricación): centraliza en una clase constructora la creación de objetos de un subtipo de un tipo determinado, ocultando al usuario la casuística, es decir, la diversidad de casos particulares que se pueden prever, para elegir el subtipo que crear.
· Prototype (prototipo): crea nuevos objetos clonándolos de una instancia ya existente.
· Singleton (instancia única): garantiza la existencia de una única instancia para una clase y la creación de un mecanismo de acceso global a dicha instancia.
Patrones estructurales:
· Adapter o Wrapper (Adaptador o Envoltorio): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podría utilizarla.
· Bridge (Puente): Desacopla una abstracción de su implementación.
· Composite (Objeto compuesto): Permite tratar objetos compuestos como si de uno simple se tratase.
· Decorator (Decorador): Añade funcionalidad a una clase dinámicamente.
· Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema.
· Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos poseen idéntica información.
· Proxy: Mantiene un representante de un objeto.
· Módulo: Agrupa varios elementos relacionados, como clases, singletons, y métodos, utilizados globalmente, en una entidad única.
Patrones de comportamiento:
· Chain of Responsibility (Cadena de responsabilidad): Permite establecer la línea que deben llevar los mensajes para que los objetos realicen la tarea indicada.
· Command (Orden): Encapsula una operación en un objeto, permitiendo ejecutar dicha operación sin necesidad de conocer el contenido de la misma.
· Interpreter (Intérprete): Dado un lenguaje, define una gramática para dicho lenguaje, así como las herramientas necesarias para interpretarlo.
· Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementación de estos.
· Mediator (Mediador): Define un objeto que coordine la comunicación entre objetos de distintas clases, pero que funcionan como un conjunto.
· Memento (Recuerdo): Permite volver a estados anteriores del sistema.
· Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automáticamente todos los objetos que dependen de él.
· State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno.
· Strategy (Estrategia): Permite disponer de varios métodos para resolver un problema y elegir cuál utilizar en tiempo de ejecución.
· Template Method (Método plantilla): Define en una operación el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura.
· Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarquía de clases sin modificar las clases sobre las que opera.
LOS LDA (LENGUAJES DESCRIPTIVOS DE ARQUITECTURA)
Criterios de definición de un ADL
Los ADLs se remontan a los lenguajes de interconexión de módulos (MIL) de la década de 1970, pero se han comenzado a desarrollar con su denominación actual a partir de 1992 o 1993, poco después de fundada la propia arquitectura de software como especialidad profesional.
Los lenguajes de descripción de arquitecturas, ocupan una parte importante del trabajo arquitectónico desde la fundación de la AS. Ya que contando con un ADL, un arquitecto puede razonar sobre las propiedades del sistema con precisión, pero a un nivel de abstracción convenientemente genérico. Algunas de esas propiedades podrían ser, por ejemplo, protocolos de interacción, anchos de banda y latencia, localización del almacenamiento, conformidad con estándares arquitectónicos y previsiones de evolución ulterior del sistema.
La definición más simple es la de Tracz [Wolf97] que define un ADL como una entidad consistente en cuatro “Cs”: componentes, conectores, configuraciones y restricciones (constraints). Una de las definiciones más tempranas es la de Vestal [Ves93] quien sostiene que un ADL debe modelar o soportar los siguientes
conceptos:
Ø Componentes
Ø Conexiones
Ø Composición jerárquica, en la que un componente puede contener una sub-arquitectura completa
Ø Paradigmas de computación, es decir, semánticas, restricciones y propiedades no funcionales
Ø Paradigmas de comunicación
Ø Modelos formales subyacentes
Ø Soporte de herramientas para modelado, análisis, evaluación y verificación
Ø Composición automática de código aplicativo
Basándose en su experiencia sobre Rapide, Luckham y Vera [LV95] establecen como requerimientos:
Ø Abstracción de componentes
Ø Abstracción de comunicación
Ø Integridad de comunicación (sólo los componentes que están conectados pueden comunicarse)
Ø Capacidad de modelar arquitecturas dinámicas
Ø Composición jerárquica 7
Ø Relatividad (o sea, la capacidad de mapear o relacionar conductas entre arquitecturas)
Tomando como parámetro de referencia a UniCon, Shaw y otros [SDK+95] alegan que un ADL debe exhibir:
Ø Capacidad para modelar componentes con aserciones de propiedades, interfaces e implementaciones
Ø Capacidad de modelar conectores con protocolos, aserción de propiedades e implementaciones
Ø Abstracción y encapsulamiento
Ø Tipos y verificación de tipos
Ø Capacidad para integrar herramientas de análisis
Otros autores, como Shaw y Garlan [SG94] estipulan que en los ADLs los conectores sean tratados explícitamente como entidades de primera clase (lo que dejaría al margen de la lista a dos de ellos al menos) y han afirmado que un ADL genuino tiene que proporcionar propiedades de composición, abstracción, reusabilidad, configuración, heterogeneidad y análisis, lo que excluiría a todos los lenguajes convencionales de programación y a los MIL.
Conociendo la importancia de los ADL, se podría pensar que existe gran número de ellos, y que son utilizados para el modelado de toda arquitectura de software, sin embargo, contrario a lo que se piensa, no existen tantas herramientas de modelado de arquitectura, existen en el mundo alrededor de unos veinte ADL de primera magnitud y quizás una cifra mayor propuestos en ponencias pero que no han resistido el paso del tiempo o que no han encontrado su camino en el mercado.
No hay comentarios.:
Publicar un comentario