Main

Sistema Gestor de Bibliotecas
Daniel Nieto
Diego Sánchez
Catalina Cano
Victor Villamil
Universidad Distrital
Copyright
c 2016 Daniel Nieto, Diego Sánchez, Catalina Cano, Victor Villamil
P UBLICADO POR U NIVERISDAD D ISTRITAL
HTTPS :// WWW. UDISTRITAL . EDU . CO
Primera edición, Abril 2016

Tabla de contenido
I Contextualización
1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Marco conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1 Descripción del problema 13
2.2 Justificación 13
2.3 Alcances 13
2.4 Limites 14
3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Objetivo general: 15
3.2 Objetivos específicos: 15
4 Lineamientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Stakeholders 17
4.1.1 Stakeholders Primarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.2 Stakeholders Secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2 Requerimientos 22
4.2.1 Requerimientos Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2 Requerimientos no funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5 Estilo arquitectural . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1 SOA 35
5.1.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.1.2 Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.1.3 Observaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2 Centrada en Datos (Pizzarra) 36
5.2.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.2 Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.3 Observaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Basada en componentes 37
5.3.1 Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3.2 Beneficios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
II Modelado Arquitectural
6 Puntos de Vista en ArchiMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.1 Clasificación de los Puntos de Vista 41
7 Punto de Vista Introductorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.1 Punto de Vista Introductorio y su funcionalidad a los Stakeholders 43
7.1.1 Gerente – Capa del Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.2 Administrador- Capa de Aplicación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.1.3 Desarrollador- Capa Tecnología . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
7.2 Consideraciones Generales 45
7.2.1 Modelo del Punto de Vista Introductorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7.3 ESPACIO PARA DANI (PROCESO DEL NEGOCIO) 47
7.4 Punto de Vista de Estructura de la Aplicación 48
7.4.1 Descripción de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
7.5 Punto de Vista de Infraestructura 50
7.5.1 Descripción de los Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
7.5.2 Modelo Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.5.3 ANEXOS: 1. Modelo Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . . 53
7.5.4 ANEXOS: 2. Modelo Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . . 54
7.6 Punto de Vista de Estructura de la Información 55
7.6.1 Descripción de los Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
7.6.2 Modelo Punto de Vista de Estructura de la Información . . . . . . . . . . . . . . . . . 56
Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Lista de figuras
6.1 Puntos de Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7.1 Punto de Vista Introductorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2 Punto de Vista de Estructura del Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
7.3 Modelo Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7.4 Anexo 1 Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . 53
7.5 Anexo 2 Punto de Vista de Infraestructura . . . . . . . . . . . . . . . . . . . . . . . . . . 54
7.6 Modelo Punto de Vista de Estructura de la Información . . . . . . . . . . . . . . . 56
Lista de Tablas
4.1 Stakeholder: Administrador del sistema de la biblioteca . . . . . . . . . . . . . . 17

4.2 Stakeholder: Equipo desarrollador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Stakeholder: Administrador de la biblioteca virtual . . . . . . . . . . . . . . . . . . . 18
4.4 Stakeholder: Administrador de la biblioteca . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.5 Stakeholder: Estudiante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.6 Stakeholder: Invitado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7 Stakeholder: Profesor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.8 Stakeholder: Funcionario de recepción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.9 Stakeholder: Bibliotecarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.10 Stakeholder: Capital de Bibliotecas (BiblioRed) . . . . . . . . . . . . . . . . . . . . . 19
4.11 Stakeholder: Red de datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.12 Stakeholder: Administrador de la red de bibliotecas (BibloRed) . . . . . . . 20
4.13 Stakeholder: Gerente de recursos físicos (Universidad Distrital) . . . . . . . . 20
4.14 Stakeholder: Consejo académico (Universidad Distrital) . . . . . . . . . . . . . 20
4.15 Stakeholder: Gerente de recursos financieros (Universidad Distrital) . . . . 21
4.16 Lista de Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.17 Lista de Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.18 Requerimiento 1.1: Registrar elementos bibliográficos . . . . . . . . . . . . . . . 23
4.19 Requerimiento 1.2: Buscar elemento Bibliográfico . . . . . . . . . . . . . . . . . . . 23
4.20 Requerimiento 1.3: Modificar Elemento Bibliográfico . . . . . . . . . . . . . . . . 24
4.21 Requerimiento 1.4: Eliminar Elemento Bibliográfico . . . . . . . . . . . . . . . . . . 24
4.22 Requerimiento 2.1 : Registrar Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.23 Requerimiento 2.2: Consultar Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.24 Requerimiento 2.3: Modificar Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.25 Requerimiento 2.4: Eliminar Usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.26 Requerimiento 3.1: Generar Reportes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.27 Requerimiento 4.1: Generar sanciones a usuarios . . . . . . . . . . . . . . . . . . . 27
4.28 Requerimiento 5.1: Alquilar elemento de la biblioteca . . . . . . . . . . . . . . . 28
4.29 Requerimiento 6.1: Registrar reserva de elemento . . . . . . . . . . . . . . . . . . 28
4.30 Requerimiento 6.2: Buscar reserva de elemento . . . . . . . . . . . . . . . . . . . . 29
4.31 Requerimiento 6.3: Modificar reserva de elemento . . . . . . . . . . . . . . . . . . 29
4.32 Requerimiento 6.4: Eliminar reserva de elemento . . . . . . . . . . . . . . . . . . . 29
4.33 Requerimiento 7.1: Permitir la interconectividad . . . . . . . . . . . . . . . . . . . . 30
4.34 Rol: Analista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.35 Rol: Administrador de Base de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.36 Rol: Líder Técnico (Arquitecto) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.37 Rol: Diseñador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.38 Rol: Desarrollador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
I
Contextualización
1 Introducción . . . . . . . . . . . . . . . . . . . . . . . . 11
2 Marco conceptual . . . . . . . . . . . . . . . . . . 13
2.1 Descripción del problema
2.2 Justificación
2.3 Alcances
2.4 Limites
3 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.1 Objetivo general:
3.2 Objetivos específicos:
4 Lineamientos . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Stakeholders
4.2 Requerimientos
5 Estilo arquitectural . . . . . . . . . . . . . . . . . . . 35
5.1 SOA
5.2 Centrada en Datos (Pizzarra)
5.3 Basada en componentes
1. Introducción
La sistematización de los datos es un elemento esencial que se ha implementado de forma necesaria

en una gran cantidad de sistemas que requieren mantener la información segura y controlada dentro
de un ámbito estable y garantizado, por tal motivo resulta prácticamente obligatorio el salto hacia
esta técnica en todos los sistemas que soliciten un manejo de datos eficaz y eficiente.
El control de inventario permite un manejo controlado de la circulación de implementos bib-

liográficos, por este motivo tiene una gran importancia mantener la información requerida de cada
movimiento de forma segura y ordenada con una correcta administración, estos objetivos corren
un gran riesgo cuando no son sistematizados. Esta sistematización es seguida por un proceso de
escalabilidad en el cual se implementa la interconectividad con otras instituciones.
El acceso a los implementos bibliográficos influyen notoriamente en el proceso de aprendizaje de

los estudiantes en todas las áreas del conocimiento, por este motivo asegurar el correcto manejo y la
disponibilidad de estos se puede entender como un componente de gran importancia tanto para los
estudiantes como para los administrativos de una universidad que desea ofrecer los mejores recursos
a sus alumnos, por tal motivo, una aplicación que permita asegurar el acceso a la información
rápida y eficazmente, resultaría de gran utilidad en el ámbito educativo.
2. Marco conceptual
2.1 Descripción del problema

La Universidad Distrital es una gran institución de educación universitaria que en el año 2015
manejo 24.310 estudiantes y que se espera maneje más para el año 2016. Actualmente, la Univer-
sidad Distrital posee un sistema de información encargado de gestionar las diferentes bibliotecas
vinculadas a la Universidad, que se encuentran ubicadas en las diferentes sedes (actualmente son 8
bibliotecas).
Actualmente presenta varias falencias en cuanto a interoperabilidad (No presta servicios de

consulta para ser implementados por otras universidades) y mantenimiento (Dificultad para actu-
alizar las interfaces y agregar nuevas funcionalidades); Por lo que con el paso del tiempo los costos
para realizar cambios sobre el sistema ha ido creciendo, entonces se ha optado por abandonar este
proyecto y desarrollar una nueva plataforma capaz de desempeñar las mismas funciones pero de
forma efectiva permitiendo agregar nuevas necesidades al sistema.
2.2 Justificación
La administración de elementos bibliográficos es un problema recurrente en las universidades
ya que en muchos casos no es óptimo e impide al estudiantado acceder a los prestamos debido
al manejo de una información inadecuada para los recursos con los que se puede contar en la
actualidad, lo que puede desembocar en un bajo aprovechamiento de los recursos del plantel.
Con la automatización y optimización de este sistema es posible llevar un control completo

de los implementos prestados con lo cual se posibilita el préstamo de forma coordinada y adecuada.
2.3 Alcances
Este aplicativo tiene como objetivo apoyar las actividades de administración de implementos en
el distrito capital de Bogotá, especialmente dirigido a la Universidad Distrital Francisco José de
Caldas, con el objetivo de que permita ser usado sin restricción alguna a cualquier entidad que la
14 Capítulo 2. Marco conceptual
desee implementar, de tal forma que este proceso facilite un acceso eficiente a los recursos por
parte de los interesados.
2.4 Limites
El proyecto se encuentra limitado por la capacidad de adaptación tanto como por datos incompletos
y no actualizados a través de las diferentes entidades en la ciudad.
3. Objetivos
3.1 Objetivo general:

Gestionar las diferentes bibliotecas que hacen parte de la red de la Universidad Distrital permitiendo
el acceso e indexación de los materiales literarios, bibliográficos de los que dispone la universidad
mediante las bases de datos disponibles y la interconectividad con otras universidades.
3.2 Objetivos específicos:

• Desarrollar una aplicación que permita controlar los préstamos de implementos de la bib-
lioteca.
• Implementar funciones que permitan acceder a la información de forma sencilla en menos de
10 segundos por operación.
• Realizar un método que permita crear multas por defecto, a causa de entregas en tiempos
vencidos.
• Efectuar una interfaz y un método de acceso a los estudiantes que les permita reservar
un implemento bibliográfico para un día y fecha determinados, logrando así asegurar la
disponibilidad de los elementos en el momento que los necesite.
• Permitir la interconectividad con las Bases de Datos a las cuales tiene acceso la universidad
4. Lineamientos
4.1 Stakeholders
Dentro de los análisis necesario para iniciar el proyecto se debe tener en cuenta a los diferentes
trabajadores, accionistas, organizaciones y hasta clientes que están interesados en que el desarrollo
de este proyecto se lleve a cabo a plenitud, cumpliendo plazos y condiciones establecidas. Todos
estos interesados se mencionan a continuación mostrando sus intereses y el papel de cada uno
de ellos, estos son los stakeholders que para las necesidades fundamentales de la biblioteca de
la Universidad Distrital Francisco José de Caldas se fundamentan en la comunidad académica y
entidades públicas por el carácter de la universidad.
4.1.1 Stakeholders Primarios
Los stakeholders primarios son fundamentales para el operar de una organización. Este grupo
incluye a quienes tienen alguna relación económica con el negocio.
Administrador del sistema de la biblioteca

Descripción:
Se encarga de administrar los usuarios, elementos, materiales y demás de
la biblioteca; además de ser el intermedio entre el equipo de desarrollo
y el administrador de la biblioteca.
Intereses:
Administración óptima de los recursos bibliográficos disponibles en cuanto a:
• Búsqueda
• Registros
• Préstamos
• Reservas
• Multas
18 Capítulo 4. Lineamientos
Equipo desarrollador
Descripción:
Son el grupo encargado de realizar mantenimiento al software y de agregar
nuevas funcionalidades requeridas al sistema.
Intereses:
Desarrollo y construcción del sistema minimizando costos en términos
de tiempo y dinero.
Administrador de la biblioteca virtual

Descripción:
Es la persona elegida para gestionar la ubicación de los elementos de la
biblioteca, entre otras funciones.
Intereses:
Obtener un sistema que sea compatible, interoperable y extensible con los
sistemas afines.
Administrador de la biblioteca
Descripción:
Es el encargado de administrar todos los aspectos referentes a la biblioteca
virtual y a la física.
Intereses:
Está interesado en la construcción del sistema para el análisis de los datos
generados por el uso progresivo del mismo. (identificación de Tendencias)
Estudiante
Descripción:
Son los alumnos de la universidad, que realizan peticiones a la biblioteca de
forma variada; pero entre las cuales se encuentran consultar el catálogo,
solicitar un préstamo y demás.
Intereses:
Acceso eficiente y dinámico a los recursos bibliográficos disponibles,
verificando disponibilidad y condiciones para su uso.
Invitado
Descripción:
Son aquellos que no hacen parte de la universidad directamente pero hacen
parte del convenio de préstamo y puede realizar solicitudes básicas y
especiales a la biblioteca.
Intereses:
Ver y acceder a los recursos bibliográficos de la universidad disponibles para
él.
4.1 Stakeholders 19
Profesor
Descripción:
Son docentes relacionados con la universidad que disponen de privilegios
especiales para la solicitud de materiales (Como tiempos de préstamo más
largo) o acceso a material exclusivo para docentes.
Intereses:
Gestionar los recursos bibliográficos de la Universidad Distrital, observando
su disponibilidad, Evaluar los recursos disponibles por la biblioteca y sugerir
reestructuraciones.
Funcionario de recepción
Descripción:
Es el encargado de realizar los trámites desde los usuarios (Estudiante, invitado
o profesor) hacia la biblioteca y viceversa.
Intereses:
Fluidez, sencillez y simplicidad en sus labores al momento prestar un mejor
servicio.
Bibliotecarios
Descripción:
Son funcionarios que se encargan de devolver el material prestado a su ubicación
correcta en la biblioteca y utilizan el catálogo para conocer su ubicación exacta.
Intereses:
Disponer de manera eficiente de los recursos bibliográficos.
4.1.2 Stakeholders Secundarios
Los stakeholders secundarios son aquellos que no participan directamente en el intercambio con
una empresa, pero que sí pueden afectar o verse afectados por las acciones de ésta.
Capital de Bibliotecas (BiblioRed)

Descripción:
La red de gestión de información y conocimiento de la Alcaldía Mayor de
Bogotá, la cual solicita información del sistema para proporcionar
préstamos a usuarios de la red y obtener información para nuevas
adquisiciones.
Intereses:
El sistema desarrollado sea interoperable y funcione de manera sinérgica
con la red.
Red de datos
Descripción:
Provee el acceso a las diferentes bases de datos interconectadas con la
universidad, adicionalmente brinda respaldo y acceso con respecto al
hosting, dominio y conexiones de red que se requieran durante el
desarrollo e implementación final del proyecto.
Intereses:
Vinculación del sistema de la universidad a las diferentes bases de datos
vinculadas a la red.
Administrador de la red de bibliotecas (BibloRed)

Descripción:
Es el encargado de llevar la información de los usuarios entre las diferentes
bibliotecas asociadas a la red para ofrecer opciones de préstamos
interbibliotecarios.
Intereses:
Llevar un control del tipo de material disponible en las diferentes bibliotecas
para que cada una este actualizada con el material correcto.
Gerente de recursos físicos (Universidad Distrital)

Descripción:
Es el encargado de ordenar las reposiciones y adiciones de libros físicos,
así como sus registros al sistema.
Intereses:
Debe estar atento a las necesidades físicas y de su optimización por
medio del sistema.
Consejo académico (Universidad Distrital)

Descripción:
Influyen indirectamente en el funcionamiento de la biblioteca al momento
de la toma de decisiones y por tanto, al sistema.
Intereses:
Ofrecer la cantidad optima de recursos a la biblioteca para que esta cumpla
con normas de calidad para los estudiantes asociados a la universidad.
4.1 Stakeholders 21
Gerente de recursos financieros (Universidad Distrital)

Descripción:
Destina los recursos de la biblioteca y por tanto la capacidad física de
adquisición y almacenamiento del sistema.
Intereses:
Asegurarse que la biblioteca gaste los recursos necesarios para funcionar
a un nivel de calidad.
4.2 Requerimientos
4.2.1 Requerimientos Funcionales
Los requerimientos funcionales son las características del sistema con las cuales se busca cubrir las
necesidades de automatización, colaboración, integración y mejoramiento en la ejecución de los
procesos del sistema. Las características aquí indicadas son las que se considerarán como línea base
inicial del proyecto; de conformidad con el funcionamiento actual de la biblioteca. Sin embargo,
son susceptibles de verificación y complementación en la fase de análisis detallado.
No REQUERIMIENTO DESCRIPCIÓN
El sistema permite ingresar elementos
Registrar elementos
1.1 bibliográficos para ser utilizados más
bibliográficos
adelante
Buscar un elemento El sistema permite buscar en sus registros
1.2
bibliográfico un elemento previamente registrado.
Modificar elemento El sistema permite modificar un elemento
1.3
bibliográfico registrado anteriormente.
Eliminar elemento El sistema permite dar de baja un elemento
1.4
bibliográfico registrado anteriormente.
El sistema permite registrar un nuevo
2.1 Registrar Usuario
usuario
El sistema permite buscar en sus registros
2.2 Buscar Usuario
a un usuario anteriormente registrado
El sistema permite realizar modificaciones
2.3 Modificar Usuario
sobre un usuario registrado anteriormente.
El sistema da de baja a un usuario
2.4 Eliminar Usuario
anteriormente registrado
Permitir la generación de El sistema genera automáticamente reportes
3.1
reportes sobre el
El sistema impone sanciones automáticamente
Generar sanciones a
4.1 a los usuarios que no devuelvan un elemento
usuarios
de la biblioteca a tiempo
El sistema permite que un usuario alquile
Alquiler de elementos
5.1 elementos de la biblioteca durante cierto
en la biblioteca
periodo de tiempo
Registrar reserva de El sistema almacena una reserva sobre un
6.1
elemento elemento de la biblioteca
El sistema busca entre sus registros alguna
Buscar reserva de
6.2 reserva realizada sobre un elemento de la
elemento
biblioteca
No REQUERIMIENTO DESCRIPCIÓN
El sistema busca entre las reservas alguna
Modificar reserva de
6.3 que tenga un ID parecido al de la solicitud
elemento
y procede a modificarlo
Eliminar reserva de
6.4 El sistema da de baja una reserva
elemento
El sistema ofrece servicios que pueden ser
Permitir la interconectividad consumidos por otras bibliotecas para realizar
7.1
con las bases de datos externas diferentes servicios como por ejemplo, buscar
elemento bibliográfico.
Requerimiento 1.1: Registrar elementos bibliográficos

Utensilios: Escenario 1:
El sistema despliega un formulario, que le permite
Computador, Servidor BD,
al usuario seleccionar el tipo de elemento que desea
Servidor de Aplicaciones
registrar.
Roles: Escenario 2:
Se despliegan cada uno de los campos
Administrador
correspondientes al tipo de elemento seleccionado.
Condiciones de entrada: Escenario 3:
Autenticarse como administrador del sistema. Guardar los datos del registro en la persistencia
Condiciones de salida: Escenario 4:
Registro Almacenado con Éxito Se notifica el resultado de la operación al usuario
Requerimiento 1.2: Buscar elemento Bibliográfico

Computador, Servidor BD, El sistema despliega un formulario, que le permite
Servidor de Aplicaciones al usuario especificar el elemento que desea buscar.
Roles: Escenario 2:
Administrador, Usuario o Invitado. El sistema valida la información del formulario
Acceder a la sección de consulta
Se realiza la búsqueda del elemento en el sistema
de la biblioteca
Permite visualizar la información
Se notifica el resultado de la operación al usuario
del elemento.
Requerimiento 1.3: Modificar Elemento Bibliográfico

al administrador especificar el elemento que desea
modificar.
Roles: Escenario 2:
Administrador El sistema valida la información del formulario.
Autenticarse como administrador El sistema busca el elemento y permite visualizar
del sistema. los datos en el formulario.
Se realizan los cambios al elemento.
Registra la nueva información
Escenario 5:
del elemento.
Se notifica al administrador del resultado de la
operación.
Requerimiento 1.4: Eliminar Elemento Bibliográfico

al administrador especificar el elemento que desea
eliminar.
Roles: Escenario 2:
Autenticarse como administrador El sistema busca el elemento y permite visualizar
del sistema. los datos en el formulario
El sistema solicita confirmación para ejecutar
la operación.
Se da de baja al elemento.
Escenario 5:
operación.
Requerimiento 2.1 : Registrar Usuario

al usuario seleccionar el tipo de usuario que desea
registrar.
Roles: Escenario 2:
Administrador
correspondientes al tipo de usuario seleccionado.
Autenticarse como administrador
El sistema valida la información del formulario.
del sistema.
Guardar los datos del registro en la persistencia
Registro Almacenado con Éxito Escenario 5:
Requerimiento 2.2: Consultar Usuario

Computador, Servidor BD, El sistema despliega un formulario, que le permite
Servidor de Aplicaciones al usuario especificar de usuario desea buscar.
Roles: Escenario 2:
Administrador, Usuario o Invitado. El sistema valida la información del formulario
Acceder a la sección de consulta
Se realiza la búsqueda del usuario en el sistema
de usuarios de la biblioteca
Permite visualizar la información
del elemento
Requerimiento 2.3: Modificar Usuario

al administrador especificar el tipo de usuario que
desea modificar.
Roles: Escenario 2:
Autenticarse como administrador El sistema busca el usuario y permite visualizar
del sistema. los datos en el formulario
Se realizan los cambios en el elemento
Escenario 5:
del elemento.
operación.
Requerimiento 2.4: Eliminar Usuario

al administrador especificar el tipo de usuario que
desea eliminar.
Roles: Escenario 2:
Autenticarse como administrador El sistema busca el usuario seleccionado y permite
del sistema. visualizar los datos en el formulario
El sistema solicita confirmación para ejecutar la
operación.
Se da de baja al usuario
Escenario 5:
operación.
Requerimiento 3.1: Generar Reportes

El sistema toma la hora y fecha del sistema.
Roles: Escenario 2:
Se toman todas las transacciones realizadas
Modulo Automatizado
en esta fecha y se imprimen a un historial.
Hora y fecha del sistema Se guarda el historial generado en persistencia.
Condiciones de salida:
Historial con las acciones de esa fecha
Requerimiento 4.1: Generar sanciones a usuarios

El sistema toma la hora y fecha del sistema.
Roles: Escenario 2:
Se obtiene la lista de elementos alquilados
Modulo Automatizado y de ella se obtiene los que coincidan o sean
mayores de la fecha asociada.
Se verifica que la hora actual del sistema sea
Hora y fecha del sistema
superior a las 8:00PM
Se genera un registro en la persistencia con el
id del usuario y el del material prestado con
Historial con las acciones de esa fecha.
un cobro por la multa que incrementa cada
día pasado desde la fecha.
Requerimiento 5.1: Alquilar elemento de la biblioteca

Computador, Servidor BD, El usuario presenta una ficha con los
Servidor de Aplicaciones datos del elemento a pedir prestado.
Roles: Escenario 2:
El bibliotecario valida la información
Usuario, Bibliotecario
de la ficha.
Ficha técnica con la información El bibliotecario valida que el usuario
del elemento no tenga multas.
Si la información fue validada
correctamente y el usuario no tiene
multas entonces registra el préstamo
Alquiler de un elemento de la biblioteca
en el sistema.
Escenario 5:
El bibliotecario notifica al usuario.
Requerimiento 6.1: Registrar reserva de elemento

El sistema despliega un formulario, que le
permite al administrador seleccionar el tipo
de elemento que desea registrar.
Roles: Escenario 2:
Administrador correspondientes al tipo de elemento
seleccionado.
Guardar los datos del registro en la persistencia
del sistema.
Registro de reserva almacenada Se notifica el resultado de la operación al
con éxito administrador
Requerimiento 6.2: Buscar reserva de elemento

El sistema despliega una ventana de
consulta que le solicita un ID de la reserva
para consultar.
Roles: Escenario 2:
El sistema valida la información del
Administrador, Usuario o Invitado
formulario
Se realiza la búsqueda de la reserva en el
Autenticarse en el sistema.
sistema
Permitir visualizar la información referente Se despliega la información de la consulta
a una consulta en pantalla
Requerimiento 6.3: Modificar reserva de elemento

Computador, Servidor BD, El sistema despliega una ventana de consulta que le
Servidor de Aplicaciones solicita un ID de la reserva para consultar.
Roles: Escenario 2:
El sistema despliega un formulario para modificar la
Administrador
información de la reserva
El administrador llena la información del formulario.
del sistema
Se valida la información del formulario
Escenario 5:
del elemento.
Se notifica al administrador sobre el estado de la
petición.
Requerimiento 6.4: Eliminar reserva de elemento

Computador, Servidor BD, El sistema despliega una ventana de consulta que le
Servidor de Aplicaciones solicita un ID de la reserva para consultar.
Roles: Escenario 2:
Administrador El sistema confirma si se desea dar de baja a la reserva
Autenticarse como administrador Se busca la reserva en el sistema y se cambia su estado
del sistema. a inactivo.
Se notifica al administrador del estado de la operación.
Se da de baja a la reserva Escenario 5:
El sistema confirma si se desea dar de baja la reserva
Requerimiento 7.1: Permitir la interconectividad

Computador, Servidor BD, El sistema habilita un módulo para la conexión
Servidor de Aplicaciones por parte de otros aplicativos.
Roles: Escenario 2:
El usuario se conecta a esos módulos y realizar
Usuario extranjero, Modulo Automatizado peticiones de consulta sobre los elementos
bibliográficos locales
Hora y fecha del sistema El usuario llena el formulario de consulta
El sistema valida la información del
formulario.
Respuesta a la petición externa.
Escenario 5:
El sistema responde la petición.
Roles
Analista
Descripción:
Su misión consiste en elaborar el análisis funcional de la aplicación, debe
controlar, analizar y supervisar el desarrollo funcional de las aplicaciones
informáticas, asegurando su correcta explotación y su óptimo rendimiento.
Administrador de base de datos

Descripción:
Su misión consiste en elaborar el análisis funcional de la aplicación, debe
controlar, analizar y supervisar el desarrollo funcional de las aplicaciones
informáticas, asegurando su correcta explotación y su óptimo rendimiento.
Líder técnico (Arquitecto)

Descripción:
Es la persona capaz de crear un entorno el que la gente se siente capaz de
tomar sus propias decisiones, siente que tiene responsabilidad
Diseñador
Descripción:
Recibe el análisis y transforma la lista de requisitos del usuario (exenta de tecnología)
en un diseño arquitectónico de alto nivel que proveerá las especificaciones a los
programadores.
Desarrollador
Descripción:
Es un programador que se dedica a una o más facetas del proceso de desarrollo
de software, un ámbito algo más amplio de la programación. Esta persona puede
contribuir a la visión general del proyecto más a nivel de aplicación que a nivel
de componentes o en las tareas de programación individuales.
4.2.2 Requerimientos no funcionales

Debido a que el Sistema de información debe disponer de las opciones para realizar registro, control
y seguimiento de la información y actividades involucradas con usuarios y servicios ofrecidos por la
biblioteca, existen ciertos requerimientos No funcionales que deben ser analizados cuidadosamente,
ya estos influyen directamente en la calidad del producto de software.
Los requerimientos no funcionales hacen relación a las características del sistema que aplican
de manera general como un todo, más que a rasgos particulares del mismo. Estos requerimientos
son adicionales a los requerimientos funcionales que debe cumplir el sistema, y corresponden a
aspectos tales como la disponibilidad, mantenibilidad, flexibilidad, seguridad, facilidad de uso, etc.
En esta sección se describen los requerimientos no funcionales del sistema, con el objetivo
de definir una arquitectura/ Estilo Arquitectural que esté enfocada en brindar soporte tanto a los
requerimientos funcionales como a los no funcionales para lograr una óptima satisfacción de todos
ellos.
Desempeño
• Garantizar la confiabilidad, la seguridad y el desempeño del sistema a los diferentes usuarios.
En este sentido la información almacenada podrá ser consultada y actualizada permanente y
simultáneamente, sin que se afecte el tiempo de respuesta.
• El sistema debe ser lo suficientemente ágil para garantizar que el despliegue entre pantallas
sea corto, de tal forma que los usuarios no tengan que incurrir en tiempos muertos
• El sistema debe estar en capacidad de dar respuesta al acceso de todos los usuarios y a los
procesos ejecutados con un tiempo de respuesta aceptable, en la medida de las posibilidades
tecnológicas de la biblioteca.
Disponibilidad
• Garantizar la confiabilidad, la seguridad y el desempeño del sistema a los diferentes usuarios.
En este sentido la información almacenada podrá ser consultada y actualizada permanente y
simultáneamente, sin que se afecte el tiempo de respuesta.
• El sistema debe estar en capacidad de dar respuesta al acceso de todos los usuarios y a los
procesos ejecutados con un tiempo de respuesta aceptable, en la medida de las posibilidades
tecnológicas de la biblioteca.
• El sistema deberá estar disponible los 6 días de uso hábil a la semana en los horarios
estipulados pero siempre debería proveer el servicio de consulta a los usuarios.
• El sistema deberá estar en la capacidad de soportar al menos 2431 peticiones de forma
concurrente.
Escalabilidad
• El sistema debe ser construido sobre la base de un desarrollo evolutivo e incremental, de
manera tal que nuevas funcionalidades y requerimientos relacionados puedan ser incorporados
afectando el código existente de la menor manera posible; para ello deben incorporarse
aspectos de reutilización de componentes.
• El sistema debe estar en capacidad de permitir en el futuro el desarrollo de nuevas funcionali-
dades, modificar o eliminar funcionalidades después de su construcción y puesta en marcha
inicial.
Facilidad de Uso / Accesibilidad

• El sistema debe ser de fácil uso y entrenamiento por parte de los usuarios de la biblioteca.
• El sistema no debe permitir el cierre de una operación hasta que todos sus procesos, subpro-
cesos y tareas relacionados, hayan sido terminados y cerrados satisfactoriamente.
• El sistema debe presentar mensajes de error que permitan facilitar la identificación del error
y comunicarse con el administrador del sistema.
• El sistema debe ser estéticamente amigable y legible (Según las politicas establecidas por el
Distrito [1]).
• Todas las pantallas del sistema deberán ser diseñadas y desarrolladas para que el usuario
comprenda el funcionamiento. Además, tanto la interfaz gráfica como los mensajes de éxito,
errores, alertas, entre otros, tener una apariencia estándar, siguiendo los lineamientos gráficos
entregados por la biblioteca
• Se deben proveer mecanismos para facilitar la obtención de información mediante criterios
de búsqueda.
• El sistema deberá contar con un Mapa del sitio que permita navegar fácilmente por el mismo
(Ver [1]).
Facilidad para las Pruebas

• El sistema debe contar con facilidades para la identificación de la localización de los errores
durante la etapa de pruebas y de operación posterior.
• Para comprobar el correcto funcionamiento de sistema deberá ser sometido a pruebas de
stress, usuario y pruebas unitarias.
Flexibilidad
• El sistema debe ser diseñado y construido de manera flexible en cuanto a la parametrización
de los tipos de datos, de tal manera que la administración del sistema sea realizada por un
administrador funcional del sistema.
Mantenibilidad
• Todo el sistema deberá estar completamente documentado, cada uno de los componentes de
software que forman parte de la solución propuesta deberán estar debidamente documentados
tanto en el código fuente como en los manuales de administración y de usuario.
• La estructura del sistema deberá dar soporte a nuevas funcionalidades, todo esto se debe
garantizar a partir de la metodología y la arquitectura seleccionada para el desarrollo del
proyecto, ofreciendo eficacia en términos de tiempo de implementación y de ejecución.
• Asegurar que los tiempos de mantenimiento para la plataforma no sobrepasen las 12 horas
mensuales.
Seguridad
• Aplicar defensa en seguridad: Para esto se puede utilizar un algoritmo de encriptamiento
punto a punto (Entre la persistencia y el aplicativo).
• Usar un modelo de seguridad positivo: Uso de contraseñas seguras y posiblemente un
captcha.
• Fallas esperadas: Programar el aplicativo para responder en caso de no poderse conectar a
la persistencia y no dejarlo a la deriva de posibles atacantes.
• Ejecutar con pocos privilegios: Exigir que cada usuario (Administrador o estudiantes)
puedan ejecutar sus acciones pero no entrometerse en el sistema.
• Evitar la seguridad mediante el oscurecimiento: Evitar que el código sea enredado con
motivo de enredar al atacante y utilizar un sistema de seguridad apropiado.
• Mantener la seguridad simple: Implementar un sistema de seguridad que sea sencillo, que
podría ser la criptografía.
• Detectar intrusos: Llevar un registro de todos los usuarios que se conecten al sistema y su
rol en el.
• No confiar en la infraestructura: Evitar la sensación de seguridad que ofrece un elemento
físico de seguridad (Candado de la puerta o modulo de seguridad)
• No confiar en los servicios: Evitar ser poco precavido con las personas con las cuales
puede interactuar el modulo de consulta del sistema.
• Establecer seguridad por defecto: El uso de contraseñas y captcha.
• La seguridad del sistema debe estar regida por las Políticas de Seguridad Informática de
la Comisión Intersectorial de Políticas y Gestión de la Información para la Administración
Pública.
• El acceso al Sistema debe estar restringido por el uso de claves asignadas a cada uno de los
usuarios. Sólo podrán ingresar al Sistema las personas que estén registradas, estos usuarios
serán clasificados en varios tipos de usuarios (o roles) con acceso a las opciones de trabajo
definidas para cada rol.
• Respecto a la confidencialidad, el sistema debe estar en capacidad de rechazar accesos o
modificaciones indebidos (no autorizados) a la información y proveer los servicios requeridos
por los usuarios legítimos del sistema.
• El sistema debe validar automáticamente la información contenida en los formularios de
ingreso. En el proceso de validación de la información, se deben tener en cuenta aspectos
tales como obligatoriedad de campos, longitud de caracteres permitidos por campo, manejo
de tipos de datos, etc.
• El sistema debe validar automáticamente la información contenida en los formularios de
ingreso. En el proceso de validación de la información, se deben tener en cuenta aspectos
tales como obligatoriedad de campos, longitud de caracteres permitidos por campo, manejo
de tipos de datos, etc.
• Facilidades y controles para permitir el acceso a la información al personal autorizado de
otras entidades a través de Internet, con el propósito de consultar la información pertinente
para cada una de ellas.
5. Estilo arquitectural
La elección del estilo arquitectural con el cual se construirá el software es una de las decisiones
más importantes y por tanto criticas en un proyecto, a pesar de que existen múltiples estilos arqui-
tecturales genéricos es muy probable que al definir la arquitectura se hagan presentes uno o varios
estilos arquitecturales que darán solución a diferentes requerimientos tanto funcionales como no
funcionales.
A continuación se evidencia el análisis realizado de acuerdo a los requerimientos establecidos,

los cuales conducen a establecer bajo que estilos arquitecturales se desarrollara el presente proyecto.
5.1 SOA
5.1.1 Descripción
“SOA es una arquitectura de software que propone la construcción de aplicaciones
mediante el ensamblaje de bloques reusables, débilmente acoplados y altamente in-
teroperables, cada uno de los cuales es representado como un servicio. Los mismos
pueden encontrarse distribuidos y pertenecer potencialmente a diferentes propietarios”
[Canto 2006].
Debido a que el enfoque del sistema propuesto se basa en la interoperabilidad de servicios web
,para cumplir con estas exigencias se optó por utilizar la denominada Arquitectura Orientada a
Servicios ya que SOA Como enfoque arquitectónico facilita la creación de servicios de negocio
interoperables y estrechamente relacionados que pueden fácilmente compartirse y consumirse.
Una Arquitectura Orientada a Servicios permite el diseño aplicaciones de software preparadas

para el cambio, se trata de aplicaciones ágiles y adaptables, por su bajo acoplamiento, es decir, sin
importar las tecnologías con que estas fueron creadas o la plataforma donde vayan a ejecutar.
36 Capítulo 5. Estilo arquitectural
5.1.2 Beneficios
• Publicación de los servicios existentes: esto se refiere a un repositorio que contenga infor-
mación relacionada a las características de los servicios, cuál es la interfaz para consumirlo
etc
• Composición de servicios: esto se enfoca en los mecanismos o estándares con los que debe
contar la organización para lograr que dos servicios con responsabilidades diferentes logren
comunicarse.
• Servicios reutilizables: los servicios deben ser diseñados pensando en que varias aplica-
ciones pueden requerir su utilización.
• Servicios autónomos: Todo servicio debe tener su propio entorno de ejecución. De esta
manera el servicio es totalmente independiente y se asegura que así podrá ser reutilizable
desde la perspectiva de la plataforma de ejecución.
• Eliminar el desorden de conexiones entre aplicaciones, hace el desarrollo de estas más rápido
y económico
5.1.3 Observaciones
Para la implementación de SOA es importante aplicar estándares de comunicación que ayuden con
la publicación y descubrimiento de los servicios; un posible inicio es basarse en:
• XML
• SOAP
• WSDL
5.2 Centrada en Datos (Pizzarra)

5.2.1 Descripción
"En esta arquitectura hay dos componentes principales: una estructura de datos que
representa el estado actual y una colección de componentes independientes que operan
sobre él." [Shaw & Garlan 2006].
.
Según los requerimientos y necesidades establecidos para el proyecto se hace pertinente contemplar
una arquitectura centrada en datos como un estilo arquitectural a utilizar en este proyecto, ya
que esta facilitara el control y gestión de la información con la cual el software trabajara en cada
momento y será uno de los pilares para su funcionamiento.
Teniendo en cuenta que una arquitectura centrada en datos se basa en tener un almacén
central donde se concentra toda la información, que en este caso serán todos los registros de
elementos bibliográficos con sus características, estados, ubicaciones y sedes entre otros. Los
cuales serán de consulta permanente en la mayoría de las operaciones del software mediate
diferentes componentes del software, los cuales podrán interactuar de forma pasiva o activa según
sus necesidades dependiendo de sus funciones.
5.2.2 Beneficios
• Promueve la capacidad de integración. Esto permitirá de ser necesario modificar componentes
existentes que interactúan con el almacén de datos o la creación componentes nuevos a la
arquitectura sin preocuparse por los demás componentes facilitando también la comunicación
entre componentes. De esta forma el sistema para la administración de la biblioteca podrá
trabajar de forma eficiente entre sus diferentes componentes permitiendo la escalabilidad de
este.
5.3 Basada en componentes 37
• Los componentes ejecutan procesos de forma independiente. Los diferentes componentes

del sistema de la biblioteca accederán a la información del almacén de datos y luego de ello
los diferentes procesos que necesiten realizar lo podrán hacer de forma independiente sin
que dependa del almacén de datos solo hasta el momento de realizar alguna modificación de
información.
5.2.3 Observaciones
Para trabajar adecuadamente con esta arquitectura es pertinente trabajar de la mano con una
arquitectura centrada en componentes. Y de la misma forma con herramientas óptimas para
gestionar información como son las bases de datos y entornos SQL.
5.3 Basada en componentes

5.3.1 Descripción
“Un componente de software, dice, es una unidad de composición con interfaces
especificadas contractualmente y dependencias del contexto explícitas”
[Szyperski 2002].
.
Al examinar la forma de interacción entre los diferentes actores del sistema hacia la biblioteca, se
puede observar una serie de patrones de comportamiento entre los cuales resalta el tipo de “Ingresar
a ventana de...”; lo que permite establecer una clara separación entre interfaz y control del sistema.
Esta separación permite establecer que vamos a tener módulos que van a interactuar entre si, por lo
que es importante que se siga a cabalidad un estilo que permita esta labor, como por ejemplo el
RM-ODP(Reference Model of Open Distributed Processing):
Este RM-ODP plantea 5 puntos importantes a tener en consideración si se desea utilizar una
arquitectura basada en componentes:
• Empresa: ¿Si se implementa este sistema sera util para la biblioteca? Por supuesto, se busca
que la implementación de un sistema gestor de biblioteca permita tomar mejores decisiones
gerenciales sobre la biblioteca.
• Información: ¿El uso de esta arquitectura dificulta el uso de la información actual? No, de
hecho se busca que la información sea más accesible y se puedan realizar más acciones con
ella que las acciones que se podrían realizar en motores básicos como Excel y demás.
• Computación: ¿Tendré que gastar más recursos mejorando los equipos que actualmente
poseo? La idea del sistema es optimizar las ganancias y minimizar los costos, por lo que se
pretende que el sistema use los recursos disponibles, no más pero con un poco de ingeniería
si un poco menos.
• Ingeniería: ¿Se utilizan demasiados elementos complejos para el diseño? En realidad, no.
De hecho este estilo se enfoca en elementos que sean fáciles de comprender desde cada
uno de estos 5 puntos de vista. Estos puntos se ponen de acuerdo en los aspectos que les
interesen del sistema y se esfuerzan en que estos se mantengan claros. Tampoco es que estos
se vuelvan muy difusos con la evolución de la arquitectura, pues como se mencionó antes, se
utilizan elementos claros de la ingeniería para representar sus intereses, como por ejemplo,
bases de datos y diagramas de clases.
• Tecnologia: ¿Que tan moderna es la tecnologia usada en el sistema? La ventaja de este estilo
es que podemos gestionarlo todo como componentes que pueden ser cambiados/actualizados
siempre y cuando esta nueva versión cumpla con la funcionalidad anterior. Para esta parte lo
38 Capítulo 5. Estilo arquitectural
único que se debería actualizar serían las versiones del JDK y del motor para la BD; que para
la fortuna de los desarrolladores, se encargan de conservar su trabajo con cada actualización
para que ese trabajo ya realizado no se pierda.
5.3.2 Beneficios
• Claridad en las interfaces: Se conoce perfectamente que hace cada componente y cómo se
comporta ante determinadas situaciones.
• Completitud: Los componentes están completos en sus 3 aspectos (Modelado, diseño e
implementación)
• Restricciones: Cada módulo tiene definido a que se pueden enfrentar en sus entradas y
también sus salidas están bien definidas.
• Ocultamiento: Sus estados no son visibles a los demás componentes, lo que nos asegura la
protección de la información por parte de instancias no autorizadas.
II
Modelado Arquitectural
6 Puntos de Vista en ArchiMate . . . . . . . . 41

6.1 Clasificación de los Puntos de Vista
7 Punto de Vista Introductorio . . . . . . . . . . 43

7.1 Punto de Vista Introductorio y su funcionalidad a
los Stakeholders
7.2 Consideraciones Generales
7.3 ESPACIO PARA DANI (PROCESO DEL NEGOCIO)
7.4 Punto de Vista de Estructura de la Aplicación
7.5 Punto de Vista de Infraestructura
7.6 Punto de Vista de Estructura de la Información
Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6. Puntos de Vista en ArchiMate
A lo largo de este capítulo, encontrará los conceptos más importantes asociados a cada uno de los
puntos de vista seleccionados para este proyecto.
6.1 Clasificación de los Puntos de Vista

Para ayudar a los arquitectos en la selección de los puntos de
vista adecuados, ArchiMate incluye un marco para la definición
y clasificación de los diferentes puntos de vista. El marco se basa
en dos dimensiones Propósito y Contenido. Para caracterizar
la dimensión del Propósito, ArchiMate define las siguientes
clasificaciones:
• Diseño: El punto de vista del diseño apoya a los arquitec-

tos y diseñadores a lo largo de todo el proceso de diseño
desde el boceto inicial hasta el diseño detallado, por lo
general consiste en diagramas de diseño utilizando por
ejemplo UML.
• Decisión: Los puntos de vista de decisión ayudan a los
gerentes en el proceso de la toma de decisiones, ofrece
proyecciones e intercepciones entre modelos subyacentes
por ejemplo tablas de referencia, listas, reportes.
• Información: Los puntos de vista de información ayu-
dan a informar a cualquier stakeholder a cerca de la arqui-
tectura de la empresa, con el fin de lograr comprensión, obtener compromiso y convencer a
los adversarios. Los ejemplos típicos son ilustraciones animaciones, historietas, volantes etc.
42 Capítulo 6. Puntos de Vista en ArchiMate
Para caracterizar el Contenido ArchiMate define los siguientes niveles de abstracción:
• Detalle: Los puntos de vista sobre el nivel del detalle son considerados una capa y un aspecto
del framework de ArchiMate. Los stakeholders típicamente interesados son un ingeniero
responsable del diseño e implementación de un componente de software o un responsable de
un proceso eficaz y eficiente. Ejemplos de estos puntos de vista a nivel del detalle son los
diagramas de clase de UML.
• Coherencia: En el nivel de abstracción de coherencia, múltiples capas o múltiples aspec-

tos son abarcados extendiendo la vista a más de una capa o aspecto permitiéndole a los
interesados concentrarse en las relaciones como procesos- usos- sistema (Múltiples capas) o
aplicación – usos – objeto (Múltiples aspectos). Los stakeholders típicos son los gerentes
responsables de una colección de servicios IT o procesos de negocio.
• Visión General:El nivel de abstracción de visión general o de resumen aborda múltiples

aspectos y múltiples capas. Tales descripciones están dirigidas a las personas que toman
decisiones o arquitectos de la empresa
Figure 6.1: Puntos de Vista
Típicos
Propósito Ejemplos
Interesados
Arquitecto,
Navegar, Diagramas de
Diseño Desarrollador de software
Diseñar, soporte al proceso de toma decisiones de diseño, comparar alternativas UML, Diagrama BPMN, Diagrama de Flujo
Diseñador de procesos de negocio
Gerente, Toma de Tablas de
Decisión
CEO, CIO decisiones referencia cruzada, listas o reportes
Empleado, Explicar Animación, Historietas, proceso
Información
cliente, otros Convencer obtener compromiso Ilustración, gráfico
Ingeniero de software, Diseño y Diagrama de clases UML, BPMN
Detalle
dueño de proceso Gestión Diagrama de proceso
Analizar las dependencias, Vistas que expresan relaciones como uso, realización
Coherencia Gerentes Operacionales
Impacto del cambio y asignación
Enterprise
Visión Gestión del
Architect, CIO, Landscape Map
General cambio
CEO
7. Punto de Vista Introductorio
Los puntos de vista que se van a presentar a lo largo de todo este capítulo solo representan algunos
de los más significativos con base a la situación expuesta en el planteamiento del proyecto y que
son de mayor prioridad para la perspectiva del mismo.
Los puntos de vista que se presentan en el capítulo son los siguientes:
Punto de Vista Capas

Introductorio Negocio, Aplicación, Tecnológica
Proceso del Negocio Negocio
Estructura de la Aplicación Aplicación
Infraestructura Tecnológica
Estructura de la Infromación Aplicación
7.1 Punto de Vista Introductorio y su funcionalidad a los Stakeholders

Uno de los puntos de vista más importantes para un proyecto es el punto de vista introductorio
ya que permite obtener un panorama general y simplificado del proyecto, al incluir las tres capas
pretende ayudar a Diseñar, decidir, informar y por tanto da soporte a el gerente, administrador y
desarrollador del sistema.
Para caracterizar la dimensión del Punto de Vista Introductorio analizaremos como da soporte
en cada capa a los diferentes Stakeholders:
44 Capítulo 7. Punto de Vista Introductorio
7.1.1 Gerente – Capa del Negocio

La vista Introductoria le permite conocer a grandes ras-
gos la magnitud del proyecto a desarrollar, identificar que
procesos de gran escala dentro de la empresa van a ser
afectados por el proyecto a desarrollar, y poder hacer
estimaciones de costos de la implementación global del
mismo.
Le sirve para reconocer que parte de su personal debe interactuar

con el proyecto permitiéndole planear que formación/capacitación
deberá dar a su personal de acuerdo a la línea estratégica que se
vaya a trabajar.
También le permite al gerente identificar relaciones causales entre los procesos de negocio princi-
pales de la empresa, además de facilitarle el mapeo de procesos de negocio en las funciones de
negocio. Permitiendo coordinar cada servicio con un proceso, evitando el exceso de procesos que
no son de la línea estratégica.
7.1.2 Administrador- Capa de Aplicación

La percepción del Administrador con respecto al punto de
vista introductorio destaca en la necesidad de saber el fun-
cionamiento general de la línea estratégica, para entender
posteriormente el funcionamiento del Sistema que se im-
plemente, permitiéndole dar respaldo y revisión periódica
a los procesos que dan vida a esa línea estratégica y de
esta manera poder gestionar los problemas que se presen-
ten en cualquier parte de la línea y con cualquier actor y/o
rol.
El administrador debe reconocer como se da la realización de los

servicios por parte de los procesos de negocio y garantizar que se
cumplan los procesos bajo los parámetros establecidos por el Manager.
7.1.3 Desarrollador- Capa Tecnología

El punto de vista introductorio le brida una visión integrada de los procesos
de negocio y las aplicaciones de software que van a dar soporte a dichos
procesos.
De ahí que recaiga el peso sobre el desarrollador sobre lo que se comprom-

eterá a hacer, ya que es él quien decidirá sobre cómo deben quedar desarrol-
ladas e implementadas las aplicaciones.
A nivel de Infraestructura, es igualmente obligatorio y esencial el punto

de vista del desarrollador, ya que basado en las aplicaciones que el piense
desarrollar necesitara el entorno adecuado para ejecutar e implementar su
software.
7.2 Consideraciones Generales 45
El punto de vista del desarrollador es poco influyente pero igualmente

necesario, ya que si bien es cierto que él no puede intervenir en las interac-
ciones que se plantean allí, si debe tener en cuenta las mismas para poder
definir los perfiles de usuario que harán parte de las aplicaciones que tenga que desarrollar, y
que permitirán posteriormente al administrador asignar a los empleados que trabajen el sistema
desarrollado para la línea estratégica.
7.2 Consideraciones Generales
Este punto de vista utiliza una notación simplificada para explicar la

Resumen
esencia de un modelo de arquitectura simple, con una notación más intuitiva.
Interesados Arquitectos de la empresa
(Stakeholders) Gerentes
Realizar un diseño que permita visualizar opciones
Preocupaciones
Convencer a las partes interesadas
Propósito Propósito,Diseñar, Decidir, Informar
Nivel de abstracción Coherencia, Detalle, Visión General (Overview)
Capa Capas del Negocio, Aplicación y Tecnológica
Aspectos Estructura, Información y comportamiento
46
7.2.1 Modelo del Punto de Vista Introductorio

A continuación, se enseña el diagrama de vista introductorio que representa de forma general, cómo un cliente opera los servicios ofrecidos por el Sistema
Gestor de Bibliotecas y el soporte que tiene de forma global cada proceso para poderse llevar acabo.
A grandes rasgos en el punto de vista introductorio permite apreciar los procesos que pueden ser automatizados y reducir tiempos y falencias.
Figure 7.1: Punto de Vista Introductorio
Este punto de vista representa una apreciación de alto nivel de toda la línea estratégica del Sistema Gestor de Bibliotecas.
Capítulo 7. Punto de Vista Introductorio
7.3 ESPACIO PARA DANI (PROCESO DEL NEGOCIO) 47
7.3 ESPACIO PARA DANI (PROCESO DEL NEGOCIO)

48
7.4 Punto de Vista de Estructura de la Aplicación
Figure 7.2: Punto de Vista de Estructura del Negocio
En este punto de vista se detallan todos losaspectos sobre la arquitectura a nivel de aplicación.
Aquí se pueden observar algunos flujos dentro de la arquitectura y detalle con respecto a la
Resumen forma en que interactúan los componentes de validación al momento de ingresar al sistema
o de realizar una interacción con los componentes de registro, búsqueda,eliminación,
modificación y para la generación de reportes..
Interesados Administrador del sistema de la biblioteca, Equipo desarrollador, Estudiante, Invitado,
(Stakeholders) Profesor, Administrador.
Preocupaciones Robustez ante fallos, Garantizar usabilidad, Seguridad, Rendimiento.
Propósito Describir la estructura del programa al Detalle
Nivel de abstracción Detalle
Capa Capa Aplicación
Aspectos Estructura e información
7.4 Punto de Vista de Estructura de la Aplicación 49
7.4.1 Descripción de Componentes

En esta capa, los elementos más recurrentes que aparecen son los de función, esto debido a que en
esta parte se busca que el aplicativo sea capaz de cumplir con una serie de funciones solicitadas en
los requerimientos iniciales. Aun así, no todos los elementos que aparecen aquí son de funciones
sino también se pueden encontrar elementos de datos, interfaces y componentes que se encargan de
comunicar con otras capas. A continuación, una descripción de estos elementos que conforman la
capa de aplicación:
• Componente Conectividad: Es el encargo de recibir la conexión de forma física y de re

direccionarla a través de las demás capas hacia el aplicativo. Sirve como intermedio entre las
capas.
• Login: Es una función encargada de regular el ingreso al sistema mediante el uso del compo-
nente de Validación de la Información.
• Consultar Catalogo: Es una función que se encarga de obtener la información referente

al material bibliográfico de la biblioteca mediante la consulta al objeto de datos Elementos
Bibliográficos
• Servicio de consulta:Presenta un servicio de consulta al público para que sea consumido

por alguna otra entidad.
• Elementos bibliográficos: Es un objeto de datos que se encarga de llevar la información de

todos los elementos bibliográficos que posee la biblioteca.
• Control: Es una colección de funciones entre las cuales se destaca la función de conectar
los demás módulos que pasan por él. (Funciona similar al patrón Mediador)
• Módulo de reportes: Es un módulo encargado de generar los reportes sobre el sistema de

forma automática.
• Modulo automatizado: Es un módulo encargado de realizar funciones automáticas con

respecto a los datos de la BD, como incrementar la duración de préstamo actual en los
registros para llevar un control sobre el tiempo de tenencia de los usuarios.
• Datos de usuarios: Objeto de datos que posee la información de los usuarios del aplicativo.
• Acceso como administrador: Agrupación de funciones que permiten realizar diversas ac-
ciones a un administrador del sistema, como gestionar elementos bibliográficos y a usuarios.
• Acceso como usuario básico: Agrupación de funciones que permiten al usuario modificar
sus datos en el sistema o interactuar con los elementos de la biblioteca.
• Solicitud componente: Es una interfaz definida para establecer la conexión con un módulo
determinado por parte de cada funcionalidad que lo requiera.
• Componente registro: Es el encargado de registrar elementos al sistema
• Componente búsqueda:Modulo al que le corresponde obtener información de las búsquedas

50 Capítulo 7. Punto de Vista Introductorio
que se le propongan siguiendo un formato de consulta pre establecido.
• Componente eliminación: Se encarga de eliminar la información asociada que el módulo

implementado desee.
• Componente modificación: Modifica la información mediante el contrato pre establecido

en la implementación de la interfaz.

Este punto de vista da soporte a la infraestructura,de software y de hardware de la capa de aplicación
se trata de dispositivos físicos,redes de comunicación o sistemas de software. El objetivo de este punto
Resumen
es identificar la infraestructura necesaria para dar cumplimiento a los requerimientos
identificados dentro del proceso de negocio
Gerentes operacionales
Interesados
Arquitectos deinfraestructura
(Stakeholders)
Diseñadores de Aplicación
Preocupaciones Dependencias, Desempeño y Escalabilidad
Propósito A nivel de Diseño
Nivel de abstracción Coherencia
Capa Aplicación y Tecnológica
Aspectos Estructura y Comportamiento
7.5.1 Descripción de los Componentes

Una de las representaciones más importantes de este diagrama son los nodos, una combinación de
hardware y software que provee un ambiente de desarrollo adecuado en donde se guardaron los
artefactos para su posible ejecución, dentro de nuestro modelo identificamos cuatro nodos:
• Mainframe(Nodo): Nodo principal de la universidad que interactúa con los sistemas de soft-
ware y de hardware internos, es el que provee la conexión a la red de datos de la universidad.
• ServidoUD(Nodo): Es el nodo encargado de administrar todos los recursos disponibles a

nivel de hardware y software de la universidad. Se vincula al sistema de software de la
universidad.
• ServidoresWeb(Nodo): Son una representación de los servidores con los que interactúa el
sistema por medio de Internet y de la red de la universidad.
• Bases de Datos Externas(Nodo): Son una representación que modela la comunicación

física entre los servidores de la universidad y los externos.
• Redes de Comunicaciones e Internet(Red): Modela el conjunto descentralizado de redes

de comunicación interconectadas. Simula redes físicas heterogéneas que componen la red
lógica de alcance mundial.
• RedUD(Red): Red de Datos UDNET garantiza la continua disponibilidad de los recursos y

servicios de las tecnologías de la información y las comunicaciones existentes, en beneficio
de la comunidad académica y administrativa de la Universidad Distrital Francisco José de
Caldas; a través de la gestión, proyección tecnológica, asesoría y soporte técnico especial-
izado.
7.5 Punto de Vista de Infraestructura 51
• Sistema de Software UD(Sistema de Software): Simula todo el conjunto de software

existente en la Universidad Distrital.
52
7.5.2 Modelo Punto de Vista de Infraestructura
Figure 7.3: Modelo Punto de Vista de Infraestructura

7.5.3 ANEXOS: 1. Modelo Punto de Vista de Infraestructura
Figure 7.4: Anexo 1 Punto de Vista de Infraestructura

53
54
7.5.4 ANEXOS: 2. Modelo Punto de Vista de Infraestructura
Figure 7.5: Anexo 2 Punto de Vista de Infraestructura

7.6 Punto de Vista de Estructura de la Información 55
7.6 Punto de Vista de Estructura de la Información

Muestra la estructura de información utilizada en la empresa, en un, proceso de negocio especifico o de aplicación
Resumen lo hace en términos de tipos,de datos o estructuras. Es comparable con los modelos de información creados,en el
desarrollo de cualquier sistema.
Interesados
Arquitectos de Infraestructura
(Stakeholders)
Dependencias y Estructuras usadas en los objetos de Información,
Preocupaciones Inconsistencia
Integridad de los datos
Propósito A nivel de Diseño
Nivel de abstracción Detalle
Capa Capas Aplicación, Negocio y Tecnológica
Aspectos Información
7.6.1 Descripción de los Componentes

56
7.6.2 Modelo Punto de Vista de Estructura de la Información
Figure 7.6: Modelo Punto de Vista de Estructura de la Información

Bibliografía
Referencias Web
[1] Guia para la construcción de sitios web del Distrito Capital [En línea] Disponible en:
http://www.alcaldiabogota.gov.co/sisjur/normas/verNormaPDF?i=34525
[2] Guia de Requerimientos No Funcionales (Ministerio) [En línea] Disponible en:

http://www.mineducacion.gov.co/1621/articles-310035_archivo_pdf_cm382012_
anexo3.pdf

Main

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Main

Caricato da

Copyright:

Formati disponibili

Sistema Gestor de Bibliotecas

P UBLICADO POR U NIVERISDAD D ISTRITAL

HTTPS :// WWW. UDISTRITAL . EDU . CO

Primera edición, Abril 2016

6 Puntos de Vista en ArchiMate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

7 Punto de Vista Introductorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.1 Puntos de Vista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7.1 Punto de Vista Introductorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.1 Stakeholder: Administrador del sistema de la biblioteca . . . . . . . . . . . . . . 17

La sistematización de los datos es un elemento esencial que se ha implementado de forma necesaria

El control de inventario permite un manejo controlado de la circulación de implementos bib-

El acceso a los implementos bibliográficos influyen notoriamente en el proceso de aprendizaje de

2.1 Descripción del problema

Actualmente presenta varias falencias en cuanto a interoperabilidad (No presta servicios de

Con la automatización y optimización de este sistema es posible llevar un control completo

3.1 Objetivo general:

3.2 Objetivos específicos:

4.1.1 Stakeholders Primarios

Administrador del sistema de la biblioteca

Administrador de la biblioteca virtual

4.1.2 Stakeholders Secundarios

Capital de Bibliotecas (BiblioRed)

Administrador de la red de bibliotecas (BibloRed)

Gerente de recursos físicos (Universidad Distrital)

Consejo académico (Universidad Distrital)

Gerente de recursos financieros (Universidad Distrital)

4.2.1 Requerimientos Funcionales

Requerimiento 1.1: Registrar elementos bibliográficos

Requerimiento 1.2: Buscar elemento Bibliográfico

Requerimiento 1.3: Modificar Elemento Bibliográfico

Requerimiento 1.4: Eliminar Elemento Bibliográfico

Requerimiento 2.1 : Registrar Usuario

Requerimiento 2.2: Consultar Usuario

Requerimiento 2.3: Modificar Usuario

Requerimiento 2.4: Eliminar Usuario

Requerimiento 3.1: Generar Reportes

Requerimiento 4.1: Generar sanciones a usuarios

Requerimiento 5.1: Alquilar elemento de la biblioteca

Requerimiento 6.1: Registrar reserva de elemento

Requerimiento 6.2: Buscar reserva de elemento

Requerimiento 6.3: Modificar reserva de elemento

Requerimiento 6.4: Eliminar reserva de elemento

Requerimiento 7.1: Permitir la interconectividad

Administrador de base de datos

Líder técnico (Arquitecto)

4.2.2 Requerimientos no funcionales

Facilidad de Uso / Accesibilidad

Facilidad para las Pruebas

A continuación se evidencia el análisis realizado de acuerdo a los requerimientos establecidos,

Una Arquitectura Orientada a Servicios permite el diseño aplicaciones de software preparadas

5.2 Centrada en Datos (Pizzarra)

• Los componentes ejecutan procesos de forma independiente. Los diferentes componentes

5.3 Basada en componentes

6 Puntos de Vista en ArchiMate . . . . . . . . 41

7 Punto de Vista Introductorio . . . . . . . . . . 43

6.1 Clasificación de los Puntos de Vista

• Diseño: El punto de vista del diseño apoya a los arquitec-

Para caracterizar el Contenido ArchiMate define los siguientes niveles de abstracción:

• Coherencia: En el nivel de abstracción de coherencia, múltiples capas o múltiples aspec-

• Visión General:El nivel de abstracción de visión general o de resumen aborda múltiples

Figure 6.1: Puntos de Vista

Los puntos de vista que se presentan en el capítulo son los siguientes:

Punto de Vista Capas

7.1 Punto de Vista Introductorio y su funcionalidad a los Stakeholders