我正在为我编程的跳棋游戏创建一个用例图。制作这些产品时你真的应该去多深入?我读到它们应该很简单,但这有点模糊。我是否需要创建更多箭头,例如“移动常规”(这意味着移动常规棋子,反对国王)和“跳跃”?或者没有那里的连接好吗?我只是不想制作太多箭头,因为它会开始变得非常混乱。任何意见都将不胜感激。
答案 0 :(得分:3)
如何深入和多么简单取决于很多因素,基本上是回答"为什么你需要它" 和"谁会读它& #34;
实际上,可以帮助您做出决定的问题和指南以及其他实践可能会很长。 Scott W. Ambler的在线书籍Agine Modeling: Agile/Lean Documentation: Strategies for Agile Software Development一章中列出了特别有用的内容。
您应该非常清楚的一件事是您需要/想要什么样的UML图
用例图中的箭头不是任意连接线,而是具有精确含义,尤其是<<include>>
和<<extend>>
关系,请参阅http://www.uml-diagrams.org/use-case-reference.html了解其定义和示例
除了是图形气泡外,用例还表示actor如何与设计中的系统进行交互。然后以更多/更少形式化的文本形式描述气泡的内容,参见Wikipedia: Use case,尤其是Alistair Cockburn's use case pages,因为他基本上定义了该术语的意义(后来由UML采用),他的意见很重要。
在您的情况下,King Piece
气泡似乎不包含在内,或延伸Start Game
发起的Player
气泡,我不知道步骤的顺序可能隐藏在其文本表示中(或在您的代码中)。
您开始绘制的内容看起来更像UML Activity Diagram,例如
和一些解释链接:
答案 1 :(得分:2)
这里的用例少得多。请参考我自己绘制的下图:
其他要求可以用用例规范编写,特别是业务规则。
用例名称:移动部分
演员:玩家(小学)
前提条件:******
后置条件:******
利益相关者和利益:******
基本路径:
玩家选择一件作品和目的地广场,然后提交移动请求。
系统验证目标方格。
系统移动棋子并计算移动。
系统显示移动结果。
例外路径:
2a上。目的地广场无效:
2A1。系统****
业务规则:
有效的目的地广场:......
计算规则,如王牌,赢得游戏......