Modelo 4+1

La arquitectura del software se trata de abstracciones, de descomposición y composición, de estilos y estética. También tiene relación con el diseño y la implementación de la estructura de alto nivel del software. Los diseñadores construyen la arquitectura usando varios elementos arquitectónicos elegidos apropiadamente. 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 disponibilidad del sistema.

Figura 1: Modelo de “4+1” La Arquitectura Lógica La arquitectura lógica apoya principalmente los requisitos funcionales –lo que el sistema debe brindar en términos de servicios a sus usuarios. El sistema se descompone en una serie de abstracciones clave, tomadas (Principalmente) del dominio del problema en la forma de objetos o clases de objetos. Aquí se aplican los principios de abstracción, encapsulamiento y herencia. Esta descomposición no sólo se hace para potenciar el análisis funcional, sino también sirve para identificar mecanismos y elementos de diseño comunes a diversas partes del sistema. Usamos el enfoque de Booch/Rational para representar la arquitectura lógica, mediante diagramas de clases y templetes de clases. Un diagrama de clases muestra un conjunto de clases y sus relaciones lógicas: asociaciones, uso, composición, herencia y similares. Grupos de clases relacionadas pueden agruparse en categorías de clases. Los templetes de clases se centran en cada clase individual; enfatizan las operaciones principales de la clase, e identifican las principales características del objeto. Si es necesario definir el comportamiento interno de un objeto, esto ser realiza con un diagrama de transición de estados o diagrama de estados. Los mecanismos y servicios comunes se definen como utilidades de la clase.

Notación. La notación para la lógica se deriva de la notación de Booch. Esta se simplifica considerablemente de

tal modo de tener en cuenta solamente los items relevantes para la arquitectura. En particular, los numerosos

adornos disponibles son bastante inútiles a este nivel de diseño. Usamos Rational Rose para apoyar el diseño

lógico de la arquitectura.

Figura 2: Notación para la lógica

La Vista de Procesos

La arquitectura de procesos toma en cuenta algunos requisitos no funcionales tales como la performance y la disponibilidad. Se enfoca en asuntos de concurrencia y distribución, integridad del sistema, de tolerancia a fallas. La vista de procesos también especifica en cuál hilo de control se ejecuta efectivamente una operación de una clase identificada en la vista lógica. La arquitectura de procesos se describe en varios niveles de abstracción, donde cada nivel se refiere a distintos intereses. El nivel más alto la arquitectura de procesos puede verse como un conjunto de redes lógicas de programas comunicantes (llamados “procesos”) ejecutándose en forma independiente, y distribuidos a lo largo de un conjunto de recursos de hardware conectados mediante un bus, una LAN o WAN. Múltiples redes lógicas pueden usarse para apoyar la separación de la operación del sistema en línea del sistema fuera de línea, así como también para apoyar la coexistencia de versiones de software de simulación o de prueba. Un proceso es una agrupación de tareas que forman una unidad ejecutable. Los procesos representan el nivel al que la arquitectura de procesos puede ser controlada tácticamente (i.e., comenzar, recuperar, re configurar, y detener). Además, los procesos pueden replicarse para aumentar la distribución de la carga de procesamiento, o para mejorar la disponibilidad. Notación. La notación que usamos para la vista de procesos se expande de la notación originalmente propia por Booch para las tareas de Ada y se centra solamente en los elementos arquitectónicamente relevantes (Figura 3).

Figura 3: Notación para el diagrama de procesos

Vista de Desarrollo La vista de desarrollo se centra en la organización real de los módulos de software en el ambiente de desarrollo del software. El software se empaqueta en partes pequeñas bibliotecas de programas o subsistemas que pueden ser desarrollados por uno o un grupo pequeño de desarrolladores. Los subsistemas se organizan en una jerarquía de capas, cada una de las cuales brinda una interfaz estrecha y bien definida hacia las capas superiores.

Figura 4: Diagrama (parcial) de procesos para Télic PBX La vista de desarrolla tiene en cuenta los requisitos internos relativos a la facilidad de desarrollo, administración del software, reutilización y elementos comunes, y restricciones impuestas por las herramientas o el lenguaje de programación que se use. La vista de desarrollo apoya la asignación de requisitos y trabajo al equipo de desarrollo, y apoya la evaluación de costos, la planificación, el monitoreo de progreso del proyecto, y también como base para analizar reusó, portabilidad y seguridad. Es la base para establecer una línea de productos. La vista de desarrollo de un sistema se representa en diagramas de módulos o subsistemas que muestran las relaciones exporta e importa. La arquitectura de desarrollo completa sólo puede describirse completamente cuando todos los elementos del software han sido identificados. Sin embargo, es posible listar las reglas que rigen la arquitectura de desarrollo – partición, agrupamiento, visibilidad antes de conocer todos los elementos.

Notación. Tal como se muestra en la Figura 5, usamos una variante de la notación de Booch limitándonos a

aquellos items relevantes para la arquitectura.

Figura 5: Notación para el diagrama de desarrollo

Arquitectura Física

Mapeando el software al hardware La arquitectura física toma en cuenta primeramente los requisitos no funcionales del sistema tales como la disponibilidad, confiabilidad (tolerancia a fallas), performance (throughput), y escalabilidad. El software ejecuta sobre una red de computadores o nodos de procesamiento (o tan solo nodos). Los variados elementos identificados –redes, procesos, tareas y objetos– requieren ser mapeados sobre los variados nodos. Esperamos que diferentes configuraciones puedan usarse: algunas para desarrollo y pruebas, otras para emplazar el sistema en varios sitios para distintos usuarios. Por lo tanto, el mapeo del software en los nodos requiere ser altamente flexible y tener un impacto mínimo sobre el código fuente en sí.

Notación. Los diagramas físicos pueden tornarse muy confusos en grandes sistemas, y por lo tanto toman

diversas formas, con o sin él mapeo de la vista de procesos.

Figure 6: Notación para el diagrama físico Escenarios Todas las partes juntas. Los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el uso de un conjunto pequeño de escenarios relevantes –instancias de casos de uso más generales– para los cuales describimos sus scripts correspondientes (secuencias de interacciones entre objetos y entre procesos) tal como lo describen Rubín y Goldberg. Los escenarios son de alguna manera una abstracción de los requisitos más importantes. Su diseño se expresa mediante el uso de diagramas de escenarios y diagramas de interacción de objetos. Notación. La notación es muy similar a la vista lógica para los componentes (ver Figura 2), pero usa los conectores de la vista de procesos para la interacción entre objetos (ver Figura 3). Nótese que las instancias de objetos se denotan con líneas sólidas. Para el diagrama lógico, capturamos y administramos los diagramas de escenarios de objetos usando Rational Rose.

Capas

Capa de presentación Esta capa es la que ve el usuario, presenta el sistema al usuario, le comunica la información y captura la información del usuario en un mínimo de proceso. Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" para el usuario generalmente se presentan como formularios. Capa de negocio Aquí es donde, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Se denomina capa de negocio (e incluso de lógica del negocio) porque es aquí donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de datos, para solicitar al gestor de base de datos para almacenar o recuperar datos de él. Toda aplicación tiene código para implementar reglas de negocios. Se puede seleccionar almacenar la lógica de negocios sobre cada estación de cliente, u optar por ejecutar la lógica de negocios sobre un servidor de aplicaciones. No toda la lógica de negocio es la misma algunas no requieren un frecuente acceso a los datos, pero una interface de usuario robusta necesitara de la lógica de negocios para la validación en la entrada de campos, cálculos en tiempo real u otras interacciones de usuarios. Capa de datos Es donde residen los datos y es la encargada de acceder a los mismos. Está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio.

Triangulo de éxito para el desarrollo de Software Notación, Herramienta y Proceso Se suele utilizar el triángulo del éxito de un proyecto software (figura 1) para explicar los componentes necesarios en todo proyecto. En cualquier caso se necesitan los tres vértices: una notación, un proceso, y una herramienta. Podemos disponer de una notación pero si no sabemos cómo utilizarla (proceso), no nos servirá de mucho. Por otro lado podemos tener un gran proceso, pero si no podemos comunicarlo (notación), la situación será en cualquier caso deficiente. Por último, si no podemos documentar los elementos de nuestro proyecto el éxito no será completo. En resumen, debemos utilizar los tres componentes conjuntamente para especificar, visualizar, documentar y crear de forma incremental e iterativa una solución software al problema.

Figura 1: Triángulo de un proyecto software

Hoy en día el diseñador software que intenta representar el diseño de un sistema software puede elegir entre una gran variedad de notaciones, cada una generalmente integrada en una metodología de análisis y diseño específica. Precisamente esta gran variedad de elección es el principal impedimento para poder hacer uso de los significativos beneficios de la reutilización. La llegada de UML (Unified Modeling Language), con un amplio respaldo de las compañías líderes en la industria del software, representa uno de los desarrollos más importantes dentro de la metodología orientada a objetos, aportando un lenguaje de modelado universal que puede ser utilizado con cualquier método.

Comparativo de Capas y Modelo 4+1 Capas

Al implementar este modelo de programación, se asegura un trabajo de forma ordenada y separada.

Cada capa está dividida según su funcionalidad cuando se quiere modificar el sistema basta con cambiar un objeto o conjunto de objetos de una capa.

Modelo 4+1

Las distintas vistas no son completamente ortogonales o independientes. Los elementos de una vista están conectados a los elementos de las otras vistas siguiendo ciertas reglas y heurísticas de diseño.

Conclusión

Una presentación de un modelo, la cual es una descripción completa de un sistema desde una particular perspectiva. Este es el modelo más aceptado “El modelo de 4+1” ha sido usado con éxito en varios proyectos

grandes con o sin ajustes locales en su terminología. Se define con 4 vistas:

Vista Lógica.- modelo de objetos.

Vista de Proceso.- modelo de concurrencia y distribución.

Vista de desarrollo.- organización estática del software en su entorno de desarrollo.

Vista Física.- modelo de correspondencia software – hardware.

Cada vista tiene su notación específica. Realmente permitió a los distintos usuarios encontrar lo que querían acerca de la arquitectura del software. Los ingenieros de sistemas se enfocaron en la física, y luego en la de procesos. Los usuarios finales, los clientes, y los especialistas en datos en la lógica. Los administradores de proyectos, las personas de configuración del software en la de desarrollo.

Y una vista más, la "+1", que se muestra y traza en cada una de las anteriores y que está formada por las necesidades funcionales que cubre el sistema, y que en ocasiones identificamos como vista de "casos de uso". De donde deducimos que según este modelo, la arquitectura es en realidad evolucionada desde escenarios. La programación por capas consta de 3 capas:

Presentación.- presentación del programa ante el usuario.

Negocios.- definen todas las reglas que se deben cumplir para una correcta ejecución del programa.

Datos.- encargada de realizar transacciones con bases de datos y con otros sistemas para obtener o ingresar información al sistema.

Ya que tiene como objetivo primordial es la separación de la lógica de negocios de la lógica de diseño, consiste en separar la capa de datos de la capa de presentación al usuario. El triangulo del éxito contiene 3 vértices: notación, procesos y herramientas. Tiene como objetivo la confección

de un material que permita una guía que de manera incremental, posibilite la asimilación y puesta en práctica de estas técnicas. Obteniendo una mejor integración de elementos que al final logra construir un software con

calidad y funcionalidad al cliente.

Como dice anteriormente el UML representa uno de los desarrollos más importantes dentro de la metodología orientada a objetos.