Business Object Model

WPD: Business Object Model

IBM Global Services

Business Object Model Work Product Description (WPD) Unique ID: APP 302 © Copyright International Business Machines Corporation 1998, 2000 Version 3.0, January 2000

1 Description The Business Object Model work product identifies objects of importance to a business and documents the relationships between them in terms of responsibilities and behavior. Its emphasizes the roles performed in the business area and their active responsibilities. It uses a subset of notation from the Unified Modeling Language (UML). The Business Object Model brings the notions of structure and behavior together. It is a bridging work product that articulates business concerns in a way that is similar to methods of software development while retaining a purely business content. It is a consolidation of what is known about the area of business concern expressed in terms of objects, attributes, and responsibilities. A Business Object Model is not a “model of business objects.” It is an “object model of the business.” The difference is a matter of perspective. The term “business objects” connotes the part of a software solution that directly represents items of interest to business. The software domain is associated with the scope of a planned implementation. This implementation-free view of the software space is the subject of an analysis object model.

2 Purpose The Business Object Model is positioned firmly on the bridge between the world of business and the world of information systems development. 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. Its creation is a way of verifying requirements to be enabled or supported by the information system to be built. Agreement between business object definitions and relationships, and the names for the objects and relationships permits business area knowledge to be represented in a precise manner that can be understood and validated by business area experts. In addition, the Business Object Model: •

Helps to scope what is inside and outside the specific application being developed. The boundaries of the application are explored through an object view of the business area.

•

Can be reused by many development projects. To the extent that it is it free of design details and is also free of application boundaries, a good Business Object Model is a key asset that a company can build, maintain, and reuse in many applications within the business area.

Work Product Description

Page 1 of 7

WPD: Business Object Model

2.1

Impact of Not Having This Work Product

Creation of the Business Object Model forces developers to examine other business modeling work products and reformulate them in terms of objects and collaborative behavior. Failure to perform this step means the risk that developers will only give superficial attention to the business model. This is a waste of costly business modeling effort and of the advantages of be gained therein. In this way, systems get built that do not support the true needs of the business.

2.2

Reasons for Not Needing This Work Product

If developers have participated in the business modeling efforts to produce classified business terms, business process models, business event lists, etc., they may be well grounded in the concepts of the business domain for the application. In this event, it may be reasonable to proceed directly into use case modeling and analysis object modeling.

3 Notation The notation for the Business Object Model is a simple subset of UML, with an emphasis on static structure diagrams and collaboration diagrams. The primary focus is on object types and their collaborations. Occasionally it is helpful to explore instance-level associations. The distinction between types and instances of objects is shown below. There is a “Type,” with attributes and behaviors, and an instance “T1,” where it is shown as an instance of Type with its name underlined. Type T1:Type

Attribute1 Attribute2

Attribute1 = x

Behavior1

Attribute2 = y

Behavior2

A useful portrayal of business objects is the class diagram, which is a static structure diagram. The three primary ways of relating types in UML are associations, compositions, and generalizations. Associations show multiplicity of the numbers of each type that can be validly related to each other. For example, any number of Type 1s can be associated with at least one Type 2. Type2

Type1

*

1..*

A variation on the association has an arrow point on one or both ends of the association path. This indicates that navigation is supported toward the class that is attached to the arrow. Type1

1..* *

Type2

Compositions show how types can be used to create other, more complicated types.

Type

Component1

Work Product Description

Component2

Page 2 of 7

WPD: Business Object Model Generalizations show levels of abstraction among types, where there is a type/subtype hierarchy.

Type

Subtype1

Subtype2

4 Example The following example is based on a business process model from a retail store gift registry process. This is a view on a more comprehensive model of the retail store operation. There are various roles that have been defined in the gift registry process, and these are reflected in the model below as active object types, such as EventCoordinator, WishLister, CustomerDefiner, and ProductSelector. These are shown at the center of the view, collaborating to ensure that the customer is defined, the WishList is created, Products are selected and associated with WishListItems, etc.

Gift Registry - Business Object Model RegistersGifts

Customer GuestLocation

InterStore Communicator

GathersToTransmit

BroadcastsTo

Store

* ProvidesShippingRadius

RequestsBroadcast

AccessesToTransmit

1 1

Establishes

Event

1

EventCoordinator

RequestsCreation

1

1..*

Creates

WishLister

WishList

EnsuresCompleteness

Adds

ShipToBefore

RequestsAuthentication

ShipToAfter

ProvidesRequirements

WishListItem

ConveysSelection

* 1

0..1

1 BeforeEvent Address

AfterEvent Address

CustomerDefiner

ProductSelector

MatchesRequirement

IsAlternativeFor

*

*

Product

* *

Establishes

Customer Address

CommunicatesAt

*

Complements

Authenticates

*

CustomerRecord

ProductOption

Clothing

ClothingSizes

Housewares

ClothingColors

This is a simplified drawing as it is intended to convey business information in a way that is conducive to thoughts of objects collaborating in a software space. There are some structural relationships, but the thrust of the drawing is to convey behavior between the role objects and others.

Work Product Description

Page 3 of 7

WPD: Business Object Model

5 Development Approach The Business Object Model is based on the object-oriented paradigm, which has become a dominant way of designing software. This approach stresses modularity, where modules are thought of as objects. These objects know their own state and collaborate to accomplish various forms of behavior by sending messages that request services from each other. Certain items in the business world have characteristics that closely parallel this object paradigm. These business items receive information, transmit information, transform information, and embody and execute rules. They have characteristics, such as classification, composition, and interaction, based on defined protocols. In business, things that most closely match object characteristics are people serving roles and organizations serving roles. People and organizations in roles receive, transform, and transmit information, often based on definable rules and protocol. These roles are susceptible to interesting classification as well as combinations. Other clearly information-bearing things, such as products, locations, and information constructs (e.g., agreements, lists, histories, monetary accounts etc.) also become candidates for objects in the Business Object Model. These generally cooperate with business role objects to calculate inventory levels, price themselves, trigger future actions, and store the results of business actions. There are three approaches to business object modeling: 1. The Business Object Model may be produced as part of a Joint Application Development (JAD) session. JAD techniques can be used to elicit agreement on business area details and on application requirements. An object model, and possibly scenarios, may be used to express the information discussed during the JAD sessions. 2. Begin from a generic reference model that is customized and expanded to articulate the specifics found in a particular business environment. A source on the refinements needed can be found in the business language of the specific business domain. This will help facilitate the customization of a generic solution for a particular IBM customer. 3. Start from other business model work products and mine them for information to produce the Business Object Model. Sources for information that can be expressed as business objects are the Classified Business Terms and Business Rules work products, and any business process models that may exist. When starting from the business process model, examine each type of role based on its responsibilities and interactions with other roles. No matter how the information is discovered, in building the Business Object Model business items that receive information, transmit information, transform information, embody business rules, execute rules, can be classified, can be composed into more complex structures, and can interact based on defined protocols are sought out. Also sought are persons in roles and organizations in roles as well as other information-bearing things such as products, locations, and information constructs such as agreements, lists, histories, and monetary accounts. As business objects are gathered and refined, their behaviors are articulated. The individual and organizational role objects cooperate with each other to perceive business events, capture information, and make decisions based on well-defined business rules. They work with other business objects that are able to calculate inventory levels, price themselves, trigger future actions, and store the results of business actions. A general rule for Business Object Models is to express as many object names as possible in terms of roles. Make the names denote performers of actions (e.g., CustomerDefiner and WishLister). This puts the modelers in a behavior-oriented mindset, which helps to avoid a problem where Business Object Models are simply entity relationship models. Instead the Business Object Model should depict

Work Product Description

Page 4 of 7

WPD: Business Object Model responsibility partitioning. Someone (or some thing) is responsible to perform certain actions. Modelers should be concerned with whether a division of labor is, at least conceptually, possible. As the Business Object Model develops, it is useful to create various views on the objects that have been modeled. One of these views is the static structure diagram. This shows a number of objects and how they relate to each other in arrangements such as composition and classification hierarchies. Collaboration diagrams are more behavior oriented and show how a number of objects work together to perform certain functions within the business. A particularly useful collaboration diagram is one that has a single business role object as its focal point. Based on all the actions that this role performs, wherever it appears in business process models, we create responsibilities and collaborations with other objects. This is a powerful mechanism for exploring the partitioning of behavior within the business domain.

6 Validation and Verification Walkthroughs with “arms-length” reviewers are a useful way of validating this work product for completeness and quality. Bring in peer experts to review the model. Ideally, a team composed of Information Technology personnel and, most importantly, key business personnel perform this validation. During such reviews, the leader should interpret the model for the attendees and invite their feedback. Another member of the modeling team should look for and record issues that arise during the session. A Business Object Model is complete when it reflects all important business concepts within the intended scope as specified by the classified business terms. A quality Business Object Model is one in which: •

The names of object types accurately reflect either concepts in the business area or abstractions that structure the model.

•

Class names are appropriate. Names should convey intent. Be suspicious of names such as Controller and Manager as these often indicate a centralization of control.

•

No design artifacts are present.

7 Advice and Guidance The following guidance is suggested: •

Focus the area of coverage on a well-defined business area, activity, function, or problem.

•

Keep instances in the Business Object Model work product few and simple.

•

Keep syntax to a minimum to enable customers and end users to participate fully.

•

Use the modeling notations informally as a way of sketching business area knowledge as business area experts reveal it.

•

Continually ask business area experts to validate the analysis. Conduct reviews with different experts.

•

Define the aim of the Business Object Model as precisely as possible; formulate it as a question to be answered by the analysis. An example of an aim might be: “Where are the boundaries of the application?” or “How is this application related to the existing another application?” Use this question whenever there is doubt about what should be analyzed and how deeply.

•

Use open questions to elicit stories. Focusing on specific historical incidents can be very powerful here.

Work Product Description

Page 5 of 7

WPD: Business Object Model

8 References Ballard, C., and Hodgson, R. (April, 1996). OTCN White Paper: Developing a Business Object Model Using Scenario-Based Responsibility Partitioning. IBM Object Technology Practice. Kurt, W. D. (1995). Applying OMT - A Practical Step-by-Step Guide to Using the Object Modeling Technique. Upper Saddle River, NJ: Prentice-Hall. New York: SIGS Books. ISBN 0-13-231390-1. Thornton G. and Eldred, J. (1996). Getting Results with the Object-Oriented Enterprise Model. New York: SIGS Books. Reenskaug, T., et al. (1996). Working with Objects. Greenwich, CT: Manning. Taylor, D. (1995). Business Engineering with Object Technology. New York: John Wiley & Sons. UML Notation Guide, Ver. 1.1, September, 1997.

9 Estimating Considerations The time spent creating a Business Object Model depends primarily on the complexity of the business area being modeled. Assuming the existence of a set of process models and classified terms, an object model can be put together in a period of 2 to 4 weeks. The basic model can be subjected to various views, in the proper tool, and these views will be revisited and refined during the course of the project. Questions to be considered when making estimations of effort required to produce Business Object Models include: •

What reference models exist from similar business situations that can be reused?

•

What models already exist in the client environment?

•

What is the scope of the effort?

•

How large and diverse is the user community being modeled?

•

How complex is the business area in general?

Work Product Description

Page 6 of 7

WPD: Business Object Model

10 Revision History Date of this release: Revision Number

Date of next revision:

Revision Date

Summary of Changes

Version 3.0

January 2000

MIFP published version – no changes.

Version 1.3

December 1999

Removed context information in Estimating Considerations.

Version 1.2

September 1999

Updated template, editorial changes, and inserted estimating considerations

Version 1.1

February 1999

A standard format template was applied, and the document was edited for grammatical errors.

Version 1.0

September 1998

Base version.

Work Product Description

Changes Marked?

No

Page 7 of 7