Issue 134: Specification of Constraints There is no standard way of specifying constraints –Constraints in MDR metamodel OCL expressions can be provided.

Slides:



Advertisements
Similar presentations
Profiles Construction Eclipse ECESIS Project Construction of Complex UML Profiles UPM ETSI Telecomunicación Ciudad Universitaria s/n Madrid 28040,
Advertisements

The role of OCL in the Model Driven Architecture Jos Warmer Klasse Objecten
UML (cont.) “The Unified Modeling Language User Guide” by G. Booch, J. Rumbaugh and I. Jacobson ● Classes ● Relationships ● Class diagrams ● Examples.
SEG4110 – Advanced Software Design and Reengineering TOPIC D Metamodelling.
Copyright Irwin/McGraw-Hill Data Modeling Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Edition 3 Metadata registry (MDR) Ray Gates May 12, /05/20151.
Is Your Data Facility ISO Compliant? Progress Towards Harmonizing the DDI and ISO/IEC Dan Gillman Information Scientist US Bureau of Labor Statistics.
The Relational Model System Development Life Cycle Normalisation
DDI 3.0 Conceptual Model Chris Nelson. Why Have a Model Non syntactic representation of the business domain Useful for identifying common constructs –Identification,
Copyright © 2011 Pearson Education, Inc. Publishing as Pearson Addison-Wesley Chapter 8 The Enhanced Entity- Relationship (EER) Model.
Detail Design Extending UML and Object Design. Object Design.
Chapter 3. 2 Chapter 3 - Objectives Terminology of relational model. Terminology of relational model. How tables are used to represent data. How tables.
The RDF meta model: a closer look Basic ideas of the RDF Resource instance descriptions in the RDF format Application-specific RDF schemas Limitations.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Chapter 41 Enhanced Entity-Relationship and Object Modeling.
Environment Change Information Request Change Definition has subtype of Business Case based upon ConceptPopulation Gives context for Statistical Program.
TMF - a tutorial TMF - Terminological Markup Framework Laurent Romary - Laboratoire Loria.
Future of MDR - ISO/IEC Metadata Registries (MDR) Larry Fitzwater, SC 32 WG 2 Convener Computer Scientist U.S. Environmental Protection Agency May.
A novel approach to modeling Zvezdan Protić, Tom Verhoeff, Mark van den Brand.
Lecture 2 The Relational Model. Objectives Terminology of relational model. How tables are used to represent data. Connection between mathematical relations.
Chapter 4 The Relational Model.
Chapter 3 The Relational Model Transparencies Last Updated: Pebruari 2011 By M. Arief
Representing variables according to the ISO/IEC standard.
Chapter 9 Integrity. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.9-2 Topics in this Chapter Predicates and Propositions Internal vs.
Classification and the Metadata Registry Judith Newton NIST IRS XML Stakeholders/ XML Working Group May 18, 2004.
Processing of structured documents Spring 2002, Part 2 Helena Ahonen-Myka.
Module 3: The Relational Model.  Overview Terminology Relational Data Structure Mathematical Relations Database Relations Relational Keys Relational.
Chapter 3 The Relational Model. 2 Chapter 3 - Objectives u Terminology of relational model. u How tables are used to represent data. u Connection between.
What is MOF? The Meta Object Facility (MOF) specification provides a set of CORBA interfaces that can be used to define and manipulate a set of interoperable.
Metadata Registries Workshop April 15, 1998 Slide 1 of 20 ANSI X Douglas D. Mann Stewardship Naming & Identification Classification.
2004 Open Forum for eBusiness and Metadata Technology Standardization Metamodel Framework for Ontology Keqing He, Yixin Jing, Yangfan He State Key Laboratory.
Specializing and extending the UML
The Final Study Period Report on MFI 6: Model registration procedure SC32WG2 Meeting, Sydney May 26, 2008 H. Horiuchi, Keqing He, Doo-Kwon Baik SC32WG2.
1 Devon M. Simmonds Metadata & The UML Metamodel SLIDES include some from tvarious sources including: (1)
XML Registries Source: Java TM API for XML Registries Specification.
2010/11/16 OKABE, Masao 1 Issues to be discussed on MFI-Part10 Core model and basic mapping and transformation OKABE, Masao Editor MFI Part
Uml is made similar by the presence of four common mechanisms that apply consistently throughout the language. After constructing or developing the architecture.
1 The Relational Database Model. 2 Learning Objectives Terminology of relational model. How tables are used to represent data. Connection between mathematical.
Structural Modeling. Objectives O Understand the rules and style guidelines for creating CRC cards, class diagrams, and object diagrams. O Understand.
9 th Open Forum on Metadata Registries Harmonization of Terminology, Ontology and Metadata 20th – 22nd March, 2006, Kobe Japan. Presentation Title: Day:
Today in OOAD  The Domain Model Artifact UML Classes  EU-Bid Domain Model Exercise  EU-Lease Domain Model Assignment Guest Speaker  Kate Cunningham,
CS551 - Lecture 8 1 CS551 Modelling with Objects (Chap. 3 of UML) Yugi Lee STB #555 (816)
Environment Change Information Request Change Definition has subtype of Business Case based upon ConceptPopulation Gives context for Statistical Program.
Lecture 6: Structural Modeling
Week III  Recap from Last Week Review Classes Review Domain Model for EU-Bid & EU-Lease Aggregation Example (Reservation) Attribute Properties.
1 1 Overview 1.Find out why software engineering is important ■ see some software engineering failures 2.Get acquainted with – ■ the Chair of Software.
ESDI Workshop on Conceptual Schema Languages and Tools
The RDF meta model Basic ideas of the RDF Resource instance descriptions in the RDF format Application-specific RDF schemas Limitations of XML compared.
Tutorial on XML Tag and Schema Registration in an ISO/IEC Metadata Registry Open Forum 2003 on Metadata Registries Tuesday, January 21, 2003; 4:45-5:30.
All Presentation Material Copyright Eurostep Group AB ® A Meta-model of EXPRESS in UML for MOF and UML to EXPRESS David Price April 2002.
The Relational Model. 2 Relational Model Terminology u A relation is a table with columns and rows. –Only applies to logical structure of the database,
UML Profile BY RAEF MOUSHEIMISH. Background Model is a description of system or part of a system using well- defined language. Model is a description.
Lecture 23 XQuery 1.0 and XPath 2.0 Data Model. 2 Example 31.7 – User-Defined Function Function to return staff at a given branch. DEFINE FUNCTION staffAtBranch($bNo)
Discussion about MFI-7: Metamodel for Service Registration Wang Jian, He Keqing, He Yangfan, Wang Chong SKLSE, Wuhan University, China
1 Chapter 2 Database Environment Pearson Education © 2009.
The Relational Model © Pearson Education Limited 1995, 2005 Bayu Adhi Tama, M.T.I.
Interpreting the Object Constraint Presented by: Ed Kausmeyer.
SEMI-STRUCTURED DATA (XML) 1. SEMI-STRUCTURED DATA ER, Relational, ODL data models are all based on schema Structure of data is rigid and known is advance.
Advanced Accounting Information Systems Day 34 XBRL Instance Documents and Taxonomies November 13, 2009.
Introduction: Databases and Database Systems Lecture # 1 June 19,2012 National University of Computer and Emerging Sciences.
Here is my personal thought about the key JP comments to MFI-5 CD5.
The Enhanced Entity- Relationship (EER) Model
XML QUESTIONS AND ANSWERS
Business Process Measures
UML Class Diagrams: Basic Concepts
Seminar 3 UML Class Diagram.
Entity Relationship Diagrams
Edition 3 Metadata registry (MDR)
ITEC 3220A Using and Designing Database Systems
ISO/IEC (MFI-6) Scope definition & Document Structure
Presentation transcript:

Issue 134: Specification of Constraints There is no standard way of specifying constraints –Constraints in MDR metamodel OCL expressions can 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

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 a Definition 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 associated with exactly one Conceptual Domain, as represented by the "data element concept-conceptual domain relationship" in Figure 8. MustBeRegistered, ShallBeAssociatedWith (9) The Conceptual Domain specifies all valid Value Meanings of a Data Element Concept. The Conceptual Domain is described in MustBeContained Constraints in Data Element Concept

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

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]]

[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

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. [C-2] FrozenAttributesCannotBeChanged 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(a))

[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: and -> notEmpty and implies (self.container.Object::non_existent() or not self.Object::non_existent())

[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(r))

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

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

[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())

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)) [C-8] ContentsMustNotCollideWithSupertypes

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

[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