用例图的本质 [英] The essense of usecase diagrams

问题描述

对于学校作业，我们必须制作用例图.但是我们拥有的文档并没有很丰富.它只是描述了一个用例由哪些组件组成，以及一个示例.
我们必须制作一个关于图书馆系统的用例.我们已经找到了 11 个用例，但我不会全部都打扰您.

For a school assignment, we have to make a Usecase diagram. But the documentation that we have, is not very extended. It just describes what components a usecase consists of, and one example.
We have to make a usecase about a library system. We have found 11 usecases, but I won't bother you with all of them.

IIRC，用例描述了系统的典型用法，对吗?但是用例图上有哪些内容，它们如何连接在一起?

IIRC, a usecase describes a typical usage of a system, right? But what things belong on a usecase diagram, and how do they connect together?

我们现在拥有四位参与者(成员、员工、经理和会计师).我们遇到最多问题的是会员和员工.
员工是使用该系统的人.成员还属于这里吗?

What we have now are four actors (member, employee, manager and accountant). The ones we have most problems with are member and employee.
The employee is the one who is using the system. Does a member still belongs here as an actor?

我们拥有的一些用例:

• 成员加入图书馆.
• 成员更改了他的记录.
• 会员借书.
• 成员将图书馆分开(取消订阅).
• 会员预订文章.
• 会员还书.
• 会员支付(部分)费用和罚款.

那些成为图表上的用例.但是是否应该有更多用例，例如，员工输入会员编号，员工输入书号等等(用途?).

Those become usecases on the diagram. But should there be more usecases, like, employee enters membernumber, employee enters booknumber and so on (uses?).

任何人都可以(?)对此有所了解吗?

Can anyone shed(?) a light on this?

如何描述动作序列?有人告诉我，您可以看到使用关联，例如对某种重复发生的例程的方法调用?这是正确的吗?以及如何使用扩展?

How are sequences of action described? I've been told you can see a uses association like a method call to some kind of routine which recurs? Is this right? And how is extended used?

推荐答案

IIRC，一个用例描述了一个典型的使用系统，对吗?但是什么Thin[g]s 属于用例图，并且它们是如何连接在一起的?

您的用例图(是的，一个典型的项目将有多个)可能应该是您的 UML 套件中最简单的图.他们应该将您定义的角色/角色直接映射到系统的用例.事实上，它们应该主要关注单个 Actor，并且仅在必须参与特定用例时才包括其他 Actor.

Your Use Case diagrams (yes, a typical project will have more than one) should probably be the simplest diagrams in your UML suite. They should map Actors / Roles that you have defined directly to the Use Cases of your system. In fact, they should focus primarily on a single Actor and only include other Actors if they must participate in a particular Use Case.

以下是我从 Google 下载的示例:

Here's an example that I got off Google:

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

注意简单.一个参与者，一个系统，5 个用例.没有别的.

Note the simplicity. One Actor, one System, 5 Use Cases. Nothing else.

此外，正如 @Eric P 所建议的和我的示例图片这意味着，您应该使用[动词] [对象]"结构为您的用例命名；即会员借书"变成借书".用例句子中缺少的主题(成员")在用例图中被编码为与用例关联的参与者.

Also, as @Eric P suggested and my example image implies, you should title your Use Cases with a "[Verb] [Object]" structure; i.e. "member borrows a book" becomes "Borrow Book". The missing subject of your use case sentence ("member") is encoded in your Use Case diagram as as an Actor with an association to the Use Case.

员工是使用系统.会员还在吗作为演员属于这里吗?

恐怕这个答案是主观的.有人会说不，因为系统只被员工使用，所以员工是唯一的参与者.我个人不同意.

I'm afraid the answer to that is subjective. Some will say no, that because the system is only being used by the employee, then the employee is the only actor. I personally disagree.

为什么?一方面，用例是需求收集阶段的一部分.它们可以帮助您组织系统的最终功能.但是，仅仅因为您目前认为 Member 不会使用该技术而拒绝 Member 参与者就是在那个阶段限制自己.

Why? For one, Use Cases are part of the requirements gathering phase. They are there to help you organize the eventual functionality of the system. But to deny the Member Actor simply because your current belief is that the technology will not be used by the Member is to limit yourself in that phase.

如果您的最终系统是自动化的，这意味着 Member 自己去终端借书会怎样?如果您在需求收集期间做出假设，您可能会错过重要的功能.

What if your eventual system is automated, meaning that the Member goes to a terminal to check out a book herself? If you made an assumption during requirements gathering, you might miss out on important functionality.

动作序列如何描述?我被告知你可以看到a 像方法调用一样使用关联到某种重复出现的例程?这是正确的吗?以及如何扩展用过吗?

How are sequences of action described? I've been told you can see a uses association like a method call to some kind of routine which recurs? Is this right? And how is extended used?

用例图是高级别的.它们应该展示您的高级功能(以每个用例的形式)以及使用它们的 Actors 而不是其他任何东西.不要用扩展和包含乱扔你的用例图；这些应该是罕见的和特殊情况.您可能犯的最大新手错误(相信我，我已经犯了！)是尝试在您的用例图中模块化您的代码.是的，我知道，这是任何值得他的盐的程序员尝试做的第一件事，但用例图不是它的地方.

Use Case Diagrams are high level. They should show your high-level functionality (in the form of each Use Case) and the Actors that utilize them and nothing else. Don't litter your Use Case Diagrams with extends and includes; those should be rare and special-case only. The biggest rookie mistake you can make (and believe me, I've made it!) is to try to modularize your code inside your Use Case diagram. Yes, I know, it's the first thing any programmer worth his salt tries to do, but Use Case diagrams are not the place for it.

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

Regarding sequences of action: in a typical suite of UML diagrams, each Use Case has associated with it one or more Activity Diagrams. These are roughly analogous to a flow chart and serve as a graphical representation of the typical Use Case narrative structure that most Software Engineering textbooks encourage.

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

Anyway, I hope this helps. If you have other questions, feel free to ask!

这篇关于用例图的本质的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！