Nombre: Oswaldo Juárez Merino

Matricula: Al12525677
Ingeniería en Desarrollo de software 5 Cuatrimestre
Programa de la asignatura: Diseño y Arquitectura de Software
Unidad 1. Arquitectura
Evidencia de aprendizaje. Lenguaje descriptor y patrones de arquitectura de
software
Facilitador: PABLO SANCHEZ LUNA

Bibliografía:
http://codeoptimizations.com/patron-de-arquitectura-layers/
http://daielrivas.blogspot.mx/
PDF unidad 1 Arquitectura
Consulta la escala de evaluación para conocer los parámetros de la actividad.

1.Identifica y describe los diferentes lenguajes descriptores de arquitectura y

agrega la utilidad que tiene.

ADLS

Para poder describir una arquitectura de manera estándar y adecuada surgió el

uso de los lenguajes de descripción de arquitecturas (ADLs), los cuales se utilizan
para satisfacer requerimientos descriptivos que necesitan un alto nivel de
abstracción, requisito que puede cumplir, por ejemplo, UML. Este nivel de
abstracción en los sistemas se debe a que cada vez se necesita que el software
resuelva más problemas de la vida cotidiana, y se ha permeado a todas las ramas
y fases de la vida de las personas, no en ambientes tan controlados como la
academia, con las fórmulas matemáticas.

Una definición un poco más formal, la que se habrá de aplicar desde ahora es la
de un lenguaje descriptivo de modelado, del cual su principal interés es la
estructura de alto nivel del producto de software antes que los detalles finos de
desarrollo e implementación de los módulos que lo conforman.
existe una definición generalizada los lenguajes, pero comúnmente debe pensarse
que estos lenguajes proporcionan un modelo explícito de componentes conectores
y sus respectivas configuraciones.
Los ADLs cuentan con cuatro criterios que los definen como una entidad:
componentes, conectores, configuraciones y restricciones. Para poder considerar
un lenguaje que pertenezca a la familia de ADLs debe soportar por lo menos los
siguientes elementos:
Componentes
Conexiones
Composición jerárquica
Paradigmas de computación
Paradigmas de comunicación
Modelos formales subyacentes

Soporte de herramientas para modelado análisis, validación y verificación

Composición automática de código aplicativo
Abstracción de componentes
Relatividad
Capacidad para modelar componentes
 PRINCIPALES CARACTERISITICAS
LENGUAJES DESCRIPTORES DE
A R Q U I T E C T U R A

C H AM C h e m i c a l A b s t r a c t M a c h i n e
Técnica de especificación basada en álgebra de
p r o c e s o s
Moléculas (componentes básicos)
Soluciones de moléculas (multiconjuntos que definen
e s t a d o s )
Reglas de transformación (cambios de estado)
No determinismo si hay + de una regla para una
m o l é c u l a o s o l u c i ó n
A c m e - A r m a n i Semántica sólo como comentario
N o g e n e r a c ó d i g o
M a n e j a e s t i l o s ( f a m i l i a )
V a r ia s h e r ra m ie n t a s e n a m b ie n t e W in d o ws :
A c m e S t u d i o
A r m a n i c o n f r o n t - e n d V i s i o
I S I : f r o n t - e n d P o w e r p o i n t
ADML: lenguaje de markup de arquitectura, derivado
d e A c m e ( e s t á n d a r )
A r m a n i : A D L . D e c l a r a t i v o
C 2 S A D L , C 2 S A D E L C2 SADL (Simulation Architecture Description Language)
ADL que permite describir arquitecturas en estilo C2
C2SADEL – Variante. Incluye DRADEL
(Development of Robust Architecture s
using a Description and Evolution Language )
xArch, xADL: Inicialmente ligados a C2
S A D L
Módulos declarativos e imperativos
1) IDN Interface Description Notatio n
2) ADN Architecture Description Notation
3) ACN Architecture Construction Notatio n
W i n d o w s :
DRADEL (Int . Para C2SADEL )
SAAGE (requiere Rose o Dradel)
ArchStudio – Argo (discontinuado)

R A P I D E D e s a r r o l l a d o p o r D a vi d L u c k h a n ( s t a n f o r d )
A D L d e p r o p ó s i t o g e n e r a l
Su objetivo es facilitar la simulación de eventos
(comportamientos aceptados y prohibidos )
Las especificaciones Rapide son ejecutable s
Lenguaje OO (modela concurrencia)
Requerimientos del sistema son expresados como
r e s t r i c c i o n e s e n e l t i e m p o
P r i n c i p a l e s e l e m e n t o s :
Componet (Interface Objects y Module )
C o n n e ct o r (I n t e rf a c e d e e n ví o y r e c e p c i ó n ,
 lo s co m p o n e n t s s e co m u n i ca n a t ra vé s d e
conectores, tres tipos de conexiones: Básicas ,
P i p e s y A g e n t e s )
Constraints (se definen en las conexiones de las
a r q u i t e c t u r a s )
D a r w i n ADL orientado a arquitecturas dinámica s
Descripción de tipo de componente mediante
i n t e r f a z
Su desarrollo consiste en instanciar declaraciones
de componentes y establecer relaciones entre
s e r v i c i o s
Soporta reconfiguración dinámica e instalación
t a r d í a
Las propiedades de un componente son sólo
c o m e n t a r i o s
No hay soporte real de estilos: solo se pueden
e x p r e s a r c o n s t r u c t i v a m e n t e
Semántica basada en cálculo Pi
Interfaz gráfica (software architect´s assistant )
2. Identifica y describe los patrones de arquitectura y agrega la utilidad que tienen.

un patrón de arquitectura deberá entenderse como una guía que ofrecen solución
a determinados problemas ya conocidos, respecto a problemáticas fundadas en la
ingeniería de software. También expresa de manera clara la relación que hay entre
los componentes de una solución basada en software y su esquema de
organización estructural, incluyendo todos los subsistemas y acciones que deberá
realizar cada uno de ellos, además de la manera correcta de comunicar el
resultado de esas acciones entre los mismos componentes, entre vistas o con
otros sistemas externos. Los patrones arquitectónicos sirven también para
describir las restricciones que tienen los módulos que comprenderán al sistema,
por ejemplo en la manera de comunicarse, la seguridad que deberá implementar
el sistema para resguardar los datos, de qué manera viajarán estos datos y por
qué protocolo de transmisión se hará. Las relaciones entre los módulos, las vistas
y los sistemas externos dan la estructura necesaria para pasar de cualquier
sistema de software a forma de esquema (gráfico o no); la estructura, expresa de
forma clara la composición total del sistema de software, pudiendo ser de un nivel
de abstracción muy alto hasta poder llegar a representarse de manera muy
detallada, a diferencia de los ADLs. Nota: Los ADLs y los patrones arquitectónicos
son complementarios
PATRONES DE ARQUITECTURA PRINCIPALES CARACTERÍSTICAS Y APLICACIONES
D E S O F T W A R E

L a y e r s
Descr ibe la c om pos ic ión de s ervic ios de forma que la m ayoría de la
interaccion corurre solamente entre capas vecinas .
Las capas de una aplicación puede residir en la misma máquina físic a
(misma capa) o puede estar distribuido sobre diferentes computadores
( n c a p a s )
Los componentes de cada capa se comunican con otros componentes en
otras capas a través de interfaces muy bien def inidas
Este modelo ha sido descrito como una “pirámide invertida de re - uso”
donde cada capa agrega responsabilidad y abstracción a la capa
d i r e c t a m e n t e s o b r e e l l a
Capa de presentación: Contiene elementos responsables de proveer
algún tipo de comunicación con los humanos, tales como las interfaces de
usuario 2. Lógica del negocio: Contiene elementos responsables de realizar
algún proceso del negocio y la aplicación de reglas del negocio. 3. Acceso de dato
a c c e s o
a los datos, tales como el modelo relacional.

M i c r o k e r n e l
Aplica para sistemas de software que deben de estar en capacidad de adaptar los
R e q u e r i m i e n t o s d e c a m b i o s d e s i s t e m a
Separa un núcleo funcional mínimo del resto de la funcionalidad y de partes
e s p e c i f i c a s p e r t e n e c i e n t e s a l c l i e n t e
P o r t a b i l i d a d
E s c a l a b i l i d a d
C o n f i a b i l i d a d
D i s p o n i b i l i d a d

El patrón de arquitectura Microkernel se aplica a sistemas de

Software que deben estar habilitados para adaptarse a
requerimientos cambiantes del sistema. Separa un núcleo de
funcionalidad mínima de la funcionalidad extendida y de partes específicas al cliente. También sirve como un socket para conectores en estas extensiones y coordinar su colaboración.
E s t r u c t u r a
El patrón Microkernel define cinco tipos de componentes :
S e r v i d o r e s i n t e r n o s
S e r v i d o r e s e x t e r n o s
C l i e n t e s
A d a p t a d o r e s
M i c r o k e r n e l
S e r v i d o r e s i n t e r n o s
También conocidos como subsistemas, extienden la
funcionalidad proporcionada por el microkernel. Representa un
componente separado que ofrece funcionalidad adicional.
El microkernel invoca la funcionalidad de los servidore s
internos vía solicitudes de servicio. Entonces, los servidores
internos pueden encapsular algunas dependencias de l
hardware o software subyacente. Por ejemplo, controladores
de dispositivos que soporten tarjetas gráficas específicas son
buenos candidatos para servidores internos.

Pipes and Filters

Proporciona una estructura para los sistemas basados en flujo de procesos de datos Los componentes se denominan filtros que son conectados por
medio de tuberías las cuales trasmiten los datos

Se aplica cuando los datos de entrada se habrán transformado

en datos de salida mediante una serie de componentes para el
c á l c u l o o l a m a n i p u l a c i ó n
R e u s a b i l i d a d
M a n t e n i b i l i d a d

Define una estructura para sistemas de software interactivos de

Presentation – Abstraction – Control Agentes de cooperación organizados de forma jerarquica .
Cada agente es responsable de un aspecto específico de la
funcionalidad de la aplicación y consiste de tres componentes:
presentación, abstracción y control.
M o d i f i c a b i l i d a d
E s c a l a b i l i d a d
I n t e g r a b i l i d a d

Model – View Controler

M o d e l o
Encapsula los datos y las funcionalidades
Es un patrón arquitectónico de tres capas conceptuales, fue definido en un principio para sistemas usuario – maquina y en la actualidad es aplicado a sistemas de información distribuidos Es independiente de cualquier representación de salida y/o
c o m p o r t a m i e n t o d e e n t r a d a
Representa toda la información con la que opera la aplicación
G e st io na e l co mp ort a m ien t o y lo s da to s d e l d om in io
Responde a peticiones de información que viene de la vista
Responde a instrucciones de cambio de estado, provenientes
d e l c o n t r o l a d o r

V i s t a
M u e s t r a l a i n f o r m a c i ó n a l u s u a r i o
Pueden existir múltiples vistas del modelo
Cada vista tiene asociado un componente controlado r
Gestiona la representación de la información de la aplicación

C o n t r o l a d o r
R e c i b e n l a s e n t r a d a s
Llama a la lógica del negocio para procesar y producir una
r e s p u e s t a
Interpreta las entradas del usuario, informando al modelo y a la
vista lo que surja de dichas entradas
.
B l a c k b o a r d Aplica para problemas cuya solución utiliza estrategias no
De t e rm in í st i ca s . V a rio s s u b s ist e m a s e n sa m b la n su
c o n o c i m i e n t o
Para construir una posible solución parcial o aproximada .

M o d i f i c a b i l i d a d
M a n t e n i b i l i d a d
R e u s a b i l i d a d
 I n t e g r i d a d

3. Elabora ejemplos de uso de la combinación de lenguajes y patrones y describe

cada ejemplo (mínimo 2

Ejemplo 1
Meta Object Facility (MOF). MOF es un lenguaje común y abstracto para la
especificación de meta-modelos, que sirve como un modelo común para UML y
CMW. MOF es una arquitectura de metamodelos de cuatro capas. La
especificación de MOF provee: i) Un modelo abstracto de los objetos y sus
relaciones; ii) un conjunto de reglas para mapear un metamodelo a interfaces
independientes del
lenguaje; iii) reglas definiendo el ciclo de vida, composición y semántica de los
modelos basados en MOF; iv) una jerarquía de interfaces reflexivas definiendo
operaciones genéricas para descubrir y manipular las propiedades de los meta-
modelos basados en MOF.
Common Warehouse Metamodel (CWM). Es un meta-modelo que especifica
interfaces que pueden ser usadas para habilitar el intercambio de metadatos de
almacenes de datos e inteligencia de negocio, entre distintas herramientas,
plataformas y metadatos en ambientes heterogéneos y distribuidos de almacenes
de datos. CMW se basa en tres estándares: MOF, UML y XMI. Los modelos CMW
permiten a los usuarios rastrear el linaje de los datos, mediante objetos que
describen de donde vienen los datos y cuándo y cómo se crearon los datos.
Unified Modeling Language (UML). El Lenguaje de Unificado (UML) sirve como
notación base para la definición de CMW. Dado que UML utiliza una definición
precisa, a partir de sus modelos visuales se pueden realizar traducciones
automáticas a otros lenguajes formales.
XML Metadata Interchange (XMI). Estándar que mapea el MOF al estándar de
XML del World Wide Web Consortium. XMI define como los tags de XML se usan
para representar en XML modelos serializados que cumplan con el estándar de
MOF. Esto facilita el intercambio
de modelos entre diversos modelos y herramientas.
Modelos MDA
MDA especifica tres modelos básicos de un sistema, correspondientes a los
puntos de vista expresados anteriormente. Estos modelos pueden verse como
niveles de abstracción donde en cada nivel pueden
construirse varios modelos

• Modelo Independiente de Cómputo. Al modelo independiente de cómputo

(Computation Independent Model o CIM) se le conoce como el modelo del dominio
o del negocio, por que se modela en términos
familiares a los expertos del negocio, representa exactamente lo que se espera
del sistema, sin contemplar toda la información relacionada con la tecnología con
el objetivo de mantenerse independiente de cómo será implementado el sistema.
Este modelo salva el abismo existente entre los expertos del negocio y los
responsables de las tecnologías de información. En una especificación MDA el
modelo CIM debe ser rastreable a las construcciones que lo implementan yasean
independientes o específicas a una plataforma.
• Modelo Independiente de Plataforma. El modelo independiente de plataforma
(Platform Independent Model o PIM) exhibe un grado de independencia tal permite
mapearlo a una o varias
plataformas, Esto se logra definiendo una serie de servicios abstrayéndolos de los
detalles técnicos para que otros modelos especifiquen cómo será la
implementación.
• Modelo Específico de Plataforma. El modelo específico de plataforma combina la
especificación de un PIM con los detalles paraindicar como el sistema usa una
plataforma en particular.

El Proceso MDA
Un sistema complejo puede incluir varios modelos relacionados entre sí,
organizados a través de varios niveles de abstracción, con mapeos definidos de
un conjunto de modelos hacia otro y que pueden incluir:
• Un CIM que contenga todas las reglas del negocio definidas en el modelo del
proceso de negocio.
• Un PIM que defina el modelo conceptual completo con todas sus relaciones.
• Uno o varios PSM para generar componentes de ejecución y pruebas del
sistema.
La idea básica de MDA, más allá de los modelos CIM/PIM/PSM, es utilizar los dos
conceptos clave: Modelo y Transformación. El primer paso es construir un modelo
conceptual (PIM) expresado en UML, el cual será transformado hacia varios PSM.
Las figuras 2 a 6 muestran el ejemplo de cómo un PIM se transforma en varios
PSM, uno para el modelo de datos, otro para las interfaces distribuidas y otro para
las clases de implementación. Estas transformaciones de un PIM en varios PSM
pueden realizarse las veces que se requiera. Si se hacen cambios al modelo
conceptual se pueden regenerar los PSM automáticamente. En el sitio web de
MDA (www.omg.org/mda) se puede encontrar una lista de
herramientas capaces de realizar estas transformaciones.

Ejemplo 2

En general, en todos los métodos de Diseño

OO se llevan a cabo las siguientes
Actividades:
ƒ Definir el contexto y modos de uso del
Sistema:
ƒ Diseñar la arquitectura del sistema;
ƒ Identificar los objetos principales del sistema;
ƒ Desarrollar los modelos de diseño;
ƒ Especificar las interfaces de los objetos
Descripción:
ƒ Se necesita un sistema de mapas climáticos para
generar mapas del tiempo de una forma regular usando los datos recopilados de
estaciones meteorológicas remotas automáticas y otras fuentes como
observadores, globos y satélites. Las estaciones meteorológicas transmiten sus
datos al computador del sistema cuando
reciben una petición al respecto desde dicha máquina.
ƒ El computador del sistema valida los datos recopilados y
los integra con los datos de otras fuentes diferentes. Los
datos integrados se archivan y, usando dichos datos y una
base de datos de mapas digitalizados, se elabora un juego de mapas del tiempo
locales. Los mapas pueden
imprimirse para su distribución en una impresora de
mapas especializada o pueden mostrarse en varios
formatos diferentes.

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

el desarrollo de la unidad.

Figura 2. Modelo Conceptual

Figura 3. Transformaciones MDA
Figura 4. Capa de Descripción de Datos

Pensando en la Transición

Moverse de un enfoque tradicional de desarrollo de software a uno dirigido por

modelos no es sencillo, requiere de un proyecto formal con planeación,
patrocinadores y recursos. El esfuerzo es importante, pero las ventajas son
muchísimas. La promesa de la arquitectura dirigida por modelos es facilitar la
creación de modelos y transformaciones automáticas, buscando flexibilidad a
largo plazo en términos de:
Obsolescencia tecnológica: Nueva infraestructura puede ser incorporada y
soportada fácilmente por los diseños existentes.
Portabilidad: Funcionalidad existente se puede migrar a nuevos ambientes y
plataformas
Productividad: La generación automática de los PSM acelera el desarrollo
Integración: Los puentes de integración entre sistemas pueden realizarse usando
modelos y transformaciones.
Calidad: Existen modelos ejecutables de UML, con los cuales los modelos pueden
probarse antes de la implementación.
Figura 5. Modelo Session Bean

Figura 6. Modelo C#
LENGUAJES DESCRIPTORES DE PRINCIPALES CARACTERÍSTICAS
ARQUI TECTURA Y APLICACIONES

WRIGHT Desarrollado por David Garlan (CMU)

ADL de propósito general
Enfasis en análisis de protocolos de
comunicación
Elementos principales (componente y
conector)
Herramientas de desarrollo limitadas

D a r w i n Lenguaje de descripción de
arquitecturas basado en XML
Desarrollado por el institute for
Software Research (Universidad de
California)
Principales elementos (componente,
conector, interfaces y
configuraciones)
Fácilmente extensible (módulos)
Diferencia dos tipos de elementos:
Instancias arquitecturales (Ejecución)

R E S T Constituye una revoluciónaria

inflexión en los estilos orientados a
servicios (“la nueva generación de
web services”) o si es una variante
colateral todavía subsiste. Es un
estilo característico de las
arquitecturas basadas en recursos,
antes que en mensajes, y la
especificación total de Web services
seria un superconjunto de dicha
estrategia, susceptible de
visualizarse como estilo de recursos
o de servicios, según convenga.
P U Consiste en core Worksflows que
definen en fases. El PU se compone
de seis de estos Worksflows
-modelado de negocios
-requerimientos
-analisis
-diseño
-implementacion
-prueba
Capacidad de Tiempo Real
La Arquitectura Basada en Estados Aunque ningún producto actúa en
Versus el Tiempo Real
Disparadores
se refiere a las operaciones del
sistema que ocurren dentro de la
percepción humana del presente.
Dado que en muchos casos puede
enviarse un evento desde un
directorio conectado al producto y
efectuar un cambio rápidamente, a
menudo se dice que los productos
basados en eventos tienen
capacidad de tiempo real. Aunque
puede parecer que esta
característica ofrece un gran valor a
muchas empresas, un análisis de
cómo funciona el producto basado en
eventos revela algunas limitaciones
significativas.
verdadero tiempo real, la arquitectura
basada en estados puede
implantarse como un sistema
distribuido “casi de tiempo real”
basado en delta.
Un producto basado en estados
puede configurarse para controlar
continuamente los deltas de los
demás sistemas y para propagarlos
rápidamente. Al igual que todos los
sistemas de tiempo real aparente, los
productos basados en estados tienen
retrasos de replicación, algunos de
ellos por diseño. Estos retrasos de
replicación dan lugar a una
infraestructura de identidad más
sólida que en el caso de que sólo se
permita efectuar las transacciones si
todas las réplicas son accesibles en
tiempo real, como sucede con los
productos basados en eventos
• Sólo los usan los sistemas
basados en eventos
• Requieren modificaciones del
directorio
• Los cambios de las reglas de
negocio requieren que se rescriba el
código del disparador y del agente
local
En un archivo de texto, redacta un reporte con los elementos solicitados en los
puntos 1, 2, 3 y 4. 6.

ADLS

para poder describir una arquitectura de manera estándar y adecuada surgió el

uso de los lenguajes de descripción de arquitecturas (ADLs), los cuales se utilizan
para satisfacer requerimientos descriptivos que necesitan un alto nivel de
abstracción, requisito que puede cumplir, por ejemplo, UML. Este nivel de
abstracción en los sistemas se debe a que cada vez se necesita que el software
resuelva más problemas de la vida cotidiana, y se ha permeado a todas las ramas
y fases de la vida de las personas, no en ambientes tan controlados como la
academia, con las fórmulas matemáticas
Las arquitecturas basadas en estados son superiores a las basadas en eventos
por su conjunto de características, su facilidad de administración y por cómo
resuelven los retos técnicos y políticos de la integración de datos distribuidos de
identidad en una empresa. La arquitectura Server 2003 es la de un sistema
basado en estados.
Los patrones coronan una práctica de diseño que se origina antes
que la arquitectura de software se distinguiera como discurso en perpetuo estado
de
formación y proclamara su independencia de la ingeniería en general y el
modelado en
particular. Los estilos, en cambio, expresan la arquitectura en el sentido más
formal y teórico.