Administración del Conocimiento – UML Simulation

Dolphin Smalltalk 7 is open source incluyendo la Máquina Virtual

Posted in Aplicaciones, POO by smalltalkuy on febrero 19, 2016
Dolphin Smalltalk

Dolphin Smalltalk

Excelente NOTICIA, Dolphin Smalltalk es open source (http://www.object-arts.com/) incluyendo el código de la Máquina Virtual.

El código esta en:

https://github.com/dolphinsmalltalk

Se pueden bajar Dolphin Smalltalk 7 con los fuentes o simplemente bajarse el instalador.

https://github.com/dolphinsmalltalk/Dolphin

El código de la Máquina Virtual esta en (para compilar la VM se necesita Visual Studio 2015 -community-):

https://github.com/dolphinsmalltalk/DolphinVM

Si simplemente quieren usar o probar Dolphin Smalltalk no hay necesidad de bajarse la VM el instalador trae todo empaquetado para instalar y comenzar a usar. El código de la VM es para quienes constribuimos a mejorar esta excelente herramienta.

Por cualquier duda pueden preguntar en el news groups en:

https://groups.google.com/forum/#!forum/comp.lang.smalltalk.dolphin

 

Anuncios

Usando JADE en Producción

Posted in Aplicaciones, OODBMS - Base de Objetos, POO by smalltalkuy on marzo 18, 2014

La siguiente figura muestra de forma simplificada como queda la instalación de un sistema con GemStone/S 64 bits: 

(http://gemtalksystems.com/(http://seaside.gemtalksystems.com/).

Los clientes Web se contectan al servidor GemStone/S por internet, de esta forma dan usa a la aplicación web.

Al mismo tiempo que los usuarios usan el sistema, existe la posibilidad que desarrolladores se conecten on-line al sistema para hacer modificaciones (paso 1) que una vez “comiteadas” (luego del #commit) quedan disponibles a los usuarios finales (paso 2).

No hay limitaciones en los tipos de cambio a realizar: cambios en la estructura de objetos (o clases), migraciones de objetos (datos), cambios de comportamiento de la aplicación, cualquier cambio es posible.

Alternative development environment

Alternative development environment

 

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

Arquitectura GLASS comparada con Ruby on Rails

Posted in Aplicaciones, OODBMS - Base de Objetos, Web by smalltalkuy on enero 26, 2011

Descripción

En esta ocasión voy a describir la arquitectura del framework GLASS (gemstone/s – linux – apache – seaside – smalltalk) con más detalle, y luego voy hacer una comparación sencilla con Ruby on Rails.

También ver el blog de Avi Bryant (Twitter) sobre GemStone/SRuby on Railshttp://www.avibryant.com/2008/03/ive-had-a-numbe.html

En la comparación solamente se mostrarán las diferencias, cada uno puede sacar sus conclusiones según su conocimiento.

La siguiente imagen denota de forma detallada (pero no completa) la arquitectura de GLASS:

Network: representa la web y los diferentes clientes web que se conectan con GLASS.

Database host: es el repositorio alojado físicamente en un servidor. El repositorio se puede dividir en N extent, cada extent es un archivo en disco.

Transaction logs host: es el LOG de transacciones de GemStone/S que puede estar ubicado en otro servidor diferente del  repositorio (como en este caso).

Stoned Process: el proceso Stoned es el coordinador del repositorio y de los procesos Gem. Este proceso se encarga de guardar y recuperar objetos del repositorio en disco, asi como asegurar la concurrencia de los procesos Gem y la consistencia del repositorio. El proceso Stoned puede correr en el mismo host que los Gem o no (esto es configurable).  Los conflictos de actualización son resueltos por el proceso Stoned. Hay un Stoned por repositorio.

Gem Process: son (procesos) máquinas virtuales que le dan vida a los objetos del repositorio, ejecutan métodos de las clases, alteran objetos y crean nuevos, etc. Cada Gem actual como un repositorio único para los clientes. Los procesos Gem también pueden actualizar el repositorio si esa actualización no entra en conflicto con algún otro proceso Gem.

Shared Page Cache: son segmentos de memoria virtual del SO. Cuando los objetos son accedidos a disco entonces se van cargando en el Shared Page Cache. Si un objeto todavía no ha sido accedido entonces cuando se lee por primera vez se carga en el Shared Page Cache, luego el próximo Gem que requiera ese objeto no tiene que acceder a disco. Como se ve en la figura puede haber más de un Shared Page Cache, estos se llaman Remote Shared Page Cache. Las sincronización entre los diferentes Shared Page Cache se haceautomáticamente  y es transparente para el desarrollador. Hay procesos (que son invisibles cuando estamos desarrollando) que se encargan de copiar y mantener actualizados los diferentes Shared Page Cache.

Continuations

Esta plataforma de desarrollo soporta Continuations. Continuations da la capacidad de persistir la pila de ejecución de un proceso Gem (recordar un Gem es una máquina virtual) y guardarla en el repositorio. Luego otro proceso Gem puede acceder a esa pila de ejecución en el repositorio, cargarla en memoria y continuar con su normal . Por lo que no hay que preocuparse en identificar que proceso Gem se hizo cargo de que petición.

Debug

Si ocurre un error en nuestra aplicación web somos capaces de guardar la pila de ejecución en el repositorio, y luego acceder al servidor y como DBAs levantar la pila de ejecución y analizar el error.

Si !!! todo el contexto del error se guarda en el repositorio y vamos a poder explorar todo los objetos involucrados en ese error, y ejecutar paso a paso lo que hizo el usuario para que surgiera ese error.

Escalabilidad

GLASS soporta escalabilidad horizontal, es decir, que a cualquier problema de performance se puede agregar más servidores para albergar más procesos Gem. Como los procesos Gem son las máquinas virtuales entonces tengo más recursos para responder a las diferentes peticiones.

Sistemas Reales

Toda esta arquitectura puede correr sobre el mismo servidor o distribuido en N servidores.

JP Morgan

Hay sistemas en producción dónde cientos de máquinas (de los mismo usuarios de la intranet) albergan cientos de procesos Gem. En este caso al escalabilidad es horizontal.

London Petroleum Exchange

Un solo servidor alberga toda la aplicación, este servidor es un AIX Power 6 con 512 Gb de memoria.

Comparación con Ruby on Rails

No soy experto en Ruby on Rails solamente conozco parte de la arquitectura.

Una aplicación Ruby on Rails típica consta de: un cluster de servidores para soportar la base de datos, varios caches en memoria, varios procesos que se encargan del funcionamiento de los objetos y la renderización de páginas web.

Normalmente la base de datos es MySQL y se ubica en unos o más servidores, luego hay varios servidores que albergan los caches en memoria (memcached) (el número de servidores para MySQL es el mismo que para los memcached), y se activan entre 8 y 12 worker processes para realizar el procesamiento, llamados mongrels (incluyen el interprete Ruby y el Web Server Mongrel).

Los mongrels aceptan las peticiones web y ejecutan el código de la aplicación. Los objetos dentro de los worker processes están vivos, envían y reciben mensajes, ejecutan métodos, cambian los estados de los objetos Ruby, etc. Los objetos solamente existen en la memoria de un mongrel en particular.

Estos objetos se persisten en la base de datos usando los Active Records de Ruby. Cuando un mongrel modifica un objeto, y la transacción hace commit entonces objeto se actualiza en MySQL, y cuando algún otro proceso lo lea obtendrá la versión actualizada del objeto.  Los objetos dentro de MySQL están muertos, no hacen nada hasta que son puestos dentro del algún proceso mongrel.

Ruby on Rails y GLASS (gemstone/s linux smalltalk seaside)

MAGLEV hace posible el desarrollo de aplicaciones Ruby sobre GemStone/S, con una la arquitectura idéntica a la de Smalltalk.

 

VMWare, Twitter y Google tres compras grandes este año

Posted in Aplicaciones, OODBMS - Base de Objetos by smalltalkuy on diciembre 11, 2010

Este año ha sido particularmente interesante para el mundo Smalltalk, ya que VMWare, Twitter y Google, compraron (total o parcialmente) tres empresas especialistas en tecnología Smalltalk.

Primera Compra (Buscar en google: “VMWare acquired GemStone”)

En mayo SpringSource una división de VMVare compro la empresa GemStone Systems.

GemStone es la empresa creadora de GemStone/S, “el Oracle de las OODBMS“, y de la plataforma de desarrollo GLASS (GemStone/S Linux Apache Smalltalk Seaside), además tiene productos para tecnología Java, Ruby, etc.

Como resultado de esta compra la plataforma GLASS ha aumentado la capacidades de la versión libre (y código abierto al estilo Smalltalk). Ahora no hay limite para el tamaño del repositorio de objetos, la SPC (shared page cache) puede ser de hasta 2 GB, y hace uso de hasta dos procesadores.

Segunda Compra (Buscar en google: “Twitter Acquires Smallthought Systems”)

En junio Twitter adquiere la empresa Smallthought Systems, esta empresa es la creadora del framework Web Seaside para diferentes Smalltalks. También han contribuido a la comunidad de Ruby on Rails, uno de sus creadores es Avi Bryant.

Tercera Compra (Buscar en google: “Google acquire Instantiations”)

En septiembre el gigante Google compra la totalidad de los productos y recursos humanos de Instantiations en tecnología Java. En esta compra hay dos claros beneficiados,  primero los desarrolladores Java, ya que todos los productos para Java de Instantiations son gratis, como ser: GWT DesignerCodePro AnalytiXWindowBuilder ProWindowTester Pro. Todos estos productos se pueden bajar sin cargo. Los segundos beneficiados son los desarrolladores de VA Smalltalk ya que el presidente de Instantiations aseguro que los ingresos obtenidos se volcarían a expandir su tecnología Smalltalk. Varias de las herramientas Java construidas por esta empresa están basadas en herramientas ya existentes en su tecnología Smalltalk.

Ha sido un año movido y parece que los ambientes y lenguajes dinámicos están tomando cada vez más fuerza…

Saludos…..

 

UML Almighty: Framework the eventos SASE

Posted in Aplicaciones, Executable UML, UML, UML Ejecutable by smalltalkuy on septiembre 22, 2010

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.

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.

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