pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS0930IS02/archivos/SRS_… · Web...

[especificación de requerimientos de software]Una descripción detallada de los requerimientos necesarios para la construcción de un servicio basado en una arquitectura tipo middleware que facilite ofrecer servicios de información y/o publicidad a dispositivos móviles basados en su ubicación geo-referenciada.

2010

AGG-JMM

Andrés Gaitán GalarzaJair Andrés Moreno

ESPECIFICACIÓN DE REQUERIMIENTOS DE SOFTWARE especificación de requerimientos de software

HISTORIAL DE CAMBIOS

Versión FechaSección del documento modificada

Descripción de cambios Responsable

1 8 marzo 2010 1-7 todo

Inicio de temas. Esqueleto. Visión

global.

Andrés Gaitán Jair Moreno

2 12 Revisión 1-7 y2 -2.3

Revisión general de documento.

Complementar el documento.


2.1 15 Revisión 1-7 y2 -2.4

Revisión general de documento.

Complementar el documento.


2.2 18 2.5-2.7 Sección agregadas Andrés Gaitán Jair Moreno

2.3 20 Revisión 1 y 2.1-2.7

Varias secciones modificadas


3 22Revisión 2 y

nueva sección 3 Sección agregada Andrés Gaitán Jair Moreno

3.1 25Revisión 2 y

nueva sección 3 Varias secciones modificadas


3.2 28 Revisión 1, 2 continuación 3

Secciones corregidas y agregadas


3.3 29 Revisión 1, 2 continuación 3

Secciones corregidas y agregadas creación modelo de dominio


3.4 30Revisión 1, 2

continuación 3

Secciones corregidas y agregadas Sección 4

Creación modelo de


2


Versión FechaSección del documento modificada

Descripción de cambios Responsable

caso de uso

3.5 2 abrilRevisión 1, 2

continuación 3y 4


Creación modelo de caso de uso


3.6 3 abrilRevisión 1, 2

continuación 3y 4


Creación de varios requerimientos y documentación de caso de uso


Tabla 1: Historial de cambios

3


Contenido

Contenido

HISTORIAL DE CAMBIOS........................................................................................................................ 2

CONTENIDO.............................................................................................................................................. 4

1 DEFINICIONES, ABREVIACIONES Y ACRÓNIMOS......................................................................................6

2 INTRODUCCIÓN...................................................................................................................................... 9

2.1 PROPÓSITO.................................................................................................................................................9

2.2 ALCANCE....................................................................................................................................................9

2.3 APRECIACIÓN GLOBAL.................................................................................................................................12

3 DESCRIPCIÓN GLOBAL........................................................................................................................... 13

3.1 PERSPECTIVA DEL PRODUCTO.......................................................................................................................13

3.2 INTERFACES CON EL SISTEMA........................................................................................................................14

3.3 INTERFACES CON EL USUARIO........................................................................................................................16

3.4 INTERFACES CON EL HARDWARE....................................................................................................................18

3.5 INTERFACES CON EL SOFTWARE.....................................................................................................................19

3.6 INTERFACES DE COMUNICACIÓN....................................................................................................................20

3.7 RESTRICCIONES DE MEMORIA.......................................................................................................................20

3.8 OPERACIONES............................................................................................................................................21

3.9 FUNCIONES DEL PRODUCTO.........................................................................................................................21

3.10 CARACTERÍSTICAS DEL USUARIO..................................................................................................................23

3.11 RESTRICCIONES........................................................................................................................................24

3.12 MODELO DEL DOMINIO.............................................................................................................................24

3.13 DISTRIBUCIÓN DE REQUERIMIENTOS............................................................................................................25

4 REQUERIMIENTOS ESPECÍFICOS............................................................................................................ 26

4.1 REQUERIMIENTOS DE INTERFACES EXTERNAS...................................................................................................26

4.1.1 Interfaces con el Usuario................................................................................................................26

4.1.2 Interfaces con el Hardware............................................................................................................26

4.1.3 Interfaces con el Software..............................................................................................................26

4


4.1.4 Interfaces de Comunicaciones........................................................................................................26

4.2 CARACTERÍSTICAS DEL PRODUCTO DE SOFTWARE..............................................................................................27

4.3 REQUERIMIENTOS DE DESEMPEÑO................................................................................................................33

4.4 RESTRICCIONES DE DISEÑO..........................................................................................................................34

4.5 ATRIBUTOS DEL SISTEMA DE SOFTWARE.........................................................................................................35

4.5.1 Disponibilidad.................................................................................................................................35

4.5.2 Seguridad.......................................................................................................................................36

4.5.3 Mantenibilidad y reusabilidad........................................................................................................36

4.5.4 Usabilidad......................................................................................................................................38

4.6 REQUERIMIENTOS DE LA BASE DE DATOS.........................................................................................................38

DISEÑO DE BASE DE DATOS................................................................................................................................39

5 ANEXOS................................................................................................................................................ 40

6 REFERENCIAS – BIBLIOGRAFÍA- INDICE DE TABLAS................................................................................54

5


1 Definiciones, abreviaciones y acrónimos

AGG-JMM: hace referencia a la asociación entre los estudiantes de Ingeniería de Sistemas

la Pontificia Universidad Javeriana llamados Andrés Gaitán Galarza y Jair Andrés Moreno

Muñoz

API: (application programming interface) programación de la interface en una aplicación

Según la revista Pc Magazine, es el formato de lenguaje y mensajes usando en una

aplicación de un programa para comunicarse con un sistema operativo, un protocolo de

comunicación, base de datos u otro. [PCMA 1996] (1)

CRUD: se refiere en ingles (CREATE, RETRIEVE, UPDATE, DELETE) a las funciones

de crear, recuperar, actualizar y eliminar.[WEBO 2010] (2)

Framework: término usado en programación orientada a objetos para definir un conjunto

de clases que definen un diseño abstracto para solucionar un conjunto de problemas

relacionados. También, puede ser una estructura de conceptos que pretenden ser un soporte

o guía para la construcción de un algo que expanda la estructura misma de forma útil.

[WHAT 2008] (3)

Galileo: Según la agencia espacial europea[ESA 2000] (4) , es un GNNS el sistema global

de navegación por satélite desarrollado por la unión europea.

GNNS: es referente a un sistema global de navegación por satélite (global navigation

satellite system) que provee posicionamiento geo espacial con cubrimiento global como

GPS, Galileo y GLONASS.[IGS 2010] (5)

GNU GPL: General Public License o licencia pública general. [GNU 1996] (6)

GNU: Es un acrónimo recursivo que significa "GNU No es Unix".

GPS: es el GNNS, sistema global de navegación por satélite, más conocido y difundido

alrededor del mundo. Inicialmente llamado NAVSTAR-GPS (global positioning system) y

permite detectar la posición de un objeto con precisión de unos metros o centímetros si se

usa GPS diferencial.[GPS 1999] (7)

GSM: es el estándar más popular para los teléfonos móviles; el sistema global para las

comunicaciones móviles (global system for mobile comunication) antes llamada Groupe

spéciale mobile.[GSMA 2010] (8)

6


GUI: (graphical user interface). Sistema de interacción entre el ordenador y el usuario,

caracterizado por la utilización de iconos y elementos gráficos en su concepción. Es un

paso más allá de los interfaces basados en caracteres, que sólo incluían líneas de texto para

introducir comandos y conocer las respuestas del sistema.[TLIP 2004] (9)

KML: KML es un formato de archivo que se utiliza para mostrar información geográfica en

navegadores terrestres como Google Earth, Google Maps y Google Maps para móviles.

KML utiliza una estructura basada en etiquetas con atributos y elementos anidados y está

basado en el estándar XML. (10)

LBS: Son los sistemas basados en localización (located based systems).Según Küpper

[KUPP 2006] (11)También son conocidos cómo servicios móviles basados en contenidos

sensibles a la localización, LDIS (location dependant information services), PALMS

(privacy-Aware location-based mobile services), spatial location based services, servicios

basados en ubicación y servicios anytime-anywhere.

Middleware: Es un software de conectividad que ofrece un conjunto de servicios que hacen

posible el funcionamiento de aplicaciones distribuidas sobre plataformas heterogéneas.

[RYME 1996] (12) y[PUEN 2005] (13)

OS: Sistema operativo, (operating system), es el software de un dispositivo electrónico

que es el intermediario de la interfaz entre el hardware y el usuario. Este es el encargado de

gestionar y coordinar todas las actividades y recursos de un computador, dispositivo móvil

entre otros.[PCMA 1996] (14)

SmartPhone: Teléfonos inteligentes, representa los celulares de gama alta, los cuales

poseen varias características como conectividad a Internet, instalar nuevos programas,

pantallas táctiles entre otros. BlackBerry e Iphone son algunos ejemplos de estos

dispositivos móviles.[PCMA 1996] (15)

SRS: Software Requirement Specification ,especificación de requerimientos de software.Es

un documento de una organización para entender el sistema de requerimientos y todas sus

7


dependencias (para un cliente potencial ) de un aspecto en particular en un momento dado

previo al actual diseño o desarrollo de un proyecto de software.[TECH 1997] (16)

Tecnología Pull: Está tecnología la utiliza cuando el usuario inicia la acción con su

navegador de visita cualquier sitio web con el fin de “tirar o jalar” información.[XU et AL

2009] (17)

Tecnología Push: A diferencia de la tecnología pull, el usuario no es el que inicia la acción

sino que la información “viene” al usuario sin la necesidad de solicitar cierta información.

[XU et AL 2009] (17)

S.M.A.R.T.: hace referencia en inglés a objetivos específicos (specific), medibles

(measurable), alcanzables (achievable), realistas (realistic), a tiempo (timely) que son

indicadores clave de desempeño para alcanzar las funcionalidades en un proyecto de

software. (18)

8


2 Introducción

2.1 Propósito

El objetivo de este documento es establecer una descripción detallada de los requerimientos

necesarios para la construcción de un servicio basado en una arquitectura de tipo middleware que

ofrezca servicios de información y publicidad a dispositivos móviles basados en su ubicación

geo-refenciada.

Rymer [RYME 1996] (12) explica que un " … middleware es el software que le permite a los

elementos de una aplicación a poder interoperar a través de enlaces de redes, a pesar de grandes

diferencias en la comunicación de protocolos, sistemas de arquitecturas[sistemas operativos], base

de datos y otros servicios de aplicaciones". Y para Puentes [PUEN 2005] (13) hace referencia al

“término usado para referirse a los componentes de software que actúan como intermediarios entre

otros componentes de software, generalmente, en el marco de la interacción cliente/servidor.”

El documento propone realizar una descripción de la funcionalidad, los actores y flujos de acciones

involucrados en el sistema y una perspectiva global de lo que será el producto. También permitirá

dejar en claro las condiciones y términos técnicos necesarios para proceder con la fase de diseño del

proyecto de trabajo de grado realizado por los estudiantes Andrés Gaitán Galarza y Jair Moreno

Muñoz y dirigido por el Ingeniero Javier Francisco López de la Pontificia Universidad Javeriana.

2.2 Alcance

Este documento está centrado hacia la prueba de una arquitectura realizada a partir del trabajo de

grado llamado “Construcción de una arquitectura que provea servicios de información y/o

publicidad a dispositivos móviles basados en su ubicación geo-referenciada”.

9


Es importante indicar que los socios AGG-JMM definieron como caso de estudio a LBS enfocados

en la personalización de los servicios de parqueaderos públicos o privados en la ciudad de Bogotá.

Algunas características que podrían marcar la diferencia de sus competidores es la obtención de

información detallada y actualizada constantemente como:

¿Existe cupos actualmente en X parqueadero?

¿Cuáles son sus características de espacio?

¿El espacio para parquear es amplio o estrecho?

¿Presenta buena señalización?

¿Es necesario dejar las llaves?

¿Ofrece servicio de valet parking y cuáles son sus características?

¿Existe algún tipo de seguridad dentro del parqueadero?

¿Ofrece parqueo para motos, bicicletas?

o ¿Existe cupo en este momento?

o ¿Cuáles son estas tarifas?

¿Posee algún tipo de descuento o precio especial para clientes con un perfil especifico?

Por otro lado, este proyecto producirá un acuerdo a los requerimientos exigidos por el cliente y

pretende beneficiar a todas las empresas interesadas en ofrecer publicidad e información de sus

negocios, a los socios AGG-JMM y a los usuarios de dispositivos móviles; su propósito es el hecho

de ofrecer un servicio modelo en base a la localización de un usuario, utilizando un enfoque hacia

una arquitectura tipo middleware y asegurando una mayor penetración de LBS en el mercado de los

dispositivos móviles en Colombia.

10


En cuanto a las funciones que se realizarán en este producto son:

Corroborar el funcionamiento entre la aplicación LBS, middleware y la plataforma

empresarial, haciendo énfasis en las necesidades de los proveedores de servicios,

desarrolladores y arquitectos de software de LBS.

Permitir la interoperabilidad de datos entre diferentes plataformas de hardware haciendo

uso de software de cartografía en los dispositivos móviles.

Las funcionalidades que no pretende y no garantiza desarrollar en el producto son:

Poseer una arquitectura eficiente en el comportamiento de uso tiempo y recursos.

Poseer una alta confiabilidad (reliability) como es la madurez, la tolerancia a fallas y la

capacidad de recuperación de algún componente de la arquitectura.

Disminuir la latencia y la fluctuación en la comunicación entre componentes.

Por último, este proyecto es importante para AGG-JMM ya que su principal objetivo es fomentar su

propio aprendizaje, instruirse en uno de sus temas favoritos en los sistemas de información

geográficos, los servicios basados en la localización, y poder optar por el título de Ingeniero de

Sistemas en la Pontificia Universidad Javeriana. Por todas estas razones se busca desarrollar un

producto novedoso, aplicable e interesante para la comunidad.

11


2.3 Apreciación Global

En la primera parte de este documento, se ha presentado una corta introducción al mismo y al

proyecto en sí. En el siguiente capítulo se hace una descripción general del proyecto, con sus

funciones, especificaciones y características del proyecto mismo y de sus futuros usuarios.

En el capítulo 3 se presenta una especificación detallada de requerimientos que son necesarios para

el desarrollo e implementación del diseño de la arquitectura tipo middleware para el software,

hardware, requerimientos de rendimiento, restricciones de diseño y descripciones detalladas del

producto.

Finalmente en los últimos capítulos y apartes del documento se encuentra la información

complementaria referente a las demás partes del documento.

12


3 Descripción Global

3.1 Perspectiva del Producto

Este producto creado por la asociación AGG-JMM está enfocado hacia las empresas que poseen un

parqueadero público en la ciudad de Bogotá (como son Park Elite, Aparcar, parking international

entre otros) y desean suministrar servicios de información y /o publicidad en los dispositivos

móviles. De igual forma, este LBS está creado para el usuario que posee un teléfono celular (con

características definidas en las secciones siguientes) y desee obtener información y/o publicidad de

modo predefinido. Este tipo de personalización para estos servicios responde a las preguntas

mencionadas en el alcance, dónde un usuario contacta a la asociación AGG-JMM para usar este

servicio y enseguida crea un perfil de acuerdo a cómo desea obtener la información y servicios de

los parqueaderos públicos en Bogotá.

Este diseño del producto es completamente nuevo, y pretende crear beneficios para este tipo de

empresas, usuarios y la asociación misma llamada AGG-JMM. Además, el propósito de este

diseño es ofrecer otro acercamiento a la industria del desarrollo de arquitecturas para middlewares

que ofrecen este tipo de LBS similares a este; dónde la arquitectura tiende a personalizar el perfil de

cada cliente de acuerdo a unas características previamente definidas.

Por último, este tipo de arquitectura no parte de una ontología nueva sino que busca contribuir al

desarrollo de estas arquitecturas a partir de otro enfoque. El documento “estado del arte de los

servicios basados en la localización” (anexo 4) establece como se ha caracterizado la construcción

de este tipo de software a lo largo de estos últimos años.

13


A nivel general, el middleware consiste en los siguientes componentes:

Ilustración 1: Componentes de un middleware

Básicamente existen 3 componentes principales en el sistema estos son las aplicaciones de

servicios, el middleware y la plataforma. Las aplicaciones de servicios son referentes a los LBS que

van a ser gestionados por el componente middleware, para así poder comunicarse con la

plataforma. Está última puede estar fuertemente sujeta al sistema operativo y este a su vez a los

dispositivos móviles y su red.

3.2 Interfaces con el sistema

El servicio que provee la arquitectura middleware AGG-JMM es un producto nuevo, sin embargo el

middleware es un componente que gestiona las funciones de las aplicaciones LBS con la plataforma

de un dispositivo móvil. Es decir, el sistema del software debe poder adaptarse y permitir la

interoperabilidad entre cada componente interno tanto de las aplicaciones como el de la plataforma.

Por ejemplo, pueden surgir casos en que existan dos sistemas heterogéneos que se desean

comunicar pero tienen un lenguaje de programación del sistema operativo diferente, lo cual

proporcionar los servicios que se soliciten. En este caso, una solución podría ser CORBA (Common

14

APLICACIONES LBS

MIDDLEWARE

SISTEMA OPERATIVO

DISPOSITIVO MÓVIL


Object Request Broker Architecture), que es una arquitectura que permite que dos aplicaciones en

diferentes lenguajes puedan interactuar.

En este caso, el servicio para este middleware se relaciona con las interfaces del sistema de acuerdo

a como se describe en la siguiente ilustración

Ilustración 2 : Interfaces con el sistema

El sistema de AGG-JMM se compone principalmente por

Un servidor web, que se encarga de transferir las páginas web a los clientes de la

arquitectura empresarial.

Un servidor de aplicaciones, que se encarga de la lógica del negocio.

Un servidor de almacenamiento, quién se encarga de guardar los datos personalizados de

los clientes en formato KML.

15


Un servidor de base de datos geo-espacial, quién se encarga de guardar los datos

geográficos de los puntos de interés.

Por otro lado, el sistema AGG-JMM se relaciona con el sistema de

Servicios geográficos quién es el encargado de suministrar los datos geográficos y

geocodificados a partir de una cartografía, en este caso es Google quien provee este tipo de

información por medio de Google Maps.

Sistema empresa, la cual representa a todos las empresas que ofrecen servicios de

parqueaderos públicos en la ciudad de Bogotá.

Sistema externo, quién son los usuarios que poseen un teléfono celular y están suscritos al

LBS de parqueaderos de AGG-JMM.

.

3.3 Interfaces con el usuario

Las interfaces que son de interacción con el usuario final, es decir el cliente que posee un teléfono

celular y ha adquirido los servicios ofrecidos por AGG-JMM, son las interfaces de un navegador

(Firefox, Opera, Safari, Internet Explorer, entre otros) que son accedidas desde un computador

que posea conexión a internet, con el fin de acceder a la página web de AGG-JMM, dónde crea un

perfil el usuario.

Por otro lado, las otras interfaces con el usuario son en base a las características referentes al

formato y estilo de presentación según la versión y modelo del teléfono celular. El LBS de

parqueaderos interactúa con esta interfaz del usuario por medio de la aplicación de Google Maps

del teléfono celular. Algunas de estas cuestiones para los teléfonos celulares son:

La interfaz será manipulada con un teclado estándar QWERTY o por interfaz tipo Touch

Screen.

16


Para la entrada de datos se usaran campos de texto, cajas de selección múltiple (combo-

boxes), cajas de selección y se diligenciará la entrada mediante la confirmación con un

botón de acción para la función seleccionada.

El tiempo de respuesta del servidor a las acciones del usuario tendrá como criterios

o Velocidad de conexión a internet en el dispositivo móvil.

o Velocidad del hardware y el soporte del dispositivo móvil para diferentes

tecnologías de posicionamiento como GPS

o Número de usuarios simultáneos haciendo uso del servicio

Para la correcta implementación de la interfaz de usuario se hará un análisis previo del formato

suministrado por la aplicación LBS del dispositivo móvil lanzando excepciones como:

Las entradas del sistema para los campos que requieran cantidades numéricas tendrán

evaluación del formato, revisando que no se ingresen letras o números negativos, de

presentarse estos se arrojará un mensaje de error explicando el hecho y se pedirá el

reingreso del valor en ese campo.

Las entradas de sistema para los campos que requieran una cantidad máxima y/o mínima de

caracteres y se les digite contenido que viole estas restricciones, la interfaz arrojará un

mensaje de error explicando el hecho y se pedirá el reingreso del valor en este campo.

Para las entradas del sistema, se tienen unos requerimientos de llenado de campos, de

faltar la diligencia de uno de estos campos, la interfaz arrojará un mensaje de error

explicando el hecho y pedirá el ingreso del valor requerido en el campo, arengándose a las

anteriores dos restricciones.

En cuanto a la interfaz GUI, está será realizada creando una capa sobre la cartografía ofrecida

mediante el API versión 4 de Google Maps para su desarrollo.

17


3.4 Interfaces con el Hardware

Las interfaces de hardware muestran como interactúa el hardware y el sistema para su correcto

funcionamiento. El software de la aplicación LBS tendrá que interactuar con el teléfono celular

donde se encuentra implementada dicha aplicación y con el servidor que se va a utilizar para

almacenar el middleware. Por otro lado, los socios AGG-JMM, quienes serán los desarrolladores

de la arquitectura y encargados de la información sobre el LBS, no estarán involucrados en trabajar

directamente con el hardware del dispositivo móvil en la cual se ejecutará la aplicación LBS.

El protocolo que se considera usar para la comunicación entre LBS, middleware y plataforma es el

protocolo de red TCP/IP explicado en detalle en el RFC 791, y traducido al español Ponce de

León[PONC 1999] (19) Este fue elegido debido a que es un mecanismo de transporte confiable y

orientado a conexión evitando la recepción de paquetes incompletos o dañados; además soporta la

comunicación full-dúplex y el envío y recepción de datos es de forma asincrónica (20)[TANE 2003]

Además soporta diversas tecnologías de comunicación en los celulares como EDGE, GSM, UMTS,

WI-FI y WIMAX entre otros que fueron descritos en el anexo 4 ( estado del arte de los servicios

basado s en la localización). Sin embargo, cabe mencionar que al implementar la red se realizarán

pruebas de velocidad y trafico y según estas, si el protocolo no cumple con los requerimientos de

dichas pruebas se podría pasar a un protocolo UDP, referido en el RFC 768 traducido al español

por Sánchez Ruiz [SANC 1999] (21), sacrificando confiabilidad frente a velocidad.

En cuanto a los puertos, la aplicación usará el puerto TCP 55600 ya que este puerto se encuentra

entre los puertos 49152 y 65535 que están reservados para aplicaciones privadas y por otra parte en

la lista completa de los números registrados para los puertos UDP y TCP publicados por la

organización IANA [IANA2010] (22) este puerto no ha sido asignado a ninguna otra aplicación.

18


3.5 Interfaces con el Software

Las interfaces con las que actuará el sistema pueden ser por parte de la aplicación LBS, por parte

del middleware y por parte del sistema operativo en cada celular.

En cuanto a la interfaz con el sistema operativo de los dispositivos móviles se pretende utilizar el

OS Symbian con el fin de mostrar la funcionalidad de la arquitectura propuesta. Sin embargo, es de

aclarar que la arquitectura middleware será independiente del sistema operativo a utilizar.

A continuación se muestran las interfaces de software con las que interactuara el sistema:

Symbian J2ME .NET

Descripción La plataforma de Symbian es ampliamente usada en la mayoría de dispositivos móviles inteligentes

Las tecnologías J2ME contienen un JRE altamente optimizado desarrollado para el mercado de gran consumo, abarcan una amplia gama de dispositivos móviles, con el fin de llevar muchas herramientas y tecnologías a soluciones JAVA.

Es una plataforma de desarrollo de software con énfasis en transparencia de redes, con independencia de plataforma de hardware y que permite un rápido desarrollo de aplicaciones.

Propósito de uso

Es el sistema operativo más difundido y conocido en los dispositivo móvil y asegura un alto número de participantes

La aplicación LBS podría utilizar el lenguaje de desarrollo JAVA ya que la mayoría de teléfonos celulares lo soportan incluido los diferentes API

Al surgir la posibilidad de utilizar Web Services para gestionar el middleware, .net es una buena solución ya que dispone de manera rápida y segura de desarrollar aplicaciones de este tipo

Versión Versión 4 4.0 Microsoft Visual Studio 2008

19


Fuente Symbian, desarroladoreshttp://developer.symbian.org/

Sun microsystemshttp:// JAVA .sun.com/ products/personalprofile/download.html

Microsofthttp://msdn.microsoft.com/es/co/netframework/default.aspx

Comentarios adicionales

La aplicación podría funcionar en otros sistemas operativos y no es dependiente de uno específico.

JAVA permite que un único desarrollo se ejecute en sistemas operativos que soporten la máquina virtual en teléfonos celulares

Tabla 2: Interfaces de software

3.6 Interfaces de Comunicación

El middleware será accedido de manera implícita por el usuario final, a través de una comunicación

por internet. El protocolo de comunicación a usar es TCP/IP [PONC 1999] (19) (por las razones ya

descritas en 3.4) y sobre este protocolo se manejará un sistema Web definido por protocolos de la

World Wide Web Consortium [w3c2010] (23). Este sistema de red maneja una serie de sockets e

hilos que recibirán la conexión y darán servicios a cada comunicación requerida.

3.7 Restricciones de Memoria

Para el funcionamiento de este servicio se establecen dos sistemas principales:

Middleware: Para el middleware ofrecido por AGG-JMM se requiere un equipo capaz de

ejecutar simultáneamente un servidor web APACHE, una base de datos ORACLE y el

20

http://msdn.microsoft.com/es/co/netframework/default.aspx



http://java.sun.com/products/personalprofile/download.html



http://developer.symbian.org/




servidor de aplicaciones GLASSFISH, con lo cual sumando los requerimientos mínimos de

memoria para estas aplicaciones da como resultado un sistema con 4GB de memoria RAM.

Dispositivo móvil: Para la correcta ejecución de la aplicación Google Maps en el

dispositivo móvil no se tienen datos concretos. Sin embargo, se tiene como dato que el

consumo de memoria en un Nokia 5800 es de 5.8 MB de memoria RAM y en un HTC

Droid es de 12.2 MB de memoria RAM ocupadas.

3.8 Operaciones

Como en todos las aplicaciones LBS, los usuarios esperan que cada aplicación esté funcionando las

24 horas al día, 7 días a la semana disponible, y que en lo posible no haya ninguna clase de

problema. Esto en la práctica es imposible, así que en los momentos en que la aplicación no esté

activa se avisa a los usuarios que el servicio no estará temporalmente disponible durante cierto

periodo de tiempo.

En estos momentos se hará mantenimiento de emergencia o alguna modificación requerida a la

aplicación y con el consiguiente respaldo de la información en caso de ser necesario. Para la

aplicación LBS de prueba, se espera como prioridad demostrar su funcionalidad para validar la

arquitectura propuesta y no garantizar un producto perfecto.

3.9 Funciones del Producto

Todas las funciones del producto se pueden observar de manera clara en el diagrama de casos de

uso, anexo 1, junto a su correspondiente documentación para cada uno de los stakeholders; de

igual forma el modelo de dominio, anexo 3, lo ubica en el contexto mencionado.

21


Las principales funciones del producto son:

La empresa puede comprar servicios de publicidad de su negocio de parqueaderos públicos

en Bogotá para pautar en Google Maps.

La empresa puede comprar servicios de información para promocionar su negocio de

parqueaderos públicos en la ciudad de Bogotá a través de Google Maps.

El usuario puede adquirir el servicio de información y publicidad personalizado de

parqueaderos públicos en Bogotá suministrados por los socios AGG-JMM, a través del

mapa de Bogotá en Google Maps.

El usuario puede crear un perfil acerca de las categorías y las características que desee de

los parqueaderos públicos en Bogotá.

AGG-JMM puede asignar publicidad o información de una empresa de parqueaderos de

Bogotá a través de Google Maps.

AGG-JMM pueden personalizar la información de cada cliente suscrito a su servicio para

luego ofrecer su LBS de parqueaderos públicos

Funciones que no realiza este servicio:

No permite hacer uso del servicio de AGG-JMM sin conexión a Internet.

No permite tener acceso desde un dispositivo móvil con capacidad limitada dentro de los

requerimientos de memoria y los requerimientos de interfaces del sistema especificados.

No permite ofrecer los servicios de información y publicidad por el cual el usuario del

dispositivo móvil no los adquirió.

3.10 Características del Usuario

22


A continuación se describe las características de los posibles usuarios en la aplicación LBS de AGG-

JMM siguiendo la tabla de la plantilla de IronWorks [IRON 2007] (24)

Características del Usuario

Descripción

Nivel de Seguridad o de Privilegios

Solo puede acceder a funciones de caso de uso 1-3, 21

Roles Usuario que posee un teléfono celular con los requisitos (del numeral 3.11) y pagó por el servicio de parqueaderos en Bogotá de AGG-JMM

Nivel de Estudios o Experiencia Técnica

El usuario no debe tener algún tipo de conocimiento específico, solo comprender la aplicación de Google Maps para disfrutar de ella

Frecuencia de Uso El usuario puede usar el servicio desde que se suscribió a él y utilizarlo cuantas veces quiera hasta el fin de su suscripción con AGG-JMM

Características del Usuario

Descripción

Nivel de Seguridad o de Privilegios

Solo debería acceder a funciones de caso de uso 4-6, 8, 9, 13-16 pero podría acceder a las funciones del usuario

Roles Es la asociación AGG-JMM de un parqueadero público que ofrece el LBS de parqueaderos públicos en Bogotá .Es el administrador y posee cualquier privilegio

Nivel de Estudios o Experiencia Técnica

Como la asociación AGG-JMM se conforma por los mismos desarrolladores de este producto, poseen una alta experiencia en este servicio

Frecuencia de Uso Siempre estará disponible

Tabla 3 : Características del usuario [IRON 2007] (24)

3.11 Restricciones

Las restricciones además de las mencionadas en el numeral 2.1 de perspectiva del producto, son las

siguientes:

23


1. Limitaciones de hardware y software: Cada dispositivo móvil que haga uso de los

beneficios de la aplicación Google Maps, deberá contar con los requisitos descritos

anteriormente en interfaces de hardware y restricciones de memoria.

2. Protocolos: Se requiere un dispositivo móvil con capacidad de acceder a redes de datos y

posibilidad de transmitir sobre TCP/IP.

3. Se establece que los socios AGG-JMM usarán este producto con fines académicos no

comerciales y no infringirá en las condiciones de servicio de Google Maps, anexo 2.

3.12 Modelo del Dominio

Véase el correspondiente anexo 3 acerca del modelo de dominio.

Los teléfonos celulares, los PDA, los laptops entre otros son dispositivos móviles que utilizan los

LBS. Estos últimos se benefician por servicios de cartografía como son Bings Maps, Yahoo Maps,

Google Maps, mapas publicar entre otros que utilizan el concepto de geolocalización. Sin embargo

es el cliente quien posee un dispositivo móvil y disfruta de los LBS´s.

Por otro lado la asociación AGG-JMM es la encargada de vender su servicio al cliente, ofrecerle

servicios de información o servicios de publicidad y al mismo tiempo negociar con una o varias

empresas que desean estos servicios. Así AGG-JMM desarrolla un middleware que está en servidor

gestionado por él mismo y cualquier empresa suministra la información necesaria al middleware

para el gestionamiento del LBS.

3.13 Distribución de Requerimientos

24


No se distribuirán o aplazarán los requerimientos debido a la especificación de requerimientos

otorgados por los socios AGG-JMM para la realización de trabajo de grado titulado “Construcción

de una arquitectura que provea servicios de información y publicidad a dispositivos móviles

basados en su ubicación geo-referenciada”; todos los requerimientos especificados serán

implementados y entregados en el producto resultado de este proyecto.

25


4 Requerimientos Específicos

4.1 Requerimientos de Interfaces Externas

4.1.1 Interfaces con el Usuario

Los requerimientos de interface de usuario se encuentran registrados en detalle en la sección

2.1.2

4.1.2 Interfaces con el Hardware

Los requerimientos de interface de usuario se encuentran registrados en detalle en la sección

2.1.3.

4.1.3 Interfaces con el Software

Los requerimientos de la interfaz de usuario se encuentran registrados en detalle en la sección

2.1.4.

4.1.4 Interfaces de Comunicaciones

Los requerimientos de la interfaz de usuario se encuentran registrados en detalle en la sección

2.1.5.

26


4.2 Características del Producto de Software

En el LBS para los parqueaderos ofrecido por AGG-JMM, se identifican 3 tipos de stakeholders:

Los desarrolladores: representan los socios llamados AGG-JMM quienes se

responsabilizan por brindar todos los servicios de información y publicidad de esta

categoría de empresas hacia una personalización de la plataforma de Google Maps.

Las empresas: son todas las compañías que ofrecen bienes y servicios y desean

establecer cualquier tipo de información y publicidad en dispositivos móviles del

Website de Google Maps.

Los clientes: son las personas que poseen un dispositivo móvil y adquirieron un LBS

con personalizaciones de algunas empresas en Google Maps.

El documento de casos de uso, anexo 1, se observa cómo se relacionan estos stakeholders

principales

A continuación, se describe los requerimientos que especifican más en detalle las características

del producto de software.

Esta documentación de requerimientos está basada en la plantilla de Volere [VOLE 2005] (25),

la cual presenta un posible formato que permite especificar los requerimientos funcionales de

manera que se cumpla con las características descritas en los puntos anteriores.

(En el caso de la prioridad se asignará de 1 a 5 siendo 5 la prioridad más alta).

#requerimiento 1Tipo de requerimiento

negocio

Casos de usos asociados

A9-A12

DescripciónLa empresa debe ser capaz de registrar, desactivar, recuperar y modificar un parqueadero público en el sistema.

RazónLa empresa debe ser el que gestiona tanto la entrada como la salida de un nuevo parqueadero

Autor Desarrollador, arquitectoCriterio de medición Cualquier modificación en el sistema será

ajustada al momento de cargar el mapaPrioridad 5 Modulo

asociadoBase de datos

Versión 1 Fecha 13 abril

27



Negocio


A13-A16

DescripciónEl cliente debe ser capaz de registrar, desactivar, recuperar y modificar un usuario suscrito a un servicio LBS ofrecido por AGG-JMM

Razón Es el cliente quien necesita realizar estas operación Desarrollador, arquitecto

Criterio de medición El cliente tendrá acceso al sistema con su usuario recién creado

Prioridad 5 Modulo asociado

Base de datos



Negocio


A1

DescripciónEl usuario debe poder consultar el mapa general de Google Maps sin ningún contratiempo asociado a la aplicación LBS

RazónEl usuario con o sin el servicio LBS debe poder utilizar el servicio que brinda Google Maps

Autor Desarrollador, arquitectoCriterio de medición El usuario puede consultar el mapa de

Google Maps en su dispositivo móvilPrioridad 5 Modulo

asociado SistemaVersión 1 Fecha 13 abril


Negocio


A4

DescripciónEl usuario debe poder consultar en detalle y de acuerdo a su personalización un parqueadero público específico escogido en el mapa de Google Maps

RazónEl usuario se inscribió al servicio LBS de parqueadero públicos en Bogotá, por lo tanto debe poder utilizar dicho servicio ofrecido por AGG-JMM

Autor Desarrollador, arquitecto

28


Criterio de medición El usuario puede consultar el mapa de Google Maps en su dispositivo móvil

Prioridad 5 Modulo asociado sistema



Negocio


A3

Descripción

El usuario debe poder ejercer una personalización en el servicio LBS asociado a los parqueaderos públicos en Bogotá; por lo tanto debe poder hacer varios filtros de los tipos de parqueadero como tarifas bajas, servicio de valet parking, descuentos entre otros.

Razón

El usuario se suscribió por el servicio LBS de parqueadero públicos en Bogotá, por lo tanto existe una personalización de acuerdo a su perfil registrado en el Website de AGG-JMM


Criterio de mediciónEl usuario puede consultar únicamente los parqueaderos públicos en Bogotá a través de Google Maps que fueron tomados en cuenta en el perfil de la cuenta asociada




Negocio


A4

DescripciónEl sistema crea un archivo personalizado de extensión KML dependiendo de las características de un perfil de un usuario específico.

RazónEl sistema debe de alguna manera personalizar las preferencias de un usuario en particular para el servicio LBS de parqueadero públicos en Bogotá,

Autor Desarrollador, arquitectoCriterio de medición El administrador puede crear un archivo y

29


reflejar sus cambios a diferentes características para un parqueadero específico




Usuario


A6

DescripciónEl administrador debe poder generar algún tipo de estadística general de todos los usuarios y empresas que usen uno o varios servicios LBS ofrecidos por AGG-JMM

RazónLa asociación AGG-JMM le interesa conocer a cabalidad cómo está gestionando sus servicios tanto a empresas como a usuarios


Criterio de medición

El administrador puede crear un informe o estadística de información de consulta de diferentes usuarios suscritos a un servicio de LBS como es el de parqueaderos público en Bogotá.




Usuario


A5

Descripción

El administrador debe poder generar algún tipo de estadística de todos los usuarios que usan un servicio LBS ofrecido por AGG-JMM y que pertenecen a información o publicidad para cierta empresa específica

RazónLas empresas desean conocer todo tipo de información relacionada a sus clientes como son sus preferencias e intereses

Autor Desarrollador, arquitectoCriterio de medición El administrador puede crear un informe o

estadística de información de consulta de

30


diferentes usuarios y empresas suscritos al servicio de LBS como son los parqueaderos público en Bogotá.




negocio


A7

DescripciónLa asociación AGG-JMM de estar en la capacidad de geocodificar la localización del negocio que desea crear servicios de información y publicidad

Razón

La localización de cada establecimiento debe estar en coordenadas geoespaciales adecuadas; en latitud longitud en el sistema AGG-JMM; para el usuario final debe incluir la dirección


Criterio de mediciónUna empresa específica se pudo o no poner en contacto con la asociación AGG-JMM para lograr una negociación de servicios de información o publicidad de su negocio

Prioridad 2 Modulo asociado negocio


Nota: este requerimiento no será tratado en el caso del prototipo con Google Maps


negocio


A7

DescripciónLa empresa puede comprar algún tipo de publicidad o servicio de información de su negocio por medio de la asociación AGG-JMM

Razón

Uno de los mayores atractivos para cualquier empresa es ofrecer sus bienes y servicios y fomentar la publicidad de su negocio para conseguir un mayor éxito en ventas

Autor Desarrollador, arquitectoCriterio de medición Una empresa específica se pudo o no poner

31


en contacto con la asociación AGG-JMM para lograr una negociación de servicios de información o publicidad de su negocio

Prioridad 1 Modulo asociado Empresa



negocio


A7

Descripción El usuario debe ser capaz de adquirir el LBS de parqueaderos públicos en Bogotá.

RazónUn usuario puede adquirir algún LBS como el de parqueadero públicos en Bogotá, por diversas razones como mejorar su estilo de vida

Autor Desarrollador, arquitectoCriterio de medición El usuario pudo o no contactarse con la

asociación AGG-JMM Prioridad 1 Modulo

asociado UsuarioVersión 1 Fecha 13 abril


negocio


A7

DescripciónEl administrador debe ser capaz de asignar publicidad o información de una empresa específica de parqueaderos públicos en Bogotá.

Razón Es una tarea fundamental para poder ofrecer algún LBS

Autor Desarrollador, arquitectoCriterio de medición El usuario pudo o no relacionar una

publicidad con una empresa específica Prioridad 5 Modulo

asociado sistema

32



4.3 Requerimientos de Desempeño


arquitectura


Descripción

Cuando ocurra un fallo o error, el tiempo medio de reparación (mean time to repair - MTTR) será mínimo entre 5 minutos y máximo 1 día. Los fallos o errores ajenos por problemas de Google Maps se excluyen

RazónLa asociación AGG-JMM debe resolver todos los inconvenientes de sus usuarios con respecto a la prestación de su LBS de parqueaderos públicos en Bogotá


Criterio de mediciónResolver en el tiempo estipulado un fallo o error que no debería presentarse en formalización de los términos y condiciones sujetos al servicio




arquitectura


Descripción

Los tiempos de respuesta estimados, requeridos y esperados del LBS serán de máximo 5 minutos sin contar con algún problema técnico ajeno a la construcción del middleware

Razón Sí un LBS no presenta tiempos de

33


respuestas rápidos, deja de ser atractivo para la mayoría de usuarios


Criterio de medición

Una tarea específica del LBS es que opere en el lapso de 0 a 5 minutos con un resultado.Sin embargo, la velocidad de navegación es un factor independiente del servicio brindado por AGG-JMM




arquitectura


DescripciónEl middleware debe permitir un número mínimo de 10 000 conexiones simultaneas por parte de los clientes

Razón

Aunque es un Es necesario tener una cifra mínima de conexión simultanea; aunque podrá no estar sujeta a una métrica adecuada porque no se conocen cifras precisas y reales del número de celulares activos en Bogotá por parte del ministerio de comunicaciones [TIEMP 2010] (26), sí Bogotá tiene aproximadamente 7 millones de habitantes, podríamos pensar que alrededor de 1 millón poseen un teléfono celular con las características necesarias y con la voluntad de adquirir un servicio LBS de este tipo, por la que la cifra podría ser baja, pero se debe tener en cuenta es que esté usando esa cantidad de usuario al mismo instante y solicitando el servicio

Autor Desarrollador, arquitectoCriterio de medición Realización de pruebas que lo confirmen Prioridad 1 Modulo

asociado sistemaVersión 1 Fecha 13 abril

Nota: Para el desarrollo del prototipo no se tendrá en cuenta este requerimiento

34


4.4 Restricciones De Diseño

Como este documento está enfocado hacia los requerimientos específicos para el servicio de los

parqueaderos públicos en Bogotá de AGG-JMM, su objetivo es la construcción de una

arquitectura tipo middleware, quién representa el diseño mismo de la arquitectura final.

Además, este tipo de middleware está orientado a servicios similares a este, todos basados en la

localización de dispositivos móviles como lo son los teléfonos celulares.

Por otro lado, el paradigma de programación escogido es el orientado a objetos, ya que uno de

los aspectos escogidos al realizar y describir la arquitectura propuesta es la facilidad y claridad

de entenderla, por lo que realizar programas y módulos con estas características será sencillo de

escribir, mantener y reutilizar.

4.5 Atributos del Sistema de Software

Los atributos del sistema de software hacen referencia a otros tipos de requerimientos no

especificados en las secciones previas. Estos son los requerimientos no funcionales, dónde se

usan criterios, por lo general que sean medibles, para poder juzgar si una operación de un

sistema se cumplió o no.

A continuación se agrupan por diferentes categorías este tipo de requerimientos siguiendo la

plantilla de Volere [VOLE 2005] (25)

4.5.1 Disponibilidad

#requerimiento 13

Tipo de requerimiento

arquitectura


1-3, 5, 6, 9-20

35


Descripción El middleware debe estar disponible en relación al tiempo en un porcentaje del 99.9%

Razón

El arquitecto de software desea siempre tener funcionando las interrelaciones entre cualquier componente por si llegarán a necesitar de forma inmediata en algún caso específico

Autor Desarrollador, arquitectoCriterio de medición El usuario puede realizar una tarea específica

en cualquier instante de tiempo.Prioridad 4 Modulo


Nota: Para el desarrollo del prototipo no se tendrá en cuenta este requerimiento

4.5.2 Seguridad


arquitectura


DescripciónEl middleware debe seguir funcionando, incluso tras haberse producido un fallo de parte de un componente del mismo, siempre y cuando no sea vital

RazónNo es conveniente que al no funcionar un componente que no sea vital, no se pueda realizar alguna operación independiente a la causa del problema


Criterio de mediciónDesactivar o descomponer una parte de la arquitectura que no es vital para una tarea específica



(Nota: Para el desarrollo del prototipo no se tendrá en cuenta este requerimiento)

36


4.5.3 Mantenibilidad y reusabilidad


arquitectura


Descripción

El código fuente debe ir junto a un documento con las descripciones generales de las clases y su funcionamiento, el cual le indica a futuros desarrolladores la forma realizar escalabilidad

Razón

Una de las razones para asegurar la escalabilidad entre componentes es proporcionar un documento que describa cómo fue construido y utilizado el middleware

Autor Desarrollador, arquitectoCriterio de medición Se entregó el documento respectivo

relacionado a la realización del middlewarePrioridad 3 Modulo



arquitectura


DescripciónEl middleware debe permitir la escalabilidad e integración sencilla en componentes y funciones sin verse gravemente afectado

Razón

Una de las razones para la realización de esta arquitectura de middleware es el hecho de poder ofrecer nuevos y diferentes LBS en el futuro, favoreciendo a todos los stakeholders involucrados ( los clientes, los desarrolladores y proveedores de este tipo de servicios) facilitando los cambios y haciéndolos menos drásticos


Criterio de mediciónEste criterio estará basado en la arquitectura entregada en el documento SAD y no estará reflejada en la realización del prototipo con el servicio de Google Maps



37



arquitectura


DescripciónEl middleware en su arquitectura debe poseer una modularidad alta, de tal forma, que su mantenimiento sea sencillo, afectando lo menos posible otros módulos

RazónAl tener un concepto de alto acoplamiento y baja cohesión, le permite a uno crear unos módulos que garanticen un mantenimiento sencillo y claro entre cada componente


Criterio de mediciónEste criterio estará basado en la arquitectura entregada en el documento SAD y no estará reflejada en la realización del prototipo con el servicio de Google Maps



4.5.4 Usabilidad


arquitectura


Descripción

El middleware debe permitir que los usuarios se puedan conectar desde diferentes dispositivos móviles, como son diversos modelos de teléfonos celulares y sistemas operativos

Razón

Es la causa más importante de construir un middleware que gestione las operaciones entre sus stakeholders y resolver uno de los problemas más grandes en el mundo informático, la poca interoperabilidad entre dispositivos y componentes.


Criterio de mediciónLa aplicación LBS debe funcionar en diferentes modelos de celulares que poseen las características idóneas



38


4.6 Requerimientos de la base de datos

La base de datos que usará el sistema de AGG-JMM es Oracle XE porque está familiarizado con

dicha herramienta y porque garantiza almacenar y gestionar tipos de datos como Char,

Varchar2, Numeric y date de forma simple.

En esta base de datos se pretende guardar las coordenadas de los establecimientos en latitud,

longitud, dirección y demás descripciones sobre características de sitios de interés y perfiles de

clientes. Se usará como llave primaria en la tabla de la empresa el atributo llamado “Nit”

correspondiente al número de identificación de la empresa (es único); y como llave primera para

el cliente su cedula. Por último, el diseño de la base de datos no requiere ser complejo y no

pretende ser un factor relevante para la creación del prototipo de LBS sobre los parqueaderos

públicos de Bogotá.

Diseño de Base de datos

El diseño de la base de datos se encuentra en tamaño real en el anexo 7.

39


Ilustración 3 : Diseño de la base de datos

40


5 Anexos

Anexo 1: Diagrama de casos de uso, adjunto a este documento

Caso de uso 1 ConsultarMapaGeneral

Objetivo en contexto El actor consulta el servicio de mapas personalizado en su

teléfono celular

Alcance Aplicación del dispositivo móvil, tarea primaria

Pre-condiciones El actor posee las características descritas en 3.3 y 3.11 de su

teléfono celular como poder acceder a la aplicación de Google

Maps y tener una conexión a internet; además

el actor efectuó el caso de uso 21, enseguida el 3 y ahora el

actor posee su teléfono celular en su mano

Condición de éxito El actor pudo acceder y consultar el mapa personalizado en su

dispositivo móvil

Condición de falla El actor no pudo acceder y consultar el mapa personalizado en

su dispositivo móvil

Actores Usuario, empresa y AGG-JMM

Disparador Ingreso a la aplicación de Google Maps desde su dispositivo

móvil.

Descripción Paso Acción

1 El actor toma su teléfono celular y visualiza el mapa

de Google Maps con su información básica como son

las calles, carreras, avenidas, transversales y barrios

principales ;además de algunos sitios de interés

general y turísticos como catedrales, hospitales,

41


estaciones de transmilenio, bibliotecas y

museos ;pero incluye el perfil establecido en el caso

de uso 3

2 la aplicación de Google Maps se actualiza y visualiza

una nueva zona del mapa según el paso 1

3 El usuario cierra la aplicación de Google Maps

Sub variación 1ª el actor decidió buscar un sitio( de la misma forma

que hacía en Google Maps sin tener el servicio LBS

de AGG-JMM ) y ingresó un lugar,

1b el actor decidió acerca o alejar el zoom

2a Si el actor desea volver a consultar otro sitio se

devuelve al paso 2

2b Si el actor desea nuevamente acerca o alejar el zoom

se devuelve al paso 2

Caso de uso 2 ConsultarDetalleParqueadero

Objetivo en contexto El actor consulta en detalle la información o publicidad a la que

se suscribió de los parqueaderos públicos en la ciudad de

Bogotá

Alcance Aplicación Google Maps del teléfono celular

, tarea primaria

Pre-condiciones Las mismas que el caso 1 ; el actor se encuentra en el caso de

uso 1, en el 1 paso

Condición de éxito El actor leyó información detallada según sus características

previamente establecidas de los parqueaderos públicos en

Bogotá.

42


Condición de falla El actor no pudo leer ninguna información a la que se suscribió

de algún parqueadero específico en la ciudad de Bogotá

Actores Usuario, empresa y AGG-JMM

Disparador El actor presiona un sitio de interés de tipo parqueadero


1 La aplicación de Google Maps se refresca mostrando

la zona del mapa original más la información de las

características de los parqueaderos públicos que

previamente filtró al comienzo de utilizar el servicio.

2 El actor lee la información o publicidad del sitió que

seleccionó

3 El actor vuelve al paso 2 del caso 1

Caso de uso 3 Filtrar

Objetivo en contexto El actor filtra una o varias características del servicio LBS al que

se suscribió

Alcance Sistema web AGG-JMM

, tarea primaria

Pre-condiciones El actor está usando un computador con conexión a internet,

está en el Website de AGG-JMM, pagó por el servicio de

43


información de parqueaderos públicos en Bogotá y se encuentra

logueado

Condición de éxito El actor pudo filtrar al menos una opción de varias disponibles

en el Website

Condición de falla El actor no pudo filtrar ninguna opción de varias disponibles en

el Website

Actores Usuario, Website AGG-JMM

Disparador Selección de la opción filtrar


1 El Website se actualiza y muestra las diferentes

categorías en las que puede filtrar para el servicio al

que se suscribió

2 El usuario escoge las características que él desea y

cierra su sesión

Incluido 1ª Si el actor escogió filtrar por empresa: el sistema le

muestra las empresas más reconocidas en

parqueaderos públicos como son City Parking, Park

Elite, Aparcar entre otros

1b Si el actor escogió filtrar por valet parking, el

sistema le mostrará todos los establecimientos que

poseen este servicio y que le garantiza al usuario el

estacionamiento de su vehículo

1c Si el actor escogió filtrar por señalización, le

mostrará al usuario información pertinente de la

adecuación del parqueadero como si es fácil o no

44


parquear debido a falta de señalización en las vías

que podrían causarle molestias al momento de

parquear por estar muy cerca de un vehículo o

pensar que está bien estacionado cuando no lo está

1d Si el actor escogió filtrar por llave, le mostrará

información dónde el dueño exige dejar la llave en

caso de que el parqueadero se llene o se necesite

“mover” el carro de un sitio a otro

1e Si el actor escogió filtrar por tarifa, le mostrará información del valor del minuto en el parqueadero, así como poder discernir entre parqueaderos de bajo, media o alta categoría

1f Si el actor escogió otras características, aquí se muestran otro tipo de información como : si el parqueadero es miembro diamante del club de Renault para obtener descuentos y beneficios(esta opción no se encuentra disponible en el prototipo)Otro filtro es el tipo de infraestructura del parqueadero, si está o no cubierto entre otros

Caso de uso 4 CrearArchivoPersonalizado

Objetivo en contexto El actor crea un archivo personalizado

Alcance

Sistema AGG-JMM, tarea primaria

Pre-condiciones Ninguna

Condición de éxito El actor pudo crear un archivo KML con las características

requeridas por una empresa contratante, y las alojó en un

servidor de su preferencia

45


Condición de falla El actor no pudo crear un archivo KML con las características

requeridas y/o no las pudo alojar en un servidor de su

preferencia

Actores AGG-JMM

Disparador Adquisición de la prestación del servicio de información o

publicidad de AGG-JMM por parte de una empresa


1 El actor, utilizando su conocimiento del API de

Google y archivos KML, crea un archivo de este

tipo utilizando los requerimientos asociados a un

servicio específico de alguna empresa negociante

Incluido El actor luego de crear dicho archivo debe almacenarlo en un servidor web específico

Caso de uso 5 generarEstadísticaEmpresa

Objetivo en contexto El actor genera estadísticas de un servicio para una empresa

específica

Alcance

Sistema AGG-JMM, primary task

Pre-condiciones Existe un servicio ofrecido por AGG-JMM que fue adquirido

por una empresa

Condición de éxito El actor pudo generar estadísticas de una empresa

46


Condición de falla El actor no pudo generar estadísticas de un servicio específico

hacia una compañia contratante

Actores AGG-JMM, empresa asociada

Disparador Cuando la empresa solicite un reporte de las estadísticas de

algún servicio de información o publicidad de AGG-JMM


1 El actor crea una base de datos para almacenar todo

tipo de información pertinente de cada usuario que

utilice un LBS de cada empresa

2 El actor activa y utiliza la base de datos para guardar

la información necesaria

3 El actor genera un reporte y lo envía a la empresa

asociada por medios físicos.

Caso de uso 6 generarEstadísticaGeneral

Objetivo en contexto El actor genera estadísticas de todos los servicios ofrecido por

AGG-JMM

Alcance

Sistema AGG-JMM, tarea secundaria

47


Pre-condiciones Existe al menos un servicio ofrecido por AGG-JMM a alguna

empresa

Condición de éxito El actor pudo generar estadísticas de todas las empresa suscritas

a AGG-JMM

Condición de falla El actor no pudo generar estadísticas de todas las empresa

suscritas a AGG-JMM

Actores AGG-JMM

Disparador El ultimo día de cada mes se realiza un reporte accionado por

AGG-JMM


1 El actor, utilizando su base de datos asociada a

todos sus LBS ofrecidos, genera un reporte total

Caso de uso 7 comprarPublicidad

Objetivo en contexto El actor desea comprar el espacio publicitario dentro del sistema

AGG-JMM

Alcance


48



Condición de éxito El actor pudo comprar un espacio publicitario a AGG-JMM

Condición de falla El actor pudo comprar un espacio publicitario a AGG-JMM

Actores Empresa, AGG-JMM

Disparador Una compañía decidió comprar un espacio publicitario a AGG-

JMM


1 El actor considera que adquirir un servicio LBS

ofrecido por AGG-JMM le daría un valor agregado a

su empresa

Caso de uso 8 asignarPublicidad

Objetivo en contexto El actor desea ofrecer el espacio publicitario dentro del sistema

AGG-JMM a una empresa que lo demande

Alcance


Pre-condiciones Una empresa ha deseado adquirir un servicio LBS de su

empresa

49


Condición de éxito El actor pudo asignar un espacio publicitario a AGG-JMM

Condición de falla El actor no pudo asignar un espacio publicitario a AGG-JMM

Actores Empresa, AGG-JMM

Disparador Una compañía decidió comprar un espacio publicitario a AGG-

JMM


1 El actor hace un diagnóstico del negocio de la

empresa.

2 El actor realiza un levantamiento de requerimientos

3 El actor negocia con la empresa los tipos de

servicios que este desea brindar a un usuario

4 Se establece un contrato con la empresa

Caso de uso 21 adquirirServicio

Objetivo en contexto El actor desea adquirir un servicio que le permita consultar

información de los parqueaderos públicos en la ciudad de

50


Bogotá

Alcance

Sistema, AGG-JMM, tarea primaria


Condición de éxito El actor pudo adquirir el LBS de parqueaderos públicos en

Bogotá

Condición de falla El actor no pudo adquirir el LBS de parqueaderos públicos en

Bogotá

Actores usuario, AGG-JMM, empresa

Disparador El usuario decidió comprar el LBS de parqueaderos públicos en

Bogotá a AGG-JMM


1 El actor se dirige a la oficina de la asociación AGG-

JMM

2 AGG-JMM le describe su negocio y le sugiere varias

servicios, entre ellos los parqueaderos públicos en

Bogotá; aquí le muestra las ventajas que podrá

disponer en su nuevo estilo de vida

3 Los anteriores discuten y establecen un acuerdo

teniendo en cuenta un contrato respectivo y sus

términos y condiciones

4 AGG-JMM le brinda un login y password que le

51


permiten identificarse en la página web del sistema

LBS AGG-JMM, con el fin de crear un perfil del

actor

Caso de uso 9 RegistrarEmpresa

Objetivo en contexto El actor desea registrar una nueva empresa suscrita a los

servicios de AGG-JMM

Alcance

Sistema, AGG-JMM, tarea primaria

Pre-condiciones La empresa firmó un contrato con AGG-JMM

Condición de éxito El actor pudo registrar una nueva empresa

Condición de falla El actor no pudo registrar una nueva empresa

Actores AGG-JMM

Disparador El actor decide registrar una empresa que está compro el

servicio de información y publicidad de parqueaderos públicos

en Bogotá


1 El actor escribe en su base de datos los datos :

Nombre de la empresa, Nit de la empresa, fecha de

inscripción, dirección del establecimiento en la

nomenclatura nueva.

52


Incluye 1ª El actor agrega nueva información; esta corresponde

cuando se realizó la visita técnica al establecimiento

y se hizo un diagnóstico del parqueadero.

1b El actor toma las coordenadas del lugar en

coordenadas WGS84 y la dirección de la

nomenclatura nueva del establecimiento

2 El sistema guarda la información en la base de datos

de las empresas

A continuación, se nombran los casos de uso básicos que no requieren una mayor descripción:

CRUD de empresa

Caso de uso 10 recuperar empresa

Caso de uso 11 actualizar empresa

Caso de uso 12 eliminar (desactivar) empresa

CRUD de usuario

Caso de uso 13 Crear (registrar) usuario

Caso de uso 14 recuperar usuario

Caso de uso 15 actualizar usuario

Caso de uso 16 eliminar (desactivar) usuario

CRUD de parqueadero

Caso de uso 17 Crear (registrar) parqueadero

Caso de uso 18 recuperar parqueadero

Caso de uso 19 actualizar parqueadero

Caso de uso 20 eliminar (desactivar) parqueadero

53


Anexo 2: Condiciones y términos de Google Maps, adjunto a este documento

Anexo 3: Modelo del dominio, adjunto a este documento

Anexo 4: documento del estado del arte de los servicios basados en la localización, adjunto a este documento

Anexo 5: diseño de la base de datos

54


6 Referencias – Bibliografía- Indice de tablas

1. PcMag.com. API definition from PC Magazine Encyclopedia. www.pcmag.com. [En línea]

[Citado el: 10 de 2 de 2010.]

http://www.pcmag.com/encyclopedia_term/0,2542,t=API&i=37856,00.asp.

2. webopedia.com. what is CRUD? a word definition from the webopedia.

www.webopedia.com. [Online] [Cited: 1 12, 2010.]

http://www.webopedia.com/TERM/C/CRUD.html.

3. whatis.techtarget.com. What is a framework? www.whatis.techtarget.com. [En línea] [Citado

el: 1 de 1 de 2010.] http://whatis.techtarget.com/definition/0,,sid9_gci1103696,00.html.

4. European space agency. ESA NAVIGATION. ESA Galileo Navigation. [Online] [Cited: 1

10, 2010.] http://www.esa.int/esaNA/galileo.html.

5. International GNSS Service. IGS International GNSS Service ,formely the international

GPS Service. http://igscb.jpl.nasa.gov/. [Online] [Cited: 1 12, 210.] http://igscb.jpl.nasa.gov/.

6. el sistema operativo GNU. www.gnu.org. [En línea] [Citado el: 10 de 1 de 2010.]

http://www.gnu.org/home.es.html.

7. Global positioning system. www.gps.com. [Online] [Cited: 1 10, 210.]

http://www.gps.gov/systems/gps/index.html.

8. gsmworld.com. History GSM World. gsmworld.com. [Online] [Cited: 1 10, 2010.]

http://gsmworld.com/about-us/history.htm.

9. The Linux Information project. GUI definition. www.linfo.org. [Online] [Cited: 1 10, 210.]

http://www.linfo.org/gui.html.

10. Google. Tutorial de KML. Google Code. [En línea] 21 de 4 de 2010.

http://code.google.com/intl/es-ES/apis/kml/documentation/kml_tut.html.

11. KÜPPER, AXEL. Location-Based Services. Location-Based Services Fundamentals and

Operation. s.l. : Wiley.

12. Client-Server Computing: The Web as Middleware. the web as a middleware. [Online]

[Cited: 1 2, 2010.] http://www.faughnan.com/papers/clservweb.html.

55


13. Universidad de la Habana. fbioinformática. http://fbio.uh.cu. [En línea] [Citado el: 1 de 2

de 2010.] http://fbio.uh.cu/sites/bioinfo/glosario.html.

14. pcmag.com. operating system definition from pc magazine. www.pcmag.com. [Online]

[Cited: 1 10, 2010.]

http://www.pcmag.com/encyclopedia_term/0,2542,t=operating+system&i=48510,00.asp.

15. Pcmag.com. Smarthphone definition from pcmagazine. www.pcmag.com. [Online] [Cited: 1

10, 2010.] http://www.pcmag.com/encyclopedia_term/0,2542,t=Smartphone&i=51537,00.asp.

16. Wrinting software requirement specifications. http://www.techwr-l.com. [Online] [Cited: 1

10, 2010.] http://www.techwr-l.com/techwhirl/magazine/writing/softwarerequirementspecs.html.

17. The Role of Push-Pull Technology in Privacy Calculus: The Case of Location-Based

Services. Heng Xu, Hock-Hai Teo,Bernard Tan,Ritu Agarwal. , s.l. : M. E. Sharpe, Inc.

Armonk, NY, USA, 2009. 0742-1222 .

18. SMART project requirements. project-management.bestmanagementarticles.com. [Online]

[Cited: 1 10, 2010.] http://project-management.bestmanagementarticles.com/a-9353-smart-

project-requirements.aspx.

19. RFC791. http://www.rfc-es.org. [En línea] http://www.rfc-es.org/rfc/rfc0791-es.txt.

20. Tanenbaum, Andrew S. Computer Networks - Fourth Edition . s.l. : Prentice Hall

International Editions.

21. http://www.rfc-es.org. rfc768. [En línea] http://www.rfc-es.org/rfc/rfc0768-es.txt.

22. http://www.iana.org/assignments/port-numbers. IANA. [Online] [Cited: 2 1, 2010.]

http://www.iana.org/assignments/port-numbers.

23. W3C. WORLD WIDE CONSORTIUM. [En línea] 10 de 3 de 2010. http://www.w3.org/.

24. Facultad de Ingeniería de Sistemas Pontifica Universidad Javeriana. Página de Miguel

Torres. Página de Miguel Torres. [En línea] [Citado el: 15 de 1 de 2010.]

http://sophia.javeriana.edu.co/~metorres/Materias/IngSoftware/Estandares/IRONWORKS.zip.

25. Robertson, James & Suzanne. Volere Requirements Resources. Requirements

Specification Template. [Online] Atlantic Systems Guild, abril 14, 2005.

http://www.volere.co.uk/template.htm.

56


26. cúantos celulares hay en Colombia. ELTIEMPO.COM. [En línea] 15 de abril de 2010.

[Citado el: 15 de abril de 2010.] http://www.eltiempo.com/archivo/documento/MAM-452754.

27. Grupo de traducción de RFC al español. RFC es. [En línea] [Citado el: 10 de 3 de 2010.]

http://www.rfc-es.org/.

Indice de tablas

Tabla 1: Historial de cambios..........................................................................................................3

Tabla 2: Interfaces de software.....................................................................................................20

Tabla 3 : Características del usuario [IRON 2007] (24)...............................................................23

57

pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS0930IS02/archivos/SRS_… · Web...

Documents

Transcript of pegasus.javeriana.edu.copegasus.javeriana.edu.co/~CIS0930IS02/archivos/SRS_… · Web...