I attended the 2nd International Conference on Software Engineering in San Francisco from 13-15 October, along with some 1200 other delegates.
Each day of the conference had a central theme. The theme for the first day was Requirements and Specifications. For many large projects, such as USA military software, a major problem is the Specification. The large software houses in the USA are now trying to produce formal languages and graphical notations allied to project data bases to aid the systems analysis define the specifications of projects and cope with changes to the specifications. Softech and TRW gave several papers describing their systems. This rediscovery of systems analysis seems to have come about because of American management's desire to 'see' progress. Up till now this has led to a code being produced very early in projects to show management that progress is indeed being made. This shortsighted policy has of course led to many failures and the development of formal definitions of Requirements and Specifications has resulted so that at least the right problem is being tackled. The involvement of the 'customer' during this phase of a project was stressed so that the 'customer' was sure he would be getting what he wanted. To this end, Softech particularly emphasised the need for formal specifications to be intelligible to the customer.
Day two focused on the next stage of any project - the design and building of programs. It seems that most of the conference was convinced that structured programming was the way to handle control when building a program, so there were no 'structured programming' papers. The emphasis on day two was on abstract data types as a method of ensuring a) protection and b) reduction in complexity. Examples of this technique are the papers by Liskov and Wulf. Briefly the technique is to define an abstract data type eg stack and to include in this definition the operations that may be performed on the abstract data type eg pop, push. the data types may be then used as building blocks in programs. The advantages over extensible languages was in the fact that the compiler ensures that the data structure is only accessed via the proper functions. This reduces the dreaded side-effects type of error and enables the implementation of a data structure to be verified and independently of its use. I think this data protection mechanism will be a standard feature of any good language in a few years time. Brinch Hansen and Hoare's monitors are a specific instance of a protected abstract data type mechanism and the success of the monitor is an indication of the way language development is proceeding.
Day three of the conference centred on verification. Proof of a program is still too long, tedious and error prone for the method to be used by the average programmer. Harlan Mills' paper is well worth reading. He made the point that a proof is an attempt to convince someone that a program will work. Today a programmer tries to convince himself that his program will work. He does this informally. Walkthroughs try to convince a third party, still informally, that a program will work. Verification is the formalisation of these existing informal current practices. Two relevant points - 1) structured control flow and abstract data types are methods which reduce the complexity of proofs and are thus 'good things', 2) Dijkstra's theory of deriving the program from the proof will probably catch on in the same way as structured programming. People at the conference felt it would probably take another 10-20 years before programs were formally proved before going into production generally.
Throughout the conference there was much discussion about the Software Life Cycle. This is
Spec -> Design -> Code -> Maintain
It was pointed out by Mills that maintenance is the restoration of something to its original condition, so that if we maintain programs we would be restoring them to their original erroneous condition. Want maintenance really means is the continuation of the design and development phase of a project. Maintenance is a word which should be purged from the software engineer's vocabulary.
To summarise the conference nothing startling was announced, just an incremental consolidation of the feeling that software engineering is a growing infant and that there is a long hard road ahead before software systems can be said to be engineered rather than thrown together. Proof methods are the key to software engineering. Perhaps structured programming and formal abstract data types will provide the basis for an improvement in proof techniques, whilst formal specifications may ensure that the customer gets what he wants as well as what he ordered.
The conference proceedings will soon be in the library, but the best papers will be published in the next IEEE Transactions on SE.
On Monday 18th Oct I visited Zahn at the Stanford Linear Accelerator Centre. We spent the day discussing Atlas's use of his construct on FR80 SYSLOG and DRIVER together with Tom Anderson's reliability techniques for termination, Dimensional flowcharting and the various topics in programming language design raised at the conference (Zahn also attended the conference).
Meissner works in the Comp Sci Dept of the Lawrence Berkely Lab. He has arrived at his own version of reliable loop construction in FORTRAN which I recommend. It is
DO 99 J=1, MAXTIMES ... IF(exitconditiontrue) GO TO 77 ... 99 CONTINUE error if reach this point STOP 77 CONTINUE continue as this is good exit point
I also spoke to Harold Holmes who has developed an interactive circuit design package and have brought back some documentation on his system.
I spent two days at the factory. The first day I spent with marketing men Gregg White and Larry Schieber. Having convinced them that their answers were inadequate, I spent the second day with Wolfgang Schlaak, the Field Service Engineering whiz-kid who was able to answer most of my questions. as most of my questions were at the clock pulse level 1 will omit the details of them here. The more general points to emerge were
The detailed questions will be written up and put in the III file when the formal answers from III are received which should be within two weeks.