Issue 4247: XML metamodel should be based on W3C XML Information Set
Issue 4398: supplierDependency reference is missing from ModelElement
Issue 4399: CWM Object resource package does not provide support for exceptions
Issue 4400: XML Schema package issue
Issue 4401: package may fail to permit definition of transformations
Issue 4402: consider changing DeployedComponent from being subclass of Core::Package
Issue 4403: Identify precise CWM definition to which interchange doc. conforms
Issue 4404: Review the semantics of existing attribute types that are also CWM classes
Issue 4405: diagram named "CWM Package Dependencies" shows wrong dependency arrow
Issue 4406: provide an example of extending the Management packages
Issue 4407: Inconsistencies caused by changing Expression etc from Data Types to Classe
Issue 4408: taggedValue reference is missing from ModelElement
Issue 4430: Add a representation for sequence to CWM relational package
Issue 4431: stereotype reference is missing from ModelElement
Issue 4442: Revise the IMS metamodel
Issue 4458: Data mining metamodel
Issue 4459: All OCL sections should be reviewed to ensure that they are complete
Issue 4460: Description, Document, ResponsibleParty should be made subtypes of Comment
Issue 4461: The metamodel for DTD should be reviewed
Issue 4462: Generic Data Mining metamodel issue
Issue 4467: The XML package should be revised/extended to represent XML schema metadata
Issue 4469: Missing letters in chapter 9 diagrams.
Issue 4470: Make it easier to interchange UML Models
Issue 4471: CWM does not reflect the latest version of UML
Issue 4472: Practical changes to Contact metamodel
Issue 4473: Inadequate support for Organizational Structures
Issue 4474: CWM model needs to be augmented to allow specification of level& hierarchy Attribute.initialValue incorrectly implemented as mandatory.
Issue 4475: Attribute.initialValue incorrectly implemented as mandatory.
Issue 4482: Optimize Instance data values
Issue 4509: CWM should consider using MOF 1.4 for it's metamodel
Issue 4510: CWM should consider generating XMI 1.2 DTDs
Issue 4511: CWM should consider generating XML Schemas, in both XMI 1.x and XMI 2.0
Issue 4512: Component Re-use unclear
Issue 4513: Predefined' values not defined in metamodel
Issue 4514: Supplier and version underspecified
Issue 4515: Make ChangeRequest useful
Issue 4516: Rationalize 'Measurement'
Issue 4517: Diagram 8-7-3 missing lines
Issue 4518: Logical-physical deployment modeling
Issue 4519: Warehouse processes missing physical information
Issue 4583: Modeling and packaging guidelines
Issue 4744: We only need one COBOL Data Division metamodel.
Issue 4834: We only need one COBOL Data Division model
Issue 5106: SQLParameter
Issue 5299: page 9-276/Section: 9.3.22 of ptc/2002-01-02 -- CWM issue
Issue 5695: Invalid explicit references for some 'association generalizations' in the
Issue 5697: TaggedValue
Issue 5921: Parameter
Issue 5925: figure 6, page 212
Issue 8707: formal/03-03-02
Issue 12298: Foreword
Issue 12299: Introduction - references
Issue 12300: Location: 3 Normative References
Issue 12301: Location: 3 Normative References -- OCL
Issue 12302: Location: 3 Normative References - ISO/IEC 9075:2003 Database language SQL
Issue 12303: Location: 4 Abbreviations and Conventions
Issue 12304: Location: 4 Abbreviations and Conventions - ODBC
Issue 12306: Location: 4 Abbreviations and Conventions - SQL
Issue 12307: 4 Abbreviations and Conventions - SQL-92 and SQL-99
Issue 12308: Location: 10.1 Overview
Issue 12309: Location: 10.1 Overview
Issue 12310: Location: 10.2.4 Structured Types and Object Extensions
Issue 12311: Location: 10.2.4 Structured Types and Object Extension , Figure 10.5
Issue 12312: Location: 10.2.6 Index
Issue 12313: Location: 10.2.8 Procedures
Issue 12314: Location: 10.3.14 SQLDataType
Issue 12315: Location: 10.3.15 SQLDistinctType
Issue 12316: Location: 10.3.16 SQLIndex
Issue 12317: 10.3.17 SQLIndexColumn
Issue 12318: 10.3.18 SQLParameter
Issue 12319: 10.3.20 SQLStructuredType
Issue 12320: 10.3.20 SQLStructuredType - referencingColumn
Issue 12321: 10.4.2 ColumnRefStructuredType
Issue 12322: Location: 12.1 Overview
Issue 12323: 13.1 Overview
Issue 12324: 13.3.9 Schema
Issue 12325: 21.5 SQL-99 Data Types
Issue 12326: 21.6 Type Mapping Examples
Issue 12327: Annex A: References
Issue 12328: Annex B: Compatibility with other Standards
Issue 12329: Annex C: Glossary
Issue 12330: Annex D: Legal Information
Issue 12331: Annex F: Acknowledgements
Issue 12332: Introduction, Page XVII
Issue 12333: value "name" attribute of ModelElement
Issue 12334: Location: 5.4
Issue 12335: 5.4 datatype attributes don't incorporate the features of 11404 datatype
Issue 12336: Add syntax type to the metamodel.
Issue 12337: Add datatype generators
Issue 12338: Add features for 11404 aggregates
Issue 12339: Add support for flat and nested N-dimensional arrays
Issue 12340: Support the full set of 11404 aggregates.
Issue 12341: The XML features should support current XML data structures
Issue 4247: XML metamodel should be based on W3C XML Information Set (cwm-rtf)
Click here for this issue's archive.
Source: Adaptive (Mr. Pete Rivett, pete.rivett@adaptive.com)
Nature: Revision
Severity: Significant
Summary:
XML metamodel should be based on W3C XML Information Set. W3C has a standard called XML Information Set http://www.w3.org/TR/xml-infoset/ (at Candidate Recommendation status) "This specification defines an abstract data set called the XML Information Set (Infoset). Its purpose is to provide a consistent set of definitions for use in other specifications that need to refer to the information in a well-formed XML document" In effect it defines an information model for XML with the following Information Items (the equivalent of classes in CWM): Document, Element, Attribute, Processing Instruction, Unexpanded Entity Reference, Character, Comment, Document Type Declaration, Unparsed Entity,Notation, Namespace. It would seem that since this is what W3C says should be modeled for XML documents then this should be the basis of the CWM XML model (the content part as opposed to the Schema part), or at least CWM should specify how it maps to this Information Set.
The supplierDependency reference is missing from ModelElement, which existed in the CWM Adapted Specification.This change makes the model illogical and unbalanced. Dependency is always defined between two ModelElements (a client and a supplier). Its definition involves two associations and four association ends. Either the supplierDependency reference should be put back (which makes a more flexible model) or the client reference on Dependency should also be removed (which makes a more restrictive model, but at least it is logical and balanced). (This is a revised write-up for issue #3398.)
Modern object-oriented programming languages such as Java and C# support the notion of exceptions as first class objects. However, the CWM Object resource package does not provide support for exceptions. Although exceptions might be added to extension packages specifically designed for each language that needs them, such an approach would not promote interchange of exceptions between data warehouse components written in different languages. This problem will become particularly accute for .NET languages in which particular exceptions are defined by language independent components (such as the .NET CLR libraries) and can be returned to application components written in any of a group of languages. Suggested approaches to resolving this difficulty might include (1) adding exceptions to the CWM Behavioral package or (2) creating an Object package and placing the new exception classes in it.
The planned XML Schema package proposed for inclusion in CWM 1.1 should be cognizant of and wherever possible, equivalent to, the XML Schema model planned for the inclusion in the XMI specification. Within reason, corresponding XML Schema-specific class in the two specifications show share the same names, attributes, and relationships to other classes.
Usage experience with the CWM 1.0 Transformation package has uncovered several situations in which the package may fail to permit definition of transformations that fully capture the intent of implementors. Such problems have appeared in several unrelated modeling venues and have led some implementors to seek alternative means for describing transformations. The existing transformation package should be reviewed by the RTF and changed as needed to improve its ability to represent the breadth of transformation semantics found in practical usage scenarios. As part of this effort, the RTF should consider incorporating the existing TypeMapping package into an evolved Transformation package -- TypeMappings are, after all, really just lightweight transformations.
In the SoftwareDeployment package, consider changing DeployedComponent from being a subclass of Core::Package to being as subclasss of Core::Subsystem. This change preserves the package nature of DeployedComponents and, at the same time, adds the ability of DeployedComponents to have features (because Core::Subsystem is a subclass of Core::Classifier, as well as Core::Package).
Provide in the body of a CWM interchange document, a means for identifying the precise CWM definition to which the interchange document conforms. Something similar to the way the XML documents identify the URI of the XML definition they conform to would do nicely. Such a mechanism in effect creates a name space within which the contents of the CWM interchange document can be evaluated. Useful side effects of having such a namespace include: (1) the definition of CWM extension packages without the present need that they be accompanied by the CWM definition itself, (2) a framework in which Universally Unique Identifiers (UUIDs) can be defined for each CWM object. Several requests for CWM UUIDs have already been received informally.
The precise semantics of the use of the CWM Expression class (and its subclasses) as the type of attributes of CWM classes is not clearly delineated (as discussed at the 7/12/01 CWM RTF meeting in Danvers, MA). Review the semantics of existing attribute types that are also CWM classes and correct them as needed.
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.
Expression and their subtypes (BooleanExpression, etc.) were changed from Data Types (in the CWM Adapted Specification) to Classes in CWM 1.0. As a result, it caused design inconsistency in CWM. For example, ExpressionNode inherits from Element. This was designed originally based on the fact that Expression was a Data Type and could not be subclassed. It should now inherit from Expression, which can be subclassed. The CWM RTF should review and revise all such inconsistencies caused by changing Expression, Multiplicity, etc. from Data Types to Classes.
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.]
A sequence is a relational database object that allows the automatic generation of values. Sequences are ideally suited to the task of generating unique key values. Applications can use sequences to avoid possible concurrency and performance problems resulting from the generation of a unique counter outside the database. Currently, the CWM Relational package does not provide a representation for sequence. It should be added.
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:
This is an issue deferred from the CWM FTF. Per recommendation from the Architecture Board, all OCL sections should be reviewed to ensure that they are complete
This is an issue deferred from the CWM FTF. Description, Document and ResponsibleParty should be made subtypes of Comment, allowing use of the corresponding reference on ModelElement.
This is an issue deferred from the CWM FTF. The metamodel for DTD should be reviewed, and revised if necessary, to make sure that it fully represents DTD information and that it is consistent with the new metamodel for XML Schema.
The Data Mining metamodel contains a sub-metamodel on classification/categorization, which is generic and which can be useful outside of data mining but in a data warehousing/business intelligence context. Following the tradition of CWM's design emphasis on modularity and reuse, this sub-metamodel should be made a separate package from the Data Mining package.
This issue is to capture what has been stated in Chapter 12 of the CWM specification. The XML package should be revised and extended to represent XML Schema metadata as soon as XML Schema is adopted by W3Cas a recommendation (which happened in 5/01).
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 uses a subset of UML for practical reasons. It also delegates the modeling of Object Oriented resources to that subset. However the way this is currently done makes it unnecessarily hard to take a model exported from a UML tool and import it as the model of an OO resource in CWM. CWM should provide support e.g. via metamodel and/or documented best practice (e.g. use of XMI namespaces) for this.
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.
These are gained from having tried to use the model in real situations. a) Add new attribute Contact.applicability: String (0..1), to allow a fuller description of when that contact should be used (e.g. "After hours or weekend emergencies only: when completion of a time-critical run is threatened"). b) the associations between COntact and its constituent parts (Telephhone etc) should be shown as aggregations (not compositions) for clarity. This will have no effect on generated code/DTDs. c) split the phoneNumber attribute into its constituent parts. This is because the actual number to ring is dependent on context), and there may be uses where automatic dialing is required (e.g. for fax/pager access to contacts). [It is assumed that the calling progam knows what country/area it is dialing from). The proposed replacement attributes (all optional and of type String) are: countryCode inCountryAreaPrefix (e.g. for UK it would be "0" - one dials +44 1202 449419 outside UK but 01202 449419 inside UK) areaCode corePhoneNumber.
Sections 8.3 and 8.3.1.7 justify ResponsibleParty inheriting from Namespace in that it can be used for "capturing organizational structures or similar relationships". This is not only quite obscure but is inadequate for even very simple and common Warehouse-oriented situations - due to the strict composition semantics of Namespace. In particular it does not allow a single person to belong to more than one Position/Team, nor does it allow the representation of matrix/management relationships which are very common. Moreover it does not allow the separation of two very different concepts: packaging of models and organizational relationships. An example 'test' scenario is of 2 support teams: one for Corp Database A, another for Corp Database B. Both will always have the same Manager (regardless of who is currently filling that position) and make use the same Performance Specialist, John Wicks. It is proposed that CWM adopt a simple but specific Organization Structure metamodel (no more than 5 classes such as Unit, Position, Person) that also aims for consistency with OMG's recently adopted Organizational Structure Facility.
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='.
Support for MOF 1.4 MOF 1.4 will probably be adopted at the September 2001 meeting. CWM should consider using MOF 1.4 for its metamodel, which will bring particular benefits in the area of DataTypes. Note that there is a new OMG directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.
Support for XMI 1.2 XMI 1.2 will probably be adopted at the September 2001 meeting. CWM should consider generating XMI 1.2 DTDs. Note that there is a new directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.
Support for XMI for XML Schemas The above will probably be adopted at the September 2001 meeting. CWM should consider generating XML Schemas, in both XMI 1.x and XMI 2.0 flavors. Note that there is a new directory and naming structure that allows a single metamodel to have many physical artifacts at different versions with clarity of access.
By using the inherited ElementOwnership association to link SOftwareSystem and Component, this would seem to prevent the same component being reused in many systems. Though an Import association is depicted in Figure 8-7-1, nothing is said in the text about its semantics in this context: typically this would be used just for definitions/types ("extending the namespace" according to the description in the Core model) and not something that would need to be physically deployed as part of the SoftwareSystem.
Proposed resolution: Introduce a new many-to-many shared aggregation to link SoftwareSystem and Component.
The 'predefined' values for SoftwareDeployment::SoftwareSystem.type (and subtype) should be formally defined as Constants in the metamodel. Similarly for WarehouseOperation::ChangeRequest.status and WarehouseOperation::Measure.type (there are probably others).
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
This should be part of BusinessInformation: it is not at all specific to WarehouseOperations since one could request changes to database schemas, transformations or pretty much anything. 'isActive' would be better than 'completed' for ChangeRequest, and would observe the convention of using 'is' for booleans. Moreover it should be a derived nonchangeable attribute to avoid inconsistency with 'status'. The reference from ChangeRequest to ModelElement should be 0..* since the request might be to create something new that cannot yet be referred to! The following are considered essential for most ChangeRequests: 1) two multivalued optional references to ResponsibleParty to indicate: a) raiser b) actionee 2) optional single-valued integer attribute 'priority' (larger value = more important), constrained to be non-negative. 3) optional single-valued string attributes 'raisersIdentifier' and 'identifier' (representing an id allocated by the raiser and that used internally by the warehouse management system). 4) optional multivalued string attribute 'history' to describe events in managing the request. 5) optional string attribute 'resolution' to decribe what actually happened (e.g. how the modelElements were changed, why the request was rejected etc).
This should be part of Foundation (probably Expressions or BusinessInformation): it is not at all specific to WarehouseOperations since one could apply measures to tables (for expected volumes), transformations etc. Measurement should have an optional reference to an Expression to define how the value has/should be calculated.
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 t