Why would any software development team want to their waste time doing 'object modeling' anymore?

Object modeling is an object-oriented analysis and design technique that became very fashionable in the 1990's. The goal of object modeling is to create a model comprising:

• a set of related object type definitions representing concepts from the 'real world' (problem domain) that are needed in the system. For example:
  
  
• a system for managing the running of training courses needs objects representing the courses that are being run, the students attending each course, the locations in which the courses are being run, the instructors giving the courses, and so on.
  
  
• software to automate the processing of loan applications needs objects representing loan application submissions, approvals, and rejections, the applicants, the approving authorities, securities, lending products, and so on.
  
  
• an online books store needs objects representing the books being sold, customers, electronic shopping carts, payments, deliveries, etc.
  
  
• descriptions of how objects of those types interact with each other to form the functions of the system. For example:
  
  
• in the training course management system, an object representing a scheduled course can compare the number of seats stored in relevant location object and the number of student objects registered for the course to see if the course is full or not.
  
  
• when processing loan applications, a loan application object can work with related security objects to calculate whether they are of sufficient value to secure the loan amount requested.
  
  
• in the online book store, the shopping cart object calculates the total of an order using pricing information kept by objects representing the book titles in the cart.
  
  
• additional mysterious stuff depending on the particular object modeling method being used. For example:

• finite state machines, use cases, etc.

presenting it all as a set of related diagrams drawn using some agreed set of symbols or notation.

During the latter part of the following decade, the term object modeling slowly fell out of favour as agile approaches like eXtreme Programming and Scrum grew in popularity, and visions like Model Driven Architecture (MDA) failed dismally to live up to their marketing.

So why would any software development team be interested in object modeling anymore? Why are model-centric approaches like Domain-Driven Design (DDD) and Feature-Driven Development (FDD) still popular?

Object-Oriented Programming Languages

For many software development teams, it is not really a question of whether or not to build an object model. If you or your developers are programming in a .Net language, Java, Objective-C, C++, Delphi, Python or Ruby, you are using an object-oriented programming language. Hopefully, you or they know this and appreciate that working with an object-oriented programming language means you are essentially answering two questions:

1. What types of object do we need to define?
   
   While the actual mechanisms used may differ and be called different names in the differnt programming languages (classes, enumerations, datatypes, and so on), we are still essentially talking about defining different types of object.
   
   
2. What are the most appropriate responsibilities for each of those types of object?
   
   Again the terminology and precise mechanics may vary according to programming language (attributes, members, operations, methods, properties, instance variables, etc.) but essentially we are still defining what questions objects of a particular type can answer for us and what services they can provide to other objects.

While it is possible to write code in a non-object-oriented way using one of these languages, if that is what you are doing, you are almost certainly doing things the hard way and making life difficult for yourself. You certainly are not using the language in the way it was designed to be used.

Assuming most teams are using these object-oriented programming languages properly, at the heart of the majority of the software written in these programming languages, must lie:

• a set of object types (both problem domain and technology-oriented) with references between them and
• code describing how objects of those types interact with each other to provide the required function of the software.

Whether you like it or not, this set of classes, references and interactions essentially form an object model. All that is really missing is the presentation of it in diagram form. Whenever anyone is thinking about what types of object the software needs and what attributes, properties, operations and methods those types of object should have, they are essentially object modeling.

Knowing that an object model is buried inside your project or product's source code means no argument can be had within the project or product team about whether or not to build one. Instead the question for the wider software development team is, not "Should we build an object model?", but "How do we know that the object model buried inside our source code is a good one?"

Object Models and Diagrams

To work out if we have a good object model at the heart of our software means asking questions:

• questions about the requirements for the software, and
• questions about the technology components, frameworks and toolkits being used.

In both cases, it becomes difficult to discuss these sorts of questions, especially with non-technical domain experts, without resorting to some sort of diagram or sset of diagrams. Source code is too detailed and too verbose to use as a vehicle for describing and discussing the object model. Even most developers find diagrams far easier to work with than pages of programming language text when trying to understand the overall organisation of object types and the relationships between them. It is similar when trying to discuss or describe the interactions between objects required for specific scenarios and requirements.

For example, the following shows three types (classes) of object, firstly as source code text and then as diagram using the industry standard UML notation.

public class Order {  private List lineItems;  private int total; } public class LineItem {  private Product product;  private int quantity; } public class Product {  private int unitPrice; }

Figure 1: Comparison of a model as source code and as a UML diagram

For most people, the spatial nature of the UML diagram makes it the easier to see that there are 3 different things involved and two links between them. While source code provides the precision neeeded to discuss designs at a fine level of detail, diagrams provide a view of a model more appropriate for 'big picture' dicussions.

Incidentally, source code and some form of diagram are not the only ways to view the structure of an object model. Most commerical object modeling tools and many of their open-source counterparts provide various views of the model as hierarchical-lists. Figures 2 and 3 shows an example from Micro Focus Together and Visual Paradigm.

Figure 2: Together Model Navigator View

Figure 3: Visual Paradigm Diagram View

Depending on the task at hand, we want to use the view or views of the model that best suit the task. Hierarchical-list views are most suitable for locating items within a large model comprising a number of diagrams. Source code is great when working with fine detail, and diagrams when considering the structure of the software at a higher level of abstraction.

Most developers in agile teams will sketch small object model diagrams on a white-board when discussing requirements with domain experts, or designs with other developers. However, in many cases the white-board is soon erased, and the team generally relies on the developers holding enough of the overall structure of the software in their heads, to get the job done. When they cannot, the developers have to retrieve that information by re-reading the relevant source code files. This can be time consuming on larger projects where some parts of the code may not be touched for months at a time.

More mature agile teams will keep sketches of the object model permanently on display in their development roooms, extending and restructuring it as new functional requirements (user stories, backlog items, features, smart use cases, etc) are coded and the existing design refactored to enable this.

When diagrams from analysing requirements and refining the design of software become important enough to a team to be kept around, it becomes almost as important to use shaoes and symbols consistently in those diagrams. It is much easier and quicker to read and follow a diagram if the reader is already very familiar with the meaning of the shapes and symbol in that diagram. In addition, it is much easier and quicker to draw a diagram if you have a mental palette of shapes and symbols with pre-defined meanings to pick from. In other words, the team should agree on the notation to use in any object model diagrams they create.  Thankfully, that choice is not a hard one.

Notation, Notation, Notation

These days, it is hard to imagine anyone without a very, very good reason drawing object model diagrams in anything other than UML, but this was not always the case. The use of diagrams to show object models is far from new. During the first half of the 1990's, numerous different ways of drawing object model diagrams were proposed, promoted and argued about:

• What kinds of diagram are needed?
• What is the best symbol to represent a class?
• What types of links should you draw between classes?
• Should corners of the rectangles in diagrams be rounded?
• Should links between symbols be dashed, solid or dotted lines?
• etc, etc

To cut a long story short, the result of all this debate was the Unified Modeling Language (UML), an industry standard for depicting object models using diagrams whose guardian is the Object Management Group (OMG). Nowadays, taught widely in universities, and used predominantly in analysis, design and programming books and manuals, UML in its current form is far from perfect but it is by far the best thing we have for the job at the moment.

Building Object Models

When source code in some object-oriented programming language exists for a peice of software, we know we already have an object model. UML diagrams for discussions about the model, can be informal with developers that know the code sketching the required UML diagrams on whiteboards, or they can be more formal using a tool that parses the source code to produce very accurate UML models.

In contrast, when building new software for which there is no source code, how do we go about producing a good object model?  One  approach is to let the developers have a crack at writing the code for the new component or system. Then we are in a position to extract the object model out of the source code into diagrams so that it we can discuss whether or not it is the best model for the job. Unfortunately, as silly as that sounds, it is not so far from what some so-called agile teams effectively do.

It would seem infinitely wiser to build the object model in diagram form while discussing and clarifying requirements for the software, and then produce the more-detailed source code version from that once the model is complete. After all, given the difference in levels of detail, it should be far quicker to draw out the model in diagrams than type it up as source code. Strange as it may seem, many agile development teams dislike this idea, and unfortunately, they have good cause to.

Omneiscient Model Building

Formal object modeling activities at the end of the last century wasted enormous amounts of time and resources. These object modeling efforts typically took the form of large upfront analysis and design activities that produced beautifully-diagrammed, highly detailed models described in nicely formatted sets of documents or held within expensive, unweildy modeling tools.

However, neither beautiful formatting nor expensive tooling make up for poor content. The models produced by these efforts were often incomplete, inconsistent, incorrect and, because the modeling effort nearly always overran its schedule very badly, still changing. Even when the models produced were relatively good, they were produced by analysts and designers working in isolation and then thrown over a wall to developers. The developers took no part in the modeling process and often had inadequate training in reading detailed UML diagrams. As a result, the model of classes, references and collaborations in the source code very rapidly diverged from that in the documents or tools. This very soon rendered the models in the documents and expensive tools worse than useless.

The term, object modeling, became strongly associated with these laborious, expensive and often unproductive upfront processes, and justifiably gained a bad reputation. As Eric Evans suggests in his book, Domain-Driven Design, the fundamental failure of these modeling efforts was due to:

1. building models in too much detail too early - to get the model correct at this level of detail required to much omneiscience on the part of the modelers. Much of the knowledge needed at this level is best discovered by working out the low-level design and implementation of individual features (user stories, backlog items). It is far too time consuming and error-prone working at this level of detail in diagrams without the sort of feedback that can be provided by compilers, automated unit tests and static code analysis tools. Models at this level of detail frequently end up incomplete and inconsistent without this sort of feedback.
   
   
2. not involving developers in the modeling building process - the set of diagrams showing an object model, no matter how well-produced, cannot compete against a solid understanding of the problem domained gained in the process of building the model. Generally, developers make better low-level design and implementation decisions, mis-interpret the model less often, and are better able to dicuss requirements and design in terms of the model if they have been involved in the building of the model. When well-facilitated, collaborative, brainstorming-style object modeling sessions involving both domain experts and developers can be enormously productive and rewarding, closing off thousands of dead-end design and coding roads before developers even consider coding down them.
   
   

So while, big upfront elitist object modeling efforts caused some development teams to drop any sort of upfront modeling or design activity that does not involve writing source code, the more effective solution is not to throw the baby out with the bath water, but instead:

• involve both domain experts and developers in the process of creating the diagrams of the model
• stop modeling when the level of detail is enough for the developers to continue, iteratively refining the model in source code
• avoid spending large amounts of time keeping the diagrams in sync with the source code by either:
• using a good UML modeling tool to keep the diagrams and source code in sync
• updating sketched diagrams at reasonable intervals
  

This has been recognised by more than one expert in this field:

• Domain-Driven Design (DDD) calls this sort of approach 'binding the model and the implementation'. The model as shown in diagrams prominantly pinned to development team meeting-room walls is intimately linked to the model of classes, references and collaborations in the source code. DDD calls the collaborative brainstorming model-building activities, knowldege crunching.
  
  
• Feature-Drive Development (FDD) , Jeff De Luca's model-centric, highly-iterative process, is characterized by an upfront process where lead developers and domain experts collaborate on the iterative building of an initial overall model.
  
  
• The authors of Streamlined Object Modeling favourably compare the process of building of an object model with domain-experts to that of writing of use cases as a means of exploring and clarifying the fundamental requirements of a piece of software.
  
  

Start with the domain blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah blah

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.

Benefits of Object Modeling

When done well, collaboratively building an initial overall object model represented in a diagrams is enormously useful:

1. The collaborative nature of the process means that the developers involved gain in-depth knowledge and insight into the domain that helps them make far better fine-detailed design decisions throughout the project. In many cases, the domain experts too come to a deeper and better organised appreciation of the domain too.
   
   
2. During the modelling sessions, the terms used to name items in the model became an unambiguous vocabularly shared by both the domain experts and the developers. This idea is so important that Domain-Driven Design calls it the ubiquitous language of the project.
   
   
3. Many modern software systems are simply too complex to 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.
   
   
4. 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.
   
   

When combined with proven analysis and design patterns and strategies, it provides initial answers faster.

UML Modeling Tools

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 Micro Focus 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 ).

All software teams writing in object-oriented programming 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.

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.

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.

Object modelling is an object-oriented analysis and design technique. It uses a graphical notation or language like the Unified Modeling Language (UML) 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.

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). While it was easy enough for these people to ignore the model-centric nature of FDD, it is much, much harder to ignore Eric Evan's Domain Driven Design book. 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, tthe key is in using them appropriately and that requires appropriate skills and experience.

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) is 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.

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. 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.

The bottom line is:

Object modelling helps us both 'build the right thing' and 'build the thing right'!