Crear la arquitectura de una solución

Parte de crear una buena arquitectura consiste en investigar las estrategias alternativas en materia de arquitectura.Las estrategias alternativas ofrecen diversas ventajas según la plataforma que se seleccione, las tecnologías que se usen y la reutilización de código.Se diseñan estrategias y se crean pruebas de concepto para investigar más a fondo los costos y las ventajas de cada estrategia.Las estrategias se evalúan en función de los requisitos del producto y los requisitos de calidad y, en última instancia, se elige la estrategia que se va a usar para implementar el producto.Por último, la seguridad y el rendimiento son aspectos arquitectónicos que afectan a todo el producto.

En este tema

• Crear diseños de partición arquitectónica alternativos

• Arquitectura e implementación del sistema de diseño

• Crear pruebas de concepto

• Evaluar las alternativas

• Seleccionar la arquitectura

• Desarrollar un modelo de rendimiento

Crear diseños de partición arquitectónica alternativos

Se analiza el problema y se consideran diferentes enfoques.Se selecciona un grupo de requisitos que representan los principales retos empresariales y tecnológicos.Se estudian las características de estos retos, como la integración de sistemas heredados y la predicción de las futuras necesidades en función de las necesidades actuales, la reusabilidad del código y los costos de mantenimiento.

Crear un diagrama de aplicaciones

A partir del modelo de dominio y los requisitos, se crea un diagrama de aplicaciones que represente los elementos lógicos básicos del sistema.Más adelante, este diagrama se dividirá en diagramas de sistemas.Se considerarán y se evaluarán esquemas de partición alternativos.

Un diagrama de aplicaciones se puede representar como un diagrama de casos de uso UML (Lenguaje de modelos unificado).En este tipo de diagrama, se pueden mostrar los principales subsistemas y sus dependencias.Además, se pueden colocar los casos de uso en cada subsistema para reflejar qué subsistema administra cada escenario de usuario.

Establecer los criterios de evaluación

Se deben determinar los criterios que se van a usar para identificar los requisitos y los escenarios que representan importantes retos arquitectónicos.Para ello, es preciso consultar los documentos existentes acerca de la arquitectura empresarial.Se deben revisar los requisitos comerciales y técnicos así como los estándares empresariales por lo que se han de regir las nuevas aplicaciones.Se deben incluir criterios adicionales de los que se sabe que son importantes para la arquitectura, como la integración con los sistemas heredados, la reusabilidad del código, la reutilización de las plataformas y bibliotecas de proveedores existentes, y el control de los costos de mantenimiento.Asimismo, se deben incluir criterios que representen los riesgos y costos de implementación de una solución técnica.

Seleccionar un grupo de requisitos candidatos

Se debe cotejar cada requisito de calidad de servicio y de producto con los criterios de evaluación.Si un requisito representa un reto arquitectónico, se debe considerarlo como candidato para el modelado.Por ejemplo, el requisito de que el nuevo producto debe ser compatible con las bases de datos anteriores del cliente cumple los criterios en materia de integración con los sistemas heredados.Este requisito es un candidato para modelar cómo funcionaría la integración.

Seleccionar un grupo de escenarios candidatos

Se ha de cotejar cada escenario con los criterios de evaluación.Si un escenario representa un reto arquitectónico, se debe considerarlo como candidato para el modelado.Por ejemplo, el escenario donde el usuario descarga la actualización de un cliente cumple los criterios en materia de costos de mantenimiento.Este escenario es un candidato para modelar cómo se administran mejor las actualizaciones de cliente.

Reducir el grupo de candidatos

Se deben revisar los escenarios y requisitos candidatos.Se han de quitar los escenarios y requisitos que duplican los criterios de evaluación o se representan mejor mediante otros escenarios y requisitos.De este modo, se reduce el grupo de candidatos hasta obtener un grupo básico que representa los principales retos arquitectónicos, riesgos y costos de la nueva aplicación.Se recomienda mantener los escenarios y requisitos que mejor representen los criterios de evaluación y que reflejen el mayor riesgo y el mayor costo posible a la hora de crear la arquitectura de una solución técnica.Se han de conservar los escenarios y requisitos que representen las principales partes de la aplicación.

Crear criterios de partición

A partir de los requisitos, se deben analizar los modelos arquitectónicos establecidos (por ejemplo, fachada o Model-View-Controller) e identificar los posibles candidatos para la implementación.Los modelos candidatos se deben identificar en función de los requisitos y se han de considerar sus ventajas y desventajas con respecto al acoplamiento, la cohesión, la extensibilidad, la adaptabilidad y la flexibilidad.A continuación, se procede a seleccionar un conjunto de candidatos para la implementación como alternativas que se han de evaluar.

Arquitectura e implementación del sistema de diseño

La arquitectura del sistema define las agrupaciones y las configuraciones de los elementos que se identifican en el diagrama de aplicaciones.Se crean diagramas de sistemas en los que se refleja la arquitectura del sistema para cada posible enfoque.En los diagramas de implementación se muestran los pasos de implementación basados en las dependencias y la funcionalidad básica.Un arquitecto de infraestructura crea un diagrama de centro de datos lógico en el que se describe la estructura lógica del centro de datos donde se va a implementar la aplicación.Los diagramas de implementación se validan con el diagrama de centro de datos lógico para garantizar que se pueden implementar los sistemas.

Crear un modelo del sistema

El arquitecto y el responsable de desarrollo crean diagramas de sistemas a partir del diagrama de aplicaciones.A través de los diagramas de sistemas, se pueden diseñar sistemas de aplicaciones reutilizables como unidades de implementación a partir de los elementos del diagrama de aplicaciones.Asimismo, es posible diseñar sistemas más grandes y más complejos que contienen otros sistemas para que se pueden utilizarlos en escenarios de sistemas distribuidos y se puedan abstraer los detalles de las aplicaciones en esos sistemas.Cada nuevo archivo de diagrama debe protegerse en el control de versiones.

Los diagramas de sistemas se pueden representar en Visual Studio de las siguientes maneras:

• Diagramas de casos de uso.Los principales escenarios de usuario se representan como casos de uso y los principales componentes del sistema se muestran como subsistemas.Cada caso de uso se puede colocar dentro de su correspondiente subsistema.Para obtener más información, vea Diagramas de casos de uso de UML: Instrucciones.

• Diagramas de componentes UML.Estos diagramas permiten mostrar los canales de comunicación entre los componentes, además de las dependencias.Asimismo, se pueden crear diagramas de clases para describir los tipos que se pueden ver en las interfaces de los componentes y se pueden crear diagramas de secuencia para mostrar sus interacciones.Para obtener más información, vea Diagramas de componentes de UML: Instrucciones, Diagramas de clases de UML: Instrucciones y Diagramas de secuencia de UML: Instrucciones.

• Diagramas de capas.En un diagrama de capas, se describe la estructura de bloques de la aplicación.En este diagrama, se muestran únicamente los componentes y las dependencias que existen entre ellos.Ofrece la ventaja de que, una vez escrito el código, se pueden validar el código y las dependencias con el diagrama.Para obtener más información, vea Diagrama de capas: Instrucciones.

Para cada subsistema, se puede crear un paquete que describe más detalladamente sus tipos y su comportamiento.Para obtener más información, vea Definir espacios de nombres y paquetes.

Crear pruebas de concepto

Los importantes riesgos de un proyecto se pueden mitigar creando una prueba de concepto arquitectónica.Es importante abordar los riesgos lo más pronto posible en el transcurso de un proyecto para que se puedan tomar las decisiones importantes en materia de estrategia y arquitectura cuando aún es fácil modificar las partes fundamentales de la arquitectura.Si se crean pruebas de concepto en una fase temprana, se reducen los riesgos y las incógnitas del proyecto.De este modo, la planeación y la estimación en iteraciones posteriores tendrán una mayor precisión.Las pruebas de concepto pueden ser temporales y pueden descartarse una vez resueltos los problemas o se pueden crear como fundamento de la arquitectura básica.

Examinar el riesgo

Es preciso conocer los elementos que conducen a la identificación del riesgo o a las decisiones en materia de arquitectura.Se han de examinar los escenarios relacionados y los requisitos de calidad de servicio.Se deben comprobar las implicaciones para los entornos de destino.

Planear el enfoque

Se debe determinar el formato de la prueba de concepto que se necesita.Los diagramas de aplicaciones y de sistemas pueden ayudar a realizar la planeación.Se debe resolver únicamente el problema arquitectónico identificado por el riesgo.Se ha de buscar la solución más simple.

Compilar y ejecutar la prueba de concepto

Se compila la prueba de concepto.Se puede implementar la prueba de concepto desde el diagrama de aplicaciones.El foco de atención debe seguir siendo el problema que se va a resolver.La prueba de concepto debe implementarse en un entorno físico que sea congruente con el diagrama de centro de datos lógico.El entorno físico debe corresponderse en la medida de lo posible con la configuración del diagrama de centro de datos lógico.La prueba de concepto debe cotejarse con los problemas de alto riesgo.

Evaluar las alternativas

El método LAAAM (Lightweight Architecture Alternative Analysis Method) ayuda a tomar una decisión con respecto a las diferentes estrategias de arquitectura para crear una aplicación.Se suele necesitar un día para completar este método.Primero, se crea un árbol de utilidad que describe los principales aspectos cualitativos y funcionales de la aplicación que se basan en los requisitos.Para cada aspecto, se escribe un escenario en forma de instrucción que se escribe como contexto, estímulo y respuesta.Se usa una matriz de evaluación para evaluar la eficacia con la que cada estrategia aborda cada escenario.

Crear un árbol de utilidad

Se examinan los requisitos de calidad de servicio y los requisitos del producto para determinar los principales aspectos cualitativos y funcionales de la aplicación.Se crea un árbol de utilidad que representa la calidad global de la aplicación.El nodo raíz del árbol se denomina Utilidad.Los nodos subsiguientes suelen denominarse según los términos de calidad estándar, como modificabilidad, disponibilidad y seguridad.El árbol debe representar la naturaleza jerárquica de las calidades y proporcionar una base para establecer las prioridades.En cada nivel del árbol, se perfeccionan aún más las calidades.Finalmente, estas calidades se convierten en escenarios.

Crear una matriz de evaluación

Para cada hoja del árbol de utilidad, se escribe un escenario.El escenario tiene el formato de contexto, estímulo y respuesta (por ejemplo, "En condiciones normales, una transacción de base de datos se realiza en menos de 100 milisegundos").

Se crea una hoja de cálculo o una tabla y se escribe cada escenario como una fila de esta matriz de evaluación.Cada estrategia de arquitectura se especifica como una columna.En cada intersección de estrategias y escenarios, se escribe una puntuación del 1 al 4.

La puntuación debe tener en cuenta los siguientes factores:

• ¿costo de desarrollo esta solución fácil o difícil implementar?¿Cuál es su impacto sobre otras áreas?

• ¿costo operativo en tiempo de ejecución, esta solución fácilmente, o afectará negativamente a la utilidad, rendimiento, etc.?

• ¿riesgo esta solución segura dirigió el escenario bien, o está ahí costos desconocidos?¿Esta solución puede afectar negativamente a la capacidad del equipo para dar cabida a las futuras mejoras de los requisitos?

Si se ha creado una prueba de concepto para una estrategia, se debe usar la información de esa prueba de concepto como ayuda para determinar los valores.

En la parte inferior de la tabla, se suman los valores de los escenarios.Estos valores se utilizan como punto de partido de un debate que conducirá a que se tomen decisiones con respecto a las arquitecturas alternativas.

La matriz de evaluación completada se carga en el portal del proyecto.

Seleccionar la arquitectura

Una vez creada la matriz de evaluación, se celebra una reunión de revisión para determinar qué arquitectura se va a utilizar en la siguiente iteración.La matriz de evaluación y la información que se obtiene al crear las pruebas de concepto se utilizan como ayuda para tomar una decisión.Una vez seleccionada la arquitectura, se protegen los diagramas de la arquitectura como solución de referencia y se crea un documento de justificación en el que se reflejan los motivos de la selección.

Preparar la revisión

El arquitecto y el responsable de desarrollo identifican a las personas apropiadas para revisar las arquitecturas propuestas y envían la documentación de las arquitecturas a cada participante.

Arquitectura e implementación del sistema de revisión

Durante la reunión de revisión, se revisan los diagramas de sistemas, el informe de implementación y el diagrama de centro de datos lógico.El objetivo es elegir la arquitectura que se va a implementar en la siguiente iteración.

Para poder evaluar la idoneidad de cada arquitectura, se tienen en cuenta las puntuaciones de la matriz de evaluación.Asimismo, se considera cualquier información que se obtenga de las pruebas de concepto, como los costos o la complejidad de la implementación de las diferentes arquitecturas.Si el diagrama de centro de datos lógico representa un centro de datos existente que no se puede modificar, no se debe revisarlo.Si se va a crear un centro de datos, revise en el diagrama las consideraciones referentes a la implementación.A continuación, se selecciona la arquitectura que se va a utilizar.Se ha de cotejar el concepto arquitectónico con los escenarios para validar que la solución se ajusta a las necesidades del cliente y es completa.

Crear una solución de referencia

Se crea un documento de justificación en el que se reflejan las decisiones que se toman en la reunión.Este documento se debe cargar en el portal del proyecto.Los diagramas de aplicaciones, sistemas o centros de datos lógicos de la arquitectura seleccionada se protegen como solución de referencia que se va a utilizar para implementar las características en la siguiente iteración.Se comunica a todo el equipo y a los equipos dependientes la decisión referente a la arquitectura seleccionada para la siguiente iteración.

Desarrollar un modelo de rendimiento

Se utiliza un model de rendimiento para identificar y resolver los posibles problemas de rendimiento de la aplicación.Un modelo de rendimiento se desarrolla a partir de un requisito de calidad de servicio, que se desglosa en tareas de desarrollo.A cada tarea de desarrollo se le asigna un presupuesto de rendimiento para la implementación.

Se identifican los escenarios vinculados al requisito de rendimiento.Se asignan las tareas de desarrollo a los escenarios.En la lista de requisitos de calidad de servicio, se determina la carga de trabajo de la aplicación.Con ayuda de las estimaciones de la carga de trabajo y la lista de los requisitos de calidad de servicio, se identifican los objetivos de rendimiento para cada escenario clave.Entre estos objetivos figuran el tiempo de respuesta, la capacidad de proceso y el uso de los recursos.Se identifican los recursos relacionados con el rendimiento que se han presupuestado para cumplir los objetivos de rendimiento.Algunos ejemplos de recursos relacionados con el rendimiento son el tiempo de ejecución y el ancho de banda de la red.Se determina la asignación máxima permitida de cada recurso.

Los recursos presupuestados se reparten entre los pasos de procesamiento de cada escenario.Cuando no se está seguro de cómo asignar el presupuesto, hay que decantarse por la mejor conjetura o repartir los recursos de manera uniforme entre los pasos.La elaboración del presupuesto se perfecciona durante la validación.La asignación se adjunta o se escribe en la correspondiente tarea de desarrollo.

Se identifican las consignaciones presupuestarias que suponen un riesgo para el cumplimiento de los objetivos en materia de rendimiento.Se examinan las contrapartidas que ayudan a cumplir los objetivos de rendimiento, como alternativas de diseño e implementación.Se vuelven a evaluar los requisitos de calidad de servicio si es necesario.

Se identifican los escenarios que no se ajustan a las consignaciones presupuestarias.Se mide el rendimiento de los escenarios.Se usa la creación de prototipos en las iteraciones tempranas si no hay código disponible.Se repiten los pasos de elaboración de presupuesto, evaluación y validación según sea necesario con los datos obtenidos durante la validación.

Desarrollar un modelo de amenaza

Para obtener más información, vea la siguiente página del sitio web de Microsoft: Security Developer Center.