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