SDD

2014
SDD
1
Stephanie
Buitrago
24/03/2014
SDD
TABLA DE CONTENIDO
LISTA DE FIGURAS ............................................................................................... 2
LISTA DE TABLAS ................................................................................................. 3
1. INTRODUCCIÓN ................................................................................................. 4
1.1
DESCRIPCIÓN DEL SISTEMA .............................................................. 4
1.2
DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES ....................... 4
1.3
REFERENCIAS ........................................................................................ 4
2. CONSIDERACIONES DE DISEÑO ................................................................ 4
2.1
SUPOSICIONES ....................................................................................... 4
2.2
RESTRICCIONES .................................................................................... 4
2.3
ENTORNO DEL SISTEMA ..................................................................... 4
3. METODOLOGIA DE DISEÑO........................................................................ 4
3.1
DISEÑO DEL SISTEMA.......................................................................... 5
3.1.1 Objetivos de diseño ............................................................................... 5
3.1.2 Identificación de subsistemas. ............................................................... 6
3.1.3 Aplicación de los principios de diseño .................................................. 6
3.2
IMPLEMENTACIÓN Y PRUEBAS ........................................................ 8
4. ARQUITECTURA ............................................................................................ 9
4.1
APRECIACIÓN GLOBAL ....................................................................... 9
4.2
MODELO DE DATOS ............................................................................. 9
4.3
DIAGRAMA DE CLASES ..................................................................... 10
4.4
ESTRATEGIAS DE DISEÑO ................................................................ 11
5. DISEÑO ALTO NIVEL .................................................................................. 13
5.1
DIAGRAMA DE DESPLIEGUE............................................................ 13
6. DISEÑO INTERFACES DE USUARIO ........................................................ 14
7. ANEXOS ......................................................................................................... 21
7.1
Referencias .............................................................................................. 21
7.2
Requerimientos ........................................................................................ 22
LISTA DE FIGURAS
Ilustración 1: Criterios para el Diseño[123] .............................................................. 5
Ilustración 2: Subsistemas ......................................................................................... 6
Ilustración 3: Principios del Diseño[122] .................................................................. 7
Ilustración 4: Bajo Acoplamiento[124] ..................................................................... 8
Ilustración 5: Diagrama de Clases ........................................................................... 11
Ilustración 6: Patrón de diseño[150]........................................................................ 12
Ilustración 7: Diagrama Despliegue [151] .............................................................. 13
Ilustración 8: Mapa de Navegación ......................................................................... 21
2
SDD
LISTA DE TABLAS
Tabla 1: Niveles de Prueba ........................................................................................ 9
3
SDD
1. INTRODUCCIÓN
El propósito de este documento es formalizar el diseño y las herramientas de diseño
que se utilizarán para el desarrollo de la aplicación propuesta por la alumna
Stephanie Buitrago para su trabajo de grado.
1.1 DESCRIPCIÓN DEL SISTEMA
Dresser es una aplicación
1.2 DEFINICIONES, ACRÓNIMOS, Y ABREVIACIONES
Ver Anexo Definiciones y Acrónimos
1.3 REFERENCIAS
Ver Anexo Referencias
2. CONSIDERACIONES DE DISEÑO
Este documento se encarga de brindar una descripción completa sobre la
funcionalidad del software y la expectativa sobre el producto por parte del
desarrollador y de los clientes. Igualmente, este es un documento de soporte para
los desarrolladores, en caso de que se vaya a continuar con el proyecto en otro
periodo academico.
2.1 SUPOSICIONES
Este producto será una aplicación independiente, que responderá con los requisitos
propuestos y tendrá un diseño modular para gestionar el proceso de
implementación.
2.2 RESTRICCIONES
Durante el transcurso de la realización de este documento, se ha estado
especificando todas las funciones del producto en la documentación de los casos de
uso (Ver anexo Casos de Uso.docx).
2.3 ENTORNO DEL SISTEMA
Las características del usuario se encuentran definidas dentro del Documento Casos
de Uso (Ver anexo Casos de Uso).
3. METODOLOGIA DE DISEÑO
La ingeniería de requerimientos de software consiste en descubrir qué
funcionalidad se tiene que crear para desarrollar las características del juego. El
diseño de software consiste en la planificación de cómo construir el sistema de
software de acuerdo con los requerimientos. El diseño de software implica
examinar todos los elementos del sistema para encontrar posibles formas de agrupar
los elementos según las relaciones que existan entre ellos.
4
SDD
En última instancia, esta actividad implica ciertos objetivos de diseño. Para
identificar los elementos y sus relaciones, se usaran reglas de diseño. Las reglas de
diseño comienzan con objetos y mensajes. Al reorganizar los elementos y refinar
las relaciones, aplicamos principios de diseño. Los principios de diseño ayudan a
identificar las colaboraciones de los objetos.
Por estas razones se ha decidido utilizar y aplicar unas modificaciones en los
métodos de diseño sugeridos por los autores Flynt & Salem y Bruegge[122][123].
3.1 DISEÑO DEL SISTEMA
La identificación de los requerimientos es necesario para el desarrollo del software,
se debe tener en cuenta el contexto en el que se pretende desarrollar la aplicación, la
población objetivo, y la meta que se quiere conseguir con la implementación del
proyecto. Además se deberá tener en cuenta el alcance definido, esto debido al
tiempo que toma el desarrollo vs el tiempo dado para desarrollar.
3.1.1
Objetivos de diseño
Los principales objetivos del diseño del sistema se pueden identificar a través de los
requerimientos del mismo, haciendo énfasis en los requerimientos no funcionales
(Ver Requerimientos del sistema). Esto se hace con el fin de poder generar un
producto de calidad que satisfaga todos los requerimientos y sus relaciones. Es por
esto que se han definido unos criterios para el diseño del sistema, estos se
encuentran descritos a continuación.
Costo
Usuario Final
Mantenibilidad
Ilustración 1: Criterios para el Diseño[123]
Como se muestra en la Ilustración 1, nuestros principales criterios de diseño son los
siguientes:
 Costo: Minimizar los costos del desarrollo del sistema, seguimiento
de los requerimientos a través de la trazabilidad, desarrollo rápido e
incremental.
5
SDD
 Mantenimiento: Minimizar el número de errores del sistema,
interfaces bien definidas, legibilidad del sistema.
 Usuario Final: La facilidad de usa para el usuario, robustez del
sistema, minimizar la tolerancia a los fallos.
La unificación de todos estos criterios de diseño permite generar una confiabilidad
del sistema para el usuario y para el cumplimiento de los requerimientos, además
también nos permite una portabilidad del sistema y una eficiencia del mismo [123].
3.1.2
Identificación de subsistemas.
Los subsistemas fueron previamente clasificados en el entregable anterior (Ver
SRS). Al hacer la clasificación de los requerimientos también se pudo concluir
como debería ser el manejo de los subsistemas en general. Estos son los tres
principales subsistemas del producto: Modelo, Vista y Controlador.
Ilustración 2: Subsistemas
Los subsistemas descritos en la ilustración 2, interactúan entre sí llevando la
información necesaria hasta el usuario final, el controlador es quien conoce la
lógica de negocio, el modelo es quien se comunica con la base de datos para
acceder a la información solicitada y la vista es la encargada de comunicarse con el
cliente para mostrar la información
3.1.3
Aplicación de los principios de diseño
Los principios de diseño nos ayudaran a dar una medida para perfeccionar las
relaciones que se desarrollan dentro y entre las componentes que conforman el
sistema de software. Además estos también nos darán a conocer cómo reformar el
sistema a través de mejoras incrementales. Se pueden utilizar estos principios para
ayudar a determinar cómo combinar, dividir, eliminar, y generalmente refinar los
elementos del sistema [122].
6
SDD
Buscar
Cohesión
Compartir
Recursos
Principios
de Diseño
Evitar
Acompla
-miento
Descomposicion
Ilustración 3: Principios del Diseño[122]
3.1.3.1 Buscar Cohesión
La cohesión se refiere a cómo podemos unir todas las dependencias de una manera
adecuada, es decir la cohesión mide la dependencia entre los componentes del
sistema. Es por esto que es deseable que en el sistema se descompongan los
componentes en subsistemas para asignar las responsabilidades adecuadas a cada
subsistema y a cada componente [122].
3.1.3.2 Evitar Acoplamiento
El acoplamiento se refiere al grado en el cual los elementos dependen unos de
otros. Cada elemento en un sistema, en cierta medida, depende de otros elementos
en el sistema. Por otra lado, cuando los elementos dependen demasiado unos de
otros, sus dependencias requieren que, cuando una parte del sistema debe ser
cambiado, muchas otras partes del sistema que tenga que ser cambiados también
[122].
7
SDD
8
Ilustración 4: Bajo Acoplamiento[124]
Es por esto que se busca que entre los subsistemas y componentes existan las
mínimas dependencias entre ellos.
3.1.3.3 Descomposición
La descomposición es un camino para lograr el acoplamiento y la cohesión. Se
puede descomponer una entidad dividiéndola en partes más pequeñas. Así pues
dividir un conjunto grande de funcionalidades en más pequeños separados por
subsistemas o componentes más pequeños reduciendo la complejidad. Se puede
observar en la Sección 3.1.2 la división que se realizó en el sistema en general para
lograr una bajo acoplamiento y alta cohesión [122].
3.1.3.4 Compartir recursos
Existen diferentes formas de ver los recursos. Compartirlos nos indica que hay
existen varias funcionalidades que necesitan de un mismo servicio. Los elementos
que proporcionan un determinado tipo de servicio se pueden agrupar en una clase o
componente. Por esto otros componentes pueden entonces recurrir a los servicios
que esta clase o componente ofrecen. Al aplicar esta colaboración se reduce la
complejidad [122].
3.1.3.5 Trazabilidad de requerimientos
En el entregable anterior se desarrollo y se describió como se realizaría la
trazabilidad de los requerimientos (ver SRS), esto es de gran ayuda para el SDD,
debido a que nos guiará en el desarrollo y planteamiento del diseño a partir de cada
una de las relaciones que se plantearon en la trazabilidad.
3.2 IMPLEMENTACIÓN Y PRUEBAS
La especificación de los requerimientos se realiza de la siguiente manera, según los
criterios definidos, basándose en la plantilla de “Requerimientos Templates Contrux[200]” con algunas modificaciones pertinentes que se adapten al desarrollo
del software.
SDD
Para lograr un análisis adecuado de todas las pruebas que se realizaran se
establecen los siguientes niveles de prueba.
Test
Unitaria
Objetivo
Personas
Descubrir errores de los
datos, lógica y algoritmos
Tester, equipo de
desarrollo y equipo de
pruebas
Tester
Funcionales
Descubrir errores de
implementación de
requerimientos
Tabla 1: Niveles de Prueba
4. ARQUITECTURA
Esta sección del documento contiene todos los requerimientos definidos para el
proyecto.
4.1 APRECIACIÓN GLOBAL
La arquitectura de la aplicación Dresser se desarrolló como una arquitectura
Modelo, Vista, Controlador, debido a que no existe un servidor o un cliente fijo, es
decir todos los nodos de la red establecida pueden ser clientes o servidores y se
comportan de igual manera, sin embarga hay que aclarar que existe una maquina
que es la anfitriona de una partida.
4.2 MODELO DE DATOS
A continuación se muestra el modelo entidad relación definido para la aplicación.
9
SDD
10
4.3 DIAGRAMA DE CLASES
Los requerimientos relacionados a las características del sistema son detallados y
especificados en el siguiente anexo (ver Anexo Requerimientos).
A continuación se muestra el diagrama de clases definido para el proyecto:
SDD
11
Ilustración 5: Diagrama de Clases
4.4 ESTRATEGIAS DE DISEÑO
Para el desarrollo de la aplicación Dresser se implementarán el siguiente patrón de
diseño en el código [125].
SDD
12
Ilustración 6: Patrón de diseño[150]
SDD
5. DISEÑO ALTO NIVEL
5.1 DIAGRAMA DE DESPLIEGUE
A continuación se muestra la arquitectura de alto nivel definido para la aplicación.
13
Ilustración 7: Diagrama Despliegue [151]
Los módulos que se observan en el diagrama anterior se describen a continuación:



Despachador: maneja el enrutamiento de solicitud del explorador. Analiza la
solicitud Web y realiza un procesamiento avanzado alrededor del HTTP, como
manejo las cookies, sesiones, métodos de petición, etc.
Controlador: una vez el despachador ha procesado la solicitud envía la
petición al controlador correspondiente. Este permite que los datos se
encuentren disponibles según sea necesario, controla la renderización de las
vistas y su redireccionamiento. Además, gestiona las sesiones de usuario, el
flujo de la aplicación, las características de almacenamiento en caché, módulos
auxiliares, etc.
Vista: es llamada por el controlador correspondiente, quien renderiza la
presentación de la página web solicitada. Este módulo proporciona diseños
SDD

magistrales, plantillas de búsqueda y ayudantes que colaboran a la generación
del código HTML y otros formatos de presentación.
Active Record: es un patrón arquitectónico usado para administrar los datos en
bases de datos relacionales a través de objetos. Mapea los objetos relacionales
con las clases. Este módulo construye la capa del Modelo que se utiliza para
crear las clases del modelo, que contienen la lógica de negocio, maneja las
validaciones y las relaciones.
6. DISEÑO INTERFACES DE USUARIO
14
SDD
15
SDD
16
SDD
17
SDD
18
SDD
19
SDD
20
SDD
21
Ilustración 8: Mapa de Navegación
7. ANEXOS
7.1 Referencias
SDD
7.2 Requerimientos
22