Analysis › Develop the Process Model › Elementary Processes › eGolf Services Elementary Processes

eGolf Services Elementary Processes

Are the processes we have identified so far for the eGolf Services business elementary?

To determine whether each process is an elementary process, we would have to examine each one with an eye towards the following guidelines:

• Does it perform meaningful work? Does it create, update, or delete entities of some entity types?
• Does it leave the business in a consistent state? At a minimum, it must not violate the optionality attribute and relationship rules as depicted in our data model.
• From the time it begins execution, to the time it finishes, does it generally happen at a single point in time?
• From the time it begins execution, to the time if finishes, does it generally happen at a single location?
• Can it be broken down further while still meeting all the previous guidelines?

Let's s examine the processes we already defined in our eGolf Services model:

Register Golfer

Creates an occurrence of Golfer, and assuming it sets all of the mandatory attributes of Golfer, leaves the business in a consistent state. The entire thing happens at one location and time, and cannot be further broken down without violating one of the previous guidelines. Therefore, it is probably an elementary process.

Login Golfer

This process does not create, update, or delete anything. It only performs a read to see if a Golfer is registered. Therefore, someone can argue it does not do meaningful work and therefore is not even a process. Another argument is that Login Golfer is a security function, and therefore should be dealt with in Design. However, this would be an exception to the rules. Processes that only do reads but are so intrinsic to the business, as security is in a Web application, can be considered processes. In this case, it can be considered elementary since it would meet the remaining guidelines as well.

Enter Scoring Record and Calculate Golfer Handicap Index

One can argue that these should be one process instead of two. After all, the interview says when they enter their scores we will recalculate their handicap index. However, the question is not "Should these be one"-, but rather-, "Can there be two". Can each be executed independently at different points in time and at different locations,- can each perform meaningful work, and can each leave the business in a consistent state? It can be argued that they can. In fact, we cannot even calculate a valid handicap index until a golfer has entered at least five scores. Do we want to make the golfers wait until they have at least five scores to enter? On the contrary, we want them to visit our Website early and often to run up our hit count. Each can be executed independently and meet the remaining guidelines assuming that when we created a Scoring Record we associated it to the Golfer which maintains it. Therefore, each would be an elementary process.

Delete Golfer

Deletes an occurrence of Golfer. Assuming it deleted all of the related occurrences of Scoring Record, then it would be considered an elementary process as well.

Each of these processes should be marked as elementary processes. When marked, each would then show the dashed line across them and each will then have a process action diagram associated with them.