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.
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.
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
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.
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.
Terms and Definitions
There are no special terms or definitions in this specification.
There are no symbols defined in this specification.
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.
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).
The following companies submitted and/or supported parts of this specification:
- Allen Systems Group, Inc
- Klocwork, Inc.
- KDM Analytics
- Tactical Strategy Group, Inc
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.