Proyecto:

Simulador de Finanzas

Documento de Arquitectura del Sistema

(SAD)

Equipo de Trabajo:

Duran Acevedo Michael Daniel, Ramos Fabián Alexander, Perilla John Edwin

TABLA DE CONTENIDO

TABLA DE
CONTENIDO........................................................................................................................
............. 2
LISTADO DE
FIGURAS..............................................................................................................................
.......... 4
LISTADO DE
TABLAS................................................................................................................................
.......... 5
SECCION 1: DESCRIPCIÓN DEL
DOCUMENTO..................................................................................... 6
(Listado de documentos relevantes, utilizados durante el desarrollo de la arquitectura) 7
SECCION 2: GENERALIDADES DEL
PROYECTO.................................................................................. 8
2.1 Problema a
Resolver.............................................................................................................................. 8
2.2 Descripción General del Sistema a Desarrollar....................................................................
8
2.3
Objetivos................................................................................................................................
........................ 9
Objetivos en términos de gestión de información................................................................. 9
Objetivos en términos de valor agregado ofrecido al usuario o al negocio........ 9
2.4
Stakeholders...........................................................................................................................
.................. 10
SECCION 3: MOTIVADORES Y FUERZAS
EXTERNAS.................................................................... 12
3.1 Motivadores de
Negocio................................................................................................................... 12
3.2
Restricciones..........................................................................................................................
.................. 13
Restricciones de
Tecnología............................................................................................................. 13
Restricciones de
Negocio..................................................................................................................... 13
SECCION 4:
CONTEXTO..........................................................................................................................
......... 14
4.1 Escenarios
Operacionales................................................................................................................ 14
4.3 Casos de
Uso.........................................................................................................................................
... 15
SECCION 5: REQUERIMIENTOS DE
CALIDAD................................................................................... 18
5.1 Árbol de
Utilidad..................................................................................................................................
18
5.2 Escenarios de Calidad
Priorizados........................................................................................... 19
SECCION 6: PUNTOS DE
VISTA................................................................................................................. 21
6.1 Punto de Vista
Funcional................................................................................................................. 21
6.1.1 Modelo de
Componentes........................................................................................................ 21
6.2 Punto de Vista de
Despliegue........................................................................................................ 22
6.2.1 Modelos de Plataforma de Ejecución..............................................................................
22
6.2.3 Modelos de
Red............................................................................................................................ 24
6.3 Punto de Vista de
Información..................................................................................................... 25
6.3.1
Descripción............................................................................................................................
.......... 25
6.3.2.1. Modelos de Estructuras (Conceptual-Clases)..................................................... 26
6.3.2.2. Modelos de Estructuras Estáticas de Datos........................................................... 27
6.3.3 Modelos de Flujo de Información.....................................................................................
28
6.4 Punto de Vista de
Concurrencia.................................................................................................. 30
6.4.1
Descripción............................................................................................................................
.......... 30
6.4.2 Modelo de
Concurrencia......................................................................................................... 30
SECCION 7: RELACIONES ENTRE LOS PUNTOS DE
VISTA..................................................... 31
SECCION 8: RETOS Y
FUTURO................................................................................................................... 33

LISTADO DE FIGURAS
 LISTADO DE TABLAS

SECCION 1: DESCRIPCIÓ N DEL DOCUMENTO

1.1 Propó sito y Audiencia

Este documento describe la arquitectura del Sistema de simulación financiera, que tiene como
propósito proveer un sistema de información vía web o móvil que brinde guía sus
usuarios acerca de la administración de las finanzas personales por medio del ingreso de
algunos datos básicos con los cuales el software se alimentara y comenzara a realizar
análisis para parametrizar y ajustarse a las necesidades del cliente.

Durante el desarrollo del documento se ilustran las decisiones de arquitectura que responden
a las necesidades, intereses y expectativas de cada interesado en el proyecto, entre
quienes se encuentran:

· Personas naturales: Usuario interesado en acceder a un guía de administración de

ingresos y egresos, manejando estos como un flujo de caja en relación al tiempo.
· Comercios: Usuarios interesados en acceder a un segmente de información tratada
con fines lucrativos en mercadeo.
 1.2 Organizació n del Documento
Este documento está dividido en secciones la primera de las cuales describe el documento.
La segunda sección corresponde a las generalidades del proyecto, explicando el problema
a resolver, el sistema a desarrollar, los objetivos y los interesados. La tercera sección
incluye los motivadores de negocio y las restricciones. La cuarta sección incluye la
descripción de los escenarios operacionales, de las entidades y los casos de uso que
representan los requerimientos funcionales del sistema. A partir de la sección cinco se
desarrollan los atributos de calidad a ser atendidos por el sistema, los cuales se presentan
de forma detallada en puntos de vista funcional, de despliegue de información, de
concurrencia y de desarrollo. Finalmente, en la sección seis y siete se relacionan los
diferentes puntos de vista.

1.3 Convenciones
(Descripción de las notaciones y símbolos utilizados en este documento)

1.4 Terminología y Definiciones

· Simulación
· Modelo de composición
· Metho Ontology
· Ontología
· Web Semántica
· Software
· Aplicación Mobil
· Base de datos
· Tabla
· campo

1.5 Documentos Relevantes

(Listado de documentos relevantes, utilizados durante el desarrollo de la arquitectura)

 SECCION 2: GENERALIDADES DEL PROYECTO

2.1 Problema a Resolver

En la actualidad se presenta una problemática latente en las finanzas de las personas naturales, esto
debido a que no saben cómo administrar su dinero, pierden la noción de la relación del gasto.
Según (Mejía, Pallotta, Egúsquiza, & Farnè , 2015), quienes realizaron una encuesta en la cual
fueron consultados un grupo de 1.726 nacionales de todos los niveles socioeconómicos para
analizar y determinar cómo organizan sus finanzas personales. Los resultados no fueron los
mejores, pese a que se tiene un conocimiento básico sobre finanzas y son de
conocimiento popular algunas buenas prácticas como la importancia de ahorrar,
elaborar un presupuesto y ceñirse a este, el sondeo arrojó que el 85% de
encuestados manifiestan tener control y disciplina sobre sobre el manejo de su
dinero, sin embargo la encuesta permitió determinar que una suma menor a la
mitad sabe cuánto gastó hace una semana. El 95 % dijo planificar el uso de sus
ingresos; pero contrario a esto, el 47 % no tiene idea de cuánto tiene para sus
gastos diarios. Finalizando el 89 % dice haber aprendido a manejar su dinero
viendo los errores de los demás; no obstante, solo el 24 % está en capacidad de
cubrir gastos imprevistos.

2.2 Descripción General del Sistema a Desarrollar

Contar con una aplicación capaz de integrar modelos de conocimiento y matemáticos

enfocados a los negocios y la economía de las personas como primera fase, la misma que
incluirá amplias funcionalidades para un manejo de finanzas personales, ayudando a los
usuarios que la consulten a identificar la mejor manera de gastar, invertir, destinar o
ahorrar su dinero, esta herramienta toma como eje principal la optimización financiera,
para que ajuste y diseñe una estructura de gastos o presupuesto a la medida para cada
persona según sus ingresos y egresos, como segunda fase se propone construir un
ambiente para que se generen actividades de intercambio, compra o venta de artículos de
necesidad para los implicados teniendo en cuenta el sistema realizará la búsqueda de los
elementos deseados basado en factores como precio, calidad y otros compendios.

La aplicación proveerá la siguiente información:

 · Flujo de caja del usuario en gráfica
· Proyección de gastos en relación al tiempo
· Estándares de administración de gastos (Consejos o guías de gastos de efectivo)
· Información segmentada y tratada, para la venta al mercado comercial(Minería de
datos)
· Espacio de venta y compra de artículos o servicios.

2.3 Objetivos
Desarrollar un software basado en modelo estadístico. Esta aplicación estará en la capacidad de
organizar un presupuesto para personas naturales según ingresos, egreso, donde se tendrá la
posibilidad de generar un reporte con los estados de cuenta.
1. Diseñar un modelo de conocimientos basado en negocios y economía para estandarizar los
conceptos y generar flujos de proceso más estables capaces de asesorar a los usuarios en las
decisiones relacionadas con el dinero que este cuenta, gasta o invierte, además de proponer una
alternativa a la compra comercial común generando un ambiente para el cambio, compra o venta
de artículos.
2. Establecer una semántica común para realizar la abstracción pura de conocimientos relacionados a
los negocios y la economía de las personas que realizan consultas, además de hacer el debido
tratamiento a la información mediante las siguientes tecnologías:
● RDF: Para la lectura y escritura en un mismo idioma o lenguaje.
● SPARQL: Diseño de consultas para la extracción de información
● OWL: El cual permite generar razonamiento sobre los datos o información captados.

3. Diseñar un prototipo de software para que pueda ser evaluado como una versión beta en
demo donde se pueda ingresar datos de sueldo y gastos realizados.

Objetivos en términos de gestión de información[S1]

Objetivos en términos de valor agregado ofrecido al usuario o al negocio [S2]

· Desarrollar un documento de arquitectura claro que pueda ser utilizado por un equipo
de desarrollo de Software para implementar la aplicación siguiendo un ciclo de vida en
cascada.
 · Responder a los motivadores de negocio con una arquitectura que favorezca los
atributos de calidad principales, teniendo en cuenta los límites impuestos por las
restricciones de negocio.

2.4 Stakeholders

Tabla 1: Listado de los Stakeholders

Stakeholder Descripció n

Personas natural Usuarios finales del sistema

Desarrolladores Miembros del equipo de desarrollo del proyecto y demás

personal responsable de diseño detallado, implementación,
gerencia técnica, pruebas, análisis de resultados, así como
especialistas de control de calidad

Administradores Personas responsables de mantener en operación la

infraestructura y el software del sistema InfoParking una vez
implementado.

Tabla 2: Stakeholders y Expectativas

Stakeholder Expectativas

Personas con vehículo particular que se Este grupo de interesados esperan obtener información de
movilizan con frecuencia por la zona valor para la selección de parqueaderos (Ubicación,
centro requiriendo estacionamiento. Disponibilidad, Tarifas, Características, Horarios, Servicios
Adicionales, etc.).

Administradores de los parqueaderos de Este grupo de interesados espera optimizar su nivel de

la zona seleccionada. ocupación de cupos de parqueo, dando a conocer sus
 servicios y servicios de valor agregado (diferenciadores). A
través de la herramienta.

Desarrolladores. Este grupo es encargado de la implementación, espera una

arquitectura clara, precisa y sin ambigüedades, que refleje
las necesidades del público objetivo, las restricciones del
negocio y las limitaciones tecnológicas.

Administradores y operadores del Este grupo espera una arquitectura que considere aspectos
sistema. de operación y administración lo suficientemente claros para
facilitar su trabajo.

SECCION 3: MOTIVADORES Y FUERZAS EXTERNAS

3.1 Motivadores de Negocio

Esta sección busca identificar los motivadores de negocio de la organización. Normalmente estos motivadores son encontrados,
respondiendo a las preguntas:
- Cómo genera utilidad la organización
- De dónde provienen las utilidades de la organización?
- Cuáles son los elementos claves del negocio?
En resumen, un motivador de negocio es una descripción corta que define clara y específicamente los resultados deseados de
negocio de una organización así como las actividades necesarias para lograrlos. Los motivadores de negocio deben ser:
Específicos, Medibles, Agresivos pero viables, Orientados al resultado y limitados en el tiempo.
El objetivo es hacer una lista priorizada de motivadores de negocio.

Ayuda para su uso:

- El nombre del motivador: Sigue en general la regla: <verbo> + <elemento a medir> + <área de énfasis>
o Ejemplo: Incrementar ventas en las áreas metropolitanas
- La descripción del motivador: Sigue en general la regla: <Retorno esperado del negocio>+ Mediante+ <Actividad
planeada de negocio>
o Ejemplo: Incrementar ventas en 15 % mediante la apertura de nuevas oficinas
- La medida: Define en una frase como valorar el impacto en el negocio del motivador. Se organiza por rangos y se
determina para cada rango, la unidad de medida del impacto. Adicionalmente, se definen los valores mínimos y máximos
para cada rango de impacto.
o Ejemplo:
o Medida: Crecimiento de las ventas en áreas metropolitanas medido en millones de pesos
Ninguna : 0 – 0.9 millones
Bajo: 1 millón – 99 millones
Moderado: 100 y 499 millones
Fuerte: 500 y 899 millones
Muy Fuerte: 900 millones o más
- La asociación con el negocio define el motivador a que área organizacional pertenece:
o Ejemplo:
o Definido Por: Gerente de Ventas
o Ejecutado Por: Director y Ejecutivos de Ventas
o Ubicación en el portafolio: Servicios persona a persona

Nombre del Motivador Descripción del Motivador de Negocio

de Negocio

Eficiencia Operacional Aumentar y mantener la eficiencia en la ocupación de los

parqueaderos de la localidad de Teusaquillo, mediante el marketing y
gestión de la ocupación a través de InfoParking.

Estrategias a Seguir

Facilitar al usuario final la identificación de parqueaderos cercanos con disponibilidad, dando a conocer
las características y servicios del valor agregado de cada parqueadero.

Rangos Cota Mínima Cota Máxima

Ninguno 0% 20%
Bajo 21% 40%

Moderado 41% 60%

Fuerte 61% 80%

Muy Fuerte 81% 99%

Definido Por: Usuarios del Sistema

Asociación del Motivador con

el Negocio Equipo de desarrollo de InfoParking
Ejecutado Por:

3.2 Restricciones
(Esta secció n describe las restricciones de tecnología y de negocio impuestas por la
organizació n o el contexto del problema)
Restricciones de Tecnología

ID Restricción: Nombre: Tipo:

Aplicación web de registro y control de gastos Tecnología (X ) Negocio ( )
personales

Descripción: La aplicacion debera permitir las consultas de manera web

Establecida por: Administradores del perfil

Alternativas:

El usuario podrá elegir los rangos de fecha

Observaciones:

Ninguna

Restricciones de Negocio
ID Restricción: Nombre: Tiempo de Desarrollo Tipo:
Tecnología ( ) Negocio
( X ) |+-
*|741856

Descripción: El tiempo de desarrollo no debe superar dos meses y la palicacion estar en lenguaje java

Establecida por: Universidad minuto de Dios ( semillero Athenea)

Alternativas: Ninguna

Observaciones: Ninguna

SECCION 4: CONTEXTO

4.1 Escenarios Operacionales

Título del Escenario Operacional:

Marketing y Gestión de Ocupación de Parqueadero

Stakeholder Asociado Administradores de aplicación web ID EO-01

Administrador de base de datos, Cliente

Consideración Operacional Respuesta del Stakeholder

Descripción general de la El Administrador del parqueadero, podrá actualizar los datos del parqueadero,
funcionalidad dando a conocer sus servicios de valor agregado y diferenciadores. Así como
gestionar las reservar en línea realizadas por los clientes.
El administrador de aplicacion financial Advisor podra actualizar y aprobar
los usuarios registrados, así mismo gestionar y los reportes finales al cliente.

Describa lo que el Stakeholder Actualmente el Administrador de la aplicación va revisar usuarios creados y

hace ahora o le gustaría poder verificar quye se encuentren con datos correctos (nombres, apellidos y coreos
hacer válidos ) del parqueadero da a conocer sus servicios (Características, Horarios,
Servicios Adicionales, Promociones, etc.) a través de pendones ubicados a la
entrada del parqueadero

Describa cualquier entrada El Administrador del parqueadero proveerá los datos asociados al parqueadero.
provista o disponible al momento El registro inicial del parqueadero será realizado por el Administrador del
del inicio sistema al momento de la afiliación.

Describa cómo el sistema debe El sistema debe almacenar los datos del usuario y mostrarlos cuando un cliente
responder consulte su información.

Describa las salidas que el sistema Visualización de los datos del presupuesto y generar un reporte de los estados
produce como resultado de la de cuenta del cliente con los gastado vs sus ingresos .
acción

Describa quién o qué usa la salida La Aplicación es usada por personas naturales para control y gestión de gastos
y para que es utilizada personales.

Nombre de la Entidad registro de usuarios ID EN-02

Descripción:

Provee:
Información actualizada sobre el parqueadero (s) a cargo

Requiere:
Herramienta de marketing y gestión de ocupación que le permita optimizar su eficiencia operacional.
Casos de Uso: CU-02, CU-07

Nombre de la Entidad Cliente ID EN-03

Descripción:
Usuario final del sistema, que se moviliza en su vehículo

Provee:
Información de localización (Latitud, Longitud)

Requiere: Información fiable y oportuna en tiempo real sobre los parqueaderos a una dirección de
interés.

Casos de Uso: CU-02, CU-04, CU-05, CU-06

4.3 Casos de Uso

Título del Caso de Uso Administrar Usuarios del Sistema ID del Caso de Uso CU-01

Descripción General del Caso de Uso

Este caso describe cómo se administran usuarios del sistema.

Entidades Involucradas

Cliente, Administrador del sistema, Administrador de usuarios

Precondiciones

Ingresar al sistema con el rol de Administrador

Flujo normal de Eventos

1 El actor ingresa datos de usuario

2 Sistema valida existencia de usuario

3 El actor asigna un rol al usuario (administrador de Financial Advisor)

4 Sistema registra la información ingresada y muestra un mensaje con el resultado de la

transacción.

Postcondiciones principales del caso de uso

Usuario tiene un rol para ver determinadas funcionalidades en el sistema.

Título del Caso de Uso Ingresar al Sistema ID del Caso de Uso CU-02

Descripción General del Caso de Uso

Este caso describe como se ingresa al sistema.

Entidades Involucradas

Cliente, administrador del sistema

Precondiciones

Usuarios creados en sistema

Flujo normal de Eventos

1 El actor ingresa nombre de usuario

2 El sistema valida existencia de usuario

3 El actor ingresa contraseña

4 El sistema valida contraseña válida para usuario

Postcondiciones principales del caso de uso

Usuario en línea.

Caminos de Excepción

Si no se escribe contraseña correcta, no hay ingreso y se comunica al usuario.

Título del Caso de Uso Crear Usuario ID del Caso de Uso CU-03

Descripción General del Caso de Uso

Este caso describe como se crea un usuario nuevo en la aplicación.

Entidades Involucradas

Usuario

Precondiciones

Ingresar en el sistema con el rol de administrador del sistema ingresa a la aplicación como usuario final

Flujo normal de Eventos

1 El actor hace clic en la opción registrar usuario

2 El sistema retorna el formulario solicitando datos.

3 El actor ingresa los valores solicitados y hace clic en registrar

4 El sistema valida que no se duplique el usuario nos esté duplicado y que se ingresen datos
válidos , si esta correcto retorna un mensaje con el resultado de la transacción.

Postcondiciones principales del caso de uso

El usuario es visible en el sistema

Caminos de Excepción

N/A

Título del Caso de Uso Ver información de gastos ID del Caso de Uso CU-04

Descripción General del Caso de Uso

Este caso describe cómo se puede ver la información de los ingresos vs egresos, según los criterios de
búsqueda

Entidades Involucradas

Cliente
Precondiciones

Usuarios creados en sistema, Financial Advisor, información sobre disponibilidad de recursos (saldo de
dinero)

Flujo normal de Eventos

1 El cliente selecciona la opción ver saldo

2 El sistema muestra un reporte con los ingresos vs los egresos registrados por el usuario.

4 El sistema discrimina en el reporte los datos de ingresos por dia y los gastos realizados por el
usuario con días de ejecución.

Postcondiciones principales del caso de uso

Se visualiza información de recursos.

Caminos de Excepción

N/A

Título del Caso de Uso configuración de perfil ID del Caso de Uso CU-06

Descripción General del Caso de Uso

Este caso describe cómo el usuario configura su perfil

Entidades Involucradas

Usuario

Precondiciones

Usuario creados en sistema, configuración de perfil

Flujo normal de Eventos

1 El usuario ingresa las fechas de corte y define los periodos (quincenal o mensual)

2 El sistema retorna un mensaje con las fechas creadas

Postcondiciones principales del caso de uso

Fecha asignada

Caminos de Excepción

N/A

Título del Caso de Uso Notificación de alertas ID del Caso de Uso CU-05

Descripción General del Caso de Uso

Este caso describe cómo se generan notificaciones o alertas al usuario sobre su flujo de efectivo donde
el cliente puede estar enterado de cuánto dinero le queda.

Entidades Involucradas

Usuario

Precondiciones

Notificacion (s) saldo disponible.

Flujo normal de Eventos

1 El sistema genera una alerta los últimos 5 dias o segun periodo asignado por el usuario

2 Sistema muestra un mensaje indicando que está próximo a llegar al límite de efectivo

Postcondiciones principales del caso de uso

Se visualiza un mensaje indicando que los ingresos están llegando al límite

Caminos de Excepción

Tiene más del 40% de sus ingresos aún, no se notifica al usuario

 SECCION 6: PUNTOS DE VISTA

(Esta sección presenta los puntos de vista de la arquitectura del sistema. Comenzando por una breve
descripción de la estrategia arquitectural y un diagrama de contexto que muestre claramente la
frontera del sistema. Es importante identificar en este diagrama de contexto los sistemas externos
con los que se debe interactuar.)

6.1 Punto de Vista Funcional

6.1.1 Modelo de Componentes

A continuación se describe la arquitectura de componentes de la solución:

Figura 2. Modelo de Componentes del Sistema

 6.2 Punto de Vista de Despliegue

6.2.1 Modelos de Plataforma de Ejecució n

El usuario podrá acceder a la aplicación (ingresar, buscar parqueadero, reservar, cancelar

reservas), a través de su celular desde su vehículo o a través de su PC en una ubicación
fija (Ver figura de Arquitectura funcional).
Para administración de información y reserva de parqueaderos, deben existir equipos en cada
parqueadero, así como para el administrador del sistema.

Figura 4. Arquitectura Funcional

A continuación se visualiza el diagrama de despliegue de la solución, donde se visualizar los

componentes que se integran a la arquitectura:

Figura 5. Diagrama de Despliegue

6.2.3 Modelos de Red

Figura 6. Modelo de red

En el anterior diagrama de manera similar al anterior, se muestran como nodos cada uno de
los equipos que pueden conectarse para participar en el servicio.

· Nodo equipo cliente: es el que representa a cada dispositivo móvil o PC, desde el cual
se hacen consultas al sistema. Posee varios componentes de software, pero solo se
destaca en el diagrama el navegador en internet, desde el cual es accede a las
capacidades del sistema.
· Nodo equipo administrador parqueadero: es el que representa a cada equipo desde el
cual el administrador de cada parqueaderos administra su parqueadero. Posee varios
componentes de software, pero solo se destaca en el diagrama el navegador en internet,
desde el cual es accede a las capacidades del sistema.

· Nodo equipo servidor principal: es el que representa a cada equipo desde el cual el
administrador general administra el sistema; allí también están las bases de datos,
librerías, etc. Posee varios componentes de software, pero solo se destaca en el diagrama
sistema como un componente compuesto de otros.

6.3 Punto de Vista de Información

6.3.1 Descripció n

Teniendo en cuenta que los elementos del mundo real se representan en los mapas como:

· Líneas – Elemento grá fico usado como la mínima expresió n espacial, que
define un lugar geométrico. No tiene longitud ni á rea - Escala: 1:20m, Precisió n:
2m de error. Proyecció n: Mercator – costo 0. Se consigue mediante mapas
físicos/electró nicos o en el sitio y registrando las coordenadas en GPS (WGS84)
· Puntos – Elemento grá fico compuesto por uno o varios segmentos
consecutivos, delimitado por un nodo inicio y un nodo fin, que no involucra el
concepto de á rea, solo longitud. - Escala: 1:20m Precisió n: un radio de 30m a la
redonda del sitio. Proyecció n: Mercator – costo: 0, Se consigue mediante mapas
físicos/electró nicos o en el sitio y registrando las coordenadas en GPS
· Polígonos – Elemento grá fico definido por un conjunto de líneas
consecutivas, cerrado y que involucra el concepto de á rea. Tiene longitud
correspondiente a su perímetro y á rea.
· Fotos – Elemento para que el cliente identifique el parqueadero cuando
llegue no solo con la ubicació n suministrada por el sistema. Costo NA
· Horarios, tarifas, convenios. Visita a parqueaderos.
Para representar esta la información, se modela el negocio por medio de las siguientes clases:

Parqueadero: representa la información básica de los parqueaderos

AdministradorSistema: Representa la información de quien es el administrador del sistema.

AdministradorParqueadero: Representa la información de quien es el administrador del

parqueadero, es quien puede hacer actualizaciones sobre información en su respectivo
parqueadero.

Cliente: representa la información de cada cliente como datos de identificación, y sobre lo

que puede hacer desde su usuario en el sistema.

LocalizacionCliente: Representa la información de donde se encuentra o donde se encontraría

un cliente.

Reserva: representa la información de cada reserva hecha por u cliente sobre un lugar en un
parqueadero después de la búsqueda.

Tarifa: representa la información de las tarifas usadas para cobro en cada parqueadero.

Vehículo: Representa la información de cada vehículo que se guarde en el sistema (no es

necesario guardar la información de cada vehículo, pero al tenerla guardada se pude por
defecto enviar datos del vehículo al parqueadero cuando se hace la reserva sin tener que
digitarlos).

Mapa: Representa un mapa con la información necesaria para ver cuadras, calles y puntos
importantes (parqueaderos).

Histórico: Representa la infamación histórica que se tiene por cada parqueadero en cuanto a
reservas realizadas mediante el uso del sistema

6.3.2.1. Modelos de Estructuras (Conceptual-Clases)

Diagrama de Clases

6.3.2.2. Modelos de Estructuras Está ticas de Datos

 Figura 7. Diagrama Relacional
Para representar esta la información, se modela el negocio por medio de las siguientes clases:

Reservas: representa la información de cada reserva hecha por u cliente sobre un lugar en un
parqueadero después de la búsqueda.

Vehículos: Representa la información de cada vehículo que se guarde en el sistema (no es

necesario guardar la información de cada vehículo, pero al tenerla guardada se pude por
defecto enviar datos del vehículo al parqueadero cuando se hace la reserva sin tener que
digitarlos).

Usuarios:

Perfiles:

Parqueaderos: representa la información básica de los parqueaderos

Promociones:

Tarifas: representa la información de las tarifas usadas para cobro en cada parqueadero.

Tarifas_Parqueaderos

Caracteristicas:

Caracteristicas_Parqueaderos:

Histórico: Representa la infamación histórica que se tiene por cada parqueadero en cuanto a
reservas realizadas mediante el uso del sistema

6.3.3 Modelos de Flujo de Informació n

Actividades conductor
 Actividades parqueadero

Actividades Administrador

6.4 Punto de Vista de Concurrencia

6.4.1 Descripció n

6.4.2 Modelo de Concurrencia

Aquí lo que se quiere para manejar la concurrencia es establecer dos escenarios de servicio
necesariamente complementarios: uno será para proveer funcionalidad para mapas, donde la
concurrencia será manejada por el contenedor de jsp’s. El otro escenario quiere manejar el flujo de
mensajes que ocurrirá cada vez que los parqueaderos quieran actualizar el cupo del parqueadero.
La idea es tener un servicio web asíncrono empotrado en el sistema de administración del
parqueadero, el cual enviara un mensaje a infoParking cada vez que ingresa o sale un carro del
parqueadero. Se quieren usar beans de mensajería, los cuales necesariamente son asíncronos y
hacen que el flujo de mensajería se acumule en una cola para ir atendiendo a los mensajes de uno
en uno.
- Estrategias en el diseño de la multitarea
El acceso a un agente debe considerarse como un punto crucial concurrente, por tanto su acceso
debe sincronizarse.
Se plantea el uso de colas de mensajes, tipo publicador/subscriptor con validación de aceptación,
tolerancia a fallas, reintentos y serialización local.
- Abrazos mortales
Para evitar posibles escenarios de abrazos mortales, se optó por el mecanismo de colas de
mensajes para la publicación en el repositorio central, y en los instrumentos de exclusión mutua
(Mutex) en los agentes locales se evitará el uso de recursos comunes que puedan ocasionar una
condición de carrera entre las aplicaciones.

Modelo de concurrencia
 SECCION 7: RELACIONES ENTRE LOS PUNTOS DE VISTA

El objetivo de las diferentes vistas desarrolladas en este documento es presentar las características de la
arquitectura que son relevantes. Principalmente se construyeron modelos que indican la
información relacionada con el sistema en los diferentes aspectos sobre los cuales tendrá
desempeño tales como: su funcionamiento, la localización de los diferentes componentes en una
determinada infraestructura de despliegue y la comunicación que existe con sistemas externos.

Aquí el punto de vista funcional y el de concurrencia muestran que la arquitectura propuesta define una
estrategia de concurrencia manejada por dos elementos diferentes de acuerdo a la funcionalidad
que provee un grupo de componentes. Una de estas estrategias es dejar que el contenedor de jsp’s
maneje esta concurrencia según sus capacidades propias. La otra estrategia permite establecer una
cola de mensajes para irlos atendiendo poco a poco, sobre todo porque en algunas horas, la
solicitud de atención de estos mensajes podría hacer colapsar al sistema.

Sumado a lo anterior tenemos el punto de vista de despliegue, a través de este podemos ver la
interacción física entre los diferentes elementos de hardware que alojan los componentes de la
aplicación. A través de los modelos de esta vista podemos identificar puntos críticos del sistema
sobre los cuales se deben tomar decisiones tecnológicas para favorecer el desempeño y la
disponibilidad del sistema. Es importante resaltar, que se trabajan estrategias de replicación y
redundancia para la correcta inclusión de la tolerancia a fallas.

Se hace una inclusión mínima del punto de vista de información para mostrar el diseño propuesto,
sobre el cual se edifica el modelo relacional implementado en la Base de Datos como mecanismo
principal de persistencia.

En resumen, las vistas ilustran el comportamiento del sistema principalmente bajo el escenario de
comunicación de alarmas y su interacción con otros sistemas a diferentes niveles de abstracción.

SECCION 8: RETOS Y FUTURO

Se tuvieron en cuenta algunos de los retos planteados con el fin de conseguir una herramienta útil y de
fácil operación, de tal manera que no necesitara de usuarios expertos.

Algunos retos se cubrieron en la entrega final de forma total o parcial, y algunos se dejan para una
próxima iteración, pensando en la implementación del sistema más allá de lo académico.

· Interoperabilidad:
La interoperabilidad es básica en el sistema: hay un servicio web que se encarga de enviar la
actualización del cupo de los parqueaderos; esta funcionalidad es consumida en el servidor y allí se
encarga de persistir en la base de datos y tratar de forzar una sincronización de los clientes para
mantener o visualizar así la última versión del cupo.

La información geo-espacial será recolectada por la misma empresa a través de quienes tengan el
rol de administrador del sistema, ya que serán los encargados de ingresar la información básica del
parqueadero. La información que el parqueadero tendrá para darnos, es la que provee a través del
web service, y esta será extraída de la base de datos que maneja el sistema de administración del
parqueadero en sí.

· Privacidad y temas sociales:

El sistema no tendrá muchas funcionalidades para interactuar con redes sociales, tan solo un site
en algunas de ellas (facebook, twitter, etc), de forma que los usuarios puedan darle clic en “me
gusta”, como una forma de publicidad para la marca, pero no podrá indicar que una persona se
encuentra en determinado lugar, sobre todo por cuestiones de seguridad.

La información almacenada en el sistema será la estrictamente necesaria para el negocio, tal como
lo es el nombre, la placa del carro, el rol (dueño, conductor asignado, etc), documentos de
identificación, etc. La administración de InfoParking se encargara de velar cuidadosamente de
estos datos y no permitirá comercializarlos bajo ningún pretexto.

· Para el proyecto InfoParking, es importante tener en cuenta que se pueden extraer

patrones de comportamiento a partir de los datos, que má s allá de las consultas
realizadas al sistema y del resto de informació n que se gestione mediante el uso del
sistema, se puede tener a la mano informació n valiosa para los propietarios de
parqueaderos como de interesados en beneficiarse del uso del sistema.; un reto en este
sentido puede ser, que a partir de los datos provenientes del registro bá sico de clientes,
parqueaderos, de las reservas y de las consultas, se pueda inferir que tipo de sitios son
los que habitualmente se visita (nodos de llegada), que tipo de usuarios visitan
determinado tipo de sitios, se puedan establecer rutas comunes por las cuales se
podrían instalar nuevos parqueaderos o establecimientos que puedan tener
oportunidad de negocio; y por qué no, proveer al usuario del sistema (conductor)
informació n importante sobre el contexto a partir de sus consultas frecuentes y los
resultados de dichas consultas, por ejemplo, si para un usuario, las consultas má s
frecuentes son sobre saber el parqueadero má s cercano a un centro comercial de la zona
establecida en nuestro alcance, se podría brindar informació n sobre otros centros
comerciales que está n má s cerca de su posició n actual, ahorrá ndole tiempo y dinero al
disminuir la distancia a recorrer.

· InfoParking, tendría má s utilidad, si proveyera actualizació n de la vista del mapa de

acuerdo al contexto, por ejemplo, que si hay alguna obra en la zona que pueda desviar al
conductor de la mejor ruta para llegar a su punto final (parqueadero), el encargado de
actualizar el sistema, notifique al sistema de dicha obra y el sistema incluya dicha
informació n en el mapa.

· En cuanto a visualizació n, se podrían tener en cuenta muchos aspectos (mapa con

escala variable, animaciones sobre rutas, etc), pero uno que es relevante y se tiene como
requerimiento desde el principio, es el de dar una vista panorá mica sobre los
 parqueaderos por medio de varias fotos; esto con el fin de brindar má s informació n al
usuario del sistema, por ejemplo, si un conductor solicita informació n sobre el
parqueadero má s cercano a un punto de la ciudad, al ver fotos del parqueadero puede
identificarlo fá cilmente si antes ha estado en la zona, y puede también pensar en la
oportunidad de realizar otras actividades gracias a dicha identificació n.

· La interfaz de usuario se contempla sencilla, así como la operació n del sistema de

forma fá cil; esto con el fin de no obligar a que los usuarios del sistema sean expertos,
que puedan usar dispositivos de diferentes tamañ os y que estén en movimiento o no
(PC, laptop, pda, celulares, etc), no se debe olvidar que el usuario principal del sistema es
un conductor de vehículo, quien puede ser cualquier persona que no debe tener
formació n especial para sacar provecho del sistema.

[S1]???
[S2]???