整个章节偏向于记忆、背诵；
主要议题：
软件体系：3层；
UML重点，重点记3要素中的关系、图；
1.软件体系结构
分层
优点：利于软件的重复利用；
缺点：以什么方式分层，分层的粒度如何；这两个问题比较难；
常考：哪些输入服务器端、哪些属于客户端？需要记忆；
2.软件工程
软件危机：采用某种方式进行开发，开发到一定程度，随着规模越来越大，这种方法开发出来的软件的质量没有保障，而且开发成本变高；
软件工程：以工程化的思想来开发软件；
3.软件配置管理
偶尔考；
基线：软件开发过程中的一个检查点；由于软件开发的过程是连续的，就必须设置检查点，以免软件质量发生偏移；
软件配置项：软件开发中所涉及到的信息和项目，比如用户名和密码、电信网络的账户、使用到的硬件如路由器，路由器上的配置；
配置项有2中状态：自由态和受控态；自由态经过基线的评价，就到了受控态；受控态下你要进行修改，就要走变更管理流程；
产品库/开发库/受控库
开发过程中的信息，经过评审进入受控库；
受控库中有一段区域为测试区，测试区为信息的变更提供工作区间；比如说你要修改一个文件，要先通过变更管理获取修改权限，将文件从受控区改到测试区，然后完成测试，测试完成后再通过基线的评审，进入受控库；
发布产品时从产品库中发布；
4.CMM（软件能力成熟度模型）
描述软件组织所处的阶段；
主要考察队cmm几个级别的理解；
1、知道几个级别的名字；
2、知道几个级别的关键点；
例如提供一段描述，问这个组织处于哪个级别；
初始级：项目没有什么规则；没有什么经验可以借鉴；特点是英雄主义，能不能成功看人了；
可重复级：做项目时有经验可借鉴；能对项目的成本、进度有一定的控制能力；
已定义级：所有的事情都已标准化、文档化了；
已管理级：可以把控项目，进行管理了；有明确的质量指标；
优化级：在先有上，利用新技术优化软件的过程；
5.开发模型
能根据题干描述知道采用的什么模型；
必须记住：每个模型的适用项目；
瀑布模型：将软件开发的生命周期划分成多个阶段；每个阶段依次进行；
优点：各个阶段划分明确，利于项目管理、控制成本；
缺点：需求分析阶段出现问题，往往在软件测试阶段才发现；越后发现，成本越高；
对测试工作不重视；
适用项目：需求明确、解决方案明确的项目；
需求分析到软件测试都处于开发阶段；
V模型：对瀑布模型的改进，改进瀑布模型中对软件测试不重视的场景；在V模型中，把软件测试和开发阶段一一对应起来，强调软件测试的意义；但从整个流程上看，软件测试依然在写完代码后，从功能上其实还没解决测试阶段处于扫尾阶段这一问题；
箭头：
水平箭头：表示检测的对象；
斜上箭投：验证上一个层次的设计有无问题；
可能会擦掉右侧箭头让你填写；
原型、增量模型常常混淆；
原型模型：快速的开发方法，先和用户沟通，大致了解需求后，就针对需求做开发，实现大致界面，没有开发实际的后台程序；再和用户交流，用户觉得有问题再改；通过逐步演进，变成最终可交付的系统；最终只有一次交付；
原型：可运行的、只体现核心功能的模型；
优点：帮我们明确需求；
缺点：快速，意味着没写文档；文档不全；
抛弃型原型：开发时，和用户交流完，用户不认可，此原型直接丢弃，再新写；
渐进演化型原型：慢慢演化、修改成最终交付的系统；
增量模型：多次交付；
其实就是版本迭代；每一次交付都是在前一次交付的基础上增加相关功能；
优点：激发用户的进一步需求；帮助用户进一步明确需求；节约开发成本、时间，风险小；
缺点：增量如何控制？粒度多大？
螺旋模型：结合了瀑布模型和原型模型；
多次迭代；每个迭代都分成几个阶段；
模型中引入了风险分析；
优点：便于对项目的风险进行控制；用户也了解软件开发中的风险；
缺点：人来做风险分析，经验很重要；经验不足识别不出风险；
喷泉模型：下图中的各个阶段都在同时进行；是以对象为驱动的；主要用于面向对象的开发项目；
6.开发方法(RUP/UP）
统一过程：
将软件开发分成4个阶段：初始、细化、构建、交付；
它是一个以用例为驱动、以架构为中心，进行迭代和增量的开发方法；
工件：工厂中的产品；相当于你要开发的代码；
活动：有特定目的的工作；
角色：人；
工作流；
下选项哪个不属于统一过程中的对象？
敏捷开发
考点漂浮不固定；适当记忆；
极限编程：XP
Jackson方法：对时序敏感，对事件发生的先后敏感；
7.MVC
考察较少；
M：业务代码；
V：呈现给用户的信息；
C：负责转换V的需求，并进行M、V的控制管理；
用户有需求通过V给M，服务器根据业务规则取出数据给V，这个过程需要C控制请求的转换；
8.软件生命周期
考点：有哪些阶段，每个阶段主要财务是什么？
概要设计，又称总体设计；
详细设计：设计各个模块的功能，怎么做，步骤；还没开始写代码呢；
需求层次：
系统需求分为：功能需求、非功能需求、设计约束；
功能需求：必须要实现的需求；
非功能需求：你的系统必须要具备的品质；如可靠性、稳定性、可维护性；
设计约束：比如服务器、数据库用哪个牌子的；开发方法、技术用啥；
结构化分析：
数据流图（DFD图）：通过对数据在系统中传递和加工的动作来描述系统的功能需求；
因为数据流图没有明确每一项数据的特征，这时就用到数据字典；
数据流图
外部实体：与系统由信息交互，但不包括在本次开发内的对象；如工资管理系统中的银行；
加工：对数据进行变换的地方；
数据流：箭头指向谁，数据流向谁；
要能看懂考题中的DFD图，不会考大题；
父子图平衡：父图有输入输出的数据流，子图也得有等量的数据流；
数据守恒：要根据输入的数据产生输出，不要凭空出现；
数据流图体现的是数据信息，而不是控制信息，一旦有控制信息，就不是数据流图；
9.系统设计
最近的软考体系把数据库设计放到总体设计中；
数据库设计分4步：需求设计、概要设计、逻辑结构设计、物理结构设计；前3步在总体设计中，第4步在详细设计中；
10.聚合与耦合
2个指标是衡量模块独立性的标准；
程序设计原则：高聚合、低耦合；
聚合是衡量一个模块内各个元素与功能的紧密程度；
耦合强调的是模块与模块之间的关系；
题目：
1、根据聚合/耦合度排序下列的几个选项；
2、给出描述，判断是哪一类聚合/耦合；
考试频率高；
功能聚合最高，模块内的所有元素都是为这个功能服务的；
偶然聚合：模块内的各个元素之间没有必然的联系；
逻辑聚合：模块内的各个元素的逻辑距离相似；
时间聚合：模块内的各个元素在同一时间执行；
过程聚合：模块内的各个元素按照特定的次序来执行；
通信聚合：模块内的各个元素利用同一个输入、或者产生同一个输出；
顺序聚合：模块内的第一个元素的输出是第二个的输入、第二个的输出是第三个的输入；
非直接耦合：两个模块之间没关系；他俩之间的关系是通过上层调用；
数据耦合：两个模块之间要传递数据；
标记耦合：传递的数据不是一个简单的变量，而是一个数据结构；
控制耦合：传递控制信息；
外部耦合：两个模块需要一个外部简单的全局变量传递；
公共耦合：两个模块使用同一个数据区域；
内容耦合：一个模块执行时跑到另一个模块内部访问数据；
11.编码原则
提高后期的可维护性；
序言性注释：写程序之前写一段话，介绍系统的功能，运行要求等；
解释型注释：告诉读者接下来这行代码要做什么；
直接转换：新系统若有缺陷，满足不了业务需求，风险高；用于小型、不重要的系统转换；
试点后直接转换：要求企业有多个分支点，选其中一个分支点进行试点，然后再推广；失败后影响面较小，风险小；对转上一个换的条件有要求；
逐步转换：分段分批转换；上线一个庞大的系统，先上一部分，正常工作了再上另一部分模块；缺陷：与旧系统开发框架、数据库不同，就得提供多个接口给旧系统；
并行转换：新旧系统同时运行一段时间，就知道新系统有哪些缺陷，在这段时间优化；风险小，但是同时运行两个系统，资源就需要更多，服务器更多；开销大；
可维护性
纠错性维护/公正性维护：本来就有bug（已经暴露出来了），用户发现了；
适应性维护：软件适应环境的变化；如操作系统环境变化；
完善性维护：提高软件的性能和可维护性；如重新整理文档；
预防性维护：软件存在问题，但没暴露出来，没暴露出来就修复；
比重表示的是占维护工作量的比重；
12.UML
注：一般不会考大题！！！
关系和图要记；
考题：给出类图，要判断2个类之间的关系；
依赖：一个事物发生变化，回影响到另一个事物；
关联：
聚合：几个独立对象聚合在一起形成整体对象；如参加聚会、显示器与电脑；
组合：强调个体在整体中的职能与责任；部分不能独立于整体而生存；如堆积木、汽车与发动机、人和大脑、企业和企业的部门；
两者都描述的是整体与部分的关系；
泛化：特殊与一般的关系；特殊对象可以代替一般对象的描述；员工与管理层员工；对应面向对象中子类与父类的关系；
实现：两个类元之间的语义关系；一个类元指定了另一个类元保证执行的契约；
图较多，不确定考哪个，多花时间看！
类图
一个框有3层，从上到下，分别表示：类名、属性、操作；
用例图
用例：如上办公系统完成工作后，离开系统；
一般图中有人形标志，就与用例图有关；
泛化关系：同上；
包含关系：
扩展关系：
执行此用例是否一定要做另一个用例，一定则包含，否则扩展；
如：缴费和登录账户的关系，包含；查询缴费记录和保存流水，扩展；
13.软件质量
记质量特性；
下图适当记
考试考：下列选项哪个不属于功能性？
评价使用质量的4个标准：
有效性：满足用户功能的准确程度、满意程度；
生产率：满足有效性的情况下，资源的合理利用程度；
安全性：用户数据的安全；
满意度；
14.软件评审
不咋考
15.软件评价—GB/T18905.5
可重复性：同一人用同一标准对系统多次评价，评价结果可接受；
可再现性：不同人用同一标准对系统评价，评价结果可接受；
16.面向对象
消息：类之间通信；
