关于图形化建模的典型

关于图形化建模的典型

那么，为什么不简单地把所有的流程都使用图形流程建模呢!根据我的经验，有些开发人员并非喜欢图形建模语言。下面是一些常见的总结他们对图形建模语言的关注。

如果开发人员认为他们错过了解决方案的重要部分，他们会感到不舒服。而图形化建模工具经常隐藏某些逻辑，比如配置属性面板或向导，不了解该工具的用户感觉他们错过重要的东西，他们从来没有完全自信过。相反，源代码不会隐藏东西，一个简单的解决办法可以是在图形视图和XML序列化文件之间切换视图。在该文件中,没有什么是隐藏的。另一个方便的策略是从编写流程模型开始

在一开始，如前所述，并切换到图形化建模方法当它变得更复杂的时候。降低开发人员的经验或开发速度:开发人员知道如何这样做很好地处理文本文件。他们是使用版本控制的专家在复杂的情况下选择、区分和合并源代码。等平台GitHub支持典型的开箱即用的用例。ide支持代码完成和复杂的模板，以提高开发人员的生产力。所以这很好工作地点。

现在，出现了一些奇怪的概念(图形模型)这并不适合他们的工具领域。你可能会认为这是部分正确的实际上会失去IDE的一些功能，比如已知类的代码补全和方法，当编辑模型。但它也有部分错误，你可以很好地在序列化上做diff和merge图形模型的格式，例如XML文件，它只是存储在您的版本中控制。有些工具甚至允许在BPMN之上进行图形差异处理。但更重要的是，这个问题基本上是无关紧要的。“结合流程模型您可以用流程模型或代码来表达逻辑，并简单地组合它们。所以流程模型表示“仅”任务序列和所有其他逻辑仍然包含在正常的编程代码中。拒绝流程模型的另一个原因：有些开发者并不接受这一事实，普通人能理解他们在做什么。他们是艺术家当然，一个正在运行的程序背后一定有一些神秘的东西。这也节省了他们未来的工作。或者至少这加强了他们作为艺术家的地位。有了这个在你的项目中使用思维模式显然会导致未来的大问题，你一定要解决它。在过去的几十年里，软件工程发生了很大的变化，我知道当前的项目也是如此将他们的大部分时间投入到讨论需求和勾画正确的解决方案，只是明天再改一遍。敏捷方法和协作到处都是，图形化的流程模型是其中的一个重要部分。一个相关的警告是，一旦您有了图形化的流程，业务涉众就会一直干扰开发，并希望加入所有的对话围绕解决方案设计。我看到过这种情况。但解决办法不是跳过图形化模型，而不是学习如何正确地应用它们。主要是关于尊重项目的不同角色。可执行流程模型也是源代码。它是解决方案设计的一部分，因此由人们负责构建解决方案(即开发团队)。他们需要最后一次选择如何设计，如果有好的技术原因来改变一个模型，他们需要被授权去做这件事。当然，他们需要能够向其他涉众解释他们的理由。与此类似，需要包含流程模型进入软件开发人员的工具链和CI/CD管道。