5. 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. 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.

../_images/MQC_DimensionsStructures_ExampleOfArtifacts.png

Figure 5.1 Example of artifacts in MQC

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.

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.

../_images/MQC_DimensionsStructures_ArtifactGrouping.png

Figure 5.2 Artifact grouping in MQC

For details about how artifacts can be grouped in MQC, please refer to Artifact Structure.

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).

../_images/MQC_DimensionsStructures_CC.png

Figure 5.3 Relationship between artifacts and data sources (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).

5.2. Revisions

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

../_images/MQC_DimensionsStructures_Revisions.png

Figure 5.4 Assigning data to revisions

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”).

5.3. Milestones

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.

../_images/MQC_DimensionsStructures_RelationshipProjectsMilestones.png

Figure 5.5 Relationship between project, milestones and revisions

For details on how to define milestones in MQC, please refer to Project Naming and Project Milestone Structure, respectively.

5.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.

../_images/MQC_DimensionsStructures_FromMeasurementToData.png

Figure 5.6 From measurement to data

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.

../_images/MQC_DimensionsStructures_FreezeArtifactAndRevisionDimension.png

Figure 5.7 Freeze artifact and revision dimension

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).

../_images/MQC_DimensionsStructures_MeasurementYieldsMeasures.png

Figure 5.8 Measurement yields measures

For example, the measurement “Measuring MISRA compliance” for model A and revision X results in a guideline report containing a measure Passed and 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 Local Complexity (from the data source MXRAY). A base measure consists of at least one variable (i.e. Good, Acceptable and Bad), each variable has a measure value.

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.

../_images/MQC_DimensionsStructures_DataSourcesMeasurementsBaseMeasures.png

Figure 5.9 Data Source, measurements and base measures

5.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.

../_images/MQC_DimensionsStructures_RelationshipMeasurementsBaseDerivedMeasures.png

Figure 5.10 Relationship between measurements, base measures and derived measures

As an example, consider the measurement “Measuring MISRA compliance” with the base measure variables Passed, Failed and Warning. Here, a suitable derived measure variable Total could be added, which stands for the total number of all Passed, Failed and Warning guidelines (see Table 5.1):

Total = Passed + Failed + Warning

Table 5.1 Derived measure for measuring MISRA compliance

Measurement

Base Measure

Derived Measure

Passed

Failed

Warning

Total = Passed + Failed + Warning

Measuring MISRA Compliance

10

5

5

20

The function for the derived measures can be used for multiple measurements as long as they have the same base measures. For the above example, this means the derived measure Total can also be computed for the measurements “Measuring MAAB compliance” and “Measuring TargetLink Known problems compliance”.

For details how derived measures are defined in MQC, please refer to Derived Measures.