Combined Metamodel for UCM Contributed by Anthony B. Coates, Londata 17 February, 2008.

Slides:



Advertisements
Similar presentations
Access 2007 ® Use Databases How can Microsoft Access 2007 help you structure your database?
Advertisements

CMSC 414 Computer (and Network) Security Lecture 13 Jonathan Katz.
Copyright © Cengage Learning. All rights reserved.
Observer Method 1. References Gamma Erich, Helm Richard, “Design Patterns: Elements of Reusable Object- Oriented Software” 2.
United Nations Statistics Division Principles and concepts of classifications.
Object-Oriented PHP (1)
Reza Gorgan Mohammadi AmirKabir University of Technology, Department of Computer Engineering & Information Technology Advanced design.
Fundamentals, Design, and Implementation, 9/e COS 346 Day 8.
VBA Modules, Functions, Variables, and Constants
Copyright © 2007 Ramez Elmasri and Shamkant B. Navathe Slide 4- 1.
Chapter 13: Object-Oriented Programming
Inheritance and Polymorphism CS351 – Programming Paradigms.
Course Instructor: Aisha Azeem
Abstraction: Polymorphism, pt. 1 Abstracting Objects.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
CSE341: Programming Languages Lecture 11 Type Inference Dan Grossman Winter 2013.
Dichotomous Phase The initial Dichotomous Phase of LCCS Classification Module Click one option of each pair of buttons. Or immediately identify to which.
Ch5: ER Diagrams - Part 2 Much of the material presented in these slides was developed by Dr. Ramon Lawrence at the University of Iowa.
Bite sized training sessions: Data Modelling – Part 1 of 2 Data Model Diagrams Feb 2011 Prepared by Guy Beauchamp Group Projects & IT.
C++ Object Oriented 1. Class and Object The main purpose of C++ programming is to add object orientation to the C programming language and classes are.
Design Patterns.
Database Processing: Fundamentals, Design and Implementation, 9/e by David M. KroenkeChapter 2/1 Copyright © 2004 Please……. No Food Or Drink in the class.
Software Requirements Engineering CSE 305 Lecture-2.
Lecture 7 Integrity & Veracity UFCE8K-15-M: Data Management.
In-Band Access Control Framework Group Name: WG4 SEC Source: Qualcomm Meeting Date: Agenda Item:
Management Information Systems MS Access MS Access is an application software that facilitates us to create Database Management Systems (DBMS)
COMP106 Assignment 2 Proposal 1. Interface Tasks My new interface design for the University library catalogue will incorporate all of the existing features,
Lecture Set 11 Creating and Using Classes Part B – Class Features – Constructors, Methods, Fields, Properties, Shared Data.
Question of the Day  On a game show you’re given the choice of three doors: Behind one door is a car; behind the others, goats. After you pick a door,
Copyright: ©2005 by Elsevier Inc. All rights reserved. 1 Chapter - 2 Basics of Sound Structure Author: Graeme C. Simsion and Graham C. Witt.
MS Access 2007 Management Information Systems 1. Overview 2  What is MS Access?  Access Terminology  Access Window  Database Window  Create New Database.
1 Relational Databases and SQL. Learning Objectives Understand techniques to model complex accounting phenomena in an E-R diagram Develop E-R diagrams.
IS 475/675 - Introduction to Database Design
UCM 2009 Vision Scott R. Hinkelman. Architecture and Glossary Goal will be to have the Architecture document and Glossary essentially completed “in content”
INFO1408 Database Design Concepts Week 15: Introduction to Database Management Systems.
Access 2007 ® Use Databases How can Microsoft Access 2007 help you structure your database?
1 Capturing Requirements As Use Cases To be discussed –Artifacts created in the requirements workflow –Workers participating in the requirements workflow.
Carnegie Mellon University © Robert T. Monroe Management Information Systems Data Modeling Management Information Systems Robert.
Topic 1 Object Oriented Programming. 1-2 Objectives To review the concepts and terminology of object-oriented programming To discuss some features of.
Object Oriented Software Development
Enhanced Entity-Relationship (EER) Modeling. Slide 4- 2 Chapter Outline EER stands for Enhanced ER or Extended ER EER Model Concepts Includes all modeling.
Copyright © Cengage Learning. All rights reserved.
Graphical Enablement In this presentation… –What is graphical enablement? –Introduction to newlook dialogs and tools used to graphical enable System i.
Chapter 6 – Architectural Design Lecture 1 1Chapter 6 Architectural design.
1 Class Diagrams. 2 Overview Class diagrams are the most commonly used diagrams in UML. Class diagrams are for visualizing, specifying and documenting.
WEB 2.0 PATTERNS Carolina Marin. Content  Introduction  The Participation-Collaboration Pattern  The Collaborative Tagging Pattern.
Working with XML Schemas ©NIITeXtensible Markup Language/Lesson 3/Slide 1 of 36 Objectives In this lesson, you will learn to: * Declare attributes in an.
COMPUTER ORGANIZATION AND ASSEMBLY LANGUAGE Lecture 21 & 22 Processor Organization Register Organization Course Instructor: Engr. Aisha Danish.
The Object-Oriented Database System Manifesto Malcolm Atkinson, François Bancilhon, David deWitt, Klaus Dittrich, David Maier, Stanley Zdonik DOOD'89,
13 December 2007 A Simple Logic For Contexts Anthony B. Coates, Miley Watts LLP, 13 th December 2007 Contributed to the UN/CEFACT.
1 CS 430 Database Theory Winter 2005 Lecture 3: A Fifty Minute Introduction to Data Modeling.
21/03/ Working with Controls Text and List Boxes.
CLASSIFICATION OF DESIGN PATTERNS Hladchuk Maksym.
Lecture 8: Collections, Comparisons and Conversions. Svetla Boytcheva AUBG, Spring COS 240 Object-Oriented Languages.
1 Database Design Sections 6 & 7 First Normal Form (1NF), Second Normal Form (2NF), Unique Identifiers (UID), Third Normal Form (3NF), Arcs, Hierarchies.
Databases (CS507) CHAPTER 7.
Microsoft Foundation Classes MFC
Enhanced Entity-Relationship (EER) Model
Topic 2: binary Trees COMP2003J: Data Structures and Algorithms 2
Session 2 Welcome: The sixth learning sequence
Business Process Measures
INTRODUCTION TO OBJECT-ORIENTED PROGRAMMING (OOP) & CONCEPTS
UML Class Diagrams: Basic Concepts
Learning Objective LO: We’re learning to understand when it is appropriate to use particular data types.
Sampath Jayarathna Cal Poly Pomona
Classes, Objects and Methods
Enhanced Entity-Relationship (EER) Modeling
C++ Object Oriented 1.
Spec model application
DataTypes Nigel Davis
Presentation transcript:

Combined Metamodel for UCM Contributed by Anthony B. Coates, Londata 17 February, 2008

17 Feb 2008slide #2Contributed by Londata Limited Models Two model proposals are to be combined Tree-based model Set-based model

17 Feb 2008slide #3Contributed by Londata Limited Tree-Based Model This is a generic, open-ended context- association model Most important association is “broader- narrower” Two important model diagrams – one for contexts, one for associations

17 Feb 2008slide #4Contributed by Londata Limited Tree-Based Model

17 Feb 2008slide #5Contributed by Londata Limited Tree-Based Model

17 Feb 2008slide #6Contributed by Londata Limited Tree-Based Model In the tree-based model, everything is a context This includes context categories, context sets, and individual context values Associations can exist between any pair of contexts, but the most common association is “broader-narrower”; another useful association may be “is identical to”.

17 Feb 2008slide #7Contributed by Londata Limited Set-Based Model The set-based model is less generic, relying on a pre-defined “types” of context (e.g. categories, sets, individual contexts) It shows explicitly how contexts are related to lists of codes and identifiers It shows how contexts are associated with artefacts like BIEs, processes, etc.

17 Feb 2008slide #8Contributed by Londata Limited Set-Based Model

17 Feb 2008slide #9Contributed by Londata Limited Set-Based Model The set-based model supports “broader- narrower” associations via the resursive relationship of “Context Category” to itself (but note, it has been discussed that the recursion needs to be changed to involve “Context Value” as well)

17 Feb 2008slide #10Contributed by Londata Limited Set-Based Model The set-based model allows a context to be assigned to an artefact, where that context can be derived as a union, intersection, or exclusion of other contexts Relies on the close association of context values to codes and identifiers to specify the contexts that are associated with an artefact

17 Feb 2008slide #11Contributed by Londata Limited Set-Based Model The set-based model does not provide a mechanism for storing pre-defined unions, intersections, and exclusions in the context model, for use and re-use by multiple artefacts The advantage of storing derived contexts in the model, and referring to them, is that the derivations can be updated in a single place as necessary

17 Feb 2008slide #12Contributed by Londata Limited Set-Based Model The advantage of being able to attach derivations of contexts directly to artefacts, without storing those derivations in the model, is that the model is not cluttered by derivations that are not re-used between artefacts

17 Feb 2008slide #13Contributed by Londata Limited Differences A key difference in the models, which makes them a little awkward to merge, is that the tree-based model uses a more generic, data-driven model The set-based model uses a more explicit model based on a pre-determined set of classes and associations

17 Feb 2008slide #14Contributed by Londata Limited Differences Generic models are always harder to read as models (you can't understand them full with out details of the data-driven usage), but are more flexible at run-time (fewer assumptions built into structure) Explicit models are easier to read as models, but are less flexible at run-time (more assumptions built into structure)

17 Feb 2008slide #15Contributed by Londata Limited Differences Note that the two proposed models are more similar than they may appear when you look at the models This is because of different choices not only in terminology, but in modelling style We'll try not to let such differences get in the way of merging the models

17 Feb 2008slide #16Contributed by Londata Limited Merging the Models Let's see how we can merge the models From the set-based model, we can immediately take the pieces that are not directly part of the context model itself, but which are important in relating the context model to artefacts, codes, and identifiers

17 Feb 2008slide #17Contributed by Londata Limited Merging the Models In a slight change from the original set- based model,  an artefact may or may not have a (business context). If it is not assigned a context, then it has no known business context, and is effectively unusable  a (business) context may be shared by multiple artefacts, or may be defined without being assigned to any artefacts

17 Feb 2008slide #18Contributed by Londata Limited Merging the Models We keep code lists and codes, identifier schemes and identifiers We don't need “Code Type” and “Identifier Type”, which are illustrative rather than a necessary part of a run- time model

17 Feb 2008slide #19Contributed by Londata Limited Merging the Models Code list and identifier scheme are special kinds of context union Code and identifier are special kinds of context

17 Feb 2008slide #20Contributed by Londata Limited Merging the Models The merged “context” concept needs to cover context categories, context value sets, and context values A context value set is just a union, so that is covered Context exclusions are essentially identical in both models, at least in terms of the result they produce

17 Feb 2008slide #21Contributed by Londata Limited Merging the Models A context union is broader than each of the individual contexts in the union A context intersection is narrower than each of the individual contexts in the intersection Recommended: A context exclusion is disjoint with any context that is the same or narrower than the excluded context

17 Feb 2008slide #22Contributed by Londata Limited Merging the Models A context value set is either a context union or a context with “narrower” sub- contexts A context union is a context value set for which “completeListIndicator” is implicitly true A context value with sub-contexts is a context value set for which “completeListIndicator” is implicitly false

17 Feb 2008slide #23Contributed by Londata Limited Merging the Models A context category is a special kind of context (i.e. derived from context) It's particular property is that context categories are mutually exclusive, i.e. if context A is in category A' (i.e. there is a direct or indirect “broader-narrower” relationship from A' to A), then context A cannot also be in another category B'

17 Feb 2008slide #24Contributed by Londata Limited Merging the Models Additionally, a category cannot be used as an artefact context, nor as part of a context derivation The sole purpose of a category is to group contexts that are orthogonal to the contexts in other (peer) categories

17 Feb 2008slide #25Contributed by Londata Limited Merging the Models Sub-categories are allowed, and must be orthogonal within their parent category A context category can only be narrower than another context category, not any other kind of context

17 Feb 2008slide #26Contributed by Londata Limited Merging the Models In order to associate artefacts with contexts, it needs to be possible to uniquely reference a context in the model So, to context is added an optional UID Any kind of unique identifier will do; could be XPath-style, or a GUID/UUID, or whatever is most appropriate and usable for the community of users

17 Feb 2008slide #27Contributed by Londata Limited Merging the Models To avoid filling the context model with single-use context derivations, we allow the following, which can't be shown in the model  each artefact may have its own private context structure consisting of context unions, intersections, and/or exclusions which are not stored in the context model  any other contexts used within these must reference the context model

17 Feb 2008slide #28Contributed by Londata Limited Merging the Models In writing “any other contexts used within these must reference the context model”, it's an open question whether the context model is actually multiple context models E.g. a context might refer to contexts in the CEFACT context model, and also to contexts in a local context model Should all work as long as the UIDs are unique across all context models in use

17 Feb 2008slide #29Contributed by Londata Limited Merging the Models Applying all of these things leads to the following merged model (in two slides):

17 Feb 2008slide #30Contributed by Londata Limited Merging the Models

17 Feb 2008slide #31Contributed by Londata Limited Merging the Models

17 Feb 2008slide #32Contributed by Londata Limited Merging the Models Hopefully, this merged model captures the important features of both proposed models However, your job as reviewers is  to ask for further explanation if anything is not completely clear  to flag any issues that you see from this particular merging of the models

17 Feb 2008slide #33Contributed by Londata Limited Caveats No internationalisation support is shown in the current model (e.g. names and/or descriptions in different languages), but some support will be necessary