用例图的本质

对于学校作业,我们必须制作一个Usecase图表.但是我们拥有的文档并没有得到很好的扩展.它只描述了一个用例组成的组件,以及一个例子.
我们必须制作一个关于图书馆系统的用例.我们找到了11个用例,但我不会打扰你.

IIRC,一个用例描述了系统的典型用法,对吧？但是什么东西属于用例图,它们如何连接在一起？

我们现在有四个参与者(成员,员工,经理和会计).我们遇到的问题最多的是会员和员工.
员工是使用该系统的人员.会员还是作为演员在这里吗？

我们有一些用例:

会员加入图书馆.

会员改变他的记录.

会员借了一本书.

成员部分库(取消订阅).

会员预订一篇文章.

会员退票.

会员支付(部分)费用和罚款.

那些成为图表上的用例.但是,如果有更多的用例,例如,员工进入会员编号,员工进入簿记号等(使用？).

任何人都可以对此有所了解吗？

编辑: 如何描述行动序列？我被告知你可以看到一个使用关联,就像一个方法调用某种常规再次出现？这是正确的吗？如何扩展使用？

IIRC,一个用例描述了系统的典型用法,对吧？但是什么瘦[g]属于用例图,它们如何连接在一起？

您的用例图(是的,一个典型的项目将有多个)应该是您的UML套件中最简单的图表.他们应该将您已定义的Actors/Roles直接映射到系统的Use Cases.事实上,他们应该主要关注单个Actor,如果他们必须参与特定的用例,则只包括其他Actors.

以下是我离开谷歌的一个例子:

示例用例图http://java.sun.com/mailers/newsletters/fundamentals/img/usecase.png

注意简单.一个演员,一个系统,5个用例.没有其他的.

另外,正如@Eric P建议的那样,我的示例图像暗示,您应该使用"[动词] [对象]"结构标题您的用例; 即"会员借书"成为"借书".您的用例句子("成员")中缺少的主题在您的用例图中被编码为与用例关联的Actor.

员工是使用该系统的人员.会员还是作为演员在这里吗？

我担心答案是主观的.有些人会说不,因为系统只供员工使用,所以员工是唯一的参与者.我个人不同意.

为什么？例如,用例是需求收集阶段的一部分.它们可以帮助您组织系统的最终功能.但是否认这位Member演员只是因为你当前的信念是技术不会被用来Member限制自己在那个阶段.

如果您的最终系统是自动化的,这意味着Member要到终端自己检查一本书怎么办？如果您在需求收集期间做出了假设,那么您可能会错过重要的功能.

编辑:如何描述行动序列？我被告知你可以看到一个使用关联,就像一个方法调用某种常规再次出现？这是正确的吗？如何扩展使用？

用例图是高级别的.它们应该显示您的高级功能(以每个用例的形式)和使用它们的Actors而不是其他任何东西.不要使用扩展和包含来丢弃您的用例图; 那些应该是罕见的,只有特殊情况.你可以做出的最大的新手错误(相信我,我已经成功了!)是试图在你的用例图中模块化你的代码.是的,我知道,这是任何值得他的盐尝试做的程序员的第一件事,但用例图不适合它.

关于操作序列:在一组典型的UML图中,每个用例都与一个或多个活动图相关联.这些大致类似于流程图,并作为大多数软件工程教科书鼓励的典型用例叙述结构的图形表示.

无论如何,我希望这会有所帮助.如果您有其他问题,请随时提出!