Guidelines:  Business Object Model

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
• How to name business workers and business entities
• Business objects in relation to business use cases
• The business object model and information systems
• Information systems as business actors
• Information systems explicitly in the business object model
• Characteristics of a good business object model

Explanation

A business object model defines the business use cases from the business workers’ internal viewpoint. The model defines how 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, both statically and dynamically, to produce the expected results. It has an emphasis on roles performed in the business area, and their active responsibilities. Together, the objects of the model’s classes should be capable of performing all business use cases. 

The key elements of the business object model are:

• Business workers show the set of responsibilities a person may carry. 
• Business entities represent deliverables, resources, and events that are used or produced.  
• Business use-case realizations show how collaborating business workers and business entities perform a workflow. The business use-case realizations are documented with::

• Class diagrams that show participating business workers and business entities.
• Activity diagrams where swimlanes show responsibilities of business workers and object flows show how business entities are used in the workflow. 
• Sequence diagrams that depict the details of the interaction among business workers, business actors, and how business entities are accessed, during the performance of a business use case. 

The business object model brings the notions of structure and behavior together. 

• It is a bridging artifact that articulates business concerns in a way that’s similar to how software developers think, while still retaining a purely business content. It is a consolidation of what we know about the area of business concern expressed in terms of objects, attributes, and responsibilities. 
• It explores the essence of business area knowledge in a way that provides a transition from thinking about business issues to thinking about software applications. 
• It is a way of firming up requirements to be enabled or supported by information system that will be built. 
• The process of agreeing to business object definitions, relationships between objects, and the names for the objects and relationships between objects, permits business area knowledge to be represented in a precise manner that can be understood and validated by business area experts.

How to Name Business Workers and Business Entities

Give each Business Worker and Entity a name that expresses the responsibilities of its objects. 

• A good name is usually a noun, or the noun form of a verb.
• Each name must be unique.
• Avoid names that sound alike or are spelled alike, as well as synonyms.
• Clear, self-explanatory names may require several words.

Business Objects in Relation to Business Use Cases

As you study the business workers and business entities that participate in your business’ different use cases, you may find several that are so similar 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. This results 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, therefore, have quite different demands on one and the same class. In the case of business workers, if you have employees capable of acting in the described set of roles, you will also have flexible employees who can work in several positions. This gives you a more flexible business.

The Business Object Model and Information Systems

In the business object model, business workers represent the roles that the employees will act whereas business entities represent those things the employees will handle. Using a business object model, you define how the employees of the business need to 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. Therefore, 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 business 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 some potential information-system support.

These two modeling contexts have the following relationships:

• An employee acting as a certain business 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 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 support one operation of the business worker instead.
• 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.
• Therefore, a system use case accesses and manipulates entity classes in the design model that represent the business entities accessed by the supported business use case.
• 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. 

See the section on Automated Business Workers in Guidelines: Going from Business Models to Systems. 

Information Systems as Business Actors

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

Example:

A software developer tries to understand a problem in the product for which he is responsible. 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. In this way, the business worker "Software Developer" interacts with the business actor "Supplier WWW Server".

Information Systems Explicitly in the Business Object Model

The general rule is that information systems should not be explicitly modeled in the business object model; they are merely tools in the hands of the business workers. We present one exception to this rule, which concerns information systems for businesses that are directly used by its customers. If this interaction forms a major part of the business services, it might be so commercially important that you may want to show it in the business object 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 the business worker, as well as a list of services that represents the information system in the business object model.
• 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 <business worker name>" or "<business worker name> (IT system)". You may even define a stereotype with a particular icon.

Characteristics of a Good Business Object Model

The business object model gives a good, comprehensive picture of the organization.

Copyright  © 1987 - 2001 Rational Software Corporation

Rational Unified Process