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.

see above

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.

see below

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

No change is required. This diagram intends to represent inheritances only

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).

see below

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).

No change is required. The metamodel is less restrictive without the stereotype reference

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.)

see below

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.

Resolved by CWM 1.1 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).

Resolved by CWM 1.1 RTF

As of XMI 1.1, an XMI format depends on both the input MOF meta-model(s)
AND some other parameters.

The CWM specification should state what XMI parameters have been used to
generate the CWM / XMI interchange formats. In particular, it should
specify:

1) what XML namespaces were used

2) what (if any) "domain data type metamodels" were used, and what
they are

3) any custom data value <-> XML string encoding rules used, and

4) whether the format supports "incomplete models".

There may be some other XMI parameters that I haven't discovered yet.

Finally, the CWM spec or an appendix should include the definitive CWM
meta-model expressed as a MOF / XMI document.

Without this information, it is difficult for someone other than the
CWM submitters to instantiate CWM repositories and CWM / XMI interchange
software.

resolved

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.

see below

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

; interface Attribute : AttributeClass, StructuralFeature

; // 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.

see below

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.

Add a new sub-type of MemberSelectionGroup which contains a reference to a hierarchy

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.

see above

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.

No Data Available

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

No Data Available

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.

Resolved by CWM 1.1 RTF