.NET naked - More pictures, some clarifications

I seem to have stumble upon something here with my look under the hood of the .NET Framework an other tools. Many readers where surprised and fascinated by what you can actually do with quality assessment tools like Lattix LDM or a simple concept like DSM (Dependency Structure Matrix) with its easy to understand and scalable depiction of the dependencies within a software.

However, my posting also raised inevitable and justified concerns which I quickly want to address:

-Did I set out to do Microsoft bashing? Definitely no. I like the .NET Framework and many things Microsoft does quite a lot. But that does not hinder me to try to look behind their marketing veil or utter concern or even criticizm. It´s just that I use the .NET Framework a lot, so I wanted to take a peek inside. Whoever is proficient in Java should do the same for that platform. Also, since I advocate the publication of software quality measurements and will try to follow my own advice, I think it´s fair to help bring more clarity about for tools in wide use like the .NET Framework. I´m very open for any explanation Microsoft might give as to why mscorlib.dll seems to have so many cyclic dependencies and why this might be inevitable or even a good thing. If such an explanation exists, let me hear it. Otherwise I have to assume my questioning was very relevant.

-Why did I choose VistaDB as a second example? Because it happened to be on my laptop. And because it seems to be a fairly complicated piece of software being a full blown database server engine. That´s the only reason. I don´t own any shares of Vista Software :-) Please note, I also showed a DSM of Spring.Net - which also happens to be on my laptop. And to round of my little gallery here´s another tool that I happen to use: Vanatec´s O/R Mapper Open Access. What do you think of it´s architectural clarity?


Fig. 1: DSM of O/R Mapper Vanatec Open Access. (Click on picture to see a larger version.)

-Some reader´s assumed, the high coupling of mscorlib.dll was a general feature of the .NET Framework. But as I already tried to say in my original posting, that´s not really the case. Some parts of the .NET Framework seem to be much better structured. Here´s the WinForms subsystem:


Fig. 2: The WinForms subsystem is an example of a pretty well structured part of the .NET Framework

It looks quite neat and the main culprit for cyclic dependencies - again - is the "general bucket" root namespace Windows.Forms.

-Some readers also speculated if a general purpose library/framework like the .NET Framework somewhat necessarily has to be structured as it is. Well, there sure is some truth to this thought. A broad and basic framework like the BCL inevitably has a different structure than the next CRM system. But then... If cyclic dependencies are as fundamentally bad as software architecture has it, why should we exculpate Microsoft from them? Given they cannot be avoided completely in such a complicated piece of software like the .NET Framework, why are so many of them necessary? I´m concerned about the number of cycles, not the mere existence of any. And the more fundamental a piece of software is, the longer it needs to live, there more worried I´m about such signs of bad architecture.

Anyway, I´m happy about each and every comment. And I´m looking forward to seeing more and more public quality reports on software of all sorts coming online. Maybe I should set up a dedicated site...?

2 Comments

  • The use of DSMs to look at the architecture of software is fairly new. I have looked at many large applications and frameworks and a surprising number of them show undesirable couplings. However, there is good reason to believe (IMHO) that once developers begin to explicity monitor inter-module dependencies, the architecture can actually be prevented from eroding.

    This can already be seen when development teams use the build order to enforce dependencies between assemblies. Of course, this approach doesn't help to keep the assembies themselves clean internally. When examining the architecture of the Eclipse platform this phenomenon became readily apparent. It is easy to see that the top level architecture is reasonably clean, though not perfect. However, when one looks inside the jar files (java equivalent of dll's) then one sees a lot of scope for improvement. Hence, my belief that once developers begin to monitor dependencies we will see the emergence of software with architecture that is manifestly modular.

  • Hallo Ralf,

    ich las nur irgendetwas mit intuitive Bedienung etc. und fast im gleichen Moment war auch schon das Lattix Download fertig ;-). Aber gut, ich vertehe zwar auf Anhieb was ich sehe, vor allem wenn's die eigenen Projekte sind, aber dies dann wiederum effektiv zu nutzen - dazu fehlt noch der ein oder andere Aha Effekt.
    Ich hoffe im Anschluss an dnp Melodie wird das Projekt mit Lattix oder einem ähnlichen Tool nochmal unter die Lupe genommen (in Form eines dnp Artikel), wobei ich zum "ähnlichen Tool" tendiere. Auch wenn die Ausgabe von NDepend schwer zu lesen ist, der Preis für die Lattix Vollversion dürfte so manchen Freelancer umhauen / vom Kauf abhalten (ich meine zumindest, dass man es nicht so oft einsetzen würde, dass der Preis gerechtfertigt wäre).

Comments have been disabled for this content.