ISO/IEC 19506:2012 情報技術— Object Management Groupアーキテクチャ主導のモダナイゼーション（ADM）—ナレッジディスカバリーメタモデル（KDM） | ページ 6

Subpart I Infrastructure Layer

KDM is a large specification, since it provides an intermediate representation for several facets of knowledge about existing enterprise software systems. In order to manage the complexity of KDM, a small set of concepts was selected and systematically used throughout the entire specification. These concepts are defined in the so-called Infrastructure Layer. It consists of the following 3 packages:

• • Core
• • kdm
• • Source

The Core package defines the fundamental meta-model element types and the corresponding constraints. Core package provides a set of types that determine each individual KDM meta-model element through subclassing. Each KDM meta-model element is a subclass of one of the classes defined in the Core package. From the meta-model perspective KDM is an entity-relationship representation. So, the two fundamental classes of the Core package are KDMEntity and KDMRelationship. An entity is a thing of significance, about which information needs to be known or held. A KDM entity is an abstraction of some element of an existing software system, that has a distinct, separate existence, a self-contained piece of data that can be referenced as a unit. Each KDM package defines several meta-model elements that represent specific entities for a particular KDM domain.

A relationship represents an association, linkage, or connection between entities that describes their interaction, the dependence of one upon the other, or their mutual interdependence. A KDM relationship represents some semantic association between elements of an existing software system. Each KDM package defines several meta-model elements that represent specific relationships for a particular KDM domain. All KDM relationships are binary.

KDM defines two special relationships:

• • containment
• • grouping

Some KDM entities are containers for other entities. There is a special container ownership (containment) relationship between a container and the entities that are directly owned by this container. Some KDM entities are groups of other KDM entities. There is a special group association (grouping) relationship between the group and the entities that are directly"grouped into" this group.

Core package defines an analysis mechanism, the so-called Aggregated Relations mechanism that brings together special relationships of containment and grouping and regular relationships of the entity-relationship model.

Core package defines a reflective API to KDM representation. Other KDM packages extend this API by specific operations, corresponding to specific facets of knowledge about existing software systems.

The Core package is aligned with the OMG SBVR specification, as it provides an abstraction of existing software systems in the form of terms (various KDM entities) and facts (various attributes of KDM entities, and relationships between KDM entities). Indeed, most of the KDM specification is a definition of a language- and platform-independent ontology of existing software systems. This alignment is important since KDM can be viewed as a standard vocabulary related to descriptions of existing software systems. SBVR rules can be written using this vocabulary to formally describe further properties of existing software systems.

The package with name"kdm" defines several elements that together constitute the framework of each KDM instance. The framework determines the physical structure of a KDM representation. The elements of the framework are present in every instance of KDM that represents a particular existing software system. From the framework perspective, each KDM representation consists of one or more Segments, where each Segment owns several KDM models. Each KDM package defines some specific type of KDM model, which addresses a certain specific facet of knowledge about existing software systems. Individual KDM implementations may support one or more selected KDM models, as defined in the KDM compliance section. KDM tools may use multiple KDM implementations to represent different facets of knowledge about the existing software system and integrate them into a single coherent representation. Further, KDM designs facilitate incremental implementations, where certain pieces of knowledge about the existing software is collected by analyzing more lower level KDM representations. According to this approach certain KDM tools may perform a"KDM enrichment" process, a"KDM to KDM transformation," where a tool analyzes the input KDM model and produces one or more additional Segments and Models, explicitly representing certain derived pieces of knowledge about the system.

The Source package defines the so called Inventory model, which represents the physical artifacts of an existing system as KDM entities as well as the mechanism of traceability links that provide associations between KDM elements and their"original" language-dependent representation in the source code of the existing software system, for which the KDM views are created. This is an important part of the KDM Infrastructure, because other KDM packages use this mechanism to refer to the source code and the physical artifacts of the existing software system.

Subpart II Program Elements Layer

The Program Elements Layer defines a large set of meta-model elements whose purpose is to provide a languageindependent intermediate representation for various constructs determined by common programming languages.

Packages of the Program Elements Layer define an architecture viewpoint for the Code domain.

• • Concerns :
  • • What are the computational elements of the system?
  • • What are the modules of the system?
  • • What is the low-level organization of the computational elements?
  • • What are the datatypes used by the computational elements?
  • • What are the units of behavior of the system?
  • • What are the low-level relationships between the code elements, in particular what are the control-flow and dataflow relationships ?
  • • What are the important non-computational elements?
  • • How are computational elements and modules related to the physical artifacts of the system?

• • Viewpoint language :

  Code views conform to KDM XMI schema. The viewpoint language for the Code architectural viewpoint is defined by the Code and Action packages. It includes several abstract entities, such as AbstractCodeElement and CodeItem, several generic entities, such as Datatype, ComputationalObject and Module, as well as several concrete entities, such as StorableUnit, CallableUnit, CompilationUnit, and ActionElement. The viewpoint language for the Code architectural viewpoint also includes several relationships, which are subclasses of AbstractCodeRelationship and AbstractActionRelationship.

• • Analytic methods :

  The Code architectural viewpoint supports the following main kinds of checking:

  • • Composition (for example, what code elements are owned by a CompilationUnit, SharedUnit, or a CodeAssembly; what action elements are owned by a CallableUnit)?
  • • Data flow (for example, what action elements read from a given StorableUnit; what action elements write to a given StorableUnit; what action elements create dynamic instances of a given Datatype; what action elements address a particular StorableUnit; what data element are being read as actual parameters in a call)?
  • • Control flow (for example, what CallableUnit is used in a call; what action element is executed after the given action element; what action elements are executed before the given action element; what data element is used to dispatch control flow from a given action element; what action element is executed after the given element under what conditions; what is the exceptional flow of control; what action elements are executed as entry points to a given module or a CallableUnit)?
  • • Datatypes (for example, what is the datatype of the given storable unit; what is the base datatype of the given pointer type; what is the base datatype of the given element of the record type; what is the signature of the given CallableUnit)?

Subpart III Runtime Resources Layer

This clause describes common patterns for representing the operating environment of existing software systems. The following are the common properties of the Runtime Resources Layer packages Data, UI, Platform, and Event:

• • They provide modeling elements to represent"resources" (something managed by the runtime platform).
• • They provide abstract"resource actions" to manage these resources.
• • These actions are implemented by the program elements as one or more API calls to some external platform-specific packages.
• • There is a binding involved between the actions and the resources.
• • Resource may involve some"inverted" control in the form of callbacks and event handlers, allowing applications to be programmed in event-driven style.
• • The content of the information flow involving the resource is associated with some data organization.
• • Resource often has a certain state, and tracking the changes of the state over time may be an important concern in understanding the logic of the existing system.

Since Runtime Resources Layer packages capture high-value knowledge about the existing system and its operating environment, which may involve advance analysis and some manual expertise KDM is designed in such a way that the Runtime Resources Layer analysis can use KDM models from the Program Elements Layer as input and produce Runtime Resources Layer models as output. There should be no references from lower KDM layers to higher layers; therefore, new Runtime Resources Layer models can be built on top of existing Program Element layer models.

Packages of the Runtime Resources Layer package systematically uses the following KDM patterns:

• • Each Runtime Resources Layer package defines entities and containers to represent specific"resources." Each package may define additional elements to represent additional concerns. For example, the Data package involves less resource definitions, and focuses on the representation of various data organization capabilities. The Event package provides the meta-model elements for representing state, state transitions caused by events. States, transitions, and events can be considered as runtime platform resources. The UI package provides the meta-model elements for representing user interfaces. User interfaces can also be considered runtime platform resources. The Platform package deals with conventional runtime platform resources, such as inter-process communication, the use of registries, management of data, etc.
• • Each Runtime Resources Layer package defines specific structural relations between"resources." For example, the Platform package defines relationship BindsTo, which represents a logical association between two resources.
• • Each Runtime Resources Layer package defines specific resource actions to represent manipulation of resource through API calls. Resource actions use the following KDM pattern. Each resource action is an entity of the base abstract class for the corresponding package. This class is named AbstractXXXElement, where"XXX" is the name of the package. So, the resource action is not a subclass of ActionElement, and this promotes modularity between KDM packages, each of which defines an independent KDM compliance point. However, each resource action owns one or more ActionElements through property called"abstraction." Each resource action also has the property called"implementation" that uses the KDM grouping mechanism to associate the resource action with one or more ActionElements owned by the Code model. The"implementation" group of the resource action represents the original API calls as they were represented in the Program Elements layer input model. The"abstraction" property uses KDM container mechanism to add the behavior counterparts to the API calls that represent the true logic of the resource operation, including the flow of data and control. The"abstracted" ActionElements are owned directly by the corresponding resource action, and are not part of any Code model.
• • The nature of the resource-specific operation performed by a particular resource action is represented by the"kind" attribute of the resource actions. The resource action owns resource action relations through the"abstraction" action container. It is the owned"abstracted" action that is the direct owner of the resource action relationship.
• •"abstraction" action container property is in fact systematically added to all elements of Runtime Resources Layer packages. This way each resource can use the meta-model elements defined in the Program Elements layer to specify behavior specific to that resource.
• • The"abstraction" action container pattern is used to systematically represent the forms of"inverted" control provided by runtime platforms. This pattern can be separately referred to as the KDM Event pattern. Each Runtime Resources Layer package defines its own meta-model element for representing events. For example, the UI package defines the class UIEvent. The"abstraction" action container mechanism allows ActionElements to be added to event elements. Calls relation originating from such an abstracted action element represents the"callback" mechanism, provided by several runtime platforms.

Runtime Resources Layer packages are independent, however they can offer additional capabilities when more than one is implemented. In order not to enforce any particular order in which these packages should be implemented, KDM involves the following approach: resource action relationships are subclasses of the AbstractActionRelationship class from the Action Package. In the full KDM implementation that uses all packages, all resource actions are available for any ActionElement. Code models should not use the extended relationships. The extended resource action relationships can only be used by the actions in"abstraction" action containers in Runtime Resources Layer models. A notable example of this mechanism are the actions"HasState" defined in the Event package, which makes it possible to associate an element of an event model with any resource. Another example is the"HasContent" relation defined in the Data package, which allows associating an element of a data model with any resource.

• • The"abstraction" action containers, available for each resource also allow arbitrary Flow relations between"resource actions" and between resources to provide abstractions of the flow between"resource actions."
• • The Runtime Resources Layer patterns are aligned with the micro KDM, which allow precise modeling of behavior related to resources as the foundation for holistic high-fidelity analysis of existing software systems. It can be achieved by associating sets of precise micro KDM actions with"abstraction" action containers.

Additional Runtime concerns involve dynamic structures (instances of some logical entities and their relationships) that emerge at the so-called"run time" of the software system. For example, dynamic entities include processes and threads. Instances of processes and threads can be created dynamically and in many cases relations between the dynamically created instances of processes and threads are an essential part of the knowledge of existing systems. Pure logical perspective in that case may be insufficient.

When separation of concerns between application code and Runtime platform is considered, it is important to be clear about the so-called bindings and various mechanisms to achieve a binding or delay it.

A binding is a common way of referring to a certain irrevocable implementation decision. Too much binding is often referred to as"hardcoding." This often results in systems that are difficult to maintain and reuse. They are often also difficult to understand. Too little binding leads to dynamic systems, where everything is resolved at run time (as late as possible). This often results in systems that are difficult to understand and error-prone. Modern platforms excel in managing binding time. Usually binding is managed at deployment time.

A large number of software development practices is about efficient management of binding time, including portable adaptors, code generation, model-driven architecture. Efficient management of binding time is often called platform independence.

Binding time

• • Generation time binding
• • Language & platform design binding
• • Versioning time
• • Compile time binding, including
  • • macro expansion
  • • Templates
  • • Product line variants defined by conditional compilation

• • Link time binding

• • Deployment time binding

• • Initialization time binding

• • Run time

Subpart IV Abstractions Layer

Abstraction Layer defines a set of meta-model elements that represent domain-specific and application-specific abstractions, as well as artifacts related to the build process of the exsting software system. The meta-model elements of the Abstractions Layer provide various containers and groups to other meta-model elements.

Abstractions Layer defines the following 3 KDM Models:

• • Structure
• • Conceptual
• • Build