Software Architecture Document IEEE-1471-2000

1. Introduction 1.1 Purpose Este documento proporciona una descripcin comprensiva arquitectnica utilizando distintas vistas para representar los aspectos del sistema. Estas vistas son necesarias para capturar y transportar las decisiones significativas y arquitectnicas que han sido hechas sobre el sistema. 1.2 Scope El sistema MAD est siendo desarrollado por el curso de ingeniera de requerimientos del Magster en Ingeniera de Software, Tercera promocin, Universidad Andrs Bello, Campus Repblica, Chile Este documento ha sido generado directamente del anlisis del sistema MAD y el Modelo de Diseo, implementado en Rational Rose Versin 7.0. La mayora de las secciones ha sido extrada del Modelo de Rational Rose Versin 7.0 y la utilizacin de plantillas de referencia de ATAM (Architecture Tradeoff Analysis Method) y del modelo 4+1 de Kruchten. 1.3 Intented Users. Este documento de Arquitectura de Software puede ser usado y comprendido por todos los usuarios interesados, participantes del proyecto de desarrollo del sistema MAD. 1.4 Conformance to this recommended practique. N/A. 2. References Las referencias aplicables a este documento son: IEEE 830-1998 ST Architecture Tradeoff Analysis Method ISO 9126 -2001 Calidad del Software y Mtricas de evaluacin The 4+1 View .Kruchten 1999.

3 .Definitions, Acronyms and Abbreviations - Servicios (S): Entidad lgica que me permite realizar las operaciones CRUD (Create, Read, Update, Delete) sobre determinados recursos que son necesarios para el funcionamiento de la aplicacin que corre en el DM. Para acceder a los recursos se puede hacer directamente o a travs de otro servicio. En los servicios se puede realizar alguna transformacin sobre la informacin que me brindan los diferentes recursos. - SP: Services Provider - SPB: Es el service provider del dispositivo mvil. - APS: Es el Access Point Service. Es el encargado de comunicar las aplicaciones. - Recursos (R): Conjunto de elementos disponibles para resolver una necesidad o llevar a cabo una tarea. En nuestro caso los recursos pueden ser: Bases de Datos, Web Services, GUI, Sensores, etc. - Aplicaciones (Ap): Conjunto de Procesos que permite cumplir con una meta a travs de la utilizacin de servicios. En nuestra arquitectura, los procesos de la aplicacin se encuentran distribuidos entre los dos mundos. La ubicacin de estos procesos se establece en el momento de hacer deploy de la aplicacin. - Peers CAS (P-CAS): Entidades que se encargan de coordinar los servicios del mundo esttico. Estos estn inmersos dentro de una aplicacin. - Peers de Aplicacin (P-APP): Procesos del ambiente dinmico que tienen la capacidad de comunicarse entre ellos de una manera P2P. Los P-CAS y los P-APP se comunican a travs del AI. Pero si son del mismo tipo de Peers se comunica P2P. - Framework (F): Un framework es la extensin de un lenguaje mediante una o ms jerarquas de clases que implementan una funcionalidad y que (opcionalmente) pueden ser extendidas. En nuestro caso, el F se encargara de todas las interacciones de comunicacin, soportando un directorio de pginas amarillas y pginas blancas y siendo el facilitador de comunicaciones. - Acceso Inalmbrico (AI): El AI es el encargado de amortiguar los problemas de comunicacin y manejar el roaming de los DM entre las diferentes reas de cubrimiento.

- DM: Dispositivo Mvil. - DEI: Dispositivo Esttico Inalmbrico. - Mundo Esttico: El mundo esttico es una agrupacin de dispositivos como P.C., mviles, servidores, etc. que no cambian de ubicacin. Mundo Dinmico: El mundo dinmico se entiende como el conjunto de dispositivos mviles que cambian de ubicacin geogrfica continuamente.

4. Conceptual Framework 4.1 Architectural description in context Este documento presenta la arquitectura como una serie de vistas basadas en la arquitectura de software del modelo 4+1 de Kruchten. Estas vistas son: La vista de escenarios. La vista lgica. La vista de desarrollos. La vista fsica. La vista de procesos.

No hay ninguna vista separada de una misma implementacin descrita en este documento, estas vistas estn hechas sobre lenguaje de modelo unificado (UML) en su versin 2.0. Usando IBM Rational Rose Enterprise 7.0. Los estilos arquitectnicos sern referenciados en este documento de arquitectura, segn las recomendaciones de la Arquitectura de software del modelo 4+1 de Kruchten.

4.2 Stakeholders and their roles Este documento representa la identificacin de Stakeholders y sus roles a partir de la interpretacin de los casos de uso del Negocio. 4.3 Architectural activities in the life cycle N/A. 4.4 Uses of Architectural Descriptions. Las descripciones de arquitectura de este documento se usaran para referenciar el diseo de MAD

5. Architectural description practices 5.1 Architectural documentation La documentacin de la arquitectura se basa en el modelo propuesto 4+1. 5.2 Identification of stakeholders and concerns
Stakeholder descripcin AI es el que establece la comunicacin entre el mundo esttico y dinmico Aplicacin puede solicitar la ejecucin de otra aplicacin, servicio o proceso Dispositivo mvil quien da aviso que sigue conectado escenario -Escenario diseo MAD vistas - escenarios 1.- caso de uso de diseo

-Escenario diseo MAD

- escenarios 1.- caso de uso de diseo

-Escenario diseo MAD

- escenarios 1.- caso de uso de diseo

P-app representa el ambiente dinmico

-Escenario diseo MAD

- escenarios 1.- caso de uso de diseo

P-cas representa el ambiente esttico

-Escenario diseo MAD

- escenarios 1.- caso de uso de diseo

SP representa el proveedor de servicio, el cual actualiza y solicita recursos SPB representa el proveedor de servicio mvil, el cual actualiza y solicita recursos base

-Escenario diseo MAD

- escenarios 1.- caso de uso de diseo

-Escenario diseo MAD

- escenarios 1.- caso de uso de diseo

5.3 Selection of architectural viewpoints

Vistas Escenarios

UML Casos de uso

5.4 Architectural views