Artifacts > Business Modeling Artifact Set > Business Object Model... > Business Object Model > Guidelines > Business Object Model
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:
The business object model brings the notions of structure and behavior together.
Give each Business Worker and Entity a name that expresses the responsibilities of its objects.
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.
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:
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.
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.
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".
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:
The business object model gives a good, comprehensive picture of the organization.
Rational Unified Process