Monolithic vs. Modular Software Reuse Libraries (Part II)

I hope it was worth the wait.

Yes, this article may have oversimplified things. The terms “library” and “monolithic” can certainly signify different things to different people and there are some gray areas. By reuse library, I meant the whole body of an individual or organization’s reusable software assets. And, when I said monolithic, I meant something that is a single unit, somewhat inseparable from it’s parts, tending to be large, and having few (if any external dependencies).

The thing that defines (to me) whether a reuse library is modular or monolithic has more to do with the release/deployment to the users. If a user of the reuse library must (or typically does out of convenience) obtain it as a single unit, then it is being treated as monolithic reuse system (all or nothing).

Michael Ashe also brings up a good point, that there are temporal as well as spatial dimensions to the reuse model. A modular library brings with it a slew of management issues as we move towards a system of interdependent modules of varying versions. Of course, as Michael hints, a package management system can provide a great solution to these problems. And, it’s probably no mystery that’s where I’m headed with the discussion

There are two aspects or “domains” here, a spatial one (how the library fits together) and a temporal one (how versioning and compatibility is handled over time. In the monolithic library the spatial and temporal aspects are linked, one to one. As soon you start breaking the monolith up into modules you enable the separation of the two domains, and what was once representable with a linear model becomes more of a sparse tree hierarchy in 2D. (or even 3D+, more on that later after your next article)

I’m assuming your second article will get into this a lot more, as you alluded. I don’t view the two patterns, mono vs module, as mutually exclusive, rather as a base root (vi.lib, etc) with branches. I have several layers to my reuse library, vi.lib, OpenG, other OpenSource and finally my own VIs from over the years. I’ve been fortunate to get the OpenG libraries and BSD open source code in general to be included in my latest customers project (by the way, thanks for the latest version of VIPM 1.1 !!). We are soon to be in the process of comverting some of the code we have developed for this customer’s project into internal OpenG style packages.

Looking forward to your part 2!

The biggest problem rises when I upgrading LabVIEW. Since my VIs depends on vi.lib and properties of front panel objects, upgrading can often cause the broken arrow. Currently I find and fix broken VIs manually. I am interested in how other people handle the situation.

You can have a library which is monolithic. You can have a library made up of lots of (individually seen) monolithic parts with clearly defined interfaces. Is that modular? There’s a whole universe in between. The definition of the interfaces is probable the most important aspect. Anything which may change an interface MUST be hidden from the user, otherwise compatibility problems occur.

I think it depends on what scale we look at the code. If we zoom in close enough, everything becomes monolithic at one stage or another. The question is how finely grained should the monolithic components be?

Shane.

Dave G.

And the same with Instrument drivers. They are inherently self contained in that they do not need other LabVIEW libraries other than vi.lib to work and could be considered monolithic but they of course depend on a lot of things such as VISA, NI-DAQ and friends, and built in LabVIEW functions such as TCP/IP etc.

The problem is not so much about monolithic versus modular but about clearly defined and very stable interfaces. VISA is such an interface and that makes the Instrument Drivers sort of monolithic in their own since they can simply assume that VISA will work the way it does if it is there at all.

Once you start to change interfaces you always end up in big troubles unless you use a fully monolithic approach. And that approach does not scale at all nor is it manageable in the long run. So the problem is not so much about not using modular libraries but about making interfaces that are stable and can be used in a backwards compatible way and that is one of the real challenges to software design, since monolithic code only works well for a small and limited scope.

Greetings from Germany!
– Uwe

I don’t consider monolithic library to be a bad thing per se. Monolithic library can be built-up from modules. However the modularity is simply hidden from the user. This causes no limitations to the upgrade process of the monolithic library. However the monolithicy gives the user a guarantee that the modules of which the library is built will always work together and that the library is tested as entity prior to releasing a patch.

I think the difference is a little bit same as with OS X and Linux. Linux is a modular architecture. Everyone can choose which packages they prefer and built a suitable Linux system of their own. With OS X everything comes in a monolithic package and it simply works. The maintenance of OS X is therefore much simpler from the user point of view, still not functionality or modularity needs to be sacrified. The problem only arises if very esoteric configurations is needed such that an old version of one module needs to be mixed with a new version of another module. Then monolithic library cannot cope with the situation.