Instituto Tecnolgico Superior De Los Reyes

Desarrollo de Proyectos de Sw

Alumno: Francisco Javier Morales Cabello

Facilitador: ISC Claudia Mara Bernal Rodrguez

Grupo: 82S

Los Reyes, Mich. 14/02/2011

NIDICE

Contenido
INTRODUCCIN ........................................................................................... 3 La vista lgica ............................................................................................... 5 La Vista de Procesos .................................................................................... 6 Vista de Desarrollo ........................................................................................ 8 Vista Fsica.................................................................................................... 9 Escenarios Casos de Uso ........................................................................ 10 CONCLUSIN ............................................................................................ 13 REFERENCIAS BIBLIOGRFIAS .............................................................. 14

INTRODUCCIN
La arquitectura software trata el diseo e implementacin de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto nmero de elementos arquitectnicos para satisfacer la funcionalidad y ejecucin 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 diseadoresde lo quieren dar a entender en sus diagramas y peor an que si alguien ajeno a la elaboracin 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 lgica. La vista de procesos. La vista fsica. La vista de desarrollo. Por tal motivo los diseadores de software pueden organizar la descripcin 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 ms a detalle a continuacin.

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; lgicamente en este proceso se hace nfasis en proporcionar la mayor informacin del mismo a travs de los diagramas que se utilicen para su descripcin, esto trae consigo que puedan suceder conflictos en la representacin de la arquitectura del sistema. Esta arquitectura de software propuesta por Kruchten es una forma de resolver esta problemtica. El modelo describe la arquitectura de software del sistema a travs de 5 vistas concurrentes. Kruchten las agrupa estas 5 vistas por su naturaleza en 3 apartados; el conceptual donde sita a la vista lgica y la de procesos, el fsico 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 LGICA
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 disea elementos comunes a travs del sistema; utiliza los diagramas de clases y la notacin de Booch.; adems de utilizar el estilo arquitectnico orientado a objetos. Notacin.La notacin para la vista lgica se deriva de la notacin 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 intiles a este nivel de dise. Usamos Rational Rose para apoyar el dise lgico 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 distribucin, integridad del sistema, de tolerancia a fallas. La vista de procesos tambin especifica en cual hilo de control se ejecuta efectivamente una operacin de una clase identificada en la vista lgica. La arquitectura de procesos se describe en varios niveles de abstraccin, donde cada nivel se refiere a distintos intereses. El nivel ms alto la arquitectura de procesos puede verse como un conjunto de redes lgicas de programas comunicantes (llamados procesos) ejecutndose en forma independiente, y distribuidos a lo largo de un conjunto de recursos de hardware conectados mediante un bus, una LAN o WAN. Mltiples redes lgicas pueden usarse para apoyar la separacin de la operacin del sistema en lnea del sistema fuera de enea, as como tambin para apoyar la coexistencia de versiones de software de simulacin o de prueba. Un proceso es una agrupacin de tareas que forman una unidad ejecutable. Los procesos representan el nivelal que la arquitectura de procesos puede ser controlada tcticamente (i.e., comenzar, recuperar, reconfigurar, ydetener). Adems, los procesos pueden replicarse para aumentar la distribucin de la carga de procesamiento, o para mejorar la disponibilidad. Particin.El software se particiona en un conjunto de tareas

independientes: hilo de control separado que puede planificarse para su ejecucin independiente en un nodo de procesamiento. Podemos entonces distinguir: Tareas mayores son elementos arquitectnicos que pueden ser manejados en forma univoca. Se comunican a travs de un conjunto bien definido de mecanismos de comunicacin inter-tarea: servicios de comunicacinsincrnicos y asincrnicos basados en mensajes, llamados a

procedimientos remotos, difusin de eventos, etc. Las tareas mayores no debieran hacer suposiciones acerca de su localizacin con otras tareas dentro de un mismo proceso o un mismo nodo de procesamiento. Tareas menores son tareas adicionales introducidas localmente por motivos de implementacin tales como actividades cclicas, 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. Tambin es posible implementar una vista de procesos vaca, con cargas dummy para los procesos y medir entonces su performance en el sistema objetivo. Notacin.La notacin que usamos para la vista de procesos se expande de la notacin originalmente propuesta por Booch para las tareas de Ada y se centra solamente en los elementos arquitectnicamente relevantes

VISTA DE DESARROLLO
La vista de desarrollo se centra en la organizacin real de los mdulos de software en el ambiente de desarrollo del software. El software se empaqueta en partes pequeas bibliotecas de programas o subsistemas que pueden ser desarrollados por uno o un grupo pequeo de desarrolladores. Los subsistemas se organizan en una jerarqua 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, administracin del software, reutilizacin y elementos comunes, y restricciones impuestas por las herramientas o el lenguaje de programacin que se use. La vista de desarrollo apoya la asignacin de requisitos y trabajo al equipo de desarrollo, y apoya la evaluacin de costos, la planificacin, el monitoreo de progreso del proyecto, y tambin como base para analizar reus, portabilidad y seguridad. Es la base para establecer una lnea de productos. La vista de desarrollo de un sistema se representa en diagramas de mdulos o subsistemas que muestran las relaciones exporta e importa. La arquitectura de desarrollo completa solopuede describirse completamente cuando todos los elementos del software han sido identificados. Sin embargo, es posible listar las reglas que rigen la arquitectura de desarrollo particin, agrupamiento, visibilidad antes de conocer todos los elementos.

Notacin.Usamos una variante de la notacin de Booch limitndonosa aquellos items relevantes para la arquitectura.

VISTA FSICA
Mapeando el software al hardware La arquitectura fsica 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 mnimo sobre el cdigo fuente en s. Notacin para la arquitectura fsica.Los diagramas fsicos 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 interaccin 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 fcilmente de qu manera interactan las diferentes vistas: 1. En un nico Proceso (aplicacin web) usuario interacta con el nodo Cliente mediante teclado y monitor

2. El cliente se comunica con el nodo Web Server 3. Web server contiene una Vista Lgica 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 cmo los elementos de las cuatro vistas trabajan conjuntamente en forma natural mediante el uso de un conjunto pequeo de escenarios relevantes _instancias de casos de uso ms generales_. Se presentan dos ejemplos ms de casos de usos:

CONCLUSIN
Pues como vimos la forma ms 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 metodologa. 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 comunicacin entre los diseadores y establecer estndares variados, lo ms claro posibles que permitan una mayor comprensin del sistema que se est modelando.

REFERENCIAS BIBLIOGRFIAS

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.ucursos.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