Analysis › Detailing the Business Rules › Action Diagramming Basics › eGolf Services Action Diagramming

eGolf Services Action Diagramming

As an example, let's look at the Login Golfer process. What are its inputs, outputs, and what work is it going to do?

If we had been good analysts and taken the time to enter a description for this process, it could read something like the following:

With a golfer's user ID and password, this process verifies that the golfer has registered to use our system, and that they are who they say they are by verifying that the password matches the one on file for them. If so, we welcome them back using their name.

Here is how the business rules discussed would look in our action diagram notation:

The information to begin executing this process, is a golfer's user ID and password.This information comes from the import view. Since this information is required for this process to begin execution, they are marked as mandatory.

Information needed because of the successful execution of this process, is the golfer's name, so that we can welcome them back by name. This information comes from the export view.

Since we do not need any temporary use of information, we do not need any local views.

We are going to access our database of golfers, to see that they exist and to check their password. The entity action view will be used for this purpose.

The action-diagramming notation appears in brackets, following the information views.

Looking at the action-diagramming notation, we see that we are going to read a golfer in our database, based on the value of import golfer user ID. There are two possible outcomes of this read, success, or there will not be a golfer in our database with a user ID matching the one given to us.

If the golfer is not found, we are going to set a special system attribute, the exit state, to a value indicating that the golfer was not found. Later in the Design phase, we will decide how we want to handle that condition. We might want to return a message, print a report, highlight some field on a screen or window, do all three, do something else entirely, or do nothing.

If the read was successful, we want to verify that the password we have on file matches the one given to us in the import view. If the passwords match, we want to move the golfer name we read from our database to the export view.

Note: There are more attributes in the entity action view than there are in the export view. On a move statement, only corresponding attributes move.

If the passwords fail to match, we set the exit state to a value indicating and invalid password. We determine the appropriate action for that condition in the Design phase.