1.软件工程目标：正确性、可用性、适合销售活动：需求、设计、实现、V&V(验证与确认)、支持原则：开发泛型、设计方法、支持工具、工程管理WW软件工程是开发，运行，维护和修复软件的系统方法，将系统化的，规范的，可度量的方法应用与软件的开发，运行维护的过程。

即将工程化应用于软件中。

2.软件过程中的基本活动（pdca）1.软件规格说明plan2.软件开发do3.软件确认check4.软件演进action3.瀑布模型：需求-》系统设计-》实现单元测试-》集成与系统测试-》运营维护。

他的显著特点是顺序性和依赖性。

4.演化模型：软件通过不断的演化才能完成和完善，其显著特点是迭代。

适合于业务和需求不断变更的开发过程，交付部分功能给客户，确认需求，逐步完善。

5.螺旋模型：将瀑布模型和演化模型结合起来，加入了风险分析。

6.增量模型：是将软件分解成一系列的增量的构件，在增量开发迭代中逐步加入，也叫极限程序设计。

7.软件工程原则：a)抽象自顶向下，逐层细化b)模块化的开发方法c)信息隐蔽和数据封装。

d)局部化e)一致性f)完备性g)可验证性8.软件工程基本原理：a)按软件生存期分阶段制定计划并认真实施b)坚持进行阶段评审c)坚持严格的产品控制d)使用现代程序设计技术e)明确责任f)用人少而精g)不断改进开发的过程9.识别用户要求，必须考虑的问题：a)功能和性能b)可靠性和质量c)总的系统目标d)成本与进度的把控e)制造需求f)市场竞争情况g)有效的技术h)将来可能的扩展10.可行性研究a)问题识别b)市场调查c)分析准备d)环境分析e)物理分析f)功能分析g)信息分析h)动态分析i)确立系统方案和成本估算j)模型评审k)成本可行性l)法律可行性11.面向对象设计面向对象=对象+分类+继承+消息通信，基本组成部分叫对象，计算是通过新对象的确立和对象之间的通信来执行。

相对于面向过程开发，核心：数据被封装在对象中，而不是全局变量中，数据流是通过消息传递，而不是面向过程解决办法。

算法被包裹在对象中，实现功能。

12.统一建模语言：UML概述Unified Modeling Language的缩写，他聚集了建模的精髓。

数据建模（实体关系图ERD）业务建模（工作流）对象建模构件建模13.UML图用例图：描述系统边界和主要功能；主要该系统在它的上下文环境所提供的服务。

1）上下文环境建模：主要指在位于系统之外并与系统进行交互的参与者以及他们扮演的角色的含义。

2）功能需求建模：说明系统想要的行为。

交互图（时序图，协作图）：描述用例的实现，其主要描述了系统的外部视图，如何通过对象之间的交互实现用例。

包括顺序图和协作图，顺序图也叫时序图或序列图，他是按照时间顺序来的。

类图：标示系统的静态机构类图从系统的逻辑视图展现了一组类、接口、协作和它们之间的关系，类图给出系统的静态设计视图，主动类的类图给出了系统的静态进程视图。

其主要包括1）类及其结构和行为2）接口3）协作4）关联、依赖、泛化关系5）多重性和导航指示符6）角色名字类图的关系：父子关系实现关系关联关系（单向关联有箭头，多项无箭头）聚合：整体和部分关系组合关系（也是整体与部分，但是部分离开整体无法存活）依赖关系（动物无法离开氧气，为依赖关系）整体类图状态图：模型化对象的行为泳道图泳道图构件图和部署图：展现物理实现的体系结构衍型：扩展建模能力14.软件需求：a)为满足用户解决某一问题而达到某个目标所需要的条件或者能力，系统或系统部件为满足合同、规格、标准说明或其他正式的强制性文档所必须具有的条件和能力。

为满足以上条件和能力的文档化说明b)软件需求包括：业务需求、用户需求、功能需求、非功能性需求。

c)业务需求：描述了组织愿景，即为什么要开发一个系统；系统的业务范围、业务对象、客户特性、价值和各种特性的优先级别。

d)用户需求：描述了系统必须完成任务，即用户对系统的目标要求。

它只涉及到外部可见行为，不涉及内部特性。

是用户对自身需求的一种陈述。

这种陈述可能与实际需求不一致。

e)功能需求：定义了开发者应该提供的软件功能或服务，但不涉及这些功能和服务的实现。

f)非功能需求：对功能需求的补充，包括了对系统的各种限制和用户对系统的质量的要求。

如系统响应时间或截面。

i.包括产品必须遵从的标准、规范和合约ii.外部接口的具体细节iii.性能要求iv.设计实现的约束条件15.需求获取的过程需求获取包括以下活动：（a）发现和分析问题（b）获取需求（c）需求归档需求获取的主要步骤（a）理解业务领域，即目标软件的业务环境，如银行、电信，了解后可以建立自对业务理解后的数据模型。

通过结合实际业务，迭代完善业务模型（b）定义项目的视图和范围，定义项目范围是描述项目该做什么，不该做什么一般使用用例图。

（c）寻找软件的需求来源，客户、竞品、系统需求规格说明书、当前系统的问题报告和改进要求、市场调研报告、观察用户如何工作、用户工作场景分析、事件和响应。

（d）识别用户类和用户代表，确定系统的用户及其分类，与用户一块工作，确定系统的决策者。

（e）确定系统的业务流程和业务规则（f）访谈和记录（g）需求整理和描述16.面向对象的UML需求获取方法：a)用户模型视图：从用户角度来标示系统，通过用例图来标示b)结构模型视图：通过静态的数据模型图，类图、对象图来建模c)行为模型视图：描述系统的动态和行为，以及在上述两种视图中的各元素如何交互。

d)实现模型视图e)环境模型视图面向对象模型，分为三个独立模型a)有用例和场景组成功能视图b)用类和对象标示的分析对象模型c)用状态图和顺序图标示的动态模型17.对需求文档的要求：1）完整：要求必要的需求信息，必须进行完整的描述2）无歧义：每种需求只有一种解释。

3）一致性：对需求规格说明，必须保持一致。

4）可验证：可演示、测试、分析、审查、特殊的检查5）可修改6）可追踪：向前和向后的追踪性。

18.软件需求评审的主要内容：a)用例：是否清晰，用例规格。

b)功能：是否清楚，是否必须，是否满足，是否覆盖异常c)性能：是否精确描述，是否制定指标，是否制定使用环境d)接口：外部、内部描述是否清晰。

调用关系。

e)数据：是否确定系统的输入、输出f)硬件g)软件h)通信i)正确性完整性一致性，兼容性，安全性清晰性，健壮性，可扩展性。

19.需求管理：a)需求变更：建议变更---分析影响---作出决策---交流---合并b)版本控制：确定需求文档版本c)需求跟踪：d)需求状态跟踪20.需求变更的控制策略：a)需求变更原因：内部原因，外部原因i.内部原因：需求获取的不确切，需要发生变更，以适应真正的客户需求ii.外部原因：客户需求与之前发生了变化，如：客户的组织结构和工作流程发生了变化。

b)需求变更的策略i.认识到变更不可避免的时候，为变更指定计划ii.重新确定需求的基线iii.指定变更的唯一渠道，防止因为变更导致的需求扩散。

iv.指定合理的需求变更管理过程：如必须经过变更管理委员会确定的变更，才能真正进入需求文档，而不是开发人员擅自做主变更需求。

21.软件设计a)传统结构化软件设计：数据设计，体系结构设计，接口设计，过程设计。

b)面向对象的软件设计：体系结构设计、类设计、接口设计、构件设计i.体系结构设计：软件的主要结构元素其之间的关系ii.类设计：转化为设计类的实现及软件实现所要求的数据结构iii.数据设计：主要是关系数据库中的E-R实体关系图iv.构件级设计：构件级设计22.软件设计原则：a)设计应遵循：过程抽象，数据抽象。

b)过程应遵循模块化的原则i.模块可分解ii.模块可组装iii.模块可被理解iv.模块连续性v.模块保护c)应遵循信息屏蔽的原则d)模块独立性：高内聚，低耦合。

e)模块设计原则：先把该模块下的所有下层模块看成黑盒23.极限编程a)极限编程是一种原型设计方法，是基于实践的设计方法。

b)极限编程的原则：交流、简单、反馈、勇气。

i.交流：鼓励开发人员与客户直接沟通，用沟通代替文档。

ii.XP不建议过分构建系统设计，反对杞人忧天的做法。

简单最好，实现为前提。

iii.反馈要迅速，反馈越快越好，进行结对编程，测试优先，现场客户。

iv.拥抱变化，不变是变化，要有坚持XP设计的勇气，同时有放弃勇气。

c)XP的重要方法：i.放弃包袱，轻装上阵。

ii.结对编程iii.测试优先，以测试用例为驱动，单元测试。

iv.重构v.持续集成vi.小版本vii.现场客户24.软件体系结构软件体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个子模块和子系统有效的组织起来，组织成一个完整的系统。

25.常见的风格：管道过滤器风格：26.面向对象的设计风格27.层次结构的风格（每一层定义一个抽相机，为上一层提供服务，并作为下一次层的客户）28.数据仓库风格（共享系统单元，所有人可以访问这些数据，此系统常见于专家系统中）专家黑板系统29.设计模式：设计模式分为三类：1）创建型模式：与对象的创建有关2）结构型模式：处理类与对象的组合，将一组对象组合成一个大的结构3）行为型模式：描述类与对象交互和职责分配。

按照使用范围，又分为对象和类两种类型其中23中设计模式，主要创建型：描述怎么创建一个对象，他隐藏对象创建的具体细节，实用程序可不依赖具体的对象，因此当增加一个新对象时几乎不需要修改代码。

其隐藏了这些类的实例如何创建、如何放在一起。

创建型类模式有：工厂模式创建型对象模式有：抽象工厂，构造模式，原型模式，单例模式重点1：抽象工厂模式：以同一接口建立一整组相关或相互依赖的对象，而不用指明个对象真正所属的具体类。

抽象工厂的特点：1.封装性：都是接口，不关心细节。

只需知道工厂类即可，就能创建出一个对象，省时省力。

2.约束性：产品约束在产品内部，外部不需要关心。

缺点：1.扩展性困难，增加一个新产品，需要抽象类，抽象类实现工厂都要修改，改动太大。

抽象工厂是一种契约关系，一种契约修改，所有的代码都要修改。

使用场景：1.使用对象组，这类对象有相同约束，如：文本编辑器，在Linux下的和Windows下的因为底层API不同，代码实现不同。

但是功能是相同的，有共同的约束条件，可以用抽象工厂，还有DB的操作，不同数据库的实例化。

2.一个模式在什么情况下才能够使用，是很多读者比较困惑的地方，抽象工厂模式是一个简单的模式，使用的场景非常多，大家在软件产品开发过程中，涉及到不同操作系统的时候，都可以考虑使用抽象工厂模式，例如一个应用，需要在三个不同平台上运行：Windows、Linux、Android（Google 发布的智能终端操作系统）上运行，你会怎么设计？分别设计三套不同的应用？非也非也，通过抽象工厂模式屏蔽掉操作系统对应用的影响。