- page 17

Chapter 2 - A Tour of Visio

byAndrew Filevet al. ?

Wrox Press 2002


	Team FLY

Summary

In this chapter, we have had a quick orientation of the Visio environment, and seen some of the software diagrams that it provides - Visio has many, many other diagrams, but we'll only be focusing on a subset of those here, and in subsequent chapters.

We began the chapter with a simple Visio diagram, looking at setting page properties, shapes, and connectors. We saw that shapes are organized into containers called stencils, and that shapes possess an intelligence, which we shall see more of whenever we work with Visio. It is this intelligence that gives Visio its power as a diagramming tool.

We then moved on to look at some of the common software diagrams to get a better idea of what Visio can offer the developer, and also to provide an opportunity to become more comfortable with environment. We didn't, however, look at the UML model diagrams - we will begin our exploration of these diagrams in the next chapter.


	Team FLY

Chapter 3 - Diagramming Business Objects

byAndrew Filevet al. ?

Wrox Press 2002


	Team FLY

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


	Team FLY

Chapter 3 - Diagramming Business Objects

byAndrew Filevet al. ?

Wrox Press 2002


	Team FLY

What is a Business Object?

A business object is an object usually representing a real-world person, place, or thing. Business objects allow you to represent both the attributes and behavior of these entities. For example, if you are creating a point-of-sale invoicing application, you may have business objects representing real-world entities such as a customer, an invoice, a payment, an inventory item, and so on. Business objects allow you to create a one-to-one correspondence between real-world entities and objects in your computer system.

Object Modeling Compared to Data Modeling

If you're familiar with data modeling, this concept of modeling entities shouldn't be too foreign. As shown in the following image, when you model data, you often create data tables representing attributes of real-world entities. Using the point-of-sale invoicing application as an example, you may have customer, invoice, payment, and inventory tables that represent real-world entities.

click to expand

During data modeling, you design tables with fields that represent the properties or attributes of real-world entities. For example, a customer table may have fields for a customer's name , mailing address, e-mail address, phone number, and so on. An inventory table represents the properties of a real-world inventory by means of description, quantity-on-hand, price, and other fields.

However, modeling the attributes of a real-world entity is only half the story. Entities also have behavior that can be modeled . For example, customers can change phone numbers , buy loads of inventory and become 'preferred' customers, or not pay their bills and be put on credit hold. Inventory can be sold, ordered, back ordered, and change in price. Business objects allow you to encapsulate both the attributes and behavior of real-world entities.

Modeling Attributes and Behavior

Business objects model the attributes of real-world entities because they encapsulate an entity's data. As shown in the following image, all data manipulation in your application should take place via business objects. This image shows a user interface, possibly a Windows Forms client accessing application data using business objects. The Customer Business Object accesses the Customer data, the Inventory Business Object manipulates the Inventory data, and the Payment Business Object manipulates the Payment data.

click to expand

You can add data manipulation methods to your business object classes. For example, a Customer business object might have a method called GetCustomerByPk that accepts a customer primary key value and returns a DataSet containing the specified customer. An Inventory object might have a method called GetInventoryByPartNumber that accepts a part number and returns a DataSet containing the specified part. You can also add methods to your business objects that manipulate and save data to the back-end database.

Business objects model the behavior of real-world entities because you can add methods to them representing real-world actions. For example, you can create a PutOnCreditHold method for a Customer business object that performs a series of actions to put a customer on hold. When you want to place a customer on credit hold, you simply call this method. You can add a ChangePrice method to an Inventory object that you call (passing a part number and the new price) whenever an inventory item's price changes. Later in this chapter, we'll be taking a closer look at how to decide which methods should be added to a business object.

Building Monolithic Applications

As mentioned earlier, the alternative to using business objects is creating monolithic applications. Many software applications are still created this way today. Sometimes the reason that they are created this way is that developers believe it's easier - and on some levels, it is! In other cases, upper management may not be willing to make an investment in analysis and design. Regardless of the reason, monolithic applications are extremely inflexible . Whenever change comes along, and it always does, you have to spend countless hours tearing out code (and your hair!) to implement new technology.

Building Component-Based Applications

There are many benefits from building component-based applications with business objects, which we'll cover in the next section. As you realize these benefits over time, you will begin to understand why we can say with confidence that you will never go back again to building monolithic applications.