HERRAMIENTA DE MONITORIZACIÓN DE SISTEMAS

Transcripción

1 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN INFORMÁTICA PROYECTO FIN DE CARRERA HERRAMIENTA DE MONITORIZACIÓN DE SISTEMAS AUTOR: Iñaki Sota Madorrán MADRID, Febrero de 2008

2 Autorizada la entrega del proyecto del alumno: Iñaki Sota Madorrán. EL DIRECTOR DEL PROYECTO Pablo Igualada Moreno Fdo.: Fecha: / / Vº Bº del Coordinador de Proyectos David Contreras Bárcena Fdo.: Fecha: / /

3 Agradecimientos A mi familia, por la confianza depositada a lo largo de toda la carrera. A la universidad y a sus profesores, por la ilusión y ganas que en general demuestran en la formación profesional y humana de los alumnos. A los encargados de supervisar el proyecto, coordinadores y director, por su apoyo y ánimo para afrontar dicha tarea. A los encargados de la empresa colaboradora y compañeros de trabajo, por hacer que el tiempo dedicado a este proyecto resultara también en un tiempo bien invertido y ameno a la par. A los amigos y colegas. I

4 Resumen El proyecto consiste en el diseño, desarrollo e implantación de un sistema que sirva de apoyo a las empresas de servicios informáticos en la tarea de mantenimiento de los sistemas informáticos de sus clientes. El sistema automatiza la auditoría y supervisión del estado y funcionamiento de los sistemas de información, consiguiendo que se reduzca considerablemente el tiempo que se debe dedicar a dicha tarea, y por tanto, aumentando la productividad. Tanto los sistemas informáticos monitorizados como los de la compañía de servicios, están compuestos por PC s y Servidores con plataformas de Microsoft. Se trata de un sistema cliente-servidor donde un servidor instalado en la empresa de servicios informáticos atiende a múltiples clientes instalados en las máquinas de los sistemas informáticos de los clientes, denominados agentes. El sistema proporciona la funcionalidad para: Instalación: Instalación de un agente en una máquina cliente y su registro en el sistema. Obtener acceso, por parte de los usuarios de las máquinas cliente, al programa VCN One Click de control remoto y a información descriptiva del agente. Auditorias: La ejecución de auditorías, por parte de los agentes, en las máquinas de los sistemas informáticos de los clientes de forma transparente a los usuarios y su posterior envío al servidor para su almacenamiento. Alertas: La generación, a partir de las auditorías y por parte del servidor, de alertas relacionadas con estados definidos en las máquinas cliente. Registro de dichas alertas en el sistema externo Microsoft CRM 3.0. Gestión de Alertas: El filtrado, por parte de los técnicos, de las alertas que se generan de forma que se obtenga una herramienta útil. Tareas: La programación, por parte de los técnicos, de tareas definidas y diseñadas para su realización por los agentes en las máquinas cliente. Tareas Programadas: La generación, por parte de los administradores, de tareas programadas repetitivas que se registran en el Programador de Tareas de Windows II

5 del servidor. Interpretación de las mismas para su registro en el sistema y su posterior realización por los agentes en las máquinas cliente. Interfaz para los técnicos: El visualizado, por parte de los técnicos, de los agentes que hay registrados en el sistema, de las tareas que ejecutan dichos agentes en las máquinas en las que están instalados, de las auditorías de dichas máquinas obtenidas y registradas en el sistema y del log registrado en el sistema por los agentes. Upgrading: Actualización automática del programa agente en todos los agentes operativos. Gestión de Usuarios: La gestión de los usuarios que tienen acceso al sistema. Para proporcionar la funcionalidad expuesta anteriormente se han construido varias aplicaciones en las que se ha utilizado tecnologías innovadoras en desarrollo de software y, para su interacción, en comunicación entre aplicaciones. En general, y debido a la mayor facilidad de integración en los sistemas a implantar, las aplicaciones se han desarrollado con Herramientas de Microsoft. Así pues, se ha trabajado con el Framework de.net bajo la herramienta Visual Studio 2005 para construir las siguientes aplicaciones: La aplicación Agente, que está compuesta por un Servicio de Windows que proporciona toda la funcionalidad del agente y una aplicación que carga un icono en la barra de tareas y sirve de información a los usuarios de las máquinas cliente. Se han construido con aplicaciones Windows Service y Windows Application respectivamente. Una librería, que contiene los componentes del dominio, nivel de negocio y de acceso a datos. La librería produce un fichero.dll que es utilizado por el resto de aplicaciones. Se ha construido con una aplicación Windows Control Library. Una aplicación de escritorio, con un interfaz amigable, para los técnicos de la empresa de servicios informáticos. Se ha construido mediante una aplicación Windows Application. Una aplicación Web que contiene los servicios Web a través de los que se comunican los agentes con el sistema y que sirve también de apoyo a la aplicación de escritorio. Se ha construido mediante una aplicación ASP.NET Web Service Application. III

6 Una aplicación que se encarga de interpretar las tareas repetitivas para asignárselas a los agentes. Se trata de una aplicación Console Application. Aplicaciones de instalación, para la instalación y actualización de los agentes e instalación de las demás aplicaciones. Se han construido mediante un Setup Project. El sistema, además, se integra con aplicaciones externas, incluido el propio sistema operativo y sus herramientas. Entre ellas, cabe destacar la aplicación Microsoft CRM 3.0, la herramienta Task Scheduler de Windows y una aplicación de software libre llamada WinAudit. Por último, se ha utilizado y profundizado en las técnicas y metodologías de ingeniería del software, especialmente en la orientación a objetos así como en otros conocimientos que se han visto a lo largo de la carrera como Estructuras de datos, Transmisión y Tecnologías de Bases de Datos, Sistemas Operativos, Redes, Métodos algorítmicos, Seguridad Informática y Gestión de Proyectos Informáticos. IV

7 Abstract The Project consists of the design, development and deployment of a software system to support IT Companies to undertake the task of maintaining their client s information systems. The system automate the audit and oversee of the state and operation of the information systems, making it possible to minimize the time it takes, and also to increase the productivity. The information system to be monitored and the IT Company s one are composed of PCs and Servers that carry Microsoft Platforms. The system is a client-server application where a server which is installed in the IT Company attends to multiple clients, called agents, which are installed in the customer s computers. The system provides the following features: Installation: Installation of the agent in a client machine and the following register in the system. The client s machine s users get access to the program VCN One CLick of remote control and to the descriptive information about the agent. Audits: The agents execute the audits in the client s information system computers in a way the users do not take care of it. The agents will register the audits in the system. Alerts: The server, using the audits and due to determined states in the client computers, generates alerts. It register the alerts in the external system Microsoft CRM 3.0 Alert generation management: The technicians configure a filter to control the alerts generated in a way it becomes a useful tool. Tasks: The technicians set previously defined and designed tasks to be executed by the agents in the client s computers. Scheduled Tasks: The IT Company administrators generate scheduled tasks that are registered in the Server Windows Task Scheduler. The system interprets and registers them to be executed by the agents in the client s computers. V

8 User Interface for the technicians: The display of the registered agents in the system, of the tasks that execute the agents, of the audits and of the log registered in the system by the agents. Upgrading: Automatic upgrade of the agent application in all operative agents. User management: The management of the system access. To provide all the features exposed there have been built several applications in which have been used innovation software development technologies and software application connections. Generally, due to the easier installation in the information systems, the applications have been developed using Microsoft tools, the.net Framework and Visual Studio The Agent application is composed by a Windows Service that provides all the agent functionality and a Windows application that charges an Icon on the taskbar. A Windows Control Library, which contains the domain, service and data access and produce a.dll file to be used by the others applications. A desktop Application (Windows Application), with a kind interface, for the IT Company s technicians. A Web Application (ASP.NET Web Service Application) containing the Web Services used to connect the agents to the system and also to support the desktop application. A Console Application used to interpret the scheduled tasks and assign them to the agents. Setup Applications, for the installation and upgrading of the agents and the installation of all the applications. The system, furthermore, is connected to several applications including the Operating System. The most remarkable ones are Microsoft CRM 3.0, the Windows Task Scheduler tool and an open source application called WinAudit. To end up, there have been used and deepened the knowledge of techniques and methodologies of software engineering, especially the Object Oriented, as well as other subjects sawn during the degree as Data Structures, Data Transfer and Database Technologies, Operating Systems, Networks, Algorithm methods, Technology Security and Software Development Projects Management. VI

9 Índice 1. Introducción Motivación y Contexto del proyecto Objetivos y Descripción del Proyecto 1 2. Herramientas y Tecnología Introducción Introducción a la Tecnología.NET Introducción a los Servicios Windows Introducción a Internet Information Services (IIS) Introducción a los Servios Web (Web Services) Introducción a las herramientas y aplicaciones a integrar con el sistema Introducción a Microsoft SQL Server Metodología de Trabajo Introducción al Análisis de requerimientos Introducción al Diseño externo del sistema Introducción al Diseño interno del sistema Introducción a la Implementación, pruebas e Implantación Análisis de Requerimientos Modelo de Dominio Casos de uso Diseño Externo del Sistema Arquitectura del Sistema Diagrama de paquetes Diseño Interno del Sistema Diseño de la Interfaz de Usuario y Diagramas de Interacción Subsistema EvoAgentManager e Interacción con el Servidor Subsistema EvoAgentService e Interacción con el Servidor Sistema Externo Microsoft Dynamics CRM Modelo de datos 151 VII

10 6.3 Diagrama de Clases Librería EvoAgentLibrary SubSistema EvoAgentServer SubSistema EvoAgentManager SubSistema EvoAgentService Implementación del sistema, Pruebas e Instalación Implementación de la base de datos Construcción del sistema Pruebas Implantación en el entorno de producción Manual de Usuario y de Explotación Planificación y Presupuesto Planificación Presupuesto Conclusiones y Evolución del Sistema Conclusiones Evolución del Sistema Bibliografía 214 Anexo 1. Manual de Usuario 215 Anexo 2. Manual de Explotación 263 A2.1. Implementación y Configuración del sistema 263 A2.2. Mantenimiento y Evolución del sistema 285 Anexo 3. Tecnologías 311 Anexo 4. Metodologías y Modelos de Diseño 339 VIII

11 1. Introducción 1.1 Motivación y Contexto del proyecto La principal motivación a la hora de afrontar el presente proyecto es la creación de una herramienta que sirva de apoyo a las empresas de servicios informáticos en la tarea de supervisión del estado y funcionamiento de los sistemas de información. Se pretende automatizar dicha tarea de forma que se reduzca considerablemente el tiempo dedicado a la misma, mejorando la productividad. Para comprender mejor el proyecto se hace necesario conocer la tarea a automatizar y el contexto en que se produce. Muchas pequeñas y medianas empresas de diferentes sectores delegan la gestión de sus sistemas de información a compañias de servicios informáticos. Éstas, además de proveerlas con las últimas y más apropiadas tecnologías para sus procesos de negocio, deben proporcionar los servicios necesarios para asegurar el correcto funcionamiento de sus sistemas. En este sentido se realiza la tarea de supervisión remota de los sistemas de información de los clientes. Dicha tarea consiste en comprobar varios ítems en los ordenadores de los clientes, tales como el espacio en disco, la fragmentación de los archivos, el log de errores de Windows, el tamaño de la cuota de los usuarios del dominio, los servicios automáticos de Windows, el software instalado en los ordenadores o la correcta ejecución de tareas programadas y de los backup de datos locales. Esta tarea se debe realizar para cada cliente y de forma diaria, con el consiguiente tiempo a dedicar. El presente proyecto pretende automatizar la tarea de forma que el tiempo dedicado a la misma sea mucho menor. Por otro lado, se va a trabajar en este proyecto con las últimas tecnologías. Se trata de un proyecto muy completo que integra aspectos de redes, bases de datos, y desarrollo de software. Todo ello hace que sea un proyecto muy atractivo. 1.2 Objetivos y Descripción del Proyecto El principal objetivo del presente proyecto es diseñar y construir una herramienta que permita la monitorización automática de los sistemas informáticos facilitando la tarea de los administradores de sistemas. 1

12 Los sistemas informáticos a monitorizar así como el sistema informático de la empresa colaboradora están basados en tecnología de Microsoft tanto en los PC s de los empleados como en los servidores. Para el desarrollo del sistema se utilizarán, por tanto, herramientas de Microsoft disponibles a tal efecto de forma que sea más sencilla la completa integración. A partir de ahora se tendrá presente que todos los componentes del sistema a construir interactuarán con sistemas operativos Windows. A continuación se describe en detalle el sistema a desarrollar y todos sus componentes: Aplicación agente para las máquinas a monitorizar: Para la monitorización diaria de las máquinas se pretende construir un programa que actúe a modo de agente y que se integre con un servicio ubicado en el servidor de la empresa. El agente deberá ser transparente a los usuarios de las máquinas a monitorizar mostrando la existencia de la aplicación mediante un icono en la barra de herramientas. Por tanto, se deberá crear un servicio de Windows y una aplicación para mostrar el icono. La monitorización, llevada a cabo por el servicio de Windows, consistirá en la obtención de información de la máquina en que esté instalado el agente. Para la obtención de dicha información se utilizará, además de las posibilidades que ofrece el entorno de desarrollo para integrarse con el sistema operativo, una aplicacion de software libre llamada WinAudit. El agente podrá, además, realizar diferentes tareas según esté instalado en un servidor o en un pc de usuario. Estará diseñado para realizar tareas como: Apagar la máquina. Ejecutar un programa de limpieza de la máquina Programa Ccleaner. Iniciar un servicio de Windows. Obtener una auditoría (monitorización). Defragmentar los discos duros. Ejecutar Scripts. Comprobar cuotas de usuario de Dominio (Servidor de dominio). Por otro lado, desde el icono que muestra la información de la aplicación al usuario se podrá acceder al programa VNC Single Click de control remoto de ordenadores. Los agentes podrán actualizarse consultando su versión contra el servidor y descargando e instalando la nueva versión. 2

13 Aplicación de gestión para los técnicos de Evotec y Servidor de la aplicación: La información obtenida en una auditoría deberá ser enviada a un servicio ubicado en el servidor, donde pasará por un filtro para, finalmente, generar alertas. Las alertas deberán ser presentadas a los técnicos de la empresa mediante la integración con la herramienta CRM de gestión de clientes utilizada, Microsoft CRM 3.0. Además de la generación de alertas en la aplicación CRM, el sistema a construir deberá ser controlado desde los puestos de los técnicos de la empresa mediante una aplicación de escritorio que se integrará igualmente con otro servicio en el servidor. Desde dicha aplicación de escritorio se podrá: Gestionar los agentes y los clientes a los que pertenecen. Programar tareas para los agentes. Controlar la generación de alertas mediante los filtros. Ver los informes completos de las máquinas. Ver el log de las acciones realizadas por los agentes. El servidor del sistema deberá atender tanto a los agentes como a la aplicación de gestión de los técnicos mediante los servicios. Tendrá, por tanto, dos servicios web, uno para los agentes y otro para la administración. Se deberá alojar en el Servidor Internet Information Server que es el utilizado en la empresa. Para ello se creará un directorio virtual con todo el contenido necesario. Los datos del sistema se almacenarán en una base de datos que estará alojada en el sistema gestor SQL Server. El servidor del sistema interactuará con la misma para gestionar los datos obtenidos a partir de la interacción con los agentes. La aplicación de gestión tendrá acceso a la base de datos para los casos de uso que se propongan. Seguridad del sistema: Los técnicos deberán autenticarse para acceder a la aplicación de gestión que accede a su vez al servicio de administración y a la base de datos, dicha autenticación estará basada en la cuenta de usuario de Windows utilizada al iniciar la sesión. Los agentes poseerán un identificador recibido del servidor al instalarse y que enviarán a éste en sus comunicaciones. Todos los programas y entornos que se han comentado en la descripción del sistema y que se utilizarán en el proyecto se exponen en el apartado 2. Herramientas y Tecnología. 3

14 2. Herramientas y Tecnología 2.1 Introducción Para el desarrollo de este proyecto se van ha utilizar las últimas herramientas, estándares y protocolos disponibles en desarrollo de aplicaciones Web distribuídas proporcionadas por Microsoft y por la industria de desarrollo de software. Se ha elegido la tecnología de desarrollo de aplicaciones de Microsoft por ser la tecnología con la que, por parte de la empresa, se está más familiarizado, que ya utiliza esta tecnología en sus sistemas. Se distinguirá entre plataformas de desarrollo y producción existiendo diferentes versiones de las herramientas de software utilizadas en dichas plataformas. En desarrollo se trabajará con una máquina con sistema operativo Windows XP o Windows Vista, con versión de Internet Information Server 5.1 o 7.0 respectivamente y con la versión gratuita del gestor de base de datos SQL Server, Sql Server Express Edition que dispone de una capacidad de 2 GB. En Producción se utilizará un servidor con Windows 2003 Server, que lleva instalada la versión 6.0 del Internet Information Server y la versión completa del SQL Server. Para el diseño de la aplicación se utilizará Lenguaje Unificado de Modelado (UML) y para el desarrollo se utilizará el entorno proporcionado por Visual Studio 2005 con el lenguaje de programación C#. Por último se diseñará y desarrollará integración con varias aplicaciones, tanto herramientas del sistema operativo y de la empresa como puede ser la herramienta de tareas programadas de Windows, la aplicación de Microsoft CRM Dinamics 3.0 o la aplicación de control remoto de ordenadores VNC Viewer, así como aplicaciones de libre distribución disponibles en el mercado como WinAudit y CCleaner. Se realiza a continuación una introducción a todas estas herramientas. 2.2 Introducción a la Tecnología.NET.NET es un proyecto de Microsoft para crear una nueva plataforma de desarrollo de software con énfasis en transparencia de redes, con independencia de plataforma y que permita un rápido desarrollo de aplicaciones. Basado en esta plataforma, Microsoft intenta desarrollar una estrategia horizontal que integre todos sus productos, desde el Sistema Operativo hasta las herramientas de mercado. 4

15 .NET podría considerarse una respuesta de Microsoft al creciente mercado de los negocios en entornos Web, como competencia a la plataforma Java de Sun Microsistems. A largo plazo Micorsoft pretende reemplazar el API Win32 o Windows API con la plataforma.net. Esto es debido a que el API Win32 fue desarrollada sobre la marcha, careciendo de documentación detallada, uniformidad y cohesión entre sus distintos componentes, provocando múltiples problemas en el desarrollo de aplicaciones para el sistema operativo Windows. La plataforma.net pretende solventar la mayoría de estos problemas proveyendo un conjunto único y expandible con facilidad, de bloques interconectados, diseñados de forma uniforme y bien documentados, que permitan a los desarrolladores tener a mano todo lo que necesitan para producir aplicaciones sólidas. Con esta plataforma Microsoft incursiona de lleno en el campo de los Servicios Web y establece el XML como norma en el transporte de información en sus productos y lo promociona como tal en los sistemas desarrollados utilizando sus herramientas..net intenta ofrecer una manera rápida y económica pero a la vez segura y robusta de desarrollar aplicaciones - o como la misma plataforma las denomina, soluciones - permitiendo a su vez una integración más rápida y ágil entre empresas y un acceso más simple y universal a todo tipo de información desde cualquier tipo de dispositivo. Para ver más detalles de los recursos que comprende la tecnología.net y que se van a aplicar a este proyecto ver Anexo 3. Tecnologías. 2.3 Introducción a los Servicios Windows Los servicios de Microsoft Windows, antes conocidos como servicios NT, permiten crear aplicaciones ejecutables de larga duración, que se ejecutan en sus propias sesiones de Windows. Estos servicios pueden iniciarse automáticamente cuando se inicia el sistema, se pueden pausar y reiniciar, y no muestran ninguna interfaz de usuario. Estas características hacen que los servicios resulten perfectos para ejecutarse en un servidor o donde se necesite una funcionalidad de ejecución larga que no interfiera con los demás usuarios que trabajen en el mismo equipo. También puede ejecutar servicios en el contexto de seguridad de una cuenta de usuario específica, diferente de la del usuario que inició la sesión o de la cuenta predeterminada del equipo. El servicio se crea como proyecto de Microsoft Visual Studio, se define el código que controla qué comandos se pueden enviar al servicio y qué acciones se deben realizar al recibir esos comandos. Entre los comandos que se pueden enviar a un servicio se encuentran los comandos de inicio, pausa, reanudación y detención del servicio; asimismo, puede ejecutar comandos personalizados. Después de crear y generar la aplicación, puede instalarla ejecutando la utilidad de línea de comandos InstallUtil.exe y pasando la ruta de acceso al archivo ejecutable del servicio, o bien utilizando las funciones de implementación de Visual Studio. A continuación, puede 5

16 utilizar el Administrador de control de servicios para iniciar, detener, pausar, reanudar y configurar el servicio. Además, puede realizar muchas de estas mismas tareas en el nodo Servicios del Explorador de servidores o al usar la clase ServiceController. En el presente proyecto se pretende construir aplicaciones agente que sean precisamente Servicios de Windows ya que éstos cumplen con los requerimientos de ocultación a los usuarios y posesión de credenciales suficientes para la conexión con el servidor. Para ver más información acerca de los servicios de Windows consultar el Anexo 3. Tecnologías. 2.4 Introducción a Internet Information Services (IIS) Para la construcción del sistema se requiere de un servidor de Internet que de servicio a los subsistemas del presente proyecto, concretamente, a los agentes instalados en las máquinas cliente y a las aplicaciones de los técnicos instaladas en la oficina. El servidor abilitado a tal efecto en la empresa es el Internet Information Server, con lo cual será necesario adaptarse a sus posibilidades. Se deberá de configurar un sitio web que contenga los servicios web que den soporte a los subsistemas y, asimismo, establecer el sistema de autenticación para controlar el acceso a los mismos. Para ver las características que ofrece el servidor web consultar el Anexo 3. Tecnologías. 2.5 Introducción a los Servios Web (Web Services) Los Web services son componentes software que permiten a los usuarios usar aplicaciones de negocio que comparten datos con otros programas modulares, vía Internet. Son aplicaciones independientes de la plataforma que pueden ser fácilmente publicadas, localizadas e invocadas mediante protocolos Web estándar, como XML, SOAP, UDDI o WSDL. El objetivo final es la creación de un directorio online de Web services, que pueda ser localizado de un modo sencillo y que tenga una alta fiabilidad. El echo de la posibilidad de modularidad y de la interconexión de aplicaciones hace que sean los servicios web la solición a las comunicaciones entre el servidor y los subsistemas del presente proyecto. Para ver más información acerca de los servicios web, los protocolos que implementan y su desarrollo e implementación con.net consultar el Anexo 3.Tecnologías. 2.6 Introducción a las herramientas y aplicaciones a integrar con el sistema Microsoft Dynamics CRM 3.0 Profesional 6

17 Evotec Consulting, empresa colaborada en este proyecto, ha apostado fuerte por ésta herramienta. Es utilizada para gestionar las acciones llevadas a cabo con todos sus clientes y es el escenario escogido para la gestión de las alertas que genere el sistema ha desarrollar. Por ello, es necesario conocer la aplicación de Microsoft, su despliegue y funcionamiento y como conseguir la integración para el programador. Introducción a Microsoft Dynamics CRM 3.0 Profesional Microsoft DynamicsTM CRM 3.0 Professional, anteriormente conocido como Microsoft Business Solutions CRM, es una completa solución de gestión de relaciones con clientes que proporciona todas las herramientas y capacidades necesarias para crear y mantener una visión clara de los clientes fácilmente, desde el primer contacto hasta el servicio de postventa. Con módulos de marketing, ventas y servicio al cliente, Microsoft CRM 3.0 Professional ofrece una solución rápida, flexible y asequible que impulsa mejoras cuantificables y coherentes en todos los procesos empresariales, permite relaciones más estrechas con los clientes y ayuda a su empresa a conseguir nuevos niveles de rentabilidad. La experiencia del usuario de Microsoft CRM 3.0 Professional se ha diseñado para que sea una ampliación natural de Microsoft Office y Outlook, lo que proporciona un entorno de trabajo familiar e intuitivo que fomenta la receptividad del usuario y su productividad. Despliegue de la aplicación La aplicación está compuesta por una serie de Servicios Web que proporcionan por un lado la implementación de la interfaz en el browser cliente y por otro lado el soporte para la conexión mediante programas. Como tal, se debe ubicar en el servidor web de la compañía, y configurar para poder ser accedida. 7

18 Figura 2.1 CRM en el Servidor Web Asimismo posee una base de datos que debe ser implementada en Sql Server. En este caso la base de datos Evotec_MSCRM. Dicha base de datos puede ser utilizada para realizar consultas directamente sin necesidad de llamar al CRM. Las actualizaciones de datos de forma directa no son aconsejables ya que es el propio CRM el que se encarga de la coherencia de los datos almacenados y de esta forma se alteraría. Figura 2.2 Base de Datos de CRM en SQL SERVER La aplicación contiene un registro de los usuarios que pueden acceder y la autenticación de usuarios se basa en integración con la autenticación de Windows. Por tanto, con iniciar sesión la aplicación conoce si tienes permiso para entrar. Integración con CRM Existen varias formas de obtener y registrar información en el sistema CRM de Microsoft de forma externa. En el presente documento se expone la que se va a utilizar en el que es mediante la utilización del servicio Web CRMService y acceso SQL a la base de datos. Hay una documentación de ayuda instalable denominada CRM SDK y que también expone el espacio de nombres que se utiliza en la aplicación, como se ve en la figura 2.3. La documentación se puede descargar desde el link: 8

19 bd14b74308c5&displaylang=en.ç Figura 2.3 CRM SDK La aplicación trabaja con entidades y grupos de entidades. En el presente proyecto nos interesan las entidades usuarios de la aplicación, clientes y una entidad nueva que llamaremos alerta. El método para manejar entidades desde un código cliente pasa por utilizar un servicio Web del CRM pensado para ello, CRMService. Dicho servicio se debe referenciar desde el proyecto que contiene el código en el Visual Studio tal y como se ve en la figura 2.4 9

20 Figura 2.4 Agregar referencia CRMService Una vez hecho esto se podría utilizar el espacio de nombres antes mencionado, crear entidades y llamar al servicio para que CRM las guarde, tal y como se contemplará en el Diseño Interno del sistema Aparatado WinAudit WinAudit es una aplicación de software libre, se puede descargar desde la página web Ésta aplicación produce un informe con todos los aspectos de la configuración y el inventario del ordenador en donde se ejecuta. El programa se compone de un archivo, no necesita instalación, lo que lo hace más fácil de utilizar. Posee una interfaz de usuario: 10

21 Figura 2.5 Interfaz WinAudit En Opciones se puede configurar las categorías del inventario que se quieren obtener. Existe una completa documentación en la página web donde se puede obtener información sobre cada una de las categorías: 11

22 Figura 2.6 WinAudit. Categorías de la Auditoría El informe se puede obtener en múltiples formatos. Si no se indica ninguno el resultado se muestra como un documento HTML. Figura 2.7 WinAudit. Fomatos de generación del informe Para el presente proyecto se necesita obtener un formato que pueda ser fácilmente transportado y manipulado. El formato más apropiado, dado que las comunicaciones entre clientes y servidor que se van ha establecer utilizarán el protocolo SOAP basado en XML, será el propio XML. Por otro lado, Visual Studio y el Framework de.net proporcionan herramientas para tratar éste tipo de documentos. Por último, para que se cumpla el requisito de transparencia con el usuario final, si se desea que éste no se entere de que se está ejecutando el programa WinAudit para obtener la auditoría de su ordenador y asimismo no repercuta en su trabajo, es necesario prescindir de la interfaz gráfica de WinAudit. WinAudit está pensado para poder ser ejecutado vía línea de comandos, sin mostrar la ventana principal, tan sólo una ventana de información, que si se une al hecho de que los servicios de Windows no interactúan con el escritorio resulta que en realidad no se muestre absolutamente nada, lo que hace que sea la herramienta perfecta para éste proyecto. En la página de la aplicación existe documentación de cómo utilizarla mediante línea de comandos, en inglés: 12

23 La sintaxis del commando (todo en una línea) es la siguiente: WinAudit.exe /h /r=gsopxutueerntnzdaibmpmidcsarblf /o=format /f=file /u=user /p=pwd /e="extensions" /l=logfile /m=msg Todos los switches son opcionales, Si no se especifica ninguno el programa arranca la ventana principal. Para ver la tabla donde se explica el significado y los posibles valores de cada switch consultar el Anexo 3. Tecnologías CCleaner v CCleaner es una herramienta que permite realizar una limpieza a fondo del sistema, mejorando el rendimiento general y aumentando el espacio libre disponible en disco. CCleaner funciona como el Liberador de espacio en disco que trae Windows pero de manera mucho más efectiva. Eliminando ficheros temporales, archivos inútiles utilizados en algún proceso de instalación, cookies, papelera de reciclaje e incluso registrando el Registro de Windows en busca de entradas no válidas. Antes de eliminar algo CCleaner permite especificar si hacerlo o no de modo tal de no perder información que sea relevante. 13

24 Figura 2.8 CCleaner La aplicación con su interfaz permite, además de realizar la limpieza, examinar el registro de Windows en busca de entradas inútiles o malintencionadas. En cualquier caso, la utilidad que aporta al presente proyecto es la posibilidad de ejecutar el programa por línea de comandos mediante el comando: ccleaner /AUTO - Ejecuta el limpiador al cargar el programa y después lo cierra Windows Task Scheduler El Programador de Tareas de Windows es un servicio que programa y ejecuta aplicaciones automáticamente. El explorador de Windows proporciona una interfaz que permite fácilmente programar tareas. Dicho interfaz se puede acceder a través de la ruta: %WINDIR%\TASKS o desde el panel de control. Por línea de comandos el comando schtasks y el Viejo comando at producen el mismo resultado. Los programadores poseen una interfaz COM bien documentada pero el.net Framework no ofrece ningún interfaz. David Hall, un ilustre programador asociado a la página web diseñó una librería que hace de interfaz con dicha herramienta permitiendo al programador integrarse con la herramienta de tareas programadas de forma fácil y rápida sin salirse de la tecnología.net. 14

25 De la página web de codeproyect se puede bajar la documentación y la librería. La librería se debe asociar al proyecto de Visual Studio con el Solution Explorer haciendo clic en el botón derecho del ratón sobre Referencias y añadiendo una nueva referencia: Figura 2.9 Agregar la librería TaskScheduler al proyecto La documentación se obtiene en un documento HTML que sigue el estilo MSDN, lo que la hace fácil de seguir y entender. Se incluye dicha documentación de ayuda junto con el proyecto en CD. 15

26 Figura 2.10 Archivo de Ayuda de la librería del TaskScheduler 2.7 Introducción a Microsoft SQL Server Gestor de base de datos relacional. El lenguaje que utiliza es Transact SQL, que es el derivado del estándar SQL. Se suele aplicar en bases de datos de PYMES, aunque de cinco años a ahora se ha incrementado su uso en grandes bases de datos empresariales. El uso de T SQL añade principalmente sintaxis para poder hacer uso de procedimientos almacenados. Cumple con los requerimientos ACID transaccionales (Atómico, Consistente, Aislado y Durable). La comunicación la ejerce en el nivel de aplicación con un protocolo llamado TDS (Tabular Data Stream) aunque también soporta ODBC (Open Database Conectivity), JDBC para Java y protocolos de servicios Web (SOAP). En el nivel de transporte es necesario habilitar el protocolo TCP/IP mediante la herramienta de configuración de SQL: 16

27 Figura 2.11 Sql Server Configuration Manager Tres cualidades que también son destacables son la replicación, clustering para evitar fallos y snapshots de base de datos. La herramienta que sirve de interfaz para el sistema Sql Server y que va ha utilizarse en este proyecto es el Sql Server Management Studio Express: Figura 2.12 Sql Server Configuration Manager 17

28 3. Metodología de Trabajo Para conseguir un software de calidad, que sea duradero y fácil de mantener hay que idear una sólida base arquitectónica que sea flexible al cambio. Para desarrollar software rápida y eficientemente, minimizando el trabajo de recodificación y evitando crear miles de líneas de código inútil hay que disponer, además de la gente y las herramientas necesarias, de un enfoque apropiado. Es necesario seguir una determinada metodología y no abordar los problemas de manera desordenada, con el fin de obtener un modelo que represente el problema que hay que abordar. Se define la metodología como el método sistemático de abordar la resolución de un problema. Una metodología de desarrollo de software se fundamenta sobre tres pilares básicos: qué hay que hacer y en qué orden, cómo deben realizarse las tareas y con qué pueden llevarse a cabo. Esto es, qué etapas, actividades y tareas se deben acometer, qué técnicas deben emplearse para realizar estas actividades y cuáles son las herramientas a utilizar en cada caso. Por otro lado, toda metodología requiere un lenguaje de representación. Todos los diagramas y representaciones gráficas que se realizarán a lo largo de la metodología de desarrollo de este sistema están basados en notación UML. Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo específico, tan solo se trata de una notación. Para ver detalles de dicho lenguaje ver el Anexo 4. Metodologías Puesto que el lenguaje de programación a utilizar va a ser un lenguaje orientado a objetos, se utilizará también una metodología de desarrollo de software orientada a objetos, frente a las metodologías de análisis estructuradas utilizadas en proyectos en los que se usan otros tipos de lenguajes estructurados (como pueda ser C). 3.1 Introducción al Análisis de requerimientos El objetivo de esta fase o etapa es alcanzar un conocimiento suficiente del sistema, definiendo las necesidades, problemas y requisitos del usuario. A lo largo de esta etapa se llevarán a cabo las siguientes actividades: 1. Desarrollar el modelo de dominio El modelo de dominio es una herramienta de comunicación fundamental que obliga a los desarrolladores y usuarios a pensar formalmente sobre el problema, les permite validar su comprensión y establece el vocabulario del espacio del problema. Junto con los requerimientos, constituye la entrada más importante para el diseño. 18

29 Para representar el modelo de dominio se utilizará los diagramas de clase UML y posteriormente se describirá las clases y relaciones que aparecen en ellos. Las clases representan los conceptos existentes en el domino del problema. Estos conceptos suelen tener información asociada y relaciones entre ellos. Una clase se representa mediante una caja subdividida en tres partes: en la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Los atributos representan información relevante asociada a los conceptos del dominio. Opcionalmente se mostrará su tipo de dato. Las asociaciones representan relaciones entre conceptos del dominio. Las asociaciones entre dos clases se representan mediante una línea que las une. El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea. Se puede añadir un pequeño triángulo negro sólido que indique la dirección en la cual leer el nombre de la asociación. La cardinalidad es una restricción que se pone a una asociación y que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase. Puede ser un número (1), un rango (2..5), una enumeración (0,1,3,5) o una combinación de los anteriores (0..2,5,7..*). El * significa cualquier número arbitrariamente grande. 2. Identificar casos de uso del sistema Se debe realizar un diagrama de Casos de Uso y posteriormente describir cada caso de uso. Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. En la Figura 3.1 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático. 19

30 Figura 3.2 Introducción Casos de Uso Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso. Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores. Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. 20

31 3.2 Introducción al Diseño externo del sistema En esta etapa se definen los componentes del sistema (aplicaciones del sistema, módulos ) y la comunicación entre ellos y con los sistemas externos. Las actividades que tendrán lugar durante esta etapa son: 1. Identificar la arquitectura del sistema En esta actividad se define la arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la especificación detallada de la infraestructura tecnológica necesaria para dar soporte al sistema de información. El particionamiento físico del sistema de información se especifica identificando los nodos y las comunicaciones entre los mismos, con cierta independencia de la infraestructura tecnológica que da soporte a cada nodo. Con el fin de organizar y facilitar el diseño, se realiza una división del sistema de información en subsistemas de diseño, como partes lógicas coherentes y con interfaces claramente definidas. 2. Elaborar el diagrama de paquetes Los paquetes se utilizan para agrupar las clases del sistema que de alguna manera guardan cierta relación. De esta forma se consigue estructurar grandes sistemas con un número elevado de clases. Cualquier sistema grande se debe dividir en unidades más pequeñas, de modo que las personas puedan trabajar con una cantidad de información limitada, a la vez y de modo que los equipos de trabajo no interfieran con el trabajo de los otros. Un paquete es una parte de un modelo. Cada parte del modelo debe pertenecer a un paquete. Pero para ser funcional, la asignación debe seguir un cierto principio racional, tal como funcionalidad común, implementación relacionada y punto de vista común. UML no impone ninguna regla a la hora de componer los paquetes. Los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado. Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema). Los paquetes son unidades de organización jerárquica de uso general de los modelos de UML. Pueden ser utilizados para el almacenamiento, el control de acceso, la gestión de la configuración y la construcción de bibliotecas que contengan fragmentos reutilizables del modelo. Un paquete puede contener otros paquetes, sin límite de anidamiento pero cada elemento pertenece a (está definido en) sólo un paquete. 21

32 Las dependencias que se presentan entre elementos individuales, pero en un sistema de cualquier tamaño, deben ser vistas en un nivel más alto. Las dependencias entre paquetes resumen dependencias entre los elementos internos a ellos. Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes. Todas las clases no son necesariamente visibles desde el exterior del paquete, es decir, un paquete encapsula a la vez que agrupa. En general, un paquete no puede tener acceso al contenido de otro paquete. Los paquetes son opacos, a menos que sean abiertos por una dependencia de acceso o de importación. La dependencia de acceso indica que el contenido del paquete del proveedor puede aparecer en referencias efectuadas por los elementos del paquete cliente. En general, un paquete puede ver solamente los elementos de otros paquetes que tienen visibilidad pública. Los elementos con visibilidad protegida pueden ser vistos únicamente por los paquetes que son descendientes del paquete contenedor de dichos elementos. Los elementos con visibilidad privada sólo son vistos por su paquete contenedor y anidados. La visibilidad también se aplica a las clases. El permiso de acceso y visibilidad son necesarios para hacer referencia a un elemento. La dependencia de acceso no modifica el espacio de nombres del cliente no crea las referencias automáticamente, simplemente concede permiso para establecer referencias. La dependencia de importación se utiliza para agregar nombres al espacio de nombres del paquete del cliente como sinónimos de los caminos completos. Los paquetes se dibujan como rectángulos con pestañas (similar al icono "carpeta"), las dependencias se muestran como flechas con líneas discontinuas. 22

33 Figura 3.3 Introducción Diagramas de Paquetes Figura 3.4 Ejemplo Diagrama de Paquetes 3.3 Introducción al Diseño interno del sistema En esta etapa se adecua el análisis a las características específicas del ambiente de implementación y se completan las distintas aplicaciones del sistema realizando las siguientes actividades: 1. Desarrollar el modelo de interfaz Las interfaces de usuario gráficas se han convertido en parte de nuestra vida cotidiana. Nos encontramos con ellas en el trabajo, en nuestro tiempo libre, cuando compramos y cuando viajamos. Los procedimientos complejos y el incremento en el número de funciones hacen que el diseño y una clara estructura sean extremadamente importantes. La interfaz de usuario tiene las tareas de recoger funciones y procesos y de representar información clara. El diseño de una pantalla es una interpretación de las cualidades definidas en el diseño y concepción de procesos. El diseño GUI con su alta calidad estética da al producto un carácter atractivo influyendo en la calidad final de la aplicación. Un producto con un buen diseño necesita una buena estructura y un diseño que no caduque rápidamente, que no sea molesto ni aburrido. Las reuniones de diseño se realizan con clientes y usuarios. A partir de ellas se desarrollan las primeras ideas. 23

34 Uno de los aspectos clave en el diseño de la interfaz del sistema es la usabilidad, La Organización Internacional para la Estandarización (ISO) ofrece dos definiciones de usabilidad: ISO/IEC 9126: "La usabilidad se refiere a la capacidad de un software de ser comprendido, aprendido, usado y ser atractivo para el usuario, en condiciones específicas de uso". Esta definición hace énfasis en los atributos internos y externos del producto, los cuales contribuyen a su funcionalidad y eficiencia. La usabilidad depende no sólo del producto sino también del usuario. Por ello un producto no es en ningún caso intrínsecamente usable, sólo tendrá la capacidad de ser usado en un contexto particular y por usuarios particulares. La usabilidad no puede ser valorada estudiando un producto de manera aislada (Bevan, 1994). ISO/IEC 9241: "Usabilidad es la eficiencia y satisfacción con la que un producto permite alcanzar objetivos específicos a usuarios específicos en un contexto de uso específico" Es una definición centrada en el concepto de calidad en el uso, es decir, se refiere a cómo el usuario realiza tareas específicas en escenarios específicos con efectividad. A partir de la conceptualización llevada a cabo por la ISO, se infieren los principios básicos en los que se basa la usabilidad: Facilidad de Aprendizaje: facilidad con la que nuevos usuarios desarrollan una interacción efectiva con el sistema o producto. Está relacionada con la predicibilidad, sintetización, familiaridad, la generalización de los conocimientos previos y la consistencia. Flexibilidad: relativa a la variedad de posibilidades con las que el usuario y el sistema pueden intercambiar información. También abarca la posibilidad de diálogo, la multiplicidad de vías para realizar la tarea, similitud con tareas anteriores y la optimización entre el usuario y el sistema. Robustez: es el nivel de apoyo al usuario que facilita el cumplimiento de sus objetivos. Está relacionada con la capacidad de observación del usuario, de recuperación de información y de ajuste de la tarea al usuario. La buena usabilidad puede lograrse mediante el diseño centrado en el usuario (que no necesariamente dirigido por él), aunque se emplean diversas técnicas. El diseñador de usabilidad proporciona un punto de vista independiente de las metas de la programación porque el papel del diseñador es actuar como defensor del usuario. Por ejemplo, tras 24

35 interactuar con los usuarios, el diseñador de usabilidad puede identificar necesidades funcionales o errores de diseño que no hayan sido anticipados. 2. Elaborar los diagramas de secuencia con el detalle de las operaciones más importantes La vista de interacción describe secuencias de intercambios de mensajes entre los roles que implementan el comportamiento de un sistema. Un rol clasificador, o simplemente "un rol", es la descripción de un objeto, que desempeña un determinado papel dentro de una interacción, distinto de los otros objetos de la misma clase. Esta visión proporciona una vista integral del comportamiento del sistema, es decir, muestra el flujo de control a través de muchos objetos. La vista de interacción se exhibe en dos diagramas centrados en distintos aspectos pero complementarios: centrados en los objetos individuales y centrados en objetos cooperantes. Los objetos interactúan para realizar colectivamente los servicios ofrecidos por las aplicaciones. Los diagramas de interacción muestran cómo se comunican los objetos en una interacción. Existen dos tipos de diagramas de interacción: el Diagrama de Colaboración y el Diagrama de Secuencia. El Diagrama de Secuencia es más adecuado para observar la perspectiva cronológica de las interacciones, muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos; es el que se va a utilizar. Muestra la secuencia de mensajes entre objetos durante un escenario concreto. Cada objeto viene dado por una barra vertical. El tiempo transcurre de arriba abajo. Cuando existe una bifurcación se representan las condiciones en la llamada mediante el uso de corchetes [ ]. Un mismo objeto puede emprender una acción u otra lo que se representaría con dos barras paralelas. Un proceso que se repite se representa con una flecha circular que sale del punto en que termina dicho proceso y entra en el punto en que empieza. 25

36 Clase1 Clase2 Clase3 Paquete superior::user op() Condición De Bifurcación Instancia de una clase del dominio [x<0] op(x) Nueva instancia de la clase 1 Bifurcación [x>0] LlamarC(X) Llamada a clase de otro subsistema <<create>> setx(x) ob4 : Clase4 Edición o creación de un objeto del dominio. retorno recurrencia <<forward>> gety(x) Nueva llamada al objeto ob5 Retorno El objeto se destruye en este punto <<create>> Obtención de un objeto del dominio. retorno de objeto ob5 : Clase5 El objeto sigue con vida Figura 3.5 Introducción Diagrama de Secuencia 3. Agregar detalles de implementación al modelo de dominio. Diagrama de Clases. Se trata de construir un modelo de diseño basándose en el modelo de análisis, pero incorporando detalles de implementación. El diseño de objetos se centra en las estructuras de datos y algoritmos que son necesarios para implementar cada clase en el lenguaje de programación que se vaya a utilizar (orientados y no orientados a objetos, bases de datos, etc.). Para diseñar las clases se especificarán los métodos y atributos que cada clase va a necesitar para que el sistema pueda alcanzar toda la funcionalidad requerida. 4. Describir el modelo de datos El diseño de bases de datos es el proceso por el que se determina la organización de una base de datos, incluidos su estructura, contenido y las aplicaciones que se han de desarrollar. 26

37 El diseño de una base de datos es un proceso complejo que abarca decisiones a muy distintos niveles. La complejidad se controla mejor si se descompone el problema en subproblemas y se resuelve cada uno de estos subproblemas independientemente, utilizando técnicas específicas. Así, el diseño de una base de datos se descompone en diseño conceptual, diseño lógico y diseño físico. 1. El diseño conceptual parte de las especificaciones de requisitos de usuario y su resultado es el esquema conceptual de la base de datos. Un esquema conceptual es una descripción de alto nivel de la estructura de la base de datos, independientemente del SGBD que se vaya a utilizar para manipularla. Un modelo conceptual es un lenguaje que se utiliza para describir esquemas conceptuales. El objetivo del diseño conceptual es describir el contenido de información de la base de datos y no las estructuras de almacenamiento que se necesitarán para manejar esta información. En este caso, tras realizar un análisis de requisitos, se obtiene un modelo conceptual de datos fiable a partir del modelo de dominio, traduciéndolo al modelo Entidad-Relación. Ver Modelo Entidad Relación en el Anexo 4. Metodologías 2. El diseño lógico parte del esquema conceptual y da como resultado un esquema lógico. Un esquema lógico es una descripción de la estructura de la base de datos en términos de las estructuras de datos que puede procesar un tipo de SGBD. Un modelo lógico es un lenguaje usado para especificar esquemas lógicos (modelo relacional, modelo de red, etc.). El diseño lógico depende del tipo de SGBD que se vaya a utilizar, no depende del producto concreto. El diseñó lógico del modelo de datos pasa por una nomalización del mismo. El proceso de normalización de una base de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo E-R (entidad-relación) al modelo relacional. Las bases de datos relacionales se normalizan para evitar la redundancia de los datos, evitar problemas de actualización de los datos en las tablas y proteger la integridad de los datos. El paso del modelo conceptual de datos al modelo lógico supone una abstracción, un mecanismo para la conversión del mundo real a un mundo formado por datos, a su agrupación y clasificación. El proceso de abstracción consiste en identificar los elementos ó conceptos empleados en el modelo global y transformarlo en lo que denominamos entidades en el modelo lógico. El resultado de esta transformación se traduce en un nuevo modelo: El modelo RE/R. Ver Anexo 4. Metodologías. Diagrama RE/R 3. El diseño físico parte del esquema lógico y da como resultado un esquema físico. Un esquema físico es una descripción de la implementación de una base de datos en memoria secundaria: las estructuras de almacenamiento y los métodos utilizados para tener un acceso eficiente a los datos. Por ello, el diseño físico depende del SGBD concreto y el esquema físico se expresa mediante su lenguaje de definición de datos. 27

38 Un aspecto importante a la hora de programar la base de datos es tener en cuenta el tratamiento que se va ha hacer de ella, es decir, las consultas que se van ha necesitar realizar y, en base a ello, puede ser necesario realizar modificaciones en el modelo de datos obtenido en el diseño lógico de forma que se aumente el rendimiento considerablemente. A este procedimiento se le denomina desnormalización de la base de datos. Una vez finalizado esta etapa, se dispone de un modelo de datos preparado para ser implementado. 3.4 Introducción a la Implementación, pruebas e Implantación Se desarrollará el código de la aplicación y se realizarán las pruebas de software necesarias que certifiquen que la aplicación funciona de manera correcta. El objetivo de estas pruebas es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseño ni programación y que se corresponde con los requerimientos. Las pruebas serán planteadas tanto a nivel de cada módulo (aislado del resto), como de integración del sistema. Como resultado de esta etapa se obtendrá el código ejecutable de las aplicaciones del sistema, el sistema instalado y operativo y los manuales de usuario y explotación. Así, se podrían definir varias etapas en este apartado: 1. Implementación de la base de datos Para poder comenzar con el desarrollo se hace necesario tener un modelo de datos ya construido con el que poder trabajar. Es, por tanto, la primera tarea a abordar en esta etapa, desarrollar la base de datos y los métodos para acceder a la misma. 2. Desarrollo del código Etapa de programación de los componentes de la aplicación. En esta etapa se cumplimentarán las clases que se han descrito en el diseño interno junto con los algoritmos necesarios para cumplir con el cometido de cada una así como la implementación de la interfaz de usuario cuando fuese necesario. Todo ello condicionado por la plataforma de desarrollo escogida así como por la metodología de comunicación entre módulos a implementar. 3. Pruebas unitarias Una vez se haya desarrollado el código de los subsistemas se podrán realizar las pruebas de dichos subsistemas y sus módulos por separado. El objetivo de las pruebas unitarias es aislar, cada parte del programa y mostrar que las partes individuales son correctas. 4. Pruebas de Integración El objetivo de las pruebas de verificación es comprobar que los módulos o componentes que conforman un sistema funcionan correctamente en conjunto o integrados. Así mismo se comprueba que el sistema desarrollado cumple con los requisitos definidos. 28

39 Para garantizar la estabilidad de la aplicación y el cumplimiento de los requerimientos propuestos se plantean las siguientes pruebas: Look & Feel: A partir de los estándares de presentación definidos se definen los requerimientos de pruebas genéricos que se validan en cada una de las aplicaciones que componen la solución. Se lleva registro de los requerimientos ejecutados y los hallazgos obtenidos. En caso que alguno de los requerimientos no aplique sobre alguno de los productos también se deja registro de ello, describiendo las razones por las cuales no se considera dentro del producto. Autenticación Única de Usuarios: Se valida el registro de los usuarios a la solución, la conexión se realiza una vez y este debe ser reconocido en cada una de las aplicaciones de la solución, sin que se solicite nuevamente login y usuario al invocar la ejecución de alguna de ellas. Se debe verificar que los accesos del usuario en cada aplicación corresponden a los definidos en cada producto de la solución. Administración de Usuarios: Se validan los requerimientos de administración de usuarios (creación de usuarios, modificación de datos, cambio de password, eliminación de usuarios, activación y desactivación de usuarios). Operación en Ambiente Integrado: Consiste en validar que cada producto funciona adecuadamente en la plataforma definida para la solución, sin que exista conflicto entre el software base instalado e incluso entre las mismas aplicaciones. Para realizar esta validación se realiza la selección de los procesos que se ejecutarán en el ambiente integrado. Repositorio Central de Datos: Se realiza validación de la estructura del repositorio central de datos para garantizar que no exista conflicto con los tipos de datos y longitudes de los mismos. El repositorio debe tener en cuenta la estructura de los datos fuentes y destinos para garantizar su correcta operación. Además, debe considerar que los destinos pueden ser múltiples aplicaciones. Integración Funcional: Se validan la sincronización a nivel de procesos, es decir la interacción entre los productos a partir de la ejecución de procesos y la transferencia de información a otros procesos. Se deben identificar los procesos de las aplicaciones que interactúan y el mecanismo de intercambio de información. Este puede realizarse a través de interfaces directas entre aplicaciones como en este proyecto o mediante el uso de herramientas altamente configurables que actúan como mediadores. Instalador: En caso que se construya un instalador único para la aplicación, se debe validar el correcto funcionamiento de este, es decir que realice la instalación de los productos de software que componen la solución y el software adicional requerido para su adecuada operación. En el presente proyecto, se verificará que el sistema de actualización automática de los agentes funciona correctamente. 29

40 PRUEBAS NO FUNCIONALES Adicionalmente, dependiendo de las características de la solución se pueden requerir la ejecución de pruebas No Funcionales tales como: Pruebas de desempeño (carga) Pruebas de Resistencia (stress) Pruebas de Seguridad Pruebas de Rendimiento 5. Implantación en entorno de producción Tras pasar las pruebas de integración, el sistema construido tiene la fiabilidad suficiente como para poder ser traspasado al entorno de producción. Se deberá especificar en qué máquinas cliente se va ha realizar la instalación de los agentes. Asimismo se deberá especificar el método de instalación y proveer de los manuales de explotación y de usuario del sistema correspondientes. 30

41 4. Análisis de Requerimientos 4.1 Modelo de Dominio 1 Limpieza -Seleccion Auditoria InicioServicio -Seleccion Apagado Tarea -idtarea -Descripcion * [Fecha, Estado] PERTENECE -iddominio -Nombre * Dominio -idcliente -Nombre Cliente PERTENECE * 1 * PERTENECE Alerta -idalerta -Descripcion -Fecha 1 1 GENERA * TIENE AuditoriaResultado 1 ** TIENE * Maquina -idmaquina -NombreHost -TimeStamp -Permiso 1 1 * 1 GENERA Tarea Figura Modelo de Dominio I Una tarea se define como una posible acción que se puede llevar a cabo en un cliente. Cada tarea requerirá un método específico para que pueda ser realizada por los clientes. Los 31

42 clientes deberán poder interpertar que tarea deben realizar. Las tareas se ejecutan en una fecha concreta y puede definirse un estado de la tarea en función de si se ha ejecutado, si esta pendiente de que la máquina lo sepa o si está pendiente de ejecución (ya enviada a la máquina cliente). Entre las tareas que pueden realizarse se encuentra la tarea de auditoría que por su significado en el proyecto es la más importante. Auditoría: Requiere una selección de los campos a auditar lo que, por tanto, es un atributo de esta tarea. Se trata de la ejecución del programa WinAudit visto en el apartado Los clientes deben poseer la capacidad de ejecutar el programa y manejar la auditoría resultado. A parte de la auditoría, también pueden haber otras tareas, como la ejecución del programa CCleaner (limpieza) visto en el apartado o el inicio de un servicio, apagado de la máquina cliente u otras tareas que puedan definirse durante el proyecto o en posteriores evoluciones. Cliente y Dominio El cliente es la empresa cliente de Evotec, que está previamente registrada en el CRM. Son los propietarios de las máquinas cliente. Los clientes normalmente tienen definido un dominio desde el que administrar sus sistemas de información y máquinas. Puede ser que tengan definido más, lo que no es normal, o que no tengan dominio definido. El dominio es conocido por las máquinas de los clientes y, es mediante el cual, el sistema podría asociar las máquinas a sus respectivos clientes. Máquina Con máquina se hace referencia a todas las máquinas cliente, donde residirán los agentes del sistema. Las máquinas pueden ser, servidores de información u cualquier otro equipo. Una máquina normalmente tiene un nombre host único en un dominio por el que puede ser identificada. No obstante, lo que es seguro es que las máquinas tienen definido un número de serie único asignado por el fabricante. Auditoría resultado Es el resultado de la ejecución de una tarea auditoría en una máquina. Éste puede variar en función de los campos que se definen para auditarse. Consultar apartado y Anexo 3. Alerta Las alertas son comunicadores disparados ante estados definidos en una máquina cliente. Dichos estados se pueden monitorizar mediante las auditorías resultado. 32

43 1 MemoriaRAMLibre 1 ServicioNoArrancado 1 AltaPrograma -FechaInstalacion -Owner Alert -idalerta -Descripcion -Fecha GENERA * 1 BajaPrograma -FechaInstalacion -FechaDesinstalacion -NumeroVecesUsado -Owner EspacioDisco ErrorLog 1 AuditoriaResultado 1 * 1 1 CampoAuditoria TareasProgramadas Pantalla Impresoras 1 1 DiscosLógicos Errores ProgramasArranque Dispositivos ModulosCargados SoftwareInstalado Procesadores PuertosYslots EstadísticasDesdeArranque VistaGeneral 1 1 Servicios Periféricos ProgramasArrancados RedBIOS SistemaOperativo 1 Memoria ParámetrosSeguridad Red TCP/IP DiscosFísicos Red Windows 1 Figura Modelo de Dominio II 33

44 Previamente se ha visto la definición de alerta. Los estados definidos de las máquinas cliente que generan estas alertas se pueden observar en la figura 4.2 y tienen que ver con el disco duro de las máquinas, la memoria RAM, los programas instalados, los errores en el sistema o en las aplicaciones y los servicios no arrancados. Por otro lado el resultado de la auditoría está compuesto de varios campos, los que se pueden ver también en la figura 4.2. Algunos de dichos campos pueden generar alertas tal y como se aprecia en la figura. 4.2 Casos de uso Sistema EvoAgent Iniciar Aplicación Servicio Windows Iniciar Aplicación Icono en Barra de Tareas Máquina Cliente Consultar Informacion de la Apliación Lanzar Cliente Escritorio Remoto Evotec Técnico Evotec Usuario Máquina Cliente Figura 4.3 Diagrama de Casos de Uso I 34

45 Sistema EvoAgentManager Tareas Ver Tareas Programadas «uses» Ver Propiedades de Tarea Programada «uses» Editar Tarea Programada «uses» EliminarTarea Programada Programar Tarea Task Scheduler Revisar Estado de Tareas Nueva Tarea «uses» Eliminar Tarea Pendiente «uses» Buscar Tareas «uses» Borrar Tareas Técnico Evotec «uses» Editar Tarea Crear Nuevo Dominio Dominios y Clientes Eliminar Dominio y Asociaciones Técnico Evotec Actualizar Clientes Actuales CRM Asociar Dominio con Cliente Asociar Maquinas a Dominio y Cliente Borrar Maquinas de Dominio y Cliente Figura 4.4 Diagrama de Casos de Uso II 35

46 Sistema EvoAgentManager Máquinas Permitir Acceso al Sistema Denegar Acceso al Sistema Técnico Evotec Buscar Máquinas Ver Detalle Auditorías Settings de la Aplicación Alertas Establecer Usuario Propietario de Alertas Establecer Elementos Generadores de Alerta Técnico Evotec Gestión de Versiones Usuarios Establecer la Última Version del Cliente Establecer Ruta del Repositorio de Versiones Actualizar Usuarios de la Apliación CRM Log Errores Buscar Errores por Fecha Ver Errores Actualizar Lista Errores Borrar Lista Errores Figura 4.5 Diagrama de Casos de Uso III 36

47 Sistema EvoAgentServer Módulo ProgramaciónTareas Registrar TareaMaquina de Tarea Programada Task Scheduler Caso de uso: Buscar Tareas Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Figura 4.6 Diagrama de Casos de Uso IV Precondiciones: Existen máquinas y tipos de tareas registradas en el sistema. Escenario principal: 1. El sistema muestra en una lista las tareas pendientes de todas las máquinas de todos los clientes en un rango de fechas de 20 días. 2. El técnico modifica los parámetros de búsqueda. 3. El sistema actualiza la lista mostrando las tareas que cumplan dichos parámetros. Extensiones: Descripción de datos: Parámetros de búsqueda: Cliente/s Máquina/s Tipo/s de tarea/s Estado Fecha Mínima Fecha Máxima Caso de uso: Nueva Tarea Actor primario: Técnico de Evotec. 37

48 Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Existen máquinas y tipos de tareas registradas en el sistema. Escenario principal: 1. El sistema muestra los clientes, máquinas y tipos de tareas disponibles para la programación de una nueva tarea. 2. El técnico selecciona la/las máquinas, tipo/tipos de tareas, sus argumentos y la fecha para la realización de la nueva tarea. 3. El sistema registra la/las nueva/s tareas y actualiza la lista de tareas con la información de la nueva tarea si ésta cumple con los parámetros de búsqueda. Extensiones: Descripción de datos: Caso de uso: Eliminar Tarea Pendiente Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Existen tareas pendientes registradas en el sistema. Escenario principal: 1. Caso de Uso Buscar Tareas 2. El técnico selecciona la tarea que desea eliminar. 3. El sistema elimina la tarea y actualiza la lista de tareas. Extensiones: 3 a. La tarea seleccionada no está en estado = pendiente. Descripción de datos: Caso de uso: Borrar Tareas Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Existen tareas registradas en el sistema. Escenario principal: 1. Caso de Uso Buscar Tareas 2. El sistema borra la/s tarea/s incluidas en la lista. Extensiones: 38

49 Descripción de datos: Caso de uso: Editar Tarea Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Existen tareas pendientes registradas en el sistema. Escenario principal: 1. Caso de Uso Buscar Tareas. 2. El técnico selecciona la tarea a editar. 3. El sistema habilita la edición de los atributos de la tarea. 4. El técnico edita los atributos de la tarea. 5. El sistema guarda los cambios de la tarea editada. Extensiones: 3 a. La tarea seleccionada no está en estado = pendiente. Descripción de datos: Caso de uso: Revisar estado de las tareas Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: Escenario principal: 1. Caso de Uso Buscar Tareas. 2. El técnico solicita la actualización de la lista de tareas. 3. El sistema actualiza la lista con las tareas que cumplan con los parámetros de búsqueda Extensiones: Descripción de datos: Parámetros de búsqueda: Cliente/s Máquina/s Tipo/s de tarea/s Estado Fecha Mínima 39

50 Fecha Máxima Caso de uso: Programar Tarea Actor primario: Técnico de Evotec. Actor secundario: Task Scheduler. Trigger: El técnico inicia la transacción. Precondiciones: Existen máquinas y tipos de tareas registradas en el sistema. Escenario principal: 1. El sistema muestra los clientes, máquinas y tipos de tareas disponibles para la programación de una nueva tarea. 2. El técnico selecciona la/las máquinas, tipo/tipos de tareas y sus argumentos para la realización de la nueva tarea. 3. El sistema muestra las posibles periodicidades de ejecución. 4. El técnico selecciona la periodicidad de ejecución de la tarea. 5. El técnico configura la periodicidad de ejecución 6. El técnico proporciona las credenciales para la ejecución de la tarea programada. 7. El sistema envía la configuración de la tarea programada al Task Scheduler. 8. El sistema guarda los atributos de máquinas y tipos de tareas de la tarea programada. Extensiones: Descripción de datos: Credenciales para la ejecución de tareas programadas: Dominio\Usuario Contraseña Caso de uso: Ver Tareas Programadas Actor primario: Técnico de Evotec. Actor secundario: Task Scheduler. Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema solicita al Task Scheduler las tareas programadas. 2. El sistema muestra una lista con las tareas programadas. Extensiones: Descripción de datos: 40

51 Caso de uso: Ver Propiedades de Tarea Programada Actor primario: Técnico de Evotec. Actor secundario: Task Scheduler. Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. Caso de uso Ver Tareas Programadas. 2. El técnico selecciona una Tarea Programada. 3. El sistema solicita al Task Scheduler la Tarea Programada. 4. El sistema muestra las propiedades de la Tarea Programada. Extensiones: Descripción de datos: Caso de uso: Editar Tarea Programada Actor primario: Técnico de Evotec. Actor secundario: Task Scheduler. Trigger: El técnico inicia la transacción. Precondiciones: Existen máquinas y tipos de tareas registradas en el sistema. Escenario principal: 1. Caso de Uso Ver Propiedades de Tarea Programada 2. El técnico edita la Tarea Programada. 3. El sistema envía la nueva configuración al Task Scheduler. 4. El sistema guarda los atributos de máquinas y tipos de tareas de la Tarea Programada. Extensiones: Descripción de datos: Caso de uso: Eliminar Tarea Programada Actor primario: Técnico de Evotec. Actor secundario: Task Scheduler. Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. Caso de Uso Ver Tareas Programada. 2. El técnico selecciona una Tarea Programada. 41

52 3. El Task Scheduler elimina la Tarea Programada. 4. El sistema elimina las propiedades de la Tarea Programada. Extensiones: Descripción de datos: Caso de uso: Crear Nuevo Dominio Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El técnico introduce el nombre del dominio que quiere crear. 2. El sistema registra el nuevo dominio en el sistema. Extensiones: Descripción de datos: Caso de uso: Asociar Dominio con Cliente Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: El dominio debe haber sido creado. Escenario principal: 1. El técnico selecciona el dominio y el cliente 2. El sistema asocia el dominio con el cliente. Extensiones: Descripción de datos: Caso de uso: Asociar Máquinas a Dominio y Cliente Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: El dominio debe estar asignado al cliente. Escenario principal: 1. El técnico selecciona la asociación dominio-cliente 2. El sistema muestra las máquinas disponibles. 42

53 3. El técnico selecciona las máquinas a asociar a la asociación dominio-cliente. 4. El sistema asocia las máquinas con el dominio y el cliente. Extensiones: Descripción de datos: Caso de uso: Actualizar clientes actuales Actor primario: Técnico de Evotec. Actor secundario: CRM. Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema solicita todos los clientes existentes al CRM. 2. El sistema actualiza los clientes registrados. Extensiones: 2 a. Los clientes del sistema están actualizados Descripción de datos: Caso de uso: Borrar Máquinas de Dominio y Cliente Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema muestra las máquinas registradas. 2. El técnico selecciona las máquinas que desea borrar del dominio y el cliente. 3. El sistema borra la asociación entre las máquinas seleccionadas y el dominio y cliente asociados. 4. El sistema muestra la nueva configuración de las máquinas. Extensiones: Descripción de datos: 43

54 Caso de uso: Eliminar dominio y asociaciones Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema muestra los dominios registrados. 2. El técnico selecciona el dominio a eliminar. 3. El sistema borra la asociación entre el dominio seleccionado y su cliente asociado y las máquinas. 4. El sistema borra la asociación entre el dominio y el cliente. 5. El sistema borra el dominio seleccionado. 6. El sistema muestra la nueva configuración de las máquinas. Extensiones: 3 a. El dominio no tiene máquinas asociadas. 1. Se vuelve a 4. 4 a. El dominio no tiene cliente asociado. 1. Se vuelve a 5. Descripción de datos: Caso de uso: Buscar Maquinas Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema muestra una lista de clientes. 2. El técnico selecciona un cliente. 3. El sistema muestra las máquinas del cliente seleccionado. Extensiones: 2 a. El técnico introduce el nombre de la máquina, del cliente, del dominio o parte del mismo nombre. 1. El sistema muestra las máquinas cuyo nombre, cliente o dominio coincidan con él. Descripción de datos: 44

55 Caso de uso: Permitir Acceso al Sistema Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. Caso de uso Buscar Maquinas. 2. El técnico selecciona las máquinas. 3. El sistema configura las máquinas para permitirles el acceso al sistema. Extensiones: Descripción de datos: Caso de uso: Denegar Acceso al Sistema Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. Caso de uso Buscar Maquinas. 2. El técnico selecciona las máquinas. 3. El sistema configura las máquinas para denegarles el acceso al sistema. Extensiones: Descripción de datos: Caso de uso: Ver detalle auditorías Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. Caso de uso Buscar Maquinas. 2. El técnico selecciona la máquina. 3. El sistema muestra la información recogida en las auditorías realizadas a la máquina. Extensiones: Descripción de datos: 45

56 Caso de uso: Establecer elementos generadores de alerta Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema muestra los campos potencialmente generadores de alertas y la configuración actual (los campos que son generadores). 2. El técnico selecciona los campos que se desea sean generadores de alertas. 3. El sistema guarda la nueva configuración. Extensiones: Descripción de datos: Caso de uso: Establecer usuario propietario de alertas Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema muestra los usuarios de la aplicación registrados y el usuario propietario. 2. El técnico selecciona el nuevo usuario propietario de alertas. 3. El sistema guarda el nuevo usuario propietario. Extensiones: Descripción de datos: Caso de uso: Actualizar usuarios de la aplicación Actor primario: Técnico de Evotec. Actor secundario: CRM. Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema solicita todos los usuarios existentes al CRM. 2. El sistema actualiza los usuarios registrados. 46

57 Extensiones: 2 a. Los usuarios del sistema están actualizados Descripción de datos: Caso de uso: Establecer la última versión del cliente Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema muestra la última versión del cliente disponible. 2. El técnico introduce la nueva última versión del cliente disponible. 3. El sistema guarda la nueva última versión del cliente disponible Extensiones: Descripción de datos: Caso de uso: Establecer ruta del repositorio de versiones Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema muestra la última ruta del repositorio de versiones. 2. El técnico introduce la nueva ruta del repositorio de versiones. 3. El sistema guarda la nueva ruta del repositorio de versiones. Extensiones: Descripción de datos: Caso de uso: Ver Errores Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. El sistema muestra una lista acotada por fechas de los errores del sistema. 47

58 Extensiones: Descripción de datos: Caso de uso: Buscar Errores por fecha Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. Caso de uso Ver Errores. 2. El sistema muestra las fechas de inicio y fin de búsqueda de errores. 3. El técnico modifica las fechas de inicio y fin de búsqueda de errores. 4. El sistema muestra la lista de errores con los errores que se hayan producido entre las fechas seleccionadas. Extensiones: Descripción de datos: Caso de uso: Actualizar lista de errores Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. Caso de uso Ver Errores. 2. El sistema muestra los errores entre las fechas de inicio y fin de búsqueda. Extensiones: Descripción de datos: Caso de uso: Borrar lista de errores Actor primario: Técnico de Evotec. Actor secundario: --- Trigger: El técnico inicia la transacción. Precondiciones: Escenario principal: 1. Caso de uso Ver Errores. 48

59 2. El técnico selecciona los errores. 3. El sistema borra toda la información concerniente a los errores seleccionados. Caso de uso: Iniciar Aplicación Servicio Windows Actor primario: Máquina Cliente. Actor secundario: --- Trigger: El máquina cliente inicia la transacción. Precondiciones: El usuario de la máquina cliente arranca la máquina e inicia la sesión. Escenario principal: 1. La máquina arranca el servicio de Windows EvoAgentService. Caso de uso: Iniciar Aplicación Icono en barra de tareas Actor primario: Máquina Cliente. Actor secundario: --- Trigger: El máquina cliente inicia la transacción. Precondiciones: El usuario de la máquina cliente arranca la máquina e inicia la sesión. Escenario principal: 1. La máquina arranca la aplicación que carga el icono en la barra de tareas. Extensiones: Descripción de datos: Caso de uso: Lanzar cliente Escritorio Remoto Evotec Actor primario: Máquina Cliente. Actor secundario: Técnico Evotec. Trigger: El usuario de la máquina cliente inicia la transacción. Precondiciones: Escenario principal: 1. El usuario de la máquina cliente solicita el control remoto. 2. El sistema arranca el cliente de la aplicación UltraVNC Viewer. 3. El usuario introduce el id de sesión del técnico. Extensiones: Descripción de datos: Caso de uso: Consultar información de la aplicación. Actor primario: Máquina Cliente. Actor secundario: Técnico Evotec. 49

60 Trigger: El usuario de la máquina cliente inicia la transacción. Precondiciones: Escenario principal: 1. El usuario solicita información de la aplicación. 2. El sistema muestra la información de la aplicación disponible. Extensiones: Descripción de datos: Caso de uso: Registrar TareaMaquina de Tarea Programada Actor primario: Task Scheduler Actor secundario: --- Trigger: El Task Scheduler ejecuta la tarea programada Precondiciones: Escenario principal: 1. El sistema obtiene las máquinas y tareas para registrar las nuevas tareas para las máquinas. 2. El sistema obtiene la próxima ejecución de la tarea para registrar la fecha de las nuevas tareas para las máquinas. 3. El sistema registra las nuevas tareas para las máquinas. 50

61 5. Diseño Externo del Sistema 5.1 Arquitectura del Sistema En este apartado se estudia la solución propuesta para la arquitectura del sistema. En el siguiente gráfico queda reflejada la arquitectura general del sistema y las tecnologías usadas en cada parte. Maquina Cliente EvoAgentService - cliente http Windows XP/2000/Vista Soap-Ssl-Http Servidor de Autenticación Maquina Cliente EvoAgentService cliente http Windows XP/2000/Vista Soap Ssl Http Soap Ssl Http EvoAgentServer Servidor de la aplicación Windows 2003 Server Internet Information Services Sql Servidor de Bases de Datos Sql CRM BBDD EvoAgentBD BBDD Maquina Cliente EvoAgentService cliente http Windows XP/2000/Vista Soap-Http Soap-Http Servidor CRM Sql Puesto Evotec EvoAgentManager cliente http Windows XP Puesto Evotec EvoAgentManager cliente http Windows XP Figura 5.1 Arquitectura General del Sistema Sql Nota: Cada componente servidor que se describe en este diagrama se corresponden con funcionalidades de la aplicación servidor de EvoAgent o aplicaciones con las que se relaciona (CRM 3.0 de Microsoft) y se dibuja como un servidor a efectos ilustrativos. La realidad es que se requiere un equipo que contiene todas las funcionalidades: base de datos, servidor de aplicaciones y de seguridad. 51

62 Servidor de la aplicación Contenedor de los distintos Servicios Web y otras funcionalidades de que se compone la aplicación servidor EvoAgentServer. El servidor de aplicaciones (Internet Information Server) dispone de la lógica de autenticación de usuarios y de acceso a los Servicios Web. En el presente proyecto se creará un sitio Web específico con un directorio particular con el mismo nombre, EvoAgentServer. Mapa del sitio Web: EvoAgentServer bin AdminManager ControlClientes Web.config Figura 5.2 Mapa del Sitio Web El Sitio Web EvoAgentServer se compone de 2 directorios fundamentalmente, ControlClientes y AdminManager, que van a contener el conjunto de los Servicios Web para las aplicaciones cliente, EvoagentService, de las máquinas cliente y para las aplicaciones de gestión, EvoAgentManager, de los puestos de Evotec, respectivamente. ControlClientes: Contiene el Servicios Web con el que se comunica las aplicaciones cliente. El nivel de seguridad de este directorio debe permitir el acceso de todas las máquinas, acceso anónimo en el directorio del sitio Web dentro del Internet Information Server, con lo que la función de autenticación de dichas máquinas pasaría a la propia aplicación. A parte del Servicio Web de control de la aplicación cliente el directorio ControlClientes posee un repositorio con las distintas versiones que se puedan generar para la misma. De esta forma se habilita la posibilidad de descarga y actualización automática de la última versión de la aplicación por parte del cliente. 52

63 AdminManager: Contiene el Servicio Web con el que interactúa la aplicación de gestión EvoAgentManager. El nivel de seguridad de este directorio debe permitir el acceso al mismo únicamente a los técnicos de Evotec con lo que se utiliza una autenticación de Windows integrada. A parte del Servicio Web con el que interactúa la aplicación EvoAgentManager, este directorio recoge las siguientes funcionalidades: o Incidencias: Almacén de documentos de texto que recogen la descripción de los errores del sistema que componen el log de errores para su control. Dentro de las incidencias existen 3 tipos dependiendo del origen de la incidencia. Puede ser del cliente (EvoAgentService), del servidor (EvoAgentServer) o de la interfaz (EvoAgentManager). o Auditorias: Almacén de documentos de texto plano (xml) que recogen el resultado de las auditorías realizadas en las máquinas cliente. o Programación de tareas: Este directorio contiene una aplicación destinada a interpretar las tareas programadas generadas por la aplicación de gestión EvoAgentManager, ProgramacionTareas.exe. La arquitectura de generación de tasks esta pensada para utilizar la herramienta Windows Task Scheduler para programar tareas a ejecutar en las máquinas cliente que se repiten periódicamente. Esta herramienta permite ejecutar programas con una periodicidad establecida. El programa que ejecute esa task deberá poder acceder a la información necesaria para poder registrar las tareas para las máquinas en el servidor. Por tanto se necesita generar una tarea programada (Tarea-xxxx.job), un fichero que contenga la información de las tareas a programar (Tarea-xxxx.xml), un programa que se ejecute para todas las tareas programadas (ProgramacionTareas.exe) y pueda interpretar el fichero que le corresponde y un programa propio para cada tarea que le indique al anterior cuál es el fichero que debe interpretar (Tarea-xxxx.bat). Generación de Tareas Programadas: 53

64 PUESTO EVOTEC SERVIDOR EVOTEC Windows Task Scheduler Task Tarea-xxxx.job Puesto Evotec EvoAgentManager cliente http Windows XP INTRANET Programacion Tareas Programa ProgramacionTareas.exe Archivo XML Tarea-xxxx.xml Archivo Lotes Tarea-xxxx.bat Servicio Web EvoAgentServer Servidor de la aplicación Windows 2003 Server Internet Information Services CRM BBDD Servidor de Bases de Datos SQL Server Figura 5.3 Arquitectura de la generación de tareas programadas Ejecución de Tareas Programadas: 54

65 PUESTO EVOTEC SERVIDOR EVOTEC Task Tarea-xxxx.job Windows Task Scheduler Puesto Evotec EvoAgentManager cliente http Windows XP INTRANET Programacion Tareas Programa ProgramacionTareas.exe Archivo XML Tarea-xxxx.xml Archivo Lotes Tarea-xxxx.bat Servicio Web EvoAgentServer TareasManager Servidor de la aplicación Windows 2003 Server Internet Information Services CRM BBDD Servidor de Bases de Datos SQL Server Figura 5.4 Arquitectura de la ejecución de tareas programadas Además: El archivo de configuración guarda la configuración del sitio Web, métodos de autenticación así como los Settings de la aplicación, conexiones a bases de datos, etc. Servidor de base de datos Permite el acceso a las bases de datos que utiliza el Sistema: 55

66 EvoAgentBD: Base de datos de la aplicación. Contiene todos los datos que maneja el sistema. Evotec_MSCRM: Base de datos del CRM. Contiene los datos de usuarios y clientes necesarios para el sistema. Servidor CRM Integración con la aplicación CRM. El sistema necesita comunicarse con dicha aplicación para el registro de alertas. Servidor de Autenticación Integración con diversos esquemas de autenticación como Active Directory. Puesto Evotec Puesto de trabajo del técnico de evotec. En dicho puesto reside la aplicación de gestión del sistema EvoAgnetManager. Como aplicación de gestión orientada al control del sistema por parte de los técnicos posee interfaz gráfica de usuario. Además contiene el programa servidor de la conexión remota mediante UltraVNC Viewer. Maquina Cliente Máquinas pertenecientes a los clientes. En ellas reside el subsistema EvoAgent, que contiene la aplicación cliente del sistema distribuido, EvoAgentService (servicio de Windows), que se ocupa de ejecutar las tareas programadas para la máquina en que esté instalado, y la aplicación que carga el icono en la barra de tareas, EvoStartup, y que permite al usuario de la máquina visualizar la información de la aplicación y acceder a servicios como el cliente del control remoto, evotec_soporte_remoto. Para la ejecución de tareas se utilizan herramientas del sistema operativo Windows XP/Vista y herramientas de software libre. Este subsistema por tanto contiene un servicio de Windows, una aplicación que carga el icono iniciada desde el registro de arranque de la máquina y las aplicaciones necesarias para completar la funcionalidad EvoAgentService: Servicio de Windows que se encargará de preguntar periódicamente al servidor si tiene tareas a realizar. El sistema operativo arranca el servicio de forma automática al iniciar la máquina. EvoAgentIcon: Programa que carga el icono de la aplicación en la barra de tareas desde el que se puede acceder a la información sobre la aplicación o al programa de control remoto. Requiere de una entrada en el registro de arranque de la máquina. 56

67 5.2 Diagrama de paquetes Primero se mostrará las relaciones del sistema con otros sistemas para ir descendiendo y mostrar los principales subsistemas y paquetes en los que se descompone el sistema Sistema y sistemas externos. Primer nivel EvoAgent Herramienta Centralizada de Monitorización <<import>> <<access/import>> <<access/import>> WinAudit CRM Dynamics Windows Task Scheduler Figura 5.5 Diagrama de Paquetes. Contexto En la imagen se muestra como existen 3 sistemas externos con los que el sistema intercambia información. Se trata de un diagrama que se corresponde en cierto modo con el diagrama de contexto de la metodología de diseño de los diagramas de flujo de datos o DFD s. WinAudit provee conceptos importantes para el sistema que han sido añadidos en el modelo de dominio como son los campos generados en la auditoria. Windows Task Scheduler requiere de implementación de una librería (.dll) o extensión de la aplicación que contiene las clases más importantes con las que se debe trabajar para crear tareas programadas. Micorsoft Dynamics CRM posee una librería de clases con las que trabaja los programadores de extensiones de dicha aplicación. Expandiendo el paquete del sistema EvoAgent o Agente de Evotec se puede observar como se divide en 3 paquetes subsistemas y dos páquetes auxiliares. En la imagen se puede observar como se relacionan cada uno y como se relacionan con los sistemas externos. 57

68 <<system>> EvoAgent <<access/import>> SQL EvoAgentBD EvoAgentLibrary CRM Dynamics <<access/import>> <<import>> <<access>> <<import>> <<import>> Windows Task Scheduler <<import>> <<subsystem>> EvoAgent <<access>> <<subsystem>> EvoAgentServer <<access>> <<subsystem>> EvoAgentManager WinAudit Figura 5.6 Diagrama de Paquetes. Primer Nivel EvoAgentBD se corresponde con el reflejo de los datos tal y como están en la base de datos. Dominio es el paquete que contiene las clases contempladas en el estudio del dominio del sistema. Todos los subsistemas tienen acceso a las clases del dominio. El paquete dominio obtiene alguna de sus clases de los sistemas externos WinAudit y CRM Dynamics Subsistemas EvoAgentServer es la aplicación servidor. Contiene toda la lógica de acceso a datos en el paquete dao y parte de la lógica de negocio del sistema en el paquete services. Como se ha visto en el modelo de arquitectura en su mayoría se compone de servicios Web con los que da servicio a los otros dos subsistemas. Utiliza muchas de las clases definidas en el dominio y el acceso a datos y accede a las necesarias de los sistemas externos CRM Dynamics y WinAudit. Todo ello a través de EvoAgentLibrary. EvoAgentManager es la aplicación de gestión para los técnicos, posee la lógica de presentación en el paquete iu con las clases que se utilizaran. Utiliza las clases pertenecientes al dominio del sistema, el acceso a datos y acceso a los servicios web del servidor, así como las del sistema externo Windows TaskScheduler y WinAudit, todo ello a través de EvoAgentLibrary. 58

69 <<subsystem>> EvoAgentServer <<subsystem>> EvoAgentManager services Programacion Tareas EvoAgentLibrary <<access/import>> iu <<access/import>> Figura 5.7 Diagrama de Paquetes. EvoAgentServer y EvoAgentManager EvoAgentLibrary es la librería del sistema. En ella se encuentra el paquete dominio con las clases del dominio del sistema y el paquete DAO con la capa de acceso a datos. Asimismo posee parte de la capa de negocio con varios servicios en un paquete servicios. Por último accede al subsistema EvoAgnetServer mediante los servicios web ubicados en éste último creando clases Proxy tal y como se explica en el anexo 3 Servicios Web en.net de este documento. La librería será compartida por los distintos componentes de la aplicación, y es utilizada para acceder a los servicios web del servidor por el sistema EvoAgentManager. <<subsystem>> EvoAgentLibrary Services <<access/import>> Microsoft CRM Dynamics <<import>> <<access>> Dominio <<import>> Dao <<access/import>> Windows Task Scheduler <<access>> <<import>> <<access>> EvoAgentServer Services WinAudit SQL EvoAgentBD Figura 5.8 Diagrama de Paquetes. EvoAgentLibrary. 59

70 EvoAgent es la aplicación cliente del sistema, utiliza alguna clase del dominio como las tareas y accede al subsistema EvoAgnetServer mediante los servicios web ubicados en éste último creando clases Proxy tal y como se explica en el anexo 3 Servicios Web en.net de este documento. <<subsystem>> EvoAgent EvoAgentIcon EvoAgentService <<access/import>> <<import>> <<subsystem>> EvoAgentLibrary EvoAgentServer Services Dominio Figura 5.9 Diagrama de Paquetes. EvoAgent 60

71 6. Diseño Interno del Sistema 6.1 Diseño de la Interfaz de Usuario y Diagramas de Interacción En este apartado se va a exponer un análisis interno del funcionamiento del sistema. Para abordarlo se divide en tres apartados. El primero, consta de los subsistemas EvoAgentServer, servidor de la aplicación, y EvoAgentManager, interfaz de gestión para los técnicos de Evotec. Se mostrará el diseño de la interfaz escogido y el resultado funcional de la interacción del usuario con éste, y que se corresponden con los diferentes casos de uso analizados en el apartado 4.2. El segundo, consta de los subsistemas EvoAgentServer, servidor de la aplicación, y EvoAgent, cliente de la aplicación ubicado en las máquinas cliente. La aplicación cliente no posee interfaz, salvo por el icono en la barra de tareas con el que el usuario de la máquina cliente se podrá informar de la aplicación que se está ejecutando y podrá acceder al servicio de conexión remota. En estos casos se mostrará una pequeña ventana o un menú desde el icono en la barra de tareas. El resto de la funcionalidad de la aplicación cliente no viene precedido de una interfaz de usuario pues no requiere de interacción con el mismo. Se analizará en este caso la interacción que existe entre cliente y servidor mediante los respectivos diagramas de secuencia. El tercero se trata de la creación del elemento Alerta dentro de la aplicación CRM y del funcionamiento de dicha aplicación para poder trabajar con este elemento Subsistema EvoAgentManager e Interacción con el Servidor A continuación se mostrará la funcionalidad de la aplicación de gestión EvoAgentManager, subsistema del presente proyecto, que estará ubicada en los puestos de los técnicos de Evotec. Para ello se mostrará el diseño final de la interfaz de usuario con los diagramas de secuencia de las operaciones que puede realizarse a partir de dicho interfaz. Para la elección del modelo de interfaz definitivo se ha tenido en cuenta a los usuarios finales, es decir, los técnicos de Evotec, de tal forma que se ha seguido el modelo de interfaz que posee la aplicación con la que más se trabaja en dicha empresa y con la que además, el sistema a construir está más ligado, Micorsoft CRM 3.0. Dicho interfaz a su vez esta basado en el estándar adoptado por Microsoft y aplicado en muchas de sus aplicaciones a partir del Microsoft Outlook y que consiste en un menú principal en el ala izquierda de la ventana de la aplicación desde el que poder acceder a toda la funcionalidad de la aplicación y un contenedor donde alojar cada ventana que se abra a modo de escritorio de la aplicación. 61

72 Para construir este modelo de interfaz se ha acudido a componentes para aplicaciones Windows desarrollados y publicados como software libre bajo un proyecto con el nombre de Ascend.net Windows Forms Controls. Como se puede observar en la página web: los controles de Ascend.NET son una colección de controles Windows Forms escritos en lenguaje C# para Visual Studio 2005 y.net 2.0. Se pueden descargar desde el link: Una vez descargado el paquete, es necesario instalarlo y, posteriormente, agregar referencias desde el proyecto de Visual Studio donde se desarrollará la interfaz a las librerías Ascend, Ascend.Resources, Ascend.Design y Ascend.Windows.Forms. Una vez referenciadas, se puede agregar los componentes o controles en la barra de herramientas del Visual Studio. En este caso, se utiliza el control Ascend.Windows.Forms.NavigationPane y los controles NavigationPanePage y NavigationButton para construir el menú de la ventana principal que aparece en la figura

73 Antes de empezar a usar la aplicación se procederá a realizar una validación del usuario que desea utilizarla de la forma que se indica en el diagrama de secuencia de la Figura Validación Usuarios EvoAgentManager. iu. Form_Main EvoAgentLibrary. Services. CredencialesUsuario System. Net. CredentialCache EvoAgentServer. services. UsuariosManager initlogin() VALIDA USUARIO getdefaultnetworkcredential() Cre <<create>> Cre : System. Net. NetworkCredentials authenticate() True [error] getcurrent().name System.Security. Principal. WindowsIdentity <<createcurrent>> WI : System.Security. Principal. WindowsIdentity WI.Name getusuario (NombreInicioSesion) Dao. UsuarioAplicacionDAO <<create>> U:Usuario [error] U True <<forward>> error? False getnombrecompleto() U.NombreCompleto EvoAgentManager. iu. Form_Login Init() Paquete superior::tecnico Evotec <<forward>> set(user, Pw, Domain) IniciarSesion() Figura 6.1 Diagrama de Secuencia. Validación Usuario 63

74 Para realizar la validación se ha escogido utilizar el registro que lleva de usuarios la aplicación Microsoft CRM que guarda los usuarios en su base de datos. Dicha base de datos será replicada en la medida de lo deseado como una tabla de la base de datos de ésta aplicación, de forma que la consulta se deberá realizar a dicha tabla. Primeramente, se realiza una comprobación de que las credenciales de usuario introducidas tienen acceso al servicio web ControlAdmin contenido en el directorio AdminManager del servidor. Como se vio en el apartado 5.1 en la descripción del servidor de la aplicación, dicho directorio tendrá habilitada la autenticación de Windows integrada de forma que el inicio de sesión deberá tener un usuario registrado en el dominio. Por otro lado, con el nombre de inicio de sesión de Windows se obtiene los datos completos del usuario registrado en la base de datos del sistema. Si la autenticación no tuviera éxito se mostrará la ventana que se indica en la Figura 6.1 con el nombre de Form_Login y que se corresponde con la siguiente imagen: Figura 6.2 Diseño de Interfaz. Login Una vez autenticado el usuario se accede a la ventana principal de la aplicación que se observa en la Figura

75 Figura 6.3 Diseño de Interfaz. Ventana Principal, Área de Trabajo (Form_Main) Como se puede observar en la figura desde el menú principal se puede acceder a 3 módulos entre los que se reparte toda la funcionalidad (Parte inferior del menú). Estos módulos son: Área de Trabajo: Permite gestionar la actividad de los agentes y visualizar información sobre los mismos. Settings: Permite gestionar parámetros de configuración de la aplicación. Se manejarán aspectos relevantes de la aplicación como el Control de Alertas, gestión de versiones de la aplicación de las máquinas agente y la gestión de los usuarios de la aplicación. Referencias: Permite ver la descripción de la aplicación y acceder a la aplicación CRM. El módulo principal es el Área de Trabajo. Éste módulo comprende varias funcionalidades resumidas en los siguientes puntos: Tareas: Donde se trabajará con las tareas asignables a las máquinas cliente. Se podrá crear nuevas tareas, editarlas o borrarlas, ver el estado actual de tareas o gestionar las tareas programadas. Maquinas: Donde se podrá ver el detalle de las auditorías así como dar acceso a máquinas cliente al sistema. Clientes/Dominios: Donde se podrá asociar máquinas cliente con los clientes registrados en la aplicación de gestión CRM a través de los dominios. 65

76 Logs: Donde se podrá monitorizar el correcto funcionamiento del sistema Tareas Desde aquí se podrá gestionar las tareas que se registran para las máquinas cliente. Al cargar se obtienen las tareas existentes y los datos que se utilizarán como filtros, esto es, Maquinas, Clientes y Tareas INICIO TAREAS EvoAgentManager. iu. Form_Tareas Dao.ClienteDAO getclientes() Dominio.Cliente <<create>> Cliente[ ] Dao.MaquinaDAO getmaquinas() Dominio.Maquina <<create>> Maquina[ ] gettareas() Dao.TareaDAO <<create>> Tarea[ ] Dao.TareaMaquinaDAO gettareasmaquinabypendiente() TM : Dominio.TareaMaquina <<create>> TareaMaquina[] Figura 6.4 Diagrama de Secuencia. Inicio Tarea Al terminar de cargar se muestra la ventana de la figura 6.5: La parte superior de la ventana incluye un filtro de búsqueda de tareas; al seleccionar un elemento de cualquiera de las categorías se dispara el evento Buscar Tarea de la figura 6.6. Las tareas resultado de la búsqueda se muestran en la lista. Dicha lista se construirá mediante un elemento 66

77 DataGridView que tiene un enlace de datos directo a una tabla de un DataSet y métodos automáticos de ordenación. Por último, el menú de acciones se encuentra entre el filtro y la lista y comprende cada una de las acciones que se explicarán más adelante: Figura 6.5 Diseño de Interfaz. Tareas (Form_Tareas) 67

78 BUSCAR TAREAS EvoAgentManager. iu. Inicio_Tareas <<create>> M : Dominio.Maquina <<create>> C : Dominio.Cliente <<create>> T : Dominio.Tarea Dao.TareaMaquinaDAO gettareasmaquinabyfilters (M, C, T, Estado) Dao.TareaMaquinaDAO gettareasmaquina() TM : Dominio.TareaMaquina <<create>> TM[ ] TareaMaquina[] Figura 6.6 Diagrama de Secuencia. Buscar Tareas ACCIONES: Nueva Tarea: Se abre una nueva ventana donde se gestiona la creación de una nueva tarea. Los botones del menú permiten guardar la tarea o abrir la ventana de parámetros de las tareas que se explican más adelante. 68

79 Figura 6.7 Diseño de Interfaz. Nueva Tarea (Form_NuevaTarea) El usuario debe seleccionar los datos necesarios para configurar la tarea, tal y como se muestra en el diagrama de secuencia de la figura 6.8. Se podrán crear varias tareas para una máquina o para varias máquinas a la vez. Una vez configurado el tipo de Tarea, dependiendo del mismo, se requerirá introducir más información para poder terminar de configurar la tarea. Esto se indica en el diagrama mediante la llamada de Form_NuevaTarea a Form_ParametrosTarea con la condición: [NombreTarea = Auditoria,Servicio,Cuotas], es decir, que si la tarea es una auditoría, un inicio de servicio o una comprobación de cuotas de usuario se requiere configurar parámetros. Al pulsar el botón Guardar se comprueba que se hayan rellenado los campos y se procede a crear las nuevas tareas y registrarlas en la base de datos a través de la capa de datos. Después se cierra la ventana y se actualizan las tareas en la ventana de tareas (Figura 6.5). La ejecución de las tareas y su diseño en los programas agente se puede ver en el apartado Módulo EvoAgentService, en el punto Ejecutar Tarea. A continuación se muestra el diagrama de secuencia de la creación de una nueva tarea: 69

80 NUEVA TAREA EvoAgentManager. iu. Form_Tareas EvoAgentManager. iu. Form_NuevaTarea EvoAgentManager. iu. Form_ParametrosTarea Paquete superior::tecnicoevotec NuevaTarea(Maquina[ ], Cliente[ ], Tarea[ ]) <<forward>> Set(NombreMaquina[],NombreTarea[]) <<forward>> [NombreTarea = Auditoria,Servicio,Cuotas] InicioParametros( ) Set(Selección[]) Set(Fecha,Hora) Save <<ok>> SetParametros() T : Dominio.TareaMaquina <<create>> [idtarea = 1,4,5] GetSelección() sett (Maquina, Tarea, Seleccion, Fecha) Dao. TareaMaquinaDAO CreateTareaMaquina( T ) Actualizar() Figura 6.8 Diagrama de Secuencia. Nueva Tarea Figura 6.9 Diseño de Interfaz. Parámetros de la Tarea (Form_ParametrosTarea) 70

81 Eliminar Tarea: El usuario debe seleccionar una o varias tareas que desea eliminar de forma que se habilite el botón eliminar y entonces pulsando dicho botón el sistema obtendrá el identificador de la tarea/as seleccionada/as y procederá a borrarla/as mediante la capa de datos. Posteriormente se actualiza la lista de tareas mediante el método actualizar que se verá más adelante. ELIMINAR TAREA EvoAgentManager. iu. Form_Tareas Dao.TareaMaquinaDAO Eliminar Tarea(idTarea) <<forward>> Actualizar() Figura 6.10 Diagrama de Secuencia. Eliminar Tarea Pendiente Actualizar Tareas: La finalidad de esta función consiste en obtener el estado modificado automáticamente por los programas agente de las máquinas a través del servidor. Es necesario obtener los datos nuevamente y se deberán mostrar los datos que cumplan con los filtros que estén en ese momento fijados. Por la tanto bastaría con llamar al método de búsqueda de tareas definido anteriormente en la Figura 6.6. ACTUALIZAR EvoAgentManager. iu. Form_Tareas Buscar Tareas() Figura 6.11 Diagrama de Secuencia. Revisar Estado Tarea 71

82 Editar Tarea: Utiliza la misma ventana que el evento Nueva Tarea (Figura 6.7). En este caso el cliente y la máquina, así como el tipo de tarea vienen definidos por la tarea que hay que pasar de entrada, la tarea a editar. Dicha tarea debe estar en estado pendiente para poder editarla. El usuario debe seleccionar una tarea de la lista (Figura 6.5) que desea editar de forma que se habilite el botón editar y pulsando dicho botón el sistema obtendrá la tarea seleccionada y se la pasará a la ventana nueva tarea. Se puede editar los parámetros de la tarea o la fecha de ejecución de la misma. EDITAR TAREA EvoAgentManager. iu. Form_Tareas EditarTareaMaquina (TareaMaquina) EvoAgentManager. iu. Form_NuevaTarea <<create>> T : Dominio. TareaMaquina EvoAgentManager. iu. Form_ParametrosTarea [NombreTarea = Auditoria,Servicio,Cuotas] Inicio(Seleccion) Paquete superior::tecnicoevotec <<forward>> SetParametros() Show() <<forward>> Set(Selección[]) <<ok>> Set(Fecha,Hora) Save sett(seleccion,fecha) [idtarea = 1,4,5] GetSelección() Dao.TareaMaquinaDAO updatetarea( T ) Actualizar() Figura 6.12 Diagrama de Secuencia. Editar Tarea 72

83 Programar Tarea: Para la generación de tareas programadas en el TaskSchduler de Windows del servidor se deben configurar varios aspectos de las mismas. Para ello se creará una ventana desde la que poder acceder a todos estos aspectos. Al pulsar sobre Nueva Tarea Programada se abrirá la siguiente ventana: Figura 6.13 Diseño de Interfaz. Programar Tarea (Form_TareaProgramada) Esta ventana se compone de un menú principal a la izquierda al igual que la ventana principal de la aplicación (Figura 6.5). Las distintas opciones del menú permiten el paso entre las ventanas que contienen los diferentes elementos a configurar, que serán: Tarea: La tarea para las máquinas agente que se desea configurar. Dicha ventana será la misma que la utilizada para crear una nueva tarea (Figura 6.7). Credenciales: Se deberá configurar las credenciales con las que el TaskScheduler ejecutará la tarea. Dichos credenciales deben tener acceso al sistema. 73

84 Figura 6.14 Diseño de Interfaz. Credenciales de la Tarea Programada (Form_CredencialesTareaProgramada) Programación: Se deberá configurar la programación de la tarea conforme a las posibilidades que ofrece la herramienta TaskScheduler de Windows. Se podrán generar programaciones diarias, semanales o mensuales para una tarea, establecer la fecha de inicio, la hora de ejecución, la fecha de fin y algunos atributos relevantes de las tareas programadas: 74

85 Figura 6.15 Diseño de Interfaz. Programación de la Tarea Programada (Form_ProgramacionTarea) Una vez configurados todos los elementos de la tarea programada y pulsando sobre el botón Guardar del menú de la izquierda el sistema inicia el proceso de guardado de la tarea programada. A continuación se muestra el proceso de generación de una tarea programada completo (diagrama de secuencia Programar Tarea, Figura 6.16), incluyendo la configuración de los diversos elementos. El proceso de guardado de la tarea programada comienza al finalizar la interacción con el usuario -momento en el que se pulsa Guardarmediante el método Save() que se observa en el diagrama. 75

86 EvoAgentManager. iu. Form_Tareas EvoAgentManager. iu. Form_TareasProgramadas PROGRAMAR TAREA ProgramarTarea(Cliente[ ], Tarea[ ], Maquina[ ]) EvoAgentManager. iu. Form_NuevaTarea NuevaProgramacion(Cliente[ ], Tarea[ ], Maquina[ ]) EvoAgentManager. iu. Form_Programacion EvoAgentManager. iu. Form_Credenciales Paquete superior::tecnico <<forward>> Set(NombreMaquina[],NombreTarea[]) <<forward>> EvoAgentManager. iu. Form_ParametrosTarea [NombreTarea = Auditoria, Servicio,Cuotas] InicioParametros( ) Set(Selección[]) <<ok>> SetParametros() Set(Programacion, Dias,Meses, DiaSemana, DiaMes, Diario, FechaIni, HoraIni, FechaFin, Flags) Set(NombreUsuario, Password) Save() TPR : Dominio.TareaProgramada getcredenciales() <<create>> Set(User, Password) SetTareas(T[]) gettareas() [idtarea = 1,4,5] GetSelección() TareaMaquina[ ] T : Dominio.TareaMaquina <<create>> sett (Maquina, Tarea, Seleccion) getprogramacion() Tg : Dominio.MiTrigger <<create>> Tg setprogramacion() SetTrigger(Tg) CreateNewTareaProgramada(TPR) Dao.TareaProgramadaDAO (*1) Continúa Figura 6.16 Diagrama de Secuencia. Programar Tarea I 76

87 Como se observa en el diagrama de secuencia de la figura 6.16 tras comenzar el proceso de guardado, el sistema crea una tarea programada (Perteneciente al Modelo de Dominio) y recupera todos los elementos de la configuración de la tarea programada almacenándolos en ésta, léase, el Usuario y Contraseña de la Ventana Credenciales, las Tareas para las máquinas Agente de la Ventana Nueva Tarea y la Programación de la tarea (Trigger = MiTrigger del Modelo de Dominio) de la ventana Programación Tarea. Una vez recuperados los datos de la tarea programada se la pasa a la capa de datos que procede a guardarla tal y como se muestra en la Figura 6.17 : EvoAgentManager. iu. Form_TareasProgramadas Dao.TareaProgramadaDAO PROGRAMAR TAREA (*1) Continuación CreateNewTareaProgramada(TPR) Ta : EvoAgentLibrary. TaskScheduler. Task Tr : EvoAgentLibrary. TaskScheduler. Trigger EvoAgentLibrary. Servicios. InterpreteProgramacionTarea ConvertMiTriggerToTrigger(TPR.Trigger) <<create>> Set( Nombre, WorkingDirectory, Aplicación, Creator, Flags, AccountInformation, Priority) <<create>> Set() Tr SetTrigger( Tr) CreateTask( Ta ) Server.TaskScheduler ConvertTareasMaquinaToXML(TPR.Tareas) DataSet EvoAgentServer. Servicios. ControlAdmin CreateNewTareaProgramada( DataSet, NombreTarea ) Figura 6.17 Diagrama de Secuencia. Programar Tarea II Para guardar la tarea se debe crear tal y como se ha explicado en el apartado 5.1 de este documento, en la descripción de la carpeta AdminManager del Servidor de la aplicación, se debe crear un fichero ejecutable por lotes de comandos de MS2 de nombre igual a la tarea programada. Dicho ejecutable, objetivo de la Task de Windows, contiene un comando con el nombre de la aplicación que se encarga de registrar la tarea en el servidor seguido del atributo que es el nombre de la tarea programada. La aplicación en cuestión lee las tareas a registrar accediendo al segundo fichero a crear, un fichero de texto plano XML- con ese mismo nombre que obtiene en el argumento. 77

88 Como se ha explicado en el apartado 5.1 estos dos ficheros residirán en el espacio de direcciones del servidor, en la carpeta ProgramacionTareas junto a la aplicación comentada (ProgramacionTareas.exe), por lo que es necesario que el sistema envíe la información necesaria para que el servidor de la aplicación genere dichos documentos en su espacio de direcciones. Para ello se sirve de una clase auxiliar de la librería, Intérprete, que traduce la información de las tareas para las máquina agente en un documento XML contenido en un DataSet. Por otro lado, anteriormente, se registra la Task de Windows en el TaskScheduler del servidor. Para ello, el sistema crea una Task, y la rellena toda la información de ejecución: Credenciales, Aplicación a ejecutar, Flags, Nombre y Trigger que debe crearse acudiendo de nuevo al Intérprete a partire de la clase MiTrigger. Por último registra la Task en el TaskSheduler. Ver Tareas Programadas: Para ver las tareas programdas que se han creado se debe pulsar el botón Ver Tareas Programadas. Se mostrará en la lista de la siguiente ventana la información de las tareas. Figura 6.18 Diseño de Interfaz. Ver Tareas Programadas El proceso de recuperación de las tareas es contrario al de creación de una tarea programada y se muestra en el diagrama de secuencia de la Figura Se obtiene una lista de tareas del Task Scheduler. Para cada Task se crea una clase Tarea Programada del dominio y se rellena con la información: se obtiene la programación de la Task, almacenada en un campo descriptivo para poder interpretarla, y se recurre de nuevo al Intérprete de la librería de la aplicación para obtener la clase MiTrigger que contiene dicha programación. Se obtiene las tareas para las máquinas agente a través del servidor y de nuevo, del intérprete. Una vez se tiene las Tareas Programadas se pasan a la ventana Ver Tareas Programadas. 78

89 EvoAgentManager. iu. Form_Tareas EvoAgentManager. iu. VerTareasProgramadas VER TAREAS PROGRAMADAS Server. TaskScheduler MostrarTareasProgramadas() Dao. TareasProgramadasDAO gettarprogramadas() gettasknames() LT: EvoAgentLibrary. TaskScheduler. TasksList <<create>> opentask(nombre) Tpr : EvoAgentLibrary. TaskScheduler. Task <<create>> TPR : Dominio.TareaProgramada <<create>> Set( Nombre, Aplicación, Creator, User, ProxEjecucion, UltimaEjecucion) Tpr EvoAgentLibrary. Servicios. InterpreteProgramacionTarea ConvertCommentToMiTrigger(Tpr.Comment) EvoAgentServer. Servicios. AdminManager Tg <<create>> Tg : Dominio.MiTrigger Set() SetMiTrigger (Tg) getpropiedadestareaprogramada(nombretarea) DataSet ConvertXmlToTareasMaquina(DataSet) TareaMaquina[ ] <<create>> Tm : Dominio. TareaMaquina Set() SetTareas (Tm[ ]) TareaProgramada[ ] Figura 6.19 Diagrama de Secuencia. Ver Tareas Programadas 79

90 La ventana Ver Tareas Programadas (Figura 6.18) posee un menú encima de la lista de tareas a través del cual se puede: Abrir Propiedades Tarea Programada: Mediante el cual se puede modificar la tarea Programada. Se abriría la ventana vista en la Figura 6.13 con la información de la tarea actual. Tras configurar de nuevo la tarea programada y pulsar Guardar se borrará la tarea programada existente con el método de la Figura 6.20 y se procederá a crear una nueva. Eliminar Tarea Programada: Tras seleccionar la tarea desde Ver Tareas Programadas (Figura 6.18) y pulsando el botón eliminar se iniciaría el siguiente proceso que borraría por completo la tarea programada del sistema. ELIMINAR TAREA PROGRAMADA EvoAgentManager. iu. VerTareasProgramadas Dao.TareaProgramadaDAO deletetareaprogramada(nombre) Server.TaskScheduler EvoAgentServer. services. ControlAdmin deletetask(nombre) <<forward>> deletetaskproperties(nombre) Figura 6.20 Diagrama de Secuencia. Eliminar Tarea Programada Registro de Tareas de una Tarea Programada. Paquete Programación Tareas de EvoAgentServer El objetivo de la tarea programada es registrar tareas para máquinas cliente de forma automática. Para ello se explicará aquí el funcionamiento del programa ProgramacionTareas.exe Dicho programa obtiene como argumento el nombre del fichero que contiene las tareas que debe registrar en el servidor y que reside en su mismo directorio. Este mismo programa, dependiendo del argumento, le pedirá al servidor que registre alertas en caso de que una máquina agente lleve tiempo sin comunicarse. 80

91 INICIO Argumentos Leer Argumento De Entrada Argumento Argumento = crear Tarea SI Leer Máquinas y Tareas Nombre fichero Abrir Fichero de Tarea XML Tarea NO Comprobación Comunicaciones Leer Tareas Obener Programacion Tarea Calcular Próxima Ejecución Registrar TareaMaquina FIN Figura 6.21 Diagrama de Flujo. Registrar TareaMaquina de Tarea Programada Acciones: Se obtiene el argumento de entrada y dependiendo de su contenido se procede a crear tareas o a comprobar la comunicación de los agentes: 1. Comprobar Comunicaciones: Se procede según el siguiente diagrama de secuencia: 81

92 COMPROBACION COMUNICACIONES ProgramacionTareas.exe ControlComunicacion() EvoAgentLibrary. Dao. ControlComunicacionesDAO getrutaservidor() URL EvoAgentServer. Servicios. ControlAgente get(currentdomain. BaseDiretory) URL System. AppDomain Dao.MaquinasDAO getmaquinas() <<create>> M : Dominio. Maquina M[ ] NewAlerta(Tipo., Maquina, Parametro, rutaservidor) <<forward>> Dao.AlertaDAO registroalerta <<forward>> Figura 6.22 Diagrama de Secuencia. Comprobar Comunicaciones de los Agentes La clase AlertaDAO mediante su método estático NewAlerta se encargará de generar las alertas y registrarlas en la aplicación CRM. Esto se muestra en el apartado Acceso al servicio CRMService para registrar nuevas alertas. 2. Crear Tareas: Abrir Fichero de Tarea. Mediante un stream lector de xml se abre el fichero que contiene la información de las tareas para las máquinas. Leer Tareas: Se obtienen las tareas leyendo el fichero xml. Obtener Programación Tarea: Una vez se ha obtenido las tareas faltaría obtener la fecha de ejecución de las tareas en las máquinas. Dicha fecha depende de la programación que se escogió para la tarea programada, por lo que se hará necesario obtener la programación de dicha tarea que viene en el archivo xml. 82

93 Calcular Próxima Ejecución: Depende de la programación que se escogió para la tarea programada. La fecha de ejecución de las tareas en las máquinas cliente será la fecha que corresponda a la próxima ejecución según la programación de la tarea. Así, a cada ejecución de la Task se creará las tareas para la siguiente ejecución. Esto hará que la primera ejecución no tenga efectos hasta la siguiente. Registrar TareaMaquina: Una vez se conoce la fecha de ejecución y las tareas a ejecutar se puede proceder a registrar las tareas: CREAR TAREAS ProgramacionTareas.exe <<create>> T : Dominio.TareaMaquina EvoAgentServer. dao. TareasMaquinaDAO sett(maquina, Tarea, Fecha) createnuevatarea(t) Figura 6.23 Diagrama de Secuencia. Registrar TareaMaquina Maquinas En este apartado se pretende configurar varios aspectos de los programas agentes (maquinas). Por otro lado se realizará la presentación del resultado de las auditorías realizadas en las máquinas. Se accede a la ventana de máquinas desde la ventana principal. Al cargarse se sigue el proceso indicado por el siguiente diagrama de secuencia: 83

94 INICIO MAQUINAS EvoAgentManager. iu. Form_Maquinas Dao. ClientesDAO getclientes() <<create>> C:Cliente Cliente[ ] Dao. MaquinaDAO getmaquinas() <<create>> M:Maquina Maquina[ ] Figura 6.24 Diagrama de Secuencia. Inicio Máquinas Tras el proceso se mostrará la siguiente ventana: Figura 6.25 Diseño de Interfaz. Máquinas (Form_Maquina) Esta ventana tiene los siguientes procesos asociados: 84

95 Buscar Máquina: Pertenece al cuadro superior de la ventana que actúa como filtro de máquinas a mostrar. Cuando se seleccione un cliente o bien se introduzca el nombre de una máquina o parte de el y se pulse sobre el botón de búsqueda se procederá a cargar las máquinas en la lista. Para ello se recurrirá a la capa de datos como se indica en el diagrama de secuencia: BUSCAR MAQUINAS EvoAgentManager. iu. Form_Maquinas Dao. MaquinaDAO MostrarMaquinas(NombreCliente) MostrarMaquina(nombreMaquina) Maquina[] Figura 6.26 Diagrama de Secuencia. Buscar Máquinas Modificar las propiedades de un programa agente: Como se observa en la figura 6.25 se han definido tres propiedades modificables correspondientes a 3 columnas de la tabla: Permiso: Indica cuando una máquina va a poder comunicarse con el sistema. Por defecto, al darse de alta una máquina, no tendrá permiso para comunicarse. Tipo de Agente: Indica si un programa agente está instalado en una máquina servidor o en una máquina pc. En función del tipo de máquina en que esté instalado, un agente realizará diferentes acciones. Auto-desfragmentación (Auto-Dfrag): Esta propiedad indica, cuando está activada, que el agente lanzará un proceso del sistema operativo de desfragmentación de las unidades de disco. Dicho proceso procede a desfragmentar las unidades cuando sea necesario. Un agente o máquina queda configurado según estos parámetros cuando se pulsa el botón guardar de la columna de la derecha. En ese momento se procede a guardar la configuración mediante la capa de datos tal y como se indica en el diagrama de secuencia: 85

96 MODIFICAR ATRIBUTOS DE MAQUINAS EvoAgentManager. iu. Form_Maquinas Dao. MaquinaDAO GuardarParametros(permiso, tipoagente, desfragmentar, idmaquina) M: Dominio.Maquina <<create>> <<forward>> setm(permiso,tipo,dfrag) Figura 6.27 Diagrama de Secuencia. Modificar los atributos de un programa agente Ver Detalle de Máquina: Debe de seleccionarse una máquina de la lista de la ventana maquina y pulsar el botón Ver Detalle Maquina. El resultado del proceso de lectura del detalle de una máquina se muestra en una ventana que contiene todos los campos reflejados en la documentación presentada en el Anexo 3 Documentación sobre las características del inventario de WinAudit (En Inglés). Para ello se ha diseñado una ventana con un menú en la izquierda mediante el cual se vaya modificando el campo a mostrar, dicha ventana se muestra en la Figura

97 Figura 6.28 Diseño de Interfaz. Detalle de Auditoria de Maquina (DetalleMaquina) Antes de mostrar el proceso que se sigue para generar el detalle de una máquina se ha de entender que la información procede de los ficheros xml que genera la aplicación WinAudit. Es, por tanto, necesario la generación de un método uniforme de lectura de dichos datos y la generación de clases dentro del dominio para definir cada uno de los apartados. La lectura del fichero xml se puede hacer una única vez mediante el uso de variables de estado para indicar el lugar del documento en que se encuentra el lector. Dicho lector es un XmlTextReader. Así, con las clases diseñadas y siguiendo el orden de categorías que se observa en los ficheros xml generados y que es el mismo que el mostrado en el menú de la Figura 6.28 el proceso de lectura sería el que se muestra a continuación: 87

98 EvoAgentLibrary. Services. LeerAuditoriaXML LeerAuditoria LeerAuditoria(Auditoria, urlworkingdirectory) <<create>> Set() VG : Dominio.WinAudit. VistaGeneral <<create>> Set() <<create>> Set() Act : Dominio.WinAudit. Maquina_Actualizacion <<create>> Set() <<create>> Set() P : Dominio.WinAudit. Maquina_Programa SO : Dominio.WinAudit. Maquina_SSOO Pf : Dominio.WinAudit. Maquina_Periferico <<create>> Set() PuA : Dominio.WinAudit. Maquina_PuertoAbierto <<create>> (*1) Continúa Set() <<create>> Set() SS : Dominio.WinAudit. Maquina_SettingSeguridad <<create>> Set() <<create>> Set() PrivilegiosUsuario : String WFS : Dominio.WinAudit. Maquina_WindowsFirewallSeting TP : Dominio.WinAudit. Maquina_TareaProgramada Figura 6.29 Diagrama de Secuencia. Leer Auditoria 1 El documento xml reside en el servidor y debe ser descargado mediante la clase DataSet. Así, el argumento Auditoría que recibe el método es un dataset que contiene el Xml. Un DataSet tiene un método que permite escribir el contenido como xml, así, se podría crear un fichero xml a leer por el XmlTextReader. El otro parámetro urlworkingdirectory le indica al método donde escribir y leer dicho fichero. A partir de ahí, se debe realizar la lectura de cada uno de los campos rellenando como se ve en la Figura 6.29 y siguientes: 88

99 EvoAgentLibrary. Services. LeerAuditoriaXML LeerAuditoria (*1) Continuación <<create>> EA : Dominio.WinAudit. Maquina_EstadisticasArranque Set() <<create>> Set() <<create>> Set() Err : Dominio.WinAudit. Maquina_ErrorLog <<create>> Set() <<create>> Set() NF : Dominio.WinAudit. Maquina_NetworkFile NSe : Dominio.WinAudit. Maquina_NetworkSession NSh : Dominio.WinAudit. Maquina_NetworkShare NTCP : Dominio.WinAudit. <<create>> Maquina_NetworkTCPIPControler Set() <<create>> (*2) Continúa Set() <<create>> NBA : Dominio.WinAudit. Maquina_NetBIOSAdapter Set() <<create>> Set() <<create>> Set() Dis : Dominio.WinAudit. Maquina_Dispositivo CP : Dominio.WinAudit. Maquina_CaractristicaPantalla I : Dominio.WinAudit. Maquina_Impresora Figura 6.30 Diagrama de Secuencia. Leer Auditoria 2 Para devolver todos los campos se creará una clase que los contenga a todos con el nombre de CamposAuditoria. Cuando se termine de leer los campos, se rellenará dicha clase y se devolverá al solicitante de la lectura como se ve en la Figura

100 EvoAgentLibrary. Services. LeerAuditoriaXML LeerAuditoria (*2) Continuación <<create>> PtC : Dominio.WinAudit. Maquina_PortConnector Set() <<create>> Set() <<create>> Set() SysSt : Dominio.WinAudit. Maquina_SystemSlot <<create>> Set() <<create>> Set() Pr : Dominio.WinAudit. Maquina_Procesador Memo : Dominio.WinAudit. Maquina_Memoria Df : Dominio.WinAudit. Maquina_DiscoFisico Dl : Dominio.WinAudit. <<create>> Maquina_DiscoLogico Set() <<create>> Set() <<create>> PA : Dominio.WinAudit. Maquina_ProgramaArranque Set() <<create>> Set() <<create>> Servicio : Dominio.WinAudit. Maquina_Servicio Set() Driver : Dominio.WinAudit. Maquina_Servicio PE : Dominio.WinAudit. Maquina_ProgramaEjec Mod : Dominio.WinAudit. <<create>> Maquina_Modulo Set() <<create>> CA : Dominio.WinAudit. CamposAuditoria Set(VG, Act[ ], P[ ], SO, Pf[ ], PuA[ ], SS[ ]) Set(PrivilegiosUsuario[ ], WFS[ ], TP[ ], EA[ ]) Set(Err[ ], NF[ ], NSe[ ], NSh[ ], NTCP[ ], NBA[ ]) Set(Dis[ ], CP[ ], I[ ], PtC[ ], SysSt[ ], Pr[ ], Memo) CA Set(Df[ ], Dl[ ], PA[ ], Servicio[ ], Driver[ ], PE[ ], Mod[ ]) Figura 6.31 Diagrama de Secuencia. Leer Auditoria 3 90

101 La tarea auditoría de una máquina debería ejecutarse diariamente con los campos necesarios para generar alertas, y se puede diseñar para que la auditoria de un día elimine la del día anterior siempre que tenga los mismos campos auditados y así no se produzca acumulación de auditorias. No obstante, se podrá llegar a tener registradas varias auditorias de una misma máquina por lo que es necesario leer los campos coincidentes de la más reciente con lo que será necesario gestionar la lectura de auditorias y los campos final que se presentan. El método anteriormente mostrado únicamente se encarga de convertir un DataSet que contiene un documento xml en una clase colección de todos los campos pertenecientes a una auditoria de WinAudit. Por lo que se requerirá un método que gestione lo expuesto en el párrafo anterior. Por otro lado, es necesario descargarse la información sobre las auditorías mediante la capa de datos y los propios documentos xml a través del servicio web del servidor. Así, el proceso a seguir para mostrar el detalle de una máquina se muestra en el siguiente diagrama de secuencia: 91

102 EvoAgentManager. iu. Form_Maquinas EvoAgentManager. iu. DetalleMaquina Dao. DetalleAuditoriaDAO VER DETALLE MAQUINA VerDetalleMaquina(idmaquina) getauditorias(idmaquina) <<create>> DA:DetalleAuditoria DetalleAuditoria[ ] getauditoriasxml(da[ ].idauditoria) EvoAgentServer. Servicios. ControlAdmin getauditoriasxml(idauditorias[ ]) Ds: System.Data.DataSet <<create>> readxml(ruta+idauditoria) DataSet[ ] DataSet[ ] EvoAgentLibrary. Services. LeerAuditoriaXML EvoAgentLibrary. Services. LeerAuditoriaXML gestionauditoriadetallemaquina (DA[ ], D[ ], urlworkingdirectory) <<create>> CAdef : Dominio.WinAudit. CamposAuditoria LeerAuditoria(Auditoria, urlworkingdirectory) CamposAuditoria LeerAuditoria set(camposseleccionados) CAdef, camposselec[ ] Figura 6.32 Diagrama de Secuencia. Ver Detalle Máquina 92

103 Clientes\Dominios Es el módulo pensado para la gestión de dominios bajo los que se identificarán las máquinas con los clientes. Dicha asociación se hace necesaria si se desean registrar alertas en la aplicación CRM y asociarlas a un cliente registrado. Al iniciar se carga el módulo con los datos necesarios siguiendo el siguiente proceso: INICIO CLIENTES EvoAgentManager. iu. Form_Clientes Dao. ClientesDAO getclientes() C : Dominio.Cliente <<create>> Cliente[ ] Dao. DominioDAO getdominios() D : Dominio.Dominio <<create>> Dominio[ ] Dao. MaquinaDAO getmaquinas() M : Dominio.Maquina <<create>> Maquina[ ] Figura 6.33 Diagrama de Secuencia. Inicio Clientes Tras cargar los datos necesarios se mostrará la siguiente ventana desde la que se puede acceder a las diferentes funciones del módulo. 93

104 CREAR NUEVO DOMINIO ELIMINAR DOMINIO Y ASOCIACIONES ASOCIAR CLIENTE Y DOMINIO AÑADIR/BORRAR CLIENTES ASOCIAR/BORRAR MAQUINAS A CLIENTE Y DOMINIO Figura 6.34 Diseño de Interfaz. Inicio Clientes (Form_Clientes) Crear Nuevo Dominio: CREAR NUEVO DOMINIO EvoAgentManager. iu. Form_Clientes createdominio(nombre) <<forward>> EvoAgentServer. dao. DominioDAO <<create>> setd(id,nombre) D:Dominio.Dominio Figura 6.35 Diagrama de Secuencia. Crear Nuevo Dominio 94

105 La instalación de un agente en una máquina lleva asociada una comunicación con el servidor tal y como se verá más adelante. En dicha comunicación se pretende enviar información de la máquina al servidor para que éste la registre en el sistema. En dicha información estará incluido el dominio al que pertenece la máquina. Así, al recibir el dominio, si éste no está registrado se creará uno nuevo. No obstante, con el proceso mostrado en el diagrama de secuencia de la Figura 6.35 se podrán registrar dominios introduciendo el nombre del mismo. Actualizar Clientes: Como se ha explicado anteriormente, el cliente asociado a una máquina tiene una función específica que es la de servir de referencia a la hora de generar alertas en la aplicación CRM. Por tanto, la gestión de clientes registrados en el sistema se llevará a cabo mediante el uso de los clientes registrados en dicha aplicación. Se podrá copiar clientes del CRM o borrar clientes registrados. AGREGAR CLIENTES EvoAgentManager. iu. Form_Clientes Dao.ClientesDAO getclientescrm() Dao. CRMDAO CRMCli : Cliente <<create>> CRMCli[ ] getclientes() Cli:Cliente <<create>> Cli[ ] MostrarClientes((CrmCli[] - Cli[]).nombreCli) nombre[ ] EvoAgentManager. iu. Form_SelectElementos Paquete superior::tecnico <<forward>> Select+OK createnewclientes(cliente[ ]) Actualizar() Figura 6.36 Diagrama de Secuencia. Agregar Clientes 95

106 Para agregar clientes se mostrarán, por tanto, los clientes que están registrados en el CRM y no lo están en el sistema y se permitirá al usuario seleccionar los que se desean agregar. Para ello se mostrará una ventana simple como la siguiente: Figura 6.37 Diseño de Interfaz. Seleccionar (Form_SelectElementos) Al eliminar un cliente del sistema hay que tener en cuenta las máquinas y los dominios asociados: 96

107 EvoAgentManager. iu. Form_Clientes Dao.ClientesDAO ELIMINAR CLIENTES getclientes() <<create>> Cli:Cliente Cli[ ] EvoAgentManager. iu. Form_SelectElementos MostrarClientes(Cli[]) nombre[ ] Paquete superior::tecnico <<forward>> Select+OK deleteclientes(idcliente[]) <<forward>> Dao.DominioDAO updatedominio(iddominio[ ], idcli=null) D:Dominio.Cliente <<create>> Actualizar() updatemaquina (idmaquina[ ], idcli=null,srazon = null) Actualizar() Set(idCli = null, srazon = null) Dao.MaquinaDAO M:Dominio.Maquina <<create>> Set(idCli = null, srazon = null) Figura 6.38 Diagrama de Secuencia. Eliminar Clientes Asociar Dominio con Cliente: Se trata de rellenar la propiedad cliente del dominio. Se deberá indicar el cliente y el dominio en la parte superior izquierda de la ventana de la Figura

108 ASOCIAR DOMINIO CON CLIENTE EvoAgentManager. iu. Inicio_Clientes EvoAgentServer. dao. DominioDAO EvoAgentServer. dao. ClienteDAO updatedominio(idcliente, iddominio) getcliente(idcli) <<create>> C:Cliente C <<create>> D:Dominio.Dominio Actualizar() setcliente(c) Figura 6.39 Diagrama de Secuencia. Asociar Dominio con Cliente Asociar Máquinas a Dominio y Cliente: ASOCIAR MAQUINAS A DOMINIO Y CLIENTE EvoAgentManager. iu. Inicio_Clientes EvoAgentManager. iu. Form_SelectElementos MostrarMaquinas[Nombres] nombres[] Paquete superior::tecnico <<forward>> Select+OK Dao.MaquinaDAO updatemaquina(dominio, idmaquina[]) <<create>> M:Maquina Actualizar() setm(d.iddom,d.nombred, D.idCli,D.nombreC) Figura 6.40 Diagrama de Secuencia. Asociar Maquinas a Dominio y Cliente 98

109 Los dominios existentes en el sistema con sus clientes asociados se mostrarán en el cuadro superior derecho de la Figura Para agregar máquinas a un dominio se deberá seleccionar un dominio y pulsar sobre asociar máquinas y Agregar. En el proceso será necesario seleccionar las máquinas que se desean asociar para lo cual se utilizará de nuevo la ventana de la Figura Para borrar máquinas se procederá de la misma manera pulsando, esta vez, sobre asociar y borrar. BORRAR MAQUINAS DE DOMINIO Y CLIENTE EvoAgentManager. iu. Form_Clientes EvoAgentManager. iu. Form_SelectElementos MostrarMaquinas[Nombres] nombres[] Paquete superior::tecnico <<forward>> Select+OK Dao. MaquinaDAO UpdateMaquina(idMaquina[ ], null, null, null, null) <<create>> M:Maquina Actualizar() setm(idcli = null, srazon = null iddom = null, NombreDom= null) Figura 6.41 Diagrama de Secuencia. Borrar Máquinas de Dominio y Cliente Eliminar Dominio y Asociaciones: 99

110 ELIMINAR DOMINIO Y ASOCIACIONES EvoAgentManager. iu. Inicio_Clientes Dao. DominioDAO Dao. MaquinaDAO deletedominio(iddom) <<destroy>> D:Dominio updatemaquinas(idmaquina[],null,null,null,null) <<create>> M:Maquina setm(idcli = null, srazon = null iddom = null, NombreDom= null) Figura 6.42 Diagrama de Secuencia. Eliminar Dominio y Asociaciones Logs Este apartado esta pensado para la gestión de errores en el funcionamiento de la aplicación y para el control de las actividades de las máquinas agente. Los errores pueden haber sido generados por las máquinas cliente, por el servidor o por la interfaz registrándose en la base de datos del servidor. Un error pertenece a una clase definida en el Framework de.net denominada Exception. Dicha clase posee una descripción del error que incluye el origen en el código del error. La descripción de un error suele ser una cadena de texto bastante extensa con lo que se ha diseñado un mecanismo mediante el cual las descripciones se guardarán mediante archivos de texto (.txt) en una carpeta en el servidor carpeta incidencias -, con un nombre que equivale al identificador con el que se almacenará en la base de datos. En la base de datos se almacenará también el origen y la fecha del error. La siguiente ventana mostrará los errores registrados: 100

111 Figura 6.43 Diseño de Interfaz. Errores (Form_Log) En la Figura 6.43 se observa que la ventana tendrá dos pestañas en la parte superior para poder cambiar entre acciones y Errores. La figura muestra la pestaña Errores. Se observa un filtro de búsqueda de errores en la parte superior. En el despegable Origen se mostrará cliente o servidor y se referirán a los errores generados en los agentes o en el servidor e interfaz respectivamente. Seleccionando cliente se podrá escoger los errores de un cliente específico o de una máquina específica. Al mostrar los errores se seguirá el siguiente proceso, mediante el cual se obtiene la información del error registrada en la base de datos: VER ERRORES EvoAgentManager. iu. Form_Log Dao. ErroresDAO geterrores(origen, Fechas) E : Dominio. ErrorAplicacion <<create>> ErrorAplicacion[ ] Figura 6.44 Diagrama de Secuencia. Ver Errores 101

112 Una vez se muestren los errores se podrá acceder a la descripción pulsando sobre el botón Ver Descripción que aparecerá sobre la misma línea del error. Se lanza un proceso que descargará el archivo de texto des servidor mediante el servicio web de administación: VER DESCRIPCIÓN ERROR EvoAgentManager. iu. Form_Log Dao. ErroresDAO EvoAgentService. services. ControlAdmin getdescripcionerror(error) getdescripcionerror(id, Tipo) String desc <<create>> Show(desc, tirulo, botones, icono) String desc System.Windows.Forms. MessageBox Figura 6.45 Diagrama de Secuencia. Ver Descripción Error Para mostrar la descripción se usará una clase del Framework de.net denominada MessageBox que, pasándole los parámetros que se observan en el diagrama de secuencia de la Figura 6.45, muestra la siguiente ventana: Figura 6.46 Diseño de Interfaz. Mensajes (MessageBox) Borrar Errores: Se podrá borrar un error específico pulsando sobre el botón borrar que aparece al final de la misma línea que la información del error. También se pueden borrar todos los errores que aparecen en la lista de errores. Se seguirá el siguiente proceso: 102

113 BORRAR ERROR EvoAgentManager. iu. Form_Log Dao. ErroresDAO EvoAgentService. services. ControlAdmin deleteerror(error) deleteerror(id, Tipo) <<delete(id)>> err : Dominio.ErrorAplicacion Figura 6.47 Diagrama de Secuencia. Borrar Error Registro Error: En cualquier acción del sistema puede ocurrir situaciones inesperadas que impidan la correcta conclusión de la acción en cuyo caso se generaría un error en forma de la clase Excepción anteriormente comentada. El sistema ha sido diseñado para poder tratar dichos errores en las acciones que poseen riesgo potencial de que ocurra, por ejemplo, en el sistema de comunicaciones entre el sistema y sistemas externos o entre el subsistema Servidor y el subsistema Cliente. En el tratamiento se construirá la clase a incluir en el dominio denominada ErrorAplicación y se procederá a registrarla en el sistema mediante la capa de datos. Aquí se muestra el proceso que se seguiría a partir de la capa de datos tras recibir el Error: REGISTRO ERROR Dao. ErrorAplicacionDAO [rutaservidor = null] createerror(err) [rutaservidor!= null] <<create>> SetNombre(rutaServidor + err.id) WriteLine(err.Descripcion) <<forward>> EvoAgentService. services. ControlAdmin System. IO. File get(currentdomain. BaseDiretory) URL System. AppDomain registroerror(error, rutaservidor) <<forward>> Dao. ErrorAplicacionDAO registroerror Figura 6.48 Diagrama de Secuencia. Registro Error 103

114 Hasta aquí se ha mostrado el funcionamiento de la gestión de Errores. En este apartado también se gestiona las acciones de las máquinas clientes o agentes. Las acciones son generadas por los agentes en su proceso normal y enviadas al servidor para que las almacene en la base de datos como se verá en el apartado La ventana de la Figura 6.43 posee dos pestañas, de las cuales se muestra la correspondiente a los Errores. A continuación se muestra la correspondiente a las acciones: Figura 6.49 Diseño de Interfaz. Acciones de los Agentes (Form_Log) Como se ve la ventana también tiene una caja en la parte superior mediante la que realizar un filtro de búsqueda. En este caso, a diferencia de los errores, sólo se originan acciones en los clientes. Al seleccionar una máquina se podrá ver las acciones realizadas por la misma en la fecha marcada. Se puede seleccionar ver las acciones registradas para una máquina en todos los días. Se podrá borrar un log de un día de una máquina o borrar el log a partir de una fecha. Los procesos seguidos son los típicos ya vistos de acceso a los datos mediante la capa de datos, para obtener Acciones o borrarlas. 104

115 Módulo Settings Es el módulo pensado para la gestión de parámetros de funcionamiento de la aplicación. Los parámetros se almacenarán en la base de datos. Como se ve en la ventana principal de la aplicación, Figura 6.3, para acceder al módulo de settings se deberá hacer desde la parte inferior del menú de la izquierda. En la parte superior se mostrarán las posibles opciones: Figura 6.50 Diseño de Interfaz. Settings (Form_Main) Gestión de Alertas: En este apartado se pretende presentar todos los parámetros relacionados con la generación de alertas. En concreto, se hace referencia al usuario del dominio que se presentará en la aplicación CRM como propietario de las alertas que se generen (se puede modificar en la misma aplicación para cada alerta). Por otro lado, se establecen los filtros necesarios para controlar la generación de alertas en sus diferentes tipos. Los tipos de alertas ya se han podido ver a lo largo del presente documento, en especial en el apartado 4.1 Modelo de Dominio, y son los generados por estados en los discos lógicos de una máquina agente, en la memoria, en el conjunto del software instalado, en los errores registrados en el log de Windows, en los servicios de Windows, en el tamaño de las cuotas de los usuarios de un dominio, en la ejecución de tareas programadas, en las backup locales o en los usuarios registrados en un dominio. Las cuatro últimas son específicas de un agente servidor de dominio. El resto se aplica a los dos tipos de agentes, pc y servidor. Para cada posible elemento generador de alerta existirá un filtro exclusivo. En la siguiente ventana se aprecian los posibles filtros: 105

116 Figura 6.51 Diseño de Interfaz. Gestión de Alertas (Form_GestionDeAlertas) En el conjunto Filtro de generación de alertas de la ventana superior en primer lugar se aprecia los elementos Disco, Memoria y Cuota de Usuario. En estos casos, se configurará los filtros como un valor máximo o mínimo según corresponda a partir del cual se generaría una alerta. Además dicho valor residirá en la tabla de Settings de la base de datos. Por tanto, para modificar el valor de los elementos, al pulsar el botón Aplicar, se procederá según el siguiente diagrama de secuencia: GUARDAR VALOR SETTING EvoAgentManager. iu. Form_GestionAlertas/ Form_GestionVersiones updatesetting(valor, idsetting) Dao. SettingsDAO <<create>> AS:Dominio.ApplicationSetting Set(valor) 106

117 Figura 6.52 Diagrama de Secuencia. Guardar Valor Setting Además, para cargar los valores al inicio se procede de manera similar: CARGAR SETTINGS EvoAgentManager. iu. Form_GestionAlertas/ Form_GestionVersiones getsettings() Dao. SettingsDAO <<create>> AS:Dominio.ApplicationSetting ApplicationSetting[ ] Figura 6.53 Diagrama de Secuencia. Cargar Settings La tabla Elementos generadores de la Figura 6.51 se configuraría para los elementos Programas, Errores del Log y Servicios. Para acceder a estos elementos la capa de datos recurrirá a la tabla Elementos Generadores. Cada uno de ellos tendrá un filtro configurable para cada tipo de Agente. Al lado derecho de cada casilla de activación del filtro (Columnas PC y Servidor), se podrá pulsar un botón Filtro que abrirá una ventana para configurar el filtro. Filtro de Programas: El filtro de programas es el más simple. Se agregará una cadena de texto que pueda ser localizada en el nombre de los programas. Los programas para los que haya alguna coincidencia no producirán alerta al detectar una instalación o desinstalación. Figura 6.54 Diseño de Interfaz. Configuración Filtro de Programas (Form_FiltroAlerta) 107

118 Filtro de Servicios: Los servicios de Windows instalados en las máquinas agente generarán alerta si son automáticos y no están iniciados. Para que no siempre sea así y se pueda controlar el volumen de generación de alerta, todo servicio que vaya a generar alerta se registrará en el sistema para poder asignarle un filtro a partir de la siguiente ventana: Figura 6.55 Diseño de Interfaz. Configuración Filtro de Servicios (Form_FiltroAlerta) Aparecerán los servicios registrados en el sistema y se podrá desactivar la generación de alertas por parte de dicho servicio. La ventana vista será la misma para agentes pc y para agentes servidor y cada cual guardará su configuración. Filtro de Errores: Los errores de Windows que aparecen en el visor de eventos son recogidos por los agentes y enviados junto con la auditoría. Dichos errores son registrados en el sistema al igual que pasa con los servicios. En este apartado se pueden ver los errores que han sido registrados y activar o desactivar la generación de alertas para cada uno y por tipo de Agente. Los errores vienen identificados por un número de instancia que corresponde al código que deja la aplicación que genera el evento. Así se puede reconocer unívocamente un error y descartarlo para un futuro como generador de alerta. En la siguiente imagen se puede ver el formato de la ventana de filtro de Errores: 108

119 Figura 6.56 Diseño de Interfaz. Configuración Filtro de Errores (Form_FiltroAlerta) Gestión de Usuarios: Se han establecido dos tipos de Usuarios. Usuario Administrador y Usuario Técnico. Los Usuarios Administrados tendrán acceso a toda la aplicación mientras que los técnicos no podrán acceder a este apartado ni al apartado Gestión de Versiones. Si se tiene permiso para acceder se mostrará la siguiente ventana: 109

120 Figura 6.57 Diseño de Interfaz. Gestión de Usuarios (Form_GestionUsuarios) Para cargar la ventana anterior se sigue el siguiente proceso mediante el cual se valida el usuario utilizando la clase que se creó al iniciar la aplicación con las credenciales del usuario y, si pertenece al grupo de administradores, se cargan los usuarios registrados en el sistema: CARGAR GESTION USUARIO EvoAgentManager. iu. Form_GestionUsuarios Dao. UsuarioAplicacionDAO EvoAgentLibrary. CredencialesUsuario compruebausuarioadmin() get(current.user) String User Dao. UsuarioAplicacionDAO gettipousuario(user) U:Dominio.UsuarioAplicacion <<create>> TipoUsuario bool getusuarios() <<create>> U:Dominio.UsuarioAplicacion Usuarios[ ] Figura 6.58 Diagrama de Secuencia. Cargar Gestión de Usuarios 110

121 En este apartado se puede configurar el grupo al que pertenece el usuario, así como agregar o borrar usuarios del sistema. Al igual que los clientes, visto en el apartado , los usuarios del sistema se corresponden con los registrados en la aplicación CRM. Por tanto, para agregar usuarios se obtendrá los usuarios registrados en el CRM y no registrados en el sistema y se seleccionará los usuarios a agregar a través de la ventana selección de elementos de la Figura El proceso es el que se indica a continuación: EvoAgentManager. iu. Form_GestionUsuarios Dao. UsuariosAplicacionDAO getusuarioscrm() Dao. CrmDAO <<create>> AGREGAR USUARIOS CrmU : Dominio. UsuarioAplicacion CrmU[ ] mostrar(crmu[ ]-U[ ]) EvoAgentManager. iu. Form_SelectElementos Usuario[ ] <<forward>> Paquete superior::tecnico Select+OK createusuario(usuario) <<create>> Set(id, NombreCompleto, NombreSesion, Tipo) U : Dominio. UsuarioAplicacion Figura 6.59 Diagrama de Secuencia. Agregar Usuarios 111

122 EvoAgentManager. iu. Form_GestionUsuarios Dao. UsuariosAplicacionDAO mostrar(u[ ]) Usuario[ ] BORRAR USUARIO EvoAgentManager. iu. Form_SelectElementos Paquete superior::tecnico <<forward>> Select+OK createusuario(usuario) <<delete>> U : Dominio. UsuarioAplicacion Figura 6.60 Diagrama de Secuencia. Borrar Usuarios Por ultimo, el proceso para modificar el tipo de usuario es un acceso a la capa de datos con una llamada de update sobre el campo en cuestión. Gestión de Usuarios: Como se ha visto en el apartado 5.1 diseño de la arquitectura, en la sección Servidor de la aplicación, el directorio ControlClientes posee un subdirectorio que servirá de repositorio de versiones del programa agente para las máquinas cliente. Se deberá establecer un parámetro en el sistema que indique la última versión disponible para los agentes e, igualmente, establecer un parámetro en los agentes que indique su versión. Cuando se verifique que un programa agente tiene una versión anticuada, éste, procederá a descargarse la última versión del directorio en cuestión. Por tanto, hay dos parámetros a configurar, la última versión disponible y la ruta del repositorio de versiones. Dichos parámetros se crearán en la tabla de settings de la aplicación, y su acceso se ha explicado en las figuras 6.52 y Se podrán gestionar desde la siguiente ventana: Figura 6.61 Diseño de Interfaz. Gestión de Versiones 112

123 6.1.2 Subsistema EvoAgentService e Interacción con el Servidor En este apartado se expone la funcionalidad del subsistema EvoAgent y como interactúa con el servidor de la aplicación. El subsistema EvoAgent se compone de dos módulos, el primero contiene el servicio de Windows, EvoAgentService, que abarca toda la funcionalidad de la herramienta de monitorización junto con las herramientas necesarias para poder realizar su trabajo (WinAudit, CCleaner ). El segundo contiene el programa que carga el icono en la barra de tareas, EvoAgentIcon, mediante el cual el usuario de la máquina cliente puede acceder a la información sobre la aplicación y al programa de control remoto Instalación del subsistema Primeramente, se muestra el proceso que se sigue al realizar la instalación del Subsistema completo en la máquina cliente: INICIO Instalación Componentes de la aplicacion Escritura Clave de registro de arranque del programa EvoAgentIcon Ejecución auditoría vista general XML Auditoría Registro y Obtención de Clave IdMaquina Escritura Clave de registro IdMaquina FIN Figura 6.62 Diagrama de Flujo. Instalación 113

124 1. Instalación de Componentes de la aplicación: Al instalar la aplicación completa se creará una carpeta para la aplicación en la dirección %PROGRAMFILES%\Evotec\EvoAgentSETUP dónde se ubicarán los programas EvoAgent y EvoAgentIcon, sus ficheros de configuración respectivos, los programas auxiliares como WinAudit o el programa cliente de Control Remoto y el subdirectorio de Errores. 2. Escritura Clave de registro de arranque del programa EvoAgentIcon: El módulo EvoAgentIcon precisa de un método para arrancar el programa que carga el icono en la barra de tareas. Para ello, se escribirá una entrada en el registro del sistema de arranque de la máquina que inicie dicha aplicación al arrancar la máquina. 3. Ejecución auditoría vista general: Para la ejecución de la auditoría es necesario ejecutar la aplicación WinAudit mediante el uso de la herramienta de línea de comandos pasándole los argumentos necesarios. Tras la ejecución se genera un archivo XML con el resultado de la auditoría que en este caso es un informe que lleva la vista general de la máquina: nombre del host, dominio, usuario, etc. Esta acción se puede ver con más detalle en el punto Tarea Diaria del apartado Módulo EvoAgentService, en la figura Registro y Obtención de Clave IdMaquina: El documento XML generado es el que se debe enviar al servidor para proceder al registro de la máquina, tal y como se indica en el siguiente diagrama de secuencia: 114

125 ALTA MÁQUINA CLIENTE EvoAgentInstaller EvoAgentServer. services. ControlClientes Dao. DominioDAO Dao. MaquinaDAO AltaMaquinaCliente(DataSet) existedominio(nombred) <<create>> D:Dominio D No createdominio(idd,nombred) D:Dominio <<create>> setd(id,nombre) iddom registramaquina(idmaquina,nombrehost,iddom,nombredom, idcli, nombrecli,timestamp,!permiso) M:Maquina <<create>> setm() IdMaquina Figura 6.63 Diagrama de Secuencia. Registro de Nueva Máquina Cliente 5. Escritura Clave de Registro idmaquina: La clave que recibe del servidor tras el registro es la que utilizará en el futuro para comunicarse con el, por lo tanto, se debe almacenar en un lugar fijo y seguro, en este caso, se crea una entrada con la clave en el registro de Windows. 115

126 Módulo EvoAgentService INICIO NO Inicio Temporizador Vencimiento Temporizador Errores Hay Permiso SI Comprueba Permiso ERROR DE CONEXIÓN Registro de Error en Local Versión Instalada Pregunta Versión del Cliente Versión del Cliente!= Versión Instalada SI Obtener Nueva Version Instalador Instalar Nueva Versión NO NO Errores Lee Errores Registrados Hay Errores o Acciones SI Envío de Errores y Acciones NO Comprobar Tarea Diaria Ejecutar Tarea Diaria SI Obtener Tipo Agente Agente = Servidor NO SI NO Solicitud de Tareas Ejecutar Tarea Diaria Servidor Ejecutar Tarea Diaria PC Hay Tareas SI Registro Tareas Tareas Pendientes Tareas Pendientes Errores SI Inicio Temporizador 2 Vencimiento Temporizador Registro de Error en Local ERROR Ejecutar Tarea Ok NO Registro Error SI Envío Resultado 116

127 Figura 6.64 Diagrama de Flujo. Proceso del Servicio de Windows EvoAgentService El funcionamiento del servicio de Windows EvoAgentService sigue el diagrama de flujo de la figura Cada elemento/proceso marcado en un color más obscuro se trata de una comunicación con el servidor de la aplicación de la que se desprende un diagrama de secuencia. Cada comunicación lleva como argumento el identificador de la máquina que obtiene el agente en el momento de la instalación. A continuación se explicarán cada uno de los pasos del proceso: INICIO: Un servicio Windows automático es iniciado por el sistema operativo al arramcar la máquina. Al iniciar el servicio se establecerán en una clase habilitada para el efecto, ConfigAgente, los parámetros del agente como el directorio de trabajo, el identificador de la máquina y la ruta de acceso al servicio Web ControlClientes del servidor. Inicio Temporizador: Tras establecer los parámetros se arranca un temporizador, que corresponde a la clase System.Timers.Timer. Se ha diseñado un intervalo entre vencimientos del temporizador de una hora. Cada intervalo se realiza un proceso que viene a ser el diagrama de flujo de la figura Comprobar Permiso: Cuando vence el temporizador la primera acción es comprobar si existe comunicación con el servidor y si la máquina tiene permiso para acceder a sus servicios. PROBAR CONEXIÓN Y PERMISO EvoAgentService comprobarpermiso() EvoAgentService. ComunicacionServidor EvoAgentService. ConfigAgente getidmaquina() IdMaquina getwebservice() EvoAgentServer. services. ControlCliente ControlClientes getinstance() Dao. MaquinasDAO comprobarpermiso(idmaquina) ValidaMaquina(idMaquina) OK OK Figura 6.65 Diagrama de Secuencia. Comprobar Permiso 117

128 Una vez que se ha comprobado que el agente tiene permiso para acceder al sistema y que la comunicación es correcta, se puede proceder con el resto de acciones. Comprobar Versión del Cliente: Tras comprobar la comunicación y el permiso hay que comprobar que la versión del agente instalado en la máquina es la correcta para que no haya errores en la comunicación y sepa interpretar los mandatos obtenidos. Para ello, se establece un atributo en el programa agente que indica su versión. Dicho argumento será enviado en la comunicación para que sea el servidor el que compruebe si es correcto comparándolo con el parámetro del sistema existente Tal y como se ha visto en el apartado Módulo Settings, existe un setting del sistema que indica la última versión de los programas agente existente. El proceso seguido se indica en el siguiente diagrama de secuencia: EvoAgentService EvoAgentService. ComunicacionServidor EvoAgentService. ConfigAgente getversioncliente() getidmaquina() IdMaquina getversion() Version getwebservice() COMPROBAR VERSIÓN DEL CLIENTE EvoAgentServer. services. ControlClientes ControlClientes getinstance() Dao. MaquinasDAO Dao. SettingsDAO CompruebaVersion(idMaquina, Version) validamaquina(idmaquina) ok getversioncliente() versión bool OK bool OK Figura 6.66 Diagrama de Secuencia. Comprobar versión del Cliente Obtener Nueva Versión: Si se ha comprobado que la versiñón instalada es la última disponible se procederá con el resto de acciones. Si la versión existente es diferente a la versión del agente, éste deberá solicitar una ruta de donde descargarse la última versión. Tras obtener la ruta el agente establece un httpwebresponse asociado a un 118

129 httwebrequest con la ruta obtenida. El httpwebresponse tendrá un stream de bytes asociado que contendrá el archivo descargado, dicho archivo será un archivo de instalación de Windows Instaler (.msi). Tras realizar la lectura de bytes, se creará el archivo en el directorio de trabajo de la aplicación y se procederá con la instalación. Este proceso se espone en el siguiente diagrama de secuencia: EvoAgentService getrutarepositorio() EvoAgentService. ComunicacionServidor EvoAgentService. ConfigAgente OBTIENE NUEVA VERSION getidmaquina() IdMaquina getwebservice() EvoAgentServer. services. ControlClientes ControlClientes getinstance() Dao. MaquinasDAO Dao. SettingsDAO getrutarepositorio(idmaquina) validamaquina(idmaquina) ok getrutarepositorio() Ruta Ruta Ruta EvoAgentServer HttpWebRequest(Ruta) NuevaVersion.msi Figura 6.67 Diagrama de Secuencia. Obtener Nueva Versión Instalar Nueva Versión: Para instalar la nueva versión se debe crear un proceso que ejecute el archivo que se ha descargado en el punto anterior. El sistema operativo se encarga de controlar el proceso de instalación. Si encuentra que existe un programa con el mismo código identificador de programa y misma versión o superior generará un error y no continuará con la instalación. Si la versión es anterior, procederá a desinstalar la versión anterior e instalar la nueva. Si la versión anterior cuenta con un programa que está ejecutándose, parará el programa (en este caso el servicio de windows) e intentará reiniciarlo tras la instalación de la nueva versión. 119

130 Lee Errores registrados y Registro de Error en Local: Tras comprobar la versión se procederá a leer el log local del agente por si existiese entradas que no se han comunicado al servidor. El agente estará diseñado para llevar un log de acciones y errores que irá transmitiendo al servidor para que éste lo almacene. Si, en alguna ocasión, no puediera transmitir, el agente almacenaría los eventos en un log local. Al volver a tener comunicación con el servidor, enviaría la información que estuviera pendiente en local. Para la gestión del log local se creará una clase específica, LogAgente que tenga los métodos para registrar y obtener tanto acciones como errores. A continuación se presenta el diagrama de secuencia del registro de un error en local: EvoAgentService. LogAgente Log : System. Xml. XmlDocument REGISTRO DE ERROR EN LOCAL Load(workingDirectory + log.xml) <<create>> Set(InnerText = error.iderror) <<create>> iderror : System. Xml. XmlNode Set(InnerText = error.fecha) <<create>> AppendChild(idError) AppendChild(Fecha) Fecha : System. Xml. XmlNode Error : System. Xml. XmlNode get(childnode[0]) <<create>> Errores : System. Xml. XmlNode Errores AppendChild(Error) Save(workingDirectory + log.xml) 'iderror' : System. IO <<create(workingdirectory)>>. File Write(error.descripcion) Close() Figura 6.68 Diagrama de Secuencia. Registro de Error en Local Como se puede observar en el diagrama de secuencia los eventos de log del agente se almacenarán en un fichero tipo.xml con una rama para los errores y otra para las acciones. En los errores, al tratarse la descripción en algunos casos de un bloque largo de texto se utilizará un documento de texto (.txt) con el identificador del error como nombre del documento, análogamente al tratamiento de los mismos en el 120

131 servidor. Por lo tanto el registro de una acción será similar, obviando la creación del documento de texto. Para la lecturá de los errores y acciones pendientes se deberá acceder de nuevo al citado documento log.xml y seguir el siguiente diagrama de secuencia: EvoAgentService. LogAgente Load(workingDirectory + log.xml) Get(ChildNode) Log : System. Xml. XmlDocument Errores : System. Xml. XmlNode <<create>> LECTURA DE ERRORES EN LOCAL Errores getchild()[i] Error : System. Xml. XmlNode <<create>> Error getchild()[0].innertext iderror : System. Xml. XmlNode <<create>> iderror getchild()[1].innertext Fecha : System. Xml. XmlNode <<create>> Fecha <<create(workingdirectory + iderror)>> ReadToEnd() 'iderror' : System. IO. File descripcion Delete() <<create>> Set(idError, fecha, descripcion) error : Dominio. ErrorAplicacion RemoveAll() <<delete>> Error : System. Xml. XmlNode Save(workingDirectory + log.xml) Figura 6.69 Diagrama de Secuencia. Lectura de Error en Local 121

132 Éste método obtiene el directorio de trabajo donde reside el documento log.xml, lee todas las entradas de la rama errores del documento, obteniendo el identificador y la fecha del error. Con el identificador, abre el documento de texto asociado que contiene la descripción, elimina dicho documento de texto y crea la clase error. Una vez hecho esto para todos los errores registrados, borra las entradas del documento log.xml y lo guarda. Devuelve todos los errores leidos. Envio de Errores y Acciones: En el punto anterior se ha explicado la funcionalidad de la clase LogAgente que gestiona el log en local. Para el envio del log al servidor y el almacenamiento de los errores en el mismo se sigue el siguiente proceso: EvoAgentService. ComunicacionServidor getidmaquina() EvoAgentService. ConfigAgente EvoAgentService. LogAgente COPIA DE ERRORES IdMaquina getworkingdirectory() WorkingDirectory EvoAgentServer. services. ControlCliente getwebservice() ControlClientes getinstance() geterrores(workingdirectory) Error[ ] Lectura de Errores en Local Dao. MaquinaDAO Dao. ErrorAplicacionDAO registraerror(idmaquina, iderror, fecha, descripcion) validamaquina(idmaquina) ok getmaquina(idmaquina) M:Maquina <<create>> M <<create>> E:Dominio. ErrorAplicacion sete(iderror,fecha, Tipo,descripcion, idmaquina,idcliente) registroerror(error) registroerror Figura 6.70 Diagrama de Secuencia. Copia de errores 122

133 Como se puede ver, hace uso del proceso anteriormente visto en la figura 6.69 al leer los errores de local y también utiliza un proceso llamado registro Error hubicado en la capa de datos de la librería. Dicho proceso se ha explicado en la figura 6.48, y sirve para guardar un error en el servidor. Las acciones del agente siguen un tratamiento similar a los errores, solo que no es necesario crear documentos de texto asociados para las descripciones. Tarea Diaria: Tras enviar las entradas del log pendientes o si no hubiera ninguna se debe comprobar si se ha realizado la tarea diaria. Los agentes serán configurados para realizar una tarea todos los días. En el servidor de la aplicación existirá un campo junto con la información de los agentes que indique la última ejecución de la tarea diaria de cada uno de ellos. Así, en cada intervalo, se comprobará si la última ejecución es la de hoy de forma que sólo se ejecutará en el primer intervalo del día. La primera acción, es comprobar si se debe ejecutar la tarea diaria: COMPROBAR TAREA DIARIA EvoAgentService comprobartareadiaria() EvoAgentService. ComunicacionServidor EvoAgentService. ConfigAgente getidmaquina() IdMaquina getwebservice() EvoAgentServer. services. ControlCliente ControlClientes getinstance() Dao. MaquinasDAO comprobartareadiaria(idmaquina) ValidaMaquina(idMaquina) OK gettareadiaria(idmaquina) OK OK OK Figura 6.71 Diagrama de Secuencia. Comprobar Tarea Diaria Como se puede apreciar el proceso es idéntico al proceso de comprobar permiso visto en la figura 6.65, interviniendo las mismas clases. Esto es debido a que tanto el parámetro permiso como el parámetro tarea diaria son atributos de un mismo agente y se acceden a ellos a través de la clase MaquinaDAO del nivel de datos. 123

134 Si se debe ejecutar la tarea diaria el agente debe verificar a que tipo de agente pertenece, si es PC o Servidor. El proceso es idéntico al de la figura 6.71 y, consecuentemente, al de la figura 6.65 sólo que se solicita a la clase MaquinaDAO el tipo de agente en lugar del permiso o de la tarea diaria, con lo que no se mostrará el diagrama de secuencia. Una vez obtenido el tipo de agente se procede a ejecutar la tarea en función del tipo. En cualquier caso se ejecuta una auditoría. La ejecución de una auditoría sigue el siguiente diagrama de flujo: INICIO Creación archivo.bat con los campos a auditar más otros argumentos Ejecución del archivo.bat Ejecución WinAudit NO Fin Ejecución? XML Auditoría SI Lectura Auditoría Lectura de la clave de máquina del registro Envío de la Auditoría FIN Figura 6.72 Diagrama de Flujo. Ejecución Auditoría Al terminar la ejecución se procede a enviar el resultado de la auditoría al servidor. Esto provoca en el servidor un estudio de la auditoría recibida para la posible generación de alertas y su almacenamiento para posteriores consultas tal y como se indica en el siguiente diagrama de secuencia: 124

135 EvoAgentService getseleccion(idtarea) EvoAgentService. ControlTareas EvoAgentService. ComunicacionServidor EvoAgentService. ConfigAgente REGISTRO AUDITORÍA SeleccionAuditoria registraauditoría(seleccionauditoria, xml.auditoría) getidmaquina() IdMaquina EvoAgentServer. services. ControlCliente EvoAgentLibrary. Dao. DetalleAuditoriaDAO getwebservice() ControlClientes registroauditoria(idmaquina, seleccionaudit, DataSet) getinstance() Dao. MaquinaDAO validamaquina(idmaquina) ok nuevaauditoria(idmaquina, seleccion, ds, workingdirectory) (*1) Continúa Figura 6.73 Diagrama de Secuencia. Registro Auditoría I El servicio, a traves de la clase comunicación, envía, junto con la selección impuesta a la auditoría, el dataset que contiene el documento xml (En el paso lectura auditoria se hace DataSet.ReadXml(ruta)), y el identificador de la máquina. El servidor valida la máquina y, si tiene permiso, envía la auditoría al nivel de datos para que la almacene. Hasta aquí llega el diagrama de secuencia de la figura En la figura 6.74 se ve como el nivel de datos obtiene la información de las auditorías registradas para la máquina. Si en dichas auditorias el contenido auditado está contenido en la auditoría recibida (se ve por el campo selección) serán eliminadas. La información de la nueva auditoría se guarda en la base de datos y el contenido del dataset se guarda como un fichero xml en el subdirectorio Auditorias del directorio AdminManager del Servidor. Una vez guardada la nueva auditoría se procede a realizar el control de la misma para la generación de alertas a traves de la clase ControlNuevaAuditoría de la librería. Si todo va bien, al terminar el control se envía un correcto al Servicio para que siga su trabajo. 125

136 EvoAgentLibrary. Dao. DetalleAuditoriaDAO REGISTRO AUDITORIA (*1) Continuación EvoAgentLibrary. Dao. DetalleAuditoriaDAO getauditorias (idmaquina) <<create>> D : Dominio.DetalleAuditoria D[ ] [seleccion.contains (D[].seleccion)] Delete (D.idAuditoria) D : Dominio.DetalleAuditoria <<delete>> Delete(workingDirectory + D.idAuditoria) AU : System.IO.File <<create>> D : Dominio.DetalleAuditoria setd(idauditoría,idmaquina, Ds: System.Data.DataSet writexml(workingdirectory+idauditoria) seleccion,fecha) EvoAgentService EvoAgentServer. services. ControlCliente EvoAgentLibrary. services. ControlNuevaAuditoria EvoAgentService. ComunicacionServidor ControlAuditoria(idMaquina, Ds, idauditoria, workingdirectory) <<forward>> Control Auditoria OK OK Figura 6.74 Diagrama de Secuencia. Registro Auditoría II El método Control Auditoría de la clase ControlNuevaAuditoría que sirve para la generación de alertas en el sistema CRM de Microsoft se ve a continuación. Se debe interpretar la salida xml del programa winaudit para obtener la información de los elementos relevantes para la generación de alertas. Se ha diseñado un filtro que se debe obtener para controlar la generación de las mismas. Además de ese filtro general por elemeto generador, cada uno tendrá un filtro específico. 126

137 EvoAgentLibrary. services. ControlNuevaAuditoria CONTROL AUDITORIA Dao. MaquinaDAO EvoAgentLibrary. services. LeerAuditoriaXML getmaquina(idmaquina) M : Dominio.Maquina <<create>> M Dao. SettingsDAO getelementosgeneradores(m.tipoagente) ElementoGeneradorActivo[ ] LeerAuditoria(workingDirectory+idAuditoria, dataset) CamposAuditoria LeerAuditoria EvoAgentLibrary. services. ControlNuevaAuditoria ControlProgramas(CamposAuditoria.Programas, bool ElementoActivo, M, workingdirectory) <<forward>> control Programas ControlDiscos(CamposAuditoria.DiscosLogicos,bool ElementoActivo, M, workingdirectory) <<forward>> ControlMemoria(CamposAuditoria.Memoria,bool ElementoActivo, M, workingdirectory) <<forward>> ControlServicios(CamposAuditoria.Servicios,bool ElementoActivo, M, workingdirectory) <<forward>> ControlErrores(CamposAuditoria.Errores,bool ElementoActivo, M, workingdirectory) <<forward>> control Discos control Memoria control Servicios control Errores Figura 6.75 Diagrama de Secuencia. Control Auditoría El método Leer Auditoría al que se hace referencia en el diagrama de secuencia se corresponde con el mismo método utilizado para leer las auditorías a la hora de mostrar el detalle de las máquinas en la aplicación de gestión. Se puede ver en el 127

138 apartado Maquinas en Ver Detalle Maquina. Devuelve la estructura CamposAuditoría de la que interesa los campos Programas, Discos, Memoria, Servicios y Errores, que son los que se van a controlar para la generación de alertas. Se requiere esa información además del filtro de generación de alertas que se obtiene de la clase SettingsDAO y la Maquina de origen para poder generar las alertas. El directorio de trabajo (workingdirectory) se utilizará para registrar errores si no se puede crear las alertas. Por cada elemento se crea un método para gestionar cuando generar alertas. Control Programas: Se debe verificar que los programas que se reciben en la auditoría no estén registrados en el sistema, en cuyo caso sería un programa nuevo. 128

139 EvoAgentLibrary. services. ControlNuevaAuditoria Dao. ProgramaDAO CONTROL PROGRAMAS getprogramas(idmaquina) P : Dominio.WinAudit. <<create>>maquina_programa P[ ] NewPrograma (CamposAuditoria.Programas[ ] - P[ ]) getfiltroprogramas() Dao. ProgramaDAO Dao. SettingsDAO string[] filtros Dao.AlertaDAO [!NuevoPrograma.Contains(Filtros)] NewAlerta(Tipo, M, Alta Programa..., rutaservidor) registroalerta Dao. ProgramaDAO DeleteDesinstalados(P[ ] - CamposAuditoria.Programas[ ] ) <<delete>> P : Dominio.WinAudit. Maquina_Programa [!ProgramaDesinstalado.Contains(Filtros)] NewAlerta (Tipo, M, Baja Programa..., rutaservidor) Dao.AlertaDAO registroalerta Figura 6.76 Diagrama de Secuencia. Control Programas Se debe obtener los filtros específicos de generación de alertas de programas registrados y compararlos con los nuevos programas. Un programa nuevo, que no contenga en su nombre uno de los filtros, generaría una alerta (Ver Filtro de programas en Gestión de alertas en el apartado Módulo Settings). La generación de alertas se realiza mediante la llamada al servicio web del CRM tal y como se explica en el apartado Acceso al Servicio CRMService para registrar nuevas alertas. En cualquier caso, el nuevo programa se registra en la base de datos para futuros controles. Una vez terminado con los nuevos programas, se comparan de nuevo los programas registrados con los obtenidos de la auditoría para 129

140 obtener programas que hayan sido desinstalados. Los programas desinstalados son eliminados de la base de datos y se procede de la misma manera que con los nuevos programas en cuanto a generación de alertas. Control Discos: Para la generación de alertas de ocupación de disco duro existe un filtro que indica el máximo porcentaje de ocupación de disco a partir del cual se registraría una alerta. EvoAgentLibrary. services. ControlNuevaAuditoria CONTROL DISCOS Dao. SettingsDAO getmaximoocupaciondisco() procentaje Dao.AlertaDAO [Disco.PorcentajeOcupacion>Maximo] NewAlerta(Tipo, M, Espacio en disco..., rutaservidor) registroalerta Figura 6.77 Diagrama de Secuencia. Control Discos Control Memoria: La memoria RAM de la máquina sigue un proceso similar a los discos para la generación de alertas: 130

141 EvoAgentLibrary. services. ControlNuevaAuditoria CONTROL MEMORIA Dao. SettingsDAO getmínimomemorialibre() procentaje Dao.AlertaDAO [Memoria.PorcentajeLibre>Mínimo] NewAlerta(Tipo, M, Memoria RAM..., rutaservidor) registroalerta Figura 6.78 Diagrama de Secuencia. Control Memoria Control Servicios: El control de las alertas generadas por los servicios de windows genera alertas cuando un servicio automático no esté iniciado. Se debe obtener los filtros específicos de generación de alertas de servicios y compararlos con los obtenidos. Un servicio automático, que coincida con uno de los filtros, y éste este desactivado, no generaría una alerta (Ver Filtro de Servicios en Gestión de alertas en el apartado Módulo Settings) El sistema alimenta automáticamente los servicios registrados cada vez que descubre un servicio nuevo. EvoAgentLibrary. services. ControlNuevaAuditoria CONTROL SERVICIO Dao. SettingsDAO getfiltroservicios(nombreservicio, M.tipoAgente) NombreServicios[ ] Dao. SettingsDAO [estado = no esta] NewFiltroServicio(Servicio.NombreServicio, Activo) Dao.AlertaDAO [estado = activo] NewAlerta(Tipo, M, ServicioAutomatico..., rutaservidor) registroalerta 131

142 Figura 6.79 Diagrama de Secuencia. Control Servicio Control Errores: Todo error del log de windows generaría una alerta a no ser que tuviera un filtro asociado y desactivado (Ver Filtro de Errores en Gestión de alertas en el apartado Módulo Settings). El sistema registra cada nuevo error en el sistema para poder aplicarle un filtro. Los errores se identifican por su id de instancia. EvoAgentLibrary. services. ControlNuevaAuditoria Dao. ErrorMaquinaDAO CONTROL ERRORES geterrores(idmaquina) E : Dominio.WinAudit. Maquina_Error <<create>> E[ ] NewError (CamposAuditoria.Errores[ ] E[ ]) Dao. ErrorMaquinaDAO getfiltroerrores(newerror.idinstance, M.TipoAgente) Dao. SettingsDAO int estado Dao. SettingsDAO [estado = no esta] NewFiltroErrores(NewError.idInstance, NewError.sTipo, NewError.sSource, NewError.sDescripcion, Activo) Dao.AlertaDAO [estado = activo] NewAlerta(Tipo, M, Error del log..., rutaservidor) registroalerta Figura 6.80 Diagrama de Secuencia. Control de Errores Una vez registrada la auditoría y generadas las alertas oportunas el servicio continúa con la tarea diaria. En función del tipo de agente obtenido se procede con el resto de tareas que comprenden las tareas diarias. Para ambos casos, osea, pcs y servidores, se realiza una desfragmentación de los discos duros si se ha activado la propiedad en la especificación de la máquina (Ver Modificar las propiedades de un programa agente en 132

143 el apartado Máquinas). Para realizar la desfragmentación de los discos se crea un hilo de trabaj0 que ejecuta el comando del sistema operativo defrag. Para los agentes de tipo servidor se han diseñado dos tareas: la comprobación de la correcta ejecución de tareas programadas y el control de los usuarios registrados en el dominio. Para el control de los usuarios de un dominio de Windows se utilizarán comandos publicados por Microsoft para la gestión del controlador de dominio como el comando dsquery user con los parámetros inactive y otros (Ver la documentación en cd53d3046f mspx?mfr=true). Otra tarea declarada como tarea programable es la comprobación de cuotas. Se puede ver como crear la tarea en el apartado Tareas, en Nueva Tarea, y en que consiste y como se ha diseñado en el punto Ejecutar Tarea más abajo. Para la comprobación de tareas programadas se utilizará la librería comentada en el apartado Windows Task Scheduler. Una vez terminada la tarea diaria se comunica al servidor para que actualice el parámetro. Solicitud de Tareas: El siguiente paso en el proceso es la petición de tareas pendientes al servidor. Además de la tarea diaria se puede programar tareas para que la ejecute un agente a cualquier hora. El agente, en este punto se comunica con el servidor y solicita las tareas que tenga programadas para ese intervalo. 133

144 EvoAgentService getnumtareas() EvoAgentService. ComunicacionServidor getidmaquina() EvoAgentService. ConfigAgente SOLICITAR TAREAS IdMaquina getwebservice() EvoAgentServer. services. ControlCliente ControlClientes getinstance() getnumtareas(idmaquina) numerotareas EvoAgentServer. dao. MaquinasDAO EvoAgentServer. dao ValidaMaquina(idMaquina). TareaMaquinaDAO OK getnumtareas(idmaquina) numerotareas numerotareas gettareas(numtareas) getidmaquina() IdMaquina getwebservice() ControlClientes getinstance() gettareas(idmaquina) EvoAgentService. ControlTareas String Tarea[ ] ValidaMaquina(idMaquina) OK gettareas(idmaquina) TareaMaquina[ ] EvoAgentServer. dao <<create>>. TareaMaquinaDAO Tarea[ ] settareas(tarea[ ]) Figura 6.81 Diagrama de Secuencia. Solicitud de Tareas Las tareas obtenidas se guardan en la clase ControlTareas que permanecerá activa hasta que se hayan ejecutado todas. La ejecución de las tareas depende de la tarea que se vaya a ejecutar: 134

145 Auditoría: Sigue el proceso que se ha explicado en el punto Tarea Diaria. Apagado: Utiliza el comando de MS2 shutdown, estableciendo un tiempo de 5 minutos hasta el apagado y comunicándolo al usuario. Limpieza: Ejecuta el programa CCLeaner por línea de comandos. Inicio de Servicio: Mediante la clase ServiceController intenta inicial el servicio con el nombre que ha recibido como parámetro. Comprobar Cuotas: Se trata de una tarea para agentes servidor de dominio. En el servidor de dominio residen los documentos de los usuarios del mismo en alguna carpeta que suele tomar el nombre PERFILES. Se pueden agrupar en varias carpetas, por ejemplo, DOCS, ESCRITORIO, FAVORITOS En cada una existirá una carpeta por cada usuario del dominio. La tarea mediante el método FileInfo.Length calcula el tamaño de disco que ocupan los ficheros y subdirectorios de las carpetas de cada usuario en cada directorio suministrado y lo suma. El resultado es un listado de usuarios y tamaños de cuota. Desfragmentar: También se puede ejecutar como parte de la tarea diaria. Se utiliza el comando dfrag como se ha explicado. Envío Resultado: Si la tarea termina correctamente se envia al servidor para que se registre. 135

146 ENVÍO RESULTADO EvoAgentService EvoAgentService. ComunicacionServidor EvoAgentService. ConfigAgente ResultadoTareaMaquina( idtarea,fecha,resultado) getidmaquina() IdMaquina getwebservice() EvoAgentServer. services. ControlCliente ControlClientes getinstance() Dao. MaquinasDAO resultadotarea(idmaquina, idtarea, resultado) validamaquina(idmaquina) ok Dao. TareaMaquinaDAO settarearealizada(idtarea) T:TareaMaquina <<create>> sett(realizada) Figura 6.82 Diagrama de Secuencia. Envío Resultado Envío de Error: Si se produce un error en alguna de las acciones descritas hasta ahora, dicho error se intentaría registrar en el servidor. Si no se pudiera registrar en el servidor se guardaría en local como se ha visto en el punto Lectura de errores y registro de error en local. 136

147 EvoAgentService. ComunicacionServidor getidmaquina() EvoAgentService. ConfigAgente ENVIO DE ERROR IdMaquina getwebservice() EvoAgentServer. services. ControlCliente [error] ControlClientes RegistraError(idMaquina, iderror fecha, descripcion) getworkingdirectory() WorkingDirectory EvoAgentService. LogAgente RegistraError (WorkingDirectory,Error) registroerror en Local getinstance() Dao. MaquinaDAO validamaquina(idmaquina) ok getmaquina(idmaquina) M <<create>> <<create>> Dao. ErrorAplicacionDAO M:Maquina E:Dominio. ErrorAplicacion sete(iderror,fecha, Tipo,descripcion, idmaquina,idcliente) registroerror(error) registroerror Figura 6.83 Diagrama de Secuencia. Envío Error El proceso de registro de error en el servidor se ha descrito ya en el apartado Logs en la figura El intervalo termina al ejecutar todas las tareas. El servicio se queda dormido hasta el siguiente intervalo en el que volverá a repetir el proceso. 137

148 Módulo EvoAgentIcon Este módulo deberá poseer interfaz de usuario y consistirá en un Icono que se ubicará en la barra de tareas. El icono tiene como finalidad informar al usuario de la existencia de la aplicación y, a su vez, permitirá desplegar un menú desde el que acceder a la funcionalidad del módulo que consiste en el acceso al programa de conexión remota y a la información de la aplicación. ICONO EN BARRA DE TAREAS Figura 6.84 Diseño de Interfaz. EvoAgentIcon. Icono de la Barra de Tareas El icono se carga al arrancar la máquina gracias a la entrada en el registro de arranque de la máquina que se incluye en el proceso de instalación del subsistema. Se arrancará con las credenciales que utiliza el usuario de Windows. Pulsando sobre el icono aparece el menú: MOSTRAR INFORMACIÓN DE LA APLICACIÓN LANZAR CLIENTE DE CONTROL REMOTO DE EVOTEC 138

149 Figura 6.85 Diseño de Interfaz. Menú de EvoAgentIcon en la barra de Tareas Al pulsar Acerca de se mostrará la siguiente ventana de información de la aplicación: LANZAR CLIENTE DE CONTROL REMOTO DE EVOTEC Figura 6.86 Diseño de Interfaz. Información de la Aplicación Desde esta ventana se podrá acceder también al cliente del programa de Control Remoto de Evotec (Cliente de Ultra VNCViewer) Figura 6.87 Interfaz del cliente de control Remoto de VNC Viewer Personalizado por Evotec El funcionamiento de dicho programa no entra dentro del marco de este proyecto, simplemente se da acceso al mismo. Ultra VNCViewer es una aplicación de software libre que permite crearse un sistema de acceso a máquinas cliente para supervisión en tiempo de ejecución, es decir, cuando el usuario de la máquina arranque el programa e introduzca el id de sesión del técnico se obtendrá acceso al mismo sin necesidad de iniciar sesión de forma remota con el terminal server. 139

150 6.1.3 Sistema Externo Microsoft Dynamics CRM En este apartado se mostrará como se realizará la integración con el CRM. En concreto se tratan los siguientes aspectos: Interacción con la interfaz del CRM para generar la entidad Alerta Acceso a la base de datos Acceso al servicio CRMService para registrar nuevas alertas Interacción con la interfaz del CRM para trabajar con las alertas generadas por el sistema Interacción con la interfaz del CRM para generar y personificar la entidad alerta Primeramente, se debe crear una entidad del CRM con el nombre, los atributos que se necesitarán y los formularios o interfaz por donde se mostrarán. Microsoft CRM permite crear y personalizar entidades: Figura 6.88 Microsoft CRM. Personalización de Entidades 140

151 Para cada entidad se pueden configurar cuatro apartados tal y como se muestra en la figura 6.78: La información de la entidad permite darle un nombre con el que se podrá identificar desde el módulo cliente de programación. Se puede especificar en que áreas de las que aparecen en el menú de la izquierda se mostrará el acceso a ésta entidad. Figura 6.89 Microsoft CRM. Personalización Entidad Alerta Los atributos son los campos que tiene la entidad. Se puede especificar el nombre, el tipo de dato, formato 141

152 Figura 6.90 Microsoft CRM. Personalización de Atributos para la Entidad Alerta Los formularios y vistas permiten configurar la interfaz con la que se mostrará los atributos de la entidad. En concreto se mostrarán 2 interfaces. El primero servirá de vista general de todas las alertas y el segundo servirá de formulario donde recoger la información de cada una. Figura 6.91 Microsoft CRM. Personalización de Vista General para la Entidad Alerta 142

153 Figura 6.92 Microsoft CRM. Personalización del Formulario para la Entidad Alerta Las relaciones permiten asociar entidades entre sí. En este proyecto además de crear alertas se deberán poder asociar a casos para tratarlas por lo que será necesario asociar las alertas a los casos: 143

154 Figura 6.93 Microsoft CRM. Personalización de la relación entre la Entidad Alerta y la Entidad Caso. Una vez que se crea una entidad, el sistema CRM actualiza su base de datos para introducir las tablas correspondientes por lo que queda fuera del dominio del proyecto el almacenar la información de las alertas. Asimismo, añade la entidad junto con sus atributos al namespace que se obtiene del Servicio Web CRMService mediante el cual se podrá programar la creación de alertas como se muestra en el diagrama de secuencia Registro de Auditoria (Figura 6.72) Acceso a la Base de Datos Si bien se puede obtener datos de la aplicación CRM a través de acceso a la base de datos de la misma gestionada bajo el sistema SQL Server, éste procedimiento no es recomendable a la hora de modificarlos o de introducir nuevos datos debido a que se pueden obtener resultados no deseados al romper la coherencia de los datos que mantiene internamente la aplicación CRM. Por tanto, éste procedimiento tan sólo se utilizara para obtener datos del sistema CRM, en concreto se debe obtener dos objetos de datos: Usuarios y Clientes, y sólo 5 atributos, 3 del primero y dos del segundo. Para acceder a dichos datos se va ha utilizar la clase DataSet de Visual Studio que se explica con más detalle en el Apartado Acceso a datos. Se requerirá una cadena de conexión con la base de datos del CRM con un usuario y contraseña válidos para poder acceder vía autenticación SQL. El DataSet contendrá dos tablas con los campos que se requieran y dos adaptadores. Dichos componentes pasarán a formar parte del nivel de datos Acceso al servicio CRMService para registrar nuevas alertas Como se ha explicado en otros apartados, la aplicación CRM posee un servicio Web que se puede utilizar para obtener o registrar información en el sistema CRM sin utilizar la interfaz pero accediendo a dicha información utilizando el gestor de datos del propio CRM y conservando, por tanto, la coherencia de los datos. Para ello se debe crear una referencia al servicio web CRMService tal como se indica en el Apartado Introducción al CRM de Microsoft de este documento y en la documentación SDK del CRM. Accediendo al espacio de nombres que provee la referencia a dicho servicio web, se pueden crear las entidades necesarias para registrar alertas en el servidor. En concreto, se requiere instanciar el propio servicio web y asignarle una credencial válida. El servicio CRMService tiene varios métodos de los que se va a utilizar el método execute. Dicho método requiere un argumento que puede ser entendido como una llamada y que recibe el nombre genérico de request. En el SDK se pueden observar todas las clases que heredan de la clase abstracta request y que se corresponden con cada una de las opciones de llamada existentes -léase create, retrieve, update, delete-. 144

155 Este argumento llamada a su vez tiene un atributo que viene a ser el objeto de la llamada y que se denomina genéricamente target. El target posee un atributo que varía en función de la llamada (si es create, retrieve ) y de la entidad existente en el CRM de la que es objeto la llamada. Así, el objeto del target de un CreateRequest es la entidad que se desea crear y el objeto del target de un RetrieveRequest es el identificador de la entidad que se desea obtener. Más concretamente, existe una clase heredada de cada tipo de target (retrieve, request) por cada entidad registrada en el CRM. Así, al crear una nueva entidad personalizada, como la entidad alerta, se generarían las clases TargetCreateAlerta, TargetRerieveAlerta. Como conclusión, para registrar una entidad alerta, se requiere generar la propia entidad, asignarla al atributo correspondiente de un nuevo objeto TargetCreateAlerta y éste a un nuevo objeto CreateRequest. Instanciando el CRMService, asignarle una credencial válida y ejecutar el método Execute pasándo como argumento el request. El resultado se obtiene en forma de CreateResponse. Todo esto se detalla en el siguiente diagrama de secuencia: 145

156 Dao.AlertaDAO <<create>> al : Dominio. CRM. new_alerta REGISTRO ALERTA Set(Tipo, NombreMaquina, UsuarioPropietario, Desc., Cliente) <<create>> target: Dominio. CRM. TargetCreateAlerta Set(al) <<create>> request : Dominio. CRM. CreateRequest <<create>> set(user, Pw, Domain) Set(target) cre : System. Net. NetworkCredentials <<create>> setcredentials(cre) service : Dominio. CRM. CRMService Execute(request) <<forward>> [error] err : Dominio.ErrorAplicacion <<create>> Dao. ErrorAplicacionDAO Set(id, fecha, tipo,maquina, cliente, descripcion) registroerror(error, rutaservidor) <<forward>> registroerror Figura 6.94 Diagrama de Secuencia. Registro de Alerta. En el diagrama de secuencia de la figura se ha tenido en cuenta la gestión de errores generados por la aplicación. La mayoría de las acciones pueden provocar excepciones de.net sin que para ello haya tenido nada que ver el propio sistema, sino, por ejemplo, por la modificación de los permisos de acceso de un directorio virtual o por la pérdida momentánea de la red. Todos estos errores son tratados por el sistema para ofrecer una visualización de los mismos al usuario gestor del sistema. Se ha hecho una referencia al método registroerror (en rojo) que se ha mostrado en el Apartado Log de la aplicación, en la Figura

157 Interfaz CRM. Trabajar con la entidad Alerta El usuario por tanto podrá acceder a las alertas generadas por el sistema desde el área de trabajo del menú de la izquierda. ASIGNAR ALERTA DESECHAR ALERTAS Figura 6.95 Diseño de Interfaz. Microsoft CRM. Alertas Desde ahí se podrán realizar las siguientes acciones: Desechar Alertas Con la información disponible se puede optar por desechar el evento como alerta y eliminarlo. Para ello se pude seleccionar las alertas a eliminar y pulsar el botón con un aspa. Se pedirá confirmación. Asignar Alertas Aunque, como se ha visto en el módulo Settings, que existe un usuario del sistema al que se registran todas las alertas el usuario propietario de unas determinadas alertas se puede modificar. Esto permitiría poder poner un usuario genérico como el propietario de las alertas y desde éste asignarlas a quien corresponda. 147

158 Para asignar la alerta se debera acceder primero a la alerta haciendo doble clic sobre ella. Aparecerá la ventana del formulario de la alerta. Sobre el menú de arriba pulsar la opción Acciones y Asignar: Figura 6.96 Diseño de Interfaz. Microsoft CRM. Asignar Alerta I Aparecerá la figura Si se desease asignar a otro usuario se podrá seleccionar la opción y pulsar sobre la lupa que aparece al final del recuadro: Figura 6.97 Diseño de Interfaz. Microsoft CRM. Asignar Alerta II Aparecería otra ventana con los posibles usuarios donde se podrá seleccionar el usuario deseado. 148

159 Figura 6.98 Diseño de Interfaz. Microsoft CRM. Asignar Alerta III Crear Caso vinculado a Alerta El caso es la unidad de tratamiento de incidencias con un cliente. Cada caso conlleva unas acciones que se deben realizar antes de resolver dicho caso. Los casos pueden ser debidos a un problema o una solicitud o revisión. Se pueden acceder a ellos a través de las cuentas de los clientes o directamente, al igual que con las alertas, desde el menú Área de Trabajo. El caso es la herramienta, interna al CRM, que se ha elegido para tratar las alertas. Es por ello que se haya realizado una integración con dicha aplicación. Cada alerta podrá generar uno o varios casos para un cliente. El tratamiento de casos es un apartado correspondiente al CRM y por tanto no será asunto de este proyecto. Sobre el formulario de la alerta, en el menú de la izquierda, aparecerá la opción Servicios y dentro de Servicios Casos. Haciendo clic sobre éste último se accederá a los casos relacionados con la alerta y se podrán crear nuevos: 149

160 Figura 6.99 Diseño de Interfaz. Microsoft CRM. Asignar Alerta III Al crear el nuevo caso, éste llevará asociado una alerta en el apartado Alerta. Figura Diseño de Interfaz. Microsoft CRM. Asignar Alerta III A partir de aquí se puede trabajar con el caso como un caso más, asignarlo a un usuario y resolverlo. 150

161 6.2 Modelo de datos El modelo de datos, tal y como se ha explicado en el apartado Describir el modelo de datos, se puede dividir en 3 apartados. Además se estudiará el método de programación a utilizar para acceder a los datos Diseño Conceptual de datos El diseño conceptual de datos se realiza a partir del modelo de dominio, que uniéndolo a un mejor conocimiento de los objetos del sistema tras el diseño externo e interno del mismo, se obtiene el modelo Entidad-Relación: Alerta N 1 R Cliente 1 M R Dominio C C N 1 1 R R R 1 1 Maquina 1 N 1 N R R N LogCliente R R R N ErrorCliente C N C Error N R Tarea N ErroresAplicacion 1 R 1 C UsuarioAplicacion SettingsAplicacion R Programa N R N R M M R M MaqAuditoria C R CARDINALIDADES: 1 1 0, 1 C 1, 2, 3,... M 0, 1, 2, 3,... N Figura Diagrama Entidad-Relación 151

162 6.2.2 Diseño Lógico de datos El modelo Entidad-Relación nos da una idea de los datos con los que trabajará el sistema. Sin embargo, es necesario pasar a un modelo lógico donde se pueda obtener los datos normalizados. El modelo lógico sería el modelo RE/R, que se obtiene con una simple conversión en los criterios de representación a partir del modelo Entidad/Relacion. Además, se introduce los atributos de las tablas: Alerta(-idAlerta-,descripcion,tipoAlerta) N R11 Cliente(-idCliente-,Nombre) R2 M Dominio(-idDominio-,nombreDom) C C N C C R1 R3 M N R15 N LogCliente(-idAccion, dfecha-, dhora, saccion) R9 Maquina(-idMaquina-,sNomHost) N R16 R4(dFecha, seleccion) N ErrorCliente(-idError-, dfechaerror, stipo, sdescipcion) C R19 R12 N R10 C Error(-idError-,sSource,dFecha,sDescripcion) N R8 R7 R5 R6 N Tarea(-idTarea-,nombreTarea) SettingsAplicacion(-idSetting-, snombre, svalor) ErroresAplicacion(-idError-, dfechaerror, stipo, sdescipcion) UsuarioAplicacion(- idusuario-, snombresesion, snombrecompleto) C Programa(-idPrograma- N,sNombrePrograma,sVersion,dFechaInstal acion,sruta) CARDINALIDADES: R13 N R14 M M MaqAuditoria(idAuditoria, M dfechaauditoria,sselección) C 1 1 (puede omitirse) 0, 1 c 1, 2, 3,... m (puede omitirse) y flecha 0, 1, 2, 3,... n y flecha Figura Conversión Entidad-Relación a RE/R El modelo obtenido debe pasar por las reglas de transformación del modelo RE/R explicado en el anexo 4.3 Metodologías Así, el nuevo modelo de datos queda de la siguiente manera: 152

163 Cliente(-idCliente-,Nombre) Dominio(-idDominio-,nombreDom, - idcliente-*) Maquina(-idMaquina-,sNomHost, - idcliente-*,-iddominio-*) N LogCliente(-idMaquina*, idaccion, dfecha-, dhora, saccion) N AlertaError(-idAlerta-,descripcion, tipoalerta, -idmaquina-*, -idcliente-*, <-iderror-*>, <ssource>, <dfecha>, sdescripcion> ) N N MaqTarea(-idMaquina*, idtarea*-, dfecha, selección, <-idauditoria-*>) N ErroresAplicacion(-idError-, dfechaerror, stipo, sdescipcion, <- idmaquina->*) SettingsAplicacion(- idsetting-, snombre, svalor) N AlertaPrograma(-idAlerta-,descripcion, tipoalerta, -idmaquina-*, -idcliente-*, <- idprograma-*>, <snombreprograma>, <sversion>, <dfechainstalacion>, <sruta> ) N N UsuarioAplicacion(- idusuario-, snombresesion, snombrecompleto) N ErrorAuditoria(-idMaquina*, idtarea*-, dfecha, selección, - idauditoria-*, -idprograma-*) N ProgramaAuditoria(-idMaquina*, idtarea*-, dfecha, selección, - idauditoria-*, -iderror-*) Tarea(-idTarea-,nombreTarea) CARDINALIDADES: 1 1 (puede omitirse) 0, 1 c 1, 2, 3,... m (puede omitirse) y flecha 0, 1, 2, 3,... n y flecha Diseño Físico de datos Figura Diagrama RE/R El último modelo de datos está normalizado lo que no implica mejores prestaciones. A partir de un análisis de las necesidades de acceso a la base de datos se descubre que se puede mejorar las prestaciones si se introducen algunos campos en las tablas. Por ejemplo, en la tabla de máquinas sería apropiado poseer el nombre del cliente propietario de la máquina además de su identificador inferido por la normalización. Por otro lado, también resulta conveniente modificar las propiedades de algunos atributos de forma que estos puedan admitir valores nulos. Por ejemplo, como se ha visto en el diseño interno, el subsistema EvoAgent registra máquinas sin conocer el cliente, tan sólo el dominio. És el servidor, EvoAgentServer, quien puede conocer el cliente a partir del dominio. Pero esto puede que no ocurra, de tal forma que sea necesario registrar la máquina sin cliente y 153

164 asociarlo después mediante el módulo Clientes del subsistema EvoAgentManager. Por tanto, sería necesario permitir que el valor del cliente en la tabla de máquinas admitiese nulos. También hay tablas que son necesarias por la lógica del programa, como las tablas de errores y programas de las máquinas para poder comprobar si hay nuevos programas instalados, que pueden reemplazar a las tablas ProgramaAuditoría y ErrorAuditoría y las tablas de Settings de la aplicación, elementos generadores y filtros de generación de alertas. Por otro lado, conviene separar las tareas de las auditorías, ya que éstas últimas hacen referencia al resultado de la tarea auditoría correspondiente. Por último, la tabla alerta no puede considerarse como parte del modelo ya que pertenece íntegramente a la base de datos del CRM y es éste el que la gestiona. Por tanto, tras estas consideraciones, el modelo de datos queda como sigue: 154

165 Cliente(-idCliente-,Nombre) N Dominio(-idDominio-,nombreDom, <-idcliente->*, <srazon>) N LogCliente(-idMaquina*, idaccion, dfecha-, dhora, saccion, <- idcliente->*) Maquina(-idMaquina-,sNomHost, <- iddom->*, snomdom, <-idcli->*, <srazon>) N N N ErroresAplicacion(-idError-, dfechaerror, stipo, sdescipcion, <- idmaquina->*, <-idcliente->*) SettingsAplicacion(-idSetting-, snombre, svalor) FiltroAlertaPrograma(-sFiltro-) MaqPrograma(-idMaquina*, idprograma-,snombreprograma,sversion,dfech ainstalacion,sruta) MaqError(-idMaquina*, iderror-, stipo, ssource, dfecha, sdescripcion) FiltroAlertaError( -iderror-, stipo, ssource, sdescripcion) N N N MaqAuditoria(-idAuditoria-,- idmaquina-*, dfechaauditoria,sselección) N MaqTarea(-idMaquina*, idtarea*-, dfecha, snombretarea, sselección) N Tarea(-idTarea-,nombreTarea) CARDINALIDADES: UsuarioAplicacion(-idUsuario-, snombresesion, snombrecompleto) ElementoGenerador(-sElemento-, ActivoPC, ActivoServidor) FiltroAlertaServicio(- snombreservicio-, bactivopc, bactivoservidor) 1 1 (puede omitirse) 0, 1 c 1, 2, 3,... m (puede omitirse) y flecha 0, 1, 2, 3,... n y flecha Figura Modelo Físico de Datos La tabla de alertas quedará registrada en la base de datos del CRM conteniendo los campos que se definan en la creación de la entidad alerta más los campos que introduzca el CRM. Irá asociada a la tabla de clientes y de usuarios del CRM. 155

166 Alerta(-idAlerta-,descripcion,tipoAlerta, - idmaquina-*, -idcliente-*, -idusuario-*, <snombreprograma>,<dfechainstalacion>, <sruta>, <iderror>, <ssource>, <dfecha>, <sdescripcion>) N N CRMCliente(-idCliente-,...) CRMUser(-idUsuario-,...) Figura Tabla Alertas del CRM Acceso a los datos Capa de Datos Aspectos de Rendimiento En un sistema que posea una base de datos con tablas de gran tamaño (con infinidad de registros), el rendimiento de la aplicación puede verse seriamente afectado a la hora de acceder a los datos. Una solución que ayuda a mejorar el rendimiento es el uso de índices. Para introducir los índices se debe entender que el acceso a los datos suele llevar asociado múltiples consultas sobre tablas con un filtro asociado (cláusula WHERE en el lenguaje SQL). Dicho filtro hace que sólo las filas de una tabla que cumplan con el filtro deben ser seleccionadas. Si se debe leer toda la tabla para tomar esta decisión (qué registros cumplen la condición) se está perdiendo rendimiento. Los índices permiten optimizar este proceso. Si se conocen los campos que actúan de filtro se podría acceder directamente a los datos que cumplen la condición. Un índice ocupa espacio en disco y en memoria pero permite optimizar las búsquedas y, por tanto, el rendimiento del sistema. Esto es posible porque al realizar una consulta el gestor de bases de datos sigue el siguiente proceso: 1. Determina si existe un índice y es útil 2. Navega a través del índice 3. Evalúa el valor de búsqueda contra cada valor de clave y repite esta evaluación hasta una de las siguientes ocurrencias El valor de búsqueda no es mayor o igual que el valor de clave 156

167 El valor de búsqueda es mayor o igual que el último valor en la página de índice Los índices se generan en forma de listas enlazadas y poseen enlaces a las páginas de datos: Figura Índices de acceso a datos Para la creación de índices se debe tener en cuenta aquellos campos que serán referenciados en las consultas. Por ejemplo, para la tabla T_MaqTarea que contiene las tareas asignadas a las máquinas se realizarán consultas de tareas en función de la tarea, de la máquina, del cliente o del estado como se muestra en la figura 6.5. Por tanto, será conveniente y casi necesario crear índices por cada uno de estos campos. Esto se realiza fácilmente por medio de la aplicación gratuita SQL Server Management Studio Express: 157

168 Figura Indices por tablas en SQL Server Se puede ver que se han creado tres índices además del generado automáticamente según la clave principal de la tabla. Un índice para el campo cliente, otro para el campo tarea y otro para el campo máquina. Un mismo índice puede tener asociadas varias columnas por las que se organiza. Por ejemplo, el índice PorTarea tiene un primer campo de orden que es el identificador de la tarea asociada, un segundo campo que es el identificador de cliente y un tercero que es el identificador de máquina. Al realizar una consulta sobre esta tabla en función de una tarea y un cliente, cabría la posibilidad de utilizar dos índices, el índice por cliente y el índice por tarea, en cualquier caso, posteriormente a la primera criba, al haber agregado ambas columnas en los índices contrarios de forma secundaria, se realizará una segunda criba por la segunda columna. En la siguiente figura se puede observar las propiedades del índice. 158

169 Figura Configuración de un índice de acceso a datos por columnas Aspectos de Programación Tras crear el modelo de datos en el Sistema Gestor de Base de Datos elegido, en este caso, SQL Server 2005, se debe proceder a configurar el acceso a los datos. Se deberá restringir el acceso a la base de datos mediante la introducción de un usuario gestor de la base de datos con una contraseña y, así, realizar la autenticación vía SQL authentication. 159

170 Figura Base de datos Evotec_Control vista con el programa Microsoft SQL Server Management Studio Express. El acceso a datos se realizará mediante una cadena de conexión estándar de los proyectos de Visual Studio. Dicha cadena contendrá los datos necesarios para autenticarse con el servidor SQL Server (Figura 6.111). A partir de esa cadena de conexión se construye una conexión SQL Connection a dicho servidor. Figura Configuración de una cadena de conexión a datos en Visual Studio. La cadena de conexión se guardará con un nombre en la carpeta Settings de la aplicación. En este caso Evoec_ControlConnectionString. En Visual Studio se pueden utilizar las clases DataSet para acceder a los datos de un origen de datos. Un DataSet contiene objetos Tabla (System.Data,DataTable) y objetos Adaptador de datos (System.Data.DataTableAdapter). Lo normal es configurar cada tabla con un 160

171 adaptador de datos propio. Los adaptadores poseen como propiedad la conexión de datos mencionada anteriormente. Si en cualquier momento se modifica la cadena de conexión los adaptadores asumen el cambio automáticamente, así se obtienen un único punto donde modificar la ruta que utiliza el sistema para acceder a los datos. Figura Creación de un DataSet en un proyecto de VisualStudio 161

172 Figura Creación de un DataAdapter en un DataSet de un proyecto de VisualStudio En la creación de un Adaptador de datos, tras seleccionar la conexión, se deberá seleccionar la tabla que se desea que controle el adaptador y seleccionar los campos de la tabla que se desea obtener. Al finalizar se creará el objeto DataTable y el objeto DataTableAdapter en el dataset. 162

173 Figura Objeto DataTableAdapter y DataTable En la Figura se observa el objeto DataTable T_Maquina creado y el objeto DataTableAdapter T_MaquinaTableAdapter. El primero contiene los campos de la tabla y estará vacio hasta que no se rellene mediante un método del segundo. Se pueden agregar tantos métodos como se quiera en un adaptador, cada uno conlleva una ejecución de una instrucción SQL contra el origen de datos indicado en la cadena de conexión. A partir de este momento se puede instanciar los objetos adaptadores y el objeto DataSet que contiene los objetos tabla. Entonces se puede utilizar los adaptadores para obtener, modificar y crear datos. Se puede trabajar con las tablas rellenándolas de datos a partir de una llamada a un método del adaptador correspondiente. Para la gestión del DataSet y los adaptadores se crearán clases pertenecientes a la capa de datos, es decir, al paquete DAO de la librería de la aplicación 163

174 6.3 Diagrama de Clases A partir del Análisis de requerimientos, el diseño externo del sistema y el diseño del modelo de interacción (diagramas de secuencia), se posee un amplio conocimiento de los objetos del sistema a construir. Así, por cada subsistema y paquete, se expone a continuación el diagrama de clases que lo compone: Librería EvoAgentLibrary Paquete Dominio 164

175 Figura Diagrama de Clases. Paquete Dominio: Dominio, Cliente, Maquina Figura Diagrama de Clases. Paquete Dominio: DetalleAuditoria, Usuario, Tarea, TareaProgramada, ApplicationSetting, AccionCliente 165

176 Figura Diagrama de Clases. Paquete Dominio: ErrorAplicacion, TareaMaquina, MiTrigger El paquete dominio comprende las clases de las figuras y y además de todas las clases que importa de otros paquetes tal y como se vio en el diseño externo del sistema. Así se podrían incluir las clases del paquete WinAudit o del paquete de TareasProgramadas aunque en este último caso existe una adaptación de las clases Trigger 166

177 en la clase MiTrigger. Por último cabría incluir también la clase Alerta del paquete CRM Dinamics. Paquete Services 167

178 Figura Diagrama de Clases. Paquete EvoAgentLibrary.Services En este paquete se incluyen clases que sirven de complemento para procesos del sistema como puede ser el Intérprete de programación de tareas que sirve de interfaz entre el sistema y el sistema externo TaskSheduler; o el lector de auditorías que sirve de interfaz entre el resultado del sistema externo winaudit y el sistema; o la clase Control Auditoria que administra la generación de alertas en el sistema externo CRM. Ésta última sólo la utilizaría el subsistema EvoAgentServer. Por otro lado se incluye aquí la clase Credenciales Usuario que es utilizada en el subsistema EvoAgentManager para almacenar las credenciales que utiliza el usuario técnico de Evotec para entrar en la aplicación de gestión. Dicha clase posee también el método de autenticación (Init_Login()) visto al principio de este capítulo 6. Las propiedades de esta clase son, entre otras, el Usuario registrado en el sistema (Clase Usuario del paquete Dominio) y las credenciales introducidas en el inicio de sesión de Windows (Clase NetworkCredential de System.Net). La clase permanece activa mientras lo esté la aplicación de gestión y se puede acceder mediante su propiedad Current que hace que devuelva la clase con los parámetros establecidos en el inicio de la sesión. También está la clase auxiliar campos auditoria que complementa a la clase Campos Auditoría de la que se ha hablado ya en este capítulo y se verá en el paquete WinAudit. Es utilizada por el módulo Área de Trabajo al mostrar el detalle de las máquinas como se explica en el apartado Maquinas. Paquete Microsoft CRM Dynamics El espacio de nombres que se obtiene al referenciar el servicio web del crm posee gran cantidad de clases. Aquí se indican las que serán necesarias para registrar las alertas. No será necesario crearlas puesto que estas clases ya existen y pertenecen a la aplicación CRM. Mediante el acceso al servicio web del CRM para programadores, CRMService, se pueden utilizar todas estas clases. Para la correcta utilización consultar la documentación del CRM SDK 3.0 descargable desde el link bd14b74308c5&displaylang=en. 168

179 Figura Diagrama de Clases. Paquete Microsoft CRM Dinamics I El mecanismo para la generación y registro de alertas en el CRM utilizando estas clases se ha explicado en el apartado Generación de Alertas 169

180 Figura Diagrama de Clases. Paquete Microsoft CRM Dinamics II 170

181 Paquete Windows Task Sheduler Pertenecientes al Namespace del ensamblado TaskScheduler. Se requiere añadir una referencía a la dll comentada en el apartado y ya se pueden utilizar las clases que se requieran. Figura Diagrama de Clases. Paquete Windows Task Sheduler I 171

182 Figura Diagrama de Clases. Paquete Windows Task Sheduler II 172

183 Paquete WinAudit Este paquete ha sido creado a partir de cada campo que se obtiene en la auditoría que realiza el programa WinAudit. Cada campo auditado posee atributos definidos en la documentación del programa que se puede analizar desde el link En la página web (en inglés) se puede navegar de un campo a otro viendo los atributos definidos para cada campo. Se ha creado una clase por cada campo y una clase general, campos auditoria, que las engloba a todas: 173

184 Figura Diagrama de Clases. Paquete WinAudit. Campos Auditoria Figura Diagrama de Clases. Paquete WinAudit I 174

185 Figura Diagrama de Clases. Paquete WinAudit II 175

186 Figura Diagrama de Clases. Paquete WinAudit III 176

187 Paquete EvoAgentLibrary.dao -Capa de Datos-. En este paquete se implementa todos los métodos y querys necesarias para acceder a la base de datos. Como se ha visto en el apartado se ha diseñado un dataset por cada base de datos que maneje el sistema, en concreto la base de datos del propio sistema, Evotec_Control, y la base de datos del CRM. En los dataset se deben agregar clases DataTable y DataTableAdapter por cada tabla a la que se quiere tener acceso. Los DataTable se agregan como atributos del DataSet mientras que los Adapters se configuran como un espacio de nombres diferente. Por otro lado, para el control de los DataSet se debe generar clases auxiliares y es lo que se ha hecho con las clases DAO. Figura Diagrama de Clases. Paquete dao. EvoDataSet 177

188 Figura Diagrama de Clases. Paquete dao. EvoDataSet.TableAdapters y CRMDataSet 178

189 Figura Diagrama de Clases. Paquete dao I 179

190 Figura Diagrama de Clases. Paquete dao II 180

191 Figura Diagrama de Clases. Paquete dao III 181

192 Figura Diagrama de Clases. Paquete dao IV 182

193 6.3.2 SubSistema EvoAgentServer Paquete EvoAgentServer.services El subsistema EvoAgentServer posee las clases correspondientes a los Servicios Web, Cada método reflejado en los Servicios se corresponde con un WebMethod a los que se puede llamar desde los clientes de los servicios. Como ya se ha explicado en anteriores apartados hay dos servicios, uno para la comunicación con el subsistema EvoAgentService y otro para la comunicación con el sistema EvoAgentManager. 183

194 Figura Diagrama de Clases. Paquete EvoAgentServer.services Paquete ProgramaciónTareas.exe El modulo de registro de tareas programadas no se correspondería con el subsistema EvoAgentManager, pero al estar ubicado en la carpeta tareas programadas del servidor se incluye aquí. Se trata de una aplicación para consola que contiene el método main más algún método auxiliar en la clase primaria de todo proyecto: Figura Diagrama de Clases. Paquete ProgramacionTareas.exe SubSistema EvoAgentManager Paquete EvoAgentManager.iu Este paquete se corresponde con la interfaz de usuario para los técnicos de Evotec. Las clases se diseñaron con el editor Visual Studio 2005 tal y como se han ido presentado en el punto 6.1 Diseño de la Interfaz de Usuario. 184

195 Figura Diagrama de Clases. Paquete EvoAgentManager.iu I Como se puede ver en la figura 6.134, existirá relación entre las ventanas (clases) que se pueden mostrar a partir de la ventana principal (Form_Main). Esto se hace así para acceder sólo una vez a cada ventana. Si una ventana está abierta (un objeto instanciado), no se creará una nueva instancia, sino que se traerá la ventana abierta a primer plano. Por otro lado siempre que se hace referencia a las ventanas se hace directamente a la propiedad Default que devuelve la instancia activa de la clase en ese momento o una nueva instancia si no la hubiera (Patrón Singleton). Los campos de las clases son cada componente de Windows.Forms que se han implementado en la ventana y que se ven mejor desde el diseño de interfaz, además de campos auxiliares que se utilizarían para la gestión de los datos que manejan las ventanas y de los eventos que disparan, que serían los métodos descritos mediante los diagramas de secuencia. Figura Diagrama de Clases. Paquete iu II 185

196 Figura Diagrama de Clases. Paquete EvoAgentManager.iu III 186

197 6.3.4 SubSistema EvoAgentService Paquete EvoAgent Aquí se presentan las clases que utiliza el Servicio de Windows. Figura Diagrama de Clases. Paquete EvoAgentService.EvoAgent I 187

198 Figura Diagrama de Clases. Paquete EvoAgentService.EvoAgent II 188

199 Paquete EvoIcon El módulo EvoIcon debe presentar una clase NotifyIcon que es el Icono que aparece en la barra de tareas. Dicha clase debe aociarse con una clase Form que lo contenga y controle el Menú que ambas comparten y los eventos que produce el mismo. La clase Form permanecerá invisible de forma que sólo se vea el Icono (Icon) de la clase NotifyIcon. Figura Diagrama de Clases. Paquete EvoAgentService.EvoIcon 189

200 7. Implementación del sistema, Pruebas e Instalación 7.1 Implementación de la base de datos Como se ha visto en el apartado 6.2 Diseño del modelo de datos, se ha creado la base de datos en el Sistema Gestor SQL Server Express, versión gratuita de SQL Server, en el entorno de desarrollo. Asimismo se ha asegurado el acceso a la misma por parte de los usuarios del dominio mediante autenticación de Windows y por parte del servicio web mediante el uso de autenticación SQL. Se ha abilitado el acceso externo al servidor de bases de datos para poder afrontar las pruebas desde el resto de la red de la empresa. Por último se ha implementado la lógica de acceso a datos en la librería EvoAgentLibrary. Se han creado los dataset y las clases de gestión de acceso en el fichero dao.cs que se verá en el siguiente punto. Para la lógica de acceso a datos se debe disponer del paquete Dominio ya implementado pues la lógica de acceso a datos traduce objetos del dominio del sistema en objetos del dominio del sistema gestor de base de datos. En este apartado se valida la prueba de integración de repositorio central de datos, definida en el apartado apartado Construcción del sistema En este apartado se procede a desarrollar el código de las aplicaciones que conforman el sistema. La codificación se realizará siguiendo los modelos obtenidos en las etapas de diseño anteriores, e implementarán fielmente las clases con los métodos y atributos descritos en ellos. El entorno de desarrollo es Visual Studio como ya se ha comentado anteriormente. Se crearán 2 soluciones que recogen toda la funcionalidad de las aplicaciones del sistema. Una solución estará orientada al desarrollo de la aplicación agente, EvoAgentService y otra al desarrollo de la librería, EvoAgentLibrary, donde ya se ha creado los paquetes dao y dominio como se vió en el apartado anterior, los servicios del servidor, EvoAgentServer, y las aplicaciónes de gestión, EvoAgentManager y de intérprete de programación de tareas, ProgramacionTareas.exe. Para el desarrollo del módulo EvoAgentServer, aplicación web del sistema y su publicación en el entorno de desarrollo, se ha instalado el servidor IIS 7.0 donde se ha creado un sitio web: 190

201 Figura 7.1 IIS del entorno de desarrollo Así pues, se dispone de la base de datos, el servidor web configurado, se ha iniciado el código donde se dispone del dominio, del acceso a datos y de los proyectos creados donde desarrollar cada subsistema. A continuación se muestra el directorio físico de trabajo, EvoAgentProyect y la estructura de las soluciones y proyectos, fiel al diseño del proyecto: Figura 7.2 Directorio de trabajo EvoAgentProyect 191

202 EvoAgentService Figura 7.3 Estructura del proyecto EvoAgentService La solución EvoAgentService posee 3 proyectos, EvoAgent, EvoIcon y EvoAgentSetup y tienen las clases con los métodos indicados en los respectivos apartados del diseño interno del sistema (Ver apartado Subsistema EvoAgentService para el diagrama de clases y Subsistema EvoAgentService e interacción con el servidor para el diseño de la funcionalidad). El primero, EvoAgent, corresponde al servicio de Windows, el segundo, EvoIcon, a la aplicación que carga el icono el la barra de tareas y el tercero es el instalador del subsistema. Dicho instalador, gestionado por el servicio Windows Instaler, crea un paquete.msi con los componentes del subsistema. 192

203 EvoAgentProyect Figura 7.4 Estructura del proyecto EvoAgentProyect La solución EvoAgentProyect posee 6 proyectos de los cuales se va a exponer la estructura de los tres primeros. EvoAgentLibrary es la librería de la aplicación. En el apartado se explica el contenido de cada paquete de clases. Se puede ver el paquete DAO que se corresponde con la lógica de acceso a datos. En el paquete Dominio se ven las clases definidas en el dominio del sistema así como el directorio WinAudit que contiene las clases del paquete winaudit. Por otro lado sin empaquetar se encuentran las clases de apoyo a la lógica de negocio pertenecientes al paquete EvoAgentLibrary.Services. Por último se verán en la carpeta References la referencia a la librería TaskScheduler.dll y en la carpeta Web References la referencia al servicio web ControlAdmin. EvoAgentManager es la aplicación de gestión y posee la interfaz de usuario. Todas las clases que posee pertenecen al paquete iu. En la carpeta References se podrá ver la referencia a la librería EvoAgentLibrary. EvoAgentServer es la aplicación basada en servicios web que se aloja en el IIS. Posee la estructura vista en el apartado 5.1 arquitectura del sistema. Servidor de la aplicación Los servicios se pueden crear en este directorio y utilizar la herramienta de publicación para alojarlos en el directorio virtual utilizado por el sitio web del IIS. Dicha herramienta genera una solución de la aplicación produciendo el código que actúa por detrás de los servicios web. El funcionamiento del codebehind se ve en el Anexo 3. La aplicación contiene un ficher de configuración del sitio web denominado web.config que establece parámetros de la aplicación así como el método de autenticación requerido. El proyecto ProgramacionTareas es una aplicación de consola y posee la clase que se ha explicado en el apartado Dicha clase implementa la funcionalidad expuesta en el apartado Los proyectos restantes se corresponden con los instaladores de la aplicación de gestión EvoAgentManager, y la aplicación de consolo ProgramacionTareas, respectivamente. 193

204 Figura 7.5 Estructura de los proyectos EvoAgentLibrary, EvoAgentManager y EvoAgentServer 7.3 Pruebas Las pruebas pretenden garantizar que el producto desarrollado cumple con los requerimientos inicialmente registrados, es decir, que se trata de un desarrollo de calidad. Por otro lado debe garantizarse el correcto funcionamiento del sistema. A la par que se ha ido construyendo el sistema se han podido ir realizando las pruebas unitarias para poder comprobar que las partes del sistema son correctas. Una vez construído se puede traspasar el sistema a un entorno de prueba donde puedan realizarse las pruebas de integración definidas en el apartado Así, queda validado el desempeño, por parte del sistema, de los requerimientos (Look & Feel), la autenticación 194

205 única de usuarios tal y como se había diseñado en el apartado y la administración de los mismos en el apartado También se valida la operación en ambiente integrado y la integración funcional, identificando los procesos de interacción entre las aplicaciones. Algunas interacciones han sido validadas en las pruebas unitarias como la interacción entre los agentes y el sistema operativo para la ejecución de tareas. Las interacciones identificadas son: Interacción entre agentes y servidor: Por parte de los agentes se ha implementado una clase, llamada ComunicaciónServidor que comprende las transacciones que se realizan entre el agente y el servidor que en cualquier caso se ejecutan con el proceso EvoAgentService, servicio de Windows. El servidor tiene dos claros puntos de acceso que son los servicios web. Interacción entre el servidor y la base de datos y entre la aplicación de gestión y la base de datos: Interactúan a traves de los adaptadores creados en las clases dataset tal y como se ha explicado en el apartado Interacción entre el servidor y el sistema CRM: Esta interacción se realiza a través de la clase AlertaDAO ubicada en el archivo Dao.cs del paquete EvoAgentLibrary.Dao. Interacción entre la aplicación de gestión y el servidor: Se realiza a través de la capa de acceso a datos de la librería (archivo Dao.cs del paquete EvoAgentLibrary.Dao) en los métodos que se han definido a tal efecto en las distintas clases. Dichos métodos utilizan la referencia web de la librería. Como ejemplo se puede ver lo diseñado para obtener las auditorías del servidor en el apartado , que utiliza la clase DetalleAuditoríaDAO para interacctuar con el servidor y obtener los ficheros xml de las auditorías mediante el método getauditorias(maquina). Interacción entre el sistema de gestión y el Task Scheduler del servidor: Se realiza dicha interacción utilizando la librería TaskScheduler referenciada en EvoAgentLibrary. Es utilizada desde la clase TareaProgramadaDAO perteneciente al archivo Dao.cs del paquete EvoAgentLibrary.Dao. Interacción entre agente y la aplicación WinAudit: Para realizar diversas tareas el agente debe interactuar con el sistema operativo. Se realiza mediante la clase Process definida en el namespace System.Diagnostics. En cualquier caso, se realiza la interacción desde el mismo proceso EvoAgentService, servicio de Windows. La clase Process arranca un proceso dependiente del servicio. Por último, se valida que el instalador del agente funcione correctamente actualizando la versión de las dos aplicaciones que comprende, el servicio de Windows y la aplicación EvoIcon del icono. También es necesario probar que el sistema posee la seguridad requerida, y el volumen de carga que puede soportar. 195

206 Una vez se han llevado a cabo las pruebas funcionales se puede proceder a pasar el sistema a un entorno de producción. En realidad parte de las pruebas funcionales se ralizan directamente sobre el entorno de producción. Para probar la interacción se debe probar directamente sobre este entorno que es el que se va a utilizar. 7.4 Implantación en el entorno de producción En este apartado se incluye un manual de instalación del sistema en producción. Para la puesta en marcha se debe establecer primeramente, tal y como se ha visto a la hora de desarrollar, los servicios del servidor y la base de datos y verificar que el acceso a los mismos es correcto. Servidor Se ha creado un directorio virtual en el sitio web del servidor de la empresa donde se ha publicado la aplicación EvoAgentServer. Para la publicación de los servicios desde el IIS se ha creado un nombre de host nuevo en el servicio DNS. En este punto es necesario hacer una breve introducción a los CNAME s. Consultar el Anexo1. Tecnologías Se ha registrado un CNAME con el nombre evoagentserver que será copiado en los DNS de los clientes. Así, el agente accederá mediante la ruta que se indique a través del CNAME. Esto hace que la hubicación de los servicios del servidor sea dinámica. La ruta por defecto es evoagentserver.evotec.es que se corresponde con el subdominio evoagentserver del dominio evotec.es. Posteriormente se debe referenciar el directorio virtual donde se ha publicado la aplicación EvoAgentServer. La ruta completa queda como sigue: después seria necesario indicar el recurso al que se quiere acceder, es decir, el servicio web, que para el caso de los agentes estaría ubicado en el directorio ControlClientes y para el caso de los técnicos en el directorio AdminManager. Esa es la ruta a la que intentarán conectarse si al utilizar el CNAME no obtiene resultado. La utilización del cname sería sustituir evoagentserver.evotec.es por evoagentserver. La instalación de los servicios se realiza mediante el Visual Studio. En el proyecto EvoAgentProyect se debe hacer clic en el botón derecho del ratón sobre el proyecto EvoAgentServer y pulsar publicar. Se deberá facilitar la ruta del directorio virtual. Base de datos La base de datos se agrega al servidor SQL Server a traves de la herramienta SQL Management Studio. Se puede realizar esta acción mediante un fichero de backup (.bak) o un ficher de datos (.mdf) y logs (.ldf). El fichero de backup se crea desde la aplicación SQL Management Studio con el servidor de base de datos donde reside la base de datos conectado. Hacer clic en el botón derecho del ratón sobre la base de datos y pulsar en Tareas/Copia de seguridad: 196

207 Figura 7.6 Creación de copia de seguridad (fichero.bak) de la base de datos Se abrirá la ventana de la figura 7.7 donde se deberá especificar el tipo de copia de seguridad, completa o diferencial, el nombre de la misma y el lugar donde se creará. 197

208 Figura 7.7 Configuración de la copia de seguridad de la base de datos Por otro lado, el archivo de datos y del log reside en el directorio c:\archivos de Programa\Microsoft SQL Server\MSSQL.1\MSSQL\Data Para acceder a la base de datos se debe crear una conexión como se ha explicado en el apartado Agente La instalación del agente consiste en la ejecución del fichero.msi generado por el proyecto EvoAgentSetup. Se puede acceder al fichero desde el directorio de trabajo: EvoAgentProyect\EvoAgentService\EvoAgentSetup\Debug\ EvoAgentSetup.msi 198

209 El instalador no requiere de interacción con el usuario. Se puede instalar en todas las máquinas de un cliente mediante una directiva de grupo. Para conocer más acerca de ésta técnica se puede visitar la siguiente página web: ProgramacionTareas La aplicación de consola debe residir en la carpeta Programacion Tareas del directorio AdminManager del servidor. Se debe realizar la instalación mediante el fichero.msi creado por el proyecto ProgramacionTareasSetup accesible desde el directorio de trabajo: EvoAgentProyect\ProgramacionTareas.exe\ProgramacionTareasSetup\Debug\ ProgramacionTareasSetup.msi Se deberá indicar la ruta de la carpeta en el proceso de instalación. Aplicación de gestión En los equipos de los técnicos se instala mediante el correspondiente fichero.msi la aplicación EvoAgentManager. El fichero reside en el directorio de trabajo: EvoAgentProyect\EvoAgentManager\ EvoAgentManager\EvoAgentManagerSetup\Debug\EvoAgentManagerSetup.msi El instalador no require de interacción con el usario. 7.4 Manual de Usuario y de Explotación Para la explotación del sistema desarrollado e instalado, además de disponer del código fuente en el directorio de trabajo, se requiere disponer del presente documento, memoria del proyecto, y de dos documentos más: Manual de Usuario: El manual de usuario comprende el uso de la aplicación de gestión en todas las funcionalidades que se han visto durante el diseño. Manual de Explotación: Va más allá del mero uso de la aplicación. Pretende facilitar los conocimientos para posibles evoluciones del sistema y su mantenimiento. Ambos documentos son documentos anexos a la memoria: Anexo 1. Manual de Usuario Anexo 2. Manual de Explotación 199

210 8. Planificación y Presupuesto 8.1 Planificación La planificación de un proyecto es un aspecto fundamental que puede reducir considerablemente el tiempo y el esfuerzo dedicado al mismo por parte de sus integrantes. La planificación debe ser coherente y para ello se debe tener un conocimiento previo de la complejidad del proyecto y de su alcance. En cualquier caso, las fases o tareas que deben planificarse se corresponderán con el modelo de metodología de desarrollo escogido Tareas o Fases del proyecto Las tareas que comprende el proyecto son las siguientes: 1. Estudio de las tecnologías y herramientas a utilizar, tanto las Aplicaciones software Libre como tecnologías como los Servicio de Windows, las comunicaciones, el Servidor Web y los Servicios Web así como el sistema gestor Sql Server y los accesos a datos. 2. Análisis de requerimientos mediante el Modelo de dominio y los Casos de uso. 3. Diseño Externo con el Modelo de Arquitectura y el Modelo de Paquetes. 4. Diseño Interno con el Modelo de Interfaz, los Diagramas de Interacción, los Diagramas de Clases y el Modelo de datos. 5. Implementación y Pruebas que comprende las tareas: 1. Programación. 2. Pruebas unitarias. 3. Pruebas de integración. 6. Instalación y Puesta en Marcha. 7. Documentación 200

211 8.1.2 Planificación Inicial La planificación inicial del proyecto era la siguiente: Figura 8.1 Planificación inicial del proyecto Según esta planificación se pretendía comenzar con el desarrollo del sistema en Febrero de 2007 toda vez que se hubiera realizado previamente las fases de análisis y diseño. Dicho desarrollo debería haber finalizado a principios de Mayo de 2007 momento en el que se iniciarian las pruebas para, en Junio de 2007, realizar la instalación del sistema. La documentación, por otro lado, se cumplimentaría al acabar cada fase. Es, sin duda, una planificación ideal, pues el plazo del proyecto debe coincidir con la finalización del curso, es decir, en Junio o en cualquier caso, en Septiembre. Además, las fases de ejecución del proyecto según la metodología son adecuadas al tipo de proyecto. 201

212 8.1.3 Evolución Real del Proyecto El proyecto se ha construido siguiendo el esquema de tiempo del diagrama de Grantt de la figura: Figura 8.2 Evolución real del proyecto 202

213 8.1.4 Conclusiones de la planificación En la evolución del proyecto se puede observar ciertas discrepancias respecto a la planificación inicial. El análisis de requerimientos tiene lugar en tres ocasiones a lo largo del proyecto, lo cual deja entrever que no se realizó con precisión en el momento en que estaba planificado. En esta línea cabe añadir un apunte en cuanto al análisis de requisitos. Es fundamental, a la hora de afrontar un proyecto de estas características, definir perfectamente el alcance del sistema de forma que sea validado por los usuarios finales con el fin de que se establezcan exactamente las funcionalidades que cubrirá el sistema y las que se deberá verificar una vez construido para comprobar la calidad del mismo. A tal efecto, se podría agregar una tarea a la hora de realizar el análisis de requesitos que consistiera en el desarrollo de los funcionales donde se definiría las operaciones desde el punto de vista funcional sin entrar en lo técnico. Esto último pretende fijar un alcance al proyecto sin afectar esto a que el diseño y desarrollo del proyecto permita agregar funcionalidad sin demasiada dificultad, es decir, a que se construya un sistema modularizable y escalable. El desarrollo llevó más tiempo del primeramente esperado. A principios de Mayo no se había completado más de los tres cuartos del desarrollo sin haber realizado las pruebas unitarias correspondientes ni comenzado las pruebas de integración. Esto hizo que la fecha de fin de proyecto se traspasara a Septiembre. Sin duda, una de las causas más probables de este retraso fue un diseño del sistema pobre, del que no se pudo sacar provecho a la hora de realizar la programación. El diseño implica conocer el sistema a construir de forma modularizada, entendiendolo de una forma global y cada módulo en profundidad. Esto permite afrontar el desarrollo con una idea mucho más clara de lo que se va a hacer y de cómo se va ha hacer, ayudando a reducir el código y a hacerlo más compacto y flexible y, con toda seguridad, a reducir considerablemente el tiempo dedicado al mismo. Finalmente, la documentación del proyecto no se realizó durante la ejecución de cada tarea, debido entre otras cosas, a que no se disponía del personal disponible necesario para realizar la tarea de documentación mientras se realizaban el resto de tareas. Por otro lado, no se dió la importancia necesaria a la documentación la cual, realizándola a conciencia, resulta fundamental a la hora de plasmar las tareas previas al desarrollo esto es, el análisis de requisitos y el diseño, como finalmente se ha visto en este proyecto. 203

214 Esto, unido al tardío comienzo de las pruebas de integración, provocó que el proyecto no pudiera terminarse en la ficha de fin del proyecto, Septiembre de 2007, teniendo que recurrir a una prórroga. En Octubre, una vez iniciada la prórroga de un curso lectivo, y con el proyecto en sus fases finales, con la documentación prácticamente terminada, salieron claramente a la luz los hechos que se han expuesto anteriormente. Con esto, se observó que no se habían seguido los pasos necesarios para garantizar un desarrollo de calidad. Por otro lado, como se ve en la evolución del proyecto, fue en Octubre cuando se adquirieron nuevos conocimientos para el diseño y desarrollo de un proyecto basados en los entornos de desarrollo que se estaban utilizando. Al tener el tiempo de la prórroga disponible y, tras todo lo anterior se planteó afrontar de nuevo el proyecto, apoyándose en la idea que se tenía ya del mismo y en muchos de los algoritmos, parte del código ya desarrollado y de la documentación ya realizada. Se puso como fecha de fin del proyecto Febrero de El proyecto, a día de hoy, 1 de febrero de 2008, está implantado en la empresa y realizándose las pruebas de integración con ciertas garantías de que se ha desarrollado un sistema de calidad. Es bien conocido que en todo proyecto ocurren circunstancias que hacen que el proyecto no vaya bien. En este caso, sin duda, se pueden atribuir a la falta de experiencia del responsable del mismo además de tratarse de un proyecto muy ambicioso. Sin embargo, lo más importante es la reflexión llevada a cabo para sacar a la luz los hechos que hicieron que el proyecto no prosperara según lo esperado. En este proyecto se ha visto que el hecho de que no pudiera resolverse en el tiempo previsto no se quedó en un simple retraso, sino que derivó en la evolución del sistema desarrollado hacia una cuota mucho mayor de calidad, además de que proporcionó nuevos conocimientos, incluida la propia experiencia, por parte del responsable del proyecto. 204

215 8.2 Presupuesto Se debe tener en cuenta dos aspectos para obtener el presupuesto del proyecto: Por un lado la valoración económica del esfuerzo de los integrantes del proyecto y por otro lado, el coste de las herramientas, ya sea software o hardware, que se necesitan a la hora de desarrollar y de implemetar el proyecto. La siguiente tabla resume el Coste del Proyecto: IMPORTE Herramientas 8.326,82 Servicio ,00 TOTAL ,82 Figura 8.3 Presupuesto del proyecto Dicho coste sería aplicable a una empresa de servicios informáticos que quisiera desarrollar e implantar el proyecto de cero incluyendo las herramientas necesarias para ello. En el caso actual, no sería necesario incluir nada dentro del apartado Herramientas. A continuación se detalla cada uno de los elementos: Valoración económica del esfuerzo de los integrantes en el proyecto Para obtener una valoración económica realista de los esfuerzos dedicados por los integrantes atendiendo también a las diferencias en cuanto a la retribución que recibe cada uno de ellos se debe tener en cuenta tres roles diferentes, jefe de proyecto, analistadiseñador, y programador, que han sido llevados a cabo por la misma persona. La retribución monetaria estimada por rol desempeñado es la siguiente: Jefe de proyecto: 85 /hora. Analista-Diseñador: 55 /hora. Programador: 40 /hora. Para el cálculo se han considereado dos periodos distintos. Esto se ha hecho así porque se produjo un cambio de la jornada laboral y del tiempo de la misma dedicado al proyecto. 205

216 Periodo 1: El primer periodo va desde el comienzo del proyecto, en Septiembre de 2006 hasta la fecha fín inscrita por la universidad, Septiembre de 2007, es decir, un año. Se ha considerado una media de 10 horas semanales de las 20 de jornada laboral dedicadas al proyecto dutante las aproximadamente 50 semanas del periodo establecido. Esto hace un total de 500 horas plenamente dedicadas al proyecto en el primer periodo. Periodo 2: El segundo periodo va desde Octubre de 2007 hasta la fecha fin del proyecto, Febrero de Se ha considerado una media de 35 horas de las 40 de jornada laboral dedicadas al proyecto durante las 20 semanas del periodo establecido. Esto hace un total de 700 horas plenamente dedicadas al proyecto. En resumen se han dedicado 1200 horas en el presente proyecto repartidas entre todas las tareas. En la siguiente tabla se resume las horas dedicadas a cada actividad: ACTIVIDAD PERIODO PERIODO TOTAL 1 2 INICIO DEL PROYECTO ESTUDIO DE LAS TECNOLOGÍAS ANÁLISIS DE REQUERIMIENTOS ESTUDIO DE TÉCNICAS DE DISEÑO Y PRG DISEÑO EXTERNO DISEÑO INTERNO DESARROLLO PRUEBAS UNITARIAS PRUEBAS INTEGRACIÓN IMPLANTACIÓN DOCUMENTACIÓN CIERRE PROYECTO TOTALES Figura 8.4 Horas dedicadas a las actividades. La tabla anterior es el resultado de unir las dos tablas siguientes donde se desglosan las horas dedicadas a las actividades durante cada uno de los periodos: 206

217 Actividad/Periodo (horas) ACTIVIDAD sep, oct y nov 06 PERIODO I dic 06, ene y feb 07 mar, abr y may 07 jun, jul,ago y sep 07 TOTAL Inicio del Proyecto 3 3 Estudio de las Tecnologías Análisis de Requerimientos Estudio de técnicas de 0 diseño y prog. Diseño Externo Diseño Interno Desarrollo Pruebas Unitarias Pruebas Integración Implantación 0 Documentación Cierre del Proyecto 0 TOTALES Figura 8.5 Horas dedicadas a las actividades durante el Periodo 1 PERIODO II Actividad/Periodo (horas) ACTIVIDAD oct-07 nov-07 dic-07 ene-08 feb-08 TOTAL Inicio del Proyecto 0 Estudio de las Tecnologías 0 Análisis de Requerimientos Estudio de técnicas de diseño y prog. Diseño Externo Diseño Interno Desarrollo Pruebas Unitarias Pruebas Integración Implantación Documentación Cierre del Proyecto 3 3 TOTALES Figura 8.6 Horas dedicadas a las actividades durante el Periodo 2 Atendiendo a los roles participantes de cada tarea y, en función de la retribución establecida para cada rol, se obtiene la siguiente tabla que indica la voloración económica de cada rol integrante en el proyecto y de las tareas realizadas: 207

218 PARTICIPANTES JEFE ANALISTA- PROGRAMADOR PROYECTO DISEÑADOR ACTIVIDAD Per H h h h TOTAL Inicio del Proyecto Estudio de las Tecnologías Análisis de Requerimientos Estudio técnicas de diseño y prog. Diseño Externo Diseño Interno Desarrollo Pruebas Unitarias Pruebas Integración Implantación Documentación Cierre del Proyecto I II I II I II I II I II I II I II I II I II I II I II I II TOTALES Figura 8.7 Estimación del esfuerzo de los integrantes del proyecto y valoración económica Coste de las herramientas software y hardware El coste de las herramientas tanto de software como de hardware es cero por proveer la empresa de todo lo necesario. No obstante, aquí se refleja las herramientas que serían necesarias para llevar a cabo el proyecto y para implantarlo en un entorno de producción y se añade el coste que supondría dichas herramientas. Entorno de Producción HERRAMIENTAS IMPORTE SOFTWARE 1.019,00 HARDWARE 570,00 Entorno de Desarrollo SOFTWARE 5.071,08 HARDWARE 1.686,74 TOTAL 8.326, 82 Figura 8.8 Estimación del coste de las herramientas necesarias para el desarrollo e implantación del proyecto. Entorno de desarrollo: En el entorno de desarrollo se requerirína las siguientes herramientas: 208

219 1. Software: Visual Studio 2005: Se requeriría de una licencia del programa Visual Studio. Visual Studio 2005 Professional Edition con suscripción MSDN Professional: 1019 Sql Server: Como la versión gratuita, SQL Express, dispone de 2 GB de memoria, se considera suficiente para poder utilizarla en el entorno de desarrollo el coste es 0. Sql Server Management Studio Express: Programa interfaz de gestor de base de datos gratuito. 0. Sistema Operativo: Windows Vista Business. Incluído con el hardware. Servicios de Internet Information Server: Viene incluído dentro del sistema operativo. Microsoft CRM 3.0: Se puede acudir al mismo sistema implantado en el entorno de Producción. Total Software: Hardware: Puesto de trabajo. Se requiere de un PC de sobremesa. Existe gran variedad de posibilidades. Se ha escogido el que se ha utilizado en el puesto de trabajo para el desarrollo: Precio: 570 con IVA. Total Presupuesto entorno de desarrollo =

220 Entorno de producción: En el entorno de producción se requerirína las siguientes herramientas: 1. Software: Sistema Operativo: Microsoft Windows Server 2003 R2, Enterprise Edition with 25 Client Licenses. Precio: 2.669,00 Microsoft CRM 3.0: Viene incluído con la licencia del sistema operativo. 0. Microsoft Sql Server Estándar Edition: 1 licencia, Precio 1.030,96 Servicios de Internet: Se requiere tener un dominio de Internet operativo para las conexiones desde las máquinas cliente. El coste del registro viene a ser de 72,12 (IVA incluido). Esta tasa permite mantener el dominio durante 1 año natural. SSL: Se requiere de seguridad en las comunicaciones entre los clientes y el servidor. Para ello se puede adquirir certificados de SSL (Socket Secure Layer). Se puede adquirir por varios proveedores. Por ejemplo: Verisign: Certificado de SSL 128 bits por 1 año: Total Software: 5071, Hardware: Servidor: Como ejemplo se pondrá un servidor asequible para una pequeña o mediana empresa 210

221 Características: Factor de forma Torre o montaje en rack 5U Procesadores Hasta dos procesadores Intel Xeon con Tecnología de 64 bits de memoria ampliada Intel de hasta 3,6 GHz Bus frontal 800 MHz Caché 1 MB L2 Chipset Intel E7250 Memoria 256 MB / 12 GB DDR2 400 SDRAM; 8 GB 12 GB con disponibilidad de rack único de 2 GB DIMMS1 Canales de E/S Siete en total: dos ranuras PCI Express (1 x 4 vías y 1 x 8 vías); cuatro ranuras PCI-X (64 bits / 100 MHz); una ranura PCI (32 bits / 33 MHz, 5v) Controlador de unidad Canal doble incorporado Ultra320 SCSI Controlador RAID Canal doble ROMB opcional (PERC4/Di), PERC4/DC y PERC4e/DC2 Unidades de disco Ocho unidades de 1 + Dos unidades de 1 SCSI Ultra320 de conexión en caliente con soporte de unidad de cinta interna Almacenamiento interno máximo Hasta 1,46 TB o hasta 3 TB con disponibilidad de unidad de disco duro de 300 GB Unidades de disco duro 36 GB, 73 GB, 146 GB y 300 GB2 ( rpm) Ultra320 SCSI 18 GB, 36 GB, 73 GB y 146 GB2 ( rpm) Ultra320 SCSI Almacenamiento interno Unidades de 10 K / 15 K RPM SCSI Almacenamiento externo SCSI de PowerVault de Dell y almacenamiento de canal de fibra de Dell/EMC Opciones de copia de seguridad Interno: PowerVault 100T y 110T en cinta Externo: PowerVault 114T, 122T, 132T, 136T y 160T Tarjeta de interfaz de red Incorporado doble Intel 10/100/1000 Gigabit NIC; Intel PRO/1000 MT Gigabit NIC (cobre), Intel PRO/1000 MF Gigabit NIC (fibra) Fuente de alimentación 930 W, alimentación redundante de conexión en caliente opcional Disponibilidad Memoria ECC, ranuras PCI Express de conexión en caliente,corrección de datos de dispositivo simple (SDDC), banco de memoria de reserva, memoria duplicada; unidades de disco duro SCSI de conexión en caliente; alimentación redundante de conexión en caliente opcional; refrigeración redundante de conexión en caliente; chasis sin necesidad de herramientas; soporte de canal de fibra de alta disponibilidad y clúster SCSI; ROMB opcional con caché de desfase de 256 MB; parte posterior dividida opcional; panel LCD; Active ID Vídeo ATI Radeon 7000-M incorporado con SDRAM de 16 MB Gestión remota Controlador de gestión de placa base con soporte IPMI 1.5, accesible mediante red o puerto serie; DRAC4/I sin ranura opcional Gestión de sistemas OpenManage de Dell Soporte para rack 4 postes (rack Dell) y otros fabricantes Sistemas operativos Microsoft Windows 2000 Server, Microsoft Windows 2000 Advanced Server, Windows Server 2003 Standard Edition, Windows Server 2003 Enterprise Edition, Windows Server 2003 Small Business Premium Edition, Windows Server 2003 Small Business Standard Edition, Red Hat Linux Enterprise v2.1 AS y ES, Red Hat Linux Enterprise v3 AS y ES Red Hat Linux Enterprise v3, Advanced Server EM64T, Novell NetWare 5.1 y 6.5 Precio Aproximado: 1.686,7388 Total Presupuesto Entorno de Producción = 6757,82 Total Presupuesto Herramientas Software y Hardware: 8326,

222 9. Conclusiones y Evolución del Sistema 9.1 Conclusiones La elaboración de este proyecto ha servido para afianzar y poner en práctica muchos de los conocimientos aprendidos a lo largo de toda la carrera. Principalmente se han tratado aspectos de ingeniería del software en todas sus fases así como tratamiento de bases de datos, programación orientada a objetos en C# y aplicación de Algoritmia en muchos de los métodos. También se ha podido afianzar y desarrollar los conocimientos adquiridos en cuanto a planificación y gestión de proyectos. Por otro lado, se puede considerar que se han cumplido los objetivos propuestos antes de comenzarlo, desarrollando un sistema de calidad que cumple con todos los requesitos y, adquiriendo un gran conocimiento y familiarización no sólo con las últimas tecnologías en cuanto a desarrollo de software sino también con técnicas adecuadas de diseño y programación. Por último, el proyecto ha requerido más horas de las previamente previstas para el desarrollo y hay que hacer referencia al apartado Conclusiones de la Planificación donde se han expuesto las conclusiones de la planificación. 9.2 Evolución del Sistema El presente sistema construido, probado e implantado comprende la fase 0 del proyecto. Esto implica que el proyecto no tiene una fecha final propia sino que se trata de un sistema que estará en constante evolución, incrementando las funcionalidades. El sistema desarrollado permite una gran evolución del mismo en cuanto a las tareas que pueden realizar los agentes. Se pueden diseñar e implementar nuevas tareas y con tal fin se ha creado el documento de manual de explotación Anexo a este documento. Por otro lado, se podrían proponer nuevas fases en el proyecto como podría ser: Ampliación de la monitoriazación a sistemas con PC s que posean sistemas operativos de otros fabricantes. Como se ha podido ver a lo largo del presente documento, se ha enfocado la monitorización de sistemas a sistemas basados en Windows donde todos los ordenadores poseen un sistema opertativo de Windows. Se propone, por tanto, una evolución del sistema para poder monitorizar también PC s con sistema operativo Linux o MAC. Desarrollo de una extensión de la aplicación CRM de tal forma que permitar transladar la información que genera una alerta a un caso que se cree asociado a la misma, con el cual se trabaja. Esto sería util al disponer, por ejemplo, de la máquina y el cliente objeto de la alerta, así como la descripción de la misma en el caso sin 212

223 tener que pasar esta información a mano. (Ver apartado Interfaz CRM, crear caso vinculado a alerta). Esto se podría hacer mediante el uso de los Callouts del CRM. Esta tecnología permite agregar funcionalidad a eventos del CRM como el crear un caso. Sería necesario desarrollar un callout y asociarlo a dicho evento. El CRM de forma interna, al crear un caso nuevo, vería el callout declarado para tal evento mediante un fichero de configuración y lo ejecutaría. El callout debería controlar que la creación del caso provenga de una alerta, en cullo caso, se obtendría la información de la alerta via sql y se pasaría dicha información al caso vía CRMService. Modificación del subsistema de Tareas Programadas de forma que permitar diseñar tareas repetitivas a los usuarios técnicos. El problema del subsistema de Tareas Programadas es que al hacer uso de la herramienta Task Scheduler de Windows del servidor sólo los usuarios administradores tienen permiso para registrar tareas repetitivas. Además se crean tantos archivos de configuración de tareas como tareas repetitivas se creen. Se propone una evolución del sistema pasando por la inclusión de una tabla en la base de datos donde se registrarán las tareas repetitivas y el desarrollo de un servicio de Windows que, instalado en el servidor, se encargue de realizar la tarea del Task Scheduler. Así, una vez instalado el servicio, cualquier usuario del sistema podría crear una tarea repetitiva. Se podría mantener el diseño de la interfaz de gestión y creación de tareas programadas. 213

224 10. Bibliografía [BARR01] [ESQU05] [ROCA05] [CHAR02] [NAGE06] [SKIB06] [HOLM04] Barranco de Areba, Jesús, Metodología del análisis estructurado de sistemas, Publicaciones de la Universidad Pontificia Comillas, Madrid Esquivel, Juan Carlos, Apuntes Ingeniería del Software II, Universidad Pontificia Comillas, Madrid María José Roca, Pruebas de Integración de Productos: Un Enfoque Práctico. PaqueSoft, GreenSQA (Software Quality Assurance), Francisco Charte Ojeda, Visual C#.NET, Anaya Multimedia, Christian Nagel, Bill Evjen, Jay Glynn, Morgan Skinner, Karli Watson, Allen Jones. Profesional C# Wiley Publishing, Craig Skibo, Marc Young, Brian Johnson. Working with Microsoft Visual Studio Microsoft Press, Dan Holme y Orin Thomas, Managing and Maintaining a Microsoft WINDOWS SERVER 2003 ENVIRONMENT, McGraw- Hill / Interamericana de España S.A.U, Principales páginas web visitadas: ( MSDN Framework.NET Development Library ) ( Wikipedia ). ( WinAudit ). ( CodeProject ). ( UML ) Consultoría de Seguridad Creangel. ( Diagramas de Secuencia de UML ). ( Diagrama de Paquetes de UML ). ( Scripting ). 214

225 Anexo 1. Manual de Usuario Este anexo pretende servir de ayuda al usuario de la aplicación de gestión de EvoAgent. Dicha aplicación consta de 3 módulos entre los que se reparte toda la funcionalidad. Estos módulos son: Área de Trabajo: Permite gestionar la actividad de los agentes y visualizar información sobre los mismos. Settings: Permite gestionar parámetros de configuración de la aplicación. Se manejarán aspectos relevantes de la aplicación como el Control de Alertas, Gestión de Versiones de la aplicación de las máquinas cliente y actualización de usuarios de la aplicación. Referencias: Permite ver la descripción de la aplicación y acceder a la aplicación CRM. El módulo principal es el Área de Trabajo. Éste módulo comprende varias funcionalidades resumidas en los siguientes puntos: Tareas: Donde se trabajará con las tareas asignables a las máquinas cliente. Se podrá crear nuevas tareas, editarlas o borrarlas, ver el estado actual de tareas o gestionar las tareas programadas. Maquinas: Donde se podrá ver el detalle de las auditorías así como dar acceso a máquinas cliente al sistema. Clientes/Dominios: Donde se podrá asociar máquinas cliente con los clientes registrados en la aplicación de gestión CRM a través de los dominios. Logs: Donde se podrá monitorizar el correcto funcionamiento del sistema. Antes de empezar con la guía práctica en cada módulo cabe reseñar que el sistema está fuertemente vinculado con la aplicación de gestión CRM. Tanto es así que nuevos usuarios no podrán trabajar con esta aplicación de gestión de EvoAgent si no se dispone de la base de datos del CRM operativa. Esto es debido a que los usuarios permitidos registrados en esta aplicación han sido obtenidos de la base de datos del CRM y un nuevo usuario que quiera iniciar la aplicación deberá haber sido previamente registrado en el CRM y actualizados los usuarios de la aplicación como se verá en el módulo Settings. (Ver Settings de Ususarios) 215

226 También se ha incluido parte de la funcionalidad del sistema dentro de la interfaz del CRM. Las alertas generadas por el sistema en relación a las máquinas monitorizadas son expuestas en esta herramienta de gestión y por tanto se incluye dentro de este manual cómo acceder y trabajar con ellas. Al arrancar la aplicación, ésta obtiene automáticamente las credenciales de usuario introducidas por éste al iniciar sesión de Windows. Con estas credenciales se realiza una autenticación. Si son correctas se carga la ventana principal de la aplicación. Desde dicha ventana se puede acceder a los distintos módulos y funcionalidades. Figura A1.1 Ventana Principal de la Aplicación Tareas Este módulo permite gestionar las tareas a realizar por parte de las máquinas agente. Hay varias tareas definidas: Auditoria: Consiste en la ejecución del programa WinAudit ( Para su ejecución se requiere seleccionar los campos que se desean auditar. La ejecución del programa genera un informe completo de la máquina que monitoriza el agente, dicho informe es tratado por el sistema generando alertas ante estados definidos que se pueden configurar tal y como se muestra en el apartado Alertas (Alertas). La selección de campos (Auditoría) incluye por defecto aquellos campos que son examinados para la generación de alertas: el campo software instalado, drivers (discos lógicos), memoria, 216

227 errores del log y servicios de Windows. La visualización del resultado de la auditoría se puede contemplar en el apartado máquinas (Ver detalle). Diariamente se ha programado una tarea auditoria con los campos anteriormente señalados. Apagado: Se puede programar el apagado remoto de una máquina. A la hora señalada para el apagado se mostrará un mensaje al usuario del proceso de apagado iniciado, dejando 5 minutos para poder cerrar todas las aplicaciones. Figura A1.2 Ventana de Apagado Remoto 1 A dos minutos del apagado se volverá a mostrar un mensaje de aviso. Figura A1.3 Ventana de Apagado Remoto 2 Limpieza: Se trata de la ejecución del Limpiador de la aplicación Ccleaner. Inicio Servicio: Se puede iniciar un servicio indicando el nombre del servicio (Ver Inicio Servicio). Comprobar Cuotas: Se puede programar la comprobación de las cuotas de usuario en agentes servidores (Ver Comprobar Cuotas). 217

228 Desfragmentación de los discos duros: Se arranca el desfragmentador de Windows que analiza los discos duros e inicia la desfragmentación si fuese necesario. Ejecución de Scripts: Se trata de la ejecución de un archivo.vbs correspondiente a un script. Los agentes se comunican con el servidor cada hora. En esa comunicación recibe las tareas que tiene pendientes hasta la próxima comunicación. La última comunicación se puede observar en el log de acciones consultando las acciones del agente en cuestión (Ver Log Acciones) o en el apartado máquinas en el campo timestamp. Con ello se puede programar la tarea para un agente a la hora adecuada. Búsqueda Predefinida de tareas y nuevas búsquedas Al iniciar se carga las tareas que cumplan con los parámetros establecidos por defecto. Por defecto se cargan todas las tareas pendientes. Estos Parámetros son los que aparecen en la parte superior (Cliente, Maquina, Tarea, Estado) dentro de la caja Filtro de Búsqueda de Tareas. Se pueden modificar para obtener las tareas buscadas. Figura A1.4 Ventana Tareas 218

229 Nueva tarea Para asignar una nueva tarea se debe pulsar el botón NUEVA. Aparece una nueva ventana donde se deben establecer los atributos de la nueva tarea. Se pueden asignar varias o todas las tareas posibles a una máquina, las máquinas de un cliente o todas las máquinas registradas en la aplicación. Para ello hay habilitados tres despegables para clientes (Cliente), máquinas (Maquina) y tareas (Tarea) que aparecen y se ocultan al pulsar el botón que hay al final del cuadro de texto de cada respectivo apartado. Figura A1.5 Ventana de Edición de Tareas Selección del cliente Pulsar el botón cuadrado al final del cuadro de texto justo debajo de la etiqueta Cliente. Aparece un despegable con los clientes registrados en la aplicación. Si no aparece el cliente deseado: - El cliente debe haberse registrado previamente en el CRM. - Actualizar los clientes registrados desde el módulo Clientes. Selección de la máquina Una vez se selecciona un cliente, pulsando el botón de nuevo se cierra el despegable, en las máquinas disponibles en el despegable correspondiente aparecerán únicamente las máquinas correspondientes a ese cliente. 219

230 Selección de la tarea Se sigue el mismo procedimiento con el despegable de Tarea. Tras seleccionar las tareas deseadas y ocultarse el despegable, para ciertas tareas se pedirá al usuario que introduzca una especificación para la correcta ejecución de algunas de ellas en las máquinas agentes. Para pasar entre las distintas tareas con parámetros se pueden elegir en el despegable superior. Figura A1.6 Ventana Configuración de Parámetros para las tareas Auditoría Se deberá seleccionar los campos que se desea que se tengan en cuenta a la hora de auditar las máquinas. Por defecto aparecen seleccionados los campos que se incluyen en la auditoría para generar alertas. 220

231 Figura A1.7 Configuración de Parámetros para auditorías Los campos definidos se pueden volver a mostrar para modificarlos pulsando el botón EDITAR PARÁMETROS. Si se desea saber el contenido de esos campos se puede consultar la ayuda en el menú superior de la ventana principal de la nueva tarea. Figura A1.8 Ventana de edición de tareas Dichos campos vienen definidos en inglés en la página principal de la aplicación WinAudit. 221

232 Figura A1.9 Página de documentación de WinAudit Inicio de Servicio Se trata del arranque de un servicio de Windows. Aparece un cuadro de texto dentro del apartado Inicio Servicio en parámetros de Tareas donde se debe indicar el nombre del servicio de Windows que se desea iniciar. 222

233 Figura A1.10 Configuración de Parámetros para inicio de servicios Dicho nombre es el que aparece en las propiedades del servicio. Herramientas Administrativas/Servicios -> Botón derecho sobre un servicio + Propiedades Figura A1.11 Servicios de Windows 223

234 Figura A1.12 Propiedades de los Servicios de Windows Comprobar Cuotas Esta tarea analiza el tamaño de las cuotas de usuarios de un dominio en un servidor. Para ello accede a las rutas donde se almacenan los perfiles de los usuarios. Dichas rutas se deben indicar al menos la primera vez que se configura la tarea: 224

235 Figura A1.13 Configuración de Parámetros para la tarea Comprobar Cuotas Ejecutar Script Debe existir el fichero físico que contiene el script (fichero.vbs) y estar en una ruta accesible para los agentes. Se debe facilitar la ruta de donde descargar el fichero: Figura A1.14 Configuración de Parámetros para la tarea Ejecutar Script 225

236 Selección de Hora Por último se debe indicar una fecha, hora y minuto en la que se desea que la/s máquinas seleccionadas ejecuten la/s tareas seleccionadas. Finalizar Para registrar la/s nueva/s tarea/s pulsar Archivo+Guardar Cambios o bien Archivo+Guardar Cambios y Salir en el menú superior. Cada dupla máquina-tarea será tratada posteriormente como una tarea independiente. Figura A1.15 Ventana Tareas Evolución de las tareas Para obtener el estado actual de las tareas se puede pulsar el botón ACTUALIZAR. Al actualizar la lista se volverá a cargar las tareas en función de los parámetros del filtro. Editar tarea La edición de tareas sólo se permite hacer sobre tareas pendientes. Se debe seleccionar la tarea sobre la columna Sel y pulsar el botón editar. Al editar una tarea aparece la misma ventana que al realizar una nueva tarea pero con los atributos predefinidos de la tarea a editar. 226

237 Figura A1.16 Ventana de Edición de Tareas en modo Editar La edición de tareas permite modificar la hora de ejecución y los parámetros de la tarea si los tuviera. Eliminar tarea Se debe seleccionar la tarea sobre la columna Sel y pulsar el botón eliminar. Se pedirá confirmación: Figura A1.17 Confirmación de Eliminación de Tareas 227

238 Tareas Programadas Siendo un submódulo perteneciente a Tareas se ha presentado como un módulo más debido a la importancia en cuanto a funcionalidad que proporciona. En este submódulo se gestiona las tareas programadas de Windows asociadas a la aplicación de gestión de EvoAgent y que vienen a ser una repetición periódica de la creación de nuevas tareas de forma automatizada. Se puede acceder a un listado de las tareas programas o directamente a la creación de una nueva tarea. Este módulo interactúa con la herramienta de Tareas Programadas del servidor, con lo que si no se posee de una credencial válida no se podrá acceder y se mostrará un mensaje informando de dicha circunstancia. Figura A1.18 Credenciales no válidas 228

239 Crear Tarea Programada Se inicia una ventana para la configuración de una tarea programada de Windows que registre periódicamente una o varias tareas para las máquinas que se seleccionen. Figura A1.19 Ventana de Edición de tareas programadas Es necesario rellenar todos los datos de cada uno de los apartados del menú de la izquierda antes de proceder a guardar la tarea programada. No se deberá cerrar ninguna ventana, en caso de hacerlo se perderá la información introducida al tener que abrirla otra vez para finalizar la creación de la tarea. Para moverse entre las diferentes ventanas se puede pulsar los botones de la izquierda o sobre la forma que se quiera traer al frente. Configuración de las credenciales de ejecución de la tarea Es necesario establecer las credenciales bajo las cuales se ejecutará la tarea programada de Windows. Windows lanzará el programa especificado con la cuenta de usuario que se indica en esta ventana. 229

240 Figura A1.20 Ventana de Configuración de Credenciales de Tarea Programada Configuración de la Programación de la tarea Figura A1.21 Ventana de Configuración de la Programación de la Tarea Programada Hay que establecer la hora y minuto en que se quiere que las máquinas cliente seleccionadas ejecuten las tareas a programar, y la fecha de inicio de la tarea. Asimismo se puede seleccionar una fecha de finalización para la tarea programada. Posteriormente se debe seleccionar un tipo de programación entre los tres disponibles en el despegable Programar Tarea:. A continuación se explica cada uno de ellos. 230

241 Se debe elegir entre si se quiere ejecutar la tarea diaria, semanal o mensualmente. Cada una de las opciones lleva una caja donde se puede configurar varios aspectos de cada periodicidad: Programación Diaria Esta programación permite ejecutar tareas todos los días, los días laborables o siguiendo un intervalo (todos los lunes = cada 7 días empezando un lunes conocido mejor ver programación semanal). Nota Importante: La fecha de inicio debe ser la anterior ejecución a la que se quiere que sea la primera. Esto es debido a que el programa de registro automático de tareas seleccionará como fecha de las tareas la siguiente fecha al momento en que se ejecuta dicho programa. Por ejemplo: Si una tarea está programada para los días laborables y ahora es viernes, el programa registra las tareas seleccionadas para las máquinas seleccionadas para ejecutarse el lunes a esta misma hora. Si se quiere que una tarea se ejecute todos los lunes y es importante que empiece este mismo lunes, se deberá crear una tarea nueva adicional para el primer lunes. Figura A1.22 Ventana de Configuración de la Programación Diaria de la Tarea Programada 231

242 Programación Semanal Esta programación permite ejecutar tareas los días seleccionados de la semana junto con un intervalo de semanas definido. Si se deja en blanco el intervalo de semanas es lo mismo que seleccionar cada semana (cada 1 semana). Hay que establecer la hora y minuto en que se quiere que las máquinas cliente seleccionadas ejecuten las tareas seleccionadas, y la fecha de inicio de la tarea. Nota Importante: La fecha de inicio debe ser la anterior ejecución a la que se quiere que sea la primera. Esto es debido a que el programa de registro automático de tareas seleccionará como fecha de las tareas la siguiente fecha al momento en que se ejecuta dicho programa. Por ejemplo: Si una tarea está programada para los días laborables y ahora es viernes, el programa registra las tareas seleccionadas para las máquinas seleccionadas para ejecutarse el lunes a esta misma hora. Si se quiere que una tarea se ejecute todos los lunes y es importante que empiece este mismo lunes, se deberá crear una tarea nueva adicional para el primer lunes. Figura A1.23 Ventana de Configuración de la Programación Semanal de la Tarea Programada Programación Mensual 232

243 Esta programación permite ejecutar tareas el día seleccionado de los meses seleccionados. Si se selecciona Día x siendo x=31 se programará para el último día del mes que corresponda. Otra opción es programar para el último/primer/segundo día de la semana: Hay que establecer la hora y minuto en que se quiere que las máquinas cliente seleccionadas ejecuten las tareas seleccionadas, y la fecha de inicio de la tarea. Nota Importante: La fecha de inicio debe ser la anterior ejecución a la que se quiere que sea la primera. Esto es debido a que el programa de registro automático de tareas seleccionará como fecha de las tareas la siguiente fecha al momento en que se ejecuta dicho programa. Por ejemplo: Si una tarea está programada para el último viernes de cada mes y ahora es viernes, el programa registra las tareas seleccionadas para las máquinas seleccionadas para ejecutarse el último viernes del próximo mes a esta misma hora. Si se quiere que una tarea se ejecute todos los primeros lunes y es importante que empiece este mismo primer lunes, se deberá crear una tarea nueva adicional para el primer de los primeros lunes. Figura A1.24 Ventana de Configuración de la Programación Mensual de la Tarea Programada 233

244 Por último, el apartado de flags hace referencia a Las propiedades con las que se trabaja: o o o El inicio de la sesión en caso de estar cerrada, lo que no quiere decir que encienda el ordenador, con lo que es preferible configurar las tareas programadas en el servidor de evotec para asegurar que se ejecuten. Por defecto está activada. Eliminar la tarea si no está programada para ejecutarse de nuevo. No aporta mucho teniendo en cuenta que una tarea que no tenga fecha de fin de ejecución nunca dejará de estar programada para ejecutarse y que en cualquier caso se puede eliminar la tarea manualmente. Detener la tarea si se ejecuta durante x minutos. Puede ser útil cuando parezca que el proceso de registro de la tarea se haya quedado colgado. De establecerse es recomendable hacerlo con un valor alto o comprobar que establecido un tiempo se ejecuta sin problemas. Puede provocar que no se ejecuten las tareas. Configuración de Tareas y Máquinas Para indicarle a la tarea programada sobre qué máquinas se deben registrar las nuevas tareas y cuáles son estas tareas. Aparecerá la ventana de Nueva Tarea. Se trata del mismo proceso seguido para el registro de una nueva tarea (Ver Nueva Tarea) sólo que en este caso no es necesario especificar la fecha de realización. Figura A1.25 Ventana de Edición de Tareas en modo Programar Tarea Finalizar Pulsando GUARDAR en la ventana de creación de tarea programada se comienza el registro de la tarea programada en el sistema. 234

245 Configuración de la tarea en el Task Scheduler La tarea se registrará en el Task Scheduler de Windows del Servidor de Evotec. Aparte, la tarea programada hace referencia a un ejecutable por lotes del sistema (.bat) con el mismo nombre que ésta y que se registra en el espacio de direcciones donde reside el sitio Web EvoAgentServer en el Servidor de Evotec. Si no ha habido ningún error se cerrará la ventana sin más. Ver, Eliminar y Editar Tareas Programadas Para ver la lista de tareas programadas registradas se debe acceder desde el módulo tareas. Se abre una ventana con las tareas programadas que residan en el Servidor de Evotec (si se tiene acceso con la cuenta de usuario actual). Figura A1.26 Ventana Ver Tareas Programadas Desde esta ventana se puede Eliminar o modificar la tarea Programada y crear nuevas tareas programadas. Al eliminar se elimina tanto la tarea.job de Windows como los ficheros.bat y.xml que dan soporte a la tarea programada. Para modificar pulsar ABRIR PROPIEDADES. Se abrirá la ventana de creación de una tarea programada con la configuración de la tarea seleccionada desde donde se podrá modificar la configuración y guardar la nueva tarea programada. 235

246 Figura A1.27 Ventana de Edición de tareas programadas 236

247 Maquinas Este módulo permite controlar el acceso de las máquinas al sistema, ver cuándo fue la última comunicación o ver el detalle de las auditorías realizadas de las mismas. Asimismo permite configurar parámetros como la fragmentación automática o el tipo de Agente (Cliente/Servidor). Al cargarse se ha inicializado una lista con las máquinas registradas en la aplicación. Para mostrarlas se debe realizar una búsqueda. Búsqueda de máquinas Una vez cargado el módulo Máquinas se puede hacer búsquedas de máquinas de dos maneras: Por Cliente: Se debe seleccionar un cliente. Figura A1.28 Ventana de Máquinas Por Contenido: Introducir texto en el cuadro Maquina y buscar. La búsqueda se realiza por contenido en los campos Host y Dominio. Permitir o denegar permiso de acceso de máquinas al sistema Las máquinas cliente recién instaladas deben de ser permitidas por Evotec para poder comenzar a ser monitorizadas. Las máquinas ya habrán sido dadas de alta en el sistema. Una vez localizadas las máquinas seleccionar/deseleccionar sobre la columna permiso haciendo clic sobre el recuadro y pulsar el botón GUARDAR al final de la fila. 237

248 Establecer Tipo de Agente El tipo de maquina que monitoriza un agente viene definido por el campo Tipo Agente. Se configura de forma automática en función del nombre del host. No obstante se puede modificar su valor desde el módulo de máquinas. Se debe localizar las máquinas y abrir el despegable de la columna Tipo Agente. Seleccionar el tipo deseado y pulsar el botón GUARDAR al final de la fila. Establecer Auto-desfragmentación El agente puede ordenar la desfragmentación automática de los discos de la máquina que monitoriza en caso de que esté configurado para ello. Esto se puede establecer desde el módulo de máquinas. Viene definido por el campo Dfrag. Se configura de forma automática en función del nombre del host. No obstante se puede modificar su valor. Se debe localizar las máquinas y seleccionar/deseleccionar sobre la columna fragmentar haciendo clic sobre el recuadro y pulsar el botón GUARDAR al final de la fila. En cualquier caso una de las tareas que se pueden programar para la máquina es la desfragmentación de los discos duros. Ver detalle de máquinas Aquí se puede ver el resultado de las auditorías ejecutadas sobre las máquinas cliente. Primero se debe buscar la máquina en el módulo máquinas. Una vez encontrada se debe seleccionar y pulsar el botón VER DETALLE. Se carga una ventana con un menú a la izquierda que contiene todos los campos de la auditoría: 238

249 Figura A1.28 Ventana de Vista de Detalle de Máquina En el menú COMPONENTES de la izquierda aparecerán activos aquellos campos que se hayan incluido en las auditorías realizadas en la máquina. Como defecto se carga en primera instancia la vista general de la máquina. Pulsando sobre cada uno de los campos en el menú COMPONENTES se podrá pasar de uno a otro. Figura A1.29 Ventana de Vista de Detalle de Máquina 239

250 Clientes / Dominios En éste módulo se pretende gestionar los clientes registrados en el sistema y las máquinas que tienen asignados cada uno por medio de los dominios a las que están asociadas. Figura A1.30 Ventana de Clientes Al abrir se carga las máquinas, clientes y dominios existentes. Sobre la lista de la derecha aparecen los dominios junto con el cliente al que están asociados y en la lista inferior las máquinas registradas con los dominios y clientes. Acciones: Actualizar Clientes Permite mantener actualizada la base de datos de clientes del sistema con los clientes registrados en el CRM. 240

251 Figura A1.31 Ventana de Clientes. Agregar/Eliminar Clientes Se puede Añadir o Borrar Clientes del sistema. Pulsar sobre la opción deseada. Aparecerá una lista de los clientes existentes en el CRM si se desea añadir o de los existentes en el sistema si se desea borrar: Figura A1.32 Ventana Selección. Selección de clientes Seleccionar el/los clientes a agregar/borrar y pulsar OK.El cliente se añade al despegable de clientes. 241

252 Nuevo Dominio Permite crear un dominio nuevo en blanco para poder asociarlo con un cliente. Para ello se debe pulsar el botón NUEVO DOMINIO. Figura A1.33 Ventana de Clientes. Agregar/Eliminar Clientes Para crear un dominio nuevo sólo es necesario introducir el nombre del nuevo dominio en el recuadro que aparece y pulsar OK El dominio nuevo aparece dentro del despegable Dominio y en la lista de dominios de la derecha. Asociar Cliente con Dominio En este apartado se explica como poder asociar un cliente registrado en el sistema con un dominio conocido. Esto sirve para poder asociar a su vez máquinas agente con los clientes a los que pertenecen ya que las máquinas cliente proporcionan el nombre del dominio del que son miembro. Es importante esta asociación para poder registrar alertas en el CRM con toda la información, incluido el cliente al que pertenece la máquina que provoca la alerta. Los clientes pueden tener varios dominios conocidos y todos se pueden asociar. Puede haber dos clientes que tengan el mismo nombre de dominio, por ejemplo WORKGROUP que es el dominio por defecto al que pertenecen las máquinas que no tienen dominio. Para poder distinguir entre clientes es necesario asociar las máquinas manualmente desde aquí. Para asociar un cliente con un dominio tienen que estar ambos registrados en el Sistema. (Ver Actualizar Clientes y Nuevo Dominio). Una vez registrados se puede hacer lo que sigue desde el módulo Clientes: 242

253 Seleccionar el Cliente y el Dominio. Pulsar el botón ASOCIAR CLI-DOM. Aparecerá en la lista dominios de la derecha la nueva asociación: Figura A1.34 Ventana de Clientes Asociar/Desasociar Máquinas con Cliente En este apartado se explica como poder asociar máquinas a un cliente registrado en el CRM por medio de un dominio conocido o como deshacer dicha asociación. Para ello se debe cargar el módulo Clientes y tener asociado el dominio al que pertenecen las máquinas al cliente (Ver Asociar Cliente con Dominio). Desde el módulo clientes Seleccionar de la lista de la derecha el Dominio al que se quiere asociar la máquina. Pulsar el botón Asociar Máquinas. Se puede Añadir o Borrar Máquinas de una asociación. Pulsar sobre la opción deseada. Aparecerá una lista de las máquinas sin asociar si se desea añadir o de las existentes en la asociación si se desea borrar: 243

254 Figura A1.35 Ventana de Clientes. Añadir/Borrar Máquinas Figura A1.36 Ventana de Selección. Selección de Máquinas Seleccionar las máquinas que se quiere asociar al cliente y dominio y Pulsar OK. La máquina aparecerá asociada al cliente y dominio en la lista de abajo: 244

255 Figura A1.37 Ventana de Clientes. Eliminar Dominio Permite eliminar un dominio. Si dicho dominio a su vez tuviera máquinas asociadas, éstas dejaran de estar asociadas a un dominio y al cliente correspondiente. Se debe seleccionar el Dominio de la lista de la derecha y pulsar el botón Eliminar Dominio. Las máquinas se quedan sin asignar y el dominio desaparece. 245

256 Log Agentes En este módulo se pretende controlar la actividad del sistema, registrando las acciones de los distintos agentes así como los errores que se hayan producido, que pueden ser: Errores en las máquinas agente: Son errores provocados ante la imposibilidad de llevar a cabo una acción o por imposibilidad de comunicación. Errores en el servidor de la aplicación: Son errores generados generalmente en el tratamiento de los datos manejados por el servidor o el interfaz. Figura A1.38 Ventana de Logs. Al cargar aparece una ventana con dos pestañas. La primera pestaña corresponde con las acciones de los agentes. Acciones Agentes Se puede seleccionar una fecha para ver las acciones de un agente en un día o seleccionando la casilla Omitir Fecha, ver todas las acciones de un mismo agente. Se debe seleccionar el agente en el despegable Maquina. Para ver las máquinas seleccionar previamente un cliente: 246

257 Figura A1.39 Ventana de Logs. Acciones de los Agentes Las acciones aparecen ordenadas por fecha, hora y acción. Éste última campo describe brevemente el proceso que lleva a cabo el agente. Van numeradas siguiendo la secuencia de acción del proceso agente ante el vencimiento del temporizador. Borrar Acciones Pulsando sobre el botón Borrar Acciones te permite varios borrados: Borrar Lista: se eliminan del sistema todas las acciones que aparecen en la lista. Así, se puede borrar las acciones de una máquina en un día o de todos los días. Borrar de Cliente: se eliminan del sistema todas las acciones de los agentes que pertenecen a un cliente. El cliente es el que está seleccionado en el despegable Cliente. Borrar Acciones de antes de Fecha: se eliminan del sistema todas las acciones de todos los agentes anteriores a la fecha que esté seleccionada en el calendario despegable Fecha. Actualizar Para disponer la información más reciente se puede cerrar la ventana y volver a cargarla o se puede pulsar sobre el botón actualizar. 247

258 Log Errores Al pulsar sobre la pestaña Errores se procede a cargar los errores registrados. Por defecto se cargan los errores entre la fecha mínima y la máxima indicadas en las respectivas casillas: Figura A1.40 Ventana de Logs. Errores Las fechas se pueden modificar para poder ver todos los errores registrados en el sistema. En el campo Origen de la tabla se indica si el error ocurrió en un agente o en el servidor, propiedad por la que se puede filtrar en el despegable Origen. Seleccionando el origen cliente se habilita el despegable correspondiente que permite seleccionar el cliente deseado. Asimismo, al seleccionar el cliente se habilita el despegable Maquina donde se puede seleccionar el agente del que se desea ver si hay errores. En la tabla, si el error pertenece a una máquina agente debe aparecer rellenados los campos Máquina y Cliente. La descripción completa de los errores se puede obtener pulsando el botón Ver Descripción. Asimismo, se puede borrar un error pulsando sobre el botón Borrar. El botón Borrar Todos del menú, elimina todos los errores que aparecen en la lista. Los errores pueden ser debidos a causas temporales que impidan el correcto funcionamiento de la aplicación, por ejemplo pérdida de comunicación de la máquina cliente, caída de la red, etc. Puede ocurrir que sea debido a un fallo ante una circunstancia no prevista que requiera una modificación en parte de la aplicación. Dichas posibles modificaciones se contemplan en la manera de llevarlas a cabo en el manual de explotación de la aplicación. 248

259 Settings Este módulo permite controlar parámetros de la aplicación. Se han definido tres apartados configurables, alertas, usuarios y versiones de la aplicación que se explican más adelante. Para acceder al módulo Settings es necesario hacerlo desde el módulo principal. Figura A1.41 Ventana Principal. Módulo Settings Settings de Alertas Los parámetros relacionados con las alertas permiten configurar las alertas que generarán las máquinas cliente, así como el usuario que aparecerá como encargado de dichas alertas. Automáticamente se carga la ventana con los valores actuales de los parámetros establecidos. Estos parámetros son consultados por el sistema a la hora de generar las alertas. 249

260 Figura A1.42 Ventana Gestión de Alertas Usuario Propietario de las Alertas: Es el usuario que tendrá asignadas todas las alertas que se generen. Se puede modificar abriendo el despegable, seleccionando el usuario deseado y pulsando sobre el botón APLICAR de la derecha. Porcentaje Máximo de Ocupación de Disco: Indica a partir de que porcentaje de ocupación de disco (Espacio Ocupado/Espacio Total) se generaría una alerta en caso de estar activado en los elementos generadores de alerta. Se puede modificar abriendo el despegable, seleccionando el porcentaje deseado y pulsando sobre el botón APLICAR de la derecha. Porcentaje Mínimo de Memoria Libre: Indica a partir de que porcentaje de memoria libre disponible (Memoria Libre/Memoria Total) se generaría una alerta en caso de estar activado en los elementos generadores de alerta. Se puede modificar abriendo el despegable, seleccionando el porcentaje deseado y pulsando sobre el botón APLICAR de la derecha. Tamaño Máximo de Cuota: Es el tamaño máximo permitido de ocupación de disco en el servidor por parte de los usuarios de un dominio. Se puede modificar introduciendo el nuevo valor en el cuadro de texto y pulsando sobre el botón APLICAR de la derecha. 250

261 Elementos Generadores de Alertas: Hasta este punto se han visto filtros simples para la generación de alertas. Existen tres campos que poseen un filtro más exhaustivo. Son los 3 que aparecen en la tabla de la parte inferior de la pantalla. Cada elemento se corresponde con una fila de la tabla y tiene 2 apartados, que permite filtrar las alertas en función del tipo de agente ya sea PC o servidor. Las casillas de activación permiten habilitar o deshabilitar la total generación de alertas de ese elemento para ese tipo de agente. Si está habilitado, se podrá configurar filtros específicos para registros del elemento para el tipo de agente elegido, es decir, se pueden introducir filtros de generación de alertas por instalación o desinstalación de ciertos programas en los agentes servidor, por ejemplo. A continuación se muestra la configuración de filtros específicos de registros de los tres elementos: Filtro específico de generación de alertas por errores del log de windows: Se mostrará una lista de los errores que a lo largo de la vida del sistema se han ido registrando. Cada uno podrá ser desactivado para evitar que produzca alertas al aparecer de nuevo en algún agente del tipo especificado. Para desactivar pulsar sobre la casilla Activo para que desaparezca el tic y sobre Aplicar. Figura A1.43 Ventana Filtro de Generación de Alertas de Errores de Windows 251

262 Filtro Específico de generación de alertas por servicios automáticos no arrancados: Al igual que con los errores, al abrir el filtro, aparecerán los servicios automáticos no arrancados que se han ido registrando a lo largo de la vida del sistema. Figura A1.44 Ventana Filtro de Generación de Alertas de Servicios Filtro Específico de generación de alertas por programas: Los programas que contengan en su nombre alguno de los filtros no producirá alertas. Figura A1.45 Ventana Filtro de Generación de Alertas de Programas 252

263 Settings de Usuarios Este apartado permite la actualización de los usuarios de la aplicación y la gestión de permisos. Los usuarios son obtenidos desde la base de dat0s de la aplicación CRM por lo que un nuevo usuario que quiera utilizar la aplicación debe haber sido registrado en el CRM antes de actualizar la base de datos del sistema. Se ha realizado una distinción de dos grupos básicos de usuarios: User y Admin. El usuario normal User no tiene acceso a esta ventana de propiedades. Aparecerá el siguiente mensaje si intenta acceder: Figura A1.46 Credenciales no válidas La distinción de usuarios sólo afecta a ésta ventana y la ventana gestión de versiones. El usuario Admin tiene acceso a toda la aplicación. Al entrar aparece la siguiente pantalla: Figura A1.47 Ventana de Gestión de Usuarios Se observa una lista con los usuarios registrados junto con el grupo al que pertenece. Al agregar o borrar un usuario (pulsando sobre sus respectivos botones) aparecerá una lista con los usuarios que se pueden agregar (registrados en el CRM y no en el sistema) o borrar: 253

264 Figura A1.48 Ventana de Selección. Selección de Usuarios Al pulsar OK el usuario queda registrado en le sistema y por defecto se le asigna al grupo User. Si se quiere establecer el grupo al que pertenece un usuario se debe seleccionar el usuario, pulsar sobre Establecer Tipo Usuario y seleccionar la opción: Figura A1.49 Ventana de Usuarios. Establecer Tipo de Usuario 254

265 Settings de Versiones En este apartado se controla las versiones de la aplicación cliente (versión del agente de las máquinas cliente). Sólo los usuarios pertenecientes al grupo Administradores tienen acceso a esta ventana. Si un usuario User intenta acceder le aparecerá el siguiente mensaje: Figura A1.50 Credenciales no válidas Si es un usuario Administrador podrá configurar los datos que aparecen en la siguinte ventana: Para cambiar de versión la aplicación cliente se debe haber desarrollado el nuevo paquete de instalación y haberlo ubicado en una ruta accesible en el servidor tal y como se explica en el manual de explotación del sistema. Figura A1.51 Ventana de Gestión de Versiones Última Versión del Cliente: Es la última versión de la aplicación cliente conocida en el sistema. El sistema comprueba cada una de las versiones de las máquinas cliente en las comunicaciones con éstas contra la última versión conocida. En caso de presentarse una versión antigua en una agente de una máquina el sistema le proporciona la ruta donde encontrar la última versión, mediante el apartado ruta del repositorio de versiones. Como mínima indicación el ejecutable debe contener la versión en el nombre de tal forma que sea: EvoAgentSetupX.Y.msi siendo X.Y el número de la versión (1.0, 1.2, etc). Ruta del Repositorio de Versiones: Dicha ruta se debe indicar en este apartado dentro del cuadro de texto y actualizarla en el sistema pulsando el botón APLICAR. Indica una ruta física en el servidor donde se ubican los paquetes de instalación para poder ser descargados. 255

266 Alertas Éste módulo forma parte de la aplicación de gestión EvoAgentManager pero se ha migrado su funcionalidad a la aplicación CRM donde se lleva la gestión de los clientes de la empresa Evotec para, de esta manera, poder trabajar con las alertas combinándolas con otras herramientas de trabajo que proporciona dicha aplicación. Se va ha proporcionar aquí alguna indicación de cómo acceder a las alertas en la aplicación CRM de Microsoft y trabajar con ellas sin meterse demasiado a fondo en el funcionamiento del CRM que no es competencia de este manual de usuario. Cómo empezar Para acceder a las alertas generadas por el sistema y registradas en el CRM, se debe abrir dicha aplicación. Para ello se ha proporcionado un enlace directo desde la interfaz de la aplicación de gestión. Se puede observar desde la ventana principal en el menú inferior izquierdo capítulo de Referencias. En cualquier caso se puede acceder a la aplicación usando los medios proporcionados por la misma para ello, en este caso, mediante Internet Explorer a la dirección de su ubicación en la red de la empresa. Figura A1.52 Ventana Principal de la aplicación. Módulo Referencias Una vez cargada la aplicación CRM y si esta correctamente configurada para el usuario actual se podrá ver en el menú Área de Trabajo de la izquierda un apartado Extensiones con el elemento Alerta: 256

267 Figura A1.53 Menú de la aplicación CRM. Internet Explorer Pulsando sobre el botón se cargan las alertas activas existentes. La vista general se compone de Tipo de alerta, identificador, equipo, fecha y descripción o detalle. Haciendo doble clic sobre la alerta se puede empezar a trabajar con ella y aparece más información como el cliente o detalles relevantes dependiendo del tipo de alerta. 257

268 Figura A1.54 Aplicación CRM. Alertas Figura A1.55 Aplicación CRM. Formulario de Alerta 258

269 Desechar Alertas Con la información disponible se puede optar por desechar el evento como alerta y eliminarlo. Para ello se pude seleccionar las alertas a eliminar y pulsar el botón con un aspa. Se pedirá confirmación. Asignar Alertas Aunque, como se ha visto en el módulo Settings, existe un usuario del sistema al que se registran todas las alertas (Ver Settings de Alertas ) el usuario propietario de unas determinadas alertas se puede modificar. Esto permitiría poder poner un usuario genérico como el propietario de las alertas y desde éste asignarlas a quien corresponda. Para asignar la alerta se debe acceder primero a la alerta haciendo doble clic sobre ella en la ventana de alertas del CRM. Aparece la ventana de arriba con la información detallada de la misma. Sobre el menú de arriba pulsar la opción Acciones y Asignar: Figura A1.56 Aplicación CRM. Formulario de Alerta Aparece la siguiente pantalla. Si se desea asignar a otro usuario seleccionar la opción y pulsar sobre la lupa que aparece al final del recuadro: 259

270 Figura A1.57 Aplicación CRM. Asignar Alerta Aparece otra ventana con los posibles usuarios. Seleccionar el usuario deseado y pulsar ACEPTAR. 260

271 Figura A1.58 Aplicación CRM. Selección de Usuarios Aparece la alerta con el Propietario actualizado. También se puede hacer pulsando directamente sobre la lupa que hay al final de dicho campo. Figura A1.59 Aplicación CRM. Formulario de Alerta Crear Caso vinculado a Alerta El caso es la unidad de tratamiento con un cliente. Cada caso conlleva unas acciones que se deben realizar antes de resolver dicho caso. Los casos pueden ser debidos a un problema o una solicitud o revisión. Se pueden acceder a ellos a través de las cuentas de los clientes o directamente, al igual que con las alertas, desde el menú Área de Trabajo. El caso es la herramienta, interna al CRM, que se ha elegido para tratar las alertas. Es por ello que para éste módulo se haya realizado una integración con dicha aplicación. Cada alerta podrá generar uno o varios casos para un cliente. El tratamiento de casos es un apartado correspondiente al CRM y la propia compañía y por tanto no será tratado en este documento. Para crear un caso a partir de una alerta es necesario abrir la alerta. En el menú de la izquierda aparece la opción Servicios y dentro de Servicios Casos. Haciendo clic sobre éste último se accede a los casos relacionados con la alerta: Para crear un caso nuevo pulsar sobre el botón Crear Caso. 261

272 Figura A1.60 Aplicación CRM. Formulario de Alerta Se abrirá una nueva ventana con la información del nuevo caso. El caso llevará asociado una alerta en el apartado Alerta que se señala en la imagen. FiguraA1.61 Aplicación CRM. Formulario Edición de Caso A partir de aquí se puede trabajar con el caso como un caso más, asignarlo a un usuario y resolverlo. 262

273 Anexo 2. Manual de Explotación Este anexo pretende servir de ayuda al administrador del sistema EvoAgent. El sistema corresponde al género de sistemas distribuidos donde la funcionalidad se reparte entre un servidor de información y gestión y un cliente consumidor de servicios bajo tecnología pull. Esta metodología se repite tanto para la aplicación agente, EvoAgent, que se instala en las máquinas cliente como para la aplicación de gestión, EvoAgent Manager, que se instala en las máquinas de los técnicos. Este manual se divide en varios apartados atendiendo primero a la implementación del sistema y posteriormente al mantenimiento del mismo. En general se explica la configuración del código fuente que genera las distintas aplicaciones y servicios del sistema así como la forma de trabajar con él y cómo se pueden introducir evoluciones en el código para aumentar la funcionalidad. A2.1. Implementación y Configuración del sistema El código fuente del sistema, desarrollado con la herramienta Visual Studio 2005, se descompone en dos soluciones. Todo el código se encuentra bajo el mismo directorio EvoAgentProyect: FiguraA2.1 Directorio del Código Fuente del Sistema 263

274 Desde aquí se puede abrir una de las dos soluciones haciendo doble clic sobre el archivo EvoAgentProyect.sln. Para acceder a la otra solución es necesario entrar en el directorio EvoAgentService y hacer doble clic sobre el archivo EvoAgentService.sln FiguraA2.2 Directorio del Código Fuente del Proyecto EvoAgentService Ambas soluciones se pueden abrir directamente desde el programa Visual Studio A2.1.1 Solución EvoAgentService Programa Agentes La solución se compone de tres proyectos de Visual Studio: EvoAgent, EvoIcon y EvoAgentSetup. FiguraA2.3 Explorador de Soluciones de Visual Studio. Solución EvoAgentService Cada uno de los proyectos posee su propia carpeta en el sistema de directorios como se ha podido observar en la figura A

275 Proyecto EvoAgent Se trata de un proyecto Visual Studio de tipo Servicio de Windows y es utilizado para generar el servicio de Windows que se instala en las máquinas cliente y que comprende toda la funcionalidad del agente del sistema. En la figura A2.4 se puede ver las diferentes clases que lo componen. FiguraA2.4 Explorador de Soluciones de Visual Studio. Proyecto EvoAgent Las clases principales de un proyecto así son la clase servicio e instalador: La clase servicio, en este caso EvoAgentService, hereda de la clase System.ServiceProcess.ServiceBase y posee los métodos Main(), OnStart() y OnStop() así como otros métodos sobrescribibles y otros que se quieran introducir. El método Main() se ejecuta la primera vez que se inicia el servicio y generalmente debe contener una llamada explícita a la inicialización del servicio mediante el método System.ServiceProcess.ServiceBase.Run() pasando como argumento una instancia del servicio (llamando al constructor). El método OnStart() se ejecuta cada vez que se inicia el ordenador. Al iniciar se crea la clase ConfigAgente que permanecerá activa hasta que se detenga el servicio. Dicha clase contiene cuatro propiedades: o o El identificador de la maquina: lo lee del registro. El directorio de trabajo: lo lee del registro. 265

276 o o La referencia al servicio web para conectar con el servidor: El proyecto contiene una referencia Web al servicio web ControlClientes del módulo servidor del sistema. Es en esta clase donde se inicializa la conexión que se utilizará. Las llamadas a este servicio se realizan mediante la ruta: dir /EvoAgentServer /ControlClientes /ControlClientes.asmx donde dir indica la ruta del servidor de Evotec. Se ha configurado para apuntar a un nombre modificado dinámicamente en el DNS del sistema donde esté instalado el agente. El cname en concreto es evoagentserver. Si no consiguiera conectarse por cualquier razón utilizando el cname, se utilizaría la ruta por defecto: evoagentserver.evotec.es. Esta acción se hace también a la hora de instalar el programa. El tipo de agente: Lo obtiene del servidor si consigue iniciar la comunicación en el punto anterior. Por otro lado, se inicia un temporizador que salta cada hora para realizar su proceso. El temporizador esta controlado por un handler que detectará cuando salte e iniciará el método IntervaloComunicación. Otros métodos que se incluyen en esta clase tienen que ver con la funcionalidad del servicio. La clase instalador, en este caso EvoAgentInstaller, hereda de la clase System.Configuration.Install.Installer y posee los métodos sobrescritos Install() y Uninstall(). También posee un atributo que contiene los distintos instaladores que debe ejecutar. Los instaladores se deben generar y, para el caso del servicio Windows se debe crear 2, de las clases: System.ServiceProcess.ServiceProcessInstaller y System.ServiceProcess.ServiceInstaller. Estos instaladores son los que se encargan de instalar el servicio de windows. Son iniciados en el constructor de la clase con los parámetros del servicio (tipo de inicio, nombre y cuenta de usuario) e incluidos en el atributo installers de la clase. En el método Install() se debe incluir todo el código que se quiere que se ejecute al instalar el servicio y en el método Uninstall() al desinstalar. En este caso, al instalar, se pretende obtener el que será el directorio de trabajo y guardarlo en el registro, así como ejecutar una auditoría de la máquina para obtener el nombre de host y número de serie de la máquina para enviársela al servidor, obtener un identificador único que será el identificador de la máquina y almacenarlo en el registro. Por último, se almacena una ruta en el registro de arranque de la máquina para que inicie el programa EvoIcon que mostrará el icono en la barra de tareas. Al desinstalar se borrará la ruta introducida en el registro de arranque de la maquina para el inicio del programa EvoIcon. 266

277 Otras clases implementan características propias de la funcionalidad del servicio. La clase comunicaciónservidor posee los métodos de acceso al servicio web del servidor y es utilizada, por tanto, para todas las comunicaciones. La clase control_tareas almacena las tareas descargadas del servidor hasta que se hayan ejecutado todas, momento en que acaba su labor hasta las siguientes tareas. La clase LogAgente se encarga de la gestión del log local del agente, que debe utilizarse en el caso de que falle el envío del log al servidor. Las clases Process sirven de apoyo en la ejecución de las diferentes tareas. Por último comentar que la versión del agente instalado en la máquina cliente viene indicada en el apartado Settings dentro de properties con un setting a nivel de aplicación. Dicho setting es el que se utiliza para contrastar la versión del agente con la última versión disponible tal y como se explica en el apartado Gestión de Versiones del punto 2 de este documento. Proyecto EvoIcon Se corresponde con el programa que carga el icono en la barra de tareas. En la figura A2.5 se puede ver las clases que lo componen: FiguraA2.5 Explorador de Soluciones de Visual Studio. Proyecto EvoIcon El proyecto consiste en una aplicación de Windows. Al iniciarse arranca la clase program que contiene el método main(). Esta clase arranca la primera ventana de la aplicación, la ventana Form1. La ventana Form1 se mantendrá oculta durante toda la vida de la aplicación. Para ello se debe acudir a las propiedades de la ventana y configurarla los siguientes Items: WindowState = Minimized y ShowInTaskBar = False. Por otro lado se debe incluir una línea de código en el método Load. 267

278 private void Form1_Load(object sender, EventArgs e) { this.hide(); } Nota: Para que visual Studio genere automáticamente dicho método se debe pulsar dos veces sobre la ventana en el modo diseño. La ventana posee dos objetos, un NotifyIcon y un ContextMenuStrip. Ambos se pueden agregar en el modo diseño desde la barra de herramientas. El NotifyIcon define el Icono que se mostrará en la barra de herramientas junto con el texto que muestra al pasar sobre él. Una de los ítems que aparecen en las propiedades del NotifyIcon es el ContextMenuStrip y está configurado para que utilice el que posee la ventana. El objeto ContextMenuStrip es un menú donde se han configurado dos acciones: Acerca De y Evotec Soporte Remoto. La primera muestra la ventana Diseñada en la clase AcercaDe.cs y la segunda inicia un proceso que arranca el programa de soporte remoto. Al incluir el contextmenú como propiedad del NotifyIcon se mostrará el menú al pulsar sobre el Icono. Proyecto EvoAgentSetup Se trata de un proyecto de instalación cuyo resultado es un fichero.msi instalable por medio del programa Windows Installer en sus distintas versiones. El archivo Windows Installer resultante contiene la aplicación, cualquier archivo dependiente, información sobre la aplicación e instrucciones para la instalación de forma que se puede instalar en cualquier equipo. La vista del proyecto desde Visual Studio es la que sigue: FiguraA2.5 Explorador de Soluciones de Visual Studio. Proyecto EvoAgentSetup 268

279 El proyecto incluye una lista de archivos que guardará en el directorio de la aplicación pudiendo agregar o quitar archivos. Los elementos con el nombre de Primary output from se corresponden con los ejecutables de los proyectos EvoAgent y EvoIcon. Al hacer clic con el botón derecho del ratón sobre el nombre del proyecto y pulsar en View aparecen varias opciones que permiten configurar aspectos de la instalación: Sistema de Archivos: Contiene una representación del sistema de archivos de un equipo de destino. La organización del sistema de archivos puede ser distinta de un equipo a otro y los nombres de carpeta pueden diferir también; por tanto, para garantizar que los archivos se instalan en donde se desea, el Editor del sistema de archivos usa el concepto de carpetas abstractas o virtuales. Se puede agregar o quitar ficheros que se desea que el instalador agregue a la carpeta de la aplicación así como al escritorio del/los usuario/s y al menú programas del/los usuario/s así como establecer la ruta del directorio de la aplicación Figura A2.6 Visual Studio. Sistema de Archivos del proyecto Setup Haciendo clic en el botón derecho del ratón sobre Application Folder y pulsando Properties se ven las propiedades de la carpeta de la aplicación. Aquí se puede configurar la ruta por defecto en la que se creará la carpeta de la aplicación con el ítem DefaultLocation. Por defecto se incluye la ruta Archivos de Programa/Evotec/EvoAgent/ 269

280 Figura A2.7 Visual Studio. Propiedades de la carpeta de la aplicación Por otra parte, pueden incluirse condiciones en cualquier archivo o carpeta mediante la propiedad Condition. Esto permite personalizar la instalación de archivos en función de las condiciones que existan en el equipo de destino durante la instalación. Por ejemplo, puede elegir instalar distintos archivos dependiendo de la versión del sistema operativo instalada en el equipo de destino. Para obtener más información sobre las condiciones ir al link: Interfaz de usuario: Se puede configurar las ventanas que se mostrarán en el proceso de instalación mediante las que se puede proporcionar información al usuario u obtenerla de éste. Por defecto no se pretende interactuar con el usuario en el proceso de instalación con lo que se han suprimido todas las ventanas posibles. Figura A2.8 Visual Studio. Configuración del Interfaz de Usuario de la instalación del paquete Acciones Personalizadas: El Editor de acciones personalizadas permite especificar acciones adicionales que se van a realizar en el equipo de destino al final de la instalación. Las acciones personalizadas deben compilarse como un archivo.dll o.exe, o agregarse a un proyecto como una secuencia de comandos o un ensamblado antes 270

281 de que puedan incorporarse a un proyecto de implementación. Las acciones sólo se pueden ejecutar al final de una instalación. El editor contiene cuatro carpetas, que se corresponden con cada fase de instalación: Instalar, Confirmar, Deshacer y Desinstalar. Se ha incluido el resultado del proyecto EvoAgent, es decir, que ejecute el instalador del servicio Windows en una Instalación y lo desinstale en una desinstalación. Figura A2.9 Visual Studio. Acciones Personalizadas del proyecto Setup En el evento Commit, al confirmar la instalación se ha incluido un script desarrollado en visual Basic Scripting que inicia el servicio instalado. Para agregar acciones se debe hacer clic con el botón derecho sobre la fase en donde se desea agregar y pulsar agregar. Para agregar en todos las fases hacerlo sobre Custom Actions. Por último, se pueden establecer condiciones para la ejecución del código. Hay múltiples condiciones configurables en función de las propiedades de la instalación, del sistema o de otros aspectos. En este caso se ha configurado una condición en la instalación del servicio de Windows: Figura A2.10 Visual Studio. Condición para la ejecución de la acción personalizada. 271

282 La condición establece que el servicio de Windows se instale si Windows Installer no encuentra una versión anterior de la aplicación instalada. Esto evita que Windows Installer desinstale y vuelva a instalar el servicio aunque correspondan a distintas versiones del mismo. Además, en Visual Studio 2008, por defecto, el paquete de instalación fuerza a que se instale la aplicación antes de desinstalar la antigua lo que provoca un error al encontrarse con un servicio existente. Con la condición comentada se evita el error. Para saber más acerca de cómo actualizar el servicio de Windows mediante este proyecto ver el apartado A Es muy importante mencionar las propiedades del paquete de instalación. Al hacer clic con el botón derecho del ratón sobre el nombre del proyecto y pulsar en Properties aparecen las propiedades del paquete de instalación. Figura A2.9 Visual Studio. Propiedades del proyecto Setup 272

283 En este apartado se han configurado varios aspectos importantes que se deben tener en cuenta: Instalación para todos los usuarios: InstallAllUsers = true; Gestión de Versiones: La gestión de versiones se controla con los campos UpgradeCode y ProductCode. Las diferentes versiones (ProductCode) de un mismo sofware (UpgradeCode) se modifican automáticamente al cambiar el atributo Versión. Se debe tener en cuenta que para que funcione la primera versión debe ser Ver apartado A DetectNewerInstalledVersion = true; Si encuentra una versión más moderna del software a instalar rechaza la instalación. RemovePreviousVersions = true; Desinstala una versión anterior del software si estuviera instalada. Esto, como se ve en el link no ocurre con los paquetes generados en Visual Studio Para más información sobre las propiedades de un proyecto de instalación consultar el link: A2.1.2 Solución EvoAgentProyect La solución se compone de 6 proyectos de los cuales existe una aplicación web, una aplicación de escritorio, una aplicación de consola, una librería y dos instaladores. Figura A2.10 Visual Studio. Solución EvoAgentProyect 273

284 Proyecto EvoAgentLibrary Se trata de un proyecto de librería de clases que contiene paquetes de clases del sistema que son utilizados por el resto de aplicaciones. El subsistema EvoAgentService visto hasta ahora se considera un subsistema independiente con un sistema de clases independiente. El resto de aplicaciones utilizan los paquetes de clases aquí definidos: Figura A2.11 Visual Studio. Proyecto EvoAgentLibrary Dominio: Todas las clases pertenecientes al dominio del sistema. Se incluye un directorio con las clases representativas de los campos auditados por winaudit. Dao: Los DataSet y DataAdapters y las clases de acceso a datos ubicadas en el fichero Dao.cs. Se maneja desde aquí todos los accesos a datos, tanto para la base de datos Evotec_Control como para el sistema Externo CRM (acceso a la base de 274

285 datos del CRM y al servicio Web CRMService), como para el sistema externo TaskScheduler. Servicios: Clases que definen funciones que son utilizadas por otras aplicaciones. Entre ellas están definidas la clase CredencialesUsuario utilizada por la aplicación de gestión EvoAgentManager para realizar el login contra el servicio web y la base de datos, la clase InterpreteProgramacionTareas utilizada por la aplicación de gestión EvoAgentManager para gestionar la creación y lectura de tareas programdas, la clase ControlNuevaAuditoria utilizada por la aplicación Web EvoAgentServer para gestionar la creación de Alertas y la clase LeerAuditoriaXML utilizada para leer los ficheros XML de auditorías para mostrar el detalle de las máquinas en la aplicación de gestión y para realizar el control de la auditoría en la aplicación Web. References: Aquí se incluye la referencia a la librería TaskScheduler necesaria para la gestión de tareas programadas. WebReferences: Se incluyen aquí las referencias a los servicios web: el servicio Web de Administración del sistema y el servicio Web del CRM. Properties: En el apartado Settings se deben configurar varios settings que utiliza el sistema como las cadenas de conexión a las dos bases de datos, la dirección del pc que contiene el Task Scheduler de Windows que almacena las tareas programadas, Las credenciales de acceso al servicio CRMService y la ruta de acceso a los servicios web ControlAdmin.asmx y CRMService.asmx. Proyecto EvoAgentManager Se trata de una aplicación de Windows que posee el interfaz gráfico de usuario para los técnicos. El documento Manual de Usuario muestra toda la funcionalidad de la aplicación. La ventana Form_Main es la primera ventana de la aplicación. Mediante esta ventana se puede acceder al resto de la aplicación. La aplicación utiliza controles de Windows de Ascend.NET que son agregados en la ficha References. Así mismo, en References, se incluye la referencia al proyecto EvoAgentLibrary para acceder a la librería del sistema. 275

286 Figura A2.12 Visual Studio. Proyecto EvoAgentManager Proyecto EvoAgentServer Se trata de una aplicación ASP.NET Web Services Application que contiene el módulo servidor del sistema. Contiene una referencia al proyecto EvoAgentLibrary para acceder a la librería del sistema. Se distinguen dos directorios que formarán el sitio web, ControlClientes y AdminManager. Cada uno de ellos debe tener un método de autenticación diferente. Se procede ahora a explicar cada uno de los componentes de los directorios: 276

287 Figura A2.13 Visual Studio. Proyecto EvoAgentServer ControlClientes: Es el directorio que contiene el servicio web ControlClientes.asmx al que acceden los agentes para comunicarse con el sistem. Dicho directorio debe tener habilitada la autenticación básica. Mediante Internet Information Server se puede configurar un usuario anónimo que represente a todos los accesos anónimos que se reciba. El sistema realiza la autenticación de los accesos en el nivel de aplicación accediendo a la base de datos. Por otro lado contiene el directorio donde se alojarán los ficheros que deban descargarse los agentes, Repositorio. Dicho directorio se utiliza para la gestión de versiones. AdminManager: Es el directorio que contiene el servicio web ControlAdmin.asmx. al que accede la aplicación de gestión EvoAgentManager. El directorio debe tener habilitada la autenticación basada en Windows para que sólo los usuarios del dominio de la empresa tengan acceso al directorio. El servicio ControlAdmin.asmx suministra servicios como la descarga de auditorias e incidencias, así como gestión de las tareas programadas. Como se ve en la figura contiene 3 directorios para cada uno de los elementos mencionados. El usuario anónimo definido en el punto ControlClientes debe tener acceso de escritura sobre los directorios Auditorias e Incidencias para poder escribir las auditorías e incidencias que recibe de los clientes. 277

288 La aplicación Web reside en un directorio virtual al que hace referencia el sitio web definido en el Servidor Web. En concreto, la aplicación web en el entorno de producción reside en el directorio \\evtsrv01\inetpub\evoagentserver\ y es ahí donde se debe publicar. Para publicar una aplicación web pulsar el botón derecho del ratón sobre el nombre del proyecto y hacer clic en publicar. Aparecerá una ventana donde será necesario indicarle la ruta donde publicarla. Visual Studio compila el proyecto y crea las carpetas necesarias incluyendo el código que necesita la aplicación para funcionar. Proyecto ProgramacionTareas Se trata de una aplicación de consola que interpreta las tareas programadas para registrar tareas en la base de datos para su realización por los agentes. Se ejecuta a partir de archivos bat que son objeto de la tarea programada. Revive como argumento el nombre de la tarea programada, que es el mismo que el nombre del fichero bat y que el nombre de un fichero xml que contiene las tareasa realizar por los agentes. El programa reside en el archivo Program.cs y contiene la función Main() y funciones de interpretación auxiliares. En References existe una referencia al proyecto EvoAgentLibrary a través de la cual utiliza la librería del sistema para registrar mediante el paquete dao TareasMaquina (del paquete dominio) en la base de datos. Figura A2.14 Visual Studio. Proyecto ProgramacionTareas La aplicación se debe desplegar en el subdirectorio TareasProgramadas del directorio AdminiManager del sitio web de la aplicación EvoAgentServer. Se debe copiar el resultado del proyect, ProgramacionTareas.exe, junto con los ficheros EvoAgentLibrary.dll y TaskScheduler.dll. Todos ellos se encuentran en la ruta ProgramacionTareas.exe/bin/debug del directorio de trabajo. Proyecto EvoAgentManagerSetup Es un proyecto de instalación de la aplicación EvoAgentManager. El proyecto contiene la referencia al proyecto EvoAgentManager (Proyect Output). Se ha establecido la ruta por 278

289 defecto de instalación de la carpeta Application Folder en %Programfiles%\Evotec\EvoAgentManager y se ha suprimido la interacción con el usuario. Como se ve la imagen, se ha añadido un acceso directo (shortcut) en el menú de programas. Figura A2.14 Visual Studio. File System del Proyecto EvoAgentManagerSetup A2.1.3 Gestión de datos Base de datos Evotec_Control en SQL Server La base de datos esta alojada en el gestor de base de datos SQL Server del servidor de la empresa. Para acceder a la misma se puede utilizar el programa SQL Server 2005 Management Studio Express mediante una conexión de confianza: Figura A2.15 Conexión de Confianza con el Gestor de Bases de Datos 279

290 Una vez conectado con el servidor se puede acceder a todas las tablas de la base de datos, modificarlas, introducir datos y realizar operaciones de backup de los datos. Figura A2.16 Base de datos Evotec_Control No se puede modificar las propiedades de las columnas de las tablas si la tabla contiene datos. Para ello borrar los datos o crear una tabla nueva donde posteriormente se copiarán. Descripción de las tablas de datos Aquí se incluye una descripción de cada una de las tablas indicando los datos que almacenan y los datos asociados que se necesitan obtener de otra fuente. El acceso a las tablas de la base de datos se realiza mediante conexiones gestionadas por un DataSet directamente desde las aplicaciones de gestión o desde el servicio web ControlClientes del servidor. Para obtener los datos asociados a algunas tablas como descripciones de errores o auditorias se usa el servicio web ControlAdmin del Servidor. 280

291 T_Cliente: Almacena los clientes agregados al sistema mediante la aplicación EvoAgentManager (Ver Manual de Usuario, Clientes/Dominios). Provienen de la base de datos del CRM y se crean dos campos que indican el mismo identificador único del CRM (Guid) y la misma Razón Social. T_Dominio: Almacena la información de dominios existentes en los clientes. Lo normal es asociar un dominio para cada cliente pero pueden asociarse más. Se identifican mendiante un Guid creado por el sistema y se registran automáticamente al dar de alta una máquina o manualmente desde la aplicación EvoAgentManager. (Ver Manual de Usuario, Clientes/Dominios). T_ElementosGeneradoresAlerta: Tabla que indica cuando se registran alertas de los tipos programa, error y servicio dependiendo del origen (pc o servidor). Se configura en la Gestión de Alertas en la aplicación EvoAgentManager. T_ErrorAplicacion: Almacena la información de los errores ocurridos en el sistema o en las actividades de los agentes. La descripción del error se obtiene del subdirectorio incidencias de AdminManager. Se identifican con el mismo nombre de fichero que el identificador creado por el sistema. T_FiltroAlertaErrores: Se identifican los errores del log obtenidos desde cualquier agente mediante un identificador de instancia y se registran automáticamente en la tabla incluyendo los datos reflejados en los campos que son obtenidos mediante la clase EventLogEntry de System.Diagnostics. Ver la documentación relacionada en Además, se incluyen dos campos que indican, para cada instancia de Error, si se registran alertas para origen PC o Servidor respectivamente y son configurados desde la Gestión de Alertas en la aplicación EvoAgentManager (Ver Manual de Usuario). T_FiltroAlertaProgramas: Almacena las cadenas de caracteres que sirven de filtro para la generación de alertas relacionadas con la instalación/desinstalación de programas. Se configuran desde la Gestión de Alertas en la aplicación EvoAgentManager (Ver Manual de Usuario). T_FiltroAlertaServicios: El sistema registra automáticamente el nombre de los servicios automáticos que no se han iniciado para cualquier máquina. Se incluye dos campos que indican, para cada servicio, si se registran alertas para origen PC o Servidor respectivamente y son configurados desde la Gestión de Alertas en la aplicación EvoAgentManager (Ver Manual de Usuario). 281

292 T_MaqAccion: Se registran automáticamente las acciones realizadas por los agentes. Se pueden acceder y borrar desde el módulo Logs de la aplicación EvoAgentManager. (Ver Manual de Usuario). T_MaqAuditoria: Almacena la información de las auditorias realizadas por los agentes. La auditoría en si se obtiene del subdirectorio Auditorias de AdminManager donde están almacenadas en formato XML. Se identifican con el mismo nombre de fichero que el identificador creado por el sistema. T_MaqCuotasUsuarios: Almacena la cuota de usuario del dominio que se está consumiendo en los agentes que son servidores. T_MaqError: Almacena el Log de Errores de las máquinas cliente obtenidos por el agente en la auditoría para no repetir el registro de alertas con errores que ya se han registrado. T_MaqPrograma: Almacena los programas instalados en las máquinas cliente obtenidos por el agente en la auditoría para obtener las instalaciones de nuevos programas y desinstalaciones para la generación de alertas. T_MaqTarea: Tabla utilizada para almacenar las tareas que se programan para los agentes mediante el módulo tareas en la aplicación EvoAgentManager. Se alamcena un identificador de tarea para la maquina que identifica cada una, un identificador de máquina que identifica la máquina y, por tanto, el cliente para el que se programa la tarea y un identificador de tarea que identifica la tarea programada y su descripción. Se registra el estado de la tarea y los parámetros necesarios para ejecutar la misma así como la fecha de ejecución para la que se programó. Mediante el identificador de máquina los agentes obtiene las tareas que deben ejecutar. T_MaqUsuario: Registra los usuarios de un agente servidor obtenidos con el comando dsquery, es decir, los usuarios del dominio registrados en el Active Directory del Servidor de Dominio. T_Settings: Almacena Settings de la aplicación con el formato id, descripción y valor. En concreto se almacena el Valor de la última versión del programa agente disponible, la ruta del repositorio y los filtros de generación de alertas de disco, memoria, y cuota de usuario. T_Tarea: Registro de las tareas que pueden ser programadas para los agentes. Únicamente se indica su identificador y nombre, para ser identificadas por el sistema y los agentes. 282

293 T_UsuarioAplicacion: Almacena los usuarios agregados al sistema mediante la aplicación EvoAgentManager (Ver Manual de Usuario, Gestión de Usuarios) y que tienen acceso a la aplicación EvoAgentManager. Provienen de la base de datos del CRM y se crean cuatro campos que indican el mismo identificador único del CRM (Guid) el nombre, el nombre de sesión y el tipo de usuario (User o Admin). Mantenimiento de la base de datos: Se hace necesario llevar un control del volumen de datos que maneja la base de datos. Los puntos conflictivos se encuentran en: o El log de acciones que dejan los agentes, tabla, T_MaqAcciones, cuyo volumen se puede controlar directamente desde el módulo logs de la aplicación EvoAgentManager. o La tabla T_MaqError que almacena los errores del log registrados en las máquinas indefinidamente. Por lo demás se tratan de tablas que no incrementan sus registros desmesuradamente, si bien, se debe intentar gestionar las tablas para que no crezcan sin control, realizar acciones como borrar tareas antiguas o control diario de los errores de la aplicación en el log de errores desde la aplicación EvoAgentManager. Las auditorías obtenidas, por ejemplo, son almacenadas tras machacar auditorias antiguas que poseen los mismos campos de forma automática, por lo que no se requiere ninguna acción y el resto de tablas mantendrán un nivel estable y proporcional al número de máquinas registradas en el sistema y monitorizadas. Por último, se debe mencionar como realizar el salvado de datos. Se puede utilizar el mismo programa visto anteriormente, SQL Server 2005 Management Studio Express para realizar backups totales o incrementales. En las siguientes figuras se ve como acceder a dicha utilidad y como configurar la copia de seguridad. Se puede seleccionar la ubicación dentro del disco donde se creará el fichero.bak de recuperación. Para restaurar una base de datos desde un fichero de recuperación se puede hacer desde un fichero que contiene una copia completa y otros que contienen copias diferenciales o simplemente desde uno que contenga la copia completa. Se debe realizar, por tanto, una copia de seguridad completa al menos una vez al mes o semanalmente y copias diferenciales diarias para garantizar que en cualquier caso se conservarán los datos. 283

294 Figura A2.17 Acceso a la utilidad Backup desde el programa Management Studio Express Figura A2.18 Configuración del Backup de la base de datos. 284

295 A2.2. Mantenimiento y Evolución del sistema A2.2.1 Desarrollo de Nuevas Tareas Este apartado pretende servir de guía para el diseño de nuevas tareas a realizar por los agentes. Este proceso pasa por varias fases que se describen a continuación. Las tareas son acciones que pueden realizar los programas agente. Son programadas desde la aplicación de gestión para ser ejecutadas por la aplicación agente. Se registran en la base de datos y se comunican al agente cuando este realiza la solicitud asociándolas a éste mediante un id de máquina. Las tareas a realizar por los agentes pueden requerir de argumento en cuyo caso éste debería poder presentarse como una cadena de texto para su envío a través de la red hasta los agentes. Se podría realizar marshaling y unmarshaling del argumento para que así fuere. Antes de comenzar con una fase se recomienda leer este apartado entero para obtener una visión global de lo que implica diseñar una nueva tarea y de los distintos puntos de vista desde los que se pueden afrontar esta acción, conociendo qué es preferible para cumplir con los requisitos necesarios. Incluir la tarea en la base de datos Una tarea debe tener un nombre y un identificador. Las tareas están registradas en la base de datos y es necesario escoger un identificador que no este ya asociado a otra tarea. Se puede registrar esta información directamente sobre la base de datos en la tabla T_Tarea utilizando el programa Sql Server 2005 Studio Management Express. Si bien se ha incluido como primer paso, esto es para que se tenga conocimiento de la existencia de la configuración de la tarea con número identificador y nombre ya que se utilizará en el resto de puntos de este apartado. Esta acción debería de realizarse la última para no autorizar acceso a programar la nueva tarea hasta que no se hayan realizado los pasos necesarios para poder ejecutarla. A continuación se muestra una imagen del contenido de la tabla T_Tarea desplegada en el programa Sql Server 2005 Studio Management Express: 285

296 Figura A2.19 Registro de nueva tarea en la base de datos Desarrollar la tarea en el código del agente Las tareas son diseñadas para ser ejecutadas por los agentes. Es necesario, por tanto, desarrollar la ejecución de la tarea en el código de la aplicación agente. Para ello es necesario conocer la estructura del código: El control de tareas se realiza en cada intervalo de comunicación, en concreto, en el método ControlTareas de la clase EvoAgentService. Para agregar una tarea nueva sería necesario introducirla en una nueva cláusula case dentro del bucle switch(). La cláusula será: case "numero identificador de tarea": {Código desarrollado para ejecutar la tarea en la máquina y registrar resultados en el sistema.} break; Donde pone código desarrollado para ejecutar la tarea se debe incluir el código que permite ejecutar la nueva tarea diseñada. Si se requiere del registro de algún resultado en el sistema, habrá que incluir los pasos para la comunicación según se explica en el siguiente punto. En este punto del código se posee datos de la tarea; vienen representados en la variable ProxTarea que es un vector de strings: Id de tarea: Viene indicado en ProxTarea[0]. Necesario para poder pasar el resultado de la tarea. Al finalizar la ejecución de la tarea se debe construir un vector bajo el nombre de TareaRealizada donde se indica el resultado de la ejecución de la tarea. 286

297 Dicho vector está compuesto por tres strings que indican el id de la tarea, la fecha de ejecución y el resultado. Su creación será como se indica: TareaRealizada[0] = ProxTarea[0]; TareaRealizada[1] = DateTime.Now.ToString(); TareaRealizada[2] = resultado; Donde resultado será "1"si se ha ejecutado correctamente o "0" si ha habido algún error en la ejecución. Parámetro: Viene indicado en ProxTarea[2]. Para las tareas que requieran de un parámetro. El código puede desarrollarse en una nueva clase incluyendo una llamada a la misma o en esta sección. Una vez desarrollado el código e introducido como se ha indicado, el agente estará listo para poder ejecutar la nueva tarea. Registrar resultado de ejecución de la nueva tarea en el sistema Por ejemplo, la tarea Auditoría registra la nueva auditoría en el sistema, a lo que sigue un control de la misma iniciado por el módulo servidor para la generación de alertas. De la misma manera, una nueva tarea podrá requerir de registro de resultados en el sistema. Para ello se debe introducir modificaciones en varios puntos del sistema: Método Web en el Servicio ControlClientes del subsistema EvoAgentServer Se debe incluir un nuevo método web en el servicio web ControlClientes. Para ello, desde la solución EvoAgentProyect, abrir el proyecto EvoAgentServer y sobre el fichero ControlClientes.asmx del directorio ControlClientes pulsar para desplegar y abrir el fichero ControlClientes.asmx.cs o, clic con el botón derecho sobre el fichero y pulsar ver código. Se abrirá el código fuente del servicio web que contiene los métodos web a través de los que se comunican los agentes. public class ControlClientes : System.Web.Services.WebService { private String[] leer_informe_maquina(dataset ds){ } [WebMethod] public string AltaMaquinaCliente(DataSet ds){ } [WebMethod] public bool Comunica(){ } 287

298 Será necesario incluir un nuevo WebMethod para recibir el resultado de la nueva tarea. El método web debe contener una comprobación de la identidad del agente que se comunica. En el siguiente ejemplo de código se ha creado un método web que recibe el identificador del agente que quiere realizar el registro y el resultado a registrar. Realiza la comprobación de identidad del agente mediante la ejecución del método MaquinaDao.validaMaquina(idMaquina) que comprueba que la máquina está registrada y tiene permiso. El método web devuelve un valor booleano en función de si se ha registrado en el sistema el resultado sin problemas o no. Se puede crear un método para que devuelva cualquier valor. Igualmente, el argumento del método debe contener lo que se quiere registrar si bien se ha de saber que un método web puede recibir sólo variables primitivas del tipo cadenas de caracteres, vectores y datasets que contengan texto plano que es lo utilizado para enviar las auditorías. El registro debería pasar por el uso de una clase DAO de acceso a datos para guardar el resultado. Puede ser necesario crear una tabla en la base de datos para registrar los resultados de la nueva tarea o la solución que se estime más oportuna. Por último en el ejemplo se ha incluido un control de errores try{}catch{} que registra un error en el registro mediante el bloque catch creando un nuevo error de la aplicación (definido en el dominio) y registrándolo utilizando la clase DAO correspondiente. [WebMethod] public bool RegistraResultadoNuevaTarea(string idmaquina, resultado) { bool registrado = false; try { if (MaquinaDAO.validaMaquina(idMaquina)) { {Registro de resultado en el sistema} registrado = true; } } catch (Exception e) { ErrorAplicacionDAO.createNewError(new ErrorApliacion("Error_" + Guid.NewGuid().ToString().Remove(8) + "_" + DateTime.Now.Year.ToString() + DateTime.Now.Month.ToString() + DateTime.Now.Day.ToString(), DateTime.Now, "servidor", e.tostring()), AppDomain.CurrentDomain.BaseDirectory); } } return registrado; Una vez creado el método, para registrarlo en el servidor se debe publicar tal y como se indica en el apartado Proyecto EvoAgentServer del apartado A

299 Método en la clase ComunicacionServidor del agente: La clase comunicacionservidor definida en el agente posee todos los métodos a través de los cuales se comunica un agente con el servidor. Para ello, contiene una referencia al objeto ConfigAgente donde se ha inicializado la referencia al servicio web ControlClientes. Una vez se ha creado el método web en el punto anterior y se han publicado los cambios en el servidor es necesario actualizar la referencia al servicio web para que ésta contenga el método web creado. En la clase ComunicaciónServidor se deberá crear un nuevo método que registre el resultado de la nueva tarea utilizando una llamada al método web creado. Utilizará la clase ConfigAgente mediante su objeto instanciado _Config para llamar al servicio web y a su nuevo método web y también para obtener el identificador del agente que debe enviar como primer argumento de la llamada. Debe seguirse el código suministrado en el siguiente ejemplo para realizar el registro. En el ejemplo se devuelve al llamador un valor que indica si se ha registrado el resultado correctamente. public void registroresultadonuevatarea(resultado) { bool registrado = false; try { if (_Config.webService.registroResultadoNuevaTarea (_Config.idMaquina, resultado)) { registrado = true; } } catch (Exception e) { envioerror(e.tostring()); } } return registrado; Este método debería ser llamado al terminar la ejecución de la nueva tarea por parte del agente pasando el resultado que se quiere registrar en el sistema de dicha ejecución en un formato adecuado. Incluir la tarea en la aplicación de gestión para su programación En este paso se va ha ver qué se debe hacer para poder programar la nueva tarea para su ejecución por los agentes. Si la tarea no necesita de ningún argumento para ejecutarse no será necesario realizar ningún cambio en esta aplicación. 289

300 En cambio, si necesita de un argumento para ejecutarse será necesario realizar modificaciones en el código de la aplicación EvoAgentManager en las clases Form_ParametrosTareas y Form_NuevaTarea para poder configurar dicho parámetro. Clase Form_ParametrosTareas: Se trata de la ventana utilizada para configurar los parámetros de cualquier tarea. Lo primero es diseñar el interfaz mediante el cual se indicará el parámetro. Cuando se seleccione la nueva tarea se presentará al usuario esta ventana para que pueda introducir el parámetro. Se puede diseñar mediante un cuadro de texto o lo que sea necesario para poder configurar el parámetro. Esto se debe introducir en un control nuevo GroupBox como el que se ve a continuación. Figura A2.20 Diseño del parámetro de la nueva tarea El groupbox deberá llevar un nombre representativo de la nueva tarea. Se diseñará colocando el nuevo GroupBox sobre el último que hay diseñado e introduciendo en su interior lo necesario para configurar el parámetro. En cuanto al código será necesario lo siguiente: Método CargarTareas(). Mediante éste método se indica a esta ventana que tareas se van a configurar. Se obtiene como atributo las tareas y en función del nombre de la tarea se muestra el GroupBox diseñado para la configuración del parámetro de la tarea en cuestión. Aquí hay que añadir una nueva cláusua esle if en el interior del bucle foreach: foreach (Tarea t in _tareas) { this.combobox1.items.add(t.sdescripcion); if (t.sdescripcion == "Auditoria") { this.groupboxauditoria.visible = true; this.groupboxauditoria.bringtofront(); //Selecciono los elementos ha incluir inicialmente en una auditoría this.checkedlistbox1.setitemchecked(0, true); 290

301 } this.checkedlistbox1.setitemchecked(1, true); this.checkedlistbox1.setitemchecked(2, true); this.checkedlistbox1.setitemchecked(7, true); this.checkedlistbox1.setitemchecked(16, true); this.checkedlistbox1.setitemchecked(18, true); this.checkedlistbox1.setitemchecked(20, true); } else if (t.sdescripcion == "ComprobarCuotas") { this.groupboxcuotas.visible = true; this.groupboxcuotas.bringtofront(); } else if (t.sdescripcion == "InicioServicio") { this.groupboxservicio.visible = true; this.groupboxservicio.bringtofront(); } else if (t.sdescripcion == "EjecutarScript") { this.groupboxscript.visible = true; this.groupboxscript.bringtofront(); } Tras él último else if se debería incluir como mínimo lo siguiente: else if (t.sdescripcion == "nombre de la tarea") { this. nombre del nuevo groupbox.visible = true; this. nombre del nuevo groupbox.bringtofront(); } También se podría incluir el relleno de valores por defecto tal y como se ve en el caso de la auditoría. Nuevos Métodos get y set. Se deben configurar sendos métodos para obtener y configurar el valor del parámetro. En la clase se puede ver ejemplos de éstos métodos para otras tareas. El método get-nuevatarea-() sigue el formato: public string get-nuevatarea-() { {Obtener valor del parámetro} } Return valor del parámetro; Se debe devolver el valor del parámetro como una cadena de texto. Se realizarán las operaciones oportunas para convertir la configuración del parámetro en una cadena de texto. El método set-nuevatarea-() sigue el formato: 291

302 public void set-nuevatarea-(string valor del parámetro) { {Configurar valor del parámetro} } Se obtiene el párametro en formato string y se requiere establecer el valor actual utilizando los elementos diseñados para su configuración (Si es un cuadro de texto escribir directamente el valor ) Método combobox1_selectedindexchanged(): en este método se controla la interacción del usuario con el combobox de selección de tareas. Como se ha comentado, esta ventana permite configurar todos los parámetros de las tareas que lo necesiten. Para ir pasando entre las distintas tareas se ha creado un combobox en la parte superior (encima de los distintos GroupBox) donde se puede seleccionar la tarea a configurar. Cuando se seleccione la nueva tarea se debe mostrar el groupbox correspondiente. Para ello incluir tras el último else if lo siguiente: else if (this.combobox1.text == "nombre de la tarea") this. nombre del nuevo groupbox.bringtofront(); Clase Form_NuevaTarea: Se trata de la ventana utilizada para programar las tareas. Dicha ventana se encarga de obtener de la base de datos todas las tareas disponibles. La nueva tarea, si ha sido creada en la base de datos, será posible seleccionarla. Una tarea que no requiera de parámetros no necesitará de ninguna modificación en la interfaz. Sin embargo, para una tarea que requiere de la configuración de parámetros es necesario realizar las siguientes modificaciones: Variable Config: Todas las tareas que requieren de parámetros poseen una variable entera global de la clase que sirve para detectar cuando se ha seleccionado o deseleccionado la tarea. Es, por tanto, necesario crear una nueva variable siguiendo el estilo de las anteriores: private int ConfigAuditoria; private int ConfigServicio; private int ConfigCuotas; private int ConfigScript; Incluir private int Config-NuevaTarea Método settareasprogramacion(): Mediante esté método se establecen las tareas que han sido configuradas en una tarea programada para poder ser modificadas. Puede haber sido configuradas tareas que requieren de parámetro con lo cual se debe habilitar la ventana de configuración de parámetros. Esto se comprueba al final del método en la sentencia if: if (activar_parametros) 292

303 { List<Tarea> tareas_para_parametros = new List<Tarea>(); this._parametros = Form_ParametrosTareas.Default; this._parametros.mdiparent = this.mdiparent; int i; for (i = 0; i<selecciones.count; i++) { if (tareas[i].idtarea == 1) this._parametros.setseleccionauditoria(selecciones[i]); else if (tareas[i].idtarea == 4) this._parametros.setseleccionservicio(selecciones[i]); else if (tareas[i].idtarea == 5) this._parametros.setseleccioncuota(selecciones[i]); else if (tareas[i].idtarea == 7) this._parametros.setseleccionscript(selecciones[i]); tareas_para_parametros.add(tareas[i]); } this.parametros.tareas = tareas_para_parametros; this.parametros.cargatareas(); } this.editartoolstripmenuitem.enabled = true; Aquí seria necesario incluir tras el último else if lo siguiente: else if (tareas[i].idtarea == numero identificador de tarea) this._parametros.set-nuevatarea(selecciones[i]); donde set-nuevatarea es el método set creado en la clase Form_ParametrosTareas. Método buttontarea_click(): Este método se utiliza para controlar la selección de tareas. Si se ha seleccionado tareas que requieren de parámetros se deberá mostrar la ventana Form_PropiedadesTareas. Para ello sirve la variable Config creada anteriormente. El código del método es como sigue: private void buttontarea_click(object sender, EventArgs e) { if (this.combotarea.visible == true) { this.combotarea.visible = false; if (this.cambios_tarea == 1) { List<Tarea> tareas = null; if (this.configauditoria == 1) { tareas = new List<Tarea>(); tareas.add(new Tarea(1, "Auditoria")); 293

304 } if (this.configservicio == 1) { if (tareas == null) tareas = new List<Tarea>(); tareas.add(new Tarea(4, "InicioServicio")); } if (this.configcuotas == 1) { if (tareas == null) tareas = new List<Tarea>(); tareas.add(new Tarea(5, "ComprobarCuotas")); } if (this.configscript == 1) { if (tareas == null) tareas = new List<Tarea>(); tareas.add(new Tarea(7,"EjecutarScript")); } En este punto sería necesario incluir lo siguiente: if (this.config-nuevatarea == 1) { if (tareas == null) tareas = new List<Tarea>(); tareas.add(new Tarea(numero identificador de tarea, "nombre de la tarea")); } Método combotarea_selectedindexchanged(): Este método se utiliza para cambiar el valor de las variables config, según se ha seleccionado o no la tarea en cuestión, que se comprueban en el método anterior. Como se debe recorrer todas las tareas del cuadro se crean variables temporales que se comprueban al finalizar el recorrido. Así, en el punto: int i; bool auditar = false; bool inicios = false; bool configcuotas = false; bool ejecutarscript = false; Crear una nueva variable que haga referencia al config creado al principio pero poniendo atención en que tenga un nombre diferente, por ejemplo con c minúscula: bool config-nuevatarea= false; Un poco más abajo, en el bucle for incluir una nueva sentencia else if después de la última que hubiera: else if (this.combotarea.checkeditems[i].tostring() == "nombre de la tarea") { config-nuevatarea= true; } 294

305 Por último, debajo del bucle for incluir una comprobación por si se hubiera seleccionado la nueva tarea para activar la variable Config: if (config-nuevatarea) this. Config-NuevaTarea = 1; else this.config-nuevatarea = 0; Método archivotoolstripmenuitem_click(): Este método se utiliza para guardar la/s tarea/s configuradas mediante una llamada a la capa de datos. Antes debe obtener los datos de configuración de las tareas a guardar. Si se trata de la edición de una tarea se obtienen en este método. Así, en la sección correspondiente, se comienza comprobando si la tarea a editar tenía parámetros para, en caso de tenerlos, obtenerlos. Como se ve en el código de abajo, esto se hace mediante llamada al método get correspondiente de la clase Form_PropiedadesTareas. else { if (this._parametros!= null &&!this._parametros.isdisposed) { if (this.tareaentrada.idtarea == 1) this.tareaentrada.sseleccion = this._parametros.getseleccionauditoria(); else if (this.tareaentrada.idtarea == 4) this.tareaentrada.sseleccion = this._parametros.getseleccionservicio(); else if (this.tareaentrada.idtarea == 5) this.tareaentrada.sseleccion = this._parametros.getseleccioncuotas(); else if (this.tareaentrada.idtarea == 7) this.tareaentrada.sseleccion = this._parametros.getseleccionscript(); } Por tanto, tras el último else if incluir: else if (this.tareaentrada.idtarea == numero identificador de tarea) this.tareaentrada.sseleccion = this._parametros.get-nuevatarea(); Método getnewtareasmaquina(): Este método se utiliza para obtener la configuración de las nuevas tareas a guardar. Dentro del doble bucle foreach: if (m.idcliente == null) { if (t.sdescripcion == "Auditoria") tareasmaquina.add(new TareaMaquina( )); else if (t.sdescripcion == "InicioServicio") tareasmaquina.add(new TareaMaquina( )); 295

306 else if (t.sdescripcion == "ComprobarCuotas") { tareasmaquina.add(new TareaMaquina( )); MaquinaDAO.setRutaCuotas(m.idMaquina, this.parametros.getseleccioncuotas()); } else if (t.sdescripcion == "EjecutarScript") tareasmaquina.add(new TareaMaquina( )); else tareasmaquina.add(new TareaMaquina( )); } else { if (t.sdescripcion == "Auditoria") tareasmaquina.add(new TareaMaquina( )); else if (t.sdescripcion == "InicioServicio") tareasmaquina.add(new TareaMaquina( )); else if (t.sdescripcion == "ComprobarCuotas") { tareasmaquina.add(new TareaMaquina( )); MaquinaDAO.setRutaCuotas(m.idMaquina, this.parametros.getseleccioncuotas()); } else if (t.sdescripcion == "EjecutarScript") tareasmaquina.add(new TareaMaquina( )); else tareasmaquina.add(new TareaMaquina( )); } Para crear una TareaMaquina (perteneciente al dominio) se deben configurar los siguientes campos: public TareaMaquina(string idtareamaquina, string idmaquina, string host, string idcliente, string razon, int idtarea, string descripcion, string seleccion, DateTime fecha, string estado) Como se puede ver, el método se separa en dos bloques dependiendo de si la máquina seleccionada tiene un cliente asociado o no. Esto es así, porque en caso de no tenerlo la tarea tendría que tener valor nulo en cliente explícitamente. Los dos bloques son pues prácticamente iguales con la única diferencia de que en la creación de la tarea se incluye o no el valor del cliente. También se ve que el último else de cada bloque incluye a todas las tareas que no tienen parámetros. Por tanto, se debe incluir en cada bloque y entre el último else if y el último else, lo siguiente: En el primer bloque: else if (t.sdescripcion == "EjecutarScript") tareasmaquina.add( new TareaMaquina( Nuevo_idTarea(m.sNombreHost), m.idmaquina, m.snombrehost, null, null, t.idtarea, t.sdescripcion, this._parametros.get-nuevatarea(), this.nuevo_fecha(), "Pendiente") ); 296

307 En el segundo bloque: else if (t.sdescripcion == "EjecutarScript") tareasmaquina.add( new TareaMaquina( Nuevo_idTarea(m.sNombreHost), m.idmaquina, m.snombrehost, m.idcliente, m.srazon, t.idtarea, t.sdescripcion, this._parametros.get-nuevatarea(), this.nuevo_fecha(), "Pendiente") ); Método _parametros_disposed(): Este método se utiliza para de-seleccionar las tareas que requieren de parámetros si se cancela la configuración de los parámetros (cerrando la ventana Form_ParametrosTareas por ejemplo). En el bucle for incluir un nuevo if : if (this.combotarea.items[i].tostring() == "nombre de la tarea") { this.combotarea.setitemchecked(i, false); this.config-nuevatarea = 0; } Método editartoolstripmenuitem_click(): Este método se utiliza para mostrar la ventana Form_ParametrosTareas siempre que se quiera al pulsar sobre el botón editar parámetros. Cuando se está editando una tarea, al pulsar sobre este botón se crea de cero la ventana y es preciso establecer el valor de configuración del parámetro. Para ello, incluir tras el último else if lo siguiente: else if (this.tareaentrada.idtarea == numero identificador de tarea) { Tarea t = new Tarea(numero identificador de tarea, "nombre de la tarea"); List<Tarea> tareas = new List<Tarea>(); tareas.add(t); this._parametros.tareas = tareas; this._parametros.cargatareas(); this._parametros.set-nuevatarea(this.tareaentrada.sseleccion); } Actualizar los agentes para que puedan ejecutar la nueva tarea Anteriormente se ha visto como modificar el código de la aplicación agente para que éste pueda ejecutar una nueva tarea. Además, también se han visto posibles modificaciones en el código fuente de la aplicación agente para registrar el resultado de dicha tarea en el sistema. El cambio en el código fuente comprende que el agente deba evolucionar a una nueva versión para poder utilizar la herramienta de actualización automática del mismo. Esto implica que los agentes actualicen su código fuente obteniendo la nueva versión del servidor. Todo esto se explica en el punto A2.2.2 Gestión de Versiones. 297

308 Actualizar la aplicación EvoAgentManager para que los técnicos puedan programar la nueva tarea. Este paso no sería necesario si no se ha tocado el código fuente de la aplicación, es decir, si no es necesario configurar un parámetro para la ejecución de la nueva tarea. Si se ha realizado alguna modificación en el código, será necesario actualizar los programas EvoAgentManager de los ordenadores de los técnicos. No se ha desarrollado un sistema de actualización automática para este programa por lo que será necesario que los técnicos desinstalen e instalen la nueva versión del programa. Para ello colgar la nueva versión en la red de forma que los técnicos tengan acceso a ella. A2.2.2 Gestión de Versiones de la aplicación Agente En este apartado se muestra como funciona el sistema de actualizaciones automáticas de la aplicación agente y como llevar a cabo la actualización de los agentes a una versión posterior en un momento dado. Para ello se explica previamente el funcionamiento de Windows Installer y de los proyectos de instalación. Consultar también el apartado Proyecto EvoAgentSetup de este documento. Windows Installer y Proyectos de Implementación de aplicaciones Windows Installer es un servicio de Instalación y Configuración de aplicaciones que trabaja junto con el sistema operativo. Mantiene una base de datos con información sobre cada una de las aplicaciones que instala, incluyendo archivos, claves del registro y componentes. Esto hace que mediante un proyecto de instalación se pueda gestionar la actualización de una aplicación utilizando para ello las propiedades del proyecto de instalación Version, UpgradeCode y ProductCode. Para que Windows Installer compruebe la existencia de versiones anteriores en el sistema y lo tenga en cuenta durante la instalación se debe poner a true la propiedad RemovePreviousVersions. Dicha propiedad funciona de distinta manera dependiendo de la versión de Visual Studio con la que se trabaje como se puede ver en el link: En Visual Studio 2005 al encontrar una versión anterior de la aplicación (Mismo UpgradeCode, Diferente ProductCode y Menor Version) se llamaba a las acciones personalizadas como se muestra a continuación: v1.0.0 custom action Uninstall() v1.0.1 custom action Install() En los paquetes de instalación creados con Visual Studio 2008, la acción de desinstalación no es llamada, tratando solamente la instalación. En la instalación consulta la base de datos 298

309 de Windows Installer para saber los ficheros que contenía la antigua versión de una aplicación y compararlos con las que contiene el paquete que está instalando. Así, puede modificar los ficheros que han cambiado de una versión a otra. Es importante asegurar que ningún fichero que deba ser sustituido este en uso para evitar que Windows Installer provoque un reinicio de la máquina al finalizar la instalación. Configuración del Proyecto de Instalación EvoAgentSetup para las actualizaciones Dado que se trabajará en un futuro con Visual Studio 2008 se hace necesario determinar una configuración apropiada del proyecto de instalación para gestionar las versiones del programa agente. Del último párrafo del punto anterior se extrae la conclusión de que ante una actualización se producirá un error al instalar el servicio de Windows EvoAgentService debido a que no se desinstala la aplicación del servicio correspondiente a la versión anterior y el sistema operativo no permite registrar dos servicios con el mismo nombre. No se debe registrar el servicio de Windows EvoAgentService en caso de que se encuentre con una versión anterior. Para ello se acude a las acciones personalizadas y en la fase de instalación, en la acción de instalación del servicio (Primary output from EvoAgent(Active)) se incluye la condición NOT PREVIOUSVERSIONSINSTALLED sobre el cuadro de propiedades. 299

310 Figura A2.21 Condición de instalación del programa EvoAgent Para configurar la siguiente versión de la aplicación, en el paquete de instalación es necesario modificar la versión del programa para lo cual se debe modificar la propiedad Version vista en el apartado Proyecto EvoAgentSetup de este documento, en la Figura A2.9 y que se accede pulsando en el explorador de soluciones sobre el proyecto EvoAgentSetup. Si no está habilitado el cuadro Properties habilitarlo desde el menú principal Ver/Properties Window. En el cuadro Properties en la propiedad Version introducir la nueva versión. Visual Studio propondrá la modificación automática del código de producto (ProductCode). Pulsar SI. Configuración del Sistema para las actualizaciones Hasta aquí se ha visto como se ha configurado el paquete de instalación mediante el proyecto de instalación y que modificaciones se han de realizar en el mismo para obtener un paquete de instalación que actualice el programa agente existente. 300

311 Por otro lado, como se pretende que los agentes se actualicen automáticamente es necesario configurar el sistema para controlar las actualizaciones. La aplicación agente tiene un atributo o setting que le indica la versión de su código. Dicho setting tiene su análogo en el sistema que indica la última versión disponible de la aplicación agente. Los agentes consultan la versión disponible en cada comunicación con el servidor. Si un agente encontrara en una consulta que existe una versión diferente (no menor o mayor), procedería a solicitar al servidor la nueva versión de la aplicación. El servidor deberá proporcionar al agente una ruta desde donde bajarse la nueva versión. Con nueva versión, se entiende, un paquete de instalación msi de Windows Installer. Dicha ruta es otro setting del sistema. Para poder modificar los settings de versiones y ruta de descarga se ha habilitado una ventana en la aplicación de gestión: Figura A2.22 Configuración de los settings de Gestión de Versiones en el programa EvoAgentManager La versión que indica el setting de la aplicación agente se corresponde con la versión que se configura en el paquete de instalación. Para introducir la nueva versión desplegar la carpeta Properties del proyecto EvoAgent en el explorador de soluciones y abrir Settings haciendo doble clic sobre él: Figura A2.23 Abrir settings de la aplicación EvoAgent 301

312 Uno de los settings que aparece como string con el nombre de Version contiene en la columna Value el valor de la versión actual de la aplicación. Introducir la nueva versión de la aplicación, la misma que se ha introducido en el paquete de instalación, en el apartado anterior: Figura A2.24 Settings de la aplicación EvoAgent Por otro lado el programa Icono muestra la versión actual al pasar el ratón por el icono o al abrir las propiedades. Por tanto, es necesario actualizar la versión también en estos dos elementos. Para acceder al mensaje del icono abrir Form1 del proyecto EvoIcon haciendo doble clic sobre la forma en el explorador de soluciones. Pulsar el elemento NotifyIcon que aparece en la parte inferior en el modo diseño y abrir las propiedades. Modificar la versión en la propiedad Text que se ve en la siguiente figura: 302

313 Figura A2.25 Configuración de la versión en el Icono 1 Para modificar la versión en el cuadro Acerca de que proporciona una descripción del programa agente a los usuarios finales abrir AcercaDe haciendo doble clic sobre la forma en el explorador de soluciones. Pulsar sobre la primera etiqueta de texto y en el cuadro propiedades modificar la propiedad Text: 303

314 Figura A2.26 Configuración de la versión en el Icono 2 Una vez actualizadas las versiones faltaría adaptar las versiones de los ficheros que contiene cada aplicación. Este aspecto es consultado por Windows Installer a la hora de seleccionar los ficheros que deben ser modificados. Si se ha realizado un cambio en el código del ensamblado del agente debe reflejarse en. Para acceder a la versión de los ficheros hacerlo desde las Properties de cada proyecto, EvoAgent y EvoIcon: Figura A2.27 Properties del proyecto EvoAgent 304

315 Pulsar en Assembly Information y, en la ventana que se abre, actualizar la versión de los ficheros (File Version): Figura A2.28 Assembly Information del proyecto EvoAgent Una vez actualizadas todos los indicadores de versión, compilar primero los proyectos EvoAgent y EvoIcon y después el proyecto EvoAgentSetup. El resultado de esto último crea un paquete de Windows Installer que contiene la nueva versión de la aplicación Agente. Para que los agentes obtengan la nueva versión se debe modificar el setting del sistema que indica la última versión disponible como se ha visto en la figura A2.22. Los agentes comprobarán que existe una nueva versión disponible y le solicitarán la ruta desde donde bajar la nueva versión. Dicha ruta por defecto es el subdirectorio Repositorio situado en el directorio ControlClientes del Servidor. Allí, se deberá guardar el nuevo paquete de Windows Installer. Para obtener dicho paquete que se acaba de crear haya que acceder al directorio de trabajo a la ruta que se ve en la siguiente imagen: 305

316 Figura A2.29 Paquete de Instalación del programa Agente en el directorio de trabajo Copiar el fichero EvoAgentSetup.msi en el directorio \\ruta_servidor\controlclientes\repositorio\ donde ruta_servidor se corresponde con la ubicación física del directorio virtual en el Servidor, actualmente: evtsrv01\inetpub\evoagentserver. Por último, y como se verá más adelante es necesario modificar el nombre del fichero. El nombre debe ser: EvoAgentSetupV.V.msi donde V.V es la versión de la aplicación. Si se trata de una actualización a la versión 1.2, por ejemplo, el nombre del fichero creado será EvoAgentSetup1.2.msi y el número de versión introducido en todos los pasos hasta ahora será 1.2. El código del agente es el que se encarga de iniciar el proceso de comprobación de versión y actualización mediante descarga y ejecución del paquete de instalación. Para ello, en el código de la clase EvoAgentService.cs, en el método de Intervalo de comunicación se ha incluido una llamada al método ComprobarVersion de la clase ComunicacionServidor que se observa a continuación: 306

317 public bool ComprobarVersion() { bool versionok = true; try { versionok = _Config.webService.VersionAgenteOK( _Config.idMaquina, Properties.Settings.Default.Version); } catch (Exception e) { envioerror(e.tostring()); } return versionok; } Como se puede ver, el método llama a un método web del servicio ControlClientes mediante la referencia al mismo existene en la clase ConfigAgente instanciada y referenciada mediante la variable _Config en esta clase. Se pasa como parámetro el identificador de la máquina, propiedad de la misma clase y el setting Versión de la aplicación. A continuación se muestra el código del método web que recibe dichos parámetros, comprueba la validez del identificador de la máquina recibido y contrasta la versión recibida con el setting del sistema que indica la última versión disponible. [WebMethod] public bool VersionAgenteOK(string idmaquina, string versionagente) { bool versionok = true; try { if (MaquinaDAO.validaMaquina(idMaquina)) { string version_actual = SettingsDAO.getValorSetting(5); if (version_actual!= versionagente) versionok = false; } } catch (Exception e) { //Registro de error } return versionok; } El método devuelve un valor booleano que indica si la versión recibida es igual o no a la última versión disponible. De la misma manera, el método ComprobarVersion anterior también devuelve un valor booleano. En caso de ser igual a false, el agente llama al método InstalarUltimaVersion de la propia clase EvoAgentService que se ilustra a continuación. 307

318 private void InstalaUltimaVersion(ComunicacionServidor com) { Process actualizacion = new Process(); string URL = com.getrutarepositorio(); if (URL!= null && URL!= "0") { try { com.envioaccion("09-existe una version nueva disponible. Descargando la última versión"); string nombrefichero = descargararchivo(url, "Instalador.msi"); StreamWriter sw = File.CreateText(config.workingDirectory + "Instalar.bat"); sw.writeline(nombrefichero); sw.close(); try { Process icon = Process.GetProcessesByName("EvoIcon")[0]; icon.kill(); } catch (Exception e){ } com.envioaccion("091-comienza la instalación de la última versión"); } } actualizacion.startinfo.workingdirectory = config.workingdirectory; actualizacion.startinfo.filename = "Instalar.bat"; actualizacion.startinfo.createnowindow = true; actualizacion.start(); actualizacion.priorityclass = ProcessPriorityClass.Idle; } catch (Exception e) { com.envioerror(e.tostring()); } El método anterior se encarga de gestionar el proceso de descarga y ejecución del instalador. Para ello, la primera acción es obtener la ruta del repositorio de donde descargarse el archivo. Como se ha comentado se obtiene de un setting del sistema a través del servidor. Como de costumbre se utiliza un método en la clase ComunicacionServidor que realiza la llamada a un método web del servicio ControlClientes: 308

319 public string getrutarepositorio() { string URL = null; try { URL = _Config.webService.getRutaRepositorio(_Config.idMaquina); } catch (Exception e) { envioerror(e.tostring()); } return URL; } [WebMethod] public string getrutarepositorio(string idmaquina) { string ruta = "0"; try { if (MaquinaDAO.validaMaquina(idMaquina)) ruta = AjustaCadena.AjustaNPalabras( SettingsDAO.getValorSetting(6)) + "EvoAgentSetup" + AjustaCadena.AjustaNPalabras( SettingsDAO.getValorSetting(5)) + ".msi"; } catch (Exception e) { //Registro de error } } return ruta; El método web valida el identificador de la máquina que realiza la solicitud. Posteriormente obtiene la ruta que es el resultado de concatenar el setting de ruta de repositorio con el nombre del fichero EvoAgentSetup más el setting de Versión (Se ha modificado el nombre del fichero previamente para que se pueda identificar así) v.v más la extensión,.msi. A través del método anterior se devuelve la URL al servicio. El servicio llama a la función descargararchivo para descargar el paquete de instalación de la ruta obtenida, crea un fichero.bat para ejecutarlo y antes de iniciar la instalación detiene el proceso EvoIcon para que el proceso no provoque el reinicio del equipo. Cuando empieza la instalación, Windows Installer detiene el servicio por encontrarlo asociado al paquete que quiere actualizar. No hace lo mismo con el Icono pues no es instalado sino un ejecutable que se arranca con una entrada en el registro de arranque de la máquina. La función de descarga del fichero utiliza conexiones HttpWebRequest y HttpWebResponse para descarga un stream de bytes que luego se leen y pasan a un stream de escritura. 309

320 Resumen de los pasos para la actualización del programa agente Se resume los pasos necesarios para actualizar los programas agente. Como ejemplo se pone la actualización de la versión 1.1 a la versión 1.2: 1. Una vez modificado el programa agente, En Settings del proyecto EvoAgent modificar el Setting Version a 1.2. En properties, pulsar en Assembly Information y actualizar el valor File Version para que sea 1 en el primer espacio y 2 en el segundo. 2. En el proyecto EvoIcon, a. Abrir Form1, seleccionar el elemento NotifyIcon y modificar la propiedad Text para que ponga EvoAgent v1.2. b. Abrir AcercaDe, seleccionar la primera etiqueta cuyo valor indica la versión del agente y modificar la propiedad Text para que ponga EvoAgent v1.2. c. Abrir Properties y pulsar en Assembly Information. Actualizar el valor File Version para que sea 1 en el primer espacio y 2 en el segundo. 3. Compilar (Build o Generar) los proyectos EvoAgent y EvoIcon. 4. En el proyecto EvoAgentSetup, modificar la propiedad Version a y aceptar el cambio automático del ProductCode. 5. Compilar (Build o Generar) el proyecto EvoAgentSetup. 6. Acceder al paquete de Windows installer de la ruta EvoAgentProyect/EvoAgentService/EvoAgentSetup/Debug/EvoAgentSetup.msi. Copiar dicho fichero y pegar en la ruta del directorio virtual del servidor: //evtsrv01/inetpub/evoagentserver/controlclientes/repositorio/. Modificar el nombre del fichero para que se indique la versión: EvoAgentSetup1.2.msi 7. Abrir la aplicación EvoAgentManager, acceder al apartado settings y dentro de settins a gestión de Versiones. Modificar la última versión disponible a 1.2 y asegurar que la ruta del repositorio es correcta y accesible. 310

321 Anexo 3. Tecnologías A3.1 Tecnología.NET A continuación se presentan varios aspectos que tienen que ver con la tecnología.net.net Framework El "framework" o marco de trabajo, constituye la base de la plataforma.net y denota la infraestructura sobre la cual se reúnen un conjunto de lenguajes, herramientas y servicios que simplifican el desarrollo de aplicaciones en entorno de ejecución distribuido. Bajo el nombre.net Framework o Marco de trabajo.net se encuentran reunidas una serie de normas impulsadas por varias compañías además de Microsoft (como Hewlett- Packard, Intel, IBM, Fujitsu Software, Plum Hall, la Universidad de Monash e ISE), entre las cuales se encuentran: La norma que define las reglas que debe seguir un lenguaje de programación para ser considerado compatible con el marco de trabajo.net (ECMA-335, ISO/IEC 23271). Por medio de esta norma se garantiza que todos los lenguajes desarrollados para la plataforma ofrezcan al programador un conjunto mínimo de funcionalidad, y compatibilidad con todos los demás lenguajes de la plataforma. La norma que define el lenguaje C# (ECMA-334, ISO/IEC 23270). Este es el lenguaje insignia del marco de trabajo.net, y pretende reunir las ventajas de lenguajes como C/C++ y Visual Basic en un solo lenguaje. La norma que define el conjunto de funciones que debe implementar la librería de clases base (BCL por sus siglas en inglés) (incluido en ECMA-335, ISO/IEC 23271). Tal vez el más importante de los componentes de la plataforma, esta norma define un conjunto funcional mínimo que debe implementarse para que el marco de trabajo sea soportado por un sistema operativo. Aunque Microsoft implementó esta norma para su sistema operativo Windows, la publicación de la norma abre la posibilidad de que sea implementada para cualquier otro sistema operativo existente o futuro, permitiendo que las aplicaciones corran sobre la plataforma independientemente del sistema operativo para el cual haya sido implementada. El Proyecto Mono emprendido por Ximian pretende realizar la implementación de la norma para varios sistemas operativos adicionales bajo el marco del software libre o código abierto. Los principales componentes del marco de trabajo son: El conjunto de lenguajes de programación 311

322 La Biblioteca de Clases Base o BCL El Entorno Común de Ejecución para Lenguajes o CLR por sus siglas en inglés. Debido a la publicación de la norma para la infraestructura común de lenguajes (CLI por sus siglas en inglés), el desarrollo de lenguajes se facilita, por lo que el marco de trabajo.net soporta ya más de 20 lenguajes de programación y es posible desarrollar cualquiera de los tipos de aplicaciones soportados en la plataforma con cualquiera de ellos, lo que elimina las diferencias que existían entre lo que era posible hacer con uno u otro lenguaje. Algunos de los lenguajes desarrollados para el marco de trabajo.net son: C#, Visual Basic, Delphi (Object Pascal), C++, J#, Perl, Python, Fortran y Cobol.NET. Common Lenguage Runtime (CLR) El CLR es el verdadero núcleo del Framework de.net, entorno de ejecución en el que se cargan las aplicaciones desarrolladas en los distintos lenguajes, ampliando el conjunto de servicios del sistema operativo (W2k y W2003). La herramienta de desarrollo compila el código fuente de cualquiera de los lenguajes soportados por.net en un código intermedio (MSIL, Microsoft Intermediate Lenguaje), similar al BYTECODE de Java. Para generar dicho código el compilador se basa en el Common Language Specification (CLS) que determina las reglas necesarias para crear ese código MSIL compatible con el CLR. Para ejecutarse se necesita un segundo paso, un compilador JIT (Just-In-Time) es el que genera el código máquina real que se ejecuta en la plataforma del cliente. De esta forma se consigue con.net independencia de la plataforma hardware. La compilación JIT la realiza el CLR a medida que el programa invoca métodos, el código ejecutable obtenido, se almacena en la memoria caché del ordenador, siendo recompilado de nuevo sólo en el caso de producirse algún cambio en el código fuente. 312

323 Figura A3.1 Entorno CLR 313

324 Figura A3.2 Librería de Clases Lenguaje de Programación C# C# (pronunciado "si sharp" o C sostenido) es un lenguaje de programación orientado a objetos desarrollado y estandarizado por Microsoft como parte de su plataforma.net, que después fue aprobado como un estándar por la ECMA e ISO. Su sintaxis básica deriva de C/C++ y utiliza el modelo de objetos de la plataforma.net el cual es similar al de Java aunque incluye mejoras derivadas de otros lenguajes (más notablemente de Delphi y Java). C# fue diseñado para combinar el control a bajo nivel de lenguajes como C y la velocidad de programación de lenguajes como Visual Basic. C# significa, "do sostenido" (C corresponde a do en la terminología musical anglo-sajona). El símbolo # viene de sobreponer "++" sobre "++" y eliminar las separaciones, indicando así su descendencia de C++. C#, como parte de la plataforma.net, está normalizado por ECMA desde diciembre de 2001 (ECMA-334 "Especificación del Lenguaje C#"). El 7 de noviembre de 2005 acabó la beta y salió la versión 2.0 del lenguaje que incluye mejoras tales como tipos genéricos, métodos anónimos, iteradores, tipos parciales y tipos anulables. Ya existe la versión 3.0 de C# en fase de beta destacando los tipos implícitos y el LINQ (Language Integrated Query). Aunque C# forma parte de la plataforma.net, ésta es una interfaz de programación de aplicaciones; mientras que C# es un lenguaje de programación independiente diseñado para generar programas sobre dicha plataforma. Aunque aún no existen, es posible implementar compiladores que no generen programas para dicha plataforma, sino para una plataforma diferente como Win32 o UNIX. Visual Studio 2005 Visual Studio.NET es un IDE (Editor Integrado de Desarrollo) desarrollado por Microsoft a partir de Es para el sistema operativo Microsoft Windows y está pensado, principal pero no exclusivamente, para desarrollar para plataformas Win

325 Figura A3.3 Visual Studio 2005 La última versión en línea de IDEs, Visual Studio.NET soporta los nuevos lenguajes.net: C#, Visual Basic.NET y Managed C++, además de C++. Visual Studio.NET puede utilizarse para construir aplicaciones dirigidas a Windows (utilizando Windows Forms), Web (usando ASP.NET y Servicios Web) y dispositivos portátiles (utilizando.net Compact Framework). El aspecto de Visual Studio.NET es casi idéntico a las versiones anteriores del IDE (Microsoft Visual Studio). Algunas excepciones destacables son la interfaz más limpia y mayor cohesión. También es más personalizable con ventanas informativas de estado que automáticamente se ocultan cuando no se usan. Todas las versiones de Visual Studio, también su predecesora Visual C++, incluyen un depurador integrado en el entorno de edición. La característica más notable del IDE es su soporte de los nuevos lenguajes.net. Los programas desarrollados en esos lenguajes no se compilan a código máquina ejecutable (como por ejemplo hace C++) sino que son compilados a algo llamado CIL. Cuando los programas ejecutan la aplicación CIL, ésta es compilada en ese momento al código de máquina apropiado para la plataforma en la que se está ejecutando. Mediante este método, Microsoft espera poder soportar varias implementaciones de sus sistemas operativos Windows (como Windows CE). Los programas compilados a CIL pueden ejecutarse sólo en plataformas que tengan una implementación de.net framework. Es posible ejecutar programas CIL en Linux o en Mac OS X utilizando algunas implementaciones.net que no pertenecen a Microsoft, como Mono y DotGNU. 315

326 La versión definitiva en inglés vio la luz en Noviembre del En castellano hubo que esperar hasta Febrero de Incorpora.NET Framework 2.0. Hay más ediciones diferenciadas por el precio y las características. Ayuda con refactorización. El desarrollo de páginas con ASP.NET ha cambiado. Soporte para el nuevo software servidor Team System. Añadido soporte de tests para todo tipo de aplicaciones. Dynamic Linking Library (dll) Técnicamente se refiere con este término a archivos con código ejecutable que se cargan bajo demanda del programa por parte del sistema operativo. Esta denominación se refiere a los sistemas operativos Windows siendo la extensión con la que se identifican los ficheros, aunque el concepto existe en prácticamente todos los sistemas operativos modernos. Las DLLs son o pueden verse como la evolución de las bibliotecas estáticas y de forma análoga contienen funcionalidad o recursos que utilizan otras aplicaciones. Sin embargo, su uso proporciona algunas ventajas: Reducen el tamaño de los archivos ejecutables: Gran parte del código puede estar almacenado en bibliotecas y no en el propio ejecutable lo que redunda en una mejor modularización. Pueden estar compartidas entre varias aplicaciones: Si el código es suficientemente genérico, puede resultar de utilidad para múltiples aplicaciones. Facilitan la gestión y aprovechamiento de la memoria del sistema: La carga dinámica permite al sistema operativo aplicar algoritmos que mejoren el rendimiento del sistema cuando se carguen estas bibliotecas. Además, al estar compartidas, basta con mantener una copia en memoria para todos los programas que la utilicen. Brindan mayor flexibilidad frente a cambios: Es posible mejorar el rendimiento o solucionar pequeños errores distribuyendo únicamente una nueva versión de la biblioteca dinámica. Nuevamente, está corrección o mejora será aprovechada por todas las aplicaciones que compartan la biblioteca. 316

327 Visual Studio Permite generar Proyectos cuya solución sea una librería dinámica. De ésta forma, y ya pensando en el diseño de la aplicación, se podrá tener un proyecto de Visual Studio que contenga elementos comunes a todo el sistema como el modelo de dominio o la lógica de negocio o acceso a datos y simplemente será necesario agregar dicha librería a cada una de las aplicaciones del sistema. Esto permitirá coherencia entre las aplicaciones que conforman el sistema además de proveer un punto común de evolución del mismo. A3.2 Servicio de Windows Aplicaciones de servicio frente a otras aplicaciones de Visual Studio Las aplicaciones de servicios funcionan, en varios aspectos, de forma diferente a muchos otros tipos de proyectos: El archivo ejecutable compilado que crea un proyecto de aplicación de servicios debe instalarse en el servidor para que el proyecto pueda funcionar de forma significativa. Es necesario instalar e iniciar el servicio y, a continuación, adjuntar un depurador al proceso del servicio. A diferencia de algunos tipos de proyectos, se deberá crear componentes de instalación para las aplicaciones de servicios. Los componentes de instalación instalan y registran el servicio en el ordenador y crean una entrada para el servicio con el Administrador de control de servicios de Windows. El método Main para la aplicación de servicios debe emitir el comando Run para los servicios que contiene el proyecto. El método Run carga los servicios en el Administrador de control de servicios del ordenador adecuado. Si se utiliza la plantilla de proyecto Servicios de Windows, este método se escribirá automáticamente. Las aplicaciones de servicios de Windows se ejecutan en una sesión de ventana diferente a la sesión interactiva del usuario que ha iniciado una sesión. Una estación de ventana es un objeto seguro que contiene un Portapapeles, un conjunto de átomos globales y un grupo de objetos de escritorio. Puesto que la estación de un servicio de Windows no es interactiva, los cuadros de diálogo que proceden de una aplicación de servicio de Windows no se ven y pueden causar que el programa deje de responder. Asimismo, es recomendable registrar los mensajes de error en el registro de eventos de Windows, en lugar de hacerlo en la interfaz del usuario. Las clases de servicios de Windows compatibles con.net Framework no admiten la interacción con estaciones interactivas, es decir, con el usuario que ha iniciado una sesión. 317

328 .NET Framework tampoco incluye clases que representen estaciones y escritorios. Si el servicio de Windows debe interactuar con otras estaciones, deberá obtener acceso a la API de Windows no administrada. La interacción del servicio de Windows con el usuario u otras estaciones debe diseñarse con cuidado para que incluya casos como, por ejemplo, que no exista un usuario que haya iniciado una sesión o que el usuario tenga un conjunto inesperado de objetos de escritorio. En algunos casos, puede ser más apropiado escribir una aplicación para Windows que se ejecute bajo el control del usuario. Las aplicaciones de servicios de Windows se ejecutan en su propio contexto de seguridad y se inician antes de que el usuario inicie la sesión en el equipo Windows en el que se encuentran instaladas. Debe considerar detenidamente en qué cuenta de usuario se ejecutará el servicio; un servicio que se ejecute bajo la cuenta del sistema tendrá más permisos y privilegios que una cuenta de usuario. Ciclo de vida de los servicios Un servicio pasa por varios estados internos a lo largo de su vida útil. En primer lugar, se instala el servicio en el sistema en el que se ejecutará. Este proceso ejecuta los instaladores para el proyecto del servicio y carga el servicio en el Administrador de control de servicios del equipo. El Administrador de control de servicios es la utilidad central que proporciona Windows para administrar servicios. Una vez cargado el servicio, es necesario iniciarlo. Al iniciar el servicio, se permite que empiece a funcionar. Puede iniciar un servicio desde el Administrador de control de servicios, desde el Explorador de servidores o desde código llamando al método Start. El método Start pasa el procesamiento al método OnStart de la aplicación y procesa el código que haya definido allí. Un servicio en ejecución puede permanecer indefinidamente en este estado, hasta que se detiene o se pausa, o hasta que se apaga el equipo. Un servicio puede estar en uno de estos tres estados básicos: Running, Paused o Stopped. El servicio también puede informar del estado de un comando pendiente: ContinuePending, PausePending, StartPending o StopPending. Estos estados indican que se emitió un comando, por ejemplo, para hacer una pausa en un servicio en ejecución, pero que el comando aún no se ejecutó. Puede consultar Status para determinar en qué estado se encuentra el servicio, o bien utilizar WaitForStatus para realizar una acción cuando se produzca uno de estos estados. Puede pausar, detener o reanudar un servicio desde el Administrador de control de servicios, desde el Explorador de servidores o llamando a los métodos adecuados desde el código. Cada una de estas acciones puede llamar a un procedimiento asociado en el servicio (OnStop, OnPause u OnContinue), en el cual es posible definir procesos adicionales que se realizarán cuando cambie el estado del servicio. 318

329 Implementar e instalar servicio Visual Studio incluye componentes de instalación que pueden instalar recursos asociados a las aplicaciones de servicios. Los componentes de instalación registran un servicio individual en el sistema en el que se está instalando y permiten que el Administrador de control de servicios conozca la existencia del servicio. Después de agregar instaladores a la aplicación, el siguiente paso consiste en crear un proyecto de instalación que instale los archivos de proyecto compilados y ejecute los instaladores necesarios para instalar el servicio. Para crear un proyecto de instalación completo, se debe agregar el resultado del proyecto de servicio al proyecto de instalación y, a continuación, agregar una acción personalizada para instalar el servicio. A3.3 Internet Information Server (IIS) IIS, es una serie de servicios para los ordenadores que funcionan con Windows. Originalmente era parte del Option Pack para Windows NT. Luego fue integrado en otros sistemas operativos de Microsoft destinados a ofrecer servicios, como Windows 2000 o Windows Server Windows XP Profesional incluye una versión limitada de IIS. Los servicios que ofrece son: FTP, SMTP, NNTP y HTTP/HTTPS. Este servicio convierte a un ordenador en un servidor de Internet o Intranet es decir que en las computadoras que tienen este servicio instalado se pueden publicar páginas Web tanto local como remotamente (servidor Web). El servidor Web se basa en varios módulos que le dan capacidad para procesar distintos tipos de páginas, por ejemplo Microsoft incluye los de Active Server Pages (ASP) y ASP.NET. También pueden ser incluidos los de otros fabricantes, como PHP o Perl. La versión actual de IIS es la 6.0 para Windows Server 2003 e IIS 5.1 para Windows XP Profesional. IIS 5.1 para Windows XP es una versión compacta del IIS que soporta solo 10 conexiones simultaneas y solo un sitio Web, aunque puede ser extensible mediante el manejo de AdminScripts instaladas en la ruta del servidor. En el presente proyecto se trabajará con las versiones actuales mencionadas, IIS 5.1 para el entorno de desarrollo e IIS 6.0 para el entorno de producción. Windows Vista viene con IIS 7.0 preinstalado. No limitará el número de conexiones permitidas pero limitará el flujo de tareas basándose en las solicitudes activas concurrentes, mejorando la usabilidad y el rendimiento en escenarios punto-a-punto (peer-to-peer). 319

330 Figura A3.4 Administrador de IIS 7.0 para Windows Vista A3.3.1 Sitios Web IIS gestiona sitios Web. Un sitio Web (en inglés: Website) es un conjunto de páginas Web, típicamente comunes a un dominio en Internet o subdominio en la World Wide Web en Internet. Una página Web es un documento HTML/XHTML accesible generalmente mediante el protocolo HTTP de Internet. 320

331 Figura A3.5 Sitio Web en IIS 7.0 A las páginas de un sitio Web se accede desde una URL raíz común llamada portada, que normalmente reside en el mismo servidor físico. Las URLs organizan las páginas en una jerarquía, aunque los hiperenlaces entre ellas controlan cómo el lector percibe la estructura general y cómo el tráfico Web fluye entre las diferentes partes de los sitios. Los sitios Web están escritos en HTML (Hyper Text Markup Language), o dinámicamente convertidos a éste y se acceden usando un cliente http, navegador Web o cualquier otro. Los sitios Web pueden ser visualizados o accedidos desde un abanico de dispositvos con disponibilidad de Internet como computadoras personales, computadores portatiles, PDAs y telefónos móviles. 321

332 Figura A3.6 Acceso a Sitio Web en Windows Internet Explorer En IIS se pueden configurar los sitios Web para que se acceda a ellos a través de un puerto TCP diferente al puerto TCP por defecto para los servidores Web, los tipos MIME que son reconocidos, la versión del ASP.NET que se utiliza así como una serie de parámetros propios de un sitio Web: (Control de acceso, seguridad, configuración ssl ). Al configurar los sitios Web debe indicar los directorios que contienen los documentos que desea publicar. El servidor Web no puede publicar documentos que no están en los directorios especificados. Cada sitio Web o FTP debe tener un directorio particular. El directorio particular es la ubicación central de las páginas publicadas. En este caso, por seguridad del sitio Web, conviene crear un directorio particular diferente al que viene por defecto. Uno de los parámetros configurables corresponde a la seguridad de acceso a un sitio web o a un directorio particular del mismo. Se accede (IIS 7.0) desde las propiedades del sitio web o directorio y ofrece varias posibilidades: 322

333 Figura A3.7 Configuración del método de Autenticación en IIS 7.0 La configuración de un sitio web o de un directorio se registra en un archivo xml llamado web.config como puede observarse en la parte inferior de la figura 2.7. Autenticación anónima: cuando se activa el acceso anónimo, no se requieren credenciales de usuario autenticado para tener acceso al sitio. El uso más adecuado de esta opción es para conceder acceso público a la información que no requiere seguridad. Cuando un usuario intenta conectarse al sitio Web, IIS asigna la conexión a la cuenta IUSER_ nombredeequipo, donde nombredeequipo es el nombre del servidor en el que se está ejecutando IIS. De forma predeterminada, la cuenta IUSER_ nombredeequipo es miembro del grupo Invitados. Este grupo tiene restricciones de seguridad, impuestas por los permisos del sistema de archivos NTFS, que indican el nivel de acceso y el tipo de contenido que está disponible para los usuarios públicos. Se puede configurar la cuenta de Windows que se utiliza para el acceso anónimo. Autenticación básica: la autenticación básica requiere un Id. de usuario y una contraseña, y proporciona un nivel bajo de seguridad. Las credenciales del usuario se envían en texto sin cifrar a través de la red. Este formato proporciona un nivel bajo de 323

334 seguridad, porque casi todos los analizadores de protocolo pueden leer la contraseña. Sin embargo, es compatible con el número más amplio de clientes Web. El uso más adecuado de esta opción es para conceder acceso a información con poca o ninguna necesidad de privacidad. Autenticación de Windows: anteriormente se denominaba NTLM o autenticación por desafío/respuesta de Windows NT. Este método envía la información de autenticación del usuario por la red en forma de vale de Kerberos y proporciona un alto nivel de seguridad. La autenticación de Windows integrada utiliza la versión 5 de Kerberos y la autenticación NTLM. Para emplear este método, los clientes deben utilizar Microsoft Internet Explorer 2.0 o posterior. Adicionalmente, la autenticación de Windows integrada no se admite sobre conexiones de proxy HTTP. El uso más adecuado de esta opción es para una intranet, donde el usuario y el servidor Web están en el mismo dominio, y los administradores pueden asegurarse de que todos los usuarios utilizan Internet Explorer 2.0 o posterior. Autenticación mediante formularios: La autenticación de formularios hace referencia a un sistema en el que la solicitudes no autenticadas se redirigen a un formulario de Lenguaje de marcado de hipertexto (HTML) en el que los usuarios escriben sus credenciales. Una vez que el usuario proporciona las credenciales y envía el formulario, la aplicación autentica la solicitud y el sistema emite un vale de autorización en el formulario de una cookie. Esta cookie contiene las credenciales o una clave para readquirir la identidad. Las solicitudes subsiguientes del explorador automáticamente incluyen la cookie. Suplantación de ASP.NET: Corresponde más que a un método alternativo de autenticación o un añadido en el proceso de autenticación de aplicaciones web. El escenario de suplantación se basa en la autenticación de Servicios de Microsoft Internet Information Server (IIS) y en la seguridad de acceso a archivos de Microsoft Windows para minimizar la programación de la seguridad en la propia aplicación ASP.NET. El flujo de datos se muestra en la ilustración siguiente. 324

335 Figura A3.8 Proceso de Autenticación de aplicaciones Web. En la figura 2.8 se muestra la siguiente secuencia de eventos: 1. Una solicitud de un cliente de red llega a IIS. 2. IIS autentica al cliente utilizando la seguridad básica, implícita o integrada de Windows (NTLM o Kerberos). 3. Si se autentica al cliente, IIS pasa la solicitud autenticada a ASP.NET. 4. La aplicación ASP.NET suplanta al cliente que realiza la solicitud utilizando el símbolo (token) de acceso pasado desde IIS, y se basa en los permisos de archivo NTFS para conceder acceso a los recursos. La aplicación ASP.NET sólo necesita comprobar que la suplantación está establecida en true en el archivo de configuración de ASP.NET; no se requiere ningún código de seguridad de ASP.NET. Si la suplantación no está habilitada, la aplicación se ejecuta con la identidad de proceso de ASP.NET. En Microsoft Windows 2000 Server y Windows XP 325

336 Professional, la identidad predeterminada es una cuenta local denominada ASPNET que se crea automáticamente al instalar ASP.NET. En Microsoft Windows Server 2003, la identidad predeterminada es la del grupo de aplicaciones correspondiente a la aplicación IIS (de manera predeterminada, la cuenta Servicio de red)..net proporciona dentro de su entorno de desarrollo la posibilidad de crear, desarrollar y organizar sitios web Figura A3.9 Proyecto de Sitio Web en Visual Studio2005 A3.4 Servicios Web La funcionalidad de los protocolos empleados es la siguiente: 326

337 XML( extensible Markup Language): Un servicio Web es una aplicación Web creada en XML. WSDL (Web Services Definition Service): Este protocolo se encarga de describir el Web service cuando es publicado. Es el lenguaje XML que los proveedores emplean para describir sus Web services. SOAP (Simple Object Access Protocol): Permite que programas que corren en diferentes sistemas operativos se comuniquen. La comunicación entre las diferentes entidades se realiza mediante mensajes que son rutados en un sobre SOAP. UDDI (Universal Description Discovery and Integration): Este protocolo permite la publicación y localización de los servicios. Los directorios UDDI actúan como una guía telefónica de Web services. Aunque la idea de la programación modular no es nueva, el éxito de esta tecnología reside en que se basa en estándares conocidos en los que ya se tiene una gran confianza, como el XML. Además, el uso de los Web services aporta ventajas significativas a las empresas. El principal objetivo que se logra, es la interoperabilidad y la integración. Mediante los Web services, las empresas pueden compartir servicios software con sus clientes y sus socios de negocio. Esto ayudará a las compañías a escalar sus negocios, reduciendo el coste en desarrollo y mantenimiento de software, y sacando los productos al mercado con mayor rapidez. La integración de aplicaciones hará posible obtener la información demandada en tiempo real, acelerando el proceso de toma de decisiones. Protocolo SOAP Son las siglas de Simple Object Access Protocol. Este protocolo deriva de un protocolo creado por David Winer, XML-RPC en En su sitio Web, Userland, se puede encontrar multitud de documentación acerca de este primer protocolo de comunicación bajo http mediante XML. Con este protocolo se pedían realizar RPC o remote procedure calls, es decir, podíamos bien en cliente o servidor realizar peticiones mediante http a un servidor Web. Los mensajes debían tener un formato determinado empleando XML para encapsular los parámetros de la petición. Con el paso del tiempo el proyecto iniciado por David Winer interesó a Importantes multinacionales entre las que se encuentran IBM y Microsoft y de este interés por XML-RPC se desarrollo SOAP." En el núcleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP, que proporciona un mecanismo estándar de empaquetar mensajes. SOAP ha recibido gran atención debido a que facilita una comunicación del estilo RPC entre un cliente y un servidor 327

338 remoto. Pero existen multitud de protocolos creados para facilitar la comunicación entre aplicaciones, incluyendo RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA. Una de las razones principales es que SOAP ha recibido un increíble apoyo por parte de la industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prácticamente por todas las grandes compañías de software del mundo. Compañías que en raras ocasiones cooperan entre sí están ofreciendo su apoyo a este protocolo. Algunas de las mayores Compañías que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba. Algunas de las Ventajas de SOAP son: No esta asociado con ningún lenguaje: los desarrolladores involucrados en nuevos proyectos pueden elegir desarrollar con el último y mejor lenguaje de programación que exista pero los desarrolladores responsables de mantener antiguas aflicciones heredadas podrían no poder hacer esta elección sobre el lenguaje de programación que utilizan. SOAP no especifica una API, por lo que la implementación de la API se deja al lenguaje de programación, como en Java, y la plataforma como Microsoft.Net. No se encuentra fuertemente asociado a ningún protocolo de transporte: La especificación de SOAP no describe como se deberían asociar los mensajes de SOAP con HTTP. Un mensaje de SOAP no es más que un documento XML, por lo que puede transportarse utilizando cualquier protocolo capaz de transmitir texto. No está atado a ninguna infraestructura de objeto distribuido La mayoría de los sistemas de objetos distribuidos se pueden extender, y ya lo están alguno de ellos para que admitan SOAP. Aprovecha los estándares existentes en la industria: Los principales contribuyentes a la especificación SOAP evitaron, intencionadamente, reinventar las cosas. Optaron por extender los estándares existentes para que coincidieran con sus necesidades. Por ejemplo, SOAP aprovecha XML para la codificación de los mensajes, en lugar de utilizar su propio sistema de tipo que ya están definidas en la especificación esquema de XML. Y como ya se ha mencionado SOAP no define un medio de trasporte de los mensajes; los mensajes de SOAP se pueden asociar a los protocolos de transporte existentes como HTTP y SMTP. Permite la interoperabilidad entre múltiples entornos: SOAP se desarrollo sobre los estándares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estándares pueden comunicarse mediante mensaje SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicación de escritorio que se ejecute en una PC puede comunicarse con una aplicación del back-end ejecutándose en un mainframe capaz de enviar y recibir XML sobre HTTP. 328

339 Servicios Web en.net Common Language Runtime proporciona soporte integrado para crear y exponer servicios Web, utilizando una abstracción de programación coherente con programadores de Web Forms ASP.NET y con usuarios existentes de Visual Basic que resulta familiar para ambos. El modelo resultante es escalable y ampliable y comprende estándares abiertos de Internet (HTTP, XML, SOAP, WSDL) de forma que cualquier cliente o dispositivo que cuente con servicios de Internet puede obtener acceso al modelo y lo puede consumir. ASP.NET proporciona soporte para servicios Web con el archivo.asmx. Un archivo.asmx es un archivo de texto. Se puede asignar una dirección URI a los archivos.asmx. Este archivo comienza con la directiva WebService ASP.NET y establece el lenguaje en C#, Visual Basic o JScript. A continuación, puede contener código o hacer referencia a una clase externa que lo contiene. La clase deberá incluir las librerías de WebServices y podrá implementar servicios declarando métodos de la clase como WebMethods. Figura A3.10 Contenido del Archivo.asmx de un Servicio Web 329

340 Figura A3.11 Contenido de la clase.cs codebehind de un Servicio Web Los archivos.asmx se publicarán dentro de un sitio Web en un directorio particular o virtual junto con el código de las clases asociadas. Se podrá acceder a ellos con un cliente http mediante la URI correspondiente. 330

341 Figura A3.12 Servicios Web dentro del Sitio Web en Windows Internet Explorer Figura A3.13 Servicio Web en Windows Internet explorer 331

342 Además de la tecnología de servidor ASP.NET que permite a los programadores crear servicios Web,.NET Framework proporciona conjuntos de herramientas y código sofisticados para consumir servicios Web. Como los servicios Web se basan en protocolos abiertos como SOAP (Simple Object Access Protocol), esta tecnología para cliente también se puede utilizar para consumir servicios Web que no estén basados en ASP.NET. Para que una aplicación consuma servicios Web ubicados en una URL se puede agregar una referencia al mismo desde el proyecto de la aplicación en Visual Studio 2005: Figura A3.14 Agregar referencia a un Servicio Web para una aplicación cliente en Visual Studio 2005 Se genera así automáticamente una carpeta en el directorio del proyecto que contiene las herramientas necesarias para poder consumir el servicio Web 332

343 Figura A3.15 Contenido de una referencia a un Servicio Web El SDK incluye una herramienta denominada WSDL.exe (Web Services Description Language). Esta herramienta basada en línea de comandos se utiliza para crear clases proxy a partir de WSDL. Por ejemplo, podría escribir WSDL URIServicioWeb.asmx?WSDL para crear una clase proxy denominada HelloWorld.cs. Esta última clase se parece a la clase que contiene el servicio Web. Contiene un método que devuelve una cadena. Si compila una clase proxy en una aplicación y después llama a su método, la clase proxy empaqueta una solicitud SOAP a través de HTTP y recibe la respuesta codificada por SOAP, que se resolverá como una cadena. De esta forma una aplicación puede consumir servicios Web ubicados en un sitio Web de un servidor Web fácilmente creando una clase Proxy que utilizará para realizar las llamadas. 333

344 A3.5 WinAudit Tabla de Switches para la ejecución del programa por línea de comandos Switch Options Comment /h Show a help message and exit. /r Report content, default is NO sections, i.e. nothing is done. g Include System Overview s Include Installed Software o Include Operating System P Include Peripherals x Include Security u Include Groups and Users (Window NT4 and above) T Include Scheduled Tasks U Include Uptime Statistics (Window NT4 and above) e Include Error Logs (Window NT4 and above) E Include Environment Variables R Include Regional Settings N Include Windows Network t Include Network TCP/IP n Include Network BIOS z Include Devices (Windows 98 and newer) D Include Display Capabilities a Include Display Adapters (Windows 98 and newer) I Include Installed Printers b Include BIOS Version 334

345 M Include System Management p Include Processor m Include Memory i Include Physical Disks: Caution d Include Drives c Include Communication Ports S Include Startup Programs A Include Services (Window NT4 and above) r Include Running Programs B Loaded Modules L Include System Files F Include Find Files /o Output format, if none is specified will default to formatted text (TEXT). CHM Save as compiled html. Requires Html Help Workshop installed. The locations of hhc.exe and hha.dll must in the PATH environment variable. CSV Save as comma delimited HTML Save as a web page without images HTMLi Save as a web page with images ODBC Export to a Database PDF Save in portable document format TEXT Save as formatted text TEXTt Save as tab delimited text TEXTu Save as unicode text ( UTF-16, little endian) XML Save as extended markup language /f Output file or data source name. Report will be saved to this file. Default is 'computername.ext'. If /o is specified as ODBC supply a data source name (DSN) or a connection string. If neither is 335

346 supplied the default is WinAuditDSN. If the DSN is a File DSN, supply its name only. It must have an extension of.dsn and be located in the user's default DSN directory. If this directory is not specified in the registry, the File DSN must be in the ODBC\Data Sources directory. If a connection string is supplied, it must have the ODBC keyword DRIVER=, no forward slashes and not end with.dsn. macaddress is a reserved word (case insensitive). If specified, the output will be written to a file named using a Media Access Control (MAC) address. If no MAC address can be resolved, then the computer's name will be used. On systems with multiple network adapters, the address of the first one discovered will be used. /u User name for database login. /p Password for database login or PDF protection. Embedding passwords in a batch file is, of course, questionable but the functionality is available for those who wish to use it. /e Quoted list of file extensions to find on local hard drives. /t Timeout in minutes for audit. The audit will automatically stop if it has been running for more than the specified number of minutes. If unspecified, the default is 20 minutes. If a timeout occurs then some or perhaps all data will be discarded. /l (little L) The log file path to record diagnostic and activity messages. The log level is fixed at verbose and the output is tab separated machine readable. If an empty path is specified i.e. '/l=' then the destination will be computername_log.txt in the programme's directory. If only a directory is supplied e.g. '/l=\\server\audits' then the destination will be '\\server\audits\computername_log.txt'. To avoid concurrency issues, multiple machines cannot log to the same file. /m The message displayed on the audit window. The user sees this window when the audit is running in command line mode. Try to keep this message brief as it must fit in the available space and still remain legible. The message does not need to be quoted. Avoid forward slashes '/' as your message will not display correctly. If no message is supplied then a default one will be shown. /L (Capital L) Set the language of strings used by the programme. By default the programme will use the language that matches the computer's regional setting or English if no translation is available. You can override this behaviour by specifying which language to use as follows: /L=be - French (Belgium) /L=br - Portuguese (Brazilian) /L=cs - Czech /L=da - Danish /L=de - German /L=el - Greek /L=en - English /L=es - Spanish /L=fr - French (France) /L=he - Hebrew 336

347 /L=hu - Hungarian /L=id - Indonesian /L=it - Italian /L=jp - Japanese (winauditu.exe only) /L=ko - Korean (winauditu.exe only) /L=nl - Dutch /L=pl - Polish /L=pt - Portuguese (Portugal) /L=ru - Russian /L=sk - Slovak /L=sr - Serbian(Latin) /L=th - Thai /L=tr - Turkish /L=zh_tw - Traditional Chinese (winauditu.exe only) This can help to ensure consistent reporting in a multi-lingual environment. Note, only translated strings are handled; any specific number or date formatting is still done according to the computer's regional setting. For CSV output, the programme will emit commas regardless of any regional setting. PDF document creation will use the code page associated with the specified language however, proper character translation is not guaranteed. WinAudit ANSI: Choosing a language which has a character set (code page) outside of the one a computer is using may give rise to undesired results. For example, German and Czech are from the Western and Central European character sets respectively. Character number 163 corresponds to the Japanese Yen sign in the former and a variant of the letter A in the latter. In general, characters used in the English language are common across all character sets so setting /L=en would probably give the most consistent results. WinAudit Unicode: Use this version in preference over the ANSI version if you are in an NT only environment. The Unicode version will automatically perform UTF-8 conversion of characters for HTML and XML output. Text files are saved in Unicode format (UTF-16 little endian) and database connectivity is via wide (2- byte) characters. Diagnostic logging will detect the log file's encoding scheme. You should also be able to set a message (/m) and use file paths in Unicode. Figura A3.16 Tabla de Switches para la ejecución de WinAudit en modo línea de comandos A3.6 CNAME en Servicio DNS En los servicios DNS se utiliza un sistema de registros como una base de datos donde existen distintos tipos de registros. El que se corresponde con la filosofía DNS es el registro A. Un Registro de dirección A (Address) sirve para asociar nombres de host a direcciones IP dentro de una zona. Éstos son los registros que componen la mayor parte del archivo de base de datos. Su formato es el siguiente 337

348 nombrehost IN A direcciónipdehost machine1 IN A nombreservidor2 IN A El registro CName que reciben el nombre de alias, aunque son conocidos como entradas de "nombre canónico" (CNAME o Canonical Name) se utilizan para usar más de un nombre al apuntar a un único host. Esto puede simplificar operaciones como albergar a la vez un servidor FTP y un servidor web en el mismo equipo. Su formato es el siguiente nombrealiashost IN CNAME nombrehost Suponga que y que ftp.midominio.com se encuentran en el mismo equipo. Si éste es el caso, entonces podría tener las siguientes entradas en su archivo de zona: servidorarchivos IN A ftp IN CNAME servidorarchivos www IN CNAME servidorarchivos 338

349 Anexo 4. Metodologías y Modelos de Diseño A4.1 Unified Modeling Language (UML) El UML (Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad, y aún sin ser todavía un estándar oficial, está apoyado en gran manera por el OMG (Object Management Group). El UML se ha convertido en el estándar de facto de la industria debido a que ha sido concebido por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores. Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa: Booch, OMT y OOSE. El UML consiste en un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema de software, particularmente aquellos que usan la orientación a objetos. Es por esta razón por la que se ha elegido para describir y diseñar el sistema objeto de este proyecto. La razón fundamental para el uso de lenguajes gráficos de modelado es que los lenguajes de programación no proporcionan el suficiente grado de abstracción para realizar el diseño de un sistema con facilidad. UML ofrece, sin embargo, un estándar para describir un modelo del sistema, incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes de software reutilizables. Un punto importante a tener en cuenta es que UML es un lenguaje para especificar y no un método o un proceso, es decir, se puede usar en una gran variedad de formas para soportar una metodología de desarrollo de software pero no determina qué metodología o proceso usar. Actualmente UML se encuentra en la versión 2.0 y describe 13 diagramas oficiales que se clasifican de la siguiente manera: Diagramas de estructura: enfatizan en los elementos que deben existir en el sistema modelado. Diagrama de clases. 339

350 Diagrama de componentes. Diagrama de objetos. Diagrama de estructura compuesta. Diagrama de despliegue. Diagrama de paquetes. Diagramas de comportamiento: enfatizan en lo que debe suceder en el sistema modelado. Diagrama de actividades. Diagrama de casos de uso. Diagrama de estados. Diagramas de interacción: un subtipo de diagramas de comportamiento que enfatiza sobre el flujo de control y de datos entre los elementos del sistema modelado. Diagrama de secuencia. Diagrama de comunicación. Diagrama de tiempos. Diagrama de vista de interacción. Figura A4.1 Introducción Modelos UML 340

351 El estándar UML indica qué elementos se usan en cada tipo de diagramas, pero los diagramas no son especialmente rígidos y frecuentemente se utilizan elementos de un tipo de diagramas en otros. Los distintos modelos que se van a utilizar se explicarán a continuación junto con las fases de la metodología que los requieren. A4.2 Modelo Entidad-Relación El modelo entidad-relación es el modelo conceptual más utilizado para el diseño conceptual de bases de datos. Fue introducido por Peter Chen en El modelo entidad-relación está formado por un conjunto de conceptos que permiten describir la realidad mediante un conjunto de representaciones gráficas y lingüísticas. Originalmente, el modelo entidad-relación sólo incluía los conceptos de entidad, relación y atributo. Más tarde, se añadieron otros conceptos, como los atributos compuestos y las jerarquías de generalización, en lo que se ha denominado modelo entidad-relación extendido. Figura A4.2 - Conceptos del modelo entidad-relación extendido. Entidad 341