Chapter 3 -
Diagramming Business Objects

byAndrew Filevet al.?

Wrox Press

©2002

Chapter 3: Diagramming Business Objects

Overview

The UML without business objects is like the Tour de France without bicycles. Without business objects, class diagrams, collaboration diagrams, sequence diagrams, and state chart diagrams hold little meaning. It's not until you begin designing and using business objects that you see a real need for the UML or modeling tools such as Visio or Rational XDE. However, once you begin using business objects, you'll be firing up your UML modeling tool on a daily basis to conceive, design, and understand the object model of your applications, which usually produces more flexible, extensible, and maintainable software.

Although much has been written about the benefits of business objects, many companies continue to create monolithic applications. A monolithic application is a piece of software with the user interface, business logic, and data access inextricably bound together. This is what you find in most of the .NET sample code shown in books, magazine articles, and on-line resources.

In this chapter, we are first going to learn what business objects are and why you should use them. If you are going to climb the business object learning curve, you should have compelling reasons to do so. Although business objects can be one of the more difficult concepts for developers to grasp, once you "get it" and begin using business objects in your applications, you'll never go back again.

In this chapter we will also cover:

Using Visio for object modeling

Defining data-access base classes for your .NET applications

Defining a business object base class

How to derive business classes from use cases

Working with abstract and concrete classes

Thinking about data during object modeling

Using sequence diagrams to model the flow of messages between objects