Business Process Modeling with Activity Diagrams
Based on the functional requirements identified for the Internet Sales System, Alec and his team decided that there were at least four high-level activities that needed to be addressed: Place CD Orders, Maintain CD Information, Maintain CD Marketing Information, and Fill Mail Orders. As a first step toward developing a functional model of the functional requirements, Alec decided to model the overall flow of execution of the business processes as an activity diagram. Upon close review of the Place CD Orders requirements,
the team identified a decision and two additional activities: Place InStore Hold and Place Special Order. These activities were based on the requirements laid out in point 3.5 of Figure 4-15. Furthermore, the team noticed that there seemed to be three separate concurrent paths of execution implied in the requirements. The first path dealt with orders, the second addressed the maintenance of marketing information, and the third focused on maintaining the information about the CDs. Based on these new insights, Alec and his team drew the activity diagram for the Internet Sales system shown in diagram below:
Identify the Major Use Cases
The first four steps in writing use cases deal with reviewing the activity diagram, finding the subject boundaries, listing the primary actors and their goals, and identifying and writing overviews of the major use cases based on these results. These use cases will form the basis of the use cases that are contained on the use-case diagram. We should review the requirements identified in the activity diagram before we continue
To begin with, it seems that the subject boundary should be drawn in such a manner that anything that is not part of CD Selections’ Internet Sales System, such as the vendors and customers, should be identified as primary actors. Therefore, these are considered outside of the scope of the system. The other potential actors identified could be the distribution system, electronic marketing (EM) manager, and the current CD Selections stores.
it seems that the distribution system and the current CD Selections stores should be outside the scope of the Internet Sales System. As such, they also should be identified as primary actors. It also seems that the EM manager should be considered as part of the Internet Sales System and, therefore, should not be identified
as a primary actor.
We should remember that primary actors are only those that can be viewed as being outside of the scope of the system.
The decision on whether the EM manager, the current CD Selections stores, or the distribution system is inside or outside of the system is somewhat arbitrary. From a customer’s perspective, the distribution system, and the current CD Selections stores could be seen as being inside of the overall system, and it could be argued
that the EM manager is a primary user of the Internet Sales System. At this point in the process, it is important to make a decision and to move on. During the process of writing use cases, there are ample opportunities to revisit this decision to determine whether the set of use cases identified are necessary and sufficient to describe the requirements of the Internet Sales System for CD Selections. As we can see, based on
the preceding, finding the systems boundaries and listing the primary actors are heavily
Based on the functional requirements and the activity diagram, Alec and his team identified four overview major use cases: Maintain CD Information, Maintain CD Marketing Information, Place Order, and Fill Order. We might have considered adding new CDs to the database, deleting old ones, and changing information about CDs as three separate use cases.
In addition to these three, we also need to have use cases for finding CD information and printing reports about CDs. However, our goal at this point is to develop a small set of essential use cases for the Internet Sales System. The same pattern should be evident for the marketing materials.
We have the same processes for recording new marketing material for a CD, creating it, reading it, updating it, deleting it, and printing it. These activities are usually required any time that we have information to be stored in a database.
The project team at CD Selections identified these same four major use cases. At this
point in the process, the project team began writing the overview use cases for these four.
Remember that an overview use case only has five pieces of information:
- Use case name
- ID number
- Primary actor
- A brief description.
At this point in time, we have already identified the primary actors and have associated them with the four use cases. Furthermore, because we are just beginning the development process, all four use cases will be
overview and essential types. Because the ID numbers are simply used for identification purposes (i.e., they act as a key in a database), their values can be assigned in a sequential manner. This leaves us with only two pieces of information for each use case to write. The use-case name should be an action verb–noun phrase combination (e.g.,Make Appointment).
In the CD Selections Internet Sales situation, Maintain CD Information, Maintain CD Marketing Information, Place Order, and Fill Order seem to capture the essence of each of the use cases. Finally, a brief description is written to describe the purpose of the use case or the goal of the primary actor using the use case. This description can range from a sentence to a short essay. The idea is to capture the primary issues in the use case and make them explicit.
The fifth step is to carefully review the current set of use cases. Take a moment to review the use cases and make sure we understand them. Based on the descriptions of all four use cases, there seems to be an obvious missing use case: Maintain Order. Because the project team did not include language in the brief description of the Place Order use case, it seems that the project team believes that maintaining an order is sufficiently different from placing an order that it should have its own use case to describe it. Furthermore, it does not seem
reasonable that a customer would see placing an order and maintaining an order as the same use case. This type of interactive and incremental process goes on until the project team feels that they have identified the major use cases for the Internet Sales System.
The sixth step is to choose one of the major use cases to expand. To help the project team to make this choice, they identified the trigger and the stakeholders and their interests for each of the major use cases.
The first use case, Maintain CD Information, was triggered by the Distribution System distributing new information for use in the CD database. Besides the Distribution System, another stakeholder was identified: EM Manager.
The second use case,Maintain CD Marketing Information, has a similar structure. The receipt of marketing materials from vendors triggers it.Again, it seemed to the project team that the EM Manager was an interested stakeholder.
The third use case, Place Order, is more interesting. The trigger is the action of a Customer. Again, the EM Manager is an interested stakeholder. This use case has many more inputs.
The fourth use case, Fill Order, is based on the decision logic identified in the activity diagram. However, upon further reflection, the team decided to replace this use case with three separate use cases, one for each approach to filling an order: Place Special Order, Place In-Store Hold, and Fill Mail Order. The first two are controlled by actions of the Customer.
However, the Fill Mail Order use case has a temporal trigger: every hour the Internet Sales System downloads orders into the Distribution System. The final use case, Maintain Order, is triggered by the action of a Customer.However, on close review, it seems that it also has much in common with the other maintenance-related use cases: Maintain CD Information and Maintain CD Marketing Information. And like all of the other use cases, the EM Manager has an interest. Based on their review of the major use cases, the project team decided that the Place Order use case was the most interesting.
The next step, step 7, is to start filling in the details of the chosen use case. At this point in time, the project team had the information to fill in the stakeholders and interests, the trigger, and the association relationship. (Note: Remember that the association relationship is simply the communication link between the primary actor and the use case.) In this use case, the association relationship is with the Customer. The project team then needed to gather and organize the information needed to define the Place Order use case in more detail. Specifically, they needed to begin writing the normal flow of events; that is, they should perform the eighth step for writing effective use cases.
The goal at this point is to describe how the chosen use-case operates: Place Order. Alec and the team decided to visualize placing a CD order over the Web and to think about how other electronic commerce Web sites work—that is, to role-play. As they role-played the Place Order use case, they realized that after the customer connected to the Web site, he or she probably began searching—perhaps for a specific CD, perhaps for a category of music—but in any event, they entered some information for their search. The Web site then should present a list of CDs matching their request along with some basic information about the CDs (e.g., artist, title, and price).
If one of the CDs is of interest to them, they might seek more information about it, such as the list of songs, liner notes, reviews, etc.
Once they found a CD they liked, they would add it to their order and perhaps continue looking for more CDs. Once they were done—perhaps immediately—they would check out by presenting their order with information on the CDs they want and giving additional information such as mailing address, credit card, etc.