Instituto Tecnolgico de Culiacn

Profesora: Emir Abel Manjarrez Montero Materia: Arquitectura de Software Alumno: Galvn Garca Jos Eduardo No. Control: 09170821 Trabajo: Tarea#2: Ensayo 4+1view-architecture

Jueves 21 de Enero del 2013

ndice
1.- Introduccin ............................................Error! Bookmark not defined. 2.- El Modelo de las 4+1 vistas .................................................................. 3 3.- La Arquitectura Logica .......................................................................... 4 4.-La Vista de Procesos.............................................................................. 5 5.-Vistas del Desarrollo .............................................................................. 6 6.-Arquitectura Fisica.- ............................................................................... 7 7.-Escenarios .............................................................................................. 8 8.-Correspondencias entre las vistas ....................................................... 8 9.-Confenccionando el Modelado .............................................................. 9 Mis Concluciones ....................................................................................... 9

1.- Introduccin
El primer apartado nos habla de cmo los diagramas o modelos no tienen mucho significado a simple vista y de que tambin pueden tener muchos significados si se les conoce ms a fondo cada uno de sus componentes. Nos habla de cmo la arquitectura del software no es nica ya que depende a la necesidad del cliente es como puede tomas forma la arquitectura del mismo. Al final de este apartado nos habla de cmo el modelo 4+1 vistas fue desarrollado para solucionar los problemas y dar un enfoque alternativo a los diseadores del software para desarrollar software. Tambin nos da un pequeo resumen de los tipos de vistas y de cmo se pueden organizar las decisiones con ellas y posteriormente ilustrarlas con un conjunto reducido de casos o escenarios, los cuales constituyen la quinta vista.

2.- El Modelo de las 4+1 Vistas

En este apartado nos habla que la arquitectura de software trata de abstracciones, de descomposicin y composicin, de estilos y esttica y de la relacin que tiene con el diseo y la implementacin de la estructura del software.

De cmo los diseadores construyen su propia arquitectura tomando los elementos apropiados para satisfacer la mayora de los requisitos funcionales y los no funcionales tales como confiabilidad, portabilidad y disponibilidad del sistema.

3.- La Arquitectura Lgica

Esta es el primer tipo de arquitectura y se basa en su mayora en los requisitos funcionales. En ella se toman los principios de abstraccin, encapsulamiento y herencia. En ella se pone un gran nfasis al anlisis funcional y sirve para identificar los mecanismos y elementos del diseo a diferentes partes del sistema. Este tipo de arquitectura se representa mediante diagramas de clases y templates de clases y que los diagramas se muestran el conjunto de clases y sus relaciones lgicas y en los templates se centran en cada clase individual. Posteriormente en este punto nos muestra la notacin para la vista lgica llamada Rational Rose que es la siguiente:

Despus nos habla del estilo de orientacin de los objetos para llevarlo a ser un modelado nico, nos explica los ejemplos para ver la forma en que se comunican los componentes entre ellos.

4.-La Vista de Procesos

Nos dice que esta arquitectura toma en cuenta los requisitos no funcionales tales como el performance y la disponibilidad. Esta vista pone nfasis en la concurrencia y la distribucin, pero que tambin se ocupa de la integridad del sistema y de manejar las fallas para llevar el control del flujo de los datos y en donde se ejecutan satisfactoriamente los datos. Tambin nos dice de cmo esta vista se puede ver como una red lgica con procesos que se ejecutan independientemente y distribuidos a lo largo del software y estos se comunican mediante sus relaciones entre ellos. Nos dice que los procesos representan el nivel al que est controlado tcticamente. Posteriormente nos habla de cmo y el por qu los procesos estn particionados en tareas independientes pero que estos estn conectados mediante un hilo con el cual puede planificarse la ejecucin del software. Luego nos muestra la notacin que se usa para la vista de procesos que esta vez est basada en la notacin propuesta por Booch y que se centra solo en los elementos arquitectnicos televantes:

En la seccin de Estilos nos dice que se pueden utilizar varios, tales como la taxonoma de Garlan y Shaw como los de tubes and filters o la de cliente/servidor, y para ms complejos se puede utilizar la forma de agrupacin de procesos del sistema de ISIS descrito por Kenneth Birman pero con otro tipo de notacin y otras herramientas.

5.- Vistas del Desarrollo

Esta vista se centra en el desarrollo real de los mdulos del software llamados subprogramas. Cada subsistema se organizan en una jerarqua de capas, y cada una est definida por especficamente definida por las capas superiores. Por ejemplo:

En esta vista se toman en cuenta los requisitos internos relativos a la facilidad del desarrollo, administracin del software, reutilizacin y elementos comunes. Se apoya en la asignacin de requisitos y trabajo al equipo de desarrollo, y apoya la evaluacin de costos, planificacin, el monitoreo de progreso del proyecto y se toma como base para analizar reso, portabilidad y seguridad del software. Esta vista se representa en diagramas de mdulos o subsistemas que muestran las relaciones que se exportan e importan. Se dice que esta vista est completa cuando cada uno de los elementos estn identificados. Esta vista utiliza tambin la notacin de boch pero limita los elementos relevantes para la arquitectura.

El estilo comn para esta vista es el estilo de capas definida de 4 a 6 niveles de subsistemas. La principal regla de esta vista es que cada subsistema en una cierta capa solo puede depender de subsistemas que estn o bien la misma capa o capas inferiores de modo de minimizar el desarrollo de complejas redes de dependencias entre mdulos y permitir estrategias de desarrollo capa a capa.

6.- Arquitectura Fsica

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. Utiliza la siguiente notacin:

7.- Escenarios
En esta etapa se utilizan las 4 vistas para que trabajen en conjunto mediante el uso de pequeas interfaces o escenarios (instancias de casos de uso ms generales) en ellos se encuentras os requerimientos ms importantes y se representan mediante diagramas de escenarios y diagramas de interaccin de objetos. Esta es la ultima vista y como utiliza loas 4 vistas principales por esa razn se le llama 4+1 y esta tiene dos principales propsitos: Como una gua para descubrir elementos arquitectnicos durante el diseo de arquitectura tal como lo describiremos ms adelante Como un rol de validacin e ilustracin despus de completar el diseo de arquitectura, en el papel y como punto de partido de las pruebas de un prototipo de la arquitectura.

8.- Correspondencia entre las Vistas

Las distintas vistas no son completamente ortogonales o independientes. Los elementos de una vista estn conectados a los elementos de las otras vistas siguiendo ciertas reglas y heursticas de diseo. De la vista lgica a la vista de procesos. Identificamos varias caractersticas importantes de las clases de la arquitectura lgica: Autnoma: Los objetos son activos, pasivos o protegidos? un objeto activo toma la iniciativa de invocar las operaciones de otros objetos o sus propias operaciones, y tiene el control completo sobre la invocacin de sus operaciones por parte de otros objetos. un objeto pasivo nunca invoca espontneamente ninguna operacin y no tiene ningn control sobre la invocacin de sus operaciones por parte de otros objetos. un objeto protegido nunca invoca espontneamente ninguna operacin pero ejecuta cierto arbitraje sobre la invocacin de sus operaciones. Persistencia: Los objetos son permanentes o temporales? Qu hacen ante la falla de un proceso o un procesador? Subordinacin: La existencia o persistencia de un objeto depende de otro objeto? Distribucin: Estn el estado y las operaciones de un objeto accesibles desde varios nodos de la arquitectura fsica, y desde varios procesos de la arquitectura de procesos? 8

9.- Confeccionando el Modelo

No toda arquitectura de software requiere las 4+1 vistas completas. Las vistas que no son tiles pueden omitirse de la descripcin de arquitectura, tales como la vista fsica si hay un nico procesador, y la vista de procesos si existe un solo proceso o programa. Para sistemas muy pequeos, es posible que las vistas lgica y de desarrollo sean tan similares que no requieran descripciones independientes. Los escenarios son tiles en todas las circunstancias.

Mis Conclusiones Pues como vio la forma ms segura y confiable de desarrollar un proyecto de software es el modelo de vistas 4+1, porque detecta errores a tiempo, para no realizar trabajo innecesario. 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.