Can I use bidirectional arrows in Process/Activity UML diagram? Any example? I am preparing a process diagram with swimlanes. what I encountered that many processes are cross referencing across the swim lanes. Not a good as-is design. Just want to know is it ok to use bidirectional arrows to represent such process diagram? What are the disadvantages?
相关问题
- System sequence diagram - Can system request input
- Does Visual Studio 2010 Professional support UML m
- Can a [GoF]-ConcreteSubject override the notify me
- How to represent enumeration classes with methods
- How to specify “one at a time” in UML?
相关文章
- Code Iris plugin on Android Studio
- Designing a sequence diagram for an auction system
- Game engine design choice [closed]
- state transition with different guard condition
- Resources for learning how to better read code
- Relationships in a UML class diagram
- How do you convert a document in UML 1.3 - XMI 1.1
- UML help C# Design Principles
The UML specs is hard to digest here. Activities/actions are connected with
ControlFlow
s (see p. 418 of the specs). AControlFlow
itself is anActivityEdge
(see p. 411):There is no constraint (I could find) that forbids bi-directional use. All examples of
ControlFlow
s are just directed with single arrow, though.Using bi-directional flows will not let you specify guards/behavior easily as you can not detect which is for which direction. But if you have unconditional flow it should just be fine.
Edit On p. 22 it is stated
DirectedRelationship
inherits fromRelationship
which inherits fromElement
.ActivityEdge
in contrast inherits fromRedefinableElement
<-NamedElement
<-Element
. Likely they "mean" thatControlFlow
has to be directed from source to target. But in fact it's not defined.tl;dr It's up to you if you use only uni-directional connectors as shown in examples in the spec. But per definition it's not defined (sic!) and bi-directional connectors do not violate the specs.