Using Aspect-Oriented Approach for Software Product Line

Development

Lei Tan and Yuqing Lin

School of Electrical Engineering and Computer Science, University of Newcastle, Callaghan, NSW, Australia

Keywords:

Software Quality, Software Product Line, Aspect-Oriented, Crosscutting Concern.

Abstract:

Software Product Line Engineering (SPLE) is a software development paradigm to improve systematic soft-

ware reuse. SPLE is intended to develop a set of similar software systems which share great commonalities

within a particular application domain. There are two key assets underpin Software Product Line (SPL) devel-

opment: feature model and reference architecture. To deal with complex crosscutting behaviors in SPL and

also manage the impact of Non-Functional Requirements (NFRs), we propose an aspect-oriented framework

in this paper. The proposed framework is able to improve the modeling of interrelationships between design

factors and representation of the variabilities in product families. We introduce a small case study to illustrate

our approach at the end.

1 INTRODUCTION

In software engineering, reusing software and its

components becomes a practical solution towards

cost-effective and quality-oriented software develop-

ment. Software Product Line Engineering (SPLE)

(Bosch, 2000) is one of software engineering ap-

proaches that focuses on providing systematic soft-

ware reuse on software families, where a product fam-

ily is a collection of software systems that share great

commonalities in a particular application domain.

Different from other software reuse techniques,

SPLE keeps design with reuse in mind. All assets

developed will be reused to produce member prod-

ucts based on different requirements. So SPLE con-

tains various reusable assets and artifacts, such as sys-

tem requirements, source code, architecture and docu-

mentation. When developinga member productof the

family, these reusable artifacts will be reﬁned, modi-

ﬁed and conﬁgured. SPLE saves the efforts of de-

veloping every single software system from scratch.

SPLE also provides systematic mapping and trace-

ability to ensure that requirements will be realized by

ﬁnal products. Once the reusable artifacts are deﬁned

and successfully implemented, the individual member

products can be produced through a very organised

customization.

The remainder of the paper is organised as fol-

lows. In section 2, we will introduce background of

SPLE and some open problems. In section 3, we pro-

pose a comprehensive framework that dealing with

these problems by using aspect-oriented techniques.

In sections 4, we present a case study to demonstrate

how we develop the framework and achieve aspect

identiﬁcations and mappings. Section 5 concludes the

paper and discusses future works.

2 BACKGROUND

2.1 Software Product Line Engineering

(SPLE)

SPLE consists of two processes, domain engineering

and application engineering. The tasks of establish-

ing a Software Product Line (SPL) belong to domain

engineering and the processes developing a particular

member product from an SPL are included in appli-

cation engineering. For SPLE, it is very important to

understand where the variations are among the mem-

ber products, and also potential changes to a prod-

uct family in the future. This information should be

well represented and managed to provide the speciﬁc

scope of a domain-based product family.

In domain engineering, there are two key reusable

artifacts: feature model and reference architecture.

These two artifacts are signiﬁcant in SPL as they are

the basis for SPL establishment and products deriva-

tion.

387

Tan L. and Lin Y..

Using Aspect-Oriented Approach for Software Product Line Development.

DOI: 10.5220/0005554203870392

In Proceedings of the 10th International Conference on Software Engineering and Applications (ICSOFT-EA-2015), pages 387-392

ISBN: 978-989-758-114-4

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

2.1.1 Feature Model

A feature model represents all the possible member

products of an SPL in terms of features and the rela-

tionships among features. In a feature model, features

are prominent and distinctive system requirements or

characteristics in an SPL (Lee et al., 2002). Features

are not existing independently, there are different re-

lationships between features. For example, “requires”

and “excludes” are two kinds of common feature rela-

tionships. Feature model is used to conﬁgure member

products by selecting desired features based on cus-

tomers’ requirements and feature relationships.

2.1.2 Reference Architecture

Another important artifact derived based on feature

modeling is called reference architecture. A refer-

ence architecture (Eixelsberger et al., 1998) is a soft-

ware architecture that provides the common struc-

tures, components and their relationships to the ex-

isting systems in a particular domain or an SPL. In

SPL, a reference architecture describes the structures

and respective elements and relations for the whole

product family, i.e. for multiple products in the prod-

uct line. So it stresses the commonalities of the ar-

chitecture and also describes the planned variabilities.

An important character of the reference architecture is

that it is conﬁgurable. Based on the requirements on

the product, the reference architecture provides tem-

plates for developing concrete architectures for the

members in the product line.

2.1.3 Open Problems

Some open problems of current SPLE have been iden-

tiﬁed in both feature modeling and reference architec-

ture development.

• Some Complex Feature Relationships Are

Hard to Manage. One-to-one relationships are

modeled effectively in feature model. The more

complex feature relationships are hard to han-

dle by current approaches. For example, vari-

ous feature groups, which represent different lev-

els of product quality, are hardly modeled by “re-

quires” and “excludes” relationships. As a result,

feature selections in conﬁguration become error-

prone and the quality of conﬁgured product is

barely preserved.

• Quality Attributes Are Not Modeled System-

atically in Feature Model. Feature model is

produced from requirement engineering based on

requirements documents from the software fam-

ily. However, the relationships between quality

attributes and features are not modeled in a sys-

tematic way. The impact of quality attributes on

features should be identiﬁed to demonstrate the

transformation from NFRs to quality attributes

and how NFRs are achieved by ﬁnal products.

• Transformation from Feature Model to Refer-

ence Architecture Is Not Straightforward. Fea-

ture model is a foundation for reference architec-

ture development. However, in most of current

approaches, the mechanisms of systematic fea-

ture mappings to components are not clearly es-

tablished. This information should be represented

explicitly to enhance SPLE in terms of efﬁcient

product derivation.

• Variability Representation Is Not Adequate. A

well-deﬁned variability representation is needed

in both feature model and reference architecture,

as it is critical to product development. All the de-

sired features for products and the possible varia-

tions to reference architecture should be described

in an easy understandable way. Furthermore, the

impact of NFRs on feature selections and archi-

tecture should also be explicitly represented to fa-

cilitate product derivation.

Aspect-oriented approaches have the ability to

model the crosscutting relationships among multiple

features and components. This is an ideal solution to

address mentioned problems in SPLE.

2.2 Aspect-Oriented Software

Development (AOSD)

Aspect-Oriented Software Development (AOSD)

(Brichau et al., 2008) is to modularize crosscutting

concerns in order to provide advanced implementa-

tion structures. In software development, crosscut-

ting concerns are those broadly-scoped features or

properties that often crosscut several other modules in

software systems. By representing crosscutting con-

cerns (or aspects) as ﬁrst-class abstractions, Aspect-

Oriented (AO) approaches are able to address mod-

ularity problems that are not well handled by other

approaches.

For example, products in an SPL might have dif-

ferent levels of security and performance, i.e. differ-

ent NFRs, which normally have impact on multiple

features and the way the features are implemented.

So, the impact of NFRs on features should be man-

aged to improve SPLE. As the nature of AOSD is to

modularize aspects and provide better representations

of complex relationships, it is appropriateto adapt this

idea to deal with existing messy relationships between

features and NFRs. Aspect-oriented modeling ap-

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

388

proach will further facilitate mappings from require-

ment level to architecture level.

Currently, there are some AO methods focusing

on feature modeling and architecture development

in SPL. For example, the framework (Conejero and

Hernandez, 2008) proposed is to identify crosscut-

ting features at early stages to reduce the difﬁculty of

products evolution and derivation in the latter stages.

This framework is based on a crosscutting pattern and

uses traceability matrices to perform the analysis of

crosscutting. To identify crosscutting features, the

crosscutting features analysis need to be conducted

and both common and variable assets of product lines

need to be acquired. In this approach, NFRs are able

to be inserted into a crosscutting matrix. However,

the focus of this approach remains on early aspect of

requirement level and it does not specify how to use

these information for implementation.

Aspect-Oriented Generative Approach (AOGA)

(Kulesza et al., 2004) is an architecture-centric ap-

proach that has been implemented to support con-

cern modularization. The main consideration of

the approach is to improve the domain modeling

and architecture speciﬁcation of crosscutting features

from early development phases. In the problem

space, feature model is extended and described by a

new domain speciﬁc language to collect both non-

crosscutting and crosscutting features. In the solu-

tion space, software architecture is designed by us-

ing aspect-oriented abstractions to model features and

using programming languages to implement compo-

nents of the architecture. However, this approach is

speciﬁcally dealing with multi-agent systems and the

capacity of the approach is limited.

3 PROPOSED FRAMEWORK

We propose an AO-based framework to better model

crosscutting features and NFRs in domain engineer-

ing. Compare to other AO approaches, our framework

contains a particular signiﬁcance. Our approach starts

from feature model at requirement level and provides

traceability to NFRs and crosscutting concerns. It

speciﬁes the impact of NFRs onto systems and mem-

ber products, so quality of member products is better

modeled. We also expect to have appropriate mecha-

nisms to achieve systematic mapping and transforma-

tion from requirements to architectures.

The proposed framework is composed into two

parts: AO feature model and AO reference archi-

tecture development. The main expectation of AO

feature modeling is to convert conventional feature

model into four elements, i.e. NFRs, concrete fea-

tures, aspectual features and aspectual concerns. We

also expect to deﬁne impact of aspectual concerns on

both concrete and aspectual features. The goal of

AO reference architecture is to specify the mappings

from AO feature model onto reference architecture.

The crosscutting concerns at architecture level will be

identiﬁed and the impact on the reference architecture

will be presented.

3.1 Aspect-Oriented Feature Model

To develop AO feature modeling, we ﬁrst model

NFRs and quality attributes, and specify the relation-

ships between features and related quality attributes

by using NFR Framework (Chung et al., 1999). Then

we moves to functional requirement modeling by us-

ing use case diagrams and activity diagrams. In our

approach, we extent conventional use case and de-

compose it into business ﬂows and sub-processes. We

are interested in systems’ internal processes and re-

sponsibilities. To apply use case models in product

line, the branch lines that under different conditions

should be considered and investigated. If a particular

system behavior existing in multi-business processes

interacts with many other user visible functionalities

of the system, this would be a candidate of aspectual

feature.

To better understand AO feature model, we divide

features into several categories as following:

• Concrete Feature. Concrete feature repre-

sents concrete functionalities of a product family.

These features represent the fundamental services

the systems provide. In AO context, these features

are crosscut by concerns.

• Aspectual Feature. Aspectual features also rep-

resent the functionalityof a productline, and these

features have various relationships and crosscut

other features.

• Aspectual Concerns. Aspectual concerns are

the key requirements and system considerations

crosscutting the concrete features and aspectual

features. The aspectual concerns map the NFRs

and requirements on qualities to the features in the

feature model. The concerns describe the impact

of NFRs and quality requirements on the system

composition and the way features interact to each

other.

According to these feature categories, the tasks of

AO feature modeling include developing related mod-

els to treat crosscutting features (functional) and con-

cerns (non-functional) in a systematic way. The steps

are roughly described as follows:

UsingAspect-OrientedApproachforSoftwareProductLineDevelopment

389

• The ﬁrst step is to model concrete features, which

is relatively easy as concrete features correspond

to the user visible functionalities of the system.

Current use case modeling and scenarios based

approaches are able to address the functional re-

quirements of the software systems. The output

of this step is a model which is able to clearly

represent the concrete features and relationships

between these concrete features.

• The second step is to identify and modularize as-

pectual concerns, which is one of the major con-

tributions of our framework. Aspectual concerns

could be identiﬁed in NFR modeling process in

order to describe the impact of NFRs onto the

functional features. In the framework, the contri-

butionof each concrete feature to satisfy the NFRs

will be examined so that the related quality levels

can be speciﬁed by these options.

• The last step of AO feature modeling is to identify

aspectual features and map aspectual concerns to

concrete features and aspectual features. An as-

pectual feature is a feature that crosscutting other

concrete features, i.e. impact the behaviors of

other features. They are additional responsibili-

ties that do not affect the main business ﬂow.

By the end, we will convert feature model into

quality attributes and other three components, i.e.

concrete features, aspectual features and aspectual

concerns. The impact of aspectual concerns on both

types of features will be identiﬁed as well. Moreover,

the complex feature relationships will be decomposed

into relationships among these three components and

NFRs.

3.2 Aspect-Oriented Reference

Architecture

Aspect-oriented reference architecture framework is

to specify how features and aspectual concerns from

AO feature modeling are mapped onto reference ar-

chitecture. The key point is to identify crosscutting

concerns caused at architecture level and how refer-

ence architecture is affected and composed.

• The ﬁrst task is to model functional requirements

by developing components and subsystems to im-

plement concrete features. Conventional SPL

approaches can be used to transform concrete

features into components or subsystems to meet

functional requirements. The output of this task

will be components and connectors to link these

components.

• The next step is to develop a set of architecture

scenarios (Rommes and America, 2006) to de-

scribe systems. From use case and business pro-

cesses identiﬁed, we are able to work out a set

of scenarios describing the internal behaviors of

systems. Since the requirements are from multi-

ple products, it is common that we have multiple

alternative ﬂows, which suggest alternative inter-

nal workﬂow of the system and will be mapped to

parallel scenarios.

• The following step is to identify variabilities of

components and possibly pointcut on the archi-

tecture components. Components of architectural

model from the ﬁrst step are involved, so it is

possible to specify the responsibilities of these

components and their interactions. Here we need

to examine how the aspectual concerns are ad-

dressed in the architecture. These aspectual con-

cerns suggest how the components interact and

possibly ways the component crosscutting each

other for satisfying functional and non-functional

requirements at different levels.

• The ﬁnal step is to assess scenario interactions

to reﬁne possible bigger scope crosscutting con-

cerns. Scenarios could be combined together to

implement more complex functionalities, so ex-

amining the interactions between scenarios could

address some complex aspectual concerns. Af-

ter this step, all the identiﬁed concerns should be

properly address in the reference architecture in

terms of components crosscutting relationships.

4 CASE STUDY

In this section, we will present a small case study

to illustrate how to identify aspects from requirement

level and map them to architecture level in our frame-

work. The case study used is a crisis management

system product line (Kienzle et al., 2010). To better

demonstrate our approach, we also did some adapta-

tions to ﬁt this case into our framework, e.g. adding

some features, expanding use case mapping diagrams,

developing alternative ﬂows of some use cases, etc.

First, we will identify all the features of the sys-

tem, which includes concert feature and aspect fea-

tures. Table 1 below shows a list of features with their

responsibilities. By relating these features to use case

mappings, some features exist in multiple business

ﬂows. These features should be considered as can-

didates of aspectual features in this step. Fig. 1 shows

a trivial part of use case mapping. As mentioned, we

decompose use case into business ﬂows and observe

systems’ internal processes and behaviors. Fig. 1

shows a business ﬂow of “Capture a Crisis Report”.

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

390

Figure 1: “rerankingCrisisPriority” in use case mapping.

From the ﬁgure, we can see that “rerankingCrisisPri-

ority” (marked as ♦), which is a functional behavior

of the system, exists in multiple parts of use case pro-

cesses. This functional behavior has interactions with

multiple system functions, so the corresponding fea-

ture could be looked as a potential candidate of aspec-

tual feature.

Table 1: Features and responsibilities.

Features Responsibility

Crisis receive

when system receives a new crisis report, this

information will be sent to center management

Position detection

to conﬁrm a crisis report, the location

has to be identiﬁed by various approaches

Communication

which provides support for communication and

information transmission among all resources

Task assignment

system assigns rescue tasks to mobile units

according to current resources and crisis priorities

rerankingCrisisPriority

once a crisis been received or a rescue task

been completed, system will automatically re-rank

the rest crisis based on their critical levels

The next step is to identify aspectual concerns. To

identify aspectual concerns in AO feature model, we

need to ﬁnd out the related quality attributes and how

they are decomposed into concerns. In this case, we

know that several quality attributes, such as “Perfor-

mance”, “Security” and “Mobility”, are affected by

multiple features (concrete and aspectual). These fea-

tures are crosscut by quality attributes in terms of var-

ious aspectual concerns. Table 2 lists the crosscutting

relationships between aspectual concerns and related

quality attributes by “X”.

Note that these aspectual concerns are not func-

tional requirements, they represent system’s non-

functional properties. For example, “Constant cache

management” is an identiﬁed aspectual concern that

has impact on systems’ “Performance” and “Secu-

Table 2: Aspectual concerns and related quality attributes.

Aspectual Concerns Performance Security Mobility

Constant cache management X X

Instant message exchange X X

Fast logging veriﬁcation X X

rity”. This concern could contain various represen-

tations to meet particular levels of related quality at-

tributes. For a high level of system security, “Con-

stant cache management” could be achieved by en-

crypted data storage in cache that only can be ac-

cessed through appropriate authorization. For a sys-

tem with low security requirement, this concern could

be achieved by a direct-mapped cache. However it is

able to enhance systems’ performance in term of fast

memory transmission.

To identify aspectual features, only candidates

that contribute to achievement of aspectual concerns

should be considered as aspectual features. For exam-

ple, for features in Table 1, “rerankingCrisisPriority”

is considered as an aspectual feature as it contributes

to aspectual concerns such as “Constant cache man-

agement” and “Instant message exchange”. “Com-

munication” does not contribute to any of identiﬁed

aspectual concern, so it is considered as a concrete

feature although it exists in multiple business ﬂows

and crosscut other features in different system pro-

cesses.

To dig further, the crosscutting relationships be-

tween aspectual concerns and features also need to be

addressed. Table 3 below represents these relation-

ships. For example, for the feature of “Task assign-

ment”, it is affected by “Instant message exchange”

for system to explore and examine current crisis situ-

ations and available resources to arrange rescue tasks.

Similarly, related users need log into system to check

UsingAspect-OrientedApproachforSoftwareProductLineDevelopment

391

and receive rescue orders, so system has to provide

fast and secure logging through “Fast logging veriﬁ-

cation”.

Table 3: Relationships between concerns and features.

Features

Constant cache Instant message Fast logging

management exchange veriﬁcation

Crisis receive X X

Position detection X X

Task assignment X X

rerankingCrisisPriority X X

Down to architectural level, we develop a set of

architecture scenarios to describe system architecture,

which includes branching lines and alternative ﬂows

to address architectural variabilities. Fig. 2 shows a

partial example of architecture. Here we have adapted

the representation of AOGA (Kulesza et al., 2004)

to represent aspectual components and aspectual in-

terfaces. In the ﬁgure, identiﬁed aspectual feature

“rerankingCrisisPriority” is mapped as a component

called “reranking” on architecture and variable design

options are achieved by aspect crosscutting in differ-

ent ways. For example, “reranking” crosscuts com-

ponents “Report” and “Task management” through

interface “data transferring” to transmit data for sys-

tems’ report generation and live task management. It

also crosscuts “Communication” and “Execute mis-

sion” through “information collecting” to provide se-

cure/instant communication and information update

among available resources.

Figure 2: “reranking” crosscuts other components.

5 CONCLUSION AND FUTURE

WORKS

In this paper, we introduce Software Product Line En-

gineering (SPLE) and discuss existing problems. To

deal with these issues, we propose a new comprehen-

sive framework by using aspect-oriented techniques

and approaches to simplify complex features relation-

ships and NFRs impacts. Our approach starts from

feature modeling and provides mappings onto archi-

tecture development. The advantageof the framework

is that it enhances the modularity of system as an AO

approach. The transformation between requirement

and architecture is more efﬁcient. The software ar-

chitecture development will be more accurate because

NFRs and qualities are treated as part of architectural

elements.

For the future work, we need further investigate

how to enhance the systematic mappings from re-

quirement to architecture. We have developed a City

Evolution product line and we would like to apply the

framework on this real-case to evaluate our approach.

REFERENCES

Bosch, J. (2000). Design and Use of Software Architec-

tures: Adopting and Evolving a Product-Line Ap-

proach. Addison-Wesley.

Brichau, J., Chitchyan, R., Rashid, A., and D’Hondt, T.

(2008). Aspect-oriented software development: An

introduction. Wiley Encyclopedia of Computer Sci-

ence and Engineering.

Chung, L., Nixon, B. A., Yu, E., and Mylopoulos, J. (1999).

Non-Functional Requirements in Software Engineer-

ing. Kluwer Academic Publishers, Boston.

Conejero, J. M. and Hernandez, J. (2008). Analysis of

crosscutting features in software product lines. In Pro-

ceedings of the 13th International Workshop on Early

Aspects, pages 3–10.

Eixelsberger, W., Ogris, M., Gall, H., and Bellay, B. (1998).

Software architecture recovery of a program family. In

Proceedings of the 20th International Conference on

Software Engineering, pages 508–511.

Kienzle, J., Guelﬁ, N., and Mustaﬁz, S. (2010). Crisis man-

agement systems: A case study for aspect-oriented

modeling. Transactions on Aspect-Oriented Software

Development, pages 1–22.

Kulesza, U., Garcia, A., and Lucena, C. (2004). Generating

aspect-oriented agent architectures. In Proceedings

of Early Aspects AspectOriented Requirements Engi-

neering and Architecture Design.

Lee, K., Kang, K., and Lee, J. (2002). Concepts and guide-

lines of feature modeling for product line software

engineering. In Proceedings of the 7th International

Conference on Software Reuse: Methods, Techniques,

and Tools, pages 62–77.

Rommes, E. and America, P. (2006). A scenario-based

method for software product line architecting. In Soft-

ware Product Lines, pages 3–52. Springer Berlin Hei-

delberg.

ICSOFT-EA2015-10thInternationalConferenceonSoftwareEngineeringandApplications

392