软件工程常见名词解释&概念题

有关的教材是南大软院用的教材《软件工程与计算》，覆盖大部分软件工程的知识
可用于准备南大软院专业课842的复习，也可应对面试中有关软件工程的知识。

1. 什么是设计？
设计是一种建造之前的“规划”，包括工程部分，也包含艺术部分。

2. 软件设计
1） 广义的软件设计
程序代码时对真正软件的规划。编译器负责根据规划建造真正产品，为产生程序代码所进行的一切工作都是设计活动。
好的设计保证质量
2） 狭义的软件设计
为使以软件系统满足规定的需求而定义系统或部件的体系结构，部件，接口和其他特征的过程

3为什么要设计？
软件开发的最大挑战就是软件的复杂性，所以控制系统复杂度是软件设计方法的核心问题。

4软件产品设计
软件产品设计是规定软件产品特性，功能和接口以满足用户需求和愿望的活动，需要用户界面，交互设计，沟通，工业设计，市场营销等技能。

5软件工程设计
软件工程设计是规定程序，子系统以及他们的组成部分和工作方式以满足软件产品规格的活动。需要编程，算法，数据结构，软件设计原则，实践，过程，架构和模式等技能。

6.软件设计的层次性
高层设计描述系统的高层结构，关注点和设计决策
中层设计关注组成构件的模块的划分，过程之间的调用关系，类之间的协作
低层设计关注具体的数据结构，算法，类型，语句等

7.关注点分解：多视点方法
常见设计视角
设计视角 设计关注 样例设计语言
上下文 系统服务和用户 Uml用例图
组合 功能分解和运行时分解，子系统的构造，购买vs建造，构建的重用 Uml包图，构件图
逻辑结构 静态结构，类型和实现的重用。最重要的层，子系统，包，框架，类，接口等的概念性组织 Uml类图，对象图
依赖 互联，分享，参数化 包图，构件图
交互 对象之间的消息通讯 顺序图，通信图
动态状态 动态状态的转移 状态图

8.软件设计的标准（外部要简洁，内部要坚固）
效用：需求（功效是必须的，容易达到的）
坚固：质量（可修改性等）（坚固是设计的重点任务，是合格设计必须的）
美感包括1）简洁性，抽象，归纳，取出噪音（美感是卓越者的素质）
2）结构清新：隐喻显而易见是正确的
3）一致性：用相同的方法做相同的事情

9.软件设计过程（软件设计没有严谨，精确地过程）
1）经验主义：在软件设计过程中添加一些灵活性以应对设计中人的因素，文档化，原型，尽早验证，迭代式开发
2）理性主义：利用模型语言，建模语言，工具支持，将软件设计过程组织成系统，规律的模型建立过程，设计方法学的目标就是不断克服人的弱点，最终得到完美。

10.软件设计的演化（迭代）性
完美的理性设计不存在，真实的设计过程是演化和迭代的，不是一次完成的。反复迭代，直到最后兼顾了功效，坚固和美感。

11.软件设计的决策性 （决策要一致！）
决策：为解决一个问题而采取的决定
软件设计是问题求解和决策的过程
决策的影响因素：经验，类似的系统，参考模型，设计约定，设计原理，体系结构风格，设计模式

12.区分逻辑设计和物理设计
1）物理设计=逻辑设计+介质匹配
2）先逻辑后物理的设计思路，否则，如果介质匹配的复杂度较高，可能会扰乱逻辑设计的思路。
3）物理是逻辑在载体上的实现。物理设计复杂度=事物（逻辑）复杂度+载体与事物的适配复杂度
4）物理实现的载体
《1》低层：基本类型+基本控制结构
《2》中层：oo编程语言机制
类声明，实例创建与撤销，实例生命期管理
类权限控制机制
复杂机制，继承
《3》高层：导入导出和名称匹配
5）比较
基于抽象的体系结构更好的表现系统结构的组织，抓住系统的基本功能和主要协作机制，利用部件和连接件之间的依赖关系将部分有机的联系起来形成整体。
而实现模型更多的考虑实现细节。

13.软件体系结构模型：部件+连接件+配置
部件：在系统体系结构中封装处理和数据的元素称为软件部件，部件通常提供特定应用的服务，部件主要通过端口（port）元素定义自己的外部可见特征，即部件与外部发生联系的窗口
连接件：定义了部件间的交互。在复杂系统中，交互可能比独立部件的功能更重要且更有挑战性，连接件通过角色（role）元素定义交互参与者的特征
连接件分为显式和隐式
配置：部件和连接件是软件体系结构的独立元素单位，相互没有直接关联，配置是将部件和连接件整合起来的专门机制，配置定义部件端口与连接件角色的适配情况，并以此为基础描述整个软件体系结构

14.体系结构风格
一．主程序与子程序风格
《1》部件：程序，函数，模块
《2》连接件：他们之间的调用
《3》约束：（控制从子程序层次结构顶部开始且向下移动）
1）层次化分解，基于定义使用关系，上层使用下层，下层不能使用上层
2） 单线程控制，主程序拥有最初控制权，在使用中将控制权转移到下层
3） 隐含子系统结构，子程序通常合并成模块
4） 层次化推理，子程序的正确性依赖于他所调用的自程序的正确性
《4》实现：实现机制：模块实现，每个子程序都实现为一个模块
主程序/子程序风格是基于部件和连接件建立的高层结构，类似于结构化程序的结构，但是部件不同于程序，是粗粒度的模块，部件的实现模块内部可以用结构化分析方法也可以使用面向对象方法。
《5》效果
1） 特点：功能分解，集中控制
2） 优点：流程清晰，易于理解，强控制性，更好的控制程序的正确性
3） 缺点：强耦合，依赖于交互方的接口，难以修改和复用，隐含的共享数据交流，不必要的公共耦合，破坏“正确性”控制能力
《6》应用：功能可以分解为多个顺序执行步骤的系统
二．面向对象风格
1）将系统组织成多个对象，每个对象封装其内部的数据，并基于数据对外提供接口
2）部件：对象或模块
3）连接件：功能或调用（方法）
4）约束：
《1》数据表示对于其他对象是隐藏的，信息内聚
《2》对象负责保持数据表示的完整性，以此为基础对外提供“正确”的服务
《3》基于方法调用机制建立连接件，连接对象部件
《4》每个对象都是自主代理，不同对象之间是平级的，没有主次，从属，层次，分解等关系
5） 实现：模块实现，将每个对象部件实现为一个模块，基于面向对象分析的实现，基于结构化方法的实现
6） 应用：适用于核心问题是识别和保护相关结构信息（数据）的应用，数据表示和相关操作封装在抽象数据类型
7） 效果：
优点：可修改性，不影响外界情况下变更内部实现
易开发，易理解，易复用，自治单位，自己负责正确性
缺点：接口的耦合性：方法调用
标识的耦合性：调用其他对象需要知道对象的标识
副作用：难以实现程序的正确性（比如A.B使用C，B对C的修改可能会对A产生不可预期的影响）
三．分层风格
1）部件：通常是程序或对象的集合
2）连接件：通常是有限可见度下的程序调用或方法调用
3）层次结构，通过分解，将复杂系统划分为多个独立的层次，每一层高度内聚，层与层之间的连接器通过层间交互的协议定义
4）约束：系统组织成层，其中每一层给上一层提供服务，作为下一层的客户端，不允许跨层，层内部件可以交互。逆向调用也是不允许的
5）应用：适用于包含不同类服务的应用，而且这些服务能够分层组织，尤其当应用可能在某些层改变。例子：分层通信协议，操作系统
6）实现：关注点分离（每层逐次抽象），层间接口使用固定协议（固定控制），每层一或多个模块实现
7）效果：
优点：设计机制清晰，易于理解，支持并行开发，更好的可复用性和内部可修改性
缺点：交互协议难以修改，性能损失（禁止跨层调用，每次请求都要层次深入，多次调用，可能生成冗余的调用处理），难以确定层次数量和粒度

四．模型-视图-控制器风格
1）model：应用程序的核心，封装了内核功能和数据
业务逻辑（核心）
数据以及访问数据的函数（视图使用）
执行特定应用程序处理的过程（控制器代表用户调用）
模型对于用不可不见，M和V独立
模型独立于特定输出表示或者输入方式（M与C独立）
用户只能通过控制器模型操作（C是M与V之间的桥梁）
2）View：模型的表示，提供交互界面，向用户展示模型信息
3）Controller：处理用户和系统之间的交互
4）变更传播机制
《1》一个模型可对应多个视图，若用户通过一个视图的控制器改变了模型中的数据，那么依赖于该数据的其他视图也应该反映出这样的变化，一旦模型的数据发生了变化，模型需要通知所有相关的视图做出相应的变化。
《2》维护数据的一致性
4） 部件：model部件负责维护领域知识和通知视图变化
View部件负责给用户显示信息和将用户手势发送给控制器
Controller改变模型的状态，将用户操作映射到模型更新，选择视图进行响应
5） 连接件：程序调用，消息，事件
6） 效果：
优点：易开发性：三种不同内容的抽象，
视图和控制的可修改性：模型相对独立，模型所封装的业务逻辑相对稳定
适宜于网络系统开发的特性：业务逻辑，表现和控制的分离是得模型可以同时建立并保持多个视图
缺点：不利于理解任务实现
模型修改困难：视图和控制都依赖与模型
7） 应用：
适用于以下应用：在运行时，用户界面的改变很容易且是可能的
用户界面的调整或抑制不会影响该应用功能部分的设计和编码
例如：web应用

15.详细设计？（会画类图，以及知道类之间的关系怎么表示）
1）哪些模块需要详细设计？
 view
 逻辑层：oo设计
 数据层：数据设计：简单设计-数据库课程

3） 详细设计从哪开始？软件体系结构设计解决了需求中关键性的需求和约束，体系结构原型代码为详细设计提供了主要的代码框架，是初步方案，要进行细化–详细设计
4） 详细设计的目标：实现所有功能性需求和非功能需求（需求驱动，细化每一个构件）
5） 结果：要能够指导程序员编程的详细设计文档和详细设计原型代码
a) 模块结构和接口
b) 类结构，类的协作，类接口（面向对象分析方法）
c) 控制结构和函数接口（结构化分析方法）
d) 重要的数据结构和算法逻辑（如果有必要的方法）
6） 面向对象的设计方法：
i. 找到所有的对象（实体或者抽象概念）
ii. 找到所有的任务/协作
iii. 将任务/协作分配给对象

对象：数据+算法
对象完成自己的职责
对象自己完成不了的通过互相发送消息请求其他对象完成
对象：根据单一职责进行分解

产生典型的面向对象式风格，容易陷入分散式控制风格，可以适当补充控制器，建立委托式控制风格

7） 面向对象设计过程：
 建立设计模型
通过职责建立静态设计模型（建立类图的步骤）
抽象类的职责
抽象类之间的关系
添加辅助类
通过协作建立动态设计模型
抽象类之间的协作
明确对象的创建
选择合适的控制风格
 重构设计模型
i. 根据模块化的思想重构，目标：高内聚，低耦合
ii. 根据信息隐藏的思想重构，目标：隐藏职责和变更
iii. 利用设计模式重构

8） 通过职责建立静态模型
 抽象对象的职责
 类是对对象的抽象，是对所有具有相同属性和相同行为的对象族的一种抽象
属性职责：对象的状态
方法职责：对象的行为
 抽象类的关系
 类之间的关系表达了相应职责的划分和组合
 依赖<关联<聚合<组合<继承
 添加辅助类
 接口类
 记录类
 启动类
 控制器类
 实现数据类型的类
 容器类

9） 通过协作建立动态的模型
 抽象对象之间的协作，通过顺序图和状态图来表达软件的动态模型
 明确对象的创建：谁负责创建类的新实例？解决方案：根据潜在创建者和被实例化类之间的关系决定哪个类应该创建实例
 建立合适的系统控制风格
为了完成某一个大的职责，需要对职责的分配做很多决策，控制风格决定了决策由谁来做和怎么做决策
 分散式：所有系统行为在对象网络中广泛传播
 集中式：少数控制器记录所有系统行为的逻辑
 委托式（授权式）：决策分布在对象网络中，一些控制器作主要决策

16.耦合
描述的是两个模块之间关系的复杂程度
根据其耦合性的高低也可以以此分为内容耦合，公共耦合，重复耦合，控制耦合，印记耦合，数据耦合

17.内聚
表达的事一个模块内部的联系的紧密性
内聚可以分为7个级别，由高到低包括信息内聚，功能内聚，通信内聚，过程内聚，时间内聚，逻辑内聚，偶然内聚

18.面向对象中提高内聚的方法
 集中信息与行为
一个高内聚的类应该是信息内聚的，也就是说类的信息应该和访问这些信息的行为放在一个类中，即集中信息与行为
每个对象都会拥有数据信息和行为，这些信息和行为应该是有关联的：信息联合起来能够支撑行为的执行：行为完成对这些信息的操纵
 单一职责原则
一个高内聚的类不仅要是信息内聚的，还应该是功能内聚的，也就是说，信息与行为除了要集中之外，还要联合起来表达一个内聚的概念，而不是单纯的堆砌，这就是单一职责原则

19.面向对象的信息隐藏
 封装
 类应该通过接口对外表现他直接和间接承载的需求，而隐藏类内部的构造机理，这就是“封装”想要达到的
 封装实现细节
 封装数据和行为
 封装内部结构
 封装其他对象的引用
 封装类型信息
 封装潜在变更
如果预计类的实现中有特定地方会发生变更，就应该将其独立为单独的类或者方法，然后为单独的类或方法抽象建立稳定的接口，并在原类中使用该稳定接口以屏蔽在变更的影响
 隐藏

20．多态
 不同类型的值能够通过统一的接口来模拟，只需要不同类型的对象拥有统一定义的公共接口，就可以不论实际类型如何，直接调用该统一接口，这样系统就可以根据实际类型的不同表现出不同的行为
 子类型多态（面向对象编程中的狭义多态）
 使用继承机制实现
 表现为很多不同的子类通过共同的父类联系在一起，通过父类表现统一的接口，通过子类表现不同的行为
 程序员不需要预先知道对象的类型，具体的行为是在运行时才决定的
 多态抽象出多个类共同的行为接口，然后通过动态绑定，在运行时根据实际对象类型执行不同的行为实现

21.设计模式
 策略模式
 设计分析：
 上下文和策略分割为不同的类，上下文Context类负责满足需求，策略类Strategy负责复杂策略的实现
 上下文类和策略类之间使用组合关系
 各种策略在具体策略类（ContreteStrategy）中提供，上下文类拥有统一的策略接口。由于策略和上下文独立，策略的增减，策略实现的修改都不会影响上下文和使用上下文的客户
 解决方案
 应用场景：
 当很多相关类只在他们的行为的实现上不一样时，策略模式提供了一个很好的方式来配置某个类，让其具有上述多种实现之一
 当我们需要同一个行为的不同实现时，策略模式可以用作实现这些变体
 一个类定义了很多行为，这些行为作为一个switch选择语句的分支执行部分，这时策略模式可以消除这些分支选择
 单件模式（会写代码）
 典型问题
 在某些场景中，对于某个类，在内存中只希望有唯一一个对象存在
 每次想得到这个类的一个对象的引用的时候，都指向唯一的那个对象
 无论创建多少次这个类的对象，其实总共还是只创建了一个对象
 设计分析
 为了实现之创建一个对象，首先要让类的构造方法变为私有的
 通过静态的getInstance方法获得Singleton类型的对象的引用
 类的成员变量中拥有一个静态的Singleton类型的引用变量uniqueInstance
 getInstance方法返回引用变量uniqueInstance，如果uniqueInstance等于null，则说明首次创建，通过关键字new创建Singleton对象，并且将该对象的引用变量赋值给uniqueInstance，否则说明不是首次创建，每次只需要返回已创建的对象的引用uniqueInstance即可
 应用场景
 某个类只有一个实例，并且作为客户公共的访问点
 当单一实现需要被继承，客户能够用一个子类的实例，而不需要修改他的代码

22.设计可靠的代码
 契约式设计（会写）
 异常方式
 断言方式
 Java中断言语句的实现
为了方便实现契约式设计，java语言提供了断言语句：assert Expression 1（：Exptression 2）；
 Expression 1是一个布尔表达式，在契约式设计中可以将其设置为前置条件或者后置条件
 Expression 2是一个值，各种常见类型都可以
 如果Expression 1为true，断言不影响程序执行
 如果Expression 2 为false，断言抛出AssertionError异常，如果存在Expression 2就使用它作为参数构造AssertionError
 防御式编程（代码）
 基本思想：在一个方法与其他方法，操作系统，硬件等外界环境交互时，不能确保外界都是正确的，所以要在外界发生错误时，保护方法内部不受伤害
 常见情景（异常和断言都可以用来实现防御式编程）
 输入参数是否合法
 用户输入是否有效
 外部文件是否存在
 对其他对象引用是否是null
 其他对象是否已初始化
 其他对象的某个方法是否已执行
 其他对象的返回值是否正确
 数据库系统连接是否正常
 网络连接是否正常
 网络接受的消息是否有效

23.软件测试
 验证与确认
 验证Verification
 检查开发者是否正确的使用技术建立系统，确保系统能够在预期的环境中按照技术要求正确的运行
 例如，“检查需求文档中的书写错误”，“发现设计思路的不完备”，“审查代码中的编程错误”等就属于验证活动
 确认Validation
 检查开发者是否建立了正确的系统，确保最终产品符合规格
 例如，对“需求文档内容是否反映用户真实意图”，“设计能否跟踪到需求”，“测试是否覆盖需求”等事宜的检查属于确认活动
 测试层次
 单元测试，验证独立软件片段的功能，软件片段可以是单个的子程序，或者是由紧密联系的单元组成的较大的组件
 又称为模块测试
 是对程序单元进行正确性检验的测试工作
 在面向对象编程中，一个单元就是类的一个方法
 通常来说，程序员没修改一次程序就会进行最少一次单元测试
 测试一个单元模块时，需要构建桩程序和驱动程序，将其与其他程序单元隔离
 集成测试，验证软件组件之间的交互
 又被称为组装测试，即对程序模块一次性或采用增量方式组装起来，对系统接口进行正确性检验的测试工作
 集成测试一般在单元测试之后，系统测试之前进行
 分为自顶向下的集成测试和自底向上的集成测试
 系统测试，关注整个系统的行为，评价系统功能需求和非功能性需求，也评价系统与外界环境（例如其他应用，硬件设备等）的交互
 单元测试和集成测试的区别
 单元测试的对象是类的一个方法，集成测试的对象是系统的接口
 单元测试的主要测试方法是基于代码的白盒测试，集成测试主要是基于功能的黑盒测试
 只有单元测试通过之后才能进行集成测试，所以单元测试是集成测试的基础，直接影响着集成测试
 测试技术（经常考什么是黑盒测试和白盒测试以及都包含哪些测试方法）
 黑盒测试
 黑盒测试是把测试对象看做是一个黑盒子，完全基于输入和输出数据来判定测试对象的正确性
 测试使用测试对象的规格说明来设计输入和输出数据
 测试方法
 等价类划分
等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的，并合理的假定：测试某等价类的代表值就等于对这一类其他类的测试
等价类划分可以有两种不同的情况
 有效等价类：是指对于程序的规格说明来说是合理的，有意义的输入数据构成的集合。利用有效等价类可检验程序是否实现了规格说明中所规定的功能和性能
 无效等价类：是指对于程序的规格说明来说是不合理的，无意义的输入数据构成的集合。利用无效等价类可检验程序是否规避了各种错误和异常
 可以将其输入数据划分为三类：
 有效数据：符合前置条件
 无效数据：破坏第一个前置条件
 无效数据：破坏第二个前置条件
 边界值分析
 是对等价类划分方法的补充
 经验表明错误最容易发生在各等价类的边界上，而不是发生等价类内部。因此针对边界情况设计测试用例，可以发现更多的缺陷
 决策表
 用于测试以复杂逻辑判断为规格的测试对象
 决策表既能保证测试的完备性，又能保证成本最小
 决策表的每一列规则选项都是一个等价类
 状态转换
 针对复杂测试对象。该类复杂测试对象对输入数据的反应是多样的，还需要依赖自身的状态才能决定
 通常要先为对象建立状态图，描述测试对象的状态集合，输入集合和输入导致的状态转换集合
 以状态图为基础，可建立测试对象的转换表
 状态转换表每一行都应该被设计为测试用例
 白盒测试（将测试对象看做透明的，按照测试对象内部的程序结构来设计测试用例进行测试工作）
 语句覆盖：确保被测试对象的每一行程序代码都至少执行一次
 条件覆盖：确保程序中每个判断的每个结果都至少满足一次
 路径覆盖：确保程序中每条独立的执行路径都至少执行一次

25．软件工程定义：
1）应用系统的，规范的，可量化的方法来开发，运行和维护软件，即将工程应用到软件
2）对1）中各种方法的研究
26.软件工程的发展
 20世纪50年代
科学计算：以机器为中心进行编程，像生产硬件一样生产软件
 20世纪60年代
业务应用（批量数据处理和事务计算）：软件不同于软件，用软件工艺的方式生产软件
 20世纪70年代
结构化方法：瀑布模型，强调规律和纪律，是后续年代软件工程发展的支撑
 20世纪80年代
追求生产力最大化，现代结构化方法/面向对象编程广泛应用，重视过程的作用
 20世纪90年代
企业为中心的大规模软件系统开发，追求快速开发，可变更性和用户价值，web应用出现
 21世纪00年代
大规模web应用，大量面向大众的web产品，追求快速开发，可变更性，用户价值和创新

26.团队结构
 主程序员团队
有一名技术能力出色的成员被指定为主程序员，主程序员负责领导团队完成任务
 民主团队
因为没有集中的交流点，所以每个成员都可以发挥自己的能动性，能取得更高的士气和工作成就感
 开放团队
为了创新而存在

27.软件质量
 质量是一个过于宏观的概念，无法进行管理，所以人们通常会选用系统的某些质量要素进行量化处理，建立质量特征，这些特征被称为质量属性
 为了根据质量属性描述和评价系统的整体质量，人们从很多质量属性的定义选择了一些能够互相配合，互相联系的特征集，他们被称为质量模型
 质量模型例子
 可用性:软件在出现系统故障后保持运行的能力
 扩展性：改进或修改软件效率与功能需要花费的精力
 易学习性：用户理解软件时所花费精力的最小化程度

28.质量保障
 在软件开发过程中，要监控和执行质量保障计划，在开发活动达到一个里程碑时，要及时根据质量保障计划进行质量验证
 质量验证的主要方法有：
 评审
 评审又称为同级评审
 现在是公认的质量保障最佳实践方法
 分为六个阶段：规划阶段，总体部署阶段，准备阶段，审查会议阶段，返工阶段和跟踪阶段
 在评审中发现问题是整个评审过程的关键阶段
 测试
 质量度量

29.软件配置管理
 配置管理：用技术和管理的指导和监督方法，来表示和说明配置项的功能和物理特征，控制对这些特征的变更，记录和报告变更处理及其实现状态，并验证与需求规格的一致性
 配置项：置于软件配置管理之下的软件配置的各种有关项目，包括各类管理文档，评审记录与文档，软件文档，源码及其可执行码，运行所需的系统软件和支撑软件以及有关数据等
 基线：已经经过正式评审的规格说明或制品，可以作为进一步开发的基础，并且只有通过正式的变更控制过程才能变更

30.软件配置管理的主要活动（期末考试）

1. 标识配置项
   首先要确定有哪些配置项需要被保存和管理。其次要给配置项确定标识，设置唯一的id，最后要详细说明配置项的特征

2. 版本管理
   为每一个刚纳入配置管理的配置项赋予一个初始的版本号，并在发生变更时更新版本号

3. 变更控制
   已经纳入配置管理中的配置项发生变化时，需要依据变更控制过程进行处理

4. 配置审计
   配置审计的目标是确定一个项目满足需求的功能和物理特征的程度，确保软件开发工作按照需求规格和设计特征进行，验证配置项的完整性，正确性，一致性和可跟踪性

5. 状态报告
   配置状态报告是要标识，收集和维持演化中的配置状态信息，也就是对在动态演化着的配置项信息及其度量取快照

6. 软件发布管理
   软件发布管理是要将软件配置项发布到开发活动之外，例如发布给客户

   31.软件建立的依据
    开发软件系统的目标：解决实际问题
    单纯的软件系统是不能解决问题的，只有和现实世界之间形成有效的互动才能实现问题的解决
    研究现实世界，分析问题，寻找与现实世界互动的方法

32需求工程
 定义：所有需求处理活动的总和。他收集信息，分析问题，整合观点，记录需求并验证其正确性，最终描述出软件被应用后与其环境互动形成的期望效应
 三个主要任务：
 需求工程必须说明软件系统将被应用的应用环境及其目标，说明用来达成这些目标的软件功能，同时说明软件需要“做什么”和“为什么”需要做
 需求工程必须将目标和功能反映到软件系统当中，映射为可行的软件行为，并对软件行为进行准确的规格说明
 现实世界是不断变化的世界，因此需求工程还需要妥善处理目标和功能随着时间演化的变化情况
 需求工程的活动
1） 需求开发
 需求获取
 从人，文档或者环境当中获取需求的过程，
 要利用各种方法和技术来“发现”需求，
 需求工程师两大重要任务：
目标分析
 根据问题确定目标，问题的反面即为目标
 通过分析利害关系人确定目标
用户需求获取
 面谈，问答形式，有特定目的的直接会话
 集体获取方法，通过和用户们讨论发现需求，在讨论中达成需求的一致
 头脑风暴，集体面谈，发现潜在的需求（发明需求）
 原型，有形的制品增进用户和需求工程师之间的交流
 需求分析
 通过建模来整合各种信息，以使得人们更好的理解问题
 为问题定义出一个需求集合，这个集合能够为问题界定一个有效的解决方案
 检查需求当中存在的错误，遗漏，不一致等各种缺陷，并加以修正
 需求规格说明
 系统用户之间交流需求信息
 高质量：要简洁，精确，一致和易于理解
 需求工程师的两大重要任务
 定制文档模板
 编写文档
 需求验证
 需求阶段的错误在维护阶段才发现，在维护阶段进行修复的代价可以高达需求阶段修复代价的100-200倍
 需求规格说明文档至少要满足下面几个标准

1. 文档内每条需求都正确，准确的反映了用户的意图
2. 文档记录的需求集在整体上具有完整性和一致性
3. 文档的组织方式和需求的书写方式具有可读性和可修改性
    同级评审，原型等

2） 需求管理
 需求管理：保证需求作用的持续，稳定和有效发挥
 进行变更控制

33.需求定义

1. 用户为了解决问题或达到某些目标所需要的条件或能力
2. 系统或系统部件为了满足合同，标准，规范或其他正式文档所规定的要求而需要具备的条件或能力
3. 对1）或2）中的一个条件或一种能力的一种文档化表述

34.问题域
 现实世界运行规律的一种反映
 需求的产生地，也是需求的解决地
 最终的软件产品要在现实中部署，它能够部分影响问题域，但不能任意改变现实
软件开发必须尊重问题域，不能因为技术原因妄自修改现实世界的实际情况

35.规格说明
 软件产品的方案描述，他以软件产品的运行机制为主要内容
 他不是需求但实现需求，不是问题域但需要与问题域互动
 要以关注对外交互的方式描述软件解决方案，它既需要以软件产品的角度而不是用户的角度进行描述，又不能太多的涉及软件产品的内部构造机制

36.问题，需求，问题域，规格说明
下面信息内容是哪一种？
 超市的成本太高 问题
 超市的成本应该降低 需求
 超市的成本主要由人力成本和库存成本组成 问题域
 系统的成本计算为：成本=人力成本+库存成本 规格说明

37.需求层次性（给例子写用户需求，业务需求和系统需求）
目标：业务需求（解决方案与系统特性）
 系统建立的战略出发点，表现为高层次的目标，他描述了组织为什么要开发系统
 为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性
任务：用户需求（问题域知识）
 执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么
 用户需求表达了用户对系统的期望，但是要透彻和全面的了解用户的真正意图，仅仅拥有期望是不够的，还需要知道期望所来源的背景知识，因此，对所有的用户需求，都应该有充分的问题域知识作为背景支持

系统行为：系统级需求（需求分析模型）
 用户对系统行为的期望，每个系统级需求反映了一次外界与系统的交互行为，或者系统的一个实现细节
 直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么
 一系列的系统级需求联系在一起满足一个用户需求，进而满足业务需求

38，将用户需求转化为系统需求的过程是一个复杂的过程
 首先需要分析问题域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型
 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让他们联合起来实现用户需求，每一个系统行为即为一个系统需求
 该过程就是需求工程当中最为重要的需求分析活动，又称为建模与分析活动

39．软件需求的分类（给出需求让写出属于什么需求）
 功能需求
 定于：和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互
 最常见，最主要和最重要的需求
 能够为用户带来业务价值的系统行为
 最需要按照三个抽象层进行展开
 软件产品产生价值的基础
 性能需求
 定义：系统整体或系统组成部分应该拥有的性能特征，例如cpu使用率，内存使用率
 速度，系统完成任务的时间
 容量，系统所能存储的数据量
 吞吐量，系统在连续的时间内完成的事务数量
 负载，系统可以承载的并发工作量
 实时性，严格的实时要求
 质量属性
 定义：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求例如可靠性程度，可维护性程度等
 通常是隐式的，在需求开发时非常困难
 极大的影响软件体系结构的设计
 可靠性：在规定时间间隔内和规定条件下，系统或部件执行所要求能力的能力
 可用性：软件系统再投入使用时可操作和可访问的程度或能实现其指定系统功能的概率
 安全性：软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意的，也可能是无意的
 可维护性：软件系统或部件能修改以排除故障，改进性能或其他属性或适应变更了的环境的容易程度，包括可修改性和可扩展性
 可移植性：系统或部件能从一种硬件或软件环境转换至另外一种环境的特性
 易用性：与用户使用软件所花费的努力及其对使用的评价相关的特性
 对外接口
 定义：系统和环境中其他系统之间需要建立的接口，包括硬件接口，软甲接口，数据库接口等
 约束：（总体上限制了开发人员设计和构建系统时的选择范围）
 系统开发及运行的环境
 问题域内的相关标准
 商业规则
 其他数据需求
功能需求的补充，如果在功能需求部分明确定义了相关的数据结构，那么就不需要再行定义数据需求
数据需求是需要在数据库，文件或者其他介质中存储的数据描述，通常包括以下内容
 各个功能使用的数据信息
 使用频率
 科访问性要求‘
 数据实体及其关系
 完整性约束
 数据保持要求’

40.需求分析的任务
 建立分析模型，达成开发者和用户对需求信息的共同理解
将复杂的系统分解成简单的部分以及这些部分之间的关系
确定本质特征，抛弃次要特征
 依据共同的理解，发挥创造性，创建软件系统解决方案

41.模型与建模
 模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解。
 建立模型的过程称为建模。“它是对系统进行思考和推理的一种方式。建模的目标是建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易”
 抽象
 关注重要的信息，忽略次要的内容
 将人质保留在适当的层次，屏蔽更深层次的细节
 通过强调本质特征减少问题复杂性
 分解
 将某个复杂难以理解的问题分解成多个相对容易的子问题，并掌握各子问题的联系
 分而治之

42.需求分析模型
描述软件解决方案的模型技术
 介于用户概念和软件内部实体之间的模型形式
 使用软件的内部实体作为模型的基本元素（对象，函数，属性等）
 使用问题域的概念描述软件内部实体，使用问题域语言表现语义

43.用例
 基本特点：目标，交互，场景（行为序列）
 定义：在系统（或子系统或者类）和外部对象的交互当中所执行的行为序列的描述，包括各种不同的序列和错误的序列，他们能够联合提供一种有价值的服务
 用例描述了在不同条件下系统对某一用户的请求的响应。根据用户的请求和请求时的系统条件，系统将执行不同的行为序列，每一个行为序列被称为一个场景，一个用例是多个场景的集合
 用例模型：以用例为单位建立的一个系统功能展示模型，是系统所有用例的集合，以统一，图形化的方式展示系统的功能和行为特性
 基本元素：
 用例，代表了一组典型的场景，帮助构建，关联，和理解基本需求
 参与者是与开发的系统进行交互的用户或其他系统等角色
用例图中一个单一的参与者可以代表多个用户（或系统）
一个单一的用户（或系统）可能扮演多种角色
参与者不一定是人，例如，需要从当前系统获取信息的外部系统也是参与者
 关系，参与者之间的关系：泛化
用例之间：泛化，包含，扩展
参与者与用例之间：关联
 系统边界
系统所包含的系统成分与系统外事务的分界线，用矩形框表示系统边界
参与者通常在边界外面，用例通唱在边界里面

44.用例图的建立
 目标分析与确定解决方向
 寻找参与者
 寻找用例
 细化用例
如果用例的粒度不合适就需要进行细化和调整
 判断标准是：用例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的业务
 不要将没有业务价值（而是技术实现需要）的事件作为用例（例如，登录（安全性需求），输入输出数据检查（数据需求或者业务规则），数据库连接，网络传输等）
 不要将没有独立业务价值的单个操作（他们仅仅是技术实现上独立）作为用例，例如删除，增加，修改，保存等等
 常见错误
 不要将用例细化成单个操作
 不要将单个步骤细化成用例
 不要将片面的一个方面细化成用例‘
 不要将登录，数据验证，连接数据库等没有业务价值的内容作为用例

45.用例描述（给出场景让写用例）
项目 内容描述
Id 用例的标识
名称 对用例内容的精确描述，体现了用例所描述的任务
参与者 描述系统的参与者和每个参与者的目标
触发条件 标识启动用例的条件，可能是系统外部的事件，也可能是系统内部的事件，还可能是正产流程的第一个步骤
前置条件 用例能够正常启动和工作的系统状态条件
后置条件 用例执行完成后的系统状态条件
正常流程 在常见和符合预期的条件下，系统与外界的行为交互序列
扩展流程 用例中可能发生的其他场景
特殊需求 和用例相关的其他特殊需求，尤其是非功能性需求

46.交互图
 描述对象之间的协作
 通常描述的是单个用例的典型场景，他也因此被称为“用例的实现”
 交互图有顺序图，通信图，交互概述图和时间图四种类型，其中顺序图是最为常用的一种

47.顺序图
以交互行为中的消息序列为主，消息以时间顺序在图中从上到下排列

48.系统顺序图
 系统顺序图将整个系统看做一个黑箱的对象而描述的简单顺序图形式，他强调外部参与者和系统的交互行为，重点展示系统级事件
 通过建立系统顺序图模型，可以：
 通过匹配“刺激/响应”发现交互行为的缺失
 只有用户发起刺激，系统才会有响应，否则意味着用户行为信息丢失
 用户发起刺激后，系统必须有响应，否则意味着软件响应行为丢失
 一个刺激，通常有一个系统响应，也可以有连续的多个响应
 通过分析每个刺激响应的异常，发现流程的异常

49.概念类图
 又被称为“领域模型”
 类图是面向对象分析方法的核心
描述类（对象）和这些类（对象）之间的关系
 概念类图与设计类图有所不同
关注现实世界问题域，而不是软件系统的内部构造机制
 类型，方法，可见性等复杂的软件构造细节不会在概念类图中
 基本元素
 对象：使用具体问题域事物的抽象
标识符：对象的引用
状态：对象的特征描述，包括对象的属性和属性的取值
行为：状态发生变化或者接收到外界消息时采取的行动
 类：对象的集合
 链接：对象之间的交互协作的关系
 关联：类之间的关系，潜在的链接抽象
聚合：部分和整体之间的关系，空心菱形
组合：整体对部分有完全的管理职责，即一个部分只能属于一个整体，实心菱形
 继承：父类是子类的泛化，子类是父类的特化
 将领域对象类组织成层次结构
 最高层的类反应了所有类的共同特点
 对象类从一到多个父类继承属性和服务，这些属性和服务可能在必要时特化

50.建立概念类图（会画）
 对每个用例文本描述，尤其是场景描述，建立局部的概念类图
 根据用例的文本描述，识别候选类（找名词）
 筛选候选类，确定概念类
 如果候选类的对象实例既需要维持一定的状态，又需要依据状态表现一定的行为，确定为一个概念类
 如果需要维护状态，不需要表现行为，则为其他概念类的属性
 不需要维护状态。却需要表现行为
首先要重新审视需求是否有遗漏，因为没有状态支持的对象无法表现行为
如果确定没有需求的遗漏，就应该删除该候选类，并将行为转交给具备状态支持能力的其他概念类

 既不需要维护状态，又不需要表现行为，应该被完全删除

 识别关联
 分析用例文本描述，发现概念类之间的协作，需要协作的类之间需要建立关联
是否需要协作的第一标准是满足需求的要求
是否需要协作的第二标准是现实状况
 分析和补充问题域内的关系，例如概念类之间的整体部分关系和明显的语义联系。对问题域关系的补充要适可而止，不要把关系搞得过度复杂化
 去除冗余关联和导出关联

 识别重要属性
 将所有用例产生的局部概念类图进行合并，建立软件系统的整体概念类图

51．有限状态机
 有限状态机理论认为系统总是处于一定的状态之中，并且，在某一个时刻，系统只能处于一种状态之中
 系统在任何一个状态中都是稳定的，如果没有外部事件触发，系统会一直持续维持该状态
 如果发生了有效的触发事件，系统将会响应事件，从一种状态转移到另一种状态中
 状态图的基本思想：基于有限状态机理论，如果能够罗列出所有可能的状态，并发现所有有效的外部事件，那么就能够从状态转移的角度完整的表达系统的所有行为

52.状态图的基本概念
 状态：一组观察到的情况，在一个给定的时间描述系统行为
 状态转移：从一个状态到另一个状态的转移
 事件：导致系统表现出可预测行为的事件
 活动：作为转换的结果而发生的过程

53.状态图的建立
 确定上下文环境
状态图是立足于状态快照进行行为描述的，因此建立状态图时 首先要搞清楚状态的主体，确定状态的上下文环境，常见的状态主体有：类，用例，多个用例和整个系统
 识别状态
状态主体会表现出一些稳定的状态，他们需要被识别出来，并且标记处其中的初始状态和结束状态集，在某些情况下，可能会不存在确定的初始状态和结束状态
 建立状态转换
根据需求所描述的系统行为，建立各个稳定状态之间可能存在的转换
 补充详细信息，完善状态图
添加转换的触发事件，转换行为和监护条件等详细信息