Software Architecture Document IEEE-1471-2000 1. Introduction 1.1 Purpose Este documento proporciona una descripción comprensiva arquitectónica utilizando distintas vistas para representar los aspectos del sistema. Estas vistas son necesarias para capturar y transportar las decisiones significativas y arquitectónicas que han sido hechas sobre el sistema. 1.2 Scope El sistema MAD está siendo desarrollado por el curso de ingeniería de requerimientos del Magíster en Ingeniería de Software, Tercera promoción, Universidad Andrés Bello, Campus República, Chile Este documento ha sido generado directamente del análisis del sistema MAD y el Modelo de Diseño, implementado en Rational Rose Versión 7.0. La mayoría de las secciones ha sido extraída del Modelo de Rational Rose Versión 7.0 y la utilización de plantillas de referencia de ATAM ATAM ( Architecture Architecture Tradeoff Analysis Method) y del modelo 4+1 de Kruchten. 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 Métricas de evaluación - The 4+1 View .Kruchten – 1999.
3 .Definitions, Acronyms and Abbreviations - Servicios (S): Entidad lógica que me permite realizar las operaciones CRUD (Create, Read, Update, Delete) sobre determinados recursos que son necesarios para el funcionamiento de la aplicación que corre en el DM. Para acceder a los recursos se puede hacer directamente o a través de otro servicio. En los servicios se puede realizar alguna transformación sobre la información que me brindan los diferentes recursos. - SP: Services Provider - SPB: Es el service provider del dispositivo móvil. - 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 través de la utilización de servicios. En nuestra arquitectura, los procesos de la aplicación se encuentran distribuidos entre los dos mundos. La ubicación de estos procesos se establece en el momento de hacer deploy de la aplicación. - Peers CAS (P-CAS): Entidades que se encargan de coordinar los servicios del mundo estático. Estos están inmersos dentro de una aplicación. - Peers de Aplicación (P-APP): Procesos del ambiente dinámico que tienen la capacidad de comunicarse entre ellos de una manera P2P. Los P-CAS y los P-APP se comunican a través del AI. Pero si son del mismo tipo de Peers se comunica P2P. - Framework (F): Un framework es la extensión de un lenguaje mediante una o más jerarquías de clases que implementan una funcionalidad y que (opcionalmente) pueden ser extendidas. En nuestro caso, el F se encargaría de todas las interacciones de comunicación, soportando un directorio de páginas amarillas y páginas blancas y siendo el facilitador de comunicaciones. - Acceso Inalámbrico (AI): El AI es el encargado de amortiguar los problemas de comunicación y manejar el roaming de los DM entre las diferentes áreas de cubrimiento.
- DM: Dispositivo Móvil. - DEI: Dispositivo Estático Inalámbrico. - Mundo Estático: El mundo estático es una agrupación de dispositivos como P.C., móviles, servidores, etc. que no cambian de ubicación. · Mundo Dinámico: El mundo dinámico se entiende como el conjunto de dispositivos móviles que cambian de ubicación geográfica 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 lógica. La vista de desarrollos. La vista física. La vista de procesos.
No hay ninguna vista separada de una misma implementación descrita en este documento, estas vistas están hechas sobre lenguaje de modelo unificado (UML) en su versión 2.0. Usando IBM Rational Rose Enterprise 7.0. Los estilos arquitectónicos serán referenciados en este documento de arquitectura, según las recomendaciones de la Arquitectura de software del modelo 4+1 de Kruchten.
4.2 Stakeholders and their roles Este documento representa la identificación de Stakeholders y sus roles a partir de la interpretación 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 diseño de MAD
5. Architectural description practices 5.1 Architectural documentation La documentación de la arquitectura se basa en el modelo propuesto 4+1. 5.2 Identification of stakeholders and concerns Stakeholder
descripción AI es el que establece la comunicación entre el mundo estático y dinámico
escenario -Escenario diseño MAD
vistas - escenarios 1.- caso de uso de diseño
Aplicación puede solicitar la ejecución de otra aplicación, servicio o proceso
-Escenario diseño MAD
- escenarios 1.- caso de uso de diseño
Dispositivo móvil quien da aviso que sigue conectado
-Escenario diseño MAD
- escenarios 1.- caso de uso de diseño
P-app representa el ambiente dinámico
-Escenario diseño MAD
- escenarios 1.- caso de uso de diseño
P-cas representa el ambiente estático
-Escenario diseño MAD
- escenarios 1.- caso de uso de diseño
SP representa el proveedor de servicio, el cual actualiza y solicita recursos
-Escenario diseño MAD
- escenarios 1.- caso de uso de diseño
SPB representa el proveedor de servicio móvil, el cual actualiza y solicita recursos base
-Escenario diseño MAD
- escenarios 1.- caso de uso de diseño
5.3 Selection of architectural viewpoints
Vistas Escenarios
5.4 Architectural views
UML Casos de uso
