Principios fundamentales
La arquitectura de software se describe como la organización de un sistema, donde el sistema representa un conjunto de componentes que cumplen las funciones definidas.
Estilo arquitectónico
los architectural style, también llamado como architectural pattern, es un conjunto de principios que da forma a una aplicación. Define un marco abstracto para una familia de sistemas en términos del patrón de organización estructural.
El estilo arquitectónico es responsable de:
Proporcione un léxico de componentes y conectores con reglas sobre cómo se pueden combinar.
Mejore la partición y permita la reutilización del diseño dando soluciones a problemas frecuentes.
Describa una forma particular de configurar una colección de componentes (un módulo con interfaces bien definidas, reutilizables y reemplazables) y conectores (enlace de comunicación entre módulos).
El software creado para sistemas basados en computadora exhibe uno de los muchos estilos arquitectónicos. Cada estilo describe una categoría de sistema que abarca:
Un conjunto de tipos de componentes que realizan una función requerida por el sistema.
Un conjunto de conectores (llamada de subrutina, llamada a procedimiento remoto, flujo de datos y socket) que permiten la comunicación, coordinación y cooperación entre diferentes componentes.
Restricciones semánticas que definen cómo se pueden integrar los componentes para formar el sistema.
Un diseño topológico de los componentes que indica sus interrelaciones en tiempo de ejecución.
Diseño arquitectónico común
La siguiente tabla enumera los estilos arquitectónicos que se pueden organizar por su área de enfoque clave:
| Categoría | Diseño arquitectonico | Descripción |
|---|---|---|
| Comunicación | Bus de mensajes | Prescribe el uso de un sistema de software que puede recibir y enviar mensajes usando uno o más canales de comunicación. |
| Arquitectura orientada a servicios (SOA) | Define las aplicaciones que exponen y consumen la funcionalidad como un servicio mediante contratos y mensajes. | |
| Despliegue | Servidor de cliente | Separe el sistema en dos aplicaciones, donde el cliente realiza solicitudes al servidor. |
| 3 niveles o N niveles | Separa la funcionalidad en segmentos separados y cada segmento es un nivel ubicado en una computadora físicamente separada. | |
| Dominio | Diseño controlado por dominio | Enfocado en modelar un dominio comercial y definir objetos comerciales basados en entidades dentro del dominio comercial. |
| Estructura | Basado en componentes | Divida el diseño de la aplicación en componentes lógicos o funcionales reutilizables que exponen interfaces de comunicación bien definidas. |
| En capas | Divida las preocupaciones de la aplicación en grupos apilados (capas). | |
| Orientado a objetos | Basado en la división de responsabilidades de una aplicación o sistema en objetos, cada uno de los cuales contiene los datos y el comportamiento relevante para el objeto. |
Tipos de Arquitectura
Hay cuatro tipos de arquitectura desde el punto de vista de una empresa y, colectivamente, estas arquitecturas se denominan enterprise architecture.
Business architecture - Define la estrategia de negocios, gobierno, organización y procesos comerciales clave dentro de una empresa y se enfoca en el análisis y diseño de procesos comerciales.
Application (software) architecture - Sirve como modelo para los sistemas de aplicaciones individuales, sus interacciones y sus relaciones con los procesos comerciales de la organización.
Information architecture - Define los activos de datos lógicos y físicos y los recursos de gestión de datos.
Information technology (IT) architecture - Define los bloques de construcción de hardware y software que componen el sistema de información general de la organización.
Proceso de diseño de arquitectura
El proceso de diseño de la arquitectura se centra en la descomposición de un sistema en diferentes componentes y sus interacciones para satisfacer requisitos funcionales y no funcionales. Las entradas clave para el diseño de la arquitectura de software son:
Los requisitos producidos por las tareas de análisis.
La arquitectura de hardware (el arquitecto de software a su vez proporciona requisitos al arquitecto del sistema, quien configura la arquitectura de hardware).
El resultado o salida del proceso de diseño de la arquitectura es un architectural description. El proceso de diseño de la arquitectura básica se compone de los siguientes pasos:
Entender el problema
Este es el paso más crucial porque afecta la calidad del diseño que sigue.
Sin una comprensión clara del problema, no es posible crear una solución eficaz.
Muchos proyectos y productos de software se consideran fallas porque en realidad no resolvieron un problema comercial válido o no tienen un retorno de la inversión (ROI) reconocible.
Identificar elementos de diseño y sus relaciones
En esta fase, construya una línea de base para definir los límites y el contexto del sistema.
Descomposición del sistema en sus componentes principales en función de los requisitos funcionales. La descomposición se puede modelar utilizando una matriz de estructura de diseño (DSM), que muestra las dependencias entre los elementos de diseño sin especificar la granularidad de los elementos.
En este paso, la primera validación de la arquitectura se realiza mediante la descripción de una serie de instancias del sistema y este paso se denomina diseño arquitectónico basado en la funcionalidad.
Evaluar el diseño de la arquitectura
A cada atributo de calidad se le da una estimación, por lo que para recopilar medidas cualitativas o datos cuantitativos, se evalúa el diseño.
Implica evaluar la arquitectura para determinar su conformidad con los requisitos de atributos de calidad arquitectónica.
Si todos los atributos de calidad estimados cumplen con el estándar requerido, el proceso de diseño arquitectónico está terminado.
De lo contrario, se ingresa a la tercera fase del diseño de la arquitectura de software: transformación de la arquitectura. Si el atributo de calidad observado no cumple con sus requisitos, se debe crear un nuevo diseño.
Transformar el diseño de la arquitectura
Este paso se realiza después de una evaluación del diseño arquitectónico. El diseño arquitectónico debe cambiarse hasta que satisfaga completamente los requisitos del atributo de calidad.
Se ocupa de seleccionar soluciones de diseño para mejorar los atributos de calidad mientras se preserva la funcionalidad del dominio.
Un diseño se transforma aplicando operadores, estilos o patrones de diseño. Para la transformación, tome el diseño existente y aplique el operador de diseño, como descomposición, replicación, compresión, abstracción y uso compartido de recursos.
El diseño se evalúa nuevamente y el mismo proceso se repite varias veces si es necesario e incluso se realiza de forma recursiva.
Las transformaciones (es decir, las soluciones de optimización de atributos de calidad) generalmente mejoran uno o algunos atributos de calidad mientras afectan a otros de manera negativa
Principios clave de la arquitectura
Los siguientes son los principios clave que se deben considerar al diseñar una arquitectura:
Construir para cambiar en lugar de construir para durar
Considere cómo la aplicación puede necesitar cambiar con el tiempo para abordar nuevos requisitos y desafíos, y desarrolle la flexibilidad para respaldar esto.
Reducir el riesgo y el modelo para analizar
Utilice herramientas de diseño, visualizaciones y sistemas de modelado como UML para capturar requisitos y decisiones de diseño. Los impactos también se pueden analizar. No formalice el modelo en la medida en que suprima la capacidad de iterar y adaptar el diseño fácilmente.
Utilice modelos y visualizaciones como herramienta de comunicación y colaboración
La comunicación eficiente del diseño, las decisiones y los cambios continuos en el diseño es fundamental para una buena arquitectura. Utilice modelos, vistas y otras visualizaciones de la arquitectura para comunicar y compartir el diseño de manera eficiente con todas las partes interesadas. Esto permite una rápida comunicación de los cambios en el diseño.
Identifique y comprenda las decisiones de ingeniería clave y las áreas donde se cometen errores con mayor frecuencia. Invierta en tomar las decisiones clave correctamente la primera vez para hacer que el diseño sea más flexible y menos probable que se rompa con los cambios.
Utilice un enfoque incremental e iterativo
Comience con la arquitectura de referencia y luego desarrolle arquitecturas candidatas mediante pruebas iterativas para mejorar la arquitectura. Agregue iterativamente detalles al diseño en múltiples pasadas para obtener la imagen grande o correcta y luego enfóquese en los detalles.
Principios clave de diseño
A continuación se presentan los principios de diseño que se deben considerar para minimizar el costo, los requisitos de mantenimiento y maximizar la extensibilidad y la usabilidad de la arquitectura:
Separación de intereses
Divida los componentes del sistema en características específicas para que no haya superposición entre la funcionalidad de los componentes. Esto proporcionará una alta cohesión y un bajo acoplamiento. Este enfoque evita la interdependencia entre los componentes del sistema, lo que ayuda a mantener el sistema fácil.
Principio de responsabilidad única
Todos y cada uno de los módulos de un sistema deben tener una responsabilidad específica, que ayude al usuario a comprender claramente el sistema. También debería ayudar con la integración del componente con otros componentes.
Principio de conocimiento mínimo
Ningún componente u objeto debe tener conocimiento sobre los detalles internos de otros componentes. Este enfoque evita la interdependencia y ayuda a la mantenibilidad.
Minimice el diseño grande por adelantado
Minimice el diseño grande por adelantado si los requisitos de una aplicación no están claros. Si existe la posibilidad de modificar los requisitos, evite hacer un diseño grande para todo el sistema.
No repita la funcionalidad
La funcionalidad No repetir especifica que la funcionalidad de los componentes no debe repetirse y, por lo tanto, una parte del código debe implementarse en un solo componente. La duplicación de funciones dentro de una aplicación puede dificultar la implementación de cambios, disminuir la claridad e introducir posibles inconsistencias.
Prefiera la composición sobre la herencia mientras reutiliza la funcionalidad
La herencia crea dependencia entre las clases secundarias y las clases principales y, por lo tanto, bloquea el uso gratuito de las clases secundarias. Por el contrario, la composición proporciona un gran nivel de libertad y reduce las jerarquías de herencia.
Identificar componentes y agruparlos en capas lógicas
Los componentes de identidad y el área de interés que se necesitan en el sistema para satisfacer los requisitos. Luego, agrupe estos componentes relacionados en una capa lógica, lo que ayudará al usuario a comprender la estructura del sistema a un alto nivel. Evite mezclar componentes de diferentes tipos de preocupaciones en la misma capa.
Definir el protocolo de comunicación entre capas
Comprender cómo se comunicarán los componentes entre sí, lo que requiere un conocimiento completo de los escenarios de implementación y el entorno de producción.
Definir formato de datos para una capa
Varios componentes interactuarán entre sí a través del formato de datos. No mezcle los formatos de datos para que las aplicaciones sean fáciles de implementar, ampliar y mantener. Intente mantener el mismo formato de datos para una capa, de modo que varios componentes no necesiten codificar / decodificar los datos mientras se comunican entre sí. Reduce una sobrecarga de procesamiento.
Los componentes del servicio del sistema deben ser abstractos
El código relacionado con la seguridad, las comunicaciones o los servicios del sistema, como el registro, la creación de perfiles y la configuración, debe resumirse en componentes separados. No mezcle este código con la lógica empresarial, ya que es fácil ampliar el diseño y mantenerlo.
Excepciones de diseño y mecanismo de manejo de excepciones
Definir las excepciones de antemano ayuda a los componentes a gestionar errores o situaciones no deseadas de manera elegante. La gestión de excepciones será la misma en todo el sistema.
Convenciones de nombres
Las convenciones de nomenclatura deben definirse de antemano. Proporcionan un modelo coherente que ayuda a los usuarios a comprender el sistema fácilmente. Es más fácil para los miembros del equipo validar el código escrito por otros y, por lo tanto, aumentará la capacidad de mantenimiento.