IIRC,用例描述了系统的典型用法,对吗?但是用例图上的东西是什么,它们是如何连接在一起的?
你的用例图(是的,一个典型的项目会有不止一个)应该是你的 UML 套件中最简单的图。它们应该将您定义的角色/角色直接映射到系统的用例。事实上,他们应该主要关注单个 Actor,并且仅在必须参与特定用例时才包含其他 Actor。
这是我从谷歌上下来的一个例子:
示例用例图 http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png
注意简单。一个参与者,一个系统,5 个用例。没有其他的。
此外,正如@Eric P所建议的和我的示例图像所暗示的那样,您应该使用“[Verb] [Object]”结构命名您的用例;即“会员借书”变成“借书”。用例句子中缺失的主题(“成员”)在用例图中编码为与用例关联的参与者。
员工是使用该系统的人。成员仍然属于这里的演员吗?
恐怕这个答案是主观的。有人会说不,因为该系统仅供员工使用,所以员工是唯一的参与者。我个人不同意。
为什么?一方面,用例是需求收集阶段的一部分。它们可以帮助您组织系统的最终功能。Member
但是仅仅因为您当前的信念是该技术不会被该演员使用而否认该演员Member
是在该阶段限制您自己。
如果您的最终系统是自动化的,这意味着您自己Member
去终端检查一本书怎么办?如果您在收集需求时做出假设,您可能会错过重要的功能。
编辑:如何描述动作序列?有人告诉我,您可以看到使用关联,例如对某种重复例程的方法调用?这是正确的吗?以及如何扩展使用?
用例图是高级别的。它们应该显示您的高级功能(以每个用例的形式)和使用它们的 Actors,仅此而已。不要在你的用例图中乱扔扩展和包含;那些应该是罕见的和特殊情况。您可能犯的最大新手错误(相信我,我已经做到了!)是尝试在用例图中模块化您的代码。是的,我知道,这是任何称职的程序员都会尝试做的第一件事,但用例图不是做它的地方。
关于动作序列:在一套典型的 UML 图中,每个用例都与一个或多个Activity Diagrams相关联。这些大致类似于流程图,并用作大多数软件工程教科书鼓励的典型用例叙述结构的图形表示。
无论如何,我希望这会有所帮助。如果您还有其他问题,请随时提问!