sdd (software design document) - …pegasus.javeriana.edu.co/~CIS1310SD04/SDD/SDD.pdf · servicios...
Transcript of sdd (software design document) - …pegasus.javeriana.edu.co/~CIS1310SD04/SDD/SDD.pdf · servicios...
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