在 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!