Aspect Oriented Programing in LabVIEW?

[eenauk]

I am designing a rather large LIMS (Lab info mgmt sys) for a highly regulated company. we therefor need a high level of security and logging. This would seem like an ideal opportunity to try aspect-like programing in LV.

I know that a full AOP in not reaaly possible in LV, but am wondering what suugestions y'all might have at the back of your heads. Here is mine at least (feel free to chop it to bits before i get all messed up in it):

The basic idea is to create a "run-time aspect server" that will monitor (via vi server) all GUI opens and closes.

- On opens, it would check to make sure the current logged-in user has rights to open that vi and would grey-out any features to which he or she should have no access, alternately aborting (?!) the vi (this should of course never happen).

- On Closes, it would pop-up a (FDA-required) box for the user to describe any changes made, if the vi did actually perform any data changes (ie INSERT, UPDATE or DELETE statements - all data is stored in a dB).

What i want to avoid is having to have all wireworkers on the project have to remember to include a special vi in both the init and close sequences of all their GUIs, but perhaps that is the 'best' solution after all.

michael

[jpdrolet]

I am designing a rather large LIMS (Lab info mgmt sys) for a highly regulated company. we therefor need a high level of security and logging. This would seem like an ideal opportunity to try aspect-like programing in LV.

I know that a full AOP in not reaaly possible in LV, but am wondering what suugestions y'all might have at the back of your heads. Here is mine at least (feel free to chop it to bits before i get all messed up in it):

The basic idea is to create a "run-time aspect server" that will monitor (via vi server) all GUI opens and closes.

- On opens, it would check to make sure the current logged-in user has rights to open that vi and would grey-out any features to which he or she should have no access, alternately aborting (?!) the vi (this should of course never happen).

- On Closes, it would pop-up a (FDA-required) box for the user to describe any changes made, if the vi did actually perform any data changes (ie INSERT, UPDATE or DELETE statements - all data is stored in a dB).

What i want to avoid is having to have all wireworkers on the project have to remember to include a special vi in both the init and close sequences of all their GUIs, but perhaps that is the 'best' solution after all.

michael

I'm not clear if you want to monitor programmers who edit VIs or users of the application.

[eenauk]

users of the application. sorry abt the confusion. we need to log any changes users make to the db and make sure they only have access to allowed features.

I'm not clear if you want to monitor programmers who edit VIs or users of the application.

[didierj]

users of the application. sorry abt the confusion. we need to log any changes users make to the db and make sure they only have access to allowed features.

What are the data you store?

If you can use a standard dB like mySQL or similar. They include by themself user-management, change logging and incremental save (the whole history is kept).

If you need a file-based system, check tools like subversion (SCC) They are usually used for version controlling of program development, but I'm sure you could also use it for your purposes.

Didier

[Mike Ashe]

Actually, doing a full system like this in LabVIEW is reasonable. I worked on one like this recently that did exactly what you are describing for a hospital management system. Due to patient information security concerns we had to have password protected access to both features and GUIs based on both user name and role. This was implemented in a distributed system with LabVIEW and MS SQL2000 database server. Passwords, logins, etc are all encrypted. It is not trivial to implement, but is doable.

If you want more info email me privately:

michael.ashe@imaginatics.net