I challenge the Java Hackers, read on….
As you probably all know by now, I have joined ISIS Papyrus a while ago and last week i was reading the Papyrus Objects Developer Guide again and suddenly lightning hit me and the question raised can this actually be done in Java and if so, how and how easy?
Be aware, reading further could put you in a depression but on the otherhand the real Hacker will find it a challenge. Are you the Hacker?
From the ISIS Papyrus Objects manual for Developers: Classes are the definitions of objects and their behavior designed by the Developer. Classes are required to define general properties of objects derived from these classes, namely attributes, methods, states, and child/parent reference definitions. All classes reside exclusively in the Repository. The object tree in the Repository reflects the inheritance chain. As child objects of a class reflect an inheritance relationship it inherits all properties (methods, attributes, states, state transitions, and parent/child relationships).
Big deal and obvious you may think. But did you noticed the fact that we talk here also about states, state transitions and parent/child relationships.
Papyrus has full support for those concepts without any line of programming. Besides this there is full support for Security (role, policy, privilege), Version control (you can even view the versions and each instance knows to what version it belongs). But more on that maybe later.
I would like to see and explained Java Implementations that cover the UML implementation of State Machine, Parent/Child and Constraints (OCL) as this is all standard in Papyrus Objects and does not require programming at all.
Hackers, show me a simple application simulating for example a traffic light with some attributes and methods that have been constrained as well the state transition itself. You would be a super hacker if you also implement security.
Need inspiration for your Java Hack? Read some parts of our ISIS Objects Manual for Developers and start Hacking. I am waiting for your solutions and i am sure other Hackers will comment on them so that at the end the best solution will be available to be compared to Papyrus Objects. SUCCESS
In Papyrus Objects, authorization is established through Roles, Privileges, and Policies that give Users the authorization appropriate for their tasks. This structure allows the Security Administrator to precisely control access to objects, whatever the User’s needs are.
The Role/Policy concept used in Papyrus Objects is modelled after the CORBA standard of Role Based Access Control (RBAC). Since users are not assigned permissions directly, but only acquire them through their Role (or Roles), management of individual user rights becomes a matter of simply assigning the appropriate Role(s) to the user, which simplifies common operations such as adding a user, or changing a user’s department. The Policy controls the visibility and thus complex filtering for presentation into frames is not necessary if the Policies are well set.
Access to objects (and usually also their visibility) is granted by policies, i.e. the user must be using a Role that is referenced by any of the Policies defined on the object, to access it.
Access to attributes and methods of objects is granted by Privileges, i.e. the user must be using a Role with the required privilege. In addition this Role must also be referenced by any of the Policies defined on the object.
A state machine consists of states and their state transitions, which define the life cycle of an object. Conditions can be defined, thus certain actions can only be applied to an object if it is currently in an appropriate state (e.g. Task in state “Completed” cannot be processed). The fields of the state machine in Papyrus Objects are similar to UML (Unified Modeling Language). The “state machine view” is a frame of the Class Editor and displays the whole state machine in a flow chart. It can be used as a graphical editor similar to the UML Case tools. The state machine lists the states that an instance can have, and the Transitions between those states. Therefore it defines the object’s behavior:
- What kind of information (event) is sent to other objects.
- Which methods are available within the current state.
- Which event sent by a program triggers a state transit
The state change of an object can be:
- user driven
- driven by events
- driven by messages
A State Change has Entry, Exit, and Do Events (actions).
Via child and parent references the relationship between parent and child objects can be defined. A child reference can be used to define which type of object may be added to the object via a parent reference it is possible to defined to which type of object the object may be added.
Constraint fields are used to define whether access to or modifications on a part of an object is granted. This way it is possible to define conditions which decide that a state transition for instance may not be executed under certain circumstances or an attribute cannot be changed in a certain state. If the expression in a constraint field evaluates to TRUE (or the field is left blank) the respective part of the object may be accessed or modified. If a constraints field evaluates to a number, then any number other than zero is true, and zero is false.
The following sections of a class / template definition contain constraint fields:
- Object start (Constraints)
- State (Send Modification Event if)
- State Transitions (Change trigger, Guard)
- Attribute (Constraints, View constraints, and Edit constraints)
- Method (Pre constraints and Post constraints)
- Child and Parent References (Constraints, View constraints, and Edit constraints)
To define which group of users should be able to call a method or view / edit an attribute, select the related Privilege(s) in the field “Privileges” of the method or “View Privileges” or “Edit Privileges” of the attribute. ISIS provides the following predefined Privileges, which are defined in the Privileges object below the Storage folder “Storage / System Collection”:
$_Developer … Create / modify classes and templates
$_Administrator … Create / Modify templates
$_Security Administrator … Manages access rights
$_User … End user, cannot create / modify classes and templates, not all methods available.
$_Guest … End user with very limited rights for viewing.
$_Licence Administrator … Administrates product authorizations
$_System Administrator … General administration (e.g. creation of Client Nodes, import of transfer files, etc.)
$_Supervisor … System supervisor for the select of objects, which should generate an audit trail (with System Supervisor Role) or privileged end user for release tasks.