    将软件开发过程划分成若干个阶段，并规定每个阶段必须完成的任务，各阶段之间具有某种顺序性； 
    体现出对于复杂问题“分而治之”的策略，但主要问题是缺少灵活性，缺少应对各种未预料变化的能力，这些变化却是在实际开发中无法避免的；
    当软件规模比较大，尤其是开发的早期需求比较模糊或者经常变化的时候，这种方法往往会导致软件开发的不成功或维护困难。

面向对象方法

特点

面向对象方法学的出发点和基本原则，是尽可能模拟人类习惯的思维方式。用面向对象方法学开发软件的过程，是一个主动地多次反复迭代的演化过程。概念和表示方法上的一致性，阶段间平滑（无缝）过渡。特殊到一般的归纳思维过程；一般到特殊的演绎思维过程。（继承的思想）

最终产品中的对象与现实世界中的实体相对应，降低了复杂性，提高了可理解性，简化了软件的开发和维护工作。对象是相对独立的实体，容易在软件产品中重复使用，促进了软件重用。面用对象方法特有的继承性，也进一步提高了面向对象软件的可重用性。

第2章软件开发过程（不是重点，但是会考选择，个人感觉带一眼那几个模型就行了）

软件过程和生命周期

过程管理主要采用的是一种“分而治之”的思想，即将整个软件的生命周期划分成软件定义、软件开发和运行维护三个主要的时期，每个时期再细分为具体的阶段，分别对应明确的任务。

传统生命周期模型

瀑布模型

特点:

    阶段间具有顺序性和依赖性，文档驱动
    推迟实现，不急于编写代码
    尽可能的理解和掌握系统需求，
    清楚地区分逻辑设计与物理设计，尽可能推迟程序的物理实现

质量保证的观点: 每个阶段都必须完成规定的文档，没有交出合格的文档就是没有完成该阶段的任务。每个阶段结束前都要对所完成的文档进行评审，以便尽早发现问题，改正错误。

问题:

    不希望有“变化”变化来的越晚，付出的代价越高。
    设计阶段过多的假设，导致理想化、一厢情愿的东西过多。(用户只参与需求)
    “文档驱动”，静态

快速原型模型

快速原型模型（Rapid Prototype）的主要作用是在用户和开发者之间起到“桥梁”的作用。

特点：

    快速原型模型要求对系统进行简单和快速的分析，快速构造一个软件原型。
    用户和开发者在试用或演示原型过程中加强沟通和反馈，通过反复评价和改进原型，减少双方的误解，降低缺陷引入的几率，降低由于需求不明确带来的开发风险和提高软件质量，获取到用户真正的需求。
    比较适合一个全新的系统开发，用户借助原型了解开发方向的正确性，如用户界面的构建，使用户建立起对未来系统的认识和了解。
    快速原型中可以尝试运用未来系统中需要的新技术，提前测试一些性能上的要求是否能够达到预期。

问题：所选用的开发技术和工具不一定是实际项目的需要。快速建立起来的模型可能由于不符合各种开发规范，再加上不断的修改，质量一般都比较差，通常在实际开发过程中会完全抛弃之前建立起来的原型系统

增量模型

也称为渐增模型。把软件产品作为一系列增量构件来设计、编码、集成和测试。

每个构件由多个相互作用的模块构成，并且能够完成特定的功能。使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。(滚雪球方式)

螺旋模型

螺旋模型的基本思想是使用原型及其它方法尽量降低风险 – 在每个阶段之前都增加了风险分析过程的快速原型模型

特别适合于大型复杂的系统。螺旋模型沿着螺线进行若干次迭代，四个象限代表了不同的活动

喷泉模型

迭代是OO开发过程的主要特性。喷泉模型是典型的面向对象生命周期模型。 “喷泉”体现了面向对象软件开发过程迭代和无缝的特性。为避免喷泉模型的过分无序，把一个线性过程作为总目标。

软件开发

敏捷软件开发

敏捷开发更适合规模中小、需求变化频繁的系统开发，并且强调团队的作用，所以更适合集中式的开发模式。

精确质量速度丰厚的投资回报率高效的自我管理团队

极限编程（XP）

主要目的是降低需求变化的成本崇尚的开发方法：客户代表与开发团队紧密融合、结对编程（pair-programming）等等开发流程：编写用户故事、架构规范、实施规划、迭代计划、代码开发、单元测试、验收测试积极接受变化

价值观与原则：互动与交流、反馈、简单、勇气、团队

核心做法：

    小规模，频繁的版本发布，短迭代周期
    测试驱动开发（Test-driven development）
    结对编程（Pair programming）
    持续集成（Continuous integration）
    每日站立会议（Daily stand-up meeting） 
    共同拥有代码（Collative code ownership）
    系统隐喻（System metaphor）

Scrum

Scrum是一个包括了一系列的实践和预定义角色的过程骨架（是一种流程、计划、模式，用于有效率地开发软件）

冲刺Sprint: 一个时间周期（通常在2周到1个月之间），开发团队会在此期间内完成所承诺的一组订单项的开发。

第3章需求分析(重点：用例图、活动图、数据流图)

用户需求与系统需求

系统需求是对用户需求的细化和完善。系统需求的阅读对象是开发者，而用户需求的阅读对象是委托方或客户。系统需求是用户需求的开始，用户需求需要得到委托方的确认。无论是系统需求还是用户需求，在调研的时候都需要搞清楚以下两个基本问题：

    – 项目涉及到的主要目标人群有哪些？
    – 项目主要的目标是什么？

涉众

涉众是与目标系统相关的一切人和物，他们对目标系统的构建会有一定的影响。涉众是一个比较宽泛的概念，可以是提出系统原始需求的人，可以是委托方，也可能是使用目标系统的最终用户等等。涉众可能并不固定，有时会对系统的设计策略和实现方式有着深远的影响。涉众的重要程度是不同的。

    – 准确的识别出来，并确定其优先级
    – 需要斡旋和协调，让目标系统满足大多数涉众的要求

常见的涉众：最终用户（直接涉众）、投资者、业务提出者、业务管理者、业务执行者、其他涉众（第三方、开发方、法律法规等）

用例（重点）

定义

使用一种交互的方式来描述系统的场景，借以“捕获”用户的需求。 “捕获”指对业务用例不是简单静态说明，要构建动态的场景，强调的参与者的活动。用例又称为是用户故事（User Story），是对需求的深入分析和理解的输出结果。 – 用例的完善需要迭代，每次添加一些业务细节

用例的表示（用例图）

寻找用例

考虑在业务系统中进行管理和处理的关键业务实体，通常是与业务相关的一些关键概念或技术术语，如：

 软件项目（Project）：每个软件项目对应着一个在系统中组织和管理的基本结构，项目开发者以团队的形式参与其中。
 员工（Employee）：即开发者，是项目实施的基本单位，可进一步组成团队的结构。

每个业务实体对应5个基本用例（根据情况合并、正名）

  1. 创建新业务实体数据的用例；
  2. 修改已有业务实体数据的用例；
  3. 删除已有业务实体数据的用例；
  4. 持久化某业务实体数据的用例，比如存储到数据库中；
  5. 访问某业务实体数据的用例，比如从存储的文件或数据库中读出。

考虑业务相关的过程数据，即围绕基本业务实体的加工和组合而产生的数据，会在业务执行期间频繁和显著的发生变化。
进一步研究系统功能，这些功能往往需要在以上识别出的基本实体数据和动态过程数据的基础上做进一步的利用和计算。
需要考虑是否存在对正在运行的其它系统的交互。

用户用例和系统用例

业务用例：是从客户的角度出发描述某个业务的具体工作流，也是一次涉众与实现业务目标功能之间的交互，其中可能包含手工和自动化的过程，也可能发生在一个长期的时间段中

系统用例：是从计算机系统的角度描述业务系统，其业务边界就是这个计算机系统的设计范围。

用例间关系

扩展和包含的关系

一般来说被包含用例属于无条件发生的用例，而扩展用例属于有条件发生的用例；被包含用例提供的是间接服务，扩展用例提供的是直接服务；而且扩展用例在用例规约中一般作为基本事件的备选流而存在。扩展关系与包含关系要注意区分，不小心很容易混淆，需要设计人员仔细甄别正确的业务含义及其关系。

数据流图（重点）

画法

从基本系统模型高的抽象层次开始画数据流图。把基本系统模型细化，描绘系统主要功能。在图中给处理和数据存储加编号，便于引用和追踪分层细化时保持信息连续性

命名应代表整个数据流(数据存储、处理)的内容，而不是仅仅某些成分。命名不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。处理名字最好是一个具体的及物动词。

第4章软件架构的构建(着重看一下那几个系统和架构和包图)

系统架构

软件架构设计就是建立系统所需的数据结构和程序构件，考虑：

    – 体系结构风格
    – 组成构件的结构和属性
    – 所有体系结构构件之间的相互关系

软件架构

定义

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成

软件架构不仅指定了系统的组织结构和拓扑结构，并且显示了系统需求和构成系统的元素之间的对应关系，提供了一些设计决策的基本原理

“4+1”视图模型

根据建模的侧重点不同，可以将软件架构的模型分为五种：结构模型、框架模型、动态模型、过程模型和功能模型

逻辑视图：支持面向对象的分解。逻辑架构主要用来支持功能性需求——满足用户服务的系统功能进程视图：进程的分解。进程架构考虑一些非功能性的需求，如性能和可用性开发视图：子系统的分解物理视图：软件至硬件的映射用例视图：综合所有的视图。（+1）

基本元素

构件是具有某种功能的可重用的软件模板单元，表示了系统中主要的计算元素和数据存储如：复合构件、原子构件连接件表示构件之间的交互 –简单的连接件如：管道、过程调用、事件广播等 –复杂的交互如：如客户/服务器通信协议、数据库和应用之间的SQL连接等。配置表示了构件和连接件的拓扑逻辑和约束。

通用体系结构风格的分类

数据流风格：批处理序列、管道与过滤器等调用/返回风格：层次结构、正交软件结构、客户机/服务器结构、浏览器/服务器结构等独立构件风格：进程通信、事件系统、MVC结构等虚拟机风格：解释器、基于规则的系统等数据中心风格：数据库系统、超文本系统、仓库/黑板系统等

第5章类的分析与设计(重中之重)

类及其种类

在系统分析与设计阶段，类通常分为实体类（Entity Class）、控制类（Control Class）和边界类（Boundary Class）

实体类：对应需求中的实体，通常需要永久保存，一般使用数据库表或文件来记录，既包括存储和传递数据的类，还包括操作数据的类。（名词、POJO）控制类：用于体现应用程序的执行逻辑，提供相应的业务操作，抽象控制类可以降低界面和数据库之间的耦合度。控制类有时也称为管理类。（动宾）边界类：边界类用于对外部用户与系统之间的交互对象进行抽象，主要包括界面类以及与外部系统的数据交换类(如同步、缓存等)。

在分析设计初始，通常首先识别出实体类，绘制初始类图，也可称为领域模型。

按照语法分析的方式将名词作为对象的候选，形容词作为属性（实例变量）的候选进行重点关注

方法和管理类

访问和修改方法，不涉及业务，在分析模型中通常不考虑，实现阶段再考虑对象通常还提供了只需通过内部信息，如实例变量，对业务数据进行计算的方法对于同类对象的协调和管理通常使用一个管理类，主要负责对对象的创建、代理访问其它对象的信息等。管理类必须能够提供所管辖所有对象统一的处理方式

控制类

控制类通常控制和协调不同对象的行为，用来封装用例的特有行为。复杂用例一般都需要一个或多个控制类借助控制类可将边界对象与实体对象分开，让系统更能适应其边界内发生的变更控制类还将用例所特有的行为与实体对象分开，使实体对象在用例和系统中具有更高的复用性

第6章代码生成(重中之重)

一些杂七杂八的概念

CASE工具：计算机辅助软件工程，软件开发环境指支持软件开发的工具及其集成机制，用以支持软件开发的过程、活动和任务，为软件的开发、维护及管理提供统一的支持

IDE：集成开发环境，是软件开发环境中的一种实现方式

“变更”的管理方式：

    需求分析、概要设计和详细设计阶段只进行一次或者迭代-增量式的进行。每次修改只发生在代码，其它文档不做更新
    每个改动的意愿都要经过完整的分析、概要设计和详细设计流程，所有必须的改动需要在所属的文档以及代码中对应修改，并保证它们的一致性
    以上两种方式的选择需要根据项目需要进行确定，或者在两者之间折中

逆向工程：将代码的修改反向映射回类图的设计中，从而在设计与代码实现之间保证一致性。需要设计和编码工具紧密集成和配合

单个类的代码实现

带有下划线的方法和属性表示静态方法和静态变量 +代表public -代表private #代表protected

系统的4+1视图(感觉不是重点，不用看)

进程视图：

    可能的独立运行的进程或者线程以及关联的活动对象。
    Java是从Thread类继承或Runnable接口实现的类，具有方法run()。
    UML中另外的描述使用构造型<<thread>>或<<process>>对活动类进行表示

开发视图：

    构件图能够描述多个构件的构成及它们之间的联系。
    除了接口说明外，可以通过<<realization>>说明该构件中包含的类、其它工件<<artifact>>、相关文件和资源等。

物理视图：

    部署图描述哪些软件构件最终在哪些机器上运行的情况
    硬件节点、可运行程序<<executable>>和相关工件<<artifacts>>
    网络连接数目

第7章类的详细设计（重点）

判定表(决策表)

判定表是一种进行详细设计的表格工具，又称为决策表判定表有4个部分构成，分别是条件列表、条件组合、动作列表及动作入口每个条件对应一个变量、关系或者预测，如上例中的机器功率、运行时长、维修记录；条件组合是各种条件可能取值的所有组合，如果每个条件有真假两种取值，则n个条件的取值组合数量为 $2^n$ 个动作入口指某个条件组合下与动作的对应，与条件组合一起构成了判定表的一列，也叫做规则

化简：

判定树

判定树又称为决策树，是应用于数据分类的一种树结构每个内部结点（internal node）代表对某个属性的一次测试，每条边代表一个测试结果，叶结点（leaf）代表某个类（class）或者类的分布（class distribution），最上面的结点是根结点。判定树提供了一种展示类似在什么条件下会得到什么值这类规则的方法。

最佳判定树的寻找是一个NP困难问题，经典的算法有ID3算法，即决策树归纳（Induction of Decision Tree）

程序设计语言(PDL、伪码)

是一种用来进行详细设计的语言类工具，又称为结构化语言或伪代码.

特点：

    PDL采用关键字的固定语法，提供了结构化控制结构、数据说明和模块化的特点
    PDL程序中会有一些能够标明程序结构的关键字
    PDL语言仅有少量的简单语法规则，大量使用人们习惯的自然语言
    使用PDL语言常常按逐步细化的方式写出程序
    PDL程序的注释行对语句进行解释，起到提高可读性的作用

状态图

状态

每个状态描述中除了状态名字以外，还可以包含以下三个预定义的事件的描述:

    Entry：给出当刚进入该状态时应该进行的动作（action）。在这里可以表示一个简单的赋值操作，也可以是对一个或多个方法的调用
    Do：给出在保持该状态的过程中，对象应执行的活动。这个部分一般对那些受时间控制行为的对象比较适用，因为它们通常要求能够持续的读取信息
    Exit：这个部分描述当离开该状态时应进行的动作
    这三个部分的内容是可选的，根据需要进行取舍。

状态转换

状态通过状态转换进行过渡（Transition）

事件部分：转换的主要内容，状态图主要是对被动系统的行为描述，对外界的刺激事件进行相应的响应。条件部分：状态间的转换只有在事件被触发并且满足某个特定条件的情况下才会进行，可选动作：表示当转换发生时执行的一个动作，该动作执行的时机是在转换对应的目标状态的entry事件被执行之前，即还未进入到目标状态前

扩展（复合状态）

状态图中若干状态在同一事件作用下具有相同的行为，比如对于异常的处理或者运行的停止状态可以以一种层次化的方法进行组织，每个状态通过多个子状态细化，该状态称为复合状态复合状态中的所有子状态只需一个转换来描述共同行为，节省了转换的个数，同时使得图形的绘制保持整洁，不会过于杂乱无章

并行状态

如果一个事件在两个子状态图中都需要进行处理，为两个子状态图建立一个到各自结果状态的转换。

从含有并行组合的状态出发的转换表示只有当其含有的所有子状态图都位于结束状态时，该转换才会被触发。

如果某个复合状态中的一个子状态图的分支导致离开了此复合状态，则所有的子状态图都将结束。也就是说如果离开其中的一个子状态，其它所有的都将自动结束

对象约束语言(OCL,课上没讲但ppt里有，所以我也不知道哪里重要，遂把ppt都截下来了，请选择性观看)

第8章设计优化(重点)

“小即是美”体现出设计思想的灵活性、完整性与轻量性，是优化的基础追求高内聚，低耦合

设计缺陷

僵化性：隐藏的设计关联性导致对文档或代码进行小的修正却埋下了不可预期的隐患，这将导致系统的改动困难重重脆弱性：在进行一个改动时，可能会导致程序许多没有概念关联的地方出现问题顽固性：分离设计中包含的有价值的部分并进行重用的付出和风险是巨大的粘滞性：在添加新功能时只是在现有代码的基础上拼凑代码，不愿意也不敢去触碰现有代码，不对代码重构，导致原有设计的破坏和退化

不必要的复杂性：设计人员预测需求的变化，为过多的可能性做准备，致使设计含有了绝不会用到的内容，无法带来回报不必要的重复性：设计中含有重复的内容，而这些重复的内容本可以使用单一的抽象进行统一，导致修改无法保持一致。复制和粘贴的编码习惯是导致大量重复代码的主要根源晦涩性：模块难以阅读和理解，代码随着时间而演化，变得越来越晦涩，逐渐丧失清晰性和表达力

设计的优化

运行时的多态

运行时的多态：多态性在结构上形成类的继承层次

重写（Override）的要求：

    重写的方法本质上与父类方法具有相似的行为，但在细节上进行了有针对性的调整
    重写的方法与原方法在相同的条件作用下工作，子类的方法不应具有比其父类更严格的条件限制
    重写的方法最高不能超出父类方法的状态

耦合的消息链

耦合的消息链：交互集中的设计与交互分散的设计

分散交互设计的好处是每个类只需了解与其本身相关的子任务，避免了不得不去了解其他所有类的情况，分散的交互方式使得模块的组织简单化

设计的基本原则

接口隔离原则(ISP)

应尽量使用“接口继承” ，而非“实现继承”。接口关注对象的概貌，将对象中“不变”的信息抽象出来，不涉及细节，因此是“稳定”的。通过接口只将需要的操作“暴露”给客户类，而将不需要的操作隐藏起来。接口在这里充当类的视图

这是一种松散的耦合，同时增加了重用的可能性

开放封闭原则(OCP)

一个模块对扩展应是开放的，而对修改应是封闭的是面向对象思想的最高境界，即设计者应给出对于需求变化进行扩展的模块，而永远不需要改写已经实现的内部代码或逻辑

两个基本的特点：–模块的行为可以被扩展，以需要满足新的需求。 –模块的源代码是不允许进行改动的

OCP是相对的，没有绝对符合OCP的设计，而且一个软件系统的所有模块不可能都满足OCP，要做的是尽量最小化不满足OCP的模块数量

合成/聚合复用原则(CARP)

合成与聚合是两种特殊的关联关系，是以委托方式实现对象间功能的重用(另外一种面向对象特有的重用方式是继承) 委托重用与继承重用是两种本质上不同的重用方式，委托重用追求的是对象间的独立性即低耦合，而继承重用追求的是对象间应能尽可能的高内聚。合成/聚合复用原则指的是应尽量使用合成/聚合形式的委托重用，尽量不使用继承重用

模式

根据处理问题的粒度不同，从高到低，模式分为3个层次：架构模式（Architectural Pattern）、设计模式（Design Pattern）和实现模式（Implementation Pattern）

架构模式

是模式中的最高层次，描述软件系统里的基本的结构组织或纲要，通常提供一组事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。比如N-层架构、MVC架构模式等

设计模式

一个架构模式常常可以分解成很多个设计模式的联合使用。设计模式是模式中的第二层次，用来处理程序设计中反复出现的问题，比如GOF总结的23个基本设计模式——Factory Pattern，Observer Pattern等等

实现模式

是最低也是最具体的层次，处理具体到编程语言的问题。比如，类名、变量名、函数名的命名规则以及异常处理的规则等

设计模式（重点,可能）

抽象工厂模式(Abstract Factory)

https://blog.shusheng007.top/archives/abstract-factory-pattern

实现了客户类在创建产品类时引入的耦合，如在对具体对象创建时使用的new操作，需要指定一个具体的产品类的名字，这样就在客户类和具体产品类之间引入了依赖关系，而这种依赖关系按照面向接口编程等原则是应该进行优化处理的

将产品的创建过程从客户类中分离，通过使用一个类似系统服务的工厂类来解决这个问题，工厂类提供了一个创建一系列相关或相互依赖对象的接口，而客户类无需指定它们需要的具体产品类

另一个例子：

单例模式(Singleton)

https://blog.shusheng007.top/archives/singleton-pattern

保证了一个类仅有一个实例，并提供一个访问它的全局访问点。单例模式要求：(1) 类的所有构造方法都为私有的，防止其被外部创建；(2) 提供一个公有的方法获取该类的实例；(3) 类中的实例变量(无static修饰，称为实例变量)为私有或受保护的

适配器模式(Adapter)

https://blog.shusheng007.top/archives/adapter-pattern

把一个类的接口变换成客户类所期待的另一种接口，从而使原本因接口原因不匹配而无法一起工作的两个类能够一起工作

一般有两种工作方式:：一种是通过委托的方式，另外一种是通过继承（接口实现）的方式

适配器充当被适配对象参与与客户类的交互并可以对基本的适配功能做进一步的扩展

桥模式(Bridge)

https://blog.shusheng007.top/archives/bridge-pattern

将抽象部分与它的实现部分(行为)进行分离，使它们都可以独立地变化

装饰模式(Decorator)

https://blog.shusheng007.top/archives/decorator-pattern

对客户端透明的方式扩展对象的功能，是继承关系的一个替代方案，提供比继承更多的灵活性既有继承又存在组合，实际上是将Bridge中的抽象和实现合二为一了，是其特殊形式

门面模式(Facade)

https://blog.shusheng007.top/archives/facade-pattern

要求外部与一个子系统的通信必须通过一个统一的门面对象进行提供了一个高层次的接口，使得子系统更易于使用，每个子系统一般只要求具有一个门面类，而且此门面类只有一个实例，也就是说它是一个单例模式

这个时候的门面类作用相当于前面介绍的适配器，负责对外部请求的转发，并且可以在此基础上进行功能的扩充，如对传递进来的参数的验证等。整个系统可以有多个门面类

代理模式(Proxy)

https://blog.shusheng007.top/archives/proxy-pattern

用来对有价值（稀缺）资源的管理，比如数据库的连接等，目的就是为了提高这些资源的利用率或者系统性能给这些资源对象提供一个代理对象，并由代理对象控制对资源对象的使用，起到中介的作用代理对象的存在使得客户类分辨不出代理对象与真实的资源对象

观察者模式(Observer)

https://blog.shusheng007.top/archives/observer-pattern

定义了一种一对多的依赖关系，让多个观察者对象同时监听某一个主题对象当这个主题对象在状态上发生变化时，会通知所有观察者对象，使它们能够自动更新自己

策略模式(Strategy)

https://blog.shusheng007.top/archives/strategy-pattern

针对一组算法，将每一个算法封装到具有共同接口的独立的类中，从而使得它们可以相互替换使得算法可以在不影响到客户端的情况下发生变化，而且将算法的行为和环境分开，环境类负责维持和查询行为类，各种算法在具体的策略类中提供

状态模式(State)

https://blog.shusheng007.top/archives/state-pattern

是策略模式的一种应用，状态模式允许一个对象在其内部状态改变的时候改变行为把所研究的对象的行为包装在不同的状态对象里，每一个状态对象都属于一个抽象状态类的一个子类让一个对象在其内部状态改变的时候，其行为也随之改变需要对每一个系统可能取得的状态创建一个状态类的子类.当系统的状态变化时，系统便改变所选的子类，从而对类在不同状态下的行为进行管理

组合模式（Composite）

https://blog.shusheng007.top/archives/composite-pattern

合成模式把部分与整体的关系用树结构进行表示，使用户对单对象和组合对象的使用具有一致性。

文件系统就是一个典型的合成模式系统。文件系统是一个树结构,树的节点有两种一种是树枝节点，即目录，有内部树结构;另一种是文件，即树叶节点，没有内部树结构。

第9章实现技术

XML

XML的处理方式一般有两种：文档对象模型（DOM）或用于XML的简单API（SAX） DOM:复杂对象处理的首选，比如当XML比较复杂的时候，或者当需要随机处理文档中数据的时候 SAX：以流的方式从文档的开始通过每一节点进行移动，以定位一个特定的节点

轮子（库函数）

对于大多数经常出现的问题，可以将常见的解决方法通过库函数的形式提取出来作为一种公共的资源共享

组件

可以理解为一种特殊的对象，组件是对数据和方法的简单封装是对类库思想的进一步提升，不是仅提供单一类的功能，而是将某个子应用封装提供使用

框架

框架是一个不涉及到业务处理的具有普遍性的半成品系统

框架提供一个通用平台，通过接口或者类继承的方式嵌入业务类，从而达到系统定制的目的程序员只需对它进行必要的参数定制就能够将其打造成符合用户需求的真实系统组件与框架最主要的差别就是控制权在框架中要进行转移，也就是说框架中的类会去调用那些由用户补充实现的对象中的方法，而不会反过来，但这在组件中是会发生的——反射

数据持久化

物理文件

直接使用文件的方式进行数据的持久化好处是可读性比较好，可以方便的通过手工编辑或者其它的程序进行读取问题是开发者必须要为每个需要持久化的类编写存储或读入的方法，这是一项很繁琐的工作

数据库

大数据量的存储一般情况下都要借助数据库系统来进行

关系型数据库较为明显的缺点是业务存储的模型需要事先在数据库端设计和构建，在数据持久层需要在应用中进行一些程序设计工作以及对象数据与关系型（表格数据）的兼容性处理等

使用单独的功能软件实现对应用中存在的对象与数据库存储过程的自动化管理，即所谓的对象关系映射

完成高效管理业务实体类与其持久化形式间的转换，包括事务管理，使开发者专心业务功能开发

领域特定语言（DSL）

为不同的领域补充进特定的不依赖具体编程语言的抽象指令，或者说针对某一特定领域具有受限表达性的一种计算机程序设计语言核心价值在于更加清晰地就系统某部分的意图进行表达和沟通提供了一种清晰而准确的概念性的语言，可以有效地改善这种沟通

基本思想是提供一种正式的解决方案，与具体编程语言甚至是架构无关的分为四个阶段： CIM（Computation Independent Model）：聚焦于系统环境及需求，但不涉及系统内部的结构与运作细节 PIM（Platform Independent Model）：聚焦于系统内部细节，但不涉及实现系统的具体平台 PSM（Platform Specific Model）：聚焦于系统落实于特定具体平台的细节，如EJB，J2EE或.NET都是一种具体平台 Coding：最后程序员依据PSM的UML模型内容，按图施工，编写出适用于特定具体平台的代码

重构

重构允许在程序首次构造后对其结构进行改造，使其能够按照希望的形式进行构造重构后代码的可读性和可重用性更强，其思想可同样扩展到对类的再造（reconstruction）和改造（outsourcing）上

第11章软件测试（重点：黑白盒测试）

一些杂七杂八的概念

软件测试：使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别

测试用例(Test Case)：为某个特殊的测试目标而编制的一组测试输入、执行条件及预期结果，以便测试某个程序路径或核实软件是否满足某个特定需求

测试分类和测试V模型

软件度量（重点：McCabe指标与程序控制流图）

度量是确定软件质量的一种有价值的辅助手段

程序控制流图（重点）

McCabe指标(重点)

LCOM*指标(作业题里没见过，不重要)

等价类测试（是黑盒测试，重点：等价类的划分）

基本等价类测试

对于数值型的集合，可根据输入变量的取值范围，产生一个有效等价类和两个无效等价类对于枚举类型，假设合理的取值包括red、yellow和blue，则可以简单的将这些取值分别对应一个等价类。如果不允许其它值作为输入数据，则不存在它的无效等价类

以下是一个划分等价类的例子：

应用边界值分析

强/弱等价类

将3个变量具有的等价类分别进行组合，就会产生2 * 3 * 3=18个测试用例，这将涵盖所有可能的输入情况，把这种组合方式称为强等价类方法

弱等价类要求满足每个变量的各种等价类被覆盖，对于上边的例子来说，弱等价类只需将E1-E8全部包含即可

面向对象中的等价类

基于控制流的测试(是白盒测试，重点：各种覆盖指标)

覆盖指标

程序覆盖是提供一组测试用例尽可能使得覆盖率指标越大越好，或者说越接近1越好

覆盖率指标有很多计算标准，其中较基础的有语句覆盖(Statement Coverage)、分支覆盖(BranchCoverage)、条件覆盖(Condition Coverage)、多条件组合覆盖(Multiple Condition Coverage)及路径覆盖(Path Coverage)等

语句覆盖

语句覆盖表示在程序控制流图中测试经过的节点数与所有节点数的比例： $\frac{控制流图中测试经过的节点数}{所有节点数}$

上图对应的语句覆盖率分为别 $\frac{5}{6} \frac{2}{3} 1 \frac{5}{6}$

分支覆盖

分支覆盖的目标是尽可能覆盖控制流图中所有的边: $\frac{控制流图中测试经过的边数}{所有的边数}$

条件覆盖

条件覆盖：要求每个原子谓词的真假两种取值都要取到条件覆盖不是根据程序的运行情况，而是根据出现的布尔条件进行测试用例的设计，条件覆盖与分支覆盖并没有直接的关系条件覆盖: $\frac{取值为真的原子谓词+取值为假的原子谓词}{2*所有的原子谓词数}$

条件覆盖与分支覆盖没有任何特别的联系，这表示分支的完全覆盖不能保证条件的完全覆盖，反之也成立，即完全的条件覆盖也不能保证分支的完全覆盖

多条件组合覆盖(注意与条件覆盖的区分)

所有的覆盖要求在多条件组合覆盖标准中得到了综合，它要求所有在条件中出现的原子谓词的组合都要覆盖到多条件组合覆盖： $\frac{取值为真的原子谓词数+取值为假的原子谓词数}{2*所有的原子谓词数}$

路径覆盖

路径覆盖(Path Coverage)是度量一个方法中所有可能路径的覆盖情况

路径：从方法的入口开始到出口结束，由控制流图中若干条边构成的一条唯一的执行路线，也可以看成由若干可能的逻辑条件的组合

基本路径测试（注意独立路径条数）

基本路径测试是路径覆盖的典型方法，它是在控制流图的基础上，通过分析控制结构的环环复杂度，导出基本可执行的路径集合，从而设计测试用例的方法

断言

可测试性构建的原则(感觉不重要,不看)

设计简单的方法

避免私有方法

优先使用通用方法

组合优于继承

避免隐藏的依赖关系与全局状态

建设性质量保证（感觉不重要,不看）

人工测试（感觉不重要,不看）

第12章软件项目级管理(重点：工程网络图，挣值分析模型)

软件配置管理(个人感觉不重要)

软件配置管理（Software Configuration Management，SCM）是一种标识、组织和控制修改的技术，贯穿于整个软件生命周期。

版本管理

核心工作是对项目软件或者项目文档的管理一方面要规范化不同开发人员之间的合作方式，必须能够保证一个人的工作不会被其它人意外的覆盖；另一方面是要确保每个人工作的对象是当前需要的版本而且能够为后续开发提供基础

版本系统对于冲突问题的解决通常存在两种方法：第一种方法被称为是悲观的方法：第一个检出文件的人将会拥有对该文件的排它锁第二种是乐观的方法：开发人员可同时对文件进行编辑，但涉及如何合并修改和冲突的解决

构建管理

主要任务是描述最终软件产品的结构和生成过程

发布管理

主要作用是协调在合适的时间对合适的用户交付合适产品的保证发布管理是对项目管理的一个有效补充

变更管理

项目计划(重点：工程网络图)

项目管理主要关注组织和管理层面的内容项目计划实际上是一个对项目规模、工作量、成本、进度等方面的估算，同时将人员、时间、计算机资源等各类资源统筹安排，对项目的成功起到非常重要的作用

工作分解WBS

软件规模估算

软件规模的估算可以基于分解的方法，项目可以按照WBS的方式分解为子项目

开发成本估算

CoCoMo（Constructive Cost Model）

管理方面的成本

任务安排与工程网络图(重点)

正推确定最早时间，逆推确定最晚时间

项目组织与甘特图(甘特图可能有选择，仔细看一下)

项目计划常使用甘特图（Gantt chart）图对计划进行描述，包括工作包、依赖、责任人、完成比例等实心菱形标识出里程碑的位置，表示在此位置可以对现有进度进行评审，并可根据需要对计划进行较大调整甚至终止项目内部里程碑，开发单位内部进行的进度评审外部里程碑，客户在此了解当前项目的进展并对产品进行部分的验收

项目计划跟踪（重点：挣值分析模型）

挣值分析模型（重点）

挣值分析（Earned Value）是对项目实施的进度、成本状态进行绩效评估的有效方法，是计算实际花在一个项目上的工作量成本，以及预计该项目所需成本和完成该项目的日期的一种方法。挣值的概念，即到目前为止项目实际完成的价值

参数定义

BCWS（Budgeted Cost of Work Scheduled）计划完成工作的预算成本:是到目前为止的总预算成本表示“到目前为止原来计划成本是多少”或者说“到该日期为止本应该完成的工作是多少” ACWP（Actual Cost of Work Performed）已完成工作的实际成本:是到目前为止所完成工作的实际成本，它说明了“到该日期为止实际花了多少钱” BCWP（Budgeted Cost of Work Performed）已完成工作的顶算成本，又称挣值:是到目前为止己经完成的工作的原来预算成本，它表示了“到该日期为止完成了多少工作?” BAC（Budgeted At Completion）工作完成的预算成本:是项目计划中的成本估算结果，是项目完成的预计总成本

进度偏差SV（Schedule Variance）= BCWP-BCWS，若此值为零，表示按照进度进行；如果为负值，表示项目进度落后；如果为正值，表示进度超前成本偏差CV（Cost Variance）=BCWP-ACWP，若此值为零，表示按照预算成本进行;如果为负值，表示项目超出预算成本；如果为正值，表示低于预算成本进度执行指标SPI（Schedule Performance Index）= BCWP/BCWS，指项目挣值与计划值之比。当SPI>1时，表示进度超前；当SPI=1时，表示实际进度与计划进度相同；当SPI<1时，表示进度延误成本执行指标CPI（Cost Performance Index）= BCWP/ACWP，项目挣值与实际费用之比。当CPI>1时，表示低于预算，即实际费用低于预算费用；当CPI=1时，表示实际费用与预算费用吻合；当CPI<1时，表示超出预算，即实际费用高于预算费用