1.- introducciÓnnúmeros enteros, números reales con distinta precisión, caracteres, etc., pero...

Tutorial gráfico de estructuras de datos dinámicas

1

1.- INTRODUCCIÓN

1.1.- RESUMEN DE LA APLICACIÓN

La finalidad de este tutorial es que sirva como herramienta visual de apoyo a

estudiantes que están empezando a manejar estructuras de datos dinámicas, para

asentar los conocimientos en la asignatura de estructuras de datos.

Los objetivos fundamentales de este tutorial son:

1. Aprendizaje de los conceptos fundamentales de las estructuras de datos

dinámicas, empezando desde un nivel bajo y, a medida que avanza el tutorial,

se incrementará la complejidad hasta un grado medio.

2. Aprendizaje de las operaciones básicas que se pueden realizar sobre una

estructura, como son las inserciones, eliminaciones y recorridos.

3. Implementación de esas operaciones, para ello en la aplicación aparecerá

para cada una de las estructuras el pseudocódigo de las operaciones

anteriormente mencionadas.

4. Conocimiento en todo momento de la variación de la estructura a medida que

el usuario va realizando las operaciones sobre la misma. Se mostrará durante

toda la ejecución de cada operación la estructura de datos y se podrán

apreciar los cambios que se van produciendo.

5. Valoración por parte del usuario de la importancia de las estructuras de datos

dinámicas como base al desarrollo y tratamiento de la información, así como

su importancia en la etapa de programación de cualquier aplicación.


2

La aplicación está dirigida a usuarios que están empezando a estudiar las

estructuras de datos dinámicas y quieren asentar una base sólida con respecto a

este tema, haciendo uso de la aplicación, para que de una forma visual comprendan

el uso de las estructuras de datos dinámicas.

El tutorial se realizará en su totalidad bajo un entorno visual, para lo cual se

programará en lenguaje Visual Basic, un lenguaje orientado a eventos, utilizando el

paquete de aplicaciones que proporciona Microsoft Visual Studio 6.0.


3

1.2.- INTRODUCCIÓN A LAS ESTRUCTURAS DE DATOS

1.2.1.- IMPORTANCIA DE LAS ESTRUCTURAS DE DATOS

Para procesar la información en un ordenador, es necesario hacer una abstracción

de los datos que se toman, abstracción en el sentido de que se ignoran algunas

propiedades de los objetos reales, es decir, se simplifican. Se hace una selección de

los datos más representativos a partir de los cuales, el ordenador pueda trabajar

para obtener unos resultados más o menos esperados.

Cualquier lenguaje suministra una serie de tipos de datos simples, como son los

números enteros, números reales con distinta precisión, caracteres, etc., pero en

realidad suministra un subconjunto de éstos, pues la memoria del ordenador es finita.

Los punteros, si los soporta el lenguaje, son también un tipo de datos. El tamaño de

todos los tipos de datos depende de la máquina y del compilador sobre los que se

trabaja.

En principio, conocer la representación interna de estos tipos de datos no es

necesaria para realizar un programa, pero sí puede afectar en algunos casos al

rendimiento de este.

En el día de hoy la utilización de las estructuras de datos es muy importante, ya que

facilitan el almacenamiento, acceso, tratamiento y manteniendo de la información de

una manera sencilla y sobre todo eficiente.


4

Multitud de aplicaciones utilizan las estructuras de datos para el tratamiento de la

información. Su uso está presente en múltiples y diversos campos de la informática,

como pueden ser los sistemas operativos, que por ejemplo en la gestión de

asignación de los recursos a un proceso lo hace por medio de listas enlazadas o en

la gestión de acceso al procesador en un sistema monoprocesador, que lo realiza

colocando los procesos preparados en una serie de colas dependiendo de su

estado.

Diversas y potentes aplicaciones utilizan algoritmos de búsqueda que se realizan

sobre árboles binarios, ya sean búsquedas en preorden, inorden o postorden. Este

tipo de búsquedas son muy eficientes y ahorran mucho tiempo cuando se trata de

buscar un dato determinado.

Java es un lenguaje de programación destinado a objetos y utiliza para eliminarlos

en tiempo de ejecución una subrutina, invocada periódicamente sin la intervención

del programador, llamada Garbage Collector. Esta subrutina recorre la lista de

espacios reservados en memoria, observando el contador de referencias de cada

espacio. Si un contador ha llegado a cero significa que ese espacio de memoria ya

no se usa y, por lo tanto, puede ser liberado. Para llevar a cabo esta gestión de la

memoria, el Recolector de Basura o Garbage Collector utiliza diferentes estructuras

de datos dependiendo del proveedor de la máquina virtual y de la versión. Además

de Java una gran lista de lenguajes utilizan esta subrutina, como por ejemplo C#,

PHP, Visual Basic, Tcl, etc.


5

En la gestión de los directorios de ficheros de varios niveles, el sistema operativo

UNIX trabaja con ellos por medio de una estructura en árbol de varios niveles. De

esta forma la organización es óptima y la búsqueda será sencilla y rápida.

Es por eso por lo que las estructuras de datos tienen su importancia hoy en día,

porque son la base de un enorme número de aplicaciones, para poder tratar la

información que manejan de una forma sencilla y eficaz, abarcando desde las más

complejas, como puede ser la gestión de los recursos que asigna un sistema

operativo a un proceso hasta la más simple de las aplicaciones.


6

1.2.2.- DEFINICIÓN DE ESTRUCTURAS DE DATOS

Una estructura de datos es un conjunto de variables de un determinado tipo

agrupadas y organizadas de alguna manera para representar un comportamiento. Lo

que se pretende con las estructuras de datos es facilitar un esquema lógico para

manipular los datos en función del problema que haya que tratar.

En algunos casos la dificultad para resolver un problema radica en escoger la

estructura de datos adecuada. En general, la elección del algoritmo y de las

estructuras de datos que se manipularán estarán muy relacionadas. El utilizar una

estructura de datos u otra, mejorará o empeorará el rendimiento de la aplicación.

Las dos características más importantes que definen a las estructuras de datos son

las siguientes:

§ Se pueden descomponer en los elementos que la forman.

§ La manera en la que se colocan los elementos dentro de la estructura de

datos afectará a la forma en que se realicen las operaciones sobre ella.


7

Según su comportamiento durante el tiempo de ejecución del programa se pueden

distinguir dos tipos estructuras de datos:

§ Estáticas: El tamaño de la estructura de datos se define en tiempo de

compilación, es decir, el programador tiene que definir el tamaño en el código

de la aplicación. Esto tiene el inconveniente de que cuando se llega al límite

del tamaño de la estructura, no se pueden insertar más elementos a no ser de

que se elimine alguno. Otro inconveniente añadido es que se puede dar el

caso, que durante la ejecución no se utilice toda la estructura de datos, lo que

conlleva a un desaprovechamiento de la memoria asignada. Tiene la ventaja

de que como el tamaño de la memoria reservada no varía durante la ejecución

del programa, la aplicación no tiene que llamar al sistema operativo para

solicitar más memoria, y por lo tanto no se produce ninguna interrupción, por

lo que el tiempo de ejecución es menor y el rendimiento del programa mayor.

§ Dinámicas: El tamaño de la estructura de datos se define en tiempo de

ejecución, es decir a medida que se insertan elementos se solicita al sistema

operativo más memoria. Tiene la ventaja de que el límite de la estructura de

datos es mayor y además el aprovechamiento de la memoria es más óptimo

que la asignación de memoria estática, ya que es muy difícil que quede

memoria sin direccionar dentro de la estructura de datos. Tiene la desventaja

de que cuando solicita más memoria, es el sistema operativo quien intercede

para asignársela, esto implica una interrupción y por lo tanto el rendimiento de

la aplicación es menor.


8

Otra clasificación que se puede hacer en las estructuras de datos, ya sean estáticas

o dinámicas, es dependiendo de su estructura, es decir de la organización de los

elementos dentro de la misma. Así, se pueden distinguir dos tipos:

§ Lineal: Cada elemento de la estructura de datos tiene al siguiente y al anterior,

es decir, están colocados uno detrás de otro. Un ejemplo de este tipo de

organización son las tablas.

Como se puede observar en la figura, el elemento 5, por ejemplo, tiene como

siguiente al 2 y como anterior al 3.

§ No lineal: Aquellas estructuras en las que no está claro cual es el siguiente

elemento. Un ejemplo de este tipo de organización son los árboles binarios.

Como se puede apreciar en la figura, el elemento siguiente al 7, por ejemplo,

puede ser el 3 o el 9, dependiendo si se recorre el árbol por la derecha o por

la izquierda y el siguiente al 3 podría ser el 9 o el 1, dependiendo si se recorre

el árbol en anchura o en profundidad.

3 5 2 8 … 4

7

3 9

1 5 4 6


9

1.2.3.- TIPOS DE ESTRUCTURAS DE DATOS

A continuación, se definirán y explicarán las características y operaciones de cada

una de las estructuras de datos que se estudiarán durante la realización del

proyecto.

1.2.3.1.- LISTAS ENLAZADAS SIMPLES

Es una estructura de datos lineal en la que los elementos se relacionan entre sí

mediante un campo puntero que indica la posición del siguiente elemento de la lista

enlazada.

La visión lógica de una lista enlazada simple podría ser la siguiente:

Donde:

§ COMIENZO es el campo tipo puntero que contiene la dirección del primer

nodo de la lista enlazada.

§ NODO es el componente del conjunto lineal de la estructura de datos y consta

de dos partes, la información y el puntero.

§ INFORMACIÓN es la parte del nodo que contiene la información que se va a

utilizar en la aplicación.

COMIENZO

C1 C2 … C1 C2 …

C1 C2 … C1 C2 …

NODO INFORMACIÓN

PUNTERO


10

§ PUNTERO es la parte del nodo que contiene la dirección del siguiente nodo

de la lista enlazada.

§ significa valor nulo (NULL) o el final de la lista enlazada.

Las operaciones que se realizan con la memoria al trabajar con listas enlazadas son:

1. Se define una estructura con los campos necesarios para almacenar la

información a utilizar por la aplicación. En tiempo de compilación no se define

espacio en memoria para estos datos.

Estructura Nodo

Campo1 es tipo_de_dato

Campo2 es tipo_de_dato

Siguiente es puntero a Nodo

Fin Estructura

2. En tiempo de compilación, se define una variable puntero que indicará el

comienzo de la lista enlazada.

Comienzo es puntero a Nodo

3. En tiempo de ejecución se solicita o se libera memoria a medida que se

añaden o eliminan elementos a la lista enlazada

Puntero=Pedir_memoria(Nodo)

Liberar_memoria(Puntero)

Campo1 Campo2 ... Siguiente

Campo1 Campo2 ... Siguiente Comienzo


11

Las operaciones que se estudiarán a continuación y que se pueden realizar sobre las

listas enlazadas son las inserciones, recorridos y eliminaciones.

INSERCIONES

Esta operación añade un nuevo nodo a la lista enlazada. Se solicita memoria para

los nodos a medida que se añaden los datos. Las inserciones que se puede realizar

en una lista enlazada son:

§ Inserciones en una lista enlazada vacía.

§ Inserciones al comienzo de la lista enlazada.

§ Inserciones entre dos nodos de la lista enlazada

§ Al final de la lista enlazada.

RECORRIDOS

Esta operación recorre todos y cada uno de los nodos de la lista enlazada, aplicando

un proceso en cada unos de ellos, como pude ser listar, acumular, contar, etc. Esta

operación se realizará hasta que llegue al final de la lista enlazada, es decir, hasta

que el campo puntero de un nodo, siguiente, sea igual a NULL.

A esta operación se le pueden añadir sentencias condicionales para realizar las

búsquedas de los nodos deseados.


12

ELIMINACIONES

Esta operación elimina un nodo existente de la lista enlazada. Se tiene que buscar la

dirección del nodo a eliminar y la dirección del anterior para así poder intercambiar

los punteros una vez eliminado el nodo deseado. Para realizar esta operación, antes

hay que realizar un recorrido de la lista enlazada para encontrar el nodo a eliminar,

utilizando dos punteros uno para apuntar al nodo a eliminar, puntero1, y otro para

apuntar el nodo anterior, puntero2. Dependiendo de los valores de ambos punteros

la eliminación resultante obtendrá distintos resultados. Los posibles resultados de

este recorrido pueden ser:

Una vez encontrado el nodo que se desea eliminar e intercambiado los punteros, se

realiza la operación de liberar memoria.

Puntero1 Puntero2 Resultado

NULL NULL La lista enlazada está vacía

Distinto de NULL NULL Eliminar el primer nodo

Distinto de NULL Distinto de NULL Eliminar un nodo intermedio o último

NULL Distinto de NULL El nodo a eliminar no existe


13

1.2.3.2.- LISTAS DOBLEMENTE ENLAZADAS

Es un caso particular de las listas enlazadas simples, en el que se añade al nodo un

puntero de más, que apunta al nodo anterior, pero conservando las mismas

características de una lista enlazada simple.

La visión lógica de una lista doblemente enlazada podría ser la siguiente:

Como se puede apreciar en el dibujo anterior, el puntero1 apunta al nodo anterior de

la lista enlazada y el puntero2 apunta a nodo siguiente.

Las operaciones que se pueden realizar sobre las listas doblemente enlazadas son

las misma que las se pueden realizar sobre las listas enlazadas simple y que se

estudiaron en el apartado anterior, con la salvedad de que ahora al realizar

inserciones y eliminaciones hay que hacer un doble intercambio de punteros, el que

apunta al nodo anterior y el que apunta al nodo siguiente.

COMIENZO

INFORMACIÓN

PUNTERO1 PUNTERO2 NODO

FINAL


14

1.2.3.3.- PILAS

Es una estructura de datos lineal en la que se pueden insertar elementos o

eliminarlos únicamente por un extremo llamado cima. Esto exigirá que la

manipulación sobre un elemento, necesariamente ocupe la posición de cima.

También son conocidas como listas LIFO (Last-In, First-Out).

La visión lógica de una pila podría ser la siguiente:

Donde:

§ CIMA es el campo que contiene la dirección del primer nodo de la pila.







§ valor nulo (NULL) o el final de la lista enlazada.

CIMA NODO

C1 C2

INFORMACIÓN

PUNTERO

C3

INSERCIÓN ELIMINACIÓN


15

Como se puede apreciar en la visión lógica de la pila, este tipo de estructura de

datos es la misma que una lista enlazada, con la salvedad de que los nodos siempre

se insertan o eliminan por el final de la pila.


pilas son las inserciones y eliminaciones.

INSERCIONES

Esta operación añade un nuevo nodo por el final, lógicamente, a la pila. Esta

operación se puede considerar prácticamente idéntica a la operación de añadir un

nuevo nodo a una lista enlazada, ya sea simple o doblemente enlazada, por el final.

Para realizarla se tiene primero que solicitar la memoria disponible para insertar el

nuevo nodo, intercambiar los punteros del elemento anterior con el que se va a

añadir y guardar la nueva dirección de la variable cima, que indica el final de la pila o

la dirección del primer nodo de la misma.

ELIMINACIONES

Esta operación elimina un nodo existente de la pila, no es necesario buscar el nodo a

eliminar, ya que siempre se elimina el último. Es la misma operación que la de

eliminar el primer nodo de una lista enlazada.

Es conveniente aclarar que en este tipo de estructuras de datos no tiene sentido

realizar la operación de recorrer la pila, ya que los elementos se introducen y se

eliminan por un orden establecido.


16

1.2.3.4.- COLAS

Es una estructura de datos lineal en la que se pueden insertar elementos únicamente

por un extremo llamado final y pueden eliminarse por el otro extremo llamado frente.

Esto exigirá que la manipulación sobre un elemento, necesite estar en uno de los

dos extremos, para ser insertado o eliminado. Este tipo de estructura también es

conocida como listas FIFO (First-In, First-Out).

Este tipo de estructura de datos, se puede considerar como una lista doblemente

enlazada o como una lista unidireccional.

La visión lógica de una pila podría ser la siguiente:

Donde:

§ FRENTE es el campo que contiene la dirección del primer nodo de la cola.





INSERCIÓN ELIMINACIÓN

FINAL FRENTE

FRENTE NODO

C1 C2

INFORMACIÓN

PUNTERO

C3


17



§ valor nulo (NULL) o el final de la lista enlazada.

Como se puede apreciar en la visión lógica de la cola, es tipo de estructura de datos

es la misma que una lista enlazada, con la salvedad de que los nodos siempre se

insertan por el final de la cola y se eliminan por el principio.


pilas son las inserciones y eliminaciones.

INSERCIONES

Esta operación añade un nuevo nodo por el final, lógicamente, de la cola. La

operación se puede considerar prácticamente idéntica a la operación de añadir un

nuevo nodo a una lista enlazada por el final. Para realizarla primero se tiene que

recorrer la cola hasta que el campo puntero de un nodo sea NULL, que indica el final

de la cola, solicitar la memoria disponible para insertar el nuevo nodo, e intercambiar

los punteros del elemento anterior con el que se va a añadir, poniendo el valor NULL

en el campo puntero del nodo añadido, que indica el final de la cola.


18

ELIMINACIONES

Esta operación elimina un nodo existente de la cola, no es necesario buscar el nodo

a eliminar, ya que siempre se elimina el primero. Es la misma operación que la de

eliminar el primer nodo de una lista enlazada, realizando el intercambio de punteros

del nodo que se va a eliminar con el comienzo de la cola y liberando después la

memoria utilizada por este nodo.

En este tipo de estructuras de datos no tiene sentido realizar la operación de recorrer

la cola, ya que los elementos se introducen y se eliminan por un orden establecido,

salvo en la operación de insertar un nodo, que hay que recorrer la cola hasta llegar al

final.


19

2.- IDENTIFICACIÓN DE NECESIDADES

En esta etapa se define el problema a resolver y se fijan las normas a seguir para el

desarrollo de la aplicación. En lo que respecta al desarrollo, se establecen los límites

del proyecto, así como los objetivos, restricciones y antecedentes del proyecto.

2.1.- OBJETIVOS DE LA APLICACIÓN

Desarrollar una aplicación gráfica para el aprendizaje de conceptos, implementación

y manipulación de estructuras de datos dinámicas en lenguaje de programación

Visual Basic. Las estructuras de datos a tratar serán listas, pilas, colas y árboles.

Dado que el carácter de la aplicación es didáctico, en ella aparecerán definiciones y

conceptos de las estructuras de datos dinámicas, implementaciones en

pseudocódigo de las diferentes operaciones que se pueden realizar, como son las

inserciones, eliminaciones y recorridos.

Una vez definidos los conceptos de la estructura de datos a estudiar y aparecido las

implementaciones de las operaciones, se presentará al usuario de forma visual la

estructura sobre la cual podrá realizar dichas operaciones y además, podrá observar

la variación de la estructura a medida que las realiza.

La funcionalidad de la aplicación es que sirva a estudiantes que están empezando a

manejar estructuras de datos dinámicas, en la asignatura de estructura de datos,

como herramienta visual de apoyo, que ayude a asentar los conocimientos, con los

objetivos de:


20

1. Facilitar el aprendizaje al usuario de los conceptos fundamentales de las

estructuras de datos dinámicas, empezando desde un nivel bajo y, a

medida que avanza el tutorial, se incrementará la complejidad hasta un

grado medio.

2. Facilitar el aprendizaje al usuario de las operaciones básicas que se

pueden realizar sobre una estructura, como son las inserciones,

eliminaciones y recorridos.

3. Implementar esas operaciones, para lo cual en la aplicación aparecerá



4. Conocer en todo momento de la variación de la estructura a medida que el

usuario va realizando las operaciones sobre la misma. Para ello, se

mostrará durante toda la ejecución la estructura de datos y se podrá


5. Valorar la importancia de las estructuras de datos dinámicas como base al

desarrollo y tratamiento de la información, así como de su importancia en

la etapa de programación de cualquier aplicación.


21

2.2.- ALCANCE DEL SISTEMA

Dada la multitud de estructuras de datos que existen en la actualidad, la aplicación a

desarrollar se centrará en las siguientes estructuras de datos: listas, pilas y colas,

aunque se pondrá en conocimiento del usuario la existencia de dicha multitud tanto

de estructuras de datos dinámicas como de operaciones que se pueden realizar

sobre ellas.

Dependiendo de la planificación del proyecto y de su seguimiento se añadirá un tipo

de estructura de datos más, los árboles, pero dependerá de la profundidad con la

que se desarrollen las estructuras de datos anteriores.

La ejecución de la aplicación por parte de los usuarios podrá ser en local, es decir,

instalando la aplicación y ejecutándola desde un ordenador personal o online,

ejecutándola desde un servidor de aplicaciones de la universidad o del centro de

estudios , que contenga todo el código necesario de la aplicación. Una vez solicitado

el servicio, se mostrará en la página Web de la zona personal del profesor o desde

un portal de recursos la ejecución de la aplicación.


22

2.3.- TIPOLOGÍA DE USUARIOS FINALES




el uso de las estructuras de datos dinámicas. La finalidad es que les sirva como una

herramienta para que entiendan y comprendan las características y operaciones de

cada estructura de datos que se está estudiando en ese momento.

Otro tipo de usuarios finales podrían ser profesores que imparten estos

conocimientos y que esta aplicación les sirva como material de apoyo didáctico a sus

explicaciones.

2.4.- RESTRICCIONES

No existen restricciones temporales, ni económicas ya que estas no son

considerables en el desarrollo de la aplicación. Sin embargo, dado que la

programación de la aplicación se realizará en lenguaje Visual Basic, para lograr una

correcta ejecución, ésta debería ser en un equipo que utilizará como sistema

operativo Microsoft Windows en cualquiera de sus versiones, ya que la migración de

aplicaciones realizadas en este lenguaje de programación a otros sistemas

operativos es prácticamente nula.


23

2.5.- ANTECEDENTES

Al no existir anteriormente ninguna aplicación de características parecidas a la

desarrollada, el principal problema que se planteaba anteriormente es la casi

imposibilidad de apreciar visualmente y de forma conceptual los cambios que se

producen en las estructuras de datos dinámicas al realizar operaciones sobre ella.

Este problema puede desencadenar otros problemas a la hora de estudiar las

operaciones que se realizan sobre las estructuras de datos, como pueden ser no

entender el pseudocódigo de las operaciones o no conocer la situación en la que se

encuentra la estructura de datos para realizar operaciones, como por ejemplo que

una lista enlazada se encuentre vacía y se desee eliminar un nodo.

La necesidad de escribir el pseudocódigo de cada operación y realizar la

representación gráfica de cada cambio que se producía en la estructura de datos es

otro problema que resuelve esta aplicación.

Los dos mayores problemas que resuelve la aplicación desarrollada son la

apreciación por parte del usuario de los cambios que se producen en la estructura de

datos y el ahorro de tiempo a la hora de escribir los pseudocódigos de las

operaciones y la representación gráfica de cada una de las estructuras de datos.


24

3.- DEFINICIÓN DEL PROBLEMA

A continuación se detallará el funcionamiento de la aplicación, ya sea en local u

online, según el tipo de acción del usuario.

EJECUCIÓN DE LA APLICACIÓN

El usuario podrá ejecutar la aplicación en local u online. Si la ejecución es online,

deberá introducir el usuario con la clave para solicitar al servidor de aplicaciones la

ejecución del tutorial gráfico de estructuras de datos dinámicas, el cual una vez

solicitado el servicio, ejecutará la aplicación y mostrará los resultados en la página

Web correspondiente.

ELECCIÓN DE LA ESTRUCTURA DE DATOS

El usuario podrá elegir mediante un menú, la estructura de datos que se va a

estudiar en ese momento, a elegir entre listas enlazadas simples, listas doblemente

enlazadas, pilas y colas. Una vez seleccionada la estructura de datos a estudiar, se

le presentarán dos situaciones:

1. Acceder a la parte de teórica de la aplicación. En esta parte se le presentarán

una introducción donde se le planteará la estructura de datos que va a

estudiar y, a continuación, podrá encontrar definiciones, conceptos,

operaciones y sus pseudocódigos, que podrán aprender y estudiar de manera

sencilla y eficaz. Toda esta parte tendrá un carácter teórico.


25

2. Acceder a la parte práctica de la aplicación. Una vez estudiado los conceptos

y operaciones de la estructura de datos, se le presentará en esta parte las

ejecuciones prácticas de las operaciones que se estudiaron en la parte

anterior. Podrá realizar las operaciones que desee, apreciando en cada

momento los cambios que se realizan en la estructura de datos, como pueden

ser los nodos, punteros etc. Durante la ejecución práctica el usuario podrá

acceder, mediante una opción, a la visualización del pseudocódigo de la

operación que se está estudiando, para que comprenda cómo se codifica, se

realiza la operación.


26

4.- ANÁLISIS DE REQUISITOS

El objetivo de esta fase es alcanzar un conocimiento suficiente de la aplicación,

definiendo las necesidades, problemas y requisitos del usuario, para expresarlo

mediante los modelos de procesos y de datos.

4.1.- RECONOCIMIENTO DEL PROBLEMA

4.1.1.- ÁMBITO DEL PROYECTO

Partiendo de los objetivos señalados en la parte de identificación de necesidades, se

definen a continuación, las entidades principales del proyecto:

1. USUARIO: Es la entidad que ejecuta la aplicación, ya sea un usuario que

desea obtener conocimientos sobre las estructuras de datos dinámicas, o un

profesor que imparte dichos conocimientos. La ejecución de la aplicación

podrá realizarse en local u online

2. SERVIDOR DE APLICACIONES: Entidad a la que se le solicita el servicio de

ejecución de la aplicación, si ésta es online, y que contiene el código de la

misma. Antes de la ejecución del tutorial de estructuras de datos dinámicas,

se realizará un proceso interno de identificación del usuario para acceder a la

zona personal del profesor o al portal de recursos.


27

3. PÁGINA WEB: Entidad que muestra la ejecución que va realizando el usuario

sobre la aplicación y muestra los resultados de dicha ejecución si ésta es

online.

4. EQUIPO LOCAL: Entidad que muestra la ejecución que va realizando el

usuario sobre la aplicación y muestra los resultados de dicha ejecución si ésta

se ejecuta en local.


28

4.1.2.- CONTEXTO GENERAL DEL SISTEMA

Este contexto general del sistema está representado mediante un diagrama de

presentación, con símbolos y figuras, donde se muestra la iteración del sistema con

el usuario, y las relaciones con las entidades anteriormente descritas.

En este diagrama de presentación, no se ha discriminado el tipo de usuario de la

aplicación, es decir, se ha tenido en cuenta tanto si es alumno como profesor, el cual

si desea ejecutar el tutorial de estructuras de datos dinámicas online deberá realizar

un proceso de verificación de usuario para acceder a la página Web y por lo tanto

poder ejecutar la aplicación.

Este proceso de verificación y autenticación del usuario no se tendrá en cuenta en la

programación de la aplicación, ya que es una medida de seguridad adoptada por la

universidad para el adecuado acceso a las zonas personales de los profesores,

alumnos y al portal de recursos.

EJECUCIÓN EN LOCAL

EJECUCIÓN ONLINE

SERVIDOR APP.

PÁGINA WEB

TUTORIAL DE ESTRUCTURAS

DE DATOS DINÁMICAS

USARIO

TUTORIAL DE ESTRUCTURAS

DE DATOS DINÁMICAS

EQUIPO LOCAL


29

4.1.3.- MATRIZ DE FUNCIONES

En la siguiente matriz de expondrán de forma esquematizada las principales

funciones y procesos a realizar por cada una de las entidades que aparecen en el

diagrama de presentación anterior.

ENTIDADES FUNCIONES / PROCESOS

Usuario

§ Introduce usuario y clave en el sistema para

acceder a la zona personal o al portal de recursos.

§ Realiza la petición del servicio al servidor de

aplicaciones para ejecutar el tutorial de estructuras

de datos dinámicas.

§ Ejecuta la aplicación, ya sea online o en local.

Servidor de aplicaciones

§ Recibe la solicitud del servicio para ejecutar la

aplicación.

§ Recibe el usuario que desea ejecutar la aplicación

y su clave.

§ Verifica la autenticidad del usuario.

§ Envía la información necesaria a la página Web

para mostrar la aplicación.

§ Contiene el código de la aplicación.

Página Web § Muestra los contenidos teóricos y la ejecución de la

aplicación, si ésta es online.

Equipo local

§ Muestra los contenidos teóricos y la ejecución de la

aplicación, si ésta es online.


30

4.2.- LISTA DE FUNCIONES DEL SISTEMA ACTUAL. MODELO

FÍSICO DEL SISTEMA ACTUAL. MODELO LÓGICO DEL SISTEM A

ACTUAL

Como ya se expuso en la parte de antecedentes de la identificación de necesidades

del proyecto, no existe ninguna aplicación de características similares a la

desarrollada. La metodología actual de la enseñanza de las estructuras de datos

dinámicas se fundamenta en el uso de la pizarra, apuntes y presentación de

diapositivas, teniendo así que representar gráficamente, por parte de la persona que

imparte los conocimientos, tanto la estructura de datos que se está estudiando y

analizando como los cambios que se producen en ella a la hora de realizar las

operaciones.

Esta metodología se caracteriza por la ausencia de procesos y funciones claramente

definidos y reconocidos para su análisis y representación en el modelo físico y

modelo lógico de sistema actual en la fase de análisis de requisitos. Por este motivo

no se han analizado y desarrollado en la realización de la documentación del

proyecto.


31

4.3.- LISTA DE REQUISITOS

A continuación se presentarán los distintos requisitos que deben cumplir cada una de

las funciones y procesos de la aplicación.

En la parte de identificación, se presenta el nombre del proyecto de la aplicación así

como el nombre de su autor.

En la sección de requisito, se identifica el mismo con sus distintas características,

como son fecha, versión, estado, prioridad, un identificador del requisito, la categoría,

que podrá ser funcional atendiendo a características propias de las funciones de

negocio, operativa si atienden al modo en el que opera la aplicación, de prestaciones

atendiendo a características adicionales o funcionales de menor prioridad, de

seguridad, si atienden al control del acceso a la aplicación y a los datos que contiene

o de fiabilidad, si atiende a la integridad, veracidad y validación de la información que

contiene la aplicación.

En la parte de medición se detallará el modo de cumplimiento del requisito en función

del tiempo de respuesta de la aplicación y de otros condicionantes.

En el apartado de beneficios, se detallarán los distintos beneficios que reporta el

requisito, ya sea a la aplicación o al usuario.

En la sección de comentarios y soluciones sugeridas se incluirán comentarios para la

correcta y óptima ejecución de la aplicación.


32

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 1 Titulo : Inserciones en listas enlazadas simples. Identificador: LRQ01 Categoría: Operativo. Descripción: El usuario de la aplicación podrá realizar inserciones, altas, en una lista enlazada simple, que se le presentará o no dependiendo de su elección hasta un número máximo de nodos. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado de la inserción será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. Cuando se alcance el número máximo de nodos a insertar aparecerá un cuadro de diálogo que informará al usuario de ha alcanzado dicha cifra y se le dará la opción de volver a insertar los nodos de nuevo. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción del usuario.

COMENTARIOS / SOLUCIONES SUGERIDAS. Puesto que la aplicación está programada con el lenguaje orientado a eventos Visual Basic 6.0 es necesario utilizar un sistema operativo Windows en cualquiera de sus versiones, ya que la migración de aplicaciones desarrolladas bajo este lenguaje a otros equipos con distinto sistema operativo es prácticamente nula. Dado que la aplicación se podrá ejecutar online, solicitando el servicio pertinente al servidor de aplicaciones, sería conveniente utilizar un navegar de última generación, como puede ser Microsoft Explorer 6 o superior.


33

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 2 Titulo : Recorridos en listas enlazadas simples. Identificador: LRQ02 Categoría: Operativo. Descripción: El usuario de la aplicación podrá observar como se recorren los nodos en una lista enlazada simple, en la que se le presentarán los distintos cambios de los punteros a medida que se recorre la estructura de datos. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado del recorrido será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. Cuando se alcance el final de la lista enlazada aparecerá un cuadro de diálogo que informará de la situación al usuario, ofreciéndole la opción de volver a recorrer la lista enlazada. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción del usuario y su correcto funcionamiento, comprobando en cada momento que no se salga de la lista enlazada. COMENTARIOS / SOLUCIONES SUGERIDAS. Puesto la aplicación está programada con el lenguaje orientado a eventos Visual Basic 6.0 es necesario utilizar un sistema operativo Windows en cualquiera de sus versiones, ya que la migración de aplicaciones desarrolladas bajo este lenguaje a otros equipos con distinto sistema operativo es prácticamente nula. Dado que la aplicación se podrá ejecutar online, solicitando el servicio pertinente al servidor de aplicaciones, sería conveniente utilizar un navegar de última generación, como puede ser Microsoft Explorer 6 o superior.


34

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 3 Titulo : Eliminaciones en listas enlazadas simples. Identificador: LRQ03 Categoría: Operativo. Descripción: El usuario de la aplicación podrá realizar eliminaciones, bajas, en una lista enlazada simple, en la que dependiendo de la opción del usuario se le presentará o no. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado de la eliminación será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. En el momento en el que el usuario no pueda eliminar más nodos de la lista enlazada por que no se pueda, se le comunicará mediante un cuadro de diálogo, informándole de esta situación. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción realizada por el usuario.

COMENTARIOS / SOLUCIONES SUGERIDAS. Puesto la aplicación está programada con el lenguaje orientado a eventos Visual Basic 6.0 es necesario utilizar un sistema operativo Windows en cualquiera de sus versiones, ya que la migración de aplicaciones desarrolladas bajo este lenguaje a otros equipos con distinto sistema operativo es prácticamente nula. Dado que la aplicación se podrá ejecutar online, solicitando el servicio pertinente al servidor de aplicaciones, sería conveniente utilizar un navegar de última generación, como puede ser Microsoft Explorer 6 o superior.


35

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 4 Titulo : Inserciones en listas doblemente enlazadas. Identificador: LRQ04 Categoría: Operativo. Descripción: El usuario de la aplicación podrá realizar inserciones, altas, en una lista doblemente enlazada, que se le presentará o no dependiendo de su elección hasta un número máximo de nodos. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado de la inserción será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. Cuando se alcance el número máximo de nodos a insertar aparecerá un cuadro de diálogo que informará al usuario de ha alcanzado dicha cifra y se le dará la opción de volver a insertar los nodos de nuevo. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción del usuario.



36

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 5 Titulo : Recorridos en listas doblemente enlazadas. Identificador: LRQ05 Categoría: Operativo. Descripción: El usuario de la aplicación podrá observar como se recorren los nodos en una lista doblemente enlazada, en la que se le presentarán los distintos cambios de los punteros, tanto del comienzo de la lista como de los nodos, a medida que se recorre la estructura de datos. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado del recorrido será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. Cuando se alcance el final de la lista enlazada aparecerá un cuadro de diálogo informándole de la situación y ofreciéndole la opción de volver a recorrer la lista doblemente enlazada. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción del usuario y su correcto funcionamiento, comprobando en cada momento que no se salga de la lista enlazada. COMENTARIOS / SOLUCIONES SUGERIDAS. Puesto la aplicación está programada con el lenguaje orientado a eventos Visual Basic 6.0 es necesario utilizar un sistema operativo Windows en cualquiera de sus versiones, ya que la migración de aplicaciones desarrolladas bajo este lenguaje a otros equipos con distinto sistema operativo es prácticamente nula. Dado que la aplicación se podrá ejecutar online, solicitando el servicio pertinente al servidor de aplicaciones, sería conveniente utilizar un navegar de última generación, como puede ser Microsoft Explorer 6 o superior.


37

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 6 Titulo : Eliminaciones en listas doblemente enlazadas. Identificador: LRQ06 Categoría: Operativo. Descripción: El usuario de la aplicación podrá realizar eliminaciones, bajas, en una lista doblemente enlazada, que se le presentará o no dependiendo de su elección hasta un número máximo de nodos. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado de la eliminación será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. En el momento en el que el usuario no pueda eliminar más nodos de la lista enlazada por que no se pueda, se le comunicará mediante un cuadro de diálogo, informándole de esta situación. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción realizada por el usuario.



38

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 7 Titulo : Inserciones en pilas. Identificador: LRQ07 Categoría: Operativo. Descripción: El usuario de la aplicación podrá realizar inserciones, altas, en una pila, en la que se le presentará completamente vacía, para que así pueda realizar el máximo número de inserciones. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado de la inserción será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. Cuando se alcance el número máximo de nodos a insertar aparecerá un cuadro de diálogo que informará al usuario de que ha alcanzado dicho límite y se le dará la opción de volver a insertar los nodos de nuevo. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción del usuario.



39

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 8 Titulo : Eliminaciones en pilas. Identificador: LRQ08 Categoría: Operativo. Descripción: El usuario de la aplicación podrá realizar eliminaciones, bajas, en una pila, que se le presentará con todos los nodos insertados, para que así pueda realizar el máximo número de eliminaciones. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado de la eliminación será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. En el momento en el que el usuario no pueda eliminar más nodos de la pila, se le comunicará mediante un cuadro de diálogo, informándole de esta situación. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción realizada por el usuario.



40

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 9 Titulo : Inserciones en colas. Identificador: LRQ09 Categoría: Operativo. Descripción: El usuario de la aplicación podrá realizar inserciones, altas, en una cola, en la que se le presentará completamente vacía, para que así pueda realizar el máximo número de inserciones. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado de la inserción será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. Cuando se alcance el número máximo de nodos a insertar aparecerá un cuadro de diálogo que informará al usuario de que ha superado el límite y se le dará la opción de volver a insertar los nodos de nuevo. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción del usuario.



41

IDENTIFICACIÓN. Proyecto: Tutorial gráfico de estructuras de datos dinámicas. Autor del proyecto : Luis Mª García Sanjuán. REQUISITO. Fecha: 18/03/2006 Versión: 1.0 Estado: Aceptado Prioridad: Media Página: 10 Titulo : Eliminaciones en colas. Identificador: LRQ010 Categoría: Operativo. Descripción: El usuario de la aplicación podrá realizar eliminaciones, bajas, en una cola, que se le presentará con todos los nodos insertados, para que así pueda realizar el máximo número de eliminaciones. MEDICIÓN. El tiempo de respuesta de la aplicación a la hora de mostrar el resultado de la eliminación será no superior a 2 segundos. Para las consultas del código de la operación en la pantalla donde se presente el pseudocódigo será de 1 segundo. En el momento en el que el usuario no pueda eliminar más nodos de la cola, se le comunicará mediante un cuadro de diálogo, informándole de esta situación. BENEFICIOS. El principal beneficio de este requisito es la rápida respuesta de la aplicación ante la acción realizada por el usuario.



42

4.4.- LISTA DE FUNCIONES LÓGICAS DEL NUEVO SISTEMA

Las principales funciones lógicas del nuevo sistema, las cuales se representarán en

el modelo lógico son:

1. Introducción del usuario y de la clave.

2. Validación del usuario y de la clave.

3. Petición del servicio

4. Ejecución de la aplicación

5. Presentación del resultado.

A continuación se representará el modelo lógico en sus dos niveles, contextual y

conceptual. En la representación de dicho modelo sólo se realizará hasta segundo

nivel, es decir, el nivel 0 para el contextual y el nivel 1 para el conceptual.


43

4.5.- MODELO LÓGICO DEL NUEVO SISTEMA

4.5.1.- NIVEL CONTEXTUAL

�

��

��

��

��

��

��

��

��

��

��

��

��

��

��

��

USUARIO Y CLAVE: Usuario y la clave con se accede a la ejecución online.

SOLICITUD DEL SERVICIO: Solicitud al servidor de la ejecución online.

EJECUCIÓN: Ejecución de la aplicación por parte del usuario.

RESULTADO: Resultado de la aplicación ya sea online o en local.

INFORMACIÓN: Información que envía la página sobre la ejecución de la aplicación.


44

4.5.2.- NIVEL CONCEPTUAL

USUARIO Y CLAVE: Usuario y la clave con se accede a la ejecución online.

RECHAZO: Rechazo de la ejecución de la aplicación debido a un usuario y clave

incorrectos.

ACEPTACIÓN: Aceptación del usuario y la clave por parte del sistema de

autenticación.


45

SERVICIO: Solicitud de la ejecución del Tutorial de estructuras de datos dinámicas

por parte del usuario.

EJECUCIÓN: Ejecución de la aplicación por parte del usuario.

RESULTADO: Resultado de la aplicación ya sea online o en local.

INFORMACIÓN: Información que envía la página sobre la ejecución de la aplicación.

USUARIOS Y CLAVES: Almacén de información que contiene los usuarios y sus

respectivas claves para acceder al sistema.

PÁGINA WEB: Almacén de información que muestra los resultados de la ejecución

de la aplicación.

SERVIDOR DE APLICACIONES: Almacén de información al que se le solicita la

ejecución de la aplicación y contiene el código de la misma.


46

Como se indicó anteriormente, se ha llegado a un nivel 2 de detalle a la hora de

representar el modelo lógico del nuevo sistema, dada la gran cantidad de procesos y

funciones que hubiera conllevado la representación de un nivel inferior y en especial

el desarrollo del proceso 4, EJECUCIÓN DE LA APLICACIÓN. No obstante, para

reconocer y saber cuales son estos procesos, se detallará a continuación una lista

con dichos procesos, aunque no aparezcan en el nivel conceptual del modelo lógico

del nuevo sistema.

La representación de estos procesos en el nivel contextual hubiera sido:

Donde ACCION DEL USUARIO es la ejecución que va realizando éste sobre

cada uno de los formularios que se le van presentando durante la ejecución de la

aplicación y RESULTADO es el resultado que muestra la aplicación debido a la

acción que ha realizado el usuario


47

EJECUCIÓN DE LA TAREA es uno de los siguientes procesos:

LISTAS ENLAZADAS SIMPLES

1. TEORÍA

1.1. Introducción.

1.2. Inserciones.

1.3. Recorridos.

1.4. Eliminaciones.

2. EJECUCIÓN PRÁCTICA

2.1 Inserciones.

2.1.1 Inserción en una lista vacía.

2.1.2 Inserción al comienzo.

2.1.3 Inserción entre dos nodos.

2.1.4 Inserción al final.

2.2 Recorridos.

2.3 Eliminaciones.

2.3.1 Eliminación del primer nodo.

2.3.2 Eliminación de un nodo intermedio o último.


48

LISTAS DOBLEMENTE ENLAZADAS

1. TEORÍA

1.1. Introducción.

1.2. Inserciones.

1.3. Recorridos.

1.4. Eliminaciones.


2.1. Inserciones.

2.1.1. Inserción en una lista vacía.

2.1.2. Inserción al comienzo.

2.1.3. Inserción entre dos nodos.

2.1.4. Inserción al final.

2.2. Recorridos.

2.3. Eliminaciones.

2.3.1. Eliminación del primer nodo.

2.3.2. Eliminación de un nodo intermedio o último.


49

PILAS

1. TEORÍA

1.1. Introducción.

1.2. Inserciones.

1.3. Eliminaciones.


2.1. Inserción de un nodo en una pila

2.2. Eliminación de un nodo en una pila

COLAS

1. TEORÍA

1.1. Introducción.

1.2. Inserciones.

1.3. Eliminaciones.


2.1. Inserción de un nodo en una cola.

2.2. Eliminación de un nodo en una cola.


50

4.6.- DIAGRAMA ENTIDAD-RELACIÓN DEL NUEVO SISTEMA

El diagrama Entidad-Relación más adecuado para resumir el funcionamiento de la

aplicación, englobando cada una de las entidades que intervienen con las relaciones

que existen entre ellas es el siguiente:

��

��

��

��

�

�

��

��

��

�

��

�

��

�

�

��

�

��

�

��

�

��


51

5.- HISTORIA DE VIDA DE LAS ENTIDADES

En esta etapa se describe la evolución de las entidades principales de la aplicación

para:

§ Obtener un registro de la secuencia de los cambios de las entidades en el

tiempo.

§ Obtener los requisitos de tratamiento de las entidades.

§ Establecer los estados posibles de las entidades para que tengan lugar las

transiciones externas, así como los cambios de estado de cada una de las

entidades debido a las transiciones.

§ Poner de manifiesto las posibles interacciones que producen los eventos o

sucesos.

Las dos principales entidades sobre las que se realizará el estudio de historia de

vida, serán los usuarios de la aplicación y el servidor en el que se alojará dicha

aplicación, si la ejecución del tutorial de estructuras de datos dinámicas es online en

vez de ser en local.

Primero se realizará un estudio de identificación de los eventos de dichas entidades,

para luego poder realizar la matriz entidad-evento y así poder concluir con un

diagrama de historia de vida de cada una de las dos entidades.


52

5.1.- IDENTIFICACIÓN DE LOS EVENTOS

Para poder identificar los eventos que ocurren en la aplicación es necesario que se

cumplan los requisitos anteriormente descritos en la etapa de Análisis de requisitos,

que se estudie en detalle los atributos de las entidades más importantes y que se

analice el Diagrama de flujo de datos que se representó en el modelo lógico del

nuevo sistema.

Una vez analizados todos estos requisitos se procede a enumerar los eventos que

acontecen:

§ Evento 1: Registro del usuario.

§ Evento 2: Registro de la clave.

§ Evento 3: Modificación del usuario.

§ Evento 4: Modificación de la clave.

§ Evento 5: Verificación del usuario.

§ Evento 6: Verificación de la clave.

§ Evento 7: Solicitud del servicio.

§ Evento 8: Verificación del servicio.

§ Evento 9: Acción del usuario.

§ Evento 10: Presentación del resultado.


53

5.2.- MATRIZ ENTIDAD-EVENTO

Para realizar la construcción de la matriz entidad-evento, se dispondrá de una matriz

de dos dimensiones. En la parte de las filas se colocarán cada una de las entidades,

en este caso serán el propio usuario de la aplicación y el servidor en el que se

encuentre almacenada y en la parte las columnas cada uno de los eventos que se

han identificado en el apartado anterior.

La matriz entidad-evento del tutorial gráfico de estructuras de datos dinámicas es la

siguiente:

EVENTOS E1 E2 E3 E4 E5 E6 E7 E8 E9 E10

USUARIO I I M M - - I - I - ENTIDADES SERVIDOR - - - - I I - M - I

La matriz entidad-evento se ha rellenado con tres símbolos: I (inserción) y M

(modificación), que indican el efecto que produce un evento determinado sobre cada

una de las entidades. En muchas ocasiones la celda correspondiente se encuentra

con el correspondiente marcador “-” indicando que no se produce ningún efecto de

ese evento determinado sobre esa entidad concreta.


54

5.3.- CONTRUCCIÓN DEL DIAGRAMA HVE

Como ya se especificó con anterioridad, los diagramas que se estudiarán serán de

las dos entidades más importantes, el usuario de la aplicación y el servidor en el que

se ejecutará.

El diagrama de la historia de vida de la entidad usuario es:


55

El diagrama de la historia de vida de la entidad servidor es:


56

6.- ESTUDIO DE LA ARQUITECTURA

El objetivo de esta fase es definir las posibles soluciones de arquitectura que

satisfagan tanto los requisitos del usuario, como las restricciones de diseño de la

aplicación. Para ello, se definen unas posibles soluciones, se las somete a un

estudio de viabilidad y se elige la más adecuada, para ser desarrollada e

implementada.

6.1.- DISEÑO DE LA ARQUITECTURA

6.1.1.- DIGRAMA DE PRESENTACIÓN

Para representar la aplicación a un alto nivel, se puede utilizar un diagrama de

presentación, que expresa las características hardware y operativas de las que esta

compuesta.

6.1.1.1.- NIVEL LOCAL

La representación del diagrama de presentación en un nivel local, carece de

elementos hardware de red, como pueden ser routers, concentradores, servidores de

aplicación y demás. Consta solamente del equipo en el que se va a ejecutar la

aplicación, pudiendo estar conectado a periféricos de entrada y salida, no siendo

relevante este hecho para la aplicación.


57

6.1.1.2.- NIVEL ONLINE

La representación del diagrama de presentación en un nivel online, está compuesto

de elementos hardware de red, como pueden ser, concentradores, servidores. Tanto

la tipología de la red como dichos elementos de red que aparecen en el diagrama

pueden diferir de la que se instale la aplicación, pudiendo ser la red de una tipología

Token Ring, en árbol, de estrella, así como los elementos encaminadotes pueden ser

conmutadores, concentradores, puentes.

Además, pueden existir más redes de las que están representadas en el diagrama y

existir tanto encaminadores de red como redes intermedias entre la red principal y el

servidor de aplicaciones en el que se encuentra el software.


58

6.1.1.- ESPECIFICACIÓN DE LOS COMPONENTES BÁSICOS

HARDWARE LOCAL NECESARIO YA EXISTENTE

Los componentes hardware ya existentes en el sistema en el que se ejecutará la

aplicación son los siguientes:

§ Microprocesador Pentium IV 1.8 MHz o superior.

§ Memoria RAM de 512 Mb.

§ Tarjeta de sonido.

§ Unidad de CD-ROM.

§ Un ratón.

§ Una tarjeta de vídeo soportada por Windows.

HARDWARE LOCAL NECESARIO DE NUEVA ADQUISICIÓN

Los elementos hardware anteriormente descritos superan a los requisitos mínimos

que especifica el paquete de aplicaciones que proporciona Microsoft Visual Studio

6.0 y que se detallan más adelante. Por lo que no es necesario ningún elemento

hardware de nueva adquisición


59

SOFWARE LOCAL NECESARIO YA EXISTENTE

Los componentes software ya existentes en el sistema en el que se ejecutará la

aplicación son los siguientes:

§ Microsoft Windows 2000.

§ Microsoft Internet Explorer versión 5.0.

§ Paquete de aplicaciones Microsoft Visual Studio 6.0.

§ Componentes OCX y DLL para Microsoft Visual Studio 6.0.

SOFTWARE LOCAL NECESARIO DE NUEVA ADQUISICIÓN

Los elementos software anteriormente descritos superan a los requisitos mínimos

que requiere cualquier aplicación realizada con Microsoft Visual Studio 6.0 y que se

detallan más adelante. Por lo que no es necesario ningún tipo de elemento software

de nueva adquisición. Los objetos programados que utiliza la aplicación son

estándares y cargados al instalar cualquier versión de Microsoft Windows con su

correspondiente archivo OCX, en el caso de utilizar componentes que no sean de

estas características se incluirá el correspondiente archivo OCX o DLL del objeto en

cuestión.


60

REQUISITOS MÍNIMOS NECESARIOS

Existen tres versiones de Microsoft Visual Basic que son la estándar o de

aprendizaje, la profesional y la empresarial. La edición estándar permite crear

robustas aplicaciones para las versiones de Windows 9x, Windows NT, Windows

2000 y Windows XP, incluye todos los controles intrínsecos y además de los

controles de rejilla, cuadros de diálogo estándar y los controles enlazados de datos.

La edición profesional contiene todas las características de la versión estándar, así

como los controles activos (ActiveX) adicionales, el diseñador de aplicaciones para

Internet Information Server, el diseñador de páginas en formato HTML dinámico y

administrador visual de bases de datos (VisData). La edición empresarial contiene

todas las características de la edición profesional como las herramientas Back Office

como SQL Server, Microsoft Transaction Server, Internet Information Server, Visual

SourceSafe, SNA Server y demás.

Los requisitos mínimos para poder instalar satisfactoriamente Microsoft Visual 6.0 y

poder ejecutar la aplicación son:

§ Microprocesador Pentium 90MHz o superior.

§ Disco duro con un espacio mínimo de 80Mb.


§ Un ratón.


§ 32 MB de memoria.

§ Microsoft Windows 95 o posterior, o Windows NT 3.51 o superior.

§ Microsoft Internet Explorer versión 4.01 o posterior.


61

6.2.- EVALUACIÓN DE LAS ALTERNATIVAS

Para realizar una correcta evaluación de las alternativas, es necesario que se

encamine la determinación de estas hacia el modo de operar del usuario final y al

tipo de arquitectura tecnológica a usar.

6.2.1.- PARÁMETROS A VALORAR

En este caso, la aplicación de tutorial gráfico de estructuras de datos dinámicas tiene

dos alternativas respecto a la posible ejecución del usuario. La primera es la

ejecución local de la aplicación en el equipo del que disponen el usuario de la

aplicación. La segunda es la ejecución por medio de un servidor de aplicaciones en

el que se alojará la aplicación y se mostrará el resultado de cada una de las

ejecuciones que realiza el usuario en una página Web destinada para ello.

A continuación se especifican cada una de las alternativas explicadas con

anterioridad, incluyendo los componentes software y hardware de cada una.


62

ESPECIFICACIÓN DE LA ALTERNATIVA 1

Título Código Ejecución local. ESAL01

Antecedentes El usuario ejecutará la aplicación en modo local, sin existir la necesidad de disponer de elementos de conectividad.

Requisitos El usuario de la aplicación deberá cumplir con los requisitos mínimos anteriormente descritos para poder ejecutar el tutorial.

Beneficios La velocidad de ejecución y su respuesta esperada de la aplicación dependerá exclusivamente del equipo que disponga el usuario.

Necesidades hardware El usuario deberá cumplir con los requisitos hardware mínimos requeridos por el paquete de aplicaciones Microsoft Visual Studio 6.0.

Necesidades software El usuario deberá cumplir con los requisitos hardware mínimos requeridos por el paquete de aplicaciones Microsoft Visual Studio 6.0.


63

ESPECIFICACIÓN DE LA ALTERNATIVA 2

Título Código Ejecución online. ESAL02

Antecedentes El usuario ejecutará la aplicación en modo online, es decir, la aplicación estará ubicada en un servidor de aplicaciones al que el usuario se conectará y solicitará el servicio de ejecución de la aplicación. A medida que realice las operaciones, los resultados se mostrarán en una página Web.

Requisitos El usuario de la aplicación deberá cumplir con los requisitos mínimos anteriormente descritos para poder ejecutar el tutorial y disponer del hardware y software necesario para poder realizar la conexión con el servidor.

Beneficios La velocidad de ejecución y su respuesta esperada de la aplicación dependerá del tipo de conexión que disponga el usuario.

Necesidades hardware El usuario deberá cumplir con los requisitos hardware mínimos requeridos por el paquete de aplicaciones Microsoft Visual Studio 6.0 así como los requisitos necesarios para poder realizar la conexión con el servidor.

Necesidades software El usuario deberá cumplir con los requisitos hardware mínimos requeridos por el paquete de aplicaciones Microsoft Visual Studio 6.0.


64

6.2.2.- MATRICES DE EVALUACIÓN

La evaluación de las diferentes soluciones propuestas para la ejecución de la

aplicación se realizará en base a tres niveles de evaluación, nivel organizativo, nivel

operativo, nivel técnico. Para analizar la evaluación de las distintas alternativas, se

utilizará una matriz de evaluación organizativa, donde se recoge y se puntúa las

diferentes características y parámetros de cada uno de los aspectos a estudiar.

En la gran mayoría de los proyectos, llegada esta etapa de evaluación de

alternativas, se suele realizar un estudio detallado del factor económico en base al

llamado análisis de coste - beneficio incorporando un nivel más a analizar, el nivel

económico. En este nivel, se estudian y evalúan los costes tangibles del desarrollo

del proyecto, como son los costes de implantación, los costes de adquisición de

tecnología y los costes operacionales. Dado el alcance y la finalidad de este proyecto

no se llevará a cabo este estudio.

6.2.2.1.- EVALUACIÓN ORGANIZATIVA

El aspecto que se valorará para la evaluación organizativa será la adecuación de los

usuarios finales de la aplicación ante los posibles cambios de metodología en el

estudio de las estructuras de datos dinámicas.


65

6.2.2.2.- EVALUACIÓN OPERATIVA

Los distintos parámetros que se analizarán desde un nivel operativo serán:

§ Apreciación de los cambios que se realizan en la estructura de datos a medida

que el usuario realiza las operaciones sobre ella.

§ Valoración por parte del usuario de la importancia de las estructuras de datos

como base del tratamiento de información.

§ Disponibilidad inmediata del pseudocódigo.

§ Fiabilidad en los conocimientos teóricos de la aplicación.

§ Acceso seguro a la información.

6.2.2.3.- EVALUACIÓN TÉCNICA

Los parámetros a evaluar en el nivel técnico serán:

§ Acceso a la ejecución de la aplicación.

§ Portabilidad de la aplicación.

§ Mantenimiento de la aplicación.

§ Seguridad de la aplicación.

§ Facilidad de uso y ejecución de la aplicación.


66

6.2.3.- VALORACIÓN DE LAS ALTERNATIVAS

Una vez mencionadas las evaluaciones a analizar, se realiza una matriz de

evaluación organizativa, especificando el concepto de cada grupo de parámetros y

los criterios seguidos a la hora de calificarlo.

Cada parámetro a analizar se referencia en la matriz con una constante, asignándola

un peso o valor entre 1 y 3, siendo 3 el valor más alto y 1 el más bajo, dependiendo

de la importancia que tenga dicho factor en la aplicación del tutorial gráfico de

estructuras de datos dinámicas.

ALTERNATIVA 1 ALTERNATIVA 2 NÚMERO PARÁMETRO

PESO PESO

1.1 Adecuación de los usuarios finales a la metodología.

3 3

2.1 Apreciación de los cambios que se realizan. 3 3

2.2 Valoración de la importancia de las estructuras de datos.

2 2

2.3 Disponibilidad inmediata del pseudocódigo. 2 2

2.4 Fiabilidad en los conocimientos teóricos de la aplicación.

3 3

2.5 Acceso seguro a la información. 2 3 3.1 Acceso a la ejecución de la aplicación. 2 3 3.2 Portabilidad de la aplicación. 3 2 3.3 Mantenimiento de la aplicación. 2 3 3.4 Seguridad de la aplicación. 3 3 3.5 Facilidad de uso y ejecución de la aplicación. 3 3

Como se puede apreciar en la matriz de evaluación organizativa, los pesos de las

dos alternativas están muy repartidos, sumando la primera alternativa un total de 28

y la segunda alternativa un total de 30.


67

6.2.4.- PONDERACIÓN DE LAS ALTERNATIVAS

A continuación se calculará la ponderación asociada a los distintos parámetros de

cada una de las dos alternativas en términos porcentuales. En un primer lugar la

evaluación de los distintos parámetros dependiendo del tipo de factor en términos de

porcentaje es:

NIVEL ALTERNATIVA 1 ALTERNATIVA 2 Organizativo 3 3 Operativo 12 13 Técnico 13 14 TOTAL 28 30

La ponderación asociada a cada uno de los parámetros:

ALTERNATIVA PONDERACIÓN NIVEL 1 2 1 2

Organizativo 3 3 10,7% 10,0% Operativo 12 13 42,9% 43,3% Técnico 13 14 46,4% 46,7%

TOTAL 28 30

Como se puede observar en esta última matriz, ambas alternativas tienen

porcentajes absolutos muy parecidos, ya que la valoración de los parámetros de

cada una de las dos alternativas está repartida equitativamente. La mayor diferencia,

en términos porcentuales, se da en el nivel organizativo con una 0,7%.


68

0,0

10,0

20,0

30,0

40,0

50,0

Nivel organizativo Nivel operativo Nivel técnico

Evaluación

ALTERNATIVA 1

ALTERNATIVA 2

El gráfico anterior muestra la representación porcentual de cada una de las

alternativas, en sus distintos niveles de evolución. Ambas alternativas dan casi la

misma importancia a los parámetros de evaluación.

6.2.4.- SELECCIÓN DE LA ALTERNATIVA

El análisis realizada para cada una de las alternativa, se puede concluir diciendo que

ambas alternativas han obtenido resultados muy parecidos tanto en los pesos

otorgados a cada parámetro como en cada una de las distintas ponderaciones que

se han realizado en el estudio. El grado de dispersión no es muy alto en lo que

respecta a los resultados obtenidos.

Se podría decir que las dos alternativas de ejecución de la aplicación son válidas

para llevar a la práctica por el usuario. Con la salvedad de que la ejecución online

está condicionada a la operatividad y funcionalidad de los elementos de conexión de

los que disponga el usuario final a la hora de ejecutar el tutorial gráfico de estructuras

de datos dinámicas.


69

6.3.- PLANIFICACIÓN DEL PROYECTO

Una planificación estimada con la que se ha determinado las distintas fases del

proyecto de aplicación es el siguiente:

NOMBRE DE LA TAREA DURACIÓN COMIENZO FINALIZACIÓN ANTERIORES

Diseño externo 24 días 17/03/2006 17/04/2006 Fronteras de mecanización 1 día 17/03/2006 17/03/2006 Especificación de los procesos 1 día 18/03/2006 18/03/2006 Diseño de entradas 5 días 19/03/2006 23/03/2006 3 Diseño página Web 1 día 19/03/2006 19/03/2006 3 Estimación de los volúmenes de información 5 días 24/03/2006 30/03/2006 4

Procesos de control 3 días 31/03/2006 04/04/2006 6 Procesos de seguridad 5 días 31/03/2006 06/04/2006 6 Modelo lógico de datos 7 días 07/04/2006 17/04/2006 8 Diseño interno 11 días 18/04/2006 02/05/2006 9 Análisis subsistemas 3 días 18/04/2006 20/04/2006 9 Subsistema BATCH 3 días 21/04/2006 25/04/2006 11 Subsistema ONLINE 3 días 21/04/2006 25/04/2006 11 Estructuración menús y pantallas 5 días 26/04/2006 02/05/2006 12 Cuadernos de carga 3 días 26/04/2006 08/04/2006 12 Realización diagramas de estructuras 2 días 01/05/2006 02/05/2006 14

Programación 19 días 18/04/2006 12/05/2006 Realización diagramas UML 2 días 15/05/2006 16/05/2006 16 Manual de usuario 4 días 15/05/2006 18/05/2006 16 Pruebas del sistema 4 días 17/05/2006 21/05/2006

La planificación del proyecto se ha realizado utilizando el programa Microsoft Project

2003, que viene incorporado en el paquete de aplicaciones Microsoft Office 2003.

Este programa basa el cálculo del comienzo, duración y finalización de las tareas en

un calendario de tipo estándar, predefiniendo los fines de semana como días

laborables.


70

A continuación, se muestra la representación de la planificación del proyecto. Esta

imagen representa la planificación de las fases del ciclo de vida de la aplicación.


71

Esta imagen representa la planificación de las distintas tareas del ciclo de vida de la

aplicación.


72

7.- DISEÑO EXTERNO

A partir de la alternativa tecnológica elegida en el estudio de la arquitectura, en esta

fase se completarán los requisitos físicos del nuevo sistema, se diseñarán las

entradas y salidas, se completará la especificación de los procesos del modelo, y se

elaborará el modelo lógico de datos, a partir de las transacciones que realiza la

aplicación. A fin de completar la definición del modelo físico, se le dota de procesos

de control y seguridad.

El conocimiento del nuevo sistema, aumentará considerablemente en esta etapa y se

podrá establecer la estrategia a seguir en los planes de formación del usuario, la

conversión de los datos, las pruebas del tutorial gráfico de estructuras de datos

dinámicas.


73

7.1.- FRONTERAS DE MECANIZACIÓN

Las posibilidades de implementación de la aplicación sobre una plataforma

tecnológica, se especificaron en la fase de estudio de arquitectura. Allí se definieron

las características técnicas, organizativas y operativas de la solución a desarrollar.

Según esto, se podrá determinar ahora qué procesos formarán parte del modelo

físico del nuevo sistema. Esta tarea, puede realizarse partiendo de los Diagramas de

flujo de datos del modelo lógico nuevo sistema, en su nivel conceptual, en el que se

establecieron con anterioridad las fronteras de mecanización para el tutorial

El modelo lógico del nuevo sistema considerado en la fase de análisis de requisitos

de este sistema de gestión es:


74

7.2.- ESPECIFICACIÓN DE PROCESOS

A continuación se realizará la especificación de cada uno de los procesos que

analizaron en el modelo lógico del nuevo sistema.

7.2.1.- INTRODUCCIÓN CLAVE Y USUARIO

ESPECIFICACIÓN DEL PRIMER PROCESO.

Proceso: Introducción usuario y clave.

Localización: Vía Web. Categoría del proceso: Online, Cliente-Servidor. Tipo de proceso: Manual. Frecuencia: Aperiódica.

Descripción: Este proceso desencadena el segundo proceso, validación del usuario y la clave. Como flujos de información recibe del exterior el usuario y la clave, los guarda en el almacén de información destinado para ello y se lo envía al siguiente proceso.

7.2.2.- VALIDACIÓN CLAVE Y USUARIO

ESPECIFICACIÓN DEL SEGUNDO PROCESO.

Proceso: Validación usuario y clave.

Localización: Vía Web. Categoría del proceso: Online, Cliente-Servidor. Tipo de proceso: Automático. Frecuencia: Aperiódica.

Descripción: Este proceso desencadena el tercer proceso, solicitud del servicio, en el caso de que el usuario y la clave pertenezcan al sistema o enviará el flujo de información necesario para indicar al usuario que el usuario y/o la clave no son válidos. Como flujos de información recibe del proceso anterior el usuario y la clave y envía la correspondiente aceptación o rechazo.


75

7.2.3.-SOLICITUD DEL SERVICIO

ESPECIFICACIÓN DEL TERCER PROCESO.

Proceso: Solicitud del servicio.

Localización: Vía Web. Categoría del proceso: Online, Cliente-Servidor. Tipo de proceso: Automático. Frecuencia: Aperiódica.

Descripción: Este proceso no desencadena ningún proceso siguiente. Como flujos de entrada de datos recibe la aceptación del proceso anterior y el tipo de servicio del exterior. Una vez recibido el servicio se lo envía al servidor de aplicaciones para que comience con la ejecución online de la aplicación.

7.2.4.- EJECUCIÓN DE LA APLICACIÓN

ESPECIFICACIÓN DEL CUARTO PROCESO.

Proceso: Ejecución de la aplicación.

Localización: Local. Categoría del proceso: Online, Cliente-Servidor. Tipo de proceso: Manual. Frecuencia: Aperiódica.

Descripción: Este proceso desencadena el último proceso, presentación del usuario. El usuario irá realizando las distintas ejecuciones de la aplicación o navegando por los menús que se le presentan. Esta ejecución será un flujo de datos que recibirá el proceso del exterior, enviando el resultado esperado a la página Web que mostrará el resultado.


76

7.2.5.- PRESENTACIÓN DEL RESULTADO

ESPECIFICACIÓN DEL QUINTO PROCESO

Proceso: Presentación del resultado.

Localización: Vía Web Categoría del proceso: Online, Cliente-Servidor Tipo de proceso: Automático. Frecuencia: Aperiódica.

Descripción: Este proceso muestra el resultado de la ejecución de la aplicación en una página Web. Al ser el último proceso no desencadena ninguno más. Recibe el resultado de la aplicación y la muestra en la página Web. La página Web a su vez enviará la información necesaria al proceso para indicar la correcta presentación.

Cabe resaltar que la frecuencia de todos los procesos es aperiódica ya que depende

de la frecuencia de ejecución del usuario, no existe en todo el sistema de la

aplicación del tutorial gráfico de estructuras de datos dinámicas un proceso que

tenga una determinada frecuencia establecida, ya que el usuario es el que decide en

todo momento el orden de navegación por los distintos formularios que se le

presentan.


77

7.3.- DISEÑO DE ENTRADAS. INTERFACE DEL USARIO

Con esta tarea, se pretende realizar el diseño de los diferentes elementos de entrada

de la aplicación, como los distintos formularios o ventanas, páginas HTML,

formularios y ficheros, especificando sus características y validaciones. El interfaz de

usuario (E/S), en este caso específico, se basa en la realización de menús y

pantallas para que el usuario pueda interaccionar con la aplicación.


78

7.3.1.- FORMUALRIOS Y PANTALLAS

Esta pantalla corresponde al formulario principal de la aplicación, en el que se

presenta un menú para la elección de la estructura de datos que se va a estudiar.


79

Esta pantalla corresponde al formulario de la estructura de datos que se va a

estudiar, en el que se presenta dos menús para la elección de la parte de teoría o la

parte de ejecución práctica. En este tipo de formularios se incluirá una breve

introducción y una imagen de la estructura de datos a estudiar.


80

Esta pantalla corresponde al formulario de la introducción de estructura de datos que

se está estudiando, en el que se definen las características de la estructura de datos

que se va a estudiar y las posibles operaciones que se pueden realizar. En este tipo

de formularios se incluirán dos botones, Anterior y Siguiente, para poder navegar por

las distintos formularios de la aplicación que pertenecen a la parte de teoría.


81

Esta pantalla corresponde al formulario de la ejecución práctica de estructura de

datos que se está estudiando, en el que se presenta la situación inicial de la

estructura de datos por medio de una etiqueta, que irá explicado como se realiza la

operación a medida que el usuario va ejecutando la aplicación. En este tipo de

formularios se incluirán dos botones, uno para realizar la operación y otro para

visualizar el pseudocódigo.


82

Esta pantalla corresponde a la ventana de la ejecución práctica de estructura de

datos que se está estudiando, en el que se informa al usuario que no puede seguir

realizando la operación que se estaba ejecutando o bien porque se han insertado el

máximo de nodos, o bien por que se han eliminado todos los nodos de la estructura

de datos, o bien por motivos de presentación del resultado.


83


datos que se está estudiando, en la que se presenta la finalización de la ejecución

por los motivos anteriormente explicados. En este tipo de formularios se inutilizará el

botón para realizar la operación se incluirá un botón, Comenzar de nuevo, por si el

usuario decide volver a realizar la operación.


84


datos que se está estudiando, en algunos casos, dependiendo del tipo de operación

que se esta realizando, se incluirá una caja de texto para que el usuario decida sobre

que nodo realizar la operación.


85

7.3.2.- PÁGINA WEB

Una posible página Web en la que se pedirán los datos de autenticación del usuario,

se mostrará la aplicación y se presentará el resultado puede ser la que se muestra a

continuación.

Esta página Web corresponde a la del proceso de autenticación. Todo ello se podría

implementar mediante código HTML y código Java Data Base Connectivity (JDBC)

embebido en el código HTML.


86

Esta página Web corresponde a la que mostraría la aplicación y los resultados. Todo

ello se podría implementar mediante código HTML alojando la aplicación por medio

de un Applet.


87

Además de diseñar físicamente los tipos de ventanas, formularios páginas Web o

pantallas, se especificarán las características de cada una de ellas.

IDENTIFICACIÓN Código: 01 Nombre: Caja de texto de la aplicación FORMATO Tipo de letra Arial a tamaño 12 con alineación a la derecha, con la longitud máxima de caracteres que viene establecida por defecto en los objetos Text de Microsoft Visual Studio 6.0. TIPO DE CAMPO La caja de texto admite cualquier tipo de carácter, ya sea numérico al alfabético, pero la aplicación validará el valor introducido, siendo exclusivamente válidos los valores numéricos mayores que 0 y menores que 9.

MENSAJES DE VALIDACIÓN En caso de que el valor introducido no pertenezca a este rango se le comunicará al usuario por medio de una ventana.

TABLAS O FICHEROS UTILIZADOS Para la validación del valor introducido en la caja de texto no se utiliza ningún tipo de tabla ni de fichero.


88

IDENTIFICACIÓN Código: 02 Nombre: Caja de texto de la página Web (Usuario) FORMATO Tipo de letra Times New Roman a tamaño 12 con alineación a la derecha, con la longitud máxima de caracteres que viene establecida por defecto en los objetos Text de Microsoft Internet Explorer. TIPO DE CAMPO La caja de texto admite cualquier tipo de carácter, ya sea numérico al alfabético, pero la aplicación validará el valor introducido, siendo exclusivamente válidos los valores que pertenezcan a la base de datos de usuarios y claves.

MENSAJES DE VALIDACIÓN En caso de que el valor introducido no pertenezca a la base de datos se le comunicará al usuario por medio de una ventana.

TABLAS O FICHEROS UTILIZADOS Para la validación del valor introducido en la caja de texto se realizará un acceso a la base de datos de usuarios y claves.

IDENTIFICACIÓN Código: 03 Nombre: Caja de texto de la página Web (Clave) FORMATO Tipo de letra Times New Roman a tamaño 12 con alineación a la derecha, con la longitud máxima de caracteres que viene establecida por defecto en los objetos Text de Microsoft Internet Explorer. TIPO DE CAMPO La caja de texto admite cualquier tipo de carácter, ya sea numérico al alfabético, pero la aplicación validará el valor introducido, siendo exclusivamente válidos los valores que pertenezcan a la base de datos de usuarios y claves.

MENSAJES DE VALIDACIÓN En caso de que el valor introducido no pertenezca a la base de datos se le comunicará al usuario por medio de una ventana.

TABLAS O FICHEROS UTILIZADOS Para la validación del valor introducido en la caja de texto se realizará un acceso a la base de datos de usuarios y claves.


89

7.4.- DISEÑO DE SALIDAS

Los flujos de datos que salen del sistema hacia entidades externas, pueden

considerarse como salidas hacia el exterior, y podrán resultar ser ventanas de

resultados o páginas, formulario, ficheros o informes. Por tanto son básicamente

elementos iguales a las entradas, a excepción de los informes o listados en papel.

La aplicación tutorial de estructuras de datos dinámicas, al tratar de una aplicación

con fines didácticos, no realiza ni produce ningún tipo de informe de salida, por lo

que no se analizará esta parte de la fase de diseño externo.


90

7.5.- ESTIMACIÓN DE LOS VOLÚMENES DE INFORMACIÓN.

DETERMINACIÓN DE ENTIDADES Y PROCESOS CRÍTICOS

La información de volúmenes persigue dos objetivos, el primero de ellos es poder

dimensionar el tipo de transacciones que pueden presentarse dentro de la

aplicación, ajustando el modelo a las necesidades físicas. Las transacciones que

conlleven mayor número de accesos a la base de datos o almacenes de información

como puede ser el servidor de aplicaciones, serán más críticas. Además este estudio

de volúmenes indicará si los procesos definidos en el modelo lógico están bien

diseñados respectos de los datos que manejan.

El segundo objetivo que se persigue en este análisis es la obtención de la

información acerca de las diferentes entidades del modelo de datos, a fin de realizar

un diseño lógico de estos. Así puede descubrirse la necesidad de crear nuevas

claves o identificadores que resten tiempo en los programas aunque se a base de

aumentar la redundancia y por tanto, la ocupación en disco.

Para realizar el estudio se parte del modelo lógico o físico de procesos, del modelo

de datos, del ciclo de vida de las entidades y de los diseños de entrada.

A continuación, se realizará el análisis de la estimación de los volúmenes de

información a partir de los procesos críticos que se identificaron en la fase de historia

de vida de las entidades.


91

Los procesos críticos más importantes que se desarrollan en la aplicación son los

siguientes:

§ Proceso 1: Registro del usuario.

§ Proceso 2: Registro de la clave.

§ Proceso 3: Modificación del usuario.

§ Proceso 4: Modificación de la clave.

§ Proceso 5: Verificación del usuario.

§ Proceso 6: Verificación de la clave.

§ Proceso 7: Solicitud del servicio.

§ Proceso 8: Verificación del servicio.

§ Proceso 9: Acción del usuario.

§ Proceso 10: Presentación del resultado.

Dentro de estos procesos críticos, cabe destacar que los procesos 5, 6, 7, 8, 9 y 10

que son verificación del usuario, verificación de la clave, solicitud del servicio,

verificación del servicio, acción del usuario y presentación del resultado son los más

críticos dentro de los críticos, ya que la frecuencia con la que se realizan el resto de

los procesos no es alta.

ENTIDADES TRANSACCIÓN

USUARIO SERVIDOR DE APLICACIONES PÁGINA

WEB Registro usuario Medio - Bajo - - Registro clave Medio - Bajo - - Modificación usuario Bajo - - Modificación clave Bajo - - Verificación usuario - Alto - Verificación clave - Alto - Solicitud servicio - Medio - Verificación servicio - Medio - Acción usuario - Alto Alto Presentación resultado - Alto Alto


92

7.6.- PROCESO DE CONTROL Y SEGURIDAD

Esta etapa introduce y especifica en el modelo de la aplicación, los controles de

operación y la seguridad del sistema. Todos estos procesos de control y seguridad

podrán incluirse dentro de alguno de los procesos existentes, o bien integrarlos como

nuevos procesos en el modelo físico. Para realizar este análisis deben estudiarse los

siguientes procesos:

§ Procesos destinados a preservar la integridad de los datos.

§ Seguridad de la información y del acceso.

§ Procedimiento de recuperación de la información.

7.6.1.- PROCESOS DE CONTROL

Este tipo de procesos son aquellos que de acuerdo al estudio y desarrollo de la

aplicación deben cumplirse bien por circunstancias detectadas en un momento del

ciclo de vida de la aplicación o bien por los propios requisitos que debe de cumplir la

aplicación. Entre las mediadas de control que preservan la integridad de control de la

aplicación se pueden citar:

§ Registro de logging de los usuarios que acceden a la aplicación si la ejecución

es cliente - servidor.

§ Controles asociados a los archivos RTF, que incluyen el pseudocódigo, para

su exclusiva lectura.

§ Control de los archivos instalados durante el proceso de instalación e

implantación de la aplicación.


93

Estos procesos de control se incorporarán a la aplicación, siendo o bien automáticos

como el proceso de logging, como propiedades que se añaden a los objetos, como

por ejemplo los archivos, que se activará la propiedad de sólo lectura para que no

puedan ser modificados por ningún tipo de usuario. De esta manera se podrá

mantener la integridad de los datos y su recuperación.

7.6.2.- PROCESOS DE SEGURIDAD DE LA INFORMACIÓN

Este tipo de procesos o procedimientos están relacionados con la seguridad de los

datos, la privacidad de la información que contiene y maneja la aplicación y la

integridad de los datos. Entre las mediadas de seguridad que preservan la integridad

de los datos de la aplicación, pueden citarse:

§ Propiedades asociadas a las componentes visuales para que no sean

modificadas.

§ Propiedades de control para las componentes que muestran el pseudocódigo

para que no sean modificadas por ningún usuario.

Estas dos medidas de seguridad de los datos que maneja la aplicación, no son

ningún tipo de proceso que se puede representar en el modelo físico del nuevo

sistema, si no que son propiedad que deben de cumplir los objetos de la aplicación,

como son los menús, los botones o los archivos de lectura que maneja.


94

Las medidas de seguridad de la red de comunicaciones serán propias del servidor y

de la red en la que se encuentre el usuario en el momento que ejecute la aplicación

en modo cliente - servidor. Este tipo de medidas de seguridad no serán implantadas

en la aplicación.

Ambos tipos de procesos, tanto los de control como los de seguridad de la

información, pueden representarse en una matriz donde se especifica su descripción,

el motivo porque es requerido el proceso, que procesos del modelo físico del nuevo

sistema están afectados.

DESCRIPCIÓN DEL CONTROL REQUERIDO POR

PROCESOS AFECTADOS

Registro de logging de los usuario. Seguridad de acceso Proceso 2

Controles asociados a los archivos RTF. Integridad Proceso 4 Control de los archivos instalados. Recuperación Proceso 4 Propiedades asociadas a las componentes. Integridad Proceso 4 Propiedades de control de las componentes. Integridad Proceso 4

Representado ahora la descripción de cada proceso con su respectiva técnica a

utilizar.

DESCRIPCIÓN DEL CONTROL TÉCINICA A UTILIZAR

Registro de logging de los usuario.

Proceso de reconocimiento del usuario por medio de un nombre de usuario y una clave.

Controles asociados a los archivos RTF. Modificación de las propiedades del archivo.

Control de los archivos instalados.

Propiedades propias del asistente para empaquetado y distribución de Microsoft Visual Studio 6.0.

Propiedades asociadas a las componentes.

Propiedades programadas en cada una de las componentes.

Propiedades de control de las componentes.

Propiedades programadas en cada una de las componentes.


95

7.7.- MODELO LÓGICO DE DATOS

El modelo lógico establece la estructura de los datos con los que trabajan los

procesos de la aplicación, sin tener en cuenta los recursos físicos utilizados. Estas

estructuras se componen de relaciones o tablas en el modelo relacional, donde las

columnas representan atributos y las filas el conjunto de ocurrencias de cada

relación. El modelo lógico se encarga de completar la información recabada en el

modelo conceptual

§ Entidades de datos: definición y composición.

§ Atributos: definición, clasificación por tipos y descripción de cada una de las

características.

§ Claves de cada una de las entidades: determinación de la clave primaria o

principal y de otras posibles claves como claves secundarias y extranjeras.

§ Relaciones entre entidades: relaciones establecidas en el modelo conceptual.

Para la realización del modelo lógico de datos se necesitan cada una de las

definiciones de las entidades que intervienen en el Diagrama Entidad-Relación y de

las relaciones entre ellas.


96

A continuación se detalla el Diagrama Entidad-Relación obtenido en la etapa del

análisis de requisitos.

A continuación se detallan cada una de las entidades y relaciones más relevantes

que constituyen el diagrama entidad – relación, detallando en cada una de ellas sus

atributos y las claves principales según la normalización establecida para ello.


97

7.7.1.- ENTIDADES

ENTIDAD_USUARIO={Nombre_usuario + Clave_usuario}

ENTIDAD_SERVIDOR={Nombre_servidor + Dirección_web}

ENTIDAD_APLICACIÓN={Identificador_aplicación + Nombre_aplicación}

ENTIDAD_FORMULARIO={Nombre_formulario + {Componentes + Eventos}}

ENTIDAD_PÁGINA_WEB={Dirección_página + Nombre_página }

ENTIDAD_RESULTADO={Identificador_resultado + {Componentes + Eventos}}

7.7.2.- RELACIONES

RELACIÓN_SOLICITA={Nombre_usario + Clave_usuario + Nombre_servidor}

RELACIÓN_CONTIENE={Nombre_servidor + Identificador_aplicación}

RELACIÓN_TIENE={Identificador_aplicación + Nombre_formulario}

RELACIÓN_MUESTRA={Nombre_formulario + Dirección_página}

RELACIÓN_EXPLICA={Dirección_página + Identificador_resultado}

Comparando el modelo lógico de datos de la aplicación con las entidades y

relaciones obtenidas en el diagrama entidad - relación, se puede observar que se ha

eliminado la entidad CLAVE, ya que es un atributo de la entidad USUARIO y parte de

la clave de esta relación. Además se ha eliminado la relación POSEE, que vinculaba

a CLAVE y USUARIO ya que se ha eliminado la primera entidad.


98

El resultado del diagrama entidad – relación, basándose en el modelo lógico de

datos anterior, es el que se muestra a continuación.


99

8.- DISEÑO INTERNO

El objetivo para realizar un adecuado diseño interno de la aplicación del tutorial

gráfico de estructuras de datos dinámicas es identificar los componentes software de

la aplicación, como son los módulos de la aplicación, fases, transiciones y servicios.

Para una correcta realización será necesario dividir el sistema dos unidades de

diseño, como son el subsistema batch y el subsistema online.

El subsistema batch afecta a los procesos de la aplicación que precisen un orden

secuencial de ejecución. Para la realización y representación de este subsistema se

utilizará la técnica del diagrama HIPO, derivando los diagramas de flujo de datos

obtenidos en la fase de análisis de requisitos hacia dicho diagrama.

EL subsistema online recoge aquellos procesos de la aplicación que no se realicen

bajo un orden secuencial de ejecución, procesándose de manera aleatoria a petición

del usuario final de la aplicación. Para la representación y análisis de este

subsistema se utilizará el diagrama de cuadros estructurado o STC.

También, en esta fase, se desarrollarán las especificaciones de cada uno de los

programas y de sus módulos.


100

8.1.- SUBSISTEMA BATCH

Para la realización del diagrama HIPO y los procedimientos catalogados se necesita

el diagrama del modelo lógico del nuevo sistema para comprender las funciones y

procesos que desempeña la aplicación. Una vez realizado ese estudio, se dota a los

procesos de una secuencialidad para obtener los diagramas HIPO. Estos diagramas

contienen una especificación de cada una de las funciones.

El modelo lógico del nuevo sistema es:

�

��

��

��

��

��

�

��

��

��

��

��

��

�

��

��

��

� ��

!

��

��

��

"

��

��

��

��

��

��


101

Una vez identificados los procesos secuenciales del modelo anterior, se realiza el

diagrama HIPO.

El diagrama HIPO anterior corresponde al proceso de validación del usuario, que se

identifica con el sistema por medio de un nombre de usuario y una clave, y al

proceso de solicitud del servicio, en este caso la ejecución del tutorial gráfico de

estructuras de datos dinámicas.


102

8.1.1.- CUADERNOS DE CARGA

Nombre Cód igo Gestión de la validación del usuario. CC1

Fecha 26/04/2006

Definición Proceso que verifica la autenticidad del usuario que desea acceder a la aplicación por medio de un sistema cliente – servidor. El proceso realizará una conexión a la base de datos de usuarios y claves para verificar su autenticidad.

Diagrama DFD

Diagrama HIPO

��

��

��

��

��

��


103

Nombre Cód igo Gestión de la de la solicitud del servicio. CC2

Fecha 26/04/2006

Definición Proceso que gestiona la solicitud de la ejecución del tutorial gráfico de estructuras de datos dinámicas por parte del usuario.

Diagrama DFD

Diagrama HIPO

��

��

��

��

��

��


104

8.2.- SUBSISTEMA ONLINE

Para la realización del diagrama de cuadros estructurado y el análisis de

transformación y transacción se necesita el DFD del modelo lógico del nuevo sistema

para comprender las funciones y procesos que desempeña la aplicación a petición

del usuario. Una vez realizado ese estudio se establece una jerarquía entre los

componentes y los parámetros utilizados por la aplicación para obtener un diagrama

de estructuras.

El modelo lógico del nuevo sistema es:

�

��

��

��

��

��

�

��

��

��

��

��

��

�

��

��

��

� ��

!

��

��

��

"

��

��

��

��

��

��


105

Una vez identificados los procesos que no son secuenciales y que ejecuta el usuario

de forma aleatoria, se realiza el diagrama STC.

El diagrama de cuadros estructurado anterior corresponde al proceso de introducción

del usuario y la clave, estos datos se introducen por medio de una página Web

vinculada al servidor de aplicaciones, y a los procesos de ejecución de la aplicación y

presentación del resultado. La presentación del resultado de la ejecución que realice

el usuario se mostrará por en una página Web destinada para ello.

PROCESO INTRODUCCIÓN USUARIO Y CLAVE

LEER USUARIO Y CLAVE

ACCESO A USUARIOS Y CLAVES

LEER USUARIO Y CLAVE

CONSULTA

RESULTADO CONSULTA

USUARIO Y CLAVE

VALIDACIÓN

RESULTADO CONSULTA

USUARIO Y CLAVE

EJECUCIÓN

RESULTADO

PRESENTAR RESULTADO

RESULTADO

TRATAR RESULTADO

TRATAR EJECUCIÓN


106

8.3.- ESTRUCTURA DE MENÚS Y PANTALLAS

El diseño deL diagrama de diálogos para la navegación del usuario en aplicación es

el siguiente:

MENÚ PRINCIPAL

DESPLIEGUES INMUTABLES

(INSERCIONES)

MENÚ SECUNDARIO


(RECORRIDOS)


(ELIMINACIONES

MENÚ SECUNDARIO

DESPLIEGUE (INSERCIONES)

DESPLIEGUE (RECORRIDOS)


107

Con este diagrama se representa la transición entre las distintas pantallas,

formularios y menús de la aplicación por los que puede navegar y ejecutar el usuario.

DESPLIEGUE (ELIMINACIONES)

NODO A ELIMINAR

MENÚ SECUNDARIO


(AYUDA)


108

9.- PROGRAMACIÓN

El objetivo de esta etapa es alcanzar la transformación de la aplicación en un

conjunto de formularios que puedan ser ejecutados correctamente, bajo los criterios

de calidad estudiados y analizadas durante el ciclo de desarrollo de la aplicación.

Para la realización de la aplicación se ha elegido un lenguaje visual y orientado a

eventos como es Microsoft Visual 6.0.

Al realizar la codificación de la aplicación en el lenguaje de programación

anteriormente mencionado, se tendrán en cuenta los procesos que debe cumplir

según el modelo lógico del nuevo sistema, estudiado en la fase de estudio de la

arquitectura y los cuadernos de carga, estudiado en la fase anterior, diseño interno.

Al terminar el análisis de esta fase se incluirá un manual de usuario que incluirá el

ámbito y entorno de la aplicación, los perfiles de los usuarios finales y

funcionamiento de la aplicación.


109

9.1.- DIAGRAMAS UML

A continuación se mostrará el diagrama UML de la aplicación, que tiene como

objetivos mostrar los formularios programados y cada unos de sus eventos y

variables que utilizan para su correcta ejecución.

9.1.1.- FORMULARIO PRINCIPAL

9.1.2.- FORMULARIOS DE ESTRUCTURAS DE DATOS


110

9.1.3.- FORMULARIOS DE LISTAS ENLAZADAS


111

9.1.4.- FORMULARIOS DE LISTAS DOBLEMENTE ENLAZADAS


112

9.1.5.- FORMULARIOS DE PILAS


113

9.1.6.- FORMULARIOS DE COLAS


114

9.2.- MANUAL DE USUARIO

A continuación, se mostrará el manual de usuario que se ha realizado para la

aplicación de Tutorial gráfico de estructuras de datos dinámicas.

La realización de este manual, esta orientada a las funciones de la aplicación que

puede realizar el usuario sobre cada uno de los controles que se le presentan en

cada formulario, ya que dependerá del uso que se haga de la aplicación y de la

determinación del usuario de cómo utilizarlo.


115

MANUAL DE USUARIO

TUTORIAL GRÁFICO DE ESTRUCTURAS DE DATOS DINÁMICAS

Luis María García Sanjuán


116

1.- INTRODUCCIÓN

1.1.- RESUMEN DE LA APLICACIÓN

La finalidad de este tutorial es que sirva como herramienta visual de apoyo a

estudiantes que están empezando a manejar estructuras de datos dinámicas, para

asentar los conocimientos en la asignatura de estructuras de datos.

Los objetivos fundamentales de este tutorial son:

1. Aprendizaje de los conceptos fundamentales de las estructuras de datos

dinámicas, empezando desde un nivel bajo y, a medida que avanza el tutorial,

se incrementará la complejidad hasta un grado medio.

2. Aprendizaje de las operaciones básicas que se pueden realizar sobre una

estructura, como son las inserciones, eliminaciones y recorridos.

3. Implementación de esas operaciones, para ello en la aplicación aparecerá



4. Conocimiento en todo momento de la variación de la estructura a medida que

el usuario va realizando las operaciones sobre la misma. Se mostrará durante

toda la ejecución de cada operación la estructura de datos y se podrán



117

5. Valoración por parte del usuario de la importancia de las estructuras de datos

dinámicas como base al desarrollo y tratamiento de la información, así como

su importancia en la etapa de programación de cualquier aplicación.




el uso de las estructuras de datos dinámicas.

El tutorial se realizará en su totalidad bajo un entorno visual, para lo cual se

programará en lenguaje Visual Basic, un lenguaje orientado a eventos, utilizando el

paquete de aplicaciones que proporciona Microsoft Visual Studio 6.0.


118

1.2.- ÁMBITO DE LA APLICACIÓN Dada la multitud de estructuras de datos que existen en la actualidad, la aplicación a

desarrollar se centrará en las siguientes estructuras de datos: listas, pilas y colas,

aunque se pondrá en conocimiento del usuario la existencia de dicha multitud tanto

de estructuras de datos dinámicas como de operaciones que se pueden realizar

sobre ellas.

Dependiendo de la planificación del proyecto y de su seguimiento se añadirá un tipo

de estructura de datos más, los árboles, pero dependerá de la profundidad con la

que se desarrollen las estructuras de datos anteriores.

La ejecución de la aplicación por parte de los usuarios podrá ser en local, es decir,

instalando la aplicación y ejecutándola desde un ordenador personal o online,

ejecutándola desde un servidor de aplicaciones de la universidad o del centro de

estudios, que contenga todo el código necesario de la aplicación. Una vez solicitado

el servicio, se mostrará en la página Web de la zona personal del profesor o desde

un portal de recursos la ejecución de la aplicación.




el uso de las estructuras de datos dinámicas. La finalidad es que les sirva como una

herramienta para que entiendan y comprendan las características y operaciones de

cada estructura de datos que se está estudiando en ese momento.


119

Otro tipo de usuarios finales podrían ser profesores que imparten estos

conocimientos y que esta aplicación les sirva como material de apoyo didáctico a sus

explicaciones.

Los dos mayores problemas que resuelve la aplicación desarrollada son la

apreciación por parte del usuario de los cambios que se producen en la estructura de

datos y el ahorro de tiempo a la hora de escribir los pseudocódigos de las

operaciones y la representación gráfica de cada una de las estructuras de datos.


120

2.- DESCRIPCIÓN GENERAL DEL SISTEMA

2.1.- ENTORNO DE LA APLICACIÓN

Para poder ejecutar la aplicación se deberá cumplir con los requisitos mínimos que

vienen reflejados en el paquete de aplicaciones Microsoft Visual Studio 6.0. Estos

requisitos mínimos son:

§ Microprocesador Pentium 90MHz o superior.

§ Disco duro con un espacio mínimo de 80Mb.


§ Un ratón.


§ 32 MB de memoria.

§ Microsoft Windows 95 o posterior, o Windows NT 3.51 o superior.

§ Microsoft Internet Explorer versión 4.01 o posterior.

La aplicación utiliza objetos y componentes que no son del tipo estándar y por lo

tanto requieren su correspondiente archivo OCX o DLL. Estos archivos se incluyen

en el instalador de la aplicación para que pueda funcionar correctamente. El resto de

los componentes que utiliza la aplicación y que son estándar están instalados en la

carpeta System 32 que es creada cuando se instala el sistema operativo Microsoft

Windows en cualquiera de sus versiones.


121

2.2.- PERFILES DE USUARIO

Dependiendo del tipo de ejecución de la aplicación, existen dos tipos de usuarios,

usuario local y usuario online. El usuario local es aquel que ejecuta la aplicación en

modo local, desde su propio equipo sin tener la necesidad de estar conectado a

ningún tipo de red de comunicaciones. El usuario online es el que ejecuta la

aplicación en modo online, por medio de un servidor de aplicaciones. Ambos tipos de

usuarios tienen los mismos privilegios a la hora de ejecutar la aplicación, la única

diferencia es que el usuario online necesitará un nombre de usuario y una clave para

identificar y así poder acceder al servidor de aplicaciones para poder ejecutar el

tutorial.

Como es lógico, el usuario que ejecute la aplicación en modo online o cliente –

servidor, también necesitará tanto el hardware como el software necesario para

realizar la conexión al servidor de aplicaciones y la posterior presentación del

resultado de la ejecución de la operación que realice.


122

3.- FUNCIONAMIENTO DE LA APLICACIÓN

3.1.- INSTALACIÓN DE LA APLICACIÓN

Para la creación del archivo instalable de la aplicación Tutorial gráfico de estructuras

de datos dinámicas se ha utilizado la herramienta de Asistente para empaquetado y

distribución, herramienta que viene incorporada en el paquete de aplicaciones

Microsoft Visual Studio 6.0.

Para poder instalar la aplicación se debe hacer doble click en el icono para

que el instalador de la ejecución comience.

Una vez se ejecute el instalador, se recomendará que se cierren todas las

aplicaciones que se estén ejecutando para llevar a cabo la correcta instalación.


123

A continuación se pedirá el directorio de instalación en el que se alojará la aplicación.

Después de indicar la ruta de instalación, el instalador requerirá un nombre de grupo

para la aplicación.


124

Una vez pulsado el botón de Continuar, el instalador comenzará a instalar la

aplicación en el directorio que se especificó anteriormente. Una vez que termine de

instalar la aplicación, ésta estará lista para ejecutar en la ruta que se especificó.


125

Por defecto el instalador la opción al usuario de guardar, en un archivo de texto un

informe con los datos de la instalación, generalmente, este informe contiene la

siguiente información:

Se ha generado el archivo .cab para su aplicación c omo

'C:\Documents and Settings\Chete\Mis documentos\Ica i\3º

ITIG\Proyecto Fin De Carrera\Proyecto\Aplicacion\Pa quete

\Tutorial gráfico de estructuras de datos dinámicas .CAB'.

También hay un archivo de proceso por lotes en el d irectorio de

soporte (C:\Documents and Settings\Chete

\Mis documentos\Icai\3º ITIG\Proyecto Fin De Carrer a

\Proyecto\Aplicacion\Paquete\Support

\Tutorial gráfico de estructuras de datos dinámicas .BAT) que le

permitirá volver a crear el archivo .cab en caso de que

modifique alguno de los archivos.


126

3.2.- EJECUCIÓN DE LA APLICACIÓN

Para poder ejecutar se debe hacer clic en el icono de la aplicación en la ruta

que especificó durante el periodo de instalación.

3.2.- AYUDA DE LA APLICACIÓN

La aplicación incluye una pequeña ayuda para resolver los problemas que surjen a la

hora de ejecutar la aplicación y las dudas con respecto a la navegación y sus

componentes, como pueden ser los distintos menús de acción y los botones de

transición de un formulario a otro.


127

4.- ANEXOS

4.1.- INCIDENCIAS MÁS FRECUENTES

La incidencia más frecuente es que al ejecutar la aplicación no se vean todos los

componentes que forman parte del formulario, como pueden ser etiquetas, cajas de

texto o botones. Esto ocurre porque la resolución de la pantalla no es la adecuada.

La aplicación se ha programado bajo una resolución de pantalla de 1024 por 768

píxeles. Esta resolución debería ser la configurada en el sistema operativo para

poder ejecutar la aplicación de forma adecuada y así poder ver todos los

componentes.

4.2.- MENSAJES DE AVISO

La aplicación maneja 4 tipos de mensajes de aviso para advertir al usuario de las

distintas incidencias que ocurres en tiempo de ejecución por la acción que ha

realizado. A continuación se describe cada unos de estos mensajes de aviso.

4.2.1.- AVISO DEL LÍMITE DE INSERCIÓN

Este aviso aparece cuando se ha superado el límite de inserciones de nodos en la

estructura de datos que se está estudiando. Dicho límite es de 8 nodos. El

correspondiente mensaje de aviso es:


128

4.2.1.- AVISO DEL LÍMITE DE RECORRIDO

Este aviso aparece cuando se ha superado el límite de recorrido de nodos en la



4.2.1.- AVISO DEL LÍMITE DE ELIMINACIÓN

Este aviso aparece cuando se ha superado el límite de eliminación de nodos en la



4.2.1.- AVISO DE NODO INCORRECTO

Este aviso aparece cuando se ha introducido un nodo incorrecto, sobre el que se

quiere realizar una determina operación. El correspondiente mensaje de aviso es:


129

4.3.- GLOSARIO DE TÉRMINOS A continuación se presenta un glosario de términos y acrónimos que utiliza la

aplicación, en cada una de las estructuras de datos.

4.3.1.- LISTAS ENLAZADAS









§ NULL es una constante que utilizan los lenguajes de programación para

indicar que una variable puntero no apunta a ninguna dirección de memoria.


130

4.2.2.- LISTAS ENLAZADAS











§ SIGUIENTE es la parte del nodo que contiene la dirección del siguiente nodo


§ ANTERIOR es la parte del nodo que contiene la dirección del anterior nodo de

la lista enlazada.


131

4.2.3.- PILAS

§ CIMA es el campo que contiene la dirección del primer nodo de la pila.









4.2.4.- COLAS

§ FRENTE es el campo que contiene la dirección del primer nodo de la cola.










132

10.- PRUEBAS DEL SISTEMA

El objetivo global de esta fase es someter a la aplicación a una serie de planes de

prueba y verificaciones encaminadas a garantizar el nivel de fiabilidad esperado.

Una vez programados todos los módulos de la aplicación y probados cada uno de

ellos las pruebas a las que se han sometido han sido:

§ Pruebas de encaminamiento, que aseguran y verifican las llamadas entre las

distintas componentes y formularios.

§ Pruebas de integración que verifican la funcionalidad de toda la aplicación y el

rendimiento de los recursos utilizados.

§ Pruebas de explotabilidad que verifican la correcta operación del sistema.

§ Pruebas de seguridad, que verifican los aspectos de seguridad exigidos en los

requisitos de la aplicación.

§ Pruebas de sobrecarga, que verifican el correcto funcionamiento y

comportamiento de la aplicación ante los estados de sobrecarga en los que se

puede ver envuelto.

§ Pruebas de recuperación que verifica la capacidad de la aplicación para

recuperar la información.

§ Pruebas de aceptación del usuario que certifican por parte de los usuarios

finales la funcionalidad y rendimiento de la aplicación de acuerdo con los

requisitos establecidos.

§ Pruebas de usabilidad que certifican la accesibilidad de la aplicación.


133

11.- CONCLUSIONES

Después de haber realizado todo el análisis, desarrollo y programación del proyecto,

parece imprescindible tratar algunas cuestiones y conclusiones que han surgido a lo

largo de la realización del Tutorial gráfico de estructuras de datos dinámicas.

Tales conclusiones, son fruto de las dudas y preguntas que han surgido en el tema

objeto de este proyecto y que a continuación se exponen a modo de conclusiones

personales.

Primera.- Con el desarrollo de este proyecto se ha podido comprobar la dificultad,

tanto en el análisis como en la realización de la aplicación y todo lo que conlleva la

realización de un proyecto.

Existen múltiples puntos de vista y metodologías a la hora de desarrollar el proyecto;

cual se debe elegir es uno de los problemas más importantes a resolver, ya que si su

elección no es la adecuada, las expectativas del proyecto no serán las esperadas.

Segunda.- El lenguaje de programación Visual Basic es un lenguaje que, a priori,

puede resultar sencillo, ya que es un lenguaje muy visual, con una interfaz y sintaxis

muy básicas. La etapa de diseño de los distintos formularios es muy sencilla, ya que

se limita a la colocación de los componentes, botones, etiquetas, cajas de texto y

demás, en el sitio elegido dentro del formulario. La etapa de programación de los

componentes y de los múltiples eventos sobre los que actúan no es tan sencilla si se

quiere realizar adecuadamente. Visual Basic es un lenguaje sencillo, pero con el que

se pueden realizar potentes aplicaciones.


134

Tercera.- En el momento en el que se estudió cada una de las asignaturas de la

carrera prácticamente unas eran independientes de las otras, se podría decir que su

dimensión era vertical, pero la puesta en práctica de los conocimientos estudiados y

aprendido durante estos 3 años de carrera, ha sido en una dimensión horizontal para

la realización del proyecto, relacionando los conocimientos de una asignatura con

otra, cuando terminaba la fase de análisis estudiada en Ingeniería de software

comenzaba la fase de programación estudiada en la asignatura de Programación

visual.

Cuarta.- Uno de los objetivos fundamentales de la aplicación es valorar la

importancia de las estructuras de datos dinámicas como base de almacenamiento de

datos. Valorar su utilidad y en qué preciso momento es mejor utilizar una u otra. Con

la implantación de las operaciones que se pueden realizar sobre cada estructura de

datos y con la inclusión de los pseudocódigos para poder entender estas

operaciones se ha alcanzado la realización de este objetivo.

Quinta.- La última conclusión, y por ello no la menos importante, es la adquisición de

un carácter constante y emprendedor ante los problemas que iban surgiendo a

medida que se realizaba el proyecto, sobre todo a lo hora de realizar la codificación

en lenguaje Visual Basic de la aplicación.

El saber afrontar los problemas, como resolverlos y sobre todo la constancia y

dedicación volcados hasta que se consigue resolverlos, se ven recompensados

cuando se ve por primera vez ejecutar la aplicación.


135

12.- BIBLIOGRAFÍA

[BARR01] Barranco de Areba, J., “Metodología del análisis de sistemas”,

Universidad Pontificia de Comillas, Madrid 2001.

[SOMM05] Sommerville, I., traducción de Alfonso Galipienso, M. I.,

“Ingeniería del software”, Pearson Addison Wesley, Madrid 2005.

[BRAU03] Braude, E. J., “Ingeniería del software: una perspectiva orientada a

objetos”, Ra-Ma, Madrid 2003.

[STEV02] Stevens, P., Pooley R., traducción de Alarcón Fernández, M.,

Sanjuán Martínez, O. Pérez Sorrozal F., “Utilización de UML en

ingeniería del software con objetos y componentes”, Addison

Wesley, Madrid 2002

[GOME03] Gómez, C., “Diseño de sistemas software en UML”, Edicions UPC,

Barcelona 2003.

[DURA04] Durán Parra, L., “Apuntes de estructura de datos”, Universidad

Pontificia de Comillas, Madrid 2004.

[JOYA03] Joyanes Aguilar, L., “Fundamentos de la programación: libro de

problemas: algoritmos estructuras de datos y objetos”, Mc Graw Hill,

Madrid 2003.


136

[LANG97] Langsam, Y., traducción de Sarmiento Martinez, M. A., “Estructuras

de datos con C y C++”, Prentice Hall Hispanoamérica, México 1997.

[HERN01] Hernández, R., “Estructuras de datos y algoritmos”, Prentice Hall,

Madrid 2001.

[CEBA99] Ceballos Sierra, F. J., “Microsoft Visual Basic. Curso de

programación”, Ra-Ma, Madrid 1999.

[CHAR99] Charte Ojeda, F., “Visual Basic 6”, Anaya Multimedia, Madrid 1999.

[AITK99] Aitken, P. G., “Visual Basic 6: manual completo de programación”,

Paraninfo, Madrid 1999.

[SWAR99] Swartzfafager, G., “Visual Basic 6: programación orientada a

objetos”, Paraninfo, Madrid 1999.

[PERE02] Pérez-Campanero Atanasio, J. A., Morera Pascual, J. M.,

“Conceptos de sistemas operativos”, Universidad Pontificia de

Comillas, pp 66-67, 228-232, 352-357, Madrid 2002.

[MICR03] Microsoft, “Diccionario de informática e Internet”, Mc Graw Hill,

Madrid 2003.


137

[DORD00] Dordoinge, J., traducción de García, F., “Networking essentials”,

ENI, Nantes 2000.

[PITT00] Pitts, D., Ball, B., traducción de Seven Servicios Integrales, “Red Hat Linux

6 a fondo”, Anaya Multimedia, Madrid 2000.


138

13.- ANEXOS

Los anexos que se adjuntan junto con el proyecto Tutorial gráfico de estructuras de

datos dinámicas son:

1. Manual de instalación de Microsoft Visual Studio 6.0.

2. Valoración económica.

3. Planificación real del proyecto.

En el primer anexo, se incluirá un breve manual de instalación del paquete de

aplicaciones con el que se ha programado la aplicación, por si en alguna ocasión el

usuario ve conveniente la implementación de ésta.

En el segundo, se realizará la valoración económica de la totalidad del proyecto,

como son las horas de trabajo, software específico, licencias y demás.

El tercer y último anexo incluirá la planificación y duración real del proyecto, ya que

en la fase de estudio de la arquitectura la planificación que se realizó fue una

estimación.


139

13.1.- MANUAL DE INSTALACIÓN

Este manual de instalación del paquete de aplicaciones con el que se ha

programado la aplicación, tiene como objetivo guiar al usuario durante los pasos de

la aplicación. Instalando el paquete de aplicaciones Microsoft Visual Studio 6.0, el

usuario tendrá la oportunidad de implementar, si cree conveniente, los formularios y

eventos del tutorial realizado.

La versión con la que se ha programado la aplicación ha sido la versión empresarial

que contiene 6 CDS para su instalación. La edición empresarial contiene todas las

características de la edición profesional como las herramientas Back Office como

SQL Server, Microsoft Transaction Server, Internet Information Server, Visual

SourceSafe, SNA Server y demás.


140

1º Paso

Insertar el primer CD en la unidad lectora, después de unos segundos, el programa

de instalación comenzará con la siguiente pantalla. En esta pantalla se podrá

acceder al archivo Léame, en el que se pueden obtener todas las características e

información relativa a Microsoft Visual Studio 6.0.


141

2º Paso

A continuación, el instalador pedirá que se acepte el contrato de licencia. Se deben

detenidamente los términos de este contrato. Si no se acepta el contrato el instalador

se cerrará y no se instalará la aplicación.


142

3º Paso

Una vez aceptado el contrato, se introduce el nombre con el que se desea que

reconozca la aplicación y la organización empresarial a la que pertenece. Si instala

una versión que no sea la empresarial, es posible que se tenga que introducir el

número de licencia que viene con el paquete de aplicaciones.


143

4º Paso

Todo el paquete de aplicaciones Microsoft Visual Studio 6.0, utiliza objetos y eventos

para la programación de proyectos. Para poder crear estos objetos, es necesario lo

que se conoce como Máquina Virtual de Java o Virtual Java Machina. El instalador

requerirá su actualización.

Una vez que se actualicen e instalen estos módulos, la máquina se reiniciará.


144

5º Paso

Una vez que se reinicie la máquina, comenzará la instalación de Visual Studio 6.0. El

asistente de la instalación pedirá que se eleccione una de las opciones de

instalación.

Se debe elegir la ruta donde se quiere que se instale Visual Studio 6.0.


145

6º Paso

Si se elige la opción de instalación personalizada, se puede decidir cuáles son los

elementos que se desea instalar. Hay elementos que vienen seleccionados por

defecto y que no se podrán eliminar, ya que sin ellos no se puede utilizar Microsoft

Visual Studio 6.0.


146

7º Paso

A continuación, el asistente comenzará con la instalación. Al terminar con ésta se

pedirá que se reinicie la máquina de nuevo.


147

Los restantes 5 CD incluyen aplicaciones que no son necesarias para la ejecución de

Visual Basic 6.0, tales como Back Office como SQL Server, Microsoft Transaction

Server, Internet Information Server, Visual SourceSafe, SNA Server, ejemplos de

aplicaciones realizadas con Visual Basic 6.0 y el último Service Pack de Windows.

Ya que estos elementos no son necesarios, no se han incluido en el manual de

instalación.


148

13.2.- VALORACIÓN ECONÓMICA

A continuación se realizará la valoración económica de la totalidad del proyecto,

como son las horas de trabajo, software específico, licencias y demás. El objetivo de

esta valoración es dotar al proyecto de un valor económico y realizar una estimación

de la implantación del mismo.

Los costes de las horas empleadas para la realización del proyecto se han calculado

a partir de los salarios que cobran un analista junior y un programador junior. Estos

salarios son:

PUESTO SALARIO HORAS TOTAL Programador junior 40€/hora 120 horas 4.800,00 € Analista junior 60€/hora 140 horas 8.400,00 €

NOTA: Los salarios anteriormente expuestos son salario s anuales.

Los costes de obtención de las distintas licencias software para el desarrollo de la

aplicación utilizando Microsoft Visual Studio son:

PRODUCTO PRECIO MSDN Library 7 - Nueva Licencia 197,73 € MSDN Professional 7- Nueva Licencia 1.384,64 € MSDN Professional 7 - Renovación 534,30 € MSDN Universal 7- Nueva Licencia 3.238,90 € MSDN Universal 7 - Renovación 1.982,74 €

NOTA: Los precios anteriores han sido sacados de www.abox.com


149

Los costes de obtención de las distintas licencias software para el desarrollo de la

documentación y demás son:

PRODUCTO PRECIO USUARIO NUEVO

VERSIÓN DE ACTUALIZACIÓN

Office Edición Professional 2003 744,00 € 470,00 €

NOTA: Los precios anteriores han sido sacados de www.microsoft.com/spain

Office Edición empresarial, es el paquete de aplicaciones por excelencia de

Microsoft. Este paquete contiene las siguientes aplicaciones:

§ Microsoft Office Word 2003.

§ Microsoft Office Excel 2003.

§ Microsoft Office Access 2003.

§ Microsoft Office PowerPoint 2003.

§ Microsoft Office Project 2003.

§ Microsoft Office Visio 2003.

§ Microsoft Office Outlook 2003.

§ Microsoft Office Publisher 2003.

§ Soporte para la creación de contenidos en Extensible Markup Lenguaje y

Information Rights Management.


150

Los costes de una estación de trabajo, para la ejecución del Tutorial gráfico de

estructuras de datos dinámicas serían 629 €, con las siguientes características:

SISTEMAS OPERATIVOS:

§ Windows XP Home Edition.

§ Windows XP Professional Edition.

§ Windows XP Media Center Edition 2005.

§ Con capacidad para Windows Vista.

PROCESADOR:

§ Procesador Intel Pentium D con tecnología de doble núcleo hasta 955 (3,4

GHz, 2x2 MB de caché de nivel 2 y bus frontal lateral a 800 MHz).

TARJETA GRÁFICA:

§ Tarjeta gráfica PCI Express de hasta 256 MB de Nvidia, GeForce 7800GTX

ALMACENAMIENTO:

§ Hasta 1000 GB (Unidades de disco duro SATA de 2x500 GB).

CONEXIONES EN REDES

§ 10/100/1000 Ethernet integrada, preparada para banda ancha.

NOTA: El precio del equipo ha sido sacado de www.dell.es


151

Otros costes imputables al proyecto son:

CONCEPTO PRECIO Amortización equipo 450,00 € Otros costes 150,00 €

NOTA: El concepto de Otros costes hace referencia a costes de material, como

papel y tinta.

Teniendo en cuenta todos estos costes, la valoración económica del proyecto sería

la que refleja la siguiente tabla.

CONCEPTO PRECIO Programador junior 4.800,00 € Analista junior 8.400,00 € MSDN Professional 7- Nueva Licencia 1.384,64 € Office Edición Professional 2003 744,00 € Equipo local 629,00 € Amortización equipo 450,00 € Otros costes 150,00 € TOTAL 16.557,64 €

Esta valoración económica corresponde a la de máximo valor, ya que se han

considerado que las licencias del software necesario son de nueva adquisición.


152

CONCEPTO PRECIO Programador junior 4.800,00 € Analista junior 8.400,00 € MSDN Professional 7 - Renovación 534,30 € Office Edición Professional 2003 470,00 € Equipo local 629,00 € Amortización equipo 450,00 € Otros costes 150,00 € TOTAL 15.433,30 €

Esta valoración económica corresponde a la de mínimo valor, ya que se han

considerado que las licencias del software necesario son de renovación y no de

nueva adquisición.

Como se puede apreciar, no existe mucha diferencia entre las dos distintas

valoraciones realizadas. La diferencia es de 1.124,34 €.


153

13.3.- PLANIFICACIÓN REAL DEL PROYECTO

A continuación se presentará la planificación real del proyecto, en las distintas fases

del ciclo de vida en las que se ha dividido según la metodología en la que se ha

desarrollado.

Se debe mencionar que la fase de programación, se ha realizado a medida que se

iban analizando y desarrollando las distintas fases del ciclo de vida del proyecto.

Aunque en la siguiente tabla, el comienzo de la fase de programación sea el

17/12/2005 y su finalización el 12/05/2006, ésta ha tenido una duración total de 50

días, ya que sí comenzó y finalizó en esas fechas, pero no se realizó a cabo en todo

el período que comprende ambas fechas.


154

NOMBRE DE LA TAREA DURACIÓN COMIENZO FINALIZACIÓN Introducción 7 días 29/10/2005 04/11/2005 Identificación de necesidades 20 días 04/11/2005 19/11/2005 Objetivos de la aplicación 4 días 04/11/2005 07/11/2005

Alcance de la aplicación 4 días 07/11/2005 10/11/2005

Tipología de usuarios finales 4 días 10/11/2005 13/11/2005 Restricciones 4 días 13/11/2005 16/11/2005

Antecedentes 4 días 16/11/2005 19/11/2005

Definición del problema 1 día 19/11/2005 20/11/2005 Análisis de requisitos 16 días 20/11/2005 04/12/2005 Reconocimiento del problema 4 días 20/11/2005 23/11/2005

Modelo lógico del sistema actual 2 día 24/11/2005 25/11/2005 Lista de requisitos 5 días 25/11/2005 29/11/2055

Lista de funciones del nuevo sistema 1día 29/11/2005 30/12/2005

Modelo lógico del nuevo sistema 2días 01/12/2005 03/12/2005

Diagrama entidad-relación 2 días 03/12/2005 04/12/2005

Historia de vida de las entidades 4 días 04/12/2005 07/12/2005 Identificación de los eventos 1 día 04/12/2005 04/12/2005 Matriz entidad-evento 2 días 05/12/2005 06/12/2005

Construcción del diagrama HVE 1 día 06/12/2005 07/12/2005

Estudio de la arquitectura 18 días 08/12/2005 30/12/2005 Diseño de la arquitectura 5 días 08/12/2005 13/12/2005

Evaluación de las alternativas 10 días 14/12/2005 23/12/2005

Planificación del proyecto 3 días 27/12/2005 30/12/2005

Diseño externo 28 días 17/03/2006 17/04/2006 Fronteras de mecanización 1 día 17/03/2006 17/03/2006

Especificación de los procesos 1 día 18/03/2006 18/03/2006

Diseño de entradas 5 días 19/03/2006 23/03/2006

Diseño página Web 1 día 19/03/2006 19/03/2006

Estimación de los volúmenes de información 5 días 24/03/2006 30/03/2006 Procesos de control 3 días 31/03/2006 04/04/2006

Procesos de seguridad 5 días 31/03/2006 06/04/2006

Modelo lógico de datos 7 días 07/04/2006 17/04/2006

Diseño interno 15 días 18/04/2006 02/05/2006 Análisis subsistemas 3 días 18/04/2006 20/04/2006

Subsistema BATCH 3 días 21/04/2006 25/04/2006 Subsistema ONLINE 3 días 21/04/2006 25/04/2006

Estructuración menús y pantallas 5 días 26/04/2006 02/05/2006

Cuadernos de carga 3 días 26/04/2006 08/04/2006

Realización diagramas de estructuras 2 días 01/05/2006 02/05/2006

Programación 50 días 17/12/2006 12/05/2006 Realización diagramas UML 2 días 15/05/2006 16/05/2006 Manual de usuario 4 días 15/05/2006 18/05/2006

Pruebas del sistema 4 días 17/05/2006 21/05/2006 Anexos 10 días 21/05/2006 30/05/2006


155

El diagrama de la planificación de las distintas fases del proyecto es el siguiente.

Como ya se mencionó anteriormente, la fase de programación, se ha realizado a

medida que se iban analizando y desarrollando las distintas fases del ciclo de vida

del proyecto. Aunque en la siguiente tabla, el comienzo de la fase de programación

sea el 17/12/2005 y su finalización el 12/05/2006, ésta ha tenido una duración total

de 50 días, ya que sí comenzó y finalizó en esas fechas, pero no se realizó a cabo

en todo el período que comprende ambas fechas. Por eso se ha representado con

puntos suspensivos.