在UML类图上进行适当的建模
在UML类图中：
a）您是否必须说明汇总的属性？还是用指示聚集的箭头足够了？
b）我必须添加“ id”作为属性还是给定？
谢谢。
In an UML class diagram:
a) Do you have to state attributes that are aggregated? Or is it enough with the arrows indicating aggregation?
b) Do I have to add "id" as an attribute or is it a given?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您正在使用图片中的共享聚合。根据UML 2.5，没有任何定义的语义（请参阅第110页）。如果您需要复合聚合，则必须填充钻石。在这种情况下，将汇总对象与汇总的对象一起被删除（后者必须确保该约束）。在您的模型中，这是没有意义的。没有员工汇总的部门。即使反之亦然，我也会有疑问或至少讨论的理由。
ID仅在具有业务目的（例如文章号）时才需要。如果您将模型转换为数据库，则出于技术原因引入人造ID。但是在抽象的业务层面上，它们没有被建模。您的模型仅在相关类的属性使用方面有所不同。 B变体是首选。但是，您需要将属性作为角色名称将其放置在关联类中（AS
-Department和-Branch）。您放置在连接器中间的是关联名称。在前面使用+选择不良。很少需要命名协会。所以摆脱这一点。角色名称应放置在扮演角色的班级附近。同样，使用点通用表明角色代表拥有的属性是一个好主意。只需将一个小的黑点放在两者的左侧附近（角色名称应该在哪里）。至于p的点通知UML 2.5状态。 18：
也为 jiml。 评论A- Version a-versiation ussociations plus plus <<< /em>引入冗余的属性。这不是违法的，但可能并不是故意的，至少会导致混乱。
You are using a shared aggregation in the picture. That does not have any defined semantics as per UML 2.5 (see p. 110). If you need a composite aggregation the diamond must be filled. In that case the aggregated object will be deleted along with the aggregating one (the latter must assure that constraint). In your model it makes no sense. No employee aggregates a department. Even vice versa I would have doubts or at least reason for discussion.
An
idis only needed if it has a business purpose (e.g. an article number). If you transform your model to a database you introduce an artificial id for technical reasons. But on an abstract business level they are not modeled.Your models only differ in the use of attributes for associated classes. The B variant is preferred. But you need to place the attributes as role names towards the associated classes (as
-departmentand-branch). What you have placed in the middle of the connectors is rather the association name. Badly chosen with the+in front. Naming associations is rarely needed. So get rid of that. Role names shall be placed near the class that takes the role. Also it's a good idea to use the dot-notation to show that the roles represent owned properties. Just place a small black dot near the left hand side of both (near where the role names should go).As for the dot-notation UML 2.5 states on p. 18:
Also as JimL. commented the A-version uses associations plus attributes which introduces redundancy. This is not illegal but likely not intended and at least leads to confusion.