Lets you define a comma delimited list of types that should not appear in the sequence diagram when it is generated. For example, if method1() calls method2() which calls method3(), and the invocation depth is set to 2, then only method2 is shown, and method3 is no longer shown. Split into smaller diagrams where appropriateĪutomatically splits sequence diagrams into smaller sub-diagrams, and automatically generates hyperlinks between them for easy navigation.ĭefines the call depth to be used in the diagram. When selected, this option also displays messages for operations or constructors which could not be resolved (that is, not found in the model). Keeps the Combined Fragment blocks on the diagram, even if they don't contain anything. Use special color for non-displayable invocationsĪssigns a color of your choice to non-displayable invocations.
Select this check box to generate the diagram with notes (callouts) that contain program code.Īlso show code of messages displayed directly belowĮven when it is possible to show a piece of code as UML Message on the diagram, this option still displays the code of that message as a note. If the two "engineering" check boxes are missing, it is likely that this diagram is just a fragment of a bigger diagram, or perhaps you have created the diagram from a non reverse-engineered operation. This will also work in production an will probably scale much better than the direct approach, but if scaling isn't your thing, then the direct approach may be what you want to do.If you select the use for forward engineering check box, the synchronization from model to code will generate code based on the sequence diagram, when you perform forward engineering (from model to code), see also Generate Code from Sequence Diagram. Use some standard tooling for tracing like " ", instrument your application using this tooling, and extract your diagrams using that standard tooling. Process the plant UML files to get sequence diagrams. Process the filtered output to generate "plant uml" input files ( ) for sequence diagrams. Using the "jq" utility is a decent choice. There are many ways this can be done, use one :-)įilter the log entries so you get only the ones you are interested in. You need to be able to retrieve that log. In the methods you want to trace, write a log entry that contains that tracing information (name of usecase, trace ID, or any combination thereof), the location where the log entry was written, and any other information you want to add to your sequence diagram. Both of these will work, and which one is the simplest in practice depends on the architecture of your application. Another would be to generate some tracing ID (or get one from an external interaction), and send that as a parameter to all involved methods.
There are many ways of doing this, but a simple one is to a thread local variable: Set the variable to contain the name of the thing you are tracing ("usecase foobar"), and some unique ID (UUIDs are a decent choice).
Make a library where you log the name of the component/method you are in, and the session you are processing. Set up your logging to log using json, it makes the rest much simpler: Kotlin or Java) so the suggestions I will make are biased by that. I will make the assumption that you are working in a jvm language (e.g. First: This is a very good idea, and there are several ways to go about it.