Centralize or Decentralize-A Requirements Engineering .ppt

《Centralize or Decentralize-A Requirements Engineering .ppt》由会员分享，可在线阅读，更多相关《Centralize or Decentralize-A Requirements Engineering .ppt（26页珍藏版）》请在麦多课文档分享上搜索。

1、Centralize or Decentralize? A Requirements Engineering Perspective on Internet-Scale Architectures,Eric YuUniversity 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 supportedNeed to collect fi

2、ne-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

3、forcesperformance 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 Req

4、uirements as evaluation criteria, ie. present an architectural solution then argue for its benefits (and drawbacks) with respect to these qualities/ attributesFor example Yimam Kobsa talk shows this approach is too coarse-grained for guiding design (first contrasts decent. and cent., then adopts hyb

5、rid.),From Yimam & Kobsa TWIST2000 presentation Analysis,Background,Alternatives,DEMOIR,First appr.,Summary,From Yimam & Kobsa TWIST2000 presentation Analysis (contd.),Background,Alternatives,DEMOIR,First appr.,Summary,To centralize or decentralize ?,Should first ask: What requirements are you tryin

6、g 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 so

7、urce 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 requiremen

8、ts occur at many places and at various stages during requirements analysis and system design decision-making processNeed systematic framework to support: managing large no. of requirements (Func. & Non-Func.) detecting & analyzing their interactions using requirements to guide exploration, pruning &

9、 evaluation of design alternatives dealing with change,Goal-Oriented Requirements Analysis,Treat requirements as Goals, refine and reduce until operationalized, taking interactions into accountChung Nixon Yu Mylopoulos 2000 Non-Func. Reqmts for SE, also CACM Jan. 99,From viewpoint of Goal-Driven Des

10、ign.,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

11、 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 Requi

12、rements-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

13、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

14、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 (contd),Methodologies for guiding the use of the framework, principl

15、es, techniques, etc., in various settingsTools 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 facili

16、ties (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

17、 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 t

18、echnical 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

19、.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 viewpoin

20、t 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 archi

21、tecture 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 domainsAlignments are sometimes intended, other times incidental usually imperfect

22、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, commit

23、ments. 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,Agent-Oriented Analysis (contd),Each actor pursues its own interests, while considering the consequences of its decision

24、s 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 localiz

25、ed spaces. Actors have limited knowledge about internal rationales of other actors.,Example: Smart Cards Detailed relationships from viewpoint of each player,Analyzing security & trust in deploying Smart Card technology,Figure 6: A Strategic Rationale model showing details of selected attacker roles

26、 and defender roles,Attack!,Defense!,One particular Smart Card deployment configuration: Phone company as Terminal Owner, Data Owner, Card Issuer, Card Manufacturer, and Software Manufacturer,When several roles are playedby the same player, some attacker-defender pairs disappear.,tools,Summary,Knowl

27、edge-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 toolsKey Challenges: collecting, organizing knowledge for system design (including various reasons for centralizing vs. decentralizing) Providing analysis and design support,