1. Professorial and Jubilee Lecture 8 October 2003 Meir (Manny) Lehman School of Computing Middlesex University mml@mdx.ac.uk http://www.cs.mdx.ac.uk/staffpages/mml Software Evolution Threat and Challenge

2. 8 October 2003 - 2 - © 712c[charts-mml] Focus this evening on software evolution but after 50 years in computing field, in academia and industry, some highlights of the earlier period deserve mention -1953/6Imperial College - PhD - ICCE 2 Arithmetic Unit -1956/7Ferranti - industry - feasibility study for missile computer command and control system -1957/64Scientific Dept. Israeli MoD - digital computer development and service -1964/72IBM Research - IMP parallel processing system, programming process study -1972/2002Imperial College - teaching, research, management (HoD - DoC), IST Ltd. -2002 …Middlesex - research A Lifetime in Computing Glimpses Computing activities constituted inside-out progress through the field, starting with AU (ICCE 2) design, via computer (Sabrac) and system (IMP) design to process methodology, software process improvement and software evolution

3. 8 October 2003 - 3 - © 712c[charts-mml] Terminated in 1956 by HoD who believed that mathematicians "should not get their hands dirty" Thermionic successor to ICCE 1 relay machine (1947 - 1953) ICCE 2 - 1953/1956 ICCE 2 project initiated 1953 in the IC Dept. of Mathematics by Dr Keith Tocher and Sid (latter Professor) Michaelson with my PhD topic design of the arithmetic unit The AU employed, inter alia, a new multiplication algorithm, subsequently proved by Tocher to be the fastest possible cyclic multiplication algorithm

4. 8 October 2003 - 4 - © 712c[charts-mml] SABRAC - 1957/61 First home grown Israeli computer, first use of transistors and printed circuits Two electronic engineers, one programmer, myself as architect, logic designer For technical details see: Lehman MM, Design Specification of a Cost Limited Digital Computer, Proc. Int. Conf. on Info. Proc., Paris, June 1959, UNESCO, Oldenbourg, Butterworth, Paris, 1960, pp. 365 - 374 Lehman MM, Eshed R, and Netter Z, SABRAC, A Time Sharing, Low-Cost Computer, Comm. ACM, vol. 6, no. 8, Aug 1963, pp. 427 - 429 id. SABRAC, A New Generation Serial Computer, Comp. Syst. Iss., IEEE Trans. Electr. Comp., vol. 12, no. 5, Dec. 1963, pp. 618 - 628 Apart from original features it also included some from Ferranti Pegasus, ICCE1/2

5. 8 October 2003 - 5 - © 712c[charts-mml] IBM IMP and the Programming Process - 1965/68 Directed a 10 - 15 person team architecting a 16 processor parallel processing and executive system at IBM Research Project terminated by new director whose interest was in pipeline processors Technical details in:- Lehman MM, A Survey of Problems and Preliminary Results Concerning Parallel Processing and Parallel Processors, Proc. IEEE, Sp. Iss. on Dig. Comp., vol. 54, no. 12, Dec. 1966, pp. 1889 - 1901 reprinted in Computer Structures, Bell and Newell, McGraw Hill, 1971, pp. 456 - 469 Experience aroused interest in design process

6. 8 October 2003 - 6 - © 712c[charts-mml] Programming Process - 1968/9 Project IMP led into nine month study of the IBM programming process, identified the presence of a dynamics of software growth and eventually to the concepts of software evolution driven and controlled by feedback system dynamics see The Programming Process, IBM Rees. Rep. RC 2722, Dec. 1969, 47p, republished in Program Evolution - Processes of Software Change, (eds. Lehman and Belady), Academic Press, London, 1985, 538 p The software evolution phenomenon

7. 8 October 2003 - 7 - © 712c[charts-mml] Demonstrates that software evolution is a disciplined phenomenon with important practical significance and worthy of systematic study Current understanding reflects 35 years of data acquisition, empirical analysis, interpretation, modelling - not fly by night Software Evolution Focus on software addressing real world - E-type - applications Foundations for development of a theory of software evolution now solidly established 70s findings have been extended and refined but not fundamentally changed and are now widely accepted in software engineering circles Increasingly societal dependence on software requires that they be urgently and widely conveyed to decisors in business and government

8. 8 October 2003 - 8 - © 712c[charts-mml] Some Basic E-type Program Properties Results of execution determine acceptability with user, and more generally, stakeholder satisfaction the acceptability criterion How is the real world/program relationship achieved? Hence, since domain properties may change, validity of results questioned and its acceptability put to test whenever program is executed Results of execution must reflect needs according to state of the operational domain, both as at time of execution Validity must be maintained as needs, desires and the world, change

9. 8 October 2003 - 9 - © 712c[charts-mml] Real World - Program Relationship Domain and program properties Specification abstraction Real World Domains validation partial verification? Program reification is_model _of with both models of the specification Abstraction involves assumptions that properties eliminated are not relevant for satisfactory solution Program development by reification, adds properties not in specification injecting further assumptions A specification derived from the real world domains by abstraction Must be maintained compatible and valid with one another reflect_ assumptions_about This intrinsic injection of assumptions implies need for repeated validation of program against real world and adaptation as necessary defines a program derived from it by reification

10. 8 October 2003 - 10 - © 712c[charts-mml] Domains and Program Properties As a consequence of abstraction and reification processes and of a changing real world each will also have properties not addressed by other Operational domain and program properties independently acquired, When incompatibilities affecting execution results arise, the program, procedures, and/or documentation must be changed to ensure user satisfaction But why is such evolution inevitable? Software evolution is driven, inter alia, by needs or desires for new capability and by changes in the real world

11. 8 October 2003 - 11 - © 712c[charts-mml] Inevitability The universe has an unbounded number of properties, as do the execution domains of E-type programs and their applications, which are its sub-domains Assumption invalidation a major source of continual software evolution Programs, on the other hand, are artefacts produced by humans and so are bounded in their number of implemented properties Thus there must be an unbounded number of assumptions reflected in specifications, program, interfaces, documentation, operational procedures etc. Some will become invalid as a consequence of domain and application changes Hence, every E-type program is incomplete relative to the applications and domains it addresses and there must be properties of both not reflected in program

12. 8 October 2003 - 12 - © 712c[charts-mml] Assumptions Assumptions may be by commission or omission, explicit or implicit, conscious or unconscious, recorded or unrecorded Assumption control and updating key to reliable, efficient and safer software evolution and computer usage As a system evolves, reliable anticipation, control, updating becomes more difficult, time consuming, costly Given the potential impact of an invalid assumption on program execution, the implications to a society increasingly dependent on software are profound Examples of major failures due to underlying invalidated assumptions -Airbus 320 Mulhouse crash -Ariane 5 -Cern accelerator malfunction -"Failure" of TOMS satellite data interpretation to detect ozone loss -scrapping of London Ambulance and Stock Exchange systems -sinking of the Sheffield

13. 8 October 2003 - 13 - © 712c[charts-mml] Examples of Release-based Evolution Interpretation, explanation, validation of some patterns indicates self stabilisation Common features striking Late 60s operating system Analysis to identify and “explain” behavioural patterns, sources of differences The software development and evolution process Size in modules over release sequence numbers (RSN) and a large current real time system

14. 8 October 2003 - 14 - © 712c[charts-mml] Global process a feedback-system The Software Development Process Exogenous change All in changing real world domain Installation and introduction into use closes major feedback loop Drives global evolution process as iterative sequence of releases Culmination: validated program Program Series of steps Application concept Application domain Step n Step 2 Step 1 Step i Step i+1 Final steps: installation Operational program Then operation, changing application and possibly, operation or domain, which changes domain

15. 8 October 2003 - 15 - © 712c[charts-mml] The Global Process Global process a feedback system involving people -multi-loop -multi-level -multi-agent Process not sequential, more than technical development Previous diagram a fiction, or better, a high level abstraction Application Concept Operational Program Views (Predictive) Evolving Understanding and Structure Theories, Models Procedures, Laws of Application and System Domains Requirements Analysis Computational Procedures and Algorithms Program Definition Program Corporate Management Marketeers Users User Support Project & Process Managers Exogenous Change. The observed detail can be encapsulated in laws Results in continual disciplined evolution whose details may depend on development domains

16. 8 October 2003 - 16 - © 712c[charts-mml] Recent Formulation Reflect observed phenomena and provide base and framework for a theory of software evolution III 1974 Self Regulation Global E-type system evolution is feedback regulated II 1974 Increasing Complexity As an E-type system is evolved its complexity increases unless work is done to maintain or reduce it IV 1978 Conservation of Organisational Stability The work rate of an organisation evolving an E-type software system tends to be constant over the operational lifetime of that system or segments of that lifetime VI 1991 Continuing Growth The functional capability of E-type systems must be continually enhanced to maintain user satisfaction over system lifetime VII 1996 Declining Quality Unless rigorously adapted and evolved to take into account changes in the operational environment, the quality of an E-type system will appear to be declining VIII 1971, 1996 Feedback System (Recognised 1971, formulated 1996) E-type evolution processes are multi-level, multi-loop, multi-agent feedback systems V 1978 In general, incremental growth (growth rate trend) of E-type systems constrained by need to maintain familiarity Conservation of Familiarity I 1974 Continuing Change An E-type system must be continually adapted else it becomes progressively less satisfactory in use, more difficult to evolve No.Brief Name Law

17. 8 October 2003 - 17 - © 712c[charts-mml] and validate against further observations Theory Formation Iterative extension - generalisations, definitions, theorems, practical implications Derive practical implications Practical Implications? e.g. Rules, Guidelines validate The latter provide inputs to formal theory development Formal Theory Formation Theory development a two level process based on observed data, behavioural patterns, models Definitions, Empirical Generalisation Continued Observation Interpretation Explanation Modelling Observational Theoretical Two levels Initial Data Predict behaviours on basis of emerging theory Prediction What entities are involved? and empirical generalisations

18. 8 October 2003 - 18 - © 712c[charts-mml] Entities Involved Three basic classes of entities are in involved in theory development Hypotheses/axioms may be rejected or may prove to be inferences/theorems Example of empirical approach

19. 8 October 2003 - 19 - © 712c[charts-mml] Preliminary Definitions - as per previous charts E-type operational domains are, respectively, sub-domains and sub-sets of the real world with determined or implied bounds An E-type specification abstracts an E-type application to identify the properties and behaviours that must be reflected in a system if it is to produce a solution to the application needs or terms of reference A program is satisfactory to the extent to which its execution fulfils the needs of stated or implicit stakeholders An E-type program is a set of computer executable instructions defining a valid solution to an E-type application Real world comprises the entire universe, its properties and all happenings in it An E-type application addresses a problem or supports an activity in a specified real world operational domain A specification is satisfactory if it defines a program that satisfies real world needs as reflected by the authoritative requirements of stated or implicit stakeholders

20. 8 October 2003 - 20 - © 712c[charts-mml] The real world has an unbounded number of attributes Observations - as per previous charts It may be partitioned in an unbounded number of ways into domains that, in general, each possess an unbounded number of attributes Attributes of an E-type program are abstractions of attribute sets of applications and operational domains to be supported A ttributes of an E-type application must all be accurately reflected in a program if it is to be satisfactory in all situations covered by accepted specification The attribute set of an E-type program - as distinct from such programs in execution - is bounded It is dynamic with continual unrelated changes to attributes, including those resulting from installation and use of computers and changes to computer systems

21. 8 October 2003 - 21 - © 712c[charts-mml] E–type operational domains have, in general, an unbounded number of properties Some Inferences that Follow There will always be operational domain properties not addressed by program E–type specifications and programs have a bounded number of properties but reflect an unbounded number of assumptions Assumptions about the operational domain reflected in an E-type programs may become invalid An E–type program and its operational domain may be or become incompatible E-type program execution entails uncertainty, satisfaction cannot be guaranteed Suffice to prove Principle of E-type Software Uncertainty:- However many executions of a given program have been satisfactory the next one can fail to be

22. 8 October 2003 - 22 - © 712c[charts-mml] The £64K Question What is practical relevance of a theory of software evolution?

23. 8 October 2003 - 23 - © 712c[charts-mml] Areas Addressed Much of what follows appears self-evident, elements in a code of good practice Assumption management From the many recommendations* developed, time restricts me to examples from those relating to: Innovative in that recommendations are unified by and follow from a common conceptual framework * Lehman MM and Ramil JF, Rules and Tools for Software Evolution Planning and Management, Annals of Softw. Eng., spec. iss. on Softw. Management, v. 11, Nov 2001, pp. 16 - 44

24. 8 October 2003 - 24 - © 712c[charts-mml] Assumptions Management Develop and use tool support for all of these activities Final observation In particular, review, revalidate whenever a change occurs/is made in program specification, design or implementation or occurs in operational domain Institute periodic and event-triggered reviews and assessments to anticipate or identify a need for corrections to assumption set Make search for and questioning of assumptions in all inspections and validations a specific and required activity Improve questioning of assumptions, for example, by using independent implementation, validation and inspection teams Identify, capture, structure, record, update, rationale, assumptions, decisions

25. 8 October 2003 - 25 - © 712c[charts-mml] Maintaining the Evolvability of Software Assumption management is one of a number of important, but generally neglected, antiregressive activities in software evolution management These include complexity management, other restructuring, technical documentation and related activities, now termed refactoring Their contribution to system value lies in the future increase in maintainability and evolvability of the software rather than its immediate value to users The problem: since there is no immediate visible return on investment, management is reluctant to allocate funds for their pursuit But, as is so often the case, appropriate encouragement and advice is at hand from the Bible Take a lesson from the Ant

26. 8 October 2003 - 26 - © 712c[charts-mml] Go to the Ant Thou Sluggard In the words of that wisest of all men King Solomon (Proverbs 6, 6 - 8) The Malbim, (19th cent. Jewish commentator) suggests that "… the ant eats in winter because she has prepared her food in the summer, which she can do because, despite the absence of any pressure, during the spring harvest she is willing to store part rather than eat it all, being willing to work for a future she may not see" Could we, our managers and our politicians not learn from the Ant?

27. 8 October 2003 - 27 - © 712c[charts-mml] Final Word - A Societal Challenge Increasing societal dependence on software evolution does constitute a threat It is also a challenge and, if acknowledged and addressed, an opportunity to be exploited The message that must be spread: -be aware of the threat of invisible software pollution - and other threats such as global warming, declining moral standards, the spread of terrorism and so on -accept the challenge -plan for in the future as well as the present Invest appropriately in antiregressive activities in all spheres even if without immediate return But I am an optimist, not a pessimist or Luddite

28. 8 October 2003 - 28 - © 712c[charts-mml] Acknowledgements To my new colleagues at Middlesex University and, in particular, to Professors Norman Revell and Colin Tully who welcomed me with enthusiasm, open arms and continuing support and to Leonard Miraziz for his continuing, unfailing support Today’s talk is based on 35 years of collaborative effort. My sincere appreciation and thanks go out to all the many colleagues who were partners in the work presented, who so often educated, corrected and set me straight Exemplified by Les Belady who laid the foundations with me in the 70s, Professor W M Turski who educated and guided me since the 80s and Dr J F Ramil, who has worked closely with me since the 90s Last, but certainly not least, to my wife Chava who, despite her commitment to her own professional work, shared these 50 years with me, backed and supported me in all my activities, producing, for example, today's Ant and, more significantly, our 5 children, taking care of them, especially during my frequent, extended travels

29. 8 October 2003 - 29 - © 712c[charts-mml] Relevant Papers A complete listing of papers is provided at http://www.doc.ic.ac.uk/~mml/feast Rules, Tools and Guidelines MM Lehman, Rules and Tools for Software Evolution Planning and Management, pos. paper, FEAST 2000 Workshop, Imp. Col., 10 - 12 Jul. 2000, DoC, Res. Rep. Nov 2000, a revised version to appear in Annals of Software Engineering, Spec. Issue on Software Management, vol. 11., 2001 MM Lehman, The Future of Software - Managing Evolution, inv. contr., IEEE Software, Jan-Feb. 1998, pp. 40-44 Theory MM Lehman and JF Ramil, Towards a Theory of Software Evolution - And Its Practical Impact, invited talk, ISPSE 2000, Intl. Symposium on the Principles of Software Evolution, Kanazawa, Japan, Nov 1-2, 2000 Process Modelling G Kahen, MM Lehman, JF Ramil and PD Wernick, Dynamic Modelling in the Investigation of Policies for E-type Software Evolution, ProSim 2000, International Workshop on Software Process Simulation and Modelling, 12 - 14 Jul. 2000, London, UK BW Chatters, MM Lehman, JF Ramil, P Wernick, Modelling a Software Evolution Process, ProSim'99, Softw. Process Modelling and Simulation Workshop, Silver Falls, Oregon, 28-30 Jun. 1999, also as Modelling a Long Term Software Evolution Process in J. of Softw. Proc.: Improv. and Practice, 2000 v. 5, iss. 2/3, Jul. 2000, pps. 95-102 MM Lehman, DE Perry and JF Ramil, On Evidence Supporting the FEAST Hypothesis and the Laws of Software Evolution, Proc. Metrics'98, Bethesda, MD, 20-21 Nov. 1998, pp. 84-88 P Wernick and MM Lehman, Software Process White Box Modelling for FEAST/1, ProSim '98 Workshop, Silver Falls, OR, 23 Jun. 1998. As a revised version in Journal of Systems and Software, Vol. 46, Numbers 2/3, 15 Apr. 1999 MM Lehman and P Wernick, System Dynamics Models of Software Evolution Processes, Proc. Int. Wrkshp. on the Principles fo Software Evolution IWPSE-98, ICSE-20, 20-21 Apr. 1998, Kyoto, Japan, pp. 6-10 MM Lehman, DE Perry, JF Ramil, WM Turski and P Wernick, Metrics and Laws of Software Evolution - The Nineties View, Proc. Fourth International Symposium on Software Metrics, Metrics 97, Albuquerque, New Mexico, 5-7 Nov. 97, IEEE Comp. Soc. or. n. PR08093, pp 20-32. Also as in K El Eman and N H Madhavji (eds.), Elements of Software Process Assessment and Improvement, IEEE CS Press, 1999 WM Turski, A Reference Model for the Smooth Growth of Software Systems, IEEE Trans. Softw. Eng., v. 22, n. 8, Aug. 1996, pp. 599 - 600 Estimation JF Ramil and MM Lehman, Exploring Cost Estimation Models in the Context of Continuing Software Evolution, FESMA-AEMES Software Measurement Conference 2000 "Management Excellence through IT Measurement", Madrid, Spain Oct. 18-20, 2000 Lessons Learnt (e.g., Modelling Methodology) JF Ramil and MM Lehman, Metrics of Software Evolution as Effort Predictors - A Case Study, Proc. ICSM 2000, Int. Conference on Software Maintenance, 11-14 Oct. 2000, San Jose, CA Component-based and Integration-intensive Processes Other MM Lehman and JF Ramil, Software Evolution Phenomenology and Component Based Software Engineering, IEE Proc. Softw., sp. issue on Component Based Software Engineering, scheduled for Dec. 2000, earlier version as Tech. Rep. 98/8, Imperial College, London, Jun. 1998 JF Ramil (ed.), Preprints of FEAST 2000 International Workshop on Feedback and Evolution in Software and Business Process, Imp. Col., London, 10 - 12 Jul. 2000, 124 pp. JF Ramil, MM Lehman and G Kahen, The FEAST Approach to Quantitative Process Modelling of Software Evolution Processes, Proc. PROFES'2000 2nd International Conference on Product Focused Software Process Improvement, Oulu, Finland, 20 - 22 Jun. 2000, in Frank Bomarius and Markku Oivo (eds.) LNCS 1840, Springer Verlag, Berlin, 2000, pp. 311 - 325. MM Lehman, Feedback in the Software Evolution Process, Keynote Address, CSR Eleventh Annual Workshop on Software Evolution: Models and Metrics. Dublin, 7-9 Sept. 1994, Workshop Proc., Information and Software Technology, sp. is. on Software Maintenance, v. 38, n. 11, 1996, Elsevier, 1996, pp. 681 - 686

30. 8 October 2003 - 30 - © 712c[charts-mml] Bibliography A listing with additional papers and other material is provided at and some may be accessed via http://www.cs.mdx.ac.uk/staffpages/mml References indicated with an ‘ * ’ have been reprinted in Lehman MM & Belady LA, Program Evolution—Processes of Software Change, Acad. Pr., London 1985 *Belady LA & Lehman MM, An Introduction to Program Growth Dynamics, in Statistical Computer Performance Evaluation, W Freiburger (ed), Academic Press, New York, 1972, pp. 503 - 511 Boehm BW, Software Engineering, IEEE Trans. on Comp., v. C-5, n. 12, Dec. 1976, pp. 1226 - 1241 id., A Spiral Model of Software Development and Enhancement, Computer, v. 21, May 1988, pp. 61 - 72 id., Software Engineering Economics, Englewood Cliffs, N.J, Prentice-Hall, 1981 Brooks FP, No Silver Bullet - Essence and Accidents of Software Engineering, Information Processing 86, Proc. IFIP Congress 1986, Dublin, Sept. 1-5, Elsevier Science Pubs. (BV), (North Holland), pp. 1069 - 1076 *Lehman MM, The Programming Process, IBM Research Report RC 2722, IBM Research Centre, Yorktown Heights, NY, Sept. 1969, also in Program Evolution— Processes of Software Change q.v. *id., Programs, Cities, Students - Limits to Growth?., Imperial College. Inaugural Lecture Series, v. 9, 1970 - 1974, also. in [GRI78], pp. 42 - 69, Lehman MM & Belady LA, 1985, pp. 133 - 163, also in Program Evolution—Processes of Software Change q.v. *id., Laws of Program Evolution - Rules and Tools for Programming Management, Proc. Infotech State of the Art Conf., Why Software Projects Fail, - Apr 9 - 11 1978, pp. 11/1 - 11/25 *id., Programs, Life Cycles and Laws of Software Evolution, Proc. IEEE Sp. Iss. on Softw. Eng., v. 68, n. 9, Sept 1980, pp. 1060 - 1076 Lehman MM, Stenning V & Turski WM, (1984). Another Look at Software Design Methodology, ICST DoC Res. Rep. 83/13, Jun 1983. Also, Software Engineering Notes, v. 9, no 2, Apr 1984, pp. 38 - 53 Lehman MM & Belady LA, Program Evolution,- Processes of Software Change, Academic Press, London, 1985, 538 p. id,. Evolution - The Cause of Iteration, Third Process Workshop, Breconridge, CO, Nov. 1986. In Iteration in the Software Process - Proc. 3rd Int. Process Wrkshp., Dowson M (ed), IEEE Comp. Soc. Press, Mar. 1987, pp. 29 - 32 Lehman MM, Process Models, Process Programs, Programming Support, Inv. Resp. To A Keynote Addr. By Lee Osterweil, Proc. 9th Int. Conf. on Softw. Eng., Monterey, CA, 30 Mar. 2 Apr 1987, IEEE Comp. Soc. pub. n. 767, IEEE Cat. n. 87CH2432-3, pp. 14 - 16 id., Uncertainty in Computer Application, Comm. of the ACM, Vol. 33, No. 5, May 1990, pp. 584-586 id., Uncertainty in Computer Application and its Control through the Engineering of Software, J. of Softw. Maint., Res. & Pract., v. 1, 1 Sept 1989, pp. 3 - 27 id., Models and Modelling in Software Engineering, Ency. of Softw. Eng., J Marciniak (ed), Wiley and Co, 1994, vol. 1, pp. 698 - 702 id., Software Evolution, loc cit, vol. 2, pp. 1202 - 1208 Osterweil L, Software Processes are Software Too, Iteration in the Software Process, Proc. of the 3rd Int. Proc. Worksh., Breckenridge, CO, 17 - 19 Nov. 1986, IEEE cat. n. TH0184-2, IEEE Comp. Soc. order n. 709, 1987, pp. 79 - 80 Perry DE, Policy and Product-Directed Process Instantiation, Proc. of the 6th Int. Softw. Process Workshop, 28-31 October 1990, Hakodate, Japan Rajlich VT and Bennet KH, A Staged Model for the Software Life Cycle, Computer, July 2000, pp. 66 - 71 Turski WM, And No Philosophers' Stone Either, Inf. Processing 86, Proc. IFIP Congr., Dublin, Sept. 1 - 5, 1986, Elsevier Sci. Pubs, London, pp. 1077 - 1080 Wilkes M V, Wheeler D J & Gill S, The Preparation of Programs for an Electronic Digital Computer, Addison Wesley Press Inc., 1951, 167 pp. Wirth N, Program Development by Stepwise Refinement, CACM, v.14, n.4, Apr 1971, pp.221-227 *Woodside CM, A Mathematical Model for the Evolution of Software, J. of Sys. and Softw. vol. 1, no. 4, Oct 1980, pp. 337 - 345 Zurcher FW and Randell B, Iterative Multi-Level Modelling - A Methodology for Computer System Design, IBM Res. Rep. RC 1938, Nov. 1967, IBM Res. Centre, Yorktown Heights, NY 10594. Also in Information Processing 67, Proc. IFIP Congr. 1968, Edinburgh, Aug. 1968, pp. D138 - 142