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

Licencia Open Source: The PostgreSQL Licence (TPL)

Posted in Executable UML, POO, UML, UML Ejecutable, Web by smalltalkuy on febrero 9, 2011

Finalmente optamos por la licencia The PostgreSQL Licence (TPL) para el UML Almighty.

The PostgreSQL Licence (TPL)

[OSI Approved License]This is a template license. The body of the license starts at the end of this paragraph. To use it, say that it is The PostgreSQL License, and then substitute the copyright year and name of the copyright holder into the body of the licnese. Then put the license into a file called “LICENSE” in your software distribution. 

Copyright (c) $YEAR, $ORGANIZATION

Permission to use, copy, modify, and distribute this software and its documentation for any purpose, without fee, and without a written agreement is hereby granted, provided that the above copyright notice and this paragraph and the following two paragraphs appear in all copies.

IN NO EVENT SHALL $ORGANISATION BE LIABLE TO ANY PARTY FOR DIRECT, INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS, ARISING OUT OF THE USE OF THIS SOFTWARE AND ITS DOCUMENTATION, EVEN IF $ORGANISATION HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

$ORGANISATION SPECIFICALLY DISCLAIMS ANY WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE SOFTWARE PROVIDED HEREUNDER IS ON AN “AS IS” BASIS, AND $ORGANISATION HAS NO OBLIGATIONS TO PROVIDE MAINTENANCE, SUPPORT, UPDATES, ENHANCEMENTS, OR MODIFICATIONS.

Actualización del Sitio Web

En los próximos días estaremos actualizando la página y poniendo el nuevo instalador y el código fuente para bajar. El código fuente demorará un días más ya que debemos remover el framework de seguridad de licencias que esta en la aplicación actual.

Para poder editar el código fuente se necesita el ambiente de programación Dolphin (www.object-arts.com), la versión Community de Dolphin es gratis y viene con todo el código fuente del ambiente de programación.

Que hace UML Almighty

* Genera una aplicación Web/Desktop customizable a partir de un Diagrama de Clases (utilizando un arvhivo XMI).

* Se puede programar comportamiento, los Diagramas de Sequencia pueden ser ejecutados.

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

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

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.

 

 

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.

 

GLASS – Ambiente de desarrollo Web

Posted in OODBMS - Base de Objetos, POO, Web by smalltalkuy on octubre 24, 2010

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


Google (google web toolkit) compra la empresa Instantiations

Posted in Web by smalltalkuy on agosto 9, 2010

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 VASTVisual 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

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]