Arquitecturas de Software
-
Upload
manuel-capel-tunon -
Category
Education
-
view
977 -
download
5
description
Transcript of Arquitecturas de Software
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Arquitecturas Software
M.I. Capel
ETS Ingenierías Informáticay Telecommunicación
Universidad de GranadaEmail: [email protected]
Desarrollo de SoftwareIngeniería de Software (3er curso de Grado)
M.I.Capel Tema 2 1/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Índice1 Introducción
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
2 Mecanismos Arquitectónicos3 Arquitecturas Orientadas a Componentes y Servicios
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
4 Lenguajes de Defición Arquitectónica (ADLs)Caso de Estudio: An Architecture DescriptionInterchange Language (ACME)
M.I.Capel Tema 2 2/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Índice1 Introducción
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
2 Mecanismos Arquitectónicos3 Arquitecturas Orientadas a Componentes y Servicios
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
4 Lenguajes de Defición Arquitectónica (ADLs)Caso de Estudio: An Architecture DescriptionInterchange Language (ACME)
M.I.Capel Tema 2 2/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Índice1 Introducción
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
2 Mecanismos Arquitectónicos3 Arquitecturas Orientadas a Componentes y Servicios
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
4 Lenguajes de Defición Arquitectónica (ADLs)Caso de Estudio: An Architecture DescriptionInterchange Language (ACME)
M.I.Capel Tema 2 2/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Índice1 Introducción
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
2 Mecanismos Arquitectónicos3 Arquitecturas Orientadas a Componentes y Servicios
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
4 Lenguajes de Defición Arquitectónica (ADLs)Caso de Estudio: An Architecture DescriptionInterchange Language (ACME)
M.I.Capel Tema 2 2/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Arquitectura de Software
Es una descripción de la estructura del software que se vaa implementar,los datos que son parte del sistema,las interfaces entre los componentes del sistema,y algunas veces, los algoritmos utilizados.
El diseño se obtiene iterativamente tras varias versiones.Incluye agregar formalidad y detalles durante el desarrollodel diseño, y regresar a los diseños anteriores y corregirlos.El proceso de diseño es aún un proceso adhoc
[Bass et al. 2003]La Arquitectura de Software de un programa o sistema decomputación es la estructura o estructuras del sistema, lacual comprende componentes de software, propiedadesexternas de esos componentes y la interacción entre ellos.
M.I.Capel Tema 2 3/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
El diseño arquitectónico
definiciónConsiste en una actividad inicial de la fase de diseño de unsistema software cuyo objetivo es identificar los subsistemas yestablecer un marco de trabajo para gestionar correctamente elcontrol y la comunicación de dichos subsistemas
M.I.Capel Tema 2 4/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
El proceso de diseño
El proceso de diseño incluye el desarrollo de variosmodelos con diferentes niveles de abstracciónLa retroalimentación entre estas actividades y laconsecuente repetición del trabajo es inevitable en todoproceso de diseño
Figure: Proceso de Diseño de Software
M.I.Capel Tema 2 5/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Ubicación dentro de proceso de diseño
El diseño arquitectónico representa el puente entre laespecificación de requerimientos del sistema y el diseñoEstablecer un marco de trabajo básico que proporcioneuna estructura para situar los componentes principales deun sistema y las comunicaciones que tienen lugar
M.I.Capel Tema 2 6/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Especificación de requerimientos
Existe un solapamiento entre análisis y especificación derequerimientos con el diseño arquitectónicoLa especificación no debería incluir ninguna informaciónsobre diseñoLa descomposición arquitectónica es necesaria paraestructurar y organizar la especificación de un sistemaNormalmente se utiliza un modelo arquitectónico como elpunto de partida para realizar la especificación de lossubsistemas
M.I.Capel Tema 2 7/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Motivación de la Arquitectura de Software
Existen unas necesidades fundamentales que justifican laimportancia de construir una AS y de su análisis:
Potencia la comunicación entre stakeholdersEs el punto más temprano en el cual el sistema que va aser construido puede ser analizado.Las decisiones de diseño aquí son muy importantes paraconseguir requisitos críticos del sistemaAbstracción de un sistema software: es una herramientaesencial para gestionar la complejidad de un sistemaModelo transferible a otros sistemas, especialmente aaquellos con requerimientos similares
M.I.Capel Tema 2 8/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Influencias
Un AS es el resultado de diversas influencias técnicas, delnegocio y socialesLa existencia de una determinada AS para un dominio deaplicaciones afecta a su vez a los ambientes técnicos denegocio y sociales, que realimentan la futura arquitecturaUn entendimiento temprano de las restricciones permite alos arquitectos de software gestionarlos, negociarexpectativas con las partes implicadas (stakeholders),manejar riesgos, establecer compromisos, etc.
M.I.Capel Tema 2 9/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Recomendaciones para el proceso
La arquitectura debe ser producto del equipoEl equipo debe conocer los requerimientos funcionales ylos de calidad priorizadosSe debe documentarRevisada por todas la partes implicadasAnalizada en base a medicionesDebe ser implementada incrementalmente
M.I.Capel Tema 2 10/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Recomendaciones para el producto
Una AS debe ser modularCada módulo debe tener una interfaz bien definida yencapsular toda la informaciónLos atributos de calidad se deben alcanzar usandotácticas específicas para cada atributo
ConsideraciónEl logro de dichos atributos dependerá fundamentalmente de laAS seleccionada [Bass et al.1998][SEI 2001], no sólo de laprácticas a nivel de código (lenguajes, diseño detallado,estructuras de datos y algoritmos)
M.I.Capel Tema 2 11/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Recomendaciones para el producto
Una AS debe ser modularCada módulo debe tener una interfaz bien definida yencapsular toda la informaciónLos atributos de calidad se deben alcanzar usandotácticas específicas para cada atributo
ConsideraciónEl logro de dichos atributos dependerá fundamentalmente de laAS seleccionada [Bass et al.1998][SEI 2001], no sólo de laprácticas a nivel de código (lenguajes, diseño detallado,estructuras de datos y algoritmos)
M.I.Capel Tema 2 11/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
AS y requisitos no–funcionales
El estilo arquitectónico y estructura interna escogidospuede depender de requisitos no-funcionales: rendimiento,seguridad, fiabilidad, disponibilidad y mantenibilidad
RendimientoClave: localizar las operaciones críticas dentro del menornúmero posible de subsistemas, que mantengan el mínimoacoplamiento posible
Seguridad (control acceso a la información)
Clave: utilizar una arquitectura estratificada donde loselementos más críticos se ubiquen en las capas más internas ycuyo acceso esté protegido muy rigurosamenteM.I.Capel Tema 2 12/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
AS y requisitos no–funcionales II
Seguridad (prevención de daños)
Clave: todas las operaciones sensibles han de ser ubicadas enun solo subsistema o en un número pequeño de estos paraconseguir la mayor protección
DisponibilidadClave: la arquitectura debe incluir componentes redundantes,tal que se puedan sustituir sin parar la ejecución del sistema
MantenibilidadClave: utilizar componentes pequeños y autocontenidos quepuedan ser cambiados con rapidez
M.I.Capel Tema 2 13/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
AS y requisitos no–funcionales III
Conflicto de interesesEl potenciar un atributo arquitectónico correspondiente aun requisito no–funcional puede estar en conflicto con losotros requisitosEjemplo: utilizar componentes grandes mejora elrendimiento, en general, pero perjudica la mantenibilidaddel diseñoSe puede bien llegar a una solución de compromiso outilizar distintos estilos arquitectnicos para diferentespartes del sistema
M.I.Capel Tema 2 14/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Decisiones Arquitectónicas
Cada enfoque desarrollado como parte de una descripciónarquitectónica aborda un aspecto de la ASSe consideran una variedad de alternativas entre losposibles enfoques arquitectónicos, y su descripcionesLas propias decisiones arquitectónicas pueden serconsideradas como un enfoque o vista de la arquitectura.Documentar las decisiones y las razones que las motivandichas es una manera fundamental de concebir y expresaruna arquitectura software [Babar09, Perry92].Las decisiones arquitectónicas se pueden considerarcomo los primeros elementos de la descripción de unaarquitectura software, por tanto, se han de hacer explícitasutilizando una plantilla de descripción arquitectónicaM.I.Capel Tema 2 15/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Decisiones Arquitectónicas II
Si una propiedad de un elemento arquitectónico no esvisible o no es discernible de cualquier otro elementoarquitectónico, ese elemento no es arquitectónico.La selección de un manejador de base de datos no es unadecisión arquitectónica. La razón de su existencia no esmateria (no le concierne) a las metas arquitectónicas.Las decisiones son arquitectónicas o no de acuerdo alcontexto. Si la estructura es importante para alcanzar lasmetas del sistema la estrutura es arquitectónica.
M.I.Capel Tema 2 16/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Plantilla de Descripción Arquitectónica
ResoluciónCategoríaSuposicionesRestriccionesAlternativas
ArgumentosImplicacionesDecisiones relacionadasProductos de trabajoNotas
M.I.Capel Tema 2 17/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Descripción de una Arquitectura Software
Una AS proporciona la definición del sistema objetivo entérminos de elementos computacionales y de lasinteracciones entre ellos.La arquitectura muestra la correspondencia entre losrequerimientos de sistemas y los elementos del sistemaconstruido, proveyendo así una exposición racional paralas decisiones de diseño.
M.I.Capel Tema 2 18/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Elementos notacionales de una AS
Computacionales:Son entidades tales como clientes, servidores, bases dedatos, filtros y capas de un sistema jerárquico.Son además, una parte encapsulada del sistema desoftware, donde cada uno tiene una interfaz.
Interacciones:Ocurren entre los elementos a nivel de diseño, pudiendoser tan simples como las llamadas a procedimientos ovariables de acceso, o tan complejas y semánticamentericas como los protocolos del modelo cliente-servidor, o losprotocolos de acceso a las bases de datos.
M.I.Capel Tema 2 19/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Elementos notacionales de una AS II
Relaciones:Denotan las conexiones entre los elementoscomputacionales y/o componentes.Relaciones estáticas: Se muestran en el código fuente,ellas reflejan la colocación de los componentes dentro dela arquitectura. Son fácilmente detectables a partir delcódigo fuente.Relaciones dinámicas: Tratan con las conexionestemporales y las interacciones dinámicas entre loscomponentes.No se suelen detectar inspeccionando el código fuente delsistema final
M.I.Capel Tema 2 20/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Protocolo para obtener la representación de una AS
1 definir los aspectos estructurales como una composiciónde componentes,
2 las estructuras globales de control,3 los protocolos de comunicación,4 la sincronización y acceso a los datos,5 la asignación de la funcionalidad a los elementos del
diseño,6 la composición de estos elementos,7 su distribución física,8 su escalabilidad y su desempeño
M.I.Capel Tema 2 21/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Proceso de Diseño Orientado a Objetos: un caso deestudio
Definition (Sistema de Información Meteorológica (WMS))
Un WMS se necesita para generar informes meteorológicosregularmente utilizando datos recogidos de estaciones deobservación remotas y sin personal, así como de otras fuentestales como observadores voluntarios, globos y satélites. Comorespuesta de una petición, las estaciones transmiten sus datosal computador encargado de área.El sistema del computador de área valida los datos recogidosdesde diferentes fuentes y los integra. Los datos integradosson archivados y, utilizando los datos desde este archivo y losde una base de datos de informes meteorológicos, se crea unconjunto de informes locales. Los informes se pueden imprimirpara su distribución en una impresora de informes de propósitoespecial o bien pueden ser mostrados en pantalla de acuerdocon diferentes formatos.
M.I.Capel Tema 2 22/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Pasos a seguir
1 Entender y definir los modos de uso y el contexto delsistema WMS
2 Diseñar la arquitectura de software (AS)3 Identificar los objetos principales dentro de la AS4 Desarrollar los modelos de diseño5 Especificar las interfaces de objetos
M.I.Capel Tema 2 23/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Selección de una arquitectura software
Arquitectura estratificada (por capas)Cada capa sólo necesita del procesamiento de la capainferior para operarCapas identificadas:
Recoger DatosProcesar DatosAchivar DatosMostrar Datos
M.I.Capel Tema 2 24/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Elementos notacionales: UML
Cada capa incluye a otros componentes del sistemaSe utilizan packaqes-UMLIdentificación de subsistemas
M.I.Capel Tema 2 25/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Arquitectura inicial del sistema objetivo
Figure: Arquitectura en capas del WMS
M.I.Capel Tema 2 26/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Modelos de uso y contexo del sistema
Definition (Objetivo)Desarollar una comprensión de las relaciones entre el softwareque está siendo diseñado y su entorno
El contexto del sistema es un modelo estático quedescribe a otros sistemasSe utiliza un modelo dinámico para describir cómointeractúa el sistema realmente con su entornoUtilizar diagramas de casos de usoUn caso de uso por cada interacción entre el sistema y suentornoAsociaciones entre casos de uso y descripciones segúnuna plantilla M.I.Capel Tema 2 27/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Diseño arquitectónico
Guiado por la descripción de las interacciones del sistemacon su entornoComponente Estación Meteorológica:
1 Interfaz: comunicaciones con las otras partes del sistema2 Recolección: de datos: gestionar los datos recogidos por
los instrumentos y el resumen de los datos meteorológicosantes de transmitirlos
3 Instrumentación: encapsulación de los instrumentosutilizados para recoger los datos en bruto
4 Descomponer los modelos hasta que sólo existan 7entidades de modelado como máximo en un modeloarquitectónico
M.I.Capel Tema 2 28/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Componentes de Subsistemas
Figure: Subsistemas del WMS
M.I.Capel Tema 2 29/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Arquitectura de Componentes
Figure: Arquitectura del componente Estación Meteo
M.I.Capel Tema 2 30/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Los objetos tienden a emerger durante el diseñoEl diseño tiene que ver con la identificación de las clasesIdentificación de atributos y operaciones de las clasesdesde la descripción informal del sistemaIdentificación de objetos de la estación meteorológica:
Objetos del dominio de aplicación:1 Termómetro Tierra2 Anemómetro3 Barómetro
Objetos procedentes de escenarios de casos de uso:1 EstacionMeteo2 DatosMeteo
M.I.Capel Tema 2 31/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Clases de Objetos
Figure: Objetos de Estación Meteo
M.I.Capel Tema 2 32/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Carácter pasivo/activo de los objetos
Los objetos pasivos ejecutan sus métodos por petición delsistema: cambios en la política de recogida de datos noafecta a las clases que los modelanObjetos activos incluyen su propio control, deciden cuándorealizan las lecturas de los instrumentos: perjudica lainteroperabilidad
M.I.Capel Tema 2 33/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Modelos estáticos y dinámicos
Los modelos de diseño son el puente entre los requisitosdel sistema y la implementación del sistema:
1 Modelos estáticos: clases, objetos, relaciones degeneralización, usa/usado–por, composición
2 Modelos dinámicos: diagramas de secuencia y de estados,entre otros (UML proporciona 12 modelos dinámicos dediagramas)
Modelos de subsistemas: incluyen componentes yasociacionesSecuencias: para cada modo de interacción del sistema,la secuencia de llamadas entre objetos que tienen lugarEstados: comportamiento de un solo objeto en respuestaa los mensajes que puede procesar
M.I.Capel Tema 2 34/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Descomposición de paquetes
Figure: Objetos de Estación Meteo
M.I.Capel Tema 2 35/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Modelo de secuencia de operaciones
Figure: Recogida datos: secuencia operacionesM.I.Capel Tema 2 36/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Diagrama de estados
Figure: Estación Meteo: diagrama de estadosM.I.Capel Tema 2 37/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Negocio de una Arquitectura SoftwareDescripción de una Arquitectura Software
Especificar las interfaces de objetos
Especificar las interfaces de los objetos de tal manera quelos objetos y los subsistemas se puedan diseñar enparaleloNo incluir detalles de la representación en el diseñoSólo proporcionar las operaciones de los objetosnecesarias para acceder y actualizar los datos del objetoNo tiene por qué existir una relación 1:1 entre objetos einterfacesUtilizar un lenguaje de programación (como Java) paradefinir las interfaces de los objetos
M.I.Capel Tema 2 38/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Modelos abstractos de AS
Modelo 4+1 Vistas de KrutchenEn la actualidad el desarrollo de sistemas se centra en laarquitectura software, que es especificada utilizando el modelosiguiente
M.I.Capel Tema 2 39/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Modelos abstractos de AS
Modelo 4+1 Vistas de KrutchenEn la actualidad el desarrollo de sistemas se centra en laarquitectura software, que es especificada utilizando el modelosiguiente
M.I.Capel Tema 2 39/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ciclo de Arquitecturas de Negocio (ABC)
Ciclo de retroalimentación entre una AS y un negocioSegún [Bass et al. 2003], estos y otros mecanismos deretroalimentación forman lo que se llama “ABC”En [Krutchen 2003] también se indica esta relación de laAS con el negocio: se habla de tres campos dearquitectura muy relacionados durante el desarrollo:
M.I.Capel Tema 2 40/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Estilos Arquitectónicos
Define una familia de sistemas de software en términos desu organización estructural.Representa los componentes y las relaciones entre elloscon las restricciones de su aplicación y las asociaciones yreglas de diseño para su construcciónDefine un vocabulario de componentes y tipos deconectores.
Ejemplos de Estilos ArquitectónicosPipes and filters, Tipos de datos abstractos y OO, Repositorios,Capas, Basados en Eventos, Intérpretes, etc.
M.I.Capel Tema 2 41/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Estilos II
La imposición de ciertos estilos arquitectónicos mejora odisminuye las posibilidades de satisfacción de ciertosatributos de calidad del sistema [Bosch, 2000]Cada estilo propicia atributos de calidad, y la decisión deimplementar alguno de los existentes depende de losrequerimientos de calidad del sistema.Un criterio importante del éxito de los estilos es la forma enque estos alcanzan de manera satisfactoria los objetivosde la Ingeniería de Software. [Buschmann et al.,1996]
M.I.Capel Tema 2 42/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Diferencias entre estilos y patrones arquitectónicos
Estilo Arquitectónico-Sólo describe el esqueletoestructural y general de lasaplicaciones-Son independientes del contextoal que puedan ser aplicados-Cada estilo es independiente delos otros-Expresan técnicas de diseñodesde una perspectivaindependiente de la situaciónactual de un diseño-Pueden comprenderse tambiéncomo una clasificación de lossistemas software
Patrón Arquitectónico-Varios rangos de escala, comenzandocon la definición de la estructura básicade una aplicación-Necesitan de la definición de un contextodel problema-Dependen de patrones más pequeños,con los que interactúan; o de patronesque los contengan-Expresan un problema recurrente dediseño, muy específico, presentando unasolución, desde el punto de vista delcontexto en el que se presenta-Son soluciones generales a problemascomunesM.I.Capel Tema 2 43/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Patrón Arquitectónico
Definición de Buschmann (1996)Una regla que consta de tres partes, la cual expresa unarelación entre un contexto, un problema y una solución.
1 Contexto: Es una situación de modelado de una parte delsistema en la que aparece un problema de diseño.
2 Problema: Es un conjunto de fuerzas que aparecenrepetidamente en el contexto.
3 Solución: Es una configuración que equilibra estasfuerzas.
M.I.Capel Tema 2 44/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Patrón Arquitectónico
Definición de Buschmann (1996)Una regla que consta de tres partes, la cual expresa unarelación entre un contexto, un problema y una solución.
1 Contexto: Es una situación de modelado de una parte delsistema en la que aparece un problema de diseño.
2 Problema: Es un conjunto de fuerzas que aparecenrepetidamente en el contexto.
3 Solución: Es una configuración que equilibra estasfuerzas.
M.I.Capel Tema 2 44/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Patrones II
Para Buschmann sonplantillas para arquitecturasde software concretas, queespecifican las propiedadesestructurales de unaaplicación y tienen unimpacto en la arquitecturade subsistemas.
El uso de ciertosmecanismos, como losestilos y patronesarquitectónicos, permitemejorar las característicasde calidad en el software[Bosch, 2000], bien seanéstas observables o no entiempo de ejecución [Basset al., 2003].
M.I.Capel Tema 2 45/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
El ámbito del patrón es menos general que el del estiloarquitectónicoUn patrón impone una regla a la arquitectura, describiendocómo el software gestionará algún aspecto de sufuncionalidad (p.e.: la concurrencia).Los patrones arquitectónicos tienden a abordar problemascomportamentales específicos dentro del contexto de unaarquitecturaLos patrones y los estilos arquitectónicos se puedenutilizar de forma conjunta para dar forma a la estructuracompleta de un sistema.
M.I.Capel Tema 2 46/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Diferencias según el nivel de abstracción
M.I.Capel Tema 2 47/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Patrón Interceptor
Permite a determinados servicios ser añadidos de maneratransparente a un marco de trabajo y ser disparadosautomáticamente cuando ocurren ciertos eventosContexto: Desarrollo de marcos de trabajo que puedan serextendidos de manera transparenteProblema: Los marcos de trabajo, arquitecturas software,etc. ha de poder anticiparse a las demandas de serviciosconcretos que deben ofrecer a sus usuariosIntegración dinámica de nuevos componentes sin afectar ala AS o a otros componentesSolución: Registro offline de servicios a través de unainterfaz predefinida del marco de trabajo, posteriormentese disparan estos servicios cuando ocurran determinadoseventos
M.I.Capel Tema 2 48/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Interceptor
M.I.Capel Tema 2 49/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Estructura de clases de “Interceptor"
Un FrameworkConcreto que instancia una arquitecturagenérica y extensibleLos Interceptores que son asociados con un eventoparticularInterceptoresConcretos que especializan las interfaces delinterceptor e implementan sus métodos de enlaceDespachadores para configurar y disparar interceptoresconcretosUna Aplicación que se ejecuta por encima de unframework concreto y utiliza los servicios que éste leproporciona
M.I.Capel Tema 2 50/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Implicaciones en la calidad del patrón Interceptor
Beneficios Atributo de calidad Características ISO 9126Cambiar/incluir servicios de un framework Extensibilidad, Mantenibilidadsin que sea preciso cambiarlo Flexibilidad,Dinamismo Facilita cambiosAñadir interceptores sin afectar al Acoplamiento Mantenibilidadcódigo de la aplicación Facilita cambiosObtención dinámica inform. del framework Monitorización Tolerancia a fallascon intercept. y objetos–contexto Control Uso de recursosInfraestructura de servicios estratificada con Encapsulamiento Mantenibilidadinterceptores correspondientes simétricos Facilita cambios,análisisReutilización de interceptores en Reusabilidad Mantenibilidaddiferentes aplicaciones Facilita cambios
M.I.Capel Tema 2 51/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Implicaciones en la calidad 2Inconvenientes Atributo de calidad Características ISO 9126Difícil ajuste del número de Complejidad Facilita cambiosdespachadores e interceptores Flexib., extensibilidad Facilita análisisBloqueo aplicación por Disponibilidad Mantenibilidadfallo del interceptor Modificabilidad Madurez, Tolerancia FallasDegradación rendimiento por Rendimiento Eficiencia,madurezcascadas de interceptores Bloqueo Tolerancia fallas
Insuficientes interceptores y despachadores reduce la flexibilidad yextensibilidad del framework concreto.
Sistema demasiado grande e ineficiente, complejo de aprender, implementar,usar, y optimizar, utilizando demasiados interceptores
Para evitar el bloqueo completo de la aplicación pueden utilizarse estrategias detime-out, pero esto puede complicar el diseño del framework concreto
Las cascadas de intercepción pueden conllevar una degradación delrendimiento o un bloqueo de la aplicación
M.I.Capel Tema 2 52/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Resumen características de calidad
Característica Sub-característica Impacto Atributo
Mantenibilidad
Facilidad de cambio Facilidad de análisis
+ Reusabilidad Modificabilidad Encapsulamiento Extensibilidad Flexibilidad Acoplamiento Dinamismo
Facilidad de cambio Facilidad de análisis
- Extensibilidad Flexibilidad Complejidad Modificabilidad
Eficiencia Tiempo de respuesta - Desempeño
Uso de recursos + Monitoreo Control
Fiabilidad Tolerancia a fallas
- Disponibilidad Bloqueo
+ Monitoreo Control
Madurez - Disponibilidad Bloqueo M.I.Capel Tema 2 53/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Resumen características de calidad
Figure: Características ISO del patrón “Interceptor"
M.I.Capel Tema 2 54/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Patrón Broker
Para modelar sistemas distribuidos compuesto decomponentes software totalmente desacopladosContexto: cualquier sistema distribuido y, posiblemente,heterogéneo con componentes cooperando dentro de unsistema de informaciónProblema:¿Cómo estructurar componentes configurablesdinámicamente e independientes de los mecanismosconcretos de comunicación de un sistema distribuido?Solución: Introducir un componente Broker para mejordesacoplamiento entre clientes y servidoresLas tareas de los Brokers incluyen la localización delservidor apropiado, envío de la petición al servidor ytransmisión de los resultadosM.I.Capel Tema 2 55/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Broker
M.I.Capel Tema 2 56/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Estructura de clases del patrón Broker
Intermediario: admite las solicitudes, asigna los servidoresy responde a las peticiones de los clientesServidor: se registra en el Intermediario e implementa elservicioCliente: accede a los servicios remotosProxy Cliente y Proxy Servidor, que proporcionantransparencia, ocultando los detalles de implementacióndel patrónPuente: le proporciona interoperabilidad al Intermediario
M.I.Capel Tema 2 57/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Implicaciones en la calidad del patrón BrokerBeneficios Atributos de calidad Característica ISO 9126Separación código de comunicaciones. Acoplamiento Facilita cambios
Modificabilidad Fac.análisis,pruebasIndependencia de la plataforma de Escalabilidad Facilita cambiosejecución para la aplicación Uso de recursosMejor descomposición del Interoperabilidad Interoperabilidadespacio del problema Simplicidad Facilita análisisIndependencia de la implementación Modificabilidad Mantenibilidadconcreta de cada capa Flexibilidad Fac.cambiosInteracciones basadas en el Transparencia Funcionalidadparadigma de objetos InteroperabilidadArquitectura software Dinamismo Facilita cambiosmuy flexible Facilita análisisReducción complejidad de Modificabilidad Facilita cambiosprogramación distribuida Flexibilidad Facilita análisisIntegración de tecnologías Reusabilidad Facilita cambios
Facilita análisisDistribución del modelo de Interoperabilidad Portabilidadobjetos AdaptabilidadM.I.Capel Tema 2 58/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Implicaciones en la calidad 2
Inconvenientes Atributos de calidad Características ISO 9126Empeora el rendimiento de la Rendimiento Eficienciaaplicación Tiempo respuestaImpide la verticalidad Optimización Facilidad pruebasen acceso a capas internas Ocultamiento Uso recursos
Tolerancia fallas
Las capas de abstracción a las que conduce este patrón pueden perjudicar eldesempeño
Usar una capa separada del Broker puede ocultar los detalles sobre cómo laaplicación utiliza la capa más baja
Eventualmente, optimizaciones específicas del rendimiento de algunas capaspodrían resultar perjudicadas
M.I.Capel Tema 2 59/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Resumen características de calidad
Característica Sub-característica Impacto Atributo
Mantenibilidad Facilidad de cambio Facilidad de análisis
+ Flexibilidad Escalabilidad Reusabilidad Bajo acoplamiento Modificabilidad Dinamismo
Facilidad de análisis + Simplicidad
Facilidad de prueba - Ocultamiento
Eficiencia Uso de recursos + Escalabilidad
- Optimización
Tiempo de respuesta - Desempeño
Funcionalidad Interoperabilidad + Transparencia
Fiabilidad Tolerancia a fallas - Ocultamiento
Portabilidad Adaptabilidad + Multiplataforma
M.I.Capel Tema 2 60/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Resumen características de calidad
Figure: Características ISO del patrón “Broker"
M.I.Capel Tema 2 61/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Patrón Reflection
Proporciona un mecanismo para cambiar la estructura ycomportamiento de sistemas software dinámicamenteSoporta la modificación de aspectos fundamentales, talescomo estructuras y mecanismos de llamadas a funciones.Contexto: Cualquier sistema que necesita soporte pararealizar cambios propios y para conseguir persistencia desus entidadesProblema: ¿Cómo se puede modificar el comportamientode los objetos de una jerarquía dinámicamente sin afectara los propios objetos en su configuración actual?Solución: Hacer que el software sea “auto-consciente" desu función y comportamiento, haciendo que los aspectosseleccionados sean accesibles para su adaptación ycambio dinámico
M.I.Capel Tema 2 62/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Reflection
M.I.Capel Tema 2 63/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Estructura de clases del patrón Reflection
Meta Nivel: proporciona la información acerca de laspropiedades escogidas del sistema y hace que el sistemasea auto-conscienteMeta Objetos: encapsulan y representan informaciónacerca del softwareNivel Base: incluye la lógica de la aplicaciónLos cambios mantenidos en el Meta Nivel afectanconsecuentemente al comportamiento del Nivel BaseLa implementación del Meta Nivel utiliza Meta Objetospara mantenerse independiente de aquellos aspectos queson propensos a cambiar
M.I.Capel Tema 2 64/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Implicaciones en la calidad del patrón Reflection
Beneficios Atributos de calidad Características ISO 9126Comprobación correctitud desde Correctitud Funcionalidadel nivel de MetaObjetos PrecisiónEjecución de los cambios Dinamismo Facilidad cambiosdesde el nivel de MetaObjetos Facilidad análisisModificación y extensión de Modificabilidad Mantenibilidadcomponentes software facilitada Extensibilidad Facilidad cambiosCambios en el software del Modificabilidad MantenibilidadNivelBase facilitados Extensibilidad Facilidad cambiosAsume modificaciones no explícitas Extensibilidad Mantenibilidaddel código fuente Facilidad cambiosSoporte para muchos Modificabilidad Mantenibilidadtipos de cambios Facilidad cambios
M.I.Capel Tema 2 65/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Implicaciones en la calidad 2
Inconvenientes Atributos de calidad Características ISO 9126Complejidad de diseño e implementación Complejidad Facilidad análisispor los niveles y protocolo meta–objetos Facilidad pruebasDemasiados meta–objetos en Rendimiento Uso recursosla aplicación final EficienciaModificaciones en meta–nivel pueden Fallas Madurezcausar daños comportamiento del sistema Tolerancia a fallasRendimiento sistema puede ser afectado Complejidad Eficienciapor complejidad diseño del patrón Tiempo respuestaDifícil adaptación a la evolución de los Adaptabilidad Tiempo respuestaproductos generados con el patrón Eficiencia
M.I.Capel Tema 2 66/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Resumen características de calidad
Característica Sub-característica Impacto Atributo
Mantenibilidad Facilidad de cambio Facilidad de análisis
+ Modificabilidad Extensibilidad Dinamismo
Facilidad de análisis - Complejidad
Facilidad de prueba
Funcionalidad Precisión + Correctitud
Eficiencia Uso de recursos - Desempeño Complejidad
Fiabilidad Madurez - Propensión a fallas
Tolerancia a fallas
M.I.Capel Tema 2 67/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Resumen características de calidad
Figure: Características ISO del patrón “Reflection"M.I.Capel Tema 2 68/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Categorización de los Estilos Arquitectónicos
Arquitecturas centradas en los datosEl núcleo de estas arquitecturas es un repositorio o una basede datos a la que acceden las aplicaciones–clienteLas aplicaciones cliente acceden a los datos o ejecutan susprocesos de forma totalmente independiente entre ellosPropician la integrabilidad
Arquitecturas de Flujo de DatosLos datos de entrada han de ser transformados tras laactuación de componentes de la AS hasta producir los datosde salidaSus componentes se llaman filtros y encauzamientos, queoperan de una forma totalmente asíncrona entre ellosM.I.Capel Tema 2 69/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Categorización de los Estilos Arquitectónicos
Arquitecturas de Llamada–retornoArquitecturas Programa principal–subprograma: jerarquíade control donde se invocan varios componentes que, a suvez, pueden invocar a otros componentesArquitecturas Llamada a procedimiento remoto: loscomponentes se distribuyen ahora a través de múltiplescomputadores conectados por una red
Arquitecturas EstratificadasEstructuradas en capas que realizan operaciones que vanacercándose a nivel de las instrucciones–máquina:-operaciones nivel interfaz de usuario-utilidades y software de aplicación-operaciones nivel interfaz sistema operativo
M.I.Capel Tema 2 70/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Categorización de los Estilos Arquitectónicos
Arquitecturas Orientadas a ObjetoLos componentes de un sistema que sea conforme con estetipo de arquitectura encapsulan los datos y las operacionesque deben ser aplicadas para manipularlosLa comunicación y coordinación entre componentes se llevan acabo mediante paso de mensajes
M.I.Capel Tema 2 71/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Arquitecturas de referencia
ConceptosLos estilos arquitectónicos se pueden aplicar a muchosdominios de aplicacionesReutilización de la estructura arquitectónica común de losmodelos que se aplican a un mismo dominio deaplicaciones
Arquitecturas específicas de un dominio de aplicacionesModelos genéricos: abstracciones de un número desistemas con elementos comunes.Modelos de referencia: AS idealizada que incluye todaslas características que los sistemas software de esa clasehan de contener.
M.I.Capel Tema 2 72/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Arquitecturas de referencia
ConceptosLos estilos arquitectónicos se pueden aplicar a muchosdominios de aplicacionesReutilización de la estructura arquitectónica común de losmodelos que se aplican a un mismo dominio deaplicaciones
Arquitecturas específicas de un dominio de aplicacionesModelos genéricos: abstracciones de un número desistemas con elementos comunes.Modelos de referencia: AS idealizada que incluye todaslas características que los sistemas software de esa clasehan de contener.
M.I.Capel Tema 2 72/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Características de las arquitecturas de referencia
No se consideran como una guía de implementación delos sistemas softwareSe utilizan para discutir la aplicación de AS específicas deun dominio de aplicaciones y compararlasProporcionan un vocabulario de términos que aluden a lossistemas dentro de un mismo dominio de aplicacionesProporcionan una base conceptual con respecto a la cualse pueden evaluar las diferentes propuestasarquitectónicasEjemplos de arquitecturas de referencia: el modelo OSI deredes, modelo de referencia CASE
M.I.Capel Tema 2 73/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Figure: Arquitectura de referencia ECMA para entornos CASE
M.I.Capel Tema 2 74/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Ejemplo: Modelo de Referencia CASE
Tipos de servicicios del modeloRepositorio de datos: manejo de los items de datos y susrelacionesIntegración de datos: la base para conseguir la integraciónde los datosGestión de tareas: definición y representación de losmodelos de procesosMensajes: comunicaciones herramienta–herramienta,entorno–herramienta y entorno–entornoInterfaces de usuario: presentación integrada de lafuncionalidad y servicios del sistema
M.I.Capel Tema 2 75/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Concepto y Motivación
ConceptoLas arquitecturas basadas en componentes y servicios: lafuncionalidad de las aplicaciones ahora se implementa en laforma de componentes reutilizables e invocables medianteinterfaces estándar, que pueden combinarse para crearfunciones progresivamente más complejas.
MotivaciónLa dificultad de las arquitecturas tradicionales para integrarseen los procesos de negocio reside en que sus aplicaciones noestán diseñadas para ser integradas con otras
M.I.Capel Tema 2 76/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Arquitectura simple de una aplicación
Figure: Aplicación de negocios
M.I.Capel Tema 2 77/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Servicios
¿Qué es un servicio?“Representación estándar para cualquier recursocomputacional o de información que pueda ser utilizado porotras aplicaciones", Turner (2003)
“Organización global encargada de establecer y adoptar losestándares de los servicios Web", OASIS (Organization for theAdvancement of Structured Information Standards)
M.I.Capel Tema 2 78/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Características de un servicio
La provisión del servicio es independiente de la plataforma dela aplicación que lo proporciona
Capacidades externas para procesamientoAcceso consistente a través de interfacesAdaptación a políticas y restricciones predefinidas
Las aplicaciones se construyen enlazando servicios desdevarios proveedores utilizando lenguajes de programación (p.e.Java) o de instrumentación de servicios (p.e. BPEL)
M.I.Capel Tema 2 79/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Tipos de servicios
Servicios:InteracciónProcesoServicios de Aplicación de NegociosInformaciónServicios de AccesoSociosServicios de Innovación y OptimizaciónServicios de DesarrolloManejo de Servicios ITServicios de InfraestructuraM.I.Capel Tema 2 80/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Antecedentes de servicios SOA
Domain Name System (DNS)Es una parte muy importante de la configuración de un sistemadistribuido
Suele “entenderse" como un computador que proporcionainformación de un dominio de nombres a una red
Servicio de Dominio de NombresGarantiza de nombres únicos en toda la red, insensibles amayúsculas–minúsculas, que consisten en una cadena decaracteres alfanuméricos y guiones separados por puntos, queel DNS hace corresponder con números de IP y otrainformación M.I.Capel Tema 2 81/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Antecedentes de servicios SOA II
Servicios de IntermediaciónServicio de meta–información (“trading") esencial de lossistemas abiertosActúa como un mediador global entre servicios,aplicaciones y clientesPermite construir un ambiente de computación a escalamundialEvolución constante de servicios y aplicacionesIngeniería de Software para Sistemas Abiertos
M.I.Capel Tema 2 82/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Antecedentes de servicios SOA III
Servicios de EventosSirven de soporte al intercambio de mensajes asíncronoentre objetos en Sistemas DistribuídosDependen de una infraestructura basada en eventos (como JEDI)Ejemplos de servicios de eventos:
Servicios de Notificación de Eventos (SIENA)CORBA Event ServiceServicios de alerta que pueden ser construidos sobreservicios de eventos
M.I.Capel Tema 2 83/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Motivación para SOA
Proveedores de tecnología (consultores y usuarios), están deacuerdo en que el enfoque Service Oriented Architecture(SOA) permite mejorar la calidad de las aplicaciones y dar unamejor respuesta a las partes interesadas de un modelo denegocio
M.I.Capel Tema 2 84/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Modelado de Procesos de Negocios
“Proceso de Negocio" (BP)
Conjunto de servicios interactivos, estructurados yrelacionados que de manera integrada son capaces deproporcionar una funcionalidad compleja para implementar losprocesos y tareas de un negocio de acuerdo con sus reglas.
Modelado de Procesos de Negocio (BPM)
Se trata de una actividad conceptual para comprender elfuncionamiento y describir la compleja estructura de losprocesos de negocio de una empresa, de tal manera quedichos procesos puedan ser entonces analizados y mejorados.
M.I.Capel Tema 2 85/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Representación de un modelo de proceso de negocio
M.I.Capel Tema 2 86/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Caracterización de SOA
¿Qué es SOA?Una arquitectura flexible y estándar que unifica los procesos denegocio estructurando grandes aplicaciones como coleccionesde servicios.
Estas aplicaciones pueden ser usadas por usuarios dentro ofuera de la organización.
Estilo arquitectónicoSOA es también un estilo de arquitectura donde todas lasfuncionalidades, ya sean existentes o nuevas, son agrupadasen servicios que se comunican entre sí.
M.I.Capel Tema 2 87/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Tecnologías de soporte para arquitecturas distribuidas
Figure: Grado de cobertura de propiedades requeridasM.I.Capel Tema 2 88/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Requerimientos de un SOA
Interoperabilidad entre los distintos sistemas y lenguajesde programación presentes en la organizaciónUtilización de un protocolo estándarLos servicios han de ser descritos con un lenguaje claro ypreciso independiente de la plataformaMecanismo de búsqueda para obtener remotamente losservicios que ya han sido implementados
M.I.Capel Tema 2 89/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Servicios WebLos Servicios Web son servicios implementados utilizandoestándares como SOAP, WSDL y UDDI para ser accedidos através de una red, preferiblemente Internet y ejecutadosremotamente
Protocolo estándarService Oriented Architecture Protocol (SOAP)
Lenguaje de descripción de servicios
Web Service Description Language (WSDL)
Descubrimiento de servicios disponiblesUniversal Description Discovery and Integration (UDDI)M.I.Capel Tema 2 90/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Principios de Diseño de SOA
Reglas para desarrollar, mantener y usar servicios
Encapsulado (en servicios SOA): Para los servicios que noestén diseñados para ser parte de SOAAcoplamiento Ligero: Independencia entre servicios, sólose “conocen"Contratos: Los servicios deben cumplir con unas reglas decomunicación preestablecidos en documentosAbstracción: La lógica interna de los servicios no tiene queser conocida por el ambiente en el que se van a ejecutar
M.I.Capel Tema 2 91/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Principios de Diseño de SOA II
Reglas para desarrollar, mantener y usar servicios
Reutilización: Los servicios deben ser diseñados siemprepara su reutilización por varias aplicaciones remotasComposición: Colecciones de servicios han de poder sercompuestos para formar otros serviciosAutonomía: Los servicios son los únicos que controlan sulógica internaOptimización: Deben ser lo más eficientes posibleDescubrimiento: Los servicios son diseñados para facilitarsu descubrimiento en el ambiente en que se ejecutan
M.I.Capel Tema 2 92/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Tecnologías
XMLUn lenguaje de marcas. XML se basa en la combinación detexto con información que describe ese texto. En XML seutilizan las etiquetas (tags) para describir bloques de texto. Fuediseñado para compartir fácilmente las estructuras de datos através de la red.
SOAPSimple Object Access Protocol es un protocolo estándar bajoel auspicio de la W3C que define cómo dos objetos endiferentes procesos pueden comunicarse por medio deintercambio de datos XML
M.I.Capel Tema 2 93/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Tecnologías
WSDLWeb Service Description Language es un lenguaje basado enXML utilizado para describir los Servicios Web. Este lenguajedefine a los servicios como colecciones de puertos, dondecada puerto indica una función del servicio que está siendodescrito. Así, cualquier usuario de un servicio puede leer elWSDL y saber qué funciones se pueden llamar utilizandoSOAP.
UDDIUniversal Description, Discovery and Integration es un registrobasado en XML para listar servicios en Internet. Está diseñadopara ser interrogado con mensajes SOAP y proveer acceso alos WSDL de los servicios que se encuentran listados.
M.I.Capel Tema 2 94/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Tecnologías
BPELBusiness Process Execution Language es un lenguajeejecutable de procesamiento de negocios basado en XML.BPEL nació como la combinación de WSFL (IBM) y XLANG(Microsoft) para crear un estándar mundial de ejecución deprocesos de negocio. Este lenguaje se utiliza para orquestar laejecución de un proceso, llamando a los servicios que vanecesitando.
M.I.Capel Tema 2 95/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Implementación de WS
Figure: Implementación de una arquitectura para Web–Services
M.I.Capel Tema 2 96/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Bus de Servicios de Empresa
ESBEnterprise Service Bus es el punto de comunicación entretodos los servicios. Funciona de forma transparente. No debecontener lógica del negocio.
M.I.Capel Tema 2 97/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Arquitectura SOA modelo
M.I.Capel Tema 2 98/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Ciclo de vida de un SOA
Modelado del negocio.Diseño de un sistema de informaciónImplementación del sistema de informaciónEvaluación del sistema para refinarlo y volver a modelar
M.I.Capel Tema 2 99/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Ciclo de vida de un SOA
ModeladoCapturar el diseño del negocio (de requerimientos yobjetivos)Traducir a procesos de negocio y metasSe recomienda elaborar distintos escenarios que permitanobtener más información sobre los procesos de negocioDefinir los Key Performance Indicators (KEI)
M.I.Capel Tema 2 100/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Ciclo de vida de un SOA
DesarrolloConvertir el diseño de negocio en definiciones deprocesos y actividadesTransformarlos a los servicios de la arquitecturaEstudiar aplicaciones ya existentes y reutilizar(asegurando estándares SOA)Implementar los servicios que faltan
M.I.Capel Tema 2 101/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Ciclo de vida de un SOA
Despliegue
Crear un ambiente en el que se ejecuten las aplicacionesResolver dependenciasCondiciones operacionales, requisitos de capacidad yrestricciones de integridad y acceso
M.I.Capel Tema 2 102/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Ciclo de vida de un SOA
GestiónDeterminar la manera de mantener el ambienteoperacional y las políticas de implementaciónMonitorizar la efectividad de las solicitudes de servicio y eltiempo de respuestaMantener registros de fallos y recuperar tareasMonitorización de las métricas de negocio (KPI) que sedefinieron en el diseño
M.I.Capel Tema 2 103/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Ciclo de vida de un SOA
GobernabilidadDefinir los derechos de decisión para el desarrollo,despliegue y manejo de nuevos serviciosSupervisar que se cumplen las políticas, estándares,proceso y procedimientosAyuda a identificar qué proyectos contribuyenprincipalmente a conseguir las metas de negocioDefinir los roles y las responsabilidades de cada miembrodel equipo de forma clara
M.I.Capel Tema 2 104/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre arquitecturas orientadas a serviciosServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de Vida
Microsoft Service Management
M.I.Capel Tema 2 48/56
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre arquitecturas orientadas a serviciosServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de Vida
Enfoque de SUN
M.I.Capel Tema 2 49/56
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre arquitecturas orientadas a serviciosServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de Vida
Ejemplo de arquitectura de SUN
M.I.Capel Tema 2 50/56
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Modelado de Procesos de Negocio
BPMN“Business Process Model and Notation"(BPMN) se consideraactualmente como el lenguaje de modelado de procesos denegocio estándar.
CaracterísticasBPMN utiliza una notación gráfica similar a UMLTal como éste, la semántica de BPMN no estáformalmente definidaLa ausencia de tal semántica produce un problema para lavalidación de los modelos de procesos de negocioBPMN 2.0 intenta modelar los procesos con restriccionestemporales
M.I.Capel Tema 2 108/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Modelado de Procesos de Negocio
BPMN“Business Process Model and Notation"(BPMN) se consideraactualmente como el lenguaje de modelado de procesos denegocio estándar.
CaracterísticasBPMN utiliza una notación gráfica similar a UMLTal como éste, la semántica de BPMN no estáformalmente definidaLa ausencia de tal semántica produce un problema para lavalidación de los modelos de procesos de negocioBPMN 2.0 intenta modelar los procesos con restriccionestemporales
M.I.Capel Tema 2 108/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
La notación BPMN
Figure: Representación gráfica de los elementos de BPMN
M.I.Capel Tema 2 109/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Ejemplo de especificación con BMPN
Figure: Proceso logístico de una farmacia de hospital
M.I.Capel Tema 2 110/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Un tipo especial de diagrama de flujo: BusinessProcess Diagram (BPD)
GatewaysEventsActivitiesFlows
Figure: Ejemplo de un BPD
M.I.Capel Tema 2 111/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Representación gráfica de un estado en BPMN
Type
in
out
error
send
/rec
eive
exit_1exit_2exit_3
links & dependences
Type
N
Figure: Modelo “black–box" de la entidad BPMN “state".M.I.Capel Tema 2 112/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Representación con BPD de las entidades BMPN
Figure: Representación gráfica de los elementos de BPMNExtendido.
M.I.Capel Tema 2 113/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Notación de modelado de BPMN extendido
EBPMN necesita de la precisión semántica que leproporciona un lenguaje formal a sus elementos básicospara transformar sus procesos de negocio en modelosejecutables
Al siguiente conjunto de constructos EBPMN se le puedeproporcionar una interpretación semántica:
Parallel Fork GatewayParallel Join GatewayData–based OR gatewaysEvent–based OR gatewaysOR–join gateways
M.I.Capel Tema 2 114/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Parallel Fork Gateway
Se necesita una rama del P(i) por cada flujo de controlsaliente representado en estado de la puerta:
Figure: Modelo “black–box" de la puerta paralela de EBPMN.
M.I.Capel Tema 2 115/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Data–based OR Gateway
Se utilizan puertas inclusivas para la selección de unconjunto de ramas de salida entre todos los flujos:
Figure: Modelo “black–box" del estado de la puerta OR de EBPMN.
M.I.Capel Tema 2 116/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Formalización de extensiones temporales de EBPMN
En muchos modelos, no cumplir con las restriccionestemporales o respetar el acceso a recursos puedeocasionar la violación de las reglas de proceso de negocioLa definición de delays asociados a los eventos BPMN 2.0intermedios (timers) no es suficiente para definirrestricciones precisas es las especificaciones de losprocesos de negocioNuevas entidades de análisis han de ser incluidas enBPMN de tal manera que puedan cumplirse lasrestriciones temporales y de acceso a recursosY han de tener asociados operadores cuantificables paraexpresar intervalos de activación, plazos de tiempo(deadlines), etc. M.I.Capel Tema 2 117/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Evento de comienzo, tiempo máximo y mínimo de unaactividad
Elegimos una extesión de BPMN que incluye una duraciónmáxima y míinima para cada actividad de BPMN:
Figure: Anotaciones temporales de la entidad “actividad" de EBMPN
M.I.Capel Tema 2 118/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Tareas de servicios
El envio/recepción de mensajes debe ser llevado a cabodentro de los límites de tiempo de las actividades queenvían o recibenEstas actividades no pueden entrar en un estado deinter–bloqueo (deadlock state)
M.I.Capel Tema 2 119/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Tareas de servicios II
Figure: Flujo de mensajes de tareas de servicio en EBMPN
M.I.Capel Tema 2 120/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Interpretación Semántica
La comunicación debe tener lugar dentro de los intervalosdefinidos por las condiciones:
s(εm1), s(εm2) ∈[max{vS1, vS2},min{vS1 + S1.ran.min, vS2 + S2.ran.min}]
M.I.Capel Tema 2 121/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Conceptos generales sobre SOAServicios proporcionados por la arquitecturaTecnologías para implantar un SOATecnologías para implantar un SOACiclo de VidaBusiness Process ModelingEspecificación GRáfica de Procesos de NegocioFormalization de las extensiones temporales de EBPMN
Representación en EBPMN de un CRM
M.I.Capel Tema 2 122/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Descripción de una AS
ISO/IEC/IEEE 42010Guiar en la construcción y mantenimiento del sistemaAyudar a planear los costes y evolución del sistemaServir como un medio para el análisis, evaluación ocomparación de arquitecturas softwareFacilitar la comunicación entre las partes interesadas enlas arquitecturas y los sistemasDocumentar el conocimiento arquitectónico más allá delámbito de los proyectos individualesCapturar idiomas arquitectónicos reutilizables (tales comoestilos arquitectónicos y patrones)
M.I.Capel Tema 2 123/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Descripción de una AS
Ventajas para el diseño arquitectónicoLa descripción inicial del sistema pueda plasmarse deforma textual o gráfica utilizando distintos estilos ycomponentes arquitectónicosDesarrollar la descripción de subsistemas en función de lainformación que recibe o produceDescripción del comportamiento y sus elementosasociadosProporciona una documentacuón de alto nivel de la AS ydel sistema objetivoCon un ADL que proporcione facilidades para ello, puederealizarse análisis de desempeño, disponibilidad,seguridad del sistema
M.I.Capel Tema 2 124/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
ADL
ConceptoResuelven el problema de la representación formal de unaarquitectura software desde un punto de vista sintáctico ysemántico [Bass et al. 1998][Clements 1996]Un ADL permite representar, analizar y especificar una ASPueden ser descriptivo–formales o semiformales, gráficos,o ambas cosasAlgunos han sido sólo definidos formalmente y otroscuentas con herramientas que los soportan
M.I.Capel Tema 2 125/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
ADL
ActualesACME (carnegie-Mellon), CODE, UNICON, Wrigth, RAPIDE,Darwin (Imperial College), xADL (UCI), DAOP-ADL(Universidad de Málaga) y ByADL (Universidad de L’Aquila)
CaracterísticasLos primeros ADLs hacían más énfasis en el modelado decomponentes, conectores y configuraciones.Los ADLs actuales (ArchiMate, SysML, etc.) tienden a serlenguajes descriptivos de un espectro mucho más amplioSe pueden utilizar lenguajes de propósito general comoUML como ADLs así como para modelar procesos denegocio y similares.
M.I.Capel Tema 2 126/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Requerimientos que han de satisfacer los ADLs
[Bass 1998][Luckhan y Vera 1995][Shaw y Garlan 1996]Capacidad de representación de componentes yelementos de análisis arquitectónico (conectores,interfaces, etc.)Proporcionar capacidad de análisis con el soporte deherramientas softwareIntegridad comunicacionalSoporte a las tareas de creación, refinamiento y validaciónde una AS
M.I.Capel Tema 2 127/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Requerimientos que han de satisfacer los ADLs
Capacidad para representar la mayoría de los patronesarquitectónicos conocidos, directa o indirectamenteCapacidad de proveer vistas del sistema que expreseninformación arquitectónicaSoportar la especificación de familias deimplementaciones que satisfacen una arquitectura comúnCapacidad de análisis basada, o bien la capacidad para larápida generación de prototipos
M.I.Capel Tema 2 128/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
An Architecture Description Interchange Language
Caracteríticas del lenguaje ACME
Una ontología arquitectónica que consiste en 7 elementosde diseño arquitectónico básicoUna notación flexible que soporta la asociación deinformación no estructural utilizando sub–lenguajesdefinidos externamenteUn mecanismo de tipos para abstraer estilos e idiomasarquitectónicos, reutilizables y de uso generalUn marco de trabajo semántico abierto para razonaracerca de las descripciones arquitectónicas
M.I.Capel Tema 2 129/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Figure: Diagrama Cliente–Servidor Simple
M.I.Capel Tema 2 130/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Ontología arquitectónica ACME
Elementos de ACMEcomponentes, conectores, sistemas, puertos, roles,representaciones y rep-maps
Los elementos más comunesComponentes: los elementos computacionales primarios ylos almacenes de datos de un sistemaConectores: representan interacciones entre componentesSistemas: representan las configuraciones decomponentes y conectores
M.I.Capel Tema 2 131/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Ontología arquitectónica ACME
Elementos de ACMEcomponentes, conectores, sistemas, puertos, roles,representaciones y rep-maps
Los elementos más comunesComponentes: los elementos computacionales primarios ylos almacenes de datos de un sistemaConectores: representan interacciones entre componentesSistemas: representan las configuraciones decomponentes y conectores
M.I.Capel Tema 2 131/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Sistema Cliente-Servidor Simple en Acme1 System simple_cs = {2 Component c l i e n t e = { Por t env iar−p e t i c i o n ; } ;3 Component se rv i do r = { Por t r e c i b i r −p e t i c i o n ; } ;4 Connector rpc = { Roles { l lama , l lamado } } ;5 Attachments {6 c l i e n t e . env iar−p e t i c i o n to rpc . l lama ;7 se rv i do r . r e c i b i r −p e t i c i o n to rpc . l lamado ;8 } }
Puerto enviar-peticion en el componente clienteSólo un puerto recibir-peticion en el servidorConector con 2 roles, denominados llama y llamadoLa topología de este sistema se declara listando unconjunto de attachments
M.I.Capel Tema 2 132/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Sistema Cliente-Servidor Simple en Acme1 System simple_cs = {2 Component c l i e n t e = { Por t env iar−p e t i c i o n ; } ;3 Component se rv i do r = { Por t r e c i b i r −p e t i c i o n ; } ;4 Connector rpc = { Roles { l lama , l lamado } } ;5 Attachments {6 c l i e n t e . env iar−p e t i c i o n to rpc . l lama ;7 se rv i do r . r e c i b i r −p e t i c i o n to rpc . l lamado ;8 } }
Puerto enviar-peticion en el componente clienteSólo un puerto recibir-peticion en el servidorConector con 2 roles, denominados llama y llamadoLa topología de este sistema se declara listando unconjunto de attachments
M.I.Capel Tema 2 132/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Figure: Elementos de una descripción ACME
M.I.Capel Tema 2 133/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Descripción jerárquica de AS
Cada componente o conector posee una descripción, debajo nivel, más detalladaRepresentaciones: múltiples vistas de entidadesAunque, no se pueden resolver sintácticamenteFronteras de una encapsulaciónMúltiples niveles de refinamiento en las descripcionesConcepto de representation map (rep-map)rep-map simples:
asociación entre puertos internos y puertos externosasociación entre roles internos y roles externosEn otros casos los constructos rep-map pueden ser muchomás complejos M.I.Capel Tema 2 134/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Figure: Representaciones y propiedades de un componente
M.I.Capel Tema 2 135/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Anotación de entidades
Propiedades ACMECada ADL define un conjunto de información para añadir ala información estructural de la AS: datos comunicados,protocolos de interacción, restricciones de planificación,uso de recursos . . .Cada una de las 7 entidades de ACME puede ser anotadaAnotación de la estructura arquitectónica mediantelistas de propiedades
M.I.Capel Tema 2 136/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Cómo usar las propiedades ACME
El significado de las propiedades no es definidoexplícitamenteACME sirve como un vehículo de convencionalización depropiedades entre varios ADLsLas propiedades poseen utilidad sólo cuando unaherramienta las utilizaComportamiento por defecto de una herramienta,delimitadores de propiedades
M.I.Capel Tema 2 137/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Cómo usar las propiedades ACME (2)
El problema de representar estructuras arquitectónicasabstractasEl atributo type indica un sub–lenguajeTipos simples: integer, string, and booleanUtilización de los indicadores: name y type
M.I.Capel Tema 2 138/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Propiedades del sistema Cliente–Servidor simple
1 System simple_cs = {2 Component c l i e n t e = {3 Por t enviar−p e t i c i o n ;4 Proper ty Aesop−s t y l e : s t y l e−i d = c l i e n t −server ;5 Proper ty UniCon−s t y l e : s t y l e−i d = cs ;6 Proper ty source−code : ex te rna l = "CODE−LIB / c l i e n t . c " ;7 }8 Component se rv i do r = {9 Por t r e c i b i r −p e t i c i o n ;
10 Proper ty idempotence : boolean = true ;11 Proper ty max−concurrent−c l i e n t s : i n t e g e r = 1 ;12 source−code : ex te rna l = "CODE−LIB / server . c " ;13 }14 // ...
M.I.Capel Tema 2 139/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Propiedades del sistema Cliente–Servidor simple (2)
1 \ \ . . .2 Connector rpc = {3 Role l lama ;4 Role l lamado ;5 Proper ty asynchronous : boolean = true ;6 max−r o l es : i n t e g e r = 2 ;7 p ro toco l : Wright = " . . . " ;8 }9 Attachment c l i e n t e . env iar−p e t i c i o n to rpc . l lama ;
10 Attachment se rv i do r . r e c i b i r −p e t i c i o n to rpc . l lamado ;11 }
M.I.Capel Tema 2 140/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Marco de trabajo semántico y abierto de ACME
ACME se enfoca a describir la estructura de una ASNo proporciona ninguna semántica computacional de lasarquitecturas que describe, de eso se encarga un marcode trabajo semántico y abierto para que lo usen otrosADLsLas especificaciones ACME intentan representar unpredicado denominado prescripciónProporcionan una correspondencia sencilla entre losaspectos estructurales de una AS en un formalismo lógicobasado en relaciones y restricciones
M.I.Capel Tema 2 141/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Prescripción general para el Cliente-Servidor
1 e x i s t s c l i e n t , server , rpc |2 component ( c l i e n t ) ^3 component ( server ) ^4 connector ( rpc ) ^5 at tached ( c l i e n t . send−request , rpc . c a l l e r ) ^6 at tached ( server . receive−request , rpc . c a l l e e )
Falta especificar que todos los componentes han sidoidentificadosy las variables existenciales han de referirse a diferentesentidades
M.I.Capel Tema 2 142/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Prescripción general para el Cliente-Servidor
1 e x i s t s c l i e n t , server , rpc |2 component ( c l i e n t ) ^3 component ( server ) ^4 connector ( rpc ) ^5 at tached ( c l i e n t . send−request , rpc . c a l l e r ) ^6 at tached ( server . receive−request , rpc . c a l l e e )
Falta especificar que todos los componentes han sidoidentificadosy las variables existenciales han de referirse a diferentesentidades
M.I.Capel Tema 2 142/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Prescripción más elaborada
1 e x i s t s c l i e n t , server , rpc |2 component ( c l i e n t ) ^3 component ( server ) ^4 connector ( rpc ) ^5 at tached ( c l i e n t . send−request , rpc . c a l l e r ) ^6 at tached ( server . receive−request , rpc . c a l l e e ) ^7 c l i e n t != server ^8 server != rpc ^9 c l i e n t != rpc ^
10 ( for a l l y : component ( y ) =>11 y = c l i e n t | y = server ) ^12 ( for a l l y : connector ( y ) => y = rpc ) ^13 ( for a l l p , q : at tached ( p , q ) =>14 ( p= c l i e n t . send−request ^ q=rpc . c a l l e r )15 | ( p=server . receive−request ^ q=rpc . c a l l e e ) )
M.I.Capel Tema 2 143/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Gestión de las propiedades definidas
Nombres de propiedadesActúan como predicados de la Lógica:
NombreP : ℘(A) → {V , F}
Aesop − style(cliente) = client − serverUnicon − style(cliente) = cs
El predicado devuelve el valor del nombre de la propiedad parala entidad cliente
M.I.Capel Tema 2 144/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Gestión de las propiedades definidas (2)
Interpretación de valores de las propiedades
Connector rpc = {Roles {llama, llamado}
Property protocol : Wright = ”...”; }
Las herramientas específicas que entiendan el sublenguajeWright pueden interpretar el valor de la especificación delprotocolo anterior para descubrir una semántica propia del ADLmás detallada
M.I.Capel Tema 2 145/146
IntroducciónMecanismos Arquitectónicos
Arquitecturas Orientadas a Componentes y ServiciosLenguajes de Defición Arquitectónica (ADLs)
Caso de Estudio: An Architecture Description Interchange Language (ACME)
Lenguajes de descripción de arquitecturas
ADLs actualesRapide: se basa en la noción matemática de power sets yposee estructuras de programación muy potentes.UniCon: un ADL pensado para ayudar a los diseñadores adefinir AS utilizando abstracciones identificadas.Aesop: intenta dar solución al problema de la reutilizaciónde estilos arquitectónicos.Wright: se trata de un lenguaje formal que incluyecomponentes con puertos, conectores con roles ... y elpegamento para ligarlos. Los estilos arquitectónicos sepueden formalizar utilizando predicadosACME: un ADL de segunda generación, que intenta hacercooperar a los ADLs.UML: como ADL incluye muchos elementos de modeladoarquitectónico pero le falta una definición formal.
M.I.Capel Tema 2 146/146