Question

我做了一些分析，并使用了许多工具来捕获需求：用户创建的故事板，用例，GUI绘图，GUI原型，用户故事＆amp;可以用作验收标准的场景等。

虽然每一项都有或多或少的优点，但我认为有一点重要。这些方法可以准确地捕获用户与您的应用程序交互的方式，但是程序员需要创建和开发应该反映在代码中的“模型”。

我最近一直在阅读Evan’s DDD，他提出了不同的建议。您需要与域专家一起创建域模型并与他共享。为了与用户交流想法，他在书中经常使用ad-hoc UML启发的绘图。

我想知道这是否是与域专家谈论该模型的最佳方式。除了UML图之外，还有其他任何工具可用于捕获领域知识并在您与领域专家讨论域时使用它吗？

Answer 1

虽然最终抽象为一个工作领域模型（最终是一个稳定的模型）是你的开发人员的工作，我同意即使是上面的工具集也可以限制，并限制你自己或你的通信只是UML可以使对话看起来对领域专家来说是深奥的。

对于系统解剖，请尝试http://www.fmc-modeling.org/处的方框图表示法工具。

对于白/黑板和思维导图尝试FreeMind

对于联想组织（和酷），请尝试TheBrain

对于更快/协作的图表（一种新的），请尝试LucidChart

当然，好的词典和词库总是在总是争取最好的术语。

如果这些似乎对你有好处，请记住，建模是由一方代表两人完成的左脑分析。使用纯粹定义的线性过程时，您将不会获得与试错法，自由运行样式信息挖掘相结合的过程。

Answer 2

最好的方法是铅笔和纸。 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

Answer 3

您可以使用/吨工具丢失：

演员地图
演员表
商业政策
商业规则
上下文关系图
决策表或决策树
域名模型
活动表
流程图
方案
Statechart Diagrams
用例
思维导图
..

关于他们每个人都有很多漫长而乏味的书。有些工具在某些情况下工作“最好”，而“可能在其他情况下失败”。没有什么比“最佳”更重要了：语境问题。

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

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

协作要求：确定需求的工作坊，艾伦 Gottesdiener

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

但要小心不要成为模板僵尸 [这是需求区域的一般疾病]

您甚至可以使用游戏来实现更好的协作：

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

Answer 4

领域专家倾向于比其他任何方式更好地理解句子。这就是我喜欢Object-Role Modeling的原因。很多开发都与图形方法有关，但在实践中我发现最好只使用结构化句子。

Answer 5

我所做的是为需求创建用例图。我可以在模型级别保存所有需要的信息。我的用例图可以保存几乎所有我需要建模的复杂系统。

我也可以在多个图表中重用相同的用例，并且仍然保留其属性。真的很棒的技术。

关于使用UML的域I nix用例和类图元素在同一个图中，并且都添加了一个数据库配置文件，允许我在类图中添加持久性。因此，这是使用数据库规范的对象建模。

我的建模非常复杂，我创建了我的数据库，可以永久地重构我的要求，并立即重构我的代码而不会丢失我的模型。

我每天都使用它，非常喜欢它。希望这有帮助。

Answer 6

我个人发现最有效率的方式就是坐下来动态编写域模型，同时经常向我旁边的域专家询问是/否问题。这只有在你足够快和编码时才有效。

同样 - 构造良好（树应该像句子一样）无处不在的语言地图是很好的沟通方式。易于创建，分享和理解。

真实世界的例子：

Payment
    comments
        can be edited
            if user is authorized
                with role [Role]
    can be approved
        if user is authorized
        if payment is initiated
        if payment is not paid yet
        if amount does not exceed allowed budget
    when approved
        remembers that
        saves approving date
    can be rejected
        if something something...
    when rejected
        forgets planned pay date
        resets amount to be paid

（如果您想在here工具中查看

，请从text2mindmap复制）

转化为：

public class Payment{
    public virtual void EditComments(string comments){
        Authorize<EditPaymentComments>();
        CommentsEntered=true;
        CommentsEditedBy=User;
        CommentsEditedOn=SysDateTime.Now();
        Comments=comments;
    }
    public virtual void Approve(){
        EnsureCanBeApproved();
        IsApproved=true;
        ApprovedOn=SysDateTime.Now();
        Raise(new Approved(this));
    }
    protected virtual void EnsureCanBeApproved(){
        Authorize<AcceptPayments>();
        ThrowIf(!IsInitiated,
            "Payment is not initiated.");
        ThrowIf(IsPaid,
            "Payment is already paid.");
        ThrowIf(ExceedsAllowedBudget(ToBePaid),
            "Amount to be paid exceeds allowed budget.");
    }
    public virtual void Reject(){
        EnsureCanReject();
        ForgetPlannedPayDate();
        ToBePaid=0;
        IsInitiated=false;
        IsRejected=true;
        Raise(new Rejected(this));
    }
    private void ForgetPlannedPayDate(){
        Deadline=DateTime.MinValue;
        DeadlineKnown=false;
    }
}

Answer 7

到目前为止，工具有很多很好的建议。尝试使用它们并使用您喜欢的那些，但成功的关键是代码和会话之间的迭代 ...... Evans称之为知识运算。您越多地倾听域专家的意见，对您在代码中听到的内容进行建模，然后向他们展示软件，获取反馈并调整模型，您就可以越接近解决手头问题的软件。

Answer 8

对我来说，这取决于领域专家。

对于某些人来说，这是在白板上绘制UI的一个问题 - 显示它在屏幕上的外观 - 然后问一些问题：“没有那个可以存在吗？”，“你有情况吗，这个一个是第一个稍后添加的，或者他们总是那里“，”你希望它们填写哪个顺序？“，”谁需要知道这个屏幕是什么？“...通常，视觉帮助他们进入一个他们可以非常准确地回答你的问题的情况。

其他人，我可以使用天真的UML（显示聚合，值类型，属性和集合），它们也可以。

真的，对我来说这很简单，我开始很简单 - 继续添加技术性的东西，直到他们的眼睛一片空白 - 然后再退一步。并始终有一些起点，以获得创造性的果汁。如果你被困住了，只要看看我的工作 - “等一下 - 你为什么不记录这些信息？”，“哇，你做了什么？” - 对我而言，这些工具只能帮助我，他们很少帮助领域专家。

基本上，知识在笔和纸旁边几乎没有工具（如果可能的话，还有白板）。

与域专家一起建模域的最佳方法

8 个答案: