5.1. Dimensions and Structures¶
The aim of MQC is to compute quality for a project based on provided data and to visualize this data in a structured way. In order to do this, MQC structures the provided data systematically. This is done with the help of artifacts, datasources, measurements, measures, variables, revisions and milestones.
Based on this structuring, MQC can offer several views on the provided data as well as the derived quality. MQC follows the terminology of ISO-25010, ISO-25012, and ISO-25022 when structuring the provided data and the computed quality. This chapter gives an overview of the terms used in MQC and their relation to ISO-25010, ISO-25012, and ISO-25022.
5.1.1. Artifacts and Artifact Structure¶
When data is collected within MQC, it is associated with artifacts for which that data was measured and which should be used for visualization and quality computation. Artifacts in MQC can be any object for which quantitative data is collected. Examples of artifacts are Simulink models, generated code or documents like review protocols. Figure 5.1 shows examples of artifacts. The Simulink model, the requirements document, the respective TargetLink model, and the generated code all represent artifacts.
However, artifacts can also be defined in a more general sense. They do not always need to represent real objects as work products. Artifacts can also represent virtual objects like process steps, for example.
MQC supports to adapt artifact names as they are used by data sources to the needs of the user (see Artifacts). Especially if different data sources use different denominations for the same artifact, a proper artifact mapping may be used to define a common artifact name. All imported measure values collected by the data sources are automatically assigned to the new artifact name.
In case the same base measures were provided for different artifact paths for the same revision and are now mapped to a common artifact name, MQC only uses the most recent of these base measures to calculate quality for the artifact.
Artifacts can be grouped hierarchically. This structure can represent a state of the artifact itself, but it can also represent a logical structure. For instance, Simulink models can be grouped based on their functionality. However, a Simulink model can also be grouped with respect to different responsibilities (e.g. model 1 and 2 are grouped by role 1). As an example, consider several Simulink and TargetLink models that are grouped according to their implementation. See Figure 5.2 for an example of a general artifact grouping in MQC.
For details about how artifacts can be grouped in MQC, please refer to Artifact Structures.
Defining relations between your artifacts and certain data sources, measurements, measures or even variables can be helpful to configure your project properly. You can assign data sources, measurements or measures to certain artifacts, defining the exact data that is expected or excluded for these artifacts within your project. You can define that association between Data Sources and Artifacts via Context Categories (including measurements and measures).
For more information concerning the usage of Context Categories for your project, please refer to the section with the same name (see Context Categories).
In real-world projects, data is collected for artifacts at different points in time. When data is imported into MQC, it is assigned to revisions. Assigning the data to revisions depends on the time stamp that is provided by the data source. If there are multiple instances of data available for the same revision, usually the latest data instance is used and visualized in MQC. As an example, consider a weekly revision granularity and several reports with data created on different days of a week. Then, the one with the latest time stamp is used for the weekly revision, see Figure 5.4
MQC supports multiple types of revision granularity:
Months (revision name e.g. “2021-10”),
CalendarWeeks (revision name e.g. “2021-W41”), and
Days (revision name e.g. “2021-08-31”).
Each project can define its own milestones, where a milestone represents an important development step, i.e. the milestone time defines the end of a respective period, which starts at the end of the previous milestone and lasts until the current milestone time.
In MQC, this is realized by clustering revisions and linking the clustered revisions to a milestone defined for a certain project according to a common timeline. This means all revisions with a start time after the previous milestone and before the current milestone are linked to the current milestone. With that, data assigned to a revision is also linked to the milestone, to which the revision belongs.
The relationship between revisions and milestones is depicted in Figure 5.5.
For details on how to define milestones in MQC see Milestones.
5.1.4. Measures and Measurements¶
Data is collected from a data source via measurements. A measurement yields one or multiple measures. This is done for an artifact at a specific point in time (by a revision). Figure 5.6 shows this workflow, i.e. the measurement yields data represented by the three dimensions Measure, Artifact and Revision.
In the following, we concentrate on one artifact for a fixed revision so that the dimensions of the data cube are reduced, see Figure 5.7.
The measurement is the process, by which data is collected and by which the values of one or multiple measures are determined. Hence, by the execution of a measurement at a certain point in time, a value is assigned to a particular measure (see Figure 5.8).
For example, the measurement “Measuring MISRA compliance” for model A and
revision X results in a guideline report containing a measure
the assigned measure value 10.
MQC often imports data from tools directly. The source of the data is named data source. For example, the tools MXAM or MTest can be data sources.
In MQC, measures are grouped. Such a group of measures directly read from a
data source is called base measure and may be for example the
Complexity (from the data source MXRAY). A base measure consists of at least
one variable (i.e.
Bad), each variable has a
Please, note that there is not necessarily a one-to-one relation between
measurement and data source. Rather it could be that a data source provides the
same measures for different measurements. For example, test results may be
related to either MiL tests or SiL tests, but nevertheless may have the same
measure names (e.g.
TestCount.Failed). In that case, measure values are
assigned to the variables of a base measure group by either executing the
measurement “MiL” or the measurement “SiL”. See
Figure 5.9 for
the relationship between data source, measurements and base measures.
5.1.5. Derived Measures¶
MQC differentiates between base measures (see Measures and Measurements) and derived measures. Derived measures are computed either from base measures or from other derived measures (see Figure 5.10). They are used to visualize their trend and/or to simplify the quality computation.
As an example, consider the measurement “Measuring MISRA compliance” with the
base measure variables
Warning. Here, a suitable
derived measure variable
Total could be added, which stands for the total
number of all
Warning guidelines (see
Total = Passed + Failed + Warning
Total = Passed + Failed + Warning
Measuring MISRA Compliance
A measure function to calculate a derived measure is executed per artifact, per revision and per measurement (see Quality Computation for more details).
For details about how to configure derived measures in MQC, please refer to Derived Measures.
For details about how to define functions and available operators, please refer to Quality Calculation.