Lesson 8 - Flowcharts
In the last lesson, UML - Activity Diagram, we introduced the Activity diagram. We already know that we use it to represent processes graphically. We also mentioned flowcharts that were used before UML. Because you'll certainly see them somewhere, and unfortunately because they are still being taught in some schools, we'll do a little detour from the UML standard today. As always on ICT.social, we'll also show the usage on a practical example from a real-world application.
Most flowcharts use only a simplified set of symbols with a single type of relationship, a solid line with an arrow.
The basic symbols are as follows:
Diagrams should begin and ideally end with the terminator symbol. However, this rule is not as strict as it was in the UML Activity diagram. The terminator is usually drawn as a rectangle with distinctly round corners. In some diagrams, however, you may also encounter an ellipse or circle. The terminator where the process flow starts usually contains the "Start" text and the one where the process ends the "End" text. Some diagrams have multiple end points and some none. You can encounter diagrams where the last process is round and works as a terminator for the sake of simplicity.
We draw the individual steps of an algorithm/process as rectangles, except for a few special ones, such as the already mentioned terminator or other processes mentioned below. The process has square corners in some diagrams and rounded corners in others. However, it should be safely distinguished from a terminator which corners are rounded more.
Most programs respond to the input and output (I/O). We draw these processes as a shape of a parallelogram. We typically read data from the user and store them into variables or we print some data back to the user. Although there are other special symbols for reading and writing data from/to the user, most of diagrams use only this symbol. In the example below, the program would print the text "Hello World" to the user.
Perhaps the last symbol, needed to create valuable diagrams, is a diamond, which indicates the decision. From a programming point of view, it's a condition. Loops are also usually drawn using conditions, we return one branch from the end to the beginning of the condition, creating a loop.
We can see that there are more symbols used in flowcharts than in Activity diagrams. We can say that the UML Activity diagram is a simplified and standardized flowchart.
Additional flowchart symbols for working with data
Flowcharts offer more symbols to work with data, some may come in handy, others you'll probably never use.
We usually draw a database as a cylinder. A similar graphical notation is also used for a hard drive.
We draw internal storage, which is most likely representing RAM nowadays, as a rectangle divided unevenly into 4 parts. The symbol can be used e.g. to work with memory cache. For classic operations with variables use parallelograms from the standard symbol set.
Direct Data and Stored Data
Direct access devices are understood to be hard drives. The second symbol below indicates any process of working with stored data that can't be drawn in any other way (see other symbols).
Extract, Merge, Sorting, Collate
Flowcharts provide several symbols for data manipulation. In the picture below, we can see from the left:
- Extract - Extracting one or more parts of a data set. Sometimes it may also refer to splitting the flow into multiple processes.
- Merge - Merges some data together. Sometimes it can be used to represent a merger of several flows or even measurements. You can see that flowcharts are not standardized diagrams.
- Sort - Sorting data.
- Collate - Organizing data, typically to a standard format or cluster.
Old data storages
Since flowcharts have been used for a long time, we can introduce symbols for historical storage devices just as a small distraction. These days, you will probably never see them. From the left, there is a punched tape, paper tape, and a magnetic tape. You can also see the symbol for multiple tapes.
Other flow control symbols
Sometimes we need to use other symbols that affect the diagram's flow. These are:
On-page and off-page connectors
Using on-page connectors which we draw as circles with textual or numeric labels we can move to different places within the same page of the diagram. We usually use them where it'd be difficult to connect the symbols by a line, e.g. because they are far apart. Off-page connectors work the same way, but allow the control flow to continue on another page.
Function, method, procedure, subprogram, subroutine... However your programming language calls a predefined functionality, you can draw it using a rectangle symbol divided into 3 vertical parts.
In the diagram, we can pause the flow for a certain period of time (for example, for 1 second while controlling some machine), or we can, for example, wait for data to return. We draw a delay as a rectangle strongly rounded on the right side.
Or == It make sense to use decision symbols in some diagrams. These are logical "or" and logical "and". We draw them as a circle crossed 2 times diagonally or vertically and horizontally. For classic programs, use the decision symbol instead
Other input/output symbols
In most I/O cases, we only use parallelogram. There are, however, several other symbols that we can use for these purposes.
The symbol of the cathode tube is a display symbol. It makes sense to use it especially if you're using a display that is not the standard output of the application.
Document and Multi-Document
To create, read, or eventually print documents, we can use the document or multi-document symbols. We draw them as a rectangle with a wavy bottom.
If, for some reason, it's not enough for us to draw an input as a standard parallelogram, we can use the manual input symbol. The manual input indicates an action when the user enters data into the system. The graphical notation is a rectangle with the upper left corner cut across the whole top edge.
Let's mention several more symbols that you can see in flowcharts. There are even more, but in most cases, a basic set mentioned at the beginning of today's lesson is enough.
Annotations or footnotes are a way to add comments to a diagram. We draw annotations as "forks" and connect them with a full or dashed line to the point to which they refer.
As has been said, loops are often drawn by the decision symbol. In some diagrams, you can encounter a notation using the Preparation symbol (on the left) or the Loop limit symbol (on the right).
The Preparation symbol, a rectangle with spikes on the left and right edges, can also be used generally for all initialization or preparatory operations.
We'll demonstrate a usage of a flowchart on an example. Again, this is one of the internal diagrams from the ICT.social network development which helps us to develop the information system easier. This one describes the notification process of a learning assistant that helps our students with learning. It's the same process as we have already described using the "UML Activity diagram":. You can compare both results. During this process, the assistant finds out where the user currently is in the courses and suggests the next step. Both the process and the code are quite complicated, therefore the use of the diagram makes the development much easier.
Let's look at the diagram and then describe it.
The color differentiation of diagram elements serves only for better orientation and is not part of the UML notation. The diagram contains 3 parts:
- Absolved lessons - The assistant finds out whether the user has already completed at least one lesson on the network to determine what the user is interested in. Then it can help them with further steps in their studies.
- Dependencies - Checks if all the absolved lessons of the given user meet their dependencies (prerequisites). This means whether the user has completed all the previous courses followed by these lessons.
- Following courses - For selecting next lessons and following courses.
The program tries to find any completed lessons of the user. If it doesn't find any, it asks them to first pick up a course on the network and take the first lesson. If it found any lessons, the program is able to build a lesson tree and intelligently help with further learning.
Once the program has user's absolved lessons, it maps the courses to which these lessons belong and finds if the user has completed the previous courses. We call these previous courses dependencies. If everything is completed, the flow moves to the next part. If there is a course with an unabsolved dependency, the program checks if the course has a quiz. If not, it asks the user whether they have the knowledge of the prior unabsolved course and want to skip it. If the quiz exists, the program finds out if the user has passed it. If not, it informs the user that they're missing the prior course and should go through the quiz to test the knowledge. If the user has passed the quiz, the program looks at their result. If the result is good, it offers the user to skip the course. Otherwise, it recommends the user to complete this course.
When the flow reaches the "Following courses" part, it means everything is fine and it needs to motivate the user to continue studying. First of all, it looks at the courses the user is reading and finds if there are any unabsolved lessons in these courses. If so, it simply recommends them to continue with one of these lessons. If there are no more lessons to continue with in the user's current courses, it tries to find a general following course. If it succeeds, it recommends the user to continue with this course. If the user has all the related general courses completed, it looks for the specialized following courses. These are courses that give the user specialization to a particular technology, and they usually choose only a few of these courses for the languages their chose. If such a specialized course is found, it's recommended to the user. Otherwise, the script looks at what courses the user has not yet passed on ICT.social. If there are any courses like this, it'll offer a list of these and let them choose a new subject. Otherwise, it'll tell the user they learned everything on the network. This last case will probably never happen considering the network's size, but the decision tree should be complete.
Phew. You can see how much text the algorithm description takes. Now look at the picture. It's proven that a human brain perceives visual drawings much more effectively than text. For such a complex decision algorithm, the diagram is a necessary help of a good programmer. It's hard to debug a code that you are not sure what is going to do at the particular point.
In the next lesson, UML - Package Diagram and Deployment Diagram, we'll take a look at the Package diagram and the Deployment diagram.
No one has commented yet - be the first!