架构-软件工程2.1-设计模型1

软件开发模型大体上可以分为三种类型。
第一种是以软件需求完全确定为前提的瀑布模型;
第二种是在软件开发初 始阶段只能提供基本需求时采用的迭代式或渐进式模型,例如喷泉模型、螺旋模型、统一开发过程和敏捷方法等;
第三种是以形式化为基础的变换模型。

软件方法学是软件开发全过程的指导原则与方法体系。其另一种含义是以软件方法为研究对象的学科。
从开发风范上看,软件方法有自顶向下的开发方法自底向上的开发方法
在实际软件开发中,大都是自顶向下与自底向上两种方法的结合,只不过是以何者为主而已。
自顶向下是指将一个大问题分化成多个可以解决的小问题,然后逐一进行解决。每个问题都会有一个模块去解决它,且每个问题包括抽象步骤和具体步骤。

补充
形式化方法是指釆用严格的数学方法,使用形式化规约语言来精确定义软件系统。
非形式化的开发方法是通过自然语言、图形或表格描述软件系统的行为和特性,然后基于这些描述进行设计和开发,而形式化开发则是基于数学的方式描述、开发和验证系统。

瀑布模型(SDLC)

瀑布模型(SDLC):瀑布模型是一个经典的软件生命周期模型。
一般将软件开发分为

  • 可行性分析(计划)
  • 需求分析、
  • 软件设计(概要设计、详细设计)、
  • 编码(含单元测试)、
  • 测试、
  • 运行维护

特点:

  1. 上一项开发活动接受该项活动的工作对象作为输入
  2. 利用这一输入,实施该项活动应完成的工作内容
  3. 给出该项活动的工作成果作为输出传给下一项开发活动
  4. 该项活动的实施工作成果进行评审。若其工作成果得到确认,则继续进行下一项开发活动;否则返回前一项,甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件
  5. 适用于需求明确的项目

缺点:

  • 软件需求完整性、正确性难确定
  • 严格串行化,很长时间才能看到结果
  • 瀑布模型要求每个阶段一次性完全解决该阶段工作,这不现实。
    瀑布模型
    瀑布模型2

原型化模型

原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。
原型法认为在很难一下子全面准确地提出用户需求的情况下,

特点:

  1. 实际可行
  2. 具有最终系统的基本特征
  3. 构造方便、快速,造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的

原型法
原型相关模型

V模型

V模型从整体上看起来,就是一个V字型的结构,由左右两边组成。
左边的下画线分别代表了需求分析、概要设计、详细设计、编码。
右边的上画线代表了单元测试、集成测试、系统测试与验收测试。
【测试贯穿于始终】

特点:

  1. 单元测试的主要目的是针对编码过程中可能存在的各种错误
  2. 集成测试的主要目的是针对详细设计中可能存在的问题
  3. 系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行
  4. 验收测试通常由业务专家或者用户进行,以确认产品能真正符合用户业务上的需要
  5. V模型用于需求明确和需求变更不频繁的情形。

V模型

W模型

【测试和开发并行】
W模型

螺旋模型

螺旋模型是一个演化软件过程模型,将原型实现的迭代特征与线性顺序(瀑布)模型中控制的和系统化的方面结合起来。在螺旋模型中,软件开发是一系列的增量发布
开发过程具有周期性重复的螺旋线状
四个象限分别标志每个周期所划分的四阶段:制订计划、风险分析、实施工程和客户评估
螺旋模型强调了【风险】分析,特别适用于庞大而复杂的、高风险的系统
螺旋模型

基于构件的开发模型CBSD

利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件,也可以是商品化成品软件构件。
特点是增强了复用性,在系统开发过程中,会构建一个构件库,供其他系统复用,因此可以提高可靠性,节省时间和成本。
【优点】易扩展、易重用、降低成本、安排任务更灵活。
【缺点】构件设计要求经验丰富的架构师、设计不好的构件难重用、强调重用可能牺牲其他指标(如性能)、第三方构件质量难控制。
基于构件

快速应用开发模型(RAD)

早先的可视化开发
快速应用开发模型


统一过程模型(RUP)(Rational Unified Process)【重】

RUP 描述了如何有效地利用商业的、可靠的方法开发和部署软件,是一种重量级过程。
RUP 类似一个在线的指导者,它可以为所有方面和层次的程序开发提供指导方针、本模版以及事例支持

RUP 把软件开发生命周期划分为多个循环,每个循环生成产品的一个新的版本,每个循环依次由4 个连续的阶段组成,每个阶段完成确定的任务。这4个阶段如下:

  • 初始阶段:定义最终产品视图和业务模型,并确定系统范围。

    里程碑:生命周期目标

  • 细化阶段:设计及确定系统的体系结构,制订工作计划及资源要求。

    里程碑:生命周期架构

  • 构造阶段构造产品并继续演进需求、体系结构、计划直至产品提交

    里程碑:初始运作功能

  • 移交阶段:把产品提交给用户使用。

    里程碑:产品发布
    统一过程图
    RUP 软件开发生命周期是一个二维的软件开发模型,RUP中有9个核心工作流,如下:

  • 业务建模:理解待开发系统所在的机构及其商业运作,确保所有参与人员对待开发系统所在的机构有共同的认识,评估待开发系统对所在机构的影响。
  • 需求:定义系统功能及用户界面,使客户知道系统的功能,使开发人员理解系统的需求,为项目预算及计划提供基础。
  • 分析与设计:把需求分析的结果转化为分析与设计模型。
  • 实现:把设计模型转换为实现结果,对开发的代码做单元测试,将不同实现人员开发的模块集成为可执行系统。
  • 测试:检查各子系统之间的交互、集成,验证所有需求是否均被正确实现,对发现的软件质量上的缺陷进行归档,对软件质量提出改进建议。
  • 部署:打包、分发、安装软件,升级旧系统;培训用户及销售人员,并提供技术支持。
  • 配置与变更管理:跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
  • 项目管理:为软件开发项目提供计划、人员分配、执行、监控等方面的指导,为风险管理提供框架。
  • 环境:为软件开发机构提供软件开发环境,即提供过程管理和工具的支持。
    9个核心工作流
    RUP 中定义了如下一些核心概念,理解这些概念对于理解RUP很有帮助。
  • 角色:Who 的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色,如体系结构师、设计人员、实现人员、测试员和配置管理人员等,并对每一个角色的工作和职责都做了详尽的说明。
  • 活动:How 的问题。活动是一个有明确目的的独立工作单元。
  • 制品:What的问题。制品是活动生成、创建或修改的一段信息。
  • 工作流:When 的问题。工作流描述了一个有意义的连续的活动序列,每个工作流产生一些有价值的产品,并显示了角色之间的关系。

RUP的特点

  1. 用例驱动:需求分析、设计、实现和测试等活动都是用例驱动的
  2. 以体系结构为中心:包括系统的总体组织和全局控制、通信协议等。是一个多维的结构,会采用多个视图来描述。在典型的4+1视图模型中:
    • 分析人员和测试人员关心的是系统的行为,会侧重于用例视图;
    • 最终用户关心的是系统的功能,会侧重于逻辑视图;
    • 程序员关心的是系统的配置、装配等问题,会侧重于实现视图;
    • 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题,会侧重于进程视图;
    • 系统工程师关心的是系统的发布、安装、拓扑结构等问题,会侧重于部署视图。
      RUA典型视图
  3. 迭代与增量。把整个项目开发分为多个迭代过程。在每次选代中,只考虑系统的一部分需求,进行分析、设计、实现、测试和部署等过程;每次迭代是在已完成部分的基础上进行的,每次增加一些新的功能实现,以此进行下去,直至最后项目的完成。

敏捷模型【重】

发展过程
敏捷方法发展路线
开发宣言:
个体和交豆 胜过 过程和工具
可以工作的软件 胜过 面面俱到的文档
客户合作 胜过合同谈判、
响应变化 胜过 遵循计划

敏捷方法区别于其他方法的两个特点:

  1. 是“适应性”而非“预设性”
  2. 是“面向人的”而非“面向过程的”

敏捷方法的核心思想:

  1. 敏捷方法是适应型,而非可预测型。拥抱变化,适应变化。
  2. 敏捷方法是以人为本,而非以过程为本。发挥人的特性。
  3. 迭代增量式的开发过程。以原型开发思想为基础,采用法代增量式开发,发行版本小型化。
    敏捷模型-概念

主要敏捷方法:

  • 极限编程(XP,Extreme Programming)。基础和价值观是交流、朴素、反馈和勇气,即任何一个软件项目都可以从4个方面入手进行改善:**(1)加强交流(2)从简单做起(3)寻求反馈(4)勇于实事求是。
    • XP 是一种近螺旋式的开发方法,它将复杂的开发过程分解为一个个相对比较简单的小周期:通过积极的交流、反馈以及其他一系列的方法,开发人员和客户可以非常清楚开发进度、变化待解决的问题和潜在的困难等,并根据实际情况及时地调整开发过程。
    • XP提倡测试先行,为了将以后出现bug的几率降到最低。
  • 水晶系列方法。与XP方法一样,都有以人为中心的理念,但在实践上有所不同。其目的是发展一种提倡“机动性的”方法,包含具有共性的核心元素,每个都含有独特的角色、过程模式工作产品和实践
  • 并列争球法(Scrum)。是一种迭代的增量化过程,把每段时间(如30天)一次的选代称为(Sprint),并按需求的优先级别来实现产品,多个自组织和自治的小组并行地递增”冲刺”实现产品。
  • 特性驱动开发方法(FDD):是一个迭代的开发模型。
    • 有效的软件开发需要3个要素:人、过程和技术
    • 有效的软件开发有5个核心过程:开发整体对象模型、构造特征列表、计划特征开发、特征设计和特征构建
      补充开发方法:

      (1) XP (Extreme Programming,极限编程)在所有的敏捷型方法中,XP是最引人瞩目的。它源于Smalltalk圈子,特别是Kent Beck和Ward Cunningham在20世纪80年代末的密切合作。XP在一些对费用控制严格的公司中的使用,已经被证明是非常有效的。

(2) Cockburn的水晶系列方法,水晶系列方法是由Alistair Cockburn提出的。它与XP方法一样,都有以人为中心的理念,但在实践上有所不同。Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程,因此,与XP的高度纪律性不同,Alistair探索了用最少纪律约束而仍能成功的方法,从而在产出效率与易于运作上达到一种平衡。也就是说,虽然水晶系列不如XP那样的产出效率,但会有更多的人能够接受并遵循它。

(3) 开放式源码,这里提到的开放式源码指的是开放源码界所用的一种运作方式。开放式源码项目有一个特别之处,就是程序开发人员在地域上分布很广,这使得它和其他敏捷方法不同,因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障(debug)的高度并行性,任何人发现了错误都可将改正源码的”补丁”文件发给维护者。然后由维护者将这些”补丁”或是新增的代码并入源码库。

(4) SCRUM。SCRUM己经出现很久了,像前面所论及的方法一样,该方法强调这样一个事实,即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中,为明确定义了的可重复的人员所用,去解决明确定义了的可重复的问题。

(5) Coad的功用驱动开发方法(FDD-Feature Driven Development)FDD是由Jeff De Luca和大师Peter Coad提出来的。像其他方法一样,它致力于短时的迭代阶段和可见可用的功能。在FDD中,一个迭代周期一般是两周。

在FDD中,编程开发人员分成两类:首席程序员和”类”程序员(class owner)。首席程序员是最富有经验的开发人员,他们是项目的协调者、设计者和指导者,而”类”程序员则主要做源码编写。

(6) ASD方法,ASD (Adaptive Software Development)方法由Jim Highsmith提出,其核心是三个非线性的、重叠的开发阶段:猜测、合作与学习。

形式化方法模型

建立在严格数学基础上的一种软件开发方法,主要活动是生成计算机软件形式化的数学规格说明。

喷泉模型

是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。

增量模型

增量模型:首先开发核心模块功能,而后与用户确认,之后再开发次核心模块的功能,即每次开发一部分功能,并与用户需求确认,最终完成项目开发,优先级最高的服务最先交付
特点:但由于并不是从系统整体角度规划各个模块,因此不利于模块划分
难点在于如何将客户需求划分为多个增量。与原型不用的是增量模型的每一次增量版本都可作为独立可操作的作品,而原型的构造一般是为了演示
增量模型


架构-软件工程2.1-设计模型1
http://060800.xyz/2025/07/27/架构/架构-软件工程2.1-设计模型1/
作者
砖头
发布于
2025年7月27日
许可协议