软件体系结构复习笔记

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
 
 
 
Cha1
软件架构概念：
    是系统的一个或多个结构，它们由软件组件，组件的外部可见属性以及组件之间的关系组成。
    组件的外部可见属性是指其他组件对该组件所做的假设。
软件架构的多个结构：
    静态的角度：
        模块结构
        分析类结构
        类结构
    动态的角度：
        进程结构
        数据流
        控制流
        使用结构
        调用结构
        层次结构
    部署的角度：
        物理结构
 
架构不止是功能需求的结果
 
Ch2:
需求包含三要素:功能，质量，限制条件
质量属性：系统在其生命周期过程中所表现出来的各种特征
质量属性的关系：
    一个质量属性的获取对其他质量属性可能产生正面或者负面的影响。
    任何质量属性都不可能在不考虑其他属性情况下单独获取。
质量属性举例：
    运行时可见属性：性能，可用性，安全性
    维护时可见属性：可修改，可扩展，可移植
    易用性：
        可学习性
        可记忆性
        错误避免
        错误处理
        满意度
 
质量场景创建的参与人员：
    最终用户
    系统管理员
    维护人员
    客户
    开发组织
构架本身的质量属性：
    一致性
    正确性和完整性
    可构建性
生成质量属性场景的目的和意义：
    帮助构架师生成有意义的质量属性需求
    使质量属性需求的描述规范化
    某一场景是一类场景的代表，系统将以完全相同的方式做出反应。
构架的商业属性（限制）：
    上市时间
    成本和收益
    预期系统生命周期长短
    目标市场
    推出计划
    与老系统的集成
 
第三章：
软件架构样式的种类：
    以数据为中心
    数据流
    虚拟机
    调用-返回
    独立组件
    C/S
构架的异质性：
    局部异质
    层次异质
    并行异质
 
ISO/OSI七层参考模型：
    应用层
    表示层
    会话层
    传输层
    网络层
    数据链路层
    物理层
 
软件框架：
    提取特定领域软件的共性部分形成的体系结构。
框架和架构的关系：
    框架不是构架。
    构架确定了系统整体结构、层次划分、不同部分之间的协作等设计老驴。
    框架比构架更具体，更偏重于技术。
    一个框架对应一个架构，一个架构可以有多个框架。
 
第四章：
架构战术：影响质量属性的设计决策。
架构策略：架构中所采用的战术的集合。
可用性的战术：
    错误检测的战术：
        回声
        心跳
        异常
    错误恢复的战术：
        表决
        主动冗余
        被动冗余
        备件
        状态再同步
        检查点/回滚
    错误预防的战术：
        进程监视器
        从服务中删除
        事物
可修改性的战术：
    局部化修改的战术：
        维持语义一致性
        预期期望的变更
        泛化模块
        限制可能的选择
    防止连锁反应的战术：
        信息隐藏
        维持现有的接口
            添加结构
            添加适配器
            提供一个占位程序
    推迟绑定时间的战术：
        运行时注册
        配置文件
        多态
        组件更换
        遵守已定义的协议
实施性能的战术：
    影响响应时间的两个基本因素：
        资源消耗
        阻塞时间：
            资源争用
            资源的可用性
            对其他计算的依赖性
    控制对资源需求的战术：
        减少处理一个事件所需要的资源：
            提高计算效率
            减少计算开销
        减少需要同时处理：
            管理事件率
            控制采样频率
        控制系统的使用：
            限制执行时间
            限制队列的大小
    资源管理的战术：
        引入并发
        维持数据或计算的多个副本
        增加可用资源
    资源仲裁常见的调度策略：
        先进/先出
        固定优先级：语义重要性；时限时间单调；速率单调
        动态优先级调度：轮转；时限时间最早优先
        静态调度
实施安全性的战术：
    用于抵抗攻击的战术：
        对用户进行身份验证
        对用户进行授权
        维护数据的机密性
        维护完整性
        限制暴露的信息
        限制访问
    检测攻击的战术：
    从攻击中恢复的战术：
        回复状态
        识别攻击者
易用性的战术：
    运行时战术：
        维持任务的一个模型
        维护用户的一个模型
        维护系统的一个模型
    设计时战术：
软件架构样式与战术的关系：
    软件架构样式是从战略层面解决质量问题，战术是从具体部署上给猪解决质量问题的局部策略。
 
 
第五章：设计构架
基于构架的开发步骤：
    为软件系统创建一个商业案例
    弄清系统需求
    构建构架
    正确表述此构架，并与有关各方进行交流
    对此构架进行分析和评价
    实现基于构架的系统并保证与构架相一致
    系统维护时，构架文档应同步维护
构架驱动的因素：
    功能
    质量
    部分限制条件（限制条件的某个子集）
 
良好架构的评判原则（判断题常考）：
    设计构架过程的建议:
        架的设计应该由一门设计师来完成
        设计师应该全面掌握对系统的技术需求，以及对各项定性指标的优先级清单。
        构架的文档完备，并蚕蛹所有人员认可的文档形式。
        构架设计文档应让各风险承担者积极评估。
        通过对构架分析，得出明确的定性与定量指标。
        构架设计应该有助于具体实现。
        允许构架带来一定的资源争用，并给出可行的解决方案。
    关于构架的结构的建议：
        构架由定义良好的模块组成，各个模块的功能划分应该基于信息隐藏。
        模块的划分应体现出相互独立的原则。
        把计算机基础结构的特性封装在一定的模块
        构架尽量不依赖某个特定版本的商品产品或工具。
        产生数据的功能和使用数据的功能应分属于不同的模块。
        对并发系统，构架应充分考虑进程与模块结构的不对应。
        进程编写要考虑到与特定处理器的关系，并容易改变关系。
        构架应尽量采用一些已知的设计模式。
 
ADD构架设计的步骤：
    样本输入
    选择要分解的模块
    根据下列5个步骤对模块进行求精（重点）：
        从具体的质量场景和功能需求集合中选择构架驱动因素。
        选择满足构架驱动因素的构架模式。
        实例化模块并根据用例分配功能，使用多个视图进行表示
        定义子模块的接口
        验证用例和质量场景并对其进行求精，使它们称为子模块的限制。
    对需求进一步分解的每个模块重复上述步骤。
创建骨架系统：
    思想：提供一种基本能力，以一种对项目有利的顺序实现系统的功能。
    好处：
        提高开发效率，鼓舞士气。
        能更早发现复杂的依赖关系。
        使开发人员更多关注最难实现的部分。
        能够缩短系统集成时间，降低其成本，并使集成成本更明确。
        便于评审和测试。
    步骤：
        实现处理构架组件交互的软件部分
        选择组件逐步添加到系统中。
        逐步进行测试。
架构师的职责：
    了解所在组织的业务目标，使架构更好地支持业务目标。
    规划产品的开发与严禁
    规划和建设架构级的重用etc
 
 
分析软件构架的原因(重要):
    它是风险承担者之间的交流平台，是早期设计决策的体现，是可传递的模型。
    软件质量不可能在软件开发的最后阶段追加上去，必须在设计之初就考虑到。
 
第七章：
构架评审：
    成本：
        人员时间成本
        构架评审部门的组织开销
        构架评审部分要求高级设计人员参与的代价（不就是人员时间成本吗。。。
    收益：
        及早发现构架中存在的问题
        构架的改进
        财务收益
        强制位评审做准备
        捕获构架设计的基本思想
        验证需求的有效性
评审实施：
    按问题的重要性进行分类
    强调那些与偶家相符或相悖的重要问题
    必须记载评审中所提的每个问题
构架评审的主要指导原则：
    把由独立部门实施的正规的构架评审作为项目开发周期规划的一部分。
    选择评审的最佳时间，尽早预审一次。
    选择恰当的评审技巧
    签署评审合同
    限制所要品神的质量属性的个数
    要保证评审小组中有构架方面的专家，领域专家，资料员，后勤员。
    一定要有系统设计师。
    收集各种场景数据，并在此基础上形成评审清单。
 
第八章：
架构权衡分析法（ATAM)：
    特点：不仅可以揭示出构架满足特定质量目标的情况，而且可以让我们更清楚地认识质量目标之间的联系。
    输入：用场景集合捕获的质量要求。
    输出：
        简介的框架表述
        表述清楚的业务目标
        构架决策到质量需求的映射
        所确定的敏感点和权衡点集合
        有风险决策和无风险决策
        风险主题的集合
    阶段：
        评估小组和项目决策者共同决定评估细节
        评估小组收集信息和分析
        风险承担着参与评估
        评估小组自我检查和改进，提交书面报告
    步骤（重点）：
        ATAM方法的表述
        商业动机的表述
        构架的表述
        对构架方法进行分类
        生成质量属性效用树
        分析构架方法
        集体讨论并确定场景优先级
        再次分析构架方法
        结果的表述
 
第九章：
    文档：
        目的与作用：让不同的风险承担者都能快速找到和理解他们需要的信息。
        基本原则：从读者的角度出发。
 
 
 
 
    
 
 
 
 

 

作者： CrazyKK

ex-ACMer@hust，stackoverflow-engineer@sensetime

说点什么

您将是第一位评论人！

提醒
wpDiscuz