Async describes an event (message or otherwise) that happens independent of the main flow of the program (here, A or B). The term async doesn't really apply at this level. That means you have a book to hand new employees. If that standard comes out of some version of a UML book so much the better. The most important thing is that your shop have a standard way to do it so you can understand each other. When async is involved predicting object life time this way becomes very complicated. To depict flow of control and to predict object life time so you know when it's safe to delete them.
Traditionally sequence diagrams have had two jobs. Really you have two different flows of control marching through A at that point. If you have a call back to A it makes more sense to have a 'return' arrow. In those cases the safest depiction is no return arrow at all. Most likely you don't even know which will happen. Your "or here" line tells me that when B terminates you expect A to have already terminated. Your "response here" line tells me that when B terminates you expect A to still be processing and, because you put it right at the end, to terminate when it see's B respond. Async doesn't really fit in this diagram because being async means you have your own damn y axis. In this metaphor a slant would be lag not asynchronicity. One thing you'll notice is that almost no one puts a slant on the arrows. I can prove this with a google image search. I'm not going to tell you how because every dang shop has their own way of doing them.
0 kommentar(er)
