=Paper=
{{Paper
|id=Vol-2326/paper16
|storemode=property
|title=An Islamic Application Based on Self-adaptive Components
|pdfUrl=https://ceur-ws.org/Vol-2326/paper16.pdf
|volume=Vol-2326
|authors=Malak Meghnous,Fadila Atil
|dblpUrl=https://dblp.org/rec/conf/icaase/MeghnousA18
}}
==An Islamic Application Based on Self-adaptive Components==
https://ceur-ws.org/Vol-2326/paper16.pdf
An Islamic application based on self-adaptive component
Meghnous Malak 1 Atil Fadila
1
Complex System Engineering Laboratory Complex System Engineering Laboratory
(LISCO), Department of Computer Science, (LISCO), Department of Computer Science,
Badji Mokhtar University, POB 12, Badji Mokhtar University, POB 12,
23000 Annaba, Algeria 23000 Annaba, Algeria
MeghnousMalak@gmail.com atil_fadila@yahoo.fr
Abstract
Self-adaptive systems are software systems Thus, modeling these systems is complex and crucial step
that have to dynamically adapt their behavior in the development process, due to the large number of
in response to environment changes and configurations and contexts.
users fluctuations. Thus, variability is a key Handling variability is a common activity between
concept in these systems; and handling it in Software Product lines and self-adaptive systems. Hence,
early stages in the software development life using SPLs mechanisms to model variability in self-
cycle, helps to control complexity. The adaptive systems will help to maintain the complexity.
Design of these systems using component Component based development is a paradigm in which
based architecture, enhances reuse and the construction of applications is essentially based on
promotes dynamic reconfiguration, enabling assembly and reuse of existing entities called "software
system’s modification without intercepting components”. Thus, it promotes reuse and provides a
its execution, thus ensuring continuity of component based architecture of system that can be
service. In this paper, we propose the configured and reconfigured by adding, altering or
dynamic adaptation of a component based deleting components or connectors or interfaces.
Islamic application according to the user The contribution of this paper is to construct an
context (expert/novice), using orthogonal adaptive Islamic application according to the user
variability modeling and an aspect-oriented context. The idea is to develop a component based
approach. We aim at combining UML architecture of the application to enhance component
Component Model and the orthogonal reuse and to benefit from the architecture
variability model in order to document reconfiguration. Also, and in in order to decrease
variability. This allows to decrease system’s system’s complexity, we propose to model variability by
complexity and to maintain whole view of using SPLs mechanisms, for instance, the OVM.
the system’s component based architecture Furthermore, to resolve variability at runtime and in
and ensures variability traceability. order to guarantee separation of concerns, we propose
an aspect oriented approach.
Keywords – Self-adaptive system, The remainder of this paper is structured as follows:
Variability modeling, Orthogonal variability section 2 and 3 introduce briefly self-adaptive systems
Model, Component based architecture, and variability management respectively. Section 4
Aspect oriented paradigm. details our proposed approach, and illustrate it with a
running example. Finally, section 5 concludes and
1. Introduction addresses future works.
Self-adaptive systems are software systems that have 2. Self-adaptive systems
to dynamically alter their behavior in response to
environment changes and user’s fluctuations, e.g. system Dynamically adaptable software (DAS) self-adapts
shifts from state N (configuration N) to a new state N+1 according to context information gathered from the
(new configuration N+1). surrounding environment [San17]. I.e. these systems
alter their own behavior dynamically in response to
Copyright © by the paper’s authors. Copying permitted only for private
and academic purposes.
In: Proceedings of the 3rd Edition of the International Conference on
Advanced Aspects of Software Engineering (ICAASE18), Constantine,
Algeria, 1,2-December-2018, published at http://ceur-ws.org
Page 122
An Islamic application based on self-adaptive component ICAASE'2018
change in its operating environment, such as end-user Accordingly, handling variability (representing,
inputs, external hardware devices and sensors, or managing, and reasoning about) in early stages of the
program instrumentation [Sai09]. software development lifecycle has become a relevant
This behavioral change requires structural change, and concern [Gal11].
the system shifts from state N to a new state N+1. Thus,
a DAS needs to be able to sense its environment, to
3.1 FODA approach
autonomously select an appropriate configuration and to
efficiently migrate to this configuration. Handling these Variability representation consists on capturing
issues at the programing level proves to be challenging commonalities and differences between potential
due to both the large number of contexts and the large variants. In product line engineering, the FODA
number of software configurations which have to be (Feature-Oriented Domain Analysis) model describes the
considered. The use of modeling and the exploitation of visible properties of systems, in terms of product
models at runtime level provide solutions to cope with features. A feature is any stakeholder-relevant
the complexity and the dynamic nature of DAS [Arc09]. characteristic of a system [Hil10]. Indeed, the FODA
Moreover, DAS can be considered as a software model models such variability in a tree graph using
product line in which variability is resolved and bound at variants (features that might be mandatory, optional or
runtime. Hence, variability modeling techniques used in alternative) and variation points representing logical
SPLs, could also be applied during design phase of DAS. relationships between variants [Bos15].
Designing such complex computing systems has been On the basis of FODA, several extensions and
enhanced by the help of structural organization support enhancement of feature modeling and feature models
of component-based architecture and model, in which were proposed, e.g. the FORM approach (Feature
software components encapsulates functionalities that Oriented Reuse Method), that aim to enriching feature
can be accessed through well-defined interfaces that do models with additional information, e.g., regarding
not depend on their particular implementations. In feature cardinalities propositional constraints and non-
addition to the benefits of modularity and reuse that functional properties of features [Hil10] [Bos15].
result from this structural organization, adaptability and
dynamic reconfigurability are key properties sought with
3.2 The orthogonal variability model
this approach: it is possible to dynamically reconfigure
the components assembly during runtime to cope with Modeling the variability within the traditional
environment or user’s fluctuations [Alv17]. software development models has some significant
Thereby, resolving variation points at runtime leads to drawbacks. For instance, it increases models complexity,
dynamically reconfigure the component based because these techniques specify both common and
architecture, by means of binding variants, e.g. adding, variable parts of the system. Moreover, Variability
removing, replacing or altering components, connectors informations cannot be traced if they are scattered among
and interfaces. different models [Poh05] [Poh07].
In order to obtain a clear separation of concerns The orthogonal variability model is a language and a
between the adaptation code and the computational methodology for superimposing variability over any
code, we consider the management of variability as a software development artifact without interfering into its
non-functional requirement. Indeed, we use the aspect contents [Ecc16].
oriented approach to weave or unweave variants (in our The OVM approach can be used to document the
work components) during runtime. variability of arbitrary development artifacts, ranging
from textual requirements to design models and even test
cases. Also, the documentation of variability is separated
3. Variability management from the technical realization of variability in the
Variability is usually understood as the ability of a development artifacts and as such provides a further level
software artifact to be changed (configured, customized, of abstraction that aids developers in managing
extended or adapted) in order to fit different contexts complexity and tracing variability [Poh07].
and environments. Variability can also be seen as the To that end, in our work we specified variability
anticipated change [Gal14]. Variation has been largely separately using the OVM as in figure 1, which depicts
addressed in the context of software product lines. the graphical notations of this model.
Indeed, it is a key fact of most systems, if not all. In such
systems, variation occurs for the same reasons as for the
product lines [Hil10] [Gal11]; including:
4. The proposed approach
I. Defer decisions about design or implementation. This section addresses the problem of developing an
II. Support multiple deployments. Islamic component-based application, that allows the
III. Achieve system qualities such as adaptability. inspection of food according to the Islamic percepts, and
makes a verdict to classify them into Halal or not.
International Conference on Advanced Aspects of Software Engineering Page 123
ICAASE, December, 01-02, 2018
An Islamic application based on self-adaptive component ICAASE'2018
As early mentioned, the component based 2, and table 1, which provides a brief description of
development provides, an entire view of the system composite components.
which helps to reduce complexity; emphasize reuse; and Also, we adopt the orthogonal variability modeling
promotes reconfiguration. Consequently, and due to its technique with a different semantic. Variation points
dynamic reconfiguration feature, we use the Fractal indicate the containing relationship between components,
Component Model. e.g. TypeF Variation point indicates the potential
subcomponents of the Food component (what
subcomponents could be contained in the Food
component), which are, the three variants: meat,
additives, and drinks. The alternative choice with [1..3]
cardinality, signify that the Food component must at least
contain one subcomponent.
Table 1: Component description
Component
Description
name
Mandatory Component provides
FoodClassifi
the name and the classification of
cation
the food (Halal/Haram).
Optional Component provides the
Figure 1: Graphical notation for variability models proof about the classification of the
Proof
[Poh 05]. food from the Holy Quran and the
Sunna.
Moreover, our application is contextually adaptable,
especially according to the user context, in order to offer
4.2 Adaptation of the architecture according to
different modes of operation, for users of different skill
the context
level (Novice user/ Expert User).
Variability management is a common key between Adaptation of the architecture, as shown in Figure 3,
software product lines and self-adaptive system. Thereby, shifts the architecture of an application from a
several works have been established to identify synergy configuration (state N) to a new configuration (N + 1)
points and cross-fertilization opportunities between the according to a well-defined context, and following the
two domains, such as [Alv12]. Correspondingly, we use adaptation policy.
the orthogonal variability model, which is a variability
modeling mechanism in SPLs, to model information
about variability in our system. 4.2.1 Context representation
Furthermore, the dynamic adaptation of our The context groups all the information about the
architecture, which can be considered as the resolution of running environment. In this work, we are interested in
variation points, is implemented in AOP that proposes the user context, in particular, the expertise level of
the separation of concerns, which allows the reuse of the users.
same aspect in different components of the system. Thus, As illustrated in figure 4, user context is characterized
we use aspects to specify when, where, and how to by, the current state of the architecture and, the incoming
reconfigure the system’s architecture with variants change of users which, in our work, is interpreted as
The following sub-sections detail each parts of our events.
work. In our user context, we have two types of users:
i. A novice user: a user who does not need
4.1 Variability modeling and components design proof/evidence about the classification of the
food.
We model the component based architecture with ii. An expert user: a user who needs accurate and
UML 2.0 Component diagram. In addition to, the detailed proof and justifications about the
Orthogonal Variability Model to document variability in classification of the food. This proof may be
design phase, in particular, to document our Islamic extracted from the Holy Quran or the
Component based architecture. This is depicted in figure Sunnah of the Prophet or both.
International Conference on Advanced Aspects of Software Engineering Page 124
ICAASE, December, 01-02, 2018
An Islamic application based on self-adaptive component ICAASE'2018
Figure 2: Linking UML Component Diagram with OVM for the Islamic Application.
International Conference on Advanced Aspects of Software Engineering Page 125
ICAASE, December, 01-02, 2018
An Islamic application based on self-adaptive component ICAASE'2018
4.2.2 Adaptation policy
We have used a rule-based approach, specifically
ECA (event, condition, action) rules, to resolve
variability at both design and runtime.
The adaptation policy is a function that transforms a
series of events that represent the context into a set of
actions by respecting a set of conditions and starting
from an initial state (configuration N).
In order to resolve variation point at the
implementation level and provide dynamic adaptation, we
have used the aspect oriented paradigm. It is a
programming paradigm that allows isolating cross-
cutting concerns, which are so-termed non-business
functionalities (security, dynamicity). There are two main
Figure 3: Description of the architectural adaptation. symptoms related to cross-cutting concerns: scattered
and entangled code.
In our approach, the aspect intercepts and captures
the state (configuration (N)) of the system as well as the
event describing the context (Expert/Novice) (see figure
5). From these data and conditions (in the ECA rules), a
series of actions (in the ECA rules) that serve to
transform the system to a new state (an N + 1
configuration), are executed. Specifically, the aspect
Figure 4: Context representation.
specify when, where, and weave/unweave components.
Lesson 1, illustrates an example of ECA-rule based
adaptation policy.
Figure 5: The adaptation policy with aspect oriented approach.
International Conference on Advanced Aspects of Software Engineering Page 126
ICAASE, December, 01-02, 2018
An Islamic application based on self-adaptive component ICAASE'2018
Lesson 1: Example of ECA-rule based adaptation policy.
Figure 6: Dynamic reconfiguration of the system‘s architecture.
International Conference on Advanced Aspects of Software Engineering Page 127
ICAASE, December, 01-02, 2018
An Islamic application based on self-adaptive component ICAASE'2018
Figure 7: Activity diagram of the scenario.
In order to understand the adaptation, we propose the
following scenario: 5. Related work
We suppose that the system’s current configuration
corresponds to figure 6.a. Several researches have been contributed for runtime
1. The user writes the word “ ”البيرةas the name adaptation of systems. Similarly to our work, [Lou13]
of the food he wants to search its proposed an aspect oriented approach to dynamically
classification, and checks the checkbox “ adapt a component based system. However, variability is
لقرءان ”الدليل من اin order to get evidence from modeled implicitly by architectural aspect at the design
the holy Quran about the classification of the level and no formal method to represent variation
searched word. method has been used. Unlikely, in our approach, the
The system considers this user as expert (expert variability is represented explicitly using the OVM.
event), because he required evidence along with the In [Wol08], SPL engineering and plugin techniques
answer. have been combined to perform runtime adaptation.
2. The aspect checks if the current Based on the information documented in the variability
configuration of the system (figure 6.a) models, and a plugin developed upon the .Net platform,
contains the Quran component: runtime adaptation and dynamic reconfiguration are
2.1 In the case, the answer is “yes”: the achieved. On the other hand,, our approach is based on
system provides the answer. components and aspect oriented paradigm that satisfy the
2.2 In the case, the answer is “no”: the separation of concerns property.
aspect adds the Quran component [Cos07], is another work that used the AOP
dynamically to the architecture (figure combined with the computational reflection, to
6.b), which allows the system to provide dynamically adapt the internal structure of aspect-
the answer. oriented component. On the contrary, our approach
3. The system displays the answer which is : achieve adaptation by reconfiguring the whole
“ ”نعم البيرة حرامalong with the evidence architecture. Moreover, the proposed adaptation has as
(number of surah=05 , number of verse=90). purpose, correction or maintenance, while in our work,
In order to simplify the representation we consider: we focus on adaptation according to the user context.
Q1 is the question asked by the user, and A1 is the Finally, the variability modeling is not considered in this
answer displayed by the system. work.
Figure 7 depicts the corresponding activity diagram to
the up-mentioned scenario.
6. Conclusion and future work
This paper addresses the adaptation of an Islamic
application according to the user context. We have
International Conference on Advanced Aspects of Software Engineering Page 128
ICAASE, December, 01-02, 2018
An Islamic application based on self-adaptive component ICAASE'2018
modeled this application using a combination of UML review”, 3rd ed., vol.40, IEEE Transactions
Component Model and the orthogonal variability model on Software Engineering, pp.282-306, 2014.
in order to document variability. This combination [Hil10] R. Hilliard, “On representing variation”,
reduces system’s complexity and maintains a whole view ECSA 2010 workshops: Workshop on
of the system’s component based architecture and Variability in Software Product Line
ensures traceability of the variability. Architectures, Copenhagen, Denmark, vol.
Based on this view and the OVM model, we have
companion, pp.312-315, 2010.
proposed an aspect oriented approach to reconfigure the
architecture in order to satisfy the user’s needs. [Lou13] S. Loukil, S. Kallel, M. Jmaiel, “Runtime
Context representation in a formal way is one of the adaptation of component based systems”,
trends of self-adaptive systems. Our perspective is Networked Systems, Marrakech, Morocco,
therefore to explore context variability representation. vol. 1, pp. 284-288, 2013.
[Poh05] K. Pohl, G. Böckle, F.V. Linden, “Software
product line engineering - foundations,
7. References principles, and techniques”, Springer, 2005.
[Poh07] K. Pohl, A. Metzger, “Variability
[Alv12] V. Alves, D. Schneider, M. Becker, N. management in software product line
Bencomo, P. Grace, “Comparitive study of engineering”, International Conference on
variability management in software product Software Engineering, Minneapolis, USA,
lines and runtime adaptable systems”, vol. companion, pp. 186-187, 2007.
Variability Modelling of Software-Intensive [Sai09] M. Salehie, L. Tahvildari, “Self-Adaptive
Systems, Sevilla, Spain, vol. 1, pp. 9-17, software: landscape and research
2012. challenges”, 2n ed., vol. 4, ACM
[Alv17] F. Alvares, E. Rutten, L. Seinturier, Transactions on Autonomous and Adaptive
“Domain-specific language for the control of Systems, pp.1-42, 2009.
self-adaptive component-based architecture”, [San17] I. Santos, T.A. Oliveira, E.S. Almeida, R.M.
1st ed., vol 130, Journal of Systems and Andrade, “Dynamically adaptable software is
Software, pp.94-112, 2016. all about modeling contextual variability and
[Arc09] M. Acher et al., “Modeling context and avoiding failures”, 6th ed., vol. 34, IEEE
dynamic adaptations with feature models”, Software, pp. 72-77, 2017.
International Workshop Models at Run.time, [Wol08] R. Wolfinger, S. Reiter, D. Dhungana, P.
Denver, USA, pp. 10, 2009. Grunbacher, H. Prahofer, “Supporting
[Bos15] J. Bosch, R. Capilla, R. Hilliard, “Trends in runtime system adaptation through product
systems and software variability”, 3rd ed., line engineering and plug-in techniques”,
vol. 32, IEEE Software, pp.44-51, 2015. International Conference on Composition-
[Cos07] C.Costa, J.Pérez, J.Á.Carsí, “Dynamic Based Software Systems, Madrid, Spain, vol.
adaptation of aspect-oriented components”, 1, pp.21-30, 2008.
Component-Based Software Engineering,
Medford, USA, vol.1, pp.49-65, 2007.
[Ecc16] J. Echeverria, F. Pérez, C. Cetina, O. Pastor,
“comprehensibility of variability in model
fragments for product configuration”,
Conference on Advanced Information
Systems Engineering, Ljubljana, Slovenia,
vol. 1, pp. 476-490, 2016.
[Gal11] M. Galster, P. Avgeriou, “Variability in
software architecture: current practice and
challenges”, 5th ed., vol. 36, ACM
SIGSOFT Software Engineering Notes,
pp.30-32, 2011.
[Gal14] M. Galster, D. Weyns, D. Tofan, B.
Michalik, P. Avgeriou, “Variability in
software systems— a systematic literature
International Conference on Advanced Aspects of Software Engineering Page 129
ICAASE, December, 01-02, 2018