|
为什么进行基于模型的开发
现在软件的规模越来越大、参与人员越来越多，所以对软件的整体理解和持续理解能力要求越来越高，而随着软件规模的积累，很多团队已经深感力不从心。而软件开发的整个过程是一个整体，这就好比软件开发过程是一个木桶，而交付的软件就是木桶中的水，软件开发过程中的每个环节都是木桶的一个挡板，任何2个挡板之间出现了间隙，都会影响整体，造成最终软件的质量问题。参照这个木桶效应，软件开发过程有必要从基于文档的分析设计进化到基于模型的分析设计，这样会实现能力的提升：
在基于文档的分析设计工作模式下，需求和设计没有统一的语言和形式，造成过渡间隙，导致需求和设计的问题。
在基于模型的需求和设计工作模式下，需求和设计工作采用模型可以实现良好而自然的过渡，所以可以形成紧密跟踪，大大提高了需求和设计的工作质量和效率。
2种工作模式对比如下：
| 基于文档的分析设计 |
工作场景 |
|
1. 需求人员编写《需求文档》
2. 设计人员编写《设计文档》
3. 开发人员理解需求和设计，编码《代码》。
4. 测试人员理解需求和设计，设计、执行《测试用例》 。
这种工作模式下，需求和设计采用文档描述，而文档的描述能力和关联跟踪能力都比较弱，进而影响分析设计的广度和深度，难以搞定复杂系统或者持续积累的系统。
|
| 基于模型的分析设计 |
工作场景 |
|
1. 需求人员建立《需求模型》
2. 设计人员建立《设计模型》
3. 开发人员理解需求和设计，编码《代码》。
4. 测试人员理解需求和设计，设计、执行《测试用例》
这种工作模式下，采用模型可以提高描述能力，进而提高分析设计能力，采用建模规范Sys
ML和UML还有助于提高交流和复用能力。能够大大提高应对复杂系统和持续积累系统的能力。 |
| 基于文档的分析设计 |
|
| 工作场景 |
1.
需求人员编写《需求文档》
2. 设计人员编写《设计文档》
3. 开发人员理解需求和设计，编码《代码》。
4. 测试人员理解需求和设计，设计、执行《测试用例》 。
这种工作模式下，需求和设计采用文档描述，而文档的描述能力和关联跟踪能力都比较弱，进而影响分析设计的广度和深度，难以搞定复杂系统或者持续积累的系统。
|
| 基于模型的分析设计 |
|
| 工作场景 |
1. 需求人员建立《需求模型》
2. 设计人员建立《设计模型》
3. 开发人员理解需求和设计，编码《代码》。
4. 测试人员理解需求和设计，设计、执行《测试用例》
这种工作模式下，采用模型可以提高描述能力，进而提高分析设计能力，采用建模规范Sys ML和UML还有助于提高交流和复用能力。能够大大提高应对复杂系统和持续积累系统的能力。 |
基于模型的开发遇到的问题
在基于模型的分析设计工作模式下，需求和设计面向后续工作软件开发和测试的信息传递主要还是靠人工进行，这就很容易出现过渡间隙，造成漏水！
基于模型的开发 ~ 测试
为了解决需求和设计模型和软件开发和测试的对接，我们还需要把模型的工作继续推进：
基于模型的开发：
基于设计模型自动化生成code，然后对代码进行编译。减少人工编码的漏洞，提高质量和效率，并形成严谨的跟踪关系。
基于模型的测试：
基于模型生成测试用例，然后基于模型实现自动化的测试设计和执行，提高测试的质量和效率，并形成严谨的跟踪关系。
基于设计模型的生成code和基于设计模型的测试工作场景描述如下：
| 基于模型的开发 |
工作场景 |
|
1. 基于《设计模型》，生成《代码》
2. 对生成的代码进行编译，获得可执行程序。
3. 部署可执行程序到目标设备。
这种工作模式下，设计到代码实现了自动化生成，提高了效率，减少了人为质量问题的引入。
|
| 基于模型的测试 |
工作场景 |
|
1. 基于《模型》生成测试用例，
2. 基于《模型》发出测试请求给可执行程序，
3. 接收可执行程序的响应，
4. 标记测试用例的执行结果。
实现了如下能力：基于需求和设计可以快速生成测试用例，然后基于模型进行自动化测试，提高了测试效率和测试的质量。 |
| 基于模型的开发 |
|
| 工作场景 |
1.
基于《设计模型》，生成《代码》
2. 对生成的代码进行编译，获得可执行程序。
3. 部署可执行程序到目标设备。
这种工作模式下，设计到代码实现了自动化生成，提高了效率，减少了人为质量问题的引入。
|
| 基于模型的测试 |
|
| 工作场景 |
1. 基于《模型》生成测试用例，
2. 基于《模型》发出测试请求给可执行程序，
3. 接收可执行程序的响应，
4. 标记测试用例的执行结果。
实现了如下能力：基于需求和设计可以快速生成测试用例，然后基于模型进行自动化测试，提高了测试效率和测试的质量。 |
基于模型，开发者就可以贯穿软件开发的整个过程：需求-设计-开发-测试，让软件开发的整个过程实现如下4大能力：
1. 平滑过渡：因为模型具有统一的规范，相近的形式，屏蔽点实现的差异，让不同的工作转换和过渡更容易。
2. 严谨跟踪：基于模型的转换和过渡，会自然而然的实现各种工作的紧密的跟踪关系，这对需求跟踪、变更管理都是非常重要的基础。
3. 提高效率：基于模型的4种工作的快速迭代，可以打破专业壁垒，大大提高沟通效率。
4. 保证质量：在工作内容清晰、工作过渡顺畅、借助自动化的能力，质量无疑会得到更好的保障。
对于这种基于模型的开发模式，取Model Based 和各个工作的首字母，可以称之为MB-DDT（Model
Based,Design ,Development , Test）。
MB-DDT的目标是：基于模型的闭环开发。为了更形象一些，我们来个图标吧：
基于模型的设计~开发~ 测试MB-DDT的工具支持
再好的方法，也要落地为工具，才能对工作形成真正的支持。为此，我们专门定制开发了工具方案：
建模工具选择当前的主流UML、SysML建模工具EA：建立需求模型、设计模型、可以自动生成需求和设计文档；
基于模型的code生成和测试工具我们专门研发了Simulator：可以基于设计模型生成可运行代码，编译，然后基于模型生成测试用例，执行仿真测试。
对于开发工具、编译工具、运行环境，这些是具体的开发者可以沿用已有的。
这样就形成了一个完整的 MB-ADDT工具链。
这个工具链提供的是对MB-DDT的基本支持，如果用户希望扩展功能，我们可以根据用户需求定制，引入更多的工具支持。
下面我就对这个工具方案做个简要介绍。此工具方案为用户提供的工作场景如下：
1. 在EA中建立需求模型
2. 在EA中建立设计模型
3. 使用Simulator基于模型自动生成代码，
4. 使用Simulator编译代码为可执行程序，
5. 部署可执行程序到目标设备；
6. 使用Simulator通过通信连接访问目标设备，执行测试用例，进行仿真测试。
7. Simulator接受目标设备的测试响应，以模型显示软件的状态。
如下是MB-ADDT的工具工作示意图：
下面是具体的工作界面截屏：
生成代码：用户可以基于SysML和UML模型自动生成100%可运行的代码。
编译可执行程序：用户可以对生成的代码一键编译。用户可以对生成的可执行程序进行部署。
仿真测试：用户可以基于模型生成测试用例，发送请求给部署了可执行程序的设备，接收设备的响应，以模型方式显示测试结果。
如下是Simulator的操作演示>>
http://video.uml.com.cn/video/broVideoEA.asp?vidID=3432
如下是Simulator基于模型的设计~开发~测试（MB-DDT）工具
,详情请见：http://tool.uml.com.cn/ToolsEA/Simulator.asp
希望您读了此文后有所受益。如果您对MB-DDT（基于模型的设计~开发~测试）方法和工具感兴趣，欢迎讨论和交流。
如果您希望了解更多信息：
下载 pdf版：《MB-DDT
：基于模型的设计~开发~测试》
本文使用的建模工具为EA，可以下载试用版http://tool.uml.com.cn/ToolsEA/download.asp
作者简介：
|
俎涛，火龙果软件工程创始人，2001年创立了火龙果软件工程，2004年创立了IBM Rational用户组。1998年，曾作为骨干参与国家重点研究课题《面向特定领域基于组件的软件复用》，有幸比较深入的学习和使用的UML进行领域建模、提炼可复用组件和架构。在后来的研发项目中，一直采用模型进行分析设计，积累了一些心得和经验。20年来一直专注于MBSE，熟悉
UML、Sys ML、ArchiMate、BPMN、UPDM、DataModel等建模语言和规范，在以往的经历中，最大的感触是汇聚了很多精英人才的软件工程和系统工程领域居然几十年都是一种凌乱迷蒙的状态，从自己的经历所得，觉得清晰的模型，才是拨开工程迷雾的关键所在，所以不断研究和应用各种建模技术，并从自己的工程实践中提炼经验，形成对于自己可持续的方法论，例如《MBSE
从方法到实践指南》 《基于模型的三维研发管理》 《基于模型的需求管理》 《模型驱动的架构设计》
《基于模型的质量管理》 《基于模型的人员能力管理》 《iProcess过程改进方法》，目前正在作为产品经理和架构师，进行MBSE（基于模型的系统工程）平台的研发，希望建立要给基于模型的工程解决方案，后续会不断写些文章，希望能给同行一些借鉴。 |
后记
希望您读了此文后有所受益。
如果您有经验乐于分享，欢迎投稿给我们。
如果您对我们的培训、咨询和工具感兴趣：
| 
