Article - Monolithic vs. Modular Software Reuse Libraries (Part I)

[Jim_Kring]

Hi All,

I've written another article, which I hope you find interesting and informative. As usual, I'm interested in your feedback

• Monolithic vs. Modular Software Reuse Libraries (Part I)

Thanks,

-Jim

[cross-post]

[MikeS81]

Hi Jim,

i can´t see your article. I get this Message: "Sorry, no posts matched your criteria."

Mike

[Jim_Kring]

---

@MikeS81 wrote:

Hi Jim,

i can´t see your article. I get this Message: "Sorry, no posts matched your criteria."

Mike

---

Thanks.  I've fixed this and you should be able to see the article, now 🙂

[Wiebe@CARYA]

Hi Jim,

Sort, but to the point!

Should I post this here?

a.. >Do you have an effective LabVIEW reuse system?
Yes. Although I have to say that most applications we make are very
different from all the previous applications. The reusable part is the
architecture and all the libraries we use for that, and all the libraries we
use to implement custom functionality like error handling and logging,
trending, front panel scaling etc.

a.. >What does your system look like?
A system we use a lot uses dynamically called VI's that interact with user
events. Each dynamically started VI can be reused, as long as each user or
the VI uses the same user events.

This only works when you also use a library of reusable sub VI's (libraries,
such as drivers, error handling, logging, picture control tools, database
tools, string manipulation tools, etc.).

a.. >Is your system monolithic or modular?
I'd say about 50/50... It is modular up to the point that we find practical.
a.. >How big is the library?
Hard to say. We don't have a formal library jet. Mostly we copy the
libraries we need from other projects (or copy the project and delete what
we don't need). It is crude, but works just fine.
a.. >How many developers contribute the library?
5, although it's an informal library...
a.. >How do you manage your installation?
Not sure what that means.

a.. >Are you feeling any pain points?
I guess a library management system would be nice, but with 5 developers,
it's just as easy to ask if any of them has a solution.

Also, I find source code control systems to rigid to work with (although I
admit I never took the time to learn to work with one). I'd like a system
where two developers can open the same project, and one gets notified if the
other is editing or finished. A simple interlocking mechanism should work
(like the "lock if read only" option: "lock when opened by someone else").
Simple idea, but probably hard to implement. Or perhaps some password scheme
where you can edit a VI if you are in the VI's edit group. So only the
programmer responsible for it can change it.*

a.. How do you plan to solve them?
I've learned to live with them. Just like the project explorer came 6 years
to late.

Regards,

Wiebe.


* For this, I'd really like a fourth security level: "Allow user to see the
diagram (but not to edit it)". Without a valid password, the user can see
the diagram (to study it), but not change it.

[Ben]

We use a modular library since that keeps the cost down for our customers. They only get charged for the components they need.

Inter-modules dependencies are documented for each component's documentation.

Ben

[Jim_Kring]

Hi Wiebe,

Thanks for the detailed feedback.  I'm curious.  Do you integrate any of your components or frameworks into the palettes?  Do you keep your compoenents in the project folder or beneath user.lib (or similar)?  That's what I meant when I asked "How do you manage your installation?" (I should have been more clear).

Thanks,

-Jim

[Jim_Kring]

Hi Ben,

What types of components are these?  Are they standard components like string or file handling tools, or are they more domain/technology specific? Also, how do you decide which components to use on a project?  Once you decide to use a component, do you store it in the project folder or beneath user.lib?

Thanks,

-Jim

[Ben]

Jim's Q are in bold.

"What types of components are these? "

They vary from simple "Get Folder Spec" to robust "Event Logging Suite" which provides trouble-shooting monitoring and functions.

"Also, how do you decide which components to use on a project? "

The developers decide what they want to use. If they think the Library component will serve their needs, they include it. The architect of the app may specify elements assumed to work in the app.

"Once you decide to use a component, do you store it in the project folder or beneath user.lib?"

They go into the project. This serves a couple of purposes.

1) Years latter when we are asked to restore an app on a machine that went bad, there is no question about what library elements were used. (I only had to be burned once before I insisted on that rule).

2) If we want to know what re-use went into a previous app, we just look in  the "re-use" folder.

3) Old apps are not put in jeopardy due to code changes.

Ben

[Jim_Kring]

Hi Ben,

Thanks for answering my follow-up questions.  Here are a couple more short ones:

How do you manage improvements to your reuse library?  If a developer is working on a project and discovers an bug or wants to add a new feature, what process (if any) must they follow?  How do you ensure that local changes to reuse components in the project (if any) make thier way into the main reuse library?

Another thing that I am curious about is how devlopers know what's available in your main reuse library.  If I am a new developer in your organization, how do I find out what reuse components are available for use in my projects?

Thanks,

-Jim

[Ben]

"How do you manage improvements to your reuse library?  If a developer is working on a project and discovers an bug or wants to add a new feature, what process (if any) must they follow?  How do you ensure that local changes to reuse components in the project (if any) make thier way into the main reuse library?"

I wrote a procedure that applies both new entries and enhancements. This procedure includes approval by one of our CLA's of both the code and the "Tester" which verifies the library entity will work correctly. To date we have not discovered any bugs in any of our library components (thank GOD!).

Once in the library each entity and it required sub-VI's are password protected so the developers are discouraged from modifying them (they know how to generate the password in the event a bug does show up). Ehnacements generally are driven by new "needs" and the developer is free to enhance as they see fit within thier project. If they think others would like their enhancements, everything has to go back through the wringer again.

" If I am a new developer in your organization, how do I find out what reuse components are available for use in my projects?"

We handle this as part of the above mentioned procedure. Any new or enhanced code must be documented in both a word and plain text document. THese are kept with the library entity. We also maintain an index that list all of the re-use entities and a short description of what they do, along with any dependencies they have of other library entities.

So Noobs are simply told to "read the book".

As new entities are added, we cc all of the techno-weenies and include the write-up so they new tools are available to them.

Ben