Nombre: Antonio Escobar Toledo

Carrera: Ingeniera en desarrollo de software

Matricula: AL11500136
Facilitador: OLIVIA ACOSTA MORALES

Email: FA1214963@unadmexico.mx
Asignatura: Diseo y arquitectura de software
Unidad: 1
Tema: Evidencia de aprendizaje. Lenguaje
descriptor y patrones de arquitectura de software

Tabla de contenido
Lenguaje descriptor y patrones de arquitectura de software ....................................... 4

Evidencia de aprendizaje. Lenguaje descriptor y patrones de ............................. 4

Arquitectura de software. ..................................................................................... 4
1.-Identifica y describe los diferentes lenguajes descriptores de arquitectura y
agrega la utilidad que tiene. ............................................................................................ 5

Acme ................................................................................................................... 5
Aesop .................................................................................................................. 5
ArTek ................................................................................................................... 5
Armani ................................................................................................................. 5
C2 SADL .............................................................................................................. 5
CHAM .................................................................................................................. 5
2. Identifica y describe los patrones de arquitectura y agrega la utilidad que tienen. 6

Programacin por capas ...................................................................................... 6

Arquitectura en pizarra ........................................................................................ 6
Arquitectura dirigida por eventos ......................................................................... 7
Peer-to-peer......................................................................................................... 7
Arquitectura orientada a servicios ........................................................................ 8
3. Elabora ejemplos de uso de la combinacin de lenguajes y patrones y describe
cada ejemplo (mnimo 2). .............................................................................................. 10

Ejemplo 1 ........................................................................................................... 10
Ejemplo 2 ........................................................................................................... 12

Lenguaje descriptor y patrones de arquitectura de

software
Evidencia de aprendizaje. Lenguaje descriptor y patrones de
Arquitectura de software.
Como parte de la evaluacin de esta unidad, es necesario realizar un reporte
donde se explique y distinga los diferentes patrones de arquitectura de software,
as como los lenguajes descriptores de arquitectura y su aplicacin a cada modelo,
de manera que investigues patrones y lenguajes que no se hayan incluido en el
desarrollo de esta primer unidad.
1.-Identifica y describe los diferentes lenguajes descriptores de arquitectura y
agrega la utilidad que tiene.
2. Identifica y describe los patrones de arquitectura y agrega la utilidad que tienen.
3. Elabora ejemplos de uso de la combinacin de lenguajes y patrones y describe
cada ejemplo (mnimo 2).
4. Investiga la aplicacin de lenguajes y patrones que no se hayan presentado en
el desarrollo de la unidad.

1.-Identifica y describe los diferentes lenguajes

descriptores de arquitectura y agrega la utilidad que
tiene.
Acme
Acme soporta la definicin de cuatro tipos de arquitectura: la estructura
(organizacin de un sistema en sus partes constituyentes); las propiedades de
inters (informacin 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
representacin).

Aesop
Se basa en el estilo de tubera y filtros propio de UNIX.

ArTek
Capacidad de modelar ciertos aspectos de una arquitectura.

Armani
Es un lenguaje puramente declarativo que describe la estructura del sistema y las
restricciones a respetar, pero no hace referencia alguna a la generacin del
sistema o a la verificacin de sus propiedades no funcionales o de consistencia

C2 SADL
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.

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.
1. Capa de presentacin: 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 de negocio: 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.
3.- Capa de datos:

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.
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 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.

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).
Ejemplo 1
El siguiente ejemplo define una familia o estilo de la clase ms simple, tubera y
filtros.
Este estilo est relacionado con las arquitecturas de flujo de datos. Por ser el estilo
ms primitivo y de definicin ms escueta, se ha escogido ejemplificar con l la
sintaxis de Acme y de todos los ADLs que se revisarn despus.
El estilo es caracterstico no slo de arquitecturas de tipo UNIX, sino que es
ampliamente usado en compiladores, flujos de datos, tratamiento de XML con
SAX, procesamiento de seales y programacin funcional, as como en los
mecanismos de procesamiento de consultas de algunos servidores de bases de
datos. Es el nico estilo, por otra parte, que puede ser implementado explcita o
implcitamente en todos los ADLs [Cle96]. En Acme la sintaxis para definirlo sera:
// Una familia Acme incluye un conjunto de tipos de
// componente,conector, puerto (port) y rol que definen el vocabulario
// propio del estilo.
Family PipeFilterFam = {
//
//
//
//

Declara tipos de componente.

Una definicin de tipo de componente en Acme permite establecer
la estructura requerida por el tipo. Esta estructura
se define mediante la misma sintaxis que la instancia de un componente.

Component Type FilterT = {

// Todos los filtros definen por lo menos dos puertos
Ports { stdin; stdout; };
Property throughput : int;
};
//
//
//
//

Extiende el tipo bsico de filtro con una subclase (herencia)

Las instancia de WindowsFilterT tendrn todas las propiedades y
puertos de las instancias de FilterT, ms un puerto stderr
y una propiedad implementationFile.

Component Type WindowsFilterT extends FilterT with {

Port stderr;
Property implementationFile : String;
};
// Declara el tipo de conector de tubera. Igual que los
// tipos de componente, un tipo de conector tambin describe
// la estructura requerida.
Connector Type PipeT = {
Roles { source; sink; };
Property bufferSize : int;
};

// Declara algunos tipos de propiedad que pueden usarse en

// sistemas del estilo PipeFilterFam
Property Type StringMsgFormatT = Record [ size:int; msg:String; ];
Property Type TasksT = enum {sort, transform, split, merge};
};

Ejemplo 2
El siguiente ejemplo ilustra la descripcin de un modelo de tubera y filtros en
Armani:
Style Pipe-and-Filter = {
// Definir el vocabulario de diseo
// Definir el tipo de flujo
Property Type flowpathRecT = Record [ fromPt : string; toPt : string; ];
// Definir tipos de puerto y rol
Port
Port
Role
Role

Type
Type
Type
Type

inputT = { Property protocol : string = "char input"; };

outputT = { Property protocol : string = "char output"; };
sourceT = { Property protocol : string = "char source"; };
sinkT = { Property protocol : string = "char sink"; };

// Definir tipos de componentes

Component Type Filter = {
Port input : inputT;
Port output : outputT;
Property function : string;
Property flowPaths : set{flowpathRecT}
<< default : set{flowpathRecT} =
[ fromPt : string = "input"; toPt : string = "output"]; >>;
// Restriccin para limitar aadido de otras puertos
Invariant forall p : port in self.Ports |
satisfiesType(p, inputT) or satisfiesType(p,outputT);
};
// Definir tipos de componentes
Connector Type Pipe = {
Role source : sourceT;
Role sink : sinkT;
Property bufferSize : int;
Property flowPaths : set{flowpathRecT} =
[ from : string = "source"; to : string = "sink" ];
// los invariantes requieren que un Pipe tenga
// exactamente dos roles y un buffer con capacidad positiva.
Invariant size(self.Roles) == 2;
Invariant bufferSize >= 0;
};
// Definir diseo abstracto de anlisis para todo el estilo
// y verificar ciclos en el grafo del sistema
Design Analysis hasCycle(sys :System) : boolean =
forall c1 : Component in sys.Components | reachable(c1,c1);
// definir anlisis de diseo externo que computa la performance
// de un componente
External Analysis throughputRate(comp :Component) : int =
armani.tools.rateAnalyses.throughputRate(comp);

// Especificar invariantes de diseo y heurstica

// para sistemas construidos en este estilo.
// Vincular inputs a sinks y outputs a fuentes
Invariant forall comp : Component in self.Components |
Forall conn : Connector in self.Connectors |
Forall p : Port in comp.Ports |
Forall r : Role in conn.Roles |
attached(p,r) ->
((satisfiesType(p,inputT) and satisfiesType(r,sinkT)) or
(satisfiesType(p,outputT) and satisfiesType(r,sourceT)));
// No hay roles no asignados
Invariant forall conn : Connector in self.Connectors | forall r : Role in
conn.Roles |
exists comp : Component in self.Components | exists p : Port in
comp.Ports |
attached(p,r);
// flag de puertos no vinculados
Heuristic forall comp : Component in self.Components |
forall p : Port in comp.Ports | exists conn : Connector in
self.Connectors |
exists r : Role in conn.Roles |
attached(p,r);
// Restriccin: En un estilo de tubera y filtros no puede haber ciclos
Invariant !hasCycle(self);
// Propiedad no funcional: Todos los componentes deben tener un
// throughput de 100 (unidades) como mnimo.
Heuristic forall comp : Component in self.Components |
throughputRate(comp) >= 100;
};
// fin de la definicin del estilo-familia.

4. Investiga la aplicacin de lenguajes y patrones que no se hayan

presentado en el desarrollo de la unidad.
Patrones Estructurales

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.

Envoltorio (Decorator): Permite aadir dinmicamente funcionalidad a una clase existente,

evitando heredar sucesivas clases para incorporar la nueva funcionalidad.

Fachada (Facade): Permite simplificar la interfaz para un subsistema.

Peso Ligero (Flyweight): Elimina la redundancia o la reduce cuando tenemos gran cantidad
de objetos con informacin idntica.

Apoderado (Proxy): Un objeto se aproxima a otro.

Cadena de responsabilidad (Chain of responsibility): La base es permitir que ms de un

objeto tenga la posibilidad de atender una peticin.

Orden (Command): Encapsula una peticin como un objeto dando la posibilidad de

deshacer la peticin.

Intrprete (Interpreter): Intrprete de lenguaje para una gramtica simple y

sencilla.
Iterador (Iterator): Define una interfaz que declara los mtodos necesarios
para acceder secuencialmente a una coleccin de objetos sin exponer su
estructura interna.
Mediador (Mediator): Coordina las relaciones entre sus asociados. Permite
la interaccin de varios objetos, sin generar acoples fuertes en esas
relaciones.
Recuerdo (Memento): Almacena el estado de un objeto y lo restaura
posteriormente.
Observador (Observer): Notificaciones de cambios de estado de un objeto.

Public Class Articulo

Delegate Sub DelegadoCambiaPrecio(ByVal unPrecio As Object)
Public Event CambiaPrecio As DelegadoCambiaPrecio
Dim _cambiaPrecio As Object
Public WriteOnly Property Precio()
Set(ByVal value As Object)
_cambiaPrecio = value
RaiseEvent CambiaPrecio(_cambiaPrecio)
End Set
End Property
End Class
Public Class ArticuloObservador

Estado (Server): Se utiliza cuando el comportamiento de un objeto cambia

dependiendo del estado del mismo.
Estrategia (Strategy): Utilizado para manejar la seleccin de un algoritmo.
Mtodo plantilla (Template Method): Algoritmo con varios pasos
suministrados por una clase derivada.

Lenguajes descriptores
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.
Darwin soporta la descripcin de arquitecturas que se reconfiguran dinmicamente
a travs de dos construcciones: instanciacin tarda [lazy] y construcciones
dinmicas explcitas. Utilizando instanciacin laxa, se describe una configuracin y
se instancian componentes slo en la medida en que los servicios que ellos
provean sean utilizados por otros componentes. La estructura dinmica explcita,
en cambio, se realiza mediante constructos de configuracin imperativos. De este
modo, la declaracin de configuracin deviene un programa que se ejecuta en
tiempo de ejecucin, antes que una declaracin esttica de la estructura.
Cada servicio de Darwin se modeliza como un nombre de canal, y cada
declaracin de binding es un proceso que trasmite el nombre del canal al
componente que requiere el servicio. En una implementacin generada en Darwin,

se presupone que cada componente primitivo est implementado en algn

lenguaje de programacin, y que para cada tipo de servicio se necesita un
ligamento (glue) que depende de cada plataforma.
Jacal

Es un lenguaje de descripcin de arquitecturas de software de propsito general

creado en la Universidad de Buenos Aires, por un grupo de investigacin del
Departamento de Computacin de la Facultad de Ciencias Exactas y Naturales.
Objetivo principal El objetivo principal de Jacal es lo que actualmente se
denomina animacin de arquitecturas. Esto es, poder visualizar una simulacin
de cmo se comportara en la prctica un sistema basado en la arquitectura que
se ha representado.
LILEANNA

Al igual que en el caso de ArTek, en opinin de Medvidovic LILEANNA no es un

genuino ADL, por cuanto la configuracin es modelizada implcitamente mediante
informacin de interconexin que se distribuye entre la definicin 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.
Basado en expresiones de mdulo propias de la programacin parametrizada. Un MIL se
puede utilizar descriptivamente, para especificar y analizar un diseo determinado, o
constructivamente, para generar un nuevo sistema en base a mdulos preexistentes,
ejecutando el diseo. Tpicamente, la programacin parametrizada presupone la
disponibilidad de dos clases de bibliotecas, que contienen respectivamente expresiones
de mdulo (que describen sistemas en trminos de interconexiones de mdulos) y grafos
de mdulo (que describen mdulos y relaciones entre ellos, y que pueden incluir cdigo u
otros objetos de software).
MetaH/AADL

As como LILEANNA es un ADL ligado a desarrollos que guardan relacin

especfica con helicpteros, MetaH modela arquitecturas en los dominios de gua,
navegacin y control (GN&C) y en el diseo aeronutico. Aunque en su origen
estuvo ligado 31 estrechamente a un dominio, los requerimientos imperantes
obligaron a implementar recursos susceptibles de extrapolarse productivamente a
la tecnologa de ADLs de propsito general. AADL (Avionics Architecture
Description Language) est basado en la estructura textual de MetaH. Aunque
comparte las mismas siglas, no debe confundirse este AADL con Axiomatic
Architecture Description Language, una iniciativa algo ms antigua que se refiere
al diseo arquitectnico fsico de computadoras paralelas.

Rapide
Se puede caracterizar como un lenguaje de descripcin de sistemas de propsito
general que permite modelar interfaces de componentes y su conducta
observable. Sera tanto un ADL como un lenguaje de simulacin. 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 especificacin
describe restricciones abstractas para la conducta de los componentes; el
lenguaje ejecutable describe mdulos ejecutables; y el lenguaje de patrones
describe patrones de los eventos. Los diversos sub-lenguajes comparten la misma
visibilidad, scoping y reglas de denominacin, as como un nico modelo de
ejecucin.