Centralize or Decentralize?
A Requirements Engineering
Perspective on Internet-Scale
Architectures
Eric Yu
University of Toronto
July 2000
Themes of this talk
• Architectural decisions are (should be) driven by
Requirements
 Need to make the linkages
• more explicit, and
• better supported
• Need to collect fine-grained design knowledge to
support systematic design
“Knowledge-based” approach





representational framework
analysis and design techniques
collections of design knowledge
methodologies
tools
Non-Functional Requirements*
• Designing large-scale systems involves tough tradeoffs
among many interacting forces









performance
cost
usability
reliability
security
maintainability
evolvability
time-to-market
...
* also called “-ilities”, Extra-Functional Requirements, Quality
Attributes, ...
“-ilities” are most often viewed as
evaluation criteria for architectures
• Most discussions of architectures take these
Requirements as evaluation criteria, ie.
 present an architectural solution
 then argue for its benefits (and drawbacks) with respect to
these qualities/ attributes
• For example…
 <most of the talks in this Workshop>
 [Yimam Kobsa] talk shows this approach is too coarse-grained
for guiding design (first contrasts decent. and cent., then
adopts hybrid.)
From [Yimam & Kobsa TWIST2000] presentation
Analysis
F acto r
A gen ts
A ggregated
L o ca lity (p ro cessing /loa d distribu tio n )
F acilitated
lim ited
M in ing p erso n al resou rces
easier
d ifficult
P erson al P riv acy p reserva tion
A t the h and o f the ex pert
A t the h and o f m ain tain er
S cala bility
R o b u stness (in fa ce o f
fa ilu re)
N o sing le po int o f failu re
S ingle point o f failure
(b acku p m ech anism s n eed ed )
E asy b y ad d ing n ew agen ts
D ep ends on design
C en tral a d m in istra tio n
No
Y es
E x p erts feelin g in co n tro l
Y es
M ostly n o t
Background
First appr.
Alternatives
DEMOIR
Summary
E x ten da bility
From [Yimam & Kobsa TWIST2000] presentation
Analysis (contd.)
F actor
Background
First appr.
Alternatives
DEMOIR
Summary
A gen ts
(alt 1)
A ggregated
(alt 2 )
O rga niza tion -w id e access to exp ertise
info.
L im ite d (e.g. to expert
netw ork, etc.)
fac ilitated
M ulti-p u rp ose/op tim al u tiliza tion of
exp er tise info (a n alysis, vis ualiza tion,
b row s ing, etc.)
S ources of exp ertise evid e nce m in ed
L im ite d
fac ilitated
M ostly lim ited to perso na l
resources
O rga nizatio na l resources
(repos ito ries, databases,
W eb/Interne t, etc.)
Q uery P erform a nce (scala b ility)
L ow (d ue to the need to
cons ult m a ny a ge nts)
H igh d ue to s ingle locatio n o f
inform atio n
K n ow le d ge-b ased /sta tistical
tec h niq ues su p p or t
poor
G ood
C oor d in ation over head
H igh (e.g. getting a ge nts
find a nd interact w ith o ne
anothe r)
low
To centralize or decentralize… ?
• Should first ask: What requirements are you trying to
address?
• Design question: Given the requirements, what are the
suitable solutions?
• Need to relate architectural solutions ---systematically to-->
requirements/ attributes
• then use them in the reverse direction during design
Examples:
 replication --> for speed of global access
 distribute data close to source or user --> for local processing
 redundancy --> for reliability
 centralized management --> to reduce mgmt costs
 single database --> to avoid inconsistencies
 fewer sites --> to reduce security exposure
• But need finer-grained reasoning
Need for Requirements Engineering
frameworks
• Tradeoffs among competing requirements occur at
many places and at various stages during
requirements analysis and system design
decision-making process
• Need systematic framework to support:
 managing large no. of requirements (Func. & Non-Func.)
 detecting & analyzing their interactions
 using requirements to guide exploration, pruning & evaluation
of design alternatives
 dealing with change
Goal-Oriented Requirements Analysis
• Treat requirements as Goals, refine and reduce until
operationalized, taking interactions into account
[Chung Nixon Yu Mylopoulos 2000 Non-Func. Reqmts for SE],
also CACM Jan. 99
Security[Ticket Info]
Availability
[Ticket Info]
Costs
[Ticket
System]
Scalability
[Ticket
System]
-
Reliability
[Ticket Info
Processing]
...
Fault Tolerant
Processor
[Ticket Info
Processor]
Confidentiality[Ticket Info]
Integrity
[Ticket Info]
Tamper
Resistant
[Ticket Info
Processing]
Redundant
Disk Array
[Ticket Info
Storage]
...
Confidentiality
[Ticket Itinerary
Info]
...
Trusted Personnel
[Ticket Itinerary Info]
Confidentiality
[Ticket Payment
Info]
...
Bonded Personnel
[Ticket Payment Info]
From viewpoint of Goal-Driven Design...
• Centralize vs. Decentralize
 refer to broad classes of design techniques or design patterns
that have been invented over the years in a number of design
areas
•
•
•
•
•
transaction processing performance
long-term storage
system availability
security
management functions
• Specific techniques for addressing each of these may
have classes of solutions that are centralized or
decentralized
• Each technique tends to address one primary
requirement, but typically have impacts on other
requirements. Need systematic support to discern,
clarify, analyze the interacting issues
Knowledge-Based Approach for
Requirements-Driven Design
• A representational framework (notations, models,
languages, ontologies) - expressive enough to deal with the
subject matter: reqmts, elaboration steps, design techniques,
design steps and process, alternatives, relationships, etc.
• Analysis and Design techniques that make use of the
semantics of the modelling constructs to support the engineering
activities,eg. analyzing interactions among reqmts, generating
design options, evaluating implications of design alternatives,...
• Collections of reusable design knowledge (KhBs) from
case studies to generic knowledge eg. common types of
requirements and their possible elaboration, design principles,
methods, rules, techniques, patterns of solutions to common
design problems, architectures, frameworks, etc.
Knowledge-Based Approach for
Requirements-Driven Design (cont’d)
• Methodologies for guiding the use of the framework,
principles, techniques, etc., in various settings
• Tools that use the structure & semantics of the knowledge to
automate some aspects of the engineering activities, eg.
visualization, animation, simulation, verification, support for
reasoning (qualitative, quantitative, case-based…) and basic
management facilities (maintaining design history, traceability,
navigation, query, retrieval, version & change management…)
Example: telecom software product
Detailed design reasoning in software architecture
• task-decomposition
• means-ends
• contributions to softgoals
Requirements and
Organizational Issues
• Requirements comes from many quarters
 in user organization
• various kinds of users,
• operations personnel
• management ...
 in development organization
•
•
•
•
•
developers
product managers
project managers
quality assurance
marketing …
• Tradeoffs involve negotiations among stakeholders
(e.g., [Boehm])
• Organizational issues affect technical decisions in
significant ways (e.g., [Conway])
For Internet-scale systems…
organizational issues even more complex
• Many distinct economic and legal entities involved in
the development, use, and management
• Each player has its own interests to pursue
• No single overview, or even understanding (e.g., new
functionality being added via plug-&-play)
• Centralize vs. Decentralize question applies to
technical as well as organizational domains
Many ways of dividing up the scope
of control at various levels
• ownership domains
• administrative and business management domains
• trust domains, from viewpoint of each (class of)
stakeholder:
 application providers, network operators, user organizations,
end-users, intermediaries
• developer domains - div. of responsibilities in
development
• operations management domains - e.g., failure
recovery, performance optimization, load balancing,
etc.
• technical architecture domains at various levels subsystems, components, modules
Domains have intertwined
relationships
• For example,
 trust domains may coincide with administrative domains
 ownership domains may overlap with design domains
• Alignments are
 sometimes intended, other times incidental
 usually imperfect
 restructured (or may drift) over time.
• Complex organizational issues => need extended
ontology
 goal-oriented --> agent-oriented
Agent-Oriented Analysis
• Intentional actor as a modelling abstraction to deal
with locality and distribution at an intentional level.
• Actors have goals, beliefs, abilities, commitments.
• Actors depend on each other for goals to be achieved,
tasks to be performed, and resources to be furnished.
Example: Smart Cards
Some basic relationships among stakeholders
LEGEND
Actor
Resource Dependency
Agent-Oriented Analysis (cont’d)
• Each actor pursues its own interests, while
considering the consequences of its decisions and
actions because of its relationships with other actors.
• The deliberations of each actor is modelled
analogously to the goal-graph structure of NFR
framework.
• The design space is carved up into many localized
spaces.
• The intentional relationships among actors define the
interfaces among localized spaces.
• Actors have limited knowledge about internal
rationales of other actors.
Example: Smart Cards
Detailed relationships from viewpoint of each player
LEGEND
Analyzing security & trust in deploying Smart Card technology
One particular Smart Card deployment configuration: Phone company as
Terminal Owner, Data Owner, Card Issuer, Card Manufacturer, and Software
Manufacturer
tools
Summary
• Knowledge-based approach to SE
 representational framework - Goals and Agents as key
constructs in the ontology
 analysis and design techniques
 collections of design knowledge
 methodologies - Requirements-Driven
 tools
• Key Challenges:
 collecting, organizing knowledge for system design
(including various reasons for centralizing vs. decentralizing)
 Providing analysis and design support
Descargar

Stability and Change in Organizing Knowledge for