如何为论坛系统创建用例图
会有具有不同权限的用户，因此会有很多条件，那么我如何在用例图中对条件进行建模？例如，论坛管理员可以创建帖子或更新帖子，甚至删除帖子、创建话题或更新可用话题、删除话题等。
1- 我应该有不同的“用例”每个任务的要素？我的意思是为每个任务添加一个椭圆形/圆形元素？就像为“创建帖子”创建一个椭圆形，为“更新帖子”创建一个椭圆形，......
2- 每个特权都有一个演员是否正确？就像一个用于匿名用户，一个用于登录用户，......
谢谢。
there would be users with different privilages and as a consequence there would be a lot of conditions, so how can i model the conditions in the use case diagrams? for example, the forum manager may create a post or update a post or even delete a post, create a threads or update avialable threads, delete threads, etc.
1- should i have different "use case" elements for each task? i mean add an oval/circle element for each task?? like creating an oval for "create a post", an oval for "updating the post",.....
2- is it correct to have one actor for each privilage?? like one for anonymuse user, one for logged in user, .....
thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您不应该在用例图中涉及条件、如果和但是。一组用例旨在提供系统功能的概述，每个用例都描述系统与一个或多个参与者之间的交互。您希望描述简单明了。
每个用例都应该以某种方式对参与者有意义。对于使用论坛的人来说，创建帖子与更新帖子（或回复帖子）是一项单独的活动，这确实有意义，因此对我来说这似乎是一个明智的开始。在此阶段您不应该过度关注用例的数量。用例的数量并不会直接转化为系统的复杂性，大量明确定义的用例比少量大量、模糊的用例要好。
下一步是详细说明您的用例，这就是您可以开始讨论条件的地方。详细阐述通常使用活动图来完成，该活动图描述了参与者和系统之间的交互如何进行，例如发布者发起发布；系统检查发帖者权限；如果权限不够，系统会拒绝发帖；当然
，没有对错之分，但一般来说，使用“登录用户”等参与者是一个坏主意，事实上，您应该完全避免使用“用户”参与者。为什么？因为交互实际上是系统和人之间的交互，而用户（帐户）是人的权限在系统中的表示。
换句话说，如果你发现自己使用的参与者实际上是系统内部的概念，那么你就在某个地方走错了方向。每个用例都必须涉及系统外部参与者，否则您就无法从外部描述系统。
论坛系统的更好的参与者可能是发布者、读者和管理者（也可能是系统管理员）。
You shouldn't get into conditions and ifs and buts in use cases diagrams. A set of use cases is intended to provide an overview of the system's functionality, and each use case describes an interaction between the system and one or more actors. You want to keep that description simple and succinct.
Each use case should in some way make sense to the actor. To a person using a forum, it does make sense that creating a post is a separate activity from updating one (or responding to one), so that seems like a sensible start to me. You should not be overly concerned with the number of use cases at this stage. The number of use cases does not translate directly into system complexity, and a large number of clearly defined use cases is better than a small number of large, ambiguous ones.
The next step is to elaborate your use cases, and that's where you can start talking about conditions. Elaboration is typically done using an activity diagram which describes how the interaction between the actor and the system proceeds, eg Poster initiates post; System checks poster's privileges; System rejects post if privileges are insufficient; etc.
There is of course no right or wrong, but generally speaking it's a bad idea to use actors such as "logged in user" etc, and in fact you should avoid employing a "user" actor at all. Why? Because the interaction is actually between the system and a person, whereas a user (account) is an in-system representation of a person's privileges.
In other words, if you find yourself using actors which are in fact concepts from within the system, you've taken a wrong turn somewhere. Every use case must involve a system-external actor, otherwise you're not describing the system from the outside.
A better set of actors for a forum system would probably be Poster, Reader and Manager (and possibly a System Administrator as well).