towards requirements-driven autonomic systems design

May 1-2, 2005 DEAS’05 May 21, 2005

Towards Requirements-Driven Autonomic Systems Design

Alexei LapouchnianSotirios LiaskosJohn Mylopoulos

Yijun Yu

May 21, 2005

May 1-2, 2005 DEAS’05 May 21, 2005

Overview

1. Autonomic Computing

2. Goal-Oriented Requirements Engineering

3. From Requirements to High-Variability Designs

4. Towards Autonomic Computing Systems

5. Conclusion

May 1-2, 2005 DEAS’05 May 21, 2005

1. Autonomic computingIT industry challenges:

Software Systems Complexity Software maintenance costs dominate

Autonomic Computing:

Move most of maintenance complexity into the software Self-management/adaptation (self-configuration, self-

protection, self-healing, self-optimization)

May 1-2, 2005 DEAS’05 May 21, 2005

Building AC SystemsThree ways to make a system autonomic:

1. Design the system to support a space of possible behaviours (our approach)System has many possible configurations built itAbility to select the most appropriate configuration

2. Make a system multiagentComposed of intelligent agentsSocial interactions, planning, etc.Dynamic system composition/configuration

3. Use evolutionary approaches

May 1-2, 2005 DEAS’05 May 21, 2005

Building AC SystemsThree ways to make a system autonomic:1. Design the system to support a space of

possible behaviours (our approach)System has many possible configurations built itAbility to select the most appropriate configuration

To make this possible we need:Concepts to analyze large spaces of

alternative behaviours/configurations

May 1-2, 2005 DEAS’05 May 21, 2005

2. Goal-Oriented REEarly Requirements

Identify stakeholdersGoals of stakeholders

Identify system goals – functional requirementsUse Goal Models to:

Refine system goals (AND/OR refinements) into tasksModel Non-Functional (quality) Requirements (NFRs)

→ SoftgoalsModel correlation among goals and softgoals to rank

alternatives [HLM03]

May 1-2, 2005 DEAS’05 May 21, 2005

3. Capturing Variability

A key aspect in the design of autonomic systems is that the system must adapt its behavior to the changes in its environment

It is beneficial to identify and implement many alternative behaviours

Alternative ways to solve a problem are captured by the OR decompositions in goal models

Alternatives in the goal model capture variability in the problem domain Variability in problem domain must be reflected in the solution

domain as alternative configurations, behaviors and structures

May 1-2, 2005 DEAS’05 May 21, 2005

Meeting scheduler example

Schedule meeting

Collect timetables

Choose schedule

By Person By System

Manually Automatically

Minimal effort

Collection effort

Matching effort

Good quality schedule

Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

VP1 VP2

VP3

May 1-2, 2005 DEAS’05 May 21, 2005

Toward High-Variability Designs

Variability in problem domain must be reflected in the solution domain as alternative configurations, behaviors, structures, concerns, etc.

1. Configuration variability: feature models in the product-line family software

2. Behavioral variability: transitional systems typically statecharts

3. Structural variability: components compositions patterns in software architectures

4. Concerns variability: aspect-oriented compositions

5. … and so on so forth …

May 1-2, 2005 DEAS’05 May 21, 2005

Converting Goal Models Into Feature Models

Schedule meeting

Collect timetables

Choose schedule

By Person By System


Minimal effort

Collection effort

Matching effort


Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

Schedule meeting

Collect timetables

Choose schedule

By System Automatically

Collect from Agents

Request from Users

+conflicts [minimal disturbances]+conflicts [accurate constraints]

Send Request

Receive Response

VP1 VP2

VP3

May 1-2, 2005 DEAS’05 May 21, 2005

Converting Goal Models Into Statecharts

Schedule meeting

Collect timetables

Choose schedule

By Person By System


Minimal effort

Collection effort

Matching effort


Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

Schedule meeting

...

Choose schedule

[VP1=2]

May 1-2, 2005 DEAS’05 May 21, 2005

Converting Into ADLMeeting Scheduler

Constraint CollectionModule

Constraint RequestServer

CommunicationModule

Slot Calculator

SchedulingMgr

ICollectConstr

RequestCnstr

Automatic Collection

Constraint Input UI

IGetConstraints

IScheduleMeeting

Prepare UI IPrepare

ISelectSlotAuto

Find Address

Request Instant

Messaging

IFindUserAddr

VP1

Request Mailer

VP3

VP4

ICommunicateReqs

PriorityBased

Algorithm

TravelCostMinimization

Algorithm

ConflictsMinimization

Algorithm

Schedule meeting

Collect timetables

Choose schedule

By Person By System


Minimal effort

Collection effort

Matching effort


Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

May 1-2, 2005 DEAS’05 May 21, 2005

Light-weight Enrichments

• Goal models in the AND/OR graph form need to be enriched with design-specific information to transform into a high-variability design

• Such enrichments are light-weight: minimal information to derive the design

• Keeping the traceability among the variabilities is crucial to the design of AC systems

May 1-2, 2005 DEAS’05 May 21, 2005

4. Towards AC Systems: Autonomic Elements

Autonomic Element (AE) – basic building block of AC systems Its behaviour and its relationships with other AEs are “driven by

goals that its designer embedded in it” [KC03] AE manages itself to deliver its service in the best

possible way Monitor its managed element(s) Analyze data and diagnose the problem Plan course of action Execute

Overall self-management of the system results from internal self-management of its AEs

May 1-2, 2005 DEAS’05 May 21, 2005

How Goal Models Can Help

1. Goal models provide a means to represent many ways in which the objectives of the system can be met and analyze/rank these alternatives with respect to stakeholder quality concerns This allows for exploration and analysis of

alternative system behaviours at design time Can lead to more predictable and trusted AC

systems If predefined alternatives perform well, there is no

need for complex social interactions among AEs

May 1-2, 2005 DEAS’05 May 21, 2005


2. Goal models can be used to support traceability b/w AC system design and requirements Easy to see how some particular goal is

decomposed and assigned to components/AEs

Easy to determine how a failure of an AE affects the overall goal of the system

May 1-2, 2005 DEAS’05 May 21, 2005


3. Goal models provide a unifying intentional view of the system by relating goals assigned to individual autonomic elements to high-level system objectives and quality concerns Helps in achieving globally optimal

behaviour

May 1-2, 2005 DEAS’05 May 21, 2005

A Hierarchical Autonomic Architecture (HAA)

A hierarchy of AEs that is structurally to the goal hierarchy of the corresponding goal model Each goal in the goal model is the responsibility of

one AE Managed elements of the leaf-level AEs are the

actual components/resources Higher-level AEs orchestrate lower-level AEs The root AE represents the whole system Communication channels b/w parent/child AEs for

control/monitoring information exchange

May 1-2, 2005 DEAS’05 May 21, 2005

The Knowledge of AE (1) The goal that its achieving How this goal is achieved – the decomposition

of the goal Information on monitored/controlled

parameters of its sub-AEs Success/failure metrics Various strategies etc. The core of the knowledge is the properly

enriched goal model

May 1-2, 2005 DEAS’05 May 21, 2005

The Knowledge of AE (2)

May 1-2, 2005 DEAS’05 May 21, 2005

Benefits of HAA Partitioning of high-variability design space into

lower-variability subspaces Easy composeability of AEs and AC systems Straightforward propagation of high-level concerns

from the room AE down to leaf-level elements Straightforward propagation of diagnostic

information from low-level AEs to high-level elements

In case of an AE failure: easy identification of affected AEs and goals

May 1-2, 2005 DEAS’05 May 21, 2005

Example: Propagating High-level Concerns Down

1. The root AE receives a high-level policy

2. It acts on the policy by determining which available alternative fits the policy best

3. Produce new policies for its children AEs

4. Pass these policies down to them

5. …

6. Leaf-level AEs tune their managed elements in accordance with the policies received from their parent AEs

Note: Each AE retains the freedom to achieve its goal in the way it sees fit provided that it satisfies the policy set by its parent AE

May 1-2, 2005 DEAS’05 May 21, 2005

Example: Handling AE failures

1. An AE “A” detects that its goal is not being achieved by the selected system configuration

2. It determines if it can correct the situation by switching to an alternative behaviour by either: Modifying the configuration parameters of its managed AE Switching to alternative AE provided that one exists (e.g., if

there is OR decomposition for “A”s goal)

3. If no corrective action can be performed, the parent AE of “A” is notified

Benefits: Failures are handled as early as possible Goal model is used to locate the failure and

determine if alternative configurations are available

May 1-2, 2005 DEAS’05 May 21, 2005

Using Goal-Based Reasoning in AC Systems

AC systems frequently need to: Determine if the current alternative satisfies

functional and non-functional requirements Predict if a potential alternative satisfies the

requirements Given changes in user goals/preferences,

find the best way to satisfy the new requirements.

Top-down [SJM04] and buttom-up [GMN02] goal reasoning approaches can be used to support these activities.

May 1-2, 2005 DEAS’05 May 21, 2005

5. Conclusion and Future Work We presented a requirements-driven approach for

designing autonomic systems Goal models are used to represent and analyze a space

of possible behaviours of software systems Possible to generate design-views preserving the

problem domain variability Proposed a hierarchical autonomic architecture based on

requirements goal models

Future Work: Generation of autonomic infrastructure from goal models Application and validation of our approach in several

areas: medical domain, business systems.

May 1-2, 2005 DEAS’05 May 21, 2005

References (1)• Autonomic Computing systems

– J. Kephart and D.M. Chess. “The vision of autonomic computing”. IEEE Computer Journal. 36(1):41-50. 2003.

• goal-oriented requirements engineering– A. van Lamsweerde. “From systems goals to software architectures”. FSE. 2004.– L. Chung, B.A. Nixon, E. Yu, J. Mylopoulos. Non-functional requirements in software

engineering. Kluwer Academic Press. 1999.• goal-oriented software configuration

– B. Hui et al. “Requirements analysis for customizable software: goals-skills-preferences farmework”, RE’03.

– S.Liaskos et al. “Configuring common personal software: a requirements-driven approach”. To appear, RE’05.

• goal-oriented software tuning– Y.Yu et al. “Software refactoring guided by multiple soft-goals”, REFACE@WCRE’03.

• quality-driven software reengineering– Ladan Tahvildari, Kostas Kontogiannis, John Mylopoulos: “Quality-driven software re-

engineering”. Journal of Systems and Software 66(3): 225-239 (2003)• quality-based software reuse

– J.C.Leite, et al. “Quality-based software reuse”, CAiSE’05.• reverse engineering goal models

– Y.Yu, et al. “From goals to aspects: discovering aspects from requirements goal models”. RE’04.

– Y.Yu et al. “Reverse engineering goals from source code”, to appear, RE’05.– S.Liaskos et al. “Configuring common personal software: a requirements-driven approach”. To

appear, RE’05.

May 1-2, 2005 DEAS’05 May 21, 2005

References (2)On High-variability software design

• Feature model and product-line family:– K.C. Kang et al. “Feature-oriented domain analysis (FODA) feasibility study”,

SEI. 1990.– K. Czarnecki et al. Generative Programming: Methods, Tools, and Applications.

Addison-Wesley, 2000.– D. Batory et al. “Scaling Stepwise Refinements”. ICSE 2003.

• Statecharts– D. Harel. “The STATEMATE Semantics of Statecharts”. TOSEM 5(4):293—333.

• Software architectures and ADL– L. Bass et al. Software Architecture in Practice, 2nd Ed. Addison-Wesley, 1998.

• Aspect-oriented programming– G. Kiczales. “Aspect-oriented programming”. EOOP. 1997.– C. Zhang et al. “Just-in-time middleware configuration using aspects”. AOSD’05.

May 1-2, 2005 DEAS’05 May 21, 2005

3.1b For configuring variability

Schedule meeting

Collect timetables

Choose schedule

By Person By System Manually Automatically

Send Request

Receive Response

OR OR OROR

AND AND

AND AND

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -+-

NOPNOP |

VP1 VP2

VP3

Schedule meeting

Collect timetables

Choose schedule

By Person By System


Minimal effort

Collection effort

Matching effort


Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

May 1-2, 2005 DEAS’05 May 21, 2005

3.2b For behavioral variability

Schedule meeting

Collect timetables

Choose schedule

By Person By System


Minimal effort

Collection effort

Matching effort


Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

Schedule meeting

Collect timetables Choose

schedule

By Person

By System


Send Request

Receive Response

OR OROROR

AND AND

AND AND

Collect from Users

Collect from Agents

OROR

NOPNOP

;

;

VP1

VP2

VP3

||

|

May 1-2, 2005 DEAS’05 May 21, 2005

3.3b For structural variability

Schedule meeting

Collect timetables

Choose schedule

By Person By System


Minimal effort

Collection effort

Matching effort


Minimal conflicts

Good participation

Send Request

Receive Response

OROR

OROR

AND

AND

AND

AND

AND AND

AND

AND

+

-

- +++-

-

Collect from Users

Collect from Agents

OROR

AccurateConstraints

MinimalDisturbances

+ -

+-

Schedule Meeting

Request Constraints

Collect Constraints

AND

OR

Select Slot

AND

Read Maintained Constraints

ORReceive Constraints

AND

PrepareAND

Find User Address

AND

Communicate Request

AND

;

;

Automatically/ Randomly

Manually

OROR

Get Users

Get Interval

ANDAND

||

|VP1

I: -O: UserSet

I: -O: Interval

system

I: UserO: Address

NOP

I: Address, IntervalO: -

I: UserSet, IntervalO: ConstraintSet

I: User, IntervalO: UserConstraints



I: ConstraintSetO: MeetingTime


I: -O: MeetingTimeI: -

O: Interval, UserSet

VP4

Instant Messaging

Email

OROR

I: Address, MessageO: -

I: Address, MessageO: -

Priority Oriented

Travel Cost Minimization

Conflict Minimization

OR

OR

OR




VP2

VP3

|

|

|

May 1-2, 2005 DEAS’05 May 21, 2005

3.1c From goal to feature

f1

f2 f3

f1

f2

f1

f2 f3

f1

f2 f3

mandatory optional alternative or

g1

g2 g3

AND AND

g1

g2 NOP

OR OR

g1

g2 g3

OR OR

g1

g2 g3

OR OR|

(A) (B) (C) (D)

May 1-2, 2005 DEAS’05 May 21, 2005

3.2c From goal to state

g

g1 g2

AND AND

g11 g12 g21 g22

AND AND AND AND|| ||

g

g1' g2'AND AND

g21 g12 g11 g22

AND AND AND AND

||

;;

(1) (2)

/action

/action

/action

/action

(1) (2)

Q Goal: name FormalDef: P=> Q

[P]/name

Q Goal: name FormalDef: P=> Q

(a)

(b) [P]/name

g

g1 g2

g1 g2

g

g1 g2

g

g1 g2

g1

g2

AND AND; || |AND AND OROR

g

g1 g2

g1

g2

OROR

(1) (2) (4) (5)

g

g1 g2

AND AND

(3)

g1

g2

g1 g2

1. Defining states 3. Transforming hierarchies

2. Treating dependencies 4. Simplifying leaf statecharts

May 1-2, 2005 DEAS’05 May 21, 2005

3.3c From goal to interfacesg

g1 g2

OR OR

I: i1,i2O: o1,o2

I: i1,i2O: o1,o2

I: i1,i2O: o1,o2

interface type I0{ G(IN i1, IN i2 OUT o1, OUT o2);}

I0

I0 I0

g

g1 g2

I: i1,i2O: o1,o2

I: i21,i22O: o21,o22

I: i11,i12O: o11,o12

interface type I0{ G(IN i1, IN i2, OUT o1, OUT o2);}Interface type I1 { G1(IN i11, IN i12, OUT o11, OUT o12);}Interface type I2 { G2(IN i21, IN i22, OUT o21, OUT o22);}

I1I2

AND AND

I0

towards requirements-driven autonomic systems design

Documents