Sei sulla pagina 1di 18

2014

Evidencia de Aprendizaje

UNIDAD 1
CARLOS PINEDA LUNA
26-3-2014

CPL

1. Identifica y describe los diferentes lenguajes descriptores de arquitectura y agrega la utilidad que tiene.

Arquitectura Acme

Descripcin Acme se define como una herramienta capaz de soportar el mapeo de especificaciones arquitectnicas 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.
Es una aplicacin de una especificacin ms abstracta y genrica, xArch, que es un lenguaje basado en XML, elaborado en Irvine y Carnegie Mellon para la descripcin de arquitecturas, est siendo promovido desde el ao 2000 por The Open Group y fue desarrollado originalmente en MCC. 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 exploracin de las bases formales de la arquitectura de software, el desarrollo del concepto de estilo arquitectnico y la produccin de herramientas tiles a la arquitectura, de las cuales Aesop es precisamente la ms relevante. La elaboracin 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

ADML

Utilidad La motivacin fundamental de Acme es el intercambio entre arquitecturas e integracin de ADLs. Con un ADL, un arquitecto puede razonar sobre las propiedades del sistema con precisin, pero a un nivel de abstraccin convenientemente genrico. Algunas de esas propiedades podran ser, por ejemplo, protocolos de interaccin, anchos de banda y latencia, localizacin del almacenamiento, conformidad con estndares arquitectnicos y previsiones de evolucin ulterior del sistema. Constituye un intento de estandarizar la descripcin de arquitecturas en base a XML. Constituye adems un tronco del que depende una cantidad de especificaciones ms puntuales. Mientras ADML todava reposaba en DTD (Document Type Definition), una sintaxis de metadata que ahora se estima obsoleta, las especificaciones ms nuevas implementan esquemas extensibles de XML
Es una herramienta para construir ambientes de diseo de software basada en principios de arquitectura. El ambiente de desarrollo de Aesop System se basa en el estilo de tubera y filtros propio de UNIX. Maneja toda una jerarqua de lenguajes especficos, y en particular FAM Command Language (FCL, a pronunciar como fickle), que a su vez es una extensin de TCL orientada a soportar modelado arquitectnico.

Aesop

CPL
explora el uso de estilos en el diseo arquitectnico [GAO94].

ArTek

ArTek fue desarrollado por Teknowledge. Se le conoce tambin como ARDEC/Teknowledge Architecture Description Language. En opinin de Medvidovic no es un genuino ADL, por cuanto la configuracin es modelada implcitamente mediante informacin de interconexin que se distribuye entre la definicin de los componentes individuales y los conectores. C2 o Chiron-2 no es estrictamente un ADL sino un estilo de arquitectura de software que se ha impuesto como estndar en el modelado de sistemas que requieren intensivamente pasaje de mensajes y que suelen poseer una interfaz grfica 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 cannica de este ltimo es DRADEL (Development of Robust Architectures using a Description and Evolution Language). CHAM (Chemical Abstract Machine) no es estrictamente un ADL, aunque algunos autores, en particular Inverardi y Wolf [BB92] aplicaron CHAM para describir la arqui tectura de un compilador. Se argumenta, en efecto, que CHAM proporciona una base til para la descripcin de una arquitectura debido a su capacidad de componer especificaciones para las partes y describir explcitamente las reglas de composicin.

Capacidad de modelar ciertos aspectos de una arquitectura

C 2 (C2 SADL, C2SADEL, xArch, xADL)

Los conectores trasmiten mensajes entre componentes, los cuales mantienen el estado, ejecutan operaciones e intercambian mensajes con otros componentes a travs de dos interfaces (llamadas top y bottom).

CHAM

Proporciona una base til para la descripcin de una arquitectura debido a su capacidad de componer especificaciones para las partes y describir explcitamente las reglas de composicin

CPL
Darwin
Darwin es un lenguaje de descripcin arquitectnica desarrollado por Jeff Magee y Jeff Kramer [MEDK95, MK96]. Darwin describe un tipo de componente mediante una interfaz consistente en una coleccin 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 vnculos entre ambas clases de servicios

2. Identifica y describe los patrones de arquitectura y agrega la utilidad que tienen.

Programacin por capas La programacin por capas es una arquitectura cliente-servidor en el que el objetivo primordial es la separacin de la lgica de negocios de la lgica de diseo; un ejemplo bsico de esto consiste en separar la capa de datos de la capa de presentacin al usuario.

La programacin por capas es una tcnica de la ingeniera del software propia de la programacin a objetos, que se divide en 3 capas: la capa de presentacin o frontera, la capa de lgica de negocio y por ltimo la capa de datos.

CPL

1. Capa de presentacin:

Se refiere a la presentacin del programa frente al usuario, esta presentacin debe cumplir su propsito con el usuario final, una presentacin fcil de usar y amigable. Tambin las interfaces deben ser consistentes con la informacin dentro del software (Por ejemplo; en los formularios no debe haber ms que lo necesario), tomar en cuenta los requerimientos del usuario, la capa de presentacin va de la mano con capa de la lgica de negocio. Es la que ve el usuario (tambin se la denomina "capa de usuario"), presenta el sistema al usuario, le comunica la informacin y captura la informacin del usuario en un mnimo de proceso (realiza un filtrado previo para comprobar que no hay errores de formato). Tambin es conocida como interfaz grfica y debe tener la caracterstica de ser "amigable" (entendible y fcil de usar) para el usuario. Esta capa se comunica nicamente con la capa de negocio. 2. Capa lgica de negocio:

En esta capa es donde se encuentran los programas que son ejecutados, recibe las peticiones del usuario y posteriormente enva las respuestas tras el proceso. Esta capa es muy importantes pues es donde se establecen todas aquellas reglas que se tendrn que cumplir, deca anteriormente que la capa de presentacin tiene comunicacin con la capa de lgica de negocio ya que se tienen que comunicar para recibir las solicitudes y presentar los resultados.

CPL

Es donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envan las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lgica del negocio) porque es aqu donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentacin, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos almacenar o recuperar datos de l. Tambin se consideran aqu los programas de aplicacin. Capa de datos:

Esta capa es la que se encarga de hacer las transacciones con la base de datos y con otros sistemas para descargar o insertar informacin al sistema. La consistencia en los datos es sumamente importante, es decir, los datos que se ingresan o insertan deben ser precisos y consientes. Aqu definimos las consultas que vamos a realizar en la base de datos, o consultas para reporteo. La comunicacin de esta capa con la capa de lgica de negocio se refiere a que la capa de datos es la que le enviara informacin a la capa de negocio para que sea procesada e ingresada en objetos segn sea necesario (encapsulamiento).
Es donde residen los datos y es la encargada de acceder a los mismos. Est formada por uno o ms gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperacin de informacin desde la capa de negocio. Arquitectura en pizarra La arquitectura en pizarra consta de mltiples elementos funcionales, denominados agentes, y un instrumento de control denominado pizarra. Los agentes suelen estar especializados en una tarea concreta o elemental. Todos ellos cooperan para alcanzar una meta comn, si bien, sus objetivos individuales no estn aparentemente coordinados. El comportamiento bsico de cualquier agente consiste en examinar la pizarra, realizar su tarea y escribir sus conclusiones en la misma pizarra. De esta manera, otro agente puede trabajar sobre los resultados generados por otro. La computacin termina cuando se alcanza alguna condicin deseada entre los resultados escritos en la pizarra.

CPL
Esta arquitectura es tremendamente til cuando el problema a resolver (o algoritmo a implementar) es extremadamente complejo en trminos cognitivos. Es decir, cuando el flujo de control del algoritmo es enrevesado, o simplemente, no se tiene un conocimiento completo del problema a resolver. Las desventajas de la arquitectura son bastante obvias a priori. Es importante no generalizar en este aspecto, puesto que cada implementacin en particular puede solventar estas desventajas en algn mbito limitado: No existe garanta de que se alcanzar una solucin. Es una arquitectura ineficiente, puesto que no existe una cota respecto al tiempo de cmputo necesario para resolver el problema. Es difcil obtener una traza de los pasos que llevaron a la solucin, es decir, no ofrece explicaciones.

Arquitectura dirigida por eventos La Arquitectura dirigida por eventos, Event-driven architecture o EDA, es un patrn de arquitectura software que promueve la produccin, deteccin, consumo de, y reaccin a eventos. Un evento puede ser definido como "un cambio significativo en un estado". Por ejemplo, cuando un consumidor compra un coche, el estado del coche pasa de "se vende" a "vendido". La arquitectura del sistema del vendedor de coches debe tratar este cambio de estado como un evento, cuyo suceso puede ser conocido en otras aplicaciones en la arquitectura. Desde una perspectiva formal, lo que es producido, publicado, propagado, detectado o consumido es un mensaje (tpicamente asncrono) llamado notificacin del evento, y no el evento en s mismo, el cul es el cambio de estado que dispar la emisin del evento. Los eventos no viajan, solamente ocurren.

Peer-to-peer Una red peer-to-peer, red de pares, red entre iguales, red entre pares o red punto a punto (P2P, por sus siglas en ingls) es una red de computadoras en la que todos o algunos aspectos funcionan sin clientes ni servidores fijos, sino una serie de nodos que se comportan como

CPL
iguales entre s. Es decir, actan simultneamente como clientes y servidores respecto a los dems nodos de la red. Las redes P2P permiten el intercambio directo de informacin, en cualquier formato, entre los ordenadores interconectados. Normalmente este tipo de redes se implementan como redes superpuestas construidas en la capa de aplicacin de redes pblicas como Internet. El hecho de que sirvan para compartir e intercambiar informacin de forma directa entre dos o ms usuarios ha propiciado que parte de los usuarios lo utilicen para intercambiar archivos cuyo contenido est sujeto a las leyes de copyright, lo que ha generado una gran polmica entre defensores y detractores de estos sistemas. Las redes peer-to-peer aprovechan, administran y optimizan el uso del ancho de banda de los dems usuarios de la red por medio de la conectividad entre los mismos, y obtienen as ms rendimiento en las conexiones y transferencias que con algunos mtodos centralizados convencionales, donde una cantidad relativamente pequea de servidores provee el total del ancho de banda y recursos compartidos para un servicio o aplicacin. Dichas redes son tiles para diversos propsitos. A menudo se usan para compartir ficheros (archivos) de cualquier tipo (por ejemplo, audio, vdeo o software). Este tipo de red tambin suele usarse en telefona VoIP para hacer ms eficiente la transmisin de datos en tiempo real.

Arquitectura orientada a servicios La 'Arquitectura Orientada a Servicios de cliente' (en ingls Service Oriented Architecture), es un concepto de arquitectura de software que define la utilizacin de servicios para dar soporte a los requisitos del negocio. Permite la creacin de sistemas de informacin altamente escalables que reflejan el negocio de la organizacin, a su vez brinda una forma bien definida de exposicin e invocacin de servicios (comnmente pero no exclusivamente servicios web), lo cual facilita la interaccin entre diferentes sistemas propios o de terceros. SOA define las siguientes capas de software: Aplicaciones bsicas - Sistemas desarrollados bajo cualquier arquitectura o tecnologa, geogrficamente dispersos y bajo cualquier figura de propiedad;

CPL
De exposicin de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente como servicios web); De integracin de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboracin; De composicin de procesos - Que define el proceso en trminos del negocio y sus necesidades, y que vara en funcin del negocio; De entrega - donde los servicios son desplegados a los usuarios finales.

SOA proporciona una metodologa y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integracin y consolidacin.

Modelo vista a controlador El Modelo Vista Controlador (MVC) es un patrn de arquitectura de software que separa los datos y la lgica de negocio de una aplicacin de la interfaz de usuario y el mdulo encargado de gestionar los eventos y las comunicaciones. Para ello MVC propone la construccin de tres componentes distintos que son el modelo, la vista y el controlador, es decir, por un lado define componentes para la representacin de la informacin, y por otro lado para la interaccin del usuario. Este patrn de diseo se basa en las ideas de reutilizacin de cdigo y la separacin de conceptos, caractersticas que buscan facilitar la tarea de desarrollo de aplicaciones y su posterior mantenimiento.

3.- Elabora ejemplos de uso de la combinacin de lenguajes y patrones y describe cada ejemplo (mnimo 2).
El ejemplo muestra la definicin de una tubera en Darwin [MK96: 5].
component pipeline ( int n) { provide input;

CPL
require output; array F[n]:filter; forall k:0..n-1 { inst F[k]; bind F[k].output -- output; when k<n-1 bind F[k].next -- F[k+1].prev; } bind input -- F[0].prev; F[n-1].next -- output; }

Rapide establece tres clases de conexiones; el conector correspondiente a una conexin de tipo pipe es =>
type Producer (Max : Positive) is interface action out Send (N: Integer); action in Reply(N : Integer); behavior Start => send(0); (?X in Integer) Reply(?X) where ?X<Max => Send(?X+1); end Producer; type Consumer is interface action in Receive(N: Integer); action out Ack(N : Integer); behavior (?X in Integer) Receive(?X) => Ack(?X); end Consumer architecture ProdCon() return SomeType is Prod : Producer(100); Cons : Consumer; connect (?n in Integer) Prod.Send(?n) => Cons.Receive(?n); Cons.Ack(?n) => Prod.Reply(?n); end architecture ProdCon;

El siguiente ejemplo muestra un modelo completo de tubera y filtro en UniCon, definiendo un primer filtro para procesamiento primario y un segundo para eliminacin de vocales:

CPL

COMPONENT System INTERFACE is TYPE Filter PLAYER input IS StreamIn SIGNATURE (line) PORTBINDING (stdin) END input PLAYER output IS StreamOut SIGNATURE (line) PORTBINDING (stdout) END output PLAYER error IS StreamOut SIGNATURE (line) PORTBINDING (stderr) END error END INTERFACE IMPLEMENTATION IS USES C INTERFACE CatFile USES R INTERFACE RemoveVowels USES P PROTOCOL Unix-pipe BIND input TO C.input BIND output TO R.output BIND C.error TO error BIND R.error TO error BIND P.err to error CONNECT C.output TO P.source CONNECT P.sink to R.input END IMPLEMENTATION END System COMPONENT CatFile INTERFACE is TYPE Filter - - como antes sin binding a puertos END INTERFACE IMPLEMENTATION IS VARIANT CatFile IN catfile IMPLTYPE (Executable) END CatFile END IMPLEMENTATION END CatFile COMPONENT RemoveVowels INTERFACE is TYPE Filter - - como antes sin binding a puertos END INTERFACE IMPLEMENTATION IS VARIANT RemoveVowels IN remove IMPLTYPE (Executable)

CPL
END RemoveVowels END IMPLEMENTATION END RemoveVowels CONNECTOR Unix-pipe PROTOCOL IS TYPE Pipe ROLE source IS source MAXCONNS (1) END source ROLE sink IS sink MAXCONNS (1) END sink ROLE err IS sink MAXCONNS (1) END err END PROTOCOL IMPLEMENTATION IS BUILTIN END IMPLEMENTATION END Unix-Pipe

4.- Investiga la aplicacin de lenguajes y patrones que no se hayan presentado en el desarrollo de la unidad.
Patrones Estructurales 3. 4. 5. Adaptador (Adapter): Convierte una interfaz en otra. Puente (Bridge): Desacopla una abstraccin de su implementacin permitiendo modificarlas independientemente. Objeto Compuesto (Composite): Utilizado para construir objetos complejos a partir de otros ms simples, utilizando para ello la composicin recursiva y una estructura de rbol. 6. Envoltorio (Decorator): Permite aadir dinmicamente funcionalidad a una clase existente, evitando heredar sucesivas clases para incorporar la nueva funcionalidad. 7. Fachada (Facade): Permite simplificar la interfaz para un subsistema. 8. Peso Ligero (Flyweight): Elimina la redundancia o la reduce cuando tenemos gran cantidad de objetos con informacin idntica. 9. Apoderado (Proxy): Un objeto se aproxima a otro. 10. Cadena de responsabilidad (Chain of responsibility): La base es permitir que ms de un objeto tenga la posibilidad de atender una peticin. 11. Orden (Command): Encapsula una peticin como un objeto dando la posibilidad de deshacer la peticin. 12. Intrprete (Interpreter): Intrprete de lenguaje para una gramtica simple y sencilla.

CPL
13. Iterador (Iterator): Define una interfaz que declara los mtodos necesarios para acceder secuencialmente a una coleccin de objetos sin exponer su estructura interna. 14. Mediador (Mediator): Coordina las relaciones entre sus asociados. Permite la interaccin de varios objetos, sin generar acoples fuertes en esas relaciones. 15. Recuerdo (Memento): Almacena el estado de un objeto y lo restaura posteriormente. 16. Observador (Observer): Notificaciones de cambios de estado de un objeto. 17. Public Class Articulo 18. Delegate Sub DelegadoCambiaPrecio(ByVal unPrecio As Object) 19. Public Event CambiaPrecio As DelegadoCambiaPrecio 20. Dim _cambiaPrecio As Object 21. Public WriteOnly Property Precio() 22. Set(ByVal value As Object) 23. _cambiaPrecio = value 24. RaiseEvent CambiaPrecio(_cambiaPrecio) 25. End Set 26. End Property 27. End Class 28. Public Class ArticuloObservador 29. 30. Estado (Server): Se utiliza cuando el comportamiento de un objeto cambia dependiendo del estado del mismo. 31. Estrategia (Strategy): Utilizado para manejar la seleccin de un algoritmo. 32. Mtodo plantilla (Template Method): Algoritmo con varios pasos suministrados por una clase derivada.

Architectural Description Languages Carlos Reynoso* Nicols Kicillof Universidad de Buenos Aires * billyreyno@hotmail.com Agenda Ubicacin de ADLs en Arquitectura Estilos Definiciones de ADLs ADLs Short List Demo - Jacal Arquitectura Arquitectura de software - IEEE 1471-2000: ...la organizacin fundamental de un sistema encarnada en sus componentes, sus relaciones con cada uno de los otros y con el entorno, y los principios que orientan su diseo y evolucin.

CPL Estilos Flujo de datos Secuencial en lotes Red de flujo de datos (tuberas & filtros) Bucle de control cerrado Llamada y Retorno Programa principal / subrutinas Ocultamiento de informacin (ADT, objeto, cliente/servidor elemental) Procesos interactivos Procesos comunicantes Sistemas de eventos (invocacin implcita, eventos puros) Repositorio Orientado a Datos Bases de datos transaccionales (cliente/servidor genuino) Pizarra Compilador moderno Datos Compartidos Documentos compuestos Hipertexto Fortran COMMON Procesos LW Jerrquicos - En capas (intrpretes) ADLs Herramientas de modelado que soportan desarrollos basados en arquitecturas Estructura de alto nivel, no detalle de implementacin Poco consenso respecto a definicin de ADL, aspectos a considerar y adecuacin de ADLs a estilos Poca distincin entre ADL, especificacin formal, interconexin de mdulos (MIL), herramientas de modelado y hasta lenguajes de programacin Condiciones de ADLs Shaw y otros, 1995: Capacidad para modelar componentes con aserciones de propiedades, interfaces e implementaciones Capacidad de modelar conectores con protocolos, asercin de propiedades e implementaciones Abstraccin y encapsulamiento Tipos y verificacin de tipos Capacidad para integrar herramientas de anlisis Condiciones Componentes Conectores Configuraciones o sistemas Propiedades no funcionales Restricciones Estilos Evolucin Herramientas de verificacin Otras herramientas Lenguajes de especificacn (LARCH, Z) Lenguajes de prototipado (Modechart, PSDL) Lenguajes de modelado (UML) Lenguajes de programacin (CODE, Ada) Herramientas para definicin de ciclo de vida (UNAS/SALE) ADLs Acme / Armani Lenguaje de intercambio de arquitectura 1995, Carnegie Mellon Lenguaje Acme Acme Tool Developers Library (AcmeLib) 4 tipos de arquitectura Estructura, propiedades (comportamiento), restricciones, tipos y estilos Estructura: componentes, conectores, sistemas, puertos, roles, representaciones y rep-mapas Acme/Armani Semntica slo como comentario No genera cdigo Maneja estilos (familia) Varias herramientas en ambiente Windows: AcmeStudio Armani con front-end Visio ISI: front-end Powerpoint ADML: lenguaje de markup de arquitectura, derivado de Acme (estndar) Armani: ADL. Declarativo Acme Armani Acme/Armani

CPL ADML Open Group, 2000 ADML: XML con DTD xADL (Zaydal,UCI): Schemas para estilos (Aplicacin de xArch) xArch (UCI/Carnegie Mellon): lenguaje basado en XML para descripcin de arquitecturas Placeholder para implementaciones variables Aesop (1/4) Parte del proyecto ABLE de CMU (con Wright) Herramienta para construir ambientes de desarrollo que soporta Estilos Conjunto de estilos para definir nuevos diseos Design manager Interface grfica Basado en Tcl/Tk Corre por separado y puede reemplazarse por otros Tool integration framework: Incorporacin de otras herramientas (compiladores, herramientas de anlisis, etc) Repositorio para reutilizacin de patrones Semntica como comentario Aesop (2/4) Ontologa basada en 7 entidades Componentes Conectores Configuraciones Topologas de componentes y conectores Puertos Interfaces de componentes Roles Interfaces de conectores Representaciones Contenidos de componente o conector Bindi ngs Correspondencias entre configuracin externa o externa de puertas o roles Aesop (3/4) Requiere manejar diversos lenguajes FAM Command Language (FCL) Extensin de Tcl/Tk que soporta modelizacin arquitectnica, etc Los elementos de definen por herencia de tipos bsicos (componente, conector, etc) Actualmente corre sobre workstations Sun (SunOS) http://www.cs.cme.edu/Web/Groups/ABLE/Aesop El link para obtener Aesop parece no estar activo (enero/2004) Aesop Aesop (4/4) C2 SADL, C2SADEL C2 SADL (Simulation Architecture Description Language) ADL que permite describir arquitecturas en estilo C2 C2SADEL Variante. Incluye DRADEL (Development of Robust Architectures using a Description and Evolution Language) xArch, xADL: Inicialmente ligados a C2 C2 SADL, C2SADEL SADL Mdulos declarativos e imperativos 1) IDN Interface Description Notation 2) ADN Architecture Description Notation 3) ACN Architecture Construction Notation Windows: DRADEL (Int. Para C2SADEL) SAAGE (requiere Rose o Dradel) ArchStudio Argo (discontinuado) SADL IDN, ADN C2

CPL CHAM Chemical Abstract Machine Tcnica de especificacin basada en lgebra de procesos Molculas (componentes bsicos) Soluciones de molculas (multiconjuntos que definen estados) Reglas de transformacin (cambios de estado) No determinismo si hay + de una regla para una molcula o solucin CHAM Ejemplo de compilador Lisp CHAM Darwin (1/2) ADL orientado a arquitecturas dinmicas Descripcin de tipo de componente mediante interfaz Interfaz: coleccin de servicios (a) provistos [declarados por componente], o (b) requeridos [presentes en el entorno] Desarrollo consiste en instanciar declaraciones de componentes y establecer relaciones entre servicios Soporta reconfiguracin dinmica e instanciacin tarda Darwin (2/2) Las propiedades de un componente son slo comentarios No hay soporte real de estilos: slo se pueden expresar constructivamente (construyendo algoritmos que representen los miembros) Semntica basada en clculo Pi Interfaz grfica: Software Architects Assistant, discontinuado Darwin Darwin Jacal (1/2) Jacal (2/2) LILEANNA Navegacin de helicpteros, Loral Federal Systems / ARPA No es ADL en sentido estricto La estructura se modela distribuyendo informacin entre la definicin de componentes individuales y conectores Es un lenguaje de interconexin de mdulos (MIL, MCL) Utiliza Ada para implementacin y Anna para especificacin MetaH / AADL (1/2) Gua, navegacon y control aeronutico MetaH: Base textual para AADL (Avionics) No confundir con Axiomatic [diseo computadoras paralelas] Windows: MetaH Graphical Editor basado en DoME MetaH / AADL (2/2) Rapide (1/2) Lenguaje de descripcin de propsito general Modelado de interfaces de componentes y conductas observables (Stanford) ADL + lenguaje de simulacin 5 lenguajes: de tipos (interfaces de componentes); de arquitectura (flujo de eventos); de

CPL especificacin (restricciones abstractas de conducta); ejecutable (describe mdulos ejecutables); de patrones (describe patrones de eventos) Modela conducta (= Wright) Genera cdigo C++ o Ada Rapide (2/2) Define tipos de componentes llamados interfaces: colecciones de eventos de comunicacin que pueden ser (a) observados (acciones externas) o (b) iniciados (acciones pblicas) El comportamiento se define vinculando observacin de acciones externas con iniciacin de acciones pblicas Cada especificacin posee conducta asociada que se define mediante conjuntos de eventos parcialmente ordenados (posets) Tambin descripcin de comportamientos con lenguaje basado en SML, con eventos y patrones de eventos Medvidovic: simulacin verifica una arquitectura, pero no un escenario (un poset distinto) Toolset disponible para Sun, Linux, etc No evoluciona desde 1997 Rapide UML No es un ADL Deficiencias como lenguaje de especificacin [estereotipos] Deficiencias en torno de roundtrip engineering [metamodelos] Ej: Asociacin Agregacin - Composicin Se ha usado como metalenguaje para implementar semntica de C2 SADL o Wright UniCon (1/2) Universal Connector Support, Shaw et al, 1995 Proyecto Vitruvius, CMU Herramienta de diseo para construir configuraciones ejecutables Tipos de componentes, implementaciones y conexiones expertas Orientado a construir sistemas a partir de descripciones arquitectnicas Sitio muerto desde hace un tiempo UniCon UniCon (2/2) No posee recursos de descripcin de estilos Los puntos de interfaz de componente (players) tienen (1) tipo que detalla la interaccin esperada, (2) propiedades que detallan la interaccin En momento de configuracin, se asocian players de componentes con roles de conectores Slo tiene un conjunto limitado de tipos (= Darwin) Omitimos cdigo de definicin de pipe-filter por ser casi tan extenso como el de un modelo en lenguaje de implementacin Wright (1/2) Herramienta de formalizacin de conexiones arquitectnicas, CMU (parte de proyecto ABLE) ABLE: herramienta de diseo (Aesop), especificacin formal (Wright) Integracin de metodologa formal con descripciones arquitectnicas Aplica procesos formales (lgebra de proceso y refinamiento de proceso) a verificacin automatizada de propiedades de arquitectura Wright (2/2) Declara conjunto de tipos de componentes y conectores y conjunto de restricciones Modelo semntico basado en CSP (Communicating Sequential Process de Hoare) Verificacin mediante verificador comercial FDR Restricciones: predicado que debe ser satisfecho por cualquier configuracin que se declare miembro del estilo Notacin de restricciones: clculo de predicados de primer orden Sub-estilos: heredan de estilos No posee interfaz grfica nativa No genera cdigo ejecutable Wright

CPL Modelos formales Darwin: clculo Pi Wright: CSP, lgica de primer orden LILEANNA: programacin parametrizada e hiperprogramacin Rapide: Posets SAM: Redes de Petri de transicin de predicados, lgica temporal de primer orden Jacal: Redes de Petri Casi todos los ADLs tienen BNF Modelo estructural no ligado a OO

Cibergrafa: www.carlosreynoso.com.ar/archivos/arquitectura/ADL.PDF http://www.slideboom.com/presentations/102549/Carlos-Reynoso---Lenguajes-de-descripci%C3%B3n-de-arquitectura-de-software http://es.wikipedia.org/wiki/Programaci%C3%B3n_por_capas

http://www.codejobs.biz/es/blog/2014/01/28/la-programacion-por-capas#sthash.Tpz48gzF.dpuf http://www.codejobs.biz/es/blog/2014/01/28/la-programacion-por-capas#sthash.Tpz48gzF.dpbs

Potrebbero piacerti anche