Arquitecturas de Software

Introducción
Mecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y Servicios
Lenguajes de Deﬁció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
Especiﬁcación GRáﬁca de Procesos de Negocio
Formalization de las extensiones temporales de EBPMN

Introducción
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 de software, propiedadesM.I.Capel Tema 2 3/146

Introducción
El diseño arquitectónico
deﬁnición
Consiste en una actividad inicial de la fase de diseño de un
sistema software cuyo objetivo es identiﬁcar 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
especiﬁcació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 justiﬁcan 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
Inﬂuencias
Un AS es el resultado de diversas inﬂuencias 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 deﬁnida y
encapsular toda la información
Los atributos de calidad se deben alcanzar usando
tácticas especíﬁcas 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, ﬁabilidad, 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 estratiﬁcada donde los
elementos más críticos se ubiquen en las capas más internas y
cuyo acceso esté protegido muy rigurosamenteM.I.Capel Tema 2 12/146

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 arquitectń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 arquitectónicaM.I.Capel Tema 2 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
Categoría
Suposiciones
Restricciones
Alternativas
Argumentos
Implicaciones
Decisiones relacionadas
Productos de trabajo
Notas

Introducción
Una AS proporciona la deﬁnició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, ﬁltros 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 reﬂejan 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 ﬁnal

Introducción
Protocolo para obtener la representación de una AS
1 deﬁnir 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
Deﬁnition (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. Los informes se pueden imprimirM.I.Capel Tema 2 22/146

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 estratiﬁcada (por capas)
Cada capa sólo necesita del procesamiento de la capa
inferior para operar
Capas identiﬁcadas:
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
Identiﬁcación de subsistemas

Introducción
Arquitectura inicial del sistema objetivo

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

Introducción
Patrón Arquitectónico
Deﬁnició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 conﬁguración que equilibra estas
fuerzas.

Introducción
Patrones II
Para Buschmann son
plantillas para arquitecturas
de software concretas, que
especiﬁcan las propiedades
estructurales de una
aplicación y tienen un
impacto en la arquitectura
de subsistemas.
El uso de ciertos
mecanismos, como los
estilos y patrones
arquitectónicos, permite
mejorar las características
de calidad en el software
[Bosch, 2000], bien sean
éstas observables o no en
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íﬁcos 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 ofﬂine de servicios a través de una
interfaz predeﬁnida del marco de trabajo, posteriormente
se disparan estos servicios cuando ocurran determinadosM.I.Capel Tema 2 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 conﬁgurar 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
Beneﬁcios 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 estratiﬁcada 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
Mantenibilidad
Facilidad de cambio
Facilidad de análisis
+ Reusabilidad
Modificabilidad
Encapsulamiento
Extensibilidad
Flexibilidad
Acoplamiento
Dinamismo
Facilidad de cambio
- Extensibilidad
Flexibilidad
Complejidad
Modificabilidad
Eficiencia Tiempo de respuesta - Desempeño
Uso de recursos + Monitoreo
Control
Fiabilidad Tolerancia a fallas - Disponibilidad
Bloqueo
+ Monitoreo
Control
Madurez - Disponibilidad
BloqueoM.I.Capel Tema 2 53/146

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 conﬁgurables
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 resultadosM.I.Capel Tema 2 55/146

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 Eﬁciencia
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íﬁcas del rendimiento de algunas capas
podrían resultar perjudicadas

Introducción
Mantenibilidad Facilidad de cambio
+ Flexibilidad
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 + MultiplataformaM.I.Capel Tema 2 60/146

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 accesibles para su adaptación yM.I.Capel Tema 2 62/146

Introducción
Reﬂection

Introducción
Estructura de clases del patrón Reﬂection
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
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 ISO del patrón “Reﬂection"M.I.Capel Tema 2 68/146

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 ﬁltros 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 Estratiﬁcadas
Estructuradas en capas que realizan operaciones que van
acercándose a nivel de las instrucciones–máquina:
-operaciones nivel interfaz de usuarioM.I.Capel Tema 2 70/146

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íﬁcas 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 software de esa claseM.I.Capel Tema 2 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íﬁcas 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: deﬁnició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
Ciclo de Vida
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 diﬁcultad 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

Introducción
Ciclo de Vida
Arquitectura simple de una aplicación
Figure: Aplicación de negocios

Introducción
Ciclo de Vida
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)

Introducción
Ciclo de Vida
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 predeﬁnidas
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)

Introducción
Ciclo de Vida
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

Introducción
Ciclo de Vida
Antecedentes de servicios SOA
Domain Name System (DNS)
Es una parte muy importante de la conﬁguració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

Introducción
Ciclo de Vida
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

Introducción
Ciclo de Vida
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 Notiﬁcación de Eventos (SIENA)
CORBA Event Service
Servicios de alerta que pueden ser construidos sobre
servicios de eventos

Introducción
Ciclo de Vida
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

Introducción
Ciclo de Vida
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.

Introducción
Ciclo de Vida
Representación de un modelo de proceso de negocio

Introducción
Ciclo de Vida
Caracterización de SOA
¿Qué es SOA?
Una arquitectura ﬂexible y estándar que uniﬁca 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í.

Introducción
Ciclo de Vida
Tecnologías de soporte para arquitecturas distribuidas
Figure: Grado de cobertura de propiedades requeridas

Introducción
Ciclo de Vida
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

Introducción
Ciclo de Vida
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 and Integration (UDDI)M.I.Capel Tema 2 90/146

Introducción
Ciclo de Vida
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

Introducción
Ciclo de Vida
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 eﬁcientes posible
Descubrimiento: Los servicios son diseñados para facilitar
su descubrimiento en el ambiente en que se ejecutan

Introducción
Ciclo de Vida
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 deﬁne cómo dos objetos en
diferentes procesos pueden comunicarse por medio de
intercambio de datos XML

Introducción
Ciclo de Vida
Tecnologías
WSDL
Web Service Description Language es un lenguaje basado en
XML utilizado para describir los Servicios Web. Este lenguaje
deﬁne 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 con mensajes SOAP y proveer acceso aM.I.Capel Tema 2 94/146

Introducción
Ciclo de Vida
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.

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

Introducción
Ciclo de Vida
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.

Introducción
Ciclo de Vida
Arquitectura SOA modelo

Introducción
Ciclo de Vida
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 reﬁnarlo y volver a modelar

Introducción
Ciclo de Vida
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
Deﬁnir los Key Performance Indicators (KEI)

Introducción
Ciclo de Vida
Desarrollo
Convertir el diseño de negocio en deﬁniciones 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

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

Introducción
Ciclo de Vida
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
deﬁnieron en el diseño

Introducción
Ciclo de Vida
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

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

Introducción
Ciclo de Vida
Enfoque de SUN

Introducción
Ciclo de Vida
Ejemplo de arquitectura de SUN

Introducción
Ciclo de Vida
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áﬁca similar a UML
Tal como éste, la semántica de BPMN no está
formalmente deﬁnida
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 los procesos con restriccionesM.I.Capel Tema 2 108/146

Introducción
Ciclo de Vida
La notación BPMN

Introducción
Ciclo de Vida
Ejemplo de especiﬁcación con BMPN
Figure: Proceso logístico de una farmacia de hospital

Introducción
Ciclo de Vida
Un tipo especial de diagrama de ﬂujo: Business
Process Diagram (BPD)
Gateways
Events
Activities
Flows

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

Introducción
Ciclo de Vida
Representación con BPD de las entidades BMPN
Figure: Representación gráﬁca de los elementos de BPMN
Extendido.

Introducción
Ciclo de Vida
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

Introducción
Ciclo de Vida
Parallel Fork Gateway
Se necesita una rama del P(i) por cada ﬂujo de control
saliente representado en estado de la puerta:
Figure: Modelo “black–box" de la puerta paralela de EBPMN.

Introducción
Ciclo de Vida
Data–based OR Gateway
Se utilizan puertas inclusivas para la selección de un
conjunto de ramas de salida entre todos los ﬂujos:
Figure: Modelo “black–box" del estado de la puerta OR de EBPMN.

Introducción
Ciclo de Vida
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

Introducción
Ciclo de Vida
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

Introducción
Ciclo de Vida
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)

Introducción
Ciclo de Vida
Tareas de servicios II

Introducción
Ciclo de Vida
Interpretación Semántica
La comunicación debe tener lugar dentro de los intervalos
deﬁnidos por las condiciones:
s( m1), s( m2) ∈
[max{vS1, vS2}, min{vS1 + S1.ran.min, vS2 + S2.ran.min}]

Introducción
Ciclo de Vida
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áﬁca 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 de desempeño, disponibilidad,M.I.Capel Tema 2 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 conﬁguraciones.
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í como para modelar procesos deM.I.Capel Tema 2 126/146

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, reﬁnamiento 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 especiﬁcació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 ﬂexible que soporta la asociación de
información no estructural utilizando sub–lenguajes
deﬁnidos 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 conﬁguraciones 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 = { Port enviar−pe ti ci on ; } ;
3 Component servidor = { Port r e c i b i r −pe ti ci on ; } ;
4 Connector rpc = { Roles { llama , llamado } } ;
5 Attachments {
6 c l i e n t e . enviar−pe ti ci on to rpc . llama ;
7 servidor . r e c i b i r −p eti ci on to rpc . 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 reﬁnamiento 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 deﬁne un conjunto de información para añadir a
la información estructural de la AS: datos comunicados,
protocolos de interacción, restricciones de planiﬁcació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 signiﬁcado de las propiedades no es deﬁnido
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
1 System simple_cs = {
2 Component c l i e n t e = {
3 Port enviar−p eti ci on ;
4 Property Aesop−s t y l e : style −id = c l i e n t −server ;
5 Property UniCon−s t y l e : style −id = cs ;
6 Property source−code : external = "CODE−LIB / c l i e n t . c " ;
7 }
8 Component servidor = {
9 Port r e c i b i r −pe ti ci on ;
10 Property idempotence : boolean = true ;
11 Property max−concurrent−c l i e n t s : integer = 1;
12 source−code : external = "CODE−LIB / server . c " ;
13 }
14 // ...

Arquitecturas de Software

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à Arquitecturas de Software

Similaire à Arquitecturas de Software (20)

Plus de Manuel Capel-Tunon

Plus de Manuel Capel-Tunon (7)

Dernier

Dernier (20)

Arquitecturas de Software