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.
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
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:
- What types of object do we need to define?
- 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,
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...
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.







Comments
Write New Comment ▼
Write New Comment
Sorry! This knol's owner(s) have blocked you from editing, making suggestions, or commenting here.