Business Objects

Business Objects

A big change in the way systems development is undertaken began in the mid- 1980s. The ideas stem back to the early days of computing, but new languages were emerging that talked about ‘objects’ rather than ‘programs and data. The pace of change in the practice of information systems development since then has been considerable, and it is the norm to see new projects written using the notion of objects.

The basic idea of objects is very simple. The world is made of objects. Just open your eyes and ears- they are out there: bank customers, students, cats, elephants, cars, balls of string, atoms, molecules, rubs of ice cream, Madonna, stars, bureau- crats, Robin Hood. The world is built of objects. Objects are built of smaller objects, and so on ad infinitum. Objects combine to make bigger objects. We live in an object-oriented world.

Object modelling consists of looking for objects and inventing objects. The first objects that are considered are representations of things in the real world, such as customers, suppliers and contracts. Of course, there has to be some boundary Even looking up from this book you can see more objects than you could reason ably list, and we shall be looking at the right way to find objects later.

Objects do things, and objects have things done to them. The ‘doing’ parts of an information about an object is held in things called attributes. Later, when we object are called operations. Objects also have information about themselves. The move on to detail. At the level of business modelling, we need only note that objects have some state, and that they can be changed by actions on them.

Objects are drawn in UML using a rectangle with the name of the object inside. We shall see later that this rectangle can have a number of compartments, but for now we shall just consider the name of the object. (Strictly, this notation is for a class, but we shall explain the distinction between a class and an object later.) Figure 8.12 shows the UML. notation for a customer object.

Object modelling is, at its simplest level, very straightforward. The trick comes in knowing what objects are appropriate – some of this comes with skill, but we shall include some guidelines. As we move on through systems analysis and design, we shall begin to devise special types of object. The skill of a designer is in knowing how best to objects and to make them cooperate.

The first stage of analysis is to look for objects in the real world, such as customers, orders, warehouses and stock. These are often known as ‘domain objects’ or ‘business objects’. These can be related to give a picture of the environ- ment in which the system is to be built. A common guideline for identification of objects is to examine documentation looking for nouns and considering the nouns as candidate objects. Once systems analysis begins the domain objects are given more detail Design will add further detail and link them to system objects such as computer screens and transaction controllers.

Objects can be related. The relationships between objects are often very impor tant Figure 8.13 shows a customer object is related to an order object, and an order object is related to an order line object. The numbering on the relationship indicates that one customer can be related to zero or more orders, and one order has one or more order lines. An order must have exactly one customer and an order line must have exactly one order. Later, we shall examine a much richer range of relationships. For the purposes of domain modelling we can stop here, though some of the richer notations might be useful occasionally.

The primary advantage of a business object model is that it gives a clear under-

standing of the relationships in the business environment. These relationships will often be reflected in some internal objects in the computer system to be built Capturing these relationships at the business analysis stage allows the analyst to build a more complete picture of the environment in which the system will reside. Figure 8.14 shows how we can place objects on activity diagrams, using a Metalwho example business process for order taking. It is sometimes useful to illustrate where objects are created and manipulated in a business process. Business processes often change the state of an object.