We've done some important work in the first two chapters. We've defined what we mean by business objects, we've considered the benefits of using business objects, and we've looked at some of the logical architectures that can use business objects to their best advantage. Now it's time to think about the relationship between our business objects and the real world they represent. Specifically, we're going to take a look at some of the techniques that can help us identify, in the very first instance, the actual business objects that we need to create when we're modeling business situations in the real world.
In this chapter, and through the rest of this book, we'll be creating three interrelated systems that are designed to help run a video rental store. We'll perform a detailed business object analysis of these systems within this chapter, which will provide us with a sound introduction to object analysis.
We'll be making extensive use of the use case technique in this chapter. This is a form of analysis that can be very useful for identifying and designing business objects. We'll also look at some of the common types of object relationship that can be found in real-world business systems, and we'll consider how we can design our business objects to support these relationships.
So here are the main business analysis themes in this chapter:
In this chapter, we'll be focusing on the UI-centric business objects that were located within the Component-based Scalable Architecture (CSLA) that I presented in the last chapter:
The UI-centric business objects are the objects that most closely represent the real-world entities that we're trying to model with our software. As such, UI-centric objects also happen to be the heart of any application that's built upon this particular model.
Any presentation layer will be built directly on top of these UI-centric business objects, so a key requirement is that they provide a robust, easy-to-use model of our business processes.
In this chapter, we'll look at real-world business entities and determine how to represent them as software objects. The technique we'll use to represent these business entities will be to model them, and the particular part of the business that we want to model will be our business domain. As we'll see, within this chapter, there are two major steps that we must accomplish if we are to successfully model our domain:
Another major aspect to the design comes when we decide which objects should go into different binary components, such as EXE's or DLL's. This is part of the implementation design of our objects, and we'll cover these issues in Chapter 4, where we discuss the creation of business object components.
Once we've identified our business objects and their relationships, we'll have created a logical object model, which will help us decide how we can implement those relationships using Visual Basic.
The relationships we'll be discussing are commonly used in object-oriented design, but exactly how we implement them in Visual Basic may vary from implementation methods commonly seen in other languages.