杨德仁，王晓峰，韩 强，刘建平，周玉玺

（1.宁夏医科大学理学院，宁夏银川 750004；2.北方民族大学计算机科学与工程学院，宁夏银川 750021）

0 引言

在软件开发早期，应用场景简单，身兼软件用户的软件开发者熟悉业务，因此软件开发难度较低，主要涉及编码和调试。随着应用范围的拓展，软件走向商业化和复杂化发展趋势，软件工程学科随即问世，标志着软件成为社会生产的基本角色。软件开发逐渐独立于业务，导致软件开发者与软件用户隔阂，造成难以逾越的开发鸿沟。开发者往往狭隘地关注软件开发，难以与待建软件目的完全契合。软件工程的问世旨在解决软件复杂性导致的软件危机问题，但在软件工程问世50 年之际，诸如软件本质复杂性［1］等困扰已久的难题仍未解决。

随着信息技术的普及，软件涉及的业务及其运营环境越来越复杂，使软件本质复杂性不断加强。软件本质复杂性源于业务过程复杂性，它是不可避免的，需通过推迟实施得以解决［2］，其机制是在软件过程中的层次化建模［3］。随着软件方法和技术的进步，软件方法学呈现多样化趋势，这引起软件过程中的“被复杂化”问题，相关过程性建模也需进一步规范以便实践［3］。正如软件设计大师Booch［4］所言，“软件工程历史就是提升抽象层次的历史”。

2 软件建模及其论域

为解决软件本质复杂性问题，软件过程从程序设计逐步向上抽象，历经软件分析、软件需求乃至业务建模［3-5］。其中，软件分析域独立和业务域回归显得尤为重要。

2.1 分析域

软件过程本质需求是实施软件建模。后者源于结构化编程设计并与编程语言范式密切相关［6］。在结构化方法中，采用程序流程图描述算法；概要设计旨在描述软件功能结构层次；结构化分析旨在通过分解业务域中的数据及其处理过程，找出最小数据处理单元与相关输入数据和输出数据，得到数据流模型，再把数据流模型中的“处理”单元映射到软件各功能层次结构上。

在面向对象的方法中，对象发现与精化是软件分析和设计难点和主要任务。早期使用数据流图描述软件需求。用例技术问世后，随即被用来描述软件需求，随着在用例中寻找对象的技术不断涌现，分析活动从软件需求中分离出来，并以“鲁棒分析”著称［7］，这体现在面向对象软件工程（OOSE）中。在设计层面，用类图描述软件静态结构，用序列图描述软件动态交互机制，它们是编码基础。软件工程知识体系（SWEBOK）包括软件需求、软件设计（含软件架构）、软件工程过程和软件工程模型与方法等［8］。

这种软件过程范式以抽象和建模为核心理念，但因没有顾及和利用业务域知识，容易导致“设计麻痹”问题。软件分析演化历程如表1 所示。

Table 1 Evolution of software analysis表1 软件分析演化历程

2.2 业务域

20 世纪90 年代，软件工程学科进入快速发展期，若干举足轻重的软件方法先后问世。针对软件本质复杂性问题，学术界和业界先后启动了业务域建模，诸如需求工程、软件架构（体系结构）、域工程、模型驱动的软件工程和领域驱动的设计等。

MDA 提倡模型及其转化以形成体系结构，进而促进模型转化；论域（平台）及其资源是软件建模基础［9］，相关著名的模型有计算无关的模型（CIM）、平台无关模型（PIM）和平台相关模型（PSM）。Dines［5］的“三段论”把软件工程分为域工程、需求工程和软件设计，旨在解决软件需求的无源之困局。领域驱动的设计则认为（业务）域模型是软件设计前驱［10］。软件方法中的业务域建模如表2 所示。

Table 2 Business domain modeling in software method表2 软件方法中的业务域建模

业务域建模是业务过程管理的必备手段，更是软件域建模基础，这是学界和业界的共识，如国际对象管理组织倡导和规范了业务域建模系列语言［9］。

3 双论域多层次软件建模

基于MDA 理念，软件设计指基于论域（平台）的建模和模型转化过程［9］。论域不同，其元素和关系（即结构）不同。基于软件过程模型、软件方法学和软件模型三维视角，软件建模一般按4 个论域逐级实施［3］，即业务域、软件需求域、软件分析域和软件设计域，如表2 所示。但这种四论域尚待细化，仅笼统地处理业务域是不可行的。

3.1 一种双论域层次化软件建模框架

业务过程痕迹用业务信息单据（即信息子）记录。而软件旨在支持业务运行，以处理业务域信息子为主。因此，设计软件需基于并满足业务域中的信息子处理要求。

根据米勒魔数定律，业务过程中的业务动作、业务对象和信息子等建模单元数量超出了人类大脑工作区容量，因此需通过探索业务实施路径从而抽象化处理。业务域建模应如同软件域建模，也历经目标、途径到过程的层次化进程。双论域层次化软件建模框架（Hierarchical Soft⁃ware Modeling Framework in Di-domain，HSMFD）如图1 所示。根据HSMFD 框架，以面向对象范式为例，分别对软件设计途径与实践集进行阐述。

Fig.1 Hierarchical software modeling framework in di-domain图1 基于双论域的层次化软件建模框架

3.2 业务域建模机制与实践集

在业务域中，业务是为客户服务的，满足客户需求和提高客户满意度是业务服务提供者首要目标。因此，业务域建模首当其冲，这需要设计和提供业务服务机制，即业务过程。其建模机制包括：①业务过程实施需要人力和其它资源，诸如业务对象和信息子；②在业务目标层，客户若有需求，业务服务提供者即有响应，用UML 用例图为其建模；③在业务途径层，用抽象的UML 活动图为业务实施途径建模。业务实施途径可通过业务参与者所做的事务确定［11］；④在业务过程层，用UML 活动图为业务过程中的业务动作、业务对象和信息子及其顺序建模，并提取该模型中的参与者、业务对象和信息子形成业务对象模型，用UML 类图表示，以备在软件域建模中重用［11］；⑤业务域建模实践集包括客户参与、业务途径探索和业务过程建模［6］。

信息子演变历程包括：①基于客户需求，探索满足该需求的各种实施途径即业务actor 的业务事务；②分解业务事务以得到业务动作；③明确各业务动作输入信息子和输出信息子［11］；④得到业务信息子模型。

业务对象演变历程类似于信息子演变历程［11］，各业务动作也有输入对象和输出对象，从而得到业务对象模型。

3.3 软件域建模机制与实践集

3.3.1 建模机制

软件需求基于业务域的信息子处理，即软件功能需求或用户需求。用户需求是宏观的，与设计层次软件基本单元（类）及其对象的交互尚有距离，需探索和桥接这种差距，可借助于用例规约和鲁棒图实施［7］。其建模机制如下：

（1）在软件需求层，分别用UML 用例图表示用户信息子处理即功能需求模型，用Axure 建立GUI 原型以获取业务对象的属性，用UML 类图表示静态模型原型。

（2）在软件分析层，分解上述功能需求模型，找出另一个软件对象即控制对象，按照用例规约和UML 鲁棒图分别为程序执行顺序和类图原型建模［12］，并通过添加控制对象优化静态模型。

（3）在软件设计层，基于上述程序执行顺序原型，用UML 顺序图为业务对象确定方法［13］，优化上述静态模型。除此外，还需用流程图为类的方法建模，用实体联系图（ERD）为数据建模［14-15］。

3.3.2 实践集

软件域建模实践集有信息子处理及其整合、用户与软件交互路径探索、类的优化、算法设计和数据建模等［6］。

软件对象交互模型变历程包括：基于用户的信息子处理需求，在软件分析域以用例规约中的“事件流”探索人机交互序列；在软件设计域基于对象交互即发送和相应“消息”用序列图将软件的二级控制对象转换为目标对象的方法。

软件类的演变历程如下：基于业务对象，在软件需求域探索人机交互界面（GUI）以找出业务对象的属性；得到静态模型原型；在软件分析域找出软件的一级控制对象和二级控制对象，更新静态模型；在软件设计域用序列图将上述二级控制对象转换为相关业务对象的方法，更新静态模型便得到软件的静态模型。

数据库表模式设计则基于上述的软件静态模型，用实体联系图（ERD），其中实体源于静态模型中的业务对象，联系则是业务对象之间的关系和信息子。

3.4 两种域建模比较

业务域模型是软件域模型基础，其建模机制相似而粒度不同，可从3 方面进行比较：

①层次不同性：软件域位于业务域中的业务过程层次，旨在支持业务过程；②机制相似性：两者均具有3 个层次，即目标层、途径层和实施过程层；③运行相关性：以信息子处理为纽带，业务域建模是基础，软件域建模是对业务的支持。

3.5 软件复杂性问题解决机制

软件本质上服务于业务，业务域建模是软件域建模的基础。如前文所述，软件的本质复杂性源于业务过程的复杂性，它是不可避免的，需通过推迟实施得以解决［2］。

业务域不同于软件域，但其逻辑实施又相似于软件域，即从业务目标到业务实施（即业务过程）也不可一蹴而就。换而言之，业务也具有偶然复杂性。

基于软件四论域（即业务域、需求域、分析与和设计域）建模实践框架［4，6］，本文提出的HSMFD 框架进一步区分了业务域和软件域，同时也对业务域实施层次化建模。

借助于MDA 模型及其转化理念［9］，通过分论域层次化建模机制，可有效避免业务本质复杂性和软件本质复杂性过早显现的问题［2］；借助于MDA 模型及其转化理念［9］，通过分论域层次化建模及其机制和实践集，有效规范了业务建模过程和软件建模过程，从而可解决因影响因素繁多而导致的业务偶然复杂性问题与软件偶然复杂性问题［4］。

4 结语

软件需求是软件开发的基础，但用户对软件的需求往往多变，难以确定，加上市场竞争因素影响，软件需求变化性是业界常态。

在迭代开发基础上，敏捷开发旨在组建业务（用户）代表全程参与的敏捷团队以拥抱需求变化，敏捷框架已成为软件开发主流技术，旨在为用户提供最大价值。而敏捷实践存在模型层次不明晰或缩水现象，混淆了不同论域的元素，超越了人类理解问题和解决问题的极限，违背了抽象和层次化设计原理，增加了软件过程中的人为隐患性，难免陷入“大泥球”风险。

目前，知名的IT 国际咨询公司都在进行敏捷与传统方法融合实践的探索和推广。面向对象技术先驱Ivar Jacob⁃son 及其雅各布森国际为客户提供基于用例的敏捷教练、敏捷咨询和敏捷训练等企业级软件开发融合实践指导［16］。责任驱动设计发明者Rebecca 及其Wirfs Brock 协会也在推广基于责任驱动设计的敏捷架构、设计启发和实用性软件设计技术。软件开发传统过程与敏捷框架的融合之道是值得深入探索的研究方向。