上周，Obeo 发布了对其Obeo 设计器产品的一次较大规模的升级。该产品的一个核心目标就是只需基于 Eclipse GMF（图形化建模框架）而无需 GMF（或 EMF，Eclipse 建模框架）方面的知识就能提供创建域特定建模工具的能力。该工具是基于“视角”的概念:
视角这个名词是一种抽象概念，它为某一系统提供某种规范，且这一系统只存在某一系列的特定问题。在 IEEE 1471 规范中有详细介绍。在本文中，我们用它来为用户提供针对某一特定关注点的一系列可视化呈现。
针对每个视角，用户可以定义展现的内容及其图形化功能、工具面板以及相关行为。图形化部分被分离成多个行为部分。Obeo 设计器提供了不同视角之间以及和 UML 的集成。UML 建模器将在几个月后发布。
InfoQ 就这次新发布与来自 Obeo 的 Jerome Benois 和 Freddy Allilaire 进行了交谈。
InfoQ：为什么你们认为企业需要加强建模能力？
Obeo：建模从广义上是从技术中得以抽象，使其达到“为人所理解”的层次。工具也可以关注解决业务难题，而不仅仅是技术限制。使用 Obeo 设计器，业务经理和软件架构师们就有能力定义并共享一套通用的语言。建模形成了自然也就有助于他们交流的一致性。企业里的每个角色都可以根据其特定的词汇和关注点表现出某一通用的模型。
Obeo 的建模方法通过基于 DSL（领域特定语言）和视图从而上升到这种抽象层面。通过分析系统必须满足的需求和约束条件，我们可以很方便地开发一些模型去呈现系统。最初的建模工具在对待类似 MDA 和 UML 这类标准上都有些“教条化”。这些标准不能够针对客户情况进行调整从而使信息技术适配业务需求。每逢这种情况，用户只能调整其语法来适应这些工具，妥协必不可少。工具提供商不得不面临定义一套最综合全面的语言的难题。
DSLs 为每个域提供了专门的形式体系而只需要尽可能少的语法和概念。结果就是与业务更进一步的协调以及建模的简化。然而，如果一个较大的组织中存在几个截然不同的业务单元时，整套 DSL 方法开发起来还是比较困难的。这必然会导致出现针对各个业务单元的多个体系。我们认为最好是定义一套由所有利益关系人共享的通用语言，一种无所不在的语言。为了提高效率并被所有利益关系人所共享，有必要采用一种投射性的方法。IEEE 1471/D4.1 标准以在一个系统中视角的概念解构了这种方法。每个视角关注在每个给定的问题上。这种解构使得分析流程变得简化，因为流程被划分成了几个清晰定义的关注点上。各视角都针对某一既定方面的信息回答了一系列问题，分析人员使用“各个视角”来验证某一给定的架构是否符合透视的不同规则。这种方法基于的是关注点分离和完善迭代信息的原则，但主要还是从多个特定视角去挖掘统一模型。模型工程学和 MDA 是与此类方法可以达到最大的一致性的方法，因为它们能够准确无误并清楚的定义这些概念并相对应这些概念来操作统一的模型。
InfoQ：可以跟我们分享一下你们的用户使用 Obe 设计器解决的一些问题吗？
Obeo：通常，用户使用 Obeo 设计器来协同设计一些受制于很多约束的复杂项目。用户可以开发若干个工具，这归功于 Obeo 设计器不同视角（逻辑的、物理的、安全方面等等）的分离。此方法非常通用，最近，我们惊奇的发现有人已经把我们的方法应用到机器人技术上了。
在业务建模领域，我们的产品可以用来，比如，支持保险服务产品及产品目录。在财务领域，我们有客户将产品给财务分析人员使用，以一种综合的语言来进行定价和制定业务规则。
在企业架构领域，Obeo 设计器被用来支持企业转型。它从几个关键的视角对 TOGAF（开发组织架构框架）提供支持：战略视角、业务视角、数据视角、应用视角和技术视角。该单元模块支持由开放组织规范定义的核心图表和矩阵。
在系统工程学领域，用户可以使用我们的产品来支持基于硬件 / 软件一致性和功能性分析的系统验证和核对。
在进行非功能需求分析时，Obeo 设计器可以用来支持生成时间约束性分析和风险分析工件。
我们很快会在我们的站点上增加一些新的案例分析。
InfoQ：你什么时候会推荐用户创建图形化设计器而不是文本型编辑器？
Obeo：有些用户，通常比较技术的那些，更喜欢文本性标注。基于文本语法的计算指令对于我们大多数人来说会更加自然和高效。而从另一方面来看，图形化标注提供了较高层次的抽象。业务一般也倾向于使用图形化方式呈现。有些图形化呈现对人们来说很自然，比如将一个集合以树状的形式表现，或者用箭头连线几个盒子的方式呈现一个串行化过程。使用画图来展现一个工作流或设计一个奇思妙想是更为自然的方式。Obeo 设计器能为你在图形化呈现上提供很大的帮助，这也是这个产品很重要的一个价值所在。除此之外，产品还提供了其他一些呈现方式，比如图表和矩阵。你也可以在同一个编辑器里混合使用图形和文本两种建模方式，这样可以结合利用两者各自的优点。我们的产品完全能够兼容 Xtext（一种为你的域模型提供文本语法的工具）和 EEF（一种为你的域模型提供表单呈现的工具）。
InfoQ：在过去，代码生成器在融入软件构建过程中遇到了一些困难，目前有何改变呢？
Obeo：第一代代码生成器大多都是基于黑盒方法的。这些方案都不适用于特殊用户的需求。这种类型的方案仅仅可用于生成代码的框架。自然，你的入口点和与其对应生成的代码之间的同步也就很快失去了。从代码生成的观点来看，收效甚微。
我们可以注意到，代码生成其实一直都是存在的！那什么是代码编译呢？所幸目前大多数的人都不必去写汇编代码，代码生成对我们来说是完全透明的。
代码生成工具（尤其是那些基于建模的）着实有了进展：提供了更加简化的语法、高效的代码生成、可以与 IDE 工具（如 JDT）相提并论的高级特征。在 Obeo 设计器中，负责生成代码的是 Acceleo。Acceleo 是由 Eclipse 基金支持的一款基于 MDA（模型驱动架构）编程视图的开源代码生成环境。从 MOF（Meta-Object Facility，元对象机制）模型到文本语言，它推行 OMG 规范。它使得应用（或部分应用）可以自动生成，而且适用于敏捷开发活动。在应用体系中的调整可以比手工构建更快速。Acceleo 是可适配的，它提供了一些预设的满足特定需求的方案。除了 Acceleo，Obeo 设计器也提供了 Obeo 可追溯功能，可以用来探测并修正所有你的应用代码和模型之间出现的不一致和同步问题。
但是代码生成并不是万能解决方案。在开发过程中，软件架构师应该仔细地判断技术决策是归属于框架的还是代码生成器的。这没有一个统一的答案，要具体问题具体分析。
注册/登录 InfoQ 发表评论