质量属性.ppt

Software Architecture Wang hunan Date1Software Architecture 4: Creating an Architecture: Understanding Quality Attributes Date2Software Architecture *3 Topics lFunctionality and Architecture lArchitecture and Quality Attributes lSystem Quality Attributes lQuality Attribute Scenarios in Practice lOther System Quality Attributes lBusiness Qualities lArchitecture Qualities lExercise Date3Software Architecture *4 Functionality and Architecture lFunctionality and quality attributes are orthogonal lFunctionality may be achieved through the use of any of a number of possible structures. lfunctionality is largely independent of structure. lSoftware architecture constrains its allocation to structure when other quality attributes are important. Date4Software Architecture * Architecture and Quality Attributes lAchieving quality attributes must be considered throughout design, implementation, and deployment. lUsability involves both architectural and nonarchitectural aspects. lModifiability is determined by how functionality is divided (architectural) and by coding techniques within a module (nonarchitectural). lPerformance involves both architectural and nonarchitectural dependencies. Date5Software Architecture * quality attributes can never be achieved in isolation. lsecurity and reliability often exist in a state of mutual tension lPoints of failure lalmost every quality attribute negatively affects performance Date6Software Architecture * Quality Attributes lQualities of the system. lavailability, lmodifiability, lperformance lsecurity, ltestability, lusability. lBusiness qualities lArchitecture qualities Date7Software Architecture * Three problems for Design Architecture lThe definitions provided for an attribute are not operational. lA focus of discussion is often on which quality a particular aspect belongs to. lEach attribute community has developed its own vocabulary. lThe performance community has “events“ arriving at a system, lthe security community has “attacks“ arriving at a system, lthe availability community has “failures“ of a system, lThe usability community has “user input.“ Date8Software Architecture * Quality Attribute Scenario lA quality attribute scenario is a (Testable) quality -attribute-specific requirement. Date9Software Architecture * general scenarios and concrete scenarios lgeneral quality attribute scenarios (general scenarios)those that are system independent and can, potentially, pertain to any system; lconcrete quality attribute scenarios (concrete scenarios)those that are specific to the particular system under consideration. Date10Software Architecture *11 Availability Scenario lAvailability general scenarios Date11Software Architecture *12 Sample availability scenario lConcrete scenarios play the same role in the specification of quality attribute requirements that use cases play in the specification of functional requirements. Date12Software Architecture Example: 刺激源 刺激 制品 响应 响应度量 环境 荨蔴 疼痛 手 正常状态 缩手 在0.1s内 完成缩手 Date13Software Architecture *14 QUALITY ATTRIBUTE SCENARIO GENERATION la systems quality attribute requirements are seldom elicited and recorded in a disciplined way. lremedy this situation by generating concrete quality attribute scenarios. lquality-attribute-specific tables: general scenarios, checklist Date14Software Architecture * Topics lFunctionality and Architecture lArchitecture and Quality Attributes lSystem Quality Attributes lQuality Attribute Scenarios in Practice lOther System Quality Attributes lBusiness Qualities lArchitecture Qualities Date15Software Architecture * Quality Attribute Scenarios in Practice lAvailability, lModifiability, lPerformance lSecurity, lTestability, lUsability. Date16Software Architecture * AVAILABILITY lAvailability is concerned with system failure and its associated consequences. l A system failure occurs when the system no longer delivers a service consistent with its specification. lSuch a failure is observable by the systems userseither humans or other systems. lWe need to differentiate between failures and faults. Date17Software Architecture *Software Architecture: Module 118 Availability General Scenario Generation Date18Software Architecture *19 Availability General Scenario Generation (Cont.) Date19Software Architecture * MODIFIABILITY lModifiability is about the cost of change. lWhat can change (the artifact)? lthe functions, the platform, the environment, the qualities, and its capacity etc.). lWhen is the change made and who makes it (the environment)? limplementation , during compile, during build (by choice of libraries), during configuration setup, or during execution (by parameter setting). Date20Software Architecture *Software Architecture: Module 121 Modifiability General Scenario Generation Date21Software Architecture * Sample modifiability scenario Date22Software Architecture * PERFORMANCE lPerformance is about timing. lperformance is concerned with how long it takes the system to respond when an event occurs. lthe number of event sources and arrival patterns make performance complicated. lAn arrival pattern for events may be characterized as either periodic or stochastic. Date23Software Architecture *Software Architecture: Module 124 PERFORMANCE Date24Software Architecture * Sample performance scenario Date25Software Architecture * SECURITY lSecurity is a measure of the systems ability to resist unauthorized usage while still providing its services to legitimate users. Date26Software Architecture * Security Characterized 1. Non repudiation 认可 is the property that a transaction (access to or modification of data or services) cannot be denied by any of the parties to it. 2. Confidentiality机密性 is the property that data or services are protected from unauthorized access. 3. Integrity完整性 is the property that data or services are being delivered as intended. 4. Assurance保证 is the property that the parties to a transaction are who they purport to be. 5. Availability可用性 is the property that the system will be available for legitimate use. 6. Auditing审核 is the property that the system tracks activities within it at levels sufficient to reconstruct them. Date27Software Architecture * Security General Scenario Generation Date28Software Architecture * Security General Scenario Generation (Cont.) Date29Software Architecture * Security General Scenario Generation (Cont.) lResponse lAuthenticates user; lhides identity of the user; lblocks access to data and/or services; l allows access to data and/or services; lgrants or withdraws permission to access data and/or services; lRecords access/modifications or attempts to access/modify data/services by identity; l stores data in an unreadable format; lrecognizes an unexplainable high demand for services, and informs a user or another system, and restricts availability of services Date30Software Architecture * Security General Scenario Generation (Cont.) lResponse Measure lTime/effort/resources required to circumvent security measures with probability of success; lprobability of detecting attack; lprobability of identifying individual responsible for attack or access/modification of data and/or services; lpercentage of services still available under denial- of-services attack; lrestore data/services; lextent to which data/services damaged and/or legitimate access denied Date31Software Architecture * Sample security scenario Date32Software Architecture * TESTABILITY lSoftware testability refers to the ease with which software can be made to demonstrate its faults through (typically execution-based) testing. lAt least 40% of the cost of developing well- engineered systems is taken up by testing. If the software architect can reduce this cost, the payoff is large. Date33Software Architecture * Testability General Scenario Generation Date34Software Architecture * Testability General Scenario Generation (Cont.) Date35Software Architecture Sample of Testability scenario l场景样例：单元测试人员在一个已完成 系统组件上执行单元测试 刺激源： 刺激： 制品： 响应： 响应度量： 环境： 单元测 试人员 执行单 元测试 系统中 的组件 在组件 完成时 组件具有控 制行为的接 口并且组件 的输出是可 观察的 在3小时内 测试了85% 的路径 Date36Software Architecture * USABILITY lUsability is concerned with how easy it is for the user to accomplish a desired task and the kind of user support the system provides. lLearning system features. lUsing a system efficiently. lMinimizing the impact of errors. lAdapting the system to user needs. lIncreasing confidence and satisfaction. Date37Software Architecture *Software Architecture: Module 138 Usability General Scenario Generation Date38Software Architecture *Software Architecture: Module 139 Usability General Scenario Generation (Cont.) Date39Software Architecture * Sample usability scenario Date40Software Architecture *Software Architecture: Module 141 COMMUNICATING CONCEPTS USING GENERAL SCENARIOS Date41Software Architecture * Other System Quality Attributes lcaptured other Quality Attributes in six scenarios lscalability is captured by modifying system capacitythe number of users supported, for example. l Portability is captured as a platform modification. lit is reasonable to create your own general scenario for some Quality Attribute linteroperability Date42Software Architecture * Business Qualities lTime to market. lCost and benefit. lProjected lifetime of the system. lTargeted market. lPlatform, feature, products line lRollout schedule. lIntegration with legacy systems. Date43Software Architecture * Sample: Time to market scenario 刺激源： 刺激： 制品： 响应： 响应度量： 环境： 市场竞争 加快开发 开发 组织 正常开 发中 尽量使用 已有技术 使用