6.7 Modelling with objects

Object-oriented software development is very much focused on representing the world of the problem domain as a set of interacting objects. If the classes of the objects are chosen to correspond to natural categories of things in the world, such as customer invoice, payment, bill, there will be a structural similarity between the world and the software. This can lead to good traceability from requirements through to code.

Domain, analysis and design are the three modelling perspectives that will guide us from a real-world situation to a final software product to address the real-world situation or part of it.

In domain modelling we represent the main concepts of the real-world problem. In terms of object-oriented development, domain modelling corresponds to identifying the important objects in the situation and building models in terms of these objects and their interactions. Its purpose is to get a better understanding of the domain; this can be done as part of the elicitation of requirements or even when the requirements have been gathered but it is important from a developer's point of view to understand the business situation that those requirements address.

In analysis (we use this term for the specification modelling activities), we assume that software system is needed to address a situation. Here we model software elements used in a software solution to the problem but avoid too many implementation details. Object-oriented analysis models are built in terms of the software representation of the real-world objects. The main emphasis is on the services provided by the software solution and not on how these services are provided.

Design modelling describes the software system, the allocation of responsibilities, and the internal sequencing and control flow. In object terms, a design model represents the software classes and objects and the messages exchanged between them and in which order. The functionality of the entire system is distributed among the classes. For instance, in a hotel system, a decision must be taken on whether the code that does the check-in of a guest into the hotel and allocates a room should be part of the Hotel class or the Person class, or whether a special class called CheckerIn is needed. Depending on the decisions made, the end product will be flexible comprehensible software that is easy to change or a rigid mess which is as intractable as the worst of coded designs. Object technology (that is, software that is built following an object-oriented approach) is an enabler of good software structures, but does not of itself guarantee them.

In software development it is difficult to say where analysis stops and design starts. In object-oriented development this is particularly true, as the techniques used are virtually the same and, therefore, the transition from analysis to design is less pronounced. Although we do not want to impose a strict division between analysis and design, we will be using these terms with the following meanings:

• Analysis is concerned with identifying the objects in the problem domain, their relationships and behaviour, and specifying their software representation only in terms of what a software system will have to achieve (and not how it will achieve it).

• Design is concerned with design modelling; that is, the responsibilities of each class, the services the classes provide and their object collaborations to achieve the desired behaviour.