Artifact: Business Object Model

Artifacts > Business Modeling Artifact Set > Business Object Model... > Business Object Model

Business Object Model	The business object model is an object model describing the realization of business use cases.
UML representation:	Model, stereotyped as «business object model».
Role:	Business-Process Analyst
Optionality:	Can be excluded.
Sample Reports:	Business Object Model Survey
More information:	Guidelines:Statechart Diagram in the Business Object Model Guidelines:Sequence Diagram in the Business Object Model Guidelines:Going from Business Models to Systems Guidelines:Collaboration Diagram in the Business Object Model Guidelines:Class Diagram in the Business Object Model Guidelines:Generalization in the Business Object Model Guidelines:Aggregation in the Business Object Model Guidelines:Association in the Business Object Model Guidelines:Activity Diagram in the Business Object Model Guidelines:Business Object Model Checkpoints:Business Object Model
Purpose Properties Timing Responsibility Tailoring

Input to Activities:

Develop Vision

Capture a Common Vocabulary

Find Actors and Use Cases

Detail a Business Worker

Detail a Business Entity

Define Automation Requirements

Review the Business Object Model

Define the Business Architecture

Maintain Business Rules

Output from Activities:

Find Business Workers and Entities

Purpose

The following people use the business object model:

The business-process analyst is responsible for the integrity of the model.
The business designer documents details about responsibilities people carry and "things" produced or used by the business in this model.
The system analyst uses this model as input for identifying system actors and system use cases.
The designer uses this model as input for identifying classes in the analysis & design models.

Properties

Property Name	Brief Description	UML Representation
Introduction	A textual description that serves as a brief introduction to the model.	Tagged value, of type "short text".
Organization Units	The packages in the model, representing a hierarchy.	Owned via the association "represents", or recursively via the aggregation "owns".
Business Workers	The business worker classes in the model, owned by the packages.	Owned recursively via the aggregation "owns".
Business Entities	The business entity classes in the model, owned by the packages.	- " -
Relationships	The relationships in the model, owned by the packages.	- " -
Business Use-Case Realizations	The business use-case realizations in the model, owned by the packages.	- " -
Diagrams	The diagrams in the model, owned by the packages.	- " -

Timing

A business object model is created during inception and finalized during the elaboration phase.

Responsibility

A business-process analyst is responsible for the integrity of the business object model, ensuring that:

The organization units correctly represent the structure of the business.
The collection of business workers together cover all responsibilities in the business.
The collection of business entities together cover all "things" produced and used in the business.

Tailoring

We have identified three main variants for tailoring the business object model:

Build an "incomplete" business object model, often called domain modeling.
Build two versions of the business object model, the "as-is" and the "to-be" model.
Exclude the business object model.

You can choose to develop an "incomplete" business object model, focusing on explaining "things" and products important to the business domain. Such a model does not include the responsibilities people will carry, it only describes the information content of the organization. This is often referred to as a domain model. In such a case, you would stereotype the model as «domain model» instead of «business object model».

As-Is and To-Be Models

If the purpose of the business modeling effort is to do business reengineering, you should consider building two variants of the business object model: one that shows the current situation (as-is), and one that shows the envisioned new processes (to-be).

The as-is version of the business object model is simply an inventory of the business use-case realizations. The elements of the business object model are not described in any detail, typically brief descriptions are sufficient. The business use-case realizations can be documented with simple activity diagram, where swimlanes correspond to elements of the business object model.

Exclude the Business Object Model

If the business domain is well-understood by all members of the project team, the benefits of developing a business object model are significantly diminished. Where this occurs, the business object model may be omitted entirely.

The business object model is a way of expressing the business processes in terms of responsibilities, deliverables, and collaborative behavior. Not producing a business object model means you run the risk that developers will only give superficial attention to the way business is done. They will do what they know best, which is to design and create software in absence of business process knowledge. The result can be that the systems that are built do not support the needs of the business.

Rational Unified Process