modelo 4+1 vista
TRANSCRIPT
Instituto Tecnológico Superior
De Los Reyes
Desarrollo de Proyectos de Sw
Alumno:
Francisco Javier Morales Cabello
Facilitador:
ISC Claudia María Bernal Rodríguez
Grupo: 82S
Los Reyes, Mich. 14/02/2011
ÍNIDICE
Contenid
o
INTRODUCCIóN............................................................................................3
La vista lógica................................................................................................5
La Vista de Procesos.....................................................................................6
Vista de Desarrollo........................................................................................8
Vista FÍsica....................................................................................................9
Escenarios ó Casos de Uso........................................................................10
CONCLUSIÓN.............................................................................................13
REFERENCIAS BIBLIOGRÁFIAS...............................................................14
INTRODUCCIÓN
La arquitectura software trata el diseño e implementación de la estructura
de alto nivel del software. Es el resultado de ensamblar un cierto número de
elementos arquitectónicos para satisfacer la funcionalidad y ejecución de los
requisitos del sistema; así como los requisitos no funcionales del mismo: fiabilidad,
escalabilidad, portabilidad, disponibilidad, etc. Esto implica tener o hacer un gran
esfuerzo para comprender planos y aspectos de los diseñadores de lo quieren dar
a entender en sus diagramas y peor aún que si alguien ajeno a la elaboración del
proyecto lo trata de comprender.
El modelo de 4+1 vistas fue desarrollado para remediar este problema. El
modelo 4+1 describe la arquitectura del software usando cinco vistas
concurrentes.
• La vista lógica.
• La vista de procesos.
• La vista física.
• La vista de desarrollo.
Por tal motivo los diseñadores de software pueden organizar la descripción
de sus decisiones de arquitectura en estas cuatro vistas, y luego ilustrarlas con un
conjunto reducido de casos de uso o escenarios, los cuales constituyen la quinta
vista. La arquitectura evoluciona parcialmente a partir de estos escenarios y pues
veremos esto más a detalle a continuación.
EL MODELO DE “4+1” VISTAS DE LA ARQUITECTURA DEL
SOFTWARE
Una de las herramientas para representar modelos de arquitectura
anteriores al UML es la denominada 4+1 vistas propuesta por Kruchten. Surge
esta necesidad cuando un desarrollador inicia el modelado de un problema;
lógicamente en este proceso se hace énfasis en proporcionar la mayor
información del mismo a través de los diagramas que se utilicen para su
descripción, esto trae consigo que puedan suceder conflictos en la representación
de la arquitectura del sistema. Esta arquitectura de software propuesta por
Kruchten es una forma de resolver esta problemática. El modelo describe la
arquitectura de software del sistema a través de 5 vistas concurrentes.
Kruchten las agrupa estas 5 vistas por su naturaleza en 3 apartados; el
conceptual donde sitúa a la vista lógica y la de procesos, el físico que lo
componen las vistas de componentes y la distribuida y por último la funcional la
que se refiere a la vista de casos de uso.
LA VISTA LÓGICA
Es aquella que trata de clases y subsistemas, tiene las siguientes
particularidades: soporta los requerimientos funcionales (estos son asignados por
el usuario final), identifica mecanismos y diseña elementos comunes a través del
sistema; utiliza los diagramas de clases y la notación de Booch.; además de
utilizar el estilo arquitectónico orientado a objetos.
Notación. La notación para la vista 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ñó. Usamos Rational
Rose para apoyar el diseñó lógico de la arquitectura.
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 cual 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
´enea, 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 particiona 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.
Notación. La notación que usamos para la vista de procesos se expande
de la notación originalmente propuesta por Booch para las tareas de Ada y se
centra solamente en los elementos arquitectónicamente relevantes
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 exporta e importa. La
arquitectura de desarrollo completa solo 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. Usamos una variante de la notación de Booch limitándonos a
aquellos items relevantes para la arquitectura.
VISTA 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 para la arquitectura física. Los diagramas físicos
pueden tornarse muy confusos en grandes sistemas, y por lo tanto
toman diversas formas, con o sin el mapeo de la vista de procesos.
ESCENARIOS O CASOS DE USO
Todas las partes juntas
En la quinta y última vista del Modelo _4+1_, se presentan los
escenarios en los cuales un Caso de Uso dispara una secuencia de
acciones que devienen en la interacción entre las vistas tratadas
anteriormente.
El usuario, como actor primario, dispara la actividad <_<Apostar>_> que
desencadena la secuencia de operaciones necesarias para completar este C.U.
Se puede comprender fácilmente de qué manera interactúan las diferentes vistas:
1. En un único Proceso (aplicación web) usuario interactúa con el nodo
Cliente mediante teclado y monitor
2. El cliente se comunica con el nodo Web Server
3. Web server contiene una Vista Lógica englobada en diferentes
Componentes que manipula los datos, validando y consultando mediante la
interfaz correspondiente, los datos del nodo Base De Datos
De esta forma notamos cómo 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_. Se presentan
dos ejemplos más de casos de usos:
CONCLUSIÓN
Pues como vimos la forma más segura y confiable de desarrollar un
proyecto se software es sin duda el modelo de vistas 4+1, ya que nos permite
detectar errores a tiempo, tanto como no realizar trabajo innecesario y siguiendo
solo su metodología.
Y cabe mencionar que no todas las arquitecturas de software requieren
todas las vistas del modelo 4+1, algunas vistas pueden ser omitidas, pero todos
los escenarios se pueden encontrar en ellas.
La finalidad es de unificar los criterios de modelado, la necesidad de facilitar
la comunicación entre los diseñadores y establecer estándares variados, lo más
claro posibles que permitan una mayor comprensión del sistema que se esté
modelando.
REFERENCIAS BIBLIOGRÁFIAS
M.Shaw, D. y. (1993). Una introduccion a la Ingenieria de Software. World
Scientific Publishing Co. , 10.
u-cursos. (s.f.). Recuperado el 14 de Febrero de 2011, de https://www.u-
cursos.cl/ingenieria/2010/1/CC61H/1/material.../273290
teraloc. (s.f.). Recuperado el 14 de Febrero de 2011, de
www.teraloc.com/aptiweb/.../FORMATO_APTI_ ArquitecturaSoftware . doc
bunastareas. (s.f.). Recuperado el 14 de Febrero de 2011, de
www.buenastareas.com/.../ Modelo -De- 4 - 1 - Vistas /200237.html