SWJTU软件架构设计重点总结.docx

SWJTU软件架构设计重点总结.docx

《SWJTU软件架构设计重点总结.docx》由会员分享，可在线阅读，更多相关《SWJTU软件架构设计重点总结.docx（10页珍藏版）》请在冰点文库上搜索。

SWJTU软件架构设计重点总结

复习知识点重点：

整理了大部分，先发给大家，如果继续整理的或者把不恰当的地方给改正了会重新上传的

整理人员：

灿哥（6-10）、小黄（11-13、15）、小綦（21-25）、老卢（19、26-29）、乔哥（14、18）

水平有限，有不确切地方还请指正

1.组成派和决策派两种流派的软件架构概念的相同和区别

相同：

1）组成派和决策派是站在不同角度的软件架构概念

2）在具体的软件架构实践中，总是同时体现两派的架构概念

区别：

组成派的观点更关注软件，倾向于“组件+交互”的思想；决策派的观点更关注人，倾向于重大决策集合的思想，除了结构和行为，还关注一些非功能的因素。

2.分离关注点的三种方法

1）通过职责划分来分离关注点

2）利用软件系统各部分的通用性不同进行关注点的分离

3）通过不同粒度级别分离关注点

3.框架和架构的联系和区别

联系：

1）框架和架构的出现，都是为了解决软件系统日益复杂所带来的困难而采取“分而治之”思维的结果。

先大局后局部，就出现了架构；先通用后专用，就出现了框架。

2）为了尽早验证架构设计，可以将关键的通用机制甚至整个架构以框架的方式进行实现。

3）软件架构可以借助框架来构造。

区别：

1）框架是软件，架构不是软件。

2）引入软件框架之后，整个开发过程变成了“分两步走”，而架构决策往往会体现在框架之中

3）架构是问题的抽象解决方案，他关注大局而忽略细节；而框架是通用半成品，必须根据具体需求进一步定制开发才能变成应用系统

4.简述软件架构的作用

软件架构的作用包括以下几个方面：

1）对新产品开发的作用：

完成从面向业务到面向技术的转换，在鸿沟上架起一座桥梁，具体包括：

上承业务目标，下接技术决策，控制复杂性，组织开发，利用迭代开发和增量交付，提高质量。

2）对产品线开发的作用：

固化核心知识，提供可重用资源，缩短推出产品的周期，降低开发和维护总成本，提高产品质量，支持批量定制。

3）对软件维护的作用：

软件架构是软件维护的基础。

4）对软件升级的作用：

软件架构会限制软件的升级力度。

5.理解视图的概念以及多种视图多种角度进行架构设计的意义

视图概念：

一个架构视图是对于从某一视角或某一点上看到的系统所作的简化描述，描述中涵盖了系统的某一特定方面，而省略了与此方面无关的实体。

多视图多角度架构设计的意义：

基于多视图的架构设计方法在一定程度上将各类需求分别对待，通过不同的架构设计视图分别满足它们，从而确保重要的需求一一被满足。

6.概念性架构和实际架构的区别点和共同点

接口：

在实际架构中，借口占据非常核心的地位；而概念性架构中没有接口的概念。

子系统：

实际交媾忠实通过子系统和模块来分割整个系统；并且子系统往往有明确的接口；

而概念性架构中只有抽象的组件，这些组件没有接口只有职责，一般是处理组件、数据组件或连接组件中的一种。

交互机制：

实际架构中的交互机制是“实在”的，如基于接口编程、消息机制或远程方法调用等等；而概念性构架中的交互机制是“概念化”的。

共同点：

该娘型架构和实际架构都满足软件架构的该娘，无论是“架构=组件+交互”，还是“架构=重要决策集”。

7.软件架构设计四条策略的策略内容、针对问题和关键点

策略一：

全面认识需求；内容：

弥补非功能需求的缺失；关键点：

是否遗漏了至关重要的非功能需求；针对问题：

对需求的理解不系统、不全面，对非功能需求不够重视。

策略二：

关键需求界定架构；内容：

“需求入架构出”的理解过于简单粗糙不能适应实践要求；关键点：

能否驯服数量巨大且频繁变化的需求；针对问题：

对于时间和质量的矛盾，颁发不足，处理草率。

策略三：

多视图探寻架构;内容：

架构是开展系统化团队开发的基础，应当为不同涉众提供指导和限制；关键点：

能否从容地设计软件架构的不同方面；针对问题：

架构设计方案覆盖范围严重不足许多关键决定被延迟，由实现人员仓促决定。

策略四：

尽早验证架构；内容：

架构设计方案应解决重大技术风险，并尽早验证架构；关键点：

是否及早验证架构方案并做出了调整；针对问题：

假设架构方案是颗星的，知道后期才发现问题，造成大规模返工。

8.理解按问题深度和问题广度两个角度解决问题的方法在软件架构设计中的具体体现

一方面，软件架构从大局着手，就技术方面的重大问题作出决策，构造一个具有一定抽象层次的解决方案，而不是将所有熙街统统展开，从而有效地控制了“技术复杂性”，属于“按问题深度分而治之”。

另一方面，有了软件架构设计后，从而可以把不同模块分配给不同小组分头开发，独立地并行工作。

对“人尽其才”也有好处，不同小组成员需要精通的技术各不相同。

软件架构为开展系统化的团队开发奠定了基础，解决了“管理复杂性”问题，属于“按问题广度分而治之”。

9.软件架构要设计到什么程度

由于项目、开发团队情况的不同，软件架构设计的成都会有不同；

软件架构应当为开发人员提供足够的指导和限制。

10.常见的高来高去式架构设计三种症状和对应决策

11.能够简要描述软件架构设过程的每个步骤

12.需求捕获、需求分析和系统分析三个活动的区别

需求捕获

需求分析

系统分析

●理解用户所从事的工作

●了解软件系统要在哪方面帮助用户工作

●挖掘、整理软件系统要“做什么”

●在变更不可避免的，涉及意愿不明朗的情况下，UP更推崇通过迭代进行需求分析—进化式需求

●解决“怎么做”的问题

●提出可行的逻辑方案

●研究并抽象地表现软件系统

各阶段的制品：

需求捕获：

需求采集卡，《需求调查报告》

需求分析：

《软件需求规格说明书》（SRS），SRS一般规格

系统分析：

结构化分析，数据流图；面向对象分析，分析类图‘鲁棒图，顺序图

13.软件需求的类型以及每种类型的含义

功能需求：

描述要开发的软件系统应该做什么，既包括为用户提供的服务‘又包括本系统为其他系统提供的服务。

非公能需求：

又分为质量属性和约束。

软件质量属性又分为运行期质量属性和开发期质量属性，运行期质量属性是软件系统在运行期间，最终用户可以直接感受到的一类属性，这些质量属性直接影响这用户会软件产品的满意度；开发期质量属性是开发人员、开发管理人员和维护人员都非常关心的，队最终用户而言，这些质量属性只是间接地促进用户需求的满足；

约束需求规定了开发软件系统时必须遵守的限制条件。

14.理解约束需求和功能需求、质量属性需求之间的关系

软件需求分为功能需求和非功能需求，分功能需求又分为质量属性和约束。

各类需求的易变更性不同。

约束需求规定了开发软件系统时必须遵守的限制条件。

功能需求描述要开发的软件系统要做什么,既包括为用户提供的服务，又包括本系统为其他系统提供的服务。

质量属性分为运行期质量属性和开发期质量属性。

15.理解各类需求的易变更性不同

软件系统的各类需求的“易变更性“并不相同。

●功能需求最易变，而质量属性需求最稳定

功能需求的易变性中潜藏着两类不易变性：

功能需求集中存在少量长期稳定的功能

功能点本身趋于稳定

●约束性需求的稳定性则稍差，技术趋势发生变化、法律规范重新界定和用户组织调整改组，都有可能是约束行需求变更。

16.能够读懂质量属性关系矩阵并理解需求折衷的含义

17.掌握ADMEMS矩阵方法

18.各种常用的用例技术（用例图、用例简述、用例规约、用例实现）与需求之间的关系

19.领域模型的概念、意义和作用

领域模型是对实际问题领域的抽象表示，它专注于分析问题领域本身，发觉重要的业务领域概念，并建立业务领域概念之间的关系。

领域模型的现实世界挂念累的一种表示，不是软件组件的一种表示。

它不是描述软件类得图集，也不是有着职责的软件对象。

重要作用体现为以下三方面：

探索复杂问题、固化领域知识；

决定功能范围、影响可扩展性；

提供交流基础、促进有效沟通。

20.在软件架构设计过程中确定关键需求的意义

21.概念性架构设计的步骤

1）鲁棒性分析：

通过分析用例违约中的事件流，识别出实现用例规定的功能所需的主要对象及其职责，行程以职责模型为主的初步设计

2）引入架构模式：

也成为架构风格，核心是架构机制

3）质量属性分析：

采用“属性-场景-决策”表

22.几种分层架构模式的特点

1：

按逻辑层分层（Layer）：

重视职责的划分，职责之间常常是上层使用下层的关系，但是根本不关心上层和下层是否分布在不同的机器上

2：

按物理层分层（Tier）：

指分布在不同机器上的软件单元，不同物理层之间必须有跨机器访问的能力，可以通过远程调用或通信协议等方式。

是看“能分布”的能力，不是看“实际部署情况”；可伸缩性

3：

按通用性分层：

将通用性不同的部分划归不同的层，以此作为系统的总体切分方式。

一般而言，通用程度越大，所处的层级就越靠下

4：

技术堆叠：

不是独立的架构模式，而是基于分层架构提供的进一步说明

23.掌握“属性-场景-决策”表法

“属性-场景-决策”表法使软件架构设计的决策过程从“黑盒”变成“灰盒”

好处：

1.可操作性强。

质量熟悉需求是笼统的目标，而一组质量场景使之明确化

2.避免过度设计。

借助“属性-场景-决策”表对质量场景进行评估，通过全红场景发生的概率和遗漏它的代价，决定是否应该满足该场景的要求

3：

便于系统升级时参考。

24.五视图设计方法中的每种视图的含义和目标

逻辑架构图：

职责划分，职责间协作

开发架构图：

程序单元，程序单元组织

数据架构图：

持久数据单元，数据存储格式

运行架构图：

控制流，控制流组织

物理结构图：

物理节点，物理节点拓扑

25.掌握划分子系统的三种必用策略

1：

分层的细化：

分层最常用的架构模式，在架构设计初期，100%的系统都可以用分层架构，就算随着设计的深入而采用了其他的架构模式也未必和分层架构矛盾。

于是，架构师最熟知、最自然的划分模式就是分层的细化。

2：

分区的引入：

为了支持迭代开发，逻辑架构设计中必须引入分区，分区是一个单元，其粒度比层要小。

一旦架构师针对每个层进行了分区设计，“深度优先”式的迭代开发就非常自然。

3：

机制的提取：

机制是指预先定义好的、能够完成预期目标的、基于抽象角色的协作方式。

机制提取有利于底稿系统概念的完整性，有利于建立起所有涉众对软件架构的共同认识。

26.逻辑架构设计的整体思维套路

要点如下：

1）质疑驱动。

2）机构设计和行为设计相分离。

3）先考虑机构方面的切分，然后，让切分出的职责协作起来，验证能否完成功能。

27.掌握数据分布的六种策略及其含义

独立Schema：

当一个大系统有相关的多个小系统组成，且不同小系统具有互不相同的数据库Schema定义，这种情况称为“独立Schema”；

集中：

只一个大系统必须支持来自不同地点的访问，或者该系统有相关的多个小系统组成，而持久集中化数据进行集中化的、统一的格式的存储；

分区：

分区方式包含水平分区和垂直分区两种；

复制：

在整个分布式系统中，数据保存多个副本，并且以某种机制（实时或快照）保持多个数据副本之间的数据一致性，这就是复制方式的数据分布策略；

子集：

“子集”是“复制”的特殊方式，就是某节点因功能或非功能考虑而保存全体数据的一个相对固定的子集；

重组：

业务决定功能，功能决定模型，当遇到模型不同时，一般都能从功能差异的角度找到答案。

28.原型技术及其的分类

垂直演进原型：

“多次交付，增量交付”的思想，垂直演进原型方法强调逐步提供用户所要求的功能。

在实践中，我们应当注重每个此次将提交的功能必须是可用的并具有接近产品发布级的质量，而不是有些实践者所认为的无需到达发布级质量。

29.验证软件架构设计的具体步骤

重点复习的案例

1.PASS系统中使用ADMEMS矩阵方法对需求对需求进行二维梳理

2.PMTool系统的领域建模过程中状态图的设计

3.银行储蓄系统“销户”时鲁棒图的设计

4.MyZip逻辑架构设计

5.数据架构设计的三个案例：

电子病历vs。

身份验证案例、服务受理系统vs。

外线施工管理系统案例、铃声下载门户案例