PONTIFICIA UNIVERSIDAD

JAVERIANA

Daniel Warner

SmartGauge

[SDD (SOFTWARE DESIGN DOCUMENT)]

PREFACIO

Respecto a Ingeniería de Software, después de un minucioso levantamiento y

análisis de requerimientos es de suma importancia que se proceda a pensar cómo

se va a diseñar la aplicación. Para esta tarea hay que identificar diferentes

factores como la arquitectura y los patrones de diseño a implementar. Este

documento es vital para la identificación de estos factores.

HISTORIAL DE CAMBIOS

Versión

Fecha de Actualización

Descripción

0.1

16/04/2013 Se adicionan puntos 1 y 2.1. y 2.2.

0.2 17/04/2013 Se modifica puntos 2.1 y 2.2. y se agregan 2.3. y 2.4.

0.2.1. 18/04/2013 Se modifica el punto 2.4.

0.3. 21/04/2013 Se agregan puntos 3,4,5 y 6

0.3.1. 25/04/2013 Se modifican puntos 5 y 6

0.3.2. 28/04/2013 Se modifica punto 4 y 5

0.3.3 03/05/2013 Se modifica punto 4

0.4 05/05/2013 Se modifican puntos 4 y 5 y se hace una revisión de ortografía y redacción del documento.

1.0. 09/05/2013 Se modifican el punto 1, 2, 3, 4 y 5

1.1. 12/05/2013 Se modifican punto 3 y 4.

1.1.1. 14/05/2013 Se hace revisión de redacción y ortografía.

Contenido PREFACIO ............................................................................................................................................. 2

HISTORIAL DE CAMBIOS ...................................................................................................................... 3

ILUSTRACIONES ................................................................................................................................... 6

TABLAS ................................................................................................................................................ 7

1. INTRODUCCIÓN ........................................................................................................................... 8

1.1. DESCRIPCIÓN DEL SISTEMA ................................................................................................. 8

1.2. MAPA DEL DISEÑO .............................................................................................................. 8

1.3. DEFINICIONES ACRÓNIMOS Y ABREVIACIONES ................................................................ 10

1.4. REFERENCIAS ..................................................................................................................... 11

2. CONSIDERACIONES DE DISEÑO ................................................................................................. 12

2.1. SUPOSICIONES ................................................................................................................... 12

2.2. RESTRICCIONES ................................................................................................................. 13

2.3. ENTORNO DEL SISTEMA .................................................................................................... 13

2.4. METODOLOGÍA DE DISEÑO ............................................................................................... 15

2.4.1. LEVANTAMIENTO Y ANÁLISIS DE REQUERIMIENTOS ................................................ 15

2.4.2. TRAZABILIDAD DE REQUERIMIENTOS ....................................................................... 16

2.4.3. PRUEBAS .................................................................................................................... 16

2.5. RIESGOS ............................................................................................................................. 17

3. ARQUITECTURA ......................................................................................................................... 18

3.1. APRECIACIÓN GLOBAL ....................................................................................................... 18

3.2. DIAGRAMA DE COMPONENTES ........................................................................................ 19

3.2.1. Cliente ....................................................................................................................... 20

3.2.2. Servidor ..................................................................................................................... 21

3.3. ESTRATEGIAS DE DISEÑO .................................................................................................. 21

4. DISEÑO DE ALTO NIVEL ............................................................................................................. 22

4.1. DIAGRAMA DE ARQUITECTURA GLOBAL .......................................................................... 22

4.1.1. CLIENTE ...................................................................................................................... 22

4.1.2. SERVIDOR .................................................................................................................. 23

4.2. DIAGRAMAS DE COMPORTAMIENTO E INTERACCIÓN ..................................................... 23

4.2.1. DIAGRAMAS DE ACTIVIDAD ...................................................................................... 23

5. DISEÑO DE BAJO NIVEL ............................................................................................................. 25

5.1. CLIENTE Y SERVIDOR ......................................................................................................... 25

6. DISEÑO DE INTERFACES DE USUARIO ....................................................................................... 26

6.1. DISEÑO GENERAL DE LA APLICACIÓN ............................................................................... 26

ILUSTRACIONES

Ilustración 1 Mapa del Diseño ............................................................................................................. 9

Ilustración 2 Suposiciones ................................................................................................................. 12

Ilustración 3 Restricciones de Diseño................................................................................................ 13

Ilustración 4 Proceso de Levantamiento Análisis de Requerimientos ............................................. 15

Ilustración 5 Trazabilidad de Requerimientos................................................................................... 16

Ilustración 6 Diagrama de Componentes SmartGauge ..................................................................... 19

Ilustración 7 Diagrama de Arquitectura ............................................................................................ 22

Ilustración 8 Pantalla de Ingreso de datos de conexión.................................................................... 27

TABLAS

Tabla 1 Requerimientos del entorno del sistema. ............................................................................ 14

Tabla 2 Pruebas de Software............................................................................................................. 17

Tabla 3 Subsistema Cliente ............................................................................................................... 20

Tabla 4 Componentes de Cliente ...................................................................................................... 20

Tabla 5 Subsistema Servidor ............................................................................................................. 21

Tabla 6 Componentes de Servidor .................................................................................................... 21

1. INTRODUCCIÓN

Lo que se busca con este documento es describir la estructura global de

SmartGauge y describir cada uno de sus componentes y cómo estos se

relacionan entre sí.

1.1. DESCRIPCIÓN DEL SISTEMA

SmartGauge es la continuación de un proyecto llamado ProMeter, busca

trabajar sobre una base de datos real de manera que se integre totalmente con

las estructuras de datos y las tablas sobre las cuales funciona el catálogo

electrónico CABASnet.

Para consumir y sincronizar datos de la base de datos, (llamada Metamodelo)

SmartGauge hace uso de Servicios Web montados sobre un servidor de GS1

Colombia, estos servicios web son consumidos tanto por la aplicación móvil,

como por otras aplicaciones de escritorio dedicadas a tareas de visión artificial.

1.2. MAPA DEL DISEÑO

En el siguiente gráfico observamos cada una de las secciones que contiene

este documento, los tipos de diseño y los diagramas que contiene cada uno:

Diseño de Alto Nivel: De acuerdo a los casos de uso, se trata de

comprender el sistema sin entrar en el tema de desarrollo.

Diseño de Bajo Nivel: De acuerdo a lo visto en el Diseño de Alto Nivel,

se da una solución lógica a los requerimientos.

Interfaz Gráfica: Hace referencia al entorno visual de la aplicación.

Ilustración 1 Mapa del Diseño

ALTO NIVEL

• Diagrama de componentes.

• Diagrama de despliegue.

• Diagrama de Secuencia

• Diagrama de Flujo.

BAJO NIVEL

• Diagrama de Clases cliente.

• Diagrama de clase servidor.

GUI

• Diseño general de la aplicación

• Árbol de navegabilidad.

1.3. DEFINICIONES ACRÓNIMOS Y ABREVIACIONES

SPMP: Software Project Management Plan.

SRS: Software Requirements Specification.

Tester: Es aquella persona encargada de realizar las pruebas de

software.

SDD: Software Design Document.

1.4. REFERENCIAS

[1] Adobe. Adobe Flash Professional CS5. Disponible en:

http://www.adobe.com/products/flash.html

[2] Adobe. Adobe Flash Builder 4.5 Premium. Disponible en:

http://www.adobe.com/products/flash-builder.html

[3] Adobe. Adobe Flash Player 11. Disponible en:

http://www.adobe.com/es/products/flashplayer.html

[4] Craig, Larman. Applying UML and patterns an introdution to object-oriented analysis and

design and interative development. Ed 3. Prentice Hall. 2005

2. CONSIDERACIONES DE DISEÑO

2.1. SUPOSICIONES

En el diseño de SmartGauge se cuenta con supuestos por parte del cliente, del

desarrollador y de las maquinas en las cuales será ejecutada la aplicación. A

continuación se listan estos supuestos.

Ilustración 2 Suposiciones

CLIENTE

• No realizará cambios en los requerimientos del sistema.

EQUIPO DESARROLLADOR

• Tendrá conocimientos en el desarrollo de aplicaciones en los lenguajes C# y Java.

• Cuenta con las herramientas necesarias para el diseño y la implementación las aplicaciones móviles y de escritorio.

MAQUINAS

• Debe poseer una dirección IP pública para facilitar el acceso permanentemente a los datos.

2.2. RESTRICCIONES

Las restricciones que afectan el diseño de SmartGauge están descritas a

continuación:

Ilustración 3 Restricciones de Diseño

2.3. ENTORNO DEL SISTEMA

A continuación se describe el entorno de SmartGauge de acuerdo a la

clasificación que se le da a los requerimientos no funcionales. (Ver

requerimientos.)

ENTORNO DEL SISTEMA

TIPO REQUERIMIENTOS ASOCIADOS

Hardware -099 -103

Arquitectura -033 -100

Lenguaje

• El sistema está diseñado bajo el paradigma Orientado a Objetos por lo que se ha elegido utilizar Java y C#

Arquitectura

• El software implementará una arquitectura que consume servicios web WCF.

Cliente

• El período de desarrollo establecido por el cliente es del 18 de Febrero de 2013al 21 de Mayo del mismo año.

Interfaz -097 -104

Portabilidad -072

Tabla 1 Requerimientos del entorno del sistema.

2.4. METODOLOGÍA DE DISEÑO

Para el diseño del software se tiene en cuenta una serie de actividades las

cuales se encuentran detalladas a continuación.

2.4.1. LEVANTAMIENTO Y ANÁLISIS DE REQUERIMIENTOS

Ilustración 4 Proceso de Levantamiento Análisis de Requerimientos

PORCENTAJE DE IMPLEMENTACIÓN

Se definió el porcentaje de completitud del software de acuerdo al número de requerimientos terminados. Para cada entrega se establecieron los requerimientos que deberían ser implementados de la siguiente manera:

2da Fase: 48% 3ra Fase: 100%

PRIORIZACIÓN DE REQUERIMIENTOS

Para esta actividad se utilizó una estrategia cognitiva la cual consiste en exponer cada uno de los requerimientos y basándose en los cronogramas establecidos y el desarrollo de actividades paralelas se hace una priorización de

requerimientos.

LEVANTAMIENTO DE REQUERIMIENTOS

De acuerdo a lo que el cliente desea, se estableció una lista de requerimietos para el desarrollo del sistema.

2.4.2. TRAZABILIDAD DE REQUERIMIENTOS

La trazabilidad de requerimientos cuenta con una serie de actividades que se

muestran en la siguiente imagen.

Ilustración 5 Trazabilidad de Requerimientos.

Según como fue especificado en el documento SRS existe una plantilla que es

utilizada para la trazabilidad de los requerimientos (Ver plantilla). A

continuación se puede observar la trazabilidad de requerimientos hecha para

SmartGauge. (Ver trazabilidad de requerimientos)

2.4.3. PRUEBAS

En la tercera fase, ya cuando se disponga del 100% de los requerimientos

implementados, se realizará un escenario de pruebas en el cual se evaluará

cada uno de los requerimientos para verificar la calidad del software. Está tarea

consiste en llevar a cabo una serie de pruebas para la identificación de errores

que contenga el software. Los tipos de pruebas a realizar son los siguientes:

1. Definición de Casos de Uso.

2. Ingeniería de Requerimientos.

3. Diseño del Modelo de Dominio

4. Programación.

5. Identificación de los Requerimientos dentro del código.

PRUEBAS

TIPO DESCRIPCIÓN

Pruebas Unitarias Se realizan para garantizar el buen funcionamiento de un módulo de código.

Pruebas de Integración

Luego de verificar el funcionamiento de cada uno de los módulos, estos se integran y se procede a verificar que funcionen como un sistema.

Pruebas de validación Comprobar que el sistema cumpla con los requerimientos.

Pruebas funcionales Se hace un diseño de tareas específicas para probar cada una de las funcionalidades del sistema.

Tabla 2 Pruebas de Software

2.5. RIESGOS

En el SPMP se han identificado los riesgos que pueden presentarse en el

desarrollo de este proyecto, de igual forma su priorización y como mitigarlos.

(Ver análisis de riesgos)

3. ARQUITECTURA

3.1. APRECIACIÓN GLOBAL

SmartGauge posee una arquitectura cliente-servidor, en la cual diferentes

clientes se conectan a un equipo servidor mediante el cual se accede a la base

de datos, este se encargará de mantener brindar una capa de comunicación

intermedia entre clientes heterogéneos y la base de datos. Por otra parte la

versión cliente estará instalada en los diferentes equipos que se conectarán al

servidor, en esta versión se encuentra la lógica de presentación y de

procesamiento.

Es importante dividir en 3 módulos la información que el sistema procesa, la

interfaz gráfica de usuario y los eventos de usuario, para esto se hará uso del

patrón de diseño MVC puesto que nos permite repartir estos componentes de

esta manera y además su uso es frecuente en aplicaciones móviles. Una

representación de la arquitectura del sistema se puede ver en la sección 4.1.

3.2. DIAGRAMA DE COMPONENTES

Ilustración 6 Diagrama de Componentes SmartGauge

Deployment

Aplicación Móvil

Computador Servidor

Cliente:: Comunicacion

Cliente::Controlador

Cliente::Modelo Cliente::Vista

Servidor:: WCF

Servidor:: Controlador

Servidor:: MetaModelo

SOAP/HTTP

Un diagrama de componentes es aquel que nos permite visualizar todos los

elementos que posee un sistema de software, mostrando la estructura general

y el comportamiento del servicio que estos elementos proporcionan. La figura

anterior corresponde al diagrama de componentes del sistema.

Ahora se describirá cada uno de los subsistemas.

3.2.1. Cliente

Propósito del Subsistema

La aplicación móvil y otras de escritorio que se conectan a la base de datos mediante servicios web WCF (Windows Communication Foundation).

Composición del Subsistema

• Comunicación • Controlador • Modelo • Vista

Tabla 3 Subsistema Cliente

3.2.1.1. Componentes de cliente

Nombre del Componente Propósito del Componente

Comunicación Se encarga del intercambio de información entre el cliente y el servidor.

Modelo Contiene toda la lógica de negocio.

Vista Se encarga de la presentación gráfica de información al usuario

Controlador Se encarga de la comunicación entre el modelo y la vista

Tabla 4 Componentes de Cliente

3.2.2. Servidor

Propósito del Subsistema

Se encarga de recibir las peticiones de conexión de los clientes, descargas de datos y sincronización de información.

Composición del Subsistema

• WCF • Controlador • Metamodelo

Tabla 5 Subsistema Servidor

3.2.2.1. Componentes de servidor

Nombre del Componente Propósito del Componente

WCF Sincronizar información entre clientes y el servidor

Controlador Procesar los mensajes y sincronizarlos con la base de datos

Metamodelo Posee la información que alimenta el catálogo CABASnet.

Tabla 6 Componentes de Servidor

3.3. ESTRATEGIAS DE DISEÑO

Las estrategias de diseño implementadas para el desarrollo de la aplicación

contienen como primera parte el definir las tecnologías a utilizar, estas son

aplicaciones móviles, servicios web SOAP y aplicaciones de Windows Forms.

También se estableció que la arquitectura adecuada para el sistema es la de

cliente-servidor.

Ya teniendo claro lo anterior se procede a el desarrollo de cada uno de los

requerimientos, esto de acuerdo a la priorización de requerimientos realizada

por en el documento SRS (Ver análisis de requerimientos).

4. DISEÑO DE ALTO NIVEL

4.1. DIAGRAMA DE ARQUITECTURA GLOBAL

SmartGauge

Analizer

MobileService

Servidor de GS1 Metamodelo

Ilustración 7 Diagrama de Arquitectura

4.1.1. CLIENTE

En el diagrama anterior observamos un dispositivo móvil que posee las

siguientes características:

Nombre: Nexus 10

Procesador: ARM Cortex-A15, Dual core, 1700 MHz,

Sistema Operativo: Android 4.2.2

Memoria Ram: 2 GB

Video: ARM Mali-T604

El cliente debe permitir conexiones tareas asíncronas de red, por lo que se

requiere de una versión del sistema operativo superior a la 3.0.

4.1.2. SERVIDOR

En el diagrama de despliegue observamos un PC Servidor que posee las

siguientes características:

Procesador: 1800 GHz

Sistema Operativo: Microsoft Windows XP o una versión superior

Memoria Ram: 4 GB

El servidor deber permitir conexiones a servicios SOAP/HTTP a través del

puerto 80.

4.2. DIAGRAMAS DE COMPORTAMIENTO E INTERACCIÓN

4.2.1. DIAGRAMAS DE ACTIVIDAD

Los diagramas de flujo que muestran los procesos más relevantes del sistema

se pueden ver en el siguiente diagrama

Precargar información

Actualizar datos de productos

Sincronizar con la base de datos

Descargar imágenes a analizar

Analizar imágenes

Actualizar datos de dimensiones de productos

Sincronizar con la base de datos

Ilustración 9 Diagrama de Flujo de Datos

5. DISEÑO DE BAJO NIVEL

5.1. CLIENTE Y SERVIDOR

A continuación se muestra el diagrama clases del cliente y el servidor para

SmartGauge.

Ilustración 10 Diagrama de Clases

6. DISEÑO DE INTERFACES DE USUARIO

6.1. DISEÑO GENERAL DE LA APLICACIÓN

Las pantallas de la aplicación móvil presentan un ambiente colorido, el

desplazamiento a través de las pantallas es muy natural para el usuario

Ilustración 11 Pantalla de inicio

La ilustración 11 muestra la pantalla de inicio de la aplicación en la que se

muestra la dinámica del proceso propuesto donde cada visitador se dirige al

punto de interés, en este caso la fábrica productora, toma los datos, los

persiste en el dispositivo y finalmente sincroniza la nueva información.

Ilustración 8 Pantalla de Ingreso de datos de conexión

La ilustración 12 muestra la pantalla que solicita al jugador ingresar la IP, el

nombre de usuario y la contraseña La siguiente tabla describe los Ítems que la

componen.

ÍTEM DESCRIPCIÓN OBSERVACIONES

IP

El campo IP permite ingresar la

dirección IP del servidor en el que se

alojan los Web Services WCF.

La dirección IP debe ingresarse

con números y puntos según IP

versión 4.

Usuario

El campo Usuario permite ingresar el

nombre de usuario de la tabla

SSO_USER.

El usuario debe existir y aparecer

como activo en la base de datos.

Contraseña El campo Contraseña permite ingresar

al sistema. La contraseña debe ir cifrada.

La siguiente ilustración muestra cómo sería la precarga de datos de empresas y productos

desde la base de datos Metamodelo a través de los Servicios Web WCF.

Ilustración 13 Precarga de información

La siguiente pantalla muestra la lista de productos para una empresa elegida en la lista

anterior. La interfaz de usuario se adapta según la categoría del producto de manera que

solamente se solicitan datos relevantes para cada producto.

Además las tonalidades de los colores varían dependiendo del grado de completitud del

producto así: tono oscuro indica ausencia total de datos, tono medio indica ausencia parcial

de datos, tono claro indica que todos los campos están llenos.

Ilustración 14 Información de productos

Adicionalmente, el usuario puede usar el botón de código de barras con ánimo

de buscar un producto de la lista analizando su código de barras. Esto se

muestra a continuación.

Ilustración 15 Buscar producto con código

Cuando se accede a cada uno de los componentes de edición de productos, el

usuario puede editar los campos de los formularios utilizando las diversas

opciones que brinda Android para ello, como el dictado por voz y el teclado por

arrastre. Además de esto, los formularios cuentan con validadores internos

que restringen el ingreso de datos de acuerdo a las normas de GS1 Colombia.

Ilustración 16 Edición de producto

Cuando el usuario termina de editar los datos de los productos requeridos,

procede a sincronizar la información con la base de datos utilizando el botón

“sincronizar”. Posteriormente puede pulsar el botón “Subir imágenes” para que

luego sean analizadas por la aplicación de escritorio llamada Analizer.

Ilustración 17 Sincronizar y subir imánges

Como paso final, el usuario (puede ser un usuario distinto) se encarga de utilizar la aplicación

de escritorio que analiza las imágenes subidas mediante la aplicación móvil. La misma

aplicación se encarga de actualizar la base de datos en su tabla MTM_PRODUCT_DIMENSIONS

con la nueva información de las dimensiones analizadas de cada producto.

Ilustración 18 Descargar y analizar imágenes