不确定我的 UML 用例图是否正确
我已经开始学习 UML，但有时它让我感到困惑（例如，我允许或不允许在用例图中放入什么，上次我想知道登录是否可以在用例图中使用）。无论如何，我已经制作了电子学习平台的简单用例图，例如 lynda，但您必须为您想参加的个人课程付费。对我的图表有什么建议/更正吗？ （我想引入更多用例）
I've started learning UML but it confuses me sometimes (for example what i'm allowed or not to put in my USECASE diagram, last time i was wondering if logging in can be used in usecase diagram). Anyways i've made simple usecase diagram of e-learning platform, like lynda but you have to pay for individual course you'd like to take. Any suggestions/corrections about my diagram? (i'd like to bring more usecases into it)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如您所知，用例是用户和系统之间流程的文本表示。用例应该有一个反映该流程的名称。当我查看您的用例名称时，我可以看到您已经理解了这一点。这些名称都是描述性的并且经过深思熟虑。干得好！
那么，关于用例图：用例图的目的是让人们更容易理解有哪些用例，以及用例的目标用户类型。因此，箭头总是从参与者到用例。
有时，一个参与者可以是一个单独的系统，然后它应该作为参与者包含在用例图中，其名称暗示参与者是一个系统。如果一群人由于某种原因可以有一个包含“系统”一词的名字，我认为应该澄清的是，描绘这群人的演员不是一个实际的系统，尽管演员的名字暗示它是一个单独的系统。
as you know, a use case is a textual representation of a flow between a user and the system. the use case should have a name that reflects that flow. when i look at your use case names i can see that you have understood this. the names are all descriptive and well thought through. well done!
so, about use case diagrams: the purpose of a use case diagram is to make it easier to understand what use cases there are, and what type of users the use cases are intended for. because of this, the arrows always go from an actor to a use case.
sometimes an actor can be a separate system, and then it should be included in the use case diagram as an actor, with a name that hints to the actor being a system. if a group of persons for some reason could have a name that include the word 'system', i think it should be clarified that the actor portraying that group of persons is not an actual system, although the name of the actor hints to it being a separate system.
我会将名为
Register/Login的用例拆分为两个单独的用例。我认为这些步骤是两个单独的操作，需要不同的步骤来执行。通过这种方式，您还可以将用例转换为组合。我们经常这样做：
然后您可以添加有关如何在活动图中实现/执行特定用例的更详细的步骤。
这个答案当然是针对 Enterprise Architect 的。
I would split that Usecase called
Register/Logininto two separate Usecases. I think these steps are two separate actions and need different steps to execute. This way you are also able to transform the Usecases to Composites.We often do it this way:
Then you could add more detailed steps on how to implement/execute the certain Usecase in the Activity Diagram.
This answer is specific to Enterprise Architect of course.
登录不是用户目标。必须登录才能满足用户注册的目的。如果用户登录后没有执行任何其他操作，然后注销，这会提供什么价值？没有任何。
Login is not a user goal. Login is necessary to be able to satify the user goal of register. If a user logged in, did nothing else, and logged out, what value does that provide? None.
一段时间以来，我一直在培训软件工程领域的基本技能，并创建一些简单的小项目，用户可以在其中免费交换报价。除了金融体系之外。所以我刚刚创建了一些关于基本系统场景的带有图表的用例，我想请您帮忙检查。我创造的东西是否很好，或者我有很多特别的错误。在过去的几个月里，我读了一本有关软件工程的书，这是我尝试创建实用内容的一部分。
UC 3. 添加服务报价
UC 4. 报价引入服务的修改
如果有必要，我可以添加功能需求以更好地理解项目的想法。
From a while I'm training basic skills in Software Engneering area and create small simple project where users will exchange offers without money. Apart of financial system. So I've just created some Use Cases with Diagrams on basic system scenarios and I want to ask You for a help to check. Is it quite good what I've created or I've here a lot of of particular mistakes. From the last couple months I read a book about Software Engeneering and this is a part where I try to create something practical.
UC 3. Adding offer of service
UC 4. Modification of offer introduced service
If it's necesserly I can add functional lrequirements to better understand the idea of project.