¿Qué es la arquitectura de software? ¿Hay alguna explicación específica?

La arquitectura de software es un conjunto de patrones abstractos relacionados que se utilizan para guiar el diseño de todos los aspectos de grandes sistemas de software. La arquitectura del software es un bosquejo de un sistema. La arquitectura de software describe los componentes abstractos que constituyen directamente un sistema. Las conexiones entre componentes describen la comunicación entre componentes de forma explícita y relativamente detallada. Durante la fase de implementación, estos componentes abstractos se refinan hasta convertirlos en componentes reales, como clases u objetos específicos. En el mundo orientado a objetos, las conexiones entre componentes generalmente se implementan mediante interfaces_(Informática).

La arquitectura del software es la base para la construcción de prácticas de software informático. Así como un arquitecto establece los principios y objetivos de diseño de un proyecto de construcción como base para los dibujos de un dibujante, un arquitecto de software o arquitecto de sistemas establece la arquitectura de software como base para diseñar sistemas reales que satisfagan las diferentes necesidades de los clientes.

La arquitectura de software es un concepto fácil de entender que la mayoría de los ingenieros, especialmente los menos experimentados, reconocen intuitivamente, pero definirlo con precisión es difícil. En particular, es difícil distinguir claramente entre diseño y arquitectura: la arquitectura es un aspecto del diseño que se centra en alguna funcionalidad específica.

En el libro "Introducción a la Arquitectura de Software", David Garrlan y Mary Shaw consideran la arquitectura de software como un nivel de diseño que aborda las siguientes cuestiones: "Además de los algoritmos y estructuras de datos utilizados para la computación También existe un nuevo problema de diseño y definición de la estructura general del sistema. Las cuestiones arquitectónicas incluyen la estructura organizativa general y la estructura de control global; los protocolos de comunicación, sincronización y acceso a datos; la distribución física de los elementos; elementos; calibración y rendimiento; y la selección de diseños alternativos.

Pero la arquitectura es más que estructura; entorno" [IEEE98]. "Conformidad" con la integridad del sistema, las limitaciones económicas, las necesidades estéticas y el estilo. No sólo se centra en factores internos, sino que también considera el sistema como un todo, sus usuarios y el entorno de desarrollo, es decir, también se centra en factores externos.

En Rational Unified ProcES, la arquitectura de un sistema de software (en un punto dado) es la organización o estructura de los componentes importantes del sistema que interactúan a través de interfaces con un número decreciente de componentes y las interfaces que componen los componentes.

La arquitectura de software se puede comparar con la arquitectura de un edificio en términos de su conexión con el propósito, el tema, los materiales y la estructura. Conocimiento y experiencia correspondiente para llevar a cabo el diseño de alto nivel de productos de software. Los arquitectos de software necesitan definir y diseñar la modularidad del software, las interacciones entre módulos, los estilos de interfaz de usuario, los métodos de interfaz externa, las características de diseño innovadoras y el alto nivel. operaciones, lógica y procesos de objetos.

En términos generales, la arquitectura de un sistema de software (Arquitectura) contiene dos elementos:

- Es la división de más alto nivel de un sistema de software. el todo a sus partes.

Un sistema generalmente consta de múltiples componentes, cómo estos componentes se forman e interactúan entre sí es información importante sobre la estructura del sistema en sí. > Específicamente, esto incluye los componentes arquitectónicos, los conectores y los flujos de tareas que conforman el sistema, mientras que los conectores describen las rutas de comunicación, los mecanismos y los resultados esperados entre estos componentes, y los flujos de tareas describen cómo los utiliza el sistema. estos componentes y conectores para cumplir con los requisitos.

- Las decisiones comerciales y técnicas de más alto nivel, difíciles de modificar, que se toman para construir un sistema.

Es necesario tomar muchas decisiones importantes. antes de construir un sistema, y ​​estas decisiones deben tomarse una vez que el sistema está diseñado en detalle o incluso construido. Es difícil o imposible cambiar. Obviamente, estas decisiones deben ser las más importantes relacionadas con el éxito o el fracaso del sistema. diseño de sistemas y, por lo tanto, debe estudiarse y examinarse con mucho cuidado

Historia

A principios de la década de 1960, E. W. Dykstra y otros ya habían propuesto el concepto de arquitectura de software. En parte debido a las actividades relacionadas de Rational Software Corporation y MiCROSoft, el concepto de arquitectura de software se ha vuelto popular.

La Universidad Carnegie Mellon y la Universidad de California en Irvine han realizado muchas investigaciones en esta área. Mary Shaw y David Garlan de la Universidad Carnegie Mellon escribieron un libro llamado "La disciplina DI emergente desde una perspectiva de arquitectura de software" en 1996. El libro introdujo muchos conceptos en arquitectura de software, como componentes de software, conectores, estilos, etc. El trabajo en el Software Institute de UC Irvine se centra en estilos arquitectónicos, lenguajes de descripción de arquitectura y arquitecturas dinámicas.

La historia del software informático comenzó en la década de 1950. En comparación con la historia de la ingeniería de la construcción, la historia del software informático es muy corta, mientras que la historia de la ingeniería de la construcción comenzó en la Edad de Piedra y se ha practicado durante mucho tiempo. miles de años Se han acumulado muchas experiencias y lecciones. El diseño arquitectónico incluye básicamente dos puntos, uno es el estilo arquitectónico y el otro es el modo arquitectónico. Los estilos arquitectónicos únicos y los patrones de construcción apropiados pueden dar como resultado edificios únicos.

La imagen de abajo es el antiguo edificio maya en Centroamérica: la Gran Pirámide de Chichén Itzá. Tiene nueve enormes capas de piedra apiladas una encima de la otra (que simbolizan las cuatro estaciones y los días). ) corre hacia la cima de la torre. El templo se eleva hacia el cielo. Todos los números son tan rigurosos y majestuosos como un calendario. Es difícil imaginar que se trate de un edificio de la Edad de Piedra.

Figura 1, el antiguo edificio maya en Chichén Itasa, México (chi significa boca en maya y chen significa pozo). (Fotografía: Autor)

La relación entre el software y los humanos es un tema central que los arquitectos deben enfrentar y ha existido desde que el software entró en los libros de historia. Asimismo, la relación entre la arquitectura y los humanos ha sido un tema central al que se enfrentan los arquitectos desde el nacimiento de la arquitectura. El Primer Ministro británico Winston Churchill dijo que nosotros damos forma a nuestros edificios y nuestros edificios nos dan forma a nosotros. La cámara de la Cámara de los Comunes es demasiado estrecha para que todos los diputados se sienten en la misma dirección, por lo que tienen que sentarse en ambos lados. Churchill creía que los miembros del Congreso naturalmente elegirían para sentarse a aquellos que compartieran sus opiniones políticas. Este fue el origen del sistema de partidos británico. La clave de los orígenes de los partidos políticos reside en el impacto de los edificios sobre las personas.

Muchas personas en la comunidad de diseño de software creen que la función es lo más importante y que la forma debe seguir a la función. De manera similar, en términos de arquitectura, Louis Sullivan, uno de los fundadores de la escuela de arquitectura modernista, también creía que la forma sigue a la función.

En la vasta historia de la arquitectura, se pueden encontrar ecos en casi todos los conceptos de diseño de software. Las más famosas son, por supuesto, la teoría de patrones y la teoría XP.

¿Cuáles son los objetivos de la arquitectura?

Al igual que los objetivos que el propio software necesita alcanzar, ¿cuáles son los objetivos del diseño arquitectónico? En términos generales, el diseño de la arquitectura de software debe alcanzar los siguientes objetivos:

- Fiabilidad. Los sistemas de software son extremadamente importantes para las operaciones y la gestión empresarial de los usuarios, por lo que los sistemas de software deben ser muy confiables.

- Seguridad. Las transacciones realizadas por el sistema de software tienen un valor comercial altísimo, por lo que la seguridad del sistema es muy importante.

- ESCalable. El software debe poder mantener un rendimiento razonable a pesar del rápido crecimiento en el uso y el número de usuarios. Sólo así podrá satisfacer a los usuarios con la posibilidad de ampliar el mercado.

- Personalizable (CuSTomizable). El mismo software se puede adaptar a diferentes segmentos de clientes y necesidades cambiantes del mercado.

- Escalabilidad. Los sistemas de software deben permitir la introducción de nuevas tecnologías disponibles, ampliando así la funcionalidad y el rendimiento de los sistemas existentes

- Mantenibilidad (MAIntainable). El mantenimiento de los sistemas de software incluye dos aspectos: eliminar los errores existentes y reflejar nuevos requisitos de software en los sistemas existentes. Los sistemas fáciles de mantener reducen los costos de soporte técnico

-Experiencia del cliente. Los sistemas de software deben ser fáciles de usar.

- Time to market. Los usuarios de software enfrentan competencia de sus pares, y los proveedores de software también enfrentan competencia de sus pares. Es importante competir por las primeras oportunidades en el mercado lo más rápido posible.

Tipos de Arquitectura

La arquitectura se puede dividir en tres tipos, según nuestra perspectiva:

- Arquitectura lógica, es decir, en un sistema software La relación entre componentes, como interfaz de usuario, base de datos, interfaz de sistema externo, componentes de lógica empresarial, etc.

Por ejemplo, el siguiente es el diagrama de arquitectura lógica de un sistema de software que he experimentado personalmente

Figura 2, ejemplo de arquitectura lógica

Como puede ser Como se ve en la figura anterior, el sistema está dividido en tres capas lógicas, a saber, capa de presentación, capa empresarial y capa de persistencia de datos. Cada nivel contiene múltiples componentes lógicos. Por ejemplo, en la capa del servidor WEB hay componentes de servicio HTML, componentes de servicio de sesión, componentes de servicio de seguridad, componentes de administración del sistema, etc.

- Arquitectura física, es decir, cómo se colocan los componentes de software en el hardware.

Por ejemplo, el siguiente diagrama de arquitectura física describe la arquitectura física de los sistemas distribuidos de Beijing y Shanghai, en los que todos los componentes son dispositivos físicos, incluidos grifos de red, servidores proxy, servidores web, servidores de aplicaciones y sistemas de informes. Servidores, servidor integrado, servidor de almacenamiento, host, etc.

Figura 3 Ejemplo de arquitectura física

- Arquitectura del sistema, es decir, las características no funcionales del sistema, como escalabilidad, confiabilidad, robustez, flexibilidad, rendimiento, etc.

El diseño de la arquitectura del sistema requiere que los arquitectos tengan una sólida comprensión de las funciones y el rendimiento del software y el hardware. Este trabajo es sin duda el más difícil en el trabajo de diseño de arquitectura.

Además, dos elementos de la arquitectura son visibles desde todos los ángulos: la partición de componentes y las decisiones de diseño.

En primer lugar, los componentes del sistema de software son, ante todo, componentes lógicos. Cómo se colocan estos componentes lógicos en el hardware y cómo contribuyen a la escalabilidad, confiabilidad, solidez, flexibilidad y rendimiento del sistema en general es información muy importante.

En segundo lugar, las decisiones que debe tomar al diseñar software deben incluir la estructura lógica, la estructura física y cómo afectan todas las características no funcionales del sistema. Muchas de estas decisiones, una vez tomadas, son difíciles de cambiar.

Según la experiencia del autor, el número de documentos de diseño arquitectónico para una arquitectura de sistema basado en bases de datos es tanto como el número de páginas de tablas de datos. Por ejemplo, una aplicación de base de datos de tamaño mediano normalmente contiene alrededor de cien tablas de datos, y diseñar un sistema de este tipo normalmente requiere alrededor de cien páginas de documentos de diseño arquitectónico.

Descripción de la arquitectura

Para discutir y analizar la arquitectura del software, primero debe definir una notación arquitectónica, un método para describir aspectos importantes de la arquitectura. Durante el proceso de unificación de Rational, esta descripción se documenta en el documento de arquitectura de software.

Vistas arquitectónicas

Decidimos utilizar múltiples vistas arquitectónicas para representar la arquitectura del software. Cada vista arquitectónica apunta a un aspecto específico de interés para quienes participan en el proceso de desarrollo (como usuarios finales, diseñadores, administradores, ingenieros de sistemas, mantenedores, etc.).

La vista arquitectónica documenta las principales decisiones de diseño arquitectónico mostrando cómo la arquitectura del software se divide en componentes y cómo los componentes se conectan a través de conectores para producir formas útiles [PW92]. Estas decisiones de diseño deben basarse en los requisitos, así como en la funcionalidad, la complementariedad y otras limitaciones. A su vez, estas decisiones imponen restricciones adicionales a los requisitos y futuras decisiones de diseño en niveles inferiores.

Un conjunto típico de vistas arquitectónicas

Una arquitectura está representada por una serie de vistas arquitectónicas diferentes, que son básicamente resúmenes gráficos de los elementos del modelo "arquitectónicamente significativos". En el proceso de Unificación Racional, se comienza con un conjunto típico de vistas llamado "Modelo de Vista 4+1" [KRU95]. Incluye:

Vista de casos de uso: incluye casos de uso y escenarios que incluyen comportamientos, clases o riesgos técnicos que son arquitectónicamente importantes. Es un subconjunto del modelo de casos de uso.

Vista lógica: incluye las clases de diseño más importantes, la organización desde estas clases de diseño hasta paquetes y subsistemas, y la organización desde estos paquetes y subsistemas hasta capas. También incluye algunas implementaciones de casos de uso. Es un subconjunto de modelos de diseño.

Vista de Implementación: Incluye una descripción general del modelo de implementación y su organización desde módulos hasta paquetes y capas. También describe el proceso de asignación de paquetes y clases en la vista lógica a paquetes y módulos en la vista de implementación. Es un subconjunto del modelo de implementación.

Vista de procesos: incluye una descripción de las tareas relacionadas (procesos y subprocesos), sus interacciones y configuraciones, y la asignación de objetos y clases de diseño a las tareas. Esta vista sólo es necesaria si el sistema tiene un alto grado de paralelismo.

En el Proceso Unificado Racional, es un subconjunto del modelo de diseño.

Vista de configuración: incluye descripciones de varios nodos físicos para las configuraciones de plataforma más típicas, así como asignaciones de tareas a los nodos físicos (desde la vista de procesos). Esta vista solo es necesaria en sistemas distribuidos. Es un subconjunto del modelo de implementación.

La vista arquitectónica se registra en el documento de arquitectura del software. Puede crear otras vistas para expresar diferentes aspectos que requieren atención especial: vistas de interfaz de usuario, vistas de seguridad, vistas de datos, etc. Para sistemas simples, puede omitir ciertas vistas en el modelo de vista 4+1.

Enfoque arquitectónico

Aunque las vistas anteriores pueden representar el diseño general del sistema, la arquitectura solo está relacionada con algunos aspectos específicos:

La estructura del modelo, es decir, el patrón organizativo, como la estructura jerárquica.

Elementos básicos, es decir, casos de uso clave, clases principales, mecanismos comunes, etc., que corresponden a los elementos del modelo.

Varios esquemas clave, que representan los principales procesos de control de todo el sistema.

Servicios que documentan el grado de modularidad, características opcionales y estado de la línea de productos.

Las vistas arquitectónicas son esencialmente abstracciones o simplificaciones del diseño general. Destacan características importantes descartando detalles específicos. Estas capacidades son importantes al considerar:

Evolución del sistema, es decir, pasar al siguiente ciclo de desarrollo.

Reutilizar arquitectura o partes de arquitectura en un entorno de línea de productos.

Evaluar complementariedades como rendimiento, usabilidad, portabilidad y seguridad.

Asignar trabajo de desarrollo a equipos o subcontratistas.

Decida si desea incluir bloques de construcción disponibles comercialmente.

Insertar sistema más amplio.

Patrones arquitectónicos

Los patrones arquitectónicos son soluciones listas para usar a problemas arquitectónicos recurrentes. Un marco arquitectónico o infraestructura arquitectónica (middleware) es un conjunto de componentes sobre los cuales se puede construir una arquitectura. Muchos de los principales desafíos arquitectónicos deben abordarse en un marco o infraestructura y, a menudo, son desafíos de dominios específicos: comando y control, sistemas de información de gestión, sistemas de control, etc.

Ejemplos de patrones arquitectónicos

[BUS96] clasifica los patrones arquitectónicos según las características de los sistemas a los que son más aplicables, con una categoría que involucra cuestiones arquitectónicas más generales. La siguiente tabla enumera las categorías proporcionadas en [BUS96] y los patrones contenidos en estas categorías.

Patrones de categorías

Capas de arquitectura

Tuberías y filtros

Blackboard

Agentes del sistema distribuido

Sistema interactivo modelo-vista-controlador

Representación-abstracción-control

Sistema adaptativo de reflexión

Microkernel

Software La arquitectura es un concepto fácil de entender que la mayoría de los ingenieros (especialmente los menos experimentados) reconocerán intuitivamente, pero es difícil dar una definición precisa. En particular, es difícil hacer una distinción clara entre diseño y arquitectura: la arquitectura es un aspecto del diseño que se centra en alguna funcionalidad específica.

En el libro "Introducción a la arquitectura de software", David Garlan y Mary Shaw creen que la arquitectura de software es el nivel de diseño relacionado con las siguientes cuestiones: "Además de los algoritmos computacionales y las estructuras de datos, la estructura general del sistema El diseño y la determinación de los elementos de diseño también se han convertido en un tema nuevo. Las cuestiones arquitectónicas incluyen la estructura organizativa general y la estructura de control global; protocolos de comunicación, sincronización y acceso a datos; distribución física de los elementos de diseño; calibración y rendimiento; y preparación de opciones de diseño seleccionadas". [GS93]

Pero la arquitectura es más que estructura; el Grupo de Trabajo de Arquitectura IEEE la define como "el concepto de nivel superior de un sistema en su entorno" [IEEE98]. La arquitectura también incluye la "conformidad" con la integridad del sistema, las limitaciones económicas, las necesidades estéticas y el estilo. No solo se centra en factores internos, sino que también considera el sistema en su conjunto, sus usuarios y el entorno de desarrollo, es decir, también se centra en factores externos.

En el proceso de unificación racional, la arquitectura de un sistema de software es (en un punto dado) la organización o estructura de los componentes importantes del sistema que interactúan a través de interfaces con un número cada vez menor de componentes y la interfaces de sus componentes constituyentes.

Para aclarar su significado, dos de estos modos se describen en detalle a continuación; consulte [BUS96] para obtener una descripción completa. Los patrones se expresan en la siguiente forma ampliamente utilizada:

Nombre del patrón

Medio ambiente

Problema

Impacto, que describe las diferencias en los problemas que debe considerarse Aspecto

Solución

Principio básico

Resultado Entorno

Ejemplo

Nombre del patrón

Capa

Medio ambiente

Grandes sistemas que requieren descomposición estructural.

Problemas

Sistemas que deben abordar problemas en diferentes niveles de abstracción. Por ejemplo, problemas de control de hardware, problemas de servicio comunes y problemas específicos en diferentes áreas. Es mejor no escribir artefactos verticales para manejar problemas en todos los niveles de abstracción. De lo contrario, tendrá que lidiar con el mismo problema varias veces en diferentes artefactos (lo que puede ser inconsistente).

Impacto

Algunas partes del sistema deben ser reemplazables

Los cambios en los artefactos no deben fluctuar

Se deben asignar responsabilidades similares según el tamaño de un conjunto de artefactos: es posible que los artefactos complejos deban dividirse en una estructura en capas. Haga que la capa superior utilice únicamente los servicios proporcionados por la capa inferior (nunca utilice la capa superior). Intente no utilizar servicios que no sean proporcionados directamente por la capa inferior (a menos que la capa intermedia solo agregue artefactos de entrega, no puede pasar a utilizar los servicios).

Ejemplo:

1. Capa común

La arquitectura en capas estricta estipula que los elementos de diseño (clases, componentes, paquetes, subsistemas) solo pueden usar los Servicios de la capa inferior. proporcionado, que puede incluir manejo de eventos, manejo de errores, acceso a bases de datos, etc. Incluye mecanismos más obvios que las llamadas a nivel del sistema operativo sin procesar registradas bajo el capó.

2. Capa del sistema empresarial

El diagrama anterior muestra otro ejemplo de capas, que incluye una capa vertical específica de la aplicación, una capa horizontal y una capa de infraestructura. Nota: El objetivo aquí es tener "chimeneas" comerciales muy cortas y lograr puntos comunes entre las aplicaciones. De lo contrario, podría haber varias personas trabajando en el mismo tema, lo que generaría posibles desacuerdos.

Para una discusión en profundidad de este patrón, consulte Guía: Capas.

Nombre del patrón

Pizarra

Entorno

No existe un método (algoritmo) identificado para resolver el problema o áreas donde el método está no es factible. Por ejemplo, sistemas de inteligencia artificial, reconocimiento de voz y sistemas de vigilancia.

Problema

Múltiples consultores de resolución de problemas (consultores de conocimiento) deben colaborar para resolver problemas que no pueden resolver solos. El trabajo de cada consultor debe ponerse a disposición de todos los demás consultores para que puedan evaluar su capacidad de participar en la búsqueda de soluciones y publicar los resultados de su trabajo.

Impacto

El orden en el que los consultores de conocimiento participan en la resolución de problemas no es fijo y puede depender de la estrategia de resolución de problemas.

Los aportes (resultados o parciales) soluciones) de diferentes consultores (soluciones) pueden expresarse de diferentes maneras

Los consultores no conocen directamente la existencia de los demás, pero pueden evaluar el trabajo publicado de cada uno

Soluciones