software multiplataforma para controlar el prÉstamo de ... · realizar pruebas de casos de uso....
TRANSCRIPT
UNIVERSIDAD NACIONAL DE TRUJILLO
FACULTAD DE CIENCIAS FISICAS Y MATEMATICAS
ESCUELA ACADEMICO PROFESIONAL DE INFORMÁTICA
SOFTWARE MULTIPLATAFORMA PARA CONTROLAR EL
PRÉSTAMO DE MATERIALES BIBLIOGRÁFICOS EN LAS
BIBLIOTECAS DE LA UNIVERSIDAD NACIONAL DE TRUJILLO
Tesis para Obtención de Título de Ingeniero Informático
Autores
Burgos Urquizo, Royer
Chomba Valverde, Juan Carlos
Asesor
Ing. Carlos Castillo Diestra
24 de Setiembre de 2013
Trujillo, La Libertad
INDICE
1. INTRODUCCIÓN ............................................................................................................ 1
1.1. Realidad Problemática ................................................................................................ 1
1.2. Hipótesis ..................................................................................................................... 1
1.3. Objetivo General......................................................................................................... 2
1.4. Objetivos Específicos ................................................................................................. 2
2. MATERIALES Y MÉTODOS ........................................................................................ 3
2.1. Enfoque. ...................................................................................................................... 3
2.2. Tipo de Investigación ................................................................................................. 3
2.3. Población y Muestra. .................................................................................................. 3
2.4. Instrumentos. .............................................................................................................. 4
2.5. Procedimientos. .......................................................................................................... 5
2.6. Métodos y Procedimientos para la Recolección de Datos. ......................................... 5
2.7. Análisis Estadístico de Datos ..................................................................................... 5
2.8. Metodología De Desarrollo del Software ................................................................... 6
2.8.1. Análisis de Requerimientos. ........................................................................... 6
2.8.2. Diseño del Sistema Solución .......................................................................... 6
2.8.3. Implementación del Sistema. ......................................................................... 7
2.8.4. Pruebas. .......................................................................................................... 7
2.8.5. Despliegue del Sistema .................................................................................. 7
3. Resultados ......................................................................................................................... 8
3.1. Marco Teórico ............................................................................................................ 8
3.1.1. Conceptos Básicos. ........................................................................................ 8
3.1.2. Conceptos de Software ................................................................................. 10
3.2. Desarrollo de la Investigación. ................................................................................. 23
3.2.1. Requerimientos del Software ....................................................................... 23
3.2.2. Diseño del Software ..................................................................................... 28
4. Conclusiones .................................................................................................................... 31
5. Referencia Bibliográfica................................................................................................. 32
INDICE DE FIGURAS
Figure 1: Estructura basica de una Libreria ................................................................... 12
Figure 2: Arquitectura por Capas .................................................................................. 15
Figure 3: Factory Pattern .............................................................................................. 19
Figure 4: Template Method Pattern ............................................................................... 20
Figure 5: Composite Pattern .......................................................................................... 21
Figure 7: The facade Design Pattern .............................................................................. 23
Figure 8: Arquitectura y Componentes de la Aplicacion ................................................. 33
Figure 9: Modelo del Dominio ....................................................................................... 34
Figure 10: Entidad Prestamo ......................................................................................... 34
Figure 11: Algoritmo de Prestamo ................................................................................. 35
INDICE DE TABLAS
Table 3: Caso de Uso – Registrar Usuario ......................................................................... 30
Table 3: Caso de Uso - Registrar Libro .............................................................................. 30
Table 3: Caso de Uso - Prestar Libro ................................................................................. 31
Table 4: Caso de Uso - Retornar Libro .............................................................................. 31
Table 5: Caso de Uso - Renovar Libro ............................................................................... 32
Table 6: Caso de Uso - Reclamar Libro ............................................................................. 32
1
1. INTRODUCCIÓN
1.1. Realidad Problemática
Las Bibliotecas de la Universidad Nacional de Trujillo poseen un sistema muy antiguo
que es prácticamente obsoleto ya que el préstamo de materiales se realiza de manera
manual, es decir el usuario tiene que llenar una pequeña ficha en la cual anota el nombre
del material bibliográfico, su código o identificador, el nombre del alumno, el tipo de
uso (sala o domicilio), luego entrega la ficha al bibliotecario junto con su carnet y este
le entrega el material solicitado. Este proceso manual consume mucho tiempo, es muy
propenso a errores y requiere de mucho esfuerzo y disciplina por parte del bibliotecario.
Además, debido al poco presupuesto que posee la universidad no se ha optado por
comprar un software propietario debido a su elevado costo y la infraestructura
tecnológica que demanda para su implementación, optando finalmente por seguir
realizando este proceso manualmente.
Problema.
¿Cómo controlar los materiales bibliográficos en las bibliotecas de la universidad
nacional de Trujillo?
1.2. Hipótesis
La hipótesis planteada fue la siguiente:
El Desarrollo de un software multiplataforma permitirá controlar el préstamo de
materiales bibliográficos.
Variable Independiente : Desarrollo de un software multiplataforma
Indicadores: Usabilidad, Confiabilidad
Variable Dependiente : Controlar el préstamo de recursos bibliográficos
Indicadores: Satisfacción del usuario, Desempeño del Personal
2
1.3. Objetivo General
El objetivo general de este trabajo es:
Desarrollar un software multiplataforma para controlar el préstamo de
materiales bibliográficos.
1.4. Objetivos Específicos
Los Objetivos específicos de este trabajo son:
Analizar el problema mediante técnicas de gestión de requerimientos.
Diseñar el sistema mediante el uso del lenguaje de modelado UML y patrones
de diseño.
Desarrollar el sistema usando una arquitectura por capas y orientada a
servicios.
Realizar pruebas de casos de uso.
Simular el préstamo de materiales bibliográficos utilizando el software
desarrollado en un ambiente controlado.
3
2. MATERIALES Y MÉTODOS
2.1. Enfoque.
El enfoque que tendrá el desarrollo del software será predominantemente cualitativo
debido a la cualidad de software que se desarrolló y predominante cuantitativo debido a
que los usuarios y el personal de la biblioteca calificaran la utilidad que tuvo este
software.
Los niveles de investigación que se llevaran a cabo en este trabajo serán:
- Exploratorio: Porque permitirá sondear el problema en un contexto muy
particular.
- Descriptivo: Porque permitirá comparar entre dos o más fenómenos, situaciones
y estructuras, es decir permitirá predicciones rudimentarias y de medición
precisa
2.2. Tipo de Investigación
Por tratarse del desarrolló de un software dirigido a solucionar un problema se llevara a
cabo una investigación de campo del proceso a automatizar, es decir la observación
directa del proceso, la recopilación de información y análisis del material bibliográfico.
Por tanto, la investigación del presente proyecto es de tipo bibliográfica y documental.
2.3. Población y Muestra.
La población que se va a considerar en la presente investigación será la totalidad del
personal que actualmente labora en la biblioteca de la Facultad de Ciencias Físicas y
Matemáticas y quienes hacen uso de este servicio de préstamo de materiales
bibliográficos como son los estudiante de la escuela de Ingeniería Informática, Física y
Matemática.
.
Para la obtención del tamaño de muestra a dicha población se aplicara la siguiente
formula:
4
Dónde:
n = Tamaño de la muestra =?
N = Tamaño de la población = 1500
e = Error máximo admisible = 0.1
Por lo tanto, se procederá a aplicar las encuestas a 94 estudiantes, además se incluyen a
la totalidad de bibliotecarios, en vista que no es un número muy alto de encuestados, así
se logrará tener una idea más clara de la opinión de los estudiantes de la escuela de
Ingeniería Informática, Física y Matemática.
2.4. Instrumentos.
Para la recolección de datos se usará:
Una grabadora de voz convencional.
Notas de Apunte (Lápiz y Borrador)
Formato de Entrevistas.
Para la prueba del software, se usará:
Impresora blanco-negro Laser HP1010
5
Lector de códigos de barra estándar
Una computadora portátil marca Toshiba A500, procesador Core 2 Dúo
[email protected] GHz, 2167 MHz, 2procesadores, 4,00 GB de RAM
2.5. Procedimientos.
A continuación se describe la secuencia de pasos que se utilizará para desarrollar la
presente investigación:
1. Recolección, Procesamiento y Análisis de la Información.
2. Elaboración de la Realidad problemática y Formulación de Hipótesis.
3. Elaboración del software para experimentación.
4. Contrastación de Hipótesis y Evaluación de Resultados.
5. Documentación del informe.
2.6. Métodos y Procedimientos para la Recolección de Datos.
La recolección de información se realizará mediante observación directa del
funcionamiento de la biblioteca y conversaciones con el personal administrativo, para
así determinar el problema que queremos solucionar
2.7. Análisis Estadístico de Datos
El análisis de la información consistirá en la interpretación y procesamiento de los datos
recolectados, es decir, las entrevistas. Las cuales después de ser procesados servirán
para dar solución al problema planteado. Esta etapa incluye:
1. Revisión y Codificación de la Información
2. Categorización y Tabulación de la Información
Tabulación Manual
3. Análisis de los datos
6
La presentación de los datos se lo hará a través de los datos, cuadros para
analizarlos e interpretarlos.
4. Interpretación de los Resultados
Describir los resultados
Redactar una síntesis general de los resultados
2.8. Metodología De Desarrollo del Software
Para el presente proyecto utilizaremos la metodología de desarrollo de software llamada
Modelo en Cascada (Waterfall Model) propuesta por primera vez por Winston W.
Royce en el año 1970, esta metodología incluye las siguientes fases:
2.8.1. Análisis de Requerimientos.
Durante esta fase se analizan las necesidades de los usuarios finales del software para
determinar qué objetivos cumplir. De esta fase surge documentación que contiene la
especificación completa de lo que debe hacer el sistema a un alto nivel de atracción. En
esta fase se llevan a cabo técnicas de recopilación de requerimientos tales como
entrevistas, reuniones de requerimientos con los usuarios y equipo de desarrollo;
además se definen las características del sistema en un documento Visión y
requerimientos funcionales en un modelo de casos de uso; además se definen atributos
del sistema o requerimientos no funcionales del sistema tales como performance,
seguridad, flexibilidad.
2.8.2. Diseño del Sistema Solución
Si la primera fase se completó con éxito y se ha establecido un plan bien pensado para
el desarrollo de software, el siguiente paso consiste en formular el diseño básico del
software. Como resultado surge el SDD (Documento de Diseño del Software), que
contiene la descripción de la estructura relacional global del sistema y la especificación
de lo que debe hacer cada una de sus partes, así como la manera en que se combinan
unas con otras.
7
Después de que el diseño básico se apruebe, a continuación, se elabora un diseño
técnico más elaborado, es decir se diseñan los algoritmos necesarios para el
cumplimiento de los requerimientos del usuario así como también los análisis
necesarios para saber que herramientas usar en la etapa de codificación.
2.8.3. Implementación del Sistema.
En esta fase, se implementa el código fuente del sistema basado en los modelos creados
previamente en la fase de diseño, haciendo uso de prototipos así como pruebas y
ensayos para corregir errores. Dependiendo del lenguaje de programación se crean
bibliotecas y componentes reutilizables dentro del mismo proyecto para hacer que la
programación sea un proceso mucho más rápido. Así mismo, se usan diferentes técnicas
y patrones de diseño que permiten que el sistema sea escalable y flexible.
2.8.4. Pruebas.
En esta fase, Los elementos (módulos) ya programados se ensamblan para componer el
sistema y se comprueba que funciona correctamente y que cumple los requisitos, antes
de ser entregado al usuario final. En esta etapa se utilizan los casos de uso previamente
desarrollados para comprobarlos mediante el uso de casos de prueba; Además, se
realizan pruebas de seguridad y performance.
2.8.5. Despliegue del Sistema
Es la fase el software obtenido se pone en producción. Se implantan los niveles software
y hardware que componen el proyecto. En esta etapa el usuario final ejecuta el sistema,
para ello el o los programadores ya realizaron exhaustivas pruebas para comprobar que
el sistema no falle. Es una de las fases finales del proyecto.
8
3. Resultados
En este punto se centra el desarrollo y ejecución del plan de trabajo de graduación, se
describe el marco teórico y el desarrollo del software según la metodología trabajo
descrito anteriormente.
3.1. Marco Teórico
En los siguientes puntos se hace referencia a los conceptos empleados para el desarrollo
de la tesis; cada concepto es descrito de forma breve ya que cada uno de ellos tiene
amplia documentación y ello está fuera del alcancé del presente trabajo.
3.1.1. Conceptos Básicos.
Organización de una Librería.
La Figura 1 muestra la organización funcional típica de la biblioteca. Este tipo
tradicional de organización funcional ofrece distintos departamentos de catalogación,
circulación y referencia. A veces, la circulación y los departamentos de referencia se
combinan en un solo departamento, porque no hay personal suficiente para cubrir los
horarios de los dos departamentos separados. Sin embargo, en la gran biblioteca, es
probable que haya un departamento de adquisiciones con el fin de hacer la selección y
adquisición de materiales. [2]
Figura 1. Estructura básica de una Librería
9
Funcionamiento de una Librería.
Las bibliotecas reflejan la diversidad y el carácter de las comunidades a las que sirven.
Excelencia en el servicio de la biblioteca no es una simple cuestión de números. Se
encuentra en el ajuste entre las funciones de la biblioteca y las necesidades y
expectativas de la comunidad a la que sirve.
a. Catalogación.
Catalogar consiste en describir un documento en sus partes esenciales con el fin
de identificar entre el resto del fondo bibliotecario y de conocer su ubicación en
la Biblioteca. Se realiza para identificar un documento y recuperarlo. El objetivo
de la catalogación es identificar los documentos de forma unívoca (Descripción
bibliográfica) y agrupar la información para poder recuperar los documentos
siguiendo los distintos criterios de selección (Normalización de punto de acceso)
El Registro Bibliográfico es conocido también como Asiento y consta de las
siguientes partes: encabezamiento, cuerpo de registro, registros de
encabezamientos secundarios, signatura, número de registro. [2]
b. Clasificación.
Clasificar es agrupar los materiales por su contenido con la finalidad de facilitar
su situación y su búsqueda. La clasificación es una técnica que permite al
bibliotecario organizar los materiales de su biblioteca de acuerdo con el tema a
que éstos se refieren. A la hora de clasificar se pueden utilizar distintos
instrumentos, que se agrupan en: sistemas de clasificación, listas de
encabezamientos de materias. La diferencia entre ambos se encuentra en el
lenguaje que utilizan. Mientras que los sistemas de clasificación tienen un
lenguaje simbólico (notación), las listas de encabezamiento emplean un lenguaje
natural normalizado. Además, los sistemas de clasificación se utilizan en
bibliotecas no solo para obtener un orden físico de los materiales, sino también
intelectual. [2]
10
c. Servicio de Circulación.
Prestar materiales de la biblioteca a los usuarios de la biblioteca. [2]
d. Servicio de Referencia.
Prestar asistencia completa a los lectores en el uso de la biblioteca y su
contenido. [2]
e. Selección.
Traer valiosas sugerencias para aumentar el material de la biblioteca. [2]
f. Adquisición.
Adquirir los libros seleccionados por compra, donación o intercambio. [2]
3.1.2. Conceptos de Software
Arquitectura de Software.
La arquitectura de software palabra denota intuitivamente las estructuras de alto nivel de
un sistema de software. Se puede definir como el conjunto de estructuras necesarias
para razonar sobre el sistema de software, que comprenden los elementos de software,
las relaciones entre ellos, y las propiedades de ambos elementos y relaciones. [7]
La arquitectura de software término también denota el conjunto de las prácticas
utilizadas para seleccionar, definir y diseñar una arquitectura de software. [7]
Por último, el término denota a menudo la documentación de la "arquitectura de
software" del sistema. Documentar la arquitectura de software facilita la comunicación
entre las partes interesadas, capta primeras decisiones sobre el diseño de alto nivel, y
permite la reutilización de componentes de diseño entre los proyectos. [8]
Arquitectura por Capas.
Los programas de software incluyen el diseño y el código para llevar a cabo diferentes
tipos de tareas. Aceptan la entrada del usuario, llevar a cabo la lógica de negocio, bases
de datos de acceso, comunicarse a través de redes, mostrar información a los usuarios, y
11
así sucesivamente. Así que el código involucrado en cada función de programa puede
ser sustancial.
En un programa orientado a objetos de interfaz de usuario, bases de datos, y otros
códigos apoyo consigue a menudo escriben directamente en los objetos de negocio.
Lógica de negocio adicional está incrustado en el comportamiento de widgets de
interfaz de usuario y secuencias de comandos de base de datos. Esto sucede debido a
que es la forma más fácil de hacer que las cosas funcionen, en el corto plazo. [9]
Figura 2. Arquitectura por Capas.
1. Interfaz de Usuario (o Capa de Presentación)
Responsable para mostrar información al usuario y la interpretación de los
comandos del usuario. El actor externo puede ser a veces otro sistema de
computadora en lugar de un usuario humano. [9]
2. Capa de Aplicación.
12
Define los trabajos que el software tiene que hacer y dirige los objetos de
dominio expresivo de solucionar los problemas. Las tareas de esta capa es
responsable son significativos para el negocio o necesarios para la interacción
con las capas de la aplicación de otros sistemas.
Esta capa se mantiene delgada. No contiene normas empresariales o
conocimientos, pero sólo coordina las tareas de trabajo y delegados a las
colaboraciones de los objetos de dominio en la siguiente capa. No tiene estado
que refleja la situación de negocios, pero puede tener estado que refleje el
progreso de una tarea para el usuario o el programa. [9]
3. Capa de Dominio (o Capa de Modelo).
Responsable para representar conceptos de la empresa, la información sobre la
situación del negocio y reglas de negocio. Estado que refleja la situación de
negocios se controla y se utiliza aquí, a pesar de que los detalles técnicos de
almacenamiento que se delegan en la infraestructura. Esta capa es el corazón
del software empresarial. [9]
4. Capa de Infraestructura.
Proporciona capacidades técnicas genéricas que apoyan las capas superiores: el
envío de mensajes de la aplicación, la persistencia del dominio, los widgets de
dibujo para la interfaz de usuario, etc. La capa de infraestructura también puede
admitir el patrón de las interacciones entre las cuatro capas a través de un
marco arquitectónico. [9]
Software Multiplataforma Basada en Servicios.
La industria del desarrollo de software se encuentra actualmente en un estado de
transición hacia un nuevo paradigma de programación: la llamada Arquitectura
Orientada a Servicios (SOA, por sus siglas en inglés).
a. Servicio Web.
Un servicio web (en inglés, Web Service o Web services) es una tecnología que
utiliza un conjunto de protocolos y estándares que sirven para intercambiar
13
datos entre distintas aplicaciones de software desarrolladas en lenguajes de
programación diferentes, y ejecutadas sobre cualquier plataforma, pueden
utilizar los servicios web para intercambiar datos en redes de ordenadores como
Internet. La interoperabilidad se consigue mediante la adopción de estándares
abiertos. Las organizaciones OASIS y W3C son los comités responsables de la
arquitectura y reglamentación de los servicios Web. Para mejorar la
interoperabilidad entre distintas implementaciones de servicios Web se ha
creado el organismo WS-I, encargado de desarrollar diversos perfiles para
definir de manera más exhaustiva estos estándares. Es una máquina que atiende
las peticiones de los clientes web y les envía los recursos solicitados. [10]
b. Protocolo HTTP.
El HTTP que significa Hyper Text Transfer Protocol se compone de 2
mensajes, el primer mensaje es originado por el cliente y es el requerimiento
inicial de la comunicación. Este requerimiento llamado Request está dividido
en una cabecera y un mensaje de texto. En la cabecera el cliente envía
información de la página solicitada al servidor y de la aplicación cliente que
estamos utilizando en el User-Agent, entre otras cosas, como así también los
datos de la plataforma en la cual se encuentra corriendo la aplicación cliente.
c. Protocolo SOAP
Es un protocolo estándar que define cómo dos objetos en diferentes procesos
pueden comunicarse por medio de intercambio de datos XML. Este protocolo
deriva de un protocolo creado por David Winer en 1998, llamado XML-RPC.
SOAP fue creado por Microsoft, IBM y otros. Está actualmente bajo el auspicio
de la W3C. Es uno de los protocolos utilizados en los servicios Web. [10]
d. WSDL
WSDL describe la interfaz pública a los servicios Web. Está basado en XML y
describe la forma de comunicación, es decir, los requisitos del protocolo y los
formatos de los mensajes necesarios para interactuar con los servicios listados
en su catálogo. Las operaciones y mensajes que soporta se describen en
14
abstracto y se ligan después al protocolo concreto de red y al formato del
mensaje.
Así, WSDL se usa a menudo en combinación con SOAP y XML Schema. Un
programa cliente que se conecta a un servicio web puede leer el WSDL para
determinar qué funciones están disponibles en el servidor. Los tipos de datos
especiales se incluyen en el archivo WSDL en forma de XML Schema. El
cliente puede usar SOAP para hacer la llamada a una de las funciones listadas
en el WSDL. El WSDL nos permite tener una descripción de un servicio web.
Especifica la interfaz abstracta a través de la cual un cliente puede acceder al
servicio y los detalles de cómo se debe utilizar.
Patrones de Diseño de Software.
En la ingeniería de software, un patrón de diseño es una solución reutilizable general a
un problema que ocurre comúnmente en un contexto determinado en el diseño de
software. Un patrón de diseño no es un diseño de acabado que se puede transformar
directamente en código de máquina. Es una descripción o una plantilla para la forma de
resolver un problema que se puede utilizar en muchas situaciones diferentes. Los
patrones formalizaron las mejores prácticas que el propio programador debe
implementar en la aplicación. [11]
Patrones de diseño orientado a objetos suelen mostrar las relaciones e interacciones
entre clases u objetos, sin especificar las clases de aplicaciones finales o los objetos que
están involucrados. Los patrones que implican la orientación a objetos o, más
generalmente estado mutable, no son aplicables en lenguajes de programación
funcional. [11]
Los patrones de diseño residen en el dominio de los módulos y las interconexiones. En
un nivel superior hay patrones arquitectónicos que son más grandes en el ámbito de
aplicación, por lo general se describe un patrón general seguido de un sistema completo.
[11]
15
Patrones para la Capa de Dominio
a. Factory Method Pattern
El patrón Factory Method pertenece al grupo creacional de la Banda de los
Cuatro patrones de diseño y se ocupa de la cuestión de la creación de objetos sin
especificar la clase exacta del objeto que se creará. [12].
Propósito.
El objetivo principal del patrón Factory es ocultar la complejidad de la creación
de objetos. Además, el cliente normalmente no especifica una clase particular
que se creará. En cambio, el cliente va a codificar en contra de una interfaz o
clase abstracta y dejar la responsabilidad de la clase Factory para crear el tipo
concreto. Normalmente, una clase Factory tiene un método estático que
devuelve una clase abstracta o interfaz. El cliente por lo general, aunque no
siempre, suministra algún tipo de información, la clase usa la información
suministrada por el determina qué subclase para crear y volver. [12]
Notación UML
Figura 3. Factory Pattern
16
La clase Client obtiene una implementación de IProduct través de una
llamada a la clase Factory. El Client pasa un poco de información sobre el
tipo de subclase, pero no tiene idea de cómo crearlo.
La clase Factory se encarga de crear la subclase correcta basada en la
información suministrada a través de un parámetro.
El IProduct es la interfaz que referencias Client en su rutina de código y que
es implementado por las clases ConcreteProductA y ConcreteProductB.
ConcreteProductA and ConcreteProductBare the subclass implementations
of IProduct
b. Template Method Pattern.
El patrón Template Method pertenece al grupo de los patrones de
comportamiento de la Banda de los Cuatro y se aplica cuando se define el
esqueleto de un algoritmo, pero algunos pasos difieren en cada subclase. [12]
Propósito.
El método plantilla define la estructura del esqueleto de un algoritmo, pero
difiere ciertos pasos y detalles de las subclases. La estructura y el flujo del
algoritmo permanecen estáticos, pero los detalles de los pasos se difieren a las
subclases. [12]
Notación UML
Figura 4. Template Method Pattern
17
El AbstractClass define un flujo de trabajo de proceso de esqueleto con
pasos abstractos que ConcreteClassA y ConcreteClassB sustituir e
implementar. Esto permite a los detalles de un algoritmo para alterar
dependiendo de las subclases, pero permitir que la estructura permanezca
constante.
ConcreteClassA y ConcreteClassB heredan de AbstractClass, implementan
los métodos abstractos, y dan los detalles del algoritmo.
c. Composite Pattern.
El patrón Composite permite una colección de objetos a ser tratado como una
sola instancia de un objeto. [12]
Propósito.
En el patrón Composite, los objetos pueden ser agrupados dentro árboles o
colección jerárquica dinámicamente y se usan como si fueran un solo objeto.
Esto le permite crear el comportamiento sobre la marcha sin el código de cliente
que necesitan para comprender la compleja estructura. [12]
Notacion UML
Figura 5. Composite Pattern.
18
El component es la clase base abstracta que proporciona los medios para
que los objetos que se unen para crear cadenas de comportamiento.
El Leaf es una implementación concreta de la clase abastracta Component
que específica comportamiento lógica de negocio.
El Composite es también una implementación concreta de la component que
permite unir Components para relacionados y proporciona la posibilidad de
llamar de forma recursiva en su comportamiento.
El client agrega objetos y elimina objetos del Composite
Patrones para la Capa de Servicios
a. The facade Design Pattern
Un patrón común utilizado por clientes de SOA es la Facade. El patrón Facade
simplifica la interfaz de un subsistema o un grupo de subsistemas complejo,
dando un cliente de una API no complicada de usar que es consistente con otras
API que el cliente puede utilizar para trabajar en contra. [6]
Propósito.
El patrón Facade proporciona una interfaz sencilla para una API compleja. El
patrón Facade se puede utilizar en muchos escenarios diferentes:
Se puede hacer una biblioteca de terceros más fácil de usar por envolver en
una interfaz compatible con el resto de la aplicación
Puede ayudar al código vagamente par abstrayendo las dependencias con
otros sistemas y bibliotecas.
Se puede envolver un subsistema complicada con una interfaz más sencilla
Notación UML
19
Figura 7. The facade Design Pattern.
El client utiliza la API simple de la Facade para realizar una tarea. El client
no es consciente de lo que realmente se necesita para lograr la transacción.
La Facade esconde la complejidad del sistema detrás de su API simple. La
Facade y luego los delegados de los subsistemas y coteja las respuestas.
SubSystemA y SubSystemB realizar el trabajo para el client.
Patrones para la Capa de Acceso a Datos.
a. The repository Pattern.
A media Repositorio entre el dominio y las capas de asignación de datos,
actuando como una colección de objetos de dominio en la memoria. Objetos de
cliente construye especificaciones de consulta declarativa y presentarlos al
repositorio de satisfacción. Los objetos se pueden agregar y quitar del depósito,
ya que pueden partir de una simple colección de objetos, y el código de
asignación encapsulado por el Repositorio llevará a cabo las operaciones
correspondientes detrás de las escenas.
Conceptualmente, un repositorio encapsula el conjunto de objetos persistido en
un almacén de datos y las operaciones que se realizan sobre ellos,
proporcionando una visión orientada a objetos más de la capa de persistencia.
Repositorio también es compatible con el objetivo de lograr una separación
20
limpia y de un solo sentido de dependencia entre el dominio y las capas de
asignación de datos. [13]
Propósito.
En un sistema grande, con muchos tipos de objetos de dominio y muchas
preguntas posibles, Repositorio reduce la cantidad de código necesario para
hacer frente a todas las consultas que se enciende. Repositorio promueve el
patrón Especificación que encapsula la consulta que se realiza de una manera
orientada a objeto puro. Por lo tanto, todo el código para la creación de un
objeto de consulta en casos específicos puede ser retirado. [13]
Tecnologías.
a. Tecnología Cliente-Servidor.
Desde el punto de vista funcional, se puede definir la computación
Cliente/Servidor como una arquitectura distribuida que permite a los usuarios
finales obtener acceso a la información en forma transparente aún en entornos
multiplataforma. [14]
Cliente.
El cliente es el proceso que permite al usuario formular los requerimientos y
pasarlos al servidor, se le conoce con el término front-end. [14]
El Cliente normalmente maneja todas las funciones relacionadas con la
manipulación y despliegue de datos, por lo que están desarrollados sobre
plataformas que permiten construir interfaces gráficas de usuario (GUI),
además de acceder a los servicios distribuidos en cualquier parte de una red.
[14]
Las funciones que lleva a cabo el proceso cliente se resumen en los
siguientes puntos:
- Administrar la interfaz de usuario.
21
- Interactuar con el usuario.
- Procesar la lógica de la aplicación y hacer validaciones locales.
- Generar requerimientos de bases de datos.
- Recibir resultados del servidor.
- Formatear resultados.
Servidor
Es el proceso encargado de atender a múltiples clientes que hacen peticiones
de algún recurso administrado por él. Al proceso servidor se le conoce con el
término back-end. [14]
El servidor normalmente maneja todas las funciones relacionadas con la
mayoría de las reglas del negocio y los recursos de datos. [14]
Las funciones que lleva a cabo el proceso servidor se resumen en los
siguientes puntos:
- Aceptar los requerimientos de bases de datos que hacen los clientes.
- Procesar requerimientos de bases de datos.
- Formatear datos para trasmitirlos a los clientes.
- Procesar la lógica de la aplicación y realizar validaciones a nivel de bases
de datos.
Características Cliente - Servidor.
Las características básicas de una arquitectura Cliente/Servidor son [14]:
- Las tareas del cliente y del servidor tienen diferentes requerimientos en
cuanto a recursos de cómputo como velocidad del procesador, memoria,
velocidad y capacidades del disco e input-output devices.
- Existe una clara distinción de funciones basada en el concepto de
"servicio", que se establece entre clientes y servidores.
22
- La relación establecida puede ser de muchos a uno, en la que un servidor
puede dar servicio a muchos clientes, regulando su acceso a recursos
compartidos.
- No existe otra relación entre clientes y servidores que no sea la que se
establece a través del intercambio de mensajes entre ambos. El mensaje es
el mecanismo para la petición y entrega de solicitudes de servicio.
- El ambiente es heterogéneo. La plataforma de hardware y el sistema
operativo del cliente y del servidor no son siempre la misma. Precisamente
una de las principales ventajas de esta arquitectura es la posibilidad de
conectar clientes y servidores independientemente de sus plataformas.
- El concepto de escalabilidad tanto horizontal como vertical es aplicable a
cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite
agregar más estaciones de trabajo activas sin afectar significativamente el
rendimiento. La escalabilidad vertical permite mejorar las características del
servidor o agregar múltiples servidores.
b. Tecnologías para Persistencia de Datos.
Object-Relational Mapper (ORM)
El mapeo objeto-relacional es una técnica de programación para convertir
datos entre el sistema de tipos utilizado en un lenguaje de programación
orientado a objetos y la utilización de una base de datos relacional,
utilizando un motor de persistencia. En la práctica esto crea una base de
datos orientada a objetos virtual, sobre la base de datos relacional. Esto
posibilita el uso de las características propias de la orientación a objetos
(básicamente herencia y polimorfismo). Hay paquetes comerciales y de uso
libre disponibles que desarrollan el mapeo relacional de objetos, aunque
algunos programadores prefieren crear sus propias herramientas ORM.
Nhibernate: NHibernate solución (ORM) para la plataforma NET de
Microsoft: Proporciona un framework para el mapeo de un modelo de
dominio orientado a objetos a una base de datos relacional tradicional. Su
23
propósito es aliviar el desarrollador de una porción significativa de las
tareas de programación relacionados con la persistencia de datos
relacionales. NHibernate es libre como el software de código abierto que
se distribuye bajo la Licencia Pública General GNU.
3.2. Desarrollo de la Investigación.
En esta sección se describe los requerimientos y el diseño del software que se pretende
desarrollar.
3.2.1. Requerimientos del Software
El primer paso, es la obtención de requerimientos que especifican lo que el software
debe hacer, es decir su funcionalidad, para ello primeros debemos identificar los
usuarios del software así como sus necesidades.
A. Usuarios del Software
Hemos identificado 2 usuarios del software: el bibliotecario y el usuario de la
biblioteca (estudiante u otro).
1. Bibliotecario
Principales necesidades:
Forma fácil de crear y administrar las cuentas de los usuarios
Habilidad de controlar y administrar actividades tales como:
- Reservaciones
- Prestamos
- Devoluciones
- Renovaciones
Habilidad de generar reportes de operaciones/transacciones
Principales funciones:
Procesar préstamos solicitados por los usuarios de la biblioteca.
Procesar devoluciones de libros.
Renovar el préstamo de libros.
24
Hacer reclamo de libros en préstamo.
Registrar a nuevos usuarios de la biblioteca.
Actualizar la información de usuarios.
Suspender la cuenta de un usuario.
Ayudar al usuario en la búsqueda de materiales bibliográficos.
2. Usuario de la Biblioteca
Principales necesidades:
Manera rápida y sencilla de buscar algún material bibliográfico sea
tesis, revista o libro.
Habilidad de reservar libros desde casas
Habilidad de ver el historial de prestamos
Habilidad de recibir mensajes de alerta cuando el tiempo de préstamo
está por terminar
Principales funciones:
Solicitar préstamo de un material bibliográfico
Devolver un libro u otro material bibliográfico.
Solicitar Renovación de un libro u otro material bibliográfico.
B. Características del Software
Esta sección describe las características del software. Cada característica
proporciona la funcionalidad necesaria para satisfacer las necesidades de los
usuarios.
Gestión de Usuarios
La gestión de usuarios incluye las creaciones de nuevas cuentas de usuario,
cambio de configuración a la cuenta de usuarios, edición de información,
suspensión de cuentas e incluso eliminación de una cuenta de usuario.
25
Gestión de Colección Bibliotecaria
La gestión de colección bibliotecaria incluye el registro de libros,
búsqueda de material bibliográfico por autor, titulo o ISBN, edición de
registros de material bibliográfico y eliminación de los mismos.
Circulación de Material Bibliográfico
La circulación de material bibliográfico incluye el préstamo, reservación,
retorno y reclamos de libros, revistas, tesis entre otros
C. Casos de Uso Representativos
En esta sección se describe los casos de usos más significativos y aquellos que
ayuden a entender como el sistema será usado
Caso de Uso: Registrar Usuario
Actores Bibliotecario
Descripción
Este caso de uso describe como el actor
Bibliotecario registra un nuevo usuario
Flujo normal de
eventos
1. El caso de uso empieza cuando el bibliotecario
navega a la sección “Registrar Usuario” de la
aplicación.
2. Sistema muestra un formulario de información
personal
3. Bibliotecario ingresa el nombre, apellidos,
género, fecha de nacimiento, número de
teléfono celular, número de teléfono fijo, y
email, luego hace clic en registrar.
4. Sistema registra el nuevo usuario.
5. Sistema muestra la cuenta creada.
6. El caso de uso termina.
26
Flujos
Alternativos
A1. Agregar Foto
Cuando el bibliotecario haya llenado el
formulario de registro (paso 3) y antes de hacer
clic en registrar, si desea puede agregar una foto
para el usuario:
Flujos de
Excepción
E1. Cancelar Registro
En cualquier momento del registro, si el
bibliotecario selecciona cancelar
1. Sistema pide confirmación de cancelación.
2. Si el bibliotecario confirma cancelación, el
sistema cierra el formulario de registración.
3. El caso de uso termina.
Tabla 1. Caso de Uso - Registrar Usuario
Caso de Uso: Registrar Libro
Actores Bibliotecario.
Descripción
Este caso de uso describe como el actor
Bibliotecario registra un nuevo libro.
Flujo normal de
eventos
1. El caso de uso inicia cuando el Bibliotecario
navega a la sección “registrar libro” de la
aplicación.
2. Sistema muestra el formulario de registro.
3. Bibliotecario ingresa información del libro como
su título, fecha de publicación, descripción, uso
referencial, ISBN y hace clic en registrar.
4. El caso de uso termina.
27
Tabla 2. Caso de Uso - Registrar Libro
Caso de Uso: Prestar Libro
Actores Bibliotecario
Descripción
Este caso de uso describe como el actor
Bibliotecario realiza el préstamo de un libro.
Flujo normal de
eventos
1. El caso de uso inicia cuando el Bibliotecario
navega a la sección “prestar” de la aplicación.
2. Sistema muestra el formulario de préstamo
3. Bibliotecario ingresa el código del usuario,
código del libro (ISBN/ID), periodo de
préstamo, modo de préstamo, y luego hace clic
en prestar.
4. Sistema registra el préstamo y actualiza el estado
del libro.
5. El caso de uso termina Tabla 3. Caso de Uso - Prestar Libro
Caso de Uso: Retornar Libro
Actores Bibliotecario.
Descripción
Este caso de uso describe como el actor
Bibliotecario realiza el retorno de un libro.
Flujo normal de
eventos
1. El caso de uso inicia cuando el Bibliotecario
navega a la sección “retornar” de la aplicación.
2. Sistema muestra el formulario de retorno.
3. Bibliotecario ingresa el código del libro
(ISBN/ID) y hace clic en devolver.
4. Sistema registra el retorno y actualiza el estado
del libro.
5. El caso de uso termina Tabla 4. Caso de Uso - Retornar Libro
Caso de Uso: Renovar Libro
Actores Bibliotecario.
28
Descripción
Este caso de uso describe como el actor
Bibliotecario realiza la renovación de un libro.
Flujo normal de
eventos
1. El caso de uso inicia cuando el Bibliotecario
navega a la sección “renovar” de la aplicación.
2. Sistema muestra el formulario de renovación.
3. Bibliotecario ingresa el código del libro
(ISBN/ID), nuevo periodo de préstamo y hace
clic en renovar.
4. Sistema registra la renovación.
5. El caso de uso termina. Tabla 5. Caso de Uso - Renovar Libro
Caso de Uso: Reclamar Libro
Actores Bibliotecario.
Descripción
Este caso de uso describe como el actor
Bibliotecario realiza el reclamo de un libro.
Flujo normal de
eventos
1. El caso de uso inicia cuando el Bibliotecario
navega a la sección “prestamos” de la aplicación.
2. Sistema muestra una lista de los libros en
préstamo.
3. Bibliotecario selecciona un l y hace clic en
reclamar.
4. Sistema envía un mensaje al usuario al que se le
presto el libro.
5. El caso de uso termina. Tabla 6. Caso de Uso – Reclamar Libro
3.2.2. Diseño del Software
Luego de definir los requerimientos funcionales del sistema (lo que el sistema debe
hacer) Ahora crearemos el diseño y modelado del software, para ello utilizaremos
diagramas UML tales como diagrama de componentes, diagrama de clases, diagrama de
actividades.
29
A. Arquitectura del Software
El software estará organizado en 4 capas: Capa de Presentación – la cual consta
de todos los componentes de interfaz las cuales manipula el usuario, Capa de
Servicios – la cual proporciona servicios y abstrae los detalles de
implementación, Capa de Lógica del Negocio – la cual modela el negocio, en
esta capa se encuentran los flujos del negocio, y sus entidades, Capa de Acceso a
Datos – la cual proporciona la persistencia de los datos para nuestro modelo
(BLL). Ver figura 8
Figura 8. Arquitectura y Componentes de la Aplicación.
30
B. Modelo del Software
El modelo es el conjunto de entidades que maneja el software y que forman
parte de la capa de lógica del negocio, es decir es un conjunto de clases POCO
(clases que ignoran la persistencia de los datos). En la figura 9 se observa el
modelo del dominio del negocio que se usara para la implementación del
software.
Figura 9. Modelo del Dominio.
En la figura 10 se observa los atributos de nuestra entidad Préstamo, la cual se
relaciona con una Modalidad de préstamo, tiene un Estado, está asociada a un
Usuario y una Copia de un Material Bibliográfico.
31
Figura 10. Entidad Préstamo.
En la figura 11 se muestra el algoritmo (lógica) utilizado para el procesamientos
de préstamos.
Figura 11. Algoritmo de Préstamo
4. Conclusiones.
La implantación del Sistema permitirá automatizar el área de préstamos de
material bibliográfico permitiendo contribuir al crecimiento tecnológico de la
Bibliotecas de la Universidad Nacional de Trujillo.
La implantación del Sistema optimizara el trabajo manual de préstamo de
material bibliográfico, dando como resultado la pronta ejecución de este
proceso.
32
5. Referencia Bibliográfica
[1] Bhupendra Singh Baghela, Shraddha Panwar, Vijay Vaishnav, "Online Library
Management System", 2001, Disponible en:
http://www.iisjaipur.org/management_system.pdf
[Fecha de consulta: 27 agosto del 2013]
[2] Seong Seung Park March, "The Development Of A Database Management System
For Librar Loan Management", 1990 , Disponible en:
http://www.dtic.mil/dtic/tr/fulltext/u2/a226249.pdf
[Fecha de consulta: 27 agosto del 2013]
[3] Joaquim Jorge Rodrigues, " An Integrated Library System on the CERN Document
Server ", 2010 , Disponible en:
http://cds.cern.ch/record/1294486/files/CERN-THESIS-2010-115.pdf
[Fecha de consulta: 28 agosto del 2013]
[4] Neelakandan.B, Duraisek ar. S, Balasubramani .R, Srinivasa Ragavan.S , "
Implementation of Automated Library Management Systemr ", 2010 , Disponible en:
http://www.ipublishing.co.in/jarvol1no12010/EIJAER1014.pdf
[Fecha de consulta: 28 agosto del 2013]
[5] Sangsuree Vasupongayya, Kittisak Keawneam, Kittipong Sengloilaun, Patt
Emmawat, " Open Source Library Management System Softwarer ", 2011 , Disponible
en: http://www.waset.org/journals/waset/v53/v53-178.pdf
[Fecha de consulta: 28 agosto del 2013]
[6] Guy R. Lyle, “The Administration of the College Library”, 4th Edition, The H.W.
Wilson Company, 1974.
[7] Clements, Paul; Felix Bachmann, Len Bass, David Garlan, James Ivers, Reed Little,
Paulo Merson, Robert Nord, Judith Stafford. “Documenting Software Architectures:
Views and Beyond, Second Edition”. Boston: Addison-Wesley, 2010.
[8] Clements P, Kazman R, “Software Architecture In Practice, Third Edition”. Boston:
Addison-Wesley, 2012.
[9] Evans E. “Domain Driven Design: Tackling Complexity in the Heart of Software”.
Addison-Wesley, 2003.
33
[10] Alonso G. , Casati F. , Kuno H. , Machiraju V. "Web Services: Concepts,
Architectures and Applications",New York Springer, 1998.
[11] Martin, Robert C.. "Design Principles and Design Patterns". Retrieved 2000.
[12] Millett S. "ASP.NET Design Patterns", Indiana Wiley Publishing, Inc, 2010.
[13] Fowler M. “Patterns of Enterprise Application Architecture”, Pearson Education,
2003.
[14] Kenneth E. , Kendall, Julie E ,” Análisis y diseño de sistemas”, Paperback –
August 1, 2005.
34
A. Anexos
A.1 Formato Entrevistas a Usuarios
A.1.1 Entrevista de Usabilidad
Nombre:
Fecha:
Califique su nivel de satisfacción de acuerdo con las siguientes afirmaciones.
Entrevista
Usuario (Estudiante) 1 2 3 4 5 NS/NC
1. Búsqueda de Publicaciones título, ámbito, Autor,
2. Realiza Préstamo.
3. Búsqueda de Prestamos
Personal (Bibliotecario) 1 2 3 4 5 NS/NC
1. Búsqueda de Publicaciones título, ámbito, Autor,
2. Ingresar nueva publicación
3. actualizar / modificar publicación
4. eliminar publicación
5. Crear Autor
6. Actualizar /Modificar Autores
7. Búsqueda de usuario de Biblioteca
8. Búsqueda de Prestamos
9. Actualizar / Modificar Préstamo
10. Reportes Sistema
1 = muy malo.
2 = malo.
3 = regular
4 = bueno
5 = muy bueno
Señale NS/NC si no tiene un juicio formado sobre la pregunta realizada.
35
A.1.1 Entrevista de Satisfacción
Nombre:
Fecha:
Califique su nivel de satisfacción de acuerdo con las siguientes afirmaciones.
Entrevista
Usuario (Estudiante) – Servicios de la Biblioteca 1 2 3 4 5 NS/NC
4. La Biblioteca tiene las colecciones de las revistas electrónicas que necesito
5. Estoy informado de las novedades de la Biblioteca.
6. Con las herramientas de búsqueda de información encuentro fácilmente lo
que necesito;
7. El Servicio de Reserva de libros me ahorra tiempo.
8. La Biblioteca tiene ejemplares suficientes de los libros impresos que
necesito.
9. En General estoy satisfecho con el servicios que brinda la biblioteca
Personal (Bibliotecario) 1 2 3 4 5 NS/NC
11. Está dispuesto a satisfacer las necesidades de los usuarios
12. Realiza el servicio correctamente
13. Es amable con los usuarios
14. Atiende con rapidez
15. El sistema actual facilita su labor.
1 = deficiente.
2 = malo.
3 = regular
4 = bueno
5 = excelente
Señale NS/NC si no tiene un juicio formado sobre la pregunta realizada.
36
A.2 Modelo de Casos de Uso
Figura A.1 Diagrama de Caso de Usos
Gestión de Usuarios
Esta sección describe los casos de uso relacionados a la gestión de usuarios.
1. Registrar Usuario
Este caso de uso describe como el actor Bibliotecario registra un nuevo
usuario.
Flujo Principal
1. El caso de uso empieza cuando el bibliotecario navega a la sección
“Registrar Usuario” de la aplicación.
2. Sistema muestra un formulario de información personal
3. Bibliotecario ingresa el nombre, apellidos, género, fecha de
nacimiento, número de teléfono celular, número de teléfono fijo, y
email, luego hace clic en registrar.
4. Sistema registra el nuevo usuario.
5. Sistema muestra la cuenta creada.
6. El caso de uso termina.
Flujos Alternativos
37
Agregar Foto
Cuando el bibliotecario haya llenado el formulario de registro (paso 3) y
antes de hacer clic en registrar, si desea puede agregar una foto para el
usuario:
1. Bibliotecario hace clic en browser para localizar el archivo en la
computadora que se quiere agregar como foto del usuario.
2. Bibliotecario hace clic en registrar.
3. Sistema registra el nuevo usuario.
4. Sistema agrega el archivo seleccionado como foto de usuario.
5. El caso de uso termina
Flujos de Error
Cancelar Registro
En cualquier momento del registro, si el bibliotecario selecciona
cancelar
1. Sistema pide confirmación de cancelación.
2. Si el bibliotecario confirma cancelación, el sistema cierra el
formulario de registración.
3. El caso de uso termina (no se registra al usuario).
2. Explorar Usuarios
Este caso de uso describe como el actor Bibliotecario explora las cuentas de
los usuarios.
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la sección
“usuarios” de la aplicación.
2. Sistema presenta una lista de usuarios.
3. Bibliotecario selecciona un usuario.
4. Ejecutar Ver Detalles de Usuario (S1) para mostrar información
detallada del usuario seleccionado.
5. El caso de uso termina.
Gestión de Colección Bibliotecaria
38
Esta sección describe los casos de uso relacionados a la gestión de material
bibliográfico.
1. Registrar Libro
Este caso de uso describe como el actor Bibliotecario registra un libro.
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la sección
“registrar libro” de la aplicación.
2. Sistema muestra el formulario de registro.
3. Bibliotecario ingresa información del libro como su título, fecha de
publicación, descripción, uso referencial, ISBN y hace clic en
registrar.
4. El caso de uso termina.
Circulación de Material Bibliográfico
Esta sección describe los casos de uso relacionados a la circulación de material
bibliográfico.
1. Prestar Libro
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la sección
“prestar” de la aplicación.
2. Sistema muestra el formulario de préstamo.
3. Bibliotecario ingresa el código del usuario, código del libro
(ISBN/ID), periodo de préstamo, modo de préstamo, y luego
hace clic en prestar.
4. Sistema registra el préstamo y actualiza el estado del libro.
5. El caso de uso termina
2. Retornar Libro
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la sección
“retornar” de la aplicación.
2. Sistema muestra el formulario de retorno.
39
3. Bibliotecario ingresa el código del libro (ISBN/ID) y hace clic en
devolver.
4. Sistema registra el retorno y actualiza el estado del libro.
5. El caso de uso termina.
3. Renovar Libro
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la sección
“renovar” de la aplicación.
2. Sistema muestra el formulario de renovación.
3. Bibliotecario ingresa el código del libro (ISBN/ID), nuevo
periodo de préstamo y hace clic en renovar.
4. Sistema registra la renovación.
5. El caso de uso termina.
4. Reclamar Libro
Flujo Principal
1. El caso de uso inicia cuando el Bibliotecario navega a la sección
“prestamos” de la aplicación.
2. Sistema muestra una lista de los libros en préstamo.
3. Bibliotecario selecciona un l y hace clic en reclamar.
4. Sistema envía un mensaje al usuario al que se le presto el libro.
5. El caso de uso termina.
40
A.3 Diseño del Software
Arquitectura del Software
Figura A.2 Arquitectura del Software
41
Diagrama de Componentes
Figura A.3 Diagrama de Componentes.
42
Modelo del Dominio
Figura A.4 Modelo del dominio.
Entidades
Figura A.4.1 Entidad Usuario.
43
Figura A.4.2 Entidad Autor.
Figura A.4.3 Entidad Material.