管理员和项目之间的关系（类图）
之间应有什么关系：
- 管理员和员工（管理员寄存器 /编辑员工）
- 管理员和项目（admin创建 /删除 /更新项目）
- 项目和order_item（order_item使用项目中的数据）
- 任务和订单（每个订单都有最多两个任务）
What relationships should be there between:
- Admin and Employee (Admin registers / edits employee)
- Admin and Item (Admin creates / deletes / updates item)
- Item and Order_Item (Order_Item uses data from Item)
- Task and Order (Each order has at most two tasks)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，很难从您提供的信息中得知。也许您想捕获管理员创建的项目。然后，您应该将关联结束<代码>创建者命名。管理员管理所有类并不意味着管理员类必须具有关联。
订购项目引用项目，因此，应该有一个关联而不是概括。所有显示的关系都应是常规关联。您使用的白色钻石表示共享的聚合，几乎总是多余的，只会使读者感到困惑。
所有关联都应具有多重性，并且可以在其末端具有角色名称，这将使图更有意义。
Well, it is hard to tell from what info you give us. Maybe you want to capture which instance of an admin created an item. Then you should name the association end
creator. That an admin manages all classes doesn‘t mean that the admin class must have associations.An
order itemreferences anitem, so, there should be an association instead of a generalization.All the rest of the shown relationships should be regular associations. The white diamond you use denotes a shared aggregation and is almost always superfluous and only confuses the readers.
All associations should have multiplicities and could have role names at their ends, which would make the diagram much more meaningful.
这是一个有趣的开始。除< Axel's 答案，并考虑您的修订图，我想为您提供一些手段来您自己找到问题：
跨检查系统上所有多重性。您首先想象一个实例在另一侧看到一个可以与相反方向相关的实例，然后在相反的方向上进行。
。
以
item和order_item的示例：以订单项目为例，很明显，它必须参考项目，并且只能与一个项目相关联。因此，1（等效于1..1）是正确的。但是在相反的方向上：您确定item只能订购一次吗？最多可以有一个order_item？确保可选关联是可选的。因此，最小基数的交叉检查多重性大于0对应于强制性关联。
再次以
项目和order_item的示例：管理员可以创建一个新的itemx，该 x，该订单不使用任何顺序项目直到第一次订购。因此，item出现在0order_item。中似乎没有错
以另一个示例：不会“最多2个任务”均值
0..2？还是确定每个订单必须至少有一个任务？只有你可以回答; - ）与任何不是简单关联的关系都要充实。。这里的问题很简单：如果您将您的特殊关系替换为简单的调解，您是否会在图中放松一些关键信息？
以黑色钻石的例子为例：好的，如果您要删除它，您会失去这样的暗示，即如果没有它所属的顺序，并且没有理由独立存在。您可以保留它。
但是白色钻石呢。如果您愿意删除它们，您真的会失去任何相关含义，这对于设计师而言至关重要？
您已经删除了继承（带有三角形箭头），这很好。因为这意味着每当箭头头的侧面的实例时，都可以使用箭头头的实例。
子公司问题：图中的任何类都共享一组重要的属性和行为吗？如果是，您可以问自己是一个不是另一个专业（继承）。
例如，
admin也是员工吗？如果是，则可以在两者之间添加继承关系，然后删除admin员工中已经定义的内容。This is an interesting start. In addition to Axel's answer, and considering your revised diagram, I'd like to provide you some means to find issues by yourself:
Cross-check systematically all the multiplicities. You do this by first imagining an instance on one side an see with how many instances it can be associated with on the opposite side, and then do the same in the opposite direction.
Take the example of
ItemandOrder_item: take an order item, it is clear that it must refer to an item and can only be associated with one item. So1(which is equivalent to1..1) is correct. But in the opposite direction: are you sure that anItemcan be ordered only once? That there can be at most a single order_item?Make sure that optional associations are optional. So cross check multiplicities with a minimum cardinality greater than 0 correspond to mandatory associations.
Take again the example of
ItemandOrder_item: the admin can create a newItemX, that is not used in any order item until it is ordered a first time. So there seem nothing wrong for anItemto appear in 0Order_item.Take another example: Wouldn't "at most 2 tasks" mean
0..2? Or are you sure that each order must have at least one task? Only you could answer ;-)Be extra-careful with any relation that are not simple associations. The question here is simple: if you would replace your special relationship with a simple assiciation, would you loose some critical information in your diagram?
Take the example of the black diamond: ok, if you'd remove it, you would loose the hint that an order item makes no sense without the order to which it belongs and has no reason to exist on its own. You can keep it.
But what about the white diamonds. If you would remove them, would you really lose any relevant meaning that is vital for the designer to know?
You've already removed the inheritance (withe triangular arrow head) and that's fine. Because this means that an instance on the side of the arrow head could be used whenever an instance of the side of the arrow head is expected.
Subsidiary question: do any classes in the diagram share a significant set of attributes and behavior? If yes, you can ask yourself is one isn't a specialization of the other (inheritance).
For example, is an
Adminalso anEmployee? If yes, you may add an inheritance relation between the two, and remove inAdminwhat is already defined in the employee.