高级软件工程学习总结

REST即REpresentational State Transfer的缩写，可以翻译为”表现层状态转化”。有表现层就有背后的信息实体，信息实体就是URI代表的资源，也可以是一种服务，状态转化就是通过HTTP协议里定义的四个表示操作方式的动词：GET、POST、PUT、DELETE，分别对应四种基本操作：

GET用来获取资源；
POST用来增加资源；
PUT用来更新资源；
DELETE用来删除资源。

2.6 模块化的基本原理

模块化是指软件开发时各部分相对独立，以便可以单独开发每一个部分。模块化的原理是关注点的分离，分解成易解决的小问题，降低思考负担。每个模块只有一个功能，易于开发，并且bug会集中在少数几个模块内，容易定位缺陷，也更加容易维护。一般用内聚度和耦合度来衡量模块化程度。

2.7 耦合的概念

耦合度是指软件模块之间的依赖程度，一般可以分为紧密耦合、松散耦合和无耦合。在软件设计中追求的是松散耦合。

2.8 耦合度划分

无耦合：两模块之间没有直接关系。完全通过主模块来控制和调用。
数据耦合：两个模块之间通过简单数据参数来交换输入、输出信息。
标记耦合：一组模块通过标记表传递记录信息。
控制耦合：一个模块通过传递开关、标志、名字等控制信息，明显的控制选择另一个模块的功能。
外部耦合：一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数传递该全局变量信息。
公共耦合：一组模块访问同一公共数据环境。
内容耦合：一个模块直接修改另一个模块的数据，或直接传入另一个模块。

2.9 通用接口的定义方法

参数化上下文。通过参数来传递上下文的信息，而不是隐含上下文环境。
移除前置条件。
简化后置条件。

2.10 线程的基本概念

线程是操作系统调度的最小单位。它包含在线程中，是进程中的实际运作单位。一个线程指的是进程中一个单一顺序的控制流，一个进程中可以并发多个线程，每条线程并行执行不同的任务。一般默认一个进程中只包含一个线程。

2.11 可重入函数的概念

可由多于一个任务并发使用，不比担心数据错误。

2.12 可重入函数的基本要求

不返回指向静态数据的指针
不直接使用全局变量，可以使用局部变量接收全局数据的拷贝
不调用可重入函数
所有数据由函数调用者提供

2.13 什么是线程安全

代码中多个线程同时运行同一段代码而不会造成错误。

2.14 可重入函数和线程安全之间的关系

可重入函数不一定是线程安全的，不可重入函数一定是线程安全的

2.15 看待软件质量的不同角度

产品的角度：软件产品本身的质量特点
用户的角度：软件是否对用户有帮助，是否有良好的的用户体验
商业的角度：能否创造商业价值

2.16 本地化外部接口的含义

不直接通过API调用外部代码，而是在代码中调用本地的外部接口，本地的外部接口再去调用外部代码。

第三章从需求分析到软件设计

3.1 需求分析

需求就是对用户期望的软件行为的表述；
获取需求就是需求分析师通过关注用户的期望和需要，从而获得用户期望的软件行为，然后对其进行表述的工作。
需求分析是在获取需求的基础上，进一步对软件设计的对象或实体的状态、特征和行为进行准确描述或建模的工作。

3.2 需求类型

功能需求：根据需要的活动描述需要的行为。
质量需求：描述软件必须具备的一些质量特征。
设计约束：设计决策，如平台或接口组件的选择。
流程约束：对可用于构建系统的技术或资源的限制。

3.3 高质量需求的特点

需求是可测试的
是可解决冲突的，不同的利益相关者有不同的要求，解决潜在的冲突想法，同时需要考虑需求的优先级。
具备一些需求特征：正确的，无二义性的，完整的，可行的，无与主要目标不相关的需求，可测试的，可追溯的。

3.4 需求分析的两类基本方法

原型化方法：在项目开发早期，用户对系统只有模糊的想法，开发人员对所要解决的问题也模糊不清。在开发过程中，用户可能会产生新的要求，开发者也可能会遇到没有预料的困难。为了解决这些问题，逐渐形成了软件系统的快速原型概念。在形成一组基本需求后，通过快速分析方法构造出待建的原型版本，然后在开发过程中不断修改得到新的原型版本。这一过程循环往复直至得到满足客户需求的系统。原型化方法可以很好地整理出用户接口方式，比如界面布局和交互操作过程。
建模的方法可以快速给出有关事件发生顺序或活动同步约束的问题，能够在逻辑上形成模型来整顿繁杂的需求细节。

3.5用例的三个抽象层次

抽象用例：只要用一个干什么、做什么、或完成什么业务任务的动名词短语，就可以非常精简地指明一个用例；
高层用例：需要给用例的范围划定一个边界，也就是用例在什么时候什么地方开始，以及在什么地方结束；
扩展用例：需要将参与者和待开发系统为了完成用例所规定的业务任务的交互过程一步一步详细地描述出来，一般我们使用一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来。

3.6 用例建模的基本步骤

第一步，从需求表述中找出用例，往往是动名词短语表示的抽象用例；
第二步，描述用例开始和结束的状态；
第三步，对用例按照子系统或不同的方面进行分类，描述用例与用例、用例与参与者之间的上下文关系，并画出用例图；
第四步，进一步逐一分析用例与参与者的详细交互过程，完成一个两列的表格将参与者和待开发软件系统之间从用例开始到用例结束的所有交互步骤都列举出来扩展用例。

3.9 用例满足的四个必要条件

它是不是一个业务过程？
它是不是由某个参与者触发开始？
它是不是显式或隐式地终止与某个参与者？
它是不是为某个参与者完成了有用的业务工作？

3.10 业务领域建模的基本步骤

收集应用业务领域的信息。聚焦在功能需求层面，也考虑其他类型的需求和资料；
头脑风暴。列出重要的应用业务领域概念，给出这些概念的属性，以及这些概念之间的关系；
给这些应用业务领域概念分类。分别列出哪些是类、哪些属性和属性值、以及列出类之间的继承关系、聚合关系和关联关系。
将结果用UML类图画出来。

3.11 统一过程

统一过程的核心要义是用例驱动、以架构为中心、增量且迭代的过程。用例驱动就是用例建模得到的用例作为驱动软件开发的目标；以架构为中心是后续软件设计的结果，就是保持软件架构相对稳定，减小软件架构层面的重构造成的混乱；增量且迭代就是软件不断增加新的模块并对旧模块进行更新。

3.12 敏捷统一过程的四个关键步骤

确定需求
通过用例来满足这些需求
分配这些用例到各增量阶段
具体完成各增量阶段所计划的任务

3.13 敏捷统一过程的增量阶段的5个步骤

用例建模
业务领域建模
对象交互建模
形成设计类图
软件编码与应用部署

3.14 形成软件设计方法的基本方法

分析和综合

分析是分解大问题变成易于理解的小问题。比如用例建模是将错综复杂的需求分解成一个一个的用例，在分析的过程中除了“分而治之”的切分分解的方法外，抽象方法的运用是一个关键。

综合是将一个个小问题的解决方案组合起来构建软件的整体解决方案。我们对每一个用例的关键步骤进行对象交互建模逐步形成了用例对应的解决方案，如何将多个用例的小解决方案组合起来构建软件整体设计方案？这在软件设计中是一个非常有挑战性的问题，一般我们通过参考已有的软件设计模式提供一个思路从而综合出一个软件整体解决方案。

参考资料：软件工程: 《代码中的软件工程》一书的配套ppt和源代码