ARQUITECTURA DE SOFTWARE. Prof. Dinarle Ortega

1

ARQUITECTURA DE SOFTWARE

Prof. Dinarle Ortega

2

Introducción

Definiciones básicas

Patrones

Estilos Arquitectónicos

Evaluación Arquitectónica

Arquitectura Empresarial

Conclusiones

Referencias bibliográficas

Contenido

3

Una disciplina de Ingeniería de Software efectiva (Wasserman, 1996):

Abstracción: descripción del problema a un nivel de generalización donde nos permite concentrarnos en aspectos claves y no en los detalles

Métodos y Notaciones de Análisis y Diseño: permiten construir modelos y chequear su completitud y consistencia, garantizando la reutilización y un mejor entendimiento entre los involucrados

Prototipo de Interfaces: es una técnica que permite clarificar aspectos de la interfaz que no estén totalmente precisos

Arquitectura del Software: es una disciplina cuyos efectos se pueden sentir a todo lo largo del proceso de desarrollo del software

Proceso del software: diferentes sistemas de software necesitan diferentes procesos de desarrollo

Reutilización: Durante el desarrollo y mantenimiento del software, se puede hacer reutilización de los elementos comunes

Métricas: permiten caracterizar de una manera más precisa nuestros procesos y productos

Herramientas y Ambientes Integrados: permiten mejorar nuestro proceso de desarrollo del software

Introducción

4

 Tres temas de Ingeniería de Software – Patrones

• Patrones de Diseño (GoF) - 1995

– Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides

• Patrones Arquitectónicos - 1996

– Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad y Michael Stal

– Métodos de Desarrollo de Software (2001)

• eXtreme Programming (XP), RUP, Crystal

– Arquitectura de Software (1992)

Introducción

5

Introducción

La arquitectura del software responde a los requisitos del sistema a desarrollar (evaluación arquitectónica)

Requisitos del sistema

Arquitectura de Software Análisis/Diseño

6

Definiciones Básicas

 Arquitectura de Software

 Manifiestos de Dewayne Perry (AT&T Bell

Laboratories de New Jersey), Alexander Wolf

(Universidad de Colorado) 1992 fundadores de la disciplina de Arquitectura de Software

– “Foundations for the study of software architecture”

– “La década de 1990, creemos, será la década de la arquitectura de software…”.

 La definen como un conjunto de elementos arquitectónicos que tienen una forma particular, distinguiendo entre

– elementos de procesamiento, elementos de datos y elementos conectores

7

Definiciones Básicas

 Arquitectura de Software

 Universidad de Carnegie Mellon: David Garlan, Mary Shaw, Paul Clements, Robert Allen. Otros

investigadores Rick Kazman, Mark Klein, Len Bass y otros autores en el contexto del SEI (Sofware

Engineering Institute)

 Arquitectura - IEEE 1471-2000 (ISO/IEC 42010:2007) :

– La Arquitectura de Software es la organización fundamental de un sistema encarnada en sus componentes, las

relaciones entre ellos y el ambiente y los principios que

orientan su diseño y evolución

8

Definiciones Básicas

 Arquitectura de Software

 Es el conjunto de decisiones de diseño las cuales si no se toman adecuadamente, pueden causar que el proyecto falle" (Eoin Woods, arquitecto de

software, co-autor de Software Systems Architecture : Working With Stakeholders Using Viewpoints and Perspectives, 2005

 Es la descripción de las estructuras del sistema (descomposición de módulos, procesos, capas, entre otros) es el primer artefacto que puede ser analizado para determinar como se logran los

atributos de calidad. Es una abstracción reutilizable

en otros sistemas

9

 Arquitectura de Software

 David Garlan y Dewayne Perry, (IEEE Transactions on Software Engineering, abril 1995 ) delinean las áreas de investigación de la Arquitectura de Software:

– la caracterización de la arquitectura a través de un lenguaje de descripción arquitectónico

– Fundamentos formales de la AS (bases matemáticas, caracterizaciones

formales de propiedades extra-funcionales tales como mantenibilidad, teorías de la interconexión, etcétera).

– Métodos de desarrollo basados en arquitectura

– Recuperación y reutilización de arquitectura: la codificación de la experiencia en arquitectura a través de la catalogación de principios y patrones. Se puede identificar sistemas de software que poseen arquitecturas con características similares: estilos arquitectónicos, patrones arquitectónicos, patrones de diseño – Codificación y guía arquitectónica: el desarrollo de frameworks de dominio

específico: robótica, interfaces de usuario, etc. los cuales permitan instanciarlo y generar nuevos productos rápidamente y de alta calidad

– Herramientas y ambientes de diseño arquitectónico

– Evaluación arquitectónica (se concentra en requisitos no funcionales)

Definiciones Básicas

10

 Arquitectura de Software

– Mary Shaw (Shaw, 2001) considera que los campos más promisorios de la AS:

• Estilos, el desarrollo de lenguajes de descripción arquitectónica, la formulación de metodologías y patrones de diseño

• Se requieren todavía modelos precisos que permitan razonar sobre las propiedades de una arquitectura y verificar su consistencia y completitud, así como la automatización del proceso de análisis y diseño

• La AS se encuentra en su fase de desarrollo y extensión, pero tanto las ideas como las

herramientas distan de estar maduras

Definiciones Básicas

11

Importancia de la Arquitectura de Software

 Las representaciones de la arquitectura de software facilitan la

comunicación entre todas las personas involucradas en el desarrollo de un sistema

 Permite el análisis de la efectividad del diseño para lograr los requisitos establecidos (evaluación arquitectónica)

 Permite la toma de decisiones de diseños en etapas tempranas en la cual hacer cambios, es relativamente fácil

 Garantiza la reducción de los riesgos asociados a la construcción del software

 La arquitectura “constituye un modelo relativamente pequeño y fácil de manejar, de como el sistema está estructurado y como sus componentes trabajan juntos” [BAS03]

Definiciones Básicas

12

Ventajas de la arquitectura del software:

 Los modelos pueden componerse para definir sistemas más complejos (BJ 1994). Expresa diferentes vistas de un sistema

 Los elementos individuales de las descripciones arquitectónicas se definen independientemente y pueden ser reutilizados en diferentes contextos

 Permite especificar la estructura y topología del sistema a construir

 Muestra la correspondencia entre los requisitos iniciales del sistema y las características del sistema construido, proporcionando

lineamientos para las decisiones de diseño en posteriores etapas [GP 95]

 Facilita las estimaciones de costo y tiempo de producción de los sistemas con mayor exactitud [SG 96]

Definiciones Básicas

13

Ventajas de la arquitectura del software:

 Un arquitecto de software se formula preguntas: ¿ Cuáles son los subsistemas subyacentes? ¿Cómo se comunican estos

subsistemas? ¿Cuáles son los patrones que se utilizarán? o ¿Cuál es el estilo más conveniente según el dominio del problema? Estas interrogantes permiten decidir, qué tipo de proceso de desarrollo se compagina mejor con el sistema a construir

 Documenta el código de un sistema

 Facilita el mantenimiento y la evolución de un sistema

 Dan información sobre el comportamiento del sistema a un alto nivel de abstracción

Definiciones Básicas

14

Hay métodos y procesos centrados en el diseño arquitectónico, tales como RUP (Rational Unified Process) [Krut 00], Bosh [Bosh 2000] y ATAM (Attribute Tradeoff Análisis Method ) [ KKB+ 99]

Todos ellos coinciden en los siguientes principios generales:

 Comienzan en diseño arquitectónico a partir de los requisitos funcionales

 Los requisitos no funcionales son luego capturados y reflejados en el diseño arquitectónico inicial

 Las estrategias de diseño pueden estar basadas en estilos o patrones arquitectónicos o de diseño

 La arquitectura final es el producto de sucesivas transformaciones realizadas durante el proceso

 Los productos generados del diseño arquitectónico se convierten en una guía para el proceso de desarrollo [Apg 96]

Definiciones Básicas

Responsabilidades de un Arquitecto de Software

• Rational Unified Process

Arquitecto es un rol en un proyecto de desarrollo de software el cual es

responsable de:

– Liderar el proceso de arquitectura.

– Producir los artefactos necesarios:

Documento de descripción de arquitectura

– Modelos y prototipos de arquitectura.

• SUN SL-425:

El arquitecto:

 Visualiza el comportamiento del sistema.

 Crea los planos del sistema.

 Define la forma en la cual los elementos del sistema trabajan en conjunto.

 Responsable de integrar los requerimientos no-funcionales (NRFs) en el sistema.

Definiciones Básicas

El Modelo de “4+1 Vistas”

El modelo “4+1” es un modelo de vistas diseñado por Philippe Kruchten en concordancia con el estándar “IEEE 1471-2000” (Recommended Practice for Architecture Description of Software-Intensive Systems)

utilizado para describir la arquitectura de un sistema software basado en múltiples puntos de vista.

Definiciones Básicas

17 Usuario Final

Analista Diseñador

Vista Lógica

Diagrama de clases, Comunicacion y Secuencia

Programadores

Vista de Implementación

Diagrama de Componentes Diagrama de paquetes

Vista de Procesos Vista de Despliegue

Vista de Casos de Uso

Definiciones Básicas

El Modelo de “4+1 Vistas”

18

 El arquitecto Christopher Alexander en 1979, escribió el libro “The Timeless Way of Building”

 Un patrón es una abstracción de una entidad concreta que es recurrente dentro de un contexto muy específico

– Captura la información vital o aspectos claves subyacentes en el contexto del problema, de forma que pueda ser utilizada de forma sistemática, permitiendo ahorro de tiempo y recursos

– Identifica las clases y sus instancias participantes, sus roles y

colaboradores, así como la distribución de las responsabilidades, forma de aplicarlo y las consecuencias que surgen de tal aplicación (Gamma et al. 95)

– Proporciona un esqueleto del comportamiento funcional y propicia requisitos no funcionales (tales como confiabilidad, extensibilidad, reutilización, facilidad de uso, entre otros)

– Ayuda a construir sistemas de software complejos y heterogéneos

Patrones: Elementos Arquitectónicos

Reutilizables

19

 Nombre

– Define un vocabulario de diseño – Facilita abstracción

 Problema

– Describe cuando aplicar el patrón – objetivos y restricciones

– Pre-requisitos

 Solución

– Elementos estructurales (gráficos, diagramas y texto), los participantes y las colaboraciones que constituyen el diseño (template)

– Incluye los errores que se deben evitar cuando se quiere llevar a cabo una implementación concreta de la solución

– Puede incluir variantes y sus relaciones con otros patrones

 Consecuencias

– Resultados, extensiones y tradeoffs

Elementos para la descripción de un patrón

Patrones: Elementos Arquitectónicos

Reutilizables

20

Características de un patrón

Patrones: Elementos Arquitectónicos Reutilizables

Encapsulación y Abstracción

Encapsula un problema bien definido y su solución dentro de un dominio particular

• Proporcionan lineamientos propios de una entidad con

características propias, capaz de contener la información esencial para el manejo y entendimiento de las dificultades que se

pretenden solventar con él

• Contiene la experticia de los especialistas que han identificado y documentado a lo largo del tiempo las soluciones aplicadas en muchos desarrollos de sistemas de software

Abiertos y flexibles

• Debe ser abierto, de forma de facilitar su extensión y

parametrización con el fin de acoplarlo a un problema específico.

Debe ser capaz de soportar variaciones en su implementación

21

 Hay patrones arquitectónicos, patrones de diseño, e idioms o también llamados patrones de codificación

 Patrones arquitectónicos

– son estrategias a un alto nivel de abstracción, que se centran en los componentes complejos de un sistema, sus propiedades globales y mecanismos internos. Estos tienen fuertes implicaciones sobre la estructura y organización del sistema de software

– proporcionan un conjunto de subsistemas predefinidos, especificando sus responsabilidades y las reglas que guían la organización de las relaciones entre ellos

Patrones: Elementos Arquitectónicos

Reutilizables

22

Patrones de diseño

– son tácticas de un nivel medio de abstracción que desarrollan algunas de las estructuras y sus relaciones. No tienen mayor influencia sobre la globalidad del sistema, sin embargo definen “micro arquitecturas” para los subsistemas y componentes

– describen las estructuras de comunicación recurrentes que solucionan un problema de diseño general dentro de un contexto particular

“Idioms” o patrones de codificación

– son patrones a un bajo nivel de especificación para un lenguaje de programación. Describen como implementar aspectos particulares de los componentes o de las relaciones entre ellos usando las

características propias del lenguaje de programación (Buschmann et al, 1996)

Patrones: Elementos Arquitectónicos

Reutilizables

23

 En los patrones arquitectónicos se hace referencia a componentes (Diseño inicial)

 En los patrones de diseño se habla de clases, objetos y de relaciones de herencia, agregación y uso (Diseño detallado)

 En los idioms, se muestra con mayor detalle la implementación de las clases y sus funciones, tomando en cuenta las características propias del lenguaje en el que se quiere implementar el sistema (Implementación, Mantenimiento, Despliegue)

Patrones: Elementos Arquitectónicos

Reutilizables

24

Patrones Arquitectónicos

Del caos al orden soportan una conveniente descomposición del funcionamiento global del sistema en varias sub–funcionalidades, para disminuir la

complejidad de las tareas de diseño. Ellos incluyen los patrones de capas, de pipes y filtros y los de pizarrón

Sistemas distribuidos

proporcionan infraestructuras para sistemas cuyos componentes se encuentran localizados en diferentes procesos o en varios sistemas o componentes. Ejemplo: Broker

Sistemas interactivos

ayudan a estructurar sistemas, tomando en cuenta las interacciones humano–computador. Ejemplos: Model-View-Controler y el

Presentación-Abstracción-Control

Sistemas Adaptables

proporcionan infraestructuras para la extensión y adaptación de aplicaciones en respuesta a nuevas exigencias de evolución y cambios de funcionalidades. Ejemplos: El patrón Reflection y

Microkernel soportan fuertemente la extensión de aplicaciones y su adaptación a tecnología evolutivas y requisitos cambiantes

(Buschmann et al, 1996)

Categorías

25

Patrones Arquitectónicos

Patrones Arquitectónicos

Ejemplos de uso Características de calidad

En ISO/IEC 9126-1 En Buschmann et al. (Buschmann et al, 1996, 2000)

Broker CORBA y sus

implementaciones [Gopalan00]

y aplicaciones de comercio electrónico

·Funcionalidad

·Mantenibilidad

·Portabilidad

·Transparencia de localización, interoperabilidad

·Cambiabilidad, extensibilidad, reutilización

·Adaptabilidad

Microkernel Windows NT, Amoeba, Chorus ·Mantenibilidad

·Portabilidad

·Cambiabilidad, flexibilidad, extensibilidad

·Adaptabilidad

Interceptor Component-based application servers, CORBA

implementations, Microsoft COM, Web browsers, reflective ORB [Gopalan00]

·Funcionalidad

·Fiabilidad

·Mantenibilidad

·Seguridad

·Tolerancia a fallas

·Cambiabilidad, flexibilidad, reutilización, extensibilidad, configurabilidad

Reflection CLOS [Keene89], OLE 2.0 ·Mantenibilidad

·Portabilidad

·Cambiabilidad

·Adaptabilidad

Reactor ORB Core component in many implementations CORBA, Call Center Management System, Xt toolkit, ADAPTIVE

Communication Environment (ACE) Reactor Framework

·Mantenibilidad

·Portabilidad

·Cambiabilidad, extensibilidad, modularidad, configurabilidad y reutilización

·Concurrencia

MVC, PAC Sistemas Interactivos con interfaces GUI

·Mantenibilidad ·Cambiabilidad. En particular MVC soporta configurabilidad

26

 El patrón Broker es flexible, permite la interacción entre Clientes y Servidores que corran en distintos ambientes

 Cuando un requerimiento llega para un servidor sostenido por un Broker que es local, ( o sea, corre en la misma máquina en la cual corre el servidor ) este directamente los transmite a dicho servidor

 Si el servidor se encuentra registrado en otro Broker, entonces el Broker local busca la ruta del Broker remoto y envía el

requerimiento usando dicha ruta

 Un servidor es un componente que expone sus funcionalidades a través de interfaces que consisten de operaciones y atributos, accesibles por medio de un IDL (Interface Definition Language)

 Los clientes son componentes que acceden a los servicios de al menos un servidor, pero siempre a través del Broker, del cual también recibe la respuesta generada por el servidor

 Un componente puede en un momento dado, asumir el rol de cliente y en otro el rol de servidor

Patrón Broker

27

Patrón Broker

 Aunque el Broker, junto con los servidores y los clientes, son los componentes principales de este patrón, existen otros que proporcionan mayor flexibilidad, a saber:

 Los Proxies:

– Proxy del lado del cliente: es una capa entre los clientes y el Broker, la cual proporciona transparencia puesto que gracias a ella un servidor remoto aparece ante un componente cliente como local. En este caso, el componente proxy oculta detalles de implementación de los clientes (transferencia de mensajes entre los clientes, pase de parámetros)

– Proxy del lado del servidor: son responsables de recibir requerimientos y desempacarlos con el fin de llamar al servicio correcto. Además se encargan de recibir resultados y excepciones del servidor, empaquetándolos para luego enviarlos al Broker. Finalmente, cuando el proxy del lado del cliente recibe los paquetes entonces los traduce, de forma que los resultados puedan ser entendidos por el cliente

28

Patrón Broker

 Interacción entre Clientes y Servidores en forma remota

– Cuando el componente Broker no encuentra en su registro un Servidor que pueda hacer frente a un requerimiento, puede enviarlo a otro Broker a través del componente Bridge correspondiente, estableciéndose en este caso una interacción remota.

– Un componente Broker puede interactuar con otro Broker, pero siempre a través de los componentes de tipo Bridge, el cual tiene como tarea establecer mecanismos que permitan la comunicación entre componentes de tipo Broker con diferentes mecanismos de comunicación que corran además en distintos sistemas operativos o en distintos ambientes

– Si ninguno de los dos componentes Broker consiguen algún Servidor que pueda hacer frente a un determinado requerimiento, una excepción es entonces transmitida de retorno al Cliente que originó tal requerimiento

29

Patrón Broker

Diagrama de relaciones del patrón Broker. Tomado de [BMR+96].

Diagrama de interacciones del patrón Broker 30

31

Patrones de Diseño

Descomposición estructural

Soportan una descomposición de subsistemas y componentes complejos en partes cooperantes. Ejemplo: Todo-Partes

Organización del trabajo

Definen como los componentes colaboran para resolver un problema complejo. Ejemplo: Maestro-Esclavo

Control de acceso Proteger y controlar el acceso a servicios o componentes de importancia crítica. Ejemplo: Proxi

Comunicación Ayudan a organizar la comunicación entre componentes. . Ejemplo:

Client-Dispatcher-Server, Publisher-Subscriber

Gestión Administran colecciones de objetos, servicios y componentes homogéneos. Ejemplo: View Handler

(Buschmann et al, 1996)

Categorías

32

Patrones de diseño

Patrones de

Diseño

Ejemplos de uso Características de calidad

En ISO/IEC 9126-1 En Buschmann et al. [Buschmann96]

[Schmidt01], Gamma et al. [Gamma95]

Client-Dispatcher server

RPC, CORBA ·Funcionalidad

·Fiabilidad

·Mantenibilidad

·Transparencia de localización

·Tolerancia a fallas, disponibilidad

·Cambiabilidad, configurabilidad

Proxy OMG-CORBA, Orbix, OLE ·Funcionalidad

·Eficiencia

·Mantenibilidad

·Interoperabilidad

·Rendimiento

Modularidad, reutilización Active Object ACE framework, Java JDK 1.3,

ORB de TAO

·Funcionalidad

·Eficiencia

·Mantenibilidad

·Portabilidad

·Sincronización

·Rendimiento

·Flexibilidad

·Concurrencia Thread-Specific

Storage

WIN 32, Solaris, Active Template Library from COM

·Eficiencia

·Mantenibilidad

·Portabilidad

·Rendimiento

·Reutilización

·Concurrencia Wrapper Façade Java Virtual Machine, Java class

libraries (AWT, Swing), Microsoft Foundation Classes (MFC).

·Fiabilidad

·Mantenibilidad

·Portabilidad

·Robustez

·Modularidad, reutilización, configurabilidad

Publisher- Subscriber also known as subject/observer

CORBA ·Funcionalidad

·Eficiencia

·Mantenibilidad

·Seguridad

·Rendimiento

·Cambiabilidad

Mediator Sistemas Interactivos ·Mantenibilidad ·Cambiabilidad

33

Su objetivo es encapsular la forma mediante la cual un conjunto de componentes interactúan manteniéndolos desacoplados.

Este patrón es aplicado cuando:

 Un conjunto de componentes necesitan comunicarse con el fin de trabajar en forma cooperativa, siendo que las vías de interacción, aunque bien definidas se caracterizan por ser muy complejas

 Se quieren utilizar componentes que tienen formas muy distintas de comunicación

Este patrón está estructurado por los siguientes componentes:

Un Mediator: que define la interfaz de comunicación entre los Colegas, permitiendo la cooperación entre ellos para la realización de tareas. Este componente conoce y mantiene a todos los Colegas.

Colegas: siendo que cada uno de estos conoce tan solo a su “Mediator”.

Estos pueden hacer requerimientos únicamente a través del Mediator

Patrón Mediator

34

En este patrón, un Colega (que actúa en este caso como cliente) hace un requerimiento al Mediator correspondiente

Luego, el Mediator busca en sus registros a aquellos Colegas que pueden hacer frente a tal requerimiento, enviándoles entonces la información necesaria

El Colega que acepta el requerimiento (actuando en este caso como servidor) no conoce al Colega cliente, tan solo produce una respuesta apropiada y la envía al Mediator, que toma la respuesta y la comunica al cliente que originalmente ha realizado la demanda del servicio

El Mediator debe conocer a todos sus Colegas en tiempo de compilación, por lo que mantiene una estructura estática y poco flexible. Como ninguno de los Colegas conoce la existencia de otros Colegas, se logra de esta manera un bajo acoplamiento

Patrón Mediator

35

Ventajas de este patrón:

 Permite el desacoplamiento: es decir, promociona el bajo acoplamiento entre los Colegas, por lo que objetos con protocolos de comunicación distintos pueden cooperar

 Simplifica los protocolos de comunicación: un Mediator reemplaza las interacciones de muchos a muchos por interacciones de uno a muchos entre el Mediator y sus Colegas, siendo además este tipo de relación mucho más sencilla de entender e implementar. La comunicación entre los Colegas y el Mediator es bidireccional

 Encapsula y abstrae los mecanismos de cooperación entre los Colegas: su uso permite al diseñador separar las formas de comunicación de los comportamientos individuales de cada uno de los Colegas. Esto puede ayudar a clarificar las interacciones entre los objetos

 Como desventaja se puede mencionar que, debido a centralización que el componente Mediator realiza tanto del control como de la comunicación entre los Colegas, este puede llegar a ser sumamente complicado, por lo que puede ser difícil de mantener

Patrón Mediator

36

Patrón Mediator

Diagrama de Clases del Patrón Mediator. Tomado de [Gamma et al. 95]

Figura 14: Diagrama de objetos del Patrón Mediator. Tomado de [Gamma et al. 95]

37

 Similar al concepto de patrón arquitectónico (Garlan&Shaw, 1996)

 Definido como familias que comparten un patrón

estructural, en el que se definen tipos de componentes y de conectores comunes, así como un conjunto de

restricciones que determinan su topología

 Mary Shaw, David Garlan, 1996

– IEEE98SA-Styles-Patterns.pdf

– Inspirado en trabajo de Parnas, 1972 (“On the criteria to be used in decomposing systems into modules”) – Datos

compartidos vs ocultamiento de información

Estilos Arquitectónicos

38

Los estilos proporcionan:

 Un vocabulario de elementos de diseño, tipos de componentes y de conectores

 Unas reglas de diseño, que determinan la composición de los elementos de diseño

 La estructura final de la arquitectura

 Una guía sobre los posibles valores que deben ser aceptados como correctos y los posibles aspectos

críticos dentro de la arquitectura (Garlan&Shaw, 1996)

Estilos Arquitectónicos

39

Estilos Arquitectónicos

Los estilos arquitectónicos más comunes son

:

 Estilos de Flujo de Datos – Tubería y filtros

 Estilos Centrados en Datos

– Arquitecturas de Pizarra o Repositorio

 Estilos de Llamada y Retorno – Model-View-Controller (MVC) – Arquitecturas en Capas

– Arquitecturas Orientadas a Objetos

– Arquitecturas Basadas en Componentes

 Estilos de Código Móvil

– Arquitectura de Máquinas Virtuales

 Estilos Peer-to-Peer

– Arquitecturas Basadas en Eventos – Arquitecturas Orientadas a Servicios

40

Algunos estilos arquitectónicos

:

Estilos arquitectónicos

Tuberias y filtros (Pipes-filters)

Descompone la funcionalidad del sistema de software en una simple descomposición de funciones en filtros individuales. Pueden terminar en una organización de procesamiento en batch. Compiladores

Basada en eventos, invocación implícita

Permiten invocación implícita de una herramienta cuando otra

herramienta produce un evento. Un componente anuncia un evento.

Otros registran interés en ese tipo de evento. Se puede incorporar los componentes simplemente registrándolo dentro del listado de

eventos que lo activa. Cuando se produce el evento, el sistema lo comunica a los suscriptores. Modelo Publisher / Subscriber

Sistemas en capas Permiten descomponer el sistema en pequeños incrementos de abstracción. Fomenta el mantenimiento en el sentido de que las mejoras introducidas en cada capa solo afecta a las adyacentes No siempre es fácil estructurar un sistema en capas. La abstracción en múltiples capas no siempre es evidente cuando se examinan el conjunto de requerimientos. Además, el desempeño de este estilo se puede afectar con la coordinación necesaria que debe existir entre las capas. Los protocolos de comunicación. Protocolo TCP/IP, sistemas operativos, como UNIX

41

Estilo Arquitectónico Repositorios de

Datos

42

Estilo Arquitectónico Pipe-Filter

43

Estilo Arquitectónico de Capas

• Es el proceso de predecir atributos de calidad del sistema basado en el desarrollo de una Arquitectura de Software.

• Según Bosch 2000, la evaluación explícita de la arquitectura de los Sistemas de Software con respecto a los requisitos de calidad, minimizará los riesgos de construir un sistema que falle y, consecuentemente, disminuirá el costo de desarrollo del sistema.

• Para Clements, resulta interesante enfocarse en la evaluación para poder detectar problemas que si no se descubren podría ser peor descubrirlos tardíamente, obteniendo como resultado mejores arquitecturas.

• La manera de constatar que se está desarrollando una arquitectura de calidad es a través de su evaluación.

Evaluación Arquitectónica

45

 Los Lenguajes de Descripción Arquitectónica (ADLs) surgen como una respuesta a la necesidad de representar los sistemas de software desde el punto de vista arquitectónico a un alto nivel de abstracción, de manera que tales descripciones puedan ser utilizadas en las primeras etapas de desarrollo como una herramienta para conocer y evaluar el comportamiento global de la arquitectura propuesta para un sistema en función de los requerimientos iniciales

 Usualmente, las descripciones arquitectónicas, vienen dadas por diagramas de cajas y flechas acompañadas con texto. Tales descripciones son poco formales, siendo los ADLs una forma de lograr una mayor formalización de estas, manteniendo al mismo tiempo un alto nivel de abstracción en la descripción.

Evaluación Arquitectónica

46

ADL:

 es un lenguaje que permite describir a un alto nivel de abstracción los aspectos arquitectónicos de un sistema de software

 proporciona una sintaxis concreta y un marco conceptual dentro del cual se produce un modelo arquitectónico de un sistema

 puede ser utilizado para producir especificaciones más formales de los patrones

 Ejemplos: C2SADEL, WRIGHT, ACME, RAPIDE

La representación formal de la arquitectura de un sistema es más proclive a ser re-utilizada y sostenida en el tiempo que otra que no lo es

Evaluación Arquitectónica

47

 Presentación de vistas múltiples.

– Para los expertos, una descripción de alto nivel, como diagramas de cajas y líneas

– Para un segundo grupo, descripción textual sobre los componentes y conectores que conforman el sistema

– un tercer grupo puede requerir una vista de la evolución del sistema

 Generación de código. La capacidad de generar sistemas

ejecutables a partir de descripciones arquitectónicas es también una característica deseable en los ADLs

 Dinamismo. Que tiene que ver con la posibilidad de producir cambios en la arquitectura en tiempo de ejecución. Es en este punto donde se evidencia mayor debilidad en las herramientas de soporte disponibles en los distintos ADLs

Características de los ADLs

Evaluación Arquitectónica

48 Se convierte en base

fiable de comunicación

Facilita la comunicación entre los distintos especialistas que

conforman el equipo de desarrollo. Ofrece la posibilidad de utilizar tanto notaciones gráficas como textuales

Permite el

establecimiento de estándares en una organización

Una arquitectura formalizada y utilizada en repetidos proyectos, se puede convertir en un estándar institucional para producir una familia de productos

Facilita la toma de

decisiones de diseño al inicio del proceso de desarrollo

Proporcionan facilidades para la especificación arquitectónica de sistemas heterogéneos. Permite la especificación de restricciones

Es un medio para el logro de atributos de calidad

Las descripciones de las características de calidad pueden ser

analizadas por medio de herramientas automatizadas que apoyan al lenguaje, de forma que se puedan comprobar las ventajas y

desventajas de la arquitectura sin necesidad de llegar a la implementación

Ventajas de los ADLs

Evaluación Arquitectónica

Existe alguna diferencia entre arquitectura y diseño de software?

Discusión

La arquitectura y el diseño difieren en tres áreas:

Arquitectura Diseño

Nivel de

Abstracción

Alto nivel Bajo nivel. Enfoque

específico en detalles

Entregables

componentes reutilizables, prototipo arquitectónico

Diseño detallado componentes.

Especificaciones de codificación

Áreas de Enfoque

Selección de tecnologías, Req.

no funcionales (QoS) Manejo de Riesgos

Requerimientos funcionales

Discusión

La Arquitectura de Software envuelve un conjunto de decisiones estratégicas de diseño, lineamientos, reglas y patrones que restringen el diseño y la implementación de un software.

Arquitectura

Diseño

Implementación Código

Las decisiones de AS causan un alto impacto en los proyectos de TI

Discusión

Arquitectura Empresarial

 La Arquitectura Empresarial (AE) es una herramienta esencial para relacionar los sistemas de información, desarrollar nuevos sistemas e insertar nuevas tecnologías que optimicen la misión de una empresa u organización, permitiendo la identificación de oportunidades de mejoras.

 La AE permite entender y razonar la necesidad continua

de integración, cambios y responsabilidades de los

negocios en términos de la información necesaria para

operar los procesos de negocio y servicios, tomando en

cuenta la tecnología de soporte (Zachman, 1987).

Arquitectura Empresarial

 El término empresa se aplica en muchas circunstancias:

– Organizaciones del Sector Público o Privado – Un negocio completo o una corporación

– Una parte de una empresa (unidad de negocio) – Un conglomerado de varias organizaciones

 El término empresa incluye un sistema complejo, socio- técnico, que incluye: (Lankhorst, 2009)

– Personas, información, tecnología, negocios, limites y objetivos

Arquitectura Empresarial

Especificación de Arquitecturas Empresariales

Frameworks Orientan los niveles de la especificación y la

estructura de las AEs

Lenguajes

Permiten describir o expresar los

modelos que describen una

arquitectura

Herramientas Permiten la gestión

de la información y artefactos de la arquitectura así

como la

visualización y el

análisis

Arquitectura Empresarial

Frameworks de AE

ArchiMate®

Lenguajes de Modelado: EEML (Extended Enterprise Modeling Language), Archimate, UML, BPMN, entre otros.

Herramientas de Soporte a las AEs: permiten realizar

evaluaciones, administrar repositorios de modelos, entre otras funcionalidades. Ejemplos: Abacus, Archi, Bizzdesign Architect, Rational System Architect, Enterprise Architect Manager, entre otros Evaluación de las AE: El análisis sobre las AE, se realiza con el fin de facilitar la toma de decisiones adecuadas y fundamentadas

(situaciones actuales y deseadas). Existen distintas técnicas:

Análisis de Impacto del Cambio, Cuantitativas, entre otras.

Arquitectura Empresarial

•Según OMG , es un estilo de arquitectura

• Pala la OASIS , es un paradigma para organizar y utilizar

capacidades distribuidas

•Conjunto de componentes los cuales pueden ser invocados, y cuya descripción de interfaces pueden ser publicadas y

descubiertas (W3C)

•Enfoques utilizados en el desarrollo de soluciones de software integradas incluyendo los sistemas legados.

•Promueve la Reutilización, integración de sistemas de software,

interoperabilidad.

•Permite reducir el tiempo de desarrollo, mejorar la agilidad y adaptabilidad para afrontar los cambios, y propiciar la alineación del ambiente de negocios y de la

infraestructura tecnológica

•Elementos básicos: applicacion frontend,

servicios, repositorio de servicios y bus de servicios.

•WSDL usado para describir el servicio

•UDDI para registrar y buscar servicios

•SOAP como una capa de transporte para enviar mensajes entre los consumidores de servicios y proveedores.

• Un servicio provee lógica de negocio y datos, un contrato de servicio,

restricciones para el consumidor, y una interfaz que expone la funcionalidad.

• Implementación: servicios Web, servicios Grid

Desarrollo de Metodología SOA

Profiles para UML. Notación para servicios.

Identificación de Servicios.

Arquitectura Empresarial

SOA

Tendencias Actuales

Hay discusiones acerca de si SOA está incluido en EA o EA está incluido en SOA

Tendencias Actuales

•Busca separar el diseño de la arquitectura y de las tecnologías de construcción,

facilitando que el diseño y la arquitectura puedan

ser alterados independientemente

•Enfoque de desarrollo de software basado en la transformación sucesiva de modelos correspondientes a distintos niveles de abstracción desde el conceptual hasta la implementación

• CIM (computation independent model)

•PIM (plataform independent model )

•PSM (platform specific model)

•Reglas de Transformación •Separación de responsabilidades,

•Modelos puedan evolucionar por separado

•Disminuir costos

•Mejorar la calidad de los modelos y procesos,

• Tecnologías involucradas : Meta Object Facility (MOF), Unified Modeling

Language (UML), XML Model Interchange (XMI), Common Warehouse Meta-model (CWM), Software Process Engineering Meta-model (SPEM), Action Semantics Language (ASL), Query-View-

Transformation? (QVT), UML profiles.

•Especificación de Transformaciones entre modelos

•Proceso de Desarrollo de Software Mediante Herramientas MDA

Model-Driven Architecture

Arquitectura Empresarial

Conclusiones

•

La Arquitectura de Software presenta la estructura o estructuras del sistema, la cual comprende componentes de Software, propiedades externas de esos componentes y la interacción entre ellos

• Existen modelos para presentar la Arquitectura de

software

•

La evaluación arquitectónica es el proceso de predecir atributos de calidad del sistema basado en el desarrollo de una Arquitectura de Software

• Los aspectos de calidad se propician y validan a través de la Arquitectura de Software

Conclusiones

Preguntas

Presentación de Elluz Uzcategui en curso electivo de Arquitecturas Empresariales, Julio 2012.

(OMG), O. M. (2011). Business Process Model and Notation (BPMN).

(OMG), O. M. (2011). OMG Unified Modeling Language (UML).

Arango, M., Londoño, J., & Zapata, J. (2010). Arquitectura Empresarial - Una visión General. Revista Ingenierías Universidad de Medellín, 101-111.

Escobar, J., Losavio, F., & Ortega, D. (2012). Una revisión de Frameworks, Lenguajes de Modelado y Herramientas. Memorias del II Simposio Científico y Tecnológico en

Computación (pp. 212-219). Caracas: Escuela de Computación de la Universidad Central de Venezuela.

KITCHENHAM, B. (1996). Evaluating Software Engineering Methods and Tools.

Lankhorst, M. (2009). Enterprise Architecture at Work: Modelling, Communication, and Analysis. Alemania: Springer.

Lankhorst, M., & team, a. t. (2004). ArchiMate Language Primer. Telematica Instituut.

SESSIONS, R. (2007). A Comparison of the Top Four EA Methodologies.

Referencias Bibliográficas

The Open Group . (2012). An Introduction to ArchiMate® 2. The Open Group.

The Open Group. (n.d.). ArchiMate® 1.0 Specification. Retrieved mayo 10, 2012, from http://www.opengroup.org/archimate/doc/ts_archimate/

Bass L., Clements, P., Kazman R., “Software Architecture in Practice, Addison Wesley, 1998

Bianco Philip; Lewis Grace A.; Merson Paulo; Simanta Soumya. Architecting Service- Oriented Systems. Technical Note CMU/SEI-2011-TN-008. Research, Technology, and System Solutions Program. August 2011. Disponible en http://www.sei.cmu.edu

Buschmann F. et al “Pattern-Oriented Software Architecture. A System of Patterns”, John Wiley & Sons Inc., 1996. C. Britton “IT Architectures And Middleware”, Addison Wesley, 2000.

Clements P., Kazman R., Klein M. “Evaluating Software Architectures. Methods and Case Studies. Addison Wesley, 2002.

Referencias Bibliográficas

Referencias Bibliográficas

Gamma H., Helm R., Johnson R.,Vlissides J. “Design Patterns”. Elements of Reusable Objet-Oriented Software, Addison Wesley, Readings Massachusetts, 1996

D. Garlan, M. Shaw, B Meyer., "An Introduction to software Architecture" CMU Software Engineering Institute Technical Report, CMU/SEI-94-TR-21, 1994

Kazman R., Gagliardib M., Wood W. Scaling up software architecture analysis. Journal of Systems and Software, pp. 1-9, 2011.

F. Losavio, L. Chirinos, N. Lévy, A. Ramdane-Cherif, “Quality Characteristics for Software Architecture”, Journal of Object Technology, vol 2., no. 2, March-April 2003, pp. 133-150, http//www.jot.fm/issues/issue_2003_03/article2

A.Lamsweerde, “From System Goals to Software Architecture” Formal Methods for Software Architecture, M. Bernardo&P. Invernardi (eds.), LNCS 2804, Springer-Verlag, 2003.

V. Poladian, J. P. Sousa, D. Garlan, M. Shaw, “Dynamic Configuration of Resource- Aware Services”, 26th ICSE, 604-613, Edinbourg, U.K., 2004

W3C, “Extensible Markup Language (XML)”, 1.0, REC-XML-19980210, Feb. 1998

Jacobson I., Booch G., Rumbaugh J. “The Unified Development Process”, Rational Software Corporation, Addison Wesley, Readings, Massachussets, 1999

A. Navarro, Pérez M. A., Murillo J. M., Aspect Modelling at Architectural Design, EWSA, LNCS, pp. 41-58, 2005.

L. Bass, Klein M, F. Bachmann, Quality Attribute Design Primitives and the Attribute Design Method, Software Product Family Engineering, Int. Workshop PFE, Bilbao, Spain, LNCS Vol. 2290, pp. 169-186, 2001

F. Losavio, C. Guillén, Comparación de métodos para la arquitectura de software: hacia un proceso unificado de diseño arquitectónico. Revista de la Facultad de Ingenieria, UCV. 2008

D. Garlan, Software Architecture: A Roadmap, from “The future of Software Engineering”, ACM press, 2000.

M. Shaw, D. Garlan, Software Architecture. Perspectives on an Emerging Discipline, Prentice Hall, New Jersey,1996.

Referencias Bibliográficas