整个章节偏向于记忆、背诵;
主要议题:
软件体系: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.面向对象
消息:类之间通信;