打造高质量的软件系统设计(第13部分：关注品质特性)

1. 软件架构 Software Architecture

1. 软件架构是结构和系统结构，包含了软件元素、这些组件的外部可视化属性以及他们之间的关系。Software Architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of these components, and the relationship among them.(In pratice书中的定义)
2. 单独的盒式模型不是架构，但是是一个开始的点 Box-and-line drawings alone are not architecture, but a starting point.
3. 架构包含了组件的行为 Architecture includes behaviour of components.

1.1. 架构扮演的角色 Role of Architecture

1. 架构是代表决定如何实现需求的决策的第一批人工制品。作为早期设计决策的体现，架构代表了那些最难更改的设计决策，因此值得最仔细的考虑 An architecture is one of the first artefacts that represents decision on how requirements are to be achieved. As the manifestation of early design decisions, the architecture represents those design decisions that are hardest to change and hence deserve the most careful consideration.
2. 架构是成功完成产品线工程，与独立开发每个系统相比，以较少的工作量，成本和风险来有序地开发一系列相似系统的关键要素 An architecture is the key artefact in achieving successful product line engineering, the disciplined development of a family of similar system with less effort, expense, and risk than developing each system independently.
3. 当有人开始在系统上工作时，架构通常是首先要检查的设计工件 An architecture is usually the first design artefact to be examined when someone starts working on a system.
4. 软件架构为维护和修改决策提供了参考框架 Software architecture provides a framework of reference for maintenance and modification decisions.

1.2. 为什么软件架构是重要的 Why is software architecture important?

1. 软件架构提供了沟通的工具 Software architecture provides a vehicle for communication

1. 软件架构是一个可以确定和谈判利益冲突的参考框架 It is a frame of reference in which competing interests may be identified and negotiated

1. 和用户讨论需求 Negotiating requirements with users
2. 保证客户获取到过程和成本的信息 Keeping customer informed of progress, cost etc.
3. 实现决策和分配的管理 Implementing management decisions and allocations.

2. 软件架构表现了最早期的决策集合 Software architecture manifests the earliest set of design decisions

1. 约束着实现和开发者 It constraints the implementation and developers

1. 实现必须要符合架构 Implementation must contorm to architecture
2. 资源分配的决策约束着单独模块的实现 Resource allocation decisions constrain implementations of individual components

3. 表现了早期的设计决策 Manifestation of early design decisions

1. 软件架构体现为了开发和维护工作的组织结构 Software architecture dictates organisational structure for development & maintenance efforts, e.g.

1. 划分为团队 Division into teams
2. 预算，计划单位 Units for budgeting, planning
3. 基础的工作拆分架构 Basis of Work Breakdown Structure
4. 文档的组织 Organisation for documentation
5. CM库的组织 Organisation for CM libraries
6. 集成的基础 Basis of integration
7. 测试计划、测试的基础 Basis of test plans, testing
8. 运维的基础 Basis of maintenance

4. 架构促进/阻碍质量属性的实现，比如灵活性、安全性、易用性 Architecture facilitates/ hinders achievement of quality attributes, e.g.modifiability, security, usability etc.
5. 架构会影响质量，但由于涉及许多其他因素，因此可能无法保证质量。Architecture influences qualities, but may not guarantee them as there are a number of other factors involved.
6. 架构引发有关潜在变更的讨论(系统的80％的工作是部署后的工作) An architecture invokes discussion about potential change ( 80% of effort for a system is post-deployment effort)
7. 架构将更改分为三种类型 Architecture categorise changes into three types:

1. 本地：信号组件修改 Local: signal component moditication
2. 非本地：几个组件修改。Non-local: several component moditication.
3. 架构：修改系统的基本结构，通信和协调机制 Architectural: modification of the system’s basic structure, communication, and coordination mechanism

8. 架构是一种可迁移和可重用的抽象：一对多映射(一种架构，许多系统) Architecture is a transferable and reusable abstraction one-to-many mapping (one architecture, many systems)
9. 架构是产品通用性的基础。整个产品线共享一个架构 Architecture is the basis for product commonality. A whole product line shares a single architecture
10. 可以通过体系结构集成独立开发的组件来开发系统(基于Component的软件工程-CBSE) Systems can be developed by integrating independently developed components via architecture ((Component-Based Software Engineering - CBSE)

1.3. 软件架构过程 Software Architecture Process

1. 通过StackHolder获取到ASRs(架构攸关的需求)
2. 通过分析得到Prioritized Quality Attribute Scenarios(高优先级质量属性解决方案)和Requirements，Constraints(需求和约束)
3. 将上述部分，结合模式和策略，综合可以得到架构的设计
4. 根据架构的设计得到由模式决定的候选视图的示意图，之后完成文档化
5. 选择、组合视图，将文档进行进一步的评估，这一部分需要StackHolders的参与、也需要Prioritized Quality Attribute Scenarios和文档等作为参考。

1.3.1. 移动手机系统架构 Mobile Phone System Architecture

1.3.2. 洗衣机架构 Washing Machine Architecture

1.4. 讨论 Discussion

1. 科学和工程有什么不同？What is Difference between Science and Engineering?

1. 科学的研究是研究这个世界既有的部分
2. 工程是研究的是人类创造新的世界(是不是因为人才产生的)

2. 软件和硬件有什么不同？What is Difference between ‘Software’ and ‘Hardware’ ?

1. 软件是不可见的：软件是虚拟的，而硬件是实体的。
2. 软件制作出来就是为了被修改和改变的(软件的演化是他的本质属性)

3. 体系结构和设计有什么不同？What is Difference between Architecture and Design?

1. 所有的体系结构都是软件设计，但是不是所有的软件设计都是体系结构
2. 体系结构是设计过程的一个过程。
3. 其他观点

1. 体系结构是更高层的设计，是为了修改的
2. 体系结构是设计决策的组合

4. 体系结构和结构有什么不同？What is Difference between Architecture and Structure?

1. 体系结构定义了组件(Component)的接口，Component之间如何交流以及如何相互依赖，Component的职责。
2. 体系结构提供了设计的更高层抽象视角，隐藏设计的复杂性和实现，更强调非功能性需求。
3. 【标准】架构是包括结构信息的，因为结构是一种静态的、逻辑的、是关于系统如何构成。但是架构除了包含结构，还会增加组件的相互之间的关系接口，还会定义一些动态的行为(一个组件可能和谁进行交互)

5. 为什么要在架构中使用抽象？Why Abstraction in Architecture?

1. 更高层的视角，更关注本身的结构而不是本身的实现。
2. 降低架构设计时的系统复杂度，可以屏蔽和隐藏一些细节。

2. 需求 Requirements

需求中往往存在有开发人员和用户的矛盾，我们需要将这一个部分进行转化

2.1. 功能性需求 Functional Requirements

1. 功能性需求定义了系统必须做什么并且强调了系统如何提供价值给涉众 Functional requirements state what the system must do and address how the system provides value to the stakeholders.
2. 功能性需求意味着系统的行为 Functional requirements means the behaviour of the system.
3. 功能是系统完成其预期工作的能力，例如，使学生能够在线注册。Functionality is the ability of the system to do the work for which it was intended, e.g., enable students to enrol online.
4. 通过使用许多可能的结构可以实现功能。Functionality may be achieved through the use of any
   number of possible structures.
5. 功能在很大程度上与结构无关，因为它可以作为单个整体系统存在而没有任何内部结构。Functionality is largely independent of structure, because it could exist as a single monolithic system without any internal structure.

2.2. 质量需求 Quality Requirements

1. 质量需求是系统应在其功能要求之上提供的整个系统的合乎需要的特性(又称质量属性) Quality requirements are desirable characteristics of the overall system (aka. quality attrilbutes) that system should provide on the top of its functional requirements.
2. 质量要求是功能要求或整个产品的资格。软件体系结构限制了分配 Quality requirements are qualifications of the functional requirements or of the overall product.
3. 如果质量属性很重要，则将功能(映射)到各种结构上。Software architecture constrains the allocatio (mapping) of the functionality onto various structures if quality attributes are important.

2.2.1. 非功能性需求 Non-functional Requirements

1. 非功能要求或体系结构要求是用于质量属性的替代术语 Non-functional requirements or architectural requirements are alternative terms used for quality attributes.
2. 无法正确使用功能，然后尝试适应非功能性要求(不具备翻新质量)。It is not possible to get the functionality right and then try to accommodate non-functional requirements (NO retro-fitting quality).
3. 在任何设计决策中都必须考虑非功能性要求。Non-functional requirements must be taken into account during any design decision.
4. 非功能性需求分为两大类：There are two broad categories ot non-functional requirements:

1. 在执行过程中可观察(外部)：系统满足其行为要求的程度如何？ 例如性能，安全性，可用性，可用性等。Observable (External) during execution: How well a system satisties its behavioural requirements? e.g., performance, security, availability, usability etc.
2. 执行期间不可观察(内部)：系统的维护，集成或测试有多容易？ 例如，可修改性，可移植性，可重用性，可测试性等。Not observable (Internal) during execution: How easily a system can be maintained, integrated, or tested? e.g., modifiability, portability, reusability, testability etc.

5. 约束了限定的边界，之后的架构是在这个边界内找到最优的解。

2.2.2. 质量属性 Quality Attributes

1. 开发完成后，质量不能添加到软件密集型系统中 Quality isn’t something that can be added to a software intensive system after development finishes.
2. 在软件开发的所有阶段都需要解决质量问题 Quality corncerns need to be addressed during ALL phases of the software development.
3. 业务目标确定系统必须具备的质量。Business goals determine qualities that a system must posses.
4. 质量属性是系统功能的基础，而功能是系统功能，服务和行为的基本说明 Quality attributes are over and above of system’s functionality, which is the basic statement of the system’s capabilities, services, and behaviours.
5. 功能通常在开发计划中占据重要位置 Functionality usually takes the front seat in the development plan.
6. 但是，系统通常是重新设计的，因为它们缺乏所需的质量级别，即难以维护，移植或扩展 However, systems are usually redesigned because they lack desired level of quality, i.e. difficult to maintain, port, or scale.
7. 软件体系结构限制了各种质量属性的实现，例如性能，安全性，可用性等 Software architecture constrains the achievement of various quality attributes, e.g., performance, security, usability etc.
8. 这就是为什么软件体系结构被认为是解决质量问题的最合适的层次 That is why software architecture is considered the most appropriate level of addressing the quality Issues.
9. 质量属性不完全取决于设计，也不取决于实现或部署 No quality attribute is entirely dependent on design, nor is it dependent on implementation or deployment.

2.2.3. 确定质量属性 Specifying Quality Attributes

1. 要在架构级别对其进行评估，必须对质量属性进行精确定义。Precise definition of a quality attribute is necessary to evaluate it at the architecture level.
2. 质量属性方案用于定义所需的质量属性。Quality attribute scenarios are used to define the desired quality attribute.
3. 方案是具有一定结构的简单句子。场景的两个主要类别是：Scenarios are simple descriptions with certain structure. Two main classes of scenarlos are:

1. 通用方案是与系统无关的方案，用于指导质量属性要求的规范 General scenarios are system independent scenarios to guide the specification of quality attribute requirements.
2. 具体方案是系统特定方案，用于指导特定系统的质量属性要求的规范。它们是一般方案的实例 Concrete scenarios are system specitic scenarios to guide the specification of quality attribute requirements tor a particular system. They are instances ot general scenarlos.

4. 这个方案就是4+1视图中的1(Use Case)

2.2.3.1. 通用方案 General Scenarios

1. 通用方案提供了一个框架，用于生成大量通用的，独立于系统的，质量属性特定的方案。General scenarios provide a framework for generating a large number of generic, system- independent, quality attribute specific scenarios.
2. 每种情况都可能但不一定与我们所关注的系统相关。Each scenario is potentialy but not necessarily relevant to the system We are concerned with.
3. 为了使一般情况对特定系统有用，我们必须使它们特定于系统。To make the general scenario useful for a particular system, We must make them system specific.
4. 使通用场景系统特定于特定环境意味着将其转换为特定系统的具体术语。Making a general scenario system specific means translating it into concrete terms for the particular system.

2.2.3.2. 质量属性方案建模 Modeling Quality Attribute Scenarios 重要

1. 刺激(Stimulus)：到达系统时需要考虑的条件 Stimulus: A condition that needs to be considered when it arrives at a system.
2. 刺激源(Source of Stimulus)：产生刺激的实体(人，系统或任何促动器) Source of Stimulus: An entity (human, system, or any actuator) that generates the stimulus.可能是输入、消息等等，对当前的状态有一个变化。
3. 应对(Response)：刺激措施到来之后开展的活动 Response: The activity undertaken after the arrival of the stimulus.
4. 响应度量(Response Measure)：对刺激的响应应以某种方式进行测量，以便可以测试需求。Response Measure: The response to the stimulus should be measurable in some fashion so that the requirement can be testable.多长时间系统有反馈
5. 环境(Environment)：发生刺激时系统的状况，例如过载，运行等 Environment: A system’s condition when a stimulus occurs, e.g. overloaded, running etc.
6. 工件(Artifact)：需求适用的整个系统或系统的一部分。Artifact: The whole system or the portion of the system to which the requirement applies.可能是一个软件制品
7. 只有定义好这6个元素，就能锁定架构的一个场景，之后可以用来进行架构的设计
8. 刺激和响应发生在一个环境中：系统正常运行、系统过载、系统受到攻击、系统网络等出现了故障。

2.2.3.3. Tactics 策略(原子级别的最小的决定)

1. 风格或样式运用策略来提供预期的收益 Style or pattern applies tactics to provide the promised benefit.
2. 策略是影响质量属性响应控制的设计决策，例如冗余。A tactic is a design decision, .e.g. redundancy, that influences the control of a quality attribute response.
3. 策略的集合称为体系结构策略。A collection of tactics is called an architectural strategy.
4. 系统设计包括一组设计决策，其中一些决策可帮助控制质量属性响应；其他确保系统功能的实现 A system design consists of a collection of design decisions: some of these decisions help control the quality attribute response; others ensure achievement of system functionality.
5. 像模式一样，策略也可以由其他策略组成，例如，冗余可以由数据的冗余，计算的冗余组成。设计人员根据需求选择一个或另一个 Like patterns, tactics may also be composed of other tactics, e.g., redundancy may be composed of redundancy of data, redundancy of computation-Designer chooses one or other depending upon requirements.
6. 策略可以用作策略等级 Tactics can be used as hierarchy of tactics.

2.2.3.4. 质量设计决策 Quality Design Decisions

1. 架构是设计决策的集合。Architecture is a collection of design decisions.
2. 七类设计决策(可能重叠) Seven categories of design decisions (may overlap):

1. 职责分配 Allocation of responsibilities：将大的职责进行分配
2. 协调模型 Coordination model：各部分之间的沟通、交互
3. 数据模型 Data model：数据格式、存储方式(缓存等)
4. 资源管理 Management of resources：CPU、网络、内存、时间(部分时间敏感的场景)等资源
5. 架构元素之间的映射 Mapping among architecture elements：将架构元素如何映射到软件的实现上
6. 绑定时间决策 Binding time decisions：

1. 系统的变化可以在什么时间点前需要固定下来，也就是这个时间前，系统还是可以变化的，但是这个时间之后就不可以变化了
2. 比如选择安装环境是需要在一个时间点前完成的，技术是否添加、编译时间、初始化时间，运行时绑定，但运行时是弹性最大的
3. 实际上我们希望绑定时间越往后越好，但是也就要付出相应的代价。

7. 技术选择 Choice of technology：前面的部分都确定后，我们可以选择技术栈相对比较局限，解空间已经被压缩了。

2.2.3.5. 特性

1. Adaptability
2. Extensibility
3. Availability
4. Modularity
5. Configurability
6. Portability
7. Flexibility
8. Reusability
9. Interoperability
10. Testability
11. Performance
12. Auditability
13. Reliability
14. Maintainability
15. Responsiveness
16. Manageability
17. Recoverability
18. Sustainability
19. Scalability
20. Supportability
21. Stability
22. Usability
23. Security

2.3. 约束 Constraints

1. 约束是具有零*度的设计决策。A constraint is a design decision with ZERO degrees of freedom.
2. 约束是已经做出的预先指定的设计决策。Constraints are pre-specified design decisions that have been already made.
3. 通过接受设计决策并将其与其他受影响的设计决策进行协调，可以满足约束条件。Constraints are satisfied by accepting the design decision and reconciling it with other affected design decisions.

3. 质量属性和策略 Quality Attributes & Tactics

3.1. 可用性 Availability

1. 可用性是应用程序的关键要求 Key requirement for most IT applications
2. 度量方式：以所需的可用时间比例来衡量，例如 Measured by the proportion of the required time it is useable, e.g.

1. 营业时间内100％可用 100% available during business hours
2. 每周计划的停机时间不超过2个小时-24x7x52(100％可用性) No more than 2 hours scheduled downtime per week - 24x7x52 (100% availability)

3. 相关性：与应用程序的可靠性有关 Related to an application’s reliability

1. 不可靠的应用程序的可用性较差 Unreliable applications suffer poor availability
2. 可用性、可靠性不同：

1. 可用性是指可以使用，但是不保证正确
2. 可靠性是指可以稳定正确的使用。

4. 可用性损失的时间由以下因素决定：Period of loss of availability determined by:

1. 发现故障的时间 Time to detect failure
2. 纠正故障的时间 Time to correct failure
3. 重启应用的时间 Time to restart application
4. 例子(时间序)：发生故障-检测到故障-纠正故障-重启应用，这三个代表的是not available的时间(N/A)
5. 提高可用性的方案

1. 尽可能降低N/A的时间

1. 机器尽可能缩短failure到detect时间
2. 机器尽可能缩短correct到restart的时间

2. 尽可能提高Available的时间

5. 高可用性策略 Strategies for high availability

1. 消除单点故障 Eliminate single points of failure
2. 复制和故障转移 Replication and failover
3. 自动检测并重启 Automatic detection and restart

6. 可恢复性(例如数据库)Recoverability (e.g… a database)

1. 在应用程序或系统出现故障后，可以重新建立性能级别并恢复受影响的数据的功能。The capability to re-establish performance levels and recover affected data after an application or system failure.

7. 可将可用性计算为在指定的时间间隔内它将在要求的范围内提供指定服务的概率。Availability can be calculated as the probability that it will provide the specified services within required bounds over a specitied time interval.

1. MTBF(平均无故障时间) MTBF (mean time between failures)
2. MTTR(平均维修时间) MTTR (mean time to repair)

上一篇： 探讨软件质量特性在系统架构中的重要性

下一篇： 探讨软件架构中的关键特性：六大数据质量要素