Search code examples
javaumlclass-diagramsequence-diagram

How to correctly create a sequence diagram?

I have some doubts about this Sequence Diagram, I haven't found similar examples on the web so I can't compare my solution.

The exercise requires modeling the invocation of the listAllFiles method of the Directory class with a sequence diagram.

This is the Java code:

public class Directory { 
         public List<File> listAllFiles(String path) { 
                List<File> all = newArrayList<File>(); 
                File[] list = new File(path).listFiles(); 
                if(list != null) { 
                   for (File f:list) { 
                       if(f.isDirectory()) { 
                       
                           all.addAll(listAllFiles(f.getAbsolutePath())); 
                           
                       } else { 
                       
                            all.add(f.getAbsoluteFile()); 
                       }
                   } 
                } 
                  return all; 
           } 
}

This is my sequence diagram:

enter image description here

I modified my solution following the advice in the replies:

enter image description here

Solution

  • Recommendation

    The first recommendation for making a useful sequence diagram, is to chose the right level of abstraction. Indeed, the diagram's value is to show in a simple way some complex interactions that are difficult to grasp when just reading the code.

    Unfortunately, here it is just the contrary: we instantly understand the code when reading it. All this is mainly about one classe's method, using standard library elements such as File or List. But showing it as a sequence diagram makes it look really complicated. Moreover, imagine the challenge when maintaining the code: your diagram will very quickly be out of sync, becoming useless.

    In short: don't use UML for graphic programming. It's not forbidden by the UML specs, but it's really not worth the effort.

    For the sake of the exercise, despite the recommendation above

    Fundamental improvements

    The lifelines shall correspond to objects and not to classes. Keeping it at class level, makes it difficult to distinguish the array of File and the individual Files you're looping on. Try with the following lifelines: :Directory (i.e. anonymous object of class Directory), all:List<File>, list:File[], f:File.

    You could also use File and ArrayList<File> if you want to show the use of static operations that are object independent, but it would make the diagram more complex than needed for the creation of the objects. Instead, I'd advise to show graphically the create message for each local object, directly from the creator to the head of the lifeline, allocating the object visually to the right scope. To avoid ambiguity, you should also show the delete message (or at least the X), especially for objects that have a limited scope, like f.

    The create message with a lifeline head that starts from the message, you'll make in particular clear that some objects only exist for the time of an iteration. This will dramatically improve the understanding of your intent. As it is, we just don't get it, if we wouldn't see the code.

    Minor improvements

    In the alt guard, put just the condition or else, but never the if.

    You may well show the parameters of the message, and the name of the returned result, but it's not mandatory, and would not significantly improve understandability here.