DCML Diagrams

Phase 1: Data Entry

Figure 7.2: Data Entry Phase of the GC179 lifecycle

Figure 7.2 summarizes the data-entry phase of handling GC179 requests in DCML and Figure 7.3 presents it in full with all the states fully defined. There are only three constraints during this phase and they are as follows:

1. Initialization: A GC179 artifact can be instantiated in either the SELF FILLED or FILLED BY DESIGNATE states.

2. Cross Checking: When leaving the FILLED BY DESIGNATE state, an artifact must either enter the CROSS CHECKED state or the CHANGES REQUIRED state.

Figure 7.3: Data Entry Phase of the GC179 lifecycle - Complete DCML Canvas. The attributes and their required values that differentiate one state from the others are high- lighted in bold font

3. Amending GC179 requests: A request in the CHANGES REQUIRED state, when leaving this state, can only go to the SELF FILLED, FILLED BY DESIGNATE or the REJECTED states.

There are some important observations that need to be pointed out. Foremost, under the designed constraint system a value of zero is assumed to be unassigned. For example, when the artifact is instantiated (either in the SELF FILLED or FILLED BY DESIG- NATE states), the Section 34 Authority for it is required to be zero. The value of zero is used to imply that the Section 34 approval has not yet been given. When this value becomes positive in the lifecycle of the artifact, then the assigned value will be interpreted as the employee identifier of the Section 34 Authority that approved the request. Note that a similar interpretation is given to the EMP ID attribute (representing the employee identifier of the person named on the request). In either of the instantiation states, this attribute must be positive, which is then interpreted to imply that an employee ID has been assigned or must be associated with every GC179 request at instantiation time.

Both the instantiation states (FILLED BY DESIGNATE and SELF FILLED) require that upon reaching either of them the attributes GC179 ID, EMP ID and FILLED BY EMP ID become invariants. Therefore, during the lifecycle of an individual GC179 artifact, these variables will retain the values they are assigned during instantiation.

Also note that the state conditions are defined to ensure that an artifact that is in the SELF FILLED state is also in the CROSS CHECKED state. This is because self- filled GC179 requests do not require an explicit cross checking and thus are ready to move on to the next phase of processing. However, an artifact that is in the FILLED BY DESIGNATE state must explicitly transition to the CROSS CHECKED (via a change

in the CROSS CHECKED attribute). Similarly, the state CHANGES REQUIRED is

distinguished by the boolean attribute CHANGES REQUIRED, and all artifacts exiting this state must have this flag unset before progressing further. Constraint 3 ensures this and accomplishes the business objectives requiring that a GC179 request that has been “sent back” to the employee for amendments must be examined by the employee or designate (to be corrected in some way) before being put back in the processing pipeline.

Phase 2: Managerial Approvals

This phase of the process involves managerial review of the GC179 request, and the only two revelent states in this phase are APPROVED BY SUPERVISOR and APPROVED BY SECT34 AUTHORITY. As before, Figure 7.4 presents a DCML canvas that summarizes the constraints in this phase, and Figure 7.5 fully defines the states.

Note that during this Phase of processing, there are several ways in which the artifact can be “pushed back” in its lifecycle to Phase 1. For example, the request may be deemed to be incomplete or inadequate by the supervisor, by the Section 34 Authority, or by the HR coordinator. In each of these cases, the artifact is moved to the CHANGES REQUIRED state which, the way we have segregated states, is not explicitly part of Phase 2. Consequently, we include some states from Phase 1 to depict fully constraints that take the artifact to the prior phase of processing. A brief summary of the constraints presented in Figures 7.4 and 7.5 is as follows:

Figure 7.4: Managerial Approvals Phase of the GC179 lifecycle. Two states that were not previously fully defined are introduced and their interaction with prior states is summarized

1. Supervisor Approval: A GC179 request can only arrive in the APPROVED BY

Figure 7.5: Managerial Approvals Phase of the GC179 lifecycle - Complete DCML Canvas serve from the function defining the APPROVED BY SUPERVISOR state that AP- PROVAL SUPERVISOR EMP ID must be set to a positive value. In addition, there are constraints on who can modify the artifact (i.e., who can provide the supervisor approval) that ensure that the supervisor is different from the employee named on the request. Finally, to ensure that a supervisor only provides approval and does not materially modify the request, all other variables are guarded (sub-container labelled G) in the APPROVED BY SUPERVISOR state.

2. Leaving the APPROVED BY SUPERVISOR state: Constraint (2) in Figures 7.4 and 7.5 ensures that an artifact leaving the APPROVED BY SUPERVISOR state

must only be able to go to one or more of REJECTED, CHANGES REQUIRED or APPROVED BY SEC34 AUTHORITY states. But since each of these states is non-intersecting, i.e., the functions associated with any two of these states cannot be satisfied at the same time, an artifact can only be in one of them when it leaves the APPROVED BY SUPERVISOR state. Thus, combined with the guard conditions in constraint (1), this further restricts which attributes modifications must take place in order for an artifact to exit towards a particular state.

3. Entering the APPROVED BY SEC34 AUTHORITY state: Constraint (3) is an entry restriction similar to constraint (1). Note that while constraint (2) implied that when leaving the APPROVED BY SUPERVISOR state an artifact may go to the APPROVED BY SEC34 AUTHORITY state, constraint (3) requires that if an artifact enters the APPROVED BY SEC34 AUTHORITY state it must have been previously been in the APPROVED BY SUPERVISOR state. The net result of constrants (2) and (3) is somewhat similar to the micro-example presented in Section 3.5 on page 65. Once again the key differentiator of the exit state (APPROVED BY SEC34 AUTHORITY) is that the SEC34 AUTHORITY EMP ID must be positive (i.e., assigned) implying approval by the employee responsible for financial oversight in the department. To ensure that the Section 34 Authority only provides the specific approval and does not materially modify the request, all other variables are guarded in the APPROVED BY SEC34 AUTHORITY state.

Phase 3: HR and Back-office Processing

The final phase of handling GC179 requests and the associated constraints are depicted in Figures 7.6 and 7.7. Recall from Section 7.2 that GC179 requests that have received Section 34 approval must go through one final review and approval by an HR coordinator responsible for handling the payroll and vacation records for employees. The calculation determining overtime salary or the equivalent in vacation hours is performed as part of this review. Once completed the request can no longer be rejected and must proceed to payment or accrual of vacation hours.

Figure 7.6: HR and back-office processing phase of the GC179 lifecycle.

received Section 34 approval. More specifically, such artifacts can either be permanently rejected, sent back to the employee for amendments, or move forward in processing to- wards payment or vacation hours being accrued for the employee. Constraints (2) and (3) ensure that if a calculation for vacation hours or cash payment respectively has been completed, then the artifact must have previously been in the APPROVED BY SEC34 AUTHORITY state. Since the states VACATION HOURS CALCULATED and CASH PAY CALCULATED are by definition mutually exclusive an artifact can only progress in one of the directions based on the value of the PAYOUT REQUESTED flag.

Constraints (4-5) together have the net effect of ensuring that an artifact waiting for comptroller review in the VACATION HOURS CALCULATED state can only move to the HOURS ACCRUED state and an artifact moving into the HOURS ACCRUED state must have previously been in the VACATION HOURS CALCULATED state. This does not preclude the calculation of hours accrued to be corrected or repeated, since the artifact will remain in the VACATION HOURS CALCULATED states if this happens. For example, if the comptroller discovers an error, the HR coordinator can still correct the relevant field of the artifact (HOURS ACCRUED) to a different non-negative value while ensuring that the artifact remains in the VACATION HOURS CALCULATED. However, both

Figure 7.7: HR and back-office processing phase of the GC179 lifecycle - Complete DCML Canvas.

these constraints are necessary to ensure that the path between these two states is strictly followed and the object does not “escape” by going off diagram. Similarly, constraints (6-7) and (8-9) accomplish the same objective of ensuring that an object only transitions between the two states linked by these constraints.

Observe that there is extensive use of guards and invariant conditions in the four major states of interest in this phase. The purpose of guarding a significant number of variables is to ensure that the HR coordinator does not modify critical information that s/he is not authorized to change. Because requests that have passed the last stage of review can not be sent back for amendments, a significant number of attributes are made invariants as soon as the calculation for pay or vacation hours is completed. The key variables that are made immutable pertain to the earlier phases of processing and include those used to determine whether the request needs changes (CROSS CHECKED and CHANGES REQUIRED), the approval supervisors identifiers (APPROVAL SUPERVISOR EMP ID and SEC34 AUTHORITY EMP ID), and the method of remuneration requested by employee. Sim- ilarly, once the comptroller review is completed (in the states HOURS ACCRUED and DATA EXPORTED TO RPS), additional variables pertaining to processing are made in- variants. Finally, in the case a cash payment is requested, the last variable to be modified is PMT ID, which is returned by the payroll system external to the department.