Unisys.JCR.1 1.3.2 The Core metamodel depends on no other packages. The ObjectModel Core metamodel contains basic metamodel classes and associations used by all other CWM metamodel packages, including other ObjectModel packages OCL Representation of Core Constraints Operations The operation allFeatures results in a Set containing all Features of the Classifier itself and all its inherited Features. allFeatures : Set(Feature); allFeatures = self.feature->union(self.parent.oclAsType(Classifier).allFeatures) The operation allAttributes results in a Set containing all Attributes of the Classifier itself and all its inherited Attributes. allAttributes : set(Attribute); allAttributes = self.allFeatures->select(f | f.oclIsKindOf(Attribute)) The operation specification yields the set of Classifiers that the current Classifier realizes. specification: Set(Classifier) specification = self.clientDependency-> select(d | d.stereotype.name = "realization" and d.supplier.oclIsKindOf(Classifier)).supplier.oclAsType(Classifier) The operation parent returns a Set containing all direct parents of a Classifier. parent : Set(Classifier); parent = self.generalization.parent The operation allParents returns a Set containing all the Classifiers inherited by this Classifier (the transitive closure), excluding the Classifier itself. allParents : Set(Classifier); allParents = self.parent->union(self.parent.allParents) The operation allContents returns a Set containing all ModelElements contained in the Classifier together with the contents inherited from its parents. allContents : Set(ModelElement); allContents = self.contents->union(self.parent.allContents-> select(e | e.elementOwnership.visibility = #public or e.elementOwnership.visibility = #protected)) The operation supplier results in a Set containing all direct suppliers of the ModelElement. supplier : Set(ModelElement); supplier = self.clientDependency.supplier The operation allSuppliers results in a Set containing all the ModelElements that are suppliers of this ModelElement, including the suppliers of these Model Elements. This is the transitive closure. allSuppliers : Set(ModelElement); allSuppliers = self.supplier->union(self.supplier.allSuppliers) The operation contents results in a Set containing all ModelElements contained by the Namespace. contents : Set(ModelElement) contents = self.ownedElement -> union(self.namespace.contents) The operation allContents results in a Set containing all ModelElements contained by the Namespace. allContents : Set(ModelElement); allContents = self.contents The operation allVisibleElements results in a Set containing all ModelElements visible outside of the Namespace. allVisibleElements : Set(ModelElement) allVisibleElements = self.allContents -> select(e | e.elementOwnership.visibility = #public) The operation allSurroundingNamespaces results in a Set containing all surrounding Namespaces. allSurroundingNamespaces : Set(Namespace) allSurroundingNamespaces = self.namespace->union(self.namespace.allSurroundingNamespaces) The operation contents results in a Set containing the ModelElements owned by or imported by the Package. contents : Set(ModelElement) contents = self.ownedElement->union(self.importedElement) The operation allImportedElements results in a Set containing the ModelElements imported by the Package. allImportedElements : Set(ModelElement) allImportedElements = self.importedElement The operation allContents results in a Set containing the ModelElements owned by or imported by the Package. allContents : Set(ModelElement) allContents = self.contents Constraints [C-3-1] A Constraint cannot be applied to itself. context Constraint inv: not self.constrainedElement->includes (self) [C-3-2] A DataType cannot contain any other ModelElements. context DataType inv: self.ownedElement->isEmpty [C-3-3] Tags associated with a model element (directly via a property list or indirectly via a stereotype) must not clash with any meta attributes associated with the model element. context ModelElement inv: -- cannot be specified with OCL org.omg.cwm.objectmodel CWM CoreModule org.omg.java.cwm.objectmodel An element is an atomic constituent of a model. In the metamodel, an Element is the top metaclass in the metaclass hierarchy. Element is an abstract metaclass. A model element is an element that is an abstraction drawn from the system being modeled. In the metamodel, a ModelElement is a named entity in a Model. It is the base for all modeling metaclasses in the CWM. All other modeling metaclasses are either direct or indirect subclasses of ModelElement. true A namespace is a part of a model that contains a set of ModelElements each of whose names designates a unique element within the namespace. In the metamodel, a Namespace is a ModelElement that can own other ModelElements, such as Classifiers. The name of each owned ModelElement must be unique within the Namespace. Moreover, each contained ModelElement is owned by at most one Namespace. The concrete subclasses of Namespace may have additional constraints on which kind of elements may be contained. Namespace is an abstract metaclass. Note that explicit parts of a model element, such as the features of a Classifier, are not modeled as owned elements in a namespace. A namespace is used for unstructured contents such as the contents of a package, or a class declared inside the scope of another class. A classifier is an element that describes structural and behavioral features; it comes in several specific forms, including class, data type, interface, component, and others that are defined in other metamodel packages. Classifier is often used as a type. In the metamodel, a Classifier may declare a collection of Features, such as Attributes, Operations and Methods. It has a name, which is unique in the Namespace enclosing the Classifier. Classifier is an abstract metaclass. Classifier is a child of Namespace. As a Namespace, a Classifier may declare other Classifiers nested in its scope. Nested Classifiers may be accessed by other Classifiers only if the nested Classifiers have adequate visibility. There are no data value or state consequences of nested Classifiers, i.e., it is not an aggregation or composition. A class is a description of a set of objects that share the same attributes, operations, methods, relationships, and semantics. A class may use a set of interfaces to specify collections of operations it provides to its environment. In the metamodel, a Class describes a set of objects sharing a collection of Features that are common to the set of objects. The purpose of a Class is to declare a collection of Features that fully describe the structure and behavior of objects. Some Classes may not be directly instantiated. These Classes are said to be abstract and exist only for other Classes to inherit and reuse the Features declared by them. No object may be a direct instance of an abstract Class, although an object may be an indirect instance of one through a subclass that is non-abstract. A Class acts as the namespace for various kinds of contained elements defined within its scope, including classes, interfaces and associations (note that this is purely a scoping construction and does not imply anything about aggregation). The contained classes can be used as ordinary classes in the container class. If a class inherits another class, the contents of the ancestor are available to its descendents if the visibility of an element is public or protected; however, if the visibility is private, then the element is not visible and therefore not available in the descendant. A data type is a type whose values have no identity (i.e., they are pure values). Data types include primitive built-in types (such as integer and string) as well as definable enumeration types. In the metamodel, a DataType defines a special kind of Classifier in which operations are all pure functions (i.e., they can return data values but they cannot change data values, because they have no identity). For example, an "add" operation on a number with another number as an argument yields a third number as a result; the target and argument are unchanged. A DataType is a special kind of Classifier whose instances are primitive values, not objects. For example, integers and strings are usually treated as primitive values. A primitive value does not have an identity, so two occurrences of the same value cannot be differentiated. Usually, DataTypes are used for specification of the type of an attribute or parameter. A package is a grouping of model elements. In the metamodel, Package is a subclass of Namespace. A Package contains ModelElements such as Packages and Classifiers. A Package may also contain Constraints and Dependencies between ModelElements of the Package. The purpose of the package construct is to provide a general grouping mechanism. In fact, its only semantics is to define a namespace for its contents. The package construct can be used for organizing elements for any purpose; the criteria to use for grouping elements together into one package are not defined. A package owns a set of model elements, with the implication that if the package is removed from the model, so are the elements owned by the package. Elements with names, such as classifiers, that are owned by the same package must have unique names within the package, although elements in different packages may have the same name. There may be relationships between elements contained in the same package, and between an element in one package and an element in a surrounding package at any level. In other words, elements “see” all the way out through nested levels of packages. Elements in peer packages, however, are encapsulated and are not a priori visible to each other. The same goes for elements in contained packages, i.e. packages do not see "inwards". Elements owned by a Package can be made available to other Packages by importing them. Although any ModelElement may be imported by a Package, imported ModelElements are typically other Packages. When an element is imported by a package it extends the namespace of that package. Thus the elements available in a Package consists of its owned and imported ModelElements. A subsystem is a grouping of model elements that represents a behavioral unit in a physical system. A subsystem offers interfaces and has operations. In the metamodel, Subsystem is a subclass of both Package and Classifier. As such it may have a set of Features. The purpose of the subsystem construct is to provide a grouping mechanism for specifying a behavioral unit of a physical system. Apart from defining a namespace for its contents, a subsystem serves as a specification unit for the behavior of its contained model elements. The contents of a subsystem is defined in the same way as for a package, thus it consists of owned elements and imported elements, with unique names within the subsystem. A model captures a view of a physical system. It is an abstraction of the physical system, with a certain purpose. The model completely describes those aspects of the physical system that are relevant to the purpose of the model, at the appropriate level of detail. In the metamodel, Model is a subclass of Package. It contains a containment hierarchy of ModelElements that together describe the physical system. A Model also contains a set of ModelElements that represents the environment of the system. Different Models can be defined for the same physical system, where each model represents a view of the physical system defined by its purpose and abstraction level, e.g. an analysis model, a design model, an implementation model. Typically different models are complementary and defined from the perspectives (viewpoints) of different system stakeholders. A feature is a property, like attribute or operation, which is encapsulated within a Classifier. In the metamodel, a Feature declares a structural or behavioral characteristic of an instance of a Classifier or of the Classifier itself. Feature is an abstract metaclass. A structural feature refers to a static feature of a model element. In the metamodel, a StructuralFeature declares a structural aspect of a Classifier that is typed, such as an attribute. For example, it specifies the multiplicity and changeability of the StructuralFeature. StructuralFeature is an abstract metaclass. UmlAttribute A constraint is a semantic condition or restriction expressed in text. In the metamodel, a Constraint is a BooleanExpression on an associated ModelElement(s) which must be true for the model to be well formed. This restriction can be stated in natural language, or in different kinds of languages with well-defined semantics. Certain Constraints are predefined, others may be user defined. Note that a Constraint is an assertion, not an executable mechanism. The specification is written as an expression in a designated constraint language. The language can be specially designed for writing constraints (such as OCL), a programming language, mathematical notation, or natural language. If constraints are to be enforced by a model editor tool, then the tool must understand the syntax and semantics of the constraint language. Because the choice of language is arbitrary, constraints can be used as an extension mechanism. The constraint concept allows new semantics to be specified linguistically for a model element. In the metamodel a Constraint directly attached to a ModelElement describes semantic restrictions that this ModelElement must obey. UmlConstraint A dependency states that the implementation or functioning of one or more elements requires the presence of one or more other elements. In the metamodel, a Dependency is a directed relationship from a client (or clients) to a supplier (or suppliers) stating that the client is dependent on the supplier (i.e., the client element requires the presence and knowledge of the supplier element). A dependency specifies that the semantics of a set of model elements requires the presence of another set of model elements. This implies that if the source is somehow modified, the dependents probably must be modified. The reason for the dependency can be specified in several different ways (e.g., using natural language or an algorithm) but is often implicit. Whenever the supplier element of a dependency changes, the client element is potentially invalidated. After such invalidation, a check should be performed followed by possible changes to the derived client element. Such a check should be performed after which action can be taken to change the derived element to validate it again. In the metamodel a Multiplicity defines a non-empty set of non-negative integers. A set which only contains zero ({0}) is not considered a valid Multiplicity. Every Multiplicity has at least one corresponding String representation. In the metamodel a MultiplicityRange defines a range of integers. The upper bound of the range cannot be below the lower bound. The lower bound must be a nonnegative integer. The upper bound must be a nonnegative integer or the special value unlimited, which indicates there is no upper bound on the range. The stereotype concept provides a way of branding (classifying) model elements so that they behave as if they were instances of new virtual metamodel constructs. These model elements have the same structure (attributes, associations, operations) as similar non-stereotyped model elements of the same kind. The stereotype may specify additional constraints and required tagged values that apply to model elements. In addition, a stereotype may be used to indicate a difference in meaning or usage between two model elements with identical structure. In the metamodel the Stereotype metaclass is a subclass of ModelElement. Tagged Values and Constraints attached to a Stereotype apply to all ModelElements branded by that Stereotype. A stereotype keeps track of the base class to which it may be applied. The base class is a class in the metamodel (not a user-level modeling element) such as Class, Association, etc. If a model element is branded by an attached stereotype, then the CWM base class of the model element must be the base class specified by the stereotype or one of the subclasses of that base class. A tagged value allows information to be attached to any model element in the form of a "tagged value" pair (i.e., name = value). The interpretation of tagged value semantics is intentionally beyond the scope of CWM. It must be determined by user or tool conventions. It is expected that tools will define tags to supply information needed for their operations beyond the basic semantics of CWM. Such information could include code generation options, model management information, or user-specified semantics. Even though TaggedValues are a simple and straightforward extension technique, their use restricts semantic interchange of metadata to only those tools that share a common understanding of the specific tagged value names. umlValue The Any data type is used to indicate that an attribute or parameter may take values from any of the available data types. In CWM, the set of data types an Any attribute or parameter may assume includes the data types and enumerations described in this chapter plus any available instances of the Classifier class. There is no default value for data type Any. Boolean defines an enumeration that denotes a logical condition. The default for data type Boolean is false. The Float data type is used to indicate that an attribute or parameter may take on floating point numeric values. The number of significant digits and other representational details are implementation defined. The default for the Float data type is the value 0.0. Integer represents the predefined type of integers. An instance of Integer is an element in the (infinite) set of integers (..., -2, -1, 0, 1, 2, ...). The default for Integer is 0. Name defines a token which is used for naming ModelElements and similar usages. Each Name has a corresponding String representation. For purposes of exchange a name should be represented as a String. The default for the Name data type is an empty string. String defines a piece of text. Strings do not normally have a defined length; rather, they are considered to be arbitrarily long (practical limits on the length of Strings exist, but are implementation dependent). When String is used as the type of an Attribute, string length sometimes can be specified (see the Relational and Record packages for examples). The default for the String data type is an empty string. Time defines a statement which will define the time of occurrence of an event. The specific format of time expressions is not specified here and is subject to implementation considerations. There is no default for the Time data type. UnlimitedInteger defines a data type whose range is the nonnegative integers augmented by the special value "unlimited". It is used for the upper bound of multiplicities. The default for an UnlimitedInteger is the special value "unlimited". ck_ In the metamodel OrderingKind defines an enumeration that specifies how the elements of a set are arranged. Used in conjunction with elements that have a multiplicity in cases when the multiplicity value is greater than one. The ordering must be determined and maintained by operations that modify the set. The default value is ok_unordered. ok_ In the metamodel ScopeKind defines an enumeration that denotes whether a feature belongs to individual instances or an entire classifier. The default value is sk_instance. sk_ In the metamodel VisibilityKind defines an enumeration that denotes how the element to which it refers is seen outside the enclosing name space. The default value is vk_public. vk_ umlConstraint The StereotypeTaggedValues association links Stereotypes with the set of TaggedValues they require. TaggedValues cannot simultaneously participate in both the TaggedElement and StereotypeTaggedValues associations. The TaggedElement association links TaggedValues with the ModelElements that own them. TaggedValues cannot simultaneously participate in both the TaggedElement and StereotypeTaggedValues associations. The Behavioral metamodel depends on the following package: org.omg::CWM::ObjectModel::Core The Behavioral metamodel collects together classes and associations that describe the behavior of CWM types and provides a foundation for recording the invocations of defined behaviors. The elements of the Behavioral metamodel are shown in the following figure. OCL Representation of Behavioral Constraints Operations The operation hasSameSignature checks if the argument has the same signature as the instance itself. hasSameSignature ( b : BehavioralFeature ) : Boolean; hasSameSignature (b) = (self.name = b.name) and (self.parameter->size = b.parameter->size) and Sequence{ 1..(self.parameter->size) }->forAll( index : Integer | b.parameter->at(index).type = self.parameter->at(index).type and b.parameter->at(index).kind = self.parameter->at(index).kind ) The operation allOperations results in a Set containing all Operations of the Classifier itself and all its inherited Operations. allOperations : Set(Operation); allOperations = self.allFeatures->select(f | f.ockIsKindOf(Operations)) The operation allMethods results in a Set containing all Methods of the Classifier itself and all its inherited Methods. allOperations : Set(Method); allMethods = self.allFeatures->select(f | f.ockIsKindOf(Method)) Constraints [C-4-1] All Parameters should have a unique name. context BehavioralFeature inv: self.parameter->forAll(p1, p2 | p1.name = p2.name implies p1 = p2) [C-4-2] The type of the Parameters should be included in the Namespace of the Classifier. context BehavioralFeature inv: self.parameter->forAll( p | self.owner.namespace.allContents->includes (p.type) ) [C-4-3] The number of arguments must be the same as the number of parameters of the Operation. context CallAction inv: self.actualArgument->size = self.operation.parameter->size [C-4-4] An Interface can only contain Operations. context Interface inv: self.allFeatures->forAll( f | f.oclIsKindOf( Operation ) ) [C-4-5] An Interface cannot contain any ModelElements. context Interface inv: self.allContents->isEmpty [C-4-6] All Features defined in an Interface are public. context Interface inv: self.allFeatures->forAll( f | f.visibility = #public ) [C-4-7] If the realized Operation is a query, then so is the Method. context Method inv: self.specification->isQuery implies self.isQuery org.omg.cwm.objectmodel CWM BehavioralModule org.omg.java.cwm.objectmodel Argument is an expression describing how to determine an actual value passed in a CallAction. In the metamodel an Argument is a composite part of a CallAction and contains a meta-attribute, value, of type Expression. It states how the actual argument is determined when the owning CallAction is executed. umlValue A behavioral feature refers to a dynamic feature of a model element, such as an operation or method. In the metamodel, BehavioralFeature specifies a behavioral aspect of a Classifier. All different kinds of behavioral aspects of a Classifier, such as Operation and Method, are subclasses of BehavioralFeature. BehavioralFeature is an abstract metaclass. A call action is an action resulting in an invocation of an operation. The purpose of a CallAction is to identify the actual Arguments used in a specific invocation of an Operation. Interface is a named set of operations that specify the behavior of an element. In the metamodel, an Interface contains a set of Operations that together define a service offered by a Classifier realizing the Interface. A Classifier may offer several services, which means that it may realize several Interfaces, and several Classifiers may realize the same Interface. UmlInterface Operation is a service that can be requested from an object to effect behavior. An Operation has a signature, which describes the parameters that are possible (including possible return values). In the metamodel, an Operation is a BehavioralFeature that can be applied to instances of the Classifier that contains the Operation. Operation is the specification, while Method is the implementation. In the metamodel ParameterDirectionKind defines an enumeration that denotes if a Parameter is used for supplying an argument and/or for returning a value. The enumeration values are: The default value is pdk_in. pdk_ The Relationships metamodel depends on the following package: org.omg::CWM::ObjectModel::Core The Relationships metamodel collects together classes and associations that describe the relationships between object within a CWM information store. The Relationships metamodel describes to types of relationships: association and generalization. Association relationships record linkages between model elements. These linkages may represent simple linkages between model elements or aggregation ("is part of") relationships between model elements; aggregation relationships come in two forms -- shared and composite. Associations have two or more named ends that link them to instances of the classes connected by the association. Generalization relationships record arrangements of model elements into type hierarchies in a parent/child (or "is type of") fashion. Child types are said to "specialize", "subclass" or "subtype" their parental types, represent a subset of parental instances that fulfill the definition of the child type, and inherit the structural features (Attributes, AssociationEnd) and behavioral features (Operations, Methods) of their parents. Parental types are said to "generalize" their child types or to be "superclasses" or "supertypes" of their children. CWM generalization hierarchies support multiple inheritance; that is, child types may have more than one parental type and inherit the union of the features of all their parental types. Although called "hierarchies", multiple inheritance actually represents a directed acyclic graph of parental and child types. OCL Representation of Relationships Constraints Operations The operation allConnections results in the set of all AssociationEnds of the Association. allConnections : Set(AssociationEnd); allConnections = self.feature.oclIsKindOf(AssociationEnd) Constraints [C-5-1] An Association must have at least 2 AssociationEnds. context Association inv: self.allConnections->size > 1 [C-5-2] The AssociationEnds must have a unique name within the association. context Association inv: self.allConnections->forAll( r1, r2 | r1.name = r2.name implies r1 = r2) [C-5-3] At most one AssociationEnd may be an aggregation or composition. context Association inv: self.allConnections->select(aggregation <> #ak_none)->size <= 1 [C-5-4] If an Association has three or more AssociationEnds, then no AssociationEnd may be an aggregation or composition. context Association inv: self.allConnections->size >=3 implies self.allConnections->forall(aggregation = #ak_none) [C-5-5] The connected Classifiers of the AssociationEnds should be included in the Namespace of the Association, or be Classifiers with public visibility in other Namespaces to which the Association has access. context Association inv: self.allConnections->forAll(r | self.namespace.allContents->includes (r.type) ) or self.allConnections->forAll(r | self.namespace.allContents->excludes (r.type)) implies self.namespace.clientDependency->exists (d | d.supplier.oclAsType(Namespace).ownedElement->select (e | e.elementOwnership.visibility = #ak_public)->includes (r.type) or d.supplier.oclAsType(Classifier).allParents. oclAsType(Namespace).ownedElement->select (e | e.elementOwnership.visibility = #ak_public)->includes (r.type) or d.supplier.oclAsType(Package).allImportedElements->select (e | e.elementImport.visibility = #ak_public) ->includes (r.type) ) ) [C-5-6] An AssociationEnd must have an owning Association. context AssociationEnd inv: self.owner.oclIsKindOf(Association) [C-5-7] The Classifier of an AssociationEnd cannot be an Interface or a DataType if the association is navigable away from that end. context AssociationEnd inv: (self.type.oclIsKindOf (Interface) or self.type.oclIsKindOf (DataType)) implies self.owner->select (ae | ae <self)->forAll(ae | ae.isNavigable = #false) [C-5-8] An instance may not belong by composition to more than one composite Instance. context AssociationEnd inv: self.aggregation = #ak_composite implies self.multiplicity.max <= 1 [C-5-9] An AssociationEnd with composite or shared aggregation semantics must be owned by an Association. context AssociationEnd inv: self.aggregation = #ak_composite or self.aggregation = #ak_shared implies self.owner.oclIsKindOf(Association) org.omg.cwm.objectmodel CWM RelationshipsModule org.omg.java.cwm.objectmodel An association defines a semantic relationship between classifiers. Associations have two or more named ends. Associations with two or more ends are called "n-ary" whereas associations with exactly two ends are called "binary". Each end, depending upon its multiplicity, connects to zero or more instances of some classifier. In the metamodel, an Association is a declaration of a semantic relationship between Classifiers, such as Classes. Associations must have two, and may have more, association ends. Each end is connected to a Classifier; the same Classifier may be connected to more than one association end in the same association. (Refer to the ObjectModel’s Instance package, below, for a description of how Associations are instantiated.) Because Associations are classifiers, they own and order their association ends (which are Attributes) via the ClassifierFeature association. In addition, because Associations are Classes, they can also own more traditional StructuralFeatures such as Attributes. Consequently, they may act in a manner similar to "association classes" described by some other object models. An association may represent an aggregation (i.e., a whole/part relationship). In this case, the association end attached to the whole element is designated, and the other association end represents the parts of the aggregation. Associations can be of three different kinds: (1) ordinary association, (2) composite aggregate, and (3) shareable aggregate. Since the aggregate construct can have several different meanings depending on the application area, CWM gives a more precise meaning to two of these constructs (i.e., association and composite aggregate) and leaves the shareable aggregate more loosely defined in between. Only binary Associations can have composite or sharable aggregation semantics. Composite aggregation is a strong form of aggregation which requires that a part instance be included in at most one composite at a time and that the composite object has sole responsibility for the disposition of its parts. This means that the composite object is responsible for the creation and destruction of the parts. In implementation terms, it is responsible for their memory allocation. If a composite object is destroyed, it must destroy all of its parts. It may remove a part and give it to another composite object, which then assumes responsibility for it. If the multiplicity from a part to composite is zero-to-one, the composite may remove the part and the part may assume responsibility for itself, otherwise it may not live apart from a composite. A consequence of these rules is that a composite aggregation implies propagation semantics (i.e., some of the dynamic semantics of the whole is propagated to its parts). For example, if the whole is copied or destroyed, then so are the parts as well (because a part may belong to at most one composite). A classifier on the composite end of an association may have parts that are classifiers and associations. At the instance level, an instance of a part element is considered "part of" the instance of a composite element. If an association is part of a composite and it connects two classes that are also part of the same composite, then an instance of the association will connect objects that are part of the same composite object of which the instance is part. A shareable aggregation denotes weak ownership (i.e., the part may be included in several aggregates) and its owner may also change over time. However, the semantics of a shareable aggregation does not imply deletion of the parts when an aggregate referencing it is deleted. Both kinds of aggregations define a transitive, antisymmetric relationship (i.e., the instances form a directed, non-cyclic graph). Composition instances form a strict tree (or rather a forest). An association end is an endpoint of an association, which connects the association to a classifier. Each association end is part of one association. The association ends of each association are ordered. In the metamodel, an AssociationEnd is part of an Association and specifies the connection of an Association to some other Classifier. Because AssociationEnds are a kind of StructuralFeature, they are owned and ordered by Association instances via the ClassifierFeature association. The StructuralFeatureType association is used to identify the Classifier to which the AssociationEnd is attached. Each AssociationEnd has a name and defines a set of properties of the connection. The multiplicity property of an association end specifies how many instances of the classifier at a given end (the one bearing the multiplicity value) may be associated with a single instance of the classifier at the other end. The association end also states whether or not the connection may be traversed towards the instance playing that role in the connection (the isNavigable attribute), that is, if the instance is directly reachable via the association. A generalization is a taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element (it has all of its properties, members, and relationships) and may contain additional information. In the metamodel, a Generalization is a directed inheritance relationship, uniting a Classifier with a more general Classifier in a hierarchy. Generalization is a subtyping relationship; that is, an instance of the more general ("parent") Classifier may be substituted by an instance of the more specific ("child") Classifier. To understand inheritance fully, it is necessary to understand the concept of a full descriptor and a segment descriptor. A full descriptor is the full description needed to describe an instance of a metamodel object. It contains a description of all of the attributes, associations, and operations that the object contains. In a pre-object-oriented language, the full descriptor of a data structure was declared directly in its entirety. In an object-oriented language, the description of an object is built out of incremental segments that are combined using inheritance to produce a full descriptor for an object. The segments are the modeling elements that are actually declared in a model. Each classifier contains a list of features and other relationships that it adds to what it inherits from its ancestors. The mechanism of inheritance defines how full descriptors are produced from a set of segments connected by generalization.The full descriptors are implicit, but they define the structure of actual instances. Features of a classifier that have private visibility are not visible to descendants of the classifier. If a classifier has no parent, then its full descriptor is the same as its segment descriptor. If a classifier has one or more parents, then its full descriptor contains the union of the features from its own segment descriptor and the segment descriptors of all of its ancestors. No attribute, operation, or association end with the same signature may be declared in more than one of the segments (in other words, they may not be redefined). A method may be declared in more than one segment. A method declared in any segment supersedes and replaces a method with the same signature declared in any ancestor. If two or more methods nevertheless remain, then they conflict and the model is ill-formed. The constraints on the full descriptor are the union of the constraints on the segment itself and all of its ancestors. If any of them are inconsistent, then the model is ill-formed. In any full descriptor for a classifier, each method must have a corresponding operation. In a concrete classifier, each operation in its full descriptor must have a corresponding method in the full descriptor. An enumeration that denotes what kind of aggregation an Association defines. When placed on a target end, specifies the relationship of the target end to the source end. The default value is ak_none. ak_ The Instance metamodel depends on the following package: org.omg::CWM::ObjectModel::Core In addition to the metadata normally interchanged with CWM, it is sometimes useful to interchange specific data instances as well. The ObjectModel’s Instance metamodel allows the inclusion of data instances with the metadata. OCL Representation of Instance Constraints Constraints [C-6-1] A DataValue originates from a Classifier that is a DataType. context DataValue inv: self.classifier.oclIsKindOf(DataType) [C-6-2] A DataValue has no Slots. context DataValue inv: self.valueSlot->isEmpty [C-6-3] An Object may only own Objects and DataValues. context Object inv: self.contents->forAll(c | c.oclIsKindOf(Object) or c.oclIsKindOf(DataValue)) [C-6-4] If an Object represents an association, at least two of its ends must be not be empty. context Object inv: self.classifier.oclIsKindOf(Association) implies self.slot.feature->iterate( ae ; cnt : Integer = 0 | if ae.oclIsKindOf(AssociationEnd) and ae.value.notEmpty then cnt + 1 else cnt end if ) > 1 [C-6-5] If the StructuralFeature describing a Slot is an AssociationEnd, the Classifier associated with the Object owning the Slot must be an Association. context Slot inv: self.feature.oclIsKindOf(AssociationEnd) implies self.value.classifier.oclIsKindOf(Association) org.omg.cwm.objectmodel CWM InstanceModule org.omg.java.cwm.objectmodel A data value is an instance with no identity. In the metamodel, DataValue is a child of Instance that cannot change its state, i.e. all operations that are applicable to it are pure functions or queries that do not cause any side effects. DataValues are typically used as attribute values. Since it is not possible to differentiate between two data values that appear to be the same, it becomes more of a philosophical issue whether there are several data values representing the same value or just one for each value. In addition, a data value cannot change its data type and it does not have contained instances. Each instance of Extent owns a collection of instances and is used to link such collections to their structural and behavioral definitions in CWM Resource packages. Because Extent is a subclass of package, it owns member instances via the ElementOwnership associaton. The instance construct defines an entity to which a set of operations can be applied and which has a state that stores the effects of the operations. In the metamodel Instance is connected to a Classifier that declares its structure and behavior. It has a set of attribute values matching the definition of its Classifier. The set of attribute values implements the current state of the Instance. Because Instance is an abstract class, all Instances are either Object or DataValue instances. The data content of an Instance comprises one value for each attribute in its full descriptor (and nothing more). The value must be consistent with the type of the attribute. An instance must obey any constraints on the full descriptor of the Classifier of which it is an instance (including both explicit constraints and built-in constraints such as multiplicity). An object is an instance that originates from a class. In the metamodel, Object is a subclass of Instance originating from a Class. The Class may be modified dynamically, which means that the set of features of the Object may change during its life-time. An object is an instance that originates from a class; it is structured and behaves according to its class. All objects originating from the same class are structured in the same way, although each of them has its own set of attribute slots. Each attribute slot references an instance, usually a data value or possibly, another object. The number of attribute slots with the same name fulfills the multiplicity of the corresponding attribute in the class. The set may be modified according to the specification in the corresponding attribute, e.g. each referenced instance must originate from (a specialization of) the type of the attribute, and attribute slots may be added or removed according to the changeable property of the attribute. UmlObject umlObject cwmlValue 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. 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 (i.e., 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, the following figure 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 reponsible party using the ModelElementResponsibility association. Finally, Description instances are used to record roles for the responsible parties. OCL Representation of BusinessInformation Constraints [C-3-1] A Description may not describe itself. context Description inv: self.modelElement->forAll(p | p <> self) [C-3-2] A Document may not describe itself. context Document inv: self.modelElement->forAll(p | p <> self) [C-3-3] A ResponsibleParty may not describe itself. context ResponsibleParty inv: self.modelElement->forAll(p | p <> self) CWM org.omg.cwm.foundation BusinessInformationModule org.omg.java.cwm.foundation The ResponsibleParty class allows representation of entities within an information system that are in some way interested in receiving information about, or are otherwise responsible for, particular ModelElements. Each ResponsibleParty may own multiple sets of contact information, and a single ResponsibleParty may be associated with many ModelElements. ResponsibleParty instances may represent any entity appropriate to the system being modeled and need not be limited to people. For example, a ResponsibleParty instance might represent an individual such as "George Washington", a role (the "President"), or an organization ("Congress"), depending upon the needs of the system being modeled. Similarly, the precise semantics of the responsibility attribute are open to intrepretation and may be adapted on a system-by-system basis. Because ResponsibleParty instances are Namespaces, they can be organized into hierarchies of ResponsibleParty instances, capturing organizational structures or similar relationships. Instances of the Telephone class represent telephone contact information. Because telephones are first class objects within the CWM, they can be used for purposes beyond those associated with the CWM Foundation’s Business Information concepts. A textual representation of the telephone’s type, such as "multi-line", or its usage, such as "home", "work", "fax", or "mobile". An Email instance identifies a single email address. Via a Contact instance, an email address can be associated with one or more ResponsibleParty instances. Email instances might, for example, be used by an automated tool to send an automatically generated email message to a ResponsibleParty instance responsible about some change of state for a particular ModelElement. Multiple Email instances may be associated with a single Contact instance and the ordering of the association between them may be used to represent the sequence in which the Email instances should be contacted. Because email addresses are first class objects within the CWM, they can be used for purposes beyond those associated with the CWMFoundation’s Business Information concepts. Instances of the Location class represent physical locations. Note that the name of a Location is derived from its superclass, ModelElement. Because Locations are first class objects within the CWM, they can be used for purposes beyond those associated with the CWM Foundation’s Business Information concepts. If additional attributes about Location instances are required, they should be added by creating subtypes of the Location class and placing the additional attributes therein. Each Contact instance collects together the various types of related contact information. Each Contact instance can be associated with multiple Email, Location and Telephone instances. Conversely, each Email, Location, ResourceLocator and Telephone instance can be associated with many Contact instances. The ordering constraints on the associations between these classes and the Contact class can be used to represent a prioritized sequence in which the various types of contact information should be used. A particular ResponsibleParty instance may have multiple instances of Contact associated with it via the ResponsiblePartyContact association. This association is ordered to support representation of the sequence in which Contact instances should be used. For example, a ResponsibleParty instance representing an employee might be associated with Contact instances representing their office, home, and mobile contact information with an indication that the employee should be contacted first at the office, then at home, and finally via their mobile phone. To maximize flexibility of the metamodel, Contact instances may provide contact information for multiple ResponsibleParty instances. Instances of the Description class contain arbitrary textual information relevant to a particular ModelElement. While Description instances may contain any desired textual information, they will typically contain documentation or references to external reference information about the owning ModelElement. Any ModelElement may have multiple Description instances associated with it. Indeed, a ModelElement instance that is a Description instance may itself have multiple Description instances linked to it. Also, a hierarchies of Description instances can be constructed. Description instances are meant to hold descriptive textual information that will be stored in the metamodel itself. In contrast, Document instances are meant to describe the location documentary information stored outside the metamodel. The Document class represents externally stored descriptive information about some aspect of the modeled system. An instance of Document might be associated with one or more ModelElements. The name of a Document instance is derived from its superclasses. Although the purposes of the Description and Document types may overlap somewhat, their chief distinction is that Description instances are stored with the CWM metadata whereas Documentation instances are stored externally to the CWM metadata. Although there is an implication here that Documentation instances might represent more voluminous information than Description instances, there is no particular requirement that this be so. Because Documentation instances are themselves Namespace instances, hierarchical relationships between various externally stored documents can be represented. Instances of the ResourceLocator class provide a general means for describing the resources whose location is not defined by a traditional mailing address. For example, a ResourceLocator instance could refer to anything from a location within a building ("Room 317, third file cabinet, 2nd drawer") to a web location ("www.omg.org"). Because they are first class objects in the CWM, ResourceLocator instances may also be used for purposes beyond those associated with the CWM Foundation's Business Information concepts. The ContactEmail association indicates the Email instances relevant used by Contact instances. The DocumentDescribes association connects a Document instance with the ModelElement instances to which it pertains. The DataTypes package depends on the following packages: org.omg::CWM::ObjectModel::Core The CWM DataTypes metamodel supports definition of metamodel constructs that modelers can use to create the specific data types they need. Although the CWM Foundation itself does not contain specific data type definitions, a number of data type definitions for widely used environments are provided (in the CWM Data Types chapter) as examples of the appropriate usage of CWM Foundation classes for creating data type definitions. OCL Representation of DataTypes Constraints [C-4-1] A TypeAlias instance cannot alias itself. context TypeAlias inv: self.type <> self [C-4-2] A Union can have at most one default UnionMember instance. context Union inv: self.allFeatures->select(isDefault)->size <= 1 CWM org.omg.cwm.foundation DataTypesModule org.omg.java.cwm.foundation The Enumeration class is intended as a starting point from which enumerated data types can be created. An enumerated data type is a collection of identifiers often used as the permitted states that some other attribute or property of the enumerated type may take. The isOrdered attribute of an Enumeration instance is used to determine if the ordered constraint on the EnumerationLiterals association is relevant for the enumeration. The particular ordering of EnumerationLiteral instances is obtained from the ordered constraint on the association even if the value attributes of the EnumerationLiteral instances contain non-null values that might be used to determine ordering. This is done to provide more flexible ordering semantics. An instance of Enumeration is also required to create a range data type. Refer to the EnumerationLiteral class for details. If True, the ordered constraint on the EnumerationLiterals association is relevant. Otherwise, the ordering of EnumerationLiteral instances is considered unspecified. EnumerationLiteral instances describe the enumeration identifiers, and possibly the values, associated with an enumerated data type. Enumeration identifiers are contained in the name attribute derived from the EnumerationLiteral instance’s ModelElement superclass. EnumerationLiteral instances may also be used to define expression-based values such as ranges. To do so, simply state the membership expression in the instance’s value. For example, a range literal can be created by setting the value attribute to "m..n", where m represents the lower bound of the range, and n, the upper bound. In this way, ranges and other more complicated expressions can be intermixed with simple enumeration literals. For example, an enumeration might contain the literals "1", "2", "4..7", and "> 10". Consequently, a simple range data type can be created with an Enumeration instance that owns a single EnumerationLiteral instance. For example, a data type for positive integers could be created as shown in the following instance diagram. A model attribute of this data type might then be declared as "posInt : PositiveInteger". umlValue typedef Foundation.DataTypes.ProcedureExpression QueryExpression; The Union class represents programming language unions and similarly structured data types. Because of the diversity of union semantics found across software systems, the Union and UnionMember classes are likely candidates for specialization to better capture union semantics in specific language extension packages. A discriminated Union has a collection of UnionMembers that determine the sets of contents that the Union may contain. Such Unions have an attribute called the discriminator that identifies the memberCase value of the UnionMember that the Union currently contains. The discriminator is found via the UnionDiscriminator association to StructuralFeature. The discriminator may be embedded within UnionMembers or may be located outside the discriminator. If it is located within UnionMembers, the discriminator should occur in every UnionMember at the same location (often, the first). Undiscriminated unions (for example, a C language union) are also supported, but have an empty discriminator reference, and the memberCase attribute of the UnionMembers it contains is ignored. Undiscriminated Unions are often used to represent alternate views of a single physical storage area. A fine degree of control over this aspect of Unions may be obtained by creating a class that derives from both UnionMember and FixedOffsetField (in the CWM Record package) and setting the offset attribute instances of that class accordingly. CwmUnion UnionMembers are described as features of a Union and each represents one of the members of a Union. Note, however, that multiple case values can map to a single UnionMember. If isDefault is true, the union member is the default member. UnionMember instances are allowed to have a memberCase and be the default case. UnionMember instances often represent structured storage areas. A particular UnionMember may be associated with a Classifier that describes its internal structure via the StructuralFeatureType association (defined in the ObjectModel::Core package). For example, the Record::Group class, itself a Classifier, can be used as the type of a UnionMember in a manner completely analogous to how it is used to describe the type of a structured field (see the instance diagrams in the Record metamodel chapter for details). The EnumerationLiterals association links enumeration literals to the Enumeration instances that contain them. If the Enumeration’s isOrdered attribute is True, the ordering constraint on the association is relevant. Otherwise, it is ignored. The UnionDiscriminator association connects a Union instance with the StructuralFeature instance that can be used to determine which UnionMember instance is currently present in the Union instance. This "discriminating" attribute may be a feature of the UnionMembers themselves or may be a feature of some Classifier that contains the Union instance as one of its Features. In the former case, the discriminating feature will usually be present at the same offset in each UnionMember instance. If the discriminator reference is empty for a particular Union instance, it is considered to be an "undiscriminated" Union and determination of the current UnionMember residing in the Union is usage-defined. The Expressions package depends on the following packages: org.omg::CWM::ObjectModel::Core The CWM Expressions metamodel provides basic support for the definition of expression trees within the CWM. The intent of the Expressions metamodel is to provide a place for other CWM packages (such as Transformation) and CWM compliant tools to record shared expressions in a common form that can be used for interchange and lineage tracking. The expression concept in the CWM Foundation takes a functional view of expression trees, resulting in the ability of relatively few expression types to represent a broad range of expressions. Every function or traditional mathematical operator that appears in an expression hierarchy is represented as a FeatureNode. For example, the arithmetic plus operation “a + b” can be thought of as the function “sum(a, b).” The semantics of a particular function or operation are left to specific tool implementations and are not captured by the CWM. The hierarchical nature of the CWM’s representation of expressions is achieved by the recursive nature of the OperationArgument association. This association allows the sub-hierarchies within an expression to be treated as actual parameters of their parent nodes. OCL Representation of Expressions Constraints [C-5-1] A FeatureNode that has parameters other than the"this" parameter represents a Feature that is also an Operation. context FeatureNode inv: if self.feature.ownerScope = #instance then self.argument->size > 1 implies self.feature.oclIsKindOf(Operation) else self.argument->size > 0 implies self.feature.oclIsKindOf(Operation) endif [C-5-2] If the FeatureNode represents an instance-scope feature, the first argument is a "this" or "self" argument; that is, the object invoking the feature. The convention is enforced by checking that the type of the first argument is the same as the type of the feature. context FeatureNode inv: self.feature.ownerScope = #instance implies self.argument->first.type.allFeatures->includes(self.feature) [C-5-3] If the FeatureNode represents a BehavioralFeature, the number of arguments must be equal to the number of the BehavioralFeature’s parameters, plus one for the “this” parameter if the BehavioralFeature is of instance scope. context FeatureNode inv: self.feature.oclIsKindOf(BehavioralFeature) implies (if self.feature.ownerScope = #instance then self.argument->size = self.feature.oclAsType(BehavioralFeature).parameters->size + 1 else self.argument->size = self.feature.oclAsType(BehavioralFeature).parameters->size endif) CWM org.omg.cwm.foundation ExpressionsModule org.omg.java.cwm.foundation All node types within an expression are derived from the ExpressionNode type. An expression is stored as a collection of instances of the subtypes of ExpressionNode arranged in a hierarchical fashion. The ExpressionNode instance at the top (or “root”) of the hierarchy represents the value of the expression and serves as a starting point for expression evaluation. Refer to the descriptions of the subtypes of ExpressionNode (ElementNode, ConstantNode, and FeatureNode) for additional information about the representation of expressions. One important purpose for providing storage of expressions as a general feature of the CWM is to promote sharing them between tools and to provide a means for recording lineage relationships between components within expressions. Specific details of the implementation of expression operators are left to the implementing tools. When ExpressionNode is used as the type of an Attribute, an instance of the Attribute can contain either an expression tree as described here or a textual representation of the expression in body and language values of in an attribute of type Expression (defined ObjectModel). The expression attribute is provided for the latter usage. To obtain CWM’s sharing and lineage tracking features for elements within an expression, the expression must be represented as an expression hierarcy. umlValue An ElementNode is a node in an expression that references some ModelElement instance. This subclass of ExpressionNode allows an expression to reference any CWM model element that is not a Feature and cannot, therefore, be represented as a FeatureNode. Typically, use of this subclass of ExpressionNode implies that a tool attempting to evaluate the expression will be able to determine if the referenced ModelElement instance is also an instance of some interesting subclass of ModelElement that contains a value of interest in the expression. The FeatureNode class represents ExpressionNode instances that are features (i.e., attributes or operations) of some Classifier instance within the CWM. A FeatureNode with a null OperationArgument association represents either a parameter-less operation or an attribute value obtained from some StructuralFeature instance. The OperationArgument association identifies and orders the actual arguments of an Operation indicated by the FeatureNode end of the association. This association is meaningful only if the FeatureNode references, via the NodeFeature association, a Feature that is also an Operation. The association is not meaningful under other circumstances. The KeysIndexes package depends on the following package: org.omg::CWM::ObjectModel::Core Keys and indexes as means for specifying instances and for identifying alternate sortings of instances are epresented in the CWMFoundation so that they can be shared among the various data models that employ hem. The CWM Foundation defines the base concepts (uniqueness and relationships implemented as keys) pon which more specific key structures can be built by other CWM and tool-specific packages. The concepts of key and index have been placed in the CWM Foundation because they are available in many types of data resources. In the CWM Foundation class and association descriptions that follow, relational model examples are frequently used when discussing the definition and usage of key and index types. This is done because of the wide-spread availability of relational systems and is thought to promote an understanding of the underlying concepts. These concepts, however, are no less applicable to other data models as well. The two central classes for representing the concept of keys are UniqueKey and KeyRelationship. UniqueKey instances correspond to the notion that keys represent the identity of instances -- similar to the relational model’s concept of a primary key or an object model’s concept of an object identity. In contrast, KeyRelationship instancescorrespond to the notion that keys embedded in an instance can be used to determine the identity of other related instances -- similar to the relational model concept of foreign key and the object model concept of a reference. Consequently, UniqueKey and KeyRelationship are best thought of as representing roles that collections of Features of Classifiers play rather than Classifiers describing the internal structure of keys. Representing keys as roles rather than structural entities provides greater flexibility and allows the reuse of Features in multiple keys and in differing relationships to each other. Associations within the KeysIndexes package describe how UniqueKey and KeyRelationship instances describe the roles they play for various Class instances and the StructuralFeature instances they contain. OCL Representation of KeysIndexes Constraints [C-6-1]The isAscending attribute is valid only if the isSorted attribute is True. context IndexedFeature inv: self.isAscending->notEmpty implies self.index.isSorted [C-6-2] A KeyRelationship instance must be owned by one and only one Class instance. context KeyRelationship inv: (self.namespace->size = 1) and self.namespace.oclIsKindOf(Class) [C-6-3] An UniqueKey instance must be owned by one and only one Class instance. context UniqueKey inv: (self.namespace->size = 1) and self.namespace.oclIsKindOf(Class) CWM org.omg.cwm.foundation KeysIndexesModule org.omg.java.cwm.foundation Instances of the Index class represent the ordering of the instances of some other Class, and the Index is said to "span" the Class. Indexes normally have an ordered set of attributes of the Class instance they span that make up the "key" of the index; this set of relationships is represented by the IndexedFeature class that indicates how the attributes are used by the Index instance. The Index class is intended primarily as a starting point for tools that require the notion of an index. The KeyRelationshipFeatures association links KeyRelationship instances with the StructuralFeature instances that comprise their key. The Software Deployment package depends on the following packages: org.omg::CWM::ObjectModel::Core org.omg::CWM::Foundation::BusinessInformation org.omg::CWM::Foundation::TypeMapping The Software Deployment package contains classes to record how the software in a data warehouse is used. A software package is represented as a SoftwareSystem object, which is a subtype of Subsystem. A SoftwareSystem may reference one or more TypeSystems that define the datatypes supported by the SoftwareSystem. The mappings between datatypes in different TypeSystems may be recorded as TypeMappings, as described in the TypeMapping metamodel. The separate components of a software package are each represented as Components that are either owned or imported by the SoftwareSystem. When a SoftwareSystem is installed, the deployment is recorded as a DeployedSoftwareSystem and a set of DeployedComponents. A DeployedComponent represents the deployment of a specific Component on a specific computer. Dependencies between DeployedComponents on the same computer may be documented as Usage dependencies between them. Individual computers are represented as Machine objects, located at a Site. A Site represents a geographical location, which may be recorded at any relevant level of granularity, e.g. a country, a building, or a room in a building. Hierarchical links between Sites at different levels of granularity may be documented. A DataManager is a DeployedComponent such as a DBMS or file management system that provides access to data. It may be associated with one or more data Packages identifying the Schema, Relational Catalog, Files or other data containers that it provides access to. A DataProvider is a DeployedComponent that acts as a client to provide access to data held by a DataManager. For example, an ODBC or JDBC client on a specific Machine would be represented as a DataProvider. A DataProvider may have several ProviderConnections, each identifying a DataManager that may be accessed using the DataProvider. If a DataProvider uses a name for a data Package that is different from the actual name used by the DataManager, a PackageUsage object can be added to record this. As a DataProvider is a subtype of DataManager, it is possible for a DataProvider to access data from a DataManager which is actually a DataProvider acting as a client to yet another DataManager. The model for the Software Deployment package is shown in three diagrams. The first diagram shows the objects related to software deployment, while the second diagram displays the DataManager and DataProvider area of the model. The third diagram shows the inheritance structure for all the classes in the Software Deployment package. OCL Representation of SoftwareDeployment Constraints [C-8-1] A PackageUsage must have a single Package (or subtype of Package) as its supplier context PackageUsage inv: self.supplier->size=1 and self.supplier->at(1).oclIsKindOf(Package) [C-8-2] A ProviderConnection must not associate a DataProvider with itself context ProviderConnection inv: self.dataManager <> self.dataProvider [C-8-3] A Site must not have a containingSite reference that refers to itself. context Site inv: self.containingSite -> forAll (c | c <> self) org.omg.cwm.foundation CWM SoftwareDeploymentModule org.omg.java.cwm.foundation A Site represents a geographical location. It provides a grouping mechanism for a group of machines at the same location. Sites may be documented at different levels of granularity; containment links may be used to record hierarchical relationships between Sites. Identifies the type of the software product. One of the following predefined values should be used if appropriate: OS, DBMS, MDDB, FileSystem, ODBC, JDBC or Application. This is used in conjunction with the type attribute to provide additional information about the type of the software product. For some of the predefined types, suggested subtype values are listed below: For an Operating System product (type OS): AIX, Linux, MVS, NT, Solaris, SunOS, VMS or Windows. For a Database Management System product (type DBMS): DB2, DMS II, IMS, Informix, Oracle, SQLServer or Sybase. For a Multidimensional Database product (type MDDB): Essbase or Express. A DeployedComponent represents the deployment of a Component on a specific Machine. It may represent the deployment of any type of Component. However, if the Component is part of a SoftwareSystem, the DeployedComponent should be part of a DeployedSoftwareSystem. Usage dependencies may be used to document that one DeployedComponent uses another DeployedComponent. A DeployedSoftwareSystem represents a deployment of a SoftwareSystem. Its associated DeployedComponents identify the individual Component deployments that constitute the DeployedSoftwareSystem. These DeployedComponents are not necessarily all deployed on the same Machine. A DataManager represents a DeployedComponent that manages access to data. For example, a deployed DBMS or File Management System would be represented as a DataManager. The DataManager may be associated with one or more data Packages identifying the Schema, Relational Catalog, Files, or other data container that it provides access to. A DataProvider is a deployed software Component that acts as a client to provide access to data that is managed by another product. For instance, a DataProvider might represent a deployed ODBC or JDBC product. The DataProvider may have resourceConnection references to ProviderConnections identifying the DataManagers to which it provides access. A Component represents a physical piece of implementation of a system, including software code (source, binary or executable) or equivalents such as scripts or command files. A Component is a subtype of Classifier, and so may have its own Features, such as Attributes and Operations. Deployment of a Component on a specific Machine is represented as a DeployedComponent. A PackageUsage represents a usage of a Package. It is particularly relevant in situations where a specific usage uses an alternative name for the Package, as this alternative name can be recorded using the packageAlias attribute. For example, if a DataProvider representing an ODBC or JDBC client uses a name for a relational database that is different from the dataPackage name used by the RDBMS server, a PackageUsage that has the relevant ProviderConnection as client and the server’s data Package as supplier can be added. Its packageAlias attribute can be used to record the name by which the data Package is known to the DataProvider. This associates the Package(s) containing the definition of the data with the DataManager that is used to access it. For example, it may be used to associate a Schema, Relational Catalog or File with the DataManager that manages access to it. The TypeMapping package depends on the following packages: org.omg::CWM::ObjectModel::Core The TypeMapping package supports the mapping of data types between different systems. The purpose of these mappings is to indicate data types in different systems that are sufficiently compatible that data values can be interchanged between them. Multiple mappings are allowed between any pair of types and a means of identifying the preferred mapping is provided. OCL Representation of TypeMapping Constraints [C-8-1] The sourceType and targetType references may not refer to the same Classifier instance. context TypeMapping inv: self.sourceType <> self.targetType [C-8-2] A TypeSystem may own only Classifiers and TypeMappings. context TypeSystem inv: self.ownedElement->forAll( e | e.oclIsKindOf(Classifier) or e.oclIsKindOf(TypeMapping)) CWM org.omg.cwm.foundation TypeMappingModule org.omg.java.cwm.foundation TypeMapping instances permit the creation of mappings between data types defined within different environments and are used to indicate data type compatibilities that permit direct assignment of values from one environment (the "source" type) into equivalent values in another environment (the "target" type). For example, an integer field data type in a record-oriented DBMS (the source type) might be mapped to a compatible integer data type in a relational DBMS (the target type). Whereas the actual transfer of data values between environments is accomplished using the CWM’s Transformation package, TypeMapping instances can be used the identify both the permissible and preferred mappings between data types. Value interchange between a pair of data types is considered permissible if a TypeMapping instance is defined for the pair. A TypeMapping instance is considered the preferred mapping if the instance’s isBestMatch attribute has the value true. Typically, there will be one TypeMapping Instance between a pair of data types that is considered the preferred mapping. To promote flexible use of this feature, there is no requirement that a preferred TypeMapping instance must be identified between a pair of data types nor are multiple preferred instances prohibited. In these latter cases, however, the precise semantics are usage-defined. Interchange between data types defined by non-preferred mappings may often function as intended. However, the isLossy boolean may be set to indicate that such interchanges may be subject to validity restrictions in certain circumstances. For example, it may be valid to move data values from a 32-bit integer data type to a 16-bit integer data type as long as the actual values in the 32-bit underlying data type do not exceed the range permitted for 16-bit integers. The CWM Foundation leaves the understanding and handling of such differences to individual tools. If such differences must be modeled, consider using the CWM Transformation package to filter data values during interchange. TypeMapping instances are unidirectional, so two instances are required to show that a data type pair can be mutually interchanged between environments. Instances of the TypeSystem class collect together the data types (subclasses of Classifier) defined by a software system and the TypeMapping instances defining how they are mapped to data types in other TypeSystems. TypeMapping instances collected by a TypeSystem instance include both those in which the software system’s data types act as sources and as targets of mappings. Classifiers and TapeMappings are maintained in a single collection via the ElementOwnership association but can be distinguished by their respective types. Because it is a Package, a TypeSystem can also serve to collect together the Classifier instances for a particular software system. The MappingTarget association indicates the exposed data type for a particular TypeMapping instance. The Relational package describes data accessible through a relational interface such as a native RDBMS, ODBC, or JDBC. The Relational package is based on the [SQL] standard section concerning RDBMS catalogs. The scope of the top level container, Catalog, is intended to cover all the tables a user can use in a single statement. A catalog is also the unit which is managed by a data resource. A catalog contains schemas which themselves contain tables. Tables are made of columns which have an associated data type. The Relational package uses constructs in the ObjectModel package to describe the object extensions added to SQL by the [SQL] standards. The Relational package also addresses the issues of indexing, primary keys and foreign keys by extending the corresponding concepts from the Foundation packages. The Relational package depends on the following packages: org.omg::CWM::ObjectModel::Behavioral org.omg::CWM::ObjectModel::Core org.omg::CWM::ObjectModel::Instance org.omg::CWM::Foundation::DataTypes org.omg::CWM::Foundation::KeysIndexes The Relational package references the ObjectModel and Foundation packages. OCL Representation of Relational Constraints [C-1] temporaryScope is valid only if the isTemporary is True. context Tabl e inv: self.temporaryScope.notEmpty implies self.isTemporary=True [C-2] checkOption is valid only if isReadOnly is False. context View inv: self.checkOption implies self.isReadOnly=False [C-3] scale is valid only if precision is specified. context Column inv: self.scale.nonEmpty implies self.precision.notEmpty CWMRDB org.omg.cwm.resource RelationalModule org.omg.java.cwm.resource Used in Trigger. It indicates if the trigger is called once per statement execution or before/after each row of the table is modified. Used in Triggers. It indicates if the trigger activity is run before or after the statement or row is modified. Used in Foreign Keys Indicates if the Foreign Key validation should be deferred to the end of the transaction or executed immadiately at the end of the statement. This is the value used at the beginning of a transaction. It can be changed within a transaction. Used in Trigger. Indicates what types of events are using the current Trigger. Used in Column. Indicates if a Column may contain null values. Used in Procedure. Indicates if the Procedure is a Function or a Procedure Used in Foreign Key. It indicates the action taken on the row containing a foreign key value, when the primary key value referenced is deleted or updated. The name of the default character set used for the values in the column. This field applies only to columns whose datatype is a character string. RelationalColumnSet CwmColumnSet A catalogued set of columns, which may be Table or View. Note for typed tables: It is assumed that the typed table will own a set of columns conforming to the type they are OF. This set of columns allows the manipulation of the table by products which ignore this [SQL] extension. It also allows the columns of type REF, to be copied to a column with a SCOPE reference. A view is a non-materialized set of rows, defined by the associated query. The query associated with the View. The query result must match the set of Columns associated with the View (in parent class ColumnSet) The length of fixed length character or byte strings. Maximum length if length is variable. Indicates if null values are valid in this column. Note: Default values for Column data are provided in initialValue in the UML Attribute class (the class from which the Column class inherits). The name of the collation sequence used to sort the data values in the column. This applies only to columns whose datatype is a form of character string. The name of the character set used for the values in the column. This field applies only to columns whose datatype is a character string. A Foreign Key associates columns from one table with columns of another table. Associates an index with its columns. This is really an association (link) class. It is associated with one index and one column. CwmRowSet The Record package covers the basic concept of a record and its structure. The package takes a broad view of the notion of record, including both traditional data records such as those stored in files and databases, as well as programming language structured data types. In fact, the concepts described here can be used as a foundation for extension packages describing any information structure that is fundamentally hierarchical, or "nested," in nature such as documents, questionnaires, and organizational structures. The Record package depends on the following packages: org.omg::CWM::ObjectModel::Core org.omg::CWM::ObjectModel::Instance Because of the antiquity of many record-based models, individual system implementations employing record models may have unusual features (such as occurs-depending arrays, various COBOL rename/remapping semantics, etc.) that are not shared with other implementations. When such features are limited to single implementations or languages, they have been purposefully left out of the Record metamodel. Rather, unusual features of this sort should be placed into extension packages designed to meet the needs of those implementations or languages. For example, record structuring features endemic to the COBOL language have been placed in the COBOLData metamodel in the CWMX package described in Volume 2 and do not appear here. In this way, COBOL-only features do not burden other record oriented implementations unnecessarily. OCL Representation of Record Constraints [C-1] The owner of a Field and the type of a Field may not refer to the same Classifier instance. context Field inv: self.owner <> self.type [C-2] The scale attribute is valid only if the precision attribute is specified. context Field inv: self.scale->notEmpty implies self.precision->notEmpty [C-3] The precision attribute is valid only if the length attribute is not specified. context Field inv: self.precision->notEmpty implies self.length->isEmpty::filely one CWMREC org.omg.cwm.resource RecordModule org.omg.java.cwm.resource A RecordDef is an ordered collection of Fields representing the structure of a Record. Examples of RecordDefs include definitions of language-specific data structures database records IMS segments The internal structure of a RecordDef instance is constructed by adding Field instances as features (using the ElementOwnership association) and pointing each Field instance’s inherited type reference to the Classifier instance representing the Field’s data type. The referenced instance can be either a primitive data type (an instance of DataType, such as "integer") or a structured data type (such as a Group instance). Refer to the example for more details of the relationships between RecordDefs, Fields, Records, and their values. Instances of FixeOffsetField represent fields that have a fixed location in a record. FixedOffsetFields can be used as a foundation for recording details of physical record layouts and as a means of representing the internal structure of undiscriminated (ie, C-type) unions. A RecordFile is the definition of a file. It may have one or more RecordDefs, defining the structure of the records in the file. Each of these RecordDefs defines a valid structure for records in the file. Subclasses of RecordFile in extensions to support specific languages and systems may be used to represent specific types of files such as COBOL CopyLib files and C-language header files. Physical deployments of a RecordFile can be found via the DataManagerDataPackage association in the SoftwareDeployment package . CwmRecordSet The CWM Multidimensional metamodel is a generic representation of a multidimensional database. Multidimensional databases are OLAP databases that are directly implemented by multidimensional database systems. In a multidimensional database, key OLAP constructs (dimensions, hierarchies, etc.) are represented by the internal data structures of a ultidimensional database server, and common OLAP operations (consolidation, drill-down, etc.) are performed by the server acting on those data structures. Multidimensional databases are often classified as "physical OLAP" or "MOLAP" (memory-based OLAP) databases. Multidimensional databases offer enhanced performance and flexibility over OLAP systems that simulate multidimensional functionality using other technologies (e.g., relational database or spreadsheet): Performance: Multidimensional databases provide rapid consolidation times and formula calculations, and consistent query response times regardless of query complexity. This is accomplished, in part, through the use of efficient cell storage techniques and highly-optimized index paths. Flexibility: The specification and use of multidimensional schemas and queries (including the design of cubes, dimensions, hierarchies, member formulas, the manipulation of query result sets, etc.) can be accomplished in a relatively straight-forward manner, since the server directly supports (and exposes) the multidimensional paradigm. The CWM Multidimensional metamodel does not attempt to provide a complete representation of all aspects of commercially available, multidimensional databases. Unlike relational database management systems, multidimensional databases tend to be proprietary in structure, and there are no published, widely agreed upon, standard representations of the logical schema of a multidimensional database. Therefore, the CWM Multidimensional Database metamodel is oriented toward complete generality of specification. Tool-specific extensions to the metamodel are relatively easy to formulate, and several examples are provided in Volume 2, Extensions, of the CWM Specification. The Multidimensional package depends on the following packages: org.omg::CWM::ObjectModel::Core org.omg::CWM::ObjectModel::Instance The major classes and associations of the Multidimensional metamodel are shown in Figure 11-1. Schema is the container of all elements comprising a Multidimensional model. It also represents the logical unit of deployment of a Multidimensional database instance. Dimension represents a physical dimension in a Multidimensional database. Whereas the OLAP metamodel defines “dimension” as a purely conceptual entity, this Dimension represents the dimension object exposed by the programming model of a Multidimensional database. A Dimension may reference other instances of Dimension to form arbitrarily complex dimensional structures (e.g., hierarchies with varying levels of detail). DimensionedObject represents an attribute of Dimension. Examples of DimensionedObjects include measures (variables), formulas, consolidation functions, member alias names, etc. DimensionedObjects are contained by the Schema and referenced by the Dimensions that use them. MemberSet represents the collection of Members associated with an instance of Dimension, and MemberValue represents an instance value of a Member. MemberSet, Member and MemberValue enable the specification and interchange of both M1-level Multidimensional models and associated M0-level data values. Figure 11-2 illustrates the inheritance of the Multidimensional classes from metaclasses of the Object Model. OCL Representation of Multidimensional Constraints [C-1] A Dimension may not reference itself as a component, nor as a composite. context Dimension inv: self.component->excludes( self ) inv: self.composite->excludes( self ) The transitive closure of components of an instance of Dimension must not include the Dimension instance. The transitive closure of composites of an instance of Dimension must not include the Dimension instance. CWMMDB org.omg.cwm.resource MultidimensionalModule org.omg.java.cwm.resource CwmDimension CwmDimension CwmMemberSet XML is rapidly becoming a very important type of data resource, especially in the Internet environment. On the one hand, HTML is evolving to be XML-compliant; in the near future, all HTML documents can be expected to become valid XML documents. On the other hand, XML is quickly becoming the standard format for interchange of data and/or metadata (e.g., XMI). Therefore, XML documents (or streams) representing data and/or metadata can be expected to appear everywhere. The XML package contains classes and associations that represent common metadata describing XML data resources. It is based on XML 1.0 [XML]. XML Schema is an ongoing activity in the W3C. As future standards are adopted by the W3C on XML Schema, this package will be revised and extended accordingly. This section provides a description of the main features of the XML package. An XML schema contains a set of definitions and declarations, in the form of XML element type definitions. An XML element type may contain a set of XML attributes and/or a content model. An attribute can have one of the following defaults: required, implied, default, or fixed. The content model can be one of the following types: empty, any, mixed, or element. Except for the empty content model, a content model consists of constituent parts, particularly element type references. The allowed occurrence of the constituents can be one of the following types: one, zero or one, zero or more, or one or more. An any content model consists of any element types. A mixed content model consists of character data and specified element type references. An element content model consists of specified element type references and/or element content models. An element content model can be one of the following types: choice or sequence. The XML package depends on the following packages: omg.org::CWM::ObjectModel::Core omg.org::CWM::ObjectModel::Instance omg.org::CWM::Foundation::DataTypes The metamodel diagram for the XML package is split into two parts. The first diagram shows the XML classes and associations, while the second shows the inheritance hierarchy. OCL Representation of XML Constraints None CWMXML org.omg.cwm.resource XMLModule org.omg.java.cwm.resource xmlAttribute XmlAttribute XmlAttribute xml_ XmlElement XmlElement A key aspect of data warehousing is to extract, transform, and load data from operational resources to a data warehouse or data mart for analysis. Extraction, transformation, and loading can all be characterized as transformations. In fact, whenever data needs to be converted from one form to another in data warehousing, whether for storage, retrieval, or presentation purposes, transformations are involved. Transformation, therefore, is central to data warehousing. The Transformation package contains classes and associations that represent common transformation metadata used in data warehousing. It covers basic transformations among all types of data sources and targets: object-oriented, relational, record, multidimensional, XML, OLAP, and data mining. The Transformation package is designed to enable interchange of common metadata about transformation tools and activities. Specifically it is designed to: 1. Relate a transformation with its data sources and targets. These data sources and targets can be of any type (e.g., object-oriented, relational) or granularity (e.g., class, attribute, table, column). They can be persistent (e.g., stored in a relational database) or transient. 2. Accommodate both "black box" and "white box" transformations. In the case of "black box" transformations, data sources and targets are related to a transformation and to each other at a coarse-grain level. We know the data sources and targets are related through the transformation, but we don’t know how a specific piece of a data source is related to a specific piece of a data target. In the case of "white box" transformations, however, data sources and targets are related to a transformation and to each other at a fine-grain level. We know exactly how a specific piece of a data source is related to a specific piece of a data target through a specific part of the transformation. 3. Allow grouping of transformations into logical units. At the functional level, a logical unit defines a single unit of work, within which all transformations must be executed and completed together. At the execution level, logical units can be used to define the execution grouping and sequencing (either explicitly through precedence constraints or implicitly through data dependencies). A key consideration here is that both parallel and sequential executions (or a combination of both) can be accommodated. The Transformation package assumes the existence of the following packages that represent types of potential data sources or targets: ObjectModel (object-oriented), Relational, Record, Multidimensional, XML, OLAP, and Data Mining. The Transformation package is an integral part of the following packages: OLAP, Data Mining, Warehouse Process, and Warehouse Operation. In particular, the Transformation and Warehouse Process packages together provide metamodel constructs that facilitate scheduling and execution in data warehousing, and the Transformation and Warehouse Operation packages together provide metamodel constructs that enable data lineage in data warehousing. This section provides a description of the main features of the Transformation package, as illustrated in Figure 13-1 (see specification document for figure). A transformation transforms a set of source objects into a set of target objects. The elements of a data object set can be any ObjectModel model elements, but typically are tables, columns, or model elements that represent transient, in memory, objects. Data object sets can be both sources and targets for different transformations. In particular, a given data object set can be the target of one transformation and the source of one or more transformations within the same logical unit. This is often the case with transformation that produce and consume temporary objects. Transformations allow a wide range of types (and granularity) to be defined for their data sources and targets. For example, the source type of a transformation can be an XML schema while the target type is a column, if the transformation deals with storing an XML document in a column of a relational database. More typically, the source types of a transformation are classes and attributes while the target types are tables and columns, or vice versa, if the transformation deals with converting object data into relational data, or vice versa. Existing programs, queries, or rules (in fact, any ObjectModel operations) can be used to perform a transformation by associating them with the transformation using the transformation use dependency. Transformations can be grouped into logical units. At the functional level, they are grouped into transformation tasks, each of which defines a set of transformations that must be executed and completed together - a logical unit of work. At the execution level, transformation steps are used to coordinate the flow of control between transformation tasks, with each transformation step executing a single transformation task. The transformation steps are further grouped into transformation activities. Within each transformation activity, the execution sequence of its transformation steps are defined either explicitly by using the step precedence dependency or precedence constraint, or implicitly through data dependency. There are certain "white-box" transformations which are commonly used and which can relate data sources and targets to a transformation and to each other at a detailed level. These transformations are convenient to use and they provide data lineage at a fine-grain level. One such transformation is the transformation map which consists of a set of classifier maps that in turn consists of a set of feature maps or classifier-feature maps. The other is the transformation tree, which represents a transformation as an unary or binary expression tree. For an example usage of the transformation map, please see Figure 13-4. The Transformation package depends on the following packages: omg.org::CWM::ObjectModel::Behavioral omg.org::CWM::ObjectModel::Core omg.org::CWM::Foundation::Expressions omg.org::CWM::Foundation::SoftwareDeployment The CWM uses packages to control complexity and create groupings of logically interrelated classes and associations. The Transformation package is one such package. Within the Transformation package itself, however, the definition of subpackages is purposefully left out to reduce the length and complexity of the fully qualified names of Transformation classes and associations. There are, however, several groupings of classes and associations that form related sets of functionality within the Transformation package. Although separate subpackages have not been created for these functional areas, their identification improves the understandability of the Transformation package. The Transformation package contains metamodel elements that support the following functions: 1. Transformation and data lineage. These classes and associations deal with transformations and their sources, targets, constraints, and operations. 2. Transformation grouping and execution. These classes and associations deal with grouping of transformations to form logical units and to define execution sequences. 3. Specialized transformations. These classes and associations define specialized, "white box", transformations that are commonly used in data warehousing. The specific Transformation classes and associations supporting each functional area are delineated in Table 13-1 (see specification document for table). The metamodel diagram for the Transformation package is split into four parts. The first two diagrams show the Transformation classes and associations, while the last two show the inheritance hierarchy. 13.5 OCL Representation of Transformation Constraints [C-1] The preceding step and succeeding step of StepPrecedence must not be the same. context StepPrecedence inv: self.precedingStep->forAll( p | self.succeedingStep->forAll( q | p <> q ) ) [C-2] A TransformationTask may not be its own inverse task. Identifies the Transformation context TransformationTask inv: self.inverseTask->forAll( p | p <> self ) [C-3] A TransformationTask may not be its own original task. context TransformationTask inv: self.originalTask->forAll( p | p <> self ) [C-4] The ClassifierMapToCFMap association is derived from the Namespace-ModelElement association. All ownedElement ends of the association must be ClassifierFeatureMaps. context ClassifierMapToCFMap inv Namespace-ModelElement.allInstances.select( ownedElement.oclIsKindOf( ClassifierFeatureMap ) ) [C-5] The ClassifierMapToFeatureMap association is derived from the Namespace-ModelElement association. All ownedElement ends of the association must be FeatureMaps. context ClassifierMapToFeatureMap inv Namespace-ModelElement.allInstances.select( ownedElement.oclIsKindOf( FeatureMap ) ) CWMTFM org.omg.cwm.analysis TransformationModule org.omg.java.cwm.analysis This represents a transformation from a set of sources to a set of targets. If a model already exists for the object that performs the Transformation, then the model can be related to the Transformation via a TransformationUse dependency. This represents a set of Transformations that must be executed together as a single task (logical unit). A TransformationTask may have an inverse task. A transformation task that maps a source set "A" into a target set "B" can be reversed by the inverse transformation task that maps "B" into "A". This represents the usage of a TransformationTask in a TransformationActivity. A TransformationStep relates to one TransformationTask. TransformationSteps are used to coordinate the flow of control between their TransformationTasks. Ordering of the TransformationSteps are defined using the PrecedenceConstrainedBy dependency. This represents a transformation activity. Each TransformationActivity consists of a set of TransformationSteps. tfm_ This association relates a ClassifierMap to its FeatureMaps. This association is derived from the Namespace-ModelElement association. All ownedElement ends of the association must be FeatureMaps. [C-5] This association relates a ClassifierMap to its ClassifierFeatureMaps. This association is derived from the Namespace-ModelElement association. All ownedElement ends of the association must be ClassifierFeatureMaps. [C-4] Online Analytical Processing (OLAP) is a class of analytic application software that exposes business data in a multidimensional format. This multidimensional format usually includes the consolidation of data drawn from multiple and diverse information sources. Unlike more traditionally structured representations (e.g., the tabular format of a relational database), the multidimensional orientation is a more natural expression of the way business enterprises view their strategic data. For example, an analyst might use an OLAP application to examine total sales revenue by product and geographic region over time, or, perhaps, compare sales margins for the same fiscal periods of two consecutive years. The ultimate objective of OLAP is the efficient construction of analytical models that transform raw business data into strategic business insight. There are many ways to implement OLAP. Most OLAP systems are constructed using OLAP server tools that enable logical OLAP structures to be built on top of a variety of physical database systems, such as relational or native multidimensional databases. The following features are generally found in most OLAP systems: Multidimensional representation of business data. Upward consolidation of multidimensional data in a hierarchical manner, possibly with the application of specialized processing rules. The ability to navigate a hierarchy from a consolidated value to the lower level values forming it. Support for time-series analysis; i.e., OLAP users are generally concerned with data and consolidations at specific points in time -- By date, week, quarter, etc. Support for modeling and scenario analysis -- A user should be able to apply arbitrary "what-if" analyses to a result set without affecting the stored information. Consistent response times, regardless of how queries are formulated -- This is critical for effective analysis and modeling. OLAP applications integrate well into the data warehousing environment, because a data warehouse provides relatively clean and stable data stores to drive the OLAP application. These data stores are usually maintained in relational tables that can be read directly by OLAP tools or loaded into OLAP servers. These relational tables are often structured in a manner that reveals the inherent dimensionality of the data (such as the ubiquitous Star and Snowflake schemas). Also, the data transformation and mapping services provided by a data warehouse can be used to supply OLAP systems with both metadata and data. Transformation-related metadata can be used to track the lineage of consolidated OLAP data back to its various sources. The primary objectives of the CWM OLAP package are: Define a metamodel of essential OLAP concepts common to most OLAP systems. Provide a facility whereby instances of the OLAP metamodel are mapped to deployment-capable structures (i.e., models of physical data resources, such as the CWM Relational and Multidimensional packages). Ensure that navigation through the logical OLAP model hierarchy and its various resource models is always performed in a uniform manner (i.e., by defining a standard usage of the CWM Transformation package as a means of implementing these mappings). Leverage services provided by other CWM packages, where appropriate (e.g., use the CWM Foundation package to supply a standard representation of expressions). The OLAP package depends on the following packages: org.omg::CWM::ObjectModel::Core org.omg::CWM::Foundation::Expressions org.omg::CWM::Analysis::Transformation The major classes and associations of the OLAP metamodel are shown in Figure 14-1. Schema is the logical container of all elements comprising an OLAP model. It is the root element of the model hierarchy and marks the entry point for navigating OLAP models. A Schema contains Dimensions and Cubes. A Dimension is an ordinate within a multidimensional structure and consists of a list of unique values (i.e., members) that share a common semantic meaning within the domain being modeled. Each member designates a unique position along its ordinate. A Cube is a collection of analytic values (i.e., measures) that share the same dimensionality. This dimensionality is specified by a set of unique Dimensions from the Schema. Each unique combination of members in the Cartesian product of the Cube’s Dimensions identifies precisely one data cell within a multidimensional structure. CubeDimensionAssociation relates a Cube to its defining Dimensions. Features relevant to Cube-Dimension relationships (e.g., calcHierarchy) are exposed by this class. A Dimension has zero or more Hierarchies. A Hierarchy is an organizational structure that describes a traversal pattern through a Dimension, based on parent/child relationships between members of a Dimension. Hierarchies are used to define both navigational and consolidation/computational paths through the Dimension (i.e., a value associated with a child member is aggregated by one or more parents). For example, a Time Dimension with a base periodicity of days might have a Hierarchy specifying the consolidation of days into weeks, weeks into months, months into quarters, and quarters into years. A specific Hierarchy may be designated as the default Hierarchy for display purposes (e.g., a user interface that displays the Dimension as a hierarchical tree of members). CubeDimensionAssociation can also identify a particular Hierarchy as the default Hierarchy for consolidation calculations performed on the Cube. MemberSelection models mechanisms capable of partitioning a Dimension’s collection of members. For example, consider a Geography Dimension with members representing cities, states, and regions. An OLAP client interested specifically in cities might define an instance of MemberSelection that extracts the city members. CubeRegion models a sub-unit of a Cube that is of the same dimensionality as the Cube itself. Each "dimension" of a CubeRegion is represented by a MemberSelection of the corresponding Dimension of the Cube. Each MemberSelection may define some subset of its Dimension’s members. CubeRegions are used to implement Cubes. A Cube may be realized by a set of CubeRegions that map portions of the logical Cube to physical data sources. The MemberSelections defining CubeRegions can also be grouped together via MemberSelectionGroups, enabling the definition of CubeRegions with specific semantics. For example, one can specify a CubeRegion containing only the "input level" data cells of a Cube. A CubeRegion may own any number of CubeDeployments. CubeDeployment is a metaclass that represents an implementation strategy for a multidimensional structure. The ordering of the CubeDeployment classes may optionally be given some implementation-specific meaning (e.g., desired order of selection of several possible deployment strategies, based on optimization considerations). The OLAP metamodel defines two special types of Dimension: Time and Measure. A Time Dimension provides a means of representing time-series data within a multidimensional structure. The members of a Time Dimension usually define some base periodicity (e.g., days of the week). The implementation of a Time Dimension might provide support for advanced "time-intelligent" functionality, such as the ability to automatically convert between different periodicities and calendars. The members of a Measure Dimension describe the meaning of the analytic values stored in each data cell of a multidimensional structure. For example, an OLAP application may define Sales, Quantity and Weight as its measures. In this case, each data cell within the Cube stores three values, with each value corresponding to one of the three measures. A measure may have an associated data type. For example, Sales might be of a monetary type, Quantity an integer, and Weight a real number. The OLAP metamodel specifies two subclasses of Hierarchy: LevelBasedHierarchy and ValueBasedHierarchy. LevelBasedHierarchy describes hierarchical relationships between specific levels of a Dimension. LevelBasedHierarchy is used to model both "pure level" hierarchies (e.g., dimension-level tables) and "mixed" hierarchies (i.e., levels plus linked nodes). Dimensional levels are modeled by the Level class, a subclass of MemberSelection that partitions a Dimension’s members into disjoint subsets, each representing a distinct level. For example, the Geography Dimension cited earlier contains members representing cities, states, and regions, such as "Stamford", "Connecticut", and "NorthEast". It might also contain a single member called "USA" representing all regions of the United States. Therefore, the Geography Dimension could have four Levels named "City", "State", 'Region", and "ALL", respectively. Each Level specifies the subset of members belonging to it: All cities belong to the "City" Level, all states belong to the "State" Level, all regions belong to the "Region" Level, and the single "USA" member belongs to the "ALL" Level. When used in the definition of a consolidation path, the meaning of "level" is quite clear: Members occupying a given Level consolidate into the next higher Level (e.g., City rolls up into State, State into Region, and Region into ALL). LevelBasedHierarchy contains an ordered collection of HierarchyLevelAssocations that defines the natural hierarchy of the Dimension. The ordering defines the hierarchical structure in top-down fashion (i.e., the "first" HierarchyLevelAssociation in the ordered collection represents the upper-most level of the dimensional hierarchy). A HierarchyLevelAssociation may own any number of DimensionDeployments. DimensionDeployment is a metaclass that represents an implementation strategy for hierarchical Dimensions. The ordering of the DimensionDeployment classes may optionally be given an implementation-specific meaning (e.g., desired order of selection of several possible deployment strategies, based on optimization considerations). A ValueBasedHierarchy defines a hierarchical ordering of members in which the concept of level has little or no significance. Instead, the topological structure of the hierarchy conveys meaning. ValueBasedHierarchies are often used to model situations where members are classified or ranked according to their distance from a common root member (e.g., an organizational chart of a corporation). In this case, each member of the hierarchy has some specific "metric" or "value" associated it with it. ValueBasedHierarchy can be used to model pure "linked node" hierarchies (e.g., asymmetric hierarchical graphs or parent-child tables). As with LevelBasedHierarchy, ValueBasedHierarchy also has an ordered collection of dimensionDeployments, where the ordering semantics are left to implementations to define. Figure 14-3 illustrates how classes of the OLAP metamodel inherit from the CWM Object Model. Two classes requiring further explanation are: Measure: A subclass of Attribute that describes the meaning of values stored in the data cells of a multidimensional structure. Different OLAP models often give different interpretations to the term "measure". In a relational Star Schema, individual measures might be represented by non-key columns of a Fact table (e.g., "Sales" and "Quantity" columns). In this case, measure may be an attribute of a Cube or CubeRegion that models the Fact table. On the other hand, measures can also be represented by members of a Measure Dimension. A Fact table supporting this representation has a single Measure column with column values consisting of the members "Sales" and "Quantity", and a single "value" column (i.e., an implicit data dimension) storing the corresponding measure values. A similar notion of Measure Dimension is used in modeling pure hypercube representations of multidimensional servers. Thus, the concept of measure can be represented either as a Dimenson or as an Attribute, depending on the type of OLAP system being modeled. Coded Level: A subclass of Level that assigns a unique encoding, or label, to each of its members. CodedLevel is not essential to the OLAP metamodel, but is provided as a helper class for certain applications that might benefit from the ability of OLAP systems to structure data hierarchically. For example, CodedLevel could be used to model systems of nomenclature or classification. The CWM OLAP metamodel describes logical models of OLAP systems, but does not directly specify how an OLAP system is physically deployed. Modeling the deployment of an OLAP system requires mapping instances of OLAP metaclasses to instances of other CWM metaclasses representing physical resources (e.g., mapping an OLAP Dimension to a Relational Table). This approach offers several advantages: The status of the OLAP metamodel as a conceptual model is preserved by this level of indirection. When using OLAP, a client may perceive to be working directly with OLAP objects, but the actual implementation of those objects is hidden from the client. For example, a client may view a member as a value of a Dimension, but whether that member value comes from a row of a relational table, or from a cell in a multidimensional database, is usually not obvious to the client. On the other hand, if a client needs to determine how a logical OLAP structure is physically realized, the metadata describing this mapping is fully available (assuming that the implementation allows the client to drill-down through the metadata). The possibility of defining mappings based on expressions means that the amount of metadata required to describe large models (e.g., Dimensions containing large collections of members) can be kept within reasonable bounds. It is generally more efficient to provide expressions that specify where large metadata sets reside, how to connect to them, and how to map their contents, rather than representing them directly as part of the metadata content. All of the OLAP metaclasses are potential candidates for such deployment mappings. In addition, some OLAP models may also define mappings between several OLAP metaclass instances, forming a natural hierarchy of logical objects (e.g., Dimension Attributes are mapped to Level Attributes which, in turn, are mapped to Table Columns). The CWM Transformation package is used as the primary means of describing these mappings. A modeler constructing an OLAP model based on CWM will generally define instances of the TransformationMap metaclass to link logical OLAP objects together, and to link those logical objects to other objects representing their physical data sources. StructureMap is a subclass of TransformationMap that models structure-oriented transformation mappings (i.e., member identity and hierarchical structure). This type of transformation mapping needs to be connected to the OLAP metamodel in a very specific way (according to Level and Hierarchy), so the StructureMap subclass is defined to make these associations explicit. Two specific usages of StructureMap are defined: ListOfValues, which maps attributes identifying members residing at a specific Level, or at a specific Level within a particular Hierarchy, and ImmediateParent, which maps attributes identifying the hierarchical parent(s) of the members. On the other hand, relatively simple TransformationMaps can be defined within any OLAP model to represent attribute-oriented transformations (e.g., mapping Dimension Attributes to Table Columns that store attribute values). ContentMap is a subclass of TransformationMap that models content-oriented transformaton mappings (i.e., cell data or measure values). For example, an instance of ContentMap might be used to map each of a CubeRegion’s Measures to Columns of an underlying Fact Table. Note that, in either case (structural mapping or content mapping), the traversal patterns used by any CWM OLAP implementation are always the same, since both deployment mappings are based on the same usage of CWM TransformationMaps. In addition to representing structural mappings, instances of TransformationMap and its subclasses are also capable of storing implementation-dependent functions or procedures that yield the instance values associated with mapped model elements. For example, a "list of values" StructureMap might store an SQL statement such as "select memberName from Product where productFamily = ’consumerElectronics’ ", as the value of its formula attribute. Figure 14-4 illustrates the CWM metaclasses and associations that describe deployment mappings between logical OLAP models and physical resource models. Note that it is possible to combine both Cube (content) and Dimension (structure) deployments together within the context of a single OLAP Schema (via the DeploymentGroup metaclass). Thus, an OLAP Schema can have several possible deployments that users may select based on implementation-specific considerations (e.g., physical optimizations). OCL Representation of OLAP Constraints [C-1] Ensure that the Dimensions defining a Cube are unique. context Cube inv: self.cubeDimensionAssociation->forAll( c1, c2 | c1 <> c2 implies c1.dimension <> c2.dimension ) [C-2] A Cube without CubeRegions cannot be mapped to a deployment structure (i.e., physical source of data). context Cube inv: self.cubeRegion->isEmpty implies self.isVirtual = true [C-3] If a calcHierarchy is defined, it must be a Hierarchy owned by the Dimension referenced by the CubeDimensionAssociation. context CubeDimensionAssociation inv: self.calcHierarchy->notEmpty implies self.calcHierarchy.dimension = self.dimension [C-4] A "fully realized" CubeRegion has no MemberSelectionGroups (and hence, no MemberSelections). context CubeRegion inv: self.isFullyRealized implies self.memberSelectionGroup->isEmpty [C-5] A CubeRegion defined by MemberSelections must have, for each Dimension of its owning Cube, a corresponding MemberSelection within each of its MemberSelectionGroups. context CubeRegion inv: self.memberSelectionGroup->notEmpty implies self.cube.cubeDimensionAssociation->forAll( d | self.memberSelectionGroup->forAll( g | g.memberSelection->exists( m | m.dimension = d.dimension ) ) ) [C-6] A CubeRegion defined by MemberSelections must have, within each MemberSelectionGroup, a MemberSelection corresponding to each Dimension of its owning Cube. context CubeRegion inv: self.memberSelectionGroup->notEmpty implies self.memberSelectionGroup->forAll( g | g.memberSelection->forAll( m | self.cube.cubeDimensionAssociation->exists( d | d.dimension = m.dimension ) ) ) [C-7] A Dimension may be a Time Dimension, a Measure Dimension, or neither, but never both types at the same time. context Dimension inv: not ( self.isTime and self.isMeasure ) [C-8] The default display Hierarchy (if defined) must be one of the Hierarchies owned by the Dimension. context Dimension inv: self.displayDefault->notEmpty implies self.hierarchy->includes( self.displayDefault ) [C-9] An instance of DimensionDeployment must be referenced exclusively by either a HierarchyLevelAssociation or a ValueBasedHierarchy. context DimensionDeployment inv: self.hierarchyLevelAssociation->isEmpty xor self.valueBasedHierarchy->isEmpty [C-10] Within a DimensionDeployment, an "immediate parent" StructureMap must always have an associated and distinct "list of values" StructureMap. context DimensionDeployment inv: self.immediateParent->notEmpty implies ( self.listOfValues->notEmpty and self.listOfValues <> self.immediateParent ) [C-11] A StructureMap referenced as a "list of values" StructureMap must not reside outside of the DimensionDeployment’s collection of StructureMaps. context DimensionDeployment inv: self.listOfValues->notEmpty implies self.structureMap->includes( self.listOfValues ) [C-12] A StructureMap referenced as an "immediate parent" StructureMap must not reside outside of the DimensionDeployment’s collection of StructureMaps. context DimensionDeployment inv: self.immediateParent->notEmpty implies self.structureMap->includes( self.immediateParent ) [C-13] The currentLevel of each HierarchyLevelAssociation must refer to a Level owned by the Dimension of the LevelBasedHierarchy containing the HierarchyLevelAssociation. context LevelBasedHierarchy inv: self.hierarchyLevelAssociation->notEmpty implies self.hierarchyLevelAssociation->forAll( h | self.dimension.memberSelection ->select( oclType = Olap::Level )->includes( h.currentLevel ) ) [C-14] No two HierarchyLevelAssociations may designate the same Level instance as their "current level". context LevelBasedHierarchy inv: self.hierarchyLevelAssociation->forAll( h1, h2 | h1 <> h2 implies h1.currentLevel <> h2.currentLevel ) CWMOLAP org.omg.cwm.analysis OlapModule org.omg.java.cwm.analysis A Cube is a collection of analytic values (i.e., measures) that share the same dimensionality. This dimensionality is specified by a set of unique Dimensions from the Schema. Each unique combination of members in the Cartesian product of the Cube’s Dimensions identifies precisely one data cell within a multidimensional structure. Synonyms: Multidimensional Array, Hypercube, Hypervolume. CubeDimensionAssociation relates a Cube to the Dimensions that define it. Features relevant to Cube-Dimension relationships (e.g., calcHierarchy) are exposed by this class. CubeRegion models a sub-unit of a Cube of the same dimensionality as the Cube itself, with each Dimension optionally subsetted in its list of members. When mapped to its physical source, a CubeRegion contains data cells identified by the member combinations of the Cartesian product of the CubeRegion's associated Dimensions and Measures. The relative ordering of CubeDeployment classes optionally implies a desired order of selection of the CubeDeployments, based on implementation-specific considerations (e.g., optimized access of aggregate data). Synonyms: Sub-Cube, Partition, Slice, Region, Area. Misc. notes: 1. A CubeRegion is not a Cube, and a Cube is not a CubeRegion. 2. A Cube has a Measure and CubeRegion may have a corresponding measure (Measures are Attributes). 3. A Cube may or may not have CubeRegions. 4. If a Cube does not have a CubeRegion, then it's not physically mapped (it's virtual). All physical mapping is based on the CubeRegion , not the Cube. DeploymentGroup represents a logical grouping of model elements defining a single, complete deployment of an instance of Olap Schema (i.e., CubeDeployments and DimensionDeployments). The usage of DeploymentGroup is as follows: A user may specify a particular DeploymentGroup as the session-wide, default deployment for all metadata queries performed throughout the session. Alternatively, for queries involving some particular deployed object (e.g., a Cube or a Dimension), the user may be asked to choose from a list of deployments. This either becomes the default deployment for the remainder of the session, or the user may continue to be asked to specify a deployment for each subsequent query against deployed objects. A Dimension is an ordinate within a multidimensional structure, and consists of an ordered list of values (i.e., members) that share a common semantic meaning within the domain being modeled. Each member designates a unique position along its ordinate. Typical Dimensions are: Time, Product, Geography, Scenario (e.g., actual, budget, forecast), Measure (e.g., sales, quantity). DimensionDeployment represents a particular implementation strategy for the dimensional/hierarchical portions of an OLAP model. It does so by organizing a collection of StructureMaps, which in turn define a mapping to an implementation model. HierarchyLevelAssociation is a class that orders Levels within a LevelBasedHierarchy, and provides a means of mapping Level/Hierarchy-oriented Dimension attributes to one or more physical deployments. The relative ordering of DimensionDeployment classes optionally implies a desired order of selection of DimensionDeployments, based on implementation-specific considerations (e.g., optimized access of aggregate data). A LevelBasedHierarchy is a hierarchy that describes relationships between specific levels of a Dimension. LevelBasedHierarchy can be used to model to "pure level" hierarchies (e.g., dimension-level tables) and "mixed" hierarchies (i.e., levels + linked nodes). ValueBasedHierarchy is a subclass of Hierarchy that ranks Dimension members according to their relative distance from the root. Each member of a ValueBasedHierarchy has a specific "metric" or "value" associated with it. ValueBasedHierarchy is used to model pure "linked node" hierarchies (e.g., parent-child tables). StructureMap is a subclass of TransformationMap that maps Dimension attributes to their physical data sources. (Note: Multiple StructureMaps may be grouped together into single, cohesive unit via TransformationTask.) A HierarchyLevelAssociation may own any number of DimensionDeployments. The ordering of the DimensionDeployment classes may optionally be assigned an implementation-specific meaning (e.g., desired order of selection of multiple deployments, based on optimized access to aggregated data). A ValueBasedHierarchy may own any number of DimensionDeployments. The ordering of the DimensionDeployment classes may optionally be assigned an implementation-specific meaning (e.g., desired order of selection of multiple deployments, based on optimized access to aggregated data). MiningCoreModule org.omg.cwm.analysis CWMDM org.omg.java.cwm.analysis This object provides a mapping between a mining attribute (logical data) and a set of attributes in the input data (physical data). logicalAttribute is the mining attribute being mapped by this object. orderIdAttribute is used when ordering of attributes is required. In some cases, ordering of attributes is important (as in sequence analysis). In other cases, a sequence of an attribute is favored over having a set-valued attributes. AttributeAssignment can be reused among several tasks, but a MiningAttribute can be refered to by an AttributeAssignment within a task. This enumeration determines which attriute in the given data to select and map it to a set-valued logical attribute. The attributes that satisfy the given condition in this enumeration get selected. The usage attribute indicates if the MiningAttribute should be used by the model or not, according to the details specified in the UsageOption enumeration class. The default is "active". This suppresses discretization to be performed on the attribute being specified, if true. The default is false. umlAttribute A CategoricalAttributeProperties object is used to describe properties of a categorical attribute. It lists the specific categories that are recognized in the attribute, as well as a taxonomy, or CategorizationGraph, that organizes the categories into a hierarchy. This metadata may or may not be used by the underlying algorithm. It may be leveraged to determine if data being supplied as input to a mining operation is sufficiently similar to the data used to build the model. Maps a pair of attributes from two different sources, for example a table column and a MiningAttribute. In this example, the table column is represented by attribute. The attribute type indicates if the attribute is categorical, ordinal, numerical, or not specified. If either categoricalProperties or numericalProperties are specified, a constraint exists to ensure the attributeType value is consistent with these attributes. This attribute allows a MiningAttribute to be identified with a particular type even if no additional properties are specified. If ordinal, then the OrdinalAttributeProperties must be specified to indicate the ordering of the categories. A NumericalAttributeProperties object is used to describe properties of the numerical attribute. This metadata may or may not be used by the underlying algorithm. It may be leveraged to determine if data being supplied as input to a mining operation is sufficiently similar to the data used to build the model. This indicates whether the values of the attributes are cyclic, i.e., the next value of the ending value is the starting value. The default is false. A PhysicalData object specifies the layout of the physical data to be used for mining, and if appropriate, the roles the various data columns play, via subclassing. The data referenced by a physical data object can be used in many capacities: model building, scoring, lift computation, statistical analysis, etc. PhysicalData supports specification of any data definable through a Class or set of Attributes, e.g., files, tables, and star schema. This object provides a mapping where the input data is in transactional format. Each of the logical attributes ocurring in a pivoted table is mapped to three physical columns, presumably the same ones every time. If the data types don't match, the value column may be different in that case. Question: Seems that we need to have more than one logical attribute associated with this assignment. Constraint: The logicalAttribute must be set valued. This object is used when the input data is in tabular (2-D) form. The sets are represented by enumerating their elements based on the selection functions. For example, if the attribute selection function is "isOne" and the value selection function is "attribute", the we get: A B C D E F 1 0 0 1 0 0 = {A, D} 0 0 0 0 0 1 = {F} 0 0 0 0 0 0 = {} Each of the input attributes (A, B, C, D, E, and F) is a selector attribute in this object. It works best for a small number of members known a priori. In some cases, when the potential number of values is large, but it is also known that the set sizes are all small, e.g., less than 6, then we get the following: A B C D F X Y NULL NULL NULL = {X, Y} Z NULL NULL NULL NULL = {Z} NULL NULL NULL NULL NULL = {} In the above example, the attribute selection function is "isNotNull" and the value selection function is "value". Constraint: The logicalAttribute must be set valued. This object provides a mapping between a set-valued mining attribute and a set of attributes in the physical data. setIdAttribute is the set identifier of the set being mapped. memberAttribute represents a set of attributes being mapped to the set-valued mining attribute. vsf_ This represents a discrete value. A collection of Category instances defines the values that may or may not be annotated with a mining attribute. Constraint on value: Datatype must define equality operator. The optional attribute isNullCategory is set to true if the Category provided is the NULL category. If true, this invalidates any specification in the value attribute. A CategoryMatrix assigns numeric values to pairs of categories. It is either represented as a set of CategoryMatrixEntries or as a table. Type of matrix, 'diagonal', 'symmetric', or 'any'. If diagonal, then all values outside the diagonal are 0. If symmetric then value(i,j)=value(j,i). Value of a cell. It overwrites any default value in CategoryMatrix. For Cost matrix, value is intended to be a double. For ConfusionMatrix, the value can be either a "count" which is an integer value, or a "percentage" which is a double value. This is up to the implementation. Table with three columns holding the definition of a category matrix. Tabular representation of a CategoryMatrix. A category matrix consists of exactly one table. The table has three row, column and value of the entry. A CategorizationGraph supports the specification of taxonomy or category hierarchy as required by data mining in the form of a directed acyclic graph. It enables two representations: 1) explicit specification of the graph through the referenced node class, and 2) referencing MiningData with specific attributes (columns) that store the data in tabular form. A CategorizationGraph can contain multiple "root" nodes, in a sense being a single representation for several possibly strict hierarchies. Constraint to have either the MiningData instances (CategoryMapTable) OR the java object instances (CategoryMap). Note: This is a "graph" as opposed to a "hierarchy" because it can have multiple roots, i.e. hierarchies in the same object. mp_ MiningDataModule A mining algorithm settings object captures the parameters associated with a particular algorithm. It allows a knowledgeable user to fine tune algorithm parameters. Generally, not all parameters must be specified, however, those specified are taken into account by the underlying data mining system. Separating mining algorithm from mining function provides a natural and convenient separation for those users experienced with data mining algorithms and those only familiar with mining functions. A MiningFunctionSettings object captures the high level specification input for building a data mining model. The intent of mining function settings, is to allow a user to specify the type of result desired without having to specify a particular algorithm. Although mining function settings allow for the specification of algorithm, if this is omitted, the underlying data mining system is responsible for selecting the algorithm based on basic user-provided parameters. Subclasses throw exceptions if invalid algorithm-function pairs are supplied. The desiredExecutionTime attribute indicates the maximum execution time (in minutes) allowed for model building. If NULL, the algrotihm determines for how long the model will build. This is to serve as a hint to the algorithm to adjust model building to meet the time constraint. Vendor implementations may support this to varying degrees, e.g., terminate model build if exceeds this limit, intelligently adjust algorithm parameters to meet this constraint, or dynamically distribute or parallelize the operation. MiningFunctionSettingsModule A MiningModel holds the metadata of the result of a mining (training) run. This information is sufficient to determine whether a model can be applied to given data. Data mining function (as opposed to algorithm), e.g. classification or clustering. The following function names are predefined: attributeImportance associationRules classification regression clustering Specific implementation of the data mining function, e.g. CART decision tree or SOM clustering. The following algorithm names are predefined (their functions in parentheses): decisionTree (classification, regression) neuralNetwork (classification, regression) naiveBayes (classification) selfOrganizingMap (clusteirng) kMeans (clustering) competitiveLearning A SignatureAttribute object describes the input expected to a model. This is automatically produced as part of the model. It indicates not only the basic Attribute properties, but also how outliers and missing values were handled for model build. This is potentially duplicate information from the MiningFunctionSettings, but must be provided since MiningFunctionSettings are optional. If an attribute was normalized or discretized automatically by the Data Mining System, the specific details are provided in the SignatureAttribute object. The user is not expected to use this information to preprocess the data in any way. The Data Mining System uses this information to automatically preprocess data, if required. The usage intended for this attribute. A model signature consists only of 'active' and 'supplemental' attributes. 'Inactive' attributes are filtered out as they do not contribute to the model. Note that 'supplemental' attributes do not contribute to model apply. MiningModelModule A MiningResult holds the metadata of the result of a mining run other than training that results in a model. It includes apply, test, and compute lift operations. MiningResultModule This object describes an entity of apply output. It is usually stored in a destination attribute. The destination attribute is specified by an AttributeAssignment object. If Transactional output, then ApplyOutputItem does not have a destination attribute. Instead, the (name) entry for the attrNameAttribute is held in 'name' inherited from ModelElement This describes the ouput Specification for a MiningApplyTask. It contains a set of attributes (represented as ApplyOutputItem objects) holding the output information. These attributes can hold the score or other computed information, or else be copied from input columns for reference. MiningTaskModule EntryPointModule ClusteringModule org.omg.cwm.analysis CWMDM org.omg.java.cwm.analysis Per ClusteringModel, there is one aggregation function: depending on the attribute type. The aggregated value is optimal if it is 0 (for distance measure) or greater values indicate optimal fit (for simiarity measure). In the definition of functions, Wi is the field weight in the attribute, and Xi and Yi are values. When two records are compared, then either the distance or similarity is of interest. In both cases the measures can be compouted by a combination of an "inner" function and an "outer" function. The inner function compares two single field values and the outer function computes an aggregation over all fields. Each field has a comparison function, this is either defined as a default in ClusteringModel or it can be defined per attribute. A ClusteringAttributeUsage is a subclass of AttributeUsage to support attribute usages that are specific to clustering algorithms. AssociationRulesModule org.omg.cwm.analysis CWMDM org.omg.java.cwm.analysis SupervisedModule org.omg.cwm.analysis CWMDM org.omg.java.cwm.analysis ClassificationModule org.omg.cwm.analysis CWMDM org.omg.java.cwm.analysis As a subclass of AttributeUsage, CategoricalAttributeUsage provides additional specification for categorical attributes only, in particular, a set of the positive categories. Positive categories are provided here since different models may choose different postive categories, hence it is not a characteristic of the data. A ClassificationFunctionSettings object is a subclass of SupervisedFunctionSettings that supports features unique to the classification mining function and corresponding algorithms, specifically costMatrix. The costMatrix must be associated with the target MiningAttribute. This represents a set of prior probabilities of the categories in a mining attribute. Mostly applies to a target MiningAttribute used for classification. The sum of the probabilities in all priorsEntries must not exceed 1. This represents the probability of the targetValue in the original data. The value must be in [0,1] ApproximationModule org.omg.cwm.analysis CWMDM org.omg.java.cwm.analysis An ApproximationFunctionSettings is a subclass of SupervisedFunctionSettings that supports features that are unique to approximate numerical values. This originally was named "RegressionFunctionSettings", however, this implies a restriction on the type of algorithms that can be applied to solve the problem of approximation, or curve fitting. This represents a task to check the quality of a regression model. A comparison of mean predicted values and mean actual values can be done and a number of numerical error measures can be computed. NULL values mean that the model did not compute the value. AttributeImportanceModule org.omg.cwm.analysis CWMDM org.omg.java.cwm.analysis The CWM Information Visualization metamodel defines metadata supporting the problem domain of "information publishing" or, more generally, "information visualization". Within the data warehousing environment, data is collected from numerous, diverse sources and transformed into a unified representation that facilitates the analysis of data for purposes of gaining business insight. Robust and flexible information visualization tools are key to the effective analysis of this information. Information visualization tools must be capable of understanding and preserving the "logical structure" of data warehouse information, while enabling the user to perform any number of "rendering transformations" on information content (e.g., displaying the same query result set in several different formats, such as a printed report, Web page, pie chart, bar graph, etc.). Since information visualization is a very broad problem domain, with a diverse set of possible solutions and many evolving standards, the CWM Information Visualization metamodel defines very generic, container-like metadata constructs that either contain or reference more complex visualization mechanisms at the M1-level. These metadata structures are intended to support the minimal metadata required to interchange more complex M1 models of visualization mechanisms. The Information Visualization package depends on the following packages: org.omg.cwm.objectmodel.core org.omg.cwm.foundation.expressions RenderedObject is the logical proxy for an arbitrary ModelElement that is to be rendered via some rendering transformation or process. A RenderedObject may be composed of an arbitrary number of other RenderedObjects (i.e., components), and may have topological relationships to still other RenderedObjects. The formula attribute allows for the specification of any implementation-dependent expression that completes the definition of a RenderedObject. For example, the formula might specify the position of the RenderedObject within a two-dimensional grid, or in relation to one of its neighbors; e.g., formula = "neighbor(x, y) + (delta-x, delta-y)". A RenderedObject generally references one or more Renderings that specify how the enderedObject is actually presented. One of these associated Renderings may optionally be designated as a default Rendering. A Rendering is semantically equivalent to a transformation, in that it transforms a source RenderedObject to some target "displayed" (or otherwise "presented" object -- e.g., a displayed image or an audio clip) . An instance of Rendering is fully specified via its formula attribute, which, like RenderedObject, contains an implementation-dependent expression. Thus, a RenderedObject may be viewed as the "logical description" of an object to be rendered, independently of how it is actually presented by any of its associated Renderings, and Renderings may be viewed as transformations that control the presentation of the RenderedObject while preserving its logical structure. Note that a RenderedObject may be the target of a complex transformation (i.e., utilizing the CWM Transformation package). For example, an N-dimensional OLAP cube might be transformed into an equivalent, two-dimensional, composite RenderedObject, with several dimensions mapped to row and column edges, respectively, and all other dimensions constrained to single member values. Several Renderings may then be defined and associated with the resultant RenderedObject, mapping the two-dimensional logical structure to the surface of a display screen in various different formats (e.g., spreadsheet, pie chart, bar graph, etc.). Possible types of Renderings include: Screen, paper, voice, Web, HTML documents, XML/XSL, languages based on extensions to XML, SVG, visual objects, responses to keying (e.g., keying interception plus rules), etc. XSLRendering represents a useful subtype of Rendering that’s based on XSL (e.g., this subtype’s formula might contain a procedure that uses XSL to create an HTML document). Finally, RenderedObjectSet represents a simple container of both logical RenderedObjects and available Renderings. The inheritance of the Information Visualization metamodel from the Object Model is shown in Fig. 16-2. OCL Representation of Information Visualization Constraints [C-1] The set of Renderings includes the default Rendering. context RenderedObject inv: self.defaultRendering->notEmpty implies self.rendering->includes( self.defaultRendering ) [C-2] A RenderedObject may not reference itself as a Neighbor nor as a Component. context RenderedObject inv: self.neighbor->excludes( self ) inv: self.component->excludes( self ) [C-3] A RenderedObject may not reference one of its Neighbors as a Component (and vice versa). context RenderedObject inv: (self.neighbor->notEmpty and self.component->notEmpty) implies self.neighbor->intersection( self.component )->isEmpty The transitive closure of Neighbors of an instance of RenderedObject must not include the RenderedObject instance. The transitive closure of Components of an instance of RenderedObject must not include the RenderedObject instance. org.omg.cwm.analysis CWMIV InformationVisualizationModule org.omg.java.cwm.analysis RenderedObject serves as a logical "proxy" for an arbitrary ModelElement that is to be rendered. CwmRenderedObjectSet Rendering is a specification of how an associated RenderedObject is to be "rendered" in some medium. This usually consists of a projection of an object of arbitrary dimensionality onto a 2-dimensional surface, but it may also include non-physical representations as well (such as audio). A Rendering is semantically equivalent to a Transformation, in that it transforms a source RenderedObject to some target "presented" object. An instance of Rendering is fully specified via its formula attribute, which contains an implementation-dependent expression that defines the transformation and tracks transformation lineage. Possible types of instances of Rendering: Screen, Paper, Voice, Web, HTML Document, XML/XSL, languages based on extensions to XML, SVG, Visual objects, responses to keying (keying interception plus rules), etc. Business users of data warehouses need to have a good understanding of what information and tools exist in a data warehouse. They need to understand what the information means from a business perspective, how it is derived, from what data resources it is derived, and what analysis and reporting tools exist for manipulating and reporting the information. They may also need to subscribe to analysis and reporting tools, and have them run with results delivered to them on a regular basis. The BusinessNomenclature package contains classes and associations that can be used to represent business metadata. Easy access to this business metadata enables business users to exploit the value of the information in a data warehouse. It can also aid technical users in certain tasks. An example is the use of common business terms and concepts for discussing information requirements with business users. Another example is accessing business intelligence tools for analyzing the impact of warehouse design changes. The scope of the BusinessNomenclature package is restricted to the domain of data warehousing and business intelligence. This section provides a description of the main features of the BusinessNomenclature package. The BusinessNomenclature package provides two main constructs to represent business terms and concepts and related semantics: Taxonomy is a collection of concepts that provide the context for the meaning of a particular term. Glossary is a collection of terms and various related forms of the term. A taxonomy is a collection of concepts. Concepts represent semantic information and relationships. Concepts are identified by terms, which in turn are manifested by a word or phrase. More than one term may describe the same concept and a given term may describe more than one concept. A glossary is a collection of terms that are related through explicit or implicit relationships. Terms may be preferred (the term best representing its concept) and thus represent the vocabulary of a business domain or user. Terms may be synonyms and point at the preferred term. A preferred term and its synonyms represent the fact that several terms describe the same concept although with different shades of meaning. Terms may be arranged into a hierarchy of more generic and more specific elements. This relationship allows substituting a narrower term, such as "USA", for a wider term, such as "country". The BusinessNomenclature package depends on the following packages: omg.org::CWM::ObjectModel::Core The metamodel diagram for the BusinessNomenclature package is split into two parts. The first diagram shows the BusinessNomenclature classes and associations, while the second shows the inheritance hierarchy. OCL Representation of Business Nomenclature Constraints [C-1] A Concept may not relate to itself. context Concept inv: self.relatedConcept->forAll ( p | p <> self ) [C-2] The parent of a Glossary must be a Glossary. context Glossary inv: self.parent.oclIsKindOf( Glossary ) [C-3] The child of a Glossary must be a Glossary. context Glossary inv: self.child->forAll( p | p.oclIsKindOf( Glossary ) ) [C-4] The parent of a Taxonomy must be a Taxonomy. context Taxonomy inv: self.parent.oclIsKindOf( Taxonomy ) [C-5] The child of a Taxonomy must be a Taxonomy. context Taxonomy inv: self.child->forAll( p | p.oclIsKindOf( Taxonomy ) ) [C-6] A Term may not relate to itself. context Term inv: self.relatedTerm->forAll ( p | p <> self ) [C-7] A VocabularyElement may not relate to itself. context Vocabulary inv: self.relatedElement->forAll ( p | p <> self ) [C-8] The RelatedConcepts association is derived from the RelatedVocabularyElements association. All ends of the RelatedConcepts association must be Concepts. context RelatedConcepts inv: RelatedVocabularyElements.allInstances.select( element.oclIsKindOf( Concept ) and relatedElement.oclIsKindOf( Concept ) ) [C-9] The RelatedTerms association is derived from the RelatedVocabularyElements association. All ends of the RelatedTerms association must beTerms. context RelatedTerms inv: RelatedVocabularyElements.allInstances.select( element.oclIsKindOf( Term ) and relatedElement.oclIsKindOf( Term ) ) CWMBUS org.omg.cwm.analysis BusinessNomenclatureModule org.omg.java.cwm.analysis This represents a business idea or notion. Concepts are represented by Terms. Users use Terms that are familiar to them in their business environment to refer to Concepts. This represents words or phrases used by business users to refer to Concepts. A Term has a definition in a specific context. The context is provided by the referenced Concept that describes the underlying semantics. This association relates a Concept to its related Concepts. This association is derived from the RelatedVocabularyElements association. All ends of the association must be Concepts. [C-8] This association relates a Term to its related Terms. This association is derived from the RelatedVocabularyElements association. All ends of the association must be Terms.[C-9] The Warehouse Process package documents the process flows used to execute transformations. These process flows may be documented at the level of a complete TransformationActivity or its individual TransformationSteps. A WarehouseProcess object associates a transformation with a set of events which will be used to trigger the execution of the transformation. The Warehouse Process package depends on the following packages: org.omg::CWM::ObjectModel::Core org.omg::CWM::ObjectModel::Behavioral org.omg::CWM::Analysis::Transformation A WarehouseProcess object represents the processing of a transformation. It is instantiated as one of its subtypes WarehouseActivity or WarehouseStep, depending on whether it represents the processing of a TransformationActivity or a Transformation Step. A WarehouseProcess may be associated with one or more WarehouseEvents, each identifying events that cause the processing to be initiated. It may also be associated with one or more internal events that will be triggered when processing terminates. A ProcessPackage may be used to group together related WarehouseActivities. WarehouseEvents are divided into three categories: scheduled, external and internal. Scheduled events can either be defined as a point in time (each Wednesday at 2 pm) or be defined by intervals (every five minutes). A point in time event can be defined as a custom calendar which contains a set of calendar dates. This allows a series of dates to be reused across several WarehouseProcesses. External events are triggered by something happening outside the data warehouse, for example by a batch process which is not described as a WarehouseProcess. Internal events are triggered by the termination of a WarehouseProcess. They can be either retry events or cascade events. Retry events normally trigger a rerun of the same WarehouseProcess, whereas cascade events normally trigger a different WarehouseProcess. An internal event may define a condition that determines whether or not the event is triggered. This condition can use details of the execution of the triggering WarehouseProcess recorded in the relevant ActivityExecution and StepExecution objects. OCL Representation of Warehouse Process Constraints [C-1] month must be specified when recurringType is everyYear. context RecurringPointInTimeEvent inv: self.recurringType=everyYear implies self.month->notEmpty [C-2] month must be between 1 and 12 (inclusive) when specified. context RecurringPointInTimeEvent inv: self.month->notEmpty implies 1 <= self.month <= 12 [C-3] dayOfMonth must be specified when recurringType is everyYear or everyMonth. context RecurringPointInTimeEvent inv: self.recurringType=everyYear or self.recurringType=everyMonth implies self.dayOfMonth->notEmpty [C-4] dayOfMonth must be between 1 and 31 (inclusive) when specified. context RecurringPointInTimeEvent inv: self.dayOfMonth->notEmpty implies 1 <= self.dayOfMonth <= 31 [C-5] dayOfWeek must be specified when recurringType is everyWeek. context RecurringPointInTimeEvent inv: self.recurringType=everyWeek implies self.dayOfWeek->notEmpty [C-6] hour must be specified when recurringType is everyYear or everyMonth or everyWeek or everyDay. context RecurringPointInTimeEvent inv: self.recurringType=everyYear or self.recurringType=everyMonth or self.recurringType=everyWeek or self.recurringType=everyDay implies self.hour->notEmpty [C-7] hour must be between 0 and 23 (inclusive) when specified. context RecurringPointInTimeEvent inv: self.hour->notEmpty implies 0 <= hour <= 23 [C-8] minute must be specified when recurringType is not everyMinute. context RecurringPointInTimeEvent inv: self.recurringType<>everyMinute implies self.minute->notEmpty [C-9] minute must be between 0 and 59 (inclusive) when specified. context RecurringPointInTimeEvent inv: self.minute->notEmpty implies 0 <= self.minute <= 59 [C-10] second must be between 0 and 59 (inclusive). context RecurringPointInTimeEvent inv: 0 <= self.second <= 59 CWMWHP org.omg.cwm.management WarehouseProcessModule org.omg.java.cwm.management A virtual class to refer to any Event. A WarehouseEvent (or its derivations) represents what triggers the running of a WarehouseProcess. An event can be initiated by a clock, by an external trigger, or by an internal trigger (the conclusion of some WarehouseProcess). A PointInTime event is triggered at a fixed time, independently of any external context. The triggering time can be either defined functionally (as in the RecurringPointInTimeEvent extension of this class), or by an explicit list of times (CustomCalendarEvent). An IntervalEvent controls a continuous run of a WarehouseProcess. The Warehouse Process will run, then wait for the duration specified in the event, then run again. An IntervalEvent is not affected by the result of the WarehouseProcess. Indicates the length of time (in seconds) to wait after a run of the WarehouseProcess before triggering the next one. An ExternalEvent allows the description of the triggering of a WarehouseProcess by a task which is not described in the model. This is merely a place holder. The actual behavior and the connection with the external trigger is left to the implementation of the scheduler. An event which may be triggered, depending on whether or not a condition is satisfied, by the conclusion of one or more WarehouseProcess runs. There are two types of InternalEvents, depending whether the event triggers a series of different WarehouseProcesses, or whether the event triggers the same WarehouseProcess in an attempt to retry a failed run. Indicates what condition the triggering WarehouseProcess run must meet to be considered (success, failure, warnings, etc.). How the condition is expressed, and how the result of a Transform is generated is left to the implementation of the scheduler and the transformation, respectively. Indicates that a WarehouseProcess should be retried upon failure. This type of event is used for example when a WarehouseProcess relies on sources with uncertain availability (connection or uptime). In general, the triggering WarehouseProcess and the triggered WarehouseProcess are the same, and only one WarehouseProcess is involved. But this is not an imposed limitation. It is left to the schedulers to decide on the implementation behavior for complex cases. Indicates which month of the year (from 1 to 12) an annual event is to be triggered. Indicates which day of the month (from 1 to 31) a monthly or annual event is to be triggered. For a monthly event, if the day of the month is greater than the number of days in the month, it is assumed that the scheduler will run the WarehouseProcess on the last day of the month. Indicates which day of the week a weekly schedule is running. Indicates at what hour (from 0 to 23) an annual, monthly, weekly, or daily event is being triggered. Indicates at what second (from 0 to 59) an event must be run. Applies to all events. A WarehouseProcess represents the processing of a transformation. It is instantiated as one of its subtypes WarehouseActivity or WarehouseStep, depending on whether it represents the processing of a TransformationActivity or a Transformation Step. A WarehouseProcess may be associated with one or more WarehouseEvents, each identifying events that cause the processing to be initiated. It may also be associated with one or more internal events that will be triggered when processing terminates. When a WarehouseProcess is a constant mapping (such as a Relational View of legacy data or a continuous data propagation process), this flag indicates that the mapping does not require to be run for the target to be up-to-date and in sync with the source. A WarehouseStep is a component of a WarehouseActivity. It represents the processing of an individual TransformationStep. It may be used to identify WarehouseEvents that trigger the processing of the TransformationStep and/or InternalEvents that are triggered by the conclusion of the processing of the TransformationStep. For example, a WarehouseStep may be used to document how a specific TransformationStep should be retried upon failure. A WarehouseActivity is a subtype of WarehouseProcess that represents the processing of a TransformationActivity. It may identify WarehouseEvents that trigger the processing of the TransformationActivity and InternalEvents that are triggered by the conclusion of this processing. It may contain a set of WarehouseSteps that define in more detail the processing of the individual TransformationSteps of the TransformationActivity. The Warehouse Operation package contains classes recording the day-to-day operation of the warehouse processes. The package covers three separate areas: Transformation Executions Measurements Change Requests Details of the most recent executions of transformations can be recorded, identifying when they ran and whether they completed successfully. This can be used to determine how complete and up-to-date specific information in the data warehouse is. An ActivityExecution represents an execution of a whole TransformationActivity, and a StepExecution object represents an execution of an individual TransformationStep. If a TransformationStep involves the use of an Operation , an associated StepExecution may reference a CallAction that records the actual arguments passed to the Operation. These classes allow the lineage of data in a data warehouse to be preserved, by recording when and how it was derived, and where it came from. Measurement objects allow metrics to be held for any ModelElement. For example, they may be used to hold actual, estimated or planned values for the size of a table. ChangeRequests allow details of proposed changes affecting any ModelElement to be recorded. They may also be used to keep a historical record of changes implemented or rejected. The Warehouse Operation package depends on the following packages: org.omg::CWM::ObjectModel::Core org.omg::CWM::ObjectModel::Behavioral org.omg::CWM::Analysis::Transformation Separate model diagrams are shown below for each of the three main areas supported by the package. OCL Representation of Warehouse Operation Constraints [C-1] A ChangeRequest instance must not apply to itself. context ChangeRequest inv: self.modelElement -> forAll (element | element <> self) [C-2] A completionDate may only be provided for a completed ChangeRequest. context ChangeRequest inv: self.completionDate->notEmpty implies self.completed [C-3] A Measurement instance must not apply to itself. context Measurement inv: self.modelElement <> self [C-4] If the TransformationExecution is not inProgress, the successful, status and endDate attributes must be present, and endDate must not be earlier than startDate. context TransformationExecution inv: self.inProgress=false implies (self.successful->notEmpty and self.status->notEmpty and self.endDate->notEmpty and self.endDate >= self.startDate) CWMWHO org.omg.cwm.management WarehouseOperationModule org.omg.java.cwm.management A Measurement object indicates the value of some attribute of an object. It can be the number of rows in a table, the number of pages in an index, the number of different values in a column, etc. The flexibility of this class allows for product specific extensions, without changing the model. Identifies how the value was computed. The following values have specific meanings: measure (measured value) estimate (estimated value) plan (planned value) minimum (minimum value) maximum (maximum value) average (average value) umlValue Indicates that no further action is required for this change request, i.e. it has either been implemented or been rejected. CWMComplete is a package that invokes all other CWM packages. It does this by listing all of the other CWM metamodel packages in declaration order in the uml2mof.clusteredImport property of the MOF tab. CWMComplete is included as a convenience for software that wants to generate the entire CWM package. It is non-normative, is not included in any normative CWM dtd file, and is not documented in either volume of the CWM specification. org.omg.cwm CWM CWMCompleteModule org.omg.java.cwm