Monolithic vs. Modular Reuse LibrariesA monolithic reuse library is one where all components of the library are released at the same time as a single unit. A modular reuse library is one where several individual libraries are released at different times, independently as separate and distinct units. For example, LabVIEW ships with a monolithic reuse library called vi.lib , the built-in library of VIs found beneath the <LabVIEW>\vi.lib folder. These VIs are all kept under the same revision and release cycle as LabVIEW, itself. You'll only get new versions of these w:st="on"> VIs when LabVIEW itself is released -- it's monolithic, all or nothing. National Instruments (the makers of LabVIEW) also sells modular libraries, such as the LabVIEW add-on toolkits. These libraries each have their own version, different from LabVIEW’s, and are installed separately. These add-on libraries have dependencies on vi.lib VIs , but rarely have dependencies on other add-ons. zid="101">
src="http://thinkinging.com/wp-content/uploads/2008/02/el_cap.png" style="padding-top: 10px;" align="right" border="0" hspace="4" vspace="0"> zid="34"> Monolithic wins the short racezid="84"> Most LabVIEW developers and teams find that the overhead of the modular reuse library is a show-stopper , right out of the gate. It’s too much work compared to the much-simpler monolithic reuse library, which can be developed and deployed as a single unit. zid="43"> zid="105"> The monolithic reuse library is alluring, because it’s: zid="48">
- easy to distribute – it might be delivered as a single ZIP file, or a checkout from source code control.
- easy to keep track of which version you have – there is a single version number for the entire reuse library (perhaps a date stamp)
- easy to manage, since there are no external dependencies – every VI that you need is kept within the reuse library, so users will never have missing VIs. zid="55">
But, there are scalability concernsAfter the monolithic reuse system is up and running, several problems loom on the horizon that will slow down progress. Soon, the reuse system might become a victim of its own success and get harder and harder to maintain as the code-base grows.
The solution is a modular systemThe solution to the scalability issues (number of developers, number of project, number of reuse w:st="on"> VIs ) is to make the reuse library modular. The only other option is to stop improving the reuse library – but, we can’t do that, of course. In href="http://thinkinging.com/2008/06/09/monolithic-vs-modular-software-reuse-libraries-part-ii/">part II of this series, I talk about the specific href="http://thinkinging.com/2008/06/09/monolithic-vs-modular-software-reuse-libraries-part-ii/">shortcomings of the monolithic reuse library and how the modular approach can solve them. Of course, this introduces some new problems that will have to be addressed.
What is your experience?Please share your experience with LabVIEW software reuse. I'm curious to know the following:
- Do you have an effective LabVIEW reuse system?
- What does your system look like?
- Is your system monolithic or modular?
- How big is the library?
- How many developers contribute the the library?
- How do you manage your installation?
- Are you feeling any pain points?
- How do you plan to solve them?
style="font-style: italic;">El Capitan style="font-style: italic;" href="http://en.wikipedia.org/wiki/Image:Yosemite_El_Capitan.jpg">photo style="font-style: italic;"> courtesy of Mike Murphy.