安派尔

软考系统架构设计师(4)-软件工程基础知识

2025/07/19
0
0

软考系统架构设计师(4)-软件工程基础知识

软件工程

软件危机:

  • 软件开发进度难以预测
  • 软件开发成本难以控制
  • 软件功能难以满足用户期望
  • 软件质量无法保证
  • 软件难以维护
  • 软件缺少适当的文档资料

1.软件过程模型

  • 瀑布模型:特点是因果关系紧密相连,前一个阶段工作的输出结果,是后一个阶段工作的输入,每一个阶段都是建筑在前一个阶段正确实施的结果之上,每一个阶段工作完成后都伴随着一个里程碑(一组检查条件),对该阶段的工作进行审查和确认;缺点是软件需求的完整性、正确性难以确定,变更代价高,结果难以预见,各阶段不能并行工作
    img

  • 原型模型:也称快速原型,在解决瀑布模型需求难以一次确定、结果难以预见的问题上提出,主要包含原型开发阶段和目标软件开发阶段,分抛弃型原型和演化型原型

    • 抛弃型原型:将原型作为需求确认的手段,在需求确认结束后,原型就被抛弃不用
    • 演化型原型:在需求确认结束后,不断补充和完善原型,直至形成一个完整的产品
      img
  • 螺旋模型:在快速原型的基础上结合瀑布模型扩展而成,把整个软件开发流程分多个阶段,每一个阶段都由

    目标设定、风险分析、开发和有效性验证、评审

    组成,强调其他模型忽视的

    风险分析

    • 目标设定:为项目进行需求分析,定义和确定目标,指定对过程和产品的约束,并制定详细的管理计划
    • 风险分析:对可选方案进行风险识别和详细分析,制定解决方案,采取有效措施避免风险
    • 开发和有效性验证:风险评估后,选择开发模型并进行原型开发,即开发软件产品
    • 评审:对项目进行评审,以确定是否进入螺旋的下一个回路

2.敏捷模型:
特点:

  • 敏捷型方法是“适应性”而非“预设性”的
  • 敏捷型方法是“面向人的”而非“面向过程的”

核心思想:

  • 敏捷方法是适应型的,而非可预测型
  • 敏捷方法是以人为本,而非以过程为本
  • 迭代增量式的开发过程

主要敏捷方法

  • 极限编程(Extreme Programming,XP):轻量级、灵巧的软件开发方法,基础和价值观是交流、朴素、反馈、勇气;即软件项目可以从4个方面进行改善:加强交流;从简单做起;寻求反馈;勇于实事求是。近似螺旋式的开发方法,将复杂开发过程分解为一个个相对简单的小周期,通过积极的交流、反馈以及其他一系列方法,项目成员可以清楚开发进度、变化、待解决的问题和潜在的困难,并根据情况进行调整
  • 水晶系列方法:不同的项目采用不同的策略
  • 并列争球法(scrum):侧重项目管理
  • 特征驱动开发方法(Feature Driven Development,FDD):软件开发需要3个要素:人、过程、技术;分项目经理、首席架构设计师、开发经理、主程序员、程序员、领域专家6中项目角色;有开发整体对象模型、构造特征列表、计划特征开发、特征设计、特征构建5个核心过程

3.统一过程模型(Rational Unified Process,RUP):

  • RUP生命周期:
    • 业务建模:理解待开发系统
    • 需求:定义系统功能及用户界面,使客户知道系统的功能,开发人员理解系统需求
    • 分析与设计:把需求分析的结果转化为分析与设计模型
    • 实现:把设计模型转换为实现结果
    • 测试:检查各子系统之间的交互、集成,验证所有需求是否正确实现
    • 部署:打包、分发、安装软件;培训用户及销售人员;提供技术支持
    • 配置与变更管理:跟踪并维护系统开发过程中产生的所有制品的完整性和一致性
    • 项目管理:为软件开发项目提供计划、人员分配、执行、监控等方面的指导
    • 环境:为软件开发机构提供软件开发环境

RUP把软件开发生命周期划分为多个循环,每一个循环产生一个新的版本,每个循环分4个阶段组成
– 初始阶段:定义最终产品视图和业务模型,并确定系统范围
– 细化阶段:设计及确定系统的体系结构,制订工作计划及资源要求
– 构造阶段:构造产品并继续演进需求、体系结构、计划直至产品提交
– 移交阶段:把产品提交给用户使用

每个阶段结束前有一个里程碑评估该阶段的工作,如未能通过里程碑的评估,则需要决定是取消该项目还是继续做该阶段的工作

  • 核心概念

    • 角色(Role):Who的问题,角色描述某个人或一个小组的行为与职责;RUP预定义了如体系结构师、设计人员、实现人员、测试员、配置管理人员等角色,并对每一个角色的工作和职责做了详尽的说明
    • 活动(activity):How的问题,活动是一个有明确目的的独立工作单元
    • 制品(Artifact):What的问题,制品是活动生成、创建或修改的一段信息。
    • 工作流(Workflow):When的问题,工作流描述了有意思的连续的活动序列,每个工作流产生一些有价值的产品,并显示角色之间的关系
  • RUP特点

    RUP是利用驱动的、以体系结构为中心的、迭代和增量的软件开发过程过程

    • 用例驱动:开发活动是用例驱动的,需求分析、设计、实现、测试等活动都是用例驱动的

    • 以体系结构为中心:4+1视图模型

      • 用例视图:分析人员和测试人员关心的是系统的行为
      • 逻辑视图:最终用户关心的是系统的功能
      • 实现视图:程序员关心的是系统的配置、装配等问题
      • 进程视图:系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题
      • 部署视图:系统工程师关心的是系统的分布、安装、拓扑结构等问题
    • 迭代与增量:RUP强调采用迭代和增量的方式来开发软件,把项目开发分为多个迭代过程,在每次迭代中,只考虑系统的一部分需求,进行分析、设计、实现、测试和部署等过程

4.软件能力成熟度模型(CMM)
软件能力成熟度模型集成(Capability Maturity Model Integration for Software,CMMI)在CMM的基础上发展而来,分5个成熟度:

  • Level 1 初始级:过程随意且混乱,依赖组织内人员的能力和英雄主义
  • Level 2 已管理级:组织要确保策划、文档化、执行、监督和控制项目级的过程,并需要为过程建立明确的目标
  • Level 3 已定义级:能根据自身的情况定义适合企业和项目的标准流程,将遮套管理系统和流程予以制度化
  • Level 4 量化管理级:组织建立产品质量、服务质量以及过程性能的定量目标,与前一级区别在于对过程性能的可预测
  • Level 5 优化级:关注通过增量式的与创新式的过程与技术改进,不断地改进过程性能

需求工程

软件需求包含3个不同层次:

  • 业务需求:反应了组织机构或客户对系统、产品高层次的目标要求
  • 用户需求:描述了用户使用产品必须要完成的任务,是用户对该软件产品的期望
  • 功能需求:定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足业务需求

需求工程:应用已证实有效的原理、方法,通过合适的工具和记号,系统地描述待开发系统及其行为特征和相关约束,分需求获取、需求分析、形成需求规格(需求文档化)、需求确认与验证、需求管理5个阶段。
需求管理的主要活动分变更控制、版本控制、需求跟踪、需求状态跟踪

1.需求获取
基本步骤:

  • 开发高层的业务模型
  • 定义项目范围和高层需求
  • 识别用户角色和用户代表
  • 获取具体的需求
  • 确定目标系统的业务工作流
  • 需求整理与总结

获取方法

  • 用户面谈
  • 需求专题讨论会
  • 问卷调差
  • 现场观察
  • 原型化方法
  • 头脑风暴法

2.需求变更
变更控制过程

Snipaste_2025-08-18_15-02-36-768x257.png

  • 问题分析和变更描述:当提出变更提议后,需要对该提议做进一步的问题分析,检查有效性,产生更明确的需求变更提议
  • 变更分析和成本计算:接受变更提议后,对提议进行影响分析和评估
  • 变更实现:确定执行变更后,按照开发模型执行相应的变更

变更控制委员会:是项目所有者权益代表,负责裁定接受哪些变更,通常由用户和实施方的决策人员组成,主要工作是通过评审手段来决定项目是否能变更,但不提出变更方案。过程和操作步骤为制定决策、交流情况、重新协商约定

3.需求跟踪
两种方式:

  • 正向跟踪:检查《产品需求规格说明书》中的每个需求是否都能在后继的工作成果中找到对应点
  • 逆向跟踪:检查设计文档、代码、测试用例等工作成果是否都能在《产品需求规格说明书》找到出处

建立和维护需求跟踪矩阵来保存需求与后继工作成果的对应关系

系统分析与设计

1.结构化方法
针对软件生存周期各个不同的阶段,由结构化分析(SA)、结构化设计(SD)、结构化编程(SP)等方法

结构化分析:给出一组帮助系统分析人员产生功能规约的原理与技术,一般利用图形表达用户需求,使用的手段主要数据流图、数据字段、结构化语言、判定表以及判定树
结构化分析常用的手段是数据流图(Data Flow Diagram,DFD)和数据字典
数据流图4个基本元素

  • 数据流:数据流用一个箭头描述数据的流向,箭头上标注的内容可以是信息说明或数据项
  • 处理:表示对数据进行的加工和转换,在图中用矩形框表示,指向处理的数据流为该处理的输入数据,离开处理的数据流为该处理的输出数据
  • 数据存储:表示用数据库形式存储的数据,对其进行的存取分别以指向或离开数据存储的箭头表示
  • 外部项:数据源或数据终点,描述系统数据的提供者或者数据的使用者

建模过程及步骤:

  • 明确目标,确定系统范围
  • 建立顶层DFD图
  • 构建第一层DFD分解图
  • 开发DFD层次结构图
  • 检查确认DFD图
    img
    数据流图具体规则:
    父图中描述过的数据流必须要在相应的子图中出现;
    一个处理至少有一个输入流和一个输出流;
    一个存储必定有流入的数据流和流出的数据流;
    一个数据流至少有一端是处理端;
    模型图中表达和描述的信息是全面的、完整的、正确的、一致的

数据字典:一种用户可以访问的记录数据库和应用程序元数据的目录,对数据的数据项、数据结构、数据流、数据存储、处理逻辑等进行定义和描述,包括数据项、数据结构、数据流、数据存储和数据处理

结构化设计(SD):面向数据流的设计方法,以SRS(需求规格说明书)和SA(结构化分析)阶段所产生的数据流图和数据字典等文档为基础,是自顶向下、逐步求精、模块化的过程;分概要设计和详细设计两个阶段
概要设计的主要任务是确定软件系统的结构,对系统进行模块划分,确定每个模块的功能、接口和模块之间的调用关系;
详细设计主要任务是为每个模块设计实现的细节

模块结构

  • 信息隐藏与抽象:信息隐藏原则要求采用封装技术,将程序模块的实现细节隐藏起来,模块外部智只能使用模块接口说明中给出的信息;抽象原则要求抽取事物最基本的特性和行为,忽略非本质的细节,包括过程抽象、数据抽象、控制抽象
  • 模块化:模块是实现功能的基本单位,一般具备功能、逻辑、状态3个基本属性,描述模块时,需要分别描述外部特性与内部特性;外部特性指模块名、参数表等,内部特性指完成其功能的程序代码和仅供内部使用的数据
  • 耦合:表示模块之间的联系程度
    Snipaste_2025-08-18_17-15-18-768x277.png
    速记:无直接联系的数据标记,却控制着外部(通信)的公共内容
  • 内聚:表示模块内部各代码成分之间联系的紧密程度,从功能角度来度量模块内的联系
    Snipaste_2025-08-18_17-19-01-768x247.png
    速记:偶然发现一个逻辑,时间和过程是可以通信的,按顺序完成一个功能

在模块的分解中尽量减少模块的耦合,力求增加模块的内聚,遵循“高内聚、低耦合”的设计原则

系统结构图(Structure Chart,SC)
详细设计的主要任务是设计每个模块的实现算法、所需的局部数据结构,两个目标:实现模块功能的算法要逻辑上正确和算法描述要简明易懂
设计步骤:

  • 分析并确定输入/输出数据的逻辑结构
  • 找出输入数据结构和输出数据结构中有对应关系的数据单元
  • 按一定的规则由输入、输出的数据结构导出程序结构
  • 列出基本操作与条件,并把它们分配到程序结构图的适当位置
  • 用伪码写出程序

详细设计的表示工具有图形工具、表格工具和语言工具

  • 图形工具
    • 程序流程图:结构清晰,易于理解,易于修改;但只能描述执行过程而不能描述有关的数据
      img
    • NS流程图:也称盒图,一种强制使用结构化构造的图示工具,功能域明确、不能任意转移控制,易于确定局部和全局数据的作用域
      img
    • PAD图:一种改进的图形描述方式,可以取代程序流程图,比程序流程图直观,结构清晰
      img
  • 表格工具:可以用一张表来描述过程的细节
  • 语言工具
    • PDL:伪码伪代码
      • 优点:可以作为注释直接插在源程序中,可以使用普通的文本编辑工具产生和管理,使用自动处理程序将PDL生成代码程序
      • 缺点:不如图形工具形象直观,描述复杂的条件组合与动作间对应关系时,不如判定树清晰简单

结构化编程(Structure Programming,SP)
结构化程序设计采用自顶向下、逐步求精的设计方法,各个模块通过“顺序、选择、循环”的控制结构进行连接,程序设计的原则可表示为:程序=算法+数据结构。算法与数据结构是独立的整体,两个可以分开设计,以算法为主;归纳为32字原则:自顶向下、逐步细化;清晰第一、效率第二;书写规范、缩进格式;基本结构、组合而成

数据库设计
概要结构设计是对用户要求描述的现实世界,通过对其中实体事物的分类、聚集和概括,建立抽象的概念数据模型,采用E-R图表示,E-R图成分如下:

  • 实体:采用矩形框表示,客观上可以相互区分的事物就是实体,实体可以是具体的人和物,也可以是抽象的概念与联系
  • 属性:采用椭圆形框表示,实体所具有的某一特性
  • 联系:采用菱形框表示,信息世界中反映实体内部或实体之间的关联关系

3种一般性约束:一对一约束、一对多约束、多对多约束

E-R图作图步骤:

  • 确定所有的实体集合
  • 选择每个实体集应该包含的属性
  • 确定实体集之间的联系
  • 确定实体集的关键字,用下画线在属性上表明关键字的属性组合
  • 确定联系类型,用线将表示联系的菱形框联系到实体集时,在线旁注明是1或n来表示联系的类型

img

2.面向对象方法
1)面向对象分析(OOA)
OOA模型的5个层次和5个活动
5个层次:主题层、对象类层、结构层、属性层、服务层
5个活动:标识对象类、标识结构、定义主题、定义属性、定义服务
分类结构:一般与特殊的关系
组装结构:对象之间整体与部分的关系

OOA原则:

  • 抽象、封装、继承、分类、聚合、关联、消息通信、粒度控制、行为分析

5个基本步骤:

  • 确定对象和类
  • 确定结构
  • 确定主题
  • 确定属性
  • 确定方法

2)面向对象设计(OOD)
类分3种类型:实体类、控制类、边界类

  • 实体类:实体类映射需求中的每个实体,是指实体类保存需要存储在永久存储体中的信息,一定有属性,但不一定有方法
  • 控制类:用于控制用例工作的类,一般由动宾短语转换的名词,控制类没有属性,但一定由方法
  • 边界类:用于封装在用例内、外流动的信息或数据流;位于系统与外界的交接处,如窗体、报表、打印机等接口,既有属性也有方法

3)面向对象编程(OOP)
基本特点:封装、继承、多态
继承分多继承和单继承;分取代继承、包含继承、受限继承、特化继承

软件测试

1.测试方法
以测试过程中程序是否在执行状态分静态测试、动态测试
以具体实现算法细节和系统内部情况分黑盒测试、白盒测试、灰盒测试
从程序执行的方式分人工测试、自动化测试

  • 静态测试:被测程序不运行,只依靠分析或检查源程序的语句、结构、过程来检查程序是否有错误
  • 动态测试:通过运行被测程序,对得到的运行结果与预期的结果进行比较分析,同时分析运行效率和健壮性能等,分3个步骤:构造测试实例、执行程序、分析结果
  • 黑盒测试:将被测程序看成一个黑盒,工作人员不考虑程序内部结构和特性,通过测试实例检查程序的功能是否正确
  • 白盒测试:主要借助程序内部的逻辑和相关信息,通过检测内部动作是否按照设定进行,检查程序功能是否正确
  • 灰盒测试:介于黑盒测试和白盒测试之间,重视输出相对于输入的正确性,也看重程序内部的逻辑
  • 自动化测试:在预先设定的条件下自动运行背测程序,并分析运行结果

2.测试阶段
分单元测试、集成测试、系统测试
系统测试分功能测试、性能测试、验收测试、压力测试

单元测试:主要对软件模块进行测试,通过测试发现该模块的功能是否满足要求,采用静态测试和动态测试相结合的方式进行测试
集成测试:对按程序设计要求和标准组装起来的模块同时进行测试,检查程序结构组装的正确性,一般采用白盒测试和黑盒测试结合的方法进行测试
系统测试:一般采用黑盒测试,以此来检查系统是否符合软件需求
性能测试:通过自动化的测试工具模拟多种正常、峰值、异常负载条件来对系统各项性能指标进行测试

  • 负载测试:测试当负载逐渐增加时,系统各项性能指标的变化情况
  • 压力测试:通过确定一个系统的瓶颈或者不能接受的性能点,来获得系统能提供的最大服务级别的测试
    验收测试:最后一个阶段的测试,是软件产品正式交付前的测试工作,主要是判断软件产品是否满足用户需求或与用户签订的合同的各项要求

其他测试

  • alpha测试:对软件产品的功能、局域化、界面、可使用性的方面进行测试
  • bate测试:在实际环境中由多个用户对其进行测试
  • AB测试:Web或App界面或流程制作两个(AB版本)版本,在同一时间维度,让相同的用户随机访问这些版本进行测试
  • Web测试:主要针对Web应用的一类测试
  • 链接测试:
    • 测试所有链接是否正确跳转到对应的页面
    • 测试对应链接的页面是否存在
    • 保证应用上没有孤立的页面
  • 表单测试:当用户在提交表单信息的时候,表单能正常工作

净室工程

净室方式不是先制作产品再消除缺陷,而是要求在规约和设计中消除错误,再以“净”的方式制作,以降低软件开发中的风险,以合理的成本开发高质量的软件

基于构建的软件工程(Component-Based Software Engineering,CBSE)

定义:一种基于分布对象技术、强调通过可复用构件设计与构造软件系统的软件复用途径。
1.构件和构件模型
CBSE构件特征

  • 可组装型:对于可组装的构件,所有外部交互必须通过公开定义的接口进行
  • 可部署性:软件必须自包含的,必须能作为一个独立实体在提供其构件模型实现的构件平台上运行
  • 文档化:构件必须是完全文档化的,用户根据文档来判断构件是否满足需求
  • 独立性:构件必须是独立的,可以在无其他特殊构件的情况下进行组装和部署
  • 标准化:构件必须符合某种标准化的构件模型
    构件模型:定义了构件实现、文档化、开发标准,主流的构件模型有Web Service 模型、Sun公司的EJB模型、微软的.NET模型,构件模型包含接口、使用信息、部署等要输

2.CBSE过程
主要活动

  • 系统需求概览
  • 识别候选构件
  • 根据发现的构件修改需求
  • 体系结构设计
  • 构件定制与适配
  • 组装构件,创建系统

与传统的软件开发过程的区别

  • CBSE早期需要完整的需求,以便尽可能多地识别可复用的软件
  • 在过程早期阶段根据可利用的构件来细化和修改需求
  • 在系统体系结构设计完成后,有一个进一步对构件搜索、设计精化的活动
  • 开发就是将已经找到的构件集成在一起组装过程

3.构件组装
3种组装方式

  • 顺序组装:通过胶水代码按顺序调用已存在的构件,利用两个构件创造一个新的构件,上一个构件的输出是下一个构件的输入
  • 层次组装:一个构件直接调用另一个构件所提供的服务
  • 叠加组装:两个或两个以上的构件一起创建新的构件,原来的构件不互相依赖也不互相调用

3种不兼容情况

  • 参数不兼容:接口每一次的操作有相同的名字,但参数类型或参数个数不同
  • 操作不兼容:提供接口和请求接口的操作名不同
  • 操作不完备:一个构件提供的接口是另一个构件请求接口的子集或相反

软件项目管理

分进度管理、配置管理、质量管理、风险管理
1.进度管理
软件进度管理过程包括:活动定义、活动排序、活动资源估计、活动历时估计、制定进度计划、进度控制

工作分解结构(Work Breakdown Structure,WBS)
任务分解:项目→任务→工作→日常活动
任务分解要求

  • WBS的工作包是可控和可管理的,不能过于复杂
  • 任务分解不能过细,树形结构不超过6层
  • 每个工作包要有一个交付成果
  • 每个任务必须有明确定义的完成标准
  • WBS必须有利于责任分配

任务活动图
通常采用甘特图等方式来展示和管理项目活动

2.软件配置管理(Software Configuration Management,SCM)
核心内容是版本控制和变更控制
版本控制:指对软件开发过程中各种程序代码、配置文件、说明文档等文件变更的管理。最主要的功能是追踪文件的变更,另一个功能是并行开发
变更控制:变更控制不是控制变更,而是对变更进行管理,确保变更有序进行。

3.软件质量管理
软件质量保证(Software Quality Assurance,SQA)
目标:

  • 事前预防工作
  • 尽量在刚刚引入缺陷时即将其捕获,不让缺陷扩散到下一个阶段
  • 作用于过程而不是最终产品
  • 贯穿于所有的活动之中

主要任务:

  • SQA审计与评审
  • SQA报告
  • 处理不符合问题

软件质量认证:ISO 9000 与CMM

4.软件风险管理
Boehm把风险管理活动分风险估计(风险辨识、风险分析、风险排序)和风险控制(风险管理计划、风险处理、风险监督)
charette把风险分成分析(辨识、估计、评价)和管理(计划、控制、监督)

注:需要把黑盒测试和白盒测试的方法增加进来