我有一个用例图,它有三个Actors:User,Librarian和Staff。
Staff和Librarian actor是User actor的特化,在Use Case图中,它们每个都有一些仅与它们相关的扩展用例。
在序列图中,如何显示图书馆员演员是用户演员的专业化?
专业演员(图书馆员和员工)能否在序列图中有自己的时间表?
我有来显示广义actor的时间表,即使它没有针对其专业化的额外用例或操作吗?
使用主序列图中的“交互使用”框,将序列图的时间轴重新排列到自己的图表后,是否可以重新排列?
答案 0 :(得分:1)
- 在序列图中,如何显示Librarian actor是User actor的特化?
醇>
没有办法(据我所知)。您可以在UML Use Case Diagram中显示此关系,在UML Class Diagram
中更好
- 专业演员(图书管理员和工作人员)能否在序列图中有自己的时间表?
醇>
是的,假设他们在序列图捕获的场景中发挥作用并进行交互
- 我是否显示广义actor的时间轴,即使它没有针对其专业化的额外用例或操作?
醇>
不,您不必在图表中显示正式但无用的工件,除非后续代码生成(或MDA)工具强制您这样做
- 使用主序列图中的“交互使用”框,将序列图的时间轴重新排列到自己的图表后,是否可以重新排列?
醇>
我不确定,但可能是的,如果你保持输入和输出的绑定以及识别生命线清晰有效的信息。一些可能隐藏正确答案的文章:
来源:uml-diagrams.org: UML Sequence Diagrams → Interaction Use
...有时难以遵循的UML规范强加的一个约束是交互使用必须涵盖封闭交互中表示的所有相关生命线。这意味着所有这些生命线应该以某种方式彼此靠近。如果我们在同一个图表上使用另一个交互,那么按照UML的要求重新排列所有相关的生命线可能会非常棘手
来源:www.omg.org/spec/UML/2.5/Beta2
17.7交互使用→语义→部分分解
通过交互在一个交互中分解生命线(由生命线的相关ConnectableElement类型拥有),被完全解释为InteractionUse。进入(或离开)分解的生命线的信息被解释为在分解时由相应的正式门匹配的实际门。
由于分解的生命线被解释为InteractionUse,PartDecomposition的语义是分解引用的交互的语义,其中门和参数已被匹配...
17.7交互使用→符号→PartDecomposition
PartDecomposition由生命线头部的引用子句指定,可以在符号子句17.3.4(生命线)中看到(参见图17.21)。
如果在分解的生命线下内联表示部分分解且分解子句为“strict”,则表示内联分解中所有子生命线上的构造按严格顺序排序(参见17.6.4(严格的interactionOperator)) ...
图17.21 PartDecomposition - 分解的部分
...