GLASS – Ambiente de desarrollo Web
La gente de GemStone/S ha aumentado los limites para la versión free del ambiente GLASS – GemStone/S Linux Apache Seaside Smalltalk– para desarrollo web.
Los nuevos limites están publicados es: http://seaside.gemstone.com/docs/GLASS-Announcement.htm
Los más importante son:
Repositorio de objetos: ilimitado (la restricción anterior era de 16 GB)
Número de Procesadores del servidor: 2 (antes 1 procesador)
Shared Page Cache (SPC): 2 GB (antes 1 GB)
El SPC es muy importante ya que es el cache de los objetos accedidos más frecuentemente, si bien 1 GB de SPC era suficiente, ahora con 2 GB esta mucho mejor.
Ahora con estos nuevos parámetros GLASS se convierte en una opción real para empresas comerciales de tamaño pequeño o para desarrolladores individuales.
Dado que GemStone/S es una Base de Objetos, NO requiere el mapeo entre el Modelo de Objetos/Clases y el Modelo Relacional.
Limites de la Versión Full de GemStone/S
Repositorio de objetos: ilimitado (8192 TeraBytes)
Número de Procesadores del servidor: ilimitado
Shared Page Cache (SPC): 32768 GB
UML Almighty: Framework the eventos SASE
Ahora el UML Almighty soporta el framework SASE de eventos (self-addressed stamped envelope).
SASE es parecido al patrón Observador (observer pattern), aunque con algunas diferencias.
Este framework facilita la construcción de sistemas con acoplamiento flexible (o débilmente acoplados).
Consta básicamente de dos partes: subscriptor y publicador. Cualquier objeto dentro del UML Almighty puede ser subscriptor y publicador al mismo tiempo, todo depende de como quiera configurar los eventos.
Publicador:
Es un objeto UML que publica eventos, y tiene una colección de subscriptores. Cuando el publicador publica un evento entonces todos los subscriptores a ese evento son notificados (los eventos puede tener parámetros).
Subscritores:
Es un objeto UML que se ha subscrito a algún evento de algún publicador.
Ejemplo:
En la siguiente imagen vemos que cuando un Proceso cambia de estado a estado [Ejecutando] trigera el evento [procesoContinua:] pasando como parámetro la fecha del día. Todos los objetos que estén subscritos a este evento serán notificados del evento, recibiendo la fecha del día como parámetro. Para esto se usa uno de los siguientes mensajes [trigger:], [trigger:with:] [trigger:withArguments:], etc. En este caso es [trigger:with:]
El primer argumento corresponde al nombre del evento, y el resto son los parámetros del evento. En este caso hay solamente un parámetro [Date today].
En el siguiente Script UML vemos como se pueden subscribir los objetos a un evento determinado. Si bien esta en un Script la suscripción se puede hacer mediante la GUI, es decir, que la suscripción esta embebida dentro del código de la aplicación. Todo depende de como este configurado el sistema.
En este caso hay 3 objetos que se subscriben al evento [procesoContinua:] del objeto [unProceso].
El mensaje para subscribirse a un evento es [subscribeTo:eventHandler:publisher:], dónde el primer argumento es el nombre del evento (que debe coincidir con el nombre enviado con el mensaje [trigger:]), el segundo argumento es el método a ejecutar del subscriptor, y el tercer argumento es el objeto publicador.
Para el primer caso entonces tenemos que: el objeto desarrollador se subscribió al evento [procesoContinua:] del objeto publicador [unProceso], cuando este evento suceda se invocará el método [cuandoUnProcesoContinue:] del objeto subscriptor [desarrollador].
Para el segundo caso entonces tenemos que: el objeto gerenteFabrica se subscribió al evento [procesoContinua:] del objeto publicador [unProceso], cuando este evento suceda se invocará el método [cuandoProcesoDetenidoContinue:] del objeto subscriptor [gerenteFabrica].
Para el tercer caso entonces tenemos que: el objeto administradorDeProcesos se subscribió al evento [procesoContinua:] del objeto publicador [unProceso], cuando este evento suceda se invocará el método [reanudarMetricasDeProceso:] del objeto subscriptor [administradorDeProcesos].
Como se ve en este ejemplo, cada subscriptor decide cual de sus métodos será el encargado de manejar el evento (eventHandler) cuando este ocurra.
Toda la configuración de eventos se puede modificar mientras el sistema esta ejecutando por lo que permite gran flexibilidad.
Google (google web toolkit) compra la empresa Instantiations
5 de Agosto de 2010 Google (GWT – google web toolkit) compra la empresa Instantiations.
En la página de Instantiations (http://www.instantiations.com/) se anuncia la noticia.
Instantiations tiene dos lineas de negocio: Java y Smalltalk. Google adquiere todo los derechos del negocio Java de Instantiations.
El producto Instantiations para Java es una IDE para usar el Google Web Toolkit. No solamente es para diseñar GUIs con GWT, sino que esta muy integrada con Eclipse, lo que permite a sus usuarios tener un ambiente de desarrollo integrado con Eclipse para desarrollar programas GWT de forma fácil y rápida.
Todavía no hay nada oficial pero los desarrolladores Java creen que el «GWT Designer» como se llama el producto de Instantiations distribuya de forma gratuita con el GWT (google web toolkit).
Con esta compra la nueva Instantiations podrá foco solamente en su producto estrella VA Smalltalk (que es el sucesor del VAST – Visual Age for Smalltalk de IBM).
Por que Google no compro esta parte (Smalltalk) del negocio también ?
Según el presidente de Instantiations que habla por parte de él y no de Google: «Google queria algo que cause un impacto inmediato. El desarrollo en Smalltalk es un mundo totalmente nuevo, y no creo que estén preparados para ese cambio».
También hay algunos blogs que se preguntan: «Habrá comprado Google el huevo y no la gallina ?. Mucha gente no sabe que Eclipse fue escrito originalmente en IBM Smalltalk. La máquina virtual de Java, HotSpot VM esta inspirada en tecnología obtenida de la comunidad Smalltalk».
Además de comprar el producto todo el equipo de Java de Instantiations se va para Google para continuar el desarrollo de este producto.
La noticia es increíble dado que hace tiempo Instantiations ha migrado parte de su tecnología Smalltalk a Java con el fin de hacer dinero, y vaya si lo lograron. La mayoría de los productos Java de Instatiations están basados productos ya existentes en Smalltalk, en este caso VA Smalltalk.
Como se titula en algunos sitios esta compra es una gran ganancia para Java y Smalltalk, y claro tambien para Instantiations, ya que la suma de dinero que se pago no se ha hecho pública.
Muy Bien por la gente de Instantiations que no cerró el negocio y se fue a vivir a una isla en el Caribe, y siguen con todo con VA Smalltalk. Nueva página: http://st.instantiations.com/. Más info: http://st.instantiations.com/company/google-transition.html
Esta es la segunda venta que hacen empresas que se dedican a Smalltalk y extrapolan/adaptan sus producto (o parte de ellos) a 0tras tecnologías.
La anterior fue la adquisición de GemStone por parte de VMWare.
PD en broma: no le interesarán los diagramas UML a Google, podrían comprar el excelente producto UML Almighty: www.uml-almighty.com, que genera una Aplicación Web a partir de un diagrama UML.
Nuevo build del UML Almighty con bugs arreglados
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
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 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.
Diagrama de Clases
Clases principales: Rol, Proyecto, Proceso, Documento, Version. Bá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 «Aprobacion» no 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-
En nuevo instalador del UML Almighty incluye la nueva funcionalidad -Role Based Prototype- (Prototipo Basado en Roles).
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»
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.
PERO…dada 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
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
//
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 Prototipo y Ejecutable 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
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.
Lanzamiento UML Almighty
El UML Almighty es un simulador de aplicaciones UML. Durante cualquier momento de la etapa de análisis, diseño y desarrollo permite crear/simular una aplicación concreta. Dando a los diferentes actores del proyecto un marco definido para trabajar sobre el sistema.
En un proyecto sin la capacidad de generar este marco definido cada actor del proyecto tiene una representación mental diferente de la solución, lo que conduce a una solución fragmentada que costará mucho integrar (desde el punto de vista funcional).
Tener la capacidad de simular/ejecutar un diseño unifica la representación mental de la solución de todos los actores de proyecto, cuando esta actividad empieza de forma temprana trae un sin número de beneficios: solución unificada en todos los actores, mejora la comunicación entre los actores, evita malentendidos entre los actores y clientes, permite mostrar prototipo al cliente en cualquier punto del proyecto, mejora la integración funcional, etc.
Proceso Inicial
1. Cuando se importa un diagrama de clases (usando un archivo XMI) el UML Almighty construye internamente un meta modelo para ese diagrama.
2. Basándose en este meta modelo el UML Almighty simula la aplicacion WEB y Desktop.
3. Para customizar esta aplicación se crean métodos que se arrastran y sueltan (drag&drop) en categorias virtuales especiales para la customización.
El UML Almighty soporta achivos XMI de la siguientes herramientas:
* UModel
Las diferentes licencias son (la cantidad de diagrama de clases no esta limitada):
0. UML Almighty x20 – permite hasta 20 clases por diagrama de clases. Sin costo
1. UML Almighty x40 – permite hasta 40 clases por diagrama de clases. USD: 40
2. UML Almighty x80 – permite hasta 80 clases por diagrama de clases. USD: 80
3. UML Almighty Full – permite hasta N clases por diagrama de clases. USD: 140
Disponible para bajar en: http://www.uml-almighty.com/sp_uml_executable_downloads.html
Link directo al instalador: http://www.uml-almighty.com/UML_Executable/uml_almighty_setup.zip
Adquirir licencias comerciales en: http://www.uml-almighty.com/sp_buy.html
UML Almighty Support
Administración del Conocimiento - UML Simulation 
1 comment