Object Modelling

At its essence, object-oriented software analysis, design, and programming is all about answering two questions:

  1. What types of object do we need to define?
  2. What are the most appropriate responsibilities for each of those types of object?

When used well, object modeling can provide better initial answers to these questions because it helps the different disciplines within the team communicate and come to a common understanding about the analysis and design of a software component, application, or system. When combined with proven analysis and design patterns and strategies, it can provide initial answers faster.

If you want to do some or all of the following:

  • model at a fine level of detail,
  • generate other artefacts such as source code or interface descriptions  from the model (e.g. WSDL, IDL, etc),
  • include your diagrams in a formal document,
  • work concurrently with a distributed team,
  • create a reusable library of models,

then you will need to consider an object modelling tool like Borland's Together.

However, you do not necessarily need sophisticated and expensive design tools to benefit from object modelling. Object modeling uncovers the overall structure of the problem that our software system or component is trying to solve. Object modelling is all about about clients, analysts, designers and developers coming to a common understanding of that overall structure. In my experience, the most productive tools for building object models that do this are pads of flip chart-sized paper (A0/B0), coloured sticky notes (e.g. 3M Post-it® notes), and marker pens.

All software teams writing in programming languages like Java and the .Net family of languages have an underlying object model represented by the classes of objects they define in their program code. Therefore, it is not a question of whether to build an object model or not. Rather, it is a question of whether our underlying object model provides the best structure within which to implement the features required by our client. If the object model is not viewable in some format that is simpler than a programing language, it is very difficult to discuss and validate it with clients. The detailed and low-level nature of current, mainstream, programming languages can also make it much harder to communicate the object model to analysts and other developers.

Object modeling may sound complicated or sophisticated but is essentially just the use of pictures (diagrams) to help discover, communicate, and understand both the problem being solved and the software solution without the need to understand any particular programming language syntax.

Most people find diagrams easier to work with than blocks of formatted text, or hierarchical lists, when trying to grasp the high-level organisation of objects and the relationships between them. Below are three different ways of showing information about three types (classes) of object and how they are related.  For most people, the spatial nature of the UML model makes it the easier to see that there are 3 different things involved and two relationships between them. Those adept at reading text may find it a close call between the UML model and the source code but then we have to remember that the three snippets of source code would normally be in three different files.

public class Order {
 private List lineItems;
 private int total;
}

public class LineItem {
 private Product product;
 private int quantity;
}

public class Product {
 private int unitPrice;
}

Simple Java code
Simple UML model

Model Navigator view from Borland Together
Borland Together Model Navigator View

Problems can also occur when the shape of the underlying object model has been driven purely by functional requirements. A small change in those requirements may trigger substantial rework because the object model was not built on a broad understanding of the overall problem area. A good object model avoids the need for this level of rework because it models the problem domain rather than a particular solution. This makes it easier for developers to accommodate changes and enhancements to the software. Given the popularity of highly iterative development processes, this becomes even more important because each iteration can be viewed as a change or extension of the software built so far.

A good object model is built using concepts, names, and terms used by the client or users of the proposed system. It provides a solid framework around which clients, analysts and developers can discuss requirements objectively. More precise than natural language communication (written or verbal), a good object model helps avoid many of the costly misunderstandings and miscommunication between business and development members of a software project team. Less detailed than a programming language, a good object model can be read and evaluated by the less technical members of a project team with far less effort and training than that required to learn a programming language.

The Unified Modeling Language(UML) has become the de facto standard object modeling notation. Although not perfect, and some might argue far from perfect, it does mean that all mainstream object models are built using same basic set of symbols and diagrams. UML allows extensions to be defined and one such extension is Peter Coad's definition of color-coded class archetypes. These archetypes represent and combine together in general patterns that are found again and again in good object models. These patterns and the strategies used to combine them has become known as 'modeling in color'. Peter first wrote about modeling in color in his book, Java Modeling in Color with UML.

As with all creative areas of human industry, object modeling has best practices, techniques and patterns that make building good object models easier and faster. Over the years, as they have been discovered, people like Peter Coad, Martin Fowler and their co-authors have written about some of these in their books.