In the previous chapter, you created the first version of the process diagram, matching the basic flow that was described in the requirements.
This chapter considers the overall structure of the Tahiti application, and how the processes within the application start and stop. Helen’s description of the vacation management application that she wants is broken down into a user experience description of the visible elements application, including the usage pattern of each element (what, who, how). This is then used to define the components of the application, how they are related, and how they are started and stopped. At the end of the chapter, you will update the diagram to include more process components.
This section contains the application description broken down into a set of descriptions of the visible parts of the application, with details of the usage pattern of each one, and an extract of the requirement from Helen.
What: A summary of days available, booked, and taken, then a table showing requests. Team information for managers. Button to modify or cancel pending vacation requests. Button to cancel an approved vacation request. Button to open a form to create a new request. This is what Helen asked for:
...display the number of days I have available to book, and the number of days booked but not yet taken. This is a kind of “vacation statement,” like a bank statement but for my vacation days! From this page, I want to click a button and fill in a form to request vacation.
Who: All users.
How: Log in to the application, and this is what you see.
Who: All users
How: Select vacation request in vacation statement and click a button to see a modification form, which is added to the application page.
Who: All users.
How: Select vacation request in vacation statement and click a button. If the request is pending, it is just cancelled. If it is already approved, the cancellation request is sent to the manager for approval.
What: An automatic notification sent by email to the manager of someone who submits a vacation request, requesting review and approval. Helen was not specific about how the manager should be informed that there is a request to review:
The request is sent to my manager, who reviews it and approves or refuses it.
Who: All managers.
How: Email is sent automatically.
As a manager, when I get a request to review, I need to be able to check at a glance that the requester is using up vacation sensibly so that there isn’t a big backlog at the end of the year.
Who: All managers.
How: In the vacation statement for a manager, select a pending request and click the button to open the review form.
I need some kind of a vacation statement for the whole team, just available to the manager.
Who: All managers.
How: If you are a manager, your vacation statement includes your team vacation information as well as your own.
I need approved vacation to be added automatically to the team calendar, so that the whole team can see at a glance who is in work on any date. It would be useful if requested vacation could be in the calendar too, but marked as provisional. That way when I review a request, I can check that there are not too many people absent at the same time.
Who: All users.
How: Calendar is updated automatically when a request is submitted, approved, refused, modified, or cancelled.
I need a way to check refusals in case an employee complains that a refusal was unfair... We need some kind of tracking of refused requests with the reason for the refusal.
How: When a manager refuses a vacation request, email is sent to HR. The email notification of refusal has a defined format of subject. Configure your email system to detect this and automatically file the messages.
Now that we have described the elements of the Tahiti application from the users’ point of view, we need to create a high-level specification for each component, including how they are related. Most of the elements that users see are web pages and forms, but there are processes and other components that connect them together logically or in code, and other components that generate the information that is displayed. This is the set of components that you will create using this book, for the first implementation of the Tahiti application.
The key page in the application is the vacation statement. You have already created a prototype for this. “Update the Vacation Statement” explains how to convert this prototype into the page that will be the Tahiti application home page.
There are also the forms used in the processes. Chapter 7 explains how to create forms for the processes.
This is the landing page that a user sees after login. You created a prototype in “Create the Application Prototype”. It shows vacation requests that are pending and approved. It has buttons to start a new request, and to request modification or cancellation of a pending or approved request.
The request process contains these elements:
In the next section, you will update the diagram to show these elements, first updating the tasks and then adding the tasks where email notifications are sent.
In the final Tahiti application, there will also be processes to handle modification and cancellation of a vacation request, and a process to initialize the data used. You will add these in later chapters, after you have created the basic process for submitting and reviewing a request.
When a user submits a new vacation request, this creates a process instance. This instance continues to exist until the manager approves or refuses the vacation request and the process reaches one of the ends you defined in the diagram. Submitting a new vacation request is the process instantiation action, so it is defined at the pool level, not in a human task. The process instance does not exist until the vacation request is submitted. Update the diagram as follows:
The Review request task does not need to be changed, but you can add a text annotation here also, indicating that a form is needed. In this case, add a link from the text annotation to the human task to show they are connected. To do this, select the annotation and drag the arrow to the task.
Your diagram should now look like Figure 4-1:
You have already created the Notify HR request refused task on the no branch.
Add each missing service task as follows:
Your diagram should now look like Figure 4-2:
Chapter 12 explains how to configure a service task to send an email message.
In this chapter, you have added more items to the diagram, and used text annotations to mark the places where you need to add a form or configure a service task to send an email message.
The next chapter explains how to define who carries out the activities in the process.