Better Object Modeling

by Gary K. Evans

Object modeling is both a skill and a discipline, that can lead to better quality software products. Modeling leads to better understanding of the problem you are trying to solve. It allows you to explore conceptual options to find the most productive approach for you and your company. It reduces project expense by minimizing rework caused by misunderstandings, or ambiguities not detected in textual specifications.

But while modeling has these and many other benefits, it can also be a deceiver: the goal of modeling is not to build just any models, the goal is to build useful models. Some people are naturally adept at object modeling. The majority of us can learn how to do it effectively given sufficient motivation, practice and time - and knowledge of common mistakes to avoid. This article discusses some of the issues you will encounter, or already have encountered, in UML object modeling. If you are not an object modeler yourself, perhaps you know people in your company who have this role. Consider sharing this article with them.

General Modeling Practices

Change is good. In his excellent book Agile Modeling, consultant Scott Ambler states that we model first to understand, then we may model for presentation. When we are in the early part of a project we are modeling to understand, and we should expect these early models to change often and significantly (see Law #1). If your early models are not changing, then your project is probably in trouble. Either the models are being created in a vacuum and not exposed to the jostling of reality, or the modeler has fallen in love with the model and does not want to admit it might be less than perfect. Models that are not changing early in a project is a very bad symptom.

Not just a pretty face. Avoid the temptation to make your early models pretty. This is an issue of expectation management. Because Change is Good, and your early models should be changing frequently, do not invest wasted time trying to make these models neat and pretty using a CASE tool. If your model is tidy, your model readers will think it is correct, and it may not be. Consider showing them a whiteboard diagram, or a digital photograph of a whiteboard diagram. They won't mistake either of these as the finished product.

CASE closed. Using a software modeling tool can slow down your project significantly when the diagrams are changing frequently. This is especially true in company cultures that mandate that specifications must always be completely up-to-date. UML modeling tools are wonderful for building diagrams for presentation to others outside the project, but they are a liability when all you want is to model to understand. Hold off on putting diagrams into CASE tools until the diagrams are stable.

UML Class Diagrams

Pain in the lower bounds. The lower bound on multiplicity is a potential disaster for your project. Does a Person work for 0..* (zero or more) Companies, or does a Person work for 1..* (one or more) Companies? The former allows for a given Person to be unemployed, even temporarily. The latter does not allow for unemployment, and in the latter situation a Person without a reference to a Company puts the model, and the system, into an error condition.

Hidden time. Time is hidden in multiplicity. If a Person is married to 0..* other Persons, does this mean "over time" or "at a point in time"? Any multiplicity could have either of these implicit time-constraints. Support your model, and your readers, by stating explicitly the time-dimension your multiplicity is assuming.

Default dangers. If you do not specify a multiplicity on a class diagram relationship, UML states this represents a default multiplicity of 1 (1 and only 1). Don't fall for this. The reason is simple: often you cannot specify a multiplicity because you do not yet know what it should be. That is, no multiplicity should literally mean "unspecified so far", and you do not want your readers to interpret all of the undecided multiplicities as 1 and only 1.

Names to avoid. Association relationships between classes should be named. Never, ever place names (aka "captions") such as "has", "uses", "is for", or "contains" on your class relationships. These are weasel-words that we use when we cannot think of the right words. Use terms from your business domain.

Behavioral Diagrams

Go numberless. Sequence diagrams support numbering of the messages sent between objects. Don't number messages on a whiteboard sequence diagram. These numbers become inaccurate and blatantly misleading as you add new messages between existing messages. When the model stablizes and you want to publish it, use a CASE tool and it will correctly number the messages for you.

Be explicit. Sequence diagrams support two basic styles of messages: with, and without explicit returns. If you are a beginner, or if your reader is not familiar with the message concepts of a sequence diagram, show explicit returns for every message. Yes, you will have twice as many lines on your sequence diagram than if you did not show these returns, but your reader will actually understand your diagram. That's a profitable trade-off.

Seek simple states. Unless your project requires hard-real time modeling, you should keep your state machine diagrams simple and concise. Avoid more than one level of nested substates. Beyond this your readers will be lost, and you may not understand your own state machine a week later.

    Gary K. Evans

New BABOK Released

Business Analysts and Business System Analysts have a new resource available from the International Institute of Business Anaysis (IIBA). Release 2.0 of the Business Analysis Body of Knowledge (BABOK 2.0) is now in pre-release.

According to the IIBA website: "Version 2.0 will be released on March 31, 2009. It will be available in electronic form at no additional charge to IIBAŽ members and for a fee to non-members. IIBAŽ is currently investigating options for making version 2 available in print."

The current official version of the BABOK is version 1.6 was released in June, 2006, and is available free of charge from the IIBA website.

Release 1.6 was a first-attempt at defining the skills, goals and practices of successful business analysis. Version 2.0 is a remarkable rewrite, with extensive diagrams throughout and a comprehensive BA Glossary. Evanetics is currently updating all BA/BSA-related courseware to comply with BABOK version 2.0.