2023电子科技大学-软件工程-复习汇总
目录
软件工程概述
软件过程
相关定义
瀑布模型（经典生命周期模型）
V模型（瀑布模型的变种）
原型模型（原型化模型、快速原型模型）
增量模型
螺旋模型
喷泉模型
基于构件的开发模型
统一过程模型
敏捷开发过程
如何选择软件过程模型？
案例
需求分析
需求分析概述
需求获取（需求抓取，需求发现，需求获得）
需求提炼（需求分析）
需求规格说明书（需求描述）
需求验证
面向过程的分析方法——结构化分析方法
概述
数据流图
面向对象的分析方法
概述
用例图
活动图
软件设计
相关概述
面向过程设计
面向对象设计
质量保证
软件工程概述
软件 = 程序+数据+文档，文档时与程序开发、维护使用有关的图文材料
软件危机：软件开发和维护的过程中所遇到的一系列严重问题
软件工程：应用系统化的、学科化的、定量的方法，来开发、运行和维护软件，即将工程应用到软件。三要素：方法、工具、过程
软件过程
相关定义
软件生命周期：
软件产品或软件系统从设计、投入使用到被淘汰的全过程
软件过程：
在工作产品构建过程中，所需完成的工作活动、动作和任务的集合。
软件过程模型：
是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略，也被称为软件开发模型、软件生存周期模型 、 软件工程范型。
瀑布模型（经典生命周期模型）
规定了各项软件工程活动，以及它们自上而下，相互衔接的固 定次序，如同瀑布流水，逐级下落。软件开发过程与软件生命周期一致。线性模型：阶段间具有顺序性与依赖性，推迟实现。
使用广泛，以文档为驱动的模型，每个阶段都有与其相关联的里程碑和可交付产品 ，每个阶段结束前完成文档审查，及早改正错误。
缺点：
-
增加工作量 各个阶段的划分完全固定， 阶段之间产生大量的文档， 极大地增加了工作量
-
开发风险大 由于开发模型是线性的， 用户只有等到整个过程的 末期才能见到开发成果， 从而增加了开发的风险
-
早期错误发现晚 早期的错误可能要等到开发 后期的测试阶段才能发现， 进而带来严重的后果
-
不适应需求变化 不能反映实际的开发方式， 软件开发需要迭代；无法 适应需求不明确和需求的 变化
使用场合：瀑布模型适用于系统需求明确且稳定、技术成熟、工程管理较严格的场合，如军工、航天、医疗
V模型（瀑布模型的变种）
原型模型（原型化模型、快速原型模型）
原型 一个部分开发的产品，使客户和 开发人员能够对计划开发的系统 的相关方面进行检查。
原型的目的是明确并完善需求，如演示原型，研究技术选择方案，如技术验证原型，最终的结果是抛弃原型或把原型发展成最终产品。
优点：减少需求不明 确带来的风险
缺点：
-
构造原型采用的技术和工具不一 定主流
-
快速建立起来的系统加上连续的修改可能导致原型质量低下
-
设计者在质量和原型中进行折中
-
客户意识不到一些质量问题
使用场合：客户定义一个总体目标集，但是他们并不清楚系统的 具体输入输出；或开发者不确定算法的效率、软件与操作系统是否兼容以及客户与计算机交互的方式。此时原型模型是很好的选择
增量模型
增量 满足用户需求的一个子集，能够完成一定功能、小而可用的软件
增量的方式
特点：非整体开发的模型，是一种进化式的开发过程。增量模型从部分需求出发，先建立一个不完整的系统，通过测试运行这个系统取得经验和反馈，进一步使系统扩充和完善。如此反复进行，直至软件人员和用户对所设计的软件系统满意为止。增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序 列，每个线性序列都会输出该软件的一个“增量”。每个增量的开发可用瀑布或快速原型模型。
优点：
-
增量概念的引入，不需要提供完整的需求，只要有一个增量出现，开发就可以进行
-
软件能够更早投入市场
-
在项目的初始阶段不需要投 入太多的人力资源
-
开放式体系结 构，便于维护。
-
产品逐步交付，软件开发能 够较好地适应需求的变化
-
能够看到软件中间产品，提 出改进意见，减少返工，降 低开发风险；
缺点：
-
每个增量必须提供一 些系统功能，这使得 开发者很难根据客户 需求给出大小适合的 增量
-
软件必须具备开放式 体系结构（困难）
-
易退化成边做边改的 方式，使软件过程控 制失去整体性
使用场合适用于软件开发中需求可能发生变化、具有较 大风险、或者希望尽早进入市场的项目
螺旋模型
开发过程分成若干次迭代，每次迭代代表开发的一个阶段，对应模型中一条环线，每次迭代分成四个方面的活动，对应笛卡尔坐标的四个象限，模型结合了瀑布模型和原型模型的特点
优点：
-
螺旋模型强调原型的可扩 充性和可修改性，原型的 进化贯穿整个软件生存周 期，这将有助于目标软件 的适应能力，支持用户需 求的动态变化
-
原型可看作可执行的需求规格 说明，易于为用户和开发人员 共同理解，还可作为继续开发 的基础，并为用户参与所有关 键决策提供了方便
-
螺旋模型为项目管理人员 及时调整管理决策提供了方便，进而可降低开发风险
缺点：
-
如果每次迭代的效率 不高，致使迭代次数过多，将会增加成本 并推迟交付时间；
-
使用该模型需要有相当丰 富的风险评估经验和专门知识，要求开发队伍水平较高，否则会带来更大风险。
使用场合：适用于需求不明确或者需求可能发生变化的大型复杂的软件系统。 支持面向过程、面向对象等多种软件开发方法，是一种具有广阔前景的模型
喷泉模型
喷泉模型是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程，软件开发早期定义对象，整个开发过程充实和扩充对象，各个阶段使用统一的概念和表示方法，生命周期各阶段无缝连接，各个开发步骤多次反复迭代
优点：
喷泉模型的各个阶段没 有明显的界限，开发人员可以同步进行开发，可以提高软件项目开发 效率，节省开发时间，适应于面向对象的软件 开发过程。
缺点：
-
由于喷泉模型在各个开发阶段是重叠的，在开发过程中需要大量的开发人员，因此不利于项目的管理。
-
喷泉模型要求严格管理文档， 使得审核的难度加大，尤其是面对可能随时加入的各种 信息、需求与资料的情况。
使用场合：适用于面向对象开发
基于构件的开发模型
构建/组件 系统中模块化的、可更换的部分，实现特定的功能，对实现进行封装，暴露一组接口
统一过程模型
适合大团队大项目
敏捷开发过程
如何选择软件过程模型？
-
前期需求明确的情况下，尽量采用瀑布模型
-
用户无系统使用经验，需求分析人员技能不足的情况下，尽量借助原型模型
-
不确定因素很多，很多东西无法提前计划的情况下，尽量采用增量模型或螺旋模型
-
需求不稳定的情况下，尽量采用增量模型
-
资金和成本无法一次到位的情况下，可采用增量模型
-
对于完成多个独立功能开发的情况，可在需求分析阶段就进行功能并行，每个功能内部 都尽量遵循瀑布模型
-
全新系统的开发必须在总体设计完成后再开始增量或并行
-
编码人员经验较少的情况下，尽量不要采用敏捷或迭代模型
-
增量、迭代和原型可以综合使用，但每一次增量或迭代都必须有明确的交付和出口原则
案例
医疗设备控制软件：瀑布模型
校园一卡通：增量模型
智能化小区：原型化模型+增量模型
需求分析
需求分析概述
需求分析：确定系统必须具有的功能和性能，系统要求的运行环 境，并且预测系统发展的前景。
过程：需求获取——需求提炼——需求描述——需求验证
需求获取（需求抓取，需求发现，需求获得）
指软件需求的来源与软件工程师收起这些需求的方法
需求分为功能性需求（描述系统应该做什么）与非功能需求（必须遵守的标准）
需求获取面临的挑战：尽可能分析清楚哪些是稳定需求，那些是易变需求，在进行系统设计时将软件的核心建筑在稳定的需求上
需求提炼（需求分析）
指对应用问题及环境的理解和分析，为问题涉及的信息、功 能及系统行为建立模型。将用户需求精确化、完全化，最 终形成下一步的需求规格说明书。
核心在于建立分析模型
需求分析模型（核心）
面向过程分析模型
其基本思想是用系统工程的思想和工程化的方法， 根据用户至上的原则，自始自终按照结构化、模块 化，自顶向下地对系统进行分析与设计。
面向对象分析模型
由5个层次（主题层、对象类层、结构层、属性层和服务层）和5个活动（标识对象类、标识结构、定义主题、定义属性和定义服务）组成
分析模型描述工具
需求规格说明书（需求描述）
软件需求规格说明书（SRS）------软件系统的需求规格说明，是对待开发系统的行为的完整描述。它包含了功能性需求和非功能性需求。一份完整、规范的需求规格说明书是需求分析工作完成的一个基本标志。
结构（IEEE标准）
（1）引言（2）综合描述（3）需求描述（4）附录（词汇表、分析模型、待定问题列表）（5）索引
需求验证
对需求文档执行检查
面向过程的分析方法——结构化分析方法
概述
是面向数据流进行需求分析的方法，适合于数据处理类型软件的需求分析。具体来说，结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止
建模工具总览
数据流图
主要图形元素
多层次数据流图的层次结构
-
顶层流图：仅包含一个加工，它代表被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据
-
中间层流图：则表示对其上层父图的细化，它的每一加工可能继续细化，形成子图
-
底层流图：是指其加工不需再做分解的数据流图，它处在最底层
加工
含义：表示对数据进行的操作，其编号说明了该加工在层次分解中的位置
命名：顶层的加工名就是整个系统项目的名字，最好使用动宾词组，不要使用空洞的动词
外部实体
系统之外的信息提供者或使用者，不是系统中的事物
数据流
表示数据和数据流向
数据流与加工之间的关系
注意：
不要把控制流化成数据流
不要标出激发条件
每个加工至少有一个输入流和输出流
数据流不能跳过加工直接在数据存储和外部实体之间流动
面向对象的分析方法
概述
数据模型（对象模型）：描述系统数据结构的对象模型
行为模型（动态模型）：描述系统控制结构
功能模型：描述系统功能
一个典型的软件系统使用数据结构（对象模型），执行操作（动态模型），并且完成数据值的变化（功能模型）
用例图
用于描述系统需求，把系统当作黑盒，从用户的角度，描述 系统的场景
系统与关联
系统用于界定系统功能范围，描述该系统功能的用例都置于其中，描述外部实体的参与者都置于其外。
关联是连接参与者与用例，表示参与者所表示的系统外部实体与该用例所描述的系统需求有关。
用例扩展
用例之间的关系
关联
表示参与者与用例之间的通信，任何一方均可发送或接受消息，箭头指向消息接收方。参与者可以参与多个用例，由此形成子系统
泛化（Inheritance）
就是继承关系，父用例通常是抽象的，子用例继承父用例的所有结构行为和关系，也可以对其重载增加新的特性。箭头指向父用例
包含
包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。一个用例可以包含另外一个用例。箭头指向分解出来的功能用例
扩展(Extend)
扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。由一个用例的扩展点可以扩展出另外一个用例。箭头指向基础用例
活动图
能够图形化显示用例的事件流；展示计算的步骤，每一步都是做某事的一个状态，执行步骤称为动作，描述了哪些步骤被顺序执行、哪些可被并发地执行，即描述了系统的控制流。
活动图表明了动作间的转换
泳道图是活动图的一种形式
软件设计
相关概述
软件设计：软件设计是软件系统或组件的架构、构件、接口和其他特性的定义过程及该过程的结果。
软件设计是生命周期中的一个活动，是进行软件编码的基础，是软件需求分析被转化为软件的内部结构，是连接用户需求和软件技术的桥梁。
软件设计实现分析模型到设计模型的转化，模型输入：软件需求的数据模型、功能模型和行为模型
设计质量属性：功能性，易用性，可靠性，性能，可支持性（包含三个属性：扩展性、适应性、可维护性）
设计工程活动：
-
软件架构设计（顶层设计） 描述软件的顶层架构和组织，划分不同的组件
-
软件详细设计 详细描述各组件以便能够编码实现
设计相关概念：
-
抽象 数据抽象：描述数据对象的冠名数据集合；过程抽象：具有明确和有限功能的指令序列
-
体系结构 软件的整体结构和这种结构为系统提供概念上完整性的方式
-
设计模式 在给定上下文环境中一类共同问题的共同解决方案
-
模块化 软件被划分为命名和功能相对独立的多个组件（通常称为模块），通过这些组件的集成来满足问题的需求
-
信息隐藏 模块应该具有彼此相互隐藏的特性，即：模块定义和设计时应当保证模块内的信息（过程和数据）不可以被 不需要这些信息的其他模块访问
-
功能独立 每个模块只负责需求中特定的子功能，并且从程序结构的其他部分看，该模块具有简单的接口。模块独立性强 = 高内聚（模块的功能相对强度）低耦合（模块之间的相互依赖程度）
-
精化 逐步求精的过程；与抽象的关系抽象使设计师确定过程和数据，但不局限于底层细节，精化有助于设计者在设计过程中揭示底层细节
-
重构 不改变组件功能和行为条件下，简化组件设计（或代码）的一种重组技术，减少冗余，优化问题。
设计技术概要
数据设计
数据设计（有时也被称为数据架构）构建高层抽象（客户/用户的数据视图）的数据模型、信息模型。包括数据建模（数据字典、ER图、类图）、数据结构、数据库、数据仓库
体系结构设计
按照风格和模式分类包括：数据中心架构、数据流体系结构、调用和返回架构、层次架构、面向对象架构
两个基本问题：
控制结构 在架构内部如何实现管理控制？是否有不同的控制架构存在？ 数据传递 组件之间如何进行数据传递？数据流是否连续，或者传递给系统的数据对象是否零散？
部署设计
以部署环境创建开始，在整个生命周期阶段中处于逻辑设 计和技术需求阶段 部署环境包含整个解决方案的逻辑架构和服务质量（QoS）需求 部署架构设计是一个反复迭代的过程，通常需要多次查看 QoS要求和多次检查先前的设计，需要考虑了服务质量QoS 需求的相互关系，平衡取舍相关问题成本以实现最佳解决方 案，最终满足项目的业务目标
接口设计（含界面设计）
组件设计
面向过程：函数与模块的编程
面向对象：类与操作的设计
面向过程设计
也称为面向数据流的设计
结构化的总体设计方法
首先研究、分析和审查数据流图。 从软件的需求规格说明中弄清数据流加工的过程，对于发现的问题及时解决。然后根据数据流图决定问题的类型。数据处理问题典型的类型有 两种：变换型和事务型。针对两种不同的类型分别进行分析处理。由数据流图推导出系统的初始结构图。利用一些启发式原则来改进系统的初始结构图，直到得到符合要 求的结构图（系统结构图）为止。修改和补充数据词典。
在系统结构图中的模块
传入模块 从下属模块取得数据，经过某些处理，再将其传送给上级模块。它传送的数据流叫做逻辑输入数据流。
传出模块 从上级模块获得数据，进行某些处理，再将其传送给下属模块。它传送的数据流叫做逻辑输出数据流。
变换模块 它从上级模块取得数据，进行特定的处理，转换成其它形式，再传送回上级模块。它加工的数据流叫做变换数据流。
协调模块 对所有下属模块进行协调和管理的模块。
变换型系统结构图
事务性系统结构图
变化和事务分析
变换分析
事务分析
混合结构分析
面向过程的组件设计——流程图
结构化组件设计。组件级设计也称为过程设计、详细设计，位于数据设计、体系结构设计和接口设计完成之后。
流程图
利用各种方块图形、线条及箭头等符号来表达解决问题的步骤及进行的顺序；是算法的一种表示方式。
基本符号：
基本结构：
顺序结构；选择结构；循环结构
面向过程的其他组件设计方法
盒图 N-S图
PDL（程序设计语言）
PDL是一种用于描述功能模块的算法设计和加工细节的语言。称为程序设计语言。 它是一种伪码。 伪码的语法规则分为“外语法”和“内语法”。 PDL具有严格的关键字外语法，用于定义控制结构和数据结构，同时它的表示实际操作和条件的内语法又是灵活自由的，可使用自然语言的词汇。
判定表（决策表）
面向对象设计
面向对象设计的活动
架构设计
用于勾画出系统的总体结构。输入用例模型、分析模型，输出物理结构、子系统及其接口、概要的设计类
步骤：
构造系统的物理模型 ：用UML的配置图（部署图）描述系统的物理架构将需求分析阶段捕获的系统功能分配到这些物理节点上。配置图上可以显示计算节点的拓扑结构、硬件设备配置、通信路径、各个节点上运行的系统软件配置、应用软件配置。
设计子系统：根据功能、硬件、软件层次划分各个子系统；然后确定子系统之间的关系，请求服务关系、平等关系、依赖关系（定义到接口上），两个子系统的关系不能过于密切；最后定义子系统的接口，接口上定义操作体现了子系统的功能。
非功能需求设计
分析阶段定义了整个系统的非功能需求，在设计阶段要研究这些需求，设计出可行的方案。非功能需求包括：系统的安全性、错误监测和故障恢复、可移植性和通用性等等。
用例设计与类设计
进一步细化用例
根据分析阶段产生的高层类图和交互图，由用例设计师研究已有的类，将它们分配到相应的用例中。检查每个用例功能，依靠当前的类能否实现，同时检查每个用例的特殊需求是否有合适的类来实现。细化每个用例的类图，描述实现用例的类及其类之间的相互关系，其中的通用类和关键类可用粗线框区分，这些类将作为项目经理检查项目时的重点。
类
最顶部的格子包含类的名字，类的命名应尽量用应用领域中的术语，有明确的含义，以利于开发 人员与用户的理解和交流。中间的格子说明类的属性。最下面的格子是类的操作行为
类间关系
分析类图
实体类
实体类用于对必须存储的信息和相关行为进行建模 实体类源于业务模型中的业务实体，但出于对系统结构的优化，可以在后续的过程中被分拆、合并
边界类
参与者与用例之间应当建立边界类 用例与用例之间如果有交互，应当为其建立边界类 如果用例与系统边界之外的非人对象有交互，应当为其建立边界类 在相关联的业务对象有明显的独立性要求，即它们可能在各自的领域内发展和变化， 但又希望互不影响时，也应当为它们建立边界类
控制类
控制类来源于对用例场景中动词的分析和定义 控制类主要起到协调对象的作用，例如从边界类通过控制类访问实体类，或者实体类通过控制类访问另一个实体类。如果用例场景中的行为在执行步骤、执行要求或者执行结果上具有类似的特征，应当合并或抽取超类
详细设计一个类
-
定义类的属性
-
定义类的操作
-
定义类之间的关系
类之间的关系：泛化, 实现，关联，聚合，组合，依赖；参考:类的关系（泛化, 实现，关联，聚合，组合，依赖）_一鲸落.万物生的博客-CSDN博客_泛化关系
UML顺序图
顺序图是强调消息时间顺序的交互图。 顺序图描述了对象之间传送消息的时间顺序，用来表示用例中的行为顺序。 顺序图将交互关系表示为一个二维图。即在图形上，顺序图是一张表，其中显示的对象沿横轴排 列，从左到右分布在图的顶部；而消息则沿纵轴按时间顺序排序。创建顺序图时，以能够使图尽 量简洁为依据布局。
什么时候使用顺序图？用涉及多个类时
顺序图的4个元素：
• 对象（Object） • 生命线（Lifeline） • 消息（Message） • 激活（Activation）
对象
顺序图中对象的符号和对象图中对象所用的符号一样。 将对象置于顺序图的顶部意味着在交互开始的时候对象就已经存在了，如果对象的位置不在顶部，那么表示对象是在交互的过程中被创建的。
参与者和对象按照从左到右的顺序排列 一般最多两个参与者，他们分列两端。启动这个用例的参与者往往排在最左边；接收消息的参与者则排在最右端； 对象从左到右按照重要性排列或按照消息先后顺序排列。
生命线
每个对象都有自己的生命线，用来表示在 该用例中一个对象在一段时间内的存在 生命线使用垂直的虚线表示 如果对象生命期结束，则用注销符号表示 对象默认的位置在图顶部，表示对象在交 互之前已经存在 如果是在交互过程中由另外的对象所创建， 则位于图的中间某处。
激活
激活表示该对象被占用以完成某个任务，去激 活指的则是对象处于空闲状态、在等待消息。 在UML中，为了表示对象是激活的，可以将该 对象的生命线拓宽成为矩形。其中的矩形称为 激活条(期)或控制期，对象就是在激活条的顶 部被激活的，对象在完成自己的工作后被去激 活。
激活期
当一条消息被传递给对象的时候，它会触发该对象的某个行为，这时就说该对象被激活了。 在UML中，激活用一个在生命线上的细长矩形框表示。 矩形本身被称为对象的激活期或控制期，对象就是在激活期顶端被激活的。 激活期说明对象正在执行某个动作。当动作完成后，伴随着一个消息箭头离开对象的生命线，此时对象的一个激活期也宣告结束。
消息
-
面向对象方法中，消息是对象间交互信息的主要方式。
-
在任何一个软件系统中，对象都不是孤立存在的，它们之间通过消息进行通信。
-
消息是用来说明顺序图中不同活动对象之间的通信。因此，消息可以激发某个操作、创建或撤销某个对象。
-
结构化程序设计中，模块间传递信息的方式主要是过程（或函数）调用。
-
对象A向对象B发送消息，可以简单地理解为对象A调用对象B的一个操作（operation）。
-
在顺序图中，消息是由从一个对象的生命线指向另一个对象的生命线的直线
-
箭头来表示的，箭头上面还可以表明要发送的消息名及序号。
-
顺序图中消息编号可显示，也可不显示。协作图中必须显示。
-
顺序图中，尽力保持消息的顺序是从左到右排列的。在各对象之间，消息的次序由它们在垂直轴上的相对位置决定。
-
一个顺序图的消息流开始于左上方，消息2的位置比消息1低，这意味着消息2的顺序比消息1要迟。因为西方的阅读习惯是从左到右。
消息的几种类型：
简单消息（Simple Message）
同步消息（Synchronous Message）
同步消息最常见的情况是调用，即消息发送者对象在它的一个操作执行时调用接收者对象的一个操作，此时消息名称通常就是被调用的操作名称。当消息被处理完后，可以回送一个简单消息，或者是隐含的返回。
异步消息（Asynchronous Message）
异步消息表示发送消息的对象不用等待回应 的返回消息，即可开始另一个活动。 异步消息在某种程度上规定了发送方和接收 方的责任，即发送方只负责将消息发送到接 收方，至于接收方如何响应，发送方则不需 要知道。对接收方来说，在接收到消息后它 既可以对消息进行处理，也可以什么都不做。
反身消息（Message to Self）
顺序图建模过程中，一个对象也可以将一个消息发送给它自己，这就是反身消息。 • 如果一条消息只能作为反身消息，那么说明该操作 只能由对象自身的行为触发。 • 这表明该操作可以被设置为private属性，只有属于 同一个类的对象才能够调用它。 • 在这种情况下，应该对顺序图进行彻底的检查，以 确定该操作不需要被其他对象直接调用。
返回消息（Return Message）
返回消息是顺序图的一个可选择部分，它表 示控制流从过程调用的返回。 返回消息一般可以缺省，隐含表示每一个调 用都有一个配对的调用返回。 是否使用返回消息依赖于建模的具体/抽象 程度。如果需要较好的具体化，返回消息是 有用的；否则，主动消息就足够了。
顺序图与用例
顺序图的主要用途之一是用来为某个用例的泛化功能提供其所缺乏的解释，即把用例表达的要求转化为更进一步的精细表达。 用例常常被细化为一个或多个顺序图。 顺序图除了在设计新系统方面的用途之外，它还能用来记录一个存在于系统的对象现在如何交互。
顺序图建模
-
对系统动态行为建模的过程中，当强调按时间展开信息的传送时，一般使用顺序图建模技术。
-
一个单独的顺序图只能显示一个控制流。
-
一般情况下，一个完整的控制流是非常复杂的，要描述它需要创建很多交互图（包括顺序图和协作图），一些图是主要的，另一些图用来描述可选择的路径和一些例外，再用一个包对它们进行统一的管理。
面向对象设计原则
面向对象设计的特点
-
面向对象设计强调定义软件对象，并且使这些软件对象相互协作来满足用户需求。
-
面向对象分析和设计的界限是模糊的，从面向对象分析到面向对象设计是一个逐渐扩充模型的过程。分析的结果通过细化直接生成设计结果，在设计过程中逐步加深对需求的理解，从而进一步完善需求分析的结果。
-
分析和设计活动是一个反复迭代的过程。
-
面向对象方法学在概念和表示方法上的一致性，保证了各个开发阶段之间的平滑性。
面向对象设计的四个层次
-
确定系统的总体结构和风格，构造系统的物理模型，将系统划分成不同的子系统。
-
中层设计：对每个用例进行设计，规划实现用例功能的关键类，确定类之间的关系。
-
进行底层设计：对每个类进行详细设计，设计类的属性和操作，优化类之间的关系。
-
补充实现非功能性需求所需要的类。
设计出高质量软件的注意点：
-
对接口进行设计
-
发现变化并且封装它
-
先考虑聚合然后考虑继承
强内聚
类内聚——设计类的原则是一个类的属性和操作全部都是完成某个任务所必须的，其中不包括无用的属性和操作
弱耦合
在面向对象设计中，耦合主要指不同对象之间相互关联的程度。如果一个对象过多地依赖于其它对象来完成自己的工作，则不仅使该对象的可理解性下降，而且还会增加测试、修改的难度，同时降低了类的可重用性和可移植性。对象不可能是完全孤立的，当两个对象必须相互联系时，应该通过类的公共接口实现耦合，不应该依赖于类的具体实现细节。
耦合方式
交互耦合
如果对象之间的耦合是通过消息连接来实现 的，则这种耦合就是交互耦合。在设计时应 该尽量减少对象之间发送的消息数和消息中 的参数个数，降低消息连接的复杂程度。
继承耦合
继承耦合是一般化类与特殊化类之间的一种 关联形式，设计时应该适当使用这种耦合。 在设计时要特别认真分析一般化类与特殊化 类之间继承关系，如果抽象层次不合理，可 能会造成对特殊化类的修改影响到一般化类， 使得系统的稳定性降低。另外，在设计时特 殊化类应该尽可能多地继承和使用一般化类 的属性和服务，充分利用继承的优势。
可重用性
含义：尽量使用已有的类，包括开发环境提供的类库和已有的相似的类；如果确实需要创建新类，则在设计这些新类时考虑将来的可重用性。
设计一个可重用的软件比设计一个普通软件的代价要高，但是随着这些软件被重用次数的增加，分摊到它的设计和实现成本就会降低
框架
框架是一组可用于不同应用的类的集合。框架中的类通常是一些抽象类并且相互有联系，可以通过继承的方式使用这些类。 • 例如，Java应用程序接口（API）就是一个成功的框架包，为众多的应用提 供服务，但一个应用程序通常只需要其中的部分服务，可以采用继承或聚合的方式将应用包与框架包关联在一起来获得需要的服务。 一般不会直接去修改框架的类，而是通过继承或聚合为应用创建合适的GUI类。
质量保证
软件质量保证
软件质量保证相关概念：
质量相关
质量控制：审查产品相关的各个方面质量的过程
质量保证：系统监测和评估工程的各个方面，最大限度提高质量最低标准
质量成本：追求质量过程或在履行质量有关活动中引起的费用以及质量不佳引起的下游费用等所有费用。
软件质量相关
软件质量：明确表示是否符合功能和性能要求，明确地记载开发标准和所有专业开发软件的期望的隐性特点。
软件质量保证（SQA）：遵照一定的软件生产标准、过程和步骤对软件质量进行评估的活动
软件评审：一个过程或会议期间进行的软件产品的审核，由项目人员、管理人员，用户、客户、用户代表或其他 有关各方对一个软件产品进行评论或批准。
软件可靠性：是指在给定时间内，特定环境下软件无错运行的概率
软件测试策略
软件测试策略含义：软件测试策略为软件开发人员、质量保证组织、和客户提供了一个路线图，规定了测试的主要步骤
软件测试策略V模型：
回归测试
测试中，如有缺陷修正、功能增加，变化的部分必须再测试。因为软件的修改可能会导致新的缺陷及其他问题。为防止，需再测试。
指有选择地重新测试系统或其组件，以验证对软件的修改没有导致不希望出现的影响，以及系统或组件仍然符合其指定的需求。回归测试应该尽量采用自动化测试。
回归测试可以在所有的测试级别执行，并应用于功能和非功能测试中。
自动化测试
将以人为驱动的传统测试转为以机器执行的测试方法
软件测试策略注意事项
略
软件测试基本步骤
计划与准备、执行阶段、返工与回归测试阶段
单元测试