En el
proyecto se propuso hacer la arquitectura siguiendo el modelo de arquitectura
4+1 propuesto por Kruchten, a continuación se describirá de manera
general , cada una de las vistas:
Vista
Lógica
La vista 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.
Se usa el enfoque de
Booch/Rational para representar la arquitectura lógica, mediante diagramas de
clases y plantillas de clases. Un diagrama de clases muestra un conjunto de
clases y sus relaciones lógicas:
Vista
de Procesos
La vista de
procesos toma en cuenta algunos requisitos no funcionales tales como el
rendimiento 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 específica
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, reconfigurar, y detener). Además, los procesos
pueden replicarse para aumentar la distribución de la carga de procesamiento, o
para mejorar la disponibilidad.
Partición.
El software se
parte en un conjunto de tareas independientes: hilo de control separado que
puede planificarse
para su ejecución independiente en un nodo de procesamiento.
Podemos entonces
distinguir:
•Tareas mayores son elementos arquitectónicos
que pueden ser manejados en forma univoca. Se comunican a través de un conjunto
bien definido de mecanismos de comunicación inter-tarea: servicios de comunicación
sincrónicos y asincrónicos basados en mensajes, llamados a procedimientos
remotos, difusión de eventos, etc. Las tareas mayores no debieran hacer
suposiciones acerca de su localización con otras tareas dentro de un mismo
proceso o un mismo nodo de procesamiento.
• Tareas menores son tareas adicionales
introducidas localmente por motivos de implementación tales como actividades cíclicas,
almacenamiento en un buffer, time-out, etc.). Pueden implementarse en Ada por ejemplo,
o como hilos de control liviano (threads). Pueden comunicarse mediante
rendezvous o memoria compartida. El flujo de mensajes y la carga de procesos pueden
estimarse en base al diagrama de procesos. También es posible implementar una
vista de procesos “vacía”, con cargas dummy para los procesos y medir entonces
su performance en el sistema objetivo.
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.
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 extend e include. La arquitectura de desarrollo 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.
Vista
Física
La vista física
toma en cuenta primeramente los requisitos no funcionales del sistema tales
como la disponibilidad, confiabilidad (tolerancia a fallas), rendimiento
(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 nodos. Esperamos que diferentes configuraciones puedan
usarse: algunas para desarrollo y pruebas, otras para mostrar el sistema en
varios sitios para distintos usuarios. Por lo tanto, la relación del software
en los nodos debe ser altamente flexible y tener un impacto mínimo sobre el código
fuente.
Escenarios
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 Rubin 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. Esta vista es redundante con las otras (y por lo tanto “+1”), pero
sirve a dos propósitos principales:
• Como una guía
para descubrir elementos arquitectónicos durante el diseño de arquitectura tal
como lo describiremos más adelante
• Como un rol de
validación e ilustración después de completar el diseño de arquitectura, en el
papel y como punto de partido de las pruebas de un prototipo de la
arquitectura.
Extraido de:
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:modelo4_1.pdf
Extraido de:
http://cic.puj.edu.co/wiki/lib/exe/fetch.php?media=materias:modelo4_1.pdf
No hay comentarios:
Publicar un comentario