信息化的本质分享 http://blog.sciencenet.cn/u/Babituo

博文

陀螺形软件生命周期模型

已有 1231 次阅读 2022-3-9 11:00 |个人分类:面向资源软件开发方法|系统分类:科研笔记

陀螺型软件生命周期模型

摘要

建立在传统软件实现技术基础之上的软件生命周期管理模型,已经不再适应新时代泛在融合的应用需求的特点。传统软件过程模型存在的“软件开发各阶段语义一致性达成成本高”、“设计时和运行时分界导致工具难以闭环”的问题,已经成为适应新需求的模型驱动架构MDA)实现技术的发展障碍。采用基于解释型编程语言的MDA,既可实现各阶段语义的分层剥离,又能大大提升递进转译的并行性和同步性。在统一的生态型分层协同建模工具系统的支撑下,可建立新型的陀螺型的软件生命周期模型,让软件工程环境得到颠覆性的创新。

关键字:陀螺型,软件生命周期模型,模型驱动架构,生态型分层协同建模工具系统

软件开发过程模型变迁概述

计算机软件生命周期管理的理念应该起源于一般产品生命周期管理,并在一般产品生命周期管理概念基础上,结合软件工程的具体特点进行了深化和拓展。

一般产品生命周期管理理论成型的标志,大约是1966年美国哈佛大学教授雷蒙德·弗农(Raymond Vernon)《产品周期中的国际投资与国际贸易》一文。该理论首次从宏观的市场整体尺度下,研究了新产品全生命周期视野范围的演化规律,影响十分深远。

计算机软件产品作为一种主要使用智力资源生产的特殊产品,与传统手工业类似,始终需要依靠个体工匠的“智力技艺”,同时又需要满足规模不断拓展的工程化的应用需求。曾经的“软件工程危机”已从危机意识转变为普通常识,不再引起关注。软件工程的思想和方法始终是学界重要的研究课题。在其理论和实践得到不断的提升和发展的同时,和应用需求期望的差距却越来越大,并且和软件开发技术进步越来越不相适应,甚至成为了新的软件实现技术的发展阻力。

遵循产品生命周期规律,现今已经发展出来的软件开发过程模型大致包括:瀑布模型螺旋模型迭代模型增量模型敏捷模型。这些过程模型各有特点和适应场景。它们共同的本质是,都遵循着产品生命周期V形模型的基本逻辑。也就是遵守产品的需求、分析、设计、实现、构建、测试、部署、发布、运维的环环相扣,出入呼应的全生命周期的“时序逻辑”。整体的发展趋势是:将串行化的、粗粒度的【软件工程活动】分层递进地微分为细粒度的、并行化的、多时间线交织的叠加方式演进。

这些过程模型发展的知识来源,主要是软件工程实践经验,并且与应用需求类型的演变密切相关。过程模型主要着眼于解决软件过程和产品的质量控制,过程管理和效能评价问题,和软件开发技术的关联并不十分紧密。或者说,它们只紧密关联传统的代码化的实现技术;再或者说,软件实现技术本身的发展进程相对缓慢,并没有取得重大的突破值得软件过程模型发生改变。或者也需反思一下:软件工程所谓没有银弹说的盛行,是否“政治正确”地对软件实现技术的发展和应用造成了一定的观念限制的影响?

软件开发技术的发展脉络

软件开发技术的发展,和软件过程管理方法一样,也是始终是伴随软件的应用需求不断发展变迁的。计算机软件应用需求经历了从早期解决独立的计算演算问题,到班组专业的作业指导管理问题,然后到企业内部生产的资源组织计划和执行的管理,再到行业供应链管理、跨界融合的区域资源整合应用管理。发展到目前,从军事领域到工商,民生各行各业,再到政府乃至全社会,行业级、城市级乃至社会级的全面业务大整合的应用需求,已成为可见的趋势。让现实世界与数字世界得到平行演进,至少成为了目前理想可期的应用需求。

软件开发技术为满足应用的需求拓展,大致经历了关系型数据库,面向对象编程语言,面向服务的分布式应用架构、大数据和机器学习、知识图谱和图计算等影响软件体系结构的主要技术。软件形态从单体结构的桌面应用,C/S应用,B/S应用到多体的B/S,云原生应用,在技术线路上经历了DLL动态链接库,CORBA,j2EE,SOA架构,容器技术支撑下的微服务架构,以及以云API为特色的无服务架构,在泛在网络和云计算环境下,又显示出了回归到超巨型的虚拟单体应用——元宇宙的迹象。显示出清晰的软件体系架构演变的主流趋势,也是:将串行化的、粗粒度的【软件功能结构】,分层递进地微分为细粒度的、并行化的、多时间线交织的叠加方式演变。

但影响软件开发过程和方法的软件实现技术,却始终停留在语言符号编码方式为主,虽然语言的功能、表达能力越来越强,但始终未能实现人类语言和计算机可执行程序之间的平滑演进的过渡,始终保留着V形软件生命周期中的设计时和运行时的鸿沟。让软件产品的设计、开发实现和运维分属不同的阶段。试图用串行的Devops工具链,自动化集成来组织并行的过程时间线,可以期望短时期内提高软件过程效能,但业界同时几乎已经触及到了传统实现技术的历史包袱,造成的软件过程效能提升的天花板了。低代码开发再次成为热点就是一个例证。这样的一个观点早已成为广泛的共识:要想在软件过程性能上取得重大的进展,必须首先要在软件实现技术上取得突破。但制约这一目的达成的关键原因:V形生命周期中的设计时和运行时分界的鸿沟,却并未得到应有的关注。

现有软件开发过程模型综述

到目前为止,主流软件开发过程模型包括瀑布型、螺旋模型迭代模型增量模型敏捷模型。它们实质上都是根据不同类型软件开发需求特点,侧重不同的风险应对策略,从实践中产生的,对V形软件生命周期模型的不同的组织演化方式。

瀑布模型是典型的单线顺序的软件开发过程模型,在一次性的流程中完成软件开发的需求分析、设计、编码实现、测试与运行维护6个阶段工作。反映了软件开发活动的基本时序逻辑,只是活动周期、任务粗粒度选择比较粗。

螺旋模型是以原型为基础,围绕原型做周期性的计划、实施和风险评估循环工作,每个循环周期的工作的内容与时序逻辑关系和瀑布模型一样,与V型模型也没有实质差异。在多轮循环后发布正式成型的软件产品,螺旋模型较瀑布模型能更好应对交付不合格发现太迟的风险。

迭代模型也是周期性的迭代循环开发,与螺旋模型不同的是,每轮循环都推出可用的最终产品,但根据软件产品全生命周期成长自身的规律,在每轮循环中的各环节的工作投入的时间精力比例各不相同,完成和升级改进的产品功能特性也不同。

增量模型则打破了时间上串行的阶段循环模式,采用并行的多流程线针对软件的不同增量进行开发。通常第一个增量完成核心产品,每个增量在核心产品上增加新的功能结构成分,每个增量完成都能发布一个可用产品版本,由此以空间换时间,压缩版本升级发布的时间间隔。

敏捷模型带来了观念的变革,则将原来串行的多阶段的工作合并到一个并行工作的机制中,敏捷开发团队集中了开发应用阶段所有角色成员,特别是还包括用户参与,把产品开发应用活动划分为一个一个的时间盒,利用共同密切的沟通而不是文档交接评审来同步原来软件产品各流程阶段的信息,在每一个限定时间盒范围内推出可靠和可用的产品。

软件开发模型的进化反映了将串行化的、粗粒度的【软件工程活动】向分层递进地微分为细粒度的、并行化的、多时间线交织的叠加方式演变的趋势但在每一个细分周期或并列时间线上的工作内容,都大体是遵循V的生命周期时序逻辑规律的,本质上只是V形生命周期模型的不同粒度的串接、并接形成的,是具有不同控制粒度、不同周转频率的开发过程模型。下图表明了各种软件开发过程模型与V生命周期模型的关系。

t1.png

   以上5种软件过程模型有演进关系,但并非靠前的就一定为过时的模型,更应该把它们看做是适应不同特点项目的,各有优缺点的过程模型。

瀑布模型适应需求不确定性小,允许开发周期比较长,产品质量要求高,体量规模比较大的应用软件开发,如专业工具应用软件,行业应用基础平台软件等;

螺旋模型为解决瀑布型一次成型发布的风险高,采用多次的循环周期开发,分内部版本控制产品质量风险,适合需求比较复杂,体量规模大,质量要求和用户体验要求高,如:广泛普及的通用工具软件,如Office软件。

迭代模型解决螺旋模型开发周期长,用户体验机会少,需求变更压力大的问题,采用每个迭代周期进行用户交互反馈,以提高对需求变更适应性。这类开发模型比较适合传统行业企业的通用型管理信息系统开发,如企业OA,MIS系统。

增量模型解决迭代模型对大型软件不能满足上线交付工期要求,目标系统的市场应用更新升级压力大的问题,采用多子系统,多特性分离并行开发。比较适合较大型的行业应用解决方案,如大型ERP软件,电子政务系统等。

敏捷模型出发点是解决软件需求不确定性较大,用户需求不明确带来的问题,强调拥抱变化,通过用户参与团队齐全的角色成员的紧密协作,在特定的时间范围内并行工作,完成特定分解目标的开发(攻山头,冲刺),减少因文档化沟通交流和评审带来的串行时间损耗。敏捷模型对团队成员和参与用户的专业能力、协作能力和团队文化的要求都非常高。国内的一段时期以来,业务应用逻辑相对简单,用户体验要求较高的互联网应用,刚好对团队专业能力要求不算太高,所以,在互联网应用开发中得到广泛应用。这也使得名义上的敏捷模型事实上变异为了一种蜕化的快速原型方法。随着行业互联网应用的需求增长,对业务逻辑和跨界融合的要求越来越高,变异的敏捷模型显然不能满足互联网行业应用的需求,而对正统的敏捷模型对团队来说,特战队级别的要求是大部分企业团队可望不可及的。

软件体系结构和开发过程模型的本质

软件开发过程的本质,是人将计算机运行所需的知识对计算机进行教育的过程。所以,编程的实质是传授知识给电脑。而知识传授的效能,主要取决于知识接受者的语言理解和知识处理的能力,而不仅仅是数据处理和知识记忆和查询复述的能力。其中前者主要是开发过程所需,而后者主要是运行过程所需。所以,程序代码是目前计算机运行知识的主要载体。

软件体系结构的本质,就是软件运行所需知识和被处理的数据及信息如何表示、保存、分解、耦合、链接、流转、处理的构造和运用的机制。

V形生命周期的分析、设计、编码、构建、测试,部署,运维7个阶段,在构建阶段之前被称为“设计时”,之后称为“运行时”。设计时的工作,本质上是对软件作为计算机运行所需知识的不同层次的语言表达。各阶段的递进,相当于多轮的翻译(语义转换),最终靠编译器编译为机器的操作语义。如果把每一轮的语义转换比作磨盘磨粉,那么,除了敏捷模型是用两套磨盘之外,其他模型都用的都是多套磨盘。

  

 t2.png

 图中展现的是共同的语义转换的逻辑时序,不同过程模型只是采用时线数多少,串并方法、出品频次不同。

除了敏捷模型外的过程模型,前三轮语义转换工作都是由不同的分工团队,利用不同的工具环境,在相对独立的不同时间段内完成,提交不同的过程成果,第四轮是编译器自动完成。敏捷模型则是把不同阶段分工的角色抽调在一起,形成一个开发全过程专一的团队,不同角色共同工作,语义转换工作时序依赖不变,但在共同的时间段内通过面对面沟通完成转移,在同一个公共知识文档中共享。相当于多阶段角色合力推一个磨盘。








 t3.png 

不管是哪种软件过程模型,软件产品的而最终真实运行效果,都必须通过【编译】这个“磨盘”之后,才能得到运行时的反馈。

多层语义并行转换困难的原因分析

在自然语言理解NLP技术用于软件开发过程短期内得不到成熟的假设下,有什么方法既可以像敏捷模型一样较大规模地提高并行工作的程度,又能避免敏捷模型对团队技能和文化要求过高呢?

从软件过程模型的语义转换本质来看,至少包含业务需求层、系统需求层、系统实现层和系统运行层四层语义需要人工转译。最大限度地提高四层语义转译的并行度和降低一致性达成的成本,是提高软件开发过程效能的潜力所在。

现有过程模型达到更高的工作并行度的瓶颈在语义的形式化转换,以及编译过程造成的设计时和运行时的鸿沟两个方面。

其中关键的阻碍因素之一是编译型语言的选择。在软件开发历史上选择编译型语言是情有可原的,主要受制于硬件运行性能的限制。在当今硬件运行性能已得到极大提升、解释型语言实际已经占据了应用开发的主流时,软件过程模型已经在编译型语言模式下积重难返了。

另一个关键因素是,统一的自然语言的语义形式化转换策略、方法和工具的缺失。一次性实现自然语言到形式语言的转换的技术就是NLP,NLP太远,就只能分阶段多次渐进转换,所以有了V型生命周期的开发段。串行效率慢就并行来,靠人工并行困难就用工具平台辅助并行,但是,并行辅助语义转换工具在哪呢?怎么样才叫真正的并行呢?不同角色在一起工作吗?用同一套集成工具平台吗?是的,但都还不够,还必须基于共享统一的模型,必须让多层的语义转换同时作用在同一个模型的不同层面上做同步分层的拼图!缺乏统一的共享工具平台和一体化的承载机制,对相同对象的不同层次的语义信息需要人工事后对接,不管是编写的代码还是生成的代码,语义被代码固化,拆解重组困难,可编辑、可重用性差,是造成实现多层语义信息的一致性的沟通成本高昂和并行演进困难的主要原因。

软件过程模型创新的机遇

在现有软件过程模型中,唯有敏捷模型贯彻了【并行工程】的思想。但由于团队成员混合交织工作,虽然减少了文档沟通的串行时间损耗,但软件语义转换能力下降以及对沟通技巧和文化要求的提高代价增大,抵消了敏捷模型的优势,使得实际的敏捷团队能适应的软件项目规模和复杂度大打折扣。

面向对象的迭代模型又称喷泉模型,由于采用面向对象的语义封装,可以较好地实现模型的语义隐藏的特性,可实现软件单元功能多层嵌套地继承,实现自底向上分层地演进和循环迭代,可在软件单元原有功能实现功能的叠加积累,大大提高了已有代码的可重用性。但是,由于类继承机制耦合紧密,加上设计时和运行时的分离,只能从设计类实例化对象进行运行,还是无法建立设计时和运行时统一的共享模型,也无法在运行时创建对象实例反向归纳类,实现运行时的可演进的闭环设计。

随着现代面向对象的脚本语言如Java Script,python语言的不断成熟,解释型语言逐渐占据前端开发的主流,并向后端开发延伸。通过原型构造函数实例化机制而不是封装类的实例化机制实现面向对象特性,实现了面向对象设计时和运行时的统一,即已经具备在程序运行的阶段修改程序代码类功能定义的能力。由于传统开发过程模型的习惯影响,脚本语言设计工具和运行环境依然是分离的,使得解释型语言的动态语义转换的优势并未发挥出来。解释型语言占据主流已成事实,在某类语言的解释引擎基础上进行模型化的封装,就可以得到可执行的软件单元模型,这为软件开发模型彻底消除设计时和运行时界限扫清了障碍。

随着面向对象建模技术的不断进步,OMG(国际对象管理组织)于2003年推出模型驱动架构MDA规范【OMG03】,提出了一种通过建模语言建模,无需人工编码来开发应用软件的架构思想和方法,发展到近期,即所谓“基于模型的系统工程MBSE”方法。通过模型构建来实现应用程序逻辑的形式化表达技术是可行的,这一点已经在军工领域的大量实践中得到验证。本质上来说,是证明了多层语义可通过形式化的元元模型,元模型,应用模型与应用实例模型的分层组织来实现语义相关性的逐层附加。

t4.png

 所谓“与XX无关“,也就是该层次的建模语言元素和规则具有足够的语义抽象性,在该语义抽象层不带任何被描述层具体对象的约束信息,因而对描述【XX范畴】的对象具有通用性,用这些通用的语言元素的不同形式的组合,就可以构造出更高层的语言元素,如此逐层发散,就可以结合不同层次引进的相关性来实现不同层次建模语言元素的快速丰富,并在依赖最底层模型表达的可运行特性,实现高层模型的可执行特性。

根据OMG规范的MDA工具,采用通用图形化建模语言如UML,SysML建立软件系统及“软件系统的系统”SoS的模型,然后通过代码生成的方式生成可编译执行的代码程序。这波操作有明显的历史包袱痕迹:本来模型驱动架构,已经能够实现教授给电脑的知识,从符号语言转移到比编程语言更接近人能理解的形式化的描述性模型上来了,本可被直接解释执行了,却还非得再转回生成程序代码去走编译过程这条弯路,似乎只有与程序员编码的程序比较得到相同或超越的效果,才能证明模型驱动架构的价值。这一波操作却舍近求远地刚好违背了支持并行语义转换必须将设计时和运行时统一的要求,奔直坑里跳了。

事实上,只需要根据MDA架构思想重新设计基于解释型语言的MDA架构,来实现设计时和运行时的模型统一。这样,就为建立统一的分析、设计、实现和运行的工具环境,支持全生命周期的并行分层语义转换与同步执行铺平了道路。

陀螺型软件生命周期模型

陀螺型软件生命周期模型是一种可面向超大规模应用软件大整合需求,综合传统软件开发过程模型的优势特点,通过透析软件逻辑架构和软件开发过程的本质,基于解释型编程语言的模型驱动开发工具环境而设计的,一种应用软件全生命周期的,分析、设计、实现、测试、运行、维护一体化的立体存活模型。

t6.png      由于采用基于解释型编程语言引擎为内核的模型驱动架构,一体化开发运行环境分四层或更多层构建,每层基于底层工具环境为内核,分层共享底层工具平台功能和资源,结合本层语义相关类型构建多个不同的对上层的基础平台。采用这种“同轴集成”的模式衍生出树形的平台族,构成一个统一虚拟模型的生态系统。

t5.png

并行运行原理如A向视图所示。对于一个具体的软件项目,有四层的团队同时并行建模开发工作。每一层团队都以上一层团队开发积累的基础模型库进行组装建模,遇到上一层模型不足,向上一层请求新增模型支持。

由于采用MDA架构,实现了建模即开发实现,加上语义分层剥离,各层开发者使用本层语义连接上层基础模型即可完成快速开发。整个软件的生命周期被缩减为建模、测试和运维三个阶段。

各层开发团队分工明确,只需用本团队熟悉的语义工具环境进行模型的拼装即完成了原先分析设计和编码实现的工作。具体而言:

对于最终项目开发团队而言,只面对本项目的特定用户的唯一的开发运行平台,直接以具体业务需求语义为输入,利用业务基础平台预先建立的模型进行组装,进行项目建模。

对于业务开发团队而言,以领域业务实现语义为输入,只面对本专业应用领域进行业务应用资源的开发,利用系统应用开发工具平台提供的组件进行连接,构成业务基础平台供多个项目团队进行定制开发。

对于系统开发团队而言,面向不同类型的应用项目,以系统组件实现语义为输入,只面对某一类,如控制,管理类应用开发此类应用的应用开发工具平台。为多个业务基础平台开发团队提供支撑。

对于内核开发团队而言,实现通用的含义库开发,支持与应用功能无关的可执行的含义建模。含义建模通过适配器挂接不同的解释语言引擎,实现和编程语言的无关性。

不同层级的开发团队,本质上是不同层级的语义转换功能提供的实施实体,层次细分越多,语义的过渡转换越平滑,语义转换难度就越小,不同特点的项目就可在语义转换难度梯度的递进规律上。由于不同的团队基于共享的同一个模型在不同的语义层工作,协同难度也能得到控制,传统软件过程模型都能在陀螺模型上找到实施的路径和方法,因而可面向不同特点的项目构建不同大小规模和细分层数的陀螺模型。

NLP不是一蹴而就的,陀螺型软件生命周期或许能为NLP技术自身发展及其在软件工程中的应用提供一个方向和框架。沿着语义转换难度梯度下降的方向,逐步取代不同层级分工的团队人员的工作,融入平滑的模型自动化构建的流程演进,一切将水到渠成。

陀螺型软件生命周期模型特点归纳

1. 哲学内核:转起来就平衡了。

2. 核心理念:最大限度地并行进行多层语义的同步转换。

3. 关键要素:基于共享统一的可执行模型的难度平滑递进的语义转换。

4. 技术支撑:同轴集成并行运转的多层生态型建模平台。

5. 技术内核:可执行的含义引擎,含义库管理系统。

6. 作业模式:分层周转,螺旋升降,自然协同。

感谢

30年的个人独立的基因架构软件的面向资源应用开发方法的探索,算是一次漫长的攀岩,时至今日的本文,思想上已彻底打通,实践上也越过了那道岩缝,我个人能及的王母瑶池顶已近在咫尺了。

感谢曾给予过我营养和灵感启发的(按时间顺序):邹晓辉老师的融智学,张学文老师的组成论,陈雨思老师的同态学,洪昆辉老师的状态论,欧阳余山对表达的数学形式的探究(补),王德奎老师的三旋理论,顾险峰老师的共形计算理论,郑智捷老师的共轭逻辑与分层结构化理论,高庆狮老师的统一语言学,蔡文杨春燕老师的可拓学。还有我曾经服务过的每一家企业提供的实践和试错机会。

感谢家人,平静相伴,平凡相依。

感谢科学网,提供了安静、温暖的攀登者宿营地。

感谢祖国,让我能和平生活,自由思想。

 

2022年3月8日星期二

邱嘉文 于珠海




https://blog.sciencenet.cn/blog-33982-1328670.html

上一篇:“时”与“态”的观念变迁
下一篇:数字孪生城市大脑架构设计思路

4 张学文 武夷山 郑智捷 杨正瓴

该博文允许注册用户评论 请点击登录 评论 (7 个评论)

数据加载中...
扫一扫,分享此博文

Archiver|手机版|科学网 ( 京ICP备07017567号-12 )

GMT+8, 2022-7-2 05:00

Powered by ScienceNet.cn

Copyright © 2007- 中国科学报社

返回顶部