Issues for CWM 1.2 Revision Task Force discussion list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 4405: diagram named "CWM Package Dependencies" shows wrong dependency arrow
Issue 4406: provide an example of extending the Management packages
Issue 4408: taggedValue reference is missing from ModelElement
Issue 4431: stereotype reference is missing from ModelElement
Issue 4442: Revise the IMS metamodel
Issue 4458: Data mining metamodel
Issue 4469: Missing letters in chapter 9 diagrams.
Issue 4471: CWM does not reflect the latest version of UML
Issue 4474: CWM model needs to be augmented to allow specification of level& hierarchy
Issue 4475: Attribute.initialValue incorrectly implemented as mandatory.
Issue 4482: Optimize Instance data values
Issue 4514: Supplier and version underspecified
Issue 4517: Diagram 8-7-3 missing lines
Issue 4518: Logical-physical deployment modeling
Issue 4834: We only need one COBOL Data Division model

Issue 4405: diagram named "CWM Package Dependencies" shows wrong dependency arrow (cwm-rtf)

In the CWM .mdl file, the diagram named "CWM Package Dependencies"
contains a dependency arrow showing that the Relational package depends on
the SoftwareDeployment package.  This dependency arrow is erroneous and
should be removed (the dependency does not appear in the definitional CWM
XMI file).

Volume 2 of the CWM Specification does not provide an example of extending the Management packages (Warehous Process and Warehouse Operation). It will be very useful to provide an example of extending these packages (and their dependent packages) based on IBM's DB2 Data Warehouse Center. This product has implemented the CWM Management packages and has demonstrated the need for such extensions as well as how they can be done.

The taggedValue reference is missing from ModelElement, which existed in the CWM Adapted Specification. This is an error and must be corrected immediately. TaggedValue is a critical, light-weight extension mechanism and is used extensively in our implementation of CWM. Without the taggedValue reference on ModelElement, we will not be able to support CWM 1.0. (This is a revised write-up for issue #4408.)

The default resolution will be to apply the following changes to the CWM 1.0 specification, document ad/01-02-01: 

(1) On page 7-80, following the definition of the 'namespace' reference and before the "Constraints" subheading, add:taggedValue References the set of taggedValue instances that extend the ModelElement. 
class: TaggedValue defined by: TaggedElement::taggedValue 
multiplicity: zero or more 
inverse: TaggedValue::modelElement 

(2) On pages 7-67 and 7-68, merge Figure 7-3-1 and Figure 7-3-3 into a new Figure 7-3-1 that contains all the elements from both original figures there will no longer be a Figure 7-3-3). [Note: the absence of the taggedValue reference on ModelElement allowed these figures to be drawn separately. With its return, the figure must be merged.] 

(3) On page 7-67, remove the last sentence of the second paragraph on the page. [Note: This sentence references "Figure 7-4" and should have referenced "Figure 7-3-3", making this a typographically convenient deletion.]

 In the Core package, the stereotype reference, that maps to the
stereotype end of the StereotypedElement association, is missing from
ModelElement. This is a result of an error in the construction of the final
CWM 1.0 spec (the same error is associated with Issue #4408).

IBM has implemented the IMS metamodel of CWM 1.0. In doing so, we have found it necessary to make some significant changes to improve usability and completeness, and to handle new facilities of IMS. The CWM RTF should revise the IMS metamodel incorporating these changes.

This is an issue deferred from the CWM FTF. The Data Mining metamodel should be revised based on feedback from the JSR-73 (JDMAPI) work

Resolution: 

The CWM.Analysis.DataMining package was re-factored to allow for varied implementaions. In DataMining the various products all support some sub-set of the existing DataMining features and algorithms. The current model is fine for interchange where a user who doesn't support a specific feature or algorithm can simply ignore it on import. The CWM model forms the basis for JDMAPI which is an API specification. The structure of the model must now reflect a way to specify various compliance points based on implementation options. In order to achieve this, the DataMining model was split into finer grained packages which are based on the different DataMining algorithms. We felt this was the correct path to take, and felt justified based on the fact that to our knowledge there are no implementers of the DataMining portion of CWM. 
The resolution was to replace the existing CWM.Analysis.DataMining package with the revised one, this was distributed for review on 8/23/01 and presented in Toronto on 9/11/01.

Revised Text: 

Figure 9-1 has initial letters missing from ModelElement and Constraint classes. Figure 9-9 has initial letter missing from Table class. Figure 9-10 has initial leters missing from the Parameter and SQLParameter classes. Figure 9-13 has initial letter missing from DataValue class.

This issue was caused when cutting and pasting from rose into the spec. This problem will be corrected by adding the figures correctly to the revised spec..

CWM aims to be a subset of UML. Various changes have occurred in Core at UML 1.4 which are not reflected in CWM. CWM 1.1 should be updated to reflect the latest UML. For example, the old TaggedValue now has been split between new TaggedValue which just holds the value (in a multivalued 'dataValue' attribute or as a 'referenceValue' ModelElement) and a new TagDefinition class which provides the tag name, reference to Stereotype and a multiplicity. Document ad/01-02-24 contains the UML 1.4 changes, though only changes to the Core will be relevant to CWM.

No update is required. The ObjectModel, though derived from UML, is independent of UML and its evolution. In the future, when MOF 2.0 and UML 2.0 are adopted, CWM 2.0 should be aligned with them.

The CWM model currently defines the physical mapping of a Cube based only on a level of a dimension. The model needs to be augmented to allow the specification of both a level and a hierarchy.

The XMI representation of the CWM metamodel does not implement the specification for the initialValue attribute of the Core.Attribute class: in the specification (section 7.3.2.1 on p7-71) it clearly states the "multiplicity: zero or one"). However in the XMI file the lower bound is 1. Note: the lower bound of 0 is consistent with the UML metamodel. 

The impact is that,despite the DTD not being affected, XMI imports fail when any subclass of Attribute (see below IDL changes for a list) does not specify an initialValue Expression. 

This affects the XMI file, the Rose model, and the IDL. It does not affect the DTD since DTDs do not reflect attribute multiplicity. 

Proposed resolution: Update the CWM XMI file, document ad/01-02-03 to change the value of Core.Attribute.initialValue.multiplicity.lower from 1 to 0. 

Update the CWM Rose model, document ad/01-02-07 for attribute initialValue of Core:Attribute to change the value of the tag 'rose2mof.multiplicity' from "1" to "0..1". 

Update the following in the CWM IDL files, document ad/01-02-06: In core.idl change the declaration of Attribute and its class proxy to: 

typedef sequence<Expression> ExpressionBag; interface AttributeClass : StructuralFeatureClass { readonly attribute AttributeSet all_of_type_attribute; readonly attribute AttributeSet all_of_class_attribute; Attribute create_attribute ( in Core::Name name, in VisibilityKind visibility, in ScopeKindBag owner_scope, in ChangeableKind changeability, in MultiplicityBag multiplicity, in OrderingKindBag ordering, in ScopeKindBag target_scope, in ExpressionBag initial_value) raises (Reflective::MofError); }; interface Attribute : AttributeClass, StructuralFeature { Expression initial_value () raises (Reflective::NotSet, Reflective::MofError); void set_initial_value (in Expression new_value) raises (Reflective::MofError); void unset_initial_value () raises (Reflective::MofError); }; // end of interface Attribute 

And in the following files and the following class proxies change the initial_value parameter of the 'create_x' constructor to be of type Core::ExpressionBag rather than Core::Expression: 

Multidimensional.idl: DimensionedObjectClass Olap.idl: MeasureClass Record.idl: FieldClass, FixedOffsetFieldClass Relational.idl: ColumnClass CML.idl: XMLAttributeClass, ElementTypeReferenceClass, TextClass InformationReporting.idl: ReportAttribute DataTypes.idl : UnionMemberClass DataMining.idl: MiningAttributeClass, NumericAttributeClass, CategoricalAttributeClass, Ordinal,AttributeClass, ApplicationAttributeClass COBOLData.idl: COBOLFieldClass, RenamesClass DMSII.idl: DataItemClass, RemapItemClass ER.idl: ErAttributeClass Essbase.idl: AliasClass, CommentClass, ConsolidationClass, CurrencyConversionClass, DataStorageClass, FormulaClass, GenerationClass, ImmediateParentClass, LevelClass, MemberNameClass, TimeBalanceClass, TwoPassCalculationClass, UDAClass, VarianceReportingClass Express.idl: VariableClass, FormulaClass, ValueSetClass, RelationClass IMSDatabase.idl: ImsFieldClass, SenFieldClass. 

Update the CWM XMI file, document ad/01-02-03 to change the value of Core.Attribute.initialValue.multiplicity.lower from 1 to 0. 
Update the CWM Rose model, document ad/01-02-07 for attribute initialValue of Core:Attribute to change the value of the tag 'rose2mof.multiplicity' from "1" to "0..1". 

Update the following in the CWM IDL files, document ad/01-02-06: In core.idl change the declaration of Attribute and its class proxy to: typedef sequence ExpressionBag; interface AttributeClass : StructuralFeatureClass { readonly attribute AttributeSet all_of_type_attribute; readonly attribute AttributeSet all_of_class_attribute; Attribute create_attribute ( in Core::Name name, in VisibilityKind visibility, in ScopeKindBag owner_scope, in ChangeableKind changeability, in MultiplicityBag multiplicity, in OrderingKindBag ordering, in ScopeKindBag target_scope, in ExpressionBag initial_value) raises (Reflective::MofError); }; interface Attribute : AttributeClass, StructuralFeature { Expression initial_value () raises  Reflective::NotSet, Reflective::MofError); void set_initial_value (in Expression new_value) raises (Reflective::MofError); void unset_initial_value () raises (Reflective::MofError); }; // end of interface Attribute And in the following files and the following class proxies change the initial_value parameter of the 'create_x' constructor to be of type Core::ExpressionBag rather than Core::Expression: Multidimensional.idl: DimensionedObjectClass Olap.idl: 
MeasureClass Record.idl: FieldClass FixedOffsetFieldClass Relational.idl: ColumnClass CML.idl: XMLAttributeClass, ElementTypeReferenceClass, 
TextClass InformationReporting.idl: ReportAttribute DataTypes.idl : UnionMemberClass DataMining.idl: MiningAttributeClass, NumericAttributeClass, 
CategoricalAttributeClass, Ordinal,AttributeClass, ApplicationAttributeClass COBOLData.idl: COBOLFieldClass, RenamesClass DMSII.idl: 
DataItemClass, RemapItemClass ER.idl: ErAttributeClass Essbase.idl: AliasClass, CommentClass, ConsolidationClass, CurrencyConversionClass, 
DataStorageClass, FormulaClass, GenerationClass, ImmediateParentClass, LevelClass, MemberNameClass, TimeBalanceClass, TwoPassCalculationClass, UDAClass, VarianceReportingClass Express.idl: VariableClass, FormulaClass, ValueSetClass, RelationClass 
IMSDatabase.idl: ImsFieldClass, SenFieldClass.

The Instances (hence MultiDimensional) metamodel is very wasteful
in requiring a separate DataValue object for each simple string slot value:
this in effect doubles the number of objects for value-oriented schemas such
as Dimension definitions (in MultiDimensional where DataValue is inherited
into MemberValue). This is a problem for XMI files and their processing, but
even more so for repository implementations which tend to have management
overheads associated with each object. Moreover these DataValue objects end
up being directly contained in the MemberSet for the Dimension, which surely
was not the intention. This means that when navigating from the Dimension to
process its Members one also has to filter out a large number of these
unwanted Data/MemberValue objects.

Proposed resolution
-------------------
a) Add new subclass of Slot called 'DataSlot' with description: "A Slot
which is used to hold a data value where there is no need to manage the
value as an element in its own right (in which case a DataValue would be
used) - for example it is a one-off string value or a number."
b) Add String attribute 'dataValue', description: "The value for the slot
expressed as a string."
c) Add reference 'dataType'[0..1] to DataType, description: "The type of the
dataValue. If not set the type is taken as the type of the StructuralFeature
associated with the DataSlot."
d) Add constraint that DataSlot.value (reference inherited from Slot) must
be empty.
e) Update Figure 7-6-3 to change the 2 instances of Slot associated with the
'name' Attribute to be instances of DataSlot, delete the attached instances
of DataValue, and attach the 'value=' strings directly to the DataSlots
making them 'dataValue='.


Rationale
---------
This is intended to be a minimal-impact proposal that is incremental and
does not impact existing implementations.
It does not replace the existing DataValue class where there is the real
need to have stand-alone managed data values (the equivalent of Constant in
MOF and EnumerationLiteral in UML), but is for use where the values are pure
one-off values for which the overhead of a separate ModelElement is not
justified: for example most numeric and string values.
The George and Martha example in Figure 7-6-3 illustrates the distinction:
for the one-off names "George Washington" and "Martha Custis Washington"
then the new DataSlot is used, but for the pseudo-enumeration values
associated with the MaritalStatus attribute ("Married", "Widowed",
"Divorced") then DataValue is still used: in particular because some of the
values (e.g. "Divorced") are not yet associated with any actual Slot.
a) Add new subclass of Slot called 'DataSlot' with description: "A Slot which is used to hold a data value where there is no need to manage the value as an element in its own right (in which case a DataValue would be used) - for example it is a one-off string value or a number. 
The dataValue (and dataType where set) must be consistent with the type of the DataSlot's feature (Attribute) and must obey any constraints on the full 
descriptor of the Attribute's DataType (including both explicit constraints and built-in constraints such as multiplicity)." 

b) Add String attribute 'dataValue', description: "The value for the slot expressed as a string." 

c) Add reference 'dataType'[0..1] to DataType, description: "The type of the dataValue. If not set the type is taken as the type of the Attribute 
(StructuralFeature) which is the feature for the DataSlot. " 

d) Add constraint that the feature of a DataSlot must be an Attribute. In OCL: 
self.feature.oclIsTypeOf(Attribute). 

e) Add constraint that a DataType associated with a DataSlot must be type compatible with that associated 
with the Attribute which is its feature. In OCL: self.dataType.oclIsKindOf(self.feature.type). 

f) Change multiplicity of reference Slot.value from 1 to 0..1 and add constraints that it must not be empty 
for direct instances of Slot and must be empty for instances of DataSlot. In OCL: [on Slot] self.oclIsTypeOf(Slot)implies self.value->notEmpty() 
and [on DataSlot] self.value->isEmpty(). 

g) Update Figure 7-6-3 to change the 2 instances of Slot associated with the'name' Attribute to be instances of DataSlot, delete the attached instances 
of DataValue, and attach the 'value=' strings directly to the DataSlots making them 'dataValue='.

Supplier and version of SoftwareSystem should be optional: they are not always known or relevant. 

The description for supplier should clarify whether it represents any/all of: a) the original developer (e.g. "Oracle"); b) the entity who sold the software to the organization (e.g. a reseller); c) the IT support group within the organization who deployed it for a particular set of business users. 

It would make more sense to model supplier as a reference to BusinessInformation::ResponsibleParty, since this would allow reuse, contact information and impact analysis ("supplier X has gone out of business, what have they supplied us?"). Version might also make sense on DeployedSoftwareSystem (at a logical/design level one might not care what the version is: but it might be required to record which version is actually deployed). 

Add string attribute ‘fixLevel’ to DeployedSoftwareSystem and make supplier and version attributes optional on SoftwareSystem

Diagram 8-7-3 could be made a clearer by using associations (lines) in addition to the references.

DataManager contains a reference to the specific data (at the schema level) that is being managed but is constrained to be a DeployedComponent on a specific Machine. Though a DataManager refers to the Component that it 'instantiates' there is nothing associated with Component that allows one to record what data it can manage. 

For example, I would like to be able to create an element called "Peopleware Payroll Application" which references the relational schema for the application. This should be possible without having to say anything about its deployment onto specific machines. 

A separate but related point is the lack of support for physical databases. For example, When deploying an application I then want to be able to say what physical database it's using. The value of tracking this is for backup purposes etc, and the fact that actual WarehouseOperations will need to be applied to specific databases. 

Proposed resolution 

Add new class 'PhysicalDatabase' to SoftwareDeployment Model; this will inherit from Package and will have a many-to-many association 'LogicalPhysical' with Package, and be contained by Machine (as for DeployedComponent). [May want a subslcass of Dependency between PhysicalDatabases to represent replication/federation/partitioning. Or alternatively use containment by one 'abstract' PhysicalDatabase of others to represent this, though this does not allow the exact relationship to be expressed.] 

Move the 'dataPackage' reference from DataManager to SoftwareSystem. Add new many-to-many reference 'databases' to DataManager with target type PhysicalDatabase. 

Resolution: 

a) Add new many-to-many Association ComponentDesign between Component and Package (with one reference 
     Component.designPackage). And description "This associates Components with the Packages 
     containing its design. Typically this will reference the logical schema." 
b) Add new many-to-many recursive Association DeployedComponentUsage on DeployedComponent (with references  usedComponents and usingComponents). And description "This links a DeployedComponent to the other DeployedComponents that it uses. Typically this might link a deployed application to the physical databases (instances of  DataManager) that it accesses."

CWM vol. 2 3.1 says
"The concepts and ideas implicit in the definition of the COBOL language's
DATA DIVISION were one of the earliest (if not the first) formalizations of
the ubiquitous record model. A COBOL program contains much more than just
record descriptions. However, because neither CWM nor UML attempt to
describe programming languages directly, only the DATA DIVISION is described
here. The model presented here is compliant to the COBOL 85 language
standard [COBOL].

The primary purpose of the COBOL DATA DIVISION metamodel extension package
in CWM is to allow the structure of DATA DIVISIONs to be captured so that
their usage of other model elements (such as RecordDefs and Fields) can be
modeled. This allows definition of files and databases created by COBOL
programs as well as direct support for tools that attempt to track the
lineage and determine the impact of proposed changes to COBOL application
programs. The metamodel does not, however, provide sufficient structure to
support tools that want to capture the structure of a DATA DIVISION source
into a CWM repository and then be able to faithfully reproduce the source on
demand.

The COBOL DATA DIVISION metamodel extension also serves as an example of
the use of the CWM Record metamodel. The CWM Record package is intended as a
foundation upon which many record-oriented programming languages can be
described. The COBOL Data Division extension package is provided as example
demonstrating appropriate usage of CWM and UML classes in modeling the data
structure representation parts of this and similar programming language
environments."


UML Profile for EAI 14.1 says
"The goal of this COBOL model is to capture the information that would be
found in the Data Division." .

Both define partial COBOL language meta models with different levels of
detail.  We only need one COBOL Data Division model.

Resolution:
An explicit  statement to this effect has been inserted as part of a new section in chapter 3 (section 3.4.1)