Arquitecturas Software

Introducción
Mecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y Servicios
Lenguajes de Defición Arquitectónica (ADLs)
Arquitecturas Software
M.I. Capel
ETS Ingenierías Informática

y Telecommunicación
Universidad de Granada
Email: manuelcapel@ugr.es
Desarrollo de Software
Ingeniería de Software (3er curso de Grado)
M.I.Capel Tema 2 1/146

Introducción
Índice
1 Introducción
Ciclo de Negocio de una Arquitectura Software
Descripción de una Arquitectura Software
2 Mecanismos Arquitectónicos
3 Arquitecturas Orientadas a Componentes y Servicios
Conceptos generales sobre SOA
Servicios proporcionados por la arquitectura
Tecnologías para implantar un SOA
Ciclo de Vida
Business Process Modeling
Especificación GRáfica de Procesos de Negocio
Formalization de las extensiones temporales de EBPMN
Introducción
Índice
1 Introducción
Ciclo de Vida
Introducción
Índice
1 Introducción
Ciclo de Vida
Introducción
Índice
1 Introducción
Ciclo de Vida
Introducción
Mecanismos Arquitectónicos Ciclo de Negocio de una Arquitectura Software
Arquitecturas Orientadas a Componentes y Servicios Descripción de una Arquitectura Software
Arquitectura de Software
Es una descripción de la estructura del software que se va
a implementar,
los datos que son parte del sistema,
las interfaces entre los componentes del sistema,
y algunas veces, los algoritmos utilizados.
El diseño se obtiene iterativamente tras varias versiones.
Incluye agregar formalidad y detalles durante el desarrollo
del diseño, y regresar a los diseños anteriores y corregirlos.
El proceso de diseño es aún un proceso adhoc
[Bass et al. 2003]
La Arquitectura de Software de un programa o sistema de
computación es la estructura o estructuras del sistema, la
cual comprende componentes
M.I.Capel
deTema
software,
2 3/146
propiedades
Introducción
El diseño arquitectónico
definición
Consiste en una actividad inicial de la fase de diseño de un
sistema software cuyo objetivo es identificar los subsistemas y
establecer un marco de trabajo para gestionar correctamente el
control y la comunicación de dichos subsistemas

Introducción
El proceso de diseño
El proceso de diseño incluye el desarrollo de varios
modelos con diferentes niveles de abstracción
La retroalimentación entre estas actividades y la
consecuente repetición del trabajo es inevitable en todo
proceso de diseño

Introducción
Ubicación dentro de proceso de diseño
El diseño arquitectónico representa el puente entre la

especificación de requerimientos del sistema y el diseño
Establecer un marco de trabajo básico que proporcione
una estructura para situar los componentes principales de
un sistema y las comunicaciones que tienen lugar

Introducción
Especificación de requerimientos
Existe un solapamiento entre análisis y especificación de

requerimientos con el diseño arquitectónico
La especificación no debería incluir ninguna información
sobre diseño
La descomposición arquitectónica es necesaria para
estructurar y organizar la especificación de un sistema
Normalmente se utiliza un modelo arquitectónico como el
punto de partida para realizar la especificación de los
subsistemas

Introducción
Motivación de la Arquitectura de Software
Existen unas necesidades fundamentales que justifican la

importancia de construir una AS y de su análisis:
Potencia la comunicación entre stakeholders
Es el punto más temprano en el cual el sistema que va a
ser construido puede ser analizado.
Las decisiones de diseño aquí son muy importantes para
conseguir requisitos críticos del sistema
Abstracción de un sistema software: es una herramienta
esencial para gestionar la complejidad de un sistema
Modelo transferible a otros sistemas, especialmente a
aquellos con requerimientos similares

Introducción
Influencias
Un AS es el resultado de diversas influencias técnicas, del

negocio y sociales
La existencia de una determinada AS para un dominio de
aplicaciones afecta a su vez a los ambientes técnicos de
negocio y sociales, que realimentan la futura arquitectura
Un entendimiento temprano de las restricciones permite a
los arquitectos de software gestionarlos, negociar
expectativas con las partes implicadas (stakeholders),
manejar riesgos, establecer compromisos, etc.
Introducción
Recomendaciones para el proceso
La arquitectura debe ser producto del equipo

El equipo debe conocer los requerimientos funcionales y
los de calidad priorizados
Se debe documentar
Revisada por todas la partes implicadas
Analizada en base a mediciones
Debe ser implementada incrementalmente

Introducción
Recomendaciones para el producto

Una AS debe ser modular
Cada módulo debe tener una interfaz bien definida y
encapsular toda la información
Los atributos de calidad se deben alcanzar usando
tácticas específicas para cada atributo
Consideración
El logro de dichos atributos dependerá fundamentalmente de la
AS seleccionada [Bass et al.1998][SEI 2001], no sólo de la
prácticas a nivel de código (lenguajes, diseño detallado,
estructuras de datos y algoritmos)

Introducción
Recomendaciones para el producto

Una AS debe ser modular
Cada módulo debe tener una interfaz bien definida y
encapsular toda la información
Los atributos de calidad se deben alcanzar usando
tácticas específicas para cada atributo
Consideración
El logro de dichos atributos dependerá fundamentalmente de la
AS seleccionada [Bass et al.1998][SEI 2001], no sólo de la
prácticas a nivel de código (lenguajes, diseño detallado,
estructuras de datos y algoritmos)

Introducción
AS y requisitos no–funcionales
El estilo arquitectónico y estructura interna escogidos
puede depender de requisitos no-funcionales: rendimiento,
seguridad, fiabilidad, disponibilidad y mantenibilidad
Rendimiento
Clave: localizar las operaciones críticas dentro del menor
número posible de subsistemas, que mantengan el mínimo
acoplamiento posible
Seguridad (control acceso a la información)

Clave: utilizar una arquitectura estratificada donde los
elementos más críticos se ubiquen en las capas más internas y
cuyo acceso esté protegido muy rigurosamente
Introducción
AS y requisitos no–funcionales II
Seguridad (prevención de daños)
Clave: todas las operaciones sensibles han de ser ubicadas en
un solo subsistema o en un número pequeño de estos para
conseguir la mayor protección
Disponibilidad
Clave: la arquitectura debe incluir componentes redundantes,
tal que se puedan sustituir sin parar la ejecución del sistema
Mantenibilidad
Clave: utilizar componentes pequeños y autocontenidos que
puedan ser cambiados con rapidez
Introducción
AS y requisitos no–funcionales III
Conflicto de intereses
El potenciar un atributo arquitectónico correspondiente a
un requisito no–funcional puede estar en conflicto con los
otros requisitos
Ejemplo: utilizar componentes grandes mejora el
rendimiento, en general, pero perjudica la mantenibilidad
del diseño
Se puede bien llegar a una solución de compromiso o
utilizar distintos estilos arquitectńicos para diferentes
partes del sistema

Introducción
Decisiones Arquitectónicas
Cada enfoque desarrollado como parte de una descripción
arquitectónica aborda un aspecto de la AS
Se consideran una variedad de alternativas entre los
posibles enfoques arquitectónicos, y su descripciones
Las propias decisiones arquitectónicas pueden ser
consideradas como un enfoque o vista de la arquitectura.
Documentar las decisiones y las razones que las motivan
dichas es una manera fundamental de concebir y expresar
una arquitectura software [Babar09, Perry92].
Las decisiones arquitectónicas se pueden considerar
como los primeros elementos de la descripción de una
arquitectura software, por tanto, se han de hacer explícitas
utilizando una plantilla de descripción
M.I.Capel Tema 2 arquitectónica
15/146
Introducción
Decisiones Arquitectónicas II
Si una propiedad de un elemento arquitectónico no es

visible o no es discernible de cualquier otro elemento
arquitectónico, ese elemento no es arquitectónico.
La selección de un manejador de base de datos no es una
decisión arquitectónica. La razón de su existencia no es
materia (no le concierne) a las metas arquitectónicas.
Las decisiones son arquitectónicas o no de acuerdo al
contexto. Si la estructura es importante para alcanzar las
metas del sistema la estrutura es arquitectónica.

Introducción
Plantilla de Descripción Arquitectónica
Resolución Argumentos
Categoría Implicaciones
Suposiciones Decisiones relacionadas
Restricciones Productos de trabajo
Alternativas Notas

Introducción
Una AS proporciona la definición del sistema objetivo en

términos de elementos computacionales y de las
interacciones entre ellos.
La arquitectura muestra la correspondencia entre los
requerimientos de sistemas y los elementos del sistema
construido, proveyendo así una exposición racional para
las decisiones de diseño.

Introducción
Elementos notacionales de una AS
Computacionales:
Son entidades tales como clientes, servidores, bases de
datos, filtros y capas de un sistema jerárquico.
Son además, una parte encapsulada del sistema de
software, donde cada uno tiene una interfaz.
Interacciones:
Ocurren entre los elementos a nivel de diseño, pudiendo
ser tan simples como las llamadas a procedimientos o
variables de acceso, o tan complejas y semánticamente
ricas como los protocolos del modelo cliente-servidor, o los
protocolos de acceso a las bases de datos.

Introducción
Elementos notacionales de una AS II
Relaciones:
Denotan las conexiones entre los elementos
computacionales y/o componentes.
Relaciones estáticas: Se muestran en el código fuente,
ellas reflejan la colocación de los componentes dentro de
la arquitectura. Son fácilmente detectables a partir del
código fuente.
Relaciones dinámicas: Tratan con las conexiones
temporales y las interacciones dinámicas entre los
componentes.
No se suelen detectar inspeccionando el código fuente del
sistema final

Introducción
Protocolo para obtener la representación de una AS

1 definir los aspectos estructurales como una composición
de componentes,
2 las estructuras globales de control,
3 los protocolos de comunicación,
4 la sincronización y acceso a los datos,
5 la asignación de la funcionalidad a los elementos del
diseño,
6 la composición de estos elementos,
7 su distribución física,
8 su escalabilidad y su desempeño
Introducción
Proceso de Diseño Orientado a Objetos: un caso de

estudio
Definition (Sistema de Información Meteorológica (WMS))
Un WMS se necesita para generar informes meteorológicos
regularmente utilizando datos recogidos de estaciones de
observación remotas y sin personal, así como de otras fuentes
tales como observadores voluntarios, globos y satélites. Como
respuesta de una petición, las estaciones transmiten sus datos
al computador encargado de área.
El sistema del computador de área valida los datos recogidos
desde diferentes fuentes y los integra. Los datos integrados
son archivados y, utilizando los datos desde este archivo y los
de una base de datos de informes meteorológicos, se crea un
conjunto de informes locales.
M.I.Capel LosTema
informes
2 22/146se pueden imprimir
Introducción
Pasos a seguir
1 Entender y definir los modos de uso y el contexto del

sistema WMS
2 Diseñar la arquitectura de software (AS)
3 Identificar los objetos principales dentro de la AS
4 Desarrollar los modelos de diseño
5 Especificar las interfaces de objetos

Introducción
Selección de una arquitectura software
Arquitectura estratificada (por capas)

Cada capa sólo necesita del procesamiento de la capa
inferior para operar
Capas identificadas:
Recoger Datos
Procesar Datos
Achivar Datos
Mostrar Datos

Introducción
Elementos notacionales: UML
Cada capa incluye a otros componentes del sistema

Se utilizan packaqes-UML
Identificación de subsistemas

Introducción
Arquitectura inicial del sistema objetivo

Introducción
Modelos de uso y contexo del sistema

Definition (Objetivo)
Desarollar una comprensión de las relaciones entre el software
que está siendo diseñado y su entorno
El contexto del sistema es un modelo estático que
describe a otros sistemas
Se utiliza un modelo dinámico para describir cómo
interactúa el sistema realmente con su entorno
Utilizar diagramas de casos de uso
Un caso de uso por cada interacción entre el sistema y su
entorno
Asociaciones entre casos de uso y descripciones según
Introducción
Diseño arquitectónico
Guiado por la descripción de las interacciones del sistema

con su entorno
Componente Estación Meteorológica:
1 Interfaz: comunicaciones con las otras partes del sistema
2 Recolección: de datos: gestionar los datos recogidos por
los instrumentos y el resumen de los datos meteorológicos
antes de transmitirlos
3 Instrumentación: encapsulación de los instrumentos
utilizados para recoger los datos en bruto
4 Descomponer los modelos hasta que sólo existan 7
entidades de modelado como máximo en un modelo
arquitectónico

Introducción
Componentes de Subsistemas

Introducción
Arquitectura de Componentes

Introducción
Los objetos tienden a emerger durante el diseño

El diseño tiene que ver con la identificación de las clases
Identificación de atributos y operaciones de las clases
desde la descripción informal del sistema
Identificación de objetos de la estación meteorológica:
Objetos del dominio de aplicación:
1 Termómetro Tierra
2 Anemómetro
3 Barómetro
Objetos procedentes de escenarios de casos de uso:
1 EstacionMeteo
2 DatosMeteo

Introducción
Clases de Objetos

Introducción
Carácter pasivo/activo de los objetos
Los objetos pasivos ejecutan sus métodos por petición del

sistema: cambios en la política de recogida de datos no
afecta a las clases que los modelan
Objetos activos incluyen su propio control, deciden cuándo
realizan las lecturas de los instrumentos: perjudica la
interoperabilidad

Introducción
Modelos estáticos y dinámicos

Los modelos de diseño son el puente entre los requisitos
del sistema y la implementación del sistema:
1 Modelos estáticos: clases, objetos, relaciones de
generalización, usa/usado–por, composición
2 Modelos dinámicos: diagramas de secuencia y de estados,
entre otros (UML proporciona 12 modelos dinámicos de
diagramas)
Modelos de subsistemas: incluyen componentes y
asociaciones
Secuencias: para cada modo de interacción del sistema,
la secuencia de llamadas entre objetos que tienen lugar
Estados: comportamiento de un solo objeto en respuesta
a los mensajes que puede procesar
Introducción
Descomposición de paquetes

Introducción
Modelo de secuencia de operaciones

Introducción
Diagrama de estados

Introducción
Especificar las interfaces de objetos
Especificar las interfaces de los objetos de tal manera que

los objetos y los subsistemas se puedan diseñar en
paralelo
No incluir detalles de la representación en el diseño
Sólo proporcionar las operaciones de los objetos
necesarias para acceder y actualizar los datos del objeto
No tiene por qué existir una relación 1:1 entre objetos e
interfaces
Utilizar un lenguaje de programación (como Java) para
definir las interfaces de los objetos

Introducción
Modelos abstractos de AS
Modelo 4+1 Vistas de Krutchen
En la actualidad el desarrollo de sistemas se centra en la
arquitectura software, que es especificada utilizando el modelo
siguiente

Introducción
Modelos abstractos de AS
Modelo 4+1 Vistas de Krutchen
En la actualidad el desarrollo de sistemas se centra en la
arquitectura software, que es especificada utilizando el modelo
siguiente

Introducción
Ciclo de Arquitecturas de Negocio (ABC)

Ciclo de retroalimentación entre una AS y un negocio
Según [Bass et al. 2003], estos y otros mecanismos de
retroalimentación forman lo que se llama “ABC”
En [Krutchen 2003] también se indica esta relación de la
AS con el negocio: se habla de tres campos de
arquitectura muy relacionados durante el desarrollo:

Introducción
Estilos Arquitectónicos
Define una familia de sistemas de software en términos de

su organización estructural.
Representa los componentes y las relaciones entre ellos
con las restricciones de su aplicación y las asociaciones y
reglas de diseño para su construcción
Define un vocabulario de componentes y tipos de
conectores.
Ejemplos de Estilos Arquitectónicos
Pipes and filters, Tipos de datos abstractos y OO, Repositorios,
Capas, Basados en Eventos, Intérpretes, etc.

Introducción
Estilos II
La imposición de ciertos estilos arquitectónicos mejora o

disminuye las posibilidades de satisfacción de ciertos
atributos de calidad del sistema [Bosch, 2000]
Cada estilo propicia atributos de calidad, y la decisión de
implementar alguno de los existentes depende de los
requerimientos de calidad del sistema.
Un criterio importante del éxito de los estilos es la forma en
que estos alcanzan de manera satisfactoria los objetivos
de la Ingeniería de Software. [Buschmann et al.,1996]

Introducción
Diferencias entre estilos y patrones arquitectónicos
Estilo Arquitectónico Patrón Arquitectónico

-Sólo describe el esqueleto -Varios rangos de escala, comenzando
estructural y general de las con la definición de la estructura básica
aplicaciones de una aplicación
-Son independientes del contexto -Necesitan de la definición de un contexto
al que puedan ser aplicados del problema
-Cada estilo es independiente de -Dependen de patrones más pequeños,
los otros con los que interactúan; o de patrones
-Expresan técnicas de diseño que los contengan
desde una perspectiva -Expresan un problema recurrente de
independiente de la situación diseño, muy específico, presentando una
actual de un diseño solución, desde el punto de vista del
-Pueden comprenderse también contexto en el que se presenta
como una clasificación de los -Son soluciones generales a problemas
sistemas software M.I.Capel comunes
Tema 2 43/146
Introducción
Patrón Arquitectónico
Definición de Buschmann (1996)

Una regla que consta de tres partes, la cual expresa una
relación entre un contexto, un problema y una solución.
1 Contexto: Es una situación de modelado de una parte del

sistema en la que aparece un problema de diseño.
2 Problema: Es un conjunto de fuerzas que aparecen
repetidamente en el contexto.
3 Solución: Es una configuración que equilibra estas
fuerzas.

Introducción
Patrón Arquitectónico
Definición de Buschmann (1996)

Una regla que consta de tres partes, la cual expresa una
relación entre un contexto, un problema y una solución.
1 Contexto: Es una situación de modelado de una parte del

sistema en la que aparece un problema de diseño.
2 Problema: Es un conjunto de fuerzas que aparecen
repetidamente en el contexto.
3 Solución: Es una configuración que equilibra estas
fuerzas.

Introducción
Patrones II
El uso de ciertos
Para Buschmann son mecanismos, como los
plantillas para arquitecturas estilos y patrones
de software concretas, que arquitectónicos, permite
especifican las propiedades mejorar las características
estructurales de una de calidad en el software
aplicación y tienen un [Bosch, 2000], bien sean
impacto en la arquitectura éstas observables o no en
de subsistemas. tiempo de ejecución [Bass
et al., 2003].

Introducción
El ámbito del patrón es menos general que el del estilo

arquitectónico
Un patrón impone una regla a la arquitectura, describiendo
cómo el software gestionará algún aspecto de su
funcionalidad (p.e.: la concurrencia).
Los patrones arquitectónicos tienden a abordar problemas
comportamentales específicos dentro del contexto de una
arquitectura
Los patrones y los estilos arquitectónicos se pueden
utilizar de forma conjunta para dar forma a la estructura
completa de un sistema.

Introducción
Diferencias según el nivel de abstracción

Introducción
Patrón Interceptor
Permite a determinados servicios ser añadidos de manera
transparente a un marco de trabajo y ser disparados
automáticamente cuando ocurren ciertos eventos
Contexto: Desarrollo de marcos de trabajo que puedan ser
extendidos de manera transparente
Problema: Los marcos de trabajo, arquitecturas software,
etc. ha de poder anticiparse a las demandas de servicios
concretos que deben ofrecer a sus usuarios
Integración dinámica de nuevos componentes sin afectar a
la AS o a otros componentes
Solución: Registro offline de servicios a través de una
interfaz predefinida del marco de trabajo, posteriormente
se disparan estos servicios
M.I.Capel cuando
Tema 2 ocurran determinados
48/146
Introducción
Interceptor

Introducción
Estructura de clases de “Interceptor"

Un FrameworkConcreto que instancia una arquitectura
genérica y extensible
Los Interceptores que son asociados con un evento
particular
InterceptoresConcretos que especializan las interfaces del
interceptor e implementan sus métodos de enlace
Despachadores para configurar y disparar interceptores
concretos
Una Aplicación que se ejecuta por encima de un
framework concreto y utiliza los servicios que éste le
proporciona
Introducción
Implicaciones en la calidad del patrón Interceptor
Beneficios Atributo de calidad Características ISO 9126

Cambiar/incluir servicios de un framework Extensibilidad, Mantenibilidad
sin que sea preciso cambiarlo Flexibilidad,Dinamismo Facilita cambios
Añadir interceptores sin afectar al Acoplamiento Mantenibilidad
código de la aplicación Facilita cambios
Obtención dinámica inform. del framework Monitorización Tolerancia a fallas
con intercept. y objetos–contexto Control Uso de recursos
Infraestructura de servicios estratificada con Encapsulamiento Mantenibilidad
interceptores correspondientes simétricos Facilita cambios,análisis
Reutilización de interceptores en Reusabilidad Mantenibilidad
diferentes aplicaciones Facilita cambios

Introducción
Implicaciones en la calidad 2
Inconvenientes Atributo de calidad Características ISO 9126
Difícil ajuste del número de Complejidad Facilita cambios
despachadores e interceptores Flexib., extensibilidad Facilita análisis
Bloqueo aplicación por Disponibilidad Mantenibilidad
fallo del interceptor Modificabilidad Madurez, Tolerancia Fallas
Degradación rendimiento por Rendimiento Eficiencia,madurez
cascadas de interceptores Bloqueo Tolerancia fallas
Insuficientes interceptores y despachadores reduce la flexibilidad y

extensibilidad del framework concreto.
Sistema demasiado grande e ineficiente, complejo de aprender, implementar,
usar, y optimizar, utilizando demasiados interceptores
Para evitar el bloqueo completo de la aplicación pueden utilizarse estrategias de
time-out, pero esto puede complicar el diseño del framework concreto
Las cascadas de intercepción pueden conllevar una degradación del
rendimiento o un bloqueo de la aplicación

Introducción
Resumen características de calidad

Característica Sub-característica Impacto Atributo
Facilidad de cambio + Reusabilidad
Facilidad de análisis Modificabilidad
Mantenibilidad Encapsulamiento
Extensibilidad
Flexibilidad
Acoplamiento
Dinamismo
Facilidad de cambio - Extensibilidad
Facilidad de análisis Flexibilidad
Complejidad
Modificabilidad
Eficiencia Tiempo de respuesta - Desempeño
Uso de recursos + Monitoreo
Control
Fiabilidad Tolerancia a fallas - Disponibilidad
Bloqueo
+ Monitoreo
Control
Madurez - Disponibilidad
M.I.Capel Tema 2 53/146 Bloqueo
Introducción
Figure: Características ISO del patrón “Interceptor"

Introducción
Patrón Broker
Para modelar sistemas distribuidos compuesto de
componentes software totalmente desacoplados
Contexto: cualquier sistema distribuido y, posiblemente,
heterogéneo con componentes cooperando dentro de un
sistema de información
Problema:¿Cómo estructurar componentes configurables
dinámicamente e independientes de los mecanismos
concretos de comunicación de un sistema distribuido?
Solución: Introducir un componente Broker para mejor
desacoplamiento entre clientes y servidores
Las tareas de los Brokers incluyen la localización del
servidor apropiado, envío de la petición al servidor y
transmisión de los resultados
Introducción
Broker

Introducción
Estructura de clases del patrón Broker
Intermediario: admite las solicitudes, asigna los servidores

y responde a las peticiones de los clientes
Servidor: se registra en el Intermediario e implementa el
servicio
Cliente: accede a los servicios remotos
Proxy Cliente y Proxy Servidor, que proporcionan
transparencia, ocultando los detalles de implementación
del patrón
Puente: le proporciona interoperabilidad al Intermediario

Introducción
Implicaciones en la calidad del patrón Broker

Beneficios Atributos de calidad Característica ISO 9126
Separación código de comunicaciones. Acoplamiento Facilita cambios
Modificabilidad Fac.análisis,pruebas
Independencia de la plataforma de Escalabilidad Facilita cambios
ejecución para la aplicación Uso de recursos
Mejor descomposición del Interoperabilidad Interoperabilidad
espacio del problema Simplicidad Facilita análisis
Independencia de la implementación Modificabilidad Mantenibilidad
concreta de cada capa Flexibilidad Fac.cambios
Interacciones basadas en el Transparencia Funcionalidad
paradigma de objetos Interoperabilidad
Arquitectura software Dinamismo Facilita cambios
muy flexible Facilita análisis
Reducción complejidad de Modificabilidad Facilita cambios
programación distribuida Flexibilidad Facilita análisis
Integración de tecnologías Reusabilidad Facilita cambios
Facilita análisis
Distribución del modelo de Interoperabilidad Portabilidad
Introducción
Inconvenientes Atributos de calidad Características ISO 9126

Empeora el rendimiento de la Rendimiento Eficiencia
aplicación Tiempo respuesta
Impide la verticalidad Optimización Facilidad pruebas
en acceso a capas internas Ocultamiento Uso recursos
Tolerancia fallas
Las capas de abstracción a las que conduce este patrón pueden perjudicar el
desempeño
Usar una capa separada del Broker puede ocultar los detalles sobre cómo la
aplicación utiliza la capa más baja
Eventualmente, optimizaciones específicas del rendimiento de algunas capas
podrían resultar perjudicadas

Introducción

Mantenibilidad Facilidad de cambio + Flexibilidad
Facilidad de análisis Escalabilidad
Reusabilidad
Bajo acoplamiento
Modificabilidad
Dinamismo
Facilidad de análisis + Simplicidad
Facilidad de prueba - Ocultamiento
Eficiencia Uso de recursos + Escalabilidad
- Optimización
Tiempo de respuesta - Desempeño
Funcionalidad Interoperabilidad + Transparencia
Fiabilidad Tolerancia a fallas - Ocultamiento
Portabilidad Adaptabilidad + Multiplataforma
Introducción
Figure: Características ISO del patrón “Broker"

Introducción
Patrón Reflection
Proporciona un mecanismo para cambiar la estructura y
comportamiento de sistemas software dinámicamente
Soporta la modificación de aspectos fundamentales, tales
como estructuras y mecanismos de llamadas a funciones.
Contexto: Cualquier sistema que necesita soporte para
realizar cambios propios y para conseguir persistencia de
sus entidades
Problema: ¿Cómo se puede modificar el comportamiento
de los objetos de una jerarquía dinámicamente sin afectar
a los propios objetos en su configuración actual?
Solución: Hacer que el software sea “auto-consciente" de
su función y comportamiento, haciendo que los aspectos
seleccionados sean M.I.Capel
accesibles
Temapara
2 su adaptación y
62/146
Introducción
Reflection

Introducción
Estructura de clases del patrón Reflection

Meta Nivel: proporciona la información acerca de las
propiedades escogidas del sistema y hace que el sistema
sea auto-consciente
Meta Objetos: encapsulan y representan información
acerca del software
Nivel Base: incluye la lógica de la aplicación
Los cambios mantenidos en el Meta Nivel afectan
consecuentemente al comportamiento del Nivel Base
La implementación del Meta Nivel utiliza Meta Objetos
para mantenerse independiente de aquellos aspectos que
son propensos a cambiar
Introducción
Implicaciones en la calidad del patrón Reflection
Beneficios Atributos de calidad Características ISO 9126

Comprobación correctitud desde Correctitud Funcionalidad
el nivel de MetaObjetos Precisión
Ejecución de los cambios Dinamismo Facilidad cambios
desde el nivel de MetaObjetos Facilidad análisis
Modificación y extensión de Modificabilidad Mantenibilidad
componentes software facilitada Extensibilidad Facilidad cambios
Cambios en el software del Modificabilidad Mantenibilidad
NivelBase facilitados Extensibilidad Facilidad cambios
Asume modificaciones no explícitas Extensibilidad Mantenibilidad
del código fuente Facilidad cambios
Soporte para muchos Modificabilidad Mantenibilidad
tipos de cambios Facilidad cambios

Introducción
Inconvenientes Atributos de calidad Características ISO 9126

Complejidad de diseño e implementación Complejidad Facilidad análisis
por los niveles y protocolo meta–objetos Facilidad pruebas
Demasiados meta–objetos en Rendimiento Uso recursos
la aplicación final Eficiencia
Modificaciones en meta–nivel pueden Fallas Madurez
causar daños comportamiento del sistema Tolerancia a fallas
Rendimiento sistema puede ser afectado Complejidad Eficiencia
por complejidad diseño del patrón Tiempo respuesta
Difícil adaptación a la evolución de los Adaptabilidad Tiempo respuesta
productos generados con el patrón Eficiencia

Introducción

Mantenibilidad Facilidad de cambio + Modificabilidad
Facilidad de análisis Extensibilidad
Dinamismo
Facilidad de análisis - Complejidad
Facilidad de prueba
Funcionalidad Precisión + Correctitud
Eficiencia Uso de recursos - Desempeño
Complejidad
Fiabilidad Madurez - Propensión a fallas
Tolerancia a fallas
Introducción
Figure: Características
M.I.Capel ISOTema
del2 patrón
68/146 “Reflection"
Introducción
Categorización de los Estilos Arquitectónicos

Arquitecturas centradas en los datos
El núcleo de estas arquitecturas es un repositorio o una base
de datos a la que acceden las aplicaciones–cliente
Las aplicaciones cliente acceden a los datos o ejecutan sus
procesos de forma totalmente independiente entre ellos
Propician la integrabilidad
Arquitecturas de Flujo de Datos

Los datos de entrada han de ser transformados tras la
actuación de componentes de la AS hasta producir los datos
de salida
Sus componentes se llaman filtros y encauzamientos, que
Introducción

Arquitecturas de Llamada–retorno
Arquitecturas Programa principal–subprograma: jerarquía
de control donde se invocan varios componentes que, a su
vez, pueden invocar a otros componentes
Arquitecturas Llamada a procedimiento remoto: los
componentes se distribuyen ahora a través de múltiples
computadores conectados por una red
Arquitecturas Estratificadas
Estructuradas en capas que realizan operaciones que van
acercándose a nivel de las instrucciones–máquina:
-operaciones nivel interfaz de usuario
Introducción
Arquitecturas Orientadas a Objeto

Los componentes de un sistema que sea conforme con este
tipo de arquitectura encapsulan los datos y las operaciones
que deben ser aplicadas para manipularlos
La comunicación y coordinación entre componentes se llevan a
cabo mediante paso de mensajes

Introducción
Arquitecturas de referencia
Conceptos
Los estilos arquitectónicos se pueden aplicar a muchos
dominios de aplicaciones
Reutilización de la estructura arquitectónica común de los
modelos que se aplican a un mismo dominio de
aplicaciones
Arquitecturas específicas de un dominio de aplicaciones

Modelos genéricos: abstracciones de un número de
sistemas con elementos comunes.
Modelos de referencia: AS idealizada que incluye todas
las características que los sistemas
M.I.Capel Tema 2 software de esa clase
72/146
Introducción
Arquitecturas de referencia
Conceptos
Los estilos arquitectónicos se pueden aplicar a muchos
dominios de aplicaciones
Reutilización de la estructura arquitectónica común de los
modelos que se aplican a un mismo dominio de
aplicaciones
Arquitecturas específicas de un dominio de aplicaciones

Modelos genéricos: abstracciones de un número de
sistemas con elementos comunes.
Modelos de referencia: AS idealizada que incluye todas
las características que los sistemas
M.I.Capel Tema 2 software de esa clase
72/146
Introducción
Características de las arquitecturas de referencia
No se consideran como una guía de implementación de

los sistemas software
Se utilizan para discutir la aplicación de AS específicas de
un dominio de aplicaciones y compararlas
Proporcionan un vocabulario de términos que aluden a los
sistemas dentro de un mismo dominio de aplicaciones
Proporcionan una base conceptual con respecto a la cual
se pueden evaluar las diferentes propuestas
arquitectónicas
Ejemplos de arquitecturas de referencia: el modelo OSI de
redes, modelo de referencia CASE
Introducción

Introducción
Ejemplo: Modelo de Referencia CASE

Tipos de servicicios del modelo
Repositorio de datos: manejo de los items de datos y sus
relaciones
Integración de datos: la base para conseguir la integración
de los datos
Gestión de tareas: definición y representación de los
modelos de procesos
Mensajes: comunicaciones herramienta–herramienta,
entorno–herramienta y entorno–entorno
Interfaces de usuario: presentación integrada de la
funcionalidad y servicios del sistema
Introducción Tecnologías para implantar un SOA
Mecanismos Arquitectónicos Tecnologías para implantar un SOA
Arquitecturas Orientadas a Componentes y Servicios Ciclo de Vida
Lenguajes de Defición Arquitectónica (ADLs) Business Process Modeling
Concepto y Motivación
Concepto
Las arquitecturas basadas en componentes y servicios: la
funcionalidad de las aplicaciones ahora se implementa en la
forma de componentes reutilizables e invocables mediante
interfaces estándar, que pueden combinarse para crear
funciones progresivamente más complejas.
Motivación
La dificultad de las arquitecturas tradicionales para integrarse
en los procesos de negocio reside en que sus aplicaciones no
están diseñadas para ser integradas con otras
Arquitectura simple de una aplicación
Figure: Aplicación de negocios

Servicios
¿Qué es un servicio?
“Representación estándar para cualquier recurso
computacional o de información que pueda ser utilizado por
otras aplicaciones", Turner (2003)
“Organización global encargada de establecer y adoptar los

estándares de los servicios Web", OASIS (Organization for the
Advancement of Structured Information Standards)

Características de un servicio
La provisión del servicio es independiente de la plataforma de

la aplicación que lo proporciona
Capacidades externas para procesamiento

Acceso consistente a través de interfaces
Adaptación a políticas y restricciones predefinidas
Las aplicaciones se construyen enlazando servicios desde

varios proveedores utilizando lenguajes de programación (p.e.
Java) o de instrumentación de servicios (p.e. BPEL)
Tipos de servicios
Servicios:
Interacción
Proceso
Servicios de Aplicación de Negocios
Información
Servicios de Acceso
Socios
Servicios de Innovación y Optimización
Servicios de Desarrollo
Manejo de Servicios IT
Antecedentes de servicios SOA

Domain Name System (DNS)
Es una parte muy importante de la configuración de un sistema
distribuido
Suele “entenderse" como un computador que proporciona

información de un dominio de nombres a una red
Servicio de Dominio de Nombres

Garantiza de nombres únicos en toda la red, insensibles a
mayúsculas–minúsculas, que consisten en una cadena de
caracteres alfanuméricos y guiones separados por puntos, que
el DNS hace corresponder con números de IP y otra
información M.I.Capel Tema 2 81/146
Antecedentes de servicios SOA II
Servicios de Intermediación
Servicio de meta–información (“trading") esencial de los
sistemas abiertos
Actúa como un mediador global entre servicios,
aplicaciones y clientes
Permite construir un ambiente de computación a escala
mundial
Evolución constante de servicios y aplicaciones
Ingeniería de Software para Sistemas Abiertos

Antecedentes de servicios SOA III
Servicios de Eventos
Sirven de soporte al intercambio de mensajes asíncrono
entre objetos en Sistemas Distribuídos
Dependen de una infraestructura basada en eventos (
como JEDI)
Ejemplos de servicios de eventos:
Servicios de Notificación de Eventos (SIENA)
CORBA Event Service
Servicios de alerta que pueden ser construidos sobre
servicios de eventos

Motivación para SOA
Proveedores de tecnología (consultores y usuarios), están de

acuerdo en que el enfoque Service Oriented Architecture
(SOA) permite mejorar la calidad de las aplicaciones y dar una
mejor respuesta a las partes interesadas de un modelo de
negocio

Modelado de Procesos de Negocios

“Proceso de Negocio" (BP)
Conjunto de servicios interactivos, estructurados y
relacionados que de manera integrada son capaces de
proporcionar una funcionalidad compleja para implementar los
procesos y tareas de un negocio de acuerdo con sus reglas.
Modelado de Procesos de Negocio (BPM)

Se trata de una actividad conceptual para comprender el
funcionamiento y describir la compleja estructura de los
procesos de negocio de una empresa, de tal manera que
dichos procesos puedan ser entonces analizados y mejorados.
Representación de un modelo de proceso de negocio

Caracterización de SOA
¿Qué es SOA?
Una arquitectura flexible y estándar que unifica los procesos de
negocio estructurando grandes aplicaciones como colecciones
de servicios.
Estas aplicaciones pueden ser usadas por usuarios dentro o

fuera de la organización.
Estilo arquitectónico
SOA es también un estilo de arquitectura donde todas las
funcionalidades, ya sean existentes o nuevas, son agrupadas
en servicios que se comunican entre sí.
Tecnologías de soporte para arquitecturas distribuidas
Figure: Grado de cobertura de propiedades requeridas

Requerimientos de un SOA
Interoperabilidad entre los distintos sistemas y lenguajes

de programación presentes en la organización
Utilización de un protocolo estándar
Los servicios han de ser descritos con un lenguaje claro y
preciso independiente de la plataforma
Mecanismo de búsqueda para obtener remotamente los
servicios que ya han sido implementados

Servicios Web
Los Servicios Web son servicios implementados utilizando
estándares como SOAP, WSDL y UDDI para ser accedidos a
través de una red, preferiblemente Internet y ejecutados
remotamente
Protocolo estándar
Service Oriented Architecture Protocol (SOAP)
Lenguaje de descripción de servicios

Web Service Description Language (WSDL)
Descubrimiento de servicios disponibles

Universal Description Discovery
M.I.Capel and Integration
Tema 2 90/146 (UDDI)
Principios de Diseño de SOA
Reglas para desarrollar, mantener y usar servicios

Encapsulado (en servicios SOA): Para los servicios que no
estén diseñados para ser parte de SOA
Acoplamiento Ligero: Independencia entre servicios, sólo
se “conocen"
Contratos: Los servicios deben cumplir con unas reglas de
comunicación preestablecidos en documentos
Abstracción: La lógica interna de los servicios no tiene que
ser conocida por el ambiente en el que se van a ejecutar

Principios de Diseño de SOA II
Reglas para desarrollar, mantener y usar servicios

Reutilización: Los servicios deben ser diseñados siempre
para su reutilización por varias aplicaciones remotas
Composición: Colecciones de servicios han de poder ser
compuestos para formar otros servicios
Autonomía: Los servicios son los únicos que controlan su
lógica interna
Optimización: Deben ser lo más eficientes posible
Descubrimiento: Los servicios son diseñados para facilitar
su descubrimiento en el ambiente en que se ejecutan
Tecnologías
XML
Un lenguaje de marcas. XML se basa en la combinación de
texto con información que describe ese texto. En XML se
utilizan las etiquetas (tags) para describir bloques de texto. Fue
diseñado para compartir fácilmente las estructuras de datos a
través de la red.
SOAP
Simple Object Access Protocol es un protocolo estándar bajo
el auspicio de la W3C que define cómo dos objetos en
diferentes procesos pueden comunicarse por medio de
intercambio de datos XML
Tecnologías
WSDL
Web Service Description Language es un lenguaje basado en
XML utilizado para describir los Servicios Web. Este lenguaje
define a los servicios como colecciones de puertos, donde
cada puerto indica una función del servicio que está siendo
descrito. Así, cualquier usuario de un servicio puede leer el
WSDL y saber qué funciones se pueden llamar utilizando
SOAP.
UDDI
Universal Description, Discovery and Integration es un registro
basado en XML para listar servicios en Internet. Está diseñado
para ser interrogado conM.I.Capel
mensajes SOAP
Tema 2 y proveer acceso a
94/146
Tecnologías
BPEL
Business Process Execution Language es un lenguaje
ejecutable de procesamiento de negocios basado en XML.
BPEL nació como la combinación de WSFL (IBM) y XLANG
(Microsoft) para crear un estándar mundial de ejecución de
procesos de negocio. Este lenguaje se utiliza para orquestar la
ejecución de un proceso, llamando a los servicios que va
necesitando.

Implementación de WS
Figure: Implementación de una arquitectura para Web–Services

Bus de Servicios de Empresa

ESB
Enterprise Service Bus es el punto de comunicación entre
todos los servicios. Funciona de forma transparente. No debe
contener lógica del negocio.

Arquitectura SOA modelo

Ciclo de vida de un SOA
Modelado del negocio.

Diseño de un sistema de información
Implementación del sistema de información
Evaluación del sistema para refinarlo y volver a modelar


Modelado
Capturar el diseño del negocio (de requerimientos y
objetivos)
Traducir a procesos de negocio y metas
Se recomienda elaborar distintos escenarios que permitan
obtener más información sobre los procesos de negocio
Definir los Key Performance Indicators (KEI)

Desarrollo
Convertir el diseño de negocio en definiciones de
procesos y actividades
Transformarlos a los servicios de la arquitectura
Estudiar aplicaciones ya existentes y reutilizar
(asegurando estándares SOA)
Implementar los servicios que faltan

Despliegue
Crear un ambiente en el que se ejecuten las aplicaciones
Resolver dependencias
Condiciones operacionales, requisitos de capacidad y
restricciones de integridad y acceso

Gestión
Determinar la manera de mantener el ambiente
operacional y las políticas de implementación
Monitorizar la efectividad de las solicitudes de servicio y el
tiempo de respuesta
Mantener registros de fallos y recuperar tareas
Monitorización de las métricas de negocio (KPI) que se
definieron en el diseño

Gobernabilidad
Definir los derechos de decisión para el desarrollo,
despliegue y manejo de nuevos servicios
Supervisar que se cumplen las políticas, estándares,
proceso y procedimientos
Ayuda a identificar qué proyectos contribuyen
principalmente a conseguir las metas de negocio
Definir los roles y las responsabilidades de cada miembro
del equipo de forma clara

Conceptos generales sobre arquitecturas orientadas a servicios
Introducción
Ciclo de Vida
Microsoft Service Management

Introducción
Ciclo de Vida
Enfoque de SUN

Introducción
Ciclo de Vida
Ejemplo de arquitectura de SUN

Modelado de Procesos de Negocio

BPMN
“Business Process Model and Notation"(BPMN) se considera
actualmente como el lenguaje de modelado de procesos de
negocio estándar.
Características
BPMN utiliza una notación gráfica similar a UML
Tal como éste, la semántica de BPMN no está
formalmente definida
La ausencia de tal semántica produce un problema para la
validación de los modelos de procesos de negocio
BPMN 2.0 intenta modelar
M.I.Capel los procesos
Tema 2 108/146 con restricciones
Modelado de Procesos de Negocio

BPMN
“Business Process Model and Notation"(BPMN) se considera
actualmente como el lenguaje de modelado de procesos de
negocio estándar.
Características
BPMN utiliza una notación gráfica similar a UML
Tal como éste, la semántica de BPMN no está
formalmente definida
La ausencia de tal semántica produce un problema para la
validación de los modelos de procesos de negocio
BPMN 2.0 intenta modelar
M.I.Capel los procesos
Tema 2 108/146 con restricciones
La notación BPMN

Ejemplo de especificación con BMPN
Figure: Proceso logístico de una farmacia de hospital

Un tipo especial de diagrama de flujo: Business

Process Diagram (BPD)
Gateways
Events
Activities
Flows

Representación gráfica de un estado en BPMN
links & dependences
Type
in Type
exit_3
N exit_2
out exit_1
send/receive
error

Representación con BPD de las entidades BMPN
Figure: Representación gráfica de los elementos de BPMN

Extendido.
Notación de modelado de BPMN extendido
EBPMN necesita de la precisión semántica que le

proporciona un lenguaje formal a sus elementos básicos
para transformar sus procesos de negocio en modelos
ejecutables
Al siguiente conjunto de constructos EBPMN se le puede

proporcionar una interpretación semántica:
Parallel Fork Gateway
Parallel Join Gateway
Data–based OR gateways
Event–based OR gateways
OR–join gateways
Parallel Fork Gateway
Se necesita una rama del P(i) por cada flujo de control

saliente representado en estado de la puerta:
Figure: Modelo “black–box" de la puerta paralela de EBPMN.

Data–based OR Gateway
Se utilizan puertas inclusivas para la selección de un

conjunto de ramas de salida entre todos los flujos:
Figure: Modelo “black–box" del estado de la puerta OR de EBPMN.

Formalización de extensiones temporales de EBPMN

En muchos modelos, no cumplir con las restricciones
temporales o respetar el acceso a recursos puede
ocasionar la violación de las reglas de proceso de negocio
La definición de delays asociados a los eventos BPMN 2.0
intermedios (timers) no es suficiente para definir
restricciones precisas es las especificaciones de los
procesos de negocio
Nuevas entidades de análisis han de ser incluidas en
BPMN de tal manera que puedan cumplirse las
restriciones temporales y de acceso a recursos
Y han de tener asociados operadores cuantificables para
expresar intervalos de activación, plazos de tiempo
(deadlines), etc. M.I.Capel Tema 2 117/146
Evento de comienzo, tiempo máximo y mínimo de una

actividad
Elegimos una extesión de BPMN que incluye una duración
máxima y míinima para cada actividad de BPMN:
Figure: Anotaciones temporales de la entidad “actividad" de EBMPN

Tareas de servicios
El envio/recepción de mensajes debe ser llevado a cabo

dentro de los límites de tiempo de las actividades que
envían o reciben
Estas actividades no pueden entrar en un estado de
inter–bloqueo (deadlock state)

Tareas de servicios II

Interpretación Semántica
La comunicación debe tener lugar dentro de los intervalos

definidos por las condiciones:
s(m1 ), s(m2 ) ∈
[max{vS1 , vS2 }, min{vS1 + S1.ran.min, vS2 + S2.ran.min}]

Representación en EBPMN de un CRM

Introducción
Caso de Estudio: An Architecture Description Interchange Languag
Descripción de una AS
ISO/IEC/IEEE 42010
Guiar en la construcción y mantenimiento del sistema
Ayudar a planear los costes y evolución del sistema
Servir como un medio para el análisis, evaluación o
comparación de arquitecturas software
Facilitar la comunicación entre las partes interesadas en
las arquitecturas y los sistemas
Documentar el conocimiento arquitectónico más allá del
ámbito de los proyectos individuales
Capturar idiomas arquitectónicos reutilizables (tales como
estilos arquitectónicos y patrones)
Introducción
Descripción de una AS
Ventajas para el diseño arquitectónico
La descripción inicial del sistema pueda plasmarse de
forma textual o gráfica utilizando distintos estilos y
componentes arquitectónicos
Desarrollar la descripción de subsistemas en función de la
información que recibe o produce
Descripción del comportamiento y sus elementos
asociados
Proporciona una documentacuón de alto nivel de la AS y
del sistema objetivo
Con un ADL que proporcione facilidades para ello, puede
realizarse análisis deM.I.Capel
desempeño,
Tema 2
disponibilidad,
124/146
Introducción
ADL
Concepto
Resuelven el problema de la representación formal de una
arquitectura software desde un punto de vista sintáctico y
semántico [Bass et al. 1998][Clements 1996]
Un ADL permite representar, analizar y especificar una AS
Pueden ser descriptivo–formales o semiformales, gráficos,
o ambas cosas
Algunos han sido sólo definidos formalmente y otros
cuentas con herramientas que los soportan

Introducción
ADL
Actuales
ACME (carnegie-Mellon), CODE, UNICON, Wrigth, RAPIDE,
Darwin (Imperial College), xADL (UCI), DAOP-ADL
(Universidad de Málaga) y ByADL (Universidad de L’Aquila)
Características
Los primeros ADLs hacían más énfasis en el modelado de
componentes, conectores y configuraciones.
Los ADLs actuales (ArchiMate, SysML, etc.) tienden a ser
lenguajes descriptivos de un espectro mucho más amplio
Se pueden utilizar lenguajes de propósito general como
UML como ADLs asíM.I.Capel
como para
Tema 2modelar
126/146 procesos de
Introducción
Requerimientos que han de satisfacer los ADLs
[Bass 1998][Luckhan y Vera 1995][Shaw y Garlan 1996]

Capacidad de representación de componentes y
elementos de análisis arquitectónico (conectores,
interfaces, etc.)
Proporcionar capacidad de análisis con el soporte de
herramientas software
Integridad comunicacional
Soporte a las tareas de creación, refinamiento y validación
de una AS

Introducción
Requerimientos que han de satisfacer los ADLs
Capacidad para representar la mayoría de los patrones

arquitectónicos conocidos, directa o indirectamente
Capacidad de proveer vistas del sistema que expresen
información arquitectónica
Soportar la especificación de familias de
implementaciones que satisfacen una arquitectura común
Capacidad de análisis basada, o bien la capacidad para la
rápida generación de prototipos

Introducción
An Architecture Description Interchange Language
Caracteríticas del lenguaje ACME

Una ontología arquitectónica que consiste en 7 elementos
de diseño arquitectónico básico
Una notación flexible que soporta la asociación de
información no estructural utilizando sub–lenguajes
definidos externamente
Un mecanismo de tipos para abstraer estilos e idiomas
arquitectónicos, reutilizables y de uso general
Un marco de trabajo semántico abierto para razonar
acerca de las descripciones arquitectónicas

Introducción
Figure: Diagrama Cliente–Servidor Simple

Introducción
Ontología arquitectónica ACME
Elementos de ACME
componentes, conectores, sistemas, puertos, roles,
representaciones y rep-maps
Los elementos más comunes

Componentes: los elementos computacionales primarios y
los almacenes de datos de un sistema
Conectores: representan interacciones entre componentes
Sistemas: representan las configuraciones de
componentes y conectores

Introducción
Ontología arquitectónica ACME
Elementos de ACME
componentes, conectores, sistemas, puertos, roles,
representaciones y rep-maps
Los elementos más comunes

Componentes: los elementos computacionales primarios y
los almacenes de datos de un sistema
Conectores: representan interacciones entre componentes
Sistemas: representan las configuraciones de
componentes y conectores

Introducción
Sistema Cliente-Servidor Simple en Acme

1 System simple_cs = {
2 Component c l i e n t e = { P o r t e n v i a r −p e t i c i o n ; } ;
3 Component s e r v i d o r = { P o r t r e c i b i r −p e t i c i o n ; } ;
4 Connector r p c = { Roles { llama , llamado } } ;
5 Attachments {
6 c l i e n t e . e n v i a r −p e t i c i o n t o r p c . l l a m a ;
7 s e r v i d o r . r e c i b i r −p e t i c i o n t o r p c . llamado ;
8 } }
Puerto enviar-peticion en el componente cliente

Sólo un puerto recibir-peticion en el servidor
Conector con 2 roles, denominados llama y llamado
La topología de este sistema se declara listando un
conjunto de attachments
Introducción
Sistema Cliente-Servidor Simple en Acme

2 Component c l i e n t e = { P o r t e n v i a r −p e t i c i o n ; } ;
3 Component s e r v i d o r = { P o r t r e c i b i r −p e t i c i o n ; } ;
4 Connector r p c = { Roles { llama , llamado } } ;
5 Attachments {
6 c l i e n t e . e n v i a r −p e t i c i o n t o r p c . l l a m a ;
7 s e r v i d o r . r e c i b i r −p e t i c i o n t o r p c . llamado ;
8 } }
Puerto enviar-peticion en el componente cliente

Sólo un puerto recibir-peticion en el servidor
Conector con 2 roles, denominados llama y llamado
La topología de este sistema se declara listando un
conjunto de attachments
Introducción
Figure: Elementos de una descripción ACME

Introducción
Descripción jerárquica de AS
Cada componente o conector posee una descripción, de

bajo nivel, más detallada
Representaciones: múltiples vistas de entidades
Aunque, no se pueden resolver sintácticamente
Fronteras de una encapsulación
Múltiples niveles de refinamiento en las descripciones
Concepto de representation map (rep-map)
rep-map simples:
asociación entre puertos internos y puertos externos
asociación entre roles internos y roles externos
En otros casos los constructos rep-map pueden ser mucho
más complejos M.I.Capel Tema 2 134/146
Introducción
Figure: Representaciones y propiedades de un componente

Introducción
Anotación de entidades
Propiedades ACME
Cada ADL define un conjunto de información para añadir a
la información estructural de la AS: datos comunicados,
protocolos de interacción, restricciones de planificación,
uso de recursos . . .
Cada una de las 7 entidades de ACME puede ser anotada
Anotación de la estructura arquitectónica mediante
listas de propiedades

Introducción
Cómo usar las propiedades ACME
El significado de las propiedades no es definido

explícitamente
ACME sirve como un vehículo de convencionalización de
propiedades entre varios ADLs
Las propiedades poseen utilidad sólo cuando una
herramienta las utiliza
Comportamiento por defecto de una herramienta,
delimitadores de propiedades

Introducción
Cómo usar las propiedades ACME (2)
El problema de representar estructuras arquitectónicas

abstractas
El atributo type indica un sub–lenguaje
Tipos simples: integer, string, and boolean
Utilización de los indicadores: name y type

Introducción
Propiedades del sistema Cliente–Servidor simple
2 Component c l i e n t e = {
3 P o r t e n v i a r −p e t i c i o n ;
4 P r o p e r t y Aesop−s t y l e : s t y l e −i d = c l i e n t −s e r v e r ;
5 P r o p e r t y UniCon−s t y l e : s t y l e −i d = cs ;
6 P r o p e r t y source−code : e x t e r n a l = "CODE−LIB / c l i e n t . c " ;
7 }
8 Component s e r v i d o r = {
9 P o r t r e c i b i r −p e t i c i o n ;
10 P r o p e r t y idempotence : boolean = t r u e ;
11 P r o p e r t y max−c o n c u r r e n t−c l i e n t s : i n t e g e r = 1 ;
12 source−code : e x t e r n a l = "CODE−LIB / s e r v e r . c " ;
13 }
14 // ...

Introducción
Propiedades del sistema Cliente–Servidor simple (2)
1 \\ ...
2 Connector r p c = {
3 Role l l a m a ;
4 Role llamado ;
5 P r o p e r t y asynchronous : boolean = t r u e ;
6 max−r o l e s : i n t e g e r = 2 ;
7 p r o t o c o l : Wright = " . . . " ;
8 }
9 Attachment c l i e n t e . e n v i a r −p e t i c i o n t o r p c . l l a m a ;
10 Attachment s e r v i d o r . r e c i b i r −p e t i c i o n t o r p c . llamado ;
11 }

Introducción
Marco de trabajo semántico y abierto de ACME
ACME se enfoca a describir la estructura de una AS

No proporciona ninguna semántica computacional de las
arquitecturas que describe, de eso se encarga un marco
de trabajo semántico y abierto para que lo usen otros
ADLs
Las especificaciones ACME intentan representar un
predicado denominado prescripción
Proporcionan una correspondencia sencilla entre los
aspectos estructurales de una AS en un formalismo lógico
basado en relaciones y restricciones

Introducción
Prescripción general para el Cliente-Servidor

1 exists c l i e n t , server , rpc |
2 component ( c l i e n t ) ^
3 component ( s e r v e r ) ^
4 connector ( rpc ) ^
5 a t t a c h e d ( c l i e n t . send−request , r p c . c a l l e r ) ^
6 a t t a c h e d ( s e r v e r . r e c e i v e −request , r p c . c a l l e e )
Falta especificar que todos los componentes han sido

identificados
y las variables existenciales han de referirse a diferentes
entidades

Introducción
Prescripción general para el Cliente-Servidor

6 a t t a c h e d ( s e r v e r . r e c e i v e −request , r p c . c a l l e e )
Falta especificar que todos los componentes han sido

identificados
y las variables existenciales han de referirse a diferentes
entidades

Introducción
Prescripción más elaborada

6 a t t a c h e d ( s e r v e r . r e c e i v e −request , r p c . c a l l e e ) ^
7 c l i e n t != server ^
8 server != rpc ^
9 c l i e n t != rpc ^
10 ( f o r a l l y : component ( y ) =>
11 y = c l i e n t | y = server ) ^
12 ( f o r a l l y : c o n n e c t o r ( y ) => y = r p c ) ^
13 ( f o r a l l p , q : a t t a c h e d ( p , q ) =>
14 ( p= c l i e n t . send−r e q u e s t ^ q= r p c . c a l l e r )
15 | ( p= s e r v e r . r e c e i v e −r e q u e s t ^ q= r p c . c a l l e e ) )

Introducción
Gestión de las propiedades definidas
Nombres de propiedades
Actúan como predicados de la Lógica:
NombreP : ℘(A) → {V , F }
Aesop − style(cliente) = client − server

Unicon − style(cliente) = cs
El predicado devuelve el valor del nombre de la propiedad para

la entidad cliente

Introducción
Gestión de las propiedades definidas (2)
Interpretación de valores de las propiedades
Connector rpc = {
Roles {llama, llamado}
Property protocol : Wright = ”...”; }
Las herramientas específicas que entiendan el sublenguaje

Wright pueden interpretar el valor de la especificación del
protocolo anterior para descubrir una semántica propia del ADL
más detallada

Introducción
Lenguajes de descripción de arquitecturas

ADLs actuales
Rapide: se basa en la noción matemática de power sets y
posee estructuras de programación muy potentes.
UniCon: un ADL pensado para ayudar a los diseñadores a
definir AS utilizando abstracciones identificadas.
Aesop: intenta dar solución al problema de la reutilización
de estilos arquitectónicos.
Wright: se trata de un lenguaje formal que incluye
componentes con puertos, conectores con roles ... y el
pegamento para ligarlos. Los estilos arquitectónicos se
pueden formalizar utilizando predicados
ACME: un ADL de segunda
M.I.Capel generación,
Tema 2 146/146 que intenta hacer

Arquitecturas Software

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Arquitecturas Software

Hochgeladen von

Copyright:

Verfügbare Formate

Introducción

ETS Ingenierías Informática

M.I.Capel Tema 2 1/146

M.I.Capel Tema 2 4/146

M.I.Capel Tema 2 5/146

Ubicación dentro de proceso de diseño

El diseño arquitectónico representa el puente entre la

M.I.Capel Tema 2 6/146

Existe un solapamiento entre análisis y especificación de

M.I.Capel Tema 2 7/146

Motivación de la Arquitectura de Software

Existen unas necesidades fundamentales que justifican la

M.I.Capel Tema 2 8/146

Un AS es el resultado de diversas influencias técnicas, del

Recomendaciones para el proceso

La arquitectura debe ser producto del equipo

M.I.Capel Tema 2 10/146

Recomendaciones para el producto

M.I.Capel Tema 2 11/146

Recomendaciones para el producto

M.I.Capel Tema 2 11/146

Seguridad (control acceso a la información)

AS y requisitos no–funcionales III

M.I.Capel Tema 2 14/146

Si una propiedad de un elemento arquitectónico no es

M.I.Capel Tema 2 16/146

Plantilla de Descripción Arquitectónica

M.I.Capel Tema 2 17/146

Descripción de una Arquitectura Software

Una AS proporciona la definición del sistema objetivo en

M.I.Capel Tema 2 18/146

Elementos notacionales de una AS

M.I.Capel Tema 2 19/146

Elementos notacionales de una AS II

M.I.Capel Tema 2 20/146

Protocolo para obtener la representación de una AS

Proceso de Diseño Orientado a Objetos: un caso de

1 Entender y definir los modos de uso y el contexto del

M.I.Capel Tema 2 23/146

Selección de una arquitectura software

Arquitectura estratificada (por capas)

M.I.Capel Tema 2 24/146

Elementos notacionales: UML

Cada capa incluye a otros componentes del sistema

M.I.Capel Tema 2 25/146

Arquitectura inicial del sistema objetivo

M.I.Capel Tema 2 26/146

Modelos de uso y contexo del sistema

Guiado por la descripción de las interacciones del sistema

M.I.Capel Tema 2 28/146

M.I.Capel Tema 2 29/146

M.I.Capel Tema 2 30/146

Los objetos tienden a emerger durante el diseño

M.I.Capel Tema 2 31/146

M.I.Capel Tema 2 32/146

Carácter pasivo/activo de los objetos

Los objetos pasivos ejecutan sus métodos por petición del

M.I.Capel Tema 2 33/146

Modelos estáticos y dinámicos

M.I.Capel Tema 2 35/146

Modelo de secuencia de operaciones

M.I.Capel Tema 2 36/146

M.I.Capel Tema 2 37/146

Especificar las interfaces de objetos