1

CATÁLOGO DIGITAL DESARROLLADO EN ANDROID PARA APPTITUD, EMPRESA PARQUESOFT PEREIRA

CATHERIN ANDREA OCHOA ROJAS

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PRÁCTICAS ACADÉMICAS

PEREIRA 2013

2

CATÁLOGO DIGITAL DESARROLLADO EN ANDROID PARA APPTITUD, EMPRESA PARQUESOFT PEREIRA

CATHERIN ANDREA OCHOA ROJAS

PLAN DE PRÁCTICA

Tutor RICARDO ALONSO HURTADO MOSQUERA

INGENIERO DE SISTEMAS Y TELECOMUNICACIONES

UNIVERSIDAD CATÓLICA DE PEREIRA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

PROGRAMA DE INGENIERÍA DE SISTEMAS Y TELECOMUNICACIONES PRÁCTICAS ACADÉMICAS

PEREIRA 2013

3

TABLA DE CONTENIDO

INTRODUCCIÓN .................................................................................................... 7

1. PRESENTACIÓN DELA ORGANIZACIÓN O SITIO DE PRÁCTICA................ 8

1.1 HISTORIA DE LA EMPRESA ........................................................................ 8

1.2 MISIÓN ........................................................................................................ 10

1.3 VISIÓN ......................................................................................................... 10

1.4ESTRUCTURA ORGANIZACIONAL ............................................................. 11

1.5 NÚMERO DE EMPLEADOS ........................................................................ 11

1.6 ÁREA DE TRABAJO DEL PRACTICANTE .................................................. 11

1.7 DESCRIPCIÓN DE LA ACTIVIDAD COMERCIAL DE LA EMPRESA ......... 11

2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN ...................................... 13

3. DESCRIPCIÓN DEL PROBLEMA .................................................................. 13

4. JUSTIFICACIÓN DE LA PROPUESTA DE SOLUCIÓN ................................. 13

5. OBJETIVOS .................................................................................................... 15

5.1. OBJETIVO GENERAL ................................................................................ 15

5.2. OBJETIVOS ESPECÍFICOS. ...................................................................... 15

6. MARCO TEÓRICO ......................................................................................... 16

6.1 HISTORIA DE ANDROID ......................................................................... 16

6.2 LENGUAJE DE DESARROLLO. .............................................................. 17

6.3 WEB SERVICE ........................................................................................ 18

6.4 BASES DE DATOS .................................................................................. 19

7. CRONOGRAMA ............................................................................................. 20

8. PRESENTACIÓN Y ANÁLISIS DE RESULTADOS ........................................ 21

8.1 LEVANTAMIENTO DE REQUERIMIENTOS. .......................................... 21

8.2 DISEÑO DE CASOS DE USO. ................................................................ 24

8.2.1 MODELO DE CASOS DE USO ......................................................... 26

8.2.2 DESCRIPCIÓN DEL CASO DE USO ................................................ 27

8.3 MODELACIÓN DE LOS DATOS .............................................................. 28

4

8.3.1 MODELO ENTIDAD-RELACIÓN ....................................................... 29

8.3.2 MODELO RELACIONAL ................................................................... 29

8.4 MODELO DE INTERFACES .................................................................... 30

9. CONCLUSIONES. .......................................................................................... 33

10. RECOMENDACIONES. .............................................................................. 33

REFERENCIAS ..................................................................................................... 35

5

LISTA DE ILUSTRACIONES

Pág.

FIGURA 1. Organigrama ParqueSoft 11

FIGURA 2. Esquema del web service 18

TABLA 3. Cronograma 20

FIGURA 4: Modelo de caso de uso general. Realizado en Enterprise Architect 26

TABLA 5. Descripción de caso de uso 1.1 27

FIGURA 6. Modelo E-R, realizado en la herramienta Día. 29

FIGURA 7. Modelo Relacional, realizado en la herramienta Día 29

FIGURA 8. Formulario de registro de usuario 30

FIGURA 9. Vista para iniciar sesión 31

FIGURA 10. Vista principal de la App, se muestra la publicidad geolocalizada 31

FIGURA 11. Listado de restaurantes 32

FIGURA 12. Listado de productos 32

6

SÍSTESIS

ABSTRACT

This document shows the entire software engineering process done for creating a mobile application, which is intended to be a catalog that can display information of the restaurants of the city, each of its products and promotions depending on where the device is found, and how to perform client-server connection.

Keywords: Android, Mobile Devices, Catalog, Web Services, Databases, Software Engineering.

SÍNTESIS

El presente documento evidencia todo el proceso de ingeniería de software realizado para la creación de una aplicación móvil, la cual tiene como fin ser un catálogo que permita mostrar información de los restaurantes de la ciudad, cada uno de sus productos y promociones dependiendo del lugar donde se encuentre el dispositivo, además de cómo realizar la conexión cliente-servidor. Descriptores: Android, Dispositivos móviles, Catálogo, Web Services, Base de datos, Ingeniería de Sofware.

7

INTRODUCCIÓN

El entorno cambiante y extremadamente competitivo del siglo XXI, dónde el

mundo se interconecta para lograr comunicarse fácilmente, ya sea en un área

local, nacional o internacional, es el gran punto de apoyo para el avance de la

tecnología móvil. Un mundo en dónde el papel está quedando en un segundo

plano,sea por el tema ambiental o por ahorrar dinero, para pasar a liderar el

mundo digital. No obstante, cada vez la tecnología nos toma más de la mano, para

facilitarnos tareas, la forma de comunicación, ahorrar costos, entre otras ventajas

que nos ofrecen las TICs.

Es gracias a esto que Apptitud, empresa ParqueSoft, decide realizar un proyecto

que permite reemplazar el catálogo físico de los restaurantes por una aplicación

móvil, de fácil manejo para sus usuarios y teniendo sus clientes la oportunidad de

administrarla mediante una plataforma web. Ésta aplicación consiste en mostrar

una lista de restaurantes de las diferentes ciudades que se encuentren registradas

en ella, por ende, ofrecer la variedad de productos entregados por los

restaurantes.

Teniendo en cuenta lo anterior y que Android, es una plataforma que está

dominando el mercado mundial de los Smartphone, muy apetecida por sus

usuarios, la aplicación se ha diseñado y desarrollado en base a ella, teniendo la

oportunidad de obtenerla mediante diversos medios como códigos QR, redes

sociales y tiendas de descarga.

8

1. PRESENTACIÓN DELA ORGANIZACIÓN O SITIO DE PRÁCTICA

1.1 HISTORIA DE LA EMPRESA

En el año de 1999 surgió en Cali bajo el liderazgo de Orlando Rincón una iniciativa

cuyo objeto era la creación de un espacio para jóvenes emprendedores de la

industria del Software. Orlando Rincón, un reconocido líder de la industria, había

fundado en 1984 Open Systems Ltda., una de las empresas más representativas

de la industria de software colombiana. Durante todos estos años acumuló

experiencias y conocimiento acerca de cómo consolidar una empresa de software.

En 1997 visitó dos países transformados en líderes globales de esta industria y

con condiciones similares a Colombia: Irlanda y la India. Orlando observó que era

viable construir, con muy poca inversión, un Parque Tecnológico de Software y

que ésta podría ser una excelente oportunidad para la ciudad de Cali, sumida

entonces en una grave crisis económica y de identidad social, debido al funesto

impacto del narcotráfico. Para ello, en junio de 1999 y aprovechando el cambio de

sede de Open Systems, Orlando acordó con ésta la donación de la infraestructura

avaluada en USD $30.000 para el inicio del Parque Tecnológico de Software de

Cali.

En años anteriores, Orlando había desarrollado un proceso de incubación de dos

empresas de software: VIANet, dedicada a crear páginas y software WEB y Apedi,

empresa a la cual Open había entregado su software de propósito comercial

cuando decidió especializarse en software para servicios públicos y

telecomunicaciones, brindándoles apoyo económico, coaching y asesoría

permanente en tecnología y situaciones de negocios. En 1998 se había

9

incorporado Innova Systems, especializada en el desarrollo de software para

gestión documental. Estas empresas se trasladaron en septiembre de 1999 a las

instalaciones donadas por Open Systems, en calidad de empresas base,

fundadoras de este proyecto. En diciembre de ese mismo año se creó la

Fundación Parque Tecnológico del Software con el objetivo de facilitar la creación

de empresas de software por parte de emprendedores jóvenes en la ciudad de

Cali, en ese entonces con capacidad para residenciar proyectos de

emprendimiento con espacio para tres personas por proyecto, así nació

ParqueSoft.

Actualmente consolida un corredor de ciencia y tecnología en las ciudades de Cali,

Popayán, Pasto, Buga, Tuluá, Palmira, Armenia, Manizales, Pereira,

Buenaventura, Ibagué, Villavicencio y Sincelejo.

En la ciudad de Pereira, ParqueSoft inició labores hace más de siete (7) años,

gracias al empuje de varios emprendedores de la empresa Fastec de Colombia,

quienes luego de conocer y valorar el modelo implementado en Cali, fueron

vinculados como miembros de la Fundación Parque Tecnológico de Software en

Agosto de 2002.

En el 2004, el proyecto fue vinculado al plan de desarrollo de la administración de

Juan Manuel Arango, alcalde de Pereira de ese entonces; también fue incorporado

en la Política de Desarrollo Regional del programa Ciencia, Tecnología e

innovación, bajo la cual se proporcionaron rubros económicos para los primeros

tres años de funcionamiento de ParqueSoft. En alianza entre Alcaldía de Pereira y

la Universidad Tecnológica de Pereira (UTP) se entregó en comodato a la UTP el

espacio físico en el cual a la fecha, opera la Fundación, fue así como el 15 de

Marzo de 2005, se constituyó la Fundación Parque Tecnológico de Pereira –

ParqueSoft Pereira- siguiendo los lineamientos filosóficos de ParqueSoft Cali.

10

Actualmente cuenta con un total de cuarenta y ocho (48) empresas y noventa

y cuatro (94) emprendedores desarrollando proyectos de base tecnológica

e investigación en áreas de Gestión empresarial, inteligencia de negocios,

educación, media digital, medio ambiente, industria y servicios; además de esto

cuenta con diferentes reconocimiento a nivel nacional e internacional donde

algunas de sus empresas han sido ganadoras en 5 ocasiones de TIC América y 4

veces del Global TIC.

1.2 MISIÓN

Posibilitar un espacio de desarrollo y respaldo para emprendedores con ideas de

base tecnológica, que favorezca la generación de soluciones para satisfacer las

necesidades delos diferentes sectores productivos de la región, fomentando el

desarrollo tecnológico y el capital social.

1.3 VISIÓN

Para el 2013, ParqueSoft Pereira, será reconocida como la entidad líder de

fomento al emprendimiento en Risaralda, dinamizando a través de sus

emprendimientos el sector delas Tecnologías de la Información y las

Comunicaciones, bajo un modelo de desarrollo endógeno.

11

1.4ESTRUCTURA ORGANIZACIONAL

FIGURA 1.Organigrama ParqueSoft

Fuente: Manual de calidad de ParqueSoft Pereira

1.5 NÚMERO DE EMPLEADOS

Actualmente ParqueSoft Pereira cuenta con 6 empleados en su campo

administrativo.

1.6 ÁREA DE TRABAJO DEL PRACTICANTE

Área de desarrollo, ejerciendo actividades como practicante en desarrollo de

software.

1.7 DESCRIPCIÓN DE LA ACTIVIDAD COMERCIAL DE LA EMPRESA

Practicante

Desarrollo de SW

12

ParqueSoft es una fundación sin ánimo de lucro cuyo propósito es facilitar a

jóvenes emprendedores la creación y desarrollo de empresas de base tecnológica

que provean al mercado de productos y servicios de tecnología informática. El

proceso de crecimiento y desarrollo de la actividad empresarial de los

emprendedores está apoyada por 3 etapas, éstas con el fin de representar el nivel

de evolución y responsabilidad que va adquiriendo cada empresa según los logros

y experiencias adquiridas.

• Etapa Junior:

Tiene duración de 6 meses e inicia al momento del ingreso a la comunidad

ParqueSoft. Esla primera etapa y representa el proceso inicial de todo

emprendedor en donde se consolida, se da forma a la idea de negocio y se

desarrolla el producto o servicio.

• Etapa Advanced

Se inicia una vez culminada la etapa Junior y tiene duración de año y medio. Esta

etapa representa el nivel de evolución de la actividad empresarial, en la que se

tiene un prototipo del producto o servicio y se está preparado para realizar prueba

piloto. En esta categoría los emprendedores adquieren la obligación de pertenecer

a uno de los comités de la Fundación.

• Etapa Senior

Se considera la etapa de mayor nivel y tiene duración indefinida, ya que culmina

únicamente con la desvinculación del parque. En esta etapa, las empresas están

plenamente consolidadas, en donde su producto o servicio ya está probado y en la

que ya se cuenta con varios clientes.

13

2. DEFINICIÓN DE LAS LÍNEAS DE INTERVENCIÓN

Siendo ParqueSoft una fundación sin ánimo de lucro, cuyo propósito es facilitar a

jóvenes emprendedores la creación y desarrollo de empresas de base tecnológica,

que provean al mercado de productos y servicios de tecnología informática, ésta

práctica se direcciona en la línea del desarrollo de software para crear

aplicaciones móviles.

3. DESCRIPCIÓN DEL PROBLEMA

Se realizó un estudio de mercado y se determinó la necesidad que tienen los

restaurantes y bares de la ciudad, para renovar sus catálogos impresos que

generalmente son costosos, permitiendo actualizarlos tan sólo de una a dos veces

por año, notándose el deterioro del papel; siendo de mala presentación para el

establecimiento e incómodo para sus usuarios tener que ver una carta vieja,

deteriorada, con enmendaduras y en algunos casos, rasgada y salvada con cinta.

No obstante, el restaurante y/o bar genera altos gastos en cartas y publicidad, lo

que ocasiona una gran inversión que en poco tiempo será desechada, sin

mencionar el impacto ambiental que causa tanto gasto de papel.

4. JUSTIFICACIÓN DE LA PROPUESTA DE SOLUCIÓN

El desarrollo consiste en realizar un menú/catálogo actualizable para

restaurantes, con promociones geo-localizadas. Permite consultar el menú del día,

anunciar a sus usuarios promociones, ver precios de los productos y teléfonos de

14

los restaurantes, con el fin de que pueda estar enterado de la carta que se ofrece

en el restaurante al que desea asistir.

La aplicación se desarrolla para la plataforma Android, disponible para dispositivos

móviles que tengan este Sistema Operativo, ya que aporta facilidad de acceso a la

carta a través del dispositivo, teniendo como meta que ésta aplicación se convierta

en una solución móvil de fácil acceso para sus usuarios y ahorro económico para

sus clientes.

A continuación, se nombran las características de la aplicación y su contenido

como solución portable a la necesidad identificada:

Registro: los usuarios pueden registrarse en la aplicación para poder

recibir información actualizada sobre las diferentes ofertas del día y conocer

la lista de restaurantes que se encuentren cerca de él con su respectiva

carta.

Promociones: facilita información sobre las ofertas del día o la semana en

diferentes restaurantes y bares, los más cercanos al sitio donde se

encuentre ubicado con su móvil.

Consultas: permite realizar búsquedas ya sea por nombre del producto o

nombre del restaurante.

Listado: muestra un listado de restaurantes con datos principales como:

nombre, dirección, teléfono.

Productos: entrega información de los productos que se venden en el

restaurante que seleccionó, al igual que el precio y algunos comentarios de

sus consumidores.

La aplicación móvil, menú/catálogo actualizable, de productos y servicios de

restaurantes, pretende integrar restaurantes y bares de las ciudades, ofreciendo a

sus usuarios un listado de estos sitios, con información actualizada de la carta y

promociones que se brindan en días especiales, de igual manera, información del

restaurante como dirección, teléfono y ciudad. Otorgándole al usuario estos

15

beneficios desde una interfaz agradable y fácil de manejar, además utilizando un

dispositivo móvil, que se ha convertido en la sombra de los ciudadanos en una

plataforma dominante del mercado a nivel mundial, economizando a sus clientes

tiempo y dinero a la hora de renovar su menú impreso.

5. OBJETIVOS

5.1. OBJETIVO GENERAL

Analizar y diseñar una aplicación cliente-servidor móvil para Android, que permita

consultar la información de ubicación y contacto de proveedores de un producto y,

al mismo tiempo, visualizar información publicitaria de proveedores aledaños a la

ubicación geográfica del móvil.

5.2. OBJETIVOS ESPECÍFICOS.

Definir las características de las imágenes publicitarias y de la información

de contacto y ubicación de los proveedores de productos.

Diseñar y desarrollar interfaces gráficas, que sigan definiciones básicas de

usabilidad para dispositivos móviles, de tal forma que estas sean sencillas

de entender y fáciles de utilizar.

Identificar las técnicas, herramientas y metodologías más adecuadas para

el desarrollo de la aplicación.

Realizar el levantamiento de requerimientos asociados al proyecto.

16

6. MARCO TEÓRICO

En este mundo de tecnología, que avanza cada día más en el sector de las aplicaciones para dispositivos móviles, cuenta con diversas plataformasdedesarrollocomo lo son Windows Phone, iOS, Blackberry OS, Symbian y el más popular en este momento a nivel mundial Android, que a su vez es la plataforma que resalta este documento.

Android es un sistema operativo creado por Google, pensado inicialmente para los dispositivos móviles. Básicamente, convierte el dispositivo móvil en un ordenador de bolsillo, se puede navegar por internet igual que con un computador tradicional, además de ser un software de código libre, lo que significa que no solo pueden mejorarlo los desarrolladores de Google, sino que también se nutre de aportaciones de desarrolladores externos.

6.1 HISTORIA DE ANDROID

Android era inicialmente una empresa joven, que desarrollaba un sistema

operativo para dispositivos móviles y en el año 2005 fue comprada por Google.

Desde entonces, varios rumores anunciaban la aparición de un teléfono Google

llamado Gphone. No obstante Google preparaba algo mucho más que eso. El 5 de

noviembre de 2007, se anunció la creación del OHA (Open Handset Alliance): un

consorcio creado por iniciavita de Google que reunía en su comienzo una treintena

de empresas, la mayoría eran operadores móviles, fabricantes de dispositivos,

empresas industriales y fabricantes de software.

El mismo día, el OHA presenta oficialmente Android: la primera plataforma

completa y abierta para dispositivos móviles. Esta plataforma incluye un sistema

operativo, el middleware (aplicaciones intermedias), una interfaz de usuario y

aplicaciones de referencia. Luego, el 12 de noviembre de 2007, el OHA anuncia la

aparición del primer SDK (Software Development Kit) o kit de desarrollo de

17

software Android, que permite a los desarrolladores poder crear sus propias

aplicaciones para la plataforma Android.

En noviembre de 2008 apareció el AndroidMarket, la tienda de aplicaciones de

Google que permite a los desarrolladores y fabricantes de software poner a

disposición de cualquier cliente de Android, las aplicaciones desarrolladas por

ellos.

El primer Smartphone Android apareció en octubre de 2008 en los Estados Unidos

y en marzo de 2009 en España. A mediados de 2009 aparecen las primeras

tabletas táctiles Android, pero sería necesario esperar hasta principios de 2011

para la aparición de la versión Android 3.0 concebida especialmente para las

tabletas, con el propósito de hacerlas disponibles para el gran público.

(PÉROCHON, Sébastien. ANDROID: Guía de desarrollo de aplicaciones para

Smartphone y Tabletas. Edición española: Francisco Javier PIQUERES JUAN

Barcelona, Editions ENI – Junio 2012. Pág. 18).

6.2 LENGUAJE DE DESARROLLO.

Las aplicaciones de Android pueden ser desarrolladas en Java o en C++, creando aplicaciones nativas, es decir, aplicaciones que se ejecutan directamente sobre el sistema operativo. Estas aplicaciones pueden ser publicadas en el AndroidMarket, luego de los desarrolladores haber tenido un proceso de registro.

El catálogo digital ha sido desarrollado en lenguaje Java, acompañado de Eclipse, su entorno de desarrollo para aplicaciones Android. Gracias a que Eclipse acoplado al plug-in ADT, integra numerosas funcionalidades específicas, desde el asistente para la creación de un proyecto Android, hasta la exportación de la aplicación final, el apk.

Java es a la vez un lenguaje y una plataforma de desarrollo. SUN caracteriza a Java como un lenguaje sencillo, orientado a objetos, distribuido, interpretado, robusto, securizado, independiente de las arquitecturas, portable, eficaz, multihilo y dinámico. Estas características son el resultado del libro blanco escrito en mayo

18

de 1996 por James Gosling y Henry Mc Gilton, disponible en http://java.sun.com/docs/white/langenv.

6.3 WEB SERVICE

Ya cuando se tiene establecido la plataforma y el lenguaje en el que se va a

desarrollar la aplicación, el paso a seguir en el desarrollo es cómo hacer que la

aplicación se comunique con el servidor, para poder así llamar (consultar datos)

que se encuentran alojados en la base de datos y de igual forma, almacenar la

información del usuario que se registra en la aplicación.

Para obtener dicha comunicación, es necesario entonces hacer uso de los web

services, que son una forma estandarizada de integrar aplicaciones web, mediante

el uso de XML, SOAP, WSDL y UDDI sobre los protocolos de internet. XML es

usado para describir los datos, SOAP se ocupa de la transferencia de los datos,

WSDL se emplea para descubrir los servicios disponibles y UDDI se ocupa de

conocer cuáles son los servicios disponibles.

“Un web service es una interfaz, accesible por protocolos (estándar o no) usados

en Internet, que permite acceder a las funcionalidades de un objeto concreto, sin

importar las tecnologías ni plataformas implicadas en la petición” (Ribas, 2003,

10).

FIGURA 2. Esquema del web service.

19

Fuente: Libro Web Services, escrito por Jean Ribas Lequerica.

La figura anterior, muestra el esquema del proceso que realizan los web services,

en este caso, un usuario hace una petición desde su computador de escritorio, no

obstante, es el mismo procedimiento si se ejecuta desde un dispositivo móvil. Con

el fin de establecer un diálogo entre cliente (Web ServiceClient), que además de

ser el que envía la petición, también recibe una respuesta, y el servidor (Web

Service), se encarga de ejecutar el proceso ante esta petición y envía la

respuesta, puede utilizar codificación basada en lenguaje XML o JSON, este

último es un formato ligero para el intercambio de datos.

Los web services ofrecen diferentes arquitecturas para el desarrollo de los

mismos, entre estas arquitecturas se encuentran SOAP y REST, la más adecuada

para este proyecto es REST; se toma esta decisión por ser un estilo de

arquitectura que ofrece un buen desempeño, escalabilidad y abstracción de

recursos, donde cada petición HTTP contiene toda la información necesaria para

responder a la petición, en un archivo JSON.

6.4 BASES DE DATOS

Este archivo JSON es recibido por el servidor, interpretado de tal forma que pueda

hacer sentencias SQL en la base de datos y resolver las solicitudes, es decir un

CRUD (Create, Read, Update and Delete).

Una petición HTTP, tiene métodos como POST, GET, PUT, DELETE, que

determinan las funciones nombradas anteriormente.

Existen diversos gestores de bases de datos, por ejemplo Oracle, SQL-Server,

MySQL, PostgreSQL, entre otros, donde los dos últimos son SGDB libres, los

demás son comerciales.

“El uso de bases de datos es parte fundamental de la gestión de la información

empresarial. Postgres surgió como una continuación del proyecto gres, para el

20

desarrollo de un sistema de bases de datos, que ha continuado bajo la filosofía de

desarrollo de software libre. Ha sido descrito como un sistema de bases de datos

relacional orientado a objetos.” (Martin, 2011, 96).

Es por esto, que para la realización del catálogo digital, la base de datos que se

implementa está desarrollada en PostgreSQL. Por ser libre y orientado a objetos;

siendo este el paradigma de programación utilizado sobre el lenguaje Java para

todo el desarrollo del proyecto. Otras características importantes de PostgreSQL

es que corre en variedad de sistemas operativos: Linux, Unix, Mac OS, Windows,

etc.

7. CRONOGRAMA

TABLA 3. Cronograma

ACTIVIDADES ENERO FEBRERO MARZO ABRIL MAYO JUNIO

Diseño de interfaz (GUI)

Prototipo no funcional

Plan de negocios

Modelo de análisis

Modelo de diseño

Modelo de los datos

Modelo de la estructura web

EVALUACIÓN Y CORRECCIÓN DE LOS

MODELOS PROPUESTOS

DOCUMENTACIÓN

- Informe de ubicación

- Plan de práctica

- Informe de avance

- Borrador final

- Informe final

21

8. PRESENTACIÓN Y ANÁLISIS DE RESULTADOS

Para solventar la problemática que presenta este proyecto, sobre la necesidad que

tiene los restaurantes y bares de la ciudad, poder renovar sus catálogos de forma

digital, se escogió una metodología propia, cumpliendo con las normas básicas

para el desarrollo de un proyecto. Allí se estiman una serie de pasos a seguir,

empezando por la ingeniería de software que se le realiza al proyecto. Éste es el

estudio que se le hace a la posible solución, estructurando toda su arquitectura:

Levantamiento de requerimientos.

Diseño de casos de uso.

Modelación de los datos.

Modelo de interfaces.

8.1 LEVANTAMIENTO DE REQUERIMIENTOS.

Requerimientos del sistema.

Inicialmente el cliente define los requerimientos que él considera necesarios para

la creación de su aplicación, estos son:

1. Una aplicación que permita registrar usuarios y luego puedan iniciar sesión

con su cuenta y contraseña.

2. Una aplicación que permita mostrar información de los restaurantes de la

ciudad.

3. Una aplicación que permita mostrar el menú de cada uno de esos

restaurantes.

4. La aplicación además permitirá mostrar publicidad dependiendo de la

ubicación geoestacionaria del usuario.

5. El usuario puede hacer comentarios de los productos de cada restaurante

desde la aplicación.

22

Esta definición se va refinando con el equipo de trabajo mediante entrevistas,

hasta llegar a la lista que se presenta a continuación:

1. Appetite debe permitir generar búsquedas de restaurantes o bares y platos

ofrecidos por los establecimientos.

2. Cuando el usuario realice una búsqueda de algún restaurante o producto,

se debe listar todos los restaurantes relacionados con la búsqueda.

3. Una vez que el usuario realice la búsqueda, podrá seleccionar el

restaurante del listado, y lo re-direcciona a otro listado que estará

compuesto por todos los productos correspondientes al restaurante

seleccionado.

4. Cada ítem del listado de restaurantes estará compuesto por: una imagen

que identifica el Restaurante, el Nombre del Restaurante, la dirección, la

ciudad, y el número telefónico.

5. Una vez que el usuario realice la búsqueda del producto, se listarán todos

los restaurantes relacionados con el producto, y el usuario, podrá

seleccionar el restaurante del listado; esta acción lo re-direcciona a otro

listado que estará compuesto por todos los productos correspondientes al

restaurante seleccionado.

6. Cada ítem del listado de productos estará compuesto por: una imagen que

identifica el producto, el Nombre del producto, el valor del producto, y la

opción de hacer un comentario.

7. Cuando el usuario desee hacer un comentario acerca del producto, podrá

seleccionar la opción de “comentario” en el ítem del listado de los

productos, esta acción lo re-direcciona hacia un listado de comentarios que

han realizado otros usuarios, y en esta misma sesión el usuario podrá hacer

el comentario pertinente.

8. El usuario deberá iniciar sesión, si desea hacer uso del sistema; deberá

ingresar un correo, y una contraseña. Si no posee una sesión en el sistema,

el usuario deberá hacer un registro.

23

9. Cada usuario deberá registrarse en el sistema si no ha creado una sesión,

ingresando los siguientes datos: Nombre completo, Nombre de usuario,

Usuario Twitter, Correo electrónico, Ciudad, Contraseña, Confirmar

Contraseña.

10. En el Menú principal, estará ubicado el buscador; enseguida del buscador

estará una lista despegable que permitirá listar las ciudades registradas en

el sistema, e irán ubicadas cuatro (4) imágenes que ilustrarán publicidad de

promociones de los restaurantes detectados a un perímetro de 600 mts

dentro del entorno del dispositivo, esto trabajará con ubicaciones

geoestacionarias.

11. Cada restaurante, para ser detectado en el entorno del dispositivo, y poder

pautar promociones, debe estar registrado en el sistema, sin necesidad de

hacer el registro de su catálogo.

12. Toda la administración de los datos y recursos, serán manipulados desde

un sistema web.

13. El sistema web deberá permitir crear un nuevo restaurante, hacer

modificaciones al restaurante nuevo, eliminar un restaurante.

14. Cada restaurante, en el momento de crearse desde el sistema, deberá

ingresar: Nombre del restaurante, Dirección del restaurante, Ciudad,

Teléfono, Logo representativo al restaurante.

15. El sistema web deberá administrar el banner de publicidad de promociones

del restaurante que solo desee usar el sistema para pautar publicidad

16. Cada restaurante o bar creado, tendrá la opción de registrar una o más

sucursales dentro del sistema.

17. El sistema web deberá permitir crear un nuevo Producto, hacer

modificaciones al producto ingresado, eliminar un producto.

18. El restaurante podrá crear un producto nuevo y deberá ingresar: Nombre

del producto, Precios del producto, Imagen correspondiente al producto.

24

8.2 DISEÑO DE CASOS DE USO.

Los casos de uso describen los pasos que deben realizarse para el desarrollo de

un proceso. Constan de actores y acciones. Los diagramas de casos de uso sirven

para especificar la comunicación y el comportamiento de un sistema, en este

sistema intervienen tres actores.

Actores.

Usuario

Cliente

Administrador.

Lista de casos de uso.

1. Ingresar al sistema.

2. Buscar Restaurante/Bar/producto.

3. Visualizar productos de restaurantes/Bar.

4. Manipular comentarios sobre productos.

5. Observar Publicidad de promociones.

6. Registrar Usuario.

7. Registrar Restaurante.

Permisos de los actores.

1. Ingresar al sistema.

a. Iniciar sesión (Usuario, Cliente, Administrador).

b. Salir (Usuario, Cliente, Administrador).

2. Buscar Restaurante/Bar/producto.

a. Hacer búsqueda (Usuario, Administrador, Cliente).

b. Seleccionar ciudad (Usuario)

3. Visualizar productos de restaurantes/Bar.

a. Listar restaurante/Bar. (Usuario, Administrador)

b. Listar producto. (Usuario, Cliente, Administrador)

25

4. Manipular comentarios sobre productos.

a. Comentar sobre un producto (Usuario)

b. Visualizar otros comentarios (Administrador, Cliente, Usuario)

c. Eliminar comentario. (Administrador)

5. Observar publicidad.

a. Observar publicidad. (Usuario)

b. Pautar publicidad (Administrador).

c. Eliminar publicidad (Administrador).

6. Registrar Usuario

a. Crear Usuario (Usuario)

b. Modificar Usuario (Usuario)

c. Eliminar Usuario (Usuario)

d. Buscar usuario (Administrador).

e. Listar usuario (Administrador).

7. Registrar Restaurante.

a. Crear Restaurante (Administrador).

b. Modificar Restaurante (Administrador).

c. Eliminar Restaurante (Administrador).

d. Crear Producto (Administrador, cliente).

e. Modificar Producto (Administrador, cliente).

f. Eliminar producto (Administrador, Cliente).

26

8.2.1 MODELO DE CASOS DE USO

FIGURA 4: Modelo de caso de uso general. Realizado en Enterprise

Architect.

27

8.2.2 DESCRIPCIÓN DEL CASO DE USO

TABLA 5. Descripción de caso de uso 1.1

ID MCU-1.1 Prioridad Alta

Nombre Iniciar sesión

Descripción El actor ingresa al sistema ingresando los datos pertinentes para validar el inicio de

sesión.

Autor Catherin Andrea Ochoa Rojas

Fecha creación 24 de Enero 2013 Fecha última

modificación

No aplica

Fuente(s) <Persona(s) y/o documentos que suministraron la información para este caso de

uso

Actores Administrador, Usuario, Cliente.

Precondiciones Haberse registrado en el sistema

Post condiciones Hacer uso del sistema

Flujo normal de eventos

1. El actor ingresa el nombre de usuario y la contraseña de inicio se sesión. 2. El actor presiona el botón “Iniciar sesión”. 3. El sistema capturar la información de las casillas 4. El sistema verifica que no haya casillas vacías. 5. EL sistema valida los datos introducidos con los datos ya almacenados en la base de datos

correspondientes al actor. 6. El sistema inicia la sesión., y muestra al actor la página principal del sistema.

Flujos alternos

4. El sistema verifica que no haya casillas vacías.

se avisa al actor que hace falta llenar información en alguna de las casillas. 5. EL sistema valida los datos introducidos con los datos ya almacenados en la base de datos

correspondientes al actor.

Si no son los mismos datos que ya están almacenados, el sistema notifica al actor que la información introducida esta errónea o que no existe un registro con esos datos.

Excepciones

o <Excepción: cuándo se presenta>

28

<Acciones>

Requerimientos No

Funcionales

<Listado de requerimientos no funcionales relacionados con este caso de

uso>

Anotaciones Caso de uso para el modulo Web, móvil

En ésta tabla se describen todas las características que puede tener un caso de

uso, en esta ocasión se toma el caso de uso 1.1 llamado “Iniciar Sesión”, de

prioridad “Alta” para tener en cuenta al momento de desarrollar, donde describe

que “El actor ingresa al sistema ingresando los datos pertinentes para validar el

inicio de sesión”, se nombra al autor, la fecha de creación y modificación (si aplica)

de este caso de uso. Así como también los “actores”, “condiciones” y “post

condiciones” para poder llevarlo a cabo. Se lista un “flujo normal de los eventos” y

“flujos alternos”, sus “excepciones” y “Requerimientos no funcionales” en caso de

que apliquen, y por ultimo unas “anotaciones” para tener en cuenta.

8.3 MODELACIÓN DE LOS DATOS

Para el almacenamiento de los datos, es necesario tener la estructura de cómo se

guardará esa información en la base. Para ello se realiza un modelo entidad-

relación y relacional. Esto dado a que se utiliza la programación orientada a

objetos.

29

8.3.1 MODELO ENTIDAD-RELACIÓN FIGURA 6. Modelo E-R, realizado en la herramienta Día.

8.3.2 MODELO RELACIONAL FIGURA 7. Modelo Relacional, realizado en la herramienta Día.

30

8.4 MODELO DE INTERFACES

El modelo de interfaces representa la información entre los actores y el sistema. Especifica los detalles de cómo se verán las interfaces de usuario al ejecutar cada uno de los casos de uso.(Weitzenfeld, INGENIERIA DE SOFTWARE ORIENTADA A OBJETOS CON UML. JAVA E INTERNET, 2005)

Registrarse en la aplicación

FIGURA 8. Formulario de registro de usuario, realizado en Pencil y

PhotoScape.

31

Iniciar sesión

FIGURA 9. Vista para iniciar sesión, realizado en Pencil y PhotoScape.

Home (publicidad)

FIGURA 10. Vista principal de la App, donde se muestra la publicidad

geolocalizada, realizado en Pencil y PhotoScape.

32

Restaurantes

FIGURA 11. Listado de restaurantes, realizado en Pencil y PhotoScape.

Productos

FIGURA 12. Listado de productos, realizado en Pencil y PhotoScape.

33

9. CONCLUSIONES.

- Es importante conocer las características de la guía de diseño de Android, y así

poder diseñar una buena interfaz para el producto, teniendo en cuenta que existe

una diversidad de dispositivos móviles en el mercado, en la guía se encuentran las

propiedades para trabajar con cada uno de ellos.

- En la construcción de las interfaces es importante tener en cuenta que al cambiar

la orientación de los dispositivos (de portrait a landscape)1, cambia también la

resolución de las imágenes, por lo que es necesario tener las imágenes con las

características correspondientes a cada una de las orientaciones para no ver la

aplicación distorsionada.

- Tener en cuenta al momento de escoger una metodología de desarrollo propia,

que ésta cumpla con los requisitos mínimos requeridos para culminar la aplicación

con éxito.

- Es esencial tener claridad desde un principio sobre qué es lo que el cliente

quiere que haga la aplicación y los alcances que ésta tiene.

10. RECOMENDACIONES.

- Es importante el compromiso y apoyo del equipo de trabajo al momento de

cumplir con el cronograma asignado para el proyecto.

- Se sugiere para la realización de este tipo de proyectos o semejantes, realizar

una estimación de tiempo de desarrollo, teniendo en cuenta los requerimientos,

alcances y complejidad del mismo.

1Portrait: impresión vertical. Landscape: impresión horizontal.

34

- El acompañamiento por parte de la universidad y asesor son significativos en el

proceso de aprendizaje del practicante.

35

REFERENCIAS

- PÉROCHON, Sébastien. ANDROID: Guía de desarrollo de aplicaciones para

Smartphone y Tabletas. Edición española: Francisco Javier PIQUERES JUAN

Barcelona, Editions ENI – Junio 2012. Pág. 18.

-Libro blanco escrito en mayo de 1996 por James Gosling y Henry Mc Gilton, disponible en http://java.sun.com/docs/white/langenv.

- WEITZENFELD, Alfredo. Ingenieria de Software Orientada a Objetos con Uml. Java E Internet, 2005. Pág. 71.