An Aspect-Oriented Approach for Dealing with Non-Functional Requirements

in a Model-Driven Development of Distributed Embedded Real-Time Systems

Marco A. Wehrmeister1, Edison P. Freitas1, Carlos E. Pereira1,2, Flvio R. Wagner1

1
Instituto de Informtica, 2Dep. Engenharia Eltrica UFRGS Brazil
{mawehrmeister, epfreitas, flavio}@inf.ufrgs.br, cpereira@ece.ufrgs.br

Abstract programming [3]; and in the early phases of the design,

This work presents a proposal to use aspect orientation in
the analysis and design of Distributed Embedded Real-time
Systems (DERTS). These systems have several requirements
directly related to their main characteristics, the so-called
Non-Functional Requirements (NFR), which refer to
orthogonal properties, conditions, and restrictions that are
spread out over the entire system. Pure object-oriented
methods do not address successfully those so called cross-
cutting concerns, so new technologies, like aspect orientation,
are applied in order to fulfill this gap. The paper presents
DERAF - Distributed Embedded Real-time Aspects
Framework, an extensible and high-level framework (i.e.
implementation-independent) to handle NFR of DERTS at
earlier design stages. DERAF combines the use of aspects with
RT-UML, aiming to separate the handling of non-functional
from functional requirements in the Model Driven Design of
DERTS. The paper presents the use of DERAF on a case study
of an unmanned air vehicle (UAV).
1. Introduction
Embedded real-time systems have become very
complex, requiring the distribution of functionalities into
different processing units approximating services to the
location where they are demanded (e.g. deploying
sensing and control tasks of each helicopter rotating wing
into small processors instead of grouping them into a
more powerful processor), without violating system
constraints. This feature characterizes the Distributed
Embedded Real-Time Systems (DERTS).
The increasing complexity of DERTS requires new
development techniques in order to better support system
evolution and maintainability, and the reuse of
previously developed artifacts. DERTS have concerns
that affect distinct parts of the system, the so-called
crosscutting concerns. Non-Functional Requirements
(NFR) must be carefully handled, in order to avoid
tangled code and loss of cohesion. The separation of
concerns, where crosscutting concerns are identified as
NFR, is addressed by some works such as [1], [4] and
[6]. Thus some guidelines are proposed in order to
separate the handling of NFR from the functional ones:
at implementation level, using concepts such as subject-
oriented programming [2] and aspect-oriented
such as in the Early-Aspects [4] approach.
Real-time systems have a very important NFR which
is the concern about timing aspects, such as deadlines,
maximum jitter, worst case execution time, maximum
tolerated delays, and others. The complexity related to
the analysis of NFR increases when these systems
become distributed and embedded. Some proposals
suggest the use of aspects, as in [5] and [6]. Aspects can
help to deal with crosscutting NFR into DERTS design
by modularizing their handling. Additionally, more
abstract aspects are easily reused because they define the
handling of a concern at high-level and also how it can
be applied (or how it affects) the system without
implementation or platform constraints.
This work presents the Distributed Embedded Real-
time Aspects Framework (DERAF), which provides an
extensible set of aspects to deal with NFR of DERTS at a
high-level of abstraction, that is, a set of implementation-
independent aspects1 to handle NFR during the creation
of RT-UML2 models at design phase. In its initial
version, DERAF handles the following NFR (see Section
2): timing, precision, performance, distribution, and
embedded behavior. However, DERAF is an extensible
framework, such that it can be extended to provide
support to other important aspects (e.g. fault-tolerance).
It is important to highlight that, in spite of the high-level
of abstraction, aspects within DERAF must be
implementable. On other words, the realization of each
aspect must be possible, avoiding unfeasible aspects.
The remaining of this paper is organized as follows.
Section 2 discusses the handling of NFR within DERTS
design, presenting an aspects framework to handle the
identified NFR. Section 3 depicts how to design DERTS
using the presented framework illustrated by a case
study. Section 4 discusses related work, and final
remarks and future work are presented in Section 5.
1
This idea of implementation-independent aspects to design DERTS
was inspired by the context-free aspects as proposed in [9].
2
The term RT-UML is used to identify UML [10] models annotated
with the real-time profile [11].
2. Handling Non-Functional Requirements elements will be affected by selected aspects. The set of
aspects available in DERAF is depicted in Fig. 2.
Fig. 1 presents NFR related to DERTS development
handled in this work. This classification is based on the <<Non-Functional>>
Timing
<<Non-Functional>>
Precision
study presented in [14], on the IEEE glossary [15] , and <<Aspect>>
<<Aspect>>
<<Aspect>> <<Aspect>>
TimingAttributes <<use>> PeriodicTiming Jitter DataFreshness
on the SEI glossary [16].
<<Aspect>> <<Aspect>>
Deadline <<Aspect>>
<<use>> <<use>>
ToleratedDelay ClockDrift
Period TimeBoundedActivity <<Aspect>>
SchedulingSupport
Timing Cost
Release Time
Activation Latency
Start and End <<Non-Functional>> <<Non-Functional>>
Time Synchronization Communication
Jitter <<use>> <<use>> <<Aspect>>
Tolerated Delay <<Aspect>> MessageAck <<Aspect>>
Laxity ConcurrentAccessControl MessageCompression
Precision Freshness <<use>>
<<use>>
Non-Functional Resolution <<Aspect>> <<Aspect>>
MessageSynchronization
Drift MessageIntegrity
Requirements
Performance Response Time
Throughtput <<Non-Functional>>
Task Alocation Embedded <<Non-Functional>>
TaskAllocation
Hosts <<Aspect>> <<Aspect>>
Distribution Communication HwAreaMonitoring <<use>> HwAreaControl <<use>>
<<Aspect>>
Synchronization <<use>>
TaskMigration
<<Aspect>> <<use>> <<Aspect>>
Area EnergyMonitoring EnergyControl
Power Consumption <<use>>
Embedded Total Energy <<Aspect>> <<Aspect>>
<<Aspect>>
<<use>> NodeStatusRetrieval
Memory Allocation MemoryUsageMonitoring MemoryUsageControl

Generic Specific
Fig. 2 DERAF aspects set to handle NFR
Fig. 1 NFR classification for DERTS
Due to paper lengths limitations a detailed
Each NFR can be handled by one or more aspects,
explanation of each NFR is omitted. Time classification
such as the TimmingAttributes and PeriodicTiming
defines requirements related to temporal constraints of
aspects, which add timing attributes to active objects3
system activities. Performance requirements are tightly
(e.g. deadline, priority, start/end time, and so on), as well
related to those presented in the Time and Distributed
as adapt their behavior (e.g. adding code to control the
classification. They express a global need of
frequency of periodic execution of a task). There are
performance, such as end-to-end response time for a
aspects which adapts the way of an activity executes,
certain activity, as well as a required throughput rate.
such as DataFreshness and ConcurrentAccessControl.
Distribution classification defines requirements related to
The former associates timestamps to data, verifying their
the distribution of DERTS activities in different nodes.
validity before they are used[12], while the last one adds
Concerns related to embedded systems generally present
a control mechanism to the concurrent access of shared
requirements/constraints related to memory usage,
resources. However, DERAF aspects can also be used to
energy consumption, and required hardware area size.
setup configurable platforms, such as Message-related
To support the handling of NFR from earlier
aspects, which can be used to configure a communication
development stages on, DERAF, an extensible high-level
API with features like acknowledge message,
aspects framework based on the aspect orientation
compression and integrity checking. Aspects in the
conceptual model proposed in [20], is proposed. DERAF
embedded package deal are related to monitoring and
aims provide a modularized way to handle NFR,
controlling features such as energy consumption,
improving the reuse of aspects in different DERTS
memory and FPGA area usage. Nevertheless, these
projects. A detailed discussion on aspect-oriented
features must be supported by the target Hw and/or Sw
concepts is out of the scope of this paper and can be
platform.
found in [3], [7] and [20].
After the modeling phase, aspects must be
The main idea behind DERAF is to provide aspects
implemented through either application or platform4
which adapt modeled system elements by adding specific
code. Thus each DERAF aspect is linked to an
behavior and structure to handle NFR, without binding
implementation technology. The semantics of how and
the DERTS model to a specific solution (e.g. an
where each aspect affects system elements are defined
implementation for cyclical activation of periodic tasks).
at high-level and must be preserved, such that every
To ensure implementation independence, details related
to aspect adaptations are abstracted. This means that the 3
Active objects have their own thread of control and execute
designer selects aspects based on how the aspect concurrently with other active objects [10][11].
4
improves the system elements, and defines which According [13], platform is a set of previously developed and tested
hardware and software components that can be configured and reuse
implementation must follow these semantics in order to
allow the reuse of previously developed aspects
implementation Sometimes, it is also interesting to
evaluate the impact of the aspects implementation into
the design at the modeling phase. Therefore, it is
necessary to provide models to describe how each aspect
implementation affects the original specification. On
other words, it is necessary to provide an aspects model
weaving, like the ideas presented in [7]. In spite of its
importance, a detailed discussion about both
implementations (models and code), as well as model
weaving are, due to paper lengths limitation, beyond the
scope of this paper.
Finally, it is important to highlight that DERAF does
not provide aspects to handle all NFR present in a
Fig. 3 UAV movement control FRs and NFR
DERTS design. Fault-tolerance is an important NFR is
not addressed in the initial version of DERAF. However,
RT-UMLs diagrams are used for functional
DERAF was proposed as an extensible framework, and
requirements specification (see for instance [25]). NFR
support to fault-tolerance aspects will be incorporated in
are handled through DERAF aspects. In the proposed
future versions.
approach, the designer describes the selection of model
3. Application example elements, which will be affected by the selected aspects,
through Join Point Designation Diagrams (JPDD) [21].
This section presents the design of a distributed real-
JPDDs are used to describe the join point [20] selection
time embedded automation and control system for an
at modeling level, that means, in order to describe
unmanned air vehicle (UAV) [22][23][24] in order to
where the selected aspects will insert adaptations. The
illustrate how to use the DERAF framework. The
use of high-level join point descriptions improves their
proposed UAV system consists of a helicopter that can
reuse, allowing that the same join point be used with
be used in a variety of applications, such as environment
different adaptations. JPDD can be modeled using
monitoring, rescue of victims in natural disasters, or
interaction, activity and statechart diagram capturing,
urban security. UAV functionalities include navigation,
respectively, control flow, data flow, and state models.
movement control, collision detection, target pursuit,
For this initial proposal, only interaction JPDD to
system maintenance, mission management, camera
capture control flow join points are used.
control and data exchange with an on ground base. This
For illustration purposes, a very simple aspect was
case study will focus on the movement control sub-
chosen to show how to specify JPDDs and how it adapts
system, which is composed by sensors and actuators and
the functional specification. The chosen DERAF aspect
whose control algorithm takes into account environment
was DataFreshness, which handle the Precision NFR of
information (e.g. wind speed and direction, humidity and
values with a lifetime restriction. Fig. 4 shows the JPDD
temperature).
that selects behavioral elements. The stereotype
The design starts with the requirements analysis,
<<JPDD>> indicates the JPDD representing a join point
following the FRIDA (From RequIrements to Design
selection. The <<JoinPoint>> stereotype indicates the
using Aspects) methodology [17], which has been
element that will be selected when the JPDD will be
adapted to real-time and embedded systems domain. In
evaluated. For details on the elements naming pattern
this phase, both functional and non-functional
and wildcards, please refer to [21]. Fig. 4a shows the
requirements must be elicited using the aspects described
selection of the construction message for objects
in section 2. At the end of this phase, a use case diagram
representing information (i.e. all the classes whose name
is provided to describe graphically the specified system
finishes with Information) that is concurrently accessed
functionalities and their crosscuttings NFRs (depicted as
(i.e. annotated with the <<SAresource>> stereotype). On
stereotypes annotating the affected use cases). Fig. 3
the other hand, Fig. 4b shows the JPDD that selects all
shows the use cases diagram for the UAV system. .The
messages requesting data (i.e. message whose name
used notation follows ideas taken mainly from [19] and
starts with get), that are sent from active objects (i.e.
[7]. For details on adapted FRIDA methodology see
annotated with <<SAschedRes>>) to information
[18].
objects.
 Fig. 4 Join point selection: (a)Object creation (b)Message
The next step is to link the joint point selection with
the aspect. Fig. 5 shows one part of the proposed Aspects
Crosscuting Overview Diagram (ACOD) describing the
Freshness aspect. The aspect is represented as a class
annotated with the <<Aspect>> stereotype, pointcuts
are represented as attributes annotated with the
<<Pointcut>> stereotype, and the adaptations
represented as operations annotated with the
<<StructuralAdaptation>> or <<Behavioral
Adaptation>> stereotype. Behavioral adaptations can
have a relative position where the adaptation is applied.
For instance, in the Freshness aspect, the timestamp will
be added to an object and associated to a specific data
(i.e. attribute value) after the execution of the object
construction (e.g. <<Pointcut>> pcActObjInit
(constructor, SetupTimeStamp, AFTER)).
Another important feature is the online monitoring of
the data freshness. As can be seen in Fig. 5, the
timestamp is inserted in those classes which record
information. This timestamp will be checked every time
an object needs to read the time-controlled information.
This is provided by the behavioral adaptation
VerifyFreshness. According to the pointcut pcReadInfo,
before any message is sent to a controlled object to
retrieve time-controlled data, freshness verification must
be performed. The attributes inserted into all structural
adaptations (e.g. TimeStamp), have their values
initialized through parameters (see [7]) passed by the
SetupTimeStamp behavioral adaptation through the
<<Crosscut>> stereotyped association. ACOD can also
be used to show an overview of all used aspects and the
affected classes of DERTS design that represent
functional requirements. The idea is to automatically
generate the summarized ACOD through a tool that
evaluates all JPDDs to find out classes affected by the
selected DERAF aspects. At the moment, the
summarized ACOD must be generated manually.
Fig. 5 Linking JPDD with an aspect and adaptation
4. Related Work
Although aspect-orientation (AO) is a relatively new
concept, there are some proposals to use it in DERTS
design, especially to handle real-time requirements.
However, most approaches propose the use of aspects in
the implementation phase. For instance, in [6] aspects are
extracted from real-time Java code of a sentient traffic
simulator, to non-functional concerns such as threads,
memory management, and asynchrony. The paper
compares pros and cons of object-oriented vs aspect-
oriented implementations. In the approach proposed in
this paper, AO concepts are applied at higher abstraction
levels using a top-down approach instead of re-factoring
an existing source code in a bottom-up approach.
In [5], a toolkit named VEST (Virginia Embedded
System Toolkit) aspects are used to abstract timing
properties of pre-designed components, in order to check
the possibility of composing components with
information taken from system models. Aspects are also
used to check and test dependencies among library
components. Results presented in the paper indicate a
reduction in design time when using VEST. Diferently,
in the approach presented in this paper, aspects are used
to directly deal with NFR from the analysis phase.
Additionally, in our work aspects play an important role
during the design of crosscutting concerns.
AODM (Aspect-Oriented Design Model) [7] is an
UML extension to deal with AO design concepts. It
reproduces constructs of the AspectJ language [8] using
UMLs stereotypes and tagged values. Additionally,
AODM also proposes a weaving mechanism to apply
aspects adaptations within the system model. AODM
was proposed to be used in the general computing system
domain, which does not have very stringent NFR as in
the embedded real-time domain. This work proposes to
deal with DERAFs supported NFR at a high-level of
abstraction, providing traceability to these NFR along the
development process. Additionally, the proposed
approach is not limited to a specific programming
language due to the abstract nature of DERAF aspects.
5. Final Remarks and Future Work
This paper proposes the use of AO to deal with non-
functional concerns that crosscut since earlier modeling
and design phases, such as requirements and analysis of
DERTS project. To support our proposal, a high-level
aspects framework named DERAF has been developed.
The set of aspects provided by DERAF deals with time,
distribution, and embedded NFR. DERAF is used to map
NFR from requirements elicitation and analysis to design
elements in the modeling phase, using a methodology
adapted from FRIDA. To illustrate the use of DERAF in
DERTS design, an UAV movement control system was
presented as case study. It has been shown how to use
DERAF aspects to model the handling of non-functional
concerns using RT-UML. Other applications were
modeled using the proposed approach. The generated
models were evaluated using software engineering
metrics and compared to object-oriented models. The
obtained results indicate that the use of AO can impact
positively in some metrics, such as cohesion, coupling
and size.
As future works, we intend to implement DERAF
aspects in order to allow their use in implementation
phase of DERTS design. In addition, we plan to use the
DERAF implementation to generate DERTS source code
automatically (as complete as possible, that is, not only
code skeletons) from RT-UML using DERAF aspects.
References
[1] L. Chung and B.A. Nixon, Dealing with Non-Functional
Requirements: Three Experimental Studies of a Process-Oriented
Approach, Proc. of 17th International Conference on Software
Engineering, ACM Press, 1995, pp. 25-37.
[2] H. Ossler, and P. Tarr, P., Using subject-oriented programming
to overcome common problems in object-oriented software
development/evolution, Proc. of 21st Int. Conf. on Software
Engineering, IEEE Computer Society Press, 1999, pp. 687-688.
[3] G. Kiczales et al., Aspect-Oriented Programming, Proc. of
European Conference for Object-Oriented Programming, ECOOP,
LNCS 1241, Springer-Verlag, 1997, pp. 220-240
[4] A. Rashid, P. Sawyer, A. Moreira, J. Araujo, Early Aspects: A
Model for Aspect-Oriented Requirements Engineering, Proc. of
IEEE Int. Conf. on Requirements Engineering, 2002, pp.199-202
[5] J.A. Stankovic et al., VEST: An Aspect-Based Composition
Tool for Real-Time System, Proc. of 9th IEEE Real-Time and
Embedded Technology and Applications Symposium, RTAS,
2003, pp. 58-59
[6] S.L. Tsang, S. Clarke, E. Baniassad, An Evaluation of Aspect-
Oriented Programming for Java-based Real-Time Systems
Development, Proc. of the 7th Int. Symp. on Object-Oriented
Real-Time Distributed Computing, IEEE Computer Society,
2004.
[7] D. Stein, S. Hanenberg, R. Unland, A UML-based Aspect-
Oriented Design Notation for AspectJ, Proc. of Int. Conference
on Aspect-Oriented Software Development, ACM Press, 2002,
pp. 106-112
[8] AspectJ, www.aspectj.org, v.1.5.2, Sep.2006
[9] R. France, I. Ray, G. Georg, and S. Ghosh, "An Aspect-Oriented
Approach to Early Design Modeling", IEE Software,vol.151,
2004, pp. 173-186
[10] Object Management Group, Unified Modeling Language:
Superstructure, v.2.0, www.omg.org/cgibin/doc?formal/05 -07-
04, Sep.2006
[11] Object Management Group, UML profile for Schedulability,
Performance and Time, v.1.1, www. omg.org/cgi-
bin/doc?formal/2005-01-02, Sep.2006
[12] A. Burns et al. The Meaning and Role of Value in Scheduling
Flexible Real-Time Systems in Journal of Systems Architecture:
the EUROMICRO Journal. vol.46, n.4, 2000, pp.305-325
[13] K.Keutzer, S.Malik, R.Newton, J.Rabaey, A.Sangiovanni-
Vicentelli, System Level Design: Orthogonalization of Concerns
and Platform-Based Design, IEEE Transactions on Computer-
Aided Design of Integrated Circuits and
Systems,vol.19,n.12,2000, pp.1523-1543
[14] A. Burns, A. Wellings, Real-time systems and programming
languages,Addison-Wesley,2ndedition, 1997.
[15] Institute of Electrical and Electronics Engineering, IEEE
Standard Glossary, http://standards.ieee.org/catalog/olis/
arch_se.html, Sep. 2006
[16] Carnegie Mellon Software Engineering Institute, Online
Technical Terms Glossary, http://www.sei.cmu.edu/str/
indexes/glossary/, Sep. 2006
[17] S.C. Bertagnolli, M.L.B. Lisba, The FRIDA Model, Proc. of
Workshop on Analysis Aspect-Oriented Software, Germany,
(Held in conjunction with ECOOP 2003), 2003.
[18] E.P. Freitas, M.A. Wehrmeister, C.E. Pereira, F.R. Wagner, E.T.
Silva Jr., F.C. Carvalho, Using Aspect-Oriented Concepts In The
Requirements Analysis Of Distributed Real-Time Embedded
Systems, to appear in Proc. of IFIP International Embedded
Systems Symposium, Irvine, USA, 2007.
[19] J. Arajo et al., Aspect-Oriented Requirements with UML, in
Proc. of Workshop on Aspect-oriented Modeling with UML,
UML 2002, Germany, 2002.
[20] A. Schauerhuber, et al. Towards a Common Reference
Architecture for Aspect-Oriented Modeling, in Prof of Int.
Workshop On Aspect-Oriented Modeling, AOSM 2006.
[21] D. Stein, S. Hanenberg, R. Unland, Expressing Different
Conceptual Models of Join Point Selections in Aspect-Oriented
Design, Proc. of 5th Int. Conf. on Aspect-Oriented Software
Development,ACM Press,2006,pp.15-26
[22] C. W. Seibel, J. Farines, J. E.R. Cury, Towards Using Hybrid
Automata for the Mission Planning of Unmanned Aerial
Vehicles, Lecture Notes In computer Science, Vol. 1567, Spring-
Verlag, London, UK, 1999, pp. 324-340.
[23] A. Ryan, M. Zennaro, A. Howell, R. Sengrupta, J. K. Hedrick,
An Overview of Emerging Results in Cooperative UAV
Control, Proc. of the 43rd IEEE Conference on Decision and
Control, IEEE Computer Society, 2004, pp. 602-607.
[24] G. Cai, K. Peng, B. M. Chen, T. H. Lee, Design and Assembling
of a UAV Helicopter System, Proc. of the International
Conference on Control and Automation, (ICCA2005), IEEE
Computer Society, 2005, pp.697-702.
[25] M.A Wehrmeister, L.B. Becker, F.R. Wagner, C.E. Pereira, On
Object-Oriented Platform-based Design Process for Embedded
Real-Time Systems, Proc. of the 8th IEEE Int. Symp. on Object-
Oriented Real-Time Distributed Computing, IEEE Computer
Society, 2005, pp. 125-128