2.2 The role of the conceptual model
At the very heart of object-oriented programming is the philosophy that software objects can usefully correspond to real-world entities. This is why we create a conceptual model that ‘looks’ object-oriented: it includes modelling elements referred to as ‘classes’, which have instances referred to as ‘objects’ and so on. Having a conceptual class such as shop, for example, makes it sensible to consider having a 
class as part of the software. Thus the conceptual model will provide an initial basis for the structure, or architecture, of the software – the classes and objects that make up the system and the way in which they fit together. That is, the conceptual model gives rise to an initial structural model for the system under development. It is important to recognise that whilst on paper the conceptual model and the initial structural model may ‘look’ the same, they are not. They model different things, from different perspectives. A conceptual model is a representation of the system domain, whilst an initial structural model is a plan – an early model – of the software itself.
The initial structural model does not deal with the behaviour of the system – the way in which objects interact. Behaviour is addressed by designing dynamic models, which you will study in later units. The way in which the conceptual and initial structural models fit into a full software development process is illustrated in Figure 1.
The initial structural model is what is taken forward to the next stage of development. It will become the basis for designing the software system, and as you go along many of the conceptual classes you identify initially will crystallise into corresponding software classes (written in Java in this course). But it is important to recognise that not all the conceptual classes will necessarily have software counterparts, and also that the software is likely to include classes which had no conceptual equivalent but which are needed in order to achieve a good software design.