3.3. Por que ArgoUML es Diferente

En la introducción, listamos las cuatro aspectos clave que hacen a ArgoUML diferente: i) hace uso de ideas de psicologia cognitiva, ii) está basado en estandares abiertos; iii) es 100% Java puro; y iv) es un proyecto de codigo abierto.

3.3.1. Psicología Cognitiva

3.3.1.1. Teoría

ArgoUML está particularmente inspirado en tres teorias dentro de la psicología cognitiva: i) reflexión-en-acción, ii) diseño oportunista iii) y comprensión y resolución de problemas.

  • Reflexión-en-Acción

    Esta teoría observa que los diseñadores de sistemas complejos no conciven un diseño totalmete formado. En su lugar, deben construir un diseño parcial, evaluarlo, reflexionar en el, y revisarlo, hasta que estén listos para extenderlo mas allá.

    Como los desrrolladores trabajan directamete sobre el diseño, sus modelos mentales de la situación del problema mejoran, por lo tanto mejoran sus diseños.

  • Diseño Oportunista

    Una teoría dentro de la psicología cognitiva sugiere que aunque los diseñadores planean y describen su trabajo de una forma jerarquica ordenada, en realidad, escogen tareas sucesivas basados en el criterio de costo cognitivo.

    Explicado simplemente, los diseñadores no sigue incluso sus propios planes en orden, si no que escogen pasos que son mentalmente menos caros entre las alternativas.

  • Comprensión y Resolución de Problemas

    Una teoría de visualización de diseño dentro de la psicología cognitiva. La teoría expone que los diseñadores deben cubrir un hueco entre su modelo mental del problema o situación y el modelo formal de una solución o sistema.

    Esta teoría sugiere que los programadores de beneficiaran de:

    1. Representaciones multiples como descomposición sintactica del programa, transiciones de estado, flujo de control, y flujo de datos. Estos permiten al programador identificar mejor elementos y relaciones en el problema y solución y por lo tanto mas facilmente crear un mapeo entre sus modelos de situación y modelos del funcionamiento del sistema.

    2. Aspectos familiares de un modelo de situación, que mejoran las abilidades de los diseñadores para formular soluciones.

3.3.1.2. Aplicación Practica en ArgoUML

ArgoUML implementa estas teorías usando un numero de tecnicas.

  1. El diseño de un interfaz de usuario que permite al usuario ver el diseño desde un numero de perspectivas diferentes, y permite al usuario alcanzar objetivos a traves de un numero de rutas alternativas.

  2. El uso de procesos ejecutandose en paralelo con la herramienta de diseño, evaluando el diseño actual contra modelos de como un diseño de la “mejor practica” puede funcionar. Estos procesos son conocidos como criticos de diseño.

  3. El uso de listas de tareas pendientes (to-do lists) para comunicar sugerencias desde los criticos de diseño al usuario, ademas de permitir al usuario registrar areas para acciones futuras.

  4. El uso de listas de validación, para guiar al usuario a traves de un proceso complejo.

3.3.2. Estandares Abiertos

UML es en si mismo un estandar abierto. ArgoUML sobre todo ha intentado usar estandares abiertos para todas sus interfaces.

La ventaja clave de la adherencia a los estandares abiertos es que ello permite un facil inter-funcionamiento entre aplicaciones, y la abilidad de moverse de una aplicación a otra como sea necesario.

3.3.2.1. XML Metadata Interchange (XMI)

XML Metadata Interchange (XMI) es el estandar para guardar los meta-datos que confeccionan un modelo UML particular. En principio esto te permitirá tomar el modelo que has creado en ArgoUML y importarlo dentro de otra herramienta.

Esto claramente tiene ventajas in permitir al UML alcanzar su meta de ser un estandar para la comunicación entre diseñadores.

La realidad no es tan buena. Anteriormente a UML 2.0 el archivo XMI no incluye información sobre la representación grafica de los modelos, así que el diseño del diagrama está perdido. ArgoUML rodea este problema guardando la información grafica separada del modelo (mira Sección 3.4.3.1, “ Cargando y Guardando).

3.3.2.2. Formatos Graficos - EPS, GIF, PGML, PNG, PS, SVG

  • Encapsulated PostScript (EPS) es un archivo PostScript que satisface restricciones adicionales. Estas restricciones estan previstas para hacer mas facil para el software incrustar un archivo EPS dentro de otro documento PostScript.

  • Graphics Interchange Format (GIF) es un formato cubierto por patente, aunque las patentes se agotaran en Agosto del 2006.

  • Precision Graphics Markup Language (PGML) es un lenguaje basado en XML para representar graficos vectoriales. Fué un borrador de la W3C, pero no fué adoptado como recomendación. PGML y VML, otro lenguaje basado en XML para graficos vectoriales, fueron luego fusionados y mejorados para crear juntos el formato SVG.

  • Portable Network Graphics (PNG) es un estandar de ISO/IEC (15948:2004) y es tambien una recomendación de la W3C. PNG es un formato de imagen de mapa de bits que emplea compresión de baja perdida. PNG fué creado para mejorar y sustituir el formato GIF con un formato de archivos de imagen que no requiriera de una licencia de patense para ser usado. PNG es oficialmente pronunciado "ping" pero a menudo es simplemente deletreado — probablemente para evitar confusión con la utilidad de red ping. PNG está soportado por la librería de referencia libpng, una librería independiente de la plataforma que contiene funciones C para el manejo de imagenes PNG.

  • PostScript (PS) es un lenguaje de descripción de pagina y lenguaje de programación usado primeramente en la areas de publicación asistida por ordenador y electronica.

  • Scalable Vector Graphics (SVG) es un lenguaje de marcado XML para describir graficos vectoriales bidimensionales, estaticos y animados, y de forma declarativa o mediante scrip. Es un estandar abierto creado por el World Wide Web Consortium. El uso de SVG en la web esta en sus primeros pasos. Hay un gran problema en la inercia debida al largo tiempo de uso de formatos basados en mapas de bits y otros formatos como Macromedia Flash or Java applets, pero ademas el soporte por navegadores web es todavía desigual, con soporte nativo en Opera y Firefox, pero Safari y Internet Explorer necesitan un plugin. Mira PGML mas arriba.

3.3.2.3. Object Constraint Language (OCL)

Object Constraint Language (OCL) es un lenguaje declarativo para describir reglas que se aplican a modelos UML. Fué desarrollado en IBM y ahora es parte del estandar UML. Inicialmente OCL fué solo una especificación formal de una extensión de lenguaje para UML. OCL puede ahora ser usado con cualquier metamodelo compatible con Meta-Object Facility (MOF), incluyendo UML. El Object Constraint Language es un lenguaje de texto preciso que proporciona limitación y expresiones de acceso a objeto en cualquier modelo MOF o metamodelo que de otra forma no puede ser expresado por notación diagramatical.

3.3.3. 100% Java Puro

Java fué concevido como un lenguaje interpretado. No tenía un compilador para producir codigo para cuaquier maquina particular. Compila codigo para su propio sistema, la Maquina Virtual Java (Java Virtual Machine; JVM).

Escribir un interprete para una JVM es mucho mas facil que escribir un compilador, y estas maquinas virtuales están ahora incorporadas dentro de casi todo Navegador Web. Como resultado, la mayoria de las maquinas pueden ejecutar Java, sin trabajo adicional.

(En caso de que te preguntes porque todos los lenguajes no son como este, es por que los lenguajes interpretados tienden a ser mas lentos que los compilados. Sin embargo, con el alto rendimiento de los modernos PCs, la ganancia en portabilidad merece la pena para muchas aplicaciones. Mas aún, las modernas caches multinivel pueden suponer que los lenguajes interpretados, que producen un codigo mas denso, pueden realmente no ser tan lentas de todas formas.)

Mediante la elección de escribir ArgoUML en Java puro, se hace inmediatamete disponible para el mayor numero de usuarios con la minima cantidad de esfuerzo.

3.3.4. Codigo Abierto

ArgoUML es un proyecto de código abierto. Esto significa que cualquiera puede tener una copia gratis del código fuente, cambiarlo, usarlo para nuevos propositos y cosas así. La única (gran) obligación es que tú pases tu código de la misma forma a otros. La naturaleza precisa de que puedes hacer y que no puede varia de un proyecto a otro, pero el principio es el mismo.

La ventaja es que un proyecto pequeño como ArgoUML subitamente se abre a una gran cantidad de ayuda adicional de aquellos que pueden indagar en sus ideas sobre como el programa puede ser mejorado. En cualquier momento pueden ser 10, 15, 20 o mas personas haciendo contribuciones significantes a ArgoUML. Hacer esto comercialmente costaría mas de 1 millon de $ al año.

No es solo un espiritu de puro altruismo. Contribuir en un camino para aprender “con las manos en la masa” sobre software puntero. Es una forma de adquirir visibilidad (mas de 100,000 personas han descargado ArgoUML hasta la primavera de 2001). Esto es una gran cantidad de buena esperiencia en suma ¡y muchos empleadores potenciales están viendote!

Y es genial para el ego!

El Código Abierto no excluye ganar dinero. Gentleware www.gentleware.com vende una versión comercial de ArgoUML, Poseidon. Su propuesta de valor no es un trozo de códogo privativo. Es el refinamiento comercial y el soporte para librarse de riesgos usando ArgoUML en un desarrollo commercial, permitiendo a los clientes tomar ventaja de la tecnología puntera de ArgoUML.