Review procedure documentation:
Review the documentation relating to the procedure being designed. Examine the task inputs for each procedure step.
Describe logic, conditions, iteration and data actions of the procedure.
There are several techniques for describing these actions - Procedure Action Diagrams are one of several techniques available.
¤ Draw procedure action diagram:
The starting point is the process action diagram from BAA. This defines the business logic that must be embodied in the procedure. A skeleton procedure action diagram is produced that includes the relevant process logic.
- One-to-one relationships -
The task of defining procedures identifies the relationship between the procedure and the process. For a one-to-one mapping, the process logic expressed in the process action diagram defines the business requirements for the procedure and is included in the procedure action diagram. In all other cases, examine the mapping to determine how the logic is split over the procedures. If a process action diagram is not available, the business logic is first expressed in process action format.
- Multi-process procedures - procedure action diagram
For multi-process procedures, the process actions are either implemented serially or as alternatives. In a serial implementation, the actions are inserted one after another.
» Creates deliverable D4.1.3 Procedure Action Diagram.
¤ Add dialog actions:
In a dialog, control is passed to the procedure through a dialog flow. For a procedure with a single flow in and a single flow out, the dialog control is simple. When there is more than one flow, it is more complex. The action of a procedure may be different under different incoming flows. Determine which outgoing flow is to be followed by setting an exit state within the procedure action diagram.
- Commands -
Examine details of the flow in order to control conditional actions. Examine the flows entering this procedure step and note the commands. If there is more than one command, determine whether the action of the procedure is different in each case and include the relevant conditional actions on the action diagram.
Examine all flows leaving the procedure and note the exit states. Determine the conditions under which each flow is taken and include actions in the procedure action diagram to set exit states.
» Creates deliverable D4.9.2 Dialog Actions.
¤ Add layout actions:
Although no actions are required to process the import layout, examine the contents of a layout to determine conditional actions required. Also note any algorithms required to derive values from fields.
Export layouts must be populated before the completion of the procedure. In addition, the procedure actions may:
* Set error indicators for particular fields
* Change the default display properties defined for a field on a layout
* Indicate where the cursor is positioned on the screen
ð Updates deliverable D4.1.1 Procedure Definition.
¤ Define procedure data views:
Each procedure has up to four types of data views associated with it (i.e., import, export, entity action and local views). The import and export views are defined during the "Define Dialog Procedures" and "Design Layouts" tasks. The entity action data view is constructed as data actions are defined. Local data views are constructed as local data requirements are defined. Revisions may be made to import and export data views, but the impact on layouts and dialog flows must be assessed.
¤ Include exception actions:
Review the action diagram for exception conditions. The identification of exceptions is mandatory for procedure action diagrams. Actions must be defined for all eventualities. Many actions have exception expressions within their syntax.
An action or action group must be associated with each exception to ensure that all values are handled in a logical and consistent manner. In many cases, the action block will activate some form of error or help procedure, or a set of conditional actions.
Example of actions with exception expressions:
READ entity view WHEN not found ...
CREATE entity view IF already exists ...
¤ Design reusable action blocks
In building the action diagram, identify algorithms or recurring procedure actions. These are documented in separate action diagrams, known as action blocks. Use an action block in any other procedure by invoking it with a USE statement in the procedure action diagram. An algorithm will have import and export views through which it receives the data on which it operates and returns a result. A catalog of algorithms is maintained so that they can be easily referenced and used in other procedures. The action block can be internal or external to the business system.
¤ Annotate procedure action diagram
NOTEs are added to the procedure action diagram to explain complex logic or to summarize the purpose of lengthy blocks. Annotation can also be useful to:
* Explain exception conditions and handling
* Provide a definition for an action procedure on the action diagram
* Define the expected user interaction
ð Updates deliverable D4.1.3 Procedure Action Diagram.
Previous : A4.5.3
Activity Overview : A4.5
Stage Overview : Design Stage
Overview : Table of Contents