Uml 4+1

En Rational, aplicamos la f´rmula de Dwayne Perry y Alexander Wolf [9] de manera independiente para o cada vista:
Arquitectura del software = {Elementos, Formas, Motivaci´n/Restricciones} o

Planos Arquitect´nicos: El Modelo de “4+1” Vistas de la o Arquitectura del Software∗

Philippe Kruchten

Abstract

Para cada vista definimos un conjunto de elementos (componentes, contenedores yconectores), captamos la forma y los patrones con que trabajan, y captamos la justificaci´n y las restricciones, relacionando la o arquitectura con algunos de sus requisitos. Cada vista se describe en lo que llamamos “diagrama” (blueprint) que usa su notaci´n particular. Los o arquitectos tambi´n pueden usar estilos de arquitectura para cada vista, y por lo tanto hacer que coexistan e distintos estilosen un mismo sistema. El modelo de 4+1 vistas es bastante gen´rico: se puede usar otra notaci´n y herramientas que las aqu´ e o ı ı e e n o descritas, as´ como tambi´n otros m´todos de dise˜ o, especialment para las descomposiciones l´gica y de procesos.

Este art´ ıculo presenta un modelo para describir la arquitectura de sistemas de software, bas´ndose a en el uso de m´ ltiples vistasconcurrentes. Este uso de m´ ltiples vistas permite abordar los intereses u u de los distintos “stakeholders” de la arquitectura por separado: usuarios finales, desarrolladores, ingenieros de sistemas, administradores de proyecto, etc., y manejar los requisitos funcionales y no funcionales separadamente. Se describe cada una de las cinco vistas descritas, conjuntamente con la notaci´n para o captarla. Lasvistas se dise˜ an mediante un proceso centrado en la arquitectura, motivado por escenarios n y desarrollado iterativamente.

2

El Modelo de 4+1 Vistas

1

Introducci´n o

La arquitectura del software se trata de abstracciones, de descomposici´n y composici´n, de estilos y est´tica. o o e Trambi´n tiene relaci´n con el dise˜o y la implementaci´n de la estructura de alto nivel delsoftware. e o n o Los dise˜adores construyen la arquitectura usando varios elementos arquitect´nicos elegidos apropiadan o mente. Estos elementos satisfacen la mayor parte de los requisitos de funcionalidad y performance del sistema, as´ como tambi´n otros requisitos no funcionales tales como confiabilidad, escalabilidad, portabilidad y ı e disponibilidad del sistema.

Todos hemos visto muchos libros yart´ ıculos donde se intenta capturar todos los detalles de la arquitectura de un sistema usando un unico diagrama. Pero si miramos cuidadosamente el conjunto de cajas y flechas que ´ muestran estos diagramas, resulta evidente que sus autores han trabajado duramente para intentar representar m´s de un plano que lo que realmente podr´ expresar la notaci´n. ¿Es acaso que las cajas representan a ıa oprogramas en ejecuci´n? ¿O representan partes del c´digo fuente? ¿O computadores f´ o o ısicos? ¿O acaso meras agrupaciones de funcionalidad? ¿Las flechas representan dependencias de compilaci´n? ¿O flujo de control? o Generalmente es un poco de todo. ¿Ser´ que una arquitectura requiere un estilo unico de arquitectura? A veces la arquitectura del software a ´ tiene secuelas de un dise˜ o del sistemaque fue muy lejos en particionar prematuramente el software, o de un n ´nfasis excesivo de algunos de los aspectos del desarrollo del software: ingenier´ de los datos, o eficiencia en e ıa tiempo de ejecuci´n, o estrategias de desarrollo y organizaci´n de equipos. A menudo la arquitectura tampoco o o aborda los intereses de todos sus “clientes”. Varios autores han notado este problema, incluyendoa David Garlan y Mary Shaw [7], Gregory Abowd y Robert Allen [1], y Paul Clements [4]. El modelo de 4+1 vistas fue desarrollado para remediar este problema. El modelo 4+1 describe la arquitectura del software usando cinco vistas concurrentes. Tal como se muestra en la Figura 1, cada vista se refiere a un conjunto de intereses de diferentes stakeholders del sistema. Figure 1: Modelo de “4+1”...