47bb062de66ae PDF

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

INGENIERO EN INFORMTICA
PROYECTO FIN DE CARRERA
HERRAMIENTA DE
MONITORIZACIN DE SISTEMAS
AUTOR: Iaki Sota Madorrn
MADRID, Febrero de 2008

Autorizada la entrega del proyecto del alumno:
Iaki Sota Madorrn

.
EL DIRECTOR DEL PROYECTO
Pablo Igualada Moreno

Fdo.: Fecha: //
V B del Coordinador de Proyectos
David Contreras Brcena

Fdo.: Fecha: //
Herramienta de Monitorizacin de Sistemas
Agradecimientos
A mi familia, por la confianza depositada a lo largo de toda la carrera.
A la universidad y a sus profesores, por la ilusin y ganas que en general

demuestran en la formacin 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 compaeros de trabajo, por hacer

que el tiempo dedicado a este proyecto resultara tambin en un tiempo bien invertido
y ameno a la par.
A los amigos y colegas.
I
Resumen
El proyecto consiste en el diseo, desarrollo e implantacin de un sistema que sirva de
apoyo a las empresas de servicios informticos en la tarea de mantenimiento de los
sistemas informticos de sus clientes. El sistema automatiza la auditora y supervisin del
estado y funcionamiento de los sistemas de informacin, consiguiendo que se reduzca
considerablemente el tiempo que se debe dedicar a dicha tarea, y por tanto, aumentando la
productividad. Tanto los sistemas informticos monitorizados como los de la compaa de
servicios, estn compuestos por PCs y Servidores con plataformas de Microsoft.
Se trata de un sistema cliente-servidor donde un servidor instalado en la empresa de

servicios informticos atiende a mltiples clientes instalados en las mquinas de los sistemas
informticos de los clientes, denominados agentes.
El sistema proporciona la funcionalidad para:
Instalacin: Instalacin de un agente en una mquina cliente y su registro en el

sistema.
Obtener acceso, por parte de los usuarios de las mquinas cliente, al programa VCN
One Click de control remoto y a informacin descriptiva del agente.
Auditorias: La ejecucin de auditoras, por parte de los agentes, en las mquinas de

los sistemas informticos de los clientes de forma transparente a los usuarios y su
posterior envo al servidor para su almacenamiento.
Alertas: La generacin, a partir de las auditoras y por parte del servidor, de alertas
relacionadas con estados definidos en las mquinas cliente. Registro de dichas
alertas en el sistema externo Microsoft CRM 3.0.
Gestin de Alertas: El filtrado, por parte de los tcnicos, de las alertas que se generan
de forma que se obtenga una herramienta til.
Tareas: La programacin, por parte de los tcnicos, de tareas definidas y diseadas

para su realizacin por los agentes en las mquinas cliente.
Tareas Programadas: La generacin, por parte de los administradores, de tareas

programadas repetitivas que se registran en el Programador de Tareas de Windows
II
del servidor. Interpretacin de las mismas para su registro en el sistema y su

posterior realizacin por los agentes en las mquinas cliente.
Interfaz para los tcnicos: El visualizado, por parte de los tcnicos, de los agentes
que hay registrados en el sistema, de las tareas que ejecutan dichos agentes en las
mquinas en las que estn instalados, de las auditoras de dichas mquinas
obtenidas y registradas en el sistema y del log registrado en el sistema por los
agentes.
Upgrading: Actualizacin automtica del programa agente en todos los agentes

operativos.
Gestin de Usuarios: La gestin 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 tecnologas innovadoras en desarrollo de software y,
para su interaccin, en comunicacin entre aplicaciones. En general, y debido a la mayor
facilidad de integracin 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 aplicacin Agente, que est compuesta por un Servicio de Windows que

proporciona toda la funcionalidad del agente y una aplicacin que carga un icono en
la barra de tareas y sirve de informacin a los usuarios de las mquinas cliente. Se
han construido con aplicaciones Windows Service y Windows Application
respectivamente.
Una librera, que contiene los componentes del dominio, nivel de negocio y de acceso
a datos. La librera produce un fichero .dll que es utilizado por el resto de
aplicaciones. Se ha construido con una aplicacin Windows Control Library.
Una aplicacin de escritorio, con un interfaz amigable, para los tcnicos de la

empresa de servicios informticos. Se ha construido mediante una aplicacin
Windows Application.
Una aplicacin Web que contiene los servicios Web a travs de los que se comunican
los agentes con el sistema y que sirve tambin de apoyo a la aplicacin de escritorio.
Se ha construido mediante una aplicacin ASP.NET Web Service Application.
III
Una aplicacin que se encarga de interpretar las tareas repetitivas para asignrselas
a los agentes. Se trata de una aplicacin Console Application.
Aplicaciones de instalacin, para la instalacin y actualizacin de los agentes e

instalacin de las dems aplicaciones. Se han construido mediante un Setup Project.
El sistema, adems, se integra con aplicaciones externas, incluido el propio sistema

operativo y sus herramientas. Entre ellas, cabe destacar la aplicacin Microsoft CRM 3.0, la
herramienta Task Scheduler de Windows y una aplicacin de software libre llamada
WinAudit.
Por ltimo, se ha utilizado y profundizado en las tcnicas y metodologas de ingeniera del

software, especialmente en la orientacin a objetos as como en otros conocimientos que se
han visto a lo largo de la carrera como Estructuras de datos, Transmisin y Tecnologas de
Bases de Datos, Sistemas Operativos, Redes, Mtodos algortmicos, Seguridad Informtica
y Gestin de Proyectos Informticos.
IV
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 clients 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 Companys 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 customers computers.
The system provides the following features:
Installation: Installation of the agent in a client machine and the following register in
the system.
The clients machines 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 clients 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 clients 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 clients computers.
V
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 2005.
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

Companys 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
ndice
1. Introduccin __________________________________________________________ 1
1.1 Motivacin y Contexto del proyecto ______________________________________________ 1
1.2 Objetivos y Descripcin del Proyecto _____________________________________________ 1
2. Herramientas y Tecnologa _________________________________________________ 4

2.1 Introduccin _________________________________________________________________ 4
2.2 Introduccin a la Tecnologa .NET ________________________________________________ 4

2.3 Introduccin a los Servicios Windows _____________________________________________ 5
2.4 Introduccin a Internet Information Services (IIS) ___________________________________ 6
2.5 Introduccin a los Servios Web (Web Services) _____________________________________ 6
2.6 Introduccin a las herramientas y aplicaciones a integrar con el sistema_________________ 6
2.7 Introduccin a Microsoft SQL Server _____________________________________________ 16
3. Metodologa de Trabajo __________________________________________________ 18

3.1 Introduccin al Anlisis de requerimientos _______________________________________ 18
3.2 Introduccin al Diseo externo del sistema _______________________________________ 21

3.3 Introduccin al Diseo interno del sistema _______________________________________ 23
3.4 Introduccin a la Implementacin, pruebas e Implantacin __________________________ 28
4. Anlisis de Requerimientos ________________________________________________ 31

4.1 Modelo de Dominio __________________________________________________________ 31
4.2 Casos de uso ________________________________________________________________ 34
5. Diseo Externo del Sistema ________________________________________________ 51

5.1 Arquitectura del Sistema ______________________________________________________ 51
5.2 Diagrama de paquetes ________________________________________________________ 57
6. Diseo Interno del Sistema ________________________________________________ 61

6.1 Diseo de la Interfaz de Usuario y Diagramas de Interaccin _________________________ 61
6.1.1 Subsistema EvoAgentManager e Interaccin con el Servidor _______________________________ 61
6.1.2 Subsistema EvoAgentService e Interaccin con el Servidor________________________________ 113
6.1.3 Sistema Externo Microsoft Dynamics CRM _____________________________________________ 140
6.2 Modelo de datos ___________________________________________________________ 151

VII
6.3 Diagrama de Clases _________________________________________________________ 164

6.3.1 Librera EvoAgentLibrary ________________________________________________________ 164
6.3.2 SubSistema EvoAgentServer _____________________________________________________ 183
6.3.3 SubSistema EvoAgentManager ___________________________________________________ 184
6.3.4 SubSistema EvoAgentService ____________________________________________________ 187
7. Implementacin del sistema, Pruebas e Instalacin ___________________________ 190

7.1 Implementacin de la base de datos____________________________________________ 190
7.2 Construccin del sistema _____________________________________________________ 190
7.3 Pruebas ___________________________________________________________________ 194

7.4 Implantacin en el entorno de produccin _______________________________________ 196
7.4 Manual de Usuario y de Explotacin ____________________________________________ 199
8. Planificacin y Presupuesto ______________________________________________ 200

8.1 Planificacin _______________________________________________________________ 200
8.2 Presupuesto _______________________________________________________________ 205
9. Conclusiones y Evolucin del Sistema _______________________________________ 212

9.1 Conclusiones _______________________________________________________________ 212
9.2 Evolucin del Sistema _______________________________________________________ 212
10. Bibliografa __________________________________________________________ 214

Anexo 1. Manual de Usuario ________________________________________________ 215
Anexo 2. Manual de Explotacin _____________________________________________ 263
A2.1. Implementacin y Configuracin del sistema ___________________________________ 263
A2.2. Mantenimiento y Evolucin del sistema _______________________________________ 285
Anexo 3. Tecnologas ______________________________________________________ 311

Anexo 4. Metodologas y Modelos de Diseo ___________________________________ 339
VIII
1. Introduccin
1.1 Motivacin y Contexto del proyecto
La principal motivacin a la hora de afrontar el presente proyecto es la creacin de una

herramienta que sirva de apoyo a las empresas de servicios informticos en la tarea de
supervisin del estado y funcionamiento de los sistemas de informacin. 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 pequeas y medianas empresas de diferentes sectores
delegan la gestin de sus sistemas de informacin a compaias de servicios informticos.
stas, adems de proveerlas con las ltimas y ms apropiadas tecnologas 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 supervisin remota de
los sistemas de informacin de los clientes.
Dicha tarea consiste en comprobar varios tems en los ordenadores de los clientes, tales
como el espacio en disco, la fragmentacin de los archivos, el log de errores de Windows, el
tamao de la cuota de los usuarios del dominio, los servicios automticos de Windows, el
software instalado en los ordenadores o la correcta ejecucin 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 tecnologas. 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 Descripcin del Proyecto
El principal objetivo del presente proyecto es disear y construir una herramienta que
permita la monitorizacin automtica de los sistemas informticos facilitando la tarea de los
administradores de sistemas.
1
Los sistemas informticos a monitorizar as como el sistema informtico de la empresa

colaboradora estn basados en tecnologa de Microsoft tanto en los PCs de los empleados
como en los servidores. Para el desarrollo del sistema se utilizarn, por tanto, herramientas
de Microsoft disponibles a tal efecto de forma que sea ms sencilla la completa integracin.
A partir de ahora se tendr presente que todos los componentes del sistema a construir
interactuarn con sistemas operativos Windows.
A continuacin se describe en detalle el sistema a desarrollar y todos sus componentes:
Aplicacin agente para las mquinas a monitorizar:
Para la monitorizacin diaria de las mquinas se pretende construir un programa que acte 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 mquinas a monitorizar mostrando la
existencia de la aplicacin mediante un icono en la barra de herramientas. Por tanto, se
deber crear un servicio de Windows y una aplicacin para mostrar el icono.
La monitorizacin, llevada a cabo por el servicio de Windows, consistir en la obtencin de

informacin de la mquina en que est instalado el agente. Para la obtencin de dicha
informacin se utilizar, adems 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, adems, realizar diferentes tareas segn est instalado en un servidor o en
un pc de usuario. Estar diseado para realizar tareas como:
Apagar la mquina.
Ejecutar un programa de limpieza de la mquina Programa Ccleaner.
Iniciar un servicio de Windows.
Obtener una auditora (monitorizacin).
Defragmentar los discos duros.
Ejecutar Scripts.
Comprobar cuotas de usuario de Dominio (Servidor de dominio).
Por otro lado, desde el icono que muestra la informacin de la aplicacin al usuario se podr
acceder al programa VNC Single Click de control remoto de ordenadores.
Los agentes podrn actualizarse consultando su versin contra el servidor y descargando e

instalando la nueva versin.
2
Aplicacin de gestin para los tcnicos de Evotec y Servidor de la aplicacin:
La informacin obtenida en una auditora deber ser enviada a un servicio ubicado en el

servidor, donde pasar por un filtro para, finalmente, generar alertas. Las alertas debern ser
presentadas a los tcnicos de la empresa mediante la integracin con la herramienta CRM
de gestin de clientes utilizada, Microsoft CRM 3.0.
Adems de la generacin de alertas en la aplicacin CRM, el sistema a construir deber ser

controlado desde los puestos de los tcnicos de la empresa mediante una aplicacin de
escritorio que se integrar igualmente con otro servicio en el servidor. Desde dicha
aplicacin de escritorio se podr:
Gestionar los agentes y los clientes a los que pertenecen.
Programar tareas para los agentes.
Controlar la generacin de alertas mediante los filtros.
Ver los informes completos de las mquinas.
Ver el log de las acciones realizadas por los agentes.
El servidor del sistema deber atender tanto a los agentes como a la aplicacin de gestin
de los tcnicos mediante los servicios. Tendr, por tanto, dos servicios web, uno para los
agentes y otro para la administracin. 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 almacenarn 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 interaccin con los agentes. La aplicacin de gestin tendr
acceso a la base de datos para los casos de uso que se propongan.
Seguridad del sistema:
Los tcnicos debern autenticarse para acceder a la aplicacin de gestin que accede a su
vez al servicio de administracin y a la base de datos, dicha autenticacin estar basada en
la cuenta de usuario de Windows utilizada al iniciar la sesin.
Los agentes poseern un identificador recibido del servidor al instalarse y que enviarn a
ste en sus comunicaciones.
Todos los programas y entornos que se han comentado en la descripcin del sistema y que
se utilizarn en el proyecto se exponen en el apartado 2. Herramientas y Tecnologa.
3
2. Herramientas y Tecnologa
2.1 Introduccin
Para el desarrollo de este proyecto se van ha utilizar las ltimas herramientas, estndares y
protocolos disponibles en desarrollo de aplicaciones Web distribudas proporcionadas por
Microsoft y por la industria de desarrollo de software.
Se ha elegido la tecnologa de desarrollo de aplicaciones de Microsoft por ser la tecnologa

con la que, por parte de la empresa, se est ms familiarizado, que ya utiliza esta tecnologa
en sus sistemas.
Se distinguir entre plataformas de desarrollo y produccin existiendo diferentes versiones

de las herramientas de software utilizadas en dichas plataformas.
En desarrollo se trabajar con una mquina con sistema operativo Windows XP o

Windows Vista, con versin de Internet Information Server 5.1 o 7.0 respectivamente
y con la versin gratuita del gestor de base de datos SQL Server, Sql Server Express
Edition que dispone de una capacidad de 2 GB.
En Produccin se utilizar un servidor con Windows 2003 Server, que lleva instalada
la versin 6.0 del Internet Information Server y la versin completa del SQL Server.
Para el diseo de la aplicacin se utilizar Lenguaje Unificado de Modelado (UML) y para el

desarrollo se utilizar el entorno proporcionado por Visual Studio 2005 con el lenguaje de
programacin C#.
Por ltimo se disear y desarrollar integracin con varias aplicaciones, tanto herramientas
del sistema operativo y de la empresa como puede ser la herramienta de tareas
programadas de Windows, la aplicacin de Microsoft CRM Dinamics 3.0 o la aplicacin de
control remoto de ordenadores VNC Viewer, as como aplicaciones de libre distribucin
disponibles en el mercado como WinAudit y CCleaner.
Se realiza a continuacin una introduccin a todas estas herramientas.
2.2 Introduccin a la Tecnologa .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
rpido 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
.NET podra 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
documentacin detallada, uniformidad y cohesin entre sus distintos componentes,
provocando mltiples problemas en el desarrollo de aplicaciones para el sistema operativo
Windows. La plataforma .NET pretende solventar la mayora de estos problemas proveyendo
un conjunto nico y expandible con facilidad, de bloques interconectados, diseados de
forma uniforme y bien documentados, que permitan a los desarrolladores tener a mano todo
lo que necesitan para producir aplicaciones slidas.
Con esta plataforma Microsoft incursiona de lleno en el campo de los Servicios Web y
establece el XML como norma en el transporte de informacin en sus productos y lo
promociona como tal en los sistemas desarrollados utilizando sus herramientas.
.NET intenta ofrecer una manera rpida y econmica pero a la vez segura y robusta de
desarrollar aplicaciones - o como la misma plataforma las denomina, soluciones -
permitiendo a su vez una integracin ms rpida y gil entre empresas y un acceso ms
simple y universal a todo tipo de informacin desde cualquier tipo de dispositivo.
Para ver ms detalles de los recursos que comprende la tecnologa .NET y que se van a
aplicar a este proyecto ver Anexo 3. Tecnologas.
2.3 Introduccin a los Servicios Windows

Los servicios de Microsoft Windows, antes conocidos como servicios NT, permiten crear
aplicaciones ejecutables de larga duracin, que se ejecutan en sus propias sesiones de
Windows. Estos servicios pueden iniciarse automticamente cuando se inicia el sistema, se
pueden pausar y reiniciar, y no muestran ninguna interfaz de usuario. Estas caractersticas
hacen que los servicios resulten perfectos para ejecutarse en un servidor o donde se
necesite una funcionalidad de ejecucin larga que no interfiera con los dems usuarios que
trabajen en el mismo equipo. Tambin puede ejecutar servicios en el contexto de seguridad
de una cuenta de usuario especfica, diferente de la del usuario que inici la sesin o de la
cuenta predeterminada del equipo.
El servicio se crea como proyecto de Microsoft Visual Studio, se define el cdigo 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, reanudacin y detencin del servicio; asimismo,
puede ejecutar comandos personalizados.
Despus de crear y generar la aplicacin, puede instalarla ejecutando la utilidad de lnea de

comandos InstallUtil.exe y pasando la ruta de acceso al archivo ejecutable del servicio, o
bien utilizando las funciones de implementacin de Visual Studio. A continuacin, puede
5
utilizar el Administrador de control de servicios para iniciar, detener, pausar, reanudar y

configurar el servicio. Adems, 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 ocultacin a los
usuarios y posesin de credenciales suficientes para la conexin con el servidor.
Para ver ms informacin acerca de los servicios de Windows consultar el Anexo 3.

Tecnologas.
2.4 Introduccin a Internet Information Services (IIS)

Para la construccin 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
mquinas cliente y a las aplicaciones de los tcnicos 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
autenticacin para controlar el acceso a los mismos.
Para ver las caractersticas que ofrece el servidor web consultar el Anexo 3. Tecnologas.
2.5 Introduccin 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, va
Internet. Son aplicaciones independientes de la plataforma que pueden ser fcilmente
publicadas, localizadas e invocadas mediante protocolos Web estndar, como XML, SOAP,
UDDI o WSDL. El objetivo final es la creacin 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 interconexin de aplicaciones hace que

sean los servicios web la solicin a las comunicaciones entre el servidor y los subsistemas
del presente proyecto.
Para ver ms informacin acerca de los servicios web, los protocolos que implementan y su
desarrollo e implementacin con .NET consultar el Anexo 3.Tecnologas.
2.6 Introduccin a las herramientas y aplicaciones a integrar con el sistema
2.6.1 Microsoft Dynamics CRM 3.0 Profesional
6
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 gestin de las alertas que genere el sistema ha
desarrollar. Por ello, es necesario conocer la aplicacin de Microsoft, su despliegue y
funcionamiento y como conseguir la integracin para el programador.
Introduccin a Microsoft Dynamics CRM 3.0 Profesional

Microsoft DynamicsTM CRM 3.0 Professional, anteriormente conocido como Microsoft
Business Solutions CRM, es una completa solucin de gestin de relaciones con clientes
que proporciona todas las herramientas y capacidades necesarias para crear y mantener
una visin clara de los clientes fcilmente, desde el primer contacto hasta el servicio de
postventa. Con mdulos de marketing, ventas y servicio al cliente, Microsoft CRM 3.0
Professional ofrece una solucin rpida, flexible y asequible que impulsa mejoras
cuantificables y coherentes en todos los procesos empresariales, permite relaciones ms
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 diseado para que sea
una ampliacin 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 aplicacin
La aplicacin est compuesta por una serie de Servicios Web que proporcionan por un lado
la implementacin de la interfaz en el browser cliente y por otro lado el soporte para la
conexin mediante programas. Como tal, se debe ubicar en el servidor web de la compaa,
y configurar para poder ser accedida.
7
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 alterara.
Figura 2.2 Base de Datos de CRM en SQL SERVER
La aplicacin contiene un registro de los usuarios que pueden acceder y la autenticacin de

usuarios se basa en integracin con la autenticacin de Windows. Por tanto, con iniciar
sesin la aplicacin conoce si tienes permiso para entrar.
Integracin con CRM

Existen varias formas de obtener y registrar informacin 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 utilizacin del servicio Web CRMService y acceso SQL a la base de datos.
Hay una documentacin de ayuda instalable denominada CRM SDK y que tambin expone
el espacio de nombres que se utiliza en la aplicacin, como se ve en la figura 2.3.
La documentacin se puede descargar desde el link:
8
http://www.microsoft.com/downloads/details.aspx?FamilyID=9c178b68-3a06-4898-bc83-
bd14b74308c5&displaylang=en.
Figura 2.3 CRM SDK
La aplicacin trabaja con entidades y grupos de entidades. En el presente proyecto nos

interesan las entidades usuarios de la aplicacin, clientes y una entidad nueva que
llamaremos alerta. El mtodo para manejar entidades desde un cdigo cliente pasa por
utilizar un servicio Web del CRM pensado para ello, CRMService. Dicho servicio se debe
referenciar desde el proyecto que contiene el cdigo en el Visual Studio tal y como se ve en
la figura 2.4
9
Figura 2.4 Agregar referencia CRMService
Una vez hecho esto se podra 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
Diseo Interno del sistema Aparatado 6.1.
2.6.2 WinAudit
WinAudit es una aplicacin de software libre, se puede descargar desde la pgina web
http://www.pxserver.com/WinAudit.htm.
sta aplicacin produce un informe con todos los aspectos de la configuracin y el inventario
del ordenador en donde se ejecuta. El programa se compone de un archivo, no necesita
instalacin, lo que lo hace ms fcil de utilizar. Posee una interfaz de usuario:
10
Figura 2.5 Interfaz WinAudit
En Opciones se puede configurar las categoras del inventario que se quieren obtener.
Existe una completa documentacin en la pgina web
http://www.pxserver.com/WinAudit/contents.html donde se puede obtener informacin sobre
cada una de las categoras:
11
Figura 2.6 WinAudit. Categoras de la Auditora
El informe se puede obtener en mltiples formatos. Si no se indica ninguno el resultado se

muestra como un documento HTML.
Figura 2.7 WinAudit. Fomatos de generacin del informe
Para el presente proyecto se necesita obtener un formato que pueda ser fcilmente
transportado y manipulado. El formato ms apropiado, dado que las comunicaciones entre
clientes y servidor que se van ha establecer utilizarn 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
auditora de su ordenador y asimismo no repercuta en su trabajo, es necesario prescindir de
la interfaz grfica de WinAudit. WinAudit est pensado para poder ser ejecutado va lnea de
comandos, sin mostrar la ventana principal, tan slo una ventana de informacin, que si se
une al hecho de que los servicios de Windows no interactan 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 pgina de la aplicacin existe documentacin de cmo utilizarla mediante lnea de

comandos, en ingls:
12
La sintaxis del commando (todo en una lnea) 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. Tecnologas
2.6.3 CCleaner v1.41.544
http://www.ccleaner.com/
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 ms efectiva. Eliminando ficheros temporales, archivos intiles utilizados en algn
proceso de instalacin, cookies, papelera de reciclaje e incluso registrando el Registro de
Windows en busca de entradas no vlidas.
Antes de eliminar algo CCleaner permite especificar si hacerlo o no de modo tal de no perder
informacin que sea relevante.
13
Figura 2.8 CCleaner
La aplicacin con su interfaz permite, adems de realizar la limpieza, examinar el registro de

Windows en busca de entradas intiles o malintencionadas.
En cualquier caso, la utilidad que aporta al presente proyecto es la posibilidad de ejecutar el

programa por lnea de comandos mediante el comando:
ccleaner /AUTO - Ejecuta el limpiador al cargar el programa y despus lo cierra.
2.6.4 Windows Task Scheduler

El Programador de Tareas de Windows es un servicio que programa y ejecuta aplicaciones
automticamente. El explorador de Windows proporciona una interfaz que permite fcilmente
programar tareas. Dicho interfaz se puede acceder a travs de la ruta: %WINDIR%\TASKS o
desde el panel de control. Por lnea 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 ningn interfaz.
David Hall, un ilustre programador asociado a la pgina web www.codeproyect.com dise

una librera que hace de interfaz con dicha herramienta permitiendo al programador
integrarse con la herramienta de tareas programadas de forma fcil y rpida sin salirse de la
tecnologa .NET.
14
De la pgina web de codeproyect se puede bajar la documentacin y la librera. La librera

se debe asociar al proyecto de Visual Studio con el Solution Explorer haciendo clic en el
botn derecho del ratn sobre Referencias y aadiendo una nueva referencia:
Figura 2.9 Agregar la librera TaskScheduler al proyecto
La documentacin se obtiene en un documento HTML que sigue el estilo MSDN, lo que la

hace fcil de seguir y entender. Se incluye dicha documentacin de ayuda junto con el
proyecto en CD.
15
Figura 2.10 Archivo de Ayuda de la librera del TaskScheduler
2.7 Introduccin a Microsoft SQL Server

Gestor de base de datos relacional. El lenguaje que utiliza es Transact SQL, que es el
derivado del estndar SQL. Se suele aplicar en bases de datos de PYMES, aunque de cinco
aos a ahora se ha incrementado su uso en grandes bases de datos empresariales. El uso
de T SQL aade principalmente sintaxis para poder hacer uso de procedimientos
almacenados.
Cumple con los requerimientos ACID transaccionales (Atmico, Consistente, Aislado y

Durable). La comunicacin la ejerce en el nivel de aplicacin con un protocolo llamado TDS
(Tabular Data Stream) aunque tambin 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 configuracin de SQL:
16
Figura 2.11 Sql Server Configuration Manager
Tres cualidades que tambin son destacables son la replicacin, 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
3. Metodologa de Trabajo
Para conseguir un software de calidad, que sea duradero y fcil de mantener hay que idear
una slida base arquitectnica que sea flexible al cambio. Para desarrollar software rpida y
eficientemente, minimizando el trabajo de recodificacin y evitando crear miles de lneas de
cdigo intil hay que disponer, adems de la gente y las herramientas necesarias, de un
enfoque apropiado. Es necesario seguir una determinada metodologa 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 metodologa como el mtodo sistemtico de abordar la resolucin de un

problema. Una metodologa de desarrollo de software se fundamenta sobre tres pilares
bsicos: qu hay que hacer y en qu orden, cmo deben realizarse las tareas y con qu
pueden llevarse a cabo. Esto es, qu etapas, actividades y tareas se deben acometer, qu
tcnicas deben emplearse para realizar estas actividades y cules son las herramientas a
utilizar en cada caso.
Por otro lado, toda metodologa requiere un lenguaje de representacin. Todos los
diagramas y representaciones grficas que se realizarn a lo largo de la metodologa de
desarrollo de este sistema estn basados en notacin UML. Hay que tener en cuenta que el
estndar UML no define un proceso de desarrollo especfico, tan solo se trata de una
notacin.
Para ver detalles de dicho lenguaje ver el Anexo 4. Metodologas
Puesto que el lenguaje de programacin a utilizar va a ser un lenguaje orientado a objetos,

se utilizar tambin una metodologa de desarrollo de software orientada a objetos, frente a
las metodologas de anlisis estructuradas utilizadas en proyectos en los que se usan otros
tipos de lenguajes estructurados (como pueda ser C).
3.1 Introduccin al Anlisis 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
llevarn a cabo las siguientes actividades:
1. Desarrollar el modelo de dominio

El modelo de dominio es una herramienta de comunicacin fundamental que obliga a los
desarrolladores y usuarios a pensar formalmente sobre el problema, les permite validar su
comprensin y establece el vocabulario del espacio del problema. Junto con los
requerimientos, constituye la entrada ms importante para el diseo.
18
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 informacin 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 informacin 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 lnea que las une. El nombre de la asociacin
es opcional y se muestra como un texto que est prximo a la lnea. Se puede aadir un
pequeo tringulo negro slido que indique la direccin en la cual leer el nombre de la
asociacin. La cardinalidad es una restriccin que se pone a una asociacin y que limita el
nmero de instancias de una clase que pueden tener esa asociacin con una instancia de la
otra clase. Puede ser un nmero (1), un rango (2..5), una enumeracin (0,1,3,5) o una
combinacin de los anteriores (0..2,5,7..*). El * significa cualquier nmero 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 relacin entre los actores y los casos de uso del
sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su
interaccin externa. En el diagrama de casos de uso se representa tambin el sistema como
una caja rectangular con el nombre en su interior. Los casos de uso estn 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 lnea.
En la Figura 3.1 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero

automtico.
19
Figura 3.2 Introduccin 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 organizacin, y que realiza algn tipo de interaccin con el sistema.. Se
representa mediante una figura humana dibujada con palotes. Esta representacin sirve
tanto para actores que son personas como para otro tipo de actores.
Un caso de uso es una descripcin 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 especfica.
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 especfica que el actor desea llevar a cabo usando el
sistema.
Un caso de uso, en principio, debera describir una tarea que tiene un sentido completo para
el usuario. Sin embargo, hay ocasiones en las que es til describir una interaccin con un
alcance menor como caso de uso. La razn para utilizar estos casos de uso no completos en
algunos casos, es mejorar la comunicacin en el equipo de desarrollo, el manejo de la
documentacin de casos de uso.
20
3.2 Introduccin al Diseo externo del sistema

En esta etapa se definen los componentes del sistema (aplicaciones del sistema, mdulos)
y la comunicacin entre ellos y con los sistemas externos. Las actividades que tendrn lugar
durante esta etapa son:
1. Identificar la arquitectura del sistema

En esta actividad se define la arquitectura general del sistema de informacin, especificando
las distintas particiones fsicas del mismo, la descomposicin lgica en subsistemas de
diseo y la ubicacin de cada subsistema en cada particin, as como la especificacin
detallada de la infraestructura tecnolgica necesaria para dar soporte al sistema de
informacin.
El particionamiento fsico del sistema de informacin se especifica identificando los nodos y

las comunicaciones entre los mismos, con cierta independencia de la infraestructura
tecnolgica que da soporte a cada nodo. Con el fin de organizar y facilitar el diseo, se
realiza una divisin del sistema de informacin en subsistemas de diseo, como partes
lgicas 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 relacin. De esta forma se consigue estructurar grandes sistemas con un nmero
elevado de clases.
Cualquier sistema grande se debe dividir en unidades ms pequeas, de modo que las
personas puedan trabajar con una cantidad de informacin 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 asignacin debe seguir un cierto principio racional, tal
como funcionalidad comn, implementacin relacionada y punto de vista comn. UML no
impone ninguna regla a la hora de componer los paquetes.
Los paquetes ofrecen un mecanismo general para la organizacin de los

modelos/subsistemas agrupando elementos de modelado. Cada paquete corresponde a un
submodelo (subsistema) del modelo (sistema). Los paquetes son unidades de organizacin
jerrquica de uso general de los modelos de UML. Pueden ser utilizados para el
almacenamiento, el control de acceso, la gestin de la configuracin y la construccin de
bibliotecas que contengan fragmentos reutilizables del modelo.
Un paquete puede contener otros paquetes, sin lmite de anidamiento pero cada elemento
pertenece a (est definido en) slo un paquete.
21
Las dependencias que se presentan entre elementos individuales, pero en un sistema de

cualquier tamao, deben ser vistas en un nivel ms 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 importacin a travs de una
relacin 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 importacin.
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 pblica.
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 slo son vistos por su paquete contenedor y anidados. La visibilidad
tambin 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 automticamente, simplemente concede permiso para establecer referencias. La
dependencia de importacin se utiliza para agregar nombres al espacio de nombres del
paquete del cliente como sinnimos de los caminos completos.
Los paquetes se dibujan como rectngulos con pestaas (similar al icono "carpeta"), las
dependencias se muestran como flechas con lneas discontinuas.
22
Figura 3.3 Introduccin Diagramas de Paquetes
Figura 3.4 Ejemplo Diagrama de Paquetes
3.3 Introduccin al Diseo interno del sistema

En esta etapa se adecua el anlisis a las caractersticas especficas del ambiente de
implementacin y se completan las distintas aplicaciones del sistema realizando las
siguientes actividades:
1. Desarrollar el modelo de interfaz

Las interfaces de usuario grficas 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 nmero de funciones hacen
que el diseo y una clara estructura sean extremadamente importantes.
La interfaz de usuario tiene las tareas de recoger funciones y procesos y de representar

informacin clara. El diseo de una pantalla es una interpretacin de las cualidades definidas
en el diseo y concepcin de procesos. El diseo GUI con su alta calidad esttica da al
producto un carcter atractivo influyendo en la calidad final de la aplicacin.
Un producto con un buen diseo necesita una buena estructura y un diseo que no caduque
rpidamente, que no sea molesto ni aburrido. Las reuniones de diseo se realizan con
clientes y usuarios. A partir de ellas se desarrollan las primeras ideas.
23
Uno de los aspectos clave en el diseo de la interfaz del sistema es la usabilidad, La

Organizacin Internacional para la Estandarizacin (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 especficas de uso".
Esta definicin hace nfasis en los atributos internos y externos del producto, los cuales
contribuyen a su funcionalidad y eficiencia. La usabilidad depende no slo del producto
sino tambin del usuario. Por ello un producto no es en ningn caso intrnsecamente
usable, slo 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 satisfaccin con la que un producto permite alcanzar objetivos

especficos a usuarios especficos en un contexto de uso especfico"
Es una definicin centrada en el concepto de calidad en el uso, es decir, se refiere a cmo el

usuario realiza tareas especficas en escenarios especficos con efectividad.
A partir de la conceptualizacin llevada a cabo por la ISO, se infieren los principios bsicos
en los que se basa la usabilidad:
Facilidad de Aprendizaje: facilidad con la que nuevos usuarios desarrollan una

interaccin efectiva con el sistema o producto. Est relacionada con la predicibilidad,
sintetizacin, familiaridad, la generalizacin de los conocimientos previos y la
consistencia.
Flexibilidad: relativa a la variedad de posibilidades con las que el usuario y el

sistema pueden intercambiar informacin. Tambin abarca la posibilidad de dilogo,
la multiplicidad de vas para realizar la tarea, similitud con tareas anteriores y la
optimizacin 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 observacin del usuario, de
recuperacin de informacin y de ajuste de la tarea al usuario.
La buena usabilidad puede lograrse mediante el diseo centrado en el usuario (que no

necesariamente dirigido por l), aunque se emplean diversas tcnicas. El diseador de
usabilidad proporciona un punto de vista independiente de las metas de la programacin
porque el papel del diseador es actuar como defensor del usuario. Por ejemplo, tras
24
interactuar con los usuarios, el diseador de usabilidad puede identificar necesidades

funcionales o errores de diseo que no hayan sido anticipados.
2. Elaborar los diagramas de secuencia con el detalle de las operaciones ms

importantes
La vista de interaccin 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 descripcin de un objeto, que desempea un determinado papel dentro de una
interaccin, distinto de los otros objetos de la misma clase. Esta visin proporciona una vista
integral del comportamiento del sistema, es decir, muestra el flujo de control a travs de
muchos objetos. La vista de interaccin se exhibe en dos diagramas centrados en distintos
aspectos pero complementarios: centrados en los objetos individuales y centrados en
objetos cooperantes.
Los objetos interactan para realizar colectivamente los servicios ofrecidos por las
aplicaciones. Los diagramas de interaccin muestran cmo se comunican los objetos en una
interaccin. Existen dos tipos de diagramas de interaccin: el Diagrama de Colaboracin y el
Diagrama de Secuencia.
El Diagrama de Secuencia es ms adecuado para observar la perspectiva cronolgica de las

interacciones, muestra la secuencia explcita 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 bifurcacin se representan las condiciones en la llamada

mediante el uso de corchetes [ ]. Un mismo objeto puede emprender una
accin u otra lo que se representara 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
Clase1 Clase2 Clase3
Paquete superior::User Condicin Instancia de una

op() De Bifurcacin clase del dominio
[x<0] op(x)
Nueva instancia de ob4 : Clase4

<<create>>
[x>0] LlamarC(X)
la clase 1 setX(x) Edicin o creacin de
Llamada a clase
Bifurcacin un objeto del dominio.
de otro subsistema
Retorno
El objeto se destruye
en este punto
getY(x)
recurrencia ob5 : Clase5
Nueva llamada <<create>>
al objeto
ob5
Obtencin de un objeto
<<forward>> del dominio.
retorno de objeto
retorno
El objeto sigue con vida
Figura 3.5 Introduccin Diagrama de Secuencia
3. Agregar detalles de implementacin al modelo de dominio. Diagrama de Clases.

Se trata de construir un modelo de diseo basndose en el modelo de anlisis, pero
incorporando detalles de implementacin. El diseo de objetos se centra en las estructuras
de datos y algoritmos que son necesarios para implementar cada clase en el lenguaje de
programacin que se vaya a utilizar (orientados y no orientados a objetos, bases de datos,
etc.).
Para disear las clases se especificarn los mtodos 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 diseo de bases de datos es el proceso por el que se determina la organizacin de una
base de datos, incluidos su estructura, contenido y las aplicaciones que se han de
desarrollar.
26
El diseo 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 tcnicas especficas. As, el diseo de una base de datos se descompone en
diseo conceptual, diseo lgico y diseo fsico.
1. El diseo 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 descripcin 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 diseo conceptual
es describir el contenido de informacin de la base de datos y no las estructuras de
almacenamiento que se necesitarn para manejar esta informacin.
En este caso, tras realizar un anlisis de requisitos, se obtiene un modelo conceptual de

datos fiable a partir del modelo de dominio, traducindolo al modelo Entidad-Relacin.
Ver Modelo Entidad Relacin en el Anexo 4. Metodologas
2. El diseo lgico parte del esquema conceptual y da como resultado un esquema lgico.
Un esquema lgico es una descripcin de la estructura de la base de datos en trminos
de las estructuras de datos que puede procesar un tipo de SGBD. Un modelo lgico es
un lenguaje usado para especificar esquemas lgicos (modelo relacional, modelo de red,
etc.). El diseo lgico depende del tipo de SGBD que se vaya a utilizar, no depende del
producto concreto.
El dise lgico del modelo de datos pasa por una nomalizacin del mismo. El proceso
de normalizacin de una base de datos consiste en aplicar una serie de reglas a las
relaciones obtenidas tras el paso del modelo E-R (entidad-relacin) al modelo relacional.
Las bases de datos relacionales se normalizan para evitar la redundancia de los datos,
evitar problemas de actualizacin de los datos en las tablas y proteger la integridad de
los datos.
El paso del modelo conceptual de datos al modelo lgico supone una abstraccin, un
mecanismo para la conversin del mundo real a un mundo formado por datos, a su
agrupacin y clasificacin. El proceso de abstraccin consiste en identificar los
elementos conceptos empleados en el modelo global y transformarlo en lo que
denominamos entidades en el modelo lgico. El resultado de esta transformacin se
traduce en un nuevo modelo: El modelo RE/R. Ver Anexo 4. Metodologas. Diagrama
RE/R
3. El diseo fsico parte del esquema lgico y da como resultado un esquema fsico. Un
esquema fsico es una descripcin de la implementacin de una base de datos en
memoria secundaria: las estructuras de almacenamiento y los mtodos utilizados para
tener un acceso eficiente a los datos. Por ello, el diseo fsico depende del SGBD
concreto y el esquema fsico se expresa mediante su lenguaje de definicin de datos.
27
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 diseo lgico de forma que se aumente el rendimiento
considerablemente. A este procedimiento se le denomina desnormalizacin de la base
de datos.
Una vez finalizado esta etapa, se dispone de un modelo de datos preparado para ser
implementado.
3.4 Introduccin a la Implementacin, pruebas e Implantacin

Se desarrollar el cdigo de la aplicacin y se realizarn las pruebas de software necesarias
que certifiquen que la aplicacin funciona de manera correcta. El objetivo de estas pruebas
es garantizar que el sistema ha sido desarrollado correctamente, sin errores de diseo ni
programacin y que se corresponde con los requerimientos. Las pruebas sern planteadas
tanto a nivel de cada mdulo (aislado del resto), como de integracin del sistema. Como
resultado de esta etapa se obtendr el cdigo ejecutable de las aplicaciones del sistema, el
sistema instalado y operativo y los manuales de usuario y explotacin.
As, se podran definir varias etapas en este apartado:
1. Implementacin 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 mtodos para acceder a la misma.
2. Desarrollo del cdigo

Etapa de programacin de los componentes de la aplicacin. En esta etapa se
cumplimentarn las clases que se han descrito en el diseo interno junto con los algoritmos
necesarios para cumplir con el cometido de cada una as como la implementacin de la
interfaz de usuario cuando fuese necesario. Todo ello condicionado por la plataforma de
desarrollo escogida as como por la metodologa de comunicacin entre mdulos a
implementar.
3. Pruebas unitarias
Una vez se haya desarrollado el cdigo de los subsistemas se podrn realizar las pruebas
de dichos subsistemas y sus mdulos 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 Integracin
El objetivo de las pruebas de verificacin es comprobar que los mdulos 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
Para garantizar la estabilidad de la aplicacin y el cumplimiento de los requerimientos

propuestos se plantean las siguientes pruebas:
Look & Feel: A partir de los estndares de presentacin definidos se definen los
requerimientos de pruebas genricos que se validan en cada una de las aplicaciones
que componen la solucin. 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 tambin se deja registro de ello, describiendo las razones por
las cuales no se considera dentro del producto.
Autenticacin nica de Usuarios: Se valida el registro de los usuarios a la solucin,

la conexin se realiza una vez y este debe ser reconocido en cada una de las
aplicaciones de la solucin, sin que se solicite nuevamente login y usuario al invocar
la ejecucin de alguna de ellas. Se debe verificar que los accesos del usuario en cada
aplicacin corresponden a los definidos en cada producto de la solucin.
Administracin de Usuarios: Se validan los requerimientos de administracin de

usuarios (creacin de usuarios, modificacin de datos, cambio de password,
eliminacin de usuarios, activacin y desactivacin de usuarios).
Operacin en Ambiente Integrado: Consiste en validar que cada producto funciona

adecuadamente en la plataforma definida para la solucin, sin que exista conflicto
entre el software base instalado e incluso entre las mismas aplicaciones. Para realizar
esta validacin se realiza la seleccin de los procesos que se ejecutarn en el
ambiente integrado.
Repositorio Central de Datos: Se realiza validacin 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 operacin. Adems, debe
considerar que los destinos pueden ser mltiples aplicaciones.
Integracin Funcional: Se validan la sincronizacin a nivel de procesos, es decir la

interaccin entre los productos a partir de la ejecucin de procesos y la transferencia
de informacin a otros procesos. Se deben identificar los procesos de las
aplicaciones que interactan y el mecanismo de intercambio de informacin. Este
puede realizarse a travs de interfaces directas entre aplicaciones como en este
proyecto o mediante el uso de herramientas altamente configurables que actan
como mediadores.
Instalador: En caso que se construya un instalador nico para la aplicacin, se debe

validar el correcto funcionamiento de este, es decir que realice la instalacin de los
productos de software que componen la solucin y el software adicional requerido
para su adecuada operacin. En el presente proyecto, se verificar que el sistema de
actualizacin automtica de los agentes funciona correctamente.
29
PRUEBAS NO FUNCIONALES
Adicionalmente, dependiendo de las caractersticas de la solucin se pueden requerir la

ejecucin de pruebas No Funcionales tales como:
Pruebas de desempeo (carga)
Pruebas de Resistencia (stress)
Pruebas de Seguridad
Pruebas de Rendimiento
5. Implantacin en entorno de produccin

Tras pasar las pruebas de integracin, el sistema construido tiene la fiabilidad suficiente
como para poder ser traspasado al entorno de produccin. Se deber especificar en qu
mquinas cliente se va ha realizar la instalacin de los agentes. Asimismo se deber
especificar el mtodo de instalacin y proveer de los manuales de explotacin y de usuario
del sistema correspondientes.
30
4. Anlisis de Requerimientos
4.1 Modelo de Dominio
Limpieza Auditoria InicioServicio Apagado

-Seleccion -Seleccion
Tarea
Cliente
-idTarea 1
-idCliente
-Descripcion
-Nombre
*
*
PERTENECE
*
Dominio *
PERTENECE
-idDominio
-Nombre
[Fecha, Estado]
* PERTENECE
* 1
1
Alerta
-idAlerta Maquina
1 TIENE
-Descripcion * -idMaquina
-Fecha
1 ** -NombreHost
1 GENERA AuditoriaResultado -TimeStamp
TIENE -Permiso
* 1
GENERA
Figura 4.1 - Modelo de Dominio I
Tarea
Una tarea se define como una posible accin que se puede llevar a cabo en un cliente. Cada
tarea requerir un mtodo especfico para que pueda ser realizada por los clientes. Los
31
clientes debern poder interpertar que tarea deben realizar. Las tareas se ejecutan en una
fecha concreta y puede definirse un estado de la tarea en funcin de si se ha ejecutado, si
esta pendiente de que la mquina lo sepa o si est pendiente de ejecucin (ya enviada a la
mquina cliente). Entre las tareas que pueden realizarse se encuentra la tarea de auditora
que por su significado en el proyecto es la ms importante.
Auditora: Requiere una seleccin de los campos a auditar lo que, por tanto, es un
atributo de esta tarea. Se trata de la ejecucin del programa WinAudit visto en el
apartado 2.6.2. Los clientes deben poseer la capacidad de ejecutar el programa y
manejar la auditora resultado.
A parte de la auditora, tambin pueden haber otras tareas, como la ejecucin del programa
CCleaner (limpieza) visto en el apartado 2.6.3. o el inicio de un servicio, apagado de la
mquina 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 mquinas cliente. Los clientes normalmente tienen definido un
dominio desde el que administrar sus sistemas de informacin y mquinas. Puede ser que
tengan definido ms, lo que no es normal, o que no tengan dominio definido. El dominio es
conocido por las mquinas de los clientes y, es mediante el cual, el sistema podra asociar
las mquinas a sus respectivos clientes.
Mquina
Con mquina se hace referencia a todas las mquinas cliente, donde residirn los agentes
del sistema. Las mquinas pueden ser, servidores de informacin u cualquier otro equipo.
Una mquina normalmente tiene un nombre host nico en un dominio por el que puede ser
identificada. No obstante, lo que es seguro es que las mquinas tienen definido un nmero
de serie nico asignado por el fabricante.
Auditora resultado
Es el resultado de la ejecucin de una tarea auditora en una mquina. ste puede variar en
funcin de los campos que se definen para auditarse. Consultar apartado 2.6.2 y Anexo 3.
Alerta
Las alertas son comunicadores disparados ante estados definidos en una mquina cliente.
Dichos estados se pueden monitorizar mediante las auditoras resultado.
32
1 MemoriaRAMLibre
1 ServicioNoArrancado
1 AltaPrograma
-FechaInstalacion
-Owner Alert
-idAlerta
-Descripcion
GENERA
*
-Fecha
BajaPrograma 1 AuditoriaResultado
1 -FechaInstalacion
-FechaDesinstalacion
-NumeroVecesUsado
-Owner EspacioDisco ErrorLog 1
*
CampoAuditoria
1 1
TareasProgramadas Pantalla Impresoras
1 1
DiscosLgicos Errores ProgramasArranque Dispositivos ModulosCargados
SoftwareInstalado Procesadores PuertosYslots EstadsticasDesdeArranque VistaGeneral
Servicios Perifricos ProgramasArrancados RedBIOS SistemaOperativo
Memoria ParmetrosSeguridad Red TCP/IP DiscosFsicos Red Windows
Figura 4.2 - Modelo de Dominio II
33
Previamente se ha visto la definicin de alerta. Los estados definidos de las mquinas cliente
que generan estas alertas se pueden observar en la figura 4.2 y tienen que ver con el disco
duro de las mquinas, 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 auditora
est compuesto de varios campos, los que se pueden ver tambin 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 Aplicacin Iniciar Aplicacin

Servicio Windows Icono en Barra de Tareas
Mquina Cliente
Consultar Lanzar Cliente

Informacion de la Apliacin Escritorio Remoto Evotec Tcnico Evotec
Usuario Mquina Cliente
Figura 4.3 Diagrama de Casos de Uso I
34
Sistema EvoAgentManager
Tareas
uses uses
Ver Tareas Ver Propiedades de Editar Tarea
Programadas Tarea Programada Programada
uses
EliminarTarea Task Scheduler

Programada Programar Tarea
Revisar Estado de
Nueva Tarea
Tareas
uses
uses uses
Eliminar Tarea
Buscar Tareas Borrar Tareas
Pendiente
uses
Tcnico Evotec
Editar Tarea
Dominios y Clientes
Eliminar Dominio y
Crear Nuevo Dominio Asociaciones
Actualizar
Clientes Actuales
CRM
Tcnico Evotec
Asociar Dominio
con Cliente Asociar Maquinas a Borrar Maquinas de
Dominio y Cliente Dominio y Cliente
Figura 4.4 Diagrama de Casos de Uso II
35
Sistema EvoAgentManager
Mquinas
Permitir Acceso al Denegar Acceso al

Sistema Sistema
Ver Detalle
Buscar Mquinas
Auditoras
Tcnico Evotec
Settings de la Aplicacin
Alertas
Establecer Usuario Establecer Elementos

Propietario de Alertas Generadores de Alerta
Gestin de Versiones Usuarios

Tcnico Evotec
Establecer la ltima Establecer Ruta del Actualizar Usuarios

Version del Cliente Repositorio de Versiones de la Apliacin
CRM
Log Errores
Buscar Errores por Actualizar Lista Borrar Lista

Ver Errores Errores Errores
Fecha
Figura 4.5 Diagrama de Casos de Uso III
36
Sistema EvoAgentServer
Mdulo ProgramacinTareas
Registrar
TareaMaquina de Tarea Programada
Task Scheduler
Figura 4.6 Diagrama de Casos de Uso IV
Caso de uso: Buscar Tareas

Actor primario: Tcnico de Evotec.
Actor secundario: ---
Trigger: El tcnico inicia la transaccin.
Precondiciones: Existen mquinas y tipos de tareas registradas en el sistema.
Escenario principal:
1. El sistema muestra en una lista las tareas pendientes de todas las mquinas de todos los
clientes en un rango de fechas de 20 das.
2. El tcnico modifica los parmetros de bsqueda.
3. El sistema actualiza la lista mostrando las tareas que cumplan dichos parmetros.
Extensiones:
Descripcin de datos:
Parmetros de bsqueda:
Cliente/s
Mquina/s
Tipo/s de tarea/s
Estado
Fecha Mnima
Fecha Mxima
Caso de uso: Nueva Tarea

37

1. El sistema muestra los clientes, mquinas y tipos de tareas disponibles para la
programacin de una nueva tarea.
2. El tcnico selecciona la/las mquinas, tipo/tipos de tareas, sus argumentos y la fecha para
la realizacin de la nueva tarea.
3. El sistema registra la/las nueva/s tareas y actualiza la lista de tareas con la informacin
de la nueva tarea si sta cumple con los parmetros de bsqueda.
Extensiones:
Caso de uso: Eliminar Tarea Pendiente

Precondiciones: Existen tareas pendientes registradas en el sistema.
1. Caso de Uso Buscar Tareas
2. El tcnico 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.
Caso de uso: Borrar Tareas

Precondiciones: Existen tareas registradas en el sistema.
1. Caso de Uso Buscar Tareas
2. El sistema borra la/s tarea/s incluidas en la lista.
Extensiones:
38
Caso de uso: Editar Tarea

Precondiciones: Existen tareas pendientes registradas en el sistema.
1. Caso de Uso Buscar Tareas.
2. El tcnico selecciona la tarea a editar.
3. El sistema habilita la edicin de los atributos de la tarea.
4. El tcnico 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.
Caso de uso: Revisar estado de las tareas

Precondiciones:
1. Caso de Uso Buscar Tareas.
2. El tcnico solicita la actualizacin de la lista de tareas.
3. El sistema actualiza la lista con las tareas que cumplan con los parmetros de bsqueda
Extensiones:
Parmetros de bsqueda:
Cliente/s
Mquina/s
Tipo/s de tarea/s
Estado
Fecha Mnima
39
Fecha Mxima
Caso de uso: Programar Tarea

Actor secundario: Task Scheduler.
1. El sistema muestra los clientes, mquinas y tipos de tareas disponibles para la
programacin de una nueva tarea.
2. El tcnico selecciona la/las mquinas, tipo/tipos de tareas y sus argumentos para la
realizacin de la nueva tarea.
3. El sistema muestra las posibles periodicidades de ejecucin.
4. El tcnico selecciona la periodicidad de ejecucin de la tarea.
5. El tcnico configura la periodicidad de ejecucin
6. El tcnico proporciona las credenciales para la ejecucin de la tarea programada.
7. El sistema enva la configuracin de la tarea programada al Task Scheduler.
8. El sistema guarda los atributos de mquinas y tipos de tareas de la tarea programada.
Extensiones:
Credenciales para la ejecucin de tareas programadas:
Dominio\Usuario
Contrasea
Caso de uso: Ver Tareas Programadas

Precondiciones:
1. El sistema solicita al Task Scheduler las tareas programadas.
2. El sistema muestra una lista con las tareas programadas.
Extensiones:
40
Caso de uso: Ver Propiedades de Tarea Programada

Precondiciones:
1. Caso de uso Ver Tareas Programadas.
2. El tcnico 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:
Caso de uso: Editar Tarea Programada

1. Caso de Uso Ver Propiedades de Tarea Programada
2. El tcnico edita la Tarea Programada.
3. El sistema enva la nueva configuracin al Task Scheduler.
4. El sistema guarda los atributos de mquinas y tipos de tareas de la Tarea Programada.
Extensiones:
Caso de uso: Eliminar Tarea Programada

Precondiciones:
1. Caso de Uso Ver Tareas Programada.
2. El tcnico selecciona una Tarea Programada.
41
3. El Task Scheduler elimina la Tarea Programada.

4. El sistema elimina las propiedades de la Tarea Programada.
Extensiones:
Caso de uso: Crear Nuevo Dominio

Precondiciones:
1. El tcnico introduce el nombre del dominio que quiere crear.
2. El sistema registra el nuevo dominio en el sistema.
Extensiones:
Caso de uso: Asociar Dominio con Cliente

Precondiciones: El dominio debe haber sido creado.
1. El tcnico selecciona el dominio y el cliente
2. El sistema asocia el dominio con el cliente.
Extensiones:
Caso de uso: Asociar Mquinas a Dominio y Cliente

Precondiciones: El dominio debe estar asignado al cliente.
1. El tcnico selecciona la asociacin dominio-cliente
2. El sistema muestra las mquinas disponibles.
42
3. El tcnico selecciona las mquinas a asociar a la asociacin dominio-cliente.

4. El sistema asocia las mquinas con el dominio y el cliente.
Extensiones:
Caso de uso: Actualizar clientes actuales

Actor secundario: CRM.
Precondiciones:
1. El sistema solicita todos los clientes existentes al CRM.
2. El sistema actualiza los clientes registrados.
Extensiones:
2 a. Los clientes del sistema estn actualizados
Caso de uso: Borrar Mquinas de Dominio y Cliente

Precondiciones:
1. El sistema muestra las mquinas registradas.
2. El tcnico selecciona las mquinas que desea borrar del dominio y el cliente.
3. El sistema borra la asociacin entre las mquinas seleccionadas y el dominio y cliente

asociados.
4. El sistema muestra la nueva configuracin de las mquinas.
Extensiones:
43
Caso de uso: Eliminar dominio y asociaciones

Precondiciones:
1. El sistema muestra los dominios registrados.
2. El tcnico selecciona el dominio a eliminar.
3. El sistema borra la asociacin entre el dominio seleccionado y su cliente asociado y las
mquinas.
4. El sistema borra la asociacin entre el dominio y el cliente.
5. El sistema borra el dominio seleccionado.
6. El sistema muestra la nueva configuracin de las mquinas.
Extensiones:
3 a. El dominio no tiene mquinas asociadas.
1. Se vuelve a 4.
4 a. El dominio no tiene cliente asociado.
1. Se vuelve a 5.
Caso de uso: Buscar Maquinas

Precondiciones:
1. El sistema muestra una lista de clientes.
2. El tcnico selecciona un cliente.
3. El sistema muestra las mquinas del cliente seleccionado.
Extensiones:
2 a. El tcnico introduce el nombre de la mquina, del cliente, del dominio o parte
del mismo nombre.
1. El sistema muestra las mquinas cuyo nombre, cliente o dominio coincidan con l.
44
Caso de uso: Permitir Acceso al Sistema

Precondiciones:
1. Caso de uso Buscar Maquinas.
2. El tcnico selecciona las mquinas.
3. El sistema configura las mquinas para permitirles el acceso al sistema.
Extensiones:
Caso de uso: Denegar Acceso al Sistema

Precondiciones:
2. El tcnico selecciona las mquinas.
3. El sistema configura las mquinas para denegarles el acceso al sistema.
Extensiones:
Caso de uso: Ver detalle auditoras

Precondiciones:
2. El tcnico selecciona la mquina.
3. El sistema muestra la informacin recogida en las auditoras realizadas a la mquina.
Extensiones:
45
Caso de uso: Establecer elementos generadores de alerta

Precondiciones:
1. El sistema muestra los campos potencialmente generadores de alertas y la configuracin
actual (los campos que son generadores).
2. El tcnico selecciona los campos que se desea sean generadores de alertas.
3. El sistema guarda la nueva configuracin.
Extensiones:
Caso de uso: Establecer usuario propietario de alertas

Precondiciones:
1. El sistema muestra los usuarios de la aplicacin registrados y el usuario propietario.
2. El tcnico selecciona el nuevo usuario propietario de alertas.
3. El sistema guarda el nuevo usuario propietario.
Extensiones:
Caso de uso: Actualizar usuarios de la aplicacin

Actor secundario: CRM.
Precondiciones:
1. El sistema solicita todos los usuarios existentes al CRM.
2. El sistema actualiza los usuarios registrados.
46
Extensiones:
2 a. Los usuarios del sistema estn actualizados
Caso de uso: Establecer la ltima versin del cliente

Precondiciones:
1. El sistema muestra la ltima versin del cliente disponible.
2. El tcnico introduce la nueva ltima versin del cliente disponible.
3. El sistema guarda la nueva ltima versin del cliente disponible
Extensiones:
Caso de uso: Establecer ruta del repositorio de versiones

Precondiciones:
1. El sistema muestra la ltima ruta del repositorio de versiones.
2. El tcnico introduce la nueva ruta del repositorio de versiones.
3. El sistema guarda la nueva ruta del repositorio de versiones.
Extensiones:
Caso de uso: Ver Errores

Precondiciones:
1. El sistema muestra una lista acotada por fechas de los errores del sistema.
47
Extensiones:
Caso de uso: Buscar Errores por fecha

Precondiciones:
1. Caso de uso Ver Errores.
2. El sistema muestra las fechas de inicio y fin de bsqueda de errores.
3. El tcnico modifica las fechas de inicio y fin de bsqueda de errores.
4. El sistema muestra la lista de errores con los errores que se hayan producido entre las
fechas seleccionadas.
Extensiones:
Caso de uso: Actualizar lista de errores

Precondiciones:
2. El sistema muestra los errores entre las fechas de inicio y fin de bsqueda.
Extensiones:
Caso de uso: Borrar lista de errores

Precondiciones:
48
2. El tcnico selecciona los errores.

3. El sistema borra toda la informacin concerniente a los errores seleccionados.
Caso de uso: Iniciar Aplicacin Servicio Windows

Actor primario: Mquina Cliente.
Trigger: El mquina cliente inicia la transaccin.
Precondiciones: El usuario de la mquina cliente arranca la mquina e inicia la sesin.
1. La mquina arranca el servicio de Windows EvoAgentService.
Caso de uso: Iniciar Aplicacin Icono en barra de tareas

Trigger: El mquina cliente inicia la transaccin.
Precondiciones: El usuario de la mquina cliente arranca la mquina e inicia la sesin.
1. La mquina arranca la aplicacin que carga el icono en la barra de tareas.
Extensiones:
Caso de uso: Lanzar cliente Escritorio Remoto Evotec

Actor secundario: Tcnico Evotec.
Trigger: El usuario de la mquina cliente inicia la transaccin.
Precondiciones:
1. El usuario de la mquina cliente solicita el control remoto.
2. El sistema arranca el cliente de la aplicacin UltraVNC Viewer.
3. El usuario introduce el id de sesin del tcnico.
Extensiones:
Caso de uso: Consultar informacin de la aplicacin.

Actor secundario: Tcnico Evotec.
49
Trigger: El usuario de la mquina cliente inicia la transaccin.

Precondiciones:
1. El usuario solicita informacin de la aplicacin.
2. El sistema muestra la informacin de la aplicacin disponible.
Extensiones:
Caso de uso: Registrar TareaMaquina de Tarea Programada

Actor primario: Task Scheduler
Trigger: El Task Scheduler ejecuta la tarea programada
Precondiciones:
1. El sistema obtiene las mquinas y tareas para registrar las nuevas tareas para las
mquinas.
2. El sistema obtiene la prxima ejecucin de la tarea para registrar la fecha de las nuevas
tareas para las mquinas.
3. El sistema registra las nuevas tareas para las mquinas.
50
5. Diseo Externo del Sistema
5.1 Arquitectura del Sistema

En este apartado se estudia la solucin propuesta para la arquitectura del sistema. En el
siguiente grfico queda reflejada la arquitectura general del sistema y las tecnologas usadas
en cada parte.
Maquina Cliente
EvoAgentService - cliente http
Windows XP/2000/Vista Servidor de Autenticacin
Soap-Ssl-Http
Soap
CRM
Ssl BBDD
Sql
Http
Maquina Cliente
EvoAgentService cliente http
Windows XP/2000/Vista Soap EvoAgentServer
Ssl
Servidor de la aplicacin Servidor de Bases de Datos
Http
Windows 2003 Server
EvoAgentBD
Internet Information Services BBDD
Sql
Maquina Cliente
EvoAgentService cliente http
Windows XP/2000/Vista
Soap-Http Soap-Http
Servidor CRM
Sql
Puesto Evotec
EvoAgentManager cliente http
Windows XP
Sql
Puesto Evotec
EvoAgentManager cliente http
Windows XP
Figura 5.1 Arquitectura General del Sistema
Nota: Cada componente servidor que se describe en este diagrama se corresponden con funcionalidades
de la aplicacin 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
Servidor de la aplicacin
Contenedor de los distintos Servicios Web y otras funcionalidades de que se compone la
aplicacin servidor EvoAgentServer. El servidor de aplicaciones (Internet Information Server)
dispone de la lgica de autenticacin de usuarios y de acceso a los Servicios Web.
En el presente proyecto se crear un sitio Web especfico 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 mquinas cliente y para las aplicaciones de
gestin, 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
mquinas, acceso annimo en el directorio del sitio Web dentro del Internet
Information Server, con lo que la funcin de autenticacin de dichas mquinas
pasara a la propia aplicacin.
A parte del Servicio Web de control de la aplicacin 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
actualizacin automtica de la ltima versin de la aplicacin por parte del cliente.
52
AdminManager: Contiene el Servicio Web con el que interacta la aplicacin de

gestin EvoAgentManager. El nivel de seguridad de este directorio debe permitir el
acceso al mismo nicamente a los tcnicos de Evotec con lo que se utiliza una
autenticacin de Windows integrada.
A parte del Servicio Web con el que interacta la aplicacin EvoAgentManager, este
directorio recoge las siguientes funcionalidades:
o Incidencias: Almacn de documentos de texto que recogen la descripcin 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: Almacn de documentos de texto plano (xml) que recogen el resultado

de las auditoras realizadas en las mquinas cliente.
o Programacin de tareas: Este directorio contiene una aplicacin destinada a

interpretar las tareas programadas generadas por la aplicacin de gestin
EvoAgentManager, ProgramacionTareas.exe.
La arquitectura de generacin de tasks esta pensada para utilizar la herramienta

Windows Task Scheduler para programar tareas a ejecutar en las mquinas
cliente que se repiten peridicamente. Esta herramienta permite ejecutar
programas con una periodicidad establecida. El programa que ejecute esa task
deber poder acceder a la informacin necesaria para poder registrar las tareas
para las mquinas en el servidor.
Por tanto se necesita generar una tarea programada (Tarea-xxxx.job), un fichero

que contenga la informacin 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 cul es el fichero que
debe interpretar (Tarea-xxxx.bat).
Generacin de Tareas Programadas:
53
SERVIDOR EVOTEC
PUESTO EVOTEC
Windows Task
Task Scheduler Tarea-xxxx.job
Puesto Evotec Programacion Tareas

EvoAgentManager cliente http INTRANET
Windows XP
Programa
ProgramacionTareas.exe
Archivo XML
Tarea-xxxx.xml
Archivo Lotes
Tarea-xxxx.bat
Servicio Web
EvoAgentServer
Windows 2003 Server
Internet Information Services
CRM
BBDD
Servidor de Bases de Datos

SQL Server
Figura 5.3 Arquitectura de la generacin de tareas programadas
Ejecucin de Tareas Programadas:
54
SERVIDOR EVOTEC
PUESTO EVOTEC
Task
Tarea-xxxx.job
Windows
Task Scheduler
Puesto Evotec Programacion Tareas

EvoAgentManager cliente http INTRANET
Windows XP
Programa
Archivo XML
Tarea-xxxx.xml
Archivo Lotes
Tarea-xxxx.bat
Servicio Web
EvoAgentServer TareasManager
Windows 2003 Server
Internet Information Services
CRM
BBDD
Servidor de Bases de Datos

SQL Server
Figura 5.4 Arquitectura de la ejecucin de tareas programadas
Adems:
El archivo de configuracin guarda la configuracin del sitio Web, mtodos de

autenticacin as como los Settings de la aplicacin, conexiones a bases de datos,
etc.
Servidor de base de datos

Permite el acceso a las bases de datos que utiliza el Sistema:
55
EvoAgentBD: Base de datos de la aplicacin. 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
Integracin con la aplicacin CRM. El sistema necesita comunicarse con dicha aplicacin
para el registro de alertas.
Servidor de Autenticacin
Integracin con diversos esquemas de autenticacin como Active Directory.
Puesto Evotec
Puesto de trabajo del tcnico de evotec. En dicho puesto reside la aplicacin de gestin del
sistema EvoAgnetManager. Como aplicacin de gestin orientada al control del sistema por
parte de los tcnicos posee interfaz grfica de usuario. Adems contiene el programa
servidor de la conexin remota mediante UltraVNC Viewer.
Maquina Cliente
Mquinas pertenecientes a los clientes. En ellas reside el subsistema EvoAgent, que
contiene la aplicacin cliente del sistema distribuido, EvoAgentService (servicio de
Windows), que se ocupa de ejecutar las tareas programadas para la mquina en que est
instalado, y la aplicacin que carga el icono en la barra de tareas, EvoStartup, y que permite
al usuario de la mquina visualizar la informacin de la aplicacin y acceder a servicios como
el cliente del control remoto, evotec_soporte_remoto.
Para la ejecucin 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 aplicacin que carga el icono iniciada desde el registro de arranque de la
mquina y las aplicaciones necesarias para completar la funcionalidad
EvoAgentService: Servicio de Windows que se encargar de preguntar

peridicamente al servidor si tiene tareas a realizar. El sistema operativo arranca el
servicio de forma automtica al iniciar la mquina.
EvoAgentIcon: Programa que carga el icono de la aplicacin en la barra de tareas

desde el que se puede acceder a la informacin sobre la aplicacin o al programa de
control remoto. Requiere de una entrada en el registro de arranque de la mquina.
56
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.
5.2.1 Sistema y sistemas externos. Primer nivel
EvoAgent
Herramienta
Centralizada de
Monitorizacin
<<import>> <<access/import>> <<access/import>>
Windows Task
WinAudit CRM Dynamics
Scheduler
Figura 5.5 Diagrama de Paquetes. Contexto
En la imagen se muestra como existen 3 sistemas externos con los que el sistema
intercambia informacin. Se trata de un diagrama que se corresponde en cierto modo con el
diagrama de contexto de la metodologa de diseo de los diagramas de flujo de datos o
DFDs.
WinAudit provee conceptos importantes para el sistema que han sido aadidos en el
modelo de dominio como son los campos generados en la auditoria.
Windows Task Scheduler requiere de implementacin de una librera (.dll) o

extensin de la aplicacin que contiene las clases ms importantes con las que se
debe trabajar para crear tareas programadas.
Micorsoft Dynamics CRM posee una librera de clases con las que trabaja los
programadores de extensiones de dicha aplicacin.
Expandiendo el paquete del sistema EvoAgent o Agente de Evotec se puede observar como
se divide en 3 paquetes subsistemas y dos pquetes auxiliares. En la imagen se puede
observar como se relacionan cada uno y como se relacionan con los sistemas externos.
57
<<system>>
EvoAgent
<<access/import>>
SQL
EvoAgentLibrary CRM Dynamics
EvoAgentBD
<<access/import>>
<<import>> Windows Task

<<access>> Scheduler
<<import>> <<import>>
<<import>>
<<access>> <<access>>
<<subsystem>> <<subsystem>> <<subsystem>>
EvoAgent EvoAgentServer EvoAgentManager WinAudit
Figura 5.6 Diagrama de Paquetes. Primer Nivel
EvoAgentBD se corresponde con el reflejo de los datos tal y como estn 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.
5.2.2 Subsistemas
EvoAgentServer es la aplicacin servidor. Contiene toda la lgica de acceso a datos
en el paquete dao y parte de la lgica de negocio del sistema en el paquete services.
Como se ha visto en el modelo de arquitectura en su mayora 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 travs de
EvoAgentLibrary.
EvoAgentManager es la aplicacin de gestin para los tcnicos, posee la lgica de

presentacin 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 travs de EvoAgentLibrary.
58
<<subsystem>> <<subsystem>>
EvoAgentServer EvoAgentManager
Programacion <<access/import>>
services
Tareas
EvoAgentLibrary iu
<<access/import>>
Figura 5.7 Diagrama de Paquetes. EvoAgentServer y EvoAgentManager
EvoAgentLibrary es la librera 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 librera ser compartida
por los distintos componentes de la aplicacin, y es utilizada para acceder a los
servicios web del servidor por el sistema EvoAgentManager.
<<subsystem>>
EvoAgentLibrary
Services Microsoft CRM

<<access/import>>
Dynamics
<<import>> <<access>>
<<access/import>> Windows Task

<<import>>
Dominio Dao Scheduler
<<access>>
<<import>> <<access>> EvoAgentServer

Services
SQL
WinAudit
EvoAgentBD
Figura 5.8 Diagrama de Paquetes. EvoAgentLibrary.
59
EvoAgent es la aplicacin 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
EvoAgentServer
Services
EvoAgentIcon
<<access/import>>
EvoAgentService <<subsystem>>
EvoAgentLibrary
<<import>>
Dominio
Figura 5.9 Diagrama de Paquetes. EvoAgent
60
6. Diseo Interno del Sistema
6.1 Diseo de la Interfaz de Usuario y Diagramas de Interaccin

En este apartado se va a exponer un anlisis interno del funcionamiento del sistema. Para
abordarlo se divide en tres apartados.
El primero, consta de los subsistemas EvoAgentServer, servidor de la aplicacin, y

EvoAgentManager, interfaz de gestin para los tcnicos de Evotec. Se mostrar el diseo de
la interfaz escogido y el resultado funcional de la interaccin 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 aplicacin, y

EvoAgent, cliente de la aplicacin ubicado en las mquinas cliente. La aplicacin cliente no
posee interfaz, salvo por el icono en la barra de tareas con el que el usuario de la mquina
cliente se podr informar de la aplicacin que se est ejecutando y podr acceder al servicio
de conexin remota. En estos casos se mostrar una pequea ventana o un men desde el
icono en la barra de tareas. El resto de la funcionalidad de la aplicacin cliente no viene
precedido de una interfaz de usuario pues no requiere de interaccin con el mismo. Se
analizar en este caso la interaccin que existe entre cliente y servidor mediante los
respectivos diagramas de secuencia.
El tercero se trata de la creacin del elemento Alerta dentro de la aplicacin CRM y del
funcionamiento de dicha aplicacin para poder trabajar con este elemento.
6.1.1 Subsistema EvoAgentManager e Interaccin con el Servidor

A continuacin se mostrar la funcionalidad de la aplicacin de gestin EvoAgentManager,
subsistema del presente proyecto, que estar ubicada en los puestos de los tcnicos de
Evotec. Para ello se mostrar el diseo final de la interfaz de usuario con los diagramas de
secuencia de las operaciones que puede realizarse a partir de dicho interfaz.
Para la eleccin del modelo de interfaz definitivo se ha tenido en cuenta a los usuarios
finales, es decir, los tcnicos de Evotec, de tal forma que se ha seguido el modelo de interfaz
que posee la aplicacin con la que ms se trabaja en dicha empresa y con la que adems, el
sistema a construir est ms ligado, Micorsoft CRM 3.0. Dicho interfaz a su vez esta basado
en el estndar 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
aplicacin desde el que poder acceder a toda la funcionalidad de la aplicacin y un
contenedor donde alojar cada ventana que se abra a modo de escritorio de la aplicacin.
61
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 pgina web:
http://www.codeplex.com/ASCENDNET los controles de Ascend.NET son una coleccin de
controles Windows Forms escritos en lenguaje C# para Visual Studio 2005 y .NET 2.0. Se
pueden descargar desde el link:
http://www.codeplex.com/ASCENDNET/Release/ProjectReleases.aspx?ReleaseId=317
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
libreras 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 6.3.
62
Antes de empezar a usar la aplicacin se proceder a realizar una validacin del usuario que
desea utilizarla de la forma que se indica en el diagrama de secuencia de la Figura 6.1.
6.1.1.1 Validacin Usuarios
EvoAgentManager . iu EvoAgentLibrary . Services System . Net . EvoAgentServer. services

. Form_Main . CredencialesUsuario CredentialCache . UsuariosManager
initLogin()
getDefaultNetworkCredential()
Cre : System . Net .
<<create>> NetworkCredentials
VALIDA USUARIO
Cre
authenticate()
True
[error]
System .Security . Principal
. WindowsIdentity
WI : System .Security
getCurrent().Name
<<createCurrent>> . Principal . WindowsIdentity
WI.Name
Dao . UsuarioAplicacionDAO
getUsuario
(NombreInicioSesion) U:Usuario
<<create>>
U
[error]
<<forward>>
error?
False EvoAgentManager . iu
True . Form_Login
getNombreCompleto()
Init()
Paquete superior::Tecnico Evotec
U.NombreCompleto <<forward>>
set(User, Pw, Domain)
IniciarSesion()
Figura 6.1 Diagrama de Secuencia. Validacin Usuario
63
Para realizar la validacin se ha escogido utilizar el registro que lleva de usuarios la

aplicacin 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
aplicacin, de forma que la consulta se deber realizar a dicha tabla.
Primeramente, se realiza una comprobacin 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 descripcin del servidor de la aplicacin, dicho
directorio tendr habilitada la autenticacin de Windows integrada de forma que el inicio de
sesin deber tener un usuario registrado en el dominio. Por otro lado, con el nombre de
inicio de sesin de Windows se obtiene los datos completos del usuario registrado en la base
de datos del sistema.
Si la autenticacin 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 Diseo de Interfaz. Login
Una vez autenticado el usuario se accede a la ventana principal de la aplicacin que se

observa en la Figura 6.3
64
Figura 6.3 Diseo 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

mdulos entre los que se reparte toda la funcionalidad (Parte inferior del men). Estos
mdulos son:
rea de Trabajo: Permite gestionar la actividad de los agentes y visualizar

informacin sobre los mismos.
Settings: Permite gestionar parmetros de configuracin de la aplicacin. Se

manejarn aspectos relevantes de la aplicacin como el Control de Alertas, gestin
de versiones de la aplicacin de las mquinas agente y la gestin de los usuarios de
la aplicacin.
Referencias: Permite ver la descripcin de la aplicacin y acceder a la aplicacin

CRM.
El mdulo principal es el rea de Trabajo. ste mdulo comprende varias funcionalidades

resumidas en los siguientes puntos:
Tareas: Donde se trabajar con las tareas asignables a las mquinas 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 auditoras as como dar acceso a
mquinas cliente al sistema.
Clientes/Dominios: Donde se podr asociar mquinas cliente con los clientes

registrados en la aplicacin de gestin CRM a travs de los dominios.
65
Logs: Donde se podr monitorizar el correcto funcionamiento del sistema.
6.1.1.2 Tareas
Desde aqu se podr gestionar las tareas que se registran para las mquinas cliente. Al
cargar se obtienen las tareas existentes y los datos que se utilizarn 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[ ]
Dao.TareaDAO
getTareas()
<<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 bsqueda de tareas; al seleccionar un elemento de cualquiera de las
categoras se dispara el evento Buscar Tarea de la figura 6.6. Las tareas resultado de la
bsqueda se muestran en la lista. Dicha lista se construir mediante un elemento
66
DataGridView que tiene un enlace de datos directo a una tabla de un DataSet y mtodos
automticos de ordenacin.
Por ltimo, el men de acciones se encuentra entre el filtro y la lista y comprende cada una
de las acciones que se explicarn ms adelante:
Figura 6.5 Diseo de Interfaz. Tareas (Form_Tareas)
67
BUSCAR TAREAS
. Inicio_Tareas
M : Dominio.Maquina
<<create>>
C : Dominio.Cliente
<<create>>
T : Dominio.Tarea
<<create>>
Dao.TareaMaquinaDAO
Dao.TareaMaquinaDAO
getTareasMaquinaByFilters
(M, C, T, Estado) 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 creacin de una nueva tarea. Los botones
del men permiten guardar la tarea o abrir la ventana de parmetros de las tareas que se
explican ms adelante.
68
Figura 6.7 Diseo 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 podrn crear varias tareas para
una mquina o para varias mquinas a la vez. Una vez configurado el tipo de Tarea,
dependiendo del mismo, se requerir introducir ms informacin para poder terminar de
configurar la tarea. Esto se indica en el diagrama mediante la llamada de Form_NuevaTarea
a Form_ParametrosTarea con la condicin: [NombreTarea = Auditoria,Servicio,Cuotas], es
decir, que si la tarea es una auditora, un inicio de servicio o una comprobacin de cuotas de
usuario se requiere configurar parmetros.
Al pulsar el botn 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 travs de la capa de datos.
Despus se cierra la ventana y se actualizan las tareas en la ventana de tareas (Figura 6.5).
La ejecucin de las tareas y su diseo en los programas agente se puede ver en el apartado
6.1.2.2 Mdulo EvoAgentService, en el punto Ejecutar Tarea.
A continuacin se muestra el diagrama de secuencia de la creacin de una nueva tarea:
69
NUEVA TAREA
. Form_Tareas
EvoAgentManager . iu EvoAgentManager . iu
. Form_NuevaTarea . Form_ParametrosTarea
NuevaTarea(Maquina[ ],
Cliente[ ], Tarea[ ])
Paquete superior::TecnicoEvotec
<<forward>>
Set(NombreMaquina[],NombreTarea[])
[NombreTarea = Auditoria,Servicio,Cuotas]
InicioParametros( )
<<forward>>
Set(Seleccin[])
<<ok>>
SetParametros()
Set(Fecha,Hora)
T : Dominio.TareaMaquina
Save
<<create>>
[idTarea = 1,4,5]
GetSeleccin()
setT (Maquina,
Tarea, Seleccion, Dao . TareaMaquinaDAO
Fecha)
CreateTareaMaquina( T )
Actualizar()
Figura 6.8 Diagrama de Secuencia. Nueva Tarea
Figura 6.9 Diseo de Interfaz. Parmetros de la Tarea (Form_ParametrosTarea)
70
Eliminar Tarea:
El usuario debe seleccionar una o varias tareas que desea eliminar de forma que se habilite
el botn eliminar y entonces pulsando dicho botn 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 mtodo actualizar que se ver ms
adelante.
ELIMINAR TAREA
. Form_Tareas
Dao.TareaMaquinaDAO
Eliminar Tarea(idTarea)
<<forward>>
Actualizar()
Figura 6.10 Diagrama de Secuencia. Eliminar Tarea Pendiente
Actualizar Tareas:
La finalidad de esta funcin consiste en obtener el estado modificado automticamente por

los programas agente de las mquinas a travs del servidor. Es necesario obtener los datos
nuevamente y se debern mostrar los datos que cumplan con los filtros que estn en ese
momento fijados. Por la tanto bastara con llamar al mtodo de bsqueda de tareas definido
anteriormente en la Figura 6.6.
ACTUALIZAR
. Form_Tareas
Buscar Tareas()
Figura 6.11 Diagrama de Secuencia. Revisar Estado Tarea
71
Editar Tarea:
Utiliza la misma ventana que el evento Nueva Tarea (Figura 6.7). En este caso el cliente y la
mquina, 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 botn editar y pulsando dicho botn el sistema obtendr la tarea seleccionada y se
la pasar a la ventana nueva tarea. Se puede editar los parmetros de la tarea o la fecha de
ejecucin de la misma.
EDITAR TAREA
. Form_Tareas
. Form_NuevaTarea . Form_ParametrosTarea
T : Dominio .
EditarTareaMaquina TareaMaquina
(TareaMaquina)
<<create>>
[NombreTarea = Auditoria,Servicio,Cuotas]
Inicio(Seleccion)
Paquete superior::TecnicoEvotec <<forward>>
SetParametros()
Show()
<<forward>>
Set(Seleccin[])
<<ok>>
Set(Fecha,Hora)
Save
[idTarea = 1,4,5]
GetSeleccin()
setT(Seleccion,Fecha)
Dao.TareaMaquinaDAO
updateTarea( T )
Actualizar()
Figura 6.12 Diagrama de Secuencia. Editar Tarea
72
Programar Tarea:
Para la generacin 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 Diseo 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 aplicacin (Figura 6.5). Las distintas opciones del men permiten el paso entre
las ventanas que contienen los diferentes elementos a configurar, que sern:
Tarea: La tarea para las mquinas 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
Figura 6.14 Diseo de Interfaz. Credenciales de la Tarea Programada (Form_CredencialesTareaProgramada)
Programacin: Se deber configurar la programacin de la tarea conforme a

las posibilidades que ofrece la herramienta TaskScheduler de Windows. Se
podrn generar programaciones diarias, semanales o mensuales para una
tarea, establecer la fecha de inicio, la hora de ejecucin, la fecha de fin y
algunos atributos relevantes de las tareas programadas:
74
Figura 6.15 Diseo de Interfaz. Programacin de la Tarea Programada (Form_ProgramacionTarea)
Una vez configurados todos los elementos de la tarea programada y pulsando sobre el botn
Guardar del men de la izquierda el sistema inicia el proceso de guardado de la tarea
programada. A continuacin se muestra el proceso de generacin de una tarea programada
completo (diagrama de secuencia Programar Tarea, Figura 6.16), incluyendo la
configuracin de los diversos elementos. El proceso de guardado de la tarea programada
comienza al finalizar la interaccin con el usuario -momento en el que se pulsa Guardar-
mediante el mtodo Save() que se observa en el diagrama.
75
EvoAgentManager . iu EvoAgentManager . iu PROGRAMAR TAREA

. Form_Tareas . Form_TareasProgramadas
EvoAgentManager . iu EvoAgentManager . iu EvoAgentManager . iu

ProgramarTarea(Cliente[ ],
. Form_NuevaTarea . Form_Programacion . Form_Credenciales
Tarea[ ], Maquina[ ])
NuevaProgramacion(Cliente[ ], Tarea[ ], Maquina[ ])
Paquete superior::Tecnico <<forward>>
Set(NombreMaquina[],NombreTarea[])
. Form_ParametrosTarea
[NombreTarea = Auditoria,
<<forward>> Servicio,Cuotas]
InicioParametros( )
Set(Seleccin[])
<<ok>>
SetParametros()
Set(Programacion, Dias,Meses, DiaSemana, DiaMes, Diario, FechaIni, HoraIni, FechaFin, Flags)
Set(NombreUsuario, Password)
Save()
getCredenciales()
TPR : Dominio.TareaProgramada
<<create>>
getTareas() T : Dominio.TareaMaquina
Set(User, Password)
<<create>>
[idTarea = 1,4,5]
GetSeleccin()
setT (Maquina,
Tarea, Seleccion)
TareaMaquina[ ]
SetTareas(T[])
getProgramacion() Tg : Dominio.MiTrigger
<<create>>
setProgramacion()
Tg
SetTrigger(Tg)
Dao.TareaProgramadaDAO
CreateNewTareaProgramada(TPR)
(*1) Contina
Figura 6.16 Diagrama de Secuencia. Programar Tarea I
76
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 configuracin de la tarea programada almacenndolos
en sta, lase, el Usuario y Contrasea de la Ventana Credenciales, las Tareas para las
mquinas Agente de la Ventana Nueva Tarea y la Programacin de la tarea (Trigger =
MiTrigger del Modelo de Dominio) de la ventana Programacin 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 PROGRAMAR TAREA

. Form_TareasProgramadas Dao.TareaProgramadaDAO
(*1) Continuacin
CreateNewTareaProgramada(TPR)
Ta : EvoAgentLibrary
. TaskScheduler . Task
<<create>>
EvoAgentLibrary . Servicios
. InterpreteProgramacionTarea Set( Nombre, WorkingDirectory,
Aplicacin, Creator, Flags,
AccountInformation, Priority)
Tr : EvoAgentLibrary ConvertMiTriggerToTrigger(TPR.Trigger)
. TaskScheduler . Trigger
<<create>>
Set()
Tr
SetTrigger( Tr)
Server.TaskScheduler
CreateTask( Ta )
ConvertTareasMaquinaToXML(TPR.Tareas)
EvoAgentServer . Servicios
. ControlAdmin
DataSet
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 descripcin de la carpeta AdminManager del Servidor de la aplicacin, 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 aplicacin que se encarga de registrar la tarea en el servidor seguido del
atributo que es el nombre de la tarea programada. La aplicacin en cuestin 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
Como se ha explicado en el apartado 5.1 estos dos ficheros residirn en el espacio de

direcciones del servidor, en la carpeta ProgramacionTareas junto a la aplicacin comentada
(ProgramacionTareas.exe), por lo que es necesario que el sistema enve la informacin
necesaria para que el servidor de la aplicacin genere dichos documentos en su espacio de
direcciones. Para ello se sirve de una clase auxiliar de la librera, Intrprete, que traduce la
informacin de las tareas para las mquina 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 informacin de ejecucin:
Credenciales, Aplicacin a ejecutar, Flags, Nombre y Trigger que debe crearse acudiendo
de nuevo al Intrprete 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 botn Ver Tareas
Programadas. Se mostrar en la lista de la siguiente ventana la informacin de las tareas.
Figura 6.18 Diseo de Interfaz. Ver Tareas Programadas
El proceso de recuperacin de las tareas es contrario al de creacin de una tarea

programada y se muestra en el diagrama de secuencia de la Figura 6.19. 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 informacin: se obtiene la programacin de la Task, almacenada
en un campo descriptivo para poder interpretarla, y se recurre de nuevo al Intrprete de la
librera de la aplicacin para obtener la clase MiTrigger que contiene dicha programacin. Se
obtiene las tareas para las mquinas agente a travs del servidor y de nuevo, del intrprete.
Una vez se tiene las Tareas Programadas se pasan a la ventana Ver Tareas Programadas.
78
EvoAgentManager . iu EvoAgentManager . iu VER TAREAS PROGRAMADAS

. Form_Tareas . VerTareasProgramadas
Server . TaskScheduler
MostrarTareasProgramadas()
Dao . TareasProgramadasDAO
LT: EvoAgentLibrary .
TaskScheduler . TasksList
getTarProgramadas() getTaskNames()
<<create>>
Tpr : EvoAgentLibrary
openTask(nombre) . TaskScheduler . Task
<<create>>
Tpr
TPR : Dominio.TareaProgramada
<<create>>
EvoAgentLibrary . Servicios EvoAgentServer . Servicios
Set( Nombre, Aplicacin, Creator, . InterpreteProgramacionTarea . AdminManager
User, ProxEjecucion, UltimaEjecucion)
ConvertCommentToMiTrigger(Tpr.Comment)
<<create>>
Tg : Dominio.MiTrigger
Set()
Tg
SetMiTrigger (Tg)
getPropiedadesTareaProgramada(nombreTarea)
DataSet
ConvertXmlToTareasMaquina(DataSet)
<<create>>
Tm : Dominio . TareaMaquina
Set()
TareaMaquina[ ]
SetTareas (Tm[ ])
TareaProgramada[ ]
Figura 6.19 Diagrama de Secuencia. Ver Tareas Programadas
79
La ventana Ver Tareas Programadas (Figura 6.18) posee un men encima de la lista de
tareas a travs del cual se puede:
Abrir Propiedades Tarea Programada:
Mediante el cual se puede modificar la tarea Programada. Se abrira la ventana vista en la

Figura 6.13 con la informacin de la tarea actual. Tras configurar de nuevo la tarea
programada y pulsar Guardar se borrar la tarea programada existente con el mtodo 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 botn
eliminar se iniciara el siguiente proceso que borrara por completo la tarea programada del
sistema.
ELIMINAR TAREA PROGRAMADA
EvoAgentManager . iu Dao.TareaProgramadaDAO Server.TaskScheduler EvoAgentServer . services

. VerTareasProgramadas . ControlAdmin
deleteTareaProgramada(nombre)
deleteTask(nombre)
deleteTaskProperties(nombre)
<<forward>>
Figura 6.20 Diagrama de Secuencia. Eliminar Tarea Programada
Registro de Tareas de una Tarea Programada. Paquete Programacin Tareas de

EvoAgentServer
El objetivo de la tarea programada es registrar tareas para mquinas cliente de forma

automtica. Para ello se explicar aqu el funcionamiento del programa
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 mquina agente lleve tiempo sin comunicarse.
80
INICIO
SI
Argumentos Leer Mquinas y
Tareas
Leer Argumento
Nombre fichero
De Entrada
Argumento Abrir Fichero de

Tarea
Argumento =
crear Tarea XML
Tarea
NO
Leer Tareas
Comprobacin
Comunicaciones
Obener
Programacion
Tarea
Calcular Prxima
Ejecucin
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 comunicacin de los agentes:
1. Comprobar Comunicaciones: Se procede segn el siguiente diagrama de secuencia:
81
COMPROBACION COMUNICACIONES
EvoAgentLibrary . Dao EvoAgentServer . Servicios

. ControlComunicacionesDAO . ControlAgente
ControlComunicacion() System . AppDomain
getRutaServidor()
get(CurrentDomain
. BaseDiretory)
URL
URL
Dao.MaquinasDAO
getMaquinas() M : Dominio . Maquina

<<create>>
M[ ]
Dao.AlertaDAO
NewAlerta(Tipo., Maquina,
Parametro, rutaServidor)
registroAlerta
<<forward>>
<<forward>>
Figura 6.22 Diagrama de Secuencia. Comprobar Comunicaciones de los Agentes
La clase AlertaDAO mediante su mtodo esttico NewAlerta se encargar de generar las

alertas y registrarlas en la aplicacin CRM. Esto se muestra en el apartado 6.1.3.3
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 informacin de las tareas para las mquinas.
Leer Tareas: Se obtienen las tareas leyendo el fichero xml.
Obtener Programacin Tarea: Una vez se ha obtenido las tareas faltara

obtener la fecha de ejecucin de las tareas en las mquinas. Dicha fecha
depende de la programacin que se escogi para la tarea programada, por lo
que se har necesario obtener la programacin de dicha tarea que viene en el
archivo xml.
82
Calcular Prxima Ejecucin: Depende de la programacin que se escogi

para la tarea programada. La fecha de ejecucin de las tareas en las
mquinas cliente ser la fecha que corresponda a la prxima ejecucin segn
la programacin de la tarea. As, a cada ejecucin de la Task se crear las
tareas para la siguiente ejecucin. Esto har que la primera ejecucin no
tenga efectos hasta la siguiente.
Registrar TareaMaquina: Una vez se conoce la fecha de ejecucin y las

tareas a ejecutar se puede proceder a registrar las tareas:
CREAR TAREAS
ProgramacionTareas.exe EvoAgentServer . dao

. TareasMaquinaDAO
T : Dominio.TareaMaquina
<<create>>
setT(Maquina,
Tarea, Fecha)
createNuevaTarea(T)
Figura 6.23 Diagrama de Secuencia. Registrar TareaMaquina
6.1.1.3 Maquinas
En este apartado se pretende configurar varios aspectos de los programas agentes
(maquinas). Por otro lado se realizar la presentacin del resultado de las auditoras
realizadas en las mquinas. Se accede a la ventana de mquinas desde la ventana principal.
Al cargarse se sigue el proceso indicado por el siguiente diagrama de secuencia:
83
INICIO MAQUINAS
Dao . ClientesDAO
. Form_Maquinas
getClientes()
C:Cliente
<<create>>
Cliente[ ]
Dao . MaquinaDAO
getMaquinas()
M:Maquina
<<create>>
Maquina[ ]
Figura 6.24 Diagrama de Secuencia. Inicio Mquinas
Tras el proceso se mostrar la siguiente ventana:
Figura 6.25 Diseo de Interfaz. Mquinas (Form_Maquina)
Esta ventana tiene los siguientes procesos asociados:
84
Buscar Mquina:
Pertenece al cuadro superior de la ventana que acta como filtro de mquinas a mostrar.
Cuando se seleccione un cliente o bien se introduzca el nombre de una mquina o parte de
el y se pulse sobre el botn de bsqueda se proceder a cargar las mquinas en la lista.
Para ello se recurrir a la capa de datos como se indica en el diagrama de secuencia:
BUSCAR MAQUINAS
Dao . MaquinaDAO
. Form_Maquinas
MostrarMaquinas(NombreCliente)
MostrarMaquina(nombreMaquina)
Maquina[]
Figura 6.26 Diagrama de Secuencia. Buscar Mquinas
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 mquina va a poder comunicarse con el sistema.

Por defecto, al darse de alta una mquina, no tendr permiso para
comunicarse.
Tipo de Agente: Indica si un programa agente est instalado en una mquina

servidor o en una mquina pc. En funcin del tipo de mquina en que est
instalado, un agente realizar diferentes acciones.
Auto-desfragmentacin (Auto-Dfrag): Esta propiedad indica, cuando est

activada, que el agente lanzar un proceso del sistema operativo de
desfragmentacin de las unidades de disco. Dicho proceso procede a
desfragmentar las unidades cuando sea necesario.
Un agente o mquina queda configurado segn estos parmetros cuando se pulsa el botn
guardar de la columna de la derecha. En ese momento se procede a guardar la
configuracin mediante la capa de datos tal y como se indica en el diagrama de secuencia:
85
MODIFICAR ATRIBUTOS DE MAQUINAS
. Form_Maquinas Dao . MaquinaDAO
GuardarParametros(permiso, tipoAgente, desfragmentar, idMaquina)

M: Dominio.Maquina
<<create>>
setM(permiso,tipo,dfrag)
<<forward>>
Figura 6.27 Diagrama de Secuencia. Modificar los atributos de un programa agente
Ver Detalle de Mquina:
Debe de seleccionarse una mquina de la lista de la ventana maquina y pulsar el botn Ver
Detalle Maquina. El resultado del proceso de lectura del detalle de una mquina se muestra
en una ventana que contiene todos los campos reflejados en la documentacin presentada
en el Anexo 3 Documentacin sobre las caractersticas del inventario de WinAudit (En
Ingls). Para ello se ha diseado 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 6.28.
86
Figura 6.28 Diseo de Interfaz. Detalle de Auditoria de Maquina (DetalleMaquina)
Antes de mostrar el proceso que se sigue para generar el detalle de una mquina se ha de
entender que la informacin procede de los ficheros xml que genera la aplicacin WinAudit.
Es, por tanto, necesario la generacin de un mtodo uniforme de lectura de dichos datos y la
generacin 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 diseadas y siguiendo el orden de categoras 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 sera el que se muestra a continuacin:
87
EvoAgentLibrary . Services LeerAuditoria

. LeerAuditoriaXML
LeerAuditoria(Auditoria, VG : Dominio.WinAudit.
urlWorkingDirectory) VistaGeneral
<<create>>
Set()
Act : Dominio.WinAudit.
<<create>> Maquina_Actualizacion
Set()
P : Dominio.WinAudit.
<<create>> Maquina_Programa
Set()
SO : Dominio.WinAudit.
<<create>> Maquina_SSOO
Set()
Pf : Dominio.WinAudit.
<<create>> Maquina_Periferico
Set()
PuA : Dominio.WinAudit.
<<create>> Maquina_PuertoAbierto
Set()
SS : Dominio.WinAudit.
<<create>> Maquina_SettingSeguridad
Set()
PrivilegiosUsuario :
<<create>> String
Set()
WFS : Dominio.WinAudit.
<<create>> Maquina_WindowsFirewallSeting
Set()
TP : Dominio.WinAudit.
<<create>> Maquina_TareaProgramada
Set()
(*1) Contina
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 Auditora que recibe el mtodo es un dataSet que contiene el Xml. Un
DataSet tiene un mtodo que permite escribir el contenido como xml, as, se podra crear un
fichero xml a leer por el XmlTextReader. El otro parmetro urlWorkingDirectory le indica al
mtodo 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

. LeerAuditoriaXML (*1) Continuacin
EA : Dominio.WinAudit.
<<create>> Maquina_EstadisticasArranque
Set()
Err : Dominio.WinAudit.
<<create>> Maquina_ErrorLog
Set()
NF : Dominio.WinAudit.
<<create>> Maquina_NetworkFile
Set()
NSe : Dominio.WinAudit.
<<create>> Maquina_NetworkSession
Set()
NSh : Dominio.WinAudit.
<<create>> Maquina_NetworkShare
Set()
NTCP : Dominio.WinAudit.
Maquina_NetworkTCPIPControler
<<create>>
Set()
NBA : Dominio.WinAudit.
<<create>> Maquina_NetBIOSAdapter
Set()
Dis : Dominio.WinAudit.
<<create>> Maquina_Dispositivo
Set()
CP : Dominio.WinAudit.
<<create>> Maquina_CaractristicaPantalla
Set()
I : Dominio.WinAudit.
<<create>> Maquina_Impresora
Set()
(*2) Contina
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 6.31.
89

. LeerAuditoriaXML (*2) Continuacin
PtC : Dominio.WinAudit.
<<create>> Maquina_PortConnector
Set()
SysSt : Dominio.WinAudit.
<<create>> Maquina_SystemSlot
Set()
Pr : Dominio.WinAudit.
<<create>> Maquina_Procesador
Set()
Memo : Dominio.WinAudit.
<<create>> Maquina_Memoria
Set()
Df : Dominio.WinAudit.
<<create>> Maquina_DiscoFisico
Set()
Dl : Dominio.WinAudit.
<<create>>Maquina_DiscoLogico
Set()
PA : Dominio.WinAudit.
<<create>> Maquina_ProgramaArranque
Set()
Servicio : Dominio.WinAudit.
<<create>> Maquina_Servicio
Set()
Driver : Dominio.WinAudit.
<<create>> Maquina_Servicio
Set()
PE : Dominio.WinAudit.
<<create>> Maquina_ProgramaEjec
Set()
Mod : Dominio.WinAudit.
<<create>> Maquina_Modulo
Set()
CA : Dominio.WinAudit.
<<create>> 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)
Set(Df[ ], Dl[ ], PA[ ], Servicio[ ], Driver[ ], PE[ ], Mod[ ])

CA

90
La tarea auditora de una mquina debera ejecutarse diariamente con los campos
necesarios para generar alertas, y se puede disear para que la auditoria de un da elimine
la del da anterior siempre que tenga los mismos campos auditados y as no se produzca
acumulacin de auditorias. No obstante, se podr llegar a tener registradas varias auditorias
de una misma mquina por lo que es necesario leer los campos coincidentes de la ms
reciente con lo que ser necesario gestionar la lectura de auditorias y los campos final que
se presentan.
El mtodo anteriormente mostrado nicamente se encarga de convertir un DataSet que

contiene un documento xml en una clase coleccin de todos los campos pertenecientes a
una auditoria de WinAudit. Por lo que se requerir un mtodo que gestione lo expuesto en el
prrafo anterior. Por otro lado, es necesario descargarse la informacin sobre las auditoras
mediante la capa de datos y los propios documentos xml a travs del servicio web del
servidor. As, el proceso a seguir para mostrar el detalle de una mquina se muestra en el
siguiente diagrama de secuencia:
91
EvoAgentManager . iu EvoAgentManager . iu Dao . DetalleAuditoriaDAO VER DETALLE MAQUINA

. Form_Maquinas . DetalleMaquina
VerDetalleMaquina(idmaquina)
getAuditorias(idMaquina)
DA:DetalleAuditoria
<<create>>
DetalleAuditoria[ ]
EvoAgentServer . Servicios
getAuditoriasXML(DA[ ].idAuditoria) . ControlAdmin
getAuditoriasXML(idAuditorias[ ])
Ds: System.Data.DataSet
<<create>>
readXML(ruta+idAuditoria)
DataSet[ ]
DataSet[ ]
EvoAgentLibrary . Services EvoAgentLibrary . Services

. LeerAuditoriaXML . LeerAuditoriaXML
gestionAuditoriaDetalleMaquina
CAdef : Dominio.WinAudit.
(DA[ ], D[ ], urlWorkingDirectory)
<<create>> CamposAuditoria
LeerAuditoria(Auditoria, urlWorkingDirectory)
LeerAuditoria
CamposAuditoria
set(CamposSeleccionados)
CAdef , camposSelec[ ]
Figura 6.32 Diagrama de Secuencia. Ver Detalle Mquina
92
6.1.1.4 Clientes\Dominios
Es el mdulo pensado para la gestin de dominios bajo los que se identificarn las mquinas
con los clientes. Dicha asociacin se hace necesaria si se desean registrar alertas en la
aplicacin CRM y asociarlas a un cliente registrado. Al iniciar se carga el mdulo con los
datos necesarios siguiendo el siguiente proceso:
INICIO CLIENTES
Dao . ClientesDAO
. Form_Clientes
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 mdulo.
93
CREAR NUEVO DOMINIO ELIMINAR DOMINIO Y ASOCIACIONES

ASOCIAR CLIENTE Y DOMINIO
AADIR/BORRAR CLIENTES ASOCIAR/BORRAR MAQUINAS A CLIENTE Y DOMINIO
Figura 6.34 Diseo de Interfaz. Inicio Clientes (Form_Clientes)
Crear Nuevo Dominio:
CREAR NUEVO DOMINIO
EvoAgentManager . iu EvoAgentServer . dao

. Form_Clientes . DominioDAO
createDominio(nombre)
D:Dominio.Dominio
<<create>>
setD(id,nombre)
<<forward>>
Figura 6.35 Diagrama de Secuencia. Crear Nuevo Dominio
94
La instalacin de un agente en una mquina lleva asociada una comunicacin con el

servidor tal y como se ver ms adelante. En dicha comunicacin se pretende enviar
informacin de la mquina al servidor para que ste la registre en el sistema. En dicha
informacin estar incluido el dominio al que pertenece la mquina. 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 podrn registrar dominios introduciendo el
nombre del mismo.
Actualizar Clientes:
Como se ha explicado anteriormente, el cliente asociado a una mquina tiene una funcin
especfica que es la de servir de referencia a la hora de generar alertas en la aplicacin
CRM. Por tanto, la gestin de clientes registrados en el sistema se llevar a cabo mediante
el uso de los clientes registrados en dicha aplicacin. Se podr copiar clientes del CRM o
borrar clientes registrados.
AGREGAR CLIENTES
Dao.ClientesDAO Dao . CRMDAO
. Form_Clientes
getClientesCRM()
CRMCli : Cliente
<<create>>
CRMCli[ ]
getClientes()
Cli:Cliente
<<create>>
Cli[ ] . Form_SelectElementos
MostrarClientes((CrmCli[] - Cli[]).nombreCli)
Paquete superior::Tecnico
<<forward>>
Select+OK
nombre[ ]
createNewClientes(Cliente[ ])
Actualizar()
Figura 6.36 Diagrama de Secuencia. Agregar Clientes
95
Para agregar clientes se mostrarn, por tanto, los clientes que estn registrados en el CRM y
no lo estn 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 Diseo de Interfaz. Seleccionar (Form_SelectElementos)
Al eliminar un cliente del sistema hay que tener en cuenta las mquinas y los dominios
asociados:
96
EvoAgentManager . iu Dao.ClientesDAO
ELIMINAR CLIENTES
. Form_Clientes
getClientes()
Cli:Cliente
<<create>>
Cli[ ] . Form_SelectElementos
MostrarClientes(Cli[])
<<forward>>
Select+OK
nombre[ ]
deleteClientes(idCliente[])
<<forward>>
Dao.DominioDAO
updateDominio(idDominio[ ], idCli=null)
D:Dominio.Cliente
<<create>>
Set(idCli = null,
Actualizar() sRazon = null)
Dao.MaquinaDAO
updateMaquina
(idMaquina[ ], idCli=null,sRazon = null) M:Dominio.Maquina
<<create>>
Set(idCli = null,
Actualizar() 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 6.34.
97
ASOCIAR DOMINIO CON CLIENTE
EvoAgentManager . iu EvoAgentServer . dao EvoAgentServer . dao

. Inicio_Clientes . DominioDAO . ClienteDAO
updateDominio(idCliente,
idDominio) getCliente(idCli)
C:Cliente
<<create>>
D:Dominio.Dominio
<<create>>
setCliente(C)
Actualizar()
Figura 6.39 Diagrama de Secuencia. Asociar Dominio con Cliente
Asociar Mquinas a Dominio y Cliente:
ASOCIAR MAQUINAS A DOMINIO Y CLIENTE
. Inicio_Clientes . Form_SelectElementos
MostrarMaquinas[Nombres]
<<forward>>
Select+OK
nombres[]
Dao.MaquinaDAO
updateMaquina(Dominio, idMaquina[])
M:Maquina
<<create>>
setM(D.idDom,D.nombreD,
Actualizar() D.idCli,D.nombreC)
Figura 6.40 Diagrama de Secuencia. Asociar Maquinas a Dominio y Cliente
98
Los dominios existentes en el sistema con sus clientes asociados se mostrarn en el cuadro
superior derecho de la Figura 6.34. Para agregar mquinas a un dominio se deber
seleccionar un dominio y pulsar sobre asociar mquinas y Agregar. En el proceso ser
necesario seleccionar las mquinas que se desean asociar para lo cual se utilizar de nuevo
la ventana de la Figura 6.37.
Para borrar mquinas se proceder de la misma manera pulsando, esta vez, sobre asociar y
borrar.
BORRAR MAQUINAS DE DOMINIO Y CLIENTE
. Form_Clientes . Form_SelectElementos
MostrarMaquinas[Nombres]
<<forward>>
Select+OK
nombres[]
Dao . MaquinaDAO
UpdateMaquina(idMaquina[ ],
null, null, null, null) M:Maquina
<<create>>
setM(idCli = null, sRazon = null

Actualizar() idDom = null, NombreDom= null)
Figura 6.41 Diagrama de Secuencia. Borrar Mquinas de Dominio y Cliente
Eliminar Dominio y Asociaciones:
99
ELIMINAR DOMINIO Y ASOCIACIONES
Dao . DominioDAO Dao . MaquinaDAO
. Inicio_Clientes
deleteDominio(idDom)
D:Dominio
<<destroy>>
updateMaquinas(idmaquina[],null,null,null,null)
M:Maquina
<<create>>
setM(idCli = null, sRazon = null

idDom = null, NombreDom= null)
Figura 6.42 Diagrama de Secuencia. Eliminar Dominio y Asociaciones
6.1.1.5 Logs
Este apartado esta pensado para la gestin de errores en el funcionamiento de la aplicacin
y para el control de las actividades de las mquinas agente.
Los errores pueden haber sido generados por las mquinas cliente, por el servidor o por la
interfaz registrndose 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
descripcin del error que incluye el origen en el cdigo del error. La descripcin de un error
suele ser una cadena de texto bastante extensa con lo que se ha diseado un mecanismo
mediante el cual las descripciones se guardarn 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 tambin
el origen y la fecha del error.
La siguiente ventana mostrar los errores registrados:
100
Figura 6.43 Diseo de Interfaz. Errores (Form_Log)
En la Figura 6.43 se observa que la ventana tendr dos pestaas en la parte superior para
poder cambiar entre acciones y Errores. La figura muestra la pestaa Errores. Se observa un
filtro de bsqueda de errores en la parte superior. En el despegable Origen se mostrar
cliente o servidor y se referirn a los errores generados en los agentes o en el servidor e
interfaz respectivamente. Seleccionando cliente se podr escoger los errores de un cliente
especfico o de una mquina especfica. Al mostrar los errores se seguir el siguiente
proceso, mediante el cual se obtiene la informacin del error registrada en la base de datos:
VER ERRORES
Dao . ErroresDAO
. Form_Log
getErrores(Origen, Fechas)
E : Dominio . ErrorAplicacion
<<create>>
ErrorAplicacion[ ]
Figura 6.44 Diagrama de Secuencia. Ver Errores
101
Una vez se muestren los errores se podr acceder a la descripcin pulsando sobre el botn
Ver Descripcin que aparecer sobre la misma lnea del error. Se lanza un proceso que
descargar el archivo de texto des servidor mediante el servicio web de administacin:
VER DESCRIPCIN ERROR
EvoAgentManager . iu EvoAgentService . services

Dao . ErroresDAO
. Form_Log . ControlAdmin
getDescripcionError(Error)
getDescripcionError(id, Tipo)
String desc
String desc
System.Windows.Forms.
<<create>> MessageBox
Show(desc, tirulo, botones, icono)
Figura 6.45 Diagrama de Secuencia. Ver Descripcin Error
Para mostrar la descripcin se usar una clase del Framework de .NET denominada
MessageBox que, pasndole los parmetros que se observan en el diagrama de secuencia
de la Figura 6.45, muestra la siguiente ventana:
Figura 6.46 Diseo de Interfaz. Mensajes (MessageBox)
Borrar Errores: Se podr borrar un error especfico pulsando sobre el botn borrar
que aparece al final de la misma lnea que la informacin del error. Tambin se
pueden borrar todos los errores que aparecen en la lista de errores. Se seguir el
siguiente proceso:
102
BORRAR ERROR
EvoAgentManager . iu EvoAgentService . services

Dao . ErroresDAO
. Form_Log . ControlAdmin
deleteError(Error)
deleteError(id, Tipo)
err : Dominio.ErrorAplicacion
<<delete(id)>>
Figura 6.47 Diagrama de Secuencia. Borrar Error
Registro Error: En cualquier accin del sistema puede ocurrir situaciones

inesperadas que impidan la correcta conclusin de la accin en cuyo caso se
generara un error en forma de la clase Excepcin anteriormente comentada. El
sistema ha sido diseado 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 ErrorAplicacin y se proceder a registrarla en el
sistema mediante la capa de datos. Aqu se muestra el proceso que se seguira a
partir de la capa de datos tras recibir el Error:
REGISTRO ERROR
Dao . ErrorAplicacionDAO EvoAgentService . services

. ControlAdmin
System . AppDomain
[rutaServidor = null] createError(err)
get(CurrentDomain
[rutaServidor != null]
System . IO . File . BaseDiretory)
<<create>>
URL Dao . ErrorAplicacionDAO
SetNombre(rutaServidor + err.id)
registroError(Error, rutaServidor)
WriteLine(err.Descripcion)
registroError
<<forward>>
<<forward>>
Figura 6.48 Diagrama de Secuencia. Registro Error
103
Hasta aqu se ha mostrado el funcionamiento de la gestin de Errores. En este apartado

tambin se gestiona las acciones de las mquinas 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 6.1.2. La ventana de la Figura
6.43 posee dos pestaas, de las cuales se muestra la correspondiente a los Errores. A
continuacin se muestra la correspondiente a las acciones:
Figura 6.49 Diseo de Interfaz. Acciones de los Agentes (Form_Log)
Como se ve la ventana tambin tiene una caja en la parte superior mediante la que realizar
un filtro de bsqueda. En este caso, a diferencia de los errores, slo se originan acciones en
los clientes. Al seleccionar una mquina se podr ver las acciones realizadas por la misma
en la fecha marcada. Se puede seleccionar ver las acciones registradas para una mquina
en todos los das.
Se podr borrar un log de un da de una mquina o borrar el log a partir de una fecha. Los
procesos seguidos son los tpicos ya vistos de acceso a los datos mediante la capa de datos,
para obtener Acciones o borrarlas.
104
6.1.1.6 Mdulo Settings

Es el mdulo pensado para la gestin de parmetros de funcionamiento de la aplicacin. Los
parmetros se almacenarn en la base de datos. Como se ve en la ventana principal de la
aplicacin, Figura 6.3, para acceder al mdulo de settings se deber hacer desde la parte
inferior del men de la izquierda. En la parte superior se mostrarn las posibles opciones:
Figura 6.50 Diseo de Interfaz. Settings (Form_Main)
Gestin de Alertas:
En este apartado se pretende presentar todos los parmetros relacionados con la

generacin de alertas. En concreto, se hace referencia al usuario del dominio que se
presentar en la aplicacin CRM como propietario de las alertas que se generen (se
puede modificar en la misma aplicacin para cada alerta). Por otro lado, se establecen los
filtros necesarios para controlar la generacin 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
lgicos de una mquina 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 tamao
de las cuotas de los usuarios de un dominio, en la ejecucin de tareas programadas, en
las backup locales o en los usuarios registrados en un dominio. Las cuatro ltimas son
especficas 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
Figura 6.51 Diseo de Interfaz. Gestin de Alertas (Form_GestionDeAlertas)
En el conjunto Filtro de generacin 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 mximo o mnimo segn corresponda a partir del
cual se generara una alerta. Adems 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 botn
Aplicar, se proceder segn el siguiente diagrama de secuencia:
GUARDAR VALOR SETTING
. Form_GestionAlertas/
Dao . SettingsDAO
Form_GestionVersiones
updateSetting(valor, idSetting)
AS:Dominio.ApplicationSetting
<<create>>
Set(valor)
106
Figura 6.52 Diagrama de Secuencia. Guardar Valor Setting
Adems, para cargar los valores al inicio se procede de manera similar:
CARGAR SETTINGS
. Form_GestionAlertas/
Dao . SettingsDAO
Form_GestionVersiones
getSettings()
AS:Dominio.ApplicationSetting
<<create>>
ApplicationSetting[ ]
Figura 6.53 Diagrama de Secuencia. Cargar Settings
La tabla Elementos generadores de la Figura 6.51 se configurara 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 activacin del
filtro (Columnas PC y Servidor), se podr pulsar un botn Filtro que abrir una ventana
para configurar el filtro.
Filtro de Programas: El filtro de programas es el ms 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 producirn alerta al
detectar una instalacin o desinstalacin.
Figura 6.54 Diseo de Interfaz. Configuracin Filtro de Programas (Form_FiltroAlerta)

107
Filtro de Servicios: Los servicios de Windows instalados en las mquinas

agente generarn alerta si son automticos y no estn iniciados. Para que no
siempre sea as y se pueda controlar el volumen de generacin 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 Diseo de Interfaz. Configuracin Filtro de Servicios (Form_FiltroAlerta)
Aparecern los servicios registrados en el sistema y se podr desactivar la

generacin 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
configuracin.
Filtro de Errores: Los errores de Windows que aparecen en el visor de

eventos son recogidos por los agentes y enviados junto con la auditora.
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 generacin de alertas para cada uno y por
tipo de Agente. Los errores vienen identificados por un nmero de instancia
que corresponde al cdigo que deja la aplicacin que genera el evento. As
se puede reconocer unvocamente 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
Figura 6.56 Diseo de Interfaz. Configuracin Filtro de Errores (Form_FiltroAlerta)
Gestin de Usuarios:
Se han establecido dos tipos de Usuarios. Usuario Administrador y Usuario Tcnico. Los
Usuarios Administrados tendrn acceso a toda la aplicacin mientras que los tcnicos no
podrn acceder a este apartado ni al apartado Gestin de Versiones. Si se tiene permiso
para acceder se mostrar la siguiente ventana:
109
Figura 6.57 Diseo de Interfaz. Gestin 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 aplicacin 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 EvoAgentLibrary .
. Form_GestionUsuarios Dao . UsuarioAplicacionDAO CredencialesUsuario
compruebaUsuarioAdmin()
get(Current.User)
String User Dao . UsuarioAplicacionDAO
getTipoUsuario(User)
U:Dominio.UsuarioAplicacion
<<create>>
TipoUsuario
bool
getUsuarios()
U:Dominio.UsuarioAplicacion
<<create>>
Usuarios[ ]
Figura 6.58 Diagrama de Secuencia. Cargar Gestin de Usuarios
110
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
6.1.1.4, los usuarios del sistema se corresponden con los registrados en la aplicacin
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 travs de la
ventana seleccin de elementos de la Figura 6.37. El proceso es el que se indica a
continuacin:
. Form_GestionUsuarios Dao . UsuariosAplicacionDAO Dao . CrmDAO
AGREGAR USUARIOS
getUsuariosCRM()
CrmU : Dominio .
<<create>> UsuarioAplicacion
CrmU[ ]
mostrar(CrmU[ ]-U[ ]) . Form_SelectElementos
<<forward>>
Select+OK
Usuario[ ]
createUsuario(Usuario)
U : Dominio .
<<create>> UsuarioAplicacion
Set(id,
NombreCompleto,
NombreSesion, Tipo)
Figura 6.59 Diagrama de Secuencia. Agregar Usuarios
111
BORRAR USUARIO
. Form_GestionUsuarios Dao . UsuariosAplicacionDAO
mostrar(U[ ]) . Form_SelectElementos
<<forward>>
Select+OK
Usuario[ ]
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 cuestin.
Gestin de Usuarios:
Como se ha visto en el apartado 5.1 diseo de la arquitectura, en la seccin Servidor de

la aplicacin, el directorio ControlClientes posee un subdirectorio que servir de
repositorio de versiones del programa agente para las mquinas cliente. Se deber
establecer un parmetro en el sistema que indique la ltima versin disponible para los
agentes e, igualmente, establecer un parmetro en los agentes que indique su versin.
Cuando se verifique que un programa agente tiene una versin anticuada, ste,
proceder a descargarse la ltima versin del directorio en cuestin. Por tanto, hay dos
parmetros a configurar, la ltima versin disponible y la ruta del repositorio de
versiones. Dichos parmetros se crearn en la tabla de settings de la aplicacin, y su
acceso se ha explicado en las figuras 6.52 y 6.53. Se podrn gestionar desde la
siguiente ventana:
Figura 6.61 Diseo de Interfaz. Gestin de Versiones

112
6.1.2 Subsistema EvoAgentService e Interaccin con el Servidor

En este apartado se expone la funcionalidad del subsistema EvoAgent y como interacta con
el servidor de la aplicacin.
El subsistema EvoAgent se compone de dos mdulos, el primero contiene el servicio de

Windows, EvoAgentService, que abarca toda la funcionalidad de la herramienta de
monitorizacin 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 mquina cliente puede acceder a la
informacin sobre la aplicacin y al programa de control remoto.
6.1.2.1 Instalacin del subsistema
Primeramente, se muestra el proceso que se sigue al realizar la instalacin del Subsistema

completo en la mquina cliente:
INICIO
Instalacin
Componentes de
la aplicacion
Escritura Clave de
registro de arranque
del programa
EvoAgentIcon
Ejecucin XML
auditora vista Auditora
general
Registro y
Obtencin de
Clave
IdMaquina
Escritura Clave
de registro
IdMaquina
FIN
Figura 6.62 Diagrama de Flujo. Instalacin
113
1. Instalacin de Componentes de la aplicacin: Al instalar la aplicacin

completa se crear una carpeta para la aplicacin en la direccin
%PROGRAMFILES%\Evotec\EvoAgentSETUP dnde se ubicarn los
programas EvoAgent y EvoAgentIcon, sus ficheros de configuracin
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

mdulo EvoAgentIcon precisa de un mtodo 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 mquina que inicie dicha aplicacin al
arrancar la mquina.
3. Ejecucin auditora vista general: Para la ejecucin de la auditora es

necesario ejecutar la aplicacin WinAudit mediante el uso de la herramienta
de lnea de comandos pasndole los argumentos necesarios. Tras la
ejecucin se genera un archivo XML con el resultado de la auditora que en
este caso es un informe que lleva la vista general de la mquina: nombre del
host, dominio, usuario, etc. Esta accin se puede ver con ms detalle en el
punto Tarea Diaria del apartado 6.1.2.2 Mdulo EvoAgentService, en la figura
6.72.
4. Registro y Obtencin de Clave IdMaquina: El documento XML generado es el

que se debe enviar al servidor para proceder al registro de la mquina, tal y
como se indica en el siguiente diagrama de secuencia:
114
ALTA MQUINA CLIENTE

EvoAgentServer . services
EvoAgentInstaller Dao . DominioDAO Dao . MaquinaDAO
. ControlClientes
AltaMaquinaCliente(DataSet)
existeDominio(nombreD) D:Dominio
<<create>>
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 Mquina 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
6.1.2.2 Mdulo EvoAgentService

INICIO
Inicio
NO
Temporizador
Vencimiento Temporizador Errores
Hay Comprueba
Permiso Permiso ERROR DE Registro de
CONEXIN Error en Local
SI
Pregunta Versin
del Cliente
Instalador
Versin
Instalada
Versin del Cliente != Obtener Nueva Instalar Nueva
SI
Versin Instalada Version Versin
NO NO Errores
Envo de
Lee Errores Hay Errores o
SI Errores y
Registrados Acciones
Acciones
NO
Comprobar Ejecutar Obtener Tipo Agente =

SI
Tarea Diaria Tarea Diaria Agente Servidor
NO SI NO
Ejecutar Tarea Ejecutar Tarea

Solicitud de Diaria Servidor Diaria PC
Tareas
Registro
Hay Tareas SI
Tareas
Tareas
Tareas
Pendientes
Pendientes Errores
SI Registro de
Error en Local
Inicio
Temporizador 2
ERROR
Vencimiento Temporizador
Ejecutar Tarea Ok NO Registro Error
SI
Envo
Resultado
116
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 6.64. Cada elemento/proceso marcado en un color ms obscuro se trata de una
comunicacin con el servidor de la aplicacin de la que se desprende un diagrama de
secuencia. Cada comunicacin lleva como argumento el identificador de la mquina que
obtiene el agente en el momento de la instalacin.
A continuacin se explicarn cada uno de los pasos del proceso:
INICIO: Un servicio Windows automtico es iniciado por el sistema operativo al

arramcar la mquina. Al iniciar el servicio se establecern en una clase habilitada para
el efecto, ConfigAgente, los parmetros del agente como el directorio de trabajo, el
identificador de la mquina y la ruta de acceso al servicio Web ControlClientes del
servidor.
Inicio Temporizador: Tras establecer los parmetros se arranca un temporizador, que

corresponde a la clase System.Timers.Timer. Se ha diseado 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 6.64.
Comprobar Permiso: Cuando vence el temporizador la primera accin es comprobar si

existe comunicacin con el servidor y si la mquina tiene permiso para acceder a sus
servicios.
PROBAR CONEXIN Y PERMISO
EvoAgentService . EvoAgentService .
EvoAgentService
ComunicacionServidor ConfigAgente
comprobarPermiso()
getIdMaquina()
IdMaquina
getWebService() . ControlCliente
getInstance()
ControlClientes Dao . MaquinasDAO
comprobarPermiso(idMaquina)
ValidaMaquina(idMaquina)
OK
OK
Figura 6.65 Diagrama de Secuencia. Comprobar Permiso
117
Una vez que se ha comprobado que el agente tiene permiso para acceder al sistema y
que la comunicacin es correcta, se puede proceder con el resto de acciones.
Comprobar Versin del Cliente: Tras comprobar la comunicacin y el permiso hay que
comprobar que la versin del agente instalado en la mquina es la correcta para que
no haya errores en la comunicacin y sepa interpretar los mandatos obtenidos.
Para ello, se establece un atributo en el programa agente que indica su versin. Dicho
argumento ser enviado en la comunicacin para que sea el servidor el que
compruebe si es correcto comparndolo con el parmetro del sistema existente Tal y
como se ha visto en el apartado 6.1.1.6 Mdulo Settings, existe un setting del sistema
que indica la ltima versin de los programas agente existente. El proceso seguido se
indica en el siguiente diagrama de secuencia:
EvoAgentService ComunicacionServidor ConfigAgente
getVersionCliente()
getIdMaquina() COMPROBAR VERSIN DEL CLIENTE
IdMaquina
getVersion()
Version
getWebService() . ControlClientes
getInstance()
ControlClientes Dao . MaquinasDAO Dao . SettingsDAO
CompruebaVersion(idMaquina, Version)
validaMaquina(idMaquina)
ok
getVersionCliente()
versin
bool OK
bool OK
Figura 6.66 Diagrama de Secuencia. Comprobar versin del Cliente
Obtener Nueva Versin: Si se ha comprobado que la versin instalada es la ltima

disponible se proceder con el resto de acciones. Si la versin existente es diferente a
la versin del agente, ste deber solicitar una ruta de donde descargarse la ltima
versin. Tras obtener la ruta el agente establece un httpwebresponse asociado a un
118
httwebrequest con la ruta obtenida. El httpwebresponse tendr un stream de bytes

asociado que contendr el archivo descargado, dicho archivo ser un archivo de
instalacin de Windows Instaler (.msi). Tras realizar la lectura de bytes, se crear el
archivo en el directorio de trabajo de la aplicacin y se proceder con la instalacin.
Este proceso se espone en el siguiente diagrama de secuencia:
OBTIENE NUEVA VERSION
getRutaRepositorio()
getIdMaquina()
IdMaquina
getWebService() . ControlClientes
getInstance()
ControlClientes Dao . MaquinasDAO Dao . SettingsDAO
getRutaRepositorio(idMaquina)
ok
getRutaRepositorio()
Ruta
Ruta
Ruta EvoAgentServer
HttpWebRequest(Ruta)
NuevaVersion.msi
Figura 6.67 Diagrama de Secuencia. Obtener Nueva Versin
Instalar Nueva Versin: Para instalar la nueva versin 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 instalacin. Si encuentra que existe un programa
con el mismo cdigo identificador de programa y misma versin o superior generar un
error y no continuar con la instalacin. Si la versin es anterior, proceder a
desinstalar la versin anterior e instalar la nueva. Si la versin anterior cuenta con un
programa que est ejecutndose, parar el programa (en este caso el servicio de
windows) e intentar reiniciarlo tras la instalacin de la nueva versin.
119
Lee Errores registrados y Registro de Error en Local: Tras comprobar la versin se

proceder a leer el log local del agente por si existiese entradas que no se han
comunicado al servidor. El agente estar diseado para llevar un log de acciones y
errores que ir transmitiendo al servidor para que ste lo almacene. Si, en alguna
ocasin, no puediera transmitir, el agente almacenara los eventos en un log local. Al
volver a tener comunicacin con el servidor, enviara la informacin que estuviera
pendiente en local. Para la gestin del log local se crear una clase especfica,
LogAgente que tenga los mtodos para registrar y obtener tanto acciones como
errores. A continuacin 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) idError : System. Xml
<<create>> . XmlNode
Set(InnerText = error.idError)
Fecha : System. Xml .
<<create>> XmlNode
Set(InnerText = error.fecha)
Error : System. Xml .
<<create>> XmlNode
AppendChild(idError)
AppendChild(Fecha)
get(ChildNode[0])
Errores : System. Xml
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 almacenarn en un fichero tipo .xml con una rama para los errores y otra para las
acciones. En los errores, al tratarse la descripcin 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, anlogamente al tratamiento de los mismos en el
120
servidor. Por lo tanto el registro de una accin ser similar, obviando la creacin 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 Log : System. Xml .
XmlDocument
Load(workingDirectory LECTURA DE ERRORES EN LOCAL
+ log.xml)
Get(ChildNode)
Errores : System. Xml
Errores
getChild()[i]
<<create>> XmlNode
Error
getChild()[0].InnerText
idError : System. Xml
idError
getChild()[1].InnerText
Fecha : System. Xml .
<<create>> XmlNode
Fecha
'idError' : System. IO
<<create(workingDirectory + idError)>> . File
ReadToEnd()
descripcion
Delete()
error : Dominio .
<<create>> ErrorAplicacion
Set(idError, fecha, descripcion)
RemoveAll()
<<delete>> XmlNode
Save(workingDirectory
+ log.xml)
Figura 6.69 Diagrama de Secuencia. Lectura de Error en Local

121
ste mtodo 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 descripcin, 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 . EvoAgentService . EvoAgentService .

ComunicacionServidor ConfigAgente LogAgente
getIdMaquina() COPIA DE ERRORES
IdMaquina
getWorkingDirectory() . ControlCliente
WorkingDirectory
getWebService()
getInstance()
ControlClientes
getErrores(WorkingDirectory)
Lectura de Errores
Error[ ] en Local Dao . MaquinaDAO Dao . ErrorAplicacionDAO
registraError(idMaquina, idError, fecha, descripcion)
ok
getMaquina(idMaquina)
M:Maquina
<<create>>
E:Dominio . ErrorAplicacion
<<create>>
setE(idError,fecha, Tipo ,descripcion,

idMaquina,idCliente)
registroError(Error)
registroError
Figura 6.70 Diagrama de Secuencia. Copia de errores
122
Como se puede ver, hace uso del proceso anteriormente visto en la figura 6.69 al leer
los errores de local y tambin utiliza un proceso llamado registro Error hubicado en la
capa de datos de la librera. 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 sern configurados
para realizar una tarea todos los das. En el servidor de la aplicacin existir un campo
junto con la informacin de los agentes que indique la ltima ejecucin de la tarea
diaria de cada uno de ellos. As, en cada intervalo, se comprobar si la ltima
ejecucin es la de hoy de forma que slo se ejecutar en el primer intervalo del da. La
primera accin, es comprobar si se debe ejecutar la tarea diaria:
COMPROBAR TAREA DIARIA
EvoAgentService
comprobarTareaDiaria()
getIdMaquina()
IdMaquina
getInstance()
comprobarTareaDiaria(idMaquina)
OK
getTareaDiaria(idMaquina)
OK
OK
OK
Figura 6.71 Diagrama de Secuencia. Comprobar Tarea Diaria
Como se puede apreciar el proceso es idntico al proceso de comprobar permiso visto

en la figura 6.65, interviniendo las mismas clases. Esto es debido a que tanto el
parmetro permiso como el parmetro tarea diaria son atributos de un mismo agente y
se acceden a ellos a travs de la clase MaquinaDAO del nivel de datos.
123
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 idntico al de la figura 6.71 y,
consecuentemente, al de la figura 6.65 slo 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 funcin del tipo.
En cualquier caso se ejecuta una auditora. La ejecucin de una auditora sigue el
siguiente diagrama de flujo:
INICIO
Creacin archivo .bat con

los campos a auditar ms
otros argumentos
Ejecucin del Ejecucin

archivo .bat WinAudit
NO
Fin XML
Ejecucin? Auditora
SI
Lectura
Auditora
Lectura de la
clave de
mquina del
registro
Envo de la
Auditora
FIN
Figura 6.72 Diagrama de Flujo. Ejecucin Auditora
Al terminar la ejecucin se procede a enviar el resultado de la auditora al servidor.

Esto provoca en el servidor un estudio de la auditora recibida para la posible
generacin de alertas y su almacenamiento para posteriores consultas tal y como se
indica en el siguiente diagrama de secuencia:
124
EvoAgentService . EvoAgentService . EvoAgentService .

ControlTareas
REGISTRO AUDITORA
getSeleccion(idTarea)
SeleccionAuditoria
. ControlCliente
registraAuditora(SeleccionAuditoria, xml.Auditora)
getIdMaquina()
EvoAgentLibrary . Dao
IdMaquina . DetalleAuditoriaDAO
getWebService()
getInstance()
ControlClientes
Dao . MaquinaDAO
registroAuditoria(idMaquina,
seleccionAudit, DataSet) validaMaquina(idMaquina)
ok
nuevaAuditoria(idMaquina,
seleccion, ds,
workingDirectory)
(*1) Contina
Figura 6.73 Diagrama de Secuencia. Registro Auditora I
El servicio, a traves de la clase comunicacin, enva, junto con la seleccin impuesta a

la auditora, el dataSet que contiene el documento xml (En el paso lectura auditoria se
hace DataSet.ReadXml(ruta)), y el identificador de la mquina. El servidor valida la
mquina y, si tiene permiso, enva la auditora al nivel de datos para que la almacene.
Hasta aqu llega el diagrama de secuencia de la figura 6.73. En la figura 6.74 se ve
como el nivel de datos obtiene la informacin de las auditoras registradas para la
mquina. Si en dichas auditorias el contenido auditado est contenido en la auditora
recibida (se ve por el campo seleccin) sern eliminadas. La informacin de la nueva
auditora 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 auditora se procede a realizar el control de la misma para
la generacin de alertas a traves de la clase ControlNuevaAuditora de la librera.
Si todo va bien, al terminar el control se enva un correcto al Servicio para que siga su
trabajo.
125
EvoAgentLibrary . Dao REGISTRO AUDITORIA

. DetalleAuditoriaDAO (*1) Continuacin
EvoAgentLibrary . Dao
. DetalleAuditoriaDAO
getAuditorias D : Dominio.DetalleAuditoria
(idMaquina) <<create>>
D[ ]
[seleccion.Contains
(D[].seleccion)] D : Dominio.DetalleAuditoria
Delete <<delete>>
(D.idAuditoria)
AU : System.IO.File
Delete(workingDirectory
+ D.idAuditoria)
D : Dominio.DetalleAuditoria
<<create>>
setD(idAuditora,idMaquina, Ds: System.Data.DataSet

seleccion,fecha)
writeXML(workingDirectory+idAuditoria)
EvoAgentServer . services EvoAgentLibrary . services

EvoAgentService . ControlCliente . ControlNuevaAuditoria
ControlAuditoria(idMaquina, Ds,
EvoAgentService . idAuditoria, workingDirectory)
ComunicacionServidor <<forward>> Control Auditoria
OK
OK
Figura 6.74 Diagrama de Secuencia. Registro Auditora II
El mtodo Control Auditora de la clase ControlNuevaAuditora que sirve para la

generacin de alertas en el sistema CRM de Microsoft se ve a continuacin. Se debe
interpretar la salida xml del programa winaudit para obtener la informacin de los
elementos relevantes para la generacin de alertas. Se ha diseado un filtro que se
debe obtener para controlar la generacin de las mismas. Adems de ese filtro general
por elemeto generador, cada uno tendr un filtro especfico.
126
CONTROL AUDITORIA
EvoAgentLibrary . services EvoAgentLibrary . services
. ControlNuevaAuditoria . LeerAuditoriaXML
Dao . MaquinaDAO
M : Dominio.Maquina
<<create>>
M Dao . SettingsDAO
getElementosGeneradores(M.tipoAgente)
ElementoGeneradorActivo[ ]
LeerAuditoria(workingDirectory+idAuditoria, dataSet)
LeerAuditoria
CamposAuditoria
EvoAgentLibrary . services
. ControlNuevaAuditoria
ControlProgramas(CamposAuditoria.Programas,
bool ElementoActivo, M, workingDirectory)
control Programas
<<forward>>
ControlDiscos(CamposAuditoria.DiscosLogicos
,bool ElementoActivo, M, workingDirectory)
control Discos
<<forward>>
ControlMemoria(CamposAuditoria.Memoria
control Memoria
<<forward>>
ControlServicios(CamposAuditoria.Servicios
control Servicios
<<forward>>
ControlErrores(CamposAuditoria.Errores
control Errores
<<forward>>
Figura 6.75 Diagrama de Secuencia. Control Auditora
El mtodo Leer Auditora al que se hace referencia en el diagrama de secuencia se

corresponde con el mismo mtodo utilizado para leer las auditoras a la hora de
mostrar el detalle de las mquinas en la aplicacin de gestin. Se puede ver en el
127
apartado 6.1.1.3 Maquinas en Ver Detalle Maquina. Devuelve la estructura

CamposAuditora de la que interesa los campos Programas, Discos, Memoria,
Servicios y Errores, que son los que se van a controlar para la generacin de alertas.
Se requiere esa informacin adems del filtro de generacin 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 mtodo para gestionar cuando generar alertas.
Control Programas: Se debe verificar que los programas que se reciben en

la auditora no estn registrados en el sistema, en cuyo caso sera un
programa nuevo.
128
EvoAgentLibrary . services CONTROL PROGRAMAS

Dao . ProgramaDAO
getProgramas(idMaquina)
<<create>>Maquina_Programa
P[ ]
Dao . ProgramaDAO
NewPrograma
(CamposAuditoria.Programas[ ] - P[ ])
Dao . SettingsDAO
getFiltroProgramas()
string[] filtros
Dao.AlertaDAO
[!NuevoPrograma.Contains(Filtros)]
NewAlerta(Tipo, M,
Alta Programa..., rutaServidor) registroAlerta
Dao . ProgramaDAO
DeleteDesinstalados(P[ ] Maquina_Programa
<<delete>>
- CamposAuditoria
.Programas[ ] )
Dao.AlertaDAO
[!ProgramaDesinstalado
.Contains(Filtros)] NewAlerta
(Tipo, M, Baja Programa..., registroAlerta
rutaServidor)
Figura 6.76 Diagrama de Secuencia. Control Programas
Se debe obtener los filtros especficos de generacin de alertas de

programas registrados y compararlos con los nuevos programas. Un
programa nuevo, que no contenga en su nombre uno de los filtros, generara
una alerta (Ver Filtro de programas en Gestin de alertas en el apartado
6.1.1.6 Mdulo Settings). La generacin de alertas se realiza mediante la
llamada al servicio web del CRM tal y como se explica en el apartado 6.1.3.3
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 auditora para
129
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 generacin de alertas.
Control Discos: Para la generacin de alertas de ocupacin de disco duro

existe un filtro que indica el mximo porcentaje de ocupacin de disco a
partir del cual se registrara una alerta.
EvoAgentLibrary . services 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 mquina sigue un proceso similar

a los discos para la generacin de alertas:
130
EvoAgentLibrary . services CONTROL MEMORIA

Dao . SettingsDAO
getMnimoMemoriaLibre()
procentaje
Dao.AlertaDAO
[Memoria.PorcentajeLibre>Mnimo]
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 automtico no est iniciado. Se
debe obtener los filtros especficos de generacin de alertas de servicios y
compararlos con los obtenidos. Un servicio automtico, que coincida con
uno de los filtros, y ste este desactivado, no generara una alerta (Ver
Filtro de Servicios en Gestin de alertas en el apartado 6.1.1.6 Mdulo
Settings) El sistema alimenta automticamente los servicios registrados
cada vez que descubre un servicio nuevo.
EvoAgentLibrary . services 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
Figura 6.79 Diagrama de Secuencia. Control Servicio
Control Errores: Todo error del log de windows generara una alerta a no
ser que tuviera un filtro asociado y desactivado (Ver Filtro de Errores en
Gestin de alertas en el apartado 6.1.1.6 Mdulo 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 CONTROL ERRORES

Dao . ErrorMaquinaDAO
getErrores(idMaquina)
E : Dominio.WinAudit.
<<create>> Maquina_Error
E[ ]
Dao . ErrorMaquinaDAO
NewError
(CamposAuditoria.Errores[ ] E[ ])
Dao . SettingsDAO
getFiltroErrores(NewError.idInstance, M.TipoAgente)
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 auditora y generadas las alertas oportunas el servicio contina
con la tarea diaria.
En funcin 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 desfragmentacin de los discos duros si se ha activado la propiedad en la
especificacin de la mquina (Ver Modificar las propiedades de un programa agente en
132
el apartado 6.1.1.3 Mquinas). Para realizar la desfragmentacin 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 diseado dos tareas: la comprobacin de la
correcta ejecucin 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 utilizarn
comandos publicados por Microsoft para la gestin del controlador de dominio como el
comando dsquery user con los parmetros inactive y otros (Ver la documentacin en
http://technet2.microsoft.com/windowsserver/en/library/46ba1426-43fd-4985-b429-
cd53d3046f011033.mspx?mfr=true). Otra tarea declarada como tarea programable es la
comprobacin de cuotas. Se puede ver como crear la tarea en el apartado 6.1.1.2
Tareas, en Nueva Tarea, y en que consiste y como se ha diseado en el punto Ejecutar
Tarea ms abajo. Para la comprobacin de tareas programadas se utilizar la librera
comentada en el apartado 2.6.4 Windows Task Scheduler.
Una vez terminada la tarea diaria se comunica al servidor para que actualice el
parmetro.
Solicitud de Tareas: El siguiente paso en el proceso es la peticin de tareas

pendientes al servidor. Adems 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
EvoAgentService
getNumTareas()
getIdMaquina() SOLICITAR TAREAS
IdMaquina
getInstance()
ControlClientes EvoAgentServer . dao
. MaquinasDAO
getNumTareas(idMaquina)
EvoAgentServer . dao
ValidaMaquina(idMaquina) . TareaMaquinaDAO
OK
getNumTareas(idMaquina)
numeroTareas
numeroTareas
numeroTareas
getTareas(numTareas)
getIdMaquina()
IdMaquina
getWebService()
getInstance()
ControlClientes
getTareas(idMaquina)
OK
getTareas(idMaquina)
EvoAgentServer . dao
<<create>>. TareaMaquinaDAO
EvoAgentService .
ControlTareas
TareaMaquina[ ]
String Tarea[ ]
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 ejecucin de las tareas depende de la tarea
que se vaya a ejecutar:
134
Auditora: 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 comunicndolo al usuario.
Limpieza: Ejecuta el programa CCLeaner por lnea de comandos.
Inicio de Servicio: Mediante la clase ServiceController intenta inicial el

servicio con el nombre que ha recibido como parmetro.
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 mtodo
FileInfo.Length calcula el tamao 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
tamaos de cuota.
Desfragmentar: Tambin se puede ejecutar como parte de la tarea

diaria. Se utiliza el comando dfrag como se ha explicado.
Envo Resultado: Si la tarea termina correctamente se envia al servidor para que se

registre.
135
ENVO RESULTADO
ResultadoTareaMaquina( getIdMaquina()
idTarea,fecha,resultado)
IdMaquina
getInstance()
resultadoTarea(idMaquina, idTarea, resultado)
Dao . TareaMaquinaDAO
ok
setTareaRealizada(idTarea)
T:TareaMaquina
<<create>>
setT(realizada)
Figura 6.82 Diagrama de Secuencia. Envo Resultado
Envo de Error: Si se produce un error en alguna de las acciones descritas hasta

ahora, dicho error se intentara registrar en el servidor. Si no se pudiera registrar en el
servidor se guardara en local como se ha visto en el punto Lectura de errores y
registro de error en local.
136
getIdMaquina() ENVIO DE ERROR

IdMaquina
getInstance()
ControlClientes Dao . MaquinaDAO Dao . ErrorAplicacionDAO
[error]
RegistraError(idMaquina, idError
fecha, descripcion) validaMaquina(idMaquina)
getWorkingDirectory() ok
WorkingDirectory
M:Maquina
EvoAgentService .
LogAgente <<create>>
RegistraError
(WorkingDirectory
,Error) registroError M
en Local E:Dominio . ErrorAplicacion
<<create>>
setE(idError,fecha, Tipo ,descripcion,

idMaquina,idCliente)
registroError(Error)
registroError
Figura 6.83 Diagrama de Secuencia. Envo Error
El proceso de registro de error en el servidor se ha descrito ya en el apartado 6.1.1.5

Logs en la figura 6.48.
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
6.1.2.3 Mdulo EvoAgentIcon
Este mdulo 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
aplicacin y, a su vez, permitir desplegar un men desde el que acceder a la funcionalidad
del mdulo que consiste en el acceso al programa de conexin remota y a la informacin de
la aplicacin.
ICONO EN BARRA DE TAREAS
Figura 6.84 Diseo de Interfaz. EvoAgentIcon. Icono de la Barra de Tareas
El icono se carga al arrancar la mquina gracias a la entrada en el registro de arranque de la

mquina que se incluye en el proceso de instalacin del subsistema. Se arrancar con las
credenciales que utiliza el usuario de Windows. Pulsando sobre el icono aparece el men:
MOSTRAR INFORMACIN DE
LA APLICACIN
LANZAR CLIENTE DE CONTROL REMOTO DE EVOTEC
138
Figura 6.85 Diseo de Interfaz. Men de EvoAgentIcon en la barra de Tareas
Al pulsar Acerca de se mostrar la siguiente ventana de informacin de la aplicacin:
LANZAR CLIENTE DE CONTROL REMOTO DE EVOTEC
Figura 6.86 Diseo de Interfaz. Informacin de la Aplicacin
Desde esta ventana se podr acceder tambin 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 aplicacin de software libre
que permite crearse un sistema de acceso a mquinas cliente para supervisin en tiempo de
ejecucin, es decir, cuando el usuario de la mquina arranque el programa e introduzca el id
de sesin del tcnico se obtendr acceso al mismo sin necesidad de iniciar sesin de forma
remota con el terminal server.
139
6.1.3 Sistema Externo Microsoft Dynamics CRM

En este apartado se mostrar como se realizar la integracin con el CRM. En concreto se
tratan los siguientes aspectos:
6.1.3.1 Interaccin con la interfaz del CRM para generar la entidad Alerta.
6.1.3.2 Acceso a la base de datos.
6.1.3.3 Acceso al servicio CRMService para registrar nuevas alertas.
6.1.3.4 Interaccin con la interfaz del CRM para trabajar con las alertas
generadas por el sistema.
6.1.3.1 Interaccin 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
necesitarn y los formularios o interfaz por donde se mostrarn. Microsoft CRM permite crear
y personalizar entidades:
Figura 6.88 Microsoft CRM. Personalizacin de Entidades
140
Para cada entidad se pueden configurar cuatro apartados tal y como se muestra en la figura
6.78:
La informacin de la entidad permite darle un nombre con el que se podr identificar

desde el mdulo cliente de programacin. 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. Personalizacin Entidad Alerta
Los atributos son los campos que tiene la entidad. Se puede especificar el nombre, el tipo
de dato, formato
141
Figura 6.90 Microsoft CRM. Personalizacin 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 mostrarn 2 interfaces. El primero servir de vista
general de todas las alertas y el segundo servir de formulario donde recoger la
informacin de cada una.
Figura 6.91 Microsoft CRM. Personalizacin de Vista General para la Entidad Alerta
142
Figura 6.92 Microsoft CRM. Personalizacin del Formulario para la Entidad Alerta
Las relaciones permiten asociar entidades entre s. En este proyecto adems de crear
alertas se debern poder asociar a casos para tratarlas por lo que ser necesario asociar
las alertas a los casos:
143
Figura 6.93 Microsoft CRM. Personalizacin de la relacin 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
informacin de las alertas. Asimismo, aade la entidad junto con sus atributos al namespace
que se obtiene del Servicio Web CRMService mediante el cual se podr programar la
creacin de alertas como se muestra en el diagrama de secuencia Registro de Auditoria
(Figura 6.72).
6.1.3.2 Acceso a la Base de Datos

Si bien se puede obtener datos de la aplicacin CRM a travs 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
aplicacin CRM.
Por tanto, ste procedimiento tan slo se utilizara para obtener datos del sistema CRM, en
concreto se debe obtener dos objetos de datos: Usuarios y Clientes, y slo 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 ms detalle en el Apartado 6.2.4 Acceso a datos. Se requerir una cadena de
conexin con la base de datos del CRM con un usuario y contrasea vlidos para poder
acceder va autenticacin SQL.
El DataSet contendr dos tablas con los campos que se requieran y dos adaptadores.
Dichos componentes pasarn a formar parte del nivel de datos.
6.1.3.3 Acceso al servicio CRMService para registrar nuevas alertas

Como se ha explicado en otros apartados, la aplicacin CRM posee un servicio Web que se
puede utilizar para obtener o registrar informacin en el sistema CRM sin utilizar la interfaz
pero accediendo a dicha informacin 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 2.6.1 Introduccin al CRM de Microsoft de este documento y en la documentacin
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 vlida.
El servicio CRMService tiene varios mtodos de los que se va a utilizar el mtodo execute.
Dicho mtodo requiere un argumento que puede ser entendido como una llamada y que
recibe el nombre genrico 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 -lase create, retrieve, update, delete-.
144
Este argumento llamada a su vez tiene un atributo que viene a ser el objeto de la llamada y
que se denomina genricamente target. El target posee un atributo que vara en funcin 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. Ms 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 generaran las clases TargetCreateAlerta,
TargetRerieveAlerta.
Como conclusin, 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 vlida y
ejecutar el mtodo Execute pasndo como argumento el request. El resultado se obtiene en
forma de CreateResponse. Todo esto se detalla en el siguiente diagrama de secuencia:
145
Dao.AlertaDAO
al : Dominio . CRM . REGISTRO ALERTA
<<create>> new_Alerta
Set(Tipo,
NombreMaquina,
UsuarioPropietario,
target: Dominio . CRM
Desc., Cliente)
<<create>> . TargetCreateAlerta
Set(al)
request : Dominio . CRM

<<create>> . CreateRequest
Set(target)
cre : System . Net .

<<create>> NetworkCredentials
set(User, Pw, Domain)
service : Dominio . CRM

<<create>> . CRMService
setCredentials(cre)
Execute(request)
<<forward>>
[error]
err : Dominio.ErrorAplicacion
<<create>>
Dao . ErrorAplicacionDAO
Set(id, fecha, tipo,maquina,
cliente, descripcion)
registroError(Error, rutaServidor)
registroError
<<forward>>
Figura 6.94 Diagrama de Secuencia. Registro de Alerta.
En el diagrama de secuencia de la figura se ha tenido en cuenta la gestin de errores

generados por la aplicacin. La mayora 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
modificacin de los permisos de acceso de un directorio virtual o por la prdida momentnea
de la red. Todos estos errores son tratados por el sistema para ofrecer una visualizacin de
los mismos al usuario gestor del sistema. Se ha hecho una referencia al mtodo registroError
(en rojo) que se ha mostrado en el Apartado 6.1.1.5 Log de la aplicacin, en la Figura 6.48.
146
6.1.3.4 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 Diseo de Interfaz. Microsoft CRM. Alertas
Desde ah se podrn realizar las siguientes acciones:
Desechar Alertas
Con la informacin disponible se puede optar por desechar el evento como alerta y
eliminarlo. Para ello se pude seleccionar las alertas a eliminar y pulsar el botn con un aspa.
Se pedir confirmacin.
Asignar Alertas
Aunque, como se ha visto en el mdulo 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 permitira poder poner un usuario genrico como el propietario de las alertas
y desde ste asignarlas a quien corresponda.
147
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 opcin
Acciones y Asignar:
Figura 6.96 Diseo de Interfaz. Microsoft CRM. Asignar Alerta I
Aparecer la figura 6.85. Si se desease asignar a otro usuario se podr seleccionar la opcin
y pulsar sobre la lupa que aparece al final del recuadro:
Figura 6.97 Diseo de Interfaz. Microsoft CRM. Asignar Alerta II
Aparecera otra ventana con los posibles usuarios donde se podr seleccionar el usuario
deseado.
148
Figura 6.98 Diseo 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 revisin. Se pueden acceder a ellos a travs 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 integracin con dicha aplicacin. 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 opcin Servicios y

dentro de Servicios Casos. Haciendo clic sobre ste ltimo se acceder a los casos
relacionados con la alerta y se podrn crear nuevos:
149
Al crear el nuevo caso, ste llevar asociado una alerta en el apartado Alerta.
A partir de aqu se puede trabajar con el caso como un caso ms, asignarlo a un usuario y
resolverlo.
150
6.2 Modelo de datos

El modelo de datos, tal y como se ha explicado en el apartado 3.1.3.4 Describir el modelo de
datos, se puede dividir en 3 apartados. Adems se estudiar el mtodo de programacin a
utilizar para acceder a los datos.
6.2.1 Diseo Conceptual de datos

El diseo conceptual de datos se realiza a partir del modelo de dominio, que unindolo a un
mejor conocimiento de los objetos del sistema tras el diseo externo e interno del mismo, se
obtiene el modelo Entidad-Relacin:
N 1 1 M
Alerta R Cliente R Dominio
C C N 1 1
R R R
N
N N R LogCliente
1
1
Maquina
1
R
1
1 1 1
N
R R R ErrorCliente
C
R
N
C
Tarea ErroresAplicacion
N N 1
Error R
C UsuarioAplicacion SettingsAplicacion
N
Programa R
CARDINALIDADES:
N
R R
1 1
R
R
M
0, 1 C
M 1, 2, 3, ... M
M MaqAuditoria 0, 1, 2, 3, ... N
C
Figura 6.101 Diagrama Entidad-Relacin
151
6.2.2 Diseo Lgico de datos

El modelo Entidad-Relacin nos da una idea de los datos con los que trabajar el sistema.
Sin embargo, es necesario pasar a un modelo lgico donde se pueda obtener los datos
normalizados. El modelo lgico sera el modelo RE/R, que se obtiene con una simple
conversin en los criterios de representacin a partir del modelo Entidad/Relacion. Adems,
se introduce los atributos de las tablas:
Alerta(-idAlerta- N R11 Cliente(-idCliente- R2 M

Dominio(-idDominio-,nombreDom)
,descripcion,tipoAlerta) ,Nombre)
C C N C C
R1
R3
R15 N LogCliente(-idAccion,
M N
dFecha-, dHora, sAccion)
R9 R16
Maquina(-idMaquina-,sNomHost)
N
ErrorCliente(-idError-, C
R4(dFecha, seleccion) dFechaError, sTipo,
N sDescipcion)
R19
N
R10 R8 ErroresAplicacion(-idError-,
dFechaError, sTipo, sDescipcion)
Tarea(-idTarea-
C ,nombreTarea)
R12
N Error(-idError- N R7
,sSource,dFecha,sDescripcion)
R5 UsuarioAplicacion(-
SettingsAplicacion(-idSetting-,
R6 idUsuario-, sNombreSesion,
sNombre, sValor)
sNombreCompleto)
Programa(-idPrograma- N
,sNombrePrograma,sVersion,dFechaInstal
C acion,sRuta) CARDINALIDADES:
N
1 1 (puede omitirse)
0, 1 c
M
1, 2, 3, ... m (puede omitirse) y flecha
R14 M 0, 1, 2, 3, ... n y flecha
MaqAuditoria(idAuditoria,
M
R13 dFechaAuditoria,sSeleccin) C
Figura 6.102 Conversin Entidad-Relacin a RE/R
El modelo obtenido debe pasar por las reglas de transformacin del modelo RE/R explicado
en el anexo 4.3 Metodologas As, el nuevo modelo de datos queda de la siguiente manera:
152
Cliente(-idCliente- Dominio(-idDominio-,nombreDom, -
,Nombre) idCliente-*)
N LogCliente(-idMaquina*, idAccion,
dFecha-, dHora, sAccion)
Maquina(-idMaquina-,sNomHost, -
idCliente-*,-idDominio-*)
N
N ErroresAplicacion(-idError-,
dFechaError, sTipo, sDescipcion, <-
AlertaError(-idAlerta-,descripcion,
N idMaquina->*)
tipoAlerta, -idMaquina-*, -idCliente-*,
<-idError-*>, <sSource>, <dFecha>,
sDescripcion> ) N
MaqTarea(-idMaquina*, SettingsAplicacion(-
idTarea*-, dFecha, seleccin, idSetting-, sNombre, sValor)
<-idAuditoria-*>)
N
AlertaPrograma(-idAlerta-,descripcion, N UsuarioAplicacion(-
tipoAlerta, -idMaquina-*, -idCliente-*, <- idUsuario-, sNombreSesion,
idPrograma-*>, <sNombrePrograma>, sNombreCompleto)
<sVersion>, <dFechaInstalacion>, N
<sRuta> )
N Tarea(-idTarea-
,nombreTarea)
ErrorAuditoria(-idMaquina*,
idTarea*-, dFecha, seleccin, -
idAuditoria-*, -idPrograma-*)
CARDINALIDADES:
N
0, 1 c
ProgramaAuditoria(-idMaquina*, 1, 2, 3, ... m (puede omitirse) y flecha
idTarea*-, dFecha, seleccin, - 0, 1, 2, 3, ... n y flecha
idAuditoria-*, -idError-*)
Figura 6.103 Diagrama RE/R
6.2.3 Diseo Fsico de datos

El ltimo modelo de datos est normalizado lo que no implica mejores prestaciones. A partir
de un anlisis 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 mquinas sera apropiado poseer el nombre del cliente propietario de la mquina
adems de su identificador inferido por la normalizacin.
Por otro lado, tambin resulta conveniente modificar las propiedades de algunos atributos de
forma que estos puedan admitir valores nulos. Por ejemplo, como se ha visto en el diseo
interno, el subsistema EvoAgent registra mquinas sin conocer el cliente, tan slo 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 mquina sin cliente y
153
asociarlo despus mediante el mdulo Clientes del subsistema EvoAgentManager. Por tanto,
sera necesario permitir que el valor del cliente en la tabla de mquinas admitiese nulos.
Tambin hay tablas que son necesarias por la lgica del programa, como las tablas de
errores y programas de las mquinas para poder comprobar si hay nuevos programas
instalados, que pueden reemplazar a las tablas ProgramaAuditora y ErrorAuditora y las
tablas de Settings de la aplicacin, elementos generadores y filtros de generacin de alertas.
Por otro lado, conviene separar las tareas de las auditoras, ya que stas ltimas hacen
referencia al resultado de la tarea auditora 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
Cliente(-idCliente- N Dominio(-idDominio-,nombreDom,
,Nombre) <-idCliente->*, <sRazon>)
LogCliente(-idMaquina*, idAccion,
dFecha-, dHora, sAccion, <-
N idCliente->*)
ErroresAplicacion(-idError-,
N
N N dFechaError, sTipo, sDescipcion, <-
idMaquina->*, <-idCliente->*)
Maquina(-idMaquina-,sNomHost, <-
idDom->*, sNomDom, <-idCli->*,
<sRazon>)
SettingsAplicacion(-idSetting-,
sNombre, sValor)
N
FiltroAlertaPrograma(-sFiltro-)
MaqTarea(-idMaquina*,
idTarea*-, dFecha, UsuarioAplicacion(-idUsuario-,
sNombreTarea, sSeleccin) sNombreSesion, sNombreCompleto)
MaqPrograma(-idMaquina*,
idPrograma- N N
,sNombrePrograma,sVersion,dFech ElementoGenerador(-sElemento-,
aInstalacion,sRuta) ActivoPC, ActivoServidor)
Tarea(-idTarea-
,nombreTarea)
FiltroAlertaServicio(-
MaqError(-idMaquina*, idError-, N sNombreServicio-, bActivoPC,
sTipo, sSource, dFecha, bActivoServidor)
sDescripcion)
N
CARDINALIDADES:
FiltroAlertaError( -idError-, MaqAuditoria(-idAuditoria-,-
sTipo, sSource, sDescripcion) idMaquina-*,
dFechaAuditoria,sSeleccin)
0, 1 c
0, 1, 2, 3, ... n y flecha
Figura 6.104 Modelo Fsico de Datos
La tabla de alertas quedar registrada en la base de datos del CRM conteniendo los campos
que se definan en la creacin de la entidad alerta ms los campos que introduzca el CRM.
Ir asociada a la tabla de clientes y de usuarios del CRM.
155
Alerta(-idAlerta-,descripcion,tipoAlerta, -
idMaquina-*, -idCliente-*, -idUsuario-*,
<sNombrePrograma>,<dFechaInstalacion>,
<sRuta>, <idError>, <sSource>, <dFecha>,
<sDescripcion>)
N N
CRMCliente(-idCliente-,...)
CRMUser(-idUsuario-,...)
Figura 6.105 Tabla Alertas del CRM
6.2.4 Acceso a los datos Capa de Datos-
6.2.4.1 Aspectos de Rendimiento

En un sistema que posea una base de datos con tablas de gran tamao (con infinidad de
registros), el rendimiento de la aplicacin puede verse seriamente afectado a la hora de
acceder a los datos. Una solucin 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
mltiples consultas sobre tablas con un filtro asociado (clusula WHERE en el lenguaje
SQL). Dicho filtro hace que slo las filas de una tabla que cumplan con el filtro deben ser
seleccionadas. Si se debe leer toda la tabla para tomar esta decisin (qu registros cumplen
la condicin) se est perdiendo rendimiento.
Los ndices permiten optimizar este proceso. Si se conocen los campos que actan de filtro
se podra acceder directamente a los datos que cumplen la condicin. Un ndice ocupa
espacio en disco y en memoria pero permite optimizar las bsquedas 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 travs del ndice
3. Evala el valor de bsqueda contra cada valor de clave y repite esta evaluacin
hasta una de las siguientes ocurrencias
El valor de bsqueda no es mayor o igual que el valor de clave
156
El valor de bsqueda es mayor o igual que el ltimo valor en la pgina de

ndice
Los ndices se generan en forma de listas enlazadas y poseen enlaces a las pginas de
datos:
Figura 6.106 ndices de acceso a datos
Para la creacin de ndices se debe tener en cuenta aquellos campos que sern
referenciados en las consultas. Por ejemplo, para la tabla T_MaqTarea que contiene las
tareas asignadas a las mquinas se realizarn consultas de tareas en funcin de la tarea, de
la mquina, 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
fcilmente por medio de la aplicacin gratuita SQL Server Management Studio Express:
157
Figura 6.107 Indices por tablas en SQL Server
Se puede ver que se han creado tres ndices adems del generado automticamente segn
la clave principal de la tabla. Un ndice para el campo cliente, otro para el campo tarea y otro
para el campo mquina. 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 mquina. Al realizar una consulta sobre esta tabla en
funcin de una tarea y un cliente, cabra 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
Figura 6.108 Configuracin de un ndice de acceso a datos por columnas
6.2.4.2 Aspectos de Programacin

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 introduccin de un usuario gestor de la
base de datos con una contrasea y, as, realizar la autenticacin va SQL authentication.
159
Figura 6.109 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 conexin estndar 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 conexin se construye una
conexin SQL Connection a dicho servidor.
Figura 6.110 Configuracin de una cadena de conexin a datos en Visual Studio.
La cadena de conexin se guardar con un nombre en la carpeta Settings de la aplicacin.

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
adaptador de datos propio. Los adaptadores poseen como propiedad la conexin de datos
mencionada anteriormente. Si en cualquier momento se modifica la cadena de conexin los
adaptadores asumen el cambio automticamente, as se obtienen un nico punto donde
modificar la ruta que utiliza el sistema para acceder a los datos.
Figura 6.111 Creacin de un DataSet en un proyecto de VisualStudio
161
Figura 6.112 Creacin de un DataAdapter en un DataSet de un proyecto de VisualStudio
En la creacin de un Adaptador de datos, tras seleccionar la conexin, 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
Figura 6.113 Objeto DataTableAdapter y DataTable
En la Figura 6.113 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 mtodo del segundo. Se pueden agregar
tantos mtodos como se quiera en un adaptador, cada uno conlleva una ejecucin de una
instruccin SQL contra el origen de datos indicado en la cadena de conexin.
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 rellenndolas de datos a partir de
una llamada a un mtodo del adaptador correspondiente.
Para la gestin del DataSet y los adaptadores se crearn clases pertenecientes a la capa de
datos, es decir, al paquete DAO de la librera de la aplicacin
163
6.3 Diagrama de Clases

A partir del Anlisis de requerimientos, el diseo externo del sistema y el diseo del modelo
de interaccin (diagramas de secuencia), se posee un amplio conocimiento de los objetos
del sistema a construir. As, por cada subsistema y paquete, se expone a continuacin el
diagrama de clases que lo compone:
6.3.1 Librera EvoAgentLibrary
Paquete Dominio
164
Figura 6.114 Diagrama de Clases. Paquete Dominio: Dominio, Cliente, Maquina
Figura 6.115 Diagrama de Clases. Paquete Dominio: DetalleAuditoria, Usuario, Tarea, TareaProgramada, ApplicationSetting,
AccionCliente
165
Figura 6.116 Diagrama de Clases. Paquete Dominio: ErrorAplicacion, TareaMaquina, MiTrigger
El paquete dominio comprende las clases de las figuras 6.114 y 6.115 y 6.116 adems de
todas las clases que importa de otros paquetes tal y como se vio en el diseo externo del
sistema. As se podran incluir las clases del paquete WinAudit o del paquete de
TareasProgramadas aunque en este ltimo caso existe una adaptacin de las clases Trigger
166
en la clase MiTrigger. Por ltimo cabra incluir tambin la clase Alerta del paquete CRM
Dinamics.
Paquete Services
167
Figura 6.117 Diagrama de Clases. Paquete EvoAgentLibrary.Services
En este paquete se incluyen clases que sirven de complemento para procesos del sistema
como puede ser el Intrprete de programacin de tareas que sirve de interfaz entre el
sistema y el sistema externo TaskSheduler; o el lector de auditoras que sirve de interfaz
entre el resultado del sistema externo winAudit y el sistema; o la clase Control Auditoria que
administra la generacin de alertas en el sistema externo CRM. sta ltima slo la utilizara
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 tcnico de Evotec
para entrar en la aplicacin de gestin. Dicha clase posee tambin el mtodo de
autenticacin (Init_Login()) visto al principio de este captulo 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 sesin de Windows (Clase
NetworkCredential de System.Net). La clase permanece activa mientras lo est la aplicacin
de gestin y se puede acceder mediante su propiedad Current que hace que devuelva la
clase con los parmetros establecidos en el inicio de la sesin.
Tambin est la clase auxiliar campos auditoria que complementa a la clase Campos
Auditora de la que se ha hablado ya en este captulo y se ver en el paquete WinAudit. Es
utilizada por el mdulo rea de Trabajo al mostrar el detalle de las mquinas como se
explica en el apartado 6.1.1.3 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 sern necesarias para registrar las alertas. No
ser necesario crearlas puesto que estas clases ya existen y pertenecen a la aplicacin
CRM. Mediante el acceso al servicio web del CRM para programadores, CRMService, se
pueden utilizar todas estas clases. Para la correcta utilizacin consultar la documentacin del
CRM SDK 3.0 descargable desde el link
http://www.microsoft.com/downloads/details.aspx?FamilyID=9c178b68-3a06-4898-bc83-
bd14b74308c5&displaylang=en.
168
Figura 6.118 Diagrama de Clases. Paquete Microsoft CRM Dinamics I
El mecanismo para la generacin y registro de alertas en el CRM utilizando estas clases se

ha explicado en el apartado 6.1.3.3 Generacin de Alertas
169
Figura 6.119 Diagrama de Clases. Paquete Microsoft CRM Dinamics II
170
Paquete Windows Task Sheduler

Pertenecientes al Namespace del ensamblado TaskScheduler. Se requiere aadir una
referenca a la dll comentada en el apartado 2.6.4 y ya se pueden utilizar las clases que se
requieran.
Figura 6.120 Diagrama de Clases. Paquete Windows Task Sheduler I
171
Figura 6.121 Diagrama de Clases. Paquete Windows Task Sheduler II
172
Paquete WinAudit
Este paquete ha sido creado a partir de cada campo que se obtiene en la auditora que
realiza el programa WinAudit. Cada campo auditado posee atributos definidos en la
documentacin del programa que se puede analizar desde el link
http://www.pxserver.com/WinAudit/hlp_interp_audit.html. En la pgina web (en ingls) 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
Figura 6.122 Diagrama de Clases. Paquete WinAudit. Campos Auditoria
Figura 6.123 Diagrama de Clases. Paquete WinAudit I
174
Figura 6.124 Diagrama de Clases. Paquete WinAudit II

175
Figura 6.125 Diagrama de Clases. Paquete WinAudit III
176
Paquete EvoAgentLibrary.dao -Capa de Datos-.

En este paquete se implementa todos los mtodos y querys necesarias para acceder a la
base de datos. Como se ha visto en el apartado 6.2.4.2 se ha diseado 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 6.126 Diagrama de Clases. Paquete dao. EvoDataSet
177
Figura 6.127 Diagrama de Clases. Paquete dao. EvoDataSet.TableAdapters y CRMDataSet
178
Figura 6.128 Diagrama de Clases. Paquete dao I
179
Figura 6.129 Diagrama de Clases. Paquete dao II
180
Figura 6.130 Diagrama de Clases. Paquete dao III
181
Figura 6.131 Diagrama de Clases. Paquete dao IV
182
6.3.2SubSistema EvoAgentServer
Paquete EvoAgentServer.services
El subsistema EvoAgentServer posee las clases correspondientes a los Servicios Web,
Cada mtodo 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 comunicacin con el subsistema EvoAgentService y
otro para la comunicacin con el sistema EvoAgentManager.
183
Figura 6.132 Diagrama de Clases. Paquete EvoAgentServer.services
Paquete ProgramacinTareas.exe
El modulo de registro de tareas programadas no se correspondera con el subsistema
EvoAgentManager, pero al estar ubicado en la carpeta tareas programadas del servidor se
incluye aqu. Se trata de una aplicacin para consola que contiene el mtodo main ms
algn mtodo auxiliar en la clase primaria de todo proyecto:
Figura 6.133 Diagrama de Clases. Paquete ProgramacionTareas.exe
6.3.3 SubSistema EvoAgentManager
Paquete EvoAgentManager.iu
Este paquete se corresponde con la interfaz de usuario para los tcnicos de Evotec. Las
clases se disearon con el editor Visual Studio 2005 tal y como se han ido presentado en el
punto 6.1 Diseo de la Interfaz de Usuario.
184
Figura 6.134 Diagrama de Clases. Paquete EvoAgentManager.iu I
Como se puede ver en la figura 6.134, existir relacin entre las ventanas (clases) que se
pueden mostrar a partir de la ventana principal (Form_Main). Esto se hace as para acceder
slo 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 (Patrn 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 diseo de interfaz, adems de
campos auxiliares que se utilizaran para la gestin de los datos que manejan las ventanas y
de los eventos que disparan, que seran los mtodos descritos mediante los diagramas de
secuencia.
Figura 6.135 Diagrama de Clases. Paquete iu II
185
Figura 6.136 Diagrama de Clases. Paquete EvoAgentManager.iu III
186
6.3.4 SubSistema EvoAgentService
Paquete EvoAgent
Aqu se presentan las clases que utiliza el Servicio de Windows.
Figura 6.137 Diagrama de Clases. Paquete EvoAgentService.EvoAgent I
187
Figura 6.138 Diagrama de Clases. Paquete EvoAgentService.EvoAgent II
188
Paquete EvoIcon
El mdulo 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 slo se vea el Icono (Icon) de la clase NotifyIcon.
Figura 6.139 Diagrama de Clases. Paquete EvoAgentService.EvoIcon
189
7. Implementacin del sistema, Pruebas e Instalacin
7.1 Implementacin de la base de datos

Como se ha visto en el apartado 6.2 Diseo del modelo de datos, se ha creado la base de
datos en el Sistema Gestor SQL Server Express, versin 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 autenticacin de Windows y por parte del servicio web
mediante el uso de autenticacin 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 lgica de acceso a datos en la librera EvoAgentLibrary. Se

han creado los dataSet y las clases de gestin de acceso en el fichero dao.cs que se ver en
el siguiente punto. Para la lgica de acceso a datos se debe disponer del paquete Dominio
ya implementado pues la lgica 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 integracin de repositorio central de datos, definida

en el apartado apartado 3.4.4.
7.2 Construccin del sistema

En este apartado se procede a desarrollar el cdigo de las aplicaciones que conforman el
sistema. La codificacin se realizar siguiendo los modelos obtenidos en las etapas de
diseo anteriores, e implementarn fielmente las clases con los mtodos y atributos
descritos en ellos.
El entorno de desarrollo es Visual Studio como ya se ha comentado anteriormente. Se

crearn 2 soluciones que recogen toda la funcionalidad de las aplicaciones del sistema. Una
solucin estar orientada al desarrollo de la aplicacin agente, EvoAgentService y otra al
desarrollo de la librera, 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
aplicacines de gestin, EvoAgentManager y de intrprete de programacin de tareas,
ProgramacionTareas.exe.
Para el desarrollo del mdulo EvoAgentServer, aplicacin web del sistema y su publicacin
en el entorno de desarrollo, se ha instalado el servidor IIS 7.0 donde se ha creado un sitio
web:
190
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

cdigo donde se dispone del dominio, del acceso a datos y de los proyectos creados donde
desarrollar cada subsistema. A continuacin se muestra el directorio fsico de trabajo,
EvoAgentProyect y la estructura de las soluciones y proyectos, fiel al diseo del proyecto:
Figura 7.2 Directorio de trabajo EvoAgentProyect
191
EvoAgentService
Figura 7.3 Estructura del proyecto EvoAgentService
La solucin EvoAgentService posee 3 proyectos, EvoAgent, EvoIcon y EvoAgentSetup y

tienen las clases con los mtodos indicados en los respectivos apartados del diseo interno
del sistema (Ver apartado 6.3.4 Subsistema EvoAgentService para el diagrama de clases y
6.1.2 Subsistema EvoAgentService e interaccin con el servidor para el diseo de la
funcionalidad). El primero, EvoAgent, corresponde al servicio de Windows, el segundo,
EvoIcon, a la aplicacin 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
EvoAgentProyect
Figura 7.4 Estructura del proyecto EvoAgentProyect
La solucin EvoAgentProyect posee 6 proyectos de los cuales se va a exponer la estructura

de los tres primeros.
EvoAgentLibrary es la librera de la aplicacin. En el apartado 6.3.1 se explica el contenido

de cada paquete de clases. Se puede ver el paquete DAO que se corresponde con la lgica
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 lgica de negocio
pertenecientes al paquete EvoAgentLibrary.Services. Por ltimo se vern en la carpeta
References la referencia a la librera TaskScheduler.dll y en la carpeta Web References la
referencia al servicio web ControlAdmin.
EvoAgentManager es la aplicacin de gestin 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 librera EvoAgentLibrary.
EvoAgentServer es la aplicacin 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 aplicacin Los
servicios se pueden crear en este directorio y utilizar la herramienta de publicacin para
alojarlos en el directorio virtual utilizado por el sitio web del IIS. Dicha herramienta genera
una solucin de la aplicacin produciendo el cdigo que acta por detrs de los servicios
web. El funcionamiento del codebehind se ve en el Anexo 3. La aplicacin contiene un
ficher de configuracin del sitio web denominado web.config que establece parmetros de la
aplicacin as como el mtodo de autenticacin requerido.
El proyecto ProgramacionTareas es una aplicacin de consola y posee la clase que se ha

explicado en el apartado 6.3.2. Dicha clase implementa la funcionalidad expuesta en el
apartado 6.1.1.2.
Los proyectos restantes se corresponden con los instaladores de la aplicacin de gestin

EvoAgentManager, y la aplicacin de consolo ProgramacionTareas, respectivamente.
193
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 construdo se puede traspasar el sistema a un entorno de prueba donde puedan
realizarse las pruebas de integracin definidas en el apartado 3.4.4. As, queda validado el
desempeo, por parte del sistema, de los requerimientos (Look & Feel), la autenticacin
194
nica de usuarios tal y como se haba diseado en el apartado 6.1.1.1 y la administracin de

los mismos en el apartado 6.1.1.6.
Tambin se valida la operacin en ambiente integrado y la integracin funcional,

identificando los procesos de interaccin entre las aplicaciones. Algunas interacciones han
sido validadas en las pruebas unitarias como la interaccin entre los agentes y el sistema
operativo para la ejecucin de tareas. Las interacciones identificadas son:
Interaccin entre agentes y servidor: Por parte de los agentes se ha implementado

una clase, llamada ComunicacinServidor 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.
Interaccin entre el servidor y la base de datos y entre la aplicacin de gestin y la

base de datos: Interactan a traves de los adaptadores creados en las clases dataSet
tal y como se ha explicado en el apartado 6.2.4.
Interaccin entre el servidor y el sistema CRM: Esta interaccin se realiza a travs de

la clase AlertaDAO ubicada en el archivo Dao.cs del paquete EvoAgentLibrary.Dao.
Interaccin entre la aplicacin de gestin y el servidor: Se realiza a travs de la capa

de acceso a datos de la librera (archivo Dao.cs del paquete EvoAgentLibrary.Dao) en
los mtodos que se han definido a tal efecto en las distintas clases. Dichos mtodos
utilizan la referencia web de la librera. Como ejemplo se puede ver lo diseado para
obtener las auditoras del servidor en el apartado 6.1.1.3, que utiliza la clase
DetalleAuditoraDAO para interacctuar con el servidor y obtener los ficheros xml de
las auditoras mediante el mtodo getAuditorias(maquina).
Interaccin entre el sistema de gestin y el Task Scheduler del servidor: Se realiza

dicha interaccin utilizando la librera TaskScheduler referenciada en
EvoAgentLibrary. Es utilizada desde la clase TareaProgramadaDAO perteneciente al
archivo Dao.cs del paquete EvoAgentLibrary.Dao.
Interaccin entre agente y la aplicacin 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 interaccin 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
versin de las dos aplicaciones que comprende, el servicio de Windows y la aplicacin
EvoIcon del icono.
Tambin es necesario probar que el sistema posee la seguridad requerida, y el volumen de

carga que puede soportar.
195
Una vez se han llevado a cabo las pruebas funcionales se puede proceder a pasar el
sistema a un entorno de produccin. En realidad parte de las pruebas funcionales se ralizan
directamente sobre el entorno de produccin. Para probar la interaccin se debe probar
directamente sobre este entorno que es el que se va a utilizar.
7.4 Implantacin en el entorno de produccin

En este apartado se incluye un manual de instalacin del sistema en produccin. 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 aplicacin EvoAgentServer. Para la publicacin 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 introduccin a los CNAMEs. Consultar el Anexo1. Tecnologas
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 travs del CNAME.
Esto hace que la hubicacin de los servicios del servidor sea dinmica.
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 aplicacin EvoAgentServer. La ruta completa queda como
sigue: http:\\evoagentserver.evotec.es\EvoAgentServer, despus seria necesario indicar el
recurso al que se quiere acceder, es decir, el servicio web, que para el caso de los agentes
estara ubicado en el directorio ControlClientes y para el caso de los tcnicos en el directorio
AdminManager. Esa es la ruta a la que intentarn conectarse si al utilizar el CNAME no
obtiene resultado. La utilizacin del cname sera sustituir evoagentserver.evotec.es por
evoagentserver.
La instalacin de los servicios se realiza mediante el Visual Studio. En el proyecto

EvoAgentProyect se debe hacer clic en el botn derecho del ratn 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 accin mediante un fichero de backup (.bak) o
un ficher de datos (.mdf) y logs (.ldf). El fichero de backup se crea desde la aplicacin SQL
Management Studio con el servidor de base de datos donde reside la base de datos
conectado. Hacer clic en el botn derecho del ratn sobre la base de datos y pulsar en
Tareas/Copia de seguridad:
196
Figura 7.6 Creacin 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
Figura 7.7 Configuracin 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 conexin como se ha explicado en el
apartado 6.2.4.
Agente
La instalacin del agente consiste en la ejecucin 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
El instalador no requiere de interaccin con el usuario. Se puede instalar en todas las

mquinas de un cliente mediante una directiva de grupo. Para conocer ms acerca de sta
tcnica se puede visitar la siguiente pgina web:
http://www.microsoft.com/spain/technet/recursos/articulos/tnt1-119.mspx
ProgramacionTareas
La aplicacin de consola debe residir en la carpeta Programacion Tareas del directorio
AdminManager del servidor. Se debe realizar la instalacin 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 instalacin.
Aplicacin de gestin
En los equipos de los tcnicos se instala mediante el correspondiente fichero .msi la
aplicacin EvoAgentManager. El fichero reside en el directorio de trabajo:
EvoAgentProyect\EvoAgentManager\
EvoAgentManager\EvoAgentManagerSetup\Debug\EvoAgentManagerSetup.msi
El instalador no require de interaccin con el usario.
7.4 Manual de Usuario y de Explotacin

Para la explotacin del sistema desarrollado e instalado, adems de disponer del cdigo
fuente en el directorio de trabajo, se requiere disponer del presente documento, memoria del
proyecto, y de dos documentos ms:
Manual de Usuario: El manual de usuario comprende el uso de la aplicacin de

gestin en todas las funcionalidades que se han visto durante el diseo.
Manual de Explotacin: Va ms all del mero uso de la aplicacin. 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 Explotacin
199
8. Planificacin y Presupuesto
8.1 Planificacin
La planificacin 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 planificacin 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 correspondern con el modelo de metodologa de desarrollo escogido.
8.1.1 Tareas o Fases del proyecto

Las tareas que comprende el proyecto son las siguientes:
1. Estudio de las tecnologas y herramientas a utilizar, tanto las Aplicaciones software Libre
como tecnologas 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. Anlisis de requerimientos mediante el Modelo de dominio y los Casos de uso.
3. Diseo Externo con el Modelo de Arquitectura y el Modelo de Paquetes.
4. Diseo Interno con el Modelo de Interfaz, los Diagramas de Interaccin, los Diagramas
de Clases y el Modelo de datos.
5. Implementacin y Pruebas que comprende las tareas:
1. Programacin.
2. Pruebas unitarias.
3. Pruebas de integracin.
6. Instalacin y Puesta en Marcha.
7. Documentacin
200
8.1.2 Planificacin Inicial

La planificacin inicial del proyecto era la siguiente:
Figura 8.1 Planificacin inicial del proyecto
Segn esta planificacin se pretenda comenzar con el desarrollo del sistema en Febrero de
2007 toda vez que se hubiera realizado previamente las fases de anlisis y diseo. Dicho
desarrollo debera haber finalizado a principios de Mayo de 2007 momento en el que se
iniciarian las pruebas para, en Junio de 2007, realizar la instalacin del sistema. La
documentacin, por otro lado, se cumplimentara al acabar cada fase.
Es, sin duda, una planificacin ideal, pues el plazo del proyecto debe coincidir con la
finalizacin del curso, es decir, en Junio o en cualquier caso, en Septiembre. Adems, las
fases de ejecucin del proyecto segn la metodologa son adecuadas al tipo de proyecto.
201
8.1.3 Evolucin Real del Proyecto

El proyecto se ha construido siguiendo el esquema de tiempo del diagrama de Grantt de la
figura:
Figura 8.2 Evolucin real del proyecto
202
8.1.4 Conclusiones de la planificacin

En la evolucin del proyecto se puede observar ciertas discrepancias respecto a la
planificacin inicial.
El anlisis de requerimientos tiene lugar en tres ocasiones a lo largo del proyecto, lo

cual deja entrever que no se realiz con precisin en el momento en que estaba
planificado.
En esta lnea cabe aadir un apunte en cuanto al anlisis de requisitos. Es

fundamental, a la hora de afrontar un proyecto de estas caractersticas, 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 podra agregar una tarea a la hora de realizar el anlisis
de requesitos que consistiera en el desarrollo de los funcionales donde se definira las
operaciones desde el punto de vista funcional sin entrar en lo tcnico.
Esto ltimo pretende fijar un alcance al proyecto sin afectar esto a que el diseo y
desarrollo del proyecto permita agregar funcionalidad sin demasiada dificultad, es
decir, a que se construya un sistema modularizable y escalable.
El desarrollo llev ms tiempo del primeramente esperado. A principios de Mayo no

se haba completado ms de los tres cuartos del desarrollo sin haber realizado las
pruebas unitarias correspondientes ni comenzado las pruebas de integracin. Esto
hizo que la fecha de fin de proyecto se traspasara a Septiembre.
Sin duda, una de las causas ms probables de este retraso fue un diseo del sistema
pobre, del que no se pudo sacar provecho a la hora de realizar la programacin. El
diseo implica conocer el sistema a construir de forma modularizada, entendiendolo
de una forma global y cada mdulo en profundidad. Esto permite afrontar el
desarrollo con una idea mucho ms clara de lo que se va a hacer y de cmo se va ha
hacer, ayudando a reducir el cdigo y a hacerlo ms compacto y flexible y, con toda
seguridad, a reducir considerablemente el tiempo dedicado al mismo.
Finalmente, la documentacin del proyecto no se realiz durante la ejecucin de cada

tarea, debido entre otras cosas, a que no se dispona del personal disponible
necesario para realizar la tarea de documentacin mientras se realizaban el resto de
tareas. Por otro lado, no se di la importancia necesaria a la documentacin la cual,
realizndola a conciencia, resulta fundamental a la hora de plasmar las tareas previas
al desarrollo esto es, el anlisis de requisitos y el diseo, como finalmente se ha visto
en este proyecto.
203
Esto, unido al tardo comienzo de las pruebas de integracin, provoc que el proyecto no
pudiera terminarse en la ficha de fin del proyecto, Septiembre de 2007, teniendo que recurrir
a una prrroga.
En Octubre, una vez iniciada la prrroga de un curso lectivo, y con el proyecto en sus fases
finales, con la documentacin prcticamente terminada, salieron claramente a la luz los
hechos que se han expuesto anteriormente. Con esto, se observ que no se haban seguido
los pasos necesarios para garantizar un desarrollo de calidad. Por otro lado, como se ve en
la evolucin del proyecto, fue en Octubre cuando se adquirieron nuevos conocimientos para
el diseo y desarrollo de un proyecto basados en los entornos de desarrollo que se estaban
utilizando.
Al tener el tiempo de la prrroga disponible y, tras todo lo anterior se plante afrontar de

nuevo el proyecto, apoyndose en la idea que se tena ya del mismo y en muchos de los
algoritmos, parte del cdigo ya desarrollado y de la documentacin ya realizada. Se puso
como fecha de fin del proyecto Febrero de 2008.
El proyecto, a da de hoy, 1 de febrero de 2008, est implantado en la empresa y

realizndose las pruebas de integracin con ciertas garantas 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 adems de tratarse de un proyecto muy ambicioso.
Sin embargo, lo ms importante es la reflexin llevada a cabo para sacar a la luz los hechos
que hicieron que el proyecto no prosperara segn 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 evolucin del sistema desarrollado hacia una cuota mucho
mayor de calidad, adems de que proporcion nuevos conocimientos, incluida la propia
experiencia, por parte del responsable del proyecto.
204
8.2 Presupuesto
Se debe tener en cuenta dos aspectos para obtener el presupuesto del proyecto: Por un lado
la valoracin econmica 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
59.925,00
TOTAL 68.251,82
Figura 8.3 Presupuesto del proyecto
Dicho coste sera aplicable a una empresa de servicios informticos que quisiera desarrollar
e implantar el proyecto de cero incluyendo las herramientas necesarias para ello. En el caso
actual, no sera necesario incluir nada dentro del apartado Herramientas.
A continuacin se detalla cada uno de los elementos:
8.2.1 Valoracin econmica del esfuerzo de los integrantes en el proyecto

Para obtener una valoracin econmica realista de los esfuerzos dedicados por los
integrantes atendiendo tambin a las diferencias en cuanto a la retribucin que recibe cada
uno de ellos se debe tener en cuenta tres roles diferentes, jefe de proyecto, analista-
diseador, y programador, que han sido llevados a cabo por la misma persona.
La retribucin monetaria estimada por rol desempeado es la siguiente:
Jefe de proyecto: 85 /hora.
Analista-Diseador: 55 /hora.
Programador: 40 /hora.
Para el clculo 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
Periodo 1: El primer periodo va desde el comienzo del proyecto, en Septiembre de

2006 hasta la fecha fn inscrita por la universidad, Septiembre de 2007, es decir, un
ao. 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 2008. 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 3 0 3
ESTUDIO DE LAS TECNOLOGAS 81 0 81
ANLISIS DE REQUERIMIENTOS 22 15 37
ESTUDIO DE TCNICAS DE DISEO 0 80 80
Y PRG
DISEO EXTERNO 20 10 30
DISEO INTERNO 40 50 90
DESARROLLO 193 217 410
PRUEBAS UNITARIAS 50 70 120
PRUEBAS INTEGRACIN 20 85 105
IMPLANTACIN 0 15 15
DOCUMENTACIN 71 155 226
CIERRE PROYECTO 0 3 3
TOTALES 500 700 1200
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
Actividad/Periodo (horas) PERIODO I

sep, oct y dic 06, ene mar, abr jun, TOTAL
ACTIVIDAD nov 06 y feb 07 y may 07 jul,ago y
sep 07
Inicio del Proyecto 3 3
Estudio de las Tecnologas 69 10 2 81
Anlisis de Requerimientos 22 22
Estudio de tcnicas de 0
diseo y prog.
Diseo Externo 20 20
Diseo Interno 25 15 40
Desarrollo 65 93 35 193
Pruebas Unitarias 10 10 30 50
Pruebas Integracin 20 20
Implantacin 0
Documentacin 6 65 71
Cierre del Proyecto 0
TOTALES 100 130 120 150 500
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 Tecnologas 0
Anlisis de Requerimientos 5 10 15
Estudio de tcnicas de 80 80
diseo y prog.
Diseo Externo 10 10
Diseo Interno 30 20 50
Desarrollo 40 80 50 40 7 217
Pruebas Unitarias 10 30 30 70
Pruebas Integracin 15 70 85
Implantacin 5 10 15
Documentacin 10 20 25 50 50 155
Cierre del Proyecto 3 3
TOTALES 175 140 105 140 140 700
Figura 8.6 Horas dedicadas a las actividades durante el Periodo 2
Atendiendo a los roles participantes de cada tarea y, en funcin de la retribucin

establecida para cada rol, se obtiene la siguiente tabla que indica la voloracin
econmica de cada rol integrante en el proyecto y de las tareas realizadas:
207
PARTICIPANTES
JEFE ANALISTA- PROGRAMADOR
PROYECTO DISEADOR
ACTIVIDAD Per H h h h TOTAL
Inicio del I 3 3 255 0 - 0 - 255
Proyecto II 0 0 - 0 - 0 - -
Estudio de las I 81 11 935 35 1.925 35 1.400 4.260
Tecnologas II 0 0 - 0 - 0 - -
Anlisis de I 22 10 850 12 660 0 - 1.510
Requerimientos II 15 7 595 8 440 0 - 1.035
Estudio tcnicas I 0 0 - 0 - 0 - -
de diseo y prog. II 80 10 850 40 2.200 30 1.200 4.250
I 20 4 340 16 880 0 - 1.220
Diseo Externo
II 10 2 170 8 440 0 - 610
I 40 2 170 23 1.265 15 600 2.035
Diseo Interno
II 50 3 255 22 1.210 25 1.000 2.465
I 193 3 255 20 1.100 170 6.800 8.155
Desarrollo
II 217 2 170 15 825 200 8.000 8.995
Pruebas I 50 2 170 18 990 30 1.200 2.360
Unitarias II 70 4 340 16 880 50 2.000 3.220
Pruebas I 20 5 425 10 550 5 200 1.175
Integracin II 85 25 2.125 40 2.200 20 800 5.125
I 0 0 - 0 - 0 - -
Implantacin
II 15 4 340 6 330 5 200 870
I 71 10 850 31 1.705 30 1.200 3.755
Documentacin
II 155 35 2.975 40 2.200 80 3.200 8.375
Cierre del I 0 0 - 0 - 0 - -
Proyecto II 3 3 255 0 - 0 - 255
TOTALES 1200 145 12.325 360 19.800 695 27.800 59.925
Figura 8.7 Estimacin del esfuerzo de los integrantes del proyecto y valoracin econmica.
8.2.2 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 seran
necesarias para llevar a cabo el proyecto y para implantarlo en un entorno de produccin y
se aade el coste que supondra dichas herramientas.
HERRAMIENTAS IMPORTE
SOFTWARE 1.019,00
Entorno de Produccin
HARDWARE 570,00
Entorno de Desarrollo SOFTWARE 5.071,08
HARDWARE 1.686,74
TOTAL 8.326, 82
Figura 8.8 Estimacin del coste de las herramientas necesarias para el desarrollo e implantacin del proyecto.
Entorno de desarrollo:
En el entorno de desarrollo se requerirna las siguientes herramientas:
208
1. Software:
Visual Studio 2005: Se requerira de una licencia del programa Visual Studio.
Visual Studio 2005 Professional Edition con suscripcin MSDN Professional:
1019
Sql Server: Como la versin 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. Includo con el hardware.
Servicios de Internet Information Server: Viene includo dentro del sistema

operativo.
Microsoft CRM 3.0: Se puede acudir al mismo sistema implantado en el entorno

de Produccin.
Total Software: 1019
2. 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 = 1569 .
209
Entorno de produccin:
En el entorno de produccin se requerirna 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 includo con la licencia del sistema operativo. 0 .
Microsoft Sql Server Estndar Edition: 1 licencia, Precio 1.030,96
Servicios de Internet: Se requiere tener un dominio de Internet operativo para las

conexiones desde las mquinas cliente. El coste del registro viene a ser de
72,12 (IVA incluido). Esta tasa permite mantener el dominio durante 1 ao
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 ao: 1299 .
Total Software: 5071,08 .
2. Hardware:
Servidor: Como ejemplo se pondr un servidor asequible para una pequea o

mediana empresa
210
Caractersticas:
Factor de forma Torre o montaje en rack 5U

Procesadores Hasta dos procesadores Intel Xeon con Tecnologa 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 vas y 1 x 8 vas);
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
conexin en caliente con soporte de unidad de cinta interna
Almacenamiento interno mximo 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 (10.000 rpm) Ultra320
SCSI
18 GB, 36 GB, 73 GB y 146 GB2 (15.000 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 alimentacin 930 W, alimentacin redundante de conexin en caliente
opcional
Disponibilidad Memoria ECC, ranuras PCI Express de conexin en
caliente,correccin de datos de dispositivo simple (SDDC), banco de memoria de
reserva, memoria duplicada; unidades de disco duro SCSI de conexin en caliente;
alimentacin redundante de conexin en caliente opcional; refrigeracin redundante
de conexin en caliente; chasis sin necesidad de herramientas; soporte de canal de
fibra de alta disponibilidad y clster SCSI; ROMB opcional con cach de desfase de
256 MB; parte posterior dividida opcional; panel LCD; Active ID
Vdeo ATI Radeon 7000-M incorporado con SDRAM de 16 MB
Gestin remota Controlador de gestin de placa base con soporte IPMI 1.5, accesible
mediante red o puerto serie; DRAC4/I sin ranura opcional
Gestin de sistemas OpenManagede 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 Produccin = 6757,82

Total Presupuesto Herramientas Software y Hardware: 8326, 82
211
9. Conclusiones y Evolucin del Sistema
9.1 Conclusiones
La elaboracin de este proyecto ha servido para afianzar y poner en prctica muchos de los
conocimientos aprendidos a lo largo de toda la carrera.
Principalmente se han tratado aspectos de ingeniera del software en todas sus fases as
como tratamiento de bases de datos, programacin orientada a objetos en C# y aplicacin
de Algoritmia en muchos de los mtodos. Tambin se ha podido afianzar y desarrollar los
conocimientos adquiridos en cuanto a planificacin y gestin 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 familiarizacin no slo con las ltimas tecnologas en
cuanto a desarrollo de software sino tambin con tcnicas adecuadas de diseo y
programacin.
Por ltimo, el proyecto ha requerido ms horas de las previamente previstas para el

desarrollo y hay que hacer referencia al apartado 8.1.4 Conclusiones de la Planificacin
donde se han expuesto las conclusiones de la planificacin.
9.2 Evolucin 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 evolucin, incrementando las funcionalidades. El sistema
desarrollado permite una gran evolucin del mismo en cuanto a las tareas que pueden
realizar los agentes. Se pueden disear e implementar nuevas tareas y con tal fin se ha
creado el documento de manual de explotacin Anexo a este documento.
Por otro lado, se podran proponer nuevas fases en el proyecto como podra ser:
Ampliacin de la monitoriazacin a sistemas con PCs que posean sistemas

operativos de otros fabricantes. Como se ha podido ver a lo largo del presente
documento, se ha enfocado la monitorizacin de sistemas a sistemas basados en
Windows donde todos los ordenadores poseen un sistema opertativo de Windows.
Se propone, por tanto, una evolucin del sistema para poder monitorizar tambin
PCs con sistema operativo Linux o MAC.
Desarrollo de una extensin de la aplicacin CRM de tal forma que permitar

transladar la informacin que genera una alerta a un caso que se cree asociado a la
misma, con el cual se trabaja. Esto sera util al disponer, por ejemplo, de la mquina
y el cliente objeto de la alerta, as como la descripcin de la misma en el caso sin
212
tener que pasar esta informacin a mano. (Ver apartado 6.1.3.4 Interfaz CRM, crear
caso vinculado a alerta).
Esto se podra hacer mediante el uso de los Callouts del CRM. Esta tecnologa
permite agregar funcionalidad a eventos del CRM como el crear un caso. Sera
necesario desarrollar un callout y asociarlo a dicho evento. El CRM de forma interna,
al crear un caso nuevo, vera el callout declarado para tal evento mediante un
fichero de configuracin y lo ejecutara. El callout debera controlar que la creacin
del caso provenga de una alerta, en cullo caso, se obtendra la informacin de la
alerta via sql y se pasara dicha informacin al caso va CRMService.
Modificacin del subsistema de Tareas Programadas de forma que permitar disear

tareas repetitivas a los usuarios tcnicos. El problema del subsistema de Tareas
Programadas es que al hacer uso de la herramienta Task Scheduler de Windows del
servidor slo los usuarios administradores tienen permiso para registrar tareas
repetitivas. Adems se crean tantos archivos de configuracin de tareas como
tareas repetitivas se creen. Se propone una evolucin del sistema pasando por la
inclusin de una tabla en la base de datos donde se registrarn 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 podra crear una tarea repetitiva. Se podra mantener el diseo
de la interfaz de gestin y creacin de tareas programadas.
213
10. Bibliografa
[BARR01] Barranco de Areba, Jess, Metodologa del anlisis estructurado

de sistemas, Publicaciones de la Universidad Pontificia Comillas,
Madrid 2001.
[ESQU05] Esquivel, Juan Carlos, Apuntes Ingeniera del Software II,

Universidad Pontificia Comillas, Madrid 2005.
[ROCA05] Mara Jos Roca, Pruebas de Integracin de Productos: Un

Enfoque Prctico. PaqueSoft, GreenSQA (Software Quality
Assurance), 2005.
[CHAR02] Francisco Charte Ojeda, Visual C# .NET, Anaya Multimedia,

2002.
[NAGE06] Christian Nagel, Bill Evjen, Jay Glynn, Morgan Skinner, Karli
Watson, Allen Jones. Profesional C# 2005. Wiley Publishing,
2006.
[SKIB06] Craig Skibo, Marc Young, Brian Johnson. Working with Microsoft
Visual Studio 2005. Microsoft Press, 2006.
[HOLM04] Dan Holme y Orin Thomas, Managing and Maintaining a

Microsoft WINDOWS SERVER 2003 ENVIRONMENT, McGraw-
Hill / Interamericana de Espaa S.A.U, 2004.
Principales pginas web visitadas:
http://msdn2.microsoft.com/en-us/library/default.aspx (MSDN Framework .NET

Development Library)
http://es.wikipedia.org/wiki/Portada (Wikipedia).
http://www.pxserver.com/WinAudit.htm (WinAudit).
http://www.codeproject.com (CodeProject).
http://www.creangel.com/uml/home.php (UML) Consultora de Seguridad Creangel.
http://www.creangel.com/uml/secuencia.php (Diagramas de Secuencia de UML).
http://www.creangel.com/uml/paquetes.php (Diagrama de Paquetes de UML).
http://msdn2.microsoft.com/en-us/library/t0aew7h6.aspx (Scripting).
214
Anexo 1. Manual de Usuario
Este anexo pretende servir de ayuda al usuario de la aplicacin de gestin de EvoAgent.

Dicha aplicacin consta de 3 mdulos entre los que se reparte toda la funcionalidad. Estos
mdulos son:
rea de Trabajo: Permite gestionar la actividad de los agentes y visualizar

informacin sobre los mismos.
Settings: Permite gestionar parmetros de configuracin de la aplicacin. Se

manejarn aspectos relevantes de la aplicacin como el Control de Alertas, Gestin
de Versiones de la aplicacin de las mquinas cliente y actualizacin de usuarios de
la aplicacin.
Referencias: Permite ver la descripcin de la aplicacin y acceder a la aplicacin

CRM.
El mdulo principal es el rea de Trabajo. ste mdulo comprende varias funcionalidades

resumidas en los siguientes puntos:
Tareas: Donde se trabajar con las tareas asignables a las mquinas 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 auditoras as como dar acceso a
mquinas cliente al sistema.
Clientes/Dominios: Donde se podr asociar mquinas cliente con los clientes

registrados en la aplicacin de gestin CRM a travs de los dominios.
Logs: Donde se podr monitorizar el correcto funcionamiento del sistema.
Antes de empezar con la gua prctica en cada mdulo cabe resear que el sistema est
fuertemente vinculado con la aplicacin de gestin CRM.
Tanto es as que nuevos usuarios no podrn trabajar con esta aplicacin de gestin 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 aplicacin han sido obtenidos de la base de datos
del CRM y un nuevo usuario que quiera iniciar la aplicacin deber haber sido previamente
registrado en el CRM y actualizados los usuarios de la aplicacin como se ver en el mdulo
Settings. (Ver Settings de Ususarios)
215
Tambin se ha incluido parte de la funcionalidad del sistema dentro de la interfaz del CRM.
Las alertas generadas por el sistema en relacin a las mquinas monitorizadas son
expuestas en esta herramienta de gestin y por tanto se incluye dentro de este manual cmo
acceder y trabajar con ellas.
Al arrancar la aplicacin, sta obtiene automticamente las credenciales de usuario

introducidas por ste al iniciar sesin de Windows. Con estas credenciales se realiza una
autenticacin. Si son correctas se carga la ventana principal de la aplicacin. Desde dicha
ventana se puede acceder a los distintos mdulos y funcionalidades.
Figura A1.1 Ventana Principal de la Aplicacin
Tareas
Este mdulo permite gestionar las tareas a realizar por parte de las mquinas agente. Hay
varias tareas definidas:
Auditoria: Consiste en la ejecucin del programa WinAudit

(http://www.pxserver.com/WinAudit/contents.html). Para su ejecucin se requiere
seleccionar los campos que se desean auditar. La ejecucin del programa genera un
informe completo de la mquina 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 seleccin de campos
(Auditora) incluye por defecto aquellos campos que son examinados para la
generacin de alertas: el campo software instalado, drivers (discos lgicos), memoria,
216
errores del log y servicios de Windows. La visualizacin del resultado de la auditora

se puede contemplar en el apartado mquinas (Ver detalle).
Diariamente se ha programado una tarea auditoria con los campos anteriormente

sealados.
Apagado: Se puede programar el apagado remoto de una mquina. A la hora

sealada 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 ejecucin del Limpiador de la aplicacin Ccleaner.
Inicio Servicio: Se puede iniciar un servicio indicando el nombre del servicio (Ver
Inicio Servicio).
Comprobar Cuotas: Se puede programar la comprobacin de las cuotas de usuario

en agentes servidores (Ver Comprobar Cuotas).
217
Desfragmentacin de los discos duros: Se arranca el desfragmentador de

Windows que analiza los discos duros e inicia la desfragmentacin si fuese
necesario.
Ejecucin de Scripts: Se trata de la ejecucin de un archivo .vbs correspondiente a

un script.
Los agentes se comunican con el servidor cada hora. En esa comunicacin recibe las
tareas que tiene pendientes hasta la prxima comunicacin. La ltima comunicacin se
puede observar en el log de acciones consultando las acciones del agente en cuestin (Ver
Log Acciones) o en el apartado mquinas en el campo timestamp. Con ello se puede
programar la tarea para un agente a la hora adecuada.
Bsqueda Predefinida de tareas y nuevas bsquedas

Al iniciar se carga las tareas que cumplan con los parmetros establecidos por defecto. Por
defecto se cargan todas las tareas pendientes. Estos Parmetros son los que aparecen en la
parte superior (Cliente, Maquina, Tarea, Estado) dentro de la caja Filtro de Bsqueda de
Tareas. Se pueden modificar para obtener las tareas buscadas.
Figura A1.4 Ventana Tareas
218
Nueva tarea
Para asignar una nueva tarea se debe pulsar el botn 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 mquina, las mquinas de un cliente
o todas las mquinas registradas en la aplicacin. Para ello hay habilitados tres despegables
para clientes (Cliente), mquinas (Maquina) y tareas (Tarea) que aparecen y se ocultan al
pulsar el botn que hay al final del cuadro de texto de cada respectivo apartado.
Figura A1.5 Ventana de Edicin de Tareas
Seleccin del cliente

Pulsar el botn cuadrado al final del cuadro de texto justo debajo de la etiqueta Cliente.
Aparece un despegable con los clientes registrados en la aplicacin. Si no aparece el cliente
deseado:
- El cliente debe haberse registrado previamente en el CRM.
- Actualizar los clientes registrados desde el mdulo Clientes.
Seleccin de la mquina
Una vez se selecciona un cliente, pulsando el botn de nuevo se cierra el despegable, en las
mquinas disponibles en el despegable correspondiente aparecern nicamente las
mquinas correspondientes a ese cliente.
219
Seleccin 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 especificacin para la correcta ejecucin de algunas de
ellas en las mquinas agentes.
Para pasar entre las distintas tareas con parmetros se pueden elegir en el despegable
superior.
Figura A1.6 Ventana Configuracin de Parmetros para las tareas
Auditora
Se deber seleccionar los campos que se desea que se tengan en cuenta a la hora de
auditar las mquinas. Por defecto aparecen seleccionados los campos que se incluyen en la
auditora para generar alertas.
220
Figura A1.7 Configuracin de Parmetros para auditoras
Los campos definidos se pueden volver a mostrar para modificarlos pulsando el botn
EDITAR PARMETROS. 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 edicin de tareas
Dichos campos vienen definidos en ingls en la pgina principal de la aplicacin WinAudit.
221
Figura A1.9 Pgina de documentacin 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 parmetros de Tareas donde se debe indicar el nombre del
servicio de Windows que se desea iniciar.
222
Figura A1.10 Configuracin de Parmetros para inicio de servicios
Dicho nombre es el que aparece en las propiedades del servicio. Herramientas

Administrativas/Servicios -> Botn derecho sobre un servicio + Propiedades
Figura A1.11 Servicios de Windows
223
Figura A1.12 Propiedades de los Servicios de Windows
Comprobar Cuotas
Esta tarea analiza el tamao 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
Figura A1.13 Configuracin de Parmetros para la tarea Comprobar Cuotas
Ejecutar Script
Debe existir el fichero fsico 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 Configuracin de Parmetros para la tarea Ejecutar Script
225
Seleccin de Hora
Por ltimo se debe indicar una fecha, hora y minuto en la que se desea que la/s mquinas
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 mquina-tarea ser tratada posteriormente como una tarea independiente.
Figura A1.15 Ventana Tareas
Evolucin de las tareas

Para obtener el estado actual de las tareas se puede pulsar el botn ACTUALIZAR.
Al actualizar la lista se volver a cargar las tareas en funcin de los parmetros del filtro.
Editar tarea
La edicin de tareas slo se permite hacer sobre tareas pendientes. Se debe seleccionar la
tarea sobre la columna Sel y pulsar el botn 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
Figura A1.16 Ventana de Edicin de Tareas en modo Editar
La edicin de tareas permite modificar la hora de ejecucin y los parmetros de la tarea si

los tuviera.
Eliminar tarea
Se debe seleccionar la tarea sobre la columna Sel y pulsar el botn eliminar. Se pedir
confirmacin:
Figura A1.17 Confirmacin de Eliminacin de Tareas
227
Tareas Programadas
Siendo un submdulo perteneciente a Tareas se ha presentado como un mdulo ms debido
a la importancia en cuanto a funcionalidad que proporciona.
En este submdulo se gestiona las tareas programadas de Windows asociadas a la

aplicacin de gestin de EvoAgent y que vienen a ser una repeticin peridica de la creacin
de nuevas tareas de forma automatizada.
Se puede acceder a un listado de las tareas programas o directamente a la creacin de una

nueva tarea. Este mdulo interacta con la herramienta de Tareas Programadas del
servidor, con lo que si no se posee de una credencial vlida no se podr acceder y se
mostrar un mensaje informando de dicha circunstancia.
Figura A1.18 Credenciales no vlidas
228
Crear Tarea Programada

Se inicia una ventana para la configuracin de una tarea programada de Windows que
registre peridicamente una o varias tareas para las mquinas que se seleccionen.
Figura A1.19 Ventana de Edicin 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 informacin introducida al tener que abrirla otra vez para
finalizar la creacin 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.
Configuracin de las credenciales de ejecucin 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
Figura A1.20 Ventana de Configuracin de Credenciales de Tarea Programada
Configuracin de la Programacin de la tarea
Figura A1.21 Ventana de Configuracin de la Programacin de la Tarea Programada
Hay que establecer la hora y minuto en que se quiere que las mquinas cliente
seleccionadas ejecuten las tareas a programar, y la fecha de inicio de la tarea.
Asimismo se puede seleccionar una fecha de finalizacin para la tarea programada.
Posteriormente se debe seleccionar un tipo de programacin entre los tres

disponibles en el despegable Programar Tarea:. A continuacin se explica cada
uno de ellos.
230
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:
Programacin Diaria
Esta programacin permite ejecutar tareas todos los das, los das laborables o
siguiendo un intervalo (todos los lunes = cada 7 das empezando un lunes conocido
mejor ver programacin semanal).
Nota Importante: La fecha de inicio debe ser la anterior ejecucin a la que se quiere
que sea la primera. Esto es debido a que el programa de registro automtico 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 das laborables y ahora es
viernes, el programa registra las tareas seleccionadas para las mquinas
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 Configuracin de la Programacin Diaria de la Tarea Programada
231
Programacin Semanal
Esta programacin permite ejecutar tareas los das 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).
seleccionadas ejecuten las tareas seleccionadas, y la fecha de inicio de la tarea.
Nota Importante: La fecha de inicio debe ser la anterior ejecucin a la que se quiere que sea
la primera. Esto es debido a que el programa de registro automtico 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 das laborables y ahora es viernes, el
programa registra las tareas seleccionadas para las mquinas 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 Configuracin de la Programacin Semanal de la Tarea Programada
Programacin Mensual
232
Esta programacin permite ejecutar tareas el da seleccionado de los meses seleccionados.

Si se selecciona Da x siendo x=31 se programar para el ltimo da del mes que
corresponda. Otra opcin es programar para el ltimo/primer/segundo da de la semana:
seleccionadas ejecuten las tareas seleccionadas, y la fecha de inicio de la tarea.
Nota Importante: La fecha de inicio debe ser la anterior ejecucin a la que se quiere que sea
la primera. Esto es debido a que el programa de registro automtico 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 mquinas seleccionadas para
ejecutarse el ltimo viernes del prximo 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 Configuracin de la Programacin Mensual de la Tarea Programada
233
Por ltimo, el apartado de flags hace referencia a Las propiedades con las que se trabaja:
o El inicio de la sesin 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.
o 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 ejecucin
nunca dejar de estar programada para ejecutarse y que en cualquier caso se
puede eliminar la tarea manualmente.
o 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.
Configuracin de Tareas y Mquinas

Para indicarle a la tarea programada sobre qu mquinas se deben registrar las nuevas
tareas y cules 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) slo que en este
caso no es necesario especificar la fecha de realizacin.
Figura A1.25 Ventana de Edicin de Tareas en modo Programar Tarea
Finalizar
Pulsando GUARDAR en la ventana de creacin de tarea programada se comienza el registro
de la tarea programada en el sistema.
234
Configuracin 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 ningn error se cerrar la ventana sin ms.
Ver, Eliminar y Editar Tareas Programadas

Para ver la lista de tareas programadas registradas se debe acceder desde el mdulo 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 creacin de una tarea
programada con la configuracin de la tarea seleccionada desde donde se podr modificar la
configuracin y guardar la nueva tarea programada.
235
Figura A1.27 Ventana de Edicin de tareas programadas
236
Maquinas
Este mdulo permite controlar el acceso de las mquinas al sistema, ver cundo fue la ltima
comunicacin o ver el detalle de las auditoras realizadas de las mismas. Asimismo permite
configurar parmetros como la fragmentacin automtica o el tipo de Agente
(Cliente/Servidor).
Al cargarse se ha inicializado una lista con las mquinas registradas en la aplicacin. Para
mostrarlas se debe realizar una bsqueda.
Bsqueda de mquinas
Una vez cargado el mdulo Mquinas se puede hacer bsquedas de mquinas de dos
maneras:
Por Cliente: Se debe seleccionar un cliente.
Figura A1.28 Ventana de Mquinas
Por Contenido: Introducir texto en el cuadro Maquina y buscar. La bsqueda se

realiza por contenido en los campos Host y Dominio.
Permitir o denegar permiso de acceso de mquinas al sistema

Las mquinas cliente recin instaladas deben de ser permitidas por Evotec para poder
comenzar a ser monitorizadas. Las mquinas ya habrn sido dadas de alta en el sistema.
Una vez localizadas las mquinas seleccionar/deseleccionar sobre la columna permiso
haciendo clic sobre el recuadro y pulsar el botn GUARDAR al final de la fila.
237
Establecer Tipo de Agente

El tipo de maquina que monitoriza un agente viene definido por el campo Tipo Agente. Se
configura de forma automtica en funcin del nombre del host. No obstante se puede
modificar su valor desde el mdulo de mquinas. Se debe localizar las mquinas y abrir el
despegable de la columna Tipo Agente. Seleccionar el tipo deseado y pulsar el botn
GUARDAR al final de la fila.
Establecer Auto-desfragmentacin
El agente puede ordenar la desfragmentacin automtica de los discos de la mquina que
monitoriza en caso de que est configurado para ello. Esto se puede establecer desde el
mdulo de mquinas. Viene definido por el campo Dfrag. Se configura de forma automtica
en funcin del nombre del host. No obstante se puede modificar su valor. Se debe localizar
las mquinas y seleccionar/deseleccionar sobre la columna fragmentar haciendo clic sobre el
recuadro y pulsar el botn GUARDAR al final de la fila.
En cualquier caso una de las tareas que se pueden programar para la mquina es la
desfragmentacin de los discos duros.
Ver detalle de mquinas

Aqu se puede ver el resultado de las auditoras ejecutadas sobre las mquinas cliente.
Primero se debe buscar la mquina en el mdulo mquinas.
Una vez encontrada se debe seleccionar y pulsar el botn VER DETALLE. Se carga una
ventana con un men a la izquierda que contiene todos los campos de la auditora:
238
Figura A1.28 Ventana de Vista de Detalle de Mquina
En el men COMPONENTES de la izquierda aparecern activos aquellos campos que se

hayan incluido en las auditoras realizadas en la mquina. Como defecto se carga en primera
instancia la vista general de la mquina. 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 Mquina
239
Clientes / Dominios
En ste mdulo se pretende gestionar los clientes registrados en el sistema y las mquinas
que tienen asignados cada uno por medio de los dominios a las que estn asociadas.
Figura A1.30 Ventana de Clientes
Al abrir se carga las mquinas, clientes y dominios existentes. Sobre la lista de la derecha
aparecen los dominios junto con el cliente al que estn asociados y en la lista inferior las
mquinas 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
Figura A1.31 Ventana de Clientes. Agregar/Eliminar Clientes
Se puede Aadir o Borrar Clientes del sistema. Pulsar sobre la opcin deseada. Aparecer
una lista de los clientes existentes en el CRM si se desea aadir o de los existentes en el
sistema si se desea borrar:
Figura A1.32 Ventana Seleccin. Seleccin de clientes
Seleccionar el/los clientes a agregar/borrar y pulsar OK.El cliente se aade al despegable de

clientes.
241
Nuevo Dominio
Permite crear un dominio nuevo en blanco para poder asociarlo con un cliente. Para ello se
debe pulsar el botn NUEVO DOMINIO.
Figura A1.33 Ventana de Clientes. Agregar/Eliminar Clientes
Para crear un dominio nuevo slo 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 mquinas agente con los clientes a
los que pertenecen ya que las mquinas cliente proporcionan el nombre del dominio del que
son miembro. Es importante esta asociacin para poder registrar alertas en el CRM con toda
la informacin, incluido el cliente al que pertenece la mquina 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 mquinas que no tienen dominio. Para poder
distinguir entre clientes es necesario asociar las mquinas 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 mdulo Clientes:
242
Seleccionar el Cliente y el Dominio. Pulsar el botn ASOCIAR CLI-DOM. Aparecer en la

lista dominios de la derecha la nueva asociacin:
Figura A1.34 Ventana de Clientes
Asociar/Desasociar Mquinas con Cliente

En este apartado se explica como poder asociar mquinas a un cliente registrado en el CRM
por medio de un dominio conocido o como deshacer dicha asociacin. Para ello se debe
cargar el mdulo Clientes y tener asociado el dominio al que pertenecen las mquinas al
cliente (Ver Asociar Cliente con Dominio).
Desde el mdulo clientes Seleccionar de la lista de la derecha el Dominio al que se quiere

asociar la mquina. Pulsar el botn Asociar Mquinas. Se puede Aadir o Borrar Mquinas
de una asociacin. Pulsar sobre la opcin deseada. Aparecer una lista de las mquinas sin
asociar si se desea aadir o de las existentes en la asociacin si se desea borrar:
243
Figura A1.35 Ventana de Clientes. Aadir/Borrar Mquinas
Figura A1.36 Ventana de Seleccin. Seleccin de Mquinas
Seleccionar las mquinas que se quiere asociar al cliente y dominio y Pulsar OK. La
mquina aparecer asociada al cliente y dominio en la lista de abajo:
244
Figura A1.37 Ventana de Clientes.
Eliminar Dominio
Permite eliminar un dominio. Si dicho dominio a su vez tuviera mquinas 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 botn Eliminar Dominio.

Las mquinas se quedan sin asignar y el dominio desaparece.
245
Log Agentes
En este mdulo 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 mquinas agente: Son errores provocados ante la imposibilidad de

llevar a cabo una accin o por imposibilidad de comunicacin.
Errores en el servidor de la aplicacin: 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 pestaas. La primera pestaa corresponde con las
acciones de los agentes.
Acciones Agentes
Se puede seleccionar una fecha para ver las acciones de un agente en un da 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 mquinas seleccionar
previamente un cliente:
246
Figura A1.39 Ventana de Logs. Acciones de los Agentes
Las acciones aparecen ordenadas por fecha, hora y accin. ste ltima campo describe
brevemente el proceso que lleva a cabo el agente. Van numeradas siguiendo la secuencia
de accin del proceso agente ante el vencimiento del temporizador.
Borrar Acciones
Pulsando sobre el botn 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 mquina en un da o de todos los das.
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 informacin ms reciente se puede cerrar la ventana y volver a cargarla o
se puede pulsar sobre el botn actualizar.
247
Log Errores
Al pulsar sobre la pestaa Errores se procede a cargar los errores registrados. Por defecto
se cargan los errores entre la fecha mnima y la mxima 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 mquina agente debe aparecer rellenados los campos
Mquina y Cliente.
La descripcin completa de los errores se puede obtener pulsando el botn Ver Descripcin.
Asimismo, se puede borrar un error pulsando sobre el botn Borrar. El botn 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 aplicacin, por ejemplo prdida de comunicacin de la mquina cliente, cada de la red,
etc. Puede ocurrir que sea debido a un fallo ante una circunstancia no prevista que requiera
una modificacin en parte de la aplicacin. Dichas posibles modificaciones se contemplan en
la manera de llevarlas a cabo en el manual de explotacin de la aplicacin.
248
Settings
Este mdulo permite controlar parmetros de la aplicacin. Se han definido tres apartados
configurables, alertas, usuarios y versiones de la aplicacin que se explican ms adelante.
Para acceder al mdulo Settings es necesario hacerlo desde el mdulo principal.
Figura A1.41 Ventana Principal. Mdulo Settings
Settings de Alertas
Los parmetros relacionados con las alertas permiten configurar las alertas que generarn
las mquinas cliente, as como el usuario que aparecer como encargado de dichas alertas.
Automticamente se carga la ventana con los valores actuales de los parmetros
establecidos.
Estos parmetros son consultados por el sistema a la hora de generar las alertas.
249
Figura A1.42 Ventana Gestin 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 botn APLICAR de la derecha.
Porcentaje Mximo de Ocupacin de Disco: Indica a partir de que porcentaje de

ocupacin de disco (Espacio Ocupado/Espacio Total) se generara 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 botn APLICAR de la derecha.
Porcentaje Mnimo de Memoria Libre: Indica a partir de que porcentaje de memoria
libre disponible (Memoria Libre/Memoria Total) se generara 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 botn
APLICAR de la derecha.
Tamao Mximo de Cuota: Es el tamao mximo permitido de ocupacin 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 botn
APLICAR de la derecha.
250
Elementos Generadores de Alertas: Hasta este punto se han visto filtros simples
para la generacin de alertas. Existen tres campos que poseen un filtro ms
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 funcin del tipo de agente ya sea PC o servidor. Las
casillas de activacin permiten habilitar o deshabilitar la total generacin de alertas de
ese elemento para ese tipo de agente. Si est habilitado, se podr configurar filtros
especficos para registros del elemento para el tipo de agente elegido, es decir, se
pueden introducir filtros de generacin de alertas por instalacin o desinstalacin de
ciertos programas en los agentes servidor, por ejemplo.
A continuacin se muestra la configuracin de filtros especficos de registros de los

tres elementos:
Filtro especfico de generacin 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 algn 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 Generacin de Alertas de Errores de Windows
251
Filtro Especfico de generacin de alertas por servicios automticos no

arrancados: Al igual que con los errores, al abrir el filtro, aparecern los
servicios automticos no arrancados que se han ido registrando a lo largo de
la vida del sistema.
Figura A1.44 Ventana Filtro de Generacin de Alertas de Servicios
Filtro Especfico de generacin de alertas por programas: Los programas que

contengan en su nombre alguno de los filtros no producir alertas.
Figura A1.45 Ventana Filtro de Generacin de Alertas de Programas
252
Settings de Usuarios
Este apartado permite la actualizacin de los usuarios de la aplicacin y la gestin de

permisos. Los usuarios son obtenidos desde la base de dat0s de la aplicacin CRM por lo
que un nuevo usuario que quiera utilizar la aplicacin debe haber sido registrado en el CRM
antes de actualizar la base de datos del sistema.
Se ha realizado una distincin de dos grupos bsicos de usuarios: User y Admin. El usuario
normal User no tiene acceso a esta ventana de propiedades. Aparecer el siguiente mensaje
si intenta acceder:
La distincin de usuarios slo afecta a sta ventana y la ventana gestin de versiones.

El usuario Admin tiene acceso a toda la aplicacin. Al entrar aparece la siguiente pantalla:
Figura A1.47 Ventana de Gestin 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
Figura A1.48 Ventana de Seleccin. Seleccin 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 opcin:
Figura A1.49 Ventana de Usuarios. Establecer Tipo de Usuario
254
Settings de Versiones
En este apartado se controla las versiones de la aplicacin cliente (versin del agente de las
mquinas cliente). Slo los usuarios pertenecientes al grupo Administradores tienen acceso
a esta ventana. Si un usuario User intenta acceder le aparecer el siguiente mensaje:
Si es un usuario Administrador podr configurar los datos que aparecen en la siguinte

ventana: Para cambiar de versin la aplicacin cliente se debe haber desarrollado el nuevo
paquete de instalacin y haberlo ubicado en una ruta accesible en el servidor tal y como se
explica en el manual de explotacin del sistema.
Figura A1.51 Ventana de Gestin de Versiones
ltima Versin del Cliente: Es la ltima versin de la aplicacin cliente conocida en

el sistema. El sistema comprueba cada una de las versiones de las mquinas cliente
en las comunicaciones con stas contra la ltima versin conocida. En caso de
presentarse una versin antigua en una agente de una mquina el sistema le
proporciona la ruta donde encontrar la ltima versin, mediante el apartado ruta del
repositorio de versiones.
Como mnima indicacin el ejecutable debe contener la versin en el nombre de tal

forma que sea: EvoAgentSetupX.Y.msi siendo X.Y el nmero de la versin (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 botn APLICAR.
Indica una ruta fsica en el servidor donde se ubican los paquetes de instalacin para
poder ser descargados.
255
Alertas
ste mdulo forma parte de la aplicacin de gestin EvoAgentManager pero se ha migrado
su funcionalidad a la aplicacin CRM donde se lleva la gestin de los clientes de la empresa
Evotec para, de esta manera, poder trabajar con las alertas combinndolas con otras
herramientas de trabajo que proporciona dicha aplicacin.
Se va ha proporcionar aqu alguna indicacin de cmo acceder a las alertas en la aplicacin

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.
Cmo empezar
Para acceder a las alertas generadas por el sistema y registradas en el CRM, se debe abrir
dicha aplicacin. Para ello se ha proporcionado un enlace directo desde la interfaz de la
aplicacin de gestin. Se puede observar desde la ventana principal en el men inferior
izquierdo captulo de Referencias. En cualquier caso se puede acceder a la aplicacin
usando los medios proporcionados por la misma para ello, en este caso, mediante Internet
Explorer a la direccin de su ubicacin en la red de la empresa.
Figura A1.52 Ventana Principal de la aplicacin. Mdulo Referencias
Una vez cargada la aplicacin 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
Figura A1.53 Men de la aplicacin CRM. Internet Explorer
Pulsando sobre el botn se cargan las alertas activas existentes. La vista general se
compone de Tipo de alerta, identificador, equipo, fecha y descripcin o detalle. Haciendo
doble clic sobre la alerta se puede empezar a trabajar con ella y aparece ms informacin
como el cliente o detalles relevantes dependiendo del tipo de alerta.
257
Figura A1.54 Aplicacin CRM. Alertas
Figura A1.55 Aplicacin CRM. Formulario de Alerta
258
Desechar Alertas
Con la informacin disponible se puede optar por desechar el evento como alerta y
eliminarlo. Para ello se pude seleccionar las alertas a eliminar y pulsar el botn con un aspa.
Se pedir confirmacin.
Asignar Alertas
Aunque, como se ha visto en el mdulo 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 permitira poder poner un usuario genrico
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 informacin detallada de la
misma. Sobre el men de arriba pulsar la opcin Acciones y Asignar:
Aparece la siguiente pantalla. Si se desea asignar a otro usuario seleccionar la opcin y

pulsar sobre la lupa que aparece al final del recuadro:
259
Figura A1.57 Aplicacin CRM. Asignar Alerta
Aparece otra ventana con los posibles usuarios. Seleccionar el usuario deseado y pulsar
ACEPTAR.
260
Figura A1.58 Aplicacin CRM. Seleccin de Usuarios
Aparece la alerta con el Propietario actualizado. Tambin se puede hacer pulsando

directamente sobre la lupa que hay al final de dicho campo.
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 revisin. Se pueden acceder a ellos a travs 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 mdulo se haya realizado una integracin con dicha aplicacin. Cada
alerta podr generar uno o varios casos para un cliente. El tratamiento de casos es un
apartado correspondiente al CRM y la propia compaa 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 opcin 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 botn Crear Caso.
261
Se abrir una nueva ventana con la informacin del nuevo caso. El caso llevar asociado
una alerta en el apartado Alerta que se seala en la imagen.
FiguraA1.61 Aplicacin CRM. Formulario Edicin de Caso
A partir de aqu se puede trabajar con el caso como un caso ms, asignarlo a un usuario y
resolverlo.
262
Anexo 2. Manual de Explotacin

Este anexo pretende servir de ayuda al administrador del sistema EvoAgent. El sistema
corresponde al gnero de sistemas distribuidos donde la funcionalidad se reparte entre un
servidor de informacin y gestin y un cliente consumidor de servicios bajo tecnologa pull.
Esta metodologa se repite tanto para la aplicacin agente, EvoAgent, que se instala en las
mquinas cliente como para la aplicacin de gestin, EvoAgent Manager, que se instala en
las mquinas de los tcnicos.
Este manual se divide en varios apartados atendiendo primero a la implementacin del

sistema y posteriormente al mantenimiento del mismo. En general se explica la configuracin
del cdigo fuente que genera las distintas aplicaciones y servicios del sistema as como la
forma de trabajar con l y cmo se pueden introducir evoluciones en el cdigo para
aumentar la funcionalidad.
A2.1. Implementacin y Configuracin del sistema
El cdigo fuente del sistema, desarrollado con la herramienta Visual Studio 2005, se
descompone en dos soluciones. Todo el cdigo se encuentra bajo el mismo directorio
EvoAgentProyect:
FiguraA2.1 Directorio del Cdigo Fuente del Sistema
263
Desde aqu se puede abrir una de las dos soluciones haciendo doble clic sobre el archivo
EvoAgentProyect.sln. Para acceder a la otra solucin es necesario entrar en el directorio
EvoAgentService y hacer doble clic sobre el archivo EvoAgentService.sln
FiguraA2.2 Directorio del Cdigo Fuente del Proyecto EvoAgentService
Ambas soluciones se pueden abrir directamente desde el programa Visual Studio 2005.
A2.1.1 Solucin EvoAgentService Programa Agentes

La solucin se compone de tres proyectos de Visual Studio: EvoAgent, EvoIcon y
EvoAgentSetup.
FiguraA2.3 Explorador de Soluciones de Visual Studio. Solucin EvoAgentService
Cada uno de los proyectos posee su propia carpeta en el sistema de directorios como se
ha podido observar en la figura A2.3.
264
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 mquinas 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 mtodos Main(), OnStart() y
OnStop() as como otros mtodos sobrescribibles y otros que se quieran introducir.
El mtodo Main() se ejecuta la primera vez que se inicia el servicio y generalmente

debe contener una llamada explcita a la inicializacin del servicio mediante el mtodo
System.ServiceProcess.ServiceBase.Run() pasando como argumento una
instancia del servicio (llamando al constructor).
El mtodo 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 El identificador de la maquina: lo lee del registro.
o El directorio de trabajo: lo lee del registro.
265
o La referencia al servicio web para conectar con el servidor: El proyecto

contiene una referencia Web al servicio web ControlClientes del mdulo
servidor del sistema. Es en esta clase donde se inicializa la conexin que se
utilizar. Las llamadas a este servicio se realizan mediante la ruta: http:// dir
/EvoAgentServer /ControlClientes /ControlClientes.asmx donde dir indica la
ruta del servidor de Evotec. Se ha configurado para apuntar a un nombre
modificado dinmicamente en el DNS del sistema donde est instalado el
agente. El cname en concreto es evoagentserver. Si no consiguiera
conectarse por cualquier razn utilizando el cname, se utilizara la ruta por
defecto: evoagentserver.evotec.es. Esta accin se hace tambin a la hora de
instalar el programa.
o El tipo de agente: Lo obtiene del servidor si consigue iniciar la comunicacin

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 mtodo IntervaloComunicacin.
Otros mtodos 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 mtodos sobrescritos
Install() y Uninstall(). Tambin 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 parmetros del servicio (tipo de inicio,
nombre y cuenta de usuario) e incluidos en el atributo installers de la clase.
En el mtodo Install() se debe incluir todo el cdigo que se quiere que se ejecute al
instalar el servicio y en el mtodo 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 auditora de la mquina para obtener
el nombre de host y nmero de serie de la mquina para envirsela al servidor,
obtener un identificador nico que ser el identificador de la mquina y almacenarlo
en el registro. Por ltimo, se almacena una ruta en el registro de arranque de la
mquina 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
Otras clases implementan caractersticas propias de la funcionalidad del servicio. La clase

comunicacinServidor posee los mtodos 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 gestin del
log local del agente, que debe utilizarse en el caso de que falle el envo del log al servidor.
Las clases Process sirven de apoyo en la ejecucin de las diferentes tareas.
Por ltimo comentar que la versin del agente instalado en la mquina cliente viene indicada
en el apartado Settings dentro de properties con un setting a nivel de aplicacin. Dicho
setting es el que se utiliza para contrastar la versin del agente con la ltima versin
disponible tal y como se explica en el apartado Gestin 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 aplicacin de Windows. Al iniciarse arranca la clase program

que contiene el mtodo main(). Esta clase arranca la primera ventana de la aplicacin, la
ventana Form1.
La ventana Form1 se mantendr oculta durante toda la vida de la aplicacin. 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 lnea
de cdigo en el mtodo Load.
267
private void Form1_Load(object sender, EventArgs e)

{
this.Hide();
}
Nota: Para que visual Studio genere automticamente dicho mtodo se debe pulsar dos veces sobre la
ventana en el modo diseo.
La ventana posee dos objetos, un NotifyIcon y un ContextMenuStrip. Ambos se pueden

agregar en el modo diseo 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 Diseada 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 instalacin cuyo resultado es un fichero .msi instalable por medio
del programa Windows Installer en sus distintas versiones. El archivo Windows Installer
resultante contiene la aplicacin, cualquier archivo dependiente, informacin sobre la
aplicacin e instrucciones para la instalacin 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
El proyecto incluye una lista de archivos que guardar en el directorio de la aplicacin

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 botn derecho del ratn sobre el nombre del proyecto y pulsar en View
aparecen varias opciones que permiten configurar aspectos de la instalacin:
Sistema de Archivos: Contiene una representacin del sistema de archivos de un

equipo de destino. La organizacin del sistema de archivos puede ser distinta de un
equipo a otro y los nombres de carpeta pueden diferir tambin; 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 aplicacin 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 aplicacin
Figura A2.6 Visual Studio. Sistema de Archivos del proyecto Setup
Haciendo clic en el botn derecho del ratn sobre Application Folder y pulsando
Properties se ven las propiedades de la carpeta de la aplicacin. Aqu se puede
configurar la ruta por defecto en la que se crear la carpeta de la aplicacin con el
tem DefaultLocation. Por defecto se incluye la ruta Archivos de
Programa/Evotec/EvoAgent/
269
Figura A2.7 Visual Studio. Propiedades de la carpeta de la aplicacin
Por otra parte, pueden incluirse condiciones en cualquier archivo o carpeta mediante
la propiedad Condition. Esto permite personalizar la instalacin de archivos en
funcin de las condiciones que existan en el equipo de destino durante la instalacin.
Por ejemplo, puede elegir instalar distintos archivos dependiendo de la versin del
sistema operativo instalada en el equipo de destino. Para obtener ms informacin
sobre las condiciones ir al link: http://msdn2.microsoft.com/es-es/library/2f471fc1.aspx
Interfaz de usuario: Se puede configurar las ventanas que se mostrarn en el proceso

de instalacin mediante las que se puede proporcionar informacin al usuario u
obtenerla de ste. Por defecto no se pretende interactuar con el usuario en el
proceso de instalacin con lo que se han suprimido todas las ventanas posibles.
Figura A2.8 Visual Studio. Configuracin del Interfaz de Usuario de la instalacin 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
instalacin.
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
de que puedan incorporarse a un proyecto de implementacin. Las acciones slo se

pueden ejecutar al final de una instalacin.
El editor contiene cuatro carpetas, que se corresponden con cada fase de instalacin:
Instalar, Confirmar, Deshacer y Desinstalar.
Se ha incluido el resultado del proyecto EvoAgent, es decir, que ejecute el instalador

del servicio Windows en una Instalacin y lo desinstale en una desinstalacin.
Figura A2.9 Visual Studio. Acciones Personalizadas del proyecto Setup
En el evento Commit, al confirmar la instalacin se ha incluido un script desarrollado

en visual Basic Scripting que inicia el servicio instalado. Para agregar acciones se
debe hacer clic con el botn 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 ejecucin del cdigo. Hay
mltiples condiciones configurables en funcin de las propiedades de la instalacin,
del sistema o de otros aspectos. En este caso se ha configurado una condicin en la
instalacin del servicio de Windows:
Figura A2.10 Visual Studio. Condicin para la ejecucin de la accin personalizada.
271
La condicin establece que el servicio de Windows se instale si Windows Installer no

encuentra una versin anterior de la aplicacin instalada. Esto evita que Windows
Installer desinstale y vuelva a instalar el servicio aunque correspondan a distintas
versiones del mismo. Adems, en Visual Studio 2008, por defecto, el paquete de
instalacin fuerza a que se instale la aplicacin antes de desinstalar la antigua lo que
provoca un error al encontrarse con un servicio existente. Con la condicin
comentada se evita el error. Para saber ms acerca de cmo actualizar el servicio de
Windows mediante este proyecto ver el apartado A2.2.2.
Es muy importante mencionar las propiedades del paquete de instalacin. Al hacer clic con
el botn derecho del ratn sobre el nombre del proyecto y pulsar en Properties aparecen las
propiedades del paquete de instalacin.
Figura A2.9 Visual Studio. Propiedades del proyecto Setup
272
En este apartado se han configurado varios aspectos importantes que se deben tener en
cuenta:
Instalacin para todos los usuarios:
InstallAllUsers = true;
Gestin de Versiones: La gestin de versiones se controla con los campos UpgradeCode y

ProductCode. Las diferentes versiones (ProductCode) de un mismo sofware (UpgradeCode)
se modifican automticamente al cambiar el atributo Versin. Se debe tener en cuenta que
para que funcione la primera versin debe ser 1.0.0. Ver apartado A2.2.2.
DetectNewerInstalledVersion = true; Si encuentra una versin ms moderna del

software a instalar rechaza la instalacin.
RemovePreviousVersions = true; Desinstala una versin anterior del software si

estuviera instalada. Esto, como se ve en el link http://msdn2.microsoft.com/es-
es/library/y63fxdw6.aspx no ocurre con los paquetes generados en Visual Studio
2008.
Para ms informacin sobre las propiedades de un proyecto de instalacin consultar el link:

http://msdn2.microsoft.com/es-es/library/seykw6dt.aspx.
A2.1.2 Solucin EvoAgentProyect

La solucin se compone de 6 proyectos de los cuales existe una aplicacin web, una
aplicacin de escritorio, una aplicacin de consola, una librera y dos instaladores.
Figura A2.10 Visual Studio. Solucin EvoAgentProyect
273
Proyecto EvoAgentLibrary
Se trata de un proyecto de librera 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
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 estn definidas la clase CredencialesUsuario utilizada por la aplicacin de
gestin EvoAgentManager para realizar el login contra el servicio web y la base de
datos, la clase InterpreteProgramacionTareas utilizada por la aplicacin de gestin
EvoAgentManager para gestionar la creacin y lectura de tareas programdas, la
clase ControlNuevaAuditoria utilizada por la aplicacin Web EvoAgentServer para
gestionar la creacin de Alertas y la clase LeerAuditoriaXML utilizada para leer los
ficheros XML de auditoras para mostrar el detalle de las mquinas en la aplicacin
de gestin y para realizar el control de la auditora en la aplicacin Web.
References: Aqu se incluye la referencia a la librera TaskScheduler necesaria para

la gestin de tareas programadas.
WebReferences: Se incluyen aqu las referencias a los servicios web: el servicio Web
de Administracin 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 conexin a las dos bases de datos, la direccin 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 aplicacin de Windows que posee el interfaz grfico de usuario para los
tcnicos. El documento Manual de Usuario muestra toda la funcionalidad de la aplicacin.
La ventana Form_Main es la primera ventana de la aplicacin. Mediante esta ventana se

puede acceder al resto de la aplicacin.
La aplicacin 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 librera del sistema.
275
Figura A2.12 Visual Studio. Proyecto EvoAgentManager
Proyecto EvoAgentServer
Se trata de una aplicacin ASP.NET Web Services Application que contiene el mdulo
servidor del sistema. Contiene una referencia al proyecto EvoAgentLibrary para acceder a la
librera del sistema.
Se distinguen dos directorios que formarn el sitio web, ControlClientes y AdminManager.
Cada uno de ellos debe tener un mtodo de autenticacin diferente. Se procede ahora a
explicar cada uno de los componentes de los directorios:
276
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 autenticacin bsica. Mediante
Internet Information Server se puede configurar un usuario annimo que
represente a todos los accesos annimos que se reciba. El sistema realiza la
autenticacin de los accesos en el nivel de aplicacin accediendo a la base de
datos.
Por otro lado contiene el directorio donde se alojarn los ficheros que deban
descargarse los agentes, Repositorio. Dicho directorio se utiliza para la gestin de
versiones.
AdminManager: Es el directorio que contiene el servicio web ControlAdmin.asmx.

al que accede la aplicacin de gestin EvoAgentManager. El directorio debe tener
habilitada la autenticacin basada en Windows para que slo 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
gestin de las tareas programadas. Como se ve en la figura contiene 3 directorios
para cada uno de los elementos mencionados. El usuario annimo definido en el
punto ControlClientes debe tener acceso de escritura sobre los directorios
Auditorias e Incidencias para poder escribir las auditoras e incidencias que recibe
de los clientes.
277
La aplicacin Web reside en un directorio virtual al que hace referencia el sitio web definido
en el Servidor Web. En concreto, la aplicacin web en el entorno de produccin reside en el
directorio \\evtsrv01\Inetpub\EvoAgentServer\ y es ah donde se debe publicar. Para publicar
una aplicacin web pulsar el botn derecho del ratn 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
cdigo que necesita la aplicacin para funcionar.
Proyecto ProgramacionTareas
Se trata de una aplicacin de consola que interpreta las tareas programadas para registrar
tareas en la base de datos para su realizacin 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 funcin Main() y funciones de interpretacin auxiliares. En
References existe una referencia al proyecto EvoAgentLibrary a travs de la cual utiliza la
librera 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 aplicacin se debe desplegar en el subdirectorio TareasProgramadas del directorio

AdminiManager del sitio web de la aplicacin 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 instalacin de la aplicacin EvoAgentManager. El proyecto contiene la
referencia al proyecto EvoAgentManager (Proyect Output). Se ha establecido la ruta por
278
defecto de instalacin de la carpeta Application Folder en

%Programfiles%\Evotec\EvoAgentManager y se ha suprimido la interaccin con el usuario.
Como se ve la imagen, se ha aadido un acceso directo (shortcut) en el men de programas.
Figura A2.14 Visual Studio. File System del Proyecto EvoAgentManagerSetup
A2.1.3 Gestin 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 conexin de confianza:
Figura A2.15 Conexin de Confianza con el Gestor de Bases de Datos

279
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
copiarn.
Descripcin de las tablas de datos
Aqu se incluye una descripcin 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 gestin 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
T_Cliente: Almacena los clientes agregados al sistema mediante la aplicacin

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 Razn Social.
T_Dominio: Almacena la informacin de dominios existentes en los clientes. Lo normal

es asociar un dominio para cada cliente pero pueden asociarse ms. Se identifican
mendiante un Guid creado por el sistema y se registran automticamente al dar de alta
una mquina o manualmente desde la aplicacin 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
Gestin de Alertas en la aplicacin EvoAgentManager.
T_ErrorAplicacion: Almacena la informacin de los errores ocurridos en el sistema o en

las actividades de los agentes. La descripcin 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 automticamente en la tabla
incluyendo los datos reflejados en los campos que son obtenidos mediante la clase
EventLogEntry de System.Diagnostics. Ver la documentacin relacionada en
http://msdn2.microsoft.com/es-
es/library/system.diagnostics.eventlogentry_members(VS.80).aspx
Adems, 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
Gestin de Alertas en la aplicacin EvoAgentManager (Ver Manual de Usuario).
T_FiltroAlertaProgramas: Almacena las cadenas de caracteres que sirven de filtro para

la generacin de alertas relacionadas con la instalacin/desinstalacin de programas. Se
configuran desde la Gestin de Alertas en la aplicacin EvoAgentManager (Ver Manual
de Usuario).
T_FiltroAlertaServicios: El sistema registra automticamente el nombre de los servicios

automticos que no se han iniciado para cualquier mquina. Se incluye dos campos que
indican, para cada servicio, si se registran alertas para origen PC o Servidor
respectivamente y son configurados desde la Gestin de Alertas en la aplicacin
EvoAgentManager (Ver Manual de Usuario).
281
T_MaqAccion: Se registran automticamente las acciones realizadas por los agentes.

Se pueden acceder y borrar desde el mdulo Logs de la aplicacin EvoAgentManager.
(Ver Manual de Usuario).
T_MaqAuditoria: Almacena la informacin de las auditorias realizadas por los agentes.

La auditora en si se obtiene del subdirectorio Auditorias de AdminManager donde estn
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 mquinas cliente obtenidos por el

agente en la auditora para no repetir el registro de alertas con errores que ya se han
registrado.
T_MaqPrograma: Almacena los programas instalados en las mquinas cliente

obtenidos por el agente en la auditora para obtener las instalaciones de nuevos
programas y desinstalaciones para la generacin de alertas.
T_MaqTarea: Tabla utilizada para almacenar las tareas que se programan para los
agentes mediante el mdulo tareas en la aplicacin EvoAgentManager. Se alamcena un
identificador de tarea para la maquina que identifica cada una, un identificador de
mquina que identifica la mquina y, por tanto, el cliente para el que se programa la
tarea y un identificador de tarea que identifica la tarea programada y su descripcin. Se
registra el estado de la tarea y los parmetros necesarios para ejecutar la misma as
como la fecha de ejecucin para la que se program. Mediante el identificador de
mquina 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 aplicacin con el formato id, descripcin y valor. En

concreto se almacena el Valor de la ltima versin del programa agente disponible, la
ruta del repositorio y los filtros de generacin 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
T_UsuarioAplicacion: Almacena los usuarios agregados al sistema mediante la

aplicacin EvoAgentManager (Ver Manual de Usuario, Gestin de Usuarios) y que tienen
acceso a la aplicacin 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 sesin 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 mdulo logs de la aplicacin
EvoAgentManager.
o La tabla T_MaqError que almacena los errores del log registrados en las mquinas
indefinidamente.
Por lo dems 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 aplicacin en el log de
errores desde la aplicacin EvoAgentManager. Las auditoras obtenidas, por ejemplo, son
almacenadas tras machacar auditorias antiguas que poseen los mismos campos de forma
automtica, por lo que no se requiere ninguna accin y el resto de tablas mantendrn un
nivel estable y proporcional al nmero de mquinas 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 ubicacin dentro
del disco donde se crear el fichero .bak de recuperacin.
Para restaurar una base de datos desde un fichero de recuperacin 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 conservarn los datos.
283
Figura A2.17 Acceso a la utilidad Backup desde el programa Management Studio Express
Figura A2.18 Configuracin del Backup de la base de datos.
284
A2.2. Mantenimiento y Evolucin del sistema
A2.2.1 Desarrollo de Nuevas Tareas

Este apartado pretende servir de gua para el diseo de nuevas tareas a realizar por los
agentes. Este proceso pasa por varias fases que se describen a continuacin.
Las tareas son acciones que pueden realizar los programas agente. Son programadas desde
la aplicacin de gestin para ser ejecutadas por la aplicacin agente. Se registran en la base
de datos y se comunican al agente cuando este realiza la solicitud asocindolas a ste
mediante un id de mquina. Las tareas a realizar por los agentes pueden requerir de
argumento en cuyo caso ste debera poder presentarse como una cadena de texto para su
envo a travs de la red hasta los agentes. Se podra 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
visin global de lo que implica disear una nueva tarea y de los distintos puntos de vista
desde los que se pueden afrontar esta accin, 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 estn registradas en la base
de datos y es necesario escoger un identificador que no este ya asociado a otra tarea. Se
puede registrar esta informacin 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 configuracin de la tarea con nmero identificador y nombre ya que se
utilizar en el resto de puntos de este apartado. Esta accin debera 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 continuacin se muestra una imagen del contenido de la tabla T_Tarea desplegada en el

programa Sql Server 2005 Studio Management Express:
285
Figura A2.19 Registro de nueva tarea en la base de datos
Desarrollar la tarea en el cdigo del agente

Las tareas son diseadas para ser ejecutadas por los agentes. Es necesario, por tanto,
desarrollar la ejecucin de la tarea en el cdigo de la aplicacin agente. Para ello es
necesario conocer la estructura del cdigo:
El control de tareas se realiza en cada intervalo de comunicacin, en concreto, en el mtodo

ControlTareas de la clase EvoAgentService. Para agregar una tarea nueva sera necesario
introducirla en una nueva clusula case dentro del bucle switch(). La clusula ser:
case "numero identificador de tarea":
{Cdigo desarrollado para ejecutar la tarea en la mquina y registrar resultados en el sistema.}
break;
Donde pone cdigo desarrollado para ejecutar la tarea se debe incluir el cdigo que
permite ejecutar la nueva tarea diseada. Si se requiere del registro de algn resultado en el
sistema, habr que incluir los pasos para la comunicacin segn se explica en el siguiente
punto.
En este punto del cdigo 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 ejecucin de la tarea se debe construir un vector bajo el
nombre de TareaRealizada donde se indica el resultado de la ejecucin de la tarea.
286
Dicho vector est compuesto por tres strings que indican el id de la tarea, la fecha de
ejecucin y el resultado. Su creacin 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 algn

error en la ejecucin.
Parmetro: Viene indicado en ProxTarea[2]. Para las tareas que requieran de un

parmetro.
El cdigo puede desarrollarse en una nueva clase incluyendo una llamada a la misma o en
esta seccin. Una vez desarrollado el cdigo e introducido como se ha indicado, el agente
estar listo para poder ejecutar la nueva tarea.
Registrar resultado de ejecucin de la nueva tarea en el sistema

Por ejemplo, la tarea Auditora registra la nueva auditora en el sistema, a lo que sigue un
control de la misma iniciado por el mdulo servidor para la generacin 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:
Mtodo Web en el Servicio ControlClientes del subsistema EvoAgentServer
Se debe incluir un nuevo mtodo web en el servicio web ControlClientes. Para ello, desde
la solucin 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 botn derecho sobre el fichero y pulsar ver cdigo.
Se abrir el cdigo fuente del servicio web que contiene los mtodos web a travs 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
Ser necesario incluir un nuevo WebMethod para recibir el resultado de la nueva tarea. El
mtodo web debe contener una comprobacin de la identidad del agente que se comunica.
En el siguiente ejemplo de cdigo se ha creado un mtodo web que recibe el identificador
del agente que quiere realizar el registro y el resultado a registrar. Realiza la comprobacin
de identidad del agente mediante la ejecucin del mtodo
MaquinaDao.validaMaquina(idMaquina) que comprueba que la mquina est registrada y
tiene permiso. El mtodo web devuelve un valor booleano en funcin de si se ha registrado
en el sistema el resultado sin problemas o no. Se puede crear un mtodo para que devuelva
cualquier valor. Igualmente, el argumento del mtodo debe contener lo que se quiere
registrar si bien se ha de saber que un mtodo web puede recibir slo variables primitivas del
tipo cadenas de caracteres, vectores y dataSets que contengan texto plano que es lo
utilizado para enviar las auditoras. El registro debera 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 solucin que se estime ms
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 aplicacin (definido en
el dominio) y registrndolo 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 mtodo, para registrarlo en el servidor se debe publicar tal y como se
indica en el apartado Proyecto EvoAgentServer del apartado A2.1.
288
Mtodo en la clase ComunicacionServidor del agente:
La clase comunicacionServidor definida en el agente posee todos los mtodos a travs 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 mtodo 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
mtodo web creado.
En la clase ComunicacinServidor se deber crear un nuevo mtodo que registre el

resultado de la nueva tarea utilizando una llamada al mtodo web creado. Utilizar la clase
ConfigAgente mediante su objeto instanciado _Config para llamar al servicio web y a su
nuevo mtodo web y tambin para obtener el identificador del agente que debe enviar como
primer argumento de la llamada. Debe seguirse el cdigo 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 mtodo debera ser llamado al terminar la ejecucin de la nueva tarea por parte del
agente pasando el resultado que se quiere registrar en el sistema de dicha ejecucin en un
formato adecuado.
Incluir la tarea en la aplicacin de gestin para su programacin

En este paso se va ha ver qu se debe hacer para poder programar la nueva tarea para su
ejecucin por los agentes.
Si la tarea no necesita de ningn argumento para ejecutarse no ser necesario realizar

ningn cambio en esta aplicacin.
289
En cambio, si necesita de un argumento para ejecutarse ser necesario realizar

modificaciones en el cdigo de la aplicacin EvoAgentManager en las clases
Form_ParametrosTareas y Form_NuevaTarea para poder configurar dicho parmetro.
Clase Form_ParametrosTareas:
Se trata de la ventana utilizada para configurar los parmetros de cualquier tarea. Lo primero
es disear el interfaz mediante el cual se indicar el parmetro. Cuando se seleccione la
nueva tarea se presentar al usuario esta ventana para que pueda introducir el parmetro.
Se puede disear mediante un cuadro de texto o lo que sea necesario para poder configurar
el parmetro. Esto se debe introducir en un control nuevo GroupBox como el que se ve a
continuacin.
Figura A2.20 Diseo del parmetro de la nueva tarea
El groupBox deber llevar un nombre representativo de la nueva tarea. Se disear

colocando el nuevo GroupBox sobre el ltimo que hay diseado e introduciendo en su
interior lo necesario para configurar el parmetro.
En cuanto al cdigo ser necesario lo siguiente:
Mtodo CargarTareas(). Mediante ste mtodo se indica a esta ventana que tareas
se van a configurar. Se obtiene como atributo las tareas y en funcin del nombre de
la tarea se muestra el GroupBox diseado para la configuracin del parmetro de la
tarea en cuestin. Aqu hay que aadir una nueva clusua 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

auditora
this.checkedListBox1.SetItemChecked(0, true);
290
}
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 debera incluir como mnimo lo siguiente:
else if (t.sDescripcion == "nombre de la tarea")

{
this. nombre del nuevo groupBox.Visible = true;
this. nombre del nuevo groupBox.BringToFront();
}
Tambin se podra incluir el relleno de valores por defecto tal y como se ve en el caso de la
auditora.
Nuevos Mtodos get y set. Se deben configurar sendos mtodos para obtener y
configurar el valor del parmetro. En la clase se puede ver ejemplos de stos
mtodos para otras tareas.
El mtodo get-NuevaTarea-() sigue el formato:
public string get-NuevaTarea-()

{
{Obtener valor del parmetro}
Return valor del parmetro;

}
Se debe devolver el valor del parmetro como una cadena de texto. Se realizarn las
operaciones oportunas para convertir la configuracin del parmetro en una cadena
de texto.
El mtodo set-NuevaTarea-() sigue el formato:

291
public void set-NuevaTarea-(string valor del parmetro)

{
{Configurar valor del parmetro}
}
Se obtiene el prametro en formato string y se requiere establecer el valor

actual utilizando los elementos diseados para su configuracin (Si es un
cuadro de texto escribir directamente el valor)
Mtodo comboBox1_SelectedIndexChanged(): en este mtodo se controla la

interaccin del usuario con el comboBox de seleccin de tareas. Como se ha
comentado, esta ventana permite configurar todos los parmetros 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 parmetros no
necesitar de ninguna modificacin en la interfaz. Sin embargo, para una tarea que requiere
de la configuracin de parmetros es necesario realizar las siguientes modificaciones:
Variable Config: Todas las tareas que requieren de parmetros 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
Mtodo setTareasProgramacion(): Mediante est mtodo se establecen las

tareas que han sido configuradas en una tarea programada para poder ser
modificadas. Puede haber sido configuradas tareas que requieren de parmetro con
lo cual se debe habilitar la ventana de configuracin de parmetros. Esto se
comprueba al final del mtodo en la sentencia if:
if (activar_parametros)
292
{
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]);
this._parametros.setSeleccionCuota(selecciones[i]);
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 mtodo set creado en la clase Form_ParametrosTareas.
Mtodo buttonTarea_Click(): Este mtodo se utiliza para controlar la seleccin

de tareas. Si se ha seleccionado tareas que requieren de parmetros se deber
mostrar la ventana Form_PropiedadesTareas. Para ello sirve la variable Config
creada anteriormente. El cdigo del mtodo 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
}
if (this.ConfigServicio == 1)
{
if (tareas == null)
tareas.Add(new Tarea(4, "InicioServicio"));
}
if (this.ConfigCuotas == 1)
{
if (tareas == null)
tareas.Add(new Tarea(5, "ComprobarCuotas"));
}
if (this.ConfigScript == 1)
{
if (tareas == null)
tareas.Add(new Tarea(7,"EjecutarScript"));
}
En este punto sera necesario incluir lo siguiente:
if (this.Config-NuevaTarea == 1)
{
if (tareas == null)
tareas.Add(new Tarea(numero identificador de tarea, "nombre de la tarea"));
}
Mtodo comboTarea_SelectedIndexChanged(): Este mtodo se utiliza para

cambiar el valor de las variables config, segn se ha seleccionado o no la tarea en
cuestin, que se comprueban en el mtodo 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 atencin en que tenga un nombre diferente, por ejemplo con c minscula:
bool config-NuevaTarea= false;
Un poco ms abajo, en el bucle for incluir una nueva sentencia else if despus de
la ltima que hubiera:
else if (this.comboTarea.CheckedItems[i].ToString() == "nombre de la

tarea") { config-NuevaTarea= true; }
294
Por ltimo, debajo del bucle for incluir una comprobacin 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;
Mtodo archivoToolStripMenuItem_Click(): Este mtodo se utiliza para guardar

la/s tarea/s configuradas mediante una llamada a la capa de datos. Antes debe
obtener los datos de configuracin de las tareas a guardar. Si se trata de la edicin
de una tarea se obtienen en este mtodo. As, en la seccin correspondiente, se
comienza comprobando si la tarea a editar tena parmetros para, en caso de
tenerlos, obtenerlos. Como se ve en el cdigo de abajo, esto se hace mediante
llamada al mtodo 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._parametros.getSeleccionServicio();
this._parametros.getSeleccionCuotas();
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();
Mtodo getNewTareasMaquina(): Este mtodo se utiliza para obtener la

configuracin de las nuevas tareas a guardar.
Dentro del doble bucle foreach:
if (m.idCliente == null)
{
tareasMaquina.Add(new TareaMaquina());
295

{
MaquinaDAO.setRutaCuotas(m.idMaquina,
this.parametros.getSeleccionCuotas());
}
else
}
else
{
{
MaquinaDAO.setRutaCuotas(m.idMaquina,
this.parametros.getSeleccionCuotas());
}
else
}
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 mtodo se separa en dos bloques dependiendo de si la

mquina seleccionada tiene un cliente asociado o no. Esto es as, porque en caso de
no tenerlo la tarea tendra que tener valor nulo en cliente explcitamente. Los dos
bloques son pues prcticamente iguales con la nica diferencia de que en la creacin
de la tarea se incluye o no el valor del cliente. Tambin se ve que el ltimo else de
cada bloque incluye a todas las tareas que no tienen parmetros. Por tanto, se debe
incluir en cada bloque y entre el ltimo else if y el ltimo else, lo siguiente:
En el primer bloque:

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
En el segundo bloque:

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")
);
Mtodo _parametros_Disposed(): Este mtodo se utiliza para de-seleccionar las

tareas que requieren de parmetros si se cancela la configuracin de los parmetros
(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;
}
Mtodo editarToolStripMenuItem_Click(): Este mtodo se utiliza para mostrar

la ventana Form_ParametrosTareas siempre que se quiera al pulsar sobre el botn
editar parmetros. Cuando se est editando una tarea, al pulsar sobre este botn se
crea de cero la ventana y es preciso establecer el valor de configuracin del
parmetro. 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 cdigo de la aplicacin agente para que ste
pueda ejecutar una nueva tarea. Adems, tambin se han visto posibles modificaciones en el
cdigo fuente de la aplicacin agente para registrar el resultado de dicha tarea en el sistema.
El cambio en el cdigo fuente comprende que el agente deba evolucionar a una nueva
versin para poder utilizar la herramienta de actualizacin automtica del mismo.
Esto implica que los agentes actualicen su cdigo fuente obteniendo la nueva versin del
servidor. Todo esto se explica en el punto A2.2.2 Gestin de Versiones.
297
Actualizar la aplicacin EvoAgentManager para que los tcnicos puedan programar la

nueva tarea.
Este paso no sera necesario si no se ha tocado el cdigo fuente de la aplicacin, es decir, si
no es necesario configurar un parmetro para la ejecucin de la nueva tarea.
Si se ha realizado alguna modificacin en el cdigo, ser necesario actualizar los programas

EvoAgentManager de los ordenadores de los tcnicos. No se ha desarrollado un sistema de
actualizacin automtica para este programa por lo que ser necesario que los tcnicos
desinstalen e instalen la nueva versin del programa. Para ello colgar la nueva versin en la
red de forma que los tcnicos tengan acceso a ella.
A2.2.2 Gestin de Versiones de la aplicacin Agente

En este apartado se muestra como funciona el sistema de actualizaciones automticas de la
aplicacin agente y como llevar a cabo la actualizacin de los agentes a una versin
posterior en un momento dado. Para ello se explica previamente el funcionamiento de
Windows Installer y de los proyectos de instalacin. Consultar tambin el apartado Proyecto
EvoAgentSetup de este documento.
Windows Installer y Proyectos de Implementacin de aplicaciones

Windows Installer es un servicio de Instalacin y Configuracin de aplicaciones que trabaja
junto con el sistema operativo. Mantiene una base de datos con informacin sobre cada una
de las aplicaciones que instala, incluyendo archivos, claves del registro y componentes.
Esto hace que mediante un proyecto de instalacin se pueda gestionar la actualizacin de

una aplicacin utilizando para ello las propiedades del proyecto de instalacin Version,
UpgradeCode y ProductCode.
Para que Windows Installer compruebe la existencia de versiones anteriores en el sistema y

lo tenga en cuenta durante la instalacin se debe poner a true la propiedad
RemovePreviousVersions. Dicha propiedad funciona de distinta manera dependiendo de la
versin de Visual Studio con la que se trabaje como se puede ver en el link:
http://msdn2.microsoft.com/es-es/library/y63fxdw6.aspx.
En Visual Studio 2005 al encontrar una versin anterior de la aplicacin (Mismo

UpgradeCode, Diferente ProductCode y Menor Version) se llamaba a las acciones
personalizadas como se muestra a continuacin:
v1.0.0 custom action Uninstall()
v1.0.1 custom action Install()
En los paquetes de instalacin creados con Visual Studio 2008, la accin de desinstalacin
no es llamada, tratando solamente la instalacin. En la instalacin consulta la base de datos
298
de Windows Installer para saber los ficheros que contena la antigua versin de una
aplicacin y compararlos con las que contiene el paquete que est instalando. As, puede
modificar los ficheros que han cambiado de una versin a otra.
Es importante asegurar que ningn fichero que deba ser sustituido este en uso para evitar
que Windows Installer provoque un reinicio de la mquina al finalizar la instalacin.
Configuracin del Proyecto de Instalacin EvoAgentSetup para las actualizaciones
Dado que se trabajar en un futuro con Visual Studio 2008 se hace necesario determinar
una configuracin apropiada del proyecto de instalacin para gestionar las versiones del
programa agente. Del ltimo prrafo del punto anterior se extrae la conclusin de que ante
una actualizacin se producir un error al instalar el servicio de Windows EvoAgentService
debido a que no se desinstala la aplicacin del servicio correspondiente a la versin 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 versin anterior. Para ello se acude a las acciones personalizadas y en la fase de
instalacin, en la accin de instalacin del servicio (Primary output from EvoAgent(Active)) se
incluye la condicin NOT PREVIOUSVERSIONSINSTALLED sobre el cuadro de
propiedades.
299
Figura A2.21 Condicin de instalacin del programa EvoAgent
Para configurar la siguiente versin de la aplicacin, en el paquete de instalacin es

necesario modificar la versin 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 versin. Visual
Studio propondr la modificacin automtica del cdigo de producto (ProductCode). Pulsar
SI.
Configuracin del Sistema para las actualizaciones

Hasta aqu se ha visto como se ha configurado el paquete de instalacin mediante el
proyecto de instalacin y que modificaciones se han de realizar en el mismo para obtener un
paquete de instalacin que actualice el programa agente existente.
300
Por otro lado, como se pretende que los agentes se actualicen automticamente es
necesario configurar el sistema para controlar las actualizaciones.
La aplicacin agente tiene un atributo o setting que le indica la versin de su cdigo. Dicho
setting tiene su anlogo en el sistema que indica la ltima versin disponible de la aplicacin
agente. Los agentes consultan la versin disponible en cada comunicacin con el servidor.
Si un agente encontrara en una consulta que existe una versin diferente (no menor o
mayor), procedera a solicitar al servidor la nueva versin de la aplicacin.
El servidor deber proporcionar al agente una ruta desde donde bajarse la nueva versin.
Con nueva versin, se entiende, un paquete de instalacin 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 aplicacin de gestin:
Figura A2.22 Configuracin de los settings de Gestin de Versiones en el programa EvoAgentManager
La versin que indica el setting de la aplicacin agente se corresponde con la versin que se
configura en el paquete de instalacin. Para introducir la nueva versin 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 aplicacin EvoAgent
301
Uno de los settings que aparece como string con el nombre de Version contiene en la
columna Value el valor de la versin actual de la aplicacin. Introducir la nueva versin de la
aplicacin, la misma que se ha introducido en el paquete de instalacin, en el apartado
anterior:
Figura A2.24 Settings de la aplicacin EvoAgent
Por otro lado el programa Icono muestra la versin actual al pasar el ratn por el icono o al
abrir las propiedades. Por tanto, es necesario actualizar la versin tambin 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 diseo y abrir las propiedades. Modificar la versin en
la propiedad Text que se ve en la siguiente figura:
302
Figura A2.25 Configuracin de la versin en el Icono 1
Para modificar la versin en el cuadro Acerca de que proporciona una descripcin 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
Figura A2.26 Configuracin de la versin en el Icono 2
Una vez actualizadas las versiones faltara adaptar las versiones de los ficheros que
contiene cada aplicacin. 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
cdigo del ensamblado del agente debe reflejarse en. Para acceder a la versin de los
ficheros hacerlo desde las Properties de cada proyecto, EvoAgent y EvoIcon:
Figura A2.27 Properties del proyecto EvoAgent
304
Pulsar en Assembly Information y, en la ventana que se abre, actualizar la versin de los

ficheros (File Version):
Figura A2.28 Assembly Information del proyecto EvoAgent
Una vez actualizadas todos los indicadores de versin, compilar primero los proyectos
EvoAgent y EvoIcon y despus el proyecto EvoAgentSetup. El resultado de esto ltimo crea
un paquete de Windows Installer que contiene la nueva versin de la aplicacin Agente. Para
que los agentes obtengan la nueva versin se debe modificar el setting del sistema que
indica la ltima versin disponible como se ha visto en la figura A2.22. Los agentes
comprobarn que existe una nueva versin disponible y le solicitarn la ruta desde donde
bajar la nueva versin. 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
Figura A2.29 Paquete de Instalacin 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
ubicacin fsica del directorio virtual en el Servidor, actualmente:
evtsrv01\InetPub\EvoAgentServer.
Por ltimo, y como se ver ms adelante es necesario modificar el nombre del fichero. El
nombre debe ser: EvoAgentSetupV.V.msi donde V.V es la versin de la aplicacin.
Si se trata de una actualizacin a la versin 1.2, por ejemplo, el nombre del fichero creado
ser EvoAgentSetup1.2.msi y el nmero de versin introducido en todos los pasos hasta
ahora ser 1.2.
El cdigo del agente es el que se encarga de iniciar el proceso de comprobacin de versin

y actualizacin mediante descarga y ejecucin del paquete de instalacin. Para ello, en el
cdigo de la clase EvoAgentService.cs, en el mtodo de Intervalo de comunicacin se ha
incluido una llamada al mtodo ComprobarVersion de la clase ComunicacionServidor que se
observa a continuacin:
306
public bool ComprobarVersion()

{
bool versionOK = true;
try
{
versionOK = _Config.webService.VersionAgenteOK(
_Config.idMaquina, Properties.Settings.Default.Version);
}
catch (Exception e)
{
}
return versionOK;
}
Como se puede ver, el mtodo llama a un mtodo 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 parmetro el identificador de la
mquina, propiedad de la misma clase y el setting Versin de la aplicacin.
A continuacin se muestra el cdigo del mtodo web que recibe dichos parmetros,
comprueba la validez del identificador de la mquina recibido y contrasta la versin recibida
con el setting del sistema que indica la ltima versin disponible.
[WebMethod]
public bool VersionAgenteOK(string idMaquina, string versionAgente)
{
bool versionOK = true;
try
{
{
string version_actual = SettingsDAO.getValorSetting(5);
if (version_actual != versionAgente)
versionOK = false;
}
}
catch (Exception e)
{
//Registro de error
}
return versionOK;
El mtodo devuelve un valor booleano que indica si la versin recibida es igual o no a la

ltima versin disponible. De la misma manera, el mtodo ComprobarVersion anterior
tambin devuelve un valor booleano. En caso de ser igual a false, el agente llama al mtodo
InstalarUltimaVersion de la propia clase EvoAgentService que se ilustra a continuacin.
307
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 versin");
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 instalacin de la ltima

versin");
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 mtodo anterior se encarga de gestionar el proceso de descarga y ejecucin del

instalador. Para ello, la primera accin es obtener la ruta del repositorio de donde
descargarse el archivo. Como se ha comentado se obtiene de un setting del sistema a travs
del servidor. Como de costumbre se utiliza un mtodo en la clase ComunicacionServidor que
realiza la llamada a un mtodo web del servicio ControlClientes:
308
public string getRutaRepositorio()

{
string URL = null;
try
{
URL = _Config.webService.getRutaRepositorio(_Config.idMaquina);
}
catch (Exception e)
{
}
return URL;
}
[WebMethod]
public string getRutaRepositorio(string idMaquina)
{
string ruta = "0";

try
{
ruta = AjustaCadena.AjustaNPalabras( SettingsDAO.getValorSetting(6))

+ "EvoAgentSetup" + AjustaCadena.AjustaNPalabras(
SettingsDAO.getValorSetting(5)) + ".msi";
}
catch (Exception e)
{
//Registro de error
}
return ruta;
}
El mtodo web valida el identificador de la mquina que realiza la solicitud. Posteriormente

obtiene la ruta que es el resultado de concatenar el setting de ruta de repositorio
http://evoagentserver//EvoAgentServer/ControlClientes/Repositorio/ con el nombre del
fichero EvoAgentSetup ms el setting de Versin (Se ha modificado el nombre del fichero
previamente para que se pueda identificar as) v.v ms la extensin, .msi.
A travs del mtodo anterior se devuelve la URL al servicio. El servicio llama a la funcin
descargarArchivo para descargar el paquete de instalacin de la ruta obtenida, crea un
fichero .bat para ejecutarlo y antes de iniciar la instalacin detiene el proceso EvoIcon para
que el proceso no provoque el reinicio del equipo. Cuando empieza la instalacin, 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 mquina.
La funcin 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
Resumen de los pasos para la actualizacin del programa agente
Se resume los pasos necesarios para actualizar los programas agente. Como ejemplo se
pone la actualizacin de la versin 1.1 a la versin 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 versin 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 1.2.0 y aceptar el

cambio automtico 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 versin: EvoAgentSetup1.2.msi
7. Abrir la aplicacin EvoAgentManager, acceder al apartado settings y dentro de settins

a gestin de Versiones. Modificar la ltima versin disponible a 1.2 y asegurar que la
ruta del repositorio es correcta y accesible.
310
Anexo 3. Tecnologas
A3.1 Tecnologa .NET

A continuacin se presentan varios aspectos que tienen que ver con la tecnologa .NET
.NET Framework
El "framework" o marco de trabajo, constituye la base de la plataforma .NET y denota la
infraestructura sobre la cual se renen un conjunto de lenguajes, herramientas y servicios
que simplifican el desarrollo de aplicaciones en entorno de ejecucin distribuido.
Bajo el nombre .NET Framework o Marco de trabajo .NET se encuentran reunidas una
serie de normas impulsadas por varias compaas adems 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 programacin 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 mnimo de funcionalidad, y
compatibilidad con todos los dems 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 librera de

clases base (BCL por sus siglas en ingls) (incluido en ECMA-335, ISO/IEC 23271).
Tal vez el ms importante de los componentes de la plataforma, esta norma define un
conjunto funcional mnimo 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 publicacin 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 implementacin de la norma para varios
sistemas operativos adicionales bajo el marco del software libre o cdigo abierto.
Los principales componentes del marco de trabajo son:
El conjunto de lenguajes de programacin

311
La Biblioteca de Clases Base o BCL
El Entorno Comn de Ejecucin para Lenguajes o CLR por sus siglas en ingls.
Debido a la publicacin de la norma para la infraestructura comn de lenguajes (CLI por

sus siglas en ingls), el desarrollo de lenguajes se facilita, por lo que el marco de trabajo
.NET soporta ya ms de 20 lenguajes de programacin y es posible desarrollar cualquiera de
los tipos de aplicaciones soportados en la plataforma con cualquiera de ellos, lo que elimina
las diferencias que existan 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 ncleo del Framework de .NET, entorno de ejecucin 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 cdigo fuente de cualquiera de los lenguajes

soportados por .NET en un cdigo intermedio (MSIL, Microsoft Intermediate Lenguaje),
similar al BYTECODE de Java. Para generar dicho cdigo el compilador se basa en el
Common Language Specification (CLS) que determina las reglas necesarias para crear ese
cdigo MSIL compatible con el CLR.
Para ejecutarse se necesita un segundo paso, un compilador JIT (Just-In-Time) es el que

genera el cdigo mquina real que se ejecuta en la plataforma del cliente.
De esta forma se consigue con .NET independencia de la plataforma hardware.
La compilacin JIT la realiza el CLR a medida que el programa invoca mtodos, el cdigo
ejecutable obtenido, se almacena en la memoria cach del ordenador, siendo recompilado
de nuevo slo en el caso de producirse algn cambio en el cdigo fuente.
312
Figura A3.1 Entorno CLR
313
Figura A3.2 Librera de Clases
Lenguaje de Programacin C#
C# (pronunciado "si sharp" o C sostenido) es un lenguaje de programacin orientado a
objetos desarrollado y estandarizado por Microsoft como parte de su plataforma .NET, que
despus fue aprobado como un estndar por la ECMA e ISO.
Su sintaxis bsica 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 (ms
notablemente de Delphi y Java). C# fue diseado para combinar el control a bajo nivel de
lenguajes como C y la velocidad de programacin de lenguajes como Visual Basic.
C# significa, "do sostenido" (C corresponde a do en la terminologa musical anglo-sajona). El

smbolo # 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 "Especificacin del Lenguaje C#"). El 7 de noviembre de 2005 acab la
beta y sali la versin 2.0 del lenguaje que incluye mejoras tales como tipos genricos,
mtodos annimos, iteradores, tipos parciales y tipos anulables. Ya existe la versin 3.0 de
C# en fase de beta destacando los tipos implcitos y el LINQ (Language Integrated Query).
Aunque C# forma parte de la plataforma .NET, sta es una interfaz de programacin de

aplicaciones; mientras que C# es un lenguaje de programacin independiente diseado para
generar programas sobre dicha plataforma. Aunque an 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 2002. Es para el sistema operativo Microsoft Windows y est pensado, principal
pero no exclusivamente, para desarrollar para plataformas Win32.
314
Figura A3.3 Visual Studio 2005
La ltima versin en lnea de IDEs, Visual Studio .NET soporta los nuevos lenguajes .NET:
C#, Visual Basic .NET y Managed C++, adems 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 porttiles (utilizando .NET Compact Framework).
El aspecto de Visual Studio .NET es casi idntico a las versiones anteriores del IDE
(Microsoft Visual Studio). Algunas excepciones destacables son la interfaz ms limpia y
mayor cohesin. Tambin es ms personalizable con ventanas informativas de estado que
automticamente se ocultan cuando no se usan. Todas las versiones de Visual Studio,
tambin su predecesora Visual C++, incluyen un depurador integrado en el entorno de
edicin.
La caracterstica ms notable del IDE es su soporte de los nuevos lenguajes .NET. Los
programas desarrollados en esos lenguajes no se compilan a cdigo mquina ejecutable
(como por ejemplo hace C++) sino que son compilados a algo llamado CIL. Cuando los
programas ejecutan la aplicacin CIL, sta es compilada en ese momento al cdigo de
mquina apropiado para la plataforma en la que se est ejecutando. Mediante este mtodo,
Microsoft espera poder soportar varias implementaciones de sus sistemas operativos
Windows (como Windows CE). Los programas compilados a CIL pueden ejecutarse slo en
plataformas que tengan una implementacin 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
La versin definitiva en ingls vio la luz en Noviembre del 2005. En castellano hubo que
esperar hasta Febrero de 2006.
Incorpora .NET Framework 2.0.
Hay ms ediciones diferenciadas por el precio y las caractersticas.
Ayuda con refactorizacin.
El desarrollo de pginas con ASP.NET ha cambiado.
Soporte para el nuevo software servidor Team System.
Aadido soporte de tests para todo tipo de aplicaciones.
Dynamic Linking Library (dll)

Tcnicamente se refiere con este trmino a archivos con cdigo ejecutable que se cargan
bajo demanda del programa por parte del sistema operativo. Esta denominacin se refiere a
los sistemas operativos Windows siendo la extensin con la que se identifican los ficheros,
aunque el concepto existe en prcticamente todos los sistemas operativos modernos.
Las DLLs son o pueden verse como la evolucin de las bibliotecas estticas y de forma
anloga contienen funcionalidad o recursos que utilizan otras aplicaciones. Sin embargo, su
uso proporciona algunas ventajas:
Reducen el tamao de los archivos ejecutables: Gran parte del cdigo puede
estar almacenado en bibliotecas y no en el propio ejecutable lo que redunda en una
mejor modularizacin.
Pueden estar compartidas entre varias aplicaciones: Si el cdigo es
suficientemente genrico, puede resultar de utilidad para mltiples aplicaciones.
Facilitan la gestin y aprovechamiento de la memoria del sistema: La carga
dinmica permite al sistema operativo aplicar algoritmos que mejoren el rendimiento
del sistema cuando se carguen estas bibliotecas. Adems, 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 pequeos errores distribuyendo nicamente una nueva versin de la
biblioteca dinmica. Nuevamente, est correccin o mejora ser aprovechada por
todas las aplicaciones que compartan la biblioteca.
316
Visual Studio Permite generar Proyectos cuya solucin sea una librera dinmica. De
sta forma, y ya pensando en el diseo de la aplicacin, se podr tener un proyecto de
Visual Studio que contenga elementos comunes a todo el sistema como el modelo de
dominio o la lgica de negocio o acceso a datos y simplemente ser necesario
agregar dicha librera a cada una de las aplicaciones del sistema. Esto permitir
coherencia entre las aplicaciones que conforman el sistema adems de proveer un
punto comn de evolucin 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 aplicacin 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 continuacin, adjuntar un depurador al proceso del
servicio.
A diferencia de algunos tipos de proyectos, se deber crear componentes de instalacin para

las aplicaciones de servicios. Los componentes de instalacin 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 mtodo Main para la aplicacin de servicios debe emitir el comando Run para los servicios
que contiene el proyecto. El mtodo 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 mtodo se escribir automticamente.
Las aplicaciones de servicios de Windows se ejecutan en una sesin de ventana diferente a

la sesin interactiva del usuario que ha iniciado una sesin. Una estacin 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 estacin de un servicio de Windows no es interactiva, los
cuadros de dilogo que proceden de una aplicacin 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

interaccin con estaciones interactivas, es decir, con el usuario que ha iniciado una sesin.
317
.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 interaccin del servicio de Windows con el usuario u otras estaciones debe disearse con
cuidado para que incluya casos como, por ejemplo, que no exista un usuario que haya
iniciado una sesin o que el usuario tenga un conjunto inesperado de objetos de escritorio.
En algunos casos, puede ser ms apropiado escribir una aplicacin 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 sesin 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 ms
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 cdigo llamando al mtodo Start. El
mtodo Start pasa el procesamiento al mtodo OnStart de la aplicacin y procesa el cdigo
que haya definido all.
Un servicio en ejecucin 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 bsicos: Running, Paused o Stopped. El servicio tambin 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 ejecucin, pero que el comando an no se ejecut. Puede consultar
Status para determinar en qu estado se encuentra el servicio, o bien utilizar WaitForStatus
para realizar una accin 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 mtodos adecuados desde
el cdigo. 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 realizarn cuando cambie el estado del servicio.
318
Implementar e instalar servicio

Visual Studio incluye componentes de instalacin que pueden instalar recursos asociados a
las aplicaciones de servicios. Los componentes de instalacin 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.
Despus de agregar instaladores a la aplicacin, el siguiente paso consiste en crear un

proyecto de instalacin que instale los archivos de proyecto compilados y ejecute los
instaladores necesarios para instalar el servicio. Para crear un proyecto de instalacin
completo, se debe agregar el resultado del proyecto de servicio al proyecto de instalacin y,
a continuacin, agregar una accin 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 2003. Windows XP Profesional incluye una versin 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 pginas Web tanto
local como remotamente (servidor Web).
El servidor Web se basa en varios mdulos que le dan capacidad para procesar distintos
tipos de pginas, por ejemplo Microsoft incluye los de Active Server Pages (ASP) y
ASP.NET. Tambin pueden ser incluidos los de otros fabricantes, como PHP o Perl.
La versin 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 versin 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 produccin.
Windows Vista viene con IIS 7.0 preinstalado. No limitar el nmero de conexiones
permitidas pero limitar el flujo de tareas basndose en las solicitudes activas concurrentes,
mejorando la usabilidad y el rendimiento en escenarios punto-a-punto (peer-to-peer).
319
Figura A3.4 Administrador de IIS 7.0 para Windows Vista
A3.3.1 Sitios Web
IIS gestiona sitios Web. Un sitio Web (en ingls: Website) es un conjunto de pginas Web,
tpicamente comunes a un dominio en Internet o subdominio en la World Wide Web en
Internet.
Una pgina Web es un documento HTML/XHTML accesible generalmente mediante el

protocolo HTTP de Internet.
320
Figura A3.5 Sitio Web en IIS 7.0
A las pginas de un sitio Web se accede desde una URL raz comn llamada portada, que
normalmente reside en el mismo servidor fsico. Las URLs organizan las pginas en una
jerarqua, aunque los hiperenlaces entre ellas controlan cmo el lector percibe la estructura
general y cmo el trfico Web fluye entre las diferentes partes de los sitios.
Los sitios Web estn escritos en HTML (Hyper Text Markup Language), o dinmicamente
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
telefnos mviles.
321
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 travs de un puerto
TCP diferente al puerto TCP por defecto para los servidores Web, los tipos MIME que son
reconocidos, la versin del ASP.NET que se utiliza as como una serie de parmetros
propios de un sitio Web: (Control de acceso, seguridad, configuracin 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 estn en los
directorios especificados.
Cada sitio Web o FTP debe tener un directorio particular. El directorio particular es la
ubicacin central de las pginas publicadas. En este caso, por seguridad del sitio Web,
conviene crear un directorio particular diferente al que viene por defecto.
Uno de los parmetros 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
Figura A3.7 Configuracin del mtodo de Autenticacin en IIS 7.0
La configuracin 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.
Autenticacin annima: cuando se activa el acceso annimo, no se requieren

credenciales de usuario autenticado para tener acceso al sitio. El uso ms adecuado
de esta opcin es para conceder acceso pblico a la informacin que no requiere
seguridad. Cuando un usuario intenta conectarse al sitio Web, IIS asigna la conexin
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 pblicos. Se puede configurar la cuenta de Windows que se utiliza para
el acceso annimo.
Autenticacin bsica: la autenticacin bsica requiere un Id. de usuario y una

contrasea, y proporciona un nivel bajo de seguridad. Las credenciales del usuario se
envan en texto sin cifrar a travs de la red. Este formato proporciona un nivel bajo de
323
seguridad, porque casi todos los analizadores de protocolo pueden leer la

contrasea. Sin embargo, es compatible con el nmero ms amplio de clientes Web.
El uso ms adecuado de esta opcin es para conceder acceso a informacin con
poca o ninguna necesidad de privacidad.
Autenticacin de Windows: anteriormente se denominaba NTLM o autenticacin

por desafo/respuesta de Windows NT. Este mtodo enva la informacin de
autenticacin del usuario por la red en forma de vale de Kerberos y proporciona un
alto nivel de seguridad. La autenticacin de Windows integrada utiliza la versin 5 de
Kerberos y la autenticacin NTLM. Para emplear este mtodo, los clientes deben
utilizar Microsoft Internet Explorer 2.0 o posterior. Adicionalmente, la autenticacin de
Windows integrada no se admite sobre conexiones de proxy HTTP. El uso ms
adecuado de esta opcin es para una intranet, donde el usuario y el servidor Web
estn en el mismo dominio, y los administradores pueden asegurarse de que todos
los usuarios utilizan Internet Explorer 2.0 o posterior.
Autenticacin mediante formularios: La autenticacin 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
enva el formulario, la aplicacin autentica la solicitud y el sistema emite un vale de
autorizacin en el formulario de una cookie. Esta cookie contiene las credenciales o
una clave para readquirir la identidad. Las solicitudes subsiguientes del explorador
automticamente incluyen la cookie.
Suplantacin de ASP.NET: Corresponde ms que a un mtodo alternativo de

autenticacin o un aadido en el proceso de autenticacin de aplicaciones web.
El escenario de suplantacin se basa en la autenticacin de Servicios de Microsoft

Internet Information Server (IIS) y en la seguridad de acceso a archivos de Microsoft
Windows para minimizar la programacin de la seguridad en la propia aplicacin
ASP.NET. El flujo de datos se muestra en la ilustracin siguiente.
324
Figura A3.8 Proceso de Autenticacin 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 bsica, implcita o integrada de

Windows (NTLM o Kerberos).
3. Si se autentica al cliente, IIS pasa la solicitud autenticada a ASP.NET.
4. La aplicacin ASP.NET suplanta al cliente que realiza la solicitud utilizando el

smbolo (token) de acceso pasado desde IIS, y se basa en los permisos de archivo
NTFS para conceder acceso a los recursos. La aplicacin ASP.NET slo necesita
comprobar que la suplantacin est establecida en true en el archivo de
configuracin de ASP.NET; no se requiere ningn cdigo de seguridad de ASP.NET.
Si la suplantacin no est habilitada, la aplicacin se ejecuta con la identidad de

proceso de ASP.NET. En Microsoft Windows 2000 Server y Windows XP
325
Professional, la identidad predeterminada es una cuenta local denominada ASPNET

que se crea automticamente al instalar ASP.NET. En Microsoft Windows Server
2003, la identidad predeterminada es la del grupo de aplicaciones correspondiente a
la aplicacin 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
XML( eXtensible Markup Language): Un servicio Web es una aplicacin 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 comunicacin 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

publicacin y localizacin de los servicios. Los directorios UDDI actan como una
gua telefnica de Web services.
Aunque la idea de la programacin modular no es nueva, el xito de esta tecnologa reside

en que se basa en estndares conocidos en los que ya se tiene una gran confianza, como el
XML. Adems, el uso de los Web services aporta ventajas significativas a las empresas.
El principal objetivo que se logra, es la interoperabilidad y la integracin. Mediante los Web

services, las empresas pueden compartir servicios software con sus clientes y sus socios de
negocio. Esto ayudar a las compaas a escalar sus negocios, reduciendo el coste en
desarrollo y mantenimiento de software, y sacando los productos al mercado con mayor
rapidez.
La integracin de aplicaciones har posible obtener la informacin 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 1998. En su sitio Web, Userland,
http://www.userland.com se puede encontrar multitud de documentacin acerca de este
primer protocolo de comunicacin bajo http mediante XML. Con este protocolo se pedan
realizar RPC o remote procedure calls, es decir, podamos bien en cliente o servidor realizar
peticiones mediante http a un servidor Web. Los mensajes deban tener un formato
determinado empleando XML para encapsular los parmetros de la peticin. 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 inters por XML-RPC se desarrollo SOAP."
En el ncleo de los servicios Web se encuentra el protocolo simple de acceso a datos SOAP,
que proporciona un mecanismo estndar de empaquetar mensajes. SOAP ha recibido gran
atencin debido a que facilita una comunicacin del estilo RPC entre un cliente y un servidor
327
remoto. Pero existen multitud de protocolos creados para facilitar la comunicacin 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 increble apoyo por parte de la
industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prcticamente por
todas las grandes compaas de software del mundo. Compaas que en raras ocasiones
cooperan entre s estn ofreciendo su apoyo a este protocolo. Algunas de las mayores
Compaas que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba.
Algunas de las Ventajas de SOAP son:
No esta asociado con ningn lenguaje: los desarrolladores involucrados en nuevos

proyectos pueden elegir desarrollar con el ltimo y mejor lenguaje de programacin
que exista pero los desarrolladores responsables de mantener antiguas aflicciones
heredadas podran no poder hacer esta eleccin sobre el lenguaje de programacin
que utilizan. SOAP no especifica una API, por lo que la implementacin de la API se
deja al lenguaje de programacin, como en Java, y la plataforma como Microsoft
.Net.
No se encuentra fuertemente asociado a ningn protocolo de transporte: La

especificacin de SOAP no describe como se deberan asociar los mensajes de
SOAP con HTTP. Un mensaje de SOAP no es ms 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 mayora de los

sistemas de objetos distribuidos se pueden extender, y ya lo estn alguno de ellos
para que admitan SOAP.
Aprovecha los estndares existentes en la industria: Los principales

contribuyentes a la especificacin SOAP evitaron, intencionadamente, reinventar las
cosas. Optaron por extender los estndares existentes para que coincidieran con sus
necesidades. Por ejemplo, SOAP aprovecha XML para la codificacin de los
mensajes, en lugar de utilizar su propio sistema de tipo que ya estn definidas en la
especificacin 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 mltiples entornos: SOAP se desarrollo sobre

los estndares existentes de la industria, por lo que las aplicaciones que se ejecuten
en plataformas con dicho estndares pueden comunicarse mediante mensaje SOAP
con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicacin
de escritorio que se ejecute en una PC puede comunicarse con una aplicacin del
back-end ejecutndose en un mainframe capaz de enviar y recibir XML sobre HTTP.
328
Servicios Web en .NET

Common Language Runtime proporciona soporte integrado para crear y exponer servicios
Web, utilizando una abstraccin de programacin 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 estndares 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 direccin 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 continuacin, puede contener cdigo o hacer referencia a una clase
externa que lo contiene. La clase deber incluir las libreras de WebServices y podr
implementar servicios declarando mtodos de la clase como WebMethods.
Figura A3.10 Contenido del Archivo .asmx de un Servicio Web
329
Figura A3.11 Contenido de la clase .cs codebehind de un Servicio Web
Los archivos .asmx se publicarn dentro de un sitio Web en un directorio particular o virtual
junto con el cdigo de las clases asociadas. Se podr acceder a ellos con un cliente http
mediante la URI correspondiente.
330
Figura A3.12 Servicios Web dentro del Sitio Web en Windows Internet Explorer
Figura A3.13 Servicio Web en Windows Internet explorer

331
Adems de la tecnologa de servidor ASP.NET que permite a los programadores crear

servicios Web, .NET Framework proporciona conjuntos de herramientas y cdigo
sofisticados para consumir servicios Web. Como los servicios Web se basan en protocolos
abiertos como SOAP (Simple Object Access Protocol), esta tecnologa para cliente tambin
se puede utilizar para consumir servicios Web que no estn basados en ASP.NET.
Para que una aplicacin consuma servicios Web ubicados en una URL se puede agregar
una referencia al mismo desde el proyecto de la aplicacin en Visual Studio 2005:
Figura A3.14 Agregar referencia a un Servicio Web para una aplicacin cliente en Visual Studio 2005
Se genera as automticamente una carpeta en el directorio del proyecto que contiene las
herramientas necesarias para poder consumir el servicio Web
332
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 lnea de comandos se utiliza para crear clases
proxy a partir de WSDL. Por ejemplo, podra 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 mtodo que
devuelve una cadena. Si compila una clase proxy en una aplicacin y despus llama a su
mtodo, la clase proxy empaqueta una solicitud SOAP a travs de HTTP y recibe la
respuesta codificada por SOAP, que se resolver como una cadena.
De esta forma una aplicacin puede consumir servicios Web ubicados en un sitio Web de un
servidor Web fcilmente creando una clase Proxy que utilizar para realizar las llamadas.
333
A3.5 WinAudit
Tabla de Switches para la ejecucin del programa por lnea 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 (Windows98 and newer)
D Include Display Capabilities
a Include Display Adapters (Windows98 and newer)
I Include Installed Printers
b Include BIOS Version
334
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).
Save as compiled html.

CHM 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
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
/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 ejecucin de WinAudit en modo lnea 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 filosofa DNS es el registro A. Un Registro de direccin 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
nombrehost IN A direccinIPdehost
machine1 IN A 157.55.201.143
nombreservidor2 IN A 157.55.200.2
El registro CName que reciben el nombre de alias, aunque son conocidos como entradas de
"nombre cannico" (CNAME o Canonical Name) se utilizan para usar ms 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 www.midominio.com y que ftp.midominio.com se encuentran en el mismo

equipo. Si ste es el caso, entonces podra tener las siguientes entradas en su archivo de
zona:
servidorarchivos IN A 157.55.200.41
ftp IN CNAME servidorarchivos
www IN CNAME servidorarchivos
338
Anexo 4. Metodologas y Modelos de Diseo
A4.1 Unified Modeling Language (UML)

El UML (Unified Modeling Language) es el lenguaje de modelado de sistemas de software
ms conocido y utilizado en la actualidad, y an sin ser todava un estndar oficial, est
apoyado en gran manera por el OMG (Object Management Group).
El UML se ha convertido en el estndar de facto de la industria debido a que ha sido

concebido por los autores de los tres mtodos ms usados de orientacin a objetos: Grady
Booch, Ivar Jacobson y Jim Rumbaugh. Estos autores fueron contratados por la empresa
Rational Software Co. para crear una notacin unificada en la que basar la construccin de
sus herramientas CASE. En el proceso de creacin 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 notacin ha sido ampliamente
aceptada debido al prestigio de sus creadores y debido a que incorpora las principales
ventajas de cada uno de los mtodos particulares en los que se basa: Booch, OMT y OOSE.
El UML consiste en un lenguaje grfico para visualizar, especificar, construir y documentar

un sistema de software, particularmente aquellos que usan la orientacin a objetos. Es por
esta razn por la que se ha elegido para describir y disear el sistema objeto de este
proyecto.
La razn fundamental para el uso de lenguajes grficos de modelado es que los lenguajes
de programacin no proporcionan el suficiente grado de abstraccin para realizar el diseo
de un sistema con facilidad. UML ofrece, sin embargo, un estndar 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 programacin,
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

mtodo o un proceso, es decir, se puede usar en una gran variedad de formas para soportar
una metodologa de desarrollo de software pero no determina qu metodologa o proceso
usar.
Actualmente UML se encuentra en la versin 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
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 interaccin: 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 comunicacin.
Diagrama de tiempos.
Diagrama de vista de interaccin.
Figura A4.1 Introduccin Modelos UML
340
El estndar UML indica qu elementos se usan en cada tipo de diagramas, pero los
diagramas no son especialmente rgidos y frecuentemente se utilizan elementos de un tipo
de diagramas en otros.
Los distintos modelos que se van a utilizar se explicarn a continuacin junto con las fases
de la metodologa que los requieren.
A4.2 Modelo Entidad-Relacin

El modelo entidad-relacin es el modelo conceptual ms utilizado para el diseo
conceptual de bases de datos. Fue introducido por Peter Chen en 1976. El modelo
entidad-relacin est formado por un conjunto de conceptos que permiten describir la
realidad mediante un conjunto de representaciones grficas y lingsticas.
Originalmente, el modelo entidad-relacin slo inclua los conceptos de entidad, relacin

y atributo. Ms tarde, se aadieron otros conceptos, como los atributos compuestos y las
jerarquas de generalizacin, en lo que se ha denominado modelo entidad-relacin
extendido.
Figura A4.2 - Conceptos del modelo entidad-relacin extendido.
Entidad
341
Cualquier tipo de objeto o concepto sobre el que se recoge informacin: cosa, persona,
concepto abstracto o suceso. Por ejemplo: coches, casas, empleados, clientes,
empresas, oficios, diseos de productos, conciertos, excursiones, etc. Las entidades se
representan grficamente mediante rectngulos y su nombre aparece en el interior.
Relacin
Es una correspondencia o asociacin entre dos o ms entidades. Cada relacin tiene un

nombre que describe su funcin. Las relaciones se representan grficamente mediante
rombos y su nombre aparece en el interior.
Las entidades que estn involucradas en una determinada relacin se denominan

entidades participantes. El nmero de participantes en una relacin es lo que se
denomina grado de la relacin. Por lo tanto, una relacin en la que participan dos
entidades es una relacin binaria; si son tres las entidades participantes, la relacin es
ternaria; etc.
Una relacin recursiva es una relacin donde la misma entidad participa ms de una vez
en la relacin con distintos papeles. El nombre de estos papeles es importante para
determinar la funcin de cada participacin.
La cardinalidad con la que una entidad participa en una relacin especifica el nmero
mnimo y el nmero mximo de correspondencias en las que puede tomar parte cada
ocurrencia de dicha entidad. La participacin de una entidad en una relacin es
obligatoria (total) si la existencia de cada una de sus ocurrencias requiere la existencia
de, al menos, una ocurrencia de la otra entidad participante. Si no, la participacin es
opcional (parcial). Las reglas que definen la cardinalidad de las relaciones son las reglas
de negocio. En este caso, se definen por las cardinalidades definidas en el modelo de
dominio.
A4.3 Modelo RE/R

Convenios de representacin
o R(-X-, Y): Relacin con atributos compuestos X, Y, con clave X. Es un

conjunto de filas. Se representa mediante un rectngulo:
342
Figura A4.3 Diagrama RE/R. Representacin de una relacin
o Asociaciones Explcitas: Es una raya entre un elemento de un conjunto y otro

de otro que representa que ambos cumplen una propiedad. En el diagrama
RE/R se representa mediante una lnea entre los rectngulos y un nombre (
&). Por tanto esta lnea representa un conjunto de rayas (incluyendo el vaco).
Figura A4.4 Diagrama RE/R. Asociaciones Explcitas
Cardinalidad: cuntas rayas salen de un elemento de un conjunto hacia el otro (Simple o

mltiple, incluyendo el cero o no). Convenio de representacin:
Valores posibles Representacin
0 0 (conjunto vaco de rayas)
343
0, 1 c
0, 1, 2, 3, ... n y flecha
Figura A4.5 Diagrama RE/R. Tabla cardinalidades.
o Varias asociaciones: Entre dos rectngulos puede haber varias propiedades

que definan asociaciones diferentes.
Figura A4.6 Diagrama RE/R. Varias Asociaciones
o Asociacin implcita: Es un caso particular de asociacin en el que la

propiedad es la de igualdad de valores en un conjunto de atributos de cada
relacin. Se representa mediante una lnea entre los rectngulos con los
nombres de los atributos con iguales valores entre parntesis (para distinguir
de las explcitas) (se pueden omitir si coinciden los nombres).
344
Figura A4.7 Diagrama RE/R. Asociaciones Implcitas
o Transformacin de asociaciones explcitas en implcitas: La asociacin

explcita se transforma en una relacin o rectngulo cuyos atributos son las
claves de los rectngulos de partida. Entre el nuevo y los de partida hay
asociaciones implcitas, cuyas cardinalidades son 1 en los extremos de
partida. En los otros extremos las cardinalidades son las que haba
originalmente.
Figura A4.8 Diagrama RE/R. Transformacin de Asociaciones Explcitas en Asociaciones Implcitas
o Asociaciones de orden superior: Son asociaciones entre asociaciones.

Primero materializar como un rectngulo la asociacin que interviene en otra.
345
Figura A4.9 Diagrama RE/R. Asociaciones de orden superior
o Asociaciones reflexivas: Son asociaciones de los elementos de un conjunto

consigo mismos.
Figura A4.10 Diagrama RE/R. Asociaciones Reflexivas
o Asociaciones de grado N (N-ARIAS): Una asociacin entre n rectngulos. Se

representa con un rectngulo con atributos las claves de los originales, y
asociaciones implcitas entre stos y aqul. Las cardinalidades son 1 en los
originales y se mantienen las otras.
346
Figura A4.11 Diagrama RE/R. Asociaciones de grado N
Reglas de transformacin para asociaciones implcitas:
o Regla de Definicin de Clave: Cardinalidad (m : c) define una superclave (en

el lado c)
( (m : 1), (1 : c), (1 : 1) )
Figura A4.12 Diagrama RE/R. Regla de transformacin para asociaciones implcitas
o Regla de Agregacin de Rectngulos: Cardinalidad (1 : 1)
Figura A4.13 Diagrama RE/R. Regla de de Agregacin de rectngulos
o Regla de Supresin de Rectngulos:
347
Si un rectngulo participa con todos sus atributos en una o varias asociaciones, de las
que una al menos tiene cardinalidad (1 : m), puede suprimirse. (ojo: que no se pierdan
cardinalidades)
Figura A4.14 Diagrama RE/R. Regla de supresin de rectngulos
o Regla de definicin de atributos:
Para asociaciones explcitas. No primitiva (deducible). Acorta pasos de transformacin.
Regla: Cardinalidad (1 : m) define atributo en el lado m
Figura A4.15 Diagrama RE/R. Regla de definicin de atributos
o Regla de propagacin de la clave:
Regla: Cardinalidad (n : 1) permite propagar la clave al lado n
348
Figura A4.16 Diagrama RE/R. Regla de propagacin de la clave
o Regla de agregacin de explcitas:
Regla: Cardinalidad (1: 1) permite agregar rectngulos
Figura A4.17 Diagrama RE/R. Regla de agregacin de Explcitas
o Inclusin de nulos en el diagrama RE/R
Notacin: entre "<" y ">", ej < A >
Redefiniciones:
349
CLAVE: Los valores no nulos deben ser nicos. Se admite que haya, en general, valores
nulos en las claves, pero una clave que admita valores nulos no puede ser elegida como
clave primaria.
CLAVE AJENA: Los valores no nulos deben existir en una clave de la tabla padre.
Cardinalidad en asociaciones implcitas: solo se refiere a los valores no nulos.
Construccin del diagrama:
1) Aplicar las reglas que no consideran valores nulos hasta que no pueda transformarse
ms, en el orden: Definicin de Claves, Agregacin de Rectngulos, Supresin de
Rectngulos.
2) Despus aplicar la regla de Agregacin Externa para la incorporacin de valores

nulos.
Regla de agregacin externa de rectngulos: Sirve para incorporar Nulos al diseo. Es

una generalizacin de la Regla de Agregacin de rectngulos para el caso de
cardinalidad (c : c ). Es una aplicacin de la yuncin externa. Se aplica cuando hay una
clave comn que no admita valores nulos.
Sean dos rectngulos con una clave X comn sin nulos: A(-X-, Y, -Z-), B(-X-, Y, W), y
con cardinalidad de la asociacin implcita segn X = (c : c), ( (1 : c), (1 : 1) ).
Entonces A y B son agregables permitiendo valores nulos en algunos atributos.
Figura A4.18 Diagrama RE/R. Regla de agregacin externa para la incorporacin de valores nulos
Caso particular: (1 : c)
350
Figura A4.19 Diagrama RE/R. Regla de agregacin externa para la incorporacin de valores nulos. Caso (1:c)
351

47bb062de66ae PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

47bb062de66ae PDF

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TCNICA SUPERIOR DE INGENIERA (ICAI)

PROYECTO FIN DE CARRERA

AUTOR: Iaki Sota Madorrn

MADRID, Febrero de 2008

Iaki Sota Madorrn

EL DIRECTOR DEL PROYECTO

Pablo Igualada Moreno

V B del Coordinador de Proyectos

David Contreras Brcena

A mi familia, por la confianza depositada a lo largo de toda la carrera.

A la universidad y a sus profesores, por la ilusin y ganas que en general

A los encargados de supervisar el proyecto, coordinadores y director, por su apoyo y

A los encargados de la empresa colaboradora y compaeros de trabajo, por hacer

A los amigos y colegas.

Se trata de un sistema cliente-servidor donde un servidor instalado en la empresa de

El sistema proporciona la funcionalidad para:

Instalacin: Instalacin de un agente en una mquina cliente y su registro en el

Auditorias: La ejecucin de auditoras, por parte de los agentes, en las mquinas de

Tareas: La programacin, por parte de los tcnicos, de tareas definidas y diseadas

Tareas Programadas: La generacin, por parte de los administradores, de tareas

del servidor. Interpretacin de las mismas para su registro en el sistema y su

Upgrading: Actualizacin automtica del programa agente en todos los agentes

Gestin de Usuarios: La gestin de los usuarios que tienen acceso al sistema.

Para proporcionar la funcionalidad expuesta anteriormente se han construido varias

La aplicacin Agente, que est compuesta por un Servicio de Windows que

Una aplicacin de escritorio, con un interfaz amigable, para los tcnicos de la

Aplicaciones de instalacin, para la instalacin y actualizacin de los agentes e

El sistema, adems, se integra con aplicaciones externas, incluido el propio sistema

Por ltimo, se ha utilizado y profundizado en las tcnicas y metodologas de ingeniera del

The system provides the following features:

Upgrading: Automatic upgrade of the agent application in all operative agents.

User management: The management of the system access.

A desktop Application (Windows Application), with a kind interface, for the IT

The system, furthermore, is connected to several applications including the Operating

2. Herramientas y Tecnologa _________________________________________________ 4

2.2 Introduccin a la Tecnologa .NET ________________________________________________ 4

2.5 Introduccin a los Servios Web (Web Services) _____________________________________ 6

2.6 Introduccin a las herramientas y aplicaciones a integrar con el sistema_________________ 6

2.7 Introduccin a Microsoft SQL Server _____________________________________________ 16

3. Metodologa de Trabajo __________________________________________________ 18

3.2 Introduccin al Diseo externo del sistema _______________________________________ 21

3.4 Introduccin a la Implementacin, pruebas e Implantacin __________________________ 28

4. Anlisis de Requerimientos ________________________________________________ 31

4.2 Casos de uso ________________________________________________________________ 34

5. Diseo Externo del Sistema ________________________________________________ 51

5.2 Diagrama de paquetes ________________________________________________________ 57

6. Diseo Interno del Sistema ________________________________________________ 61

6.2 Modelo de datos ___________________________________________________________ 151

6.3 Diagrama de Clases _________________________________________________________ 164

7. Implementacin del sistema, Pruebas e Instalacin ___________________________ 190

7.3 Pruebas ___________________________________________________________________ 194

7.4 Manual de Usuario y de Explotacin ____________________________________________ 199

8. Planificacin y Presupuesto ______________________________________________ 200

9. Conclusiones y Evolucin del Sistema _______________________________________ 212

10. Bibliografa __________________________________________________________ 214

A2.2. Mantenimiento y Evolucin del sistema _______________________________________ 285

Anexo 3. Tecnologas ______________________________________________________ 311

1.1 Motivacin y Contexto del proyecto

La principal motivacin a la hora de afrontar el presente proyecto es la creacin de una

Para comprender mejor el proyecto se hace necesario conocer la tarea a automatizar y el

El presente proyecto pretende automatizar la tarea de forma que el tiempo dedicado a la

1.2 Objetivos y Descripcin del Proyecto