①superordinate systems（上级系统） ②subordinate systems（下级系统） ③peer-level systems（同级系统） ④Actors（参与者）
5. 原始模型（archetype）是一个类或者一个模式，描述了一个目标系统体系结构设计的核心抽象。但是随着体系结构设计的进行，这些抽象必须被进一步精化。
6. 体系机构设计中的三种依赖：
①sharing dependency（共享依赖）：消费者间或生产者间的依赖关系 ②flow dependency（流依赖）：生产者和消费者间的依赖关系
③constrained dependency（约束依赖）：在一组活动间相关控制流上的约束。
7.转换流（transform flow）：the overall flow of data occurs in a sequential manner and follows one，Or only a few，\straight line\。
8.事务流（transaction flow）：with a single item that triggers other data flow among one of many paths of a data flow diagram，transaction flow characterizes the information flow。
Within a DFD for a large system，both transform flow and transaction flow may be present。（在一个大的DFD中，交换流和事务流可能会同时出现）
9.在一些面向流模型中这两种类型的数据流都会经常遇到（encounter），这些流被分割成段，并且使用适当的映射获取程序结构。
10. 事务映射第一级分解分出软件控制层，第二级分解在合适的控制器下分布“第一线工作者模块”。
第十一章——构件级设计建模
1.在面向对象软件工程环境中，构件包括一个协作类集合。 2.传统构件承担的三个角色：
①control component（控制构件）
②problem domain component（问题域构件） ③infrastructure component（基础设施构件）
3.构件开发的原则
OCP原则的内容、优点和实现方法
开关原则（OCP）：模块应该对外延具有开放性，对修改具有封闭性 优点：无需对构件自身内部做修改就可以进行扩展的方式来说明构件
实现方法：设计者在那些可能需要扩展的功能与设计类本身之间分离出一个缓冲区 LSP、DIP、ISP、REP、CCP、CRP
4.那些体现出功能、层和通信等内聚性的类和构件，相对来说易于实现、测试和维护。 5.Persistent data source 包含①databases ②files
6.OCL对象约束语言complements UML by allowing a software engineer to use a formal grammar and syntax to construct unambiguous statements about various design model language。
OCL的四个最简单组成：语境（context）、特性（property）、操作（operation）、关键字（keyword）
16
7. 结构化编程是局限于逻辑流的设计技术，它有三种构造： ①顺序型（sequence） ②条件型（condition） ③重复型（repetition）
结构化设计的优点：reduce complexity，enhances readability、testability、and maintainability
8. 传统构件的三种设计表示： ①graphical——flowchart
②tabular——resultant decision table ③text-based formats
9. 在构建级设计中，面向对象的观点和传统的观点的区别?
面向对象的观点注重细化来自于问题域和基础设施域的设计类；而传统的观点则细化三种不同的构建或模块。
第十二章——user interface design
1. 用户接口设计的黄金法则（golden rule） ①place the user in control(置用户于控制之下)
②reduce the user's memory load（减少用户的记忆负担） ③make the user interface consistent（保持界面一致）
2.用户必须记住的东西越多，则越容易出错。减少用户记忆负担： ①减少对短期记忆的要求。
②建立有意义的缺省（meaningful defaults）
③定义直观的快捷方式（shortcuts that are intuitive） ④界面的布局应当基于真实世界的象征
⑤以不断进展（progressive）的方式揭示信息
3. 至于用户控制之下：
①以不强迫用户进入用户不必要的或不希望的动作的方式来定义交互方式 ②提供灵活的交互
③允许用户交互可以被中断和撤消
④当技能级别增加时可以使交互流水化并允许定制交互 ⑤使用户隔离内部技术细节
⑥设计应允许用户和出现在屏幕上的对象直接交互
4. 界面一致（interface consistent）的设计原则： ①允许用户将当前任务放入有意义的语境 ②在应用系列内保持一致性
③如过去的交互模型已建立起了用户期望，除非有迫不得已的理由，不要改变它
用户以一致的方式展示和获取信息，意味着
①all visual information is organized according to a design standard
②input mechanisms are constrained to a limited set that is used consistently throughout the application。
③mechanisms for navigating from tasks to tasks are consistently defined and implemented
17
5. 用户界面设计的四种模型：
①user model：establish the profile of end-users of system。（建立系统最终用户的轮廓） ②design model：包括对软件的数据、体系结构、界面和程序上的表示。
③mental model心理模型（system perception系统感觉）：the image of the system that end-user carry in their heads。
④implementation model：结合了计算机的外在表现（界面的感觉），结合了所有用来描述系统语法和语义的支撑信息。
6. 用户界面设计分析的四个框架活动：
①user、task、and environment analysis and modeling ②interface design
③interface construction（implementation） ④interface validation
7. 用户界面设计模式（pattern）：Each of the example patterns presented would also have a complete component-level design，including design classes、attributes、operations、and interfaces。
8. 用户界面设计时遇到的问题： ①system response time ②user help facilities
③error information handling ④menu and command labeling
9. 评估时观察用户与界面交互，记录如下数据：
①number of tasks correctly completed over a standard time period ②frequency of actions ③sequence of actions
④time spent looking at the display ⑤number and types of error ⑥error recovery time ⑦time spent using help
⑧number of help references per standard time period
十三章——测试策略
1.测试的顺序：
①unit testing：充分利用测试技术，检查构件中每个控制结构的特定路径以确保完全覆盖，并最大可能地发现错误。
②integration testing：处理并验证与程序构造相关的问题。
③validation testing ：为满足所有的功能、行为和性能需求提供最后的保证
④system testing：验证所有的成分能合适地结合在一起，且能满足整个系统的功能/性能需求。
2. Guidelines lead to a successful software testing strategy （P361）
①specify product requirements in a quantifiable manner long before commence。（在最早开始测试之前，要以量化的方式规定产品需求）
18
②conduct formal technical reviews to assess the testing strategy and test cases themselves。（实施正式技术评审以评估测试策略和测试用例本身·）
3. unit test（单元测试）要测的单元： ①interface
②local data structure
③boundary conditions：确保模块在达到边界值的极限或受限处理的情形下仍能正确执行 ④independent paths（execution path） ⑤error handing paths
Because a component is not a stand-alone program（独立程序），driver and/or stub software （驱动软件和或桩软件）must be developed for each unit test。
4. Integration test（集成测试）：is a systematic technique for constructing the software architecture while at the same time conducting tests to uncover errors associated with interfacing 。 ①top-down（自顶向下）integration：
A. no drivers need to be written，但还是要stubs
B. The top down integration strategy verifies major control or decision points early in the process。
C.主控模块用作测试驱动程序，所有的桩模块替换为直接从属于主控模块的模块。
②bottom-up integration（自底向上）：the need for stubs is eliminated（不需要stubs )，排除了对复杂桩的需求。
③regression test（回归测试），为什么说回归测试是集成测试流程中的关键部分？
因为在集成测试策略的环境下，每加入一个新的模块作为测试的一部分时，软件会发生变更，这些变更可能会是使本来可以正常工作的功能产生问题，而回归测试只是重新执行已进行测试的某个子集，以确保变更没有传播不期望的副作用。
④smoking testing（冒烟测试）：一种滚动（rolling）的集成测试方法，是时间关键性（time-critical）项目的步进机制，它让软件团队频繁地对项目进行评估。
5.面对对象环境中的集成测试：
①基于线程的测试（thread-based），集成响应系统的一个输入或事件所需的一组类 ②基于使用的测试（use-based）
6. 调试使错误清除，发生在测试之后。三种调试方法（debugging tactics）： ①brute force（蛮力法）：最常用但最低效的方法 ②backtracking（回溯法）：常用用于小程序
③cause elimination（原因排除）：通过归纳演绎引入二分法 7.为什么需要“独立测试组”
独立测试组（ITG）的作用是为了避免开发人员进行测试所引发的固有问题，它可以消除可能存在的认识差异。
第十四章
1.可测性（testability）的特征
①operability ②observability ③controllability ④decomposability(可划分) ⑤simplicity ⑥stability ⑦understandability
19
2. A good test
①high probability of finding an error ②is not redundant
③should be best breed（最佳品种）
④should be neither too simple or too complex
3. 黑盒测试：knowing the function that a product has been designed to perform，可执行显示每个功能是可操作的，同时查找在每个功能中的错误。暗指在软件接口处执行测试，很少关心软件的内部结构。
黑盒测试找到的错误类型： ①功能不正确或遗漏 ②接口错误
③数据结构或外部数据库访问错误 ④行为或性能错误 ⑤初始化和终止错误
Equivalence partitioning（等价划分）是一种黑盒测试，divides the input domain of a program into classes of data from which test cases can be derived。
4. 白盒测试：knowing the internal working of a product，可以测试以保证内部操作依据规格说明执行，而且对所有的内部构件已进行了充分的说明。基于过程细节的封闭检查。
5. 黑盒测试与白盒测试的比较
黑盒测试是从用户观点，按规格说明书要求的输入数据与输出数据的对应关系设计测试用例,是根据程序外部特征进行测试。
白盒测试是根据程序内部逻辑结构进行测试。 黑盒测试 白盒测试 ①适用于各阶段测试 ①可构成测试数据使特定程序部分得到测试 优 ②从产品功能角度测试 ②有一定的充分性度量手段 点 ③容易入手生成测试数 据 ③可或较多工具支持 ①不易生成测试数据(通常) ①某些代码得不到测试 缺 ②无法对未实现规格说明的部分进行测试 ②如果规格说明有误，则无法发现 点 ③工作量大，通常只用于单元测试，有应用局③不易进行充分性测试 限 性 是一种确认技术，回答 是一种验证技术，回答 质 “我们在构造一个正确的系统吗？” “我们在正确 地构造一个系统吗？”
6. Cyclomatic complexity（环复杂性）is a software metric that provides a quantitative measure of the logical complexity of a program（环复杂性是一种软件度量，它为程序的逻辑复杂度提供一个量化的测度）。When used in the context of the basis path testing method，the value computed for Cyclomatic complexity defines the number of independent paths。（环复杂性的值是独立路径的条数）
环复杂性V(G)=E-N+2 （E是流图边数，N是流图节点数）
20