If all the parts of the whole program are Zero Coupled AF and therefore know nothing about each other, then the documentation is the only glue that makes it whole: True / False? |
Neither--the question is flawed. There are lots of different kinds of coupling: static, interface, behavioral, etc. There *must* be some kind of coupling between any two components that interact. IIRC zero coupling in the context of the document AQ wrote is referring to an actor callee that is not statically coupled to the actor caller. The caller may still be statically coupled to the callee. There are many ways to create two interacting actors that are not statically dependent on each other; however, there has to be some code somewhere that sets up the relationship between them. It's not practical to write an application where all parts of the program have no static dependencies on each other.
To look at it another way, if the documentation was the only glue that made it whole (wrt static coupling,) you would have to write your app so that it reads the documentation and uses it to set up the relationships between the components. At that point it's probably no longer fair to categorize it simply as "documentation."
It seems to me that as coupling goes down documentation must go up. |
Not necessarily. Documentation is useful for information that cannot be easily determined by looking at the code--complex relationship trees, message chains, etc. If I have to open vis from several different parts of the application to understand some aspect of the application I'm interested in, then that is a good candidate for documentation. Any reduced coupling solution has a section of code that sets up the initial relationships that must be established for the application to work. Having all the setup code in one place can reduce the need for documentation.
| As a potential customer for LabVIEW developers who might use AF, how much documentation should I require for acceptance of the finished project, and how would I specify that? |
As a potential customer, you should specify the amount of documentation that you require to meet your needs. If you allow your application to be developed using the AF, then you are implicitly agreeing to reducing the size of the developer pool you can draw on to work on the code. IMO, it's unreasonable to expect an average (as of July 2012) LV developer to be able to look at AF code and understand the big picture. They may be able to make small changes successfully, but they would have difficulty maintaining the architecture and over time it would degrade into a big ball of mud. It's equally unreasonable, imo, to expect a developer to provide enough documentation to explain the AF (and OOP) to developers who aren't familiar with it.
A few comments on various block diagrams, and sometimes a README.txt for the project, are good enough implementation notes to myself and other developers.
