pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1230IS03/documentos/SDD.docx · Web viewEn UML...
Transcript of pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS1230IS03/documentos/SDD.docx · Web viewEn UML...
Sistema de Monitoreo del Estado Vial
Software
Design
Document
Diego Andrés Casas Avellaneda
Versión 1.0
1
SIME
Historial de cambios
Versión Fecha Sección del documento
Descripción de cambios
0.1 23/9/2012 Secciones 1 y 2 Creación de sección0.2 30/9/2012 Secciones 3 Creación de sección0.3 5/10/2012 Secciones 1 y 2 Modificación de
sección1.0 15/10/2012 Secciones 1, 2 y 3 Lanzamiento de
documento
2
Tabla de contenido
Historial de cambios............................................................................................................................2
Tabla de contenido..............................................................................................................................3
Tabla de ilustraciones..........................................................................................................................5
Tabla de tablas.....................................................................................................................................6
1. Introducción.................................................................................................................................7
1.1. Propósito..............................................................................................................................7
1.2. Alcance.................................................................................................................................7
1.3. Definiciones acrónimos y abreviaciones..............................................................................8
1.4. Referencias bibliográficas..................................................................................................10
1.5. Apreciación global..............................................................................................................11
2. Consideraciones de diseño........................................................................................................12
2.1. Suposiciones......................................................................................................................12
2.2. Restricciones......................................................................................................................12
2.3. Estrategias de diseño.........................................................................................................12
3. Arquitectura del sistema............................................................................................................14
3.1. Apreciación global..............................................................................................................14
3.2. Punto de vista contextual del diseño.................................................................................15
4. Diseño de alto nivel....................................................................................................................16
4.1. Diseño de componentes del sistema..................................................................................16
4.1.1. Overview de la arquitectura propuesta......................................................................16
4.1.2. Diagrama de componentes........................................................................................18
4.1.3. Diagrama de despliegue.............................................................................................19
4.1.4. Justificación del diseño...............................................................................................19
4.2. Diseño de interacción del sistema......................................................................................20
4.2.1. Diagramas de secuencia.............................................................................................20
4.2.2. Diagramas de actividad..............................................................................................20
4.2.3. Justificación del diseño...............................................................................................22
3
5. Diseño de Bajo Nivel..................................................................................................................23
5.1. Diseño de la estructura del sistema...................................................................................23
5.1.1. Justificación del diseño...............................................................................................24
5.2. Diseño de distribución de datos del sistema......................................................................25
5.2.1. Modelo entidad relación............................................................................................25
5.2.2. Justificación de diseño................................................................................................27
6. Diseño de interfaces de usuario.................................................................................................28
4
Tabla de ilustraciones
Ilustración 1 - Estrategias de diseño del sistema...............................................................................12Ilustración 2 - Estilos arquitecturales del sistema..............................................................................13Ilustración 3 - Overview de la arquitectura de SIMEV........................................................................16Ilustración 4 - Diagrama de componentes del sistema......................................................................18Ilustración 5 - Diagrama de despliegue..............................................................................................19Ilustración 6 - Estructura del diseño de bajo nivel.............................................................................23
5
Tabla de tablas
Tabla 1- Definiciones, acrónimos y abreviaciones...............................................................................9Tabla 2 - Documentación de actividad 1: Captura de datos por medio de los sensores....................21Tabla 3 - Documentación de actividad 2: Rectificación de las coordenadas empleando la cartografía de Transmilenio.................................................................................................................................21Tabla 4 - Documentación de actividad 3: Generación de mapa.........................................................22Tabla 5 - Diseño de subsistemas........................................................................................................23Tabla 6 - Diseño de componentes......................................................................................................24Tabla 7 - Descripción de tabla datosmedicion...................................................................................25Tabla 8 - Descripción de tabla estación..............................................................................................25Tabla 9 - Descripción de tabla imperfección......................................................................................26Tabla 10 - Descripción de la tabla imperfecciontipo..........................................................................26Tabla 11 - Descripción de la tabla medicion.......................................................................................26Tabla 12 - Descripción de la tabla poligono_ruta...............................................................................26Tabla 13 - Descripción de la tabla punto_poligono............................................................................26Tabla 14 - Descripción de la tabla usuario.........................................................................................27Tabla 15 - Descripción de la tabla usuario_movil...............................................................................27
6
1. Introducción
1.1. Propósito
Objetivo del documento:
Especificar el diseño del sistema de software de SIMEV (Sistema de Información y Monitoreo del Estado Vial).
Razón del documento:
El presente documento tiene como objetivo principal especificar el diseño del sistema empleando los requerimientos y casos de uso especificados en el Documento de Especificación de Software. El documento también establece los parámetros del diseño de alto nivel, diseño de bajo nivel y diseño de interfaces de usuario para definir el sistema en su totalidad.
Audiencia:
El documento está dirigido a cualquier persona con conocimientos técnicos en diseño de software con metodología orientada a objetos [1] y en Lenguaje Unificado de Modelado (UML) [2].
1.2. Alcance
El presente documento abarca los siguientes temas:
Diseño en alto nivel del sistema empleando las vistas de componentes, despliegue, actividades y secuencia.
Diseño en bajo nivel del sistema empleando división por subsistemas, el modelo entidad-relación y diagrama de clases
Diseño de interfaces del sistema.
7
1.3. Definiciones acrónimos y abreviacionesConcepto DefiniciónArchivo PDF Es un formato de almacenamiento de documentos
desarrollado por la empresa Adobe Systems
Cobertura Es el área geográfica en la que se dispone de un servicio determinado.
Concurrencia Es la capacidad que tiene el sistema para que desarrolle en paralelo peticiones de múltiples usuarios.
Conexión Remota Es la capacidad que tiene una maquina, PC o dispositivo móvil para compartir información con otra dentro de una misma red LAN o GPRS
Dependencia Es una aplicación o biblioteca requerida por otro programa para poder funcionar correctamente
Diagrama de actividad En UML un diagrama de actividades se usa para mostrar la secuencia de actividades. Los diagramas de actividades muestran el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el progreso de eventos contenidos en la actividad.
Diagrama de secuencia Es un diagrama que muestra la interacción de un conjunto de objetos a través del tiempo en un caso de uso determinado.
Diagrama de estados Estos diagramas sirven para describir el comportamiento de un sistema, representa los diferentes estados que puede adquirir una clase, como representarlas a diferentes etapas de su vida.
Dirección IP Una dirección IP es una etiqueta numérica que identifica de una manera lógica y jerárquica a una interfaz de un dispositivo dentro de una red.
GHz El gigahercio (GHz) es un múltiplo de la unidad de medida de frecuencia hercio. En esta unidad se mide el número de instrucciones del procesador de una máquina
Grafo Es una representación gráfica de objetos llamados “Vértices” unidos por enlaces llamados “Aristas” que permiten representar relaciones binarias.
Hardware Es la parte tangible de un sistema informático.
8
Interfaz Conocido también como GUI, es un programa informático que utiliza un conjunto de imágenes y objetos gráficos para representar visualmente las acciones de un sistema
ISP Internet Service Provider. Proveedor de acceso a internet.
Memoria RAM Es la memoria desde donde el procesador recibe instrucciones y guarda datos o resultados
Persistencia Es la capacidad de un sistema para guardar información en una base de datos, un archivo de texto, etc.
Priorización Es la asignación de un valor numérico a un determinado requerimiento para representar su importancia
Procesador Es el componente que interpreta las instrucciones contenidas en los programas y procesa sus datos
Protocolo TCP/IP Es el protocolo que permite que una máquina o PC se comunique con otra dentro de una red LAN. Protocolo orientado a conexión.
Prototipo Es un ejemplar o un primer molde de un producto en desarrollo
Puerto Es una interfaz para comunicarse con un programa a través de una red
Requerimiento funcional Define el comportamiento interno de un sistema, ya sean cálculos, manipulación de datos, que muestran como los casos de uso van a ser llevados a la practica
Requerimiento no funcional
Especifica criterios que pueden usarse para juzgar la operación de un sistema. No describe las funciones de un sistema.
Servidor Es una maquina o PC que forma parte de una red y provee servicios a otras computadoras denominadas clientes
Software Es el equipamiento lógico de un sistema informático, comprende el conjunto de componentes lógicos que hacen posible la realización de tareas
Trazabilidad Es la metodología de describir y seguir el requerimiento desde su origen hasta implementación en el sistema
Usuario Es la persona que va a usar el sistema (Usuario móvil, Usuario Web, Analista SIG, Jefe de Mantenimiento)
Tabla 1- Definiciones, acrónimos y abreviaciones
9
1.4. Referencias bibliográficas
[1] P. Coad, J. Luca and E. Lefebvre, Java Modeling Color with Uml: Enterprise Components and Process with Cdrom. Prentice Hall PTR, 1999.
[2] M. Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley Professional, 2004.
[3] Anonymous "IEEE Draft Standard for Information Technology--Systems Design--Software Design Descriptions," IEEE Unapproved Draft Std P1016/D7, Oct 2008, 2009.
[4] D. Distante, P. Pedone, G. Rossi and G. Canfora, "Model-driven development of web applications with UWA, MVC and JavaServer faces," Web Engineering, pp. 457-472, 2007.
[5] N. Medvidovic and R. N. Taylor, "Software architecture: Foundations, theory, and practice," in Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering-Volume 2, 2010, pp. 471-472.
[6] Y. Natchetoi, V. Kaufman and A. Shapiro, "Service-oriented architecture for mobile applications," in Proceedings of the 1st International Workshop on Software Architectures and Mobility, Leipzig, Germany, 2008, pp. 27-32.
[7] G. Smiatek, "SOAP-based web services in GIS/RDBMS environment," Environmental Modelling & Software, vol. 20, pp. 775-782, 6, 2005.
[8] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee, "Hypertext transfer protocol--HTTP/1.1," Hypertext Transfer Protocol--HTTP/1.1, 1999.
[9] M. Widenius, D. Axmark and A. MySQL, MySQL Reference Manual: Documentation from the Source. O'Reilly Media, Incorporated, 2002.
[10] N. Kassem and E. Team, Designing Enterprise Applications: Java 2 Platform. Addison-Wesley Longman Publishing Co., Inc., 2000.
[11] C. C. Miller, "A beast in the field: The Google Maps mashup as GIS/2," Cartographica: The International Journal for Geographic Information and Geovisualization, vol. 41, pp. 187-199, 2006.
[12] S. Coast, "The OpenStreetMap Initiative," 2008.
[13] Escuela Superior De Ingenieros De Bilbao, " Diseño e Implementación de un agente de usuario SIP," .
[14] Google Inc., "What is Android?" vol. 2012, 2012.
[15] Google Inc., "Android Developers - Main Page," 2012.
10
1.5. Apreciación global
En el presente documento se podrá encontrar la especificación del diseño del sistema en alto y bajo nivel, y el diseño de las interfaces de los usuarios para la interacción con el sistema.
Introducción – 1° Parte (Ir a la sección)
o Esta sección se encarga de presentar las razones por las cuales se desarrolla este documento SDD, su propósito y el alcance del sistema a desarrollar.
o Presenta términos y abreviaciones utilizados en el documento.
o Presenta las referencias y bibliografía consultada para el desarrollo de este documento.
Consideraciones de diseño – 2° Parte (Ir a la sección)
o Esta sección se encarga de describir las suposiciones, restricciones y estrategias de diseño.
Arquitectura del sistema – 3° Parte (Ir a la sección)
o En esta sección se describe la arquitectura general del sistema y sus principales características.
Diseño de alto nivel – 4° Parte (Ir a la sección)
o En esta sección describe de forma muy general la estructura y funcionalidades del sistema.
Diseño de bajo nivel – 5° Parte (Ir a la sección)
o En esta sección se describe de forma detallada los subsistemas que conforman el sistema y permiten una abstracción para realizar la implementación del sistema.
Diseño de interfaces de usuario – 6° Parte (Ir a la sección)
o En esta sección describe la interfaz gráfica que visualizará el usuario web y móvil.
El estándar que se sigue para la elaboración del SDD es el 1016 de 2009 de la IEEE [3]
11
2. Consideraciones de diseño
2.1.SuposicionesLas suposiciones tenidas en cuenta para el diseño del sistema son:
La aplicación web en ambiente de producción debe contar con Java Runtime Enviroment y Glassfish Open Source Edition y MySQL DB Community Edition para su correcto funcionamiento.
La aplicación móvil en ambiente de producción debe ser ejecutada teléfonos inteligentes con sistema operativo Android Gingerbread (API 2.2.3) o superior.
2.2.RestriccionesLas restricciones y limitaciones externas definidas para el sistema están descritas en la sección 2.4 del documento SRS.
2.3.Estrategias de diseñoLas principales estrategias de diseño que han sido empleadas para la construcción de SIMEV son: [4] [5]
Ilustración 1 - Estrategias de diseño del sistema
Los estilos arquitecturales empleados para la construcción de SIMEV son: [5] [6]
12
Modelo vista controlador
En el modelo se realiza la lógica de visualización del sistema.
La vista es la interfaz gráfica que comunica al usuario con el sistema.
El controlador se ocupa de todos losbotones y eventos que ocurren
en la interfaz del sistema.
Modelo sensor-computador-accionador
El sensor capta un estímulo externo según su tipo
El computador capta y procesa las lecturas del sensor según las reglas
del sistema.
El accionador captura la orden del computador y ejecuta la acción
correspondiente
Ilustración 2 - Estilos arquitecturales del sistema
13
Un servidor atiende múltiples peticiones de múltiples clientes.La conexión entre servidor y cliente se realiza empleando un protocolo.Los principales atributos de calidad de este estilo son: Rendimiento y disponibilidad.
Cliente servidor
Las aplicaciones se dividen funcionalmente en capas de persistencia, lógica de negocio y presentación.Las capas pueden estar distribuidas físicamente en múltiples nodos.Los principales atributos de calidad de este estilo son: Disponibilidad, Modificabilidad, Rendimiento y Escalabilidad.
3-tier
La Arquitectura Orientada a Servicios es una filosofía que debe permear la arquitectura general del sistema.Está orientado a una aproximación del modelo de negocio del sistema.Permite conectividad via internet empleando web service con interfaces y protocolos estándar (interfaces XML y conectividad via protocolo SOAP)
SOA
3. Arquitectura del sistema
3.1.Apreciación globalPara el diseño de SIMEV se han definido dos protocolos de comunicación principales dependiendo de la forma como se acceda al sistema (vía web ó vía móvil). Cada uno de los protocolos presenta opciones de interoperabilidad diferentes acorde a la plataforma de hardware sobre la cual se está interactuando con el sistema.
Forma de acceso Protocolo CaracterísticasVía web HTTP (TCP 8080) Protocolo orientado a conexión.
Permite fácilmente el despliegue de contenido multimedia.
Adecuado para mostrar información vinculada por hipertexto.
Vía móvil SOAP (TCP 8080) [7]
Protocolo orientado a conexión. Permite interoperabilidad de objetos de
forma remota. Protocolo estándar empleado en SOA. Independiente del lenguaje de
programación y lógica del sistema. Emplea intercambio de datos en XML.
Acceso Base de Datos
JDBC (TCP 3306) [8]
Protocolo orientado a conexión. Conector elaborado en lenguaje Java
para la base de datos MySQL Community Edition. [9]
Permite enviar y obtener información entre la capa lógica de la aplicación y la capa de persistencia empleando el lenguaje estructurado de consultas SQL.
Los atributos de calidad que se han tenido en cuenta para la elección de los protocolos son:
Disponibilidad de las conexiones (ISP móvil e ISP fijo). Disponibilidad del servidor de aplicaciones. Rendimiento: Volumen de datos transportados entre los clientes y el servidor. Modificabilidad: Independencia entre los protocolos de comunicación y la lógica del
sistema.
Para el diseño del sistema se debe tener en cuenta que la aplicación web es construida de acuerdo a la arquitectura provista por el framework Java Enterprise Edition (JEE) y a los contenedores Enterprise Java Beans (EJB). [4, 10]
14
3.2.Punto de vista contextual del diseñoEl sistema ofrecerá las funcionalidades especificadas en los casos de uso que se encuentran en el documento http://pegasus.javeriana.edu.co/~CIS1230IS03/documentos/EspecificaciónReqCasosdeUsoSIMEV.xlsx
15
4. Diseño de alto nivel
4.1.Diseño de componentes del sistemaEl diseño en alto nivel muestra la división del sistema en componentes, sus dependencias y el uso de los estilos arquitecturales en alto nivel. Este nivel de entendimiento contribuye a guiar al desarrollador en la implementación y a dar una perspectiva de alto vuelo con los detalles suficientes para la comprensión del sistema.
4.1.1. Overview de la arquitectura propuesta
Ilustración 3 - Overview de la arquitectura de SIMEV
Como se puede observar en la ilustración 3, la arquitectura general de SIMEV tiene en cuenta las partes principales del sistema según la arquitectura orientada a servicios móviles [6] y adiciona otras partes que realizan la funcionalidad del Sistema de Información Geográfica y la interacción con el cliente web.
Las principales partes del overview son:
16
Administrador de
conexiones
Controlador basado en eventos
Parser
Admon.
Objetos de Negoc
io
Visualización Interfa
z Usuari
o
Invocación Remota
Red Móvi
l WiFI/GPRS
Web Servic
eContenedor Web
RDBM
S
LBS Dispositivo móvil
Servidor Web
Servidor LBS
Servidor RDBMS
Almacenamiento
Admon. de
Sensores
Browser
Cliente Web
Servidor LBS: Representa los servicios de Google Maps [11] y OpenStreetMaps [12] con los cuales interactuará el sistema para realizar el despliegue de información de los análisis del Sistema de Información Geográfico.
Servidor Web: Contiene el servidor de aplicaciones y la lógica del sistema con las funcionalidades del Sistema de Información Geográfico. En este servidor también se exponen los servicios web necesarios para la interacción con el dispositivo móvil.
Servidor RDBMS: Contiene el motor de base de datos relacional empleado para almacenar la información del sistema.
Cliente Web: Permite a los usuarios que tienen acceso vía Web, según el Documento de Especificación de Software, acceder a la aplicación por medio de un browser.
Dispositivo móvil: Representa los Smartphones con sistema operativo Android que conformarán el sistema para capturar y enviar los datos de las imperfecciones viales. La arquitectura del sistema en el dispositivo cuenta con un mayor grado de detalle debido a las restricciones de los recursos del dispositivo móvil, las cuales son:
o Conectividad limitada del dispositivo por la cobertura de la red móvil.o Capacidad de procesamiento del dispositivo.o Capacidad de almacenamiento secundario del dispositivo.o Prestaciones del sistema operativo.
Con el fin de mitigar las restricciones se ha planteado la arquitectura general, teniendo en cuenta el uso intensivo de los sensores (GPS, acelerómetro y brújula) y de la comunicación entre el dispositivo y el servidor con el fin de almacenar los datos.
17
4.1.2. Diagrama de componentesEn el siguiente diagrama de componentes se mostrará el diseño general del sistema:
cmp Componentes
RDBM
Serv idor de aplicaciones
Cliente web
Cliente móvil
Servidor
Contenedor web
Base de datos
Navegador de Internet
Simev Móv il
JSF
WebServ ice
El cliente web puede ser cualquier navegador descrito en el SRS
El cliente móvi l es la aplicación móvil diseñada para el sistema.
Sensores
Sensor GPS Sensor acelerómetro
Controlador
Sensor brújula
Computador (Lógica)
Accionador
Comunicación WS «interface»
GUI
Se observa la implementación del estilo arquitectural Sensor, Computador, Accionador.
Como parte del estilo SCA se puede ver el estilo MVC. El modelo está contenido dentro de la lógica del computador y la vista se actual iza cada vez que el controlador realiza una acción sobre el paquete accionador.
Servidor de bases de datos relacional.
El servidor contiene el servidor de aplicaciones con la aplicación desarrolladaen el contenedor web.
«use»
«use»
«use»
Ilustración 4 - Diagrama de componentes del sistema
Como se puede observar en la ilustración 4, se hace un gran énfasis en el diseño de la aplicación móvil y en la contextualización de los principales componentes de la aplicación en el servidor de aplicaciones. El contenedor web es el entorno virtual de Java en donde la lógica de la aplicación correspondiente al servidor realiza su ciclo de vida en modo de ejecución. Este concepto es muy importante en el entorno de la aplicación debido a que los Requerimientos No Funcionales (RNF) y los Atributos de Calidad (AC) están apoyados directamente sobre el framework de desarrollo y no se construyen como parte de la solución, por lo que únicamente se hará alusión en el documento a los elementos de diseño correspondientes a las funcionalidades principales del sistema, las cuales han sido descritas en el Documento de Especificación del Sistema. Para mayor información sobre las principales características funcionales y no funcionales de Java Enterprise Edition por favor ingrese a la especificación del framework.
18
4.1.3. Diagrama de despliegueEn el diagrama de despliegue se detallarán las unidades de despliegue del sistema en sus respectivos nodos:
Ilustración 5 - Diagrama de despliegue
En la ilustración 5 se puede observar el diagrama de despliegue del sistema en el cuál se hace énfasis en la interrelación entre la configuración de hardware, software y unidades de despliegue del sistema. Es importante mencionar que desde esta vista se comienza a referenciar la tecnología sobre la cual está desarrollado el sistema con el fin de tener en cuenta los Atributos de Calidad específicos y necesarios para el desarrollo y la puesta en marcha del mismo.
4.1.4. Justificación del diseñoLa arquitectura del sistema se ha diseñado en conjunto para contrarrestar las limitaciones del sistema respecto a los siguientes Atributos de Calidad:
Rendimiento: Capacidad de procesamiento de los dispositivos móviles. Rendimiento: Capacidad de ancho de banda de las conexiones. Fiabilidad: Conexión de datos estable durante la transmisión de datos. Disponibilidad: Conexión de datos disponible durante el tiempo de uso del sistema. Escalabilidad: Crecimiento de las capacidades de cómputo de los clientes (web y
móvil), servidores y bases de datos.
19
4.2.Diseño de interacción del sistemaA continuación se especificarán las interacciones del sistema más significativas para el desarrollo y entendimiento del mismo.
4.2.1. Diagramas de secuenciaSe enfatizará en los siguientes Casos de Uso:
Capturar datos en modo manual. (CU-001) Analizar información recolectada empleando Buffer. (CU-004) Visualizar posibles imperfecciones por estación. (CU-008)
Las precondiciones y pos-condiciones de cada caso de uso están enunciados en el documento de especificación de casos de uso. Especificación de Requerimientos
4.2.2. Diagramas de actividadSe enfatizará en las siguientes funcionalidades:
Captura de datos por medio de los sensores.
ID Diagrama de Actividad 1Nombre Captura de datos por medio de los sensores
Descripción Muestra la forma como opera la recolección de sensores empleando el estilo arquitectural Sensor
– Controlador – Accionador. [5]
Casos de uso asociados CU – 001, CU – 002 Requerimientos asociados R01, R02, R03, R04, R05, R06, R07, R10
Pre condiciones El dispositivo debe estar en posición horizontal con respecto al suelo del vehículo con la pantalla hacia arriba.
El GPS debe estar habilitado en el dispositivo.
El vehículo debe estar en movimiento sobre la imperfección durante la captura de datos.
El dispositivo móvil debe operarse en condiciones normales (Plan de datos activo, señal de celda 50%, batería mínimo al 20%)
Post condiciones Condición de éxito: Los datos son capturados y almacenados en la aplicación web.
Condición de fallo: Los datos no son capturados por el dispositivo ni almacenados en el sistema.
20
Tabla 2 - Documentación de actividad 1: Captura de datos por medio de los sensores
Rectificación de las coordenadas empleando la cartografía vial de Transmilenio.
ID Diagrama de Actividad 2Nombre Rectificación de coordenadas
Descripción Muestra el proceso de rectificación de coordenadas capturadas por el GPS con una precisión inferior a 20 metros empleando la cartografía de Transmilenio obtenida desde
OpenStreetMap [12]Casos de uso asociados CU-003, CU-004, CU-005, CU-007, CU-009
Requerimientos asociados R8, R9, R11, R12, R13, R14, R17, R18Pre condiciones La información almacenada en el sistema
para su procesamiento a través de esta actividad debe ser consistente (latitud y longitud de tipo coma flotante)
El servidor debe contar con la suficiente capacidad de cómputo para la actividad, la cual se debe ejecutar sin impactar la disponibilidad de recursos del sistema.
Post condiciones Condición de éxito: La coordenada es rectificada correctamente.
Condición de fallo: La coordenada no es rectificada, por lo que su nuevo valor no es alterado.
Tabla 3 - Documentación de actividad 2: Rectificación de las coordenadas empleando la cartografía de Transmilenio
Generación de mapa.
ID Diagrama de Actividad 3Nombre Generación de mapa
Descripción Muestra la forma como se generan los mapas en la aplicación web con el apoyo de la cartografía
disponible en los LBS Google Maps y OpenStreetMaps [11][12]
Casos de uso asociados CU-004, CU-005, CU-006, CU-008, CU-009Requerimientos asociados R11, R12, R13, R15, R16, R18
Pre condiciones La información debe encontrarse en un estado consistente en el sistema.
Los campos de la información consultada deben ser válidos.
Post condiciones Condición de éxito: El mapa es generado correctamente.
Condición de fallo: El mapa no es
21
generado.Tabla 4 - Documentación de actividad 3: Generación de mapa
4.2.3. Justificación del diseñoEl diseño del sistema en la vista dinámica se ha centrado en modelar los estilos arquitecturales como parte de las funcionalidades del sistema y el impacto que tienen en la construcción del mismo. Para este fin se tienen en cuenta las restricciones del hardware del sistema dónde se desplegarán las funcionalidades.
22
5. Diseño de Bajo Nivel
5.1.Diseño de la estructura del sistemaLa estructura del sistema se representa de la siguiente manera con el fin de lograr mayor entendimiento sobre cada una de sus partes principales (subsistema), saber el objetivo que cumple cada sección dentro de sus partes principales (componente) y la forma como se implementa cada sección dentro del sistema y su integración con el conjunto (diagrama de clase) [13]
Ilustración 6 - Estructura del diseño de bajo nivel
Los principales subsistemas y componentes del sistema son:
Subsistema DescripciónCliente Web Permite la conexión remota con el sistema a
través del protocolo HTTP (TCP) empleando características de hipertexto y multimedia.
Cliente móvil Permite la conexión remota a través de una aplicación en la plataforma Android [14] y emplea el protocolo SOAP [7] para interactuar con el sistema de forma remota.
Servidor Equipo de gran capacidad de cómputo que alberga el servidor de aplicaciones y el servidor de bases de datos. Permite el procesamiento de grandes volúmenes de información que solicitan los clientes para realizar sus funcionalidades.
23
Subsistema
Componente
Diagrama de clases
Tabla 5 - Diseño de subsistemas
Cada subsistema contiene los siguientes componentes, mostrados en la Tabla 6.
Subsistema Componente DescripciónCliente Web Navegador de Internet Permite la navegación en la aplicación
web empleando HTMLCliente móvil SIMEV Móvil:
Comunicación WS GUI Computador (Lógica) Sensor GPS (Listener) Sensor acelerómetro
(Listener) Sensor brújula
(Listener)
Aplicación web que contiene los componentes de la arquitectura Sensor-Computador-Control.
Servidor Servidor de aplicaciones: HTTPD - JSF Contenedor web WebService
RDBM: Base de datos
Partes del servidor de aplicaciones: Generador de páginas dinámicas. Contenedor en tiempo de
ejecución de objetos. WebService SOAP (JAX-WS). Administrador de bases de datos
relacionales.Tabla 6 - Diseño de componentes
Los diagramas de clases que modelan el sistema se encuentran en:
Diagrama de Clases Aplicación Móvil (SIMEV.apk) Servidor (GlassFish 3.1.1)
o Contenedor JEE (SIMEV_container.jar) SIMEV_container.EJB SIMEV_container.Model
o Aplicación Web (SIMEV_web.war) SIMEV_web.controller SIMEV_web.webservice Interfaz WebService WSDL SIMEV
5.1.1. Justificación del diseñoLos subsistemas se han definido según el criterio de ubicación en los nodos físicos respectivos de despliegue, la alta cohesión de los componentes y funcionalidades que desarrollan los subsistemas. Según el diagrama de componentes y el diagrama de despliegue, los cuales establecen la arquitectura general del sistema, se ha realizado el análisis correspondiente para dividir los subsistemas.
24
25
5.2.Diseño de distribución de datos del sistema
5.2.1. Modelo entidad relaciónPara almacenar la información del sistema se ha diseñado el siguiente modelo Entidad-Relación que modela el conjunto de datos del sistema y brinda fiabilidad a la base de datos.
El modelo puede ser consultado aquí.
A continuación se muestra la descripción de cada una de las tablas de la base de datos:
Tabla DatosmedicionCampo Tipo Nul
oLlav
eValor por defecto Atributos extra
Id int(11) NO PRI auto_increment
medicion_id int(11) NO PRILat double NOLon double NOFechahora timestam
pNO CURRENT_TIMESTAM
Pon update CURRENT_TIMESTAMP
Precisionmed int(11) YES
Velocidad float YESX float YESY float YESZ float YESAzimuth float YESlat_aj double YESlon_aj double YESpoligono_ruta_osm_id int(11) YES MULestacion_id int(11) YES MUL
Tabla 7 - Descripción de tabla datosmedicion
Tabla EstaciónCampo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO PRI auto_incrementNombre varchar(50
)NO
Dirección varchar(60)
YES
Tipo varchar(8) YESLat double NOLon double NO
26
Tabla 8 - Descripción de tabla estación
Tabla EstaciónCampo Tipo Nul
oLlave Valor por defecto Atributos extra
Id int(11) NO PRIFechahora timestamp NO CURRENT_TIMEST
AMPon update CURRENT_TIMESTAMP
Usuarioid int(11) NO MULVizir int(11) NOimperfecciontipoid int(11) NO MULmedicion_id int(11) NO MUL
Tabla 9 - Descripción de tabla imperfección
Tabla ImperfecciontipoCampo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO PRINombre varchar(45) YESDescripción varchar(200) YES
Tabla 10 - Descripción de la tabla imperfecciontipo
Tabla MediciónCampo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO PRI auto_incrementUsuarioid int(11) NO MUL
Tabla 11 - Descripción de la tabla medicion
Tabla poligono_rutaCampo Tipo Nulo Llave Valor por defecto Atributos extra
osm_id int(11) NO PRIName varchar(45) NOOneway tinyint(1) YESBridge tinyint(1) YESSentido varchar(2) YESActualización datetime NO
Tabla 12 - Descripción de la tabla poligono_ruta
Tabla punto_poligonoCampo Tipo Nulo Llave Valor por defecto Atributos extraid_poligono int(11) NO PRI auto_incrementpoligono_ruta_osm_id int(11) NO PRI
27
Lat double YESLon double YES
Tabla 13 - Descripción de la tabla punto_poligono
Tabla UsuarioCampo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO UNI auto_incrementUsuario varchar(45) NO PRIPassword varchar(65) YESUltimoacceso timestamp YESWeb tinyint(1) YESTipo char(1) YES
Tabla 14 - Descripción de la tabla usuario
Tabla usuario_movilCampo Tipo Nulo Llave Valor por defecto Atributos extrausuario_id int(11) NO PRIIMEI varchar(18) YES
Tabla 15 - Descripción de la tabla usuario_movil
5.2.2. Justificación de diseñoDebido al gran volumen de datos que requieren ser almacenados, es necesario mantener la consistencia de la información de diversos tipos (usuarios, dispositivos, deficiencias y mediciones referenciadas geográficamente, etc.) en forma ordenada y con mecanismos que faciliten el acceso rápido a la información, en este caso a través del motor de bases de datos MySQL Community Edition. La decisión se basa también en la especificación de requerimientos del sistema (Sección 2.2.2.2) que ha sido desarrollada previamente.
28
6. Diseño de interfaces de usuario
Las interfaces de usuario han sido diseñadas de acuerdo a las necesidades de cada tipo de usuario y del dispositivo que empleen para interactuar con el sistema. De acuerdo con esta restricción las interfaces para los teléfonos inteligentes con sistema operativo Android [15] han sido desarrolladas en lenguaje XML siguiendo los parámetros de la arquitectura del sistema operativo. Para el caso de las interfaces de la aplicación web, el diseño se ha realizado empleando JSF (Java Server Faces) [4] a través de la metodología de Facelets, que permite una interacción rápida entre los elementos del estilo arquitectural Modelo-Vista-Controlador que se emplea en la visualización de elementos a través de Internet.
La descripción de cada interfaz se encuentra disponible en el Documento de Especificación de Requerimientos (Sección 2.1.2) junto a los mapas de navegabilidad para la aplicación móvil y la aplicación web.
29