Use of Yourdon methodology.

[DNicholls]

Does anyone use the Yourdon methodology or similar to analsye and design their software before writing the LabView code.

I'd be interested to know this as someone in an earlier question suggested that LabView is 'self documenting'. I don't believe any language can be self documenting no matter how well you comment it.

Any thoughts?

[Enrique]

Greetings;

I am not familiar with the "Yourdon methodology". I will appreciate if you can provide further information, preferibly a website link if possible.

I think it is necessary to define the meaning of "self-documenting". "Documentation" can be tricky word. The type and structure of the documentation depends on the intended audience and sometimes that can be problematic even for a specified audience.

As I see it, one of the best characteristics of LabVIEW is that it offer several methods for documentation: from adding text boxes in the diagram or front panel, to adding the documentation to the vi itself and its components. That, along with the interactivity of its help utility, makes LabVIEW one of the most programmers-friendly environments ever.


That been said, it is interesting to note that some of these attributes made LabVIEW a semi self-documenting programming language. For example, let say you add a function as a subvi in your diagram. If that subvi is well documented and you create controls or indicators for your main vi from that subvi (right-click a connector in the subvi and select "Create Control" or "Create Indicator"), the new elements not only have the right attributes for the subvi, but their documentation is also included for the main vi. You can check that by opening the help window (Ctrl-E) and placing the mouse over the control or the indicator.

This is just one aspect. As you said, maybe it is not possible that a language program is self-documenting, but certainly LabVIEW is closer to that ideal than many other programming languages.

[DNicholls]

Hi Enrique

I agree entirely with your comments on documentaion.

The Yourdon method is really a way of designing a system before you start to actually write the code. It can be quite conceptual if thats what you want or it can go down deeper into the way the code is written.

It provides a way in which you can present the solution to a problem in an initially platform independant manner, and then go on to define the way the code is written on a specific platform whether its embedded or something like LabView.

This means you can present to your customer at an early stage your solution in a way that they hopefully can understand without having to go through pages of code (or vi's!) Also they can suggest changes or improvements more easily.

I cou
ld go on for ages about this as I find it quite interesting and I've only been looking at the method for about a year.

I don't know any web pages that cover it very well but a good book is 'Real-Time Systems Development' by Sylvia Goldsmith, ISBN 0-13-718503-0. You can try Ed Yourdon's homepage www.yourdon.com which is quite an interesting read even though it doesn't seem to mention his own methodology very much!

[Labviewguru]

D,

I think I may be the mystery person you are referring to, as I use a set of programming guidelines that I claim is self-documenting.

Perhaps it would help if I elaborated on documentation:

I am not a C++ programmer, but I am VERY familiar with the language, and have had to call on those skills to figure out the functioning of some C and C++ Programs recently. I am also familiar, of course, with LabVIEW, as well as Pascal, Basic, Cobol, and a few other text languages, including HTML. I believe HTML to be the closest thing to a self documenting language as there will ever be.

When I state that the programming I do is self documenting, what I mean is that a person who has any level of knowledge of LabVIEW, enough to know what subVIs are, and what wires are, can look at most of my programs (except algorithms) and know EXACTLY what the program does. This, to me, is the most important level of documentation. Giving your customer (client, internal customer, etc) a program which has a means of that customer very easily understanding how it works is the best practice. Also, giving other programmers knowledge of what is going on is a bonus, and just plain respectable.

The way it works is I use function or component based programming. A program, such as a test, is made up of a series of linked and parallel functions. These functions are clearly identified as to what they do. For example, a program may be a test, which consists of the following functions: Initialize Instrument, Init UUT, Start Measurment, Stimulate UUT, Retrieve Measurement, DeInit UUT, Close Instrument. My program would give the viewer of the diagram the sense that that is EXACTLY what happens as the functions named above would be linked by the error handler, and any inputs/outputs would be so wired. The inputs would be on the far left of the diagram, and the outputs on the far left. The viewer would clearly see the inputs to the function, the functions themselves, in the order performed, and the results of the function.

To me, this is self documenting. I don't need to write notes on the diagram explaining what is going on. It is quite clear. I can, however, enter a description of the functions in the VI Description. If a user wants more detail, they can either view the description of the function, or even open the function to get more information. I know for a fact that you can't get that in C++. This is the biggest stumbling block for me in learning and using C++, the notion that functions are defined in other files, and not easily accessible from the main().

I hope this helps.

I am doing a search of the Yourdon Methodology to figure out what you are discussing, but I did want to clarify the statement in question.

For further information, please check out the Programming Guidelines topic in LabVIEW General.

[DNicholls]

Guru

I agree with what you are saying. As I said to another reply to my post, Yourdon is a methodology used for designing the software before you write it rather than being specifically the documentation for the software.

It is intended to be quite conceptual so that you don't get hung up with the details of actually making the software work. It allows you to define exactly what you want the application to do without restricting you to a particaular programming language or platform.

This means you can get the design agreed with the customer right at the beginning before you start to write any code. It also make changes to software at a later stage more easily implemented as you can fairly quickly see the effect it will have on your system without having to delve into the code.

Typically I write my LabView code in a similar way to how you described, essentially you build up more and more complex functions from simpler lower level building blocks. These lower level blocks are also reusable in other parts of the code. I think this is a sensible method for programming in any language.

The problem with this from a system design point of view is that if you want to make a change at the top level this can quite often mean the change has to start at a much lower level so you have to move down through the vi's until you find the lowest level at which you have to implement the change. This change will then filter up through the levels to the point you needed the change. However as you are reusing code this change may have unpredictable effects in other parts of the system. This isn't necessarily a bad thing its just the way things are. Yourdon should allow you to identify all effects a change can have in the system and then determine whether they are desirable or not.

Basically I'm saying you are correct in the way you define documentation of the code and I do the pretty much the same in my code. Yourdon is a design tool that can be used before going to code.

[swatts]

I've tried using the Select Yourdon Case tool for the predesign work on a
project and it is reasonably consistant with LabVIEW. There are benefits
when defining interfaces in a multideveloper environment where you can
publish Interface connection diagrams and details of functionality. The Data
Dictionary is also useful for defining and recording data throughout the
system. My overall impression is that initial modelling and prototyping in
LabVIEW is so strong and rapid that there is little payback for smaller
projects. (we usually define a top-level DFD and leave it at that).
There are also management issues (no excuse) with defining and structuring a
program in Yourdon and then doing a similar thing in LabVIEW (they are too
similar)
We now see the future in pre-defin
ed patterns and components.

In summary I'd still use it as a communication tool for V.Large
multideveloper projects.