Philippe Kruchten propuso este modelo para describir la arquitectura de sistemas de software el cual se dio a conocer a través de un articulo publicado en 1995 y a continuación se hace un resumen del mismo.

Inicialmente hay que resaltar que el modelo 4+1 va de la mano con el estándar IEEE 1471-2000 que incluye las prácticas recomendadas para la descripción de arquitecturas en sistemas de software, basándose en diferentes puntos de vista.

Las cuatro vistas que incluye el modelo son:






1. Vista lógica

Soporta principalmente los requerimientos funcionales, que se traduce en los servicios que el sistema debería ofrecer a sus usuarios finales.

Notación



Estilo: Para la vista lógica se usa un estilo orientado a objetos. La principal guía es mantener un modelo de objetos sencillo y coherente a través de todo el sistema, evitando la prematura especialización de clases y mecanismos.

2. Vista de procesos: Incluye aspectos no funcionales como el desempeño y la disponibilidad del sistema. Se direcciona a la concurrencia y la distribución la integridad del sistema y la tolerancia a fallos. También específica que sub-proceso o hilo de control ejecuta cada operación de cada clase identificada en la vista lógica.

Notación




Estilo: Muchos estilos pueden ser usados en la vista de procesos como: tubos y filtros, cliente / servidor con sus diferentes variantes, etc.

4. Vista de desarrollo: Describe la organización estática del software en su ambiente de desarrollo.

Notación




Estilo: Se recomienda definir 4 a 6 capas de subsistemas.

3. Vista Física: Describe el mapeo del Software en el hardware y cómo esta distribuido.




Los diseñadores de software pueden organizar la descripción de sus decisiones de arquitectura en estas
cuatro vistas, y luego ilustrarlas con un conjunto reducido de casos de uso o escenarios, los cuales constituyen la quinta vista. La arqutitectura evoluciona parcialmente a partir de estos escenarios.






Para describir la arquitectura de sistemas de software intensivo, basado en el uso de puntos de vista múltiples y concurrentes. Este uso de múltiples puntos de vista permite tratar por separado las preocupaciones de la diferentes 'stakeholders' de la arquitectura: los usuarios finales, desarrolladores, ingenieros de sistemas, administradores de proyectos, etc y para manejar por separado los requisitos funcionales y no funcionales. Cada una de las cinco vistas se describe, junto con una anotación para capturarlo. Las opiniones están diseñados con una arquitectura centrada en scenariodriven, proceso de desarrollo iterativo. Palabras clave: arquitectura de software, punto de vista, diseño orientado a objetos, el proceso de desarrollo de software
Introducción
Todos hemos visto muchos libros y artículos en un esquema de trata de captar la esencia de la arquitectura de un sistema. Pero si miramos cuidadosamente el conjunto de cajas y flechas que aparecen en estos diagramas, se hace evidente que sus autores se han esforzado mucho para representar a más de un modelo de lo que realmente pueden expresar. ¿Son
las cajas que representan programas que se ejecutan? O trozos de código fuente? O equipos físicos? ¿O simplemente agrupaciones lógicas de funcionalidad? ¿Son las flechas que representan las dependencias de compilación? O el control
los flujos? O los datos de los flujos? Por lo general, es un poco de todo. ¿Se necesita una arquitectura de una sola arquitectura estilo? A veces la arquitectura del software sufre cicatrices de un diseño del sistema que fue demasiado lejos en
prematuramente la partición del software, o de un excesivo hincapié en un aspecto de desarrollo de software:
eficiencia de la ingeniería de datos, o tiempo de ejecución o desarrollo de la estrategia y el equipo de organización. A menudo, también el la arquitectura no se ocupa de las preocupaciones de todos sus "clientes" (o "partes interesadas", como se les llama en el
USC). Este problema ha sido señalado por varios autores: Garlan y Shaw1, Abowd y Allen en la CMU, Clements en el SEI. Como remedio, se propone la organización de la descripción de una arquitectura de software usando varios puntos de vista simultáneos, cada uno frente a un conjunto específico de las preocupaciones.

Un modelo de arquitectura
Arquitectura de software se ocupa de la elaboración y ejecución de la estructura de alto nivel del software. lo es el resultado de ensamblar un cierto número de elementos arquitectónicos en algunas formas bien escogidas para satisfacer la principal funcionalidad y los requisitos de rendimiento del sistema, así como algún otro, no funcionales requisitos tales como la fiabilidad, escalabilidad, portabilidad, y la disponibilidad. Perry y Wolfe lo puso muy bien
en este formula2, modificado por Boehm:
Arquitectura del software = {Elementos, Formas, Motivación / Restricciones}
Arquitectura de software se refiere a la abstracción, con descomposición y composición, con el estilo y la estética.
Para describir una arquitectura de software, se utiliza un modelo compuesto de múltiples puntos de vista o perspectivas. Para finalmente frente a las arquitecturas de grandes y desafiantes, el modelo que proponemos se compone de cinco principales puntos de vista
(v. fig 1.):
• El punto de vista lógico, que es el modelo de objetos de diseño (cuando un método de diseño orientado a objetos es se utiliza),
• el proceso de juicio, que capta los aspectos de concurrencia y la sincronización del diseño,
• el punto de vista físico, el cual se describe la asignación (s) del software en el hardware y refleja su aspecto distribuido,
2
• el desarrollo vista, que describe la organización estática del software en su desarrollo
medio ambiente.
La descripción de una arquitectura de las decisiones tomadas, se pueden organizar en torno a estos cuatro puntos de vista y
a continuación se ilustra en los pocos casos de uso o escenarios seleccionados, que se convierten en un quinto punto de vista. La arquitectura es, en hecho parcialmente evolucionado a partir de estos escenarios, como veremos más adelante.


Nosotros aplicamos la ecuación de Perry y Wolf de forma independiente en cada punto de vista, es decir, por cada punto de vista se define el conjunto de los elementos a utilizar (componentes, contenedores y conectores), captamos las formas y patrones que trabajan, y
captamos la justificación y las limitaciones, la conexión de la arquitectura de algunos de los requisitos.
Cada vista se describe por un modelo con su notación particular. Para cada punto de vista también, los arquitectos puede elegir un estilo arquitectónico determinado, por lo tanto, lo que permite la coexistencia de múltiples estilos en un solo sistema.
Ahora se verá, a su vez en cada uno de los cinco puntos de vista, indicando para cada uno su objetivo: que las preocupaciones son las direcciones, una notación para el modelo correspondiente de arquitectura, las herramientas que hemos utilizado para describir y gestionarlo.
Pequeños ejemplos se han extraído de el diseño de una centralita telefónica, derivada de nuestro trabajo en el Sistema de Empresas de Alcatel y un control de tráfico aéreo SYSTEM3, pero en forma muy simplificada, la intención aquí es sólo para dar una idea de los puntos de vista y su notación y no para definir la arquitectura de estos sistemas.
El "4 +1" modelo de punto de vista es más "genérico": otras notaciones y herramientas se pueden utilizar otros métodos de diseño puede
ser utilizado, especialmente para el y las descomposiciones lógicas y proceso, pero nos han indicado los que hemos han utilizado con éxito.


La arquitectura lógica
La descomposición orientada a objetos
La arquitectura lógica apoya principalmente los requisitos funcionales-lo que el sistema debería proporcionar, en términos de servicios a sus usuarios. El sistema se descompone en una serie de posibles abstracciones clave, tomado (la mayoría) de el dominio del problema, en la forma de objetos o clases de objetos. Explotan los principios de la abstracción,
encapsulación y la herencia. Esta descomposición no es sólo por el bien de análisis funcional, sino también sirve para identificar mecanismos comunes y elementos de diseño a través de las diversas partes del sistema. Usamos El enfoque racional / Booch para representar la arquitectura lógica, por medio de diagramas de clases y la clase templates.4 Un diagrama de clases muestra un conjunto de clases y sus relaciones lógicas: la asociación, el uso,
composición, herencia, y así sucesivamente. Los conjuntos de clases relacionadas se pueden agrupar en categorías de clase. clase plantillas de centrarse en cada clase se hace hincapié en las operaciones principales de la clase, e identificar los objetos clave
características. Si es importante para definir el comportamiento interno de un objeto, esto se hace con transición de estado diagramas o gráficos del estado. Los mecanismos comunes o servicios se definen en los servicios públicos de clase.
Como alternativa a un enfoque orientado a objetos, una aplicación que está muy por datos podrá utilizar algún otro tipo de lógica punto de vista, tales como E-R diagramas.
Notación para el punto de vista lógico
La notación para la vista lógica se deriva de la Booch notation4. Se ha simplificado considerablemente para tomar en cuenta únicamente los elementos que son relevantes para la arquitectura. En particular, los adornos son numerosas no es muy útil en este nivel de diseño. Usamos Rational Rose ® para apoyar el diseño de arquitectura lógica.
Estilo para el punto de vista lógico
El estilo que usamos para el punto de vista lógico es un estilo orientado a objetos. La directriz principal para el diseño de la punto de vista lógico es tratar de mantener un único modelo de objeto coherente en todo el sistema, para evitar la eyaculación
especialización de las clases y los mecanismos por sitio o por procesador.
4
Ejemplos de modelos lógicos
La figura 3a muestra las clases principales que participan en la arquitectura de Telic PABX.
}
La Arquitectura de Procesos
El proceso de descomposición
La arquitectura de procesos se tienen en cuenta algunos requisitos no funcionales, tales como el rendimiento y la disponibilidad. Se ocupa de cuestiones relativas a la concurrencia y distribución, de la integridad del sistema, de la tolerancia a fallos, y cómo las abstracciones principales de la forma vista lógica en el proceso de la arquitectura sobre la cual hilo de
control es una operación para un objeto realmente ejecutado.
La arquitectura de proceso puede ser descrito en varios niveles de abstracción, cada nivel de abordar diferentes preocupaciones. Al más alto nivel, la arquitectura de procesos puede ser visto como un conjunto de forma independiente de ejecución redes lógicas de los programas de comunicación (llamados "procesos"), distribuidos a través de un conjunto de hardware
recursos conectados por una red LAN o WAN. Múltiples redes lógicas pueden existir al mismo tiempo, compartir la mismos recursos físicos. Por ejemplo, redes lógicas independientes pueden ser utilizado para apoyar la separación de el sistema operativo on-line del sistema off-line, así como el apoyo a la convivencia de la simulación o versiones de prueba del software.
Un proceso es un conjunto de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que el arquitectura de procesos puede ser tácticamente controlado (es decir, empezar, recuperar, reconfigurar y apagado). En 5
Además, los procesos pueden ser replicados para su distribución aumentó de la carga de procesamiento, o para la mejora disponibilidad.
El software se divide en un conjunto de tareas independientes. Una tarea es un hilo de control separado, que puede ser programado de forma individual en el nodo de procesamiento.
Podemos distinguir entonces: las tareas más importantes, que son los elementos arquitectónicos que pueden ser abordados únicamente y tareas de menor importancia, que son tareas adicionales introducidos a nivel local por razones de aplicación (actividades cíclicas, de almacenamiento en búfer, el tiempo de espera, etc). Ellos pueden ser implementados como tareas Ada por ejemplo, o hilos de peso ligero.
Las principales tareas comunicarse a través de un conjunto de mecanismos bien definidos de comunicación entre tareas: sincrónica y asíncrono de mensajes basados ​​en los servicios de comunicación, las llamadas a procedimientos remotos, la difusión de eventos, etc Menor
tareas pueden comunicarse por encuentro o de la memoria compartida. Las principales tareas no se hacen suposiciones acerca de su colocación en el mismo proceso o nodo de procesamiento.
Flujo de mensajes, las cargas de proceso pueden ser estimados con base en el modelo de proceso. También es posible a implementar un "hueco" arquitectura de procesos con cargas ficticias para los procesos, y medir su el rendimiento en el sistema objetivo, como se describe por Filarey et al. en su experimento de Eurocontrol.