Process View

Introduction

There are three separate user stories (as mentioned in the context view section). This does not necessarily force us to create three process diagrams. For complex processing, there may be more process diagrams than user stories. In some cases, a user story may be too simple to require a carefully designed diagram.

For our application, it seems as though there are at least three unique processes of interest, specifically these:

• Upload the initial set of Samples that comprise some TrainingData.
• Run a test of the classifier with a given k value.
• Make a classification request with a new Sample object.

Activity diagram

We’ll sketch activity diagrams for these use cases. An activity diagram summarizes a number of state changes. The processing begins with a start node and proceeds until an end node is reached. In transaction-based applications, like web services, it’s common to omit showing the overall web server engine. This saves us from describing common features of HTTP, including standard headers, cookies, and security concerns. Instead, we generally focus on the unique processing that’s performed to create a response for each distinct kind of request.

What’s more important is making sure that the logical view is updated as ideas arise while working on the processing view. It’s difficult to get either view done completely in isolation. It’s far more important to make incremental changes in each view as new solution ideas arise. In some cases, additional user input is required, and this too will lead to the evolution of these views. We can sketch a diagram to show how the system responds when the Botanist provides the initial data. Here’s the first example: