1. Art and Diseño

KumbangSec: An Approach for Modelling Functional and Security Variability
in Software Architectures
Varvana Myll¨arniemi, Mikko Raatikainen, Tomi M¨annist¨o
Helsinki University of Technology
Software Business and Engineering Institute
P.O. Box 9210, 02015 TKK, Finland
{varvana.myllarniemi, mikko.raatikainen, tomi.mannisto}@tkk.fi
Abstract
Software products often need to vary in terms of functionality, but also in terms of quality attributes. We describe
KumbangSec, which in an approach for modelling functional and security variability applying different architectural viewpoints. KumbangSec builds on an existing variability modelling method, Kumbang, by extending it with
security engineering concepts. KumbangSec consists of a
conceptualisation and a language implementing the conceptualisation. The semantics for the conceptualisation has
been described using natural language; the syntax for the
language has been defined in a grammar. KumbangSec can
be supported with a configurator, which is an intelligent tool
supporting derivation of products that each satisfy specific
and different functional and security requirements. Such
a tool, KumbangSec configurator, is currently being developed.
1
Introduction
Quality attributes, such as performance, security and
availability, are important in many industrial software products. Quality attribute has been defined as a feature or characteristic that affects an item’s quality [16]. Many quality
attributes are architectural, meaning that the architecture of
the software is critical to their realisation, and these qualities should be designed in and evaluated at the architectural
level [4].
Today, many software product companies have to face
the diversity of customer needs. Instead of developing a
single product as a compromise of these needs, many companies offer several software products with slightly varying
capabilities. Variability is the ability of a system to be efficiently extended, changed, customised or configured for
use in a particular context [36]. Feature models [19] are one
of the first widely known approaches to express variability.
Recently, several other approaches to express variability by
modelling have emerged. Modelling methods such as orthogonal variability modelling [27] and COVAMOF [33]
augment other models of software to express variability.
These methods can be used at any level of modelling: at the
requirements, architecture or detailed design level. In contrast, Koala [37] and its derivate Koalish [2] are modelling
methods that contain specific constructs for variability and
address only architectural level modelling. Finally, despite
the lack of explicit constructs for variability, existing modelling methods such as UML are used to express variability
[11].
However, research on variability rarely addresses quality attributes. In particular, most variability modelling approaches do not have explicit constructs for quality attributes. Despite this, there are industrial cases in which
the products in a product family have different quality attribute requirements; such examples of varying qualities include security [10] and performance [25]. Thus quality attribute variability needs to be realised [12, 22, 26, 24]. Since
software architecture is critical to the realisation of many
quality attributes, modelling quality attribute variability is
relevant at the architectural level. Further, the fact that software architecture is a key asset in realising software product
family variability [6] stresses the importance of addressing
quality attribute variability at the architectural level.
In this paper, we describe KumbangSec, which is an approach for modelling functional and security variability in
software architectures. KumbangSec is built on the concepts of product configuration, software architectures, feature modelling, and security engineering. To address functional and security concerns, KumbangSec has been organised into four architectural viewpoints [15]: functional
view, component view, deployment view and security policy view.
KumbangSec approach consists of a conceptualisation
and a language. The language has been unambiguously
specified in such a way that KumbangSec models can be
configured with a configurator. A configurator is an intelligent tool that enables derivation of products satisfying specified functional and security requirements; such a configurator tool is currently being developed.
The rest of the paper is organised as follows. Firstly,
Section 2 outlines the background for KumbangSec. Thereafter, Section 3 introduces KumbangSec. Section 4 discusses the validity of KumbangSec. Finally, Section 5
draws conclusions and discusses future work.
2
Previous work
This section discusses the research on which KumbangSec is based.
2.1
Figure 1. ISO/IEC 15408 security concepts
[17]
Quality attributes in software architectures
According to [15], software architecture is the fundamental organisation of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.
State of the practice is to model and document software
architectures using different viewpoints and views as described in IEEE Standard [15]. A view is a representation
of a whole system from the perspective of a related set of
concerns. Example viewpoints include module view that
describes the decomposition of code units, and deployment
view that describes how software is allocated to physical
devices. Typically, certain viewpoints are used to answer
concerns related to certain quality attributes; e.g. process
view is often used when addressing performance concerns.
The goal of KumbangSec is to enable tool-supported
derivation of products that satisfy varying quality attribute
requirements. In order to target this goal, the approach
should include a mechanism for ensuring that quality attribute requirements are met. This can be done in two ways.
Firstly, the approach can apply well-known quality attribute
solutions, such as patterns [31] or tactics [4]. Secondly, the
approach can evaluate quality attributes from the architectural models.
When applications are built by reusing existing components, as is the case with configurable component-based
products, the task of evaluating quality attributes from the
architectural models can utilise information about the characteristics of components. The problem of predictable assembly [7] is as follows: given a set of components with
know property p, and the composition of these components,
how can system-wide property P be evaluated? Several approaches have been presented, e.g., for static memory consumption [9], performance [5], and reliability [28]. How-
ever, some quality attributes, such as security or safety,
are more difficult in the sense that their prediction requires
more information [21]. A prediction mechanism for security has also been proposed [30]. However, a problem with
security is that it is not trivial to come up with a quantitative,
composable metric that captures security concepts well.
2.2
Software security
According to ISO/IEC 9126 [18], security is the capability of the software to protect information and data so
that unauthorised persons or systems cannot read or modify them and authorised persons or systems are not denied
access to them. That is, security is a composite of confidentiality, integrity and availability [3]. Confidentially means
absence of unauthorised disclosure of information; integrity
means absence of unauthorised system alternations [3]; and
availability means readiness for correct service for authorised actions [3].
Figure 1 illustrates high-level security concepts of
ISO/IEC 15408 [17]. Security is concerned with the protection of assets from threats [17]; assets are defined to be
information or resources to be protected with countermeasures [17]. A threat exploits vulnerability in the software.
In order to reduce vulnerabilities, countermeasures are imposed in the software (see Figure 1).
The definition of ISO/IEC 9126 [18] makes a distinction
between authorised and unauthorised persons or systems;
these parties are termed as principals (e.g.[29, 20]). In order to specify authorisation, an access policy (also called
security policy) should be defined. In the security perpective tactics by Rozanki and Woods [29], access policy is
constructed by first identifying assets and principals, classifying them, and then mapping principal classes to asset
classes. Principals can also be software systems; in fact,
some studies on security of component-based software treat
components as principals (e.g.[20]).
As noted in ISO/IEC 9126 [18], security also applies to
data in transmission. In order to ensure that security policies are not violated when components transmit information
with each other, Herrmann [13] has proposed an approach
for analysing information flow in component-structured architectures by labeling pieces of information with access
policies. The idea is to prevent information from flowing to
unauthorised principals.
The concepts illustrated in Figure 1 are to some extent
reflected in the conceptual model of reference architectures
for software product lines with varying security requirements [10]. The model consists of three submodels [10].
Security submodel deals with risk assessment; core concepts include threat, asset, vulnerability, unwanted incident
and risk. An architecture submodel incorporates architectural solutions, that is, countermeasures that promise to address security requirements. A decision support submodel
supports security requirements through scenarios.
2.3
Kumbang
Variability has been studied in the domain of traditional
products, i.e. mechanical and electrical ones. This domain
of research is called product configuration, and it pertains
to modifying the general design of a product in prescribed
ways to produce product individuals that match the specific needs of customers [35]. The results include a number
of conceptualisations [34], languages and tools. Recently,
these same concepts have been applied to software products
[1] [14].
Kumbang [1] is a domain ontology for modelling the
variability in software product families. It includes concepts for modelling variability both from an architectural
and feature point of view. From architectural point of view,
Kumbang builds on Koala [37], which is an architecture description language developed and used in Philips.
More specifically, the modelling concepts include components and features with compositional structure, attributes, the interfaces of components and connections between these, and constraints. Hence, Kumbang enables
modelling variability in parallel from an architectural and
feature point of view as well as describing how features are
implemented by the architectural elements.
The semantics of Kumbang is rigorously described using
natural language and a UML profile. A language based on
the Kumbang ontology likewise called Kumbang has been
defined. Kumbang has been provided with formal semantics by defining and implementing a translation from Kumbang to WCRL (Weight Constraint Rule Language) [32],
a general-purpose knowledge representation language with
formal semantics.
Kumbang addresses only functional aspects of configurable software products. This means that using Kumbang,
it is possible to derive configurations in which the component architecture satisfies functional requirements, which
are specified through features. It is possible to model quality attribute variability with features [14]. However, Kumbang does not provide explicit constructs for modelling
quality attributes, which makes it more difficult to address
quality attribute variability.
3
KumbangSec
In this section, we describe KumbangSec that builds on
the concepts outlined in Section 2. KumbangSec is an approach that includes a conceptualisation and a language for
modelling component-based products that satisfy varying
functional and security requirements. The ultimate goal of
KumbangSec is to provide intelligent tool support for deriving these products from family models. Firstly, Section 3.1
gives an overview of the approach. Thereafter, Section 3.2
describes the conceptualisation KumbangSec is based on,
and how this conceptualisation makes a distinction between
instances and types. Finally, Section 3.3 describes the language that implements the conceptualisation.
3.1
Overview of KumbangSec approach
3.1.1
Basic ideas
KumbangSec is an approach for modelling componentbased architectures from functional, compositional and security point of view. KumbangSec builds on Kumbang language [1] by extending it with concepts from security engineering.
KumbangSec is organised to reflect the idea of separate
architectural viewpoints discussed in IEEE 1471-2000 standard [15]. The viewpoints in KumbangSec are feature viewpoint, component viewpoint, deployment viewpoint, and security policy viewpoint. Features mean user visible characteristics of a system. Components refer to the reused
software entities that are connected to form an application.
Deployment shows the software components operating on
physical devices and networks; this information is needed
in order to analyse security threats. Security policy specifies the threats and applied countermeasures; countermeasures are realised within the component architecture. The
viewpoints can be linked with constraints in such a way that
a change in one viewpoint is reflected to other viewpoints
as well.
The foundation of Kumbang, and therefore also of KumbangSec, lies on the dichotomy between types and instances, and between a configuration model and configuration, respectively. The situation is illustrated in Figure 2.
Figure 2. Metamodel of KumbangSec configuration models, configurations, types and instances.
A configuration describes one particular software product
variant, while a configuration model describes the rules and
the structure upon which valid configurations can be constructed. A configuration contains instances of types defined in the configuration model. Types in the configuration
model contain variability, while instances in the configuration do not; a configuration has been resolved from all
variability. This dichotomy is similar to development for
reuse and development with reuse; domain and application
engineering in family based development; and types and instances in object oriented programming.
A corollary of this position is that we need to capture a
configuration model only, since a configuration can be derived from the configuration model by selecting one variant
for each variation point. Therefore, KumbangSec provides
a language that can be used for describing configuration
models. An essential aspect of this language is that it can
be translated to a form that enables tool support for deriving
configurations from configuration models.
3.1.2
Security in KumbangSec
In order to address security, KumbangSec conceptualises
assets, principals, threats and countermeasures.
In component-based systems and component models, information is not usually explicitly modelled, but is encapsulated in the components and their connections. In order
to support explicit reasoning about security, KumbangSec
contains concepts for modelling assets. An asset in KumbangSec is information that needs to be protected. However,
only information that is relevant to security reasoning needs
to be modelled. Since the number of different assets can be
considerable, it is possible to classify assets that have similar security requirements into groups; such a group is called
an asset class.
Instead of considering stakeholders as principals, KumbangSec adopts the approach by Khan and Han [20] to treat
software components as principals. However, components
represent different stakeholders through their origin or role
in the system. In a similar fashion to assets, principals can
be classified into principal classes.
Typically, threats and countermeasures that are relevant
to an application are very much dependant on the domain
at hand. As a consequence, it is difficult to come up with
a fixed set of threats and countermeasures that are suitable
to all applications. Therefore, threats and countermeasures
can be specified in the configuration model to match security requirements at hand.
Threats and countermeasures are specified in a security
policy. One threat can be addressed by several countermeasures. A countermeasure represents a constraint that is implemented by the component and deployment architecture.
In order to achieve finer granularity, one countermeasure
can be selected individually for different elements; for example, it is possible to specify for each network which kind
of encryption to use.
To exemplify how threats and countermeasures can be
represented, we have modelled three threats to confidentiality and integrity, and corresponding countermeasures to
them. Firstly, information should not flow to unauthorised components; this threat is addressed by preventing
such connections between components. Secondly, malicious components may try to access or modify information
in the memory; this can be prevented by instantiating components into separate, restricted processes. Thirdly, connections that transmit assets over networks are vulnerable
to eavesdropping; this can be addressed by encrypting such
connections.
3.1.3
Variability in KumbangSec
As is illustrated in Figure 2, configuration models describe
the types from which instances in configurations are instantiated. Therefore, configuration models specify variability,
whereas all variability has been bound in configurations.
There are four kinds of variability in KumbangSec.
Firstly, functional variability is specified through features. This variability is achieved through subfeature structures, in which the number and types of subfeatures can
vary. Further variability can be achieved through attributes.
Secondly, security variability is specified through security policy. Threats cannot be varied, but for each threat, the
desired countermeasures (if any) can be varied.
Thirdly, architectural variability is specified through
component and interface structures. For each component,
the number and types of contained components can vary.
Further, interfaces can be optional, and interfaces can be
bound in different ways. Finally, variability can be achieved
by characterising components with attributes.
Finally, it is possible to vary deployment by varying the
number and types of devices that are deployed to networks.
For further discussion about variability in types, please
refer to Section 3.2.2.
Figure 4. An example how components are
deployed to devices and networks
tree; a configuration contains exactly one root feature. Further, features can be characterised with attributes: a feature
can be attached with an attribute that is a name/value pair.
Figure 3. KumbangSec instance metamodel
3.2
KumbangSec conceptualisation
The following describes the conceptualisation upon
which KumbangSec is based. We first describe the concepts that are reflected in the configuration, that is, KumbangSec instances. Thereafter, we discuss how KumbangSec types are used to characterise instances in the configuration model.
3.2.1
KumbangSec instances
A configuration in KumbangSec consists of instances that
are features, components, interfaces, bindings, assets, networks, devices, threats, and countermeasures. Figure 3
shows the metamodel of these instances. A configuration
provides a set of features, and adheres to a security policy.
Components provide or require interfaces that can be bound
together, and can form structures in terms of other components as parts. Components are deployed to devices, which
reside on networks. Components handle and store assets
and transfer them through interfaces.
Feature instances The basic representation of a functional requirement in KumbangSec configuration is a feature. Since the number of features in a typical application
can be considerable, features can be composed into hierarchies. Thus there can be is-subfeature-of relation between
two features in a configuration. Feature hierarchies form a
Component and interface instances The basic building
block of KumbangSec component architecture is a component. The components in KumbangSec configuration are
conceptually much akin to Koala components. However,
any component technology with similar concepts can be
used for implementing KumbangSec components.
A component can specify a number of interfaces, which
are sets of operation specifications. The interfaces that a
component specifies have a direction, i.e., interfaces are either provided or required. A provided interface offers its
operations for other components to use, while a required interface states that the component needs other components to
provide the operations. Interfaces can be bound with each
other according to the rules specified in [37].
Components can be organised into hierarchies. A component can contain other components; thus components are
in a compositional relation with each other, and this hierarchy forms a tree. Also, components may be characterised
with attributes. An attribute is a name/value pair that can be
used, e.g., for parameterisation of the component.
Device and network instances Software components in
the configuration may be deployed to separate physical devices; these devices are deployed in a network. Figure 4
illustrates an example situation of deployment. A network can contain several different devices, but devices cannot contain other devices. Networks can form hierarchies
through subnets similarly as, e.g., corporate intranet is a part
or subnet of Internet.
A configuration that has more than one device is distributed. A binding that crosses device borders is a distributed binding, which represents communication over network.
Asset, threat and countermeasure instances Assets are
attached to components in three different ways. Firstly, a
component may handle an asset, which means it stores it in
random access memory. Secondly, a component may also
store the asset in a permanent storage, for example to a file
on the disk. Thirdly, a component may transmit an asset to
another component via its interfaces.
Security policy specifies how threats are addressed with
countermeasures. Each configuration has one security policy, which lists a number of threats. For each threat, a number of countermeasures can be selected to address the threat.
In the most simple case, a countermeasure selection is either
applied or not applied; in the former case, the countermeasure is enforced in the architecture, while in the latter case
not. In general, a countermeasure can be characterised with
a selection, which acts as a parameter for implementing the
countermeasure in the architecture. For example, a countermeasure that encrypts communication may be attached with
a selection SSL 2.0, RSA 128 bit encryption, which specifies
the encryption protocol to use.
3.2.2
KumbangSec types
As is illustrated in Figure 2, types are the elements in the
configuration models, from which instances in the configurations are instantiated.
Figure 5 illustrates the metamodel of KumbangSec
types. All instances in Figure 3 have a respective type,
and vice versa. However, there are two exceptions to this
rule. Firstly, binding instances are defined solely upon their
connected interface instances, and thus they need no information from the types. Secondly, principal classes and asset classes do not have respective instances, since they are
already instantiated by component instances and asset instances, respectively.
A distinctive difference to the metamodel of instances
(Figure 3) is the use of definitions. A definition separates
typing from the structure, and acts as a point of variability. For example, a part definition specified by a component
type C states what kind of components a component instantiated from C can contain. As an example, a part definition
named database in component type Server may specify that
possible component types are Oracle and mySQL and that
cardinality is (0, 1). This means that a component instance
of type Server may contain zero or one Oracle or mySQL
component instances. Similar compositional structures can
be defined between features, or between networks and devices or devices and components.
Another example is the use of attribute definitions. Attribute value types specify the value range of attributes; for
example, attribute value type Boolean may specify value
range (yes, no). Attribute value types are attached to feature and component types through attribute definitions; for
Figure 5. KumbangSec type metamodel
example, feature type Map may define an attribute definition zoomable of type Boolean.
To summarise, variability may occur in the compositional structure of networks, features, and components; in
attributes; and in what interfaces components contain and
which bindings between interfaces exist. The variability in
compositional structures is specified using part definitions:
the number and type of parts an entity has may vary. Features and components can be parameterised using attributes.
Similarly, interfaces may be defined optional and be of different types. Finally, security policies can vary how countermeasures are applied.
3.3
KumbangSec language
In order to use KumbangSec concepts for modelling
product families, a language that captures the conceptualisation described in Section 3.2 has been developed. The
language has been constructed in such a way that it enables
development of tool support. Since KumbangSec configurations are derived from KumbangSec configuration models (Figure 2), only a language for specifying configuration
models is required. The language represents KumbangSec
types (see metamodel in Figure 5).
KumbangSec language is specified using XML. KumbangSec grammar has been described as an XML schema,
whereas the configuration models are XML instance documents from the schema. XML was chosen due to its widespread use; for example, a number of parsers and editors are
available for XML.
The XML schema that represents KumbangSec grammar has been specified. Each definition and each type in
KumbangSec type metamodel (Figure 5) has its own XML
schema data type in the grammar.
For example, the XML schema definition for ComponentType is illustrated in Figure 6(a). This snippet states
that each component type has a name, a principal class, defines any number of interfaces, any number of component
parts, any number of attributes and any number of assets.
Finally, a component type can specify constraints on its elements.
An example of the corresponding component type specification is shown in Figure 6(b). It specifies a component
type named ServerMain that belongs to principal class InHouse. Further, the component type contains two interfaces, named TransmitInterface and StorageInterface, and
specifies that is handles an asset nodeLocation belonging
to asset class Location. A component instance instantiated
from type ServerMain is visualised in the lower part of Figure 7.
In order to give formal semantics to KumbangSec, KumbangSec has been provided with a translation to WCRL
(Weight Constraint Rule Language) [32]. WCRL is a form
of logic programming, using which one can specify a set
of atoms, statements concerning atoms and rules that extend these statements [32]. Further, this translation makes it
possible to utilise smodels [32] inference engine to automatically verify whether the configuration matches the rules of
the configuration model.
The translation to WCRL utilises the fact a translation
from Kumbang to WCRL has already been defined [1].
Therefore, KumbangSec is provided with the translation by
first translating KumbangSec to Kumbang, and then using
the existing translation to WCRL. The translation between
KumbangSec and Kumbang treats assets, devices and networks as special kind of components, and policies as special
kind of features.
Figure 6(c) illustrates part of the WCRL that has been
translated from the component specification in Figure 6(b).
The first line specifies that component of type ServerMain
is an InHouse component. The second and the third line
specify the two interfaces this component has. The fourth
line specifies that this component defines an asset named
nodeLocation.
4
Evaluation
In this section, the validity of KumbangSec is evaluated from the following viewpoints. How well does KumbangSec address the problem; are the conceptualisation and
language sound; and can KumbangSec be applied in practice, integrated with component implementation technologies and supported with tools?
Addressing the problem. The aim of KumbangSec is to
study how security variability and functional variability can
be modelled from architecture point of view. To target this
aim, several existing approaches are integrated into one.
The novelty of KumbangSec is combining existing concepts to model variability, while the concepts themselves
are based on existing studies. Therefore, the soundness of
KumbangSec concepts can be argued from these existing
studies.
For functional and architectural variability, KumbangSec
is based on Kumbang, which in turn is based on feature modelling, Koala, and traditional product configuration
concepts. For security variability, KumbangSec extends
Kumbang with established security concepts that underlie
many studies, including ISO/IEC standard 15408 [17] and
security model presented in [10].
However, it is yet unknown how well this combination of
concepts addresses the problem. For example, it is unknown
whether explicit concepts for risks or vulnerabilities should
be included, or how well the conceptualisation supports definition of different kinds of threats and countermeasures.
Figure 6. Example translations from a weather station network configuration model. (a) A snippet
from the XML schema that defines how component types are specified. (b) An example component
type specification in a configuration model. (c) Few lines of the WCRL that is produced from the
component type specification.
Figure 7. A screenshot of KumbangSec configurator under development (some inconsistencies with
current conceptualisation may occur)
Soundness of conceptualisation and language. To address the problem of modelling functional and security variability, KumbangSec conceptualisation has been defined.
The concepts and their relations have been specified using
natural language and metamodels. Further, the separation
between instances and types has been specified.
To implement the conceptualisation, KumbangSec language has been defined. The semantics of KumbangSec
language follows the semantics of KumbangSec conceptualisation. The syntax of the language has been described using an XML schema, which validates that the language can
be captured with a grammar. Moreover, using the grammar,
it has been possible to parse XML instance documents that
represent KumbangSec configuration models.
Further, KumbangSec has been given a semantics by
providing a translation to WCRL. This validates that the approach can be subjected to automated reasoning.
Practical feasibility. KumbangSec has been used to
model two small configurable products. Firstly, we have
modelled a weather station network that is loosely based on
a real software product family. Secondly, we are currently
modelling a map viewer application for Nokia 770 Internet Tablet. This application is currently being developed to
demonstrate the approach.
Hence, it has been shown that it is possible to model
products using KumbangSec. However, the limitation to
this validity is that no industrial products have been modelled. Further, there is no general knowledge on how easily
KumbangSec constructs can be used for capturing product
characteristics. Further studies on KumbangSec applicability are therefore required.
Integration with component implementation technology. The scope of KumbangSec is high-level variability
modelling. That is, KumbangSec is not limited to any particular component implementation technology, but it can be
integrated with any approach that is compatible with the
conceptualisation, and is able to enforce the specified countermeasures.
At the moment, we are integrating KumbangSec with
a component technology developed within the research
project.
Tool support. Finally, the validity of the approach can
be demonstrated by building a configurator tool to support
derivation of products based on KumbangSec configuration
models. We are currently developing KumbangSec configurator by extending previously developed Kumbang configurator [23]. The configurator utilises smodels [32] inference
engine for implementing the configuration reasoning in an
efficient manner. Further, it is being developed in Java programming language on top of Eclipse platform [8].
A preliminary screenshot of KumbangSec configurator is
illustrated in Figure 7. The current results seem to indicate
the feasibility of constructing such a configurator.
5
Conclusions
We have presented KumbangSec, which is an approach
for modelling functional and security variability in software
architectures. To address functional and security concerns,
KumbangSec has been organised into functional view, component view, deployment view and security policy view.
KumbangSec approach consists of a conceptualisation and
a language. They have been constructed in such a way that
they can be supported with a configurator, which is an intelligent tool that enables derivation of products satisfying
specified functional and security requirements.
However, the work is still in progress. We are working
on developing a configurator tool that supports derivation
by extending existing Kumbang configurator. Further, we
are validating the approach by modelling product families
or configurable products with KumbangSec language.
There are several directions to which this approach can
be extended.
Firstly, KumbangSec assets are considered to be information. However, it is possible that also resources or operations could be treated as assets that need protection. We
seek to extend the concept of asset to cover also these, e.g.,
by classifying interfaces in components according to asset
classes.
Secondly, more threats and countermeasures should be
modelled to study how the conceptualisation can be used to
capture different kinds of security characteristics.
Finally, different aspects of quality may require different concepts and viewpoints. It has proven to be laborous
to extend existing languages with new concepts in such a
way that existing tools can be reused efficiently. Therefore, we are currently working on a meta-language, using
which concrete languages can be specified; corresponding
configurator tool implementation can be generated from the
specification.
Acknowlegments
This research is being carried out in participation of
Nokia within Trust4All ITEA project. The authors acknowledge Nokia and all other participants of Trust4All
project who have provided feedback and comments on this
work.
References
[1] T. Asikainen, T. M¨annist¨o, and T. Soininen. Kumbang: A
domain ontology for modelling variability in software prod-
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
uct families. Advanced engineering informatics journal, Accepted, 2007.
T. Asikainen, T. Soininen, and T. M¨annist¨o. A Koala-based
approach for modelling and deploying configurable software
product families. In Proc. of Workshop on Product Family
Engineering, 2003.
A. Avizienis, J.-C. Laprie, B. Randell, and C. Landwehr. Basic concepts and taxonomy of dependable and secure computing. IEEE Transactions on Dependable and Secure Computing, 1(1), 2004.
L. Bass, P. Clements, and R. Kazman. Software Architecture
in Practice. Addison-Wesley, 2nd edition, 2003.
E. Bondarev, M. R. V. Chaudron, and P. H. N. de With. A
process for resolving performance trade-offs in componentbased architectures. In Proceedings of International Symposium on Component-Based Software Engineering, 2006.
P. Clements and L. Northrop. Software Product Lines—
Practices and Patterns. Addison-Wesley, 2001.
I. Crnkovic, H. Schmidt, J. Stafford, and K. Wallnau.
Anatomy of a reseach project in predictable assembly. In
Proc. of 5th Workshop on Component-Based Software Engineering, 2002.
Eclipse, http://www.eclipse.org/.
E. Eskenazi, A. Fioukov, D. Hammer, and M. Chaudron.
Estimation of static memory consumption for systems built
from source code components. In Proceedings of the
9th IEEE Conference and Workshops on Engineering of
Computer-Based Systems, 2002.
T. E. Fægri and S. Hallsteinsen. A software product line
reference architecture for security. In T. K¨ak¨ol¨a and J. C.
Due˜nas, editors, Software Product Lines—Research Issues
in Engineering and Management. Springer, 2006.
H. Gomaa. Designing Software Product Lines with UML:
From Use Cases to Pattern-Based Software Architectures.
Addison-Wesley, 2004.
S. Hallsteinsen, T. E. Fægri, and M. Syrstad. Patterns in
product family architecture design. In Proc. of Workshop on
Product Family Engineering, 2003.
P. Herrmann. Information flow analysis of componentstructured applications. In Proceedings 17th Annual Computer Security Applications Conference (ACSAC 2001),
2001.
L. Hotz, K. Wolter, T. Krebs, J. Nijhuis, S. Deelstra, M. Sinnema, and J. MacGregor. Configuration in Industrial Product Families—The ConIPF Methodology. IOS Press, 2006.
IEEE Std 1471-2000. IEEE recommended practice for architectural description of software-intensive systems, 2000.
IEEE Std 610.12-1990. IEEE standard glossary of software
engineering terminology, 1990.
ISO/IEC 15408-1.
Information technology—security
techniques—evaluation criteria for IT security—part 1: Introduction and general model, 1999.
ISO/IEC 9126-1. Software engineering—product quality—
part 1: Quality model, 2001.
K. Kang, S. Cohen, J. Hess, W. Novak, and A. Peterson.
Feature-oriented domain analysis (FODA) feasibility study.
Technical Report CMU/SEI-90-TR-21, ADA 235785, Software Engineering Institute, 1990.
[20] K. Khan and J. Han. Composing security-aware software.
IEEE Software, 19(1):34–41, 2002.
[21] M. Larsson. Predicting Quality Attributes in Componentbased Software Systems. PhD thesis, M¨alardalen University,
2004.
[22] M. Matinlassi. Quality-driven software architecture model
transformation. In Proc. of Working IEEE/IFIP Conference
on Software Architecture, 2005.
[23] V. Myll¨arniemi, T. Asikainen, T. M¨annist¨o, and T. Soininen. Kumbang configurator—a configuration tool for software product families. In IJCAI-05 Workshop on Configuration, 2005.
[24] V. Myll¨arniemi, T. M¨annist¨o, and M. Raatikainen. Quality
attribute variability within a software product family architecture. In Short paper in Conference on the Quality of Software Architectures (QoSA), 2006.
[25] V. Myll¨arniemi, M. Raatikainen, and T. M¨annist¨o. Interorganisational approach in rapid software product family
development—a case study. In Proc. of International Conference on Software Reuse (ICSR), 2006.
[26] V. Olumofin, F.G.; Misic. Extending the ATAM architecture
evaluation to product line architectures. In Proc. of Working
IEEE/IFIP Conference on Software Architecture, 2005.
[27] K. Pohl, G. B¨ockle, and F. van der Linden. Software Product
Line Engineering. Springer, 2005.
[28] R. Reussner, H. Schmidt, and I. Poernomo. Reliability prediction for component-based software architectures. Journal
of Systems and Software, 66(3), 2003.
[29] N. Rozanski and E. Woods. Software Systems Architecture.
Addison-Wesley, 2005.
[30] V. S. Sharma and K. S. Trivedi. Architecture based analysis
of performance, reliability and security of software systems.
In Proceedings of the 5th International Workshop on Software and Performance, 2005.
[31] M. Shaw and D. Garlan. Software Architecture–Perspectives
on an Emerging Discipline, chapter 2. Prentice Hall, 1996.
[32] P. Simons, I. Niemel¨a, and T. Soininen. Extending and implementing the stable model semantics. Artificial Intelligence, 138(1–2), 2002.
[33] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A framework for modeling variability in software
product families. In Proc. of Software Product Line Conference (SPLC 2004), 2004.
[34] T. Soininen, J. Tiihonen, T. M¨annist¨o, and R. Sulonen. Towards a general ontology of configuration. AI EDAM (Artificial Intelligence for Engineering Design, Analysis and Manufacturing), 12(4):357–372, 1998.
[35] T. Soininen, J. Tiihonen, T. M¨annist¨o, and R. Sulonen. Special issue: Configuration (guest editorial introduction. AI
EDAM (Artificial Intelligence for Engineering Design, Analysis and Manufacturing), 17(1–2), 2002.
[36] M. Svahnberg, J. van Gurp, and J. Bosch. A taxononomy of
variability realization techniques. Software—Practice and
Experience, 35(8), 2005.
[37] R. van Ommering, F. van der Linden, J. Kramer, and
J. Magee. The Koala component model for consumer electronics software. IEEE Computer, 33(3):78–85, 2000.