Putting it in context.
A context diagram is one of the first diagrams you will start creating when you begin looking at software design and development. It is a diagram which will help you define what the problem is that your software is going to solve. It does this by showing who your system will interact with and what data is incolved. Creating a Context diagram is not that difficult and it will encourage you to consider several aspects of what you are going to produce which are useful before diving into the more serious aspects.
A context diagram consists of a circle in the center which represents your system. Around the outside are rectangles which represent the external entities that your system has to interact with. External entities could be a person, or another business, a system etc. Joining the external entities to your system are lines with arrows labelled with what data is transferred (or flows). These Data flows (sometimes referred to as relationships) are any piece of data (or information) which moves between your system and an external entity.
Here is an example of a possible context diagram for an online store:
Data flows are shown but nothing is said about the order in which the data flows, any logic regarding when and if data flows, how the data flows (what technology is used) or how much data flows.
A context diagram is also sometimes referred to as a Level 0 Data flow diagram.
An external entity which your system receives data from may also be referred to as a source. An external entity which your system sends data to may also be referred to as a sink. An external entity may bo both a source and a sink.
A context diagram is a simple diagram but it helps you in answering several important questions:
What does my system need to produce? - It defines exactly what it is that your system is to produce. The data leaving your system and going to sinks are effectively the reason for the existence of your system.
What resources does my system need to acquire to do its thing? - The context diagram then identifies what data is required in order to produce those outputs. The data originating at sources is effectively the raw materials required in order for your system to produce the required outputs. ie. data flowing into your system.
What is part of my system and what is not? - It defines the boundary of your system. This is very important to get right and to get clearly represented. Everything inside the boundary is your system. You have control over it and responsibility for how it is managed. Everything outside the boundary you have no control over and is not your responsibility. This is referred to as the environment.
The means by which data flows between your system and the external entities is an interface. Whilst a context diagram doesn't define the interface, by identifying what data needs to flow and who it needs to flow to and from you are starting to lay the groundwork for what the interface needs to look like.
For most systems the production of specific data is the central reason for the existence of the software. The mangling of data is the main activity. For some systems, such as games, other reasons such as entertainment are the main focus. When modelling a system such as this it can be tricky to model the system effectively as actions tend to be more important than data.
Here is a possible context diagram for a chess game:
Notice that multiple related pieces of data, which would normally flow at the same time can be listed together on the one data flow. Also, although there would be two players we don't represent each player as an external entity. They both effectively send and receive the same data flows so it would be redundant.
You will also notice that it leaves a lot of questions unanswered regarding the nature of the game. Is it single player (vs a n AI) or multiplayer or both? etc. For a game, the nature of the interactions are the main focus of the system as opposed to creating and managing data. A context diagram is still a useful diagram to create in developing a game, it's just not as useful as when developing an information based system.
Creating a context diagram is easy. Creating a context diagram which is an accurate representation of your system can be hard. Expect to go through several iterations, modifying your diagram as your understanding of the problem improves. In fact, if you are needing to update the diagram, that is great as it shows you are developing a better understanding of the problem and / or the best solution required to solve it. These diagrams are created as a process to help you by encouraging you to consider the project from a variety of perspectives. As such, the main value in them is the thinking you do whilst creating and updating them as opposed to viewing them after they are finished.
You should consider these diagrams never finished but a work in progress. Don't aim for perfection. These diagrams are a tool, not a product. You want to put enough time and effort into them that they achieve their purpose but not so much that they detract from your core purpose which is developing the best system you can.
You are genearlly creating a context diagram as part of your software design and development, or to answer a question in an exam. The following steps can make the process smoother:
Step 1: Draw a circle in the center of your document and label it with a reasonable name for the system.
Step 2: Think about who your external entities are and draw these in. This can be tricky. It can be useful to first think about who your system is producing information for. Then work backwards and think about where you will get the data from in order to do this.
Step 3: Add in data flows from your system to sinks.
Step 4: Work out what data will be required in order to produce the data flows in step 3 and add these in as well.
Step 5: Discuss this diagram with the client (or other important stakeholders) and ensure that your understanding of the problem is the same as theirs.
This is generally an easier task. In doing this you are normally provided a scenario which you are to create a context diagram for. The nature of this also dictates that it is usually quite a simple scenario and hence diagram you are asked to draw out as well.
Step 1: Read the question carefully and highlight / underline key bits of information (external entities, hints at data flows). Maybe think about noting these down, just to the side as well.
Step 2: Draw a circle in the center of your answer area and label it with a reasonable name for the system (don't just write down 'system').
Step 3: Draw a rectangle for each of the external entities and label them. (to make things neater it is generally better to put sources on the left and sinks on the right)
Step 4: Add in the obvious and major data flows, then work backwards and fill in other data flows to make the major ones make sense / be doable.
Here is an example question:
A group of runners do a weekly run in a park. The number of runners partaking in the run is increasing and the organisers would like a system to help them keep track of everyones runs. Each runner will get a runner id (which will be printed as a QR code on a band the runners wear). The QR code will be scanned by a timekeeper as they complete the run. Their time taken will be stored in a database and runners can get a listing of times for all their runs from the system. The organisers can also get a report telling them how many people ran each week and other statistics. A photographer may be present and can upload pictures of the run into the system as well.
Show suggested highlighting : external entities, data flows
A common mistake is to consider the database as an external entity. It is in fact part of the system and so is not medelled within a context diagram. Storage mechanisms for the data will be looked at in Data Flow Diagrams (which follow on from Context diagrams).
In producing an accurate and correct context diagram the following rules should be observed:
Data may only flow between exernal entities and the system. Data may not flow between two external entities. Data may actually flow between two external entities in the real world but this is something which happens outside of the boundary of our system and as such, does not show up in our diagram.
External entities should be listed as singular not plural. There may be a group of people (or things) which the external entity is representing but we are modelling an individual instance of them and so it is listed as singular. eg. we may have a system which interacts with many clients but in our diagram our external entity would just be labelled as 'Client'.
Data flows can be general rather than specific. eg. we should list a data flow as payment details rather than listing all the individual elements of the payment details. This is meant to be a broad, high level document and if we tried to list all the specific data the document would most likely become way too cluttered to easily read. It would also take too much time and effort trying to get all the data accurate and complete which would distract us from the main purpose of the diagram. We will deal with more specific data in later diagrams.
It is also ok to leave minor ancilliary data flows out of the diagram (for similar reasons as stated in the previous paragraph). I would recommend you consider this only when modelling a larger, more complex system however.
Use descriptive names for everything (external entities, data flows, the system). It should be obvious what they are without needing further explanation.
Model data flows only, not actions. eg. your diagram should not have data flows such as 'menu selection'. Determining what is data and what is an action can sometimes be tricky (when modelling a game in particular).
The following context diagram makes several mistakes. Can you identify what they are?
A good context diagram sets a solid starting point for your software development. It should act as a reference point when considering other aspects of your design later on. Context diagrams are then expanded into Data Flow Diagrams which start to look at how the inputs into your system are transformed into the outputs.
A context diagram is also a document you should discuss with your client / stakeholders to help ensure you are working on exactly what it is intended you should be working on (and not a misinterpretation of it).
Education is the kindling of a flame,
not the filling of a vessel.
- Socrates
