用例图网站 (UML)
Use Case Diagram Website (UML)
关于以下过程是否可以被视为用例，我有几个问题。
可以举办 post 活动的网站。
用户可以"follow"建立，"attend"事件。
等...
- 在我的索引页上，我有以下部分：
推荐事件、最近创建的事件、来自用户 "follows" 的机构的事件、排名前 10 位的机构、最近的评论、热门事件等等……（所有这些都是我从数据库中提取的）
索引页会被视为用例吗？我命名的所有部分都是单独的用例吗？考虑到我已经有一个咨询机构，并且咨询事件用例，是否所有部分都属于此类？
- 我在机构页面上有一个按钮，用户可以单击该按钮，用户将关注该机构并接收通知。单击按钮后，所有按钮都会将用户添加到 table (User_Preferences)，非常类似于 "like" 按钮或关注按钮。
这会被视为一个用例（添加到首选项用例）吗？
- 当我访问一个机构页面时，我从许多 table 中提取数据，例如：饮料、音乐、artists_attended、食品等。
在用例咨询机构中，我是否需要包含所有个人信息？ consult_beverage，consults_music，consult_artist，咨询食品都包括咨询机构？或者他们是否被认为已经在咨询机构中？
- 最后，我创建的每个页面，Index、Establishment、Events、UserProfile 等等……它们都会被视为一个用例吗？咨询机构、咨询活动、管理个人资料
谢谢，任何提示或帮助将不胜感激，我理解用例的概念，但有时我倾向于过度思考某些用例。感谢您的帮助。
页面永远不是任何用例。用例是为参与者带来价值的东西。就那么简单。如果您可以命名该值，那么您将获得用例的名称。如果您无法命名该值，那么您就没有用例。
例如您的第一个活动页面：我假设它背后的用例是 Find Event。同样，您必须考虑其他情况。相反 Login to Site 不是用例，因为它不会给参与者带来任何价值。
索引页本身不是用例。用例表示参与者与系统之间的某种交互，但页面及其部分是系统设计的一部分。如果您要用自定义编写的 GUI 应用程序替换 Web 浏览器，则用例应该基本相同。
在这种情况下，您似乎是在设计系统之后创建用例，这可能是让您感到困惑的原因——用例通常在系统设计之前就已确定。
"Add to Preferences" 似乎是一个很好的用例。实现用例的工作量通常并不重要；重要的是交互是否为参与者提供了一些价值。完整的用例集描述了用户可以使用系统做什么，而不是花费了多少工程时间来构建它。
您不应在用例中包含有关存储数据的详细信息。如果你发现自己在这样做，你需要退后一步，尝试更抽象一点地思考。用例为演员做了什么，演员想要什么？获取有关机构的信息？那么这就足够了，您不需要指定系统中存储的确切信息。重要的是演员想要信息并且系统提供了它。
用例是系统分析的一部分，而不是系统设计的一部分。因此，让相同的设计组件（页面）实现多个用例是没有问题的。因此，例如，您可以有 "see recommended events"、"see coming events for 'followed' establishments"、"see coming 'attended' events" 的用例，所有这些都在同一页面的不同部分中实现。
关于以下过程是否可以被视为用例，我有几个问题。
可以举办 post 活动的网站。 用户可以"follow"建立，"attend"事件。 等...
- 在我的索引页上，我有以下部分： 推荐事件、最近创建的事件、来自用户 "follows" 的机构的事件、排名前 10 位的机构、最近的评论、热门事件等等……（所有这些都是我从数据库中提取的）
索引页会被视为用例吗？我命名的所有部分都是单独的用例吗？考虑到我已经有一个咨询机构，并且咨询事件用例，是否所有部分都属于此类？
- 我在机构页面上有一个按钮，用户可以单击该按钮，用户将关注该机构并接收通知。单击按钮后，所有按钮都会将用户添加到 table (User_Preferences)，非常类似于 "like" 按钮或关注按钮。
这会被视为一个用例（添加到首选项用例）吗？
- 当我访问一个机构页面时，我从许多 table 中提取数据，例如：饮料、音乐、artists_attended、食品等。
在用例咨询机构中，我是否需要包含所有个人信息？ consult_beverage，consults_music，consult_artist，咨询食品都包括咨询机构？或者他们是否被认为已经在咨询机构中？
- 最后，我创建的每个页面，Index、Establishment、Events、UserProfile 等等……它们都会被视为一个用例吗？咨询机构、咨询活动、管理个人资料
谢谢，任何提示或帮助将不胜感激，我理解用例的概念，但有时我倾向于过度思考某些用例。感谢您的帮助。
页面永远不是任何用例。用例是为参与者带来价值的东西。就那么简单。如果您可以命名该值，那么您将获得用例的名称。如果您无法命名该值，那么您就没有用例。
例如您的第一个活动页面：我假设它背后的用例是 Find Event。同样，您必须考虑其他情况。相反 Login to Site 不是用例，因为它不会给参与者带来任何价值。
索引页本身不是用例。用例表示参与者与系统之间的某种交互，但页面及其部分是系统设计的一部分。如果您要用自定义编写的 GUI 应用程序替换 Web 浏览器，则用例应该基本相同。
在这种情况下，您似乎是在设计系统之后创建用例，这可能是让您感到困惑的原因——用例通常在系统设计之前就已确定。
"Add to Preferences" 似乎是一个很好的用例。实现用例的工作量通常并不重要；重要的是交互是否为参与者提供了一些价值。完整的用例集描述了用户可以使用系统做什么，而不是花费了多少工程时间来构建它。
您不应在用例中包含有关存储数据的详细信息。如果你发现自己在这样做，你需要退后一步，尝试更抽象一点地思考。用例为演员做了什么，演员想要什么？获取有关机构的信息？那么这就足够了，您不需要指定系统中存储的确切信息。重要的是演员想要信息并且系统提供了它。
用例是系统分析的一部分，而不是系统设计的一部分。因此，让相同的设计组件（页面）实现多个用例是没有问题的。因此，例如，您可以有 "see recommended events"、"see coming events for 'followed' establishments"、"see coming 'attended' events" 的用例，所有这些都在同一页面的不同部分中实现。