Process Flow Models show the steps taken by a user to complete a task. The tasks are shown in sequential order, usually in curved rectangles and decisions with a Yes or No answer are shown in diamonds. The links between the steps are shown with lines with arrows which indicate the order in which the steps are taken.

Using flow models to explain how a user performs a set of tasks

Below is a flow model I have made for starting a car – it includes getting into the car, starting the engine, checking if it’s safe to go and then the steps taken to make a manual and an automatic car go forwards or backwards. The goal is that the car is moving at the end of the model. You can see that the start of the process of making a car move is shown by a circle at the beginning of the model (in this example on the far left of the diagram) and the end of the model is shown with a concentric circle at the far right.

The model shows all of the different decisions and the different information that the driver needs to take in order to get the end goal, for example the driver needs to know if the car uses a traditional key or a modern ‘card style’ key to start the engine. The driver needs to determine if it’s safe to go and make a decision based on the surrounding traffic at the time. The driver needs to know if the car that’s being driven uses a manual or automatic transmission and the driver needs to know if they need to go forwards or backwards.

You could make a flow model to show how a user does anything – my example above is starting a car, but you could do one about making a sandwich, making a cup of tea, going to a shops – anything that requires some kind of thought or processes (which is most things in life). In this context, flow models are useful for explaining how a user might use an app and the steps they take to get to the end goal. It also shows all of the possible pages they can visit and how they can get to each page and which decisions they may need to make in order to reach each page.

Using flow models to explain algorithms

Suppose that an algorithm is a set of instructions – the diagram above shows an algorithm for starting a car. It’s basically just a set of instructions which result in the car moving either forwards or backwards. These diagrams can be used to easily explain complex algorithms that are written in either pseudo code (a form of simplified high-level language which is closer to English than high-level language) or high-level language. For example, the diagram below is one I made to show the process flow of my entire A level Computer Science app. For my final project in Year 13 of Sixth Form I created a helpdesk app in C# for Windows 10 Universal App Platform (meaning the app runs on both Windows 10 desktop computers and Windows 10 phones) which allowed the user to specify a problem, specify a room that they were experiencing the problem in, write a description and also add attachments such as photos and videos using the device camera (if available) and then send all of this information to the IT technicians where it would be viewed as a new ticket on their helpdesk. There’s other pages too such as various help pages but the main pages are the ones that allow the user to create the ticket. The final code for this app is tens of thousands of lines long, but the diagram below simplifies this into one easy-to-read diagram when you use the key to determine what the different colours and shapes mean. If you have a little knowledge of the language that the app was written in, you can almost guess the entire code for the app – even if it’s just guessing what the pseudo code for the app might look like.

 

 

Even more basic algorithms can be explained much more easily using flow diagrams. The diagram below shows the algorithm to remove the saved sign-in address from the app using the unified modelling language.

From the diagram it is clear that the process begins on the page called ‘Help’ when the user presses the button labelled ‘Remove sign in address’. From there, if a file called ‘address.txt’ (which the sign-in address is saved in) exists, the file is deleted and a message that informs the user that the address has been removed is shown. When the user dismisses the message they are taken back to the page they were originally on. If the file ‘address.txt’ doesn’t exist, a message is displayed to inform the user that there is no address to remove and again, when the user dismisses the message they are taken back to the original page that they were on.

From the diagram, it is much easier to have an idea of what the pseudo code for this may look like.

START
PAGE help.xaml.cs
IF FILE address.txt.EXISTS == FALSE THEN:
Message "There is no address to remove.";
NAVIGATE TO help.xaml.cs;
ELSE:
DELETE FILE address.txt;
Message "The address has been removed.";
NVIGATE TO help.xaml.cs;
END

And from there, it is easier to have an idea of what the high-level language (the original C#) will look like.

A more complicated algorithm is the one to activate the camera feature, see the flow diagram below.

So here, the user starts on the ‘Create a ticket’ pivot on the main page (in Windows, a ‘pivot’ page is one that has multiple sections) and presses the camera button at the bottom of the app. If a camera is not detected a message is displayed to inform the user about this and when the user dismisses the message they are taken back on the previous page. If a camera is detected, the user must choose whether they wish to take a photo or a video. If they choose to take a photo, the Camera Capture UI opens (this is an in-built Windows 10 control for accessing the camera in apps) and the user takes a photo. The user can then choose to save the photo or they can choose to re=shoot. If they choose to save the photo, it is automatically saved with the name shown in the diagram and the user is returned to the previous page they were on. If they choose to shoot a video a similar thing happens, as shown in the diagram.

Using the diagram, we can assume that the pseudo code for this algorithm is something along the lines of:

START PAGE helpdesk.xaml.cs
IF Camera Detected == FALSE THEN:
Message "Your device does not have a camera.";
NAVIGATE TO helpdesk.xaml.cs;
ELSE:
IF Photo SELECTED == TRUE THEN:
OPEN CameraCaptureUI in PHOTO Mode;
WHEN user TAPS Take Photo BUTTON, TAKE Photograph;
OPEN CameraCaptureUI in POST-PHOTO Mode;
SAVE FILE AS;
helpdesk_photo_DDMMYY_HHMMSS.jpg;
NAVIGATE TO helpdesk.xaml.cs;
ELSE: OPEN CameraCaptureUI in VIDEO Mode;
WHEN user TAPS Record Video BUTTON, TAKE Video;
WHEN user TAPS Record Video BUTTON, FINISH Recording;
SAVE FILE AS;
helpdesk_video_DDMMYY_HHMMSS.mp4;
NAVIGATE TO helpdesk.xaml.cs;
END

These are just a few examples of how these diagrams can help to break-down complete code. Once you’ve got each algorithm displayed as a flow model, there’s no reason why you can’t do what I did and put them all together to create one diagram of the whole app or website showing all of the algorithms. This can be used to help map out a project and show how things link.