MANUEL ALEJANDRO LOPERA OSPINA - USBCalibibliotecadigital.usbcali.edu.co/bitstream/10819/1659/1/...A...
120
APLICACIÓN WEB PARA EL DESARROLLO Y DIFUSIÓN DE REALIDAD AUMENTADA UTILIZANDO TECNOLOGÍAS LIBRES MANUEL ALEJANDRO LOPERA OSPINA UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN FACULTAD DE INGENIERÍAS INGENIERÍA DE SISTEMAS MEDELLIN 2013
Transcript of MANUEL ALEJANDRO LOPERA OSPINA - USBCalibibliotecadigital.usbcali.edu.co/bitstream/10819/1659/1/...A...
APLICACIÓN WEB PARA EL DESARROLLO Y DIFUSIÓN DE REALIDAD
AUMENTADA UTILIZANDO TECNOLOGÍAS LIBRES
MANUEL ALEJANDRO LOPERA OSPINA
UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN
FACULTAD DE INGENIERÍAS
INGENIERÍA DE SISTEMAS
MEDELLIN
2013
APLICACIÓN WEB PARA EL DESARROLLO Y DIFUSIÓN DE REALIDAD
AUMENTADA UTILIZANDO TECNOLOGÍAS LIBRES
MANUEL ALEJANDRO LOPERA OSPINA
Proyecto presentado para optar al título de Ingeniero de Sistemas
Asesor
Wilder Perdomo Charry, MSc. Gestión Tecnológica
UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN
FACULTAD DE INGENIERÍAS
INGENIERÍA DE SISTEMAS
MEDELLIN
2013
Nota de aceptación
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
__________________________
Firma del jurado
__________________________
Firma del jurado
Medellín, 18 de septiembre de 2013
DEDICATORIA
A mis padres Iván y Lucy por todo su amor, apoyo y confianza en mis decisiones.
Su esfuerzo ha sido grande y gracias a ustedes estoy aquí.
A mis hermanos Aldebaran, Santiago, Esteban y Airin por su cariño, sus juegos y
sus locuras, son los chicos de la casa y llenan de alegría a esta familia.
A mi amor María Teresa por todo su amor y comprensión. Desde el primer día que
te conocí me apoyaste, lo sigues haciendo y espero que así sea para siempre.
A mis amigos, Jonathan, Juan, Lorena y Giselly, ustedes con quienes estudié de
adolescente, aunque no fuimos a la misma universidad, siempre estuvieron
pendientes de mí, nunca nos distanciamos y seguimos siendo los mismos chicos
de siempre cuando estamos juntos.
A mis compañeros de pregrado, especialmente a Alejandra, Robert, Hugo y Jorge,
con quienes compartí muchas preocupaciones, momentos estresantes y
satisfacciones. Felicidades a ustedes también por su titulo.
A todos los maestros, facultad y personal administrativo, en especial a la Oficina
de Relaciones Internacionales. Todos ustedes aportaron a las bases de mi actual
profesión.
A todos aquellos que no alcanzo a nombrar, pero que de una u otra forma hicieron
posible que no me quedara a la mitad de mi camino.
AGRADECIMIENTOS
Al profesor Wilder Perdomo Charry por su acompañamiento y asesoría en la
elaboración de este proyecto. Sus consejos y observaciones hicieron posible la
culminación exitosa de mi carrera.
A todos mis maestros, especialmente a Carlos Arturo Castro Castro y Leonel
Velasquez (ex director del programa de Ingeniería de Sistemas) quienes fueron
claves en mi formación, por su metodología, disposición y acompañamiento en las
diferentes asignaturas y en la vida universitaria en general.
A la Universidad Nacional Autónoma de México, mi segunda Alma Mater, por
abrirme sus puertas durante un año y ofrecerme conocimientos que nunca pensé
encontrar en mi carrera, derivando así la idea de este proyecto de grado.
A Nasatec Ltda., una pequeña empresa y una gran familia que me abrió sus
puertas en el momento en que más lo necesitaba y que directamente contribuyó a
la culminación de mi carrera.
A mis padres, hermanos, esposa, amigos y compañeros de estudio, por su apoyo,
afecto y compañía, muchas gracias.
CONTENIDO
1 INTRODUCCIÓN ............................................................................................ 10
2 JUSTIFICACIÓN ............................................................................................. 11
3 PLANTEAMIENTO DEL PROBLEMA ............................................................. 12
4 OBJETIVO GENERAL .................................................................................... 13
5 OBJETIVOS ESPECIFICOS ........................................................................... 13
6 MARCO REFERENCIAL ................................................................................ 14
6.1 REALIDAD AUMENTADA ........................................................................ 14
6.2 METODOLOGIAS DE DESARROLLO DE SOFTWARE .......................... 17
6.2.1 Modelos de desarrollo de procesos.................................................... 20
6.2.2 Etapas del Proyecto de Software ....................................................... 28
6.2.3 El Lenguaje Unificado de Modelado (UML) ........................................ 48
7 DISEÑO METODÓLOGICO PRELIMINAR..................................................... 51
7.1 CON RELACIÓN A LOS REQUERIMIENTOS DEL SOFTWARE ............ 53
7.2 CON RELACIÓN AL DISEÑO DEL SOFTWARE ..................................... 54
7.3 CON RELACIÓN A LA IMPLEMENTACIÓN DEL SOFTWARE ............... 56
7.4 CON RELACIÓN A LA VALIDACIÓN DEL SOFTWARE .......................... 57
7.5 CON RELACIÓN A LA EVOLUCIÓN DEL SOFTWARE ........................... 57
8 CRONOGRAMA ............................................................................................. 58
9 APLICACIÓN WEB PARA EL DESARROLLO Y DIFUSIÓN DE REALIDAD
AUMENTADA UTILIZANDO TECNOLOGÍAS LIBRES .......................................... 59
9.1 OBJETIVOS DEL SISTEMA ..................................................................... 59
9.2 REQUERIMIENTOS DEL SISTEMA......................................................... 59
9.2.1 Requerimientos Funcionales .............................................................. 59
9.2.2 Requerimientos No Funcionales ........................................................ 61
9.2.3 Requerimientos de Información.......................................................... 62
9.3 ANÁLISIS Y DISEÑO DEL SISTEMA ....................................................... 62
9.3.1 Documento de Requisitos del Sistema ............................................... 63
9.3.2 Diagrama de Clases ........................................................................... 87
9.3.3 Diagramas de Secuencia ................................................................... 88
9.3.4 Arquitectura ........................................................................................ 89
9.3.5 Modelo de Datos ................................................................................ 91
9.3.6 Bosquejos de Interfaces Gráficas....................................................... 91
9.4 DESARROLLO DEL SISTEMA ................................................................. 96
9.4.1 Herramientas para el desarrollo del software ..................................... 96
9.4.2 Marcador de prueba para el visualizador de Realidad Aumentada .... 98
9.5 FUTURO Y EVOLUCIÓN DEL SISTEMA ................................................. 99
10 CONCLUSIONES ...................................................................................... 101
11 REFERENCIAS BIBLIOGRÁFICAS ........................................................... 102
12 ANEXOS .................................................................................................... 104
12.1 Manual de Usuario .............................................................................. 104
12.2 Manual de Administración ................................................................... 114
12.3 Glosario ............................................................................................... 117
12.4 Marcadores de prueba para Realidad Aumentada .............................. 120
INDICE DE FIGURAS
Figura 1. Flujo típico de una aplicación de Realidad Aumentada. ......................... 16
Figura 2. Diagrama del Modelo de Desarrollo Evolutivo ........................................ 23
Figura 3. Fases y actividades del Proceso Unificado. ............................................ 27
Figura 4. Patrón de Diseño Modelo – Vista – Controlador ..................................... 37
Figura 5. Diagrama de Casos de Uso del Sistema ................................................ 65
Figura 6. Diagrama de Clases ............................................................................... 87
Figura 7. Diagrama de Secuencia Crear Contenido .............................................. 88
Figura 8. Diagrama de Secuencia Visualizar Contenido ........................................ 88
Figura 9. Diagrama de la Arquitectura del Patrón de Diseño ................................. 89
Figura 10. Diagrama de la Arquitectura del Sistema .............................................. 90
Figura 11. Diagrama del Modelo de Datos ............................................................ 91
Figura 12. Interfaz Gráfica del Home Principal ...................................................... 92
Figura 13. Interfaz Gráfica del Home del Perfil del Usuario ................................... 92
Figura 14. Interfaz Gráfica de Información del Perfil de un Usuario ....................... 93
Figura 15. Interfaz Gráfica de la lista de Galerías .................................................. 93
Figura 16. Interfaz Gráfica de Creaciones ............................................................. 94
Figura 17. Interfaz Gráfica de Contactos ............................................................... 94
Figura 18. Interfaz Gráfica de Mensajes ................................................................ 95
Figura 19. Marcador de prueba para visualizador de Realidad Aumentada .......... 98
10
1 INTRODUCCIÓN
El proyecto que se presenta a continuación se enfoca en una tecnología
relativamente nueva: la Realidad Aumentada. El proyecto contempla el diseño y
desarrollo de un software de entorno Web que permita la difusión de esta
tecnología de forma simple, para que los desarrolladores especializados o no en el
tema puedan experimentar con ella utilizando contenido propio o de otros
usuarios.
La Realidad Aumentada es una tecnología que está siendo considerada de gran
potencial en muchos campos, como la educación y el entretenimiento, y aunque
fue desarrollada hace más de una década, el actual auge de los smartphones
abrió sus puertas a un sin número de aplicaciones innovadoras cercanas al
público en general.
El presente documento está constituido por el contexto que sustenta el proyecto,
el marco teórico de referencia, la metodología de trabajo en el desarrollo del
software y los primeros requerimientos y arquitectura del sistema. Cabe resaltar
que la documentación elaborada en el proceso del software, tiene en cuenta solo
los aspectos principales de una primera versión de prueba que servirá para ir
profundizando más en los requerimientos que se vayan haciendo evidentes con el
paso del tempo, la practica con la tecnología estudiada y las tendencias de los
usuarios que finalmente son quienes darán su aprobación.
11
2 JUSTIFICACIÓN
En la actualidad, los smartphones constituyen la mayor cuota del mercado para las
aplicaciones de Realidad Aumentada, sin embargo, las posibilidades de aplicación
en computadoras personales son aun más impresionantes dada la capacidad de
procesamiento superior a los teléfonos celulares. El uso de Realidad Aumentada
directamente en un navegador Web es actualmente un rubro menos explorado,
apenas hasta 2009 investigaciones particulares lograron portar un API para
generar Realidad Aumentada usando Java Script en páginas Web, así como otros
desarrollos en Actionscript para poder usar el Flash Player integrado en los
navegadores. Así pues, la escasa utilización de Realidad Aumentada en entornos
Web proporciona un área interesante por explotar y desarrollar.
Otro aspecto que motiva el desarrollo de este proyecto, es el reciente apoyo que
en la ciudad de Medellín se está dando en temas de Tecnologías de la
Información y contenidos de entretenimiento digital (área en que la Realidad
Aumentada es fuertemente explotada). Sería muy gratificante poder aportar a la
consolidación del uso de esta tecnología en la ciudad y a hacer más fácil su
apropiación entre los desarrolladores.
12
3 PLANTEAMIENTO DEL PROBLEMA
ARToolKit fue quizás uno de los avances más significativos en el mundo de la
Realidad Aumentada (RA). Esta biblioteca escrita en C y C++ abrió las puertas en
1999 a muchos desarrolladores que vieron la posibilidad de crear sus propias
aplicaciones de RA sin preocuparse por conceptos técnicos complejos propios de
la tecnología como el rastreo de patrones en tiempo real, el cálculo de la posición
relativa de la cámara con respecto al patrón y el posterior despliegue (renderizado)
del objeto virtual sobre el marcador en el mundo real. Este flujo aunque es sencillo
y comprensible en teoría, resulta ser complejo en la práctica, puesto que no todos
tienen los conocimientos matemáticos, algorítmicos y de acceso a hardware que
se requieren para programar una aplicación de este tipo.
Con el tiempo otros desarrolladores realizaron derivados de ARToolKit para
entornos móviles y web, este último es el principal enfoque de este proyecto.
JSARToolKit escrito en JavaScript o FLARToolKit en ActionScript (para ser usado
con Flash) son solo algunos casos de éxito que permitieron a la Realidad
Aumentada saltar a ambientes web. Ahora bien, en páginas Web, Flash Player
conlleva cierta carga de procesamiento sobre los navegadores, además de
requerir la instalación previa de plugins para su funcionamiento; esto puede
evitarse con el uso de HTML5 y/o WebGL.
A pesar de estos avances, en la actualidad sigue siendo difícil encontrar recursos
para aprender de forma fácil a utilizar RA en ambientes Web, tampoco existe
alguna comunidad online que se enfoque en este tema, solo algunos entusiastas
trabajando por separado y compartiendo sus avances en sus propios sitios Web.
Otro aspecto, que no es un problema desde el punto de vista técnico, pero si una
apreciación personal y que anima al desarrollo de este proyecto, es el tema de la
libertad del software. Explorar maneras de trabajo eficientes con la menor carga o
dependencia de licencias privativas es el reto a superar.
13
4 OBJETIVO GENERAL
Desarrollar una aplicación de entorno Web que permita la difusión de la Realidad
Aumentada entre los desarrolladores novatos y con experiencia en esta
tecnología, permitiendo así su experimentación con ella.
5 OBJETIVOS ESPECIFICOS
a. Investigar y explorar el uso de tecnologías libres para el desarrollo e
implementación de la plataforma.
b. Generar nuevo conocimiento, reforzar el existente y documentar los casos
de éxito para otras formas de desarrollar Realidad Aumentada y
aplicaciones de software usando tecnologías libres.
c. Compartir el contenido de Realidad Aumentada creado por los usuarios a
través de la interacción con los demás miembros de la plataforma, para así
difundir la tecnología.
d. Brindar más opciones de trabajo con Realidad Aumentada y propiciar
ambientes de creatividad en los usuarios que puedan desembocar en
modelos de negocio para su beneficio.
e. Portabilizar el contenido de Realidad Aumentada independientemente de la
plataforma donde se ejecute, por tratarse de un entorno Web.
f. Aplicar una metodología de desarrollo de software mixta que comprenda
aspectos importantes de los modelos: Evolutivo y Proceso Unificado.
14
6 MARCO REFERENCIAL
6.1 REALIDAD AUMENTADA
La Realidad Aumentada es una tecnología que a diferencia de la realidad virtual,
no pretende reemplazar el mundo real por uno virtual, sino al contrario, integrar
elementos virtuales al mundo real.
La idea de la Realidad Aumentada es ampliar (aumentar) la información que
percibimos con nuestros sentidos, un ejemplo de esto es Wikitude, una aplicación
muy galardonada de Realidad Aumentada disponible en Smartphones, cuya tarea
es sobreponer información (en pantalla) proveniente de Wikipedia (si tuviere) en la
imagen que está captando la cámara del dispositivo en tiempo real, así por
ejemplo, si un turista estuviese enfocando la torre Eiffel de Paris con la cámara de
su teléfono móvil, Wikitude buscará en Wikipedia la información relacionada y la
mostrará en pantalla sin perder de vista la imagen que la cámara está captando,
podemos ilustrarlo como globos de información flotando sobre la imagen de la
torre.
El ejemplo anterior muestra una de las aplicaciones que se le ha dado a la
Realidad Aumentada, pero existen muchas más posibilidades, limitadas solo por la
imaginación de los desarrolladores. El funcionamiento general de esta tecnología
se basa en la información que puede captar algún periférico de entrada (por lo
general una cámara), esta información es procesada para detectar patrones en la
imagen que son confrontados con una base de datos que relaciona que
información desplegar para cada patrón. La información es mostrada en pantalla
sobre el patrón que está captando la cámara, a esto se refiere con sobreponer
información virtual al mundo real, si el patrón se mueve la información virtual debe
hacerlo con él, conservando la posición y perspectiva de visualización. Otras
características de los dispositivos, como función GPS y sensores, ayudan a la
15
aplicación a brindar información referente a la ubicación del usuario y sus
movimientos.
El concepto de Realidad Aumentada no es tan nuevo, lleva más de 20 años
desarrollándose, pero las tecnologías para su desarrollo no estaban al alcance de
todos [1]. En épocas recientes, los avances en dispositivos móviles que integran
cámaras y pantallas de buena resolución, así como GPS y sensores de
movimiento, hicieron que se incrementara la producción de aplicaciones de
Realidad Aumentada para consumo cotidiano [2] como por ejemplo búsquedas en
internet a través de imágenes captadas por la cámara, despliegue de información
de acuerdo al punto de localización geográfico del usuario, videojuegos simples
con interacción de objetos reales, entre otros.
Muchas aplicaciones de Realidad Aumentada utilizan animaciones en tercera
dimensión para desplegar su contenido, actualmente esto es más eficiente dados
los avances en el hardware gráfico de las computadoras modernas. En general los
componentes de hardware necesarios para la Realidad Aumentada son:
Cámara de video.
Monitor o proyector de imágenes.
Hardware de procesamiento gráfico.
Funcionalidad GPS (sistema de posicionamiento global). Opcional.
Sensores de movimiento, proximidad, entre otros. Opcional.
Micrófono para captura de audio. Opcional.
El principal elemento en el desarrollo de RA es el sistema de seguimiento de
movimiento o Tracking System. La RA se apoya en marcadores que “ven” las
cámaras para que el software tenga un punto de referencia sobre el cual
superponer las imágenes virtuales. Estos marcadores se definen previamente y
pueden ser imágenes impresas (simples o complejas), texturas o más
recientemente objetos en tres dimensiones. El inconveniente con los marcadores
16
impresos es que no pertenecen al ambiente natural que la cámara está
visualizando por tal motivo interfieren en la percepción de inmersión del usuario.
En los años más recientes, se han dado avances para evitar utilizar estos
marcadores, así el sistema de tracking de RA es capaz de reconocer formas
reales, como el cuerpo humano u objetos cotidianos del mundo real [3], esto no
solo evita la molestia de tener que imprimir una imagen para mostrar a la cámara,
sino que también beneficia la experiencia e interacción del usuario con la
aplicación.
En la siguiente imagen tomada del sitio Web oficial del proyecto ARToolKit se
muestra el funcionamiento de una aplicación de Realidad Aumentada que utiliza
marcadores simples para realizar el proceso de tracking [4]:
Figura 1. Flujo típico de una aplicación de Realidad Aumentada.
Algunos campos en los que se utiliza actualmente la Realidad Aumentada son:
educación, medicina, procesos industriales, videojuegos, marketing y publicidad.
17
6.2 METODOLOGIAS DE DESARROLLO DE SOFTWARE
El proceso de construcción de software implica el uso de cierta metodología
estructurada para garantizar el mejor resultado posible en la calidad y
funcionalidad del producto final, que satisfaga completamente los objetivos para
los que fue creado y por ende supliendo la o las necesidades del cliente o usuario
final.
Para este proyecto en especial, se recopilará la información clave sobre las
metodologías que más se acoplen al esquema del mismo; ya que se trata de una
propuesta de software de desarrollo personal con la visión de ofrecer un servicio
de interés público a futuro, que no recopilará directamente requisitos de clientes o
usuarios finales, sino que planteará sus bases y funcionalidad en lo que
personalmente el desarrollador quiere ofrecer a un público masivo. Así pues, la
información teórica contenida en este apartado, se centrará exclusivamente en la
descripción de los procesos y métodos a utilizar durante el ciclo de vida del
proyecto y dejará de lado (o se mencionarán solamente) aquellas metodologías
que no serán usadas.
Aun así, sin importar el modelo del proceso de desarrollo, hay ciertas etapas de
actividades que son transversales a todos ellos y rigen la dirección del proyecto
[5]. Estas son:
Especificación del Software: se refiere al planteamiento de los alcances y la
funcionalidad, elaborado a partir del análisis de requisitos levantados al
inicio del proyecto. También se le conoce como Ingeniería de
Requerimientos, la cual entrega como producto final un documento de
requerimientos formal y detallado que se necesitará en las demás etapas
del proyecto. Las tareas básicas de la ingeniería de requerimientos son:
18
o Estudio de factibilidad: analiza si el software es viable, desde lo
tecnológico y desde el aspecto económico.
o Obtención y análisis de requerimientos: es la recolección de los
requerimientos a través de entrevistas con los usuarios, la
observación del ambiente, los roles y tareas de los usuarios.
o Especificación de requerimientos: se elabora el documento de
requerimientos con base al análisis hecho en la tarea anterior. Este
documento incluye los requerimientos abstractos del usuario y los
requerimientos del sistema, los cuales sirven al equipo de
desarrolladores para programar la aplicación (en este proyecto solo
se incluirá este último tipo de requerimientos).
o Validación de requerimientos: se verifica la consistencia de los
requerimientos incluidos en el documento anterior. Si se encuentran
errores se procede a la corrección antes de liberar el documento
hacia la siguiente etapa del proyecto.
Diseño e implementación del software: el diseño e implementación habla
sobre la producción de la aplicación como tal con base a la especificación
planteada. Abarca las actividades de diseño del sistema y su programación.
Las actividades principales de esta etapa son:
o Diseño arquitectónico: se comprende y se realiza el diseño de los
subsistemas del software y sus interacciones.
o Especificación abstracta: para cada subsistema se especifican sus
servicios y limitaciones de operación.
o Diseño de interfaces: forma de comunicación entre los subsistemas.
19
o Diseño de componentes: se determinan los servicios que ofrecerán
los diferentes componentes que integran los subsistemas y se
diseñan sus interfaces.
o Diseño de la estructura de datos: definición de los modelos de bases
de datos y de estructuras estáticas y dinámicas de almacenamiento.
o Diseño de algoritmos: esta tarea no siempre es realizada por los
analistas, sino que se deja a los programadores. De todas formas,
incluye la determinación de la lógica de programación a utilizar para
llevar los casos de uso a programas ejecutables.
Validación del software: las actividades de validación abarcan todo el
compendio de pruebas funcionales, de rendimiento y detección de errores
para depurar el software antes de salir a servicio. En sistemas grandes,
estas pruebas por lo general se desarrollan desde las unidades mínimas
que integran el software hasta el software como un todo funcional. Las
etapas en el proceso de prueba son:
o Prueba de unidades: pruebas individuales a cada componente para
asegurar su correcto funcionamiento.
o Prueba de módulos: los módulos contienen varios componentes que
se relacionan entre sí, la prueba de módulos consiste en verificar el
funcionamiento de todos esos componentes trabajando juntos dentro
del módulo.
o Prueba de subsistemas: consiste en probar las interfaces de los
módulos que conforman el subsistema para asegurar que dichos
módulos se comuniquen adecuadamente.
20
o Prueba del sistema: se prueba el sistema completo, con todos los
subsistemas que lo integran y se verifica que cumpla con los casos
de uso (requisitos funcionales).
o Prueba de aceptación: se utilizan los datos reales del cliente para
probar el sistema completo antes de ponerse en servicio, esta
prueba revela el desempeño del sistema y verifica que los datos
están bien definidos y la información que proporciona el sistema es
fiable.
Evolución del Software: hace referencia a todo el seguimiento post-
producción que se le realiza a la aplicación, con el ánimo de agregar
nuevas funcionalidades, ajustar detalles, corregir posibles fallas no
detectadas y en general asegurar una línea de usabilidad prolongada del
sistema, haciendo que este se adapte a los cambios de las organizaciones
y/o tendencias de los usuarios finales.
6.2.1 Modelos de desarrollo de procesos
Existen importantes modelos de procesos de software muy utilizados, como por
ejemplo, el Modelo en Cascada, el cual ve cada etapa de actividades como una
fase separada a las demás, las cuales se desarrollan completamente antes de
pasar a la siguiente, partiendo desde el análisis de requisitos hasta la
implementación y seguimiento del sistema.
Este Modelo en Cascada no es el más adecuado para el desarrollo de este
proyecto de software. Debido a su corto plazo de entrega, no es recomendable
dedicar toda una larga, rigurosa y exhaustiva fase inicial en solo el levantamiento
de requerimientos para la especificación del sistema, ya que podría agotarse
considerablemente el tiempo para entregar por lo menos un prototipo funcional.
21
Por otro lado, está el modelo de Proceso Unificado, el cual proporciona una
estructurada forma de trabajo y presenta un enfoque incremental e iterativo de las
actividades. Es muy completo, pero debido al periodo de tiempo tan corto para la
entrega del software, no se podrá abarcar en su totalidad.
Es por lo anterior, que se ha tomado la decisión de implementar un Modelo
Evolutivo [5] y tomar ciertas características del Proceso Unificado. El Modelo
Evolutivo permitirá entrelazar las actividades del proceso, teniendo así una más
rápida transición a la etapa de programación de los componentes del software con
base a unos requerimientos iniciales generales de gran relevancia recopilados
mediante algunas técnicas que propone la metodología del Proceso Unificado. Los
detalles de la metodología a utilizar se tratarán más adelante.
6.2.1.1 Modelo de Desarrollo Evolutivo
Como se mencionó anteriormente, este modelo permite entrelazar las diferentes
fases de actividades del proyecto, entre otras cosas, como la transición rápida a la
programación directa de la aplicación, este modelo posibilita la continua
retroalimentación entre las etapas de desarrollo. Básicamente, se trata de
implementar un sistema inicial basado en los requerimientos más generales, este
sistema se somete a pruebas de validación y regresa a la etapa de especificación
para definir requerimientos más específicos que añadan funcionalidad al software,
normalmente son los usuarios los cuales están muy cercanos al proceso de
desarrollo, quienes retroalimentan cada nuevo requerimiento a través de pruebas
funcionales, observaciones y comentarios entre cada versión. Por las razones
expuestas previamente, será el programador de la aplicación y su tutor encargado
quienes evalúen el funcionamiento de la nueva versión en cada ciclo de iteración
del modelo hasta obtener un sistema adecuado para su lanzamiento (no siendo
este la versión final ya que podrá evolucionar posteriormente).
22
La diferencia crucial con el Modelo en Cascada es que no pretende separar las
etapas de especificación, desarrollo y validación, al contrario estas se
complementan mutuamente unas con otras a lo largo del proyecto, esto permite
una retroalimentación y respuestas rápidas entre cada nuevo requerimiento
funcional del sistema. El Modelo Evolutivo pretende que se tenga la mayor
comprensión de los requerimientos iniciales del sistema para desarrollar la primera
versión y mediante sometimiento a la evaluación del cliente, se refine hasta
alcanzar la versión final.
En su libro, Ingeniería de Software, Ian Sommerville describe dos tipos de
desarrollo evolutivo:
Desarrollo exploratorio: el cual se basa en desarrollar un sistema inicial con
los requerimientos generales que se comprendan mejor, e ir
evolucionándolo mediante la agregación de nuevas funcionalidades con los
requisitos propuestos por el cliente.
Prototipos desechables: los prototipos tienen la función de experimentar
con los requerimientos del cliente que no se comprendan completamente.
El Modelo Evolutivo es una forma muy eficiente de llevar proyectos pequeños y
medianos en cortos períodos de tiempo, para proyectos grandes con períodos de
tiempo largos no es muy recomendado debido a la constante interacción entre las
fases que puede descomponer o alterar la arquitectura inicial del sistema. En
general, como todo modelo, el Modelo Evolutivo presenta desventajas [5]:
La rápida iteración especificación - desarrollo – validación hace que sea
complicado, tedioso y costoso la documentación rigurosa de la evolución
del proceso.
23
Los cambios continuos al sistema pueden tender a desequilibrar o
corromper la arquitectura de diseño del software. Por esta razón, el modelo
no es recomendable para proyectos muy grandes y extensos en tiempo.
Al permitir que los requerimientos y decisiones de diseño se retrasen, la
arquitectura del software corre el riesgo de estar débilmente planteada y su
programación puede ser difícil de mantener y comprender.
El siguiente diagrama está basado en la Figura 3.2 contenida en el libro Ingeniería
de Software, Sexta Edición de Ian Sommerville y proporciona una comprensión
más clara del Modelo de Desarrollo Evolutivo:
Figura 2. Diagrama del Modelo de Desarrollo Evolutivo
En la Figura 2 pueden verse las etapas del desarrollo, su interacción concurrente y
las versiones del sistema que entregan. El bosquejo de la descripción del sistema
es la primera entrada al proceso, la cual sirve para generar junto con las
especificaciones generales la versión inicial del software. Por último, las flechas
Seguimiento y Mantenimiento
Bosquejo de
la descripción
Versión inicial
Versión final
Versiones
intermedias
Especificación
Desarrollo
Validación
Evolución
Fases de
Actividades
24
punteadas de seguimiento y mantenimiento indican su característica de opcional,
ya que en la práctica real, no siempre en un proyecto se contrata una fase post-
producción para seguir dando soporte al software. En el caso de que se ingrese en
una fase de Evolución, implica retomar la metodología desde el bosquejo de la
descripción de lo que se quiere lograr, para luego especificar los requerimientos
de la nueva versión a desarrollar.
6.2.1.2 El Proceso Unificado
El Proceso Unificado (UP por sus siglas en inglés) es una metodología híbrida de
desarrollo iterativa, esto quiere decir que recoge las mejores características del
modelo en cascada y también las mejores prácticas del desarrollo evolutivo, para
de esta forma conformar un desarrollo incremental. El Proceso Unificado es una
de las más robustas metodologías, la cual está basada en tres ideas
fundamentales [6]:
Dirigido por casos de uso
Centrado en la Arquitectura
Iterativo e incremental
Los casos de uso son funciones del sistema que dan resultados al usuario. Estas
funciones están especificadas individualmente y mediante la integración de todas
se genera un software plenamente funcional. Los casos de uso se representan
mediante diagramas UML (Lenguaje Unificado de Modelado por sus siglas en
ingles), los cuales son una fuerte herramienta para la especificación de los
requisitos funcionales del sistema. UML abarca además otra serie de diagramas
importantes que se tratarán más adelante.
El Proceso Unificado propone los casos de uso para ser utilizados a lo largo de
todo el proyecto. Se encuentran inmersos en la especificación de requerimientos,
25
diseño de la arquitectura, programación del código de la aplicación, realización de
la validación y en general para tener documentado el diseño del software.
UP está centrado en la arquitectura porque define rigurosamente su diseño. Esta
arquitectura está basada en componentes que se integran e interactúan entre sí a
través de interfaces. Esta visión arquitectónica fuertemente definida, disminuye los
riesgos de inestabilidad del software que podrían tenerse con la aparición de
nuevos requerimientos a lo largo del ciclo de vida del proyecto.
Es Iterativo e incremental, porque su desarrollo se lleva a cabo a través de mini-
proyectos que van incrementando la funcionalidad del software. Las iteraciones
son los pasos en el flujo de actividades y los incrementos se refieren al
crecimiento del producto [6], cada nueva iteración del proceso genera valor al
producto. Los incrementos brindan la posibilidad a los usuarios de probar
funcionalidades del sistema y explorar nuevos requerimientos ya que por lo
general nunca se obtiene el 100% de los requerimientos al inicio del proyecto; las
iteraciones facilitan la adaptación ante estos cambios.
En el Proceso Unificado, la arquitectura y los casos de uso dependen el uno del
otro, deben coexistir y evolucionar a la par a través del proceso de desarrollo. Esto
es evidente en la necesidad que tiene la arquitectura de estructurarse basada en
los casos de uso claves del sistema y a su vez estar diseñada de tal forma que
permita la evolución e inclusión de nuevos casos de uso. El proceso de diseño de
la arquitectura podría definirse de la siguiente manera [6]:
Borrador con un esquema básico de la arquitectura, empezando con la
parte no específica de los casos de uso, como la plataforma.
Se toman los casos de uso claves del sistema, aquellos que representan
las funciones más relevantes del software, estos casos de uso representan
subsistemas dentro del sistema global.
26
La evolución de casos de uso apoyan el ajuste de la arquitectura, la cual
genera de forma recíproca ajustes de más casos de uso.
El Proceso Unificado comprende cinco flujos de trabajo o actividades:
Requisitos
Análisis
Diseño
Implementación
Pruebas
Y se divide en cuatro fases durante la línea de tiempo del proyecto, en las cuales
constantemente se desarrollan las 5 actividades anteriores:
Inicio: comprende una descripción del producto final, sus objetivos,
justificación, comprensión del ambiente del negocio en el cual estará
inmerso el producto, se definen los riesgos más relevantes, se realiza una
estimación de los costos del proyecto, se levantan requerimientos críticos y
se elaboran casos de uso claves, se diseña un borrador de la arquitectura
general la cual puede ser provisional, también se planifica la siguiente fase
del proyecto.
Elaboración: esta fase contempla la especificación en detalle de la mayor
parte de los casos de uso y el diseño de la arquitectura.
Construcción: se crea el producto como tal. Se programan los casos de
uso, se crean los componentes que conforman los subsistemas y se
integran finalmente para entregar el software completo. Los programadores
pueden descubrir pequeñas mejores formas de pulir la arquitectura pero
esta sin embargo no debe sufrir mayores modificaciones.
27
Transición: esta fase está comprendida por el periodo en que el software
completo se somete a pruebas de algunos usuarios para informar de fallas
o deficiencias que los programadores deben resolver antes de liberarse
completamente a todos los usuarios finales. Esta fase comprende también
la capacitación, acompañamiento y asistencia al cliente.
A lo largo de estas cuatro fases se realizan las diferentes iteraciones, cada
iteración abarca las 5 actividades o flujos de trabajo mencionadas previamente y
cada iteración desembocara en un incremento del sistema. La siguiente figura
muestra las fases y su correspondiente carga de trabajo a cada una, estas cargas
no representan ningún dato exacto, son solo representaciones para ayudar a
comprender mejor el comportamiento del proceso de desarrollo.
Figura 3. Fases y actividades del Proceso Unificado.
28
6.2.2 Etapas del Proyecto de Software
6.2.2.1 Requerimientos del Software
El proceso del levantamiento y análisis de requerimientos es posiblemente una de
las etapas más delicadas y complejas de todo proyecto de software. Su
importancia es tan alta, porque implica el establecimiento claro, detallado y
estructurado de la funcionalidad del sistema completo antes de comenzar la etapa
de construcción de código de software.
A menudo los problemas más recurrentes durante esta etapa son producto de no
haber especificado y establecido las diferencias entre los requerimientos del
usuario y los requerimientos del sistema [5]. Estos son:
Requerimientos del usuario: describen la forma en la que el sistema debe
funcionar, a través de diagramas o mediante declaraciones escritas en
lenguaje natural, contienen los servicios que se esperan y las limitaciones
de operación.
Requerimientos del sistema: describen con riguroso detalle los
requerimientos del usuario, esto es, especificar las funciones y restricciones
del software, estos requerimientos conforman el documento de
requerimientos del sistema (DRS) el cual servirá como guía a los
programadores y también como contrato oficial entre el cliente y el equipo
de desarrollo, ya que contiene claramente lo que el sistema podrá y no
podrá hacer.
Los requerimientos se clasifican según su nivel de aportación a la funcionalidad,
comportamiento, implementación y despliegue del sistema. Esto significa que no
todos los requerimientos están directamente relacionados con la estructura del
sistema que provee los servicios funcionales a los usuarios finales, además hay
29
una serie de requerimientos que denotan otras instancias del software que no
tienen que ver con su desarrollo ejecutable, sino que describen él como este se
incorporará a las organizaciones y a las sociedades, considerando desde las
plataformas tecnológicas hasta las disposiciones legales, sociales y éticas entre
las que se enmarcará el sistema.
6.2.2.1.1 Requerimientos Funcionales
Los requerimientos funcionales se refieren al comportamiento del sistema, los
servicios que ofrecerá, la forma de reaccionar ante las entradas que proporcione el
usuario (u otros sistemas) y a las salidas o resultados que emitirá. Esto especifica
también cuales son las restricciones y alcances de la aplicación de software y es
el punto de partida para diseñar la arquitectura del sistema y posteriormente
proceder con la programación.
Los requerimientos funcionales del sistema deben estar rigurosamente detallados,
no deben ser ambiguos en su descripción ya que provocarían malas
interpretaciones por parte de los programadores y esto conllevaría a fallas en el
software que causaran contratiempos en las etapas finales de proyecto y su
consiguiente incremento de tiempo y costos presupuestales.
Estos requerimientos funcionales del sistema serán representados en detalle a
través del modelo de casos de uso, que a su vez estará contenido en el
documento de requerimientos del sistema.
6.2.2.1.2 Requerimientos No Funcionales
Los requerimientos no funcionales son todos aquellos que no se refieren a la
funcionalidad del sistema como tal, sino que plantean características o
propiedades que debe tener la aplicación para cumplir con los objetivos. Ejemplos
de estos requerimientos podrían ser: un ancho de banda considerable en canal de
30
conexión si es una aplicación en red, capacidad suficiente de almacenamiento en
la base de datos, manejo de estándares para alguna aplicación específica,
características de los servidores, plataformas sobre las cuales debe estar
soportada la aplicación, entre otros.
“Los requerimientos no funcionales surgen de las necesidades del usuario, debido
a las restricciones en el presupuesto, a las políticas de la organización, a la
necesidad de interoperabilidad con otros sistemas de software o hardware o a
factores externos como los reglamentos de seguridad, las políticas de privacidad,
etcétera” [5]. Estos requerimientos se podrían clasificar en:
Requerimientos del producto: describen el comportamiento del sistema, su
desempeño, su usabilidad, portabilidad, rapidez de ejecución, etcétera.
Requerimientos organizacionales: de acuerdo a las políticas y procesos al
interior de la organización del cliente y también en la empresa de desarrollo.
Se refieren a estándares, documentación, políticas de calidad, etcétera.
Requerimientos externos: todos los demás requerimientos que implica la
implementación del sistema, por ejemplo, requerimientos legales y éticos.
Los requerimientos no funcionales son importantes porque si no se cumplen
podrían generar la no utilización del producto de software. Mientras que las
consecuencias de no cumplir un requerimiento funcional son la pérdida de
funcionalidad que podría arreglarse implementando nuevamente dicho
requerimiento, las consecuencias al no cumplir un requerimiento no funcional son
más graves aun, puesto que el sistema de software nunca podría ver la luz, por
ejemplo al incumplir con un requerimiento de tipo legal.
31
6.2.2.1.3 Requerimientos del Dominio
Estos requerimientos pueden ser funcionales o no funcionales, o restringir o
ampliar alguno de estos. Se refieren a los requerimientos vinculados al dominio del
negocio para el cual el software está siendo desarrollado. Por lo general, el
analista de requerimientos debe conocer sobre el negocio para poder entender
estos requerimientos y describirlos detalladamente para que sean comprendidos
también por los desarrolladores, sino podría producirse un problema de
interpretación y el requerimiento se implementaría de forma incorrecta.
6.2.2.1.4 Requerimientos de información
Los requerimientos de información aunque en muchos libros no están clasificados
independientemente de los demás requisitos, en esta ocasión serán utilizados
para definir el compendio de requisitos relacionados a la información que debe
almacenar el sistema (en concreto, la base de datos del sistema). Estos
requerimientos serán de ayuda en el análisis y diseño de la base de datos de la
aplicación ya que están compuestos por la descripción de los campos que
deberán llevar las tablas de la base de datos. Aunque podrían considerarse un
requerimiento funcional (es cierto que se podrán mencionar en los requerimientos
funcionales), al definirlos detalladamente aparte de los demás requerimientos
brindan la facilidad de tener casi listo el esquema de la base de datos, quedando
solo pendiente el análisis de las relaciones entre las entidades.
6.2.2.1.5 Documento de Requerimientos del Sistema
Este documento es la especificación detallada de lo que debe hacer y no hacer el
software. Servirá a los diseñadores y arquitectos de software, programadores y
analistas de pruebas en todas sus actividades, y al cliente y a la misma empresa
de desarrollo les servirá como un contrato que describe los alcances del proyecto.
32
Es por todo esto, que su importancia es alta, y debe estar arduamente revisado
para evitar contratiempos. Un proyecto de software no siempre mantiene el
original de este documento hasta culminarse, generalmente, los cambios y ajustes
a los requerimientos siempre se presentarán, la idea con un buen análisis de
requerimientos es que estos cambios sean los menos posibles.
El documento de requerimientos del sistema incluye los requerimientos del usuario
en un lenguaje comprensible para el cliente y los requerimientos del sistema
detallados dirigidos al equipo de desarrolladores y analistas del proyecto. Los
requerimientos funcionales del sistema se especificaran mediante la descripción y
diagramas de casos de uso de UML. Además, el documento de requerimientos del
sistema, también puede incluir:
Historial de los cambios entre cada versión del documento.
Índice (de diagramas, tablas, imágenes)
Introducción
Participantes en el proyecto
Objetivos del sistema
Requerimientos de información
Arquitectura del sistema, mostrada de manera global.
Evolución del sistema, donde se planteen cambios previstos a futuro.
Glosario de términos técnicos utilizados en el documento.
Apéndices
6.2.2.2 Diseño del Software
La etapa de diseño consiste en la elaboración del material que describa la manera
en que estará estructurado el producto de software a desarrollar. El diseño es el
proceso creativo de transformar el problema planteado a través de los
requerimientos en una solución de software [7]. Esto indica que el diseño es una
33
de las etapas más críticas del proyecto ya que de este dependerá el rendimiento,
estabilidad y confiabilidad del sistema. El diseño del software entrega
generalmente cuatro productos de documentación importantes, estos son:
Diseño de la Arquitectura
Diseño de Interfaces
Diseño del Modelo de Datos
Diseño de Algoritmos
6.2.2.2.1 Diseño de la Arquitectura
El diseño arquitectónico del sistema es una etapa crucial en el ciclo de vida del
proyecto, este debe ser cuidadosamente analizado para cumplir con los
requerimientos. Como se mencionó anteriormente, en el Proceso Unificado por
ejemplo, las actividades de diseño y análisis de requerimientos prácticamente
evolucionan a la par, ya que una retroalimenta a la otra y viceversa. Esto significa
que el diseño arquitectónico inicial del software se realizará con base a los
requerimientos claves, conforme se tenga mejor comprensión de los
requerimientos se refinará esta arquitectura. Lo ideal es que la arquitectura no sea
modificada a lo largo del proyecto, en la práctica se ve a menudo que la
arquitectura final no es la original propuesta inicialmente; esto puede darse debido
a un mal análisis de los requerimientos, cambios en los requisitos por parte del
cliente, necesidad de implementar una nueva tecnología, entre otros. Siendo
conscientes de que estos cambios a la arquitectura pueden darse, la idea es
diseñar una arquitectura lo más estable posible, en la cual los cambios (si se
presentan) sean menores y no afecten la esencia de la misma.
En sistemas medianos y grandes, el software se compone de subsistemas y
módulos [5]. Los subsistemas son independientes de los servicios suministrados
por otros subsistemas, se componen de módulos los cuales por lo general si
34
dependen de los servicios brindados por otros módulos. Los módulos están
integrados por componentes de menos escala como pueden ser las clases de
objetos.
El diseño arquitectónico define la relación entre los elementos estructurales más
importantes del software, los estilos y patrones de diseño, así como las
restricciones de operación [8]. Los requerimientos no funcionales son
fundamentales en la definición de estas restricciones de operación, ya que como
se mencionó anteriormente, evalúan si el sistema puede ser utilizado.
La tarea de diseñar la arquitectura iniciará con la identificación de los subsistemas
del software (si los tiene) y los servicios que ofrecerá cada uno, paso siguiente,
deben identificarse las relaciones entre estos. Con esto se armará una estructura
base de cómo estará distribuida a aplicación. Ahora cada subsistema se especifica
en sus componentes y de igual manera teniendo claro que servicio ofrecerá cada
componente, se pueden agrupar en módulos por tipos de servicio, tipos de
procesos o roles de los usuarios, entre otros.
Un criterio muy importante a la hora de diseñar los subsistemas y sus
componentes, es el concepto de independencia entre estos. La independencia
básicamente se refiere a dos factores: acoplamiento y cohesión [7].
Acoplamiento: si dos componentes dependen mucho el uno del otro se dice
que están fuertemente acoplados. Si las dependencias no son muchas
entonces los componentes son poco acoplados y en ese mismo orden, si
no existen dependencias entonces son componentes no acoplados. Las
dependencias pueden darse:
o Al un componente referenciar a otro.
o Al pasar datos de un componente a otro.
o Al un componente controlar el estado de otro.
o La complejidad de las interfaces entre componentes.
35
Cohesión: se refiere al grado de relación que existen entre las partes de un
componente. En otras palabras, “un componente es cohesivo si todos sus
elementos están orientados a la realización de una única tarea y son
esenciales para llevarla a cabo” [7].
El acoplamiento entonces se refiere a la relación de los componentes hacia afuera
de ellos y su interdependencia con otros. La cohesión en cambio tiene el sentido
contrario y se refiere a la relación hacia adentro del componente, el cómo sus
partes se organizan y trabajan para cumplir una función.
La meta del diseño de la arquitectura es proponer componentes con un bajo
acoplamiento y una alta cohesión, que permitan mayor facilidad en la
comprensión, programación y mantenimiento del software.
Después de definir la estructura de subsistemas del software, se procede a
desglosar sus módulos. Para este proyecto se utilizará un estilo de modelo
arquitectónico Orientado a Objetos [5] para definir los componentes que
conforman los subsistemas, dichos objetos estarán interrelacionados mediante
interfaces bien definidas y acoplados lo menos posible. En términos de
programación, los objetos son instancias de una clase que define sus atributos
(características) y métodos (lo que puede hacer).
6.2.2.2.1.1 Patrón de diseño arquitectónico Modelo – Vista – Controlador
Ya se habló sobre la utilización de un estilo orientado a objetos para este
desarrollo, ahora, se tratará brevemente el concepto de patrones de diseño. Un
patrón de diseño es una forma efectiva de implementar la arquitectura de un
sistema. Existen muchos patrones que han demostrado su efectividad en la
implementación de sistemas, pero en este caso se tratará específicamente el
patrón Modelo – Vista – Controlador (MVC).
36
El patrón MVC es posiblemente el más difundido entre todos los patrones de
diseño, esta popularidad se debe quizá a su facilidad de comprensión para los
programadores novatos y a la vez a su buena adaptación a gran variedad de
sistemas de software. Los componentes de este patrón son:
Modelo: se refiere a los datos con que el sistema funciona.
Vista: es la parte visual de cara al usuario, los datos del modelo se
representan en esta vista.
Controlador: es el encargado de responder a los eventos generados por el
usuario. Recibe entradas del usuario, solicita información al modelo (y a la
vista) para procesarla y presentarla al usuario a través de la vista.
Esta separación entre la parte visual, la interacción del sistema con el usuario y el
modelo de datos, hacen más fácil la comprensión y mantenimiento del sistema, así
como la actualización de la interfaz gráfica, ya que estos cambios no afectan a la
parte del modelo ni a los procedimientos del controlador.
El proceso de comunicación entre el modelo, la vista y el controlador podría
describirse de la siguiente manera:
i. El usuario realiza acciones sobre la interfaz gráfica de la aplicación (vista).
ii. El controlador recibe la orden generada por el usuario y la procesa,
realizando operaciones y/o consultas a la base datos (por medio del
modelo). Luego retorna el resultado a la vista.
iii. Se despliega el resultado en la vista. El proceso se repite siempre que el
usuario ejecute una acción sobre la aplicación.
EL siguiente diagrama muestra la interacción entre los componentes del patrón
MVC:
37
Figura 4. Patrón de Diseño Modelo – Vista – Controlador
A nivel de programación este patrón podría implementarse creando un paquete de
componentes para el modelo donde estén contenidas todas sus clases, otro
paquete para la vista donde se agrupen todos los componentes de la interfaz
gráfica de usuario y por último un paquete para el controlador donde se
almacenen todas las clases encargadas de controlar los eventos del sistema.
6.2.2.2.2 Diseño de Interfaces
Como se mencionó anteriormente, las interfaces son ese medio de comunicación
entre los componentes del sistema y con el usuario. De este modo podríamos
definirlas por separado para evitar confusiones conceptuales entre interfaces del
sistema e interfaces de usuario.
6.2.2.2.2.1 Interfaces de Usuario
Retomando el concepto anterior, una interfaz de usuario es la forma de
comunicación entre el software y los usuarios que lo utilizan. Con esto se podría
pensar solo en la parte gráfica que despliega un monitor, que es la forma más
tradicional de llevar a los usuarios a familiarizarse con las aplicaciones, pero
también existen otras formas de interacción las cuales también se consideran
Controlador
Modelo Vista
38
interfaces de usuario, tal es el caso de salidas a impresoras, obtención de
información mediante cámaras, sensores, lectores ópticos, etc.
En lo que compete a este proyecto, inicialmente solo se necesitará diseñar
interfaces gráficas de usuario (GUI por sus siglas en ingles) e interfaces para el
uso de la cámara web del usuario, pero este último se tratará más adelante en otra
instancia del proyecto.
Las GUIs hacen posible que sea más fácil para el usuario aprender a utilizar los
servicios de un software, no siempre existieron y no siempre fue tan fácil utilizar
programas de computadora, es por eso que su importancia radica en lo fácil que le
resulte al usuario interactuar con una aplicación. Se pueden describir ciertas
características transversales a cualquier diseño de interfaz gráfica de usuario [5]:
Ventanas: comprende todo los tipos de contenedores que pueden
manejarse independientemente, esto es, abrirlas, redimensionarlas,
cerrarlas. Por lo general son el área de trabajo de la aplicación, así como
para desplegar información emergente.
Iconos: los iconos deben ser consistentes los unos con los otros, deben
guiar al usuario y estar relacionados gráficamente con la función que
cumplen. En el caso de los iconos que ejecutan aplicaciones, se considera
relevante (desde el punto de vista del diseño artístico) la impresión que este
genera al usuario, al ser el primer contacto que se tiene con el software es
importante que el usuario se sienta atraído a usarlo.
Menús: los menús proporcionan el listado de servicios y acciones que
pueden realizarse en la aplicación. Los menús pueden estar codificados en
formas de barras horizontales y/o verticales, desplegarse mediante clic
derecho del ratón o eventos como presionar una tecla o mover el ratón por
encima de un objeto especifico.
39
Apuntadores: los apuntadores son importantes para indicar al usuario
donde se tiene el foco actual de acción sobre la aplicación. Los
apuntadores pueden ser el puntero del mouse, el cursor de escritura y el
efecto de resalto sobre un objeto que se da al posicionarse sobre él con el
ratón o con el teclado, para escribir sobre un cuadro de texto por ejemplo.
Gráficos: todos los elementos gráficos en 2D o 3D que contenga la
aplicación, como los fondos de ventanas, gráficos de despliegue de
información, efectos de transición entre ventanas, entre otros. En el caso
del desarrollo de videojuegos es este el punto más relevante por obvias
razones.
Las interfaces gráficas de usuario deben tener consistencia en el diseño, esto
quiere decir que los colores, logos, tamaños y tipos de letra, botones y demás
elementos gráficos guarden cierto patrón o estilo entre sí. Esto da al usuario una
experiencia más cómoda y reduce el riesgo de confusión ante el manejo del
software.
Ahora, la parte de navegación a través de las opciones del sistema también es
muy importante, no es lo mismo llevar al usuario a un servicio determinado en 10
que en 2 clics de ratón. El software está hecho para facilitarles las cosas a sus
usuarios y esto implica rapidez en la usabilidad.
De la mano de la rapidez que el usuario busca, viene también el rendimiento con
que el sistema recibe, procesa y devuelve información. En muchos casos aunque
internamente el sistema procese con un rendimiento alto, a la hora de que esta
información se represente en el medio visual (como un monitor) se generan
retrasos considerables que precisamente son generados por una interfaz de
usuario “pesada” gráficamente. Este tema es de mucho cuidado principalmente en
aplicaciones de entornos Web.
40
El usuario debe sentir que tiene el control sobre la aplicación en todo momento y
esto se consigue con una interfaz gráfica bien diseñada.
6.2.2.2.2.2 Interfaces del Sistema
Las interfaces del sistema ocurren en un entorno interno del software, trasparente
para el usuario final. Se refieren a como se comunican los componentes, módulos
y subsistemas que conforman un software. Las interfaces del sistema
proporcionan información importante acerca de la comunicación y colaboración
entre componentes [8]. A nivel de programación y en orientación a objetos, las
interfaces del sistema pueden ser implementadas a través de los atributos y
métodos públicos que exponen las clases y por ende pueden ser referenciadas
desde otros componentes.
6.2.2.2.3 Diseño del Modelo de Datos
El manejo de datos y gestión eficiente de la información es en si el objetivo central
de muchos sistemas de computación. Diseñar entonces un adecuado modelo de
datos es una tarea que requiere conocer muy bien los objetivos y dirección del
software.
Las bases de datos pueden estar ya construidas independientemente del software
que se esté desarrollando y por lo tanto este debe acoplarse a dicha base de
datos. Otro caso puede ser que la base de datos se construya para el sistema en
desarrollo, lo cual brindará mayor flexibilidad al equipo de diseño.
En el caso particular de este proyecto, la base de datos será construida para el
sistema en cuestión. Generalmente para los sistemas de bases de datos
relacionales se emplean los diagramas de entidad – relación para describir su
estructura; este diagrama junto con el diccionario de datos definirá el modelo de
base de datos del sistema.
41
El diccionario de datos no es más que un documento detallado de cada atributo,
entidad y relación de la base de datos. En el diccionario de datos se especifican
características como el tipo y longitud de los datos almacenados, la función de
cada entidad y atributo, entre otros.
El modelo de datos también puede abarcar las estructuras de datos empleadas en
memoria durante la ejecución, como pueden ser los arreglos, listas ligadas y
árboles.
6.2.2.2.4 Diseño de Algoritmos
En el proceso de diseño se encuentra contemplada la descripción de la lógica
procedimental del software. Para esto no se utiliza un lenguaje de programación
específico, más bien se emplea una especie de pseudocódigo en lenguaje natural
que pueda ser leído y comprendido por todo programador de cualquier plataforma
de desarrollo. El objetivo con este diseño es proveer a los programadores de una
guía de cómo deben comportarse los algoritmos programados y que resultado se
espera de ellos.
En un proyecto grande la cantidad de líneas de código pueden contarse por miles
y sería muy tedioso y costoso que el diseñador especifique cada línea mediante
pseudocódigo antes de ser codificada; lo que se hace es simplemente definir en
palabras generales lo que un bloque de código debe hacer, el cómo lo debe hacer
es tarea del programador que implementa el algoritmo en algún lenguaje (Java,
C++, Python, etc).
Esto es muy útil para los equipos de desarrollo grandes donde es importante que
los programadores entiendan el código creado por los demás y así cualquiera
pueda continuar con el proceso que alguien más inició. Este diseño de algoritmos
es elaborado a partir de los casos de uso del sistema y teniendo claros los
42
diagramas de clases que es donde se describen las interrelaciones entre
componentes del sistema.
6.2.2.3 Implementación del Software
El proceso de implementación del software es uno de los que mayor tiempo de
vida consume al proyecto en general, ya que es la etapa donde se lleva el modelo
de requerimientos a código ejecutable. Es quizá también la etapa más esperada
por muchos, puesto que es la fase que demuestra si todo el análisis previo del
diseño es acertado y de esa manera el sistema va tomando forma. La
implementación del software requiere del trabajo conjunto y cohesivo de todo el
equipo del proyecto. Por un lado los programadores son los más atareados en
esta etapa y por el otro los analistas deben ir retroalimentándose de los
programadores que pueden generar observaciones importantes en el diseño y
arquitectura del sistema.
En esta fase se deben usar guías y estándares de programación existentes en las
organizaciones, si no se tienen, el equipo de desarrollo debe implementar sus
propias guías donde se especifiquen parámetros importantes como el formato
para nombres de variables, estilos de programación, métodos de documentación
[9] y demás puntos que todo el equipo deba conocer para generar código
ordenado, eficiente y comprensible por los demás del equipo.
El lenguaje de programación y las herramientas que se utilizarán para codificar y
construir el software son una decisión importante, debe tomarse teniendo en
cuenta factores como:
Sistema operativo que alojará la aplicación: no todos los lenguajes de
programación soportan múltiples plataformas, de acuerdo al sistema
operativo anfitrión del software deben analizarse las posibilidades de
lenguajes y comparar sus ventajas y desventajas de implementación.
43
Costo de licencias y/o patentes: aunque obviamente estos temas debieron
ser abordados en la etapa de planeación del proyecto, el costo de licencias
es un punto que debe determinarse a la hora de escoger un lenguaje sobre
otro. Algunos lenguajes son de libre utilización como PHP o Python, otros
requieren el pago de licencias para desarrollar sobre ellos como la suite de
.NET, y ambos ofrecen características que pueden ser aprovechadas
dependiendo al tipo de proyecto.
Requerimientos de la Base de Datos: es importante planificar el
crecimiento, concurrencia y demás factores que influyan en la decisión de
cual motor de base de datos utilizar.
Ambiente operativo de ejecución de la aplicación: no es lo mismo diseñar y
construir una aplicación stand alone (de escritorio), una aplicación cliente –
servidor o una aplicación de entorno Web. El rendimiento por ejemplo
puede ser más fácil de gestionar en una aplicación stand alone que en una
cliente – servidor o Web, ya que solo dependerá de los recursos asignados
al sistema anfitrión. En cambio una aplicación cliente – servidor introduce
otros factores como el rendimiento y estabilidad de la red, y ni hablar de
una aplicación Web donde el rendimiento depende del navegador que
utilicen los usuarios, el canal de conexión a Internet, la seguridad del medio,
el software de terceros como plugins, entre otros.
Sistema es estructurado u orientado a objetos: al definirse esto en la etapa
de diseño ya se van evidenciando los lenguajes que pueden ser más
eficientes dado un caso o el otro.
Utilización de patrones de diseño: con la aceptación que han tenido los
patrones de diseño (como el MVC), se han creado muchos proyectos de
herramientas que faciliten el uso de estos patrones en la construcción de
software y de esta manera incrementen la productividad de los
44
desarrolladores. Un ejemplo de estas herramientas es Apache Struts para
MVC.
Utilización de tecnologías particulares para un ambiente operativo
específico: por ejemplo JavaScript o AJAX, las cuales enriquecen la
experiencia del usuario en aplicaciones Web, son tecnologías ampliamente
desarrolladas por herramientas como JQuery o ZK Framework para Ajax,
solo por mencionar algunas dentro de las decenas de potentes opciones
que hay en el mercado. Las posibilidades que brindan estas herramientas
son excepcionales y generalmente mejores que las que podría desarrollar
un programador desde cero.
Dependiendo de la naturaleza y finalidad del software, podrían emerger muchos
otros factores de decisión que inclinen la balanza hacia un lenguaje de
programación o tecnología específica. Esta es una tarea importante que debe
definirse con anticipación a la fase de implementación.
6.2.2.4 Validación del Software
Validar el software es una tarea crítica que debe realizarse minuciosamente, ya
que esta etapa se encarga de revisar el producto antes de generar un incremento
o evolución en el proceso o al final del proyecto en revisar el producto antes de ser
entregado al cliente o liberado al público.
También se le conoce como etapa de pruebas o testing, es tan importante esta
fase, que incluso se han creado empresas dedicadas a ofrecer solo este servicio y
en parte también ha ayudado al surgimiento de estas empresas, el concepto que
se tiene en el mercado laboral de la ingeniería del software de que los analistas de
pruebas no deben tener vinculo o relación alguno con los participantes de las
fases anteriores del proyecto. Muchos proyectos contratan esta etapa de pruebas
con terceros, pero también existe aún la tradición de realizar las pruebas al interior
45
de los equipos del proyecto. Cualquiera que sea el caso, la etapa de validación del
software generalmente contiene estos tipos de pruebas:
Pruebas de unidad: verifican cada uno de los más pequeños componentes
del software, cada uno por separado.
Pruebas de integración: verifican el comportamiento de todos los
componentes o módulos trabajando juntos como un software completo.
Pruebas de regresión: al incluir una nueva funcionalidad o componente el
sistema cambia, la prueba de regresión verifica que el sistema aun cumpla
su funcionalidad [9].
Pruebas funcionales o de casos de uso: se toman los casos de uso del
sistema para verificar si el sistema en verdad hace lo que los casos de uso
indican que debería hacer.
Pruebas de humo: también llamadas smoke test, son pruebas rápidas sin
mucho nivel de detalle y profundidad, generalmente son las pruebas que
hacen los programadores durante la codificación para comprobar que el
código hace lo que se espera.
Pruebas de rendimiento: tienen el propósito de medir la capacidad y
resistencia del sistema ante diferentes cargas de procesamiento.
Pruebas de recuperación: verifican la capacidad del sistema de reponerse a
fallos graves en tiempo de ejecución y volver a un estado de operación
adecuada, esto incluye la no pérdida de datos durante esta recuperación.
Pruebas de seguridad: verifican el nivel de seguridad en la información, la
ocultación de código, métodos de encriptación y demás factores de
seguridad.
46
Prueba de aceptación: es la prueba que realiza el cliente mediante el uso
del sistema con datos reales. Esta prueba puede llevar semanas o incluso
meses y es la que define si el software cumple con los requerimientos del
cliente o deben hacerse correcciones.
Existen también las pruebas de caja blanca las cuales son más especializadas y
enfocadas a verificar el código fuente del software, dicho de otra manera, se
preocupan por verificar como el software ejecuta sus procesos. Por otro lado,
están las pruebas de caja negra, las cuales se enfocan en el comportamiento y
funciones del sistema [8] , pero sin importar como lo hace.
Es importante anotar que el objetivo de los analistas de pruebas es encontrar
errores y fallos en el software. Si un software saliera impecable de errores durante
su primera entrada a pruebas, no se pensaría en que el producto está muy bien
desarrollado, sino en que las pruebas estuvieron mal planteadas y los analistas de
prueba hicieron mal su trabajo.
Para diseñar las pruebas, se debe tener consideración de los recursos disponibles
para diseñarlas y aplicarlas, estos recursos pueden ser por ejemplo si los datos
serán los reales o si la plataforma donde se correrán las pruebas cumple los
requisitos mínimos. Las pruebas deben estar siempre enfocadas a encontrar el
máximo número de errores, por lo tanto deben ser diseñadas y aplicadas de
manera que la probabilidad de hallarlos se maximice.
Al encontrar errores, estos deben analizarse y documentarse detalladamente para
luego enviar el componente o el software completo a un proceso de depuración de
nuevo con los encargados de la programación. El proceso se reinicia una vez más
con la entrada del software depurado a las instancias de prueba y continúa hasta
que finalmente pueda entregarse una versión confiable del sistema.
47
6.2.2.5 Evolución del Software
La evolución del software no necesariamente entra en el ciclo de vida de un
proyecto contratado, esto se debe en primer lugar porque los recursos de las
organizaciones para costear un proyecto son limitados. La idea de evolucionar el
software involucra dinero de por medio, así que en primera instancia solo se
piensa en construir un software estable que funcione bien hasta que la
organización requiera algún ajuste en el sistema. Estos ajustes serán entonces
resueltos mediante otro contrato de desarrollo a menor escala.
Otro enfoque sería el de una organización que libere un software enfocado a cierto
modelo de negocio, es de esperarse que en términos ideales este software genere
ganancias lo cual obligue a la organización a mantener actualizado y evolucionar
dicho sistema, que en si es su núcleo de negocio. Aunque hay programas de
software que constantemente están en evolución sin un aparente objetivo lucrativo
(como es el caso del software libre) y que son mantenidos por comunidades
abiertas de desarrolladores, es inevitable pensar que en el fondo todo se resume
de nuevo a algún tipo de ingreso económico que sostenga el proyecto.
Para cualquiera de los casos, la evolución de cualquier sistema de software
generalmente consiste en:
El análisis de lo que se tiene y se espera mejorar (sistema actual y sistema
futuro).
La planificación del “mini proyecto” de evolución (recursos necesarios,
costos, riesgos, personal, tiempo de entrega).
El análisis del o los requerimientos considerados para la nueva versión del
sistema.
48
El diseño de la integración del nuevo componente (servicio o función) -si
existe- con el sistema actual. La idea es no alterar bruscamente la
arquitectura ya implementada.
La programación de los nuevos componentes o cambios a los componentes
actuales.
Las pruebas pertinentes para la unidad o módulo respectivo y su
correspondiente integración con el sistema completo.
Como se puede observar, la evolución del software es considerar a una menor
escala todas las actividades de ingeniería de software que se llevan a cabo para
un sistema completo. La idea de llevar también una metodología completa para
este proceso consiste principalmente en no degradar a través de malas prácticas,
el software ya fabricado mediante un previo proceso estructurado que buscó
precisamente obtener un software de buena calidad.
6.2.3 El Lenguaje Unificado de Modelado (UML)
UML es un lenguaje visual considerado como lenguaje formal de especificación,
que es ampliamente utilizado para desarrollar sistemas de software [10]. UML
consiste en una serie de elementos gráficos que representan algo dentro del
sistema, estos elementos se relacionan a través de conectores determinados que
significan algo relevante, estas relaciones comúnmente están etiquetadas con
palabras en lenguaje natural (inglés como estándar) que describen de dicha
relación. Los elementos relacionados forman diagramas completos que
representan la arquitectura, comportamiento, funciones y todo lo demás
concerniente al producto de software y a su entorno (dominio) de negocio. UML
proporciona tres categorías dentro de su estructura básica [6]:
Elementos: esta categoría se compone de cuatro tipos, los cuales son:
49
o Estructurales: existen siete tipos principales:
Casos de uso
Clases
Clases activas
Interfaces
Componentes
Colaboraciones
Nodos
o De comportamiento: existen dos tipos de estos elementos:
Interacciones
Máquinas de estados
o De agrupación: existen cuatro tipos de agrupaciones:
Paquetes
Modelos
Subsistemas
Marcos de Trabajo
o De anotación: solo hay un tipo principal de elementos de anotación:
Notas
Relaciones: dentro de esta categoría se encuentran tres tipos básicos:
o De dependencia
o De asociación
o De generalización
Diagramas: en esta categoría se encuentran agrupados nueve tipos:
o Casos de uso
o Clases
50
o Objetos
o Secuencia
o Colaboración
o Estado
o Actividad
o Componentes
o Despliegue
51
7 DISEÑO METODÓLOGICO PRELIMINAR
Ahora que se ha conceptualizado un poco a través del marco teórico, se puede
plantear claramente la metodología de trabajo que se utilizará durante todo el
desarrollo de este proyecto. Se describirá claramente la metodología de ingeniería
del software a seguir para elaborar la documentación del sistema y manejar las
actividades de programación, considerando en todo momento los posibles ajustes
en requerimientos y arquitectura del sistema.
Es importante aclarar que la metodología aquí definida está basada en las
siguientes premisas particulares del proyecto:
Es un desarrollo de software personal, lo que significa que las tareas de
requisitos, análisis, diseño, codificación, pruebas y evolución, serán
llevadas a cabo por una sola persona. Esto también indica que será una
característica del proyecto, el que a menudo se generen nuevas ideas que
posiblemente impliquen modificaciones menores a los modelos inicialmente
planteados. Esto no significa que deba aceptarse y permitirse el desorden y
la informalidad en los procesos, al contrario, esto generará un mayor grado
de documentación de cambios y organización del trabajo.
Los requerimientos del sistema no obedecerán a requisitos de terceros (al
menos no en la primera versión del software), todas las funciones, servicios
y características particulares de la aplicación estarán planteadas por su
creador bajo sus criterios actuales, los cuales son influenciados por su
experiencia como usuario en el uso de tecnologías similares y sus
expectativas de aprovechamiento y aplicación en nuevos campos.
Al finalizar el proyecto, la idea es que la versión inicial pueda ser sometida a
la evaluación de varios usuarios (con conocimientos técnicos y sin ellos),
que den su opinión y retroalimenten al desarrollador, esto con el fin de
52
analizar la posible liberación, sostenimiento y evolución de la aplicación.
Esto implica la posibilidad de un modelo de negocio que para alcances del
presente proyecto no será analizado.
Habiendo aclarado estos tres aspectos, se podrá entender por qué la metodología
del proyecto está planeada de esta manera. Todas las actividades del proyecto
irán de lo general a lo particular. Esto quiere decir que primero se buscará
comprender un aspecto global del sistema para luego ir adentrándose en los
aspectos más específicos.
La metodología utilizada será mixta, básicamente se tomarán los aspectos básicos
del Proceso Unificado a través de un enfoque evolutivo, esto es:
Dirigir el proyecto de desarrollo por casos de uso. Todos los requerimientos
funcionales serán representados por casos de uso, además las pruebas
funcionales estarán basados en ellos.
Centrar todo en la arquitectura. Todas las decisiones que se tomen no irán
en contra de la arquitectura propuesta. Esta se podrá actualizar pero
conservando siempre su esencia inicial.
Flujo de trabajo comprendido por actividades de requisitos, análisis, diseño,
implementación y pruebas. Los requisitos y análisis serán abarcados como
una única etapa, puesto que el desarrollador es quién estipula los
requerimientos.
El sistema empezará básicamente como un prototipo exploratorio a partir
de los requerimientos claves más generales, el cual irá evolucionando
mediante la inclusión de nuevos requerimientos.
Prototipos rápidos serán diseñados cuando sea necesario comprender
requerimientos y/o funcionalidades poco conocidas de la plataforma.
53
El sistema irá evolucionando a través de las iteraciones en las actividades.
Los requerimientos empezarán siendo muy generales en la primera
iteración y conforme se vayan implementando se irán descubriendo y
agregando requerimientos más específicos. Esto quiere decir que nuevos
casos de uso podrán aparecer en cada iteración, lo ideal es que se integren
a la arquitectura sin modificarla; los demás diagramas UML se actualizarán
si es necesario cuando un nuevo caso de uso es propuesto, se conservarán
las versiones previas cada documento y se llevará el control en un historial
de cambios.
Cada vez que se programen nuevos requerimientos se realizarán las
validaciones respectivas.
Las interfaces gráficas de usuario podrán ser modificadas también si
nuevos requerimientos lo ameritan.
A continuación se presentan las actividades más representativas de cada etapa
del proyecto.
7.1 CON RELACIÓN A LOS REQUERIMIENTOS DEL SOFTWARE
La etapa inicial del proyecto comprenderá las actividades de recolección,
descripción, organización y análisis de requerimientos. Estos requerimientos serán
organizados teniendo en cuenta su grado de importancia, los requerimientos más
importantes serán aquellos que revelen funciones clave del sistema y que se
necesita para implementarlas. De manera detallada las tareas de esta fase se
desarrollaran de la siguiente manera:
Se definen los objetivos del sistema.
54
Se recogen y listan los requerimientos claves de la aplicación, se
categorizan los funcionales, no funcionales y de información. Los
requerimientos del dominio pueden estar implícitos en los anteriores.
Se analiza la criticidad de cada requerimiento para determinar la prioridad
en el desarrollo de cada uno.
Se construyen los casos de uso y sus diagramas para los requerimientos
funcionales.
Se realiza una matriz de rastreabilidad de objetivos – requisitos funcionales,
para ver qué casos de uso cumplen con cuales de los objetivos del sistema.
Toda la información anterior recolectada, analizada y modelada a través de
los casos de uso, se reúne en el Documento de Requerimientos del
Sistema (DRS), el cual será la guía y referencia principal para el resto del
proyecto.
7.2 CON RELACIÓN AL DISEÑO DEL SOFTWARE
Las primeras actividades de diseño se entrelazarán con las actividades de
requerimientos, como es el caso del diseño de la arquitectura. Esto con el fin de
retroalimentar una actividad con la otra y generar una arquitectura coherente con
los requerimientos del sistema y que permita su evolución. En concreto las tareas
detalladas del diseño serán:
Se inicia la creación de un modelo de la arquitectura mientras aun se está
trabajando en los requerimientos. Se descompone el sistema en
subsistemas.
Se diseña el modelo de base de datos inicial, el cual consistirá en la
elaboración del diagrama entidad - relación, los requerimientos de
55
información serán importantes para la especificación de las entidades y sus
atributos.
Se realizan bocetos (lo más sencillos posible) del diseño de las interfaces
gráficas de usuario también de manera conjunta con la etapa de
requerimientos, esto con el objetivo de ilustrar de mejor manera la
descripción de los casos de uso.
La arquitectura se describirá desde diferentes vistas, por ejemplo, una
visión de la arquitectura desde los requerimientos no funcionales, desde los
requerimientos funcionales y de información, desde el patrón de diseño
arquitectónico y/o desde los componentes que conforman los subsistemas.
Para esto se utilizarán diagramas de componentes, paquetes y/o
despliegue de UML según convenga.
Se indican las interfaces entre los subsistemas y componentes del sistema
(aún sin detalle de que las componen).
Se realizan los diagramas de clases con base a los casos de uso y al
patrón de diseño arquitectónico utilizado. Se especifican en detalle las
interfaces, puesto que ya se tienen los atributos y métodos públicos que
expondrán las clases hacia otros componentes.
Teniendo la arquitectura y las clases definidas, se elaboran los diagramas
de secuencia del software.
Es importante mencionar que el diseño de la arquitectura también será incluido en
el Documento de Requerimientos del Sistema (DRS).
Solo se elaborarán los diagramas UML mencionados. Otros diagramas como los
de objetos, colaboración, estados y actividades aunque de gran importancia, no
serán tenidos en cuenta, dadas las dimensiones y tiempo del proyecto, así como
las consideraciones mencionadas al inicio de este capítulo.
56
7.3 CON RELACIÓN A LA IMPLEMENTACIÓN DEL SOFTWARE
La implementación del software comenzará una vez definidos los casos de uso
claves y los productos de la etapa de diseño. Las tareas que se desarrollarán en
esta fase son:
Implementación en la máquina de desarrollo de la plataforma que soportará
el sistema de acuerdo a los requerimientos no funcionales (servidor Web,
sistema de gestión de bases de datos, bibliotecas, compiladores, entornos
de desarrollo, frameworks, máquinas virtuales, etc).
Construcción de la base de datos en el Sistema de Gestión de Bases de
Datos seleccionado.
Creación de las clases e interfaces de acuerdo a la arquitectura.
Las interfaces gráficas de usuario serán construidas siguiendo los
bosquejos realizados en la fase de diseño. No se considerará inicialmente
desarrollar la estética visual del programa (solo los componentes sin
formato) y se dejará para más adelante cuando la aplicación comience a
cobrar una funcionalidad más completa.
Codificación de algoritmos para los diferentes métodos de las clases con
base a los casos de uso.
Ante los obstáculos de programación que puedan presentarse, como por
ejemplo funcionalidades poco conocidas, se podrán realizar prototipos
rápidos de tipo exploratorio. El código empleado en estos prototipos se
podrá utilizar para el sistema y de esta manera no sufrir retrasos en el
tiempo de desarrollo.
57
7.4 CON RELACIÓN A LA VALIDACIÓN DEL SOFTWARE
La validación del software se hará de manera continua y concurrente desde que
inicie la etapa de implementación. Así, estas dos etapas serán realizadas a la par
y luego de que termine la fase de programación se realizaran algunas pruebas
más de validación. En concreto, las actividades de validación a realizar serán:
Pruebas de humo (smoke test) pequeñas y constantes durante la
programación de cada componente del sistema. Estas pruebas no serán
documentadas de ninguna manera ya que no sería para nada práctico,
puesto que se realizan prácticamente todo el tiempo.
Al integrar los componentes se realizarán las pruebas de integración
respectivas. No se documentará el proceso de la prueba, solo su
descripción y resultado. Si se detectan fallas se describirán detalladamente
para ser corregidas.
Pruebas funcionales con base a los casos de uso del sistema. Estas
pruebas son más detalladas ya que se describen paso a paso e indican el
resultado esperado. Si se documentarán y se realizarán al completar el
sistema durante la etapa final del proyecto para probar el software como un
todo. Si se detectan fallas se describirán detalladamente para ser
corregidas.
7.5 CON RELACIÓN A LA EVOLUCIÓN DEL SOFTWARE
Aunque esta etapa no está contemplada durante el tiempo de vida del presente
proyecto, se menciona debido a la posibilidad de seguir dando soporte al software
si este fuera liberado al público general. En este caso la evolución del software
consistiría en retomar de nuevo las mismas actividades descritas en las fases
anteriores para generar un nuevo producto del sistema.
58
8 CRONOGRAMA
59
9 APLICACIÓN WEB PARA EL DESARROLLO Y DIFUSIÓN DE REALIDAD
AUMENTADA UTILIZANDO TECNOLOGÍAS LIBRES
9.1 OBJETIVOS DEL SISTEMA
Básicamente, todo el software se puede englobar en tres objetivos clave:
a. Gestionar el perfil y entorno social del usuario.
b. Crear contenidos en Realidad Aumentada.
c. Gestionar las creaciones en Realidad Aumentada de los usuarios.
9.2 REQUERIMIENTOS DEL SISTEMA
En esta sección se exponen (en lenguaje natural) los requerimientos más
generales del sistema. Como se propuso en la metodología, conforme avance el
desarrollo de estos requisitos, se descubrirán e incluirán nuevos requerimientos
que añadan funcionalidad y robustez al sistema. Para una información más
detallada consúltese el Documento de Requisitos del Sistema formal en la sección
de Anexos al final de este documento.
9.2.1 Requerimientos Funcionales
A continuación se presenta una primera visión de los requerimientos funcionales
generales del software:
a. El sistema deberá permitir el registro de nuevos usuarios.
b. La plataforma de creación de Realidad Aumentada permitirá importar
contenidos desde otras fuentes y a su vez ofrecerá contenido prediseñado.
60
c. Se permitirá el uso de la aplicación de Realidad Aumentada sin registro
previo por parte de los usuarios. De esta manera el usuario podrá utilizar
completamente la aplicación pero sin posibilidades de compartir la creación
y sin las funcionalidades de red social.
d. Para ingresar a todas las funcionalidades del sistema el usuario deberá
autenticarse con su e-mail y contraseña.
e. El usuario podrá compartir sus creaciones a sus contactos de correo
electrónico, redes sociales más importantes o embeber el contenido en
sitios web.
f. El software debe permitir etiquetar las creaciones para crear categorías de
búsqueda.
g. Los usuarios podrán hacer visibles o no sus creaciones ante las búsquedas
públicas o implantar directivas de seguridad personalizadas sobre sus
creaciones.
h. El usuario registrado tendrá un espacio o perfil personalizable que podrá
utilizar para administrar sus creaciones y relacionarse con otros usuarios
del sistema.
i. El usuario podrá tener galerías de creaciones propias o de otros usuarios,
según los niveles de seguridad configurados por ellos.
j. El mecanismo de agregar contactos o amigos estará disponible en el
sistema con la filosofía de compartir las creaciones y no de competir con
redes sociales ya posicionadas para conocer o contactar personas.
k. Cada usuario dispondrá de un buzón de mensajes donde recibirá
notificaciones del sistema o de otros usuarios.
61
l. El usuario podrá comentar creaciones de otros usuarios según los niveles
personalizados de seguridad sobre ellas.
9.2.2 Requerimientos No Funcionales
Los siguientes son los requerimientos no funcionales que definen las bases de
como deberá funcionar el sistema:
a. El sistema debe funcionar en un entorno Web, por lo cual se requiere de un
servidor Web para alojar la aplicación y una conexión a Internet rápida para
el acceso de usuarios.
b. La plataforma de creación de Realidad Aumentada debe ser fácil e intuitiva
para cualquier usuario con conocimientos básicos en el uso de servicios
Web.
c. Se requiere un motor de base de datos para almacenar la información de
usuarios, sus creaciones y formas de compartirlas.
d. El sistema debe soportar una alta concurrencia e incremento de usuarios.
e. El sistema debe estar en línea y disponible todo el tiempo.
f. La aplicación debe ser rápida y directa al interactuar con el usuario.
g. El sistema deberá estar compuesto en su totalidad de herramientas open
source y libres.
62
9.2.3 Requerimientos de Información
Los requerimientos de información que se listan a continuación brindarán una
visión general de que datos e información serán almacenados y manipulados por
la aplicación. Estos son:
a. El sistema debe almacenar la información de perfil de cada usuario.
b. El sistema debe almacenar las creaciones de Realidad Aumentada de los
usuarios.
c. El sistema debe almacenar las políticas de seguridad que los usuarios
configuren sobre sus creaciones.
d. El sistema debe almacenar las relaciones de contacto entre los diferentes
usuarios del sistema, así como los mensajes que estos intercambien dentro
de la plataforma.
e. El sistema debe almacenar los comentarios que los usuarios realicen sobre
los contenidos de Realidad Aumentada, así como las votaciones que estas
reciban y cuando sean marcadas como favoritas por los usuarios.
9.3 ANÁLISIS Y DISEÑO DEL SISTEMA
A continuación se presentan los artefactos considerados necesarios para suplir la
etapa de análisis y diseño del sistema durante esta primera etapa de la evolución
del software. Dichos artefactos consisten en los diagramas de clases, secuencias,
arquitectura, modelo de datos y diseño de interfaces gráficas. Además del
documento de requisitos del sistema (DRS) que incluye el diagrama de casos de
uso y su correspondiente descripción.
63
9.3.1 Documento de Requisitos del Sistema
9.3.1.1 Participantes en el Proyecto
Participante Manuel Alejandro Lopera Ospina
Organización Universidad de San Buenaventura Medellín
Rol Desarrollador
Es desarrollador Sí
Es cliente No
Es usuario Sí
Participante Wilder Perdomo Charry, MSc. Gestión Tecnológica
Organización Universidad de San Buenaventura Medellín
Rol Asesor
Es desarrollador No
Es cliente Sí
Es usuario Sí
9.3.1.2 Objetivos del Sistema
OBJ-0001 Gestionar perfil y entorno social del usuario
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Descripción El sistema deberá gestionar de manera eficiente toda la información de perfil del usuario, así como la forma en que interactúa con otros usuarios y demás elementos de la aplicación.
Subobjetivos Ninguno
Importancia importante
Estabilidad baja
64
OBJ-0002 Crear contenido de Realidad Aumentada
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Descripción El sistema deberá permitir la creación de contenido de Realidad Aumentada por parte de los usuarios de la aplicación.
Subobjetivos Ninguno
Importancia Vital
Estabilidad Alta
OBJ-0003 Gestionar las creaciones de Realidad Aumentada de los usuarios.
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Descripción El sistema deberá permitir la gestión por parte de los usuarios de sus propias creaciones de Realidad Aumentada.
Subobjetivos Ninguno
Importancia Vital
Estabilidad Media
65
9.3.1.3 Diagrama de Casos de Uso
Figura 5. Diagrama de Casos de Uso del Sistema
9.3.1.4 Definición de Actores
ACT-0001 Usuario
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Descripción Este actor representa a un usuario común del sistema que accede a la aplicación a través de su navegador Web desde cualquier computadora conectada a Internet.
66
9.3.1.5 Descripción de Casos de Uso
UC-0001 Ver Home General
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario [OBJ-0003] Gestionar las creaciones de Realidad
Aumentada de los usuarios. [OBJ-0002] Crear contenido de Realidad Aumentada
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario digita la dirección URL de la página Web del sistema y presiona Enter o el botón Ir del navegador.
Precondición Haber digitado la URL de la página Web en el navegador de Internet.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) digita la URL de la página Web en su navegador y presiona Enter o el botón Ir.
2 El sistema recibe la petición y envía al cliente la página del home solicitada. (Este paso depende de la velocidad de conexión a Internet del usuario y de donde esté ubicado el servidor del sistema).
3 El sistema muestra la página del home de bienvenida (con los formularios de inicio de sesión y registro y una breve descripción de la aplicación) y queda preparado para recibir instrucciones del usuario.
Postcondición El usuario verá la pantalla del home general de bienvenida de la página Web.
Excepciones Paso Acción
2 Si se presenta una caída de conexión entre el servidor y el cliente, el actor Usuario (ACT-0001) puede reintentar el paso 1, a continuación este caso de uso continúa
Importancia vital
Estabilidad alta
67
UC-0003 Registrarse
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario [OBJ-0002] Crear contenido de Realidad Aumentada
[OBJ-0003] Gestionar las creaciones de Realidad Aumentada de los usuarios.
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desea registrarse como miembro del sitio Web.
Precondición Estar posicionado en el home general.
Secuencia normal Paso Acción
1 El actor Usuario (ACT-0001) diligencia el formulario de registro que está ubicado en la parte lateral derecha del home principal y presiona el botón Registrarse. El formulario cuenta con los campos: nombre de usuario, email, verificar email, contraseña, verificar contraseña y un botón Registrarse.
2 El sistema valida los datos ingresados por el usuario para verificar que cumplan el formato requerido por los campos de la base de datos.
3 El sistema almacena los datos del nuevo usuario en la base de datos y redirecciona al usuario al interior de la aplicación (espacio exclusivo para miembros registrados) ubicandolo en la página de inicio donde se muestra la actividad pública reciente de otros usuarios.
Postcondición El usuario queda registrado en la base de datos de usuarios.
Excepciones Paso Acción
2 Si uno o varios datos tienen un formato inválido , el sistema despliega un mensaje de error y resalta el campo o campos incorrectos para que el usuario los corrija, a continuación este caso de uso continúa
Importancia Vital
Estabilidad Alta
68
UC-0004 Iniciar Sesión
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario [OBJ-0003] Gestionar las creaciones de Realidad
Aumentada de los usuarios. [OBJ-0002] Crear contenido de Realidad Aumentada
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee iniciar sesión en el sistema.
Precondición Estar registrado en la base de datos de usuarios y haber accedido al home general del sistema.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) ingresa su correo electrónico (o nombre de usuario) y contraseña en el cuadro Iniciar Sesión ubicado en la parte lateral derecha del home principal del sitio y presiona el botón Entrar.
2 El sistema consulta la base de datos de usuarios para verificar si el correo electrónico (o nombre de usuario) y contraseña existen y son correctos.
3 Se realiza el caso de uso Ver Home del Perfil (UC-0005)
Postcondición El usuario podrá manipular todas las opciones de su perfil, crear contenido y gestionarlo.
Excepciones Paso Acción
2 Si los datos de inicio de sesión del usuario no son correctos, el sistema despliega un mensaje de error indicandole al usuario verificar su información y reescribirla volviendo asi al paso 1, a continuación este caso de uso continúa
Importancia vital
Estabilidad alta
69
UC-0005 Ver Home del Perfil
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando se da clic en la opción Inicio si el usuario ha iniciado sesión o durante la realización de los siguientes casos de uso: [UC-0004] Iniciar Sesión
Precondición Haber iniciado sesión.
Secuencia normal
Paso Acción
1 El sistema muestra en la parte lateral izquierda las opciones: Inicio, Contenidos, Contactos y Mensajes.
2 Se realiza el caso de uso Ver Actividad Reciente (UC-0006)
3 Si el actor presiona sobre su nombre de usuario ubicado en la parte superior derecha de la página, se realiza el caso de uso Editar Perfil (UC-0007)
4 Si el usuario da clic en el link Contenidos, se realiza el caso de uso Ver Centro de Contenidos (UC-0011)
5 Si el usuario da clic al link de Contactos, se realiza el caso de uso Ver Centro de Contactos (UC-0009)
6 Si el usuario da clic en el link Mensajes, se realiza el caso de uso Ver Centro de Mensajes (UC-0010)
Postcondición Mostrar la última actividad pública de los usuarios del sitio.
Excepciones Paso Acción
- -
Importancia importante
Estabilidad media
UC-0006 Ver Actividad Reciente
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario
70
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando de clic en la opción Inicio o durante la realización de los siguientes casos de uso: [UC-0005] Ver Home del Perfil
Precondición Haber accedido al home del perfil del usuario.
Secuencia normal Paso Acción
1 El sistema muestra en la parte central del home del perfil, una lista vertical con los ultimos contenidos públicos de otros usuarios.
Postcondición Desplegar los contenidos recientes de la comunidad de usuarios.
Excepciones Paso Acción
- -
Importancia quedaría bien
Estabilidad Baja
UC-0007 Editar Perfil
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee modificar su información personal o durante la realización de los siguientes casos de uso: [UC-0005] Ver Home del Perfil
Precondición Estar posicionado en el home del perfil.
Secuencia normal Paso Acción
1 El actor Usuario (ACT-0001) da clic sobre su nombre de usuario ubicado en la parte superior derecha de la página
2 El sistema muestra el formulario con la información personal que el usuario podrá modificar. Los campos estan diligenciados por defecto con la información que el usuario haya proporcionado anteriormente. Estos campos son: nombre de usuario, nombre completo, apellidos, email, fotografia. Todos son campos de texto excepto la
71
fotografia que es un campo que permite seleccionar una imágen desde el disco duro para subirla como foto de perfil.
3 El actor Usuario (ACT-0001) modifica los campos que considere y presiona el botón Actualizar
4 El sistema verifica los campos para comprobar que no hayan valores no permitidos.
5 El sistema envía la información a la base de datos y actualiza los campos respectivos.
6 El sistema permanece en el formulario por si el usuario requiere hacer otra modificación. ( Los campos del formulario de esta ventana se actualizan a sus nuevos valores.)
Postcondición La información del perfil del usuario será actualizada.
Excepciones Paso Acción
4 Si algún valor ingresado en un campo del formulario tiene caractéres no permitidos o no corresponde al formato esperado, el sistema no guarda la información, a continuación este caso de uso continúa
Importancia vital
Estabilidad media
UC-0009 Ver Centro de Contactos
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee acceder a su lista de contactos o durante la realización de los siguientes casos de uso: [UC-0005] Ver Home del Perfil
Precondición Estar posicionado en el home del perfil.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) da clic en el link Contactos.
2 El sistema muestra la bandeja de contactos del usuario ordenados alfabéticamente.
72
Postcondición El usuario verá la lista de contactos agregados a su comunidad.
Excepciones Paso Acción
- -
Importancia importante
Estabilidad media
UC-0010 Ver Centro de Mensajes
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario requiera abrir su centro de mensajes o durante la realización de los siguientes casos de uso: [UC-0005] Ver Home del Perfil
Precondición Estar posicionado en el home del perfil.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) da clic en el link Mensajes.
2 El sistema muestra el centro de mensajes ubicando al usuario por defecto en la bandeja de entrada, asi como las opciones de mensajes enviados y solicitudes de contacto pendientes.
Postcondición El usuario verá su bandeja de mensajes de entrada, mensajes enviados y su lista de solicitudes entrantes de contacto pendientes de aprobación.
Excepciones Paso Acción
- -
Importancia quedaría bien
Estabilidad Baja
73
UC-0011 Ver Centro de Contenidos
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0002] Crear contenido de Realidad Aumentada [OBJ-0003] Gestionar las creaciones de Realidad
Aumentada de los usuarios.
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario requiera ingresar a la sección de Contenidos de Realidad Aumentada o durante la realización de los siguientes casos de uso: [UC-0005] Ver Home del Perfil
Precondición Estar logueado en la aplicación.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) da clic en el link Contenidos.
2 Se realiza el caso de uso Ver Galerías (UC-0012)
Postcondición El usuario verá su lista de Galerías de contenidos.
Excepciones Paso Acción
- -
Importancia Vital
Estabilidad Media
UC-0012 Ver Galerías
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0003] Gestionar las creaciones de Realidad Aumentada de los usuarios.
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee ver su lista de galerías o durante la realización de los siguientes casos de uso: [UC-0011] Ver Centro de Contenidos
Precondición Ejecutar el caso de uso Ver Centro de Contenidos
Secuencia normal Paso Acción
74
1 Si el usuario da clic sobre una galería, se realiza el caso de uso Ver Contenidos (UC-0013)
2 Si el usuario selecciona alguna opción de la lista "Compartir con" que tiene cada Galería, se realiza el caso de uso Compartir (UC-0015)
3 Si el usuario da clic en la opción Eliminar de alguna Galería, se realiza el caso de uso Eliminar (UC-0016)
4 Si el usuario desea crear una Galería nueva, se realiza el caso de uso Crear Galería (UC-0014)
Postcondición Mostrar las galerias del usuario(contenedores de creaciones).
Excepciones Paso Acción
- -
Rendimiento Paso Tiempo máximo
- -
Frecuencia esperada
450 veces por día(s)
Importancia vital
Urgencia inmediatamente
Estabilidad alta
Comentarios Ninguno
UC-0013 Ver Contenidos
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0003] Gestionar las creaciones de Realidad Aumentada de los usuarios.
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee ver los contenidos de alguna Galería o durante la realización de los siguientes casos de uso: [UC-0012] Ver Galerías
Precondición Haber ingresado a un galería.
Secuencia normal
Paso Acción
1 Si el usuario selecciona alguna opción de la lista
75
"Compartir con" que tiene cada Contenido, se realiza el caso de uso Compartir (UC-0015)
2 Si el usuario da clic en la opción Eliminar de algún contenido, se realiza el caso de uso Eliminar (UC-0016)
3 Si el usuario desea crear un nuevo contenido, se realiza el caso de uso Subir Contenido (UC-0017)
Postcondición El usuario puede navegar entre todas sus creaciones dentro de la galería.
Excepciones Paso Acción
- -
Importancia vital
Estabilidad alta
UC-0014 Crear Galería
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0002] Crear contenido de Realidad Aumentada
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee crear una nueva galería o durante la realización de los siguientes casos de uso: [UC-0012] Ver Galerías
Precondición Haber ingresado a través del link Contenidos.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) diligencia el campo "Nombre para tu nueva galería" con el nombre con el que quiera identificar a la nueva Galería y da clic en el botón Crear Galería.
2 El sistema crea una nueva Galería vacia con el nombre especificado por el usuario.
Postcondición Una nueva galería será creada para poder almacenar contenidos.
Excepciones Paso Acción
- -
Importancia Importante
Estabilidad Media
76
UC-0015 Compartir
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0003] Gestionar las creaciones de Realidad Aumentada de los usuarios.
[OBJ-0001] Gestionar perfil y entorno social del usuario
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee compartir una creación o durante la realización de los siguientes casos de uso: [UC-0012] Ver Galerías,[UC-0013] Ver Contenidos
Precondición Haber ingresado a una galería.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) selecciona una de las 4 opciones de permisos de la lista desplegable "Compartir con" que posee cada elemento (galería o contenido), estas opciones son: Todos (por defecto), Contactos, Contactos de Contactos, Nadie (privado).
2 El sistema cambia en la base de datos el tipo de permiso para el elemento (galería o contenido).
3 El sistema muestra el elemento a los demás miembros de la aplicación de acuerdo con la opción seleccionada por el usuario.
Postcondición La creación debe ser visible de acuerdo con las restricciones de seguridad impuestas por el usuario.
Excepciones Paso Acción
- -
Importancia Importante
Estabilidad Media
UC-0016 Eliminar
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0003] Gestionar las creaciones de Realidad
77
Aumentada de los usuarios.
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee eliminar un elemento (galería o contenido) o durante la realización de los siguientes casos de uso: [UC-0012] Ver Galerías, [UC-0013] Ver Contenidos
Precondición Haber ingresado a través del link Contenidos.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) da clic en la opción Eliminar que posee cada elemento (galería o contenido).
2 El sistema muestra un mensaje donde se pregunta al usuario si esta seguro de eliminar el elemento.
3 El actor Usuario (ACT-0001) presiona el botón Aceptar.
4 El sistema borra el elemento de la base de datos y todo el contenido asociado (si se trata de una galería).
5 El sistema actualiza la lista en pantalla retirando el elemento borrado y permanece en la vista correspondiente (lista de galerías o lista de contenidos)
Postcondición El elemento será eliminado de la cuenta del usuario junto con todo su contenido asociado (en el caso de una Galería)
Excepciones Paso Acción
- -
Importancia importante
Estabilidad baja
UC-0017 Subir Contenido
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0002] Crear contenido de Realidad Aumentada
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desee crear un nuevo contenido dentro de la Galería donde se encuentra ubicado o durante la realización de los siguientes casos de uso: [UC-0013] Ver Contenidos
78
Precondición Haber ingresado a una Galería.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) diligencia el formulario que se encuentra en la parte superior de la lista de contenidos de la Galería en la cual se está posicionado y presiona el botón Subir. Este formulario tiene los campos: nombre, descripción del contenido y un campo que permite seleccionar del disco duro el archivo a cargar (video en formato .ogg o modelo 3d en formato .js, .json o .dae). El archivo debe estar comprimido en ZIP, si el modelo 3D tiene texturas deben estar ubicadas en el mismo directorio que el archivo del modelo.
2 El sistema valida que el tipo de archivo sea un ZIP y que no se dejen campos del formulario en blanco.
3 El sistema carga el contenido al servidor y guarda el registro en la base de datos. ( el tiempo de carga depende del peso del archivo y la velocidad de conexión a internet del usuario.)
4 El sistema actualiza la lista de contenidos y muestra el recien creado.
Postcondición Se almacenará un nuevo contenido dentro de la Galería para ser visualizado en Realidad Aumentada.
Excepciones Paso Acción
2 Si se encuentra algun campo del formulario en blanco, el sistema muestra un mensaje advirtiendo del error y permite al usuario reintentarlo, a continuación este caso de uso continúa
2 Si el archivo que se pretende subir no es un ZIP, el sistema muestra un mensaje advirtiendo el error y permite al usuario seleccionar un archivo correcto, a continuación este caso de uso continúa
Importancia vital
Estabilidad media
UC-0018 Ver Contenido en Realidad Aumentada
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
79
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0003] Gestionar las creaciones de Realidad Aumentada de los usuarios.
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desea visualizar un contenido en Realidad Aumentada.
Precondición Seleccionar un contenido ya cargado en el sistema y haber ingresado con una versión del navegador Google Chrome que soporte WebGL y acceso a la camara Web del usuario mediante WebRTC.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) selecciona un contenido de Realidad Aumentada.
2 El sistema muestra la página de visualización de Realidad Aumentada, la cual consta del botón Play/Pause para iniciar o detener el video donde se presenta el contenido, tres botones para definir el tamaño del video (pequeño, normal, grande), la descripción del contenido, una opción de votarlo (me gusta), agregarlo a favoritos y dejar un comentario. Asi mismo, en la parte lateral derecha, unos controles tipo sliders (deslizantes) de transformaciónes básicas del contenido (escala, rotación y traslación) y la opción de cambiar entre video de la cámara Web (si tiene impreso el marcador de Realidad Aumentada) o video de prueba predefinido por el sistema.
3 El actor Usuario (ACT-0001) da clic en el botón Play/Pause.
4 El sistema dependiendo del navegador, informa al usuario ue la página solicita acceso a la cámara Web del equipo y pide aprobar dicho acceso. ( éste aviso varía con la versión del navegador)
5 El actor Usuario (ACT-0001) aprueba el acceso de la aplicación a la camara Web del equipo.
6 El sistema despliega el origen de video seleccionado (camara Web o video de prueba predefinido) y sobre el marcador de Realidad Aumentada el contenido correspondiente (video o modelo 3D).
7 El actor Usuario (ACT-0001) puede ahora manipular el contenido (video o modelo 3D) con los controles de
80
transformación laterales (sliders), dejar su comentario, votar o agregarlo a sus favoritos.
Postcondición Se visualizará el contenido en Realidad Aumentada sobre el video captado por la camara Web del usuario o el video de prueba predefinido por la aplicación.
Excepciones Paso Acción
Importancia vital
Estabilidad alta
UC-0019 Votar
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0003] Gestionar las creaciones de Realidad Aumentada de los usuarios.
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desea dar su voto a un contenido de Realidad Aumentada
Precondición Haber ingresado a la herramienta de visualizacón de Realidad Aumentada mediante el caso de uso Ver Contenido en Realidad Aumentada.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) da clic en la opción Votar +1 ubicada al lado de la descripción del contenido seleccionado.
2 El sistema almacena en la base de datos la suma de un voto para dicho contenido y que usuario lo efectuó.
3 El sistema quita la opción Votar +1 y en su lugar muestra "Votado. Total Votos: n" donde n es el total de votos que se le ha dado a dicho contenido desde que fue creado.
Postcondición El contenido sumará un voto.
Excepciones Paso Acción
- -
Importancia quedaría bien
Estabilidad Media
81
UC-0020 Comentar
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0001] Gestionar perfil y entorno social del usuario [OBJ-0003] Gestionar las creaciones de Realidad
Aumentada de los usuarios.
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desea dejar su comentario a un contenido
Precondición Haber ingresado a la herramienta de visualizacón de Realidad Aumentada mediante el caso de uso Ver Contenido en Realidad Aumentada.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) redacta su comentario en el cuadro de texto disponible bajo el area del visualización del contenido y presiona el botón Comentar.
2 El sistema guarda el comentario en la base de datos y el usuario que lo redactó.
3 El sistema actualiza la lista de comentarios que es mostrada a lo largo de la página de visualización del contenido y el nuevo comentario aparecerá en primer lugar.
Postcondición Se agregará un comentario al contenido.
Excepciones Paso Acción
- -
Importancia importante
Estabilidad alta
UC-0021 Agregar a Favoritos
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias [OBJ-0003] Gestionar las creaciones de Realidad Aumentada de los usuarios.
82
Descripción El sistema deberá comportarse tal como se describe en el siguiente caso de uso cuando el usuario desea agregar un contenido seleccionado a su lista de favoritos para accederlos facilmente en otro momento
Precondición Haber ingresado a la herramienta de visualizacón de Realidad Aumentada mediante el caso de uso Ver Contenido en Realidad Aumentada.
Secuencia normal
Paso Acción
1 El actor Usuario (ACT-0001) selecciona la opción Agregar a Favoritos ubicada al lado de la descripción del contenido y de la opción Votar +1.
2 El sistema almacena en la base de datos la relación al contenido como favorito del usuario.
3 El sistema reemplaza la opción Agregar a Favoritos del contenido por el texto "Agregado a tus favoritos".
Postcondición El contenido se agrega a los favoritos del usuario.
Excepciones Paso Acción
- -
Importancia quedaría bien
Estabilidad Media
9.3.1.6 Requisitos No Funcionales
FRQ-0001 Ambiente de operación
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá ejecutarse en un navegador Web con soporte HTML5, WebGL y WebRTC. Esto significa que las características de la aplicación solo estarán disponibles para los navegadores más modernos.
Importancia Vital
Estabilidad Alta
83
FRQ-0002 Aplicación de Realidad Aumentada
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá proveer al usuario de una herramienta fácil e intuitiva para la creación de contenido de Realidad Aumentada.
Importancia Vital
Estabilidad Alta
FRQ-0003 Servidor Web
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá ejecutarse sobre un servidor Web compatible con el framework Django.
Importancia vital
Estabilidad alta
FRQ-0004 Motor de Base de Datos
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá disponer de una o varias bases de datos para almacenar toda la información del usuario, sus creaciones y su gestión social.
Importancia vital
Estabilidad alta
FRQ-0005 Conexión a Internet
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
84
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá ser accedido mediante Internet, por lo cual es un requerimiento imprescindible para los usuarios que quieran usar el sistema y para quien lo administra.
Importancia vital
Urgencia inmediatamente
Estado validado
Estabilidad alta
Comentarios Ninguno
FRQ-0006 Uso de software libre
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá estar compuesto en su totalidad de herramientas open source y libres, sin licencias privativas.
Importancia vital
Estabilidad alta
9.3.1.7 Requisitos de Información
IRQ-0001 Información de Usuarios
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá almacenar la información correspondiente a Usuarios. En concreto:
Datos específicos
Nombre de Usuario Nombre Completo Apellidos Correo Electrónico Contraseña
85
Fecha de Registro Último ingreso Si esta activo Imagen de Perfil
Tiempo de vida Medio Máximo
10 año(s) 20 año(s)
Ocurrencias simultáneas
Medio Máximo
250 300
Importancia Vital
Estabilidad Media
IRQ-0002 Información de Creaciones (Contenido)
Versión 1.0 ( 10/10/2012 )
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá almacenar la información correspondiente a Creaciones (contenidos) de Realidad Aumentada. En concreto:
Datos específicos
Galería que lo contiene Nombre Descripción del contenido Usuario propietario Fecha de Creación Fecha de Modificación Ruta de Ubicación en el servidor Comentarios recibidos Votos recibidos
Tiempo de vida Medio Máximo
10 año(s) 20 año(s)
Ocurrencias simultáneas
Medio Máximo
500 500
Importancia Vital
Estabilidad Media
IRQ-0003 Información de Contactos
Versión 1.0 ( 10/10/2012 )
86
Autores Manuel Alejandro Lopera Ospina
Fuentes Manuel Alejandro Lopera Ospina
Dependencias Ninguno
Descripción El sistema deberá almacenar la información correspondiente a Contactos del Usuario. En concreto:
Datos específicos
Usuario solicitante Usuario solicitado Fecha solicitud Fecha de aceptación Mensajes intercambiados
Tiempo de vida Medio Máximo
10 año(s) 20 año(s)
Ocurrencias simultáneas
Medio Máximo
400 500
Importancia importante
Estabilidad media
9.3.1.8 Matriz de Rastreabilidad Casos de Uso – Objetivos
TRM-0001 OBJ-0001 OBJ-0002 OBJ-0003
UC-0001
UC-0003
UC-0004
UC-0005
- -
UC-0006
- -
UC-0007
- -
UC-0009
- -
UC-0010
- -
UC-0011 -
UC-0012 - -
UC-0013 - -
UC-0014 -
-
UC-0015
-
87
UC-0016 - -
UC-0017 -
-
UC-0018 - -
UC-0019 - -
UC-0020
-
UC-0021 - -
9.3.2 Diagrama de Clases
Este diagrama de clases muestra el fundamento del sistema, aunque las ideas
para implementar en un futuro son muchas, para esta primera etapa del sistema
solo se trabajarán en las funcionalidades aquí expuestas.
Figura 6. Diagrama de Clases
88
9.3.3 Diagramas de Secuencia
Los siguientes diagramas de secuencia representan los usos más característicos
de la aplicación: crear contenido y visualizar la creación.
9.3.3.1 Diagrama de secuencia Crear Contenido
Figura 7. Diagrama de Secuencia Crear Contenido
9.3.3.2 Diagrama de secuencia Visualizar Contenido
Figura 8. Diagrama de Secuencia Visualizar Contenido
89
9.3.4 Arquitectura
La arquitectura que se muestra a continuación está representada desde el punto
de vista del patrón de diseño, que en este caso es Modelo – Vista – Controlador
(MVC). Puede observarse que la estructura mostrada se presta para ser trabajada
desde un framework de desarrollo Web robusto como Django. En la filosofía
Django la correspondencia para el Control es la Vista, para la Vista son los
Templates y el Modelo sigue inalterado, así que lo podríamos llamar patrón de
diseño Modelo – Template – Vista pero en esencia es lo mismo que el patrón
MVC.
Figura 9. Diagrama de la Arquitectura del Patrón de Diseño
90
Luego de haber visto el patrón de diseño MVC que se utilizará, se muestra en la
siguiente imagen un acercamiento a la arquitectura del sistema que se encuentra
ubicada del lado del servidor. En la sección 9.4.1 se explica cada uno de estos
componentes.
Figura 10. Diagrama de la Arquitectura del Sistema
91
9.3.5 Modelo de Datos
Realmente sencillo para un inicio, la metodología de desarrollo expuesta
anteriormente, contempla el empezar con lo fundamental y agregar complejidad
paulatinamente a medida que el sistema evoluciona.
Figura 11. Diagrama del Modelo de Datos
9.3.6 Bosquejos de Interfaces Gráficas
En esta sección se mostrarán los bosquejos ideados para posteriormente construir
las interfaces gráficas de la aplicación definitiva con mayor agilidad y sin
contratiempos. Estas interfaces no están pensadas para prototipos ya que estos
estarán más enfocados a la parte funcional del software y no de apariencia gráfica.
92
9.3.6.1 Ventana del Home Principal
Figura 12. Interfaz Gráfica del Home Principal
9.3.6.2 Ventana del Home del Perfil del Usuario
Figura 13. Interfaz Gráfica del Home del Perfil del Usuario
93
9.3.6.3 Ventana de Información del Perfil de un Usuario
Figura 14. Interfaz Gráfica de Información del Perfil de un Usuario
9.3.6.4 Ventana de Galerías
Figura 15. Interfaz Gráfica de la lista de Galerías
94
9.3.6.5 Ventana de Creaciones
Figura 16. Interfaz Gráfica de Creaciones
9.3.6.6 Ventana de Contactos
Figura 17. Interfaz Gráfica de Contactos
95
9.3.6.7 Ventana de Mensajes
Figura 18. Interfaz Gráfica de Mensajes
96
9.4 DESARROLLO DEL SISTEMA
9.4.1 Herramientas para el desarrollo del software
El sistema se desarrollará utilizando las siguientes herramientas:
HTML5 y CSS3
JavaScript
Biblioteca JSARToolKit de Realidad Aumentada
Biblioteca Three.js para WebGL
Lenguaje Python
Django Framework Web para Python
PostgreSQL 9.1
Apache2
A continuación una pequeña descripción de las razones para utilizar estas y no
otras herramientas:
HTML5 y CSS3: el auge que han tenido desde su lanzamiento claramente los
hacen muy interesantes, los desarrolladores que quieran continuar en el mundo
Web deben implementarlos obligatoriamente ya que a futuro serán los estándares
de facto.
JavaScript: lenguaje de scripting, el cual siempre está inmerso en cualquier
desarrollo Web de aplicaciones dinámicas.
JSARToolKit: API escrita en JavaScript para el desarrollo de aplicaciones de
Realidad Aumentada en ambientes Web, es open source, gratuita para uso no
comercial.
Three.js: potente motor 3D el cual facilita enormemente el desarrollo y
renderización de contenidos 3D en los navegadores Web más modernos que
soporten el estándar WebGL. Es open source y está programado en JavaScript.
97
Lenguaje Python: además de tener la ventaja de ser libre y multiplataforma, es
bastante robusto y completo, con una gran comunidad de usuarios y
desarrolladores, con innumerables recursos, ayuda y soporte.
Django Framework: potente framework open source para desarrollo Web en
Python, con una amplia comunidad de desarrolladores, soporte y mejoras
continuas.
PostgreSQL: sin duda la base de datos objeto relacionales open source más
potente del mundo en la actualidad. Tiene una historia de más de 15 años de
desarrollo y una arquitectura robusta que brinda una inmensa fiabilidad, ya que se
sustenta bajo los principios ACID. Ha sido catalogado en varias ocasiones por
diferentes medios especializados como el mejor sistema de bases de datos.
Posee uno de los mejores soportes para datos espaciales en la actualidad
(postGIS) e interfaces de programación nativas en lenguajes como Python, C/C++,
.Net, Java, Perl, entre otros. Además cuenta con una de las comunidades de
usuarios y desarrolladores más grandes del mundo en su tipo y una
documentación completa y actualizada.
Apache2: servidor Web gratuito y muy potente, capaz de soportar alto tráfico para
los sitios Web que aloje.
Se puede apreciar la preferencia por herramientas open source, esto tiene una
razón de ser y es la mayor posibilidad de personalización de las herramientas a
las necesidades específicas del proyecto, a su vez que brinda la opción de probar
sin comprar. Algunas de ellas como ARToolkit tienen licencias de pago para uso
comercial, pero antes de eso se puede probar para ver si realmente suplirá las
exigencias del proyecto.
98
9.4.2 Marcador de prueba para el visualizador de Realidad Aumentada
La imagen de la Figura 19 es el marcador de prueba para el prototipo del sistema,
específicamente para la visualización de contenido de Realidad Aumentada desde
el visor del sitio web. Este visor se nombró ARViewer y utiliza el API de ARToolkit
para dar acceso a la cámara web del usuario. El marcador se muestra frente a la
cámara para desplegar en el monitor el contenido sobrepuesto a la imágen del
marcador en el mundo real.
Este marcador conserva una forma sencilla y con esquinas que formen ángulos
rectos para facilitarle el reconocimiento al programa. Entre más complejo el patrón
del marcador, mas difícil será para el software llevar a cabo su reconocimiento. Así
que para efectos de la implementación de este prototipo, es más que suficiente.
En la sección de Anexos se encontrarán otros marcadores de ejemplo provistos
por ARToolKit para tener una referencia más clara de la forma de estos patrones.
Figura 19. Marcador de prueba para visualizador de Realidad Aumentada
99
9.5 FUTURO Y EVOLUCIÓN DEL SISTEMA
Este tema ha dejado muchas ideas abiertas pero debido al poco tiempo para
concretarlas, se convertirán en el camino de evolución de este sistema. En
concreto, se pueden listar los siguientes temas pendientes e ideas por desarrollar:
a. Desarrollar la aplicación completa como está definida en el documento de
requisitos del sistema y en la sección de requerimientos del apartado 7.2 de
este documento.
b. Explotar el potencial de Canvas de HTML5 y WebGL para desarrollar un
creador de contenido en 3D Web, conservando la facilidad de uso, para que
pueda ser usado por cualquier usuario sin experiencia.
c. Implementar la opción de generar marcadores con cualquier patrón, color u
objeto del mundo real, por ejemplo una fotografía, un rostro en movimiento,
etc. Introduciendo así la aplicación a un campo más profesional de la visión
por computadora y dando la posibilidad a los usuarios de visualizar
contenido sin necesidad de imprimir algún patrón.
d. Desarrollar un cliente de escritorio que permita sincronización con la
aplicación web para trabajar más cómoda y rápidamente con contenido
avanzado que requiera mayor versatilidad, como por ejemplo modelos
tridimensionales
e. Desarrollar un cliente para dispositivos móviles que permita acceso al
contenido de Realidad Aumentada del usuario y realizar modificaciones en
sincronía con el servidor web. Esta idea es muy interesante por lo que
implica el estudio reciente que la comunidad de desarrolladores ha venido
realizando sobre la portabilidad de Python en plataformas como iOS y
Android.
100
f. Estudiar las posibilidades de integración de los contenidos de Realidad
Aumentada con redes sociales.
g. Apoyar mediante la plataforma el diseño profesional de contenidos de
Realidad Aumentada para aplicaciones en publicidad, entretenimiento
digital, educación y demás ideas de la comunidad de usuarios.
h. Avanzar en el desarrollo de APIs propias de la plataforma que puedan ser
liberadas al público mediante licencias de código abierto para así colaborar
con la comunidad de desarrolladores.
101
10 CONCLUSIONES
La Realidad Aumentada se perfila como una tecnología cada vez más cotidiana en
la vida de las personas, el avance acelerado de los dispositivos móviles y la
creatividad cada vez mayor de los desarrolladores promete mucho camino por
delante.
Python es un lenguaje de programación potente y fácil de aprender, y aunque es
muy popular en el mundo open source, muchos en nuestro entorno lo ignoran ya
que el mercado se ha orientado hacia otras tecnologías privativas como .NET.
Esto es particularmente motivador por lo que significa el poder dar a conocer otras
opciones que sirvan de elección a programadores que se vean imposibilitados de
adquirir licencias de desarrollo con otras tecnologías.
La metodología de trabajo planteada para este proyecto pudo hacerse gracias a
los conocimientos previos adquiridos en los cursos de Ingeniería del Software.
Escoger una metodología de trabajo que se adapte al proyecto fue uno de los
elementos de análisis al inicio de la propuesta y finalmente se optó por una
metodología combinada que hiciera más dinámica y productiva la forma de trabajo
del desarrollador.
Actualmente Medellín le apuesta mucho al desarrollo de tecnologías innovadoras
de entretenimiento digital que no se habían trabajado antes en la ciudad,
enfocándose en un sector de clase mundial: “la industria de la comunicación
gráfica”. Esta actitud es motivación para desarrollar este proyecto de la mejor
manera posible y poder colaborar con dichas ideas que hagan de Medellín una
ciudad reconocida por su innovación.
102
11 REFERENCIAS BIBLIOGRÁFICAS
[1] L. Heras y J. L. Villareal, «La Realidad Aumentada: una tecnologia a la espera
de usuarios,» 10 Agosto 2004. [En línea]. Available:
www.revista.unam.mx/vol.8/num6/art48/int48.htm. [Último acceso: 12
Septiembre 2011].
[2] G. E. Jaramillo, J. E. Quiroz, C. A. Cartagena, C. A. Vivares y J. W. Branch,
«Mobile Augmented Reality Applications in Daily Environments,» Revista EIA,
nº 14, pp. 125-134, Diciembre 2010.
[3] A. Loup, «www.jeuazarru.com,» [En línea]. Available:
http://www.jeuazarru.com/docs/Realidad_Aumentada.pdf. [Último acceso: 11
11 2012].
[4] «ARToolKit,» [En línea]. Available:
http://www.hitl.washington.edu/artoolkit/documentation/userarwork.htm.
[Último acceso: 11 11 2012].
[5] I. Sommerville, Ingeniería de Software, Sexta ed., México: Pearson Education,
2002.
[6] I. Jacobson, B. Grady y J. Rumbaugh, El Proceso Unificado de Desarrollo de
Software, Madrid: Pearson Education, 2000, pp. 3-8.
[7] S. L. Pfleeger, Ingeniería de Software, teoría y práctica, Primera ed., Buenos
Aires: Pearson Education, 2002.
[8] R. Pressman, Ingeniería de Software, Un enfoque práctico, Sexta ed.,
McGraw Hill, 2008, pp. 245-249.
[9] A. Weitzenfeld, Ingeniería de Software orientada a objetos con UML, Java e
103
Internet, Mexico: Thomson Learning, 2005, p. 523.
[10] S. Bennett, J. Skelton y K. Lunn, Schaum's Outline of UML, Second ed.,
Beccles: McGraw Hill, 2005.
104
12 ANEXOS
12.1 Manual de Usuario
El siguiente manual explica de manera concisa la utilización de la aplicación Web
para creación de Realidad Aumentada desarrollada a lo largo de este proyecto.
I. Acceso a la página Web
El primer paso es abrir un explorador Web compatible (Google Chrome XX,
Firefox 4, Opera XX o versiones posteriores correspondientes. Digitar en la
barra de direcciones la URL de la página Web (en este tutorial es
http://localhost:8000 ya que aún no se ha implementado en un servidor
público).
II. Registro de Usuario e Inicio de Sesión
Si el usuario no dispone de una cuenta en la plataforma deberá diligenciar
el formulario llamado “Crear una cuenta” que se encuentra ubicado en la
parte lateral derecha de la página principal.
105
Si por el contrario, el usuario ya ha creado una cuenta previamente deberá
utilizar el formulario llamado “Iniciar sesión” también ubicado en la parte
lateral derecha de la página principal.
Cualquiera de estas dos opciones llevarán a los usuarios al interior de la
plataforma, espacio reservado para miembros registrados, mostrando la
106
página inicial donde se encuentra la actividad reciente de otros miembros
que hayan compartido públicamente sus creaciones.
III. Completar la información de perfil del usuario
Dando clic sobre el nombre de usuario ubicado en la parte superior derecha
(junto a la opción “Salir”), se muestra la página donde el usuario podrá
completar y editar su información personal. Una vez diligenciados los
campos de información y habiendo seleccionado una imagen de perfil se
presiona el botón “Actualizar” para guardar los cambios realizados.
IV. Explorar el contenido de otros usuarios
En la página de inicio se encuentran las creaciones compartidas
públicamente por otros usuarios, o el contenido compartido contigo por ser
contacto del propietario.
Haciendo clic sobre cualquiera de estas creaciones se muestra al usuario la
página de visualización de Realidad Aumentada, donde puedes escoger si
reproducir el contenido utilizando la cámara web y el marcador de Realidad
107
Aumentada ya impreso, o utilizar el video de prueba que viene incluido en la
plataforma para no tener que imprimir el marcador. Los controles
deslizables del lado derecho permiten manipular en contenido, haciéndolo
más grande o pequeño, rotándolo o moviéndolo en dirección de los ejes
XYZ. En la parte de abajo se encuentra el área de comentarios donde
puedes opinar sobre el contenido que estas visualizando.
V. Crear contenido de Realidad Aumentada
Acceder a través de la opción “Contenidos” del menú principal izquierdo.
Todo contenido debe estar dentro de una Galería, por lo tanto crea una
como se muestra en la imagen a continuación. Puedes ponerle cualquier
nombre que sirva para identificar el contenido que vayas a almacenar
dentro.
108
Una vez creada la galería puedes cambiar su tipo de privacidad
seleccionando una opción de la lista “Compartir con”, la opción por defecto
es compartir con “Todos” lo cual significa que la galería será pública.
Para abrir la galería, dar clic sobre ella. Al principio aparecerá vacía,
debemos disponer de un modelo 3D en formato .dae, .js o .json, o de un
109
video en formato .ogg. Estos formatos son los únicos soportados
actualmente por la plataforma (se requiere que el contenido este
comprimido en formato .zip). Para subir el contenido se debe utilizar el
formulario ubicado en la parte superior central, como se muestra a
continuación:
El tiempo de carga depende de la velocidad de conexión a Internet y
tamaño del modelo 3D o video. Una vez terminada la carga aparecerá el
nuevo contenido, el cual puedes visualizar como de la misma manera como
se mencionó en el inciso IV. También puedes cambiar la forma de como se
comparte este contenido, por defecto esta público, pero puedes hacerlo
privado, visible para amigos o para amigos de amigos.
110
VI. Explorar lista de favoritos
Acceder a través de la opción “Contenido” del menú principal izquierdo y
dar clic en la opción “Mis Favoritos. Se mostrará toda la lista de creaciones
que hayas marcado como favorita, la cual puede ser visualizada dando clic
sobre ella de la misma manera como se mostró en el inciso IV.
111
VII. Explorar perfiles de otros usuarios y agregarlos a contactos
En la página de “Inicio” en la parte lateral derecha se encuentra la lista de
usuarios registrados. Al hacer clic sobre alguno de ellos se abre su página
de información de perfil. Desde allí se puede acceder a sus galerías y
creaciones si estas son públicas y enviarle un mensaje o una invitación para
agregarlo a tus contactos.
Si das clic en la opción “Mensaje” se abre la ventana de redacción que se
muestra a continuación:
112
Si agregas a otros usuarios como contactos y estos aceptan la invitación,
puedes ver tu lista de amigos a través de la opción “Contactos” del menú
principal. Desde esta lista puedes acceder a la información de cada uno
simplemente dando clic sobre su fotografía o nombre de usuario.
113
VIII. Enviar y recibir mensajes de otros usuarios
Acceder a través de la opción “Mensajes” del menú principal. Una vez allí,
dispones de tres opciones de mensajes: “Enviados”, “Recibidos” y
“Solicitudes de contacto”.
La opción de “Enviados” muestra los mensajes que ha enviado a otros
miembros de la plataforma, con su correspondiente destinatario, asunto y
fecha. Al dar clic sobre el nombre de usuario destinatario se abre la página
de información de perfil de ese usuario como ya se explicó anteriormente
en el inciso VII y al dar clic sobre el asunto del mensaje se abre la página
de lectura con el cuerpo del mensaje enviado.
La opción de “Recibidos” muestra los mensajes que otros usuarios te han
enviado con su correspondiente remitente, asunto y fecha. Al dar clic sobre
el nombre de usuario remitente se abre la página de información de perfil de
ese usuario. Al dar clic sobre el asunto del mensaje se abre la ventana de
lectura donde también se puede responder con otro mensaje al usuario
remitente.
114
La opción de “Solicitudes de contacto pendientes” muestra las invitaciones
que otros miembros te han hecho para agregarte como contacto y que aun
no se han aprobado o rechazado.
IX. Cerrar sesión
Para cerrar sesión de manera segura solo basta con dar clic en la opción
“Salir” ubicada en la parte superior derecha de la página.
De inmediato el sistema direcciona al usuario a la página de inicio principal
donde empezó este manual.
12.2 Manual de Administración
Django proporciona un sistema de administración integrado para el modelo de
datos. Primero este sistema debe estar activado en el fichero de configuración de
la aplicación web Django (settings.py). Para acceder a la interfaz de
administración solo digita en tu navegador Web la URL de la página seguido de
115
“/admin”, así por ejemplo en el servidor de desarrollo local sería
http://localhost:8000/admin. La página inicial solicitará ingresar el usuario y
contraseña del administrador, que en este caso ambas son “admin” (sin las
comillas).
Una vez autenticado, la interfaz de administración luce como en la imagen
siguiente:
Como se puede ver en la imagen anterior, Django muestra las tablas de la base de
datos (se puede configurar cuales queremos mostrar y cuáles no y la forma en que
116
estas son presentadas), dando clic sobre cualquiera de ellas se pueden agregar,
actualizar o borrar registros. A continuación un par de imágenes más que
muestran la navegación a través de este útil administrador que proporciona
Django.
La interfaz es muy intuitiva y fácil de navegar, así que es preferible dedicar las
siguientes líneas a explicar resumidamente cómo está estructurada la aplicación
web con el framework Django. Para información completa de Django consulte la
página oficial de la comunidad (www.djangoproject.com), donde se encuentra
documentación, foros y demás recursos para aprender sobre ésta poderosa
herramienta.
117
12.3 Glosario
ActionScript: lenguaje de programación de Adobe Flash propiedad de la
compañía Adobe, muy usado en el desarrollo de contenido interactivo.
ACID: término utilizado en bases de datos para referirse a ciertas características
transaccionales que poseen algunos motores de gestión de bases de datos. Estas
características son Atomicidad (una operación debe completarse), Consistencia
(asegura la integridad de los datos), Aislamiento (Isolation, una operación no
afecta a otras) y Durabilidad (los datos son persistentes y soportarán fallos del
sistema).
ARToolKit: biblioteca desarrollada en C y C++ que facilita la creación de
aplicaciones de Realidad Aumentada. Hace transparente para el desarrollador el
complejo manejo de la detección de marcadores, posicionamiento de contenido,
cámara y visualización que son los principales flujos de una aplicación típica de
RA.
DRS: documento de requisitos del sistema; es un documento de vital importancia
producto de la etapa de análisis, y que sirve como base para las siguientes etapas
en el ciclo de vida del software.
FLARToolKit: variante de ARToolKit en ActionScript que hace uso del plugin de
Flash Player instalado en los navegadores Web.
Flash Player: software multimedia que reproduce (ejecuta) las aplicaciones o
contenidos desarrollados en Flash Player. En este caso, se refiere al software
instalado en el navegador de internet (plugin).
Framework: o marco de trabajo, en el campo del desarrollo de software se refiere
a una metodología para el desarrollo de sistemas informáticos que agiliza el
trabajo y la calidad de los productos de software. También puede referirse a
herramientas de software que facilitan la programación con ciertas tecnologías,
118
por ejemplo los frameworks para desarrollo web como Simphony o Yii para PHP, o
Django para Python (este último es el utilizado para el desarrollo de este
proyecto).
GPS: sistema de posicionamiento global; tecnología que permite la ubicación en
cualquier lugar del planeta de algún dispositivo (por ejemplo un smartphone) que
posea una antena que comunique con los satélites encargados del cálculo de esta
posición.
GUI: interfaz gráfica de usuario; parte visual ante el usuario de una aplicación de
software, de vital importancia ya que puede hacer la diferencia entre una
aplicación fácil de usar y una poco intuitiva y confusa.
HTML5: quinta versión del estándar HTML que incorpora varias novedades con
respecto a la versión anterior, por ejemplo Canvas (para renderizado), WebRTC
(para el acceso a la cámara y el micrófono), características que antes solo eran
posibles con el uso de plugins ajenos al navegador Web como Flash Player.
JavaScript: lenguaje de programación interpretado de uso “obligatorio” en la Web.
Puede afirmarse que casi todas (o todas) las páginas y aplicaciones web actuales
hacen uso de este lenguaje y todos los navegadores modernos incluyen un motor
de interpretación que hacen posible ejecutar el código escrito en este lenguaje.
JSARToolKit: variante de ARToolKit en JavaScript. Es la biblioteca utilizada en
este proyecto debido a su entorno Web.
Marcador RA: se refiere a una figura patrón en el mundo real utilizada en
Realidad Aumentada para desplegar contenido virtual sobre ella y preservar la
perspectiva de visualización de la cámara.
MVC: el patrón de diseño Modelo – Vista – Controlador es en la arquitectura de
software, una forma ampliamente utilizada para la creación de un sistema de
computo, separando y organizando las partes fundamentales de este, de tal forma
119
que los datos del negocio (Modelo) puedan ser accedidos por el usuario a través
de una Vista gráfica que es manejada por un Controlador central que recibe las
peticiones, las gestiona y retorna la información solicitada a la Vista para ser
presentada al usuario.
Plugin: pequeña aplicación de software desarrollada por separado de un sistema
más robusto el cual se sirve de la primera para efectuar tareas que no fueron
incluidas en su código nativo.
RA: sigla en español para Realidad Aumentada, la tecnología que aborda este
proyecto.
Renderizado: término usado en Computación Gráfica para referirse al proceso de
generación de imágenes o animaciones mediante cálculos geométricos, de
iluminación, color, vértices y pixeles, generalmente mediante programas
especializados en diseño 3D.
Smartphone: en español teléfono inteligente; término usado para referirse a la
gama de teléfonos móviles que brindan prestaciones más avanzadas (semejantes
a una computadora de bolsillo) que un teléfono móvil convencional.
UML: siglas en ingles para el Lenguaje Unificado de Modelado creado por Ivar
Jacobson, Grady Booch y James Rumbaugh a mediados de los años 90,
convertido en estándar por la ISO desde el año 2005. Se trata de un lenguaje
grafico que permite la especificación y documentación de un sistema de software.
UP: siglas en ingles para la metodología de desarrollo de software conocida como
Proceso Unificado, el cual es ampliamente utilizado como marco de trabajo en
ingeniería de software ya que se adapta fácilmente a las organizaciones y
proyectos.
WebGL: es un estándar para el desarrollo de contenido 3D en navegadores Web
modernos que no necesita el uso de plugins de terceros para este cometido.
120
12.4 Marcadores de prueba para Realidad Aumentada
