Knol will be unavailable during scheduled maintenance starting at Mon, 09 Nov 2009 18:30:00 GMT. We expect the maintenance to be completed at Mon, 09 Nov 2009 20:00:00 GMT.
Version: Baidi441

Object Modelling

Why would I waste time doing this?

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 source code. Therefore, it is not a question of whether to build an object model or not. Rather, it is a question of whether the underlying object model provides the best framework within which to implement the features required by the client.


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

Like any modelling activity, we build object models primarily for two reasons, firstly to gain understanding and secondly to communicate. Most software systems are too complex to easily understand in their entirety at any significant level of detail. Building an object model enables us to explore and understand the overall structure and function of a system from different perspectives and at a higher levels of abstraction where we can temporarily ignore the details of specific programming languages and software operating environments.

All software teams writing in programming languages like Java and the .Net family of languages have an underlying object model represented by classes of objects they define in their program code. Therefore, for these teams, it is not a question of whether to build an object model or not. Rather, it is a question of whether the chosen object model provides the best framework within which to implement the features required by the client. Object modelling helps us 'build the thing right'.

If the object model is not visible in some format that is simpler than programming language source code, it is very difficult to discuss and validate it with clients and users. The detailed and low-level nature of current, mainstream, programming languages also makes it much harder to communicate the object model to analysts and other developers. Therefore, object modelling can help us 'build the right thing'.



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


Borland Together Model Navigator View

Object modelling is an object-oriented analysis and design technique. Object modeling uses a graphical notation or language like the Unified Modeling Language  ) to build a set of related diagrams. These show classes of object, their responsibilities, and how they relate to each other. They also show how the objects defined by these classes interact with each other to perform the required functions of the software.

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 modelling provides 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 provides initial answers faster.

Some people believe agile software development and especially extreme programming do away with the need for analysis and design techniques like object modelling and notations like the Unified Modelling Language (UML). For those who have been told that, Eric Evan's Domain Driven Design book comes as a bit of a surprise. Its endorsement by Kent Beck and Martin Fowler, two leading names in the extreme programming community, shows there is definitely a place for object modelling in an agile world. As with all tools and techniques, there is a skill in using them appropriately. 

 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 diagrams and associated model information in a formal document, 
  • work concurrently on models within a distributed team, 
  • create a reusable library of models,
 then you will need to consider an object modelling tool like Borland 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. Many times the collaboration and information sharing during the building the model is as, if not more, important and useful than the end result. In my experience, the most productive tools for building object models collaboratively are pads of flip chart-sized paper (A0/B0 size), coloured sticky notes (e.g. 3M Post-it® notes ), and decent marker pens (e.g. Sanford Sharpies ).

More on collaborative object modelling and accelerated analysis... 

Problems can 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 increasing popularity of highly iterative, agile 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 the same basic set of symbols and diagrams. UML allows extensions to be defined and one such extension is Peter Coad's definition of colour-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 Coad 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.

More and more model and domain-centric techniques are becoming fashionable again. Already we have a growing set of new model-centric acronyms with which to confuse people including: Model Driven Architecture (MDA), Model Driven Development (MDD), Model Driven Engineering (MDE), Agile Modeling (AM) and Domain Driven Design(DDD)

Then there is the next generation of model-centric tooling being built by the Eclipse community as part of the open-source Eclipse Modeling Project. Borland is being contributing heavily to this project and Borland Together is being increasingly built on top of the various frameworks delivered by the project.

Therefore, object modelling techniques look like they will continue to be useful for at least the next few years. 

Further Reading

Comments

Stephen Palmer
Stephen Palmer
Software Developer, Consultant, Author
Exmouth, Devon, UK
Article rating:
Your rating:

Activity for this knol

This week:

23pageviews

Totals:

569pageviews