Tarea: Análisis de la arquitectura
Esta tarea se centra en la definición de una arquitectura candidata y en la restricción de las técnicas de arquitectura que se van a utilizar en el sistema.
Disciplinas: Análisis y diseño
Objetivo
  • Definir una arquitectura candidata para el sistema basada en la experiencia obtenida de sistemas similares o dominios de problemas parecidos.
  • Definir los patrones de arquitectura, los mecanismos clave y los convenios de modelado del sistema.
Relaciones
Descripción principal

El análisis de la arquitectura se centra en la definición de una arquitectura candidata y en la restricción de las técnicas de arquitectura que se van a utilizar en el sistema. Se basa en la recopilación de experiencias obtenidas en sistemas o dominios de problemas similares para restringir y centrar la arquitectura de forma que no se malgaste esfuerzo en el redescubrimiento de arquitecturas. En los sistemas en los que ya hay una arquitectura bien definida, el análisis de la arquitectura se puede omitir. El análisis de arquitecturas resulta beneficioso principalmente cuando se desarrollan sistemas nuevos sin precedentes.

Pasos
Desarrollar una visión general de la arquitectura
Objetivo  Facilitar la visualización del sistema mediante la exploración y la evaluación de opciones de arquitectura de alto nivel. 
Transmitir una primera idea de la estructura de alto nivel del sistema al patrocinador, los equipos de desarrollo y otros interesados.

La visión general de la arquitectura se crea al principio del ciclo vital del proyecto, probablemente durante la fase inicial. Refleja las primeras decisiones y suposiciones de trabajo sobre la implementación de la visión, así como las decisiones sobre la arquitectura física y lógica, y los requisitos no funcionales del sistema. El encargado de producirla es el arquitecto de software, a menudo en colaboración con el patrocinador del proyecto, y tiene la forma de un gráfico de iconos o un guión gráfico informal, con muchas imágenes. Conceptualmente, ilustra la naturaleza de la solución propuesta, a la vez que transmite las ideas gobernantes e incluye los principales bloques de construcción. El nivel de formalidad de la visión general de la arquitectura depende del proyecto. Por ejemplo, en un proyecto grande y esencial, será necesario capturar la visión general de la arquitectura en las secciones correspondientes del documento de arquitectura de software, para que se pueda revisar formalmente.

En este punto, la visión general de la arquitectura es un primer paso provisional. No base ningún compromiso en el diagrama de visión general de la arquitectura hasta que un prototipo de arquitectura ejecutable haya validado la arquitectura, incluidos los problemas de diseño, implementación y despliegue.

También puede basar la arquitectura en una arquitectura de referencia, otros patrones de arquitectura u otros activos de arquitectura.

Considere si desea perfeccionar y mantener el diagrama de visión general de la arquitectura, para que sirva como vehículo de comunicación.

Muchos sistemas están restringidos a desarrollarse y desplegarse en un entorno existente de hardware y software; para estos sistemas, el arquitecto de software recopilará información sobre el entorno actual.

Por ejemplo, en el desarrollo de un sistema de e-business, la siguiente información es pertinente:

  • el diseño físico y lógico de la red existente
  • las bases de datos existentes y el diseño de las bases de datos
  • el entorno web existente (servidores, cortafuegos, etc.)
  • el entorno de servidores existente (configuración, versiones de software, actualizaciones previstas)
  • estándares existentes (red, denominación, protocolos, etc.)

Esta información se puede capturar textualmente o en un Modelo de despliegue.

Inspeccionar los activos disponibles
Objetivo  Identificar los activos que pueden ser relevantes para el proyecto.
Analizar la adecuación entre los activos y los requisitos del proyecto.
Decidir si las áreas del sistema se deben basar en los activos.
Localizar y enumerar los activos que sean reutilizables en el proyecto.
Ejecutar una evaluación preliminar para garantizar que el soporte necesario esté disponible.

Debe entender los requisitos del entorno para el que se consideran los activos, así como el ámbito del sistema y la funcionalidad general necesaria. Busque en la literatura industrial y en las bases de activos de organizaciones para identificar activos o proyectos similares. Existen varios tipos de activos que debe tener en cuenta, por ejemplo, los modelos industriales, las infraestructuras, las clases y la experiencia, entre otros. Deberá valorar si los activos disponibles contribuyen a la solución de los retos clave del proyecto actual y si son compatibles con las restricciones del proyecto.

Puede analizar el grado de adecuación entre los activos y los requisitos del cliente, y considerar si alguno de los requisitos son negociables (para permitir el uso del activo).

Asegúrese de valorar si el activo se puede modificar o ampliar para satisfacer los requisitos, y determine qué intercambio supone, en términos de coste, riesgo y funcionalidad, la adopción del activo.

Por último, deberá decidir básicamente si desea utilizar uno o varios de los activos y documentar el fundamento de esa decisión.

Definir la organización de alto nivel de los subsistemas
Objetivo Crear una estructura inicial para el modelo de diseño.

Cuando el objetivo es realizar la síntesis de arquitectura durante la fase inicial, este paso se excluye de esta tarea.

Normalmente, el modelo de diseño se organiza en capas, un patrón de arquitectura común para moderar los sistemas de gran tamaño. El número de capas no es fijo, sino que varía de situación en situación.

Durante el análisis de la arquitectura, normalmente se centra en las dos capas de alto nivel, esto es, la capa de aplicación y la capa específica de negocios. Éste es el significado de la organización de alto nivel de los subsistemas. Las otras capas de nivel inferior se describen en Tarea: Incorporar elementos de diseño existentes. Si utiliza patrones de arquitectura específicos, los subsistemas se definen alrededor de la plantilla de arquitectura de ese patrón.

Para obtener más información sobre las capas, consulte Directriz de producto de trabajo: Creación de capas.

Identificar abstracciones clave
Objetivo Preparar el análisis mediante la identificación de las abstracciones clave (representación de los conceptos identificados durante las tareas de modelado empresarial, cuando sea aplicable, y las tareas de requisitos) que el sistema debe manejar.

Cuando el objetivo es realizar la síntesis de arquitectura, este paso se ejecuta según sea necesario para guiar al arquitecto de software en la selección de activos para la construcción del Producto de trabajo: Arquitectura de prueba de concepto y para dar soporte a los casos de ejemplo de uso representativos.

Las tareas de requisitos y, cuando sea aplicable, las tareas de modelado empresarial, normalmente ponen al descubierto los conceptos clave que el sistema debe poder manejar; estos conceptos se manifiestan como abstracciones de diseño clave. Gracias al trabajo realizado, no es necesario repetir de nuevo el trabajo de identificación durante la Tarea: Análisis de caso de uso .

Puede aprovechar los conocimientos existentes en la identificación de las clases de análisis de entidades preliminares para representar estas abstracciones clave, basándose en el conocimiento general del sistema como, por ejemplo, los requisitos, el glosario y, en concreto, el modelo de dominio o el modelo de análisis empresarial, si dispone de uno.

Cuando se definen las abstracciones clave, también se definen las relaciones que existen entre las clases de entidad. Presente las abstracciones clave en uno o varios diagramas de clases y cree una breve descripción para cada una. Dependiendo del dominio y la novedad del sistema, los patrones de análisis que capturan muchas de las abstracciones clave necesarias para modelar el sistema puede que existan previamente. El uso de dichos patrones (que se han debido utilizar de forma satisfactoria en el dominio) facilitará considerablemente el trabajo intelectual que supone identificar los conceptos importantes que se deben representar. En [FOW97a], se presentan algunos patrones de análisis que son inmediatamente útiles para modelar sistemas empresariales, pero que se pueden aplicar en otros contextos. Otro ejemplo es el Grupo de gestión de objetos (OMG), que también intenta definir interfaces y protocolos para muchos dominios a través del trabajo de su Comité tecnológico de dominios y las fuerzas de trabajo asociadas. Inevitablemente, este trabajo permite identificar abstracciones importantes en el dominio.

Las clases de análisis identificadas en este punto probablemente cambiarán y evolucionarán durante el curso del proyecto. El objetivo de este paso no es identificar un conjunto de clases que sobrevivan todo el diseño, sino identificar los conceptos clave que el sistema debe manejar. No invierta demasiado tiempo describiendo en detalle las clases de entidad en esta fase inicial, ya que existe el riesgo de identificar clases y relaciones que no se necesiten luego en los casos de uso . Recuerde que encontrará más clases de entidad y relaciones cuando observe los casos de uso .

Identificar iteraciones estereotipadas

Este paso sólo se incluye cuando se lleva a cabo esta tarea durante la fase inicial.

El objetivo de este paso es identificar las interacciones entre abstracciones de clave del sistema que caracterizan o son representativas de tipos de actividad significativos del sistema. Dichas interacciones se capturan como ejecuciones de casos de uso .

Desarrollar una visión general del desarrollo

Objetivo

Proporcionar una base para valorar la viabilidad de la implementación del sistema.
Conocer mejor la distribución geográfica y la complejidad operativa del sistema.
Proporcionar una base para los primeros cálculos de esfuerzos y costes.

Desarrolle una visión general de alto nivel de cómo está desplegado el software. Por ejemplo, determine si será necesario acceder al sistema de forma remota, o si el sistema tiene requisitos que sugieren la distribución entre varios nodos. Algunas de las fuentes de información a considerar son:

  • los usuarios (en las ubicaciones), definidos en Perfiles de usuario (en la Visión) y casos de uso (en el Modelo de caso de uso )
  • la organización de los datos empresariales (en el Modelo de análisis empresarial y el Modelo de diseño, cuando estén disponibles)
  • los requisitos de nivel de servicio (en las Especificaciones suplementarias)
  • las restricciones (en las Especificaciones suplementarias, por ejemplo, los requisitos de la interfaz con sistemas de herencia)

Si se necesita un sistema distribuido no trivial, se puede utilizar un modelo de despliegue para capturar la relación entre los nodos. Este debe incluir la asignación provisional de componentes y datos a los nodos, e indicar cómo acceden los usuarios a los componentes que acceden a los datos. La especificación detallada de los nodos y las conexiones se retrasa, excepto si son importantes para calcular o valorar la viabilidad. Se pueden utilizar los activos existentes, si están disponibles los activos adecuados. Aunque este es el primer modelo de despliegue producido en el proyecto, y se produce rápidamente y a un alto nivel, puede identificar productos de hardware y software reales si son conocidos, o si es importante tomar las decisiones de selección en este momento.

Compruebe que el modelo de despliegue dé soporte a los usuarios (especialmente, a los usuarios en ubicaciones remotas si es necesario) mediante la ejecución casos de uso típicos, teniendo en cuenta las restricciones y los requisitos no funcionales. Compruebe que los nodos y las conexiones sean adecuados para dar soporte a las interacciones entre los componentes de distintos nodos, y entre los componentes y sus datos almacenados.

Identificar mecanismos de análisis
Objetivo Definir los mecanismos de análisis y los servicios que utilizan los diseñadores para dar "vida" a los objetos.

Cuando el objetivo es realizar la síntesis de arquitectura durante la fase inicial, este paso se excluye de esta tarea.

Los mecanismos de análisis se pueden identificar de forma descendente (conocimiento a priori) o ascendente (descubiertos sobre la marcha). En la modalidad descendente, la experiencia guía al arquitecto de software para saber que existen determinados problemas en el dominio y necesitarán un determinado tipo de soluciones. Algunos ejemplos de problemas comunes de arquitectura que se pueden expresar como mecanismos durante el análisis son: persistencia, gestión de transacciones, gestión de anomalías, mensajería y motores de inferencia. El aspecto común a todos ellos es que cada uno constituye una posibilidad general de una amplia clase de sistemas, y cada uno proporciona una funcionalidad que interactúa o da soporte a la funcionalidad de aplicaciones básica. Los mecanismos de análisis dan soporte a las posibilidades de soporte necesarias en los requisitos funcionales básicos del sistema, independientemente de la plataforma en la que estén desplegados o del lenguaje de implementación. Los mecanismos de análisis también se pueden diseñar e implementar de varias formas; generalmente, habrá más de un mecanismo de diseño correspondiente a cada mecanismo de análisis, y quizás más de una forma de implementar cada mecanismo de diseño.

El enfoque ascendente es donde nacen en última instancia los mecanismos de análisis; se crean a medida que el arquitecto de software percibe, quizás vagamente al principio, un tema común que emerge de un conjunto de soluciones a varios problemas. Existe la necesidad de proporcionar una forma de que los elementos de hebras diferentes sincronicen sus relojes, y la necesidad de una forma común de asignar los recursos. Los mecanismos de análisis, que simplifican el lenguaje del análisis, surgen de estos patrones.

La identificación de un mecanismo de análisis significa identificar que existe un subproblema común, quizás implícito (en tanto que implicado por los requisitos del sistema) y darle un nombre. Inicialmente, el nombre puede ser lo único que exista; por ejemplo, el arquitecto de software reconoce que el sistema necesitará un mecanismo de persistencia. En última instancia, este mecanismo se implementará mediante la colaboración de una sociedad de clases (consulte [BOO98]), algunas de las cuales no proporcionan directamente funciones de la aplicación, sólo existen para dar soporte. Muy a menudo, estas clases de soporte se ubican en las capas inferiores o del medio de una arquitectura en capas; de esta manera, proporcionan un servicio de soporte común a todas las clases del nivel de aplicación.

Si el subproblema identificado es bastante común, es posible que exista un patrón desde el que se puedan crear instancias del mecanismo, mediante la vinculación de clases existentes y la implementación de clases nuevas, según requiera el patrón. Un mecanismo de análisis producido de esta esta manera será abstracto y requerirá un mayor perfeccionamiento mediante el diseño y la implementación.

Para obtener más información, consulte Concepto: Mecanismos de análisis.

Revisar los resultados
Objetivo Garantizar que los resultados del análisis de la arquitectura sean completos y coherentes.

Cuando concluya el análisis de la arquitectura, revise los mecanismos de arquitectura, los subsistemas, los paquetes y las clases que se han identificado para garantizar que sean completos y coherentes. Como los resultados del análisis de la arquitectura son preliminares y relativamente informales, las revisiones también tienen que ser informales. Se pueden utilizar casos de ejemplo o casos de uso para validar las selecciones de arquitectura realizadas a distintos niveles; desde la perspectiva empresarial hasta las interacciones específicas que se producen.

Consulte el apartado Lista de comprobación: Documento de arquitectura de software - Consideraciones sobre el análisis de la arquitectura para obtener más información sobre la evaluación de los resultados de esta tarea.



Más información