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
+===================================================+
+======= Testing Techniques Newsletter (TTN) =======+
+======= ON-LINE EDITION =======+
+======= October 1999 =======+
+===================================================+
TESTING TECHNIQUES NEWSLETTER (TTN), Online Edition, is E-mailed monthly
to support the Software Research, Inc. (SR)/TestWorks user community and
to provide information of general use to the worldwide software quality
and testing community.
Permission to copy and/or re-distribute is granted, and secondary
circulation is encouraged by recipients of TTN-Online provided that the
entire document/file is kept intact and this complete copyright notice
appears with it in all copies. (c) Copyright 2003 by Software Research,
Inc.
========================================================================
INSIDE THIS ISSUE:
o Quality Week Europe 1999 -- Final Two Weeks, Special Events
Described
o Effective Beta Testing, by Michael Bolton
o DSVV'2000: Call for Participation
o TestWorks Corner: CAPBAK/Web Builds, New QuickLook eValid Test
Service, More!
o Y2K Dates on Windows: Readers Respond...
o Correction: Found that URL...
o Ada-Belgium '99: Call for Participation
o "Testing Object-Oriented Systems: Model, Patterns, and Tools"
Released
o ICS Distinguished Speaker Series: Human-Competitive Machine
Intelligence by Means of Genetic Programming, by John Koza
o Third Grace Hopper Celebration, Cape Cod, Massachusetts, September
14-16, 2000
o SERG Report #380 & #381
o TTN SUBMITTAL, SUBSCRIPTION INFORMATION
========================================================================
3rd International Software & Web Quality Week Europe '99
1-5 November 1999 * The Sheraton Brussels * Brussels, Belgium
ONLY TWO WEEKS LEFT!
There are only two weeks left to register and take advantage of this
premier conference dedicated to software and web quality. Every
software and web professional will appreciate QWE'99's strong technical
program with 40 published technical papers and 80 presentations that
will respectively compete in the exciting race for The Gitek QWE'99 Best
Paper Award and The Qualityhouse QWE'99 Best Presentation Award.
- The GITEK QWE'99 Best Paper Award -
Finalists for this award will be selected by the esteemed QWE'99
Advisory Board. Gitek will make the final decision, recognizing the
exceptional skills and insight of the chosen author(s).
- The QUALITYHOUSE QWE'99 Best Presentation Award -
This award will be chosen by you as a QWE'99 attendee and presented by
Qualityhouse to the most dynamic, charismatic and professional presenter
of QWE'99.
Register now to take part in learning and choosing from the best and
brightest experts in Europe and the world!
The technical program can be found at:
<http://www.soft.com/QualWeek/QWE99/qwe99.program.html>
To Register for QWE'99, go to:
<http://www.soft.com/QW/QWE99/qwe99.register.html>
+ + + + + + + + + + + + + + + + + + + + +
SPECIAL EVENTS at Quality Week Europe '99!
As well as being the most-information packed, intensive, software
quality event around, QWE'99 is also a place where you can relax, enjoy
and have fun at Special Events!
MEET THE AUTHORS:
Purchase books written by Robert Binder, Martin Pol & Tim Koomen and
have them autographed during special book signing sessions! The Book
signings will be at the Pearson Education table during desserts at 13:15
on 3 & 4 Nov.
WELCOME RECEPTION AT THE BEGLIAN BREWERIES MUSEUM:
Sample the finest Belgian beers... On Tuesday evening, 2 November,
you'll be amicably welcomed to QWE'99. Relax, Mingle and Network with
your peers and meet others with whom you will spend the rest of the week
with sharing your experiences and knowledge. This informal event will
set the tone for your week of learning and fun!
COCKTAIL PARTY:
Mingle and Network with the Exhibitors... This party will be held on
the EXPO floor so you can talk to the vendors about their state-of-the-
art tools and services. Have a great time while you learn how their
tools can help you in *your* work. This party will be held on Wednesday
evening, 3 November.
ROYAL MUSEUM OF FINE ARTS OF BELGIUM:
Join us to enjoy the exquisite paintings of James Ensor... This event
is SOLD OUT to the general public, but QWE'99 attendees will be able to
visit this beautiful museum and enjoy the unique paintings of the famous
Belgian artist, James Ensor. Afterwards, join us for a 3-course, sit-
down dinner at a typical Brussels cafe to savor the delicious Belgian
cuisine and Belgian abbey beers. Thursday evening, 4 November.
All Special Events are included in the price of registration. Register
today!
<http://www.soft.com/QualWeek/QWE99/>
========================================================================
Effective Beta Testing
by
Michael Bolton
mb@michaelbolton.net
ABSTRACT: Many well-intentioned companies hold beta tests
for the wrong reasons, and waste months of time in the
process. Here are some practical ways of optimizing your
beta test program. As usual, taking a little extra time
early on provides huge benefits.
The outside beta test can be a very exciting stage in the software
development process. Dedicated, loyal customers who are anxious to see
your company and its products succeed eagerly download the software,
thereby exposing it to a much broader range of platforms than you can
hope to have available in your laband all for free. The marketing
department is thrilled because your product is being exposed to
privileged customers who will spread great word of mouth before your
product hits the shelves. For the product team, the release of a beta
is usually regarded as the last milestone before the retail version of
the product ships. Beta tests can, however, be laden with unfulfilled
promise and wasted cycles.
Testers don't always find defects or report them. Often you'll get a
number of beta test reports that say nothing more than "everything's
great!". Many of the defects that are reported are trivial. Some
testers, especially the better ones, report a few defects, and then are
never heard from again. A large beta test might be a useful publicity
stunt, but it's debatable that numbers alone improve the quality of the
test. Microsoft proudly announces that tens of thousands have beta
tested Office and Windows. Ever seen a defect in any of those products?
A beta test, like life itself, is like a sewer: what you get out of it
depends on what you put into it. The beta cycle can be used purely as a
marketing ploy, with little useful feedback for engineering. However, if
you prepare your product carefully, choose your testers wisely, and
provide testers with appropriate incentives, you can get useful
information from the beta. There are a few issues for which you should
prepare:
* Consider the purpose of your beta test. If your organization's
priority is solely to send out a trial balloon for the product,
prepare to spend several months debating the merits of the feedback
with the marketing department, and be ready for lots of
recriminations later on. If you want useful feedback, prepare your
product and your team carefully before the beta release.
* Each defect that an outside beta tester finds costs plenty of time to
your organization. It doesn't take many defects before that time
begins to turn into staff-months.
* It's essential to prevent the reporting of defects that are already
known inside your organization; the easiest way to do this is simply
to eliminate those defects before releasing the beta.
* The best outside beta testers cannot match the defect counts for
qualified internal testing groups and quality assurance. Make sure
that your quality assurance team has had a chance to find defects and
that your product team has resolved them if you wish to get the
greatest possible value from an outside test.
* "Beta fatigue" can set in; it's difficult to get outside beta testers
to commit their time, especially over a long program.
* Both your installation and uninstallation routines have to be rock-
solid. Otherwise, later beta versions will not be installed on clean
systems but the released product will.
* If features are missing in an early beta, they won't get the coverage
in later cycles than they might have in the early rounds.
In a well-written function, the best way to assure optimal performance
is to reduce extra work and wasted cycles inside loops. If function
takes a value, does some work, and returns exactly the same value, most
people would remove that function from the code. And yet exactly this
kind of sub-optimal performance appears when a product with plenty of
known defects is released to beta test. Consider two scenarios:
Case 0:
* It takes a developer n minutes to fix a defect that he knows about.
Case 1:
* An outside beta tester takes five minutes to test long enough to find
a given problem
* The beta tester takes two minutes to reproduce the problem.
* The beta tester takes five minutes to write up the report.
* The Beta Test Coordinator (BTC), QA person, or program manager takes
three minutes to read the report and to consider whether the defect
has been reported before.
* The BTC takes three minutes to enter the defect into the defect
tracking system.
* It takes three minutes for a developer to read the report and
recognize that he knew about the problem already and otherwise
process the report.
* The developer takes n minutes to fix the defect (which he already
knew about, remember?).
* Having fixed the defect, the developer takes two minutes to note the
problem fixed in the defect tracking system.
* The QA person takes two minutes to read the report, in preparation to
verify that the problem is fixed.
* The QA person takes three minutes to set up, retest and to verify
that the problem is fixed.
* The QA person takes two minutes to check the report off as fixed in
the defect tracking system.
* The BTC takes two minutes to write a note to the original beta
tester, asking to verify that the problem is fixed.
* The beta tester takes five minutes to retest the problem and to
verify that the problem is fixed.
* The beta tester takes three minutes to prepare a message to the BTC
confirming the fix.
* The BTC takes two minutes to mark the report as close in the defect
tracking system.
I would consider most of these time estimates to be hopelessly
optimistic in general, although the estimate for each step might be
reasonable in a best-case scenario. I haven't included the time
associated with processing the same report from two or more different
testers. Moreover, I have not included any wait-states in this
breakdown; there's going to be considerable lag time between the time
the tester submits his report and the time that the BTC enters the
report in the defect tracker, for instance. Turnaround times of a day
are easy to imagine at several of the steps described above.
But even ignoring all those factors, look at the difference between
scenarios! In the first case, the developer fixes the known problem
before the beta, which takes n minutes. In the second case, a whole
bunch of other people get involved pointlessly, and that costs n plus 42
minutes, according to my highly optimistic assessment. Multiply that by
a thousand defect reports -- which would not be uncommon for beta test
programs that I have observed -- and you've got 42,000 staff minutes.
That translates to 700 staff hours or 17 staff weeks of wasted time.
Or, to put it another way, you're wasting four people's time for a month
for every thousand reports all to get to exactly the same place you
would have been had the beta shipped without the known, fixable defects.
And that's just the wasted time never mind the time that the product
team needs to do the rest of their jobs. While developers, QA people,
and outside testers are distracting themselves with the known defects,
the unknown ones still lurk.
If the process above were rendered as a program function in C, most
developers would have no problem in identifying the wasted cycles, and
immediately would optimize out the unnecessary steps. Why not do in
real life what you'd do in a few minutes in front of a debugger?
The most important optimization by far is to eliminate defects as early
as possible in the development process. Most people consider fixing
defects to be unpleasant; it's a lot more fun and a lot more exciting to
add features. However, it's a much better use of time to address
problems while they're fresh in your mind, and before the problems
become embedded in the program's source. That means subjecting the
requirements, the functional specification, and the source itself to
review, with the goal of eliminating defects before they start to waste
cycles. Many people equate defects with programming errors. However, to
paraphrase Gerald Weinberg, a program that has a lousy design but no
programming errors is still a lousy program.
The most important person in the program's design is the person who is
going to use it. Make sure that the program follows the user's task,
rather making the user follow the programmers' functions and procedures.
Forestall the first wave of beta test reports in most betas, you'll get
plenty of suggestions on how to improve the user interface or the
feature set of the program by being highly conscious of the user during
the design process, by reviewing functional specifications and
prototypes carefully, and by performing usability testing on your
product long before the beta ships. Programmers are sometimes resistant
to participating in code review. Usually the problem relates to ego and
insecurity; sometimes additional resistance comes from bad experience.
However, review is used by all other forms of engineering. No-one would
consider working alone to build a bridge, and no engineering company
would permit it. Development managers should make sure that the reviews
are conducted by the development team with the goal of finding defects,
not with finding fault. Code review is also a very inexpensive way to
for developers to teach and to learn. If a developer is absolutely
certain that his code is robust and free from defects, he is probably
wrong; but in any case, you can leverage his pride to suggest that he
teach his defect prevention techniques to other developers.
Automated tools, such as Lint and BoundsChecker can find subtle
problems, improving quality while saving enormous amounts of time.
Remember also that testing alone tells you neither about the cause of
the problem nor where to find it in the code. Unless you choose to look
for it, a defect such as a null pointer or a memory leak can easily lie
submerged until the product ships to paying customers.
A product's installation program is often written by a junior programmer
with relatively little supervision. However, the installation program is
critical to assuring a good beta test. If a program cannot be installed
at all, you will lose an entire beta cycle for each tester affected by
the problem. If the product seems to install correctly but leaves out
something crucial, testers will report problems that don't really exist
in the core product, netting you nothing but red herrings and
unnecessary work. Finally, if the product doesn't uninstall correctly,
later beta cycles may fail to identify problems with missing files or
configuration settings those items will be left on the tester's platform
from the previous cycle. For this reason, the installation program
should be reviewed by senior developers and checked carefully against
the product's specifications another good way for experienced
programmers to bring the junior ones along.
Several studies have shown that outside beta testers are dramatically
less effective than internal QA staff. There are several reasons for
this: QA staff have experience with the product, and often have access
to the developers. Good management and a good test plan mean that QA
tests more methodically and thoroughly than any outsider could; an
outsider usually cannot hope to have the preparation or the discipline
that a well-managed QA team can. Outside beta testers might not provide
the kind of clarity or consistency that you expect from your own staff.
Finally, there's a motivational issue. Your QA department is being paid
to test your software; outside testers are typically volunteers.
There are a few obvious ways to improve on this. The first is to qualify
your outside testers, and to continue to monitor the quantity and
quality of problem reports that you receive. If you find that a tester
is costing time by returning inadequate reports, drop him from the
program. Due to the high cost of processing a report, the quality of
beta testers is generally more important than the quantity. Second,
prepare your testers; provide them with instructions and tools to help
make their reports detailed, consistent, and efficient. Get detailed
data on their test platforms once; assign that system an identifier, and
make sure that the tester includes the identifier in defect reports.
Give your testers clear instructions on testing goals and the areas of
the product that you expect them to inspect. If you are aware of any
serious problems, note them carefully and clearly. Don't send a product
whose feature set is not complete; first you'll get remarks on the
missing features, and second, after you add the feature, it will receive
less testing coverage than the rest of the product. On later rounds of
the test, use your problem tracking tool to generate a report that
indicates clearly which problems have been fixed.
Provide incentives to your testers for producing plenty of clear
reports. A free copy of the released software is fine as a courtesy to
all of the testers, but it's not likely to be an inducement towards
spending several hours on serious testing and clear reporting, which is
what you're looking for. Consider substantial monetary awards for the
top three providers of useful reports. You should be able to demonstrate
easily a good business case for doing this. Current studies suggest that
a single technical support call costs a minimum of $20; finding a single
defect that generates five calls is worth $100.
Most importantly, remember that you waste your testers' time and your
own by releasing beta products without finding and resolving all of the
clear, obvious defects first. Beta testers want to find and report
defects; if you make defects too easy to find, they'll simply find and
report the easy ones. If your product has defects that can be resolved,
don't stick to the beta release date just to say that you made it;
you'll cause far more work for your product team almost immediately.
Check the business case: it's usually worth delaying your beta release
for a few days or even weeks, since each known defect that generates a
report has a high probability of taking an hour or more of staff time
away from your organization.
A beta test can give you valuable feedback and the assurance that your
product works on a wide variety of platforms. By releasing a product
that is truly ready for the test, and by preparing your testers
properly, you can make sure that the positive feedback does not cost you
unnecessary time and effort, and helps to improve the quality of your
product.
Michael Bolton is an independent consultant specializing in
program and process management, testing, and technical
support issues. He can be reached on the Web at
<http://www.michaelbolton.net>; via email at
mb@michaelbolton.net; or the old-fashioned way at +1 (310)
477-5677.
========================================================================
International Workshop on
"DISTRIBUTED SYSTEM VALIDATION and VERIFICATION"
(DSVV'2000)
Third Call For Papers
http://www.iis.sinica.edu.tw/~eric/icdcs2k-dsvv/
(Proceedings to be published by IEEE Computer Society Press)
An International Workshop held in conjunction with
the 20th IEEE International Conference on Distributed Computing Systems
(ICDCS'2000)
April 10-13, 2000, Taipei, Taiwan, ROC
Distributed systems have parts located in more than one location and
distributed applications need to work coherently within such a system to
be feasible. Such systems and applications are difficult to validate and
verify. The DSVV'2000 workshop will try to assimilate all related
techniques, either formal or technical, which contribute towards proving
systems valid. Formal methods include queuing theory, analytic methods,
model-checking, process algebra, theorem proving, term rewriting, and
other logic-related techniques. Technical methods include different
simulation models, testing, emulation, virtual prototyping, rapid
prototyping, and other ad-hoc techniques.
In today's world of wireless and mobile networking, distributed system
protocols form a major aspect of system design. Verifying such protocols
is usually a formidable task. DSVV'2000 will try to uncover and
integrate existing techniques and introduce new ones for distributed
system protocol verification.
When both hardware and software are present in distributed systems,
system validation and verification become all the more complex and
challenging. Hardware-software timing co-verification of distributed
embedded systems is also currently a hot topic, which DSVV'2000 will try
to emphasize on.
All topics related to distributed system validation and verification are
invited. Topics of interest include, but are not limited to, the
following:
* Specification/Modeling Techniques * Formal Methods
* Simulation Techniques * Industrial Techniques
* Testing Techniques * Case Studies
* Verification Techniques * IP / Virtual Components
* Validation Tools * Embedded Systems
* Verification Tools * Hardware-Software Co-verification
WORKSHOP ORGANIZER:
Dr. Pao-Ann Hsiung
Institute of Information Science
Academia Sinica
No. 128, Sec. 2, Academic Road
Nankang, Taipei 115, TAIWAN, R.O.C.
For further detailed information on ICDCS'2000, please refer to the
conference home page: http://www.cis.ohio-state.edu/~icdcs20/.
========================================================================
TestWorks Corner: News Items for TestWorks Users
TestWorks products support client/server, embedded system, and website
testing and quality assurance activities. eValid Test Services are
based on application of TestWorks product to websites. Here are items
that will be of interest to current and prospective TestWorks users.
o CAPBAK/Web technology is applied to websites in our eValid(tm) brand
name test services offering. If you are a website manager and wish
to have complete assurance about the quality, content, response time,
and operational status of your website you may want to subscribe to
eValid services. A summary (and links to individual services) is
available at:
<http://www.soft.com/Products/Web/eValid/evalid.summary.html>
You may also request FREE QuickLook test services -- representing a
sampler of the full eValid test service offerings -- by going to:
<http://www.soft.com/Products/Web/eValid/evalid.quicklook.html>
That page will take you to the eValid QuickLook application form at:
<http://www.soft.com/Products/Web/eValid/evalid.apply.quicklook.html>
o The latest build (14 October 1999) of our new CAPBAK/Web capture
replay system is now available for evaluation. You can do the
download from:
<http://www.soft.com/Products/Downloads>.
Complete information about CAPBAK/Web is found at:
<http://www.soft.com/Products/Web/CAPBAK/capbakweb.html>.
There is an introductory "Frequently Asked Questions" about
CAPBAK/Web and WebSite testing at:
<http://www.soft.com/Products/Web/CAPBAK/faq.html>.
o If you would like to be added to the regular TestWorks Software
Installation List (SIL) mailing please make your request to
and be sure to include complete company and contact
information.
o We are offering potential CAPBAK/Web customers a free "2-Deep
TestSuite" for a specified URL to help them get started. The 2-deep
suite gives you a SMARTS "ats file" and a set of CAPBAK/Web "keysave
files" that fully exercise two layers of your WebSite. Make your
request at:
<http://www.soft.com/Products/Web/CAPBAK/2deep.request.html>
o "WebSite Testing" White Paper. If you are working with testing of
websites you may want to read this white paper by Edward Miller. It
outlines basic requirements of WebSite testing and gives a brief
summary of how CAPBAK/Web and SMARTS can be used to meet most of the
requirements for deep WebSite testing. You can find the White Paper
at:
<http://www.soft.com/Products/Web/Technology/website.testing.html>
Complete information about TestWorks can be obtained by Emailing
.
========================================================================
Y2K Dates on Windows: Responses
Editors Note: We had an inkling that the item in last
month's TTN-Online about dates on Windows was a bit shady,
and it turns out many readers pointed this out. The more
interesting responses are included here.
+ + + + + + + + + + + + + + + + + +
From: Dorota Chelstowski
Date: Mon, 20 Sep 1999 15:21:42 -0400
Organization: Windsor Mold Inc.
Ok, I don't want to insult anyone here but, did anyone of you think
about testing these steps and how they work? The Regional Settings do
not control how your dates are Stored, they control how they are viewed.
That means, that it doesn't matter if your short date is 'yy' or 'yyyy'.
The only way that it matters is if the user is paranoid and wants to see
all his/her dates in two- digits.
The memo that the original person received was just another hoax mail
that has been going around the internet and Microsoft has tried to make
sure people don't misinterpret.
Could someone please print a correction in the next issue.
Dorota Chelstowski
Y2K Software Analyst
Windsor Mold Group
Windsor Ontario
+ + + + + + + + + + + + + + + + + +
From: "Dave & Beth Kvindlog"
Subject: Re: Is This A Genuine Y2K Fix? Opinions Invited !
Date: Mon, 20 Sep 1999 22:34:50 -0500
In response to the subject TNN article published this month, I submit
the following information cut and paste verbatim from Microsoft's web
site as a rebuttal to this blatant hoax. The fact that this was a hoax
seemed obvious when I received the same "warning" from a couple of well
intentioned but mislead friends. If anyone had actually tried to change
the date from the yyyy format to yy format, and then back to the yyyy
format, the final result should be the Windows default year and not the
entered year -- unless the date was stored as a 4 digit date (which it
is).
David Kvindlog
- - - - (start quote) - - - -
There is a hoax email in circulation on the Internet concerning the Y2K
compliance of Windows 95 and Windows 98. There are various versions of
this mail which resemble the below:
"Every copy of Windows will fail on January 1st unless you fix it now,
to fix it..."
Click on "My Computer".
Click on "Control Panel".
Click on "Regional Settings".
Click on the "Date" tab. Where it says, "Short DateSample" look
and see if it shows a "two Digit" year. Of course it does. That's
the default setting for Windows 95, 98 and NT. This date RIGHT HERE
is the date that feeds application software and WILL NOT roll-over in
the year 2000. It will roll over to 00.
Click on the button across from "Short Date Style" and select the
option that shows mm/dd/yyyy. Be sure your selection has four Y's
showing, not two.
Click "Apply" and then click on "OK" at the bottom. Easy enough
to fix. However, every single installation of Windows worldwide is
defaulted to fail Y2K rollover.
"Thanks and have a great day"
Facts about Windows 95, Windows 98 and Y2K...
Microsoft Windows 95 and Windows 98 are compliant and customers do
not have to perform the above steps to obtain compliance.
Windows will store and calculate the date as 4 digits, independent
of the date display selected by the customer.
Dates are stored and processed by Windows in a 4 digit format
regardless of the date display style selected in Regional settings.
Customers can use the regional settings tab to adjust how the date
is displayed (e.g. mm/dd/yy or mm/dd/yyyyy)
http://www.microsoft.com/y2k/hoax/y2khoax.htm
Last Updated: Friday, August 6, 1999 - 7:40 a.m. Pacific Time
"1999 Microsoft Corporation. All rights reserved.
- - - - (end quote) - - - -
+ + + + + + + + + + + + + + + + + +
From: alan.simkins@canadalife.co.uk
Date: Mon, 27 Sep 1999 13:23:04 GMT
Subject: September TTN Newsletter - Y2k Fix article.
Status: RO
Dear Sir,
I raised the matter discussed in the above article with our Y2K team.
They have pointed me to the following Microsoft Web page, which
acknowledges the information supplied in your article to be a hoax.
<http://www.microsoft.com/y2k/hoax/y2khoax.htm>
I would be grateful if you could print a reference to this article in
your next newsletter to save people worrying unduly.
Regards,
Alan Simkins
Quality Analyst
========================================================================
CORRECTION: The Theory and Practice of Stealthy Hacker Attacks
<http://www.securityfocus.com>
[snip]...
This well written piece lays out the extremely sophisticated methods
used by actual hackers to penetrate sites. [snip]...
After extensive searching of the site listed above, I was unable to
locate the article you referenced. Could you please give a more complete
URL? Thanks.
--David Askey
- - - - - - - - - - - - - - - - - - - - - - - -
From: David Brown
Subject: RE: TTN-Online -- September 1999 Issue
Date: Mon, 20 Sep 1999 14:35:37 -0700
The Theory and Practice of Stealthy Hacker Attacks
<http://www.securityfocus.com <http://www.securityfocus.com> >
Found it!!
<http://www.securityfocus.com/templates/
forum_message.html?forum=2&head=168&id=168>
Editors Note: The last section of the URL (the material after the ?'s)
left off in the September Issue of TTN-Online.
========================================================================
oce 6 Preliminary Call for Participation
A d a - B e l g i u m ' 9 9 - 9 t h A n n u a l S e m i n a r
A d a 9 5 W o r k s !
Friday, November 19, 1999 Leuven, Belgium
http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/events/local.html
Ada-Belgium is a non-profit volunteer organization whose purpose is to
promote the use in Belgium of the Ada programming language, the first
ISO standardized object-oriented language and a great language for
engineering reliable systems.
Ada offers commercial developers an ideal blend of consistency,
maturity, reliability, and performance. Ada supports the
creativity and innovation of top technical talent while providing
the discipline and engineering required for critical software
systems. No other language is as uniquely qualified for building
viable, cost-effective, long-term software solutions. It is a
choice you need to consider.
From: "Ada - The Language For A Complex World" (Ada Resource
Association)
We are pleased to announce that on Friday, November 19, 1999, Ada-
Belgium organizes its 9th Annual Seminar at the Faculty Club, Groot
Begijnhof, in Leuven.
Highlights
* Theme of Ada-Belgium'99 is "Ada 95 Works!". We will have a mix of
longer tutorial like presentations and shorter experience reports or
product presentations, given by speakers both from the s.c. Ada
vendors and the Ada users.
* Invited speaker is John Barnes. He will give two tutorial
presentations: one on the SPARK language and toolset for developing
"more correct" Ada 95 programs, and one on how to use some of the
advanced new features in Ada 95.
* Free Ada-related material will be distributed, a.o. the new Walnut
Creek Ada and Software Engineering double CD-ROM set (the October
1999 release is a special edition for SIGAda'99 and Ada-Belgium'99).
* All presentations are in English. Everyone interested is welcome.
Presentations
Tutorial: "An Overview of SPARK" (1h00)
John Barnes, JBI, U.K.
The SPARK language consists of a subset of Ada 95 with embedded
annotations in the form of Ada comments. One of the keys to
developing correct software is using appropriate abstractions. This
presentation will show how the SPARK language and its associated
tools improve the completeness and correctness of abstractions and
thus lead to Ada programs which are more likely to be correct.
Tutorial: "Advanced Ada 95" (1h30)
John Barnes, JBI, U.K.
Ada 95 contains many advanced features which give the programmer
greater control over various aspects of programs. Examples are the
ability to define storage pools, to manipulate exception occurrences,
to handle streams, and to control visibility. This presentation will
discuss a number of such topics illustrated by examples.
Tutorial: "Building Frameworks in Ada 95" (1h00)
Ehud Lamm, Instructor, The Open University, Israel
One major vehicle for reuse is the use of libraries of code. Many
libraries attempt to provide common data structures and algorithms
(e.g., trees and sorting), and this seems to be the focus of the 'Ada
Standard Component Library WG' (see http://www.suffix.com/Ada/SCL/)
in which I take part. Another type of libraries consists of
frameworks. We will informally define as a framework a canned
application structure, which the programmer augments with specific
functionality. An Ada 95 framework can be built as a class-
hierarchy, a generic package, and in several other ways. Our aim is
to encourage application frameworks sharing, this being a high level
form of reuse, and to explore the various possibilities and pitfalls,
in using the various Ada 95 features.
Example code will include file processing frameworks, output
generation (possibly HTML) etc. The work presented is work in
progress, code examples will be shown and discussed. Major Ada (and
Ada 95) features explored: Generics, access-to-subprogram parameters,
tagged types, Ada.Finalization.
Experience Report: "Ada activities at Aircraft Development and Systems
Engineering (ADSE)" (0h25)
Kees de Lezenne Coulander, ADSE, the Netherlands
ADSE has developed a number of programs to support the aircraft
design activities. These are general engineering programs on
subjects like engine performance, aircraft performance and anti-icing
systems. All of these programs are in Ada 95. Development is done
using the GNAT compiler on OS/2. The finished executables also run
on DOS or Windows with the use of suitable DOS extenders. The
programs are used in-house and also at customer sites.
The choice of Ada is based on the good support for general software
engineering principles, reliability, and in particular the stability
of the language under hectic circumstances. Over time a large pool
of reusable components has been developed, so that new programs can
be fielded relatively quickly.
Technical Presentation: "Ada 95 for Real Time Applications" (0h20)
Pierre Morere, Aonix France, France
Technical Presentation: "The Use of CORBA with Ada 95" (0h25)
Jean-Claude Mahieux, Top-Graph'X, France
Technical Vendor Presentation: "Teleuse/Ada UIMS" (0h20)
Patricia Langle, Aonix France, France
Technical Vendor Presentation: "GTKAda GUI and GUI builder technology" (0h25)
TBD, ACT Europe, France
Technical Vendor Presentation: "Rational's Ada-related tools" (0h25)
Jean-Luc Adda, Rational Software Corporation, France
Seminar Secretariat
Ada-Belgium'99 Seminar Secretariat
Attn. Prof. K. De Vlaminck
c/o Department of Computer Science
Katholieke Universiteit Leuven (K.U.Leuven)
Celestijnenlaan 200A, B-3001 Leuven (Heverlee)
Phone: +32-(0)16-32.70.58 or 32.76.32
Fax: +32-(0)16-32.79.96
E-mail: ada-belgium-board@cs.kuleuven.ac.be
WWW: http://www.cs.kuleuven.ac.be/~dirk/ada-belgium/
========================================================================
"Testing Object-Oriented Systems: Model, Patterns, and Tools" Now Available
by Robert Binder
"Testing Object-Oriented Systems: Model, Patterns, and Tools" is finally
complete. This book is a comprehensive guide to designing and
implementing test suites for object-oriented software (ISBN 0-201-
80938-9, 1286 pages, hardcover.)
He has uploaded a list of chapters, the complete table of contents, and
lists of all the patterns to http://www.rbsc.com/TOOSMPT.htm.
Addison-Wesley or Amazon.com will take orders now and begin shipping in
November. Follow the link to amazon.com on the TOOSMPT page or visit
http://cseng.awl.com/ and search on the ISBN. AW plans to have copies
available at OOPSLA (1st week in November.)
Robert Binder will be giving the keynote at Quality Week Europe
(Brussels Nov 1-5) http://www.soft.com/QualWeek/QWE99/qwe99.program.html
and hopes to have a book signing event there.
------------------------------------------------------------------
Bob Binder http://www.rbsc.com RBSC Corporation
312 214-3280 tel Software Engineering 3 First National Plaza
312 214-3110 fax Process Improvement Suite 1400
rbinder@rbsc.com Chicago, IL 60602-4205
-------------------------------------------------------------------
========================================================================
ICS Distinguished Speaker Series
Wednesday, October 20, 1999
McDonnell Douglas Engineering Auditorium
10:30 Light Refreshments
11:00 Talk Begins
www.ics.uci.edu/~chair/dss.html
John Koza
Stanford University
"Human-Competitive Machine Intelligence by Means of Genetic Programming"
Genetic programming is an automatic programming technique that creates a
computer program to solve a problem. Starting with a primordial ooze of
thousands of randomly created chromosomes, a population of computer
programs is progressively evolved over a series of generations. The
evolutionary search uses the Darwinian principle of survival of the
fittest and is patterned after naturally occurring operations, including
crossover (sexual recombination), mutation, gene duplication, gene
deletion, and operations for the development of embryos.
There are now over two dozen instances where genetic programming has
produced a result that is competitive with a human-produced result. When
we talk about competitive with human performance, we mean that the
machine- created result infringes on a previously patented invention,
duplicates the functionality of a previously patented invention, equals
or exceeds a result that was accepted as a new scientific result in a
peer-reviewed publication, or is publishable in its own right (i.e.,
independent of the fact that it was produced by an automated method).
The human-competitive results come from the fields of automatic design
of analog electrical circuits, automatic design of controllers, quantum
computing circuits, robotics, cellular automata, sorting networks, and
computational molecular biology.
Eleven books and over 1,900 papers have been published on genetic
programming since l992.
Bio
John R. Koza is consulting professor in the Section of Medical
Informatics in the School of Medicine and in the Department of
Electrical Engineering in the School of Engineering at Stanford
University. At Stanford, he has taught a course on genetic algorithms
and genetic programming since 1988 and he co-teaches a course on
computational molecular biology. He is author of Genetic Programming: On
the Programming of Computers by Means of Natural Selection (1992),
Genetic Programming II: Automatic Discovery of Reusable Programs (1994),
and co-author of Genetic Programming III: Darwinian Invention and
Problem Solving (1999). He received his Ph.D. in Computer Science from
the University of Michigan under John Holland in 1972. Between 1973 and
1987, he was chief executive officer and co-founder of Scientific Games
Inc. (NYSE company).
========================================================================
C A L L F O R P A R T I C I P A T I O N
Third Grace Hopper Celebration
September 14-16, 2000
Sheraton Hotels
Cape Cod, Massachusetts
www.sdsc.edu/Hopper
The Grace Hopper Celebration of Women Conference is a technical
conference that consists of plenary speakers, technical papers, panels
and workshops by successful researchers in the area of computing. The
speakers are leaders in their respective fields, representing
industrial, academic and government communities. The theme of the Third
Grace Hopper Celebration is Interconnection, as the computing field
provides the necessary technology for interconnecting international
communities. In keeping with the theme of Interconnection, the Grace
Hopper Program is being extended to include forums on technology
innovations in addition to the papers, panels, workshops and birds of a
feather sessions.
Authors are invited to submit electronically (in ascii or postscript
formats) papers and proposals for panels, workshops and birds of a
feather sessions by the following deadline with the given length
requirements:
Email for submissions: gh2000@ece.nwu.edu
Deadline for submissions: December 15, 1999
Notification to authors: March 1, 2000
Final camera-ready copy due: April 1, 2000
Length requirements: Technical papers must be at most 5 pages including
figures and references.
Proposals for panels, workshops, birds of a feather and technology
innovation forums must be at most 2 pages.
Submissions will be evaluated based upon quality and relevance to the
field of computing; submissions beyond the required length will be
penalized in the review process. Brief descriptions of the different
types of submissions are given below.
INFORMATION FOR AUTHORS
Authors are invited to submit papers and proposals for the following:
TECHNICAL PAPERS: The goal of the technical papers is to highlight a
broad range of unique work completed in part by women
engineers and scientists in the computing field.
WORKSHOPS/PANELS: The goal of the workshops and panels is to provide
in-depth discussions on a particular topic related to
women in computing, which are lead by groups of 3-4
leaders in the field.
TECHNOLOGY FORUMS: The goal of the technology forums is to provide
opportunities for women to brainstorm about specific
technology directions and fold the results into
technology research and development.
BOFs: The goal of the BOFs is to provide an informal
discussion in a specific topic area related to women
in computing.
GENERAL INFORMATION
General organization information on the conference can be obtained by
e-mail to gh2000@ece.nwu.edu
or by accessing the Grace Hopper 2000 Conference website:
URL: http://www.sdsc.edu/Hopper
GENERAL CHAIR: Telle Whitney
Malleable Microsystems Inc.
telle@malleable.com
PROGRAM CHAIR: Valerie Taylor
Northwestern University
taylor@ece.nwu.edu
PROGRAM SUBCOMMITTEE CHAIRS:
TECHNICAL PAPERS: Sandra Johnson Baylor Tracy Camp
IBM Watson Research Center Colorado School of Mines
sandrajb@us.ibm.com tcamp@mines.edu
WORKSHOPS/PANELS: Lois Curfman McInnes Amy Pearl
Argonne National Laboratory pearl@cs.stanford.edu
curfman@mcs.anl.gov
BOFS: Lori Freitag
Argonne National Laboratory
freitag@mcs.anl.gov
TECHNOLOGY FORUMS: Kathy Richardson
Compaq Computer Corporation
kjr@pa.dec.com
Please forward this Call to all interested parties.
----------------------------------------------------------------
Valerie Taylor Northwestern Univ.
taylor@ece.nwu.edu ECE Department
Associate Professor Evanston, IL 60208-3118
http://www.ece.nwu.edu/~taylor/
========================================================================
SERG Report 380
Structured Decision Table <=>
Generalized Decision Table Conversion Tool
Tian Fu
Tabular notation is a very important part of the functional
documentation method that is used to produce computer system
specifications. Many types of tables are currently used by the Software
Engineering Research Group at McMaster University. Generalized decision
tables are one of the types. In order to facilitate the use of tabular
notation, a variety of tools were built or are being built to simplify
tables, convert between table formats, check syntax, automatically
generate test oracles, etc. Other types of decision tables are used by
industry to write software specifications. Structured decision tables
are one of the four types of tables adopted by Ontario Hydro for their
safety critical software documentation. Like the Software Engineering
Research Group, they also have tools to conduct syntax checking,
software design verification, table completeness checking, table
consistency checking, etc. The two sets of tools overlap in some areas
but not others.
Structured decision tables and generalized decision tables have
different formats and representations for expressions in the tables. One
type of table may be easier to read and have shorter expressions in some
cases than the other. In order for Ontario Hydro and the Software
Engineering Research Group to exchange specifications and utilize each
other's available tools, the structured decision table <==> generalized
decision table conversion tool project was initiated. The tool will help
to ease communication and increase collaboration between the two
parties. Based on the table holder module, the tool is developed in C
using information hiding methodology. With the tool integration
framework in mind, the tool is developed and tested independently, and
finally integrated to the TTS (Table Tool System).
****************************************************************
SERG Report 381
Use of Aliases in Tabular Expressions
Junhua Hu
Experience has shown that tabular expressions can improve the
readability of document for conditional function and relation which
frequently occur in software documentation, but tabular expressions may
still be long and hard to read when the same substructure of a
complicated data structure appears in several places in tabular
expressions. Parnas proposed the use of aliases to reduce the
complexity of tabular expressions. An alias is a short identifier that
designates a substructure or a set of substructures. Once an alias is
defined, the short identifier can be used in tabular expressions. This
thesis presents how to define aliases and how to use aliases in tabular
expressions. This thesis also shows that the use of aliases can improve
the readability of tabular expression. Tabular expressions containing
aliases can be evaluated using the Alias Table Tool and the Code
Generator. The Alias Table Tool, which works as a preprocessor of the
Code Generator, has been developed.
========================================================================
------------>>> TTN SUBMITTAL POLICY <<<------------
========================================================================
The TTN Online Edition is E-mailed around the 15th of each month to
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 "ttn@soft.com".
TTN On-Line's submittal policy is:
o Submission deadlines indicated in "Calls for Papers" should provide at
least a 1-month lead time from the TTN On-Line issue date. For
example, submission deadlines for "Calls for Papers" in the January
issue of TTN On-Line would be for February and beyond.
o Length of submitted non-calendar items should not exceed 350 lines
(about four pages). Longer articles are OK and 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 are the opinions of their authors or
submitters; TTN-Online disclaims any responsibility for their content.
TRADEMARKS: STW, TestWorks, CAPBAK, SMARTS, EXDIFF, Xdemo, Xvirtual,
Xflight, STW/Regression, STW/Coverage, STW/Advisor, TCAT, TCAT-PATH, T-
SCOPE 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.
========================================================================
----------------->>> TTN SUBSCRIPTION INFORMATION <<<-----------------
========================================================================
To SUBSCRIBE to TTN-Online, to CANCEL a current subscription, to CHANGE
an address (a CANCEL and a SUBSCRIBE combined) or to submit or propose
an article, use the convenient Subscribe/Unsubscribe facility at:
<http://www.soft.com/News/TTN-Online/subscribe.html>.
Or, send E-mail to "ttn@soft.com" as follows:
TO SUBSCRIBE: Include this phrase in the body of your message:
subscribe your-E-mail-address
TO UNSUBSCRIBE: Include this phrase in the body of your message:
unsubscribe your-E-mail-address
NOTE: Please, when subscribing or unsubscribing via email, type YOUR
email address, NOT the phrase "your-E-mail-address".
QUALITY TECHNIQUES NEWSLETTER
Software Research, Inc.
1663 Mission Street, Suite 400
San Francisco, CA 94103 USA
Phone: +1 (415) 861-2800
Toll Free: +1 (800) 942-SOFT (USA Only)
Fax: +1 (415) 861-9801
Email: qtn@soft.com
Web: <http://www.soft.com/News/QTN-Online>
## End ##