Arquitectura 4+1 Ferney Toledo Norato ferneytoledo@gmail.

com RESUMEN La importancia de tener un modelo de desarrollo, que sea eficiente y eficaz, hace que se tomen estndares necesarios para suplir todas las necesidades en el proceso de desarrollo de software, el modelo 4+1, es uno de ellos y fue propuesto por el SR Philippe B. Kruchten.

Categoras y Asuntos Descriptores: Ingeniera de sistemas. Trminos Generales: Componentes de Software Palabras Clave: Diagramacin, Casos de uso, UML, Modelo arquitectura, Desarrollo de software. 1. INTRODUCCIN: El modelo 4+1 nace para suplir, arreglar e implementar soluciones pues en el desarrollo normal de una solucin existen falencias tanto en el recogimiento de informacin como en el desarrollo e implementacin del sistema, es decir, a veces la arquitectura del software tiene secuelas de un diseo del sistema o de un nfasis excesivo de algunos de los aspectos del desarrollo del software tales como la ingeniera de datos, eficiencia en tiempo de ejecucin o estrategias de desarrollo y organizacin de equipos. A menudo la arquitectura tampoco aborda los intereses de todos sus clientes, colocando as una mala imagen de la empresa y malas expectativas de una implementacin de software. 2. QUE ES 4+1? Realizar una arquitectura de software en un slo modelo, es difcil, Para manejar esta complejidad se representan diferentes aspectos y caractersticas de la arquitectura en mltiples presentaciones de un modelo, la cual es una descripcin completa de un sistema desde una particular perspectiva. para solucionar y establecer una estructura general de tal forma que esta supla todos los aspectos necesarios dentro de una solucin de software, se cre 4+1 El modelo ms aceptado a la hora de establecer las vistas necesarias para describir una arquitectura software

2.1 Cmo funciona 4+1? 4 +1 es un modelo enfocado en ser claro para la obtencin de informacin del mismo sistema, por medio de los diagramas UML conteniendo los diagramas de casos de uso por ende 4+1 define 4 vistas principales, estas son: Vista Lgica (Logical View), donde especficamente se tratan: el modelo de objetos, clases, entidad relacin, etc. Vista de Proceso (Process View), donde especficamente se tratan: el modelo de concurrencia y sincronizacin. Vista de Desarrollo (Development View), donde especficamente se tratan temas como: la organizacin esttica del software en su entorno de desarrollo (libreras, componentes, .ear, .jar, etc.). Vista Fsica (Physical View), donde especficamente se tratan: el modelo de correspondencia software hardware. Estas vistas se plasman en un diagrama como el siguiente:

Imagen 1: Vistas modelo 4+1 Fuente: Ferney Toledo Norato 2.2 Caractersticas de las vistas 4+1

2.2.1. Arquitectura Lgica (Logical Architecture) 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.2.2. Arquitectura de Procesos (Process Architecture) 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. Estilo: Pueden encajar varios estilos. Por ejemplo, tomando la taxonoma de Garlan y Shaw (1993), pueden usarse tuberas y filtros o Cliente Servidor, Para sistemas ms complejos puede usarse un estilo similar a la ISIS system's process groups.

2.2.3. Arquitectura de Desarrollo (Development Architecture) 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 (libreras de programa, subsistemas, componentes, etc.), 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 (reparto de requisitos, trabajo del equipo), evaluacin de costes, planificacin, monitorizacin del progreso del proyecto, reutilizacin, portabilidad, seguridad y restricciones impuestas por las herramientas o por el lenguaje de programacin. Esta organizacin del software se suele apoyar en diagramas de mdulos o de subsistemas que muestran las relaciones de exportacin (export) e importacin (import). Y destacar que podr describirse la vista de desarrollo por completo solamente despus de haber identificado todos los elementos software. Notacin: La notacin ms usada es UML, y dentro de esta diagramas de componentes y paquetes. Estilo: se recomienda definir de cuatro a seis capas de subsistemas en la vista de desarrollo. Esto minimiza las dependencias entre mdulos.

2.2.4. Arquitectura Fsica (Physical Architecture) 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.

3. Escenarios (Scenarios) 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 .jar, o procesos, son los responsables de que el sistema cubra una cierta funcionalidad. 4. Relacin entre las vistas Como sucede en otras muchas ocasiones, si bien el modelo no es una metodologa s que "sugiere" un mtodo de trabajo. Parece lgico que la vista de escenarios o casos de uso sea la de arranque, y que de ah se pase a la vista lgica. Desde la vista lgica afrontaremos la de desarrollo y procesos, una vez que tenemos por ejemplo las clases definiremos maneras de agruparlas y modos de ejecucin. Para con todo concluir en la vista fsica. Todo ello, obviamente, con sus correspondientes y tpicas iteraciones.

CONCLUSIN Cuando se esta creando un proyecto, Empezamos a analizar requerimientos y a realizar todo el ciclo de vida del proyecto teniendo en cuenta que en cada proceso se debe tener un control adecuado de calidad, por ende se establecen Modelos de arquitectura de software las cuales son viables a seguir para tener un desarrollo optimo y sobre todo que cumpla con lo pactado adems de ser eficiente, eficaz y que sus requerimientos tanto funcionales como no funcionales se cumplan a todo dar. El porque de la implementacin de un modelo como el 4+1?, simplemente porque con el tanto como otros modelos que hay, lo que se ve, es que es ms sencillo comprender, realizar y conocer que se est haciendo dentro del proceso de elaboracin del proyecto con una comunicacin optima dentro del equipo de desarrollo siguiendo y cumpliendo todo lo pactado dentro del modelo es seguro que se tendr una solucin de software de muy buena calidad y lo mejor comprensible con su diagramacin realizada y comprensible y no tener as problemas que siguiendo un modelo nunca van a existir

Como conclusin tome la siguiente tabla que representa del modelo 4+1 las vistas vs los diagramas UML que cumple cada vista, es esencial comprender la diagramacin, pues es un medio de comunicacin para los lideres de equipo dentro de una solucin de software. Vista UML Escenarios Casos de Uso Lgica Clases, de Estados y Colaboracin Desarrollo Componentes Fsica Despliegue Procesos Actividad, Estados, Secuencia

REFERENCIAS: K.P. Birman and R. Van Renesse, Reliable Distributed Computing with the Isis Toolkit, IEEE CS Press, and Los Alamitos, Calif. 1994. 4+1 View Model of Software Architecture IEEE Software. Kruchtn P. Architectural Blueprints, November 1995