Tools and techniques for creation, use and management of ... · Tools and techniques for creation,...

September 2010

A water information R & D alliance between the Bureau of Meteorology and CSIRO’s Water for a Healthy Country Flagship

Tools and Techniques for Creation, Use and Management of Information Models as Metadata for System-of-Systems Interoperability Rob Atkinson, William Francis, Rick Meng and David Lemon

Water for a Healthy Country Flagship Report series ISSN: 1835-095X

Australia is founding its future on science and innovation. Its national science agency, CSIRO, is a powerhouse of ideas, technologies and skills.

CSIRO initiated the National Research Flagships to address Australia’s major research challenges and opportunities. They apply large scale, long term, multidisciplinary science and aim for widespread adoption of solutions. The Flagship Collaboration Fund supports the best and brightest researchers to address these complex challenges through partnerships between CSIRO, universities, research agencies and industry.

The Water for a Healthy Country Flagship aims to provide Australia with solutions for water resource management, creating economic gains of $3 billion per annum by 2030, while protecting or restoring our major water ecosystems.

The work contained in this report is collaboration between CSIRO’s Water for a Healthy Country Flagship and the Bureau of Meteorology’s Water Division under the Water Information Research and Development Alliance (WIRADA).

WIRADA is a five-year, $50 million partnership that will use CSIRO’s R&D expertise to help the Bureau of Meteorology report on availability, condition and use of Australia's water resources. For more information about the partnership visit www.csiro.au/partnerships/WIRADA.html For more information about Water for a Healthy Country Flagship or the National Research Flagship Initiative visit www.csiro.au/org/HealthyCountry.html

Citation: Atkinson R., Francis, W., Meng R., Lemon D., 2010. Tools and techniques for creation, use and management of information models as metadata for system-of-systems interoperability CSIRO: Water for a Healthy Country National Research Flagship. 61 pp.

Copyright and Disclaimer:

© 2010 Bureauof Meteorology and CSIRO. To the extent permitted by law, all rights are reserved and no part of this publication covered by copyright may be reproduced or copied in any form or by any means except with the written permission of Bureau of Meteorology and CSIRO.

Important Disclaimer:

Bureau of Meteorology and CSIRO advise that the information contained in this publication comprises general statements based on scientific research. The reader is advised and needs to be aware that such information may be incomplete or unable to be used in any specific situation. No reliance or actions must therefore be made on that information without seeking prior expert professional, scientific and technical advice. To the extent permitted by law, Bureau of Meteorology and CSIRO, including each of its employees and consultants, excludes all liability to any person for any consequences, including but not limited to all losses, damages, costs, expenses and any other compensation, arising directly or indirectly from using this publication (in part or in whole) and any information or material contained in it.

Cover Photograph: Solid Ground logo Graphic design: Heinz Buettikofer © 2010 CSIRO

Tools and techniques for creation, use and management of information models as metadata for system-of-systems

interoperability Page iii

CONTENTS Acknowledgments ....................................................................................................... vi

Executive Summary .................................................................................................... vii

1. Introduction ......................................................................................................... 1

2. Theory .................................................................................................................. 2 2.1. Evolution of information models ................................................................................ 2

2.2. Model conceptualisation and modularisation ............................................................ 2

2.3. Governance, provenance and metadata .................................................................. 3

2.4. Distributed Governance ............................................................................................ 4

2.5. Versioning ................................................................................................................. 4

2.6. Vocabularies ............................................................................................................. 6

2.7. Solid Ground Model Registry and Repository .......................................................... 8

2.8. Platform independent model profiles (PIMPS) and platform specific models (PSMs)10

2.9. Object Relational (O-R) Mapping ............................................................................ 13

3. Methodology ...................................................................................................... 20 3.1. Scenarios ................................................................................................................ 20

3.2. Scenario 1: Reverse engineering a model from a database and creating a conceptual model ...................................................................................................................... 20 3.2.1. Scenario rationale ................................................................................................ 20 3.2.2. Pre-conditions ...................................................................................................... 21 3.2.3. Scenario narrative ............................................................................................... 21 3.2.4. Post-condition ...................................................................................................... 24 3.2.5. Points to remember ............................................................................................. 24

3.3. Scenario 2: Registering model components with dependencies ............................ 25 3.3.1. Scenario rationale ................................................................................................ 25 3.3.2. Pre-conditions ...................................................................................................... 25 3.3.3. Scenario narrative ............................................................................................... 25 3.3.4. Post-condition ...................................................................................................... 28 3.3.5. Points to remember ............................................................................................. 28

3.4. Scenario 3: Importing model components and all their dependent models components ................................................................................................................................ 29 3.4.1. Scenario rationale ................................................................................................ 29 3.4.2. Pre-conditions ...................................................................................................... 29 3.4.3. Scenario narrative ............................................................................................... 29 3.4.4. Post-condition ...................................................................................................... 32 3.4.5. Points to remember ............................................................................................. 32

3.5. Scenario 4: Updating existing model dependencies to a new version model (using name) ................................................................................................................................ 32 3.5.1. Scenario rationale ................................................................................................ 32 3.5.2. Pre-conditions ...................................................................................................... 34 3.5.3. Scenario narrative ............................................................................................... 34 3.5.4. Post-condition ...................................................................................................... 37 3.5.5. Points to remember ............................................................................................. 37

3.6. Scenario 5: Creating a “mapping model” to map between two versions of a model37 3.6.1. Scenario rationale ................................................................................................ 37 3.6.2. Pre-conditions ...................................................................................................... 37 3.6.3. Scenario narrative ............................................................................................... 37 3.6.4. Post-condition ...................................................................................................... 41 3.6.5. Points to remember ............................................................................................. 41


interoperability Page iv

3.7. Scenario 6: Updating existing model dependencies to a new version of a model (using “mapping model”) .................................................................................................... 41 3.7.1. Scenario rationale ................................................................................................ 41 3.7.2. Pre-conditions ...................................................................................................... 41 3.7.3. Scenario narrative ............................................................................................... 41 3.7.4. Post-condition ...................................................................................................... 43 3.7.5. Points to remember ............................................................................................. 43

3.8. Scenario 7: Creating Platform Independent Model Profiles (PIMPs) ..................... 43 3.8.1. Scenario rationale ................................................................................................ 43 3.8.2. Pre-conditions ...................................................................................................... 44 3.8.3. Scenario narrative ............................................................................................... 44 3.8.4. Post-condition ...................................................................................................... 45 3.8.5. Points to remember ............................................................................................. 45

3.9. Scenario 8: Forward engineering a Platform Specific Model (PSM) from a conceptual model e.g. PIM or PIMP .......................................................................................... 45 3.9.1. Scenario rationale ................................................................................................ 45 3.9.2. Pre-condition ....................................................................................................... 46 3.9.3. Scenario narrative ............................................................................................... 46 3.9.4. Post-condition ...................................................................................................... 49 3.9.5. Points to remember ............................................................................................. 49

3.10. Scenario 9: Using conceptual models to configure a controlled vocabulary .......... 49 3.10.1. Scenario rationale ................................................................................................ 49 3.10.2. Pre-conditions ...................................................................................................... 50 3.10.3. Scenario narrative ............................................................................................... 50 3.10.4. Post-condition ...................................................................................................... 51 3.10.5. Points to remember ............................................................................................. 51

4. Deployment Considerations ............................................................................. 52 4.1. Model Registry and general system metadatabase functions ................................ 52

4.2. Using the Solid Ground Model Registry with EA Version Control Configurations .. 52 4.2.1. Overview ............................................................................................................. 52 4.2.2. Deployment ......................................................................................................... 54

5. Future Development .......................................................................................... 58 5.1. Vocabulary system: ................................................................................................. 58

5.2. Solid Ground: .......................................................................................................... 58

References .................................................................................................................. 60


interoperability Page v

LIST OF FIGURES Figure 1 Roles and responsibilities in object registration (from ISO 19135) ............................ 4

Figure 2 Creating a new model version by updating an existing model .................................. 5

Figure 3 Creating new versions of related models .................................................................. 6

Figure 4 Current MDA best practice ........................................................................................ 8

Figure 5 Solid Ground Model Registry and Repository ........................................................... 9

Figure 6 The sequence of functions applied when registering models in Solid Ground to generate vocabulary configuration (UML) .............................................................................. 10

Figure 7 Roles of Conceptual and Implementation models ................................................... 11

Figure 8 sample conceptual model ........................................................................................ 12

Figure 9 Mapping an implementation class to a conceptual model ....................................... 12

Figure 10 Master-detail style implementation mapping ......................................................... 13

Figure 11 Example application schema ................................................................................. 14

Figure 12 Single table per class hierarchy ............................................................................. 14

Figure 13 Implementation of a specialised class in a “one table per class hierarchy” case .. 15

Figure 14 "One table per class" O-R mapping ....................................................................... 15

Figure 15 Implementation of a general class in a "one table per class" case ........................ 16

Figure 16 "Extension table" O-R mapping ............................................................................. 16

Figure 17 Implementing inheritance in extension table model ............................................... 16

Figure 18 Application schema dependency relationship ....................................................... 17

Figure 19 Class inheritance across schema boundaries ....................................................... 18

Figure 20 Using a class view to hide internal schema implementation details ...................... 18

Figure 21 Refactored class model ......................................................................................... 24

Figure 22 Model metadata view ............................................................................................. 29

Figure 23 Model contents (Feature Types) view ................................................................... 30

Figure 24 Model dependency view ........................................................................................ 31

Figure 25 Dependency Diagram ............................................................................................ 35

Figure 26 Package dependency diagram example ............................................................... 36

Figure 27 Generated “Model Mapping Diagram” ................................................................... 40

Figure 28 Generated “New Attribute Mapping Diagram ........................................................ 40

Figure 29 Using FullMoon to process a model package ........................................................ 53

Figure 30 Model Management and MDA using subversion ................................................... 55

Figure 31 Model Registry and local subversion integration ................................................... 56

Figure 32 Proposed vision for federated model registries ..................................................... 57

Figure 33 A workflow for MDA configuration of a metadata registry ...................................... 59


interoperability Page vi

ACKNOWLEDGMENTS The Authors wish to thank the Bureau of Meteorology’s Water Division under the Water Information Research and Development Alliance (WIRADA) and all the reviewers for their effort and valuable input.


interoperability Page vii

EXECUTIVE SUMMARY The CSIRO Sustainable Water Information Models (SWIM) project1 has developed a suite of tools that support users in creating and maintaining formal information models. These tools address specific problems facing the water informatics domain, but are based on, and generally applicable to formal modelling approaches in the broader spatio-temporal application domain, using the ISO/TC211 Geographic Information modelling framework (ISO, 1999).

The development of the tools was borne from experiences with formal information models and their application across several domains of application highlighting a number of common challenges (Atkinson and Box, 2007; Atkinson et al., 2007; Laxton et al., 2010; Osuchowski and Atkinson, 2008). There is, in general, poor support for modular information models, typical of situations where multiple stakeholders define different parts of a domain model. Existing tools have a pragmatic concern with single enterprise scope for projects, and identifiable business customers: this is how software is sold, but is not what broader communities need.

In response to these challenges, the SWIM project has created prototype or proof-of-concept tools to explore and test the feasibility of a more modular, multi-stakeholder modelling environment.

Descriptions of the theoretical basis and possible alternatives to the approaches considered will be dealt with in a series of planned publications. This report provides an overview of the technical aspects for the benefit of a practitioner who may wish to understand and apply the techniques described.

The tools address the multiple inter-related challenges and phases of model creation, management and use. As such they are a discrete set of functions that support a more general application methodology. A full articulation of such a methodology is planned for the future, pending further experience with the effectiveness of the techniques described here. A crucial success factor for this approach will be the emergence of infrastructure to enable sharing of resources.

This document describes the theory and the model management methodology with reference to user scenarios. A technical discussion of key aspects of the implementation is provided, followed by a discussion of the future directions of development.

1 This project is funded under the Water Information Research and Development Alliance with the Bureau of Meteorology.


interoperability Page 1

1. INTRODUCTION The water cycle knows no boundaries: it crosses geographic and thematic boundaries. This means that to successfully model water information, input is required from multiple domains, provided by different geospatial communities for issues such as groundwater, climate, and so on.

A conceptual model of a domain of application (a “domain model”) is necessary to enable practitioners to share data characterising aspects of the state of that domain. It is impossible to create a complete model of all aspects of a domain in the natural sciences, so sub-communities need to be able to describe their current understanding and terminology in the context of specific applications. Such models, or “application schema” typically describe data sets or data exchange formats in use within the community.

To manage a domain model over time requires formalised information models governed by their respective communities. This in turn implies a ‘system-of-systems’ modelling approach, providing a separation of responsibility and governance for each component and which supports a federated multi-domain model management approach.

This approach must support the modularisation of models, where each module may be governed by a different authority. The approach must also govern evolution over time, employing concepts such as versioning and dependency tracking. Finally, one must understand how they can be applied within operational systems such as databases and semantic vocabularies.

The CSIRO Sustainable Water Information Models (SWIM) project has developed a suite of tools that support users in creating and maintaining formal information models. These tools address specific problems facing the water informatics domain, but are based on, and generally applicable to formal modelling approaches in the broader spatio-temporal application domain, using the ISO/TC211 Geographic Information modelling framework (ISO, 1999).

The development of the tools was borne from experiences with formal information models and their application across several domains of application highlighting a number of common challenges(Atkinson and Box, 2007; Atkinson et al., 2007; Laxton et al., 2010; Osuchowski and Atkinson, 2008). There is, in general, poor support for modular information models, typical of situations where multiple stakeholders define different parts of a domain model. Existing tools have a pragmatic concern with single enterprise scope for projects, and identifiable business customers: this is how software is sold, but is not what broader communities need.

In response to these challenges, the SWIM project has created prototype or proof-of-concept tools to explore and test the feasibility of a more modular, multi-stakeholder modelling environment.

Descriptions of the theoretical basis and possible alternatives to the approaches considered will be dealt with in a series of planned publications. This report provides an overview of the technical aspects for the benefit of a practitioner who may wish to understand and apply the techniques described.

The tools address the multiple inter-related challenges and phases of model creation, management and use. As such they are a discrete set of functions that support a more general application methodology. A full articulation of such a methodology is planned for the future, pending further experience with the effectiveness of the techniques described here. A crucial success factor for this approach will be the emergence of infrastructure to enable sharing of resources.

This document describes the theory and the model management methodology with reference to user scenarios. A technical discussion of key aspects of the implementation is provided, followed by a discussion of the future directions of development.



2. THEORY The SWIM tools are underpinned by the concept of a Model Driven Architecture (MDA) (Chen et al., 2009; Mellor et al., 2004), which separates a formalised, platform neutral conceptual model from its implementation. Implementations may express parts of the complete model in multiple interacting components of a system using a platform specific model instead of the general formalism. With MDA, a single model is the point of truth for directly generated artefacts that form part of implementations, ensuring internal consistency as well as availability of a complete system model as reliable and up-to-date documentation.

The SWIM approach extends this principle to support interoperability across multiple stakeholders, and multiple application domains. Models are separated into components and stored in a repository and accessible to users (during design or system usage phases) in a suitable derived format. This is achieved via a registry which has the potential to facilitate governance processes and support additional metadata to assist in the use of the models.

2.1. Evolution of information models It is inevitable that there will be multiple overlapping or competing information models developed (and implemented in existing systems) for related application domains. Understanding of domains will evolve over time. Harmonisation of sets of such models may be used to limit the complexity of the whole, and achieve practical interoperability across related systems, introducing another source of change in such models. Thus there is inevitably a “population” of information models that need to be managed.

In a biological sense, evolvability is defined as the ability of a population of organisms to generate genetic diversity and evolve through natural selection (Colegrave and Collins, 2008). In a distributed information system the concept translates to the ability to introduce new components and update or replace existing components without compromising the ability of the system to support distributed applications.

As in biology, the “mutation rate” is critical to maintaining a healthy system – too high and interoperability contracts are unreliable and fragile, too low and it is too difficult to introduce change and technical obsolescence may overtake the system. We might consider one form of mutation to be a change in the information models of the system. Different approaches to governing such changes are possible, and will affect this “mutation rate”. Such changes may be constrained by forcing cross-system adoption of every change in a single common information model. Alternatively, laissez-fair changes in any part of the system may be allowed, with no requirement to maintain a completely consistent “current” version of the whole domain model. A compromise is possible whereby information models are componentized into interrelated modules and alternative versions of each component model may also co-exist.

This report describes the outcomes of exploring such an approach and the necessary tools required to maintain such an ecosystem of related models.

2.2. Model conceptualisation and modularisation In the “SWIM theory” a modular UML model supports the evolvability of a system-of-systems through a standardised, visually represented view of dependencies between components. Use of MDA principles ensures model dependencies reflect actual system interoperability contracts. Dependencies support practical governance considerations by highlighting which components are potentially affected by any change in any model module.

Managing such dependencies at the level of Application Schema (ISO, 1999) simplifies this process by supporting more granular governance and change processes than individual model elements, making it easier to visualise, avoid circular dependencies and ultimately clarify interoperability contracts through explicit subscription of stakeholders to the published information models.



In order to support distributed modelling across multiple domains, the domain specific models of existing systems need to be modularised, that is broken down into components representing concepts that may be relevant to the broader modelling community.

There are two types of component that may be interrelated:

Services that may be invoked in future; and

Data that needs to be assimilated into the system at design time.

2.3. Governance, provenance and metadata For each component we want to integrate or create, it is necessary to:

Create a model of the component

Relate it to the concepts in our application

Record the provenance of the component model (how it was created, when and what version).Governance is crucial to management of these resources, and should be reflected in provenance metadata for the resource. This provenance metadata is a crucial concept in the SWIM theory, but defining it completely is beyond the current scope of research. Once it is established that modularity and description of system of systems interoperability can be fully realised, then provenance metadata design can be explored in the context of emerging best practices in networked electronic resource sharing.

If a component system provides a formal information model of a transaction or service it provides, as part of its metadata (i.e. self-describes) then it is necessary to incorporate this model into the shared model of any application domain that uses this component. This may involve different strategies depending upon the degree of overlap between the component information model and the existing domain model, and the level of abstraction of the component information model.

The SWIM project aims to enable capture of relationships between related sub-domain models as they evolve over time. At this stage the full scope of such models to describe and enable integration is not considered, however it is regarded as a worthwhile goal to support a common formalism for information models as a starting point to describing such integrations.

Typically, a model describing a system component will be implementation-specific and mix various aspects that exist in the domain model – and some form of mapping, with possible domain model extension in some places will be required. Attempts to create broader interoperability between systems tend towards more abstract models (INSPIRE, 2007), but the individual implementation models may still be relevant.

Possible scenarios for handling relationships with a components implementation model include:

“map” the concepts from the component onto existing concepts in the domain model;

Update (to extend) the domain model with the abstract model of the component;

Register the abstract model of the component as a new component of the domain model.

The SWIM theory also seeks to support workable maintenance of these model systems over time through its versioning methodology, conceptual mapping principles and the creation of mapping artefacts, and functions to update models based upon explicit mappings or implicit mappings through common identifiers (currently implicit mappings are supported by the tools pending further research into a mapping paradigm).



2.4. Distributed Governance Governance mechanisms are critical in supporting modelling communities in publishing and reusing models in a distributed environment.

The Solid Ground tools have a preliminary governance framework, exposing provenance metadata and providing the ability to authenticate users on specific instances of the Model Registry.

The ability to handle versions and MDA derived artefact relationships significantly improves the available mechanisms for distributed governance of cross-domain model suites. The view is that Solid Ground provides necessary, but not yet sufficient, tools for model governance.

To achieve a complete solution to model management further work will be required. A governance system will need to be developed to support functions and metadata required around the ISO 19135 standard Procedures for Registration of Geographic Items (ISO 2004). Engineering improvements – such as “Cloud Computing” – are required to provision services to provide scalability, robustness and distributed back-up

Future research plans include the design and testing of provenance metadata reflecting these roles and the policies that apply to each register, and actions against these policies.

Register Owner Submitting Organization

Control Body Register Manager

Register Registry

Register User

1

1..*qualifier

qualifiedBy

1

1..*

appointer

appointedBy 1..*

1

delegatedBy

delegator1

1..*

owner

register

1

1..*

receiver

submitter

1..*

1

managed

manager

1..* 1content storedOn

1

1..*

operator

system

1

1

contentController

controlled

1..*

1..*

usedBy

user

1..*

1..*

accessor

accessedBy

ManagementLevel

User Level

ExecutiveLevel

DeploymentLevel

Registry Manager

1..*1..*

contentManager

systemManager

1..*

1decisionAuthority

decisionRequester

Figure 1. Roles and responsibilities in object registration (from ISO 19135)

2.5. Versioning A significant challenge with managing UML models is keeping model versions synchronised with dependencies, and with deployed system components.



Within a model, model elements are given global unique identifiers (GUIDS), even though these are not typically visualised, they form the basis of references between model components.

If a new version of a model is required, the simplest approach has been to update the model, leaving all object GUIDS intact. This preserves any relationships between related models and the updated model, but essentially loses the ability to maintain a model of existing system components. Figure 1 shows such a scenario, where it is impossible for a related model to maintain a stable relationship with the original model. This violates an essential requirement of model re-use: that the governance of dependent models should not interfere with the governance of the core model. With this close coupling it is impossible to update a model without first assessing its impact on all models that import it, but these may not be visible to the owner of the original model.

Figure 2. Creating a new model version by updating an existing model

Figure 2 shows how a related model may be versioned to maintain references to both original and new versions of a model. The ModelRegister performs multiple roles here

it allows the new version of a model dependency to be identified allows updated versions of object references to be accessed allows new version of related model to be linked to new version of dependent model,

while preserving original relationships between previous versions allows a client (modelling tool) to access the correct version of all components of new

models



Figure 3. Creating new versions of related models

Old versions can remain within the system, according to the governance policies of the community. This may include flagging old versions still relevant to existing system components to be flagged as deprecated, or indication of preferred status of particular versions.

2.6. Vocabularies Experience developing domain models suggests that a structural information model is coupled to a set of controlled vocabularies at implementation time. Sometimes these controlled vocabularies reflect loosely coupled information models – for example a reference to an organisation may be an identifier, but the register holding the organisation description will have its own information model, typically only relevant within the context of a specific implementation. This description may be exposed as facets of a term definition within a vocabulary of entities – so some form of information model is required to describe vocabulary definitions.

Realising a domain model may require in the order of 20-30 vocabularies (based on water, geosciences and other cases), of which a small subset are specific to the domain. One subset of vocabularies is feature type identifiers, which are directly sourced from a formal information model, but require the minting of externally usable identifiers. This concept is further explored in a separate paper (Atkinson et al.).

Likewise, properties of a feature type (e.g. attributes) may be required, for example if one wanted to create an RDF realisation of the feature type,

e.g. ex:employer rdfs:domain foaf:Person

If we have a formal model in UML that we want to share across platforms, the property ex:employer would need to be a resource, either derived from the model of Person, or referenced by it. The set of such properties of the feature type Person is a controlled vocabulary. Referenced (common) properties would likewise need to be managed as a controlled vocabulary.

Controlled vocabularies in general exist as a key part of the system information architecture, and to fully model the system it is necessary to be able to model the concepts represented by the set of terms. – For instance, .a feature of type “Cinema” may have a property which references an entity of type “town”. We do not need to model the concept of a town in the model of a Cinema, but we do need to implement a list of towns to populate the property in practice. Building such a list requires us to have a Feature type for the concept of town. The



SWIM tools provide the ability to maintain a vocabulary of terms connected to an information model expressed in UML. This will be further extended in future by allowing subscription to controlled vocabularies and reverse-engineering or directly importing a formal information model for each Feature Type implied by the existence of a set of instances – i.e. terms in a controlled vocabulary.

There is considerable debate over the optimal form of semantic information to be stored and queried in an information system. The SWIM project takes the view that:

Formal structural models may be defined in UML using the ISO 19103 Conceptual Schema Language (ISO, 1999);

UML models may provide a visual representation suitable for a domain modelling process with multiple stakeholders;

“Ontologies” (in the sense of the Semantic Web and OWL) may be derived from such models;

Well-formed ontologies with explicit packaging and governance may be used as the point of truth for a UML package (i.e. the UML reverse engineered from an ontology. (This is however currently problematic due to variability in ontology models and poor support for explicit governance of component ontology models).

Ontology engineering may be used to infer such models from sample data, or to test such models;

Controlled vocabularies are necessary to implement data products using any information model;

Models supply a sub-set of the controlled vocabularies needs for a system; Ontologies may be used to describe other types of relationships between concepts

once formal agreed models are published.

This viewpoint is supported by the use of formal models for interoperability standards across the spatial-temporal domain, such as (INSPIRE, 2007; Sen and Duffy, 2005) and other domains such as telecommunications (Duke et al., 2004) or bioinformatics (Komatsoulis et al., 2008).

In general, it is required to be able to reference elements defined in information models within higher-order semantic constructs such as OWL encoded ontologies. This requires registration of network accessible identifiers for such elements.

Thus, there is a need to create a Model Driven Architecture (Mellor et al., 2004) mechanism to bridge the process of model management with the concepts of, for example Linked Open Data (Bizer et al., 2008).

There are approaches to exposing contents of UML models, such as the Reusable Asset Specification (OMG, 2005), however these may be idiosyncratic and difficult to integrate into a system of systems, whereas exposing model contents in a more general vocabulary definition syntax may provide easier integration. ISO/OGC architecture defines a Feature Catalogue (As/Nzs, 2006), which can be implemented in a web accessible registry. (Stock et al., 2009). Registry implementation technologies such as ebXML may provide a suitable common syntax, however the initial goal is to develop the simplest possible solution with widest applicability in the Web context.

Multiple options may co-exist in an MDA solution however, driven by a single point of truth.

The SWIM project has assumed an MDA approach where Feature Types defined in an Application Schema may be expressed in multiple artefacts, accessible by one or more service interfaces. For example a single service will be responsible for defining web accessible URI for a concept, but another system component may need to express the same concept within a database lookup table, and make this available via a database connection. Irrespective of the service interface used to access the model, it must be possible to trace the definition back to the specific version of the model artefact containing the authoritative definition.



Current approaches to MDA do not connect artefact management and controlled vocabulary deployment to the domain modelling exercise. Figure 3 shows the control flows used in activities such as GeoSciML(Sen and Duffy, 2005), Water Data Transfer Standard (INSPIRE, 2007) and INSPIRE activities (INSPIRE, 2007).

Figure 4. Current MDA best practice

This current practice has several drawbacks:

Artefact versions are not explicitly related - schema, vocabulary, deployment profile (validation rules) should reference versions of other components they reference;

A high degree of technical skill is required to configure each component; It is difficult to check that a set of artefacts and components is self consistent; The coupling between concepts in the controlled vocabularies and domain models is

reliant on implementation choices; Relationships between terms in the vocabularies are not controlled, or predictable

(there is no formal information model of the vocabularies themselves). These issues can be addressed by treating the conceptual relationships between vocabularies as part of the domain model, and using MDA to configure and annotate the vocabulary implementations. Each vocabulary can provide an explicit type model and reference to a versioned conceptual model for those types. SWIM has explored, and successfully implemented a solution based on the hypothesis that a FeatureType in an ISO 19103 Application Schema can be defined for every type of concept in a controlled vocabulary. This type may be quite trivial – being just a term name, or may be more complex with a faceted definition of each entity. This FeatureType may be used as the object type in a register – i.e. a controlled vocabulary is a register of terms of a particular FeatureType – for example a vocabulary service may expose registers of Rivers, Catchments, Units of Measure, Organisations, Document Types etc. as simple vocabularies, allowing these information elements to be referenced within the context of loosely coupled domain models.

2.7. Solid Ground Model Registry and Repository The model registry is itself a component of the system metadata, and may provide mechanisms to assist discovery of related components at run-time.



Solid Ground supports users in implementing an information model architecture that is maintained with in a common repository, accessed and managed through a Model Registry. This allows the users of distributed systems and systems in related domains to have a definitive source of model information.

The Model Registry provides the following functions:

It exposes model relationships;

Provides internal analysis of dependencies to ensure dependencies between models are not broken; and

Supports version control through the identification of dependencies based upon version specific identifiers used in the registry.

The model repository is built using a relational database, implementing a registry meta-model (based on ISO 19135) that may be used as a general metadata database. It stores all the model elements, relationships and related artefacts. Figure 5 presents a user centric view of Model Registry and Repository and the key functions it currently supports.

Figure 5. Solid Ground Model Registry and Repository

Figure 5 shows a UML sequence diagram for the activity of generating a vocabulary configuration through registering a conceptual model of feature types.

In the context of an MDA approach, the actions initiated within the modelling environment cause generation of registered artefacts within the registry. The ModelRegistryGateway component executes a set of policies specific to the register (the register of models in this case) which results in rules-based transformation and generation of related register artefacts (such as FeatureTypes extracted from the model, and relationship assertions between these). These in turn trigger additional policies that generate derived vocabulary artefacts. These policies are internally expressed as business processes and executed using a BPEL engine, and it is envisaged that future research into policy characterisation would allow such policies to be registered as metadata for each register – providing a very powerful and extensible mechanism. The key question for such research would be whether federation (importing resources from external registers) can be adequately controlled with a formal and transparent policy notation mechanism.



Figure 6. The sequence of functions applied when registering models in Solid Ground to generate vocabulary configuration (UML)

At this stage of development the registry system currently comprises a set of unconnected nodes hosted by CSIRO on a number of restricted servers requiring authentication. These are managed by the Solid Ground development team. In future it is envisaged to deploy multi-user registries within a federation of nodes, implementing governance arrangements defined by policy metadata.

2.8. Platform independent model profiles (PIMPS) and platform specific models (PSMs)

Different levels of abstraction are possible in a formal information model. Traditionally MDA approaches separate “Platform Independent Models” (PIM) and “Platform Specific Models” (PSM). System-of-systems applications however need to support data products derived from one system and transferred to another – but these transfers represent a separate application to the underlying systems involved. Thus application models are related, and will share concepts that may be implemented quite differently as the data level, independently of the platform. A means of relation different levels of abstraction in the models is required. OMG provides an “out-of-band” mechanism called “Query-View-Transform” (QVT) – but within our system of systems the relationships are important parts of the overall system model, so a mechanism has been introduced to relate different levels of abstraction within the modelling environment. This mechanism has been provisionally labelled a PIM –Profile – or PIMP – based on the concept of a hierarchy of abstractions, with each profile constraining the implementation patterns further – making data types more concrete, selecting subsets of attributes and repackaging them into alternative structures. The PIMP mechanism allows the semantics to be traced from lower level abstractions to higher level concepts.

A platform independent model profile (PIMP) has the role of providing a model representation of a conceptual model that is more readily applied to implementation models, and facilitates an easier process of mapping between the implemented model and the conceptual model(s) from which it is applied.



A paper is in preparation which provides a more detailed and comprehensive discussion of this topic, and at some point a technical specification of the mapping idiom is required. The underlying premises are:

Different implementations are potentially concerned with different aspects of the same real-world objects;

Implementations are constrained by the meta-model of the implementation platform;

Domain models should contain all aspects of a domain that need to be agreed by participating components in applications within that domain

internal implementation details are not part of the domain model;

Conceptual models should contain the simplest representation of a domain, which will contain abstractions and normalised relationships;

Given a domain model, it is possible to derive an application schema that is “competent” to hold any objects described by the domain model – this could be a general-purpose transfer format or a data warehouse schema for example;

Implementations can be seen as logical views of the domain model, containing a sub-set of the domain model structured according to an implementation meta-model.

Figure 7 shows how different types of Platform Independent Model (PIM) relate to implementations.

Figure 7. Roles of Conceptual and Implementation models

The mapping between PIM (the conceptual model) and PIMP itself requires development of a new formalism, as no suitable candidate exists for this function. The separation of concerns within an evolvable MDA is a novel paradigm, synthesising the underlying best practices of MDA, UML and data warehouse design fields.



Figure 8 shows a simple conceptual model with a range of typical constructs – specialisation, attributes and relationships, including objects imported from another schema.

class ConceptualModel

Class1

+ id: ScopedName+ att1: CharacterString

Class2

+ id

Class3

+ id+ anAtt

Class4

+ att2: ScopedName

ImportedConceptualModel::ImportedClass

+ baseAtt: CharacterString

ImportedConceptualModel::ExternallyReferencedClass

+ refAtt: ScopedName

+externalRef

+aProperty 0..*

Figure 8. Sample conceptual model

Figure 9 shows a simple case where an implementation (myClass), contains a sub-set of attributes, with different names, that can be mapped to attributes in the conceptual model.

PIM to PIMP Mapping Diagram

RenamedAttribute::myClass

+ myAttribute: CharacterString

«MappingClass»Class1_myClass

ImportedClass

ConceptualModel::Class1

+ id: ScopedName+ att1: CharacterString +myAttribute

1represents

+att1

1

1«realizeObject»1

1 «mapsTo» 1

Name:Package:Version:Author:

PIM to PIMP Mapping Diagram«MappingPackage» BasicAttributeRenaming1MDA Tools Add-In

Figure 9. Mapping an implementation class to a conceptual model

More complex mappings are possible, including “master-detail” style mappings, as in Figure 10, where a single “flat” implementation class is used to handle multi-valued complex properties in the conceptual model.



PIM to PIMP Mapping Diagram

MultipleRowsRepresentation::ApplicationObject1

+ key1+ key2+ anAtt

«MappingClass»Class2_ApplicationObject1


+ id


+ id+ anAtt

+key2

+aProperty.id+anAtt

+aProperty.anAtt

+key1+id

1..*1

1

mapsto

1..*

+aProperty 0..*

Name:Package:Version:Author:

PIM to PIMP Mapping Diagram«MappingPackage» MasterDetailToMultipleVersionsPattern1MDA Tools Add-In

Figure 10. Master-detail style implementation mapping

This concept needs much further testing and elaboration. The SolidGround functionality represents a proof-of-concept that this approach can be used in an MDA environment. For example a PIMP mapping can be used to create a “Data Definition Language” (DDL) executable SQL artefact for a database view into a database created from the conceptual model.

2.9. Object Relational (O-R) Mapping A model driven architecture means the ability to create Platform Specific Models from our common model. A key platform is the relational database, providing persistence capability for data conforming to the model and supporting efficient query and access functionality. This requires mapping the object model to a relational meta-model – Object-Relational (O-R) mapping. There are several approaches to this, with different implications of modular models.

O-R mapping techniques and technologies abound in the business IT environment, as there is a very common need to provide “business objects” that exhibit specific behaviours, but can be maintained in persistent databases. Often this is a matter of mapping a business object to a legacy database schema. Our concern here is to consider the implications of modular information models on the ability to create relational database implementations. Defining a data product, derived from a conceptual model, that is not easily persisted raises barriers to adoption of the conceptual model.

The SWIM project has thus explored the ability to create relational database implementations that mirror the modularity of the conceptual model, to achieve the re-use of data implied by the re-use of common semantics in shared models. Broader issues of ORM for integration of legacy schemas or generation of business objects are not revisited here, although the ability to reverse engineer legacy schemas and create PIM/PIMP mappings manually may provide scope for such capabilities in future. Automation of these mappings will be complex, and it is suggested that existing software is likely to provide more powerful approaches that can be developed within the SWIM research scope.

This subject is to be covered in more depth in future technical report and paper, but is raised here largely to reinforce the perspective that MDA can be realised with a modular information model.



A key issue with modularity is that of inheritance: the definition of a feature type is likely to include aspects from more general types.

If we consider a simple model, such as in Figure 11, we can see that classes (feature types) may specialise a base class with additional attributes.

The SWIM theory also seeks to support workable maintenance of these model systems over time through its versioning methodology, conceptual mapping principles and the creation of mapping artefacts, and functions to update models based upon explicit mappings or implicit mappings through common identifiers (currently name is supported).

Figure 11. Example application schema

There are several options for converting this into a relation database model. One option is to create a single table with sufficient attributes to describe all the sub-types (specialisations), as in Figure 12.

Figure 12. Single table per class hierarchy

The Employee object could be realised with a constrained view of this table:



Figure 13. Implementation of a specialised class in a “one table per class hierarchy” case

There are several disadvantages to this approach however. If the class hierarchy is large there may be many attributes that are not required. It is necessary to add a layer of business rules somewhere to enforce the set of attributes defined in any specialisation – for example enforce that “Salary” is mandatory if PersonType = Employee. From the perspective of a model in a distributed system there is a more serious problem however: any new specialisation, or change to any component, requires a change to the common, shared implementation. This dramatically increases the governance overhead of the system, as a minor change in one application would require validation and testing in any affected application. An alternative is “one table per class”, as in Figure 14.

Figure 14. "One table per class" O-R mapping

This is better, but still has some problems from a distributed system perspective: changes in the base class require propagation to each implementation. This may lead to an inconsistent state in the system, where only some implementations have been changed. Furthermore, the approach has lost the generalised concepts – to generate a list of Person for example, we would need to perform some trick, as in Figure 15.



Figure 15. Implementation of a general class in a "one table per class" case

Aside from the potential difficulty in making this perform well, the implementation of the common case will be dependent on the robustness of each implementation. Each new extension of the domain model will once again be forced to propagate a change to a common implementation – leading to complex and unwieldy governance processes. An alternative makes more sense from our point of view: the “extension tables” approach, where each class has a table, but specialisations extend a base table, as in Figure 16.

Figure 16. "Extension table" O-R mapping

This may be implemented with a join, as show in Figure 17.

Figure 17. Implementing inheritance in extension table model



The extension table model particularly suits a modular application schema environment, as such views can encapsulate the internal implementation of the base class. Consider the case where separately governed application schemas are related, as in Figure 14 and Figure 15.

pkg Package dependencies

«Application Schema»Person

+ Customer

+ Employee

+ Person

(from Test Cases)

«Application Schema»Employee

+ Casual

+ Permanent

(from Test Cases)

«import»

Figure 18. Application schema dependency relationship



Figure 19. Class inheritance across schema boundaries

Using the extension table approach, and a view for each class, the dependent schema is only reliant on the stability of the logical view – not the underlying implementation of the entire Person schema.

Figure 20. Using a class view to hide internal schema implementation details



The SolidGround tools will automatically create these views when generating a DDL for an application schema, so the potential additional burden of a more complex database schema is mitigated. This illustrates again the notion that modular models may require more complex implementation, but the MDA approach can be used to hide this complexity to create stable, reusable components that accurately reflect the model.



3. METHODOLOGY

This section provides an overview of the model management methodology through scenarios using the combined functionality of the Solid Ground tools.

3.1. Scenarios

Experiences with model management and MDA approaches have led to identification of a set of issues where existing tools provide little or no support for reliable re-use of component information models.

The scenarios described below show the usage of prototype tools in the SolidGround suite to address these issues:

1. Reverse engineering a model from a database and creating a conceptual model

2. Creating and registering model components with dependencies

3. Importing model components and all their dependent model components

4. Updating existing model dependencies to a new version model (mapped by name)

5. Creating a “mapping model” to capture the relationships between two versions of a model

6. Updating existing model dependencies to a new version of a model (using “mapping model”)

7. Creating Platform Independent Model Profiles (PIMPs)

8. Forward engineering a Platform Specific Model (PSM) from a conceptual model e.g. PIMP

9. Using conceptual models to configure a controlled vocabulary

3.2. Scenario 1: Reverse engineering a model from a database and creating a conceptual model

3.2.1. Scenario rationale

An existing database represents implicit model information describing this as a potential component in an interoperable system.

In the case of a domain without a formal model, such a database contains the seeds of a domain model (limited to the operational scope of the database, but nevertheless valid). In this scenario a modeller refactors models reverse engineered from one or more sources to extract common concepts and register the definitions in a conceptual model, which should be free of redundancy and mutual dependencies between independently governed components.

Semantics (concept definitions) and “feature identifiers” are the key entities that need to be directly assimilated at design time. Further Scenarios will demonstrate how these can be later registered and published to support others subscribing to such reusable resources in a distributed system. This is seen as the long term future of an evolving system.



3.2.2. Pre-conditions

There exists the model in a RDBMS. Solid Ground supports a range of database technologies, currently including: MySQL, Postgres, Oracle and SQL Server

3.2.3. Scenario narrative

User selects Select Model/Package you wish to import the converted DB to UML model into. User selects Add-in > Solid Ground > Import PSM tools > Database to UML

User selects the Database type and configuration.

User selects a set of tables from the database



At this point, the user may select a “Database profile” to create a PSM (platform specific model), or the ISO 19100 profile, to create a platform independent model). Tools to create database-specific views already exist, but the ability to directly abstract a database schema to the ISO 19103 conceptual schema language is extremely useful and saves laborious editing of the imported model.

User selects a “Data Type Mapping File”. Solid Ground provides a suite of default mapping files under the installed directory, and will choose a sensible default based on the database type being accessed.

This Mapping file has the role of defining how DB elements will be translated into UML elements. The figure below shows an example of how this translation is defined in the mapping format.



Select Generate and the selected tables from the database and the mapping files will be imported into the EA project. A simplified example (using the ISO profile) is shown below (real cases will be much more complicated, make it hard to illustrate the principle).

Here the model elements can be refactored into cleaner abstractions, this stage requires detailed knowledge of how the underlying concepts are applied in the database. There is no one-size-fits all approach to do this, it will be dependent upon the nature of the underlying information model and how the database has been implemented. An example is provided below.

Take classes “WaterVolume” and “WaterQuality”, with common attributes CreatedBy and CreateDateTime. . The classes can be refactored to produce a single parent class that contains the common attributes:WaterMeasurement as in Figure 21.



Figure 21. Refactored class model

Because much of the logic of a formal model, including predictability in a model-driven architecture, stylistic consistency and avoidance of ambiguity are realised through use of a common modelling idiom (ISO 10103 conceptual Schema Language) a set of tools are provided for “model hygiene” to assist in creating a conformant Application Schema. For more details see: https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/HollowWorldHelperPlugin. (Atkinson, 2009)

3.2.4. Post-condition

DB information model exists in the selected UML idiom.

3.2.5. Points to remember

Mapping file examples exists, but tuning may be required to meet the format of the DB.

Conceptualisation of the implementation models is required, but this must performed by a modeller and cannot be automated (thus no function in Solid Ground can perform this step).

Reverse engineering is also supported for limited ArcGIS models.

OWL models may be supported in the future, initial experiments here have highlighted that individual OWL authors have widely varying approaches to handling the basics of how features interrelate, and it is difficult to predict how the concepts in ISO 19109 General Feature Model are expressed in a given OWL model.

Translation is performed according to xml mapping prescriptions. A suite of standard XML files are provided. These may augmented to suit specific modelling requirements.



3.3. Scenario 2: Registering model components with dependencies


Here the user wishes to register their conceptual model into the Solid Ground Model Registry in such a way that allows components of the model to be reused by other models, with metadata of the model component preserved and the contract explicit. Once registered, the tool allows users to visualise dependencies to and from the model and import dependencies as required (this is covered in Scenario 3).


Conceptual model exists and conforms to the ISO 19103 Conceptual Schema Language idiom. This may be designed from the “top-down” or refactored from one or more imported implementation models.


The user takes the conceptual model and registers it in the model registry.

Take the following example from Scenario 1:

Here the classes that represent a distinct conceptual component are able to be moved into their own UML package with the “Application Schema” stereotype. (Note that the <<FeatureType>> stereotype is the default interpretation and is not explicitly specified.



The dependencies across packages can be generated, either manually or by using the “Create dependencies diagram” tool in the HollowWorld Helper suite (Atkinson, 2009).

Note that this diagram is generated using another Software add-in “Hollow World Helpers”. The next step is the registration of the models. This process is relatively straightforward and requires the use of the Solid Ground tool: Model Registry tools > Register Models.

Right-click on the model component (package) that you wish to register and select the Solid Ground Add-in, Model Registry > Register Model.

If you have not previously logged-in to the server, your authentication details will be required.

Select the option to “Register in the Registry server”. The option exists to “Register in local SKOS file” if you wish to distribute using a file in SKOS format.



Next an option will appear to select “Publish Vocabulary Options”, these options are relevant to Scenario 9 (see section for more details).

At the point of registration, there will be an evaluation of dependent models. If the model component being registered does not have all its dependent models already registered in the Solid Ground registry then the user will be notified, providing the option to “Ignore” and break the link to the dependent model or “Abort” to go back to your packages and register first the component that was identified in the alert.

When the components have been registered in with their dependent models first registered, they will be available in the Solid Ground Model Registry Brower with their “dependency tree”. To view this, select Add-in>Solid Ground>Model Registry tools>Browse Model Registry.




Model components will be registered in the Solid Ground registry, with information on the creator of the model component. These components will be available for others to “import” and reference in their models.


Dependencies are important and the registration tools will help ensure that you maintain dependencies.

Circular dependencies are not part of the ISO 19100 idiom and are not well supported by Solid Ground.

There may exist erroneous dependencies in your models (particularly if they are haven’t been checked in detail) and the registration process will help identifying any incorrect dependencies.



3.4. Scenario 3: Importing model components and all their dependent models components


A second modeller/ modelling community wishes to import a model into EA to explore and/or reuse components from it. The user requires also that they import all model components that the selected model is dependent upon so that all information defining the model is maintained.


Model is registered in the Solid Ground registry and the user wishing to import has access to the registry (see Scenario 2 for more details).


User selects Add-ins>Solid Ground >Browse Model Registry.

Select model:

The interface is fairly limited at this stage, but significantly better than browsing subversion repositories by file name – model metadata is shown for each model. Search functions, history, profiles (say for example “GeoSciML development trunk” could show the latest versions of GeoSciML governed packages), saved filters are all possible.

Figure 22. Model metadata view

It would even be possible to find an application schema by a Feature type it contained, currently these can be browsed:



Figure 23. Model contents (Feature Types) view

Likewise, a model can be located by its dependencies, related artefacts or use by other models, or ultimately any aspect of the system metadata pertaining to the model.



Figure 24. Model dependency view

Once the appropriate component has been identified, select the Import option, which will show the dependency dialogue:



Select all dependencies. (Note in future only dependencies not currently loaded will be selected by default, including information about version update requirements if an older version is currently loaded.)

Select Next and the function will import all models required.

Note that all models and dependencies are identified in the registry functions using GUIDs created in Enterprise Architect. If two models have the same name and version number but not the same GUID, then registry tools will correctly recognise the models as being different, allowing multiple versions of models to be managed simultaneously. Hint - The Solid Ground function “Get GUID” allows the user to find this identifier for an element in your EA project browser.

If dependent models already exist in the user’s project (as determined by ID), then the tool will identify the models and request whether the user wishes to replace or use the existing model component.


User has imported the desired model and any dependent components into their active Enterprise Architect project.


If dependent model has already been imported you will be able to update to that existing model.

All models and dependencies are identified in the registry functions using GUIDs created in Enterprise Architect. The Solid Ground function “Get GUID” allows the user to find this identifier for an element in your EA project browser.

3.5. Scenario 4: Updating existing model dependencies to a new version model (using name)


A new version of a model that defines ISO TC211 standards or a domain has been produced and a modeller who was using concepts from the previous version of this model wishes to update to the new model and preserve these dependencies.

Dependencies between model components can exist in a number of forms. Where EA draws a dependency this may be hidden from the diagram and otherwise they may only be seen in multiple layers of properties.

For example where an attribute in the class of a dependent model (model A/WaterMeasurement below) has its data type defined by the class of a reference model (model B/ISO 19156 Observations and Measurements) this dependency between the two model is only found by going into the properties of the class, looking up the attribute data type name and finding it in the project browser list (this is new to version 8 of EA, prior to this it required searching names and performing trial and error tests). The figures below demonstrate this process.



To find these dependencies manually can be a challenging and error fraught task – this tool automates the search and conformance of dependencies when importing (see scenario rationale for more details).


Modeller has model A dependent on model B and both are present with correctly described dependencies in the EA project. A new version of model B exists in the Solid Ground Model Registry.


Modeller has a dependency of their model “WaterMeasurement” to the reference model “ISO 19156 Observations and Measurements”.



Figure 25. Dependency Diagram

Figure 25 shows a Dependency Diagram generated from HollowWorld Helper Plugin: Generate Package Dependencies Diagram.

The reference model has been updated from version 1.0.0 to version 2.0.0 and the modeller wishes to update to the new reference model and preserve the dependencies they have modelled.

Modeller selects the model “WaterMeasurement” in EA’s project browser and right-clicks selecting Add-in>Solid Ground>Model Registry tools>Update Model Dependencies Using Registry.

Modeller selects “Change existing models” to update directly into the EA project, otherwise an XMI file can be generated which can later be updated into the project.

User selects the new version of the reference model “ISO 19156 Observations and Measurements” in the Registry Browser and selects the “update” button.



Dependencies will be updated. These dependencies (references to a class or specification of an attribute type) will be performed through matching by name. If the class name has changed between versions dependencies will not be updated, but can be detected through package dependencies to the old package persisting after update. This process gets the vast majority of updates – a process that takes hours or days and is difficult to check is complete otherwise. Name changes can potentially be handled by the presence of inter-version mapping models (mapping models are discussed in scenarios 5 and 6). NB – dependencies cannot be not matched by ID as these IDs must be unique across models and versions (see Theory section on versioning).

Figure 26. Package dependency diagram example




User has model A and the updated model B in their EA project browser with dependencies preserved (as were matched by names of classes/attributes across the two versions).


Dependencies may not be evident and this tool automates the search and conformance of dependencies when importing (see scenario rationale for more details).

Both model A and the previous version of model B must already be in the modeller’s EA project.

The update of dependencies to a class or attribute will only perform through matching by name and not ID or mapping classes (mapping classes are discussed in scenarios 5 and 6). They are not matched by ID as these IDs have been determined to be unique across models and versions (see Theory section on versioning).

3.6. Scenario 5: Creating a “mapping model” to map between two versions of a model


The user wishes to model the relationship between two models, which may each be composed of a number of components, and may have a range of calculated functions performed on their attribute values (e.g. concatenation, sum of values, etc.) in order to be mapped.

These mappings may define the relationship between versions of models or profiles. These relationships can be exploited with the dependency updating utilities provided by SolidGround, so some form of recording such mappings is required. Whether the PIMP mechanism is most appropriate for recording and annotating such changes is an open question, it is used here for convenience in the absence of a standard way of recording such changes. (For more information on profiles see Theory section on Platform Independent Model Profiles).

The Mapping creates visual links to profiles/version and provides an artefact to define the lineage between models.

Also the user may in future wish to perform version updates based upon this mapping (see Scenario 6.) Note that a copy may be created using the Version Management/Create a new version tool – which will automatically create a mapping model. This scenario handles the case of more general mappings between similar models, or if version creation has been done by other means.


Two related models exist in EA project browser. The narrative assumes these are versions of a model.


User has two versions (1.0 and 2.0) of the model component “Site”.

User selects version 1.0 and right clicks, selecting Add-in>Solid Ground>Concept/Implementation Mapping tools>Create Model Mapping



Selecting the function “Auto Mapping” will create a mapping from attributes in v1.0 to attributes in v2.0 where the name is identical. Selecting “Basic Mapping” would allow the modeller to create simple Source -> Target mappings where the name is not like.



Where a function must be performed on the attributes, the modeller selects “Calculated Mapping”. In this example the modeller wishes to map the attributes “Longitude” and “Latitude” in v1.0 to the single attribute “Coordinates” in v2.0. This is done by correctly selecting the destination attribute and using the function CONCATENATE.



The modeller saves all mappings and selects “Complete”.

Now a new package will exists in the EA project with the stereotype “Mapping Package”. It formally models the mapped relationship. It also automatically generates diagrams showing the mapped attributes and how new attributes have been calculated.

Figure 27. Generated “Model Mapping Diagram”

Figure 28. Generated “New Attribute Mapping Diagram




Both models exist with a separate mapping package in the EA project browser as an artefact defining explicitly their relationship.


Mappings are limited to attributes.

3.7. Scenario 6: Updating existing model dependencies to a new version of a model (using “mapping model”)


Simple name matching when updating dependencies would not handle, for example, the simple case where a class name has been changed between versions – for example to correct a type, or reflect a more general description – both common cases.

To predict equivalence is a hard problem, but for many reasons we may wish to record the changes in a formal mapping model – which could be used for example to create an adaptor component between two components using different versions of the model (provided of course that sufficient semantic correlation remains between versions).

Such a mapping model can be used to drive dependency updating in a more comprehensive manner than just name matching.


The user has modelled the relationship between two models, “Site” and “WaterMeasurement”. The user a formal mapping model (as described in Scenario 5) has mapped version 1.0 of “Sites” to version 2.0 of “Sites” which are both in their project browser and generated using the Solid Ground function “Create a new version” (this function is described within the scenario). The user now wishes to perform an update of the model “WaterMeasurement” dependencies to now make it dependent upon the new version of “Sites”.


User right-clicks on the package for “WaterMeasurement” and selects the Solid Ground function “Create a new version”.

The user then specifies the change to the name (where appropriate), the new version number and chooses the option to “Create a Mapping Model”.



This new version has been created as a ‘clone’, in anticipation of future changes that will be made the model to distinguish it from the previous version. In this scenario, the change will be to update the model’s dependencies.

Now the updated version will maintain its dependencies to Site v1.0.

Next, select the new version of WaterMeasurement (v2.0.0), right-click and select the Solid Ground function “Check for a new version of related packages”.



Ensure that the external package “Site v2.0” is available and then continue. Note: this process of cloning connectors in this function is equivalent to ‘updating dependencies’.

Now the new version of WaterMeasurement will be dependent upon version 2.0 of the model Site.


The target application schema now has dependencies updated using the specified mappings.


The two initial versions of the conceptual model and dependent model must be mapped using the Solid Ground mapping idiom (includes defining the relationship Stereotype as “mapsto”). Currently this must be done using the function “Create a new version” for both mapping models.

Mapping will only cover dependencies to classes and attributes, not other UML objects.

3.8. Scenario 7: Creating Platform Independent Model Profiles (PIMPs)


The modeller wishes to provide a model that is conceptually consistent but provides information that can be easily translated into implementation models (a.k.a. Platform Specific Models, PSMs). Thus this intermediary model has been ‘flattened’ in the conceptual sense, representing a profile of the conceptual model.

See the section Error! Reference source not found. for further explanation.




The user has a conceptual model in their EA project (this could be first imported from the Solid Ground Model Registry, see Scenario 3).


This path in the scenario is similar to Scenario 5; however the starting point is to have only the version 1.0 of the model component “Site”.

The modeller right-clicks on the “Site”, selects Add-in>Solid Ground>Concept/Implementation Mapping tools>Profile PIM – create PIMP.

At this point, a PIMP containing a clone of the profiled FeatureType is created. Unneeded attributes may be deleted, but additional or different attributes derived from the original class can be created. The scenario assumes such a case.

The modeller then right clicks on the class “Site” and selects “Add Attribute”

Similar to Scenario 5, the user specifies the function and inputs and the attribute name being mapped to.



Modeller Saves mapping and selects “Complete”.

The same Mapping package will be generated as in the previous path, with an addition model package “PIMP – Sites v1.0”.


Both models (the original conceptual model, or PIM), and its derived profile (or PIMP) co-exist in the EA project along with separate mapping package an artefact defining explicitly their relationship.


Mapping dialogue is limited to attributes, although in the mapping idiom mappings can include relationship properties as well.

The “platform independent implementation profiles” (PIMP) will reflect only the current state of the conceptual model. Thus, the mappings and derived artefacts (the PIMP model) will require systematic version control and dependency management – in the form of policies to determine the status of a derived artefact if the source is changed.

3.9. Scenario 8: Forward engineering a Platform Specific Model (PSM) from a conceptual model e.g. PIM or PIMP


This tool provides a configurable ability to transform an information model - i.e. a PIM (Platform Independent Model) to a specific database schema (DDL). Most UML tools provide



some ability to do this, but this tool specifically supports the concept of a shared domain model, made of libraries or re-usable model components. This tool provides the ability to create a database schema for each model package, allowing isolation of changes when the model is used to document and maintain complex databases. This tool allows complex data types (such as spatial and temporal) to be mapped to multiple database columns. Tables are created for each FeatureType class. Inheritance is handled by extension tables and views to implement joins.

3.9.2. Pre-condition

The user has a conceptual model in their EA project (this could be first imported from the Solid Ground Model Registry, see Scenario 3).


Select the Solid Ground Add-in, then select the function Generate PSM > UML to Database. Select the database vendor type. When you generate SQL DDL for your UML model, it conforms to the database type that you select here.

Select one of more packages which you want to transform to a database schema from the "Select Import Packages" window



Specify the data type mapping file (a default based on the target database type is selected automatically). This data type mapping file is a XML file. It tells the application how to map a UML data type to the selected database data type. For example, to map the ISO 19100 data type "CharacterString" to Oracle data type "VARCHAR2", the following xml element need to be added in the mapping file.



A set of default xml mapping files are provided with the software, in this scenario the default file “ISO1900toMySQL.xml” was selected.



Provide the target location and name for the generated DDL file, and then select “Generate”.


A set of DDL files will be generated defining a database schema to match each application schema selected.


See section 2.8 for more details on the concepts underlying this scenario.

Tables are created for each FeatureType class. Inheritance is handled by extension tables and views to implement joins. Translation is performed according to xml mapping prescriptions. Standard xml files are provided but it may be required that these files be configured to suit specific modelling requirements

3.10. Scenario 9: Using conceptual models to configure a controlled vocabulary


The user wishes to use information models that have been modelled in UML to configure (establish the structure and annotate) a controlled vocabulary as a network accessible resource. For example the concept catchment would be modelled and through this process would become a referenceable term, as well as the type model for a register which could contain list specific catchments, e.g. Murrumbidgee, Murray, etc.



This concept is explained in detail in a journal paper.(Atkinson et al.) Future development of the Solid Ground tools will have a strong focus on further enhancing the functionality to create model driven controlled vocabularies (see section on Future Development.)


User has an application schema as a UML model that models Feature Types and Code lists.


User wishes to use an existing conceptual model that defines Feature Types and or Code lists that are relevant to a controlled vocabulary (see Theory section for more on controlled vocabularies).

See scenarios 1 and 2 for examples of conceptual models.

User selects the tool Add-ins>Model Registry Tools>Register Models (if the model has already been registered in the Solid Ground Model Registry, then simply re-register the model to initiate the Publish Vocabulary function). User then selects “Register in the Model Registry”.

User selects class types you wish to have stored in a secondary register, of model 'vocabularies'. For an application schema it would normally make sense to have both Feature Types and CodeList registered as vocabularies. The next release of SolidGround will populate the contents of a CodeList as instances in the vocabulary.

(NB this is currently only internally visible – a public example is required and will be deployed at some future date).

Finally the Feature Types and/or Code Lists will be available on the Vocabulary Service.




The CSIRO Vocabulary Service will now be configured to have registers of the models Feature Types and/or Code Lists. This will include:

An entry for the model package in the register of model packages (i.e. any other derived component can reference this specific version as metadata), and from this potentially access dependency and change history information.

A register created for the model, containing entries for each model element – allowing reference to the feature types in other systems

A register created for each feature type and CodeList – i.e. configuration of a vocabulary that can be populated with instances later

In the next release, CodeList contents will be populated as instances in the register created for that CodeList.


This functionality exists as a prototype, and the vocabulary service component is only currently available on the CSIRO internal server <http://virt06-wron.nexus.csiro.au:9080/SkosLookup/>.

If you have already registered the conceptual model, then simply re-register the model to initiate the Publish Vocabulary function



4. DEPLOYMENT CONSIDERATIONS This section covers the pragmatics of deployment and utilisation of the SolidGround Tools. Some future plans and ambitions are provided to add context to these issues – and provide the basis for feedback about community needs for such tools. Merely describing the current state of development would not adequately explain the concepts or potential of these tools.

4.1. Model Registry and general system metadatabase functions The long term goal is to define an interface for model registry functions, and deliver this from a general purpose metadatabase following the logic that system metadata includes information models. Such a generalised metadatabase may be, for example, a relational database as part of a data warehouse, a triple-store supporting semantic reasoning, or an EbXML Registry/Repository implementation. Alternatively, a model registry could be implemented as a lightweight stand-alone option specifically to support modelling activities, or delivered as an infrastructure component. In the short term, the model registry may form a component of an environment, with harvesting of content via the vocabulary service interface into the run-time metadatabase. The harvest policies decouple the rather basic security mechanism and untested performance of the interim registry implementation from the demands of a high-availability run-time metadatabase. Integration of a standalone model development environment with a run-time metadatabase may exploit several options for accessing the model contents:

SKOS export format Vocabulary services (SKOS format) XMI artefacts Web service interface to model registry Database connection to model registry

Note that all these approaches with the exception of the XMI file format use prototype proof-of-concept interfaces and formats that are not yet stable. Current work includes discussion with the Bureau of Meteorology on requirements for stable versions of these interfaces. Recommendation: SolidGround model registry can be deployed in a development environment with user-customised processes to migrate model information exposed by the SKOS vocabulary services into run-time metadata systems.

4.2. Using the Solid Ground Model Registry with EA Version Control Configurations

4.2.1. Overview

Subversion may be used to manage version control of model components, as described by the HollowWorld (Cox) environment. This works well in terms of providing strong control over edit controls, history and versioning, but suffered from a number of problems:

Dependencies between models in separate subversion managed XMI files are not accessible or visible to the user;

Loading a model file without loading its dependencies creates an incomplete local copy of a model without warning;



Metadata about contents of individual files is not visible, requiring external instructions identifying location of each file required to load a model;

Versioning strategies and publication status are devolved to individual communities – leading to inconsistent use of subversion mechanisms such as release tags, branches etc.;

Ditto with regard to model modification vs. cloning packages (with SVN it is possible to copy and edit, or clone a package with new internal object Ids, leading to inconsistent versions of models with the same object ids);

A cross-domain modelling exercise may lead to many (ten or more) individual subversion configurations, each of which is checked at model load time and requires maintenance;

It is not possible to search models in multiple subversion repositories containing XMI files to locate specific elements (except by checking all files out and running a local text search using deep knowledge of XMI structure to interpret the results);

Identifying potential updates to packages in local modelling environment is not possible (EA supports a GetAllLatest function that provides little opportunity to review changes and determine appropriate update strategy);

It is not possible to see which external models may be affected by a change to a model package.

We can extend the analysis to include aspects of model exploitation in a Model Driven Architecture. Presently MDA is limited to generation of GML schemas, using for example the FullMoon utility. (Cox). Figure 4 shows how FullMoon uses files from the subversion repository, and the typical process of checking in the generated schema to the repository.

act FullMoonProcess

FullMoon

DomainSubv ersionRepo

«WorkingCopy»ModelXMI

GMLClassMaps SWEClassMaps

DomainGMLSchema

DomainModel

«flow»

«flow»«flow»«flow»

«trace»

Figure 29. Using FullMoon to process a model package

There is a need to relate generated artefacts to the models that generated them. This is typically done by the user community choosing and documenting a particular directory structure in their subversion repository. It is generally difficult to have a finer grained control than the release tag and branch structure of the model. The SolidGround Registry addresses these issues; however a version control system still offers benefits for a development process:

Ability to retrieve or revert to a known state; Check-out and lock control of model packages to manage editing rights;



Decouples unstable editing phases from the formal publication and versioning process.

As such, it can be seen that SolidGround Model Registry is suited for the role of providing a standardised approach to publication and distribution of model releases, allowing subversion to be used for the components of a model under active development. The deployment scenarios below illustrate how these components may interact in practice.

4.2.2. Deployment

Using subversion repositories

Figure 30 shows a typical case for management of a thematic domain model using components from the ISO/OGC domain. This matches the GeoSciML and INSPIRE activities and represents the best practice available to date.



Figure 30. Model Management and MDA using subversion

Note that there is a requirement to maintain and locate “ClassMap” artefacts. This holds true for downstream use of the DomainModel by a related sub-domain, in which case FullMoon could potentially generate both a GM Schema and a ClassMap artefact.

Current SolidGround Model Registry model

This section outlines a recommended deployment scenario for the current release of SolidGround, in which the ModelRegistry is used to access dependencies and test model quality, but subversion is used as both a fine-grained development environment and means



of formal publishing of model outputs to external communities. This obviates the need for a stable, publically accessible model registry in the short term.

cmp SolidGround June 2010

EnterpriseArchitect«EA Add-In»

HollowWorldHelper

SpatialInformationServ icesStack::DomainSubv ersionRepo

SVN

ISO_UMLProfile

(from SpatialInformationServicesStack)

SolidGroundPlugIn

UMLModelRegistry

WebService

ISOModel


DomainModel


SWEModel


Domain model can be managed in subversion in parallel with model registry.

Figure 31. Model Registry and local subversion integration

This approach allows for clean versions of ISO models (and other imported domain models) to be accessed without complex subversion set ups, but the benefits of subversion for development processes to be exploited. This approach does not require the ModelRegistry to be stable (as either a service or a technology) as the authoritative copy of the developed model is always available via subversion. It provides a convenient read-only access to external model components, and the ability to manage and visualise dependencies and related artefacts.

Proposed model

This section envisages an ideal world when multiple stable external model registries are available. In this case a modeller will subscribe to the models they need, triggering a local registry to mirror resources required to complete a domain model. Thus the local domain registry will be able to show a complete dependencies tree, and make them accessible to its community. This simplifies the mechanisms and governance overhead of supporting access to multiple external repositories from multiple client environments.



Local copies of model components and artefacts can be synchronised with the original authoritative sources through a range of automated or manual processes. A MDA can also be fully supported by having generated artefacts directly registered back into the model registry linked to the correct versions of authoritative model components.

Figure 32. Proposed vision for federated model registries

This vision can be extended by having discovery interfaces across the contents of multiple registries, however this is not seen as a high priority, since subscription to a model is usually likely to be driven by familiarity with or acceptance of the authority of the model publisher, and hence the model registry is likely to be known, and discovery required to locate the specific versions of specific resources required. Note that whilst Figure 7 does not explicitly include using a subversion repository component for local model development, it can be implemented as per Figure 6.



5. FUTURE DEVELOPMENT A range of developments are underway to extend and operationalise aspects of this work. Some of these are listed here in brief form pending further establishment of requirements.

A workflow for a MDA approach to configuring a registry using a formal information model will be tested in upcoming research.

5.1. Vocabulary system: Establish model

o Compatible with SWIM UML model use o Extensibility mechanism – sub –register must be able to be supported by model

(add feature types – i.e. item classes - to a model) o Items need to be listed in UI o Model design to be compatible with WDTF/WaterML model design

Model elements that are identical… Model elements that are different and reasons…

Vocab configurability: o Registry function to commit to vocabulary (item class) o Support different versions of item classes (change from current replace rule)

Harvest tools – support excel/ web service o Test case for excel spreadsheet required (Bureau) o Test case for other formats desired (GeosciML)

5.2. Solid Ground:

Flexible meta-database restructure (based upon triple store rather than current relational database)

Support synchronisation from vocabulary o E.g. Function in Registry to update models from vocab, display changes etc.

Registry to support all artefacts o Option to register all derived artefacts (documents, database schemas etc) o Option to store original sources in register when importing o dependencies view for all artefacts o Version change view, possibly with user notification

Improve user options/coherence with mapping function extend mapping idiom o Registry to display mapping relationships/ provide functions to their use.

Governance o Accessibility to multiple servers o Read and read-write authorisation (currently only read-write exists) o Policy metadata design



Figure 33. A workflow for MDA configuration of a metadata registry



REFERENCES As/Nzs, 2006. AS/NZS ISO 19110:2006 Geographic information — Methodology for cataloguing.

AS/NZS %* Copyright ISO - International Organization for Standardization. All rights reserved. %U http://www.saiglobal.com/online/Script/OpenDoc.asp?name=AS%2FNZS+ISO+19110%3A2006&path=http%3A%2F%2Fwww.saiglobal.com%2FPDFTemp%2Fosu-2009-12-07%2F5626590444%2F19110-2006.pdf\.

Atkinson, R., 2009. HollowWorld Helper. Atkinson, R., Box, P., 2007. United Nations Spatial Data Infrastructure (UNSDI) Proposed Technical

Governance Framework - Preliminary Report Version 1.1. Atkinson, R., Fox, P., Francis, W., Using formal information models to configure and annotate

vocabulary services., TBD. Atkinson, R., Millard, K., Arctur, D., 2007. Standards Based Approaches for Cross-Domain Data.

International Journal of Spatial Data Infrastructures Research, 2: 74-89 %U http://www.doaj.org/doaj?func=abstract&id=245564&recNo=3&toc=1.

Bizer, C., Heath, T., Idehen, K., Berners-Lee, T., 2008. Linked data on the web (LDOW2008),

Proceeding of the 17th international conference on World Wide Web. ACM, Beijing, China. Chen, F., Cao, W.H., Huang, Y., 2009. Research on Component-based Model Driven Architecture

Development and assembly. EIGHTH IEEE INTERNATIONAL CONFERENCE ON DEPENDABLE, AUTONOMIC AND: 636-641 %U http://apps.isiknowledge.com/full_record.do?product=WOS&search_mode=GeneralSearch&qid=19&SID=P1jEPFdkeDdCHG6E1dB&page=1&doc=10.

Colegrave, N., Collins, S., 2008. Experimental evolution: experimental evolution and evolvability.

Heredity, 100(5): 464-470. Cox, S., Atkinson, R, Configuring your UML tool for HollowWorld. CSIRO. Cox, S.J.D., Full Moon project. Duke, A., Davies, J., Richardson, M., Kings, N., 2004. A Semantic Service Orientated Architecture for

the Telecommunications Industry. Intelligence in Communication Systems: 236-245. INSPIRE, E., 2007. D2.6: Methodology for the development of data specifications. INSPIRE Drafting

Team "Data Specifications" ISO, 1999. ISO 19103 Geographic information - Part 3: Conceptual schema language. International

Organization for Standardization (ISO). Komatsoulis, G.A. et al., 2008. caCORE version 3: Implementation of a model driven, service-oriented

architecture for semantic interoperability. J. Biomed. Inform., 41(1): 106-123. Laxton, J., Serrano, J.-J., Tellez-Arenas, A., 2010. Geological applications using geospatial standards

â€“ an example from OneGeology-Europe and GeoSciML. International Journal of Digital Earth, 3(1 supp 1): 31 - 49.

Mellor, S., Scott, K., Weise, D., 2004. MDA distilled: principles of model-driven architecture. Addison-

Wesley Professional. OMG, 2005. Reusable Asset Specification. Version 2.2.



Osuchowski, M., Atkinson, R., 2008. Connecting diverse landslide inventories for improved landslide

information in Australia, Proceedings of the 1st World Landslide Forum, Tokyo, Japan. Sen, M., Duffy, T., 2005. GeoSciML: Development of a generic GeoScience Markup Language.

Comput. Geosci., 31(9): 1095-1103. Stock, K. et al., 2009. A semantic registry using a Feature Type Catalogue instead of ontologies to

support spatial data infrastructures. International Journal of Geographical Information Science, 23.

Tools and techniques for creation, use and management of ... · Tools and techniques for creation,...

Documents

Transcript of Tools and techniques for creation, use and management of ... · Tools and techniques for creation,...