DRS_U1_EA_REAG

Diseño y arquitectura de Software

Universidad abierta y a distancia de México

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

Lenguajes descriptores de arquitectura ADL Lenguaje ACME

Descripción

Características

Se define como una herramienta capaz de soportar el mapeo de especificaciones arquitectónicas entre diferentes ADL

AESOP

Su objetivo es explorar 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.

ARTEK

Se lo conoce también como ARDEC/Teknowledge Architecture Description Language.

ADML

El propósito de ADML (Architecture Description Markup Language) es estandarizar la descripción de arquitecturas en base a XML, de modo que pueda ser leída por cualquier parser de XML.

CHAM

Proporciona la base para la Descripción de una arquitectura debido a su capacidad de componer especificaciones para las partes y describir explícitamente las reglas de composición.

1. 2.

Fecha de aparición

Desarrolladores

Utilidad

Intercambio arquitectural Plataforma extensible de herramientas de arquitectura Descripción de arquitecturas

1995

Monroe & Garlan (CMU), Wile (USC)

Sirve como lenguaje de intercambio de arquitectura.

Se describe mediante la definición de subtipos de los tipos arquitectónicos básicos: Componente, Conector, Puerto, Rol, Configuración y Binding 2. Los puntos de interfaz se llaman puertos ( ports ports). 3. Sólo soporta nativamente desarrollos realizados en C++. 4. Genera código C++. 1. Tiene la capacidad de modelar ciertos aspectos de una arquitectura. 2. Puede generarse un modelo a partir de una instancia particular de uso. Permite definir vínculos con objetos externos a la arquitectura (fundamentación racional, diseños, componentes, etc.), 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, RosettaNet o similares. 1. CHAM es un modelo de máquina abstracta independiente de plataforma y del lenguaje o paradigma de programación que se vaya a utilizar en el sistema que se modela.

1994

Garlan (CMU)

Es una herramienta para construir ambientes de diseño de software basada en principios de arquitectura.

1994

Terry, Hayes-Roth, Erman (Teknowledge, DSSA)

Lenguaje específico de dominio - No es ADL

2000

The Open Architectural Framework

Vincular descripciones arquitectónicas y modelos directamente con cualquier binario, scripting o entidad en cualquier plataforma y en cualquier lenguaje.

1990

Berry / Boudol

3. 1.

Group

Lenguaje especificación

de

Diseño y arquitectura de Software Lenguaje DARWIN

C2 SADL

Jacal

LILEANNA

Descripción 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. 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. El objetivo principal de Jacal es “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. Cuenta con una representación gráfica que permite a simple vista transmitir la arquitectura del sistema, sin necesidad de recurrir a información adicional.

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.

Universidad abierta y a distancia de México Características

1.

Soporta la descripción de arquitecturas que se reconfiguran dinámicamente a través de dos construcciones. 2. Cada servicio de Darwin se modeliza como un nombre de canal, y cada declaración de binding es un proceso que trasmite el nombre del canal al componente que requiere el servicio.

Fecha de aparición

Desarrolladores

Utilidad

1991

Magee, Dulay, Eisenbach, Kramer

ADL con dinámica

Los mensajes de requerimiento sólo se pueden enviar “hacia arriba” en la arquitectura, y los de notificación sólo “hacia abajo”. La comunicación es a través de MENSAJES.

1996

Taylor/Medvidovic (UCI)

ADL específico de estilo

Puede ser utilizado para expresar arquitecturas de distintos estilos. Cada componente cuenta con puertos (ports) que constituyen su interfaz y a los que pueden adosarse conectores.

1997

Kicillof , Yankelevich (Universidad de Buenos Aires)

ADL - Notación de alto nivel para descripción y prototipado

1. Soporta diferentes estilos de comunicación, tales como variables compartidas, tuberías, paso de mensajes y blackboarding. 3. Mediante un sistema auxiliar llamado TOOR, se hace el rastreo (tracing) de dependencias entre objetos potencialmente evolutivos y relaciones entre objetos en función del tiempo.

1993

Tracz (Loral Federal)

Lenguaje de conexión de módulos

1.

2.

1. 2.

énfasis

en



Lenguaje

Descripción

Características

Fecha de aparición

Desarrolladores

Utilidad

MetaH

MetaH modela arquitecturas en los dominios de guía, navegación y control (GN&C) y en el diseño aeronáutico. 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. 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.

4.

MetaH está exclusivamente ligado a desarrollos hechos en Ada en el dominio de referencia.

1993

Binns, Englehart (Honeywell)

ADL específico dominio

1. En Rapide los puntos de interfaz de los componentes se llaman constituyentes. 2. En Rapide (al igual que en Darwin) no es posible poner nombre, sub-tipear o reutilizar un conector.

1990

Luckham (Stanford)

ADL & simulación

1995

Shaw (CMU)

ADL de propósito general, énfasis en conectores y estilos

1994

Garlan (CMU)

ADL de propósito general, énfasis en comunicación

Rapide

UniCon

1.

2.

3.

Wright

Es una herramienta de formalización de conexiones arquitectónicas.

4. 1. 2. 3.

El propósito de UniCon es generar código ejecutable a partir de una descripción, a partir de componentes primitivos adecuados. Capacidad de manejo de métodos de análisis de tiempo real a través de RMA (Rate Monotonic Analysis). Proporciona medios para describir o delinear familias de sistemas o estilos. Soporta notación gráfica. En Wright (igual que en Acme y Aesop) los puntos de interfaz se llaman puertos (ports). Permite modelar la conducta de sus componentes. Permite analizar los conectores para verificar que no haya deadlocks.

de

¿Qué es un lenguaje descriptor de Arquitectura Software? Es un lenguaje que ayuda a abstraer, conceptualizar modelar y concretar de una manera más amplia y optima un software, esto lo hace a través de las herramientas, los modelos y los patrones para aplicar estas en su desarrollo o construcción. En la comunidad de ingeniería de sistemas, una arquitec tura Description Language es un lenguaje y/o el modelo conceptual utiliz ado para describi r y representar arquitecturas de sistemas. En la comunidad de ingeniería de software, una arquitectura Description Language es un lenguaje de programación utilizado para crear una descripción de una arquitectura de software. Esto significa en el caso de la arquitectura técnica, la arquitectura debe ser comunicada a los desarrolladores de software. Con una arquitectura funcional, la arquitectura de software se comunica con las partes interesadas y los ingenieros de la empresa. Por la comunidad de ingeniería de software varias AVD se han desarrollado, como Acme, AADL, C2, Darwin, y Wright.



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

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 es 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 reusable, lo que significa que es aplicable a diferentes problemas de diseño en circunstancias parecidas. Estableciendo patrones de diseño, se hace más fácil construir soluciones específicas que tienen determinadas estructuras o piezas en común, reutilizando al mismo tiempo experiencias adquiridas.

Objetivos de los patrones 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 d e los patrones puede ser un err or".



Descripción de un patrón Los siguientes tópicos describen las secciones de un patrón de arquitectura. Sección

Descripción

Nombre

Nombre descriptivo que identifica al patrón

Clasificación

Clasificación del patrón que permita focalizar su orientación a la solución de una determinada área de problemas

Intención

Breve descripción del objetivo para el cuál se crea el patrón (problema que pretende resolver)

También conocido como

Otros nombres por los cuáles se conoce al patrón

Motivación

Escenario de ejemplo de uso del patrón

Aplicabilidad

Usos comunes y criterio de aplicabilidad del patrón

Estructura

Representación gráfica del patrón: todos sus componentes y las relaciones entre ellos

Componentes

Lista de componentes o recursos que intervienen en el patrón

(Participantes)

y sus roles en el diseño así como los enlaces a sus respectivas documentaciones en el caso que sean componentes de arquitectura en uso


Colaboraciones


Descripción de las interacciones entre los diversos componentes del patrón

Consecuencias

Descripción de los resultados, efectos colaterales o compensaciones causadas por el uso del patrón (consecuencias positivas y negativas de su uso)

Implementación

Descripción de la implementación del patrón (técnicas y comentarios oportunos para poder llevarlo a la realidad)

Código de ejemplo

Código fuente asociado a la implementación del patrón

Usos conocidos

Lista de casos reales de implementación del patrón

Patrones relacionados

Otros patrones que tienen relación con el patrón así como diferencias con patrones similares



BlackBoard 





 

Es una aplicación de inteligencia artificial basada en una base común de conocimientos llamada el pizarrón. A partir de la especificación de un problema se plantea la solución. Cada sistema experto envía a la pizarra una posible solución. Si la solución es aplicable queda como un bo rrador. Cada sistema experto interactúa con el borrador hasta hallar una solución final.

Cliente-Servidor 









Se tiene una máquina cliente, que requiere un servicio de una máquina servidor, y éste realiza la función para la que está programado. El sistema queda distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. Los servicios se separan situándolos en su plataforma más adecuada. Esto permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma. En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio).



Front-End, Back-End 







Front-End.- Es la parte del software que interactúa con los usuarios Back-End.- Es la parte que procesa la entrada de datos proveniente del Front-End El Front-End es responsable de recolectar los datos de entrada y los procesa conforme a las especificaciones del Back-End para que este las pueda utilizar. La conexión del Frot-End y el Back-End es de tipo interface ya sea de manera física o virtual.

Computo Distribuido 





Las computadoras interactúan entre sí, para lograr un objetivo en común. Utiliza un gran número de computadoras organizado en racimos por medio de una estructura de telecomunicaciones. Cada usuario comparte tiempo de procesamiento de su máquina para manejar grandes volúmenes de información.



Monolítico   

 

Tres capas 

 



Cada capa está separada, únicamente puede comunicarse con la siguiente capa. Es la más utilizada debido a su escalabilidad y flexibilidad La interfaz del usuario, la lógica funcional del proceso, almacenamiento de datos y acceso a los datos son desarrollados y mantenidos como módulos independientes comúnmente en plataformas separadas. Permite que cualquiera de sus capas sea reemplazada sin afectar a las demás.

Toda la estructura y grupo funcional está en un mismo lugar. Existen interfaces gráficas de usuario (GUI). Servicios de presentación, negocio y persistencia en la misma máquina. No hay concurrencia de usuarios. Alto acoplamiento entre niveles.



4. Elabora ejemplos de uso de la combinación de lenguajes y patrones y describe cada ejemplo (mínimo 2).

Caso 1 PATRONES DE DISEÑO EN EL DESARROLLO SOFTWARE En el desarrollo software el patrón de diseño describe las clases y objetos que se comunicarán entre sí de manera que puedan resolver un problema general de diseño en un contexto particular. En un contexto informático un patrón de diseño es similar a conceptos como biblioteca de clases, frameworks, técnicas y/ herramientas de refactorización o programación extrema. La clasificación de los patrones de diseño en este contexto atiende a dos características como son:

Atendiendo a su propósito   

Creacionales: Resuelven problemas relativos a la creación de objetos Estructurales: Resuelven problemas relativos a la composición de objetos De Comportamiento: Resuelven problemas relativos a la interacción entre objetos.

Atendiendo a su ámbito  

Clases: Relaciones estáticas entre clases Objetos: Relaciones dinámicas entre objetos

Un ejemplo de lo que podría constituir un patrón de diseño aplicado a un contexto informático podría ser el siguiente:  

 

  

Nombre: Retroalimentación visual de navegación directa. Problema: El usuario tiene dificultades para acceder directamente a las ventanas del sistema informático y desconoce cuál de entre ellas es la ventana actual de trabajo. Principio de usabilidad: Guiar al usuario y dar el control de la interacción al usuario. Contexto: Dada una gran cantidades de información facilitar al usuario los medios para navegar directamente entre las ventanas del sistema informático. Fuerza: El sistema debe siempre mostrar la lista de ventanas navegables. Solución: Permitir al usuario a seleccionar directamente las ventana de la interfaz y mostrar continuamente la ventana activa y desactivas. Consecuencias: El acceso directo a las ventanas del sistema no solo beneficia la manipulación directa de ellas sino también la manipulación de los objetos que retienen ya que cada ventana es definida en términos de sus objetos de interacción (e.g. iconos, ítems de menú, radio botones) los cuales permiten la adquisición y la restitución de información que requiere el usuario Fuente: RED. Revista de Educación a Distancia. Número especial dedicado a Patrones de eLearning y Objetos de Aprendizaje Generativo. http://www.um.es/ead/red/M10/



Caso 2 LENGUAJES DE PATRÓN El lenguaje de patrón se define como "La especificación de una serie de elementos (patrones) y sus relaciones (con otros patrones) de modo que nos permiten describir buenas soluciones a los diferentes problemas que aparecen en un contexto específico." Si bien notaciones como UML o los diagramas de flujo ayudan a explicar un determinado patrón, no constituyen un lenguaje de patrones.



Desafortunadamente los lenguajes de patrones no son la panacea, y presentan muchas lagunas. Sobre todo, hay que recordar que todo este movimiento de documentación de diseño se origina a mediados de los noventa y que aun siendo mucho el trabajo realizado, no existe todavía ninguna estandarización sobre cómo abordar el desarrollo de estos lenguajes, ni ninguna clasificación que los relacione. Un posible ejemplo de lenguaje de patrones es el que hemos visto anteriormente en el que se aporta información sobre el nombre del patrón, contexto, patrones anteriores, la definición del problema, la solución y futuros patrones a considerar. Todos los patrones que aporten esta información podrían formar parte de este lenguaje de patrones. Otro ejemplo que modelase un tipo de sistema podría ser el sig uiente: 



 

 

Características básicas que lo definen y diferencian. Por ejemplo: un sistema web se caracteriza por; clientes ultra ligeros, uso de protocolos sin estado, centralización del software de ejecución en servidores, etc.. . Definición de los actores principales que participan en dicho sistema así como sus casos de uso básicos, descritos evidentemente de forma genérica. Especificación de los principales componentes funcionales del sistema. Así como las relaciones entre ellos. Arquitectura lógica y flujos de información, que estructuran lo diferentes subsistemas, el intercambio de información de los mismos, etc. Por ejemplo: arquitecturas reflexivas, modelo-vista-controlador etc… Arquitectura de componentes. Consiste en mapear los componentes funcionales en la arquitectura lógica de la aplicación. Arquitectura física. Especificación del despliegue de los componentes. Fuente: RED. Revista de Educación a Distancia. Número especial dedicado a Patrones de eLearning y Objetos de Aprendizaje Generativo. http://www.um.es/ead/red/M10/



4. Investiga la aplicación de lenguajes y patrones que no se hayan presentado en el desarrollo de la unidad.

Catálogo de patrones Un catálogo es un grupo de patrones clasificados por uno o más criterios y relacionados entre sí, los cuales pueden ser utilizados de forma conjunta o independiente. Estos criterios permiten organizar los patrones en grupos que comparten el mismo conjunto de propiedades, y dependiendo de los criterios elegidos se pueden definir esquemas de clasificación con diferentes dimensiones. Los esquemas de clasificación ponen de manifiesto las principales cualidades de los patrones y ayudan a reducir el ta maño del espacio de búsqueda. En la literatura se pueden encontrar los siguientes criterios utilizados para clasificar diferentes tipos de patrones (Kardell, 1997): 

Por su dominio. Dentro del campo de la ingeniería del software, los patrones no están restringidos a resolver problemas de diseño o de arquitectura software. Considerando el problema del diseño, se han propuesto gran cantidad de patrones en diferentes áreas, como pueden ser los de sistemas distribuidos, concurrentes o paralelos (Schmith et al., 2000) o colaborativos (Guerrero y Fuller, 2001).



Por su paradigma. Cada paradigma tiene sus propios patrones. Un patrón de diseño imperativo (uno de los paradigmas de la programación) podría dirigir un problema similar que un patrón de diseño orientado a objetos, pero la solución se describiría en términos de cada paradigma. Un ejemplo de este tipo sería el patrón Decorator (Gamma et al., 1994) que es presentado según el paradigma de la orientación a objetos y el patrón Navigational Context (Rossi et al., 1997) que es el mismo patrón pero adaptado al paradigma del hipertexto.



Por su granularidad. Los patrones también pueden ser clasificados dependiendo del nivel al cual se dirijan. La clasificación más famosa es la descrita en (Buschmann et al., 1996), donde en el nivel más bajo se encuentran los patrones específicos del lenguaje de programación, en el nivel medio se ubican los de diseño y en el nivel superior los patrones referentes a la arquitectura del sistema.



Por su nivel de abstracción . De una manera similar a la anterior, los patrones software se pueden clasificar en: patrones conceptuales, que son descritos mediante términos y conceptos de un dominio de aplicación específico; patrones de diseño, que describen construcciones software, complementando el espacio conceptual abierto por los patrones conceptuales; y patrones de programación, que estarían en el nivel más bajo de ab stracción, cuyas soluciones son descritas mediante construcciones propias de los lenguajes de programación (Riehle y Zullighoven’s, 1996).



Por su propósito. El propósito representa qué tipo de problemas resuelve el patrón. Este criterio fue usado inicialmente por Gamma et al. ( 1994), quienes establecieron las siguientes categorías: creación, estructurales y de comportamiento.



Por su alcance. Dentro de un mismo paradigma y usando el mismo entorno de desarrollo, los patrones pueden ser clasificados según el espacio del entorno en el que se aplica la solución del patrón. En el paradigma de la orientación a objetos, por ejemplo, el patrón puede ser aplicado a una clase o a un objeto (Gamma et al., 1994).



Por las relaciones entre patrones . En 1995, Zimmer examinó la naturaleza de las relaciones entre los patrones a través del campo “Patrones relacionados”, centrándose en las relaciones entre los aspectos del problema y la sol ución, dando lugar a tres tipos de relación: el patrón X usa el patrón Y en su solución, el patrón X es similar al patrón Y, y el patrón X puede ser combinado con el patrón Y. Posteriormente, viendo que la relación más predominante era “X usa Y”, los pa trones fueron organizados en niveles de uso, como se ve en la figura 2.4.1.a. Fuente: http://ares.cnice.mec.es/informes/21/contenidos/10.htm



5. En un archivo de texto, redacta un reporte con los elementos solicitados en los puntos 1, 2, 3 y 4.

DRS_U1_EA_REAG

Recommend Documents