在 UML 类图中何时使用 memberEnd 以及 navigableOwnedEnd？
我已经下载了 Altova UModel 的试用版并开始使用 UML。作为一个实际的开始，我正在建模一个个人信息管理器应用程序，其中包括一个网络书签管理。
一个书签可以同时属于许多（或不属于）标签，并且一个标签可以包含许多（如果它包含的所有书签都被删除，则不包含）书签。该关系必须是双向可导航的 - 用户必须能够查看具有特定标签的所有书签以及书签的所有标签。
Bookmark 和 Tag 类之间正确的 UML 关系是什么？
据我现在理解的UML，它是一个关联（而不是聚合）。但是对于双向可导航的多对多关系，我可以将结束角色指定为“memberEnd”或“when navigableOwnedEnd”，从图形上看，连接在两种情况下看起来相同（箭头）（据我所知意味着可导航性）但是仅当使用“memberEnd”时，类框中才会出现属性。
如果我的意思是双向可导航的多对多关系，我应该如何在模型中指定它？
I've download a trial of Altova UModel and am starting using UML. As a practical beginning I am modelling a personal information manager application, which includes a web bookmark managing.
A Bookmark can belong to many (or no) Tags at once and a Tag can contain many (or no if all the bookmarks it contained were deleted) bookmarks. The relation has to be both-way navigable - a user has to be able to see all Bookmarks with a particular Tags ans all Tags of a Bookmark.
What is the correct UML relation between Bookmark and Tag classes?
As far as I understand UML now, it is an Association (not an Aggregation). But for a 2-way navigable many-to-many relation I can specify ends roles as "memberEnd" or "when navigableOwnedEnd", graphically the connection looks the same in both cases (an arrow) (which as I understand means navigability) but a property appears in the class box in case only when "memberEnd" is used.
How should I specif it in the model If I mean both-way navigable many-to-many relation there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
来自 UML 上部结构规范 v2.1.2 第 7.3.3 节：
因此，如果该端由关联“拥有”，则使用ownedEnd/navigableOwnedEnd类型，否则使用memberEnd类型。
两者均可用于“双向可导航的多对多关系”；如果每个关系链接是设计中的一个单独实例，则它可以拥有端点（例如，类 A 和类 B 具有对相关 As 和 B 的引用对列表的引用），但如果关系链接是隐式的，则它不拥有任何东西（例如，类 A 有一个对相关 B 的引用列表，类 B 有一个对相关 As 的引用列表）。
从 90 年代末开始就使用 UML，您是我遇到的第一个关心其中差异的人！
From UML Superstructure Specification, v2.1.2 section 7.3.3:
So if the end is 'owned' by the association, use the ownedEnd/navigableOwnedEnd type, otherwise use the memberEnd type.
Either can be used for a 'both-way navigable many-to-many relation'; if each relation link is a separate instance in your design, it can own the ends (e.g. class A and class B has a reference to a list of pairs of references to related As and Bs), but if the relation link is implicit then it does not own anything (e.g. class A has a list of references to related Bs, class B has a list of references to related As).
Having used UML since the late `90s, you're the first person I've met who cared about the difference!