The CWM Experience Implementing a UMLBased Data Warehouse

Agenda • Overview of CWM • Modeling Issues – Package boundaries – Minimizing package dependencies – Associations, references, and reuse • Was UML a useful foundation metamodel for CWM? – Design vs. Implementation – Package granularity is critical – The CWM Object. Model • Suggestions for UML 2 Copyright 2001. UNISYS Corporation. 2

CWM Charter CWM “Standard interfaces that can be used to enable easy interchange of warehouse and business intelligence metadata between warehouse tools, warehouse platforms and warehouse metadata repositories in distributed heterogeneous environments. ” – www. omg. org Charter “A complete specification of the syntax and semantics needed to export/import warehouse metadata and the common warehouse metamodel. This may consist of a specification for the common warehouse metamodel, APIs (in IDL), and/or interchange formats. ” -- Common Warehouse Metadata Interchange RFP, OMG document ad/98 -07 -16, page 2. Sponsors Co-submitters IBM, Unisys, NCR, Hyperion, Oracle, UBS, Genesis, Dimension EDI Supporters Deere, Sun, HP, Data Access Technologies, In. Line Software, Aonix, Hitachi, SAS Institute, Meta Integration Technology Specs: http: //www. omg. org Info: http: //www. cwmforum. org Copyright 2001. UNISYS Corporation. 3

The CWM Metamodel ETL Operational Data Sources Data Warehouses Source Target Source Pairwise (9

OMG Metamodel Architecture Standard Components üModeling Notation: UML üMetadata Interchange: XMI üMetadata API: MOF IDL Mapping JMI – MOF/Java Mapping CWM 1. 0 is based on üUML 1. 3 üMOF 1. 3 üXMI 1. 1 M I D D L E W A R E A P P L I C A T I O N Copyright 2001. UNISYS Corporation. Meta-metamodel Layer (M 3) MOF: Class, Attribute, Operation, Association Metamodel Layer(M 2) UML: Class, Attribute CWM: Table, Column Element. Type, Attribute Metadata/Model Layer(M 1) User Data/Object Layer (M 0) Stock: name, price <Stock name=“IBM” price=“ 112”/> 5

The CWM Metamodel Warehouse Process Management Analysis Resource Foundation Object Model Transformation OLAP Object (Core+Behavioral+ Relationships) Relational Warehouse Operation Data Information Business Mining Visualization Nomenclature Record Multi. Dimensional XML Business Data Keys Type Software Expressions Information Types Index Mapping Deployment Core Behavioral Copyright 2001. UNISYS Corporation. Relationships Instance 6

CWM Statistics Management Analysis Resource (Reuses Core+Behavioral+ Relationships) Foundation Object Model 204 classes &

CWM Model Subsets Management Analysis (Reuses Core+Behavioral+ Relationships) Resource Foundation Object Model Relational subset : 68 classes & 37 associations in 6 packages Add-on for Relational => OLAP ETL : 100 classes & 74 associations in 8 packages Copyright 2001. UNISYS Corporation. 8

Modeling Issues – Package Boundries • MOF rules affect how associations may cross package boundaries Metamodel (M 2) Composition Closure Rule The composite and component instances in a composition along with any links that form the composition must all belong to the same outermost Package extent. -- MOF v 1. 3 specification, page 4 -19 Instances (M 1) Package Extent P 1 Metamodel Package X Y x 1 y 1 Links <x 1, y 1> <x 1, y 3> y 2 Illegal: Component instance y 3 must in same package as composite instance x 1 Package Extent P 2 y 3 Links <x 1, y 2> Effect on CWM: Preserve lifecycle semantics Classes X and Y and the composite association between them must be in the same metamodel package to preserve cascade delete semantics. Copyright 2001. UNISYS Corporation. Illegal: Association must be declared in same package as its composite instance x 1 9

Modeling Issues – Package Boundries • MOF rules affect how associations may cross package boundaries Instances (M 1) Metamodel (M 2) Reference Closure Rule If Class C has a Reference R that exposes an Association End E in an Association A, then it is illegal to cause a link to be constructed such that an instance of C (or a subclass of C) at the exposed End belongs to a different outermost extent to the A link set containing the link. Package Extent P 1 Metamodel Package X / ref. Y : Y / ref. Z : Z XY x 1 Y / ref. X : X XZ y 1 XY Metamodel Package XZ Links <x 2, z 2> XY XZ XY Links <x 1, y 1> <x 2, y 2> Package Extent P 2 Z z 2 Illegal: Cyclical dependencies not allowed x 2 y 2 XZ Links <x 2, z 2> Illegal: XY link must exist in P 2 -- MOF v 1. 3 specification, page 4 -18 Effect on CWM: No Cyclical Dependencies Classes X and Y and associations XY and XZ must reside in the same metamodel package. Class Z cannot have a reference to class X. Copyright 2001. UNISYS Corporation. 10

Modeling Issues -Minimize Package Dependencies • Reuse inherited associations wherever possible • Without association generatization, precise semantics will require OCL constraints. Do this … Not this … Copyright 2001. UNISYS Corporation. One package invokes three One package invokes six! 11

Modeling Issues – Associations, References & Reuse • Association generalization would define association reuse much more precisely Classifier (from Core) owner {ordered} * 0. . 1 What CWM wanted to reuse Class – Avoids messy, situational feature (from Core) Feature (from Core) Structural. Feature (from Core) OCL statements • MOF’s association end/reference dichotomy is foreign to UML – CWM invented notational Attribute Column. Set (from Core) (from Relational) What CWM meant Named. Column. Set (from Relational) conventions to handle – Notation & semantics for renaming inherited association ends and references is unclear Copyright 2001. UNISYS Corporation. What CWM wanted to show Table column table (from Relational) 1 New. Class 2 Column (from Relational) * 12

UML as a Foundation for MDA Implementations • Design vs. Implementation Orientation – UML is design-oriented • Notational clarity is paramount • Leads to fewer, larger packages • Implementation pragmatics absent – CWM and MOF are implementation-oriented • Many, smaller packages desirable • Implementation pragmatics enforced • Amenable to interface and repository generation – MOF/UML incompatibilities were very troublesome Copyright 2001. UNISYS Corporation. 13

UML as a Foundation for MDA Implementations • Package granularity is critical – Many, smaller packages preferred • Group related concepts into reusable units • Minimize dependencies between packages • Many obvious parallels in the high modularity of modern programming languages – Reduced conceptual clutter • UML v 1. 3 has ca. 125 classes – Many represent ideas not used by CWM – Deleterious impact on generated interfaces – Creates need to explain unused concepts to users • CWM needed only 37 UML classes – From all three UML outermost packages > But 95% for these from UML Foundation – Must invoke all 125 UML classes! Copyright 2001. UNISYS Corporation. 14

UML as a Foundation for MDA Implementations • In CWM, UML replaced by Object. Model – Subset of UML needed by CWM • Plus a few CWM-specific simplifications – 37 classes – 25 associations Copyright 2001. UNISYS Corporation. 15

UML as a Foundation for MDA Implementations UML 1. 3 Copyright 2001. UNISYS Corporation.

Suggestion for UML 2 • Identify a common core – Reusable by UML, MOF, CWM, and others – CWM 2. 0 can test usability • More, smaller packages containing functionally coherent groups of classes – Follow MOF rules when crossing package boundaries • Support association generalization • Resolve association/reference dichotomy Copyright 2001. UNISYS Corporation. 17