问与领域专家一起对领域进行建模的最佳方法

EN

虽然对工作领域模型(以及最终的稳定模型)的最终抽象是您、开发人员的工作，但我确实同意，即使是上面的工具集也会受到限制，并且将您自己或您的沟通限制在UML上可能会使对话对领域专家来说看起来很深奥。

有关系统剖析，请尝试http://www.fmc-modeling.org/上的方框图表示法工具。

要查看白板/黑板和思维导图，请尝试FreeMind

对于关联组织(和酷炫)，请尝试TheBrain

要获得更快的/协作图形(某种新功能)，请尝试使用LucidChart

当然，好的老词典和同义词总是，总是争取最好的术语。

如果这些对你来说似乎是右脑的，请记住，建模是由一方代表两方完成的左脑分析。与纯粹定义的线性过程相比，当它与试错、自由运行风格的信息挖掘结合在一起时，您将不会获得更多。

最好的方法是铅笔和纸。UML以及之后不会出现的东西。从DSL (谈论领域时使用的词汇表列表)开始。然后，您可以使用该列表来确定什么是实际内容(模型、聚合、动作动词等)，然后您可以进行关联。

在所有这些之后，然后制作您的UML图，并与领域专家一起检查它。如果他们能理解，那么你就是金子。

这本书完全按照我说的做。我建议至少浏览一下这本书(实际上我不知道你是否在使用.NET)。http://www.amazon.com/Professional-Refactoring-ASP-NET-Wrox-Programmer/dp/047043452X/ref=sr_1_1?s=books&ie=UTF8&qid=1306529986&sr=1-1

您可以使用的工具有很多：

Maps

• ..

• Actor Map
• Actor Table
• • Rules
  • Context Diagram
  • Decision Table or Decision Table
  • Process Map
  • Scenarios
  • Statechart
  • Context

  <代码>H113域模型

  • 事件图
  • 用例
  • Mind Maps
  • ..

关于他们中的每一个，都有很多冗长而无聊的书。有些工具在某些情况下“最好”，在另一些情况下“可能会失败”。没有什么比“最好的”更好的了:上下文很重要。

但重要的不是技术本身：重要的是你如何应用它们...。

的诀窍是如何与客户--领域专家--终端用户“协作”。协作--研讨会通常在许多情况下都是最好的。下面这本书在这方面做得很好。

协作的

需求:定义需求的研讨会，Ellen Gottesdiener

检查http://ebgconsulting.com/facassets.php

但要小心，不要做模板僵尸，这是需求领域的通病

你甚至可以使用游戏来进行更好的协作：

创新游戏:通过协作游戏创造突破性产品，Luke Hohmann