Implementación de un Manejador Gráfico de Decisiones para ...
86
Implementación de un Manejador Gráfico de Decisiones para un Simulador de Juego Empresarial Daniel Tovar Mikan 200521454 Jesús Alfonso Vargas Sánchez 200621838 Universidad de los Andes Facultad de Ingeniería Departamento de Ingeniería de Sistemas y Computación Bogotá D.C. 2010
Transcript of Implementación de un Manejador Gráfico de Decisiones para ...
Implementación de un Manejador Gráfico de
Decisiones para un Simulador de Juego
Empresarial
Daniel Tovar Mikan 200521454
Jesús Alfonso Vargas Sánchez 200621838
Universidad de los Andes
Facultad de Ingeniería
Departamento de Ingeniería de Sistemas y Computación
Bogotá D.C.
2010
ii
PROYECTO DE GRADO Trabajo de grado para optar por el título de Ingenieros de Sistemas y Computación
Por:
Daniel Tovar Mikan 200521454
Jesús Alfonso Vargas Sánchez 200621838
Asesores:
Rubby Casallas Gutiérrez PhD. Profesora Asociada
Rafael Gustavo Meneses Ramírez M.Sc. Instructor
iii
Listado de Figuras
Figura 3-1: QtDesigner para construcción de un dialogo 10
Figura 3-2: Opciones de visualización del QtDesigner 10 Figura 3-3: Qt Widgets 11 Figura 5-1: Parámetros de una Decisión 14
Figura 5-2: Filtro de un Parámetro 15 Figura 5-3: Fórmula 16 Figura 5-4: Transacciones Contables y Operativas 17
Figura 5-5: Casos de Uso 18 Figura 6-1: Patrón Observador del manejador de decisiones 28 Figura 6-2: Modelo de propiedades BaseModel aplicado a la clase Parameter 29
Figura 6-3: DecisionManager con manejadores específicos 30 Figura 6-4: Diseño Manejador de Parámetros 31 Figura 6-5: Diseño Manejador de Fórmulas 32
Figura 6-6: Diseño Manejador de Cómputos 33 Figura 6-7: Diseño Manejador de transacciones contables 34 Figura 6-8: Diseño Manejador de transacciones operativas 35
Figura 6-9: Diseño Generador de archivos MAGES 36 Figura 6-10: Diseño Lector de Metamodelo Entidad-Relación 37 Figura 6-11: Diagrama de Componentes Manejador de Decisiones 38
Figura 6-12: Diseño de QWidgets extendidos 39 Figura 6-13: Panel genérico para manejo de tablas 40 Figura 6-14: Diseño panel genérico para el manejo de tablas 41
Figura 6-15: Diseño GUI Manejador de Decisiones 42 Figura 6-16: Diseño panel contenedor de parámetros 43 Figura 6-17: Diseño panel contenedor de fórmulas 44
Figura 6-18: Diseño panel contenedor de cómputos 45 Figura 6-19: Diseño panel de transacciones contables 46 Figura 6-20: Diseño panel de transacciones operativas 47
Figura 6-21: Diseño diálogo para navegación del modelo del Juego Gerencial 48 Figura 6-22: Diseño de diálogo para crear y modificar filtros 49 Figura 6-23: Diseño de diálogo para selección de parámetros 50
Figura 6-24: Diseño diálogo para selección de cuentas 51 Figura 7-1: Introducir datos básicos de una decisión 52 Figura 7-2: Creación de un parámetro simple 53
Figura 7-3: Configuración de un parámetro simple ya creado 54 Figura 7-4: Configuración de un parámetro tipo filtro 54 Figura 7-5: Diálogo de navegación del modelo del Juego Gerencial 55
Figura 7-6: Definición de un Filtro 55 Figura 7-7: Configuración de una fórmula tipo search 56 Figura 7-8: Creación de cómputos para una decisión 57 Figura 7-9: Adición de transacciones contables 58
Figura 7-10: Diálogo para seleccionar una cuenta 58 Figura 7-11: Creación de movimientos operativos 59
iv
Figura 7-12: Generar archivos con sintaxis Mages 60 Figura 7-13: Guardar una decisión para su futura modificación 61 Figura 7-14: Selección de archivo con extensión .decis 61
Figura 7-15: Tiempo dedicado a la implementación 64
v
Resumen
En el marco del Juego Gerencial los estudiantes del curso toman una serie de decisiones
para guiar la evolución de una empresa. Cada decisión es previamente definida por un
profesor que las pone a disposición de los estudiantes. Tanto el profesor como los
estudiantes utilizan una herramienta que sirve como apoyo al curso. En ella, los estudiantes
pueden monitorear el estado de sus organizaciones y tomar las decisiones sobre éstas que
consideren necesarias. Para incorporar una decisión a dicha herramienta, se requiere de
varios interlocutores, entre los que se incluyen programadores encargados de hacer la
traducción a código de los requerimientos que exige el profesor. Esto presenta una
complicación y a la vez una oportunidad para plantear una solución. Es sobre esta
problemática que se basa el desarrollo del manejador de decisiones.
La solución que se propuso fue la implementación de una aplicación stand-alone encargada
de optimizar la manera en que se define una decisión. Ésta debía ser modificable, fácil de
comprender, amigable al usuario y manejarse de forma similar a las herramientas ya
conocidas por los usuarios. Teniendo en cuenta los anteriores requerimientos se planteó
para este proyecto la creación de una interfaz gráfica que guíe al usuario en la definición de
los conceptos de una decisión. Para que el usuario tenga un cierto grado de afinidad con la
aplicación se desarrolló una interfaz gráfica con tablas similares a las hojas de cálculo de
MS Excel. Ésta es empleada a diario por los profesores del curso del Juego Gerencial;
potenciales usuarios de este programa. Para ello, en las fases iniciales del proyecto se
investigó una librería que permite la creación de tablas con múltiples funcionalidades y
elementos gráficos agradables a la vista.
Durante el proceso de desarrollo se toman diferentes decisiones de diseño con el fin de
favorecer la usabilidad y modificabilidad de la aplicación. Las cuales, se tienen en cuenta
tanto en la lógica del manejador de decisiones como en la interfaz gráfica. Esta última se
diseñó presentándole al usuario la definición de una decisión en diferentes secciones. Cada
una de éstas se encarga de mostrar una serie de elementos relacionados, con el fin de
brindarle la mayor comodidad al usuario a la hora de plantear su definición. Una vez la
decisión se haya construido, la aplicación se encarga del procesamiento de estos datos para
generar los archivos de salida. Estos archivos se basan en el MAGES-DL: lenguaje de
dominio específico que puede ser transformado para ser utilizado por la herramienta del
juego gerencial. Así se agregaría directamente una decisión a ésta, sin necesidad de los
intermediarios antes descritos.
vi
Contenido
1 INTRODUCCIÓN 1
1.1 DESCRIPCIÓN DEL PROBLEMA 1 1.2 MOTIVACIÓN 2 1.3 ORGANIZACIÓN DEL DOCUMENTO 3
2 OBJETIVOS 4
2.1 OBJETIVOS GENERALES 4 2.2 OBJETIVOS ESPECÍFICOS 4
3 MARCO TEÓRICO 6
3.1 METAMODELOS Y MODELOS 6 3.1.1 ¿QUÉ ES UN MODELO? 6 3.1.2 METAMODELOS Y SU RELACIÓN CON LOS MODELOS 7 3.2 QT JAMBI 8 3.2.1 HERRAMIENTA DE DESARROLLO QT 8 3.2.2 GUI TOOLKITS 9
3.2.3 ¿QUÉ SON LOS QWIDGETS? 11 3.2.4 MANEJO DE EVENTOS EN QT JAMBI 11
4 METODOLOGÍA DE TRABAJO 13
5 ANÁLISIS DE REQUERIMIENTOS 14
5.1 ESTRUCTURA DE UNA DECISIÓN 14 5.2 REQUERIMIENTOS FUNCIONALES 18 5.2.1 CREAR UNA DECISIÓN 18 5.2.2 GUARDAR UNA DECISIÓN 19
5.2.3 ABRIR UNA DECISIÓN 19 5.2.4 MODIFICAR UNA DECISIÓN 19 5.2.5 GENERAR ARCHIVO MAGES 19 5.3 ATRIBUTOS DE CALIDAD 20 5.3.1 USABILIDAD 20 5.3.2 MODIFICABILIDAD 21 5.4 ESCENARIOS DE CALIDAD 22
5.4.1 ESCENARIOS DE USABILIDAD 22 5.4.2 ESCENARIOS DE MODIFICABILIDAD 23
6 DISEÑO 27
vii
6.1 JUSTIFICACIONES DE DISEÑO 27 6.1.1 SEPARACIÓN EN MANEJADORES DE MENOR TAMAÑO 27 6.1.2 IMPLEMENTACIÓN CLASES OBSERVABLES Y OBSERVADORES 28 6.1.3 MODELO DE PROPIEDADES 28 6.2 DIAGRAMAS DE CLASE 29 6.2.1 MANEJADOR DE DECISIONES Y MANEJADORES SUBORDINADOS 29
6.2.2 MANEJADOR DE PARÁMETROS 31 6.2.3 MANEJADOR DE FÓRMULAS 32 6.2.4 MANEJADOR DE CÓMPUTOS 33 6.2.5 MANEJADOR DE TRANSACCIONES CONTABLES 34 6.2.6 MANEJADOR DE TRANSACCIONES OPERATIVAS 35 6.2.7 GENERADOR ARCHIVOS MAGES 36 6.2.8 LECTOR DE METAMODELO ENTIDAD-RELACIÓN 37
6.3 MODELO DE COMPONENTES 37 6.4 JUSTIFICACIONES DE DISEÑO INTERFAZ GRÁFICA 38 6.4.1 EXTENSIÓN DE COMPONENTES GRÁFICOS QT JAMBI 38 6.4.2 PANEL GENÉRICO PARA USO DE TABLAS 40 6.5 DIAGRAMAS DE CLASE INTERFAZ DE USUARIO 42 6.5.1 INTERFAZ DE USUARIO MANEJADOR DE DECISIONES 42 6.5.2 PANEL DE PARÁMETROS 43
6.5.3 PANEL DE FÓRMULAS 44 6.5.4 PANEL DE CÓMPUTOS 45 6.5.5 PANEL DE TRANSACCIONES CONTABLES 46 6.5.6 PANEL DE TRANSACCIONES OPERATIVAS 47 6.5.7 DIALOGO PARA NAVEGACIÓN DEL MODELO DEL JUEGO GERENCIAL 48 6.5.8 DIÁLOGO PARA CREACIÓN Y MODIFICACIÓN DE FILTROS 49 6.5.9 DIÁLOGO PARA SELECCIÓN DE PARÁMETROS 49 6.5.10 DIÁLOGO PARA SELECCIÓN DE CUENTAS 50
7 PRODUCTO DESARROLLADO 52
7.1 ALCANCE OBTENIDO 52 7.1.1 DATOS BÁSICOS DE UNA DECISIÓN 52 7.1.2 CREACIÓN DE PARÁMETROS SIMPLES 53 7.1.3 CREACIÓN DE PARÁMETROS FILTRO 53 7.1.4 DECLARACIÓN DE FÓRMULAS 56 7.1.5 ORDENAMIENTO DE CÓMPUTOS 56
7.1.6 DEFINICIÓN DE TRANSACCIONES CONTABLES 57 7.1.7 DEFINICIÓN DE TRANSACCIONES OPERATIVAS 59 7.1.8 GENERAR ARCHIVOS MAGES 59 7.1.9 GUARDAR LA DECISIÓN 60 7.1.10 ABRIR LA DECISIÓN 60 7.2 MÉTRICAS 62 7.2.1 TAMAÑO DEL PRODUCTO 62
7.2.2 MÉTRICAS DE PRODUCTIVIDAD 63 7.2.3 COMPLEJIDAD CICLOMÁTICA 64
8 PRUEBAS 66
viii
8.1 DESCRIPCIÓN DE PRUEBAS 66 8.1.1 PRUEBAS UNITARIAS: MANEJADORES DE PARÁMETROS Y FÓRMULAS 66 8.1.2 PRUEBAS DE INTEGRACIÓN: MANEJADOR DE CÓMPUTOS 68 8.1.3 PRUEBAS VARIAS: MANEJADOR DE TRANSACCIONES CONTABLES 70 8.1.4 PRUEBAS DE INTEGRACIÓN: MANEJADOR DE TRANSACCIONES OPERATIVAS 71 8.1.5 PRUEBAS DE SISTEMA 72
8.2 EJECUCIÓN DE PRUEBAS 73
9 CONCLUSIONES 74
9.1 DISCUSIÓN 74 9.2 TRABAJO FUTURO 75
10 REFERENCIAS 77
1 Introducción
En el contexto del curso de Juego Gerencial se propone un marco de experimentación para
la toma de decisiones en un entorno simulado. En él se establece un espacio en que los
estudiantes experimentan la toma de decisiones, el respectivo análisis de sus resultados y la
dirección de las diferentes áreas funcionales de una organización. El desarrollo del curso se
divide en dos momentos: en primer lugar se da una etapa de concepción y especificación de
la empresa en la que se establece su estrategia global y funcional. La segunda etapa hace
referencia a la toma de decisiones cada cierto tiempo para simular la evolución de la
empresa en un ambiente de competencia [Fac10]. En esta segunda etapa del curso se
definen periodos en que los grupos corporativos toman decisiones de negocio que impactan
su participación en el mercado. Dichas decisiones son simuladas en un entorno de negocio
y al final del respectivo periodo el profesor evalúa las decisiones planeadas por cada uno de
los grupos corporativos. Así él establece la participación en el mercado de cada grupo
causada por las acciones tomadas durante el periodo [Jug10].
El curso utiliza una herramienta que apoya el proceso de simulación de las acciones
tomadas y que facilita el seguimiento de los grupos corporativos. En esta herramienta se le
facilita al profesor la definición del entorno de negocio y de las participaciones de mercado
de cada grupo al final de cada periodo. Por otra parte, los estudiantes que lo utilizan tienen
la posibilidad de obtener información sobre el estado de su grupo corporativo, su entorno
competitivo, y los resultados de su toma de decisiones, reflejados en los estados financiero
y operativo, al finalizar cada periodo [Jug10].
Esta herramienta ha sido desarrollada de forma incremental y posee oportunidades de
mejora en cuanto a la definición de las decisiones que se toman en el juego. En este aspecto
del Juego Gerencial se centra el actual documento como se verá a continuación.
1.1 Descripción del problema
En la actualidad, el profesor del curso concibe las decisiones que se podrán tomar en el
juego, pero el proceso de incorporarlas a la herramienta que se utiliza en el curso no es
totalmente automatizado. Existe un intermediario entre el profesor y el sistema del Juego
Gerencial, que posee los conocimientos para transformar la información sobre la decisión
definida por el profesor, en un formato de entrada compatible con el sistema. Esta
transformación se hace manualmente recibiendo los datos de la decisión en un archivo de
MS Excel que se acordaron en presencia del profesor, y transformándolos a un formato
XML. Este último sirve como entrada al sistema para que posteriormente los estudiantes
planeen la decisión que será ejecutada por el simulador del Juego Gerencial.
La oportunidad que surge como consecuencia de esto es definir un mecanismo en que el
mismo profesor pueda definir la decisión e incorporarla al sistema del Juego Gerencial sin
mayor necesidad de intermediarios. El producto a desarrollar debe cumplir con dos
necesidades cruciales: (1) Permitir modelar todos los conceptos de una decisión de tal
2
forma que se preserve la lógica que el profesor utiliza para definirla; (2) El producto
terminado debe ser amigable para el usuario, en el sentido de que utilizarlo sea
efectivamente más cómodo a como se ha venido realizando el proceso.
La solución a plantear debe afrontar esas dos situaciones y permitirle una adaptación
efectiva al profesor del curso. Para aplicar los conceptos y el proceso de definición de una
decisión a la aplicación que se busca desarrollar, se debería plantear una construcción
incremental de la decisión. En esta, se establecerían los elementos más básicos de la
decisión primero e ir construyendo elementos más complejos que los utilicen. En lo
referente a la visualización de la herramienta a desarrollar, se considera que la utilización
de tablas para los elementos de la decisión es lo más adecuado. Esto se debe a la
familiaridad del profesor con herramientas basadas en hojas de cálculo como MS Excel.
Así, se busca que el proceso para definir una decisión sea lo más similar a medios que el
profesor ha utilizado hasta el momento.
Una vez definida la decisión, debe ser posible exportarla de diferentes formas. Se espera
que esto se pueda hacer de dos maneras dependiendo del momento en el proceso de
definición de una decisión. Por un lado, se debe poder guardar una decisión de tal forma
que en un futuro pueda volver a ser abierta por el manejador de decisiones para su
consecuente edición. Esto solamente implica serializar todo el contenido que se tenga hasta
cierto punto y al momento de abrirla, que se despliegue el mismo contenido nuevamente en
la interfaz de usuario. Por otra parte, se generaría un archivo de texto con una sintaxis
específicamente diseñada para manejar información de una decisión. Este archivo
atravesaría una serie de transformaciones para luego procesarse directamente en la
herramienta del Juego Gerencial para incorporar la nueva decisión. Dicha sintaxis, parte del
lenguaje MAGES-DL, se definió en [Tel10], un proceso realizado paralelamente al del
manejador de decisiones que se trata en este documento.
1.2 Motivación
Desde la primera versión del sistema del Juego Gerencial se estableció que su diseño debía
favorecer la evolución del mismo. Inicialmente, se tenía un conjunto limitado de
decisiones, pero a futuro se debía contar con la flexibilidad adecuada para que un usuario
final pudiese definir nuevas decisiones y modelar la forma en que estas afectan los estados
de los grupos corporativos [Jug10]. En posteriores desarrollos del sistema se incorporó la
capacidad de especificar decisiones en un formato establecido e interpretable por los
componentes del sistema. Sin embargo este mecanismo, como se explicó anteriormente,
requiere de un intermediario que en principio puede evitarse. Así se aceleraría el proceso de
definición de una decisión, resultando en una menor dedicación en actividades
administrativas de un Juego Gerencial.
El manejador de decisiones forma parte de este proceso de crecimiento y mejora del
sistema de Juego Gerencial. Esta es una primera aproximación a la necesidad de proveer
herramientas para la definición de una decisión y su consecuente incorporación al sistema.
3
Como primera propuesta para solucionar dicha problemática, se busca que el producto
pueda evolucionar a futuro y que encapsule la lógica de una decisión de tal forma que
pueda ser modificada fácilmente. Así, se espera que otros desarrolladores puedan retomar el
producto y continuar realizando mejoras según las observaciones de profesores y personas
involucradas en el proyecto del Juego Gerencial.
1.3 Organización del documento
Este trabajo se enfoca en fundamentar y documentar el desarrollo de la aplicación para la
definición de decisiones. La secuencia de secciones de este documento viene definida por el
proceso que se siguió para llegar a una aplicación funcional, desde su especificación hasta
las pruebas realizadas. En la siguiente sección se presenta un marco teórico que comprende
algunas de las tecnologías y conceptos más notables en los que se basan el sistema del
Juego Gerencial, la construcción del manejador de decisiones y su visión a futuro. Por
medio de éste es más fácil comprender algunas de las situaciones que se enfrentaron en las
etapas de diseño e implementación del producto. Seguidamente, se expone la metodología
de desarrollo que se planteó para esta aplicación.
En posteriores secciones se encuentran las diferentes etapas que se llevaron a cabo para
llegar a un producto terminado. En primera medida, se presenta el análisis de
requerimientos de la aplicación. En ésta se documentan los requerimientos con los que
debía cumplir el programa, teniendo en cuenta ciertos atributos de calidad que también se
especifican en esta sección. Luego se presenta el diseño de la aplicación que documenta la
estructura de la lógica y de la interfaz gráfica que se buscaba lograr. A su vez, se presentan
las justificaciones más importantes de las decisiones tomadas sobre la interacción entre los
diferentes elementos del modelo desarrollado.
Una vez expuesto el diseño de la aplicación, se presentan los resultados del proceso de
implementación. En esta sección se exhibe el alcance obtenido y se discuten las
funcionalidades alcanzadas por el grupo de desarrollo. También se presentan estadísticas
del producto terminado que incluyen métricas sobre el tamaño del programa. Seguido se
encuentra la sección de pruebas realizadas sobre la aplicación. En ella se exponen y
justifican los tipos de validaciones que se realizaron sobre los componentes de la
aplicación, junto con los resultados obtenidos. Por último, se presentan las conclusiones
correspondientes del trabajo realizado, oportunidades de mejora y el trabajo a futuro que
puede llevarse a cabo como parte de este desarrollo incremental.
4
2 Objetivos
En esta sección se exponen los objetivos generales y específicos que se establecieron en
cuanto al proceso de desarrollo y al producto deseado.
2.1 Objetivos Generales
Desarrollar una aplicación para la definición completa de una decisión
Se pretende construir un medio a través del cual se pueda crear una decisión con todos
los elementos que la componen. Para ello se debía comprender el papel de cada
elemento de una decisión, sus relaciones y dependencias. Así, se establecería claramente
el proceso de definición que debe ser apoyado por el manejador de decisiones.
Implementar una interfaz gráfica altamente usable por el usuario
Buena parte del cambio que se espera causar con este proyecto viene dado por la
facilidad de adaptarlo al proceso de definición de decisiones con el que ya cuentan en el
proyecto del Juego Gerencial. Una faceta crucial de dicha labor es presentar una interfaz
gráfica que sea intuitiva para el usuario y que aprender a utilizarla no implique mayor
dedicación. Por ello, se considera que una opción adecuada es utilizar tablas similares a
las que se observan en las hojas de cálculo que se han utilizado en el proyecto para
definir las decisiones. Así, se esperaría proponer una experiencia más familiar para el
usuario y que promueva la usabilidad de la aplicación.
Proponer un diseño que favorezca la modificabilidad y evolución del manejador
Por tratarse de una aplicación que va a estar sujeta a cambios en el futuro, debe estar en
capacidad de soportar dichas modificaciones con relativa facilidad. Estas pueden tratarse
de corrección de fallas, mejorar el desempeño o adaptarlo a algún cambio en las reglas
de negocio. Esto implica que, en lo posible, el manejador de decisiones debería poderse
mantener en, o cambiar a, un estado en el que pueda cumplir las funciones requeridas sin
incurrir en modificaciones de todos sus componentes [Bar03].
2.2 Objetivos Específicos
Identificar una librería para interfaces gráficas
La escogencia de esta librería se basa en sus funcionalidades respecto a las tablas y en la
variedad de componentes gráficos que se puedan utilizar. Se busca crear una interfaz
llamativa a la vista y que incorporar múltiples tablas en la aplicación genere una
experiencia similar a usar hojas de cálculo.
5
Comprender el proceso de definición de una decisión y su uso en el sistema del
Juego Gerencial
Se deben identificar los puntos de mejora en el proceso de definición de una decisión.
Para ello, se estudiará la forma en que éstas se construyen actualmente y el impacto que
pueda causar esta aplicación en el Juego Gerencial.
Estudiar los elementos que componen una decisión y las relaciones entre ellos
Con el fin de establecer un diseño consecuente con la realidad de una decisión, se deben
comprender qué elementos la componen y cómo se relacionan entre ellos. De esta forma,
los conceptos que se presenten en el producto terminado serán fácilmente identificados
por los usuarios finales.
Definir un esquema para la interfaz gráfica que siga el orden en que se definen los
elementos de una decisión
Se propone una interfaz en la que a medida que se avanza en la construcción de la
decisión, sus elementos más complejos hacen uso de elementos definidos previamente.
Este debe ser un orden que se haga evidente al momento de interactuar con la interfaz
gráfica.
Diseñar la representación de los elementos de una decisión en la aplicación y la
lógica completa para el manejo de estos
Cada entidad que compone una decisión debe verse definida en el modelo de una
decisión que utilice la aplicación. Se deben establecer componentes que se encarguen de
administrar cada elemento de este modelo y la forma en que estos se asocian para
construir la decisión.
Utilizar una decisión ya definida en el Juego Gerencial para ejemplificar y validar
el uso del programa
Al intentar introducir una decisión completa en la aplicación desarrollada es posible
identificar puntos fuertes y puntos por mejorar en esta. Así se evidencia la utilidad del
producto y es posible también reconocer mejoras potenciales en la definición de una
decisión.
Generar un archivo de texto con la gramática MAGES para su futura
incorporación al sistema del Juego Gerencial
Después de definir una decisión, debe existir una forma de incorporarla al Juego
Gerencial. Para ello, se debe implementar un generador MAGES que basado en los datos
introducidos sobre una decisión genere una serie de archivos establecidos. Los cuales,
serán posteriormente leídos por un interpretador y transformado finalmente en una
decisión disponible en el juego.
6
3 Marco Teórico
El sistema del Juego Gerencial y el manejador de decisiones se basan en uno o más de los
elementos que se tratan a continuación. El sistema del Juego Gerencial que utilizan en el
curso se ha construido con base en el uso de tecnologías que permiten transformar modelos
a código que puede ser ejecutado. La idea fundamental detrás de esto es disminuir los
tiempos de desarrollo en la medida que no se tenga que programar directamente, sino
creando modelos a partir de los cuales se genere automáticamente el código. En la primera
sección de este marco teórico se presenta una descripción de esta tecnología y de su
relevancia tanto en la herramienta del Juego Gerencial, como en la aplicación desarrollada
para definir decisiones.
La siguiente sección introduce la librería gráfica que se utilizó en el manejador de
decisiones. Se presentan sus diferentes características y limitantes con el fin de comprender
en mayor medida las posteriores decisiones de diseño e implementación que se tomaron.
3.1 Metamodelos y modelos
A continuación se presenta una introducción a una serie de conceptos y tecnologías
fundamentales para la herramienta del Juego Gerencial y el manejador de decisiones. Los
modelos, y las transformaciones de estos a código ejecutable, son utilizados ampliamente
en el Juego Gerencial para generar tanto la lógica del sistema como la interfaz gráfica Web.
A su vez, en el manejador de decisiones se leen datos a partir de modelos y se generan
archivos de texto con una sintaxis conforme al metamodelo de una decisión. Las siguientes
secciones contribuyen a crear conceptos comunes sobre modelos, meta-modelos y su
relación.
3.1.1 ¿Qué es un modelo?
Si se piensa en un modelo como una entidad ajena a la construcción de software, se puede
establecer que es una manera de describir a un sistema o a un proceso para estudiar parte de
su comportamiento ante diferentes situaciones y comunicarlo posteriormente. Lo cual, no
es complejo de asimilar si se trata de un modelo de un automóvil por ejemplo. Éste se crea
para analizar el funcionamiento y características puntuales del mismo, como tolerancia a
choques, o la manera que el viento afecta su desempeño. Se crean de tal forma que
representen un comportamiento lo más cercano a lo que sería en la realidad, sin necesidad
de incurrir en todos los costos de fabricación necesarios para producir la copia real del
automóvil, entre otros objetivos [Küh05]. Lo mismo ocurre en otras áreas de la ingeniería
como la construcción de edificaciones, de componentes electrónicos, por nombrar algunos.
Ahora bien, extrapolar esta noción de modelo al área de la construcción de software puede
ser algo más compleja.
Existe cierta diferencia entre la noción tradicional de modelos en ingeniería, y lo que se
entiende como modelos para el desarrollo de software. En general, los modelos que se
7
utilizan en diferentes estudios son simulaciones de objetos que siguen una serie de reglas
físicas. En cambio, los modelos de software se centran más en una descripción y un
esquema de construcción para algo que finalmente no se convertirá en algo tan material
como un automóvil o una casa. Esto se debe a que en el centro del desarrollo de software,
se encuentra una inherente abstracción del mundo real, la cual se representa por medio de
modelos. Los cuales, pueden ser utilizados para dos fines: describir un sistema ya existente,
o especificar un sistema a construir [Sei03]. En el primer caso, el modelo se evalúa respecto
a una serie de leyes y propiedades que exhibe el sistema. La validez del modelo en este
caso es relativa a qué tan bien represente el comportamiento del sistema en cuestión. En el
segundo caso, el sistema desarrollado es el que no se debería desviar de las especificaciones
del modelo, y en caso de hacerlo es el sistema lo que es inválido respecto al modelo mismo.
Para el manejador de decisiones son importantes estas dos funciones, puesto que por un
lado, se tiene un modelo describe el sistema del Juego Gerencial y que sirve de entrada para
crear una decisión. Por otro lado, se busca definir un modelo que especifique las
propiedades ya conocidas de una decisión.
En lo referente al Juego Gerencial, se tiene un modelo que representa las diferentes
entidades que componen al juego mismo. Elementos como “Unidad de negocio”,
“Periodo”, “Estado Operativo” y “Región” forman parte de este modelo. El manejador de
decisiones recurre a este modelo para asociar elementos del mismo a la decisión que se esté
creando. Por otra parte, se tiene un modelo que representa una decisión y que contiene los
elementos que la conforman y la relación que existe entre cada uno de ellos. El manejador
de decisiones genera un archivo, que a partir de una sintaxis específica expresa las
características de la decisión que se esté definiendo en el momento. Esta sintaxis se basa en
los elementos del modelo de una decisión para lograr dicha labor. Sin embargo, esta
sintaxis no se definió para este trabajo en concreto, sino uno que se realizó en paralelo.
Información sobre este proyecto se puede obtener en [Tel10].
Lo importante a resaltar en los modelos es que el enfoque del desarrollo de software pueden
ser ellos mismos. En la programación orientada a objetos, los modelos realizados en las
etapas de análisis y diseño se limitan a ser guías para que un grupo de programadores
tengan un soporte al momento de implementar la solución. Si vamos más allá de ese
esquema, podría considerarse la posibilidad de generar directamente parte del código del
sistema deseado basándose en la información que contengan los modelos creados. Lo cual
aportaría a la constante búsqueda de disminución de costos y tiempos del lanzamiento del
producto al mercado, junto con una mejoría en la calidad del software mismo. Sin embargo,
para acercarse a este objetivo es necesario definir una serie de reglas respecto a la forma de
hacer los modelos, lo cual se tratará a continuación.
3.1.2 Metamodelos y su relación con los modelos
Se busca un lenguaje, unas reglas y unas restricciones para poder expresar los modelos
mismos como abstracciones de la realidad. En ese sentido, cualquier modelo que se realice
debe ser conforme a un metamodelo [Bez04]. Este último establece los elementos que se
pueden utilizar en un modelo, las relaciones estructurales entre estos elementos y una serie
de restricciones que quizás no se puedan expresar gráficamente. Así, un modelo debe ser
8
creado en términos del lenguaje que presente su respectivo metamodelo, por medio de una
sintaxis, semántica y reglas de inferencia claramente establecidas. Se dice entonces, que un
modelo es conforme a un metamodelo en la medida que el primero utilice los elementos
gráficos y textuales, junto con las reglas establecidas para crearlos y relacionarlos entre sí,
que especifica el metamodelo.
Sin embargo, surge la problemática de que pueden darse una gran cantidad de metamodelos
incompatibles e individuales que responden solo por el contexto en el que fueron creados y
que evolucionan de forma separada. Por lo cual, se hizo necesario establecer un modelo
más allá de los metamodelos (un meta-metamodelo), llamado “Meta Object Facility”
(MOF) y concebido por la OMG (Object Management Group). Todo metamodelo debe ser
conforme a éste ya que establece el lenguaje y propiedades estandarizadas para que haya un
consenso respecto a la construcción de metamodelos. De esta forma se nota la diferencia
entre un modelo y un metamodelo, en la medida que el modelo solo responde ante algún
metamodelo creado por los desarrolladores mismos. En cambio, un metamodelo debe
responder solo ante el meta-metamodelo, que en este caso se refiere a MOF [OMG06].
Aplicando dicha noción al caso del Juego Gerencial, se pueden observar dos metamodelos
y la forma en que se utilizan modelos conformes a ellos. En primera medida, se tiene un
modelo anterior a la realización del manejador de decisiones, que como se explicó
anteriormente, contiene los elementos que se utilizan en un Juego Gerencial. Este modelo
es conforme a un metamodelo EA (Entidad-Relación por sus siglas en inglés). Este
metamodelo contiene elementos como Entidad, que poseen asociaciones o relaciones con
otras entidades. Las entidades también tienen atributos y operaciones. El modelo del Juego
Gerencial fue creado a partir de dichos elementos y así, se crean entidades como “Unidad
de Negocio” que posee atributos como “nombre” y asociaciones a otras entidades como
“Estado Operativo”. En segunda medida, el MAGES-DL [Tel10] definió un metamodelo
para una decisión. En este se tienen elementos como “Transacción Operativa” y “Parámetro
Simple” que son genéricos a toda decisión. Luego, el manejador de decisiones convertirá
los datos de la decisión que se desee crear, en un modelo que instancia los elementos del
metamodelo de una decisión para su caso específico. Este modelo se representa por medio
de la sintaxis específica para el metamodelo de una decisión.
3.2 Qt Jambi
En esta sección se presenta la herramienta seleccionada para el desarrollo de la interfaz
gráfica de este proyecto. Ésta fue elegida por su versatilidad para crear interfaces graficas
amigables y por las diferentes capacidades ofrecidas para el manejo de tablas.
3.2.1 Herramienta de Desarrollo Qt
Qt es una librería multiplataforma desarrollada desde 1991 y publicada en 1995 por la
empresa noruega Trolltech. Desde su primera versión, fue diseñada con el objetivo de
proveer un entorno de interacción gráfico compatible con Unix, Macintosh y Windows. Ya
9
en 1993 sus creadores habían desarrollado el primer kernel Qt a partir del lenguaje C++ y
se encontraban en capacidad de implementar sus propios componentes gráficos. Con el
paso de los años fueron adquiriendo un mayor número de clientes y en 1997 adquirió
mayor auge gracias a su utilización en el proyecto KDE para la construcción de interfaces
gráficas en Linux [BS04].
La reputación de Qt viene dada no solo por ser una herramienta multi-plataforma, sino
porproveer un API intuitivo y ordenado. Esto le presenta a los desarrolladores la posibilidad
de trabajar en un sistema operativo y ampliar su mercado a otros de estos teniendo
solamente que volver a compilar su código Qt. A su vez, los programas desarrollados en Qt
tienden a ser rápidos gracias a la optimización de su implementación [BS04]. Gracias a
estas características Qt extendió su dominio a las plataformas móviles y presentó librerías
adicionales para adaptarse a varios lenguajes de programación. Entre ellas, se encuentra Qt
Jambi como adaptador para Java. Así, se presenta una alternativa a otras herramientas
disponibles en este lenguaje como Swing [RV04] o SWT [NW04], y que cuenta con una
serie de componentes más atractivos a la vista y al momento de programar.
3.2.2 GUI Toolkits
Las herramientas para desarrollar interfaces gráficas, o GUI toolkits, no son muy conocidas
en MS Windows o Macintosh, pero son ampliamente difundidas en Unix. En el caso de
Unix, y a diferencia de los otros dos sistemas operativos, éste no cuenta con una serie de
primitivas como botones o cuadros de texto a partir de los cuales diseñar una interfaz. Unix
ofrece una cantidad muy limitada de funciones gráficas y construir una aplicación con éstas
resulta ser una labor sumamente extenuante. Por lo cual, han surgido múltiples toolkits para
apoyar a los desarrolladores en esta labor y facilitar la creación de elementos gráficos más
complejos. Windows por su parte provee un API con funciones para crear diversos
elementos gráficos, manipular colores, entre otras. Sin embargo, estas funciones no son lo
suficientemente sencillas de utilizar como para facilitar la creación de interfaces gráficas
sofisticadas. Razón por la cual, aparecen frameworks como Qt.
Como framework, Qt es más que una librería de elementos gráficos como botones y menús.
Esta plataforma aísla al desarrollador delos detalles de implementación de bajo nivel y le
proporciona una serie de herramientas para responder ante la interacción del usuario con
sus componentes gráficos [Kal02]. Esta es una razón importante por la cual se utiliza Qt, y
más específicamente Qt Jambi, en el desarrollo del manejador de decisiones. Es una librería
que provee una diversidad de medios para interactuar con el usuario y cuenta con un
catálogo de elementos gráficos que contribuyen a la creación de una interfaz llamativa.
Entre una de sus herramientas se encuentra el QtDesigner. Éste permite definir la relación
entre los componentes gráficos al interior de la interfaz y cuenta con la capacidad de
mostrar cómo se vería la interfaz gráfica en diferentes entornos de ejecución. La Figura 3-1
presenta el espacio de trabajo en que se construye la interfaz gráfica y algunas de las
opciones con las que se pueden configurar. La Figura 3-2 ilustra las diferentes opciones que
provee el QtDesigner para visualizar la interfaz.
10
Figura 3-1: QtDesigner para construcción de un dialogo
Figura 3-2: Opciones de visualización del QtDesigner
11
3.2.3 ¿Qué son los QWidgets?
Los QWidgets son elementos gráficos que sirven de bloques para una aplicación. Los
widgets se pueden dividir en dos categorías: de tipo simple y compuesto. En Qt, son
widgets simples aquellos como etiquetas (labels), botones y cuadros de texto. El
desarrollador al momento de crear su interfaz puede unir diferentes widgets simples para
formar un widget compuesto. Este nuevo widget puede ser usado en diferentes puntos de la
aplicación y es una característica de la cual se aprovecha el manejador de decisiones para
reutilizar paneles con tablas como se verá más adelante. La Figura 3-3 presenta la lista de
widgets predefinidos por Qt.
Figura 3-3: Qt Widgets
3.2.4 Manejo de eventos en Qt Jambi
Qt introduce los conceptos de slots y signals para manejar los eventos que se presentan en
los widgets.
Signals: Son declaraciones para expresar eventos producidos por la interacción entre el
usuario y algún widget. Estos pueden ser un click del mouse o la entrada del teclado, los
cuales generan el lanzamiento de un evento dependiendo del tipo de widget [Kal02].
Cada widget tiene asociada una serie de eventos que el desarrollador puede utilizar para
que su aplicación responda ante la ocurrencia de los mismos. Un botón por ejemplo,
cuenta con las señales clicked, pressed y released, que son lanzadas dependiendo de la
forma en que éste interactúe con el mouse.
Slots: Son los receptores de las señales y definen la forma en que se responderá al
evento en cuestión. Los slots en el caso de Qt Jambi son métodos implementados en
Java. Estos pueden ser de tipo privado, protegido o público dependiendo de la situación
12
que se desee manejar y pueden encontrarse en instancias de cualquier objeto de la
aplicación.
Para lograr esto, cada señal cuenta con un método connect que recibe dos parámetros: la
instancia del objeto que responde a la señal, y el método de este que será invocado (slot)
[Kal02]. Este slot debe cumplir con una lista de parámetros que se determinan a partir de la
señal con la que esté conectada. En el caso de la señal clicked de un botón, se seguiría un
esquema como el siguiente:
QPushButton button;
… button.clicked.connect(this,"testSlot(Boolean)");
… private void testSlot(Boolean b)
{
button.setText("Hello Qt");
}
La señal clicked exige que el slot receptor tenga como parámetro un objeto de tipo Boolean.
De lo contrario, la aplicación fallaría en ejecución. Como se puede observar en el ejemplo
anterior, este esquema de signals y slots puede presenta inconvenientes en la
modificabilidad del manejador de decisiones. Esto se debe a que eventualmente se podrían
asociar métodos de cualquier objeto a una señal, y en caso de modificar la declaración del
slot, sería necesario hacer cambios en múltiples puntos. A su vez, es un sistema susceptible
a errores por tener que mantener establecidos los nombres de los métodos slot a invocar y
porque un error en un parámetro de un slot no se identifica al momento de compilar el
código, sino solo en ejecución. Por lo cual, en la sección de diseño del manejador de
decisiones se plantean alternativas a este sistema.
13
4 Metodología de Trabajo
El desarrollo del manejador de decisiones debió tener en cuenta múltiples características del
proyecto para realizarlo de la forma más efectiva posible. Como primera medida, el grupo
de desarrollo constaba de sólo dos personas. Por lo que si bien la comunicación se
facilitaba, se hacía necesaria una correcta distribución de labores y un seguimiento
constante de actividades realizadas. En segundo lugar, la comprensión de los
requerimientos y el entendimiento de lo que compone a una decisión se dieron a la par del
proceso de análisis, diseño e implementación del producto. Esto implicaba que en cualquier
momento podía ser necesario reestructurar algún entregable de la aplicación. Así, en tercer
lugar, se requerían reuniones cada cierto periodo de tiempo con diferentes personas para
comprender mejor la problemática a resolver, adaptarse a los cambios presentados y
redefinir la construcción incremental de la aplicación.
Ante el tamaño del grupo se debió buscar una estrategia que tuviese en cuenta la rápida
adaptación a nuevas tecnologías como Qt Jambi, y cambios frecuentes en las actividades de
análisis, diseño e implementación. Por ello, se decidió utilizar algunos principios del
método Extreme Programming (XP). Principalmente se utilizaron las reglas de este método
sobre desarrollo iterativo, programación por pares, frecuente integración y soluciones spike
[Bec00]. Este último elemento es importante en la medida que se resuelve un problema
puntual de forma aislada para comprender cómo se soluciona y luego se aplican estos
conocimientos concretamente al manejador de decisiones. Eso se utilizó principalmente con
Qt Jambi, puesto que no había mayor conocimiento de la herramienta previo al inicio de
este proyecto. Luego para aprender a utilizar sus diferentes componentes gráficos, se
crearon varios proyectos simples y desechables a lo largo de la construcción de la
aplicación que se centraran solo en el uso de esta librería.
Cada una o dos semanas se realizaban reuniones con diferentes personas involucradas en el
proyecto del Juego Gerencial. En estas se presentaban los avances de la aplicación que
fuesen adecuados para cada reunión. Junto con el grupo asesor y en algunas ocasiones con
desarrolladores del Juego Gerencial se realizaban recomendaciones y correcciones sobre la
versión del manejador de decisiones que se tuviese en ese momento. Basado en estas
reuniones se procedía a realizar el análisis de nuevas labores, de elementos de la aplicación
que tuviesen que ser modificadas y se distribuían rápidamente estas tareas para responder
ágilmente a los cambios deseados. Como consecuencia de esto se tienen cinco mayores
iteraciones del manejador de decisiones. Cada una con una serie notable de cambios
respecto a su versión anterior.
Se realizaban reuniones del grupo de desarrollo con buena frecuencia debido al tiempo
limitado y a la facilidad con la que cambiaban las reglas para definir una decisión. En éstas,
realizadas mínimo una vez a la semana, se buscaba lograr un conocimiento común al
interior del grupo, sobre lo que se quería lograr y en algunos casos hasta se rediseñaban
elementos de la aplicación. Además se revisaba lo que se había logrado hasta ese momento,
qué había que corregir, qué faltaba agregar y quien sería el responsable de esto.
14
5 Análisis de Requerimientos
Habiendo establecido el problema que se busca resolver y el marco teórico que sirve como
fundamento para las próximas secciones, se procede a detallar la solución que se busca
alcanzar. En esta sección se identifican los objetos que forman parte de la solución a
desarrollar, las asociaciones que existen entre ellos y sus respectivos atributos. Se
consideran las necesidades del profesor que utilizará el producto terminado para definir las
decisiones junto con las expectativas de calidad de la aplicación. En primera medida se
define claramente qué es una decisión a partir de los elementos que la componen. A su vez,
se explican los principales componentes de la misma. Una vez establecido ese lenguaje
común para expresar los elementos de la solución, se exponen los casos de uso que hacen
referencia a las interacciones que se desean lograr entre el profesor y el manejador de
decisiones. Posteriormente, se documentan los requerimientos en términos de dicha
interacción, sus entradas y sus resultados. Por último, se exponen los principales atributos
de calidad que se buscan favorecer en el diseño e implementación de esta herramienta.
5.1 Estructura de una Decisión
El desarrollo de esta herramienta parte de una correcta comprensión de los elementos que
se busca modelar. Para lograr esto, se estudiaron los archivos de MS Excel donde se definía
inicialmente una decisión. Luego, se analizaron los archivos XML donde se especificaba de
forma definitiva los elementos que componen una decisión y la relación existente entre
ellos. A partir de estos, se pudo establecer un proceso de construcción de una decisión que
debía ser modelado en la aplicación.
El proceso de construcción inicia con una Decisión como elemento central. A este se le
atribuyen propiedades como un nombre, un tipo y una descripción. Los elementos más
básicos de una decisión son, adicionalmente, los parámetros que serán utilizados por otros
componentes. Se identificaron dos tipos iniciales de parámetros que se describen a
continuación y se muestran en la Figura 5-1.
Figura 5-1: Parámetros de una Decisión
15
Parámetro Tipo Simple: Es el tipo más básico de parámetro que se puede incluir en una
decisión. Solamente pueden manejar datos de tipos básicos como enteros, reales o cadenas
de texto. A su vez, tiene un valor inicial dependiendo del tipo de dato de dicho parámetro.
Parámetro Tipo Filtro: Este tipo de parámetros tiene como objetivo acceder a la base de
datos del Juego Gerencial para extraer información que servirá como parámetro de entrada
en la ejecución de la decisión. Por ello, tiene asociada una entidad del modelo que es el
resultado de ejecutar la consulta del filtro. El resultado de la consulta también puede ser un
tipo básico como un entero o una cadena de texto. La consulta de este parámetro se define a
partir de otras entidades como se muestra en la Figura 5-2.
Figura 5-2: Filtro de un Parámetro
Filtro: Elemento central para una consulta a la base de datos del Juego Gerencial. Éste
administra a un elemento Query que es el encargado de contener la expresión de la consulta
y saber en qué lenguaje está escrita. A su vez, el Filtro contiene una serie de parámetros
según sean necesarios para realizar la consulta.
Continuando con el orden de los componentes de una decisión encontramos las fórmulas.
Estas son las encargadas de definir en qué orden se realizan los cómputos de una decisión y
cuáles parámetros intervienen en cada uno de estos cálculos. Los resultados de las fórmulas
pueden ser utilizados por otras fórmulas para construir una cadena de dependencias en la
computación de la decisión. Por esta razón, el resultado de una fórmula se considera
también como un parámetro.
Las fórmulas de una decisión se clasifican en cuatro categorías. Las de tipo Access retornan
un atributo especificado de un objeto. Este objeto puede ser obtenido a partir de otra
fórmula, o de un parámetro tipo filtro. El segundo tipo de fórmula es Operation y retorna el
resultado de una expresión matemática cuyos operandos son los parámetros de la función.
El tercer tipo es Service, el cual define la localización de un servicio externo que debe ser
16
invocado por el simulador. Por último, las fórmulas Search realizan una consulta a partir de
un Filtro asociado. Este es del mismo tipo que los utilizados por los parámetros tipo filtro.
Fórmula: Elemento central para los cómputos de una decisión que toma como argumentos
a parámetros tipo simple, tipo filtro o los resultados de otras fórmulas. Los parámetros de
una fórmula se declaran por medio de un elemento denominado
FormulaParameterAssociation. Dependiendo del tipo de fórmula, contarán con otra serie
de elementos asociados como filtros o proveedores de servicios. Se consideran parámetros
en la medida que sus resultados pueden ser utilizados como argumentos en la invocación de
otras fórmulas en la cadena de cómputos de una decisión.
Figura 5-3: Fórmula
Los elementos que finalmente requieren de todos los anteriores son las transacciones. Hay
dos tipos de transacciones en una decisión: Contables y Operativas. Cada transacción
contiene una serie de movimientos. Los movimientos operativos contienen atributos que
tienen asociado un parámetro que es el encargado de proporcionarle el valor a dicho
atributo. Como se definió anteriormente, un parámetro puede estar definido en términos de
un parámetro simple, filtro o del resultado de la invocación de una fórmula. La Figura 5-4
presenta la relación entre estos elementos y los diferentes parámetros.
Transacción: Es el medio a través del cual la decisión afecta el estado operativo y contable
de una unidad de un grupo corporativo. En el caso de una transacción operativa, el efecto
de sus movimientos se ven reflejados en una unidad de negocio. Esta unidad de negocio se
17
obtiene a partir de un parámetro tipo filtro que con base en su consulta retorna la unidad
deseada. Por otra parte, en caso de que haya un movimiento cuya operación sea eliminar o
modificar un estado operativo, se haría sobre un ítem concreto. Este ítem se obtiene
también a partir de un parámetro tipo filtro, de forma análoga a como se hace con la unidad
de negocio.
Figura 5-4: Transacciones Contables y Operativas
18
5.2 Requerimientos Funcionales
Teniendo en cuenta los elementos que componen una decisión y la relación existente entre
ellos, se consideran las actividades que deben poderse realizar en el manejador de
decisiones. La Figura 5-5 ilustra los casos de uso definidos para un usuario de la aplicación.
Cada uno de estos es luego dividido en actividades más específicas que finalmente se
refieren a los requerimientos funcionales.
Figura 5-5: Casos de Uso
5.2.1 Crear una decisión
El usuario puede crear una nueva decisión para ser editada. Esta se encuentra inicialmente
vacía con el fin de que el usuario diligencie los formularios propuestos.
A continuación se detallas las actividades específicas que componen la tarea de crear una
decisión:
Definir las propiedades de la decisión. Asignarle un nombre, un tipo y una descripción
a la decisión que se esté construyendo.
Definir parámetros. Se especifican cuales son los parámetros tipo simple y tipo filtro
que utilizará la decisión
Declarar fórmulas. Se crean funciones con un tipo de retorno y una serie de
parámetros.
Ordenar cómputos. Se define un orden de ejecución para los cómputos de una decisión
a partir de invocaciones de las fórmulas antes declaradas.
Definir transacciones contables. Se detallan cuales serán los efectos contables de la
decisión asignándole a cada movimiento los resultados de cómputos específicos.
19
Definir transacciones operativas. Se realizan operaciones sobre unidades de negocio
asignándole resultados de cómputos específicos a los atributos de un estado operativo.
5.2.2 Guardar una decisión
El usuario puede guardar la decisión que esté modificando, permitiendo que este pueda
volver a cargarla con fines de edición y generación de archivos.
Actividades específicas
Indicar la ubicación en la máquina donde se almacenará el archivo con extensión .decis.
5.2.3 Abrir una decisión
Se puede abrir una decisión previamente guardada con el fin de continuar su edición.
Actividades específicas
Seleccionar un archivo previamente guardado con la extensión .decis para que los datos
puedan ser procesados por la aplicación y desplegados por medio de la interfaz grafica al
usuario.
5.2.4 Modificar una decisión
Después de abrir una decisión, el usuario debe poder aplicar cambios sobre la información
ya existente de la decisión. Estas modificaciones deben hacerse visibles en la interfaz
gráfica.
Actividades específicas
Modificar cada elemento antes creado de una decisión. Dichos cambios son
efectivamente validados y desplegados en la interfaz gráfica.
5.2.5 Generar archivo MAGES
El usuario puede exportar la decisión en un formato con sintaxis MAGES que será
posteriormente interpretado y transformado en una decisión disponible en el Juego
Gerencial.
Actividades específicas
Generar archivo principal MAGES: Este contiene los parámetros, el orden de cómputos
y las transacciones de la decisión.
Generar archivo fórmulas y filtros MAGES: Este contiene la declaración de las fórmulas
y de los filtros que utiliza la decisión.
20
5.3 Atributos de Calidad
En la sección anterior se trataron las necesidades que debe suplir el manejador de
decisiones. Ahora bien, paralelo a ese grupo de tareas se deben tener en cuenta una serie de
restricciones y prioridades sobre el funcionamiento de la aplicación. Estas vienen dadas por
la motivación inicial y conducen al proyecto a través de las etapas de diseño e
implementación. A continuación se tratan los principales atributos de calidad que se buscó
favorecer durante la construcción del manejador de decisiones.
5.3.1 Usabilidad
Este atributo de calidad se refiere a la facilidad con la que un usuario es capaz de aprender a
operar un sistema. Con esto se busca que los usuarios finales puedan sacar el mayor
provecho posible de la aplicación desarrollada [RW05].
5.3.1.1 Calidad Deseada
Se desea proveer un medio intuitivo a través del cual sea más eficiente la definición de
decisiones. Los usuarios de la aplicación deberían poderse adaptar rápidamente al
manejador de decisiones para así involucrar una menor cantidad de intermediarios en el
proceso. La interfaz gráfica debería presentar un orden claramente establecido y
aprehensible para la configuración de una nueva decisión.
5.3.1.2 Preocupaciones
Incluir todos los elementos de una decisión en un entorno gráfico de tal forma que se
comprenda la estructura y el orden en el que se construye la misma.
Una vez se haya aprendido a utilizar la herramienta, un experto en ella debería poseer un
alto nivel de productividad definiendo decisiones.
El uso del manejador de decisiones genera satisfacción y aceptación en los usuarios
5.3.1.3 Actividades de potenciación
Comprender la forma en la que se definen las decisiones en el Juego Gerencial.
Proponer una interfaz gráfica de usuario basada en tablas que se asemejen a las que han
venido utilizando en hojas de cálculo para disminuir el impacto del cambio.
Proponer un proceso de definición ordenado que sea fácil de memorizar y comprender.
21
5.3.2 Modificabilidad
Favoreciendo este atributo de calidad se busca que el manejador de decisiones pueda ser
modificado con relativa facilidad para corregir errores, mejorar su desempeño y adaptarlo a
cambios en las reglas del negocio [Bar03]. Para identificar puntos donde se pueda potenciar
este atributo es importante comprender: quién hace el cambio, en qué momento lo hace, qué
puede modificarse y cómo se debería medir el costo de dicha modificación [BBN07].
5.3.2.1 Calidad Deseada
El manejador de decisiones es una aplicación que en el futuro estará sujeta a cambios y
estos no serán necesariamente realizados por los desarrolladores iniciales. Por consecuente,
sin importar en qué modulo de la aplicación se desee hacer el cambio, este módulo debe ser
fácilmente identificable y el cambio debe afectar la menor cantidad de módulos adicionales
en el manejador. Esto se justifica en la medida que los cambios pueden originarse en
cualquier punto de la aplicación, ya sea en la interfaz de usuario, en la lógica para asociar
los componentes de una decisión, en el acceso de datos externos a la aplicación, o en la
generación de archivos de salida. A su vez, estos cambios pueden ocurrir en diferentes
etapas como pueden ser la de diseño, la de despliegue o la de ejecución de la aplicación y
pueden venir motivados por comentarios de los usuarios finales, o por los mismos
desarrolladores que identificaron puntos de mejora.
5.3.2.2 Preocupaciones
Extender, agregar o reparar funcionalidades del manejador de decisiones implica
identificar componentes concretos de la aplicación. Estas modificaciones pueden
involucrar a la interfaz gráfica, la lógica del manejo de la decisión, o la forma en que se
manejan archivos de entrada y salida de la aplicación.
Futuros desarrolladores pueden verse en la necesidad de realizar cambios en diferentes
secciones del programa bajo ciertas expectativas de tiempo para volver realidad dichos
cambios.
5.3.2.3 Actividades de potenciación
Dividir la lógica de la aplicación en diferentes módulos o manejadores más específicos
para administrar los componentes de la decisión que se esté creando.
Independizar la interfaz gráfica de la lógica de la aplicación. La interfaz gráfica
solamente se comunica por medio de interfaces de servicios que exponen los módulos de
la aplicación. A su vez, que los módulos lancen eventos que sean atrapados por los
diferentes elementos de la interfaz gráfica para actualizar las diferentes vistas.
Diseñar e implementar componentes gráficos reutilizables que se valgan de una
arquitectura modelo-vista-controlador.
22
Buscar una baja complejidad ciclomática [MCC76] de todos los módulos en la
aplicación para hacer que el código sea más fácil de comprender y que
consecuentemente, realizar una modificación sea menos extenuante.
5.4 Escenarios de Calidad
Dada la inherente dificultad que implica evaluar cuán efectivamente la aplicación cumple
las necesidades que expresan los atributos de calidad, se hace necesario presentar
situaciones específicas en las que se establezca una medida de satisfacción. Cada uno de
estos escenarios de calidad plantea dicha situación a partir de las cuales se puede evaluar el
cumplimiento de los atributos de calidad antes planteados.
5.4.1 Escenarios de Usabilidad
5.4.1.1 Comprensión de la interfaz gráfica
Descripción
Se desea que un nuevo usuario de la aplicación esté en capacidad de comprender fácilmente
el orden en el que debe definir una decisión y qué espacio de la interfaz gráfica está
destinado a cada elemento de una decisión. Esta persona debería poder asociar sus
conocimientos previos de una decisión a la manera en que se plantea la construcción de la
misma, a través de la interfaz propuesta.
Fuente
Nuevo usuario del manejador de decisiones.
Estímulo
El nuevo usuario desea familiarizarse con la interfaz gráfica que se propone para crear una
decisión.
Artefacto
La aplicación terminada.
Ambiente
Tiempo de ejecución.
Respuesta
El usuario busca conocer la aplicación estudiando los diferentes paneles y ventanas que en
ella se exponen, junto con la finalidad de cada uno de estos elementos gráficos.
23
Medida de la respuesta
El usuario relaciona sus conocimientos de una decisión con lo planteado en la interfaz
gráfica en un tiempo de una hora.
5.4.1.2 Creación de una decisión
Descripción
Un usuario que ya se ha familiarizado con la herramienta desea definir una nueva decisión.
En este caso se asume que el usuario ha definido previamente su decisión y que solo
requiere introducir dicha información a la aplicación.
Fuente
Usuario familiarizado con el manejador de decisiones.
Estímulo
El usuario desea plasmar en la aplicación, la decisión que ha concebido previamente y que
está correctamente construida.
Artefacto
La aplicación terminada.
Ambiente
Tiempo de ejecución.
Respuesta
El usuario utiliza los diferentes elementos gráficos de la aplicación para introducir la
información de su nueva decisión.
Medida de la respuesta
Al usuario no le toma más de noventa minutos introducir completamente la información de
la decisión en la aplicación.
5.4.2 Escenarios de Modificabilidad
5.4.2.1 Adicionar el manejo de parámetros complejos a la lógica de la aplicación
Descripción
Otro de los elementos que se manejan en una decisión son los parámetros complejos. Estos
contienen una referencia a un servicio externo que debe ser invocado al momento de
ejecutar la decisión en el simulador del Juego Gerencial. En lo que respecta al manejador de
decisiones, se buscaría que la aplicación permita declarar parámetros de este tipo,
especificando su servicio externo, y que otros elementos como fórmulas o transacciones
puedan utilizar el resultado de dicho servicio.
24
Fuente
El grupo de desarrolladores encargados de adicionar el manejo de estos parámetros al
manejador
Estímulo
Los desarrolladores desean que en la lógica de la aplicación se manejen parámetros de tipo
complejo
Artefacto
El conjunto de componentes de la lógica del manejador de decisiones que requieran utilizar
parámetros complejos
Ambiente
Etapa de diseño y desarrollo. Se tiene una versión estable del manejador de decisiones a la
cual se le quiere adicionar el uso de parámetros complejos.
Respuesta
Los desarrolladores diseñan e implementan el uso de parámetros complejos en la lógica de
negocio de la aplicación. También se realizan pruebas sobre la modificación de estos
parámetros y sobre las referencias que otros elementos de la decisión puedan crear, hacia
estos parámetros.
Medida de la respuesta
El diseño, la implementación y las pruebas toman un tiempo máximo de seis horas.
5.4.2.2 Adicionar el manejo de parámetros complejos a la interfaz gráfica
Descripción
Una vez definida la lógica de negocio para el manejo de parámetros complejos, se busca
representar gráficamente la creación, modificación y eliminación de estos en la interfaz
gráfica. Se debe tener en cuenta que otros elementos de la decisión como fórmulas o
transacciones pueden referenciar dichos parámetros para utilizarlos en sus cálculos.
Fuente
El grupo de desarrolladores encargados de adicionar el manejo de estos parámetros al
manejador
Estímulo
Los desarrolladores desean que en la interfaz gráfica de la aplicación se manejen
parámetros de tipo complejo
Artefacto
Los componentes gráficos del manejador de decisiones encargados de desplegar la
información de un parámetro.
25
Ambiente
Etapa de diseño y desarrollo. Se tiene una versión estable del manejador de decisiones a la
cual se le quiere adicionar el uso de parámetros complejos.
Respuesta
Los desarrolladores diseñan e implementan el uso de parámetros complejos en la interfaz
gráfica de la aplicación. Adicionan una tabla donde se crean, modifican y eliminan estos
parámetros. Se aseguran que fórmulas y transacciones puedan hacer uso de los parámetros
complejos definidos. A su vez, se encargan de unir los servicios de la lógica de negocio con
la interfaz gráfica y de realizar las pruebas correspondientes.
Medida de la respuesta
El diseño, la implementación y las pruebas toman un tiempo máximo de ocho horas.
5.4.2.3 Comprensión de la estructura de la aplicación desarrollada
Descripción
Un desarrollador que ya está familiarizado con el Juego Gerencial busca agregar
funcionalidades o realizar modificaciones sobre la aplicación. Adicionalmente, este
desarrollador no tiene experiencia con el código o el diseño del manejador de decisiones. Él
debería poder, estudiar la estructura del código de la aplicación, junto con los diagramas de
clase tanto de la interfaz como de la lógica de negocio, y lograr comprender cuál es la
función de cada componente y cuáles de estos son los lugares indicados para realizar su
tarea.
Fuente
El desarrollador que no posee conocimientos sobre el diseño e implementación del
manejador de decisiones
Estímulo
El nuevo desarrollador busca familiarizarse con el diseño e implementación del manejador
de decisiones.
Artefacto
Diagramas de clase de la interfaz y la lógica de negocio, estructura de paquetes del
manejador de decisiones y las clases que en estos se encuentren.
Ambiente
Etapa de diseño y desarrollo. Se tiene una versión estable del manejador de decisiones a la
cual se le quieren adicionar o modificar funcionalidades.
Respuesta
El desarrollador inicia analizando los diagramas de clase de la lógica del mundo para
identificar qué componentes están presentes en la aplicación. Luego, se estudia cómo los
componentes gráficos se encuentran estructurados y la forma en que consumen los servicios
26
expuestos por la lógica de negocio. Por último, se analiza la estructura de paquetes para
saber qué clases componen cada uno de estos, y se revisan detalles puntuales del código
como la forma en que los componentes lanzan notificaciones para ser atrapadas por la
interfaz gráfica.
Medida de la respuesta
Al desarrollador no le toma más de dos horas tener una noción completa de la estructura del
manejador de decisiones.
27
6 Diseño
En esta sección del documento se plantea la estructura de los elementos implementados y la
interacción que hay entre ellos. En ella se busca producir una especificación lo más precisa
posible de la construcción del producto y una clara distribución de responsabilidades entre
sus partes. Se presentan inicialmente las principales decisiones de diseño con su respectiva
justificación para soportar los atributos de calidad que se desean favorecer. Posteriormente
se exponen los diagramas de clase de las diferentes secciones de la aplicación desarrollada,
seguido por otros diagramas que explican la estructura del manejador de decisiones. Por
último, se presentan las decisiones más importantes que se tomaron respecto al diseño de la
interfaz y la forma en que se desarrollaron los diferentes componentes gráficos.
6.1 Justificaciones de Diseño
A continuación se presentan las decisiones más importantes que se tomaron respecto al
diseño de la lógica del manejador.
6.1.1 Separación en manejadores de menor tamaño
Descripción
El manejador de decisiones se divide en componentes más pequeños para una mejor
distribución de responsabilidades. Estos exponen una o más interfaces de servicios que
pueden ser usadas por los demás manejadores. Se establecen los siguientes componentes:
ParameterManager. Encargado de administrar los parámetros de tipos simple y
filtro.
FormulaManager. Maneja la lógica para declarar las diferentes fórmulas y sus
respectivos parámetros
ComputationManager. Estructura el orden de ejecución de las fórmulas de la
decisión. Es el encargado de manejar las invocaciones de cada fórmula y los valores
de los parámetros que se le pasan a cada una.
AccountingTransactionsManager. Permite manejar las transacciones contables de
la decisión. Este toma los resultados necesarios de los cómputos realizados para
asociárselos a cada movimiento de una transacción.
OperativeTransactionsManager. Se encarga de administrar las transacciones
operativas y sus respectivos movimientos y atributos. Al igual que el manejador de
transacciones contables, requiere de los cómputos realizados por el manejador de
cómputos para asociarle valores a los atributos de un movimiento.
MagesGenerator. Centraliza las tareas de generar los archivos con la gramática
MAGES a partir de los datos que le provean los demás manejadores.
Justificación
Al separar la creación de una decisión en componentes más pequeños se favorece la
modificabilidad de la aplicación. Cada componente tiene unas responsabilidades claramente
28
definidas y un cambio en la lógica de dichas responsabilidades no debe afectar los demás
componentes en mayor medida. Esta separación se realiza basándose en áreas funcionales
que pueden variar relativamente independiente y así encapsular dicha funcionalidad para
limitar los efectos de estos cambios en otros módulos.
6.1.2 Implementación clases observables y observadores
Descripción
Se implementarán dos clases encargadas de materializar el patrón observador [FRB04] en
el manejador de decisiones. Es un modelo similar al patrón que implementa internamente
Java y se basa en una clase abstracta DecisionObservable que tiene la capacidad de
notificar cambios a otras clases que implementen la interfaz DecisionObserver.
Figura 6-1: Patrón Observador del manejador de decisiones
Justificación
Es una táctica utilizada ante la incompatibilidad de Qt Jambi para manejar el patrón
observador interno de Java. La implementación de estas dos clases no requiere mayor
esfuerzo y representa un elemento importante para la posterior comunicación entre los
mismos componentes de la lógica del manejador, y de estos, a las diferentes vistas de la
interfaz. Esto promueve el desacoplamiento entre el sujeto y el observador, logrando que
estos puedan evolucionar de forma independiente y sólo respondiendo a los eventos
generados por un elemento observable.
6.1.3 Modelo de propiedades
Descripción
Se utiliza un modelo genérico para manejar ciertas propiedades de los objetos de una
decisión. Se tiene una clase abstracta BaseModel que se encarga de almacenar cadenas de
texto que se refieren a propiedades del objeto que extienda dicha clase. Esta última clase
contiene las constantes que sirven como llaves para obtener las respectivas propiedades. A
continuación se ilustra el caso de la clase Parameter que extiende de BaseModel para
almacenar su nombre, identificador, tipo y descripción. Como se verá más adelante, otras
clases del modelo del mundo extienden también de BaseModel con el mismo fin.
29
Figura 6-2: Modelo de propiedades BaseModel aplicado a la clase Parameter
Justificación
En ciertas ocasiones es posible que se desee extraer alguna propiedad de un objeto y donde
no sea importante saber de qué tipo es el objeto en cuestión. Esto permite que otras clases
puedan utilizar las propiedades de algún objeto sin tener que restringirse al manejo de este
tipo específico de objetos. En el caso del manejador de decisiones, como se verá más
adelante, se cuenta con diferentes tablas para desplegar la información de elementos de una
decisión. Sin embargo, para no restringir a dichas tablas para que manejen únicamente un
objeto específico de una decisión, se les pueden asociar objetos que extiendan de
BaseModel, y solo especificar las propiedades que se deseen extraer del mismo. Con esto,
la fuente de datos y el consumidor de datos evolucionan de forma separada y se promueve
la modificabilidad de estos dos. A su vez, la clase que extiende de BaseModel se
despreocupa del almacenamiento de dichas propiedades y solo las solicita o almacena en la
medida que lo necesite.
6.2 Diagramas de Clase
En esta sección se presentan los diagramas de clase más relevantes del manejador de
decisiones. Estos presentan la estructura estática de los componentes de la aplicación.
6.2.1 Manejador de decisiones y manejadores subordinados
El manejador de decisiones es el conector de los demás componentes de la aplicación. Este
se encarga de centralizar a todos los manejadores, al generador de archivos Mages y a las
propiedades básicas de la decisión. Su labor principal es recibir eventos de los demás
manejadores que notifiquen que la decisión ha sido modificada, y llamados desde la
interfaz gráfica que hagan referencia a la persistencia de la decisión o a la generación del
30
archivo MAGES. Los diferentes elementos de la interfaz gráfica se comunican
directamente con cada manejador según la entidad de la decisión que desplieguen.
Figura 6-3: DecisionManager con manejadores específicos
31
6.2.2 Manejador de Parámetros
Figura 6-4: Diseño Manejador de Parámetros
El manejador de parámetros provee las operaciones necesarias para crear, modificar y
eliminar parámetros tipo simple y tipo filtro. También implementa una interfaz para
consultas sobre los parámetros creados que es utilizada por los componentes que requieran
acceso a estos sin necesidad de modificarlos. Por simplicidad en la estructura se decidió
almacenar los parámetros en una lista. En caso de realizar alguna modificación sobre un
parámetro, este notifica al manejador de decisiones.
32
6.2.3 Manejador de Fórmulas
Figura 6-5: Diseño Manejador de Fórmulas
De forma análoga al manejador de parámetros, el manejador de fórmulas expone dos
interfaces de servicios: una encargada de las operaciones de creación, modificación y
eliminación, y otra encargada de operaciones de consulta. Este manejador sólo se encarga
de la declaración de las fórmulas y la especificación de los parámetros que esta requiera.
Dependiendo del tipo de fórmula, esta tendrá asociada otra serie de elementos. Si es de tipo
búsqueda, tendrá un filtro, o si es de tipo servicio, tendrá un proveedor para este.
33
6.2.4 Manejador de Cómputos
Figura 6-6: Diseño Manejador de Cómputos
El manejador de cómputos utiliza los manejadores de parámetros y fórmulas para definir un
orden de ejecución de las fórmulas, y los parámetros que recibirá cada una de estas en el
momento de ser invocadas. Este manejador posee una lista de instrucciones que se
ejecutarán secuencialmente, cada una de las cuales tiene asociada la ejecución de una
fórmula. La cual, se representa por medio de la clase FormulaComputation. Además de
conocer la declaración de la fórmula, esta contiene los parámetros que se utilizarán para
dicha fórmula, por medio de la clase ComputationParameter. El valor de cada parámetro
viene dado por una clase Parameter, que puede ser entonces un parámetro simple, uno tipo
filtro, u otra instrucción ComputationInstruction.
34
6.2.5 Manejador de Transacciones Contables
Figura 6-7: Diseño Manejador de transacciones contables
El manejador de transacciones contables se basa en los mismos principios de los
manejadores anteriores. Almacena en una lista los movimientos que se vayan creando, que
su a vez tienen asociada una cuenta sobre la cual tiene efecto dicho movimiento. Estas
cuentas son almacenadas en otra lista al interior del manejador y se cargan de un archivo de
propiedades con el fin de tener a disposición la totalidad de las cuentas a ser usadas por los
movimientos. Este manejador también cuenta con una interfaz de servicio adicional que se
encarga de las consultas sobre sus transacciones y movimientos.
35
6.2.6 Manejador de Transacciones Operativas
Figura 6-8: Diseño Manejador de transacciones operativas
El manejador de transacciones operativas toma los resultados de los cómputos realizados
por el manejador de cómputos para asignarles valores a los atributos de sus movimientos.
Para ello, requiere de la interfaz de consultas IComputationQuery. Este manejador recibe
notificaciones del manejador de cómputos para actualizaciones en caso de que se le haga
algún cambio a una instrucción y este cambio deba ser actualizado en el manejador de
transacciones operativas. La estructura para el manejo de estos datos no es compleja, ya que
solo se manejan listas que contienen las diferentes entidades que requiere este manejador.
36
6.2.7 Generador Archivos MAGES
Figura 6-9: Diseño Generador de archivos MAGES
Este componente expone una interfaz de servicio destinada únicamente a la generación del
archivo con gramática MAGES. Para que la gramática esté completa se deben generar dos
archivos: uno con la información principal de la decisión que incluye los parámetros tipo
simple, tipo filtro, ambos tipos de transacciones y el bloque de cómputos. En el otro
archivo se declaran los filtros y las fórmulas en caso de querer ser reutilizadas por otras
decisiones. Para generar estos archivos, el componente requiere de las interfaces de
consulta expuestas por los demás manejadores.
37
6.2.8 Lector de Metamodelo Entidad-Relación
Figura 6-10: Diseño Lector de Metamodelo Entidad-Relación
Este componente del manejador de decisiones se encarga de cargar las entidades de un
modelo que sea conforme a un metamodelo entidad-relación (EA por sus siglas en inglés).
En este caso, se obtienen las entidades del Juego Gerencial a partir de uno de estos
modelos. La clase principal MetaModelLoader cuenta con las operaciones estáticas para
que cualquier manejador de la aplicación tenga acceso a los elementos del modelo. Se
decidió hacerlo de esta forma ya que los elementos del modelo (EAModelElement) se
utilizan de forma transversal en la aplicación y no son propiedad de alguno de los demás
manejadores. Cada EAModelElement contiene una serie de atributos que son equivalentes a
los atributos que se presenten en el modelo de entrada. Además de los elementos del
modelo del Juego Gerencial, el MetaModelLoader también genera EAModelElements que
hacen referencia a los tipos de datos básicos.
6.3 Modelo de Componentes
Con los diagramas de clases se presentó la estructura interna de cada componente del
manejador de decisiones. En este modelo se presenta una abstracción a más alto nivel de la
estructura de la lógica de la aplicación. En este se presenta cada manejador como un
componente que expone sus respectivas interfaces, algunas de las cuales son requeridas por
otros componentes. Se tiene un componente DecisionManager que encapsula los demás
manejadores y es el encargado de exponer las interfaces de estos componentes internos a
otros componentes que puedan requerirlas, como será el caso de la interfaz gráfica que se
verá más adelante.
38
Figura 6-11: Diagrama de Componentes Manejador de Decisiones
En este diagrama se puede observar la secuencia en que los componentes requieren
servicios de otros. El ComputationManager es el encargado de tomar los parámetros y
fórmulas que se hayan definido, y al utilizarlos en el orden de ejecución de la decisión, le
permite a los componentes encargados de las transacciones utilizar los resultados de dichos
cómputos para concretar el efecto de la decisión. Por último, el MagesGenerator hace uso
de los servicios de consulta expuestos por los manejadores para generar el archivo con la
gramática deseada.
6.4 Justificaciones de Diseño Interfaz Gráfica
La interfaz gráfica es otro componente de vital importancia para el manejador de
decisiones. Sobre esta se toman una serie de decisiones que buscan favorecer los atributos
de calidad antes planteados.
6.4.1 Extensión de Componentes Gráficos Qt Jambi
Descripción
Se crearon widgets que extienden de los widgets de Qt Jambi con el fin de incorporarles el
manejo de eventos y evitar el uso del modelo signals-slots que incorporan originalmente.
Se busca implementar una variación del patrón publicador-suscriptor, en que el widget
39
como publicador lanza eventos y algún otro elemento en calidad de suscriptor, recibe dicho
mensaje. Esto se hace utilizando un modelo similar al manejado en Java Swing y haciendo
uso de algunas de las clases de dicha librería. La conexión entre un evento (signal) ocurrido
en un QWidget y el método (slot) que se invoca, se sigue utilizando al interior del QWidget
modificado, pero queda aislado en el mismo. De tal forma, que al utilizar posteriormente el
QWidget modificado ya se cuenta con la posibilidad de incluir suscriptores (listeners) a un
evento.
A continuación se ilustran algunos de los QWidgets extendidos:
Figura 6-12: Diseño de QWidgets extendidos
En la Figura 6-12 se presentan los widgets QPushButtonMod, QComboBoxMod y
QTableWidgetMod. Cada uno de estos extiende de su respectivo QWidget e incorpora el
uso de suscriptores para sus eventos. QPushButtonMod tiene asociada una lista de
ActionListener que es la interfaz que Swing utiliza en sus botones. Este componente gráfico
invoca el método actionPerformed de dichos listeners pasando por parámetro un
ActionEvent que contiene el comando (actionCommand) que se le especificó al botón.
40
QComboBoxMod, QTableWidgetMod y los demás widgets modificados funcionan de
forma similar. Estos asocian internamente un método (slot) al evento (signal) del widget, y
este es el encargado de hacer los llamados a los suscriptores. En el caso de
QComboBoxMod, el evento que lanza originalmente este QWidget invoca al método
currentIndexChanged, que luego llama a todos sus suscriptores ListSelectionListener
pasando por parámetro un ListSelectionEvent.
Justificación
El modelo signal-slots que incorporan los widgets de Qt Jambi no promueve el nivel de
modificabilidad que se desea favorecer en esta aplicación. Como se vio anteriormente, este
sistema de eventos se presta para errores en la sintaxis de los métodos que se desean
invocar. Crea una relación muy fuerte entre el que publica y el que se recibe un evento,
para lo cual, existe la alternativa planteada que les permiten a estos dos elementos
evolucionar con mayor independencia.
6.4.2 Panel genérico para uso de tablas
Descripción
Se creó un panel genérico que contiene una tabla y botones para agregar y eliminar
elementos de esta. Este hace uso exclusivo de widgets extendidos como los que se
presentaron anteriormente y en él se concentran todas las operaciones necesarias para
desplegar información de un BaseModel en una tabla. Este panel aprovecha la genericidad
de un BaseModel para mostrar las propiedades del mismo en cada columna de la tabla
según se desee. De esta forma, este panel genérico puede ser reutilizado en múltiples puntos
de la aplicación.
Figura 6-13: Panel genérico para manejo de tablas
Para configurar este panel se le debe asociar un modelo que establece las propiedades de
cada columna a desplegar. En este modelo se especifica el texto que se desea mostrar en el
título de cada columna de la tabla, junto con el tipo de celda de cada columna. Se manejan
tres tipos de columnas: texto simple, una lista de opciones por medio de un
QComboBoxMod, o un botón QToolButtonMod para diferentes tareas como desplegar
algún dialogo con opciones. Este modelo se materializa en la clase ParameterTableModel
41
que hace uso de la clase ParameterTableCellDataType para especificar uno de los 3 tipos
de columnas antes mencionados.
Figura 6-14: Diseño panel genérico para el manejo de tablas
Justificación
Gran parte de la interfaz gráfica de la aplicación se basa en tablas para proponer un medio
similar al que se ha venido utilizando para definir las decisiones. Para evitar implementar
múltiples paneles que tengan la misma funcionalidad de desplegar diferentes elementos de
una decisión, es preferible utilizar un único panel genérico del cual extiendan otros paneles
que implementen la funcionalidad específica del elemento de una decisión que se desee
mostrar. A su vez, se aprovecha el uso de BaseModel para proveer un elemento genérico
que se despliega en la tabla. Esto favorece la modificabilidad puesto que es un único punto
para realizar cambios en la interfaz.
42
6.5 Diagramas de Clase Interfaz de Usuario
A continuación se presentan los principales diagramas de clase de la interfaz de usuario. Se
tiene una clase principal llamada DecisionManagerUI que se encarga de agrupar los demás
paneles por medio de pestañas. Cada uno de estos paneles es un contenedor de otros
paneles más específicos dependiendo del elemento de la decisión al que corresponda a cada
panel.
6.5.1 Interfaz de Usuario Manejador de Decisiones
Figura 6-15: Diseño GUI Manejador de Decisiones
Esta es la clase principal de la interfaz que tiene una asociación a la clase DecisionManager
que se trató anteriormente. De esta última extrae las interfaces de servicio de los diferentes
manejadores para asociárselos a los paneles contenidos. Así, estos paneles se comunican
directamente con los manejadores y no por medio del DecisionManagerUI.
43
6.5.2 Panel de Parámetros
Figura 6-16: Diseño panel contenedor de parámetros
El panel contenedor de parámetros se encarga de agrupar otros tres paneles. El primero de
ellos es un panel donde se presenta información general para todo tipo de parámetro. En él
se despliega el nombre, el tipo y la descripción de estos. La intención detrás de este panel
general es centralizar la información común a todo tipo de parámetro y permitir agregar y
eliminarlos en un mismo lugar sin importar si son de tipo simple, filtro o complejo, de ser
agregados.
Los otros dos paneles hacen referencia cada uno a un tipo específico de parámetro. En el
caso de los parámetros simples, se presenta el nombre, el tipo de este, ya sea entero, real o
cadena de texto, y un posible valor inicial. Para los parámetros filtro, se presenta el nombre,
el tipo de retorno de su filtro, un atributo de este tipo de objeto que se desee mostrar y el
filtro escogido. Para escoger al filtro, se despliega un dialogo que permite crear y
44
configurar un filtro con todas sus propiedades y asociárselo al parámetro que se esté
editando.
6.5.3 Panel de Fórmulas
Figura 6-17: Diseño panel contenedor de fórmulas
El panel contenedor de fórmulas presenta tres sub-paneles, de los cuales uno varía según el
tipo de parámetro que se esté editando. Existe un panel llamado PanelFormulaDeclaration
que le permite al usuario definir una fórmula por cada fila de la tabla. En esta se especifica
el nombre, el tipo de fórmula, una descripción y el tipo de objeto que esta retorna. El
segundo panel llamado PanelFormulaParameterAssociation permite declarar parámetros a
cada fórmula antes creada. Para cada uno de estos se escribe un nombre y se especifica el
tipo, que puede ser un tipo básico o cualquier objeto del modelo del Juego Gerencial.
45
El tercer panel depende del tipo de fórmula que se esté editando. Dependiendo de esto, se
desplegará un panel para las fórmulas tipo Access, Search, Operation o Service. Las
fórmulas tipo Operation requieren una expresión que será calculada a partir de sus
parámetros. En su caso, se utiliza el PanelEquation para que el usuario pueda introducir
esta información. Este panel también es válido para las fórmulas tipo Access ya que para
éstas sus parámetros son una entidad del modelo del Juego Gerencial y el nombre de un
atributo de ésta que se desee extraer. La expresión utiliza la notación
<entidad>.<atributo> en este caso. El PanelFormulaSearch le permite al usuario
especificar un filtro para ese tipo de fórmulas. Por último, el PanelFormulasProvider se
utiliza para el caso de las fórmulas Service que requieren información para la localización y
llamado a un servicio externo.
6.5.4 Panel de Cómputos
Figura 6-18: Diseño panel contenedor de cómputos
Para especificar el orden de los cómputos de la decisión se requieren dos paneles. El
primero es el PanelComputationInstructions donde por cada fila de la tabla se crea una
variable. A esta variable se le asociará el resultado de invocar una fórmula con unos
parámetros específicos. La selección de estos parámetros por cada invocación se hace en el
PanelComputationInstructionsParameters. Dependiendo de la fórmula que se invoque para
46
una variable, en este panel se mostraran los parámetros esperados y el usuario podrá
escoger qué valores asignarles a partir de parámetros tipo simple, tipo filtro, o una variable
declarada anteriormente.
En este contenedor de cómputos se crean las variables donde se almacenan los valores que
luego se asignarán a los movimientos contables o a los atributos operativos de los
movimientos de la decisión. Cada fila de la tabla en PanelComputationInstructions
representa una asignación a una variable que puede ser referenciada como parámetro en
posteriores invocaciones de fórmulas. Así, se utilizan estas variables para asignarle un valor
a diferentes elementos de las transacciones que lo requieran.
6.5.5 Panel de Transacciones Contables
Figura 6-19: Diseño panel de transacciones contables
Para agregar transacciones contables a la decisión se utilizan dos paneles. El primero es el
PanelAccountingTransactions y en su tabla se agregan transacciones especificando su
nombre y la unidad de negocio sobre la que esta se realizará. Cada transacción contiene una
serie de movimientos y es lo que se despliega en el
PanelAccountingTransactionsAttributes. En este se pueden agregar filas que representan
los movimientos de la transacción seleccionada en el primer panel. En las columnas de la
tabla se especifica la cuenta que afectará el movimiento, la operación a realizarse, la
cantidad de la operación y el tipo de operación. Para escoger la cuenta se despliega un
diálogo con una lista de estas, y para especificar la cantidad que se debitará o acreditará
según el tipo de operación, se despliega un diálogo que permite escoger las variables
definidas en la sección de cómputos. Estos diálogos se presentan más adelante y son el
DialogAccountSelection y el DialogParameterValue, respectivamente.
47
6.5.6 Panel de Transacciones Operativas
Figura 6-20: Diseño panel de transacciones operativas
Para crear transacciones operativas se utilizan tres paneles. El primero,
PanelMainOpTransactions, no cuenta con una tabla y es donde se agregan y eliminan estas
transacciones. Se específica su nombre y una unidad de negocio sobre la que actuará la
transacción. Para agregarle movimientos a una transacción se utiliza el
PanelMovementsOpTransactions. A cada movimiento en una fila se le asigna un nombre,
un estado operativo y la operación que se realizará. A su vez, cada atributo de un
movimiento se define en el PanelOpTransactionAttributes. En este se despliegan los
atributos del estado operativo escogido para el movimiento al cual pertenece. Solo se
modifica la columna del valor, escogiendo el resultado de un cómputo, un parámetro filtro
o un parámetro simple, a través del DialogParameterValue.
48
6.5.7 Dialogo para navegación del modelo del Juego Gerencial
Figura 6-21: Diseño diálogo para navegación del modelo del Juego Gerencial
En diferentes puntos de la aplicación es necesario especificar de qué tipo es un filtro o el
retorno de una fórmula. Estos pueden ser cualquier entidad del modelo del Juego Gerencial
como una unidad de negocio, un ítem, entre otros. Para escogerlos, se utiliza un diálogo que
permite navegar la jerarquía de elementos en el Juego Gerencial, y adicionalmente, escoger
tipos básicos como números enteros, reales o cadenas de texto. La navegación se hace por
medio de un árbol en el que hay elementos raíz. Por ejemplo, el elemento Juego es uno de
estos, y contiene una serie de grupos corporativos, el cual a su vez tiene un grupo de
unidades de negocio. El usuario puede también consultar a partir de un nombre y el diálogo
despliega los elementos filtrados.
El diseño de este y los demás diálogos presenta una serie de características importantes.
Todos utilizan el patrón singleton para manejar una única instancia de cada diálogo
[FRB04]. Para que estos aparezcan en pantalla se invocan métodos estáticos que mínimo
reciben como parámetros un QWidget padre, y un DialogInvoker. Este último elemento es
una interfaz que implementan los paneles que despliegan un diálogo. Se utiliza para recibir
la respuesta de este. Así es más flexible la interacción con el diálogo y se permite
intercambiar una mayor cantidad de datos comparado a esperar por el retorno del método
invocado. La interfaz DialogInvoker también incluye un método que se invoca cuando el
diálogo se está cerrando para cualquier necesidad de procesamiento en ese momento.
49
6.5.8 Diálogo para creación y modificación de filtros
Figura 6-22: Diseño de diálogo para crear y modificar filtros
Este dialogo se despliega cada vez que se requiera crear o modificar el filtro de un
parámetro tipo filtro o de una fórmula tipo search. Cuenta con un único método estático
que entre otros parámetros, tiene el filtro que se desea mostrar en los campos de este. El
diálogo cuenta con campos para especificar o cambiar el nombre del filtro, la consulta y el
lenguaje en que esta se encuentra, y con un panel para los parámetros de la consulta. Este
panel al igual que otros anteriores utiliza una tabla para presentar los valores.
6.5.9 Diálogo para selección de parámetros
El objetivo de este dialogo es asociarle valores a diferentes elementos de una decisión. Se
requiere al momento de asignar un parámetro a una función en la sección de cómputos. En
este caso el diálogo despliega una lista con los parámetros tipo simple, tipo filtro, o
variables declaradas en cómputos anteriores, que sean del mismo tipo que el parámetro de
la función. Cuando se están creando movimientos contables, se utiliza para encontrar un
valor y asignárselo a la cantidad que será agregada o extraída de una cuenta. Para este tipo
de consulta, se filtran los parámetros para que se visualicen solo los que sean números
50
enteros o reales. De forma similar, al momento de asignarle valores a los atributos de un
movimiento contable, se requiere filtrar según el tipo del atributo.
Figura 6-23: Diseño de diálogo para selección de parámetros
Para cumplir su labor, este diálogo requiere de las interfaces de consulta de varios
manejadores. Dependiendo del método estático que se invoque, el diálogo desplegará una
lista de parámetros extraídos de los manejadores. El parámetro escogido es retornado a
través del método dialogCallback del DialogInvoker asignado.
6.5.10 Diálogo para selección de cuentas
Como se explicó anteriormente, es necesario especificar una cuenta sobre la cual se
realizará un movimiento contable. Este diálogo se encarga de desplegar la lista de cuentas
y de proveer opciones para filtrarlas según sus características. Para ello, utiliza la interfaz
de consulta de cuentas que implementa el manejador de movimientos contables. Es posible
también buscar por el nombre de la cuenta sobre la lista que se presente en un momento
dado.
51
Figura 6-24: Diseño diálogo para selección de cuentas
52
7 Producto Desarrollado
El proceso de diseño conlleva finalmente a la implementación del manejador de decisiones.
Para esto se utilizó Eclipse 3.5 como entorno de desarrollo, junto con el plug-in para Qt
Jambi. En esta sección se presentan las funcionalidades de la aplicación que se lograron
materializar y lo que se alcanzó en términos de métricas. En primera medida se presentan
los requerimientos más importantes y la forma en que estos se cumplen en la interfaz
gráfica. Luego se presentan diferentes métricas sobre tamaño del producto y características
del código implementado.
7.1 Alcance Obtenido
A continuación se demuestra la implementación de los requerimientos más importantes a
partir de la definición de una decisión ya existente. Se presentan las diferentes etapas a
través de las cuales el usuario pasa para crear la decisión “BuyAsset” del Juego Gerencial.
Al momento de iniciar la aplicación, todos los campos se encuentran vacíos y el usuario irá
completándolos según sea necesario en el caso de esta decisión.
7.1.1 Datos básicos de una decisión
Las propiedades de una decisión son: el nombre, la descripción la acción y el tipo. Con
estas propiedades se define el cuerpo de la decisión para ser identificada dentro del sistema.
Figura 7-1: Introducir datos básicos de una decisión
53
Tanto las acciones como el tipo son campos de selección predeterminados que ayudan al
usuario a definir una definición. Dichos campos son: Decisión y compromiso, producción y
mercadeo respectivamente.
7.1.2 Creación de parámetros simples
La creación de los parámetros simples consiste principalmente en tres partes mostradas a
continuación. La primera es una ventana que ayuda al cliente a determinar si el parámetro
que se desea crear es un tipo Simple, o un tipo Filtro. Esto se realiza por medio de un
cuadro de selección tipo Combo box con el fin de restringir y guiar al usuario como se
ilustra en la Figura 7-2. El manejo de las ventanas de selección se hace modal, de tal
manera el usuario debe seleccionar una opción antes de proseguir con el siguiente paso.
Figura 7-2: Creación de un parámetro simple
Luego de tener el parámetro creado se procede a asignar un identificador (nombre), y una
descripción de dicho parámetro. La tercera parte, consiste en asignar las características
específicas como un tipo y en algunos casos especiales un valor inicial. Esto se demuestra
en la Figura 7-3.
7.1.3 Creación de parámetros filtro
Un parámetro de tipo filtro se crea de una manera similar a como se crea uno tipo simple.
Consiste también en tres actividades distintas: La primera es seleccionar el tipo de
parámetro por medio del mismo dialogo de selección. Una vez se haya creado el parámetro,
54
se procede a definir los campos de nombre y descripción, de igual manera que pasa en el
caso de los parámetros de tipo simple. La Figura 7-4 ilustra este caso.
Figura 7-3: Configuración de un parámetro simple ya creado
Figura 7-4: Configuración de un parámetro tipo filtro
55
Teniendo los campos anteriores se procede a definir un tipo de filtro. Esto se refiere al tipo
de objeto que retorna el parámetro. El cual, proviene del modelo del Juego Gerencial y
puede ser un elemento cualquiera dependiendo de los requerimientos de la decisión. De
dicho elemento se escoge un atributo (show) que será utilizado por la interfaz gráfica del
Juego Gerencial.
El diálogo de selección DialogModelNavigation introducido anteriormente se despliega
como un navegador del modelo del Juego Gerencial El modelo está mostrado a manera de
árbol así como lo ilustra la Figura 7-5. La idea de esta clasificación es permitirle al usuario
navegar por las raíces, y llegando al elemento buscado. Adicionalmente se le presenta un
filtro de palabras en caso de que el usuario conozca el elemento de interés.
Figura 7-5: Diálogo de navegación del modelo del Juego Gerencial
Teniendo la definición básica del filtro se procede a asociarle una consulta, parte central del
parámetro de tipo filtro. Esto se hace por medio del DialogFilterDefinition como se explicó
en la etapa de diseño. En él se define un nombre, una consulta escrita en el lenguaje EJBQL
o SQL y una serie de parámetros para esta, como se observa en la Figura 7-6.
Figura 7-6: Definición de un Filtro
56
El usuario debe encargarse de introducir la consulta, alcance propuesto para este proyecto.
La definición de parámetros para esta consulta se hace manualmente en esta versión del
manejador.
7.1.4 Declaración de fórmulas
En el orden de definición de una decisión sigue la declaración de las fórmulas. Estas tienen
una definición general al igual que el caso de parámetros. Esta consiste en establecer un
nombre, tipo, descripción y tipo de retorno. Una vez se hayan definido estas propiedades
generales se procede a establecer las propiedades puntuales para cada tipo diferente de
fórmula. Dependiendo del tipo seleccionado, la fórmula tiene asociada a ella un servicio, un
filtro o una expresión según sea el caso.
Figura 7-7: Configuración de una fórmula tipo search
Las fórmulas pueden tener parámetros asociados para realizar su operación, y serán
profundizados en la siguiente sección. La Figura 7-7 presenta una fórmula
f_TerrainAssetType con un parámetro pf_TerrainName.
7.1.5 Ordenamiento de cómputos
Computations es una sección de la definición de una decisión en la cual el usuario define el
orden de ejecución de las formulas. La aplicación por defecto crea variables en orden
numérico. Sin embargo, el usuario puede modificar este campo para brindar un
identificador personalizado. La expresión consiste en la invocación de una fórmula o un
57
filtro. Esta selección define el campo del tipo de computación. Es en este punto donde se le
asignan a los valores usador por las formula y filtros dentro de la aplicación.
Figura 7-8: Creación de cómputos para una decisión
En la definición de los cómputos de la decisión se invocan (se le da valor a los parámetros
que se encuentren asociados a la función), los diferentes parámetros con el fin de permitirle
a la función realizar los cálculos definidos. Una variable de cómputo puede ser invocada en
uno de los parámetros de otra variable de cómputo, permitiendo que las formulas se
invoquen de manera secuencial.
7.1.6 Definición de transacciones contables
Las transacciones contables son transacciones que tienen movimientos asociados. Una
transacción contable está definida por medio de un identificador y una unidad sobre la cual
se realiza la transacción. Por otra parte un movimiento asociado a una transacción, tiene
una cuenta sobre la cual se realiza el movimiento, una cantidad, una operación y un tipo. La
operación indica si es un tipo de movimiento, es un uso o una fuente, para ejecutar el
movimiento sobre dicha cuenta. Por otra parte existe el tipo de operación, el cual indica si
el movimiento que se desea realizar es de tipo adición o sustracción.
58
Figura 7-9: Adición de transacciones contables
La transacción TF1 que se presenta en la Figura 7-9 posee dos movimientos. A cada uno de
estos se le debe asociar una cuenta. La cual, se selecciona en el diálogo de la Figura 7-10.
Esta cuenta se obtiene a partir de un archivo de propiedades, preestablecido en los datos de
la aplicación. El diálogo de selección de cuentas (DialogAccountSelection) permite al
usuario tener a disposición la totalidad de cuentas existentes en el Juego Gerencial. Estas
cuentas pueden ser filtradas por: nombre de la cuenta, reporte (El reporte es el asociado en
el reporte: balance general, flujo de caja y flujo de entrada) y tipo. Dentro de cada reporte
existe otro filtro, que permite buscar por cada una de las categorías del reporte.
Figura 7-10: Diálogo para seleccionar una cuenta
59
7.1.7 Definición de transacciones operativas
Las transacciones operativas estas compuestas por un identificador o nombre definido por
el usuario, y por una unidad sobre la cual se realiza la transacción. Por cada transacción se
definen unos movimientos en su respectiva fila de la tabla. Hay una columna donde definen
un estado operativo y otra columna para la operación. Al escoger el estado operativo de un
movimiento se actualiza la tabla de atributos. En ella el usuario puede escoger qué valor de
un cómputo le asigna a cada atributo. En el caso de la Figura 7-11, al atributo serialNumber
se le asigna el valor de la variable var1 definida anteriormente.
Figura 7-11: Creación de movimientos operativos
La aplicación en su totalidad maneja unos filtros de tipo, estos filtros ayudan a guiar al
usuario en el manejo de la aplicación, desplegándole solamente la información que le sirve.
7.1.8 Generar archivos MAGES
La generación de la decisión usando la gramática MAGES consiste en producir dos
archivos. El primero contiene la definición de parámetros, de cómputos y de ambos tipos de
transacciones. El segundo archivo contiene la definición de filtros y fórmulas. El generador
de archivos MAGES toma todos los datos de los diferentes manejadores de la aplicación y
siguiendo las reglas específicas de sintaxis escribe los dos archivos con extensión .mages.
Antes de empezar la generación de los archivos, la aplicación verifica que cada uno de los
elementos que participa en la decisión se encuentre correctamente definido. De presentar un
error en alguno de estos, la aplicación se lo comunica al usuario indicando dónde se
encuentra error y qué propiedad del elemento se encuentra mal definida.
60
Figura 7-12: Generar archivos con sintaxis Mages
7.1.9 Guardar la decisión
Una definición de una decisión se puede guardar en cualquier momento según lo requiera el
usuario. Para mejorar la interactividad con el usuario la aplicación maneja un control de
cambios. Este le permite proteger su trabajo, alertándolo ante posibles pérdidas de
información. La decisión se guarda con la extensión .decis. La Figura 7-13 ilustra la opción
en la interfaz gráfica para almacenar este archivo.
7.1.10 Abrir la decisión
Una decisión que ha sido guardada por medio de este manejador de decisiones, puede ser
cargada para editar sus propiedades o generar los archivos Mages. Cuando se desea abrir
una decisión, durante la edición de otra, el control de cambios informa al usuario si es
necesario guardar de nuevo la decisión para no perder los datos que se están editando en ese
momento. La Figura 7-14 demuestra el uso de la aplicación para seleccionar el archivo con
extensión .decis de la decisión que luego será modificada.
61
Figura 7-13: Guardar una decisión para su futura modificación
Figura 7-14: Selección de archivo con extensión .decis
62
7.2 Métricas
En esta sección se presenta el producto terminado en términos de su tamaño y tiempo
invertido. Se expone también la complejidad ciclomática de diferentes partes del manejador
de decisiones con el fin de evaluar su modificabilidad.
7.2.1 Tamaño del producto
A continuación se presentan el número de paquetes, clases y líneas de código
implementadas. Se debe tener en cuenta que la librería Qt Jambi genera código de forma
automática para los diferentes componentes gráficos que se utilizan. En las siguientes tablas
se presentan solo aquellos elementos totalmente implementados por el grupo de desarrollo.
7.2.1.1 Paquetes implementados
Fuente Número de paquetes
Lógica de negocio 16 Interfaz gráfica 14
TOTAL 30
Paquetes generados por Qt Jambi: 11
Total paquetes aplicación: 41
7.2.1.2 Clases implementadas
Fuente – Lógica de Negocio Número de clases LOCs
Manejador de Parámetros 4 520 Manejador de Fórmulas 4 536 Manejador de Cómputos 4 435
Transacciones 3 106 Manejador de Transacciones Contables 4 362 Manejador de Transacciones Operativas 4 641 Generador MAGES 2 350 Manejador de Decisiones 2 160 Lector de modelos Entidad-Relación 3 287 Filtros 3 169
Eventos de Notificación y Excepciones 5 100 BaseModel y observadores 2 50 Constantes de tipos 15 153 Utilitarios 2 181
TOTAL 57 4050
63
Fuente – Interfaz Gráfica Número de clases LOCs
Panel de Parámetros 4 563 Panel de Fórmulas 10 1627 Panel de Cómputos 3 390
Panel de Transacciones Contables 5 1026 Panel de Transacciones Operativas 4 677 Interfaz principal DecisionManagerUI 2 685 Diálogos 7 1616 Panel Genérico para manejo de tablas 1 491 Widgets extendidos 9 374 Modelo de tabla genérica 2 92
TOTAL 47 7541
Clases implementadas: 104
Clases generadas por Qt Jambi: 33
Total Clases aplicación: 137
7.2.1.3 Líneas de Código
Fuente LOCs
Lógica de negocio 4218 Interfaz gráfica 7561
TOTAL 11779
Líneas de código generadas por Qt Jambi: 1828
Total líneas de código de la aplicación: 13607
7.2.2 Métricas de Productividad
En esta sección se presenta la información sobre el tiempo invertido en la implementación y
el cálculo de la productividad del grupo de trabajo. Se expone la cantidad de horas que se
trabajó durante cada semana del proyecto y por último se realizan los cálculos de
productividad con base en la cantidad de líneas de código presentes en el producto final.
7.2.2.1 Tiempo de implementación
La Figura 7-15 presenta la cantidad de horas dedicadas a la implementación. En cada
semana se señala el número de horas que el grupo de trabajo invirtió en la respectiva
implementación del momento. El tiempo dedicado a cada actividad es muy influenciado
por los constantes cambios en la aplicación debido a la progresiva comprensión del
problema que se buscaba resolver. Se presenta el caso específico de la semana catorce en
que se realizaron modificaciones importantes respecto a la sección de cómputos de la
decisión que se esté construyendo.
64
Figura 7-15: Tiempo dedicado a la implementación
7.2.2.2 Cálculo de productividad
Para determinar la productividad del grupo de trabajo se toma el número total de líneas de
código (LOC) que implementó cada integrante y se divide entre el número de horas que
cada uno dedicó a esta labor. Luego se obtiene el promedio de estos valores para establecer
la productividad del grupo.
Integrante LOC
implementadas
Horas
trabajadas
Productividad
(LOC/ hora)
Daniel Tovar 5579 341 16.36
Jesús Vargas 6200 349 17.76
Total 11779 690 ---
Productividad del grupo de trabajo: 17 LOC / hora hombre
Esta métrica servirá como referencia en futuros proyectos para estimar cuánto tiempo se
requerirá para desarrollarlo. Así se cuenta con un dato histórico para contribuir a una mejor
evaluación del tiempo de desarrollo, con base en una estimación de las líneas de código a
implementar.
7.2.3 Complejidad Ciclomática
La complejidad ciclomática es una métrica de cuántos caminos de ejecución posee una
porción de código [MCC76]. Esto afecta directamente la facilidad de comprender el código
y por consecuente, afecta la modificabilidad de la aplicación. En general, se considera que
55 52
40
31
51 48
20
50 53 55 57
4236
68
32
0
10
20
30
40
50
60
70
80
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Semana
Horas Dedicadas
65
una complejidad menor a 10 es adecuada. Sin embargo, puede haber excepciones que
tengan razones comprensibles. A continuación se presentan los resultados obtenidos.
Fuente –
Lógica de Negocio
Complejidad
Promedio
Desviación
Estándar
Máxima
Complejidad
Manejador de Parámetros 1.80 3.37 23 Manejador de Fórmulas 2.11 6.14 33
Manejador de Cómputos 1.56 1.21 6 Manejador de Transacciones Contables 1.51 1.17 6 Manejador de Transacciones Operativas 1.67 1.33 7 Generador MAGES 2.20 1.64 6 Manejador de Decisiones 1.08 0.39 3 Lector de modelos Entidad-Relación 3.00 3.70 12 Filtros 1.19 0.55 3
Fuente –
Interfaz Gráfica
Complejidad Promedio
Desviación Estándar
Máxima Complejidad
Panel de Parámetros 2.54 3.49 14 Panel de Fórmulas 2.68 3.05 14
Panel de Cómputos 2.46 3.39 14 Panel de Transacciones Contables 2.17 2.99 12 Panel de Transacciones Operativas 2.51 3.56 18
Interfaz principal DecisionManagerUI 1.88 1.58 7 Diálogos 4.27 12.93 85
Panel Genérico para manejo de tablas 3.38 3.70 14 Widgets extendidos 1 0 1
Modelo de tabla genérica 1.38 0.62 3
La complejidad máxima se obtiene a partir del método que tenga el valor más alto de esta
métrica, al interior de cada componente o grupo de clases antes presentados. En la sección
de conclusiones se hace la discusión sobre estos valores y sus implicaciones en la
aplicación.
66
8 Pruebas
Esta sección presenta la estrategia de validación de los diferentes componentes del
manejador de decisiones.
8.1 Descripción de Pruebas
Para hacer las verificaciones sobre los componentes de la aplicación se utilizaron diversas
aproximaciones. Como se vio previamente en el modelo de componentes de la aplicación,
algunos de estos requieren de interfaces de servicios expuestas por otros componentes. Por
esto, se decidió realizar una combinación de pruebas unitarias y pruebas de integración para
validar los componentes y su interacción. A su vez, y de forma paralela al desarrollo de la
aplicación se realizaron pruebas de sistema que se detallan más adelante.
8.1.1 Pruebas Unitarias: Manejadores de Parámetros y Fórmulas
Los manejadores de parámetros y fórmulas se probaron de forma aislada para asegurar su
correcto funcionamiento. Sobre estos se realizaron pruebas unitarias de sus operaciones
más relevantes. Por ser componentes independientes y que no requieren servicios de otros
componentes, una correcta verificación aseguraría que al momento de integrarlos con otros
elementos de la aplicación se lograse tener una base ya probada.
Manejador de Parámetros
Para este manejador se decidió enfocar la atención de las pruebas en la actualización de las
propiedades de los parámetros tipo simple y filtro. Hay una variedad de restricciones
respecto a las actualizaciones válidas para estos parámetros. Por lo cual, se evalúa que el
componente sea capaz de responder adecuadamente a estos casos. Inicialmente se tienen
dos parámetros: uno de tipo simple con identificador idSimpleParam y otro de tipo filtro
con identificador idFilterParam.
1. Pruebas de actualizaciones básicas – todos los datos válidos
Acción Resultado Esperado
Modificar nombre de idSimpleParam
Al consultar por sus respectivos identificadores, los parámetros retornados poseen los valores que se modificaron
Modificar descripción de idSimpleParam
Modificar el tipo de idSimpleParam
Modificar el valor inicial de idSimpleParam
Modificar el nombre de idFilterParam
Modificar el tipo de retorno de idFilterParam
Modificar el atributo a mostrar de idFilterParam
Asignarle un filtro a idFilterParam
67
2. Pruebas de actualizaciones sobre el tipo de un parámetro simple
Los siguientes casos se ejecutan de forma secuencial:
Caso 1
Acción Resultado Esperado
Modificar idSimpleParam para que maneje números reales.
No le lanza ninguna excepción Asignarle a idSimpleParam un número real como valor inicial
Caso 2
Acción Resultado Esperado
Asignarle a idSimpleParam una cadena de caracteres como valor inicial
Se lanza una excepción y se conserva el valor inicial de número real asignado previamente
Caso 3
Acción Resultado Esperado
Modificar idSimpleParam para que su valor inicial sea nulo
No le lanza ninguna excepción Modificar idSimpleParam para que maneje
cadenas de caracteres
Asignarle a idSimpleParam una cadena de caracteres como valor inicial
3. Pruebas de asignación de nombres
Acción Resultado Esperado
Asignarle a idSimpleParam un nombre X Se lanza una excepción y se conserva el nombre Y de idFilterParam asignado previamente
Asignarle a idFilterParam un nombre Y
Asignarle a idFilterParam el mismo nombre X
Manejador de Fórmulas
Para este manejador se decidió enfocar la atención de las pruebas en la actualización de las
propiedades de las formulas de tipo service, search y de operación. Además de eso, se
probaron las acciones de eliminar una formula seleccionada. Se probó también la
actualización de atributos específicos asociados a formulas con tipo definido.
68
1. Pruebas de actualizaciones básicas – todos los datos válidos
Acción Resultado Esperado
Modificar el nombre de formula operative
Al consultar por sus respectivos
identificadores, los parámetros retornados poseen los valores que se modificaron
Modificar el nombre de formula search
Modificar el nombre de formula service
Modificar el tipo de formula operative
Modificar el tipo de formula search
Modificar el tipo de formula service
Modificar el atributo descripción de formula operative
2. Pruebas especificas
Los siguientes casos se ejecutan de forma secuencial
Caso 1
Acción Resultado Esperado
Modificar atributo nombre de una fórmula Si el valor del atributo es true entonces se elimina el valor y no se asigna el nombre
Asigna el valor al atributo
Caso 2
Acción Resultado Esperado
Modificar la expresión de una fórmula Lanza una excepción en caso que la fórmula no deba contener una expresión.
Caso 3
Acción Resultado Esperado
Borrar la fórmula que se está editando Lanza una excepción, en caso que la cuenta de referencias sea mayor a cero
8.1.2 Pruebas de Integración: Manejador de Cómputos
Ya probados individualmente los manejadores de parámetros y fórmulas, se puede
continuar construyendo la jerarquía de componentes para sus respectivas pruebas. El
manejador de cómputos es el encargado de crear el orden de la invocación de fórmulas
tomando valores obtenidos de los parámetros simples, filtro y el resultado de otros
69
cómputos. Así, se definieron pruebas de descomposición funcional siguiendo la estrategia
Bottom-Up [ZTW03]. Con esta, se evalúa su función de integrar parámetros a las variables
de cómputo que se vayan creando. En general, el modelo de pruebas para la aplicación es
basado en esta aproximación puesto que los próximos componentes requieren de resultados
obtenidos a partir del manejador de cómputos.
A continuación se presentan las pruebas realizadas sobre la integración del manejador de
cómputos con los manejadores de parámetros y fórmulas. Todo esto se hace teniendo en
cuenta que se ha definido lo siguiente:
Parámetros:
- Simple1 : Real
- Simple2 : Real
- Filtro1: Unidad de Negocio
- SimpleStr : String
Fórmulas:
- F1( p1_1: Real, p1_2: Real) : Real
- F2( p2_1: Unidad de Negocio, p2_2: String): Real
- F3( p3_1: Real): Real
- F4(p4_1: String): String
1. Asociación de una fórmula a una instrucción de cómputo
Acción Resultado Esperado
Creación de una instrucción var1 Var1 tiene el mismo tipo de retorno que F1 Asociación de F1 a var1
Eliminar F1desde el manejador de fórmulas No es posible eliminar la fórmula porque var1 la está referenciando
2. Asignar parámetros simple y filtro a los parámetros de una función
Acción Resultado Esperado
Asignar simple1 a parámetro p1_1 de F1 Var1 tiene tantos parámetros de cómputo, como parámetros tiene F1 Asignar simple2 a p1_2 de F1
Eliminar simple1 desde el manejador de parámetros
No es posible eliminar a simple1: F1 lo requiere
Creación de instrucción var2 y asociarle fórmula F2
Se probó en el caso anterior
Asignarle filter1 a p2_1 de F2
No es posible eliminar a filter1 desde el manejador de parámetros: F2 lo requiere
Asignar simpleStr a p2_2 de F2
Eliminar filter1 desde el manejador de parámetros
70
3. Asignar una instrucción de cómputo a un parámetro de una fórmula
Acción Resultado Esperado
Creación de instrucción var3 y asociación de F3
a var3 Se probó en casos anteriores
Asignar var2 a p3_1 de F3 No es posible eliminar la instrucción var2 porque var3 la está referenciando Eliminar var2 desde el manejador de cómputos
4. Eliminar instrucciones y actualización en manejadores
Acción Resultado Esperado
Eliminar var3 en el manejador de cómputos En este orden se deben poder eliminar
todos ya que se pierden las referencias antes existentes
Eliminar F3 en el manejador de fórmulas
Eliminar var2 en el manejador de cómputos
Eliminar filter1 en el manejador de parámetros
8.1.3 Pruebas varias: Manejador de transacciones contables
El manejador de transacciones contables se prueba en dos etapas. Esto quiere decir que
dentro de sus métodos de prueba se incluyen tanto: Pruebas unitarias sobre la modificación
de sus atributos y pruebas de integración con el manejador de cómputos. Estos con el fin
de, además de probar sus método, probar la integración entre estos dos manejadores.
1. Pruebas de actualizaciones sobre las transacciones
Acción Resultado Esperado
Modificar nombre Al consultar por sus respectivos identificadores, se verifica que la transacción se actualice correctamente.
Modificar unit
2. Pruebas de actualizaciones sobre los movimientos
Acción Resultado Esperado
Asociar un movimiento La lista de movimientos se incrementa en 1
Acción Resultado Esperado
Modificar la cuenta Los valores se actualizan, correctamente al modificar los atributos de los movimientos.
Modificar el tipo de la operación
Modificar el OP
Modificar la cantidad
En la prueba de modificar la cantidad, vale la pena mencionar que se restringe a que tome
valores de tipo filtro y valores de tipo instrucciones de cómputo.
71
8.1.4 Pruebas de integración: Manejador de transacciones operativas
Para el manejador de transacciones operativas se construyen los casos de prueba a partir de
los parámetros, fórmulas y cómputos definidos en las pruebas del manejador de cómputos.
Habiendo probado este manejador, se puede proceder en la jerarquía de componentes y
evaluar ahora la integración con el manejador de transacciones operativas. Se busca
asegurar que la interacción entre estos dos componentes sea correcta. Para ello, se valida
que al momento de asignar, modificar o eliminar elementos de una transacción operativa, se
vean los cambios adecuados en los cómputos que se puedan referenciar.
En este caso se tiene el siguiente escenario:
Hay una transacción operativa OT1 con un movimiento OM1. Este movimiento tiene varios
atributos, entre ellos: OA1 de tipo Real y OA2 de tipo String. Las pruebas realizadas son:
1. Asignar una variable de cómputo a un atributo operativo
Acción Resultado Esperado
Asignar var3 al atributo operativo OA1 Var3 no puede ser eliminado por estar en uso. Eliminar var3 en el manejador de cómputos
Cambiar la fórmula asociada a var3, de F3 a F1. No es posible realizar el cambio porque var3 está referenciada por OA1
2. Reemplazar una variable de cómputo asociada a un atributo operativo
Acción Resultado Esperado
Asignar var3 al atributo operativo OA1 El cambio es permitido pues ambas variables son del mismo tipo (reales).
Después de la operación nadie referencia a var3 y a var2 se le adiciona una referencia.
Asignar var2 a OA1
3. Evaluar referencias después de remover un movimiento operativo
Acción Resultado Esperado
Asignar var2 al atributo operativo OA1 La operación es permitida y var2 debe tener una referencia menos al final de la
operación. Eliminar el movimiento OM1
4. Evaluar referencias después de remover una transacción operativo
Acción Resultado Esperado
Asignar var2 al atributo operativo OA1 La operación es permitida. Las variables var2 y var4 deben tener una referencia menos al final de la operación.
Asignar var4 al atributo operativo OA2
Eliminar la transacción OT1
72
8.1.5 Pruebas de Sistema
A medida que se agregaban funcionalidades se realizaban pruebas sobre toda la aplicación
para asegurar que se cumplieran las expectativas. Fue un proceso de construcción
incremental en el que hubo momentos en que se debían reformular aspectos de la lógica
para manejar los datos de una decisión. Adicionalmente, la forma en que se presentaba esta
información en la interfaz de usuario debió modificarse en varias ocasiones. Estos cambios
fueron causados por el constante proceso de aprendizaje sobre la definición de una decisión
y por las reuniones de seguimiento. Así, se plantearon esta serie de pruebas que se debían
realizar después de cada mayor modificación para asegurar que la aplicación resolviera el
problema deseado:
1. Se inicia la aplicación y el cliente debe editar las propiedades de la decisión. Se
selecciona la opción en el menú y se abre el dialogo correspondiente. La información es
introducida y aceptada por el usuario. Se verifica que la información haya sido
almacenada abriendo de nuevo estas propiedades y verificando que los cambios
persistan.
2. Se crea un nuevo parámetro, seleccionando la opción de tipo simple. Se verifica que la
interfaz se actualice de manera correcta creando una nueva fila en la tabla para la
definición de dicho parámetro.
3. Se crea un nuevo parámetro de tipo filtro. Se introduce el mismo nombre del parámetro
anterior y se verifica que la aplicación prohíba la repetición de nombres.
4. Se realiza la corrección del nombre y se definen sus propiedades básicas, las cuales
incluyen la definición de un filtro asociado el cual debe ser definido en su totalidad. Una
vez asociado se accede nuevamente y se verifica la información que se encuentra en
dicho dialogo.
5. Se crea una fórmula de tipo operación. La interfaz actualiza los campos ofreciendo al
usuario campos para introducir la expresión y hacer uso del editor y del validador de
expresiones.
6. Se crea una fórmula de tipo búsqueda. La interfaz debe proveer un acceso al dialogo de
definición de filtros para asociarle una consulta a la fórmula.
7. Se crea una fórmula de tipo servicio y se verifica que los campos para introducir un
proveedor de servicio sean desplegados en la interfaz.
8. Se crean parámetros sobre las fórmulas existentes, cambiando la selección de las mismas
para verificar que las vistas en las tablas se actualicen dependiendo de la fórmula
escogida.
9. Se procede a definir el segmento de cómputos, donde se crea una nueva instrucción.
Dicha instrucción debe desplegar la información a definir y se le asocia una expresión.
La expresión asociada se selecciona del diálogo de parámetros. Este puede desplegar
fórmulas, parámetros simples y filtro, y otras instrucciones de cómputo. Para este caso
debería filtrar solo por fórmulas.
10. Sobre cada instrucción se verifican parámetros involucrados y se procede a realizar
asociaciones de valor. Se utiliza el diálogo de parámetros que filtra elementos por el
tipo del parámetro que se desea asociar.
11. Se procede a crear una transacción contable. Se verifica que el campo de unidad de
negocio solamente permita seleccionar elementos que tengan ese tipo de retorno.
73
12. Se crea un movimiento asociado a la transacción creada, sobre la cual se presentan los
campos que permiten su edición. La cuenta es seleccionada de una lista de cuentas,
desplegada en un dialogo que permite realizar búsquedas. Se prueban búsquedas sobre
las cuentas para verificar que el filtro esté funcionando correctamente y finalmente se
selecciona una.
13. La definición de las transacciones operativas implica la creación de una transacción y
asociarle un número de movimientos. Se verifica que las vistas se actualicen
desplegando los atributos del movimiento cada vez que se cambia la selección de este.
Para asociarle valores a los atributos, solamente deben mostrarse instrucciones de
cómputo en el diálogo de selección de parámetros.
14. Una vez definidos los campos de la definición de la decisión, se procede a guardarla.
Se selecciona la opción de guardar y se introducen los datos pedidos por el sistema.
15. Se selecciona la opción “Nueva Decisión” en el menú de opciones verificando que los
datos anteriores se borren de la interfaz. En caso de haber realizado modificaciones
después de guardarla, debe desplegarse un mensaje manifestando los cambios.
16. Se realiza la carga de la decisión seleccionando “Abrir Decisión” y ubicando el archivo
guardado anteriormente. Se verifican que los datos se hayan cargado de manera
exitosa, ubicando datos específicos.
17. Finalmente la última prueba consiste en generar el archivo MAGES. Se verifican que
los diálogos para la generación de los archivos se despliegan de manera correcta. Se
identifican las rutas y nombre de los archivos. Una vez creados los archivos, se verifica
que estos tengan la información correspondiente en el lenguaje de dominio específico
indicado.
8.2 Ejecución de Pruebas
Todas las pruebas se ejecutan de forma correcta y se obtienen los resultados esperados.
Estas pruebas sirvieron para señalar algunas fallas que pudieron ser corregidas
adecuadamente en tiempo de implementación. Las pruebas unitarias y de integración
contribuyeron a asegurar una correcta dependencia entre los diferentes componentes de la
aplicación. Si bien no se probaron todas las posibilidades al interior de cada componente, se
asegura que las interacciones de mayor importancia funcionan adecuadamente. Esto se
refiere a la capacidad de asociar elementos que administran un componente con elementos
administrados por otros componentes. En la medida que se asegure que las relaciones entre
estos elementos sean consistentes, se puede decir que la decisión se ha construido de forma
adecuada.
Las pruebas de sistema a diferencia de las otras dos, se realizaron a la par de la etapa de
implementación. Esto permitió que se hicieran evidentes ciertos errores de la interfaz de
usuario y la forma en que esta interactúa con la lógica de negocio. A su vez, fueron de gran
utilidad en la medida que las diferentes personas que asesoraban el proyecto pudieron dar
su opinión y sugerencias de mejora sobre la forma en que se manejan los datos de una
decisión. Como se pudo observar, estas pruebas se realizaron enfocándose en los
requerimientos funcionales antes planteados buscando al mismo tiempo la usabilidad
deseada para la aplicación.
74
9 Conclusiones
En esta sección se presenta el resumen del trabajo realizado, discutiendo la forma en que se
cumplieron los objetivos del manejador de decisiones. A su vez se presentan las
oportunidades de mejora y de trabajo para futuros desarrollos.
9.1 Discusión
A continuación se analizan diferentes características de la aplicación y su efecto en los
resultados esperados. También se establecen problemáticas relacionadas con las decisiones
tomadas en diferentes etapas del proceso de desarrollo.
1. Se identificó una librería para interfaces gráficas que provee las funcionalidades
adecuadas para el manejo de tablas. Se buscaba presentar en la interfaz gráfica
elementos similares a los encontrados en aplicaciones de hojas de cálculo y que fuesen
agradables a la vista. Las pruebas realizadas para familiarizarse con Qt Jambi
demostraron que es una librería con una variedad de widgets que soportaban la
usabilidad deseada para la aplicación. Se debían buscar tácticas para resolver la
problemática de modificabilidad causada por el modelo signal-slots que incorpora esta
librería.
2. Se estudiaron los componentes de una decisión y la forma en que esta es construida y
luego incorporada en el Juego Gerencial. Este proceso no se dio en un solo momento
puesto que al iniciar el proyecto no se tenía total comprensión de los elementos de una
decisión al ser representados en los archivo XML. A medida que se fueron
comprendiendo sus respectivos papeles y relaciones, se construían diferentes elementos
de la aplicación. Por esta razón se buscaba plantear un diseño que favoreciera la
modificabilidad con el fin de agilizar el proceso de desarrollo y futuros cambios.
3. Las diferentes personas que conocen sobre el tema de las decisiones de este juego
lograron comprender satisfactoriamente la función de cada panel y ventana de la
aplicación. Solamente se necesitaron ciertas aclaraciones sobre elementos muy puntuales
de una decisión. Por lo cual, se considera que el proyecto logró plasmar los conceptos de
una decisión de forma adecuada en una interfaz de usuario. Cumpliendo en buena
medida el escenario de calidad sobre la comprensión de la interfaz gráfica por parte de
un nuevo usuario.
4. La división de la lógica de la aplicación en manejadores específicos demostró ser una
medida adecuada para favorecer la modificabilidad de la aplicación. Gracias a esta
estrategia fue posible una mejor distribución del trabajo del grupo de desarrollo. A su
vez, el proceso de pruebas puede ser dividido en elementos más puntuales al interior de
cada componente. La integración de estos componentes debió ser claramente establecida
a través de las interfaces de servicio expuesta por cada uno de ellos. Sin embargo, se
75
debió realizar un mejor trabajo en la especificación de estas interfaces para evitar
constantes modificaciones.
5. Qt Jambi presentaba una serie de limitantes en cuanto a la modificabilidad que se
deseaba para la aplicación. Por esta razón se tomaron una serie de decisiones que
potenciaran este atributo de calidad. Las que tuvieron mayor utilidad fueron la
implementación de clases obervables-observador y la creación de widgets extendidos. El
primer caso no requirió mayor tiempo de implementación puesto que es muy similar al
modelo que maneja Java Swing. Sin embargo, su utilidad es claramente visible al
momento de desacoplar la lógica de negocio y la interfaz de usuario. Los diferentes
manejadores solo lanzaban eventos de notificación sin ser conscientes de que algún
panel de la interfaz lo recibiera. En cuanto a los widgets modificados, la adición del
modelo publicador-suscriptor presentó una mejoría en la modificabilidad ya que no
debían tenerse preocupaciones sobre mantener consistentes los nombres de los slots.
6. La utilización del panel genérico para el manejo de tablas demostró ser de gran utilidad
cuando se debían crear nuevos paneles. Es el caso del panel de cómputos que tuvo que
someterse a una gran cantidad de cambios debido a una mejor comprensión de la lógica
de una decisión. Ante este tipo de situaciones que se podían dar en cualquier momento,
utilizar este panel genérico logró reducir el tiempo de dichos cambios y proporcionaba la
lógica necesaria para agregar y eliminar elementos a la tabla. Con esto, cualquier cambio
deseado se puede realizar únicamente en este panel y verse reflejado en diferentes
puntos del programa. La limitante sobre este panel es su capacidad de configuración
visual. En el futuro se le pueden agregar otros elementos que pueden ser desplegados en
la tabla.
7. Una de las actividades para potenciar la modificabilidad de este producto era alcanzar
una baja complejidad ciclomática. En términos generales se logró el objetivo, sin
embargo, hay casos puntuales que causan elevados niveles de esta métrica. El caso más
notorio es uno encontrado en el diálogo de selección de cuentas. Este es el causante de la
complejidad de 85 debido a la gran cantidad de puntos de decisión implementados para
filtrar la lista de cuentas. De igual forma, las mayores complejidades se observan en
métodos que se encargan de las verificaciones de porciones de una decisión. Esto era de
esperarse debido a los múltiples caminos de ejecución que tiene evaluar cada caso.
Elevados niveles de complejidad ciclomática afectan la modificabilidad de la aplicación
ya que se requiere más tiempo para comprender la función de una sección de código.
9.2 Trabajo Futuro
A continuación se listan características que pueden tenerse en cuenta a futuro:
1. El objetivo principal de la aplicación es que el profesor sea capaz de introducir toda una
decisión e incorporarla a la herramienta del Juego Gerencial. Para ello, no debería poseer
conocimiento sobre consultas SQL o EJBQL. Se propone entonces la inclusión de un
76
medio interactivo para crear las consultas de los filtros en el manejador de decisiones.
Debería ser una herramienta visual e intuitiva que le facilite la labor al usuario.
2. Implementar un componente que almacene la información de la decisión que vaya
introduciendo el usuario. Así se tiene un registro del proceso de definición y brinda la
facilidad de retroceder a un estado previo de la decisión en caso de que se quieran
descartar cambios.
3. Adicionar un validador para los nombres de los elementos que se declaren en la
decisión. Los nombres que se le asignan a los parámetros, fórmulas y demás elementos
deben seguir un estándar para asegurar una mejor comprensión por parte de otros
usuarios. Este componente se encargaría de manejar la lógica para asignarlos
adecuadamente según el tipo de elemento.
4. Incluir el manejo de parámetros complejos tanto en la lógica de negocio como en la
interfaz gráfica. Este tipo de parámetros no se tuvo en cuenta durante el desarrollo de
este proyecto para dedicar más tiempo en la comprensión e implementación de los
demás conceptos. Al momento de incluirlos, es posible evaluar la modificabilidad de la
aplicación basándose en dos escenarios de calidad antes propuestos.
5. Realizar pruebas de aceptación con un usuario final del Juego Gerencial. Para ello, se
debe contar con una versión estable de Mages-DL y que el generador de archivos con
esta gramática tenga las modificaciones necesarias para esta versión.
77
10 Referencias
[Bar03] Barbacci, M. Software Quality Attributes Tutorial: Modifiability and Usability.
Software Engineering Institute – Carnegie Mellon University (2004)
[BBN07] Bachman, F., Bass, L., Nord, R. Modifiability Tactics. (CMU/SEI-2007-TR-
002). Software Engineering Institute – Carnegie Mellon University (2007)
[Bec00] Beck, K. Extreme Programming Explained: Embrace Change, Addison
Wesley. (2000)
[Bez04] Bezivin, J. In Search of a Basic Principle for Model-Driven Engineering.
Novatica – Special Issue on UML (Unified Modeling Language) pp 21-24.
(2004)
[BS04]
Blanchette, J. Summerfield, M. C++ GUI Programming with Qt 3 – Prentice
Hall (2004)
[Fac10]
Facultad de Administración - Universidad de los Andes. Plan de Estudios -
Pregrado en Administración - Juego Gerencial. Recuperado Noviembre de
2010, de
http://administracion.uniandes.edu.co/pregrado_en_administracion/aspectos_a
cademicos/plan_de_estudios
[FRB04] Freeman, E., Robson, E., Bates, B., Sierra, K. Head First Design Patterns.
O’Reilly Media. (2004).
[Jug10] Departamento de Ingeniería de Sistemas y Computación – Universidad de los
Andes. Proyecto Juego Gerencial –
http://sistemas.uniandes.edu.co/~gerencial/wikijuego/doku.php?id=informacio
n_general
[Kal02] Kalle Dalheimer, M. Programing with Qt. O’Reilly Media; 2da Edición.
(2002)
[Küh05] Kühne, T. What is a Model? Language Engineering for Model-Driven
Software Development. Dagstuhl Seminar Proceedings 04101. (2005)
[MCC76] McCabe, T. A Complexity Measure. IEE Transactions On Software
Engineering, Vol SE-2. No. 4 (1976)
[NW04] Northover, S., Wilson, M. SWT: The Standard Widget Toolkit, Volume 1.
Addison-Wesley. (2004)
78
[OMG06] Object Management Group. Meta Object Facility (MOF) Core Specification.
The Object Management Group. Version 2. (2006)
[RV04] Robinson, M., Vorobiev, P. Swing (Second Edition). Dreamtech Press. (2004)
[RW05] Rozanski, N., Woods, E. Software Systems Architecture: Working with
stakeholders using viewpoints and perspectives. Addison Wesley. (2005)
[Sei03] Seidewitz, E.: What Models Mean. IEEE Software. Vol 20, No. 5, pp 26-32
(2003)
[Tel10] Téllez, L. MAGES-DL: Un lenguaje de Dominio Específico para un
Simulador Financiero. (2010)
[ZTW03] Zayu Gao, J., Tsao, J., Wu, Y., H.-S. Jacob, T. Testing and Quality Assurance
for Component-Based Software. Artech House Computer Library. (2003)
