Universidad de San Carlos de Guatemala Escuela de Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026.
SISTEMA DE CATÁLOGO INTELIGENTE PARA LIBRERÍAS: ESTRUCTURAS JERÁRQUICAS Y ÁRBOLES AVL PROPIOS CON INTERFAZ WEB ASP.NET MVC Y REPRESENTACIÓN GRÁFICA CON GRAPHVIZ 202404788 – Christian Eduardo Sequen Orellana Resumen
Abstract
El proyecto describe el diseño e implementación, en el lenguaje C#, de un sistema de catálogo inteligente para una cadena de librerías con más de 100,000 libros distribuidos en varias sucursales. El sistema organiza el catálogo de forma jerárquica, similar a una biblioteca física dividida en categorías y subcategorías, y permite registrar, buscar, eliminar y visualizar libros de manera eficiente. La jerarquía se representa mediante un árbol binario propio construido con la técnica hijo-hermano, y la búsqueda de libros por ISBN se resuelve mediante un árbol AVL autobalanceado desarrollado íntegramente por el estudiante, sin recurrir a colecciones genéricas ni estructuras nativas del lenguaje. El sistema recibe archivos XML de configuración de forma incremental, expone su funcionalidad mediante una interfaz web ASP.NET Core MVC, y genera representaciones gráficas del catálogo mediante Graphviz.
This project describes the design and implementation, in the C# language, of an intelligent catalog system for a bookstore chain with more than 100,000 books distributed across several branches. The system organizes the catalog hierarchically, similar to a physical library divided into categories and subcategories, and allows registering, searching, deleting and visualizing books efficiently. The hierarchy is represented through a custom binary tree built with the child-sibling technique, and book search by ISBN is solved through a self-balancing AVL tree fully developed by the student, without relying on generic collections or native language structures. The system receives XML configuration files incrementally, exposes its functionality through an ASP.NET Core MVC web interface, and generates graphical representations of the catalog using Graphviz.
Palabras Clave
Keywords
1. Programación 2. Objetos 3. Árboles 4. Catálogo 5. Grafos
1. Programming 2. Objects 3. Trees 4. Catalog 5. Graphs
Universidad de San Carlos de Guatemala Escuela de Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026.
Introducción El curso Introducción a la Programación y Computación 2 plantea, mediante el Proyecto 2, el desarrollo de un sistema completo para administrar el catálogo de una cadena de librerías, combinando programación orientada a objetos, estructuras de datos no lineales construidas manualmente, consumo de archivos XML y una interfaz web funcional. El problema exige organizar la información de forma jerárquica, análoga a un organigrama o a un sistema de carpetas, y garantizar tiempos de búsqueda reducidos aun cuando el catálogo crezca a miles de registros distribuidos en distintas sucursales. El presente informe explica, con el mayor detalle posible, las decisiones técnicas tomadas para resolver este problema respetando la restricción central del enunciado: no utilizar ninguna colección genérica, arreglo, matriz ni tipo genérico propio del lenguaje C#. Toda la información del sistema se almacena en Tipos de Datos Abstractos desarrollados enteramente por el estudiante, cada uno implementado de forma específica para su tipo de dato, sin recurrir siquiera a clases genéricas propias, ya que la restricción alcanza también al uso de la palabra reservada generic dentro del propio código del estudiante. A lo largo del documento se describe primero el modelo del dominio y la técnica utilizada para representar jerarquías arbitrarias mediante un árbol estrictamente binario; después se detalla el árbol AVL construido para la búsqueda eficiente de libros, incluyendo el análisis de su complejidad algorítmica; a continuación se explica la lectura incremental de archivos XML y la estrategia utilizada para resolver dependencias entre categorías sin importar el orden de aparición en el archivo; luego se describe la arquitectura de la interfaz web y su integración con Graphviz; y finalmente se resume el proceso de desarrollo, control de versiones, validación funcional del sistema y las limitaciones identificadas. Este enfoque de documentación busca, además de cumplir con el requisito académico del curso, dejar constancia razonada de cada decisión de diseño tomada durante el desarrollo, de manera que puedan justificarse ante el auxiliar del curso tanto las estructuras de datos elegidas como los algoritmos implementados para cada una de las funcionalidades que exige el enunciado del Proyecto 2. 1. Diseño Orientado a Objetos del Modelo del Dominio El modelo del dominio se organiza alrededor de dos entidades principales. La clase Libro concentra un ISBN entero que actúa como identificador único, un título, un autor y el nombre de la categoría a la que pertenece. Se decidió
almacenar el nombre de la categoría como una cadena de texto dentro del propio Libro, en lugar de una referencia directa al objeto Categoria, para que la lectura del archivo XML pudiera construir primero el objeto Libro de forma independiente, y que fuera la clase Catalogo, que sí conoce el árbol completo de categorías, la responsable de resolver y enlazar esa referencia al momento del registro. La clase Categoria representa tanto una categoría principal como cualquier subcategoría dentro del árbol jerárquico, y encapsula su nombre, una referencia a su categoría padre, y la lista de libros que le pertenecen directamente. Esta separación entre 'libros que pertenecen directamente a una categoría' y 'libros que pertenecen a toda la subrama' fue una decisión de diseño explícita: el enunciado pide identificar los libros de una categoría determinada, y se interpretó que dicha categoría corresponde exactamente al valor indicado en el campo categoria de cada libro dentro del XML, sin necesidad de acumular recursivamente los libros de las subcategorías. 1.1. Técnica Hijo-Hermano Dado que una categoría puede tener una cantidad arbitraria de subcategorías, pero el diseño debía mantenerse estrictamente binario —es decir, cada nodo solo puede tener dos referencias—, se optó por la técnica de árbol binario conocida como hijo-hermano (child-sibling). Cada nodo Categoria conserva únicamente dos referencias adicionales a su nombre y a su padre: PrimerHijo, que apunta a la primera subcategoría registrada bajo ese nodo, y SiguienteHermano, que apunta a la siguiente categoría dentro del mismo nivel jerárquico. De esta manera, cualquier cantidad de subcategorías bajo un mismo padre se recorre siguiendo la cadena de hermanos a partir del primer hijo, sin necesidad de una lista de hijos independiente ni de un arreglo de tamaño variable. Por ejemplo, si la categoría Ficción tiene tres subcategorías —Aventura, Fantasía y Terror—, el nodo Ficción solamente guarda una referencia a PrimerHijo apuntando a Aventura (la primera en orden alfabético), y el nodo Aventura guarda en SiguienteHermano una referencia a Fantasía, que a su vez apunta a Terror mediante su propio SiguienteHermano. Recorrer todas las subcategorías de Ficción consiste, entonces, en partir de PrimerHijo y avanzar repetidamente por SiguienteHermano hasta llegar a una referencia nula. Al insertar una nueva subcategoría, esta se ubica en su posición alfabética dentro de la cadena de hermanos, comparando su nombre con el de los hermanos existentes hasta encontrar la posición correcta, e insertando el nuevo nodo entre el hermano anterior y el siguiente. Esto cumple con el requisito de que las categorías se presenten siempre
Universidad de San Carlos de Guatemala Escuela de Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026.
ordenadas alfabéticamente, sin necesidad de un paso de ordenamiento posterior sobre una colección completa.
un árbol balanceado para la búsqueda rápida sobre el catálogo completo.
1.2. Raíz Virtual
2.1. Árbol AVL para Búsqueda Eficiente
Como el enunciado permite varias categorías principales sin padre, la clase Catalogo mantiene una raíz virtual e invisible, identificada internamente con un nombre reservado, cuyo único propósito es servir de punto de entrada común para todas las categorías principales, que se comportan como hermanas entre sí bajo esa raíz. Esta raíz nunca se expone al usuario final ni aparece en ninguna de las vistas de la interfaz web; su función es puramente estructural, evitando que el sistema tuviera que manejar un caso especial para 'no tener raíz'.
Para resolver la búsqueda de un libro por su ISBN, obtener el libro con el código menor y el mayor, y mostrar el catálogo en orden ascendente, se implementó un árbol AVL —un Árbol Binario de Búsqueda que se autobalancea— indexado por el valor entero del ISBN. Cada nodo NodoAVL conserva, además del libro y sus dos referencias a los subárboles izquierdo y derecho, su propia altura. Tras cada inserción o eliminación se recalcula el factor de balance del nodo afectado, definido como la diferencia entre la altura del subárbol izquierdo y la del subárbol derecho.
1.3. Búsqueda Recursiva de Categorías
Cuando ese factor de balance excede el rango permitido de 1 a 1, se aplica una de las cuatro rotaciones clásicas: rotación simple a la derecha, cuando el desbalance ocurre hacia la izquierda del hijo izquierdo (caso izquierda-izquierda); rotación simple a la izquierda, cuando ocurre hacia la derecha del hijo derecho (caso derecha-derecha); y dos rotaciones dobles —izquierda-derecha y derecha-izquierda— para los casos en que el desbalance se produce en zigzag entre ambos subárboles. Estas rotaciones reorganizan un número constante de referencias, por lo que su costo es O(1), y como a lo sumo se aplican en cada nivel del camino de inserción, el costo total de mantener el árbol balanceado tras una operación es O(log n).
Dado que el árbol de categorías no mantiene ningún índice adicional, la búsqueda de una categoría por nombre se resuelve mediante un recorrido recursivo en preorden sobre la estructura hijo-hermano: se compara el nombre del nodo actual, y si no coincide, se busca primero en todo el subárbol de PrimerHijo y, si no se encuentra ahí, se continúa la búsqueda en SiguienteHermano. Esta misma función recursiva es la base tanto para registrar una nueva categoría —verificando que su nombre no exista ya en cualquier parte del árbol, como exige el enunciado— como para resolver la categoría padre indicada al registrar un libro. 2. Tipos de Datos Abstractos Propios Dado que el enunciado prohíbe expresamente cualquier estructura genérica —incluyendo listas, pilas, colas o diccionarios propios de C#, así como cualquier clase o método genérico escrito por el propio estudiante—, se construyó, para cada entidad que lo requería, una pareja de clases específica: un nodo que almacena un dato de tipo concreto y una referencia al siguiente, y una estructura contenedora que administra la cabeza y las operaciones de agregar, eliminar y buscar. Así, el sistema cuenta con NodoLibro y ListaLibros, utilizados dentro de cada Categoria para almacenar los libros que le pertenecen directamente, y con NodoAVL y ArbolAVL, utilizados por el Catalogo para indexar todos los libros del sistema por su ISBN. Esta restricción, lejos de ser solo una limitación arbitraria, obliga a razonar con mayor profundidad sobre qué estructura es la más adecuada para cada necesidad concreta del problema, en lugar de recurrir por defecto a una colección genérica de propósito general. El resultado es un diseño donde cada estructura de datos está pensada exactamente para el tipo de acceso que necesita: una lista simple para recorrer secuencialmente los pocos libros de una categoría, y
Gracias a este balanceo constante, la altura del árbol se mantiene siempre en el orden de log₂(n), lo que garantiza que la búsqueda, inserción y eliminación se resuelvan en tiempo logarítmico incluso cuando el catálogo crece a los miles de libros que exige el enunciado, en contraste con un árbol binario de búsqueda simple, cuya altura podría degenerar en O(n) si los libros se insertaran en un orden desfavorable, por ejemplo, si los archivos XML de entrada trajeran los ISBN ya ordenados de forma ascendente o descendente. 2.2. Recorridos y Aprovechamiento del Orden Natural Una ventaja adicional del árbol AVL es que su recorrido inorder —visitar primero el subárbol izquierdo, luego el nodo actual y finalmente el subárbol derecho— entrega los libros ya ordenados de forma ascendente por ISBN, sin necesidad de una fase de ordenamiento adicional. Este mismo recorrido, filtrado por el nombre de la categoría de cada libro, es el mecanismo utilizado para mostrar los libros de una categoría específica en orden ascendente, reutilizando una sola estructura y un solo algoritmo de recorrido para resolver dos requerimientos distintos del enunciado: el orden ascendente global del catálogo y el orden ascendente dentro de una categoría. 2.3. Política ante ISBN Duplicados
Universidad de San Carlos de Guatemala Escuela de Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026.
En caso de que el archivo de entrada contenga dos libros con el mismo ISBN, el sistema descarta el registro duplicado en lugar de sobrescribir la información existente, y reporta la situación como una advertencia en el resultado de la carga, sin detener el procesamiento del resto del archivo. Este comportamiento no estaba especificado de forma explícita en el enunciado original, por lo que se confirmó directamente con el auxiliar del curso a través de una consulta en el foro de la UEDI, quien indicó que, dado que el ISBN representa un valor entero único, deben descartarse los duplicados para mantener la integridad del catálogo. La misma política se aplica cuando el usuario intenta registrar manualmente, desde la interfaz web, un libro con un ISBN ya existente. 2.4. Ejemplo de Inserción con Rotación Para ilustrar el funcionamiento del rebalanceo, supóngase que se insertan de forma sucesiva los libros con ISBN 30, 20 y 10, en ese orden, sobre un árbol AVL inicialmente vacío. Tras insertar 30 y 20, el árbol queda con 30 como raíz y 20 como su hijo izquierdo, con un factor de balance de 1, todavía dentro del rango permitido. Al insertar 10, este se ubica como hijo izquierdo de 20, formando una cadena descendente hacia la izquierda —el caso izquierdaizquierda—, y el factor de balance de la raíz 30 se eleva a 2, superando el límite permitido. En ese momento se aplica una rotación simple a la derecha sobre el nodo 30: el nodo 20 asciende a la posición de raíz, 10 permanece como su hijo izquierdo, y 30 pasa a ser su hijo derecho, devolviendo el árbol a un estado balanceado con una altura mínima. 2.5. Complejidad Comparada Resulta ilustrativo comparar la complejidad del árbol AVL frente a la alternativa más simple de almacenar todo el catálogo en una lista enlazada. Buscar un libro por ISBN en una lista enlazada de n elementos requiere, en el peor caso, recorrer los n nodos de forma secuencial, es decir, un costo O(n); el mismo procedimiento sobre el árbol AVL cuesta, como se explicó, O(log n). Para un catálogo de 100,000 libros como el planteado en el enunciado, log₂(100000) es aproximadamente 17, frente a los 100,000 pasos que podría llegar a necesitar una búsqueda lineal en el peor caso, lo que evidencia de forma concreta por qué el enunciado exige explícitamente estructuras no lineales para esta parte del sistema. 3. Manipulación de Archivos XML La carga de información se realiza mediante la clase LectorXml, que utiliza la biblioteca estándar de .NET, System.Xml, exclusivamente como mecanismo de lectura del archivo; en ningún momento dicha biblioteca almacena la información del dominio, papel que corresponde íntegramente al Catalogo y a sus estructuras propias. El archivo de entrada define, bajo un nodo raíz config, una lista
de categorías —cada una con un nombre y, opcionalmente, el nombre de su categoría padre a través del atributo padre— y una lista de libros independiente, ambas opcionales, ya que el archivo puede cargarse de forma incremental en varias ejecuciones sucesivas, agregando nuevas categorías y nuevos libros sin alterar lo que ya existía en el catálogo. 3.1. Resolución en Varias Pasadas Debido a que el enunciado no garantiza que una categoría padre aparezca antes que su hija dentro del mismo archivo, el procesamiento de categorías se realiza en varias pasadas sobre la misma lista: en cada pasada se registran únicamente las categorías cuyo padre ya existe en el catálogo en ese momento, y el proceso se repite hasta que una pasada completa no logre agregar ninguna categoría nueva. De esta manera, el orden de aparición en el XML deja de ser una restricción para quien construye el archivo de entrada, y el sistema es capaz de resolver correctamente jerarquías profundas independientemente de en qué orden se hayan escrito las etiquetas categoria. Si, después de todas las pasadas, alguna categoría sigue sin poder agregarse —por ejemplo, porque su padre nunca aparece en el archivo, porque el nombre ya estaba en uso, o porque existiera una referencia circular entre categorías—, dicha categoría se reporta como advertencia en el resultado de la carga, sin interrumpir el procesamiento de las demás categorías ni de la lista de libros. 4. Interfaz Web con ASP.NET Core MVC La interfaz se desarrolló como una aplicación ASP.NET Core MVC, siguiendo el patrón Modelo-Vista-Controlador exigido por el enunciado. Una instancia única de la clase Catalogo se registra como servicio singleton dentro del contenedor de inyección de dependencias de ASP.NET Core, de modo que los cuatro controladores del sistema — HomeController, ArchivoController, CategoriaController y LibroController— comparten en todo momento el mismo catálogo en memoria durante toda la ejecución del servidor, sin necesidad de una base de datos ni de serializar el estado entre peticiones. 4.1. Responsabilidades de cada Controlador HomeController resuelve la inicialización del sistema, reemplazando las estructuras internas del catálogo por unas nuevas y vacías, y la sección de ayuda, con la información del estudiante y el enlace a la documentación completa. ArchivoController gestiona la carga de archivos XML: recibe el archivo subido por el usuario, lo guarda temporalmente en disco y delega su procesamiento a LectorXml, mostrando después un resumen con la cantidad de categorías y libros agregados, junto con cualquier advertencia registrada.
Universidad de San Carlos de Guatemala Escuela de Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026.
CategoriaController expone la visualización de la estructura jerárquica —completa o a partir de una subcategoría específica indicada por el usuario—, el alta de nuevas categorías validando que el nombre no exista y que la categoría padre, si se indica, sí exista, y la generación del gráfico de Graphviz con los libros de una categoría en orden ascendente. LibroController concentra el registro de nuevos libros, la eliminación por ISBN, la búsqueda de un libro específico por su código, y la consulta del libro con el ISBN menor y el mayor de todo el catálogo. 4.2. Persistencia en Memoria Al no existir una base de datos, toda la información del catálogo vive exclusivamente en memoria mientras el proceso del servidor está en ejecución. Esta decisión, coherente con el uso de estructuras dinámicas propias como eje central del proyecto, implica que reiniciar el servidor equivale a inicializar el sistema sin información previa, y que la carga de archivos XML al arrancar la aplicación es, en la práctica, el mecanismo principal para poblar el catálogo antes de las pruebas manuales realizadas a través del navegador. 5. Representación Gráfica con Graphviz La clase GeneradorDot construye, a partir del catálogo, el texto en formato DOT —el lenguaje de descripción de grafos que interpreta Graphviz— correspondiente tanto a la estructura de categorías como a los libros de una categoría específica. Para este último caso, se aprovecha que el recorrido in-order del árbol AVL ya entrega los libros en orden ascendente de ISBN, por lo que basta con filtrar dicho recorrido por el nombre de la categoría solicitada para obtener, sin pasos adicionales, la secuencia de nodos conectados que exige el enunciado. 5.1. De DOT a Imagen La clase EjecutorGraphviz guarda ese texto en un archivo .dot temporal dentro del servidor, e invoca directamente, mediante la clase Process de .NET, el ejecutable dot de Graphviz instalado en el sistema operativo, indicándole que produzca una imagen en formato PNG a partir de ese archivo. El resultado se guarda dentro de la carpeta pública wwwroot de la aplicación web, y finalmente se muestra dentro de la vista correspondiente mediante una etiqueta de imagen estándar de HTML, sin que el usuario final necesite interactuar en ningún momento con Graphviz de forma directa. 4.3. Manejo de Errores y Validaciones Cada acción expuesta por la interfaz web valida sus datos de entrada antes de modificar el catálogo, y comunica el resultado mediante mensajes claros en pantalla, en lugar de dejar que una excepción interrumpa la ejecución del servidor.
Registrar una categoría con un nombre ya existente, registrar un libro con un ISBN repetido o con una categoría inexistente, eliminar un libro con un ISBN que no está en el catálogo, o buscar un ISBN inexistente son todos casos contemplados explícitamente, devolviendo en cada caso un mensaje descriptivo del motivo por el cual la operación no pudo completarse, sin afectar el resto de la información ya almacenada en el catálogo. 6. Proceso de Desarrollo y Control de Versiones El desarrollo del proyecto se organizó en cuatro entregas incrementales sobre un repositorio de GitHub, siguiendo la restricción del curso de documentar el avance continuo mediante releases. La primera entrega incluyó los Tipos de Datos Abstractos base del modelo (Libro, ListaLibros, Categoria y ArbolAVL) junto con la clase Catalogo que los coordina; la segunda incorporó la lectura incremental de archivos XML; la tercera integró la interfaz web completa, con sus cuatro controladores y la generación de gráficos con Graphviz; y la cuarta y última entrega corresponde a la validación funcional exhaustiva del sistema y a la documentación final. Durante el desarrollo se aplicaron de forma estricta las restricciones adicionales indicadas por el auxiliar del curso: prohibición total de estructuras genéricas o nativas de C#, obligatoriedad de que las estructuras de datos requeridas fueran no lineales, y uso exclusivo de la plantilla de ASP.NET Core MVC para la interfaz, descartando cualquier alternativa basada en Windows Forms o en páginas HTML sueltas fuera de dicha estructura. Cada una de las cuatro entregas se documentó mediante un mensaje de commit descriptivo y un release independiente en GitHub, de manera que el historial del repositorio reflejara de forma verificable el avance incremental del proyecto semana a semana, tal como lo exige el enunciado del curso, en lugar de concentrar todo el desarrollo en una única entrega de último momento. 7. Pruebas y Validación del Sistema Antes de la entrega final, el sistema se sometió a una batería de pruebas manuales a través de la interfaz web, utilizando un archivo XML de prueba con categorías anidadas en varios niveles y libros con ISBN intencionalmente desordenados. Se verificó, entre otros casos: la inicialización del sistema sin información previa; la carga de un archivo XML completo y su carga incremental posterior mediante un segundo archivo; la visualización de la estructura completa de categorías y desde una subcategoría específica, confirmando el orden alfabético; la generación correcta del gráfico de Graphviz para los libros de una categoría, verificando que aparecieran en orden ascendente de ISBN aunque en el archivo de origen
Universidad de San Carlos de Guatemala Escuela de Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026.
estuvieran en otro orden; la consulta del libro con ISBN menor y mayor; la búsqueda de un libro existente y de uno inexistente; la eliminación de un libro y la confirmación de que el árbol AVL se reequilibrara correctamente; y finalmente, los casos de error controlados al intentar agregar una categoría con nombre repetido o con un padre inexistente, y al intentar registrar un libro con un ISBN repetido o con una categoría inexistente. En todos los casos, el sistema respondió con el comportamiento esperado, sin interrupciones ni excepciones no controladas. 8. Limitaciones y Trabajo Futuro El sistema desarrollado almacena el catálogo exclusivamente en memoria, por lo que la información se pierde al detener el servidor, a menos que se vuelvan a cargar los archivos XML de entrada. Una extensión natural del proyecto sería incorporar persistencia en disco, ya sea regenerando los mismos archivos XML de salida o mediante un formato binario propio, de manera que el catálogo sobreviva a reinicios del servidor sin depender de una base de datos externa, que el enunciado no exige. Asimismo, la generación de imágenes con Graphviz depende de que el ejecutable dot esté instalado y accesible en el sistema operativo donde corre el servidor, lo que representa una dependencia externa a tener en cuenta al desplegar la aplicación en un entorno distinto al de desarrollo. Conclusiones 1. La restricción de no utilizar colecciones ni tipos genéricos obligó a diseñar Tipos de Datos Abstractos específicos para cada tipo de dato, resultando en una arquitectura explícita y completamente trazable a memoria dinámica administrada manualmente por el estudiante, en lugar de depender de estructuras de propósito general provistas por el framework. 2. La técnica de árbol binario hijo-hermano demostró ser una solución elegante y eficiente en memoria para representar una jerarquía con una cantidad arbitraria de hijos por nodo, cumpliendo con la restricción de mantener una estructura estrictamente binaria sin sacrificar la semántica de una jerarquía real de categorías y subcategorías. 3. El uso de un árbol AVL autobalanceado, en lugar de un árbol binario de búsqueda simple, garantiza que el sistema mantenga tiempos de búsqueda del orden de log(n) de forma consistente, sin depender del orden en que se registren los libros, cumpliendo así el requisito de eficiencia aun cuando el catálogo crezca significativamente. 4. Reutilizar el recorrido in-order del árbol AVL, tanto para el orden ascendente global como para el orden ascendente por categoría, evidenció el valor de elegir estructuras de datos cuyas propiedades intrínsecas resuelvan directamente varios requerimientos del problema, en lugar de
implementar mecanismos de ordenamiento independientes para cada caso. 5. La combinación de una interfaz web ASP.NET Core MVC con la generación dinámica de imágenes mediante Graphviz permite comunicar de forma visual e inmediata resultados que, de otra manera, solo podrían describirse textualmente, integrando una herramienta externa de forma robusta dentro del flujo completo de la aplicación. 6. Las pruebas manuales sistemáticas, realizadas antes de la entrega final, resultaron fundamentales para confirmar que las estructuras de datos propias se comportaran correctamente ante casos borde —duplicados, referencias inexistentes, eliminaciones que requieren rebalanceo—, casos que en una prueba superficial fácilmente podrían pasar desapercibidos. 7. Aunque el sistema cumple con la totalidad de los requerimientos funcionales del enunciado, la ausencia de persistencia en disco queda identificada como la principal limitación del proyecto en su estado actual, y constituye la extensión más natural para una futura versión del sistema. Referencias Bibliográficas Cormen, T. H., Leiserson, C. E., Rivest, R. L., & Stein, C. (2009). Introduction to Algorithms (3.ª ed.). MIT Press. Microsoft. (s.f.). Introducción a ASP.NET Core. Obtenido de Microsoft Learn: https://learn.microsoft.com/aspnet/core/introductionto-aspnet-core Microsoft. (s.f.). Dependency injection in ASP.NET Core. Obtenido de Microsoft Learn: https://learn.microsoft.com/aspnet/core/fundamentals/d ependency-injection Microsoft. (s.f.). XmlDocument Class. Obtenido de Microsoft Learn: https://learn.microsoft.com/dotnet/api/system.xml.xml document Graphviz. (s.f.). Graphviz Documentation. Obtenido de https://graphviz.org/documentation/ SoyHenry. (10 de Febrero de 2022). Estructura de datos en programación. Obtenido de SoyHenry: https://blog.soyhenry.com/que-es-una-estructura-dedatos-en-programacion/ Takeyas, B. L. (2012). Estructura de Datos Orientados a Objetos: Pseudocódigo y Aplicaciones en C#. Net. México: Alfa Omega. Weiss, M. A. (2013). Data Structures and Algorithm Analysis in C++ (4.ª ed.). Pearson. Anexos 1. Tabla de Actividades
Universidad de San Carlos de Guatemala Escuela de Ciencias y Sistemas, Facultad de Ingeniería Introducción a la Programación y Computación 2, 2do. Semestre 2026. Semana
Actividad
Semana 1
TDAs propios (ListaLibros, Categoria con técnica hijo-hermano, ArbolAVL) y clase Catalogo.
Semana 2
Lectura incremental de archivos XML de entrada, resolviendo categorías en varias pasadas.
Semana 3
Interfaz web con ASP.NET Core MVC e integración con Graphviz.
Semana 4
Pruebas funcionales, documentación, diagramas y entrega final en GitHub. Tabla 1. Cronograma de Actividades Fuente: Elaboración Propia
2. Diagrama de Clases
Figura 2. Estructura Jerárquica de Categorías Fuente: Elaboración Propia
Figura 3. Libros de una Categoría en Orden Ascendente de ISBN Fuente: Elaboración Propia
Figura 1. Diagrama de Clases
3. Representación Gráfica con Graphviz