Seleccionando una herramienta
de modelaje UML
|
Al evaluar una herramienta de modelaje UML pueden utilizarse los siguientes criterios. En el mercado hay varios productos que responden a los mismos. Dado que usted quiere el mejor, tome su tiempo al evaluar los productos que prueba teniendo en cuenta los criterios enumerados en esta lista. Si tiene un criterio que valora en particular y no se encuentra en esta lista, por favor háganoslo saber.
Para un proyecto grande, es necesario un repertorio que permita a los conceptores compartir los diseños de los componentes. Dos o más conceptores pueden compartir los componentes de un modelo o incluso pueden colaborar en el desarrollo de un solo componente si se define el "ownership" y la autorizacion para compartir a un nivel apropiado. Generalmente se construye un repertorio sobre una base de datos que proporciona las funciones para compartir informacion y para el control concurrente. Al proporcionar protección de acceso y de acceso sólo para lectura, el repertorio le permite a un conceptor poseer el modelo y a la misma vez deja a otros leerlo, permitiendo asi la incorporacion de componentes en sus propios diseños. Importante: La herramienta debe permitirle capturar sólo los componentes que desea de otro modelo, sin tener que importar la totalidad del mismo. Otra forma interesante de construir el repertorio es construyendolo sobre el propio código fuente de un proyecto, utilizando un sistema de control de código fuente para proporcionar el control concurrente. El beneficio de este metodo es un mayor grado de sincronización entre el código y el modelo. Otro beneficio es la eliminación de una segunda fuente de datos. No olvide que si utiliza una base de datos para un repertorio es necesario salvaguardar estos datos almacenados separadamente y realizar una sincronización trilateral entre el modelo, el repertorio y el código fuente en lugar de tan sólo una sincronización bilateral entre el código y el modelo. Con las herramientas de modelaje que apoyan un repertorio, los cambios efectuados a cualquier componente seran propagados automáticamente a cualquier diseño que importe el componente.
La capacidad de realizar la ingeniería avanzada e invertida al código fuente (Java, C++, CORBA IDL), es requerimiento complejo que los vendedores proporcionan con varios grados de éxito. La exitosa combinación de ambas funciones, la ingeniería avanzada e invertida, se define como round-trip engineering. La ingeniería avanzada es muy útil la primera vez que se genera el código de un modelo. Esto le evitará en gran parte el tener que teclear clases, atributos y métodos. La ingeniería invertida es muy útil tanto en la transformación del código en un modelo cuando no existía ningún modelo previo, como en la resincronización de un modelo con el código al final de una iteración. Durante un ciclo de desarrollo iterativo, una vez que un modelo ha sido actualizado como parte de la iteración, otra iteracion de ingeniería avanzada debe permitir que el código se actualize con todas las nuevas clases, métodos o atributos añadidos al modelo. Este paso es adoptado con menor frecuencia por los conceptores debido a que muchas herramientas pueden estropear totalmente el código fuente en el proceso. El problema reside en que el código fuente contiene mucho más que el modelo; las herramientas deberan ser muy capaces de reconstruir el código fuente que existía antes de la nueva iteracion de ingeniería avanzada. Como mínimo, la herramienta de modelaje debera apoyar con éxito la ingeniería avanzada en primera instancia y la ingeniería invertida a lo largo del proceso. Asimismo, la herramienta no debera tener ningún problema al aplicar la ingeniería invertida al lenguaje Java. Asegúrese de verificar esta función en su propio código fuente puesto que hemos visto fallar reputadas herramientas en las aplicaciones de ingeniería invertida al lenguaje Java tales como las clases internas. Cada vez que aplique la ingeniería invertida se verá obligado a crear un comentario que desactive el código ofensivo, algo realmente desagradable.
La herramienta de modelaje de objetos debera proporcionar la generación continua de documentación HTML para un modelo de objetos y sus componentes. La documentación HTML proporciona una visualización estática del modelo de objetos a traves de un navegador por cualquier conceptor que utilice el modelo de objetos para uso de referencia rapida sin tener que lanzar la herramienta de modelaje. Asimismo, al producir HTML como documentación, el número de licencias requeridas para la herramienta de modelaje pueden verse reducidas por número de personas que necesiten acceso sólo para lectura a la información del modelo. La documentación HTML debera incluir una imagen (bitmap) de cada uno de los diagramas del modelo y debera proporcionar navegación a través del modelo mediante el uso de enlaces hipertexto. El tiempo requerido para generar la documentación HTML debería ser razonable. Un número de productos actualmente disponibles apoyan estas funciones con diversos grados de éxito. Asegúrese una vez más de probar esta función por si mismo. Una casilla marcada en una tabla de funciones no es garantía de éxito.
Aunque muchas herramientas afirman prestar apoyo completo para UML 1.3, en realidad esta es requerimiento complejo y algunas herramientas pueden no corresponder a las pretensiones anunciadas de pleno apoyo. Como mínimo, los diagramas que deberan ser apoyados son los de Casos de uso (Use Case), Clase (Class), Colaboración (Collaboration), Secuencia (Sequence), Paquete (Package), y Estado (State).
La herramienta de modelización debería proporcionar listas de selección en varias interfaces clave: Diagramas de Colaboración y Secuencia - La herramienta debera permitir la asignación de un objeto a una clase proveniente de una lista conteniendo todas las clases del modelo. Debera permitir la selección de los mensajes enviados entre objetos a traves de una lista válida de métodos para el objeto/clase que ha de recibir el mensaje. Diagrama de Clase - La herramienta debera permitir la importacion de clases provenientes de otros paquetes o modelos a traves de la selección de una clase perteneciente a una lista de clases del paquete. La función "listas de selección" contribuye en gran manera a el facil uso de la herramienta de modelaje y puede considerarse como una función esencial. El desarrollo de diagramas de secuencia (sequence diagrams) y de diagramas de colaboración (collaboration diagrams) se facilita en gran medida al ser posible el seleccionar rápidamente el mensaje que usted desea enviar de un objeto a otro.
La herramienta de modelaje de objetos debera permitir la integración con funciones de modelaje de datos. Existen muchas formas de proporcionar esta funcionalidad. Una de ellas consiste en que la herramienta del objeto proporcione una función que permita la transformación de un modelo del objeto a DDL, que es en si las intrucciones de SQL requeridas para crear tablas para clases. Otra forma es que la herramienta de objetos exporte metadatos a una herramienta de modelaje de datos y esta ultima importar los metadatos y utilizarlos como base para un modelo de datos. Un conjunto de herramientas integrado y avanzado debera permitir que los modelos de datos y de objetos se sincronicen tras cada iteración del diseño.
La herramienta de modelaje debera permitir salvaguardar las versiones de modo que cuando comiencen las demas iteraciones, la versión previa se encuentre disponible para su restauración o para la conservación del código existente que depende de esa versión.
La herramienta de modelaje debera proporcionar un fuerte apoyo de navegacion para que el conceptor pueda navegar a través de todos los diagramas y clases del modelo. Un directorio o lista de selección de clases, ordenadas por nombre, es una forma de permitir que el diseñador vaya a la clase deseada dentro de un diagrama. Para diagramas grandes, la herramienta debera facilitar la navegación cuando se efectúe una visualización con zoom y panorámica. Asimismo, la herramienta debera facilitar la navegación al código fuente de una clase cuando se utilice ingeniería avanzada e invertida.
La herramienta de modelaje debera proporcionar imagenes adecuadas de diagramas grandes para ser reproducidos mediante la impresión en páginas múltiples. Deberan apoyarse las funciones de visualización previa a la impresión y de escala para asi facilitar el ajuste del diagrama al deseado número de páginas. La capacidad de ajuste de un diagrama en una sola página es muy importante. Desafortunadamente, hemos constatado que muchas herramientas presentan dificultades en la ejecución de esta importante tarea.
La herramienta de modelaje debera proporcionar la facilidad de para personalizar la visualización de una clase y sus detalles. Por ejemplo, debera ser posible excluir todos los métodos get/set del diagrama, puesto que tienden a aglomerarlo en lugar de aclararlo. Debera permitirse de un modo facil mostrar u ocultar la firma completa de los métodos, dependiendo del nivel de detalle deseado. La visibilidad de atributos y métodos (privado, protegido, público) debera ser otra dimensión con la cual seleccionar lo que se debe mostrar u ocultar en el diagrama.
Una característica clave que a menudo se pasa por alto es la capacidad de exportar diagramas en un formato que pueda ser importado ya sea a un documento Word, o a una página web (web page). Los formatos gráficos más populares utilizados para la exportación son el GIF y el JPEG. En la exportación, la herramienta debera permitirle definir la resolución y el tamaño preferidos para la gráfica que ha de producirse Esta funcionalidad se origina por el requerimiento de algunos autores ambiciosos que quieren escribir un libro de UML que incluya diagramas, o que desean mostrar su trabajo en una página web. <guiño>
El scripting es otra poderosa función que debera proporcionar una herramienta de modelaje. Con el scripting, el usuario experto (power user) puede crear scripts que accesen directamente el modelo deobjetos que radica dentro de la herramienta de modelaje con el fin de crear otros artefactos. Ejemplos de estos artefactos son las hojas de cálculo para manejo de de proyectos, documentación personalizada, código personalizado, reportes y metrica. Un ejemplo de código personalizado son las firmas para las clases de colección y los métodos get/set utilizados para accesar estas clases. Para facilitar el scripting, la herramienta de modelaje debera exponer interfaces al modelo de objetos, internas a este mismo, que proporcionen acceso a los componentes del modelo de objetos en elaboración. (Si ésto suena un tanto circular, léalo de nuevo). Por ejemplo, el editor de script debera ser capaz de accesar la colección de clases en un diagrama de clases a través de una iteración, y entonces debera poder accesar las propiedades de las clases a través de métodos de acceso sobre el objeto de la clase. Naturalmente, el propio lenguage de scripting debera estar basado en objectos; una elección obvia es el mismo lenguaje Java y otro es el lenguaje de scripting Python.
Usted desea una herramienta UML de sólida confiabilidad para prevenir que los usuarios pierdan horas potenciales de productividad cuando la herramienta deje de funcionar en medio de una sesión de diseño o que corrompa un modelo que no ha sido salvaguardado. Personalmente hemos constatado que un número de destacadas herramientas provocan la pérdida de horas de trabajo debido a una avería o a la corrupción de un archivo. Si usted es conceptor, conoce el sentimiento de desden hacia las "aplicaciones de productividad" que son menos productivas que las herramientas de codificación en bruto. Si usted es director, seguramente reconoce el resentimiento que los conceptores muestran cuando se les obliga a utilizar una herramienta poco fiable. Actualmente la robustez puede encontrarse a menudo en aplicaciones implementadas en Java (proteccion JVM para lafase de ejecución) o como proyectos "open-source"(internet, depuración paralela). La forma más rápida de descubrir si una herramienta UML en particular es fiable o no, es consultando a un newsgroup tal como comp.object. ¡Así estará seguro de que le soltarán un buen rollo! Otra estrategia que puede aplicar aquí, y la cual recomendamos que adopten los vendedores de herramientas, ha sido tomada de aplicaciones de productividad de oficina. La estrategia es que la herramienta UML salvaguarde automática y periódicamente un modelo.
Para aprovechar al máximo su inversión en una herramienta de modelaje, considere cuidadosamente los systemas de cómputo en los cuales la herramienta ejecutará. ¿Desarrollará usted software para Windows, para Unix ó para los dos sistemas? ¿En que sistema hará usted su desarrollo? Recientes acontecimientos han propagado el mito de que interfaces para usuarios de primera clase y aptos para sistemas múltiples no funcionan ó solo ofrecen como mínimo una presentación común entre los sistemas. Por un largo tiempo esto venía siendo cierto (con la excepción de aplicaciones basadas en HTML) hasta la recién llegada de la interface Java llamada Swing. Sin embargo, herramientas aptas para sistemas múltiples necesitan ser apoyadas en sistemas comunes y accesibles, tales como Linux, para lograr ser adoptadas por programadores. Sun originalmente había hecho poco para promover Java en Linux. Pero recientes iniciativas en la industria, principalment de IBM que ha prometido amplio soporte a Linux en todos sus sistemas de hardware y esta apoyando el proyecto Apache/Jakarta, están ahora empujando rapidamente a Java hacia Linux. Posiblemente por IBM haber decidido distribuir su version de JDK 1.1.8 a los principales vendedores, Sun a sido forzado a apoyar la distribución de un JDK 1.2 (Java 2, con Swing) de funcinalidad completa para Linux. Este desarrollo de Java para Linux se ha llevado a cabo en gran parte bajo los auspicios del Blackdown Group. Hasta ahora hemos probado una destacada herramienta UML para Linux y basada en Swing con excelentes resultados con tan solo una advertencia: el tener 128MB the memoria es imperativo.
Deberá seleccionar una herramienta de modelaje que continue siendo mejorada activamente a través de la corrección de errores, mejoras en su rendimiento, y la inclusión de nuevas funciones. Después de todo, usted está invirtiendo mucho tiempo y dinero no siendo fácil cambiar a otra herramienta de modelaje. Cuidado con productos que hayan sido adquiridos por compañías grandes. Muchas veces los desarrolladores originales han renunciado de la compañía (despues de canjear sus acciones) para continuar con nuevas oportunidades. Es muy difícil encontrar programadores talentosos que puedan aprender un pedazo de software complicado y que además quieran mantenerlo aún sin haber ellos desarrollado el código original. Esto puede ocurrir aún en proyectos de código abierto… ¿Como puede usted determinar si un producto está evolucionando? Pida al representate de ventas un programa detallado de las versiones mas recientes y un plan para versiones futuras. Observe detalladamente que tan rápido nuevas funciones y mejoras se han llevado a cabo. ¿Cuando se planea el soporte de UML 1.3 para el producto? ¿Apoya la interface gráfica los mas recientes estilos convencionales? Podrá usted también mirar en el sitio Web de la compañía: si los anuncios y crítica del producto son viejos, entre en sospecha.
Ahora entremos en lo que respecta a nuestra lista de deseos para el futuro. La presente madurez en las herramientas de modelaje, nos indica que los vendedores de herramientas están prestos a llevarlas a el próximo nivel de sofisticación. Esperamos ver aparecer algunas de las siguientes funciones en la proxima generacion de productos.
Durante el desarrollo iterativo de un modelo, es muy productivo mirar en ventanas adyacentes el diagrama UML y el código fuente concordante. Los productos que apoyen esta coordinación de perspectivas podrían añadir una dimensión adicional muy poderosa a la caja de herramientas del diseñador al añadir directamente a la herramienta de modelaje potentes funciones de edición de código fuente. Aunque la herramienta de modelaje no necesita ser el editor primario del diseñador, es bastante útil poder cambiar el nombre o firma de un método directamente en el código y dejar que el cambio se refleje inmediatamente en el modelo. A la cabeza de la lista de funciones deseables se encuentra la emulación de teclado para editores populares tales como emacs. Otra importante función es la de el uso de colores para subrayar en el código palabras clave, comentarios, etc. Esta función facilita la legibilidad del código. Una función esencial es la capacidad de saltar a la línea concordante del código cuando se seleccione una clase, atributo o método en un diagrama de clase. Por encima de todo, el editor debería ser rápido y fácil de utilizar. Como variación de este tema, otra solución es permitir que la herramienta de modelaje se comunique con el editor preferido del conceptor. Un ejemplo sería: una tecla personalizada podría permitir que la herramienta de modelaje cambie la ventana activa al editor externo con el cursor posicionado en la línea concordante del código.
Una función que nos encantaría ver en un futuro próximo es la capacidad de las herramientas de modelaje para asistir en la generación de diagramas de estado e interacción. Así es como debería funcionar: la herramienta de trabajo debería facilitar la creación de un archivo de rastreo durante la ejecución de un programa existente. El proposito de este archivo seria el de capturar la interaccion entre objectos al pasarse mensajes entre uno y otro. Después de la creacion del archivo de rastreo, la herramienta de modelaje sería utilizada para analizar el rastreo con el fin de hallar patrones de interacción entre los objetos. La herramienta de modelaje permitiria al usuario efectuar la selección para analisis entre un grupo de clases. La herramienta podría entonces presentar cada conjunto único de interacciones que hayan sido registradas a traves del archivo de rastreo para estas clases y podría permitir que el usuario seleccione las interacciones que desee modelar. Finalmente, la herramienta permitiria la generacion de un diagrama de sequencia o un diagrama de colaboración basados en interacciones del objeto reales y registradas. ??? Suena bien? Si parece demasiado futurista, en realidad no debeiera, porque la técnica de rastreo ya ha sido implementada con bastante éxito en herramientas que ayudan a los conceptores a localizar fallas de rendimiento en sus programas. Un buen ejemplo de productos en esta categoría es JProbe del Grupo KL, que usado para analizar el rendimiento de los programas Java. Asimismo debería ser posible autogenerar diagramas de estado utilizando la misma técnica: una modificación de la secuencia descrita previamente sería permitir al usuario especificar el nombre de una clase base para los estados en la máquina de estado (state machine). La herramienta de modelaje rastrearia las interacciones entre clases derivadas de la clase base. A partir de dicho rastreo, la herramienta de modelaje podría crear un diagrama de estado mediante la elaboración de un diagrama de cada una de las transiciones de estado registradas.
Si usted corresponde al tipo "director de proyecto", entonces lo más probable es que desee poder medir en qué medida progresa su proyecto O-O. Una util función que debería ser integrada en las herramientas de modelaje es la capacidad de exportar la información del modelo a una herramienta que le permita verificar el progreso tanto del diseño como el de la ejecución de su proyecto. La hoja de cálculo es una herramienta ideal para aplicar a esta solución debido a su familiaridad y flexibilidad. De igual modo, las herramientas de administracion de proyecto son candidatas ideales. ¿Cómo trabajaria esta función? En el nivel más elevado, normalmente lo que usted desea localizar son las clases en el modelo y las personas asignadas para trabajar en ellas. Usted desea saber cuándo alguien comenzó a trabajar en una clase y qué tan cerca de completar el trabajo esta. En el siguiente nivel de detalle, usted desea tener conocimiento acerca de los métodos para cada clase. En este nivel quizá le gustaría saber qué métodos han sido incluidos en los diagramas de interacción o, durante la fase de ejecución, la cantidad de código terminado para cada método. Para que esta función sea eficaz, necesitará una actualización de tipo avanzado para la información utilizada en la administracion del proyecto. A diferencia de las herramientas para preparación de informes, que siempre generan un nuevo informe desde el inicio, usted sólo desea exportar todo la primera vez. Tras la exportación inicial, su herramienta de modelaje sólo tendra que actualizar la herramienta de administracion con nueva información. Dependiendo del nivel de control deseado por el usuario, la herramienta de modelaje podría presentar al usuario una lista de actualizaciones antes de efectuar la exportación. Uno de los apreciables dividendos que resultarian al tener un enlace para la administracion de proyecto es la capacidad de elegir fechas de finalización de las fases de análisis y de diseño de un proyecto. La forma en la cual esto funcionaría seria mediante el cálculo de un índice de progreso para calcular y anticipar las fechas de finalización basándose en las tareas restantes para completar el modelo.
Cuando su proyecto comience a madurar, quizá desee tener accesso a metricas para su modelo. Estas metricas pueden proporcionar al arquitecto O-O informacion inmediata sobre la viabilidad de un modelo en particular. Algunas metricase de de particular interés incluyen: el número de super-clases en una jerarquía de clases, el número de métodos por clase, el número de atributos por clase, el número de métodos "get/set", el número de métodos anulados, las líneas de código para cada método, el porcentaje de métodos públicos, privados y protegidos, el grado de acoplamiento por clase (el número de clases diferentes que conoce esta clase), y el porcentaje de métodos comentado. La metrica podría proporcionarse a través de una interface para preparación de informes, o aún mejor, mediante un enlace a una hoja de cálculo similar al enlace para administracion del proyecto descrita anteriormente.
Para lograr ofrecer verdadera funcionalidad de importación y exportación de gráficas de vector, basada en estándares, las compañías de herramientas UML pronto tendrán una opción. La recomendación del W3C llamada SVG (Scalable Vector Graphics) es una gramática XML para gráficas estilizables que ha progresado hasta lograr una especificación madura en version 1.0 en la fase de "revision de ultima hora" (3/3/2000). Una vez que esté completamente aprovada, usted podrá buscar esta funcionalidad en la nueva generación de navegadores. ¿Por que SVG? Porque un grupo de diagramas, exportado usando el formato de gráficas de vector, puede ser enlazdo con páginas web. El lector de un documento de diseño, a traves del Web, podría utilizar técnicas de navegación gráficas tales como zoom y panorámica dentro del mismo navegador para así poder explorar un diagrama UML grande. Además, este formato mejorará radicalmente la velocidad a la cual diagramas grandes puedan ser montados a través del Web, comparado a diagrams de formato GIF. Como prueba, observe que tan rápido presentaciones de Macromedia Flash son montadas en el navegador hoy en día! Para mostrar la diferencia radical que existe entre imágenes GIF y gráficas con funciones de escala (SVG) para publicación, hemos preparado una simulación creando un archivo Adobe PDF que contiene dos instancias de un diagrama de clase, una con un diagrama GIF importado y la otra con una imagen de gráfica de vector. Puede usted bajar este documento PDF y verlo con el Adobe Acrobat. Trate de ampliar la imagen a un porcentaje alto como 800 o 1600 y compare los resultados entre la imagen GIF y el diagrama de vector. Este experimento no es poco realista: quizás usted querrá preparar un diagrama tamaño mapa a escala para poder ser leído mejor. Baje el archivo PDF de ejemplo para comparar entre GIF y graficas de vector. Para ver de preestreno el futuro de UML y SVG, también hemos preparado una demo usando SVG para visualizar un diagrama de clase en un navegador. Para ver esta demostración, primero tendrá que bajar un visualizador SVG para su navegador. Le recomendamos el excelente Adobe SVG plugin. Con él podrá usted ver la demo Graphics Model in SVG.
El estándar XMI creado por el Object Management Group -(OMG) es uno de los recientes desarrollos mas excitantes de la comunidad de conceptores de UML. XMI es un formato de intercambio con el potencial de finalmente permitir a las mejores herramientas de desarrollo compartir modelos facilmente. Por ejemplo, en lugar de escribir scripts para crear informes con una herramienta de modelaje UML, un usuario simplemente podríaexportar el modelo en desarrollo utilizando XMI e importarlo a una herramienta especializada para la creacion de informes. De hecho, este paradigma se aplicaría igualmente bien a las funciones discutidas anteriormente: rastreo de metricas O-O y la administracion de proyectos. Ademas, como XMI utiliza XML para representar la información del modelo, un grupo de soluciones basadas en XML estaran inmediatamente disponibles, tales como las hojas de estilo (stylesheets) XSL para la presentación basada en navegadores y las herramientas de interrogación (query tools) XQL para funciones de busqueda. El estándar XMI es complejo y tomará tiempo reconciliar muchas cuestiones de compatibilidad que inevitablemente se suscitarán (¿quién dijo que los estándars no están abiertos a la interpretación?) antes de que su uso pueda generalizarse. Sin embargo, dado que el XMI ha sido desarrollado por compannias destacadas en la industria, tales como IBM y Unisys entre otras, se anticipa que los productos aparecerán proximamente. Incumbe a la comunidad de usuarios exigir el soporte XMI en las herramientas UML mediante su inclusión al principio de las listas de control de funciones. Para mayor información sobre XMI, consulte la excelente página web de IBM. Si tiene alguna idea sobre nuevas funciones para herramientas de modelaje UML que no se encuentren en esta lista, le agradeceríamos nos contactase. |
|
|
Copyright © 1999-2005 Objects by Design, Inc. All rights reserved.
