Módulo 5: Diseño arquitectónico

Diseño y Desarrollo de Software (1er. Cuat. 2018)

Profesora titular de la cátedra:Marcela Capobianco

Profesor interino:Gerardo I. Simari

Licenciatura en Ciencias de la Computación – UNS

Licencia

● Copyright ©2018 Marcela Capobianco.● Se asegura la libertad para copiar, distribuir y modificar

este documento de acuerdo a los términos de la GNU Free Documentation License, Version 1.2 o cualquiera posterior publicada por la Free Software Foundation, sin secciones invariantes ni textos de cubierta delantera o trasera.

● Una copia de esta licencia está siempre disponible en la página http://www.gnu.org/copyleft/fdl.html

Qué es una arquitectura de software

Definición: Conjunto de todas las principales decisiones de diseño sobre el sistema:

● Es el “plano” para la construcción y evolución del sistema.

● Las decisiones de diseño abarcan:– Estructura– Comportamiento– Interacción– Propiedades no funcionales

3

¿Qué significa “principal”?

● “Principal” implica un grado de importancia que le da a la decisión de diseño un estado arquitectónico.

● No todas las decisiones impactan en la arquitectura del sistema.

● Depende de lo que los participantes definan como objetivos del sistema.

4

Otras definiciones

Shaw y Garlan (1996):

“Software architecture [is a level of design that] involves the description of elements from which systems are built, interactions among those elements, patterns that guide their composition, and constraints on these patterns.”

Otras definiciones

Kruchten (1995):

“Software architecture deals with the design and implementation of the high-level structure of software. Architecture deals with abstraction, decomposition, composition, style, and aesthetics.”

En conclusión

● La arquitectura de software es un modelo:

– Simplificación de la realidad.– Abstracción cerrada: tiene cierta independencia.

● El modelado puede ser:

– Informal– Semi-formal– Formal

● En la academia suele ser formal, mientras que en la industria generalmente es semi-formal o informal.

Componentes y conectores

● Garlan (1993) ataca la tarea de definir la arquitectura planteando una tupla:

SA={componentes, conectores, restricciones}● Los componentes y conectores son elementos en un

nivel arquitectónico.● Los componentes no necesariamente son clases de

sistemas OO.● Los componentes y conectores pueden reflejar el

estado en tiempo de ejecución; no son estáticos como una clase.

¿Qué falta?

● Los componentes definen protocolos de comunicación y estrategias.

● Las restricciones definen las reglas que el sistema debe respetar.

● ¿Es esto suficiente? ¿Qué falta?

¿Qué falta?

● Los componentes definen protocolos de comunicación y estrategias.

● Las restricciones definen las reglas que el sistema debe respetar.

● ¿Es esto suficiente? ¿Qué falta?

Se necesitan varias vistas diferentes: – Estática/Dinámica– Lógica– etc.

Word Frequency Counter

Supongamos que queremos desarrollar un programa que toma un archivo de texto y devuelve pares (palabra, frecuencia) para cada palabra que ocurre en el texto, ordenados por frecuencia.

Word Frequency Counter: Primera idea

Word Frequency Counter: Otra posibilidad

Aspectos temporales

● Las decisiones de diseño pueden hacerse y deshacerse durante la vida del sistema.

● Por lo tanto, la arquitectura tiene un aspecto temporal.

● En un punto en el tiempo, el sistema tiene una sola arquitectura.

● Pero si cambia, se puede pensar que ha tenido una “familia de arquitecturas”.

14

Prescriptiva vs. Descriptiva

● Arquitectura prescriptiva: Captura las decisiones de diseño tomadas previo a la construcción del sistema:

Es cómo fue concebido el sistema

● Arquitectura descriptiva: describe cómo el sistema ha sido construido

Es la arquitectura de acuerdo a cómo fue implementado

15

Evolución arquitectónica

● Cuando un sistema evoluciona, idealmente se modifica primero su arquitectura prescriptiva.

● En la práctica, el sistema – y por ende su arquitectura descriptiva – es frecuentemente modificado directamente por:– Pereza de los desarrolladores– Fechas de entrega demasiado estrictas– Falta de documentación de la arquitectura prescriptiva– Técnicas o herramientas inadecuadas– etc., ...

16

Degradación Arquitectónica

● Architectural drift (corrimiento arquitectónico): Introducción de las principales decisiones de diseño en la arquitectura descriptiva del sistema– que no están incluidas en (o implicadas por) la

arquitectura prescriptiva– pero no violan las decisiones de diseño de la

arquitectura prescriptiva● Architectural erosion (erosión arquitectónica):

Introducción de las decisiones de diseño arquitectónicas en la arquitectura descriptiva que violan su arquitectura prescriptiva.

17

Recuperación arquitectónica

● Si se permite que progrese la degradación, tarde o temprano tendrá que hacerse una recuperación.

● Es el proceso de determinar la arquitectura de un sistema desde sus artefactos a nivel de implementación.

● Los artefactos pueden ser:– Código fuente– Archivos ejecutables (Java .class, etc.)– Archivos de configuración– Bases de datos

● Es un proceso muy costoso en general.

18

IEEE 1471 (año 2000)

● Esfuerzo por crear un estándar en el campo de la arquitectura de software.

● Se resaltan varios aspectos clave.

IEEE 1471 (año 2000)

● Every system has its own architecture, no two are identical.

El sistema es un producto concreto, mientras que la arquitectura es una abstracción dependiente del sistema.

● A software’s architecture and its description are different.

La arquitectura existe cuando existe el software. Antes de que exista, sólo tenemos el modelo prescriptivo.

IEEE 1471 (año 2000)

● SA: la organización del sistema personificada en sus componentes, las relaciones entre estos, la relación con el ambiente y los principios que guiaron su diseño y evolución.

● Descripción: una colección de productos para documentar la arquitectura.

● Técnicas para documentar: diagramas varios en UML, uso de un ADL, diagramas simples de cajas y líneas, etc. Es importante el uso de convenciones.

● No todos los sistemas cuentan con una descripción adecuada; por ejemplo, los sistemas legado (legacy).

IEEE 1471 (año 2000)

● Software architecture, architectural description, and development process are separated, both in research and in application.

El uso de un modelo de proceso no implica que deba usarse un tipo particular de descripción.

● Space should be left for facilitating the customization of detailed architectural models for research and practice.

Es por esto que nos enforamos en los principios rectores.

ISO/IEC/IEEE 42010

● Evolución de la anterior norma, publicada en 2011.● Especifica, entre otras cosas:

– La manera en que se organizan y expresan las descripciones arquitectónicas de un sistema.

– Los conceptos de architecture viewpoints, architecture frameworks, y define nuevamente SA.

● También define el concepto de description languages para usar en las descripciones.

Conceptos importantes

● Architecting: Proceso de concebir, definir, comunicar, certificar la implementación adecuada y mejorar una arquitectura a través de su ciclo de vida.

● System Architecture: Conceptos fundamentales o propiedades de un sistema corporizado en sus elementos, relaciones y los principios de su diseño y evolución.

Conceptos importantes

● Architecture description (AD): Producto usado para expresar una arquitectura.

● Architecture framework: Convenciones, principios y prácticas para la descripción de arquitecturas que están establecidas en un dominio específico.

● Concern: Interés en un sistema que es relevante a uno o mas de los participantes (stakeholders).

Conceptos importantes

● Architecture view (vista): Producto que expresa la arquitectura de un sistema desde la perspectiva de un aspecto (concern) específico del mismo.

● Architecture viewpoint (punto de vista): Producto que establece las convenciones para la construcción, interpretación y uso de las vistas arquitectónicas para enmarcar un concern específico.

● Environment: Contexto que determina las circunstancias de todas las influencias sobre un sistema

Una vista es lo que se ve. Un punto de vista es desde dónde se mira; el punto o perspectiva determina lo que se ve.

Algunos concerns

● Funcionalidad● Factibilidad● Uso● Propósitos, características y propiedades del sistema● Limitaciones conocidas● Estructura● Comportamiento● Performance● Recursos

Contexto de la Descripción Arquitectónica

Descripciones

● SA contiene lo que es esencial para el sistema, considerando su entorno.

● Esto puede contener alguno o todos de los siguientes elementos:

– Constituyentes del sistema o elementos– Cómo se relacionan estos elementos y/u organizan– Principios de organización y diseño del sistema

Descripción arquitectónica: Contexto ampliado

Importante

No se especifican:– Formatos o medios para almacenar las descripciones.– Procesos o métodos usados para producirlas. – Modelos, notaciones o técnicas.

Views vs. Viewpoints

● Un architecture view (vista) expresa la arquitectura del sistema de acuerdo con un architecture viewpoint (punto de vista).

● Aspectos de un viewpoint: Los concerns que enmarca para los participantes (stakeholders) y las convenciones sobre las cuales establece las vistas.

● Un architecture viewpoint enmarca uno o más concerns, y un concern puede ser enmarcado por más de un viewpoint.

Views vs. Viewpoints

● Una vista es gobernada por su viewpoint asociado, el cual establece las convenciones para construir, interpretar y analizar la vista para así abordar los concerns enmarcados.

● Las convenciones de un viewpoint pueden incluir lenguajes, notaciones, clases de modelos, etc.

Ejemplo views y viewpoints

Vista de deployment de una aplicación de 3 etapas (3-tier)

Vista de deployment de un sistema Lunar Lander

Son instancias del punto de vista de deployment

Observación importante

● El estándar no usa frases como “business architecture”, “physical architecture” o “technical architecture”.

● La arquitectura es una concepción holística de las propiedades fundamentales del sistema, que se entiende mejor mediante diversas vistas.

● Sí se pueden usar los términos “business view”, “physical view” y “technical view”.

Modelos arquitectónicos

● Un architecture view se compone de uno o más modelos arquitectónicos (architecture models).

● Un modelo usa convenciones apropiadas para los concerns que se quieren abordar.

● Esas convenciones se especifican por el tipo de modelo que lo gobierna.

AD: Elementos y Correspondencias

● Correspondencias: Capturan las relaciones entre elementos de AD.

● Las correspondencias y las reglas de correspondencias se usan para expresar y forzar relaciones arquitectónicas como: composición, refinamiento, consistencia, trazabilidad.

Ejemplo de correspondencia

● HW(S): Vista de hardware. Incluye las plataformas de hardware p1, …, p4.

● SC(S): Vista de componentes de software. Incluye los elementos de software e1, …, e6.

● Se reglamentan (enforce) las correspondencias de ejecución especificadas en la tabla.

Decisiones arquitectónicas

Decisiones arquitectónicas

● Una decisión arquitectónica afecta los elementos de DA y se relaciona con uno o más concerns.

● Importante: Al tomar una decisión pueden aparecer nuevos concerns.

● Architecture rationale: Registra la explicación o justificación sobre decisiones arquitectónicas que se realizaron, y posiblemente las alternativas que no se eligieron.

Architecture Framework

● Un architecture framework establece una práctica común para crear, interpretar, analizar y usar una DA dentro de un dominio particular o comunidad de stakeholders.

● Nos ayuda a elegir qué viewpoints y vistas usar en cada caso.

Architecture Framework

¿Qué hace un framework?

● Describe una metodología para la definición de un sistema de información en términos de un conjunto de bloques constitutivos.

● Contiene un conjunto de herramientas.● Provee un vocabulario común.● Incluye una lista de estándares recomendados.

Algunos ejemplos de frameworks

● Zachman’s information systems architecture framework [44],

● UK Ministry of Defence Architecture Framework [27],

● The Open Group’s Architecture Framework (TOGAF) [41],

● Kruchten’s “4+1” view model [23],

● Siemens’ 4 views method [10],

● Reference Model for Open Distributed Processing (RM-ODP),

● [ISO/IEC 10746] and Generalized Enterprise Reference Architecture (GERA) [ISO 15704].

Las referencias están

en la definición de la norma

Ejemplo de framework: TOGAF

● Provee un enfoque para el diseño, planificación, implementación y gobierno de una arquitectura empresarial de información.

● Está modelada en cuatro niveles o dimensiones:– Negocios– Tecnología– Datos– Aplicaciones

TOGAF

● Arquitectura de Negocios: Define la estrategia de negocios, la gobernabilidad, la estructura y los procesos clave de la organización.

● Arquitectura de Aplicaciones: Provee un plano para:

– cada uno de los sistemas de aplicación que se requiere implantar,

– las interacciones entre estos sistemas y – sus relaciones con los procesos de negocio centrales de

la organización.

TOGAF

● Arquitectura de Datos: Describe la estructura de los datos físicos y lógicos de la organización, y los recursos de gestión de estos datos.

● Arquitectura Tecnológica: Describe la estructura de hardware, software y redes requerida.

Architecture Description Language (ADL)

ADLs

● Un ADL es una forma de expresión para ser usada en la descripción arquitectónica.

● Puede incluir un tipo de modelo, un viewpoint o varios de ellos.

● Ejemplos: – Rapide– SysML– ArchiMate– ACME– xADL.

Resumiendo

Resumiendo

● “A viewpoint is a way of looking at a system, a view is what you can see.”

● Un viewpoint define las convenciones (notaciones, lenguajes y tipos de modelos) que van a ser usados en una vista.

● Una vista es el resultado de aplicar un viewpoint a un sistema de interés particular.

ISO/IEC/IEEE 42010

Resumiendo

● Architecture viewpoints: Definen los contenidos de cada vista.

● Architecture frameworks: Conjunto coordinado de viewpoints para usar en un dominio en particular.

● ADLs: Cualquier modo de expresión usado en una descripción arquitectónica.

Vista: Componentes y conectores

● Es la vista más importante y comunmente usada.● Muchos autores (sobre todo en el pasado) sólo usan

este tipo de vista para sus descripciones arquitectónicas.

● Es fácil deducir atributos de calidad en esta vista en fases tempranas del desarrollo.

● Esto disminuye los riesgos de desarrollo.

Ejemplo: Sistema de gestión de versiones

Vista: Componentes y conectores

● Abstrae la esencia de la ejecución del sistema.● Cada elemento tiene un significado en tiempo de

ejecución.● Por ejemplo, el code repository server puede ser

implementado por varias clases OO.● Cada elemento debe tener un significado claro y bien

definido (notación).● Es históricamente importante: inicialmente se la pensó

como “la arquitectura”.

Componentes

● Elementos que encapsulan procesamiento y datos en la arquitectura del sistema.

● Un componente de software es una entidad que:– Encapsula un subconjunto de funcionalidad y/o datos del

sistema.– Restringe acceso a ese conjunto vía una interfaz definida

en forma explícita.– Posee dependencias explícitamente definidas en su

contexto requerido de ejecución.● Típicamente proveen servicios específicos de

la aplicación.56

Conectores

57

● En sistemas complejos, la interacción puede ser más importante que la funcionalidad de las componentes.

● Un conector es un bloque de construcción arquitectónico al que se le asigna la tarea de realizar y regular la interacción entre componentes.

● En muchos casos son llamadas a subrutinas, o accesos de datos compartidos; otras veces son más complejos.

Ejemplos de conectores

● Llamadas a procedimiento (métodos, subrutinas, etc.)

● Memoria compartida● Pasaje de mensajes● de flujo (streaming)● de distribución● de envoltorio/adaptación (wrapper/adapter)

58

Viewpoints más comunes

● Requerimientos● Lógica/Descomposición● Datos● Implementación/Artefactos● Procesos● Deployment

Vista de descomposición

● Brinda información más estática.● Se puede usar en primer lugar para definir el

vocabulario del sistema y luego construir su modelo lógico.

● Descomponemos el sistema completo en varios conceptos con un estilo top-down.

Vista de descomposición

● El proceso puede continuar hasta cumplir con el objetivo de los desarrolladores.

● Los conceptos y sus asociaciones construyen el modelo lógico del sistema.

● Ventaja: Se pueden reutilizar bloques del sistema.● Permite dividir el trabajo entre los desarrolladores.

Vista de implementación

● Implementation view, o artifact view, se concentra en especificar qué archivos fuente se usan para implementar las unidades lógicas.

● También refleja la relación entre los archivos de código fuente.

● Se debe incluir información de versiones.● Es principalmente de utilidad para los desarrolladores

y líderes de proyecto.

Vista de implementación

Vista de deployment

● Llena la brecha entre el software y hardware.● Los elementos de software incluyen módulos,

objetos, procesos, etc.● Los de hardware se llaman nodos, y pueden ser un

workstation, un mainframe, un server, un router o un dispositivo móvil.

● Se expresan en varios grados de formalidad.

Vista de deployment

Vista de deployment

● Principal utilidad:

Analizar las propiedades de los nodos (CPU, memoria, ancho de banda de las redes) expone los problemas existentes en este aspecto.

● Ejemplo:

Calcular y rastrear qué parte del sistema completo degrada la performance por motivos de HW, y luego simplificar u optimizar los algoritmos.

Vista de deployment: Resumen

● Propósito: Documentar la puesta en funcionamiento física de los bloques de software.

● Interesados: Arquitectos, desarrolladores, operadores.

● Concerns: ¿Cómo se ponen en funcionamiento los bloques del sistema, y cómo se operan?

● Artefactos:– Instalación y configuración

– Topología de la red

– Protocolos de red

– Entorno de operación

– Guías (guidelines)

Vista de requerimientos: Resumen

● Propósito: Documentar los requerimientos del sistema.

● Interesados: Arquitectos, desarrolladores, clientes, gerentes, expertos del dominio, testers, líder de proyecto.

● Concerns:

– ¿Cómo es el contexto de sistema en el negocio?

– ¿Cuáles son los reqerimientos esenciales que deben satisfacerse?

● Artefactos:

– Oportunidades de negocio y descripción del problema

– Interesados

– Procesos de negocio

– Requerimientos

– Guías (guidelines)

Vista lógica: Resumen

● Propósito: Documentar el diseño de la arquitectura.

● Interesados: Arquitectos, desarrolladores, expertos del dominio.

● Concerns: ¿Cuáles son las estructuras lógicas del sistema?

● Artefactos:

– Visión general/resumen de la arquitectura

– Contexto del sistema

– Abstracciones clave (con descripción de comportamientos)

– Bloques básicos de funcionalidad

– Bloques básicos técnicos

– Guías (guidelines)

Vista de datos: Resumen

● Propósito: Documentar los aspectos relevantes al almacenamiento, manipulación, manejo y distribución de datos.

● Interesados: Arquitectos (de datos), desarrolladores.

● Concerns: ¿Cuáles son las estructuras de datos y flujos de datos del sistema?

● Artefactos:

– Abstracciones clave (sin descripción de comportamientos)

– Modelos de datos

– Flujos de datos

– Guías (guidelines)

Vista de implementación: Resumen

● Propósito: Documentar la estructura e infraestructura de implementación.

● Interesados: Arquitectos, desarrolladores, administradores de la configuración, administradores de testing, testers.

● Concerns: ¿Cómo son la estructura e infraestructura de implementación?

● Artefactos:

– Estructura de implementación

– Guías (guidelines)

Vista de procesos: Resumen

● Propósito: Documentar el control y coordinación de bloques concurrentes.

● Interesados: Arquitectos, desarrolladores.

● Concerns: ¿Cuáles son los bloques concurrentes del sistema?

● Artefactos:

– Procesos e hilos de ejecución (threads)

– Comunicación interproceso

– Modelo de estados

– Guías (guidelines)

Patrones y estilos arquitectónicos

● Algunas decisiones de diseño resultan regularmente en soluciones con propiedades superiores.

● Comparado con otras alternativas posibles, estas soluciones son más elegantes, eficientes, efectivas, escalables, etc.

Estilos arquitectónicos

Un estilo arquitectónico es una colección de decisiones de diseño con un nombre determinado que:

● Son aplicables en un contexto determinado.● Restringen las decisiones de diseño arquitectónicas

que son específicas a un sistema particular dentro de ese contexto.

● Elicitan cualidades beneficiosas en el sistema resultante.

Patrones arquitectónicos

● Un patrón arquitectónico es un conjunto de decisiones de diseño de arquitectura que son aplicables a un problema recurrente de diseño y parametrizados para ser usados en distintos contextos.

● Un patrón muy usando en los sistemas distribuidos es el three-tiered system pattern:

– Applicaciones científicas

– Bancos y comercio electrónico

– Sistemas de reservas

75

Three-Tiered Pattern

● Front TierContiene la funcionalidad de interface de usuario para acceder a los servicios del sistema.

● Middle TierContiene la funcionalidad principal del sistema.

● Back TierContiene los accesos a datos y almacenamiento de la aplicación.

76

Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.

Modelos, Vistas y Visualizaciones

Tres conceptos que suelen causar confusión:● Architecture Model

Un artefacto documentando algunas de las decisiones de diseño del sistema

● Architecture VisualizationUna forma de describir algunas de las decisiones de diseño sobre un sistema a un participante

● Architecture ViewUn subconjunto de decisiones de diseño relacionadas

77

Bibliografía

● R. N. Taylor, N. Medividovic, E. Dashofy: “Software Architecture: Foundations, Theory, and Practice”. Wiley, 2009. Capítulos 3 y 4.

● ISO/IEC/IEEE 42010:2011. Systems and Software Engineering — Architecture Description.

Otra bibliografía

● Z. Qin, J. Xing, X. Zheng: “Software Architecture”. Springer, 2008. Capítulo 1.