KDM12 — Alignment with the ISO concept of architecture view (rh-2)

Related to section 2.1

"KDM domains correspond to the well-known concept of architecture views." If this is true, the requirements for documenting views should be met; and the rules for interpreting such views should be provided. Usually this is done in terms of an Architectural Viewpoint definition for each view.

Satisfy requirements on each architectural view in accordance with ISO/IEC 42010.

Add Architectural Viewpoint definitions for each view in accordance with the rules of ISO/IEC 42010.

EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 1 (see specification with changebars and editorial notes)
page 1 Change sentence: Each KDM domain consists of a single KDM package that
defines meta-model elements to represent particular aspects of the system under study.
KDM domains correspond to the well-known concept of architecture views. Each KDM domain defines an architectural viewpoint. The viewpoint language for the
domain is defined by the corresponding KDM package that defines meta-model elements
to represent particular facts of the system under study that are essential to the given
knowledge discovery domain. The meta-model elements defined by all KDM packages
constitute the ontology for describing existing systems.
Page 1 change sentence:
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.
Into
For example, the Code package defines the language to represent individual code elements, such as
variables, statements and procedures, the Structure package provides the language to represent
architectural elements of the system such as subsystems and components, while the Conceptual package,
corresponding to the Business Rules domain defines the language to represent behavioral elements of the
same system such as features or business rules. KDM formally defines traceability, aggregation and
derivation of facts across domains.
Page 1 remove sentence: Separation of concerns in the design of KDM is embodied in the concept of
KDM domains.
Page 1 change sentence: 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.
Into:
The following domains of knowledge have been identified as the foundation for defining compliance in
KDM: Inventory, Code, Build, Structure, Data, Business Rules, UI, Event, Platform, and micro KDM.
EDITORIAL NOTE: This is the end of Block 1.
EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 2 (see specification with changebars and editorial notes)
Page 2: change sentence: This compliance level contains the following KDM packages: Core, kdm, Source,
Code, and Action packages.
Into:
This compliance level addresses the Inventory and Code domains and is determined by the following KDM
packages: Core, kdm, Source, Code, and Action packages.
Page 2 change sentence: To be L0 compliant, a tool must completely support all model elements within all
packages for L0 level.
Into
To be L0 compliant, a tool shall completely support all meta-model elements within all packages of L0
level.
Page 2: change sentence
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 sub clause 14 “Micro KDM,” and Annex A “Semantics of the Micro KDM Action Elements.” These packages are grouped to form abovementioned
domains.
Into
Level 1 (L1) - This level addresses the remaining KDM domains and extends the capabilities provided by
Level 0. Specifically, this level is determined by the following packages: Build, Structure, Data,
Conceptual, UI, Event, Platform, as well as the set of constraints for the micro KDM domain defined in sub
clause 14 “Micro KDM,” and Annex A “Semantics of the Micro KDM Action Elements.”.
Page 3 change sentence:
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.
Into
To be L1 compliant for a given KDM domain, a tool shall completely support all meta-model elements
defined by the corresponding packages and satisfy all semantic constraints specified for that domain.
EDITORIAL NOTE: This is the end of Block 2.
EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 3 (see specification with changebars and editorial notes)
Change sentence page 12 KDM representation is a single, integrated repository of different facets of
knowledge about the software system.
Into
KDM instance is a single, integrated representation of different facets of knowledge about the software
system.
EDITORIAL NOTE: This is the end of Block 3.
EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 4 (see specification with changebars and editorial notes)
Page 9 Change from: KDM separates knowledge about existing systems into several orthogonal facets
that are well-known in software engineering and are often referred to as Architecture Views.
into:
KDM groups facts about existing systems into several domains each of which corresponds to an ISO 42010
architectural viewpoint. Each KDM domain is represented by one or more KDM packages, which
formalizes the viewpoint language for that domain. KDM focuses at the entities and their relationships that
are essential for the given domain. A KDM representation of a given existing system – KDM instance - is a
collection of facts about that system. These facts are organized into KDM models per each domain. KDM
model corresponds to an ISO 42010 architectural view. KDM facts are further organized into meaningful
groups called segments. A KDM segment may include one or more architectural views of the given
system. KDM instances may be part of the complete architectural description of the system, as defined by
ISO 42010, in which case additional requirements of ISO 42010 shall be satisfied by the overall document.
KDM instances are represented as XML documents conforming to the KDM XMI schema.
Add clarification page 9 after sentence: Logically, KDM consists of 9 models.
Each KDM model is described by one or more KDM packages and corresponds to one KDM domain.
Most KDM domains are defined by a single package, with the exception of the Code domain, which is split
between the Code and the Action packages.
EDITORIAL NOTE: This is the end of Block 4. EDITORIAL NOTE: For traceability purposes in editorial notes of the specification with
changebars the following edit instructions are collectively referred to as Issue 13293
Block 5 (see specification with changebars and editorial notes)
Page 27: Change from: A KDM model corresponds to one of the well-known architecture views of
software systems. KDM defines several concrete subclasses of the KDMModel class.
To:
A KDMModel element is an abstract class that defines the common properties of KDM model instances
which are collection of facts about a given existing system from the same architectural viewpoint of one of
the KDM domains. KDM defines several concrete subclasses of the KDMModel class, each of which
defines a particular kind of a KDM model. The architectural viewpoint is defined by the corresponding
KDM package. A KDM model instance is an architectural view of the given system.