RESUMEN DEL PROYECTO

Tamaño: px
Comenzar la demostración a partir de la página:

Download "RESUMEN DEL PROYECTO"

Transcripción

1 RESUMEN DEL PROYECTO El proyecto Stock Market Game agrupa tres conceptos muy interesantes para cualquier persona interesada en los mercados financieros. Por un lado, se trata de una plataforma ficticia de inversión donde el usuario puede poner a prueba sus conocimientos o competir contra otros usuarios. Por otro lado, recopila la información necesaria para proporcionar todas las herramientas necesarias de inversión (cotizaciones intradía, gráficos e información de indicadores y osciladores charlistas). Además, ofrece al usuario una plataforma de ayuda de inversión, indicando el momento de realizar sus operaciones. El sistema permitirá a los usuarios registrados de forma ficticia invertir sobre los valores del IBEX35. En Stock Market Game los usuarios podrán realizar órdenes de compra y venta, tanto a precio de mercado como con precios limitados o condicionados. El sistema deberá interactuar con aplicaciones de terceros para incorporar las cotizaciones al sistema, con ellas el sistema creará unas gráficas estadísticas y calculará diversos indicadores del análisis técnico bursátil para ayudar a los usuarios en sus inversiones. Las noticias bursátiles se han incorporado al sistema a través del RSS de Para la realización del proyecto Stock Market Game, se han definido unos osciladores propios del sistema que son necesarios para crear el módulo de ayuda a la inversión. Este módulo se ha construido como un sistema experto basado en reglas de producción que transmitirá al usuario recomendaciones sobre la toma de posiciones para el día siguiente. La plataforma web se ha desarrollado como un juego que incluye características típicas de los juegos online masivos como son la incorporación de ligas, donde se puede competir entre varios usuarios para ser el mejor inversor. Por otra parte existe en el sistema una clasificación con los mejores inversores. Para su desarrollo se ha utilizado la metodología UML con algunas modificaciones para poder incluir dentro de cada fase la plataforma web y la aplicación batch que obtiene los datos de las cotizaciones, crea las gráficas y al final del día analiza los I

2 valores para dar recomendaciones. Entre las modificaciones figuran la incorporación de DFDs y diagramas de flujo al proceso de diseño de la aplicación batch. Las tecnologías utilizadas para la realización del proyecto han sido JavaEE para la plataforma web, siguiendo el patrón MVC (Modelo-Vista-Controlador). Para la vista, se ha incorporado tecnología AJAX combinada con JSPs para mejorar la apariencia y seguir el modelo de WEB 2.0. La aplicación batch se ha desarrollado usando JavaSE, incorporando el FrameWork de JFreeChart para la realización de gráficas. El sistema experto está basado en reglas de producción y la aplicación de terceros elegida para suministrar las cotizaciones está formada por archivos.csv alojados en los servidores de Yahoo Financial. La base de datos es de tipo relacional, está gestionada por MySQL y es el nexo de unión entre las dos aplicaciones. II

3 ABSTRACT Stock Market Game involves three different and really interesting concepts to anyone interested in financial markets. On one hand, Stock Market Game is a web platform where users can fictitiously invest to test their knowledge or compete with other users. On the other hand, it receives all needed information to give the user all kinds of investment tools (daily prices, charts and indicators). The system, gives the user a investment-help platform, indicating when should de user buy or sell. The system will allow registered users to buy and sell stocks in three different ways, current price, limited price and price conditions. The system needs to communicate with a third party application to receive the stock s price during the open market and the historical log files of each company in the IBEX35. The system creates graphics charts and calculates different technical analysis concepts such as the RSI or momentum to identify trends in the stocks and help users to find the best investment. Financial news are brought by the RSS file from Several indexes and oscillators have been created especially for Stock Market Game, which will help to build the investments advice module. This module is a knowledge system, based on production rules that will give the users advices on the different next day stocks. The web platform has been built as a game, with some typical characteristics of the multi-masive online games, such as leagues where users can compete between them to sort out who is the best investor. The game creates a classification of the best investors registered in the server. The Methodology chosen to develop the project is UML, modified by adding DFD and flow diagrams of the batch application that incorporates the charts module, stock price receiving and the knowledge system. The technologies used for the project have been JavaEE for the web platform, implementing a MVC (Model-View-Controller) pattern. AJAX technology has been incorporated into the view combined with Java Server Pages to improve the traditional static web pages, following the WEB 2.0 standard. III

4 The batch applications has been built using JavaSE using JFreeChart FrameWork for creating the charts. The knowledge System is based on production rules. The third party application chosen to provide the stock s price have been.csv files hosted in the yahoo financial servers. The relational database is managed by MySQL server and unifies both applications by using the database tables to transfer data between them. IV

5 Índice 1. Introducción Identificación de necesidades Análisis de requisitos Modelo conceptual de la aplicación web Casos de uso del sistema Modelo de dominio Interfaz inicial del sistema Modelo conceptual de datos Requisitos de la aplicación batch Lista de requisitos Diagrama de contexto de la aplicación batch Diseño del sistema Arquitectura del sistema Diagramas de secuencia Diseño detallado Diseño de la aplicación web Estructura de la aplicación Diagrama de paquetes Diagramas de clase Diseño de la base de datos Diagrama de la base de datos Diseño físico de la base de datos Diseño de la aplicación batch DFD de primer nivel Diagramas de flujo Programación AJAX con DWR FrameWork JFreeChart Java EE y Java SE El Sistema Experto de Análisis Técnico El análisis técnico Los osciladores de SMG El sistema experto V

6 7.4 Resultados El simulador Presupuesto Conclusiones Futuras Mejoras Planificación Bibliografía Anexo I. Manual de instalación Anexo II. Manual de usuario VI

7 Introducción 1

8 1. Introducción El propósito del proyecto es crear una aplicación web que funcione como un juego y cuya temática sea la bolsa española, más concretamente el IBEX35. La necesidad de esta aplicación viene dada por no existir simuladores de inversión en la bolsa española. Se ha decidido desarrollar la aplicación como si fuera un juego para atraer a usuarios sin conocimientos del funcionamiento de la bolsa a parte de los expertos. El hecho de que puedan practicar sus habilidades de inversión sin apostar su dinero, atraerá a más usuarios. El propósito del juego es introducir a los usuarios en el mundo de la bolsa, el análisis técnico puede ser muy aburrido pero si se muestra como un juego, los usuarios irán adquiriendo experiencia poco a poco de forma divertida. La aplicación deberá mostrar estadísticas del intradía e históricas, permitir lanzar órdenes de compra o venta con condiciones. Reflejar la competición en una clasificación. Los datos de las cotizaciones, deben ser datos reales del IBEX35, por lo tanto se ha creado una aplicación batch capaz de recibir los datos de las cotizaciones y los históricos de los valores para más tarde introducirlos en la base de datos. Por último, se ha desarrollado un módulo de ayuda a la inversión que dará recomendaciones diarias sobre cada uno de los valores. Dicho módulo se ha incorporado a la aplicación batch. 2

9 Quedando el sistema como se ve a continuación: La aplicación batch, obtendrá las cotizaciones de Yahoo, creará las estadísticas y a final del día dará recomendaciones sobre los valores del mercado. La aplicación web incorporará las noticias del RSS de y se desarrollará con JavaEE y con contenido dinámico proporcionado por AJAX Para la realización del proyecto se ha elegido la metodología UML cuyos pasos se van a relatar en los siguientes apartados. 3

10 Identificación de necesidades 4

11 2. Identificación de necesidades En esta fase del desarrollo se ha realizado un análisis de los requerimientos del sistema, sus objetivos, normas a seguir, tecnologías a utilizar, todos estos requerimientos se describen en el documento de conceptos del sistema que figura a continuación. El documento de conceptos del sistema se divide en 4 partes: Objetivos del sistema. En este apartado se relatan los objetivos más generales del sistema en una descripción clara y escueta pero que debe definir claramente la finalidad del sistema, estos objetivos se describen desde una perspectiva empresarial. Alcance del sistema. El alcance describe todas las funcionalidades que debe tener el sistema, detallando todas ellas lo mejor posible ya que es el punto de partida para realizar el sistema. Tipología de los usuarios finales. En este apartado se describe el perfil de los usuarios finales, de tal manera que el interfaz pueda ser lo más apropiado posible para los usuarios finales. Restricciones. Tal como su nombre indica, las restricciones son todos aquellos factores que puedan afectar al desarrollo del sistema, las restricciones pueden ser de tipo económico, tecnológico, logístico o de cualquier otro tipo. 5

12 DOCUMENTO DE CONCEPTOS DEL SISTEMA 1. OBJETIVOS DEL SISTEMA El sistema consiste en el desarrollo de un juego de bolsa sobre una plataforma web en el que los usuarios podrán invertir de forma ficticia sobre los valores del IBEX35. El sistema deberá realizarse como un juego y tendrá en cuenta tanto a usuarios avanzados en la inversión como a aquellos que nunca hayan invertido. Para obtener los datos de las cotizaciones el sistema deberá ser capaz de interactuar con aplicaciones de terceros. El juego dispondrá de la opción de crear y participar ligas, para que los usuarios puedan competir por ser el mejor inversor dentro de su liga además de la competición global. Habrá un sistema de mensajería con el cual los usuarios podrán comunicarse con los demás jugadores. El sistema contará adicionalmente con un módulo de ayuda a la inversión que utilizará diversos indicadores del análisis técnico para realizar estimaciones de cuáles serán los mejores valores en los que invertir. 6

13 DOCUMENTO DE CONCEPTOS DEL SISTEMA 2. ALCANCE DEL SISTEMA La aplicación debe permitir invertir de la forma más real posible, los datos de las cotizaciones deben obtenerse periódicamente para que la experiencia de la inversión sea lo más realista posible. Se dispondrá de un sistema de ayuda a la inversión que usará osciladores e indicadores del análisis técnico para dar recomendaciones para el día siguiente. El módulo de estadísticas tendrá la información del intradía e histórica. El sistema, se realizará como un juego, habrá una competición con una clasificación de los mejores inversores además de la opción de pertenecer a una liga, en la que los jugadores podrán realizar una competición entre los usuarios que se apunten a la liga. Los usuarios podrán comunicarse entre ellos con un sistema de mensajería, que deberá ser lo más simple posible para no interferir en la mecánica del juego. El sistema dispondrá de un manejo simple e intuitivo de la cartera de valores del usuario, permitiendo compras y ventas tanto a precio de mercado como con precio limitado o condicionado. Habrá una sección en el sistema en la que se podrán visualizar las últimas noticias del mundo financiero proporcionadas por terceros. 7

14 DOCUMENTO DE CONCEPTOS DEL SISTEMA 3. TIPOLOGÍA DE LOS USUARIOS El tipo de usuario del sistema será un inversor en bolsa, tanto si tiene altos conocimientos sobre el mundo financiero como si acaba de empezar en el y no se atreve a invertir su dinero. Perfiles: Usuario: El usuario del sistema tiene que ser capaz de invertir, mandar mensajes y de apuntarse a cualquier liga que el desee. Administrador de la liga: El administrador de la liga será un usuario cualquiera que haya creado una liga podrá aceptar usuarios en su liga, expulsarlos o borrar la liga. DOCUMENTO DE CONCEPTOS DEL SISTEMA 4. RESTRICCIONES Restricción temporal: El sistema deberá estar completo antes de la convocatoria de septiembre de Restricción de recursos El sistema se desarrollará con Java y deberá contener elementos del WEB 2.0 que es como se denomina a las aplicaciones web de contenido dinámico. 8

15 Análisis de requisitos 9

16 3. Análisis de requisitos El análisis de requisitos consiste en la creación de un modelo conceptual del sistema que satisfaga todos los requisitos, para ello, esta etapa del desarrollo se divide en varias actividades técnicas. Para el desarrollo de la plataforma web, se realizarán las siguientes actividades definidas por la metodología UML: Identificar los casos de Uso del Sistema. Dar detalle de los casos de uso descritos. Dar una interfaz inicial al sistema. Desarrollar el modelo de dominio. Como la metodología elegida para el desarrollo no es la más apropiada para las aplicaciones secuenciales como la aplicación batch que recogerá los datos de las cotizaciones y los analizará, la fase de análisis de requisitos añadirá una actividad extra para la aplicación batch que será: Lista de requisitos para la aplicación batch. Por último, en esta fase se va a realizar el modelo conceptual de datos que representa las entidades con sus atributos y las relaciones existentes entre ellas. Esta primera visión técnica del sistema, se encarga de dar una perspectiva de qué funcionalidades debe tener el sistema sin entrar a definir cómo debe realizarlas. 10

17 3.1 Modelo conceptual de la aplicación web Casos de uso del sistema. Los casos de uso permiten recoger y documentar los requerimientos funcionales de un sistema, para su realización se necesita primeramente identificarlos y posteriormente realizar una descripción detallada de cada caso de uso. Un caso de uso permite recoger y documentar un requerimiento funcional del sistema y su forma de interactuar con el usuario. Para identificarlos y representarlos se utilizan los diagramas de casos de uso en los que se representa a los actores y sus relaciones con el sistema y otros actores. Un actor puede ser cualquier persona, organización o sistema que sea externo al sistema que se está analizando y que además interactúa de alguna manera con él. Un actor, más que un ente concreto es un rol abstracto que representa la forma de interactuar con el sistema. Un caso de uso responde a un objetivo de un actor con respecto al sistema y es una unidad funcional completa. Un ejemplo puede ser un inversor que quiere comprar valores de una empresa, el caso de uso comprendería todas los pasos que necesitaría el usuario para conseguir su fin. 11

18 Diagramas de casos de uso del sistema. Los diagramas de casos de uso son una representación gráfica del caso de uso, representa gráficamente la relación entre el actor principal el sistema. Para nuestro sistema, además nos va a servir para identificar los casos de uso. A continuación figura un gráfico explicativo de las figuras que pueden aparecer en los diagramas de casos de uso. Caso 1 Caso de uso relacionado con el actor principal Actor principal Relación 12

19 13

20 Descripción de los casos de uso. La descripción de los casos de uso se ha realizado rellenando una plantilla que se explica a continuación, la plantilla tiene diferentes secciones: Título: Da nombre al caso de uso, debe ser claro, conciso y auto explicativo. Actor primario: Es aquel cuyo objetivo da nombre al caso de uso, normalmente es también el que lo inicia aunque no siempre es así. Actor secundario: Cualquier otro actor que intervenga en el caso de uso y que ayude al sistema a conseguir el objetivo del actor primario. Trigger: Es el evento que inicia el caso de uso, a veces precede al primer paso del caso de uso, mientras que otras veces es el primer caso. Precondiciones: Son condiciones que se han de dar para que pueda iniciarse el caso de uso y como se han de cumplir antes, no se vuelven a comprobar una vez iniciado el caso de uso, pueden ser una o varias, pero todas ellas han de cumplirse. Escenario Primario: Se describe mediante una serie de pasos numerados, cada paso consistirá en una frase activa en tiempo presente, cada paso puede ser únicamente de los siguientes tipos: o Una interacción entre sistema y actor o actores. o Una validación de cierta información recibida o de una regla de negocio. o Un cambio de estado lógico del sistema. Extensiones: Describen escenarios alternativos al escenario primario, todas las alternativas deben ser activadas por una condición detectable por el sistema. Descripción de datos: En esta sección se desglosan los datos que son referidos en el escenario principal. Reglas de negocio: Son reglas externas al sistema. 14

21 Caso de Uso: Alta Usuario Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción Precondiciones: Escenario principal: 1. El usuario accede al sistema El Sistema le muestra la página de Inicio. 2. El usuario selecciona crear cuenta. 3. El sistema muestra un formulario a rellenar. 4. El usuario introduce los datos de la nueva cuenta. 5. El sistema registra el nuevo usuario Extensiones: 6a. El sistema comprueba que el nick del socio ya existía. 1. El sistema notifica al usuario del fallo y se vuelve al punto 2. 6b. El sistema comprueba que los datos introducidos son erróneos. 2. El sistema notifica al usuario de los errores en el formulario y se vuelve al punto 4. Descripción de Datos: Formulario: Nick Contraseña Comprobación de la contraseña Nombre Apellidos . Reglas de Negocio: 15

22 Caso de Uso: Conectar a cuenta Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción Precondiciones: Escenario principal: 1. El usuario selecciona la opción de conectarse al sistema de la página de inicio. 2. El sistema muestra al usuario la página de login. 3. El usuario introduce el nick y la contraseña. 4. El sistema comprueba que el nick y la contraseña concuerdan. 5. El sistema muestra la página principal. Extensiones: 4a. El sistema comprueba que el nick y la contraseña no existen. 1. El sistema notifica al usuario del fallo y se vuelve al punto 2. 4b. El sistema comprueba que no existe un usuario con ese nick. 1. El sistema notifica al usuario y el sistema muestra la página de inicio. Descripción de Datos: Reglas de Negocio: 16

23 Caso de Uso: Crear Liga Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado. Escenario principal: 1. El usuario selecciona en su página principal la opción de crear liga 2. El sistema le muestra un formulario de creación de liga. 3. El usuario introduce los datos de la nueva liga. 4. El sistema comprueba los datos de la liga y le da de alta. Extensiones: 4a. El sistema comprueba que los datos del formulario no son válidos. 1. El sistema notifica al usuario de los errores en el formulario y se vuelve al punto 4. Descripción de Datos: formulario de creación de liga: Nombre Descripción. Tag. Reglas de Negocio: 17

24 Caso de Uso: Petición de alta en una liga Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado. Escenario principal: 1. El usuario selecciona la opción de darse de alta en una liga 2. El sistema muestra el formulario para darse de alta. 3. El usuario introduce los datos de alta. 4. El sistema envía la petición de alta al administrador de la liga. Extensiones: Descripción de Datos: formulario de alta en liga: Tag. Descripcion Reglas de Negocio: 18

25 Caso de Uso: Ver participantes de la liga Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado. El usuario pertenece a una liga. Escenario principal: 1. El usuario selecciona ver la sección de ligas. 2. El sistema muestra la información de las ligas a las que pertenece. 3. El usuario selecciona ver una liga específica. 4. El sistema le muestra los datos de la liga. Extensiones: Descripción de Datos: Datos de la liga: Componentes. Clasificación de cada componente. Descripción de la liga. Administrador de la liga. Reglas de Negocio: 19

26 Caso de Uso: Alta de jugador en la liga Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado. El usuario es Administrador de la liga. Hay una petición de alta en la liga. Escenario principal: 1. El usuario selecciona ver la sección de ligas. 2. El sistema muestra la información de la liga a la que pertenece. 3. El sistema le muestra los datos de la liga y los datos de administrador de la liga. 4. El usuario selecciona ver las peticiones de entrada. 5. El sistema muestra las peticiones de entrada en la liga. 6. El usuario selecciona aceptar petición. 7. El sistema da de alta al jugador que hizo la petición en la liga. Extensiones: 6a. El usuario selecciona rechazar la petición. 1. El sistema borra el mensaje de petición. Descripción de Datos: Datos de la liga: Componentes. Clasificación de cada componente. Descripción de la liga. Administrador de la liga. Datos de administrador de la liga: Peticiones pendientes. Reglas de Negocio: 20

27 Caso de Uso: Baja de jugador en la liga Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado. El usuario es Administrador de la liga. Escenario principal: 1. El usuario selecciona ver la sección de ligas. 2. El sistema muestra la información de la liga a la que pertenece. 3. El sistema le muestra los datos de la liga y los datos de administrador de la liga. 4. El usuario selecciona expulsar al jugador de la liga. 5. El sistema da de baja al jugador seleccionado. Extensiones: Descripción de Datos: Datos de la liga: Componentes. Clasificación de cada componente. Descripción de la liga. Administrador de la liga. Datos de administrador de la liga: Peticiones pendientes. Reglas de Negocio: 21

28 Caso de Uso: Abandonar la liga. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado. El usuario pertenece a una liga. El usuario no es el administrador de la liga Escenario principal: 1. El usuario selecciona ver la sección de ligas. 2. El sistema muestra la información de la liga a la que pertenece 3. El sistema le muestra los datos de la liga 4. El usuario selecciona la opción abandonar liga y además el usuario no es el administrador de la liga. 5. El sistema borra al jugador de la liga. Extensiones: Descripción de Datos: Datos de la liga: Componentes. Clasificación de cada componente. Descripción de la liga. Administrador de la liga. Reglas de Negocio: 22

29 Caso de Uso: Comprar valores a precio de mercado. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver las cotizaciones del día. 2. El sistema muestra al usuario el menú de cotizaciones. 3. El usuario selecciona comprar un valor. 4. El sistema muestra los datos del valor y un formulario de compra. 5. El usuario introduce el número de acciones que desea comprar. 6. El sistema comprueba que el usuario tiene suficiente cash para realizar la transacción. 7. El sistema registra la orden de compra. Extensiones: 6a. El sistema comprueba que el usuario no tiene suficiente cash para realizar la transacción. 1. El sistema registra una orden de compra con el máximo posible de valores a comprar. Descripción de Datos: Cotizaciones actuales: Abreviatura del nombre de la compañía. Precio actual de la cotización. Máximo Mínimo Apertura. Incremento. Volumen. Formulario de compra: Cantidad a comprar 23

30 Reglas de Negocio: (RN001): Las compras no se ejecutan directamente, se ejecutarán cuando el sistema que obtiene los datos de las cotizaciones haga su próxima actualización. (RN002): Las compras a precio de mercado consisten en comprar X cantidad de acciones de un mismo valor al precio que se obtenga en la próxima ejecución del sistema que obtiene los datos de los valores. 24

31 Caso de Uso: Comprar valores a precio limitado Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver las cotizaciones del día. 2. El sistema muestra al usuario el menú de cotizaciones. 3. El usuario selecciona comprar un valor. 4. El sistema muestra los datos del valor y un formulario de compra. 5. El usuario introduce el número de acciones que desea comprar y el limite. 6. El sistema comprueba que el usuario tiene suficiente cash para realizar la transacción. 7. El sistema registra la orden de compra. Extensiones: 6a. El sistema comprueba que el usuario no tiene suficiente cash para realizar la transacción. 1. El sistema registra una orden de compra con el máximo posible de valores a comprar. Descripción de Datos: Cotizaciones actuales: Abreviatura del nombre de la compañía. Precio actual de la cotización. Máximo Mínimo Apertura. Incremento. Volumen Formulario de compra: Cantidad a comprar Límite de la compra. 25

32 Reglas de Negocio: (RN001): Las compras no se ejecutan directamente, se ejecutarán cuando el sistema que obtiene los datos de las cotizaciones haga su próxima actualización. (RN003): Las compras a precio Limitado consisten en comprar X cantidad de acciones de un mismo valor cuando el precio del valor se sitúe por debajo del precio marcado por el límite. 26

33 Caso de Uso: Comprar valores a precio condicionado Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver las cotizaciones del día. 2. El sistema muestra al usuario el menú de cotizaciones. 3. El usuario selecciona comprar un valor. 4. El sistema muestra los datos del valor y un formulario de compra. 5. El usuario introduce el número de acciones que desea comprar y la condición. 6. El sistema comprueba que el usuario tiene suficiente cash para realizar la transacción. 7. El sistema registra la orden de compra. Extensiones: 6a. El sistema comprueba que el usuario no tiene suficiente cash para realizar la transacción. 1. El sistema registra una orden de compra con el máximo posible de valores a comprar. Descripción de Datos: Cotizaciones actuales: Abreviatura del nombre de la compañía. Precio actual de la cotización. Máximo Mínimo Apertura. Incremento. Volumen Formulario de compra: Cantidad a comprar Condición de la compra. 27

34 Reglas de Negocio: (RN001): Las compras no se ejecutan directamente, se ejecutarán cuando el sistema que obtiene los datos de las cotizaciones haga su próxima actualización. (RN004): Las compras a precio Condicionado consisten en comprar X cantidad de acciones de un mismo valor cuando el precio del valor se sitúe por encima del precio marcado por el límite. 28

35 Caso de Uso: Vender valores a precio de mercado. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver cartera. 2. El sistema muestra al usuario el menú de cartera. 3. El usuario selecciona vender un valor. 4. El sistema muestra un formulario de venta. 5. El usuario introduce la cantidad a vender. 6. El sistema registra la orden de venta. Extensiones: Descripción de Datos: Valores de cartera: Abreviatura del nombre de la compañía. Precio actual de la cotización. Incremento. Precio de compra Inversión Inversión actual Beneficio Cantidad de valores Formulario de venta: Cantidad a vender. Reglas de Negocio: (RN005): Las ventas no se ejecutan directamente, se ejecutarán cuando el sistema que obtiene los datos de las cotizaciones haga su próxima actualización. 29

36 Caso de Uso: Vender valores con limite. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver cartera. 2. El sistema muestra al usuario el menú de cartera. 3. El usuario selecciona vender un valor. 4. El sistema muestra un formulario de venta. 5. El usuario introduce la cantidad a vender y el límite de la venta. 6. El sistema registra la orden de venta. Extensiones: Descripción de Datos: Valores de cartera: Abreviatura del nombre de la compañía. Precio actual de la cotización. Incremento. Precio de compra Inversión Inversión actual Beneficio Cantidad de valores Formulario de venta: Cantidad a vender. Límite de la venta. Reglas de Negocio: (RN005): Las ventas no se ejecutan directamente, se ejecutarán cuando el sistema que obtiene los datos de las cotizaciones haga su próxima actualización. (RN006): Las ventas Limitadas consisten en vender acciones de un mismo valor cuando el precio se sitúe por encima del precio marcado por el límite. 30

37 Caso de Uso: Vender valores condicionados. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver cartera. 2. El sistema muestra al usuario el menú de cartera. 3. El usuario selecciona vender un valor. 4. El sistema muestra un formulario de venta. 5. El usuario introduce la cantidad a vender y la condición de la venta. 6. El sistema registra la orden de venta. Extensiones: Descripción de Datos: Valores de cartera: Abreviatura del nombre de la compañía. Precio actual de la cotización. Incremento. Precio de compra Inversión Inversión actual Beneficio Cantidad de valores Formulario de venta: Cantidad a vender. Condició de la venta. Reglas de Negocio: (RN005): Las ventas no se ejecutan directamente, se ejecutarán cuando el sistema que obtiene los datos de las cotizaciones haga su próxima actualización. (RN007): Las ventas condicionadas consisten en vender un valor cuando el precio se sitúe por encima del precio marcado en la condición. 31

38 Caso de Uso: Ver Cartera de valores. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver cartera. 2. El sistema muestra al usuario el menú con los valores de la cartera. Extensiones: Descripción de Datos: Valores de cartera: Abreviatura del nombre de la compañía. Precio actual de la cotización. Incremento. Precio de compra Inversión Inversión actual Beneficio Cantidad de valores Reglas de Negocio: 32

39 Caso de Uso: Ver cotizaciones. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver valores. 2. El sistema muestra las cotizaciones actuales. Extensiones: Descripción de Datos: Cotizaciones actuales: Abreviatura del nombre de la compañía. Precio actual de la cotización. Máximo Mínimo Apertura. Incremento. Volumen Reglas de Negocio: 33

40 Caso de Uso: Ver top 5 jugadores. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver los mejores jugadores. 2. El sistema muestra los datos de los 5 mejores. Extensiones: Descripción de Datos: Datos de los 5 mejores: Nick. Valor total de la cartera. Valor total de la cartera: Valor de las acciones de la cartera + cash disponible. Reglas de Negocio: 34

41 Caso de Uso: Ver buzón. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona la opción del buzón. 2. El sistema le muestra los últimos mensajes y un formulario para enviar mensajes. Extensiones: Descripción de Datos: Mensaje: Remitente. Día y hora. Mensaje escrito Formulario: Tag. Texto. Reglas de Negocio: 35

42 Caso de Uso: Mandar Mensaje Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona la opción del buzón. 2. El sistema le muestra los últimos mensajes y un formulario para enviar mensajes. 3. El usuario rellena el mensaje e introduce el tag del destinatario y envía el mensaje. 4. El sistema envía el mensaje al buzón del destinatario. Extensiones: 4a. El sistema no identifica el tag del destinatario. 1. El sistema notifica del error al usuario. Descripción de Datos: Mensaje: Remitente. Día y hora. Mensaje escrito Formulario: Tag. Texto. Reglas de Negocio: 36

43 Caso de Uso: Borrar mensaje. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona la opción del buzón. 2. El sistema le muestra los últimos mensajes. 3. El usuario selecciona un mensaje selecciona borrar. 4. El sistema borra el mensaje. Extensiones: 4a. El sistema no identifica el tag del destinatario. 2. El sistema notifica del error al usuario. Descripción de Datos: Mensaje: Remitente. Día y hora. Mensaje escrito Reglas de Negocio: 37

44 Caso de Uso: Ver los valores que más ganan. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver los valores que mas ganan 2. El sistema muestra los datos de los 5 mejores valores. Extensiones: Descripción de Datos: Datos de los 5 mejores: Ticker. Incremeto en % y en. Reglas de Negocio: Caso de Uso: Ver los valores que más pierden. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver los valores que más pierden. 2. El sistema muestra los datos de los 5 peores valores. Extensiones: Descripción de Datos: Datos de los 5 peores: Ticker. Incremeto en % y en. Reglas de Negocio: 38

45 Caso de Uso: Ver los valores más recomendados. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver los valores más recomendados 2. El sistema muestra los datos de los 5 valores más recomendados. Extensiones: Descripción de Datos: Datos de las recomendaciones de los valores: Ticker. Recomendación. Reglas de Negocio: Caso de Uso: Ver los valores menos recomendados. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver los valores más recomendados 2. El sistema muestra los datos de los 5 valores menos recomendados. Extensiones: Descripción de Datos: Datos de las recomendaciones de los valores: Ticker. Recomendación. Reglas de Negocio: 39

46 Caso de Uso: Ver las noticias. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver las noticias. 2. El sistema muestra las últimas noticias. Extensiones: Descripción de Datos: Noticias Titulo con enlace. Resumen de la noticia. Reglas de Negocio: Caso de Uso: Ver los links interesantes. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver los links interesantes. 2. El sistema muestra los links a las páginas interesantes. Extensiones: Descripción de Datos: Reglas de Negocio: 40

47 Caso de Uso: Ver la información sobre la pagina. Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver la información. 2. El sistema muestra la información. Extensiones: Descripción de Datos: Reglas de Negocio: Caso de Uso: Ver las recomendaciones Actor Principal: Usuario Actor Secundario: Trigger: El usuario inicia la transacción. Precondiciones: El usuario está conectado Escenario principal: 1. El usuario selecciona ver las recomendaciones. 2. El sistema muestra los datos de las recomendaciones. Extensiones: Descripción de Datos: Datos de las recomendaciones de los valores: Ticker. Datos de osciladores. Reglas de Negocio: 41

48 3.1.2 Modelo de dominio. El modelo de dominio es un diagrama de la metodología UML que muestra los conceptos básicos del dominio del problema, sus propiedades más importantes y las relaciones existentes entre ellos. El modelo de dominio obliga a los desarrolladores y usuarios a pensar formalmente sobre el problema para intentar reflejar la realidad sobre un diagrama. Este reflejo de la realidad, permite a los desarrolladores validar su comprensión del problema a tratar. Para realizar el modelo de dominio, se ha utilizado una perspectiva conceptual, que pretende reflejar lo más fielmente posible el problema, sus conceptos, las propiedades de los conceptos y sus relaciones. El modelo de dominio no es una solución, es una perspectiva del problema. En el diagrama del modelo de dominio existen varios conceptos que se explican a continuación para una correcta interpretación del diagrama, estos conceptos son: Clases: Las clases representan conceptos existentes en el dominio del problema, estos conceptos suelen tener información asociada y relaciones entre ellos, por ejemplo cosas físicas como una empresa o conceptos lógicos como son una operación de compra. Su representación suele ser una caja, en la que el nombre de la caja está en la parte superior y los atributos debajo. Esta es la clase Empresa, con los atributos nombre y ticker, ambos son de tipo String. 42

49 Atributos: Los atributos representan información relevante asociado a los conceptos del dominio, es decir, las clases. Suelen ir acompañadas del prototipo del atributo: String Boolean Int Muchos otros como doublé, float, Date Relaciones: Representan las asociaciones entre las clases del dominio, tienen diversos atributos: Nombre: Puede ser cualquiera, pero explicativo, como alumnos que pertenecen a un grupo, etc. Cardinalidad: Indica el numero de instancias como mínimo y como máximo que pueden participar en la asociación con una instancia. Clase A Nombre de asociacion 1 0..* Clase B Existen diferentes tipos de relaciones, pero en el caso que nos ocupa, tan solo se han necesitado 2: Composición: Una clase puede estar compuesta por otras clases, por ejemplo, un libro puede tener varios capítulos. La composición se representa con una flecha con un rombo en el lado del origen. Asociación: Es la relación de interacción entre 2 clases. Se representa con una línea recta. 43

50 Diagrama del modelo de dominio 44

51 Glosario de clases En el glosario de clases se explican las clases expuestas en el modelo de dominio haciendo una breve descripción de cada una de ellas. Clase Descripción Usuario Mensajes Liga Acción Orden Esta clase representa al usuario de Stock Market Game Los mensajes forman el buzón del usuario, son todos aquellos mensajes que ha recibido por parte de otros usuarios. La liga es un concepto, es una pequeña competición entre unos usuarios determinados que son miembros de la liga. El conjunto de las acciones forman la cartera del usuario, son las acciones que posee y que puede comprar o vender a través de las órdenes. Una orden representa una transacción, es la compra o venta de una acción que aún no se ha completado, ya sea porque no se cumplen las condiciones o simplemente porque no se ha ejecutado. Hay diversos tipos de ordenes: Órdenes de compra a precio de mercado. Órdenes de compra a precio limitado. Órdenes de compra a precio condicionado. Órdenes de venta a precio de mercado. Órdenes de venta a precio limitado. Órdenes de venta a precio condicionado. El atributo tipo es el que marca qué tipo de orden es. Empresa Clase que representa a cada una de las empresas que son parte de IBEX35. 45

52 Cotización Análisis Una cotización son los datos de una empresa en un momento determinado, es decir, el precio al que está cotizando, su variación, etc. Un análisis son todas las operaciones de análisis técnico que se hacen un día sobre una empresa. Además también contendrá los valores obtenidos de los osciladores creados por SMG. 46

53 3.1.3 Interfaz inicial del sistema Es el último paso del análisis de requisitos para la aplicación web, en ella se ha definido como será el interfaz inicial que tendrá el sistema, además de dar una aproximación de cómo será estéticamente. Lo primero que se realizó fue un boceto con DreamWeaver de cuál sería el aspecto de la página, quedando como se ve a continuación. Pantalla Principal Tal como se puede ver en la imagen, el diseño consta de varias partes, 2 barras de navegación, sobre las que se podrá acceder a las partes principales del sistema y la parte central en la que se mostrará el contenido de la información solicitada. El diseño es muy simple e intuitivo dejando todas las unidades funcionales accesibles rápidamente. Por cada caso de uso podrán existir uno o varios archivos.jsp que rellenarán el contenido de la página. Los principales apartados accesibles desde la barra de navegación, será la visualización de la cartera, las cotizaciones actuales, las ordenes pendientes de ejecución, noticias e información, además de todo lo referente a las ligas y el buzón. 47

54 Formularios En la parte del contenido de la página existirán los formularios para la toma de datos, como pueda ser para darse de alta en el sistema o enviar mensajes a los demás jugadores. Mandar Mensaje El formato del formulario es muy simple con un textbox para rellenar con el nombre de usuario del destinatario y debajo un textarea con el texto del mensaje. Es bastante intuitivo, el usuario solo tiene que rellenar los campos y hacer click sobre el botón de enviar. El resto de formularios de los que dispondrá el sistema será muy parecido tal y como se puede ver en algunos ejemplos que figuran a continuación. 48

55 Crear Liga Los diseños se han intentado realizar los más simples posibles, evitando radiobuttons e intentando mostrar la máxima información. Este formulario es el que se muestra cuando un usuario que no pertenece a una liga quiere crear la suya propia, en el pondrá el tag de la liga (es una abreviatura o un seudónimo del nombre), el nombre y por último una descripción del propósito de la liga. 49

56 Alta Liga Tal como indican los casos de uso, antes de pertenecer a una liga, hay que mandar una petición al administrador de la liga, para eso existe este formulario. Este formulario se envía como un mensaje de petición de alta en la liga, la única diferencia entre un mensaje a un usuario y este formulario, es que en vez de el nombre de usuario se usa el tag de la liga como destinatario. El resto de formularios seguirán este mismo tipo de formato, quedando sujetos en su apariencia a la hoja de estilos que se elija definitivamente. Con este apartado se acaba el análisis de requisitos de la aplicación web, quedando concretados los casos de uso, el modelo de dominio y el interfaz inicial del sistema. 50

57 3.2 Modelo conceptual de datos. El modelo conceptual de datos describe las características principales de los datos del sistema. Al igual que el modelo de dominio, el modelo conceptual de datos, consta de 2 partes, un esquema gráfico y una especificación en la que se describen cada uno de los componentes del esquema. En el modelo conceptual de datos se describe las entidades, atributos y relaciones de interés para el negocio a representar. Este modelo debe ser independiente del hardware y software utilizado para el manejo de los datos. El modelo que se ha elegido para la representación es el desarrollado por P.Chen en 1976 bautizado como Análisis entidad-relación. En el existen los siguientes conceptos: Entidad: Son objetos que tienen una existencia propia. Es aquello de interés duradero para la empresa, sobre lo cual se pueden almacenar datos e identificar de un modo único. Relaciones: Representación de asociaciones entre entidades. Las relaciones establecen el grado de asociación entre 2 estructuras de datos diferentes. Atributos: Datos elementales, son características o propiedades de una entidad que sirven para definir, describir y clasificar. Los atributos. Estos son los símbolos que se usarán para realizar el modelo entidad relación: Entidad Relación 51

58 Las cardinalidades de las relaciones se representarán como: 0,1: Relación de 0 ó *: Relación de 0 ó muchos. 1..*: Relación de 1 o muchos. Un ejemplo rápido de la nomenclatura sería este: En él se ve, que la entidad usuario tiene una relación con la entidad stocks, esa relación es de tipo posee, con una cardinalidad de 1 en usuario y de 0 a muchos en Stocks, lo cual se traduce en que 1 usuario posee muchos o ningún stock. Así mismo, un stock no puede pertenecer más que a 1 solo usuario. Una vez explicado el modelo se van a representar todas las relaciones del sistema. En esta relación un usuario puede pertenecer a una liga o no. Pero todas las ligas tienen que tener al menos un miembro. 52

59 Cada stock del sistema es de una empresa en concreto, pero no hay un límite de stocks por cada empresa. Combinando esta relación con la de stocks-usuarios, se puede observar como un usuario tiene stocks que son de 1 empresa. De cada empresa, el sistema hará un análisis al día, es por eso que las empresas tienen varios análisis. Cada análisis es de 1 empresa únicamente. La entidad cotización representa el precio al que cotiza una empresa en un momento dado, tal y como se ha explicado anteriormente. Es por eso que a lo largo del día y del año hay varias cotizaciones por cada empresa. Las ligas son creadas por el líder de la liga y cada liga sólo tiene un líder que es el usuario que la creó. 53

60 En la relación entre la entidad mensaje y usuario hay 2 opciones. En un mensaje un usuario puede ser el origen del mensaje o puede ser el destinatario. Sin embargo cada usuario puede mandar o recibir varios mensajes. Cuando un usuario quiere comprar o vender un stock, lanza una orden. Es decir, cada usuario puede tener varias órdenes, pero cada orden pertenece a un usuario únicamente. En la relación anterior se puede ver como un usuario lanzaba órdenes de compra, las ordenes, son sobre una empresa específica. Cada empresa puede sufrir varias órdenes de compra o venta en un momento dado. 54

61 En los siguientes diagramas se han agrupado todas las relaciones entorno a las 2 entidades que más relaciones tienen, para de esta manera tener una visión global del sistema En el diagrama se puede ver como de una misma empresa pueden existir al mismo tiempo varios análisis, stocks, cotizaciones y órdenes. 55

62 El modelo queda completado con este diagrama en el que se pueden observar las relaciones del usuario con el resto de entidades, que tienen coherencia con las funcionalidades descritas en los casos de uso. Ambos diagramas se pueden unir entre las relaciones existentes entre usuariosordenes-empresas o usuarios-stocks-empresas dando lugar al diagrama entidad relación final del sistema. 56

63 3.3 Requisitos de la aplicación batch Lista de requisitos. Se ha elaborado una lista de requisitos que debe cumplir la aplicación batch para el correcto funcionamiento del sistema completo. Tal como se ha descrito en la identificación de necesidades, la funcionalidad principal de la aplicación batch es la de recoger las cotizaciones de los valores y analizarlos. Título: Horario del mercado Identificador: R01 Descripción: El sistema debe funcionar de lunes a viernes mientras esté abierto el mercado, de 09:00 a 18:00 Horario GMT+1. Medición: Los datos se deben recoger entre el horario mencionado ya que es el horario de apertura de la bolsa española. Beneficio: Sin este requisito la aplicación no podría obtener los datos del intradía y el sistema no tendría sentido. 57

64 Título: Frecuencia de muestreo Identificador: R02 Descripción: Este requisito describe la frecuencia con la que se debe recoger los datos de las cotizaciones durante el horario de mercado Medición: Los datos se deben recoger cada 3 minutos aproximadamente, para tener una referencia clara de los cambios rápidos del mercado. Beneficio: Una frecuencia muy alta de muestreo podría perder cambios bruscos en la cotización, mientras que una demasiado baja podría saturar las conexiones con la base de datos. Requisitos relacionados: R01 Título: Estadísticas Identificador: R03 Descripción: Este requisito describe las estadísticas que debe mostrar el sistema. Medición: Las estadísticas que debe recoger el sistema y representarlas son las de los precios de las cotizaciones de los últimos días y las del intradía. Beneficio: Las gráficas muestran más información que muchos otros datos, una aplicación de bolsa sin estadísticas no estaría completa. 58

65 Título: Análisis técnico Identificador: R04 Descripción: Este requisito describe los tipos de análisis que debe realizar el sistema sobre las cotizaciones. Medición: El análisis técnico describe muchos análisis y osciladores calculables para interpretar los movimientos del mercado. En este sistema se pretende utilizar los más comunes y mas informativos como: RSI, Media móvil, Estocástico y Momentum. Beneficio: Para desarrollar el módulo de ayuda a la inversión es necesario contar con las herramientas del análisis chartista. Título: Histórico Identificador: R05 Descripción: Este requisito describe los datos que debe recibir el sistema Medición: Para calcular osciladores e indicadores, además de las estadísticas es necesario obtener un histórico de las cotizaciones. Se debe obtener los datos del último año siempre que sea posible obtenerlas. Beneficio: Con estos datos se podrán realizar las estadísticas y los análisis. Requisitos relacionados: R03, R04. 59

66 3.3.2 Diagrama de contexto de la aplicación batch Para realizar el modelo lógico se ha utilizado un DFD (diagrama de flujo de datos), para representar el comportamiento de la aplicación. Los símbolos del DFD son los siguientes: Proceso Flujo de datos Entidad externa Almacén de datos Diagrama de contexto Yahoo Ficheros Históricos Cotizaciones Stock Market Game 60

67 Diseño del Sistema 61

68 4. Diseño del sistema 4.1 Arquitectura del sistema La arquitectura elegida para la realización de la aplicación web es el modelo vista controlador (MVC) definido por la enciclopedia online wikipedia como: Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón MVC se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página, el controlador es el Sistema de Gestión de Base de Datos y el modelo es el modelo de datos. Modelo: Esta es la representación específica de la información con la cual el sistema opera. La lógica de datos asegura la integridad de estos y permite derivar nuevos datos; por ejemplo, no permitiendo comprar un número de unidades negativo, calculando si hoy es el cumpleaños del usuario o los totales, impuestos o portes en un carrito de la compra. Vista: Este presenta el modelo en un formato adecuado para interactuar, usualmente la interfaz de usuario. Controlador: Este responde a eventos, usualmente acciones del usuario e invoca cambios en el modelo y probablemente en la vista. Muchos sistemas informáticos utilizan un Sistema de Gestión de Base de Datos para gestionar los datos. En MVC corresponde al controlador. Aunque se pueden encontrar diferentes implementaciones de MVC, el flujo que sigue el control generalmente es el siguiente: 1. El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace) 2. El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback. 3. El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión. 62

69 4. El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se refleja los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, el patrón de observador puede ser utilizado para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista. 5. La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente. Para el modelo MVC se ha elegido una implementación basada en JavaEE. Modelo: El modelo se controla a través de los DAOs (Data Access Control) para el acceso a los datos, que son clases java que acceden a la base de datos y transmiten al controlador los datos solicitados. Controlador: El controlador lo llevan los Servicios, que controlan todo el flujo de datos y realizan todas las funcionalidades del sistema, los DAOs existen únicamente para acceder a los datos, el encargado de operar con ellos son los servicios. Para la recepción de eventos se utilizan los Servlets que ceden el control a los servicios. 63

70 Vista: La vista la generan los JSPs (Java Server Pages) generando un código HTML interpretable por cualquier navegador. Para la implementación de características de WEB 2.0 en la vista, se ha elegido AJAX (Asynchronous JavaScript and XML) para generar contenido dinámico en las páginas generadas por el sistema. AJAX permite cambiar contenidos o mostrar nuevos contenidos en una página web sin necesidad de recargar la página, esto se realiza a través de eventos generados por el navegador en el ordenador del cliente sin que él se entere. Estos eventos son generados por códigos javascript que se ejecutan cuando el usuario provoca un evento, ya sea haciendo click en algún botón, pasando por encima de secciones de una página, que genera una petición asíncrona a un Servlet. Para más información sobre la tecnología AJAX consulta el apartado 6 de este mismo documento (Tecnología AJAX y el Framework DWR). 64

71 4.2 Diagramas de secuencia. Una vez elegida la implementación para el sistema, se realizan los diagramas de secuencia para los casos de uso. Los diagramas de secuencia son un tipo de diagramas de interacción. Estos diagramas representan las interacciones, que consisten en el intercambio de mensajes entre un conjunto de objetos con un propósito específico. Los diagramas de secuencia hacen énfasis en la secuencia temporal de los mensajes enviados. A continuación se va a mostrar unos diagramas de secuencia que representan todos los intercambios de mensajes necesarios para ejecutar un caso de uso: Caso de uso: Comprar valores a precio limitado : Recordemos los pasos del caso de uso: 1. El usuario selecciona ver las cotizaciones del día. 2. El sistema muestra al usuario el menú de cotizaciones. 3. El usuario selecciona comprar un valor. 4. El sistema muestra los datos del valor y un formulario de compra. 5. El usuario introduce el número de acciones que desea comprar y el límite. 6. El sistema comprueba que el usuario tiene suficiente cash para realizar la transacción. 7. El sistema registra la orden de compra. 65

72 El usuario selecciona en el menú de cotizaciones comprar un valor, que en este caso es ACS pulsando el botón comprar. Este botón genera una petición al servlet ComprarTipoServlet. El servlet, cede el control a ComprarTipo.jsp, que muestra un formulario de compra, tal y como se relata en el caso de uso. 66

73 El usuario introduce el número de acciones y el límite para la compra, presiona el botón comprar. El servlet ComprarLimitadaServlet, recibe la petición de compra, que cede el control al ServicioComprar, que introduce la orden de compra en la base de datos a través de OrdenDAO. Por último se cede el control a ordenes.jsp que muestra la página con las ordenes del usuario. 67

74 Estas son las interacciones necesarias para realizar el caso de uso, como se puede ver, la lógica de negocio está en los servicios, el Servlet le proporciona los datos de la petición para que genere las órdenes de compra, el Servicio comprueba que el usuario tiene suficientes fondos sin usar y delega en ordendao para que inserte en la base de datos la orden de compra. El resto de casos de uso se realizan de la misma manera, la lógica de negocio en los servicios, la vista en los jsp y la recepción de eventos en los servlets. 68

75 Diagrama de secuencia de una petición asíncrona: En este diagrama se muestra un ejemplo de cómo funciona una petición asíncrona de AJAX usando el frameworkdwr. En este caso, la petición consiste en refrescar los datos del usuario, sus órdenes, stocks y fondos actuales. El navegador, genera una petición asíncrona forzada por un javascript. Dicha petición llega al servlet proporcionado por DWR, que recibe la petición asíncrona, cediendo la petición al servicio que en este caso se llama Cotizar. Este servicio, recibe todas las peticiones asíncronas existentes y las gestiona. En este caso, el servicio Cotizar necesita todos los datos del usuario, llamando al ServicioUsuario que casualmente tiene un método para recopilar toda la información e usuario. ServicioUsuario, llama a UsuarioDAO que crea una instancia de Usuario y se la devuelve a Servicio Usuario que a su vez se la pasa a Cotizar, que introduce en la sesión el usuario recibido. Como el navegador sólo entiende código HTML, cotizar ejecuta usuario.jsp para generar un String con el código y devolvérselo a través del servlet DWR al navegador. 69

76 Diseño Detallado 70

77 5. Diseño detallado En esta fase del desarrollo, se realiza la última fase del proceso de diseño, en esta fase, se agregan los detalles de implementación del modelo del mundo y se desarrollan los modelos de control persistencia y comunicaciones. El diseño detallado se va a dividir en 3 partes, referentes a: Aplicación web: En esta fase, se realizarán los diagramas de clases y paquetes en los que se describirán todos los atributos y métodos necesarios en cada clase y la comunicación entre los paquetes. También se definirá como se ha de estructurar la aplicación, sus carpetas y subcarpetas, el código fuente y todo lo necesario para que funcione la aplicación. Aplicación Batch: Para la aplicación batch se realizarán los DFDs de primer nivel y los diagramas de flujo de cada uno de los procesos. La base de datos: Para la base de datos, se realizará un diagrama con el diseño final y las sentencias sql necesarias para crear las tablas. Esta última fase del diseño, precede directamente a la programación, por lo tanto tiene que dejar claros todos los detalles de diseño del sistema. 71

78 5.1 Diseño de la aplicación web Estructura de la aplicación. La aplicación web se estructurará de la siguiente manera: Carpetas: Src: Esta carpeta contendrá los paquetes con el código fuente de los DAOs, objetos del dominio, los servlets y los servicios. Etc: Contendrá el código sql necesario para crear la base de datos. META-INF: contendrá en context.xml y el manifest. Web: Dentro de esta carpeta se ubican todos los archivos accesibles desde el navegador. Cada subcarpeta contiene un tipo de archivo, los htmls, las imágenes, los javascripts, las paginas jsp y las hojas de estilo. WEB-INF: Contiene el web.xml, el dwr.xml y las librerías necesarias. 72

79 5.1.2 Diagrama de paquetes. Los paquetes se utilizan para descomponer el sistema en partes más pequeñas y manejables. Un paquete puede agrupar cualquier tipo de elementos, en nuestra aplicación, cada paquete agrupará clases relacionadas entre sí. En el diagrama de paquetes, cada paquete se muestra como un rectángulo con una solapa, las flechas indican qué paquetes pueden acceder a los demás paquetes. El diagrama de paquetes es en realidad un diagrama de clases especial donde se muestran los paquetes. Todos los paquetes pueden acceder a los objetos del dominio y son los servicios los que pueden acceder a los DAOs, los servlets, incluidos en el paquete iu, acceden a los servicios y al paquete de domino. 73

80 5.1.3 Diagramas de clase. Los diagramas de clase, especifican los atributos, métodos y relaciones entre las clases de un mismo paquete. La sintaxis de un atributo es la siguiente: [Visibilidad]nombre[:tipo] La visibilidad puede ser: Public: Private: Representado por un cubo rojo Protected: El tipo ser refiere al tipo de atributo que es, si es una clase Usuario por ejemplo, o un String. Las relaciones se representan igual que en el modelo de dominio, tanto de composición como de relación. Las primeras representadas como una flecha con un rombo en el origen y las segundas como una flecha simple o doble dependiendo de su navegabilidad. 74

81 Diagrama de clase del paquete iu 75

82 En este diagrama se ven todas las clases del paquete iu, que contiene los servlets, todos con sus métodos doget y dopost. 76

83 Diagrama de clase del paquete DAO 77

84 Diagrama de clase del paquete Servicios 78

85 Diagrama de clase del paquete Dominio 79

86 5.2 Diseño de la base de datos Diagrama de la base de datos Después de realizar el diagrama entidad relación, el siguiente paso es transformarlo en el diseño de una base de datos, quedando como se puede ver en la figura siguiente. 80

87 5.2.2 Diseño físico de la base de datos Por último, se ha desarrollado el diseño físico de la base de datos, con todos sus atributos, claves extranjeras. Este modelo se representa mediante el lenguaje de descripción de datos o DLL, con las siguientes tablas: Tabla Empresas CREATE TABLE `empresas` ( `idempresa` int(11) NOT NULL auto_increment, `nombre` varchar(20) NOT NULL, `tiker` varchar(5) NOT NULL, PRIMARY KEY (`idempresa`) ) Tabla Análisis CREATE TABLE `analisis` ( `idanalisis` int(11) NOT NULL auto_increment, `idempresa` int(11) NOT NULL, `mediamovil` double NOT NULL, `rsi` double NOT NULL, `momentum` double NOT NULL, `estocasticod` double NOT NULL, `estocasticok` double NOT NULL, `volatilidad` double NOT NULL, `subidalibre` int(11) NOT NULL, `stoploss` int(11) NOT NULL, `osciladorvuelta` int(11) NOT NULL, `fecha` date NOT NULL, `osciladorsmg` double(6,2) NOT NULL, PRIMARY KEY (`idanalisis`) ) 81

88 Tabla Usuarios CREATE TABLE `usuarios` ( `idusuario` int(11) NOT NULL auto_increment, `nombre` varchar(20) NOT NULL, `apellidos` varchar(20) NOT NULL, ` ` varchar(40) NOT NULL, `login` varchar(20) NOT NULL, `pass` varchar(20) NOT NULL, `fondos` double(10,2) NOT NULL, `idliga` int(11) default NULL, PRIMARY KEY (`idusuario`) ) Tabla Ligas CREATE TABLE `ligas` ( `idliga` int(11) NOT NULL auto_increment, `nombre` varchar(20) NOT NULL, `descripcion` varchar(250) NOT NULL, `tag` varchar(20) NOT NULL, `idusuario` int(11) NOT NULL, PRIMARY KEY (`idliga`), KEY `FK_idUSuario_Lider` (`idusuario`), CONSTRAINT `FK_idUSuario_Lider` FOREIGN KEY (`idusuario`) REFERENCES `usuarios` (`idusuario`) ) ALTER TABLE usuarios ADD CONSTRAINT FK_idLigaPertenece FOREIGN KEY (`idliga`) REFERENCES `ligas` (`idliga`); 82

89 Tabla Mensajes CREATE TABLE `mensajes` ( `idmensaje` int(11) NOT NULL auto_increment, `idusuarioori` int(11) NOT NULL, `idusuariodest` int(11) NOT NULL, `texto` varchar(250) NOT NULL, `fecha` date NOT NULL, `peticion` int(11) NOT NULL, PRIMARY KEY (`idmensaje`), KEY `FK_idUsuarioOri` (`idusuarioori`), KEY `FK_idUsuarioDest` (`idusuariodest`), CONSTRAINT `FK_idUsuarioDest` FOREIGN KEY (`idusuariodest`) REFERENCES `usuarios` (`idusuario`), CONSTRAINT `FK_idUsuarioOri` FOREIGN KEY (`idusuarioori`) REFERENCES `usuarios` (`idusuario`) ) Tabla Stocks CREATE TABLE `stocks` ( `idstock` int(11) NOT NULL auto_increment, `idusuario` int(11) NOT NULL, `idempresa` int(11) NOT NULL, `titulos` int(11) NOT NULL, `preciocompra` double(6,2) NOT NULL, PRIMARY KEY (`idstock`), KEY `FK_idEmpresaSt` (`idempresa`), KEY `FK_idUsuarioSt` (`idusuario`), CONSTRAINT `FK_idEmpresa_st` FOREIGN KEY (`idempresa`) REFERENCES `empresas` (`idempresa`), CONSTRAINT `FK_idUsuario_st` FOREIGN KEY (`idusuario`) REFERENCES `usuarios` (`idusuario`) ) 83

90 Tabla Ordenes CREATE TABLE `ordenes` ( `idorden` int(11) NOT NULL auto_increment, `idusuario` int(11) NOT NULL, `idempresa` int(11) NOT NULL, `tipo` int(11) NOT NULL, `cantidad` int(11) NOT NULL, `condicion` decimal(6,2) NOT NULL, PRIMARY KEY (`idorden`), KEY `FK_idUsuario_ord` (`idusuario`), KEY `FK_idEmpresa_ord` (`idempresa`), CONSTRAINT `FK_idEmpresaOrd` FOREIGN KEY (`idempresa`) REFERENCES `empresas` (`idempresa`), CONSTRAINT `FK_idUsuarioOrd` FOREIGN KEY (`idusuario`) REFERENCES `usuarios` (`idusuario`) ) Tabla Cotizaciones CREATE TABLE `cotizaciones` ( `idcotizacion` int(11) NOT NULL auto_increment, `idempresa` int(11) NOT NULL, `precio` double(6,2) NOT NULL, `fecha` date NOT NULL, `hora` varchar(20) NOT NULL, `variacion` double(6,2) NOT NULL, `max` double(6,2) NOT NULL, `min` double(6,2) NOT NULL, `apertura` double(6,2) NOT NULL, `volumen` int(11) NOT NULL, PRIMARY KEY (`idcotizacion`), KEY `FK_idEmpresa_cot` (`idempresa`), CONSTRAINT `FK_idEmpresa_cot` FOREIGN KEY (`idempresa`) REFERENCES `empresas` (`idempresa`) ) 84

91 5.3 Diseño de la aplicación batch Para realizar el diseño de la aplicación batch, primeramente se ha realizado un diagrama de flujo de datos de primer nivel de la aplicación. Los símbolos utilizados, son los mismos que se han explicado a la hora de realizar el diagrama de contexto en el análisis de requisitos. Primero se han identificado los procesos: Main: Este proceso se encarga de gestionar la ejecución de los demás procesos, coordina la ejecución de todos, debe ejecutar la obtención de cotizaciones en el horario de mercado, arrancar el histórico al iniciar el sistema y ejecutar el sistema experto al final del día. Histórico: El sistema necesita datos históricos de las cotizaciones para iniciar su funcionamiento, este proceso se encarga de la obtención de dichos históricos. Obtener cotizaciones: Como su nombre indica, este proceso se encarga de ir recibiendo las cotizaciones del día según llegan. Sistema experto, análisis técnico y el simulador: Este proceso se tratará en el punto 7 de este mismo documento por ser un apartado fundamental en el desarrollo del proyecto y necesitando una explicación más exhaustiva. 85

92 5.3.1 DFD de primer nivel. Los flujos de datos se pueden ver claramente en el diagrama, los diversos procesos se comunican entre sí usando el almacén de datos. Con este diagrama se tiene un diseño de cómo funcionan los flujos de datos entre los diversos procesos. Los datos de los ficheros históricos y las cotizaciones vienen de la página de yahoo finanzas. La aplicación web, aunque no aparece en el DFD por no ser parte de la aplicación batch, también usa el mismo almacén de datos. 86

93 5.3.2 Diagramas de flujo Al ser estos programas de una naturaleza lineal, los diagramas que más se ajustan a su comportamiento son los más tradicionales tal y como son los diagramas de flujo. En este apartado se van a representar los diagramas de flujo de cada uno de los programas y sus funcionalidades. Se pueden observar los siguientes símbolos en los diagramas de flujo. Flechas: Representan el orden de ejecución de cada una de las funciones, cuando una operación termina, se pasa a la siguiente a través de una de las flechas. Rectángulos: Son operaciones que ejecuta el proceso, las operaciones aquí presentadas son a alto nivel y conllevan muchas instrucciones de ejecución. Rombos: Son decisiones que pueden desembocar en varios caminos según sea la decisión que se tome. Una sentencia if que desemboque en 2 hilos de ejecución totalmente diferentes puede ser una decisión. 87

94 Main En el diagrama, se puede observar como el hilo de ejecución del programa no acaba nunca. El horario de mercado está marcado por los requisitos. Tal como se ha mencionado anteriormente, este proceso se encarga de la coordinación de cada uno de los procesos involucrados en la aplicación batch. 88

95 Histórico El histórico se encarga de descargar de los servidores de yahoo un archivo por cada una de las empresas del IBEX35. Cada vez que se descarga uno, lo carga en memora, realiza un rastreo de los datos en él y los introduce en la base de datos. Por último llama al un método de la clase que realiza las estadísticas históricas para que cree las estadísticas. SI existen más empresas se vuelve a repetir el proceso hasta que no quedan más empresas. 89

96 Obtener cotizaciones El proceso de obtener las cotizaciones se encarga de recibir las cotizaciones de un fichero de yahoo. Cada línea de dicho fichero contiene los datos de una empresa del ibex35, que introduce en la base de datos. Luego se invoca a una función de la clase estadísticas que realiza la estadística del intradía de dicha empresa. El último paso, consiste en ejecutar las órdenes de los usuarios con las nuevas cotizaciones, tal y como viene descrito en los casos de uso. De esta manera, las operaciones no son inmediatas y se pueden realizar operaciones a largo plazo con órdenes con precio limitado o condicionado. 90

97 Programación 91

98 6. Programación En este apartado se detallan los lenguajes de programación utilizados, las herramientas y las tecnologías que han sido utilizadas para la realización de la fase de programación. Para la realización de la aplicación web se ha utilizado las siguientes tecnologías: JavaEE AJAX con el framework DWR Para la aplicación batch se han utilizado las siguientes tecnologías: JavaSE Framework JFreeChart (realización de estadísticas). Las herramientas utilizadas para la programación han sido: Eclipse 3.2: Entorno de desarrollo muy completo de código libre. Jakarta Tomcat : Contenedor de servlets, servirá como servidor de la aplicación web. MySql : Gestor de base de datos de software libre bajo la licencia GNU GPL, las empresas que quieran incorporarlo en productos privativos deben abonar la licencia. A continuación se va a realizar una descripción de cada una de las tecnologías haciendo énfasis en aquellas que pueden ser más desconocidas por su menor uso como son JFreeChart y AJAX usando DWR. Java en sus 2 versiones está muy extendido y no se necesita describirlo en exceso. 92

99 6.1 AJAX con DWR AJAX AJAX (Asynchronous JavaScript and XML) es una técnica de desarrollo para crear páginas interactivas. Estas aplicaciones se ejecutan en el navegador del usuario realizando peticiones al servidor en segundo plano. De esta manera es posible realizar cambios en una página sin necesidad de recargarla. Las principales ventajas que se obtienen con esta tecnología son: Interactividad: El contenido de las paginas cambia dinámicamente, el contenido de la página que no se vea afectado por las peticiones en segundo plano no cambia. Velocidad: Realizar una petición asíncrona es más ligera que una síncrona, además no se transmite tanta información ya que tan sólo se transmite la información solicitada no toda la página con sus imágenes y contenido repetido. Usabilidad: Estas páginas creadas con AJAX son siempre mucho más útiles, permiten mostrar más información en menos espacio al ir cambiado esta información poco a poco. AJAX en sí misma no es una tecnología, al igual que DHTML, no es una única tecnología sino que se compone de varias: HTML o XHTML: El HTML (HyperText Markup Languaje es el lenguaje de programación de páginas web tradicionales, pero combinadas con el resto de tecnologías se obtiene AJAX. El HTML se utiliza para el diseño que acompaña a la información. CSS: Cascade Style Sheet, se utiliza para definir el formato de los objetos del HTML, es un estándar del W3C. 93

100 El Objeto XMLHttpRequest: Es un interfaz para realizar peticiones HTML asíncronas al servidor. La interfaz se presenta encapsulado en una clase. Para utilizarlo la aplicación cliente debe crear una nueva instancia mediante el constructor adecuado. Es posible realizar peticiones síncronas y asíncronas al servidor; en una llamada asíncrona el flujo de proceso no se detiene a esperar la respuesta como se haría en una llamada síncrona, si no que se define una función que se ejecutará cuando se complete la petición: un manejador de evento. DOM: Document Object Model: es una forma de representar los elementos de un documento estructurado (tal como una página web HTML o un documento XML) como objetos que tienen sus propios métodos y propiedades. El responsable del DOM es el W3C. El DOM proporciona una API para poder modificar los objetos de un HTML dinámicamente. 94

101 DWR Una vez definido lo que es AJAX, vamos a ver cómo funciona la implementación que utiliza el FrameWork DWR. DWR consiste básicamente en 2 cosas: JavaScript: Funcionando en el lado del cliente para lanzar las peticiones asíncronas. Un Servlet que procesa las peticiones y envía las respuestas al cliente. El enfoque interesante del DWR es que el javascript se genera dinámicamente a partir de clases java. Lo interesante de esto es que el cliente puede ejecutar códigos javascript como si fuera código java con la excepción de que las clases que se ejecutan no lo hacen en el cliente sino que se están ejecutando en el servidor. Por razones de seguridad, no se permite la ejecución de cualquier clase java, tan sólo las que se den permiso en el servidor. Una vez proporcionadas a DWR las clases java que quieres poder ejecutar, DWR te proporciona una función javascript que hay que incorporar a la página, el código está oculto para el desarrollador, se encuentra dentro de las librerías del DWR. 95

102 Un ejemplo de funcionamiento: Desde una página web, en el código de un formulario se introduce un evento que al activar el formulario pide información al servidor a través de una petición asíncrona para rellenar una lista de opciones. En este caso, con las opciones 1,2 y 3. La ventaja fundamental de DWR es que no hay que preocuparse del objeto XMLHttpRequest ya que él tiene su propia implementación y se encarga de controlar sus estados a través del código javascript que te proporciona. Únicamente hay que crear funciones de javascript que actúen con el DOM para situar la información dentro de la página web. Es por su simplicidad que este FrameWork está cada día más extendido. Su instalación es bastante simple, hay que incorporar 1 librería, retocar el web.xml y poner un archivo dwr.xml al lado del web.xml. Sin embargo hay que cerciorarse de que las librerías necesarias para AJAX estén también en el Tomcat. 96

103 Vamos ahora a ver un ejemplo de la aplicación de cómo funciona DWR: Actualizar el marquee de cotizaciones con DWR Al instalar el DWR, hemos creado una clase Java que funcionará como el coordinador de las peticiones que nos sirva el servlet de DWR. Esta clase es Cotizar.java y está dentro del paquete servicios. Al indicarle al servlet que puede acceder a esa clase java nos crea 2 javascripts ocultos. DWR nos proporciona entonces 2 líneas de código para importar esas funciones javascripts e incorporarlas a la página. <script type='text/javascript' src='/smg/dwr/engine.js'></script> <script type='text/javascript' src='/smg/dwr/util.js'></script> Estas 2 funciones son para el funcionamiento del DWR <script type='text/javascript' src='/smg/dwr/interface/cotizar.js'></script> Ésta función es la que DWR crea para poder acceder a Cotizar.java Adicionalmente nos hemos creado un javascript que es el que llamará a la función getmarquee() de Cotizar.java y volverá a ejecutarla a los 60 segundos, así el contenido del marquee se actualizará al minuto. <script type="text/javascript" src='/smg/js/marquee.js'></script> function updatemarquee() { Cotizar.getMarquee(marquee); settimeout(updatemarquee,60000); } function marquee(data) { document.getelementbyid("cotizaciones").innerhtml = data; } Cotizar.getMarquee(marquee); Con esta sentencia se llama a la función getmarquee de Cotizacion.java y le decimos que la vuelta la debe recibir la función marquee. 97

104 Ahora tan solo necesitamos que el evento ejecute la función updatemarquee(), para ello hemos incorporado al tag body un evento onload. <body bgcolor="#cccccc" onload="updatemarquee();=> Ahora veamos el código de Cotizar.java para ver que hace. public String getmarquee() throws ServletException, IOException { WebContext webcontext = WebContextFactory.get(); HttpSession session = webcontext.getsession(); HttpServletRequest request = webcontext.gethttpservletrequest(); ServicioIndice l = new ServicioIndice(); ArrayList cot = null; cot=l.cotizaciones(); Date dia = new Date(); session.setattribute("dia",dia); session.setattribute("cotizaciones",cot); String html = webcontext.forwardtostring("/jsp/marqueecotizaciones.jsp"); } return html; Básicamente, el método llama al servicio índice para que le suministre las últimas cotizaciones, luego las introduce en la sesión. A continuación con la sentencia webcontext.forwardtostring("/jsp/marqueecotizaciones.jsp"); Realiza una request a un jsp para que cree el código con las nuevas cotizaciones y se lo devuelva en un String que será el que Cotizacion.java devuelva al Servlet DWR. Una vez en el servlet, éste devuelve a través de la request asíncrona el código HTML a la función marquee: function marquee(data) { document.getelementbyid("cotizaciones").innerhtml = data; } Ésta utiliza una de las funciones del DOM para encontrar el elemento marcado con el nombre cotizaciones dentro de la página que está mostrando el navegador y actualiza su código con en recibido por el servlet DWR y generado por Cotizar.java. 98

105 6.2 FrameWork JFreeChart JFreeChart es una librería de java que permite crear estadísticas puede mostrarlas a través de streaming, formatos pdf, jpg,png y muchos más. Es software libre aunque la documentación no lo es y la API no es fácil de utilizar. JFreeChart permite hacer muchos tipos de gráficas como gráficos de barras, líneas, puntos, tartas y muchos otros tipos. Algunos ejemplos de lo que se puede hacer con JFreeChart: 99

106 Para poder utilizarlo únicamente hay que introducir los archivos.jar que hay en las librerías de la aplicación a desarrollar. Para ver cómo funciona vamos a explicar un ejemplo que se ha realizado con para el sistema. Histórico de una Empresa public void graficahistorica(string tiker, Connection con, int id) { try { int i=0; PreparedStatement pstmt = con.preparestatement("select * FROM COTIZACIONES WHERE idempresa=? ORDER BY fecha DESC"); pstmt.setint(1, id); ResultSet rs = pstmt.executequery(); XYSeries series = new XYSeries("precio",false); rs.afterlast(); while(rs.previous()) { double precio =rs.getdouble("precio"); series.add(precio, i); i++; } i=0; XYDataset xydataset = new XYSeriesCollection(series); JFreeChart chart = ChartFactory.createXYLineChart(tiker, "precio", "dia", xydataset, PlotOrientation.HORIZONTAL, true, false, false); BufferedImage imgpantalla = chart.createbufferedimage(300,300); String root=system.getenv("catalina_home"); File foto= new File(root+"/webapps/smg/images/"+tiker+"historicomax.jpg"); FileOutputStream os; os = new FileOutputStream(foto); JPEGImageEncoder objcodifica = JPEGCodec.createJPEGEncoder(os); objcodifica.encode(imgpantalla); os.close(); } } catch (Exception e) { // TODO Auto-generated catch block e.printstacktrace(); } 100

107 Veamos cómo funciona detalladamente. Primero se obtienen los datos a representar con una sentencia SQL. Creamos una serie en el eje XY (XYSeries). Recorremos el ResultSet y vamos añadiendo a la serie valores. Añadimos al xydataset la serie creada, con esta clase podríamos añadir a un mismo gráfico varias series. Por último se crea la gráfica con la clase JFreeChart, se le pasan el título, los nombres de los ejes, los datos del DataSet, y otras opciones. En ete caso queremos crear una imagen con la gráfica y depositarla en la carpeta $CATALINA_HOME/webapps/smg/images para que pueda ser accedida desde navegador. JFreeChart también proporciona un codificador a varios formatos, en este caso usamos JPEG, el JPEGImageEncoder codifica la gráfica y lo enviía a un Stream. El resultado es el siguiente: 101

108 6.3 Java EE y Java SE La tecnología Java proporciona un entorno de desarrollo multiplataforma y admite varias plataformas, desde servidores hasta teléfonos celulares y tarjetas inteligentes. La tecnología de Java unifica la infraestructura de negocio creando una plataforma ininterrumpida, segura y conectada en red para los usuarios. JavaEE (Java Enterprise Edition) es el estándar utilizado para la creación de aplicaciones web Java, portables, robustas, escalables y seguras. Son aplicaciones Server Side, donde todo se ejecuta sobre el servidor. Ventajas de JavaEE: Múltiples clientes: Es un servidor de aplicaciones y permite a varios usuarios utilizar sus recursos al mismo tiempo. Múltiples arquitecturas, en nuestro caso hemos elegido MVC. Código portable: Al ser java sólo se necesita una JavaVM y un servidor compatible con la plataforma en la que se instale. Orientación a objetos: Al ser Java tiene todas las ventajas de java. JavaSE (Java Standard Edition) Java Platform, Standard Edition o Java SE (conocido anteriormente hasta la versión 5.0 como Plataforma Java 2, Standard Edition o J2SE), es una colección de APIs del lenguaje de programación Java útiles para muchos programas de la Plataforma Java. 102

109 El Sistema Experto de Análisis Técnico 103

110 7. El Sistema Experto de Análisis Técnico Al ser una parte importante del proyecto, es necesario hacer un apartado especial para abarcarlo de una forma más amplia y profunda. Para entender el problema primero se va a estudiar en qué consiste el análisis técnico bursátil, los indicadores y osciladores utilizados, su interpretación y su forma de calcularlos. Al realizar Stock Market Game se han creado nuevos osciladores propios y que se describen en el punto 7.2 El sistema experto está basado en reglas de producción, una vez obtenido los resultados del análisis técnico, el sistema aplicará unas reglas y como resultado dará recomendaciones de compra, fuerte compra, venta, fuerte venta y mantener el valor. Por último, se ha creado un simulador, que participa en el juego de Stock Market Game y que utiliza únicamente las recomendaciones del sistema experto para invertir. De esta manera podemos comprobar que el sistema experto minimiza pérdidas y aumenta las ganancias. Para estudiar el sistema experto es necesario primero entender cómo funciona la bolsa, sus osciladores e indicadores, luego los osciladores creados explícitamente para Stock Market Game y por último las reglas que mueven el sistema. 104

111 7.1 El análisis técnico. El análisis técnico se basa en el uso de osciladores e indicadores para encontrar las señales de compra y venta de un título. Un indicador u oscilador técnico es tan sólo una relación matemática entre variables bursátiles (generalmente cotizaciones), que según su tendencia, cambio de sentido o corte de líneas de referencia, indica el momento de compra o de venta de un título. Los osciladores técnicos oscilan entre el cero y el cien por cien. La principal ventaja de los indicadores y osciladores técnicos es su sencilla utilización y fiabilidad en la toma de decisiones, destacando la fácil lectura de sus señales de compra y venta, muy clara y concreta. Existen muchos tipos de indicadores y osciladores técnicos y continuamente se crean nuevos indicadores que desaparecen tan rápido como se crearon. No existe un indicador universal que sirva para cualquier título o situación del mercado, por lo que es conveniente utilizar más de un indicador u oscilador técnico para valorar una sociedad en un momento determinado. 105

112 Los osciladores del análisis técnico tradicional utilizados por Stock Market game son los siguientes: RSI Definición: El RSI (Relative Streeght Index), conocido como Indicador de Fuerza Relativa, funciona muy bien en la bolsa española, mide la fuerza de la oferta y la demanda. Cálculo: RSI n = 100- (100/1+RS) Siendo RS= Suma de cotizaciones de subida/ Suma de cotizaciones en bajada en los últimos n días. Interpretación: Cuando el RSI sobrepasa el 80% se considera que el valor ha entrado en zona de sobre compra. Por el contrario, si se sitúa por debajo del 20%, se considera que el valor ha entrado en zona de sobre venta. Media Móvil Definición: La media móvil es una media aritmética de los últimos N días, sirve para ver si el valor se encuentra por encima de la media. Cálculo: Media móvil = Suma de las cotizaciones de los últimos N dias/ N Interpretación: No proporciona cambios de tendencia pero si los puede confirmar. 106

113 Estocástico Definición: El estocástico consta de 2 datos, la K y la D, Se trata de comparar el precio de cierre respecto de la gama de precios de un determinado periodo. Cálculo: K= 100*(C-Min/Max-Min) Siendo Min y Max el mínimo y máximo de las últimas n sesiones respectivamente y C el cierre de la última cotización. %D= mediamóvil de %K de los últimos 3 días. Interpretación: Las señales de compra o de venta se pueden producir cuando la línea del %K corta a la línea del %D. Estas señales solo serán significativas si se producen en los máximos o en los mínimos del estocástico, siempre traspasada la línea 70 (hacia arriba) o del 30 (hacia abajo). Momentum Definición: Se basa en el diferencial entre una cotización y una anterior Cálculo: Momentum= C- Cn, siendo C el cierre anterior y Cn el cierre de hace n sesiones. Interpretación: Este oscilador pretende medir la velocidad del movimiento de los precios. 107

114 Volatilidad Definición: La volatilidad mide las distancias entre máximos y mínimos de una cotización para determinar si un valor es muy volatil Cálculo: Volatilidad= (max-min)/ media de variación entre máximos y minimos en N periodos Interpretación: Si un valor es muy volátil, significa que hay grandes diferencias entre los máximos y mínimos, haciendo más difícil verificar las tendencias. Por el contrario si es poco volátil, las tendencias son más veraces. 108

115 7.2 Los osciladores de SMG. Otro de los aspectos interesantes de Stock Market Game ha sido la invención de varios osciladores. Algunos de ellos no sirven mucho solos, pero sirven para confirmar tendencias. Stop Loss El Stop Loss intenta prevenir las pérdidas, puede servir para identificar roturas de tendencias laterales. El Stop Loss observa si el cierre de la última sesión ha rebasado el límite marcado por el mínimo de las últimas 3 sesiones. En el ejemplo que se ve a continuación, en el primer descenso el Stop Loss habría dado una señal de venta. Subida Libre La subida libre es un indicador que avisa de que es posible que se rompa una resistencia, hay veces en que el RSI y el estocástico dan señales de venta falsas porque están en una tendencia lateral. Este indicador te señala esta situación. El uso de este oscilador, es para que el inversor esté atento a las roturas de resistencias. Si se rompe es muy probable que el valor sufra un brusco cambio. 109

116 Oscilador de Vuelta El oscilador de vuelta, mide las vueltas que da el valor, ya sean al alza o a la baja. Si un valor sufre una gran vuelta como la que se muestra a continuación, el oscilador de vuelta, avisa de la gran vuelta y es posible que el valor empiece una tendencia al alza. Estos son los osciladores que se han desarrollado para Stock Maket Game, estos osciladores, no son muy útiles por si solos, pero le servirán al sistema experto para determinar mejor cuando vender y cuando comprar ya que un programa informático no puede visualizar tendencias tan fácilmente como un ojo humano al ver una gráfica. Otros, como el oscilador de subida libre es un indicador para el usuario, para que esté atento a cambios bruscos en los que se puede ganar o perder altas cantidades de dinero. 110

117 7.3 El sistema experto El sistema experto diseñado para Stock Market Game, se basa en reglas. Una vez calculados todos los indicadores, el sistema experto determinará recomendaciones sobre cada valor, dependiendo de los indicadores calculados. El mayor problema al que se enfrenta el sistema es el momento de la venta, es mucho más difícil saber cuándo vender que cuándo comprar. Situaciones posibles: Compra Si: Se produce un corte de compra del estocástico y no se produce un Stop Loss. Fuerte Compra: Si se produce la situación anterior y además se ha formado una figura de vuelta al alza. Si se produce una situación de compra y el RSI<20 Venta: Se produce un corte de venta de estocástico. Se forma una figura de vuelta a la baja. Se produce un Stop Loss. Fuerte venta: Se produce un corte de venta del estocástico y hay una figura de vuelta. Se produce un corte de venta del estocástico y el RSI>80, sin embargo en esta situación es posible que se produzca una subida libre. Neutro: El resto de casos. 111

118 7.4 Resultados El Simulador ha obtenido los siguientes resultados en 2 semanas de evaluación. Para comparar resultados se va a coger el incremento del día del índice del IBEX y el valor de la cartera con los beneficios del día. Se hace de esta manera para ver si el sistema invierte mejor que el índice sobre el que trabaja. La tendencia del IBEX35 de los últimos días ha sido de una gran bajada, por lo tanto el sistema debería minimizar las pérdidas. Día %IBEX35 Cartera Ganancias %Ganancias Diferencia IBEX-SMG 30-ago 0,10% ,8375% 1,74% 31-ago 0,60% ,6625% 0,06% 05-sep -2,10% ,75% 1,35% 06-sep -0,50% ,333% 0,17% 07-sep -0,83% ,323% 0,51% Como se puede ver en la tabla, aunque la tendencia del IBEX sea bajista, empezara en puntos, y el día 7 cerrara con puntos, el sistema ha ganado en ese periodo en total 30 en inversiones, no es mucho, pero al contrario que la bolsa su cartera de valores ha subido. De hecho el SMG siempre mejora los resultados del IBEX, tal y como se puede ver en la última columna. Estos valores son extremadamente positivos, porque se demuestra que el sistema sabe cuándo debe vender, ya que es mucho más difícil saber cuándo vender que comprar. 112

119 7.5 El simulador Para comprobar la exactitud del sistema experto, se ha desarrollado un simulador. Este simulador sigue las indicaciones de compra y venta que manda el sistema experto. Además este simulador está incluido en el juego como un jugador más. De esta manera, los demás jugadores pueden observar cómo evoluciona el sistema y si son capaces de invertir mejor que el sistema. El funcionamiento del simulador sigue un patrón bastante simple. Después de que se ejecute el sistema experto al final del día, el simulador rastrea las recomendaciones: Si hay recomendaciones de compra, el simulador lanzará órdenes de compra de ese valor. Si hay recomendaciones de venta y el simulador tiene stocks, las venderá. El simulador se gastará todos los días un 10% de los fondos que tenga sin usar equitativamente entre los valores recomendados. 113

120 Presupuesto 114

121 8. Presupuesto. Actividades Horas Coste Lanzamiento 2 80 Identificación de necesidades Análisis de requisitos Diseño del sistema Diseño detallado Programación y pruebas Documentación Dirección del proyecto Coordinación del proyecto TOTALES Para la realización del presupuesto se han tenido en cuenta los siguientes perfiles profesionales: Jefe de proyecto: El jefe de proyecto se encarga de las fases de: Lanzamiento. Identificación de necesidades. Documentación. Su tarifa es de 40 /hora Analista funcional: El analista funcional se encarga de las fases de: Análisis de requisitos. Diseño del sistema. Diseño detallado. Su tarifa es de 35 /hora Programador: El programador se encarga de las fases de: Programación y pruebas Su tarifa es de 30 /hora 115

122 Director de Proyecto: El director se encarga de las labores de dirección del proyecto. Su tarifa es de 45 /hora Coordinador del Proyecto: El coordinador se encarga de las labores de coordinación. Su tarifa es de 50 /hora Quedando el presupuesto en la cuantía de iva incluido. Siendo todas las herramientas utilizadas de software libre. A excepción de MySQL que deberá abonarse la licencia en caso de ser explotado por una empresa. 116

123 Conclusiones 117

124 9. Conclusiones El sistema creado, aparte de usar tecnologías de última generación, tiene un sistema de ayuda a la inversión, este sistema se basa en el análisis técnico, que es muy valioso a la hora de interpretar las tendencias del mercado. Estos sistemas suelen servir de gran ayuda a cualquier persona, sin embargo su utilización optima se obtiene al combinarlos con la experiencia de los inversores y saber cuándo vender. El análisis técnico es una herramienta útil a la hora de invertir día a día, los osciladores tienen argumentos modificables para adecuarlos a cada valor. En definitiva, el sistema experto creado para los usuarios del sistema es una gran herramienta de ayuda a la inversión. Los osciladores creados específicamente para el sistema permiten observar situaciones que no se aprecian a simple vista y permite reducir perdidas, como por ejemplo el oscilador StopLoss. La realización del proyecto Stock Market Game, me ha permitido aprender nuevas tecnologías como el J2EE, AJAX o JFreeChart, que mejorará mi preparación como ingeniero en informática además de la experiencia adquirida en la realización de proyectos, muy beneficiosa de cara al mundo laboral. Gracias a este proyecto he podido recopilar información sobre el mundo de la bolsa, sus comportamientos, las herramientas que se utilizan en el análisis técnico y el análisis chartista. Este proyecto fin de carrera, me ha permitido crear un proyecto de principio a fin, desarrollando cada una de sus fases, desde el diseño hasta la programación sin olvidar el proceso de documentación que ha acompañado al proyecto durante su desarrollo. Las herramientas adquiridas durante la carrera me han servido de mucha ayuda, ya sean los lenguajes de programación, como las asignaturas de ingeniería de software o de bases de datos, me han permitido abarcar el proyecto de una forma profesional. La experiencia del aprendizaje en la escuela, me ha permitido entender mejor las herramientas que antes no conocía y ponerlas en práctica en un proyecto completo. 118

125 Futuras Mejoras 119

126 10. Futuras Mejoras Aunque el sistema es muy completo, siempre existen márgenes de mejora, sin embargo no ha sido posible implantarlas por estar fuera del alcance del proyecto y las fechas de entrega marcadas. Encontrar una fuente de cotizaciones más fiable que yahoo. Existen empresas que se proporcionan los datos al minuto a cambio de una cuota al mes. Optimizar el Sistema Experto, cada oscilador podría ser adaptado a cada valor del IBEX35, en este momento, se usa una configuración genérica. Observar el comportamiento del Sistema Experto a largo plazo, los periodos de recogida de datos han sido pequeños y en una época difícil para la bolsa. Incluir más osciladores en el sistema experto. Crear Gráficas de los osciladores Gráficos de velas para las cotizaciones históricas. Mejorar el simulador con los resultados obtenidos. 120

127 Planificación 121

128 11. Planificación Para representar la planificación de actividades se ha realizado un diagrama de gant, en el eje horizontal se representan los meses del desarrollo del sistema y en el eje vertical las actividades a realizar. Las actividades representadas en la planificación son las correspondientes a las fases de desarrollo del sistema. LANZ: Lanzamiento ID. N: Identificación de necesidades ARQ: Análisis de requisitos DIS S: Diseño del sistema DIS D: Diseño detallado PRO: Programación y pruebas DOC: Documentación 122

129 Bibliografía 123

130 12. Bibliografía [BARR01] [ECKE00] [PERR06] Jesús Barranco de Areba, Metodología del análisis estructurado de sistemas, Publicaciones de la Universidad Pontificia de Comillas Madrid. Bruce Eckel, Thinking in Java, Second Edition, Editorial Prentice Hall. Bruce W. Perry, AJAX HACKS, tips & tools for Creating Responsive Web Sites, Editorial O Reilly [RMRBO02] Enrique Rivero Cornelio, Luis Martinez Fuentes, Luis Reina Juliá, Juan Benavides Abajo, Jan Mª Odriozola Bartolomé, Introducción al SQL para Usuarios y Programadores, Editorial Thompson Apuntes de la asignatura: Ingeniería del software II, Juan Carlos Esquivel. tecnología wiki. La enciclopedia libre plurilingüe basada en Portal de finanzas de yahoo. La Web de bolsa y los mercados de valores. Manual de JavaScript Web de DWR (Direct Web Remoting) Artículo con un pequeño manual de DWR. API de JFreeChart API Java 124

131 Tutorial de análisis técnico técnico. Curso de análisis Wiki con manual de DWR Página oficial de JFreeChart 125

132 Anexo I: Manual de instalación 126

133 Anexo I. Manual de instalación Paso 1: Instale Java versión 1.5 revisión 9 o superior. Paso2: Instale Jakarta Tomcat que está incluido en el CD, o instale un servidor de aplicaciones java compatible con J2EE y AJAX. En el caso de no instalar el Tomcat que viene incluido, copie las librerías al nuevo servidor. Paso 3: Instale MySQL o superior. Ejecute el archivo smg.sql que encontrará en la carpeta etc de la aplicación web, o en la misma carpeta del ejecutable de MySQL. Paso4: Instalar Eclipse 3.2 o superior. Abrir proyecto SMG y Cotizaciones. Desplegar la aplicación web copiando el archivo smg.war en la carpeta webapp del servidor. O desde Eclipse haga click con el botón derecho sobre el archivo build.xml del proyecto smg (Recuerde que en el path del sistema debe figurar CATALINA_HOME como la ruta donde instaló el tomcat). Paso 5: Arraque el tomcat y seguidamente Ejecute el programa main.java del proyecto cotizaciones Felicidades, ya ha instalado Stock Market Game Puede acceder localmente al programa con la dirección del navegador: 127

134 Anexo II: Manual de Usuario 128

135 Anexo II. Manual de usuario El manual de usuario describe todas las opciones disponibles en Stock Market Game. Registro Para empezar, accedemos a la página principal del programa para proceder a registrarnos: Para registrarse, pulsamos en la barra de navegación superior en el Registrarse o en el formulario de conexión. apartado A través de esta página también se puede visitar la información referente a Stock Market Game o la página con Links a las mejores páginas de inversión de España. 129

136 Apareceremos en la siguiente página: Rellenamos el formulario y enviamos la solicitud, si todo esta correcto, nos saldrá un aviso confirmándolo, sino, se informará del error cometido para proceder a cumplimentar correctamente el formulario. Si todo está correcto, primera vez. ya pertenecemos al sistema y podemos conectarnos por Errores posibles: El nombre de usuario ya está elegido. No se han aceptado las condiciones de uso. 130

137 Conectarse al sistema Para conectarse al sistema, es necesario haberse registrado previamente, una vez registrados, rellenaremos el formulario de conexión que figura en la parte superior izquierda de las páginas de inicio. Este es el formulario: Se rellena con el nombre de usuario y la contraseña elegidas a la hora de registrarse. Si nos equivocamos nos saldrá un aviso como este: Si todo es correcto llegaremos a la página principal. 131

138 Página principal. Elementos de la página principal: Barra de navegación: Todos los aspectos del sistema son accesibles desde esa barra, servirá para moverse por el sistema, todas las páginas tienen el mismo menú, para poder acceder desde cualquier situación a cualquier parte del sistema. 132

139 Información de usuario: Encima de la barra de navegación podemos encontrar información que tenemos del usuario, como las ordenes pendientes de ejecución o los mensajes en el buzón. Esta información al igual que la barra de navegación se encuentra en todas las páginas. Contenido: En la página principal podemos encontrar diversos contenidos, todos ellos informativos: Clasificación de jugadores. Clasificación de ligas Los mejores valores del día Los peores valores del día Las mejores recomendaciones del sistema experto. Marquee de cotizaciones: Este elemento también está presente en todo el sistema, da información de todas las cotizaciones al minuto: Se sitúa encima del contenido. Como se podrá comprobar, todas las páginas del sistema mantienen el mismo formato. Tan sólo cambia el contenido de la página. Las barras de navegación, el título, la información de usuario y el marquee de cotizaciones se mantiene en todas las páginas. 133

140 Cotizaciones En el menú de cotizaciones se pueden ver todos los datos de las empresas y sus cotizaciones actuales, desde este menú se puede: Acceder a comprar Valores Ver el análisis de los valores Ver las estadísticas del valor 134

141 Cartera En este apartado aparecen todos los valores que tiene la cartera del usuario, pudiendo ver información como la inversión inicial, el beneficio y el precio de compra. Desde el menú de cartera se puede acceder a; Las estadísticas del valor Vender valores. 135

142 Comprar Valores Una vez seleccionado un valor en la página de cotizaciones y pulsado el botón de comprar, aparecemos en la pantalla de compra de valores. Existen distintos tipos de compras: A precio de mercado: Esta orden de venta consiste en comprar el valor al precio de mercado en el momento de la compra Precio Limitado: Esta orden se ejecutará si el valor se sitúe por debajo del precio marcado en la condición Precio Condicionado: Esta orden se ejecutará si el valor supera o iguala al precio marcado en la condición. 136

143 Vender Valores Una vez seleccionado un valor en la página de la cartera y pulsado el botón de vender, aparecemos en la pantalla de venta de valores. Existen distintos tipos de ventas: A precio de mercado: Esta orden de venta consiste en vender el valor al precio de mercado en el momento de la venta. Precio Limitado: Esta orden se ejecutará si el valor supera o iguala al precio marcado en la condición. Precio Condicionado: Esta orden se ejecutará si el valor se sitúe por debajo del precio marcado en la condición. 137

144 Análisis En la pantalla de análisis se puede ver los valores que toman los osciladores y otros tipos de información: Osciladores de análisis técnico. Osciladores propios de Stock Market Game Información sobre la cotización. Mínimos de los últimos días. La recomendación del sistema. Existe un enlace debajo del análisis donde se explica cómo interpretar los valores que toman los distintos indicadores. 138

145 Estadísticas En la página de estadísticas a la izquierda se puede observar el gráfico del intradía, mientras que a la derecha podemos ver estadísticas a largo plazo, de 10,30,60,180 y máximo número de días. Pulsando sobre los enlaces de la derecha cambiaremos el contenido de la gráfica de la derecha únicamente que es la que corresponde a la estadística histórica. 139

146 Órdenes La pantalla de órdenes contiene las órdenes de compra y venta que un usuario tiene, muestra la información de la orden y la opción de cancelarla en caso de no ser ya útil o de habernos equivocado al lanzar la orden. La opción de cancelar órdenes se hace obligatoria debido a que pueden existir órdenes a largo plazo utilizando las órdenes limitadas y condicionadas de compra y venta. 140

147 Recomendaciones La página de recomendaciones, contiene toda la información de los osciladores creados por Stock Market Game sobre todos los valores del sistema. En la pantalla de análisis sólo se veía un valor, en esta pantalla se pueden ver todos los valores de forma global. Noticias Esta pantalla contiene las noticias de última hora obtenidas del RSS de cada noticia tiene un enlace a la noticia completa 141

148 Opciones de Liga Alta en liga Si no hemos creado ninguna liga y no pertenecemos a una liga concreta, el menú de la izquierda contendrá 2 opciones de liga: Alta en liga y crear Liga: El alta en liga sirve para realizar una petición al líder de una liga para que le acepte dentro de su liga, se introduce el tag de la liga y el mensaje que acompaña a la petición de entrada. Una vez aceptados en la liga, nuestra visión del menú de liga será el siguiente, veremos los datos de la liga, la clasificación de los miembros y la opción de abandonarla, si la pulsamos, volveremos a no pertenecer a ninguna liga. 142

149 Crear Liga Si no hemos creado ninguna liga y no pertenecemos a una liga concreta, el menú de la izquierda contendrá 2 opciones de liga: Alta en liga y crear Liga: En la creación de la liga, se tiene que introducir los datos de esta: Tag. Nombre Descripción Una vez introducida habremos creado la liga. El creador de la líga es también el líder y administrador de la misma. 143

- MANUAL TÉCNICO - Implantación de software de Marketing Online

- MANUAL TÉCNICO - Implantación de software de Marketing Online - MANUAL TÉCNICO - Implantación de software de Marketing Online Rev. 01- MAYO 2013 Implantación de software de Marketing Online Teléfono Adeada: 945 253 388 Email Adeada: adeada@adeada.com REALIZADO POR:

Más detalles

Licencia 2: (Creative Commons)

Licencia 2: (Creative Commons) Licencia 2: (Creative Commons) Esta obra está bajo una licencia Reconocimiento-No comercial-sin obras derivadas 2.5 España de Creative Commons. Puede copiarlo, distribuirlo y transmitirlo públicamente

Más detalles

- MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD. Rev. 01- FEBRERO 2013

- MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD. Rev. 01- FEBRERO 2013 - MANUAL TÉCNICO - Software de diagnóstico de la seguridad de la información y autoimplantación de LOPD Rev. 01- FEBRERO 2013 Software de diagnóstico de la seguridad de la información y autoimplantación

Más detalles

Curso Tecnologías Móviles

Curso Tecnologías Móviles INSTALACION DEL SDK DE ANDROID. INTRODUCCION AL ENTORNO DE DESARROLLO DE ANDROID. (ECLIPSE) Donde descargar el sdk de android. http://developer.android.com/sdk/index.html Como saber si tenemos correctamente

Más detalles

Análisis y diseño del sistema CAPÍTULO 3

Análisis y diseño del sistema CAPÍTULO 3 Análisis y diseño del sistema CAPÍTULO 3 36 CAPÍTULO 3 Análisis y diseño del sistema En este capítulo se pretende realizar un análisis detallado de los requerimientos del software a desarrollar para la

Más detalles

TFC J2EE. Tienda Online:WebCine

TFC J2EE. Tienda Online:WebCine TFC J2EE Tienda Online:WebCine Jose Luis Del Hoyo Fernández Consultor: Antoni Oller Arcas 13/01/2014 Índice del contenido 1. Introducción... 4 1.1 Descripción del proyecto... 4 1.2 Objetivos... 4 1.3

Más detalles

Memoria. Alumno: Pablo López López. Consultor: Jesús Bosch Ayguade

Memoria. Alumno: Pablo López López. Consultor: Jesús Bosch Ayguade TFC.NET Memoria Alumno: Pablo López López Consultor: Jesús Bosch Ayguade ETIS 2011 Índice Descripción del proyecto y objetivos Pág. 3 Estudio de la idoneidad del proyecto Pág. 4 Tecnologías utilizadas

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

Proyecto para una tienda On-Line Documento FINAL. Alumno Santiago González ITIG. Consultor Javier Ferró García. Fecha de entrega: 16/01/07

Proyecto para una tienda On-Line Documento FINAL. Alumno Santiago González ITIG. Consultor Javier Ferró García. Fecha de entrega: 16/01/07 Proyecto para una tienda On-Line Alumno Santiago González ITIG Consultor Javier Ferró García Fecha de entrega: 16/01/07 ÍNDICE 1. INTRODUCCIÓN... 3 2. FASE DE ANÁLISIS... 4 a) DESCRIPCIÓN DEL PROYECTO

Más detalles

PROYECTO FINAL DE CARRERA: RESERVA DE VEHÍCULOS MEDIANTE INTERFAZ WEB

PROYECTO FINAL DE CARRERA: RESERVA DE VEHÍCULOS MEDIANTE INTERFAZ WEB PROYECTO FINAL DE CARRERA: RESERVA DE VEHÍCULOS MEDIANTE INTERFAZ WEB Ingeniería Técnica Informática de Gestión Alumno: Jorge Bou Ramón Director: Sergio Sáez Barona Junio 2012 ÍNDICE 1. INTRODUCCIÓN...4

Más detalles

TELEFÓNICA MÓVILES ESPAÑA, S.A.U. Software para Soporte Unificado de Facturación

TELEFÓNICA MÓVILES ESPAÑA, S.A.U. Software para Soporte Unificado de Facturación TELEFÓNICA MÓVILES ESPAÑA, S.A.U. Software para Soporte Unificado de Facturación Manual de Usuario SOFIA GESTIÓN V.5 Pág. 2 de 300 S O F T W A R E P A R A S O P O R T E U N I F I C A D O D E F A C T U

Más detalles

Portafolio de finanzas implementado en Joomla! Antoni Aguiló Tarré PFC de ingeniería informática 01/07/2010

Portafolio de finanzas implementado en Joomla! Antoni Aguiló Tarré PFC de ingeniería informática 01/07/2010 Portafolio de finanzas implementado en Joomla! Antoni Aguiló Tarré PFC de ingeniería informática 01/07/2010 Introducción Orígenes y objetivos Planificación Contexto de la aplicación - Gestor de portafolios

Más detalles

Model View Controller Architecture. Dra. Marcela Capobianco

Model View Controller Architecture. Dra. Marcela Capobianco Diseño y Desarrollo de Software Model View Controller Architecture Dra. Marcela Capobianco 1 Qué es MVC? Model View Controller (MVC) es un patrón agregado que separa los datos de una aplicación, la interfaz

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR

CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR CAPÍTULO 4 ANÁLISIS Y DISEÑO: e-commerce CONSTRUCTOR En este capítulo se describe el análisis y diseño de un sistema, denominado e-commerce Constructor, el cual cumple con los siguientes objetivos: Fungir

Más detalles

E5.1b Diseño Arquitectónico

E5.1b Diseño Arquitectónico E5.1b Diseño Arquitectónico Estado: FINAL CEIEC-UFV Este documento contiene el diseño arquitectónico de la solución propuesta para el Sistema PAUTA Referencia: PAUTA_DOC_E5.1b DiseñoArquitectonico v1.4

Más detalles

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje

Aplicaciones Web que Permitan Administrar Portafolios para Gestionar el Aprendizaje Escuela Universitaria de Ingeniería Industrial, Informática y Sistemas Área de Computación e Informática Universidad Tarapacá Arica Aplicaciones Web que Permitan Administrar Portafolios para Gestionar

Más detalles

IVista: es la interfaz con la que el Presentador se comunica con la vista.

IVista: es la interfaz con la que el Presentador se comunica con la vista. Capítulo 3 MODELO DE DISEÑO 3.1 Arquitectura Modelo-Vista-Presentador La arquitectura Modelo-Vista-Presentador (MVP) [11] separa el modelo, la presentación y las acciones basadas en la interacción con

Más detalles

Person IP CRM Manual MOBILE

Person IP CRM Manual MOBILE Manual MOBILE División Informática BuscPerson Telecomunicaciones : Manual MOBILE 0.- Introducción 3 0.1 Configuración de los terminales 3 0.2 Acceso de Usuarios 3 1.- Funcionalidades CRM 5 1.1 Agenda del

Más detalles

SERVICIOS PARA EL DISEÑO E IMPLEMENTACIÓN DEL PROGRAMA INTEGRAL DE TRANSFORMACIÓN DIGITAL DE LA PROVINCIA DE LUGO: TRANSFORM@TIC

SERVICIOS PARA EL DISEÑO E IMPLEMENTACIÓN DEL PROGRAMA INTEGRAL DE TRANSFORMACIÓN DIGITAL DE LA PROVINCIA DE LUGO: TRANSFORM@TIC Diputación de Lugo SERVICIOS PARA EL DISEÑO E IMPLEMENTACIÓN DEL PROGRAMA INTEGRAL DE TRANSFORMACIÓN DIGITAL DE LA PROVINCIA DE LUGO: TRANSFORM@TIC Manual usuario ERP Marzo 2015 ÍNDICE 1 INTRODUCCIÓN...

Más detalles

EXPERIENCIAS EDUCATIVAS. CREAR UN PORTAL EDUCATIVO CON JOOMLA

EXPERIENCIAS EDUCATIVAS. CREAR UN PORTAL EDUCATIVO CON JOOMLA EXPERIENCIAS EDUCATIVAS. CREAR UN PORTAL EDUCATIVO CON JOOMLA AUTORÍA PEDRO J. MORENO GARCÍA TEMÁTICA TIC ETAPA ESO, BACHILLERATO,FP Resumen Con Joomla podemos crear en pocas horas un completo portal para

Más detalles

Desarrollo de una Aplicación Móvil para Revisar

Desarrollo de una Aplicación Móvil para Revisar Desarrollo de una Aplicación Móvil para Revisar Horarios de Atención de Tutores de la UNAD Development of a Movil Application for Check Over Office Hours of Tutors of the Unad Correa Rodríguez Arellys

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES

UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES UNIVERSIDAD TÉCNICA DEL NORTE FACULTAD DE INGENIERÍA EN CIENCIAS APLICADAS ESCUELA DE INGENIERÍA EN SISTEMAS COMPUTACIONALES TEMA: La Programación Extrema aplicada al desarrollo del Sistema Informático

Más detalles

Títol: Didici - Language Learning Platform. Volum: 1/1 Alumne: Rubén Arroyo Gil

Títol: Didici - Language Learning Platform. Volum: 1/1 Alumne: Rubén Arroyo Gil Títol: Didici - Language Learning Platform Volum: 1/1 Alumne: Rubén Arroyo Gil Director: Leandro Navarro Moldes Departament: Arquitectura de Computadors Data: Juny 2012 DADES DEL PROJECTE Títol del

Más detalles

SMS Marketing. Manual de usuario. By DIDIMO Servicios Móviles

SMS Marketing. Manual de usuario. By DIDIMO Servicios Móviles SMS Marketing Manual de usuario By DIDIMO Servicios Móviles Manual de usuario SMS Marketing Madrid Network Marketplace INDICE INDICE... 2 1 QUÉ ES SMS MARKETING?... 3 2 MENÚ PRINCIPAL... 4 2.1 CAMPAÑAS...4

Más detalles

Este proyecto tiene como finalidad la creación de una aplicación para la gestión y explotación de los teléfonos de los empleados de una gran compañía.

Este proyecto tiene como finalidad la creación de una aplicación para la gestión y explotación de los teléfonos de los empleados de una gran compañía. SISTEMA DE GESTIÓN DE MÓVILES Autor: Holgado Oca, Luis Miguel. Director: Mañueco, MªLuisa. Entidad Colaboradora: Eli & Lilly Company. RESUMEN DEL PROYECTO Este proyecto tiene como finalidad la creación

Más detalles

CAPÍTULO V. Propuesta

CAPÍTULO V. Propuesta CAPÍTULO V Propuesta 5.1 Propuesta Implantación de una aplicación WEB para optimizar el Enlace Laboral de la Cámara de Comercio e Industria de El Salvador, Filial San Miguel 5.2 Requerimientos de la Aplicación

Más detalles

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego

TFC. Ingeniería de Software MEMORIA. Consultor: Juan José Cuadrado Gallego TFC Ingeniería de Software Alumno: Halyna Klachko Consultor: Juan José Cuadrado Gallego Índice 1. Identificación del proyecto..5 1.1 Introducción...5 1.2 Objetivos del proyecto..5 1.3 Descripción general..5

Más detalles

GESTOR DE DESCARGAS. Índice de contenido

GESTOR DE DESCARGAS. Índice de contenido GESTOR DE DESCARGAS Índice de contenido 1. Qué es DocumentosOnLine.net?...2 2. Qué es el Gestor de Descargas?...3 3.Instalación / Configuración...5 4.Descarga de Documentos...9 5.Búsqueda / Consulta de

Más detalles

TRABAJO FIN DE ESTUDIOS

TRABAJO FIN DE ESTUDIOS TRABAJO FIN DE ESTUDIOS PROYECTO FIN DECARRERA Sitio web y aplicación para la gestión de una tienda de bellas artes Tania De Pedro Sáenz Tutor: Beatriz Pérez Valle Curso 2011-2012 Sitio web y aplicación

Más detalles

Capítulo III. Diseño del sistema. Dentro de este capítulo veremos a detalle el diseño del sistema, que como se había

Capítulo III. Diseño del sistema. Dentro de este capítulo veremos a detalle el diseño del sistema, que como se había Capítulo III Diseño del sistema Dentro de este capítulo veremos a detalle el diseño del sistema, que como se había mencionado anteriormente, contara con 2 módulos principales: el módulo de administración

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

Nombre del Proyecto: Página web GAQSA S.A de C.V. (Módulo de laboratorios) Nombre de la Empresa: Ganaderos Asociados de Querétaro S.A de C.

Nombre del Proyecto: Página web GAQSA S.A de C.V. (Módulo de laboratorios) Nombre de la Empresa: Ganaderos Asociados de Querétaro S.A de C. UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Nombre del Proyecto: Página web GAQSA S.A de C.V. (Módulo de laboratorios) Nombre de la Empresa: Ganaderos Asociados de Querétaro S.A de C.V (GAQSA) Memoria que como

Más detalles

Resumen. Sistema informática para el desarrollo de la empresa de calzados

Resumen. Sistema informática para el desarrollo de la empresa de calzados Resumen Sistema informática para el desarrollo de la empresa de calzados Este trabajo presenta el desarrollo en las áreas de ventas y en las áreas de producción y de almacén. En el área de ventas se presenta

Más detalles

Características de OpenCms

Características de OpenCms Características de OpenCms Se basa en Java y Xml OpenCms está totalmente desarrollado en java bajo el estándar servlet. Por lo tanto, se puede integrar fácilmente en entornos hardware y software existentes,

Más detalles

APLICATECA. didimo Marketing. Manual de usuario. By DIDIMO Servicios Móviles. www.telefonica.es

APLICATECA. didimo Marketing. Manual de usuario. By DIDIMO Servicios Móviles. www.telefonica.es APLICATECA didimo Marketing Manual de usuario. By DIDIMO Servicios Móviles www.telefonica.es APLICATECA INDICE INDICE... 2 1 QUÉ ES DIDIMO MARKETING?... 3 2 MENÚ PRINCIPAL... 4 2.1 CAMPAÑAS... 4 2.1.1

Más detalles

CAPÍTULO OCHO. Módulo de Marketing. Contenido

CAPÍTULO OCHO. Módulo de Marketing. Contenido CAPÍTULO OCHO Módulo de Marketing 1. INTRODUCCIÓN 2 2. CAMPAÑAS 3 3. SEGMENTOS 8 4. SEGUIMIENTO DE CAMPAÑA 10 5. LANZAR UNA CAMPAÑA DE MARKETING Contenido 1.- Introducción El módulo de marketing permitirá

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Sistema basado en firma digital para enviar datos por Internet de forma segura mediante un navegador.

Sistema basado en firma digital para enviar datos por Internet de forma segura mediante un navegador. Sistema basado en firma digital para enviar datos por Internet de forma segura mediante un navegador. Autor: David de la Fuente González Directores: Rafael Palacios, Javier Jarauta. Este proyecto consiste

Más detalles

Capítulo 6: Instrumentación: Diseño del Sistema de H2O

Capítulo 6: Instrumentación: Diseño del Sistema de H2O Capítulo 6: Instrumentación: Diseño del Sistema de H2O Digital Media Server El video en demanda a través del web aún está restringido a las grandes empresas que pueden pagar por contar por un servicio

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA... 7 Tarea DSI 1.1: Definición de Niveles de Arquitectura... 9 Tarea DSI

Más detalles

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012 TFC J2EE Aplicación Web para la gestión de facturación de una empresa de cerrajería Sara Gutiérrez Melero ITIG Junio de 2012 Consultor: Jose Juan Rodriguez Índice 1. Introducción Objetivos Planificación

Más detalles

Aplicateca Certificados SMS

Aplicateca Certificados SMS Aplicateca Certificados SMS Manual de usuario Versión v-2 By DIDIMO Servicios Móviles INDICE INDICE...2 1 QUÉ ES CERTIFICADOS SMS?...3 2 MENÚ PRINCIPAL...5 2.1 GRUPOS...5 2.1.1 Crear Grupo...5 2.1.2 Gestión

Más detalles

Historia de revisiones

Historia de revisiones Especificación de Requerimientos de Software Versión 3.0 Historia de revisiones Fecha Versión Descripción Autor 22/08/2015 1.0 Especificación Inicial. Analistas 23/08/2015 1.1 Revisión de SQA. Correcciones

Más detalles

Práctica Java POJO de Integración de Sistemas Sitio Web de Apuestas Deportivas

Práctica Java POJO de Integración de Sistemas Sitio Web de Apuestas Deportivas Práctica Java POJO de Integración de Sistemas Sitio Web de Apuestas Deportivas Curso académico 2009-2010 1 Introducción La práctica de Integración de Sistemas consistirá en el diseño e implementación de

Más detalles

GESTIÓN DE UN SUPERMERCADO BAJO UN SERVIDOR DE ORACLE. Noemí Peña Portillo

GESTIÓN DE UN SUPERMERCADO BAJO UN SERVIDOR DE ORACLE. Noemí Peña Portillo GESTIÓN DE UN SUPERMERCADO BAJO UN SERVIDOR DE ORACLE Noemí Peña Portillo 1. Qué voy a explicar? Objetivos del proyecto. Oracle Developer Suite 10g y Componentes. Configuración de red. Oracle Designer

Más detalles

SISTEMA DE INFORMACIÓN COMERCIAL Libro de Operatividad. Solución WEB enlazada con la Gestión Corporativa / ERP

SISTEMA DE INFORMACIÓN COMERCIAL Libro de Operatividad. Solución WEB enlazada con la Gestión Corporativa / ERP SISTEMA DE INFORMACIÓN COMERCIAL Libro de Operatividad Solución WEB enlazada con la Gestión Corporativa / ERP El Sistema de Información Comercial SIC, es un software CRM orientado a suministrar al departamento

Más detalles

Grow Shop Web Grow Shop Web Especificación de Requisitos de Software (ERS) Versión 1.1.0

Grow Shop Web Grow Shop Web Especificación de Requisitos de Software (ERS) Versión 1.1.0 Grow Shop Web Grow Shop Web Especificación de Requisitos de Software (ERS) Versión 1.1.0 Francisco Pérez Pavón id 103319 Asignaturas: Comercio Electrónico y Proyectos Informáticos. Título Proyecto Especificaciones

Más detalles

TWS Charts. Presentación. Esta poderosa herramienta se empaqueta, se escala y se personaliza en la ventana de negociación.

TWS Charts. Presentación. Esta poderosa herramienta se empaqueta, se escala y se personaliza en la ventana de negociación. TWS Charts Presentación Acceso Chart Tiempo Real Parámetros Chart Componentes Ventana Herramientas Chart Chart Trader Panel Gestión Órdenes Charts Históricos Presentación Esta poderosa herramienta se empaqueta,

Más detalles

Cómo comprar en la tienda en línea de UDP y cómo inscribirse a los módulos UDP

Cómo comprar en la tienda en línea de UDP y cómo inscribirse a los módulos UDP Cómo comprar en la tienda en línea de UDP y cómo inscribirse a los módulos UDP Sistema de registro y pago Este sistema está dividido en dos etapas diferentes*. Por favor, haga clic en la liga de la etapa

Más detalles

Trabajo Final de Grado

Trabajo Final de Grado Grado en Ingeniería Informática Trabajo Final de Grado Desarrollo de una aplicación para mostrar gráficamente datos de uso del producto de realidad aumentada DOING3D Autor: Xavier Cano Ebrí Supervisor:

Más detalles

Visual Chart 6. Cotizaciones, análisis y trading 2 Departamento de formación

Visual Chart 6. Cotizaciones, análisis y trading 2 Departamento de formación 2 Departamento de formación www.visualchart.com CONTENIDO 1. VISUAL CHART. ASPECTOS GENERALES 2. CONECTAR CON EL SERVIDOR DE DATOS 3. ACCESO A LA INFORMACIÓN 3.1 Gráficos 3.2 Tablas 3.3 Profundidad de

Más detalles

Diseño del Sistema de Información

Diseño del Sistema de Información Diseño del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS...2 ACTIVIDAD DSI 1: DEFINICIÓN DE LA ARQUITECTURA DEL SISTEMA...7 Tarea DSI 1.1: Definición de Niveles de Arquitectura...9 Tarea DSI 1.2:

Más detalles

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos

Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos Práctica de Integración de Sistemas Aplicación Web.NET: Sitio de Comentarios de Eventos Deportivos 1. Introducción Curso académico 2009-2010 La práctica de Integración de Sistemas consiste en el diseño

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

Títol: Intranet Diagonal Recobros. Volum: 1/1 Alumne: Miguel Meneses Nicolau

Títol: Intranet Diagonal Recobros. Volum: 1/1 Alumne: Miguel Meneses Nicolau Títol: Intranet Dianal Recobros Volum: 1/1 Alumne: Miguel Meneses Nicolau Director/Ponent: Carles Farré Tost Departament: Lenguajes y Sistemas Informaticos Data: 22/05/2010 DADES DEL PROJECTE Títol

Más detalles

COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA

COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA Trabajo fin de carrera INGENIERÍA TÉCNICA EN INFORMÁTICA DE SISTEMAS Facultad de Matemáticas Universidad de Barcelona COUNTSTAR: ADMINISTRACIÓN Y GESTIÓN DE EMPRESA Óscar Llorente Lucía Director/a: Dra.

Más detalles

Historial de Revisiones

Historial de Revisiones Página: 1 Especificación de Requerimientos de Software Plataforma Libre Orientada a Servicios para la Gestión de Trámites a través de Gobierno Electrónico (Actualización FASE I) Historial de Revisiones

Más detalles

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases

Inicio de MO Inicio de MD Inicio de MF. Documento de Análisis. Base de datos de las especificaciones OMT. MO, MD, MF Detallados. Librería de Clases 3.2 TÉCNICA DE MODELADO DE OBJETOS (OMT) (JAMES RUMBAUGH). 3.2.1 Introducción. En este documento se trata tanto el OMT-1 como el OMT-2, el primero contenido en el Libro Modelado y Diseño Orientado (Metodología

Más detalles

ZAR FOREX. Plataforma Comercial MetaTrader 4 Manual de Usuario

ZAR FOREX. Plataforma Comercial MetaTrader 4 Manual de Usuario ZAR FOREX Plataforma Comercial MetaTrader 4 Manual de Usuario Contenido 1. Inicio Para iniciar el trabajo en la plataforma, es necesario aperturar una cuenta demo. Luego de registrarse recibirá en su correo

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

SERVICIO CREA TU WEB TELEFÓNICA NET. (Manual de usuario)

SERVICIO CREA TU WEB TELEFÓNICA NET. (Manual de usuario) SERVICIO CREA TU WEB TELEFÓNICA NET (Manual de usuario) 1 ÍNDICE 1. INTRODUCCIÓN... 3 2. CÓMO CREAR UNA TIENDA... 4 Paso 1: registro nuevo comerciante... 4 Paso 2: datos básicos web.... 5 Paso 3: diseño

Más detalles

Cálculo de calidad del suministro eléctrico y Energía y Facturación. - Manual de Usuario

Cálculo de calidad del suministro eléctrico y Energía y Facturación. - Manual de Usuario Cálculo de calidad del suministro eléctrico y Energía y Facturación. - Manual de Usuario ÍNDICE 1. INTRODUCCIÓN 2. ASPECTOS COMUNES DE LA APLICACIÓN 3. GESTIÓN 3.1. USUARIOS 3.2. ORGANIZACIONES 3.3. ASOCIACIONES

Más detalles

V. CAPÍTULO: CONTRIBUCIÓN

V. CAPÍTULO: CONTRIBUCIÓN V. CAPÍTULO: CONTRIBUCIÓN Requerimientos del Sistema Para llevar a cabo el desarrollo de nuestro sistema se establecieron tanto los actores como los requerimientos funcionales y no funcionales del sistema.

Más detalles

BackflipSD Modelo de Diseño

BackflipSD Modelo de Diseño BackflipSD Modelo de Diseño Historia de revisiones: Fecha Versión Descripción Autor 04/09/2012 1.0 Rodrigo Stecanella 16/09/2012 1.1 Rodrigo Stecanella 1 Contenido Historia de revisiones:...1 Introducción...3

Más detalles

CATÁLOGO ELECTRÓNICO PARA LA EMPRESA NERELIA TORRES PRODUCTOS INDUSTRIALES Y AGRÍCOLAS. 1 Soraya Díaz, 2 Germán Ñacato, 3 Mario Ron Egas

CATÁLOGO ELECTRÓNICO PARA LA EMPRESA NERELIA TORRES PRODUCTOS INDUSTRIALES Y AGRÍCOLAS. 1 Soraya Díaz, 2 Germán Ñacato, 3 Mario Ron Egas CATÁLOGO ELECTRÓNICO PARA LA EMPRESA NERELIA TORRES PRODUCTOS INDUSTRIALES Y AGRÍCOLAS 1 Soraya Díaz, 2 Germán Ñacato, 3 Mario Ron Egas Departamento de Ciencias de la Computación, Universidad de las Fuerzas

Más detalles

Capítulo II. Arquitectura del Software

Capítulo II. Arquitectura del Software Capítulo II. Arquitectura del Software Después de un cuidadoso análisis de los objetivos del proyecto, se determinó que la mejor manera de estructurar el sistema era haciendo uso del muy famoso patrón

Más detalles

Sistema de Movilidad de Ventas - CLOUD -

Sistema de Movilidad de Ventas - CLOUD - Planificación de un proyecto de construcción de software. Sistema de Movilidad de Ventas - CLOUD - Informe de definición 1 1 RAZÓN Y OPORTUNIDAD DEL PROYECTO.... 3 1.1 LA EMPRESA... 3 1.3 EL NACIMIENTO

Más detalles

Proyecto de Desarrollo de una Base de Datos para un concesionario

Proyecto de Desarrollo de una Base de Datos para un concesionario Proyecto de Desarrollo de una Base de Datos para un concesionario Etienne Boshoff de Jong Enginyeria en Informàtica Juan Martinez Bolaños 14 enero 2013 Proyecto Final de Carrera: Base de Datos Page 1 1.

Más detalles

Aplicateca. Guía Rápida Mensajería Negocios de Movistar/Uptiva

Aplicateca. Guía Rápida Mensajería Negocios de Movistar/Uptiva Aplicateca Guía Rápida Mensajería Negocios de Movistar/Uptiva Índice 1 Qué es Mensajería Negocios?... 2 1.1 Más detalles...... 2 1.2 Qué ventajas ofrece Mensajería Negocios?... 3 2 Requisitos técnicos...

Más detalles

TUTORIAL CAMPUS WEB EXITAE

TUTORIAL CAMPUS WEB EXITAE DOCUMENTO1 MD_UDxxxxxx_V(10)UniversidadEsp.dot TUTORIAL CAMPUS WEB EXITAE https://www.exitae.es/acceso-campus-virtual FINALIDAD El campus virtual es una herramienta de enseñanza On-Line, desarrollada

Más detalles

La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México

La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México Licencia La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México S. A de C.V., Está protegida por derechos de autor y / u otras leyes aplicables. Cualquier uso diferente a

Más detalles

MANUAL EASYCHAIR. A) Ingresar su nombre de usuario y password, si ya tiene una cuenta registrada Ó

MANUAL EASYCHAIR. A) Ingresar su nombre de usuario y password, si ya tiene una cuenta registrada Ó MANUAL EASYCHAIR La URL para enviar su propuesta a la convocatoria es: https://easychair.org/conferences/?conf=genconciencia2015 Donde aparece la siguiente pantalla: Se encuentran dos opciones: A) Ingresar

Más detalles

Alojamiento web gratuito

Alojamiento web gratuito Alojamiento web gratuito 3. Alojamiento web gratuito Sin dejar de tener en cuenta que un alojamiento web gratuito no será el más adecuado para mantener un sitio web de calidad, sí podemos disponer de alguno

Más detalles

Por Jennifer Islas. Manual de uso para Intranet

Por Jennifer Islas. Manual de uso para Intranet Por Jennifer Islas Manual de uso para Intranet Presentación El siguiente manual se ha hecho con la finalidad de que los miembros del laboratorio de átomos fríos se sirvan de una ayuda para poder gestionar

Más detalles

AVANZO LMS - Manual del Alumno

AVANZO LMS - Manual del Alumno AVANZO LMS - Manual del Alumno INDICE Descripción General 1. FUNCIONALIDADES DE LA PLATAFORMA AVANZO LMS... 1 2. REQUISITOS TÉCNICOS PARA EL USUARIO... 1 Interfaz de usuario 3. PÁGINA DE INICIO... 2 4.

Más detalles

WEBMAIL 13 de julio de 2009

WEBMAIL 13 de julio de 2009 USO DE UN WEBMAIL Índice de Mensajes Después de seleccionar una carpeta, en el marco de la izquierda se desplegará al índice de mensajes. Consiste en una lista de los mensajes contenidos por la carpeta

Más detalles

Introducción a AJAX y visión global de la práctica

Introducción a AJAX y visión global de la práctica Introducción a AJAX y visión global de la práctica Modelo de aplicaciones Web clásico (1) La mayor parte de las interacciones del usuario causan una petición HTTP al servidor Web El servidor Web procesa

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

MANUAL ONLINE. Plataforma de Teleformación INAEM

MANUAL ONLINE. Plataforma de Teleformación INAEM MANUAL ONLINE Plataforma de Teleformación INAEM Índice 1. Acceso a la plataforma 3 2. Estructura de plataforma 5 Contenidos 5 Recursos 11 3. Herramientas de colaboración y comunicación 12 Foros de Debate

Más detalles

SOLUCIÓN SITUACIÓN ACTUAL

SOLUCIÓN SITUACIÓN ACTUAL SITUACIÓN ACTUAL La necesidad de las organizaciones de ser más competitivas en un mercado dinámico ha generado estructuras organizacionales complejas y exigentes en términos de calidad y eficiencia. Sobre

Más detalles

Manual de Usuario. Junio 2013

Manual de Usuario. Junio 2013 Manual de Usuario Junio 2013 MARCAS COMERCIALES Full Network y el logotipo de Full Network son marcas registradas o marcas comerciales de Full Network, S.L. y pueden estar registradas en España o en otras

Más detalles

Gestionando Agile/Scrum con Sciforma

Gestionando Agile/Scrum con Sciforma agile Gestionando Agile/Scrum con Sciforma El desarrollo ágil de software son métodos de ingeniería del software basados en el desarrollo iterativo e incremental, donde los requerimientos y soluciones

Más detalles

Desarrollo y servicios web Sesión 18

Desarrollo y servicios web Sesión 18 Desarrollo y servicios web Sesión 18 Luisa Fernanda Rincón Pérez 2014-2 Qué son los patrones arquitectónicos? Definen la estructura de la solución al mas alto nivel. Por esto es lo primero que se tiene

Más detalles

TFC J2EE: Desarrollo de una tienda virtual. (Plan de trabajo)

TFC J2EE: Desarrollo de una tienda virtual. (Plan de trabajo) TFC J2EE: Desarrollo de una tienda virtual (Plan de trabajo) Estudiante: Asier Moreno Pascuas Titulación: ITIS Consultor: Oscar Escudero Sanchez Fecha: 12 de Marzo de 2007 Agradecimientos A mi familia,

Más detalles

APLICATECA. Guía para la contratación y gestión de. Hacemos Tu Web

APLICATECA. Guía para la contratación y gestión de. Hacemos Tu Web APLICATECA Guía para la contratación y gestión de Hacemos Tu Web INDICE 1 QUÉ ES HACEMOS TU WEB?... 1 1.1 PARA QUÉ SIRVE?... 1 1.2 CARACTERÍSTICAS DE HACEMOS TU WEB... 1 1.3 REQUERIMIENTOS DEL SERVICIO...

Más detalles

ORVE OFICINA DE REGISTRO VIRTUAL. Manual Usuario Final Versión 2.1 Fecha de revisión 26/08/2013 Realizado por Equipo de Desarrollo PHP ORVE - 2.

ORVE OFICINA DE REGISTRO VIRTUAL. Manual Usuario Final Versión 2.1 Fecha de revisión 26/08/2013 Realizado por Equipo de Desarrollo PHP ORVE - 2. ORVE OFICINA DE REGISTRO VIRTUAL Manual Usuario Final Versión 2.1 Fecha de revisión 26/08/2013 Realizado por Equipo de Desarrollo PHP ORVE - 2.1 / 1 ÍNDICE 1 ACCESO A LA APLICACIÓN... 3 2 NUEVO REGISTRO...

Más detalles

Práctica: Tienda online

Práctica: Tienda online Práctica: Tienda online José Ruiz Jiménez 14/05/2011 Contenido 1. Descripción y Características... 3 2. Configurando la aplicación y su servidor... 5 3. El modelo empleado... 7 4. El mecanismo de persistencia...

Más detalles

TUTORIAL. Introducción Email-marketing. Creación Listas de Contactos. Creación de la campaña. Resultados de las Campañas

TUTORIAL. Introducción Email-marketing. Creación Listas de Contactos. Creación de la campaña. Resultados de las Campañas TUTORIAL Introducción Email-marketing Creación Listas de Contactos Creación de la campaña Resultados de las Campañas Introducción El e-mailing se ha convertido en los últimos años en una herramienta fundamental

Más detalles

INTRODUCCION A LOS SGBD

INTRODUCCION A LOS SGBD Parte Primera: INTRODUCCION A LOS SGBD Sistemas de Gestión de Bases de Datos Tabla Tabla Type Fila Tabla Type Fila Tabla text Fila Type Fila Fila text Type Fila Tabla Tabla Fila text Fila text Fila Fila

Más detalles

INTRODUCCION AL LENGUAJE UNIFICADO MODELADO

INTRODUCCION AL LENGUAJE UNIFICADO MODELADO INTRODUCCION AL LENGUAJE UNIFICADO MODELADO Cap. 9 Kendall & Kendall Cap 2 P11 Jacobson SESION 8 Ana Mercedes Cáceres mercycaceres@gmail.com Año 2006. 1 OBJETIVOS Presentar el lenguaje de modelado UML,

Más detalles

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN

Juan de Dios Murillo Morera e-mail: jmurillo@una.ac.cr Santiago Caamaño Polini e-mail: scaamano@costarricense.cr INTRODUCCIÓN UNICIENCIA 24 pp. 83-89 2010 IMPLEMENTACIÓN DE UN SERVIDOR FTP UTILIZANDO EL MODELO CLIENTE/SERVIDOR MEDIANTE EL USO DE SOCKETS EN LENGUAJE C UNIX CON EL FIN DE MEJORAR LOS TIEMPOS DE RESPUESTA EN LA RED

Más detalles

Descripción del Proyecto Fecha: 2011-04-20

Descripción del Proyecto Fecha: 2011-04-20 Nombre el Proyecto Pesecar System Versión.1. Preparado por: Página: 1 de 35 Historia de Revisiones Fecha Versión Descripción Autor 2010-04-27 1.0 Versión Preliminar Responsable Página: 2 de 35 Tabla de

Más detalles

Tema 3: Bases de datos en Entorno Web

Tema 3: Bases de datos en Entorno Web Tema 3: Bases de datos en Entorno Web 1. Introducción. Un sistema de bases de datos proporciona un control centralizado de los datos. Esto contrasta con la situación que prevalece actualmente, donde a

Más detalles

Operating MATLAB by Internet

Operating MATLAB by Internet Operating MATLAB by Internet Bonifacio Castaño, Juan Llovet, Javier Sánchez University of Alcalá de Henares, Departament of mathematics. Abstract. In this work we demonstrate an interactive web-page, that

Más detalles