5.3 Business Information Metamodel

   The Business Information package depends on the following package: org.omg::CWM::ObjectModel::Core

   The Business Information Metamodel provides general purpose services available to all CWM packages for defining business-oriented information about model elements. The business-oriented services described here are designed to support the needs of data warehousing and business intelligence systems; they are not intended as a complete representation of general purpose business intelligence metamodel.

   Business Information Metamodel services support the notions of responsible parties and information about how to contact them, identification of off-line documentation and support for general-purpose descriptive information. Three CWM classes “anchor? these services: ResponsibleParty, Document, and Description, respectively.

   The metamodel is shown in Figure 5-2 .

   Figure 5-2 BusinessInformation metamodel

   To aid in representing the diversity of organizational structures and documentation relationships that may be encountered in a business intelligence system, the metamodel provides robust relationships between the anchor classes and every model element in the CWM metamodel. The necessary robustness is achieved in several ways.

   First, every CWM model element may have zero or more instances of each anchor class associated with it. This means, for example, that a single Description instance can be used to describe many different model elements. Conversely, a single model element may be described by many different Description instances. Likewise, Document and ResponsibleParty instances can be associated in completely ad hoc ways with any model element. Extending this idea means, for example, that Description instances could be used to further describe ResponsibleParty and Document instance, if needed.

   Second, because they are Namespaces, the anchor classes can be organized into hierarchies using the ElementOwnership association. For instance, an organizational structure can be represented by a hierarchy of ResponsibleParty instances. Also, the internal structure of a document; that is, its chapters, sections, subsections, etc. might be represented by a hierarchy of Document instances.

   Finally, instances of the three anchor classes can be associated with any model element (via their individual associations to ModelElement) and referenced by multiple instances of any of the three anchor classes. Because of the strong containment of the ElementOwnership association in the ObjectModel, anchor class instances can only participate in one hierarchy, but there are no restrictions preventing anchor class instances embedded in a hierarchy from referencing, or being referenced by, other model elements (even other members of the same hierarchy).

    To illustrate some of the ways that the metamodel can be used, Figure 5-3 shows a simple document hierarchy with responsibility assignments and descriptive comments (boxes represent instances of metamodel classes and labelled lines represent metamodel associations connecting instances). In the example, the product plan document for the Widget product is composed of three subplans: a marketing plan, an engineering plan, and a resource plan. The relationships between the subplans documents is shown as a hierarchy with the product plan owning the three subordinate plans via the ElementOwnership association. Each part of the plan is assigned to a responsible party using the ModelElementResponsibility association. Finally, Description instances are used to record roles for the responsible parties.

    : ModelElementDescription Product Manager :DescriptionResponsibleParty

   "Widget" : ElementOwnership Name

   Product Plan : DocumentDescribes Product : Document Class

   Marketing Plan : Engineering Plan : Resources Plan :Document Document Document

   ModelElementResponsibility ModelElementResponsibility ModelElementResponsibility

   VP Marketing : Architect : CFO :ResponsibleParty ResponsibleParty ResponsibleParty

   ModelElementDescription ModelElementDescription ModelElementDescription

   : :

   :

   DescriptionDescriptionDescription

   body ="Approves body ="Develops body= "Builds financial marketing plan" : String engineering plan" : String model" : String

   Figure 5-3 Document hierarchy with assigned ResponsibleParties

   Similar robustness is provided for structuring relationships between ResponsibleParty instances and the means of contacting them. Each ResponsibleParty can have multiple, ordered sets of contact information (the Contact class) and a single set of contact information can service multiple ResponsibleParties. Also, because they are not owned by any particular Contact instance, Telephone, Email, Location, and ResourceLocator instances can be reused elsewhere in the CWM metamodel. An example of the use of Business Information classes to find the ChiefEngineer at three times (Weekday, Weekend, Emergency) is shown in Figure 5-4.

   Chief Engineer : ResponsibleParty

   Emergency : Contact ResponsiblePartyContact Office Phone :

   Telephone Weekday : Contact ContactTelephone

   Beeper :

   ContactLocation ContactEmail

   Telephone Office : OfficeEmail ContactTelephone Location : Email

   HomePhone : Telephone

   Weekend :

   ContactTelephone

   Contact

   Home : HomeEmail : Location Email

   Figure 5-4 Using Contact information to find the ChiefEngineer