Aplicación para la configuración automática del certificado digital en un ordenador personal

Trabajo de Fin de Grado Aplicación para la configuración automática del certificado digital en un ordenador personal Julio 2014 – Las Palmas de Gran Canaria Alumno: Ravi Raj Khubchandani Khubchandani Grado en Ingeniería Informática (Sistemas de Información) Tutores: Dr. Francisco Javier Carreras Riudavets Departamento de Informática y Sistemas Ángel Sánchez de la Cruz Oficina Técnica de la Administración Electrónica Índice Introducción......................................................................................................................................................1 Estado actual y objetivos..................................................................................................................................2 Situación actual...........................................................................................................................................2 Objetivos.....................................................................................................................................................2 Competencias cubiertas....................................................................................................................................3 Trabajo Fin de Grado...................................................................................................................................3 Comunes a la Ingeniería Informática...........................................................................................................3 Ingeniería del software................................................................................................................................5 Sistemas de Información..............................................................................................................................5 Aportaciones.....................................................................................................................................................6 Aportación al medio socio-económico........................................................................................................6 Aportación al medio técnico........................................................................................................................6 Normativa y legislación....................................................................................................................................6 Ley Orgánica de Protección de Datos (LOPD)............................................................................................6 Licencias del software usado.......................................................................................................................6 Requisitos.........................................................................................................................................................8 Planificación y estructuración del proyecto......................................................................................................8 Tecnologías, herramientas y metodologías aplicadas........................................................................................9 Tecnologías y herramientas.........................................................................................................................9 Metodologías.............................................................................................................................................10 Principios, mecanismos y patrones de diseño usados......................................................................................11 Análisis y diseño.............................................................................................................................................13 Archivo de configuración..........................................................................................................................13 El modelo de negocio................................................................................................................................15 Cabeceras de SpecLists..............................................................................................................................17 Tipos de instrucciones...............................................................................................................................18 Interpretar los archivos de configuración...................................................................................................21 Identificación del sistema..........................................................................................................................22 Ejecución de SpecSets...............................................................................................................................23 Sistema de logging.....................................................................................................................................24 Acceso a funciones del sistema operativo y sistema de archivos...............................................................25 Programas auxiliares..................................................................................................................................27 Diseño e implementación de la interfaz de usuario.........................................................................................28 Diseño........................................................................................................................................................28 Implementación.........................................................................................................................................30 Pruebas y validación de uso............................................................................................................................31 Diagrama de secuencias..................................................................................................................................31 Trabajos futuros..............................................................................................................................................33 Conclusiones...................................................................................................................................................33 Fuentes de información...................................................................................................................................34 Anexo.............................................................................................................................................................37 Diagramas de secuencias...........................................................................................................................37 Diagrama de clases UML completo...........................................................................................................40 Manual de usuario.....................................................................................................................................41 Índice de ilustraciones Ilustración 1: Marco de trabajo de Scrum.........................................................................................................8 Ilustración 2: Marco de trabajo de la arquitectura MVC.................................................................................12 Ilustración 3: Ejemplo de sistema soportado...................................................................................................13 Ilustración 4: Ejemplo de comprobación de requerimiento.............................................................................14 Ilustración 5: Ejemplo de instalación de un requerimiento.............................................................................14 Ilustración 6: Ejemplo de desinstalación de un requerimiento........................................................................15 Ilustración 7: Ejemplo de identificación de requerimientos instalados...........................................................15 Ilustración 8: Diagrama de clases del modelo de negocio...............................................................................17 Ilustración 9: Diagrama de clases del intérprete.............................................................................................22 Ilustración 10: Diagrama de clases para identificar un sistema.......................................................................23 Ilustración 11: Diagrama de clases para ejecutar SpecSet...............................................................................24 Ilustración 12: Diagrama de clases del sistema de logging.............................................................................25 Ilustración 13: Ejemplo de análisis sintáctico de un archivo...........................................................................28 Ilustración 14: Diseño inicial de la interfaz de usuario...................................................................................29 Ilustración 15: Diseño de la interfaz actual, inicio del programa....................................................................29 Ilustración 16: Diseño actual de la interfaz, menú de instalación personalizada.............................................30 Ilustración 17: Diagrama de secuencias, carga inicial.....................................................................................31 Ilustración 18: Diagrama de secuencias, instalación automática.....................................................................32 Ilustración 19: Diagrama de secuencias, carga inicial.....................................................................................37 Ilustración 20: Diagrama de secuencias, instalación automática.....................................................................37 Ilustración 21: Pantalla de inicio de la aplicación...........................................................................................41 Ilustración 22: Menú de análisis del equipo, análisis negativo........................................................................42 Ilustración 23: Diálogo de análisis negativo...................................................................................................42 Ilustración 24: Menú de instalación personalizada.........................................................................................43 Ilustración 25: Realización de instalación automática....................................................................................44 Ilustración 26: Diálogo de análisis positivo....................................................................................................44 Ilustración 27: Menú de análisis del equipo, análisis positivo........................................................................45 Ilustración 28: Menú de desinstalación personalizada....................................................................................46 Ilustración 29: Confirmación de desinstalación automática............................................................................46 Ilustración 30: Menú de desinstalación automática.........................................................................................47 Ilustración 31: Menú de Contacto...................................................................................................................48 Introducción En los tiempos modernos los equipos informáticos vienen configurados de fábrica para que el usuario pueda disfrutar de su producto desde el momento en que lo adquiere, pero existen situaciones en que se necesita cumplir con una serie requerimientos. Esta situación es común en empresas, donde muchos trabajadores necesitan sus ordenadores configurados de cierta manera. Gracias a las nuevas tecnologías se han desarrollado elementos software que detecten el problema y lo solucionen automáticamente, adquiriendo archivos desde la red en caso necesario. Todo ello con una intervención mínima del usuario. Estas tareas se podrían hacer de forma manual, pero consumiría mayor cantidad de tiempo y por tanto, se resta productividad. Este proyecto se ha creado como una solución a un problema real encontrado en la administración de la Universidad de Las Palmas de Gran Canaria (en adelante ULPGC), con el cual se pretende facilitar y automatizar el proceso de configuración de un ordenador personal de forma que un miembro de la comunidad universitaria pueda identificarse ante la página web institucional usando su certificado electrónico emitido por la Fábrica Nacional de Moneda y Timbre. 1 Estado actual y objetivos Hoy en día existe diversidad de servicios tanto privados como públicos que pueden ser usados de forma telemática, éstos son totalmente seguros y aportan gran comodidad al usuario. Dependiendo del tipo de servicio que se ofrece se requiere de unos componentes u otros que tienen que ser instalados en el equipo del usuario. Si se usa más de un servicio, el hecho de tener que cumplir distintos requisitos puede causar rechazo a los mismos y optar por medios más tradicionales. Situación actual Con la idea de automatizar la configuración de un equipo para un fin concreto, distintos programas han sido creados, ejemplos de estos son el configurador de redes inalámbricas para acceder a universidades europeas Eduroam y el configurador de navegadores web de la Agencia Tributaria de España. Ambos están disponibles como programas que se pueden descargar desde sus respectivas páginas web, la ejecución de estos programas modifica los archivos del equipo de la forma en que sea necesaria y de forma automática en cuestión de minutos para que el usuario siga con sus tareas. Actualmente la configuración del funcionamiento de la firma electrónica de la ULPGC se realiza manualmente, no existe ninguna solución que automatice este proceso. En caso de problemas se contacta con la oficina técnica de la administración electrónica. Objetivos El objetivo de este proyecto es desarrollar un software que instale y configure automáticamente los componentes necesarios para que la firma electrónica funcione correctamente en al menos un sistema operativo y un navegador web concretos. Se ha elegido el sistema operativo Windows 7 y navegador web Internet Explorer 11. Para tomar esta decisión se han tenido en cuenta las siguientes consideraciones: •Microsoft ya no da soporte a Windows XP, por lo que en poco tiempo la administración debería migrar a otro sistema operativo. •Internet Explorer se posiciona entre los navegadores más usados entre el personal de la administración. Se ha ideado desde cero un sistema de configuración automática de dicho proceso pero que a la vez es flexible y escalable a otras necesidades. La idea es que el usuario sin ayuda técnica, usando el programa tenga listo su equipo con un mínimo esfuerzo y aproveche al máximo su tiempo. Más adelante vemos en profundidad el funcionamiento del primer prototipo, pero los principales objetivos del proyecto son: •Identificar los requerimientos del equipo en base al sistema operativo y navegadores web usados. •Tras identificar las necesidades, el usuario puede elegir los navegadores web que quiere configurar para usar la firma electrónica. •Instalación de los componentes, todos los componentes o cada uno individualmente bajo petición del usuario. •Mantenimiento de un archivo de log para monitorizar todo cambio realizado para poder revertir el equipo al estado anterior. •Desinstalar componentes instalados por el propio programa. El sistema es escalable a otras necesidades que puedan aparecer en el futuro. Esto es así ya que los requerimientos para cada sistema operativo y navegador se establece mediante un archivo de configuración, de forma transparente al usuario. Esto permite que actualizando este archivo, el programa siga siendo útil sin realizar modificaciones. La identificación mediante certificado electrónico es más segura que mediante usuario y contraseña. Además 2 permite a los miembros de la comunidad universitaria realizar tareas administrativas a través de la red. Este proyecto ha permitido poner en práctica el conocimiento sobre diseño e ingeniería de software adquiridos en la carrera. En el desarrollo del proyecto se ha seguido la metodología ágil Scrum y Lean Software Development, se ha ido desarrollando de forma progresiva, manteniendo reuniones periódicas para la supervisión del tutor. En cada reunión se ha mostrado una versión del programa cada vez más completa hasta llegar a una primera versión prototipo que cumple con los requisitos establecidos. Además me ha dado la oportunidad de desarrollar el aprendizaje autónomo así como un conocimiento en cierta profundidad sobre las distintas versiones del sistema operativo Windows y su sistema de registros. Competencias cubiertas Trabajo Fin de Grado TFG01 Ejercicio original a realizar individualmente y presentar y defender ante un tribunal universitario, consistente en un proyecto en el ámbito de las tecnologías específicas de la Ingeniería en Informática de naturaleza profesional en el que se sinteticen e integren las competencias adquiridas en las enseñanzas. Este proyecto se diseñó desde cero, el desarrollo se ha llevado a cabo de forma modular aplicando arquitecturas de software y diseño de patrones estudiados en asignaturas de la carrera. Se ha elegido desarrollarlo usando herramientas modernas y de uso extendido. Al ser modular, al proyecto se pueden agregar componentes nuevos que podrían incrementar su funcionalidad a la vez que componentes de este proyecto se pueden usar en otros. Al usar herramientas modernas y de uso extendido se evita que se convierta en software obsoleto a la vez que la documentación disponible es amplia. Comunes a la Ingeniería Informática CII08 Capacidad para analizar, diseñar, construir y mantener aplicaciones de forma robusta, segura y eficiente, eligiendo el paradigma y los lenguajes de programación más adecuados. Antes de iniciar el desarrollo de la aplicación se investigó distintos sistemas y lenguajes de programación disponibles para asegurarse de que la opción tomada es la correcta. Se planteó la posibilidad de que el proyecto fuese una aplicación web pero dada la naturaleza del software y sus requerimientos esta posibilidad no se pudo realizar y se optó por el lenguaje C# usando el framework .NET 4.5 desarrollado por Microsoft. Gran parte del tiempo disponible para el desarrollo se ha invertido en la correcta programación de patrones de diseño de forma que el mantenimiento y ampliación del programa se pueda realizar de la forma más eficiente posible. Se ha optado por una arquitectura MVC por su sencilla implementación pero siendo a la vez eficiente y su capacidad para cumplir con los requisitos del programa, también se han usado más patrones de diseño para los componentes del programa. CII010 Conocimiento de las características, funcionalidades y estructura de los Sistemas Operativos y diseñar e Implementar aplicaciones basadas en sus servicios. El proyecto se ha desarrollado para sistemas Windows, dada la naturaleza del proyecto se ha realizado una importante investigación sobre su sistema de registros, las diferentes opciones que dispone en su sistema de 3 ficheros para archivos temporales, archivos de opciones personales individuales para cada usuario y sus variables de entorno. Un motivo por el cual se opta por usar C# y .NET es que este framework está desarrollado por Microsoft y facilita y agiliza el desarrollo de aplicaciones que necesiten conocimiento del hardware y sistema operativo del equipo en que se ejecuta. CII012 Conocimiento y aplicación de las características, funcionalidades y estructura de las bases de datos, que permitan su adecuado uso, y el diseño y el análisis e implementación de aplicaciones basadas en ellos. El proyecto ha permitido conocer en profundidad el funcionamiento, estructuración y uso del registro de Windows, el cual es una base de datos jerárquica así como su integración para ser accedida desde programas externos para su lectura y escritura. CII014 Conocimiento y aplicación de los principios fundamentales y técnicas básicas de la programación paralela, concurrente, distribuida y de tiempo real. El programa desarrollado se ejecuta en diferentes hilos de ejecución concurrentes que se comunican entre ellos. Se ha usado técnicas y estructuras propias de .NET para la programación de los mismos ya que permite la ejecución paralela de varios hilos sin que el trabajo de un hilo afecte al de otro. CII016 Conocimiento y aplicación de los principios, metodologías y ciclos de vida de la ingeniería de software. Se han seguido metodologías de desarrollo ágil durante el proceso de desarrollo, de forma que pequeños cambios no han supuesto grandes cambios en el proyecto. Se han mantenido reuniones periódicas con los tutores, como propone la metodología Scrum, en cada reunión se ha mostrado una versión cada vez más completa del programa. Al implementar un requisito se hacía de forma que el programa respondiese de la forma esperada y luego se refactorizaba para obtener una versión mejorada, como establece la metodología Lean Software Development. En el desarrollo del programa se han usado los patrones de diseño más convenientes para cada componente, como el patrón 'Command' para programar la acción de la interfaz; 'SRP' o Single Responsibility Principle, de forma que se ha procurado que cada clase tenga un solo propósito y sea independiente del resto; y así otros patrones generales como el 'Principio de inversión de dependencias', clases 'Singleton' o 'Factory'. Todo ello modularizado de forma que se respete el principio 'DRY' o Don't Repeat Yourself para evitar repetición de código. CII017 Capacidad para diseñar y evaluar interfaces persona computador que garanticen la accesibilidad y usabilidad a los sistemas, servicios y aplicaciones informáticas. Para el funcionamiento de este programa se necesita de un archivo de configuración, su formato se ha diseñado de forma que permita insertar la mayor cantidad de información de la forma más cómoda posible. Este archivo se verá en detalle más adelante. La interfaz de usuario también se ha diseñado de forma que su uso sea intuitivo al usuario final, reduciendo el número de ventanas en la medida de lo posible. Más adelante veremos que la primera versión de la interfaz fue modificada de forma que resulte más familiar al estilo que el usuario está acostumbrado. 4 Ingeniería del software IS01 Capacidad para desarrollar, mantener y evaluar servicios y sistemas software que satisfagan todos los requisitos del usuario y se comporten de forma fiable y eficiente, sean asequibles de desarrollar y mantener y cumplan normas de calidad, aplicando las teorías, principios, métodos y prácticas de la ingeniería del software. En el desarrollo del proyecto se ha llevado a cabo una detallada planificación de todos sus aspectos funcionales. Se han puesto en práctica las diferentes etapas del ciclo de vida de un software. Desde la especificación de requisitos hasta su testeo en distintos equipos. Se ha puesto énfasis en control del estado de los datos en cada momento para evitar fallos en el programa, de esta forma es más robusto y fiable. Se han empleado buenas prácticas de programación, se ha documentado toda acción realizada, se han realizado prototipos de la interfaz, el código es modular y legible aunque se han añadido algunos comentarios en el código en donde es necesario. Se ha desarrollado aplicando arquitecturas y patrones de diseño ya consolidados, de esta forma es más fácil de mantener y realizar cambios cuando sea necesario. IS05 Capacidad de identificar, evaluar y gestionar los riesgos potenciales asociados que pudieran presentarse. El mayor riesgo para el proyecto era la variación en el tipo de requisitos que tenía el programa. Algunos requisitos consumieron más tiempo por el objetivo que tenían ya que requerían un conocimiento avanzado, se tuvo que investigar la solución al problema o la documentación para resolver el problema es escasa. Por este motivo se llegó a un consenso en los requisitos a cumplir en el tiempo disponible. Sistemas de Información SI01 Capacidad de integrar soluciones de Tecnologías de la información y las comunicaciones y procesos empresariales para satisfacer las necesidades de información de las organizaciones, permitiéndoles alcanzar sus objetivos de forma efectiva y eficiente, dándoles así ventajas competitivas. El programa está pensado para su uso en red. Esto es así ya que el programa se comunica con los servidores remotos de la ULPGC y obtener archivos alojados en el mismo. El software genera archivos de log para cada usuario, en un principio estos logs estaban pensados para ser alojados también en los servidores de la ULPGC, por ello debían tener identificadores únicos, esto se logró usando la herramienta 'WMI', Windows Management Instrumentation, como veremos más adelante. En una de las iteraciones del software se decide que el log se aloja en el propio equipo del usuario pero la implementación ya está realizada, por lo que si en el futuro se decide alojar estos logs en la nube, el cambio no será muy costoso y la competencia y el conocimiento para ello ya han sido adquiridos. 5 Aportaciones Aportación al medio socio-económico El uso de esta aplicación aporta a sus usuarios la comodidad de automatizar el proceso de configuración de la firma electrónica en sus ordenadores. Afecta de manera económica ya que el propio usuario puede configurar con éxito su propio equipo sin ayuda y en menos tiempo. Por este motivo tanto el usuario como el personal técnico pueden emplear su tiempo en otras tareas. Si el programa cumple con el nivel de calidad exigido, se pondrá a disposición de la comunidad universitaria. Aportación al medio técnico El proyecto está estructurado de forma que se pueden sustituir o añadir módulos, se pueden integrar nuevas funcionalidades si se desease. Se introducen datos en el programa mediante un archivo de configuración. En este archivo se establecen todos los requerimientos del equipo para que funcione la firma electrónica. Cambiar este archivo supondría que el usuario tiene a su disposición las actualizaciones que hubiesen. Por estos dos motivos se alarga la vida útil del software a bajo coste. Normativa y legislación Ley Orgánica de Protección de Datos (LOPD) La Ley Orgánica 15/1999 de 13 de diciembre de Protección de Datos de Carácter Personal tiene el objetivo de garantizar y proteger las libertades públicas y derechos fundamentales de las personas físicas en lo concerniente al tratamiento y comunicación de sus datos personales independientemente del soporte usado. Esta ley afecta a todos los datos que hacen referencia a personas físicas registradas sobre cualquier tipo de soporte (informático o no), aunque están excluidos datos recogidos para uso doméstico y material clasificado por el estado que tratan sobre delincuencia organizada y terrorismo. Este proyecto trata datos del equipo local y almacena un archivo de log en el mismo, pero en ningún caso se envía información a servidores remotos ni almacena información personal del usuario, por lo que no es necesario cifrarlo. Licencias del software usado En la realización de este proyecto se ha usado tanto software libre como propietario, cada uno con sus respectivas licencias. A continuación vemos cada una de ellas: Software propietario Se trata de software que puede ser gratuito o no, pero se necesita de permiso para poder usarlo para ciertos fines y no otros. Estas pueden ser su modificación, su distribución o copia. El software propietario usado en el proyecto se ha conseguido por medio de la suscripción de la ULPGC al programa MSDN de Microsoft. Éstos son: •Microsoft Visual Studio 2012 Premium •Microsoft Windows 7 Professional •Microsoft Visio 2013 6 Command El patrón Command permite diseñar clases que encapsulan las acciones que se deben ejecutar como respuesta a un evento ocurrido en la interfaz de usuario. Análisis y diseño En este apartado se explica la funcionalidad de los módulos desarrollados, así como su integración y objetivo con el cuál fue ideado. Junto a cada módulo que se explique se muestra su diagrama UML parcial, el diagrama UML completo está disponible en el anexo. Por último veremos cómo funcionan los módulos en conjunto para resolver un caso de uso de ejemplo. Archivo de configuración El configurador de firma electrónica se basa en dos archivos de configuración. Son archivos de texto que puede ser editado usando cualquier editor de texto compatible con la codificación UTF-8, como por ejemplo Notepad en Windows. Al primero lo llamaremos 'archivo de configuración principal' y es el mismo para todos los usuarios. Para ser usado será descargado desde el servidor de la ULPGC por el configurador. El segundo es el archivo de log, es único por cada usuario, lo vemos más adelante en este apartado. Su formato ha sido diseñado específicamente para este proyecto. Su estructura es sencilla, permite insertar líneas vacías y escribir comentarios. Está estructurado por bloques, existen cinco bloques definidos por sus etiquetas de apertura y cierre. En estos bloques se especifican grupos de instrucciones, éstas tienen funciones diferentes, como leer un registro o un archivo y compararlo con un valor, escribir un valor en un registro o archivo o ejecutar un proceso nuevo en el equipo. Los comentarios comienzan con el símbolo // y abarcan una línea del archivo. Todas las instrucciones y sintaxis relacionadas con el archivo se describen en siguientes apartados. En este documento se va a referir como 'sistema soportado' como un sistema que cumple ciertas características y para el cuál sabemos los requerimientos que debe cumplir para que la firma electrónica funcione correctamente. Por cuestiones de compatibilidad de la configuración de la firma electrónica con diferentes sistemas operativos de Microsoft y diferentes navegadores disponibles para el mismo, los requerimientos para éstos pueden variar. El primer bloque, el bloque 'NEEDS', comienza con la etiqueta de apertura #NEEDS y se cierra con #/NEEDS. Este bloque contiene grupos de instrucciones que sirven para identificar un sistema soportado, al mismo se le asigna una lista de requerimientos que el equipo debe cumplir. Existe un grupo de instrucciones por cada uno. Vemos un ejemplo: En este ejemplo se leen tres valores del registro de Windows, se comprueba que la versión de Windows instalada en el equipo en que se ejecuta el configurador es la 6.1, el nombre de la versión comienza con Windows 7, '*' indica que la edición de Windows 7 es indiferente. Por último se comprueba que el equipo tiene instalado el navegador web Internet Explorer 11. Si estas tres condiciones se cumplen, en el equipo deben estar instalados los requerimientos indicados por 13 Ilustración 3: Ejemplo de sistema soportado 'CertificadosDigitales', 'Capicom', 'LectorPDF', 'Java', 'IE_SafeSite' y 'IE11_VistaCompatible' para que la firma electrónica funcione correctamente en Internet Explorer 11 (indicado por IE). Ya tenemos identificados los requerimientos que debe cumplir el sistema, ahora hay que especificar cómo se tiene que comprobar que estos requerimientos se cumplen o no. La especificación de estas comprobaciones se realizan en el segundo bloque, llamado CONFIG, comienza con la etiqueta #CONFIG y se cierra con #/CONFIG. Este bloque contiene grupos de instrucciones con las que se puede determinar si el equipo cumple con los requerimientos identificados en el bloque NEEDS. Existe un grupo de instrucciones por cada requerimiento necesario. Vemos un ejemplo: En este ejemplo se muestra cómo averiguar si la máquina virtual Java está instalada, el formato completo de la cabecera está explicada en el siguiente apartado, pero podemos ver que se indica 'SUCCEED_ONE', esto significa que para considerar que Java está instalado, como mínimo una de las instrucciones debe ejecutarse con éxito. En este caso, sabiendo que la versión mínima compatible con la firma electrónica de la ULPGC es Java 7 update 55 y que la versión actual es Java 8 update 5, se considera que se cumple el requerimiento 'Java' si el equipo tiene instalado Java 7 update 55, Java 7 update 60 o Java 8 update 5. En el bloque CONFIG también tienen que estar presentes las comprobaciones a realizar para verificar el cumplimiento del resto de requerimientos identificados. Con los dos bloques presentados podemos comprobar qué requerimientos debe cumplir un equipo y cómo saber si éstos se cumplen. En el bloque ONFAIL, que comienza con la etiqueta #ONFAIL y termina con #/ONFAIL se especifica al programa, mediante grupos de instrucciones, las acciones que se deben realizar para instalar cada requerimiento si se ha determinado que este no se cumple. Vemos un ejemplo: En este ejemplo vemos las acciones a realizar si el requerimiento 'Java' no está instalado, en este bloque se definen los grupos de instrucciones para el resto de requisitos. Primero se copia al equipo local el ejecutable del programa java7_55.exe desde el servidor de la ULPGC y luego se lanza su ejecución. Uno de los requisitos funcionales de este proyecto es que el software debe ser capaz de deshacer los cambios realizados en el equipo. Para cumplir con este objetivo se introduce el bloque UNDO, comenzado y terminado por las etiquetas #UNDO y #/UNDO, respectivamente. Vemos un ejemplo: 14 Ilustración 4: Ejemplo de comprobación de requerimiento Ilustración 5: Ejemplo de instalación de un requerimiento En este ejemplo vemos las acciones a realizar para desinstalar el requerimiento 'Java', puede haber más grupos que indiquen cómo deshacer otros requerimientos. En el bloque UNDO del archivo de configuración principal se define cómo desinstalar requerimientos pero teniendo en cuenta que estas acciones se realizan de la misma forma en todos los equipos, es decir, para desinstalar el requisito siempre se siguen las mismas instrucciones, independientemente del equipo. Se genera un archivo de log individual para cada usuario. Este archivo tiene el mismo formato que el archivo de configuración principal pero contiene el bloque UNDO y el bloque INSTALLED que vemos a continuación. Es necesario dividir el bloque UNDO ya que hay situaciones en las que un mismo requerimiento no se desinstala de la misma forma para dos equipos distintos. Este tipo de situaciones se da, por ejemplo, al escribir un valor en un registro. Si este ya existe, hay que guardar este valor existente para poderlo restaurar cuando se vaya a deshacer el cambio realizado en el equipo. Si el registro no existe, la instrucción para deshacer el cambio será borrar el registro. El archivo de log es generado por el programa y su contenido varía en función de las acciones del usuario. Por último, el bloque INSTALLED contiene los requisitos instalados. En el ejemplo vemos que se ha instalado Java y Capicom usando el configurador. A la hora de deshacer cambios se realizan las acciones del bloque UNDO pertenecientes a dichos requerimientos. El modelo de negocio Vamos a ver la estructura de datos diseñada para cargar en memoria principal los archivos de configuración y trabajar con ésta información. Como se ha visto, existen cinco bloques, en cuatro de éstos existen grupos de instrucciones. Cada bloque tiene su propia razón de ser y almacena unos datos u otros. Por este motivo debe existir más de un tipo de grupo de instrucciones. A su vez existen diferentes tipos de instrucciones, según la acción que se tenga que realizar. Por este motivo tiene que existir más de un tipo de instrucción. Se ha identificado que los grupos de instrucciones en los bloques CONFIG, ONFAIL y UNDO tienen la misma estructura. El bloque NEEDS también tiene grupos de instrucciones pero con unas necesidades diferentes. El bloque INSTALLED almacena una lista de los nombres de los requerimientos instalados. Teniendo esta idea en mente se ha creado la clase SpecList. Un SpecList define un grupo de instrucciones. Como se ha dicho, existen dos clases de grupos de instrucciones, existen dos clases herederas de SpecList, IdentificationSpecList, que define grupos de instrucciones del bloque NEEDS e InstallationSpecList, que define grupos de instrucciones de los bloques CONFIG, ONFAIL y UNDO. El equivalente a una instrucción en el modelo de negocio es la clase Spec (de 'specification'). Como existen distintas clases de instrucciones, existen distintas clases de Specs, cada una con su propia finalidad. El contenido del bloque INSTALLED se traduce como una lista de elementos de tipo ristra (List<string>). 15 Ilustración 6: Ejemplo de desinstalación de un requerimiento Ilustración 7: Ejemplo de identificación de requerimientos instalados Al igual que un SpecList es una colección de Specs, un SpecSet es una colección de SpecLists. Se ha definido de esta forma ya que un bloque puede tener varios grupos de instrucciones o lo que es lo mismo, un SpecSet tener varios SpecLists. Para agrupar estos elementos existe la clase DataSet que almacena: •cuatro SpecSet, correspondiente a los bloques NEEDS, CONFIG, ONFAIL y UNDO. •un List<string>, correspondiente al bloque INSTALLED. Estos son los tipos de Spec, que representan diferentes tipos de instrucciones: •CopySpec: guarda información relativa sobre archivos que deben ser copiados al equipo local. •DeleteSpec: guarda información relativa a elementos del equipo local que deben ser eliminados. •DirectorySpec: guarda información relativa a operaciones de lectura o escritura de directorios. •FileSpec: guarda información relativa a operaciones de lectura o escritura de archivos. •InfoSpec: guarda información que será mostrada al usuario por pantalla. •MSCertSpec: guarda información relativa a operaciones de lectura o escritura de certificados digitales. •RegistrySpec: guarda información relativa a operaciones de lectura o escritura en valores de registro. •SubKeySpec: guarda información relativa a operaciones de lectura o escritura de subclaves de registro. •ThreadSpec: guarda información sobre hilos de ejecución que serán solicitados. Dependiendo del bloque que se trate, se permiten un tipo de Spec u otros. Las clases IdentificationSpecList e InstallationSpecList heredan de la clase List<Spec>. En el apartado anterior vimos que un SpecList del bloque NEEDS está destinado a determinar los requerimientos para un sistema soportado y además indica los navegadores a los que dichos requerimientos están destinados a configurar. En el modelo de negocio, cada SpecList tiene asociado un objeto Browsers, son tres variables booleanas que identifican si dicho SpecList está destinado, según el archivo de configuración, para Internet Explorer, Google Chrome y Firefox. 16 Cabeceras de SpecLists Los SpecLists son grupos de instrucciones. Existen dos tipos de SpecList. Un SpecList debe comenzar después de una etiqueta de apertura de un bloque. Los IdentificationSpecList pertenecen al bloque NEEDS e identifican sistemas soportados. Los InstallationSpecList pertenecen a los bloques CONFIG, ONFAIL y UNDO, definen grupos de instrucciones para comprobar, instalar o desinstalar un requerimiento, respectivamente. Para comenzar cada tipo de SpecList se especifican unos parámetros u otros. 17 Ilustración 8: Diagrama de clases del modelo de negocio Flags Se puede ver este archivo en el modelo de negocio, esta es una clase estática en la que se han definido cuáles son todos los signos y palabras reconocidos por el intérprete a la hora instanciar objetos a partir de los archivos de configuración de forma correcta. IdentificationSpecList Identifican cada sistema soportado, para ello también tienen que definir sus requerimientos. Comienzan con el símbolo % seguido de los nombres de los requerimientos, si hay más de un requerimiento, se separa cada uno por el símbolo :: Finalmente se especifican los navegadores para los cuáles están dirigidos estos requerimientos, los valores posibles son IE, FIREFOX y CHROME, en caso de que la misma sea aplicable a más de un navegador, se separan mediante el símbolo -. Los nombres de los requerimientos escritos en los IdentificationSpecList serán identificadores únicos de cada requerimiento. Estos identificadores se usan en el resto de bloques para formar sus InstallationSpecList. En la Ilustración 3 podemos ver un ejemplo, en este se necesitan hasta seis requerimientos para configurar Internet Explorer. InstallationSpecList Especifican cómo comprobar si un requerimiento está instalado, cómo instalarlo y desinstalarlo. A la hora de ejecutar un InstallationSpecList para considerar que su ejecución es exitosa se especifica uno de los tres criterios siguientes, a este criterio se le llamará 'grado de satisfacción': •SUCCEED_ALL: se considera que tiene éxito si todas sus instrucciones han tenido éxito. •SUCCEED_ONE: se considera que tiene éxito si al menos una de sus instrucciones ha tenido éxito, por lo tanto se detiene su ejecución tras ejecutar su primera instrucción exitosa. •SUCCEED_POSSIBLE: se ejecutan todas sus instrucciones indiferentemente de cuáles han tenido éxito y cuáles no. Comienzan con el símbolo % seguido del identificador del requerimiento al que corresponde. A este dato le siguen cuatro parámetros más. El primero será el grado de satisfacción, seguido de su nombre (este nombre no es un identificador, será el nombre que se muestre al usuario a través de la interfaz). Los dos últimos parámetros serán utilizados para cumplir con el objetivo de permitir la instalación de componentes de forma individual bajo petición del usuario. Es información ampliada sobre el requerimiento mostrada al usuario durante la instalación personalizada. Todos los datos en esta cabecera se separan por el símbolo ::. En el bloque CONFIG es necesario especificar todos los parámetros, en el bloque ONFAIL es suficiente con especificar el identificador único y el grado de satisfacción. Por último, en el bloque UNDO es necesario especificar el identificador único, el grado de satisfacción y el nombre del requerimiento que será mostrado al usuario. En las ilustraciones 4, 5 y 6 podemos ver ejemplos de los tres usos de esta cabecera. Tipos de instrucciones Las instrucciones son órdenes que se especifican en el archivo de configuración. Existen once tipos de instrucciones diferentes. Una instrucción debe aparecer después de haber comenzado un SpecList. Cada uno de los tipos de instrucciones comienzan con una palabra reconocida por el programa. Dependiendo de la instrucción, puede tener unos parámetros u otros. 18 REGREAD Lee un registro y lo compara con el valor deseado. Se pueden leer registros de tipo stringz, dword, qword y binarios. Si el registro es binario, se especifica su codificación. Éstos son los formatos de la instrucción: •REGREAD::(STRINGZ/DWORD/QWORD)::RUTA DEL REGISTRO::VALOR •REGREAD::BINARY::CODIFICACIÓN::RUTA DEL REGISTRO::VALOR FREAD Lee un archivo del equipo local y lo compara con un valor. Si el contenido con el que se quiere comparar tiene más de una línea, éstas se especifican con {{jumpline}}. Este es el formato de la instrucción: •FREAD::RUTA DEL ARCHIVO LOCAL::VALOR REGSUBKEY Examina el contenido del registro en busca de una subclave dada. Permite crearla si ésta no existe. Este es el formato de la instrucción: •REGSUBKEY::RUTA DE SUBCLAVE EN REGISTRO::READ ONLY (TRUE/FALSE) El campo READ ONLY es false crea la subclave si no existe ya. MSCERTS Permite acceder a la base de certificados de Windows e instalar un certificado digital pertenecientes al estándar PKCS12, en formatos p12 y pfx, o comprobar si existen certificados digitales emitidos por una organización. Este es su formato: •MSCERTS::*O=ORGANIZACIÓN*::TIPO::BASE::READ ONLY (TRUE / FALSE) El campo TIPO puede ser (OTHERS / 3PARTYCA / CA / ROOTCA / MY / PEOPLE / PUBLISHERS) El campo BASE puede ser (USER / MACHINE) Si el campo READ ONLY es false, primero se busca un certificado con las características descritas y si no se encuentra ninguno se permite instalar un certificado, este puede ser emitido por cualquier organización. THREAD Crea un hilo de ejecución nuevo, si existe el programa ejecutable especificado en el equipo local. Este ejecutable puede tomar argumentos al iniciar. Su formato es este: •THREAD::RUTA EJECUTABLE::ARGUMENTOS INFO Muestra un mensaje al usuario en una ventana de diálogo. Su formato es este: •INFO::TÍTULO DE VENTANA::CONTENIDO DEL MENSAJE 19 REGWRITE Escribe un valor en el registro. Este es su formato: •REGWRITE::TIPO::APPEND (TRUE / FALSE)::RUTA DEL REGISTRO:: VALOR El campo TIPO puede ser (STRINGZ / DWORD / QWORD) COPY Descarga un archivo de la red al equipo local. Si existe un archivo con el mismo nombre, éste se sobrescribe. Su formato es el siguiente: •COPY::URL::RUTA LOCAL FWRITE Escribe un valor en un archivo. Si el valor tiene más de una línea, éste se especifica con {{jumpline}}. Su formato es este: •FWRITE::APPEND (TRUE / FALSE)::RUTA LOCAL::VALOR MKDIR Crea un directorio en el equipo local, si éste no existe. Su formato es: •MKDIR::RUTA LOCAL DELETE Elimina un archivo, directorio, registro, subclave de registro o desinstalar un certificado digital o un software del equipo local. Dependiendo del tipo de elemento que se quiere borrar se especifica unos parámetros u otros. Formato para eliminar un archivo, directorio, registro o subclave •DELETE::RUTA Formato para desinstalar un certificado digital: •DELETE::TIPO::BASE::(Número de serie del certificado) Los campos TIPO y BASE son los mismos que en la instrucción MSCERTS. Formato para eliminar un software: •DELETE::BASE DE DESINSTALACIÓN::REGISTRO DE IDENTIFICACIÓN::VALOR DE IDENTIFICACIÓN::REGISTRO DE DESINSTALACIÓN En la base de datos del registro de Windows existen subclaves destinadas a almacenar información sobre cómo desinstalar software, por ejemplo HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, esta subclave (junto a otras separadas por coma) forma el campo BASE DE DESINSTALACIÓN. Dentro de dichas subclaves existe una subclave por cada software instalado, para identificar el software podemos usar registros propios de dicho software que estén en esa subclave, por ejemplo 'DisplayName', este dato forma el campo REGISTRO DE IDENTIFICACIÓN. VALOR DE IDENTIFICACIÓN es el valor que toma REGISTRO DE IDENTIFICACIÓN para ese software concreto. En la misma subclave donde se encuentra el REGISTRO DE IDENTIFICACIÓN debe existir un registro que indica el comando a ejecutar 20 para desinstalar dicho software, por ejemplo 'UninstallString'. Este tipo de instrucciones están disponibles únicamente en el bloque UNDO. Exceptuando el formato para desinstalar software, el resto se generan automáticamente para el archivo de log. Windows dispone de un directorio donde programas pueden almacenar archivos de forma temporal. Los archivos de este directorio es eliminado periódicamente por el sistema operativo. El directorio es accesible mediante la variable de entorno %TEMP%. Al iniciar el programa se crea un subdirectorio, 'ConfiguradorFirmaULPGC', dentro del directorio temporal. En las instrucciones donde en alguno de los campos se deba especificar una ruta para un archivo en el equipo local, por ejemplo COPY, por defecto el archivo se guarda en el directorio 'ConfiguradorFirmaULPGC', a no ser que se especifique otra ruta, puede ser relativa (será relativa al directorio donde el usuario ha guardado el propio configurador de firma electrónica) o absoluta (haciendo uso de variables de entorno como %USERPROFILE%). En todas las instrucciones, todas las apariciones de la cadena '%CONFIG_TEMP%' será sustituida por la ruta absoluta del directorio temporal creado por el programa. Interpretar los archivos de configuración Teniendo un archivo de configuración independiente del programa se necesita de un mecanismo que permita trabajar con estos datos, con esta finalidad se crean las clases Interpreter y FileInterpreter. FileInterpreter es una clase heredera de Interpreter. Lee archivos de configuración y genera una instancia de la clase DataSet, donde hay SpecList correspondientes a los distintos bloques. Se ha usado el mecanismo de inversión de dependencias, de esta forma si en el futuro aparece otra forma de almacenar e interpretar la configuración, como en una base de datos, los cambios son más fáciles de introducir. La clase FileInterpreter está implementada como una clase Singleton ya que no se necesita tener más de un intérprete en una instancia del programa. Esta clase devuelve una instancia de la clase DataSet, vista antes, que contiene los datos en memoria principal equivalentes a los almacenados en el archivo correspondiente. Al iniciar el programa se interpreta tanto el archivo de configuración principal como el archivo de log personal (en caso de que exista información logueada con anterioridad), como tienen el mismo formato se puede usar el mismo intérprete. Para interpretar cada Spec, FileInterpreter se basa en la clase SpecInterpreter, esta clase permite traducir instrucciones del archivo de configuración a objetos Spec de su tipo correspondiente. Como se dijo en el apartado anterior, dependiendo del bloque (NEEDS, CONFIG, ONFAIL o UNDO), se permiten ciertos tipos de Spec u otros. Esta prohibición no viene dada por el modelo de negocio, es decir, el modelo de negocio no impide que una IdentificationSpecList sea capaz de almacenar un ThreadSpec, sino es el intérprete quien no lo permite. Si en un bloque aparece una instrucción no permitida, esta es ignorada. En la siguiente tabla vemos los tipos de instrucciones permitidas en los diferentes bloques: NEEDS CONFIG ONFAIL UNDO INSTALLED REGREAD Sí Sí Sí Sí FREAD Sí Sí Sí Sí REGSUBKEY Sólo lectura Sólo lectura Sí Sí MSCERTS Sí Sí Sí THREAD Sí Sí Sí INFO Sí Sí Sí REGWRITE Sí Sí 21 COPY Sí Sí FWRITE Sí Sí MKDIR Sí Sí DELETE Sí Identificación del sistema Al iniciarse el programa, se crea en el directorio temporal de Windows un subdirectorio de nombre 'ConfiguradorFirmaULPGC'. Como el archivo de configuración principal está almacenado en un servidor de la ULPGC, para poder interpretar su contenido primero se descarga a este directorio temporal. A no ser que en el archivo de configuración se especifique un directorio concreto, los archivos copiados al equipo local mediante la instrucción COPY se almacenan en este directorio. Los archivos copiados al directorio temporal no se incluyen en el log para ser eliminados, en cambio los que se guarden en un directorio diferente a éste, sí. Una vez interpretado el archivo de configuración, tenemos los sistemas soportados y los navegadores web a los que dan soporte, que pueden ser Internet Explorer, Google Chrome o Firefox. De la lista de NEEDS interpretada, hay que averiguar qué requerimientos son los necesarios para el equipo que ejecuta el programa. Para lograr este objetivo se ha ideado la clase SystemIdentifier. Esta clase determinará los nombres de los requerimientos aplicables para el equipo y los navegadores para los cuales están destinados a configurar estos requerimientos. Mediante la interfaz de usuario, que veremos más adelante, se permite al usuario elegir los navegadores web que desea configurar. De esta forma se instalarán los requerimientos que elija el usuario. Esta elección de navegadores realizada por el usuario se almacenan en una instancia de la clase Browsers, esta clase tiene como atributos tres variables booleanas, cada una corresponde a cada uno de los navegadores web soportados, que indican si el usuario quiere o no configurar el navegador web asociado a esta. 22 Ilustración 9: Diagrama de clases del intérprete Este es el diseño de la interfaz actual del prototipo: 29 Ilustración 14: Diseño inicial de la interfaz de usuario Ilustración 15: Diseño de la interfaz actual, inicio del programa En primer lugar el usuario elige los navegadores que desea configurar, luego se muestra el siguiente panel: En el segundo diseño podemos ver que existe un panel central donde se muestra información al usuario y a la derecha está el menú principal de la aplicación. Dependiendo de la opción elegida del panel derecho, el contenido del panel central varía. Como se ve en la imagen, en el panel inferior se muestran las acciones realizadas en el momento así como una barra de progreso que indica la cantidad realizada del proceso. En el segundo diseño existe un panel central que no existe en el primero. De acuerdo al primer diseño esta información se habría mostrado en una ventana separada. De esta forma se reduce considerablemente el número de ventanas generadas. Implementación Para implementar la acción de los elementos de la interfaz de usuario se ha hecho uso del patrón Command. Con este patrón se ha creado una clase que simboliza una acción, a partir de esta 'acción' se definen 'acciones concretas'. El comando a su vez se comunica con un objeto de clase Agent para realizar su tarea, es decir, se han abstraído las operaciones de instalación y desinstalación a esta clase. De esta forma se ha reducido el acoplamiento de las clases Command y la ejecución de SpecSets, es el agente quien ordena su ejecución. El trabajo realizado en la ejecución programada para cada acción (cuando se pulsa un botón) tiene lugar en un hilo de ejecución separado del programa principal. De esta forma la interfaz no queda bloqueada, el usuario puede moverla por la pantalla, minimizarla, etc. El progreso de la ejecución se muestra en el panel 30 Ilustración 16: Diseño actual de la interfaz, menú de instalación personalizada inferior. Para ejecutar acciones en otros hilos se hace uso de la clase de .NET BackgroundWorker, esta clase permite, además de ejecutar procesos en segundo plano, generar eventos que refresquen la información en pantalla (usado para actualizar la barra de progreso) y realizar acciones cuando el hilo en segundo plano ha terminado. Las acciones programadas para realizar usando la clase BackgroundWorker, incluyen análisis del equipo para comprobar que se cumplen los requerimientos, instalar requerimientos necesarios y la desinstalación de requerimientos, tanto de forma automática (instala todos los requerimientos necesarios) como de forma personalizada (el usuario instala individualmente los componentes que desea). Pruebas y validación de uso El prototipo ha sido probado en diferentes sistemas operativos, concretamente en Windows 8.1 Professional de 32 bits, Windows 7 Professional de 32 bits y en Windows 7 Professional de 64 bits. Para validar el diseño de la interfaz de usuario, éste se ha puesto a prueba mediante el uso del prototipo de dos situaciones diferentes: •En reuniones con los tutores, en los que se plantea un escenario que pudiese ser habitual entre los usuarios finales •Uso en solitario de usuarios finales, donde el programa será usado sin ayuda. El resultado de esta forma de validación es la más útil y productiva. El usuario final es quien mejor sabe cómo debe ser el diseño para que él mismo pueda usarlo de forma más cómoda. El feedback recibido por usuarios finales ha generado la inserción de algunos requisitos nuevos pero factibles, de forma que se han podido cumplir en tiempo y forma. Diagrama de secuencias En este apartado se va a ver un diagrama de secuencias para describir las acciones que realiza el programa al realizar una instalación automática. De esta forma veremos de forma gráfica la interacción de los módulos descritos en el apartado de análisis y diseño. En primer lugar se realizan algunas operaciones antes de mostrar la interfaz de usuario: 31 Ilustración 17: Diagrama de secuencias, carga inicial Después de cargar en memoria principal estos datos iniciales, se muestra la interfaz. En el anexo de este documento están disponibles más diagramas de secuencia. 32 Ilustración 18: Diagrama de secuencias, instalación automática Trabajos futuros En el desarrollo de este proyecto se ha desarrollado un sistema que puede realizar la configuración de un equipo valiéndose de datos en su archivo de configuración. Durante todo el trayecto se ha hecho énfasis en idearlo de forma que pueda seguir siendo útil en el futuro. Gracias a que el sistema de detección de requerimientos (en este caso configuración de la firma electrónica de la ULPGC) se ha independizado del programa, se ha hecho posible que si en un futuro estos requerimientos cambian, para reflejar estos cambios en el programa será suficiente con editar el archivo de configuración. Siguiendo este planteamiento, editando el archivo de configuración el programa será capaz de configurar un equipo con los requerimientos que sean necesarios y no solamente la configuración para la firma electrónica, siempre y cuando estos requerimientos se puedan instalar de forma correcta con las instrucciones vistas en el apartado de 'Análisis y diseño'. Teniendo en cuenta la duración que abarca el TFG, que son trescientas horas, se ha procurado implementar la mayor cantidad de requisitos posibles atendiendo a su prioridad. Por este motivo hay requisitos que se pueden seguir desarrollando, incluso se pueden plantear nuevas funcionalidades para incluir en el programa. •El proyecto se ha desarrollado para sistemas Windows, pero los requerimientos identificados para que la firma electrónica de la ULPGC funcione correctamente son para sistemas Windows 7 y Windows 8.1. Se puede ampliar el número de sistemas soportados dentro de la familia Windows. •El modo de proceder del programa puede transportarse a otros sistemas operativos y desarrollar configuradores para éstos. Sabiendo los requerimientos necesarios para que funcione la firma electrónica en sistemas operativos de Apple y Linux, se pueden desarrollar configuradores para ellos. •Ampliar el número de navegadores web de la familia Internet Explorer que se pueden configurar, en el archivo de configuración se han definido los requerimientos para Internet Explorer 11, pero existen otras versiones que se siguen usando actualmente. Se pueden detectar sus requerimientos e incluirlos en el archivo de configuración. Conclusiones Se ha desarrollado un proyecto con muchas posibilidades de poder seguir creciendo en el futuro. Se han puesto en práctica diferentes áreas de la informática estudiadas a lo largo de la carrera, en especial la ingeniería de software. Anteriormente había realizado algunos pequeños proyectos usando Windows Forms, que es otra tecnología para desarrollar software escrito con C# en .NET, pero no con Windows Presentation Foundation. Al igual que WPF, existen otros aspectos que quería investigar pero no había tenido la ocasión de hacerlo. Estos son la programación concurrente, implementación de servicios criptográficos en C#. Por estos motivos el proyecto no solo ha posibilitado poner en práctica conocimiento ya adquirido sino también adquirir nuevas competencias. Considero que se ha logrado cumplir con el objetivo con un buen grado de satisfacción ya que la configuración se realiza de forma automática en más de un sistema operativo y en más de un navegador web. 33 Fuentes de información Para la realización de este proyecto se han consultado fuentes tanto virtuales como en soporte físico, se han consultado fuentes lo más actuales posibles. Las fuentes de soporte físico han sido los siguientes libros: •Beginning Visual C# 2012 Programming, escrito por Karli Watson, Jacob Vibe Hammer, Jon D. Reid, Morgan Skinner, Daniel Kemper y Christian Nigel. Publicado por Wrox, año 2013. ◦Se consultaron los capítulos 19 (información general sobre desarrollo de servicios web con ASP.NET) y 23 (Información básica sobre LINQ). •Visual Studio 2012 And .NET 4.5 Expert Development Cookbook, escrito por Abhishek Sur. Publicado por PACKT Publishing, año 2013. ◦Se consultó el capítulo 3 (programación asíncrona en .NET). •Codes And Cryptography, escrito por Dominic Welsh. Publicado por Oxford University Press, año 1988. ◦Se consultó el capítulo 11 (criptosistemas de clave pública). Las fuentes de información en la red han sido las siguientes: •Información general sobre Windows Presentation Foundation (WPF) ◦http://msdn.microsoft.com/es-es/library/ms754130%28v=vs.110%29.aspx •Información general sobre las distintas ramas del registro de Windows ◦http://msdn.microsoft.com/en-us/library/windows/desktop/ms724836%28v=vs.85%29.aspx •Cómo instalar y desinstalar librerías de enlace dinámico (DLL) en Windows ◦http://www.sophos.com/es-es/support/knowledgebase/14343.aspx ◦http://stackoverflow.com/questions/3474988/what-does-regsvr32-filename-ax-actually-do •Información sobre implementación de cifrado simétrico en C# ◦http://www.technical-recipes.com/2013/using-rsa-to-encrypt-large-data-files-in-c/ •Información sobre implementación del algoritmo AES para cifrado simétrico en C# ◦http://www.gutgames.com/post/AES-Encryption-in-C.aspx •Generación avanzada de números aleatorios para servicios criptográficos ◦http://www.dotnetperls.com/rngcryptoserviceprovider •Información general sobre cómo usar Windows Management Instrumentation (WMI) ◦http://msdn.microsoft.com/en-us/library/aa389763%28v=vs.85%29.aspx ◦http://msdn.microsoft.com/es-es/library/system.management.managementobjectsearcher %28v=vs.110%29.aspx ◦http://msdn.microsoft.com/en-us/library/aa394346%28v=vs.85%29.aspx ◦http://www.dreamincode.net/forums/topic/288487-wmi-win32-useraccount-exception/ •Uso de WMI para obtener el número ID del usuario con sesión iniciada ◦http://social.msdn.microsoft.com/Forums/vstudio/en-US/dc973f8c-4fd9-41f3-82a93646721e9dbd/how-to-retrieve-a-remote-users-sid-using-wmi?forum=csharpgeneral 34 •Información sobre la clase Win32_UserAccount para obtener datos del usuario mediante WMI ◦http://msdn.microsoft.com/en-us/library/aa394507%28v=vs.85%29.aspx •Información sobre obtención de valores del registro en C# ◦http://msdn.microsoft.com/en-us/library/microsoft.win32.registrykey%28v=vs.110%29.aspx •Información sobre registros de desinstalación de software ◦http://msdn.microsoft.com/en-us/library/aa372105%28v=vs.85%29.aspx ◦http://msdn.microsoft.com/en-us/library/ms954376.aspx •Cómo saber si una instancia de una clase de C# tiene una propiedad o un método ◦http://stackoverflow.com/questions/5114469/how-to-check-whether-an-object-has-certainmethod-property •Cómo desinstalar software instalado en Windows usando C# ◦http://stackoverflow.com/questions/9126104/how-to-uninstall-software-using-c-sharp-bycalling-software-uninstallstring-list •Consulta sobre existencia de una subclave en el registro ◦http://stackoverflow.com/questions/13728491/opensubkey-returns-null-for-a-registry-key-that-ican-see-in-regedit-exe •Cómo saber desde código C# si el sistema operativo usado es de 64 bits o de 32 bits. ◦http://stackoverflow.com/questions/14423057/how-to-check-if-os-is-32-bit-os-or-64-bit •Cómo acceder a controles de usuario en una interfaz matricial en WPF ◦http://stackoverflow.com/questions/1511722/how-to-programmatically-access-control-in-wpfgrid-by-row-and-column-index •Información general sobre implementación de barras de progreso en WPF ◦http://www.wpf-tutorial.com/misc-controls/the-progressbar-control/ •Información general sobre programación concurrente aplicada a actualización de interfaz de usuario ◦http://stackoverflow.com/questions/4253088/c-updating-gui-wpf-using-a-different-thread •Tabla de caracteres en codificación Unicode UTF-8 ◦http://utf8-chartable.de/unicode-utf8-table.pl?utf8=0x&unicodeinhtml=hex •Traducción de ristras binarias a texto, eliminando caracteres de control ◦http://stackoverflow.com/questions/4500870/how-to-remove-control-chars-from-utf8-string •Información sobre la inclusión de sitios web en modo compatible de Internet Explorer 11 en su registro de Windows ◦http://jeffgraves.me/2014/02/19/modifying-ie-compatibility-view-settings-with-powershell/ •Iconos de uso libre usados en el proyecto ◦https://www.iconfinder.com/icons/27831/add_blue_minus_new_plus_icon#size=128 •Imágenes de ULPGC usadas en el proyecto ◦http://www.ulpgc.es/index.php?pagina=identidadgrafica&ver=inicio& •Comparación de arrays usando LINQ 35 ◦http://stackoverflow.com/questions/43289/comparing-two-byte-arrays-in-net •LOPD de la Agencia Española de Protección de Datos ◦http://www.agpd.es/portalwebAGPD/canaldocumentacion/legislacion/estatal/index-idesidphp.php •Instalación de certificados digitales del formato X509 en C# ◦http://stackoverflow.com/questions/16276213/issue-installing-x509certificate2-from-c-sharpcode •Información sobre el directorio personal AppData en Windows ◦http://windows.microsoft.com/en-us/windows-8/what-appdata-folder •Manual de Adobe del administrador, apartado 1.6 ◦http://eddiejackson.net/web_documents/Acrobat_Enterprise_Administration.pdf •Información sobre el patrón de pensamiento Lean en el marco de trabajo de Scrum ◦http://msdn.microsoft.com/es-es/library/jj161049.aspx •Información sobre Scrum y Lean Software Development ◦http://es.wikipedia.org/wiki/Scrum ◦http://es.wikipedia.org/wiki/Lean_software_development ◦http://msdn.microsoft.com/es-es/library/hh533841.aspx •Diferencias entre C# y Visual Basic aplicados en .NET ◦http://support.microsoft.com/?kbid=308470 •Información sobre hallar versión de Internet Explorer via registro de Windows ◦http://social.msdn.microsoft.com/Forums/windowsazure/en-US/b5f47548-69d5-499c-be60de6ec78ce182/how-to-get-the-version-of-ie-programmatically-and-reliably •Ejemplo de programación concurrente en C# ◦http://www.albahari.com/threading/part3.aspx •Información sobre diferentes estrategias para obtener un UID de usuario ◦http://en.wikipedia.org/wiki/Universally_unique_identifier ◦http://tools.ietf.org/html/rfc4122 •Manipulación de certificados digitales en C# ◦http://www.programandoamedianoche.com/2009/08/utilizar-certificados-digitales-desde-net/ ◦http://vyktor5k.blogspot.com.es/2010/06/howto-leer-certificados-digitales-en-c.html ◦http://programacion.com/articulo/trabajar_con_certificados_digitales_desde_net_i_838 ◦http://www.programacion.com/articulo/trabajar_con_certificados_digitales_en_net_ii_847 •Uso de comandos de consola desde C# ◦http://stackoverflow.com/questions/437419/execute-multiple-command-lines-with-the-sameprocess-using-net ◦http://stackoverflow.com/questions/1469764/run-command-prompt-commands •Información y ejemplos de uso de variables de entorno en Windows ◦http://ss64.com/nt/syntax-variables.html 36 Anexo Diagramas de secuencias En este apartado vamos a ver las distintas situaciones que se generan dependiendo de las acciones realizadas por el usuario en el programa. Primero vemos el diagrama correspondiente al arranque del prototipo, se interpretan los archivos de configuración y se comprueba si el equipo es sistema soportado. Este diagrama representa la interacción de los módulos al realizar una instalación automática 37 Ilustración 19: Diagrama de secuencias, carga inicial Ilustración 20: Diagrama de secuencias, instalación automática Este diagrama representa la interacción de los módulos al realizar una instalación personalizada: Este diagrama representa la interacción de los módulos al realizar una desinstalación automática: Este diagrama representa la interacción de los módulos al realizar una desinstalación personalizada: 38 Este es el aspecto de la pantalla principal: En el menú de desinstalación personalizada vemos que nos da la posibilidad de eliminar componentes instalados por el programa. 45 Ilustración 27: Menú de análisis del equipo, análisis positivo Desinstalación de componentes También se pueden eliminar todos los componentes instalados uno tras otro automáticamente, desde la opción 'Desinstalación automática'. Nos confirmará la decisión: 46 Ilustración 28: Menú de desinstalación personalizada Ilustración 29: Confirmación de desinstalación automática Si se acepta, el programa procede a desinstalar los componentes instalados, tras haber terminado, mostrará la siguiente pantalla: 47 Ilustración 30: Menú de desinstalación automática Ayuda e información de contacto Si el usuario tiene cualquier duda, puede ponerse en contacto con los técnicos del departamento de informática de la ULPGC, puede consultar las formas de contactar en la opción 'Contacto' del menú de opciones Por último, si no se desea realizar ninguna otra acción, se puede cerrar el programa mediante la opción 'Salir del Configurador' o pulsando sobre el botón 'X'. 48 Ilustración 31: Menú de Contacto