The DSM above contains the Java classes that make-up an applet for uploading a file via FTP. According to the specifications the file transfer must be resumable.
What I first did was making three layers:
- User Interface
- Logic
- Data access
After that I dragged the classes into the layer they (should) belong to, thereafter I partitioned the DSM, in such a way that the dependencies towards the providing classes appear below diagonal. Luckily this works for most dependencies. I have seen systems where this was less obvious.
The row and column indicated by the same number contain the same sub-system/class. Cells that contain a value >= 1 indicate a dependency (method call, usage of attribute, constructor, include or other). Layered systems only contain dependencies below the diagonal.
Based on the DSM a number of conclusions can be drawn:
The Upload logic is too much intertwined with the User Interface code, this can be concluded based on the dependencies between ImageCanvas and SendDialog towards Upload (indicated by 1 and 3) but also in reverse calling order were Upload calls ChooseMediaDialog and SendDialog. This makes the code hard to read and therefore less easy to maintain.
- There is a cyclic dependency between Upload and Dict. Dict is a dictionary class, so this in itself is already strange. The Upload logic should no have any output to the GUI and thus it is unclear why it should have a dependency with class Dict.
- Class ChunkedInputStream (strange name, since we would expect an output stream towards the FTP server) is however never used. The first question that arises here is: Is resumable transfer supported by this applet? This however cannot be answered via this DSM, but code inspection shows that the file transfer is (re)placed in Upload and does not support resumable streams in any sense.
The following conclusions can be drawn in this example:
- Creation of an usable DSM takes only a few minutes.
- Intended architecture can be viewed against the realised architecture. Higher level questions can be answered more easy and precise.
- Code inspection can be postponed until the big picture is created. After this is done code inspection is more focussed on the points of interest (in stead of starting with main() and read downwards from there).
- Relatively scattered DSMs tend to be representative for less clean and eroded code.
- One would, based on the name expect that Upload makes calls to the FTPClient(s), this however is not done.
Other information shown in the DSM:
- On the diagonal percentage figures are shown, these represent the relative size of the sub-system/class compared to the overall size.
- The small red triangle indicated a violation of a dependency rule. In this case FTPSecureClient uses and external third party library that was not yet allowed for usage by the architect.
