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

[Jim_Kring]

Ben,

Thanks for expanding on your process.  This info will be helpful to me as I work on my follow-up articles.

Thanks,

-Jim

[Wiebe@CARYA]

We are not 100% converted to all the project explorer features. So we either
add the library folder into the project, or add it as a library (no need to
mention:.lvlib, not llb). Sometimes I simply use VI's that aren't in the
project at all! To me it seems useless to add a library in the project when
I use it only once or twice (I don't use code distribution features).

In both cases we copy the library to the project folder. This is easy, and
there is no concern about code changes...

I never used vi.lib or user.lib directories. Don't know exactly why, just
never liked to use them.

Regards,

Wiebe.

[Wiebe@CARYA]

Ben,

Sounds like you've got it all together!

We've thought about charging for library usage, but our applications are too
much appart (HPLC software has not much in common with a train sound
measurement system).

Good to hear the password idea is working. I might try it. My idea was to
take it a step further. Make the passwords so long, no one can remember
them. Then, make an application that uses a network file to register usage.
If you need to edit a VI, use the app. to get access to it. No one else can
get access, since the register on the network knows it is already being
edited. This way, the system doesn't rely on teh disipline of the users.
Something that is required for most scc systems.

I guess your story is an example for Jim's point: it does take a lot of work
to program modulairy. Procedures, manuals, etc. is a lot to set up if you
are making an application.

Regards,

Wiebe.

[Ben]

Weibe wrote

"

Ben,

Sounds like you've got it all together!

We've thought about charging for library usage, but our applications are too
much appart (HPLC software has not much in common with a train sound
measurement system).

"

We have the same challenge since it is rare two of our projects are the same.

We have found most of our re-use code at the "edges" of the application (GUI, generic utilities). More often that not it is the performance req's that prevent us from re-using geneirc solutions and force us to optimize the "data paths".

Ben