Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Stardust/Knowledge Base/Modeling/Pattern/Maker Checker"
(New page: == Introduction<br> == The Maker-Checker principle states that important decisions are not to be made by a single person but by two people. The aim therefore is to reduce the risk of err...) |
m (STP/Stardust/KnowledgeBase/Modelling/Pattern/MakerChecker moved to Stardust/Knowledge Base/Modeling/Pattern/Maker Checker: Stardust is not STP) |
(No difference)
| |
Revision as of 03:05, 19 March 2012
Introduction
The Maker-Checker principle states that important decisions are not to be made by a single person but by two people. The aim therefore is to reduce the risk of errors or misuse. In a Stardust model, this principle in general is implemented as follows: suppose there are two sequenced manual activities, A1 and A2. Further, suppose the user userX completes the first activity A1. Thus, according to the Maker-Checker principle, userX is not allowed to complete the second activity A2.
Note: The process model discussed below is available for download from here.
Model
To illustrate the Maker-Checker pattern, the following model is implemented:
In the first manual activity of the process Input Data, the user in the role Clerk (e.g., userX) is required to input some customer data (here: first name and last name) stored in the Structured Data Customer. Within the same activity the OID of the user that completed the activity is stored in the Primitive Data of Type java.lang.Long. The corresponding OUT Data Mapping is defined on the engine level:
The corresponding access point is defined on Activity Instance method getPerformedByOID():
According to the Maker-Checker principle, the next activity Approve Data cannot be completed by the userX. This restriction is modeled as follows:
- Open the properties of the activity Approve Data
- On the left hand side, select On Assignment
- On the right hand side, click Add and right afterwards Add Event
- In the dialog window that appears, select Exclude User in Action Type dropdown list
- In Data dropdown list, select LastUserOID
- Save the settings by clicking OK.
Thus, these settings ensure that the activity Approve Data cannot be assigned to the user with the OID equal to the value of LastUserOID (i.e. the OID of the user that completed Insert Data-activity).
When (after the model is deployed) the user completes the Insert Data activity and tries to execute the Approve Data activity, following message is displayed in Process Portal:
