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
Engineering of Complex Computer Systems
IEEE TC ECCS NEWSLETTER, Vol.2 No.2
Contents of this issue
-- 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
-- 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
-- Mike Hinchey, NJIT, USA
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:
or via anonymous FTP from our Cambridge site:
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:
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
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
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
Until Florida and ICECCS'95 ....
-- Mike Hinchey.
2. Engineering of Complex Computer Systems --- A New Challenge for Computer
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.
Alexander D. Stoyenko
Real-Time Computing Laboratory
Department of Computer and Information Science
New Jersey Institute of Technology
Newark, New Jersey 07102 USA
(201) 596-3366 (phone) (201) 596-5777 (fax)
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
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
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
(email@example.com) regarding the TSC, Mike Hinchey
(Mike.Hinchey@cl.cam.ac.uk) to subscribe to the TSC newsletter,
for more information.
TO PROBE FURTHER
1. Newsletters of the IEEE Technical Segment Committee on Engineering
of Complex Computer Systems, contact Mike Hinchey, Editor,
2. Proceedings of the 1994 and 1995 Workshops on Engineering of
Systems in the 21st Century, contact Harry Crisp,
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,
3. Fighting Complexity
-- David Lorge Parnas, McMaster University, Canada
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
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
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  and in the theories of information
hiding attributed to David Parnas .
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 .
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"  -- 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.
 Liskov , B., A. Snyder, R. Atkinson, and C. Schaffert,
"Abstraction mechanisms in CLU," Communications of the ACM,
vol 20, 1977, page 564.
 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.
 Proceedings of the NATO ASI on Real-Time Computing, Elsevier, 1992.
 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.