Elements of MBT - Part 1 - What is a model?

In this series of "Elements of MBT" posts, I will be covering some basic concepts used when trying to build models of software systems for use in Model Based Testing. The aim is to give an explanation of the various elements involved in defining a model of a software system and hopefully this should get us on the same page and allow us to explore the complexities in more detail.

Let us start by going over what we mean by a "model" of a system. Put simply, a model is a description of the system and is much simpler than the actual system itself. What this means is that the model hides a lot of the details about the system and hiding these details allows us to work at a higher level of abstraction. For e.g. a simple model of driving a car could be:

One thing to keep in mind is that there is no perfect model of a system, since the same system can have completely different models depending on what you plan to use the model for. Are you creating the model of a system simply to capture the behavior and requirements of the system? Are you creating the model to auto-generate the code for the model implementation itself? To describe the data flowing through the system? Or are you generating the model to actually test a particular portion of the system?

A quote which captures this unusual thing about models really well is as follows:

All models are wrong; some models are useful.

- George Box

What is worth hanging onto from this definition is that a model that you create should strive to be "useful" more than anything else. It might be rough round the edges and might not tell you everything about the system (for e.g. you don't know from the above model how the gear is to be changed or what happens when a gear is changed) but if it is useful for the purpose it was created it is a correct model.

Another aspect of defining a model is the notion that the model should help predict what the behavior of the system would be under certain conditions. So if you are in the "Not Moving" state and you "ChangeGearAndAccelerate" then you reach the "Moving" state. Are there certain assumptions in the model? You bet there are! Such as assuming that the ignition is on, that the car has wheels, that the car is not hanging in the air, that there is oxygen in the air, we can go on and on and on. The hiding of these details and assumptions is what helps us look at just this behavior we are capturing. If anything is important for the purpose (say testing) for which we are creating the model, we should consider adding that detail into the model. So if we thought that it was important to know whether the ignition was on or off we would change the model to capture this as well.

Now we know that if you are in the "Ignition Off" and "Not Moving" state then if you "TurnIgnitionOn" you reach the "Ignition On" and "Not Moving" state since simply turning on the ignition does not cause the car to start moving in the model that we have created. To start moving you will need to "ChangeGearAndAccelerate" which should take you to the state of having the "Ignition On" and the car "Moving".

Hope this gives you an idea of what a model contains and what it can be used to capture. In the following posts we will look into each element of a model in more detail.