Analysis › Detailing the Business Rules › Action Diagramming Basics

Action Diagramming Basics

As a review, in our business model, entity types represent things of interest to our business. Processes represent the business activities we perform with those things. The downstream effects are that the data model forms the basis for our database design, and the elementary processes we defined become subroutines called by batch, online, client/server, or Web Procedures, that we write in the Design phase.

To eventually turn elementary processes into subroutines, we need to continue detailing them in terms of the specific business rules associated with each one. For example, a business can have a process called Take Order. One of the business rules associated with this business can be that any Customer in good standing automatically gets a five percent discount applied to their Order. Detailing the business rules for this process involve documenting, in our action diagram notation, how we determine if a customer is in good standing and applying the five percent discount to their order.

These business rules are documented in the elementary process' Process Action Diagram (PAD). When we refer to processes, we are referring to elementary processes. Only elementary processes have Process Action Diagrams, and only elementary processes are carried forward into Design.

Other types of action diagrams are the Procedure Step Action Diagrams (PrAD) and the Common Action Diagrams (CAD). The type of action diagram, process, procedure step, or common, signifies the source of the action diagram:

• Process Action Diagrams are associated with elementary processes
• Procedure Step Action Diagrams are associated with Procedures, essentially programs, that we cover in Design
• Common Action Diagrams are not associated with processes or procedures. Common Action Diagrams represent some common code that can be called by processes, procedures, or other Common Action Diagrams. Common Action Diagrams are often known as Common Action Blocks, and sometimes as Process Action Blocks, depending on if they were discovered in the Analysis or the Design phase.

All action diagrams have some common characteristics, as you can see by examining the following example:

At the top of the diagram is its name, XYZ ACTION DIAGRAM. If this were a PAD, the name would be the same as the process' name. Changing the name here would change it on the Activity Hierarchy and vice versa. If this were a PrAD, it would be the same name as the Procedure Step, and if it were a CAD, it would not be the same name with anything but itself.

At the top and bottom of the action diagram name are its place holders for Information Views. There are four types of information views:

• Import
• Export
• Local
• Entity Action

The action diagram logic manipulates the information in these views.

The import views and export views are the linkage to the action diagram. Any information, arguments passed into the diagram are passed through the import views. Any information passed out of the diagram is passed through the export views. While the import and export views can be configured to be bi-directional, as the linkage is in most programming languages, that is not the normal case in CA Gen. Separating the views in such a way helps the analyst think through the action diagram logic. Import views generally contain the information the action diagram needs to begin execution, and the export views contain the information the action diagram needs to provide to other action diagrams, screens, windows, or reports.

Local views represent information that the action diagram needs to maintain temporarily; that is, for the length of its execution. After the diagram completes execution, the information in the local, import, and export views is lost. For that reason, the import, export, and local views are collectively known as transient views.

Entity Action views represent the data in the database that the action diagram manipulates. If the action diagram reads, updates, deletes, or creates an occurrence of an entity type, it requires an entity action view. Since this view is actually manipulating the data in the database, when the program completes execution, the data remains in the database, assuming it was not being deleted. The entity action views are known as persistent views.

In most programming languages, the programmer must define the arguments in terms of length and domain, a process that is error-prone. How many times have we seen data truncated as it was passed from program to program? Worse yet, how many times have we seen programs abend due to a mismatch in arguments? With CA Gen, your data model contains the majority of your data definitions. To define an argument to contain a Golfer's name, for instance, add an entity view of a Golfer containing the Name attribute. We will see an example of this shortly. By definition, this view would be the correct length and domain. If you realized you made a mistake, updating the data model updates the argument's properties in every action diagram in which it was used.

Finally, at the bottom of the views, but within the bracket that runs down the left side of the action diagram, we would see the action diagram statements required to represent the business rules.

Action diagram statements can broadly be categorized as follows:

• Entity Actions such as Create, Read, Read Each, Update, and Delete
• Relationship Actions such as Associate, Disassociate, and Transfer
• Assignment Actions such as Set, Remove, Summarize, Move, and Exit State
• Conditional Actions such as If / Else, and Case Of
• Control Actions such as Next, Escape, and Use
• Repeating Actions such as Read Each, For Each, Repeat Until, For, and While
• Miscellaneous Actions such as Note

Although this list is not meant to be all-inclusive, it represents of many of the action diagram statements available.