Front Matter

Scope

This specification defines a meta-model for representing existing software assets, their associations and operational environments, referred to as the Knowledge Discovery Meta-model (KDM). This is the first in the series of specifications related to Software Assurance (SwA) and Architecture-Driven Modernization (ADM) activities. KDM facilitates projects which involve existing software systems by insuring interoperability and exchange of data between tools provided by different vendors.

One common characteristic of various tools that address SwA and ADM challenge is that they analyze existing software assets (for example, source code modules, database descriptions, build scripts, etc.) to obtain explicit knowledge. Each tool produces a portion of the knowledge about existing software assets. Such tool-specific knowledge may be implicit (“hard-coded” in the tool), restricted to a particular source language and/or particular transformation and/or operational environment. All the above may hinder interoperability between different tools. The meta-model for Knowledge Discovery provides a common repository structure that facilitates the exchange of data contained within individual tool models that represent existing software assets. The meta-model represents the physical and logical assets at various levels of abstraction. The primary purpose of this meta-model is to provide a common interchange format that will allow interoperability between existing modernization and software assurance tools, services and their respective intermediate representations.

Conformance

KDM is a meta-model with a very broad scope that covers a large and diverse set of applications, platforms and programming languages. Not all of its capabilities are equally applicable to all platforms, applications or programming languages. The primary goal of KDM is provide the capability to exchange models between tools and thus facilitate cooperation between tool suppliers by allowing integration information about a complex enterprise application from multiple sources, as the complexity of modern enterprise applications involves multiple platform technologies and programming languages. In order to achieve interoperability and especially the integration of information about different facets of an enterprise application from multiple analysis tools, this specification defines several of compliance levels thereby increasing the likelihood that two or more compliant tools will support the same or compatible meta-model subsets. This suggests that the meta-model should be structured modularly, following the principle of separation of concerns, with the ability to select only those parts of the meta-model that are of direct interest to a particular tool vendor. Consequently, the definition of compliance for KDM requires a balance to be drawn between modularity and ease of interchange. Separation of concerns in the design of KDM is embodied in the concept of KDM domains.

KDM Domains

Separate facts of knowledge discovery in enterprise application in KDM are grouped into several KDM domains (refer to See – Domains and levels of KDM compliance.). Each KDM domain consists of a single KDM package which defines meta-model elements to represent particular aspects of the system under study. KDM domains correspond to the well-known concept of architecture views. For example, the Structure domain enables users to discover architectural elements of source code from the system under study, while the Business Rules domain provides users with behavioral elements of the same system such as features or process rules.

The following domains of knowledge have been identified as the foundation for defining compliance in KDM: Build, Structure, Data, Business Rules, UI, Event, Platform and micro KDM

From the user’s perspective, this partitioning of KDM means that they need only to be concerned with those parts of the KDM that they consider necessary for their activities. If those needs change over time, further KDM domains can be added to the user’s repertoire as required. Hence, a KDM user does not have to know the full meta-model to use it effectively. In addition, most KDM domains are partitioned into multiple increments, each adding more knowledge capabilities to the previous ones. This fine-grained decomposition of KDM serves to make the KDM easier to learn and use, but the individual segments within this structure do not represent separate compliance points. The latter strategy would lead to an excess of compliance points and result to the interoperability problems described above. Nevertheless, the groupings provided by KDM domains and their increments do serve to simplify the definition of KDM compliance as explained below.

– Domains and levels of KDM compliance

Compliance Levels

In addition, the total set of KDM packages is further partitioned into layers of increasing capability called compliance levels. There are two KDM compliance levels:

  • Level 0 (L0) – This compliance level contains the following KDM packages: Core, kdm, Source, Code and Action packages. It provides an entry-level of knowledge discovery capability. More importantly, it represents a common denominator that can serve as a basis for interoperability between different categories of KDM tools.

    To be L0 compliant, a tool must completely support all model elements within all packages for L0 level.

  • Level 1 (L1) – This level addresses KDM domains and extends the capabilities provided by Level 0. Specifically, it adds the following packages: Build, Structure, Data, Conceptual, UI, Event, Platform, as well as the set of constraints for the micro KDM domain defined in section 14 Micro KDM, and Appendix 1 “Semantics of the micro KDM action elements”. These packages are grouped to form above-mentioned domains. More importantly, this level represents a layer where tools could be complimentary since their focus would be in different areas of concern. This would be additional reason why L0 interoperability (which at this level would be viewed as information sharing between tools) is mandated. In this case interoperability at this level would be viewed as correlation between tools to complete knowledge puzzle that end user might need to perform particular task.

    To be L1 compliant for a given KDM domain, a tool must completely support all model elements defined by the package for that domain and satisfy all semantic constraints specified for that domain.

  • Level 2 (L2) – This level is the union of L1 levels for all KDM domains.

Meaning and Types of Compliance

Compliance to Level 1 (L1) for a certain KDM domain entails full realization of all KDM packages for the corresponding KDM Domain. This also implies full realization of all KDM packages in all the levels below that level (in this case Level 0 (L0)). It is not meaningful to claim compliance to Level 1 without also being compliant with the Level 0. A tool that is compliant at a Level 1 must be able (at least) to import models from tools that are compliant to Level 0 without loss of information. So, “full realization” for a KDM domain means supporting the complete set of concepts defined for that KDM domain at L1 and complete set of concepts defined at L0.

For a given compliance level, a KDM implementation can provide:

  • the capability to analyze physical artifacts of existing applications and export their representations based on the XMI schema corresponding to the given compliance level.
  • the capability to import representations of existing software systems based on the XMI schema corresponding to the given compliance level and perform operations suggested by the corresponding packages.

– Compliance Statements

Compliance Statement

Compliance Level

Import-Analysis

Import API

Export

L0
 Import KDM models based on complete KDM XMI schema into existing tool;
support specified mapping between KDM and existing model in the tool;
extend operations of existing tool to support meta-model elements of KDM framework;
extend operations of existing tool to support meta-model elements of Code and Action packages;
extend operations of existing tool to traceability to the physical artifacts of the application from Source package. 		Import KDM models based on complete KDM XMI schema;
support KDM API defined by the KDM Core package;
support KDM framework as defined in the Kdm package;
support KDM API defined by the Code and Action packages;
support traceability to the physical artifacts of the application as defined in the Source package. 		Provide capability to analyze artifacts of an application for specified programming language or multiple languages;
Generate XMI documents corresponding to the KDM XMI schema;
Support KDM framework as defined by the Kdm package;
Support Code and Action packages;
Provide traceability back to the physical artifacts as defined by the Source package.
L1 STRUCTURE L0 compliance for analysis;extend operations of existing tool to support meta-model elements of the Structure package. L0 compliance for import;Support KDM API as defined by the Structure package. L0 compliance for export;Provide capability to analyze architecture components of existing application and generate KDM Structure model according to Structure package.
DATA L0 compliance for analysis;
extend operations of existing tool to support meta-model elements of the Data package. 		L0 compliance for import;
Support KDM API as defined by the Data package. 		L0 compliance for export;
Provide capability to analyze persistent data components of existing application for specified database system and generate KDM Data model according to Data package.
PLATFORM L0 compliance for analysis;
extend operations of existing tool to support meta-model elements of the Platform package. 		L0 compliance for import;
Support KDM API as defined by the Platform and Runtime packages.

 L0 compliance for export;
Provide capability to analyze platform artifacts for specified platform and generate KDM Platform model according to Platform package.
BUILD L0 compliance for analysis;
extend operations of existing tool to support meta-model elements of the Build package. 		L0 compliance for import;
Support KDM API as defined by the Build package.

 L0 compliance for export;
Provide capability to analyze build artifacts for specified build environment and generate KDM Build model according to Build package.
UI L0 compliance for analysis;
extend operations of existing tool to support meta-model elements of the UI package. 		L0 compliance for import;
Support KDM API as defined by the UI package. 		L0 compliance for export;
Provide capability to analyze user interface artifacts for specified user interface system and generate KDM UI model according to UI package;
EVENT L0 compliance for analysis;
extend operations of existing tool to support meta-model elements of the Event package.
 L0 compliance for import;
Support KDM API as defined by the Event package. 		L0 compliance for export;
Provide capability to analyze artifacts related to event-driven runtime frameworks and state-transition behavior and
generate KDM Event model according to Event package.
BUSINESS L0 compliance for analysis;
extend operations of existing tool to support meta-model elements of the Conceptual package. 		L0 compliance for import;
Support KDM API as defined by the Conceptual package. 		L0 compliance for export;
Provide capability to analyze conceptual and behavior artifacts (e.g., domain concepts, business rules, scenarios) of existing application and generate KDM Conceptual model according to Conceptual package;
MICRO KDM L0 compliance for analysis; extend operations of existing tool to support micro KDM actions as specified in section 14 micro KDM and Appendix 1 L0 compliance for import; Support micro KDM actions as specified in section 14 micro KDM and Appendix 1 L0 compliance for export; Provide capability to analyze artifacts of existing application to the level of detail specified in section 14 and Appendix 1 provide the mapping of semantics of the existing application as it is determined by the programming languages and the runtime platform into KDM micro actions and generate KDM models that represent the same meaning
L2 L0 import compliance for analysis;
L1 import-analysis compliance for all KDM domains. 		L0 compliance for import;
Support KDM API as defined by all KDM packages. 		L0 export compliance;
L1 export compliance for all KDM domains.

Normative References

The following normative documents contain provisions, which, through reference in this text, constitute provisions of this specification. For dated references, subsequent amendments to, or revisions of any of these publications do not apply.

  • UML 2. Infrastructure Specification
  • MOF 2.0 Specification

Terms and Definitions

There are no special terms or definitions in this specification.

Symbols

There are no symbols defined in this specification.

Additional Information

Changes to Other OMG Specifications

There are no changes to other OMG specifications.

How to Read this Specification

The rest of this document contains the technical content of this specification.

Chapter 7. Specification overview
Provides design rationale for the KDM specification

Chapter 8. KDM
Gives the overview of the packages of KDM

Part 1. The KDM Infrastructure Layer

Chapter 9. Core package
Describes foundation constructs for creating and describing meta-model classes in other KDM packages. Classes and associations of the Core package determine the structure of KDM models, provide meta-modeling services to other classes and define fundamental constraints.

Chapter 10. kdm package
Describes the key infrastructure elements that determine patterns for constructing KDM models and integrating them. This package defines several static elements that are shared by all KDM models. This package determines the queries against KDM models.

Chapter 11. Source package
This package describes meta-model elements for specifying the linkage between the KDM model artifacts and their physical implementations in the artifacts of existing software. Elements of the Source package allow viewing the source code, corresponding to KDM model elements.

Part 2. The Program Elements Layer

Chapter 12. Code package
Describes meta-model elements that capture programming artifacts as provided by programming languages, such as data types, procedures, macros, prototypes, templates, etc.

Chapter 13. Action package
Describes the meta-model elements related to the behavior of applications. Action package defines detailed endpoints for most KDM relations. The key element related to behavior is a KDM action. Other packages depend on the Action package to use actions in further modeling aspects of existing applications such as features, scenarios, business rules, etc.

Chapter 14. Micro KDM
Describes the guidelines and constraints for semantically precise KDM representations.

Part 3. The Runtime Resources Layer

Chapter 15. Platform package
Describes the meta-model elements for representing operating environments of existing software systems. Application code is not self-contained, as it depends not only on the selected programming language, but also on the selected Runtime platform. Platform elements determine the execution context for the application. Platform package provides meta-model elements to address the following:

  • Resources that Runtime platforms provide to components
  • Services that are provided by the platform to manage the life-cycle of each resource
  • Control-flow between components as it is determined by the platform
  • Error handling across application components
  • Integration of application components

The Platform package focuses on the logical aspects of the operating environments of existing applications, while the Runtime package further addresses the physical aspects of operating environments, such as deployment.

Chapter 16. UI package
Describes the meta-model elements to represent knowledge related to user interfaces, including their logical composition, sequence of operations, etc.

Chapter 17. Event package
Describes meta-model elements that represent basic elements related to behavior of applications in terms of events, messages and responses.

Chapter 18. Data package
Describes the Data domain of KDM, aiming primarily at databases and other ways of organizing persistent data in enterprise applications independent of a particular technology, vendor and platform.

Part 4. Abstractions Layer

Chapter 19. Structure package
Describes the meta-model elements for representing the logical organization of the software system in terms of logical subsystems, architectural layers, components and packages.

Chapter 20. Conceptual package
Describes the meta-model elements for representing business domain knowledge about existing applications in the context of other KDM views.

Chapter 21. Build package
Describes the meta-model elements for representing the artifacts involved in building the software system (the engineering view of the software system).

Acknowledgements

The following companies submitted and/or supported parts of this specification:

  • Allen Systems Group, Inc
  • BluePhoenix
  • EDS
  • Flashline
  • IBM
  • Klocwork, Inc.
  • KDM Analytics
  • SoftwareRevolution
  • Tactical Strategy Group, Inc
  • Unisys

The following persons were members of the core team that designed and wrote this specification: Nikolai Mansourov, Michael Smith, Djenana Campara, Larry Hines, William Ulrich, Howard Hess, Henric Gomez, Chris Caputo, Vitaly Khusidman, Barbara Errickson-Connor.

In addition, the following persons contributed valuable ideas and feedback that significantly improved the content and the quality of this specification: Pete Rivett, Adam Neal, Sumeet Malhotra, Jim Rhyne, Mark Dutra, Sara Porat, Fred Cummins, Manfred Koethe, Alena Laskavaia, Alain Picard.