Open Source "UML Almighty": Executable UML, Simulation, Prototyping and more

June 30, 2010

UML Almighty now support “Rol Based Prototype”

Filed under: Executable UML, OOP, UML, UML Simulation — umlalmighty @ 7:38 pm

UML Almighty can customize a prototype in different ways. But once the prototype is customized, all users has the same view of the system.

Now UML Almighty support “Rol Based Prototype” that allows to define more than one view for the same UML class, depending on the loged user.

With this capability the UML Almighty can simulate any workflow of any UML system. The complexity of the workflow is not a problem, because it is simulated as behavior. To remember the prototype and simulation:

A web page that shows an UML object can:

  • Add/Remove simple aspects (integers, strings, dates, times, etc)
  • Add/Remove link aspects (for 1x relations- web links to other objetcts. The Account class Cuenta has a web link [link aspect] to it’s Bank).
  • Add/Remove collection aspects (for Nx relationsweb tabs with a collection of UML objects. . The Bank class has a web tab [collection aspect] with it’s Accounts)

As the aspects are based on behavior they are very flexible and powerful.

BUTfor the class Session in an ATM system, the GUI (web page) is the same for all users. This has changed with the new functionallity.

NOW UML Almighty can be customized to show different prototypes (for the same class) depending on the loged user.

Example with Session class:


The class Session

Attributes: lastMessage (char), number (char)

1x Relations: Rol, Card, ATM (each Session has a Rol, a Card and an ATM)

Nx Relations: Transaction (each Session has a collection of Transaction)

As you can see there are two different rols: User and Operator.

Now the class Session shows a GUI when the loged user is an Operator and shows another GUI when the loged user is an User.

The picture above shows the two Views for the same class Session. The command buttons also can be customized based on the loged user.

How UML Almighty ahieve this ?

Each GUI component can be associated to an UML show/hide method. When a component is about to be rendered then the UML Almighty executes the show/hide method sending the loged user as an argument.

Class: Session Method: [canDeposit:]

canDeposit: logedUser

“The [logedUser] is sent as an argument to the show/hide method. We ask to the loged user if it can deposit cash “

^logedUser canDeposit

Class: Operator Method: [canDeposit]

canDeposit

“The [Operator] can not Deposit

^false

Class: User Method: [canDeposit]

canDeposit

“The [User]  can Deposit

^true


The logic here is very simple (true or false) but it can be very complicated.

Class: User Method: [canDeposit]

canDeposit

“The [User]  can Deposi  if the [Card] not expired, and the [Bank] does not have the [Account] in the blak list

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


Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: