Information Technology Reference
In-Depth Information
may use relegation relation to infer, if the G with a Q is to have the Internet connec-
tivity not less than 256Kbps can be relegated. After re-evaluating the possibilities, SAS
finds CS
i.e. set of tasks T ,e.g. enable 3G or Edge service and connect to the
Internet with a refined Q i.e. Internet connectivity greater than 256Kbps for the user.
At this stage the influence relation is also used to ascertain the influence of CS
(
C 2 )
C 2 )
on
user's goals and preference, e.g. Hi-speed Internet is preferred than no Internet connec-
tion . SAS can derive conclusions that adapting to CS ( C 2 )
(
i.e. Any
flight information must be communicated to the customer and goal G i.e. to connect to
the Internet to view itinerary and inform about the flight delays will be satisfied. There-
fore, CS
will not affect K C 2
(
C 2 )
=
(
K C 2
,T C 2 )
; satisfying the runtime requirements adaptation problem
i.e. RP
(
C 2 )
. We can rewrite this as:
C 2 , K C 2 , T C 2 |
G C 2 , Q C 2
R (
C 2
K C 2
T C 2 )
identifies the set of resources R available, e.g. (Access 3G
or Edge data services, Mobile Phone of the user) to perform T C 2 .
After Adaptation: At time t 3 , SAS adapts to the candidate solution CS
where
taking
into account the context C 2 and available resources R i.e. Access 3G or Edge data
services, Mobile Phone of the user, thus not violating the K C 2
(
C 2 )
. Adaptation is performed
dynamically at runtime by changing (e.g. switching, re-configuring, optimizing) SAS
from one requirements problem to another i.e. RP
(
C 1 )
to RP
(
C 2 )
, in response to
changes in the context, user's needs or resource variability.
5
Related Work
Requirements engineering is carried out at the outset of the whole development pro-
cess, but in the context of SAS, RE activities are also needed at runtime thus enabling
a seamless adaptation. Research on SAS has recently received attention from variety of
research communities mainly targeting the software engineering of SAS from require-
ments, design and implementation perspectives. Focusing on requirements engineering
for SAS, research agenda from SEAMS [5] and RE community has identified key chal-
lenges that must be addressed while developing such systems.
For instance, in [23], a declarative language (RELAX) is proposed to capture uncer-
tainty, using temporal operators (such as eventually, until) by formalizing the semantics
in Fuzzy Branching Temporal logic, to specify requirements for SAS. Similarly, adopt-
ing goal-oriented analysis for adaptive systems, mitigation strategies are proposed to
accommodate uncertainty and failures by using obstacle analysis in [4]. Requirements
reflection is another aspect, where ideas from computational reflection has been bor-
rowed to provide SAS the capability to be aware of its own requirements [21]. Similarly,
online goal refinement [9] is of prime importance considering the underline architecture
of the intended SAS. Taking the engineering perspective, making the role of feedback
loops more explicit in the design of SAS has been recognized as a key requirement for
developing SAS in [3].
In our previous work, we proposed similar ideas to engineer adaptive requirements
using goal models and ontologies by making explicit the requirements for feedback loop
(i.e. monitoring, evaluation criteria, and adaptation alternative) more explicit in [16]. We
 
Search WWH ::




Custom Search