软件工程复习

选择10'
填空10'
简答25'
分析设计40'
综合15'


一、软件与软件工程

1.软件的本质(什么是软件)
计算机软件是由专业⼈员开发并⻓期维护的⼯作产品,程序、数据和描述信息。这些产品包括可以在各种不同容量和不同系统结构的计算机上运⾏的程序。
软件和硬件具有完全不同的特性:软件不会"磨损",但是软件退化的确存在。
软件维护要应对变更请求,⽐硬件维护更为复杂。
2.软件应用领域(与开放题前景有关)
①系统软件:一整套服务于其他程序的程序。
②应用软件:解决特定业务需要的独立应用程序。
③工程/科学软件:"数值计算"类程序
④嵌入式软件:存在于某个产品或系统中,可实现和控制面向最终用户和系统本身的特性和功能。
⑤产品线软件:包括可复用的构件,并为多个不同用户的使用提供特定功能。
⑥Web/移动APP:以网络为中心,涵盖宽泛的应用软件产品、
⑦人工智能软件
3.软件工程
软件工程:将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护,即将工程化方法应用于软件。支持软件工程的根基在于质量关注点。
软件工程的基础是过程层,将各个技术层次结合在一起。方法层为构建软件提供技术上的解决方法。工具层为过程和方法提供自动化或半自动化的支持。

二、软件过程

1.软件过程

为创建高质量软件所需要完成的活动、动作和任务的框架。 活动主要实现宽泛的目标。动作包含主要工作产品生产过程中的一系列任务。任务关注小而明确的目标,能够产生实际产品。
1.1过程框架
定义了若干个框架活动,为实现完整的软件工程过程奠定基础,还包含一些适用于整个软件过程的普适性活动。
1.2通用过程模型
通⽤过程框架定义了 5 种框架活动 ------ 沟通、策划、建模、构建以及部署。
⼀系列普适性活动 ------ 项⽬跟踪控制、⻛险管理、质量保证、配置管理、技术评审以及其他活动(测量、配置管理、可复用性管理、工作产品的准备和生产) ------ 贯穿软件过程始终。
过程流:描述了在执行顺序和执行时间上如何组织框架中的活动、动作、任务。
①线性过程流:从沟通到部署顺序执行五个框架活动
②迭代过程流:在执行下一个活动前重复执行之前的一个活多个活动。
③演化过程流:采用循环的方式执行各个活动,每次循环都能产生更为完善的软件版本。
④并行过程流:将一个或多个活动与其他活动并行执行。
2.惯用过程模型
定义一组预定义的过程元素和一个可预测的过程工作流,力求达到软件开发的结构和秩序,其活动和任务都是按照过程的特定指引顺序进行。
瀑布、统一过程、原型、螺旋模型
2.1瀑布模型(线性顺序模型)了解
提出了一个系统的、顺序的软件开发方法。从用户需求规格说明开始,通过策划、建模、构建和部署的过程最终提供完整的软件支撑。【需求是准确定义或相对稳定的】
2.2统一过程模型(重要)
统一过程模型是一种"用例驱动、以体系结构为核心、迭代及增量"的软件过程框架,由UML方法和工具支撑。五个UP阶段不是顺序执行,而是阶段性并发执行。

  1. UP 的 起始阶段 包括客户沟通和策划活动。
  2. 细化阶段 包括沟通和通⽤过程模型的建模活动。
  3. 构建阶段 与通⽤软件过程中的构建活动相同。
  4. 转换阶段 包括通⽤构建活动的后期阶段以及通⽤部署活动的第⼀部分。
  5. ⽣产阶段 与通⽤过程的部署活动⼀致。
    三、敏捷开发
    1.敏捷
    要定义灵活机动、有适应能力和精益的过程以适应现代商务的需求。 敏捷开发 是⼀种软件开发⽅法论,可以应对客户快速变更的需求。它强调以⼈为核⼼,采⽤迭代的⽅式,循序渐进的 开发软件。
    2.变更成本降低。敏捷过程(基于敏捷原则进行的开发过程)必须具有可适应性。采用增量式开发策略,短时间间隔内交付软件增量来适应变更的步伐。
    3.敏捷原则
    通过尽快向客户交付软件来提供价值,可以获得客户满意度。
    3.1敏捷宣言(四大宣言)
  • 个体和互动 高于 流程和工具
  • 工作的软件 高于 详尽的文档
  • 客户合作 高于 合同谈判
  • 相应变化 高于 遵循计划
    4.敏捷框架
    4.1Scrum
    在固定的时间盒内进行检视和调整,并坦诚地面对真相。每次冲刺期间都会产生至少一个软件增量,产生有形成果。
    4.2 XP框架(极限编程)最广泛
    按照策划、设计、编码、测试四个框架活动组织,并提出一系列新颖有力的技术。保证利益相关者指定优先级特征和功能软件的频发发布。
    4.3 看板法
    提供了改进过程或工作流的方法,专注于变更管理和服务交付。
    4.4 DevOps
    将开发与运维结合。快速响应需求提升客户体验。

    四、如何成为一个优秀的开发人员
    个人责任感、敏锐的意识、坦诚、抗压能力、高度的公平感、注重细节、务实的。
    采用敏捷理论、社交媒体和电子通信对全球化软件开发尤其有益处。
    五、需求工程
    需求⼯程是指致⼒于不断理解需求的⼤量任务和技术。
    需求⼯程包括七项任务:起始,获取,细化,协商,规格说明,确认和管理。
    六、需求建模【有多少种图】
    1.需求分析
    产生规格说明,指定接口,规定约束。软件工程师可细化起始、获取、协商任务中建立的基础需求。
    需求建模动作结果为以下多种模型类型:场景模型、面向类的模型、行为模型、数据模型、面向流的模型。
    2.编写用例
    用例就是以用户的角度描述系统
    ⽤例描述⼀般包括:简要描述(说明)、前置(前提)条件、基本事件流、其他事件流、异常事件流、后置(事后)条件等等。下⾯说说各个部分的意思:
    简要描述:对⽤例的⻆⾊、⽬的的简要描述;
    前置条件:执⾏⽤例之前系统必须要处于的状态,或者要满⾜的条件;
    基本事件流:描述该⽤例的基本流程,指每个流程都 " 正常 " 运作时所发⽣的事情,没有任何备选流和异常流,⽽只有最有可能发⽣的事件流;
    其他事件流:表示这个⾏为或流程是可选的或备选的,并不是总要总要执⾏它们;
    异常事件流:表示发⽣了某些⾮正常的事情所要执⾏的流程;
    后置条件:⽤例⼀旦执⾏后系统所处的状态;

3.基于类建模

角色、外部实体、事件或事物

3.1CRC

一个CRC卡片由三个组成部分构成:1、首先构成相似现实对象的类;2、明确此类应该知道或者应该做的职责;3、找出在此类实现职责过程中产生相互作用的其他类作为协作者。

4.功能建模

4.1活动图

通过提供特定场景内交互流的图形化表示来补充用例

4.2顺序图

显示事件如何引发从一个对象到另一个对象的转移。

5.行为建模

以过程为导向,描述了软件的动态行为。

5.1状态图

被动状态(某个属性当前值)、主动状态(对象进行持续变换时的当前状态)、事件(触发器) 【必须发生以迫使对象做出从一个主动状态到另一个主动状态的转移】

为每个类呈现了主动状态和导致发生变化的事件(触发器)

5.2活动图

在特定场景内通过提供迭代流的图形化表示来补充用例。(系统如何对内部事件做出反应)

5.3泳道图

允许建模人员表示用例所描述的活动流,同时指出哪个参与者或分析类负责由活动矩形描述的活动。职责由纵向分割图中的并行条表示。

七、设计概念【选填】

1.模式

设计模式描述了解决某个定义明确的设计问题的设计结构,环境会影响到模式的应用和使用方式。

每种设计模式目的都是提供一种描述,可决定模式是否适用于当前工作、是否能够复用、是否能够用于指导开发一个相似但功能或结构不同的模式。

2.关注点分离

是一个设计概念,表明任何复杂问题如果被分解为可以独立解决或优化的若干块,该复杂问题便能够更容易地得到处理。关注的是一个特征或行为,被指定为软件需求模型的一部分。将关注点切割为更小的关注点。

3.模块化
模块化是软件的单⼀属性,它使程序能被智能化地管理。
模块化是为了使⼀个复杂的⼤型程序能被⼈的智⼒所管理,软件应该具备的惟⼀属性。
如果⼀个⼤型程序仅由⼀个模块组成,它将很难被⼈所理解。
4.信息隐蔽
模块应该被特别说明并设计,使信息都包含在模块内,其他模块无权访问。
5.功能独立
软件设计时应使每个模块仅设计需求的某个特定子集,并且当从程序结构的其他部分观察时,每个模块只有一个简单接口。
5.1 内聚性
传统观点:构件的专⼀性
⾯向对象的观点:内聚性意味着构件或类只封装那些相互关联密切,以及与构件或类⾃身有密切关系的属性和操作。
内聚分类:功能内聚、分层内聚、通信内聚、顺序内聚、过程内聚、时间内聚、偶然内聚
5.2 耦合性
耦合性是程序结构中各个模块之间相互关联的度量它取决于各个模块之间接⼝的复杂程度、调⽤模块的⽅式 以及那些信息通过接⼝
传统观点:⼀个组件连接到其他组件和外部世界的程度。
⾯向对象的观点:耦合是类之间彼此联系程序的⼀种定性度量。
耦合是必然存在的。
耦合程度:内容耦合、共⽤耦合、控制耦合、标记耦合、数据耦合、例程调⽤耦合、类型使⽤耦合、包含或
者导⼊耦合、外部耦合。
6.逐步求精
是一种自顶向下的设计策略。连续细化过程细节层,通过逐步分解功能的宏观陈述(过程抽象)进行层次开发,直至最终到达程序设计语言的语句一致。
求精是一个细化的过程。
7.重构
一种重新组织的技术,可以简化构件的设计而无需改变其功能或行为。
8. 设计建模原则

  1. 设计应可追溯到需求模型。
  2. 始终考虑要构建系统的体系结构。
  3. 数据设计与处理功能设计同等重要。
  4. 接⼝(内部和外部)的设计必须谨慎。
  5. ⽤户界⾯设计应适应最终⽤户的需求。
  6. 构件级设计应在功能上独⽴。
  7. 构件应彼此松耦合,并应与外部环境松耦合。
  8. 设计表示(模型)应易于理解。
  9. 设计应迭代式开发。
  10. 设计模型的创建并不排除采⽤敏捷⽅法的可能性。
    八、体系结构
    1.体系结构
    提供了待构建软件的整体视图,描绘了软件构件的结构和组织形式,构件的性质及构件之间的链接。
  11. 构件
    通常来讲,构件是计算机软件中的⼀个模块化的构造块。
    系统中模块化的、可部署的和可替换的部件,该部件封装了实现并对外提供⼀组接⼝。
    3.敏捷性和体系结构
    将新的体系结构设计实践结合到敏捷开发过程至关重要,保证在不妨碍敏捷开发团队做出所需要决策的同时,给监管方和审计部分提供可验证的签收。
    4.体系结构风格
    施加在整个系统设计上的一种变换,目的是为系统中所有构件建立一个结构。
    4.1简单分类
    ①以数据为中心的体系结构
    ②数据流体系结构
    ③调用和返回体系结构
    ④面向对象的体系结构
    ⑤层次体系结构
    九、用户体验设计
    1.黄金规则
    Theo Mandel 关于界⾯设计提出的三条⻩⾦规则
  12. 把控制权交给⽤户
  13. 减轻⽤户的记忆负担
  14. 保持界⾯⼀致
    2.用户界面分析设计
    2.1模型
    工程师建立用户模型,软件工程师创建设计模型,最终用户在脑海里对界面产生印象,称为用户心理模型/系统感觉;系统实现者创建现实模型
    2.2过程
    用户界面分析和设计过程开始于螺旋模型内部并包括四个不同框架活动
    ①界面分析和建模
    ②界面设计
    ③界面构建
    ④界面验证
    3.UI图设计绘制
    十、软件测试
    1.软件测试
    1.1目的是发现错误。
    1.2步骤
    ①单元测试,侧重于单个构建,确保起到单元的作用
    ②集成测试 侧重于软件体系结构的设计和构建
    ③高阶测试
    ④确认测试 需求的最终保证
    ⑤系统测试 软件与系统的其他部分作为一个整体测试
    2.白盒测试
    也称玻璃盒测试、结构化测试。利用作为构件级设计的一部分描述的控制结构来生成测试用例。侧重于程序控制结构
    ①一个模块中的所有独立路径至少被执行一次
    ②对所有逻辑判定均需测试取真取假两方面
    ③在上下边界及可操作的范围内执行所有循环
    ④验证内部数据结构以确保有效性
    2.1基本路径测试
    保证第一条,利用程序图生成保证覆盖率的线性无关的测试集。
    2.2控制结构测试
    条件测试通过检查程序模块中包含的逻辑条件进行测试用例设计。
    数据流测试根据程序中变量的定义和使用位置来选择程序的测试路径。
    进一步检查程序逻辑
    循环测试侧重于循环构建的有效性(简单循环、嵌套循环)。检查不同复杂度的循环
    3.黑盒测试
    行为测试或功能测试,侧重于软件的功能需求。通过划分输入域和输出域来设计测试用例。
    ①不正确或遗漏的功能
    ②接口错误
    ③数据结构或外部数据库访问错误
    ④行为或性能错误
    ⑤初始化和终止错误
    白盒测试在测试过程早期执行,黑盒测试倾向于应用在测试的后期阶段。不考虑控制结构而是侧重于信息域。
    3.1接口测试
    集成测试的一部分,检查程序构建是否以正确的顺序和数据类型接受传递给它的信息并返回。
    3.2等价类划分
    将程序输入划分为若干个数据类,从中生成测试用例。
    3.3边界值分析
    选择一组测试用例检查边界值。在可接受的限度内处理边界数据的能力
    4.面向对象测试
    4.1类测试
    等价于单元测试,由封装在类中的操作和类的状态行为所驱动。
    4.2行为测试
    类的状态图可用于辅助生成检查类的动态行为的测试序列。
    十一、制定可行的软件计划
    1.估算
    制定计划。
    1.1影响因素
    ①项目的复杂性
    ②项目规模
    ③结构的不确定程度
    2.项目计划过程
    目标是提供一个能使管理人员对资源、成本、进度进行合理估算的框架。不确定性,实时更新。
    3.软件工程资源
    人员、可复用的软件构件、开发环境
    3.1人力资源
    评估软件范围、开发所需技能、指定职位和专业、开发工作量
    4.项目进度安排基本原则
    ①划分
    ②相互依赖性
    ③时间分配
    ④工作量确认
    ⑤确认责任
    ⑥明确输出结果
    ⑦确认里程碑
    十二、软件风险
    1.什么是风险
    风险是关系到未来的事件,涉及选择具有不确定性、损失性。
    技术债务 项目风险、技术风险、商业风险
相关推荐
rolt1 天前
长得像用例图的类图-《软件方法》8.2.3.4
软件工程·uml·面向对象
阿萨姆.3572 天前
结对编程 --- 软件工程
java·软件工程·结对编程
写代码的橘子n2 天前
软件工程笔记一
笔记·软件工程
思茂信息2 天前
CST汽车天线仿真(双向混合求解)
javascript·人工智能·5g·汽车·ar·软件工程
幸运超级加倍~2 天前
软件设计师-上午题-12、13 软件工程(11分)
笔记·软件工程
晓北斗NorSnow2 天前
在软件工程开发中,瀑布式开发和螺旋式开发的优缺点比较
软件工程
zk计科小牛马3 天前
软件工程(软考高频)
软件工程
蜗牛学苑_武汉3 天前
浏览器中的事件循环
前端·javascript·chrome·ajax·软件工程·html5
诗和远方ya5 天前
c# 值类型
开发语言·c#·软件工程·visual studio
张瑞东6 天前
系统架构设计师-未来信息综合技术(2)
系统架构·软件工程