Administración del Conocimiento – UML Simulation

Importacion de Maquinas de Estado en U-Fabrik

Posted in Executable UML, GUI, POO, UML, Web by smalltalkuy on agosto 17, 2013

El U-Fabrik ahora soporta la importación de Máquinas de Estado UML. Básicamente una máquina de estados consta de 3 partes que serán representadas por 3 clases diferentes dentro de U-Fabrik. Estas 3 partes son: el estado, la transición (estado inicial y estado final) y la máquina misma. En la siguiente imagen, la máquina de estado es representada por toda la imagen, los estados son: Creada, Enviada, Recibida, EnEstudio, EnProceso, Rechazada, Respondida. Las transiciones son: crear, enviarCreada, recibirEnviada, estudiarRecibida, aceptarRecibida, aceptarEstudiada, rechazarEstudiada, responderProceso, finalizarRechazada y finalizarRespondida.

Image

Cuando importamos la máquina de esatdo deberemos indicar que clase UML representa cada parte del estado. En nuestro caso como muestra la figura correspondiente son: Estado, DefinicionTransicion, y DefinicionProceso.

DefinicionProceso es una colección de DefinicionTransicion y cada DefinicionTransicion tiene un estado actual y estado siguiente.

Image

Cuando U-Fabrik importa el diagrama de estado relaciona la máquina de estados con estas clases. Y crea una instancia de DefiniciónProceso por cada diagrama en el archivo XML. Cada instancia de DefiniciónProceso a su vez tiene una colección de instancias de DefinicionTransicion que representan las transiciones. Y cada DefinicionTransicion tiene dos variables del tipo Estado (actual y siguiente). Mientras las clases UML tengan esta estructura cualquiera puede representar los elementos de la máquina de estados.

Este framework de tres clases puede ser asociado a otras clases del modelo para dar sentido a la máquina de estados como muestra la siguiente figura:

Image

Como se ve en la figura anterior las clases que representan TODAS las máquinas de estado están integradas al modelo clases. La clase Rol asociada a DefinicionTransicion indica que roles pueden accionar esa transición. La clase Transicion representa un DefinicionTransicion en el tiempo. Y la clase Proceso son todos los procesos del sistema y cada Proceso sigue una ruta determinada por DefinicionProceso. A su vez, cada Proceso esta compuesto por una colección de Transiciones. Y cada Proceso es el proceso de una Solicitud que ha ingresado al sistema.

De esta forma U-Fabrik integra los diagramas de estado UML con los diagramas de clases UML.

Proceso

Image

Transiciones del Proceso

Image

Una Transición del Proceso

Image

Anuncios

Mapeo de usuarios Web con usuarios UML

Posted in Aplicaciones, Executable UML, GUI, POO, UML, UML Ejecutable by smalltalkuy on febrero 19, 2013

Para poder mapear los usuarios del UML Almighty Web Server con los usuarios UML debemos seguir los siguientes pasos:

1. Crear los usuarios de mi aplicación UML application. Será algo como:security wokspace 01

Recordar que la clase User debe ser la Login Manager Class.

2. Ahora tenemos que mapear (o replicar) el User “John” en el UML Almighty Web Server.
2.1. Logerse con User: admin password: password.
2.2. Ir a  Security Settings
security 01

3. En los Security Settings agregar un nuevo usuario New User (John), llenar datos y presionar Save
security 02

security 03
5. Ir a los Access Rights del usuario John User
security 04
6. Ahora hay que seleccionar la aplicación UMLInstanceApp que es el Servidor Web para el UML Almighty
security 05
7. Ahora estamos en la aplicación UMLInstanceApp que maneja los permisos de John
security 06
8. El último paso es hacer Click en “Yes” para habilitar todos los permisos de John. El usuario creado en el paso step 1.
security 07

Principio de “Conexión Inmediata” en la Programación

Posted in Aplicaciones, GUI, POO by smalltalkuy on marzo 24, 2012

“Conexión Inmediata” en la Programación

http://instanceof.me/post/18455380137/inventing-on-principle-by-bret-victor

El principio de Conexion Inmediata es una redefinición de una principio que data de los ’60, el Principio Reactivo.

Principio Reactivo: Cada componente accesible al usuario debería ser capaz de presentarse de una manera entendible para ser observado y manipulado.

Esto es poder acceder al componente e interactuar con el en tiempo real, recibiendo respuestas en tiempo real.

Este principio reactivo o conexión inmediata es soportado por el Smalltalk y también por UML Almighty .

Sin una demostración cara a cara es difícil mostrar las ventajas de estos principios  principio reactivo/conexión inmediata, y casi imposible plasmar esto en un blog, pero por suerte Bret Victor ha realizado una excelente demostración de su conexión inmediata.

La charla esta en ingles (lamentablemente) y dura 55 minutos, pero todo PROGRAMADOR debe ver esta charla, es excelente !

Muestra claramente como la conexión inmediata (o principio reactivo) afecta la capacidad de CREACIÓN de un programador.

http://instanceof.me/post/18455380137/inventing-on-principle-by-bret-victor

Licencias Open Source

Posted in Executable UML, GUI, POO, Traits, UML, UML Ejecutable, Web by smalltalkuy on febrero 6, 2011

Estamos viendo que licencia Open Source es la mejor para el UML Almighty, pero la cantidad de posibilidades es bastante grande y algunas licencias son extensas y en ocasiones no muy claras. Hasta ahora la licencia más cerca de lo que queremos es The PostgreSQL Licence (TPL).

Los objetivos a buscar

* Código fuente libre (para futuras versiones o aplicaciones derivadas).

* Aplicaciones o Distribuciones Derivadas que mantengan la misma licencia.

* Que no se pueda cobrar por el software en si o por extensiones.

* Que si se puedan vender servicios (SaaS – software as a service).

Público Objetivo

* Programadores, Analistas, Ingenieros de sistemas en proyectos utilizando UML.

* Empresas que utilizan UML en sus proyectos.

* Instituciones Educativas (con orientación informática) cuyos planes de estudio incluyan UML.

* Investigadores de Máquinas Virtuales y Meta Programación, etc.

Que hace

* Genera una aplicación Web/Desktop customizable a partir de un Diagrama de Clases.

* Se puede programar comportamiento por lo que los Diagramas de Sequencia pueden ser programados y ejecutados.

* La aplicación generada es una Simulación (con prototipo customizable) y Ejecución del diseño UML.

* Asegura en un 100% que el diseño ejecuta y puede ser programado sin contratiempo para los proagramdores.

 

 

Nuevo build del UML Almighty con bugs arreglados

Posted in Aplicaciones, Executable UML, GUI, POO, UML, UML Ejecutable, Web by smalltalkuy on agosto 2, 2010

El bug Web más reclamado fue arreglado estará disponible en esta semana cuando subamos el nuevo instalador.

Descripción del bug:

Cuando se agregan objetos a una colección (derivada de una relación 1xN o NxN entre clases) si la clase se ha customizado para mostrar determinados aspectos, estos aspectos no se muestran. El UML Almighty hace caso omiso a la customización.

Solución:

No se estaba chequeando si había una customización. Ahora funciona correctamente como podemos ver en la siguiente imagen.

En este caso la clase no tiene atributos entonces se mostraba una lista vacía, y si se customizaba seguía mostrando la lista vacía.

Luego se customizo para mostrar el nombre de la clase, funciono correctamente.

UML Almighty

Simulación UML – UML Simulation

Prototipos UML – UML Prototype

UML Ejecutable – Executable UML

Simulación de un Workflow de Procesos y Documentos

Posted in Aplicaciones, Executable UML, GUI, POO, UML, UML Ejecutable, Web by smalltalkuy on julio 22, 2010

Introducción

En la siguiente simulación mostramos parte de un Workflow de Procesos y Documentos de uno de nuestros clientes.

Dado que esta será una aplicación propietaria no publicaremos la Simulación final sino una de las simulaciones intermedias.

Este sistema tiene como objetivo administrar los proceso y documentos de la empresa. Cada usuario (o Rol) puede participar en más de un proceso de la empresa, y estos procesos del usuario pueden pertenecer a diferentes proyectos.

La idea general es que cuando un Rol entre al sistema vea o tenga sus Proceso, sus Documentos (MS Office), y los eventos relacionados (con los Procesos y Documentos) en los que este Rol tiene los permisos necesarios. Por ejemplo: si se termina la edición de un documento (se paso a Revision), y el Rol tiene permiso de Aprobar –> este evento debe aparecer en la lista de eventos de este rol.

Reglas Generales

* Los administradores (o jefes de proyecto) asignan a los demás roles a los diferentes procesos.

* Los procesos tiene diferentes permisos para los roles: Entrada, Continuar, Detener, Finalizar. Dependiendo de los permisos del Rol, los comandos disponibles (botones) para este en la página web.

* Los documentos del Rol dependen de los procesos en los que este asignado este rol, y de los permisos sobre estos. Permisos de documentos: Acceder, Aprobar, Editar, Publicar, Revisar.

Beneficios de la Simulación

Como el sistema tiene cierto nivel de complejidad, muchas fallas (u omisiones) en el diseño no se detectan. Solo cuando los programadores empiezan la implementación y estas fallas empiezan a surgir.

Cuanto más complejo el sistema más propenso a fallas de diseño estará. Estas fallas tiene diferentes características, es muy difícil listar todas. Un diseño puede tener fallas menores y fallas mayores. Entre las fallas menores se pueden encontrar: omisión de atributos de una clase, una relación entre clases no especificada, clases que no existen pero son necesarias, incongruencia entre clases, etc.

Las fallas mayores NO pueden ser detectadas (o al menos es muy difícil hacerlo) hasta tanto no se comience con la implementación.

Esto es porque el diseño esta especificado en documentación estática, ejemplo, documentos Word, diagramas de clases, diagramas de casos de uso, diagramas de secuencia, máquinas de estado,etc.  Es decir, si bien esta documentación es fundamental en todo proyecto, tambien hay que reconocer que es “letra muerta“.

Por “letra muerta” se tiene que entender que es algo estático, y es imposible para alguien tener en cuenta todos los casos que se puede dar en un sistema dinámico a partir de documentos estáticos (si bien sabemos que esta documentación es fundamental).

Este es el motivo por el cual todos los proyectos tienen varias etapas de diseño –> desarrollo –> diseño –> desarrollo, etc. Esta actividad de “prueba y error” entre el diseño y el desarrollo es extremadamente costosa.

En este punto es donde la simulación es un paso fundamental para asegurar la calidad de un diseño, y así evitar por completo o en un gran porcentaje, este vaivén entre el diseño y el desarrollo.

La simulación da una visión concreta de los problemas que tiene un diseño, y los errores en el diseño están 100% especificados en la simulación.

Esta simulación provee a los actores del proyecto con valiosa información.

Si a la simulación le sumamos el prototipado –> estamos en gran ventaja con respecto a la forma tradicional de diseño.

El prototipado permite al cliente tener una mejor visión de lo que será su sistema, permitiendo que este que pueda especificar mucho mejor sus requermientos, esto redunda en ahorro de costos (que generalmente es muy difícil de cuantificar).

Antes de describir el sistema adelanto la conclusión final…

Conclusión

Con esta simulación nuestro cliente llego a la etapa de desarrollo 100% seguro de que su diseño funcionahace lo esperado y además  es lo que quiere su cliente, ya que este participo de la simulación y el diseño del prototipo.

Diagrama de Clases

Clases principales: Rol, Proyecto, Proceso, Documento, VersionBásicamente: en el sistema existen Proyectos, cada Proyecto tiene un conjunto de Procesos, y cada Proceso tiene un conjunto de Documentos. A su vez cada Documento tiene un conjunto de Versiones, la cual la última versión del conjunto es la actual.

Los Roles se asigna a los Procesos de la siguiente manera: se debe crear uno o varios GrupoProceso para cada Proceso. Luego a cada GrupoProceso se le asignan los Roles y los Permisos sobre los procesos. De esta forma un Proceso(P1) puede tener el GrupoProceso(adm), este GrupoProceso(adm) contiene los roles que serán administradores del proceso, y los permisos correspondientes de administración (Entrada, Continuar, Detener, Finalizar).

Los mismo sucede para los documentos, si bien como usuario estoy en varios procesos, pero no tengo los mismos permisos para todos los documentos de mis procesos. Al igual que los procesos, los documentos tienen GrupoDocumento, donde se configuran los roles y los permisos para estos roles.

Cuando un proceso o un documento cambia de estado, entonces se crea un evento que es enviado a todos los roles que tenga alguna responsabilidad sobre este nuevo estado.

Diagramas de Estado

Simulación y Prototipo

Esta es la ventana que le aparece el Rol luego de acceder al sistema.

La siguiente muestra los GrupoDocumento que tiene asignado este Rol.

La siguiente imagen muestra el GrupoDocumento “Administrar Documentos”.

Para mostrar parte del código de la simulación usaremos el ejemplo de Publicar una nueva Versión de un Documento. La siguiente imagen muestra una Version a punto de ser publicada.

Ahora veremos el código que se encarga de mostrar o no el botón de “Publicar” al usuario actual del sistema. En el UML Almighty a cada método se le puede asignar otro método que indica si el primero puede ser ejecutado o no por el usuario actual del sistema.

En la siguiente imagen se muestra el ambiente de desarrollo del UML Almighty, y los métodos “publicar” y “puedePublicar:”  de la clase Version.

Aquí se esta indicando que el botón “Publicar” (que ejecuta el método #publicar:) será dibujado en la página web solamente si el método #puedePublicarVersion: devuelve “true cuando se ejecute.

Estamos en la clase Version que es la responsable de publicar la nueva Version del Documento. El argumento unRol es pasado como parámetro por el UML Almighty a la hora de ejecutar el método. Para poder publicar la versión, esta tiene que estar en estado “Aprobada” y ademas el usuario actual unRol debe tener permisos para realizar esta operación, de lo contrario el botón no aparece.

Reglas:

* Si la Version no tiene estado actual no se puede publicar.

* Si la Version esta en un estado diferente al de “Aprobacionno se puede publicar.

– Se obtienen los GrupoDocumento (de este documento) en los que participa unRol.

* Si algún GrupoDocumento de unRol incluye el permiso Publicar –> el botón se dibuja en la página.

Este código se ejecuta cada vez que algún usuario entra en la página de alguna Version.

Ahora veremos el código para publicar una Versión

Reglas:

* Se crea la nueva la instancia del nuevo estado “Publicado”.

* Se pone este nuevo estado como el actual (es decir, se agrega a la colección de estados en la última posicion).

* Se envían los eventos a los usuarios correspondientes.

Código de como se cambia el estado actual

Este método es bastante sencillo, asigna la Version y Rol al nuevo EstadoDocumento. Agrega el estado a la colección de estados en la última posición, de esta forma el nuevo estado queda como actual.

Código de como se envían los eventos

Este método es un poco más complicado que el anterior.

Reglas:

* Se crea el Evento y se inicializa. Se le asigna al Evento el documento y version correspondiente, así como el estado y el permiso.

* La reglas siguientes son más complejas. Se separan en:

+ documento in: GrupoDocumento select: []. “[] – bloque de código”

+ eachGrupoDoc any: PermisoDocumento satisfy: []. “[] – bloque de código”

El primer mensaje itera sobre todos los GrupoDocumento de la Version, y selecciona solamente los GrupoDocumento que devuelvan “true” cuando se evalúa el bloque interno.

El bloque interno en este caso es el segundo mensaje #any:satisfy:, y devuelve “true” cuando al menos una de sus evaluaciones internas devuelve “true” (diferente de #all:satisfy:, donde todas tienen que ser true).

Por lo que [gruposConPermisos] son todos los GrupoDocumento que el tienen un permiso igual al permiso pasado por parametro <unPermiso>.

* Por último se agrega el Evento a todos los usuarios de los GrupoDocumento anteriores.

Conclusión

Con esta simulación nuestro cliente llego a la etapa de desarrollo 100% seguro de que su diseño funciona, hace lo esperado y además es lo que quiere su cliente, ya que este participo de la simulación y el diseño del prototipo.

Nuevo Upgrade del UML Almighty incluye -Role Based Prototype-

Posted in Executable UML, GUI, UML, UML Ejecutable, Web by smalltalkuy on julio 5, 2010

En nuevo instalador del UML Almighty incluye la nueva funcionalidad -Role Based Prototype- (Prototipo Basado en Roles).

www.uml-almighty.com

La constante simulación de un sistema a lo largo de un proyecto es una actividad que trae una enorme cantidad de beneficios.

La simulación ataca el problema fundamental de todo proyecto informático, es decir, la comunicación entre TODOS los actores del proyecto.

Esto es porque la simulación promueve que todos los actores del proyecto tengan la misma solución en sus mentes, mejorando de forma considerable la comunicación y el entendimiento.

Pero una imagen vale más que mil palabras…

UML Almighty ahora soporta Prototipo Basado en Roles y Reglas – “Rol Based Prototype”

Posted in Executable UML, GUI, POO, UML, UML Ejecutable, Web by smalltalkuy on junio 30, 2010

Hasta ahora el UML Almighty era capaz de customizar un prototipo de todas formas posibles (con un pero…). Con esta nueva funcionalidad ya somos capaces de simular cualquier sistema UML sin importar lo complicado del workflow involucrado. Pero hagamos un poco de memoria:

A una página web que muestra un objeto UML se le podía:

  • Agregar/Remover aspectos simples (enteros, cadenas, fechas, horas, etc)
  • Agregar/Remover aspectos vinculantes (para relaciones 1x – web links a otros objetos. La clase Cuenta tiene una web link [aspecto vinculante] a su Banco).
  • Agregar/Remover aspectos colecciones (para relaciones Nx – web tabs con una lista de objetos. La clase Banco tiene un web tab [aspecto colección] con sus Cuentas))

Como los aspectos están basados en comportamiento, la flexibilidad es muy grande.

PEROdada la clase Session de  un sistema ATM, la GUI (página web generada) es la misma para todos los usuarios. La página se podía customizar pero todos los usuarios verían la misma versión.

Ahora el UML Almighty puede ser customizado para mostrar diferentes prototipos (para una misma clase) según el usuario logeado actualmente.

Ejemplo con la clase Session:

La clase Session tiene…

Atributos: lastMessage (char), number (char)

Relaciones 1x: Rol, Card, ATM (es decir cada Session tiene un Rol, una Card y un ATM)

Relaciones Nx: Transaction (cada Session tiene una colección de Transaction)

Como se puede ver en el modelo hay 2 tipos de roles: User y Operator.

Ahora veremos que para la Session de un Operator de muestra una GUI y para la Session de un User se muestra otra GUI (tanto para ver como para editar).

La figura anterior muestra la dos vistas (según el Rol) para la misma clase. Los comandos (botones) también difieren según el Rol (NewDeposit para uno UpdateCash para otro).

Simplemente se definen la reglas por la cuales cada componente gráfico se muestra o no, basándose en el usuario logeado actualmente.

En este caso por ejemplo en la clase Session se define que el botón “NewDeposit” se mostrará si el método UML #canDeposit: devuelve true al ejecutarse.

Class: Session Method: [canDeposit:]

canDeposit: logedUser

“El [logedUser] se pasa como parámetro y es el usuario logeado cuando se accedió a la aplicación”

^logedUser canDeposit

Class: Operator Method: [canDeposit]

canDeposit

“El [Operator] no puede Depositar

^false

Class: User Method: [canDeposit]

canDeposit

“El [User]  puede Depositar

^true


La lógica en este caso es sencilla pero puede hacerse mucho más complicada

Class: User Method: [canDeposit]canDeposit

“El [User]  puede Depositar si la [Card] no expiro, y si el banco [Bank] no tiene a la cuenta [Account] de la tarjeta en la lista negra

^session card notExpired and: [(session bank isAccountInBlackList: session card account) not]


UML Simulation Example with ATM Model – Prototype and Executable UML

Posted in Aplicaciones, Executable UML, GUI, POO, UML, UML Ejecutable, Web by smalltalkuy on junio 17, 2010

//
En este ejemplo se verá como creat una Simulación con el UML Almighty usando un modelo ATM (cajero automático). (Ver Videos)

Luego de instalar el archivo XMI toma 10 minutos generar la siguiente simulación con el UML Almighty (incluyendo PrototipoEjecutable UML).

El modelo ATM es solamente una posible solución. La Simulación muestra como los diferentes diagramas UML se relacionan con el UML Almighty.

Se usarán dos Casos de Uso de ejemplo: login al ATM, y Realizar Depósito.

Caso de Uso: Login al ATM

El Usuario/Customer comienza una nueva Session y entra el nombre de usuario y la clave.

Si los datos ingresados concuerdan con los datos de la Card (tarjeta) insertada –> se muestra el Panel de Transacciones para realizar operaciones.

Caso de Uso: Realizar Depósito

El Usuario/Customer comienza una nueva Session (inserta tarjeta, usuario y clave). Luego realiza un Deposit en la cuenta asociada a la Card (tarjeta).


Diagram UML  de Clases – Modelo UML

Detalles

La clase ATM representa los cajeros reales. Cada Usuario (actor) comienza un nueva Session en la máquina ATM. La relación entre ATM y Session es una  association class ATMLogin.

La clase ATMLogin tiene el usuario y clave. Luego de ingresar los datos una Session es creada. Dentro de esta Session el Usuario puede realizar diferentes Transacciones.

Cada Card (tarjeta) pertence a una Account (cuenta) de un Bank (banco). El Bank (banco) realiza diferentes Transacciones. Para simular la insercción de la Card (tarjeta) se desplega una lista para seleccionar una.

Las máquinas ATM tiene un Log de operaciones. Los billetes de los ATM son administrados por la clase InnerCash.

Diagram de Actividad

Detalles

El proceso comienza cuando el Usuario ingresa el nombre de usuario y clave. Luego se selecciona una tarjeta de una lista (para simular la insercción).

Si el usuario y clave son correctos entonces se desplega un Panel de Transacciones para realizar diferentes tareas.

Cuando una Transaction es realizada se desplega nuevamente el Panel de Transacciones para que el Usuario siga trabajando.

Los diagramas de Secuencia muestran en detalle estos procesos.

Las siguente figuras muestran el Panel de Usuario y Password (o ATMLogin GUI)

Esta es la página Web que genera el UML Almighty para la clase ATMLogin, la llamamos “Panel de Usuario y Password“.

Video de la Simulación

El siguiente es el diagrama de Secuencia del proceso de login (ver video)

Como se puede ver en el diagrama de Secuencia el proceso de login devuelve una Session. Desde esta Session el Usuario puede realizar diferentes operaciones.

Ver figura del Panel de Transacciones (arriba) donde se muestra la GUI para la clase Session.

Código de la Simulación para el método UML [loginWith:] de la clase ATMLogin

En verde los comentarios.

De la misma manera que vemos en el diagrama de Secuencia este método devuelve una Session.

Cuando el usuario hace click en el botón Login el UML Almighty desplega una lista de tarjeta para simular la inserción de tarjeta.

Cuando una Card (tarjeta) es seleccinada entonces el método UML <loginWith:> es ejecutado. Este método UML pertenece a la clase ATMLogin class (ver diagrama de Secuencia).

El argumento <aCard> del método es la Card (tarjeta) seleccionada por el Usuario.

El método compara los nombres de usuario y clave ingresados con los de la Card (tarjeta). Si son iguales entonces el acceso es correcto.

Se desplega el Panel de Transacciones para realizar operaciones (es la GUI de la clase Session).

La figura siguiente muestra Panel de Transacciones:

Realizar Depósito

La figura siguiente muestra el Panel para Depósitos (clase Deposit).

Luego de ingresar los datos del Depósito el Usuario debe confirmar o cancelar la transación.

Cuando el Usuario hace click en Save Object la siguiente página es desplegada:

El siguiente diagrama de Secuencia muestra el proceso para depositar en el ATM.

1. El Usuario hace click en NewDeposit en el Panel de Transacciones (SessionGUI).

2. Se crea una instancia de Deposit y se desplega el Panel de Depósitos (DepositGUI). El Usuario ingresa los datos (Panel de Depósitos 1).

3. El Usuario hace click en Confirm o Cancel (Panel de Depósitos 2)

4. El banco realiza la transacción para la cuenta de la tarjeta (método processDeposit:for:).

5. El Panel de Transacciones se muestra nuevamente con el resultado de la transacción. El Usuario puede seguir realizando otras operaciones.

Código de Simulacióm para el método UML #confirm de la clase Deposit

Código de Simulacióm para el método UML #processDeposit:for: de la clase Bank

El resultado de la transacción:

Video de la Simulación

“UML Simulation and Execution” con el UML Almighty

Posted in Aplicaciones, Executable UML, GUI, POO, Traits, UML, UML Ejecutable, Uncategorized, Web by smalltalkuy on junio 3, 2010

Simulando una aplicación con el UML Almighty.

En este video vemos como usar el UML Almighty para poder simular/ejecutar lo diseñado. En unos pocos minutos tenemos la aplicación andando.

UML Almighty ademas de generar un prototipo ejecuta comportamiento.

En este video se ven algunas de las customizaciones posibles en el UML Almighty.

www.uml-almighty.com