KDM12 — Need to clarify the use of term ‘view’ and align with ISO (rh-5)

Related to section 4

"View" is used in a number of context. Sometimes as "architectural view" other times, unclear

Clarify when "architecture view" in intended, and use ISO 42010 definition. If "database view" is meant (which is a very different notion); make that clear. If both notions are needed; qualify each usage.

The resolution to this issue involves the following editorial changes:
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 1 in the editorial note in the specification text with changebars
Change sentence Page 6: 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.
Into:
Chapter 11. Source package – Describes meta-model elements that provide traceability
from KDM facts to the original representation of the software item (for example, the
source code).
Change sentence Page 7 Chapter 20. Conceptual package - Describes the meta-model elements for
representing business domain knowledge about existing applications in the context of other KDM views.
Into
Chapter 20. Conceptual package – Describes meta-model elements that represent facts
related to the business domain of the existing system and provide traceability to other
KDM facts.
Change sentence Page 7: 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).
Into: Chapter 21. Build package - Describes the meta-model elements that represent the facts
related to the build process of the software system (including but not limited to the
engineering transformations of the “source code” to “executables”). Build package
defines the architectural viewpoint for the Build domain.
EDITORIAL NOTE: This is the end of Block 1
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 2 in the editorial note in the specification text with changebars
Change sentence Page 13: Each KDM package defines several entity types representing specific
abstractions related to a certain viewpoint on existing software systems.
Into
Each KDM package defines several meta-model elements that represent specific entities
for a particular KDM domain.
Change sentence Page 13: Each KDM package defines several relationship types representing specific
abstractions related to a certain viewpoint on existing software systems.
Into
Each KDM package defines several meta-model elements that represent specific
relationships for a particular KDM domain.
EDITORIAL NOTE: This is the end of Block 2
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 3 in the editorial note in the specification text with changebars
Change sentence Page 18: Each KDM package defines several entity types representing specific
abstractions related to a certain viewpoint on existing software systems.
Into
Each KDM package defines several meta-model elements that represent specific entities
for a particular KDM domain.
EDITORIAL NOTE: This is the end of Block 3
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 4 in the editorial note in the specification text with changebars
Change sentence Page 19: Each KDM package defines several relationship types representing specific
abstractions related to a certain viewpoint on existing software systems.
Into
Each KDM package defines several meta-model elements that represent specific
relationships for a particular KDM domain.
EDITORIAL NOTE: This is the end of Block 4
EDITORIAL NOTE: for the purposes of traceability the following changes will be
referred to as block 5 in the editorial note in the specification text with changebars Change sentence section 10.2 page 25: There are 9 kinds of models, corresponding to some well-known
concerns of software engineering.
Into
There are 9 kinds of models. Each KDM model is described by one or more KDM packages and
corresponds to one KDM domain.
Change sentence section 10.2, page 25, From the architectural perspective, each KDM model represents a
particular view of the existing system. From the infrastructure perspective, a KDM model is a typed
container for model element instances. From the meta-model perspective, KDM model is represented by a
separate package that defines a collection of the meta-model elements, which can be used to build
representations of the particular view of existing systems.
Into
From the architectural perspective, each KDM package defines an architectural viewpoint. KDM model is
the key mechanism to organize individual facts into architecture views. From the infrastructure perspective,
a KDM model is a typed container for meta-model element instances (collection of facts organzied into an
architectural view). From the meta-model perspective, each KDM model is represented by a separate KDM
package that defines a collection of the meta-model elements, which can be used to represent the facts
about the given existing systems from a particular viewpoint.
Change sentence Page 27 A KDM model corresponds to one of the well-known architecture views of
software systems.
Into
Each KDM model defines an architectural viewpoint. An instance of a KDM model is an
architectural view of the given existing system. Physically every instance of KDMModel
element and its subclasses is a container for the facts from the corresponding KDM
domain.
Change sentence Page 29: The Segment element represents a coherent set of logically
related KDM models that together provide a useful view of an existing software system.
Into
The Segment element is a container for a meaningful set of facts about an existing
software system. Each Segment may involve one or more KDM model instances and thus
represents a collection of one or more architectural views for a given existing system.
Change sentence Page 29: Each KDM model defines KDM entities representing a certain view of the
existing software system. Each KDM model defines specific meta-model elements.
Into
Each KDM model defines an architectural viewpoint. KDM model defines specific metamodel
elements (entities and relationships specific to the viewpoint) that collectively
define the viewpoint language.
Change sentence Page 43: The Source package defines the KDM Inventory model that corresponds in part
to the engineering view of the existing software system.
Into
The Source package defines an architectural viewpoint for the Inventory domain.
Change section 11.1 sentence: The Source package also represents traceability links between instances of
KDM meta-elements and the regions of source code, which is represented by these meta-model elements. It
represents the convergence between the KDM intermediate representation and the application source it
represents
Into: The Source package also represents traceability links between instances of KDM meta-elements and the
regions of source code, which is represented by these meta-model elements. It represents the link between
the KDM instance and the corresponding artifacts of the existing system.
Change sentence Page 44: InventoryModel class diagram defines meta-model elements that represent the
artifacts of the existing software system as “first class citizens” on the KDM instance.
into
: InventoryModel class diagram defines meta-model elements that represent the physical artifacts of the
existing software system.
Change sentence Page 44: The InventoryModel class diagram follows the uniform pattern for KDM model
to extend the KDM Framework with specific meta-model elements related to the engineering view of
existing software systems.
into
The InventoryModel class diagram follows the uniform pattern for KDM model to extend the KDM
Framework with specific meta-model elements.
Change sentence Page 45: The InventoryModel is a specific KDM model which corresponds to the physical
(engineering) view of the existing software system.
into
The InventoryModel is a specific KDM model which represents facts related to the physical artifacts of the
existing software system.
Change sentence Page 51: KDM Build package that constitutes a separate L1.Build
compliance point, defines more precise meta-model elements to represent the engineering
view of the software system.
into
KDM Build package that constitutes a separate L1.Build compliance point, defines additional meta-model
elements that represent the facts involved in building the software system (including but not limited to the
engineering transformations of the “source code” to “executables”).
Remove sentence Page 59: This facet of knowledge about existing software systems corresponds to the
logical view.
Change sentence Page 61 The CodeModel is the specific KDM model that corresponds to the logical view
of the implementation of the existing software system.
Into
The CodeModel is the specific KDM model that represents collections of facts about the existing software
system such that these facts correspond to the Code domain.
Change sentence Page 164: Platform model defines one of the architectural views in support of the
principle of separation of concerns in KDM models.
Into
PlatformModel is the specific KDM model that represents collections of facts about the existing software
system such that these facts correspond to the Platform domain.
Remove sentence Page 177 The logical view of KDM model describes one or more SoftwareSystems.
Change sentence Page 207 This fact of knowledge corresponds to the logical view. It is determined by a
data description language.
Into
Fact in the Data domain are usually determined by a certain Data Description Language (for example,
SQL) but may in some cases be determined by the code elements. Change sentence Page 253: Abstraction Layer defines a set of meta-model elements whose purpose is to
represent domain-specific and application-specific abstractions, as well as the engineering view of the
exsting software system.
Into
Abstraction Layer defines a set of meta-model elements that represent domain-specific and applicationspecific
abstractions, as well as the artifacts related to the build process of the existing software system.
Change sentence Page 262: The Conceptual package defines meta-model elements for representing highlevel,
high-value application-specific “conceptual” views of existing software systems.
Into
The Conceptual package defines meta-model elements for representing high-level, high-value applicationspecific
“conceptual” elements of existing software systems and their traceability to other KDM facts.
Change the sentence Page 263: The ConceptualModel class is a KDM model that extends the KDM
Infrastructure framework to provide the infrastructure for representing conceptual views of existing
software systems.
Into
The ConceptualModel is the specific KDM model that represents collections of facts about conceptual
elements implemented by a given existing software system.
Change sentence Page 279: The Build package represents the artifacts that represent the engineering view
of a particular existing system. The Build package also includes the entities to represent the artifacts that
are generated by the build process.
into
The Build package defines meta-model elements that represent the facts involved in building the software
system (including but not limited to the engineering transformations of the “source code” to “executables”).
The Build package also includes the meta-model elements to represent the artifacts that are generated by
the build process.
Change sentence Page 279 The Build package defines a collection of meta-model elements that represent
entities and relationships related to the engineering view of existing software systems.
Into
The Build package defines a collection of meta-model elements that represent entities and relationships
related to the build process of an existing software system.
Change sentence Page 279 The BuildModel class diagram provides basic meta-model constructs to model
the engineering view of a particular existing software system within the KDM framework.
into
The BuildModel class diagram provides basic meta-model elements that represent entities and relationships
related to the build process of an existing software system.