IS Case Tool-Docs

IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 1 Universidad Complutense de Madrid Facultad De Informática Trabajo de Fin de Grado IS CASE TOOL - DOCS Daniel Reyes Tubón Director Antonio Sarasa Cabezuelo Madrid-2018 IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 2 Resumen Para este TFG se ha creado una herramienta case para mantener, gestionar y generar documentos referentes a la asignatura de Ingeniería del Software. El objetivo del trabajo es proveer una herramienta de ayuda a estudiantes y profesores en el contexto de la asignatura de IS; permitiendo asignar proyectos documentales a cada equipo de trabajo y facilitando a los estudiantes el rellenado y generación de los distintos documentos requeridos en la asignatura como son SRS y Plan de Proyecto. Para ello, se ha desarrollado una herramienta web, que mediante autenticación diferencia dos escenarios de acuerdo con el tipo de usuario, utilizando para ello una interfaz común. El primero se dedica a los Profesores (Administradores) quienes, tienen la posibilidad de gestionar de forma básica los Equipos de trabajo en función de los Estudiantes previamente registrados. Para ello, los profesores deben ser dados de alta en el sistema previa puesta en producción de la herramienta, funcionalidad que también está disponible a través de la interfaz web mediante el cambio de un simple ‘flag’ en el fichero de configuración del proyecto. Mientras que, el segundo escenario se dedica a los Estudiantes (Miembros) quienes, mediante una sencilla interfaz podrán editar, guardar y generar los documentos de su Equipo; recibiendo para ello consejos y ejemplos de ayuda en el rellenado de cada uno de los apartados de un documento. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 3 Abstract A Case Tool has been created in this work to maintain, manage and generate documents related to the Software Engineering course. The work’s purpose is to provide a tool to help students and teachers in the context of the IS course, allowing the assignment of documentary projects to each work team and facilitating the students the completion and generation of the different documents required in the subject such as SRS and Project Plan. To this end, a web tool has been developed, which uses authentication to differentiate two scenarios according to the type of user, using a common interface. The first one is dedicated to the Teachers (Administrators) who have the possibility to manage in a simple way the Work Teams according to the previously registered Students. For this, teachers must be registered in the system before the tool is put into production, a feature to do it is also available through the web interface by changing a simple 'flag' in the project configuration file. The second scenario is dedicated to the Students (Members) who, through a simple interface, will be able to edit, save and generate the documents of their Team, receiving advices and examples to help in the completion of each document's section. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 4 Agradecimientos Mis más sinceros agradecimientos, van dedicados en primera instancia a mi director de proyecto, Antonio Sarasa Cabezuelo, por el apoyo y tiempo dedicados a trabajar en la realización. Siempre valoraré sus enseñanzas y disposición para ayudar cuando ha sido necesario. Agradezco a mi madre y seres más allegados, quienes siempre estuvieron apoyándome en la culminación de mi trabajo, sin importar las circunstancias. Además, dedico un agradecimiento especial, a la dirección de la empresa Provide HCM People, en la actualmente trabajo ya que; sin su formación, apoyo y flexibilidad, este trabajo no habría sido posible. De igual manera, de antemano agradezco a todos y cada uno de los lectores, por la atención prestada. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 5 Índice general Resumen ..................................................................................................................................... 2 Abstract ....................................................................................................................................... 3 Agradecimientos .......................................................................................................................... 4 Índice general ............................................................................................................................... 5 1. Introducción ............................................................................................................................. 6 1.1 Introducción al TFG ................................................................................................................ 6 1.2 Contexto del proyecto ............................................................................................................ 6 1.3 Estado del arte ....................................................................................................................... 7 1.4 Estructura de la memoria ....................................................................................................... 9 1. Introduction .............................................................................................................................. 10 1.2 Context of the project ….......................................................................................................... 10 1.3 State of art .............................................................................................................................. 11 1.4 Structure of the Report ........................................................................................................... 13 2. Objetivos Generales …………………............................................................................................... 14 2. 1 Objetivos ................................................................................................................................ 14 2.2 Motivación .............................................................................................................................. 15 3. Especificación de requisitos ...................................................................................................... 16 3.1 Casos de Uso ……………………………………………………………………………………………………………………… 16 3.2 Características del Usuario ………………………………………………………………………………………………... 16 3.3 Requisitos Funcionales ………………………………………………………………………………………………………. 17 4. Tecnologías aplicadas ......................................................................... ...................................... 31 5. Arquitectura y modelo de datos ............................................................................................... 33 5.1 Arquitectura de la herramienta .............................................................................................. 33 5.2 Arquitectura de la Implementación ………………………………………………………………..…………………. 36 5.3 Modelo de datos ..................................................................................................................... 37 6. Diseño e Implementación ......................................................................................................... 42 6.1 Principios de diseño ................................................................................................................ 42 6.2 Interfaz de Usuario e Implementación ................................................................................... 43 6.2.1 Visión Estructural del Código Implementado ...................................................................... 43 6.2.2 Una Herramienta con Información Autogenerada ………………..………………………………………… 44 6.2.3 Interfaz de Usuario y su Funcionalidad Implementada ………………………………..…………………. 49 6.2.3.1 UI y Funcionalidades para Miembro Administrador ………………………………….…………………. 49 6.2.3.2 UI y Funcionalidades para Miembro (No Administrador) …………………………………………….. 58 6.2.3.3 UI y Funcionalidades Generales (Todos los Usuarios) ………………………………………………….. 68 7. Conclusiones y Trabajos de futuro ........................................................................................... 72 7.1 Conclusiones del Trabajo ....................................................................................................... 72 7.2 Trabajos de futuro .................................................................................................................. 72 7. Conclusions and future works .................................................................................................. 73 7.1 Conclusions ............................................................................................................................ 73 7.2 Future work ............................................................................................................................ 74 8. Contribuciones ......................................................................................................................... 74 Bibliografía ................................................................................................................................... 75 ANEXOS ........................................................................................................................................ 77 APÉNDICE A. Guía de instalación de la herramienta .................................................................... 77 APÉNDICE B. Manual de usuario .................................................................................................. 83 IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 6 1. Introducción 1.1 Introducción al TFG Este trabajo se formula como apoyo a la enseñanza de la asignatura de Ingeniería del Software con la intención de facilitar el entendimiento y aprendizaje de conocimientos avanzados y necesarios para el desarrollo de un Proyecto y su Documentación, orientando a los estudiantes poco experimentados a la adquisición de dichos conocimientos mediante la ayuda y ejemplificación del desarrollo del documento de especificación de Requisitos ‘SRS’. A través de una herramienta web, “IS Case Tool - Docs”, este proyecto permite a un equipo de estudiantes generar un documento común y autogestionado que, mediante consejos y ejemplos mostrados sobre una Interfaz de Usuario muy intuitiva, guía a los autores en la construcción del mismo. Para ello, la herramienta ofrece al Profesor (Administrador) la posibilidad de dar de alta a Equipos de Trabajo, generando así un documento único, al que pueden acceder, editar y guardar todos los miembros del equipo. IS Case Tool - Docs, es capaz de generar todos los apartados (a rellenar) y guías de ayuda para fabricar un documento SRS a partir de una plantilla preconfigurada y basada actualmente en “IEEE Recommended Practice for Software Requirements Specifications Std. 830-1998” ofreciendo las siguientes funcionalidades implementadas y que a posteriori se explican con detalle:  Funcionalidades Generales: o Registro de usuario en el Sistema. o Acceso a la Herramienta mediante autenticación. o Consulta del Perfil de Usuario. o Modificación del Perfil de Usuario.  Funcionalidades del Usuario Administrador: o Alta de Equipos de Trabajo. o Modificación de Miembros de un Equipo de Trabajo. o Baja de un Equipo de Trabajo.  Funcionalidades del Usuario Miembro: o Acceso al documento de su equipo. o Modificación de todos y cada uno de los apartados del Documento (incluye Auto Guardado de la información). o Previsualización del Documento PDF. o Generación del Documento en formato PDF. 1.2 Contexto del Proyecto Cada año, en la Facultad de Informática, se imparte la asignatura de “Ingeniería del Software”, en la que se propone a los estudiantes desarrollar un proyecto en equipo en el que, durante la primera etapa, se requiere la realización de toda la Documentación incluyendo los documentos de SRS (especificación de Requisitos), Plan de Proyecto y Memoria Final. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 7 Dicha tarea, constituye uno de los mayores retos de la asignatura, sobre todo para los estudiantes poco experimentados en el desarrollo de proyectos de esta índole. En dicho contexto, este proyecto, expone el prototipo de la herramienta IS Case Tool – Docs, pensada para la organización y construcción guiada de dichos documentos en un entorno compartido por un mismo equipo de trabajo; es esta ocasión concretamente sobre el SRS. Sin embargo, y aunque este trabajo se enmarca en un único caso, en realidad el sistema, ha sido preparado, para poder continuar en un futuro con la generación del resto de Documentos e incluso una gestión de equipos más extendida. 1.3 Estado del Arte Hoy en Día, el trabajo cooperativo está en auge en todos los ámbitos, desde educacionales, comenzando su aplicación desde educación infantil y en todos los niveles posteriores, hasta profesionales, considerando casi cualquier área. Se escucha hablar de equipos científicos, técnicos, de investigación o de diseño, aplicados a campos tan distintos como la medicina, la ingeniería, la política o la seguridad estatal. Se entiende por trabajo en equipo una labor realizada por varios individuos, donde cada uno efectúa una parte en pos de un objetivo común. Para que dicha obra se considere trabajo en equipo, éste debe tener una estructura organizativa y cada miembro un rol definido, obteniéndose, en general, muy buenos resultados. [22]. Estos aspectos se aplican directamente en la realización de proyectos de Ingeniería del Software, campo que enmarca el presente trabajo fin de grado. Las primeras fases de los proyectos software se basan en la generación de documentación, que aglutina el diseño del sistema a construir, los requisitos a cubrir y las fases a completar, entre otros aspectos importantes para finalizar con éxito el proyecto a realizar. Es muy importante que todos los miembros del equipo tengan acceso a los documentos generados durante todo el proceso para su consulta y completitud, lo que sugiere la idea de utilizar alguna herramienta o almacenamiento en la nube. Por otro lado, si puede facilitarse la tarea asociada a producción de los documentos, se simplifica significativamente la fase de diseño y se disminuyen los posibles errores que se puedan cometer. Se pueden encontrar diversas herramientas en el mercado, tanto gratuitas como de pago, orientadas a la gestión y generación documental. A continuación, se presentan algunas de las mismas, citando sus características más importantes, así como sus carencias o puntos débiles.  Google Docs es la primera herramienta que se ha analizado. Se trata de una herramienta gratuita y multiplataforma propuesta por Google Inc., cuyo lema es “Nuestra misión es organizar la información del mundo para que todos puedan acceder a ella y usarla” [23]. Acorde con dicha idea, Google Docs soporta el almacenamiento en la nube de documentos y su edición, apostando por la movilidad. Proporciona una plataforma que permite compartir documentos entre varios participantes, modificaciones en tiempo real y la posibilidad de incluir comentarios sobre los documentos gestionados. Ofrece la posibilidad de realizar conversaciones en línea entre miembros de un equipo de trabajo, tanto escritas como de voz o vídeo. Además, se han desarrollado diversos complementos que añaden funcionalidades específicas, como la posibilidad de realizar diagramas, crear plantillas, gestionar la biblioteca o corregir ortografía y gramática, entre muchas otras. [24] Su carencia más importante considerando el ámbito de aplicación objetivo del proyecto es la no existencia de un complemento suficientemente robusto y completo para dar soporte al diseño de proyectos.  La siguiente herramienta que ha resultado interesante revisar ha sido Heflo, desarrollada por Venki. Orientada a la documentación de procesos de negocio, es una herramienta de pago que ofrece IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 8 almacenamiento en la nube y facilidad para compartir diagramas y documentación con los participantes en un proyecto. Se basa en notación BPMN (Business Process Model and Notation por sus siglas en inglés), estandarizada y gráfica, cualidades que facilitan la comprensión de los procesos descritos de esta forma [25]. Es capaz de generar documentación a partir de las gráficas realizadas con un formato limpio, y permite descargar imágenes y realizar control de versiones, así como exportar o importar modelos en formato BPMN. Presenta diferentes planes de contratación, ofreciendo funcionalidades como listados de tareas, alarmas sobre plazos de entrega, integración con Slack como herramienta para conversaciones en línea o herramientas de monitorización [26]. Se trata de una opción potente a la vez que cara, muy orientada a empresa, presentando la paradoja de ofrecer complementos que no son necesarios en la fase de diseño de proyectos y no cubrir todas las necesidades objetivo del desarrollo realizado.  REM es una herramienta gratuita desarrollada por el departamento de lenguajes y sistemas de la Universidad de Sevilla, orientada principalmente a la gestión de requisitos, siguiendo la metodología desarrollada por D. Amador Durán. Actualmente se ofrece una versión experimental de la herramienta, y aunque sencilla, cubre todas las necesidades de la fase de ingeniería de requisitos de un proyecto [27]. Su principal carencia es la dificultad de compartir información en tiempo real entre miembros de un equipo que se no se encuentren reunidos físicamente, ya que no permite almacenamiento en la nube.  Una opción muy completa es Enterprise Architect, de SparxSystems. Es capaz de cubrir todas las etapas de diseño y modelado para diversas áreas, desde procesos de negocio hasta desarrollo software, incluyendo proyecto orientados a sistemas embebidos, y cubriendo también diseño de sistemas o de bases de datos. Ofrece la posibilidad de realizar y componer distintos tipos de gráficos, entre los que destaca la notación UML para casos de uso. A partir de los requisitos y diseños introducidos en la herramienta, genera documentación e informes. Una de las características más atractivas es la generación a partir de los modelos realizados de código fuente en varios lenguajes de programación (por ejemplo, C#, Java, PHP, VHDL o Phyton, entre otros). En conjunto, se trata de una opción muy potente, que permite un alto grado de cooperación entre los integrantes de un equipo de trabajo, asignando roles a los participantes e integrando control de versiones, y brindando la posibilidad de ser desplegada sobre un servidor (basado en la nube o en red de área local) o servicio de almacenamiento en la nube. Como ya se ha adelantado, cubre desde el modelado hasta el análisis del impacto producido por cambios en el diseño, ofrece modelos y plantillas tanto para modelado como para documentación e informes, integra varias herramientas para dar soporte a cada fase de un proyecto y está basado en estándares como UML, BPMN y SysML [28]. Con todo ello, se trata de una alternativa robusta y eficaz, a la vez que cara, ofreciendo diversos planes de suscripción para su uso.  Centrándose únicamente en la gestión documental, Ibermática ofrece la plataforma iberDok, para la generación, gestión y edición de documentación a partir de plantillas. Permite la utilización de objetos dinámicos y la producción de documentos inteligentes basados en reglas y dependencias. Orientado a empresas que generan y distribuyen por diversas vías (correo electrónico, impresión en papel o publicación en formato electrónico) grandes volúmenes de documentos [29], podría considerarse como una opción para la generación de documentos basados en plantillas unificadas, pero no ofrece funcionalidades básicas para el ámbito al que se orienta este proyecto. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 9  Dentro de la misma familia de herramientas orientadas a la gestión documental, cabe mencionar openKm, que integra control de versiones y permite controlar el ciclo de vida de los distintos documentos. Al tratarse de un repositorio en la nube, permite la colaboración entre miembros de un equipo para la generación de documentación, pero no está orientada de forma específica a diseño de sistemas o desarrollos en marcados en el área IT. Aunque admite el diseño de flujos de trabajo, no ofrece herramientas específicas para modelar gráficamente casos de uso o diagramas de proceso. Se trata de una opción adecuada para la administración de documentos, que permite definir tareas automáticas y el uso de distintos módulos que aumentan las funciones básicas ofertadas, según necesidades más específicas, como puede ser la firma digital o la gestión de tareas. [30] Como puede inferirse de todo lo expuesto anteriormente, existen en el mercado una gran variedad de herramientas, plataformas y aplicaciones orientadas a la gestión, generación y almacenaje de documentación. Con el presente proyecto, se pretende desarrollar una herramienta dinámica, orientada específicamente a la gestión de requisitos en el ámbito de Ingeniería del software, que permita a los distintos equipos desarrollar documentos de forma colaborativa, respetando los roles asignados y facilitando la labor que conlleva dicha fase de diseño software. 1.4 Estructura de la Memoria En el transcurso de la lectura, se puede apreciar en el documento una estructura organizada en capítulos. El Capítulo 1, ofrece una introducción al trabajo realizado, exponiendo los aspectos fundamentales para ubicar al lector en un contexto adecuado, pretendiendo así, cimentar una idea general del tema principal sobre el que fundamenta este trabajo, incluyendo funcionalidades y símiles del mismo. El Capítulo 2, describe las razones que han motivado la realización del trabajo y los objetivos generales de su desarrollo; los cuales, se han generado a partir del estudio de las necesidades en el apoyo educacional para con los profesores y estudiantes de generaciones futuras. Así también, desde una perspectiva tecnológica, se pretende exponer algunos aspectos fundamentales del desarrollo web en la actualidad. El Capítulo 3, presenta la especificación de requisitos del sistema, estructurando y definiendo de forma concisa las funcionalidades que se han desarrollado. El Capítulo 4, expone las distintas tecnologías utilizadas para el desarrollo, describiendo sus características y motivos de elección. El Capítulo 5, explica la Arquitectura utilizada como base del desarrollo y describe el Modelo de Datos utilizado para gestionar y mantener la información que permite al sistema ofrecer toda su funcionalidad. El Capítulo 6, expone y explica todas las decisiones de diseño que se han tomado para el sistema y los principios aplicados para tomarlas. Además, incluye un análisis detallado de la implementación. El Capítulo 7, cierra el conjunto presentando las conclusiones a las que se ha llegado después de la realización del trabajo y propone posibles extensiones que den completitud al mismo. Finalmente, existe un apartado de anexos, donde se puede encontrar una guía de instalación de la herramienta y un manual de usuario básico, para el uso de IS Case Tool – Docs. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 16 3. Especificación de Requisitos 3.1 Casos de Uso Las distintas funcionalidades de la herramienta desarrollada, IS Case Tool – Docs, se detallan en este capítulo de manera formal, explícita y coherente de acuerdo con los fundamentos de la Especificación de Requisitos. Para ello, se ofrecen los siguientes casos de uso [Figura 1.], descritos mediante un diagrama UML: [ Figura 1: Diagrama de Casos de Uso] 3.2 Características del Usuario El Sistema denomina a los usuarios “Miembros” y como podemos apreciar en [Figura 1.] contempla dos tipos:  Miembro Administrador, que tendrá disponibles, además de las funcionalidades generales que tratan sus propios datos; funcionalidades de gestión de Equipos de trabajo de la asignatura. En contexto, este usuario haría el Rol de Profesor.  Miembro, que tendrá disponibles, además de las funcionalidades generales que tratan sus propios datos; funcionalidades dedicadas a la construcción, edición, almacenamiento e impresión del Documento SRS. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 17 3.3 Requisitos Funcionales A continuación, realizamos un detalle de los casos de uso descritos en [Figura 1.] donde se aprecia la existencia de tres bloques diferenciados:  Funciones Comunes a Todos los Miembros: Identificador del Caso de Uso CU1 Nombre Registro de Miembro Actores M iembro ó Miembr o Administrador Precondiciones Configuración de la Herramienta, mediante un fichero ( config. json), para determinar el Rol (Admin/ No Admin) de Registro mediante un flag. Post Condiciones El Usuario recibe un mensaje de confirmación de alta como Miembro a través de la UI y puede proceder a autenticarse. Descripción Cada usuario debe realizar un registro para darse de alta como Miembro del Sistema, a través de un formulario, facilitando los datos requeridos. El proceso se realiza desde la vista principal de la UI en IS Case Tool - Docs. Flujo Principal 1. El Usuario accede a la vista principal del sistema utilizando un web Browser. 2. El usuario presiona el botón de “Registro” que presenta un formulario a rellenar con sus datos. 3. Tras rellenar todos sus datos el sistema lo valida y activa el botón de confirmación de Registro. 4. El usuario presiona el botón de Confirmación. 5. Los datos se almacenan en el sistema, y el Usuario queda dado de Alta. 6. Se muestra un mensaje de confirmación del Alta. Flujo Alternativo 1. El Usuario accede a la vista principal del sistema utilizando un web Browser. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 18 2. El usuario presiona el botón de “Registro” que presenta un formulario a rellenar con sus datos. 3. Tras rellenar todos sus datos el sistema No valida los Datos por haber algún error en los mismos. 4. El usuario corrige los datos erróneos. 5. Tras rellenar todos sus datos el sistema lo valida y activa el botón de confirmación de Registro. 6. El usuario presiona el botón de Confirmación. 7. Los datos se almacenan en el sistema, y el usuario queda dado de Alta. 8. Se muestra un mensaje de confirmación del Alta. Identificador del Caso de Uso CU2 Nombre LogIn Actores Miembr o ó Miembro Administrador Precondiciones El usuario debe haber realizado un Registro de Miembro (CU 1 ) correcto en el sistema. Post Condiciones El usuario , accede al catálogo de funcionalidades ofrecidas “LaunchPad”. Descripción Un usuario registrad o, accede al sistema mediante un formulario de autenticación. Pudiendo así visitar la interfaz “Launchpad” que da acceso a todas las funcionalidades que se le ofrecen. Flujo Principal 1. El usuario accede a la vista principal del sistema utilizando un web Browser. 2. El usuario rellena los datos de autenticación mostrados en el formulario de LogIn. 3. El usuario presiona el Botón de LogIn. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 19 4. Los datos introducidos son evaluados por el sistema y se validan correctamente. 5. El sistema configura una sesión sobre el web Browser. 6. El usuario accede al sistema, pudiendo interactuar con el catálogo de funcionalidades. Flujo Alternativo 1. El usuario accede a la vista principal del sistema utilizando un web Browser. 2. El usuario rellena los datos de autenticación mostrados en el formulario de LogIn. 3. El usuario presiona el Botón de LogIn. 4. Los datos introducidos son evaluados por el sistema y Nó se validan por ser erróneos. 5. Se muestra un mensaje de error en la autenticación. Identificador del Caso de Uso CU3 No mbre LogOut Actores Miembro ó Miembro Administrador Precondiciones El usuario, ha realizado un LogIn (CU2) y accede al catálogo de funcionalidades ofrecidas “LaunchPad”. Post Condiciones El listado de Equipos se muestra actualizado de acuerdo al fi ltro aplicado. Descripción El usuario puede cerrar su sesión y volver a la vista inicial de la aplicación desde el catálogo “LaunchPad”; borrando de forma segura así sus datos de sesión. Flujo Principal 1. El usuario presiona el Botón de LogOut. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 20 2. El s istema Limpia los datos de sesión vigentes sobre el Web Browser. 3. El sistema muestra la interfaz inicial de la herramienta. (CU2) Flujo Alternativo 1. El usuario cierra el web Browser. 2. El sistema Limpia los datos de sesión vigentes sobre el Web Browser. 3. El sistema muestra la interfaz inicial de la herramienta. (CU2) Identificador del Caso de Uso CU 4 Nombre Consultar Perfil Actores Miembro ó Miembro Administrador Precondiciones El usuario ha sido autenticado (CU2) y ha accedido al catálogo de Funcionalidades disponibles “LaunchPad” Post Condiciones El usuario puede ver correctamente sus datos personales y utilizar la funcionalidad ofrecida para gestionarlos. Descripción Cada usuario puede consultar sus datos personales, facilitados tras su registro, accediendo a la interfaz de “Mi Perfil” disponible en el catálogo previo “LaunchPad”. Flujo Principal 1. El usuario p resiona sobre el Tile correspondiente a “Mi Perfil” disponible en el Catálogo. 2. El Sistema recupera los datos del usuario almacenados. 3. El sistema presenta los datos del Miembro a través de la UI en la vista correspondiente. Flujo Alternativo IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 21 Identificador del Caso de Uso CU 5 Nombre Editar Perfil Actores Miembro ó Miembro Administrador Precondiciones El usuario ha sido autenticado y ha accedido a la UI de “Mi Perfil” (CU4) mediante el Tile correspondiente del catálogo “LaunchPad”. Post Condiciones Todos los datos actualizados por el usuario quedan almacenados en el sistema y se muestran correctamente. Descripc ión Tras acceder a su perfil el usuario es capaz de modificar los datos personales proporcionados durante su registro y almacenarlos actualizados en el sistema, a través de la funcionalidad que ofrece la UI. Flujo Principal 1. El usuario presiona sobre cu alquiera de los botones de edición de la vista “Mi Perfil” en la UI. 2. El sistema habilita los campos de datos a Modificar. 3. El usuario edita los datos. 4. El usuario confirma los cambios. 5. El sistema actualiza los datos almacenados. 6. El sistema muestra un mensaje que confirma una actualización correcta Flujo Alternativo  Funciones de Miembro Administrador: Identificador del Caso de Uso CU 6 IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 22 Nombre Ver Equipos Actores Miembro Administrador Precondiciones El usuario ha sido autenticado (CU2) y ha a ccedido al catálogo de Funcionalidades disponibles “LaunchPad”. Post Condiciones El usuario es capaz de ver y utilizar las funcionalidades ofrecidas para la Gestión de Equipos de Trabajo. Descripción El usuario puede consultar los nombres y m iembros de los equipos de trabajo dados de alta en el sistema, accediendo a la interfaz de “Gestionar Equipos” ofrecida en el catálogo “LaunchPad” y seleccionando un equipo de entre una lista de ellos; para a continuación ver la información detallada del equipo seleccionado. Flujo Principal 1. El usuario presiona sobre el Tile correspondiente a “Gestionar Equipos” disponible en el Catálogo. 2. El Sistema recupera los datos de los equipos almacenados. 3. El sistema presenta los datos de los equipos dados de alta a través de la UI en la vista correspondiente. Flujo Alternativo Identificador del Caso de Uso CU 7 Nombre Búsqueda de Equipos Actores Miembro Administrador Precondiciones El usuario ha sido autenticado y accedido a la UI de “Gestionar Equipos” (CU5) mediante el Tile correspondiente del catálogo “LaunchPad”. Post Condiciones El usuario visualiza el listado de equipos filtrado por el nombre introducido. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 23 Descripción El usuario puede buscar equipos a través de un input de búsqueda, cuya función es mostrar los equipos con el nombre o parte del nombre que ha introducido el usuario. Flujo Principal 1. El usuario escribe el nombre de un equipo o parte del mismo en el input de búsqueda. 2. El Sistema filtra el listado de equipos por nombre. 3. El sistema actualiza el listado de equipos que se muestran y los presenta al usuario. Flujo Alternativo Identificador del Caso de Uso CU 8 Nombre Alta de Equipo Actores Miembro Administrador Precondiciones El usuario ha sido autenticado y accedido a la UI de “Gestionar Equipos” (CU5) mediante el Tile correspondiente del catálogo “LaunchPad”. Post Condiciones Un nuevo equipo de trabajo se ha dado de alta en el sistema. Descripción El usuario da de alta un nuevo equipo de trabajo, escogiendo a los miembros que lo conforman, de entre los ya registrados, y dándole un nombre al equipo. De esta manera un equipo y sus documentos, en principio sin contenido, quedan almacenados en el sistema. Flujo Principal 1. El usuario presiona sobre el botón de “Nuevo Equipo”. 2. El sistema recupera los datos de los miembros disponibles y muestra una lista seleccionable al usuario, así como un campo para escribir el nombre del nuevo equipo. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 24 3. El usuario escribe El nombre del equipo y selecciona uno o más miembros. 4. El botón de confirmación de Creación se activa. 5. El usuario presiona el botón de confirmación de Creación. 6. El sistema Crea un nuevo equipo, relaciona el equipo con sus miembros y da de alta todos los documentos y apartados en principio vacíos del nuevo equipo. 7. Se muestra un mensaje de confirmación, asegurando la creación correcta del equipo. Flujo Alternativo Identificador del Caso de Uso CU 9 Nombre Modificar Miembros de un Equipo Actores Miembros y/o Miembros Administradores Precondiciones El usuario ha sido autenticado y accedido a la UI de “Gestionar Equipos” (CU5) mediante el Tile correspondiente del catálogo “LaunchPad”. Y además ha seleccionado uno de los equipos existentes. Post Condiciones Toda la información de un equipo se muestra de maner a correcta y actualizada. Descripción El usuario agrega o elimina miembro/s en un equipo en el sistema utilizando para ello, los botones ofrecidos por la UI en la vista correspondiente. Flujo Principal 1. El usuario selecciona un equipo y visualiza los detalles del mismo. 2. El usuario presiona el botón de “Agregar Miembro” 3. El sistema recupera los datos de los miembros disponibles y muestra una lista seleccionable al usuario. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 25 4. El usuario selecciona uno a más miembros para agregar al equipo. 5. El botón de confirmación de la agregación se Activa. 6. El usuario presiona el botón de Confirmación. 7. El sistema agrega y almacena la información con el/los miembros agregados. 8. El sistema muestra la información de los miembros de un equipo actualizada. Flujo Alternativo 1. El usuario selecciona un equipo y visualiza los detalles del mismo. 2. El usuario presiona sobre el botón “Eliminar” asociado a uno de los miembros de un equipo. 3. El sistema, actualiza la información del equipo almacenada eliminando el miembro seleccionado. 4. El sistema muestra la información de los miembros de un equipo actualizada. Identificador del Caso de Uso CU 10 Nombre Baja de Equipo Actores Miembros y/o Miembros Administradores Precondiciones El usuario ha sido autenticado y accedido a la UI de “Gestionar Equipos” (CU6) mediante el Tile correspondiente del catálogo “LaunchPad”. Post Condiciones Toda la información sobre los equipos almacenada y mostrada se encuentra actualizada. Descripción El usuario elimina un equipo d el sistema utilizando para ello, los botones ofrecidos por la UI en la vista correspondiente. Flujo Principal 1. El usuario selecciona un equipo. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 32  Almacenamiento: Para almacenar y gestionar todos los datos se ha escogido la Base de Datos no relacional MongoDB [13]. Mongo DB, es una base de datos no relacional de código abierto, que almacena información en documentos con formato JSON.  Servidor-web: aunque “n-odata-server” ofrece una API RestFull expuesta, que sería suficiente para conectarse desde un PC que tenga la implementación front-end; se ha decidido establecer un entorno más real, colocando ésta última sobre un servidor Apache [14] que arranca a través de la conocida distribución Apache XAMPP [15] de manera sencilla y ágil. Esto permite tener toda la implementación en servidor y ofrecer al usuario una herramienta web a la que puede acceder simplemente utilizando una URL en su navegador.  Entorno de desarrollo y Gestión de Versiones: en este aspecto y dado que es un trabajo individual, se ha seleccionado como entorno de desarrollo la herramienta SAP WEB IDE [16] ofrecida como servicio por SAP Cloud Platform (trial Version) [17] y que cuenta con integración GitHub [18], para el control de versiones. SAP WEB IDE [16], es un entorno de desarrollo web, especializado en proyectos SAP UI5[2] que ofrece una serie de funcionalidades adecuadas de cara a la programación, configuración, estructura y volcado de proyectos de este tipo. Se puede acceder a él (gratuitamente), como servicio en cloud a través de la plataforma SAP Cloud Platform (trial Version) [17]. SAP Cloud Platform (trial Version) [17], explican en la web, “Es una plataforma abierta como servicio en cloud, que ofrece capacidades en memoria, servicios básicos de plataforma y microservicios únicos para crear y ampliar aplicaciones inteligentes y móviles. La plataforma está diseñada para acelerar la transformación digital ayudando a desarrollar de forma rápida, sencilla y económica, aplicaciones que se adecuan a nuestro interés, sin invertir en infraestructura local. Basado en estándares abiertos, SAP Cloud Platform ofrece total flexibilidad y control sobre Frameworks y aplicaciones”. En resumen, a través de esta plataforma se puede acceder a los servicios necesarios para empezar el desarrollo; en concreto se adquiere acceso al entorno de desarrollo SAP WEB IDE [16], y a la configuración de las conexiones que permitirán la comunicación con el Back-end API RestFull para poder arrancar nuestras aplicaciones en desarrollo. Es importante conocer que la plataforma ofrece versiones libres (TRIAL) y de pago; como es de esperar la versión de pago ofrece infinidad de servicios, utilidades y prestaciones. Sin Embargo y para lo que a este trabajo interesa, se va a utilizar la versión TRIAL que ofrece más que suficiente; incluyendo integración con una cuenta GitHub [18] para el control de versiones. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 33 5. Arquitectura y Modelo de Datos 5.1 Arquitectura de la herramienta IS Case Tool – Docs, plantea una arquitectura por capas diferenciadas. En primera instancia la capa más externa, tiene una arquitectura Cliente-Servidor [20] escalable, es decir, en otra perspectiva el Servidor se convierte en Cliente de una API REST. En general, la siguiente figura muestra la arquitectura completa: [ Figura 2. Arquitectura Completa del Proyecto] A continuación, se ven estos aspectos con mayor detalle:  Arquitectura en la Capa Más Externa (Cliente - Servidor): En la capa más externa, encontramos una arquitectura Cliente-Servidor, en la que el Cliente viene a ser el web Browser del usuario final, mientras que el servidor(escalable) es la máquina en la que se ha levantado un Apache, encargado de servir las páginas web. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 34 [ Figura 3. Arquitectura Capa Externa]  Arquitectura en la Capa Secundaria (Cliente - Servidor): En esta capa, en cambio, encontramos una arquitectura Cliente-Servidor, en la que el Cliente viene a ser la máquina que sirve las páginas front-end SAPUI5, mientras que el servidor es una máquina en la se levanta la API REST (n-odata-server) conectada a la anterior, como servicio a través de un puerto y que a su vez se conecta a una base de Datos Mongo DB. Dicha configuración se hace a través de un fichero simple en el back-end. [ Figura 4. Arquitectura Capa Secundaria] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 35  La Arquitectura sobre el trabajo presentado Actualmente, con motivo de la presentación de este trabajo y por tiempo limitado, se ha montado toda la arquitectura en una sola máquina personal utilizando: o Una estructura de ficheros conjunta y ubicada en el servidor Apache como directorio principal de XAMPP o Para la Capa Externa, un DynDNS [19] a través del puerto 82 “http://iscasetool.hopto.org:82”. Aunque en la práctica, se puede construir esta parte sobre cualquier servidor Apache que sirva las páginas de la parte Front-end (SAP UI5). o Para la Capa secundaria, se configura la conexión a la base de datos Mongo DB local, mediante un fichero de configuración en el back-end. Mientras que la API REST (n-odataserver) se levanta sobre el puerto 3001; que es el puerto al que atacará el front-end. [ Figura 5. Arquitectura Presentada para Demo] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 36 5.2 Arquitectura de la Implementación Para realizar la implementación de la herramienta, se sigue una arquitectura MVC (modelo - vista - controlador) separando la interfaz de usuario y la lógica de implementación en tres partes El Modelo, se encarga de manejar la representación de los datos y los mecanismos de persistencia. La Vista, se encarga de componer y presentar la interfaz de Usuario consumiendo los datos entregados por el Modelo. El Controlador, trabaja como punto intermedio entre la Vista y el Modelo, gestionando las transformaciones, manejo de datos e interacciones de usuario para establecer una vía de flujo entre las dos partes anteriores. Si bien es cierto, que el modelo final persiste en servidor sobre una base de datos, decimos que el proyecto es un 90% Front-end debido a que SAP UI5, trabaja con su propio MVC, componiendo su propio modelo a partir de una imagen de los datos persistentes. Todos los flujos de datos se trabajan sobre el Modelo Frontend (oData Model) y cuando todas las operaciones o cambios han sido hechos sobre él, finalmente se envían a servidor donde solamente se realiza la lectura o persistencia de los cambios. El siguiente diagrama muestra un ejemplo del funcionamiento comentado: [ Figura 6. MVC en Front-end e Interacción con Back-end] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 37 5.3 Modelo de Datos IS Case Tool – Docs, plantea un modelo de datos basado en el protocolo oData y que se traduce finalmente, comúnmente se conoce, que se trata de bases de datos no relacionales, sin embargo, se pueden ir construyendo relaciones mediante foreign Keys de acuerdo con el modelado que se precisa. Dicho modelado se realiza sobre el servicio oData (n-odata-server), definiendo las distintas Entidades y relaciones que representan la información de Equipos, Miembros, Documentos, Items y Contenidos. Una vez hecho esto, es el propio servicio quien da de alta las Entidades sobre MongoDB (Colecciones) y nos proporcionará la estructura a través de una simple llamada URL. En el caso de la demo preparada para este trabajo, por ejemplo: http://iscasetool.hopto.org:3001/odata/$metadata Para representar la información se decide crear las siguientes Entidades y relaciones: IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 38 [Figura 7. Modelo de Datos y Relaciones] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 39  Entidad Team, representa la información necesaria para definir un Equipo de Trabajo y sus atributos son: o id: identificador único de un equipo (Clave Primaria – Mongo Id). o name: nombre del Equipo de Trabajo (String). o director: identificador del Miembro Director del Proyecto de IS. (Mongo Id).  Entidad Miembro, representa la información necesaria para definir un Miembro, es decir un usuario de la herramienta, que puede o nó pertenecer algún equipo y sus atributos son: o id: identificador único de un equipo (Clave Primaria – Mongo Id). o mail: correo electrónico del usuario (String). o pass: clave de acceso a la herramienta, definido por el usuario (String Codificado). o name: nombre del Usuario (String). o lastName: Apellido/s del Usuario (String). o picture: URL o fichero base 64, de la imagen que representa el avatar o Foto del usuario (String). o admin: flag que especifica si un usuario tiene Rol de Administrador o nó (String). o team: id del Equipo de trabajo (Team), que se refiere al equipo de trabajo al que pertenece un usuario (String). o director: flag que especifica si un usuario es director de su Equipo o Nó (String)  Entidad Document, representa la información necesaria para definir un Documento. Desde el punto de vista de la herramienta, un Documento representará uno de los temas que un usuario puede tratar desde la UI en forma de mini-Aplicaciones partiendo de un catálogo. Actualmente, pueden tratarse: SRS, Plan de Proyecto (no Activo), Memoria (No Activo), Mi Perfil y Gestionar Equipos (en caso de ser Admin). Sus atributos son: o id: identificador único de un equipo (Clave Primaria – Mongo Id). o name: nombre del Documento (String). o docType: tipo de Documento utilizado para diferenciar la navegación desde el catálogo de mini-Aplicaciones (SRS, PLAN, MEM, PROFILE, TEAMS). (String). o credential: representa una credencial de acceso basada en el Rol que un usuario tenga en el Sistema diferenciando a todos los usuarios, solo Miembros no administradores, solo IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 40 Miembros administradores ó solo Directores de Equipo. Permite presentar un catálogo de mini-Aplicaciones u otro de acuerdo al tipo de Usuario (String).  Entidad Item, representa la información necesaria para definir cada uno de los Apartados de un documento, que el usuario deberá rellenar; es decir, en conjunto los Items representan el índice de un documento. Dado que un documento específico, siempre tendrá los mismos apartados, lo que se hace es definir estos datos a partir de una plantilla preconfigurada que puede ser cambiada fácilmente retocando un fichero JSON en el proyecto. Sus atributos son: o id: identificador único de un Item (Clave Primaria – Mongo Id). o title: título del Item (String). o description: descripción del Item (String). o doc: tipo de documento al que pertenece el ítem (se refiere a un docType de la entidad Document). (String) o parent: número del Item padre; cuando un Item (Apartado de un Documento) contiene subapartados, éstos están contenidos bajo su Item Padre. (String – se refiere al num del Item Padre) o num: número de Item, representa el numero ordinal de un apartado sobre el documento (String) o finalContent: especifica si un subapartado tiene más niveles de subapartados dentro de un documento. En tal caso todos los subniveles pasarán a ser Contenidos (Content) y este atributo permite hacer una diferenciación en la UI. (String – con valores “final”, “middle”, “last”).  Entidad Content, representa la información necesaria para definir alguno de los contenidos de un Apartado (Item) sobre un documento. Con el fin de facilitar la construcción de la UI, cada Content, representa un objeto Gráfico (a mostrar por pantalla) y que puede o nó tener una cadena escrita, que irá plasmada en un documento Real y será rellenada por un usuario. Sus atributos son: o id: identificador único de un Content (Clave Primaria – Mongo Id). o contentType: representa el tipo de objeto Gráfico que será construido sobre la UI. En base a este valor, el Front-end decide cómo se pintará el Contenido (String). o infoLabel: etiqueta informativa del “Content”, se refiere a una etiqueta con información predefinida, no por el Usuario, a mostrar en un objeto gráfico (String). IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 41 o inContent: contenido Real de cada elemento gráfico. Generalmente es sobre este campo, sobre el cual un usuario trabaja actualizando su valor. Se refiere en General al contenido que mostrará cada objeto Gráfico de la UI (String). o flagCollection: especifica si el campo “inContent” ha sido almacenado como un conjunto de valores que se deben separar mediante su procesamiento (String). o printable: representa un flag que especifica si un “inContent” debe ser presentado en la impresión final del Documento (String). o container: representa el identificador del “Content” que hace de contenedor gráfico de un contenido (Mongo Id – se refiere al id de otros Contenidos). o parent: representa el identificador del “Content” que actúa como Subapartado de tercer Nivel en un documento, en el caso de existir. Por tanto, no se trata de un contenedor sino de una construcción gráfica totalmente diferente, a nivel de un subapartado (Mongo Id – se refiere al id de otros Contenidos). o editor: representa a un Miembro del equipo específico o a varios, quien/es podrán editar el contenido (Mongo Id ó String). o team: representa el equipo al que pertenece el “Content” tratado (Mongo Id – se refiere al identificador de una entidad “Team”). o item: representa el Item (apartado) al que pertenece el “Content” tratado (Mongo Id – se refiere al identificador de una entidad “Item”). IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 48 [Figura 15. Implementación del Alta de Entidades “Content” Front-end] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 49 6.2.3 Interfaz de Usuario y su Funcionalidad Implementada En este apartado, explica cómo se ha implementado la herramienta y presenta a la vez las funcionalidades ofrecidas a través de la Interfaz de Usuario. IS Case Tool – Docs, implementa un punto de acceso común tanto a Miembros Administradores como a Miembros No administradores, a través de autenticación se realiza una diferenciación del tipo de usuario y se carga un Catálogo (LaunchPad) de funcionalidades adecuadas a cada tipo de usuario. Para ello cada usuario debe realizar un registro previo en la aplicación. Para entrar en detalle, se clasifican las interfaces de usuario y sus funcionalidades de acuerdo al tipo de usuario: 6.2.3.1 UI y Funcionalidades para Miembro Administrador  Registro de Usuario) Es muy importante destacar que el Registro de Miembro/s Administrador/es, ha de realizarse previo a la puesta en producción de la herramienta, dado que la interfaz es común a todos los usuarios. Para ello se ha dispuesto un fichero de configuración en el Front-end que permite visualizar el control de registro de un miembro administrador en la Aplicación ubicado en “frontend/config/config.json” y que además permite configurar algunos datos que se mostrarán en la Impresión Final de un Documento. [Figura 16. Fichero JSON de configuración Admin] A Partir de ahí y una vez arrancada la herramienta; el registro se realiza desde la vista principal “LogIn” utilizando el botón adecuado para este cometido “Regístrate”, se abrirá un formulario a rellenar. Tras la validación de campos del formulario se activa la posibilidad de realizar el registro, se encripta la contraseña y se envía la petición de alta de usuario al Back-end. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 50 Una vez creado el Usuario en la BD, se muestra un mensaje de confirmación. [Figura 17. UI – Registro de Miembro Administrador] [Figura 18. Implementación – Registro de Miembro] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 51  Acceso a Gestión de Equipos) Tras hacer un “LogIn” correcto en la pantalla principal, la herramienta comprueba el tipo de usuario (Admin) y navega al catálogo (Launchpad) donde se muestra el acceso a la Gestión de Equipos mediante un Tile. Tras hacer Clic en el Tile “Gestionar Equipos”, la herramienta Navega a la vista de Gestión de Equipos, disponible sólo para Miembro/s Administrador/es. [Figura 19. UI – Acceso a Gestión de Equipos] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 52 [Figura 20. Implementación – Acceso a Gestión de Equipos IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 53  Alta de un Equipo) Desde la Vista de Gestión de Equipos, haciendo clic sobre el botón “Agregar Equipo” ubicado en el menú de la izquierda que muestra los equipos actualmente creados; la herramienta presenta un PopOver en el que se debe definir el Nombre del Nuevo Equipo y los Miembros Integrantes (al menos uno) que lo componen. Tras validar lo anterior, se activa la posibilidad de Crear un Nuevo Equipo mediante el botón “Añadir”. El Usuario, hace clic en el Botón Añadir, ordenando el envío de los datos para la creación del nuevo Equipo al Back-end. La herramienta, atacando al back-end; da de alta el Equipo, Actualiza el campo “team” de todos sus miembros y crea los contenidos estáticos del equipo relacionados con el SRS (único documento activo). Al terminar se muestra un mensaje de confirmación y se actualiza la Lista de Equipos mostrada en la vista. [Figura 21. UI – Alta de un Equipo] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 54 [Figura 22. Implementación– Alta de un Equipo] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 55  Modificar Miembros de un Equipo) Desde la Vista de Gestión de Equipos, es posible agregar o Eliminar Miembros de un Equipo mediante los Botones dispuestos para ello en la parte derecha de la Vista donde se muestran los detalles de un Equipo. Para Agregar un Miembro al Equipo, el usuario debe utilizar el botón de “Añadir Miembro”, que abre un PopOver similar al de alta de Equipos, donde se muestran los usuarios seleccionables que aún no pertenecen a ningún Equipo. Tras seleccionar uno o más usuarios se activa la posibilidad de Agregar más miembros al Equipo mediante el botón “Añadir”. El Usuario, hace clic en el Botón Añadir, ordenando el envío de los datos para agregación del nuevo Miembro al Equipo que se pide al Back-end. La herramienta, atacando al back-end; Actualiza el campo “team” de todos los miembros Nuevos seleccionados. Al terminar se muestra un mensaje de confirmación y se actualiza la Lista de Miembros del Equipo mostrada en la vista. Para Eliminar un Miembro del Equipo, simplemente se debe hacer uso del botón “Eliminar” mostrado junto a la información de cada Miembro, ordenando el envío de los datos para la exclusión del Miembro seleccionado de su Equipo, que se pide al Back-end. La herramienta, atacando al back-end; Actualiza el campo “team” del miembro Excluido dejándolo sin Valor. Al terminar se muestra un mensaje de confirmación y se actualiza la Lista de Miembros del Equipo mostrada en la vista. [Figura 23. UI – Modificar Miembros de un Equipo] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 56 [Figura 24. Implementación– Modificar Miembros de un Equipo] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 57  Baja de un Equipo) Desde la Vista de Gestión de Equipos, haciendo clic sobre el botón “Eliminar Equipo” ubicado en el menú de la izquierda que muestra los equipos actualmente creados. El Usuario, hace clic en el Botón mencionado, ordenando el envío de los datos para el borrado del Equipo al Back-end. La herramienta, atacando al back-end; borra todos los contenidos del equipo relacionados con el SRS (único documento activo), Actualiza el campo “team” de todos sus miembros y elimina el Equipo de la BD. Al terminar se muestra un mensaje de confirmación y se actualiza la Lista de Equipos mostrada en la vista. [Figura 25.UI – Baja de un Equipo] [Figura 26. Implementación – Baja de un Equipo] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 64 [Figura 36. Implementación – Edición de Contenidos] [Figura 37. Implementación – Construcción de Contenidos por tipo] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 65  Previsualización del Documento Final ) Una vez se accede a la vista del SRS, un usuario es capaz de navegar a una vista con la previsualización del documento final que será impreso. La acción se realiza al hacer clic en el botón “Previsualizar PDF”. La herramienta, recoge y organiza: todos los datos de equipo, índice y contenidos del Documento del Equipo al que pertenece el Usuario con sesión abierta. Y finalmente, construye la Vista con el formato de impresión. [Figura 38. UI– Previsualización de PDF] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 66 [Figura 39. Implementación – Previsualización de PDF] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 67  Impresión del Documento PDF ) Una vez se accede a la vista de Previsualización PDF, un usuario es capaz de imprimir el documento final SRS. La acción se realiza al hacer clic en el botón “Imprimir”. La Herramienta ataca a la Impresión del web browser, aplicando CSS media Queries, para ajustar los parámetros de impresión. [Figura 40. UI–Impresión PDF] [Figura 41. Implementación–Impresión PDF] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 68 6.2.3.3 UI y Funcionalidades Generales (Todos Los Usuarios)  LogIn ) Vista principal de la herramienta, establece un punto de acceso común. Presenta un formulario de autenticación que tras ser rellenado por el usuario permite el acceso al catálogo Launchpad tras clic en el botón “LogIn”. La herramienta, Comprueba las credenciales contra el back-end, si son válidos guarda los datos de sesión en el web Browser Session y navega al LaunchPad. [Figura 42. UI – LogIn] [Figura 43. Implementación – LogIn] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 69  Acceso al Perfil de Usuario Tras hacer un “LogIn” correcto en la pantalla principal, la herramienta comprueba el tipo de usuario (No Admin) y navega al catálogo (Launchpad) donde se muestra el acceso al Perfil de Usuario mediante un Tile. Tras hacer Clic en el Tile “Mi Perfil”, la herramienta Navega a la vista de perfil de usuario. [Figura 44. UI–Acceso a Perfil de Usuario]  Modificación de Datos del Usuario La vista “Mi Perfil” permite activar la edición de Datos de Usuario (utilizando el botón de Edición) y/o su imagen (haciendo clic sobre la imagen actual). La herramienta, comprueba la consistencia de datos y activa el botón de guardado. Tras clic en el botón de “Guardar”, la herramienta envía los datos actualizados al Back-end para persistencia y actualiza la Vista. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 70 [Figura 45. UI–Editar Perfil de Usuario] [Figura 46. Implementación –Editar Perfil de Usuario] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 71  LogOut Todos los usuarios pueden cerrar su sesión utilizando el Botón “LogOut ” ubicado en el catálogo LaunchPad o bien simplemente cerrando el navegador. El sistema limpia las variables de Sesión del Browser navega a la página principal “LogIn” [Figura 47. UI – LogOut] [Figura 48. Implementación – LogOut] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 72 7. Conclusiones y Trabajos de Futuro 7.1 Conclusiones ● El trabajo realizado muestra el desarrollo de un proyecto web casi totalmente desarrollado en la parte Front-End aprovechando la tecnología SAP UI 5. ● A pesar de que, de momento, la herramienta IS Case Tool – Docs es sólo un prototipo para generar Documentos (actualmente sólo SRS) es suficiente para servir de apoyo a la enseñanza y Aprendizaje de conceptos de Ingeniería del Software. ● IS Case Tool – Docs, plantea sin duda una herramienta de acceso web fomentando el desarrollo colaborativo entre quienes la puedan usar. ● El trabajo realizado, demuestra que es completamente loable desarrollar una Aplicación Web – SAPUI 5 atacando un back-end que nada tiene que ver con SAP. Por Tanto, se demuestra a la vez, que es posible integrar, con este tipo de aplicaciones y mediante el uso del Protocolo oData, sistemas de distinta índole; se trate de sistemas SAP, externos a SAP o ambos. ● SAP UI5 es, desde mi punto de vista, uno de los Frameworks Web que cuenta con una estructura sólida, librerías basadas en patrones de diseño y facilidad de aprendizaje y uso ágil. ● Finalmente, quiero expresar que todo el esfuerzo realizado durante el desarrollo de este trabajo ha servido para mi crecimiento a nivel profesional e incluso laboral. Las tecnologías aplicadas y la investigación realizada han permitido un continuo aprendizaje. 7.2 Trabajos de Futuro Como ya se ha comentado con anterioridad, IS Case Tool – Docs es una herramienta que se plantea como prototipo en este trabajo. Por tanto, quedan muchas tareas abiertas y por resolver, entre ellas:  Autenticación back-end Basada en Token, según la documentación investigada sobre n-oDataserver (API Rest) el proyecto está basado en el conocido framework LoopBack y por tanto existe la posibilidad de extender el back-end, incluyendo una mejor autenticación y seguridad.  Plantear otro tipo de back-end, sabiendo que el front-end está preparado para atacar cualquier servicio que maneje oData. Cabe la posibilidad de implementar un back-end más completo, sobre el cual el programador tenga un mejor control. Según algunas investigaciones realizadas, por ejemplo, es lícito desarrollar un servicio oData API REST desde cero utilizando Visual Basic y librerías Microsoft sobre Distintas Bases de Datos. Esto constituye un punto de Investigación y Desarrollo interesante para el futuro.  Completar desarrollo y Tratamiento de Plantillas, puesto que actualmente solo se puede Generar un SRS, la funcionalidad de la herramienta queda limitada, aunque su estructura haya sido preparada para generar más documentos (P.e. Plan de Proyecto y Memoria Final de IS).  Directores y Editores, son campos que se plantean en el modelo de datos que hacen referencia al director de un equipo de trabajo y al usuario que puede editar un contenido. Esto se planteó en principio con el fin de añadir una entrada en el Launchpad que permita Gestionar un Equipo IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 73 de manera interna. Es decir, designando un director que fuese capaz de gestionar las tareas o apartados que deben rellenar los miembros de su equipo.  Mejoras, a realizar sobre el CSS de Media Queries desarrollado para la impresión nativa. O incluso agregar una librería externa JS que se encargue de generar PDF. 7. Conclusions and Future Works 7.1 Conclusions ● The work carried out shows the development of a web project almost totally developed in the Front-End part, taking advantage of SAP UI 5 technology. ● Although, at the moment, the IS Case Tool - Docs is only a prototype to generate Documents (currently only SRS) is sufficient to support the teaching and Learning of Software Engineering concepts. ● IS Case Tool - Docs, undoubtedly proposes a web access tool promoting collaborative development among those who can use it. ● The work done shows that it is completely doable to develop a Web Application - SAPUI 5 attacking a back-end that has nothing to do with SAP. Therefore, it is demonstrated at the same time, that it is possible to integrate, with this type of applications and through the use of the Protocol oData, systems of different nature, whether SAP systems, external to SAP or both. ● SAP UI5, is from my point of view, one of the Web Frameworks that has a solid structure, libraries based on design patterns and ease of learning and agile use. ● Finally, to express that all the effort made during the development of this work, has served for my growth to professional and even laboral level. The applied technologies and the research carried out have allowed a continuous learning. 7.2 Future Works As previously mentioned, IS Case Tool - Docs is a tool that is proposed as a prototype in this work. There are therefore many open and unresolved tasks, among them:  Back-end authentication Token-based, according to the documentation researched on n-oDataserver (API Rest) the project is based on the well-known LoopBack framework and therefore there is the possibility of extending the back-end, including better authentication and security.  Raise another type of back-end, knowing that the front-end is ready to attach any service that handles oData. It is possible to implement a more complete back-end, over which the IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 80 b) front-End:  Levantar un servidor APACHE, para servir las páginas front-end. Se puede usar cualquier distribución APACHE cuyo directorio principal a servir sea “IScasetool/frontend/”. En esta guía se usa, para ello la distribución XAMPP.  Instalar XAMPP, en la máquina que servirá las páginas de front-end. Para saber más, puede visitar: https://www.apachefriends.org/es/index.html descargar la versión adecuada y seguir las guías de instalación.  Cambiar el directorio Raíz de servicio en XAMPP para el servidor Apache, para ello: o Acceder a la interfaz gráfica de XAMPP o Clic en el botón “Config” de la línea del servidor Apache [Figura 52. Configuración de XAMPP] o Abrir el fichero de configuración “httpd.conf” o Buscar la directiva “DocumentRoot” dentro del fichero. Debe quedar algo similar a la siguiente imagen, de acuerdo a donde se tenga almacenado el proyecto. Se recomienda mantener la estructura de la imagen. [Figura 53. Configuración de Directorio en XAMPP] o Se recomienda además cambiar el puerto escucha del servidor apache por uno diferente al 80. Puesto que es posible que se encuentre ocupado. Más información en https://www.srcodigofuente.es/tutoriales/ver-tutorial/cambiar-puerto-apache-xampp IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 81  Configurar el servicio oData como recurso de datos en el front-end. Para ello: o Abrir el fichero “IScasetool/front-end/manifest.json” o Verificar la URI que referencia al servicio oData configurado en el back-end. El puerto debe coincidir con lo descrito en la [Figura 50.] La siguiente figura muestra la configuración por defecto de la URI basada en el servicio presentado en producción sobre este trabajo. [Figura 54. Configuración de conexión a oData desde Front-end]  Finalmente, Iniciar el servidor Apache desde la interfaz de XAMPP. Al finalizar la herramienta será accesible desde el navegador web con la URL o IP Configurada. IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 82 [Figura 55. Iniciar Apache desde XAMPP]  Como Recomendación Final, no se debe olvidar que antes de poner en producción la herramienta y/o publicarla; es conveniente dar de alta a Miembro/s Administrador/es. Activando para ello, el flag dispuesto en el fichero “IScasetool/frontend/config/config.json”. Que actúa sobre la UI permitiendo el alta de dichos Miembros. Tras terminar las altas, se debe volver a desactivar. [Figura 56. Configuración de Administrador Front-end] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 83 Apéndice B. Manual de Usuario. A continuación, se explica cómo utilizar las principales funcionalidades ofrecidas por “IS Case Tool – Docs”, desde un punto de vista enfocado a los usuarios. Para ello sólo hace falta seguir los pasos descritos a continuación: Para Miembro Administrador:  Registro de Usuario) o Acceder a la herramienta en la vista principal “LogIn” o Hacer clic en el botón “Regístrate”, se abrirá un formulario a rellenar. o Rellenar los campos solicitados de forma coherente. De lo contrario no es posible realizar el Registro. o Activar el botón “Switch” de “Registro como Administrador” o Se activa el botón “Registrarse” al pie del formulario. o Clic en el botón “Registrarse”. Una vez creado el Usuario en la BD, se muestra un mensaje de confirmación. [Figura 57. Réplica de Figura 17.] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 84  Acceso a Gestión de Equipos) o Realizar un “LogIn” siendo Miembro Administrador (ver Funcionalidades Generales) o Desde el catálogo “Launchpad” clic sobre el Tile “Gestión de Equipos”. [Figura 58. Réplica de Figura 19.] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 85  Alta de un Equipo) o Desde la Vista de “Gestión de Equipos”, clic sobre el botón “Agregar Equipo” en la cabecera del menú de la izquierda o Se abre un formulario y una lista de Miembros sin Equipo Asignado o Definir el Nombre del Nuevo Equipo o Seleccionar los Miembros Integrantes (al menos uno) para el nuevo Equipo. o Se activa el botón “Añadir” al pie del Formulario. o Clic en el botón “Añadir”. o El Nuevo equipo creado aparece en la lista. [Figura 59. Réplica de Figura 21] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 86  Agregar Miembros a un Equipo ) o Acceder a la “Gestión de Equipos” o Seleccionar Equipo concreto en el menú de la izquierda. o Clic en el botón “+”(añadir Miembro). Ubicado en la cabecera de la lista de Miembros del equipo Seleccionado. o Se abre una lista de Miembros disponibles. o Seleccionar uno o más usuarios de la lista mostrada o Se activa el botón “Añadir” al pie de la Lista de Miembros Seleccionados. o Clic en el botón “Añadir”. o Los miembros Nuevos aparecen como parte del Equipo.  Eliminar Miembro de un Equipo) o Acceder a la “Gestión de Equipos” o Seleccionar Equipo concreto en el menú de la izquierda. o Clic en el botón “Eliminar” mostrado junto a la información del Miembro que se desea excluir del Equipo. o El miembro excluido desaparece de la Lista de Miembros del Equipo. [Figura 60. Réplica de Figura 23.] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 87  Baja de un Equipo) o Acceder a la “Gestión de Equipos” o Seleccionar Equipo concreto en el menú de la izquierda. o Clic en el botón “Eliminar” mostrado en la cabecera del Menú de la Izquierda. o El Equipo desaparece del Menú de la Izquierda. [Figura 61. Réplica de Figura 25.] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 88 Para Miembro (No Administrador)  Registro de Usuario) o Acceder a la herramienta en la vista principal “LogIn”. o Hacer clic en el botón “Regístrate”, se abrirá un formulario a rellenar. o Rellenar los campos solicitados de forma coherente. De lo contrario no es posible realizar el Registro. o Se activa el botón “Registrarse” al pie del formulario. o Clic en el botón “Registrarse”. Una vez creado el Usuario en la BD, se muestra un mensaje de confirmación. [Figura 62. Réplica de Figura 27.] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 89  Acceso a un Documento concreto (SRS en este caso) o Realizar un “LogIn” siendo Miembro No Administrador (ver Funcionalidades Generales) o Desde el catálogo “Launchpad” clic sobre el Tile “SRS”. [Figura 63. Réplica de Figura 28.] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 96  Modificación de Datos del Usuario) o Acceder a “Mi Perfil” o Se muestra un formulario deshabilitado con los datos actuales. o Clic sobre el botón “Editar” ubicado a la derecha sobre los datos. o Se habilitan todos los campos del formulario y aparece el botón de “Reset” que sirve para cancelar la acción. o Modificar los campos que lo requieran de forma coherente. De lo contrario no se puede continuar al paso siguiente. o Se hace visible el botón “Guardar”. o Clic Sobre el botón “Guardar”. o Se recibe un mensaje de Confirmación de Cambios. o Se muestran los datos actualizados y se deshabilita el formulario. [Figura 72. Réplica de Figura 45.] IS CASE TOOL - DOCS Daniel, Reyes Tubón Madrid - 2018 97  LogOut) o Acceder al LauncPad. o Clic en el Botón “LogOut”, ubicado en la cabecera a la derecha del catálogo LauncPad. o Se muestra la vista Principal “LogIn”. o Otra opción es simplemente, cerrar la istancia del Navegador. [Figura 73. Réplica de Figura 47.]