Proyecto Fin de Carrera - Universidad de...

AUTOR: Francisco José Díaz Borrego

TUTOR: D. José Miguel León Blanco

COTUTOR: D. José Manuel Fornés Rumbao

DEPARTAMENTO: Org.Industrial y Gestión de Empresas I

FECHA: 27 de febrero de 2015

Proyecto Fin de Carrera Plataforma de Inversión Bursátil

Francisco José Díaz Borrego PFC: Plataforma de Inversión Bursátil 1


CAPÍTULO I: ESTADO DEL ARTE


I.1.- Introducción a las operaciones en el mercado de valores

El sistema económico y financiero moderno no es ya concebible sin uno de sus

componentes más relevantes: El Mercado de Valores. Un mercado de capitales donde se

negocia tanto la renta fija como la variable a través de la compraventa de valores

negociables.

El Mercado de Valores o Bolsa fue creado originalmente en los Países Bajos a finales

del Siglo XVI por la Compañía Holandesa de las Indias Orientales, primera compañía

privada de la historia, para negociar participaciones de la misma mediante un sistema de

subastas y financiar así su expansión comercial por todo el mundo. El gran éxito de la

idea, y la enorme capacidad de financiación que le proporcionó a la Compañía

Holandesa de las Indias Orientales, hizo que se extendiera rápidamente por otras

potencias coloniales de la época, emulando el modelo holandés.

Aunque en un principio su propósito fuera únicamente el de comprar y vender acciones

o participaciones de una compañía, posibilitando así su mejor financiación y obteniendo

los inversores una rentabilidad, ya fuera esta especulativa o no, en la actualidad el

Mercado de Valores comprende muchas más actividades que esta, que se han ido

incorporando con el paso del tiempo. Actualmente es posible negociar en los mercados

de valores modernos acciones, títulos de deuda pública, intercambiar divisas, futuros de

valores o materias primas, participaciones en fondos de inversión y productos derivados

de préstamos o hipotecas concedidas por entidades financieras entre una larga lista de

productos.

A pesar de la imagen generalizada en la sociedad, de grandes muchedumbres de

agentes de bolsa negociando a voz en grito el precio de una transacción determinada, en

un edificio majestuoso, con suelo de parqué, ubicado en algún importante enclave

financiero global como Nueva York o Londres, lo cierto es que esta imagen es, de

hecho, más propia de antes de los años ochenta. De aquella época en la que o bien no

existían o bien aún no eran lo suficientemente potentes, rápidos y fiables los

dispositivos informáticos.

A día de hoy la inmensa mayoría de "parqués" de todo el mundo están prácticamente

desiertos incluso en los días más ajetreados, salvo excepciones como la Bolsa de Nueva

York o los corros de la London Metal Exchange donde, más por tradición que por otra

cosa, aún se conservan en cierta medida las negociaciones directas en persona entre

agentes. Si bien es cierto que incluso en los círculos más tradicionales los sistemas de

compra-venta de valores de forma telemática están también muy presentes, y son a

través de los cuales se realiza la práctica totalidad de las transacciones.


I.2.- Plataformas de Inversión Bursátil

La utilidad principal que emplean los inversores para realizar sus operaciones en el

Mercado de Valores es conocida como Plataforma de Inversión. Mediante ella es

posible comprar y vender prácticamente cualquier título que cotice en el cualquier

mercado del mundo a través de una interfaz sencilla y generalmente muy intuitiva y

simple.

Estas Plataformas pueden ser aplicaciones instalables en el PC o terminal del usuario,

ya sea este particular o corporativo, o bien aplicaciones web a las que es posible acceder

desde cualquier lugar mediante la mayoría de los exploradores de internet presentes en

casi la totalidad de los equipos informáticos con conectividad a la red.

Por regla general estas aplicaciones, o el acceso a ellas, son proporcionadas por el

bróker o proveedor de servicios financieros del usuario, no existiendo un formato

estandarizado para las mismas, ya que este depende exclusivamente de los requisitos

que el propietario de la aplicación haya tenido a la hora de su planificación. Por tanto,

aunque todas guardan una línea parecida, principalmente porque tienen que tener una

serie de funcionalidades comunes básicas, no hay dos iguales.

De entre las principales funcionalidades que cualquier plataforma de inversión diseñada

para operar en el mercado de valores debe tener cabe destacar las siguientes:

1.- Capacidad para operar en tiempo real con Acciones, CFDs, ETFs, Futuros, etc.

2.- Presentar datos financieros de los valores integrantes de los principales

mercados sin retraso y con total fiabilidad.

3.- Permitir al usuario la gestión de los valores de su cartera, así como poder llevar

un control del histórico de operaciones realizadas y de las ganancias o pérdidas

generadas.

4.- Capacidad para poner ordenes tanto de compra como de venta que el sistema

deberá ejecutar de manera automática y sin intervención del usuario una vez

se cumplan las condiciones marcadas por este último.

5.- Posibilidad multiplataforma, de manera que el usuario pueda tener acceso a

la herramienta también desde dispositivos móviles.

Además es habitual que estas plataformas incluyan la posibilidad de obtener

información económica de relevancia, una utilidad de análisis de gráficas, calculadoras

de rentabilidades y alertas de precios personalizables.


I.3.- Plataforma de Inversión Instalable

En el presente apartado va a tratar de desgranarse el funcionamiento de una plataforma

de inversión bursátil instalable en un dispositivo. En nuestro caso ese dispositivo será

un PC, pero su funcionamiento es en la práctica idéntico en cualquier otro dispositivo ya

sea tablet o móvil.

La plataforma que hemos tomado como referencia es la plataforma perteneciente al

proveedor de servicios bursátiles "DIF Broker" llamada "DIF Freedom".

I.3.1.- Distribución General

La vista principal de una plataforma de inversión en bolsa guarda siempre un estilo

similar al que puede apreciarse en la siguiente imagen:

En dicha vista principal puede ver un resumen de la cartera del usuario. En este

resumen se da toda la información imprescindible para que el usuario pueda conocer el

estado de su cartera. Se proporcionan datos tales como el saldo líquido, es decir, dinero

que el usuario tiene disponible para realizar operaciones, el dinero no realizado en

posiciones, que es en realidad el valor actual de los activos en cartera, entre otros.

Además se tiene acceso a la mayoría de las funcionalidades de la aplicación gracias a la

barra superior, la cual puede verse con más detalle en la siguiente imagen:


I.3.2.- Principales Funcionalidades

I.3.2.a.- Operaciones a mercado:

La principal funcionalidad de cualquier plataforma de inversión es la compra-venta a

mercado de títulos de cualquier tipo, ya sean estos acciones, divisas o ForEx (Foreign

Exchange), opciones o productos derivados como CFDs (Contracts For Difference) o

ETFs (Equity Traded Funds).

Se entiende como operaciones "a mercado" a todas aquellas operaciones bursátiles que

se lleven a cabo al precio actual del título sobre el que se vaya a hacer la transacción,

pudiendo ser esta tanto de compra como de venta. Téngase además en cuenta que

determinados productos financieros, como los CFDs por ejemplo, pueden venderse sin

necesidad de poseerse. Estas operaciones, conocidas como operaciones en corto o a la

baja, son posibles gracias al apalancamiento financiero y se realizan mediante un

proceso de "préstamo teórico" de títulos entre una entidad bancaria y el usuario. Dicho

proceso es automatizado por los proveedores de servicios financieros a través de las

plataformas de inversión, equiparando así el nivel de dificultad de su realización a la

compra o venta ordinaria de acciones tradicionales.

Para llevar realizar una operación como la

mencionada anteriormente las plataformas

de inversión instalables emplean una

utilidad de manejo muy simple. En la

imagen izquierda puede verse un ejemplo.

En dicha utilidad es posible realizar tanto

una operación de compra como de venta a

mercado. Para ello el usuario simplemente

tiene que fijar el número de acciones que

desea comprar y seleccionar el tipo de

operación a realizar.


I.3.2.b.- Ordenes:

Todas estas plataformas tienen una funcionalidad común, que es además considerada

básica para poder operar en el Mercado de Valores. El posicionamiento de órdenes,

tanto de compra como de venta, es una función fundamental para el inversor ya que a

través de ella es posible limitar las pérdidas, controlando así el riesgo asumido, y

recoger beneficios cuando se alcance el nivel de rentabilidad deseado. El proceso para

crear una orden, sea del tipo que sea, es muy similar al proceso seguido para realizar

una operación a mercado. Por ello en la mayoría de las aplicaciones la utilidad de

creación de órdenes suele estar integrada dentro de la propia utilidad de compra-venta,

donde lo único extra que debe modificar el usuario, a parte del número de títulos de la

operación, el precio objetivo y la acción a realizar, es el tipo de orden. En este caso en

lugar de dejarla en una orden "a mercado" se marcaría cualquier otra cosa.

I.3.2.c.- Control de Ordenes:

Dado que las condiciones del mercado y sus perspectivas pueden cambiar, cualquier

plataforma de inversión permite al usuario gestionar y administrar aquellas órdenes que

haya cursado. De esta forma el usuario puede eliminarlas si lo desea, o modificarlas en

función de sus nuevas necesidades.

En la imagen inferior puede verse el menú que permite administrar las órdenes creadas

por el usuario en la plataforma instalable que hemos tomado como referencia.

A su vez, a través de una utilidad parecida a la usada para la compra-venta de títulos,

se pueden modificar todas las características de cada una de las órdenes cursadas por el

usuario, de tal forma que cumpla los requisitos del mismo. De la misma forma es

posible eliminar la orden del sistema a discreción del usuario.

I.3.2.d.- Divisas:

Las operaciones de divisas dentro de lo que se conoce como mercado ForEx son un

pilar capital dentro de cualquier estrategia de inversión y, consecuentemente, lo son

también de cualquier plataforma de inversión bursátil. Este tipo de operaciones, que

constituyen un objetivo de inversión en sí mismo, son también empleadas para realizar

operaciones de "hedging", en las que un inversor con una cartera en una divisa concreta

compensa su exposición a otra mediante una operación, contraria a la que haya

provocado dicha exposición, en el mercado de divisas. Es decir, si un inversor con una

cartera en euros compra acciones en un mercado en dólares compensará su exposición a

esta última moneda vendiendo una cantidad de dólares, igual al importe de la operación


anterior, por euros en el mercado de divisas. De ahí la extrema importancia del mercado

de divisas, lo que lo convierte en el más voluminoso de cuantos existen en el mundo.

La operativa en el mercado ForEx dentro de cualquier plataforma de inversión bursátil

es bastante simple. Básicamente se vende una moneda y se compra otra, sin necesidad

de que alguna sea la moneda en la que el usuario tiene su cartera. Dado a que todas estas

operaciones funcionan con títulos cotizables, es decir no es un intercambio puro de

divisas, es posible operar en cualquier cruce. A continuación se muestra un ejemplo de

un cruce entre el dólar de Hong Kong (HKD) y el Yen Japonés (JPY) hecho en nuestra

aplicación de referencia con una cartera en Euros.

Puede verse también a continuación la utilidad empleada para realizar operaciones en el

mercado de divisas que, aunque con ciertas diferencias, es considerablemente similar a

la empleada para operar en el mercado de acciones.

I.3.2.e.- Control de Histórico:

Cualquier plataforma de inversión bursátil que se precie permite al usuario llevar un

seguimiento de sus operaciones en el Mercado de Valores a través de un histórico o

fichero de operaciones. Gracias a esta función el usuario puede saber todas las

transacciones que ha realizado en un periodo determinado de tiempo, pudiendo así

determinar su evolución. A su vez le facilita el conocer que ordenes han sido cursadas

efectivamente o cuales han caducado y, por tanto, ha eliminado el sistema de manera

automática.

Aunque el control de histórico no puede considerarse una funcionalidad principal de

una aplicación inversión en sí misma, si es cierto que es muy útil, y prácticamente

imprescindible, para que el inversor pueda llevar cierto nivel de control aceptable y

realizar un buen seguimiento de su cartera de valores.


I.3.2.f.- Herramientas y Servicios:

Casi cualquier plataforma de inversión instalable proporciona también una serie de

herramientas y servicios que, si bien el usuario puede obtener por otros medios dado

que hay multitud disponibles en el mercado, son bastante convenientes al estar

integradas en la misma plataforma que el usuario emplea para invertir. De esta manera

puede realizar su análisis y obtener información de fiabilidad que le permitan construir

una estrategia de inversión, y llevar a cabo dicha inversión dentro del mismo marco en

el que ya se encuentra.

Las herramientas y servicios disponibles dependen fundamentalmente del proveedor de

servicios financieros y del acuerdo que se tenga con él. En cualquier caso entre sus

características comunes suele estar la posibilidad de analizar gráficas, recibir

información económica de última hora y tener acceso a asesoramiento en tiempo real a

través de salas privadas de chat.

I.3.3.- Ventajas y desventajas

Las plataformas de inversión en el Mercado de Valores guardan todas una gran

similitud entre ellas, incluso entre aquellas instalables en un dispositivo y aquellas

accesibles vía internet.

Dado que son un instrumento muy específico orientando siempre hacia el mismo

propósito, las funcionalidades básicas tales como operaciones a mercado de acciones,

divisas, futuros, productos derivados, etc., posicionamiento de órdenes, control de

cartera e histórico existen en todas ellas. Debido también a que en sí dichas operaciones

son simples de realizar, las utilidades que se emplean en una plataforma instalable o en

una en internet para ello suelen ser prácticamente iguales. No hay demasiado margen de

innovación ni ampliación, y sus características vienen más definidas por las

posibilidades y necesidades de operatividad en el mercado, que por las características

que el creador de la aplicación haya querido ofrecer.

Tampoco en el plano de la seguridad en la transmisión de los datos de las operaciones

las diferencias son acusadas, si bien este aspecto suele permanecer oculto a los ojos del

usuario no siendo posible en la mayoría de los casos apreciar las diferencias.

Está extendido el uso de encriptación para una transmisión segura de los datos y

prevenir así el uso fraudulento o modificación de la información por parte de atacantes

malintencionados. Aunque suelen entenderse como más seguras, las plataformas de

inversión instalables en los dispositivos suelen estar expuestas a los mismos riesgos que

las plataformas web, si bien estas últimas suelen ser objeto de más ataques y, por ello,

suelen ser empleadas por los usuarios de menor nivel o por los de mayor nivel solo en

casos puntuales de necesidad.


En la actualidad es muy frecuente que casi cualquier plataforma de inversión bursátil

instalable se ofrezca para distintos sistemas operativos y distintos dispositivos,

destacando especialmente los dispositivos móviles. Ello hace que, en la práctica, no

exista ninguna gran diferencia apreciable, en lo que a la disponibilidad de la plataforma

se refiere, entre una plataforma instalable y una vía web. Siendo incluso más

conveniente la primera dado que, para el caso de un dispositivo móvil como un

Smartphone o una tablet, el funcionamiento de la plataforma y su rendimiento es

considerablemente mayor con una aplicación instalable que empleando un navegador de

internet.


I.4.- Plataforma de Inversión Web

Dada la versatilidad que permite y el no requerir la descarga e instalación previa de

ninguna aplicación las plataformas de inversión web son muy populares entre los

inversores de todo el mundo. Si bien es cierto que las aplicaciones instalables siguen

siendo las más populares y muchos usuarios reservan las plataformas web para casos de

necesidad puntual.

En la comparativa realizada se ha optado por revisar las características de la versión

online de la plataforma ya revisada en el punto anterior "Dif Freedom", por ser una de

las más completas y populares en Europa.

I.4.1.- Distribución General

La distribución general de la plataforma web es muy similar a la de la plataforma

descargable, salvo por las lógicas limitaciones, fundamentalmente de rendimiento, que

conlleva el hecho de ser una versión online.

En la siguiente imagen puede apreciarse una vista global de la pantalla de inicio de la

plataforma de inversión web. En los siguientes apartados se irán describiendo con más

profundidad sus distintas funcionalidades y características.

Como puede observarse la plataforma web de inversión guarda gran similitud con la

descargable. Puede verse que, como es lógico, las operaciones que pueden realizarse

son exactamente las mismas. Además por comodidad para el usuario se suele procurar


que no existan grandes diferencias entre la operativa con la plataforma instalable y la

versión web. Debido, fundamentalmente, a que un mismo usuario puede operar con

cualquiera de las plataformas según sus necesidades en cada momento.

I.4.2.- Principales Funcionalidades

Dada la intercambiabilidad entre versiones de las plataformas y los estrictos requisitos

para operar en el mercado, las principales funcionalidades tanto en la versión instalable

como en la versión web son las mismas. Sin embargo se encuentran adaptadas al medio

en el que están funcionando.

I.4.2.a.- Operaciones a mercado y órdenes:

Tanto las operaciones a mercado como la creación de órdenes comparten una misma

utilidad dentro de la versión web de la plataforma que guarda una enorme similitud con

la utilidad de la versión instalable. El procedimiento para realiza una operación a

mercado o para cursar una orden de compra o venta de un título es el mismo. Puede

verse en la siguiente imagen un ejemplo de compra de valores empleando dicha utilidad

de la plataforma web.

En esta utilidad, para la realización de una compra de

títulos a mercado, es decir, al precio actual, basta con

fijar la cantidad de títulos que se desean adquirir y

realizar la operación.

Por otro lado para crear una orden, ya sea esta de

compra o de venta, tan solo es necesario fijar el tipo

de orden dentro de esta misma utilidad y las

condiciones de ejecución y duración. A su vez es

posible, al igual que en la plataforma instalable, crear

una orden de seguridad, o de limitación de pérdidas,

conocida como "STOP LOSS", en el preciso instante

que se da la orden de compra a mercado. Práctica muy

habitual entre inversores sensatos que desean mantener

un buen control de su riesgo.


I.4.2.b.- Divisas:

Un punto tan importante en cualquier estrategia de inversión como es el mercado de

divisas debe, irremediablemente, estar incluido también en la versión web de una

plataforma.

En la imagen derecha puede verse la utilidad que se

emplea en la versión web de nuestra plataforma de

referencia para operar en el mercado de divisas. De

la misma manera, y simplemente seleccionando una

pestaña diferente, pueden cursarse ordenes sobre

divisas y operar con opciones sobre las mismas.

Estas últimas, además, son un tipo de operación

tremendamente frecuente en este mercado en

concreto.

I.4.2.c.- Control de Histórico:

Como no podía ser de otra manera la versión web de la plataforma de inversión incluye

también una sección que permite al usuario revisar el histórico de las operaciones

realizadas así como de las órdenes ejecutadas o caducadas según sea el caso.

Dicho control puede llevarse a cabo mediante una pantalla, llamada en esta plataforma

fichero de operaciones, donde es posible ver todas las operaciones y ordenes que haya

realizado el usuario y filtrarlas de acuerdo al criterio que el usuario desee.

En la siguiente imagen puede verse dicha pantalla de control de histórico de la versión

web de nuestra plataforma de referencia.


I.4.2.d.- Herramientas y Servicios:

De igual forma que en la versión instalable, es también posible acceder a diversas

herramientas de soporte al inversor, así como a servicios de asesoramiento en vivo y

fuentes de información económica dentro de la propia aplicación. A su vez, la versión

web permite también ver gráficas de todos los títulos disponibles, así como indicadores

técnicos de utilidad de los mismos.

Hay que destacar que la fluidez y rendimiento de algunas de estas herramientas

presentes en la plataforma web están por debajo de sus análogas ofrecidas en la versión

instalable. Otro de los motivos por lo que suelen resultar mejores estas últimas.

En la siguiente imagen puede apreciarse la utilidad de análisis de gráficas de la versión

web de la plataforma DiF Freedom.

I.4.3.- Ventajas y desventajas

En el caso de las versiones web de las plataformas de inversión en el Mercado de

Valores, o de aquellas que, aunque minoría, operan exclusivamente a través de una

aplicación accesible mediante un explorador de internet, las ventajas son menores que

los inconvenientes cuando se comparan con sus versiones instalables.

Quizás la principal ventaja y motivo por el cual se mantienen, a pesar del extendido uso

de aplicaciones instalables, es que ofrecen la posibilidad de ser usadas en cualquier

dispositivo, en cualquier lugar, siempre y cuando se tenga acceso a la red. Ello permite

que en casos puntuales, en los que el usuario no pueda, por el motivo que sea, tener

acceso a sus dispositivos habituales, donde tiene instalada la plataforma, pueda tener

acceso rápido a su cartera y a realizar la operación que en ese momento la urja llevar a

cabo.

En lo demás, tanto en lo que se refiere a la rapidez, eficiencia o seguridad, las versiones

web de estas plataformas de inversión están por detrás de sus homólogas instalables.


I.5.- Simuladores y Demos

Es muy común que los propios proveedores de servicios financieros que proporcionan

las plataformas de inversión, ya sean estas accesibles vía web o instalables, faciliten

también al potencial cliente el acceso a una demo de sus plataformas. Permitiéndole así

al usuario evaluar las bondades del producto sin correr riesgo alguno.

Para ello facilitan una cuenta de prueba que permite el acceso a la misma plataforma

que se usa para invertir con capital real. Generalmente esta cuenta suele contar con un

saldo inicial ficticio para que los clientes puedan hacer uso de él y comprobar el

funcionamiento de la aplicación. Que mejor estrategia de marketing que dejar que

prueben tu producto.

Es muy habitual también encontrar en internet simuladores de inversión bursátil. Estos

suelen tener dos objetivos fundamentales: uno, el meramente recreativo y, dos, la

posibilidad de entrenar las habilidades del inversor sin riesgo de perder capital alguno,

es decir, para propósitos puramente educativos y no lucrativos.

Un ejemplo de estos simuladores puede verse en la siguiente imagen obtenida del

simulador "labolsavirtual.com".


CAPÍTULO II: IMPLEMENTACIÓN


II.1.- Introducción a la plataforma desarrollada

Ha sido objeto de este proyecto desarrollar una plataforma de inversión bursátil

simulada plenamente funcional. Esta plataforma permite llevar a cabo operaciones en el

Mercado de Valores a un nivel básico de una manera similar a la que se realizan en las

plataformas profesionales disponibles actualmente en el mercado.

No se ha pretendido su implementación a un nivel real de operatividad en el mercado,

aunque sí crear la estructura de partida de lo que podría convertirse en una plataforma

útil de inversión o, en su defecto, en una herramienta de entrenamiento para futuros

inversores. Esto último es ya posible con las características que presenta la aplicación,

aunque de manera limitada a las operaciones con acciones, las únicas disponibles en la

plataforma por el momento.

En próximos puntos del presente capítulo se desarrollará con profundidad las

posibilidades existentes para incrementar las capacidades de funcionamiento de la

plataforma y el abanico de operaciones y tipos de valores en los que se puede invertir. A

su vez también se estudiará la viabilidad de una eventual implementación como

herramienta real o simulada de inversión bursátil.

A pesar de la multitud de plataformas disponibles que han servido de inspiración, se ha

optado por desarrollar un estilo propio que, no obstante, guarde características y

capacidades semejantes al resto de aplicaciones a las que pueden accederse. Sigue por

tanto la plataforma desarrollada un esquema de funcionamiento perfectamente

equiparable al que siguen el resto. Ofreciéndose no solo la posibilidad de invertir en

acciones de manera ordinaria con una cuenta simulada, sino además de poder realizar un

seguimiento activo de estas inversiones y de obtener información financiera de

relevancia a través de la propia aplicación. Es el caso del visionado de gráficas e

indicadores técnicos de las acciones disponibles a través de la plataforma.

Por ello va a poderse comprobar que el funcionamiento y las capacidades de la

plataforma objeto del presente proyecto guarda grandes similitudes con las descritas en

el capítulo anterior sobre el estado del arte.

Contamos, pues, con la estructura fundamental de una plataforma de inversión bursátil

con un gran potencial de desarrollo, pero siendo a su vez plenamente operativa y

funcional.

En el presente capítulo se irá describiendo su funcionamiento, así como el proceso de

creación seguido hasta llegar a la plataforma de inversión creada. Se describirá también

la lógica que opera tras ella, oculta a ojos del usuario, y la forma en que se ha

implementado la misma en un código.


II.2.- Estrucutura Global de la aplicación

Como puede verse la plataforma posee cuatro elementos o conjuntos de ellos que están

claramente diferenciados entre sí y desempeñan una función específica y llevan a cabo

una serie de interacciones con los otros.

Estos cuatro grandes bloques, compuestos por diferentes elementos, son, de acuerdo

con el anterior diagrama, los siguientes:

Aplicación: Llamamos aplicación al conjunto de controladores, vistas y modelos

que integran los elementos funcionales de la plataforma. La aplicación contiene

la lógica, interacciona con el usuario y con la base de datos.

Base de Datos: La Base de datos es el espacio de almacenamiento de toda la

información relevante que la aplicación requiere para desarrollar su

funcionamiento. En nuestro caso se trata de una base de datos relacional, por lo

que la información se encuentra distribuida entre distintas tablas relacionadas

entre sí.

Actualizador: El actualizador es uno de los pilares fundamentales de la

plataforma. Se encarga de actualizar toda la información de la base de datos de

forma periódica, mediante ejecuciones programadas de un script de comandos.

Framework: El Framework proporciona a la aplicación un marco de trabajo para

determinadas tareas estandarizadas, así como para ciertos aspectos visuales de la

aplicación.

ACTUALIZADOR

BASE

DE

DATOS

APLICACIÓN

FRAMEWORK


II.3.- Obtención de datos financieros

II.3.1.- Introducción

Un elemento crítico de la aplicación desarrollada es el proveedor de datos financieros y

bursátiles. Gracias a este proveedor es posible tener prácticamente cualquier dato de

relevancia de casi cualquier valor de la mayoría de mercados mundiales.

Estos datos son los empleados para nutrir a nuestra plataforma. No solo en lo referente

a valores, sus precios y variaciones, sino también en lo referente a gráficas de los

mismos.

Además este proveedor de datos empleado tiene una amplia gama de información que

puede suministrar, no solo de índole financiera o económica. Ello brinda multitud de

opciones en cuanto a nuevas líneas de desarrollo y ampliación de la plataforma.

En el curso del presente apartado se explicará el funcionamiento de las interacciones de

la plataforma con el proveedor de datos y el proceso seguido para realizarlas. Así como

determinados elementos a tener en cuenta cuando se trabaja con un proveedor de datos

de las características del empleado.

II.3.2.- API: Definición y funcionamiento

API son las siglas en inglés de Application Programming Interface, en español, Interfaz

de programación de aplicaciones. Su función es brindar la capacidad a dos piezas

diferentes de software de comunicarse entre sí. Para entendernos, permite el empleo de

contenido de una aplicación de un tercero dentro de la aplicación propia.

Evidentemente es este tercero el que determina las reglas y condiciones de acceso a

dicha información de su aplicación. Ello implica que APIs que restringen el acceso a

determinados clientes, a determinados niveles de información o a un número máximo de

consultas de dicha información, por ejemplo.

Desde el punto de vista del cliente de una API, la solicitud y recepción suele ser,

generalmente, bastante simple. Para un uso apropiado de una API determinada es

necesario tener en cuenta una serie de factores y observar un conjunto de normas que se

especifican a continuación de una manera resumida:

Conocimiento de la estructura de la información a recibir


Empleo de la sentencia/s adecuadas para obtener los datos deseados

Cumplimiento de las condiciones impuestas por el proveedor

Contar con los permisos de acceso exigidos

Por lo demás, el procedimiento de implementación de una llamada a la API

suministradora de datos dentro de la aplicación, a nivel de código, consiste,

generalmente, en realizar una llamada a una dirección url con los parámetros adecuados,

y almacenar los datos devueltos en una variable u objeto de programación para el

posterior empleo de dicha información a través del mismo.

II.3.3.- YQL: Yahoo Finance

YQL, siglas en inglés de "Yahoo Query Language", es una API ofrecida por el famoso

buscador de internet que permite a los clientes de la misma obtener, buscar y combinar

datos de diversa índole, empleando un lenguaje muy parecido al empleado para realizar

peticiones o "queries" a una base de datos SQL.

Dentro de los diversos tipos de datos que proporciona la API YQL se encuentra el

servicio proveedor de datos financieros. Estos datos financieros son originarios de la

sección de información financiera del buscador, conocida como Yahoo Finance. Por

consiguiente, implementando una llamada a la API de Yahoo YQL, y estableciendo

como parámetro que se desea obtener información financiera de Yahoo Finance, pueden

obtenerse los datos externos necesarios para el funcionamiento de la aplicación

desarrollada.

La elección de este proveedor de datos se debe fundamentalmente a un criterio

económico, dado que es actualmente de los pocos proveedores de datos financieros y de

valores bursátiles que proporcionen APIs gratuitas a través de las cuales pueda

accederse a su contenido. Además se ha debido tener en cuenta el lenguaje de

programación empleado, ya que no todas las APIs de información financiera existentes,

sean gratuitas o no, permiten consultas empleando cualquier lenguaje. Era el caso, por

ejemplo, de la API del proveedor de información financiera y bursátil Bloomberg que,

aunque gratuita, no soporta consultas empleando el lenguaje PHP.

Yahho es, de hecho, prácticamente el único en la actualidad que provee tantos datos

financieros con tanta precisión y diversidad, ya que la otra gran API de datos

financieros gratuita, la de Google Finance, cesó su funcionamiento tiempo atrás. No

pudiendo ser considerada para su uso en el desarrollo de la plataforma objeto del

presente proyecto.


No cabe duda que existen APIs de proveedores de datos financieros que suministran

información de mucha más calidad y diversidad, e incluso en tiempo real, pero la

inmensa mayoría son de subscripción, y no precisamente a un bajo coste. Por ello no

pudieron ser consideradas como posibles en el proceso de selección de proveedor que se

hizo previamente al desarrollo de la aplicación. Esto, como puede suponerse, redujo

considerablemente el abanico de opciones viables.

II.3.4.- Implementación de consultas

En la implementación de consultas a Yahoo Finance de datos financieros debe tenerse

en cuenta que las consultas sobre precios de acciones y otra información relacionada

con las mismas se realizan de manera separada a las consultas de las gráficas de estas

misma acciones.

Por ello en la explicación de la implementación de estas consultas en la aplicación

creada se distinguirá entre datos bursátiles y gráficas.

II.3.4.a.- Solicitud de datos de valores

En el funcionamiento de la plataforma se requiere mantener todos los precios de las

acciones disponibles para operar actualizados lo máximo posible. Por consiguiente

carece de sentido realizar actualizaciones de datos de valores individuales. De modo que

la actualización y, por ello, la solicitud de datos de valores se hace en bloque. Así una

sola llamada a la API proveedora solicitando datos actualizados devuelve los precios,

variaciones y demás datos relacionados de todos los valores disponibles en la

aplicación.

El procedimiento que se sigue para cursar una solicitud de datos a esta API consiste en

una serie de pasos que quedan descritos en el siguiente diagrama de flujo:

INICIO

FUSIÓN ENTRE

DIRECCIÓN Y

SOLICITUD

FIN

ESTABLECIMIENTO

DE DIRECCIÓN

DE DESTINO

ENVÍO DE

LA SENTENCIA

AL PROVEEDOR

CREACIÓN DE LA

SOLICITUD DE

DATOS TIPO SQL

RECEPCIÓN DE

DATOS Y

TRANSFORMACIÓN


Dada la relevancia de este proceso dentro de la aplicación se va a profundizar en mayor

medida en su funcionamiento hasta nivel de código, siguiendo los pasos del anterior

diagrama de flujo.

En primer, el establecimiento de la dirección de destino, no es más que el

almacenamiento en una variable de la dirección url de API de nuestro proveedor de

datos. Dicha dirección es la siguiente:

http://query.yahooapis.com/v1/public/yql

A continuación debe crearse una sentencia de consulta. Esta sentencia tiene una

estructura muy similar a una sentencia de consulta en una base de datos mediante

lenguaje SQL.

Desafortunadamente existe una limitación en la creación de estas sentencias para la

API de Yahoo Finance: No pueden realizarse peticiones masivas de datos de distintos

valores especificando una característica común de los mismos. Así, por ejemplo, si se

desea obtener todos los valores que cotizan en un determinado mercado no puede

especificarse, dentro de la sentencia, que devuelva todos los valores que tengan el

mismo valor dentro del campo mercado.

El único parámetro que la API de Yahoo Finance permite usar para la obtención de

información de valores bursátiles es el ticker de cada valor. El ticker de un valor es un

identificador único y universal de un título concreto. Consecuentemente, hay que

especificar dentro de la sentencia de consulta el ticker de cada uno de los valores cuya

información debe proporcionar la API. Sin que exista, en principio, limitación en el

número de valores a buscar en cada consulta.

Dicha consulta tiene la forma siguiente:

select * from yahoo.finance.quote where symbol in ("AAL"," AAPL")

En el caso de la sentencia de consulta se procede de forma idéntica a como se ha hecho

con la dirección de destino. Almacenándola en una variable para su uso posterior.

Seguidamente se fusionan la dirección de destino y la sentencia de consulta dentro de

una consulta url, junto con información extra que el proveedor de datos requiere. Esta

información extra es el conjunto de tablas del proveedor donde se encuentran los datos

así como el formato concreto en el que queremos que nos envíe dichos datos. En


nuestro caso dicho formato es conocido como "json". Del que se hablará

posteriormente.

La sentencia url final de solicitud de información a la API, almacenada en una variable,

es la siguiente:

$ch = curl_init($endpoint.'?q='.$query. &env=http://datatables.org/alltables.env' . '&format=json')

Donde "endpoint" es la dirección de destino y "query" la sentencia de consulta creada

anteriormente.

Una vez hecho esto se remite la sentencia anterior a la API y se almacena su contenido

en un variable objeto que contiene toda la información proporcionada.

Como se dijo con anterioridad se ha optado por emplear un formato de datos en la

respuesta de la consulta denominado json. Esta elección se ha realizado debido a la

buena y práctica estructuración de los datos que permite este formato. A continuación

puede verse un ejemplo de la respuesta de la API al solicitarle los datos formateados de

esta forma:

stdClass Object (

[query] => stdClass Object (

[count] => 1 [created] => 2015-02-25T19:43:23Z [lang] => en-US

[results] => stdClass Object (

[quote] => stdClass Object (

[symbol] => AAL [AverageDailyVolume] => 13436100 [Change] => -1.61

[DaysLow] => 49.80 [DaysHigh] => 51.49 [YearLow] => 28.10

[YearHigh] => 56.20 [MarketCapitalization] => 35.246B

[LastTradePriceOnly] => 49.91 [DaysRange] => 49.80 - 51.49

[Name] => American Airlines [Symbol] => AAL

[Volume] => 6288089 [StockExchange] => NasdaqNM ) ) ) )

Si atendemos a la información suministrada, puede verse que se encuentra estructurada

por niveles. De esta manera el fragmento de información que se requiere es accesible

bajando niveles dentro de esta estructura y seleccionando el dato deseado. Al ser un

objeto lo que devuelve la API, o una serie de ellos para el caso de una solicitud de

múltiples valores, esto puede hacerse de una manera fácil y rápida.


Por ejemplo, si se desea emplear el nombre del valor devuelto basta con emplear una

sentencia como la siguiente:

$result->query->results->quote->name

Suponiendo "$result" como la variable donde se ha almacenado el resultado de la

solicitud de datos al proveedor. Puede, por un procedimiento idéntico al anterior,

manejarse paquetes de información de múltiples valores empleando índices para

recorrer el resultado de la consulta.

A partir de aquí ya es misión de la aplicación, concretamente del actualizador, manejar

esta información recibida y emplear los procedimientos anteriormente descritos para

actualizar la base de datos que emplea la aplicación para desarrollar las tareas a las que

está destinada.

II.3.4.b.- Solicitud de gráficas de valores

Los gráficos de los valores son obtenidos de manera diferente a como se obtienen los

datos de los valores empleados por la aplicación.

En primer lugar hay que tener en cuenta como la API de Yahoo Finance suministra las

gráficas de los valores a los solicitantes. Estás gráficas son generadas por la propia API

en función de los parámetros que se le pasen en la url de solicitud. Cuando se accede a

esta url, desde la barra de direcciones del navegador por ejemplo, se llega a una página

cuyo único contenido es una imagen con la gráfica solicitada.

Sabiendo esto puede implementarse la gráfica devuelta por la API dentro de la propia

aplicación, insertando para ello una imagen en la vista Chart cuya fuente (parámetro src)

sea la url de solicitud.

La url base de la petición de gráfica de un valor, a la que luego habrá de añadírsele

todos los parámetros, identificador del valor incluido, es la siguiente:

http://chart.finance.yahoo.com/z

Estos parámetros vienen definidos por una letra y, según el caso, un valor numérico que

se le añade a la url para que añada a la gráfica la característica correspondiente. Nótese

que no todos los indicadores y tipos de gráfica están disponibles para todos los valores,

siendo esto imposible de conocer de antemano.


II.4.- Actualización Automática


Para el correcto funcionamiento de la plataforma y para que la simulación de las

operaciones en bolsa sea lo más real posible es necesario que la información que maneje

el usuario sea lo más actual que pueda conseguirse, tal y como sucede en cualquier

plataforma real de operación en el Mercado de Valores.

Por otro lado el propio sistema tiene una serie de funcionalidades que requieren la

revisión continuada de determinadas tablas y el lanzamiento de operaciones bajo ciertas

condiciones. Este es el caso de las órdenes creadas por el usuario, independientemente

de que estas sean de compra o venta. Dichas órdenes perderían sentido si el sistema no

vigilase el cumplimiento de las condiciones que los usuarios hayan establecido y no las

lanzase o eliminase según el caso.

Además se hace necesario actualizar de manera periódica los valores y variaciones de

las carteras de los distintos usuarios dados de alta en el sistema. De esta manera es

posible conseguir un nivel de precisión de dichos parámetros muy alto, cosa que con

actualizaciones esporádicas o con baja cadencia no se alcanzaría, ya que introducirían

un alto nivel de error en los mismos.

Por consiguiente se convierte en fundamental el actualizador de la aplicación, también

llamado Updater. Esta rutina de la aplicación, que es en realidad un archivo php

programado de una manera parecida a un controlador ordinario, ejecuta una serie de

sentencias que actualizan de una pasada toda la información almacenada en las distintas

tablas de la base de datos, poniéndolas al día. El lanzamiento automatizado y periódico

de esta rutina se realiza mediante un administrador de tareas programadas cualquiera

que ejecuta un script de comandos que llama al actualizador.

En el caso particular de que la aplicación se encuentre en un servidor virtual, como

Apache o similar, puede usarse el gestor de tareas programadas del propio sistema

operativo del equipo donde se encuentre dicho servidor virtual que se emplea para

correr la aplicación creada. Por otro lado puede procederse de una manera similar para

el caso que la aplicación se encuentre alojada en un servidor remoto, empleando la

utilidad de programación de tareas del sistema operativo de dicho servidor.


II.4.2.- Ritmo de actualización

Para la aplicación desarrollada existen diversas limitaciones en el ritmo de

actualización de la misma por el actualizador. En primer lugar el proveedor de datos

financieros empleado, del cual se hablará con más detalle en posteriores apartados, no

proporciona datos financieros ni del Mercado de Valores en directo. Por lo general

suelen estar retrasados entre cinco y hasta quince minutos según el caso. Además dichos

datos no suelen actualizarse cada segundo, sino cada quince o veinte segundos. Esto

hace que no tengan ningún sentido solicitar los nuevos datos del mercado en intervalos

de tiempo inferiores a veinte segundos. Siendo este valor puramente orientativo y

pudiendo variar entre distintos mercados.

Debe tenerse en cuenta también que el número de llamadas al proveedor de datos para

la actualización del sistema está limitada por el proveedor en 2000 llamadas por hora y

dirección IP no autentificada, como es nuestro caso, y en 20000 llamadas por hora y

dirección IP autentificada. En cualquier caso este no es el factor limitante del

actualizador en nuestra aplicación y, en principio, tampoco podría serlo en otro

escenario ya que carece de sentido actualizar los valores financieros a ritmos de 5,55

llamadas por segundo, como podría llegar a alcanzarse.

A pesar de todo lo mencionado con anterioridad el auténtico factor limitante del ritmo

de actualización de nuestra aplicación viene dado por el gestor de tareas programadas

del sistema operativo. En nuestro caso, al estar empleando el propio de Windows, el

ritmo máximo de ejecución de una tarea programada repetitiva es de una cada cinco

minutos. Ritmo completamente inaceptable para una plataforma que opere en el

mercado real pero admisible para el propósito del presente proyecto.

II.4.3.- Necesidades

Las necesidades que requieren ser satisfechas por un actualizador automático del

sistema se detallan a continuación:

Actualización de precios y variaciones de los valores disponibles

Actualización del valor de las carteras y sus variaciones

Actualización de los valores integrantes de las carteras

Revisión de órdenes

Lanzamiento de órdenes

Eliminación de órdenes caducadas


Registro en histórico de las operaciones realizadas autónomamente

Registro en histórico de órdenes de lo acontecido con ellas

Actualización de valores de referencia para el cálculo de variaciones

Nótese que determinadas necesidades no eran requisitos indispensables para el buen

funcionamiento de la aplicación, sin embargo aportaban realismo y eran de gran utilidad

para el usuario. Era el caso del registro en histórico de los lanzamientos de las órdenes

ejecutadas por el sistema de manera autónoma.

II.4.4.- Implementación

Debido a que el actualizador se ejecuta de manera autónoma e independientemente de

la aplicación principal su estructura es ligeramente diferente a la de un controlador que

se ejecuta dentro de la propia aplicación. Por ello el procedimiento empleado para

trabajar con la base de datos es diferente al usado habitualmente.

En el presente punto se pretende explicar el funcionamiento completo del actualizador

de la aplicación. Si bien, debido a su extensión, se ha optado por dividir el mismo en

diversos bloques operativos que serán explicados por separado, como si de funciones en

un controlador se tratase, aunque en realidad integran un único ente. En el siguiente

diagrama es posible ver esta división en bloques que se ha hecho del actualizador.

II.4.4.a.- Actualización de valores:

La función principal del actualizador es la de proporcionar los nuevos precios y

variaciones de los valores disponibles para su adquisición por los usuarios dentro de la

plataforma. Ninguna de las otras funcionalidades del actualizador tiene sentido ni

utilidad alguna sin que primero se actualicen los datos de los valores.

El proceso de dicha actualización es relativamente simple. Dentro del código del

actualizador se encuentran los identificadores de cada uno de los valores disponibles en

la plataforma. Estos se encapsulan de manera adecuada dentro de una petición de

Actualizador

Actualización de Valores

Actualización de los valores de las carteras

y sus variaciones

Ejecución de Órdenes debido a vencimiento

Ejecución de órdenes debido a

cumplimiento de condiciones


información a nuestro proveedor de datos y, tras recibir la respuesta con los nuevos

precios y variaciones, se actualiza la tabla Valores de la base de datos.

Dicha actualización de la tabla Valores se realiza mediante un bucle que recorre la

misma desde el primer registro hasta el último. Por consiguiente es necesario que el

actualizador conozca el número de valores a actualizar. Aunque esto podría hacerse

realizando una consulta a la base de datos, dentro de la información proporcionada por

el proveedor existe un campo conteniendo el número de registros enviados, lo que

facilita la tarea del actualizador.

El bloque de actualización de valores funciona de acuerdo al siguiente diagrama de

flujo:

Por otro lado las interacciones con la base de datos de este bloque del actualizador

pueden verse en el siguiente diagrama:

INICIO

SELECCIÓN

DEL PRIMER

VALOR

FIN

PETICIÓN DE

DATOS

FINANCIEROS

ACTUALIZACIÓN

VALOR

CONEXIÓN

A BASE DE DATOS Y

SELECCIÓN TABLA

ÚLTIMO

VALOR

SI

NO

BD

TABLA VALORES ACTUALIZADOR

SIGUIENTE

VALOR


II.4.4.b.- Actualización de valores de carteras y variaciones:

Una vez el sistema ha obtenido la última versión de los datos de los distintos valores

disponibles para operar en la plataforma, es necesario actualizar el valor de las carteras

de todos y cada uno de los usuarios. Paralelamente hay que calcular y actualizar las

variaciones diarias, mensuales y anuales de estas carteras.

El valor de una cartera de valores se define como la suma de la liquidez disponible más

el valor de sus activos que, en nuestro caso, son solo las acciones que integran la

cartera. Su cálculo se realiza de acuerdo a la siguiente fórmula:

Donde es el valor total de la cartera, es la liquidez de la cartera, es el precio del

valor i-ésimo, la cantidad de títulos del valor i-ésimo existentes en la cartera y el

número de valores distintos que posee el usuario en la cartera.

Por otro lado las variaciones diarias, mensuales y anuales de una cartera de valores se

definen con el cambio de valor experimentado por la misma a lo largo de un día, un mes

y un año respectivamente, expresadas como porcentaje respecto a sus valores al inicio

del periodo de cálculo. Se calculan según las siguientes fórmulas:

Donde , y son las variaciones porcentuales experimentadas por las carteras a

lo largo de un día, un mes y un año respectivamente, es el valor total actual de la

cartera y , y son los valores de la cartera al comienzo del día, el mes y el

año respectivamente.

El actualizador realiza estos cálculos y modificas las tablas correspondientes de la base

de datos dentro de un bucle que es recorrido una vez para cada usuario existente dentro

del sistema. De modo que el primer paso dado por el actualizador es conocer el número

de usuarios dados de alta en la plataforma. Para ello realiza una consulta a la tabla

Usuario y cuenta el número de registros que hay en la misma.

Una vez se conoce el número de usuarios existentes se comienza el bucle desde el cual

se modificarán los datos de las tablas, empezándose a recorrer este bucle desde el

primer usuario hasta el último.

Para un usuario determinado lo primero que se hace es una consulta a la tabla Cartera

para averiguar los valores que dicho usuario posee. A continuación se crea un nuevo


bucle que permite recorrer todos estos valores que pertenecen al usuario y modificar sus

datos. La modificación de estos datos se realiza tomándolos primero de la tabla Valores

y actualizando los de la tabla Cartera a continuación. Al mismo tiempo se van

calculando y sumando los nuevos importes de cada una de las posiciones que tiene

abierta el usuario.

Una vez terminado el bucle anterior se toma el resultado de la suma de los nuevos

importes y se le suma la liquidez del usuario, obteniéndose así el nuevo valor de la

cartera.

Seguidamente el actualizador compara la fecha actual con la fecha de última

modificación de los valores de referencia de la cartera dentro de la tabla Variaciones. Si

corresponde, el actualizador modifica dichos valores poniéndolos a cero y, lógicamente,

establece como el momento actual la fecha de última modificación. Esto ocurre siempre

que se cambie de día, mes o año. En caso contrario el actualizador emplea los valores de

referencia de la tabla Variaciones para realizar el cálculo de las variaciones de la cartera

del usuario y, posteriormente, los modifica dentro de la tabla Usuario.

El funcionamiento de este bloque del actualizador se produce de acuerdo al siguiente

diagrama de flujo:

INICIO

FIN

AÑO ACTUAL = AÑO

VARIACIÓN

DETERMINACIÓN

NÚMERO DE

USUARIOS

NO

DETERMINACIÓN

NÚMERO DE

VALORES

VARIACIÓN DIA = 0

Y REF. VARIACIÓN =

VALOR CARTERA

SI

CÁLCULO VALOR

TOTAL DE

CARTERA

SI

NO

NO

SELECCIÓN

PRIMER

USUARIO

SELECCIÓN

PRIMER

VALOR

CONSULTA DE

NUEVOS DATOS

DEL VALOR

ACTUALIZACIÓN

REGISTRO EN

CARTERA

ACUMULACIÓN

DEL SUBTOTAL

DE CARTERA

SIGUIENTE

VALOR

DIA ACTUAL > DIA

VARIACIÓN

MES ACTUAL > MES

VARIACIÓN

SI

VARIACIÓN MES = 0

Y REF. VARIACIÓN =

VALOR CARTERA

NO

VARIACIÓN DIA = 0

Y REF. VARIACIÓN =

VALOR CARTERA

VARIACIÓN MES = 0

Y REF. VARIACIÓN =

VALOR CARTERA

VARIACIÓN AÑO =

0 Y REF. VARIACIÓN

= VALOR CARTERA

CALCULA

VARIACIÓN

DIARIA

CALCULA

VARIACIÓN

MENSUAL

CALCULA

VARIACIÓN

ANUAL

ÚLTIMO

USUARIO

ÚLTIMO

VALOR

SI

SI

NO SIGUIENTE

USUARIO


Por otro lado, las interacciones de este bloque del actualizador con la base de datos

pueden verse en el siguiente diagrama:

II.4.4.c.- Ejecución de órdenes debido a vencimiento

Una vez los datos de los valores disponibles en la aplicación están completamente

actualizados, así como los distintos parámetros de las carteras, es el momento de revisar

lar órdenes creadas por todos los usuarios del sistema.

El lanzamiento o ejecución de una orden es la realización de la operación en el mercado

de valores que se ha definido en la creación de la orden. Esto es la compra o venta de

una determinada cantidad de títulos de un valor determinado bajo ciertas condiciones.

En la plataforma desarrollada las órdenes pueden ser ejecutadas debido a dos causas

diferentes, a saber:

1. Llegada de la fecha de ejecución definida en la orden: En este caso la orden

es ejecutada a mercado, es decir, al precio que en ese momento se encuentre el

valor objeto de la operación definida en la orden.

2. Alcance del precio objetivo: En caso de que antes de la fecha de ejecución o

caducidad, de haberlas, el valor objeto de la operación de la orden alcance en el

mercado el precio objetivo establecido en la misma, sea este superior o inferior

al precio del valor en el momento de la creación de la orden, la orden será

lanzada, llevándose a cabo su operación al precio objetivo definido, que en este

caso coincidirá con el de mercado.

Por otro lado, los usuarios pueden establecer una fecha de caducidad de la orden. Al

alcanzarse esta, sin haberse ejecutado la orden, debido al cumplimiento de la condición

de precio objetivo, el sistema debe eliminar dicha orden.

BD

ACTUALIZADOR

TABLA

USUARIO

TABLA

VALORES

TABLA

CARTERA

TABLA

VARIACIONES


Conjuntamente al lanzamiento de las órdenes de manera autónoma por el sistema ha de

ir seguido de un registro en el histórico de operaciones y en el de órdenes de lo

acontecido. De igual manera, en el caso de caducidad de la orden, el sistema deberá

registrar la eliminación de la misma en el histórico de órdenes.

En el caso de ejecución de una orden debido al vencimiento de la misma, el

actualizador sigue el proceso mostrado en el diagrama de flujo inferior. En este

diagrama se incluye también la comprobación de caducidad de las órdenes.

En caso de que aún no haya llegado la fecha de ejecución se pasa al proceso de

lanzamiento de órdenes debido al cumplimiento de condiciones, es decir, bajo criterios

respecto al precio objetivo. En el diagrama este paso se ha marcado con una flecha roja.

INICIO

FIN

FECHA CADUCIDAD

<

FECHA ACTUAL

NO

SI ELIMINA ORDEN

Y GUARDA

HISTÓRICO

SI NO

NO

SELECCIÓN

PRIMERA

ORDEN

SIGUIENTE

ORDEN

ÚLTIMA

ORDEN

ÚLTIMA

ORDEN

SI

SI

NO

SIGUIENTE

ORDEN

SELECCIÓN

PRIMERA

ORDEN

MODIFICA

CARTERA Y

LIQUIDEZ

EJECUTA ORDEN

DE COMPRA

AL PRECIO ACTUAL

EJECUTA ORDEN

DE VENTA

AL PRECIO ACTUAL

DETERMINCIÓN

PRECIO

ACTUAL

ORDEN

COMPRA

FECHA EJECUCIÓN

<

FECHA ACTUAL

SI

NO

MODIFICA

CARTERA Y

LIQUIDEZ

GUARDA HISTÓRICOS

DE ORDEN Y

OPERACIÓN

LIQUIDEZ

SUFICIENTE

NO

SI

PROCEDENTE DEL

BLOQUE DE EJECUCIÓN

POR CUMPLIMIENTO

DE CONDICIONES


Cuando se acaba la pasada correspondiente a una orden en el bloque siguiente se vuelve

a este. Paso marcado en el diagrama por una flecha verde.

Las interacciones del actualizador con la base de datos en el proceso descrito

anteriormente pueden verse en el siguiente diagrama:

II.4.4.d.- Ejecución de órdenes debido a cumplimiento de condiciones

Una vez se han eliminado del sistema las órdenes caducadas y las ejecutadas debido a

vencimiento, las remanentes en el sistema solo podrán lanzarse si se cumple su

condición relativa al precio objetivo o, de lo contrario, permanecerán almacenadas para

ser comprobadas en el futuro.

Existen tres condiciones de lanzamiento de órdenes relativas al precio objetivo fijado

en la misma. Estas condiciones son excluyentes entre sí, es decir el usuario solo puede

fijar una de ellas para una misma orden.

En la plataforma desarrollada pueden seleccionarse entre dos opciones de órdenes para

operaciones de venta y tan solo una para operaciones de compra de valores. Los tipos de

órdenes existentes en la aplicación son los siguientes:

Órdenes de Compra:

IF-DONE: Son aquellas en las que se adquiere el valor establecido en la

orden si el precio del mercado es mayor o igual que el precio

objetivo de la orden.

BD

ACTUALIZADOR

TABLA

USUARIO

TABLA

CARTERA

TABLA

ÓRDENES

TABLA

HISTÓRICO

TABLA

HISTÓRICO

ÓRDENES


Órdenes de Venta:

LIMITADA: Son aquellas en las que se vende un valor determinado de la

cartera para recoger beneficios. Por tanto su condición es la

de venta si el precio de mercado es mayor o igual que el precio

objetivo de la orden.

STOP LOSS: Estas órdenes se emplean para limitar pérdidas. Una orden de

Stop es lanzada por el sistema cuando el precio de mercado es

menor o igual que el precio objetivo de la orden, creada para

vender un valor determinado de la cartera.

Dadas las condiciones anteriores, el actualizador actuará de una u otra forma en función

del tipo de orden creada. Este será el parámetro que empleará para discernir el proceso a

seguir en cada caso.

La dinámica seguida por el actualizador puede verse en el siguiente diagrama de flujo,

al que se llega en caso de que la fecha de ejecución sea posterior a la fecha actual

(flecha roja del anterior diagrama).

SI

ELIMINA

ORDEN

SI

NO ORDEN

IF-DONE

SI

SI

MODIFICA

CARTERA Y

LIQUIDEZ

EJECUTA COMPRA

AL PRECIO

OBJETIVO

P. MERCADO >=

P. OBJETIVO

SI

NO

GUARDA HISTÓRICOS

DE ORDEN Y

OPERACIÓN

ORDEN

LIMITADA NO

NO NO P. MERCADO >=

P. OBJETIVO

P. MERCADO <=

P. OBJETIVO

EJECUTA VENTA

AL PRECIO

OBJETIVO

MODIFICA

CARTERA Y

LIQUIDEZ

GUARDA HISTÓRICOS

DE ORDEN Y

OPERACIÓN

PROCEDENTE DEL

BLOQUE DE EJECUCIÓN

POR VENCIMIENTO


En este bloque del actualizador las interacciones que se producen con la base de datos

se reflejan en el siguiente diagrama:

Debe recordarse que la estructuración por bloques del actualizador se ha hecho, a

efectos de esta memoria, para mayor claridad y facilidad de comprensión del

funcionamiento del mismo. Sin embargo la implementación del actualizador real se ha

realizado en un único bloque integrado por diversos bucles y condiciones.

BD

ACTUALIZADOR

TABLA

USUARIO

TABLA

CARTERA

TABLA

ÓRDENES

TABLA

HISTÓRICO

TABLA

HISTÓRICO

ÓRDENES


II.5.- Diagrama de aplicación

Se muestra a continuación un diagrama que muestra todas las secciones y sub-

secciones de la plataforma desarrollada, que se empleará como base para describir en

profundidad el funcionamiento de la misma.

Plataforma

Login

Administrador

Gestión

Crear Usuario Eliminar Usuario

Usuario

Trading

Órdenes Compra

Compra

Perfil

Cartera

Venta Órdenes Venta

Histórico

Ordenes

Eliminar Orden

Histórico Órdenes


II.6.- Modelo Vista Controlador (MVC)

La arquitectura seguida para el desarrollo de la aplicación objeto de este proyecto ha

sido la arquitectura conocida como Modelo-Vista-Controlador.

En esta arquitectura la aplicación es dividida en tres grandes bloques estructurales

principales, cada uno de ellos con una responsabilidad concreta dentro de la aplicación.

II.6.1.- Modelo

El Modelo, dentro de la estructura MVC, se encarga de representar y manejar la

información requerida en cada instante por la aplicación. En él se establecen las reglas y

privilegios de acceso a esta información. Esquemáticamente puede decirse que el

modelo recibe las peticiones de información del controlador y se las devuelve bien a

este o a la vista, en caso de que se deba mostrar dicha información al usuario.

II.6.2.- Vista

La Vista es la parte encargada a interaccionar con el usuario. Proporciona a este la

información que el controlador, a través del modelo, determina que debe serle

proporcionada y, a su vez, permite al usuario proporcionar a la aplicación información

externa. En esencia actúa como entrada y salida de información con respecto al usuario.

II.6.3.- Controlador

El Controlador es el cerebro de cualquier aplicación donde se emplee la estructura

MVC. En él se implementa toda la lógica de la aplicación, se realizan las peticiones de

información al modelo y se decide que información se muestra al usuario a través de la

vista. A su vez el propio controlador tiene la capacidad de modificar la vista según sea

necesario en cada caso.


II.7.- Detalle Estructura MVC Implementada

En el siguiente esquema es posible ver los distintos controladores, modelos y las

distintas vistas que integran la aplicación. En posteriores puntos se irá detallando

su funcionamiento recorriendo hacia abajo los distintos niveles que los componen.

Aplicación

Modelo

Usuario Cartera

Valores Histórico

Órdenes Histórico Órdenes

LoginForm ChartForm

Vista

Index Login

Stock Cartera

Histórico Histórico Órdenes

Compra Venta

OrdenCSelect OrdenVSelect

ChartSelection Chart

Reporte AdminMenu

CreateUser Users

Controlador

Admin Site

Stock Perfil


II.8.- Base de datos

Prácticamente cualquier aplicación posee una base de datos que la respalda, donde se

almacena la información, pudiendo esta ser manejada por la aplicación a voluntad.

Las bases de datos suelen estar organizadas en tablas. A estas tablas corresponden

generalmente la mayoría de los modelos de la estructura MVC, en los que se establecen

las reglas de acceso, filtrado y privilegios de cada una.

Aunque por lo general cada tabla tiene su modelo correspondiente, esto no es

estrictamente imprescindible, al igual que no es imprescindible que un modelo

corresponda a una tabla de una base de datos.

II.8.1.- Tablas

II.8.1.a.- Usuario:

En la tabla Usuario se almacena la información fundamental de cada uno de los

usuarios, siendo cada fila única y estando estas identificadas inequívocamente por el

campo "id_usuario".

A su vez dentro de esta tabla se almacenan las credenciales de acceso de cada usuario,

siendo estos empleados por la aplicación para conceder o denegar el acceso a la misma.

Los campos integrantes de esta tabla son los siguientes:

Id_Usuario: Identificador único de cada usuario

Usuario: Nombre del usuario

Password: Contraseña de acceso del usuario

Email: Dirección de correo electrónico del usuario

Roles: Permisos del usuario (Administrador o Usuario)

Liquidez: Capital disponible para realizar operaciones del usuario

Valor_Cartera: Valor de la cartera del usuario

Variacion_dia: Variación diaria del valor de la cartera

Base de Datos

Usuario Cartera Valores Órdenes Histórico Histórico Órdenes

Variaciones


Variación_mes: Variación mensual del valor de la cartera

Variación_year: Variación anual del valor de la cartera

II.8.1.b.- Cartera:

Todos los títulos que poseen los usuarios dados de alta en el sistema se encuentran

almacenados en la tabla cartera. Estos se encuentran relacionados con el usuario que los

posee por medio del campo "user_id". De esta forma pueden existir varias filas con el

mismo campo "ticker", que identifica el valor concreto de manera inequívoca, también

varias filas con el mismo campo "user_id", pero solo UNA con una combinación

determinada de ambos.

Los campos integrantes de esta tabla son:

Id_Cartera: Identificador único de cada fila de la tabla Cartera

User_id: Identificador que relaciona una fila de la tabla con un usuario

Ticker: Identificador único del título correspondiente. Relaciona la fila

con un valor concreto de la tabla Valores

Nombre: Nombre del título correspondiente

Precio: Precio actual del título correspondiente

Tipo: Tipo de título adquirido

Cantidad: Cantidad de títulos de un valor que posee el usuario correspondiente

Importe: Valor total actual de la posición reflejada por una fila

Variación_dia: Variación diaria del importe de una fila

II.8.1.c.- Valores:

Los datos de los valores disponibles en el sistema para que los usuarios puedan realizar

operaciones bursátiles se almacenan en esta tabla. En ella se identifica cada valor de

manera única e inequívoca mediante el campo "ticker".

De esta tabla se nutren todas aquellas que hagan algún tipo de referencia a un valor

determinado. Al mismo tiempo dicha tabla obtiene los datos mediante un proveedor

público de datos bursátiles.


Id_valores: Identificador único de cada fila de la tabla Valores

Ticker: Identificador único de cada valor. Se emplea también como

identificador único de una fila de la tabla

Nombre: Nombre del valor correspondiente

Precio: Precio actual del valor correspondiente

Tipo: Clase de título componente de la fila


Mercado: Mercado bursátil donde puede adquirirse el título

Variación_dia: Variación diaria del precio del valor

Update_time: Fecha y hora de la última actualización

II.8.1.d.- Órdenes:

Las órdenes creadas por los usuarios son almacenadas en esta tabla. En dicha tabla se

sigue un método análogo al empleado en la tabla Cartera para relacionar una orden

concreta con el usuario que la creo y con el valor que la integra. Para ello se emplea el

campo "id_usuario", para relacionarla con el usuario que la ha creado, y el campo

"ticker" para relacionarla con el valor sobre el cual es la orden.


Id_Orden: Identificador único de cada fila de la tabla Órdenes

Id_Usuario: Número de identificación del usuario creador de la orden

Ticker: Identificador único del valor objeto de la orden

Nombre: Nombre del valor integrante de la orden

Tipo_valor: Clase del valor sobre el que se hace la orden

Tipo_orden: Clase de orden creada (IF-DONE, LIMITADA, STOP LOSS)

Acción: Operación a realizar cuando la orden se ejecute (Compra o Venta)

Precio_objetivo: Precio condicionante para la ejecución de la orden

Cantidad: Cantidad de títulos sobre los que tiene efecto la orden

Fecha_ejecucion: Fecha límite antes de la cual la orden deberá ejecutarse, o de

lo contrario se ejecutará en ese momento independientemente

de otras condiciones

Fecha_caducidad: Fecha tras la cual la orden será eliminada del sistema en

en caso de no haberse ejecutado previamente

Fecha_creacion: Fecha en la cual se creó la orden por el usuario

II.8.1.e.- Histórico:

Todo reporte de una operación realizada por un usuario es almacenado en la tabla

"Histórico", de tal forma que el usuario pueda tener conocimiento total de todo lo que

ha acontecido en su cartera desde el primer momento.

Por otro lado, para el caso de que una operación concreta sea realizada por el sistema al

ejecutar de manera autónoma una orden debido al cumplimiento de alguna de sus

condiciones, también se guarda un histórico de la operación realizada en esta misma

tabla.



Id_historico: Identificador único de un registro de la tabla Histórico

Id_usuario: Identificador del usuario que ha realizado la operación en cuestión

Operación: Operación realizada (Compra o Venta)

Ticker: Ticker del valor sobre el cual se ha realizado la operación

Tipo: Clase de valor objeto de la operación

Cantidad: Número de títulos de la operación realizada

Precio: Precio al que se realizó la operación

Importe: Valor de la operación en su momento de ejecución

Fecha: Fecha y hora a la que se realizó la operación

II.8.1.f.- Histórico Órdenes:

De igual manera que se guarda un histórico de las operaciones que se realizan se guarda

también un histórico de lo que sucede con las órdenes creadas por los usuarios. Esto es

tanto si se ejecutan como si no, o como si caducan. Dicho histórico de órdenes se

almacena en la base de datos en la tabla homónima.


Id_historden: Identificador único de una fila de la tabla Histórico de Órdenes

Orden_id: Identificador de la orden correspondiente

User_id: Identificador del usuario que creó la orden

Ticker: Ticker del valor sobre el cual se creó la orden

Tipo_orden: Clase de orden (IF-DONE, LIMITADA, STOP LOSS)

Accion: Operación a realizar por la orden (Compra o Venta)

Precio: Precio objetivo fijado por el usuario en la orden

Cantidad: Cantidad de títulos sobre los que corresponde la orden

Ejecución: Paradero final de la orden (EJECUTADA, NO EJECUTADA,

CADUCADA)

Fecha: Fecha de ejecución o eliminación de la orden

II.8.1.g.- Variaciones:

Para el cálculo de las variaciones diarias, mensuales y anuales de las carteras de los

usuarios es necesario tener una seria de valores de referencia. Dichos valores de

referencia son almacenados en la tabla "Variaciones" y modificados oportunamente por

el sistema cuando se comienza un nuevo ciclo. Dicho de otra forma el valor de

referencia diaria se modifica cada día, el valor de referencia mensual cada mes y el

anual cada año.



Id_usuario: Identificador único de una fila de la tabla Variaciones. Este campo

se emplea además para relacionar una fila de esta tabla con una

cartera concreta

Valord0: Valor de referencia para el cálculo de las variaciones diarias

Valorm0: Valor de referencia para el cálculo de las variaciones mensuales

Valory0: Valor de referencia para el cálculo de las variaciones anuales

Fecha: Fecha de la última modificación de los valores de referencia

II.8.2.- Relaciones entre tablas

A continuación pueden verse las relaciones entre las tablas integrantes de la base de

datos de la aplicación de una manera global.


II.9.- Diagramas de relaciones MVC

Los siguientes diagramas especifican las relaciones entre los controladores los modelos

y sus vistas, tomando como referencia los distintos controladores empleados en la

arquitectura MVC de la aplicación desarrollada.

II.9.1.- Controlador Site

Mediante el controlador Site se gestiona el acceso a la aplicación de los usuarios, se

recaba y muestra la información de su cartera y se le proporciona acceso a la sección

donde puede realizar operaciones con los valores disponibles en la aplicación.

II.9.2.-Controlador Stock

Puede decirse que el controlador Stock es el núcleo central de operaciones de la

aplicación. Desde el se realizan las compras y ventas de acciones y la creación de

órdenes. Este controlador es el encargado de mostrar al usuario las vistas desde las

cuales le es posible proporcionar los datos necesarios para efectuar una operación o

crear una orden.

Estas vistas son en esencia formularios, parcialmente rellenos al inicio, que, tras ser

completados por el usuario, remiten la información de nuevo al controlador Stock para

que realice la operación pertinente.

Site

Modelos

LoginForm Valores

Usuario Cartera

Vistas

Index Login

Stock Cartera


II.9.3.- Controlador Perfil

Desde el controlador Perfil es posible realizar todas aquellas tareas que están

restringidas al perfil de un usuario en concreto. Es posible revisar y gestionar ordenes,

realizar ventas a mercado de valores que se posean, poner órdenes de venta, ver los

históricos tanto de operaciones como de órdenes y ver gráficas de valores, función

también incluida en el controlador Stock previamente descrito.

Stock

Modelos

Usuario Cartera

Órdenes Histórico

ChartForm

Vistas

Login Reporte

Compra Venta

Chartselection Chart

OrdenCselect OrdenVselect

Perfil

Modelos

Usuario Cartera


Vistas

Cartera Órdenes



II.9.4.- Controlador Admin

El uso del controlador Admin se encuentra restringido a aquellos usuarios con el

permiso apropiado. Desde dicho controlador es posible revisar los usuarios dados de

alta en el sistema, eliminarlos o crear nuevos.

Admin

Modelos

Usuario Cartera

Variaciones

Vistas

AdminMenu Users

CreateUser


II.10.- Controlador Site: Funciones e interacciones con base de datos

II.10.1.- Función Index

Esta la función por defecto de la aplicación. Su única pero crucial misión es mostrar la

vista Index o principal de la aplicación, junto con la layout básica llamada Main. Dicha

layout es la responsable de mostrar el menú de opciones fijo en la parte superior de la

pantalla, que heredado de vista a vista siempre que no se especifique lo contrario.

El controlador no realiza interacciones con la base de datos mediante la función Index.

II.10.2.- Función Login

La función Login es la encargada de gestionar la autorización de acceso a la aplicación

de los usuarios. Esta función se emplea tanto para mostrar el formulario de ingreso deen

caso de que los usuarios no estén logeados ya en el sistema, como para autorizar su

acceso cuando este formulario haya sido rellenado debidamente por el usuario y sus

datos hayan sido contrastados por el sistema.

II.10.2.a.- Diagrama de flujo:

MUESTRA

FORMULARIO

LOGIN

COMPROBACIÓN

DATOS

ESTABLECE

MENSAJE ERROR

REDIRIGE A

FUNCIÓN

PERFIL

INICIO

FIN INCORRECTOS CORRECTOS


II.10.2.b.- Interacciones con base de datos:

II.10.3.- Función Logout

La función Logout cierra la sesión de un usuario activo y lo redirecciona a la vista de

entrada de la aplicación. Esta función no realiza interacción alguna con la base de datos.

II.10.4.- Función Buscavalor

Esta función es la encargada de generar la sección denominada "Trading" dentro de la

aplicación, desde donde el usuario puede tener acceso a todos los valores disponibles en

la misma y realizar operaciones con ellos.

La función emplea el modelo de la tabla Valores con la regla "search", la cual permite

filtrar los datos desde la tabla que se le mostrará al usuario conteniendo todos los

valores.

A continuación la función muestra la vista "Stock" utilizando como parámetro el

modelo de la tabla Valores. Dicho modelo es empleado para volcar todo el contenido de

la tabla Valores en la tabla de la vista.

En este vista además se le presentan al usuario las distintas opciones de operación con

los valores existente. El usuario es redireccionado a distintas funciones de otros

controladores al elegir una opción concreta.

BD

TABLA USUARIO FUNCIÓN LOGIN




LLAMADA AL

MODELO CON

REGLA 'SEARCH'

MUESTRA VISTA

CON MODELO

COMO PARÁMETRO

INICIO

FIN

BD

TABLA VALORES FUNCIÓN BUSCAVALOR


II.11.- Controlador Stock: Funciones e interacciones con base de datos

II.11.1.- Función Compra

Al contrario de lo que pueda parecer la función Compra no es en sí la que se encarga de

efectuar la compra a mercado de los valores, sino la que muestra el formulario,

parcialmente relleno con la información del valore que se desea comprar, al usuario,

para que este lo complete con los datos restantes. En nuestro caso estos datos restantes

son solamente la cantidad de valores a comprar.

Debe tenerse en cuenta que a esta función se llega desde la tabla en la que se muestran

los valores disponibles. Por tanto, al seleccionar en uno de ellos para comprarlo, se

transfieren todos sus datos de relevancia a la función Compra del controlador Stock.



En rigor esta función no interacciona con la base de datos, ya que los datos que maneja

son heredados de una función anterior (Buscavalor en Site) que sí interaccionó con la

base datos para obtener la información de los valores que componían la tabla que

mostraba.

INICIO

NO

FUNCIÓN

LOGIN EN

SITE

USUARIO

LOGEADO

MUESTRA

FORMULARIO

COMPRA

FIN

SI

DATOS

VALOR


II.11.2.- Función Buyshares

Esta función es la verdaderamente encargada de realizar la compra de los valores y

todas la acciones que ello conlleva.

Se llega a esta función desde la vista que muestra la función compra, transfiriéndose los

datos que se muestran en la misma así como los que ha introducido el usuario.

La función Buyshares comprueba siempre si el usuario posee liquidez suficiente para

realizar la operación de compra a mercado que desea. En caso afirmativo efectúa la

compra actualizando la cartera del usuario y su liquidez. Por otro lado genera un nuevo

registro en el histórico de la plataforma con los datos de la operación y muestra un

reporte de la operación realizada.


INICIO

NO USUARIO TIENE

LIQUIDEZ SUFICIENTE

MUESTRA

REPORTE DE

COMPRA

FIN

SI

DATOS

COMPRA

VALOR NUEVO

EN CARTERA

ESTABLECE

MENSAJE DE

ÉXITO

REGISTRA

COMPRA EN

HISTÓRICO

RESTA EL

IMPORTE DE LA

LIQUIDEZ

ACTUALIZA EL

REGISTRO EN

TABLA CARTERA

CREA UN NUEVO

REGISTRO EN

TABLA CARTERA

SI

NO

ESTABLECE

MENSAJE DE

ERROR



II.11.3.- Función Venta

La función Venta es prácticamente igual que la función Compra, estando destinada a

mostrar al usuario el formulario de venta de algún valor que este posee en cartera. Al

igual que el caso de la función Compra el formulario es parcialmente relleno con los

datos del valor que se quiere vender, siendo estos transferidos desde la tabla que

muestra los valores integrantes de la cartera del usuario en su perfil.


BD

TABLA HISTÓRICO FUNCIÓN BUYSHARES

TABLA USUARIO

TABLA CARTERA

INICIO

NO

FUNCIÓN

LOGIN EN

SITE

USUARIO

LOGEADO

MUESTRA

FORMULARIO

VENTA

FIN

SI

DATOS

VALOR



La función Venta no interacciona con la base de datos de ninguna forma. Toda la

información que maneja es heredada de una función precedente. Igual que en la función

Compra.

II.11.4.- Función Sellshares

Siguiendo una dinámica similar a la que se sigue en la compra de valores a mercado, la

función Sellshares es la encargada de realizar la venta del valor deseado de la cartera.

De manera análoga al proceso de compra se llega a esta función desde la vista que

muestra la función venta, transfiriéndose los datos que se muestran en la misma así

como los que ha introducido el usuario.

La función Sellshares resta la cantidad de títulos de la venta de la cartera del usuario,

suma el importe de la venta a la liquidez del usuario, guarda un registro de la operación

en el histórico y muestra un reporte de confirmación de la operación.


INICIO

NO CANTIDAD DE

TÍTULOS MENOR QUE

TÍTULOS EN CARTERA

MUESTRA

REPORTE DE

VENTA

FIN

SI

DATOS

VENTA

ESTABLECE

MENSAJE DE

ÉXITO

REGISTRA VENTA

EN HISTÓRICO

SUMA EL

IMPORTE A LA

LIQUIDEZ

ACTUALIZA EL

REGISTRO EN

TABLA CARTERA

ELIMINA EL

REGISTRO EN

TABLA CARTERA



II.11.5.- Función Selectchart

Esta la función llamada cuando un usuario desea visualizar la gráfica de un valor. Dado

que el usuario debe configurar previamente el gráfico que verá la visualización del

mismo se hace en dos pasos. La función Selectchart es el primero de ellos.

A la función se le proporciona un solo parámetro identificativo del valor cuya gráfica

se desea ver, y esta devuelve un formulario con diferentes opciones para que el usuario

determine el tipo de gráfico que desea ver y lo visualice a su gusto.


BD

TABLA HISTÓRICO FUNCIÓN SELLSHARES

TABLA USUARIO

TABLA CARTERA

INICIO

MUESTRA

FORMULARIO

VENTA

FIN

TICKER

VALOR



La función Selectchart no realiza ninguna interacción con la base de datos. Toda la

información que maneja es heredada de funciones precedentes.

II.11.6.- Función Getchart

El segundo paso en la dinámica para mostrar un gráfico es la función Getchart. Esta

función recibe la información del formulario de selección, es decir, el identificador del

valor y los parámetros definidos por el usuario que establecen la gráfica que desea le

devuelva el sistema. A partir de aquí el proceso consiste en añadir a una sentencia de

petición base de gráficas a nuestro proveedor dichos parámetros.


INICIO

NO

ESCALA

LOGARÍTMICA

FIN

SI

DATOS

GRÁFICA

MEDIA MÓVIL

ACTIVA INDIC.

TÉCNICOS

SELECCIONADOS

ACTIVA ESCALA

EN PETICIÓN

ACTIVA MEDIA

MÓVIL EXP. EN

PETICIÓN

SI

NO

ACTIVA MEDIA

MÓVIL EN

PETICIÓN

MEDIA MÓVIL

EXPONENCIAL

NO

SI

INDICADORES

TÉCNICOS

SI NO

ENVÍA PETICIÓN Y

MUESTRA

GRÁFICA

INDICADORES

TÉCNICOS

AVANZADOS

ACTIVA INDIC.

TÉCNICOS AVAN.

SELECCIONADOS

SI

NO



La función Getchart exclusivamente maneja la petición del usuario, la remite al

proveedor de datos financieros y muestra la gráfica al usuario. No hay interacción

alguna con la base datos en todo es proceso.

II.11.7.- Función Ordencompra

Esta función se encarga de mostrar el formulario de creación de órdenes de compra y,

al igual que en la función Compra, la información referente al valor sobre el que se

desea poner la orden se hereda desde la tabla donde se selecciona el valor deseado.



Esta función no realiza interacción alguna con la base de datos al ser el procedimiento

de creación de órdenes un proceso en dos pasos al igual que la compra o el visionado de

gráficas.

INICIO

NO

FUNCIÓN

LOGIN EN

SITE

USUARIO

LOGEADO

MUESTRA

FORMULARIO

ORDEN COMPRA

FIN

SI

DATOS

VALOR


II.11.8.- Función Ordenventa

Análogamente, para la creación de órdenes de venta existe la función Ordenventa, que

sigue un procedimiento similar a la función Ordencompra.

Téngase en cuenta que a esta función se accede desde la cartera del usuario y, por tanto,

solo pueden ponerse órdenes de venta sobre los valores que existan en la misma. A esta

función se le pasa además un parámetro extra que limita la cantidad de acciones que

pueden ser vendidas a partir de cuantas se posean.



De manera similar a la función Ordencompra esta función tampoco realiza interacción

alguna con la base de datos.

II.11.9.- Función Orden

La función Orden es empleada tanto para la creación de órdenes de compra como de

venta, y ambos formularios de creación de órdenes remiten la información a esta

función una vez han sido rellenados por el usuario.

INICIO

NO

FUNCIÓN

LOGIN EN

SITE

USUARIO

LOGEADO

MUESTRA

FORMULARIO

ORDEN VENTA

FIN

SI

DATOS

VALOR


Cuando la función recibe la información determina en primer lugar si la orden es de

compra o de venta y a continuación la inscribe en la base de datos y muestra un reporte

de orden insertada con éxito al usuario.



INICIO

NO

ORDEN

COMPRA

GUARDA ORDEN

EN EL SISTEMA

FIN

SI

DATOS

ORDEN

CREA ORDEN

DE COMPRA CREA ORDEN

DE VENTA

BD

TABLA ÓRDENES FUNCIÓN ORDEN

TABLA CARTERA

MUESTRA

MENSAJE DE

ÉXITO


II.12.- Controlador Perfil: Funciones e interacciones con base de datos

II.12.1.- Función Perfil

La función Perfil se emplea para mostrar el apartado de perfil del usuario, desde donde

el mismo puede consultar su histórico, ver las órdenes abiertas en el mercado, poner

órdenes de venta y vender valores directamente a mercado, además de visualizar

gráficas de los valores que posee en la cartera.

Esta función emplea el modelo de la tabla Usuario y el de la tabla Cartera para generar

sendos proveedores de datos que se emplearan para poblar de información las tablas

tanto de resumen como de valores que pueden verse en la vista cartera dentro del perfil,

a la que le redericciona automáticamente esta función del controlador.



BD

TABLA USUARIO FUNCIÓN PERFIL

TABLA CARTERA

INICIO

NO

FUNCIÓN

LOGIN EN

SITE

USUARIO

LOGEADO

OBTIENE DATOS

DE CARTERA DE

USUARIO

FIN

SI

MUESTRA LA

VISTA CARTERA


II.12.2.- Función Histórico

La misión de esta función es simplemente la de mostrar al usuario el registro o

histórico de operaciones. Para ello emplea el modelo de la tabla Histórico e interacciona

con la base de datos para obtener todos los registros del usuario en cuestión. A

continuación muestra dichos registros de forma ordenada al usuario.



BD

TABLA HISTÓRICO FUNCIÓN HISTÓRICO

INICIO

OBTIENE DATOS

DE HISTÓRICO

DEL USUARIO

FIN MUESTRA LA

VISTA HISTÓRICO


II.12.3.- Función HistoricoOrden

Esta función trabaja de manera similar a como lo hace la función Histórico previamente

descrita. En este caso se emplea el modelo de la tabla Historicoorden y se obtienen las

filas de la misma correspondientes al usuario que hace la solicitud. Posteriormente se le

muestra al mismo los resultados obtenidos en dicha búsqueda, mediante una tabla, en la

vista HistoricoOrden.



BD

TABLA HISTÓRICO

ÓRDENES FUNCIÓN HISTÓRICO ÓRDENES

INICIO

OBTIENE DATOS

DE HISTÓRICO

DE ÓRDENES

FIN MUESTRA LA VISTA

HISTÓRICO DE

ÓRDENES


II.12.4.- Función GestOrder

Su misión es la de mostrar al usuario todas aquellas órdenes que tenga abiertas en el

sistema, facilitándole además la posibilidad de eliminarlas. Para esto último se emplea

otra función que es descrita posteriormente en la presente memoria.

La función GestOrder se vale del modelo de la tabla Órdenes para realizar una consulta

a esta tabla de la base de datos y exportar aquellos referentes al usuario actual para

mostrarlos en la tabla de la vista Órdenes.

Para permitir el filtrado de órdenes por parte del usuario se emplea la regla "search" a

la hora de recurrir al modelo de la tabla. De esta forma el usuario puede realizar una

búsqueda rápida de una orden en concreta de entre todas las que tiene abiertas en el

sistema.



BD

TABLA ÓRDENES FUNCIÓN GESTORDER

INICIO

OBTIENE DATOS

DE ÓRDENES

FIN MUESTRA LA

VISTA ÓRDENES


II.12.5.- Función KillOrder

Como se comentó en el apartado anterior, el usuario tiene la posibilidad de eliminar una

orden del sistema. Dicha operación la lleva a cabo la función del controlador Perfil

denominada KillOrder. A esta función se remite el identificador de la orden que se

desea eliminar desde la vista Órdenes, cuando el usuario ha realizado su selección.

Una vez se llega a la función, habiéndose recibido como parámetro el identificador de

la orden a eliminar, se realiza una búsqueda en la tabla Órdenes a partir de dicho

identificador. Ello es necesario puesto que se requiere información adicional para los

siguientes pasos.

Con la información adicional obtenida sobre la orden se crea un registro de eliminación

de la misma en la tabla Historicoorden y, a continuación, se elimina la orden de la tabla

Órdenes. Finalmente se muestra un mensaje de éxito de la operación.


INICIO

ELIMINACIÓN DE

ORDEN DEL

SISTEMA

FIN

IDENTIFICADOR

ORDEN

CONSULTA

DATOS ORDEN

MUESTRA

MENSAJE DE

ÉXITO

REGISTRO DE

ELIMINACIÓN EN

HISTÓRICO ORDEN



BD

TABLA HISTÓRICO

ÓRDENES FUNCIÓN PERFIL

TABLA ÓRDENES


II.13.- Controlador Admin: Funciones e interacciones con base de datos

II.13.1.- Función Management

La función Management, Gestión en inglés, es la función principal del controlador

Admin, y por tanto la primera a la que se acude siempre para la administración de la

aplicación desde la plataforma. Su única misión es la de mostrar por pantalla el menú de

administración de la aplicación, así como garantizar que el usuario que accede a él tiene

los permisos adecuados.

Téngase en cuenta que la concesión de acceso a la administración de la aplicación está

protegida en dos niveles diferentes. Uno a nivel menú de navegación, mostrando la

opción "Gestión" solo a usuarios registrados con permiso de administrador, y otro a

nivel controlador, volviendo a comprobar los permisos del usuario cuando se llama a la

función Management.

Para proteger aún más la administración de la aplicación es habitual que en cada

función a la que se hace llamada durante la misma se comprueben, una vez más, los

permisos del usuario. De esta forma el control de permisos, en el caso de la

administración, es redundante a varios niveles. Por consiguiente se previene así el

acceso directo a alguna función de administración sin necesidad de logearse o de tener

los permisos de administrador requeridos para ello. Cosa que sería posible hacer si no

existiera esta seguridad redundante mediante, tan solo, escribir la dirección del

controlador y su función en el explorador.


INICIO

NO

USUARIO

ADMINISTRADOR

MUESTRA

MENÚ ADMIN. FIN

SI DENIEGA

ACCESO



II.13.2.- Función CreateUser

El administrador de la aplicación tiene dos capacidades de gestión fundamentales:

Crear nuevos usuarios y eliminarlos. Ambas tareas son realizadas siguiendo un esquema

de dos pasos parecido al que se sigue para la compra, venta o creación de órdenes.

En estos procesos de dos pasos primeramente se muestra al usuario la vista donde

pueda introducir o visualizar una información determinada, y luego se lleva a cabo la

tarea correspondiente.

Para el caso de la creación de nuevos usuarios la función CreateUser es el primero de

sus dos pasos. Su misión es la de mostrar al administrador el formulario que habrá de

rellenar para dar de alta al nuevo usuario en el sistema.

Dado que cualquier usuario del sistema debe tener un número de identificación único

para que la plataforma pueda gestionar todas las operaciones y tareas que este realice, la

función CreateUser deberá asignar dicho número de identificación de manera

automática al nuevo usuario. A tal efecto la función consulta el número de usuarios

registrados y, dado que el identificador es ordinal, suma un número más al número de

usuarios existentes y lo emplea para rellenar parcialmente el formulario que debe

rellenar el administrador con los datos restantes. Evidentemente no se le permite al

administrador modificar dicho número de identificación.

Por otro lado, como es habitual, aquí también se hace redundante la comprobación de

permisos de administración del usuario, brindando así un mayor nivel de seguridad.

BD

TABLA USUARIO FUNCIÓN MANAGEMENT




II.13.3.- Función AddUser

El segundo paso del proceso de creación de usuarios es la función AddUser. Ella

emplea los datos proporcionados por el usuario más el número de identificación único

proporcionado por el sistema para añadir dicho usuario a la base de datos.

La función crea al nuevo usuario como un nuevo registro en la tabla Usuario, y por otro

lado crea sus valores de referencia para el cálculo de las variaciones de su cartera en la

tabla Variaciones. De esta forma se consigue total correspondencia entre la tabla

Usuario y la tabla Variaciones, previniendo errores.

INICIO

NO

USUARIO

ADMINISTRADOR

DETERMINACIÓN

IDENTIFICADOR

USUARIO

FIN

SI DENIEGA

ACCESO

BD

TABLA USUARIO FUNCIÓN CREATEUSER

MUESTRA VISTA

CREACIÓN

USUARIO


La función recalcula el número de identificación del usuario siguiente y muestra de

nuevo el formulario de creación de usuarios junto con un mensaje de éxito. Esto se hace

de esta forma para agilizar el proceso de creación de múltiples usuarios por parte del

administrador. No puede evitarse que el administrador introduzca todos los datos

manualmente pero sí que tenga que seleccionar una y otra vez la opción de

introducción, facilitándose así la tarea.



INICIO

ESTABLECE

IDENTIFICADOR

NUEVO USUARIO

FIN

DATOS

USUARIO

AÑADE

USUARIO

MUESTRA MENSAJE

DE ÉXITO Y

FORMULARIO

CREACIÓN

AÑADE

VARIACIONES

DE REFERENCIA

BD

TABLA

VARIACIONES FUNCIÓN ADDUSER

TABLA USUARIO


II.13.4.- Función SelectUser

La función SelectUser permite al administrador gestionar los usuarios dados de alta

hasta el momento en el sistema. Esta función permite, por un lado, ver en una tabla

todos los usuarios existentes y, por el otro, seleccionar un usuario determinado para su

eliminación del sistema. Siendo en este último caso el primer paso de los dos que hay

que dar para eliminar un usuario concreto.

De nuevo, al igual que en otras funciones del controlador Admin, se vuelve a emplear

una seguridad redundante para controlar siempre que el usuario tiene los permisos

adecuados.

También se emplea una regla de búsqueda en el modelo de la tabla usuario empleado

para permitir así el filtrado de usuarios desde la tabla de la vista.



INICIO

NO USUARIO

ADMINISTRADOR

FIN

SI DENIEGA

ACCESO

BD

TABLA USUARIO FUNCIÓN SELECTUSER

MUESTRA VISTA

SELECCIÓN

USUARIO


II.13.5.- Función KillUser

La función KillUser es la encargada de borrar todo rastro del sistema del usuario

eliminado. No solo eliminando las credenciales del mismo, sino también los valores que

poseyera, las órdenes que hubiese creado y sus históricos de órdenes y operaciones.

Dado que la asignación de número de identificación de usuario es ordinal, es necesario

modificar los identificadores de los usuarios por encima del usuario eliminado. Los que

se encuentran por debajo, naturalmente, se mantienen igual.

Debido a que prácticamente toda la información en la mayoría de las tablas está

relacionada con un usuario concreto a través del número de identificación del mismo,

tales como valores que posee y las órdenes que ha creado entre otros, se hace

fundamental modificar también los números de identificación de usuario en las otras

tablas, no solamente en la tabla Usuario.

Para que pueda comprenderse mejor, si el administrador elimina el usuario con

identificador "6", la aplicación eliminará todos los registros de todas las tablas cuyo

campo identificador de usuario sea "6". Una vez realizado esto el sistema modificará el

identificador de, por ejemplo, el usuario "7" restándole uno y pasando ahora a ser este

"6", no solo en la tabla usuario sino también en las demás. De esta forma toda la

información del usuario "7" permanece intacta y asociada a él aunque el número de

identificación del mismo sea ahora distinto. Idéntico procedimiento se sigue con todos

los usuarios por encima del eliminado hasta el último.

Como en otras funciones de este controlador la comprobación de las credenciales de

administrador es redundante.


INICIO

NO

USUARIO

ADMINISTRADOR

ELIMINA LOS

REGISTROS CON

ESE ID USUARIO

FIN

SI DENIEGA

ACCESO

ACTUALIZA LOS

ID USUARIO

RESTANTES

ID

USUARIO



BD

FUNCIÓN KILLUSER

TABLA

USUARIO

TABLA

CARTERA

TABLA

ÓRDENES

TABLA

HISTÓRICO

TABLA

HISTÓRICO

ÓRDENES

TABLA

VARIACIONES


II.14.- Marco de trabajo


Desarrollar una aplicación cualquiera, independientemente de la función que esté

llamada a cumplir o del servicio que preste, presenta habitualmente la necesidad de

llevar a cabo tareas por parte del programador que poco o nada tienen que ver con la

elaboración e implementación de la lógica que opera tras las misma o el diseño de una

interfaz visual adaptada para su propósito. Dichas tareas, por regla general rutinarias, y

que son comunes y fácilmente exportable entre aplicaciones, consumen un tiempo de

programación que, en realidad, no es productivo. Puesto que al completarlas aún no se

tiene una aplicación con ninguna funcionalidad concreta sino más bien la estructura

básica sobre la que se ha de empezar a construir.

Para eliminar la necesidad de que los programadores y desarrolladores,

fundamentalmente los más prolíficos, tengan que repetir una y otra vez la creación de

esta estructura básica en cada una de las aplicaciones que desarrollen se emplean los

marcos de trabajo. Más conocidos por su apelativo en inglés "Frameworks".

Estos "frameworks" permiten al desarrollador de aplicaciones la creación de la

estructura básica de una aplicación en pocos minutos y con un empleo mínimo de

recursos. De esta forma se puede partir de un esqueleto fundamental, que cumple con

las condiciones y funcionalidades más básicas y comunes de una aplicación cualquiera,

y empezar a desarrollar la aplicación directamente sobre dicha estructura base. Incluso,

en ocasiones, basta con modificar determinados elementos creados por el "framework"

para conseguir algunas funcionalidades o características de la aplicación en desarrollo.

Como es lógico existen "frameworks" destinados a la creación de la estructura de

partida de aplicaciones desarrolladas en distintos lenguajes de programación. Como, por

ejemplo, Zen Framework para lenguaje PHP o ASP.NET para crear aplicaciones en

ASP siguiendo una arquitectura Modelo-Vista-Controlador.

II.14.2.- Framework YII

El marco o framework empleado para el desarrollo de la aplicación objeto del presente

proyecto es el conocidísimo y muy reputado framework YII, acrónimo en inglés de

"Yes It Is!". YII es un marco de trabajo gratuito, programado en PHP5 que proporciona

un diseño base de una aplicación en PHP limpio y sencillo y que permite el rápido

desarrollo de la misma. A su vez YII proporciona una serie de herramientas utilísimas


que hacen que el desarrollo de la aplicación por parte del programador se aún más

rápido y eficiente.

II.14.2.a.- Características principales

De entre todas las características de este marco de trabajo cabe destacar las siguientes,

aunque no todas hayan sido empleadas en el desarrollo de la aplicación:

Diseño Modelo-Vista-Controlador

DAO: Acceso a base de datos como objetos

Creación de formularios y validación

Autentificación y autorización

Capacidad de internacionalización y localización de la aplicación

Gestión de errores

Logging

Seguridad integrada que previene determinados tipos de ataques

Empleo de temas para mejorar la apariencia

Utilidad de generación automática de código

Librería de funcionalidades extras y de libre acceso

II.14.2.b.- Empleo de YII en el desarrollo de la aplicación

YII ha sido empleado para la creación de la estructura base de la aplicación de

inversión bursátil desarrollada. Estructura a partir de la cual se ha comenzado a

construir tanto la lógica como el aspecto visual y la base de datos de la aplicación.

No se ha empleado YII para la elaboración de la base de datos en absoluto, aunque sí

para generar los modelos de las tablas de la misma. Modelos que han sido modificados

en contadas ocasiones y por necesidades muy puntuales. Ha sido el caso, por ejemplo,

del establecimiento de reglas para el filtrado de los datos de determinadas tablas.

Por otro lado se ha empleado YII para controlar el acceso de usuarios a la plataforma y

permitírselo o denegárselo. Esto además permite el uso de una serie de atajos de

programación que son extraordinariamente útiles y ampliamente aplicables en distintos

escenarios. Es el caso, por ejemplo, del conocimiento inmediato y en cualquier

momento del acceso o no de los usuarios a la aplicación, así como de los privilegios de

acceso que estos tienen. De esta forma, con solo una línea de código, es posible saberse

si un usuario determinado es o no administrador del sistema, por ejemplo.

A su vez el uso de la funcionalidad DAO de YII ha permitido que las consultas y

modificaciones de registros en la base de datos se hayan podido programar de una


manera más intuitiva, rápida y eficaz. No teniéndose la necesidad de escribir la

sentencia SQL para realizar una operación determinada con la base de datos, ya que con

esta funcionalidad esta se hace accesible como si de un objeto se tratase. Si bien es

cierto que no siempre se ha hecho uso de esta funcionalidad. YII ha facilitado también

todo el proceso de conexión a la base de datos. Simplificándolo y estandarizándolo.

Evidentemente, no se ha podido emplear ninguna funcionalidad de YII para el

desarrollo del actualizador. Esto es debido a que el actualizador, a pesar de ser en la

práctica muy similar a un controlador de la aplicación, funciona de manera

independiente de la aplicación. Es decir, no es necesario ejecutar la aplicación para que

el actualizador funcione. Esto, que permite mantener la base de datos actualizada sin

necesidad de intervención humana, tiene como contrapartida que todas las ventajas,

funcionalidades y atajos que ofrece YII, y que sí han sido usados para el resto de

componentes, no puedan ser empleados aquí. Así, por ejemplo, en el actualizador ha

sido necesario escribir todas y cada una de las sentencias de consulta o modificación de

la base de datos o, también, realizar todo el proceso de conexión a la misma.


II.15.- Vistas


Las vistas, como su propio nombre indica, representan el apartado visual y de

interacción con el usuario dentro de la aplicación. Se ha decidido incluirlas en este

punto de la memoria y no antes porque, al igual que se ha hecho durante el proceso de

desarrollo de la aplicación, primero se ha elaborado la lógica que la gobierna y luego se

han establecido las interacciones con los usuarios y por último su apariencia. De ahí

que, tras haber sido descrita la lógica, sea descrita la parte de visual.

En el caso de nuestra aplicación podríamos distinguir entre tres tipos fundamentales de

vistas. Un tipo en el que el objetivo principal es mostrar información a los usuarios. Un

segundo tipo en el que lo que se pretende es que el usuario introduzca alguna clase de

datos para la aplicación, vistas conocidas como formularios. Y, por último, un tercer

tipo donde se integran los distintos menús de navegación que se muestran

permanentemente sin necesidad de ser invocados, vistas conocidas como "layouts".

En el siguiente esquema pueden verse todas las vistas existentes en la aplicación

agrupadas por controladores. Se hace esta clasificación dado que, a efectos de

programación, las vistas están asociadas a un controlador en concreto, que es el único

con potestad para invocarlas.

Aplicación

Controlador Site

Index Login

Stock

Controlador Stock

Compra Venta

OrdenCselect OrdenVselect

Chartselect Chart

Reporte

Controlador Perfil

Cartera Órdenes


Controlador Admin

Adminmenu Users

Createuser

Layouts

Main Profile

ProfileH


II.15.2.- Vistas del controlador Site

II.15.2.a.- Index

La vista es Index es la vista principal de la aplicación. Es la vista que se carga por

defecto cuando un usuario accede a la misma. En nuestra aplicación esta vista consiste,

fundamentalmente, en una pantalla de bienvenida con el título de la aplicación y

algunos datos de interés. La vista también incluye un botón que envía al usuario hacia la

acción Login del controlador Site.

II.15.2.b.- Login

Esta vista es la mostrada por la acción Login del controlador Site. También se redirige

a un usuario a esta vista en cualquier momento si se detecta que no ha introducido

credenciales válidas para el acceso en la aplicación.

La vista Login está compuesta en realidad por un formulario bastante simple que

permite al usuario introducir sus credenciales de acceso y remitírselas a la aplicación

para que las valide y le conceda acceso a la misma. En este caso cuando se pulsa sobre

el botón entrar y, siempre y cuando se haya rellenado el formulario de acceso, las

credenciales son enviadas de nuevo a la función Login del controlador Site.

En caso de ser validadas esta redirige al usuario hacia otra función en otro controlador

que le acabará mostrando una vista diferente. De no serlo se le volverá a mostrar la vista

Login con un mensaje de error.

II.15.2.c.- Stock

En la vista Stock se le muestra al usuario una tabla con todos los valores en los que es

posible invertir dentro de la plataforma, además de datos de relevancia de los mismos.

Desde el punto de vista de la programación siguiendo una estructura MVC, una vista

como esta no es más que la estructura de una tabla, con un aspecto definido y con una

serie de campos y atributos que se han fijados previamente por el programador. Pero en

realidad la tabla está vacía.

Para poblar las tablas con registros, presumiblemente de una base de datos, la función

del controlador que invocará la vista deberá primero realizar una consulta en la tabla o

tablas de la base de datos correspondiente y, tras ello, deberá pasar el resultado de dicha

consulta a la vista como parámetro al ser esta invocada. De esta forma cuando el usuario

accede a la vista a través del controlador no solo ve la estructura definida en la misma,


sino también el resultado de la consulta que el controlador ha realizado como filas de la

tabla mostrada.

Por otro lado, en cada fila de la tabla que se muestra en esta vista existen tres opciones

que el usuario puede seleccionar: Compra, Orden y Gráfica. Estas opciones permiten al

usuario comprar, poner una orden o ver la gráfica del valor de una fila concreta. Para

ello la vista remite la información de la fila seleccionada a un controlador específico,

que variará en función de la opción escogida, para que realice una cierta tarea con dicha

información.

A continuación puede verse un esquema que refleja los controladores accesibles

mediante cada una de las opciones disponibles en la tabla de la vista Stock.

II.15.3.- Vistas del controlador Stock

II.15.3.a.- Compra

La vista Compra es la que muestra al usuario la función Compra del controlador Stock,

a la que se llega, como ya hemos visto, tras seleccionar la opción Compra en una fila

cualquiera de la tabla que muestra los valores con los que se puede operar en la vista

Stock del controlador Site.

En esta vista Compra se le presenta al usuario un formulario parcialmente relleno con

los datos del valor que desea comprar. Dichos datos han sido remitidos a la vista por el

controlador que la invoca, en este caso el controlador Stock. A su vez estos datos han

llegado al controlador al ser pasados como parámetro a su función Compra desde la

vista, como ya se ha visto anteriormente.

Función Opción Controlador

Stock

Compra Stock Compra

Orden Stock Ordencompra

Gráfica Stock Selectchart


Una vez el usuario rellena el formulario mostrado con los datos restantes y, pulsa sobre

el botón "Comprar" que le muestra la vista, envía la información contenida en él a la

función BuyShares del propio controlador Stock que ya se encarga de procesar la

compra de manera apropiada.

II.15.3.b.- Venta

De manera análoga a la vista Compra, la vista Venta muestra al usuario un formulario

muy similar pero, en esta ocasión, con los datos del valor que posee en cartera y que

desea vender.

A esta vista se llega desde la función Venta del controlador Stock, a la que se le pasa la

información contenida en la tabla de la cartera del usuario, como se verá más adelante.

Quizás la diferencia más reseñable entre la vista Venta y la vista Compra es que, en el

caso de la vista Venta, la cantidad de acciones que puede fijar el usuario para su venta

está acotada superiormente por la cantidad de acciones que posee. De esta forma el

formulario de la vista Venta no permite introducir cifras en el campo cantidad que estén

por encima de este valor. Para ello a la vista Venta hay que pasarle un parámetro extra

que no se le pasaba a la vista Compra: la cantidad de acciones del valor que el usuario

tiene en cartera.

La vista venta remite los datos del formulario que contiene a la función SellShares del

controlador Stock, que ya se encarga de formalizar la venta de las acciones.

II.15.3.c.- OrdenCselect

Sigui5endo una dinámica similar a la vista de compra de valores a mercado se tiene la

vista de creación de órdenes de compra. Esta vista contiene también un formulario al

que le han sido transferidos los datos del valor sobre el que se desea poner la orden.

En este caso el usuario tiene que rellenar más campos, pero en realidad el

funcionamiento es el mismo a pesar del número extra de campos a rellenar. La

información contenida en el formulario es enviada a la función Orden del controlador

Stock que la introduce en el sistema.

Es la función Ordencompra del controlador stock la que invoca a esta vista y le pasa los

datos del valor sobre el que se va crear la orden.


II.15.3.d.- OrdenVselect

La vista de creación de órdenes de venta es prácticamente igual que la vista para la

creación de órdenes de compra, salvo, evidentemente, la función del controlador Stock

que la invoca y le pasa los datos del valor, llamada Ordenventa. La función de destino

en el controlador Stock es la misma.

Si bien es cierto que en esta vista existe una pequeña variación del formulario. Ella es

debida a que en la plataforma pueden crearse dos tipos de órdenes de venta y tan solo

una de compra. Por lo tanto, en la vista OrdenCselect el usuario no puede modificar el

tipo de orden, estando esto bloqueado y, sin embargo, aquí puede escoger entre las dos

opciones por medio de un menú desplegable.

II.15.3.e.- Chartselection

En esta vista el usuario visualiza un formulario donde se le permite escoger entre todas

las opciones disponibles para la configuración de la gráfica. Opciones que son

posteriormente enviadas a la función Getchart del controlador Stock, junto con el

identificador del valor cuya gráfica queremos ver.

Esta vista es invocada por la función Selectchart del controlador Stock, la cual también

le pasa los parámetros del valor en cuestión. De igual modo a la función Selectchart se

puede llegar bien mediante la opción "Gráfica" disponible en la tabla de la vista Stock o

bien mediante la opción homónima disponible en la tabla de la vista Cartera.

II.15.3.f.- Chart

La vista Chart sencillamente muestra la gráfica solicitada por el usuario dentro de la

propia aplicación, junto con un botón de vuelta, que envía al usuario a la sección

denominada "Trading".

II.15.3.g.- Reporte

La vista Reporte es una vista que podríamos denominar como multiusos, puesto que es

usada por diversas funciones del controlador Stock en, lógicamente, diversas

situaciones.

Esta vista muestra dentro de una cuadrícula, denominada panel, un resumen de la

operación realizada, ya sea esta la compra de valores a mercado o la creación de una

orden de venta tipo Stop.


En este caso son las propias funciones de gestión interna del controlador, es decir,

BuyShares, SellShares y Orden las que remiten a esta vista, poblándola con la

información de la operación que han realizado.

II.15.4.- Vistas del controlador Perfil

II.15.4.a.- Cartera

La vista Cartera es la vista principal dentro del perfil del usuario. A ella se llega a

través de la función Perfil dentro del controlador del mismo nombre. Dicha vista

funciona de una manera muy parecida a como lo hace la vista Stock previamente

explicada.

Sin embargo, a diferencia de la vista Stock, para poblar de información esta vista son

necesarios dos proveedores de datos de dos tablas diferentes de la base de datos, ya que

además en esta vista o se muestra un tabla sino dos.

La primera tabla, la cual se encuentra dentro de un panel para darle un diseño

diferenciado, muestra un resumen de la cartera del usuario. Se refleja en ella el valor de

la misma, su liquidez y sus respectivas variaciones diarias, mensuales y anuales. Amén

de del nombre del usuario. Como puede deducirse los datos de esta tabla de la vista son

obtenidos por el controlador que la invocan de la tabla Usuario de la base de datos.

La segunda tabla muestra el conjunto de valores que el usuario posee en su cartera, con

un aspecto prácticamente idéntico al de la tabla que se muestra en la vista Stock. Los

datos mostrados en esta tabla son obtenidos de la tabla Cartera de la base de datos.

Por comodidad para el usuario siempre que se muestra una tabla que, a priori,

contendrán un número relativamente alto de registros se procura habilitar el filtrado en

ciertos campos de la misma. De esta forma el usuario puede introducir el nombre, el

ticker o el tipo del valor que quiere ver y el sistema le filtra la tabla de acuerdo a ese

criterio, lo que facilita enormemente encontrar registros en la misma.

Por otro lado es posible ordenar la tabla creciente o decrecientemente según uno de los

campos mediante, simplemente, pulsando en el encabezado de una de las columnas.

Al igual que en la vista Stock, en esta vista también se tienen una serie de opciones

para cada valor de la cartera que permiten al usuario realizar ciertas operaciones con

ellos. Las opciones aquí presentes son las de Venta, Orden y Gráfica. Obviamente, en

este caso, la opción Orden se refiere a una orden de venta y no de compra como en la

vista Stock.


En el siguiente esquema se reflejan los controladores accesibles mediante cada una de

las opciones disponibles en la segunda tabla de la vista Cartera.

II.15.4.b.- Órdenes

Dentro de la vista órdenes un usuario puede visualizar todas las órdenes que tiene

almacenadas en el sistema y que se encuentran pendientes de ejecución. Dichas órdenes

son mostradas dentro de una tabla con una estructura similar a la de las anteriormente

vistas. Las tablas son rellenadas con información obtenida de la tabla Órdenes de la base

de datos por la función GestOrder del controlador.

En este caso, para cada orden, solo se brinda una opción al usuario: la de eliminar la

orden del sistema. Dicha opción funciona redirigiendo la información por la ruta

mostrada en el diagrama siguiente:


Cartera

Venta Stock Venta

Orden Stock Ordenventa

Gráfica Stock Selectchart


Órdenes Eliminar Perfil KillOrder


II.15.4.c.- Histórico

La vista Histórico muestra al usuario una tabla con todo el registro de operaciones

llevadas a cabo tanto por el usuario como por el sistema de manera autónoma al lanzar

órdenes.

A dicha vista se llega procedente de la función Histórico del controlador. La cual hace

la consulta apropiada a la tabla del mismo nombre de la base de datos.

En la tabla mostrada en esta vista solo se ofrece la opción de ver la gráfica de cada uno

de los valores. No se volverá a explicar la ruta de esta opción ya que es la misa que en

vistas anteriores.

II.15.4.d.- Histórico Órdenes

De igual manera que ocurre con el registro de las operaciones realizadas ocurre con el

registro de las órdenes, que es mostrado al usuario en esta vista mediante una tabla

similar a las descritas anteriormente.

La información empleada en esta vista para rellenar la tabla es obtenida mediante una

consulta a la tabla Historicoorden de la base de datos por la función del mismo nombre

del controlador.

En esta vista también se permite al usuario visualizar gráficas de los valores a los que

hacen referencia los registros de las órdenes.

II.15.5.- Vistas del controlador Admin

II.15.5.a.- Adminmenu

La única misión de esta vista, como puede deducirse por su nombre, es la de mostrar el

menú de administración. Este menú consta de dos botones, embebidos en un panel para

mejorar su aspecto, que dan a elegir al administrador entre crear un nuevo usuario en el

sistema o eliminar uno ya existente.

La primera opción envía al usuario a la función CreateUser del controlador Admin,

mientras que la segunda lo envía a la función SelectUser del mismo.

Téngase en cuenta que a esta vista solo es posible llegar desde la función Management

del controlador Admin, la cual gestiona el acceso a las funcionalidades de administrador

de la aplicación.


II.15.5.b.- CreateUser

La vista CreateUser presenta una disposición muy parecida a la que pueda presentar la

vista Venta o la vista Compra. Un formulario, parcialmente relleno donde, el

administrador en este caso, introducirá los datos del nuevo usuario a dar de alta en el

sistema.

Una vez acepta la creación del usuario, los datos son enviados a la función AddUser del

controlador, la cual añade el usuario a la tabla Usuario de la base de datos.

II.15.5.c.- Users

En la presente vista se muestra al administrador una tabla con todos los usuarios dados

de alta en el sistema. A efectos prácticos esta tabla y la tabla Usuario de la base de datos

son prácticamente la misma.

Los datos de esta vista han sido obtenidos mediante consulta por la función SelectUser

del controlador Admin, la cual se los ha pasado a la vista tras invocarla.

De manera similar a la tabla de la vista Órdenes, en esta tabla solo se facilita al usuario,

administrador aquí, la opción de eliminar cada uno de los registros individualmente. En

este caso la eliminación de un registro de la tabla en la vista Users comporta la

eliminación del usuario de la plataforma y de toda la información relacionada con él, así

como la reasignación de números de usuario a los restantes en el sistema por encima de

él.

Esta opción funciona siguiendo la ruta mostrada en el diagrama siguiente:


Users Eliminar Admin KillUser


II.15.6.- Layouts

Una Layout es una vista que se muestra conjuntamente a la vista invocada. Para una

mejor comprensión puede entenderse que las Layouts aparecen sobreimpresas a la vista

invocadas.

La layouts son mostradas siempre y cuando se invoque la vista empleando la sentencia

"render". Siendo la denominada como Main la layout que siempre se muestra en nuestra

aplicación sin necesidad de invocarse explícitamente. Una característica propiciada por

el uso de YII como marco de trabajo.

Es perfectamente posible emplear otras layouts diferentes a Main, bien excluyendo esta

o no, siempre que se especifique antes de mostrar la vista deseada.

Por regla general las layouts suelen emplearse para mostrar barras de menú, navegación

y otro tipo utilidades que interese se mantengan fijas en una zona de la pantalla al ir

cambiando de vistas en nuestra aplicación.

II.15.6.a.- Main

La layout Main contiene el menú de navegación superior, que se mantiene fijo siempre

sea cual sea la vista que se esté mostrando en nuestra aplicación.

Este menú es en realidad lo que se denomina como un "widget", que no es más que una

pieza reutilizable de código. Además el menú de navegación sufre diversas

modificaciones, añadiendo o eliminando opciones, según el usuario esté registrado o no

y según tenga o no permisos de administrador.

En el siguiente esquema puede verse a que controlador función y vista conduce cada

uno de los botones del menú de navegación superior.

Vista Función Opción Controlador

Menú

Login Site Login Login

Trading Site Buscavalor Stock

Mi Perfil Perfil Perfil Cartera

Gestión Admin Management AdminMenu

Logout Site Logout Index


II.15.6.b.- Profile

Esta layout, al contrario que Main, es solo cargada en una situación concreta. Cuando

usuario accede a su perfil. La misión de esta layout es la de mostrar un menú de

navegación más, debajo del ya existente, que permite al usuario moverse por las

distintas secciones en las que está dividido su perfil.

Al contrario de lo que pueda parecer la layout Main no es cargado a la vez que la layout

Profile. Cosa que podría deducirse erróneamente por el hecho de ver la barra de

navegación superior también cuando se carga esta layout. Sin embargo lo que sucede en

realidad es que el menú principal de navegación esta también incluido dentro de la

layout Profile.

Las opciones disponibles en el menú que muestra esta layout son las de Cartera,

Histórico y Órdenes, que redirigen al usuario de acuerdo con el esquema siguiente.

II.15.6.c.- ProfileH

La layout ProfileH es cargada por el sistema en sustitución de la layout Profile cuando

el usuario selecciona en esta última la opción de Histórico. Su misión es que, al

seleccionar Histórico, se muestre, además, una nueva opción en la barra denominada

Histórico Órdenes que permite al usuario visualizar dicho histórico al seleccionarla. Es

evidente que esta layout se carga también al seleccionar tal opción.

La ruta de controlador, función y vista seguida por esta opción es la siguiente:


Menú Profile

Cartera Perfil Perfil Cartera

Histórico Perfil Histórico Histórico

Órdenes Perfil GestOrder Órdenes


Menú ProfileH

Histórico Órdenes

Perfil HistoricoOrden HistoricoOrden


II.15.7.- Alertas

Un elemento importante dentro del funcionamiento de la aplicación y que forma parte

de la inmensa mayoría de las vistas son las alertas. Una alerta es un mensaje corto que

se muestra al usuario cuando sucede un evento determinado. Existiendo alertas de

distintos tipos, acordes con la clase de mensaje que se quiera mostrar.

Generalmente el mensaje de la alerta es establecido en una función de algún

controlador antes de mostrar la vista correspondiente. A la alerta además se le asigna un

identificador único para poder hacer uso de ella en cualquier parte de la aplicación sin

necesidad de volver a declararla. Esto es posible gracias a las funciones "setFlash",

"hasFlash" y "getFlash" ofrecidas por YII. Siendo cada una de llas para establecer una

nueva alerta, determinar si existe una alerta concreta y recuperar una alerta

respectivamente.

Los tipos de alertas creados se definen a continuación.

II.15.7.a.- Alertas de confirmación

Son aquellas empleadas para confirmar el éxito de una operación concreta. Son las que

se muestran al usuario para confirmar la realización de una compra o venta, la creación

de una orden cualquiera con éxito, la eliminación de una orden del sistema y la creación

o eliminación de un usuario por parte el administrador.

Generalmente aquellas tareas referentes a sucesos de creación de algo suelen mostrarse

en un marco de color verde, mientras que aquellas que implican la destrucción de algún

elemento se suelen mostrar en un marco de color rojo.

II.15.7.b.- Alertas de advertencia

Son aquellas empleadas para advertir al usuario sobre algún hecho. Se muestran cuando

el usuario no tiene los permisos adecuados o no está registrado en el sistema o cuando

se le deniega alguna operación.

Suelen mostrarse en dentro de un marco de color naranja cuando implican una

advertencia sobre permisos y de color rojo cuando implican la negación de alguna

operación.


II.16.- Utilidades empleadas para la implementación


En el desarrollo del presente proyecto se ha empleado una serie de utilidades y

herramientas para alcanzar los objetivos propuestos. Dado que ya se le ha dedicado un

apartado específico al marco de trabajo empleado, debido a su relevancia, no se incluirá

en el presente. Haciéndose mención y describiendo someramente el funcionamiento del

resto de utilidades y herramientas empleadas en el transcurso del mismo.

Salta a la vista que ha sido necesario un servidor virtual que permita el uso de la

aplicación a nivel local. De igual manera ha sido necesario emplear una utilidad de base

de datos a nivel local para que la aplicación desarrollada pueda funcionar

correctamente.

Por otro lado para la escritura del código fuente de la aplicación se ha empleado un

editor de código especializado. Al mismo tiempo se ha optado por programar la

aplicación, casi en su totalidad, empleando el lenguaje de programación PHP, y para las

vistas, al menos en determinadas partes, se ha decidido emplear HTML. Los motivos de

estas elecciones serán explicados a lo largo de este apartado.

II.16.2.- XAMPP

Sin duda la utilidad principal que se ha empleado, al margen de YII, es el programa

XAMPP. Este programa actúa como una consola multifunción que presta multitud de

servicios y sirve de apoyo al desarrollador.

Aunque usos y funciones tiene muchos, solo se han empleado dos de ellos. Por un lado

el servidor virtual Apache, integrado en el propio XAMPP, y por el otro la utilidad de

gestión de bases de datos conocida como PHPMyAdmin. Ambas ejecutables de manera

centralizada desde la aplicación de XAMPP y que se explican a continuación.


II.16.2.a.- Apache

El servidor Apache es un tipo de servidor HTTP (Hypertext Transfer Protocol) de uso

muy extendido y ventajoso que, además, posee una versión local la cual permite

desarrollar aplicaciones web y visualizarlas sin necesidad de transferirlas a un servidor

remoto.

Al estar tan extendido es muy posible que un posible futuro proveedor de "web

hosting" ofrezca sus servicios también desde un servidor Apache, por lo que la

implementación en el mismo de una aplicación desarrollada con la versión local de este

es inmediata.

Por otro lado los servidores Apache presentan una estructura modular que incrementa

sus funcionalidades. Es el caso por ejemplo del modulo "mod_ssl", empleado en el

desarrollo de nuestra aplicación para el establecimiento de una conexión segura.

Más aún, los servidores Apaches al ser tan populares y de código abierto cuenta con

una ingente cantidad de documentación que siempre es de ayuda para el desarrollador.

II.16.2.b.- MySQL

MySQL es uno de los sistemas de gestión de base de datos más populares existentes

actualmente. Este sistema permite administrar base de datos relacionales, es decir,

aquellas en las que la información se almacena en diferentes tablas en lugar de un único

archivo, estando las tablas relacionadas entre sí, permitiéndose así combinar sus datos

cuando sea necesario. Lo que convierte a MySQL en un administrador de bases de datos

tremendamente conveniente por su rapidez y flexibilidad.

Otro de los motivos por el que se ha elegido MySQL como gestor de base de datos ha

sido por el hecho de que su uso se encuentra ampliamente extendido entre casi todos los

servidores de internet. Ello implica que no sería necesario adaptar nuestra aplicación

para trabajar con la bases de datos en el servidor ya que este emplea el mismo sistema.

II.16.2.c.- PHPMyAdmin

Se ha empleado también durante el desarrollo de la aplicación y, más específicamente,

de la base de datos que respalda la misma la utilidad PHPMyAdmin. Esta utilidad

permite gestionar bases de datos MySQL a través de páginas web empleando un

explorador de internet cualquiera.

PHPMyAdmin proporciona una interfaz tipo página web que permite al usuario

administrar sus bases de datos y realizar en ellas cuantas operaciones sean necesarias,

evitando así la necesidad de emplear sentencias SQL para administrar la misma.


La utilidad permite al usuario también controlar el uso y la transferencia de datos

dentro de la base, lo que es muy interesante cuando se manejan grandes cantidades de

datos. También permite exportar una o varias bases de datos completas a ficheros de

diferentes formatos, muy útil para implementar la base de datos de la aplicación allá

donde sea necesario sin gran dificultad.

Por otro lado la utilidad viene integrada dentro de la herramienta XAMPP y ha sido

usada en la mayor parte del proceso de creación de la base de datos.

II.16.2.d.- Sublime Text 2

Es perfectamente posible desarrollar casi cualquier código empleando un editor de

texto cualquiera y guardando el código correspondiente en el formato adecuado. Esto,

sin embargo, aunque posible es muy poco conveniente, pues dificulta seriamente la

correcta lectura del mismo. Para mejorar la apariencia del código y facilitar la tarea al

programador se emplean editores de texto especializados. De los que existen en

abundancia en el mercado.

Estos editores permiten una estructuración del código de una manera mucho más

práctica, enumerando por lo general las líneas, permitiendo así encontrar un fallo con

mucha más facilidad. Empleando un sistema de colores que facilita la identificación de

los distintos componentes del código, y multitud de herramientas visuales destinadas a

mejorar y facilitar el proceso de programación.

Por los motivos anteriormente descritos y por considerar ser un programa de alta

calidad que ofrece características que otros no, además de muchas comunes, se ha hecho

uso del programa gratuito Sublime Text 2. Este, sin lugar a dudas, ha hecho más

intuitiva y eficiente la escritura del código de la aplicación.


CAPÍTULO III: MANUAL DE USO


III.1.- Requisitos mínimos

Para el correcto funcionamiento de esta Plataforma de Inversión Bursátil es necesario

que el usuario tenga en cuenta que existen una serie de requisitos mínimos para que la

aplicación opere de manera efectiva. Dichos requisitos son enumerados en el presente

apartado, indicando al usuario final como debe proceder para obtenerlos, instalarlos y

configurarlos debidamente.

III.1.1.- Servidor local Apache

La Plataforma de inversión está pensada para su funcionamiento a nivel local en

cualquier PC de uso diario, con sistema operativo Windows XP o superior. Para ello se

requiere la presencia en el equipo de un servidor HTTP a nivel local que simule el

comportamiento de un servidor HTTP remoto. Se requiere para ello el uso de un

servidor Apache versión 2.0 o superior, apta para protocolos de seguridad OpenSSL 1.0

o superior y preparada para PHP 5. Aunque se recomiendan las siguientes

características:

APACHE

Apache/2.4.7 (Win32); OpenSSL/1.0.1e; PHP/5.5.9

Para la instalación del servidor Apache se recomienda al usuario emplear la utilidad

conocida como XAMPP, cuyo uso e instalación se explica en puntos posteriores.

III.1.2.- Base de datos MySQL

La base de datos que emplea el sistema así como todas las interacciones que se realizan

con ella se producen empleado el lenguaje SQL. Por ello además se recomienda al

usuario el empleo de MySQL como administrador de la base de datos. Además, aunque

no es necesario para el usuario final, pero sí para el administrador, se recomienda el uso

de la aplicación PHPMyAdmin para facilitar la gestión de la base de datos de la

plataforma.


Las versiones recomendadas de estas utilidades son las siguientes:

MySQL

MySQL/5.6.16; PHPMyAdmin/4.1.6

Se recomienda la instalación de MySQL y PHPMyAdmin conjuntamente con la

utilidad XAMPP en la que vienen integradas. La instalación de XAMPP se especifica a

continuación.

III.1.3.- XAMPP

Para la instalación y configuración adecuada del servido Apache local así como de

MySQL, y para un manejo más sencillo y directo de los mismos se recomienda el uso

de la utilidad XAMPP.

XAMPP integra en una consola única ejecución del servidor Apache, así como de

MySQL. Su instalación es bastante sencilla siguiendo los siguientes pasos:

1. Ejecute el Instalador de XAMPP con permisos de Administrador. Para ello pulse

con el botón derecho sobre él y seleccione Ejecutar como Administrador.

2. Seleccione los componentes que desee instala. Tenga en cuenta cuales son los

necesarios para el buen funcionamiento de la plataforma. Se recomienda instalar

todos los componentes.


3. Seleccione la carpeta donde desea instalar XAMPP.

4. Una vez finalizado el proceso ya tiene XAMPP y todos los componentes

necesarios para trabajar con la aplicación de forma correcta.

La versión recomendada de esta utilidad es la siguiente:

XAMPP

XAMPP (Win32)/1.8.3


III.2.- Instalación de la Plataforma

Por favor, para la instalación y puesta en marcha de la plataforma sigue estrictamente

los siguientes pasos. Tenga en cuenta que deberá tener previamente instaladas las

utilidades especificadas en el punto III.1.

1. Descomprima el archivo PlataformaInvB.rar en un directorio cualquiera

2. Una vez descomprimido, deberá copiar la carpeta Bolsa dentro de la carpeta

htdocs, que se encuentra en el directorio raíz de su instalación de XAMPP. Así,

por ejemplo, si XAMPP ha sido instalado en C:/xampp, la carpeta htdocs se

encuentra en C:/xampp/htdocs.

No modifique el contenido de la carpeta bolsa o, de lo contrario, la aplicación

podría no funcionar adecuadamente.

3. Cuando haya finalizado la copia de la carpeta Bolsa diríjase al directorio raíz de

la instalación de XAMPP. Allí ejecute una aplicación denominada

Xampp-Control. De esta forma abrirá el panel de control de XAMPP.

4. En el panel de control de XAMPP existen multitud de opciones que pueden ser

seleccionada, cumpliendo cada una de ellas un propósito distinto.

Para la correcta ejecución de la plataforma solo es necesario que active el

servidor Apache local de XAMPP y MySQL. Para ello pulse sobre los botones

Start de ambas opciones, como se muestra en la imagen inferior.

Una vez activadas estas utilidades verá sus nombres en el panel de control de

XAMPP resaltados en verde.

5. Antes de inicializar la plataforma deberá cargar la base de datos que respalda la

misma. Para ello abra cualquier explorador de internet y escriba localhost en la

barra de direcciones y pulse enter para acceder al directorio de gestión de

XAMPP.


6. Verá en su explorador una pantalla como la siguiente.

Seleccione en la sección Tools, abajo a la izquierda, la opción phpMyAdmin.

7. Una vez en la utilidad de gestión de bases de datos MySQL via web conocida

como phpMyAdmin verá una pantalla como la siguiente.

Seleccione la opción Importar en el menú superior.

8. Dentro de la pantalla de importación que se le mostrará seleccione la opción

Seleccionar Archivo, tal y como se ve en la imagen inferior.

.


9. Seleccione el archivo Bolsa_BD.sql, que se encuentra en el directorio don haya

descomprimido el archivo PlataformaInvB.rar. Una vez cargado pulse en

continuar.

10. Una vez se haya cargado la base de datos en MySQL ya podrá hacer uso de la

plataforma de manera norma. Para ello escriba en la barra de direcciones del

explorador localhost/bolsa.

Nota Importante: Cada vez que haga uso de la plataforma deberá tener activado el

servidor Apache local y MySQL. Puede hacerlo siguiendo las instrucciones del punto

4 del presente apartado.


III.3.- Acceso a la Plataforma

Como es lógico carece de sentido en cualquier plataforma de esta naturaleza permitir el

acceso de usuarios sin unas credenciales que asocien al mismo con una cuenta

determinada y por tanto con una cartera de valores. Es por ello que ninguna

funcionalidad de la aplicación es accesible careciendo de un nombre de usuario y

contraseña de acceso.

Por ello, tras la pantalla de bienvenida, se le solicitan al usuario dichas credenciales

para autorizar su acceso a la plataforma. En la imagen siguiente puede verse dicha

solicitud de nombre de usuario y contraseña dentro de la aplicación creada.

Puede verse también en la siguiente imagen que el sistema no permite al usuario no

logeado el acceso a ninguna funcionalidad disponible en el menú superior de la

aplicación, mostrándole a su vez un mensaje de error en el caso de que, pese a ello, lo

intente.


III.4.- Perfil del usuario

Una vez el usuario ha introducido su nombre de usuario y contraseña, accediendo con

éxito a la aplicación, esta le redirige automáticamente a la sección denominada "Mi

Perfil". En esta sección se concentran todas las funcionalidades que permiten al usuario

llevar un control de su cartera, incluyendo la posibilidad de vender aquellos valores que

ya posea.

Dentro de la sección "Mi Perfil" se incluyen las sub-secciones "Cartera", "Histórico" y

"Órdenes", incluyendo también la sub-sección "Histórico" otra de "Histórico de

Órdenes". Se describirá en el presente apartado el funcionamiento y estructura de cada

una de ellas.

III.4.1.- Cartera:

En la sub-sección "Cartera" el usuario puede ver el valor actual de su cartera, calculado

a partir de la liquidez que posee y del valor total en el momento de los distintos títulos

que formen parte de la misma. A su vez le es posible conocer la liquidez actual con la

que cuenta y las variaciones diarias, mensuales y anuales que ha experimentado su

cartera de valores.

En la siguiente imagen se ve como muestra la aplicación dichos datos al usuario.

Cabe señalar que la cartera mostrada en la imagen superior partía con un capital

disponible de un millón de euros y que durante el tiempo que ha estado operativa ha ido

variando su valor debido a las fluctuaciones de los precios de los valores con los que

cuenta. La aplicación ha calculado automáticamente y de forma periódica la variación

experimentada en los distintos periodos, facilitándole al usuario dicha información.

Por otro lado el usuario puede ver en la misma sección "Cartera" los valores que la

integran y que adquirió cada uno en su momento. Siempre, después de la compra de una


cierta cantidad de títulos de una compañía, el sistema lo agrega automáticamente a la

cartera del usuario y se lo muestra en su perfil siempre que los conserve.

Los valores que integran la cartera del usuario tomado como ejemplo se muestran en la

captura siguiente.

A su vez desde esta sección se pueden vender las acciones que posee el usuario, total o

parcialmente, poner órdenes de venta de las mismas e incluso visionar gráficas de ellos.

III.4.2.- Órdenes:

En la sub-sección de "Órdenes" perteneciente a la sección "Mi Perfil" es posible

administrar las órdenes que el usuario tenga almacenadas en el sistema y que aún no se

hayan ejecutado por no haberse cumplido los requisitos fijados por el mismo.


Como puede verse el propio usuario puede cancelar una orden eliminándola del sistema

a voluntad. Téngase en cuenta que para aquellos casos en los que las órdenes se ejecuten

o caduquen el sistema los eliminan de la base datos no apareciendo ya en esta sección.

III.4.3.- Histórico:

En la sub-sección "Histórico" se almacenan los datos de todas, sin excepción, las

operaciones que haya realizado el usuario directamente y las que haya realizado el

sistema mediante la ejecución de órdenes, de manera automática, bajo las condiciones

establecidas por el usuario en el momento de la creación de la orden.

Por otro lado dentro de esta sección existe también la sub-sección "Histórico de

Órdenes", donde se guardan los reportes de ejecución, caducidad o no ejecución de las

órdenes creadas por el usuario. De esta forma se le permite al mismo tener un

conocimiento total de lo que ha acontecido en su cartera de valores entre sesiones.


III.5.- Trading

La sección principal para operar dentro de la plataforma es la sección "Trading". En

dicha sección es posible buscar y consultar cualquier valor disponible para operar en la

plataforma y a su vez realizar compras de acciones a mercado o poner órdenes de

compra para que el sistema las ejecute cuando se cumplan los requisitos establecidos.

Del mismo modo es posible acceder a las gráficas de cualquier valor al igual que es

posible hacerlo en la sección "Mi Perfil".

III.5.1.- Utilidades de Compra y Venta:

Una vez el usuario ha decidido que valor comprar o cuál de los que ya tiene en cartera

va a vender a mercado pulsará sobre el botón correspondiente bien desde la sección de

"Trading" si es para realizar una compra o desde la sección de "Cartera" si es para una

venta. Una vez realizada esta acción el sistema le redirigirá a la correspondiente

plataforma de compra o venta.

III.5.1.a.- Utilidad de Compra:

En la utilidad de compra el usuario solo tiene opción de establecer el número de

acciones que desea adquirir al precio actual. Evidentemente el sistema limita este

número de acciones a comprar de acuerdo con la liquidez disponible del usuario.


Una vez se accede a la utilidad de compra el propio sistema migra todos los datos del

valor escogido y rellena la utilidad con los mismos, los cuales no son modificables por

el usuario.

III.5.1.b.- Utilidad de Venta:

La utilidad de venta de la plataforma es prácticamente igual a la de compra, pudiendo

el usuario exclusivamente establecer el número de acciones a vender. Estando estas, en

este caso, limitadas por la cantidad de acciones con las que el usuario cuenta en cartera.

III.5.2.- Utilidad de Órdenes:

Tal y como ocurre con las utilidades de compra venta, las utilidades de creación de

órdenes tanto de compra como de venta son prácticamente idénticas, salvo por el hecho

de que en el caso de las órdenes de venta el usuario debe elegir entre una orden "STOP

LOSS", empleada para limitar pérdidas, o una orden "LIMITADA", empleada para

recoger beneficios.


Por lo demás, en ambas utilidades es necesario especificar un precio objetivo y, de

manera opcional, una fecha de ejecución, fecha en la que se ejecutará la orden con

independencia de cuál sea el precio en ese momento, y una fecha de caducidad. Siendo

esta última la fecha límite para la ejecución de la orden, eliminándose la misma una

superado el plazo.

III.5.3.- Utilidad de Gráficas:

La utilidad de gráficas es posiblemente la más compleja de toda la plataforma, dado la

multitud de posibilidades que ofrece. En dicha utilidad el usuario puede pre-configurar

la gráfica del valor que desea visualizar, seleccionando el horizonte temporal, el tipo de

gráfica, el tamaño y añadiendo casi cualquier indicador financiero disponible para un

valor.

Una vez realizada la configuración previa el sistema le muestra la gráfica al usuario

cumpliendo con sus requisitos.


La plataforma muestra la gráfica que el usuario ha configurado.

En la imagen la gráfica de una compañía configurada por el usuario para que los

indicadores se muestren en forma de vela y a la que le ha añadido un indicador técnico

denominado "ROC".


III.6.- Administración

La aplicación incluye una sección oculta donde se pueden administrar los usuarios. El

sistema restringe el acceso a esta área solo a aquellos usuarios con permisos de

administrador, mostrándole un menú diferente a aquellos que carecen de los mismos.

Como puede verse, en el menú restringido para el administrador se muestra también la

sección "Gestión", desde la cual el administrado puede añadir nuevos usuarios o

eliminarlos.

III.6.1.- Gestión:

En la sección "Gestión" se ofrece el

menú de la imagen al administrador,

donde puede seleccionar entre añadir o

eliminar usuarios.

III.6.2.- Utilidad de Creación de Usuarios:

En la utilidad para la creación de un nuevo usuario el administrado debe introducir

todos los datos fundamentales para el sistema para poder registrar al nuevo usuario. El

único dato de relevancia que le viene impuesto es el número de identificación del nuevo

usuario, que es calculado por el sistema de manera autónoma en función del número de

usuarios registrados.


III.6.3.- Eliminación de Usuarios:

La sección de eliminación de usuarios presenta en una tabla todos los usuarios dados de

alta en el sistema, junto con sus datos. El administrador puede seleccionar el usuario

que desee y eliminarlo de la base de datos, denegando así su acceso a la aplicación.

Una vez se ha eliminado a un usuario determinado el sistema lanza un mensaje de

confirmación.


CAPÍTULO IV: CONCLUSIONES


IV.1.- Conclusión

Como se desprende del contenido de esta memoria y del funcionamiento de la

plataforma desarrollada, no se ha buscado la realización de una plataforma plenamente

funcional apta para operar en el mercado de valores o, al menos, preparada para una

adaptación a ello. Esto, evidentemente, se alejaba en mucho del objetivo del proyecto y

requeriría muchísimo más tiempo de trabajo y desarrollo que el que es lógico emplear

para la elaboración de un proyecto fin de carrera. Sin ser esto óbice para que haya sido

necesario dedicar un considerable tiempo y esfuerzo en la elaboración de la plataforma

tal cual está.

No obstante, la plataforma desarrollada sí que presenta un buen punto de partida para la

construcción de una plataforma más amplia que, eventualmente, pudiera ser empleada

para operaciones en el Mercado de Valores. Pudiendo ser utilizada como estructura base

sobre la que empezar a desarrollar funcionalidades extras y capacidades de conexión

con los proveedores de servicio bursátiles que, por lo general, son servicios ofrecidos

por bancos, y que suelen requerir altas medidas de seguridad.

El principal objetivo de la plataforma de inversión desarrollada ha sido desde un primer

momento el de simular los aspectos principales del funcionamiento de una plataforma

de inversión real. Además, ha sido un objetivo autoimpuesto que fuera funcional hasta

el punto de poder servir como herramienta de ensayo de operaciones bursátiles o incluso

como herramienta de seguimiento de posiciones en el Mercado de Valores.

Gracias a este enfoque fue posible establecer los objetivos, en cuanto a capacidades

funcionales se refiere, que se fijaron para la plataforma. De tal manera que, aparte de la

funcionalidad básica de compra y venta de valores, la plataforma cuenta con otras que

consiguen, precisamente, ese objetivo marcado de conseguir una plataforma que sirviera

como herramienta de entrenamiento y de seguimiento de operaciones en el mercado. Es

el caso de la capacidad para crear órdenes, por ejemplo.

Mención aparte merece la otra gran funcionalidad que ha permitido, conjuntamente con

la creación de órdenes, el que la plataforma alcance el objetivo de ser una herramienta

útil para el inversor principiante. La posibilidad de visionar gráficas de valores.

Esta funcionalidad, no cabe duda, permite al usuario no solo hacer un buen seguimiento

de la situación de las inversiones, sino también poder estudiar sus inversiones futuras

dentro de la propia plataforma en la que las va a realizar. Lo que le da aún más entidad

de herramienta a la plataforma.

Es lógico pensar que si la plataforma es válida como herramienta de entrenamiento o

apoyo para el inversor principiante, incluso para algunos más experimentados, pueda ser

también una buena herramienta educativa o formativa para absolutos desconocedores de

las operaciones en el Mercado de Valores.


Sin duda alguna, vista como herramienta formativa, podría ser útil tanto como un

primer paso para empezar a conocer la dinámica básica de cómo se realizan las

inversiones bursátiles, así como primera toma de contacto con el funcionamiento del

Mercado de Valores para aquellos que aún lo desconocen casi todo sobre este.

No se pretende de ninguna manera considerar la plataforma desarrollada como una

herramienta completa, ni tan siquiera como una herramienta que alcance un ámbito más

allá del puramente académico, comparable siquiera a alguna de las que se puedan

adquirir en la actualidad. Sin embargo si se quiere hacer especial énfasis sobre el

potencial que, en mi humilde opinión, alberga.

Evidentemente muchas de las funcionalidades que podrían ser consideradas, quizás no

como básicas, pero si como muy convenientes han quedado fuera de la plataforma. Lo

que no implica que no puedan ser implementadas sobre la misma estructura ya creada,

lo cual era también un punto importante a lograr en el desarrollo. Es decir, no solo se ha

pretendido que la plataforma sirva como herramienta, sea funcional o simule con

realismo las condiciones de operación normales en el mercado, sino también establecer

un punto de partida, una buena base, para construir una futura plataforma más compleja,

con más funciones, capacidades y que atienda otras necesidades de los inversores.

Son muchas las características de la aplicación y las del proceso de desarrollo seguido

que brindan la posibilidad al desarrollador inquieto, que en un futuro quiera mejorarla o

ampliarla, el hacerlo fácilmente. La propia arquitectura MVC facilita el desarrollo

modular de la aplicación, de tal manera que es posible ir añadiéndole nuevos módulos,

que en definitiva son nuevas funcionalidades, sin alterar lo más mínimo el núcleo

fundamental de la aplicación original.

Queda claro, a poco que se conozca con relativa profundidad el funcionamiento del

Mercado de Valores, que funcionalidades tales como la operación en el mercado de

divisas, el uso de productos derivados o algo tan aparentemente simple como las alertas

de precios son elementos que deberían ser incluidos en una versión ampliada de la

actual plataforma.

Consecuentemente, cuantas más funcionalidades complejas se le añadan a la

aplicación, más importante será tener un buen proveedor de datos, ya que el actual, para

según qué funciones dejaría de ser lo óptimo que es para la plataforma en su estado

actual.


BIBLIOGRAFÍA


Libros

Cibelli, Christian. PHP: programación web para profesionales. Barcelona:

Marcombo, 2012. ISBN 9788426718389.

Holzner, Steven. PHP: the complete reference. New York: McGraw-Hill, cop.

2008. ISBN 9780071508544.

Boronczyk, Timothy. Desarrollo web con PHP 6, Apache y MySQL. Madrid:

Anaya Multimedia, cop. 2010. ISBN 9788441526228.

Recursos electrónicos

The PHP Group. Manual PHP. https://php.net/manual/es/index.php.

Yii Software LLC. YII: Documentation. http://www.yiiframework.com/doc/.

Yahoo! Inc. Yahoo Developer Network. https://developer.yahoo.com/yql/.

Plataformas de Inversión y Brokers

DIF Broker. DIF Freedom. http://www.difbroker.es/.

Plus 500UK Ltd. Plus 500. http://www.plus500.es/.

Interactive Brokers LLC. Trader Workstation (TWS).

https://www.interactivebrokers.com/

Proyecto Fin de Carrera - Universidad de...

Documents

Transcript of Proyecto Fin de Carrera - Universidad de...