软件的定义（R.S.Pressman）：
软件是能够完成预定功能和性能的可执行的计算机程序，包括使程序正常执行所需要的数据，以及有关描述程序操作和使用的文档，
软件 = 程序（包括数据） + 文档
程序是为了解决某个特定问题而用程序设计语言描述的适合计算机处理的语句序列。
数据是使程序能正常操纵信息的数据结构。
文档是与程序开发，维护和使用有关的图文材料。
软件具有不同的特征
1.软件开发不同于硬件设计（软件设计所耗费的精力与成本 相对于硬件而言占大头）
2.软件生产不同于硬件制造（软件在制成之后，制造只是简单的复制而已）
3.软件维护不同于硬件维修（硬件会耗损，软件不会但维护成本高）
软件是逻辑的不是物理的
软件危机
拓展了解：（随着软件复杂度的增加，大型软件的开发费用经常超出预算，完成时间也常常脱期。尤其糟糕的是，软件可靠性往往随规模的增长而下降，质量保证也越来越困难。）
软件危机的原因
客观：软件自身特点 （本质问题，难改变）
逻辑部件
规模庞大，复杂度高
主观：不正确的开发方法 （能改变）
忽视需求分析
轻视软件维护
个人化方式：软件开发=程序编写
（庞大的软件费用，加上软件质量的下降，对计算机应用的继续扩大构成了巨大的威胁。）
软件危机的原因
1.软件维护费用急剧上升，直接威胁计算机应用的扩大
2.软件生产技术进步缓慢，是加剧软件危机的重要原因。（软件技术进步落后于需求的增长）
（软件工程 —— 把软件当作一种工业产品，要求“采用工程化的原理与方法对软件进行计划、开发和维护“。）
1968年，软件工程的概念首次提出。1956年，世界上第一个高级语言FORTRAN问世
按不同的思路和方法来编写程序，就形成不同的编程范型。
1.过程式编程范型 程序 = 数据结构 + 算法
面向过程编码语言（POPL procedure-oriented programming language）
2.面向对象编程范型 程序 = 对象 + 消息
面向对象程序设计（OOP object-oriented programming）
3.基于构件技术的编程范型 构件（component）
基于构件的开发技术（CBD component-based development）
在整个软件开发过程中，通常包括需求分析、软件设计、程序编码、软件测试等多个阶段
软件工程的分代
1.传统软件工程或经典软件工程 (以结构化程序设计为基础，又可区分为瀑布模型、原型模型等)
结构化分析——结构化设计——面向过程的编码——软件测试
2.面向对象软件工程 （以面向对象程序设计为基础）
OO分析与对象抽取——对象详细设计——面向对象的编码与测试
3.基于构件的软件工程 （以软件复用为目标，领域工程为基础）
领域分析和测试计划定制——领域设计——建立可复用构件库——按“构件集成模型“查找与集成构件
根据程序代码行数规模的多少，程序有极小、小、中、大、甚大、极大等分类
形式化方法与非形式化方法的关系
形式化方法：是一种基于数学的开发技术，主要采用数学的方法来描述系统的性质，例如程序变换和程序验证等。 （实现难度大，进度十分缓慢，数学要求高）
非形式化方法（也称作欠形式化方法）：主要运用文本、图、表与符号来描述系统的模型，如结构化设计、面向对象设计和UML语言等
软件生存周期（Software Life Cycle）
一个软件项目从问题提出开始，直到软件产品最终退役（废弃不用）为止。
软件生存周期分为三个时期：计划、开发和运行。
整个软件生存周期划分为多个相对独立的较小阶段，给每个阶段赋予确定而有限的任务，从而降低了整个软件工程的难度，提高了软件开发生产率。
需求分析：主要弄清用户需要用计算机来解决什么问题，从用户的视角进行分析，具体包括软件的功能需求、性能需求、环境约束和外部接口描述等。
软件分析：从开发人员的视角进行分析
软件设计：将设计任务具体化，还需要编写相应的设计文档
编码：编写代码
软件测试：多层次进行测试
运行维护：运行维护阶段的任务主要是做好软件维护。
软件过程
围绕软件开发所进行的一系列活动
软件过程模型
把软件生存周期中软件开发活动的有序流程用一个合理的框架来规范描述。
软件过程模型是一种软件过程的抽象表示法，它从一个特定的角度表现一个开发过程。
软件生存周期中的阶段和软件过程中的活动是基本一致的。
传统的软件过程
瀑布模型（waterfall model）
一种基于软件生存周期的线性开发模型。
由W.Royce在1970年首次提出
具有特性：
- 阶段间的顺序性和依赖性
顺序性：只有等前一阶段的工作完成之后，后一阶段的工作才能开始
依赖性：前一阶段的输出文档是后一阶段的输入文档。
- 推迟实现的观点
把待开发软件的逻辑设计与物理实现清楚地区别开来。
- 保证质量的观点
- 每一阶段必须完成规定的文档；
- 每一阶段都要对完成的文档进行复审，以便尽早发现问题，消除隐患。
- 存在的问题
很难在开发的初始阶段彻底弄清软件需求。
快速原型模型（rapid prototype model）
基于原型的迭代化开发模型。
中心思想：先建立一个能够反应用户主要需求的模型，然后将原型反复改进
原型模型只包括未来系统的主要功能及系统的重要接口。
启示：原型开发模型使人们认识到：生存周期只指出了整个周期中应包含哪些活动，并未规定这些活动应该发生多少次。所以软件开发人员的任务，就是通过对软件过程的重新安排，使之更适合于待开发的软件系统。
软件演化模型（迭代化开发模型）
增量模型
是瀑布模型的顺序特征与快速原型法的迭代特征相结合的产物。
这种模型把软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。
在一般情况下，第一个增量通常是软件的核心部分。
螺旋模型
为目前软件开发中最常用的一种软件开发模型，尤其适用于大型软件的开发。
每轮螺旋均包含计划、风险分析、建立原型、用户评审四种活动。
其中，风险分析是螺旋模型最经典的特性。
特点：螺旋模型的特点，是在项目的所有阶段都考虑各类风险。过多的迭代周期，也会增加开发成本和时间，螺旋模型开发的成败，在很大程度上依赖于风险评估的准确性。
构件集成模型
面向对象的方法：
面向对象 = 对象 + 分类（classification） + 继承 + 消息通信。
构件（component）
在某个领域内具有通用性，可以复用的软件部件。
将可以复用的构件存储起来，形成构件库。
特点：面向对象 基于构件库
融合螺旋模型特征 支持软件开发的迭代 软件复用
转换模型
净室模型 （形式化的增量开发模型）
统一过程 RUP(Rational Unified Process)
由原Rational公司开发，现为IBM公司的一个产品。
统一过程描述了软件开发中各个环节应该做什么、怎么做、什么时候做以及为什么要做，描述了一组以某种顺序完成的活动。
其结果是一组有关系统的文档。
统一过程包括四个阶段，分别是 初始阶段、细化阶段、构造阶段和迁移阶段。
初始阶段（先启） 定义整个项目的范围
- 对需求有一个大概的了解，确定系统中的大多数角色和用例。此时用例是简要的
- 划分主要子系统，给出系统的体系结构概貌。
- 分析项目执行的风险。
- 考虑时间、经费、技术、项目规模和效益等因素。
- 制定开发计划。
细化阶段（精化） 指定项目计划、描述功能、建立体系架构框架。
- 进行需求风险分析。考虑项目的目标是否偏离了用户的需求。充分了解用户需求以及各需求的优先级。
- 进行技术风险分析。（建立原型）
- 进行技能风险分析。（人员素质）
- 进行政策风险分析。
- 进行高层分析和设计，并作出结构性决策
- 产生简要体系结构，包括用例列表、领域概念模型和技术平台等。
- 为构造阶段制定计划。
构造阶段（构建） 构造软件产品
识别出剩余的用例。
各项目组可以进行并行开发。
迁移阶段（迁移） 将软件产品移交到最终用户手中。
这一阶段完成最后的软件产品和验收测试，并完成用户文档编制以及用户培训等工作。
敏捷过程 （agile development）
敏捷开发是一种以人为核心，以迭代方式循序渐进开发的方法，其软件开发的过程成为“敏捷过程”。
简言之，就是把一个大项目分为多个互相联系但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可用状态。
敏捷开发的价值观 四条 （以人为核心，软件可运行）
敏捷开发应遵循的十二条原则 （可随时改变需求，速度尽可能快，面对面交流，软件可运行，一起工作，还得简单为根本，会总结自省，依旧是以人、员工为核心） P33
敏捷开发是一个持续地应用原则、模式以及实践来改进软件的结构和可读性的过程，而不是一个事件。
极限编程（extreme programming,XP）
极限编程就是敏捷过程的一种方法。
极限编程是由Kent Beck在1996年提出的轻量级的、敏捷的软件开发方法。
它有4个价值观：交流、简单、反馈和勇气；即任何一个软件项目都可以从4个方面入手进行改善：加强交流；从简单做起；寻求反馈；勇于实事求是。
XP建议采用循环迭代的开发方法，它将复杂的开发过程分解为一个个相对比较简单的小周期。
XP方法包括以下12个核心实践 P34
其中比较重要的地方有：
5.结对编程（pair programming）
XP方法强烈推荐结对编程，即由两个程序员坐在同一台计算机前一起编程，在一个程序员开发的同时，另一个程序员负责检查程序的正确性和可读性。
10.编码标准（coding standard）
XP方法强调制定一个统一的编码标准，包括命名、注释、格式等，使系统中所有的代码看起来就好像是一个人编写的。
软件可行性研究 （重点）
可行性研究（feasibility study）的目的：
1.研究项目是否可能实现和值得进行。
2.回答 Why to do
这通常由系统分析员完成，并需写出可行性论证报告；可行性论证其实是在高层次上进行的一次大大简化了的需求分析与设计。
可行性研究的内容与步骤 （重点）
一、研究的内容
1.经济可行性。实现这个系统有没有经济效益？多长时间可以收回成本？
2.技术可行性。现有的技术能否实现这一新系统？有哪些技术难点？建议采用的技术先进程度怎样？
3.运行可行性。为新系统规定的运行方式是否可行？例如，若新系统是建立在原来已担负其他任务的计算机系统上的，就不能要求它在实时在线的状态下运行，以免与原有的任务相矛盾。
4.法律可行性。新系统的开发会不会在社会上或政治上引起侵权、破坏或其他责任问题？
二、研究的步骤
1.对当前系统进行调查和研究
弄清当前系统
导出新系统逻辑模型
2.导出新系统的解决方案
设计不同的解决方案（目的）
3.提出推荐的方案
本项目的开发价值
推荐这个方案的理由
4.编写可行性认证报告
报告主要由下面3个部分组成
系统概述
可行性分析
结论意见 （结论可区分为可立即进行、推迟进行以及不能或不值得进行这3类）
软件风险分析 P36
风险识别
项目风险
技术风险
商业风险
风险预测
风险发生的可能性
风险发生后的后果
风险的驾驭和监控
SD structured design 结构化设计
SA structured analysis 结构化分析
二者合称为结构化分析与设计方法
DFD data flow diagram 数据流图
指明系统中的数据是如何流动和变换的，以及描述使数据流进行变换的功能
PSPEC process specification 加工规格说明
SRS software requirements specification 软件需求规格说明书
SC图 structured chart 系统结构图 又称为 模块结构图
DD data dictionary 数据字典 （对软件中的每个数据规定一个定义条目）
E-R图 entidy – relation diagram 实体联系图 （描述数据对象间的关系）
STD status transform diagram 状态变换图 （实时）
用于指明系统在外部事件的作用下将如何动作，表明系统的各种状态以及状态间的变换（tranfer，或称变迁），从而构成行为模型的基础。
CSPEC control specification 控制规格说明 （软件控制方面的附加信息）
CFD control flow diagram 控制流图
结构化分析与设计是瀑布模型的首次实践。
SA与SD的流程 （重点：描述流程）
结构化分析（工具：DFD、PSPEC） → 分析模型（分层DFD图）+ SRS
结构化设计（工具：SC图） →（映射） 初始设计模型（初始SC图）
初始设计模型（初始SC图） →（优化） 最终设计模型（最终SC图）
简而言之，SA与SD的流程其实也是为待开发系统建立分析模型和设计模型的过程
基本任务与指导思想
（1）结构化分析
SA有两项基本任务，即建立系统分析模型（analysis model）和编写软件需求规格说明书（software requirements specification SRS），二者都是分析阶段必须完成的文档
1.建立分析模型。SA模型包含描述软件需求的“一组”模型，通常有功能模型、数据模型和行为模型3种模型。由于它们一般都用图形符号来表示，直观易懂，因此是形成SRS文档、完成软件设计的基础。
2.编写软件需求规格说明书。SRS是分析阶段编写的、以文字为主的文档。
SRS应该具有准确性。任何微小的错漏都可能铸成大错，在纠正时需付出巨大的代价。
SRS应该防止二义性。不要采用用户不容易理解的专门术语，以免导致误解
SRS应该直观易改。尽可能采用图形和符号。
3.主要指导思想。抽象与分解，是结构化分析的主要指导思想。
抽象的层次愈低，呈现的细节也会愈多
（2）结构化设计
1. 软件设计 = 总体设计 + 详细设计。瀑布模型的软件设计包含了总体设计和详细设计两个阶段。SD阶段把分析模型中的DFD图转化为最终SC图
2. SC图需分两步完成。首先通过“映射”获得初始SC图；然后通过“优化”获得最终SC图。
3.软件设计的指导思想。
分解和细化，历来是重要的软件设计策略。
细化的实质就是分解。
3.1.2 SA模型的组成与描述
引例：教材销售系统 P43-44 （DFD图的具体书写过程 有条件的情况看）
SA模型的组成
（1）数据流图（DFD）
组成符号。
圆框代表加工
箭头代表数据的流向 数据名称总是标在箭头的边上
方框表示数据的源点和终点。
双杠（或单杠）表示数据文件或数据库。
注：文件与加工之间用带箭头的直线连接，单向表示只读或只写，双向表示又读又写。每一图形符号都必须标上名字，加工框还应该加上编号，以帮助识别。
（2）数据字典 （DD）
数据流
条目中{}表示重复
数据文件
“组织”是数据文件条目所特有的内容，用于说明文件中的记录将按照什么规则组合成文件。
（3）加工规格说明 (PSPEC)
加工规格说明通常用结构化语言、判定表或判定树作为描述工具
SD模型的组成与描述
SD模型的组成
SD模型是由SA模型映射而来的
DD可转换为待开发系统的数据设计
DFD可转换为体系结构设计（SC图）与接口设计
PSPEC可转换为模块内部的详细过程设计
SC图的组成符号
矩形框表示模块
带箭头的连线表示模块间的调用，并在调用线的两旁标出传入和传出模块的数据流。
SC图的模块调用
结构化系统分析
结构化分析的定义（SA）
结构化分析就是使用DFD、DD、结构化语言、判定表和判定树等工具，来建立一种新的、称为结构化说明书（SRS）的目标文档
结构化分析的基本步骤（重）
1.自顶向下对系统进行功能分解，画出分层DFD图
2.由后向前定义系统的数据和加工，编制DD和PSPEC
3.最终写出SRS.
画分层DFD图
逐层对系统进行分解，直到所有的加工都足够简单为止
自顶向下，逐步细化
分层DFD图具有优点
1.便于实现；（有利于控制问题的复杂度）
2.便于使用 （使用者各取所需）
数据分析从数据的终点开始，沿着DFD图一步步向数据源点回溯
需求分析的复审
复审人员：用户和系统分析员共同进行复审，并吸收设计人员参加
复审的重点：是DFD、DD、和PSPEC等文档的完整性、易改性和易读性，尽量多地发现文档中存在的矛盾、冗余与遗漏。
结构化系统设计
软件设计目前也有两种主流方法
1、基于结构化程序设计地结构化软件设计
2、基于面向对象技术地面向对象软件设计
传统的软件设计可细分为 面向数据流设计 和 面向数据设计
数据流是考虑一切问题的出发点。
从分析模型导出设计模型 （对应关系）
DD、E-R图 数据设计
DFD 体系结构设计（SC图）
DFD 接口设计
PSPEC、CSPEC、STD 过程设计
从DFD图到SC图 （重）
结构化软件的设计，通常从DFD图到SC图的映射开始
所有系统可归结为 变换型结构 和 事务型结构 两种类型
1.变换型结构
由传入路径、变换中心、传出路径 三部分组成 “一对一“
2.事务型结构
由接受路径、事务中心、若干条动作路径组成 “一对多”
3.复合型
SD方法的步骤
1.复审DFD图
2.确定软件结构是变换型还是事务型
3.把DFD图映射为初始SC图
变换型DFD图 通过 变换映射 初始SC图
事物型DFD图 通过 事物映射 初始SC图
4.按照优化设计改进SC图，获得最终SC图
变换映射
主要步骤包括
1.划分DFD图的边界
2.建立初始SC图的框架
3.分解SC图的各个分支
事物映射
主要步骤包括
1.划分DFD图的边界，并做出标记
2.画出相应SC图的初始框架
3.重点是对动作（即发送）分支进行分解。其接受分支因一般具有变换特性，可以按变换映射对它进行分解。
每一动作路径可映射为一个事物模块
处理层 -》 事物层 -》 操作层 -》 细节层
优化初始SC图的指导规则
1.对模块划分的原则
一般来说，模块的总行数应控制在10-100行的范围内，最好为30-60行，模块位置视情况而变更
2.高扇入（fan-in）/ 低扇出 (fan-out) 的原则
扇入高则上级模块多，能够增加模块利用率
扇出低则表示下级模块少，可以减少模块调用和控制的复杂度
软件结构最好为瓮型结构，两头小、中间大，不要煎饼形和塔形
模块设计
把DFD图转换为最终SC图，仅仅完成了软件设计的第一步
传统的软件工程将软件设计分成两步走：
1.总体（或结构）设计 —— 用最终SC图表示
2.模块设计 —— 用逐步细化的方法来实现
目的与任务
详细设计的目的，是为了SC图中每个模块确定采用的算法和块内数据结构，用选定的表达工具给出清晰的描述
这一阶段的主要任务，是编写软件的模块设计说明书
1.为每个模块确定采用的算法
2.确定每一模块使用的数据结构
3.确定模块接口、数据等全部细节
模块设计的原则与方法
1.清晰第一的设计风格
2.结构化的控制结构
任何程序的逻辑均可用顺序、选择和循环（DO-WHILE型）3种控制结构或他们的组合来实现。
3.逐步细化的实现方法
逐步细化的设计步骤：
1.由粗到细地对程序进行逐步的细化
2.在细化程序的过程时，同时对数据的描述进行细化。过程和数据结构的细化要并行地进行，在适当地时候交叉穿插。
3.每一步细化均使用相同地结构化语言，最后一步一般用伪代码描述
主要优点：
1.每一步只优先处理当前最需要细化的部分，其余的后头再说，主次分明
2.易于验证程序的正确性
常用的表达工具
详细设计中经常使用的集中设计表达工具
1.流程图和N-S图
2.伪代码和PDL语言（program design language）
面向对象概述
对象可代表客观世界中实际或抽象的事物
类是一组相似的对象的共性抽象，是创建对象的有效模板
面向对象的基本特征（必考）
抽象、封装、继承和多态，构成了OO的基本特征
抽象常用于在某个重要或想关注的侧面来表示某个物体或概念
封装可用于把操作和数据包围起来，对数据的访问只通过已定义的接口来完成
继承常用于类的层次模型，它提供了一种表述共性的方法。定义一个新类，可以从现有的类中派生出来，这称为类继承
不同类的对象可以对同一消息作出响应，执行不同的处理，这称为多态，
面向对象开发的优点（重）
1.提高软件系统的可复用性。
可复用性是面向对象软件开发的核心思路。面向对象的四大特征——抽象、封装、多态、继承，都或多或少地围绕着这个核心。对象的封装性较好地实现了模块独立和信息隐藏，使得在构造新的软件时可以方便地复用已有的对象，极大地提高了软件开发的效率
2.提高软件系统的可拓展性
面向对象程序设计可以实现很好的可拓展性，因为开发人员可以根据对用户需求的理解，不断地修改及完善有关类的描述。
3.提高软件系统的可维护性
一个系统是由对象组成的。当系统的功能需求发生变化时，通常仅需修改与之相关的对象或者类。
UML简介
UML（unified modeling language）统一建模语言
UML的组成
UML是一种基于面向对象的可视化建模语言。它提供了丰富的以图形符号表示的模型元素。
UML的模型元素
UML定义了两类模型元素。一类用于表示模型中的某个概念；另一类用于表示模型元素之间相互联系的关系。
UML的元模型结构
按照UNL的语义，UML模型可定义为4个抽象层次。从低到高分别是：
元元模型、元模型、模型和用户模型。下一层是上一层的基础，上一层是下一层的实例。
元元模型定义了用于描述元模型的语言，它是任何模型的基础。
元模型定义了用于描述模型的语言，是元元模型的一个实例
模型定义了用于描述信息领域的语言
用户模型是模型的实例，用于表达一个模型的特定情况
图和视图（必背）
图
UML有两大类图——静态图和动态图
静态图包括 用例图、类图、对象图、构件图、部署图
用例图描述系统功能（可描述软件系统和外部参与者之间的交互）
类图描述系统的静态结构
对象图描述系统在某个时刻的静态结构
构件图描述实现系统的元素的组织
部署图描述系统环境元素的配置
动态图包括 状态图、时序图、协作图、活动图
状态图描述系统元素的状态条件和响应
时序图按时间顺序描述系统元素间的交互
协作图按照连接关系描述系统元素间的交互
活动图描述系统元素的活动流程
视图
具体包括 用例视图 逻辑视图 进程视图 构件视图 部署视图
UML的特点
1.统一标准
2.面向对象
3.表达能力强大、可视化
UML的应用
1.通过对问题进行说明和可视化描述，帮助理解问题，并建立文档
2.获取和交流有关应用问题求解的知识
3.对解决方案进行说明和可视化描述，辅助构件系统，并建立文档
静态建模
UML的静态建模机制包括用例图、类图和对象图
用例图与用例模型
用例模型用于把应满足用户需求的基本功能聚合起来表示
用例模型由一组用例图组成，其基本组成部件是用例、参与者和系统。用例图可描述软件系统和外部参与者之间的交互；
用例代表从外部可见的系统的一个功能
参与者表示与系统交互的外部环境
组成符号
系统边界以一个矩形表示，上方标注系统名称，内部包含一个或多个样例；
每个用例由一个椭圆形表示，其中标上用例的名称
参与者用一个人形的符号表示
参与者和用例之间或用例和用例之间的关联均用直线表示。
用例之间的关系
用例之间主要存在两种关系：扩展关系和包含关系
类图和对象图
类描述同类对象的属性的行为
类图可表示类和类之间的关系。
在UML中，类一般表示为一个划分为3格的矩形框；
第一格指定类的名字；第二格包含类的属性；第三行包含类的操作（方法）。
第二格的语法格式为：
可见性 属性名： 类型 = 默认值 {约束特性}
常见的可见性有：Public Private Protected，对应的为 + 、 - 和 #
第三格的语法格式为：
可见性 操作名（参数表）：返回类型 {约束特性}
关联关系
关联表示两个类之间存在的某种语义上的联系，即与该关联连接的类在对象之间的语义连接（称为链接）。
普通关联
这是最常见的关联，可在两个类之间用一条直线连接，直线上写上关联名；
在关联的两端可写上一个被称为重数的数值范围，表示该类有多少个对象可与对方的一个对象连接。
递归关联
UML中允许一个类与自身关联，这称为递归关联
多重关联
有序关联 {ordered}
限制关联
用于一对多，或多对多的关联，用一个称为限制子的小方块来区分关联“多”端的对象集合
或关联（排斥或 即不能同时存在） {or}
关联类
当两个类之间的关联重数是多对多时，可以把该关联定义成关联类
聚集关系
聚集是一种特殊形式的关联
在UML中，聚集表示为空心菱形，组合表示为实心菱形。
聚集 （“部分”对象可以是多个任意“整体”对象的一部分）
组合 （“整体”的重数必须是0或1，而“部分”的重数可以是任意的）
泛化
泛化也称为继承
UML对泛化有3个要求
1.一般元素所具有的关联、属性和操作，特殊元素也都隐含性地具有
2.特殊元素应包含额外信息
3.允许使用特殊元素实例地地方，也应能使用一般元素
普通泛化
在UML中，泛化常表示为一段带空心地三角形的连线。空心三角形紧挨着父类
没有具体对象的类称为抽象类，一般用一个附加标记值{abstract}来表示
限制泛化
限制泛化是指在泛化关系上附加一个约束条件，以便进一步说明泛化关系的使用方法或扩充方法。在UML中，预定义的约束有4种：多重、不相交、完全和不完全（也称非完全）
多重继承指的是子类的子类可以同时继承多个上一级子类
与多重继承对立的是不相交继承。一般的继承都是不相交继承
完全继承是指父类的所有子类都被穷举完毕
不完全继承相反，父类的子类可以不断地补充和完善。
依赖
假设有两个元素X、Y，如果修改X的定义可能会引起对Y的定义和修改，则称元素Y依赖于元素X。
依赖关系的图形表示为带箭头的虚线，箭头指向独立的类
约束与派生
派生用于描述某种事物的产生规则
约束和派生机制能应用于任何模型元素
通常在派生属性前面加一个“/”表示
派生属性的计算公式用花括号括起来放在类的下方
包
在OO设计中，可将许多类集合成一个更高层次的单位，形成一个高内聚、低耦合的类的集合。UML把这种将一些模型元素组织成语义上相关的组的分组机制称为包。
包与包之间允许的关系有：依赖和泛化
动态建模
消息
在面向对象技术中，对象间的交互通过对象间的消息传递来完成。
在UML中，用带有箭头的线段将消息的发送者和接收者联系起来，箭头的类型表示消息的类型
UML定义的消息类型有以下3种：简单消息、同步消息、异步消息
简单消息 表示简单的控制流
同步消息 表示嵌套的控制流，操作的调用是一种典型的同步消息
异步消息 表示异步控制流
状态图
状态图用来描述一个特定对象的所有可能状态以及引起其状态转移的事件。
状态图有初态、终态与中间状态3种状态
一个状态图只能有一个初态，而终态则可以有多个。
一个状态由状态名、状态变量和活动3部分组成，其中状态变量和活动是可选的
时序图
时序图用来描述对象之间的动态交互，着重体现对象间信息传递的时间顺序。
它以垂直轴表示时间，水平轴表示不同的对象。
协作图
协作图用于描述相互协作的对象间的交互和链接。
时序图着重体现交互的时间顺序，而协作图则着重体现交互对象间的静态链接
软件需求工程
软件需求主要指一个软件系统必须遵循的条件或具备的能力（系统的外部行为、系统的内部特性）
软件需求一般包括3个不同的层次：业务需求、用户需求和功能需求
业务需求是客户或市场对软件的高层次的目标要求
用户需求即从用户使用角度来描述软件产品必须完成的任务
功能需求定义软件开发人员必须实现的软件功能，以及为了有效实现这些功能而必须达到的非功能要求、约束条件等，从而完成任务，满足业务需求。
软件需求的特性
软件需求包括六个特性：功能性、可用性、可靠性、性能、可支持性和设计约束
软件需求工程
软件需求工程是一门应用有效的技术和方法、合适的工具和符号，来确定、管理和描述目标系统及其外部行为特征的学科；是一门分析、记录并维护软件需求的学科。
需求分析与建模（重）
需求分析通常指软件开发的第一项活动，而该项活动的目的主要是为待开发的软件系统进行需求定义与分析，并建立一个需求模型
需求分析的步骤
软件需求分析一般包括如下的四个步骤：需求获取、需求建模、需求描述（即编写SRS）和需求验证
需求获取 通常从分析当前系统包含的数据开始。为了获取较为全面的信息，可以按照使用频率等类别对客户进行分类，然后每类选取用户代表，从中获取功能期望，之后再考虑质量等其他要求
需求建模 主要任务是建立需求模型，用以可视化地说明软件需求，常用模型包括（用例图、数据流图、实体联系图、控制流图、状态转换图等）
需求描述 编写软件需求规格说明书（SRS），必须用统一格式的文档进行描述。在编写时应该指明需求的来源、为每项需求标号，便于后续跟踪
需求验证 通过验证来改善编写SRS时出现的问题，确保SRS的正确与完善。
这四个步骤是周而复始，组成一个迭代的过程，直到所编写的SRS真正符合用户的需求为止
常规的需求获取方法：建立联合分析小组、用户访谈
需求模型
包括结构化需求模型与面向对象需求模型
结构化需求模型
包括数据流图和加工规格说明的功能模型
数据字典和E-R图的数据模型
状态转换图、控制流图、控制规格说明的行为模型
面向对象需求模型
由三个部分组成：用例模型、补充规约和术语表，其中用例模型包括用例图和用例规约
用例图主要用于显示软件系统的功能，它包括用例和参与者两方面的内容
面向对象的需求建模
包括画用例图、写用例规约、描述补充规约和编写术语表等四步
画用例图
（1）确定参与者
参与者主要是待开发系统的使用者，可以是人、其他软件系统或硬件设备
可从以下问题入手：
谁使用、从那些人获取数据、谁来维护管理、与哪些其他系统关联
（2）确定用例
主要是考察各参与者需要系统提供什么样的服务，可从以下问题入手
为什么要用，如何进行操作，
（3）绘制和检查用例图，检查内容如下
1.每个用例至少应该涉及一个参与者
2.参与者和用例的名称是否符合统一的命名约定和风格
3.用例建模通常属于团队开发
写用例规约（重）
用例规约用来描述每一个用例的功能，一个用例对应一个用例规约，描述用例的细节。
用例规约文档一般包含以下内容
简要说明：简要介绍该用例的作用和目的
事件流：包括基本流和备选流，表示出所有可能的活动及流程
特殊需求：描述与该用例相关的非功能性需求和设计约束
前置条件和后置条件
补：
1.简要说明主要用文本方式表达
2.基本流，是指该用例最正常的一种场景
3.备选流：用于描述用例执行过程中的异常或偶尔发生的情况
4.特殊需求 通常是非功能性需求，为一个用例所专有
5.前置和后置条件。前置条件是执行用例之前必须存在的系统状态，后置条件是用例执行完毕后系统可能处于的一组状态。
用例模型的检查
1.功能需求的完备性；2.模型是否容易理解；3.是否存在不一致性；4.避免二义性语义
描述补充规约
补充规约用于记录在用例模型中不易表述的系统需求。
编写术语表
术语表主要用于定义软件开发项目特定的术语。
调整用例模型
可从以下方面检查
1.用例之间是否独立
2.用例的包含关系
3.多个用例间是否有相似的行为或事件流
软件需求描述
软件需求规格说明书简称SRS，是软件开发人员在分析阶段需要完成的用于描述需求的文档。
SRS的主体描述软件系统的分析模型，包括信息描述、功能描述和行为描述。
软件分析概述
软件需求：用户角度，注重软件的外在表现
软件分析：开发者角度，注重软件的内部逻辑结构
OOA的主要任务
首先要理解用户的需求
然后进行分析，提取类和对象，并结合分析进行建模
OOA的模型
处于OOA模型核心的是以用例模型为主体的需求模型
有3种子模型：类/对象模型、对象-关系模型、对象-行为模型
OOA的优点（重）
1.同时加强了对问题空间和软件系统的理解
2.改进包括用户在内的与软件分析有关的各类人员之间的交流
3.对需求的变化具有较强的适应性
4.很好地支持软件复用
5.确保从需求模型到设计模型地一致性
面向对象分析模型
典型的五层次模型
1.建立类/对象层；2.建立属性层；3.建立服务层；4.建立结构层；5.建立主题层
OOA方法的共同特征
1.需求理解；2.定义类和对象；3.标识对象的属性和操作；4.表示类的结构和层次
5.建立对象-关系模型；6.建立对象-行为模型；7.评审OOA模型
面向对象分析模型
通常分析类被划分为3种类型：边界类、控制类和实体类
《boundary》《control》《entity》
边界类提供接口；控制类封装行为；实体类存储信息
边界类和实体类之间并非始终需要一个控制类
查找分析类
1.为每队参与者/用例确定一个边界类
2.为每个用例设置一个控制类
3.确定相关的各个实体（包括属性和方法）
用例模型的对象-行为模型 （动态模型） 对象-关系模型（静态模型）
面向对象设计的任务，是将分析阶段建立的分析模型转变为软件设计模型
软件设计的概念
设计的目标，是细化解决方案的可视化设计模型，确保设计模型最终能平滑地过度到程序代码。关键是构造解决问题的方案，并在决定实施细节的基础上获得该方案的设计模型。
模块是一个拥有明确定义的输入、输出和特性的程序实体
可重复使用的软件组件称为软件构件
细化的实质就是分解
软件设计一般包括数据设计、体系结构设计、接口设计和过程设计等内容
模块化设计
模块化设计的目的是按照规定的原则把大型软件划分为一个较小的、相对独立但相互关联的模块。
分解和模块独立性，是实现模块设计的重要指导思想
分解
7+-2 —— 人类信息处理能力的限度
模块的独立性可以从两个方面来度量，即模块本身的内聚（块内联系）和模块之间的耦合（块间联系）
内聚
内聚是从功能的角度对模块内部聚合能力的量度
由弱到强
低内聚 偶然性内聚 逻辑性内聚 时间性内聚
中内聚 过程性内聚 通信性内聚
高内聚 顺序性内聚 功能性内聚
耦合
耦合是对软件内部块间联系的度量
由弱到强
弱耦合 非直接耦合 数据耦合 特征耦合
中耦合 控制耦合
较强耦合 外部耦合 公共耦合
强耦合 内容耦合
OO分析模型转换到OO设计模型 P173
OOD的软件设计划分为两个层次：系统架构设计 系统元素设计
系统元素设计包括： 类/对象设计 子系统设计 包设计
软件模式分为 架构模式、设计模式 和 习惯用法三种
子系统实际上是一种特殊的包
进程和线程的关联关系——组合关系，因为线程在进程外无法存在
《process》 进程 《thread》 线程
编码概述
编码俗称编程序。软件开发的终极目标，是产生能在计算机上执行的程序
只有到了编码阶段，才产生可执行的代码，把软件的需求真正付诸实现，所以编码阶段也称为实现阶段。
编码的目的，是使用选定的程序设计语言，把设计模型翻译为用该语言书写的源程序。源程序经过编译等环节，再转化成可执行代码。
编码的风格提倡简明与直接
软件 = 程序 + 文档
测试的基本概念
软件测试是动态查找程序代码中的各类错误和问题的过程。
目的：发现程序的错误
任务：通过在计算机上执行程序，暴露程序中潜在的错误
先测试，若与预期结果不符，后纠错
测试的特性：挑剔性、复杂性、不彻底性 、经济性。
测试的种类
程序测试分为两类：静态分析（程序不执行）和动态测试（程序执行）
静态分析就是通过对被测程序的静态审查，发现代码中潜在的错误，一般用人工方式脱机完成。
动态测试也可分为两类，一类把被测程序看成一个黑盒，根据程序的功能来设计测试用例，称为黑盒测试；另一类根据被测程序的内部结构设置测试用例，测试者需要事先了解被测程序的结构，故称为白盒测试。
测试的文档
为了保证测试质量，软件测试必须完成规定的文档。
测试用例 = {测试数据 + 期望结果}
测试结果 = {测试数据 + 期望结果 + 实际结果}
黑盒测试
黑盒测试就是根据被测试程序功能来进行测试，所以也称为功能测试。
常用技术有：等价分类法、边界值分析法、错误猜测法等
白盒测试
白盒测试以程序的结构为依据，所以又称为结构测试。
常用技术有：逻辑覆盖测试、路径测试
单元测试的实施步骤可以简述为：
编译 ——》 静态分析器检查 ——》 代码评审 ——》 动态测试
集成测试的策略，可以分为 自顶向下、自底向上、两头逼近的混合方式的三种
对于OO软件而言，单元是封装的类和对象
第一章绪论
1．软件：是能够完成预定功能和性能的可执行的计算机诚信度。包括使程序正常执行所需的数据，以及有关描述程序操作和使用的文档。即：软件＝程序＋文档
2．软件的特征：软件的开发不同于硬件设计、不同于硬件制造、不同于硬件维修。
3．软件工程方法学：把在软件生命周期全过程中使用的一整套技术方法的集合。三要素：方法、工具、过程
4．软件工程学的范畴：
软件开发技术（软件开发方法学、软件工具、软件工程环境）、软件工程管理（软件管理学、软件经济学、度量学）。
5．软件工程：是指导计算机软件开发和维护的工程学科。它采用工程的概念、原理、技术和方法来开发与维护软件，
目的是为了实现按照预期的进度和经费完成软件生产计划，同时提高软件的生产率和可靠性。
6．软件的发展：大体经历了程序、软件、软件产品3个阶段。
7.工具和方法是软件开发技术的2大支柱。
8.3种编程泛型：过程式编程泛型、面向对象编程泛型、基于构件技术的编程泛型
9．面向对象程序设计中，数据和操作被封装在一个对象中，对象之间则是通过消息相互联系。
10．构件：标准化／规格化的对象类。
11.3种编程泛型的差异：粒度由小到大依次是：过程式编程范式、面向对象编程范式、基于构件的编程泛型。
12．软件工程的分化：1、传统软件工程2、面向对象软件工程3、基于构件的软件工程
13．消除软件危机的途径：①正确认识计算机软件；②充分认识到软件开发是一种组织良好、管理严密、各类人员协同工作的工程项目，推广使用在实践中总结出来的开发软件的成功的技术和方法；③开发和使用更好的软件工具。
第二章软件生存周期与软件过程
1．软件生存周期：计划、开发、运行3个时期。
需求分析﹣》软件分析﹣》软件设计﹣》编码测试﹣》软件测试﹣》运行维护
2．需求分析（用户视角）：功能需求、性能需求、环境约束、外部接口描述。
3．软件分析（开发人员视角）：建立与需求模型一致的，与实现无关的软件分析模型。
4．软件设计：总体设计／概要设计、详细设计（确定软件的数据结构和操作）。
5．软件测试：单元测试、集成测试、系统测试。
6．软件开发方法可区分：形式化方法、非形式化方法。
7．形式化开发模型：转换模型、净室模型
8．软件可行性研究：经济可行性、技术可行性、运行可行性、法律可行性。
9．可行性研究的步骤：对当前系统进行调查研究、导出新系统的解决方案、提出推荐方案、编写可行性论证报告。
10．可行性论证报告的内容：系统概述、可行性分析、结论意见。
11．软件风险分析包括：风险识别（项目风险、技术风险、商业风险）、风险预测、风险的驾驭和监控。
12．软件计划的7种类型：项目实施计划、质量保证计划、软件测试计划、文档编制计划、用户培训计划、综合支持计划、软件分发计划。
第三章结构化分析与设计
1.瀑布模型的生命周期：需求定义与分析﹣》总体设计﹣》详细设计﹣》编码﹣》测试﹣》维护
2．系统的开发流程（ SA 和 SD 流程）;
结构化分析（工具： DFD , PSPEC )------》分析模型（分层 DFD 图）+ SRS
结构化设计（工具： SC 图（映射）-----》初始设计模型（初始 SC 图）
初始设计模型（初始 sc 图）（优化）------》最终设计模型（最终 SC 图）
3. SA 需求分析的两项基本任务：建立系统分析模型、编写 SRS 。
4．分析模型组成：功能模型、数据模型、行为模型3种。
5.抽象和分解是结构化分析的主要指导思想，细化的实质是分解。分解和细化是软件设计的策略。
6. SD 阶段把分析模型中的 DFD 图转换为最终 SC 图。
7．传统软件的开发技术：结构化设计、模块设计。
8．软件设计：总体设计／概要设计（初始 sc 图、最终 Sc 图）、详细设计（用逐步细化的方法，完成模块的说明）。
9．需求分析的步骤：需求获取、需求提炼、需求描述、需求验证。
10.DFD图不能表示程序的控制结构（如选择、循结构）。
11．加工规格说明通常用结构化语言、判定表、判定树作为描述工具。
12．软件中的数据分为3类：数据项（数据元素）、数据流（多个相关数据项）、数据文件和数据库。
13．数据字典的组成：数据项、数据流、数据存储（文件或数据库）、加工（处理逻辑）、外部项（人、物或其它软件系统）。14.SD模型是由 SA 模型映射而来的。
14.SA 模型的数据字典可转换为待开发系统的数据设计
数据流图可转换为体系结构设计（ SC 图）与接口设计
加工规格说明可转换为模块内部的详细过程设计
构设计
15.SD模型的组成：从上到下依次是：过程设计、接口设计、体系结构设计、数据设计。
16．结构化分析的基本步骤：
自顶向下对系统进行功能分解，画出 DFD 图；由后向前定义系统的数据和加工；编制 DD 和 PEPES ；写出 SRS 。
17．把不需要分解的加工成为基本加工。把逐步分解成为"自顶向下，逐步细化"。
18.DFD的优点：便于实现，便于使用。
19．传统的软件设计可细分为：面向数据流设计（ SD 方法）、面向数据结构设计（ Jackson 方法）。
20．用数据流图表示逻辑模型，在设计阶段，按照数据流图的不同类型（变换型、事务型）转换为相应的软件结构。
21．结构化设计通常从 DFD 图到 SC 图的映射开始。
22．面向数据流的设计方法：从 DFD 图到 SC 图的映射的4个步骤
1、复审 DFD 图，必要时可再次进行修改或细化；
2、鉴别 DFD 图的结构特征：事务？变换？;
3、按照规则，把 DFD 图为初始的 SC 图；
4、改进初始的 SC 图。
23．变换型结构：由输入、变换中心和输出三部分组成。
事务型结构：具有在多种事务中选择执行某类事物的能力。
24．变换映射的步骤：划分 DFD 图的边界、建立初始 SC 图的框架、分解 SC 图的各个分支。
事务映射的步骤：在 DFD 图上确定边界、画出 Sc 图框架、分解和细化接受分支和发送分支。
25．优化结构设计的指导规则：对模块分割、合并和变动调用关系的指导规则、保持高扇入／低扇出的原则、作用域／控制域规则。
26．模块设计（详细设计）的主要任务是编写软件的模块设计说明书。目的是确定模块采用的算法和块内数据结构。
27．模块设计的原则：清晰第一的设计风格、结构化的控制结构、逐步细化的实现方法。
28．结构化程序设计原理和逐步细化的实现方法是完成模块设计的基础。
第四章面向对象和 UML
1．面向对象的基本特征：抽象、封装、集成、多态。
2．面向对象开发的优点：提高软件系统的可复用性、可扩展性、可维护性、面向对象符合人类习惯的思维方式。
3.元素之间的联系有：关联、泛化、依赖、实现、聚集、组合。
4. UML 的4个抽象层次：用户模型、模型、元模型、元元模型。
5. UML 的2类图：
静态图（用例图、类图、对象图、构件图、部署图）;
动态图（状态图、时序图、协作图、活动图）
UML 的5种视图：用例视图、逻辑视图、进程视图、构件视图、部署视图。
6.UML的特点：统一标准、面向对象、表达能力强，可视化。
7. UML 模型作为测试阶段的依据：
单元测试使用类图和类规格说明；集成测试使用构件图和协作图；系统测试使用用例图来验证系统行为。
8.UML中用例图由系统边界、用例、参与者、关联组成。用例之间存在的关系：扩展关系、包含关系。
包与包之间的关系有：依赖、泛化。
9.根据类／对象之间的具体情况，可分为普通关联，递归关联、多重关联、有序关联、限制关联、或关联、关联类
10．消息（类里面的方法加参数）：简单消息、同步消息、异步消息。状态图有：初态、终态、中间态。
11．时序图中的消息可以是信号或操作调用。
12．时序图着重体现交互的时间顺序；协作图着重体现交互对象间的静态链接。
13．时序图和协作图适合描述单个用例中几个对象的行为；活动图适合表现跨越多用例或多线程的复杂行为。
14．构件图可以用来表现、编译、链接、执行时构件间的依赖关系。
15.UML用图表示语法，用元模型表示语义，采用模型来描述系统的结构（静态特征）以及行为（动态特征）。
第五章需求工程和需求分析
1．软件需求的3个层次：业务需求、用户需求、功能需求。软件项目中40%~60％的问题源自软件需求阶段。
2.软件需求的6个特性：功能性、可用性、可靠性、性能、可支持性、设计约束。
3．需求分析的步骤：需求获取、需求建模、需求描述（编写 SRS )、需求验证。
4.需求分析的主要任务：建立需求模型。需求分析是迭代过程。
常见模型有：用例图、数据流图、实体联系图、控制流图、状态转换图。
5.需求获取的方法：1、建立联合分析小组2、用户访谈。
6．获得用例的方法通过问问题：1、系统用户是谁？系统维护时谁？从哪获得信息？给谁？
7．需求建模方法：结构化分析建模方法、面向对象分析建模。
8.结构化需求模型由3部分组成：功能模型（数据流图、加工规格说明书）、数据模型（数据字典、 ER 图）、行为模
型（状态转换图、控制流图、控制规格说明书）。
9．面向对象需求模型：用例模型（用例图、用例规约）、补充规约、术语表。
10．面向对象需求建模的步骤：画用例图、写用例规约、描述补充规约、编写术语表、调整优化。
11．用例规约文档的内容：简要说明、事件流、特殊需求、前置条件和后置条件。
12．用例规约的检查：功能需求的完备性、模型是否易于理解、是否存在不一致性、避免二义性。
13．软件需求规格说明书 SRS 的内容：引言、信息描述、功能描述、行为描述、质量保证、接口描述、其他描述。
14．需求管理的流程：需求确认、需求跟踪、需求变更。需求跟踪有两种方式，正向跟踪与逆向跟踪。
需求变更的流程：变更申请、审批、更改、更新确认。
第六章面向对象分析
1．建立面向对象分析模型步骤：1、建立类／对象层（抽象出类和对象）、2、建立属性层（设计静态属性和关系）、3、建立服务层（定义动态属性和消息通信）、4、建立结构层（定义层次结构关系）、5、建立主题层
2.OOA方法的共同特征：类和类层次的表示、建立对象﹣关系模型、建立对象﹣行为模型。
3．面向对象开发的全过程： OOA （分析）、 OOD （设计）、 OOP （编码）、 OOT （测试）。
4.用例模型是面向对象分析最常用的一种模型。
5.分析类的类型：边界类、控制类、实体类。
6．每个参与者与用例之间确定一个边界类，每个用例设置一个控制类，而实体类为现实生活中的对象，类（属性与方法）或用于保存和更新信息的有关对象。
7．边界类包括：用户界面类、系统接口类、设备接口类。如事务管理器、资源协调器、错误处理器都可为控制类。
8．控制类分离边界类和实体类，可用来建立系统的动态行为模型。实体类用于保存和更新一些对象的有关信息。
9.为分析类分配职责是 OOD 的重点。实体类具有持久性。
10．对象﹣关系模型的内容：分析类的属性、分析类的关联、分析类图、分析类的合并。（用类图来表示）
11．对象行为模型用状态转换图、时序图、协作图、活动图来表示。
12．面向对象分析时：1、确定分析类，2、静态模型建立画类图，3、动态模型建立画时序图和协作图。
13．时序图中的元素有：对象、对象生命线、消息。协作图中的元素有：对象、链接、消息流。
14．面向对象分析的任务是：将需求阶段产生的需求模型转换为软件分析模型。
面向对象设计的任务是：将分析阶段建立的分析模型转换为软件设计模型。
第七章面向对象设计
1．软件设计的基本概念：模块（拥有明确定义的输入、输出和特性的程序实体）与构件、抽象与细化、信息隐藏、软件复用。
2．软件设计的基础：分析阶段对目标系统的数据、功能、行为建模。
3．软件设计的任务：把分析阶段产生的分析模型转换为软件设计模型。
4．软件设计包括：数据设计、体系结构设计、接口设计、过程设计。
5．面向对象设计准则：模块化；抽象；信息隐藏；弱耦合；强内聚；可重用
6．分解和模块独立性是实现模块设计的重要指导思想。
7.模块的独立性从2个方面度量：模块本身的内聚、模块之间的耦合。
8．内聚分类：低内聚（偶然性内聚、逻辑性内聚、时间性内聚）、中内聚（过程性内聚、通讯性内聚）、高内聚（顺序性内聚、功能性内聚）。
9．耦合分类：弱耦合（非直接耦合、数据耦合、特征耦合）、中耦合（控制耦合）、较强耦合（外部耦合、公共耦合）、强耦合（内容耦合）。
10．一个模块，一个功能是模块化设计的一条准则。
11.00设计模型由系统架构层、类和对象层、消息层、责任层4个层次组成。
12．面向对象设计中，数据和过程被封装为类／对象的属性和操作◇接口被封装为对象间的消息，而体系结构的设计则体现为系统的技术基础设施和具有控制流程的对象间的协作。
13．传统的软件设计任务包括：概要设计和详细设计
14．概要设计（总体设计）：包括软件的结构和接口设计，并编写概要设计文档。详细设计，确定模块内部的算法和数据结构，产生描述各模块程序过程的详细文档。每个阶段完成的文档都必须经过复审。
15.OOD的软件设计任务可划分为2个层次：系统架构设计、系统元素设计。
16．系统架构设计的内容：系统高层结构设计、确定设计元素、确定任务管理策略、实现分布式机制、设计数据存储
方案、人机界面设计。系统元素设计的内容：子系统设计、分包设计、类／对象设计。
17．常用的架构模式有：层次架构、模型﹣视图﹣控制（ MVC ）架构、管道﹣过滤器架构、黑板架构。
18．面向并行需求，任务管理策略主要3种解决方案：多处理机方案、操作系统方案、应用程序方案。
19．分包的原则：将边界类打包、将功能相关的类打包。高内聚﹣低耦合的原则，包之间的耦合表现为依赖关系。
20. a 向 b 发送消息的必要条件是 a 能够引用 b , a 可以通过4种方式引用 b ，对应于从 a 到 b 的4种连接可见度：1、全局： b 是可以在全局范围内直接引用的对象。2、参数： b 作为 a 的某一项操作的参数或返回值。3、局部： b 在 a 的某一操作中充当临时变量。
21．操作的可见性：公有：除了累本身以外，操作对其他模型元素也是可见的；也可以用"+"表示；
保护：操作只对类本身、它的子类也是可见的；也可以用"#"表示。
私有：操作只对类本身是可见的，也可以用"一"表示。
第八章编码和测试
1.编码的风格：1、追求"聪明"和"技巧"--＞提倡"简明"和"直接"2、使用标准的控制结构3、清晰的前提下求取效率
2.编码的目的：设计模型（不可执行的）--->（编码）源程序﹣﹣可执行代码
3.选择编码语言的标准：1、应用领域2、算法与计算复杂性3、数据结构的复杂性4、效率的考虑
4．测试和纠错：
测试（ testing ）的目的与任务：目的：发现程序的错误；任务：通过执行程序，暴露潜在的错误。
纠错（ debugging ）的目的与任务：目的：定位和纠正错误；任务：消除软件故障，保证程序的可靠运行。
5．测试的特性：挑剔型、复杂性、不彻底性、经济型。
6．测试分类：静态分析（静态分析器分析、代码评审（代码会审、走查、办公桌检查）);
动态测试（黑盒测试（功能测试）、白盒测试（结构测试）)。
7．黑盒测试分类（根据被测试程序功能来进行测试）：等价类法、边界值法、错误猜测法。
8．白盒测试分类（以程序结构为依据的测试方法）：路经测试（点覆盖、边覆盖、路径覆盖）、逻辑覆盖测试（语句
覆盖、判定覆盖、条件覆盖、判定／条件覆盖、条件组合覆盖）。
1、什么是软件危机？为什么会产生软件危机？
答：软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题，如软件费用、软件可靠性、软件维护、
软件生产、软件重用等。(1)．软件维护费用急剧上升，直接威胁计算机应用的扩大。(2)．软件生产技术进步缓慢
2、何谓面向对象软件工程？简述它与传统软件工程的差别和联系？
传统方法学：采用结构化技术；软件生命周期的全过程依次划分为若干阶段，自顶向下顺序完成；
优点：便于分工协作，每个阶段采用科学的管理技术和良好的技术方法，提高软件开发的成功率；
缺点：只能面向行为或者数据。
面向对象方法学：是一种以数据为主线，把数据和对数据的操作结合起来的方法。把对象作为融合数据及数据上的操作优点：①降低了软件产品的复杂性，提高了软件的可理解性，简化了软件的开发和维护工作；②提高了软件的可重用性。缺点：只能面向对象和行为。
的统一的软件构件；划分类；按照继承关系；通过发送消息互相联系；
第二章
1．什么是软件生存周期？把生存周期划分为阶段的目的是什么？
答：软件生存周期是指一个软件从提出需求开始直到该软件报废为止的整个时期。需求分析、软件分析、软件设计、编码、软件测试、运行维护等活动，可以将这些活动以适当方式分配到不同阶段去完成。，把整个生存周期划分为较小的阶段，给每个阶段赋予确定而有限的任务，就能够化简每一步的工作内容，使因为软件规模而增长而大大增加了软件复杂性变得交易控制和管理。
2．传统的瀑布模型把生存周期分为哪些阶段？瀑布模型软件开发有哪些特点？
答：瀑布模型在编码以前安排了分析阶段和设计阶段◇阶段间具有顺序性和依赖性。
3．什么是快速原型法？其快速表现在哪里？
答：首先建立一个能够反映用户主要需求的原型，让用户实际看一看未来系统的概貌，以便判断哪些功能是符合需要的，哪些方面还需要改进。然后将原型改进，最终建立完全符合用户要求的新系统。它的快速表现在能够缩短开发周期的语言和工具，能在短时间内提供出成品，但不包括成品中的细节，然后让客户进行对比。
6．比较增量模型和螺旋模型的特点，有什么不同和相似的地方？
答：增量模型是瀑布模型的顺序特征与快速原型法的迭代特征相结合的产物。螺旋模型是一种迭代模型，每迭代一次，螺旋线就前进一周。增量模型每个增量具有高内聚低耦合，高度的独立性。而螺旋模型它在结合瀑布模型与快速原型的基础上还增加了风险分析。
哪些开发模型适用于面向对象的软件开发？
答：构件集成模型、转换模型、净室模型。
第三章问题
1．需求分析的任务是什么？怎样理解分析阶段的任务是决定"做什么"，而不是"怎么做"?
答：需求分析主要有两个任务：第一是通过对问题及其环境的理解、分析和综合建立分析模型；第二是在完全弄清用户对软件系统的确切要求的基础上，用"软件需求规格说明书"把用户的需求表达出来。需求分析的任务就是为了明确要开发的是一个什么样的系统，而不是去怎么去实现这个系统。
2．需求分析要经过哪些步骤？
答：需求获取、需求提炼、需求描述、需求验证。
3．有哪两种主要的分析模型，它们有什么联系？
答：面向对象分析模型、结构化分析模型。前者是采用面向对象的思想进行软件需求分析的建模过程，而后者模型的核心是 DD ，它是设计各种数据对象的总和。他们的模型分别起到了描述数据模型，功能模型与行为模型的作用。
5．什么是面向对象分析？其主要思想是什么？
答： OOA 面向对象的分析是采用面向对象的思想进行软件需求分析建模的过程．主要思想是采用面向对象的思想。
7．为什么 DFD 要分层？画分层 DFD 要遵循哪些原则？
答：大型复杂的软件系统，其 DFD 可能含有数百乃至数千个加工，不能设想一次就将它们全部画齐。正确的做法是：从系统的基本模型（把整个系统看成一个加工）开始，逐层地对系统进行分解。原则：由顶向下，逐步细化。
第四章问题
1、面向对象有哪些基本特征？
封装，继承，抽象，多态
2、 uml 中提供了哪9种图？试诉每种图所描述的内容
1、用例图
??？描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。2、类图
??？类图是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。
3、对象图
??？与类图极为相似，它是类图的实例，对象图显示类的多个对象实例，而不是实际的类。它描述的不是类之间的关系，而是对象之间的关系。
4、活动图
??？描述用例要求所要进行的活动，以及活动间的约束关系，有利于识别并行活动。能够演示出系统中哪些地方存在功能，以及这些功能和系统中其他组件的功能如何共同满足前面使用用例图建模的商务需求。
5、状态图
??？描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件（如消息的接收、时间的流逝、错误、条件变为真等）会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态图是对类图的补充。
6、序列图（顺序图）
??？序列图是用来显示你的参与者如何以一系列顺序的步骤与系统的对象交互的模型。顺序图可以用来展示对象之间是如何进行交互的。顺序图将显示的重点放在消息序列上，即强调消息是如何在对象之间被发送和接收的。
7、协作图
??？和序列图相似，显示对象间的动态合作关系。可以看成是类图和顺序图的交集，协作图建模对象或者角色，以及它们彼此之间是如何通信的。如果强调时间和顺序，则使用序列图；如果强调上下级关系，则选择协作图，这两种图合称为交互图。
8、构件图（组件图）
??？描述代码构件的物理结构以及各种构建之间的依赖关系。用来建模软件的组件及其相互之间的关系，这些图由构件标记符和构件之间的关系构成。在组件图中，构件时软件单个组成部分，它可以是一个文件，产品、可执行文件和脚本等。
9、部署图（配置图）
??？是用来建模系统的物理部署。例如计算机和设备，以及它们之间是如何连接的。部署图的使用者是开发人员、系统集成人员和测试人员。
1105
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
