软考-系统架构设计师-第七章 软件工程基础知识
软件工程基础知识
- 软件工程
- 7.2需求工程
- 7.3系统分析与设计
- 7.4 软件测试
- 7.5 净室软件工程
- 7.6 基于构件的软件工程
- 7.7 软件项目管理
软件工程
(1)软件危机(Software Crisis)。具体表现为:软件开发进度难以预测、软件开发成本难以控制、软件功能难以满足用户期望、软件质量无法保证、软件难以
维护和软件缺少适当的文档资料。
(2)软件过程模型。软件要经历从需求分析、软件设计、软件开发、运行维护,直至被淘汰这样的全过程,这个全过程就是软件的生命周期。
常见的软件过程模型主要包括:
-
- 瀑布模型(Waterfall Model)是结构化开发方法使用的软件过程模型。瀑布模型的特点还是因果关系相连,前一个阶段的工作的输出结果,是后一个阶段的输入。
每一个阶段工作完成后都是伴随着一个里程碑。缺点是需求难以一次确定、变更的代价高、结果难以预见、各阶段不能并行。
- 瀑布模型(Waterfall Model)是结构化开发方法使用的软件过程模型。瀑布模型的特点还是因果关系相连,前一个阶段的工作的输出结果,是后一个阶段的输入。
-
- 原型模型(Prototype Model)又称快速原型,是原型方法使用的生命周期模型。原型模型解决了瀑布模型需求难以一次确定、结果难以预见的缺点。原型模型
有原型开发和目标软件开发两个阶段。抛弃型原型将原型作为需求的确认的手段,在需求确认结束后就被抛弃不用,继续用瀑布模型,演化型原型在需求确认结束后,
不断补充和完善原型,直至形成一个完整的产品。
- 原型模型(Prototype Model)又称快速原型,是原型方法使用的生命周期模型。原型模型解决了瀑布模型需求难以一次确定、结果难以预见的缺点。原型模型
-
- 螺旋模型(Spiral Model)是在快速原型的基础上结合瀑布模型扩展而成。把整个软件的开发流程分成多个阶段,每一个阶段那都由
目标设定、风险分析、
开发和有效性验证、评审4部分组成。支持大型软件开发,适用于面向规格说明、面向过程和面向对象的软件开发方法,强调其他模型忽略的
风险分析。
- 螺旋模型(Spiral Model)是在快速原型的基础上结合瀑布模型扩展而成。把整个软件的开发流程分成多个阶段,每一个阶段那都由
-
- 敏捷模型(Agile Model)敏捷模型主要有极限编程(Extreme Programming,XP)、水晶系列方法、并列争球法(Scrum)、特征驱动开发方法(Feature
Driven Development,FDD)等具体符敏捷方法,这些方法的显著特征如下:
- 极限编程(XP):高效、低风险、测试先行(先写测试代码,再写程序代码)
- 水晶系列方法: 不同的项目,采用不同的策略
- 并列争球法(Scrum):该方法侧重于项目管理。Scrum包含一系列实践和预定义角色的过程骨架(是一种流程、计划、模式,用于有效率低开发软件),产品的Backlog
是一个按照商业价值排序的需求列表,根据Backlog的内容,将整个开发过程分为若干个短的迭代周期(Sprint),在Sprint中,Scrum团队从Backlog中挑选
最高优先级的需求组成Sprint Backlog。在每个迭代结束时,Scrum团队将递交可交付的产品增量。当所有Sprint结束时,团队提交最终的软件产品。 - 特征驱动开发方法:该方法把开发人员分类,分为指挥者(首席程序员)、类程序员等。
- 敏捷模型(Agile Model)敏捷模型主要有极限编程(Extreme Programming,XP)、水晶系列方法、并列争球法(Scrum)、特征驱动开发方法(Feature
-
- 软件统一过程(Rational Unified Process,RUP)模型。RUP是一种重量级过程模型,属于构建化开发使用的软件过程模型。其生命周期是一个二维软件开发模型
,划分为多个循环(Cycle),每个循环生成产品的一个新版本,每个循环依次由初始、细化、构造和移交
4个连续的阶段(Phase)组成,每个阶段完成确定的任务。
RUP中有9个核心工作流,分别是:业务建模、需求、分析和设计、实现、测试、部署、配置与变更管理、项目管理、环境。RUP的特点是
用例驱动的、 以架构为中心的、 迭代和增量的软件开发过程。
RUP用4+1视图模型来描述架构 用例视图、逻辑视图、实现视图、进程视图、部署视图
- 逻辑视图:对应最终用户,主要支持功能性需求,即在为用户提供服务方面系统所应该提供的功能。逻辑视图常用类图、对象图、状态图、协作图表示。
- 实现视图:又称为开发视图,对应程序员,关注软件开发环境下实际模块的组织,描述系统的各个部分如何组织为模块和组件即开发环境中的静态组织
结构。该视图通常包含包图和组件图。 - 进程视图(过程视图) ,对应系统集成人员,考虑一些非功能性的需求,如性能和可用性,他可以解决并发性,分布性,系统完整性、容错性的问题。进程视图常用
活动图表示。 - 部署视图。又叫物理视图,对应系统工程师。描述如何将起那三个视图所描述的系统实现为一组现实世界的实体。展示了如何把如那件映射到硬件上,它通常要考虑
到系统性能、规模、可靠性等。解决系统拓扑结构、系统安装、通信等问题。部署视图常用部署图表示。 - 用例视图:所有其他视图都依靠用例视图(场景)来指导他们。
- 软件统一过程(Rational Unified Process,RUP)模型。RUP是一种重量级过程模型,属于构建化开发使用的软件过程模型。其生命周期是一个二维软件开发模型
RUP在每次迭代中,只考虑系统的一部分需求,进行分析、设计、实践、测试和部署等过程。
(3)软件能力成熟度模型(Capability Maturity Model for Software, CMM)。CMM是一个概念模型,模型框架和表示是刚性的,不能随意改变,
但模型的解释和实现有一定的弹性。
(4)软件能力成熟度模型集成(Capability Maturity Model Integration for Software,CMMI)提供了一个软件能力成熟度的框架,它将软件过程改进
的步骤组织成5个成熟度等级: 初始级、已管理级、已定义级、量化管理级、优化级。
7.2需求工程
- 软件需求的层次
- (1)业务需求(Business Requirement),反映了组织机构或客户对系统、产品高层次的目标要求。
- (2)用户需求(User Requirement),描述了用户使用产品必须要完成的任务,是用户对该软件产品的期望。业务需求和用户需求构成了用户原始需求文档的内容。
- (3)功能需求(functional requirement),从系统操作的角度定义了开发人员必须实现的软件功能,来满足业务需求和用户需求。
- 需求工程(Requirement Engineering, RE)
需求工程由需求获取、需求分析、形成需求规格(需求文档化)、需求确认与验证、需求管理5个阶段组成。 - 软件需求规格说明书(Software Requirement Specification, SRS)
SRS具体包含功能需求、非功能需求和约束。约束包括设计约束和过程约束。批准的SRS是需求开发和需求管理之间的桥梁。 - 需求管理
需求管理是一个系统需求变更、了解和控制的过程,包括变更控制、版本控制、需求跟踪等活动。 - 需求获取
需求获取是获取系统必要的特征,或者是获得用户能接受的、系统必须满足的约束。需求获取的基本步骤:
- (1)开发高层的业务模型
- (2)定义项目范围和高层需求
- (3)识别用户角色和用户代表
- (4)获取具体的需求
- (5)确定目标系统的业务工作流
- (6)需求整理与总结
需求获取的方法包括用户面谈、需求专题讨论会、问卷调查、现场观察、原型化方法和头脑风暴法等。
-
需求变更
-
变更控制委员会(Change Control Board, CCB)
过程及操作步骤为制定决策、交流情况、重新协商约定。 -
需求跟踪
需求跟踪提供了由需求到产品实现整个过程范围的明确查阅的能力。需求跟踪的目的是建立与维护“需求-设计-编程-测试”之间的一致性。确保所有的工作成果符合用
户需求。需求跟踪有正向跟踪和逆向跟踪两种方式,合称双向跟踪。不论采用何种跟踪方式,都要建立与维护需求跟踪矩阵。
7.3系统分析与设计
- 结构化方法(Structured Analysis and Sturcturted Design,SASD)
结构化方法又称为面向功能的软件开发方法或面向数据流的软件开发方法。针对软件生命周期各个不同阶段,有结构化分析、结构化设计和结构化编程等方法。
-
- 结构化分析(Structured Analysis, SA)。SA利用图形表达用户需求中的功能需求,使用的主要手段主要有数据流图(Data Flow
Diagram,DFD)数据字典、结构化语言、判定表以及判定树等。
数据流图(DFD)由4种基本元素组成:数据流、处理/加工、数据存储和外部项。
结构化分析具体的建模过程及步骤为明确目标、确定系统范围、建立顶层DFD图、构建第一层DFD分解图、开发DFD层次结构图、检查确认DFD图。DFD图需要满足规则:
父图数据流必须在子图中出现:一个处理至少有一个输入流和一个输出流;一个存储必定有流入和流出;一个数据流至少有一端是处理端;模型表达的信息是全面的、
完整的、正确的和一致的。
数据字典(Data Dictionary)是一种标记用户可以访问的数据项和元数据的目录,是对系统中使用的所有数据元素定义的集合,包括数据项、数据结构、数据流、
数据存储和处理过程。
- 结构化分析(Structured Analysis, SA)。SA利用图形表达用户需求中的功能需求,使用的主要手段主要有数据流图(Data Flow
-
- 结构化设计(Structured Design, SD)。SD是一种面向数据流的设计方法,以SRS和SA阶段所产出的数据流图和数据字典等文档为基础,是一种
自顶向下、逐步求精和模块化的过程。SD分为概要设计和详细设计两个阶段,其中概要设计的主要任务是确定软件系统的结构,对系统进行模块划分,
确定每个每个模块的功能、接口和模块之间的调用关系;详细设计的主要任务是为每个模块设计实现细节。在SD中,模块是实现功能的基本单位,一般具有
功能、逻辑和状态3个基本属性。
耦合表示模块之间联系的程度
- 结构化设计(Structured Design, SD)。SD是一种面向数据流的设计方法,以SRS和SA阶段所产出的数据流图和数据字典等文档为基础,是一种
耦合类型 | 描述 |
---|---|
非直接耦合 | 两个模块之间没有直接关系,互向不依赖对方 |
数据耦合 | 一组模块借助参数传递简单数据 |
标记耦合 | 一组模块通过参数表传递记录等复杂信息(数据结构) |
控制耦合 | 模块之间传递的信息包含用于直接控制模块内部逻辑的信息 |
通信耦合 | 一组模块共享了输入或输出 |
公共耦合 | 多个模块都访问同一个公共数据环境,公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等 |
内容耦合 | 一个模块直接访问另外一个模块的内部数据、一个模块不通过正常入口乔传到另外一个模块的内部、两个模块有一部分代码重叠、一个模块有多个入口等 |
内聚表示模块内部各代码成分之间联系的紧密程度,内聚度从高到底
内聚类型 | 描述 |
---|---|
功能内聚 | 各个部分系统完成一个单一功能,缺一不可 |
顺序内聚 | 处理元素相关,而且必须顺序执行,通常迁移任务的输出是后一任务的输入 |
通信内聚 | 所有处理元素集中在一个数据结构的区域上 |
过程内聚 | 处理元素相关,而且必须按特度部分的次序执行 |
时间内聚 | 所包含的任务必须在同一时间间隔内执行 |
逻辑内聚 | 完成逻辑上相关的一组任务,互向存在调用关系 |
偶然内聚 | 完成一组没有关系或松散关系的任务,或者仅仅代码相似 |
模块分解中应遵循高内聚、低耦合的设计原则。
概要设计使用系统结构图(Structure Chart,SC),又称为模块结构图,反映了系统的总体结构。详细设计的主要任务是设计每个模块的实现算法、所需的局部
数据结构。详细设计的表示工具有图形工具表格工具和语言工具。图形有业务流图、程序流程图、问题分析图(Problem Analysis
Diagram,PAD)、NS流程图等。
-
- 结构化编程(Structured Programming,SP)。SP通过顺序、分支和循环三种基本的控制结构可以构造出任何单入口单出口的程序。SP强调:自顶向下,
逐步细化;清晰第一,效率第二;书写规范,缩进规范;基本结构,组合而成。P原则;程序=(算法)+(数据结构)。两者分开设计,以算法(函数或过程)为主。
- 结构化编程(Structured Programming,SP)。SP通过顺序、分支和循环三种基本的控制结构可以构造出任何单入口单出口的程序。SP强调:自顶向下,
-
- 数据库设计(概念结构设计部分)。概念结构设计建立抽象的概念数据模型,通常采用实体-联系图(Entity Relationship,E-R图)来表示。
- 面向对象(Object-Oriented,OO)方法
面相对象的方法可以分为:
-
- 面向对象的分析方法(Object-Oriented Analysis,OOA)。OOA模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动
(标识对象类、 标识结构、定义主题、定义属性和定义服务)组成
- 面向对象的分析方法(Object-Oriented Analysis,OOA)。OOA模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动
OOA的基本原则有抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制和行为分析。 OOA的5个基本步骤:确定对象和类、确定结构、确定主题、确定
属性、确定方法。
-
- 面向对象设计方法(Object-Oriented Design,OOD)。在OOD中,数据结构和在数据结构上定义的操作算法封装在一个对象之中。类封装了信息和行为,
是具有相同属性、方法和关系的对象集合的总称。类可以分为3种类型:
-
- 实体类:一般来说就是一个名词,通常都是永久性需要存储的。
-
- 控制类: 是用于控制用例工作的类,控制对象(控制类的实例)通常控制其他对象或者协调其他对象的行为,例如登录验证。
-
- 边界类: 用于封装在用例内、外流动的信息或数据流,例如窗口、通信协议、接口等。
- 面向对象设计方法(Object-Oriented Design,OOD)。在OOD中,数据结构和在数据结构上定义的操作算法封装在一个对象之中。类封装了信息和行为,
-
- 面向对象设计(Object-Oriented Programming, OOP).OOP以对象为核心,该方法认为程序由一系列对象组成。OOP的基本特点有封装、继承和多态。
封装是指将一个计算机系统中的数据以及与这个数据相关的一切操作组装到一起。继承是指一个对象针对另一个对象的某些独有特点、能力进行复制或者延续。继承
分为4类,分别是取代继承、包含继承、受限继承和特化继承。多态是指同一操作作用于不同对象,可以产生不同的结果。
- 面向对象设计(Object-Oriented Programming, OOP).OOP以对象为核心,该方法认为程序由一系列对象组成。OOP的基本特点有封装、继承和多态。
-
- 数据持久化与数据库。永久保存对象状态,需要进行对象的持久化(Persistence)
- 其他设计方法
其他设计方法如构件与软件重用。软件重用是使用已有的软件产品来开发新的软件系统的过程,分为水平式重用和垂直式重用两种类型。
名称 | 对象 | 举例 |
---|---|---|
水平式重用 | 不同应用领域中的软件元素 | 标准函数库 |
垂直式重用 | 共性应用领域间的软部件 | 区块链 |
- 逆向工程(Reverse Engineering)
逆向工程是通过分析已有的程序,寻求比源代码更高级的抽象表现形式(比如文档)的活动,是在不同抽象层级中进行的溯源行为。
逆向工程得出的设计称为设计恢复(Design Recovery),但不一定能够抽象还原到原设计。
重构(Restructuring)是在同一抽向层中转换系统描述的活动。对逆向工程所形成的系统进行修改或重构,生成新版本称为重构工程。
逆向工程信息恢复级别如下表:
级别 | 内容 | 抽象级别 | 逆向工程恢复难度 | 工具支持可能性 | 人工参与程度 |
---|---|---|---|---|---|
实现级 | 语法树、符号表 | 递增 | 递增 | 递减 | 递增 |
结构级 | 程序分量间的关系,如调用图 | 递增 | 递增 | 递减 | 递增 |
功能级 | 功能和程序段之间的关系 | 递增 | 递增 | 递减 | 递增 |
领域级 | 实体与应用域之间的关系 | 递增 | 递增 | 递减 | 递增 |
7.4 软件测试
- 测试分类
-
- 根据程序执行状态可以分为静态测试(Static Testing,ST)和动态测试(Dynamic Testing,DT)。
-
- 根据是否关注具体实现和内部结构可以分为黑盒测试、白盒测试和灰盒测试
-
- 根据程序执行的方式来分类可以分为人工测试(Manual Testing,MT)和自动测试(Automatic Testing,AT)。
-
- 从阶段上划分,软件测试可以分为单元测试、集成测试、系统测试、验收测试。
7.5 净室软件工程
净室软件工程(CLeanroom Software Engineering,CSE)是一种在软件开发过程汇总强调在软件中建立正确性的需要的方法。CSE的理论基础主要是函数理论
和抽样理论。CSE使用盒子结构规约进行分析和设计建模,并且强调将正确性验证(而不是测试)作为发现和消除错误的主要机制,可以生成质量非常高的软件。
CSE的缺点是太理论化、忽视测试、带有传统软件工程的弊端。
7.6 基于构件的软件工程
- 定义
基于构件的软件工程(Component-Based Software Engineering,CBS)是一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。
用于CBSE的构件应该具备以下特征:
-
- 可组装性: 所有的外部交互必须通过公开定义的接口进行。
-
- 可部署性:必须能作为一个独立实体在提供其构建模型实现构件平台上运行。
-
- 文档化: 构件必须是完全文档化的 。
-
- 独立性: 构件应该是独立的,如确实需要其他构件提供服务,则应显示声明。
-
- 标准化: 必须符合某种标准化的构件模型。
- 构件模型
构件模型定义了构件实现、文档化以及开发的标准。目前主流的构件模型是Web Services模型、Sun公司的EJB模型和微软公司的.NET模型。构件模型包含了一些模型
要素如接口、使用信息和部署信息。构件模型提供给了一组被构件使用的通用服务,包括平台服务和支持服务
。容器是构件模型基础设施,是支持服务的一个实现
加上一个接口定义,构件必须提供该接口定义以便和容器整合在一起。 - CBSE过程
支持基于构件组装的软件开发过程主要包括:
-
- 系统需求概览
-
- 识别候选构件
-
- 根据发现的构件修改需求
-
- 体系结构设计
-
- 构件定制与适配
-
- 组装构件,创建系统。
CBSE过程与传统软件开发过程的不同点:
-
- 早期需要完整的需求,以便尽可能多的识别出来可以复用的构件。
-
- 早期阶段根据可利用到构件来细化和修改需求以匹配CBSE
-
- 架构设计完成后,可能需要修改构件以适合功能和架构的需求
-
- 开发过程技术组装构件的过程,有时需要开发适配器
-
- CBSE中的机构设计阶段特别重要,决定和限制了可选构件的范围。
- 构件组装
常见的的构件组装有顺序组装、层次组装和叠加组装3种组装方式。构件组装可能面临接口不兼容的问题,常见的有*
参数不兼容、操作不兼容和操作不完备*
3种。这个时候需要编写适配器来解决不兼容的问题。
7.7 软件项目管理
- 软件进度管理一般包括活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划和进度控制6个过程。
- 工作分解结构(Work Breakdown Structure,WBS)是把一个项目,按一定的原则分解成任务,任务在分解成一项项工作,再把一项项工作分配到每个人的
活动中,直到分解不下去为止。以可交付成果为导向,对项目要素机械能分组,总是处于计划过程的中心。 - 活动定义是指确定完成项目的各个交付成功所必须进行的各项具体活动,还需要明确每个活动的前驱、持续时间、必须完成日期、里程碑或可交付成果。
- 任务活动图是项目的进展管理、项目的成本管理等一些列项目管理活动地基础,通常采用甘特图等方式来展示和管理项目活动
- 软件配置管理(Software Configuration Management,SCM)是一种标识、组织和控制修改的技术。SCM的目的是使错误率降为最小并最有效率的提高
生产效率。SCM和核心内容包括版本控制和变更控制。版本控制(Version Control)是指对软件开发过程中各种文件变更的管理最主要的功能就是追踪和记录文件变更、
并行开发。变更控制(Change Control)是指对变更进项管理,确保变更有序进行。 - 软件质量管理。软件质量就是软件与明确地和隐含地定义的需求相一致的程度。软件质量保证(Software Quality Assurance,SQA
)的目的是使软件过程
对于管理人员是可见的。
SQA的主要任务是:
-
- SQA审计与评审
-
- SQA报告
-
- 处理不符合问题
软件质量认证,国内主要采用的是 ISO 9001 和CMM
- 软件风险管理。软件项目风险是指在软件开发过程中遇到的预算和进度等方面的问题以及这些问题对项目的影响。风险管理的主要目标是预防风险,以及应对发生的
风险。风险管理活动可以 分为:
-
- Bochm把风险管理活动分为风险评估(风险辨识、风险分析、风险排序)和风险控制(风险管理计划、风险处理、风险监督)两大阶段。
-
- Charette把风险分为分析(辨识、估计、评价)和管理(计划 、控制、监督)两大阶段