软件体系架构复习要点

本文根据华南理工大学软件学院《软件体系架构》课程及相关教材《软件构架实践》总结，作复习回顾用。

很抽象的课程……不知道开给本科生干什么，而且是跟项目管理一起上的，安排很不科学。这门课学起来能听懂，也知道要干什么，就是没体会。

---

 

Chapter. 1 What is software architecture?

1. 软件体系架构的定义

The software architecture of a system is the set of structures neeed to reason about the system, which comprise software elements,relations among them, and properties of both.

2. 软件系统有哪几类结构？

Module; component and connector; Allocation

3. Module structure 模块结构

Structures partition systems into implementation units are called modules. Modules are assigned specific responsibilities, and are the basis of work.

常见的模块结构: decomposition structure / uses structure / layer structure / class structure / data model

4. Component-and-connector structure 组件与连接件结构

Structures focus on the way the elements interact with each other a runtime to carry out the system's functions are called C&C structures. A component is always a runtime entity.

常见的C&C结构: service structure / concurrency structure

5. Allocation structures 分配结构

Allocation structures describe the mapping from software structures to the system's environments.

常见分配结构: deployment structure / implementation structure / work assignment structure

6. What's the relationship between structures and views?

A view is a representation of a structure. Architects design structures. They document views of those structures.

 

Chapter. 2 Why is Software Architecture Important?

Thirteen reasons

1. Influence quality attributes
2. Help reason about and manage change as the system evolves
3. Early prediction of a system's qualities
4. Enhances communication among stakeholders
5. Capture the earliest and hence most fundamental, hardest-to-change design decisions
6. Defines a set of constraints on subsequent implementation
7. Dictates the structure of an organization, or vice versa
8. Provide the basis for evolutionary prototyping
9. Allows the architect and project manager to reason about cost and schedule
10. As a transferable, reusable model that from the heart of a product line
11. Architecture-based development focuses attention on the assembly of components, rather then simply on their creation
12. Reducing design and system complexity
13. Be the foundation for training a new team member

 

Chapter. 3 The Many Contexts of Software Architecture

1. Contexts of Software Architecture

Technical, project life cycle, business, professional

2. Technical context

A serious quality attributes (most important). 

3. Project life-cycle context

瀑布模型、迭代开发、敏捷开发、模型驱动开发

4. Business context

没啥可说的

5. Professional context

也没啥可说的

6. Stakeholder

A stakeholder is anyone who has a stake in the success of the system, such as developing organization's management stakeholder, marketing stakeholder, end user stakeholder, maintenance organization stakeholder and customer stakeholder.

7. How is architecture influeced? 

需求影响架构。一个软件架构是受商业、社会、技术的影响。一个架构的存在反过来影响未来架构的商业、社会、技术等因素。每个架构的上下文环境都影响架构师和架构本身。

 

Chapter. 4 Understanding Quality Attributes

1. Functional requirements

Functionality is the ability of the system to do the work for which it was intended.

2. Quality attribute scenarios

1. Stimulus 刺激：到达时要求系统作出响应的一个条件
2. Stimulus source 刺激源：产生刺激的一些实体(人、计算机系统等)
3. Response 响应：系统在刺激到达时采取的活动
4. Response measure 相应度量：当响应发生时，应该以某种方式测量，以便可以测试该需求
5. Environment 环境：刺激发生的某些特定条件
6. Artifact 制品：受到刺激产生的制品

3. Tactics

Acollection of primitive design techniques that an architect can use to achieve a quality attribute response.

4. Quality design decisions

1. Allocation of responsibilities
2. Coordination model
3. Data model
4. Management of resources
5. Mapping among architectural elements
6. Binding time decisions
7. Choice of technology

 

Chapter. 5 Availability

1. Concept

Availability refers to a property of software that it is there and ready to carry out its task when you need it to be.

2. Formular

t=MTBF/(MTBF+MTTR)

MTBF=平均故障间隔时间  MTTR=平均修复时间

3. Tactics

Detect faults: Ping/Echo / monitor / heartbeat / timestamp / sanity checking / condition monitoring / voting / exception detection / self-test

Preparation and Repair: actice redundancy / passive redundancy / spare / exception handling / rollback / software upgrade / retry / ignore faulty behavior / degradation / reconfiguration

Reintroduction: shadow/ state resynchronization/ escalating restart / non-stop forwarding

Prevent faults: removal from service / transactions / predictice model / exception prevention / increase competence set

 

Chapter. 6 Interoperability

1. Concept

INteroperability is about the degree to which two or more systems can usefully exchange meaningful information.

2. Tactics

Locate: discover service

Manage interfaces: orchestrate tailor interface

 

Chapter. 7 Modifiability

1. Concept

Modifiability is about change and out interest in it is in the cost and risk of making changes.

2. Tactics

Reduce size of a module: split module

Increase cohesion: increase semantic coherence

Reduce coupling: encapsulate / use an intermediary / restrict dependencies / refactor / abstract common services

Defer binding

 

Chapter. 8 Performance

1. Concept

Performance is about time and the software system's ability to meet timing requirements.

2. Tactics

Control resource demand: manage sampling rate /  limit event response / prioritize events / reduce overhead / bound execution times / increase resource efficiency

Manage resources: Increase resources / introduce concurrency / maintain multiple copies of computations / maintain multiple copies of data / bound queue sizes / schedule resources

 

Chapter. 9 Security

1. Concept

Security is a measure of the system's ability to protect data and information from unauthorized access while still providing access to people and systems that are authorized.

Three mainly features: confidentiality、intergrity、abailability.

Other features: Authentication、nonrepudiation、authorization.

2. Tactics

Detect attacks: detect intrustion /  detect service denial / verify message integrity / detect message delay

Resist attacks: identify actors / authenticate actors / authorize actors / limit access / limit exposure / encrypt data / separate entities / change default settings

React to attacks: revoke access / lock computer / inform actors

Recover from attacks: maintain audit trail / restore(see abailability)

 

Chapter. 10 Testability

1. Concept

Software testability refers to the ease with which software can be made to demonstrate its faults through testing. Specifically, testability refers to the probability, assuming that the software has at least one fault, that it will fail on its next test execution.

2. Tactics

Control and observe system state: specialized interfaces / record or playback / localize state storage / abstract data sources / sandbox / executable assertions

Limit complexity: limit structural complexity / limit non-determinism

 

Chapter. 11 Usability

1. Concept

Usability is concerned with how easy it's for the user to accomplish a desired task and the kind of user support the system provides.

2. Tactics

Suport user initiative: cancel / undo / pause or resume / aggregate

Support system initiative: maintain task model / maintain user model / maintain system model

 

Chapter. 12 Other Quality Attributes

1. List

Variability(变异性)、portability(可移植性)、development distributability(开发可分布性)、scalability(可伸缩性)、deployability(可部署性)、mobility(可移动性)、monitorability(可监控性)、safety(安全性)

2. Other

Conceptual integrity(概念完整性)、marketability(市场性)、quality in use(使用质量)

3. How to deal with unknown quality attributes?

1. MOdel the quality attribute
2. assemble a set of tactice for the quality attribute
3. construct design checklists

 

Chapter. 13 Patterns and Tactics

1. Conception of Patterns

An architectural pattern establishes a relationship between: a context, a problem and a solution.

2. Layer pattern 层次模式

context：关注点的分离

problem：需要对软件分段，使得模块可以单独开发，部件之间几乎没有交互，支持可移植性，可修改性和重用。

solution：将软件以层为单位划分。每个层为一组模块，提供一组连贯的服务。使用方向必须为单向。

3. Broker pattern 代理模式

context：分布式服务彼此之间互相操作

problem：如何构建分布式软件以便服务用户，满足不需要知道服务提供商的的性质和位置就可以容易地动态更改用户和提供商之间的绑定？

solution：代理模式通过插入一个称为代理的中介，将服务的用户(客户端)与服务的提供者(服务器)分离。

4. Model-View-Controller MVC模式

context：从模型中分离视图。

problem：如何将用户界面功能与应用程序功能分开，但仍然响应用户输入或低层应用程序数据的更改？当底层应用程序数据发生变化时，如何创建、维护和协调用户界面的多个视图？

solution：使用MVC模式将应用程序功能分为三种类型的组件。

5. Pipe and Filter Pattern 管道-过滤器模式

context：处理数据流

problem：系统需要被分成可重复使用的松散耦合的组件，这些组件具有简单的通用交互机制。

solution：使用管道-过滤器模式，其交互模式的特征在于数据流的连续变换。

6. Client-Server Pattern 客户端-服务器模式

context：有大量分布式客户端希望访问的共享资源和服务。

problem：我们希望通过集中控制这些资源和服务来提高可伸缩性和可用性，同事将资源本身分布在多个物理服务器上。

solution：客户端通过请求服务器的服务进行交互，服务器提供一系列服务。

7. Peer-to-Peer Pattern P2P模式

context：分布式计算实体被认为是对等的。

problem：一组“相等”的分布式计算实体如何通过公共协议相互连接，以便它们能够以高可用性和可扩展性组织和共享其服务？

solution：在P2P模式中，组件直接作为对等体进行交互。所有对等体都是“相等的”，并且没有对等体或对等体组对于系统的健康是至关重要的。

8. Service Oriented Architecture Pattern 面向服务的架构模式(SOA)

context：许多服务互操作，但是对他们的实现没有任何详细的了解。

problem：如何支持在不同平台上运行并以不同实现语言编写的、由不同组织提供并分布在因特网上的分布式组件的互操作性？

solution：面向服务的体系结构(SOA)模式描述了提供和/或使用服务的分布式组件的集合。

9. Publish-Subscribe Pattern 发布-订阅模式

context：数据生产者和消费者的确切数量和性质不是预先确定的或固定的，也不是它们共享的数据。

problem：如何创建支持在生产中和消费者之间传输消息的能力的集成机制，使他们h不知道对方的身份甚至存在？

solution：在发布-订阅模式中，组件通过已发布的消息或时间进行交互。

10. Shared-Data Pattern 共享数据模式

context：各种计算组件需要共享和操作大量的数据。

problem：系统如何存储和操作由多个独立组件访问的持久数据？

solution：在共享数据模式中，交互主要由多个数据访问器和至少一个共享数据存储之间的持久数据交换所主导。

11. Map-Reduce Pattern 映射-减少模式

context：需要快速分析大量数据。

problem：有效地执行大型数据集的分布式并行排序，并为程序员指定要执行的分析提供了一种简单的方法。

solution：map-reduce模式需要三个部分：一个负责根据需要分配数据的专用基础设施；一个用于过滤数据以检索项目的map；一个结合了映射结果的reduce。

12. Multi-Tier Pattern 多级模式

context：将系统的基础结构分不到不同的子集中

problem：如何将系统分成许多计算独立的执行结构：由一些通信戒指连接的软件组和硬件组？

solution：许多系统的执行结构被组织为一系列组件的逻辑分组。每个分组称为级。

13. Relationship between tactics and patterns

Patterns are built from tactics; if a pattern is a molecule, a tactic is an atom. Tactics augment patterns.

 

Chapter. 14 Quality Attribute Modeling and Analysis

1. Quality Attribute Modeling 

一些质量属性具有可被用于辅助分析的、已被充分理解的、经时间测试的分析模型。有了分析模型就意味着支持定量分析。

2. Maturity of Quality Attribute Models

Availability: Markov models; Statistical models.

Interoperability: Conceptual framework.

Modifiability: Coupling and cohesion metrics; Cost models.

Performance Queuing theory; Real time scheduling theory.

Security: No architectural models.

Testability: Component Interaction Metrics

Usability: No architectural models

3. Thought Experiment Steps

1. 枚举用例的步骤
2. 不停问自己：正在实施什么机制来支持实现哪些特定的质量要求？这个机制是否阻碍了其他属性的实现？
3. 记录问题供后续分析。

4. 在生命周期不同阶段进行不同类型的分析

1. 需求阶段：分析模型和背景分析可以帮助规划容量；检查表可以帮助确保捕获正确的要求
2. 设计阶段：原型可以帮助探索设计选项
3. 实现阶段：实验和合成负载测试可以再实现过程中或字段化之后使用
4. 字段化阶段：监视器可以再字段化之后使用，以确定实际行为并发现瓶颈

 

Chapter. 15 Architecures in Agile Projects

1. 敏捷过程的思想

敏捷过程为以下这些项目服务：对其涉众更加敏感；更快地开发用户关注的功能；在项目生命周期中显示更多和更早的进展；通过文档记录减轻负担。敏捷项目关注问题：应做多少架构、应记录多少架构。

2. Twelve Agile Principles

1. HIghest priority is to satisfy the customer through early and continuous delivery.
2. Welcome changing requirements, even late in development.
3. Deliver working software frequently with a preference to the shorter timescale.
4. Business people and developers work together daily throughout the project
5. Build projects around motivated individuals
6. Face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development
9. Continuous attention to technical excellence and good design.
10. Simplicity-the art of maximizing the amount of work not done-is essential
11. Self-organizing teams
12. At regular intervals, the team reflects on how to become more effective.

3. Agility and Documentation 敏捷开发与架构编档

敏捷项目中的文档是为读者而写，如果不需要就不要写。

4. Agility and Architecture Evaluation 敏捷开发与架构评估

架构评估是敏捷过程的一部分。满足涉众重点关注是敏捷哲学的基石。架构评估方法由架构权衡分析方法(ATAM)来说明。ATAM确定了涉众一组最重要的关注点。

 

Chapter. 16 Architecture and Requirements

1. ASR

An architecturally significant requirement is a requirement that will have a profound effect on the architecture.

2. Serval way to get ASRs

1. Gathering ASRs from requirements documents 从需求文档中获取
2. Gathering ASRs by interviewing stakeholders 采访涉众
3. Gathering ASRs by understanding the business goals 理解业务目标
4. Capturing ASRs in a utility tree 在效用树中捕获

3. Quality Attribute Workshop(QAW) 质量属性研讨会

QAW专注于系统级的关注，特别是软件在系统中的作用。

4. PLAM

A method for eliciting business goals.

7个步骤为：

1. PALM overview presentation
2. Business drivers presentation
3. Architecture drivers presentation
4. Business goals elicitation
5. Identification of potential quality attributes from business goals
6. Assignment of pedigree to existing quality attribute drivers
7. Exercise conclusion

5. Utility Tree 效用树

效用树是一种记录ASR的方法，确定每个ASR的优先级。ASR作为场景被捕获。树的根节点被称为“实用程序”。第二层节点包含广泛的质量检查类别。第三层节点精化这些类别。

 

Chapter. 17 Designing an Architecture 

1. Generate and Test 架构设计中的假设-检验法

1. 把当前的设计当做一个假设
2. 询问当前的设计是否已经满足需求
3. 如果不是，产生一个新的假设并迭代

2. 初始的假设从何而来

可靠的来源：存在的系统、框架

不可靠的来源：模式和战术、域分解、设计清单

3. 如何测试假设

已经涵盖的分析技术；质量属性讨论的分析策略；ASR

测试的输出是什么？当前设计未满足的需求列表

4. 如何产生下一次假设

添加缺少的职责；使用战术来调整假设的质量属性行为

5. 什么时候完成假设检验法

所有的ASR都被满足。或者设计活动的预算用完。

6. The Attribute-Driven Design Method(ADD) 属性驱动设计方法

包装了许多已经讨论过的技术，是一个迭代的方法。每次迭代选择系统的一部分进行设计，整顿该部分的ASR。ADD不会产生完整的设计，而是产生带有职责的容器以及容器之间的交互和信息流。不为容器生产api或发布签名。

7. ADD的步骤

1. Choose an element of the system to design.
2. Identify the ASRs for the chosen element.
3. Generate a design solution for the chosen element.
4. Inventory remaining requirements and select the input for the next iteration.

 

Chapter. 18 Documenting Software Architectures

1. 架构文档的重要性

生命周期长于代码。

2. 读者

新雇员，开发者，分析师

3. 架构文档的用途

教育；涉众之间的主要沟通手段；系统分析和构件的基础

4. View

视图将软件架构分为系统的多个可管理的表示。不同视图支持不同目标和用途。应记录视图取决于你对文档的期望使用。每个视图都有成本和收益，应确保维护视图的好处超过其成本。

5. Module Views

element: module

relationship: is part of, depends on, is a

constraint: topological constraint, behaviour constraint

usage: 构建代码蓝图、受变化影响的分析、规划增量开发、需求跟踪分析、工作分配、时间表和预算信息.如果没有至少一个模块视图，任何软件体系结构的文档都不可能是完整的。

6. C&C views

element: components, connectors

relationship: attachments, interface delegation

constraint: 组件只能连接到连接器，连接器只能连接到组件，只能在兼容端口和角色之间进行附件、接口委托只能在两个兼容端口(或两个兼容角色)之间定义，连接器不能孤立出现，连接器必须连接到组件。

usage: 显示系统如何交互，帮助推理运行时系统的质量

7. Allocation Views

element: software elements; environment elements

relationship: 分配到

constraint: 随视图而变化

usage: 推理性能、可用性、安全性和安全；推理分布式开发和团队的工作分配；推理软件版本的并发访问；推理系统安装的形式和机制

8. Method for Choosing the Views

1. Build a stakeholder/view table
2. Combine vies to reduce their number
3. Prioritize and stage

9. Documenting a view

1. The primary presentation
2. The element catalog
3. Context diagram
4. Variability guide
5. Rationale

10. Documenting information beyond views

1.  Documentation roadmap
2. How a view is documented
3. System overview
4. Mapping between views
5. Rationale
6. Directory

11. Documenting behavior

12. Documenting quality attributes

 

Chapter. 19 Architecture, Implementation, and Testing

1. 帮助保持代码和架构一致的4种技术

1. Embedding the design in the code
2. Frameworks
3. Code templates
4. Keeping code and architecture consistent

2. Embedding the design in the code

架构作为实现的蓝图。

3. Framework

框架是围绕特定主题组织的一组可重用的类

4. Code template

代码模板是代码的集合，是程序员提供的应用的特定部分。

5. Keeping code and architecture consistent

6. 架构师在测试中的角色

1. 测试计划
2. 测试开发
3. 测试解释
4. 测试工具构建

 

Chapter. 20 Architecture Reconstruction and Conformance

1. Background of architecture reconstruction

1. 系统已经存在但你不了解它的架构
2. 如何维护
3. 如何管理系统的发展以维持其架构提供的质量属性

2. Aim of architecture reconstruction

1. 记录一个文档，关于从未存在或文档已经过时的架构
2. 确保完成时的架构和设计的架构之间的一致性
3. 在架构重构中，构建的架构是从现有系统组件反向设计过来的

3. Steps of architecture reconstruction

1. Raw view extraction
2. Database construction
3. View fusion and manipulation
4. Architecture analysis

Chapter. 21 Architecture Evaluation

1. 架构评估的三种形式及其特点

1. Evaluation by the designer within the design process
2. Evaluation by peers within the design process
3. Analysis by outsiders once the architecture has been designed

2. The architecture tradeoff analysis method(ATAM)

ATAM的设计使得评估者不需要熟悉架构或其业务目标，系统不需要构建，并且可能有大量的涉众。

3. ATAM的参与者

1. The evaluation team
2. Project decision makers
3. Architecture stakeholders

4. ATAM的输出

1. 简洁的架构演示
2. 业务目标的说明
3. 表示为质量属性场景的优先级质量属性
4. 一组风险和非风险
5. 一组风险主题
6. 将架构决策映射到质量要求
7. 一组确定的灵敏度和权衡点

5. Steps of ATAM

1. Present the ATAM
2. Present business dribers
3. Present the architecture
4. Identify architectural approaches
5. Generate utility tree
6. Analyze architectural approaches
7. Brainstorm and prioritize scenarios
8. Analyze architectural approaches
9. Present results

6. Lightweight Architectural Evaluation

 

Chapter. 26 Architectures for the clod

1. Basic definition of cloud

• On-demand self-service
• Ubiquitous network access
• Resource pooling
• Location independence
• Rapid elasticity
• Measured service
• Multi-tenancy

2. Basic service model of cloud

1. Software as a service
2. Platform as a service
3. Infrastructure as a service

3. Deploy model of cloud

private cloud; public cloud; community cloud; hybird cloud

4. Main mechanism of cloud

Hypervisor; virtual machine; file system; network

5. Main technology of cloud

• Virtual meory page table
• Hypervisor manages
• Virualization
• HDFS Hadoop
• IaaS
• PaaS
• Databases

6. Infrastructure as a Service (IaaS)

An arrangement of servers that manages the base technologies

服务器以集群形式排列，一些服务器作为IaaS的基础结构，每个服务器都有一个管理程序作为其基础。

Components of IaaS: 

• Cluster manager
• Persistent object manager
• Virtual resource manager
• The file system manager

IaaS提供的服务：

• 在低层虚拟机实例故障的情况下自动重新分配IP地址
• 自动缩放：根须负载创建或删除新虚拟机

7. Platform as a Service (Platform as a Service)

为开发人员提供集成堆栈；PaaS管理对堆栈底层的分配。

8. Database

关系型数据库已经不适用，引入新的数据模型：键值对。

9. Quality Attributes of Cloud Architectures

1. Security
   1. 多租户引起了对非云环境的额外关注：无意中的信息共享、虚拟机“逃离”、侧信道攻击、拒绝服务攻击
   2. 当决定在云中托管什么应用程序时，组织需要考虑风险
2. Performance
   1. 自动缩放在负载增长时提供额外的性能。新资源的响应时间可能不适合，架构师需要了解应用程序的资源需求
3. Availability
   1. 故障是云系统的常见事件。云服务提供商必须在出现一些异常时确保云服务本身仍然可用。应用程序开发人员必须假设实例会失败，并在失败的情况下构建检测和纠正体制。