INSTITUTO TECNOLGICO DE CULIACN

INGENIERA EN SISTEMAS COMPUTACIONALES Ingeniera del software orientada a objetos

Ensayo: Modelo 4+1 Vistas

Profesora: Valenzuela Tirado Martha Estela

Alumno: Contreras Nieblas Alberto Leonel

Fecha de entrega: 11/02/2013

1. ndice: 2. Introduccin.............................................................................. 2 3. Modelo 4+1 vistas ... 2 3.1. Las distintas vistas del modelo 2 3.1.1. Vista lgica.. 2 3.1.2. Vista de proceso2 3.1.3. Vista de desarrollo.3 3.1.4. Vista fsica.3 3.1.5. Vistas de escenarios..3 3.2. Relacin entre las vistas.. 4 4. Conclusin4 5. Referencias.4

1. Introduccin:
Estamos viviendo en un tiempo en que el desarrollo de software debe de ser rpido y de calidad, es por eso que es muy importante adoptar un modelo de desarrollo que cumpla con estas cualidades, uno de ellos es el modelo 4+1 vistas desarrollado por Philippe y Kruchten.

2. Modelo 4+1 vistas:

Realizar una arquitectura de software en un slo modelo, es complejo. Para acabar con la complejidad se realiza una arquitectura de software dividida en mltiples presentaciones, las cuales describen el sistema desde diferentes puntos de vistas. El modelo 4+1 vistas surge para establecer una estructura general que abarca todos los aspectos de una solucin de software, este modelo establece las vistas necesarias para describir una arquitectura de software. 2.1. Las distintas vistas del modelo: Este modelo se basa en diagramas UML para definir las vistas que son necesarias, entre las cuales se encuentran las siguientes:

2.1.1. Vista lgica: Esta es la que trata el anlisis y la especificacin de los requisitos funcionales, es decir, lo que el sistema debera proporcionar en trminos de servicios a sus usuarios. El sistema se descompone en un conjunto de abstracciones clave tomadas mayormente del dominio del problema, en forma de objetos o clases. En esta vista se usan comnmente los diagramas de clases, los de interaccin y objetos. Notacin: La notacin ms usada es UML, y dentro de esta diagramas de clases y paquetes. Estilo: El estilo ms usado para la vista lgica es el Orientado a Objetos. 2.1.2. Vista de proceso: Dentro de esta arquitectura se tratan algunos requisitos no funcionales tales como la Ejecucin, disponibilidad, tolerancia a fallos, integridad, etc. Esta vista tambin especifica que hilo de control ejecuta cada operacin identificada en cada clase identificada en la vista lgica. La vista se centra por tanto en la concurrencia y distribucin de procesos. Notacin: La notacin ms usada es UML, y dentro de esta diagramas estados, actividad y similares. 2

 Estilo: Pueden encajar varios estilos. Por ejemplo tuberas y filtros, o Cliente Servidor. 2.1.3. Vista de desarrollo: La vista de desarrollo o despliegue se enfoca en la organizacin de los mdulos software en el entorno de desarrollo. El software es empaquetado en pequeos trozos, los subsistemas se organizan en capas jerrquicas, y cada capa proporciona una interfaz bien definida a sus capas superiores. La vista de desarrollo toma por tanto requisitos internos relacionados con facilidad de desarrollo, gestin del software, evaluacin de costes, planificacin, monitorizacin del progreso del proyecto, reutilizacin, portabilidad, seguridad y restricciones impuestas por las herramientas o por el lenguaje de programacin. 2.1.4. Vista fsica: La vista fsica se centra en los requisitos no funcionales, tales como la disponibilidad del sistema, la fiabilidad (tolerancia a fallos), ejecucin y escalabilidad. Y tambin presenta cmo los procesos, objetos, etc., corresponden a nodos de proceso: Componentes: nodos de proceso. Conectores: LAN, WAN, bus, etc. Contenedores: subsistemas fsico.

Varias configuraciones fsicas pueden usarse. La correspondencia del software a los nodos debe ser altamente flexible y tener el mnimo impacto en el cdigo fuente. 2.1.5. Vistas de escenarios: La vista de escenarios corresponde con instancias de casos de uso que unifican todas las vistas. As, desde casos de uso se debiera poder hacer una trazabilidad a todos los componentes del sistema software, viendo, por ejemplo, que mquinas, o clases, o componentes o procesos, son los responsables de que el sistema cubra una cierta funcionalidad. Como vemos cada vista est orientada a distintos aspectos del sistema de cmputo, lo cual vuelve muy efectiva esta metodologa ya que divide el problema general en problemas ms pequeos, lo cual lo vuelve ms sencillo de resolver, adems esta metodologa sirve como base para todo el proyecto de desarrollo, facilitando las etapas futuras dando una referencia muy clara y efectiva.

2.2. Relacin entre las Vistas:

Las distintas vistas no son completamente ortogonales o independientes. Los elementos de una vista estn conectados a los elementos de las otras vistas siguiendo ciertas reglas y heursticas de diseo. De la vista lgica a la vista de procesos. Identificamos varias caractersticas importantes de las clases de la arquitectura lgica: Autonoma, Persistencia, Subordinacin, Distribucin. De la lgica al desarrollo. Una clase se implementa generalmente como un mdulo, las clases grandes se descomponen en mltiples paquetes. Colecciones de clases ntimamente relacionadas se agrupan en subsistemas. De procesos a fsico. Los procesos y grupos de procesos se mapean sobre el hardware fsico disponible en varias configuraciones para testing o distribucin.

Como vemos no basta con generar las vistas, si no ms a un importante relacionarlas, para que el proceso de flujo entre vistas sea el adecuado y no trunque el proceso de desarrollo de software.

Conclusion: Debemos de recordar que un equipo de desarrollo est compuesto por sub equipos, como por ejemplo el equipo de anlisis, diseo, desarrollo entre otros; lo cual vuelve cumplido explicar a cada equipo los puntos esenciales que necesita para desarrollar la parte del proyecto que le corresponde llevar acabo. El modelo 4+1 vistas soluciona este problema al darnos distintos enfoques del sistema cada uno orientado a distintos puntos del sistema y sub equipos de desarrollo. Adems ese modelo muy fcil de implementar y de comprender. Por lo tanto sera muy importante tomarlo en cuenta para futuros proyectos de software Referencias:
1. 4+1 View Model of Software Architecture IEEE Software. Kruchtn P. Architectural Blueprints,November 1995