Implementación de un manejador gráfico de decisiones para un simulador de juego empresarial

Texto completo

(1)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.

(2) 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 ii.

(3) Listado de Figuras Figura 3-1: QtDesigner para construcción de un dialogo Figura 3-2: Opciones de visualización del QtDesigner Figura 3-3: Qt Widgets Figura 5-1: Parámetros de una Decisión Figura 5-2: Filtro de un Parámetro Figura 5-3: Fórmula Figura 5-4: Transacciones Contables y Operativas Figura 5-5: Casos de Uso Figura 6-1: Patrón Observador del manejador de decisiones Figura 6-2: Modelo de propiedades BaseModel aplicado a la clase Parameter Figura 6-3: DecisionManager con manejadores específicos Figura 6-4: Diseño Manejador de Parámetros Figura 6-5: Diseño Manejador de Fórmulas Figura 6-6: Diseño Manejador de Cómputos Figura 6-7: Diseño Manejador de transacciones contables Figura 6-8: Diseño Manejador de transacciones operativas Figura 6-9: Diseño Generador de archivos MAGES Figura 6-10: Diseño Lector de Metamodelo Entidad-Relación Figura 6-11: Diagrama de Componentes Manejador de Decisiones Figura 6-12: Diseño de QWidgets extendidos Figura 6-13: Panel genérico para manejo de tablas Figura 6-14: Diseño panel genérico para el manejo de tablas Figura 6-15: Diseño GUI Manejador de Decisiones Figura 6-16: Diseño panel contenedor de parámetros Figura 6-17: Diseño panel contenedor de fórmulas Figura 6-18: Diseño panel contenedor de cómputos Figura 6-19: Diseño panel de transacciones contables Figura 6-20: Diseño panel de transacciones operativas Figura 6-21: Diseño diálogo para navegación del modelo del Juego Gerencial Figura 6-22: Diseño de diálogo para crear y modificar filtros Figura 6-23: Diseño de diálogo para selección de parámetros Figura 6-24: Diseño diálogo para selección de cuentas Figura 7-1: Introducir datos básicos de una decisión Figura 7-2: Creación de un parámetro simple Figura 7-3: Configuración de un parámetro simple ya creado Figura 7-4: Configuración de un parámetro tipo filtro Figura 7-5: Diálogo de navegación del modelo del Juego Gerencial Figura 7-6: Definición de un Filtro Figura 7-7: Configuración de una fórmula tipo search Figura 7-8: Creación de cómputos para una decisión Figura 7-9: Adición de transacciones contables Figura 7-10: Diálogo para seleccionar una cuenta Figura 7-11: Creación de movimientos operativos iii. 10 10 11 14 15 16 17 18 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 54 55 55 56 57 58 58 59.

(4) Figura 7-12: Generar archivos con sintaxis Mages Figura 7-13: Guardar una decisión para su futura modificación Figura 7-14: Selección de archivo con extensión .decis Figura 7-15: Tiempo dedicado a la implementación. iv. 60 61 61 64.

(5) 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.. v.

(6) Contenido 1 INTRODUCCIÓN. 1. 1.1 1.2 1.3. 1 2 3. DESCRIPCIÓN DEL PROBLEMA MOTIVACIÓN ORGANIZACIÓN DEL DOCUMENTO. 2 OBJETIVOS. 4. 2.1 2.2. 4 4. OBJETIVOS GENERALES OBJETIVOS ESPECÍFICOS. 3 MARCO TEÓRICO. 6. 3.1 METAMODELOS Y MODELOS 3.1.1 ¿QUÉ ES UN MODELO? 3.1.2 METAMODELOS Y SU RELACIÓN CON LOS MODELOS 3.2 QT JAMBI 3.2.1 HERRAMIENTA DE DESARROLLO QT 3.2.2 GUI TOOLKITS 3.2.3 ¿QUÉ SON LOS QWIDGETS? 3.2.4 MANEJO DE EVENTOS EN QT JAMBI. 6 6 7 8 8 9 11 11. 4 METODOLOGÍA DE TRABAJO. 13. 5 ANÁLISIS DE REQUERIMIENTOS. 14. 5.1 ESTRUCTURA DE UNA DECISIÓN 5.2 REQUERIMIENTOS FUNCIONALES 5.2.1 CREAR UNA DECISIÓN 5.2.2 GUARDAR UNA DECISIÓN 5.2.3 ABRIR UNA DECISIÓN 5.2.4 MODIFICAR UNA DECISIÓN 5.2.5 GENERAR ARCHIVO MAGES 5.3 ATRIBUTOS DE CALIDAD 5.3.1 USABILIDAD 5.3.2 MODIFICABILIDAD 5.4 ESCENARIOS DE CALIDAD 5.4.1 ESCENARIOS DE USABILIDAD 5.4.2 ESCENARIOS DE MODIFICABILIDAD. 14 18 18 19 19 19 19 20 20 21 22 22 23. 6 DISEÑO. 27. vi.

(7) 6.1 JUSTIFICACIONES DE DISEÑO 6.1.1 SEPARACIÓN EN MANEJADORES DE MENOR TAMAÑO 6.1.2 IMPLEMENTACIÓN CLASES OBSERVABLES Y OBSERVADORES 6.1.3 MODELO DE PROPIEDADES 6.2 DIAGRAMAS DE CLASE 6.2.1 MANEJADOR DE DECISIONES Y MANEJADORES SUBORDINADOS 6.2.2 MANEJADOR DE PARÁMETROS 6.2.3 MANEJADOR DE FÓRMULAS 6.2.4 MANEJADOR DE CÓMPUTOS 6.2.5 MANEJADOR DE TRANSACCIONES CONTABLES 6.2.6 MANEJADOR DE TRANSACCIONES OPERATIVAS 6.2.7 GENERADOR ARCHIVOS MAGES 6.2.8 LECTOR DE METAMODELO ENTIDAD-RELACIÓN 6.3 MODELO DE COMPONENTES 6.4 JUSTIFICACIONES DE DISEÑO INTERFAZ GRÁFICA 6.4.1 EXTENSIÓN DE COMPONENTES GRÁFICOS QT JAMBI 6.4.2 PANEL GENÉRICO PARA USO DE TABLAS 6.5 DIAGRAMAS DE CLASE INTERFAZ DE USUARIO 6.5.1 INTERFAZ DE USUARIO MANEJADOR DE DECISIONES 6.5.2 PANEL DE PARÁMETROS 6.5.3 PANEL DE FÓRMULAS 6.5.4 PANEL DE CÓMPUTOS 6.5.5 PANEL DE TRANSACCIONES CONTABLES 6.5.6 PANEL DE TRANSACCIONES OPERATIVAS 6.5.7 DIALOGO PARA NAVEGACIÓN DEL MODELO DEL J UEGO GERENCIAL 6.5.8 DIÁLOGO PARA CREACIÓN Y MODIFICACIÓN DE FILTROS 6.5.9 DIÁLOGO PARA SELECCIÓN DE PARÁMETROS 6.5.10 DIÁLOGO PARA SELECCIÓN DE CUENTAS. 27 27 28 28 29 29 31 32 33 34 35 36 37 37 38 38 40 42 42 43 44 45 46 47 48 49 49 50. 7 PRODUCTO DESARROLLADO. 52. 7.1 ALCANCE OBTENIDO 7.1.1 DATOS BÁSICOS DE UNA DECISIÓN 7.1.2 CREACIÓN DE PARÁMETROS SIMPLES 7.1.3 CREACIÓN DE PARÁMETROS FILTRO 7.1.4 DECLARACIÓN DE FÓRMULAS 7.1.5 ORDENAMIENTO DE CÓMPUTOS 7.1.6 DEFINICIÓN DE TRANSACCIONES CONTABLES 7.1.7 DEFINICIÓN DE TRANSACCIONES OPERATIVAS 7.1.8 GENERAR ARCHIVOS MAGES 7.1.9 GUARDAR LA DECISIÓN 7.1.10 ABRIR LA DECISIÓN 7.2 MÉTRICAS 7.2.1 TAMAÑO DEL PRODUCTO 7.2.2 MÉTRICAS DE PRODUCTIVIDAD 7.2.3 COMPLEJIDAD CICLOMÁTICA. 52 52 53 53 56 56 57 59 59 60 60 62 62 63 64. 8 PRUEBAS. 66. vii.

(8) 8.1 DESCRIPCIÓN DE PRUEBAS 8.1.1 PRUEBAS UNITARIAS: MANEJADORES DE PARÁMETROS Y FÓRMULAS 8.1.2 PRUEBAS DE INTEGRACIÓN: MANEJADOR DE CÓMPUTOS 8.1.3 PRUEBAS VARIAS: MANEJADOR DE TRANSACCIONES CONTABLES 8.1.4 PRUEBAS DE INTEGRACIÓN: MANEJADOR DE TRANSACCIONES OPERATIVAS 8.1.5 PRUEBAS DE SISTEMA 8.2 EJECUCIÓN DE PRUEBAS. 66 66 68 70 71 72 73. 9 CONCLUSIONES. 74. 9.1 9.2. 74 75. DISCUSIÓN TRABAJO FUTURO. 10 REFERENCIAS. 77. viii.

(9) 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.

(10) 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. 2.

(11) 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.. 3.

(12) 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.. 4.

(13)  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. 5.

(14) 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 6.

(15) 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 7.

(16) 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 8.

(17) 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. 9.

(18) Figura 3-1: QtDesigner para construcción de un dialogo. Figura 3-2: Opciones de visualización del QtDesigner 10.

(19) 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 11.

(20) 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.. 12.

(21) 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. 13.

(22) 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 14.

(23) 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. 15.

(24) 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 16.

(25) 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. 17.

(26) 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. 18.

(27)  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.. 19.

(28) 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. 20.

(29) 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. 21.

(30)  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.. 22.

(31) 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. 23.

(32) 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.. 24.

(33) 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 25.

(34) 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.. 26.

(35) 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 27.

(36) 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. 28.