CS 446 Abstracts 7, 18 Oct 1995

CS 446 Fall Quarter Abstracts from IEEE TC ECCS, Notes 7A Gio Wiederhold
Experimental Seminar on Large Scale Software Construction.

IEEE Technical Segment Committee on Engineering of Complex Computer Systems

IEEE TC ECCS NEWSLETTER, Vol.2 No.2

October 1995 Contents of this issue
1. Editorial -- Mike Hinchey, NJIT, USA
2. "Engineering of Complex Computer Systems -- A New Challenge for Computer Types Everywhere", Part I: "Let's Agree on What These Systems Are" -- Alex Stoyenko, NJIT, USA
3. "Fighting Complexity" -- David Lorge Parnas, McMaster University, Canada
4. "Where is Software Headed" -- Phil Laplante, BCC/NJIT Education Technology Center, USA
5. Call for Participation: ICECCS'95, 1st IEEE International Conference on the Engineering of Complex Computer Systems -- Mike Hinchey, NJIT, USA --------- Omitted
6. CFP: ICECCS'96, 2nd IEEE International Conference on the Engineering of Complex Computer Systems -- Mike Hinchey, NJIT, USA -------- omitted

1. Editorial

-- Mike Hinchey, NJIT, USA hinchey@cis.njit.edu

Dear Friends,
It has been some time since our last newsletter, as we've all had other priorities, namely our forthcoming 1st International Conference on the Engineering of Complex Computer Systems (ICECCS'95).
Sincerest thanks to all those who have given their time and effort in the run-up to the conference in Fort Lauderdale. We have a fine technical program, a number of attractive tutorials, as well as panel sessions and a number of tool demonstrations. This promises to be a highly enjoyable and informative event. More complete details are available via the World-Wide Web at:
http://rtlab12.njit.edu:8000/rtcl_pub_html/Mosaic/act/iceccs95.html
or via anonymous FTP from our Cambridge site:
ftp://ftp.cl.cam.ac.uk/IEEE-TSC-ECCS/program.ascii
Please remember that the deadline for early registration is now very close.
We are, of course, already planning for ICECCS'96, which will be held in Montreal, Canada, 21 - 25 October 1995. The Call for Papers is included in this issue of the newsletter, and further details will be available via the World-Wide Web as:
http://rtlab12.njit.edu:8000/rtcl_pub_html/Mosaic/act/iceccs96.html
In this issue we also consider the topic of ECCS in somewhat more detail. Alex Stoyenko writes (which appeared as an IEEE Computer "Hot Topics" article) on the topic of ECCS, describing the need and motivation for such a field of study and research, and what we consider to be complex systems.
This issue also includes the abstract of the keynote address of Prof. David Lorge Parnas at ICECCS'95 (Prof. Parnas is one of 4 keynote speakers), which discusses various means of fighting complexity.
The third feature in this issue is an article entitled "Where is Software Headed" by Phil Laplante, which also appeared as part of an IEEE Computer feature article.
We hope that these articles will provide food for thought in advance of ICECCS'95, and we hope to see as many of you as possible there. Please also pencil ICECCS'96 into your calendar, and consider contributing in some way: by submitting a paper or tutorial proposal, or by participating in tool demonstrations, etc.
Until Florida and ICECCS'95 ....
-- Mike Hinchey.

2. Engineering of Complex Computer Systems --- A New Challenge for Computer Types Everywhere.

Part I: Let's Agree on What These Systems Are.
-- Alex Stoyenko, with assistance from Tom Bihari, Harry Crisp, Prabha Gopinath, Dieter Hammer, Bob Harrison, Mike Hinchey, Steve Howell, Jim Huang, Tad Ichikawa, Phil Laplante, Bud Lawson, Tom Marlowe, Bruce Shriver and many (other) IEEE TSC on ECCS volunteers.
Contact Address:
Alexander D. Stoyenko
Real-Time Computing Laboratory
Department of Computer and Information Science
New Jersey Institute of Technology
University Heights
Newark, New Jersey 07102 USA
(201) 596-3366 (phone) (201) 596-5777 (fax)
alex@rtlab12.njit.edu
http://rtlab12.njit.edu:8000/welcome.html

INTRODUCTION

What is a complex problem? A complex computer system? Engineering of such systems? In the past five years, there have been scores of articles and books, meetings and newsgroups, and tools and applications --- purporting to address these topics. There must therefore be scores of folks out there who truly understand these systems and know how to talk about them. Are there? Let us find out.

WHAT ARE NOT (NECESSARILY) COMPLEX COMPUTER SYSTEMS

Obviously, no group or definition can own a perfect definition of complex computer systems and their engineering. However, it is important to understand where some seemingly appropriate definitions in fact do not define what these systems are.
One existing definition appears to equate complex computer systems with computer-based systems. Not so, in our opinion. While naturally most example computer-based systems possess real-time or embedded real-time features, this class of systems includes great many that are, frankly, not so ``complex'': programmable toasters, home thermostats and --- the granddaddy of all examples --- cruise controls circa the early 80s. On principle, we refuse to refer to any system with a perfectly static definition and a complete state transition diagram with well under 100 states and transitions as complex.
Another existing definition ties engineering of complex computer systems to what has become known as ``systems engineering'' or sometimes ``software and systems engineering''. This also has problems, for it seems to suggest that the hardest problems are found where the computer system interfaces with the external environment, including machines, humans and other largely non-Turing and rather physical entities. (This definition ironically pretty much ``abstracts away'' the issues typically faced by ``computer engineers'' and ``computer scientists''.) We certainly agree that this interface has its problems, many of which ``complex''. However, we are equally interested in what happens on the computer system side of that interface.
Lastly, one finds a definition in the systems integration community, that is mostly concerned with complexity found in connecting and integrating components. While we once again agree that system integration is a truly challenging area, and no laughing matter, this definition ignores the complexity which may lurk inside an individual component, which may be as complex as an entire system. Integration alone is not the only complex problem.

WHAT (WE THINK) ARE COMPLEX COMPUTER SYSTEMS

As demands on functional and non-functional objectives of computer systems have continued unabated for the last 30-years, so has the size of the resultant systems. They have become extremely large, consisting of scores of components, including distributed and parallel software, hardware, and communications, which increasingly interface with a large number of external devices, such as sensors and actuators. Large (and certain small) systems also tend to be complex because of the number of interconnections between their components tends to be large and complicated. Even as users place increasing importance on such non-functional objectives as availability, fault-tolerance, security, safety, and traceability, the operation of a complex computer system is also required to be ``non-stop'', ``real-time'', adaptable, and dependable, providing graceful degradation. It is typical that such systems have lifetimes measured in decades; over this period, components evolve, logical and physical interconnections change, and interfaces and operational semantics change accordingly, often leading to increased system complexity. Other factors that may also affect complexity are geographic distribution of processing and databases, interaction with humans, and unpredictability of system reactions to unexpected sequences of external events.
We thus define the engineering of complex computer systems as all activities pertinent to specifying, designing, prototyping, building, testing, operating, maintaining, and evolving of complex computer systems. While in the past, relatively non-complex ``traditional'' systems sufficed for most computer control applications, the new and emerging demands of applications and the evolution of computer architectures and networks now essentially ``force'' systems to be complex, given our current understanding how to engineer these systems. Complex computer systems are found in almost every industry. These include industrial process control, aerospace and defense, transportation and communications, energy and utilities, medical and health, commercial data processing, and others. Unfortunately, the current state-of-the-art in research and technology has clearly fallen far behind the requirements of industrial, commercial and government complex computer systems.

KEEPING COMPLEXITY IN CHECK --- WHERE DO WE FIND IT?

An inquisitive reader may observe that our definition of complex computer systems is rather wide. Indeed, how do we know which systems are and which are not complex? A programmable toaster is not complex. An integrated air defense system, such as Aegis, is. What about systems that are somehow ``in-between''? There seems to be no easy answer to this question. Somehow, those directly involved seem to know. Somehow, certain attributes of systems, such as dynamicity, or the presence of multiple, competing objectives, or evolutionary tendencies, seem to contribute. Inability to ``separate concerns'' (a'la Parnas) contributes to complexity. ``Classic'' computer-theoretic complexity too contributes, such as for instance where exhaustive performance analysis of a system is prohibitively expensive.

AN EXAMPLE SYSTEM

Of all complex computer systems, none have received as much attention as those that are of the real-time, safety-critical variety. Typically, actions of such a system must be not only predictable but also controllable by people. People are ultimately accountable for the consequences of a system's actions. Therefore, a system that people are asked to use in accomplishing their mission must be (in the user's mind) controllable, in that it yields predictable results acceptably soon. Quite possibly, on the other hand, the subsystems of a complex system could be individually deterministic but when integrated form a non-deterministic whole. This is due in part to neglect of macro-level control issues of migrating threads of control that flow across subsystem boundaries when the complex system is performing a critical function. Complex systems therefore require coordination (macro-level control) of their activities to yield a smoothly connected and predictably responsive entity.
One concrete example of a complex computer system, the Aegis integrated fleet defense system, has been in operation for over quarter of a century. Many components of the Aegis are themselves fairly complex as are their interactions. By way of illustration, consider two Aegis Combat subsystems: the Lamps system, which has to illuminate a target, and the Harpoon missile system, which has to destroy it. Each system can complete its assigned task on its own and thus is independently deterministic. But the two systems are also interdependent, in that Lamps illumination is needed by missile guidance to accomplish the mission. Both subsystems are also quite rich in structure, in the functional and non-functional objectives they face, and in the way their components interact, in turn.

LOOKING FORWARD TO THE SEQUEL

In the sequel, we will examine a number of key application domains where engineering of complex computer systems finds its natural habitat. Owing to complexity and rapidly growing search and solution spaces, heuristics must be used for scores of purposes, in these systems. We will discuss these as well. Ongoing work by some of the existing groups in this area will be presented, such as that by the IEEE Computer Society's Technical Segment Committee on Engineering of Complex Computer Systems (TSC on ECCS) and the Naval Surface Warfare Center's Engineering of Complex Systems program. In the meantime, the readers may wish to contact Alex Stoyenko (alex@rtlab12.njit.edu) regarding the TSC, Mike Hinchey (Mike.Hinchey@cl.cam.ac.uk) to subscribe to the TSC newsletter, or browse http://www.cl.cam.ac.uk/IEEE-TSC-ECCS/eccs.html and http://rtlab12.njit.edu:8000/rtcl_pub_html/Mosaic/act/iceccs95.html for more information.

TO PROBE FURTHER

1. Newsletters of the IEEE Technical Segment Committee on Engineering of Complex Computer Systems, contact Mike Hinchey, Editor, Michael.Hinchey@cl.cam.ac.uk
2. Proceedings of the 1994 and 1995 Workshops on Engineering of Systems in the 21st Century, contact Harry Crisp, hcrisp@relay.nswc.navy.mil.
3. A. D. Stoyenko, P. A. Laplante, R. Harrison, T. J, Marlowe, ``Engineering of Complex Systems: A Case for Dual Use and Defense Technology Conversion,'' IEEE Spectrum, Vol. 31, No. 11, pp. 32--39, December 1994.

3. Fighting Complexity

-- David Lorge Parnas, McMaster University, Canada Abstract:
A system can be considered complex if its shortest useful description is relatively long. The length of the shortest descriptions indicates the amount of information required to understand the product. Software systems are almost always perceived as complex and software engineering researchers are all studying ways to deal with complexity. The fact that we must work with these systems in spite of the fact that they are difficult to understand has many practical consequences. "Cut and try", a development philosophy considered unprofessional in other areas of engineering, has become the norm in software development.
There are three approaches to dealing with complexity. One approach is to provide tools that help people to find the information that they need; another is to reduce the amount of information that a programmer or user will need, the third is revise the product in a way that reduces its complexity. The first approach is easier and yields impressive short-term results, but that the other two approaches can be more effective in the long-run. Fortunately, the three methods are mutually supportive. We illustrate these general approaches with specific techniques for dealing with complexity in computer systems.

Biosketch:
Dr. David Lorge Parnas, born 10 February 1941, is the holder of the NSERC/Bell Industrial Research Chair in Software Engineering in the Department of Electrical and Computer Engineering at McMaster University in Hamilton, Ontario. He is a member of the Communications Research Laboratory and Principal Investigator for the Telecommunica- tions Research Institute of Ontario. He has been Professor at the University of Victoria, the Technische Hochschule Darmstadt, the University of North Carolina at Chapel Hill, Carnegie Mellon University and the University of Maryland. He has also held non-academic positions advising Philips Computer Industry (Apeldoorn), the United States Naval Research Laboratory in Washington, D.C. and the IBM Federal Systems Division. At NRL, he instigated the Software Cost Reduction (A-7) Project, which developed and applied software technology to aircraft weapon systems. He has advised the Atomic Energy Control Board of Canada on the use of safety-critical real-time software at the Darlington Nuclear Generation Station.
The author of more than 170 papers and reports, Dr. Parnas is interested in most aspects of computer system design. His special interests include precise specifica- tions, real-time systems, safety-critical software, program semantics, language design, software structure, and syn- chronisation. Dr. Parnas seeks to find a "middle road" between theory and practice, emphasising theory that can be applied to improve the quality of our products.
Professor Parnas received his Ph.D. in Electrical Engineering from Carnegie-Mellon University, and an honorary doctorate from the ETH in Zurich. He won an ACM "Best Paper" Award in 1979, and two "Most Influential Paper" awards from the International Conference on Software Engineering. He is a Fellow of the Royal Society of Canada and a Fellow of the Association for Computing Machinery (ACM).
Dr. Parnas has contributed a number of fundamental concepts to the field of software engineering. He became well-known outside of his profession when he resigned from a committee advising the "Star Wars" Project, explaining why he felt that the project was fraudulent and dangerous. In the three years following his resignation from that Star Wars committee he gave more than 150 talks explaining why software problems would make President Reagan's dream project a nightmare for the world.
Deeply concerned that technology be applied to the benefit of society, David Parnas was the first winner of the "Norbert Wiener Award for Professional and Social Responsi- bility" (awarded by Computing Professionals for Social Responsibility) and has been President of the Canadian group "Science for Peace" and an officer of Canadian Pugwash.

4. Where is Software Headed?

-- Phil Laplante, Dean of Engineering and Technology
BCC/NJIT Technology Education Center, Pemberton, NJ 08068, USA
laplante@njit.edu

In order to understand where software is headed, it is interesting and informative to look back at where software has been. From its earliest inception as the reconfiguration of wires and switches, to machines codes, microprograms, and macroprograms, to assembly codes and higher order languages; the development of software has always been a quest for more abstraction in support of more complexity. And it is unlikely that software engineering will change the direction of that evolution.
As hardware systems become increasingly more complex (billions of gates in newer systems as opposed to a few hundred in the first computers) and support more and different kinds of devices and applications, a richer framework for software engineering will be needed to permit the conversion of complex behavior from conception to a set of instructions that ultimately map into those gates. Fortunately, those very complex machines for which the software is targeted, provide powerful platforms from which the software can be constructed. For example, object-oriented methods require bulky compilers that generate relatively massive code. However, the speed of even the most modest personal computers is enough to mask the inefficiency of such primitive software engineering methods. I say primitive because, although object-oriented techniques have been hailed as innovative and the solution to so many software engineering problems such as reusability, testability, maintainability, and so forth (the so-called "ilites"), it is deeply rooted in concepts that evolved in the 1970s with the revolutionary language CLU [1] and in the theories of information hiding attributed to David Parnas [2].
Nor is any single framework for software engineering (object-oriented or otherwise) going to be sufficient. At a recent NATO Advanced Study Institute on Real-Time Systems, a distinguished panel was asked "What is the proper software engineering framework for the development of real-time systems?" All six members of the panel answered differently [3]. It is my steadfast opinion that development of a unified software engineering framework for all applications areas is folly. Efforts would be best expended concentrating on applications areas. Frankly, some academics (and some practitioners) have begun to wonder if Computer Science as a distinct field can survive -- the study of architecture has become dominated by electrical engineers, the study of algorithms by mathematicians, and the study of software engineering by applications experts. Why should not traditional software engineering be absorbed into applications disciplines? This eventuality represents somewhat of a full circle in the evolution of computing science -- a science that was originally founded by physicists, mathematicians, and engineers.
To a certain extent I have avoided a prediction for the appearance of software engineering in the next century. I have argued that as systems become more complex, so should software engineering techniques and tools. One prediction is that software engineering tools will expand beyond the rather flat, keyboard and screen driven interfaces. Human beings arguably perform more complex processing while driving a car. Why not have software engineering tools that involve interaction with sound, force feedback, and use movements of the eyes, feet, arms, voice, and head for input? The next software engineering tools will be more graphical, colorful, and musical. We must expand the portions of the brain that are used in the preparation of computer programs -- typing and clicking are not enough.
Current research focuses on artificially intelligent software systems using "intelligent agents" that can anticipate the needs of users and systems designers. While these agents are promising, we must never forget their origins in early expert systems (nested CASE statements) along with languages supporting data abstraction such as CLU (and successor object-oriented languages like smalltalk). We must also never forget what software engineering tools are -- abstraction mechanisms -- which simply represent layers of complexity that can now be smoothed over by increasingly fast hardware. The original Fortran compiler was introduced as an "automatic program generator" [4] -- the ultimate in artificially intelligent systems (The Fortran compiler has not evolved much beyond its original, brilliant form). New forms of "intelligent" software and software engineering tools will be largely incremental improvements on existing manifestations with better interfaces enabled by faster hardware.
The sad fact is that software engineering has not evolved nearly as fast as the hardware has. And most of the innovations in software engineering and software systems are not profound innovations, rather, they are variations on very old themes. These new innovations are primarily enabled by faster hardware and better interface devices. It is not unbelievable that the next generation of software won't be the same. I don't mean to sound pessimistic or mean-spirited -- I am not. I simply am not allured by the bells and whistles that are attached to well-worn and well-known priniciples of software engineering. And I caution skepticism for some of the "snake-oil" that I feel is being sold as panacea.
What will the next generation of software be like? It will be more of the same, just faster, more of it, and with prettier wrapping.
[1] Liskov , B., A. Snyder, R. Atkinson, and C. Schaffert, "Abstraction mechanisms in CLU," Communications of the ACM, vol 20, 1977, page 564.
[2] Parnas, D. L., "On The Criteria To Be Used In Decomposing Systems Into Modules, Communications of the ACM, vol. 15, no. 12, Dec. 1972, pp. 1053-1058.
[3] Proceedings of the NATO ASI on Real-Time Computing, Elsevier, 1992.
[4] Backus, John, "Programming in the Nineteen Fifties -- some Personal Impressions," A History of Computing in the Twentieth Century, edited by N. Metropolis, J. Howlett, and Gian-Carlo Rota, Academic Press, 1980.