tutorial

how to control the object instance behaviour with a lifecycle

Business objects may have methods, rules, states as ways to describe the actions that can be performed with them. You cannot create an object instance in OBEROn without specify what is its behaviour inside the application environment. The object behaviour depends in part from the object type (or class) but mainly from the lifecycle associated to it. A lifecycle controls a business object: it specifies the rules that govern user access, validations, state transitions, revision rules, type of attachments, documents and so on. If you want to know what a user can do with a business object, you should look at the object’s lifecycle.

In details, a lifecycle includes all the following information:
• The object classes that may be subjected to it
• The types of documents (filetypes) that are allowed for objects associated with this lifecycle
and the default filetype automatically used
• The filespace where these files are stored into
• The revision rule that defines the labels in the revision sequence
... and some options :

  Check update This option enables/disables the synchronization counter for object instance updates: the object internal counter is increased after each modification, in case of the read counter doesn't match the current value during the update operation an exception is raised
  Undo This option enables/disables the rollback of edit operations for object instances
  Add To Recent Every time a user opens an object and reads its information, the object is added to a user own objectgroup called "Recent_Objects" (automatically created if not exists). This flag overrides the same flags activated or not on single stages.





The revision rule is an expression composed of positional digits (symbols) and separator characters.

Symbol
Description
1,2,3,4,5,
6,7,8,9
digits from 0 to N [ ex: 1 = (0,1) binary ; 7 = (0,1,2,3,4,5,6,7) octal ; 9 = (0,1,...,8,9) decimal ]
x
hex digits with lower case letters (0,..9,a,b,c,d,e,f)
X
hex digits with upper case letters (0,..9,A,B,C,D,E,F)
a
lower case alphabetic characters (a,b,c,d,....,x,y,w,z)
A
upper case alphabetic characters (A,B,C,D,....,X,Y,W,Z)
z
lower case alphanumeric characters (0,1,..,9,a,b,c,d,....,x,y,w,z)
Z
upper case alphanumeric characters (0,1,..,9,A,B,C,D,....,X,Y,W,Z)
o
unlimited lower case english literal numbers (one,two,three,four,..........)
O
unlimited upper case english literal numbers (ONE,TWO,THREE,FOUR,..........)
l
limited lower case english literal numbers (one,two,three,four,...,nine,ten)
L
limited upper case english literal numbers (ONE,TWO,THREE,FOUR,...,NINE,TEN)
i
unlimited lower case roman numbers (i,ii,iii,iv,v,vi,vii,viii,ix,x,xi...)
I
unlimited upper case roman numbers (I,II,III,IV,V,VI,VII,VIII,IX,X,XI...)
r
limited lower case roman numbers (i,ii,iii,iv,v,vi,vii,viii,ix,x)
R
limited upper case roman numbers (I,II,III,IV,V,VI,VII,VIII,IX,X)
   
Separator characters: !£$%&/()=?^*+°§<>;,:._-#@[]{}€ and space

The first revision is obtained by replacing every positional symbols with the first item in the corresponding sequences. The next revisions are computed by incrementing the most right symbol; when the digit sequence reaches the last element the rest is propagated to the other digits on the left, as in a usual positional number system.
For example the sequence generated from the rule R/2 will be:

I/0  I/1  I/2  II/0  II/1  II/2  III/0  III/1  III/2  IV/0  IV/1  IV/2 .......  IX/0  IX/1  IX/2  X/0  X/1  X/2



When you add a class under the lifecycle control, all derived classes in the class-hierarchy automatically will be subjected to it and it is not necessary to add all of them.


Moreover a lifecycle consists of a series of linked stages, each of which represents a state in the life of the governed objects and includes the following information:
• Who will have access to the object when it is in this stage
• What actions will be registered into the object history
• If the object can be revised (revisionable condition)
• The conditions required for changing state

A lifecycle may have one or more stages. This number depends from the type of objects it governs. For example, you might have a lifecycle for a static object that represents a company: you can update its information data like the name, the address, the telephone number, but it never changes its state. In this situation, you might have only one stage where access to modify this information is well defined.
To add a new stage simply click with the mouse right-button inside the drawing area; this stage will be appended to the end of the sequence. Otherwise, if you want to insert a new stage before or after another just select the reference stage and click over it. As soon as you add a new stage this takes a progressive name (Stage_1, Stage_2 ...); with a mouse double click over it, you can edit the stage properties included the stage name and description.




The access level for each stage is characterized by different conditions. The lifecycle allows the user access for a specific action on a object in the current stage if the access for the action is permitted:

• to the community or
• to the holder and the user is the object holder or
• directly to the user or to a user category (team or assignment) to which the user belongs

The user’s definition takes precedence over accesses granted in the lifecycle: if an access is denied in the user mask, the user will not have access to the specified action, even if the lifecycle assigns the access.
(*) However, a person can be “granted” access to an object instance even if the action is denied in the user definition. This possibility is called "delegation".
Users - who have the "delegate" access privilege for an object instance in the current stage - can delegate any or all the access privileges they have for an object to one or more user.

In particular the access precedence is computed as follow:
- if the user is a superuser, then the access is automatically granted
- if the user's general specification don't allow the action, the access is denied (see above *)
otherwise the access is allowed if the action is selected for:
- the community [refers to every user defined in the OBEROn database]
- the holder [refers to the user who is the current (main/alternative) holder of the object instance. The user who created an object it is identified as its holder and keeps this role unless this qualify is transferred to someone else]
- the user directly
- a team to which the user directly or indirectly (due to the team hierarchy) belong
- an assignment directly associated to the user or inherited from a team

Finally, if the user has no access for the given action on the basis of object's lifecycle, then he may have some delegations assigned by one or more delegator users to perform the action on the specified object. In this case, the system execute (recursively) the same checks for the delegators and if one of them results enabled, the action privilege is transferred also to the user that we are taking into consideration.



Action Description
create Create a new (original/revised/cloned) object instance. When you add a new object you can set the initial stage; if this stage allows the creation access, the object can be created in this stage. Usually only the first stage in a lifecycle is enabled for the creation and only for a specific team or assignment (when objects are created, the holder is the one performing the function). You can create the object only if the class is not abstract and not hidden.
clone Create a clone of a selected object instance; the action is allowed only if the user has the clone access for the reference object (in the current stage) and the create access to add the new instance. The new object will be of the same object class.
revise Create a revision of a selected object instance; the action is allowed only if the user has the revise access for the reference object and it is revisionable (in the current stage), and he has the create access to add the new instance. The new object will be of the same object class and will inherit the same name.
read Allows a user to view the properties of an object, including field values, the history, etc. If a user has not the read access he can only see the basic properties (class, name, revision, holder, currentstage, lifecycle, locker) while the other will be hidden by a '#####' string.
edit Edit the description and the field values of an object
execute Execute a method (or program) defined for the object's class
changespace Move the object from a space to another
changeclass Change the class for the object instance. The operation is allowed if the new class is not abstract and not hidden and the lifecycle supports it. Values for fields that are not in common between the old and the new class will be lost.
changename Change the object name (and revision). You cannot change revision without revise the object or change also the object name.
changeholder Change the object holder or update the alternative holder list.
changelifecycle Change the object's lifecycle (and stage). You can change the object stage by performing a progress or a regress action, or changing also the object lifecycle.
addlinkfrom Allow the object to be the "from" side of a link with another object [out-link].
To edit the link field values, you need the same access rights for the link creation
addlinkto Allow the object to be the "to" side of a link with another object [in-link].
To edit the link field values, you need the same access rights for the link creation
removelinkfrom Remove a link from the current object to another [out-link]
removelinkto

Remove a link from another object [in-link]

fileput Attach files to an object instance, lock and unlock single files. The operation is allowed if the object is not locked by another user.
fileget Allows the user to extract an attached file from an object instance and save it to a local folder or open it with an editor
filerename For an object's attached file, permit to change the filetype or the name or move to another filespace. The operation is allowed if the object is not locked by another user.
filedelete Delete an object's attached file. The operation is allowed if the object is not locked by another user.
lock Disable other users to edit the object, change the current stage or to work with its attached files. The operation is allowed if the object is not already locked by another user.
unlock Release a lock placed on an object by another user and remove all file locks. Users may release locks they themselves have placed on objects without this access. This operation should be reserved to some supervisor user.
progress Change the object lifecycle-stage to be that of the next stage. The operation is allowed if the object is not locked by another user.
regress Change the object lifecycle-stage to be that of the previous stage. The operation is allowed if the object is not locked by another user.
delegate Grant the access privileges the user has for an object instance to another user.
revoke Revoke the access privileges that have been granted for an object instance.
undo Restore back the previous values of object fields
destroy Remove an object from the database. The operation is allowed if the object is not locked by another user.

As said before you can also establish which actions performed on the governed object in a given stage are logged into the object history. If you set in the "History Trace" tab a specific flag, everytime a user performs the relative action a new record containing the action description, the event time and the user name, will be added in the history. The are two level of history settings: at the lifecycle level and at the single stage level; in the first case, the selected flags are valid for all stages and you cannot override the behaviour in the stage mask (selected flags fro the lifecycle are disabled in the history trace panel for stages).

The object status evolves respecting the stage sequence described by the lifecycle.
If this sequence is linear you know every time what is the next stage respect to the current stage. However, in most cases the stage diagram may be more complex; for example you can take into account the possibility to jump to other stages out of the main sequence.
When more branches take origin from a stage, you have to select the next stage during the progress operation. In OBEROn, "validations" are a way to control the change of an object’s stage. A validation definition is necessary every time you have more than one path from a given stage: each path will have at least one validation.
Validations can be associated with user, team or assignment. When a validation is required for a path, a user must validate the object in order for the object to move on to the next stage along that path. If that user does not validate it, the object remains in the current stage until the user does validate or until someone with higher authority provides approval.

A validation is characterized by the following parameters:
- the identificative name
- the destination stage (or stagefork)
- the access privileges to define which category of users can validate, refuse or ignore it

Sometimes a change in stage is controlled by one or more users when different people are involved in deciding whether the object is ready for the next state.
In this case more than one validation can be associated with the transition of an object and when all the validations for a given path (stagefork) are satisfied [validated or ignored] the object can be promoted. If the "autoprogress" option is activated for the current stage, the transition is automatically performed as soon as the last validation for the destination stage is satisfied.
When validation is refused, promotion to the next state is prevented from taking place.
It a user demote the object status to the previous stage, the validation conditions for the current stage are all kept; you can check the "autoreset" flag on the Properties panel to enable the validation signature reset on object status regression.

An equivalent lifecycle creation OOQL command might be:

lifecycle define 'MovieLC' description 'Governs the Movie objects'

  filespace 'Posters'
revisionrule '-'
class 'Movie'
filetype 'JPG' 'PNG'
defaultfiletype 'JPG'
stage 'ComingSoon' description 'Movie will be available soon' !revisionable
    // stage definition
  stage 'Available' description 'Movie is available for rent' autoprogress !revisionable
    history addlink ,removelink ,progress ,regress
access
    holder edit ,fileput
community read ,fileget
team 'CustomerCare' clone ,progress ,regress ,addlinkto ,addlinkfrom                ,removelinkto ,removelinkfrom
    validation 'Rent' stagefork 'Rented'
    validate team 'CustomerCare'
refuse team 'CustomerCare'
    validation 'Out' stagefork 'OutOfStock'
    validate team 'Administration'
  stage 'Rented' description 'The movie is not available' autoprogress !revisionable
    // stage definition
  stage 'OutOfStock' description 'No more available' !revisionable ...... ;

 

<< define object connections  
© 2008-2015 MS Enterprise Solutions | Website Templates by IceTemplates.com
Please Read: Privacy Policy and Terms of Use