i have to draw some sequence diagrams for a software i wrote. In my Software i have some Objects that dispatch custom Events and other Objects that listens for these events.
When it comes to illustrate Eventlisteners und dispatchEvent-function i'm a little bit confused how to do that. I googled a lot, but couldn't find the right hint :(
Or is a sequence diagram not a good choice for explaining event handling?
Thanks for your help!
On
There is no definitive answer to your question, because creating useful diagrams largely depends on what kind of information you want to convey to the reader. My advice is: You will never be able to show all your program's functionality in just one diagram; event handling is often too complex and ugly - try to split it up into smaller parts and decide individually, which kind of diagram is useful for which aspects you want to show.
For each one, your focus should always be on the reader: What do you want him or her to understand?
To start with, it's usually best to write user stories and show use cases, if you don't have those already. They convey the functionality your program was made for, and help you to identify processes and organize the way in which you think about your program. For each of those processes, a sequence diagram is probably most useful to show how things work. For example, if one of your program features is uploading an image, you should draw a sequence diagram showing the main components, objects and sequences of events involved only in the upload procedure.
The next step is to categorize the remaining events and objects, which are more fine-grained or do not interact directly with the user: Which events are internal (i.e. dispatched and handled within the same object), which are external (between some objects), or even global (affecting the entire application). This will help you to identify groups of objects interacting with one another.
Depending on how complex an object is, I often display internal event sequences within a state diagram or flow chart.
If you have some smaller object groups where the interactions are not too complex and more interesting in terms of who does what why instead of when, you can possibly use slightly altered class diagrams - these might not be very formal, but for some concepts, they are often more useful than flow charts, state or sequence diagrams.
It should also be mentioned, that in some cases, a diagram doesn't really help at all. Sometimes it is far more useful to write a short text providing an example, or collect information in tables. Documentation is complete, when a reader understands the concepts of what your program does and how it does so. For everything else, there is always the source code.
I don't know exactly what you are trying to do here but sequence diagrams are perfectly capable of representing the sort of system you have described. Here is an article on sequence diagrams. Look at the section on asynchronous messages and concurrency. Another article actually has an example of an event listener. It talks about both sequence and class diagrams. I guess the example of sequence diagrams will be of interest to you.