=Paper=
{{Paper
|id=Vol-1723/3
|storemode=property
|title=Consistent Extra-Functional Properties Tagging for Component and Connector Models
|pdfUrl=https://ceur-ws.org/Vol-1723/3.pdf
|volume=Vol-1723
|authors=Shahar Maoz,Jan Oliver Ringert,Bernhard Rumpe,Michael von Wenckstern
|dblpUrl=https://dblp.org/rec/conf/models/MaozRRW16
}}
==Consistent Extra-Functional Properties Tagging for Component and Connector Models==
https://ceur-ws.org/Vol-1723/3.pdf
Consistent Extra-Functional Properties Tagging for
Component and Connector Models
Shahar Maoz1 , Jan Oliver Ringert1 , Bernhard Rumpe2,3 , and Michael von Wenckstern2
1
School of Computer Science, Tel Aviv University, Israel http://www.cs.tau.ac.il
2
Software Engineering, RWTH Aachen University, Germany http://www.se-rwth.de
3
Fraunhofer FIT, Aachen, Germany http://www.fit.fraunhofer.de
Abstract—We present a model-driven approach for adding evolution [2], and deployment [25]. The second contribution
extra-functional properties to component and connector (C&C) of this paper is a framework for defining rich consistency
models. The approach is based on a tagging mechanism that rules for tagged EFP values in the context of C&C
allows non-invasive extensions of existing languages and their
models, here C&C models, with attributes for extra-functional models. Our consistency rules are specific to an EFP and C&C
properties. Importantly, our language extension provides means element and consist of selection, aggregation, and comparison
for integrated formal analyses of the consistency of tagged values. operators. Rules select relevant C&C model elements, aggre-
Consistency ranges from type-safety and units of quantitative gate their EFP values, and compare them to determine the
measures to complex dependencies across component hierarchies consistency of the checked element’s EFP value.
as well as between component definitions and their instances. We
provide a framework for defining and checking rich consistency We implemented our ideas within MontiCore [13] for the
rules of extra-functional property values based on selection, C&C architecture description language MontiArc [11].
aggregation, and comparison operators. Our work allows for The next section presents our running example. Sect. III
independent definition and organization of tagged properties presents necessary background. The two main contributions,
to support reuse across models and development stages. The our tagging language and our consistency framework, are pre-
approach is implemented within the MontiCore framework for
the C&C architecture description language MontiArc. sented in Sect. IV and Sect. V. We present the implementation
and a discussion in Sect. VI, related work in Sect. VII, and a
I. I NTRODUCTION conclusion in Sect. VIII.
Component and connector (C&C) models are used in many
application domains of software engineering, from cyber- II. RUNNING E XAMPLE
physical and embedded systems to web services and enter- As running example we use an excerpt of a wind turbine ex-
prise applications. Their structure consists of components at ample adapted from [25], [28], as shown in Fig. 1 and Lst. 1.
different containment levels, their typed interaction points, The turbine controller (component type TurbineCtrl) con-
and connectors between them [17]. In addition to expressing tains two brake controllers (component type BrakeCtrl) to
functional properties, also extra-functional properties (EFPs) compute force on the turbine and merge the calculated result
play an important role in successful development of C&C with brake commands from the main controller MainCtrl.
models [10], [24]–[26]. Typical examples of EFPs include A team of engineers developing the controller deals with
worst-case-execution-time, memory and power consumption, various EFPs including the traceability of component im-
security properties, and traceability [1], [21], [23]. plementations to the requirements catalog and the power
We are interested in consistent definition of EFPs for C&C consumption of components. The component BrakeCtrl
models, commonly expressed in C&C architecture description is a safety relevant component and thus requires traceability
languages (C&C ADLs) [17]. Previous works in this direction for safety audits. This extra-functional property is added to
have extended the meta-models of languages or defined special the component type definition. As a requirement the power
language profiles for adding EFPs to ADLs [4], [26]. These consumption of TurbineCtrl is limited to 4W .
extension mechanisms are typically invasive to the language The team created an implementation of component type
definition and thus impede extensibility. One approach for BrakeCtrl that consumes power of 1W and is traceable. In
extending modeling languages without modifying their meta- an attempt to improve safety and provide different instances
model are tagging languages [9]. The first contribution of for subcomponents brCoA and brCoB, the team uses an
this paper is a tagging language for non-invasive extension existing implementation that consumes 2010mW . The chief
of C&C models with EFPs. This new language supports the architect decides to update the power consumption defined for
tagging of C&C elements in component definitions as well as type BrakeCtrl to the new value of 2010mW .
in their instances. A team member is unsure whether these updates are enough
The consistency of EFP values is crucial throughout the and the C&C model is consistent with respect to its EFPs. She
life-cycle of a system. Consistency checks of EFPs have been is right to doubt consistency: on the component type level
investigated for various development steps of C&C models, the power consumption of TurbineCtrl (4W ) is smaller
e.g., property definition [26], refinement and subtyping [14], than two times the power consumption of BrakeCtrl
component type • Ports is a disjoint union of input and output ports where
MA
extra-functional
each port p ∈ Ports has a name, a type type(p) ∈ Types,
TurbineCtrl power=4W
turbineCtrl instance name
properties and belongs to exactly one component p ∈ ports(cmp),
• Cons is a set of directed connectors con ∈ Cons, each
BrakeCtrl traceable, power=2010mW
MainCtrl
brCoA traceable, power=1W
of which connects two ports con.src, con.tgt ∈ Ports of
the same type, which belong to two sibling components
main
or to a parent component and one of its immediate
Merger
ForceCalc
me
subcomponents, and
foCa
• Types is a finite set of type names.
C&C models from Def. 1 are well-formed iff no component
BrakeCtrl traceable, power=2010mW is its own (transitive) subcomponent and has at most one direct
brCoB power=2010mW parent and subcomponents are connected legally (see [15] and
[22] for complete definitions).
PitchReg
piRe
Merger
While some formalisms directly express C&C models, e.g.,
ForceCalc
me
foCa
[12], [29], others provide component and connector type
definitions and their instantiation to define C&C models, e.g.,
[5], [11]. We use excerpts of component type definitions of
Fig. 1. Excerpt of slightly modified wind turbine example from [25], [28]. the ADL MontiArc in Def. 2.
Definition 2 (Component Type Definition): A compo-
1 component TurbineCtrl {
2 ports in AngularVelocity omega,
nent type definition is a structure ct = hcType, CPorts,
3 in Velocity windSpeed, CSubs, CConsi ∈ CTDefs where
4 out Byte[] controlSignals; • cType uniquely identifies the component type,
5 component MainCtrl main; • CPorts is a set of input and output port definitions where
6 component PitchReg piRe;
7 component BrakeCtrl brCoA, brCoB; each port p ∈ CPorts has a name and a type,
8 connect brCoA.brakeControl -> parkController. • CSubs ⊂ N ame × CTDefs is a set of named subcom-
brakeControlA; ponent declarations, and
9 ...
• CCons is a set of directed connector definitions con ∈
10 }
CCons, each of which connects two port definitions
Listing 1. Definition of TurbineCtrl from Fig. 1 in MontiArc. con.src, con.tgt of the same type, which belong to two
sibling subcomponent declarations or to a component
(2010mW )1 . In addition, the component instance brCoB is type definition and one of its subcomponent declarations.
not traceable despite what its type BrakeCtrl dictates. A component type t ∈ CTDefs is instantiated to a C&C
Our solution allows the engineers to add the described model by creating a component for c with subcomponents,
properties to the C&C model and component type definitions that are instances of t.CSubs with connectors according
and to check their consistency. to t.CCons. For a more detailed definition including well-
III. P RELIMINARIES formedness rules and instantiation see [22].
We start off with background on C&C models, extra- B. Extra-Functional Properties
functional properties, and tagging languages. Extra-functional properties are attributes of a system or
A. Component and Connector Models subsystem that do not directly describe functionality. Various
Component and connector models describe components, definitions of extra-functional properties exist [1], [8], [21],
their points of interaction, and their hierarchical composition. [23], [30]. Typical examples of extra-functional properties
We repeat a definition of C&C models as, e.g., given in include worst-case-execution-time, memory consumption, se-
[15], in Def. 1, which represents the essence of component curity properties, usability, maintenance, interoperability, testa-
models [17] as formalized by ADLs ACME [7], AADL [5], bility, understandability, modifiability, reusability, correctness,
and MontiArc [11], or used in the tools AutoFOCUS [12] and flexibility and also legal, economic, or cultural constraints [1],
Simulink [29]. [21], [23]. Extra-functional properties can be quantitative, e.g.,
Definition 1 (Component and Connector model [15]): A memory consumption, or qualitative, e.g., a security level or a
C&C model is a structure cncm = hCmps, Ports, Cons, Boolean property indicating whether software is portable [20].
Types, subs, ports, typei where In this paper we focus on quantitative properties with
• Cmps is a set of named components, cmp ∈ Cmps has a
clear mathematical semantics such as power consumption,
set of ports ports(cmp) ⊆ Ports and a (possibly empty) traceability, or modes of encryption.
set of immediate subcomponents subs(cmp) ⊂ Cmps, C. Tagging Language
1 Note, the described instantiation with (1W for brCoA) could be consistent Greifenberg et al. [9] presented a mechanism to derive
(depending on the other subcomponents), but the component types are not! tagging languages for domain specific modeling languages.
1 tagschema EmbeddedTagSchema {
The mechanism uses two languages: the tag model, which 2 tagtype traceable for ComponentInstance,
decorates the domain specific model with additional informa- ComponentDefinition;
tion, and the tag schema, which defines the tag types that are 3 tagtype power: Power for ComponentInstance,
ComponentDefinition; // power consumption
used in the tag model. 4 tagtype encryption: [AES, RSA, DES, 3-DES]+
Defining a tagging language based on this mechanism has for PortDefinition; // list of values
the following advantages: (1) The model will be kept clean 5 tagtype encryption: [AES, RSA, DES, 3-DES] for
PortInstance; // one value
and, therefore, easy to read, not polluted with extra infor- 6 tagtype reliability: Number for
mation; (2) Inherent separation of concerns [3], as different ConnectorInstance;
people can decorate the domain specific model with their 7 }
own separated tagging models; and (3) The tagging language Listing 2. Definition of example schema EmbeddedTagSchema for
references the elements by their concrete syntax as they are tagging C&C models and type definitions.
defined in the domain specific model. 1 conforms to EmbeddedTagSchema;
2 tags Example1 {
IV. C&C TAGGING L ANGUAGE 3 tag BrakeCtrl with traceable;
4 tag TurbineCtrl with power = 4W;
This section presents our first contribution, namely, the C&C 5 tag BrakeCtrl with power = 2010 mW;
tagging language, which allows one to add extra-functional 6 tag MainCtrl.pitchBrake with encryption = [AES
, RSA];
properties (encryption, ASIL level, traceability, memory usage, 7 tag BrakeCtrl.pitchBrake with encryption = [
power consumption, latency, etc.) from different domains (se- DES, 3-DES];
curity, safety, runtime, etc.) to existing C&C models, without 8 }
changing them. Our tagging language enables tagging of all Listing 3. Tag model for tagging concrete EFPs values to component
C&C elements from Def.s 1 and 2: type definitions
1 conforms to EmbeddedTagSchema;
1) component definitions CTDefs, e.g., BrakeCtrl, and
2 tags Example2 for turbineCtrl {
instances Cmps, e.g. brCoA; 3 tag brCoA with traceable;
2) port definitions CPorts, e.g., BrakeCtrl.pitch- 4 tag brCoA with power = 1 W;
Brake, and port instances Ports; and 5 tag brCoB with power = 2010 mW;
6 tag main.pitchBrake, brCoA.pitchBrake with
3) connector definitions CCons, e.g., brCoA.brake- encryption = AES;
Control -> parkController.brakeContolA, 7 tag brCoB.pitchBrake with DES;
and connector instances Cons. 8 tag brCoA.brakeControl -> parkController.
brakeControlA with reliability = 0.8;
9 }
A. Tag Schema Definitions
Listing 4. Tag model for tagging concrete EFPs values to component
The tag schema defines the types of the tags used to decorate instances
C&C models. One may view tag schemes as meta-models.
Similar to Greifenberg et al. [9], we have the following tag set (+ sign in L. 4) containing one or more values of the
types: (1) simple tags, when one only cares whether a C&C enumeration defined inside square brackets; whereas, in con-
element is or is not tagged with this information, similar to trast, tags for port instances contain exactly one enumeration
Java’s marker interface; (2) valued tags, decorating a C&C value. This is due to the fact that a defined port can support
element with a tag containing a value, such as Boolean, multiple encryption modes, whereas a concrete port instance
Number, String, enumeration value or a JScience2 quantity en-/decrypts its data using one concrete algorithm.
(e.g. Power or DataAmount); and (3) complex tags to
B. Tag Model Definitions
store several values, such as estimated worst-case-execution
time [26] wcet = {time=800ms, confidence=50%}. After the tag schema is defined, C&C elements can be
Since complex tags consist of several simple or valued tags, tagged with it. Listings 3 and 4 tag C&C element definitions
the rest of this paper handles only the simple and value tags. (Example1) and instances (Example2). Tag models have a
The EmbeddedTagSchema in Lst. 2 defines a tag schema header and body (e.g., Lst. 3, ll. 1-2 and ll. 3-8), containing
for C&C models used in an embedded context. It contains one additional information which is added to the C&C elements.
simple tag traceable, which can be applied for compo- Every header starts with conforms to followed by the
nent instances and definitions, and three valued tags power, tag schema name to which the tag model definition conforms
encryption, and reliability. All defined tags start to. The header also includes the tags keyword and the tag
with tagtype, have a name, and end with for plus the model’s name (e.g., Example1). Additionally, the header
C&C element to which the tag type can be applied; the valued may contain an optional list of C&C elements (a comma
tag types have after the name additionally a colon followed separated list of names after the for keyword) to address
by a data type. The data type of a valued tag can depend these C&C elements’ children directly in the body.
on the element decorated with it. This is the case for the A body is a container for several tag definitions starting
encryption tag, where port definitions are tagged with a with a tag keyword and ending with a semicolon. Each tag
definition has at least one C&C element name and one tag
2 see http://jscience.org/api/javax/measure/quantity/Quantity.html type name separated by the with keyword (e.g., Lst. 3, l. 3).
Valued tag types must additionally include the tag type’s value, Third, the rule defines how to aggregate tagged values over the
preceded by an equals sign (e.g., Lst. 3, l. 4). Multiple values selected elements. Finally, the aggregated value is compared to
are assigned by using a comma separated list inside square the value of the checked element, to determine its consistency.
brackets (e.g., Lst. 3, l. 6). We summarize the structure of consistency rules in Def. 3
Line 3 in Lst. 3 adds the traceable tag to the compo- Definition 3 (EFP Value Consistency Rule): A consistency
nent instance turbineCtrl.brCoA, because the context is rule is a structure consisting of:
turbineCtrl3 (l. 1). Line 8 in Lst. 4 shows that the domain checks name of tag and element checked by rule;
expert decorating C&C elements needs no knowledge about selection selects relevant C&C elements to check consistency;
the C&C meta-model and directly uses the concrete syntax of aggregation aggregates values of selected elements; and
the C&C model (e.g., Lst. 1, l. 8). comparison compares values to decide consistency.
V. C ONSISTENCY OF E XTRA -F UNCTIONAL -P ROPERTIES The next two subsections illustrate consistency definition
rules according to Def. 3. Sect. V-B1 presents example rules
We now present the second contribution of our paper,
for the consistency of EFP values in the context of component
namely, a framework for the definition of rich consistency rules
type instantiation. Sect. V-B2 presents example rules in the
for tagged extra-functional property values.
context of composition.
We distinguish between the consistency of EFP tags with
1) Instantiation Consistency Examples: Instantiation con-
their tag schema and the more interesting consistency of
sistency checks whether the EFPs of C&C model instances
tagged EFP values in the context of the C&C model. Our
conform to the EFPs of their type definitions. To simplify the
rules for checking the consistency of tags and their schema are
definition of rules, we employ a general operator typeOf :
independent of the specific semantics of the respective EFP.
Cmps → CTDefs, which given a component instance returns
In contrast, the consistency rules for values in the context of
its uniquely determined component type.
the C&C model are very specific to the expressed EFP.
Rule 1 (InstTrace): If the component type definition is
A. Consistency of Tags and Tag Schema traceable, all instances have to be traceable:
The following rules check for consistency of tags and their • checks: tag traceable of c ∈ Cmps
tagging schema: • selection: t := typeOf (c) ∈ CTDefs
1) tag type names are unique per C&C model element kind • aggregation: v := t.traceable
2) tagged C&C elements exist uniquely and are of the kind • comparison: v ⇒ c.traceable
defined in the schema In our example, component type BrakeCtrl is tagged as
3) every C&C element is tagged at most once per tag type traceable in Lst. 3, l. 3. while component instance brCoB
4) the tag value is of the data type defined in the schema is not tagged as traceable. It will thus be reported by
5) the unit of the tag is compatible with the unit in the Rule 1 as inconsistent.
schema, e.g., W and mW but not W and s Rule 2 (InstPower): The power consumption of an instance
6) for complex tags the above applies to every value. is at most the power consumption of its type:
Note that rule 3 does not allow to tag a C&C element twice • checks: tag power of c ∈ Cmps
for the same EFP. While one could define strategies to resolve • selection: t := typeOf (c) ∈ CTDefs
possible inconsistencies, e.g., considering maximal or minimal • aggregation: v := c.power
values, we added this rule to avoid inconsistencies. • comparison: v ≤ t.power
B. Consistency of Tags and C&C Models In our example, both component instances of type
BrakeCtrl pass the check of Rule 2 with 1W ≤ 2010mW
In addition to the consistency of tags with their tag schema, for brCoA and 2010mW ≤ 2010mW for brCoB (see Lst. 3,
the consistency of a tagged EFP value may also depend on l. 5 and Lst. 4, ll. 4-5).
its context in the C&C model. More advanced examples of Rule 3 (InstEncryption): The encryption of a port instance
consistency relate to component instantiation and composition must be in the encryption set of the port definition:
in C&C models. It is important to note that the consistency of
• checks: tag encryption of p ∈ Ports
a tagged EFP value may depend on multiple other C&C model 4 5
• selection: pt := THE pt ∈ typeOf (p.parent ).CPorts :
elements and their relation. In addition, consistency may be
pt.name = p.name
very specific to the EFP type, e.g., allowing subsets of values
• aggregation: v := pt.encryption
or defining their bounds.
• comparison: p.encryption ∈ v
To address the challenge of ensuring consistency of tagged
EFP values, we define a general framework based on consis- In our example, the port instances main.pitchBrake
tency rules. First, each rule defines what tag of which kind and brCoB.pitchBrake pass Rule 1, while port in-
of C&C model element it checks. Second, the rule specifies stance brCoA.pitchBrake violates Rule 3: AES ∈ / v =
how to select relevant C&C model elements for the check. {DES, 3-DES} (see Lst. 4, l. 6 and Lst. 3, l. 7).
3 turbineCtrl 4 Definite description operator THE x : P (x) returns x satisfying P (x).
is the top-level instance of the component type
TurbineCtrl defined in Lst. 1 5 The parent of a port is the component it belongs to.
2) Composition Consistency Examples: Composition con- of C&C model definitions and instantiations for readabil-
sistency checks whether the EFPs of C&C model elements are ity purposes, it is not possible to tag chains of instances
consistent across their composition. The following example (e.g., turbineCtrl.brCoA.brakeControl) differently
rules address consistency on the type level. Similar rules can as both of them are represented by the same AST node; the ST
be defined on the instance level. solves this problem by providing separate symbols for C&C
Rule 4 (CompPower): The combined power consumption of definitions and for all C&C instances; and (3) Contrary to the
all subcomponents is at most the power consumption of the AST, the ST is a graph with additional references making
composed component: it possible to easily navigate through it and execute more
• checks: tag power of c ∈ CTDefs complex selections as needed for consistency checks, e.g., in
• selection: S := c.CSubs Rule 5.
P
• aggregation: v := ct.power B. Discussion
(name,ct)∈S
• comparison: v ≤ c.power The ST’s resolving mechanism – containing bidirectional
In our example, the component type TurbineCtrl con- navigation together with symbol filtering and adaption – as
tains subcomponents brCoA and brCoB of type BrakeCtrl well as the ability to add several different EFP tags to the same
and v = 2010mW + 2010mW + . . . 6≤ 4W , i.e., the tagged C&C element symbol, allows to check constraints between
value of 4W violates Rule 4 and is thus inconsistent. different EFPs, such as time vs. data amount. We consider
Rule 5 (CompEncryption): A receiver port must support at this to be a nice property of our work.
least one encryption of its sender ports. Regarding composition, the complex tag is a composition
of tags (which can be complex themselves). This way, it is
• checks: tag encryption of p ∈ CPorts
possible to logically group EFPs (e.g., power consumption and
• selection: P := {p0 | ∃con ∈ CCons : (p0 = con.src ∧
confidence) as is suggested by Shaw [27] and implemented by
p = con.tgt)} T Sentilles et al. [26].
• aggregation: v := p.encryption
p0 ∈P It is important to note that extra-functional properties may
• comparison: v ∩ p.encryption 6= ∅ evolve, together with knowledge about a system [2], [14], [18].
In our example, the port BrakeCtrl.pitchBrake sup- They may also depend on the viewpoint of stakeholders [4],
ports encryption DES and 3-DES (Lst. 3, l. 7), and is a which can be solved by tagging the extra-functional tags again
receiving port for MainCtrl.pitchBrake with encryption with the stakeholders name. Since it is possible to tag elements
AES and RSA (Lst. 3, l. 6). Rule 5 will report port Brake- or tags several times, one tag can be tagged by different
Ctrl.pitchBrake as inconsistent. stakeholders. Since all the tags (including tags of tags) are
The above examples of Rule 1 to Rule 5 show the ex- stored in the same ST, consistency constraints can also be
pressiveness of consistency rules of our framework that cover expressed between tags of tags with the same concepts shown
various EFPs and C&C element relations. in Sect. V. For simplicity, in this paper we did not discuss the
tagging of one element multiple times. Rather than multiple
VI. I MPLEMENTATION AND D ISCUSSION tagging, we consider organizing ownership by using separate
tag models. Meta-model approaches cannot easily do it but it
A. Implementation is natural in our approach.
We implemented the tagging language together with its EFP Note that depending on the EFP type and its composition
consistency checks in MontiArc [11], a textual C&C modeling and instantiation semantics, the consistency of composition
framework. The workflow of processing MontiArc models is on the type level and the consistency of instantiation, do not
as follows: (1) The parser converts the textual input model guarantee consistency of instance composition. Our presented
to an abstract syntax tree (AST); (2) The AST is traversed port encryption semantics in Rule 3 and Rule 5 still allow for
to store all model definitions as symbols in the symbol table inconsistent instance compositions. We believe that a unified
(ST); (3) Based on the AST and the model definition symbols, framework, as the one we have presented, is a first step towards
all C&C instances’ symbols are created by (a) resolving the reasoning about EFP consistency.
component extension chains, (b) binding all generics, and (c)
recursively instantiating all subcomponent hierarchies. VII. R ELATED W ORK
Although the MontiArc tagging language is based on the Espinoza et al. [4] annotate UML/MARTE models with
same concepts and concrete syntax as the one presented in quantitative EFPs. One of their main goals is to distinguish
Greifenberg et al. [9], our approach adds tags to the ST sources of EFPs, e.g., requirement vs. measurement during
while their method enriches the AST directly. Decorating test. This could be done with complex tags containing the
the ST has the following advantages: (1) The ST represents actual value and the value source.
the semantic model [6], [19], and, thus, in contrast to the Grunske [10] presents an evaluation framework for EFPs
AST (see ArcConnector and ArcSimpleConnector consisting of four elements: usage profile, evaluation model,
in [11]), each C&C element in Def. 1 and Def. 2 is represented composition algorithm, and evaluation algorithm. We focus on
by exactly one symbol; (2) Since MontiArc’s AST is a mixture solutions for the composition and evaluation parts.
Sentilles et al. [26] present a meta-model for integrating
[4] H. Espinoza, H. Dubois, S. Gérard, J. L. M. Pasaje, D. C. Petriu,
non-functional properties into C&C models. Their model and C. M. Woodside. Annotating UML models with non-functional
allows to specify multiple values per attribute with validity properties for quantitative analysis. In MoDELS Int. Workshops, pages
conditions, dependencies, and version information. Since our 79–90, 2005.
[5] P. H. Feiler and D. P. Gluch. Model-Based Engineering with AADL:
models are all text-based, external version control mechanisms An Introduction to the SAE Architecture Analysis & Design Language.
such as Git or SVN can handle EFP’s history. All the other Addison-Wesley, 2012.
information, e.g., validity condition or dependencies, can be [6] M. Fowler. Domain-Specific Languages. Addison-Wesley, 2010.
[7] D. Garlan, R. T. Monroe, and D. Wile. Acme: An architecture
expressed via complex tags. Finally, the complete information description interchange language. In CASCON, pages 169–183, 1997.
tagging is available in the symbol table for consistency checks. [8] M. Glinz. On non-functional requirements. In RE, pages 21–26, 2007.
Leveque et al. [14] present a way to express refinement [9] T. Greifenberg, M. Look, S. Roidl, and B. Rumpe. Engineering Tagging
of attribute values for instances and subtypes of components. Languages for DSLs. In MoDELS, pages 34–43, 2015.
[10] L. Grunske. Early quality prediction of component-based systems - A
Similar rules can be defined in our framework. For MontiArc, generic framework. Journal of Systems and Software, 80(5):678–686,
one can formulate EFP consistency constraints for refinements 2007.
of port types (Java-like inheritance and generics) as well as for [11] A. Haber, J. O. Ringert, and B. Rumpe. MontiArc - Architectural Mod-
refinements of components (inheritance of component types). eling of Interactive Distributed and Cyber-Physical Systems. Technical
Report AIB-2012-03, RWTH Aachen, february 2012.
Cicchetti et al. [2] introduce a framework for evolution of [12] F. Huber, B. Schätz, A. Schmidt, and K. Spies. Autofocus: A tool for
EFP values and present, as an example, how the change of the distributed systems specification. In FTRTFT, pages 467–470, 1996.
worst-case-execution time (WCET) of a component requires [13] H. Krahn, B. Rumpe, and S. Völkel. Monticore: a framework for com-
positional development of domain specific languages. In International
updating the WCET of its parent component. It is possible to Journal on Software Tools for Technology Transfer (STTT), volume 12,
extend our framework to support similar evolution scenarios. pages 353 – 372, 2010.
Sapienza et al. [25] motivate the benefit of composing EFPs [14] T. Leveque and S. Sentilles. Refining extra-functional property values
in hierarchical component models. In CBSE, pages 83–92, 2011.
of components in embedded system design. They present a
[15] S. Maoz, J. O. Ringert, and B. Rumpe. Synthesis of component and
general classification of property composability and provide connector models from crosscutting structural views. In FSE, pages
many examples. In their terminology, our rules for consistency 444–454. ACM, 2013.
of composed components compute non-emergent, directly [16] S. Maoz, J. O. Ringert, and B. Rumpe. Verifying component and
connector models against crosscutting structural views. In ICSE, pages
composable properties. Additional types of composition identi- 95–105. ACM, 2014.
fied by Sapienza et al. [25] require further information beyond [17] N. Medvidovic and R. Taylor. A Classification and Comparison
the tagging language and C&C model. Framework for Software Architecture Description Languages. IEEE
Transactions on Software Engineering, 2000.
VIII. C ONCLUSION [18] T. Mens, J. Magee, and B. Rumpe. Evolving software architecture
descriptions of critical systems. IEEE Computer, 43(5):42–48, 2010.
We presented a mechanism to enrich existing C&C models [19] P. Mir Seyed Nazari, A. Roth, and B. Rumpe. An Extended Symbol
with consistent extra-functional properties. The strengths of Table Infrastructure to Manage the Composition of Output-Specific
Generator Information. In Modellierung 2016 Conference, 2016.
our approach are: (1) All EFPs are stored in separate files to
[20] OMG. UML Profile for MARTE: Modeling and Analysis of Real-Time
avoid model pollution, (2) The tag schema is used to validate Embedded Systems, 2011.
tag models to avoid tagging mistakes (typos, wrong units, [21] A. Rawashdeh and B. Matalkah. A new software quality model for
wrong C&C element, etc.), (3) EFP-specific consistency rules evaluating COTS components. Journal of Computer Science, 2(4):373–
381, 2006.
between tagged C&C elements (C&C definitions as well as [22] J. O. Ringert. Analysis and Synthesis of Interactive Component and
C&C instantiations) can be defined and verified. Connector Systems. Aachener Informatik-Berichte, Software Engineer-
We illustrated the two main contributions, our tagging ing, Band 19. Shaker Verlag, 2014.
language and consistency rule framework, using several ex- [23] G. C. Roman. A taxonomy of current issues in requirements engineering.
Computer, 18(4):14–23, April 1985.
amples. The examples cover many scenarios of consistency [24] M. Saadatmand, A. Cicchetti, and M. Sjödin. UML-based modeling of
defined also in related work. non-functional requirements in telecommunication systems. In 6th Int.
As future work we consider the application of extra- Conf. on Software Engineering Advances (ICSEA), 2011.
[25] G. Sapienza, S. Sentilles, I. Crnkovic, and T. Seceleanu. Extra-functional
functional property tags to C&C views, with corresponding properties composability for embedded systems partitioning. In CBSE,
verification between views and models, extending [16]. 2016.
[26] S. Sentilles, P. Stepan, J. Carlson, and I. Crnkovic. Integration of extra-
Acknowledgements Part of this work was done while Shahar Maoz was on sabbatical functional properties in component models. In CBSE, 2009.
as visiting scientist at MIT CSAIL. This research was supported by a Grant from the [27] M. Shaw. Truth vs. knowledge: the difference between what a compo-
GIF, the German-Israeli Foundation for Scientific Research and Development.
nent does and what we know it does. In 8th Int. Wrksp. on Software
Specification and Design, pages 181–185. IEEE, 1996.
R EFERENCES [28] J. Suryadevara, G. Sapienza, C. C. Seceleanu, T. Seceleanu, S. E.
[1] J. P. Cavano and J. A. McCall. A framework for the measurement of Ellevseth, and P. Pettersson. Wind turbine system: An industrial case
software quality. SIGSOFT Softw. Eng. Notes, 3(5):133–139, Jan. 1978. study in formal modeling and verification. In FTSCS, pages 229–245,
[2] A. Cicchetti, F. Ciccozzi, T. Leveque, and S. Sentilles. Evolution man- 2013.
agement of extra-functional properties in component-based embedded [29] MathWorks Simulink. http://www.mathworks.com/products/simulink/.
systems. In CBSE, pages 93–102, 2011. [30] S. Zschaler. Formal specification of non-functional properties of
[3] E. W. Dijkstra. A discipline of programming, volume 1. prentice-hall component-based software systems. Software and System Modeling,
Englewood Cliffs, 1976. 9(2):161–201, 2010.