Business Object Model		 The business object model is an object model describing the realization of business use cases. It serves as an abstraction of how business workers and business entities need to be related and how they need to collaborate in order to perform the business.
Topics

Explanation To top of page

A business object model describes the use cases of a business from the business workers’ internal viewpoint. The model defines how the people who work in the business, and the things they handle and use—"the classes and objects of the business"—should relate to one another, statically as well as dynamically, in order to produce the expected results. Together, the objects of the model’s classes should be capable of performing all the use cases of the business. The model’s primary target group is the affected members of the business. The terms and level of detail used here are specific to this target group.

How to Name Business Workers and Business Entities To top of page

It is recommended that you give each Business Worker and Entity a name that expresses the responsibilities of its objects. Clear, self-explanatory names may require several words. Each name should be unique. You should also avoid names that sound alike or are spelled alike, as well as synonyms. A good name is usually a noun, or the noun form of a verb.

Business Objects in Relation to Business Use Cases To top of page

As you study the business workers and business entities that participate in your business’ different use cases, you may find several that seem to be so similar that they are really one class. Even when different business use cases do not have identical demands, the classes may be similar enough to be considered one and the same phenomenon. If this is the case, you should merge the similar classes into one, resulting in a business worker or business entity that has sufficient relationships, attributes and operations to meet all the demands of the different business use cases.

Several business use cases may thus have quite different demands on one and the same class. In the case of business workers, if you have employees who are capable of acting in the described set of roles, you will also have flexible employees that can work in several positions. This gives you a more flexible business.

The Business Object Model and Information Systems To top of page

In the business object model, workers represent the roles which the employees will act; and business entities represent the things the employees will handle. Using a business object model, you define how the employees of the business should interact to produce the desired results for the business actor. The system use-case model and design model, on the other hand, specify the business’ information systems.

Business modeling and system modeling address two different problem areas, at two different abstraction levels. Thus, the general rule is that the information systems should have no direct presence in the business models.

On the other hand, the employees acting as workers use information systems to communicate with each other, and with the actors, and to access information about business entities. Whenever there is a link, association or attribute, there is also potentially some information-system support.

These two modeling contexts have the following relationships:

  • An employee acting as a certain worker corresponds to a system actor of the information system. She is probably best supported if the information systems are structured so that her entire work in a business use case is supported by one information-system use case.
  • Alternatively, if the business use case is large, long-lived, or combines work from several independent areas, an information-system use case could instead support one operation of the worker.
  • The things the employees work with—modeled as business entities—often have representations in the information systems. In the object model of an information system, these business entities occur as entity classes.
  • Associations and aggregations between business entities often give rise to corresponding association and aggregations between entity classes in the design model.
  • Thus, potentially an information-system use case accesses and manipulates entity classes in the design model representing the business entities that the supported business use case accesses.
  • Finally, a business actor that directly uses a business’ information system also becomes a system actor of the information system.

These relations are essential when identifying requirements on the information systems that support the business.

Information Systems as Business Actors To top of page

Sometimes the employees of one business contact the employees of another business by using the other business’ information system. From the perspective of the modeled business, that information system is an actor.

Example:

A software developer tries to understand a problem in the product he is responsible for. To understand if the problem originates from the programming tool she is using, she contacts the supplier’s World Wide Web server and studies the list of known problems in the current release of the programming tool. Thus, the worker "Software Developer" interacts with the actor "Supplier WWW Server".

Information Systems Explicitly in the Business Object Model To top of page

The general rule is that information systems should not be modeled explicitly in the business object model; they are just tools in the hands of the workers. We present one exception to this rule, which concerns information systems for businesses that are used directly by customers. If this interaction forms a major part of the business services, it might be so important commercially that you want to show it in the business model. Telephone banking services are good examples of this type of information system.

From the business-modeling perspective, the following approach is suggested:

  • Regard the information system as a fully automated business worker that interacts with an actor.
  • If the information system relates to any of the other business workers or business entities, consider illustrating this relationship with a link or an association. Perhaps the system informs a business worker of its progress, or uses information concerning a business entity.
  • Briefly describe in the business object model the business worker, as well as a list of services that represents the information system.
  • Model all details and characteristics of the information system and its environment in an information system model.
  • Introduce a naming convention so that a fully automated business worker is easily identified among the business workers; for example a prefix or a suffix, like "automated <worker name>" or "<worker name> (IT system)". You may even define a stereotype with a particular icon.

Characteristics of a Good Business Object Model To top of page

  • Taken together, the business workers and business entities perform all the activities described in the business use cases—no more, no less.
  • The business object model gives a good, comprehensive picture of the organization.
 

Display Rational Unified Process using frames

 

© Rational Software Corporation 1998 Rational Unified Process 5.1 (build 43)