Arquitecturas de Software

157
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: [email protected] Desarrollo de Software Ingeniería de Software (3er curso de Grado) M.I.Capel Tema 2 1/146

description

El diseño de una arquitectura de software 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 a lo largo de todo el ciclo de vida del software.

Transcript of Arquitecturas de Software

Page 1: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Arquitecturas Software

M.I. Capel

ETS Ingenierías Informáticay Telecommunicación

Universidad de GranadaEmail: [email protected]

Desarrollo de SoftwareIngeniería de Software (3er curso de Grado)

M.I.Capel Tema 2 1/146

Page 2: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Índice1 Introducción

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

2 Mecanismos Arquitectónicos3 Arquitecturas Orientadas a Componentes y Servicios

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

4 Lenguajes de Defición Arquitectónica (ADLs)Caso de Estudio: An Architecture DescriptionInterchange Language (ACME)

M.I.Capel Tema 2 2/146

Page 3: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Índice1 Introducción

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

2 Mecanismos Arquitectónicos3 Arquitecturas Orientadas a Componentes y Servicios

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

4 Lenguajes de Defición Arquitectónica (ADLs)Caso de Estudio: An Architecture DescriptionInterchange Language (ACME)

M.I.Capel Tema 2 2/146

Page 4: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Índice1 Introducción

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

2 Mecanismos Arquitectónicos3 Arquitecturas Orientadas a Componentes y Servicios

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

4 Lenguajes de Defición Arquitectónica (ADLs)Caso de Estudio: An Architecture DescriptionInterchange Language (ACME)

M.I.Capel Tema 2 2/146

Page 5: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Índice1 Introducción

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

2 Mecanismos Arquitectónicos3 Arquitecturas Orientadas a Componentes y Servicios

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

4 Lenguajes de Defición Arquitectónica (ADLs)Caso de Estudio: An Architecture DescriptionInterchange Language (ACME)

M.I.Capel Tema 2 2/146

Page 6: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Arquitectura de Software

Es una descripción de la estructura del software que se vaa 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 desarrollodel 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 decomputación es la estructura o estructuras del sistema, lacual comprende componentes de software, propiedadesexternas de esos componentes y la interacción entre ellos.

M.I.Capel Tema 2 3/146

Page 7: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

El diseño arquitectónico

definiciónConsiste en una actividad inicial de la fase de diseño de unsistema software cuyo objetivo es identificar los subsistemas yestablecer un marco de trabajo para gestionar correctamente elcontrol y la comunicación de dichos subsistemas

M.I.Capel Tema 2 4/146

Page 8: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

El proceso de diseño

El proceso de diseño incluye el desarrollo de variosmodelos con diferentes niveles de abstracciónLa retroalimentación entre estas actividades y laconsecuente repetición del trabajo es inevitable en todoproceso de diseño

Figure: Proceso de Diseño de Software

M.I.Capel Tema 2 5/146

Page 9: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Ubicación dentro de proceso de diseño

El diseño arquitectónico representa el puente entre laespecificación de requerimientos del sistema y el diseñoEstablecer un marco de trabajo básico que proporcioneuna estructura para situar los componentes principales deun sistema y las comunicaciones que tienen lugar

M.I.Capel Tema 2 6/146

Page 10: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Especificación de requerimientos

Existe un solapamiento entre análisis y especificación derequerimientos con el diseño arquitectónicoLa especificación no debería incluir ninguna informaciónsobre diseñoLa descomposición arquitectónica es necesaria paraestructurar y organizar la especificación de un sistemaNormalmente se utiliza un modelo arquitectónico como elpunto de partida para realizar la especificación de lossubsistemas

M.I.Capel Tema 2 7/146

Page 11: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Motivación de la Arquitectura de Software

Existen unas necesidades fundamentales que justifican laimportancia de construir una AS y de su análisis:

Potencia la comunicación entre stakeholdersEs el punto más temprano en el cual el sistema que va aser construido puede ser analizado.Las decisiones de diseño aquí son muy importantes paraconseguir requisitos críticos del sistemaAbstracción de un sistema software: es una herramientaesencial para gestionar la complejidad de un sistemaModelo transferible a otros sistemas, especialmente aaquellos con requerimientos similares

M.I.Capel Tema 2 8/146

Page 12: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Influencias

Un AS es el resultado de diversas influencias técnicas, delnegocio y socialesLa existencia de una determinada AS para un dominio deaplicaciones afecta a su vez a los ambientes técnicos denegocio y sociales, que realimentan la futura arquitecturaUn entendimiento temprano de las restricciones permite alos arquitectos de software gestionarlos, negociarexpectativas con las partes implicadas (stakeholders),manejar riesgos, establecer compromisos, etc.

M.I.Capel Tema 2 9/146

Page 13: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Recomendaciones para el proceso

La arquitectura debe ser producto del equipoEl equipo debe conocer los requerimientos funcionales ylos de calidad priorizadosSe debe documentarRevisada por todas la partes implicadasAnalizada en base a medicionesDebe ser implementada incrementalmente

M.I.Capel Tema 2 10/146

Page 14: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Recomendaciones para el producto

Una AS debe ser modularCada módulo debe tener una interfaz bien definida yencapsular toda la informaciónLos atributos de calidad se deben alcanzar usandotácticas específicas para cada atributo

ConsideraciónEl logro de dichos atributos dependerá fundamentalmente de laAS seleccionada [Bass et al.1998][SEI 2001], no sólo de laprácticas a nivel de código (lenguajes, diseño detallado,estructuras de datos y algoritmos)

M.I.Capel Tema 2 11/146

Page 15: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Recomendaciones para el producto

Una AS debe ser modularCada módulo debe tener una interfaz bien definida yencapsular toda la informaciónLos atributos de calidad se deben alcanzar usandotácticas específicas para cada atributo

ConsideraciónEl logro de dichos atributos dependerá fundamentalmente de laAS seleccionada [Bass et al.1998][SEI 2001], no sólo de laprácticas a nivel de código (lenguajes, diseño detallado,estructuras de datos y algoritmos)

M.I.Capel Tema 2 11/146

Page 16: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

AS y requisitos no–funcionales

El estilo arquitectónico y estructura interna escogidospuede depender de requisitos no-funcionales: rendimiento,seguridad, fiabilidad, disponibilidad y mantenibilidad

RendimientoClave: localizar las operaciones críticas dentro del menornúmero posible de subsistemas, que mantengan el mínimoacoplamiento posible

Seguridad (control acceso a la información)

Clave: utilizar una arquitectura estratificada donde loselementos más críticos se ubiquen en las capas más internas ycuyo acceso esté protegido muy rigurosamenteM.I.Capel Tema 2 12/146

Page 17: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

AS y requisitos no–funcionales II

Seguridad (prevención de daños)

Clave: todas las operaciones sensibles han de ser ubicadas enun solo subsistema o en un número pequeño de estos paraconseguir la mayor protección

DisponibilidadClave: la arquitectura debe incluir componentes redundantes,tal que se puedan sustituir sin parar la ejecución del sistema

MantenibilidadClave: utilizar componentes pequeños y autocontenidos quepuedan ser cambiados con rapidez

M.I.Capel Tema 2 13/146

Page 18: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

AS y requisitos no–funcionales III

Conflicto de interesesEl potenciar un atributo arquitectónico correspondiente aun requisito no–funcional puede estar en conflicto con losotros requisitosEjemplo: utilizar componentes grandes mejora elrendimiento, en general, pero perjudica la mantenibilidaddel diseñoSe puede bien llegar a una solución de compromiso outilizar distintos estilos arquitectnicos para diferentespartes del sistema

M.I.Capel Tema 2 14/146

Page 19: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Decisiones Arquitectónicas

Cada enfoque desarrollado como parte de una descripciónarquitectónica aborda un aspecto de la ASSe consideran una variedad de alternativas entre losposibles enfoques arquitectónicos, y su descripcionesLas propias decisiones arquitectónicas pueden serconsideradas como un enfoque o vista de la arquitectura.Documentar las decisiones y las razones que las motivandichas es una manera fundamental de concebir y expresaruna arquitectura software [Babar09, Perry92].Las decisiones arquitectónicas se pueden considerarcomo los primeros elementos de la descripción de unaarquitectura software, por tanto, se han de hacer explícitasutilizando una plantilla de descripción arquitectónicaM.I.Capel Tema 2 15/146

Page 20: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Decisiones Arquitectónicas II

Si una propiedad de un elemento arquitectónico no esvisible o no es discernible de cualquier otro elementoarquitectónico, ese elemento no es arquitectónico.La selección de un manejador de base de datos no es unadecisión arquitectónica. La razón de su existencia no esmateria (no le concierne) a las metas arquitectónicas.Las decisiones son arquitectónicas o no de acuerdo alcontexto. Si la estructura es importante para alcanzar lasmetas del sistema la estrutura es arquitectónica.

M.I.Capel Tema 2 16/146

Page 21: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Plantilla de Descripción Arquitectónica

ResoluciónCategoríaSuposicionesRestriccionesAlternativas

ArgumentosImplicacionesDecisiones relacionadasProductos de trabajoNotas

M.I.Capel Tema 2 17/146

Page 22: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Descripción de una Arquitectura Software

Una AS proporciona la definición del sistema objetivo entérminos de elementos computacionales y de lasinteracciones entre ellos.La arquitectura muestra la correspondencia entre losrequerimientos de sistemas y los elementos del sistemaconstruido, proveyendo así una exposición racional paralas decisiones de diseño.

M.I.Capel Tema 2 18/146

Page 23: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Elementos notacionales de una AS

Computacionales:Son entidades tales como clientes, servidores, bases dedatos, filtros y capas de un sistema jerárquico.Son además, una parte encapsulada del sistema desoftware, donde cada uno tiene una interfaz.

Interacciones:Ocurren entre los elementos a nivel de diseño, pudiendoser tan simples como las llamadas a procedimientos ovariables de acceso, o tan complejas y semánticamentericas como los protocolos del modelo cliente-servidor, o losprotocolos de acceso a las bases de datos.

M.I.Capel Tema 2 19/146

Page 24: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Elementos notacionales de una AS II

Relaciones:Denotan las conexiones entre los elementoscomputacionales y/o componentes.Relaciones estáticas: Se muestran en el código fuente,ellas reflejan la colocación de los componentes dentro dela arquitectura. Son fácilmente detectables a partir delcódigo fuente.Relaciones dinámicas: Tratan con las conexionestemporales y las interacciones dinámicas entre loscomponentes.No se suelen detectar inspeccionando el código fuente delsistema final

M.I.Capel Tema 2 20/146

Page 25: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Protocolo para obtener la representación de una AS

1 definir los aspectos estructurales como una composiciónde 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

M.I.Capel Tema 2 21/146

Page 26: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

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

Definition (Sistema de Información Meteorológica (WMS))

Un WMS se necesita para generar informes meteorológicosregularmente utilizando datos recogidos de estaciones deobservación remotas y sin personal, así como de otras fuentestales como observadores voluntarios, globos y satélites. Comorespuesta de una petición, las estaciones transmiten sus datosal computador encargado de área.El sistema del computador de área valida los datos recogidosdesde diferentes fuentes y los integra. Los datos integradosson archivados y, utilizando los datos desde este archivo y losde una base de datos de informes meteorológicos, se crea unconjunto de informes locales. Los informes se pueden imprimirpara su distribución en una impresora de informes de propósitoespecial o bien pueden ser mostrados en pantalla de acuerdocon diferentes formatos.

M.I.Capel Tema 2 22/146

Page 27: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Pasos a seguir

1 Entender y definir los modos de uso y el contexto delsistema WMS

2 Diseñar la arquitectura de software (AS)3 Identificar los objetos principales dentro de la AS4 Desarrollar los modelos de diseño5 Especificar las interfaces de objetos

M.I.Capel Tema 2 23/146

Page 28: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Selección de una arquitectura software

Arquitectura estratificada (por capas)Cada capa sólo necesita del procesamiento de la capainferior para operarCapas identificadas:

Recoger DatosProcesar DatosAchivar DatosMostrar Datos

M.I.Capel Tema 2 24/146

Page 29: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Elementos notacionales: UML

Cada capa incluye a otros componentes del sistemaSe utilizan packaqes-UMLIdentificación de subsistemas

M.I.Capel Tema 2 25/146

Page 30: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Arquitectura inicial del sistema objetivo

Figure: Arquitectura en capas del WMS

M.I.Capel Tema 2 26/146

Page 31: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Modelos de uso y contexo del sistema

Definition (Objetivo)Desarollar una comprensión de las relaciones entre el softwareque está siendo diseñado y su entorno

El contexto del sistema es un modelo estático quedescribe a otros sistemasSe utiliza un modelo dinámico para describir cómointeractúa el sistema realmente con su entornoUtilizar diagramas de casos de usoUn caso de uso por cada interacción entre el sistema y suentornoAsociaciones entre casos de uso y descripciones segúnuna plantilla M.I.Capel Tema 2 27/146

Page 32: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Diseño arquitectónico

Guiado por la descripción de las interacciones del sistemacon su entornoComponente Estación Meteorológica:

1 Interfaz: comunicaciones con las otras partes del sistema2 Recolección: de datos: gestionar los datos recogidos por

los instrumentos y el resumen de los datos meteorológicosantes de transmitirlos

3 Instrumentación: encapsulación de los instrumentosutilizados para recoger los datos en bruto

4 Descomponer los modelos hasta que sólo existan 7entidades de modelado como máximo en un modeloarquitectónico

M.I.Capel Tema 2 28/146

Page 33: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Componentes de Subsistemas

Figure: Subsistemas del WMS

M.I.Capel Tema 2 29/146

Page 34: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Arquitectura de Componentes

Figure: Arquitectura del componente Estación Meteo

M.I.Capel Tema 2 30/146

Page 35: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Los objetos tienden a emerger durante el diseñoEl diseño tiene que ver con la identificación de las clasesIdentificación de atributos y operaciones de las clasesdesde la descripción informal del sistemaIdentificación de objetos de la estación meteorológica:

Objetos del dominio de aplicación:1 Termómetro Tierra2 Anemómetro3 Barómetro

Objetos procedentes de escenarios de casos de uso:1 EstacionMeteo2 DatosMeteo

M.I.Capel Tema 2 31/146

Page 36: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Clases de Objetos

Figure: Objetos de Estación Meteo

M.I.Capel Tema 2 32/146

Page 37: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Carácter pasivo/activo de los objetos

Los objetos pasivos ejecutan sus métodos por petición delsistema: cambios en la política de recogida de datos noafecta a las clases que los modelanObjetos activos incluyen su propio control, deciden cuándorealizan las lecturas de los instrumentos: perjudica lainteroperabilidad

M.I.Capel Tema 2 33/146

Page 38: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Modelos estáticos y dinámicos

Los modelos de diseño son el puente entre los requisitosdel sistema y la implementación del sistema:

1 Modelos estáticos: clases, objetos, relaciones degeneralización, usa/usado–por, composición

2 Modelos dinámicos: diagramas de secuencia y de estados,entre otros (UML proporciona 12 modelos dinámicos dediagramas)

Modelos de subsistemas: incluyen componentes yasociacionesSecuencias: para cada modo de interacción del sistema,la secuencia de llamadas entre objetos que tienen lugarEstados: comportamiento de un solo objeto en respuestaa los mensajes que puede procesar

M.I.Capel Tema 2 34/146

Page 39: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Descomposición de paquetes

Figure: Objetos de Estación Meteo

M.I.Capel Tema 2 35/146

Page 40: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Modelo de secuencia de operaciones

Figure: Recogida datos: secuencia operacionesM.I.Capel Tema 2 36/146

Page 41: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Diagrama de estados

Figure: Estación Meteo: diagrama de estadosM.I.Capel Tema 2 37/146

Page 42: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software

Especificar las interfaces de objetos

Especificar las interfaces de los objetos de tal manera quelos objetos y los subsistemas se puedan diseñar enparaleloNo incluir detalles de la representación en el diseñoSólo proporcionar las operaciones de los objetosnecesarias para acceder y actualizar los datos del objetoNo tiene por qué existir una relación 1:1 entre objetos einterfacesUtilizar un lenguaje de programación (como Java) paradefinir las interfaces de los objetos

M.I.Capel Tema 2 38/146

Page 43: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Modelos abstractos de AS

Modelo 4+1 Vistas de KrutchenEn la actualidad el desarrollo de sistemas se centra en laarquitectura software, que es especificada utilizando el modelosiguiente

M.I.Capel Tema 2 39/146

Page 44: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Modelos abstractos de AS

Modelo 4+1 Vistas de KrutchenEn la actualidad el desarrollo de sistemas se centra en laarquitectura software, que es especificada utilizando el modelosiguiente

M.I.Capel Tema 2 39/146

Page 45: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ciclo de Arquitecturas de Negocio (ABC)

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

M.I.Capel Tema 2 40/146

Page 46: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Estilos Arquitectónicos

Define una familia de sistemas de software en términos desu organización estructural.Representa los componentes y las relaciones entre elloscon las restricciones de su aplicación y las asociaciones yreglas de diseño para su construcciónDefine un vocabulario de componentes y tipos deconectores.

Ejemplos de Estilos ArquitectónicosPipes and filters, Tipos de datos abstractos y OO, Repositorios,Capas, Basados en Eventos, Intérpretes, etc.

M.I.Capel Tema 2 41/146

Page 47: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Estilos II

La imposición de ciertos estilos arquitectónicos mejora odisminuye las posibilidades de satisfacción de ciertosatributos de calidad del sistema [Bosch, 2000]Cada estilo propicia atributos de calidad, y la decisión deimplementar alguno de los existentes depende de losrequerimientos de calidad del sistema.Un criterio importante del éxito de los estilos es la forma enque estos alcanzan de manera satisfactoria los objetivosde la Ingeniería de Software. [Buschmann et al.,1996]

M.I.Capel Tema 2 42/146

Page 48: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Diferencias entre estilos y patrones arquitectónicos

Estilo Arquitectónico-Sólo describe el esqueletoestructural y general de lasaplicaciones-Son independientes del contextoal que puedan ser aplicados-Cada estilo es independiente delos otros-Expresan técnicas de diseñodesde una perspectivaindependiente de la situaciónactual de un diseño-Pueden comprenderse tambiéncomo una clasificación de lossistemas software

Patrón Arquitectónico-Varios rangos de escala, comenzandocon la definición de la estructura básicade una aplicación-Necesitan de la definición de un contextodel problema-Dependen de patrones más pequeños,con los que interactúan; o de patronesque los contengan-Expresan un problema recurrente dediseño, muy específico, presentando unasolución, desde el punto de vista delcontexto en el que se presenta-Son soluciones generales a problemascomunesM.I.Capel Tema 2 43/146

Page 49: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Patrón Arquitectónico

Definición de Buschmann (1996)Una regla que consta de tres partes, la cual expresa unarelación entre un contexto, un problema y una solución.

1 Contexto: Es una situación de modelado de una parte delsistema en la que aparece un problema de diseño.

2 Problema: Es un conjunto de fuerzas que aparecenrepetidamente en el contexto.

3 Solución: Es una configuración que equilibra estasfuerzas.

M.I.Capel Tema 2 44/146

Page 50: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Patrón Arquitectónico

Definición de Buschmann (1996)Una regla que consta de tres partes, la cual expresa unarelación entre un contexto, un problema y una solución.

1 Contexto: Es una situación de modelado de una parte delsistema en la que aparece un problema de diseño.

2 Problema: Es un conjunto de fuerzas que aparecenrepetidamente en el contexto.

3 Solución: Es una configuración que equilibra estasfuerzas.

M.I.Capel Tema 2 44/146

Page 51: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Patrones II

Para Buschmann sonplantillas para arquitecturasde software concretas, queespecifican las propiedadesestructurales de unaaplicación y tienen unimpacto en la arquitecturade subsistemas.

El uso de ciertosmecanismos, como losestilos y patronesarquitectónicos, permitemejorar las característicasde calidad en el software[Bosch, 2000], bien seanéstas observables o no entiempo de ejecución [Basset al., 2003].

M.I.Capel Tema 2 45/146

Page 52: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

El ámbito del patrón es menos general que el del estiloarquitectónicoUn patrón impone una regla a la arquitectura, describiendocómo el software gestionará algún aspecto de sufuncionalidad (p.e.: la concurrencia).Los patrones arquitectónicos tienden a abordar problemascomportamentales específicos dentro del contexto de unaarquitecturaLos patrones y los estilos arquitectónicos se puedenutilizar de forma conjunta para dar forma a la estructuracompleta de un sistema.

M.I.Capel Tema 2 46/146

Page 53: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Diferencias según el nivel de abstracción

M.I.Capel Tema 2 47/146

Page 54: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Patrón Interceptor

Permite a determinados servicios ser añadidos de maneratransparente a un marco de trabajo y ser disparadosautomáticamente cuando ocurren ciertos eventosContexto: Desarrollo de marcos de trabajo que puedan serextendidos de manera transparenteProblema: Los marcos de trabajo, arquitecturas software,etc. ha de poder anticiparse a las demandas de serviciosconcretos que deben ofrecer a sus usuariosIntegración dinámica de nuevos componentes sin afectar ala AS o a otros componentesSolución: Registro offline de servicios a través de unainterfaz predefinida del marco de trabajo, posteriormentese disparan estos servicios cuando ocurran determinadoseventos

M.I.Capel Tema 2 48/146

Page 55: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Interceptor

M.I.Capel Tema 2 49/146

Page 56: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Estructura de clases de “Interceptor"

Un FrameworkConcreto que instancia una arquitecturagenérica y extensibleLos Interceptores que son asociados con un eventoparticularInterceptoresConcretos que especializan las interfaces delinterceptor e implementan sus métodos de enlaceDespachadores para configurar y disparar interceptoresconcretosUna Aplicación que se ejecuta por encima de unframework concreto y utiliza los servicios que éste leproporciona

M.I.Capel Tema 2 50/146

Page 57: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Implicaciones en la calidad del patrón Interceptor

Beneficios Atributo de calidad Características ISO 9126Cambiar/incluir servicios de un framework Extensibilidad, Mantenibilidadsin que sea preciso cambiarlo Flexibilidad,Dinamismo Facilita cambiosAñadir interceptores sin afectar al Acoplamiento Mantenibilidadcódigo de la aplicación Facilita cambiosObtención dinámica inform. del framework Monitorización Tolerancia a fallascon intercept. y objetos–contexto Control Uso de recursosInfraestructura de servicios estratificada con Encapsulamiento Mantenibilidadinterceptores correspondientes simétricos Facilita cambios,análisisReutilización de interceptores en Reusabilidad Mantenibilidaddiferentes aplicaciones Facilita cambios

M.I.Capel Tema 2 51/146

Page 58: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Implicaciones en la calidad 2Inconvenientes Atributo de calidad Características ISO 9126Difícil ajuste del número de Complejidad Facilita cambiosdespachadores e interceptores Flexib., extensibilidad Facilita análisisBloqueo aplicación por Disponibilidad Mantenibilidadfallo del interceptor Modificabilidad Madurez, Tolerancia FallasDegradación rendimiento por Rendimiento Eficiencia,madurezcascadas de interceptores Bloqueo Tolerancia fallas

Insuficientes interceptores y despachadores reduce la flexibilidad yextensibilidad 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 detime-out, pero esto puede complicar el diseño del framework concreto

Las cascadas de intercepción pueden conllevar una degradación delrendimiento o un bloqueo de la aplicación

M.I.Capel Tema 2 52/146

Page 59: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

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 Facilidad de análisis

- 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 Bloqueo M.I.Capel Tema 2 53/146

Page 60: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Resumen características de calidad

Figure: Características ISO del patrón “Interceptor"

M.I.Capel Tema 2 54/146

Page 61: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Patrón Broker

Para modelar sistemas distribuidos compuesto decomponentes software totalmente desacopladosContexto: cualquier sistema distribuido y, posiblemente,heterogéneo con componentes cooperando dentro de unsistema de informaciónProblema:¿Cómo estructurar componentes configurablesdinámicamente e independientes de los mecanismosconcretos de comunicación de un sistema distribuido?Solución: Introducir un componente Broker para mejordesacoplamiento entre clientes y servidoresLas tareas de los Brokers incluyen la localización delservidor apropiado, envío de la petición al servidor ytransmisión de los resultadosM.I.Capel Tema 2 55/146

Page 62: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Broker

M.I.Capel Tema 2 56/146

Page 63: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Estructura de clases del patrón Broker

Intermediario: admite las solicitudes, asigna los servidoresy responde a las peticiones de los clientesServidor: se registra en el Intermediario e implementa elservicioCliente: accede a los servicios remotosProxy Cliente y Proxy Servidor, que proporcionantransparencia, ocultando los detalles de implementacióndel patrónPuente: le proporciona interoperabilidad al Intermediario

M.I.Capel Tema 2 57/146

Page 64: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Implicaciones en la calidad del patrón BrokerBeneficios Atributos de calidad Característica ISO 9126Separación código de comunicaciones. Acoplamiento Facilita cambios

Modificabilidad Fac.análisis,pruebasIndependencia de la plataforma de Escalabilidad Facilita cambiosejecución para la aplicación Uso de recursosMejor descomposición del Interoperabilidad Interoperabilidadespacio del problema Simplicidad Facilita análisisIndependencia de la implementación Modificabilidad Mantenibilidadconcreta de cada capa Flexibilidad Fac.cambiosInteracciones basadas en el Transparencia Funcionalidadparadigma de objetos InteroperabilidadArquitectura software Dinamismo Facilita cambiosmuy flexible Facilita análisisReducción complejidad de Modificabilidad Facilita cambiosprogramación distribuida Flexibilidad Facilita análisisIntegración de tecnologías Reusabilidad Facilita cambios

Facilita análisisDistribución del modelo de Interoperabilidad Portabilidadobjetos AdaptabilidadM.I.Capel Tema 2 58/146

Page 65: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Implicaciones en la calidad 2

Inconvenientes Atributos de calidad Características ISO 9126Empeora el rendimiento de la Rendimiento Eficienciaaplicación Tiempo respuestaImpide la verticalidad Optimización Facilidad pruebasen acceso a capas internas Ocultamiento Uso recursos

Tolerancia fallas

Las capas de abstracción a las que conduce este patrón pueden perjudicar eldesempeño

Usar una capa separada del Broker puede ocultar los detalles sobre cómo laaplicación utiliza la capa más baja

Eventualmente, optimizaciones específicas del rendimiento de algunas capaspodrían resultar perjudicadas

M.I.Capel Tema 2 59/146

Page 66: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Resumen características de calidad

Característica Sub-característica Impacto Atributo

Mantenibilidad Facilidad de cambio Facilidad de análisis

+ 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 + Multiplataforma

M.I.Capel Tema 2 60/146

Page 67: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Resumen características de calidad

Figure: Características ISO del patrón “Broker"

M.I.Capel Tema 2 61/146

Page 68: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Patrón Reflection

Proporciona un mecanismo para cambiar la estructura ycomportamiento de sistemas software dinámicamenteSoporta la modificación de aspectos fundamentales, talescomo estructuras y mecanismos de llamadas a funciones.Contexto: Cualquier sistema que necesita soporte pararealizar cambios propios y para conseguir persistencia desus entidadesProblema: ¿Cómo se puede modificar el comportamientode los objetos de una jerarquía dinámicamente sin afectara los propios objetos en su configuración actual?Solución: Hacer que el software sea “auto-consciente" desu función y comportamiento, haciendo que los aspectosseleccionados sean accesibles para su adaptación ycambio dinámico

M.I.Capel Tema 2 62/146

Page 69: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Reflection

M.I.Capel Tema 2 63/146

Page 70: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Estructura de clases del patrón Reflection

Meta Nivel: proporciona la información acerca de laspropiedades escogidas del sistema y hace que el sistemasea auto-conscienteMeta Objetos: encapsulan y representan informaciónacerca del softwareNivel Base: incluye la lógica de la aplicaciónLos cambios mantenidos en el Meta Nivel afectanconsecuentemente al comportamiento del Nivel BaseLa implementación del Meta Nivel utiliza Meta Objetospara mantenerse independiente de aquellos aspectos queson propensos a cambiar

M.I.Capel Tema 2 64/146

Page 71: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Implicaciones en la calidad del patrón Reflection

Beneficios Atributos de calidad Características ISO 9126Comprobación correctitud desde Correctitud Funcionalidadel nivel de MetaObjetos PrecisiónEjecución de los cambios Dinamismo Facilidad cambiosdesde el nivel de MetaObjetos Facilidad análisisModificación y extensión de Modificabilidad Mantenibilidadcomponentes software facilitada Extensibilidad Facilidad cambiosCambios en el software del Modificabilidad MantenibilidadNivelBase facilitados Extensibilidad Facilidad cambiosAsume modificaciones no explícitas Extensibilidad Mantenibilidaddel código fuente Facilidad cambiosSoporte para muchos Modificabilidad Mantenibilidadtipos de cambios Facilidad cambios

M.I.Capel Tema 2 65/146

Page 72: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Implicaciones en la calidad 2

Inconvenientes Atributos de calidad Características ISO 9126Complejidad de diseño e implementación Complejidad Facilidad análisispor los niveles y protocolo meta–objetos Facilidad pruebasDemasiados meta–objetos en Rendimiento Uso recursosla aplicación final EficienciaModificaciones en meta–nivel pueden Fallas Madurezcausar daños comportamiento del sistema Tolerancia a fallasRendimiento sistema puede ser afectado Complejidad Eficienciapor complejidad diseño del patrón Tiempo respuestaDifícil adaptación a la evolución de los Adaptabilidad Tiempo respuestaproductos generados con el patrón Eficiencia

M.I.Capel Tema 2 66/146

Page 73: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Resumen características de calidad

Característica Sub-característica Impacto Atributo

Mantenibilidad Facilidad de cambio Facilidad de análisis

+ 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

M.I.Capel Tema 2 67/146

Page 74: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Resumen características de calidad

Figure: Características ISO del patrón “Reflection"M.I.Capel Tema 2 68/146

Page 75: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Categorización de los Estilos Arquitectónicos

Arquitecturas centradas en los datosEl núcleo de estas arquitecturas es un repositorio o una basede datos a la que acceden las aplicaciones–clienteLas aplicaciones cliente acceden a los datos o ejecutan susprocesos de forma totalmente independiente entre ellosPropician la integrabilidad

Arquitecturas de Flujo de DatosLos datos de entrada han de ser transformados tras laactuación de componentes de la AS hasta producir los datosde salidaSus componentes se llaman filtros y encauzamientos, queoperan de una forma totalmente asíncrona entre ellosM.I.Capel Tema 2 69/146

Page 76: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Categorización de los Estilos Arquitectónicos

Arquitecturas de Llamada–retornoArquitecturas Programa principal–subprograma: jerarquíade control donde se invocan varios componentes que, a suvez, pueden invocar a otros componentesArquitecturas Llamada a procedimiento remoto: loscomponentes se distribuyen ahora a través de múltiplescomputadores conectados por una red

Arquitecturas EstratificadasEstructuradas en capas que realizan operaciones que vanacercándose a nivel de las instrucciones–máquina:-operaciones nivel interfaz de usuario-utilidades y software de aplicación-operaciones nivel interfaz sistema operativo

M.I.Capel Tema 2 70/146

Page 77: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Categorización de los Estilos Arquitectónicos

Arquitecturas Orientadas a ObjetoLos componentes de un sistema que sea conforme con estetipo de arquitectura encapsulan los datos y las operacionesque deben ser aplicadas para manipularlosLa comunicación y coordinación entre componentes se llevan acabo mediante paso de mensajes

M.I.Capel Tema 2 71/146

Page 78: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Arquitecturas de referencia

ConceptosLos estilos arquitectónicos se pueden aplicar a muchosdominios de aplicacionesReutilización de la estructura arquitectónica común de losmodelos que se aplican a un mismo dominio deaplicaciones

Arquitecturas específicas de un dominio de aplicacionesModelos genéricos: abstracciones de un número desistemas con elementos comunes.Modelos de referencia: AS idealizada que incluye todaslas características que los sistemas software de esa clasehan de contener.

M.I.Capel Tema 2 72/146

Page 79: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Arquitecturas de referencia

ConceptosLos estilos arquitectónicos se pueden aplicar a muchosdominios de aplicacionesReutilización de la estructura arquitectónica común de losmodelos que se aplican a un mismo dominio deaplicaciones

Arquitecturas específicas de un dominio de aplicacionesModelos genéricos: abstracciones de un número desistemas con elementos comunes.Modelos de referencia: AS idealizada que incluye todaslas características que los sistemas software de esa clasehan de contener.

M.I.Capel Tema 2 72/146

Page 80: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Características de las arquitecturas de referencia

No se consideran como una guía de implementación delos sistemas softwareSe utilizan para discutir la aplicación de AS específicas deun dominio de aplicaciones y compararlasProporcionan un vocabulario de términos que aluden a lossistemas dentro de un mismo dominio de aplicacionesProporcionan una base conceptual con respecto a la cualse pueden evaluar las diferentes propuestasarquitectónicasEjemplos de arquitecturas de referencia: el modelo OSI deredes, modelo de referencia CASE

M.I.Capel Tema 2 73/146

Page 81: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Figure: Arquitectura de referencia ECMA para entornos CASE

M.I.Capel Tema 2 74/146

Page 82: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Ejemplo: Modelo de Referencia CASE

Tipos de servicicios del modeloRepositorio de datos: manejo de los items de datos y susrelacionesIntegración de datos: la base para conseguir la integraciónde los datosGestión de tareas: definición y representación de losmodelos de procesosMensajes: comunicaciones herramienta–herramienta,entorno–herramienta y entorno–entornoInterfaces de usuario: presentación integrada de lafuncionalidad y servicios del sistema

M.I.Capel Tema 2 75/146

Page 83: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Concepto y Motivación

ConceptoLas arquitecturas basadas en componentes y servicios: lafuncionalidad de las aplicaciones ahora se implementa en laforma de componentes reutilizables e invocables medianteinterfaces estándar, que pueden combinarse para crearfunciones progresivamente más complejas.

MotivaciónLa dificultad de las arquitecturas tradicionales para integrarseen los procesos de negocio reside en que sus aplicaciones noestán diseñadas para ser integradas con otras

M.I.Capel Tema 2 76/146

Page 84: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Arquitectura simple de una aplicación

Figure: Aplicación de negocios

M.I.Capel Tema 2 77/146

Page 85: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Servicios

¿Qué es un servicio?“Representación estándar para cualquier recursocomputacional o de información que pueda ser utilizado porotras aplicaciones", Turner (2003)

“Organización global encargada de establecer y adoptar losestándares de los servicios Web", OASIS (Organization for theAdvancement of Structured Information Standards)

M.I.Capel Tema 2 78/146

Page 86: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Características de un servicio

La provisión del servicio es independiente de la plataforma dela aplicación que lo proporciona

Capacidades externas para procesamientoAcceso consistente a través de interfacesAdaptación a políticas y restricciones predefinidas

Las aplicaciones se construyen enlazando servicios desdevarios proveedores utilizando lenguajes de programación (p.e.Java) o de instrumentación de servicios (p.e. BPEL)

M.I.Capel Tema 2 79/146

Page 87: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Tipos de servicios

Servicios:InteracciónProcesoServicios de Aplicación de NegociosInformaciónServicios de AccesoSociosServicios de Innovación y OptimizaciónServicios de DesarrolloManejo de Servicios ITServicios de InfraestructuraM.I.Capel Tema 2 80/146

Page 88: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Antecedentes de servicios SOA

Domain Name System (DNS)Es una parte muy importante de la configuración de un sistemadistribuido

Suele “entenderse" como un computador que proporcionainformación de un dominio de nombres a una red

Servicio de Dominio de NombresGarantiza de nombres únicos en toda la red, insensibles amayúsculas–minúsculas, que consisten en una cadena decaracteres alfanuméricos y guiones separados por puntos, queel DNS hace corresponder con números de IP y otrainformación M.I.Capel Tema 2 81/146

Page 89: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Antecedentes de servicios SOA II

Servicios de IntermediaciónServicio de meta–información (“trading") esencial de lossistemas abiertosActúa como un mediador global entre servicios,aplicaciones y clientesPermite construir un ambiente de computación a escalamundialEvolución constante de servicios y aplicacionesIngeniería de Software para Sistemas Abiertos

M.I.Capel Tema 2 82/146

Page 90: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Antecedentes de servicios SOA III

Servicios de EventosSirven de soporte al intercambio de mensajes asíncronoentre objetos en Sistemas DistribuídosDependen de una infraestructura basada en eventos (como JEDI)Ejemplos de servicios de eventos:

Servicios de Notificación de Eventos (SIENA)CORBA Event ServiceServicios de alerta que pueden ser construidos sobreservicios de eventos

M.I.Capel Tema 2 83/146

Page 91: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Motivación para SOA

Proveedores de tecnología (consultores y usuarios), están deacuerdo en que el enfoque Service Oriented Architecture(SOA) permite mejorar la calidad de las aplicaciones y dar unamejor respuesta a las partes interesadas de un modelo denegocio

M.I.Capel Tema 2 84/146

Page 92: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Modelado de Procesos de Negocios

“Proceso de Negocio" (BP)

Conjunto de servicios interactivos, estructurados yrelacionados que de manera integrada son capaces deproporcionar una funcionalidad compleja para implementar losprocesos y tareas de un negocio de acuerdo con sus reglas.

Modelado de Procesos de Negocio (BPM)

Se trata de una actividad conceptual para comprender elfuncionamiento y describir la compleja estructura de losprocesos de negocio de una empresa, de tal manera quedichos procesos puedan ser entonces analizados y mejorados.

M.I.Capel Tema 2 85/146

Page 93: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Representación de un modelo de proceso de negocio

M.I.Capel Tema 2 86/146

Page 94: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Caracterización de SOA

¿Qué es SOA?Una arquitectura flexible y estándar que unifica los procesos denegocio estructurando grandes aplicaciones como coleccionesde servicios.

Estas aplicaciones pueden ser usadas por usuarios dentro ofuera de la organización.

Estilo arquitectónicoSOA es también un estilo de arquitectura donde todas lasfuncionalidades, ya sean existentes o nuevas, son agrupadasen servicios que se comunican entre sí.

M.I.Capel Tema 2 87/146

Page 95: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Tecnologías de soporte para arquitecturas distribuidas

Figure: Grado de cobertura de propiedades requeridasM.I.Capel Tema 2 88/146

Page 96: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Requerimientos de un SOA

Interoperabilidad entre los distintos sistemas y lenguajesde programación presentes en la organizaciónUtilización de un protocolo estándarLos servicios han de ser descritos con un lenguaje claro ypreciso independiente de la plataformaMecanismo de búsqueda para obtener remotamente losservicios que ya han sido implementados

M.I.Capel Tema 2 89/146

Page 97: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Servicios WebLos Servicios Web son servicios implementados utilizandoestándares como SOAP, WSDL y UDDI para ser accedidos através de una red, preferiblemente Internet y ejecutadosremotamente

Protocolo estándarService Oriented Architecture Protocol (SOAP)

Lenguaje de descripción de servicios

Web Service Description Language (WSDL)

Descubrimiento de servicios disponiblesUniversal Description Discovery and Integration (UDDI)M.I.Capel Tema 2 90/146

Page 98: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Principios de Diseño de SOA

Reglas para desarrollar, mantener y usar servicios

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

M.I.Capel Tema 2 91/146

Page 99: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Principios de Diseño de SOA II

Reglas para desarrollar, mantener y usar servicios

Reutilización: Los servicios deben ser diseñados siemprepara su reutilización por varias aplicaciones remotasComposición: Colecciones de servicios han de poder sercompuestos para formar otros serviciosAutonomía: Los servicios son los únicos que controlan sulógica internaOptimización: Deben ser lo más eficientes posibleDescubrimiento: Los servicios son diseñados para facilitarsu descubrimiento en el ambiente en que se ejecutan

M.I.Capel Tema 2 92/146

Page 100: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Tecnologías

XMLUn lenguaje de marcas. XML se basa en la combinación detexto con información que describe ese texto. En XML seutilizan las etiquetas (tags) para describir bloques de texto. Fuediseñado para compartir fácilmente las estructuras de datos através de la red.

SOAPSimple Object Access Protocol es un protocolo estándar bajoel auspicio de la W3C que define cómo dos objetos endiferentes procesos pueden comunicarse por medio deintercambio de datos XML

M.I.Capel Tema 2 93/146

Page 101: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Tecnologías

WSDLWeb Service Description Language es un lenguaje basado enXML utilizado para describir los Servicios Web. Este lenguajedefine a los servicios como colecciones de puertos, dondecada puerto indica una función del servicio que está siendodescrito. Así, cualquier usuario de un servicio puede leer elWSDL y saber qué funciones se pueden llamar utilizandoSOAP.

UDDIUniversal Description, Discovery and Integration es un registrobasado en XML para listar servicios en Internet. Está diseñadopara ser interrogado con mensajes SOAP y proveer acceso alos WSDL de los servicios que se encuentran listados.

M.I.Capel Tema 2 94/146

Page 102: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Tecnologías

BPELBusiness Process Execution Language es un lenguajeejecutable 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 deprocesos de negocio. Este lenguaje se utiliza para orquestar laejecución de un proceso, llamando a los servicios que vanecesitando.

M.I.Capel Tema 2 95/146

Page 103: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Implementación de WS

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

M.I.Capel Tema 2 96/146

Page 104: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Bus de Servicios de Empresa

ESBEnterprise Service Bus es el punto de comunicación entretodos los servicios. Funciona de forma transparente. No debecontener lógica del negocio.

M.I.Capel Tema 2 97/146

Page 105: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Arquitectura SOA modelo

M.I.Capel Tema 2 98/146

Page 106: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Ciclo de vida de un SOA

Modelado del negocio.Diseño de un sistema de informaciónImplementación del sistema de informaciónEvaluación del sistema para refinarlo y volver a modelar

M.I.Capel Tema 2 99/146

Page 107: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Ciclo de vida de un SOA

ModeladoCapturar el diseño del negocio (de requerimientos yobjetivos)Traducir a procesos de negocio y metasSe recomienda elaborar distintos escenarios que permitanobtener más información sobre los procesos de negocioDefinir los Key Performance Indicators (KEI)

M.I.Capel Tema 2 100/146

Page 108: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Ciclo de vida de un SOA

DesarrolloConvertir el diseño de negocio en definiciones deprocesos y actividadesTransformarlos a los servicios de la arquitecturaEstudiar aplicaciones ya existentes y reutilizar(asegurando estándares SOA)Implementar los servicios que faltan

M.I.Capel Tema 2 101/146

Page 109: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Ciclo de vida de un SOA

Despliegue

Crear un ambiente en el que se ejecuten las aplicacionesResolver dependenciasCondiciones operacionales, requisitos de capacidad yrestricciones de integridad y acceso

M.I.Capel Tema 2 102/146

Page 110: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Ciclo de vida de un SOA

GestiónDeterminar la manera de mantener el ambienteoperacional y las políticas de implementaciónMonitorizar la efectividad de las solicitudes de servicio y eltiempo de respuestaMantener registros de fallos y recuperar tareasMonitorización de las métricas de negocio (KPI) que sedefinieron en el diseño

M.I.Capel Tema 2 103/146

Page 111: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Ciclo de vida de un SOA

GobernabilidadDefinir los derechos de decisión para el desarrollo,despliegue y manejo de nuevos serviciosSupervisar que se cumplen las políticas, estándares,proceso y procedimientosAyuda a identificar qué proyectos contribuyenprincipalmente a conseguir las metas de negocioDefinir los roles y las responsabilidades de cada miembrodel equipo de forma clara

M.I.Capel Tema 2 104/146

Page 112: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre arquitecturas orientadas a serviciosServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de Vida

Microsoft Service Management

M.I.Capel Tema 2 48/56

Page 113: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre arquitecturas orientadas a serviciosServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de Vida

Enfoque de SUN

M.I.Capel Tema 2 49/56

Page 114: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre arquitecturas orientadas a serviciosServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de Vida

Ejemplo de arquitectura de SUN

M.I.Capel Tema 2 50/56

Page 115: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Modelado de Procesos de Negocio

BPMN“Business Process Model and Notation"(BPMN) se consideraactualmente como el lenguaje de modelado de procesos denegocio estándar.

CaracterísticasBPMN utiliza una notación gráfica similar a UMLTal como éste, la semántica de BPMN no estáformalmente definidaLa ausencia de tal semántica produce un problema para lavalidación de los modelos de procesos de negocioBPMN 2.0 intenta modelar los procesos con restriccionestemporales

M.I.Capel Tema 2 108/146

Page 116: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Modelado de Procesos de Negocio

BPMN“Business Process Model and Notation"(BPMN) se consideraactualmente como el lenguaje de modelado de procesos denegocio estándar.

CaracterísticasBPMN utiliza una notación gráfica similar a UMLTal como éste, la semántica de BPMN no estáformalmente definidaLa ausencia de tal semántica produce un problema para lavalidación de los modelos de procesos de negocioBPMN 2.0 intenta modelar los procesos con restriccionestemporales

M.I.Capel Tema 2 108/146

Page 117: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

La notación BPMN

Figure: Representación gráfica de los elementos de BPMN

M.I.Capel Tema 2 109/146

Page 118: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Ejemplo de especificación con BMPN

Figure: Proceso logístico de una farmacia de hospital

M.I.Capel Tema 2 110/146

Page 119: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Un tipo especial de diagrama de flujo: BusinessProcess Diagram (BPD)

GatewaysEventsActivitiesFlows

Figure: Ejemplo de un BPD

M.I.Capel Tema 2 111/146

Page 120: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Representación gráfica de un estado en BPMN

Type

in

out

error

send

/rec

eive

exit_1exit_2exit_3

links & dependences

Type

N

Figure: Modelo “black–box" de la entidad BPMN “state".M.I.Capel Tema 2 112/146

Page 121: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Representación con BPD de las entidades BMPN

Figure: Representación gráfica de los elementos de BPMNExtendido.

M.I.Capel Tema 2 113/146

Page 122: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Notación de modelado de BPMN extendido

EBPMN necesita de la precisión semántica que leproporciona un lenguaje formal a sus elementos básicospara transformar sus procesos de negocio en modelosejecutables

Al siguiente conjunto de constructos EBPMN se le puedeproporcionar una interpretación semántica:

Parallel Fork GatewayParallel Join GatewayData–based OR gatewaysEvent–based OR gatewaysOR–join gateways

M.I.Capel Tema 2 114/146

Page 123: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Parallel Fork Gateway

Se necesita una rama del P(i) por cada flujo de controlsaliente representado en estado de la puerta:

Figure: Modelo “black–box" de la puerta paralela de EBPMN.

M.I.Capel Tema 2 115/146

Page 124: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Data–based OR Gateway

Se utilizan puertas inclusivas para la selección de unconjunto de ramas de salida entre todos los flujos:

Figure: Modelo “black–box" del estado de la puerta OR de EBPMN.

M.I.Capel Tema 2 116/146

Page 125: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Formalización de extensiones temporales de EBPMN

En muchos modelos, no cumplir con las restriccionestemporales o respetar el acceso a recursos puedeocasionar la violación de las reglas de proceso de negocioLa definición de delays asociados a los eventos BPMN 2.0intermedios (timers) no es suficiente para definirrestricciones precisas es las especificaciones de losprocesos de negocioNuevas entidades de análisis han de ser incluidas enBPMN de tal manera que puedan cumplirse lasrestriciones temporales y de acceso a recursosY han de tener asociados operadores cuantificables paraexpresar intervalos de activación, plazos de tiempo(deadlines), etc. M.I.Capel Tema 2 117/146

Page 126: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Evento de comienzo, tiempo máximo y mínimo de unaactividad

Elegimos una extesión de BPMN que incluye una duraciónmáxima y míinima para cada actividad de BPMN:

Figure: Anotaciones temporales de la entidad “actividad" de EBMPN

M.I.Capel Tema 2 118/146

Page 127: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Tareas de servicios

El envio/recepción de mensajes debe ser llevado a cabodentro de los límites de tiempo de las actividades queenvían o recibenEstas actividades no pueden entrar en un estado deinter–bloqueo (deadlock state)

M.I.Capel Tema 2 119/146

Page 128: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Tareas de servicios II

Figure: Flujo de mensajes de tareas de servicio en EBMPN

M.I.Capel Tema 2 120/146

Page 129: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Interpretación Semántica

La comunicación debe tener lugar dentro de los intervalosdefinidos por las condiciones:

s(εm1), s(εm2) ∈[max{vS1, vS2},min{vS1 + S1.ran.min, vS2 + S2.ran.min}]

M.I.Capel Tema 2 121/146

Page 130: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN

Representación en EBPMN de un CRM

M.I.Capel Tema 2 122/146

Page 131: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Descripción de una AS

ISO/IEC/IEEE 42010Guiar en la construcción y mantenimiento del sistemaAyudar a planear los costes y evolución del sistemaServir como un medio para el análisis, evaluación ocomparación de arquitecturas softwareFacilitar la comunicación entre las partes interesadas enlas arquitecturas y los sistemasDocumentar el conocimiento arquitectónico más allá delámbito de los proyectos individualesCapturar idiomas arquitectónicos reutilizables (tales comoestilos arquitectónicos y patrones)

M.I.Capel Tema 2 123/146

Page 132: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Descripción de una AS

Ventajas para el diseño arquitectónicoLa descripción inicial del sistema pueda plasmarse deforma textual o gráfica utilizando distintos estilos ycomponentes arquitectónicosDesarrollar la descripción de subsistemas en función de lainformación que recibe o produceDescripción del comportamiento y sus elementosasociadosProporciona una documentacuón de alto nivel de la AS ydel sistema objetivoCon un ADL que proporcione facilidades para ello, puederealizarse análisis de desempeño, disponibilidad,seguridad del sistema

M.I.Capel Tema 2 124/146

Page 133: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

ADL

ConceptoResuelven el problema de la representación formal de unaarquitectura software desde un punto de vista sintáctico ysemántico [Bass et al. 1998][Clements 1996]Un ADL permite representar, analizar y especificar una ASPueden ser descriptivo–formales o semiformales, gráficos,o ambas cosasAlgunos han sido sólo definidos formalmente y otroscuentas con herramientas que los soportan

M.I.Capel Tema 2 125/146

Page 134: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

ADL

ActualesACME (carnegie-Mellon), CODE, UNICON, Wrigth, RAPIDE,Darwin (Imperial College), xADL (UCI), DAOP-ADL(Universidad de Málaga) y ByADL (Universidad de L’Aquila)

CaracterísticasLos primeros ADLs hacían más énfasis en el modelado decomponentes, conectores y configuraciones.Los ADLs actuales (ArchiMate, SysML, etc.) tienden a serlenguajes descriptivos de un espectro mucho más amplioSe pueden utilizar lenguajes de propósito general comoUML como ADLs así como para modelar procesos denegocio y similares.

M.I.Capel Tema 2 126/146

Page 135: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Requerimientos que han de satisfacer los ADLs

[Bass 1998][Luckhan y Vera 1995][Shaw y Garlan 1996]Capacidad de representación de componentes yelementos de análisis arquitectónico (conectores,interfaces, etc.)Proporcionar capacidad de análisis con el soporte deherramientas softwareIntegridad comunicacionalSoporte a las tareas de creación, refinamiento y validaciónde una AS

M.I.Capel Tema 2 127/146

Page 136: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Requerimientos que han de satisfacer los ADLs

Capacidad para representar la mayoría de los patronesarquitectónicos conocidos, directa o indirectamenteCapacidad de proveer vistas del sistema que expreseninformación arquitectónicaSoportar la especificación de familias deimplementaciones que satisfacen una arquitectura comúnCapacidad de análisis basada, o bien la capacidad para larápida generación de prototipos

M.I.Capel Tema 2 128/146

Page 137: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

An Architecture Description Interchange Language

Caracteríticas del lenguaje ACME

Una ontología arquitectónica que consiste en 7 elementosde diseño arquitectónico básicoUna notación flexible que soporta la asociación deinformación no estructural utilizando sub–lenguajesdefinidos externamenteUn mecanismo de tipos para abstraer estilos e idiomasarquitectónicos, reutilizables y de uso generalUn marco de trabajo semántico abierto para razonaracerca de las descripciones arquitectónicas

M.I.Capel Tema 2 129/146

Page 138: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Figure: Diagrama Cliente–Servidor Simple

M.I.Capel Tema 2 130/146

Page 139: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Ontología arquitectónica ACME

Elementos de ACMEcomponentes, conectores, sistemas, puertos, roles,representaciones y rep-maps

Los elementos más comunesComponentes: los elementos computacionales primarios ylos almacenes de datos de un sistemaConectores: representan interacciones entre componentesSistemas: representan las configuraciones decomponentes y conectores

M.I.Capel Tema 2 131/146

Page 140: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Ontología arquitectónica ACME

Elementos de ACMEcomponentes, conectores, sistemas, puertos, roles,representaciones y rep-maps

Los elementos más comunesComponentes: los elementos computacionales primarios ylos almacenes de datos de un sistemaConectores: representan interacciones entre componentesSistemas: representan las configuraciones decomponentes y conectores

M.I.Capel Tema 2 131/146

Page 141: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Sistema Cliente-Servidor Simple en Acme1 System simple_cs = {2 Component c l i e n t e = { Por t env iar−p e t i c i o n ; } ;3 Component se rv i do r = { Por t r e c i b i r −p e t i c i o n ; } ;4 Connector rpc = { Roles { l lama , l lamado } } ;5 Attachments {6 c l i e n t e . env iar−p e t i c i o n to rpc . l lama ;7 se rv i do r . r e c i b i r −p e t i c i o n to rpc . l lamado ;8 } }

Puerto enviar-peticion en el componente clienteSólo un puerto recibir-peticion en el servidorConector con 2 roles, denominados llama y llamadoLa topología de este sistema se declara listando unconjunto de attachments

M.I.Capel Tema 2 132/146

Page 142: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Sistema Cliente-Servidor Simple en Acme1 System simple_cs = {2 Component c l i e n t e = { Por t env iar−p e t i c i o n ; } ;3 Component se rv i do r = { Por t r e c i b i r −p e t i c i o n ; } ;4 Connector rpc = { Roles { l lama , l lamado } } ;5 Attachments {6 c l i e n t e . env iar−p e t i c i o n to rpc . l lama ;7 se rv i do r . r e c i b i r −p e t i c i o n to rpc . l lamado ;8 } }

Puerto enviar-peticion en el componente clienteSólo un puerto recibir-peticion en el servidorConector con 2 roles, denominados llama y llamadoLa topología de este sistema se declara listando unconjunto de attachments

M.I.Capel Tema 2 132/146

Page 143: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Figure: Elementos de una descripción ACME

M.I.Capel Tema 2 133/146

Page 144: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Descripción jerárquica de AS

Cada componente o conector posee una descripción, debajo nivel, más detalladaRepresentaciones: múltiples vistas de entidadesAunque, no se pueden resolver sintácticamenteFronteras de una encapsulaciónMúltiples niveles de refinamiento en las descripcionesConcepto de representation map (rep-map)rep-map simples:

asociación entre puertos internos y puertos externosasociación entre roles internos y roles externosEn otros casos los constructos rep-map pueden ser muchomás complejos M.I.Capel Tema 2 134/146

Page 145: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Figure: Representaciones y propiedades de un componente

M.I.Capel Tema 2 135/146

Page 146: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Anotación de entidades

Propiedades ACMECada ADL define un conjunto de información para añadir ala 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 anotadaAnotación de la estructura arquitectónica mediantelistas de propiedades

M.I.Capel Tema 2 136/146

Page 147: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Cómo usar las propiedades ACME

El significado de las propiedades no es definidoexplícitamenteACME sirve como un vehículo de convencionalización depropiedades entre varios ADLsLas propiedades poseen utilidad sólo cuando unaherramienta las utilizaComportamiento por defecto de una herramienta,delimitadores de propiedades

M.I.Capel Tema 2 137/146

Page 148: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Cómo usar las propiedades ACME (2)

El problema de representar estructuras arquitectónicasabstractasEl atributo type indica un sub–lenguajeTipos simples: integer, string, and booleanUtilización de los indicadores: name y type

M.I.Capel Tema 2 138/146

Page 149: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Propiedades del sistema Cliente–Servidor simple

1 System simple_cs = {2 Component c l i e n t e = {3 Por t enviar−p e t i c i o n ;4 Proper ty Aesop−s t y l e : s t y l e−i d = c l i e n t −server ;5 Proper ty UniCon−s t y l e : s t y l e−i d = cs ;6 Proper ty source−code : ex te rna l = "CODE−LIB / c l i e n t . c " ;7 }8 Component se rv i do r = {9 Por t r e c i b i r −p e t i c i o n ;

10 Proper ty idempotence : boolean = true ;11 Proper ty max−concurrent−c l i e n t s : i n t e g e r = 1 ;12 source−code : ex te rna l = "CODE−LIB / server . c " ;13 }14 // ...

M.I.Capel Tema 2 139/146

Page 150: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Propiedades del sistema Cliente–Servidor simple (2)

1 \ \ . . .2 Connector rpc = {3 Role l lama ;4 Role l lamado ;5 Proper ty asynchronous : boolean = true ;6 max−r o l es : i n t e g e r = 2 ;7 p ro toco l : Wright = " . . . " ;8 }9 Attachment c l i e n t e . env iar−p e t i c i o n to rpc . l lama ;

10 Attachment se rv i do r . r e c i b i r −p e t i c i o n to rpc . l lamado ;11 }

M.I.Capel Tema 2 140/146

Page 151: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Marco de trabajo semántico y abierto de ACME

ACME se enfoca a describir la estructura de una ASNo proporciona ninguna semántica computacional de lasarquitecturas que describe, de eso se encarga un marcode trabajo semántico y abierto para que lo usen otrosADLsLas especificaciones ACME intentan representar unpredicado denominado prescripciónProporcionan una correspondencia sencilla entre losaspectos estructurales de una AS en un formalismo lógicobasado en relaciones y restricciones

M.I.Capel Tema 2 141/146

Page 152: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Prescripción general para el Cliente-Servidor

1 e x i s t s c l i e n t , server , rpc |2 component ( c l i e n t ) ^3 component ( server ) ^4 connector ( rpc ) ^5 at tached ( c l i e n t . send−request , rpc . c a l l e r ) ^6 at tached ( server . receive−request , rpc . c a l l e e )

Falta especificar que todos los componentes han sidoidentificadosy las variables existenciales han de referirse a diferentesentidades

M.I.Capel Tema 2 142/146

Page 153: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Prescripción general para el Cliente-Servidor

1 e x i s t s c l i e n t , server , rpc |2 component ( c l i e n t ) ^3 component ( server ) ^4 connector ( rpc ) ^5 at tached ( c l i e n t . send−request , rpc . c a l l e r ) ^6 at tached ( server . receive−request , rpc . c a l l e e )

Falta especificar que todos los componentes han sidoidentificadosy las variables existenciales han de referirse a diferentesentidades

M.I.Capel Tema 2 142/146

Page 154: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Prescripción más elaborada

1 e x i s t s c l i e n t , server , rpc |2 component ( c l i e n t ) ^3 component ( server ) ^4 connector ( rpc ) ^5 at tached ( c l i e n t . send−request , rpc . c a l l e r ) ^6 at tached ( server . receive−request , rpc . 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 ( for a l l y : component ( y ) =>11 y = c l i e n t | y = server ) ^12 ( for a l l y : connector ( y ) => y = rpc ) ^13 ( for a l l p , q : at tached ( p , q ) =>14 ( p= c l i e n t . send−request ^ q=rpc . c a l l e r )15 | ( p=server . receive−request ^ q=rpc . c a l l e e ) )

M.I.Capel Tema 2 143/146

Page 155: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Gestión de las propiedades definidas

Nombres de propiedadesActúan como predicados de la Lógica:

NombreP : ℘(A) → {V , F}

Aesop − style(cliente) = client − serverUnicon − style(cliente) = cs

El predicado devuelve el valor del nombre de la propiedad parala entidad cliente

M.I.Capel Tema 2 144/146

Page 156: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

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 sublenguajeWright pueden interpretar el valor de la especificación delprotocolo anterior para descubrir una semántica propia del ADLmás detallada

M.I.Capel Tema 2 145/146

Page 157: Arquitecturas de Software

IntroducciónMecanismos Arquitectónicos

Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)

Caso de Estudio: An Architecture Description Interchange Language (ACME)

Lenguajes de descripción de arquitecturas

ADLs actualesRapide: se basa en la noción matemática de power sets yposee estructuras de programación muy potentes.UniCon: un ADL pensado para ayudar a los diseñadores adefinir AS utilizando abstracciones identificadas.Aesop: intenta dar solución al problema de la reutilizaciónde estilos arquitectónicos.Wright: se trata de un lenguaje formal que incluyecomponentes con puertos, conectores con roles ... y elpegamento para ligarlos. Los estilos arquitectónicos sepueden formalizar utilizando predicadosACME: un ADL de segunda generación, que intenta hacercooperar a los ADLs.UML: como ADL incluye muchos elementos de modeladoarquitectónico pero le falta una definición formal.

M.I.Capel Tema 2 146/146