构建自适应软件系统：动态环境下的工程挑战与方法

DESIGN

需积分: 15 97 浏览量更新于2024-07-17 收藏 4.7MB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

资源详情

资源推荐

1 Design and Engineering of Adaptive Software Systems 9

Table 1.2 Revoking action

Action Revoke(s

)

Precondition Constraint(s

)

∧(bound(s

) ∧ (Function(s

) | Function(s

))

∧Quality(s

) | Quality(G)

∨¬Available(s

))

Trigger Quality(s

) | Quality(s

) ∧ available(s

)

Effect bound(s

) ∧ remove(s

)

Table 1.3 Par_and(s

) Composition action

Action Par_and(s

)

Precondition Constraint(s

) holds

∧(Function(s

) | Function(s

)) ∧ Function(s

) | Function(s

))

∧minimal(throughput(G)) ≥ throughput(s

)

∧minimal(throughput(G)) ≥ throughput(s

)

∧minimal(throughput(G)) ≥ throughput(s

)

∧available(s

) ∧ available(s

)

Trigger throughput(Par_and(s

)) ≥ minimal(throughput(G))

Effect bound(s

) ∧ bound(s

)

“Network speed” has a value that is less than 50 kbps, then the service is not

available.

An adaptive system can perform actions to handle changes of user goals, the

environment, or service components. Each action represents a speciﬁc procedure

to be carried out by the system. Adaptation actions include adding, removing, or

updating an atomic service; reorganizing the structure of an abstract service plan;

reorganizing the structure of a concrete service chain and adding, removing, or

updating user goals; and adding, removing, or updating an environmental monitor.

For each action there may be associated environmental conditions that need to

be monitored by the system and included in the environment set E. Actions have

associated preconditions, triggers, and effects with usual semantics. All of them

consist of propositions constraining environmental variables and the internal state

of a service component.

For example, when a new atomic service s

emerges, s

is an atomic service of

a composite service that suddenly becomes unavailable or waiting to be executed

at the moment, i.e., Functionality(s

) = Functionality(s

), and Quality(s

)is

obviously better than Quality (s

); the system may take “revoking” action in

Table 1.2.

When a user’s required value exceeds the QoS value of any existing service

,...,e

, the system may execute more than one atomic service (say s

)

concurrently (with complete synchronization) to meet the demand. This is shown as

action “Par _and(s

) composition” in Table 1.3.

10 S. Hidaka et al.

Table 1.4 Par_or(s

) Composition action

Action Par_or(s

)

Precondition Constraint(s

ij,

) holds

∧(Function(s

) == Function(s

))

∧minimal(reliability(G)) ≤ reliability(s

) ≤ optimal(reliability(G))

∧minimal(reliability(G)) ≤ reliability(s

) ≤ optimal(reliability(G))

∧available(s

) ∧ available(s

)

Trigger reliability(Par_or(s

)) ≥ reliability(s

)

∧reliability(Par_or(s

)) ≥ reliability(s

)

Effect bound(s

) ∧ bound(s

)

When a user needs a high-reliability service, while every available service has a

certain level of risk, the system may execute more than one atomic service (e.g., s

and s

) concurrently (with 1 out of n synchronization) to meet the demand. This is

shownasaction“Par_or(s

)”inTable1.4.

The concepts deﬁned above form a basic framework for representing the planning

strategy of composite services. During the service composition process, user goals

are likely to change, the environment variables are often unpredictable, and the

service repository is constantly updated, so the service composition plan has to

adapt to these changes. Strategies can be formed to decide what adaptive actions to

be carried out, based on the user’s goals to be satisﬁed, the environment conditions

to be monitored, and the service repository dynamically changing. We provide three

categories of strategies according to the type of change: goal-driven adaptation strat-

egy, environment-triggered adaptation strategy, and service-association strategy.

• Goal-driven strategy: Given a softgoal G, if Quality(s

,...,s

) does not satisfy

the user’s minimal (Quality(G)), we take actions according to the service

repository and the environment variables to satisfy the user’s new softgoal G,

if possible. This corresponds to the scenario when user requirements change at

runtime. Generally, a goal-driven strategy inﬂuences the selection of the structure

of an abstract service.

• Environment-triggered strategy: Given a certain runtime context E, where there

are composed but not yet executed services, if a certain constraint on E does

not hold, alternative services are selected to satisfy the environment constraints.

The strategy ﬁts the cases where the environment is not stable and requires

reconﬁguration of concrete services.

• Service-dominated strategy: This strategy applies if there is a bounded set of

services that haven’t been executed yet and there is a new service providing

equivalent function and better quality or one of the bounded services becomes

unavailable. Assuming that user goals and the environment stay the same, the

new service can satisfy user goals better, so we take action to add the new service

or remove the unavailable one. This strategy is useful for a dynamically changing

service repository and will result in replacement of the concrete services.

12 S. Hidaka et al.

Step 4: The select and adapt concrete services operation (P4) selects atomic

services or compositions from the abstract service according to user softgoals,

Quality(G). If the Monitor operation (P7) identiﬁes certain Change(S,G, E), the

Select operation (P4) undertakes adaptive action to tackle the problems according

to the current strategy (G×E ×S ×A). During selection and adaptation, machine

learning and AI strategies can be adopted to provide useful feedbacks. The select

and adapt the concrete services (P4) would output a series of selected services.

Step 5: Selected services generated in Step 4 are now executed (P5). The exe-

cution affects the runtime values of the environmental variables, whose change

can be monitored by the monitoring mechanism. And when abnormal behaviors

have been observed, the system will trigger predeﬁned actions to maintain the

expected service effect.

Step 6: The runtime status is analyzed, and new environmental variables may be

obtained (P4). If current values do not satisfy expected values of environmental

variables, the monitor for events operation (P7) identiﬁes the problem.

Step 7: During the execution of the service process (P5), user goals are also

allowed to change, environmental variables are allowed to have uncertain

changes, while service repository is also allowed to change dynamically. These

changes (S,G, E) need to be captured and submitted to the select and adaptation

engine for concrete services (P4).

AsshowninFig.1.2, the steps P4, P5, P6, and P7 form a feedback loop that

executes iteratively to support runtime adaptation. Those changes on the goals and

the service repository come from the user and the platform correspondingly, so they

are not part of the feedback loop.

In summary, the goal-driven runtime service composition adaptation proposed

in this chapter aims to provide a different viewpoint and interpretation to runtime

requirement monitoring and services adaptation. To allow runtime requirements

changes and system adaptation, the software system needs to maintain a goal

reﬁnement model during execution, in which the set of user goals, environment

variables, possible system actions, and triggering rules connecting the previous

three sets can evolve dynamically. The proposed service adaptation architecture, the

different types of rules in the rule base, the monitoring mechanism for collecting the

environmental parameters, and the planning mechanism reasoning about adaptation

strategies are to be further examined in our ongoing future work.

1.2.3 Human Factors

An engineered adaptive system captures the knowledge of human experts such as

business analysts and architects as runtime models and adaptation rules and uses

them as a knowledge base for adaptation decisions. On the other hand, most of

∗

Contributed by Xin Peng.

1 Design and Engineering of Adaptive Software Systems 13

the software systems today can be treated as the so-called socio-technical systems,

in which human, hardware, and software components work in tandem to fulﬁll

stakeholder requirements [40]. Therefore, human factors are critical for the design

and engineering of adaptive software systems.

Human factors in an adaptive system can be understood and considered from

different perspectives. A human can act as an expert providing knowledge for

runtime adaptation decisions. A human can also be treated as a user, an agent, or

a component of an adaptive system. Human factors from these perspectives need

to be considered together with software techniques such as reconﬁgurable software

architectures when designing an adaptive system.

1.2.3.1 Human as Expert

In traditional software evolution, human experts such as business analysts and

architects make adaptation decisions based on their business and design knowledge.

Runtime adaptation can be regarded as the automation of human-directed adaptation

based on runtime representations of human knowledge. Some adaptive systems

even can have humans in the adaptation loop, where major changes are demanded

and require human approval or guidance [41]. Moreover, runtime adaptation often

involves both requirements and architectural decisions where different concerns

require different knowledge [13]. Considering human as expert, we need to capture

human knowledge at different layers as knowledge bases of runtime adaptation

and establish some kinds of multilayered control and feedback loops at runtime. A

difﬁculty of this multilayered loop lies in the complex interaction between different

layers. For example, if a problem (e.g., performance degradation) cannot be handled

by lower-layer adaptation, an adaptation request will be thrown to higher layers. On

the other hand, higher-layer adaptation actions need to be mapped to lower-layer

adaptation actions. This mapping involves complex traceability between different

layers (e.g., requirements and architecture).

1.2.3.2 Human as User

Online systems such as online shopping and games usually serve a large number

of users simultaneously. Each user in this kind of system has his own experience

on the system. And their preferences on quality attributes are usually different. For

example, a response time of 10 s is usually unacceptable for a young person doing

online shopping but may be good enough for an old person. From this perspective,

an adaptive system can plan the overall adaptation by considering personalized

experiences of different users. This can provide more ﬂexibility for system-level

adaptation decisions. For example, the system can allocate less resources for users

who are less sensitive to response time to ensure the satisfaction of more sensitive

users. Considering human as user, an adaptive system can learn user experience and

quality preference by implicitly monitoring user behaviors and feedback using HCI

剩余172页未读，继续阅读

THESUMMERE

粉丝: 23
资源: 328

构建自适应软件系统：动态环境下的工程挑战与方法

Software Engineering for Self-Adaptive Systems III. Assurances epub

近几年的软件工程的文献

design 3rd order Adaptive Torque Filter

iso 15622 - adaptive cruise control systems (accs)

principles of adaptive filters and self-learning systems

3rd order Adaptive Torque Filter

bad adaptive filter value

adaptive control bjorn 2nd

Adaptive stabilization filter

Adaptive Autosar与 autosar

基于preevision的autosar adaptive设计-上篇

Outcome-Adaptive Lasso的原始文献

不是使用opencv是让你用AdaptivePooling

adaptive lasso

adaptive autosar 和 linux 有什么关系

adaptive_filling 这个算子那个版本有

adaptive server anywhere8.0 服务器

lasagne的adaptive dropout方法

Unity adaptive performance 是什么

Outcome-Adaptive Lasso的R代码解读

最新资源