UNIVERSIDAD ANDINA DEL CUSCO

FACULTAD DE INGENIERA

CARRERA PROFESIONAL DE INGENIERA

DE SISTEMAS

TEMA

4+1 Vistas
(Modelo de Arquitectura de
Software)
CURSO

Programacin Avanzada

DOCENTE

Ing. Amrico Estrada Snchez

ALUMNO

Cesar Jordano Moscoso Yarn

CUSCO 2014
Pgina 1 de 15

Indice
Indice

Introduccin

4+1 Vistas

Qu es 4+1 Vistas?

Las 5 Vistas

La vista Logica

Notacin para la vista lgica

Estilo para la vista lgica

La vista de Proceso

Particionamiento

Notacin

Estilo

La vista de Desarrollo

Notacin

Estilo

La vista Fisica

Notacin

10

Ejemplo

10

La vista de uso(escenarios)
Notacin

Correspondencia entre Vistas

Desde vista lgica a vista de proceso

10
11

11
11

En el interior de salida:

12

Fuera de entrada:

12

Desde vista lgica a vista de desarrollo

13

Desde vista de proceso a vista fisica

13

Conclusiones

14

Bibliografia

15

Pgina 2 de 15

Introduccin
En noviembre de 1995, mientras trabajada como lder de Arquitectura de Software en
Hughes Aircraft Of Canada, Philippe Kruchten publico un Paper llamado: "Architectural
BlueprintsThe 4+1 View Model of Software Architecture . El intento fue de traer un
mecanismo para separar los diferentes aspectos de un Sistema de Software en diferentes
formas de ver el sistema. Esto debido a que diferentes participantes siempretenandiferentes
intereses en el sistema de software. Algunos aspectos del sistema eran importantes para los
desarrolladores, otros eran relevantes para los administradores del sistema. Los
desarrolladores queran saber acerca de cosas como las clases, los administradores del
sistemas queran saber acerca del despliegue,hardware y configuraciones de red y no les
importaban las clases. Temas similares podran ser los Testers, lderes de proyecto o clientes.
Kruchten penso que esto era una razn importante para descomponer la arquitectura en
distintas vistas para que los participantes pueden tener lo que quieren. Eldecididollamarlo no 5
vistas sino 4 vistas +1 ya que la ultima, la vista del cliente es la masimportante.

Pgina 3 de 15

4+1 Vistas

Qu es 4+1 Vistas?
El Modelo de 4+1 vistas fue desarrollado para remediar el problema de las diferentes
percepciones de un sistema, de esta manera el Modelo 4+s vistas consiste en enfocar el sistema
a diferentes tipos deobservadores usando 5 vistas diferentes.

Las 5 Vistas
La vista Logica
La arquitectura lgica apoya principalmente los requisitos funcionales que representa lo que el
sistema debe proporcionar en trminos de servicios a sus usuarios. El sistema se descompone en
un conjunto de abstracciones clave, tomadas (en su mayora) desde el dominio del problema, en
la forma de objetos o clases de objetos. Explotan los principios de la abstraccin, encapsulacin
y herencia. Esta descomposicin no es slo por el bien del anlisis funcional, sino que tambin
sirve para identificar mecanismos comunes y elementos de diseo a travs de las diversas partes
del sistema. Utilizamos el enfoque racional / Booch para la representacin de la arquitectura
lgica, por medio de diagramas de clases y plantillas de clase. Un diagrama de clases muestra un
conjunto de clases y sus relaciones lgicas: asociacin, el uso, la composicin, la herencia, y as
sucesivamente.
Un Conjunto de clases relacionadas se pueden agrupar en categoras de clase. Una Plantilla de
clase se centra en cada clase individual; destaca las operaciones principales de la clase, e
identifica las caractersticas clave del objeto. Para definir el comportamiento interno de un
objeto, se hace diagramas de transicin de estado, o grficos de estado. Los mecanismos o
servicios comunes se definen en los servicios pblicos de la clase.
Como alternativa a un enfoque orientado a objetos, una aplicacin que es impulsada por datos
puede utilizar alguna otra forma de vista lgica, tal como el diagrama ER.

Pgina 4 de 15

Notacin para la vista lgica

La notacin para la vista lgica se deriva de la notation de Booch. Se simplifica
considerablemente al tener en cuenta slo los elementos que son de gran importancia
arquitectnica. En particular, los numerosos adornos no son muy tiles en este nivel de diseo.
Utilizamos Rational Rose para apoyar el diseo de arquitectura lgica.

Estilo para la vista lgica

El estilo que utilizamos para la vista lgica es un estilo orientado a objetos. La directriz principal
para el diseo de la vista lgico es tratar de mantener un nico modelo, objeto coherente en
todo el sistema, para evitar la especializacin prematura de las clases y los mecanismos por sitio
o por procesador.

La vista de Proceso
La arquitectura de procesos tiene en cuenta algunos requisitos no funcionales, como el
rendimiento y la disponibilidad. Aborda temas de concurrencia y distribucin, de la integridad
del sistema, de la tolerancia a fallos, y cmo las principales abstracciones de la vista en forma
lgica dentro del proceso de la arquitectura-en el que el hilo de control es una operacin de un
objeto realmente ejecutado.
La arquitectura de procesos puede ser descrito en varios niveles de abstraccin, cada nivel de
abordar diferentes inquietudes. En el nivel ms alto, la arquitectura de proceso puede ser visto
como un conjunto de ejecuciones independientes de redes lgicas de los programas que se
comunican (llamado "procesos"), distribuido a travs de un conjunto de recursos de hardware
conectados por una LAN o una WAN. Pueden existir simultneamente mltiples redes lgicas,
compartiendo los mismos recursos fsicos.
Pgina 5 de 15

Por ejemplo, redes lgicas independientes pueden ser utilizadas para apoyar la separacin del
sistema operativo en lnea desde el sistema fuera de lnea, as como el apoyo a la coexistencia de
versiones de simulacin o de prueba del software.
Un proceso es un conjunto de tareas que forman una unidad ejecutable. Los procesos
representan el nivel en que la arquitectura de proceso puede ser controlado tcticamente (es
decir, comenz, recuperadas, re configurado, y cierran). Adicionalmente, los procesos pueden ser
replicados para una mayor distribucin de la carga de procesamiento, o para la mejora de la
disponibilidad.
El software se divide en un conjunto de tareas independientes. Una tarea es un hilo de control
separado, que se pueden programar individualmente en un nodo de procesamiento.
Podemos distinguir entonces: las tareas principales, que son los elementos arquitectnicos que
se pueden abordar de forma nica y las tareas de menor importancia, que son tareas adicionales
introducidos a nivel local por razones de implementacin (actividades cclicas, buering, los
tiempos de espera, etc.). Las principales tareas se comunican a travs de un conjunto de
mecanismos bien definidos entre las tareas de comunicacin: servicios de comunicacin
basados en mensajes sncronos y asncronos, llamadas a procedimientos remotos, difusin de
eventos, etc. tareas menores pueden comunicarse por cita o memoria compartida. Tareas
principales no debern hacer suposiciones acerca de su colocacin en el mismo proceso o nodo
de procesamiento.
Flujo de mensajes, cargas de proceso puede ser estimado basado en el modelo de proceso.
Tambin es posible implementar una arquitectura de procesos "hueco" con cargas ficticias para
los procesos, y medir su rendimiento en el sistema de destino, tal como se describe por Filarey et
al. en su experimento Eurocontrol.

Particionamiento
Para desarrollar la vista de proceso, los diseadores participan el software en un conjunto de
pruebas independientes, separadas por hilos de control que pueden ser individualmente
organizadas y separadas en nodos de procesamiento.
Se separan las pruebas en dos grupos:
Pruebas mayores: son elementos de arquitectura que pueden ser direccionados nicamente.
Estos se comunican a travs de mecanismos de intercomunicacin:mensajes sncronos
oasncronosbasados encomunicacin de servicios.
Pruebas Menores:Son pruebas adicionales introducidas localmente para la implementacin de
razones como actividadescclicas, buering, etc. Estos pueden ser implementados como hilos.

Pgina 6 de 15

Notacin
La notacin que se utilizo para la visin de proceso se expande desde la notacin originalmente
propuesto por Booch para Ada tareas. Una vez ms la notacin utilizada se centra en los
elementos que son de gran importancia arquitectnica.
Se ha utilizado el producto Universal Network Services Architecture (UNAS) de TRW para la
arquitectura y aplicar el conjunto de procesos y tareas (y sus redundancias) en redes de
procesos. UNAS contiene una herramienta de Software Arquitectos del ciclo de vida para el
Medio Ambiente (VENTA) -que apoya una notacin. VENTA permite la representacin grfica de
la arquitectura de procesos, incluyendo especificaciones de las posibles vas de comunicacin
entre las tareas, desde la que se genera de forma automtica el Ada correspondiente o cdigo
fuente en C ++.
El beneficio de este enfoque para la especificacin y la implementacin de la arquitectura de
procesos es que los cambios se pueden incorporar fcilmente sin mucho impacto en el software
de aplicacin.

Estilo
Varios estilos intervienen en la vista del proceso. Por ejemplo, la cosecha de Garlan y
la Taxonoma de Shaw podemos tener: tubos y filtros, o cliente / servidor, con variantes
mltiples de cliente / servidor nico y varios clientes / servidores mltiples. Para sistemas ms
complejos, se podra utilizar un estilo similar al enfoque de grupos de procesos del sistema ISIS
como se describe por K. Birman con otra notacin y conjunto de herramientas.

Pgina 7 de 15

La vista de Desarrollo
La vista de desarrollo de centra en los modelos de software y sub sistemas. En UML, los
diagramas de paquetes y componentes son usados para modelar la vista del desarrollador.
La arquitectura de desarrollo se centra en la organizacin actual del mdulo de software en el
entorno de desarrollo de software. El software se envasa en pequeos trozos-bibliotecas de
programas, o subsystems- que pueden ser desarrolladas por uno o un pequeo nmero de
desarrolladores. Los sub sistemas se organizan en una jerarqua de capas, cada capa que
proporciona una interfaz estrecho y bien definido para las capas por encima de ella.
La arquitectura de desarrollo del sistema est representada por diagramas de mdulos y sub
sistemas, que muestra las relaciones 'importacin y ' exportacin' . La arquitectura de
desarrollo completo slo puede ser descrito cuando se han identificado todos los elementos del
software. Es, sin embargo, posible hacer una lista de las normas que rigen la arquitectura de
desarrollo: creacin de particiones, de agrupacin, de visibilidad.
En su mayor parte, la arquitectura de desarrollo tiene en cuenta los requisitos internos
relacionados con la facilidad de desarrollo, gestin de software, reutilizacin o comn, y las
restricciones impuestas por el conjunto de herramientas, o el lenguaje de programacin. El
punto de vista del desarrollo sirve como base para la asignacin de requisito, para la asignacin
de trabajo a los equipos (o incluso para la organizacin del equipo), para la evaluacin de los
costos y la planificacin, para el seguimiento de los avances del proyecto, para el razonamiento
sobre la reutilizacin del software, portabilidad y seguridad. Es la base para el establecimiento
de una lnea de producto.

Notacin
El entorno de desarrollo de Apex racional apoya la definicin y la implementacin de la
arquitectura de desarrollo, la estrategia de estratificacin se ha descrito anteriormente, y la
aplicacin de las reglas de diseo. Rational Rose puede dibujar los planos de desarrollo a nivel de
mdulo y subsistema, en la ingeniera directa y por la ingeniera inversa del cdigo fuente de
desarrollo, para Ada y C ++.

Pgina 8 de 15

Estilo
Se recomienda la adopcin de un estilo en capas para la vista del desarrollo, la definicin de
algunos de 4 a 6 capas de sub sistemas. Cada capa tiene una responsabilidad bien definida. La
regla de diseo es que un sub sistema en un determinado slo puede depender de sub sistema
que estn en la misma capa o en capas por debajo, con el fin de minimizar el desarrollo de redes
muy complejas de dependencias entre mdulos y permitir estrategias de liberacin sencilla capa
por capa.

La vista Fisica
La vista fsica describe el despliegue fsico del sistema. Por ejemplo, cuantos nodos son usados y
por que esta desarrollado en ese nodo. Por ello, la vista fsica concierne requerimientos no
funcionales como la estabilidad y la disponibilidad. En UML, diagramas de despliegue son
usados para modelar el modelofsico.
La arquitectura fsica tiene en cuenta principalmente los requisitos no funcionales del sistema,
tales como la disponibilidad, la fiabilidad (tolerancia a fallos), rendimiento (throughput), y la
escalabilidad. El software se ejecuta en una red de computadoras, o nodos de procesamiento (o
simplemente nodos para abreviar). Redes de los diversos elementos identificado-, procesos,
tareas y objetos necesitan ser mapeadas a los distintos nodos. Esperamos que se utilizarn
varias configuraciones fsicas diferentes: algunos para el desarrollo y las pruebas, otros para el
despliegue del sistema para varios sitios o de los diferentes clientes. El mapeo del software a los
nodos, por tanto, necesita ser altamente flexible y tener un impacto mnimo en el propio cdigo
fuente.

Pgina 9 de 15

Notacin
Planos fsicos pueden llegar a ser muy desordenado en grandes sistemas, por lo que tomar
varias formas, con o sin el mapeo de la vista del proceso.

Ejemplo

La vista de uso(escenarios)
Esta vista describe la funcionalidad del sistema desde la perspectiva desde afuera. Esto
contiene diagramas describiendo por que el sistema esta haciendo esas tareas. Normalmente
contiene diagramas de casos de uso. Otras vistas usan esta vista como base y guiarse.
Los elementos de las cuatro vistas trabajan juntos sin problemas por el uso de un pequeo
conjunto de escenarios importantes(instancias) de uso general y tambin situaciones para los
que se describen las secuencias de comandos correspondientes (secuencias de interacciones
entre los objetos, y entre procesos) como se describe por Rubin y Goldberg. Los escenarios son
en cierto sentido, una abstraccin de los requisitos ms importantes. Su diseo se expresa
utilizando diagramas de escenarios de objetos y diagramas de interaccin de objetos.
Este punto de vista es redundante con los otros (de ah el +1"), pero tiene dos propsitos
principales:
Cmo un conductor para descubrir los elementos arquitectnicos durante el diseo de la
arquitectura como describiremos ms adelante.
Cmo una funcin de validacin y la ilustracin despus de este diseo de la arquitectura
es completa, tanto en papel como como la de punto de partida para las pruebas de un
prototipo arquitectnico.
Pgina 10 de 15

Notacin
La notacin es muy similar a la vista lgica para los componentes, pero utiliza los conectores de
la vista de proceso para las interacciones entre los objetos. Tenga en cuenta que las instancias
de objetos se denotan con lneas slidas. En cuanto al modelo lgico, capturamos y
administramos los diagramas de escenarios de objetos utilizando Rational Rose.

Correspondencia entre Vistas

Los diferentes puntos de vista no son totalmente independientes. Los elementos de una vista
estn conectados a elementos en otras vistas, siguiendo ciertas reglas de diseo y heursticas.

Desde vista lgica a vista de proceso

Identificamos varias caractersticas importantes de las clases de la arquitectura lgica:
Autonoma: son los objetos activo, pasivo y protegido.
1. Objeto activo: una toma la iniciativa de invocar operaciones de otros objetos o de sus
propias operaciones, y tiene control total sobre la invocacin de sus propias
operaciones por otros objetos.
2. Objeto pasivo: nunca invoca espontneamente ninguna operacin y no tiene ningn
control sobre la invocacin de sus propias operaciones por otros objetos.
3. Objeto protegido: nunca invoca espontneamente ninguna operacin pero realiza
alguna de arbitraje en lainvocacin de sus operaciones.
Persistencia: Los objetos son permanentes.
Subordinacin: La existencia o persistencia de un objeto puede estar en funcin de otro
objeto.
Distribucin: Son los estados de las operaciones de un objeto accesible desde muchos
nodos de la visin fsica.
En la vista lgica de la arquitectura consideramos cada objeto como activo, y potencialmente
"concurrente", es decir, comportarse "en paralelo" con otros objetos, y no prestamos ms
atencin al grado exacto de la concurrencia que necesitamos para lograr este efecto. Por lo
tanto la arquitectura lgica tiene en cuenta slo el aspecto funcional de los requisitos.
Sin embargo, cuando llegamos a la definicin de la arquitectura de procesos, implementacin de
cada objeto con su propio hilo de control (por ejemplo, su propio proceso Unix o tarea Ada) no
es muy prctico en el estado actual de la tecnologa, debido a la enorme sobrecarga que esto
impone. Por otra parte, si los objetos son concurrentes, debe haber alguna forma de arbitraje
para invocar sus operaciones.

Pgina 11 de 15

Por otro lado, se necesitan mltiples hilos de control por varias razones:
Para reaccionar rpidamente a ciertas clases de estmulos externos, incluyendo los
eventos relacionados con el tiempo.
Para aprovechar las ventajas de mltiples CPUs en un nodo, o varios nodos en un sistema
distribuido.
Para aumentar la utilizacin de la CPU, mediante la asignacin de la CPU para otras
actividades, mientras que un poco de hilo de control de se suspende a la espera de alguna
otra actividad para completar (por ejemplo, acceso a algn dispositivo externo, o el acceso
a algn otro objeto activo).
Priorizar las actividades (y, potencialmente, mejorar la capacidad de respuesta).
Apoyar a la escalabilidad del sistema (con procesos adicionales compartiendo la carga).
Para separar preocupaciones entre diferentes reas del software.
Para lograr una mayor disponibilidad del sistema (con los procesos de copia de seguridad).
Utilizamos concurrentemente dos estrategias para determinar la cantidad "correcta" de la
concurrencia y definir el conjunto de procesos que son necesarios. Teniendo en cuenta el
conjunto de posibles arquitecturas objetivo fsicas, podemos proceder ya sea:

En el interior de salida:
A partir de la arquitectura lgica: definir tareas de agente que multiplexar solo hilo de control a
travs de mltiples objetos activos de una clase; objetos cuya persistencia o vida est
subordinada a un objeto activo tambin se ejecutan en ese mismo agente; varias clases que
deben ser ejecutados en la exclusin mutua, o que requieren slo una pequea cantidad de la
cuota de procesamiento de un nico agente. Esta agrupacin procede hasta que hemos reducido
los procesos a un nmero razonablemente pequeo que todava permite la distribucin y el uso
de los recursos fsicos.

Fuera de entrada:
A partir de la arquitectura fsica: identificar los estmulos externos (solicitudes) al sistema,
definir los procesos de cliente para manejar los estmulos y los servidores de procesos que slo
prestan servicios y no inician ellos; utilizar la integridad de los datos y de serializacin
restricciones del problema de definir el conjunto adecuado de servidores, y asignar objetos a los
agentes de cliente y servidores; identificar qu objetos debe ser distribuido.
El resultado es un mapeo de clases (y sus objetos) en un conjunto de tareas y procesos de la
arquitectura de procesos. Tpicamente, 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 mapeadas a un solo agente debido a que sus operaciones se invocan con poca frecuencia
o para garantizar la ejecucin secuencial.

Pgina 12 de 15

Desde vista lgica a vista de desarrollo

Una clase se implementa normalmente como un mdulo, por ejemplo, un tipo en la parte
visible de un paquete de Ada. Clases grandes se descomponen en varios paquetes. Colecciones
de estrechamente relacionadas categoras-clases-clase se agrupan en sub sistemas.
Restricciones adicionales deben ser considerados para la definicin de los sub sistemas, tales
como la organizacin del equipo, la magnitud esperada de cdigo (normalmente 5K a 20K SLOC
por sub sistema), el grado de reutilizacin se esperaba, y los principios de estratificacin
estrictas (cuestiones de visibilidad), la poltica de la liberacin y la configuracin gestin. Por lo
tanto, por lo general terminamos con una vista que no tiene una correspondencia uno a uno con
el punto de vista lgico.
Las vistas lgicas y de desarrollo estn muy cerca, pero abordan muy diferentes preocupaciones.
Hemos encontrado que cuanto mayor sea el proyecto, mayor es la distancia entre estos puntos
de vista. Del mismo modo para el proceso y vistas fsicas: cuanto mayor sea el proyecto, mayor
es la distancia entre los puntos de vista. Por ejemplo, si comparamos fig. 3b y fig. 6, no hay una
hasta un mapeo de las categoras de clase a las capas. Si tomamos las 'interfaces de puerta de
enlace externos' categora, su aplicacin se extiende a travs de varias capas: protocolos de
comunicacin estn en sub sistemas en o por debajo de la capa 1, los mecanismos generales de
pasarela estn en los sub sistemas de la capa 2, y las puertas de enlace especficas reales en capa
de 5 sub sistemas .

Desde vista de proceso a vista fisica

Procesos y grupos de procesos se mapean en el hardware fsico disponible, en varias
configuraciones para las pruebas o despliegue. Los escenarios se refieren sobre todo a la vista
lgica, en trminos de los que se utilizan las clases, ya la vista del proceso, cuando las
interacciones entre objetos implican ms de un hilo de control.

Pgina 13 de 15

Conclusiones
Este modelo de vista "4 + 1" se ha utilizado con xito en varios proyectos grandes con o sin algn
tipo de personalizacin local y ajuste en terminologa. En realidad, permiti a las distintas partes
interesadas a encontrar lo quequiere saber acerca de la arquitectura de software. Los ingenieros
de sistemas de aproximacin desde el punto de vista fsico, entonces la vista del proceso. Los
usuarios finales, clientes, especialistas de datos desde el punto de vista lgico. Los gerentes de
proyecto, personal de configuracin de software lo ven desde el punto de vista de desarrollo.
Se han propuesto otros conjuntos de vistas y discutidas, dentro racional 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 por lo general podra
ser doblado en una de las 4 describimos. Por ejemplo, un punto de vista de costos y horario se
pliega en la opinin de Desarrollo, una Vista de datos en el punto de vista lgico, una vista de
ejecucin en una combinacin de los procesos y vista fsico

Pgina 14 de 15

Bibliografia
TITULO : The 4+1 View Model of Architecture
AUTOR: Philippe Kruchten
Rational Software Corp. 638-650 West 41stAvenue
Vancouver, B.C., V5Z 2M9 Canada
FUENTE: International Christian School
URL : http://www.ics.uci.edu/~andre/ics223w2006/kruchten3.pdf
FECHA DE INGRESO : 29/10/2014
TITULO :The Decision View of Software Architecture: Building by Browsing
AUTORES:
Juan C. Dueas
Department of Engineering of Telematic Systems, ETSI Telecomunicacin, Universidad
Politcnica de Madrid, Ciudad Universitaria s/n, 28040 Madrid, Espaa
Rafael Capilla
Department of Informatics and Telematics, Universidad Rey Juan Carlos, c/ Tulipan s/n, 28933,
Madrid, Espaa
URL :http://eciencia.urjc.es/bitstream/10115/3187/1/dueas-rcapilla.pdf
FECHA DE INGRESO : 29/10/2014
TITULO :The 4+1 View Model of Software Architecture
AUTOR:Alex Staveley
Alex Staveley is a software professional passionate about software engineering and technical
architecture.
Department of Informatics and Telematics, Universidad Rey Juan Carlos, c/ Tulipan s/n, 28933,
Madrid, Espaa
FUENTE: Alex Staveleys Blog
URL :http://dublintech.blogspot.com/2011/05/41-view-model-of-software-architecture.html
FECHA DE INGRESO : 29/10/2014
TITULO :Architectural BlueprintsThe 4+1 View Model of Software Architecture
AUTOR:Philippe Kruchten
Rational Software Corp. 638-650 West 41stAvenue
Vancouver, B.C., V5Z 2M9 Canada
FUENTE: Eindhoven University of Technology (TU/e) is a research university specializing in
engineering science & technology - Holanda
URL :http://www.win.tue.nl/~wstomv/edu/2ip30/references/Kruchten-4+1-view.pdf
FECHA DE INGRESO : 29/10/2014

Pgina 15 de 15