UML和分析
我理解 UML，但似乎在进行一些基本分析时遇到困难。这是一个项目的示例：
目的是设计一个注册的页面或 Facebook 应用程序 用户可以购买另一个用户来拥有他们并修改他们的状态 消息。
每个用户一开始有 1000 点积分，可以购买另一个用户 500分。这可以防止其他用户在半小时内购买该用户。 交易完成后，买家获得200积分 购买用户获得200积分。每消费100积分 20 赚取积分。每次购买用户时，他们的价值都会增加 200，每天赠送300积分。
会员可以通过搜索功能或列表找到其他会员。
管理员可以查看用户信息，获取游戏信息 并给予奖励积分。
我可以发现用例参与者 User 和 Administrator。用例将是搜索、购买、修改（对于用户）和查看用户信息、查看游戏信息，给予奖励积分（针对管理员）。当涉及到序列图时，我陷入了困境，无法确定需要哪些类和操作。
您可以提供什么建议或什么方法来开始这个示例？我尝试阅读一些有关该主题的书籍，但我很困惑。
I understand UML but it seems I have trouble doing some basic analysis. Here is an example of a project:
The aim is to design a page or facebook application where registered
users can buy another user to own them and modify their status
message.Each user starts off with a 1000 points and can buy another user for
500 points. This prevents other users buying a user for a half hour.
After the transaction is complete, the buyer gets 200 points and the
bought user gets 200 points. Each time a 100 points are spent 20
points are earned. Each time a user is bought their value increases by
200. 300 points are given each day.A member can find other members through a search function or list.
An administrator can see user information, get information about the game
and give bonus points.
I can spot the Use Case Actors User and Administrator. The Use Cases would be Search, Buy, Modify (for a User) and View user information, View game information, Give bonus points (for an Administrator). I'm stuck when it comes to sequence diagrams, determining what classes are needed and operations though.
What advice or what approach can you give to get started with this example? I've tried reading a few books on the subject but I'm confused.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在你有一些课程之前，做序列图是没有意义的。
听起来你太沉迷于符号了。更担心你的问题。 UML 只不过是一种标准符号，用于捕获有关如何描述面向对象软件系统的想法。重要的是想法，而不是符号。
更关心如何获得您要解决的问题的良好对象表示。问题必须首先解决。如果您得到“我的系统需要做什么？”是的，没有人会问你用例图中的参与者是谁。
是的，看起来您有用户和管理员作为两个参与者。我看到诸如“搜索用户”和“添加游戏点”之类的操作。 （是不是有什么“玩游戏”藏在某处？）
No sense doing a sequence diagram until you have some classes.
You sound like you're too hung up on the notation. Worry more about your problem. UML is nothing more than a standard notation for capturing your ideas about how to describe an object-oriented software system. It's the ideas that matter, not the notation.
Worry more about getting a good object representation of the problem you're trying to solve. The problem needs to be first and foremost. If you get "what does my system need to do?" right, no one will ask you who the actors were in your use case diagrams.
Yes, it looks like you have User and Admin as two actors. I see operations like "search for users" and "add game points". (Is there a "play game" hiding in there somewhere?)
如果可以的话，您可能会考虑使用 SysML 而不是 UML。 SysML 是为系统分析/设计而设计的，因此不具有表示 UML 所具有的精细细节的所有建模元素。但它确实有需求（UML 没有），当然还有用例、活动等。
然而，更重要的是，我认为您无法从一组用例得出类设计。或者你可以，但它很可能会很糟糕。
这是因为设计不是分析的细化，它是本质上不同的事情：分析被输入到设计中（即系统应该做什么？），但是没有用例模型会告诉您什么错误报告策略你的代码应该使用。或者在您的情况下，排名第一的设计驱动程序实际上根本不是用例，而是您将在 Facebook API 上实现这一点的事实。
所以我能给出的最好建议是在进行分析时不要担心设计。忘记类并决定系统应该做什么，而不是应该如何实现。
If it's an option, you might look into using SysML instead of UML. SysML was designed for systems analysis / design and as a consequence does not have all the modelling elements to represent fine detail that UML has. But it does have Requirements (which UML does not), and of course Use Cases, Activities, etc.
More importantly, however, I don't think you can arrive at a class design from a set of use cases. Or you can, but it will most likely be bad.
This is because a design is not a refinement of an analysis, it is a qualitatively different thing: the analysis is input into the design (ie, what should the system do?), but no use case model will tell you what error reporting strategy your code should employ. Or in your case, the number one design driver isn't actually a use case at all, but the fact that you will be implementing this on the Facebook API.
So the best advice I can give is not to worry about the design when you are doing the analysis. Forget about the classes and decide what the system should do, not how it should be implemented.