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,
Inc.
========================================================================
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
<http://www.qualityweek.com/QW2001/>
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:
<http://www.qualityweek.com/QW2001/brochure.phtml>
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
Practice"
> 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
field.
> 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.
SPECIAL EVENTS:
> 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:
<http://www.qualityweek.com/QW2001/>
========================================================================
eValid Ver. 2.2 New Feature Summary
This note summarizes new features in eValid Ver. 2.2. A complete
description can be found at:
<http://www.soft.com/eValid/Products/Documentation.22/release.2.2.html>
* 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:
DEMO:
EVAL/Full:
* 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:
<http://www.soft.com/eValid/Products/pricelist.22.html>
========================================================================
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, remartin@uci.edu
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
systems.
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:
<http://www.isr.uci.edu/directions.html>
========================================================================
Software Is Different (Part 1 of 3)
by
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
software!"
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
language).
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
thinking:
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
change.
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
SYMPTOMS OF A BUG CAN BE MANIFESTED ARBITRARILY LONG AFTER THE EXECUTION
OF THE FAULTY CODE.
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
ARBITRARILY RELATED TO THE CAUSE.
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!
<http://www.soft.com/QualWeek/QWE2001>
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.
QWE2001 OFFERS:
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
Technologists.
o State-of-the-art Information on Software Quality & Web Quality
Methods.
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.
QWE2001 IS SOLICITING:
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
IMPORTANT DATES:
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)
SUBMISSION INFORMATION:
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:
<http://www.soft.com/QWE2001/speaker.data.html>
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
SR/INSTITUTE, 1663 MISSION STREET, STITE 400, SAN FRANCISCO, CA 94103 USA
Phone: [+1] (415) 861-2800
FAX: [+1] (415) 861-9801
Email: qw@soft.com
WebSite: <http://www.soft.com/QualWeek/QWE2001>
========================================================================
David L. Parnas Symposium
Special event at the International Conference on Software Engineering
Tuesday May 15, 2001
Toronto, Canada
<http://www.csr.uvic.ca/icse2001/special.html>
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
Addison-Wesley.
========================================================================
6th International Conference on
Reliable Software Technologies - Ada-Europe'2001
May 14-18, 2001, Leuven, Belgium
<http://www.ada-europe.org/conference2001.html>
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,
Dirk.Craeynest@cs.kuleuven.ac.be
- Alfred Strohmeier, Swiss Federal Institute of Technology
in Lausanne (EPFL), Switzerland, Alfred.Strohmeier@epfl.ch
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
Tutorials
- 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)
Papers
- 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
Exhibition
- 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
Registration
- 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
URLs
- conference registration form (small PDF file):
http://www.cs.kuleuven.ac.be/conference/AE2001/registration/registration.pdf
- hotel reservation form (small web page):
http://www.omnia.be/Holidays/Travelagents/agri/kongressen/kongressen_e.cfm
- preliminary program (large PDF file, contains all information and forms):
http://www.cs.kuleuven.ac.be/conference/AE2001/program/program.pdf
For more info, latest updates, or to get printed brochures, see the
conference web site at http://www.ada-europe.org/conference2001.html
or contact Dirk Craeynest mailto: Dirk.Craeynest@cs.kuleuven.ac.be
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
inheritance.
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.
TRADEMARKS: eValid, STW, TestWorks, CAPBAK, SMARTS, EXDIFF,
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:
<http://www.soft.com/News/QTN-Online/subscribe.html>.
As a backup you may send Email direct to as follows:
TO SUBSCRIBE: Include this phrase in the body of your message:
subscribe
TO UNSUBSCRIBE: Include this phrase in the body of your message:
unsubscribe
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.
QUALITY TECHNIQUES NEWSLETTER
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
Email: qtn@soft.com
eteb: <http://www.soft.com/News/QTN-Online>