如何建模简单的用例图
假设您必须为这个简单的问题制作一个用例图（这是我正在做的一个更大的练习的一部分）：（
网络应用程序的）注册用户可以通过两种方式搜索旅游景点：按类别（例如：博物馆、公园、剧院、考古遗址）或按地点（城市、县）。
我应该如何为这个 UCD 建模？
最简单的方法是：参与者（注册用户）、两个用例（按类别搜索旅游景点和按位置搜索）、次要参与者（Web 应用程序的服务器，它将处理查询并返回结果） ）。
我担心的是，这样四种类别和两种类型的位置将不会出现在用例中。
我正在考虑使用“扩展”关系。例如，我将添加一个名为“搜索公园”的用例，该用例扩展了“按类别搜索”的用例。扩展点将是用户选择搜索公园的事件。
或者我可以使用“按类别搜索”和“搜索公园”之间的继承关系...嗯...我有点困惑...
你将如何使用美元来模拟这个小问题？
谢谢你， 卢卡
suppose you have to do a Use Case Diagram for this simple problem (that is part of a much bigger exercise i am doing):
a registered user (of a web application) can search for tourist attractions in two ways: by category (for example: museums, parks, theaters, archaeological sites) or by location (city, county).
How should i model this UCD?
The most simple way would be: the actor (registered user), two use cases (search tourist attraction by category and search by location), the secondary actor (the server of the web application, which would process the query and send back the results).
My concern is that in this way the four categories and the two type of locations would not be present in the use case.
I was thinking of using the "extend" relationship. For example, i would add a use case named "Search parks" that extends the use case "Search by category". The extension point would be the event that the user chooses to search for parks.
Or i could use an inheritance relationship between the "Search by category" and "Search parks"...mmmm...i am a little confused...
How would you model this little problem using USD??
Thank you,
Luca
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
首先，您必须认识到，用例图不能替代实际（书面）用例。用例描述包含许多重要的细节，这些细节在用例图中被省略。用例图非常适合描述参与者的层次结构、关联的用例以及用例之间的关系，但仅此而已。
另一件重要的事情是认识到用例实际上是什么。思考它们的好方法是找到演员的目标，他/她希望在系统的帮助下实现该目标。实现这一目标应该会给演员带来一些商业价值。我的观点是，根据您的描述，注册用户可能想要搜索观光景点和/或购买门票。所以这是他的目标，这应该是一个用例，不要将用例与功能/特性（例如不同的搜索方式等）混淆。
在您的第一个建议中，您有两个用例，它们仅在数据上有所不同（例如，它可能只是与表单中的组合框不同的选择）。如果此类差异不影响系统和参与者交互的方式，则它们将与您在用例中引用的数据术语表中的用例分开描述。这样您就可以避免用例描述中的许多不必要的细节。另一方面，如果描述中的步骤发生变化（例如，当注册用户选择位置时，系统为他/她提供选择另一个注册用户作为朋友的选项，并预先选择两者最喜欢的位置或类似的东西......） ，您可以通过使用替代方案/扩展来捕获它。
您提到您正在开发的系统是次要角色。不要忘记，正在开发的系统是一个隐式参与者，并且没有作为单独的参与者在图表中显示。使用边界框（包含不包括参与者的用例的矩形）来描述系统的范围。
终于说到您的关心了。这些只是有关数据的详细信息，不是用例的一部分。您可以使用上面提到的数据术语表以文本形式捕获这些详细信息（通过命名所有类别等）。如果您认为数据之间的结构和关系很重要并且需要使用图表来捕获，则可以使用类图来创建数据/域模型。
关于用例关系的最后一个注意事项 - 如果不需要，请不要使用它们。它们通常难以理解且定义模糊。永远不要使用它们来分解功能，这取决于设计，而不是用例分析。
First of all you have to realize, that Use Case Diagrams aren't substitute for actual (written) Use Cases. Use Case descriptions contain many important details, which are omitted in Use Case diagrams. Use Case diagrams are good for depicting hierarchies of actors, associated use cases and relationships between use cases, but nothing more.
Another important thing is to realize what an use case actually is. Good way to think about them is to find a goal of an actor, which he/she wants to achieve with help from the system. Achieving this goal should give the actor some business value. My point is, that from what you described, registered user might want to search for a sightseeing and/or buy entry tickets. So this is his goal and this should be a an use case, don't confuse use cases with functionality/features like different ways of searching etc.
In your first suggestion you have two use cases, which differ only in data (e.g. it might be just different choice from a combo box in a form). Such differences, if they don't influence the way the system and actors interact, are described separately from the use cases in a data glossary, which you reference in your use case. This way you avoid many unnecessary details in use case descriptions. If on the other hand, the steps in the description change (e.g. when registečred user chooses location system gives him/her an option to select another registered user as a friend and pre-selects favourite locations of both or something like that...), you can capture this by using alternatives/extensions.
You mention the system you are developing as the secondary actor. Don't forget, the system under development is an implicit actor and is not shown diagrams as a separate actor. Use boundary box (rectangle encompassing use cases excluding actors) to depict scope of your system.
Finally to your concern. These are all just details about the data, which are not part of an use case. You can capture those details in text (by namicng all categories etc.) using the data glossary as mentioned above. If you think the structure and relations between data is important and needs to be captured using diagrams, you can use class diagrams to create data/domain models.
Last note about use case relationships - don't use them if you don't have to. They are often hard to understand and vaguely defined. Never ever use them to decompose the functionality, that is up to design, not analysis with use cases.
我讨厌在用例中描述搜索。变量太多了。这就像尝试编写一个使用浏览器的用例。
搜索是补充业务规则的早期原型的良好候选者。
I hate depicting Search in a use case. There are simply too many variables. It's like trying to write a use case for using a browser.
Search is a good candidate for early prototyping supplemented with business rules.