我了解UML，但似乎我有困难做一些基本的分析。下面是一个项目的例子:
目的是设计一个页面或facebook应用程序注册用户可以购买另一个用户来拥有自己并修改自己的状态消息。
每个用户开始时都有1000点，可以用1000点购买另一个用户500点。这可以防止其他用户购买一个用户半小时。交易完成后，买家将获得200分购买的用户获得200分。每100点就花20点积分是挣来的。每购买一次用户，他们的价值就会增加200. 每天300分。
成员可以通过搜索函数或列表找到其他成员。
管理员可以查看用户信息，获取游戏信息并给予奖励积分。
我可以发现用例参与者User和Administrator。用例是Search、Buy、Modify(用于用户)和View user information、View game information、Give bonus points(用于管理员)。当涉及到序列图时，我被卡住了，决定需要哪些类和操作。
你能给出什么建议或方法来开始这个例子?我试着读了几本关于这个主题的书，但我还是很困惑。
没有意义做一个序列图，直到你有一些类。
听起来你太在意符号了。多担心自己的问题。UML只不过是一种标准符号，用于捕获关于如何描述面向对象的软件系统的想法。重要的是思想，而不是符号。
更关心如何获得你想要解决的问题的良好对象表示。问题必须摆在首位。如果你正确地得到了"我的系统需要做什么?"，没有人会问你用例图中的参与者是谁。
是的，看起来你有User和Admin作为两个角色。我看到了"搜索用户"one_answers"添加游戏积分"等操作。(是否有"play game"隐藏在某处?)
如果它是一个选项，您可能会考虑使用SysML而不是UML。SysML是为系统分析/设计而设计的，因此它没有UML所具有的所有建模元素来表示精细的细节。但是它确实有需求(UML没有)，当然还有用例，活动，等等。
更重要的是，我不认为你可以从一组用例中得到一个类的设计。或者你可以，但它很可能是坏的。
这是因为设计不是分析的精化，它是一种性质不同的东西:分析被输入到设计中(例如，系统应该做什么?)，但是没有用例模型会告诉你代码应该采用什么错误报告策略。或者在你的情况下，头号设计驱动实际上根本不是用例，而是你将在Facebook API上实现它的事实。
所以我能给的最好的建议是，当你做分析时，不要担心设计。忘记类，决定系统应该做什么，而不是如何实现。