目录
用户需求
需求分析常用的分析方法
软件设计
创建良好设计的原则
内聚性
耦合性
UML中各种视图及其作用
用例视图VS逻辑视图
UML中的主要图及其作用
软件开发过程与UML可视化建模
MVC模式
MVVM模式
面向对象模型主要哪些模型组成？
概要设计阶段的基本任务是什么？
详细设计的基本任务是什么？有哪几种描述方法？
黑盒测试（Black_Box testing)
用黑盒测试（功能测试）设计测试用例的方法及各自的特点
软件测试步骤及这些步骤的测试对象
白盒测试(White-box Testing)
白盒测试法的逻辑覆盖标准
用户需求
用户需求采用例如采用用例（Use Case）文档或场景（Scenario）等方式说明。
功能需求定义了开发者应提供的软件功能或服务，但不涉及这些功能或服务的实现。
非功能需求则是对功能需求的补充，包括了对系统的各种限制和用户对系统的质量要求。
需求分析常用的分析方法
- 基于瀑布模型的结构化方法，结构化分析方法的分析策略是：自顶向下，逐层分解
- 基于需求动态定义就的原型化方法
- 基于对象的面向对象的方法：UML是软件开发中的一个重要工具
- 基于数据的数据流开发方法
- 面向数据结构设计Jackson方法给出三种结构是. 顺序结构，选择结构，重复结构
- 面向对象的需求分析
1 Booch方法
2 Rumbaugh方法
3 Coad和Yourdon方法
4 Jacobson方法
5 Wirfs―Brock方法
6 UML的OOA方法(现在主流技术基本都使用UML来建模，其他很少使用)
软件设计
传统的结构化方法将软件设计划分为体系结构设计、数据设计、接口设计及过程设计四部分；
结构化分析特点：自顶向下，逐步求精
面向对象方法则将软件设计划分为体系结构设计、类设计∕数据设计、接口设计、构件级设计四部分。
创建良好设计的原则
设计应遵循抽象化的原则，包含数据抽象和过程抽象
设计应当遵循模块化的原则。
设计应遵循信息隐蔽的原则。
模块独立性
高内聚，低耦合
内聚性
内聚是一个模块内部各个元素彼此结合的紧密程度的度量。
(1) 功能内聚
一个模块中各个部分都是为了完成一项具体功能而协同工作，紧密联系，不可分割的。这种模块就是功能内聚模块。功能内聚模块的模块独立性最强。
(2) 层内聚
相关服务放在一起，并有严格的层次结构，高层服务可访问低层服务，反之不可。如分层结构。
(3) 通信内聚
访问或操作同一数据的过程放在一个类中，这些过程可以互相通信。如某个类设计。
(4) 顺序内聚
存在一系列过程，其中一个过程向另一个过程提供输入，这些过程放在一起，形成顺序内聚。如面向对象系统中的消息序列。
(5) 过程内聚
几个一次调用的操作放在一个模块中，它们是相关的且必须以特定次序执行，则称这个模块为过程内聚模块。但在这种模块内，一个操作的输出不一定是下一个操作的输入。如调用结构。
(6) 时间内聚
程序执行过程中同一阶段内完成的操作放在一起，达到时间内聚。
(7) 实用程序内聚
逻辑上不能纳入其他内聚类型的相关实用程序放在一起，形成实用程序内聚。如可复用的过程或类。
耦合性
耦合是模块间互相连接的紧密程度的度量，它取决于各个模块之间接口的复杂度、调用方式以及哪些信息通过接口。
模块之间的耦合性越高，其模块独立性就越弱。模块的内聚性越高，它与其他模块之间的耦合性就会降低，而模块独立性就越强。
(1) 内容耦合
如果发生下列情形，模块间就是内容耦合: 一个模块直接访问另一个模块的内部数据;
(2) 公共耦合
若一组模块都访问同一个公共数据环境，则它们之间的耦合就是公共耦合。公共数据环境可以是全局变量、全局数据结构、共享的通信区、内存的公共覆盖区等。
(3) 控制耦合
一个过程通过标志、开关或命令显式地控制另一个过程的动作，就产生控制耦合。
(4) 标记耦合
如果一组模块通过参数表传递结构或对象（注意，不是简单变量或结构中的某一分量），就是标记耦合。
(5) 数据耦合
如果模块之间的访问是通过数据参数（不是控制参数、结构或对象参数、公共数据结构）来交换输入、输出信息的，则称这种耦合为数据耦合。
(6) 例程调用耦合
一个程序（或对象的操作）调用另一个程序（或另一个对象的操作），就产生例程调用耦合。
(7) 类型使用耦合
类将实例变量或本地变量声明为另一个类的实例，就产生类型（嵌套）耦合。
(8) 包含/引入耦合
一个构件引入（import）一个包时就产生引入耦合，一个构件包含（include）另一个构件时，就产生包含耦合。
(9) 外部耦合
模块对外部系统，如操作系统、共享库或硬件有依赖关系时就产生外部耦合。可通过信息隐蔽减少这种依赖关系。
UML中各种视图及其作用
| 视图名 | 所辖框图 | 作 用 |
| 用例视图 | 用例图 | 从用例一级建立系统的高层模型，并不关注系统的具体实现。类图、交互图、状态图和活动图用于粗略描述系统业务领域的模型，不包括界面和服务对象层 |
| 类图 | ||
| 交互图 | ||
| 状态图 | ||
| 活动图 | ||
| 逻辑视图 | 用例图 | 从类（对象）一级建立系统的实现模型。类图、交互图、状态图和活动图用于详细描述整个系统工程各个层次的设计模型，包括界面和服务对象层 |
| 类图 | ||
| 交互图 | ||
| 状态图 | ||
| 活动图 | ||
| 构件视图 | 构件图 | 建模所要实现系统的各个模块、连接库或文件等之间的关系 |
| 部署视图 | 部署图 | 建模所要实现的系统在物理上的部署及其性能要求 |
用例视图VS逻辑视图
用例视图主要从系统外部来看系统，描述诸如用户在什么样的界面登陆，如何登陆，系统如何响应，但不会描述系统内部如何去验证用户；逻辑视图描述系统内部结构，诸如系统如何验证用户，可能有一个验证类、一个认证控制类等。（一个是程序的表面，一个是程序的内部）
UML中的主要图及其作用
（1）用例图：描述的是参与者（Actor）所理解的系统功能，用于需求分析阶段，列出系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行 。
（2）状态机图：通过对类对象的生存周期建立模型来描述对象随时间变化的动态行为，也可以用来描述用例、协作和方法的动态行为，它是展示状态与状态转换的图。
状态机是一个类的对象所有可能的生命历程的模型。状态机包括状态图和活动图两种表示方法。
活动图：用于描述满足用例要求所要进行的活动以及活动间的约束关系，有利于识别并行活动和工作流程情况。 活动图实际上是用来为用例的事件流建模的工具。展示的主要内容是对象的活动状态。
状态图：用于对系统的动态方面建模。
（3）类图：是逻辑视图的重要组成部分，用于对系统的静态结构建模，涉及到具体的实现细节。在系统分析阶段，类图主要用于显示角色和提供系统行为的实体的职责；在系统设计阶段，类图主要用于捕捉组成系统体系结构的类结构；在系统编码阶段，根据类图中的类及它们之间的关系实现系统的功能。
关联关系：如果A类中成员变量是用B类声明的对象，那么A和B的关系是关联关系
依赖关系： 如果A类中某个方法的参数是用B类声明的对象或某个方法返回的数据类型是B类对象，那么A和B的关系是依赖关系
泛化（继承）关系：如果一个类是另一个类的子类，那么二者之间是泛化（继承）关系
实现关系：是指一个class实现interface接口
聚合关系：表示类的对象之间是整体和部分之间的关系
组合关系：表示类的对象之间整体拥有部分，部分与整体共存之间的关系。整体不存在，部分随之消失。
（4）交互图：可以用于对一个用例的事件流程进行建模，也可以单独使用，用于可视化、详述、构造和文档化一个特定对象群体的动态方面。交互图显示一个交互，由一组对象和它们之间的关系构成，其中包括：需要什么对象、对象相互发送什么消息、什么角色启动消息以及消息按什么顺序发送。
交互图分为两种：顺序图和协作图；顺序图强调消息发送的时间顺序，协作图则强调接收和发送消息的对象的组织结构。
（5）构件图：提供当前模型的物理视图，对系统的静态实现视图建模。构件图显示一个系统物理设计时，构件所映射的类和对象的配置。构件图主要包含以下几种内容：构件、接口、依赖关系以及构件包。
（6）部署图：对面向对象系统的物理方面建模,描述系统运行时节点、构件实例及其对象的配置。节点是各种计算资源的通用名称，包括处理器和设备两种类型，两者的区别是处理器能够执行程序的硬件构件（如计算机主机），而设备是一种不具备计算能力的硬件构件（如打印机）
软件开发过程与UML可视化建模
| 软件开发阶段 | UML使用情况 | 可能用到的UML模型图及元素 |
| 开始阶段 | 建立业务模型（Business Use Case） | 业务用例、业务参与者、业务工人 |
| 确定用例模型（Use Case） | 参与者、用例、关系 | |
| 细化阶段 | 细化用例 | 参与者、用例、关系 |
| 事件流程建模 | 顺序图、协作图、状态图 | |
| 对系统静态结构和动态行为建模 | 类图、交互图、状态机图 | |
| 确定系统构件 | 构件图、关系 | |
| 构建阶段 | 正向工程产生框架代码 | 类图、交互图、状态机图、构件图 |
| 逆向工程更新模型 | 构件图 | |
| 创建部署 | 部署图 | |
| 交付阶段 | 交付使用，维护和升级模型 | 构件图、部署图 |
与传统方法中的数据设计所不同的是，面向对象设计中的数据设计并不是独立进行的，面向对象设计中的类图相当于数据的逻辑模型，可以很容易地转换成数据的物理模型。
MVC模式
即模型—视图—控制器（Model-View-Controller）模式，分别对应于内部数据、数据表示和输入/输出控制部分，把它们分开设计，其过程是：首先控制器接收用户的请求，并决定调用哪个模型处理；然后模型用业务逻辑来响应用户的请求并返回数据；最型后控制器用视图表示模型返回的数据呈现给用户。
模型侧重数据和功能，视图侧重数据显示，控制器侧重用户输入，其优点是把数据和业务规则分开表示。
1) 模型对象
模型对象是应用程序中用于处理应用程序数据逻辑的部分，模型对象的变化通过事件处理通知视图和控制器对象。
2) 视图对象
视图对象代表GUI对象，并且以用户需要的格式表示模型状态，是交互系统与外界的接口。视图对象可以包含子视图，子视图用于显示模型的不同部分。通常，每个视图对象对应一个控制器对象。
3) 控制器对象
控制器对象代表事件，处理用户的输入行为，给模型发送业务事件，将其解析为模型执行的动作，同时，模型的更新与修改经由控制器通知视图，实现各视图与模型一致。
MVVM模式
MVVM模式改进了MVC模式，更好分离视图和模型。
MVVM的组成结构。
a) 模型层（Model）：指数据模型，或指代表内容的数据访问层，在前后端分离的架构中，可以理解为后端往前端传递的数据。
b) 视图层（View）：指用户界面。
c) 视图模型层（ViewModel）：该层主要负责Model层与View层的通信以及数据与视图的绑定。将数据封装并传递至视图层，将视图的行为与状态的变换传递到Model层。
MVVM与前后端分离开发。
课程案例采用前后端分离架构开发。在该架构中，后端对应MVVM模式中的Model层，围绕数据库系统进行业务逻辑的处理，封装数据（主要为JSON格式）并传输至前端。前端对应MVVM模式中的ViewModel层和View层。前端从后端获取的数据通过JavaScipt代码进行二次封装，以生成符合View层使用预期的视图数据模型，以网页形式展示。当视图发生变化时，前端根据与后端约定好的接口规则，通过JavaScipt代码向后端发起请求。MVVM模式降低了模块之间的耦合度，前后端分离架构提高了开发效率。
前后端分离的信息系统设计与实现（基于MVVM的设计模式）
- MVVM的组成结构。
- 模型层（Model）：指数据模型，或指代表内容的数据访问层，在前后端分离的架构中，可以理解为后端往前端传递的数据。
- 视图层（View）：指用户界面。
- 视图模型层（ViewModel）：该层主要负责Model层与View层的通信以及数据与视图的绑定。将数据封装并传递至视图层，将视图的行为与状态的变换传递到Model层。
该模式能够实现高内聚低耦合
面向对象模型主要哪些模型组成？
1 对象模型 描述对象、类、层次和关系，静态结构，其作用是描述系统的静态结构，包括构成系统的类和对象，它们的属性和操作，以及它们之间 的联系。 – 对象模型包括类图
2 动态模型 其作用是描述系统的控制逻辑，主要涉及系统中各个类和对象的时序及变化情况。时序图等
3 功能模型 描述系统的功能 表示方法：数据流图，用例图
概要设计阶段的基本任务是什么？
⑴设计软件系统结构（简称软件结构），具体为：
①采用某种设计方法，将一个复杂的系统按功能划分成模块。
②确定每个模块的功能。
③确定模块之间的调用关系。
④确定模块之间的接口，即模块之间传递的信息。
⑤评价模块结构的质量。
⑵数据结构及数据库设计。
⑶编写概要设计文档。主要有：概要设计说明书；数据库设计说明书；用户手册；修订测试计划。⑷评审。
详细设计的基本任务是什么？有哪几种描述方法？
详细设计是软件设计的第二阶段
其基本任务有：
- 为每个模块进行详细的算法设计；
- 为模块内的数据结构进行设计；
- 对数据库进行物理设计，即确定数据库的物理结构；
- 其它设计，根据软件系统类型，还可能要进行代码设计、输入/输出格式设计、人机对话设计；
- 编写详细设计说明书；
- 评审。
详细描述处理过程常用三种工具：图形、表格和语言。如结构化程序流程图、盒图和问题分析图。IPO图也是详细设计的主要工具之一。表格工具如判定表可作为详细设计中描述逻辑条件复杂的算法。过程设计语言（PDL）是一种用于描述模块算法设计和处理细节的语言工具。
图形工具：程序流程图， N-S ，PAD， HIPO
表格工具：判定表
语言工具： PDL ， HIPO
黑盒测试（Black_Box testing)
黑盒测试把程序看作一个不能打开的黑盒子，在完全不考虑程序内部结构和内部特性的情况下、注重于测试软件的功能性要求，测试者在程序接口处进行测试，只检查程序功能是否按照规格说明书的规定正常使用，程序是否能接收输入数据而产生正确的输出信息，并且保持数据库和文件的完整性
用黑盒测试（功能测试）设计测试用例的方法及各自的特点
㈠等价类划分。等价类划分是将输入数据域按有效的或无效的（也称合理的或不合理的）划分成若干个等价类，测试每个等价类的代表值就等于对该类其它值的测试。
某“调整工资”处理模块接受一个“职称”的变量，根据职称的不同（助教，讲师，副教授，教授）作不同的处理，其中若是助教还必须输入工龄，只有工龄超过两年才能调整工资。请用等价类划分法设计测试用例。
输入条件
合理等价类
不合理等价类
职称
①教授
②副教授
③讲师
⑤四种职称之外任意一种
职称兼工龄
④助教兼工龄大于2年
⑥助教兼工龄等于两年
⑦助教兼工龄小于两年
设计测试用例：
输入数据
预期结果
覆盖范围
教授
输入有效，进行调整工资处理
①
副教授
输入有效，进行调整工资处理
②
讲师
输入有效，进行调整工资处理
③
助教 3
输入有效，进行调整工资处理
④
助教 2
输入有效，不调整工资处理
⑥
助教 1
输入有效，不调整工资处理
⑦
工程师
输入无效
⑤
㈡边界值分析。该方法是将测试边界情况作为重点目标，选取正好等于，刚刚大于或刚刚小于边界值的情况，根据这些情况选择测试用例。
㈢错误推测。错误推测法没有确定的步骤，凭检验进行。它的基本思想是列出程序中可能发生错误的情况，根据这些情况选择测试用例。
㈣因果图。因果图能有效的检测输入条件的各种组合可能会引起的错误。因果图的基本原理是通过画因果图，把用自然语言描述的功能说明转换为判定表，最后为判定表的每一列设计一个测试用例。
在网络中，sendfile命令用来发送一个文件到不同的服务器。Sendfile有三个变量：变量1是发送者根目录的文件名，变量2是接受文件服务器的名称，变量3是接受方的用户useid。如果所有的变量是正确的，那么文件成功发送，否则给发送者返回一个错误信息。如果原因用1代表变量1，2代表变量2，3代表变量3，结果用100代表成功，101代表返回错误信息，请画出因果图并建立因果关系判定表。
软件测试步骤及这些步骤的测试对象
白盒测试(White-box Testing)
白盒测试又称结构测试或逻辑驱动测试，指通过对程序内部结构的分析、检测来寻找问题。白盒测试把程序看成装在一个透明的白盒子里，也就是清楚了解程序结构和处理过程，检查是否所有的结构及路径都是正确的，检查软件的内部动作是否按照设计说明的规定正常进行。
白盒测试法的逻辑覆盖标准
![[进阶]Java：对象序列化、反序列化](https://img-blog.csdnimg.cn/6b812d83c89148f88fb0ef387a9d74d8.png)
