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.