sss ssss      rrrrrrrrrrr
                      ssss    ss       rrrr   rrrr
                     sssss     s       rrrr    rrrr
                     ssssss            rrrr    rrrr
                      ssssssss         rrrr   rrrr
                          ssssss       rrrrrrrrr
                    s      ssssss      rrrr  rrrr
                    ss      sssss      rrrr   rrrr
                    sss    sssss       rrrr    rrrr
                    s  sssssss        rrrrr     rrrrr
         +=======    Quality Techniques Newsletter    =======+
         +=======             April 2001              =======+

QUALITY TECHNIQUES NEWSLETTER (QTN) is E-mailed monthly to Subscribers
worldwide to support the Software Research, Inc. (SR), TestWorks,
QualityLabs, and eValid user communities and other interested parties to
provide information of general use to the worldwide internet and
software quality and testing community.

Permission to copy and/or re-distribute is granted, and secondary
circulation is encouraged by recipients of QTN provided that the entire
document/file is kept intact and this complete copyright notice appears
with it in all copies.  Information on how to subscribe or unsubscribe
is at the end of this issue.  (c) Copyright 2003 by Software Research,


                         Contents of This Issue

   o  Conference Description: 14th Annual International Internet and
      Software Quality Wek (QW2001)

   o  eValid Ver. 2.2 New Feature Summary

   o  Prof. Lori Clarke speaks on "Finite State Verification for
      Software Systems"

   o  Software Is Different, by Boris Beizer (Part 1 of 3)

   o  QWE2001 Call for Participation (November 2001)

   o  David L. Parnas Symposum at ICSE(May 2001)

   o  6th International RST/Ada Conference (May 2001)

   o  SERG Reports (#392, #393)

   o  QTN Article Submittal, Subscription Information


           Conference Description: 14th Annual International
               Internet & Software Quality Week (QW2001)

                       29 May 2001 - 1 June 2001

                     San Francisco, California  USA


                  CONFERENCE THEME: The Internet Wave

The 16-page full-color brochure for the QW2001 conference is available
for download from the conference WebSite.  To print your own copy go to:


Conference Description:

    QW2001 is the 14th in the continuing series of International
    Internet and Software Quality Week Conferences that focus on
    advances in internet quality, software test technology, quality
    control, risk management, software safety, and test automation.
    There are 14 in-depth tutorials on Tuesday, and 4 Post-Conference
    workshops on Friday.

KEYNOTE TALKS from industry experts include presentations by:

      > Dr. Dalibor Vrsalovic (Intel Corporation) "Internet
        Infrastructure: The Shape Of Things To Come"
      > Mr. Dave Lilly (SiteROCK) "Internet Quality of Service (QoS):
        The State Of The Practice"
      > Mr. Thomas Drake (Integrated Computer Concepts, Inc ICCI)
        "Riding The Wave -- The Future For Software Quality"
      > Dr. Linda Rosenberg (GSFC NASA) "Independent Verification And
        Validation Implementation At NASA"
      > Ms. Lisa Crispin (iFactor-e) "The Need For Speed: Automating
        Functional Testing In An eXtreme Programming Environment (QW2000
        Best Presentation)"
      > Mr. Ed Kit (SDT Corporation) "Test Automation -- State of the
      > Mr. Hans Buwalda (CMG) "The Three "Holy Grails" of Test
        Development (...adventures of a mortal tester...)"

SIX PARALLEL PRESENTATION TRACKS with over 60 presentations:

      > Internet: Special focus on the critical quality and performance
        issues that are beginning to dominate the software quality
      > Technology: New software quality technology offerings, with
        emphasis on Java and WebSite issues.
      > Management: Software process and management issues, with special
        emphasis on WebSite production, performance, and quality.
      > Applications: How-to presentations that help attendees learn
        useful take-home skills.
      > QuickStart: Special get-started seminars, taught by world
        experts, to help you get the most out of QW2001.
      > Vendor Technical Track: Selected technical presentations from
        leading vendors.


      > Birds-Of-A-Feather Sessions (BOFS) [organized for QW2001 by
        Advisory Board Member Mark Wiley (nCUBE),
      > Special reserved sections for QW2001 attendees to see the SF
        Giants vs. the Arizona Diamondbacks on Wednesday evening, 30 May
        2001 in San Francisco's world-famous downtown Pacific Bell Park.
      > Nick Borelli (Microsoft) "Ask The Experts" (Panel Session), a
        session supported by an interactive WebSite to collect the
        most-asked questions about software quality.

Get complete QW2001 information by Email from  or go to:



                  eValid Ver. 2.2 New Feature Summary

This note summarizes new features in eValid Ver. 2.2.  A complete
description can be found at:

* Download Location:  You can download the new eValid Ver. 2.2 at these
  URLs.  Your existing eValid Ver. 2.1 keys will work with eValid Ver.
  2.2.  Download from:


* Revised Menu Structure:  The pulldown menu structure has been
  simplified and consolidated for ease of use.  We have added menu
  access (from the View Script window) to Modal Dialog commands and
  Extrinsic commands.

* New ToolBar Controls:  There are new graphic controls for record,
  play, single-step, pause/resume, and stop available now on the tool
  bar.  eValid looks like a VCR!

* Animated Playback:  The View Script dialog highlights the current
  command being executed.

* Variable Complexity Download Option:  You can choose a range of
  download characteristics to vary the level of detail.  Three levels
  are available:

    > FULL Get full, complete, normal download [Default].
    > TEXT Get text files only, no images, animations, or sounds.
    > URL  Get only the base URL.

* Chart Additions:  eValid's charts now also indicate:

    > Green Line: The average value of all measurements shown on the
      chart.  This normally is your "baseline".
    > Yellow Line: 25% below the average value.
    > Red Line: 25% above the average value.

* Many New Extrinsic Commands:  There are many new extrinsic (edit-in)
  commands to eValid's command language, including:  MatchNotString,
  OnErrorGoScript, OnAlarmGoScript, SecureDataID, Lock, Unlock.

* Supported Platforms.  eValid supports the Windows NT/2000/PE/ME
  family.  Some eValid scripts that work perfectly on these platforms
  may have some problems if you are running Windows 98.  Some eValid
  scripts that work perfectly on these platforms may have severe
  problems if you are on Windows 95.

* Revised Pricing.  New pricing that gives users wider choices takes
  effect very soon.  Completion pricing information is available at:


                    University of California, Irvine
                 Distinguished Speaker Series 2000-2001

                           Prof. Lori Clarke
         Laboratory for Advanced Software Engineering Research
                University of Massachusetts, Amherst, MA

             Finite State Verification for Software Systems

        Date:           Wednesday, May 2
        Time:           2:00 pm - 3:30 pm
        Location:       McDonnell Douglas Auditorium
                        University of California, Irvine

No cost to attend.

Email RSVP requested.
To:  Rick Martin,
By:  Monday, April 30

Faculty Host:  Debra J. Richardson, ICS Chair 

Abstract: Finite State Verification approaches, such as model checking,
have been successfully applied to hardware systems, but generally do not
scale to handle the complexity of software systems. This talk will
describe FLAVERS, FLow Analysis for VERifying Systems, that has been
developed to verify user-specified properties of software systems.
FLAVERS handles the complexity of software systems by focusing on events
instead of state information and by creating a conservative, but very
concise, representation of the system. One of the advantages of FLAVERS
is that the system model is created automatically using predefined
abstraction techniques.

With FLAVERS, users form queries about important properties of their
system and either receive assurances that the properties can never be
violated by any execution of the system or are shown traces where such
violations might occur. We believe that FLAVERS can successfully scale
to handle software systems as well as bridge the gulf between the
mathematical sophistication required for formal verification and the
capabilities and time constraints of practicing software engineers. Our
goal is to hide the "formal" in formal verification, yet provide
powerful reasoning tools that can deal with complex, distributed

About the Speaker: Lori A. Clarke received a B.A. degree in mathematics
from the University of Rochester and a Ph.D. degree in Computer Science
from the University of Colorado. She joined the Computer Science faculty
at the University of Massachusetts, Amherst in 1975 where she has
continued to pursue research on a broad range of software engineering
issues including verification of distributed systems and distributed
object technology.

Dr. Clarke is a Fellow of the ACM, a recipient of the University of
Massachusetts Chancellor's medal, a member of the IEEE Computer Society
Publications Board, the board of directors of the Computing Research
Association (CRA), the executive committee of the ACM Special Interest
Group on Software Engineering (SIGSOFT), and the steering committee for
the International Conference on Software Engineering (ICSE). She is a
former IEEE Distinguished Visitor, ACM National Lecturer, member of the
NSF CCR advisory board, recipient of a University Faculty Fellowship,
associate editor of ACM Transactions on Programming Languages and
Systems and the IEEE Transactions on Software Engineering, and
secretary/treasurer, vice-chair, and chair of SIGSOFT. She has served on
or chaired numerous program committees as well as served as program co-
chair of ICSE 92 and general chair of ICSE 2003.

Directions and parking information are available at:


                  Software Is Different (Part 1 of 3)
                              Boris Beizer

      Note:  This article is taken from a collection of Dr. Boris
      Beizer's essays "Software Quality Reflections" and is
      reprinted with permission of the author.  We plan to include
      additional items from this collection in future months.  You
      can contact Dr. Beizer at .

1. The Problem

Who will argue that software quality isn't a problem?  As software
users, we don't get the quality we need and, as software developers, we
don't deliver the quality our users want; and if we do, it's at a higher
cost and takes longer than our managers and marketeers would have it.
Who, if anybody, is to blame? The usual practice has been to blame
software designers, implying that if they worked more carefully, then
these perennial quality problems would be solved.  That may be a popular
thing to do, but it won't lead to better software.  Blaming programmers
has been the prevailing approach for a half century of software
development: It hasn't solved the problem yet, so it's time to look in
different directions.

Quality assurance, as a discipline, is rooted in the manufacturing
process.  The design of a widget, say, is rarely questioned because most
design defects are found before manufacturing begins.  The problems, if
any, are usually production problems.  The core of the differences
between software quality and widget (traditional) quality is that
traditional quality people often have preconceived notions about the
world.  Although these assumptions are based on common sense, they don't
apply to software.  Users make the same common-sense assumptions about
software.  And, unfortunately, many software developers also accept
these misconceptions.  The consequence is that users, managers, and we
who develop or assure software's quality, have inappropriate
expectations for it.

2.  The Fundamentally Flawed Assumptions

2.1.  General

In his classic and, at the time, revolutionary book, Games People Play
[BERN64], Eric Berne talks about what he calls "crossed transactions."
In each of us, Berne says, there are three persons: a parent, an adult,
and a child.  Therefore any interaction between two individuals has 81
possible variations if we consider all the hidden agendas.  The left
figure shows the best kind of open transaction, of adult talking to
adult while the right figure shows the worst: what Berne calls a
"crossed transaction."

In useful transaction, both parties talk to each other, adult-to-adult,
without the interfering hidden agendas of either's internal parent or
child.  In the crossed transaction they talk at each other.  The
traditional QA type, who I call Mr.  Q.A.  Widget, says:

"Why can't you software types adopt proper methodology and quality
assurance methods, such as statistical quality control, in your work?"

An adult-to-child transaction.  The hidden assumption in Widget's
criticism is that software types are ignorant, that they don't know that
methodology and quality are important, or that there is such a thing as
statistical quality control.  The software engineer is no better,
because she counters:

"You boob! You don't even begin to understand the issues.  Your notion
of software is something a high-school kid knocks off in Basic in a few
hours.  And your notions of 'proper' engineering methods don't apply to

They're crossed transactions.  Conversation must be adult-to-adult in
both directions before communication is possible.  We must see where
each party is coming from as a step in achieving that objective.  Widget
QA is rooted in traditional engineering disciplines: old, and for civil
engineering, ancient traditions.  Ancient traditions that work very
well, thank you -- for traditional engineering.  The underlying
assumptions of traditional engineering are part of the fundamental
paradigms of Western thought.  Software engineers shouldn't blame
traditional engineers for unconsciously invoking these paradigms because
it takes much effort and brain twisting, as I'm sure most software
engineers forget, to get those restrictive ideas out of their head so
that they can write good software.

Conversely, the software engineers, who have internalized a new set of
paradigms, falsely assume that any rational person would understand
them.  They don't.  Most people just don't think digitally.  And
shouting louder doesn't get the point across any more than shouting
louder helps a non-English speaker understand English (or any other

To communicate, we must expose the fundamental assumptions on each side
and contrast them: by understanding the differences we break the crossed
transactions and engage in real adult-to-adult communications.  That's
what this essay is about.

2.2.  Physical Constraints

Whether or not we are physicists, we have an intuitive understanding of
the physical world.  Apples, when released fall down, not up.  Actions
are causally related to consequences.  We expect things to behave
sensibly.  Our intuitive notion of what is "sensible" is based on
common-sense experiences learned in childhood, and rooted in the
physical world.  The software world is neither physical nor constrained
by physical laws.  It is closer to the psychic world of human behavior
than to the physical world.  Think of how long it takes to get insights
into how people behave: most of us take a lifetime at the attempt and
usually don't succeed.

The corollary to assuming that software should behave like physical
things is the contradictory notion that software is easy to build and
easier to change.  Here's the syllogistic logic of this unproductive

   1. If software were decent, it would behave like physical systems and
      obey physical laws.

   2. Software doesn't behave like physical things.  It isn't even
      physical.  Therefore, it's indecent.

   3. Poured concrete and rolled steel (physical things) are hard to

   4. Software is easy to build.  Any high school kid who knows Basic
      can do it.

   5. Therefore, software is easy to change.

The hardest things to change in this world are people's heads -- the way
they think.  Fifty centuries of religious warfare has taught us that.
When such thoughts are encapsulated into text, say in the form of
programs and documentation, they become even harder to change.  Which is
tougher to change: a poured concrete foundation that's wrongly sized or
the head of the engineer who sized it? You know the answer: you won't
change his head until he sees the wrecking ball taking his mistake apart
-- and even then you might not succeed.  Changing software doesn't
merely mean changing a few lines of code.  Before that can happen you
must change things in a programmer's head.  Contemporary software isn't
the work of one programmer but of dozens and hundreds:  all of their
heads must be changed before that code can change.  The physical world
is easy to change by comparison: an enthusiastic guy with a bulldozer
can do that.

I hope that in the future we will understand the software world as well
as we understand the physical world.  Surely there are "laws" that are
as binding to software as physical laws are to the physical world.
There must be laws that will tell us how immutable our software is at
various stages of development just like we can predict the mutability of
concrete for any given hour after it's been poured.  But we have yet to
discover such laws.  Most of the differences between software systems
and physical systems discussed below devolve from a faulty expectation
that software follows the laws of physics.  That's the first faulty
notion to drop.

2.3.  The Principle of Locality

2.3.1.  General

In the physical world, the consequences of an action or a bug are
closely related in time, space, and severity to the cause.  I call this
"The Principle of Locality." In the software world, the consequences of
a bug are arbitrarily related in time, space, and severity to the cause.
Simple bugs in simple software often have localized impact; but as the
size and complexity of software increases, the locality principle is
increasingly violated.

2.3.2.  Space Locality

Simple bugs obey the principle of locality and are usually found and
eliminated by programmers before they start formal testing.  The
difficult bugs that survive testing and eventually plague users with
misbehavior are not like that.  If you have a problem with the
windshield wipers of your car, you don't expect it to affect the radio.
If you can't tune your radio to a station, you don't expect your right-
rear tire to blow out.  Physical systems have space locality, software
does not.  The use of constructs such as global data (to meet
performance demands) exposes software to the possibility of bugs that
don't have space locality.  The main reason that programmers encapsulate
their programs into subroutines is an attempt to promote locality.
Contemporary ideas such as object-oriented programming are also attempts
to improve locality1 .  Good programmers are, of course, aware of this
problem and good programming and testing practices consisting of
systematic unit, integration, and then system testing, are in part
dictated by the desire to catch bugs in the most local scope possible.
To understand software and how it can misbehave, we must change our
expectations and accept the fact that THE SYMPTOMS OF A BUG CAN BE
MANIFESTED ARBITRARILY FAR AWAY (in terms of functionality, location,
etc.) FROM THE CAUSE.  To have others (e.g., Q.A.  Widget, users)
understand software quality, they must understand, and more important,
accept this fundamental difference.

2.3.3.  Time Locality.

We haven't yet seen bugs that travel in time -- although it sometimes
seems that way.  In the physical world, we expect immediate consequences
to bug.  That's in keeping with our common-sense notion of causality.
The tire blows out causing the car to lurch to the right immediately.
Typically, cause and effect are closely related in time.  The physical
world does surprise us now and then when the consequences of an action
are not felt until hours, weeks, or years after the fact.  However, this
is exceptional, and when it does occur, we usually make a special note
of it.  In software, the consequences (i.e., the symptoms of a bug) are
manifested arbitrarily and unpredictably close or far in time from the
cause.  In software, this is not the exception, but the rule.  While the
symptoms of simple bugs are closely located in time to the moment at
which the faulty code is executed such bugs usually don't survive to a
working product.  When the symptoms show up mostly results from the way
the user employs the software.  Not just the general way, but the
specific (and unpredictable) sequence of actions executed by the user.

No programmer can anticipate all such scenarios: yet bug-free software
demands that they do.  Good software development practices require that
programmers execute specific tests, such as stress and synchronization
tests designed to catch such bugs.  They also use automated audit tools
to detect if any data or program items have been corrupted as a
consequence of running the program -- because it is most often corrupted
data and programs that lie in wait like time bombs with uncertain fuses.
So we must again change our expectations and accept the idea that THE

2.3.4.  Consequence Locality and Proportionality

We expect justice in the world.  "Let the punishment fit the crime," we
say.  We expect justice in our legal systems when we limit liability to
be proportional to damage.  Things wear out in the physical world.
Knives get gradually dull.  It isn't as if the knife cuts perfectly
today and tomorrow it can't cut at all.  Our tires wear out gradually,
so we gradually lose road-handling; not catastrophically and suddenly
when the tread depth falls below 4.3mm.  The intuitive notion of wear-
and-tear applies to the physical world, at least in its simplest
aspects.  Many physical situations do exhibit disproportionate severity:
a threshold is reached and the part no longer functions, resulting in
catastrophic failure: but again, these are exceptional.  Our notion of
the world is analog rather than digital, and in analog systems reactions
are generally proportional to action.  "To every action there is an
equal and opposite reaction." Ever since Newton said it, we've believed
it: not just theoretical physicists, but music teachers, taxi drivers,
users, children, and even politicians.  It isn't true for software.

Justice is not proportional in the software world.  Individual bugs do
not exhibit consequences in proportion to the error: an error in two
bytes does not produce symptoms that are twice as severe or that occur
twice as often as those produced by an error in one byte.  Furthermore,
the same bug, depending on circumstances and the specific history of
usage, can have consequences ranging from trivial to catastrophic.2
There is also no relation between the severity of the symptom and the
effort or lines of code that must be changed to correct the bug.  All
such proportionalities between bugs and symptoms do not exist for
software and, indeed, it is likely that all such proportionalities are
theoretically impossible.

To make the problem worse, a given bug may exhibit many different
symptoms and a given symptom may be caused by many different bugs.
There has never been (except for trivial software) and it is likely that
there never will be, any consistent way to map causes onto effect or
effect onto causes.  THE CONSEQUENCES OF A BUG (i.e., the symptoms) ARE

2.4.  Synergistic Bugs.

When catastrophes occur in the physical world, we want to find a cause
-- that's consistent with our common-sense notions about the world.  If
there is a design defect in a product, then someone can be found who
made an error.  If there is a manufacturing defect in a product, then a
tool is maladjusted or a person needs retraining.  The idea of personal
responsibility is one of the first things we learn as infants and
learning that is a basic step in our socialization.  And if we are
personally responsible, it follows that it is possible to fix
responsibility (i.e. blame) for all catastrophes.

Not so with software.  While the simplest unit bugs can be localized to
an error in a single routine, good unit tests find them long before the
product is fielded.  Integration bugs are more insidious and difficult:
the bugs that result from unpredictable interactions between otherwise
correct components.  For them, it is not possible to point to a specific
line of code and say "That's where the bug is!" and, therefore "The
person who wrote that line is to blame."

Most integration bugs are distributed.  Not one program location is
wrong, but several.  Furthermore, it isn't a set of distributed location
that is wrong because the individual components are correct.  The bug is
synergistic.  It is manifested only when two or more components are used
together.  There are no sure ways to test all such combinations, or even
to conceive of them.  Good testing does require a systematic approach to
finding such bugs and most can be eliminated before the software is
used: but it is inevitable that some will remain and elude the most
careful testing because it is both theoretically and practically
impossible to test all possible combinations.

Righteous programmers can do their best and bad things will still
happen.  Recognizing this possibility is a paradigmic shift, especially
for users and the legal system -- it is often impossible to blame anyone
for a bug.3

                           (To Be Continued)


                    Call For Participation: QWE2001

 International Internet & Software Quality Week EuropE 2001 (QWE2001)
                         November 12 - 16 2001
                          Brussels, BELGIUM

                    Conference Theme: Internet NOW!


QWE2001, the 19th in the continuing series of Quality Week Conferences,
is the 5th International Internet & Software Quality Week/Europe
Conference.  QWE2001 focuses on advances in software test technology,
reliability assessment, software quality processes, quality control,
risk management, software safety and reliability, and test automation as
it applies to client-server applications and WebSites.

QWE2001 papers are reviewed and selected by a distinguished
International Advisory Board made up of Industry and Academic Experts
from Europe and the United States.  The Conference is produced by
Software Research Institute.

The mission of the QWE2001 Conference is to increase awareness of the
entire spectrum of methods used to achieve internet & software quality.
QWE2001 provides technical education, in addition to  opportunities for
practical experience exchange within the software development, QA and
testing community.


The QWE2001 program consists of five days of tutorials, panels,
technical papers and workshops that focus on software quality, test
automation and new internet technology.  QWE2001 provides the Software
Testing and Web QA community with:

  o Real-World Experience from Leading Industry, Academic and Government
  o State-of-the-art Information on Software Quality & Web Quality
  o Quality Assurance and Test Involvement in the Development Process.
  o E-commerce Reliability / Assurance.
  o Case Studies, Lessons Learned and Success Stories.
  o Latests Trends and Tools.
  o Two Days of carefully chosen half-day and full-day Tutorials from
    Internationally Recognized Experts.
  o Three-Day Conference with: Technology, Internet, Process,
    Applications and Vendor Technical Presentations.
  o Two-Day Vendor Exhibitions and Demonstrations of the latest Tools.
  o Five Parallel Tracks with over 50 Presentations.


  o Full-day and half-day Tutorials
  o Proposals for, or Participation in,  Panel Discussions
  o 45- and 90-minute Presentations on any area of Quality, Testing
    and Automation, including:

    E-Commerce Reliability          Object Oriented Testing
    Application of Formal Methods   Outsourcing
    Automated Inspection Methods    Process Improvement
    Software Reliability Studies    Productivity and Quality Issues
    Client / Server Testing         Real-Time Software
    CMM/PMM Process Assessment      Test Automation Technology
    Cost / Schedule Estimation      Test Data Generation
    WebSite Monitoring              WebSite Testing
    Test Documentation Standards    Defect Tracking / Monitoring
    GUI Test Technology             Risk Management
    Test Management                 Test Planning Methods
    Integrated Test Environments    Test Policies and Standards
    Quality of Service (QoS)        New/Novel Test Methods
    WebSite Load Generation         WebSite Quality Issues


        Abstracts and Proposals Due:    30 June 2001
        Notification of Participation:  15 August 2001
        Camera Ready Materials Due:     22 September 2001
        Final Paper Length:             10-20 pages
        Powerpoint / View Graphs:       Max 15 pages (2 slides/page)


There are two steps to submitting material for review in QWE2001:

 1. Prepare your Abstract as an ASCII file, a MS Word document, in
    PostScript, or in PDF format.  Abstracts should be 1 - 2 pages long,
    with enough detail to give members of QWE2001's International
    Advisory Board an understanding of the final paper / presentation,
    including a rough outline of its contents.

    Email your submission to:  as a MIME attachment.

 2. Fill out the Speaker Data Sheet giving some essential facts about
    you and about your proposed presentation at:

    This information includes:
      o Author's Name, Title, Organization and contact information
      o Target Audience Level, Target Track and Basis of Paper
      o Three bullet/phrases describing the main points of the paper.
      o Short Abstract of the paper for publication on the WebSite
      o Brief Biographical sketch of each author (and later a photo of
        each author).
      o Lessons to be learned from this presentation.

As a backup to e-mail, you can also send material by postal mail to:

      Ms. Rita Bral,
      Software Research Institute,
      1663 Mission Street, Suite 400
      San Francisco, CA  94103  USA


                      Phone: [+1] (415) 861-2800
                      FAX:   [+1] (415) 861-9801
            WebSite: <>


                       David L. Parnas Symposium
 Special event at the International Conference on Software Engineering

                          Tuesday May 15, 2001
                            Toronto, Canada

This symposium is being held in recognition of Parnas's work and in
honor of his 60th birthday.  It is an opportunity for everyone in the
software engineering community to celebrate his contributions and to
think hard about where we are today and where we are going.

The symposium program includes:
    * keynotes by Fred Brooks and Jon Bentley
    * invited talks by Jo Atlee, Paul Clements, and Jim Waldo
    * a short presentation by Parnas
    * a panel on software engineering education

Each symposium attendee will receive a copy of the book "Software
Fundamentals: Collected Papers" by David L. Parnas, a new book from


                    6th International Conference on
            Reliable Software Technologies - Ada-Europe'2001

                    May 14-18, 2001, Leuven, Belgium


                Organized by Ada-Belgium and K.U.Leuven
        Sponsored by Ada-Europe, in cooperation with ACM SIGAda

A 16-page color brochure is available on the conference website.  Select
"Program" to either download a PDF version or to request a printed copy.

Quick overview
- Mon 14 & Fri 18: 8 full- or half-day tutorials
- Tue 15 - Thu 17: paper & vendor presentation sessions, exhibition

Program co-chairs
- Dirk Craeynest, Offis nv/sa & K.U.Leuven, Belgium,
- Alfred Strohmeier, Swiss Federal Institute of Technology
  in Lausanne (EPFL), Switzerland,

Invited speakers
- Building formal requirement models for reliable software
  Axel van Lamsweerde, Universiti Catholique de Louvain, Belgium
- Using Ada in interactive digital television systems
  Pascal Hiraud, CANAL+ Technologies, France
- Testing from formal specifications, a generic approach
  Marie-Claude Gaudel, Universiti de Paris-Sud, France
- Logic versus Magic in critical systems
  Peter Amey, Praxis Critical Systems, UK
- Can Java meet its real-time deadlines?
  Brian Dobbing, Praxis Critical Systems, UK,
  co-author Ben Brosgol, ACT, USA

- Art Duncan: "Non-standard techniques in Ada" (full day)
- Peter Amey & Rod Chapman: "Practical experiences of safety-critical
  Ada technologies" (full day)
- Jeff Tian: "Early reliability measurement and improvement" (half day)
- Gregory Neven, Maarten Coene & Roel Addriaensens: "An introduction to
  XML" (half day)
- John Harbaugh: "From full concurrency to safe concurrency" (full day)
- Samuel Tardieu, Laurent Pautet & Thomas Quinot: "Building distributed
  systems with Ada" (full day)
- Matthew Heaney: "Implementing design patterns in Ada: sequential
  programming idioms" (half day)
- Bruce Lewis & Ed Colbert: "Architecture centred development and
  evolution of reliable real-time systems" (half day)

- 32 papers on Formal Methods, Testing, High-Integrity Systems, Program
  Analysis, Distributed Systems, Real-Time Systems, Language and
  Patterns, Dependable Systems, APIs and Components, Real-Time Kernels,
  Standard Formats: UML & XML, System Evolution, and Software Process
- authors from Australia, Belgium, China, France, Germany, Israel,
  Portugal, Russia, Spain, Sweden, Switzerland, United Kingdom, USA

- 8 exhibitors already committed: ACT Europe, Aonix, DDC-I, Irvine
  Compiler, Praxis Critical Systems, Rational Software, TNI-Europe and
  Top Graph'X, others expressed interest
- separate vendor presentation tracks for exhibitors

Social evening events
- Mon: welcome reception with Belgian beers
- Tue: guided tour of historic town hall followed by civic reception
- Wed: guided historic walk followed by conference banquet at Faculty
       Club in Groot Begijnhof
- Thu: visit to Stella Artois brewery followed by tasting session

- includes copy of full proceedings, published by Springer-Verlag in
  Lecture Notes in Computer Science series (LNCS)
- early registration DISCOUNT up to SUNDAY, APRIL 22, 2001
- discount for academia, Ada-Europe and ACM members

- conference registration form (small PDF file):
- hotel reservation form (small web page):
- preliminary program (large PDF file, contains all information and forms):

For more info, latest updates, or to get printed brochures, see the
conference web site at
or contact Dirk Craeynest mailto:

Dirk Craeynest, Ada-Europe'2001 Program Co-Chair


                            SERG REPORT 392
               Modelling Object Oriented Non-Sequential
                     Systems by Coloured Petri Nets
                               By: Lin He

Abstract: Object Oriented Coloured Petri Nets (OO-CPN) formalism has
been introduced. The formalism is based on Kurt Jensen's Hierarchical
Coloured Petri Nets and supports the concepts of object, class and

                            SERG REPORT 393
         Remarks on Mereology of Direct Products and Relations
                          By: Ryszard Janicki

Abstract: The concept of being a "part of" for direct products and
relations is analysed. Some operations based on this concept are
introduced and analysed.

      ------------>>> QTN ARTICLE SUBMITTAL POLICY <<<------------

QTN is E-mailed around the middle of each month to over 9000 subscribers
worldwide.  To have your event listed in an upcoming issue E-mail a
complete description and full details of your Call for Papers or Call
for Participation to .

QTN's submittal policy is:

o Submission deadlines indicated in "Calls for Papers" should provide at
  least a 1-month lead time from the QTN issue date.  For example,
  submission deadlines for "Calls for Papers" in the March issue of QTN
  On-Line should be for April and beyond.
o Length of submitted non-calendar items should not exceed 350 lines
  (about four pages).  Longer articles are OK but may be serialized.
o Length of submitted calendar items should not exceed 60 lines.
o Publication of submitted items is determined by Software Research,
  Inc., and may be edited for style and content as necessary.

DISCLAIMER:  Articles and items appearing in QTN represent the opinions
of their authors or submitters; QTN disclaims any responsibility for
their content.

STW/Regression, STW/Coverage, STW/Advisor, TCAT, and the SR logo are
trademarks or registered trademarks of Software Research, Inc. All other
systems are either trademarks or registered trademarks of their
respective companies.

          -------->>> QTN SUBSCRIPTION INFORMATION <<<--------

To SUBSCRIBE to QTN, to UNSUBSCRIBE a current subscription, to CHANGE an
address (an UNSUBSCRIBE and a SUBSCRIBE combined) please use the
convenient Subscribe/Unsubscribe facility at:


As a backup you may send Email direct to  as follows:

   TO SUBSCRIBE: Include this phrase in the body of your message:

   TO UNSUBSCRIBE: Include this phrase in the body of your message:

Please, when using either method to subscribe or unsubscribe, type the
 exactly and completely.  Requests to unsubscribe that do
not match an email address on the subscriber list are ignored.

               Software Research, Inc.
               1663 Mission Street, Suite 400
               San Francisco, CA  94103  USA

               Phone:     +1 (415) 861-2801
               Toll Free: +1 (800) 942-SOFT (USA Only)
               FAX:       +1 (415) 861-9801
               eteb:       <>