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.
|
|