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

UML Almighty Ciclo: Editar – Debug – Editar – Debug SIN detener el Sistema

Posted in Executable UML, POO, UML, UML Ejecutable by smalltalkuy on diciembre 1, 2011

UML Almighty tiene la capacidad de agregar/modificar clases y comportamiento sin necesidad de detener la aplicación.

Esta funcionalidad fue cuidadosamente pensada y diseñada para maximizar la experiencia del usuario en la simulación UML.

Obviamente que la funcionalidad esta inspirada en la misma solución implementada en los diferentes Smalltalk.

En palabras de Malte Ubl de Google (link a post original):

… También Gilad Bracha (creador del lenguaje de Google Dart) está prometiendo ciclos de edición-depuración-edición-depuración al estilo Smalltalk (sin detener el programa). Si has trabajado alguna vez con Visual Works Smalltalk u otro ambiente Smalltalk que soporte esta funcionalidad, tendrás que estar de acuerdo en que otro ambiente de desarrollo incluyendo los de la corriente principal –mainstream– (C, C++, Java, C#, etc) se siente como de la edad de piedra.

Poder crear un sistema agregando/modificando/moviendo comportamiento y sin detener el sistema es una ventaja enorme que puede ser comprendida mediante la experimentación con cualquiera de estos sistemas.

En el UML Almighty toda la configuración del comportamiento de la simulación asi como el interfase (GUI) del prototipo se puede hacer on the fly, es decir, con el sistema andando, el sistema nunca se detiene, esta forma de trabajo se asemeja a trabajar con un sistema biológico, que siempre esta en marcha.

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.

 

 

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.

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]