《软件体系结构与设计》笔记——第一、二章

第一章 概述

1.软件开发知识的半衰期为3年。
2.软件工程是一种层次化的技术，支持软件工程的根基在于“质量关注点”层，基础是“过程”层，过程上面是方法，方法上面是工具。
3.跨越软件工程过程和实践的通用原则主要是：

1. 为最终用户提供价值；
2. 保持简洁；
3. 维护可见的东西；
4. 认识（必须理解别人将消费你所生产的产品）；
5. 面向未来；
6. 计划复用；
7. 认真思考

4.指导实践的核心原则是指导过程的原则+指导实践的原则
（PS：？？啥呀，上面不是说了。。。哦我懂了，上面的只是通用原则，下面分别阐述每个原则）

1）指导过程的原则：

1. 敏捷（提供判断的方法）；（敏捷就是要尽可能快地将软件提供给用户）
2. 每一步都关注质量；
3. 做好适应的准备；
4. 建立一个有效的团队；
5. 建立沟通和协调机制；
6. 管理变更；
7. 评估风险；（评审的目的：为了提供反馈，用于纠正模型中的错误，改变误解，并补充不经意遗漏的功能和特性）
8. 创造能给别人带来价值的工作产品。

2） 指导实践的原则：
（1）重要目标：按时交付包含了满足所有利益相关者要求的功能和特性的高质量、可运行的软件；
（2）核心原则：

1. 分治策略；
2. 理解抽象的使用；
3. 力求一致性；
4. 关注信息传送；
5. 构建能展示有效模块化的软件；
6. 寻找模式；
7. 在可能的时候，用大量不同的观点描述问题及解决方法；
8. 要对软件进行维护。
   
   

5.指导框架活动的原则：
（1）沟通原则：定义全局目标。

1. 倾听、有准备的沟通、有人推动、最好当面沟通、记笔记并且记录所有决定；
2. 保持通力协作、把讨论集中在限定的范围内;
3. 可用图形解释难以表述的内容;
4. 学会转换话题;
5. 要协商要双赢。

（2）策划原则：包括一系列管理和技术实践，定义一个路线图

1. 理解项目范围；
2. 用户参与策划；
3. 计划的制订应按照迭代的方式进行
4. 基于已知的估计、计划时考虑风险
5. 保持脚踏实地；
6. 调整计划粒度；（粒度：项目计划细节的精细程度）
7. 制定计划确保质量；
8. 描述如何适应变化；
9. 跟踪并调整计划。

（3）建模原则：更好地理解需要构建的实体。（建模的目的：加深对要完成的工作的理解，并为软件开发人员提供技术指导）
（4）构造原则
（5）部署原则

6.重点讲建模原则：
1）敏捷模型建模原则：

1. 主要目标是构建软件而不是创建模型；
2. 不要创建任何不需要的模型；
3. 尽量创建能描述问题和软件的最简单模型；
4. 明确描述创建每一个模型的目的；
5. 调整所开发模型来适应待开发系统；
6. 构建有用而不是完美的模型；
7. 模型的构造方法不要过于死板、相信直觉；
8. 尽可能快地获得反馈（评审）。

2)软件工程中要创建两类模型，需求模型和设计模型
（1）需求模型（分析模型）：
——通过在信息域、功能域和行为域中描述软件来表达客户需求。
——原则：

1. 必须描述并理解问题的信息域；
2. 必须确定软件所要实现的功能；
3. 必须描述软件的行为；
4. 描述信息、功能和行为的模型必须以一种能揭示分层细节的方式分解开来；
   （把大的问题分解划分成很多易于理解的子问题）
5. 分析任务应该从本质信息转向实现细节；

（2） 设计模型：为系统提供各种不同的视图
——表述了可以帮助开发者高效开发软件的特征，即架构、用户界面及构件细节。

1. 设计可追溯需求模型；
   （设计模型的咯咯咯元素都应该能追溯到需求模型）
2. 始终关注待建系统的架构；
   （架构是待建系统的骨架，决定着系统接口、数据结构等等）
3. 数据设计与功能设计同等重要；
4. 精心设计接口；
5. 用户界面设计必须符合最终用户要求；
6. 构件级设计应是功能独立的；（高内聚）
7. 构件之间及构件与外部环境之间低耦合；
8. 设计模型应易于理解；
   （设计的目的是向人们传递信息)
9. 设计应该迭代式进行。

补充：需求模型到设计模型的转换：
(1)基于场景的元素（用例文本/图、活动图、泳道图）——接口设计
(2)基于类的元素（类图、分析包、CRC（类-职责-协作者模型）、协作图）——数据/类设计、体系结构设计、构件级设计
(3)面向流的元素（数据流图、控制流图、处理叙述）——体系结构设计、接口设计、构件级设计
(4)行为元素（状态图、顺序图）——接口设计、构件级设计

由图我们可以看出：体系结构设计是在数据设计和接口设计之间的。

7.构造原则
——构造活动包括一系列编码和测试任务，从而向客户交付可运行软件做好准备。
——测试的好处：

1. 表明软件功能的执行按照规格说明进行的，行为需求和性能需求得到满足。
2. 测试收集的数据为软件的可靠性提供一个很好的说明，为软件质量提供了一些说明；
3. 但是只能显示现存的错误和缺陷哦。

8.部署原则
——部署发生在向客户展示每个软件增量的时候，包括：交付、支持和反馈。
——客户对软件的期望必须得到管理、完整的交付包应该经过安装和测试、技术支持必须在软件交付之前就确定下来、必须提供适当的说明材料、有缺陷的先改正后交付。

重点：什么是软件体系结构

（1）软件体系结构提供了待构造系统的整体视图，其设计主要是建立计算机系统所需的数据结构和程序构件，它需要考虑系统所采取的体系结构风格、系统组成构件的结构和性质，以及系统中所有体系结构构件之间的相互关系，数据设计是软件体系结构设计的一个组成部分。
（2）3个设计层次

• 体系结构级：包括系统性能和构件之间的整体联系，构成元素是模块，模块通过各种方法互连；通过操作算子将子系统组装成一个系统；
• 代码级：包括算法和数据结构，构成元素是编程语言原语，比如数值、字符、指针以及控制线程。基本的操作算子是算法和程序设计语言提供的数据操作原语，组装机制包括记录、数组、过程。
• 执行级：包括存储器映射、数据格式配置、堆栈和寄存器的分配，构成元素是硬件所支持的位模式。使用机器代码来描述操作和组装。

在体系结构的层次上，相关的系统级别的问题包括了容量、吞吐量、一致性、构件的兼容性等。

（3）软件体系结构的定义：
我选了一条：
软件体系结构是具有一定形式化的结构化元素，即构件的集合，包括处理构件、数据构件和连接构件。处理构件负责对数据进行加工，数据构件是被加工的信息，连接构件把体系结构的不同部分组合连接起来。
（4）作用：

1. 有助于对计算机系统开发感兴趣的各方开展交流。
2. 体系结构突出了早期的设计决策，对后期工作有深远的影响；
3. 体系结构“构建了一个相对小的、易于理解的模型”，该模型描述了系统如何构成以及构件如何一起工作。

（5）什么是构件呢？
参考：什么是构件

我的理解：可以实现某个功能的独立的单元。构件可以是客户机/服务器、数据库或分层系统的某一层；然后构件之间，可以通过接口联系起来，实现更强大的功能。
（6)软件体系结构的4+1视图：

(7)体系结构的设计原则

1. 抽象原则：集中表现十五的主要特征和属性，隐藏和忽略细节部分，概括了具有相同特征的事物。
2. 分而治之原则：大问题分解为小问题，包括横向分解和纵向分解。
   *横向分解:从底层基础到上层问题的方式，将问题分解成相互独立的层次。每层完成局部问题，并为上次提供支持。
   *纵向分解：在每层上，将问题分解成多项，相互配合，实现完整的解。
3. 封装和信息隐藏原则：减少各部分的依赖程度，增强可维护性。
4. 模块化原则：模块是软件被划分成独立命名的，并可被独立访问的成分。
5. 高内聚和低耦合：内部特性与外部联系
6. 关注点分离原则：所要适应的内容。关注点设定，非关注点复用
7. 策略和现实分离
8. 接口和实现分离

第二章 理解需求

（1）什么是需求工程：
——需求工程：RE，致力于不断理解需求的大量任务和技术。从软件过程的角度看，RE发生在与客户沟通活动和为一般的软件过程定义的建模活动过程中，其任务是为了设计和构建活动建立一个可靠坚固的基础，它必须适应过程、项目、产品和人员工作的需要。

• 我的理解：需求工程，说小一点，将用户的想达成的目标、想收获什么样的效果，即需求，通过适合的方法，梳理得更加有逻辑性、条理性，并且，最终写出需求规格说明书，作为依据。当然它有发生在与客户沟通活动中，但是更重要的是，要真正理解客户的需求，并通过软件建模活动什么的，将需求实体化。

（2）需求工程过程通过执行7个不同的活动来实现：

其中起始、导出和精华属于项目的起始阶段
（3）需求工程师的工作：把所有利益相关者（“直/间接从中获益的人）提供的信息（包括不一致/矛盾的）分类，分类的方法应该便于决策制定者为系统选择一个内部一致的需求集合。
（4）收集需求的目的是识别问题，提出解决方案的要素，协商不同的方法以及在有利于完成目标的氛围中确定一套解决需求问题的初步方案。（识别——>初步方案）
（5）在需求的起始阶段，基本问题和问题的答案确定了问题的范围和对解决方案的整体理解。
（6）QFD质量功能部署：是一种将客户要求转化成软件技术需求的质量管理技术，其目的是”最大限度地让客户从软件工程过程中感到满意“。为达到这个目标，QFD强调理解"什么是对客户有价值的”，然后在整个工程活动中部署这些价值。
——QFD确认三类需求：

1. 正常需求：和客户开会时确定的针对某产品/系统的目标。若实现则满足客户。（eg：图形显示类型、特定的系统功能、性能）
2. 期望需求：需求隐含在产品或系统中，并且可能时非常基础的，以至于客户没有显示地说明，但是缺少会导致客户不满。（人机交互的易用性、整体运行的正确性和可靠性、软件安装的简易性）
3. 令人兴奋的需求：需求反映了客户期望之外的特点，实现会使客户非常满意。（多重触控技术的触摸屏，可视语音邮箱）

（7）用户场景：场景通常称为用例，它提供了将如何使用系统的描述。用例从某个特定参与者的角度出发，采用简明的语言描述一个特定的使用场景。
（8）开发用例

1. 撰写用例的第一步是确定故事中所包含的“参与者”；
2. 参与者是任何与系统或产品通信的事物，且对系统本身而言参与者是外部的。（参与者不等于最终用户）

（9）需求模型的特定元素取决于将要使用的分析建模方法。分析模型的目的是为基于计算机的系统提供必要的信息、功能和行为域的说明。