Transcript Towards “Good-enough” Autonomic Computing Architectures: A

Towards “Good-enough”
Autonomic Computing Architectures:
A Goal-Oriented Approach
Lawrence Chung
The University of Texas at Dallas
Autonomic Computing:
A Requirements View
“A smart machine should
(1)
(2)
understand the tasks to be performed,
perform the required tasks, and
(3)
manage itself with the goal of staying available and performing
efficiently. “ [Hong et. al]

Functional requirements – what the system should do
- task-oriented
Non-Functional Requirements – properties the system should
have in doing what the system should do
- availability, efficiency, stability, sustainability, security, usability,
reconfigurability, interactivity, survivability, evolvability, adaptability,
…

Autonomic Computing:
An Architectural View
• Architectual design space potentially huge
Mapping requirements into architectural constituents:







Components – Process, Data, Control, Resource, etc. – what, how many
Connections – explicit, implicit, #param, …, RPC, Messages, MOMs, etc. – what, how many
Constraints – dependencies among components, (de-)activation conditions, etc.,
Patterns – structural, behavioral, etc.
Styles – OO, Imp. Invocation, Pipe&Filter, …
Rationale – why the particular architectual solution
Infrastructure – J2EE/.NET/CORBA/…
Is a decision-making process.
Autonomic computing architecture ~
only as good, or bad, as the development decisions!
Autonomic Computing:
A Goal-Oriented Approach
“… manage itself with the goal of staying available
and performing efficiently…” [Hong et. Al]








Requirements as Goals
o
Functional Requirements as Hardgoals
o
Non-Functional Requirements as Softgoals
Refinements of Goals
Analysis of Goal Conflicts and Synergies
Exploration of Satificing Design Solutions [Simon]
Analysis of Tradeoffs through Correlations
Evaluation of Goal Satificing
Traceability
Use of Repository of reusable knowledge
Adaptability: A Key Success Factor
“Autonomic computing systems have the ability to manage themselves.
And to dynamically adapt to changes in business policies and objectives…”
http://www.ibm.com/autonomic/pdfs/WAS_AC_WhitePaper.pdf
Adaptability is the ability of software systems to
accommodate changes in their environment.
Environment
Software System
Environment: OS, hardware platform, heat, noise, speed, number of interrupts,
vibration, power, attenuation, new commands, etc.
Why Adaptability?
•
•
•
Easier to develop systems satisfying new
requirements
Facilitates addition of new software
features
Saves maintenance costs
Staying useful
•
Survival of the fittest!
•
Examples of Adaptable Systems
• Dual-mode cell phone
• Dynamic uploading of firmware
• Command-processing system accepting commands of
different versions
• A software system operating on different OS
• Performing system maintenance functions when the
system is least busy
• A dynamically changeable format - from 2 digit year to 4
digit year; change units of measurement
• Mars Pathfinder project
• eLiza project at IBM
Representation and Reasoning
• Softgoal Interdependency Graph (SIG)
Adaptability[System]
NFR Softgoal
Design (or Operationalizing)
Softgoal
Claim Softgoal
EnvChangeRecognition
SysChangeRecognition
[System]
[System]
SysChange
[System]
++
or
+
or
-
or
--
++
--
Strongly Positively Satisficing or
MAKE Contribution
Positively Satisficing or
HELP Contribution
Negatively Satisficing or
HURT Contribution
Strongly Negatively Satisficing or
BREAK Contribution
or
Correlation
AND Contribution
Claim1
Claim2
OR Contribution
Controller
!
Example SIG
Criticality
Legend
Autonomic Computing:
Towards A Society of Collaborating Agents
• Shift in paradigm
– From OO to GO (& AO) modeling
– From Distributed to Collaborative computing
• Collaborative Infrastructure
– J2EE/.Net/CORBA/… not enough
– From non-intentional (OO) to intentional (GO) middleware
– From non-social to social (AO) middleware