Upload
vanduong
View
213
Download
0
Embed Size (px)
Citation preview
1
Sistema de Monitoreo del Estado Vial
Software
Design
Document
Diego Andrés Casas Avellaneda
Versión 1.0
SIMEV
2
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ón 0.2 30/9/2012 Secciones 3 Creación de sección 0.3 5/10/2012 Secciones 1 y 2 Modificación de
sección 1.0 15/10/2012 Secciones 1, 2 y 3 Lanzamiento de
documento
3
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
5. Diseño de Bajo Nivel.................................................................................................................... 23
4
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
5
Tabla de ilustraciones
Ilustración 1 - Estrategias de diseño del sistema ................................................................................ 12
Ilustración 2 - Estilos arquitecturales del sistema ............................................................................... 13
Ilustración 3 - Overview de la arquitectura de SIMEV ......................................................................... 16
Ilustración 4 - Diagrama de componentes del sistema ....................................................................... 18
Ilustración 5 - Diagrama de despliegue ............................................................................................... 19
Ilustración 6 - Estructura del diseño de bajo nivel .............................................................................. 23
6
Tabla de tablas
Tabla 1- Definiciones, acrónimos y abreviaciones ................................................................................ 9
Tabla 2 - Documentación de actividad 1: Captura de datos por medio de los sensores .................... 21
Tabla 3 - Documentación de actividad 2: Rectificación de las coordenadas empleando la cartografía
de Transmilenio ................................................................................................................................... 21
Tabla 4 - Documentación de actividad 3: Generación de mapa ......................................................... 22
Tabla 5 - Diseño de subsistemas ......................................................................................................... 23
Tabla 6 - Diseño de componentes ....................................................................................................... 24
Tabla 7 - Descripción de tabla datosmedicion .................................................................................... 25
Tabla 8 - Descripción de tabla estación ............................................................................................... 25
Tabla 9 - Descripción de tabla imperfección ....................................................................................... 26
Tabla 10 - Descripción de la tabla imperfecciontipo ........................................................................... 26
Tabla 11 - Descripción de la tabla medicion ....................................................................................... 26
Tabla 12 - Descripción de la tabla poligono_ruta................................................................................ 26
Tabla 13 - Descripción de la tabla punto_poligono............................................................................. 26
Tabla 14 - Descripción de la tabla usuario .......................................................................................... 27
Tabla 15 - Descripción de la tabla usuario_movil ............................................................................... 27
7
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.
8
1.3. Definiciones acrónimos y abreviaciones
Concepto Definición
Archivo 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.
9
Hardware Es la parte tangible de un sistema informático.
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
10
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.
11
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]
12
2. Consideraciones de diseño
2.1. Suposiciones Las 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. Restricciones Las 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ño Las 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]
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
13
Ilustración 2 - Estilos arquitecturales del sistema
• 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
14
3. Arquitectura del sistema
3.1. Apreciación global Para 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ísticas
Ví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]
15
3.2. Punto de vista contextual del diseño El sistema ofrecerá las funcionalidades especificadas en los casos de uso que se encuentran en
el documento
http://pegasus.javeriana.edu.co/~CIS1230IS03/documentos/EspecificaciónReqCasosdeUsoSIM
EV.xlsx
16
4. Diseño de alto nivel
4.1. Diseño de componentes del sistema El 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:
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.
17
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.
18
4.1.2. Diagrama de componentes
En el siguiente diagrama de componentes se mostrará el diseño general del sistema:
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.
cmp Componentes
RDBM
Serv idor de aplicaciones
Cliente web
Cliente móvil
Servidor
Contenedor web
Base de datos
Nav egador de
Internet
Simev Móv il
JSF
WebServ ice
El cliente web puede
ser cualquier
navegador descrito en
el SRS
El cliente móvil 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 actualiza 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 desarrollada
en el contenedor web.
«use»
«use»
«use»
19
4.1.3. Diagrama de despliegue
En 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ño
La 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.
20
4.2. Diseño de interacción del sistema A continuación se especificarán las interacciones del sistema más significativas para el
desarrollo y entendimiento del mismo.
4.2.1. Diagramas de secuencia
Se 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 actividad
Se enfatizará en las siguientes funcionalidades:
Captura de datos por medio de los sensores.
ID Diagrama de Actividad 1
Nombre 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.
21
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 2
Nombre 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, R18
Pre 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 3
Nombre 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-009
Requerimientos 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.
22
Condición de fallo: El mapa no es generado.
Tabla 4 - Documentación de actividad 3: Generación de mapa
4.2.3. Justificación del diseño
El 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.
23
5. Diseño de Bajo Nivel
5.1. Diseño de la estructura del sistema La 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ón
Cliente 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.
Tabla 5 - Diseño de subsistemas
Subsistema
Componente
Diagrama de clases
24
Cada subsistema contiene los siguientes componentes, mostrados en la Tabla 6.
Subsistema Componente Descripción
Cliente Web Navegador de Internet Permite la navegación en la aplicación web empleando HTML
Cliente 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ño
Los 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.
25
5.2. Diseño de distribución de datos del sistema
5.2.1. Modelo entidad relación
Para 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 Datosmedicion
Campo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO PRI auto_increment
medicion_id int(11) NO PRI
Lat double NO
Lon double NO
Fechahora timestamp NO CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP
Precisionmed int(11) YES
Velocidad float YES
X float YES
Y float YES
Z float YES
Azimuth float YES
lat_aj double YES
lon_aj double YES
poligono_ruta_osm_id int(11) YES MUL estacion_id int(11) YES MUL
Tabla 7 - Descripción de tabla datosmedicion
Tabla Estación
Campo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO PRI auto_increment
Nombre varchar(50) NO Dirección varchar(60) YES
Tipo varchar(8) YES
Lat double NO
Lon double NO
Tabla 8 - Descripción de tabla estación
26
Tabla Estación
Campo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO PRI
Fechahora timestamp NO CURRENT_TIMESTAMP
on update CURRENT_TIMESTAMP
Usuarioid int(11) NO MUL
Vizir int(11) NO
imperfecciontipoid int(11) NO MUL
medicion_id int(11) NO MUL
Tabla 9 - Descripción de tabla imperfección
Tabla Imperfecciontipo
Campo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO PRI
Nombre varchar(45) YES
Descripción varchar(200) YES
Tabla 10 - Descripción de la tabla imperfecciontipo
Tabla Medición
Campo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO PRI auto_increment
Usuarioid int(11) NO MUL
Tabla 11 - Descripción de la tabla medicion
Tabla poligono_ruta
Campo Tipo Nulo Llave Valor por defecto Atributos extra
osm_id int(11) NO PRI
Name varchar(45) NO
Oneway tinyint(1) YES
Bridge tinyint(1) YES
Sentido varchar(2) YES
Actualización datetime NO
Tabla 12 - Descripción de la tabla poligono_ruta
Tabla punto_poligono
Campo Tipo Nulo Llave Valor por defecto Atributos extra
id_poligono int(11) NO PRI auto_increment
poligono_ruta_osm_id int(11) NO PRI
Lat double YES
Lon double YES
Tabla 13 - Descripción de la tabla punto_poligono
27
Tabla Usuario
Campo Tipo Nulo Llave Valor por defecto Atributos extra
Id int(11) NO UNI auto_increment
Usuario varchar(45) NO PRI
Password varchar(65) YES
Ultimoacceso timestamp YES
Web tinyint(1) YES
Tipo char(1) YES
Tabla 14 - Descripción de la tabla usuario
Tabla usuario_movil
Campo Tipo Nulo Llave Valor por defecto Atributos extra
usuario_id int(11) NO PRI
IMEI varchar(18) YES
Tabla 15 - Descripción de la tabla usuario_movil
5.2.2. Justificación de diseño
Debido 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.