首页 > 代码库 > 一种工业级系统交互建模工具的应用--EventStudio System Designer
一种工业级系统交互建模工具的应用--EventStudio System Designer
一种工业级系统交互建模工具的应用
【摘要】
本文以探索如何维护大规模复杂系统交互设计模型为目的,以EventHelix公司的商业付费软件EventStudio System Designer为建模工具,对大规模复杂系统的交互设计进行了应用,认为类ESSD的设计工具能大幅降低系统设计建模的开发和维护复杂度。
【关键词】
系统交互建模 建模语言 EventStudio System Designer
一、问题的提出
软件开发人员日常工作中经常需要绘制系统交互流程图,比如顺序图和活动图等,以描述系统设计行为供研发内部使用或用于外部客户交流。如果是单一简单的流程图,问题不大,传统的UML建模工具能轻松应对;但如果是规模庞大场景复杂且有相互关联的一系列流程图(长达数百页),通过传统的建模工具开发可能会导致共享片段重复/格式不一致/不易于变更等诸多问题。以上问题,有没有更好的建模方法和工具能解决?
分析目前传统的UML建模工具,对于规模庞大场景复杂的一系列系统交互流程图的绘制,在开发和维护上有如下问题:
l 传统的建模工具通过UI界面操作,不支持通过提供建模语言的方式“编译”生成流程图;
l 流程图的描述成为建模工具所特有的二进制文件,不能所见即所得,比如类似makedown的技术;
l 多个场景下相同的流程片段无法做到共享或引用,只能通过硬拷贝实现;
l 数量巨大的顺序图,如何维护统一的格式也是问题;
l 同一场景不同粒度下的呈现只能拆分成不同的流程图,无法按照detail粒度自适应生成;
l 通常情况下,不能对格式进行定制;
二、解决思路
通过以上的分析可以看到,导致目前传统UML建模工具对支持“规模庞大场景复杂的一系列系统交互流程图”效率底下的原因,主要是缺乏对领域建模语言的支持。即,是否支持通过领域建模语言的方式对流程图进行描述,并通过编辑器对建模语言所描述的流程图提供UI展现。
通过对现有开源和商业建模软件的比较分析,找到一个无限接近笔者要求的建模应用,即本文要重点介绍的EventStudio System Designer(以下简称ESSD),由EventHelix出品,目前商用发布版本已经更新到v6版本。
ESSD作为一种全新的系统工程建模方式,支持以下特性:
l 强大而简单的建模语言
提供了FeatureDescription Language(FDL)作为建模语言,能定义系统架构边界,描述消息交互流程,支持定时器等语言特性
l 更关注System Engineering而不是diagram layout
l 在生命周期早期发现错误
l 支持对不同的抽象层次进行自适应呈现
l 支持对多种场景建模
多个场景间相同的部分可以只定义一份,自动生成一大堆成功和失败的场景
l 丰富多余的应用程序
l 对模型进行切割和分析
l 支持定制化diagram
详细的说明,请参见ESSD用户手册。
三、实践情况
LTE控制面对UE基本流程和移动性流程的系统交互建模进行了应用试点,分别从以下几方面阐述ESSD在项目中的应用情况:
l FDL的基本语言特性
l ESSD的实践结果
3.1 FDL的基本语言特性
1. 如何定义系统模块与组件
FDL中通过“module”定义模块,“component”定义组件,“xx_component in xx_module”的方式定义组件与模块的关系,如下图所示:
通过上面的定义,FDL生成流程图时就可以生成以下流程图的表头,用于标识UML中的系统交互对象:
最多支持5层架构,
2. 如何描述消息交互
FDL中通过“->”描述消息的发送,发送方在前,接收方在后。同时可以对消息名字和补充说明进行描述。
FDL生成的流程文档如下所示:
3. 如何使用注释(C-Type Comments,Remarks和Block Remarks)
FDL中以/* comment*/的方式支持FDL代码中的注释,以(* remark*)的方式支持消息的简短说明,以[*block remark*]的方式支持消息流程交互的补充说明。
FDL生成的流程图如下图所示,分别为“remark”和“blockremark”方式:
4. 如何进行分支定义(Case,IF-ELSE-ENDIF)
FDL中以case-endcase的方式支持流程的局部细节差异化,case-endcase区间内以leg标识不同的分支场景,也可以对leg标识进行if的判定。
每个分支场景作为一个独立的branch,在单个FDL生成流程图时会弹出编辑框,让用户选择以确定每一种确定场景下拥有的所有分支(leg)。
5. 如何进行流程片段共享(include)
对公共的流程片段,可以在独立的FDL中进行定义,通过include的方式进行引用。
3.2 ESSD的实践结果
以下为ESSD在项目中的实践结果,
场景类型 | FDL文件数 | FDL代码总行数 | 生成流程图文档页数 | 流程图个数 | 备注 | |||
UE基本流程 | 4 | 391 | 25 | 17 | 包含2个的高度复用片段,54行 | |||
UE移动性流程 | 2 | 371 | 18 | 15 | 包含2个的高度复用片段,54行 | |||
| | | | | | |||
总体来讲,通过ESSD在项目中的应用,发现以下比较明显的优势:
? 通过include FDL文件的方式支持片段共享
? 支持局部分支场景的差异化,进而自动演变成多个独立的流程
? 自动调整格式并输出
? 流程文档规范专业,适合与客户交流时使用
同时也发现了以下不足:
? 不支持Unicode,即不支持中文,一大硬伤
? 比较遗憾,目前商用版本只提供45天的free trial,需要按license付费,最便宜的单个license版本也要299刀
四、效果评价
通过在项目中对ESSD的应用,对于规模庞大场景复杂的一系列流程图的设计,确实能尽极大的消除重复,让设计人员集中精力关注建模本身。
五、推广建议
本次ESSD在项目中的应用实践在笔者看来可以分为两个层次,一方面是应用程序本身,另一方面是方法论。
首先,ESSD的设计优势确实能有效降低对流程图的设计和维护复杂度。对于“规模庞大场景复杂的一系列流程图的设计”(反复强调这个应用场景是因为笔者觉得单一简单的设计用这个应用所带来的增益不明显),强烈推荐ESSD。
其次,ESSD通过FDL的思路解决建模问题能给我们哪些启迪。领域建模语言(Domain Modeling Language)的应用日趋火热,问题域的复杂度与日俱增越来越让大家倾向于通过DSL来描述特性领域的特定问题,而让大部分的复杂度隐藏在DSL背后。除了ESSD对FDL的应用,近来流行的makedown对文档编辑的革新,也是类似的思路。笔者是在接触DSL之前先使用的ESSD,后来才发觉两者有共通之处,同时个人也坚信DSL是未来大规模复杂软件和问题域解决的重要方向。
所以ESSD软件和ESSD对建模设计问题的解决思路,都值得大家去尝试和使用,相信一定会有所收获。
参考资料
1. EventStudio_System_Designer_Manual.pdf
2. getting-started-eventstudio.pdf
3. sequence-diagram-tutorial.pdf