Planos arquitectónicos: la vista "4 + 1"
Modelo de arquitectura de software
Modelo de arquitectura de software
Artículo publicado en IEEE Software 12 (6)
Noviembre de 1995, págs. 42-50
Resumen
Este artículo presenta un modelo para describir la arquitectura de sistemas intensivos en software, basado en el uso de múltiples vistas concurrentes. Este uso de múltiples vistas permite abordar por separado las preocupaciones de varias 'partes interesadas' de la arquitectura: usuario final, desarrolladores, ingenieros de sistemas, directores de proyectos, etc., y manejar por separado los requisitos funcionales y no funcionales.
Se describe cada una de las cinco vistas, junto con una notación para capturarlo. Las vistas se diseñan utilizando un escenario centrado en la arquitectura, guiando el proceso de desarrollo iterativo .
Palabras clave : arquitectura de software, vista, diseño orientado a objetos, proceso de desarrollo de software
Introducción
Todos hemos visto muchos libros y artículos en los que un diagrama intenta capturar la esencia de la arquitectura de un sistema. Pero al observar cuidadosamente el conjunto de cuadros y flechas que se muestran en estos diagramas, queda claro que sus autores han luchado mucho para representar en un plano más de lo que realmente puede expresar.
- ¿Son las casillas que representan los programas en ejecución?
- ¿O trozos de código fuente?
- ¿O computadoras físicas?
- ¿O simplemente agrupaciones lógicas de funcionalidad?
- ¿Las flechas representan dependencias de compilación?
- ¿O controlar flujos?
- ¿O flujos de datos?
A menudo también la arquitectura no aborda las preocupaciones de todos sus "clientes" (o "partes interesadas", como se les llama en USC). Este problema ha sido notado por varios autores: Garlan & Shaw 1 , Abowd & Allen en CMU, Clements en el SEI.
Como remedio, proponemos organizar la descripción de una arquitectura de software utilizando varias opiniones concurrentes, cada una de las cuales aborda un conjunto específico de preocupaciones.
Un modelo arquitectónico
La arquitectura del software se ocupa del diseño y la implementación de la estructura de alto nivel del software. Eso es el resultado de ensamblar un cierto número de elementos arquitectónicos en algunas formas bien elegidas para satisfacer los principales requisitos de funcionalidad y rendimiento del sistema, así como algunos otros requisitos no funcionales, requisitos como confiabilidad, escalabilidad, portabilidad y disponibilidad.
Perry y Wolfe lo expresaron muy bien en esta fórmula2, modificada por Boehm:
Arquitectura de software = {Elementos, formas, fundamento / restricciones}
La arquitectura de software se ocupa de la abstracción, la descomposición y la composición, el estilo y la estética.
Para describir una arquitectura de software, utilizamos un modelo compuesto por múltiples vistas o perspectivas. A fin de que eventualmente abordar arquitecturas grandes y desafiantes, el modelo que proponemos se compone de cinco vistas principales, (ver figura 1):
- La vista lógica, la cual es el modelo de objetos del diseño (cuando se utiliza el método de diseño orientado a objetos),
- La vista del proceso, que captura los aspectos de simultaneidad y sincronización del diseño,
- La vista física, que describe el mapeo(s) del software en el hardware y refleja su aspecto distribuido,
- La vista de desarrollo, que describe la organización estática del software en su ambiente de desarrollo.
La descripción de una arquitectura (las decisiones tomadas) se pueden organizar en torno a estas cuatro vistas y luego se ilustra con algunos casos de uso seleccionados o escenarios que se convierten en una quinta vista.
La arquitectura de hecho evolucionó parcialmente a partir de estos escenarios como veremos más adelante.
Aplicamos la ecuación de Perry & Wolf independientemente en cada vista, es decir, para cada vista definimos el conjunto de elementos a utilizar (componentes, contenedores y conectores), capturamos las formas y patrones que funcionan y capturamos el fundamento y las limitaciones, conectando la arquitectura con algunos de los requisitos.
Cada vista se describe mediante un plano que utiliza su propia notación particular. Para cada vista también, los arquitectos puede elegir un determinado estilo arquitectónico, lo que permite la coexistencia de múltiples estilos en un sistema.
Ahora veremos sucesivamente cada uno de los cinco puntos de vista, dando para cada uno su propósito: lo que se refiere a las direcciones, una notación para el plano arquitectónico correspondiente, las herramientas que hemos utilizado para describirlo y administrarlo.
Se extraen pequeños ejemplos del diseño de una centralita, derivado de nuestro trabajo en Alcatel Business System y un sistema de control de tráfico aéreo 3, pero en una forma muy simplificada, la intención aquí es solo dar una idea de las vistas y su notación y no definir la arquitectura de esos sistemas.
El modelo de vista "4 + 1" es bastante "genérico": se pueden usar otras notaciones y herramientas, otros especialmente métodos de diseño para las descomposiciones lógicas y de proceso, pero hemos indicado las que han sido utilizadas con éxito.
La arquitectura lógica
La descomposición orientada a objetos
La arquitectura lógica soporta principalmente los requisitos funcionales: lo que el sistema debe proporcionar en condiciones de servicio a sus usuarios. El sistema se descompone en un conjunto de abstracciones clave, tomadas (en su mayoría) del dominio del problema, en forma de objetos o clases de objetos.
Aprovechamos los principios de la abstracción, encapsulación y herencia. Esta descomposición no es solo por el análisis funcional, sino que también sirve para identificar mecanismos comunes y elementos de diseño en las distintas partes del sistema.
Usamos el enfoque Rational / Booch para representar la arquitectura lógica, mediante diagramas de clases y plantillas de clases.4 Un diagrama de clases muestra un conjunto de clases y sus relaciones lógicas: asociación, uso, composición, herencia, etc. Los conjuntos de clases relacionadas se pueden agrupar en categorías de clases. Las plantillas de clase se centran en cada clase individual; enfatizan las operaciones de la clase principal e identifican el objeto y sus características clave.
Si es importante definir el comportamiento interno de un objeto, esto se hace con diagramas de transición de estado. o diagramas de estado. Los mecanismos o servicios comunes se definen en las clases de utilidades.
Alternativamente a un enfoque orientado a objetos, una aplicación que está basada mucho en los datos puede usar alguna otra forma de vista lógica, como diagramas ER.
Notación para la vista lógica
La notación para la vista lógica se deriva de la notación de Booch4 . Esta es considerablemente simplificada y toma en cuenta solo los elementos que son arquitectónicamente significativos. En particular, los numerosos adornos no son muy útiles en este nivel de diseño. Usamos Rational Rose® para respaldar el diseño de la arquitectura lógica.
Estilo para la vista lógica
El estilo que usamos para la vista lógica es un estilo orientado a objetos. La principal directriz para el diseño de la vista lógica es tratar de mantener un modelo de objetos único y coherente en todo el sistema, para evitar la especialización de clases y mecanismos por sitio o por procesador.
Ejemplos de planos lógicos
La Figura 3a muestra las principales clases involucradas en la arquitectura de Télic PABX
Podemos distinguir entonces: las tareas principales , que son los elementos arquitectónicos que pueden ser abordados y tareas menores, que son tareas adicionales introducidas localmente por razones de implementación (actividades cíclicas, búfer, tiempos muertos, etc.). Se pueden implementar como tareas de Ada por ejemplo, o como hilos ligeros.
Ejemplo de una plantilla de procesos
Un PABX establecen comunicaciones entre terminales. Una terminal puede ser un teléfono, una línea troncal (es decir, línea a la oficina central), una línea de enlace (es decir, línea PABX privada a PABX), una línea telefónica de función, una línea de datos, un línea ISDN, etc.
Las diferentes líneas son soportadas por tarjetas de interfaz de líneas. La responsabilidad de un objeto controlador de línea es decodificar e inyectar todas las señales hacia la tarjeta de interfaz de línea, traduciendo hacia y desde un conjunto pequeño y uniforme de eventos: inicio, parada, dígito, etc. El controlador también lleva todos las estricciones estrictas en tiempo real. Esta clase tiene muchas subclases para adaptarse a diferentes tipos de interfaces.
La responsabilidad del objeto terminal es mantener el estado de una terminal y negociar servicios en nombre de esa línea. Por ejemplo, utiliza los servicios del plan de numeración para interpretar la marcación en la fase de selección.
La conversación representa un conjunto de terminales involucrados en la conversación. La conversación usa servicios de traducción (directorio, asignación de direcciones lógicas a físicas, rutas) y servicios de conexión al establecer una ruta de voz entre los terminales.
Para sistemas mucho más grandes, que contienen congeladas unas pocas docenas de clases de importancia arquitectónica, la figura 3b muestra el diagrama de clase de nivel superior de un sistema de control de tránsito aéreo, que contiene 8 categorías de clase (es decir, grupos de clases).
La Arquitectura de Procesos
El proceso de descomposición
La arquitectura de procesos tiene en cuenta algunos requisitos no funcionales, como el rendimiento y ladisponibilidad. Aborda problemas de concurrencia y distribución, de la integridad del sistema, de la tolerancia a fallas y cómo las principales abstracciones de la vista lógica encajan dentro de la arquitectura de procesos, en qué hilo del control realmente se está ejecutado una operación para un objeto.
La arquitectura de procesos se puede describir en varios niveles de abstracción, cada nivel aborda diferentes preocupaciones. En el nivel más alto, la arquitectura de procesos se puede ver como un conjunto de "procesos" en ejecución independiente como redes lógicas de programas de comunicación (llamados "procesos"), distribuidos en un conjunto de recursos hardware conectados por una LAN o una WAN.
Pueden existir múltiples redes lógicas simultáneamente, compartiendo los mismos recursos físicos. Por ejemplo, se pueden utilizar redes lógicas independientes para soportar la separación del sistema operativo en línea desde el sistema fuera de línea, así como el apoyo a la coexistencia de la simulación o probar versiones del software.
Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos representan el nivel en el que la arquitectura de procesos se puede controlar tácticamente (es decir, iniciar, recuperar, reconfigurar y apagar). Además, los procesos se pueden replicar para una mayor distribución de la carga de procesamiento, o para mejorar disponibilidad.
El software es dividido en un conjunto de tareas independientes . Una tarea es un hilo de control separado, que puede ser programados individualmente en un nodo de procesamiento.
Podemos distinguir entonces: las tareas principales , que son los elementos arquitectónicos que pueden ser abordados y tareas menores, que son tareas adicionales introducidas localmente por razones de implementación (actividades cíclicas, búfer, tiempos muertos, etc.). Se pueden implementar como tareas de Ada por ejemplo, o como hilos ligeros.
Las tareas principales se comunican a través de un conjunto de mecanismos de comunicación entre tareas bien definidos: síncronos y servicios de comunicación asíncronos basados en mensajes, llamadas a procedimientos remotos, difusión de eventos, etc. Las tareas pueden comunicarse por encuentro o memoria compartida. Las tareas principales no deben hacer suposiciones sobre su colocación en el mismo proceso o nodo de procesamiento.
El flujo de mensajes, las cargas de procesos se pueden estimar en función plantillas de procesos. También es posible implementar una arquitectura de proceso "hueca" con cargas ficticias para los procesos y medir su rendimiento en el sistema objetivo, como lo describen Filarey et al. en su experimento de Eurocontrol.
Notación para la vista de Procesos
La notación que usamos para la vista de procesos, amplía la notación propuesta originalmente por Booch para Tareas Ada. Una vez más, la notación utilizada se centra en los elementos que son arquitectónicamente significativos. (Figura 4)
Hemos utilizado el producto Universal Network Architecture Services (UNAS) de TRW para diseñar e implementar el conjunto de procesos y tareas (y sus redundancias) en redes de procesos. UNAS contiene una herramienta, el entorno del ciclo de vida de software de arquitectos (SALE), que admite dicha notación.
SALE permite la representación gráfica de la arquitectura del proceso, incluidas las especificaciones de los posibles rutas de comunicación entre tareas, de las que se extrae automáticamente el código fuente Ada o C ++ automáticamente generado. El beneficio de este enfoque para especificar e implementar la arquitectura del proceso es que los cambios se pueden incorporar fácilmente sin mucho impacto en el software de la aplicación.
Estilo para la vista de procesos
Varios estilos encajarían en la vista del procesos. Por ejemplo, tomando de la taxonomía1 de Garlan y Shaw podemos tener: canalizaciones y filtros, o cliente / servidor, con variantes de cliente / servidor único y múltiples clientes / servidores múltiples. Para sistemas más complejos, se podría usar un estilo similar a los grupos de procesos enfoque del sistema ISIS como lo describe K. Birman con otra notación y conjunto de herramientas.
Ejemplo de una plantilla de procesos
Todos las terminales son manejadas por un solo proceso de terminal, que es impulsado por mensajes en sus colas de entrada. Los objetos del controlador se ejecutan en una de las tres tareas que componen el proceso del controlador: Una tarea de ciclo de frecuencia baja escanea todos los terminales inactivos (200 ms), coloca cualquier terminal que llegue a activarse en la lista de escaneo del alto tarea de frecuencia de ciclo (10 ms), que detecta cualquier cambio de estado significativo y los pasa a las tareas del controlador principal que interpreta los cambios y los comunica por mensaje al terminal correspondiente. Aquí el paso de mensajes dentro del proceso del controlador se realiza a través de la memoria compartida.
La arquitectura de desarrollo
Descomposición del subsistema
La arquitectura de desarrollo se centra en la real organización de módulos de software en el entorno de desarrollo de software. El software está empaquetado en pequeños fragmentos (bibliotecas de programas o subsistemas ) que pueden ser desarrollados por uno o un pequeño número de desarrolladores. Los subsistemas están organizados en una jerarquía de capas, cada capa proporciona una interfaz estrecha y bien definida con las capas superiores.
La arquitectura de desarrollo del sistema está representada por diagramas de módulos y subsistemas, que muestran la relaciones de 'exportación' e 'importación'. La arquitectura de desarrollo completa solo se puede describir cuando se han identificado todos los elementos del software. Sin embargo, es posible enumerar las reglas que gobiernan la arquitectura de desarrollo: particionamiento, agrupamiento, visibilidad.
En su mayor parte, la arquitectura de desarrollo tiene en cuenta los requisitos internos relacionados con la facilidad de desarrollo, gestión de software, reutilización o comunidad y a las limitaciones impuestas por el conjunto de herramientas, o el lenguaje de programación. La vista de desarrollo sirve como base para la asignación de requisitos, para asignación de trabajo a equipos (o incluso para la organización de equipos), para la evaluación y planificación de costos, para monitorear el avance del proyecto, para razonar sobre reutilización, portabilidad y seguridad del software. Es la base para establecer una línea de producto.
Notación para la plantilla de desarrollo
Nuevamente, una variación de la notación de Booch, limitándola a los elementos que son arquitectónicamente significativos.
El entorno de desarrollo de Apex de Rational apoya la definición y la implementación de la arquitectura de desarrollo, la estrategia de capas descrita anteriormente y la aplicación de las reglas de diseño.
Rational Rose puede dibujar las plantillas de desarrollo a nivel de módulo y subsistema, en adelante ingeniería y por ingeniería inversa del código fuente de desarrollo, para Ada y C ++.
Estilo para la vista de desarrollo
Recomendamos adoptar un estilo en capas para la vista de desarrollo, definiendo entre 4 y 6 capas de subsistemas. Cada capa tiene una responsabilidad bien definida. La regla de diseño es que un subsistema en una determinada capa solo depende de subsistemas que se encuentran en la misma capa o en capas inferiores, para minimizar la desarrollo de redes muy complejas de dependencias entre módulos y permitir estrategias de liberación sencillas, capa por capa.
Ejemplo de arquitectura de desarrollo
La Figura 6 representa la organización de desarrollo en cinco capas de una línea de producto de control de tráfico aéreo, sistemas desarrollados por Hughes Aircraft of Canada3 . Esta es la arquitectura de desarrollo correspondiente a la lógica mostrada en la fig. 3b.
Las capas 1 y 2 constituyen una infraestructura distribuida independiente del dominio que es común en la línea de productos y lo protege de variaciones en la plataforma de hardware, el sistema operativo o los productos disponibles en el mercado como el sistema de gestión de bases de datos. A esta infraestructura, la capa 3 agrega un marco ATC para formar una arquitectura de software de dominio específico . Con este marco, se crea una paleta de funciones en la capa 4.
La capa 5 depende en gran medida del cliente y del producto y contiene la mayor parte de la interfaz de usuario y las interfaces con los sistemas externos. Unos 72 subsistemas se distribuyen en las 5 capas, que contienen cada una de 10 av50 módulos y se pueden representar en planos adicionales.
La Arquitectura Física
Mapeo del software al hardware
La arquitectura física tiene en cuenta principalmente los requisitos no funcionales del sistema, como la disponibilidad, la confiabilidad (tolerancia a fallas), el rendimiento (rendimiento) y la escalabilidad. El software se ejecuta en una red de computadoras o nodos de procesamiento (o simplemente nodos para abreviar). Los diversos elementos identificados: redes, procesos, tareas y objetos: deben asignarse a los distintos nodos. Esperamos que se utilizarán varias diferentes configuraciones físicas: algunas para el desarrollo y las pruebas, otras para la implementación del sistema para varios sitios o para diferentes clientes. El mapeo del software a los nodos por lo tanto, debe ser muy flexible y tener un impacto mínimo en el código fuente en sí.
Notación para el plano físico
Los planos físicos pueden volverse muy confusos en sistemas grandes, por lo que toman varias formas, con o sin el mapeo desde la vista del proceso.
UNAS de TRW nos proporciona aquí medios basados en datos para mapear la arquitectura del proceso en la arquitectura física que permite una gran clase de cambios en el mapeo sin modificaciones en el código fuente.
Ejemplo de una plantilla física
La figura 8 muestra una posible configuración de hardware para una centralita telefónica grande, mientras que las figuras 9 y 10 muestran mapeos de la arquitectura del proceso en dos arquitecturas físicas diferentes, correspondientes a una pequeña y una PABX grande. C, F y K son tres tipos de computadoras de diferente capacidad, que admiten tres diferentes ejecutables
Escenarios
Poniéndolo todo junto
Se muestra que los elementos de las cuatro vistas funcionan juntos a la perfección mediante el uso de un pequeño conjunto de elementos importantes, los escenarios —instancias de casos de uso más generales— para los cuales describimos los scripts correspondientes (secuencias de interacciones entre objetos y entre procesos) como lo describen Rubin y Goldberg6. Los escenarios son en cierto sentido una abstracción de los requisitos más importantes. Su diseño es expresado utilizando diagramas de escenarios de objetos y diagramas de interacción de objetos4.
Esta vista es redundante con las otras (de ahí el "+1"), pero tiene dos propósitos principales:
- como impulsor para descubrir los elementos arquitectónicos durante el diseño de la arquitectura como describiremos más adelante,
- como una función de validación e ilustración después de que este diseño de arquitectura esté completo, tanto en papel como punto de partida para las pruebas de un prototipo arquitectónico.
Notación para los escenarios
La notación es muy similar a la vista lógica para los componentes (ver fig.2), pero usa los conectores de la vista de procesos para interacciones entre objetos (ver fig. 4). Tenga en cuenta que las instancias de objetos se indican con líneas solidas. En cuanto al plano lógico, capturamos y gestionamos diagramas de escenarios de objetos utilizando Rational Rose.
Ejemplo de un escenario
La Fig. 11 muestra un fragmento de un escenario para la PABX pequeña. El script correspondiente dice:
- El controlador del teléfono de Joe detecta y valida la transición de colgado a descolgado y envía un mensaje para despertar el objeto terminal correspondiente.
- El terminal asigna algunos recursos y le dice al controlador que emita algún tono de marcación.
- El controlador recibe dígitos y los transmite al terminal.
- El terminal utiliza el plan de numeración para analizar el flujo de dígitos.
- Cuando se ingresa una secuencia válida de dígitos, el terminal abre una conversación.
Correspondencia entre las vistas
Las distintas vistas no son totalmente ortogonales ni independientes. Los elementos de una vista están conectados a elementos en otras vistas, siguiendo ciertas reglas de diseño y heurísticas.De la visión lógica a la de procesos
Identificamos varias características importantes de las clases de la arquitectura lógica:
- Autonomía: ¿los objetos son activos, pasivos, protegidos?
- un objeto activo toma la iniciativa de invocar las operaciones de otros objetos o sus propias operaciones y tiene control total sobre la invocación de sus propias operaciones por otros objetos
- un objeto pasivo nunca invoca espontáneamente ninguna operación y no tiene control sobre la invocación de sus propias operaciones por otros objetos
- un objeto protegido nunca invoca espontáneamente ninguna operación, pero realiza algún arbitraje sobre la invocación de sus operaciones.
- Persistencia: ¿los objetos son transitorios, permanentes? ¿Son la falla de un proceso o procesador?
- Subordinación: ¿la existencia o persistencia de un objeto depende de otro objeto?
- Distribución: son el estado o las operaciones de un objeto accesible desde muchos nodos en la arquitectura física, desde varios procesos en la arquitectura de procesos?
En la vista lógica de la arquitectura, consideramos cada objeto como activo y potencialmente "concurrente", es decir, comportarse "en paralelo" con otros objetos y no prestamos más atención al grado exacto de concurrencia, necesitamos lograr este efecto. Por tanto, la arquitectura lógica sólo tiene en cuenta el aspecto funcional de los requisitos.
Sin embargo, cuando llegamos a definir la arquitectura del proceso, implementar cada objeto con su propio hilo de control (por ejemplo, su propio proceso Unix o tarea Ada) no es muy práctico en el estado actual de la tecnología, debido a la enorme sobrecarga que esto impone. Además, si los objetos son concurrentes, debe haber alguna forma de arbitraje para invocar sus operaciones.
Por otro lado, se necesitan múltiples hilos de control por varias razones:
- Reaccionar rápidamente a ciertas clases de estímulos externos, incluidos eventos relacionados con el tiempo.
- Para aprovechar varias CPU en un nodo o varios nodos en un sistema distribuido
- Para aumentar la utilización de la CPU, asignando la CPU a otras actividades mientras se controla algo está suspendido esperando a que se complete alguna otra actividad (por ejemplo, acceso a algún dispositivo externo o acceso a algún otro objeto activo)
- Para priorizar actividades (y potencialmente mejorar la capacidad de respuesta)
- Para respaldar la escalabilidad del sistema (con procesos adicionales que comparten la carga)
- Separar preocupaciones entre diferentes áreas del software.
- Para lograr una mayor disponibilidad del sistema (con procesos de respaldo)
Usamos simultáneamente dos estrategias para determinar la cantidad 'correcta' de concurrencia y definir el conjunto de procesos que se necesitan. Teniendo en cuenta el conjunto de posibles arquitecturas de destino físico, podemos continuar ya sea:
- De adentro hacia afuera:Partiendo de la arquitectura lógica: defina las tareas del agente que multiplexen un solo hilo de control a través de múltiples objetos activos de una clase; objetos cuya persistencia o vida está subordinada a un objeto activo también se ejecuta en ese mismo agente; varias clases que deben ejecutarse en mutua exclusión, o que requieren solo una pequeña cantidad de procesamiento comparten un solo agente. Este agrupamiento continúa hasta que hayamos reducido los procesos a un número razonablemente pequeño que aún permite la distribución y uso de los recursos físicos.
- De fuera hacia dentro:
Empezando por la arquitectura física: identificar estímulos externos (peticiones) al sistema, definir procesos cliente para manejar los estímulos y procesos servidores que solo brindan servicios y no inician ellos; utilizar la integridad de los datos y las restricciones de serialización del problema para definir el conjunto correcto de servidores y asignar objetos a los agentes del cliente y servidores; identificar qué objetos deben distribuirse.
El resultado es un mapeo de clases (y sus objetos) en un conjunto de tareas y procesos del proceso arquitectura. Normalmente, hay una tarea de agente para una clase activa, con algunas variaciones: varios agentes para una clase dada para aumentar el rendimiento, o varias clases asignadas a un solo agente porque sus operaciones se invocan con poca frecuencia o para garantizar la ejecución secuencial.
Tenga en cuenta que este no es un proceso determinista lineal que conduce a una arquitectura de proceso óptima; se requiere unas pocas iteraciones para conseguir un compromiso aceptable . Hay muchas otras formas de proceder, como se muestra en Birman y col. 5 o Witt et al. 7 por ejemplo. El método preciso utilizado para construir el mapeo está fuera del alcance de este artículo, pero podemos ilustrarlo con un pequeño ejemplo.
La figura 12 muestra cómo se puede mapear un pequeño conjunto de clases de algún sistema hipotético de control de tráfico aéreo en procesos.
La clase de vuelo se asigna a un conjunto de agentes de vuelo, hay muchos vuelos para procesar, una alta tasa de estímulos externos, el tiempo de respuesta es crítico, la carga debe distribuirse entre varias CPU. Además los aspectos de persistencia y distribución del procesamiento del vuelo se difieren a un servidor de vuelo, que es duplicado por razones de disponibilidad.
Un perfil de vuelo o una autorización están siempre subordinados a un vuelo y aunque existen clases complejas, comparten los procesos de la clase de vuelo. Los vuelos se distribuyen a varios otros procesos, en particular para pantalla e interfaces externas.
Una clase de sectorización, que estableció una partición del espacio aéreo para la asignación de jurisdicción de los controladores sobre vuelos, debido a sus limitaciones de integridad, pueden ser manejados por un solo agente, pero pueden compartir el proceso del servidor con el vuelo: las actualizaciones son poco frecuentes.
Ubicaciones y el espacio aéreo y otra información estática aeronáutica están protegidos objetos, compartida entre varias clases, rara vez actualizadas; se mapean en su propio servidor y se distribuyen a otros procesos.
De la lógica al desarrollo
Una clase generalmente se implementa como un módulo, por ejemplo, un tipo en la parte visible de un paquete Ada. Clases grandes se descomponen en varios paquetes. Las colecciones de clases estrechamente relacionadas (categorías de clases) se agrupan en subsistemas. Se deben considerar restricciones adicionales para la definición de subsistemas, como la organización del equipo, la magnitud esperada del código (típicamente 5K a 20K SLOC por subsistema), grado de reutilización esperada y elementos comunes y principios estrictos de estratificación por capas (problemas de visibilidad), política de liberación y gestión de la configuración. Por lo tanto, solemos terminar con una vista que no tiene una correspondencia uno a uno con la visión lógica.
Las vistas lógica y de desarrollo son muy cercanas, pero abordan preocupaciones muy diferentes. Hemos encontrado que cuanto mayor sea el proyecto, mayor será la distancia entre estas vistas. Del mismo modo entre la vista de procesos y la vista física de despliegue.
Por ejemplo, si comparamos la fig. 3b y fig. 6, no hay un mapeo de uno a uno de las categorías de clase a las capas. Si tomamos las interfaces externas: categoría puerta de enlace, su implementación se distribuye en varias capas: los protocolos de comunicaciones están en subsistemas en o debajo de la capa 1, los mecanismos de puerta de enlace generales están en subsistemas en la capa 2, y las pasarelas específicas reales en subsistemas de capa 5.
Del proceso al físico de despliegue
Los procesos y los grupos de procesos se asignan al hardware físico disponible, en varias configuraciones para pruebas o implementación. Birman describe algunos esquemas muy elaborados para este mapeo en el proyecto Isis5 .
Los escenarios se relacionan principalmente con la vista lógica, en términos de las clases que se utilizan, y con la vista del proceso, cuando las interacciones entre objetos involucran más de un hilo de control.
Adaptación del modelo
No toda arquitectura de software necesita las vistas completas “4 + 1”. Las vistas que son inútiles se pueden omitir de la descripción de la arquitectura, como la vista física, si solo hay un procesador y la vista del proceso si solo hay un proceso o programa. Para sistemas muy pequeños, incluso es posible que la vista lógica y la vista de desarrollo son tan similares que no requieren descripciones separadas.
Los escenarios son útiles en todas las circunstancias.
Proceso iterativo
Witt et al, indican 4 fases para el diseño o para una arquitectura: bosquejar, organizar, especificar y optimización, subdividida en unos 12 pasos 7 . Indican que puede ser necesario dar marcha atrás. Nosotros pensamos que este enfoque es demasiado "lineal" para un proyecto ambicioso y sin precedentes. Se sabe muy poco en el final de las 4 fases para validar la arquitectura. Abogamos por un desarrollo más iterativo, si los En realidad, la arquitectura se crea un prototipo, se prueba, se mide, se analiza y luego se refina en iteraciones posteriores.
Además de permitir mitigar los riesgos asociados con la arquitectura, este enfoque tiene otro lado beneficios para el proyecto: team building, formación, conocimiento de la arquitectura, adquisición de herramientas, ejecución de procedimientos y herramientas, etc. (Estamos hablando aquí de un prototipo evolutivo, que lentamente se convierte en convertirse en el sistema, y no en prototipos exploratorios desechables.) Este enfoque iterativo también permite los requisitos para ser refinados, maduros, mejor comprendidos.
Un enfoque basado en escenarios
La funcionalidad más crítica del sistema se captura en forma de escenarios (o casos de uso). Por crítico queremos decir: funciones que son las más importantes, la razón de ser del sistema, o que tienen la mayor frecuencia de uso, o que presenten algún riesgo técnico significativo que deba ser mitigado.
Comienzo:
- Se elige una pequeña cantidad de escenarios para una iteración en función del riesgo y la criticidad. Escenarios puede sintetizarse para abstraer una serie de requisitos del usuario.
- Se implementa una arquitectura de hombre de paja. Luego, los escenarios se "escriben" para identificar los principales abstracciones (clases, mecanismos, procesos, subsistemas) como lo indican Rubin y Goldberg 6 - descompuesto en secuencias de pares (objeto, operación).
- Los elementos arquitectónicos descubiertos se establecen en los 4 planos: lógico, proceso, desarrollo y físico.
- Esta arquitectura se implementa, prueba, mide y este análisis puede detectar algunas fallas o mejora potencial.
- Se capturan las lecciones aprendidas.
La siguiente iteración puede comenzar por:
- reevaluar los riesgos,
- ampliando la paleta de escenarios a considerar
- seleccionar algunos escenarios adicionales que permitan la mitigación de riesgos o una mayor cobertura arquitectura
- Intente escribir esos escenarios en la arquitectura preliminar
- descubrir elementos arquitectónicos adicionales o, a veces, cambios arquitectónicos significativos que deben ocurrir para adaptarse a estos escenarios
- actualizar los 4 planos principales: lógico, proceso, desarrollo, físico
- revisar los escenarios existentes en función de los cambios
- actualizar la implementación (el prototipo arquitectónico) para admitir el nuevo conjunto extendido de guión.
- Prueba. Mida bajo carga, en el entorno objetivo real si es posible.
- Luego, se revisan los cinco planos para detectar el potencial de simplificación, reutilización y similitud.
- Se actualizan las pautas de diseño y la justificación.
- Capture las lecciones aprendidas.
El prototipo arquitectónico inicial evoluciona para convertirse en el sistema real. Con suerte, después de 2 o 3 iteraciones, la arquitectura misma se vuelve estable: no se encuentran nuevas abstracciones importantes, no hay nuevos subsistemas o procesos, no nuevas interfaces. El resto de la historia está en el ámbito del diseño de software, donde, por cierto, el desarrollo puede continúe usando métodos y procesos muy similares.
La duración de estas iteraciones varía considerablemente: con el tamaño del proyecto a implementar, con el número de personas involucradas y su familiaridad con el dominio y con el método, y con el grado de "sin precedentes" del sistema con esta organización de desarrollo. De ahí la duración de una iteración puede ser de 2 a 3 semanas para un proyecto pequeño (por ejemplo, 10 KSLOC) o de hasta 6 a 9 meses para un comando grande y sistema de control (por ejemplo, 700 KSLOC).
Documentando la arquitectura
La documentación producida durante el diseño arquitectónico se recoge en dos documentos:- Un Documento de Arquitectura de Software , cuya organización sigue de cerca las vistas “4 + 1” (ver fig. 13 para un esquema típico)
- Una guía de diseño de software , que captura (entre otras cosas) el diseño más importante decisiones que deben respetarse para mantener la integridad arquitectónica del sistema
Conclusión
Este modelo de vista "4 + 1" se ha utilizado con éxito en varios proyectos grandes con o sin algunos personalización y ajuste de la terminología 4 . De hecho, permitió a las distintas partes interesadas encontrar lo que quiere saber sobre la arquitectura del software. Los ingenieros de sistemas lo abordan desde la vista física, luego la vista Proceso. Usuarios finales, clientes, especialistas en datos desde la vista lógica. Jefes de proyecto, software el personal de configuración lo ve desde la vista Desarrollo.Se han propuesto y discutido otros conjuntos de puntos de vista, dentro de Rational y en otros lugares, por ejemplo Meszaros (BNR), Hofmeister, Nord y Soni (Siemens), Emery y Hilliard (Mitre) 8 , pero hemos encontrado que a menudo estos otros puntos de vista propuestos normalmente podrían plegarse en uno de los 4 que describimos. Por ejemplo una vista Costo y programa se pliega en la vista Desarrollo, una vista Datos en la vista Lógica, una Ejecución vista en una combinación de la vista de proceso y física.
Tabla 1 - Resumen del modelo de vista "4 + 1"
Expresiones de gratitud
El modelo de vista “4 + 1” debe su existencia a muchos colegas de Rational, en Hughes Aircraft of Canada, en Alcatel y otros lugares. En particular, me gustaría agradecer sus contribuciones al Cap. Thompson, A. Bell, M. Devlin, G. Booch, W. Royce, J. Marasco, R. Reitman, V. Ohnjec y E. Schonberg.
Referencias
1. D. Garlan & M. Shaw, "Una introducción a la arquitectura de software", Avances en softwareIngeniería e Ingeniería del conocimiento , vol. 1, World Scientific Publishing Co. (1993).
2. DE Perry y AL Wolf, "Fundamentos para el estudio de la arquitectura de software", ACM Software
Engineering Notes , 17 , 4, octubre de 1992, 40-52.
3. Ph. Kruchten & Ch. Thompson, “Una arquitectura distribuida orientada a objetos para Ada a gran escala Systems ”, Actas de la Conferencia TRI-Ada '94 , Baltimore, 6-11 de noviembre de 1994, ACM,
p.262-271.
4. G. Booch: Análisis y diseño orientado a objetos con aplicaciones , 2do. edición, Benjamin-Cummings Pub. Co., Redwood City, California, 1993, 589p.
5. KP Birman y R. Van Renesse, Computación distribuida confiable con el kit de herramientas de Isis, IEEE Computer Society Press, Los Alamitos CA, 1994.
6. K. Rubin y A. Goldberg, “Object Behavior Analysis” , MCCA , 35 , 9 (septiembre de 1992) 48-62
7. BI Witt, FT Baker y EW Merritt, Arquitectura y diseño de software: principios, modelos y
Methods , Van Nostrand Reinhold, Nueva York (1994) 324p.
8. D. Garlan (ed.), Actas del primer taller interno sobre arquitecturas para sistemas de software ,
CMU-CS-TR-95-151, CMU, Pittsburgh, 1995
