28
1 Sistema de Monitoreo del Estado Vial Software Design Document Diego Andrés Casas Avellaneda Versión 1.0 SIMEV

Software Design Document - Trabajos de Grado de la ...pegasus.javeriana.edu.co/~CIS1230IS03/documentos/SDD.pdf · de bajo nivel y diseño de interfaces de usuario para definir el

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.