Upload
vernon-beasley
View
15
Download
0
Embed Size (px)
DESCRIPTION
Towards Requirements-Driven Autonomic Systems Design. Alexei Lapouchnian Sotirios Liaskos John Mylopoulos Yijun Yu. May 21, 2005. Overview. Autonomic Computing Goal-Oriented Requirements Engineering From Requirements to High-Variability Designs Towards Autonomic Computing Systems - PowerPoint PPT Presentation
Citation preview
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
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
+ -
+-
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
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
+ -
+-
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
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
+ -
+-
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
How Goal Models Can Help
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
How Goal Models Can Help
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
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
+ -
+-
May 1-2, 2005 DEAS’05 May 21, 2005
3.2b For behavioral variability
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
+ -
+-
Schedule meeting
Collect timetables Choose
schedule
By Person
By System
Manually Automatically
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
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
+ -
+-
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: UserSet, IntervalO: ConstraintSet
I: UserSet, IntervalO: ConstraintSet
I: ConstraintSetO: MeetingTime
I: ConstraintSetO: MeetingTime
I: -O: MeetingTimeI: -
O: Interval, UserSet
VP4
Instant Messaging
OROR
I: Address, MessageO: -
I: Address, MessageO: -
Priority Oriented
Travel Cost Minimization
Conflict Minimization
OR
OR
OR
I: ConstraintSetO: MeetingTime
I: ConstraintSetO: MeetingTime
I: ConstraintSetO: MeetingTime
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