Diseño de un portal web de gestión de carteras de acciones

UNIVERSIDAD POLITÉCNICA DE VALENCIA ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA DISEÑO DE UN PORTAL WEB DE GESTIÓN DE CARTERAS DE ACCIONES DISCA-14 PROYECTO FINAL DE CARRERA Autor: Antonio Poveda González Director: Sergio Sáez Barona Valencia, 2011 1 Índice: 1. Introducción........................................................................................................ 3 2. Especificación de requisitos ...................................................................... 5 2.1. Introducción ............................................................................................... 5 2.1.1. Propósito .............................................................................................. 5 2.1.2. Ámbito.................................................................................................... 5 2.1.3. Definiciones, acrónimos y abreviaturas ............................ 5 2.1.4. Referencias.......................................................................................... 7 2.1.5. Visión global....................................................................................... 8 2.2.1. Perspectiva del producto............................................................ 8 2.2.2. Funciones del producto................................................................ 8 2.2.3. Características del usuario........................................................ 9 2.2.4. Restricciones.................................................................................... 10 2.2.5. Supuestos y dependencias ...................................................... 10 2.3. Requisitos Específicos......................................................................... 11 2.3.1. Requisitos Funcionales .............................................................. 11 3. Análisis................................................................................................................. 17 3.1. Introducción ............................................................................................. 17 3.2. Diagrama de clases............................................................................... 17 3.3. Casos de uso............................................................................................. 18 3.4. Diagramas de secuencia.................................................................... 20 4. Diseño................................................................................................................... 24 4.1. Introducción ............................................................................................. 24 4.2. Arquitectura de tres capas............................................................... 24 4.2.1. Nivel de interfaz............................................................................. 25 4.2.2. Nivel de lógica de la aplicación............................................. 28 4.2.3. Nivel de datos o persistencia................................................. 29 4.3. Diagrama entidad relación............................................................... 29 4.4. Diseño lógico............................................................................................ 30 5. Implementación.............................................................................................. 32 5.1. Tecnologías................................................................................................ 32 5.1.1. HTML...................................................................................................... 32 5.1.2. HTTP...................................................................................................... 33 5.1.3. Arquitectura cliente – servidor............................................. 33 5.1.4. PHP......................................................................................................... 34 5.1.5 CSS........................................................................................................... 34 5.1.6. jQuery................................................................................................... 35 5.1.7. MySQL................................................................................................... 35 5.2. Herramientas............................................................................................ 36 5.3. Detalles de la implementación ...................................................... 36 5.3.1. Perfiles de usuario........................................................................ 36 5.3.2. Objetos: interfaz más manejable......................................... 37 5.2.3. Persistencia de sesión del usuario...................................... 37 5.2.4. Login...................................................................................................... 38 5.2.5. Zona Usuario .................................................................................... 40 2 5.2.6. Alta Usuario (JavaScript) ......................................................... 40 5.2.7. Gráficos con amCharts: Estado actual.............................. 42 5.2.8. JQuery: Selector de fecha ........................................................ 43 6. Evaluación y pruebas................................................................................... 46 6.1. Evaluación.................................................................................................. 46 6.2 Pruebas ......................................................................................................... 46 6.2.1. Pruebas de Validación HTML y CSS..................................... 46 6.2.2. Pruebas de compatibilidad en navegadores ................. 47 6.2.3. Pruebas de compatibilidad de resolución....................... 48 6.2.4. Pruebas unitarias .......................................................................... 49 • Proceso de introducción de operaciones........................... 50 • Estado actual...................................................................................... 54 • Listado de operaciones ................................................................ 55 • Información Fiscal .......................................................................... 55 7. Conclusión.......................................................................................................... 58 7.1. Trabajo realizado................................................................................... 58 7. 2. Valoración personal............................................................................ 58 7.3. Posibles ampliaciones......................................................................... 59 8. Bibliografía......................................................................................................... 61 3 1. Introducción Muchos bancos no ofrecen una plataforma sencilla donde poder analizar, detallar o consultar los movimientos que se realizan en bolsa. A veces se limitan a mostrar los resultados tal y como los trata Hacienda. Y nosotros, de vez en cuando, queremos darle otro enfoque. El propósito de este proyecto es el desarrollo de una aplicación Web específica para la administración de carteras de valores. La aplicación permitirá al usuario simular carteras o fondos de inversión y crear operaciones bursátiles con títulos que cotizan en el Ibex 35. Estas operaciones podrán consultarse, así como mostrar estadísticas personalizadas, resúmenes, consultas, etc. Cabe destacar que la aplicación no emite órdenes reales sobre el mercado. Simplemente es una herramienta de gestión de operaciones que pueden ser reales o ficticias. En cuanto al contexto del proyecto, por un lado, puede ser una herramienta de ayuda para aquellas personas que operan en Bolsa en la realidad. El usuario dará de alta las operaciones que ha realizado, a priori, en el mercado, introduciendo los datos que le faciliten su broker o el banco. Por otro lado, se quiere atraer al mayor número de usuarios posible, y no es necesario ser accionista real. Además de que cuenta con una estructura clara y sencilla, con esta aplicación podremos convertirnos en inversores ficticios, insertando las operaciones de la misma manera que si las hubiéramos hecho de verdad. Puede ser interesante, por ejemplo, para aquellas personas que quieren invertir en bolsa, pero aun no conocen la operativa, no se atreven, etc. Esta herramienta puede ser muy útil como primera aproximación. El documento que se presenta se divide en diferentes capítulos, y se corresponden con las fases del desarrollo de software tradicional. A continuación se describe la estructura de la memoria: Tras la introducción, el segundo capítulo se centra en la especificación de requisitos, detectando los requisitos que debe tener el software. Por otro lado, se explican a fondo todos los objetivos del sistema, además de comentar todos los tipos de restricciones que ha tenido que respetar el proyecto. El tercer capítulo, análisis, trata de explicar los aspectos generales del software, utilizando el lenguaje de modelado UML. Se 4 exponen aspectos que tienen que ver con la funcionalidad, la estructura y el comportamiento del software. En el cuarto capítulo, referente al diseño, se indica cómo se ha puesto solución a los requisitos. También se explica la estructura armada para realizar el proyecto, la definición de capas y qué componentes se han usado. El quinto capítulo se centra en la parte de implementación, donde se ilustra tanto de qué se ha implementado como de los problemas que se tuvieron y las soluciones que se aplicaron. El sexto capítulo hace referencia a las posibles pruebas a las que debe someterse la aplicación, cómo documentarlas y sus resultados. En el último capítulo se valoran las conclusiones y experiencias extraídas, se compara el resultado con los objetivos iniciales, se documenta el trabajo realizado, y además se dan ideas sobre posibles mejoras de la aplicación. 5 2. Especificación de requisitos 2.1. Introducción En este apartado se describen el propósito, ámbito, definiciones, acrónimos y abreviaturas, las referencias de la especificación de requisitos y la visión global del producto. 2.1.1. Propósito El propósito de la especificación de requisitos es servir de base para desarrollar la aplicación Web. También sirve para detallar los requisitos de diseño de interfaz, contenidos y funcionalidad de la misma. Así como la definir claramente los objetivos que se pretenden conseguir. 2.1.2. Ámbito El producto que se describe a continuación desempeña el papel de una aplicación Web encargada de gestionar las acciones de una o varias carteras de valores. Se abordan todos los aspectos de la gestión de acciones: introducir las operaciones, gestión de carteras, y también mostrar las operaciones y sacar resultados, cálculo de rentabilidad, plusvalías, etc. Las operaciones no son en tiempo real, son un reflejo de las operaciones que el usuario ha podido hacer en la realidad, o bien operaciones ficticias. 2.1.3. Definiciones, acrónimos y abreviaturas Definiciones: Canje: Es una operación de bolsa en la cual el inversor recibe las acciones de un valor a cambio de otro valor ya sea porque va a desaparecer, va a ser absorbido por otra empresa, u otro motivo. Cliente: Usuario final que accede a un servicio remoto en otro ordenador, llamado servidor. Dividendo: Operación bursátil en la cual la empresa reparte el beneficio anual obtenido entre sus inversores. Ibex 35: Nombre como se conoce al índice español de referencia, compuesto por las 35 empresas españolas con más liquidez. 6 Login: Es el nombre con el que se identifica a un usuario, que con anterioridad ha realizado un proceso de registro. En nuestra aplicación no tendrá ninguna distinción entre roles, sólo hay un tipo de usuario. Navegador: Aplicación para navegar por Internet y para visualizar documentos HTML. Norma antiaplicación: Es una norma puesta por Hacienda Pública. Dice que si se venden acciones perdiendo dinero y dos meses antes o después de la venta, existe una compra, Hacienda entiende que son las mismas acciones y por tanto no permite que esa pérdida compense con otras ganancias. Password: Es el texto que sirve como código secreto de acceso, va relacionado con el Login. Servidor: Ordenador que se encarga de ejecutar la aplicación y de servir los recursos y páginas a los usuarios o clientes. Split: Es una operación bursátil. Significa que la empresa va a dividir el precio de la acción voluntariamente, a cambio, el inversor recibirá más acciones con el mismo ratio. Usuario anónimo: Usuario que visita la Web y del cual no se tiene ningún tipo de información guardada. No puede realizar operaciones, sólo consultar el mercado. Usuario registrado: Usuario que ha realizado el proceso de registro en la Web, de forma que se dispone de información personal para identificarlo y personalizar su visita a la Web. Acrónimos y abreviaturas: CSS: Hojas de estilo en cascada (Cascading Style Sheets), es un lenguaje empleado para definir la presentación de un documento escrito en HTML, XHTML o XML. HTML: Lenguaje de marcado de hipertexto (HyperText Markup Language). Es el principal lenguaje utilizado en las páginas web para describir su contenido y apariencia. HTTP: Protocolo de transferencia de hipertexto (HyperText Transfer Protocol), es el método de intercambio de información en la Web más utilizado. 7 JavaScript: es un lenguaje interpretado ligero y sin tipos de datos, utilizado para acceder a objetos en aplicaciones y que no requiere compilación. MySQL: Es un sistema de gestión de base de datos relacional, multihilo y multiusuario. PHP: Es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas Web dinámicas, usado en el lado del servidor. SQL: Lenguaje de consulta estructurado (structured query language), es un lenguaje declarativo de acceso a bases de datos relacionales que nos proporciona la posibilidad de precisar diversos tipos de operaciones en estas. UML: Lenguaje Unificado de Modelado, es un lenguaje gráfico utilizado para construir, documentar, visualizar y especificar un sistema software. WAMP: Usado para describir un sistema de infraestructuras de Internet que utiliza las herramientas siguientes: Windows como sistema operativo, Apache como servidor Web, MySQL como gestor de base de datos y PHP como lenguaje de programación. Web: World Wide Web (WWW), es la red de redes, un medio de comunicación de texto, gráficos y multimedia a través de Internet. 2.1.4. Referencias - BUENDIA GARCÍA, FÉLIX. Guía para la realización y supervisión de proyectos de final de carrera (PFC) en el ámbito de la web. Valencia, Editorial UPV. - Apuntes ISG. Esquemas y temario. http://poliformate.upv.es Accedido Junio de 2011 - Diccionario de la Real Academia Española. http://rae.es Accedido Agosto de 2011. - Diccionario. http://wordreference.com Accedido Agosto de 2011. - Wikipedia. Definiciones. http://es.wikipedia.org Accedido en Agosto 2011. 8 2.1.5. Visión global Vamos a centrar la especificación de requisitos en la descripción de la aplicación, sus características, sus restricciones generales, sus funciones, sus supuestos y dependencias, que son las que nos aportarán una mayor información del proyecto a desarrollar. Cuando terminemos de desarrollar la descripción general, pasaremos a la descripción de los requisitos específicos de nuestra aplicación. 2.2. Descripción general 2.2.1. Perspectiva del producto La aplicación pretende ser un portal Web para la administración de las carteras de valores de los usuarios de dicho portal. Así pues, realizará los cometidos básicos propios de un portal de gestión de carteras tales como alta, baja y modificación de éstas. La modificación de las carteras se realiza básicamente con la gestión de las operaciones asociadas a una acción determinada que está sujeta a negociación en el mercado de valores. Aunque el producto se conecta a otra aplicación Web para recoger datos en tiempo real, podemos decir que la aplicación es dependiente, ya que esto no afecta a la gestión propia del producto y, en el supuesto caso de no disponer de la aplicación externa, la mayoría de la funcionalidad se ejecutaría correctamente. 2.2.2. Funciones del producto -Función de consulta en tiempo real del Ibex 35: La aplicación se conecta a una aplicación Web externa, traerá y almacenará los datos de las cotizaciones del selectivo español. La aplicación mostrará siempre estos datos hasta que vuelvan a ser actualizados a petición del usuario, directa o indirectamente. Esta función la puede realizar cualquier tipo de usuario. -Funciones de gestión de operaciones: Esta función está disponible sólo para usuarios registrados y que previamente hayan dado de alta una cartera. Mediante la gestión de las operaciones, la cartera se constituye con determinadas acciones. Los tipos de operaciones disponibles serán: compra y venta, dividendos, canjes y splits. 15 Visualización de la información Fiscal: Propósito: Pretende ser una ayuda para el cálculo de las ganancias y pérdidas patrimoniales consecuentes de la operativa de las acciones de la cartera. Se utiliza el método FIFO (primera entrada, primera salida), ya que así es como las trata Hacienda en la declaración. También se tiene en cuenta la “norma antiaplicación” para las compras anteriores o posteriores a los 2 meses de la venta con pérdida. Entrada: Listado de todos los valores de la cartera de los cuales están en una operación de venta Proceso: Para cada valor: Listado de todas sus operaciones. Para cada operación: - Si es una venta, buscar las compras que le corresponden en base al volumen de la venta y almacenar una plusvalía en euros para esa asociación. Si la venta tiene pérdidas, buscar compras 2 meses atrás y 2 meses adelante. Si hay, se considera recompra y restar a la minusvalía el importe de la pérdida que no se puede imputar, y guardarla en un vector. Si la venta genera plusvalía o un volumen actual de 0 en la cartera, y no hay compra en los 2 meses posteriores, imputarle las pérdidas que hay almacenadas de operaciones anteriores. - Si es un dividendo, calcular el importe total. (Siempre tendrá plusvalía positiva). - Si es un split o canje, multiplicar el volumen actual por el valor de cambio, para saber el nuevo volumen del título. En el caso del canje, borrar en las compras el valor absorbido, ya que no habrá operación de venta de ese valor. Salida: Una tabla por cada valor, con las asociaciones Compra-Venta encontradas, su plusvalía y ganancia/pérdida patrimonial correspondiente. La suma total de cada título en cartera. Visualización de beneficios de la cartera: Propósito: Idéntico al anterior, excepto que se utilizará un algoritmo LIFO (ultimo en entrar, primero en salir) con lo que los resultados pueden llegar a variar. Tampoco se tiene en cuenta la “norma antiaplicación” ya explicada. 16 Entrada: Idéntico al anterior. Proceso: Idéntico con las restricciones nombradas. Salida: Idéntico al anterior. Modificación de datos del usuario: Propósito: Opción en la zona de usuario para modificar datos propios del usuario tales como teléfono, e-mail o contraseña. Entrada: Nombre, apellidos, e-mail, teléfono, dirección, contraseña Proceso: El sistema actualiza los datos pasados. Salida: - 17 3. Análisis 3.1. Introducción El análisis es la construcción de un modelo o especificación detallada del problema del mundo real. Un buen desarrollo de software debe dedicar un alto porcentaje de los recursos exclusivamente a la etapa de análisis. El análisis constituye una de las actividades primordiales, donde se analizan todas las consideraciones técnicas del proyecto, así como la comprensión y solución del problema que se plantea. Se debe desarrollar con profundidad el análisis para evitar errores de diseño difíciles de solucionar. No entender la funcionalidad o una mala comunicación con el cliente una vez está terminado el producto, provoca un error en todas las siguientes etapas del desarrollo, con lo cual es un problema grave. La notación que se va a utilizar es la proporcionada por el estándar UML. En nuestro proyecto se usarán los casos de uso, diagramas de clases y algunos diagramas de secuencia. 3.2. Diagrama de clases El primer paso va a ser la realización del diagrama de clases, que es el diagrama principal para el modelado orientado a objetos. Representa las clases del sistema junto con sus relaciones y atributos. Con el diagrama de clases entenderemos qué funciones se pueden llevar a cabo y quien las realiza. Cómo se pueden desarrollar dichas funciones y qué tipo de objetos interactúan entre sí. Hay dos tipos de usuarios, el usuario anónimo, es el más básico. Sólo podrá consultar y actualizar los valores del Ibex 35 aparte de registrarse. Está muy limitado. El usuario registrado es una especialización del anónimo, que podrá llevar a cabo toda la funcionalidad del sistema si tiene creada alguna cartera. 18 Figura 3-1. Diagrama de clases 3.3. Casos de uso Un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software. La utilidad de los casos de uso es capturar las funcionalidades del sistema. Cada caso se compone de uno o más escenarios que representan cómo interactúan los usuarios con el sistema. La creación de los casos de uso se realiza junto al cliente, por tanto los casos no tienen que ser técnicos, ya que el cliente no dispondrá de conocimientos de Ingeniería Informática. Un Caso de Uso es una interacción cliente-software. Los usuarios del sistema son llamados actores. Los actores siempre son entidades externas al sistema, los cuales suelen desempeñar un rol, como podría ser usuario, administrador… Estos 19 deberán realizar ciertas acciones para poder conseguir sus objetivos, cada uno de los objetivos quedan representado como un Caso de Uso. En el siguiente diagrama mostramos el caso de uso realizado para nuestro proyecto: Figura 3-2. Casos de uso La Figura 3-2 muestra los dos tipos de usuarios ya comentados en la sección anterior. Vemos como el usuario anónimo sólo puede hacer 20 tres cosas: registrarse y consulta o petición de actualización de datos del Ibex 35. El registrado puede hacer cualquier cosa: Operar con acciones y con cualquiera de los tipos: Compra, venta, etc. Gestionar sus carteras, dando de alta o baja. Al hacer un alta de una cartera es opcional marcarla como principal y si se indica hay que llamar a esa funcionalidad. También tiene acceso a todo el tema de la visualización: Operaciones, estado actual e información Fiscal. Por último, también puede modificar sus datos por si han cambiado. 3.4. Diagramas de secuencia Muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada método de la clase. El diagrama de secuencia tiene pequeños detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes o avisos que se producen en la interacción. Se examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Alta Cartera En este escenario se pide los datos en un formulario de alta de una cartera. Nombre, descripción, y si será principal. El sistema rellena los datos dando de alta una nueva cartera y devuelve una confirmación al usuario. 21 Registrarse El formulario de registro sólo está accesible si el usuario no está autentificado. Comprueba que ningún dato esté en blanco y que el nombre de usuario no está ya registrado en la base de datos, puesto que es único. Si el nombre de usuario no está ocupado, devuelve una confirmación y crea el usuario. Si no, lanza un aviso. Login La ventana de identificación es para los usuarios que previamente se han registrado. Con el nombre de usuario y el password podrá entrar a todo el menú de la aplicación web. 22 Comprar Cuando el usuario abre el formulario para comprar, el sistema muestra todos los valores que existen. El usuario elige uno y rellena el resto de datos: Volumen, precio, fecha, etc. El sistema rellena los datos y genera una operación de compra. En el caso de una compra no hay comprobaciones, para otras operaciones sí según qué caso. Seleccionar cartera principal El formulario para seleccionar la cartera principal es muy sencillo. El sistema muestra primero al usuario todas sus carteras, indicando cual es la principal actualmente, si la hay. Entonces el usuario puede marcar otra cartera como la principal, y al darle al botón de “Aceptar”, el sistema sustituirá la cartera principal. A partir de ahora el usuario trabaja con la nueva cartera seleccionada. 23 Filtrar Operaciones El formulario de búsqueda de operaciones tiene cuatro filtros, fecha de inicio, fecha de fin, valor, y tipo de operación. Se pueden combinar para filtrar las operaciones deseadas por el usuario. Si no se marca nada, el sistema traerá todas las operaciones de la cartera principal. 24 4. Diseño 4.1. Introducción Este capítulo se centrará en describir el proyecto con mayor nivel de especificación que en el capítulo anterior. A partir de los modelos de los diagramas, casos de uso y demás elementos UML de la fase de análisis, se plantea como se lleva a cabo la implementación del producto pero sin entrar de lleno en las particularidades de una determinada tecnología. Ésta fase se abstrae aún de esos detalles. Pasamos a describir con detalle la arquitectura que se ha construido para este proyecto, teniendo en cuenta el entorno Web y un esquema basado en cliente-servidor 4.2. Arquitectura de tres capas La estructura de nuestra aplicación Web se basa en una arquitectura multicapa de tres capas. Una arquitectura multicapa es un conjunto ordenado de subsistemas, cada uno de los cuales está constituido en términos de los que tiene por debajo y proporciona la base de la implementación de aquellos que están por encima de él. Los objetos de cada capa suelen ser independientes, aunque pueden existir dependencias. - Nivel de Interfaz, también llamada como capa de presentación, porque se encarga de la presentación de los resultados al usuario y la recogida de información que el usuario introduce. - Capa de negocio o lógica de la aplicación, proporciona la funcionalidad de la aplicación. Se denomina capa de negocio o lógica de la aplicación a donde residen los programas que se ejecutan, se reciben las peticiones del usuario y se envían las respuestas tras el proceso. Aquí es donde se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, y con la capa de persistencia, para solicitar al gestor de base de datos almacenar o recuperar datos de él. - Nivel de almacenamiento o persistencia, este nivel es el encargado de que los datos persistan entre diferentes ejecuciones del 31 CAJ {fkValorD}  Valor CAJ {fkCartera}  Cartera Split(id:int(10), cambio:double, fecha:timestamp, fkValor:int(10), fkCartera: int(10)) CP: {id} VNN: {cambio, fecha, fkValor, fkCartera} CAJ {fkValor}  Valor CAJ {fkCartera}  Cartera 32 5. Implementación Después de comprobar en capítulos anteriores cómo se permitía describir en los diversos niveles en que se puede descomponer un proyecto Web, este capítulo pretende mostrar la forma en que las tecnologías que han sido usadas intervienen en la implementación de estos niveles. 5.1. Tecnologías Para poder realizar toda nuestra aplicación hemos utilizado distintas tecnologías y lenguajes de programación. Para ello se ha optado por instalar WAMP Server 2.13.3, que se compone de las siguientes tecnologías: - Apache versión 2.2.17 en versión Web - PHP versión 5.3.5 lenguaje de programación interpretado. - MySQL, 5.5.8 junto con phpmyadmin 3.3.9 que nos permite la creación y gestión de nuestras bases de datos. - En el diseño de interfaces hemos utilizado el lenguaje HTML 4.0 y CSS. - Javascript se ha utilizado para la comprobación de formularios, comprobar campos que se rellenen con espacios en blanco o vacíos, y además, cálculos sobre campos de texto del importe de las operaciones. - Se ha utilizado jQuery 1.6.3, que es una biblioteca de JavaScript, para realizar la entrada de fechas por formulario de manera más fácil y vistosa. También para recargar datos sin tener que volver a recargar toda la página entera. - amCharts. Librería gráfica de PHP que se ha utilizado para sacar el gráfico de desglose patrimonial en el menú de estado actual. 5.1.1. HTML HTML, siglas de HyperText Markup Language («lenguaje de marcado de hipertexto»), es un lenguaje de marcación de elementos para la creación de documentos hipertexto, es el lenguaje predominante para la elaboración de páginas web. Es usado para describir la estructura y el contenido en forma de texto. HTML se escribe en forma de “etiquetas”, rodeadas por corchetes angulares 33 (<,>). HTML también puede describir, hasta un cierto punto, la apariencia de un documento, y puede incluir scripts, el cual puede afectar el comportamiento de navegadores Web y otros procesadores de HTML. HTML también es usado para referirse al contenido del tipo de MIME text/html o todavía más ampliamente como un término genérico para el HTML, ya sea en forma descendida del XML (como XHTML 1.0 y posteriores) o en forma descendida directamente de SGML (como HTML 4.01 y anteriores). 5.1.2. HTTP Hypertext Transfer Protocol o HTTP (en español protocolo de transferencia de hipertexto) es el protocolo usado en cada transacción de la World Wide Web. HTTP define la sintaxis y la semántica que utilizan los elementos de software de la arquitectura web (clientes, servidores, proxies) para comunicarse. Es un protocolo orientado a transacciones y sigue el esquema petición-respuesta entre un cliente y un servidor. Al cliente que efectúa la petición (usualmente un navegador Web) se lo conoce como agente de usuario A la información transmitida se la llama recurso y se la identifica mediante un localizador uniforme de recursos (URL). Los recursos pueden ser archivos, el resultado de la ejecución de un programa, una consulta a una base de datos, la traducción automática de un documento, etc. HTTP es un protocolo sin estado, es decir, que no guarda ninguna información sobre conexiones anteriores. El desarrollo de aplicaciones Web necesita frecuentemente mantener estado. Para esto se usan las cookies, que es información que un servidor puede almacenar en el sistema cliente. Esto le permite a las aplicaciones web instituir la noción de "sesión", y también permite rastrear usuarios ya que las cookies pueden guardarse en el cliente por tiempo indeterminado. 5.1.3. Arquitectura cliente – servidor La arquitectura cliente-servidor es un modelo de aplicación distribuida en el que las tareas se reparten entre los proveedores de recursos o servicios, llamados servidores, y los demandantes, llamados clientes. Un cliente realiza peticiones a otro programa, el servidor, que esperan peticiones y dan respuestas. En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las 34 ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema. La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores Web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos a otros, la arquitectura básica es la misma. En este proyecto se usará un servidor Web. La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico. 5.1.4. PHP PHP es un lenguaje de programación interpretado, diseñado originalmente para la creación de páginas web dinámicas. Aunque pede ser utilizado desde una línea de comandos, en este proyecto se usará para la interpretación del lado del servidor (server-side scripting). Puede ser desplegado en la mayoría de los servidores Web y en casi todos los sistemas operativos y plataformas sin costo alguno. Es uno de los lenguajes más utilizados en la red, el cual nos permite la realización de páginas Web dinámicas de forma sencilla y potente. Cuando el cliente hace una petición al servidor para que le envíe una web, el servidor ejecuta el intérprete de PHP. Éste procesa el script php solicitado que generará el contenido de manera dinámica (por ejemplo obteniendo información de una base de datos). El resultado es enviado por el intérprete al servidor, quien a su vez se lo envía al cliente. 5.1.5 CSS CSS es un lenguaje de hojas de estilos creado para controlar el aspecto o presentación de los documentos electrónicos definidos con HTML y XHTML. CSS es la mejor forma de separar los contenidos y su presentación y es imprescindible para crear páginas web con un mínimo de complejidad. Separar la definición de los contenidos y la definición de su aspecto presenta numerosas ventajas, ya que obliga a crear documentos HTML bien definidos y con significado completo (también 35 llamados "documentos semánticos"). Además, mejora la accesibilidad del documento, reduce la dificultad de su mantenimiento y permite visualizar el mismo documento en infinidad de dispositivos diferentes. Al crear una página web, se utiliza en primer lugar el lenguaje HTML/XHTML para marcar los contenidos, es decir, para designar la función de cada elemento dentro de la página: párrafo, titular, texto destacado, tabla, lista de elementos, etc. Una vez creados los contenidos, se utiliza el lenguaje CSS para definir el aspecto de cada elemento: color, tamaño y tipo de letra del texto, separación horizontal y vertical entre elementos, posición de cada elemento dentro de la página, etc. 5.1.6. jQuery jQuery es una biblioteca o framework de JavaScript que permite simplificar la manera de interactuar con los documentos HTML, manipular el árbol DOM, manejar eventos, desarrollar animaciones y agregar interacción con la técnica AJAX a páginas web. Es un software libre y de código abierto, posee un doble licenciamiento bajo la Licencia MIT y la Licencia Pública General de GNU v2. Al igual que otras bibliotecas, ofrece una serie de funcionalidades basadas en JavaScript, que de otra manera requerirían de mucho más código, es decir, con las funciones propias de esta biblioteca se logran grandes resultados en menos tiempo y espacio. 5.1.7. MySQL MySQL, Structured Query Languaje, es un sistema de gestión de base de datos relacional multihilo y multiusuario. Las bases de datos relacionales almacenan los datos en tablas separadas y proporciona velocidad y flexibilidad. Las tablas pueden estar enlazadas mediante relaciones, por tanto es posible combinar datos de varias tablas cuando realizamos una consulta. Este software es de código abierto, open source. 36 5.2. Herramientas Las herramientas utilizadas en el desarrollo de este proyecto han sido: - WAMP versión 1.7.3, funcionando bajo Windows XP Service Pack 3. -Con NetBeans 6.9.1 se ha construido toda la parte de programación HTML, PHP, CSS y JavaScript. -Para la creación del título, botones y retocar imágenes se ha utilizado el Gimp. Respecto a la gestión de la base de datos se ha utilizado phpmyadmin. Es una herramienta escrita en PHP con la intención de manejar la administración de MySQL a través de páginas web. Se pueden crear y eliminar Bases de Datos, crear, eliminar y alterar tablas o campos y ejecutar cualquier sentencia SQL. -StarUML: Es una herramienta para el modelado de software basado en los estándares UML y MDA (Model Driven Arquitecture), que en un principio era un producto comercial y pasó a ser uno de licencia abierta GNU/GPL. Con esta herramienta se han desarrollado los casos de uso, los diagramas de secuencia y el diagrama de clases. 5.3. Detalles de la implementación 5.3.1. Perfiles de usuario Perfil de usuario anónimo Este perfil es el que aparece siempre que la persona inicie la aplicación. Sólo puede realizar las acciones de consulta de las cotizaciones del Ibex 35 y su actualización, además de contar con la posibilidad de registrarse o identificarse. A pesar de que es deseable que este perfil de usuario pueda interactuar más con la aplicación, para familiarizarse con ella, su funcionalidad está limitada puesto que se necesita que el usuario esté registrado para poder operar carteras o visualizar datos, trabajando sobre una cartera creada. 37 Una vez esté registrado, la opción de registro desaparecerá. Perfil de usuario registrado Si el usuario se ha registrado, podrá realizar todas las funciones del proyecto descritas en este documento mediante una identificación. 5.3.2. Objetos: interfaz más manejable El proyecto ha sido desarrollado con una pequeño enfoque orientado a objetos. Se ha definido un objeto para cada tabla de la base de datos. En vez de construir la conexión, la consulta y recorrer las filas con el puntero fetch de jdbc, lo que se hace es llamar a un método de una clase php, por ejemplo, “usuarioUtils.class.php”. Dicha clase contiene todos los métodos que están relacionados con el objeto “Usuario” y que realizarán las operaciones en la base de datos. Estos métodos devolverán el objeto o una lista de objetos, con todos sus datos listos para ser “usados” con una simple llamada al método get() del atributo. Las clases de utilidades se encuentran en la carpeta “logica” del proyecto, y se puede considerar como una subcapa dentro de la lógica de la aplicación, para comunicarse con la capa de persistencia. El resultado es que el código queda mucho más limpio, conciso, intuitivo y manejable. Con esto, me he centrado mejor a la hora de desarrollar el diseño de la Interfaz de usuario. Aparte de que el código queda mucho más reutilizable y ligero, porque hay métodos que son llamados desde distintas interfaces, también vendrá bien en el supuesto caso de que haya mejoras en la aplicación. 5.2.3. Persistencia de sesión del usuario Se manejan las sesiones de usuario del navegador para que la aplicación pueda mantener la coherencia de los datos del usuario desde que éste se identifica hasta que desconecta. Con las sesiones también garantizamos restringir el acceso a la información de cualquier usuario de la base de datos a personas no autorizadas que intenten introducir a mano los parámetros mediante la URL o mediante otras artimañas. 38 Si la sesión con el identificador de usuario está rellenada, el usuario está conectado. Sino, se redirige a la página principal. También se podría poner un aviso de acceso no autorizado, etc. <?php session_start(); $idu = -1; if (isset($_SESSION['idusuario']) != 0) { $idu = $_SESSION['idusuario']; $ncartera = $_SESSION['ncartera']; $nusuario = $_SESSION['nusuario']; } else { header('Location: /ecartera/index.php'); } ?> 5.2.4. Login En el fichero login.php se pasan los parámetros Usuario y contraseña por el formulario y se recogen. Primero, se comprueba si existe el usuario con la función “existeUsuario”. Si no existe, mostramos un error. Si existe, se comprueba que ese usuario coincida con el password. Si coincide, el usuario pasará a estar identificado, dejará de ser anónimo, modificando las variables de sesión a través de otras dos funciones que traen, el nombre de usuario a partir de su identificador, y su cartera principal. <?php if (isset($_POST['enviar'])) { include('conexion.inc.php'); include('logica/usuarioUtils.class.php'); include('logica/carteraUtils.class.php'); $usuario = $_POST['usuario']; $passw = $_POST['password']; $conexion = conectarse(); $existe = existeUsuario($conexion, $usuario); if($existe == true){ $idu = login($conexion, $usuario, $passw); if ($idu == -1) { $error = "Error, contraseña incorrecta."; } else { $_SESSION['idusuario'] = $idu; $_SESSION['nusuario'] = getNombreUsuarioById($conexion, $idu); 39 $cartera = getObjetoPrincipalCarteraDeUsuario($conexion, $idu); $_SESSION['ncartera'] = $cartera->getNombre(); header('Location: /ecartera/index.php'); } }else{ $error = "Error, usuario inexistente."; } cerrarConexion($conexion); } echo $error ?> <form action="login.php" method="POST"> <label>Usuario: </label><input type="text" name="usuario" value="" /><br> <label>Contraseña: </label><input type="password" name="password" value="" /><br> <input class="buttonForm" type="submit" name="enviar" value="Login" /> </form> Y estas son las funciones “login” y “usuarioExiste” de la clase de utilidades. <?php function login($conexion, $nick, $pass) { $consulta = "SELECT * from Usuario where usuario='" . $nick . "' AND password='" . $pass . "'"; $res = mysql_query($consulta, $conexion) or die(mysql_error()); $numres = mysql_num_rows($res); $id = -1; if ($numres > 0) { $row = mysql_fetch_assoc($res); $id = $row['id']; } return $id; } ?> 40 5.2.5. Zona Usuario Este código es una plantilla que será llamada desde todas las páginas de la aplicación. Es una pequeña región de la página en el marco superior izquierdo, que te indica en todo momento la cartera actual con la que estamos trabajando. <!-- Zona Usuario--> <div id ="usuario"> <?php if ($idu != -1) { echo "Bienvenido, " . $nusuario . ". <br> "; $var; if ($ncartera != "") { $var = " La cartera actual es " . $ncartera; } else { $var = "No hay cartera seleccionada"; } echo $var; ?> <br><a href="/ecartera/logout.php">Desconectarse</a> <?php } ?> </div> <!-- FIN Zona Usuario--> 5.2.6. Alta Usuario (JavaScript) Esta es la parte php de la función de alta de usuario. Se recogen los parámetros y se llama a la funcion “altaUsuario”. Si tiene éxito el usuario se ha insertado y se redirige a la página principal. Si el usuario existe, muestra una advertencia. Los campos son comprobados previamente mediante JavaScript. Se comprueba campo a campo porque queremos que ante un fallo en el registro, indique los campos no válidos en rojo, En este caso se ha asignado al atributo “class” del formulario el texto “textFieldFallo”, para ser referenciado desde la hoja de estilo. <?php if (isset($_POST['enviar'])) { include('conexion.inc.php'); include('logica/usuarioUtils.class.php'); //recogida de parametros 47 Figura 6-1. Validación de un archivo HTML 6.2.2. Pruebas de compatibilidad en navegadores Se han pruebas en los siguientes navegadores: -Mozilla Firefox 6.0.2: Es el navegador predeterminado con el cual se ha diseñado la aplicación, aparece todo correctamente. -Opera 11.51: La anchura de las listas desplegables (comboBox) no es la correcta. Coge la anchura de la opción de la lista más larga, sin hacer caso a la hoja de estilo. Los bordes de las filas de las tablas no aparecen. Además, las opciones del menú no aparecen con los cantos ligeramente redondeados como toca. -Google Chrome 14.0.835.186: 48 Pasa lo mismo con las listas desplegables que en Opera. -Safari 5.1: Pasa lo mismo con las listas desplegables y los bordes de las tablas tampoco aparecen. El resto todo bien. -Microsoft Internet Explorer 8: Este navegador además de hacer lo mismo con las listas desplegables y no redondear los bordes, tampoco reconoce el gradiente del menú contextual. Por lo demás todo bien, se comporta mejor de lo que esperaba. Figura 6-2. Imagen tomada desde Microsoft Internet Explorer 8 6.2.3. Pruebas de compatibilidad de resolución Aunque la aplicación se ha probado en diferentes resoluciones y funciona correctamente, no se recomiendan resoluciones menores a 1024 x 768. Con resoluciones mayores no se presentan diferencias. A partir de esta resolución o menor, las tablas de información Fiscal o de operaciones que son las tablas más anchas, a veces descuadran 49 del ancho del contenedor general de la página, pero no es nada importante ya que son unos pocos píxeles. Tampoco se recomiendan estas resoluciones tan bajas porque se ve todo muy grande y aunque podemos disminuir el tamaño de la visualización con la rueda del ratón, sigue siendo muy engorroso, como vemos en la Figura 6-3, ejemplo de resolución a 800 x 600. Figura 6-3. Visualización con resolución 800 x 600 en IE8 6.2.4. Pruebas unitarias En este apartado probaremos individualmente y una por una todas las distintas funcionalidades de la aplicación para comprobar que funcionan correctamente. Probaremos cada funcionalidad en todas las diversas situaciones que se puedan dar, y además, simularemos posibles errores del usuario en la introducción y flujo de datos. La aplicación debe de estar correctamente preparada para cualquier eventualidad, mostrando un mensaje de aviso si no está preparada para ello o hay algún tipo de error, explicándolo en un lenguaje natural y sugiriendo soluciones. Por razones de extensión, vamos a plasmar sólo cuatro ejemplos de los casos de uso, paso a paso, para que a la vez que los probamos nos sirva como demostración o como manual de la aplicación. Los casos de uso elegidos son: Operar (Compra y venta), 50 estado actual, listado de operaciones y información fiscal.Representan los casos de uso más frecuentes en la operativa, lo que significa que es el flujo de datos más común. • Proceso de introducción de operaciones Una vez logueados en la aplicación, tenemos que asegurarnos sobre qué cartera vamos a trabajar. Se ha definido una cartera llamada “Demo”. Una vez tengamos la cartera deseada, nos dirigimos al apartado del menú contextual “Comprar”. Allí aparece el formulario de alta de la operación. Vamos a coger por ejemplo el valor “BBVA”, pero puede valor cualquiera que no tenga operaciones antes. Figura 6-4. Introducción del valor Indicamos Fecha 1 de Junio de 2011 a un precio de 9 euros la acción, un volumen de 200 acciones y aceptamos. Nótese que el sistema indica el importe, es decir lo que nos cuesta en total automáticamente. (9x200 = 1800 euros). Vamos a obviar las comisiones para simplificar, pero se pueden indicar para tener en cuenta, con lo que se restarían a los 1800 euros. Le damos a aceptar y compramos. Observar como se ha creado la compra en el historial reciente de BBVA, a la derecha. 51 Figura 6-5. Historial BBVA tras la operación Ahora nos vamos al apartado “Vender” del menú. Vamos a vender 100 acciones. Seleccionamos el valor “BBVA”, a un precio de 7.5 euros la acción. Ponemos el 5 de Septiembre. Tenemos 100 acciones de BBVA ahora mismo, vamos realizar 3 operaciones más: Una compra de 50 acciones a 6 euros el 6 de Septiembre. Una venta de 50 acciones a 8 euros el 9 de Septiembre. Otra venta de 100 acciones a 9.5 euros el 18 de Septiembre, con lo que la cartera ya no tiene acciones de BBVA. El historial de las operaciones se muestra en la siguiente imagen. 52 Figura 6-6. Historial BBVA Una vez explicado el proceso de operar, vamos a realizar con otros valores más compras y más ventas: Por ejemplo con el valor “ACS”: -Compra de 100 acciones a 30 euros el 5 de Septiembre. -Venta de 100 acciones a 32 euros el 15 de Septiembre. -Compra de 400 acciones a 28 euros el 19 de Septiembre. -Venta de 200 acciones a 26 euros el 23 de Septiembre. Figura 6-7. Historial ACS 53 Con el valor “ABENGOA”: -Compra de 100 acciones a 20 euros el 1 de Septiembre. -Venta de 100 acciones a 18 euros el 5 de Septiembre. -Compra de 100 acciones a 17 euros el 19 de Septiembre. Figura 6-8. Historial ABENGOA Para acabar, vamos a comprar acciones de Telefónica por un importe total de 6000 euros a un precio de 11 euros la acción. Simplemente se introduce el importe en el campo de texto, y el sistema genera las acciones que se pueden comprar con ese precio. En este caso 600/15 = 400. No las vamos a vender posteriormente, simulando una inversión a largo plazo. Figura 6-9. Historial TELEFÓNICA 54 • Estado actual Vamos a ver cómo queda la cartera en conjunto. En el menú, seleccionamos “Estado actual”. Como se puede comprobar en la Figura 6-10, se muestran los títulos que la cartera tiene actualmente. De BBVA se vendieron todas, por tanto no aparece nada. Por otro lado, tenemos 400 acciones de Telefónica con un valor actual de 13.47 cada una lo que supone una rentabilidad casi el 11% respecto al precio de compra (12). Tenemos 200 acciones de ACS. Recordar que se compraron 400 a 28 y luego se vendieron 200, así que las que quedan tienen un precio medio de 28. Ahora cotiza a 24.945 con lo cual estamos perdiendo dinero. De ABENGOA quedan 100 acciones y también estamos perdiendo -173 € debido a que las acciones actualmente están más bajas. Figura 6-10. Estado actual de la cartera 55 • Listado de operaciones Así es como queda el listado de las operaciones ordenadas por fecha. Se puede jugar con los filtros para encontrar la información más rápidamente. • Información Fiscal Vamos a analizar cómo quedaría la información fiscal, las plusvalías reales de la cartera, y las pérdidas o ganancias patrimoniales que podemos imputar en la declaración de la renta. Este informe agrupa las operaciones por valor, y está basado en las ventas. Para cada operación de venta, el sistema buscará con un método FIFO (Primero en entrar, primero en salir) las compras que le corresponde a esa venta. Es decir, que primero encontrará las compras más antiguas. Es importante destacar que se limitará al volumen de la venta. Es decir, si hay una compra de 200 y una venta de 100, se han vendido 100, así que los datos de la compra corresponderán sólo a 100 acciones, quedando otras 100 pendientes para futuras ventas. Si pasa esto en el campo “Tipo” aparecerá el texto: “C Par.” Hay que tener en cuenta la famosa norma “anti-aplicación”. Si hay una venta con pérdidas y otra compra dos meses antes o después de la venta, se considerará como que se está recomprando y Hacienda no deja que esas pérdidas se puedan compensar con otras ganancias. Así la plusvalía será menos negativa o llegará ser 0 €. Ejemplos En la Figura 6-11, en ABENGOA y en la primera venta de BBVA. 56 Información Fiscal de la cartera Figura 6-11. Información Fiscal de la cartera En primer lugar, observar que no aparece Telefónica, pues no hemos hecho ninguna Venta. Respecto a BBVA, recordemos que la primera compra es de 200 acciones y la primera venta es de 100 acciones, con lo que aún queda volumen de compra pendiente. La pérdida patrimonial es sólo de 75 € porque hay una compra de 50 acciones en los 2 meses siguientes, con lo que se considera una recompra a ojos de Hacienda. Como la recompra tiene la mitad del volumen de la venta, la mitad de las pérdidas no se imputan. (150 € / 2 = 75 €).