Técnicas de Arquitectura
Enfoque iterativo e incremental
Es un enfoque iterativo e incremental que consta de cinco pasos principales que ayudan a generar soluciones candidatas. Esta solución candidata se puede refinar aún más repitiendo estos pasos y finalmente crear un diseño de arquitectura que se adapte mejor a nuestra aplicación. Al final del proceso, podemos revisar y comunicar nuestra arquitectura a todas las partes interesadas.
Es solo un enfoque posible. Hay muchos otros enfoques más formales que definen, revisan y comunican su arquitectura.
Identificar el objetivo de la arquitectura
Identificar el objetivo de la arquitectura que forma el proceso de arquitectura y diseño. Los objetivos impecables y definidos hacen hincapié en la arquitectura, resuelven los problemas correctos en el diseño y ayudan a determinar cuándo se ha completado la fase actual y están listos para pasar a la siguiente fase.
Este paso incluye las siguientes actividades:
- Identifique sus objetivos de arquitectura desde el principio.
- Identificar al consumidor de nuestra arquitectura.
- Identifica las limitaciones.
Los ejemplos de actividades de arquitectura incluyen la construcción de un prototipo para obtener comentarios sobre la interfaz de usuario de procesamiento de pedidos para una aplicación web, la construcción de una aplicación de seguimiento de pedidos del cliente y el diseño de la arquitectura de autenticación y autorización para una aplicación con el fin de realizar una revisión de seguridad.
Escenarios clave
Este paso pone énfasis en el diseño que más importa. Un escenario es una descripción extensa y que cubre la interacción de un usuario con el sistema.
Los escenarios clave son aquellos que se consideran los escenarios más importantes para el éxito de su aplicación. Ayuda a tomar decisiones sobre la arquitectura. El objetivo es lograr un equilibrio entre los objetivos del usuario, la empresa y el sistema. Por ejemplo, la autenticación de usuario es un escenario clave porque es una intersección de un atributo de calidad (seguridad) con una funcionalidad importante (cómo un usuario inicia sesión en su sistema).
Descripción general de la aplicación
Cree una descripción general de la aplicación, lo que hace que la arquitectura sea más accesible, conectándola a las restricciones y decisiones del mundo real. Consta de las siguientes actividades:
Identificar el tipo de aplicación
Identifique el tipo de aplicación, ya sea una aplicación móvil, un cliente enriquecido, una aplicación de Internet enriquecida, un servicio, una aplicación web o alguna combinación de estos tipos.
Identificar las restricciones de implementación
Elija una topología de implementación adecuada y resuelva los conflictos entre la aplicación y la infraestructura de destino.
Identificar estilos de diseño arquitectónicos importantes
Identifique estilos de diseño de arquitectura importantes, como cliente / servidor, en capas, bus de mensajes, diseño controlado por dominios, etc. para mejorar la partición y promover la reutilización del diseño al proporcionar soluciones a problemas que se repiten con frecuencia. Las aplicaciones suelen utilizar una combinación de estilos.
Identificar las tecnologías relevantes
Identifique las tecnologías relevantes considerando el tipo de aplicación que estamos desarrollando, nuestras opciones preferidas para la topología de implementación de aplicaciones y los estilos arquitectónicos. La elección de tecnologías también estará dirigida por las políticas de la organización, las limitaciones de la infraestructura, las habilidades de recursos, etc.
Problemas clave o puntos clave
Al diseñar una aplicación, los puntos calientes son las zonas donde se cometen errores con mayor frecuencia. Identificar problemas clave basados en atributos de calidad y preocupaciones transversales. Los problemas potenciales incluyen la aparición de nuevas tecnologías y requisitos comerciales críticos.
Los atributos de calidad son las características generales de su arquitectura que afectan el comportamiento en tiempo de ejecución, el diseño del sistema y la experiencia del usuario. Las preocupaciones transversales son las características de nuestro diseño que pueden aplicarse a todas las capas, componentes y niveles.
Estas son también las áreas en las que se cometen con mayor frecuencia errores de diseño de alto impacto. Ejemplos de preocupaciones transversales son autenticación y autorización, comunicación, gestión de la configuración, gestión y validación de excepciones, etc.
Soluciones candidatas
Después de definir los puntos clave, cree la arquitectura de referencia inicial o el primer diseño de alto nivel y luego comience a completar los detalles para generar la arquitectura candidata.
La arquitectura candidata incluye el tipo de aplicación, la arquitectura de implementación, el estilo arquitectónico, las opciones de tecnología, los atributos de calidad y las preocupaciones transversales. Si la arquitectura candidata es una mejora, puede convertirse en la línea de base a partir de la cual se pueden crear y probar nuevas arquitecturas candidatas.
Valide el diseño de la solución candidata contra los escenarios y requisitos clave que ya se han definido, antes de seguir iterativamente el ciclo y mejorar el diseño.
Podemos utilizar picos arquitectónicos para descubrir áreas específicas del diseño o para validar nuevos conceptos. Los picos arquitectónicos son un prototipo de diseño, que determinan la viabilidad de una ruta de diseño específica, reducen el riesgo y determinan rápidamente la viabilidad de diferentes enfoques. Pruebe los picos arquitectónicos en escenarios clave y puntos de acceso.
Revisión de arquitectura
La revisión de la arquitectura es la tarea más importante para reducir el costo de los errores y para encontrar y solucionar los problemas arquitectónicos lo antes posible. Es una forma rentable y bien establecida de reducir los costos del proyecto y las posibilidades de que el proyecto fracase.
Revise la arquitectura con frecuencia en los principales hitos del proyecto y en respuesta a otros cambios arquitectónicos importantes.
El objetivo principal de una revisión de arquitectura es determinar la viabilidad de arquitecturas de línea base y candidatas, que verifican la arquitectura correctamente.
Vincula los requisitos funcionales y los atributos de calidad con la solución técnica propuesta. También ayuda a identificar problemas y reconocer áreas de mejora.
Las evaluaciones basadas en escenarios son un método dominante para revisar un diseño de arquitectura que se enfoca en los escenarios que son más importantes desde la perspectiva empresarial y que tienen el mayor impacto en la arquitectura. A continuación se presentan las metodologías de revisión comunes:
Método de análisis de arquitectura de software (SAAM)
Originalmente está diseñado para evaluar la modificabilidad, pero luego se amplió para revisar la arquitectura con respecto a los atributos de calidad.
Método de análisis de compensación de arquitectura (ATAM)
Es una versión pulida y mejorada de SAAM, que revisa las decisiones arquitectónicas con respecto a los requisitos de atributos de calidad y qué tan bien satisfacen objetivos de calidad particulares.
Revisión de diseño activo (ADR)
Es más adecuado para arquitecturas incompletas o en progreso, que se centran más en un conjunto de problemas o secciones individuales de la arquitectura a la vez, en lugar de realizar una revisión general.
Revisiones activas de diseños intermedios (ARID)
Combina el aspecto ADR de la revisión de la arquitectura en curso con un enfoque en un conjunto de cuestiones, y el enfoque ATAM y SAAM de revisión basada en escenarios centrados en atributos de calidad.
Método de análisis de costo-beneficio (CBAM)
Se centra en analizar los costos, los beneficios y las implicaciones de programación de las decisiones arquitectónicas.
Análisis de modificabilidad a nivel de arquitectura (ALMA)
Estima la modificabilidad de la arquitectura para los sistemas de información empresarial (BIS).
Método de evaluación de arquitectura familiar (FAAM)
Estima las arquitecturas de la familia de sistemas de información para la interoperabilidad y la extensibilidad.
Comunicando el diseño de la arquitectura
Después de completar el diseño de la arquitectura, debemos comunicar el diseño a las otras partes interesadas, que incluyen al equipo de desarrollo, administradores de sistemas, operadores, propietarios de negocios y otras partes interesadas.
Existen varios métodos conocidos siguientes para describir la arquitectura a otros: -
Modelo 4 + 1
Este enfoque utiliza cinco vistas de la arquitectura completa. Entre ellos, cuatro vistas (ellogical view, la process view, la physical view, y el development view) describen la arquitectura desde diferentes enfoques. Una quinta vista muestra los escenarios y casos de uso del software. Permite a las partes interesadas ver las características de la arquitectura que les interesan específicamente.
Lenguaje de descripción de arquitectura (ADL)
Este enfoque se utiliza para describir la arquitectura del software antes de la implementación del sistema. Aborda las siguientes preocupaciones: comportamiento, protocolo y conector.
La principal ventaja de ADL es que podemos analizar la arquitectura en cuanto a integridad, coherencia, ambigüedad y rendimiento antes de comenzar formalmente el uso del diseño.
Modelado ágil
Este enfoque sigue el concepto de que "el contenido es más importante que la representación". Asegura que los modelos creados sean simples y fáciles de entender, suficientemente precisos, detallados y consistentes.
Los documentos modelo ágiles se dirigen a clientes específicos y cumplen con los esfuerzos laborales de ese cliente. La simplicidad del documento asegura que haya una participación activa de las partes interesadas en el modelado del artefacto.
IEEE 1471
IEEE 1471 es el nombre corto de un estándar formalmente conocido como ANSI / IEEE 1471-2000, "Práctica recomendada para la descripción de la arquitectura de sistemas intensivos en software". IEEE 1471 mejora el contenido de una descripción arquitectónica, en particular, dando un significado específico al contexto, las vistas y los puntos de vista.
Lenguaje unificado de modelado UML)
Este enfoque representa tres vistas de un modelo de sistema. losfunctional requirements view (requisitos funcionales del sistema desde el punto de vista del usuario, incluidos los casos de uso); the static structural view(objetos, atributos, relaciones y operaciones, incluidos los diagramas de clases); y eldynamic behavior view (colaboración entre objetos y cambios en el estado interno de los objetos, incluidos diagramas de secuencia, actividad y estado).