Uso de la notacion UML en el desarrollo de aplicaciones educativas Antonio Edwin Benavente Morales Universidad Nacional de San Agustín Nucleo de NTIC en la Educación Perú abenavente@unsa.edu.pe Resumen Este documento se presenta como la descripción de una experiencia en el uso de la notación del Lenguaje Unificado de Modelado o UML, con el propósito de diseñar aplicaciones educativas. La clásica cuestión de por qué realizamos el análisis y diseño si lo que el usuario necesita es que el software funcione, marca la línea entre lo que el desarrollador debe hacer y lo que el usuario final y quienes encargan el producto, piensan que debe tener programa. La búsqueda de fórmulas para mejor concebir y realizar software educativo por quienes conforman el equipo multidisciplinario de desarrollo, tiene en este lenguaje de modelado, una herramienta valiosa a su favor, la que esperamos describir en su pertinente aporte. Introducción El Lenguaje Unificado de Modelado, en adelante UML (Unified Modeling Languaje), es el resultado mas integrador de una serie de métodos de análisis y diseño orientado a objetos. Originado entre fines de los ochenta y principios de los noventa, UML no fue concebido como un método en sí mismo, sinó como la notación básicamente gráfica de la que se puede valer cualquier método para expresar los diseños y el proceso que orienta los pasos a dar para realizar este diseño. Así completa lo que todo método debe presentar, un lenguaje de modelado y un proceso. Al proceso en sí, se le ha llamado Método Unificado (Unified Method u Objectory). El Lenguaje de Modelación Unificado y el Proceso Unificado, son el resultado del trabajo de los llamados "tres amigos" Grady Booch, Jim Rumbaugh e Ivar Jacobson. A nuestro propósito, resaltaremos el uso del lenguaje de modelado que permite al equipo multidisciplinario de desarrollo de software educativo comunicarse entre sí, pues al analizar un diseño, lo que el equipo necesita es un lenguaje de modelación más que el proceso seguido para lograr tal diseño. UML en el Análisis y Diseño de Software Educativo En tanto que este trabajo no pretende dar cátedra del Lenguaje de Modelación Unificado, toca resaltar los aportes de su aplicación, es decir, rescatar principalmente la comunicación que posibilita el UML entre los que diseñan y desarrollan el software educativo y quienes lo encargan. Se tiene por tanto, que uno de los mayores requisitos en el desarrollo de software educativo es el de elaborar un sistema "ad hoc", que atienda y resuelva las necesidades de los usuarios a un costo asumible. Esta labor se complica porque nuestro lenguaje formalizado y nuestro argot debe serle inteligible a los demás miembros del equipo, educadores de carrera, psicólogos en educación, expertos en el dominio del tema, diseñadores
gráficos, ingenieros de software, entre otros, que deben comprender las alternativas que se discuten para diseñar una aplicación educativa. Lograr un buen grado de comunicación, aparte de establecer una adecuada comprensión de los requerimientos del usuario final, es el punto de partida para el desarrollo del software educativo. La técnica que provee en esta situación el UML, es la referida a los Casos de Uso. Un caso de uso es una instantánea de algún aspecto del sistema. La acumulación de todos los casos de uso, constituyen la integridad del sistema, lo que que en suma permitirá una explicación de lo que el software educativo podrá hacer. Un notable conjunto de casos de uso es la esencia para comprender lo que quieren los usuarios finales y quienes encargan el software. Los casos de uso son entes pasibles de asumir el desarrollo iterativo, que es en sí mismo una técnica valiosa, puesto que retroalimenta de manera reiterativa a los miembros del equipo sobre el rumbo que va tomando el resultado del desarrollo. Aparte de que los casos de uso posibilitan la comunicación de los elementos superficiales, también se convierten en esenciales para observar las cuestiones más profundas. Esto implica saber cómo entienden su mundo en sus peculiaridades los expertos del dominio, en este caso lo profesores. Una herramienta fundamental en esta parte del UML, lo constituyen los diagramas de clases, muy valiosos en la medida en que se usen de modo conceptual. En otras palabras, debe tratarse cada clase (tecnología de objetos) como si fuese un concepto en la mente del usuario, como parte de su lenguaje. Los diagramas de clase que se diseña no son, por tanto, diagramas de datos o de clase, sinó diagramas del lenguaje de los usuarios. Otro aporte lo constituyen los diagramas de actividades, útiles en los casos en que los procesos de flujo de trabajo son una parte importante del mundo de los usuarios. Dado que los diagramas de actividades manejan procesos paralelos, pueden ayudar a deshacerse de secuencias innecesarias en el diseño del software. Objetivos que debe perseguir la realización de un análisis de software educativo Comprender el problema, objetivos, contenidos y situaciones de enseñanza-aprendizaje que tendrá que atender la aplicación. Suscitar cuestiones relevantes acerca los requerimientos educativos y las respuestas que pueda dar el sistema. Proporcionar una base para responder preguntas acerca de propiedades específicas del problema a atender y del sistema. Decidir lo que tiene que hacer el sistema. Decidir lo que no tiene que hacer el sistema. Asegurar que el sistema satisfaga las necesidades de los usuarios y definir los criterios de aceptación. Y, Proporcionar una base para el desarrollo del sistema. El Proceso de Desarrollo de Software Educativo Se afirma que el UML es un lenguaje para modelar, no un método. El UML no asume la noción de lo que es un proceso, el cual constituye una parte importante de un método. A pesar del Proceso Unificado (Objectory), no es posible contar con un solo proceso para el desarrollo de software en general y menos de aplicaciones educativas. Por otra parte distintos factores relacionados con el desarrollo de software conducen a diferentes tipos de procesos. Entre estos factores se incluye el tipo de aplicación que se está desarrollando y la escala del equipo involucrado en su construcción. Sin importar cual sea el análisis del proceso, puede emplearse cualquier proceso con el UML, sin duda el
Leguaje Unificado de Modelado es independiente del proceso. Hay que seleccionar algo adecuado para el tipo particular de proyecto que se esté realizando. Sea cual fuere el proceso con el que se trabaje, el UML puede servir para registrar las decisiones de análisis y diseño que resulten del requerimiento del software educativo. Estado del Arte e Indicadores de Calidad del Software Teniendo en cuenta el estado del arte en la construcción de software en general desde la década de los 90 en adelante, se tiene el predominio de las Tecnologías de Objetos y su generalización más completa, las Tecnologías de Componentes. De ese avance se rescata que los temas que se vienen desarrollando con mayor ahínco en foros académicos tienen que ver con asuntos tocantes a: Aplicaciones Cliente/Servidor Herramientas, Estrategias y Protocolos de Internet Metodología de Análisis y Diseño Interfaces Humano-Computador Diseño de Bibliotecas Concurrencia Persistencia Ciclo de Vida del Software Calidad del Software Reutilización, entre otros. Sobre la calidad del software se mencionan diversos parámetros de evaluación que ayudan a identificar sus fortalezas y debilidades, a cuyo efecto damos cuenta de los siguientes indicadores: a)corrección Entendida como la capacidad del software para realizar con exactitud sus tareas, tal y como se definen en las especificaciones. b) Robustez Es decir, la capacidad de los sistemas de software de reaccionar apropiadamente ante condiciones excepcionales. c) Extensibilidad Asumida como la facilidad de adaptar los productos de software a los cambios de especificación y requerimientos. d) Reutilización Capacidad de los elementos de software para servir para la construcción de muchas aplicaciones diferentes. e) Compatibilidad Vale decir, la facilidad de combinar unos elementos de software con otros. f) Eficiencia Concebida como la capacidad del software para exigir la menor cantidad posible de recursos hardware, tales como tiempo del procesador, espacio ocupado de memoria interna y externa o ancho de banda utilizado en los dispositivos de comunicación.
g) Portabilidad También llamada, transportabilidad, es decir, la facilidad de transferir los productos software a diferentes entornos hardware y software. h) Facilidad de Uso Es la facilidad con la cual las personas con diferentes formaciones y aptitudes pueden aprender a usar los productos software y aplicarlos a la resolución de problemas. También se involucra la facilidad de instalación, de operación y de supervisión. i) Funcionalidad Es el conunto de posibilidades que proporciona un sistema. j) Oportunidad Es la capacidad de un sistema de software para ser lanzado cuando los usuarios lo deseen o antes. A estos indicadores se añaden otras cualidades estrictamente del ámbito computacional como, Verificabilidad, Integridad, Reparabilidad y Economía. Fases del Lenguaje Unificado de Modelado Luego del análisis en el nivel más alto del proceso de desarrollo se tiene la secuencia a seguir, siendo sus fases, la Concepción, la Elaboración, la Construcción y por último, la Transición. Este proceso de desarrollo es de naturaleza iterativa e incremental, toda vez que el software no se entrega enteramente de una sola vez al final del proyecto, sinó que se desarrolla y entrega por partes, las que deben pensarse una y otra vez al tiempo de mejorar sus aportaciones. Durante la concepción, se establece finalidad del proyecto y se estima su alcance. Es aquí cuando se obtiene el compromiso quien encarga el proyecto para proseguir. En la elaboración se reúnen requerimientos mas detallados, se hacen análisis y diseños de alto nivel, a fin de establecer una arquitectura base y se crea el plan de construcción. Incluso en este tipo de proceso iterativo, hay trabajos que deben quedar para el final, la etapa de transición. Entre ellos están las versiones preliminares de evaluación, la afinación del funcionamiento y el entrenamiento del usuario. Los proyectos varían en función de la cantidad de aprobaciones que llevan consigo. Así tenemos que los proyectos que requieren muchas aprobaciones tienen muchas entregas formales en papel, reuniones formales, autorizaciones formales. Los proyectos de mínima aprobación y burocracia pueden tener una etapa de concepción que consista en un diálogo de una hora con quienes encargan el proyecto y un plan formulado en una hoja de cálculo. Es un hecho que cuanto más grande sea el proyecto, más aprobaciones necesitará. Los pasos fundamentales de las etapas también se llevan a cabo pero de un modo muy diferente. Si bien es cierto que las iteraciones se dan en todas las fases, es en la fase de construcción donde más se debe iterar. Un caso de Desarrollo de Software Educativo con UML Requerimiento:
Desarrollo de Software para Enseñanza de Química General, nivel de pregrado, orientado a estudiantes de ingeniería de procesos. Perspectiva de Alto Nivel 1. Concepción La concepción adopta muchas formas. Durante esta etapa se define: Los requerimientos económicos del proyecto. Vale decir, cuánto costará y cuánto permitirá, el software desarrollado, mejorar el aprendizaje mediado por computador vs aprendizaje convencional, además de aportar ideas sobre el impacto del uso de materiales educativos computarizados. La magnitud y alcance del proyecto. En esta parte, previo análisis inicial, se estimará la amplitud de la empresa y se tendrá la aprobación de quienes encargan el proyecto. 2. Elaboración Teniendo idea de los requerimientos diremos, a modo de ejemplo: Que se desarrollará una aplicación que permitirá a los alumnos aprender y ejercitar los contenidos del curso de Química General, haciendo énfasis en los fenómenos y procesos, apoyados en simulaciones y módulos de ejercitación, sobre todo en áreas de fuerte abstracción, cual es el caso de la química nuclear. A este efecto, desde el punto de vista de los desarrolladores de software, conviene escudriñar las mejores soluciones al requerimiento y responder: Qué tipo de software educativo se desarrollará? Cómo se construirá? Qué tecnología es necesaria? Tendrá que estimarse los riesgos del proyecto, vale decir, tomar en cuenta los factores que pueden detenerlo o echarlo por tierra. Estos riesgos pueden clasificarse en cuatro categorías: a) Riesgos de requerimientos Aquí deberá enfrentarse los requerimientos del sistema. Hay la posibilidad de desarrollar un sistema que no haga lo que se quiere del él. Por ello, es necesario enfatizar el análisis de los requerimientos y sus prioridades relativas. b) Riesgos tecnológicos Es decir, qué limitaciones e inconvenientes tecnológicos hay que enfrentar. Conviene atender a las siguientes cuestiones a manera de ejemplo: Si se va a usar tecnología de objetos. Tiene el equipo de desarrollo experiencia suficiente en el diseño orientado a objetos?. Segun el medio donde se desplegará la aplicación, suponiendo que se trate de una aplicación educativa de aula virtual a difundirse vía internet y habiendo decidido utilizar Java y HTML. Puede habilitarse las herramientas necesarias para que el alumno las utilice sin inconvenientes a través de un explorador conectado a una base de datos?
c) Riesgos de habilidades Pueden conseguirse los asesores e ingenieros de software que se necesita? La dificultad de aglutinar al personal con el perfil y la experiencia requerida puede hacer que el proyecto concebido de una determinada forma simplemente se desestime. d) Riesgos políticos Exiten entes de decisión que pueden detener o influir negativamente en el avance del proyecto? Es algo que habrá de manejarse con sutileza y el marketing de los beneficios del proyecto. Como resultado de la elaboración tendremos la Base Arquitectónica para el sistema, la cual está compuesta por: La lista de Casos de Uso, que da cuenta de los requerimientos de los usuarios, en este caso, de quienes encargan el software educativo. El Modelo de Dominio, que menciona lo que se ha entendido sobre el problema a abordar. La Plataforma Tecnológica, que describe las partes clave de la tecnología de implementación y la manera cómo se acoplan. Esta arquitectura es el cimiento del desarrollo y funciona como anteproyecto de las etapas posteriores La elaboración se termina cuando los desarroladores tienen idea de lo que tardará la implementación de cada caso de uso con una margen mínimo de error en la cronología del trabajo y sean identificados además, todos los riesgos significativos y se tenga claro cómo abordarlos. Como se desprende de lo anterior, los casos de uso son la base de la planificación del proyecto. 3. Construcción Es la parte donde se elabora el sistema en base a una serie de iteraciones, donde cada iteración es un pequeño proyecto. Se hace el análisis, diseño, codificación, pruebas e integración de los casos de uso asignados a cada iteración. Esta termina con una demostración al usuario y haciendo pruebas del sistema con el fin de confirmar que se han construido correctamente los casos de uso. El propósito de este proceso es reducir el riesgo. Los riesgos surgen con frecuencia debido a que las cuestiones difíciles se posponen para el final del proyecto. Las iteraciones dentro de la construcción son tanto incrementales como iterativas. Asi tenemos que: Funcionalmente las iteraciones son incrementales. Dado que cada iteración se construye sobre los casos de uso atendidos y desarrollados en las iteraciones anteriores. Son iterativas en término del código de base. Cada iteración implica la reescritura de algún código ya existente con el fin de hacerlo más flexible. La reestructuración de factores es una técnica muy útil para la iteración del código. Así se reducen las molestias del rediseño generadas por las adiciones al programa que pueden hacer las estructuras mas complejas de lo que deberían.
Cuando se reestructuran los factores, no se cambia la funcionalidad del programa, únicamente se cambia la estructura interna para simplificar su lectura y modificación. 4. Transición De lo que se trata en el desarrollo iterativo es de hacer todo el proceso de desarrollo consistentemente, de tal modo que el equipo de desarrollo se acostumbre a entregar código terminado. A esta altura debe pensarse en la optimización que permita mejorar el desempeño del sistema aún a costa de su claridad y capacidad de ampliación. Durante la transición no se hacen desarrollos para añadir funciones nuevas, de hecho si hay desarrollo para depuración. Un ejemplo de la transición es el tiempo entre la liberación de programa en prueba y la liberación definitiva del producto. Importancia del estudio de los casos de uso Tanto en el desarrollo orientado a objetos como en el tradicional, las personas recurrían a ciertas estrategias a fin de ayudarse a comprender los requerimientos. Estas estrategias se trabajaban de manera informal y en contados casos se documentaban debidamente. Ivar Jacobson es ampliamete conocido por haber cambiado esta situación con su método Objectory y sus publicaciones al respecto. Jacobson evidenció el caso de uso al punto de convertirlo en un elemento primario de la planificación y el desarrollo de proyectos. Ahora bien, qué es un caso de uso? Un caso de uso es en esencia, una interacción típica entre un usuario y un sistema de cómputo. Por ejemplo, un caso de uso típico en un programa educativo sería "elige en qué tópico de la sesión deseas ser evaluado", o "imprime la gráfica". De aquí se desprenden algunas propiedades de los casos de uso, tales como: Que el caso de uso capta alguna función visible para el usuario Que el caso de uso puede ser pequeño o grande y Que el caso de uso logra un objetivo discreto para el usuario. En su forma más simple, el caso de uso se obtiene hablando con los usuarios habituales y analizando con ellos las distintas cosas que deseen hacer con el sistema. Para abordar cada caso concreto se debe darle un nombre, y describirlo brevemente. Durante la elaboración esto es todo lo que se necesita para empezar. Objetivos del usuario e interacciones con el sistema En la identificación de casos de uso existe diferencia entre los objetivos del usuario y sus interacciones con el sistema. A manera de ejemplo podemos mencionar las docenas de opciones "nunca invocadas" por los usuarios al utilizar exploradores de páginas web. Estos casos de uso reflejan las cosas que puede hacer el usuario con el sistema en vez de apoyar lo que realmente quiere y necesita.
En el desarrollo de software educativo convendría centrarse primero en los objetivos del usuario y preocuparnos después de encontrar casos de uso que lo cumplan. A este paso, hacia el final del período de elaboración se espera tener un conjunto de casos de uso de interacción con el sistema por cada objetivo del usuario. Diagramas de casos de uso Jacobson (1994), además de introducir los casos de uso como elementos primarios del desarrollo del software, también diseñó un diagrama para la representación gráfica de los casos de uso. Este diagrama es parte del UML. Elementos de los casos de uso Actores, en nuestro caso, los actores podrían ser los alumnos o los profesores o ambos en tanto interactúen con el sistema Cuando se identifican los actores conviene enfatizar los papeles que asumen, no en las personas ni en los títulos de sus puestos. Los actores llevan a cabo casos de uso. De hecho un mismo actor puede realizar muchos casos de uso y a la inversa, un caso de uso puede ser atendido por varios actores. Los actores pueden ser seres humanos o sistemas externos que necesiten datos del sistema actual. Usos y extensiones (uses, extends), son tipos de vínculos que representan las relaciones entre los casos de uso. Al efecto de utilizarlos debidamente conviene tener en cuenta lo siguiente: Que debe utilizarse extends cuando se describa una variación de conducta normal, o lo que llamaríamos, un flujo alternativo. Habrá que emplear uses para repetir cuando se trate de uno o varios casos de uso y se quiera evitar repeticiones. En UML se dice que un caso de uso puede tener muchas realizaciones. Otras Herramientas de la Notación Se tienen los diagramas de clase, que describen los tipos de objetos que hay en el sistema y las diversas clases de relaciones estáticas que existen entre ellos. Los diagramas de interacción, que describen la manera en que interactúan grupos de objetos para lograr cierto comportamiento, los diagramas de paquetes que muestran los paquetes de clases y las dependencias entre ellos, los diagramas de estados, que describen el comportamiento del sistema, los diagramas de actividades, útiles en conexión con el flujo de trabajo y para la descripción del comportamiento que tiene gran cantidad de proceso paralelo y los diagramas de emplazamiento, que muestran las relaciones físicas entre los componentes de software y hardware en el sistema entregado. Discusión Final De la revisión de las fuentes y la experimentación podemos concluir que el desarrollo de software educativo tiene en el Lenguaje Unificado de Modelado una herramienta fundamental de la que rescatamos principalmente su gran capacidad de vincular a los usuarios y desarrolladores en torno a lo que se espera de una determinada aplicación que se encarga y lo que los entendidos en sistemas computacionales deberán tomar en cuenta a través de los casos de uso para proponer alternativas a los requerimientos de sistemas con propósito educativo. La notación gráfica del UML posibilita dicha comunicación y su aprendizaje por parte de los integrantes del
equipo multidisciplinario de desarrollo ajenos al area computacional toma poco tiempo. Si cuando menos se logra involucrar a los expertos en el dominio y a los profesores de carrera en la identificación de casos de uso para desarrollar una aplicación educativa se habrá logrado un avance significativo en el mejor desarrollo de software para la educación. Bibliografía Booch G., Object-Oriented Analysis and Design with Applications, Segunda Edicion, Addison Wesley, 1994. Fowler M. & Scott K., UML Gota a Gota, México, Pearson (Addisson Wesley Longman), 1999. James M. & James O., Métodos Orientados a Objetos: Conceptos Fundamentales, México, Prentice- Hall Hispanoamericana,1997. Manganelli R. & Klein M., Cómo Hacer Reingeniería, Colombia, Editorial Norma S.A., 1995 Meyer B., Construcción de Software Orientado a Objetos, Segunda Edición, Madrid, Prentice Hall, 1999. Staugaard A., Técnicas Estructuradas y Orientadas a Objetos : Una Introducción Usando C++, Segunda Edición, México, Prentice-Hall Hispanoamericana, 1998 Recursos de software utilizados en la experimentación Suite de Rational Rose Release 98i Oracle Designer Release 8