I have recently been learning VB v5 and I am still at the early stages so forgive me if I am asking a stupid question. " How can you ensure the reliability of a VB program"

I was astonished to discover that you really have to know these VB objects and their limitations very well. These limitations are often far from obvious or intuitive and will cause the system to hang under adverse conditions ( a bit like a basic prog that calls for division by zero only far more obtuse). Of course you can run and debug the procedure but how can you be sure that you have covered all the conditions? The more complex the procedure, the more obscure the likely faults.

As we know only too well, programmers hate writing up their work in a way that someone else can follow easily (one hour of code takes 5 hours to writeup and validate). Have you ever seen a system where blocks of code are written up, checked and approved (just like a design drawing). I know there is a Quality Assurance standard for software but Ive never seen a program with a QA approved stamp on it??

I ramble on about this because of the push to you PC in the automation business and all the emphasis seems to be at the juicy end - programming and problem solving. Nothing comes from the systems end where I am sitting

 

You bring up an interesting point. I have been a field service engineer for about seven years, working on automated systems. About a year ago I became interested in the use of VB6 as an HMI interface. The company that I work for had always used products such as Wonderware, and Factorylink, which to me seemed over kill for some of the projects I was working on. I tried to learn VB, from reading, and hands on, and I was able to create some pretty stable interfaces. This past spring I came to a turning point, when I took a VB6 class at a local community college. The instructor really made the difference. It turns out he was employed full time as a programmer, and throughout the class, he stressed the importance of diciplined programming, and error checking. Now the applications that I write are bullet proof.
To me it makes little difference what type of software you are using, it comes down to the individuals knowledge, and attention to detail. Believe me, I have had to fly half way around the world, because someone couldn't be bothered to fully investigate a customers needs, or go back and double check their work.

 

You can't. You don't have access to all of the code that your program runs, since some of it is locked away inside of microsoft DLL's and third party OCX files, which you have no right to debug and fix.

The best design would be modular, where most of a system can be written using code that has already been tested many times, and has a higher level of confidence. Ideally, you could get this code without having to pay an obscene amount of cash. And if you could get the source code, instead of just a DLL or OCX file, you could make adjustments to it that would make it fit your project, rather than kludging your project together to fit within the constraints of VB. If only someone were working on something like that.........

Hmmmmmm.......

Oh, wait! How about http://mat.sf.net

--Joe Jansen

 

I understand NASA has procedures like that in place, but I don't have any personal knowledge there.

It certainly doesn't seem to be common in the programming world, anyway, leading to the joke with architects and a woodpecker.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

On June 20, 2002 11:56 am, brian slater wrote:
> I have recently been learning VB v5 and I am still at the early stages so forgive me if I am asking a stupid question. " How can you ensure the
reliability of a VB program" I was astonished to discover that you really have to know these VB objects and their limitations very well. These limitations are often far from obvious or intuitive <

I don't think that is a stupid question at all. Indeed it is a much more intelligent question than would occur to most people. The ability to ask questions like that is what distinguishes a real programmer from a code
twiddler.

I have been helping a colleague reverse engineer a custom VB program controlling a test system. The entire system including the program was created by a company which specialises in building custom test systems.
The objective of the project is to get to the root of a number of problems and reduce them to a tolerable level (we have given up on any idea of eliminating all of them). This project has brought to my attention quite forcefully a great number of the weaknesses in the VB language design, and also the obscure side effects of the language itself and the window management system. Observing someone else's code shows you many things that you would not have noticed about your own.
My opinion of VB (based on this and other experiences) is that creating a *reliable* non-trivial program in VB takes considerably more effort, knowlege and experience than it would to accomplish the same task with virtually any other modern computer language I am familiar with. In making this statement I am distinguishing between merely getting a program to compile and run, and
creating a *reliable* program (however you want to define this). I don't believe the deficiencies in VB can be corrected, because the necessary
changes would "break" too many existing programs.

> and will cause the system to hang under adverse conditions ( a bit like a basic prog that calls for division by zero only far more obtuse). Of course you can run and debug the procedure but how can you be sure that you have covered all the conditions? The more complex the procedure, the more obscure the likely faults. <

You cannot debug reliability into a program any more than you can inspect quality into the parts on your production line. In both cases quality must be designed into the product and the process for creating it from the beginning.


> As we know only too well, programmers hate writing up their work in a way that someone else can follow easily (one hour of code takes 5 hours to writeup and validate). Have you ever seen a system where blocks of code are written up, checked and approved (just like a design drawing).I know there is a Quality Assurance standard for software but Ive never seen a program with a QA approved stamp on it??<

This is doing things backwards if you want a reliable program. The design documentation should be created first (just like a drawing is), and then the program written from it. The code should then be examined to see if it conforms with the program design. The design tools can include such methods as flow charts, grafcet (SFC), and state diagrams. Different methods may be appropriate for different parts of the same project.

> I ramble on about this because of the push to you PC in the automation business and all the emphasis seems to be at the juicy end - programming and problem solving. Nothing comes from the systems end where I am sitting.<

Having gone through the above mentioned experience with reverse engineering an existing system, I believe that if we were to purchase an equivalent custom system today, we would grant a purchase order only on the condition that proper software engineering practices were being followed, and on reviewing the software design before the actual programming was started.
The original programmer from this project could bang out code remarkably quickly. However, what he was banging out was object oriented spagetti code. In the end, any time he may have saved by operating by the seat of his pants was consumed ten times over in debugging and re-writing.

The old fashioned flow charts we created were remarkably useful in discovering bad algorithms and incorrect fundamental assumptions. We are making new flow charts to design the corrections to the most serious problems.
A grafect chart was very good in providing a general overview of the test sequence. A state diagram clarified one particularly tricky bit.
When you simply read the program you cannot see the forest for the trees. Adding comments to the code doesn't solve this because it doesn't change the fact that you are operating at too low a level to see the fundamental design
problems.

************************
Michael Griffin
London, Ont. Canada
************************

 

Hi Brian.

There is no way that you can ever know all the side effects and interactions with closed source code. That's why even with closed source products, companies with a lot at stake pay for a source license. This, by the way is one of the reasons OSS can be more reliable. If you want to, you _can_ know exactly how everything works. If you look at your license, they don't guarantee anything not even basic function. About all you can do is test and pray. That seems to be good enough for a lot of folks. And you can do what other Windows users do. Just blame it on the hardware.

Regards

cww