Towards Metrics for Analyzing System Architectures Modeled with

EAST-ADL

Christoph Etzel, Florian Hofhammer and Bernhard Bauer

Institute of Computer Science, University of Augsburg, Germany

Keywords:

System Architecture Metrics, Model-based Systems Engineering, Automotive Systems Engineering, EAST-

ADL.

Abstract:

Quality of system and software architectures plays a major role in today’s development to reduce the com-

plexity of systems during design and ensure maintainability and extensibility. Metrics can provide system

architects with information about the quality of the system architectures and support them to ensure the qual-

ity characteristics deﬁned in ISO 25010. In this position paper, we look on selected metrics from code and

object-oriented design analysis to use them for the evaluation of system architectures modeled with EAST-

ADL. Therefore, the metrics (collections) Lines of Code, Cyclomatic Complexity, Chidamber and Kemerer

and MOOD are examined for their application on EAST-ADL models.

1 INTRODUCTION

Since the 1970s, software quality became more and

more important in the course of the evolution of soft-

ware development towards an engineering discipline.

For this reason, metrics were developed to enable

comparability of the software systems quality as key

ﬁgures. The comparison of different systems as well

as of revisions of a single system played are use cases.

At the time, quality was mainly deﬁned and measured

with regard to the prevailing imperative programming

paradigms. The change to object-oriented program-

ming then required fundamental changes and exten-

sions of the previously deﬁned key ﬁgures. Since the

publication and subsequent distribution of the Uni-

ﬁed Modelling Language (UML), extensions emerged

with the possibility not only to measure code quality,

but also to analyze models and architectures already

before the implementation.

Today it is important not only to examine pure

software architectures and measure their quality, but

also to consider system architectures (more precisely,

functional and logical architectures). A prominent ex-

ample for complex system architectures are modern

automobiles, which contain various electronic control

units, sensors, actuators and entertainment systems,

communicating with each other by an interaction of

software and hardware. Among others, the architec-

ture description language EAST-ADL can be used to

model such systems.

In the context of the Electronics Architecture and

Software Technology - Architecture Description Lan-

guage (EAST-ADL), literature lacks of concrete met-

rics for measuring the quality of modeled system ar-

chitectures. In this position paper, we present some

potential metrics to narrow this gap. If available, such

quality measuring metrics can then be used in review

processes like Architecture Tradeoff Analysis Method

(ATAM) and support the decision-making. There-

fore, approaches of quality analysis from the software

development are studied and afterwards possibilities

for the adjustment and application of these on EAST-

ADL models are pointed out. The aim is to form the

basis for empirical evaluations of the quality of sys-

tem architectures (functional/logical architecture) and

thus to lay the foundation for an automated quality

analysis of such models. In the context of this position

paper, explicitly no extensive evaluations and classi-

ﬁcations of applied metrics are made, but possible in-

terpretations for the analysis are pointed out. Further-

more, currently only metrics from software develop-

ment are considered and none from hardware design.

First, this paper explains the basic structure of the

modeling language EAST-ADL. After a clariﬁcation

of the quality concept in software development, met-

rics for the analysis of code and object-oriented soft-

ware designs are presented and transferred to EAST-

ADL models where possible. We conclude with a

summary and outlook on further steps that can follow

this work.

Etzel, C., Hofhammer, F. and Bauer, B.

Towards Metrics for Analyzing System Architectures Modeled with EAST-ADL.

DOI: 10.5220/0009165704410448

In Proceedings of the 8th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2020), pages 441-448

ISBN: 978-989-758-400-8; ISSN: 2184-4348

441

Environment Model

System Model

Vehicle Level

Analysis Level

Design Level

Implementation Level

Technical Feature Model

Functional Analysis Architecture

Functional Design Architecture Hardware Design Architecture

AUTOSAR

Application SW

AUTOSAR

Basic SW

AUTOSAR

Requirements

Variability

Timing

...

Extensions

Figure 1: EAST-ADL abstraction levels with the containing

models and extensions (based on (Blom et al., 2016)).

2 EAST-ADL

The Electronics Architecture and Software Technol-

ogy - Architecture Description Language (EAST-

ADL) is developed and administered by the EAST-

ADL Association. The current version of the spec-

iﬁcation is 2.1.12 (EAST-ADL Association, 2013).

This architecture description language can be consid-

ered an extension of the UML and a specialization of

Systems Modelling Language (SysML) (Blom et al.,

2016).

EAST-ADL allows to comprehensively represent

and model the electronic systems of a vehicle, their

features and characteristics, the requirements and the

communication from the hardware to the software

level (Blom et al., 2016). The system is described in

several horizontal levels, which are extended by verti-

cal layers (Extensions) to model concerns on different

degrees of abstraction.

The horizontal structure consists of the System

Model (see Figure 1) and provides the means to

model system architectures. This is supplemented

by the Extensions with additional modeling possibili-

ties. These are of particular importance with regard

to ISO 26262, for example. ISO 26262 describes

the functional safety requirements for road vehicles

(ISO, 2018). Using the EAST-ADL extensions (e.g.

Requirements, Dependability), modeling means can

be used to ensure that safety requirements are docu-

mented and met by model (Blom et al., 2016). The

Environment Model describes the external inﬂuences

on the system. For example, mechanical and hy-

draulic systems in the vehicle, the environment in-

cluding road surface, adjacent vehicles and trafﬁc

information systems can be included (Blom et al.,

2016).

In this paper, just the architectures on Analysis

and Design Level of the system model are further

investigated, since these contain functional architec-

tures. The System Model itself is divided vertically

into four levels, which abstract the system to different

degrees. At the Vehicle Level, the vehicle is described

from a feature perspective. The Analysis Level pro-

vides the FunctionalAnalysisArchitecture (FAA) that

deﬁnes systems from a functional perspective. The

architecture describes “which” functions are required

and which data they exchange. Figure 1 shows the

Design Level further subdivided into the Function-

alDesignArchitecture (FDA) and the HardwareDesig-

nArchitecture (HDA). On this level, the FDA models

“how” functions are realized from a more technical

viewpoint. However, no concrete software elements

are modeled. The hardware design architecture, on

the other hand, represents the structure of the sys-

tem in hardware so that different functions from the

FDA can then be mapped to the hardware entities of

the HDA. Finally, the Implementation Level models

the actual implementation of the software and hard-

ware. This level is not deﬁned by the EAST-ADL,

but by AUTomotive Open System ARchitecture (AU-

TOSAR). This part is outside the deﬁnitions of the

EAST-ADL and not analyzed in this paper.

3 THE CONCEPT OF SOFTWARE

QUALITY

Ensuring high software quality is an important part of

software engineering and plays a major role in reduc-

ing the time and cost of developing a software project

(Liggesmeyer, 2009). Therefore, more and more at-

tention is placed on this and quality assurance tech-

niques have been developed that deliver comparable

results as far as possible, e.g. an absolute numerical

value as a result of the application of a quality metric.

When talking about software quality, reference is

often made to the ISO 9000 series of standards, which

generally provides standards for quality management,

and speciﬁcally to the ISO/IEC 9126-1:2001 (ISO

9126) standard, as the mention in literature shows:

(Liggesmeyer, 2009), (Sneed et al., 2010), (Abran,

2010), (Hoffmann, 2013), (Kan, 2003). ISO 9126

deﬁnes criteria for product quality in software devel-

opment and thus criteria for software quality. It has

been replaced by the standard ISO/IEC 25010:2011

(ISO 25010) in 2011 (ISO, 2011).

Since this is a standardized and globally recog-

nized deﬁnition of the quality of a software product,

the content of this standard is used in the following as

criteria for software quality.

Quality Characteristics According to ISO 25010.

According to ISO 25010, there are both quality char-

acteristics for software in use and for product quality.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

442

The ﬁrst grouping refers to the interaction of users

with the software and to what degree it meets the spe-

ciﬁc requirements. The quality characteristics for the

software as a product deﬁnes quality independently

of the user, based on objective requirements (ISO,

2011). This also means that product quality can be

determined statically without user interaction. There-

fore, only this part of the ISO standard is considered

in this paper, since the quality of an architecture is to

be determined and not the quality of the ﬁnal product

(usefulness, freedom from health risks ...).

The criteria for product quality can be divided into

eight characteristics according to ISO 25010: func-

tional suitability, reliability, performance efﬁciency,

usability, security, compatibility, maintainability and

portability. These are further divided into sub-criteria.

4 METRICS FOR EAST-ADL

In the previous section, ISO 25010 was introduced

as a foundation for the deﬁnition of software quality.

Now it is a matter of measuring this software quality.

For this purpose, many metrics have been published in

literature, which are supposed to summarize the still

abstract concept of quality in numbers. In this sec-

tion, metrics from code analysis and object-oriented

design analysis are presented to calculate key values,

which can be used to evaluate architectures according

to the quality criteria. The selection of metrics is not

intended to be exhaustive.

4.1 Selected Code Metrics

A large number of metrics refer to ﬁndings from the

source code of a ﬁnished software product, which

cannot provide direct ﬁndings in the case of the analy-

sis of EAST-ADL architecture models. Nevertheless,

for the sake of completeness and due to the great im-

portance in literature, two metrics have been selected.

4.1.1 Lines of Code

Lines of Code (LOC) is a software metric for the

source code size of a program. A simple connection is

established: the higher the number source code line,

the more extensive the software project. If the LOC

for individual software modules or classes are calcu-

lated, conclusions can be drawn with the LOC as a

basis, for example with regard to freedom from er-

rors, by evaluating a correlation between LOC and the

number of errors. Mapping the metric to quality char-

acteristics of the ISO 25010, high values may neg-

atively inﬂuence the functional suitability, reliability

and maintainability.

With regard to the freedom from errors, particu-

larly small or particularly large modules usually have

more errors per LOC. Since the number of external

interfaces of a module is usually relatively constant

regardless of its size, errors in the interfaces are of

greater impact for smaller modules or classes. Large

modules become more confusing and difﬁcult for de-

velopers to control, which is why more errors creep

in. (Kan, 2003)

This metric is supposed to be easy to measure,

since you only have to count the lines of the source

code ﬁles. In fact, this metric is much more complex

and difﬁcult to use, because the comparability of the

values is usually not given. It depends on many vari-

ables like the programming language, programming

style, coding guidelines for code formatting, to men-

tion a few (Hoffmann, 2013) (Kan, 2003). In terms of

quality, it is very difﬁcult to draw comparable conclu-

sions.

Transfer to EAST-ADL. Although one could mea-

sure the LOC of EAXML ﬁles, which contain EAST-

ADL models in a standardized eXtensible Markup

Language (XML) format, this would not provide any

signiﬁcant ﬁndings for the quality an architecture. On

the one hand, such ﬁles generally contain more than

the elements of the FAA, FDA and HDA, on the other

hand the goal of the analysis of system architectures

on the basis of their representative diagrams is missed.

Therefore, the application of this metric to EAST-

ADL does not provide any valuable insights.

4.1.2 Cyclomatic Complexity (McCabe)

In 1976, McCabe presented the Cyclomatic Complex-

ity (McCabe, 1976), which is based on a completely

different approach than LOC. The method does not

analyze the program code itself, but creates a control

ﬂow graph from the code, from whose structure the

complexity of the code could be calculated.

The formula for calculating the cyclomatic com-

plexity is a slightly modiﬁed formula from graph the-

ory, which describes the maximum number of lin-

ear independent cycles in strongly connected graphs

(McCabe, 1976) (Liggesmeyer, 2009). The modiﬁca-

tion refers only to the insertion of an additional edge

from the end node to the start node of the control ﬂow

graph, otherwise control ﬂow graphs usually cannot

be considered as strongly connected. The following

terms apply in the further course of this section:

Towards Metrics for Analyzing System Architectures Modeled with EAST-ADL

443

G = control ﬂow chart,

= single independent control ﬂow graph,

E = set of edges,

N = set of nodes,

n = # independent control ﬂow graphs

The cyclomatic complexity of a single strongly con-

nected control ﬂow graph is indicated by the follow-

ing formula:

V (G) = |E| − |N| + 2

(1)

This formula results from

V (G) = |E| − |N| + 2n

(2)

with n = 1. This generalized form calculates the cy-

clomatic complexity of several independent control

ﬂow graphs (e.g. several methods of a class).

V (G) = |E| − |N| + 2n =

∑

i=1

V (G

)

(3)

Thus, the calculation of the cyclomatic complexity of

a network of functions and methods is only as com-

plex as the calculation of the cyclomatic number for

the independent graphs of the individual functions

and methods.

During the calculation, it becomes clear that the

cyclomatic number does not change when sequential

instructions are inserted, since in this case the addi-

tional edge is compensated by the additional node.

The same applies when removing instructions from

sequential program parts (McCabe, 1976) (Hoffmann,

2013). Therefore, in principle, no causality can be es-

tablished between program size and cyclomatic num-

ber, even if a certain correlation often occurs (Kan,

2003). A similar correlation can also be observed be-

tween the number of errors in the program and the

cyclomatic complexity, whereby here too a causality

cannot be proven (Abran, 2010) (Kan, 2003).

Nevertheless, McCabe suggests a maximum cy-

clomatic complexity of 10 (McCabe, 1976). This

automatically limits the number of loops and deci-

sions because, unlike sequential statements, they in-

sert more new edges than nodes into a control ﬂow

graph. This approach should keep the code readable

and thus enable a more efﬁcient and error-free imple-

mentation. In addition, this metric simpliﬁes the iden-

tiﬁcation of code sections that have been implemented

in an excessively complex way (Kan, 2003). The

term “complex” is to be understood as “with many

loops and decisions” . Since the cyclomatic complex-

ity speciﬁes the maximum number of test cases for a

complete branch coverage, this metric is also suitable

as the upper bound of the effort estimate for branch

coverage tests (Liggesmeyer, 2009). Thus, the cyclo-

matic complexity has a direct inﬂuence on the ISO

25010 maintainability quality criteria.

Transfer to EAST-ADL. The calculation of the cy-

clomatic complexity is not directly transferable to

EAST-ADL models, because there is no code with

control ﬂows in the architectures modeled. Neverthe-

less, this metric is of interest in the context of EAST-

ADL models.

If one considers the representation of a FAA, FDA

or HDA as control ﬂow graphs, the calculation rules

could be applied. However, this requires redeﬁnitions,

because these models are not control ﬂow graphs but

data ﬂow graphs. In the considered EAST-ADL mod-

els, connections between entities deﬁne mostly di-

rected information ﬂows, which justiﬁes this adapta-

tion. Thus, the entities of the models are not states in

the program ﬂow, but states in the data ﬂow.

The problem occurs, however, that entities in

EAST-ADL can have several incoming and outgoing

edges, since information can enter or being sent at the

same time. This could be seen in a control ﬂow graph

as an expression of parallelism or concurrency. How-

ever, the cyclomatic complexity only considers se-

quential program ﬂows (de Paoli and Morasca, 1990).

In their paper, De Paoli and Morasca propose the use

of Petri nets instead of normal control ﬂow graphs and

based on this an extension of the cyclomatic complex-

ity to parallel software. The parallelism is modeled

by several incoming and outgoing edges in and from

transitions.

The necessary intermediate step is a transfer of an

EAST-ADL model like the FAA to a Petri net. For

example using the functions of the model as places

of the Petri net, every place could have exactly one

incoming and one outgoing edge of exactly one tran-

sition. This transition can then have several incoming

or outgoing edges.

A continuation of this consideration as well as

its evaluation or other approaches for the transfer of

EAST-ADL models to Petri nets, go beyond the scope

of this paper. The application of the cyclomatic com-

plexity to EAST-ADL architecture models needs fur-

ther research.

4.2 Selected Object-oriented Metrics

In addition to the code metrics discussed so far, which

mainly refer to code implemented with imperative

programming paradigms, there are also many metrics

published referring to object-oriented code or object-

oriented models.

4.2.1 Chidamber and Kemerer

The metrics by Chidamber and Kemerer (Chidamber

and Kemerer, 1994) have often been quoted in litera-

ture (Sneed et al., 2010). Most of these metrics can

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

444

be applied directly to models such as UML class or

sequence diagrams, since they do not require a refer-

ence to the code for the calculation.

In this paper, we focus on the metrics Coupling

between Object Classes (CBO) and Response for a

Class (RFC). The other metrics Weighted Methods

per Class (WMC), Lack of Cohesion in Methods

(LCOM), Depth of Inheritance Tree (DIT) and Num-

ber of Children (NOC) are not explained, since we see

no portability to EAST-ADL models and omit them

for reasons of space. See the original publication for

further information.

Coupling between Object Classes (CBO). The

metric CBO is supposed to be a measure for the cou-

pling between classes. In (Chidamber and Kemerer,

1994) it is deﬁned as the number of associations of

the considered class to other classes, where in (Sneed

et al., 2010) represents another interpretation of the

metric using the formula

CBO = 1 −

# classes with associations

# associations

(4)

In this way, they generalize the measure from one

class to an entire system.

Chidamber and Kemerer present three possible in-

terpretations for this metric. First, they write that too

high coupling speaks against a modular design and

limits the reusability of the class in question due to

its many dependencies. Subsequently, they conclude

from high coupling to high maintenance effort or poor

maintainability, since the high coupling increases the

sensitivity for changes in other parts of the software

system. Finally, they state that an increased coupling

also entails more testing effort. Therefore, the cou-

pling should be kept as low as suitable in order to im-

prove the ISO 25010 characteristics reusability, main-

tainability and testability.

Response for a Class (RFC). The RFC measure in-

dicates how many methods can be called in response

to receiving a message from an object. It is deﬁned

by the following formulas:

RFC = |RS| (5)

RS = {M} ∪

all i

} (6)

Where RS is the so-called Response Set, which is

deﬁned as the methods M of the class to which the

called object belongs, and the methods R

, which can

be called by the methods of the class. Thus, this set

contains either directly or also transitively all those

methods which can be called when receiving a mes-

sage of the object, no matter whether as direct method

call, when creating the object by the constructor or in

other ways.

It should be noted, however, that the calculation of

the metric is not recursively carried out for reasons of

meaningfulness and practicability and therefore only

the methods called directly by methods of the class in

question are actually included in the set of R

(Chi-

damber and Kemerer, 1994).

An alternative deﬁnition of the metric is provided

by (Sneed et al., 2010):

RFC = 1 −

# dynamic calls + 1

# potential target methods

(7)

The difference to the original deﬁnition by Chidamber

and Kemerer is that not the number of potentially

callable methods is measured, but a rational measure

for the polymorphism is given. In this context, a dy-

namic call is one that can have several different target

methods, for example, if the same method signature

occurs with different implementations of the method

body in connection with inheritance at several levels

of the inheritance hierarchy. For this reason, the deﬁ-

nition uses a subset and does not include all methods

of a class and messages to it as in the original deﬁni-

tion.

The idea of this RFC deﬁnition is that an increased

polymorphism increases the complexity of the call,

since it is less predictable which actual implemen-

tation of the method will be called. A similar re-

lationship is established with the original deﬁnition.

Chidamber and Kemerer describe that an increased

value for RFC requires a better code understanding

and makes testing and debugging more difﬁcult (Chi-

damber and Kemerer, 1994). They therefore conclude

that increasing the RFC value also increases the com-

plexity of the class. Therefore, one can conclude that

the value of this metric should be kept low. However,

it does not make sense to keep the number of methods

unnecessarily low, but an appropriate mean should be

sought.

Transfer to EAST-ADL. As initial stated, some of

measures can be excluded from an application to the

FAA, FDA and HDA. This is because the considered

parts of the EAST-ADL system models have no cor-

respondences for methods and inheritance. Thus, the

metrics WMC and LCOM are ruled out due to a lack

of methods, since they are based only on instance

variables, complexity or number of the methods. The

same applies to the metrics DIT and NOC, which re-

quire an inheritance hierarchy for the calculation.

The metric CBO can be transferred to EAST-ADL

models. All entities of the considered models are

used as correspondences of classes. The connections

Towards Metrics for Analyzing System Architectures Modeled with EAST-ADL

445

between the input and output interfaces of the enti-

ties are regarded here as connections. Since the mea-

sure of coupling aims to measure the information ﬂow

between individual entities or objects, this metric is

meaningful on the levels of FAA and FDA, since the

connections model the data ﬂow. If, on the other hand,

the HDA is considered, the meaningfulness of this

metric can decrease, because in addition to data ﬂow

paths (bus systems), electrical power supply lines can

also be modeled. From a functional data ﬂow per-

spective, connections representing power lines should

not have an inﬂuence on the coupling and therefore be

excluded.

The RFC metric requires closer consideration,

since it depends on knowledge of the methods of

a class to calculate this metric. According to Chi-

damber and Kemerer, this metric is generally a mea-

sure for the potential communication between classes

(Chidamber and Kemerer, 1994). Based on the idea

of communication potential, a deﬁnition for the cal-

culation of this metric can be derived for EAST-ADL

models. The RS is not understood as a set of poten-

tially callable methods inside and outside the class,

but is redeﬁned as the set of potentially usable mes-

sage channels for sending messages as a reaction to

incoming information. This corresponds to the idea

that entities in the FAA, FDA and HDA react to some-

thing. For example, in the case of sensors in the HDA

model, this can be environmental inﬂuences detected

by the sensors. Or in the case of an AnalysisFunction

of the FAA model, this can be data received through

incoming connections. As a response, any entity with

outgoing connections can then output processed data.

Depending on the number of outgoing connections,

the potential for outgoing data ﬂows is different, so

this modiﬁed metric provides an indication of this po-

tential. In this deﬁnition, however, the number of out-

going messages per connection is irrelevant. This is

equivalent to the original deﬁnition of Chidamber and

Kemerer, where only the set of potentially callable

methods plays a role and not the number of method

calls.

Analogous to the original metrics of Chidamber

and Kemerer it is advisable to keep the values of the

CBO and RFC low. This makes individual functions

or components more easily interchangeable, which

makes the system easier to adapt to special deploy-

ment scenarios during development or, in the case of

defective hardware components during run-time, eas-

ier to maintain.

4.2.2 MOOD

The set of Metrics for Object-Oriented Design

(MOOD) contains metrics to determine the quality of

an object-oriented software design. It was published

in 1994 with a number of eight metrics (Abreu and

Carapuc¸a, 1994).

The eight metrics have in common that their val-

ues are all in [0, 1] ⊂ R and therefore can be given

as degrees from 0% to 100%. 0% stands for total

absence and 100% for total presence of a property

measured by the corresponding metric. Furthermore,

the metrics do not refer to a single class (as the Chi-

damber and Kemerer metrics), but to the whole sys-

tem. Since we did not transfer all metrics for the use

with EAST-ADL models, we ommit the description

of the Method Hiding Factor (MHF), Attribute Hiding

Factor (AHF), Method Inheritance Factor (MIF), At-

tribute Inheritance Factor (AIF), Polymorphism Fac-

tor (PF) and Reuse Factor (RF).

Coupling Factor (COF) and Clustering Factor

(CLF). The Coupling Factor (COF) indicates how

strong the coupling of the classes of the system is.

The formula for this metric is

COF =

# all refs from classes to other classes

− n

(8)

where n is the number of classes in the system (Abreu

and Carapuc¸a, 1994). The term references must be

understood here very comprehensively: according to

the authors, for example, method calls can be summa-

rized here just like global or local variables with ref-

erence to another class (Abreu and Carapuc¸a, 1994).

As already stated for the metric CBO in Sec-

tion 4.2.1, the coupling should be kept as low as suit-

able. Abreu and Carapuc¸a also conﬁrm this objective

by writing that classes should communicate with each

other as little as possible and if it is not avoidable, ex-

change as little data as possible. In addition, a high

coupling would increase the complexity and would

reduce the encapsulation, reusability, comprehensibil-

ity and maintainability of the code. This would either

directly or indirectly counteract the goals of the ISO

25010 quality model (see Section 3).

The Clustering Factor (CLF) metric is similar, be-

cause it is a measure for the coupling in a system,

albeit on a different level. A cluster of classes is to

be understood as a coherent subgraph of a graph that

represents the system, with the classes representing

the nodes and any associations, references, or inheri-

tances representing the edges between the nodes. This

graph can consist of disjunctive and unconnected sub-

graphs, each such subgraph being a cluster. Thus, the

CLF is deﬁned by

CLF =

# clusters

# classes in the system

(9)

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

446

It can be concluded from the deﬁnition that a higher

CLF is desirable, since smaller clusters can be an indi-

cation of good function and data encapsulation in the

individual clusters and better reusability due to less

dependence on other classes.

Both COF and CLF are difﬁcult to calculate from

a component model or class diagram alone, since they

are not only based on associations and inheritances,

but also explicitly on references such as method calls

in the code. One could limit the metrics to the cal-

culation by means of information readable from class

diagrams, but this falsiﬁes the expressiveness of the

metrics and should therefore not be understood as a

fully-ﬂedged alternative, but at most be used as a sup-

plement to other, more expressive measures.

Transfer to EAST-ADL. The lack of correspon-

dences for methods or inheritance in EAST-ADL of-

ten prevents the direct transfer of the MOOD metrics.

Attributes can be provided to entities in the EAST-

ADL architecture models, e.g. for electrical compo-

nents of the HDA, but there exists no equivalent for

the visibility of attributes. However, in cases where

attributes are used to calculate metrics, the visibil-

ity or inheritance of the attributes plays a role. For

these reasons the metrics MHF, AHF, MIF, AIF and

PF are excluded for further consideration. In addition,

the number of library classes is used for the calcula-

tion of RF. Although there are packages deﬁned in

EAST-ADL, they are intended to structure the entire

EAST-ADL model in a human understandable way

and should therefore not be understood as packaging

in the sense of software libraries.

In contrast, the CLF can be transferred without

problems. As in the original deﬁnition, the dis-

joint, coherent subgraphs are understood as clusters.

Classes correspond in this interpretation to the ele-

ments of the considered architecture model. Thus,

the value of this metric can be calculated as the quo-

tient of the number of clusters and the number of el-

ements in the model. As in the version intended for

software architectures, it can also be concluded here,

that a larger value is desirable for the CLF in order to

keep the dependency on other elements.

Finally, the coupling is measured by the COF,

which is originally deﬁned by the references between

classes and the number of classes. The entities con-

tained in an EAST-ADL model can be used as classes

again. With the references, however, a new deﬁni-

tion of this term is necessary. According to the orig-

inal deﬁnition, references can be both associations

between elements and method calls on other objects

(Abreu and Carapuc¸a, 1994). Since the aspect of

methods is missing in the architecture models of the

EAST-ADL it cannot be considered and is omitted for

the calculation. Analogous to the CBO metric (see

4.2.1) , the power lines on the HDA should be ex-

cluded from the set of associations.

5 RELATED WORK

There are many publications regarding quality metrics

for software and system engineering. An overview of

metrics can be found for example in (Mohagheghi and

Dehlen, 2009).

MATLAB Simulink models are commonly used in

the automotive domain to solve control system engi-

neering tasks. EAST-ADL provides the feature to link

such models to have a behavioral description of func-

tions via the behavior extension. Scheible (Scheible,

2012) presents an approach for automatic quality rat-

ing of MATLAB Simulink models. The metrics in

this approach are created for Simulink models and

cannot simply be applied to the FAA, FDA or HDA

of EAST-ADL models.

SysML is closely related to EAST-ADL. Frieden-

thal et al. describe in their book “A Practical Guide to

SysML” (Friedenthal et al., 2014), that model-based

metrics are a good tool to assess on the quality of a

design. They do not deﬁne concrete metrics, but give

hints, which parameters of a SysML model are of in-

terest for different kinds of metrics.

Architecture evaluations represent a comprehen-

sive approach to the evaluation and analysis of

speciﬁc or general quality criteria. Examples are

Architecture-Level Modiﬁability Analysis (ALMA)

(Bengtsson et al., 2004), Scenario-based Architec-

ture Analysis Method (SAAM) (Kazman et al., 1994)

and Architecture Trade-off Analysis Method (ATAM)

(Kazman et al., 1998). These evaluations go beyond a

pure metric assessment. However, metrics can play a

supporting role in the various evaluation steps of the

processes.

6 CONCLUSIONS AND FUTURE

WORK

In this position paper, we presented metrics to support

system designer in development process of EAST-

ADL system architectures. Therefore, we gave a

short introduction of the quality characteristics for

system and software development deﬁned by ISO

25010. In order to be able to conclude on the qual-

ity of EAST-ADL architectures we examined selected

metrics from code analysis and object-oriented design

Towards Metrics for Analyzing System Architectures Modeled with EAST-ADL

447

and proposed the application of these on EAST-ADL

architecture models where possible.

The results of this paper do not provide a classi-

ﬁcation of which values can be regarded as “good”

or “bad” for the metrics. For this purpose, a detailed

evaluation of the metrics on models of already known

quality is necessary. Then, using these metrics as key

values to support other analysis like the partition anal-

ysis of EAST-ADL models (Etzel and Bauer, 2019)

would be an application.

Section 4 exploits only a very small selection

of available metrics for the quality determination of

software, system and hardware design. Many more

measures can be examined for their transferability to

EAST-ADL models (see Section 5). Transferring the

presented metrics to the more widespread SysML was

not considered in this paper but may be of particular

interest, since EAST-ADL is a specialization of this

modeling language. As mentioned, a further analysis

of the cyclomatic complexity in the context of EAST-

ADL models may be valuable (see Section 4.1.2).

ACKNOWLEDGEMENTS

This work was partially funded within the project

ARAMiS II by the German Federal Ministry for Edu-

cation and Research with the funding ID 01IS16025.

The responsibility for the content remains with the au-

thors.

REFERENCES

Abran, A. (2010). Software Metrics and Software Metrol-

ogy. John Wiley & Sons, Inc., Hoboken, New Jersey.

Abreu, F. B. and Carapuc¸a, R. (1994). Object-oriented

software engineering: Measuring and controlling the

development process. In Proc. Int’l Conf. Software

Quality (QSIC).

Bengtsson, P., Lassing, N., Bosch, J., and van Vliet,

H. (2004). Architecture-level modiﬁability analysis

(alma). Journal of Systems and Software, 69(1):129 –

147.

Blom, H., Chen, D., Kaijser, H., L

onn, H., Papadopoulos,

Y., Reiser, M., Kolagari, R., and Tucci-Piergiovanni,

S. (2016). EAST-ADL: An architecture description

language for automotive software-intensive systems

in the light of recent use and research. International

Journal of System Dynamics Applications, 5:1–20.

Chidamber, S. R. and Kemerer, C. F. (1994). A metrics

suite for object oriented design. IEEE Transactions

on Software Engineering, 20:476–493.

de Paoli, F. and Morasca, S. (1990). Extending software

complexity metrics to concurrent programs. In Pro-

ceedings., Fourteenth Annual International Computer

Software and Applications Conference, pages 414–

419.

EAST-ADL Association (2013). EAST-ADL Domain

Model Speciﬁcation. Version V2.1.12.

Etzel, C. and Bauer, B. (2019). Extending EAST-ADL

for modeling and analysis of partitions on functional

architectures. In Proceedings of the 7th Interna-

tional Conference on Model-Driven Engineering and

Software Development - Volume 1: MODELSWARD,,

pages 169–178. INSTICC, SciTePress.

Friedenthal, S., Moore, A., and Steiner, R. (2014). A Practi-

cal Guide to SysML, Third Edition: The Systems Mod-

eling Language. Morgan Kaufmann Publishers Inc.,

San Francisco, CA, USA, 3rd edition.

Hoffmann, D. W. (2013). Software-Qualit

at. Springer

Vieweg, Springer-Verlag Berlin Heidelberg, 2 edition.

ISO (2011). ISO/IEC 25010:2011. Standard, International

Organization for Standardization.

ISO (2018). ISO 26262-1:2018. Standard, International

Organization for Standardization.

Kan, S. H. (2003). Metrics and models in software quality

engineering. Pearson Education, Inc., 2 edition.

Kazman, R., Bass, L., Webb, M., and Abowd, G. (1994).

Saam: A method for analyzing the properties of soft-

ware architectures. In Proceedings of the 16th Inter-

national Conference on Software Engineering, ICSE

’94, pages 81–90, Los Alamitos, CA, USA. IEEE

Computer Society Press.

Kazman, R., Klein, M., Barbacci, M., Longstaff, T., Lip-

son, H., and Carriere, J. (1998). The architecture

tradeoff analysis method. In Engineering of Complex

Computer Systems, 1998. ICECCS ’98. Proceedings.

Fourth IEEE International Conference on, pages 68–

78.

Liggesmeyer, P. (2009). Software-Qualit

at – Testen,

Analysieren und Veriﬁzieren von Software. Spektrum

Akademischer Verlag Heidelberg, 2 edition.

McCabe, T. J. (1976). A complexity measure. IEEE Trans-

actions on Software Engineering, SE-2(4):308–320.

Mohagheghi, P. and Dehlen, V. (2009). Existing model met-

rics and relations to model quality. In Proceedings

of the Seventh ICSE Conference on Software Qual-

ity, WOSQ’09, pages 39–45, Washington, DC, USA.

IEEE Computer Society.

Scheible, J. (2012). Automated quality rating on the ex-

ample of matlab simulink models in the automotive

domain. Dissertation, Universit

at T

ubingen.

Sneed, H. M., Seidl, R., and Baumgartner, M. (2010). Soft-

ware in Zahlen - Die Vermessung von Applikationen.

Carl Hanser Verlag M

unchen.

MODELSWARD 2020 - 8th International Conference on Model-Driven Engineering and Software Development

448