Documento Subsistema Control Elementos Devolutivos

SUBSISTEMA CONTROL DE ELEMENTOS DEVOLUTIVOS
LUZ MARY BUITRAGO GÓMEZ (CÓDIGO. 084950442017)

LINA ROCIO MOSQUERA GARCÍA (CÓDIGO. 084950092017)
DAVID ESTEBAN TRUJILLO MORENO (CÓDIGO 084950382017)
UNIVERSIDAD DEL TOLIMA

INSTITUTO DE EDUCACIÓN A DISTANCIA IDEAD
PROGRAMA DE INGENIERÍA DE SISTEMAS
SEMINARIO PL/SQL
IBAGUÉ, TOLIMA
AÑO 2019
INDICE
INTRODUCCIÓN .......................................................................................................................... 4
1. OBJETIVOS ............................................................................................................................ 5
GENERAL ........................................................................................................................... 5
ESPECIFICOS ..................................................................................................................... 5
2. METODOLOGÍA .................................................................................................................... 6
2.1. Fase Análisis de requisitos ............................................................................................... 6
Requerimientos Funcionales ............................................................................................ 6
Elaboración Modelo Conceptual de Datos ....................................................................... 6
2.2. Fase de Diseño ................................................................................................................. 6
Elaboración del modelo físico .......................................................................................... 7
Diseño CRUD .................................................................................................................. 7
2.3. Fase de Construcción ....................................................................................................... 7
3. ANÁLISIS DE REQUERIMIENTOS..................................................................................... 8
3.1. ALCANCE ....................................................................................................................... 8
3.2. REQUERIMIENTOS FUNCIONALES .......................................................................... 9
Descripción de procesos ................................................................................................... 9
3.3. MODELO CONCEPTUAL DE DATOS ....................................................................... 12
Concepto Modelo Conceptual ........................................................................................ 12
Diagrama Entidad relación E / R (Modelo Conceptual) ................................................ 13
Descripción de Entidades ............................................................................................... 13
4. DISEÑO................................................................................................................................. 14
4.1. MODELO FÍSICO DE DATOS .................................................................................... 14
Diagrama Relacional (Modelo Físico) ........................................................................... 15
Descripción De Las Tablas ............................................................................................ 15
4.2. ARQUITECTURA MODULAR.................................................................................... 19
Diagrama de Jerarquía de Módulos ................................................................................ 20
Descripción de Módulos................................................................................................. 22
5. CONSTRUCCIÓN ................................................................................................................ 24
5.1. PRUEBAS ...................................................................................................................... 24
Inserción ......................................................................................................................... 24
Actualización .................................................................................................................. 25
Eliminación .................................................................................................................... 26
Consultas ........................................................................................................................ 27
6. CONCLUSIONES ................................................................................................................. 29
7. REFERENCIAS .................................................................................................................... 30
8. ANEXOS ............................................................................................................................... 31
8.1. CAPA DE ALMACENAMIENTO ................................................................................ 31
Script de la Base de Datos .............................................................................................. 31
8.2. CAPA LÓGICA ............................................................................................................. 31
Procedimientos ............................................................................................................... 31
INTRODUCCIÓN
En la actualidad el respaldo, cuidado y administración de la información es vital para cualquier
organización sin importar su objeto empresarial, por tal razón las tecnologías de la información
han ayudado a la creación de sistemas inteligentes que brinden a los usuarios la seguridad de
preservar y gestionar su información de la manera más eficiente. Para esto se ha optado por el
diseño e implementación de bases de datos que cumplan con el objetivo principal que es conservar
de manera segura la información de las organizaciones.
A continuación se describe el diseño e implementación de un modelo de datos y lógico para el
módulo o subsistema elementos devolutivos de un sistema de información perteneciente a un
colegio de secundaria el cual tiene como fin satisface los requerimientos funcionales suministrados
por el tutor. Lo primero que se expondrá es el diseño de los modelos relacionales conceptual y
físico realizados con una herramienta CASE denominada Power Designer, seguido a estó se realiza
la capa de almacenamiento la cual consta del script para la generación de la base de datos la cual
es de tipo ORACLE, por último se encuentra la capa lógica en la cual se muestran los
procedimientos realizados en el subsistema los cuales fueron codificados en lenguaje PL/SQL e
implementados en el motor de base de datos SQL Developer y permiten insertar, actualizar,
eliminar, consultar y auditar la transacciones realizadas en el módulo.

1. OBJETIVOS
 GENERAL
Implementar las capas de almacenamiento de datos y lógica de un aplicativo que soporte los
procesos del subsistema de información para el control de elementos devolutivos de un
colegio de secundaria.
 ESPECIFICOS
 Desarrollar los procedimientos para el módulo de inserción y actualización de la tabla de
detalle_transaccion que será validado por medio de las tablas de transacción, y
elementos_devolutivos.
 Realizar los procedimientos para el módulo de consultas referente a las transacciones y su
respectivo detalle_transaccion y sus relaciones con las tablas tipo_transaccion
funcionarios, y elementos_devolutivos.
 Desarrollar los procedimientos para el módulo de consultas sumarias relacionadas con el
costo de adquisición de los elementos_devolutivos, separados por tipo_elemento y
obtener el cálculo del IVA que se pagó por dichos elementos.
 Desarrollar los procedimientos para el cambio de la disponibilidad de los elementos
devolutivos en caso de que sean prestados o devueltos en un detalle transacción.
 Desarrollar los procedimientos de auditoría para la tabla de detalle_transaccion ( log)

2. METODOLOGÍA
La metodología que se aplicará constará de tres fases las cuales serán análisis de
requerimientos, diseño y construcción; en cada una de las cuales se detallará lo desarrollado para
la generación del subsitema.
2.1. Fase Análisis de requisitos
 Requerimientos Funcionales
Los requerimientos funcionales fueron asignados por el tutor por medio de un documento
debidamente detallado con cada una de las necesidades del módulo con esto lo que se obtuvo
fue un catalogo de requerimientos funcionales expresados en párrafos de procesos asincrónicos.
 Elaboración Modelo Conceptual de Datos
Se realizó basado en la técnica del diagrama relacional E/R, primero se identificaron las
entidades, luego sus relaciones entre sí y por último los atributos de cada entidad, definiendo sus
llaves primarias, su obligatoriedad y los tipos de datos q permiten ingresar en cada campo.
2.2.Fase de Diseño
En esta fase se desarrollaron las actividades de estructuración de los modelos de la Base de datos,
se obtuvo el modelo conceptual y el modelo físico de la BD y una base de datos relacional; para
el diseño de los modelos se empleó una herramienta CASE la cual es Power Designer.
 Elaboración del modelo físico
El diseño físico de la base de datos se creó en base al modelo conceptual previo, también se
realizó aplicando la técnica del modelo entidad relación. Durante el diseño físico, se transforman
las entidades en tablas, las instancias en filas y los atributos en columnas.
 Diseño CRUD
Se realiza el diseño de los CRUD (Create, read, Update, delete) a través de diagramas de
Jerarquía de módulos los cuales tienen como fin explicar el camino que recorren los
procedimientos al momento de ejecutarse, desde la capa de presentación hasta la capa de datos
2.3.Fase de Construcción
En esta fase se obtuvo el Script de la BD , se realizó la población de las tablas y se crearon los
procedimientos para los cuales se empleó un enfoque estructurado, no orientado objetos, la
tecnología utilizada fue lenguaje de programación PL/Sql .
 Generación del script
El Script se obtiene a partir del modelo físico de datos por medio de la herramienta CASE
Power Designer y se implementa en el entorno de desarrollo SQL Developer con un lenguaje de
programación Oracle PL/Sql.
 Cargue del script al motor Oracle utilizando SQL Developer.
Para el cargue del script, se crea un usuario por medio de la consola de la herramienta
SQL*Plus de Oracle XE, luego se realiza la creación de una nueva base de datos en el entorno de
desarrollo en el entorno de desarrollo Sql Developer y se realiza la conexión de la DB con el
usuario creado y se importa el Script sql generado prevamente.
 Población de tablas
Para la población de las tablas se realizaron los insert directamente desde el entorno de
desarrollo integral SQL Developer mediante el lenguaje PL-SQL que es un lenguaje de
programación incrustado en Oracle y que soporta todas las consultas. La estructura para la
inserción de datos es INSERT INTO "nombre_tabla" ("columna1", "columna2”) VALUES
("valor1", "valor2",...).
 Construcción, compilación y pruebas de los módulos CRUD, los módulos de
consulta y auditoría.
Se realizó la programación de los procedimientos para la inserción, edición, eliminación y
consulta al subsistema en el lenguaje PL/Sql directamente en el entorno Sql Developer,
posterior a esto se realizaron las pruebas a cada uno de los procedimientos para comprobar
que se ejecutaran correctamente y que en efecto cumplieran con lo requerido.
3. ANÁLISIS DE REQUERIMIENTOS
3.1. ALCANCE
El análisis, diseño, construcción y prueba de las capas de almacenamiento y lógica de un
aplicativo cliente servidor con tecnología de base de datos Oracle que soporte los procesos del
subsistema de control de elementos devolutivos de un colegio.

El aplicativo facilitará la gestión de la información correspondiente a los procesos
relacionados con el control de los elementos devolutivos, esto se realiza por medio de
transacciones para el préstamo o devolución de los elementos con una especificación detallada,
además de generar un historial de los procesos realizados.
3.2. REQUERIMIENTOS FUNCIONALES
Para la determinación de los requerimientos funcionales del subsistema de control de
elementos devolutivos, se requiere complementar el modelo conceptual de la base de datos del
sistema del colegio con la implementación de un diseño para el subsistema de control de
elementos devolutivos los requerimientos son los siguientes:
 Descripción de procesos
REGISTRO DE FUNCIONARIOS
Todos los funcionarios que deseen pedir elementos al colegio deben estar o ser registrados
para llevar a cabo dicho proceso y tener un mejor control en cuanto a quien se le ha prestado y si
aún tiene o no algo pendiente. Los principales datos que deben aparecer en dicho registro son:
nombre, apellido, tipo de documento, número de documento, género, municipio de nacimiento,
cargo y dependencia a la que pertenece.
REGISTRO DE ELEMENTOS DEVOLUTIVOS
Se requiere tener un registro de los elementos que se van a prestar y que tienen carácter de
devolutivo. Para ello es necesario tener en cuenta los siguientes datos: identificador numérico del
devolutivo, nombre del devolutivo, descripción del devolutivo, año de adquisición, valor de
adquisición, tipo de devolutivo (equipo de oficina, mueble de oficina, computador, equipo
audiovisual, etc.), estado de disponibilidad (disponible, prestado).
REGITRO DE PRÉSTAMOS Y DETALLES
Al momento que un funcionario desee realizar un préstamo sobre algún elemento, se debe
elaborar un comprobante de préstamo y registrar en su cabecera el número del préstamo, fecha
del préstamo, tipo de documento y número de documento del funcionario a quien se le hace el
préstamo.
En el detalle del préstamo se registra un ítem de detalle, el identificador del elemento
devolutivo a prestar, la cantidad prestada se asume con el valor de 1 y el estado de aplicación del
detalle del préstamo (PA= pendiente de aplicar, AP= aplicado)
REGISTRO DE DEVOLUCIÓN Y DETALLES
Al momento que un funcionario desee realizar una devolución de algún elemento devolutivo,
se debe elaborar un comprobante de devolución y registrar en su cabecera el número de
devolución, fecha de la devolución, tipo de documento y número de documento del funcionario
que devuelve el elemento.
En el detalle de la devolución se registra un ítem de detalle, el identificador del elemento que
se devuelve y el estado de aplicación del detalle de la devolución (PA= pendiente de aplicar,
AP= aplicado)
APLICACIÓN DE LOS COMPROBANTES TRANSACCIONALES DE DEVOLUTIVOS
Al solicitarle al sistema la aplicación en lote de las transacciones diarias pertinentes a
elementos devolutivos, se debe proceder de la siguiente manera:
Por cada comprobante de préstamo, el sistema debe actualizar el estado de disponibilidad del
elemento devolutivo cambiándolo de disponible a prestado y actualizar el detalle del préstamo de
PA= pendiente de aplicar a AP= aplicado.
Por cada comprobante de devolución, el sistema debe actualizar el estado de disponibilidad
del elemento devolutivo cambiándolo de prestado a disponible, y actualizar el detalle de la
devolución de PA= pendiente de aplicar a AP= aplicado.
GENERACIÓN DE REPORTES Y CONSULTAS
Se desea que se puedan generar reportes de la siguiente forma:
 Una relación de los elementos devolutivos del colegio clasificado por tipo de devolutivo
donde se especifique el identificador del devolutivo, nombre del devolutivo, año de
adquisición, valor de adquisición y estado de disponibilidad.
 Dado el identificador del elemento devolutivo, el sistema muestre los datos del elemento.
 Dados el tipo de documento y el número de documento de un funcionario, el sistema
debe generar una relación donde se especifiquen los datos básicos de los elementos
devolutivos a cargo del funcionario referenciado.
 Un informe donde se relacione el historial de préstamos y devoluciones realizados sobre
un elemento, indicando el identificador de la transacción, tipo de transacción, fecha de la
transacción y los datos del funcionario relacionado con la transacción. Para la generación
del reporte, el sistema solicitará el identificador del elemento devolutivo para el que se
requiere el historial.
3.3.MODELO CONCEPTUAL DE DATOS
 Concepto Modelo Conceptual
Identifica las relaciones de más alto nivel entre las diferentes entidades. El modelo entidad –
relación es un modelo conceptual que representa la vista estructural de datos de un sistema a
través de entidades y relaciones entre las entidades pertinentes de un sistema y se utiliza en el
proceso de base de datos. (Pacheco, 2017, pag.9).
En esta sección se encontrará el modelo conceptual de datos del diagrama E/R (entidad –
relación) perteneciente al subsistema del control de elementos devolutivos, así como la
descripción de cada una de las entidades.

 Diagrama Entidad relación E / R (Modelo Conceptual)
Ilustración 1
Modelo Conceptual de Datos
Fuente: Elaboración Propia
 Descripción de Entidades
Tabla 1
Descripción de Entidades
ENTIDADES DESCRIPCIÓN
Representa el cargo que se le asigne a cada
CARGO
funcionario del colegio.
Representa la dependencia a la cual pertenece el
DEPENDENCIA
funcionario.
Registra el detalle de la transacción que se
realiza, allí se especifica el elemento y la
DETALLE TRANSACCIÓN
cantidad de elementos solicitados por el
funcionario.
Representa los elementos devolutivos con los que
ELEMENTOS DEVOLUTIVOS
cuenta el colegio para su préstamo.
FUNCIONARIOS Registro de los datos básicos del funcionario.
IDENTIFICACIÓN Registra el tipo de identificación del funcionario.
MUNICIPIO Registra el nombre del municipio.
Registra el tipo al que pertenece el elemento
TIPO DE ELEMENTO devolutivo (ej, audiovisual, proyección,
mobiliario etc.)
Se registran el tipo de transacción que se pueden
TIPO DE TRANSACCIÓN realizar en el sistema (ej. Préstamos,
devoluciones, etc.)
Aquí se lleva a cabo el registro de la transacción
se incluirá el funcionario que la realiza, y que
TRANSACCIONES tipo de transacción realiza al igual que la fecha,
esto para que posteriormente sea asociado a un
detalle.
4. DISEÑO
4.1. MODELO FÍSICO DE DATOS
El modelo de datos físico muestra una representación de cómo será construida la base de
datos. Este modelo especifica todas las estructuras de la tabla incluidos el nombre, tipo de datos
y restricciones de las columnas, la llave principal, la o las llaves foráneas y las relaciones entre
las tablas. (Tecnologías-Información, s.f)
El modelo físico de datos se crea a partir del diagrama entidad relación en el cual las tablas
representan a las entidades y la interdependencia entre las tablas a las relaciones. Y sirve para
conocer los tipos de datos que almacenarán los campos de la base de datos. (Editorial, 2013)
En esta sección se encontrará el modelo físico del diagrama relacional perteneciente al
módulo Elementos Devolutivos, así como la descripción de cada una de sus tablas.
 Diagrama Relacional (Modelo Físico)
Ilustración 2
Modelo Físico de Datos
Cargo Tipo_Transaccion
Id_Cargo NUMBER(2) <pk> Id_TipoTransaccion NUMBER(3) <pk>

Nombre_Cargo VARCHAR2(40) Nombre_Transaccion VARCHAR2(30)
Identificacion
Id_Identificacion CHAR(2) <pk> FK_TRANSACC_REFERENCI_TIPO_TRA
Tipo_Identificacion VARCHAR2(40)
FK_FUNCIONA_CARGO_ACT_CARGO
Transacciones
FK_FUNCIONA_TIENE_IDENTIFI Id_Transaccion NUMBER(10) <pk>

Id_Funcionarios NUMBER(3) <fk1>
Id_TipoTransaccion NUMBER(3) <fk2>
FK_TRANSACC_REALIZA_
Fecha DATE
FUNCIONA
Funcionarios
Id_Funcionarios NUMBER(3) <pk> FK_DETALLE__GENERA_TRANSACC
Id_Municipio NUMBER(3) <fk3>
Id_Dependencias NUMBER(3) <fk4>
Id_Identificacion CHAR(2) <fk2> Detalle_Transaccion
Id_Cargo NUMBER(2) <fk1> Id_Transaccion NUMBER(10) <pk,fk3>
Nombres VARCHAR2(30) Id_Detalle NUMBER(10) <pk>
Apellidos VARCHAR2(30) Det_Id_Transaccion NUMBER(10) <fk2> FK_DETALLE__REGISTRA_ELEMENTO
Num_Identificacion NUMBER(10) Det_Id_Detalle NUMBER(10) <fk2>
Genero CHAR(1) Id_Elemento NUMBER(3) <fk1>
Cant NUMBER(1)
Elementos_Devolutivos
Id_Elemento NUMBER(3) <pk>
FK_FUNCIONA_NACIMIENT_MUNICIPI
Id_TipoElemento NUMBER(2) <fk>
FK_DETALLE__ANTECEDE_DETALLE_ Nombre VARCHAR2(30)
Año_Adquisicion NUMBER(4)
FK_FUNCIONA_PERTENECE_DEPENDEN Valor_Adquisicion NUMBER(10)
Estado_Disponibilidad VARCHAR2(10)
Municipio
Id_Municipio NUMBER(3) <pk>
Nombre_Municipio VARCHAR2(30) FK_ELEMENTO_CORRESPON_TIPO_ELE
Tipo_Elemento
Dependencias Id_TipoElemento NUMBER(2) <pk>
Descripcion VARCHAR2(100)
Id_Dependencias NUMBER(3) <pk>
Nombre_Dependencia VARCHAR2(30)
 Descripción De Las Tablas
A continuación se presentará una tabla con la descripción de cada uno de los campos que
poseen las tablas del modelo:
PK: Primary Key – Llave Primaria
FK: Foreign Key – Llave Foránea
N/A: No aplica
Tabla 2
Descripción Tabla Cargo
CARGO
Tipo de Obligatorio u Tipo de
Nombre Descripción Longitud
Dato Opcional Llave
Código
Id_Cargo NUMBER 2 Obligatorio PK
identificador
Nombre del
Nombre_Cargo VARCHAR2 40 Obligatorio N/A
cargo
Tabla 3
Descripción Tabla Identificación
IDENTIFICACIÓN
Obligatorio
Tipo de Tipo de
Nombre Descripción Longitud u
Dato Llave
Opcional
Código
Id_Identificacion CHAR 2 Obligatorio PK
identificador
Tipo de
Tipo_Identificacion VARCHAR2 40 Obligatorio N/A
Identificación
Tabla 4
Descripción Tabla Municipio
MUNICIPIO
Tipo de Obligatorio u Tipo de
Nombre Descripción Longitud
Dato Opcional Llave
Código
Id_Municipio NUMBER 3 Obligatorio PK
identificador
Nombre del
Nombre_Municipio VARCHAR2 30 Obligatorio N/A
municipio
Tabla 5
Descripción Dependencias
DEPENDENCIAS
Obligatorio
Tipo de Tipo de
Dato Llave
Opcional
Código
Id_Dependencias NUMBER 3 Obligatorio PK
identificador
Nombre de la
Nombre_Dependencia VARCHAR2 30 Obligatorio N/A
Dependencia
Tabla 6
Descripción Tabla Funcionarios
FUNCIONARIOS
Obligatorio Tipo
Tipo de
Nombre Descripción Longitud u de
Dato
Opcional Llave
Id_Funcionarios Código identificador NUMBER 3 Obligatorio PK
Código identificador
Id_Municipio NUMBER 3 Obligatorio FK
del municipio
Id_Dependencias NUMBER 3 Obligatorio FK
de la dependencias
Id_Identificacion del tipo de CHAR 2 Obligatorio FK
identificación
Id_Cargo NUMBER 3 Obligatorio FK
del Cargo
Nombre del VARCHAR
Nombres 30 Obligatorio N/A
Funcionario 2
Apellidos del VARCHAR
Apellidos 30 Obligatorio N/A
Funcionario 2
Número de
Num_Identificaci
identificación del NUMBER 10 Obligatorio N/A
on
funcionario
Género del
Genero CHAR 1 Obligatorio N/A
funcionario
Tabla 7
Descripción Tipo Transacción
TIPO_TRANSACCION
Tipo
Tipo de Longitu Obligatorio u
Nombre Descripción de
Dato d Opcional
Llave
Id_TipoTransaccio NUMBE
Código identificador 3 Obligatorio PK
n R
Tipo de transacción
Nombre_Transacci VARCH
(Préstamo, 30 Obligatorio N/A
on AR2
Devolución, etc.)
Tabla 8
Tabla Transacciones
TRANSACCIONES
Tipo
Tipo de Obligatorio u
Nombre Descripción Longitud de
Dato Opcional
Llave
Código
Id_Transaccion NUMBER 10 Obligatorio PK
identificador
Código
Id_Funcionarios Identificador del NUMBER 3 Obligatorio FK
funcionario
Código
Id_TipoTransaccion identificador del NUMBER 3 Obligatorio FK
tipo de transacción
Fecha en que se
Fecha realiza la DATE N/A Obligatorio N/A
transacción
Tabla 9
Descripción Tipo Elemento
TIPO_ELEMENTO
Obligatorio Tipo
Tipo de
Nombre Descripción Longitud u de
Dato
Opcional Llave
Id_TipoElemento Código identificador NUMBER 2 Obligatorio PK
Descripción del tipo
Descripción de elemento VARCHAR2 100 Obligatorio N/A
devolutivo
Tabla 10
Descripción Elementos Devolutivos
ELEMENTOS_DEVOLUTIVOS
Obligatorio
Tipo de Tipo de
Dato Llave
Opcional
Id_Elemento Código identificador NUMBER 3 Obligatorio PK
Id_TipoElemento del tipo de elemento NUMBER 2 Obligatorio FK
devolutivo
Nombre del elemento VARCHAR
Nombre 30 Obligatorio N/A
devolutivo 2
Año en el que se
Año_Adquisicion NUMBER 4 Obligatorio N/A
adquirió el elemento
Costo del elemento al
Valor_Adquisicio
momento de su NUMBER 10 Obligatorio N/A
n
adquisición
Estado del elemento
Estado_Disponibili VARCHAR
(Disponible, No 10 Obligatorio N/A
dad 2
Disponible)
Tabla 11
Descripción Detalle Transacción
DETALLE_TRANSACCION
Obligatorio Tipo
Tipo de Longitu
Nombre Descripción u de
Dato d
Opcional Llave
Código identificador de la NUMBE PK -
Id_Transaccion 10 Obligatorio
transacción R FK
NUMBE
Id_Detalle Código identificador 10 Obligatorio PK
R
Código identificador de la
Det_ID_Transacc transacción con la que se NUMBE
10 Opcional FK
ion realiza la devolución del R
elemento
Código identificador del
NUMBE
Det_Id_Detalle detalle en el que se realiza 10 Opcional FK
R
la devolución del elemento
Código identificador del NUMBE
Id_Elemento 3 Obligatorio FK
elemento devolutivo R
NUMBE
Cant Cantidad de elementos 1 Obligatorio N/A
R
4.2. ARQUITECTURA MODULAR
Descomposición Modular o Modularización es el proceso de descomposición del diseño físico
de un sistema en un conjunto de elementos con un índice bajo de acoplamiento (independientes) y
alto índice de cohesión (con significado propio).
Consiste en descomponer el problema a resolver en módulos o tareas más simples. Cada tarea
representa una actividad completa y se codifica de manera independiente. Facilita el diseño
descendente del problema, centrándonos cada vez en la resolución de subproblemas de magnitud

inferior. A la resolución de cada uno de estos subproblemas de complejidad inferior se denomina
refinamiento por pasos. Los módulos pueden ser planificados, codificados, comprobados y
depurados independientemente, y luego se combinan uno a uno con otros módulos.
El diseño modular propone dividir el sistema en partes diferenciadas y definir sus interfaces.
(ittgweb, 2016)
 Diagrama de Jerarquía de Módulos
El objetivo de este diagrama es representar la estructura modular del sistema o de un
componente del mismo y definir los parámetros de entrada y salida de cada uno de los módulos.
La jerarquía entre los módulos se emplea de forma que los módulos de niveles superiores
coordinen a los de niveles inferiores. Al dividir los módulos jerárquicamente, es posible controlar
el número de módulos que interactúan con cualquiera de los otros. (Cillero, s.f.)
Ilustración 3
Diagrama de Módulo Eliminación

Ilustración 4
Diagrama de Módulo Inserción y Actualización

Ilustración 5
Diagrama de Módulo Consulta

 Descripción de Módulos
Teniendo en cuenta que un módulo es la división del software clara y manejable con
interfaces modulares perfectamente definidas y que puede representar un programa, subprograma
o rutina dependiendo del lenguaje a utilizar, y que además admite parámetros de llamada y
retorno. (Cillero, s.f.)
A continuación se realiza la descripción de los módulos creados en los diagramas de
jerarquía del punto anterior.
Tabla 12 Descripción
Diagrama Modular de Eliminación
ARQUITECTURA DE ELIMINACIÓN A LA TABLA FUNCIONARIOS
NOMBRE FUNCIÓN
Representa la parte pública, visible y accesible desde
Capa de Presentación afuera del mismo paquete, es la interfaz de interacción
entre el usuario y el sistema.
Este módulo realiza las validaciones controles y
Controlador, validador, y
verificación necesarios para concretar la eliminación del
verificador de la eliminación
registro correctamente.
Realiza la eliminación del registro seleccionado por el
Eliminar Funcionario
usuario.
Verifica que el registro seleccionado por el usuario exista y
Validar eliminación
se elimine correctamente.
Muestra en la consola los registros que existen en la tabla
Desplegar tabla funcionarios
una vez hecha la eliminación.
Diagrama Modular Inserción y Actualización
ARQUITECTURA DE INSERCIÓN Y ACTUALIZACIÓN
TABLA DETALLE_TRANSACCION
NOMBRE FUNCIÓN
Controlador, validador, y Este módulo realiza las validaciones controles y
verificador de la inserción y verificación necesarios para concretar la inserción y
actualización actualización del registro.
Comprueba que el elemento devolutivo seleccionado
Verificar elemento devolutivo
exista.
Verificar transacción Comprueba que la transacción seleccionada exista.
Realiza la inserción del detalle de la transacción
Insertar detalle de transacción
seleccionada.
Si el elemento y el detalle seleccionados corresponden a un
Actualizar detalle transacción detalle anterior toma la inserción como una devolución por
tanto actualiza el registro de préstamo.
Despliega un mensaje para comprobar si se realizó o no
Desplegar Mensaje
correctamente el proceso.
Diagrama Modular Consulta
ARQUITECTURA DE CONSULTA A LA TRANSACCIÓN CON SU DETALLE

NOMBRE FUNCIÓN
Este módulo realiza las validaciones controles y
Controlador, validador, y
verificación necesarios para concretar la consulta a los
verificador de la consulta
registros.
Verificar transacción Comprueba que la transacción seleccionada exista.
Verificar detalle transacción Comprueba que el detalle transacción seleccionado exista.
Consultar transacción Realiza la consulta al registro ingresado por el usuario.
Realiza la consulta a la transacción ingresada por el
Consultar detalle transacción
usuario.
Desplegar transacción con su Muestra en la consola una tabla con la transacción y su
detalle de transacción detalle correspondiente.
5. CONSTRUCCIÓN
En la fase de construcción se empieza a analizar todo lo obtenido y realizado en la fase de
diseño para efectuar la implementación de la base de datos, se inicia con la generación del Script
el cual se obtuvo a partir del diagrama relacional físico y por medio de la herramienta Power
Designer.
Una vez conseguido el script se procede a crear la base de datos, para esto se empleó la
herramienta SQL Developer y la consola de Oracle XE. Lograda la creación de la BD se realizó
la población y se obtuvo un nuevo Script el cual contiene la base de datos pero con la inserción
de datos a las tablas.
Adicional a lo anterior también se logró la generación de la arquitectura modular y la
creación de las consultas CRUD (Create, Read, Update & Delete) en base a estos modelos. La
descripción precisa de cada uno de los productos obtenidos a partir de esta fase se puede
evidenciar en la sección de anexos en la cual se exponen con más detalle a fin de obtener la
compresión del lector.
5.1.PRUEBAS
A continuación se muestran una serie de capturas correspondientes a las pruebas realizadas a los
procedimientos creados en el módulo de elementos devolutivos.
 Inserción
En las imágenes se muestra el resultado del proceso de inserción a la tabla funcionarios, para
ello se realizó la captura de datos por consola una vez ingresados el programa ejecuta una serie
de validaciones las cuales al ser superadas permiten la inserción del nuevo registro. Una vez
registrado nos muestra en la consola una pequeña tabla con los datos del funcionario ingresado.
Ilustración 6
Pruebas de Inserción de un Registro
 Actualización
En las imágenes se muestra el resultado del proceso de actualización de un registro de la
tabla funcionarios, para ello se realizó la captura de datos a actualizar por consola una vez
ingresados el programa ejecuta una serie de validaciones las cuales al ser superadas permiten la
actualización del registro. Una vez actualizado genera un mensaje que constata la actualización
del registro.
Ilustración 7
Actualización de un Registro
 Eliminación
En las imágenes se muestra el resultado del proceso de eliminación de un registro de la tabla
funcionarios, para ello se realizó la captura del código del funcionario a eliminar por medio de la
consola una vez ingresado el programa ejecuta una serie de validaciones las cuales al ser
superadas permiten la eliminación del registro. Una vez eliminado el registro el programa genera
una consulta a la tabla y nos muestra todos sus valores actuales.
Ilustración 8
Eliminación de un Registro
 Consultas
 A un registro
La siguiente imagen muestra el resultado de una consulta a la tabla transacciones, se solicita
el id de la transacción por medio de la consola y el programa arroja el dato perteneciente al tipo

de transacción, lo organiza en una tabla y lo muestra.
Ilustración 9
Consulta a Un Registro
 A varios registros
La siguiente imagen muestra el resultado de una consulta a las tablas transacciones y
detalle_transaccion, se solicita el id de la transacción por medio de la consola y el programa trae
los datos pertenecientes a ese id en la tabla transacciones y en la tabla detalle_transacciones, los
organiza en una tabla y los muestra.
Ilustración 10
Consulta a Varios Registros

6. CONCLUSIONES
 Se llevó a cabo la implementación de las capas de almacenamiento de datos y lógica de
un aplicativo con soporte a los procesos del subsistema de información para el control de
elementos devolutivos de un colegio de secundaria.
 Se desarrollaron los procedimientos para el módulo de inserción y actualización de la
tabla de detalle_transaccion que es validado por medio de las tablas de transacción, y
elementos_devolutivos.
 Se realizaron los procedimientos para el módulo de consultas referente a las transacciones
y su respectivo detalle_transaccion y sus relaciones con las tablas tipo_transaccion
funcionarios, y elementos_devolutivos.
 Se desarrollaron los procedimientos para el módulo de consultas sumarias relacionadas
con el costo de adquisición de los elementos_devolutivos, separados por tipo_elemento y
se obtiene el cálculo del IVA que se pagó por dichos elementos.
 Se desarrollaron los procedimientos para el cambio de la disponibilidad de los elementos
devolutivos en caso de que sean prestados o devueltos en un detalle transacción.
 Se desarrollaron los procedimientos de auditoría para la tabla de detalle_transaccion (
log), los cuales involucran la creación de una tabla para controlar el historial de
movimientos a la tabla detalle_transaccion

7. REFERENCIAS
 J.M. Pacheco - Casadiego, 2016 "Modelado de requerimientos de software.",
(Documento de docencia N° 18), Bogotá, Ediciones Universidad Cooperativa de
Colombia.
 J.M. Pacheco - Casadiego, 2017 "Metodologia para elaborar el modelo conceptual de
datos", (Documento de docencia N° 37), Bogotá, Ediciones Universidad Cooperativa de
Colombia.
 Tecnologías-información, s.f., “Modelos de datos: Modelo Conceptual, Físico y Lógico”,
https://www.tecnologias-informacion.com/modelos-datos.html
 Editorial, 2013 “Modelo físico de datos (Modelo relacional)”, tareas universitarias,
https://tareasuniversitarias.com/modelo-fisico-de-datos-modelo-relacional.html
 Ittgweb, 2016, “Descomposición modular”, ingeniería de software, https://ittgweb.
wordpress.com/2016/05/29/descomposicion-modular/
 Manuel Cillero, s.f., “Diagrama de Estructura”, https://manuel.cillero.es/doc/metrica-
3/tecnicas/diagrama-de-estructura/
8. ANEXOS
8.1. CAPA DE ALMACENAMIENTO
 Script de la Base de Datos
La imagen a continuación muestra una parte del script generado a partir del modelo físico
relacional en el cual se realiza la creación de las tablas con sus respectivas relaciones, para ver el
script completo diríjase a la carpeta de diseño y posteriormente abra el archivo denominado
Script.sql:
Ilustración 11
Script SQL de la BD
8.2. CAPA LÓGICA
 Procedimientos
 Edición (Creación, actualización y eliminación de un registro de una tabla)
La imagen a continuación muestra la ejecución del proceso de inserción a una tabla de la
base de datos para ver los procesos completos de Creación, Actualización y Eliminación,
diríjase a la carpeta de construcción y posteriormente abra la carpeta Inserción, Actualización y
Eliminación, allí se encuentran todos los procesos debidamente organizados:
Ilustración 12
Creación Edición y Eliminación de un Registro
 Consultas
La imagen a continuación muestra la ejecución de una consulta a un registro de la tabla
transacciones de la base de datos para ver los procesos completos que generan la consulta,
diríjase a la carpeta de construcción y posteriormente abra la carpeta Consultas, allí se
encuentran todos los procesos debidamente organizados:
Ilustración 13
Consulta a Un Registro Tabla Transacciones

La imagen a continuación muestra la ejecución de una consulta a varios registros de las tablas
de la base de datos para ver los procesos completos que generan la consulta, diríjase a la carpeta
de construcción y posteriormente abra la carpeta Consultas, allí se encuentran todos los procesos
debidamente organizados:
Ilustración 14
Consulta a Varios Registros de la Tabla Transacciones
 Consultas Sumarias
La imagen a continuación muestra el resultado de una consulta sumaría a las tablas
elementos devolutivos y tipo de elemento de las cuales se extrajo el nombre del tipo de elemento
y se sumó la cantidad de elementos devolutivos que pertenecen a este, al igual que su valor de
adquisición y al final muestra una columna extra con el valor del IVA para ver los procesos
completos que generan la consulta, diríjase a la carpeta de construcción y posteriormente abra la
carpeta Consultas, allí se encuentran todos los procesos debidamente organizados:
Ilustración 15
Consulta Sumaria
 Transacciones
La imagen a continuación muestra el llamado a los procesos para ejecutar una transacción a
la tabla detalle transacción lo que el proceso realiza es la inserción de un nuevo registro y si el
registro es una devolución automáticamente actualiza el registro correspondiente al préstamo de
lo contrario simplemente inserta el nuevo registro; para ver los procesos completos que generan
la transacción, diríjase a la carpeta de construcción y posteriormente abra la carpeta
Transacciones, allí se encuentran todos los procesos debidamente organizados:
Ilustración 16
Procedimiento de Transacción
 Auditoría
La imagen a continuación muestra la ejecución de un trigger o disparador a la tabla
log_detalle_transaccion con el fin de registrar todos las acciones que se realicen a la tabla
detalle_transaccion ya sean inserciones, actualizaciones o eliminación de los registros y captura
la fecha exacta y el usuario que realiza la alteración; para ver los procesos completos que
generan la transacción, diríjase a la carpeta de construcción y posteriormente abra la carpeta
Auditoria, allí se encuentran todos los procesos debidamente organizados:
Ilustración 17
Procedimiento de Auditoría

Documento Subsistema Control Elementos Devolutivos

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Documento Subsistema Control Elementos Devolutivos

Transféré par

Droits d'auteur :

Formats disponibles

SUBSISTEMA CONTROL DE ELEMENTOS DEVOLUTIVOS

LUZ MARY BUITRAGO GÓMEZ (CÓDIGO. 084950442017)

UNIVERSIDAD DEL TOLIMA

En la actualidad el respaldo, cuidado y administración de la información es vital para cualquier

de manera segura la información de las organizaciones.

A continuación se describe el diseño e implementación de un modelo de datos y lógico para el

módulo o subsistema elementos devolutivos de un sistema de información perteneciente a un

procedimientos realizados en el subsistema los cuales fueron codificados en lenguaje PL/SQL e

implementados en el motor de base de datos SQL Developer y permiten insertar, actualizar,

eliminar, consultar y auditar la transacciones realizadas en el módulo.

procesos del subsistema de información para el control de elementos devolutivos de un

 Desarrollar los procedimientos para el módulo de inserción y actualización de la tabla de

detalle_transaccion que será validado por medio de las tablas de transacción, y

 Realizar los procedimientos para el módulo de consultas referente a las transacciones y su

respectivo detalle_transaccion y sus relaciones con las tablas tipo_transaccion

 Desarrollar los procedimientos para el módulo de consultas sumarias relacionadas con el

costo de adquisición de los elementos_devolutivos, separados por tipo_elemento y

obtener el cálculo del IVA que se pagó por dichos elementos.

 Desarrollar los procedimientos para el cambio de la disponibilidad de los elementos

devolutivos en caso de que sean prestados o devueltos en un detalle transacción.

 Desarrollar los procedimientos de auditoría para la tabla de detalle_transaccion ( log)

la generación del subsitema.

2.1. Fase Análisis de requisitos

fue un catalogo de requerimientos funcionales expresados en párrafos de procesos asincrónicos.

 Elaboración Modelo Conceptual de Datos

las entidades en tablas, las instancias en filas y los atributos en columnas.

procedimientos al momento de ejecutarse, desde la capa de presentación hasta la capa de datos

procedimientos para los cuales se empleó un enfoque estructurado, no orientado objetos, la

tecnología utilizada fue lenguaje de programación PL/Sql .

 Generación del script

Power Designer y se implementa en el entorno de desarrollo SQL Developer con un lenguaje de

programación Oracle PL/Sql.

 Cargue del script al motor Oracle utilizando SQL Developer.

usuario creado y se importa el Script sql generado prevamente.

desarrollo integral SQL Developer mediante el lenguaje PL-SQL que es un lenguaje de

inserción de datos es INSERT INTO "nombre_tabla" ("columna1", "columna2”) VALUES

 Construcción, compilación y pruebas de los módulos CRUD, los módulos de

Se realizó la programación de los procedimientos para la inserción, edición, eliminación y

consulta al subsistema en el lenguaje PL/Sql directamente en el entorno Sql Developer,

que se ejecutaran correctamente y que en efecto cumplieran con lo requerido.

El análisis, diseño, construcción y prueba de las capas de almacenamiento y lógica de un

subsistema de control de elementos devolutivos de un colegio.

además de generar un historial de los procesos realizados.

3.2. REQUERIMIENTOS FUNCIONALES

Para la determinación de los requerimientos funcionales del subsistema de control de

elementos devolutivos, se requiere complementar el modelo conceptual de la base de datos del

sistema del colegio con la implementación de un diseño para el subsistema de control de

elementos devolutivos los requerimientos son los siguientes:

nombre, apellido, tipo de documento, número de documento, género, municipio de nacimiento,

cargo y dependencia a la que pertenece.

REGISTRO DE ELEMENTOS DEVOLUTIVOS

adquisición, tipo de devolutivo (equipo de oficina, mueble de oficina, computador, equipo

audiovisual, etc.), estado de disponibilidad (disponible, prestado).

REGITRO DE PRÉSTAMOS Y DETALLES

elaborar un comprobante de préstamo y registrar en su cabecera el número del préstamo, fecha

En el detalle del préstamo se registra un ítem de detalle, el identificador del elemento

detalle del préstamo (PA= pendiente de aplicar, AP= aplicado)

REGISTRO DE DEVOLUCIÓN Y DETALLES

se debe elaborar un comprobante de devolución y registrar en su cabecera el número de

devolución, fecha de la devolución, tipo de documento y número de documento del funcionario

que devuelve el elemento.

En el detalle de la devolución se registra un ítem de detalle, el identificador del elemento que

se devuelve y el estado de aplicación del detalle de la devolución (PA= pendiente de aplicar,