Capítulo 6 - Diseño arquitectónico
Temas cubiertos
Decisiones de diseño arquitectónico
Vistas arquitectónicas
Patrones arquitectónicos
Arquitecturas de aplicaciones
Diseño arquitectónico
El diseño arquitectónico se ocupa de comprender cómo se debe organizar un sistema de
software y diseñar la estructura general de ese sistema.
El diseño arquitectónico es el vínculo crítico entre el diseño y la ingeniería de requisitos, ya que
identifica los principales componentes estructurales de un sistema y las relaciones entre ellos.
El resultado del proceso de diseño arquitectónico es un modelo arquitectónico que describe
cómo se organiza el sistema como un conjunto de componentes comunicantes.
Agilidad y arquitectura
En general, se acepta que una etapa inicial de los procesos ágiles es diseñar una arquitectura
general de sistemas.
La refactorización de la arquitectura del sistema suele ser costosa porque afecta a muchos
componentes del sistema.
Abstracción arquitectónica
La arquitectura en lo pequeño se ocupa de la arquitectura de programas individuales. En este
nivel, nos preocupa la forma en que un programa individual se descompone en componentes.
La arquitectura en general se ocupa de la arquitectura de sistemas empresariales complejos que
incluyen otros sistemas, programas y componentes de programas. Estos sistemas empresariales se
distribuyen en diferentes computadoras, que pueden ser propiedad y estar administradas por
diferentes compañías.
Ventajas de la arquitectura explícita
Comunicación con las partes interesadas
La arquitectura puede ser utilizada como foco de discusión por las partes interesadas del sistema.
Análisis del sistema
Significa que es posible analizar si el sistema puede cumplir con sus requisitos no funcionales.
Reutilización a gran escala
La arquitectura puede ser reutilizable en una variedad de sistemas Se pueden desarrollar
arquitecturas de línea de productos.
Representaciones arquitectónicas
Los diagramas de bloques simples e informales que muestran entidades y relaciones son el
método más utilizado para documentar arquitecturas de software.
Pero estos han sido criticados porque carecen de semántica, no muestran los tipos de relaciones
entre entidades ni las propiedades visibles de las entidades en la arquitectura.
Depende del uso de modelos arquitectónicos. Los requisitos para la semántica del modelo
dependen de cómo se utilicen los modelos.
Diagramas de recuadros y líneas
Muy abstractos: no muestran la naturaleza de las relaciones de los componentes ni las
propiedades visibles externamente de los subsistemas.
Sin embargo, útil para la comunicación con las partes interesadas y para la planificación de
proyectos.
Uso de modelos arquitectónicos
Como una forma de facilitar la discusión sobre el diseño del sistema
Una vista arquitectónica de alto nivel de un sistema es útil para la comunicación con las partes
interesadas del sistema y la planificación del proyecto porque no está abarrotada de detalles. Las
partes interesadas pueden relacionarse con él y comprender una visión abstracta del sistema.
Luego pueden discutir el sistema en su conjunto sin confundirse con los detalles.
Como una forma de documentar una arquitectura que ha sido diseñada
El objetivo aquí es producir un modelo de sistema completo que muestre los diferentes
componentes de un sistema, sus interfaces y sus conexiones.
Decisiones de diseño arquitectónico
El diseño arquitectónico es un proceso creativo, por lo que el proceso difiere según el tipo de
sistema que se esté desarrollando.
Sin embargo, una serie de decisiones comunes abarcan todos los procesos de diseño y estas
decisiones afectan las características no funcionales del sistema.
Reutilización de la arquitectura
Los sistemas en el mismo dominio a menudo tienen arquitecturas similares que reflejan
conceptos de dominio.
Las líneas de productos de aplicación se basan en una arquitectura central con variantes que
satisfacen los requisitos particulares de los clientes.
La arquitectura de un sistema puede diseñarse en torno a uno o más patrones arquitectónicos o
"estilos".
Estos capturan la esencia de una arquitectura y se pueden instanciar de diferentes maneras.
Arquitectura y características del sistema
Rendimiento
Localice las operaciones críticas y minimice las comunicaciones. Utilice componentes grandes en
lugar de grano fino.
Seguridad
Utilice una arquitectura en capas con activos críticos en las capas internas.
Protección
Localice las características críticas para la seguridad en una pequeña cantidad de subsistemas.
Disponibilidad
Incluya componentes y mecanismos redundantes para la tolerancia a fallas.
Mantenibilidad
Utilice componentes reemplazables de grano fino.
Vistas arquitectónicas
¿Qué vistas o perspectivas son útiles al diseñar y documentar la arquitectura de un sistema?
¿Qué notaciones deben usarse para describir modelos arquitectónicos?
Cada modelo arquitectónico solo muestra una vista o perspectiva del sistema.
Podría mostrar cómo se descompone un sistema en módulos, cómo interactúan los procesos en
tiempo de ejecución o las diferentes formas en que los componentes del sistema se distribuyen en
una red. Tanto para el diseño como para la documentación, normalmente es necesario presentar
varias vistas de la arquitectura del software.
Modelo de vista 4 + 1 de arquitectura de software
Una vista lógica, que muestra las abstracciones clave en el sistema como objetos o clases de
objetos.
Una vista de procesos, que muestra cómo, en tiempo de ejecución, el sistema está compuesto
por procesos que interactúan.
Una vista de desarrollo, que muestra cómo se descompone el software para su desarrollo.
Una vista física, que muestra el hardware del sistema y cómo se distribuyen los componentes de
software en los procesadores del sistema.
Relacionado con el uso de casos de uso o escenarios (+1)
Representación de vistas arquitectónicas
Algunas personas argumentan que el Lenguaje de modelado unificado (UML) es una notación
apropiada para describir y documentar arquitecturas de sistemas
No estoy de acuerdo con esto porque no creo que UML incluya abstracciones apropiadas para la
descripción de sistemas de alto nivel.
Se han desarrollado lenguajes de descripción arquitectónica (ADL) pero no se utilizan
ampliamente.
Patrones arquitectónicos
Los patrones son un medio de representar, compartir y reutilizar el conocimiento.
Un patrón arquitectónico es una descripción estilizada de buenas prácticas de diseño, que ha
sido probada en diferentes entornos.
Los patrones deben incluir información sobre cuándo son y cuándo no son útiles.
Los patrones se pueden representar mediante descripciones tabulares y gráficas.
El patrón Modelo-Vista-Controlador (MVC)
Descripción: Separa la presentación y la interacción de los datos del sistema. El sistema está
estructurado en tres componentes lógicos que interactúan entre sí. El componente Modelo
administra los datos del sistema y las operaciones asociadas en esos datos. El componente Ver
define y administra cómo se presentan los datos al usuario. El componente Controlador gestiona
la interacción del usuario (por ejemplo, pulsaciones de teclas, clics del ratón, etc.) y pasa estas
interacciones a la Vista y al Modelo. Ver la figura 6.3.
Ejemplo: La Figura 6.4 muestra la arquitectura de un sistema de aplicaciones basado en web
organizado usando el patrón MVC.
Cuando se usa: Se usa cuando hay varias formas de ver e interactuar con los datos. También se
utiliza cuando se desconocen los requisitos futuros de interacción y presentación de datos.
Ventajas: Permite que los datos cambien independientemente de su representación y viceversa.
Admite la presentación de los mismos datos de diferentes formas con los cambios realizados en
una representación que se muestra en todos ellos.
Desventajas: Puede implicar código adicional y complejidad de código cuando el modelo de datos
y las interacciones son simples.
Arquitectura en capas
Se utiliza para modelar la interconexión de subsistemas.
Organiza el sistema en un conjunto de capas (o máquinas abstractas), cada una de las cuales
proporciona un conjunto de servicios.
Apoya el desarrollo incremental de subsistemas en diferentes capas. Cuando cambia la interfaz
de una capa, solo se ve afectada la capa adyacente.
Sin embargo, a menudo es artificial para estructurar sistemas de esta manera.
El patrón de arquitectura en capas
Descripción: Organiza el sistema en capas con la funcionalidad relacionada asociada con cada
capa. Una capa proporciona servicios a la capa superior, por lo que las capas de nivel más bajo
representan servicios básicos que probablemente se utilizarán en todo el sistema. Ver figura 6.6.
Ejemplo: Un modelo en capas de un sistema para compartir documentos con derechos de autor
que se encuentran en diferentes bibliotecas, como se muestra en la Figura 6.7.
Cuando se usa: Se usa cuando se construyen nuevas instalaciones sobre sistemas existentes;
cuando el desarrollo se distribuye entre varios equipos y cada equipo es responsable de una capa
de funcionalidad; cuando existe un requisito de seguridad multinivel.
Ventajas: Permite la sustitución de capas enteras siempre que se mantenga la interfaz. Se pueden
proporcionar instalaciones redundantes (por ejemplo, autenticación) en cada capa para aumentar
la confiabilidad del sistema.
Desventajas: En la práctica, proporcionar una separación limpia entre capas a menudo es difícil y
una capa de nivel alto puede tener que interactuar directamente con capas de nivel inferior en
lugar de a través de la capa inmediatamente debajo de ella. El rendimiento puede ser un problema
debido a los múltiples niveles de interpretación de una solicitud de servicio a medida que se
procesa en cada capa.
Arquitectura del repositorio
Los subsistemas deben intercambiar datos. Esto se puede hacer de dos maneras:
Los datos compartidos se mantienen en una base de datos o repositorio central y todos los
subsistemas pueden acceder a ellos;
Cada subsistema mantiene su propia base de datos y pasa datos explícitamente a otros
subsistemas.
Cuando se van a compartir grandes cantidades de datos, el modelo de repositorio de
intercambio se utiliza con mayor frecuencia, ya que se trata de un mecanismo de intercambio de
datos eficiente.
El patrón del repositorio
Descripción: Todos los datos de un sistema se gestionan en un repositorio central al que pueden
acceder todos los componentes del sistema. Los componentes no interactúan directamente, solo a
través del repositorio.
Ejemplo: La Figura 6.9 es un ejemplo de un IDE en el que los componentes utilizan un depósito de
información de diseño del sistema. Cada herramienta de software genera información que luego
está disponible para ser utilizada por otras herramientas.
Cuando se utiliza: Debe utilizar este patrón cuando tenga un sistema en el que se generen grandes
volúmenes de información que deba almacenarse durante mucho tiempo. También puede usarlo
en sistemas basados en datos donde la inclusión de datos en el repositorio desencadena una
acción o herramienta.
Ventajas: Los componentes pueden ser independientes; no necesitan conocer la existencia de
otros componentes. Los cambios realizados por un componente se pueden propagar a todos los
componentes. Todos los datos se pueden administrar de manera consistente (por ejemplo, las
copias de seguridad se realizan al mismo tiempo), ya que están todos en un solo lugar.
Desventajas: El repositorio es un único punto de falla, por lo que los problemas en el repositorio
afectan a todo el sistema. Puede haber ineficiencias en la organización de toda la comunicación a
través del repositorio. La distribución del repositorio en varios equipos puede resultar difícil.
Arquitectura cliente-servidor
Modelo de sistema distribuido que muestra cómo se distribuyen los datos y el procesamiento en
una variedad de componentes.
Se puede implementar en una sola computadora.
Conjunto de servidores autónomos que brindan servicios específicos como impresión, gestión de
datos, etc.
Conjunto de clientes que recurren a estos servicios.
Red que permite a los clientes acceder a los servidores.
El patrón Cliente-servidor
Descripción: En una arquitectura cliente-servidor, la funcionalidad del sistema se organiza en
servicios, y cada servicio se entrega desde un servidor separado. Los clientes son usuarios de estos
servicios y acceden a los servidores para hacer uso de ellos.
Ejemplo: La Figura 6.11 es un ejemplo de una biblioteca de películas y videos / DVD organizada
como un sistema cliente-servidor.
Cuando se usa: Se usa cuando se debe acceder a los datos de una base de datos compartida desde
una variedad de ubicaciones. Debido a que los servidores se pueden replicar, también se pueden
usar cuando la carga en un sistema es variable.
Ventajas: La principal ventaja de este modelo es que los servidores se pueden distribuir a través
de una red. La funcionalidad general (por ejemplo, un servicio de impresión) puede estar
disponible para todos los clientes y no es necesario que todos los servicios la implementen.
Desventajas: Cada servicio es un punto único de falla, por lo que es susceptible a ataques de
denegación de servicio o fallas del servidor. El rendimiento puede ser impredecible porque
depende tanto de la red como del sistema. Pueden ser problemas de administración si los
servidores son propiedad de diferentes organizaciones.
Arquitectura de tuberías y filtros
Las transformaciones funcionales procesan sus entradas para producir salidas.
Puede denominarse modelo de tubería y filtro (como en el shell de UNIX).
Las variantes de este enfoque son muy comunes. Cuando las transformaciones son secuenciales,
se trata de un modelo secuencial por lotes que se utiliza ampliamente en los sistemas de
procesamiento de datos.
No es realmente adecuado para sistemas interactivos.
La tubería y el patrón de filtro
Descripción: El procesamiento de los datos en un sistema está organizado de manera que cada
componente de procesamiento (filtro) sea discreto y lleve a cabo un tipo de transformación de
datos. Los datos fluyen (como en una tubería) de un componente a otro para su procesamiento.
Ejemplo: La Figura 6.13 es un ejemplo de un sistema de tubería y filtro utilizado para procesar
facturas.
Cuando se usa: Se usa comúnmente en aplicaciones de procesamiento de datos (tanto en lotes
como en transacciones) donde las entradas se procesan en etapas separadas para generar salidas
relacionadas.
Ventajas: Fácil de entender y admite la reutilización de la transformación. El estilo del flujo de
trabajo coincide con la estructura de muchos procesos comerciales. La evolución mediante la
adición de transformaciones es sencilla. Puede implementarse como un sistema secuencial o
concurrente.
Desventajas: El formato para la transferencia de datos debe acordarse entre las transformaciones
comunicantes. Cada transformación debe analizar su entrada y descomprimir su salida en la forma
acordada. Esto aumenta la sobrecarga del sistema y puede significar que es imposible reutilizar
transformaciones funcionales que usan estructuras de datos incompatibles.
Arquitecturas de aplicaciones
Los sistemas de aplicaciones están diseñados para satisfacer una necesidad organizativa.
Dado que las empresas tienen mucho en común, sus sistemas de aplicación también tienden a
tener una arquitectura común que refleja los requisitos de la aplicación.
Una arquitectura de aplicación genérica es una arquitectura para un tipo de sistema de software
que puede configurarse y adaptarse para crear un sistema que cumpla con requisitos específicos.
Uso de arquitecturas de aplicaciones
Como punto de partida para el diseño arquitectónico.
Como lista de verificación de diseño.
Como forma de organizar el trabajo del equipo de desarrollo.
Como medio de evaluar componentes para su reutilización.
Como vocabulario para hablar sobre tipos de aplicaciones.
Ejemplos de tipos de aplicaciones
Aplicaciones de procesamiento de datos
Aplicaciones basadas en datos que procesan datos en lotes sin la intervención explícita del usuario
durante el procesamiento.
Aplicaciones de procesamiento de transacciones
Aplicaciones centradas en datos que procesan las solicitudes de los usuarios y actualizan la
información en una base de datos del sistema.
Sistemas de procesamiento de eventos
Aplicaciones donde las acciones del sistema dependen de la interpretación de eventos del entorno
del sistema.
Sistemas de procesamiento del lenguaje
Aplicaciones donde las intenciones de los usuarios se especifican en un lenguaje formal que es
procesado e interpretado por el sistema.
Ejemplos de tipos de aplicaciones
Dos arquitecturas de aplicaciones genéricas muy utilizadas son los sistemas de procesamiento de
transacciones y los sistemas de procesamiento de lenguaje.
Sistemas de procesamiento de transacciones
Sistemas de comercio electrónico;
Sistemas de reserva.
Sistemas de procesamiento del lenguaje
Compiladores;
Intérpretes de comando.
Sistemas de procesamiento de transacciones
Procesar las solicitudes de información de los usuarios de una base de datos o las solicitudes
para actualizar la base de datos.
Desde la perspectiva del usuario, una transacción es:
Cualquier secuencia coherente de operaciones que satisfaga un objetivo; Por ejemplo, busque los
horarios de los vuelos de Londres a París. Los usuarios realizan solicitudes de servicio asincrónicas
que luego son procesadas por un administrador de transacciones.
Arquitectura de los sistemas de información
Los sistemas de información tienen una arquitectura genérica que puede organizarse como una
arquitectura en capas.
Estos son sistemas basados en transacciones, ya que la interacción con estos sistemas
generalmente involucra transacciones de bases de datos.
Las capas incluyen: La interfaz de usuario Comunicaciones de usuario Recuperación de
información Base de datos del sistema.
Sistemas de información basados en la web
Los sistemas de gestión de la información y los recursos ahora suelen ser sistemas basados en la
web en los que las interfaces de usuario se implementan mediante un navegador web.
Por ejemplo, los sistemas de comercio electrónico son sistemas de gestión de recursos basados
en Internet que aceptan pedidos electrónicos de bienes o servicios y luego organizan la entrega de
estos bienes o servicios al cliente.
En un sistema de comercio electrónico, la capa específica de la aplicación incluye una
funcionalidad adicional que admite un "carrito de compras" en el que los usuarios pueden colocar
varios artículos en transacciones independientes y luego pagarlos todos juntos en una sola
transacción.
Implementación del servidor
Estos sistemas a menudo se implementan como arquitecturas / servidores cliente de múltiples
niveles (discutido en el Capítulo 17)
El servidor web es responsable de todas las comunicaciones de usuario, con la interfaz de
usuario implementada usando un navegador web; El servidor de aplicaciones es responsable de
implementar la lógica específica de la aplicación, así como las solicitudes de almacenamiento y
recuperación de información; El servidor de la base de datos mueve información hacia y desde la
base de datos y maneja la gestión de transacciones.
Sistemas de procesamiento del lenguaje
Aceptar un lenguaje natural o artificial como entrada y generar alguna otra representación de
ese lenguaje.
Puede incluir un intérprete para actuar según las instrucciones en el idioma que se está
procesando.
Se utiliza en situaciones donde la forma más fácil de resolver un problema es describir un
algoritmo o describir los datos del sistema. Las herramientas de meta-caso procesan
descripciones de herramientas, reglas de métodos, etc. y generan herramientas.
Componentes del compilador
Un analizador léxico, que toma tokens del lenguaje de entrada y los convierte a un formato
interno.
Una tabla de símbolos, que contiene información sobre los nombres de las entidades (variables,
nombres de clases, nombres de objetos, etc.) utilizados en el texto que se está traduciendo.
Un analizador de sintaxis, que comprueba la sintaxis del idioma que se está traduciendo.
Un árbol de sintaxis, que es una estructura interna que representa el programa que se está
compilando.
Componentes del compilador
Un analizador semántico que usa información del árbol de sintaxis y la tabla de símbolos para
verificar la corrección semántica del texto del idioma de entrada.
Un generador de código que "recorre" el árbol de sintaxis y genera código de máquina abstracto.
Puntos clave
Una arquitectura de software es una descripción de cómo está organizado un sistema de
software.
Las decisiones de diseño arquitectónico incluyen decisiones sobre el tipo de aplicación, la
distribución del sistema y los estilos arquitectónicos que se utilizarán.
Las arquitecturas se pueden documentar desde varias perspectivas o vistas diferentes, como una
vista conceptual, una vista lógica, una vista de proceso y una vista de desarrollo.
Los patrones arquitectónicos son un medio de reutilizar el conocimiento sobre arquitecturas de
sistemas genéricos. Describen la arquitectura, explican cuándo se puede utilizar y describen sus
ventajas y desventajas.
Los modelos de arquitecturas de sistemas de aplicaciones nos ayudan a comprender y comparar
aplicaciones, validar diseños de sistemas de aplicaciones y evaluar componentes a gran escala para
su reutilización. Los sistemas de procesamiento de transacciones son sistemas interactivos que
permiten que varios usuarios accedan y modifiquen de forma remota la información de una base
de datos.
Los sistemas de procesamiento de idiomas se utilizan para traducir textos de un idioma a otro y
para llevar a cabo las instrucciones especificadas en el idioma de entrada. Incluyen un traductor y
una máquina abstracta que ejecuta el lenguaje generado.