软件架构复习.docx

软件架构复习.docx

《软件架构复习.docx》由会员分享，可在线阅读，更多相关《软件架构复习.docx（11页珍藏版）》请在冰豆网上搜索。

软件架构复习

Chapter1.WhatisSoftwareArchitecture?

理解：

软件体系结构（软件架构）的定义、架构模式的概念。

软件体系结构：

某个软件或计算系统的软件架构是该系统的一个或多个结构，他们由软件元素、这些元素的外部可见属性以及这些元素之间的关系组成

架构模式：

架构元素可以被组织成解决特定问题，这种架构元素的组合成为构架模式。

构架模式是对构架的一组制约条件

掌握：

软件系统有哪几类结构？

在每类结构里，元素及其之间的关系是什么？

每类结构各有哪些常见的结构？

其特点是什么？

Module：

分解结构，模块，是一个子模块，可修改性

使用，模块，使用，可扩展性

层结构，层，。

。

。

，可移植性，相关功能一致

类结构，类（object），是一个实例、继承自，可修改性、可扩展性

数据模型，数据实体，泛化、特化，可修改性、性能

Component&Connector：

Service，Service、ESB、Registry、others，。

。

。

，互操作性、可修改性

Concurrency并发，Processes、threads，parallel，性能、可用性

Allocation：

部署，软件硬件元素、通信路径，allocatedto、migratesto移植到，性能、安全性、可用性

实现，模块、文件系统，存储于，开发效率

工作分配，模块、组织单元，分配给，开发效率

了解：

结构与视图是什么关系？

好的结构的一些经验法则。

视图表示一组内聚架构元素集。

一个视图表示一个或多个结构。

Chapter2.WhyisSoftwareArchitectureImportant?

理解：

13个理由。

Chapter3.TheManyContextsofSoftwareArchitecture

理解：

技术环境、项目生命周期、商业环境、架构师职业环境中的软件体系结构。

架构与环境的相互影响。

技术环境：

最重要的技术环境要素—架构能帮助达到的质量属性集；机构现在的技术环境也是很重要的因素

项目生命周期：

软件开发过程是标准的开发软件的方法；他们规定纪律；他们告诉团队成员应该做什么；有四个主要的软件开发过程：

瀑布、迭代、敏捷、模型驱动的。

商业环境：

架构和系统不是愚昧地构造；他们提供商业目标；这些目标可能随时间更改。

架构师职业环境：

你将会执行很多任务；架构师需要不止一项技术技能；架构师需要最新的知识。

架构与环境相互影响：

（1）技术环境：

架构影响涉众的需求；一些客户愿意为了经济效益放松某些需求；

（2）项目环境：

架构影响开发组织的结构；架构规定软件的单元必须实现和集成以完成一个系统；团队嵌入进组织结构中。

（3）商业环境：

架构可以影响商业目标；一个成功的从架构发展而来的系统可以使一个公司在特定的市场区域立足；（4）职业环境：

系统构建的过程将会影响架构师的经验；一个使用特定方法的成功的系统构建将会使架构师倾向于在未来是用同样的方法。

了解：

涉众。

Chapter4.UnderstandingQualityAttributes

了解：

系统的功能需求。

功能需求与系统架构的关系。

功能需求与质量需求的关系。

系统约束。

功能需求：

功能需求与架构的关系：

一对多，不决定架构

功能需求与质量属性的关系：

无关，正交的

系统约束：

0自由度的设计决策

理解：

系统的质量需求。

战术的概念。

质量需求：

战术：

架构师用来得到质量属性响应的技术。

影响质量属性响应的设计决策。

掌握：

质量属性场景的概念和举例。

质量设计的7种决策。

质量属性场景是一种面向特定的质量属性的需求，刺激源、刺激、环境、制品、响应、响应度量

质量设计的7种决策：

职责分配、协调模型、数据模型、资源管理、架构元素之间的映射、绑定时间决策、技术选择

Chapter5.Availability

理解：

可用性概念。

与系统故障及其相关后果有关。

当出现错误时系统能够使用的能力。

了解：

可用性公式。

可用性一般场景。

掌握：

可用性战术。

可用性设计清单。

（1）检测错误：

Ping/echo，监控，心跳，时间戳，完整性检验，条件监控，表决，异常检测，自测试

（2）从错误中恢复：

1）准备恢复：

主动冗余（热重启），被动冗余（暖重启），备用（冷重启），异常处理，回滚，软件升级，重试，退化，重新配置，忽略错误行为2）再引入：

shadow，状态再同步，重启升级，转发

（3）预防错误：

从服务中删除，事务，预测模型，预防异常，增强能力集

Chapter6.Interoperability

理解：

互操作性概念。

有效交换有意义的信息

了解：

互操作性一般场景。

掌握：

互操作性战术。

互操作性设计清单。

（1）Locate：

Discoverservice，相关系统相互定位

（2）ManageInterface：

Orchestrate，复杂的交互，TailorInterface，增加或移除接口的能力

Chapter7.Modifiability

理解：

可修改性概念。

有关变更的成本问题，成本和风险

了解：

可修改性一般场景。

掌握：

可修改性战术。

可修改性设计清单。

控制实现、测试和部署变更的时间和成本

（1）减少模块的大小：

分裂模块

（2）增加凝聚力：

增强语义一致性

（3）降低耦合：

封装，用中间件，限制依赖，重构，抽象公共服务

（4）推迟绑定

Chapter8.Performance

理解：

性能概念。

事件发生时，将要耗费系统多长时间做出响应

了解：

性能公式。

性能一般场景。

掌握：

性能战术。

性能设计清单。

对在一定的时间限制内到达系统的事件生成一个响应

（1）控制资源需求：

控制采样率，限制事件响应，优先化事件，减少开销，限制执行时间，增强资源（计算）效率

（2）管理资源：

增加资源，增强并发性，维护计算的多个副本，维护数据的多个副本，限制队列大小，调度资源

Chapter9.Security

理解：

安全性概念。

衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力

了解：

安全一般场景。

掌握：

安全性战术。

安全性设计清单。

（1）检测攻击：

入侵检测，检测DOS，验证消息完整性，检测消息延迟

（2）抵抗攻击：

识别actor，身份验证actor，授权actor，限制访问，限制暴露面，加密数据，分解实体，改变默认设置

（3）对攻击的反应：

撤销访问，锁住电脑，通知actor

（4）从攻击中恢复：

1）恢复，查看可用性2）识别，维持审计追踪

Chapter10.Testability

理解：

可测试性概念。

通过测试揭示软件缺陷的容易程度。

了解：

可测试性一般场景。

掌握：

可测试性战术。

可测试性设计清单。

允许在完成软件开发的一个增量后，较轻松地对软件进行测试。

（1）控制和观察系统状态：

特化接口，记录/回放（跨接口），本地化存储状态，抽象化数据源，沙箱（隔离，无限制，撤销），执行断言

（2）限制复杂性：

限制结构复杂型，限制非确定性

Chapter11.Usability

理解：

易用性概念。

对用户来说完成某个期望任务的容易程度和系统所提供的的用户支持的种类

了解：

易用性一般场景。

掌握：

易用性战术。

易用性设计清单。

（1）用户主动的：

取消，暂停/恢复，撤销，聚合

（2）系统主动的：

维持任务模型（用户想做什么，提供协助），维持用户模型（系统以用户可以阅读页面的速度滚动页面），维持系统模型（确定期望的系统行为，以便为用户提供反馈，系统完成当前活动所需要的时间）

Chapter12.OtherQualityAttributes

了解：

其它软件质量属性如可变性、可移植性、开发可分布性、伸缩性、可部署性、移动性、可监控性、生命财产安全性。

其它类别的质量属性如架构质量属性、商业属性、系统质量属性。

ISO/IECFCD25010产品质量标准。

其他质量属性：

可变性、可移植性、开发可分布性、伸缩性、可部署性、移动性、可监控性、生命财产安全性

其他类别的质量属性：

架构质量属性：

概念完整性，正确性和完整性，可构建性

商业属性：

上市时间，成本和收益，所希望的系统生命期的长短，目标市场，推出计划，与老系统的集成

系统质量属性：

软件架构对系统质量属性有实质性的影响。

理解：

如何处理未知的质量属性。

建模，组装战术集，构造设计清单

Chapter13.PatternsandTactics

了解：

架构模式（架构风格）的概念。

描述软件系统里的基本结构组织和纲要。

Apackageofdesigndecisions。

Establishrelationbetweencontext，problem，solution。

掌握：

层次模式、代理模式、MVC模式、管道-过滤器模式、CS模式、P2P模式、SOA模式、发布订阅模式、共享数据模式、Map-Reduce模式、多级模式。

层次模式：

层，接口，，允许使用关系，至少两层，不能形成circular，增加了前期成本和复杂性，有性能损失；

代理模式：

插入一个中介—代理，间接，导致延迟，有通信瓶颈，单点故障，成为安全攻击的目标，增加前期复杂性，很难测试

MVC：

控制器—转发请求，对请求进行处理，模型不应该与控制器直接相连，对于简单的用户接口不值得，对于某些用户接口工具不适合

管道-过滤器：

交互性差，数据流，管道保存数据顺序，不改变数据，一致数据类型

客户-服务器：

可以既是服务器又是客户，有请求/回复连接器，采用协议，远程，加密，有性能瓶颈，单点故障，复杂，高成本的

P2P：

直接连接，相等，运行时可以更改关系，星型拓扑，小的P2P系统不能持续满足质量要求如性能和可用性

SOA：

面向服务模式，分布式组件的集合，提供或使用服务，ESB，中间件注册表，编制服务器，连接器—SOAP、REST、异步消息连接器，可能用中间件，构造复杂，性能瓶颈，没有性能保障，不能控制独立服务的发展

发布-订阅：

C&C结构有至少一个发布或订阅接口，增加延迟，消息交付的可伸缩性和可预测性有不好的影响，消息的顺序不好控制，消息的交付不能保障

共享数据：

多个数据访问器，至少一个共享数据存储区，持久，连接器，有性能瓶颈，单点故障，紧密耦合

映射-规约：

并行，低延迟，高可用性，提取和传送，部署和加载，基础机制，引导，检测和恢复，map无状态不交流，键值对，需要大的数据集—公正，相似的size—并行性，复杂

多级：

逻辑分组-级，是一部分，与什么交流，分配给，前期需要大量成本和复杂性

理解：

模式与战术的关系。

模式由战术建成。

战术增强模式。

Chapter14.QualityAttributeModelingandAnalysis

了解：

模型。

常见质量属性模型的成熟度。

可用性：

中成熟度，硬件；低成熟度，软件

互操作性：

低成熟度

可修改性：

等待

性能：

高成熟度

安全性：

无

可测试性：

低成熟度

易用性：

无

了解：

思想实验。

粗略分析。

原型。

模拟仿真。

实验。

思想实验：

精神或口头上的；架构师为了探索替代品；评估或编写文档时向第三方证明这个选择的明智。

粗略分析：

分析不需要精确；为了很多目的；问题领域和重要的需求才深刻分析；

实验：

许多工具可以帮助执行实验，为了得到设计行为

模拟仿真：

在不同负载下模拟系统

原型：

取决于要部分还是原型实现

Chapter15.ArchitecturesinAgileProjects

了解：

敏捷开发思想与准则。

我们的最高优先级hi满足客户通过早期和持续交付有价值的软件。

欢迎改变需求，即便在开发的后期。

利用变更为客户的竞争优势。

频繁交付可工作的软件。

业务人员和工作人员必须每天一起工作。

围绕被激励的个人构建项目。

给他们需要的环境和支持，袭人他们完成工作。

在一个开发团队中传达信息的最有效的方法是面对面交流。

可工作的软件是进度的主要测量工具。

敏捷过程提倡可持续发展。

持续关注技术优势和好的设计可以提高敏捷性。

最大化不需要做的工作。

最好的架构、需求、设计产生自自组织团队。

每隔一段时间，团队反思如何能更有效，然后相对应的调整和改变。

理解：

敏捷开发的甜蜜点。

前期计划有回报的地方。

了解：

敏捷开发与架构编档。

敏捷开发与架构演化。

敏捷开发与架构编档：

写给读者；如果读者不需要，不用写。

敏捷开发与架构演化：

架构演化是敏捷过程的一部分；满足涉众的重要关心问题；我们进行架构演化的方法用ATAM进行示范；裁定轻量级架构评估方法是容易的。

Chapter16.ArchitectureandRequirements

理解：

ASR。

ASR的几种获取方法。

QAW。

ASR：

架构重要需求，对架构有深远影响。

获取方法：

需求文档，采访涉众，理解商业目标，效用树。

QWA：

质量属性研讨会

是促进的、涉众关注的方法为了生成、优化、完善质量属性场景。

关注系统级问题，特别是软件在系统中的角色。

了解：

商业目标场景。

目标源：

提供目标的人或制品

目标主体：

涉众

目标物：

目标提供的实体

环境：

社会，法律，竞争力，客户，技术

目标：

目标源提出来的商业目标

目标度量：

可以测试的度量—一个人如何知道目标是否达成；通常包括时间构件，生命在什么时间前完成目标。

血统和价值：

声明目标的人自信程度；目标的波动性和价值。

理解：

PALM方法。

引出商业目标的方法。

有7个步骤；名义上研讨会需要一天半；可以讲出相关的商业目标的架构师和涉众参加。

掌握：

效用树。

Utilitytree

把ASR记录在一个地方的方法；根据对架构的影响和商业或使命价值，对每个ASR建立优先级；ASR都被做成场景；树的根是效用；第二层包括质量属性；第三城改进、细化质量属性；（H,H），最值得关注的ASR；涉众可以回顾效用树来确定自己的问题得以解决。

Chapter17.DesigninganArchitecture

理解：

GenerateandTest（架构设计的假设检验法）。

初始化、迭代、终结。

GenerateandTest（架构设计的假设检验法）：

把当前设计看成一个假设；当前设计是否符合需求；不符合，生成新的假设。

终结：

当所有的ASR都被满足；预算被耗尽。

掌握：

ADD方法。

Attribute-DrivenDesignModel属性驱动设计

包括多种技术；一种迭代的方法；不会生成一个完整的设计；不提供API或者签名；ADD输入：

需求（功能，质量，约束）；ADD输出：

containers（职责，相互作用，信息流）。

Step：

在系统中选择要设计的元素；

为选择的元素识别ASR

未选择的元素产生一个设计方法

为下一次迭代，选择输入

重复1-4，知道所有的ASR都被满足

Chapter18.DocumentingSoftwareArchitectures

理解：

架构编档的重要性。

架构文档的用途、读者。

重要性：

如果需要的人不知道他是什么，不能充分理解它，误解或误用它，就算是最好的架构也是没用的。

用途、读者：

架构文档必须是足够透明的，新的使用者能够很快理解，足够坚固的作为结构的蓝图，有足够的信息作为分析的依据；即是说明性（规定性）的又是描述性的；理解涉众对架构文档的使用是至关重要的；有三个用途：

教育，涉众交流的主要工具，系统分析和建设的基础。

了解：

如何选择视图进行编档。

建立一个涉众/视图表格

连接视图以减少数量

优先和划分等级

掌握：

如何对视图进行编档。

视图文档模版。

架构文档摘要信息。

如何对系统行为进行编档。

如何对质量属性进行编档。

对视图进行编档：

主要表示（视图中的元素和关系，通常是图，偶尔是表格或列表）；元素目录（详细描述元素和关系，包括元素及其属性、关系及其属性、元素接口、元素行为）；上下文图（如何和环境产生关系，目标是为了描述视图的范围）；可变性指南（可变点）；基本原理（为什么反映在视图中的设计是这样，提供可信的理由）

对系统行为进行编档：

提供元素间的交互顺序、并发机会以及加护的时间依赖性；完成每个视图通过描述每个视图元素是如何进行交互的；思考系统死锁的潜在性、在理想时间中完成一个任务的能力、最大的内存消耗；在视图文档元素目录中，行为有自己的部分；Notation：

Trace-orientedlanguage：

用例图、顺序图、通信图、活动图、消息顺序图、时序图、业务流程执行；comprehensivelanguage：

状态图。

对质量属性进行编档：

基本原理解—设计方法的选择应该包括讨论和权衡质量属性需求；架构文档通常包括到需求的映射，为了展示需求如何被满足；每一个质量属性需求将会有一个涉众的选区。

Chapter19.Architecture,Implementation,andTesting

理解：

实现与架构的一致性。

有四个方法：

将架构嵌入进代码，框架方法，代码模板方法，防止侵蚀。

掌握：

将架构嵌入代码。

框架方法。

代码模版方法。

防止架构侵蚀。

将架构嵌入代码：

架构作为注释

框架方法：

可重用的

代码模板方法：

热备份，放在固定的地方；优点：

有相似的属性，表现也相似；模板只需要调试一次；复杂的部分有有技术的人员完成并且交接给低技术人员

防止架构侵蚀：

用工具来执行架构约束；当侵蚀出现把文档标记为过时的；计划文档/代码同步

了解：

架构师在测试中的角色。

积极参与，计划测试，开发测试，解释测试，构造测试工具

Chapter20.ArchitectureReconstructionandConformance

了解：

架构重构的背景和目的。

背景：

假设你被赋予责任给一个已经存在的系统，但是你不知道它的体系结构，如何维持这个系统，如何管理它的进化来维持质量属性。

目的：

当文档不存在或过时时，记录架构；保证构造和设计的一致性；在架构重构中，从已有的制品中构建架构是逆向工程。

理解：

架构重构的阶段。

每个阶段的方法。

阶段：

原始视图提取（静态信息通过观察系统制品获得，动态信息通过观察系统的运行方式）；数据库构造（将提取的信息转换为标准的格式）；视图融合和操作（提高整体精度，创建一个融合的视图就是创建一个架构的假设）；架构分析（寻找冲突，测试，假设是否正确）

Chapter21.ArchitectureEvaluation

了解：

架构评审的3种形式及其特点。

轻量级架构评审。

架构评审的3种形式：

在设计阶段通过设计师评估（取决于决定的重要性）；

在设计阶段通过同行评审（持续几个小时或半天，在任一设计阶段）；

一旦架构被设计好通过外界人员评估（客观，有专业知识和经验，经理倾向于这种方式，评估完整的架构）。

轻量级架构评审：

基于ATAM，为了更小的，更少风险的项目；参与者通常是内部人员，并且数目少；步骤和阶段可以更快地执行；在一个项目中可以被当做同行评审执行数次。

掌握：

ATAM方法：

目的、参与人员、步骤、采用的方法、结论。

目的：

获取系统以及架构的业务目标，他还设计用于使用这些目标和涉众参与来使评估人员把注意力放到对实现这些目标重要的构架部分上。

参与人员：

评估小组（外部，3-5人，有能力的公正的）；项目决策者（项目管理人员，提供费用的用户，设计师必须愿意！

）；架构涉众（有一个既得利益，阐述构架应满足的质量属性目标，12-15人大型）

步骤：

ATAM方法的表述；商业动机的表述；架构的表述；对架构方法进行分类；生成效用树（场景被分配等级H,M,L）；分析架构方法；集体讨论并确定场景优先级；分析架构方法；展示结果。

结论：

简洁的构架表述；清楚的业务目标；质量需求；构架决策到质量属性的映射；敏感点、权衡点；有风险决策、无风险决策；风险主题集合。

Chapter26.ArchitecturesfortheCloud

了解：

云计算的特点、主要机制、技术。

特点：

按需自助服务；无处不在的；资源池；位置独立；快速的弹性；测量服务；多租户（共享）

机制：

Hypervision（虚拟机监控程序）；虚拟机；文件系统；网络

技术：

IaaS（cluster）；PaaS（stack）；Database（key-value；Documentcentric）

掌握：

云计算下的质量属性。

可用性（错误经常出现；云服务提供商保证云维持可用性；应用开发者假设实例会失败，万一失败建立检测和连接机制）

性能（新资源的响应时间可能不够；架构师要意识到应用程序的资源需求）

安全性（多租户会引入新的问题；组织需要考虑风险）

考题类型

选择题（30%）

简答题（30%）

分析设计题（40%）