1 / 21

Specification of Constraints in Data Element Concepts and Metadata Representation

This document outlines the specification of constraints within the Model Driven Requirements (MDR) metamodel. It highlights the absence of a standardized method for defining constraints and introduces the use of Object Constraint Language (OCL) to express constraints regarding Data Element Concepts, Conceptual Domains, and Value Domains. It emphasizes user-defined constraints for registered data elements, describes relationships between data concepts, and provides various examples to illustrate constraints. The need for formal description languages to enhance metadata representation is also discussed.

knoton
Télécharger la présentation

Specification of Constraints in Data Element Concepts and Metadata Representation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Issue 134: Specification of Constraints • There is no standard way of specifying constraints • Constraints in MDR metamodel • OCL expressionscan be provided for metaclass and its instance • Target: Data Element Concept and Conceptual Domain, Value Domain and Data Element and so on. • Constraints of registered data elements (user should be defined) • Target: Conceptual Domain or Value Domain • Representation, Dimensionality and Classification are a kind of constraints • User defined matadata should enable to be defined as extension mechanism, such as ebXML Registry and Repository • Constraint should be described using such user defined slots • Need formal description language such as OCL, CL • We should allow OCL or other specification languages to be used by users of the registry

  2. Constraints in Data Element Concept • 4.11.1.3 Data Element Concept • (1) A Data Element Concept is a concept that can be represented in the form of a data element, described independently of any particular representation. • (2) A Data Element Concept may have zero or one Object Class and zero or one Property. • (3) The union of a Property and an Object Class provides significance beyond either that of the Property or the Object Class. • (4) A Data Element Concept thus has aDefinition independent from the Definition of the Object Class or the Property. • (5) As an Administered Item, a Data Element Concept carries its own Administration Record information, allowing it to be identified, named,defined and optionally classified within a Classification Scheme. IdentifiedandOptionallyClassified • (6) A Data Element Concept may be associated with other Data Element Concepts, via the Data Element Concept Relationship. • (7) The nature of the relationship is described using the data element concept relationship type description. IsDescribedUsing • (8) A Data Element Concept may be registered as an Administered Item without necessarily being associated with any Data Element, but a Data Element Concept shall be associatedwith exactly oneConceptual Domain, as represented by the "data element concept-conceptual domain relationship" in Figure 8.MustBeRegistered, ShallBeAssociatedWith • (9)TheConceptual Domainspecifies all validValue Meanings of a Data Element Concept. The Conceptual Domainis described in 4.12.1.1.MustBeContained

  3. Examples of OCL expression MustBeContainedUnless…. ….AttributesCannotBeChanged ….CannotBeDeleted ….DependenciesCannotBeChanged ….NamesMustNotCollide ….MustNotBeSelf ….MustBeSame ….MustNotCollideWith…. ….RuleMustBeObeyed No….AllowedFor…..

  4. Examples of Constraints (form MOF1.4) • [A ModelElement that is not a Package must have a container. [C-1]] • [The attribute values of a ModelElement which is frozen cannot be changed. [C-2]] • [A frozen ModelElement which is in a frozen Namespace can only be deleted, by deleting the Namespace. [C-3]] • [The link sets that express dependencies of a frozen Element on other Elements cannot be explicitly changed. [C-4]] • [The names of the contents of a Namespace must not collide. [C-5]] • [A Generalizable Element cannot be its own direct or indirect supertype. [C-6]] • [A supertypes of a GeneralizableElement must be of the same kind as the GeneralizableElement itself. [C-7]] • [The names of the contents of a GeneralizableElement should not collide with the names of the contents of any direct or indirect supertype. [C-8]] • [Multiple inheritance must obey the “Diamond Rule.” [C-9]] • [If a Generalizable Element is marked as a “root,” it cannot have any supertypes. [C-10]] • [A GeneralizableElement’s immediate supertypes must all be visible to it. [C-11]] • [A GeneralizableElement cannot inherit from a GeneralizableElement defined as a “leaf.” [C-12]]

  5. [C-1] MustBeContainedUnlessPackage • format1: MUST_BE_CONTAINED_UNLESS_PACKAGE • format2: must_be_contained_unless_package • evaluation policy: deferred • description: A ModelElement that is not a Package must have a container. context ModelElement inv: not self.oclIsTypeOf(Package) implies self.container -> size = 1

  6. [C-2] FrozenAttributesCannotBeChanged • format1: FROZEN_ATTRIBUTES_CANNOT_BE_CHANGED • format2: frozen_attributes_cannot_be_changed • evaluation policy: immediate • description: The attribute values of a ModelElement which is frozen cannot be changed. context ModelElement inv: self.isFrozen() implies let myTypes = self.oclType() -> allSupertypes() -> 　　　　　　　includes(self.oclType()) in let myAttrs : Set(Attribute) = self.RefBaseObject::refMetaObject() ->asOclType(Class) -> 　　　　　findElementsByTypeExtended(Attribute) in 　　myAttrs -> forAll(a |self.RefObject::refValue@pre(a) = self.RefObject::refValue(a))

  7. [C-3] FrozenElementsCannotBeDeleted • format1: FROZEN_ELEMENTS_CANNOT_BE_DELETED • format2: frozen_elements_cannot_be_deleted • evaluation policy: immediate • description: A frozen ModelElement which is in a frozen Namespace can only be deleted, by deleting the Namespace. • context ModelElement • post: • (self.isFrozen@pre() and • self.container@pre -> notEmpty and • self.container.isFrozen@pre()) implies (self.container.Object::non_existent() or not self.Object::non_existent())

  8. [C-4] FrozenDependenciesCannotBeChanged • format1: FROZEN_DEPENDENCIES_CANNOT_BE_CHANGED • format2: frozen_dependencies_cannot_be_changed • evaluation policy: immediate • description: The link sets that express dependencies of a frozen Element on other Elements cannot be explicitly changed. • context ModelElement • post: • self.isFrozen() implies • let myClasses = self.oclType() -> allSupertypes() -> includes(self.oclType()) in • let myRefs = Set(Reference) = • self.RefBaseObject::refMetaObject() -> asOclType(Class) -> • findElementsByTypeExtended(Reference) in • let myDepRefs = myRefs -> • select(r | Set{“contents”, “constraints”, “supertypes”, “type”, “referencedEnd”, “exceptions”, “importedNamespace”, “elements”} -> includes(r.name)) in • myDepRefs -> forAll(r |self.RefObject::refValue@pre(r) = • self.RefObject::refValue(r))

  9. [C-5] ContentNamesMustNotCollide • format1: CONTENT_NAMES_MUST_NOT_COLLIDE • format2: content_names_must_not_collide • evaluation policy: immediate • description: The names of the contents of a Namespace must not collide. • context Namespace • inv: self.contents.forAll( e1, e2 | e1.name = e2.name implies r1 = r2)

  10. [C-6] SupertypeMustNotBeSelf • format1: SUPERTYPE_MUST_NOT_BE_SELF • format2: supertype_must_not_be_self • evaluation policy: immediate • description: A Generalizable Element cannot be its own direct or indirect • supertype. • context GeneralizableElement • inv: self.allSupertypes() -> forAll(s | s <> self)

  11. [C-7] SupertypeKindMustBeSame • format1: SUPERTYPE_KIND_MUST_BE_SAME • format2: supertype_kind_must_be_same • evaluation policy: immediate • description: A supertypes of a GeneralizableElement must be of the same kind as the GeneralizableElement itself. • context GeneralizableElement • inv: self.supertypes -> forAll(s | s.oclType() = self.oclType())

  12. [C-8] ContentsMustNotCollideWithSupertypes • format1: CONTENTS_MUST_NOT_COLLIDE_WITH_SUPERTYPES • format2: contents_must_not_collide_with_supertypes • evaluation policy: immediate • description: The names of the contents of a GeneralizableElement should not • collide with the names of the contents of any direct or indirect • supertype. • context GeneralizableElement • inv: • let superContents = self.allSupertypes() -> collect(s | s.contents) in • self.contents -> forAll(m1 | superContents -> forAll(m2 | m1.name = m2.name implies m1 = m2))

  13. [C-9] DiamondRuleMustBeObeyed • format1: DIAMOND_RULE_MUST_BE_OBEYED • format2: diamond_rule_must_be_obeyed • evaluation policy: immediate • description: Multiple inheritance must obey the “Diamond Rule.” • context GeneralizableElement • inv: • let superNamespaces = • self.supertypes -> collect(s | s.extendedNamespace) in superNamespaces -> asSet -> isUnique(s | s.name)

  14. [C-10] NoSupertypesAllowedForRoot • format1: NO_SUPERTYPES_ALLOWED_FOR_ROOT • format2: no_supertypes_allowed_for_root • evaluation policy: immediate • description: If a Generalizable Element is marked as a “root,” it cannot have any supertypes. • context GeneralizableElement • inv: self.isRoot implies self.supertypes -> isEmpty

More Related