46ea52ba2ad25 PDF

UNIVERSIDAD PONTIFICIA COMILLAS
ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN
PROYECTO FIN DE CARRERA
DESARROLLO DE UN PORTAL
DE GESTIÓN DOCUMENTAL
AUTOR: ROBERTO LÓPEZ LÓPEZ
MADRID, SEPTIEMBRE DE 2007

Para Laura, porque ahora viene lo mejor.
I
Mi más sincera gratitud a mi familia, por su constante apoyo. A mis amigos, por hacerme reír en
los malos momentos. A Víctor Martínez y Eduardo Alcalde, por brindarme esta oportunidad.
II
RESUMEN
Hoy por hoy, la gestión documental se ha convertido en una necesidad real para toda
organización que maneje un mínimo volumen de datos. Cada vez representa un porcentaje mayor
de gastos en almacenamiento, infraestructuras, sistemas digitalizadores o fotocopiadoras, etc.
El motivo principal se debe a que las empresas precisan acceder a un gran volumen de
documentación de forma rápida y segura, bien para mera consulta o bien para modificar los datos
ya existentes con otros más actualizados. Ahí es donde un sistema de gestión documental
informatizado puede ahorrar a dichas organizaciones mucho tiempo y, por lo tanto dinero, así
como seguridad y flexibilidad.
De este modo, pueden hacerse al menos dos divisiones entre entornos de trabajo diferenciados, el
administrativo y el documental. El primero de ellos, encargado de la gestión diaria de cualquier
empresa, utiliza documentos administrativos. El entorno documental hace uso de documentación
de temática científico – técnica, necesaria para ciertos departamentos como I+D, investigación
de mercados, etc.
Los sistemas de gestión documental son programas que poseen una tecnología de bases de datos
idónea para la gestión de documentos. En todo sistema de este tipo, hay elementos hardware y
III
software, que proveerán servicios para la gestión de documentos. Estos servicios se distinguen
entre:
• Infraestructura: hardware y software básico, red de interconexión y sistemas operativos.
• Servicios de autor: se ofrece acceso a herramientas de autor, para facilitar la creación y
edición de documentos.
• Servicios de almacenamiento: usualmente el núcleo de un sistema de gestión documental
es un sistema gestor de bases de datos, normalmente relacional (actualmente se tiende a
los orientados a objetos, que ofrecen información para el reensamblaje).
• Servicios de búsqueda: las búsquedas se realizan sobre la base de datos, normamente
mediante índices en campos determinados. De esta manera se consigue una mayor
velocidad y calidad en los resultados obtenidos.
• Servicios de biblioteca: diversos servicios que incluyen retención de documentos, control
de versiones de documentos, seguimiento de uso de documentos, control de acceso y
copias de seguridad.
• Servicios de presentación y distribución.
• Servicios de trabajo en grupo: permiten una comunicación perfecta entre los integrantes
del grupo de trabajo.
Se ha intentado, mediante la realización de este proyecto fin de carrera, la consecución de un
sistema usable y útil para el usuario final, siendo esta una de las motivaciones principales del
IV
autor.
V
ABSTRACT
Documentary management has turned into a real need for any organization that handles a
minimal volume of information nowadays. More and more, it represents a major percentage of
storage expenses, infrastructures, digitizer systems, photocopiers, etc.
This is due to the fact that companies require access to a great volume of documentation in a
quick and secure way, both for mere consultation and for the modification of the already existing
information with more updated data. It is this way a computerized documentary management
system can save the above mentioned organizations not only a lot of time, but also money, safety
and flexibility.
Thus, two divisions can be established, at least, among nowadays working environments: the
administrative and the documentary ones. The first one, on charge of the daily management of
any company, makes use of administrative documents. The documentary environment makes use
of scientific and technical documentation, necessary for certain departments such as I+D, market
research, etc.
Documentary management systems are programmes with a database technology suitable for
documentation management. In this kind of systems there are both hardware and software
VI
elements that will provide services for the management of documents. The services are:
-Infrastructure: basic hardware and software, interconnection network and operative systems.
-Author services: access to author's tools is offered in order to make document creation and
edition easier.
-Storage services: the core of a documentary management system is usually a relational
managing system of databases, (Nowadays, there is a tendency towards the object orientated
ones. They offer information on reassembly).
-Search services: the searches are carried out on the database using indexes in certain fields.
Hereby, a higher speed and a better quality in the results are obtained.
- Library services: several services such as document retention, control of document versions,
documents follow-up, access control and safety copies.
- Presentation and distribution services.
- Group work services: they contribute towards a perfect communication among the different
members of a given group work.
• This end of degree project is intended for the accomplishment of a practical and useful
system for the final user, this being one of the main motivations of the author.
VII
Índice
0. MOTIVACIÓN Y OBJETIVOS……………………………………………………………….1
1. IDENTIFICACIÓN DE NECESIDADES……………………………………………………...2
1.1. DOCUMENTO DE CONCEPTOS DEL SISTEMA...............................................................3
2. ANÁLISIS DE REQUISITOS………………………………………………………………….9
2.1. MODELO FÍSICO DEL SISTEMA ACTUAL......................................................................10
2.2. MODELO LÓGICO DEL SISTEMA ACTUAL...................................................................25
2.3. LISTA DE REQUISITOS......................................................................................................36
2.4. MODELO LÓGICO DEL NUEVO SISTEMA.....................................................................48
2.5. MODELO CONCEPTUAL DE DATOS...............................................................................64
3. ESTUDIO DE ARQUITECTURA……………………………………………………………65
3.1. ESPECIFICACIÓN DE LAS ALTERNATIVAS..................................................................67
3.2. EVALUACIÓN DE ALTERNATIVAS................................................................................78
4. DISEÑO……………………………………………………………………………………….83
4.1. REQUISITOS FÍSICOS DEL NUEVO SISTEMA...............................................................84
4.2. DESARROLLO DEL MODELO FÍSICO DEL NUEVO SISTEMA....................................93
5. PROGRAMACIÓN………………………………………………………………………….149
5.1. PRUEBAS UNITARIAS......................................................................................................150
VIII
6. PRUEBAS DEL SISTEMA..………………………………………………………………...151
6.1. ENTORNO DE PRUEBAS..................................................................................................151
6.2. TIPOS DE PRUEBAS REALIZADAS................................................................................152
6.3. MANUAL DE INSTALACIÓN Y CONFIGURACIÓN.....................................................154
6.3.1. INSTALACIÓN DE UBUNTU LINUX...........................................................................155
6.3.2. INSTALACIÓN DEL SDK 5.0 DE SUN MICROSYSTEMS.........................................162
6.3.3. INSTALACIÓN DEL SERVIDOR DE APLICACIONES JBOSS..................................163
6.3.4. INSTALACIÓN DEL FRAMEWORK STRUTS.............................................................165
6.3.5. INSTALACIÓN DE MySQL............................................................................................165
6.3.6. CONFIGURACIÓN JDBC EN JBOSS.............................................................................166
6.3.7. ESTRUCTURA DEL SERVIDOR JBOSS.......................................................................169
7. IMPLANTACIÓN…………………………………………………………………………...172
7.1. PRUEBAS DE IMPLANTACIÓN.......................................................................................173
7.2. PLAN DE CONTINGENCIAS............................................................................................173
Anexos
ANEXO I: MODELOS DE DESARROLLO DE APLICACIONES
DISTRIBUIDAS CON J2EE…………….…………….…………….…………….…………...175
ANEXO II: EJB 3.0…………….…………….…………….…………………………….…….202
ANEXO III: EVALUACIÓN ECONÓMICA DEL NUEVO SISTEMA……………………...207
ANEXO IV: PLANIFICACIÓN FINAL DEL PROYECTO…………….…………………….208
ANEXO V: MANTENIMIENTO.…………….…………….…………….…………………...209
ANEXO VI: CONCLUSIONES………….…………….…………….…………….….……….212
ANEXO VII: MANUAL DE USUARIO…………….………...….…………….……………..214
ANEXO VIII: BIBLIOGRAFÍA…………………………………………………………….....225
IX
Desarrollo de un Portal de Gestión Documental
0. MOTIVACIÓN Y OBJETIVOS
No se puede expresar en una frase la motivación del autor para sacar adelante este proyecto. El
principal motivo que guía a todos, terminar los estudios, no puede sintetizar la totalidad de los
sentimientos que lo han envuelto durante su desarrollo.
Las ganas de terminar la carrera y poder dar rienda suelta a su creatividad ya en el entorno
laboral, es también otro de los factores que dan fuerza a la mayoría de los estudiantes en estos
momentos. Otros compañeros seguirán unos cuantos años más en la universidad, realizando
estudios superiores, a los cuales desea la mejor suerte posible.
De este modo, los objetivos planteados cara al desarrollo de este proyecto son los siguientes:
• Llevar a cabo un sistema de gestión documental mediante tecnologías JEE.
• Alcanzar un mayor dominio de las tecnologías asociadas, tales como EJB y Struts.
• Presentación del proyecto en septiembre.
1
1. IDENTIFICACIÓN DE NECESIDADES
En esta fase inicial del proyecto se procede a la identificación del problema, así como al
establecimiento del alcance y los limites del proyecto, definiendo sus objetivos básico.
En este caso en concreto, la hipotética empresa para la cual se desarrolla el sistema, está
buscando una automatización de la mayoría de las tareas que conlleva la gestión de la
documentación que controla.
Con un Sistema de Gestión de Documentación se pretende rastrear y almacenar documentos
electrónicos y/o imágenes de documentos soportados en papel. Concretamente, y aunque el
término genérico tiene relación con los Sistemas de Administración de Contenido (CMS), el
objetivo de este proyecto se centra en un sistema de administración de contenido corporativo.
En un principio, tras escoger este proyecto, se procedió a recabar información sobre las
necesidades del sistema, para lo cual se realizaron una serie de entrevistas con el director de
proyecto, intentando dar forma a lo que el proyecto precisaba. Fruto de tales entrevistas, no
documentadas específicamente, surge el siguiente Documento de Conceptos del Sistema.
2
1.1. DOCUMENTO DE CONCEPTOS DEL SISTEMA

I. Objetivos del sistema.
II. Alcance del sistema o aplicación.
III. Tipología de los usuarios finales.
IV. Restricciones.
V. Organización y funciones empresariales.
VI. Antecedentes.
PROYECTO: SISTEMA DE DOCUMENTO DE CONCEPTOS OCTUBRE 2007
GESTIÓN DOCUMENTAL DEL SISTEMA
I. OBJETIVOS DEL SISTEMA
3
Se pretende desarrollar un sistema de gestión de identidad, que permita almacenar de modo
centralizado la documentación generada por una organización genérica. Por lo tanto, el
objetivo no está tanto en especializar el sistema en un área de mercado en particular, sino
generar un sistema sencillo que sirva tanto a PYMEs como a usuarios domésticos.
Por ello el desarrollo no se centrará en ninguna estructura empresarial en concreto, sino que se
intentará la compatibilidad con cualquier organización.
La funcionalidad del sistema de gestión documental será proporcionar servicios de almacenado
y control de acceso a la documentación, con el objetivo de:
• Facilitar el acceso de los nuevos usuarios a la documentación ya generada previamente.
• Controlar las nuevas versiones de cada uno de los documentos, así como que las
antiguas queden almacenadas, para su eventual posterior consulta.
• Creación de una cuenta para cada uno de los usuarios.
• Creación de grupos de usuarios.
• Permitir a los usuarios establecer permisos de acceso, ya sean individuales o de grupo.
II. ALCANCE DEL SISTEMA
4
La construcción del sistema abarca las áreas indicadas a continuación:
Almacenamiento de datos.
Su objetivo abarca la persistencia de los datos entregados por los usuarios para la
gestión del sistema.
Administración de usuarios y grupos.
El sistema dispondrá de herramientas para la administración de usuarios y grupos. Las
funciones más comunes serán el alta, baja y cambio de contraseñas de usuarios y
grupos, y la administración de los grupos en sí.
Acceso a la información desde clientes.
Se dotará al sistema de las herramientas necesarias para poder ofrecer al usuario el
acceso a través de un navegador web, pudiendo realizar las tareas comunes mediante el
mismo.
El navegador web permitirá almacenar y recoger la información de manera remota,
como si el usuario se encontrara en las oficinas de la organización. A este respecto, se
podrá configurar desde dónde se podrá realizar dichos accesos.
Gestión de permisos.
Un usuario con suficientes permisos para ello, podrá gestionar fácilmente la máscara de
permisos de un recurso dado. Para suplir esta necesidad, habrá que proveer al sistema
de los servicios necesarios.
III. TIPOLOGÍA DE USUARIOS FINALES.
5
Los usuarios del sistema no tendrán a priori unos grandes conocimientos informáticos. Podrán
ser desde administrativos de una empresa, hasta alumnos universitarios que acceden a la
documentación generada previamente por el profesor de la asignatura. Sólo se presumirán
conocimientos generales de uso de un navegador de internet.
Por otro lado, para la administración de la plataforma no se precisarán muchos más
conocimientos que los ya indicados.
Se presupondrá que este sistema es para consumo interno de la organización.
IV. RESTRICCIONES.
El sistema se va a construir a partir de cero, por lo que no afectarán al proyecto restricciones
debidas a reutilización de productos previos.
Por motivaciones personales y siguiendo la tendencia actual en los entornos educativos y
empresariales respecto al uso del software libre, se intentarán utilizar únicamente tecnologías
de este tipo.
Se pretende terminar este proyecto para la convocatoria de septiembre del 2007. También
habrá que amoldarse al tiempo libre del autor, fuera del horario laboral, por lo que el tiempo
será otra restricción a tener en cuenta.
V. ORGANIZACIÓN Y FUNCIONES EMPRESARIALES.
6
Como se indicó previamente, el sistema no va enfocado a ningún tipo de organización en
concreto. De cualquier manera, se tomará como estructura genérica la siguiente (Imagen 1):
Imagen 1. Organigrama de la empresa.
Contabilidad: gestión económica de la empresa. Nóminas, impuestos, cobros, pagos, etc.
Back Office: desarrollo del producto en sí.
Front Office: interacción con los clientes de la empresa. Gestión con proveedores.
Desarrollo: creación y mantenimiento del software.
VI. ANTECEDENTES.
Tal como se ha indicado previamente, se presupondrá que no había ningún sistema software
dedicado a tal premisa con anterioridad. En la empresa modelo, los documentos eran
almacenados de forma física en archivos.
Por lo tanto, una vez el sistema esté implantado, habrá una fase en la que coexistirán ambos
sistemas hasta lograr la digitalización de todos los documentos previos.
7
Creado el Documento de Conceptos del Sistema, se puede pasar a la siguiente etapa del
desarrollo, en la que se partirá de él para determinar los requisitos del sistema.
8
2. ANÁLISIS DE REQUISITOS
El objetivo de la etapa de análisis de requisitos, es alcanzar un conocimiento suficiente del
sistema, definiendo las necesidades, problemas y requerimientos del usuario, para expresarlos
mediante los modelos de procesos y de datos.
La etapa consta de las siguientes divisiones:
• Modelo Físico del Sistema Actual.
• Modelo Lógico del Sistema Actual.
• Lista de requisitos.
• Modelo Lógico del Nuevo Sistema.
• Modelo Físico del Nuevo Sistema.
• Modelo Conceptual de Datos.
El sistema actual no está informatizado. Por lo tanto, no existe sistema actual y se tomarán como
referencia las acciones genéricas que se realizan en un sistema de documentación genérico. No
9
tiene por qué estar informatizado, de hecho las acciones a realizar por el sistema serían
perfectamente realizables por un operario.
2.1. MODELO FÍSICO DEL SISTEMA ACTUAL

Este apartado permite conocer la implementación actual de las actividades y procesos, de forma
manual o, como en el caso a tratar, automática. Muestra el sistema actual, lo documenta,
posibilita la confirmación del cliente y detectar sus problemas de operación, a la vez que da a los
clientes una visión mejor de su sistema.
Al realizarse todas las tareas de forma manual, todas ellas serán sencillas y basadas en el
funcionamiento general de un archivo.
El modelo físico pretende recoger la problemática existente y los requisitos necesarios para
solventarla. Un modelo de procesos como el que se pretende obtener, consta de tres
componentes: gráfico, de definición y de especificación.
• Componente gráfico: descomposición de procesos, desde el nivel superior –nivel de
contexto– hasta el nivel de detalle deseado mediante una metodología top-down,
representados por medio de diagramas de flujos de datos. El primer nivel, denominado
Diagrama de Contexto, muestra los interfaces del sistema con el exterior, las entidades
externas que envían o reciben información del sistema a desarrollar.
• Componente de definición: consta de un diccionario cuyo objetivo no es otro sino
describir cada objeto representado en los diagramas, tales como entidades externas, procesos,
10
flujos de datos y almacenes. Cuanto más minucioso sea el análisis, se hace más grande la
necesidad de herramientas específicas que ofrezcan servicios de diccionario activo, de
manera que cada modificación en el diccionario se ve reflejada automáticamente en todos los
diagramas.
• Componente de especificación: consiste en una descripción detallada en el diccionario de
datos, de los procesos de más bajo nivel, difícilmente separables en piezas más pequeñas.
Estos procesos en realidad son los que definen la lógica del sistema, por lo que han de ser los
más detalladamente especificados.
Tras identificar los usuarios a entrevistar y las funciones asociadas a cada área, se elabora un
calendario de entrevistas y una lista de preguntas clave –no especificadas en el presente MFSA–,
útiles para entender mejor el sistema actual. El objetivo principal de estas entrevistas es ir
descomponiendo de forma sucesiva las funciones primarias, hasta obtener las elementales. Todas
estas funciones han de ser expresadas mediante diagramas de flujo de datos.
DIAGRAMA DE FLUJO DE DATOS
Nivel 0.
11
Diagrama Contextual (Imagen 2)
El diagrama contextual muestra las entidades externas con las que interactúa el sistema, así como
sus respectivos interfaces.
Se aprecia que la única entidad externa es el operario que gestiona el sistema de documentación,
que da servicio a los usuarios del sistema.
Imagen 2. Diagrama contextual.
Nivel 1.
0. Diagrama Conceptual (Imagen 3)
Las principales acciones a realizar son básicamente las siguientes:
• Consulta del catálogo general.
• Acceso a documentos específicos.

12
• Devolución de documentos.
• Introducción de nuevos documentos.
Imagen 3. Diagrama conceptual del sistema.
A simple vista se puede observar que el sistema actual tiene limitaciones, tales como la no
catalogación de sucesivas versiones, de forma explícita. Estas globos funcionales se pueden
descomponer en niveles de mayor detalle.
13
Nivel 2.
0.1. Decidir acción (Imagen 4)
Imagen 4. Decisión de acción.
14
0.2. Consultar catálogo (Imagen 5)
Imagen 5. Consulta del catálogo.
15
0.3. Acceder documento (Imagen 6)
Imagen 6. Acceso a un documento.
16
0.4. Devolver documento (Imagen 7)
Imagen 7. Devolución de un documento.
17
0.5. Introducir nuevo documento (Imagen 8)
Imagen 8. Introducción de un nuevo documento.
18
DICCIONARIO DE DATOS.
Consta de los las entradas de datos constituyentes de los nombres y descripciones de los
elementos utilizados en la especificación del software del sistema.
0. Sistema de Gestión Documental: proceso. Todo se realiza de modo manual.
0.1. Decidir acción: proceso.
Siempre que haya una nueva petición, se decide de qué tipo de acción se trata (nuevo
documento, devolución, acceso, consulta).
0.1.1. ¿Nuevo documento? : proceso. Determina si se pretende introducir un nuevo
documento o no, dirigiendo el flujo de ejecución en consecuencia.
0.1.2. ¿Devolución? : proceso. Determina si se pretende realizar la devolución de un
documento al que previamente se había accedido y, por lo tanto, no estaba disponible.
0.1.3. ¿Préstamo? : proceso. Determina si con la presente consulta se intenta solicitar el
acceso a un documento que hay disponible, o por el contrario se intenta realizar una
consulta en el catálogo general.
0.2. Consultar catálogo: proceso. Engloba todas las operaciones necesarias para realizar una
consulta en el catálogo general. Permite la búsqueda por autor, por título, por fecha o
materia. Estas opciones son exclusivas entre sí.
0.2.1. ¿Por autor? : proceso. Determina si la consulta se pretende realizar por autor.
19
0.2.2. Buscar autores: proceso. Realiza una búsqueda en el catálogo general, tomando
como campo significativo el nombre del autor.
0.2.3. ¿Por título? : proceso. Determina si la consulta se pretende realizar por título.
0.2.4. Buscar títulos: proceso. Realiza una búsqueda en el catálogo general, tomando
como campo significativo el nombre del libro.
0.2.5. ¿Por fecha? : proceso. Determina si la consulta se pretende realizar por fecha.
0.2.6. Buscar cronológico: proceso. Realiza una búsqueda en el catálogo general,
tomando como campo significativo la fecha de introducción en el archivo.
0.2.7. ¿Por materia? : proceso. Determina si la consulta se pretende realizar por materia.
0.2.8. Buscar materias: proceso. Realiza una búsqueda en el catálogo general, tomando
como campo significativo la materia sobre la que versa el documento.
0.2.9. Buscar descripción: proceso. Realiza una búsqueda en el catálogo general,
tomando como campo significativo la descripción del libro.
0.2.10. Resultados temporales: almacén.
COMPONENTES
- Listado: fichas de los ejemplares encontrados en el catálogo general que cumplen con
el patrón de búsqueda.
DESCRIPCIÓN
Almacén temporal, que almacena todos los títulos del archivo que cumplen el patrón de
búsqueda. No tiene en cuenta si estos títulos están disponibles para consulta.

20
0.2.11. Cotejar con disponibles: proceso. Comprueba, uno por uno, si los títulos obtenidos
en el almacén de resultados temporales (0.2.10) están a su vez en el almacén de títulos
disponibles (6). Todos los que no cumplen esta condición son borrados del almacén de
resultados temporales.
0.2.12. ¿Más resultados temporales? : proceso. Determina si queda algún resultado en el
almacén de resultados temporales (0.2.10) sin cotejar con el almacén de títulos
disponibles (6).
0.2.13. Recoger resultado final: proceso. Colecta los resultados almacenados en la tabla
de resultados temporales (0.2.10) y los redirige al conector de datos de los ejemplares (3).
0.3. Acceder documento: proceso. Engloba todas las operaciones necesarias para poder
acceder a un documento almacenado.
0.3.1. ¿Existe ejemplar? : proceso. Determina si el documento solicitado realmente
existe.
0.3.2. ¿Hay ejemplares libres? : proceso. Determina si el ejemplar solicitado está
disponible para consulta.
0.3.3. Reservar ejemplar: proceso. Borra el ejemplar solicitado del registro de
documentos disponibles.
0.4. Devolver documento: proceso. Engloba todas las acciones necesarias para devolver un
documento al que previamente se ha tenido acceso y, por lo tanto, no se encuentra en el
registro de documentos disponibles.
21
0.4.1. Borrar préstamo: proceso. Introduce la referencia del título a devolver en el
archivo de documentos disponibles (6).
0.4.2. Extraer ubicación: proceso. Consulta en el catálogo general, la ubicación del
documento buscado. Redirige estos datos por el conector datos ejemplar (3).
0.5. Introducir nuevo elemento: proceso. Engloba todas las tareas necesarias previas a
introducir un nuevo título en el archivo de documentos.
0.5.1. Consultar disponibilidad: proceso. Realiza la comprobación de que el ejemplar
solicitado se encuentre en el listado de documentos. En tal caso, se trata de una
devolución en vez de un alta, y redirige la acción hacia ese bloque (0.4).
0.5.3. Calcular ubicación: proceso. Consulta el índice de materias (7) para estimar la
zona del archivo en la que se debe colocar el documento dado.
0.5.4. Modificar ficha: proceso. Tras recibir la nueva ficha por su conector
correspondiente (4), escribe en ella la dirección calculada en el proceso calcular
ubicación (0.5.3).
0.5.5. Almacenar ficha: proceso. Escribe la entrada correspondiente al nuevo documento
en el catálogo general del archivo, y en su respectivo registro de documentos disponibles.
1. Operario: única entidad externa con la que interactúa el sistema. Encargado del archivo
general, dispensa los documentos a los usuarios, da de alta nuevos documentos, etc.
2. Consulta: flujo de datos.
COMPONENTES
22
Datos de la consulta:
- Tipo: si se trata de una devolución, una consulta, etc.
- Datos de la búsqueda: en caso de tratarse de una consulta, aquellos datos que sean relevantes
para la misma.
- Datos devolución: en caso de querer devolver un documento al que se haya tenido acceso
previo.
DESCRIPCIÓN
El operario realiza diversas acciones en el sistema actual. Cualquiera que sea el cometido, éste
tendrá unos campos genéricos, que vienen especificados dentro de este flujo de datos.
3. Datos ejemplar: flujo de datos.
COMPONENTES
Datos
- Encontrados: serie de fichas de los documentos encontrados en el catálogo general, que
cumplen con el patrón indicado.
DESCRIPCIÓN
Datos de retorno de las operaciones realizadas, ya sea la ubicación de un libro introducido en el
sistema o devuelto, para colocarlo físicamente en el archivo; la de un documento solicitado, para
proceder a su acceso físico en el archivo; o los datos de una búsqueda en el catálogo general.
4. Nueva ficha: flujo de datos.
COMPONENTES
- Datos del documento: título, autor, fecha de introducción en el archivo.
- Ubicación: dirección en el archivo general.
- Descripción: sinopsis general del documento.
23
DESCRIPCIÓN
Este flujo es necesario si el operario se dispone a introducir un nuevo documento en el archivo.
Este documento tiene una plantilla, y la rellena el propio operario.
5. General: almacén.
CONTENIDO
- Listado: relación general de todos los documentos de los que dispone el archivo, estén
disponibles o no.
DESCRIPCIÓN
Archivador con todas las fichas de los documentos que gestiona el archivo.
6. Disponibles: almacén.
CONTENIDO
- Listado: lista de los documentos disponibles para consulta.
DESCRIPCIÓN
Archivador con todas las fichas de los documentos que están disponibles para consulta. Cada vez
que se saca un ejemplar para consulta, se borra de este listado. Asimismo, cuando se devuelve se
introduce de nuevo.
7. Índice materias: almacén.
CONTENIDO
- Listado: lista de las materias en el archivo.
DESCRIPCIÓN
Índice de todas las materias de los documentos gestionados, con su dirección relativa en el
archivo general.
24
2.2. MODELO LÓGICO DEL SISTEMA ACTUAL
Una vez obtenido el modelo físico del sistema actual, se deduce el modelo lógico del sistema
actual, de alto nivel, retirando del modelo físico las características físicas y agrupando procesos
físicos para deducir procesos lógicos.
De este modo, el objetivo principal del modelo lógico es identificar las funciones o procesos y
sus datos esenciales, eliminando o sustituyendo lo superfluo para el funcionamiento del negocio
en estudio. El modelo físico incluirá procesos y datos esenciales, aunque sean necesarios para la
operativa actual del sistema. Esos procesos y datos no esenciales se eliminarán en el paso del
modelo físico al lógico actual.
Para deducir el modelo lógico a partir del físico, debe descubrirse lo esencial del sistema en
estudio. Los procesos o funciones esenciales son aquellos que caracterizan la operativa del
negocio, procesos esenciales hechos por razones de negocio y no tecnológicas.
En general, los procesos realizados por razones tecnológicas o procesos no esenciales se deben a:
• Procedimientos o normas establecidas en la organización.
• Políticas de empresa.
• Deficiencias del trabajo, o la manera de hacer las cosas.
• Elementos redundantes y obsoletos en la gestión.
25
• Limitaciones geográficas.
• Tecnología utilizada.
DIAGRAMA DE FLUJO DE DATOS
Nivel 0.
Diagrama contextual (Imagen 9)
Imagen 9. Nivel contextual del sistema.
26
Nivel 1.
0. Diagrama conceptual (Imagen 10)
Imagen 10. Diagrama conceptual del sistema.
27
Imagen 11. Consulta en el catálogo general.
28
Imagen 12. Acceso a un documento.
29
0.4. Devolver documento (Imagen 13)
Imagen 13. Devolución de un documento.
30
0.5. Introducir nuevo documento (Imagen 14)
Imagen 14. Introducción de un nuevo documento.
31
0. Sistema de Gestión Documental: proceso.
0.1. Decidir acción: proceso.
Siempre que haya una nueva petición, se decide de qué tipo de acción se trata (nuevo
documento, devolución, acceso, consulta).
0.2. Consultar catálogo: proceso. Engloba todas las operaciones necesarias para realizar una
consulta en el catálogo general. Permite la búsqueda por autor, por título, por fecha o
materia. Estas opciones son exclusivas entre sí.
0.2.1. Buscar: proceso. Extrae del catálogo general los ejemplares que se correspondan
con el patrón dado.
0.2.2. Cotejar con disponibles: proceso. Recibe los resultados del proceso 0.2.1, y los
filtra comprobando aquellos que estén disponibles.
0.3. Acceder documento: proceso. Engloba todas las operaciones necesarias para poder
acceder a un documento almacenado.
0.3.1. Comprobar disponibilidad: proceso. Comprueba si el documento solicitado se
encuentra en el registro de documentos disponibles.
0.3.2. Reservar: proceso. Borra el documento solicitado del inventario de documentos
disponibles.
32
0.4. Devolver documento: proceso. Engloba todas las acciones necesarias para devolver un
documento al que previamente se ha tenido acceso y, por lo tanto, no se encuentra en el
registro de documentos disponibles.
0.4.1. Borrar préstamo: proceso. Reintroduce el documento devuelto en la tabla de
documentos disponibles.
0.4.2. Extraer ubicación: proceso. Devuelve la ubicación del título devuelto, sacándolo
del registro general.
0.5. Introducir nuevo elemento: proceso. Engloba todas las tareas necesarias previas a
introducir un nuevo título en el archivo de documentos.
0.5.1. Consultar disponibilidad: proceso. Comprueba si el documento que se pretende
añadir al registro no se encuentra ya en el mismo. En tal caso, redirige la petición como
devolución.
0.5.3. Calcular ubicación: proceso. Calcula la posición que el documento dado ha de
tener en el archivo.
0.5.4. Almacenar nueva ficha: proceso. Supone el almacenamiento de la fichas
correspondiente al documento dado el catálogo general y la introducción de su referencia
en el índice de documentos disponibles. Retorna los datos calculados en el proceso 0.5.3.
1. Operario: única entidad externa con la que interactúa el sistema. Encargado del archivo
general, dispensa los documentos a los usuarios, da de alta nuevos documentos, etc.
2. Consulta: flujo de datos.

33
COMPONENTES
Datos de la consulta:
- Tipo: si se trata de una devolución, una consulta, etc.
- Datos de la búsqueda: en caso de tratarse de una consulta, aquellos datos que sean relevantes
para la misma.
- Datos devolución: en caso de querer devolver un documento al que se haya tenido acceso
previo.
DESCRIPCIÓN
El operario realiza diversas acciones en el sistema actual. Cualquiera que sea el cometido, éste
tendrá unos campos genéricos, que vienen especificados dentro de este flujo de datos.
3. Datos ejemplar: flujo de datos.
COMPONENTES
Datos
- Encontrados: serie de fichas de los documentos encontrados en el catálogo general, que
cumplen con el patrón indicado.
DESCRIPCIÓN
Datos de retorno de las operaciones realizadas, ya sea la ubicación de un libro introducido en el
sistema o devuelto, para colocarlo físicamente en el archivo; la de un documento solicitado, para
proceder a su acceso físico en el archivo; o los datos de una búsqueda en el catálogo general.
4. Nueva ficha: flujo de datos.
COMPONENTES
- Datos del documento: título, autor, fecha de introducción en el archivo.
- Ubicación: dirección en el archivo general.
34
- Descripción: sinopsis general del documento.
DESCRIPCIÓN
Este flujo es necesario si el operario se dispone a introducir un nuevo documento en el archivo.
Este documento tiene una plantilla, y la rellena el propio operario.
5. General: almacén.
CONTENIDO
- Listado: relación general de todos los documentos de los que dispone el archivo, estén
disponibles o no.
DESCRIPCIÓN
Archivador con todas las fichas de los documentos que gestiona el archivo.
6. Disponibles: almacén.
CONTENIDO
- Listado: lista de los documentos disponibles para consulta.
DESCRIPCIÓN
Archivador con todas las fichas de los documentos que están disponibles para consulta. Cada vez
que se saca un ejemplar para consulta, se borra de este listado. Asimismo, cuando se devuelve se
introduce de nuevo.
7. Índice materias: almacén.
CONTENIDO
- Listado: lista de las materias en el archivo.
DESCRIPCIÓN
Índice de todas las materias de los documentos gestionados, con su dirección relativa en el
35
archivo general.
2.3. LISTA DE REQUISITOS
Relación de los requisitos expresados por el cliente para el nuevo sistema. Confeccionado a
partir de las entrevistas con el cliente, recogiendo las características de cada requisito en una
ficha específica. A su vez, se puede realizar una división de los requisitos en función a su
naturaleza, encontrando de este modo los siguientes tipos:
• Funcionales: aquellos relacionados con las funciones de negocio.
• Operativos: relativos al modo de funcionamiento interno del sistema.
• De prestaciones: características adicionales o funciones de menor prioridad.
• De seguridad: relativos al acceso al sistema y la prioridad de los datos.
• De fiabilidad: relativos a la integridad y veracidad de la información.
36
IDENTIFICACIÓN
Proyecto: Sistema de Gestión Documental

Jefe de proyecto: Roberto López López
REQUISITO
Fecha: 4-8-2007 -Versión: 1.0 -Estado: pendiente -Prioridad:

- Página: 1
Título: Estructura de directorios.
Identificador: REQ-01
Fuente: Cliente.
Categoría: Funcional.
Descripción: Los documentos se podrán organizar en una estructura de directorios, que pueden
coincidir con las áreas temáticas de los documentos.
MEDICIÓN
Aprobación del cliente.

BENEFICIOS
Organización más intuitiva para el cliente. Es análoga a la del sistema actual, con lo que
podría reducir el tiempo de aprendizaje para el cliente.
Permitirá una búsqueda por áreas en vez de por términos clave.
COMENTARIOS / SOLUCIONES SUGERIDAS
Puede implementarse con una base de datos jerárquica.

Otra solución más asequible sería emular el sistema de directorios introduciendo las
tablas pertientes en la base de datos relacional, y a su vez un campo en las tuplas de los
documentos, indicando en qué directorio se encuentran ubicados.
REQUISITOS RELACIONADOS
37
IDENTIFICACIÓN

REQUISITO

- Página: 2
Título: Control de versiones.
Fuente: Cliente.
Categoría: Fiabilidad.
Descripción: Se precisa realizar un seguimiento pormenorizado de las modificaciones que se
produjeron en cada documento en cada fecha, almacenando las anteriores versiones por motivos
de seguridad, claridad, etc.
MEDICIÓN
Aprobación por el cliente.

BENEFICIOS
Mayor seguridad: se podrá controlar quién ha modificado cada documento y qué partes
han sido afectadas.
Mayor fiabilidad: las versiones anteriores seguirán almacenadas en el sistema, para el
caso de que se almacene una versión errónea.
Integración de un sistema de control de versiones ya existente.

Emulación del sistema de control de versiones a nivel de la base de datos.
38
IDENTIFICACIÓN

REQUISITO

- Página: 3
Título: Sistema distribuido.
Fuente: Cliente.
Categoría: Operativo.
Descripción: El sistema podrá ser accedido desde cualquier PC conectado a la red. Los usuarios
podrán realizar consultas y peticiones de manera remota.
MEDICIÓN
Aprobación por el cliente.

BENEFICIOS
El operario tendrá menor carga de trabajo, simplemente tendrá que introducir los nuevos
títulos en el sistema.
Se reducirán las colas y varios usuarios podrán utilizar el sistema a la vez.
Servicios web en el servidor y cliente remoto tipo SWING, Visual Basic o similar.
Aplicación web accesible desde cualquier navegador web remoto que esté conectado a la
red.
REQ-04
39
IDENTIFICACIÓN

REQUISITO

- Página: 4
Título: Digitalización de documentos físicos.
Fuente: Análisis posterior a la entrevista.
Descripción: Los documentos ya existentes en el sistema, que estén almacenados de una forma
meramente física, han de ser digitalizados para su posterior acceso remoto.
MEDICIÓN
Se pretende que, dependiendo del volumen del fondo bibliográfico, se digitalice todo en un
plazo prudencial, una vez comience el período de implantación.
De todas maneras, el que dará el visto bueno final será el cliente.

BENEFICIOS
Los documentos previos han de ser accesibles en el nuevo sistema de forma remota.
Los documentos almacenados podrán ser consultados sin peligro de que se deterioren.
Contratar los servicios de una empresa externa.

Dotar al operario del hardware y software necesario para digitalizar: scanner, sistema
OCR para el reconocimiento de textos, etc. Para esta tarea precisará de la ayuda de más
personal, en su momento se tendrá en cuenta esta posibilidad.
Una vez digitalizado todo el fondo documental, el operario necesitará digitalizar todos
los documentos físicos que vayan llegando al sistema, previamente a almacenarlos.
REQ-03
40
IDENTIFICACIÓN

REQUISITO

- Página: 5
Título: Alta remota de documentos digitales.
Fuente: Cliente.
Descripción: Como consecuencia al requisito REQ-03, el usuario podrá no sólo consultar
documentos de forma remota, sino también subir sus propios documentos al sistema.
MEDICIÓN
El cliente ha de dar su aprobación.

BENEFICIOS
Ahorro de tiempo, comodidad para el usuario.

Menos trabajo para el operario.
Formularios web, conjuntados con servlets que acceden a la base de datos remota.
Acceso ftp.
REQ-03
41
IDENTIFICACIÓN

REQUISITO

- Página: 6
Título: Informe documentos dados de alta.
Categoría: Operativo.
Descripción: El operario tendrá un menú donde ver los últimos documentos dados de alta, para
comprobar si han sido bien categorizados por el usuario, y corregirlo en tal caso.
MEDICIÓN
El equipo de análisis ha de comprobar el cumplimiento de este requisito.

BENEFICIOS
Mejor auditoría a los usuarios.

Mejor categorización de los documentos.
Los documentos que no hayan sido todavía auditados, tendrán una marca para ser
reconocidos.
Se podrá hacer una auditoría por fecha (los últimos X días, entre dos fechas
determinadas...).
REQ-05
42
IDENTIFICACIÓN

REQUISITO

- Página:
Título: Control de acceso.
Categoría: De seguridad.
Descripción: Habrá un sistema para realizar la autentificación de usuarios, con nombre y
contraseña. Los usuarios no autentificados no podrán utilizar el sistema.
MEDICIÓN
Las distintas funcionalidades no podrán ser accesibles para un usuario que no haya sido
autentificado o que no tenga acceso a las mismas.
BENEFICIOS
Mayor seguridad: los usuarios no autorizados no podrán acceder al sistema.

Creación de roles: el operario tendrá mayor acceso a las capacidades del sistema, los
usuario sólo a las normales.
Pantalla de bienvenida con campos para nombre de usuario y contraseña.

Si se realiza un sistema con páginas web, en cada JSP se pueden introducir controles de
la sesión: en caso de no estar bien autentificado, se redirige a la página de bienvenida.
43
IDENTIFICACIÓN

REQUISITO

- Página: 8
Título: Auditoría de accesos.
Descripción: Al igual que en REQ-06, el operario dispondrá de un informe de los últimos
usuarios que han utilizado el sistema.
MEDICIÓN

BENEFICIOS
Mejor auditoría a los usuarios.

Mayor seguridad en el sistema.
Cada vez que un usuario entre al sistema, este evento quedará almacenado en la base de
datos. Lo mismo con los intentos fallidos.
Se podrá hacer una auditoría por fecha (los últimos X días, entre dos fechas
determinadas...).
REQ-06, REQ-07
44
IDENTIFICACIÓN

REQUISITO

- Página: 9
Título: Alta de usuarios
Fuente: Análisis posterior a entrevista.
Descripción: El operario dispondrá de una pantalla en la que poder dar de alta a nuevos
usuarios en el sistema. Del mismo modo, podrá cambiar contraseñas, revocar accesos, dar de
baja...
MEDICIÓN

BENEFICIOS
Mayor control sobre los usuarios del sistema.

Centraliza todo el proceso de control de usuarios, el operario seguirá siendo responsable
de todo el sistema.
El alta manual, en la base de datos, será poco factible.

Se generarán una serie de JSP que presenten un interfaz amigable.
REQ-07, REQ-10
45
IDENTIFICACIÓN

REQUISITO

- Página: 10
Título: Contraseñas cifradas.
Descripción: Las contraseñas se almacenarán en la base de datos con un algoritmo
preestablecido.
MEDICIÓN

BENEFICIOS
Mayor seguridad en el almacenamiento de contraseñas.

Las contraseñas no serán visibles en forma de texto plano por el operario.
Algoritmo simétrico, con una clave común para cifrar y descifrar.

Algoritmo asimétrico, con una clave pública para cifrar y otra privada para descifrar.
REQ-07, REQ-09
46
IDENTIFICACIÓN

REQUISITO

- Página: 11
Título: Sistema multiusuario.
Fuente: Cliente.
Descripción: Varios usuarios podrán utilizar el sistema a la vez, e incluso acceder al mismo
documento.
MEDICIÓN
El cliente ha de dar su aprobación.

BENEFICIOS
Mayor productividad para la plantilla de la organización.

Documentos almacenados de forma digital.

Documentos accesibles de modo no exclusivo.
REQ-03, REQ-04
47
2.4. MODELO LÓGICO DEL NUEVO SISTEMA
Los requisitos incorporados por el usuario se van incorporando al modelo lógico del sistema
actual. Ello supondrá la incorporación, eliminación y modificación de objetos en el mismo.
El trabajo comienza en el modelo lógico de más bajo nivel, remodelando los procesos y
diagramas de flujo de datos. De este modo, se va subiendo de nivel para consolidar lo expresado
en los niveles subyacentes hasta llegar al diagrama de contexto. Tras este proceso, se habrán
modificado, borrado o añadido nuevos almacenes de datos y flujos de datos.
DIAGRAMA DE FLUJO DE DATOS.
Nivel 0.
Diagrama de contexto (Imagen 15)
En este nuevo diagrama de contexto se puede observar que aparece una nueva entidad externa.
• Por un lado se tiene el operario del sistema que continúa actuando como administrador
del sistema; por el otro aparece la entidad usuario, como respuesta al requisito REQ-11.
• Se observan nuevos interfaces, como el flujo de datos 7. HTML, que no es otra cosa que
48
páginas HTML generadas por el sistema para comunicarse de modo remoto con los distintos
perfiles de usuario (REQ-03).
• También se ha tenido en cuenta en el nuevo diseño el requisito REQ-07, que se refleja en
el flujo 6. user/pwd.
• El nuevo flujo de datos Acción simplemente consiste en la interacción que el usuario
tiene con el sistema, como clicks de ratón o introducción de texto con el teclado.
• Finalmente, los flujos de datos Download y Upload responden a los requisitos REQ-11 y
REQ-05, respectivamente.
Imagen 15. Modelo contextual.
Nivel 1.
0. Diagrama conceptual (Imagen 16)
Los procesos principales se ven alterados en el MLNS. Concretamente, se tiene los siguientes:
49
• Entrar.
• Mostrar pantalla principal.
• Control de usuarios.
• Consultar catálogo.
• Subir documento.
• Acceder documento.
• Mostrar documento.
• Informe nuevos documentos.
Todos ellos comparten flujos de datos como HTML, ya que se van a generar documentos de este
tipo para mostrar al usuario a través del navegador. Por lo tanto, también reciben la interacción
del cliente, mediante el flujo 3. Acción, o los 4. Download o 5. Upload.
50
Imagen 16. Modelo conceptual.
Con este nuevo diagrama de concepto se percibe una fácil cobertura a los requisitos expresados
en la lista de requisitos, que se concretará en los niveles inferiores.
Nivel 2.
51
0.1. Entrar (Imagen 17)
Gestiona la entrada al sistema.
Imagen 17. Módulo de entrada al sistema.
52
0.3. Control usuarios (Imagen 18)
Módulo para el alta y baja de usuarios.
Imagen 18. Módulo de control de usuarios.
53
Proceso para consultar el catálogo general.
Imagen 19. Módulo de búsqueda.
54
0.5. Subir documento (Imagen 20)
Proceso cuya misión es gestionar la subida de documentos al sistema.
Imagen 20. Módulo de subida de nuevos documentos.
55
0.6. Acceder documento (Imagen 21).
Este módulo gestiona un documento concreto.
Imagen 21. Módulo de acceso a un documento.
56
0.7. Mostrar documento (Imagen 22)
Este proceso posibilita la descarga del documento.
Imagen 22. Módulo de descarga de archivos.
57
0.8. Informe nuevos documentos (Imagen 23)
Genera los informes de los últimos documentos subidos al sistema.
Imagen 23. Módulo de informes de nuevos documentos.
0. Sistema de Gestión documental: proceso. Sistema a desarrollar
0.1. Entrar: proceso. Encargado de controlar el acceso al sistema. Respuesta al requisito
REQ-07.
0.1.1. Mostrar pantalla entrada: proceso. Genera la pantalla inicial, donde se han de
introducir el nombre de usuario y la contraseña respectiva. En caso de ser correctos,
58
permite la entrada al sistema y anexa a la petición HTTP una sesión identificativa del
usuario.
0.1.2. Comprobar con BD: proceso. Módulo que, dados un nombre de usuario y una
contraseña, consulta en la base de datos si son correctos.
0.2. Mostrar pantalla principal: proceso. Encargado de generar la pantalla principal del
usuario u operario, y enviarla a través del servidor web.
0.3. Control usuarios: proceso. Módulo accesible sólo para el operario, cuya función es la
administración de usuarios del sistema.
0.3.1. Mostrar pantalla usuarios: proceso. Genera la pantalla donde se puede dar de alta
nuevos usuarios, o dar de baja otros ya existentes.
0.3.2. Dar de alta usuarios: proceso. Interactúa con la base de datos, insertando en la
misma un nuevo par nombre de usuario – contraseña ya dados. Devuelve un mensaje de
éxito, o de error en caso de ya existir un usuario con el mismo nombre.
0.3.3. Dar de baja usuarios: proceso. Interactúa con la base de datos, borrando de la
misma un par nombre de usuario – contraseña. Devuelve un mensaje de éxito o fallo.
0.3.4. Mostrar últimos accesos: proceso. Genera la pantalla donde el operador puede
observar los últimos usuarios que han accedido al sistema. Por defecto muestra los 10
últimos, pero permite seleccionar usuarios por diversos conceptos: fecha, usuario,
módulo funcional, etc.
0.3.5. Mostrar X accesos: proceso. Genera la página donde el operador puede observar
59
los últimos accesos que cumplen con el patrón indicado en el proceso 0.3.4.
0.3.6. Mostrar accesos: proceso. Devuelve los accesos que cumplen con el patrón dado.
0.4. Consultar catálogo: proceso. Este módulo permite realizar pesquisas en el archivo
general, tomando como filtro diversos campos.
0.4.1. Mostrar pantalla de búsqueda: proceso. Genera la pantalla donde el usuario puede
realizar búsquedas sobre el catálogo general. Permitirá realizar las mismas por diversos
conceptos.
0.4.2. Mostrar pantalla resultados: proceso. Genera la pantalla de resultados a la consulta
realizada en 0.4.1. Permite seleccionar cualquiera de los resultados obtenidos.
0.5. Subir elemento: proceso. Su función consiste en administrar la adición de nuevos
contenidos al sistema.
0.5.1. Mostrar pantalla subir documento: proceso. Genera la pantalla que permite al
usuario subir nuevos documentos, o versiones, al sistema.
0.5.2. Guardar: proceso. Recibe el documento remitido por el usuario, y se encarga de
almacenar el mismo en la base de datos, identificándolo con el IDFile y la versión
indicados.
0.6. Acceder documento: proceso. Permite seleccionar un documento dado, y muestra las
posibles acciones a realizar sobre éste.
0.6.1. Mostrar página acceso documento: proceso. Genera y envía a través del servidor
60
web la pantalla de selección de un documento dado, permitiendo diversas opciones, tales
como descarga o análisis de las distintas versiones del mismo.
0.6.2. Acceder objeto en la BD: proceso. Dado un IDFile, retorna los identificadores de
las diversas versiones que hay almacenadas del mismo en el sistema.
0.7. Mostrar documento: proceso. Posibilita la descarga del documento al ordenador del
usuario.
0.7.1. Mostrar pantalla versión documento: proceso. Dados un IDFile y una de sus
versiones, genera la pantalla que permite descargar el documento asociado. También
permite solicitar la subida de una nueva versión del mismo documento asociado al
IDFile.
0.7.2. Descargar: proceso. Dado un IDFile y una versión, devuelve al usuario el
documento en sí a través del flujo 4. Download.
0.8. Informe nuevos documentos: proceso. Permite al usuario consultar cuales han sido los
últimos documentos dados de alta en el sistema.
0.8.1. Generar pantalla informes: proceso. Genera la pantalla que permite al operario
observar cuáles son los últimos documentos y versiones dados de alta. También permite
un informe más exhaustivo, indicando los parámetros deseados.
0.8.2. Generar informe docs: proceso. Genera el informe con los parámetros indicados
por el procedimiento 0.8.1.
0.8.3. Buscar altas: proceso. Permite consultar a la base de datos documentos dados de
61
álta, por diversos conceptos.
1. Operario: entidad externa. Tiene los privilegios necesarios para administrar el sistema.
2. Usuario: entidad externa. Cliente sin privilegios.
3. Acción: flujo de datos.
COMPONENTES
-Evento: click de ratón, texto introducido...
DESCRIPCIÓN
Cada vez que un usuario interactúa con el sistema a través de una pantalla remota, ya sea
realizando un click de ratón, introduciendo un texto por teclado o cualquier tipo de evento que se
pretenda capturar, éste será capturado en el flujo de datos acción.
4. Download: flujo de datos.
COMPONENTES
-Fichero: documento anexado a la respuesta HTTP.
DESCRIPCIÓN
Respuesta del sistema al cliente cada vez que solicite la descarga a su equipo de uno de sus
recursos. No es otra cosa que una respuesta HTTP, con el respectivo fichero anexado como
parámetro.
5. Upload: flujo de datos.
COMPONENTES
-Fichero: documento anexado a la petición HTTP.
DESCRIPCIÓN
62
Petición del usuario al sistema, cada vez que se pretende subir un documento al sistema.
Consiste en una petición HTTP, con el respectivo fichero anexado en forma de parámetro.
6. user/pwd: flujo de datos.
COMPONENTES
-Usuario: campo cadena anexado a la petición HTTP.
-Contraseña: campo cadena anexado a la petición HTTP.
DESCRIPCIÓN
Par nombre de usuario – contraseña que introduce el mismo cuando intenta acceder al sistema.
7. Pantalla: flujo de datos.
COMPONENTES
-Text: texto escrito en forma de código de marcado.
-Archivos: imágenes, hojas de estilo, etc.
DESCRIPCIÓN
El sistema estructurará sus todas sus respuestas al usuario (exceptuando el caso del flujo de
datos 4. Download) en forma de código de marcado que enviará al navegador web de éste y otros
ficheros anexos a esta tecnología.
63
2.5. MODELO CONCEPTUAL DE DATOS
DIAGRAMA ENTIDAD – RELACIÓN (Imagen 24)
Imagen 24. Modelo Conceptual de Datos.
Con el desarrollo de los anteriores modelos y tras la definición de los requisitos del sistema,
finaliza esta etapa del desarrollo. Tras ella comienza el estudio de la arquitectura del sistema, y
de ahí se pasará a la etapa de diseño de la aplicación.
64
3. ESTUDIO DE LA ARQUITECTURA
El objetivo de esta fase es definir las posibles soluciones de arquitectura que satisfagan tanto los
requisitos del usuario como las restricciones de diseño. Para ello, se definen esas posibles
soluciones, y se elige la más adecuada, para ser desarrollada e implementada.
Suele ser común en las metodologías de desarrollo, realizar una planificación detallada o
programación de actividades del proyecto, dentro de esa etapa, una vez aprobada la alternativa a
desarrollar. Para ello, no es necesario un exhaustivo estudio de cada alternativa, ya que éste se
realizará en la fase de diseño. Además no conviene dedicar demasiado esfuerzo en esta etapa:
puede decidirse la necesidad de cambiar los objetivos originales de forma sustancial.
De este modo, la solución adoptada debe aportar información suficiente para estimar
razonablemente el coste del proyecto, y una visión sobre la estructura del nuevo sistema a los
usuarios. El número de alternativas dependerá del tamaño y complejidad del proyecto a realizar,
si bien es conveniente sopesar diversas opciones organizativas y de arquitectura técnica. Las
organizativas apuntan a determinar el tipo de sistema deseado, las de arquitectura a la
configuración tecnológica de la plataforma final en producción.
En concreto, esta etapa consiste básicamente en realizar cuatro actividades:
65
• Especificación de la tecnología hardware, software y de comunicaciones de cada
alternativa a estudiar.
• Evaluación de cada alternativa, en sus aspectos organizativos, operativos, técnicos y
económicos.
• Selección de una alternativa.
• Planificación general del proyecto.
66
3.1. ESPECIFICACIÓN DE LAS ALTERNATIVAS
ESPECIFICACIÓN DE LA ALTERNATIVA-1
Título Código
Cliente rico con acceso a servicios remotos 2007-08-08-1
Área Fecha
Gestión documental. 2007-08-08
Antecedentes
La gestión documental se ha ido convertiendo en uno de las áreas con mayor importancia dentro
de toda organización que maneje un volumen de información importante. De este modo, se
pretende realizar un sistema gestor, que agilice de forma segura y eficiente este departamento.
Para ello se ha tomado como base un sistema en el cual no hubiera ningún componente
informatizado.
67
Requisitos
El sistema necesita un mecanismo que permita la automatización de las tareas de acceso al
archivo. Con ello se busca también aumentar la seguridad del archivo, controlando el acceso de
los usuarios y monitorizando el acceso a la información.
Otro punto a tener en cuenta es que el acceso a estos documentos se ha de realizar de modo
remoto, para salvaguardar en todo momento los documentos originales y a su vez permitir la
consulta de un documento por varios usuarios a la vez.
ESPECIFICACIÓN DE LA SOLUCIÓN
Arquitectura:
Se propone la creación de una aplicación multicapa, que conste de los siguientes niveles
[KEOG03]:
• Cliente: aplicación escrita en Adobe Flex. Esta tecnología permite la creación de
aplicaciones mediante el lenguaje de programación ActionScript. El código se compila,
generando archivos SWF accesibles mediante un navegador. También existe la posibilidad de
generar ficheros ejecutables que se ejecuten de forma autónoma. Se trata de una manera fácil
y rápida de generar aplicaciones de internet ricas.
• Servidor: contenido en un servidor de EJB. El cliente utilizará la Message Queue (MQ)
68
como cola para dejar sus mensajes de petición de servicio. A su vez, los diversos servicios
estarán formados por tres capas: EJB de entidad, orientados a la persistencia de datos, de
sesión sin estado (Stateless), que implementan la lógica de negocio, y los dirigidos por
mensajes, que toman los mensajes del MQ y los sirven a los Stateless.
• Infraestructura de seguridad: un firewall corporativo que proteja la red interna de
amenazas externas.
De este modo se consigue una separación entre las capas de la aplicación bastante bien definida.
Necesidades Hardware:
1. Servidor de bases de datos: equipo donde hospedar la base de datos general.
2. Servidor de aplicaciones – contenedor de EJB: si se hospeda en un equipo distinto al de la
base de datos, han de estar conectados a la misma red. No habrá problema de soporte de
hardware en este aspecto, ya que se pretende utilizar para la parte de servidor el Sistema
Operativo Windows, con gran soporte para este tipo de dispositivos.
3. Operador: una simple estación de trabajo, conectada a la red corporativa, y el equipo
necesario para digitalizar documentos (scanner).
4. Usuarios: estaciones de trabajo conectadas a la red interna.
5. Firewall: equipo dedicado con soporte para varios dispositivos de red.
69
Necesidades Software:
1. Servidor de base de datos: para hospedar la base de datos se precisan diversas tecnologías.
Empezando por el Sistema Operativo, para el que se utilizará MS Windows 2003 Server; el
Sistema Gestor de Bases de Datos, donde se optará por MS SQL Server. En cuanto a la
conectividad, ha de disponer de soporte del driver de conexión a bases de datos ODBC, que ya
implementa el servidor MS SQL Server.
2. Servidor de aplicaciones: como Sistema Operativo se optará por MS Windows 2003
Server. Como entorno de ejecución de aplicaciones java, se precisará el JRE 5.0 de Sun
Microsystems. Finalmente, el fiable contenedor EJB Bea Weblogic v10, y acceso al puente
JDBC/ODBC.
3. Operador: Sistema Operativo Microsoft Windows XP SP2, con el paquete Office XP
Professional, software de reconocimiento de caracteres (OCR) y software de adquisición de
imágenes a través de scanner.
4. Firewall: Sistema Operativo Microsoft Windows Server 2003, y como sistema de
protección, el Microsoft Internet Security and Acceleration (ISA) Server.
70
Título Código
Cliente pesado con acceso a una base de datos centralizada. 2007-08-08-2
Área Fecha
Antecedentes
informatizado.
Requisitos
71
Arquitectura:
Se propone la creación de una clásica arquitectura bicapa, con clientes pesados que acceden de
forma directa a la base de datos:
• Cliente: programa escrito en cualquier lenguaje de alto nivel con soporte gráfico, en este
caso se opta por Java/Swing. Implementa toda la lógica de negocio y de acceso a la base de
datos.
• Base de datos: Sistema Gestor de Bases de Datos centralizado en un servidor central, sin
más lógica que la de almacenamiento de datos y comunicación con los clientes.
• Infraestructura de seguridad: firewall corporativo Nortel Firewall/VPN Director.
Necesidades hardware:
72
1. Cliente: se ha de disponer de estaciones de trabajo con acceso a red.
2. Operador: estación de trabajo y equipo de digitalización de documentos.
3. Servidor de base de datos: equipo servidor, con soporte de red. Al ser un elemento crítico
y estar probablemente bajo una carga bastante importante, ha de ser fácilmente escalable por
lo que se escoge la estructura en rack.
4. Infraestructura de seguridad: soporte para dispositivos de red, ya integrado en el producto
escogido.
Necesidades software:
1. Cliente: Sistema Operativo Windows XP SP2, entorno de ejecución java JRE 5.0 de Sun
Microsystems. Driver para acceso a la base de datos escogida.
2. Operador: Sistema Operativo Windows XP SP2, entorno de ejecución java JRE 5.0 de Sun
Microsystems. Driver para acceso a la base de datos escogida. Software de gestión de scanner,
y software de reconocimiento de caracteres (OCR).
3. Servidor de base de datos: Sistema Operativo IBM AIX 5L, entorno sobradamente
probado y fiable. Como Sistema Gestor de Base de Datos, se escogerá DB2 9, también de
IBM.
4. Infraestructura de seguridad: el producto escogido funciona de modo autónomo.
73
Título Código
Arquitectura de aplicación Struts con tecnología EJB 3.0. 2007-08-08-3
Área Fecha
Antecedentes
informatizado.
Requisitos
74
Arquitectura:
Se propone la siguiente arquitectura multinivel:
• Cliente: el acceso al sistema se ejecutará de forma remota mediante el uso de un
navegador web. Se trata, de este modo, de un cliente ligero con uso de un interfaz escrito en el
lenguaje de marcado HTML.
• Servidor: el servidor contenerá la lógica de presentación, negocio y acceso a base de datos.
• Infraestructura de seguridad: un firewall coporativo que trabaje tanto a nivel de red como
aplicación.
Necesidades hardware:
1. Cliente: estación de trabajo conectada a red.
2. Operador: estación de trabajo conectada a red y equipo de digitalización de documentos.
75
3. Servidor de aplicaciones: equipo servidor, con posibilidad de escalar en el futuro.
Conexión a red.
4. Servidor de bases de datos: equipo servidor, con conexión a red, con sistema de
almacenamiento rápido y de capacidad acorde a las necesidades del cliente.
5. Infraestructura de seguridad: soporte para dispositivos de red, ya integrado en el producto
escogido.
Necesidades software:
1. Cliente: cualquier sistema operativo con soporte de red. Por coste, se escoge la
distribución de GNU/Linux Ubuntu Edgy 7.04, de interfaz amigable y fácil manejo.
2. Operador: cualquier sistema operativo con soporte de red, y scanner. Al igual que en el
cliente, se escoge la distribución de GNU/Linux Ubuntu Edgy 7.04. Software de gestión del
scanner: XSane, interfaz gráfico de sencillo uso. Como software de reconocimiento de
caracteres se opta por Tesseract OCR, software desarrollado por HP y actualmente mantenido
por la empresa Google.
3. Servidor de aplicaciones: como sistema operativo se ha escogido un GNU/Linux Ubuntu,
por la familiaridad que ya posee el desarrollador con éste. Con entorno de ejecución java, JRE
5.0 de Sun Microsystems, y como contenedor JBoss 4.2.1, preparado ya para la especificación
3.0 de EJB. Es necesaria también la librería struts.jar, y el driver jdbc correspondiente al
Sistema Gestor de Bases de Datos escogido.
4. Servidor de base de datos: sistema operativo GNU/Linux Ubuntu, como en el servidor de
76
aplicaciones. Sistema Gestor de Bases de Datos MySQL.
5. Infraestructura de seguridad: el producto escogido funciona de modo autónomo.
77
3.2. EVALUACIÓN DE LAS ALTERNATIVAS
Se ha de realizar la elección de la alternativa tomando como base diversos factores. de distinta
índole.
3.2.1. Evaluación organizativa.
El aspecto más valorado en este apartado será la adaptación de los usuarios finales al nuevo
sistema.
3.2.2. Evaluación operativa.
1. Valoración de la utilidad del nuevo sistema por parte del usuario.
2. Fiabilidad de los datos almacenados.
3. Acceso simultáneo a los mismos documentos por parte de varias personas.
3.2.3. Evaluación técnica
1. Disponibilidad del nuevo sistema.
2. Portabilidad.
3. Compatibilidad con otros sistemas y plataformas.
4. Mantenibilidad.
78
5. Escalabilidad.
6. Seguridad.
7. Facilidad de instalación y ejecución.
3.2.4. Evaluación económica.
1. Coste en licencias de software.
2. Coste del hardware.
3. Mantenimiento barato.
3.2.5. Matriz de evaluación de las alternativas.
Se realizará una matriz de evaluación de las tres alternativas planteadas (Tabla 1). Todos los
factores a tener en cuenta tendrán el mismo peso, 3 puntos, de modo que 1 sea el valor más bajo
y 3 el más alto. [WWW01] [SRIK04]
2007-08-08-1 2007-08-08-2 2007-08-08-3
3.2.1.1. Adaptación al usuario 3 2 3
3.2.2.1. Valoración del sistema por

3 2 3
parte del usuario
79
3.2.2.2. Fiabilidad de los datos 3 3 3
3.2.2.3. Acceso simultáneo 3 2 3
3.2.3.1. Disponibilidad 3 2 2
3.2.3.2. Portabilidad 2 3 3
3.2.3.3. Compatibilidad 3 2 3
3.2.3.4. Mantenibilidad 3 1 3
3.2.3.5. Escalabilidad 3 1 2
3.2.3.6. Seguridad 3 3 3
3.2.3.7. Facilidad 1 2 2
3.2.4.1. Coste licencias 1 1 3
3.2.4.2. Coste hardware 2 2 3
3.2.4.3. Coste mantenimiento 3 1 3
Tabla 1
3.2.6. Ponderación de las alternativas
A continuación en la Tabla 2 se realiza un compendio de la evaluación de las alternativas.
80
PUNTUACIÓN 2007-08-08-1 2007-08-08-2 2007-08-08-3
Nivel organizativo 3 2 3
Nivel operativo 9 7 9
Nivel técnico 17 15 18
Nivel económico 6 4 9
TOTAL 35 28 39
Tabla 2
La ponderación asociada a cada uno de los niveles, se realiza en la Tabla 3.
PONDERACIÓN 2007-08-08-1 2007-08-08-2 2007-08-08-3
Nivel organizativo 8’57% 7’14% 7’69%
Nivel operativo 25’71% 25% 23’08%
Nivel técnico 48’57% 53’57% 46’15%
Nivel económico 17’14% 14’28% 23’08%
Tabla 3
Se toma como alternativa a desarrollar la “Arquitectura de aplicación Struts con tecnología EJB
3.0.” (2007-08-08-3), al ser una alternativa razonablemente económica, que también destaca en
el resto de campos.
81
Estructura general de la arquitectura escogida.
Imagen 25
La aplicación Struts, como se puede apreciar en la imagen 25, reside en un contenedor web
dentro del servidor de aplicaciones JBoss, y se encarga de la lógica de presentación. [SRIK04]
82
4. DISEÑO
El objetivo principal del Diseño Externo es transformar el modelo lógico del nuevo sistema en
un modelo físico a implementar sobre una plataforma hardware y software específica. Cuando
este modelo se haya completado, se pasará al Diseño para editar sobre la plataforma elegida la
arquitectura software.
En esta fase se completarán los requisitos físicos del nuevo sistema, se diseñarán las entradas y
salidas, se completará la especificación de los procesos del modelo, y se elaborará el modelo
lógico de datos, a partir de los volúmenes y transacciones del sistema.
Se podrá establecer la estrategia a seguir en los planes de formación al usuario, la conversión de
los datos, las pruebas del sistema y la implantación, como parte del ciclo de vida a recorrer.
83
4.1. REQUISITOS FÍSICOS DEL NUEVO SISTEMA
Se debe completar y definir detalladamente la plataforma hardware y software para la puesta en
marcha del sistema. Estos requisitos físicos se pueden expresar bajo los conceptos de: entorno
operativo del sistema y configuración hardware/software.
1. Entorno Operativo del Nuevo Sistema.
En esta fase se han de determinar aspectos claves del nuevo sistema.
Entrada, salida y recogida de datos.
Se han de definir las distintas entradas y salidas de datos, a fin de poder diseñar interfaces con
otros sistemas que dialogan con éste. Además se especifica cómo van a llevarse a cabo las
posibles tomas de datos para la entrada al sistema: quienes van a realizarlas, con qué seguridad
se va a contar, qué información se va a introducir.
84
Interfaz con el operario del sistema (Imagen 26)
Imagen 26
La interfaz del operario con el sistema, se realizará a través de formularios previamente
diseñados.
La salida de los datos hacia el operario se realizará a través de las páginas web que
serán diseñadas con el lenguaje de marcado HTML.
Interfaz del usuario con el sistema (Imagen 27)
Imagen 27
85
La comunicación del usuario con el sistema, al igual que con el operario, se realizará con
formularios previamente diseñados. Del mismo modo, la comunicación del sistema con el
usuario también se realizará con páginas HTML.
La descarga de archivos al cliente se realizará como datos adjuntos a través del protocolo HTTP.
Del mismo modo, la subida de documentos al servidor se realizará como datos adjuntos con el
método POST de HTML.
Mantenimiento de Ficheros.
La base de datos, al almacenar documentos en forma de datos binarios, estará sujeta a una
fragmentación importante. Por lo tanto, habrá que someter a periódicas defragmentaciones las
tablas pertinentes.
Generación de Informes.
El sistema generará dos tipos de informes, bien al operario o a otro usuario cualquiera.
Informe de accesos al sistema: generado mediante una plantilla. Un JSP iterará sobre los
resultados para generar el informe para todos los datos obtenidos.
Informe de últimos documentos subidos: generado mediante otra plantilla, mediante la
misma técnica que el anterior.
86
Control de información y seguridad del sistema.
El sistema será accesible a través de una pantalla inicial donde habrá que indicar el nombre de
usuario y contraseña deseados. Dichas contraseñas serán almacenadas en la base de datos,
encriptadas mediante el algoritmo de cifrado simétrico Blowfish. La clave del cifrado será
almacenada en una constante.
Del mismo modo, en cada pantalla se crearán controles para controlar si la petición la origina un
usuario debidamente autentificado, o con los permisos suficientes.
Rendimiento del sistema y escalabilidad.
El sistema está diseñado para una PYME. De cualquier modo, la arquitectura será fácilmente
escalable, en caso de entornos más exigentes. El servidor de aplicaciones JBoss implementa
novedosas tecnologías que mejoran considerablemente la escalabilidad:
JBoss Cache: almacena en caché los objetos más recientemente utilizados.
EJB 3.0: la nueva especificación de los Enterprise JavaBeans elimina la necesidad de
implementar todas las capas de seguridad, comunicaciones, etc. que en muchos casos
resultan innecesarios. De este modo, las exigencias de estos componentes se reducen de un
modo considerable.
Condicionantes de operación.
Los procesos de defragmetación de la base de datos habrán de hacerse en una franja horaria que
no intefiera con los procesos de explotación del sistema. Como la organización objetivo de este
87
proyecto es tan genérica, se ha de tener en cuenta la posibilidad de que sea preciso mantener
operativo el sistema de forma ininterrumpida. En ambos casos, se podrá configurar el sistema
para un mejor rendimiento.
Horario de oficina: el sistema realizará los procesos batch, como por ejemplo el ya
indicado, durante el arranque. Se indicarán estas órdenes en los scripts de arranque.
Horario ininterrumpido: se podrá indicar el horario a escoger, mediante la edición de los
ficheros de configuración. Lo más conveniente, como previamente se ha dicho, será realizar
estos procesos cuando menor carga de trabajo sufra el sistema.
Forma de implantación.
Se buscará un proceso de implantación en paralelo. Obviamente, cuando el sistema ya esté
operativo y empiece a funcionar, todos los documentos previamente almacenados en el archivo
no lo estarán en el nuevo sistema. Para ello habrá un tiempo en el cual ambos sistemas coexistan,
hasta que se hayan digitalizado todos los documentos previos. Para ello se dotará al operario del
equipo necesario, ya especificado en el estudio de la arquitectura, para realizar esta
digitalización. Asímismo, se precisará que durante la digitalización de los fondos ya
almacenados, el operario cuente con más personal de apoyo, por el volumen del fondo y la
importancia de que el nuevo sistema entre cuanto antes en plena producción.
88
2. Configuración hardware/software.
Se debe contemplar la especificación de los elementos hardware y software que van a configurar
la plataforma del sistema.
La especificación debe plantearse mediante un gráfico para la configuración hardware y otro
para la configuración software. En el primero, deben recogerse los elementos básicos que van a
conformar la plataforma, y sus interconexiones de comunicación. En el segundo, se representan
los ficheros maestros, bases de datos y productos software que estarán soportados sobre la
plataforma hardware.
Configuración hardware (Imagen 28)
Imagen 28. Modelo hardware.
89
Especificaciones Hardware del Sistema.
Servidor de aplicaciones:
DELL PowerEdge SC1430
Intel Xeon 5110 de doble núcleo.
1 GB de memoria RAM FB a 667 Mhz.
Disco duro SATA 160 GB, 7200 rpm.
Unidad de CD-ROM 48X.
2x Tarjeta de red Gigabit ethernet.
Servidor de base de datos:
DELL PowerEdge SC1430
Intel Xeon 5110 de doble núcleo.
1 GB de memoria RAM FB a 667 Mhz.
Unidad de CD-ROM 48X.
Tarjeta de red Gigabit ethernet.
Terminal operario:
HP Compaq dc7800
Intel Core 2 Duo E4400.
1 GB SDRAM DDR2 667MHz.
Controlador del subsistema de disco SATA, 3 Gb/s.
Unidad DVD-RW SATA SuperMulti LightScribe.
90
Tarjeta gráfica Intel Graphics Media Accelerator 3100.
Tarjeta de interfaz de red Gigabit PCIe Intel Pro 1000 PT.
Terminal usuario:
HP Compac dc5700
Intel Core 2 Duo E2160.
1 GB SDRAM DDR2 667MHz.
Unidada Combo DVD-ROM/CD-RW 48X.
Controladora de disco ATA SMART III a 3 Mb/s.
Tarjeta de interfaz de red Gigabit PCIe Intel Pro 1000 PT.
Configuración Software (Imagen 29)
Imagen 29. Configuración software del sistema.
91
Especificaciones Software del Sistema.
Servidor de aplicaciones:
Sistema Operativo: Debian GNU/Linux, rama estable. Con actualizaciones
periódicas.
Máquina virtual java: Sun JRE 5.0.
Servidor de aplicaciones: JBoss 4.2.1.
Driver JDBC: MySQL Connector/J 5.0.
Framework web: Apache Jakarta Struts 1.3.8.
Servidor de base de datos:
Sistema Operativo: Debian GNU/Linux, rama estable. Con actualizaciones
periódicas.
MySQL 5.0 Database Server – Community Edition.
Terminal operario:
Sistema Operativo: Ubuntu GNU/Linux 7.04.
Suite Ofimática: OpenOffice.org 2.0.4.
Software gestor de scanner: XSane 0.994.
Software OCR: gOCR 0.42.
Terminal usuario:
Sistema Operativo: Ubuntu GNU/Linux 7.04.
Suite Ofimática: OpenOffice.org 2.0.4.
Navegador: Mozilla Firefox 2.0.0.6.
Cliente de correo: Mozilla Thunderbird 1.5.0.12.
92
4.2. DESARROLLO DEL MODELO FÍSICO DEL NUEVO SISTEMA
Llegados a este punto, se ha de profundizar en el Modelo Lógico del Nuevo Sistema, definido en
la fase de Análisis de Requisitos, para obtener un Modelo Físico del nuevo sistema.
Para desarrollar este modelo deben realizarse diferentes actividades:
Establecer las fronteras de mecanización: qué procesos deben realizarse manualmente y
cuáles mediante ordenador.
Determinar los diferentes tipos de procesos, y especificarlos :por lotes, on-line, servicio,
web, su frecuencia y la situación física donde se procesa (servidor de red, servidor web,
estaciones cliente…).
Diseñar las entradas y salidas del sistema: ventanas, informes, formularios y ficheros.
Estimar volúmenes de información e identificar transacciones críticas, para desarrollar el
modelo lógico de datos a partir del conceptual
Definir los controles y seguridad del sistema para su explotación: procesos de control,
seguridad y auditabilidad.
93
Fronteras de mecanización.
Todas las funcionalidades se implementarán para que se realicen de forma automática, salvo la
digitalización de documentos físicos. Esta tarea la realizará de forma manual el operario, con la
ayuda del equipamiento informático pertinente.
Especificación de procesos.
Se realizará una especificación más profunda del MLNS, mediante DFD y una nueva descripción
en el diccionario de datos.
DIAGRAMA DE FLUJO DE DATOS.
Nivel 0.
Diagrama Contextual (Imagen 30)
Imagen 30. Modelo contextual del sistema.
Se mantienen los interfaces del sistema con las entidades externas
94
Nivel 1.
0. Diagrama Conceptual (Imagen 31)
Imagen 31. Modelo conceptual del sistema.
Se puede observar que el nuevo diagrama conceptual se basa claramente en el del modelo lógico.
Los cambios se pueden observar en los niveles inferiores.
95
Nivel 2.
0.1. Entrar.
Controla las entradas al sistema (Imagen 31)
Imagen 31. Entrada al sistema.
En el nivel 3 se podrá observar con detalle en qué consisten los dos subprocesos 0.1.1 y 0.1.2. Se
reincide en el MLNS.
96
0.2. Mostrar pantalla principal (Imagen 32)
Este proceso permite la elaboración de la pantalla principal del sistema.
Imagen 32. Mostrar la pantalla principal.
Se puede observar en este proceso que se introduce la comprobación de permisos, cumpliendo
con el requisito REQ-07 (control de accesos), con el subproceso 0.2.1 que simplemente
comprueba la validez del objeto Session asociado a la petición. En caso de fallo, muestra una
página de error y en caso contrario, dependiendo del tipo de usuario, confecciona la página
principal de una manera u otra.
97
0.3. Control de usuarios (Imagen 33)
Mediante este módulo el operario podrá controlar las altas y bajas de nuevos usuarios, así como
obtener informes al respecto.
Imagen 33. Módulo de control de usuarios.
Tampoco se perciben cambios sustanciales en esta nueva versión del proceso de control de
usuario. Se observará con mayor detalle el funcionamiento de los respectivos subprocesos en el
nivel inferior.
98
Permitirá realizar la consulta del fondo general, por diversos conceptos.
Imagen 34. Consulta del catálogo.
La misma afirmación hecha en el anterior proceso se puede repetir en este caso.
99
0.5. Subir documento (Imagen 35)
Gracias a esta funcionalidad se puede realizar la subida de nuevos documentos o versiones al
sistema.
Imagen 35. Elaboración de la página de subida de documentos.
No se observan cambios respecto al MLNS.
100
Gracias a este procedimiento se perciben los comentarios y características generales de un
documento, así como acceder a las versiones asociadas al mismo.
Imagen 36. Acceso a las características de un documento.
En los niveles inferiores se consigue un mayor nivel de detalle.
101
0.7. Mostrar documento (Imagen 37)
Permite la visualización de las características de una versión específica de un documento en
concreto. Así como la descarga de la misma.
Imagen 37. Mostrar documento.
102
0.8. Informe de nuevos documentos (Imagen 38)
Este proceso, sólo accesible por el operario, permite obtener un informe parametrizable acerca de
los últimos documentos dados de alta. Permite la búsqueda por conceptos.
Imagen 38. Realización de informes de nuevos documentos.
103
Nivel 3.
0.1.2. Comprobar con la BD (Imagen 39)
Este subproceso realiza la comprobación de el nombre de usuario y contraseña, contra la base de
datos.
Imagen 39. Comprobación de contraseñas.
104
0.1.3. Registrar entrada (Imagen 40)
Imagen 40. Registro de una entrada en el sistema.
105
0.3.2. Alta usuario (Imagen 41)
Este método realiza la inserción en la base de datos del par usuario – contraseña deseado.
Imagen 41. Proceso de alta de un usuario.
106
0.3.3. Baja usuario (Imagen 42)
Elimina el usuario solicitado de la tabla usuarios de la base de datos.
Imagen 42. Proceso de baja de un usuario.
107
0.4.1. Elaborar JSP búsqueda (Imagen 43)
Este JSP dará al usuario la capacidad de realizar búsquedas en el fondo general, con diversos
conceptos. Una vez más, se realiza la comprobación de la validez de la sesión antes de mostrar la
página en sí.
Imagen 43. Elaboración de un JSP de búsqueda.
108
0.4.2. Elaborar JSP resultados (Imagen 44)
Este proceso recibe los parámetros del formulario del proceso 0.4.1 y, mediante llamadas a los
EJB correspondientes, elabora la página correspondiente para su muestra al usuario. Otra vez
más se comprueba la validez de la sesión.
Imagen 44. Elaboración de un JSP de resultados.
109
0.5.1. Elaborar JSP subida (Imagen 45)
Especificación en detalle de uno de los subprocesos de la funcionalidad 0.5 –subir documentos-.
No es otra cosa que, una vez más, la lógica de presentación.
Imagen 45. Elaboración de un JSP para subir un archivo.
110
0.5.2. Guardar (Imagen 46)
Lógica de negocio y de acceso a datos asociada a la funcionalidad 0.5. Al ser un método de la
capa empresarial, no se realiza la seguimiento de sesión –el objetivo es realizar el mismo dentro
de la capa de presentación.
Imagen 46. Guardado de un fichero.
111
0.6.1. Elaborar JSP acceso documento (Imagen 47)
Mediante este proceso se elabora de nuevo la presentación en forma de JSP de un documento
genérico, con acceso a sus respectivas versiones.
Imagen 47. Elaboración de un JSP de acceso al documento.
112
0.6.2. Acceder Objeto BD (Imagen 48)
Permite el acceso a la información del documento, almacenada en la base de datos: sinopsis,
versiones, etc.
Imagen 48. Acceso a un objeto de la base de datos.
113
0.7.1. Elaborar JSP versión documento (Imagen 49)
Lógica de presentación del módulo 0.7 –mostrar documento-. Como es usual en el resto de
módulos, realiza, previamente a mostrar nada por pantalla, la comprobación de sesión.
Imagen 49. Generación del JSP de subida de documentos.
114
0.7.2. Descargar (Imagen 50)
Realiza la gestión de las consultas.
Imagen 50. Descarga de un documento.
115
0.8.1. Mostrar JSP informes (Imagen 51)
Lógica de presentación del módulo 0.8 –informe nuevos documentos. También comprueba la
validez de la sesión al comienzo.
Imagen 51. Proceso para mostrar los informes.
116
0.8.2. Generar JSP informe docs (Imagen 52)
Este subprograma recibe los parámetros de búsqueda de 0.8.1 –mostrar JSP informes- y elabora
un informe acorde a lo solicitado. También se realiza el control de acceso a través de la sesión.
Imagen 52. Generación del JSP de informes.
117
0.8.3. Buscar altas (Imagen 53)
Este módulo, encargado de la lógica de negocio del proceso 0.8 –informe docs-, realiza consultas
a la base de datos para obtener los últimos documentos dados de alta, o bien realiza una
búsqueda de éstos de forma acorde a los parámetros que se le pasan.
Imagen 53. Búsqueda de altas.
118
Cada proceso definido en el diccionario de datos del MLNS requiere una descripción más
detallada.
0. Sistema de Gestión documental: proceso. Sistema a desarrollar
0.1. Entrar: proceso. Encargado de controlar el acceso al sistema. Respuesta al requisito
REQ-07.
0.1.1. Mostrar pantalla entrada: proceso. Genera la pantalla inicial, donde se han de
introducir el nombre de usuario y la contraseña respectiva. En caso de ser correctos,
permite la entrada al sistema y anexa a la petición HTTP una sesión identificativa del
usuario.
0.1.2. Comprobar con BD: proceso. Módulo que, dados un nombre de usuario y una
contraseña, consulta en la base de datos si son correctos.
0.1.2.1. Obtener pwd real: proceso. Dados un nombre de usuario y una contraseña,
obtiene de la entidad 8.Usuario la contraseña real del usuario dado.
0.1.2.2. Comparar pwds: proceso. En caso de ser la contraseña almacenada y la
proporcionada por el usuario iguales, devuelve true. En caso contrario o en caso de
error de base de datos, false.
0.1.3. Registrar entrada: proceso encargado de crear el log de accesos al sistema.
119
0.1.3.1. Registrar usuario: proceso. Guarda el nombre de usuario en el almacén
temporal 0.1.3.4.
0.1.3.2. Registrar timestamp: proceso. Guarda la fecha y la hora en el almacén
temporal 0.1.3.4.
0.1.3.3. Consolidar: proceso. Recoge los datos del almacén temporal 0.1.3.4, y los
escribe en la entidad 14.Sesiones.
0.1.3.4. Almacén temporal.
0.2. Mostrar pantalla principal: proceso. Encargado de generar la pantalla principal del
usuario u operario, y enviarla a través del servidor web.
0.2.1. Comprobar permisos: proceso. Si la sesión asociada a la petición es errónea,
redirige al proceso 0.2.2. En caso contrario, reenvía la petición al proceso 0.2.4 ó 0.2.5.
0.2.2. Mostrar error: proceso. Envía al usuario un documento HTML indicando un error
de autenticación, contenido en el almacén 9. Páginas estáticas.
0.2.3. Elaborar JSP usuario: proceso. Confecciona el JSP de la página principal para un
usuario genérico.
0.2.4. Elaborar JSP operario: proceso. Confecciona el JSP de la página principal para el
operario, con más opciones que el de un usuario genérico: el módulo de control de
usuarios –0.3-, y el informe de documentos dados de alta –0.8.
0.3. Control usuarios: proceso. Módulo accesible sólo para el operario, cuya función es la
120
administración de usuarios del sistema.
0.3.1. Mostrar pantalla usuarios: proceso. Genera la pantalla donde se da de alta nuevos
usuarios, o dar de baja otros ya existentes.
0.3.2. Dar de alta usuarios: proceso. Interactúa con la base de datos, insertando en la
misma un nuevo par nombre de usuario – contraseña ya dados. Devuelve un mensaje de
éxito, o de error en caso de ya existir un usuario con el mismo nombre.
0.3.2.1. Comprobar existencia usuario: proceso. Comprueba si el usuario dado ya
existe en la base de datos. En tal caso, interrumpe el proceso 0.3.2 con un mensaje de
error.
0.3.2.2. Introducir usuario en la BD: proceso. Escribe en la entidad 8.Usuario el
par nombre de usuario – contraseña deseados en un principio. Devuelve un mensaje
de confirmación.
0.3.3. Dar de baja usuarios: proceso. Interactúa con la base de datos, borrando de la
misma un par nombre de usuario – contraseña. Devuelve un mensaje de éxito o fallo.
0.3.3.1. Comprobar existencia de usuario: proceso. Comprueba si el usuario
deseado existe en la base de datos, en caso contrario interrumpe el proceso 0.3.3 con
un mensaje de error.
0.3.3.2. Borrar usuario de la BD: proceso. Borra de la entidad 8.Usuario el par
nombre de usuario dado – contraseña asociada. Devuelve un mensaje de
confirmación.
121
0.3.4. Mostrar últimos accesos: proceso. Genera la pantalla donde el operador puede
observar los últimos usuarios que han accedido al sistema. Por defecto muestra los 10
últimos, pero permite seleccionar usuarios por diversos conceptos: fecha, usuario,
módulo funcional, etc.
0.3.5. Mostrar X accesos: proceso. Genera la página donde el operador puede observar
los últimos accesos que cumplen con el patrón indicado en el proceso 0.3.4.
0.3.6. Mostrar accesos: proceso. Devuelve los accesos que cumplen con el patrón dado.
0.4. Consultar catálogo: proceso. Este módulo permite realizar pesquisas en el archivo
general, tomando como filtro diversos campos.
0.4.1. Mostrar JSP de búsqueda: proceso. Genera la pantalla donde el usuario puede
realizar búsquedas sobre el catálogo general. Permitirá realizar las mismas por diversos
conceptos.
0.4.1.1. Comprobar permisos: proceso. Comprueba la validez de la sesión asociada
a la petición. En caso de error redirige al proceso 0.4.1.2, en caso contrario reenvía a
0.4.1.3.
0.4.1.2. Mostrar error: proceso. Envía al usuario un mensaje de error almacenado
en 9.Páginas estáticas.
0.4.1.3. Elaborar JSP búsqueda: proceso. Elabora la página de búsqueda. Permite
realizarla por varios conceptos distintos.
0.4.2. Mostrar JSP resultados: proceso. Genera la pantalla de resultados a la consulta

122
realizada en 0.4.1. Permite seleccionar cualquiera de los resultados obtenidos.
0.4.1.3.
0.4.2.3. Elaborar JSP resultados: proceso. A partir de los parámetros 0.4.3 pasados,
realiza peticiones para elaborar una página de resultados.
0.4.3. Datos búsqueda: flujo de datos.
COMPONENTES
-Parámetros: lista de condiciones escogidas para la búsqueda.
DESCRIPCIÓN
Cuando el JSP generado por el proceso 0.4.1 realiza una petición, dicha petición tendrá
una serie de condiciones. Dichas condiciones están contenidas en este flujo de datos.
0.5. Subir elemento: proceso. Su función consiste en administrar la adición de nuevos
contenidos al sistema.
0.5.1. Mostrar pantalla subir documento: proceso. Genera la pantalla que permite al
usuario subir nuevos documentos, o versiones, al sistema.
123
0.5.1.3.
0.5.1.3. Elaborar JSP subida: proceso. Elabora el JSP con el formulario de subida
de documentos al servidor.
0.5.2. Guardar: proceso. Recibe el documento remitido por el usuario, y se encarga de
almacenar el mismo en la base de datos, identificándolo con el IDFile y la versión
indicados.
0.5.2.1. Comprobar existencia documento: proceso. Realiza una búsqueda en la
entidad 11.Documentos para comprobar si el que se intenta subir existe ya. En tal
caso, redirige al proceso 0.5.2.3, en caso contrario al 0.5.2.2.
0.5.2.2. Generar IDFile: proceso. Utilizado en caso de subida de un nuevo
documento. Número aleatorio, no puede estar repetido en la entidad 11.Documentos.
0.5.2.3. Generar IDVersión: proceso. Número aleatorio, no puede estar repetido en
la entidad 12.Versiones.
0.5.2.4. Guardar upload: proceso. Almacena el documento subido por el usuario en
la entidad 12.Versiones, y devuelve un mensaje de confirmación o error.
0.6. Acceder documento: proceso. Permite seleccionar un documento dado, y muestra las
posibles acciones a realizar sobre éste.
124
0.6.1. Mostrar página acceso documento: proceso. Genera y envía a través del servidor
web la pantalla de selección de un documento dado, permitiendo diversas opciones, tales
como descarga o análisis de las distintas versiones del mismo.
0.6.1.2.
0.6.1.2. Generar JSP acceso: proceso. Genera el JSP asociado al proceso 0.6.1,
tomando datos de las entidades 11.Documentos y 12.Versiones.
0.6.2. Acceder objeto en la BD: proceso. Dado un IDFile, retorna los identificadores de
las diversas versiones que hay almacenadas del mismo en el sistema.
0.6.2.1. Obtener información documento: proceso. Obtiene información acerca del
IDFile dado, de la entidad 10.Documentos y la almacena en 0.6.2.3.
0.6.2.2. Obtener información versiones: proceso. Obtiene información referente a
las distintas versiones del documento dado, y las almacena en 0.6.2.3.
0.6.2.3. Almacén temporal.
0.6.2.4. Recopilar información: proceso. Recoge el contenido de 0.6.2.3 y lo
redirige a la salida.
125
0.7. Mostrar documento: proceso. Posibilita la descarga del documento al ordenador del
usuario.
0.7.1. Elaborar JSP versión documento: proceso. Dados un IDFile y una de sus
versiones, genera la pantalla que permite descargar el documento asociado. También
permite solicitar la subida de una nueva versión del mismo documento asociado al
IDFile.
0.7.1.2.
0.7.1.2. Elaborar JSP acceso versión: proceso. Obtiene la información necesaria de
las entidades 10.Documentos y 11.Versiones para elaborar la página de acceso a una
determinada versión de un documento dado.
0.7.2. Descargar: proceso. Dado un IDFile y una versión, devuelve al usuario el
documento en sí a través del flujo 4. Download.
0.7.2.1. Grabar consulta: proceso. Antes de realizar la descarga del documento
solicitado, la registra en la entidad 13.Consultas.
0.7.2.2. Obtener de la base de datos: proceso. Extrae el archivo deseado de la base
de datos, y lo reenvía como respuesta a la petición a 0.7.2.
126
0.8. Informe nuevos documentos: proceso. Permite al usuario consultar cuales han sido los
últimos documentos dados de alta en el sistema.
0.8.1. Generar JSP informes: proceso. Genera la pantalla que permite al operario
observar cuáles son los últimos documentos y versiones dados de alta. También permite
un informe más exhaustivo, indicando los parámetros deseados.
0.8.1.2.
0.8.1.2. Elaborar JSP acceso versión: proceso. Obtiene la información necesaria
del proceso 0.8.3.Buscar altas para elaborar el informe por defecto, con los nuevos
documentos que todavía no han sido auditados. Asímismo, muestra el formulario para
obtener informes más detallados.
0.8.2. Generar informe docs: proceso. Genera el informe con los parámetros indicados
por el procedimiento 0.8.1.2.
0.8.2.2.
0.8.2.2. Generar JSP: proceso. Tras obtener los parámetros remitidos por 0.8.1.3,
127
solicita a 0.8.3 una búsqueda acorde a tales parámetros, y elabora la página de
resultados con los datos obtenidos en respuesta.
0.8.2.3. Esperar eventos: proceso.
0.8.3. Buscar altas: proceso. Permite consultar a la base de datos documentos dados de
álta, por diversos conceptos.
0.8.3.1. Recopilar datos: proceso. Realiza la búsqueda en la entidad 12.Versiones
conforme a los parámetros recibidos con 0.8.4.
0.8.3.2. Elaborar respuesta: proceso. Empaqueta los datos obtenidos en el proceso
0.8.3.1 de la entidad 12.Versiones como respuesta a la llamada al proceso.
0.8.4. Parámetros: flujo de datos.
COMPONENTES
-Condiciones: lista de parámetros pasados a 0.8.3.Buscar altas.
DESCRIPCIÓN
Este flujo de datos es utilizado por el proceso 0.8.2 cada vez que necesite realizar una
consulta parametrizada.
0.8.5. Parámetros forward: flujo de datos.
COMPONENTES
-Condiciones: conjunto de parámetros que se pasan con el HTTPServletRequest.
128
DESCRIPCIÓN
Este flujo de datos es utilizado por el proceso 0.8.1 cada vez que solicite una búsqueda
parametrizada a 0.8.2.
0.10. Forward: flujo de datos.
COMPONENTES
-Destino: URI del proceso destino.
DESCRIPCIÓN
Siempre que se desee redirigir de un proceso a otro sin perder la sesión asociada a la
petición, se utilizará este flujo de datos.
0.11. Redirección: flujo de datos.
COMPONENTES
-Destino: URI del proceso destino.
DESCRIPCIÓN
Siempre que se desee redirigir a una página de error por autentificación, se utilizará este
flujo de datos. Supondrá una pérdida de la sesión asociada a la petición.
1. Operario: entidad externa. Tiene los privilegios necesarios para administrar el sistema.
2. Usuario: entidad externa. Cliente sin privilegios.
3. Acción: flujo de datos.
COMPONENTES
-Evento: click de ratón, texto introducido...
DESCRIPCIÓN
129
Cada vez que un usuario interactúa con el sistema a través de una pantalla remota, ya sea
realizando un click de ratón, introduciendo un texto por teclado o cualquier tipo de evento que se
pretenda capturar, éste será capturado en el flujo de datos acción.
4. Download: flujo de datos.
COMPONENTES
-Fichero: documento anexado a la respuesta HTTP.
DESCRIPCIÓN
Respuesta del sistema al cliente cada vez que solicite la descarga a su equipo de uno de sus
recursos. No es otra cosa que una respuesta HTTP, con el respectivo fichero anexado como
parámetro.
5. Upload: flujo de datos.
COMPONENTES
-Fichero: documento anexado a la petición HTTP.
DESCRIPCIÓN
Petición del usuario al sistema, cada vez que se pretende subir un documento al sistema.
Consiste en una petición HTTP, con el respectivo fichero anexado en forma de parámetro.
6. user/pwd: flujo de datos.
COMPONENTES
-Usuario: campo cadena anexado a la petición HTTP.
-Contraseña: campo cadena anexado a la petición HTTP.
DESCRIPCIÓN
Par nombre de usuario – contraseña que introduce el mismo cuando intenta acceder al sistema.
130
7. HTML: flujo de datos.
COMPONENTES
-Text: texto escrito en forma de código de marcado.
-Archivos: imágenes, hojas de estilo, etc.
DESCRIPCIÓN
El sistema estructurará sus todas sus respuestas al usuario (exceptuando el caso del flujo de
datos 4. Download) en forma de código de marcado que enviará al navegador web de éste y otros
ficheros anexos a esta tecnología.Usuarios: almacén.
8. Usuarios: entidad de datos.
CONTENIDO
-IDUser: identificador del usuario, entero largo.
-Nombre: nombre de usuario, cadena.
-pwd: contraseña del usuario, cadena.
-Fecha: hora y fecha de creación del usuario.
DESCRIPCIÓN
Esta entidad contiene los datos referidos a la autentificación de usuarios. El campo pwd estará
codificado mediante un algoritmo de clave simétrica, probablemente blowfish.
9. Páginas estáticas: almacén.
CONTENIDO
-Páginas: ficheros HTML.
DESCRIPCIÓN
Este almacén de datos contiene páginas estáticas que se utilizarán en la plataforma.
131
10. Directorio: entidad de datos.
CONTENIDO
-IDDir: identificador del directorio, entero largo.
-IDPadre: IDDir del directorio superior, entero largo.
-NombreDir: nombre del directorio, cadena.
DESCRIPCIÓN
Esta entidad puede ser usada para caracterizar los documentos con una estructura jerárquica,
con una estructura de directorios. El directorio superior tendrá IDPadre = NULL.
11. Documentos: entidad de datos.
CONTENIDO
-IDDoc: identificador de un documento, entero largo.
-Título: nombre del documento, cadena.
-Área temática: cadena.
-Sinópsis: cadena.
-IDDir: identificador del directorio que lo contiene, entero largo.
DESCRIPCIÓN
Esta entidad permitirá clasificar los diversos documentos por nombre, área temática, etc.
12. Versiones: entidad de datos.
CONTENIDO
-IDVersion: identificador de la versión, entero largo.
-Fecha Versión: fecha y hora del momento de introducción, time stamp.
-Comentario: cadena.
-Fichero: documento en formato binario, ya que puede tratarse de un txt, pdf, doc, odt… Por
132
lo tanto, ha de ser un tipo BLOB (255-65535 bits), MEDIUMBLOB (hasta 16777215 bits) o
LONGBLOB (hasta 4.294.967.295 bits) .
-IDDoc: identificador del documento al que pertenece el documento, entero largo. .
-Auditado: switch para indicar si un documento ha sido auditado ya o no, tipo bit.
DESCRIPCIÓN
Cada versión de documento vendrá caracterizada finalmente por su digitalización completa.
Ésta será almacenada finalmente en esta tabla.
13. Consultas: entidad de datos.
CONTENIDO
-IDConsulta: identificador de la consulta, entero largo.
-IDVersión: identificador de la versión de documento accedida, entero largo.
-Fecha consulta: fecha y hora del acceso, time stamp.
-IDSesión: identificador de la sesión en la cual se realizó la consulta.
DESCRIPCIÓN
Esta entidad es añadida para la posible adición en el futuro de un módulo de auditoría de
consultas, así como para su análisis en caso de necesidad por seguridad.
14. Sesiones: entidad de datos.
CONTENIDO
-IDSesión: identificador de la sesión, entero largo.
-IDUser: identificador del usuario autentificado, entero largo.
-Inicio: fecha y hora en la que el usuario se autentificó, time stamp.
-Fin: fecha y hora en que la sesión caducó por inactividad, time stamp.
DESCRIPCIÓN
133
La sesión de un usuario comenzará en el momento en el cual éste introduzca de modo exitoso
su nombre de usuario y contraseña en el módulo correspondiente, y finalizará una vez caduque la
misma por inactividad. En esta entidad quedan almacenadas todas las sesiones con fines de
auditoría posterior.
OBTENCIÓN DE UN MODELO FÍSICO DE DATOS.
[RIVE92] En el análisis de requisitos se obtuvo un modelo conceptual de datos general que sirve
como modelo para el posterior desarrollo de la base de datos. A continuación se desarrollan una
serie de procesos que llevan a la consecución de una base de datos completamente optimizada,
sin información redundante ni problemas estructurales.
Conjunto de Dependencias Funcionales.
a) IDSesión → Inicio j) IDVersión → IDDoc
b) IDSesión → Fin k) IDVersión → Fecha Versión
c) IDSesión → IDUser l) IDVersión → Comentario
d) IDUser → Nombre m) IDVersión → Fichero
e) IDUser → Usuario n) IDConsulta → Fecha Consulta
f) IDUser → pwd o) IDConsulta → IDVersión
g) IDDoc → Título p) IDConsulta → IDUser
h) IDDoc → Área Temática q) IDConsulta → IDSesión
i) IDDoc → Sinopsis r) IDConsulta → IDDoc
134
s) IDDoc → IDDir w) IDUser → FechaUser
t) IDDir → IDPadre x) IDUser → IDGrupo
u) IDDir → NombreDir y) IDGrupo, IDUser → Derecho
v) IDVersión → Auditado z) IDGrupo → NombreGrupo
De este conjunto de Dependencias Funcionales se puede extraer un diagrama de dependencias,
en el que se pueden observar problemas de redundancia (Imagen 54).
Imagen 54. Diagrama de dependencias de la base de datos inicial.
135
Descomposición de una relación.
Proceso en el cual se divide una relación R en una serie de relaciones R1, R2, ... Rn; tales que la
unión de sus atributos es igual al conjunto de atributos de R. Una buena descomposición cumple
con dos propiedades:
• Reversibilidad por yunción: el conjunto de Ri obtenidas, han de resultar en la relación
original al realizar la yunción entre sí.
• Mantenimiento de dependencias: la unión de los nuevos conjuntos de dependencias
funcionales, han de resultar en el conjunto de dependencias funcionales original.
• No repetición de información, aunque a veces no será posible.
Anomalías de actualización
En los casos de dependencias funcionales, en las cuales el antecedente no sea superclave de la
relación, puede dar lugar a anomalías en operaciones de mantenimiento. Tales anomalías se
pueden manifestar en operaciones de mantenimiento, inserción y borrado. Por el contrario, si el
antecedente es superclave, no existirán este tipo de problemas.
Formas normales.
Se tratan de formas de medir la corrección de un diseño y, por tanto, sus problemas de
actualización o mantenimiento. De este modo, y de mayor a menor grado de corrección, se
pueden clasificar las relaciones en:
136
• Primera Forma Normal: tiene claves correctas, y no forma grupos repetitivos. Sus
atributos son todos atómicos.
• Segunda Forma Normal: no contiene dependencias parciales, es decir, todas sus
dependencias tienen como antecedente la clave de la relación.
• Tercera Forma Normal: no contiene dependencias parciales, ni transitivas. Todas sus
dependencias, o bien tienen el antecedente superclave, o el consecuente atributo primario.
• Forma Normal de Boyce Codd: cada una de sus dependencias funcionales no triviales,
cumple que su antecedente sea superclave.
• Cuarta y Quinta Formas Normales: referentes a las dependencias plurales, no existentes
en el sistema desarrollado y por lo tanto no aplicables en este caso.
Si una relación cumple con determinada forma normal, también lo hará con las anteriores, esta
clasificación está ordenada de modo que haya menor riesgo de anomalías de actualización cuanto
mayor grado de normalización se consiga.
4.2.1. OBTENCIÓN DE UN MODELO DE DATOS NORMALIZADO
El conjunto de dependencias obtenido presenta anomalías de actualización, porque hay
dependencias cuyo antecedente no es clave de R. Por ello conviene descomponer la misma para
alcanzar un nivel de normalización aceptable.
137
Conjunto mínimo.
a) IDSesión → Inicio n) IDConsulta → Fecha Consulta
b) IDSesión → Fin o) IDConsulta → IDVersión
c) IDSesión → IDUser p) IDConsulta → IDUser
d) IDUser → Nombre q) IDConsulta → IDSesión
e) IDUser → Usuario r) IDConsulta → IDDoc
f) IDUser → pwd s) IDDoc → IDDir
g) IDDoc → Título t) IDDir → IDPadre
h) IDDoc → Área Temática u) IDDir → NombreDir
i) IDDoc → Sinopsis v) IDVersión → Auditado
j) IDVersión → IDDoc w) IDUser → FechaUser
k) IDVersión → Fecha Versión x) IDUser → IDGrupo
l) IDVersión → Comentario y) IDDoc, IDGrupo → Derecho
m) IDVersión → Fichero z) IDGrupo → NombreGrupo
La dependencia r es redundante respecto de las dependencias q y c. P lo es respecto de o y j. De
138
esta manera se han eliminado las dependencias redundantes.
Primera Forma Normal.
El conjunto de dependencias funcionales obtenido, ya cumple con las condiciones para estar en
primera forma normal.
Segunda Forma Normal.
Se ha de realizar una serie de transformaciones para conseguir un modelo de datos con este
grado de normalización. A continuación, se detallan estas transformaciones:
R(IDConsulta, IDVersión, IDSesión, FechaConsulta, Inicio, Fin, IDUser, Nombre, Usuario,
pwd, FechaUser, IDVersión, Comentario, Fichero, FechaVersión, IDDoc, Título,
ÁreaTemática, Sinopsis, IDDir, IDPadre, NombreDir, Auditado, FechaUser, Derecho,
IDGrupo, NombreGrupo)
CM(R) = {a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, q, s, t, u, v, w, x, y, z}
Se divide R en R1 y RI:
R1(IDDir, IDPadre, NombreDir)
t) IDDir → IDPadre
u) IDDir → NombreDir
139
Imagen 55. Entidad Directorio
RI(IDConsulta, IDVersión, IDSesión, FechaConsulta, Inicio, Fin, IDUser, Nombre, Usuario,
pwd, FechaUser, IDVersión, Comentario, Fichero, FechaVersión, IDDoc, Título,
ÁreaTemática, Sinopsis, IDDir*, Auditado, FechaUser, Derecho, IDGrupo, NombreGrupo)
CM(RI) = {a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, q, s, v, w, x, y, z }
Se divide RI en R2 y RII:
R2(IDDoc, Título, ÁreaTemática, Sinopsis, IDDir*)
g) IDDoc → Título
h) IDDoc → ÁreaTemática
i) IDDoc → Sinopsis
s) IDDoc → IDDir
140
Imagen 56. Entidad Documentos
RII(IDConsulta, IDVersión, IDSesión, FechaConsulta, Inicio, Fin, IDUser, Nombre, Usuario,
pwd, FechaUser, IDVersión, Comentario, Fichero, FechaVersión, IDDoc*, Auditado,
FechaUser, Derecho, IDGrupo, NombreGrupo)
CM(RII)={ a, b, c, d, e, f, j, k, l, m, n, o, q, v, w , x, y, z }
Se divide RII en R3 y RIII:
R3(IDDoc, IDGrupo, Derecho)
x) IDDoc, IDGrupo → Derecho
141
Imagen 57. Entidad Derechos
RIII(IDConsulta, IDVersión, IDSesión, FechaConsulta, Inicio, Fin, IDUser, Nombre, Usuario,
pwd, FechaUser, IDVersión, Comentario, Fichero, FechaVersión, IDDoc*, Auditado,
FechaUser, IDGrupo, NombreGrupo)
CM(RII)={ a, b, c, d, e, f, j, k, l, m, n, o, q, v, w, y, z}
Se divide RIII en R4 y RIV:
R4 (IDVersión, FechaVersión, Comentario, Fichero, Auditado, IDDoc*)
j) IDVersión → IDDoc
k) IDVersión → FechaVersión
l) IDVersión → Comentario
m) IDVersión → Fichero
v) IDVersión → Auditado
142
Imagen 58. Entidad Versiones
RIV (IDConsulta, IDVersión*, IDSesión, FechaConsulta, Inicio, Fin, IDUser, Nombre, Usuario,
pwd, FechaUser, IDGrupo, NombreGrupo)
CM(RIV) = { a, b, c, d, e, f, n, o, q, w, y, z}
Se divide RIV en R5 y RV:
R5(IDGrupo, NombreGrupo)
z) IDGrupo → NombreGrupo
143
Imagen 59. Entidad Grupos
RV (IDConsulta, IDVersión*, IDSesión, FechaConsulta, Inicio, Fin, IDUser, Nombre, Usuario,
pwd, FechaUser, IDGrupo*)
CM(RV) = { a, b, c, d, e, f, n, o, q, w, y }
Se divide RV en R6 y RVI:
R6 (IDUser, Nombre, Usuario, pwd, FechaUser, IDGrupo*)
d) IDUser → Nombre
e) IDUser → Usuario
f) IDUser → pwd
w) IDUser → FechaUser
y) IDUser → IDGrupo
144
Imagen 59. Entidad Usuarios
RVI (IDConsulta, IDVersión*, IDSesión, FechaConsulta, Inicio, Fin, IDUser*)
CM(RIV) = { a, b, c, n, o, q }
Finalmente se divide RVI en R7 y R8:
R7 (IDSesión, IDUser*, Inicio, Fin)
a) IDSesión → Inicio
b) IDSesión → Fin
c) IDSesión → IDUser
145
Imagen 60. Entidad sesiones
R8 (IDConsulta, IDVersión*, FechaConsulta, IDSesión*)
n) IDConsulta → FechaConsulta
o) IDConsulta → IDVersión
q) IDConsulta → IDSesión
146
Imagen 61. Entidad Consultas
Tercera Forma Normal - Forma Normal de Boyce-Codd.
La tercera forma normal se obtiene en el momento en el que todas las dependencias funcionales,
tienen como antecedente una clave de la relación. En el caso de la forma normal de Boyce-Codd,
su requisito es que todo antecedente sea la superclave de su relación.
Por lo tanto, el modelo obtenido en la segunda forma normal, cumple también los requisitos para
estar en tercera forma normal y forma normal de Boyce-Codd.
147
El modelo resultante da lugar a un diseño de la base de datos con unas tablas tal como se detalla
a continuación (Imagen 62).
Imagen 62. Estructura de la base de datos normalizada.
148
5. PROGRAMACIÓN
El objetivo de esta nueva fase es la de transformar todos los diagramas generados con el Modelo
Físico del Nuevo Sistema, en el sistema a desarrollar. De todos modos, y como se puede
suponer, la fiabilidad, economía y eficiencia del sistema no va a depender únicamente de un
buen diseño previo, sino también de otros factores como el lenguaje de programación escogido.
En esta fase se inician las pruebas unitarias del software. Cada programador ha de garantizar el
buen funcionamiento de su pieza de software, no ha de detenerse ante una correcta compilación
del código fuente sino que se han de probar todas las eventualidades que puedan surgir, para
evitar posteriores sorpresas que, probablemente, puedan suponer mayores dolores de cabeza de
los debidos.
La sucesión de eventos que se realizaron en esta fase de programación fue la siguiente:
1. Implantación del modelo normalizado de base de datos obtenido en la fase anterior,
sobre el servidor MySQL.
2. Realización de los respectivos EJBs de entidad, para controlar el contexto de persistencia
149
o relación con la base de datos MySQL, y despliegue de los mismos en JBoss.
3. Codificación de la lógica de negocio asociada, mediante EJB de sesión sin estado
5.1. PRUEBAS UNITARIAS
Estas pruebas consisten en comprobar la funcionalidad del programa o subprograma, de acuerdo
con las especificaciones indicadas en el Modelo Físico del Nuevo Sistema.
Para realizar este tipo de pruebas, el programador dispone de herramientas depuradoras. Estas
herramientas permiten la ejecución de un programa paso a paso y el examen de las variables
locales y de entorno que se desee. De este modo, se pueden provocar los diversos escenarios de
ejecución que puedan darse durante la vida de la aplicación. En el entorno de desarrollo
escogido, Eclipse, ya hay integrada una herramienta de este tipo muy eficiente.
150
6. PRUEBAS DEL SISTEMA
Tras desarrollar y probar cada uno de los componentes que integrarán el nuevo sistema, se
realizarán una serie de pruebas con el objetivo de una mejor integración del sistema. De este
modo, se someterá al sistema y sus componentes a una serie de verificaciones para obtener una
mayor fiabilidad, con la misma seriedad y rigor con el que se ha desarrollado el resto del sistema.
Estas pruebas han de realizarse sobre un entorno lo más parecido al de producción real. En
nuestro caso, se realizaron las pruebas sobre el mismo entorno de producción, tras realizar las
respectivas copias de seguridad.
6.1. ENTORNO DE PRUEBAS
Se trata de un entorno apropiado donde realizar las pruebas de software. Por lo tanto, ha de tener
una arquitectura hardware y software similar al entorno final de producción, donde se ha de
instalar y explotar el sistema final.
151
Suele adaptarse y configurarse antes de cada una de las pruebas, para encontrar un sistema
análogo al de producción en el que no hayan interferido las pruebas previas. Asimismo, se suele
cargar un volumen de datos de ejemplo representativo, para llevar a cabo cada prueba.
Existen una serie de herramientas para realizar cada tipo de prueba.
6.2. TIPOS DE PRUEBAS REALIZADAS
Se han de realizar una serie de pruebas diversas, cada una con distintos objetivos. En el sistema
desarrollado se ha optado por las siguientes pruebas, cuyo objetivo no es otro sino comprobar la
funcionalidad y rendimiento exigido en los requisitos, en adición a las pruebas unitarias previas.
• Pruebas de encadenamiento.
Tras comprobar el correcto funcionamiento de cada componente mediante sus respectivas
pruebas unitarias, mediante estas pruebas se comprueba la comunicación entre ellos. En los
sistemas online como es el caso a tratar, se comprueban las comunicaciones y llamadas remotas
de unos módulos a otros.
Para ello se han utilizado las librerías JUnit sobre los procesos de negocio. De este modo, y tras
comprobar que la persistencia en la base de datos se realiza correctamente, obtenemos un nivel
de fiabilidad importante.
152
• Pruebas de integración.
Tras las pruebas de encadenamiento entre procesos, se han de integrar éstos. En este aspecto es
sobre el que este tipo de pruebas actúa, pudiendo realizarse por partes o de forma íntegral. Tras
comprobar la integración con sus interfaces de entrada, salida y externos, se ha de proceder a
comprobar la funcionalidad respecto a los requisitos que en su momento se plantearon.
• Pruebas de explotabilidad del sistema.
Su razón de ser es determinar la facilidad a la hora de la explotación del sistema. Se realiza
especial hincapié en las tareas administrativas.
• Pruebas de seguridad.
En todo sistema se han de incorporar mecanismos de seguridad, que se activarán al acceder el
sistema y las funciones permitidas para el usuario dado. Si se trata de una aplicación web, se
habrá definido una arquitectura segura mediante un firewall, conexiones SSL, proxies,
directorios LDAP, etc.
• Pruebas de aceptación del usuario.
Estas pruebas son realizadas por el usuario, bien desde el entorno de pruebas o su propio entorno
de trabajo.
153
• Pruebas de usabilidad.
En este caso, debido a estar enfocado el sistema a usuarios genéricos, se ha de comprobar la
facilidad de uso del sistema. De este modo, se entiende por usabilidad como el diseño del
interfaz de usuario.
Un punto importante es la posible formación a impartir a los usuarios, ya que el usuario puede
detectar errores de diseño o funcionamiento que los técnicos no.
6.3. MANUAL DE INSTALACIÓN Y CONFIGURACIÓN
DESCRIPCIÓN GENERAL DE LA ARQUITECTURA.
La arquitectura escogida, ya previamente explicada en la fase de Estudio de la Arquitectura, tiene
la siguiente estructura (Imagen 63).
154
Imagen 63. Estructura de la arquitctura del sistema.
6.3.1. INSTALACIÓN DE UBUNTU LINUX
Este sistema operativo es fácil de instalar. A continuación se muestran los diversos pasos a
realizar para obtener una plataforma completamente funcional.
155
1. Arranque desde el CD.
Imagen 64
Para comenzar la instalación se ha de introducir el CD de Ubuntu Linux en la unidad de CD-
ROM (Imagen 64). Tras reiniciar el sistema, el administrador estará observando esta pantalla,
donde podrá escoger entre diversas opciones: la que se ha de escoger es la primera.
156
2. Escoger el idioma.
Imagen 65
Tras varios segundos en los que se cargarán los datos necesarios desde el CD, el administrador
obtendrá esta pantalla donde escoger el idioma del resto de la instalación (Imagen 65).
157
3. Escoger la distribución del teclado.
Imagen 66
En la siguiente pantalla (Imagen 66), el administrador podrá escoger la variante de teclado de su
equipo.
158
4. Datos personales y contraseña.
Imagen 67
El cuarto paso a realizar durante la instalación será la introducción de datos personales del
usuario final del equipo, así como su contraseña y el nombre del ordenador (Imagen 67).
159
5. Preparando el disco.
Imagen 68
En la pantalla siguiente (Imagen 68) el administrador podrá realizar la partición manual del disco
duro, la opción recomendada es que el propio Ubuntu realice un particionamiento automático.
160
6. Proceso de instalación.
Imagen 69
El administrador habrá de esperar unos minutos para tener un sistema operativo, en esta etapa se
realizará el particionamiento escogido, y se copiarán datos desde el CD al disco duro (Imagen
69).
7. Instalación finalizada.
Imagen 70
Cuando termine la instalación del sistema operativo, el administrador podrá observar esta
161
ventana. Se escogerá la opción “Reiniciar ahora”, y se sacará el CD de instalación de su
correspondiente unidad (Imagen 70).
6.3.2. INSTALACIÓN DEL SDK 5.0 DE SUN MICROSYSTEMS
Una vez realizada la instalación del sistema operativo Ubuntu, lo siguiente que se ha de realizar
es la instalación del JDK en el servidor de aplicaciones.
Para ello, el administrador ha de dirigirse a la línea de comandos, e iniciar una sesión como
usuario root. Una vez allí, ha de teclear los comandos dados en el Cuadro 1.
root@servidor_apps: /home/administrador# apt-get update
[...]
root@servidor_apps: /home/administrador# apt-get dist-upgrade
[...]
root@servidor_apps: /home/administrador# apt-get install sun-
java5-jdk
[...]
root@servidor_apps: /home/administrador# reboot
Cuadro 1
Gracias a estos comandos se tendrá completamente instalada, tras el reinicio, la máquina virtual
Java 5.0 de Sun Microsystems, así como sus respectivas herramientas de desarrollo.
162
6.3.3. INSTALACIÓN DEL SERVIDOR DE APLICACIONES JBOSS
[WWW03] Se ha de descargar la versión estable más reciente del servidor JBoss de la página
web http://labs.jboss.com/jbossas/downloads . Para el desarrollo se ha utilizado la versión 4.2.0
del servidor (incluida en el CD-ROM), pero cualquier versión posterior a la 4.0 tiene soporte
para la versión 3.0 de EJB y por lo tanto podría servir.
Tras descomprimir el archivo en el directorio deseado (en adelante, <DIR_JBOSS>), se han de
configurar las respectivas variables de entorno. Concretamente, se ha de añadir la línea siguiente
al archivo /etc/environment (Cuadro 2):
JBOSS_HOME=”<DIR_JBOSS>”
Cuadro 2
Para que el sistema reconozca esta variable de entorno, es necesario reiniciar el equipo.
Para conseguir que se arranque automáticamente tras cada reinicio del servidor, se ha de editar el
archivo /etc/init.d/jboss tal como se indica a continuación [WWW03] (Cuadro 4):
#! /bin/sh
# /etc/init.d/jboss: Start and stop JBoss AS
ECHO=/bin/echo
TEST=/usr/bin/test
JBOSS_START_SCRIPT=$JBOSS_HOME/bin/run.sh
JBOSS_STOP_SCRIPT=$JBOSS_HOME/bin/shutdown.sh
$TEST –x $JBOSS_START_SCRIPT || exit 0

$TEST –x $JBOSS_STOP_SCRIPT || exit 0
163
start() {
$ECHO –n “Starting Jboss”
su – jboss –c “$JBOSS_START_SCRIPT > /dev/null 2> /dev/null
&”
$ECHO “.”
}
stop() {
$ECHO –n “Stopping Jboss”
su – jboss –c “$JBOSS_STOP_SCRIPT –S > /dev/null &”
$ECHO “.”
}
case “$1” in
start)
start
;;
stop)
stop
;;
restart)
stop
sleep 30
start
;;
*)
$ECHO “Usage: jboss {start|stop|restart}”
exit 1
esac
exit 0
Cuadro 4
Tras esto, se han de ejecutar los siguientes comandos (Cuadro 5).
root@servidor_apps: /home/administrador# sudo chmod +x
/etc/init.d/jboss
[...]
root@servidor_apps: /home/administrador# update-rc.d jboss
defaults
164
[...]
Cuadro 5
6.3.4. INSTALACIÓN DEL FRAMEWORK STRUTS
Descargar el archivo http://apache.rediris.es/struts/binaries/struts-1.3.8-all.zip, descomprimirlo
en el directorio <DIR_JBOSS>/server/default/lib/.
6.3.5. INSTALACIÓN DE MySQL
El administrador ha de entrar en el servidor de aplicaciones, como usuario root. Una vez allí, se
dirigirá a la línea de comandos y tecleará los siguientes comandos (Cuadro 6).
root@servidor_apps: /home/administrador# apt-get update

[...]
root@servidor_apps: /home/administrador# apt-get dist-upgrade
[...]
root@servidor_apps: /home/administrador# apt-get install mysql-
server
[...]
root@servidor_apps: /home/administrador# /usr/bin/mysqladmin –u root
password clavenueva
Cuadro 6
Para que MySQL acepte conexiones del servidor del equipo servidor de aplicaciones, se ha de
editar el archivo /etc/mysql/my.cnf , sustituyendo la IP 127.0.0.1 por la del servidor de
aplicaciones en la línea:
165
bind-address = 127.0.0.1
Después se ha de reiniciar el servicio.
root@servidor_apps: /home/administrador# /etc/init.d/mysql restart
El administrador se ha de conectar a la base de datos (Cuadro 7)
root@servidor_apps: /home/administrador# mysql –u root
password:
shell> CREATE USER roberto IDENTIFIED BY ‘roberto’;
shell> \. Crearbd.sql
Cuadro 7
Con estos simples comandos quedará instalada la base de datos MySQL.
6.3.6. CONFIGURACIÓN JDBC EN JBOSS.
[BURK06] Para empezar el administrador ha de descargar el conector JDBC, de la página
http://dev.mysql.com/downloads/connector/j/. De todos los archivos que hay dentro de este
archivo comprimido, sólo se precisará mysql-connector-<XXX>-bin.jar. Habrá que copiarlo en
<JBOSS_DIR>/server/default/lib/ para que JBOSS tenga acceso a las rutinas necesarias de
acceso a MySQL.
166
Una vez hecho esto, se copiará el documento <DIR_JBOSS>/docs/examples/jca/mysql-ds.xml
en el directorio <DIR_JBOSS>/server/default/deploy/. También se ha de editar, para que
coincida con la configuración deseada (Cuadro 8):
<driver-class>com.mysql.jdbc.Driver</driver-class>
<connection-url>
jdbc:mysql://<IP_servidor_MySQL>:3306/jbossdb
</connection-url>
<user-name>roberto</user-name>
<password>roberto</user-name>
Cuadro 8
Donde <IP_servidor_MySQL> es la IP del servidor de bases de datos.
Después, sólo si la versión de JBoss escogida es igual o inferior a las versiones 4.0.X, se ha de
modificar el documento <DIR_JBOSS>/server/conf/standardjaws.xml tal como se indica en el
Cuadro 9.
<jaws>
<datasource>java:/MySqlDS</datasource>
<type-mapping>mySQL</type-mapping>
</jaws>
Cuadro 9
El siguiente paso, común a todas las versiones de JBoss, consiste en modificar
<DIR_JBOSS>/server/default/conf/standardjbosscmp-jdbc.xml igual que en el Cuadro 10.

167
<jbosscmp-jdbc>
<defaults>
<datasource>java:/MySqlDS</datasource>
<datasource-mapping>mySQL</datasource-mapping>
</defaults>
</jbosscmp-jdbc>
Cuadro 10
El paso final de configuración a nivel de servidor consiste en la edición de
<DIR_JBOSS>/server/default/conf/login-config.xml (Cuadro 11).
<application-config name=”MySqlDbRealm”>
<authentication>
<login-module code=
”org.jboss.resource.security.ConfiguredIdentityLoginModule”
flag=”required”>
<module-option name=”principal”>sa</module-option>
<module-option name=”userName”>sa</module-option>
<module-option name=”password”></module-option>
<module-option name=”managedConnectionFactoryName”>
jboss.jca:service=LocalTxCM,name=MySqlDS
</module-option>
</login-module>
</authentication>
168
</application-config>
Cuadro 11
Este driver y estos archivos de configuración permitirán al programa cliente, en nuestro caso el
sistema desarrollado, el acceso al servicio de persistencia controlado por el contenedor (CMP).
En el EJB, para hacer uso de este servicio, sólo es necesario el archivo persistence.xml y realizar
la correspondiente inyección de dependencias.
6.3.7. ESTRUCTURA DEL SERVIDOR JBOSS
La estructura de directorios de un servidor JBoss es tal como muestra la ilustración. A
continuación se detalla el contenido de los subdirectorios más importantes (Imagen 71):
• bin: scripts para arrancar y detener JBoss.
• client: JARs necesarios para que los clientes interactúen con JBoss.
• docs: ejemplos de ficheros de configuración.
• docs/dtd: Document Type Definitions (DTDs) para los diversos ficheros XML utilizados
en JBoss.
• docs/examples: ejemplos de ficheros de configuración.
• lib: JARs cargados en tiempo de arranque por JBoss y compartidos por todas las
169
configuraciones que convivan en éste.
• server: diversas configuraciones de JBoss, cada una en su respectivo subdirectorio. Se
suele usar la default.
• server/default: configuración por defecto de JBoss.
• server/default/conf: ficheros de configuración para default.
• server/default/deploy: directorio para desplegar las aplicaciones “en caliente”, es decir,
en tiempo de ejecución del servidor. Aquí se han de copiar los JAR, WAR o EAR que se
pretendan desplegar en el servidor. En el caso del sistema de gestión documental, se
copiará aquí la aplicación comprimida en un EAR.
• server/default/lib: JARs que el servidor, sólo en su configuración default, carga en
tiempo de arranque.
• server/default/log: documentos log del servidor default.
170
Imagen 71. Árbol de directorios de un servidor JBoss.
171
7. IMPLANTACIÓN
Una vez probada la integridad y robustez del software desarrollado, y especificada su instalación
y configuración, se ha de transferir el software del entorno de pruebas al de producción, para
poder explotar el sistema. Se ha de tener en cuenta también el proceso de migración de los
clientes, para poder explotar el sistema desde sus estaciones de trabajo.
En concreto, en el cada PC cliente se ha de realizar la instalación del sistema operativo. El autor
ha optado por Ubuntu Linux, cuyo proceso de instalación ya se ha detallado en el manual de
instalación y configuración. Cualquier otro sistema operativo actual tendría la misma validez.
No se ha de olvidar que el operario ha de obtener un sistema de digitalización de archivos
físicos, consistente en un scanner, software gestor de dicho dispositivo, y software de
reconocimiento de caracteres; así como el PC ya decidido previamente. El cliente ha de decidir si
se opta por designar otro empleado para realizar el volcado de información del archivo antiguo a
la base de datos; simplemente dependerá del volumen del fondo del archivo y el tiempo en el que
se pretende tener el sistema en funcionamiento.
172
Todas las tareas realizadas en esta fase habrán sido previamente planificadas en las anteriores
fases. Los equipos y servidores han sido adquiridos en etapas previas, y sólo resta realizar las
pruebas de implantación y el plan de contingencias.
7.1. PRUEBAS DE IMPLANTACIÓN
Estas pruebas tienen dos objetivos principales. Por un lado, se ha de comprobar el correcto
funcionamiento de la aplicación en el entorno de explotación, compitiendo con el resto de
sistemas por los recursos físicos.
Por otro lado, también es necesario obtener la aceptación final del usuario, que ha de realizar la
aceptación final del proyecto.
7.2. PLAN DE CONTINGENCIAS
Durante el despliegue del sistema se puede dar lugar a problemas que impidan la correcta
implantación del sistema. En tal caso, será preciso volver al antiguo sistema de documentación
consistente en un fichero al que acceden todos los usuarios de forma indirecta, a través del
operario.
El plan consiste simplemente en desconectar el servidor, y que el operario vuelva a ofrecer los
173
documentos de forma física. Como previamente el sistema no estaba informatizado, no será
necesario realizar ningún tipo de proceso.
Con los sistemas desconectados, se podrá analizar la problemática surgida, para volver a ponerlo
en funcionamiento en el plazo más breve posible.
174
ANEXO I
MODELOS DE DESARROLLO DE APLICACIONES
DISTRIBUIDAS CON J2EE
[WWW02]
1.- El modelo de desarrollo de J2EE
J2EE es una plataforma abierta que permite el desarrollo de aplicaciones distribuidas para la
empresa. El desarrollo de estos sistemas J2EE, al igual que en otras plataformas, se basa en la
división por capas (aumentar cohesión, minimizar acoplamiento). El número de capas varía
según las necesidades, pero las que se sugieren son las indicadas en la Imagen 72:
175
Imagen 72 - Estructura típica de una aplicacion J2EE
Se ha impuesto esta estructura de capas como estándar, no sólo para J2EE sino también para
.NET. Los roles de cada una de las capas, se exponen brevemente a continuación:
• Capa de cliente: diferentes aplicaciones cliente.
• Capa de presentación: lógica de interacción usuario - aplicación.
• Capa de lógica de negocio: contiene la lógica de la aplicación empresarial. Requisitos:
flexibilidad y fácil extensibilidad, reutilización, etc.
• Capa de integración: permite integrar otros sistemas como acceso a datos, sistemas
legacy, motores de reglas, etc. Es muy importante que esta capa sea fácilmente extensible.
176
2.- La capa cliente
Distintos tipos de aplicaciones cliente: aplicaciones de escritorio tradicionales, navegadores web,
aplicaciones para dispositivos móviles...
Pegas de las aplicaciones de escritorio:
• La propia aplicación la encargada de gestionar la lógica de presentación -en una
aplicación web, de ello se encarga el contenedor, ubicado en potentes servidores remotos.
• Otro punto es que la lógica de negocio es accesible únicamente mediante interfaces
remotos, lo que obliga a utilizar el patrón FACADE -si no se hiciera así, el rendimiento se
vería muy perjudicado al acceder a los EJB de modo remoto.
• La ejecución de aplicaciones en servidores remotos puede conllevar la instalación en
cliente de una serie de rutinas para acceder a éstos, lo cual puede acarrear bastantes
quebraderos de cabeza. Por ejemplo, IBM Websphere.
En dispositivos móviles, se podrá utilizar un navegador web o una aplicación propia. Ambas
opciones tienen los mismos pros y contras expuestos anteriormente. La diferencia está en el
protocolo utilizado, siempre HTTP/HTTPS. La petición es recibida por un servlet, que la
decodifica y se pone en contacto con la capa de negocio. Esa es su única función, sólo reenvía
los mensajes a la capa superior.
177
3.- La capa de presentación
Independientemente de su implementación, es la encargada de controlar la generación de
contenido a mostrar al usuario final:
1. Lógica necesaria para obtener los datos objetivo.
2. Control del flujo de pantallas, y de la interacción entre componentes.
3. Ensamblaje de vistas que componen la pantalla, y probablemente distinguir entre perfiles
para ello.
Para ello se suele utilizar el patrón MVC (modelo - datos, vista - presentación, controlador -
lógica) que conlleva múltiples ventajas.
3.1.- Aplicaciones de escritorio
Se suele utilizar Swing, o JFace. La segunda opción facilita la realización de tareas comunes, o el
uso de componentes complejos como árboles o tablas.
3.2.- Aplicaciones web
La multiplicidad de los clientes, que acceden a través del navegador al mismo servidor, hace
necesario prestar atención a factores como sincronización de usuarios, calidad de servicio,
transacciones, etc.
178
3.2.1.- Frameworks web
Conjunto de librerías que proporcionan de modo automático servicios al desarrollador. La
mayoría implementan patrones MVC, y aquellos que no lo hacen es preferible descartarlos.
Como se ha indicado, incluyen una serie de servicios, normalmente custom tags, formateo de
XML, acceso a bases de datos, control de flujo entre páginas, templates, filtros de peticiones, etc.
Todos estos servicios suponen un gran ahorro de tiempo.
Como ejemplos: Jakarta Struts, Spring, Hibernate, Tapestry, Expresso, etc. todos ellos open
source.
3.2.2.- Soluciones sin framework web
No son muy recomendables, pero a veces el desarrollador se ve obligado a su uso. En tal caso,
habrá que seguir un patrón MVC-II (sólo con JSP's).
3.2.3.- Java Server Faces
Framework de referencia cuya funcionalidad se parece mucho a Struts. Custom tags, validación
automática de formularios, etc. Independiente de JSP, puede utilizarse otro tipo de cliente, por
ejemplo tipo Swing. Se limita a la creación de interfaces de usuario, y control del flujo de la
aplicación.
179
4.- Lógica de negocio
La más importante de la aplicación: entidades, relaciones y reglas que implementan los procesos
de negocio de la empresa.
Los blueprints de Java para J2EE recomiendan la implementación de la lógica de negocio con
beans de sesión sin estado y los datos como beans de entidad. Como alternativas, se tienen las
estudiadas a continuación.
4.1.- POJOs (Imagen 73)
Simples clases java que representan un proceso de negocio de la empresa. Normalmente,
representan tanto la lógica de negocio como las entidades de la empresa (los permite convivir en
la misma capa, al contrario que con EJB).
Ventaja: muy ligeros, fáciles de implementar (no incorporan todas las capas externas de los EJB)
y de mantener. Sin embargo, no ofrecen toda las funcionalidades de los contenedores de EJB por
lo que habrá que desarrollar o recurrir a librerías externas. Si no se precisan esos servicios, se
recomienda el uso de POJOs por su sencillez y rapidez de desarrollo.
180
Imagen 73 - Estructura típica de un framework web
En el caso de la mayoría de frameworks web, se encapsula la lógica de negocio en una serie de
acciones y POJOs. La lógica de negocio puede estar en las acciones, los POJOs o ambos. Los
POJOs suelen ser JavaBeans con lógica y posiblemente también datos, accesibles fácilmente por
los otros componentes del framework, sobre todo los encargados de la vista. Tras ejecutarse las
acciones, se devuelve el control al Front Controller que generará la vista, si es necesario
utilizando los JavaBeans.
4.2.- Beans de Sesión
Tipo de EJB que representan un proceso o conjunto de tareas de nuestra aplicación; por lo que
representan una buena opción para implementar una plataforma SOA, donde cada bean de sesión
181
ofrece un servicio al exterior.
Pueden dividirse en beans con estado -que guardan el estado interno del bean- y beans sin estado
-que no lo hacen-. Como recomendación general, siempre que se encuentre una aplicación con
EJB, conviene utilizar un EJB de sesión con estado para guardar información del usuario.
Cuando se trate con una aplicación únicamente web, se guardará el estado en un objeto
HttpSession. Podemos ver una comparativa en la Tabla 4.
HttpSession Stateful EJB

Ventajas Sencilla implementación. Muchos tipos de clientes.
Optimización. Thread safe.
Delega en el servidor. Gestión automática del ciclo de
Muy escalable. vida.
Portable
Desventajas Los servlet no son thread safe. Más complejo.
Acceso a sesión menos
intuitivo.
Un bean supone menos
rendimiento que HttpSession.
Tabla 4
Este tipo de beans se utilizará para almacenar información del usuario, como por ejemplo, en un
carrito de la compra online.
El segundo tipo de beans de sesión, los que no almacenan información del estado, no se asocian
para nada con el cliente. Cada vez que se ejecuta un método, se pierde toda la información
relativa al usuario. Por ello y porque se encargan de modo automático de reutilizar instancias de
beans para servir peticiones de clientes, consumen muchos menos recursos que el resto de beans.
182
3.2.1.- Fachada de sesión (session façade)
Uno de los patrones básicos en el diseño de aplicaciones empresariales que hagan uso de EJB.
El surgimiento de la tecnología EJB hizo que los desarrolladores utilizaran estos objetos como si
de objetos locales se tratara, sin tener en cuenta que podían ubicarse en servidores remoto. Si el
número de llamadas a EJB es excesivo, el rendimiento decae de modo considerable (round trip).
Este patrón, que surgió para paliar este problema, intenta evitar llamadas "finas" a EJB,
utilizando únicamente llamadas a EJB que realicen procesos completos. Normalmente los
candidatos idóneos para utilizar este patrón son los EJB de sesión (Imagen 74).
Imagen 74 - Sin fachada de sesión / Con fachada de sesión
Los beans de sesión pueden ser utilizados tanto desde una aplicación de escritorio, caso en el que
la llamada será siempre remota, como desde una aplicación web, caso en el que podrá ser remota
o local.
183
4.3.- Beans de Mensajería (Message-driven Beans, MDB)
La solución más eficaz en J2EE para implementar un sistema de comunicación asíncrona. Están
preparados para leer mensajes a través de JMS. Tal como se observa en la siguiente ilustración,
el cliente se comunica con el servidor JMS (interno al servidor de aplicaciones o externo,
también llamado MOM - Message Oriented Middleware). Asociadas a éste, hay colas de
mensajes, a cada una de las cuales se asocia un MDB. El MDB puede contener lógica de negocio
en su interior, o, más apropiadamente, redirigir la petición al EJB correspondiente (Imagen 75).
Imagen 75 - Proceso de llamada a un MDB
Ventajas de los bean de mensajería:
• Rendimiento: obligan al cliente a quedarse bloqueado hasta que termina el procesado en
el servidor.
184
• Fiabilidad: el MOM es independiente del contenedor de EJB.
• Interoperabilidad: con sistemas de distintas plataformas.
• Soporte para múltiples clientes y receptores, complicado de implementar mediante el
protocolo tradicional, RMI-IIOP.
• Máxima cohesión, mínimo acoplamiento.
4.3.1.- Fachada de mensajería (messaging façade)
Patrón común con los MDB. El funcionamiento es igual al anteriormente descrito, pero la lógica
de negocio se implementa en los propios MDB. Como alternativa, está la posiblidad de que los
MDB se comuniquen directamente con la fachada de sesión en vez de hacerlo los EJB de sesión.
Utilizando la fachada de mensajería se evita, además de tener que realizar varias llamadas
remotas, la realización de múltiples peticiones JMS para un único proceso de negocio. (Múltiples
peticiones remotas pueden suponer que éstas se realicen en un orden no deseado.)
4.4.- Beans de Entidad
Representan datos, por lo que no encajan en la lógica de negocio -aunque a veces se utilizan en
ella- sino en la de integración (apartado 5.1.2).
185
5.- Capa de integración
Encargada de acceder a los datos procedentes de diversas fuentes, como bases de datos o
servidores LDAP. Arquitecturas orientadas a dominio: las entidades tienen plena conciencia de
sus responsabilidades, por lo que la lógica de acceso a datos se encuentra en el interior del
objeto, junto a la lógica de negocio. Arquitectura orientada a servicios: la lógica de acceso a
datos está aislada de la de negocio, fuera del objeto.
5.1.- Los datos
Núcleo de la arquitectura empresarial. Las entidades han de representar abstracciones del mundo
real, y a poder ser reutilizables en distintos escenarios. Opciones: POJOs y EJBs.
5.1.1.- POJOs
Clases java planas, normalmente en forma de JavaBeans. Flexibilidad: muy portable, no precisan
ni servidor de aplicaciones. Rendimiento alto, debido a la falta de capas externas de seguridad.
El principal vacío en el desarrollo con POJOs está en la persistencia. Como alternativa, se puede
recurrir a motores de persistencia o herramientas de generación de código.
5.1.2.- EJBs de entidad
Representan entidades de nuestra base de datos relacionales, y conocen cómo realizar la
persistencia (lo ideal es que lo hagan de forma autónoma). Los beans son reutilizados para
186
diversos clientes mediante un pool, lo que supone un importante ahorro de recursos. Entre los
servicios extras que ofrecen, se encuentran la seguridad y la gestión automática del ciclo de vida.
5.1.2.1.- Problemas de rendimiento
Se trata de uno de los componentes más pesados de Java, pero se han ido superando las causas
más importantes.
• Uso de interfaces remotas: hasta EJB 2.0 la única vía de acceder a estos beans era
mediante RMI-IIOP a través del interfaz remoto. El tema es que si se realizan múltiples
llamadas a beans de entidad, el rendimiento se reduce de modo considerable. Desde EJB 2.0
se ha superado el problema.
• Abuso de los EJB: al sobrecargar tanto el sistema, no se ha de encapsular toda entidad
con EJB. Sólo se utilizarán para encapsular las entidades sobre las que se vaya a escribir, y
en los casos de entidades de sólo lectura utilizar otro tipo de patrón.
También hay que tener en cuenta si realmente se precisan todos esos servicios extra que
prestan los EJBs, como seguridad o control del ciclo de vida. Probablemente un POJO
podría ofrecer las funcionalidades deseadas, en la mayoría de los casos.
5.1.2.2.- Lógica de negocio en EJBs de entidad
Esta alternativa se dirige principalmente a arquitecturas orientadas a servicio (local).
Factores negativos que podrían influir negativamente en el rendimiento:
• Introducción de relaciones entre entidades.
187
• Introducción de gestión del flujo de trabajo dentro del bean de entidad.
• Adquisición dentro del bean de entidad, de responsabilidades reclamables por otro
componente de negocio.
La práctica recomendable es sólo incluir lógica de negocio propia, es decir, que un bean de
entidad sólo contenga lógica que no afecte a terceras entidades.
5.2.- Acceso a datos
5.2.1.- JDBC
La opción más sencilla. Usado cuando hay una estructura de POJOs o EJBs de entidad manejada
por el propio bean (BMP).
Ventajas: ligereza, muy extendido. Desventajas: necesidad de conocimiento profundo de SQL, el
acceso a jerarquías complejas de objetos puede resultar en sentencias muy complicadas y
dependientes del SGBD.
5.2.1.2.- Data Access Objects (DAO)
Este patrón propone crear una serie de interfaces para abstraer el acceso a datos. Tras ser creadas
estas interfaces que permitirán la creación, lectura, actualización y eliminación de entidades, se
han de crear distintas implementaciones, una por cada base de datos a acceder. Si cambia la base
de datos, sólo habrá que cambiar a la implementación adecuada de DAO.
188
Casos en los que implementar DAO de forma manual:
• Uso de JDBC sin ningún entorno especial de persistencia.
• EJBs de entidad con BMP.
Los motores de mapeo objeto-relacional, CMP y JDO implementan de foma automática DAO.
5.2.2.- Motores de mapeo objetos-relacional (frameworks de persistencia)
Una de las herramientas más útiles y utilizadas dentro de las aplicaciones empresariales,
automatizan el proceso de creación, lectura, actualización y eliminación de entidades de bases de
datos relacionales. Permiten la definición de entidades a través de XML, a partir del cual extrae
la información para modelar los objetos. Realizan el modelado a objetos, para más tarde
convertirlos a clases Java. También permiten el proceso opuesto: de objetos a base de datos.
Desventaja: no son estándar, se corre el peligro de quedarse ligado al motor y que se cese el
desarrollo de éste. BMP, CMP Y JDO no acarrean este riesgo.
Suele utilizarse en cualquier sistema que no implemente EJBs, especialmente con POJOs ya que
son una buena combinación (Imagen 76). Sin embargo, en la implementación 3.0 de EJB, se
utiliza Hibernate de forma interna.
189
Imagen 76 - Arquitectura web con sistema de mapeo objeto - relacional.
5.2.3.- BMP / Persistencia Manejada por el Bean
El código de persistencia es implementado por el desarrollador, con códigos de carga,
actualización, creación y borrado llamados desde el contenedor para realizar estas tareas de
persistencia. Normalmente utilizará JDBC básico, ya que el resto de alternativas no tienen
mucho sentido en esta opción.
5.2.4.- CMP / Persistencia Manejada por el Contenedor
El contenedor implementa y ejecuta el código necesario para las operaciones CRUD de acceso a
la base de datos. Este código además es compatible para todas las bases de datos soportadas por
el servidor de aplicaciones. Tras EJB 3.0 el rendimiento de CMP es bastante bueno.
Para la ejecución de SQL, CMP utiliza el lenguaje EJB-QL, que permite manejar el esquema
abstracto de datos definido previamente.
190
5.2.4.1.- CMP vs. BMP (Tabla 5)
BMP CMP
• Mejor rendimiento, el
servidor puede aplicar
optimizaciones.
• Menor esfuerzo de
desarrollo.
• SQL: mayor control. • Más mantenible.
• Permite acceso a múltiples Soporta mejor los

Ventajas
fuentes de datos. cambios de estructura y
• Más sencillo de depurar. base de datos.
• Jerarquías de objetos:
persistencia más fácil.
• Mejor integración con
herramientas RAD.
• Portabilidad.
191
• Poco control sobre las
• Desarrollo complicado. sentencias SQL.
• Sin DAO o motor de • Sólo se puede asociar
persistencia, poco mantenible. un bean a una base de

Inconvenientes
• Peor rendimiento que CMP, a datos.
no ser que use un motor de • Sólo bases de datos
persistencia. relacionales.
• Difícil depuración.
Tabla 5
5.2.5.- JDO
Modelo de persistencia estándar de persistencia de objetos, con diversas implementaciones
comerciales y libres. Principalmente para bases de datos orientadas a objetos, aunque también
permite las relacionales así como sistemas de ficheros o cualquier otro mecanismo de
persistencia. Sus detractores, alegan que otros motores de persistencia -como Hibernate- dan
mejores resultados con bases de datos relacionales, pero se está trabajando en ello. No supone
ninguna ligazón con ningún proveedor concreto.
5.3.- JCA
Arquitectura estándar para conectar J2EE con diferentes sistemas de información, ya sean
aplicaciones web, de escritorio, EJBs, POJOs, etc. Conecta sistemas de información empresarial
192
tradicionalmente bastante cerrados, como SAP, Tuxedo, Navision, etc.
Funcionalidades: gestión de conexiones e hilos de JCA, de seguridad y transacciones, envío y
recepción de mensajes asíncronos a sistemas heredados, portabilidad entre servidores de
aplicaciones.
193
6.- Capa de recursos.

Todos los sistemas d einformación a los que se accede desde la capa de integración. Muy
diversos: SGBD relacionales / orientados a objetos, sistemas de ficheros, ERPs, etc.
194
7.- Servicios web.
Se tratan de aplicaciones software accesibles desde una url. La comunicación se realiza mediante
protocolos basados en XML como SOAP, a través de protocolos de internet como HTTP. Los
clientes utilizan los servicios directamente a través de su interfaz, definida mediante WSDL, o
buscando en un catálogo de servicios web. Objetivo final: promover la interoperabilidad entre
diversos sistemas empresariales y de negocio, con garantía de seguridad y transaccionalidad.
Su principal utilidad consiste en promover la interoperabilidad entre distintas plataformas,
sistemas y lenguajes. El mayor problema radica en su inmadurez, se basa en tecnologías y
estándares recientes, muchos todavía no definidos en su totalidad.
7.1.- Servicios web en J2EE. (1.3)
Hay dos sistemas de acceso a los servicios web en java: JAXM Y JAX-RPC. La primera es más
compleja y ofrece más funcionalidades, como mensajería asíncrona y multicast. JAX-RPC, por
contra, es mucho más simple -hace más sencillas las tareas comunes- y por ello se recomienda.
Su especificación se basa en la ejecución de procesos RPC punto a punto mediante SOAP
(Imagen 77).
195
Imagen 77 - Funcionamiento típico de JAX-RPC
El desarrollador sólo crea una interfaz para el servicio web y una implementación de la interfaz.
JAX-RPC crea de forma automática el fichero WSDL, las clases proxy y publica el servicio web
en un registro UDDI.
7.2.- Servicios web en J2EE. (1.4)
Aparece el concepto de web service endpoint. Sus funciones:
Recibir la petición de ejecución por parte del cliente.
196
Extraer el método a ejecutar y parámetros correspondientes.
Realizar el mapeo XML-Java.
También realiza un proceso similar para enviar la respuesta al cliente.
Tipos de web service endpoints (Imagen 78):
JAX-RPC service endpoint: como un servlet.
EJB service endpoint: como un EJB de sesión sin estado.
Imagen 78 - Tipos de web service endpoints en J2EE 1.4
La elección entre un tipo u otro se realizará en función de cómo se haya implementado la lógica
197
de negocio.
XML es un formato de texto que ocupa bastante más tamaño que una llamada a RMI-IIOP. Al
coste en ancho de banda, se ha de añadir el coste de mapear entre XML y Java. Por ello conviene
crear servicios con una granularidad bastante gruesa, al igual que con los beans de entidad.
7.3.- Mapeo entre clases y XML.
Se trata de transformar XML a objetos Java y viceversa (Imagen 79).
Para ello, estas herramientas utilizan el concepto del binding compiler. De este modo, se
compilan los archivos Java en .class, y éstos a su vez se transforman en XML conformes al
esquema de jerarquías dado. Estos .class son manejados de un modo mucho más sencillo que el
XML.
JAXB se utiliza en JAX-RPC para transformar los mensajes SOAP en .class y los parámetros
requeridos por los servicios web para su ejecución. No es la única herramienta de mapeo, pero sí
la más extendida.
198
Imagen 79 – Proceso de mapeo de un objeto java a XML y XSL
7.4.- Servicios web vs. JCA y JMS (Tabla 6)
Cliente – Entre Sistemas de Distintos Sistemas

Mensajería
servidor aplicaciones partners lenguajes delegados
Conveniente
JCA Fuerte Sencilla Asíncrona
(con driver)
Síncrona –
JMS Floja Sencilla Conveniente
asíncrona
Servicios Síncrona – Sin control

Floja Conveniente
web asíncrona (conveniente)
Tabla 6
199
8.- Generación de código.

La tendencia actual en cuanto a las herramientas va hacia el desarrollo orientado a atributos.
Los IDEs modernos automatizan en gran parte la generación de código, ahorrando gran trabajo al
desarrollador. Pero no se contemplan todas las posibilidades. Ahí es donde entran en juego
herramientas como XDoclet.
XDoclet es un motor de generación de código, que permite un modelo de programación
orientado a atributos dentro de Java. El desarrollador puede centrarse en la lógica de la
aplicación: mediante metadatos insertados en los archivos Java que en tiempo de compilación
son leídos por XDoclet, para generar todo el código auxiliar a las clases que contienen la
funcionalidad en sí. Contiene multitud de etiquetas que simplifican la creación de aplicaciones
empresariales: Struts, motores de persistencia como Hibernate, servicios web con Axis, EJBs,
JSPs, etc. Así como para multitud de servidores de aplicaciones, permitiendo exprimir al
máximo las características de cada uno de ellos.
200
9.- Conclusiones.
Han ido apareciendo una serie de patrones de desarrollo adicionales a los expuestos oficialmente
por SUN Microsystems. Asimismo, existen una serie de herramientas no incluidas dentro de los
blueprints de la misma, pero que se han ido convirtiendo en fundamentales en el desarrollo de
aplicaciones.
La plataforma J2EE es muy compleja como se ha visto, y repleta de alternativas y posibilidades
para implementar todas las capas típicas de una aplicación distribuida. Se debe encontrar la
arquitectura más simple que permita satisfacer los requerimientos no funcionales de nuestras
aplicaciones.
Debido a ello, los blueprints oficiales han evolucionado para adaptarse a los nuevos frameworks
de desarrollo ligeros, impuestos por las limitaciones de implementaciones ya contenidas dentro
de los blueprints.
Esta anexo pretende aclarar todas las elecciones que J2EE ofrece.
201
ANEXO II
EJB 3.0
Este texto pretende actuar como introducción al uso de la nueva API 3.0 de la tecnología EJB y
al API de Persistencia Java. Han sido desarrolladas con el objetivo de simplificar las anteriores
versiones, cuya complicación llevó a muchos desarrolladores por escoger otros frameworks de
persistencia como Hibernate o Spring.
CARACTERÍSTICAS GENERALES DE EJB 3.0.
La gran novedad en la tecnología EJB 3.0 es el mayor control que el contenedor realiza sobre los
EJB. Sin embargo, se trata de una tecnología flexible que permite al programador, si así lo desea,
todo el control que las anteriores versiones obligaban a realizar.
202
EJB 2.1 vs. EJB 3.0 (Tabla 7)
EJB 2.1 EJB 3.0
Componentes: El objetivo es que el contenedor EJB realice
más trabajo.
• Clase del bean.
Aparecen las anotaciones: ya no será necesario

• Interfaz local.
escribir interfaces obvios o descriptores de
• Interfaz remoto. despliegue.
• Descriptor de despliegue del bean: ejb- El contenedor dota de los servicios requeridos
jar.xml al bean.
• Más descriptores. Los EJB previos continuan siendo soportados.
Tabla 7
Clases bean más simples.
Los EJB se convierten en POJOs (clases simples). El tipo de bean se especifica mediante
anotaciones o XML: @Stateless, @Stateful, @MessageDriven. Por lo tanto, ya no es necesario
implementar interfaces como javax.ejb.Entity, javax.ejb.SessionBean, etc. Y la programación se
hace más sencilla.
203
Inyección de dependencias.
El acceso al entorno se ha de realizar mediante inyección de dependencias (o simplemente
JNDI). La instancia del bean incluye referencias a recursos del entorno, a los cuales se puede
acceder mediante este método, en tiempo de instanciación.
Servicios del contenedor.
Persistencia y transacciones, bien gestionadas por el bean o por el contenedor.
Seguridad.
Control del ciclo de vida.
Excepciones.
Introducción al API de Persistencia Java.
Está integrada en la especificación EJB 3.0.
Características principales:
• Basada en POJOs: clases simples de java, con soporte de herencia, polimorfismo,
encapsulamiento, etc.
• SQL: utiliza un lenguaje de consulta basado en SQL, pero con mayor profundidad
204
(permite utilizar objetos).
• Usable en J2SE y J2EE.
• Las entidades se convierten en POJOs serializables.
• Realiza el control del ciclo de vida de las entidades.
El contexto de Persistencia.
Conjunto de instancias de entidades, gestionadas en tiempo de ejecución. Todas ellas pertenecen
a la misma unidad de persistencia (empaquetado y despliegue).
Resumen.
EJB 3.0 se convierte en una nueva versión que simplifica en gran manera la tecnología EJB al
desarrollador. Permiten interoperar con componentes y aplicaciones ya existentes, ya que se
mantiene la compatibilidad con EJB 2.1 y anteriores. Del mismo modo, EJB consiste una
estandarización importante gracias a características importantes para el desarrollador:
• Los beans se convierten en POJOs.
• Los APIs se simplifican.
• Acceso sencillo a servicios del entorno y del contenedor.
205
• Se puede seguir utilizando descriptores de despliegue, aunque no es obligatorio.
• El mapeo objeto – relacional puede realizarse mediante anotaciones o XML.
• Definición de consultas dinámicas o estáticas.
• SPI (Service Provider Interface): para integrar proveedores de persistencia. Por defecto,
EJB 3.0 utiliza Hibernate, pero puede escogerse cualquier otro, como por ejemplo
Spring.
206
ANEXO III
EVALUACIÓN ECONÓMICA DEL NUEVO SISTEMA.
CONCEPTO PRECIO EN €
Gasto de desarrollo: salario de 5 meses de un analista-programador. 5.000
Coste de los servidores. 1.198
Coste de los terminales de usuario (5) y operario. 4.332
Infraestructura de comunicaciones. 1.000
Licencias de software adicionales. 0
Mantenimiento anual. 3.000
TOTAL 14.530
Tabla 8
207
ANEXO IV
PLANIFICACIÓN FINAL DEL PROYECTO
Imagen 80. Planificación final del proyecto.
208
ANEXO V
MANTENIMIENTO
Tras las fases ya pasadas de desarrollo del sistema e implantación, han de tenerse en cuenta las
tareas, no menos importantes, de mantenimiento. Este mantenimiento no sólo se ha de limitar a
la corrección de errores –correctivo– sino también han de adaptar, en la medida de lo posible, las
nuevas funcionalidades que el cliente pueda precisar –adaptativo.
El equipo de mantenimiento formará parte del equipo de desarrollo original del proyecto, por
ello se pagarán ciertas tasas que se ven reflejadas en el presupuesto del proyecto.
MANTENIMIENTO CORRECTIVO.
Han de remitirse al equipo de desarrollo, de forma constante, los informes de los errores que
puedan ir apareciendo. Estos informes han de ser lo más detallados posible, incluyendo datos
como:
209
• Sucesión de acciones para obtener el error dado.
• Condiciones del entorno en el cual se ha obtenido: datos del equipo, fecha y hora,
circunstancias en las que se produjo...
• Archivos LOG generados por el programa.
• Cualquier otro dato que se considere relevante.
MANTENIMIENTO ADAPTATIVO.
El equipo de desarrollo concertará reuniones periódicas con el cliente para tratar, aparte de los
errores ya comentados, las necesidades que puedan surgir en la plataforma. Todas ellas han de
ser presupuestadas aparte de las tasas de mantenimiento anual.
MANTENIMIENTO DE LA BASE DE DATOS.
El equipo de desarrollo ha de realizar, cada cierto tiempo, tareas de defragmentación de la base
de datos MySQL. Esta necesidad surge del almacenamiento de datos binarios, concretamente los
documentos. Estas tareas se han de realizar a nivel de línea de comandos, aunque más adelante
se podrá estudiar integrar esta funcionalidad en la plataforma para automatizar la tarea, por
210
ejemplo mediante el uso de demonios estilo CRON.
El comando en concreto para realizar esta tarea es el siguiente:
ALTER TABLE Versiones ENGINE=INNODB;
Dicho comando ha de realizarse por el usuario root en MySQL.
211
ANEXO VI
CONCLUSIONES
A nivel personal, el haber tenido la oportunidad de llevar a cabo este proyecto ha sido una
experiencia enriquecedora para el autor. Ha tenido la oportunidad de conocer en profundidad
tecnologías muy demandadas en el mercado laboral hoy en día, como son EJB y Struts, lo cual a
bien seguro marcará un antes y un después en su desarrollo profesional. Por brindarle esta
oportunidad, no puede hacer otra cosa que dar las gracias al Instituto Católico de Artes e
Industrias –ICAI– y su profesorado.
A nivel de resultados, la organización del archivo preexistente en la empresa cliente, suponía un
coste administrativo considerable. Estos gastos no sólo se manifestaban en almacenamiento
físico de los documentos, sino la administración y accesibilidad de los mismos.
El sistema de Gestión documental desarrollado contribuirá a una mejor organización y control de
documentación técnica y administrativa. La información suministrada por el cliente ha sido clave
para ello.
Una arquitectura como la escogida, basada en estándares J2EE, supone un salto adelante en
materia de estandarización, modularización y escalabilidad. Como bien se ha señalado en
212
apartados anteriores, todas las capas de la aplicación son fácilmente escalables, pudiendo llegar
incluso a la realización de clústeres fácilmente para un mejor rendimiento.
• Capa de presentación: el framework Struts supone una ayuda para implementar un patrón
Modelo - Vista - Controlador sencillo y sobradamente testado.
• Capas de negocio y persistencia: se ha escogido la versión 3.0 de EJB, que se caracteriza
por su ligereza y sencillez para definir clústeres. La facilidad para el desarrollo ha sido
otro aspecto que ha decantado al analista por esta tecnología frente a otras que en los
Últimos tiempos están bastante en boga (Spring, Hibernate).
• Sistema Gestor de Base de datos: se ha optado por el sistema MySQL frente a otras
opciones comerciales ya existentes debido tanto al coste como a la posibilidad de
migración en un futuro al motor de persistencia "MySQL Cluster" que permite la
escalabilidad buscada.
Otro punto que se tuvo en cuenta al desarrollar este proyecto fue la utilización de tecnologías
libres. Su uso asegura en un futuro la independencia de desarrollador. Al estar el código fuente
disponible, el usuario podría optar por solicitar a cualquier analista con los conocimientos
necesarios la modificación del mismo en un futuro. Ello asegura al cliente el soporte futuro de la
aplicación adquirida, siendo un modelo de desarrollo que poco a poco se está imponiendo en
todo el mundo.
En definitiva, el sistema desarrollado va a ayudar a la empresa en tareas administrativas y
técnicas, suponiendo un ahorro ingente de dinero.
213
ANEXO VII
MANUAL DE USUARIO
Imagen 81. Entrada al sistema
214
Imagen 82. Página principal del administrador.
Imagen 83. Módulo de búsqueda de documentos
215
Imagen 84. Resultados obtenidos de la búsqueda
216
Imagen 85. Módulo de acceso a documentos.
217
Imagen 86. Módulo de acceso a versiones específicas.
Imagen 87. Primera pantalla del módulo de subida de nuevos documentos.
218
Imagen 88. Segunda pantalla del módulo de subida de documentos.
219
Imagen 89. Módulo de navegación por las diversas áreas temáticas.
220
Imagen 90. Módulo de navegación por las diversas áreas temáticas.
221
Imagen 91. Módulo de gestión de usuarios.
Imagen 92. Módulo de gestión de grupos.
222
Imagen 93. Informe de actividad reciente.
Imagen 94. Informe de los últimos accesos y salidas del sistema.
223
Imagen 95. Informe de los nuevos documentos subidos al sistema.
Salida del sistema.
224
ANEXO VIII
BIBLIOGRAFÍA
[BURK06] Burke B., Monson-Haefel R. “Enterprise JavaBeans 3.0” O’Reilly, 5ª edición,
Santa Clara, 2006.
[BARR01] Barranco de Areba J. “Metodología del análisis estructurado de sistemas”
Universidad Pontificia Comillas, Madrid, 2001.
[SRIK04] Srikanth Shenoy, Nithin Mallya “Struts Survival Guide: Basics to Best Practices”
ObjectSource Publications, Austin, 2004.
[KEOG03] Keogh J.,”Manual de referencia J2EE”, Mc Graw Hill, Madrid, 2003.
[RIVE92] Rivero Cornelio, E., “Bases de datos Relacionales”, Universidad Pontificia
Comillas, Madrid, 2005
Otras fuentes.
[WWW01] Srikanth Ramakrishna, “EJB 3.0”, Sun Microsystems Inc., 2006
http://sg.sun.com/sunnews/events/presentation/files/20060906_id_developer/EJ
225
B3.0_Srikanth_jakarta.pdf
[WWW02] Pérez Mariñán, M. “Modelos de desarrollo de aplicaciones distribuidas con
J2EE” 2003.
http://sicas.dyndns.org/biblio/Java-J2ee/ModeloAplicacionesJ2EE.pdf
[WWW03] JBoss – Guía Ubuntu
http://www.guia-ubuntu.org/index.php?title=JBoss
226

46ea52ba2ad25 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

46ea52ba2ad25 PDF

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD PONTIFICIA COMILLAS

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

PROYECTO FIN DE CARRERA

AUTOR: ROBERTO LÓPEZ LÓPEZ

MADRID, SEPTIEMBRE DE 2007

de gastos en almacenamiento, infraestructuras, sistemas digitalizadores o fotocopiadoras, etc.

como seguridad y flexibilidad.

administrativo y el documental. El primero de ellos, encargado de la gestión diaria de cualquier

empresa, utiliza documentos administrativos. El entorno documental hace uso de documentación

• Infraestructura: hardware y software básico, red de interconexión y sistemas operativos.

• Servicios de autor: se ofrece acceso a herramientas de autor, para facilitar la creación y

• Servicios de almacenamiento: usualmente el núcleo de un sistema de gestión documental

es un sistema gestor de bases de datos, normalmente relacional (actualmente se tiende a

los orientados a objetos, que ofrecen información para el reensamblaje).

• Servicios de búsqueda: las búsquedas se realizan sobre la base de datos, normamente

mediante índices en campos determinados. De esta manera se consigue una mayor

velocidad y calidad en los resultados obtenidos.

• Servicios de biblioteca: diversos servicios que incluyen retención de documentos, control

de versiones de documentos, seguimiento de uso de documentos, control de acceso y

• Servicios de presentación y distribución.

del grupo de trabajo.

Se ha intentado, mediante la realización de este proyecto fin de carrera, la consecución de un

storage expenses, infrastructures, digitizer systems, photocopiers, etc.

-Storage services: the core of a documentary management system is usually a relational

ones. They offer information on reassembly).

documents follow-up, access control and safety copies.

- Presentation and distribution services.

members of a given group work.

1.1. DOCUMENTO DE CONCEPTOS DEL SISTEMA...............................................................3

2.1. MODELO FÍSICO DEL SISTEMA ACTUAL......................................................................10

2.2. MODELO LÓGICO DEL SISTEMA ACTUAL...................................................................25

2.3. LISTA DE REQUISITOS......................................................................................................36

2.4. MODELO LÓGICO DEL NUEVO SISTEMA.....................................................................48

2.5. MODELO CONCEPTUAL DE DATOS...............................................................................64

3.1. ESPECIFICACIÓN DE LAS ALTERNATIVAS..................................................................67

3.2. EVALUACIÓN DE ALTERNATIVAS................................................................................78

4.1. REQUISITOS FÍSICOS DEL NUEVO SISTEMA...............................................................84

4.2. DESARROLLO DEL MODELO FÍSICO DEL NUEVO SISTEMA....................................93

5.1. PRUEBAS UNITARIAS......................................................................................................150

6.1. ENTORNO DE PRUEBAS..................................................................................................151

6.2. TIPOS DE PRUEBAS REALIZADAS................................................................................152

6.3. MANUAL DE INSTALACIÓN Y CONFIGURACIÓN.....................................................154

6.3.1. INSTALACIÓN DE UBUNTU LINUX...........................................................................155

6.3.2. INSTALACIÓN DEL SDK 5.0 DE SUN MICROSYSTEMS.........................................162

6.3.3. INSTALACIÓN DEL SERVIDOR DE APLICACIONES JBOSS..................................163

6.3.4. INSTALACIÓN DEL FRAMEWORK STRUTS.............................................................165

6.3.5. INSTALACIÓN DE MySQL............................................................................................165

6.3.6. CONFIGURACIÓN JDBC EN JBOSS.............................................................................166

6.3.7. ESTRUCTURA DEL SERVIDOR JBOSS.......................................................................169

7.1. PRUEBAS DE IMPLANTACIÓN.......................................................................................173

7.2. PLAN DE CONTINGENCIAS............................................................................................173

ANEXO I: MODELOS DE DESARROLLO DE APLICACIONES

DISTRIBUIDAS CON J2EE…………….…………….…………….…………….…………...175

ANEXO II: EJB 3.0…………….…………….…………….…………………………….…….202

ANEXO III: EVALUACIÓN ECONÓMICA DEL NUEVO SISTEMA……………………...207

ANEXO IV: PLANIFICACIÓN FINAL DEL PROYECTO…………….…………………….208

ANEXO VI: CONCLUSIONES………….…………….…………….…………….….……….212

ANEXO VII: MANUAL DE USUARIO…………….………...….…………….……………..214

ANEXO VIII: BIBLIOGRAFÍA…………………………………………………………….....225

sentimientos que lo han envuelto durante su desarrollo.

estudios superiores, a los cuales desea la mejor suerte posible.

• Llevar a cabo un sistema de gestión documental mediante tecnologías JEE.

• Presentación del proyecto en septiembre.