Arquitecturas de Software
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Arquitecturas de Software

  • 825 views
Uploaded on

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

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.

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
825
On Slideshare
822
From Embeds
3
Number of Embeds
1

Actions

Shares
Downloads
40
Comments
0
Likes
0

Embeds 3

http://comunidad.itsae.edu.ec 3

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Arquitecturas Software M.I. Capel ETS Ingenierías Informática y Telecommunicación Universidad de Granada Email: manuelcapel@ugr.es Desarrollo de Software Ingeniería de Software (3er curso de Grado) M.I.Capel Tema 2 1/146
  • 2. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Índice 1 Introducción Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software 2 Mecanismos Arquitectónicos 3 Arquitecturas Orientadas a Componentes y Servicios Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN M.I.Capel Tema 2 2/146
  • 3. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Índice 1 Introducción Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software 2 Mecanismos Arquitectónicos 3 Arquitecturas Orientadas a Componentes y Servicios Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN M.I.Capel Tema 2 2/146
  • 4. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Índice 1 Introducción Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software 2 Mecanismos Arquitectónicos 3 Arquitecturas Orientadas a Componentes y Servicios Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN M.I.Capel Tema 2 2/146
  • 5. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Índice 1 Introducción Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software 2 Mecanismos Arquitectónicos 3 Arquitecturas Orientadas a Componentes y Servicios Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN M.I.Capel Tema 2 2/146
  • 6. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Arquitectura de Software Es una descripción de la estructura del software que se va a implementar, los datos que son parte del sistema, las interfaces entre los componentes del sistema, y algunas veces, los algoritmos utilizados. El diseño se obtiene iterativamente tras varias versiones. Incluye agregar formalidad y detalles durante el desarrollo del diseño, y regresar a los diseños anteriores y corregirlos. El proceso de diseño es aún un proceso adhoc [Bass et al. 2003] La Arquitectura de Software de un programa o sistema de computación es la estructura o estructuras del sistema, la cual comprende componentes de software, propiedadesM.I.Capel Tema 2 3/146
  • 7. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software El diseño arquitectónico definición Consiste en una actividad inicial de la fase de diseño de un sistema software cuyo objetivo es identificar los subsistemas y establecer un marco de trabajo para gestionar correctamente el control y la comunicación de dichos subsistemas M.I.Capel Tema 2 4/146
  • 8. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software El proceso de diseño El proceso de diseño incluye el desarrollo de varios modelos con diferentes niveles de abstracción La retroalimentación entre estas actividades y la consecuente repetición del trabajo es inevitable en todo proceso de diseño M.I.Capel Tema 2 5/146
  • 9. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Ubicación dentro de proceso de diseño El diseño arquitectónico representa el puente entre la especificación de requerimientos del sistema y el diseño Establecer un marco de trabajo básico que proporcione una estructura para situar los componentes principales de un sistema y las comunicaciones que tienen lugar M.I.Capel Tema 2 6/146
  • 10. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Especificación de requerimientos Existe un solapamiento entre análisis y especificación de requerimientos con el diseño arquitectónico La especificación no debería incluir ninguna información sobre diseño La descomposición arquitectónica es necesaria para estructurar y organizar la especificación de un sistema Normalmente se utiliza un modelo arquitectónico como el punto de partida para realizar la especificación de los subsistemas M.I.Capel Tema 2 7/146
  • 11. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Motivación de la Arquitectura de Software Existen unas necesidades fundamentales que justifican la importancia de construir una AS y de su análisis: Potencia la comunicación entre stakeholders Es el punto más temprano en el cual el sistema que va a ser construido puede ser analizado. Las decisiones de diseño aquí son muy importantes para conseguir requisitos críticos del sistema Abstracción de un sistema software: es una herramienta esencial para gestionar la complejidad de un sistema Modelo transferible a otros sistemas, especialmente a aquellos con requerimientos similares M.I.Capel Tema 2 8/146
  • 12. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Influencias Un AS es el resultado de diversas influencias técnicas, del negocio y sociales La existencia de una determinada AS para un dominio de aplicaciones afecta a su vez a los ambientes técnicos de negocio y sociales, que realimentan la futura arquitectura Un entendimiento temprano de las restricciones permite a los arquitectos de software gestionarlos, negociar expectativas con las partes implicadas (stakeholders), manejar riesgos, establecer compromisos, etc. M.I.Capel Tema 2 9/146
  • 13. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Recomendaciones para el proceso La arquitectura debe ser producto del equipo El equipo debe conocer los requerimientos funcionales y los de calidad priorizados Se debe documentar Revisada por todas la partes implicadas Analizada en base a mediciones Debe ser implementada incrementalmente M.I.Capel Tema 2 10/146
  • 14. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Recomendaciones para el producto Una AS debe ser modular Cada módulo debe tener una interfaz bien definida y encapsular toda la información Los atributos de calidad se deben alcanzar usando tácticas específicas para cada atributo Consideración El logro de dichos atributos dependerá fundamentalmente de la AS seleccionada [Bass et al.1998][SEI 2001], no sólo de la prácticas a nivel de código (lenguajes, diseño detallado, estructuras de datos y algoritmos) M.I.Capel Tema 2 11/146
  • 15. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Recomendaciones para el producto Una AS debe ser modular Cada módulo debe tener una interfaz bien definida y encapsular toda la información Los atributos de calidad se deben alcanzar usando tácticas específicas para cada atributo Consideración El logro de dichos atributos dependerá fundamentalmente de la AS seleccionada [Bass et al.1998][SEI 2001], no sólo de la prácticas a nivel de código (lenguajes, diseño detallado, estructuras de datos y algoritmos) M.I.Capel Tema 2 11/146
  • 16. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software AS y requisitos no–funcionales El estilo arquitectónico y estructura interna escogidos puede depender de requisitos no-funcionales: rendimiento, seguridad, fiabilidad, disponibilidad y mantenibilidad Rendimiento Clave: localizar las operaciones críticas dentro del menor número posible de subsistemas, que mantengan el mínimo acoplamiento posible Seguridad (control acceso a la información) Clave: utilizar una arquitectura estratificada donde los elementos más críticos se ubiquen en las capas más internas y cuyo acceso esté protegido muy rigurosamenteM.I.Capel Tema 2 12/146
  • 17. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripció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 en un solo subsistema o en un número pequeño de estos para conseguir la mayor protección Disponibilidad Clave: la arquitectura debe incluir componentes redundantes, tal que se puedan sustituir sin parar la ejecución del sistema Mantenibilidad Clave: utilizar componentes pequeños y autocontenidos que puedan ser cambiados con rapidez M.I.Capel Tema 2 13/146
  • 18. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software AS y requisitos no–funcionales III Conflicto de intereses El potenciar un atributo arquitectónico correspondiente a un requisito no–funcional puede estar en conflicto con los otros requisitos Ejemplo: utilizar componentes grandes mejora el rendimiento, en general, pero perjudica la mantenibilidad del diseño Se puede bien llegar a una solución de compromiso o utilizar distintos estilos arquitect´nicos para diferentes partes del sistema M.I.Capel Tema 2 14/146
  • 19. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Decisiones Arquitectónicas Cada enfoque desarrollado como parte de una descripción arquitectónica aborda un aspecto de la AS Se consideran una variedad de alternativas entre los posibles enfoques arquitectónicos, y su descripciones Las propias decisiones arquitectónicas pueden ser consideradas como un enfoque o vista de la arquitectura. Documentar las decisiones y las razones que las motivan dichas es una manera fundamental de concebir y expresar una arquitectura software [Babar09, Perry92]. Las decisiones arquitectónicas se pueden considerar como los primeros elementos de la descripción de una arquitectura software, por tanto, se han de hacer explícitas utilizando una plantilla de descripción arquitectónicaM.I.Capel Tema 2 15/146
  • 20. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Decisiones Arquitectónicas II Si una propiedad de un elemento arquitectónico no es visible o no es discernible de cualquier otro elemento arquitectónico, ese elemento no es arquitectónico. La selección de un manejador de base de datos no es una decisión arquitectónica. La razón de su existencia no es materia (no le concierne) a las metas arquitectónicas. Las decisiones son arquitectónicas o no de acuerdo al contexto. Si la estructura es importante para alcanzar las metas del sistema la estrutura es arquitectónica. M.I.Capel Tema 2 16/146
  • 21. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Plantilla de Descripción Arquitectónica Resolución Categoría Suposiciones Restricciones Alternativas Argumentos Implicaciones Decisiones relacionadas Productos de trabajo Notas M.I.Capel Tema 2 17/146
  • 22. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Descripción de una Arquitectura Software Una AS proporciona la definición del sistema objetivo en términos de elementos computacionales y de las interacciones entre ellos. La arquitectura muestra la correspondencia entre los requerimientos de sistemas y los elementos del sistema construido, proveyendo así una exposición racional para las decisiones de diseño. M.I.Capel Tema 2 18/146
  • 23. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Elementos notacionales de una AS Computacionales: Son entidades tales como clientes, servidores, bases de datos, filtros y capas de un sistema jerárquico. Son además, una parte encapsulada del sistema de software, donde cada uno tiene una interfaz. Interacciones: Ocurren entre los elementos a nivel de diseño, pudiendo ser tan simples como las llamadas a procedimientos o variables de acceso, o tan complejas y semánticamente ricas como los protocolos del modelo cliente-servidor, o los protocolos de acceso a las bases de datos. M.I.Capel Tema 2 19/146
  • 24. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Elementos notacionales de una AS II Relaciones: Denotan las conexiones entre los elementos computacionales y/o componentes. Relaciones estáticas: Se muestran en el código fuente, ellas reflejan la colocación de los componentes dentro de la arquitectura. Son fácilmente detectables a partir del código fuente. Relaciones dinámicas: Tratan con las conexiones temporales y las interacciones dinámicas entre los componentes. No se suelen detectar inspeccionando el código fuente del sistema final M.I.Capel Tema 2 20/146
  • 25. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Protocolo para obtener la representación de una AS 1 definir los aspectos estructurales como una composición de componentes, 2 las estructuras globales de control, 3 los protocolos de comunicación, 4 la sincronización y acceso a los datos, 5 la asignación de la funcionalidad a los elementos del diseño, 6 la composición de estos elementos, 7 su distribución física, 8 su escalabilidad y su desempeño M.I.Capel Tema 2 21/146
  • 26. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Proceso de Diseño Orientado a Objetos: un caso de estudio Definition (Sistema de Información Meteorológica (WMS)) Un WMS se necesita para generar informes meteorológicos regularmente utilizando datos recogidos de estaciones de observación remotas y sin personal, así como de otras fuentes tales como observadores voluntarios, globos y satélites. Como respuesta de una petición, las estaciones transmiten sus datos al computador encargado de área. El sistema del computador de área valida los datos recogidos desde diferentes fuentes y los integra. Los datos integrados son archivados y, utilizando los datos desde este archivo y los de una base de datos de informes meteorológicos, se crea un conjunto de informes locales. Los informes se pueden imprimirM.I.Capel Tema 2 22/146
  • 27. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Pasos a seguir 1 Entender y definir los modos de uso y el contexto del sistema WMS 2 Diseñar la arquitectura de software (AS) 3 Identificar los objetos principales dentro de la AS 4 Desarrollar los modelos de diseño 5 Especificar las interfaces de objetos M.I.Capel Tema 2 23/146
  • 28. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Selección de una arquitectura software Arquitectura estratificada (por capas) Cada capa sólo necesita del procesamiento de la capa inferior para operar Capas identificadas: Recoger Datos Procesar Datos Achivar Datos Mostrar Datos M.I.Capel Tema 2 24/146
  • 29. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Elementos notacionales: UML Cada capa incluye a otros componentes del sistema Se utilizan packaqes-UML Identificación de subsistemas M.I.Capel Tema 2 25/146
  • 30. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Arquitectura inicial del sistema objetivo M.I.Capel Tema 2 26/146
  • 31. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Modelos de uso y contexo del sistema Definition (Objetivo) Desarollar una comprensión de las relaciones entre el software que está siendo diseñado y su entorno El contexto del sistema es un modelo estático que describe a otros sistemas Se utiliza un modelo dinámico para describir cómo interactúa el sistema realmente con su entorno Utilizar diagramas de casos de uso Un caso de uso por cada interacción entre el sistema y su entorno Asociaciones entre casos de uso y descripciones según M.I.Capel Tema 2 27/146
  • 32. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Diseño arquitectónico Guiado por la descripción de las interacciones del sistema con su entorno Componente Estación Meteorológica: 1 Interfaz: comunicaciones con las otras partes del sistema 2 Recolección: de datos: gestionar los datos recogidos por los instrumentos y el resumen de los datos meteorológicos antes de transmitirlos 3 Instrumentación: encapsulación de los instrumentos utilizados para recoger los datos en bruto 4 Descomponer los modelos hasta que sólo existan 7 entidades de modelado como máximo en un modelo arquitectónico M.I.Capel Tema 2 28/146
  • 33. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Componentes de Subsistemas M.I.Capel Tema 2 29/146
  • 34. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Arquitectura de Componentes M.I.Capel Tema 2 30/146
  • 35. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Los objetos tienden a emerger durante el diseño El diseño tiene que ver con la identificación de las clases Identificación de atributos y operaciones de las clases desde la descripción informal del sistema Identificación de objetos de la estación meteorológica: Objetos del dominio de aplicación: 1 Termómetro Tierra 2 Anemómetro 3 Barómetro Objetos procedentes de escenarios de casos de uso: 1 EstacionMeteo 2 DatosMeteo M.I.Capel Tema 2 31/146
  • 36. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Clases de Objetos M.I.Capel Tema 2 32/146
  • 37. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Carácter pasivo/activo de los objetos Los objetos pasivos ejecutan sus métodos por petición del sistema: cambios en la política de recogida de datos no afecta a las clases que los modelan Objetos activos incluyen su propio control, deciden cuándo realizan las lecturas de los instrumentos: perjudica la interoperabilidad M.I.Capel Tema 2 33/146
  • 38. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Modelos estáticos y dinámicos Los modelos de diseño son el puente entre los requisitos del sistema y la implementación del sistema: 1 Modelos estáticos: clases, objetos, relaciones de generalización, usa/usado–por, composición 2 Modelos dinámicos: diagramas de secuencia y de estados, entre otros (UML proporciona 12 modelos dinámicos de diagramas) Modelos de subsistemas: incluyen componentes y asociaciones Secuencias: para cada modo de interacción del sistema, la secuencia de llamadas entre objetos que tienen lugar Estados: comportamiento de un solo objeto en respuesta a los mensajes que puede procesar M.I.Capel Tema 2 34/146
  • 39. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Descomposición de paquetes M.I.Capel Tema 2 35/146
  • 40. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Modelo de secuencia de operaciones M.I.Capel Tema 2 36/146
  • 41. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Diagrama de estados M.I.Capel Tema 2 37/146
  • 42. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Negocio de una Arquitectura Software Descripción de una Arquitectura Software Especificar las interfaces de objetos Especificar las interfaces de los objetos de tal manera que los objetos y los subsistemas se puedan diseñar en paralelo No incluir detalles de la representación en el diseño Sólo proporcionar las operaciones de los objetos necesarias para acceder y actualizar los datos del objeto No tiene por qué existir una relación 1:1 entre objetos e interfaces Utilizar un lenguaje de programación (como Java) para definir las interfaces de los objetos M.I.Capel Tema 2 38/146
  • 43. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Modelos abstractos de AS Modelo 4+1 Vistas de Krutchen En la actualidad el desarrollo de sistemas se centra en la arquitectura software, que es especificada utilizando el modelo siguiente M.I.Capel Tema 2 39/146
  • 44. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Modelos abstractos de AS Modelo 4+1 Vistas de Krutchen En la actualidad el desarrollo de sistemas se centra en la arquitectura software, que es especificada utilizando el modelo siguiente M.I.Capel Tema 2 39/146
  • 45. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ciclo de Arquitecturas de Negocio (ABC) Ciclo de retroalimentación entre una AS y un negocio Según [Bass et al. 2003], estos y otros mecanismos de retroalimentación forman lo que se llama “ABC” En [Krutchen 2003] también se indica esta relación de la AS con el negocio: se habla de tres campos de arquitectura muy relacionados durante el desarrollo: M.I.Capel Tema 2 40/146
  • 46. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Estilos Arquitectónicos Define una familia de sistemas de software en términos de su organización estructural. Representa los componentes y las relaciones entre ellos con las restricciones de su aplicación y las asociaciones y reglas de diseño para su construcción Define un vocabulario de componentes y tipos de conectores. Ejemplos de Estilos Arquitectónicos Pipes and filters, Tipos de datos abstractos y OO, Repositorios, Capas, Basados en Eventos, Intérpretes, etc. M.I.Capel Tema 2 41/146
  • 47. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Estilos II La imposición de ciertos estilos arquitectónicos mejora o disminuye las posibilidades de satisfacción de ciertos atributos de calidad del sistema [Bosch, 2000] Cada estilo propicia atributos de calidad, y la decisión de implementar alguno de los existentes depende de los requerimientos de calidad del sistema. Un criterio importante del éxito de los estilos es la forma en que estos alcanzan de manera satisfactoria los objetivos de la Ingeniería de Software. [Buschmann et al.,1996] M.I.Capel Tema 2 42/146
  • 48. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Diferencias entre estilos y patrones arquitectónicos Estilo Arquitectónico -Sólo describe el esqueleto estructural y general de las aplicaciones -Son independientes del contexto al que puedan ser aplicados -Cada estilo es independiente de los otros -Expresan técnicas de diseño desde una perspectiva independiente de la situación actual de un diseño -Pueden comprenderse también como una clasificación de los sistemas software Patrón Arquitectónico -Varios rangos de escala, comenzando con la definición de la estructura básica de una aplicación -Necesitan de la definición de un contexto del problema -Dependen de patrones más pequeños, con los que interactúan; o de patrones que los contengan -Expresan un problema recurrente de diseño, muy específico, presentando una solución, desde el punto de vista del contexto en el que se presenta -Son soluciones generales a problemas comunesM.I.Capel Tema 2 43/146
  • 49. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes 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 una relación entre un contexto, un problema y una solución. 1 Contexto: Es una situación de modelado de una parte del sistema en la que aparece un problema de diseño. 2 Problema: Es un conjunto de fuerzas que aparecen repetidamente en el contexto. 3 Solución: Es una configuración que equilibra estas fuerzas. M.I.Capel Tema 2 44/146
  • 50. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes 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 una relación entre un contexto, un problema y una solución. 1 Contexto: Es una situación de modelado de una parte del sistema en la que aparece un problema de diseño. 2 Problema: Es un conjunto de fuerzas que aparecen repetidamente en el contexto. 3 Solución: Es una configuración que equilibra estas fuerzas. M.I.Capel Tema 2 44/146
  • 51. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Patrones II Para Buschmann son plantillas para arquitecturas de software concretas, que especifican las propiedades estructurales de una aplicación y tienen un impacto en la arquitectura de subsistemas. El uso de ciertos mecanismos, como los estilos y patrones arquitectónicos, permite mejorar las características de calidad en el software [Bosch, 2000], bien sean éstas observables o no en tiempo de ejecución [Bass et al., 2003]. M.I.Capel Tema 2 45/146
  • 52. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) El ámbito del patrón es menos general que el del estilo arquitectónico Un patrón impone una regla a la arquitectura, describiendo cómo el software gestionará algún aspecto de su funcionalidad (p.e.: la concurrencia). Los patrones arquitectónicos tienden a abordar problemas comportamentales específicos dentro del contexto de una arquitectura Los patrones y los estilos arquitectónicos se pueden utilizar de forma conjunta para dar forma a la estructura completa de un sistema. M.I.Capel Tema 2 46/146
  • 53. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Diferencias según el nivel de abstracción M.I.Capel Tema 2 47/146
  • 54. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Patrón Interceptor Permite a determinados servicios ser añadidos de manera transparente a un marco de trabajo y ser disparados automáticamente cuando ocurren ciertos eventos Contexto: Desarrollo de marcos de trabajo que puedan ser extendidos de manera transparente Problema: Los marcos de trabajo, arquitecturas software, etc. ha de poder anticiparse a las demandas de servicios concretos que deben ofrecer a sus usuarios Integración dinámica de nuevos componentes sin afectar a la AS o a otros componentes Solución: Registro offline de servicios a través de una interfaz predefinida del marco de trabajo, posteriormente se disparan estos servicios cuando ocurran determinadosM.I.Capel Tema 2 48/146
  • 55. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Interceptor M.I.Capel Tema 2 49/146
  • 56. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Estructura de clases de “Interceptor" Un FrameworkConcreto que instancia una arquitectura genérica y extensible Los Interceptores que son asociados con un evento particular InterceptoresConcretos que especializan las interfaces del interceptor e implementan sus métodos de enlace Despachadores para configurar y disparar interceptores concretos Una Aplicación que se ejecuta por encima de un framework concreto y utiliza los servicios que éste le proporciona M.I.Capel Tema 2 50/146
  • 57. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Implicaciones en la calidad del patrón Interceptor Beneficios Atributo de calidad Características ISO 9126 Cambiar/incluir servicios de un framework Extensibilidad, Mantenibilidad sin que sea preciso cambiarlo Flexibilidad,Dinamismo Facilita cambios Añadir interceptores sin afectar al Acoplamiento Mantenibilidad código de la aplicación Facilita cambios Obtención dinámica inform. del framework Monitorización Tolerancia a fallas con intercept. y objetos–contexto Control Uso de recursos Infraestructura de servicios estratificada con Encapsulamiento Mantenibilidad interceptores correspondientes simétricos Facilita cambios,análisis Reutilización de interceptores en Reusabilidad Mantenibilidad diferentes aplicaciones Facilita cambios M.I.Capel Tema 2 51/146
  • 58. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Implicaciones en la calidad 2 Inconvenientes Atributo de calidad Características ISO 9126 Difícil ajuste del número de Complejidad Facilita cambios despachadores e interceptores Flexib., extensibilidad Facilita análisis Bloqueo aplicación por Disponibilidad Mantenibilidad fallo del interceptor Modificabilidad Madurez, Tolerancia Fallas Degradación rendimiento por Rendimiento Eficiencia,madurez cascadas de interceptores Bloqueo Tolerancia fallas Insuficientes interceptores y despachadores reduce la flexibilidad y extensibilidad del framework concreto. Sistema demasiado grande e ineficiente, complejo de aprender, implementar, usar, y optimizar, utilizando demasiados interceptores Para evitar el bloqueo completo de la aplicación pueden utilizarse estrategias de time-out, pero esto puede complicar el diseño del framework concreto Las cascadas de intercepción pueden conllevar una degradación del rendimiento o un bloqueo de la aplicación M.I.Capel Tema 2 52/146
  • 59. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes 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 BloqueoM.I.Capel Tema 2 53/146
  • 60. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes 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
  • 61. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Patrón Broker Para modelar sistemas distribuidos compuesto de componentes software totalmente desacoplados Contexto: cualquier sistema distribuido y, posiblemente, heterogéneo con componentes cooperando dentro de un sistema de información Problema:¿Cómo estructurar componentes configurables dinámicamente e independientes de los mecanismos concretos de comunicación de un sistema distribuido? Solución: Introducir un componente Broker para mejor desacoplamiento entre clientes y servidores Las tareas de los Brokers incluyen la localización del servidor apropiado, envío de la petición al servidor y transmisión de los resultadosM.I.Capel Tema 2 55/146
  • 62. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Broker M.I.Capel Tema 2 56/146
  • 63. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Estructura de clases del patrón Broker Intermediario: admite las solicitudes, asigna los servidores y responde a las peticiones de los clientes Servidor: se registra en el Intermediario e implementa el servicio Cliente: accede a los servicios remotos Proxy Cliente y Proxy Servidor, que proporcionan transparencia, ocultando los detalles de implementación del patrón Puente: le proporciona interoperabilidad al Intermediario M.I.Capel Tema 2 57/146
  • 64. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Implicaciones en la calidad del patrón Broker Beneficios Atributos de calidad Característica ISO 9126 Separación código de comunicaciones. Acoplamiento Facilita cambios Modificabilidad Fac.análisis,pruebas Independencia de la plataforma de Escalabilidad Facilita cambios ejecución para la aplicación Uso de recursos Mejor descomposición del Interoperabilidad Interoperabilidad espacio del problema Simplicidad Facilita análisis Independencia de la implementación Modificabilidad Mantenibilidad concreta de cada capa Flexibilidad Fac.cambios Interacciones basadas en el Transparencia Funcionalidad paradigma de objetos Interoperabilidad Arquitectura software Dinamismo Facilita cambios muy flexible Facilita análisis Reducción complejidad de Modificabilidad Facilita cambios programación distribuida Flexibilidad Facilita análisis Integración de tecnologías Reusabilidad Facilita cambios Facilita análisis Distribución del modelo de Interoperabilidad Portabilidad M.I.Capel Tema 2 58/146
  • 65. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Implicaciones en la calidad 2 Inconvenientes Atributos de calidad Características ISO 9126 Empeora el rendimiento de la Rendimiento Eficiencia aplicación Tiempo respuesta Impide la verticalidad Optimización Facilidad pruebas en acceso a capas internas Ocultamiento Uso recursos Tolerancia fallas Las capas de abstracción a las que conduce este patrón pueden perjudicar el desempeño Usar una capa separada del Broker puede ocultar los detalles sobre cómo la aplicación utiliza la capa más baja Eventualmente, optimizaciones específicas del rendimiento de algunas capas podrían resultar perjudicadas M.I.Capel Tema 2 59/146
  • 66. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes 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 + MultiplataformaM.I.Capel Tema 2 60/146
  • 67. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes 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
  • 68. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Patrón Reflection Proporciona un mecanismo para cambiar la estructura y comportamiento de sistemas software dinámicamente Soporta la modificación de aspectos fundamentales, tales como estructuras y mecanismos de llamadas a funciones. Contexto: Cualquier sistema que necesita soporte para realizar cambios propios y para conseguir persistencia de sus entidades Problema: ¿Cómo se puede modificar el comportamiento de los objetos de una jerarquía dinámicamente sin afectar a los propios objetos en su configuración actual? Solución: Hacer que el software sea “auto-consciente" de su función y comportamiento, haciendo que los aspectos seleccionados sean accesibles para su adaptación yM.I.Capel Tema 2 62/146
  • 69. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Reflection M.I.Capel Tema 2 63/146
  • 70. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Estructura de clases del patrón Reflection Meta Nivel: proporciona la información acerca de las propiedades escogidas del sistema y hace que el sistema sea auto-consciente Meta Objetos: encapsulan y representan información acerca del software Nivel Base: incluye la lógica de la aplicación Los cambios mantenidos en el Meta Nivel afectan consecuentemente al comportamiento del Nivel Base La implementación del Meta Nivel utiliza Meta Objetos para mantenerse independiente de aquellos aspectos que son propensos a cambiar M.I.Capel Tema 2 64/146
  • 71. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Implicaciones en la calidad del patrón Reflection Beneficios Atributos de calidad Características ISO 9126 Comprobación correctitud desde Correctitud Funcionalidad el nivel de MetaObjetos Precisión Ejecución de los cambios Dinamismo Facilidad cambios desde el nivel de MetaObjetos Facilidad análisis Modificación y extensión de Modificabilidad Mantenibilidad componentes software facilitada Extensibilidad Facilidad cambios Cambios en el software del Modificabilidad Mantenibilidad NivelBase facilitados Extensibilidad Facilidad cambios Asume modificaciones no explícitas Extensibilidad Mantenibilidad del código fuente Facilidad cambios Soporte para muchos Modificabilidad Mantenibilidad tipos de cambios Facilidad cambios M.I.Capel Tema 2 65/146
  • 72. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Implicaciones en la calidad 2 Inconvenientes Atributos de calidad Características ISO 9126 Complejidad de diseño e implementación Complejidad Facilidad análisis por los niveles y protocolo meta–objetos Facilidad pruebas Demasiados meta–objetos en Rendimiento Uso recursos la aplicación final Eficiencia Modificaciones en meta–nivel pueden Fallas Madurez causar daños comportamiento del sistema Tolerancia a fallas Rendimiento sistema puede ser afectado Complejidad Eficiencia por complejidad diseño del patrón Tiempo respuesta Difícil adaptación a la evolución de los Adaptabilidad Tiempo respuesta productos generados con el patrón Eficiencia M.I.Capel Tema 2 66/146
  • 73. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes 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
  • 74. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes 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
  • 75. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Categorización de los Estilos Arquitectónicos Arquitecturas centradas en los datos El núcleo de estas arquitecturas es un repositorio o una base de datos a la que acceden las aplicaciones–cliente Las aplicaciones cliente acceden a los datos o ejecutan sus procesos de forma totalmente independiente entre ellos Propician la integrabilidad Arquitecturas de Flujo de Datos Los datos de entrada han de ser transformados tras la actuación de componentes de la AS hasta producir los datos de salida Sus componentes se llaman filtros y encauzamientos, que M.I.Capel Tema 2 69/146
  • 76. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Categorización de los Estilos Arquitectónicos Arquitecturas de Llamada–retorno Arquitecturas Programa principal–subprograma: jerarquía de control donde se invocan varios componentes que, a su vez, pueden invocar a otros componentes Arquitecturas Llamada a procedimiento remoto: los componentes se distribuyen ahora a través de múltiples computadores conectados por una red Arquitecturas Estratificadas Estructuradas en capas que realizan operaciones que van acercándose a nivel de las instrucciones–máquina: -operaciones nivel interfaz de usuarioM.I.Capel Tema 2 70/146
  • 77. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Categorización de los Estilos Arquitectónicos Arquitecturas Orientadas a Objeto Los componentes de un sistema que sea conforme con este tipo de arquitectura encapsulan los datos y las operaciones que deben ser aplicadas para manipularlos La comunicación y coordinación entre componentes se llevan a cabo mediante paso de mensajes M.I.Capel Tema 2 71/146
  • 78. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Arquitecturas de referencia Conceptos Los estilos arquitectónicos se pueden aplicar a muchos dominios de aplicaciones Reutilización de la estructura arquitectónica común de los modelos que se aplican a un mismo dominio de aplicaciones Arquitecturas específicas de un dominio de aplicaciones Modelos genéricos: abstracciones de un número de sistemas con elementos comunes. Modelos de referencia: AS idealizada que incluye todas las características que los sistemas software de esa claseM.I.Capel Tema 2 72/146
  • 79. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Arquitecturas de referencia Conceptos Los estilos arquitectónicos se pueden aplicar a muchos dominios de aplicaciones Reutilización de la estructura arquitectónica común de los modelos que se aplican a un mismo dominio de aplicaciones Arquitecturas específicas de un dominio de aplicaciones Modelos genéricos: abstracciones de un número de sistemas con elementos comunes. Modelos de referencia: AS idealizada que incluye todas las características que los sistemas software de esa claseM.I.Capel Tema 2 72/146
  • 80. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Características de las arquitecturas de referencia No se consideran como una guía de implementación de los sistemas software Se utilizan para discutir la aplicación de AS específicas de un dominio de aplicaciones y compararlas Proporcionan un vocabulario de términos que aluden a los sistemas dentro de un mismo dominio de aplicaciones Proporcionan una base conceptual con respecto a la cual se pueden evaluar las diferentes propuestas arquitectónicas Ejemplos de arquitecturas de referencia: el modelo OSI de redes, modelo de referencia CASE M.I.Capel Tema 2 73/146
  • 81. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) M.I.Capel Tema 2 74/146
  • 82. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Ejemplo: Modelo de Referencia CASE Tipos de servicicios del modelo Repositorio de datos: manejo de los items de datos y sus relaciones Integración de datos: la base para conseguir la integración de los datos Gestión de tareas: definición y representación de los modelos de procesos Mensajes: comunicaciones herramienta–herramienta, entorno–herramienta y entorno–entorno Interfaces de usuario: presentación integrada de la funcionalidad y servicios del sistema M.I.Capel Tema 2 75/146
  • 83. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Concepto y Motivación Concepto Las arquitecturas basadas en componentes y servicios: la funcionalidad de las aplicaciones ahora se implementa en la forma de componentes reutilizables e invocables mediante interfaces estándar, que pueden combinarse para crear funciones progresivamente más complejas. Motivación La dificultad de las arquitecturas tradicionales para integrarse en los procesos de negocio reside en que sus aplicaciones no están diseñadas para ser integradas con otras M.I.Capel Tema 2 76/146
  • 84. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Arquitectura simple de una aplicación Figure: Aplicación de negocios M.I.Capel Tema 2 77/146
  • 85. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Servicios ¿Qué es un servicio? “Representación estándar para cualquier recurso computacional o de información que pueda ser utilizado por otras aplicaciones", Turner (2003) “Organización global encargada de establecer y adoptar los estándares de los servicios Web", OASIS (Organization for the Advancement of Structured Information Standards) M.I.Capel Tema 2 78/146
  • 86. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Características de un servicio La provisión del servicio es independiente de la plataforma de la aplicación que lo proporciona Capacidades externas para procesamiento Acceso consistente a través de interfaces Adaptación a políticas y restricciones predefinidas Las aplicaciones se construyen enlazando servicios desde varios proveedores utilizando lenguajes de programación (p.e. Java) o de instrumentación de servicios (p.e. BPEL) M.I.Capel Tema 2 79/146
  • 87. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Tipos de servicios Servicios: Interacción Proceso Servicios de Aplicación de Negocios Información Servicios de Acceso Socios Servicios de Innovación y Optimización Servicios de Desarrollo Manejo de Servicios IT M.I.Capel Tema 2 80/146
  • 88. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Antecedentes de servicios SOA Domain Name System (DNS) Es una parte muy importante de la configuración de un sistema distribuido Suele “entenderse" como un computador que proporciona información de un dominio de nombres a una red Servicio de Dominio de Nombres Garantiza de nombres únicos en toda la red, insensibles a mayúsculas–minúsculas, que consisten en una cadena de caracteres alfanuméricos y guiones separados por puntos, que el DNS hace corresponder con números de IP y otra información M.I.Capel Tema 2 81/146
  • 89. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Antecedentes de servicios SOA II Servicios de Intermediación Servicio de meta–información (“trading") esencial de los sistemas abiertos Actúa como un mediador global entre servicios, aplicaciones y clientes Permite construir un ambiente de computación a escala mundial Evolución constante de servicios y aplicaciones Ingeniería de Software para Sistemas Abiertos M.I.Capel Tema 2 82/146
  • 90. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Antecedentes de servicios SOA III Servicios de Eventos Sirven de soporte al intercambio de mensajes asíncrono entre objetos en Sistemas Distribuídos Dependen de una infraestructura basada en eventos ( como JEDI) Ejemplos de servicios de eventos: Servicios de Notificación de Eventos (SIENA) CORBA Event Service Servicios de alerta que pueden ser construidos sobre servicios de eventos M.I.Capel Tema 2 83/146
  • 91. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Motivación para SOA Proveedores de tecnología (consultores y usuarios), están de acuerdo en que el enfoque Service Oriented Architecture (SOA) permite mejorar la calidad de las aplicaciones y dar una mejor respuesta a las partes interesadas de un modelo de negocio M.I.Capel Tema 2 84/146
  • 92. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Modelado de Procesos de Negocios “Proceso de Negocio" (BP) Conjunto de servicios interactivos, estructurados y relacionados que de manera integrada son capaces de proporcionar una funcionalidad compleja para implementar los procesos y tareas de un negocio de acuerdo con sus reglas. Modelado de Procesos de Negocio (BPM) Se trata de una actividad conceptual para comprender el funcionamiento y describir la compleja estructura de los procesos de negocio de una empresa, de tal manera que dichos procesos puedan ser entonces analizados y mejorados. M.I.Capel Tema 2 85/146
  • 93. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Representación de un modelo de proceso de negocio M.I.Capel Tema 2 86/146
  • 94. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Caracterización de SOA ¿Qué es SOA? Una arquitectura flexible y estándar que unifica los procesos de negocio estructurando grandes aplicaciones como colecciones de servicios. Estas aplicaciones pueden ser usadas por usuarios dentro o fuera de la organización. Estilo arquitectónico SOA es también un estilo de arquitectura donde todas las funcionalidades, ya sean existentes o nuevas, son agrupadas en servicios que se comunican entre sí. M.I.Capel Tema 2 87/146
  • 95. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Tecnologías de soporte para arquitecturas distribuidas Figure: Grado de cobertura de propiedades requeridas M.I.Capel Tema 2 88/146
  • 96. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Requerimientos de un SOA Interoperabilidad entre los distintos sistemas y lenguajes de programación presentes en la organización Utilización de un protocolo estándar Los servicios han de ser descritos con un lenguaje claro y preciso independiente de la plataforma Mecanismo de búsqueda para obtener remotamente los servicios que ya han sido implementados M.I.Capel Tema 2 89/146
  • 97. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Servicios Web Los Servicios Web son servicios implementados utilizando estándares como SOAP, WSDL y UDDI para ser accedidos a través de una red, preferiblemente Internet y ejecutados remotamente Protocolo estándar Service Oriented Architecture Protocol (SOAP) Lenguaje de descripción de servicios Web Service Description Language (WSDL) Descubrimiento de servicios disponibles Universal Description Discovery and Integration (UDDI)M.I.Capel Tema 2 90/146
  • 98. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Principios de Diseño de SOA Reglas para desarrollar, mantener y usar servicios Encapsulado (en servicios SOA): Para los servicios que no estén diseñados para ser parte de SOA Acoplamiento Ligero: Independencia entre servicios, sólo se “conocen" Contratos: Los servicios deben cumplir con unas reglas de comunicación preestablecidos en documentos Abstracción: La lógica interna de los servicios no tiene que ser conocida por el ambiente en el que se van a ejecutar M.I.Capel Tema 2 91/146
  • 99. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Principios de Diseño de SOA II Reglas para desarrollar, mantener y usar servicios Reutilización: Los servicios deben ser diseñados siempre para su reutilización por varias aplicaciones remotas Composición: Colecciones de servicios han de poder ser compuestos para formar otros servicios Autonomía: Los servicios son los únicos que controlan su lógica interna Optimización: Deben ser lo más eficientes posible Descubrimiento: Los servicios son diseñados para facilitar su descubrimiento en el ambiente en que se ejecutan M.I.Capel Tema 2 92/146
  • 100. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Tecnologías XML Un lenguaje de marcas. XML se basa en la combinación de texto con información que describe ese texto. En XML se utilizan las etiquetas (tags) para describir bloques de texto. Fue diseñado para compartir fácilmente las estructuras de datos a través de la red. SOAP Simple Object Access Protocol es un protocolo estándar bajo el auspicio de la W3C que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML M.I.Capel Tema 2 93/146
  • 101. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Tecnologías WSDL Web Service Description Language es un lenguaje basado en XML utilizado para describir los Servicios Web. Este lenguaje define a los servicios como colecciones de puertos, donde cada puerto indica una función del servicio que está siendo descrito. Así, cualquier usuario de un servicio puede leer el WSDL y saber qué funciones se pueden llamar utilizando SOAP. UDDI Universal Description, Discovery and Integration es un registro basado en XML para listar servicios en Internet. Está diseñado para ser interrogado con mensajes SOAP y proveer acceso aM.I.Capel Tema 2 94/146
  • 102. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Tecnologías BPEL Business Process Execution Language es un lenguaje ejecutable de procesamiento de negocios basado en XML. BPEL nació como la combinación de WSFL (IBM) y XLANG (Microsoft) para crear un estándar mundial de ejecución de procesos de negocio. Este lenguaje se utiliza para orquestar la ejecución de un proceso, llamando a los servicios que va necesitando. M.I.Capel Tema 2 95/146
  • 103. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Implementación de WS Figure: Implementación de una arquitectura para Web–Services M.I.Capel Tema 2 96/146
  • 104. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Bus de Servicios de Empresa ESB Enterprise Service Bus es el punto de comunicación entre todos los servicios. Funciona de forma transparente. No debe contener lógica del negocio. M.I.Capel Tema 2 97/146
  • 105. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Arquitectura SOA modelo M.I.Capel Tema 2 98/146
  • 106. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Ciclo de vida de un SOA Modelado del negocio. Diseño de un sistema de información Implementación del sistema de información Evaluación del sistema para refinarlo y volver a modelar M.I.Capel Tema 2 99/146
  • 107. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Ciclo de vida de un SOA Modelado Capturar el diseño del negocio (de requerimientos y objetivos) Traducir a procesos de negocio y metas Se recomienda elaborar distintos escenarios que permitan obtener más información sobre los procesos de negocio Definir los Key Performance Indicators (KEI) M.I.Capel Tema 2 100/146
  • 108. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Ciclo de vida de un SOA Desarrollo Convertir el diseño de negocio en definiciones de procesos y actividades Transformarlos a los servicios de la arquitectura Estudiar aplicaciones ya existentes y reutilizar (asegurando estándares SOA) Implementar los servicios que faltan M.I.Capel Tema 2 101/146
  • 109. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Ciclo de vida de un SOA Despliegue Crear un ambiente en el que se ejecuten las aplicaciones Resolver dependencias Condiciones operacionales, requisitos de capacidad y restricciones de integridad y acceso M.I.Capel Tema 2 102/146
  • 110. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Ciclo de vida de un SOA Gestión Determinar la manera de mantener el ambiente operacional y las políticas de implementación Monitorizar la efectividad de las solicitudes de servicio y el tiempo de respuesta Mantener registros de fallos y recuperar tareas Monitorización de las métricas de negocio (KPI) que se definieron en el diseño M.I.Capel Tema 2 103/146
  • 111. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Ciclo de vida de un SOA Gobernabilidad Definir los derechos de decisión para el desarrollo, despliegue y manejo de nuevos servicios Supervisar que se cumplen las políticas, estándares, proceso y procedimientos Ayuda a identificar qué proyectos contribuyen principalmente a conseguir las metas de negocio Definir los roles y las responsabilidades de cada miembro del equipo de forma clara M.I.Capel Tema 2 104/146
  • 112. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre arquitecturasorientadas a servicios Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Microsoft Service Management M.I.Capel Tema 2 48/56
  • 113. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre arquitecturasorientadas a servicios Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Enfoque de SUN M.I.Capel Tema 2 49/56
  • 114. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre arquitecturasorientadas a servicios Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Ejemplo de arquitectura de SUN M.I.Capel Tema 2 50/56
  • 115. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Modelado de Procesos de Negocio BPMN “Business Process Model and Notation"(BPMN) se considera actualmente como el lenguaje de modelado de procesos de negocio estándar. Características BPMN utiliza una notación gráfica similar a UML Tal como éste, la semántica de BPMN no está formalmente definida La ausencia de tal semántica produce un problema para la validación de los modelos de procesos de negocio BPMN 2.0 intenta modelar los procesos con restriccionesM.I.Capel Tema 2 108/146
  • 116. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Modelado de Procesos de Negocio BPMN “Business Process Model and Notation"(BPMN) se considera actualmente como el lenguaje de modelado de procesos de negocio estándar. Características BPMN utiliza una notación gráfica similar a UML Tal como éste, la semántica de BPMN no está formalmente definida La ausencia de tal semántica produce un problema para la validación de los modelos de procesos de negocio BPMN 2.0 intenta modelar los procesos con restriccionesM.I.Capel Tema 2 108/146
  • 117. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN La notación BPMN M.I.Capel Tema 2 109/146
  • 118. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Ejemplo de especificación con BMPN Figure: Proceso logístico de una farmacia de hospital M.I.Capel Tema 2 110/146
  • 119. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Un tipo especial de diagrama de flujo: Business Process Diagram (BPD) Gateways Events Activities Flows M.I.Capel Tema 2 111/146
  • 120. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Representación gráfica de un estado en BPMN Type in out error send/receive exit_1 exit_2 exit_3 links & dependences Type N M.I.Capel Tema 2 112/146
  • 121. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Representación con BPD de las entidades BMPN Figure: Representación gráfica de los elementos de BPMN Extendido. M.I.Capel Tema 2 113/146
  • 122. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Notación de modelado de BPMN extendido EBPMN necesita de la precisión semántica que le proporciona un lenguaje formal a sus elementos básicos para transformar sus procesos de negocio en modelos ejecutables Al siguiente conjunto de constructos EBPMN se le puede proporcionar una interpretación semántica: Parallel Fork Gateway Parallel Join Gateway Data–based OR gateways Event–based OR gateways OR–join gateways M.I.Capel Tema 2 114/146
  • 123. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Parallel Fork Gateway Se necesita una rama del P(i) por cada flujo de control saliente representado en estado de la puerta: Figure: Modelo “black–box" de la puerta paralela de EBPMN. M.I.Capel Tema 2 115/146
  • 124. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Data–based OR Gateway Se utilizan puertas inclusivas para la selección de un conjunto de ramas de salida entre todos los flujos: Figure: Modelo “black–box" del estado de la puerta OR de EBPMN. M.I.Capel Tema 2 116/146
  • 125. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Formalización de extensiones temporales de EBPMN En muchos modelos, no cumplir con las restricciones temporales o respetar el acceso a recursos puede ocasionar la violación de las reglas de proceso de negocio La definición de delays asociados a los eventos BPMN 2.0 intermedios (timers) no es suficiente para definir restricciones precisas es las especificaciones de los procesos de negocio Nuevas entidades de análisis han de ser incluidas en BPMN de tal manera que puedan cumplirse las restriciones temporales y de acceso a recursos Y han de tener asociados operadores cuantificables para expresar intervalos de activación, plazos de tiempo (deadlines), etc. M.I.Capel Tema 2 117/146
  • 126. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Evento de comienzo, tiempo máximo y mínimo de una actividad Elegimos una extesión de BPMN que incluye una duración máxima y míinima para cada actividad de BPMN: Figure: Anotaciones temporales de la entidad “actividad" de EBMPN M.I.Capel Tema 2 118/146
  • 127. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Tareas de servicios El envio/recepción de mensajes debe ser llevado a cabo dentro de los límites de tiempo de las actividades que envían o reciben Estas actividades no pueden entrar en un estado de inter–bloqueo (deadlock state) M.I.Capel Tema 2 119/146
  • 128. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Tareas de servicios II M.I.Capel Tema 2 120/146
  • 129. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Interpretación Semántica La comunicación debe tener lugar dentro de los intervalos definidos por las condiciones: s( m1), s( m2) ∈ [max{vS1, vS2}, min{vS1 + S1.ran.min, vS2 + S2.ran.min}] M.I.Capel Tema 2 121/146
  • 130. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Conceptos generales sobre SOA Servicios proporcionados por la arquitectura Tecnologías para implantar un SOA Tecnologías para implantar un SOA Ciclo de Vida Business Process Modeling Especificación GRáfica de Procesos de Negocio Formalization de las extensiones temporales de EBPMN Representación en EBPMN de un CRM M.I.Capel Tema 2 122/146
  • 131. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Descripción de una AS ISO/IEC/IEEE 42010 Guiar en la construcción y mantenimiento del sistema Ayudar a planear los costes y evolución del sistema Servir como un medio para el análisis, evaluación o comparación de arquitecturas software Facilitar la comunicación entre las partes interesadas en las arquitecturas y los sistemas Documentar el conocimiento arquitectónico más allá del ámbito de los proyectos individuales Capturar idiomas arquitectónicos reutilizables (tales como estilos arquitectónicos y patrones) M.I.Capel Tema 2 123/146
  • 132. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Descripción de una AS Ventajas para el diseño arquitectónico La descripción inicial del sistema pueda plasmarse de forma textual o gráfica utilizando distintos estilos y componentes arquitectónicos Desarrollar la descripción de subsistemas en función de la información que recibe o produce Descripción del comportamiento y sus elementos asociados Proporciona una documentacuón de alto nivel de la AS y del sistema objetivo Con un ADL que proporcione facilidades para ello, puede realizarse análisis de desempeño, disponibilidad,M.I.Capel Tema 2 124/146
  • 133. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag ADL Concepto Resuelven el problema de la representación formal de una arquitectura software desde un punto de vista sintáctico y semántico [Bass et al. 1998][Clements 1996] Un ADL permite representar, analizar y especificar una AS Pueden ser descriptivo–formales o semiformales, gráficos, o ambas cosas Algunos han sido sólo definidos formalmente y otros cuentas con herramientas que los soportan M.I.Capel Tema 2 125/146
  • 134. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag ADL Actuales ACME (carnegie-Mellon), CODE, UNICON, Wrigth, RAPIDE, Darwin (Imperial College), xADL (UCI), DAOP-ADL (Universidad de Málaga) y ByADL (Universidad de L’Aquila) Características Los primeros ADLs hacían más énfasis en el modelado de componentes, conectores y configuraciones. Los ADLs actuales (ArchiMate, SysML, etc.) tienden a ser lenguajes descriptivos de un espectro mucho más amplio Se pueden utilizar lenguajes de propósito general como UML como ADLs así como para modelar procesos deM.I.Capel Tema 2 126/146
  • 135. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Requerimientos que han de satisfacer los ADLs [Bass 1998][Luckhan y Vera 1995][Shaw y Garlan 1996] Capacidad de representación de componentes y elementos de análisis arquitectónico (conectores, interfaces, etc.) Proporcionar capacidad de análisis con el soporte de herramientas software Integridad comunicacional Soporte a las tareas de creación, refinamiento y validación de una AS M.I.Capel Tema 2 127/146
  • 136. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Requerimientos que han de satisfacer los ADLs Capacidad para representar la mayoría de los patrones arquitectónicos conocidos, directa o indirectamente Capacidad de proveer vistas del sistema que expresen información arquitectónica Soportar la especificación de familias de implementaciones que satisfacen una arquitectura común Capacidad de análisis basada, o bien la capacidad para la rápida generación de prototipos M.I.Capel Tema 2 128/146
  • 137. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag An Architecture Description Interchange Language Caracteríticas del lenguaje ACME Una ontología arquitectónica que consiste en 7 elementos de diseño arquitectónico básico Una notación flexible que soporta la asociación de información no estructural utilizando sub–lenguajes definidos externamente Un mecanismo de tipos para abstraer estilos e idiomas arquitectónicos, reutilizables y de uso general Un marco de trabajo semántico abierto para razonar acerca de las descripciones arquitectónicas M.I.Capel Tema 2 129/146
  • 138. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Figure: Diagrama Cliente–Servidor Simple M.I.Capel Tema 2 130/146
  • 139. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Ontología arquitectónica ACME Elementos de ACME componentes, conectores, sistemas, puertos, roles, representaciones y rep-maps Los elementos más comunes Componentes: los elementos computacionales primarios y los almacenes de datos de un sistema Conectores: representan interacciones entre componentes Sistemas: representan las configuraciones de componentes y conectores M.I.Capel Tema 2 131/146
  • 140. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Ontología arquitectónica ACME Elementos de ACME componentes, conectores, sistemas, puertos, roles, representaciones y rep-maps Los elementos más comunes Componentes: los elementos computacionales primarios y los almacenes de datos de un sistema Conectores: representan interacciones entre componentes Sistemas: representan las configuraciones de componentes y conectores M.I.Capel Tema 2 131/146
  • 141. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Sistema Cliente-Servidor Simple en Acme 1 System simple_cs = { 2 Component c l i e n t e = { Port enviar−pe ti ci on ; } ; 3 Component servidor = { Port r e c i b i r −pe ti ci on ; } ; 4 Connector rpc = { Roles { llama , llamado } } ; 5 Attachments { 6 c l i e n t e . enviar−pe ti ci on to rpc . llama ; 7 servidor . r e c i b i r −p eti ci on to rpc . llamado ; 8 } } Puerto enviar-peticion en el componente cliente Sólo un puerto recibir-peticion en el servidor Conector con 2 roles, denominados llama y llamado La topología de este sistema se declara listando un conjunto de attachments M.I.Capel Tema 2 132/146
  • 142. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Sistema Cliente-Servidor Simple en Acme 1 System simple_cs = { 2 Component c l i e n t e = { Port enviar−pe ti ci on ; } ; 3 Component servidor = { Port r e c i b i r −pe ti ci on ; } ; 4 Connector rpc = { Roles { llama , llamado } } ; 5 Attachments { 6 c l i e n t e . enviar−pe ti ci on to rpc . llama ; 7 servidor . r e c i b i r −p eti ci on to rpc . llamado ; 8 } } Puerto enviar-peticion en el componente cliente Sólo un puerto recibir-peticion en el servidor Conector con 2 roles, denominados llama y llamado La topología de este sistema se declara listando un conjunto de attachments M.I.Capel Tema 2 132/146
  • 143. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Figure: Elementos de una descripción ACME M.I.Capel Tema 2 133/146
  • 144. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Descripción jerárquica de AS Cada componente o conector posee una descripción, de bajo nivel, más detallada Representaciones: múltiples vistas de entidades Aunque, no se pueden resolver sintácticamente Fronteras de una encapsulación Múltiples niveles de refinamiento en las descripciones Concepto de representation map (rep-map) rep-map simples: asociación entre puertos internos y puertos externos asociación entre roles internos y roles externos En otros casos los constructos rep-map pueden ser mucho más complejos M.I.Capel Tema 2 134/146
  • 145. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Figure: Representaciones y propiedades de un componente M.I.Capel Tema 2 135/146
  • 146. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Anotación de entidades Propiedades ACME Cada ADL define un conjunto de información para añadir a la información estructural de la AS: datos comunicados, protocolos de interacción, restricciones de planificación, uso de recursos . . . Cada una de las 7 entidades de ACME puede ser anotada Anotación de la estructura arquitectónica mediante listas de propiedades M.I.Capel Tema 2 136/146
  • 147. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Cómo usar las propiedades ACME El significado de las propiedades no es definido explícitamente ACME sirve como un vehículo de convencionalización de propiedades entre varios ADLs Las propiedades poseen utilidad sólo cuando una herramienta las utiliza Comportamiento por defecto de una herramienta, delimitadores de propiedades M.I.Capel Tema 2 137/146
  • 148. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Cómo usar las propiedades ACME (2) El problema de representar estructuras arquitectónicas abstractas El atributo type indica un sub–lenguaje Tipos simples: integer, string, and boolean Utilización de los indicadores: name y type M.I.Capel Tema 2 138/146
  • 149. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Propiedades del sistema Cliente–Servidor simple 1 System simple_cs = { 2 Component c l i e n t e = { 3 Port enviar−p eti ci on ; 4 Property Aesop−s t y l e : style −id = c l i e n t −server ; 5 Property UniCon−s t y l e : style −id = cs ; 6 Property source−code : external = "CODE−LIB / c l i e n t . c " ; 7 } 8 Component servidor = { 9 Port r e c i b i r −pe ti ci on ; 10 Property idempotence : boolean = true ; 11 Property max−concurrent−c l i e n t s : integer = 1; 12 source−code : external = "CODE−LIB / server . c " ; 13 } 14 // ... M.I.Capel Tema 2 139/146
  • 150. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Propiedades del sistema Cliente–Servidor simple (2) 1 . . . 2 Connector rpc = { 3 Role llama ; 4 Role llamado ; 5 Property asynchronous : boolean = true ; 6 max−roles : integer = 2; 7 protocol : Wright = " . . . " ; 8 } 9 Attachment c l i e n t e . enviar−pe ti ci on to rpc . llama ; 10 Attachment servidor . r e c i b i r −pe ti ci on to rpc . llamado ; 11 } M.I.Capel Tema 2 140/146
  • 151. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Marco de trabajo semántico y abierto de ACME ACME se enfoca a describir la estructura de una AS No proporciona ninguna semántica computacional de las arquitecturas que describe, de eso se encarga un marco de trabajo semántico y abierto para que lo usen otros ADLs Las especificaciones ACME intentan representar un predicado denominado prescripción Proporcionan una correspondencia sencilla entre los aspectos estructurales de una AS en un formalismo lógico basado en relaciones y restricciones M.I.Capel Tema 2 141/146
  • 152. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Prescripción general para el Cliente-Servidor 1 exists c l i e n t , server , rpc | 2 component ( c l i e n t ) ^ 3 component ( server ) ^ 4 connector ( rpc ) ^ 5 attached ( c l i e n t . send−request , rpc . c a l l e r ) ^ 6 attached ( server . receive−request , rpc . callee ) Falta especificar que todos los componentes han sido identificados y las variables existenciales han de referirse a diferentes entidades M.I.Capel Tema 2 142/146
  • 153. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Prescripción general para el Cliente-Servidor 1 exists c l i e n t , server , rpc | 2 component ( c l i e n t ) ^ 3 component ( server ) ^ 4 connector ( rpc ) ^ 5 attached ( c l i e n t . send−request , rpc . c a l l e r ) ^ 6 attached ( server . receive−request , rpc . callee ) Falta especificar que todos los componentes han sido identificados y las variables existenciales han de referirse a diferentes entidades M.I.Capel Tema 2 142/146
  • 154. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Prescripción más elaborada 1 exists c l i e n t , server , rpc | 2 component ( c l i e n t ) ^ 3 component ( server ) ^ 4 connector ( rpc ) ^ 5 attached ( c l i e n t . send−request , rpc . c a l l e r ) ^ 6 attached ( server . receive−request , rpc . callee ) ^ 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 : attached (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 . callee ) ) M.I.Capel Tema 2 143/146
  • 155. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Gestión de las propiedades definidas Nombres de propiedades Actúan como predicados de la Lógica: NombreP : ℘(A) → {V, F} Aesop − style(cliente) = client − server Unicon − style(cliente) = cs El predicado devuelve el valor del nombre de la propiedad para la entidad cliente M.I.Capel Tema 2 144/146
  • 156. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Gestión de las propiedades definidas (2) Interpretación de valores de las propiedades Connector rpc = { Roles {llama, llamado} Property protocol : Wright = ”...”; } Las herramientas específicas que entiendan el sublenguaje Wright pueden interpretar el valor de la especificación del protocolo anterior para descubrir una semántica propia del ADL más detallada M.I.Capel Tema 2 145/146
  • 157. Introducción Mecanismos Arquitectónicos Arquitecturas Orientadas a Componentes y Servicios Lenguajes de Defición Arquitectónica (ADLs) Caso de Estudio: An Architecture Description Interchange Languag Lenguajes de descripción de arquitecturas ADLs actuales Rapide: se basa en la noción matemática de power sets y posee estructuras de programación muy potentes. UniCon: un ADL pensado para ayudar a los diseñadores a definir AS utilizando abstracciones identificadas. Aesop: intenta dar solución al problema de la reutilización de estilos arquitectónicos. Wright: se trata de un lenguaje formal que incluye componentes con puertos, conectores con roles ... y el pegamento para ligarlos. Los estilos arquitectónicos se pueden formalizar utilizando predicados ACME: un ADL de segunda generación, que intenta hacerM.I.Capel Tema 2 146/146