Contact us Heritage collections Image license terms
HOME ACL ACD ICF SUS DCS G&A STARLINK Literature
Further reading □ OverviewEngineering Board VisitCentral SystemFORTRAN AssessmentMuxworthy August 1976User InterfaceUtilitiesOps SysRoberts March 1979Tree-Meta on the ICL 1900Trip June 1976Trip October 1976Trip August 1977Trip August 1978Trip August 1979Trip August 1981Trip August 1981GKS January 1982Trip March 1982Trip March 1983Trip July 1983NATO Dec 1983CSP/Recursion 1984
C&A INF CCD CISD Archives Contact us Heritage archives Image license terms

Search

   
ACDLiteratureReports
ACDLiteratureReports
ACL ACD C&A INF CCD CISD Archives
Further reading

OverviewEngineering Board VisitCentral SystemFORTRAN AssessmentMuxworthy August 1976User InterfaceUtilitiesOps SysRoberts March 1979Tree-Meta on the ICL 1900Trip June 1976Trip October 1976Trip August 1977Trip August 1978Trip August 1979Trip August 1981Trip August 1981GKS January 1982Trip March 1982Trip March 1983Trip July 1983NATO Dec 1983CSP/Recursion 1984

Trip to USA 11-26 October 1976

Rob Witty

October 1976

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.

Zahn

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

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.

III

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

  1. A patch is being sent to us to cure the advance fiche bug (overwriting 1st frame onto title area)
  2. The listing of the Displayer which we bought should be 'assembleable'. If not we were cheated.
  3. In future we should always buy the Fiche version of any III program as this will contain the most code.
  4. John Whitney has an office in the factory and is making more sequences for films like Future World and Logos for ABC TV.
  5. III will shortly be offering to customers short courses on specific pieces of III software, going into the details of the program much more deeply than did Peter Christianson
  6. The ICL print program does not use the High Speed Char Gen. III are still very much embarrassed by the HSCG problem. III would not even tell me the difference between the high speed CG and the Slow Speed CG ie what it was we bought. I therefore requested that they write to us explaining the difference. It is even clearer after talking to III that they have made a major mistake in their use or non-use of the HSCG and C&A must not be white- washed into thinking that the HSCG problem is just another software bug. It is a major mistake in that the software was never designed to use the HSCG,
  7. Gash fiche in ICL print prog due to subfiles. III would say nothing other than if we formally request a change to the program then they will consider whether or not they want to do it and if they do then how much it will cost us.
  8. Gaps in fiche titles when char sizes reduced. Gregg thought this could be cured by adjusting our titling parameters. Perhaps we could check this.
  9. III were amazed at our tail of the Hardcopy camera pulldown reversal due to software asynchrony. Their software people do not seem very good at all. Their Field engineering will probably adopt D Green's mod for the other FR80s.
  10. No further FR80/COMP80 software development is planned. Mods requested by customers must be paid for by customers if III condescend to do the work.
  11. Gregg confirmed that fiche title characters breaking up was caused by wraparound ie software error.
  12. Structural analysis of a tube is not done by III. If a customer requests such an analysis he must pay for it, and it would be contracted out by III.
  13. DISKS. III are now fitting PERTEC moving head disks to all new machines. FR80s have one fixed disk. Our FR80 is field upgradeable and III might recommend this in the future. COMP80s have the same disk but with an additional exchangeable platter as well. FR80s cannot be fitted with this. The PERTEC disk has the same rotational speed as our disk but 3 times the capacity with increased access times.
  14. III estimates that 10-15 man-years of effort has gone into the Displayer programs.
  15. III are not likely to offer 6250dpi tape decks in the forseeable future.
  16. I complained about the PLS situation and made our displeasure known, although one must sympathise with III over their supply problem.
  17. I mentioned the hardcopy drive belts problem to Wolfie

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.

⇑ Top of page
© Chilton Computing and UKRI Science and Technology Facilities Council webmaster@chilton-computing.org.uk
Our thanks to UKRI Science and Technology Facilities Council for hosting this site