DOC - Ingeniería de Sistemas | Pontificia Universidad Javeriana

SAD
Software Architecture Document
08/04/2010
AGG-JMM
Andrés Gaitán Galarza– Jair Andrés Moreno Muñoz
SAD
Contenido
Índice de Ilustraciones y tablas .......................................................................................... 4
Definiciones, acrónimos y abreviaciones ........................................................................... 4
1.
Introducción ................................................................................................................ 9
1.1 Propósito ............................................................................................................... 10
1.2 Alcance ................................................................................................................. 10
1.3 Visión Global ......................................................................................................... 10
2.
Representación Arquitectónica ................................................................................. 11
2.1 Descripción de la Arquitectura............................................................................... 13
3.
Objetivos y Restricciones Arquitectónicas................................................................. 14
4.
Vista Casos de Uso .................................................................................................. 16
4.1 Diagrama de casos de uso .................................................................................... 16
4.2 Documentación Casos de Uso .............................................................................. 17
5.
Escenarios ................................................................................................................ 32
6.
Vista Lógica .............................................................................................................. 35
6.1 Diagrama .............................................................................................................. 36
6.2 Descripción ........................................................................................................... 37
7.
Realización de Casos de uso.................................................................................... 38
8.
Vista de Procesos ..................................................................................................... 39
8.1 Diagrama de procesos .......................................................................................... 39
8.2 Descripción ........................................................................................................... 40
MTG
Página 2
SAD
9.
Vista de Desarrollo ................................................................................................... 40
9.1 Diagrama .............................................................................................................. 41
9.2 Descripción ........................................................................................................... 42
10.
Vista de Despliegue .............................................................................................. 44
10.1 Diagrama Físico .................................................................................................... 44
10.2 Descripción ........................................................................................................... 45
10.3
Diagrama de despliegue ....................................................................................... 46
10.4 Descripción ........................................................................................................... 47
11.
Vista de Datos ....................................................................................................... 48
11.1 Diagrama entidad/relación que modela el sistema AGG-JMM............................... 48
11.2 Descripción ........................................................................................................... 49
12.
Tamaño y Desempeño .......................................................................................... 50
13.
Calidad .................................................................................................................. 50
14.
Anexos .................................................................................................................. 50
15.
Referencias y Bibliografía ..................................................................................... 51
MTG
Página 3
SAD
Índice de Ilustraciones y tablas
Ilustración 1: metodología de 4 +1 vistas ......................................................................... 13
Ilustración 2: Casos de uso .............................................................................................. 17
Ilustración 3: Vista de Procesos ....................................................................................... 39
Ilustración 4: Vista de Desarrollo ..................................................................................... 41
Ilustración 5: diagrama Físico .......................................................................................... 44
Ilustración 6: Vista de Despliegue .................................................................................... 46
Ilustración 7: vista de Datos ............................................................................................. 49
Definiciones, acrónimos y abreviaciones

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)

Contenedor Web: Web Container, este objeto crea el pedido HTTP y respuesta
para el servlet, enseguida llama al apropiado método de servicio del servlet para
satisfacer la demanda del cliente. [J2EE 2010] (2)

CORBA: Common Object Request Broker Architecture es una interface de
software basada en la organización OMG que le permite a los módulos de
MTG
Página 4
SAD
software u objetos comunicarse entre sí sin importarse si se encuentran en una
red privada o pública como internet.[PCMAG 1996] (3)

CRUD: se refiere en ingles (CREATE, RETRIEVE, UPDATE, DELETE) a las
funciones de crear, recuperar, actualizar y eliminar.[WEBO 2010] (4)

DCOM: Distributed component object model, es la tecnología de Microsoft para
distribuir objetos, como CORBA o RMI.[PCMAG 1996] (5)

Galileo: Según la agencia espacial europea [ESA 2000] (6) , 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] (7)

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] (8)

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 anytimeanywhere.
MTG
Página 5
SAD

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)

ODBC: open database connectivity, es una interface de programación de base de
datos de Microsoft que provee un lenguaje común para aplicaciones de Windows
para acceder a unas bases de datos en una red. ODBC soporta trabajar con o
sin SQL (lenguaje nativo de la base de datos) [PCMAG 1996] (14)

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] (15)

RMI: remote method invocation, es un estándar de la empresa Sun para objetos
distribuidos escritos en lenguaje JAVA. Es un llamado a un procedimiento local
(RPC) que permite a componentes de JAVA almacenarse en una red para ser
ejecutada remotamente.[PCMAG 1996] (16)

RMI-IIOP: Es una extensión de de RMI de la empresa de Sun que le permite a los
objetos de JAVA ejecutar objetos de CORBA.[PCMAG 1996] (17)

RPC: remote procedure call, es una interface de programación que le permite a
un programa usar servicios de otro programa en una máquina remota. El programa
de llamado manda un mensaje o información a un programa remoto , el cual es
ejecutado y sus resultados son devueltos por el mismo mecanismo.[PCMAG
1996] (18)

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. (19)

Servicio web: Según el glosario de J2EE, un web service es una aplicación que
existe en un entorno distribuido, como Internet. Este acepta una solicitud, realiza
su función sobre la base de la solicitud y devuelve una respuesta. Tanto la
solicitud y la respuesta suele adoptar la forma de XML y se entregan más de un
protocolo de conexión, como el HTTP [J2EE 2010] (2)
MTG
Página 6
SAD

Servidor de aplicaciones: application server, es servidor más completo que un
web server, y ideal para gestionar páginas Web con alta concurrencia y
paralelismo al momento de establecer conexiones de clientes ante diferentes
solicitudes (están diseñados alrededores de arquitectura J2EE); además el
servidor de aplicación puede estar en la misma computadora que el web server o
estar en una computadora distinta. Algunos application server son WebSphere de
Bea Weblogic, Weblogic, oracle 9i application server, sun applicaction server
[OSMO 2009] (20)

Servidor web: un web server, según el glosario de J2EE, es un software que
proporciona servicios para tener acceso a Internet, una Intranet, o a una extranet.
El servidor Web almacena sitios Web, proporciona la ayuda para HTTP y otros
protocolos, y ejecuta programas por parte del servidor. Algunos web server son de
Apache, AOL servers, IIS entre otros [J2EE 2010] (2)

Servlet: Es un programa en lenguaje JAVA que extiende la funcionalidad a un
web server generando contenido dinámico y interactuando con aplicaciones web
usando el paradigma solicitud –respuesta. . [J2EE 2010] (2)

Smalltalk:es un sistema operativo y un lenguaje de programación orientado a
objetos que fue desarrollado por Xerox PARC.[PCMAG 1996] (21)

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] (22)

SOAP: simple object Access protocol ,es un protocolo de mensajes basados en
XML para acceder servicios Web.[PCMAG 1996] (23)

SQL: structured query language , es un lenguaje usado para interrogar y procesar
datos en una base de datos relacionada; y aunque ANSI estandarizó el SQL,
muchos DBMS están sujetos a mejorías por empresas propietarias lo cual hace
algunas veces un SQL no estándar.[PCMAG 1996] (24)

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 dependencias (para un cliente potencial ) de un
MTG
Página 7
SAD
aspecto en particular en un momento dado previo al actual diseño o desarrollo de
un proyecto de software.[TECH 1997] (25)

UML: unified modelling language (26) es un objeto orientado al análisis y diseño
de un lenguaje de la organización OMG. Este consorcio dedicado al manejo de
estándares de tecnologías orientados a objetos para empresas como Hewlett –
Packard, IBM, Sun Microsystems y Apple computers.

XML: extensible markup language, es un lenguaje extensible que le permite
marcar (markup) lo necesitado para identificar un contenido ,datos y texto en
documentos XML. [J2EE 2010] (2)
MTG
Página 8
SAD
1. Introducción
Este documento hace parte del trabajo de grado de los estudiantes Andrés
Gaitán Galarza y Jair Moreno Muñoz. En las siguientes secciones, se busca
organizar, precisar y analizar las interacciones, configuraciones y limitaciones de
una arquitectura llamada MTG “Middleware to Go”. Además, en el documento se
encuentra:
Representación arquitectónica a utilizar
Objetivos y limitaciones arquitectónicas.
Estilo arquitectónica a usar.
Casos de uso.
Vista lógica.
Vista de proceso.
Vista de despliegue.
Vista de implementación.
Vista de datos.
Calidad, tamaño y rendimiento.
MTG
Página 9
SAD
1.1
Propósito
El presente documento persigue dar un panorama de la arquitectura llamada MTG
para la propuesta del trabajo de grado “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”.
1.2
Alcance
Este entregable busca dar a conocer la representación arquitectónica del sistema
MTG, desarrollada por los estudiantes Andrés Gaitán Galarza y Jair Moreno
Muñoz (AGG-JMM) para su trabajo de grado. El documento está delimitado por la
metodología escogida “4+1 vistas”, elaborada por Krutchen de la compañía
Rational Software Corporation [KRUT 1995] (27) y la arquitectura en sí utilizada.
1.3
Visión Global
Este documento está compuesto por diferentes secciones dirigidas a lectores
expertos; en primera instancia se encuentra una visión general del documento
dirigida a cualquier constructor del sistema para orientarlo en su lectura.
Posteriormente se encuentra una sección dedicada a la descripción global del
ambiente arquitectónico del producto dirigido a diseñadores, arquitectos y
desarrolladores. Del comienzo hasta esta parte del documento, se ha introducido
lo que va a contener en términos generales, así como su propósito y su alcance.
MTG
Página 10
SAD
En las siguientes secciones la descripción arquitectónica se hará con más detalle y
básicamente se pretende:

Dar a conocer cómo se va a realizar la representación arquitectónica en el
sistema y de qué forma se puede adaptar a las necesidades de los
Stakeholders.

Mostrar los objetivos que se tienen en cuenta en el ambiente
arquitectónico, así como las limitaciones con las que hay que restringir el
sistema.

Mostrar el estilo arquitectónico que se va a utilizar en el sistema.

Determinar cómo se va a adaptar el modelo de “4+1 vistas “a la
arquitectura planteada para el sistema.

Características de tamaño y rendimiento de los programas del sistema.

Contribución del estilo arquitectónico escogido a los atributos de calidad del
sistema.
2. Representación Arquitectónica
El sistema MTG es un arquitectura tipo middleware que pretende facilitar la
construcción de la misma en la búsqueda de satisfacer las características básicas
al momento de ofrecer soluciones LBS similares al servicio descrito en el anexo 2.
MTG
Página 11
SAD
Estas propiedades son:

Poseer una arquitectura que en sí permita una personalización de un LBS
brindado por alguna empresa, solicitado por un cliente y gestionado por
un tercero, como es el caso de AGG-JMM para el LBS de parqueaderos
públicos en la ciudad de Bogotá, descrito en el anexo 2.

La información y publicidad brindada está orientada a segmentos
específicos al usuario que posee un dispositivo móvil

Los usuarios pueden escoger que servicios consumen de la arquitectura

La(s) empresa recibe uno o varios reportes estadísticos de las preferencias
de los usuarios que consumen sus servicios
Así mismo, esta representación pretende aplicar los conceptos fundamentales de
diseño e implementación de una arquitectura de software, usando la presentación
de las vistas que se usa en el modelo “4+1”, escogida porque un sistema se
descompone en un conjunto de abstracciones claves tomadas del dominio del
problema en la forma de objetos y clases que son familiares para AGG-JMM.
Además, el uso de múltiples vistas permite enfocarse en varios aspectos por parte
de los Stakeholders y poder orientarse en alguno específico. La siguiente
ilustración explica este modelo:
MTG
Página 12
SAD
Ilustración 1: metodología de 4 +1 vistas
Por último, está metodología hace uso de diagramas del lenguaje de modelo
unificado UML (28) que es respaldado por el Object Management Group OGM
(29), consorcio dedicado al manejo de estándares de tecnologías orientados a
objetos para empresas como Hewlett –Packard, IBM, Sun Microsystems y Apple
computers. Entre estos diagramas, se especifican de: diseño, implementación,
procesos, distribución y caso de uso.
2.1
Descripción de la Arquitectura
A continuación se muestra una breve descripción de los principales componentes
del modelo 4+1 vistas:

Vista lógica: se describen los requerimientos funcionales del sistema en
términos de servicios a los usuarios. Esta vista muestra la funcionalidad del
sistema en base a las interacciones del los elementos internos.

Vista de procesos: Describe cada una de las tareas que se ejecutan en el
sistema.
MTG
Página 13
SAD

Vista de desarrollo: Esta vista se enfoca en la organización de módulos de
software en el desarrollo, la representación de la aplicación se hace mediante
componentes y paquetes.

Vista de despliegue: en esta vista se aprecia los componentes de hardware y
como se distribuyen los elementos de software, también se muestran las
formas cómo interactúan las maquinas y las características de las mismas.

Vista de casos de uso: este diagrama proporciona uno o más escenarios que
indican cómo debería interactuar el sistema con el usuario final.
3. Objetivos y Restricciones Arquitectónicas
El objetivo principal de construir esta arquitectura, descrita en las siguientes
secciones, es brindar una solución a la problemática propuesta en el trabajo de grado
“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”. Además, la
construcción de esta arquitectura describe y profundiza el LBS de AGG-JMM de los
parqueaderos públicos en la ciudad de Bogotá, reseñado en el anexo 2: SRS
Dadas las necesidades del sistema descrito en ese documento, surge una serie de
requisitos y restricciones (detallados en ese anexo) las cuales nombramos a
continuación:
(R hace referencia al requerimiento especificado en el documento SRS anexo 2)
MTG
Página 14
SAD
El sistema debe
En cuanto al desempeño

Garantizar un tiempo medio de reparación (MTTR) entre 5 minutos y un día
como máximo.R15

Estar en capacidad de dar respuesta a todos los usuarios con tiempos de
respuesta aceptables y/o requeridos.R17
Permitir un estimado de 10 000 conexiones simultaneas en el servicio solicitadas por
clientes.R18
(Nota: Para el desarrollo del prototipo no se tendrá en cuenta este requerimiento)
En cuanto a la disponibilidad:
Poseer una alta disponibilidad (99.999%) en los servicios, funcionando las 24
horas al día.R13
(Nota: Para el desarrollo del prototipo no se tendrá en cuenta este requerimiento)
En cuanto a seguridad:

Permitir seguir funcionando después del fallo de un componente que no sea
vital.R14
(Nota: Para el desarrollo del prototipo no se tendrá en cuenta este requerimiento)
En cuanto a la mantenibilidad y reusabilidad:

El código fuente debe estar acompañado por una documentación con las
descripciones generales de las clases y su funcionamiento, el cual le indica a
futuros desarrolladores la forma realizar escalabilidad.R16
MTG
Página 15
SAD
En cuanto a la escalabilidad:

Ser flexible para que nuevas funcionalidades o requerimientos sean
agregados.R19

Poder soportar cambios teniendo un impacto menor en el código existente.R20

Permitir el retiro de funcionalidades de forma que tengan un impacto menor en el
código existente. R20
En cuanto a su extensibidad:

Permitir una facilidad para adaptar los productos de software a los cambios de
especificación; principios de simplicidad del diseño y descentralización. R20

Facilitar la realización de nuevas implementaciones en un futuro.R19

Soportar correcciones de manera sencilla sobre la implementación sin ver
afectada su integridad funcional.R20

Poder integrar fácilmente mejoras de eficiencia en su implementación sin verse
gravemente afectado.R20
En cuanto a su interoperabilidad:

Permitir la conexión en diferentes modelos de teléfonos celulares, así como sus
sistemas operativos
4. Vista Casos de Uso
4.1
Diagrama de casos de uso
El diagrama de casos de uso se puede encontrar en tamaño mayor en el anexo 1
MTG
Página 16
SAD
Ilustración 2: Casos de uso
4.2
Documentación Casos de Uso
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
MTG
Página 17
SAD
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, 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
1a
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
Sub variación
MTG
Página 18
SAD
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
características previamente establecidas de
parqueaderos públicos en Bogotá.
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
MTG
sus
los
Página 19
SAD
Disparador
El actor presiona un sitio de interés de tipo parqueadero
Descripción
Paso
Acción
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
MTG
El actor está usando un computador con conexión a
internet, está en el Website de AGG-JMM, pagó por el
servicio de información de parqueaderos públicos en
Bogotá y se encuentra logueado
Página 20
SAD
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
Descripción
Paso
Acción
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
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
Incluido
MTG
Página 21
SAD
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 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 parqueaderoes 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
MTG
Página 22
SAD
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
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
Descripción
Paso
Acción
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
MTG
El actor luego de crear dicho archivo debe
almacenarlo en un servidor web específico
Página 23
SAD
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
Condición de falla
El actor no pudo generar estadísticas de un servicio
específico hacia una compañía 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 AGGJMM
Descripción
Paso
Acción
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
MTG
Página 24
SAD
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
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
MTG
Página 25
SAD
Disparador
El ultimo día de cada mes se realiza un reporte accionado
por AGG-JMM
Descripción
Paso
Acción
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
Sistema AGG-JMM, tarea primaria
Pre-condiciones
Ninguna
Condición de éxito
El actor pudo comprar un espacio publicitario a AGGJMM
Condición de falla
El actor pudo comprar un espacio publicitario a AGGJMM
MTG
Página 26
SAD
Actores
Empresa, AGG-JMM
Disparador
Una compañía decidió comprar un espacio publicitario a
AGG-JMM
Descripción
Paso
Acción
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
Sistema AGG-JMM, tarea primaria
Pre-condiciones
Una empresa ha deseado adquirir un servicio LBS de su
empresa
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 AGGJMM
MTG
Página 27
SAD
Actores
Empresa, AGG-JMM
Disparador
Una compañía decidió comprar un espacio publicitario a
AGG-JMM
Descripción
Paso
Acción
1
El actor hace un diagnóstico del negocio de la
empresa.
2
El actor realiza
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
un
levantamiento
de
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 Bogotá
MTG
Página 28
SAD
Alcance
Sistema, AGG-JMM, tarea primaria
Pre-condiciones
Ninguna
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
Descripción
Paso
Acción
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
MTG
Página 29
SAD
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
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
MTG
Página 30
SAD
Disparador
El actor decide registrar una empresa que está compro el
servicio de información y publicidad de parqueaderos
públicos en Bogotá
Descripción
Paso
Acción
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.
incluye
1a
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
MTG
Página 31
SAD
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
5. Escenarios
A continuación, se usa las tablas propuestas por Bruegge y Dutoit [BRUE ET AL 1999]
(30) de la universidad de Carnegie Mellon en Pittusburg ,Estados Unidos.
Nombre del escenario
relación Empresa AGG-JMM
Instancias de actores
partícipes
La empresa
Flujo de eventos
1. La empresa de algún parqueadero público
La asociación AGG-JMM
desea ofrecer información y publicidad en los
teléfonos celulares para generar valor en su
MTG
Página 32
SAD
negocio
2. AGG-JMM es una compañía que ofrece
servicios basados en la localización a través de
teléfonos celulares
3. La empresa se contacta con AGG-JMM en sus
instalaciones.
En este lugar, el departo de servicio al cliente le
ofrece las ventajas de usar este LBS, cómo
funciona y hace algunas demostración de su valor.
Además le indica su valor anual, el reporte y tipos
de estadísticas de la información de cada usuario
suscrito y por último le especifica los términos y
condiciones.
4.La empresa y AGG-JMM firman el contrato
Nombre del escenario
relación Usuario AGG-JMM
Instancias de actores
partícipes
Usuario
Flujo de eventos
1. Una persona posee un teléfono celular , ha
La asociación AGG-JMM
visto algún tipo de publicidad de la empresa AGGJMM y está curiosa por conocer los servicios
MTG
Página 33
SAD
basados de localización que le puede ofrecer,
como el de los parqueaderos públicos en la ciudad
de Bogotá.
2. La persona se dirige a las oficinas de AGGJMM.
3. En este lugar, el departo de servicio al cliente,
primero revisa si el celular podría servir para algún
LBS. Enseguida, sí lo anterior es positivo, le ofrece
las ventajas de usar este LBS, cómo funciona y
hace algunas demostración de su valor. Además le
indica su valor anual, cómo crear su perfil de
usuario y como elegir la información y publicidad
deseada para teléfono celular.
4. El usuario y AGG-JMM firman el contrato
después de leer los términos y condiciones.
Nombre del escenario
CreandoPerfil
Instancias de actores
partícipes
Usuario
Flujo de eventos
1.El usuario recién se escribió al LBS de
El sistema de AGG-JMM
parqueaderos públicos de la ciudad de Bogotá.
MTG
Página 34
SAD
2. El usuario se dirige a un computador con
conexión a internet. Ingresa a la página de AGGJMM con su login y password suministrados al
momento de firmar el contrato.
3. El usuario observa una gran variedad de
opciones para personalizar su servicio.
Dentro de algunas de ellas, están organizadas por
categoría como el nombre de la empresa de los
parqueaderos, sí la tarifa es baja, media o alta, sí
existe valet parking, sí hay que dejar la llave entre
otras.
4. El usuario indica en cada casilla sí desea recibir
información o publicidad de cada característica
6. Vista Lógica
Para esta vista se describen los requerimientos funcionales representados como
conjuntos de objetos y relaciones para mostrar el flujo de datos y conexión entre
componentes y paquetes.
MTG
Página 35
SAD
6.1
MTG
Diagrama
Página 36
SAD
Ilustración 1 : vista lógica
6.2
Descripción
En el diagrama de lógica, Anexo(6), se observan los paquetes de Usuario, presentación,
lógica , modelo de datos ,sistemas externos y DBMS .
Dentro del paquete de usuario, existe un navegador quien se comunica con el
componente Controlador para suministrarle información de las solicitudes del cliente y/o
administrador a través del protocolo Hypertext transfer (HTTP), descrito por la Internet
Society en el RFC 2616 [INTER 1999] (31) a través de cualquier navegador (browser).
Este mecanismo es el mismo usado para acceder a los servicios de aplicación
cartografía, los cuales pueden ser Google Maps, Bing Maps,Yahoo Maps, mapas com.co,
mapas publicar entre otros. Cabe anotar, que podría remplazarse por otro protocolo, por
ejemplo HTTPS sí dicho LBS se específica que debe poseer una alta seguridad en sus
transferencias.
El componente de Controlador, controla el componente de Vista y es el encargado de
devolver o responder la comunicación al browser por el mismo mecanismo. El
Controlador le indica al componente Modelo, una tarea específica y junto al componente
de Vista usan el componente de Sesion, quien identifica el tipo de usuario.
El componente Modelo, se puede comunicar con el componente de Manejadores del
paquete lógica por el intermedio de tecnología RMI o CORBA (si es necesario usarla). Los
Manejadores son unos receptores de peticiones del cliente que facilitan y simplifican las
tareas solicitadas por parte del usuario. Estos se enlazan con el paquete de Modelo de
datos y su componente de persistencia. Además estos Manejadores se enlazan con el
paquete llamado sistemas externos, a través del protocolo Simple Objet Access Protocol
(SOAP) descrito por la W3 Consortium [W3C 2007] (32) ; este garantiza la comunicación
de aplicaciones de diferentes sistemas operativos, y/ o lenguajes o tecnologías diferentes
a las usadas en el servicio ofrecido por AGG-JMM.
Dentro de este paquete, están los componentes para la geo-codificación de los puntos de
interés (no aplicable en el caso del servicio de LBS con Google Maps) y un servicio de
cartografía ofrecidos por algún proveedor de mapas.
MTG
Página 37
SAD
Todos los datos referentes a la personalización y al sector geográfico se pueden
encontrar en una base de datos externa. Por lo tanto es necesario usar un protocolo
universal como tecnología ODBC.
7. Realización de Casos de uso
La siguiente tabla muestra los componentes que satisfacen los casos de uso más
relevantes del sistema.
Componente
Código Caso de Uso
Consulta LBS
CU 2
Sistema Web
CU 3
Sistema Personalización
CU 4
Estos tres componentes son los que resuelven los casos de uso más relevantes porque
comprende consultar el LBS de parqueaderos públicos, que en este caso es la
funcionalidad principal; y al asegurar este caso de uso, se establece varias tareas básicas
de comunicación entre componentes. Por otro lado, el sistema Web junto con la
personalización, garantiza la parte más importante de esta última ya que representa el
valor agregado que tiene este LBS con otros servicios similares.
MTG
Página 38
SAD
8. Vista de Procesos
Se define proceso como la agrupación de tareas que forman una unidad ejecutable, en
nuestro caso se mostraran los procesos que se hacen necesarios para correcto
funcionamiento de la aplicación.
8.1
Diagrama de procesos
Ilustración 3: Vista de Procesos
MTG
Página 39
SAD
8.2
Descripción
En el diagrama de procesos (anexo 4) se puede apreciar como cada proceso cíclico de
cada cliente y empresa se comunican a través del protocolo HTTP con el proceso donde
está ubicado patrón MVC (modelo-vista-controlador).Este patrón descrito por Gamma
[GAMM et AL 1994] (33)para la construcción de aplicaciones para el sistema operativo
SmallTalk, es y sigue usado principalmente para abstraer las principales vistas en un
paradigma de lenguaje orientado objeto. Enseguida, este modelo se puede enlazar por
RMI o CORBA (sí es necesario) a un proceso dónde se encuentra un receptor de
peticiones. Este último, se encarga de tomar la información correspondiente al proceso
cíclico de geo-codificación por el protocolo SOAP, o un API para el proceso cíclico de la
cartografía. De igual forma, el proceso de recepciones de peticiones establece
comunicación con la base de datos de AGG-JMM con tecnología ODBC (de forma
bidireccional).
9. Vista de Desarrollo
La vista de desarrollo o despliegue se enfoca en la organización de los módulos software
en el entorno de desarrollo. El software es empaquetado en pequeños trozos (librerías de
programa, subsistemas, componentes, etc.), los subsistemas se organizan en capas
jerárquicas, y cada capa proporciona una interfaz bien definida a sus capas superiores.
MTG
Página 40
SAD
9.1
Diagrama
Ilustración 4: Vista de Desarrollo
MTG
Página 41
SAD
9.2
Descripción
El diagrama de desarrollo (incluida en mayor tamaño en el Anexo 7) identifica 4 grandes
paquetes: Presentación, Lógica, Modelo de datos y Persistencia.
Dentro del paquete de Presentación se encuentran los siguientes sub paquetes:
Vista, Modelo y Controlador
Dentro del paquete de Vista se encuentra:

Editar JSP

Registro JSP

Estadisticas JSP

Sistema JSP

Publicidad.JSP

MapaGeneral.JSP

InicioAdministrativo. JSP

InicioEmpresarial. JSP

SistemaAdmin. JSP

Editar. JSP

ListaEmpresas. JSP

ListaParqueaderos. JSP

Inicio. JSP (LOGIN)

Error.JSP
Dentro del paquete de Modelo se encuentra:

Editar JAVA

Registro JAVA

Estadisticas JAVA

Sistema JAVA

Publicidad. JAVA

MapaGeneral. JAVA

InicioAdministrativo. JAVA

InicioEmpresarial. JAVA

SistemaAdmin. JAVA

Editar. JAVA

ListaEmpresas. JAVA

ListaParqueaderos. JAVA

Inicio. JAVA
MTG
Página 42
SAD
Y dentro del paquete de Controlador se encuentran los servlets de control
Por otro lado,el paquete de Lógica se posee:

ManejadorAsociaciones

ManjadorEmpresa

ManejadorUsuario

ManejadorSistema
Dentro del paquete de Modelo de Datos se encuentra las entidades de persistencia
Dentro del paquete de Persistencia se encuentra:

Asociaciones

metaDatosParqueadero (representan los datos adicionales que pueden brindar valor)

metaDatosEmpresa

Preferencias

Empresas

Publicidad

Parqueadero

Usuario
Y como subpaquete un paquete llamado Controladores


Asociaciones. JPAController
metaDatosParqueadero. JPAController
(representan los datos adicionales que pueden brindar valor)

metaDatosEmpresa. JPAController

Preferencias. JPAController

Empresas. JPAController

Publicidad. JPAController

Parqueadero. JPAController

Usuario. JPAController
Y como sub paquete, un paquete llamado Exception con
MTG

IllegalOrphanException

PreexistingEntityException

NonexistentEntityException
Página 43
SAD
10.
Vista de Despliegue
El diagrama de despliegue nos muestra las relaciones físicas entre los
componentes de hardware y software en el sistema final esto quiere decir que se
ve como el software se ejecuta sobre una red de computadoras o nodos de
procesamiento.
A continuación, se describe primero el diagrama físico para mayor comprensión de
la vista de despliegue.
10.1 Diagrama Físico
Ilustración 5: diagrama Físico
MTG
Página 44
SAD
10.2 Descripción
Observando el diagrama (anexo 5) desde el centro, el sistema de AGG-JMM se
compone principalmente por:

Un servidor web, que se encarga de transferir las páginas web a los
clientes.

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 el LBS de parqueaderos públicos en
Bogotá, son archivos en formato KML.

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. Otros servicios podrían ser
Yahoo Maps, mapas.com, mapas publicar entre otros.
Sistema empresa, en el caso de la aplicación LBS descrita en el anexo 1 SRS,
representa todos las empresas que ofrecen servicios de parqueaderos públicos en
la ciudad de Bogotá. Otros sistemas empresa podrían ser empresas que deseen
ofrecer servicios de información o publicidad similares a este, como por ejemplo
restaurantes, centros comerciales, museos y cualquier otro establecimiento que
desee una fuerte personalización a través de los dispositivos móviles.
MTG
Página 45
SAD
Sistema externo, es el sistema dónde se encuentra los usuarios con sus
dispositivos móviles, que en el caso de la aplicación LBS del anexo 1 SRS, son
teléfonos celulares con características descritas en dicho documento. En otros
LBS similares, podrían ser diferentes las características de los teléfonos celulares,
otros dispositivos móviles y hasta otro tipo mercado de usuarios.
10.3 Diagrama de despliegue
Ilustración 6: Vista de Despliegue
MTG
Página 46
SAD
10.4 Descripción
(El diagrama está en mayor escala en el anexo 8)
Por empezar, para el componente de dispositivo móvil, en esta aplicación LBS para
los parqueaderos públicos de Bogotá descrito en el anexo1 del SRS, son únicamente
los teléfonos celulares que se ajustan a las restricciones descritas en el mismo anexo.
Enseguida, el componente de PC es referente al computador de escritorio (desktop) o
computador móvil (laptop) descrito con características en el SRS. Ambos
componentes se enlazan a la red de Internet, por el protocolo Hypertext transfer
(HTTP), descrito por la Internet Society en el RFC 2616 [INTER 1999] (31) a través de
cualquier navegador (browser).Cabe anotar, que podría remplazarse por otro
protocolo, por ejemplo HTTPS sí dicho LBS se específica que debe poseer una alta
seguridad en sus transferencias.
El componente web, es donde reside un contenedor web que posee el objeto de la
presentación, lugar donde surge el MVC. En el caso de LBS descrito en el documento
SRS, se usa la herramienta de Apache Tomcat, pero se podría otra.
Cabe aclarar que en la a arquitectura de J2EE se asume que un web container es
recibido por un web server del mismo vendedor, así que no especifica el contrato entre
estas dos entidades; de igual forma un web server puede recibir unos o más web
containers[J2EE 2010] . Además el web server, solamente recibe peticiones por
HTTP, las interpreta, procesa las correspondientes respuestas y las envía a los
clientes apropiados o web browsers.
Por otro lado, aunque en el diagrama está escrito contenedor web, no se pretende a
que únicamente se haga alusión a la arquitectura de J2EE y que se use únicamente
el lenguaje JAVA; sin embargo usar containers, crea que la entidad pueda proveer
gestionamiento de ciclo de vida, seguridad, despliegue y servicios en tiempo de
ejecución de componentes J2EE, características que seguramente serán deseadas
en otros LBS que utilicen tecnologías de plataforma como J2ME para aplicaciones
MTG
Página 47
SAD
en los dispositivos móviles y pequeños.[J2ME 2010] (34) (En este caso, el LBS de
parqueaderos públicos de Bogotá, en su aplicación de Google Maps, usa en lenguaje
JAVA y J2ME).
Continuando con la descripción, el componente de presentación establece
comunicación por medio de tecnología RMI o CORBA al componente del servidor de
aplicaciones. Este último puede ser una excelente alternativa para sitios Web de alto
tráfico, como por ejemplo poder gestionar solicitudes de una gran multitud de clientes ,
consultando de forma paralela o simultanea LBS como el de parqueaderos públicos
en Bogotá u otros que exijan una alta confiabilidad y tolerancia a fallas similares a
ataques de denegación de servicios(DoS).
Por último, en este componente se encuentra la lógica del negocio, y el componente
persistente que se comunica de forma bidireccional por medio de tecnología ODBC a
una base de datos.
11.
Vista de Datos
11.1 Diagrama entidad/relación que modela el sistema AGG-JMM.
(Tamaño mayor en el anexo 3)
MTG
Página 48
SAD
Ilustración 7: vista de Datos
11.2 Descripción
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.
MTG
Página 49
SAD
12.
Tamaño y Desempeño
La arquitectura de software orienta sus esfuerzos en brindar una solución clara y rápida
al momento de construir un middleware para los servicios basados en la localización
similares al propuesto en el documento SRS, anexo 2, el cual detalla su tamaño y
alcance.
En cuanto al desempeño, los tiempos requeridos y esperados del LBS son de máximo 5
minutos, sin tener en cuenta algún problema técnico ajeno a la construcción del
middleware.
13.
Calidad
Para mayor información remitirse al documento SRS, anexo 2 donde se encuentran
especificadas las diferentes métricas de calidad y como estas serán medidas.
14.
Anexos
Anexo 2: Documento de especificación de requerimientos de software (SRS)
Diagramas:
Anexo 1: Diagrama de casos de uso
Anexo 3: Diagrama de modelo de dominio
Anexo 4: Diagrama de procesos
Anexo 5: Diagrama Físico
Anexo 6: Diagrama de Lógico
Anexo 7: Diagrama de desarrollo
Anexo 8: Diagrama de despliegue
MTG
Página 50
SAD
15.
Referencias y Bibliografía
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. GLOS, J2EE. J2EE 1.4 Glossary. java.sun.com. [Online] [Cited: 1 1, 2010.]
http://java.sun.com/javaee/reference/glossary/index.jsp#89338.
3. Pc magazine. CORBA Definition from Pc Magazine. pcmag.com. [Online] [Cited: 1 10,
2010.] http://www.pcmag.com/encyclopedia_term/0,2542,t=CORBA&i=40365,00.asp.
4. 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.
5. Pc magazine. DCOM Definition from Pc Magazine. pcmag.com. [Online] [Cited: 1 10,
2010.]
http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3DDCOM&i%3D40970%2C
00.asp.
6. European space agency. ESA NAVIGATION. ESA Galileo Navigation. [Online] [Cited:
1 10, 2010.] http://www.esa.int/esaNA/galileo.html.
7. 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/.
8. Global positioning system. www.gps.com. [Online] [Cited: 1 10, 210.]
http://www.gps.gov/systems/gps/index.html.
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.
MTG
Página 51
SAD
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. Pc Magazine. ODBC Definition from Pc Magazine. Pcmag.com. [Online] [Cited: 1 10,
2010.] http://www.pcmag.com/encyclopedia_term/0,2542,t=ODBC&i=48273,00.asp.
15. 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.
16. Pcmag. RMI definition from Pc Magazine. pcmag.com. [Online] [Cited: 1 10, 2010.]
http://www.pcmag.com/encyclopedia_term/0,2542,t=RMI&i=50570,00.asp.
17. PcMag. RMI IIOP Definition from Pc Magazine. pcmag.com. [Online] [Cited: 1 10,
2010.]
http://www.pcmag.com/encyclopedia_term/0,2542,t=RMI+over+IIOP&i=50571,00.asp.
18. Pc Magazine. RPC definition from Pc Magazine. pcmag.com. [Online] [Cited: 1 10,
2010.]
http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3DRPC&i%3D50652%2C00.
asp.
19. SMART project requirements. project-management.bestmanagementarticles.com.
[Online] [Cited: 1 10, 2010.] http://project-management.bestmanagementarticles.com/a9353-smart-project-requirements.aspx.
20. servidores de páginas "web servers" y java applications servers.
http://www.osmosislatina.com. [En línea] [Citado el: 1 de 1 de 2010.]
http://www.osmosislatina.com/aplicaciones/servidor_web.htm.
21. Pc Magazine. Smalltalk a definition from pc magazine. pcmag.com. [Online] [Cited: 1
10, 2010.]
http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3DSmalltalk&i%3D51493%2
C00.asp.
22. 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.
23. Pc Magazine. SOAP Definition from Pc Magazine. pcmag.com. [Online] [Cited: 1 12,
2010.]
http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3DSOAP&i%3D51602%2C0
0.asp.
MTG
Página 52
SAD
24. —. SQL Definition from Pc Magazine. pcmag.com. [Online] [Cited: 1 10, 2010.]
http://www.pcmag.com/encyclopedia_term/0%2C2542%2Ct%3DSQL&i%3D51902%2C00.
asp.
25. Wrinting software requirement specifications. http://www.techwr-l.com. [Online] [Cited:
1 10, 2010.] http://www.techwrl.com/techwhirl/magazine/writing/softwarerequirementspecs.html.
26. pcmag.com. UML Definition from PC Magazine. www.pcmag.com. [Online] [Cited: 1
10, 2010.] http://www.pcmag.com/encyclopedia_term/0,2542,t=UML&i=53392,00.asp.
27. Krutchen, Phillip. 4+1view-architecture.pdf. Architectural Blueprints—The “4+1” View.
[Online] noviembre 2005. http://www.cs.ubc.ca/~gregor/teaching/papers/4+1viewarchitecture.pdf.
28. Object Management Group-UML. UML Resource page. [En línea] [Citado el: 20 de
abril de 20.] http://www.uml.org/.
29. Object Management Group. OMG We set the Standards. [En línea] [Citado el: 2 de 4
de 2010.] http://www.omg.org/.
30. H.Dutoit, Bernd Bruegge & Allen. A deeper view into UML. Object-oriented software
engineering:Conquering complex and changing systems. Pittsburg : Prentice Hall, 1999.
31. Internet Society. RFC 2616 Hyper text transfer protocol. www.faqs.org. [Online]
[Cited: 1 1, 2010.] http://www.faqs.org/rfcs/rfc2616.html.
32. W3 Consortium. SOAP version 1.2 Messaging Framework. W3C Recomendations.
[Online] 2007. [Cited: 3 10, 2010.] http://www.w3.org/TR/soap12-part1/.
33. Eric Gamma, Richard Helm,Ralph Johnson,John Vlissides. Design Patterns in
Smalltalk MVC. Design Patterns:Elements or Reusable Object-Oriented Software. 1994.
34. J2ME Glossary. http://www.info4java.com. [Online] [Cited: 1 1, 2010.]
http://www.info4java.com/?this=j2me_glossary.
35. http://www.iana.org/assignments/port-numbers. IANA. [Online] [Cited: 2 1, 2010.]
http://www.iana.org/assignments/port-numbers.
36. 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/.
37. W3C. WORLD WIDE CONSORTIUM. [En línea] 10 de 3 de 2010. http://www.w3.org/.
MTG
Página 53
SAD
38. Robertson, James & Suzanne. Volere Requirements Resources. Requirements
Specification Template. [Online] Atlantic Systems Guild, abril 14, 2005.
http://www.volere.co.uk/template.htm.
39. 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/MAM452754.
40. RFC791. http://www.rfc-es.org. [En línea] http://www.rfc-es.org/rfc/rfc0791-es.txt.
41. Tanenbaum, Andrew S. Computer Networks - Fourth Edition . s.l. : Prentice Hall
International Editions.
42. http://www.rfc-es.org. rfc768. [En línea] http://www.rfc-es.org/rfc/rfc0768-es.txt.
43. 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.
44. 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.
45. el sistema operativo GNU. www.gnu.org. [En línea] [Citado el: 10 de 1 de 2010.]
http://www.gnu.org/home.es.html.
46. gsmworld.com. History GSM World. gsmworld.com. [Online] [Cited: 1 10, 2010.]
http://gsmworld.com/about-us/history.htm.
47. 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 .
MTG
Página 54