IEEE Software (September/October)

81 Pages·2002·4.718 MB·English

manager
Editor: Donald J. Reifer (cid:2) Reifer Consultants (cid:2) [email protected]
Eight Secrets of Software
Measurement
Betsy Clark
T
wenty years ago, I left the security To create an effective measurement pro-
(and frustration) of working for a gram, you first must understand exactly where
large corporation to begin a consult- you want to go or what you want to accom-
ing career in software measurement. plish; that is the “why” of measurement.
Since then, I’ve helped many firms
implement software measurement Success comes from channeling an
programs. For some clients, the motivation organization’s pain into action
for measurement was process improve- No matter how much I dislike this secret,
ment; for others, it was resolv- I have found it to be so. It comes back to the
ing an immediate crisis and get- fact that it’s not about the metrics; it’s about
ting a product out the door. In the strength of the motivation to know or
this column, I’ll share the eight improve something and to follow through
“secrets” of software measure- with action. No matter how noble the inten-
ment that I’ve learned. I call tion, “Let’s do metrics” just doesn’t provide
them secrets because they were sufficient motivation.
not obvious to me at the begin- The single biggest determinant of mea-
ning. Only in retrospect, as I’ve surement success lies in the answers to the
tried to discern patterns of suc- following questions: How badly do you
cess and failure, have these se- want to know the information, and how
crets become clear. will you use it?
It’s not about the metrics Establishing a measurement
Four-time Tour de France winner Lance program is easy; keeping it going is
Armstrong titled his autobiography It’s hard
Not About the Bike: My Journey Back to I am continually impressed by how easy it
Life (Berkeley Publishing Group, New is to think about potentially useful measures
York, 2001). Although he has spent count- and how hard it is to implement an effective
less hours on the bike, for him, it was only measurement program. Within a project or
a vehicle for his fight back from life-threat- organization, it’s often easy to get people en-
ening cancer. thused about measures—but all too often,
By the same token, measurement is not an that enthusiasm does not translate into ac-
end in itself; it’s a vehicle for highlighting ac- tion. Even when it does, it is unlikely to be
tivities and products that you, your project sustained. Getting the numbers is easy; do-
team, and your organization value so you ing something with them is not.
can reach your goals. But it’s only a tool. To What you need is no less than to change
get anywhere, you must navigate the road— your organization’s culture. Cultural change
you’ve got to make decisions and act. is hard.
12 IEEE SOFTWARE September/October 2002 0740-7459/02/$17.00 © 2002 IEEE
MANAGER
People skills matter Measuring individuals
more than quantitative can be okay
skills This is probably the most
Every step of the measure- controversial secret. Every
ment process requires input source of guidance I’ve read
from the people within the pro- on measurement advises
ject or organization who will against measuring individu-
provide and use the data. Emo- als. In conference presenta-
tion plays a strong role, espe- tions and casual conversa-
cially at the beginning, leading tion, people often repeat this
to a variety of reactions from observation. In my view,
the individuals involved. Fear there are counterproductive
that the measures will be mis- ways of measuring individu-
interpreted or misused can also als, but there are also times
lead to resistance. (We’ll ad- when it is appropriate.
dress this in more detail below.) Let’s look first at some
Positive and negative reactions counterproductive ways.
accompany any organizational Punishing people for re-
change; anticipating and man- porting honest results can
aging these are necessary. quickly destroy data in-
In my experience, at least tegrity. Organizations with
one person always steps up effective measurement pro-
as an early adopter. This per- grams do punish people
son intuitively understands who hide risks and prob-
the need for measurement lems; they don’t punish peo-
and its benefits. I make sure ple for exposing them, espe-
to find that person and work cially when they also offer
with him or her. By demonstrating ticulating a vision and following solutions. Rewarding one program-
that providing the data isn’t so hard through with consistent and persis- mer for producing more lines of code
and that it really is useful, such peo- tent action. Without these, measure- per labor hour or punishing someone
ple can bring credibility to the mea- ment won’t help. The person at the else for producing less is also inap-
surement activities. top must participate in the measure- propriate. That course ignores the
By the same token, I almost al- ment program, by fact that code quality and inherent
ways encounter someone who feels task difficulty vary.
threatened by the measurement pro- (cid:2) Articulating organizational goals In looking at intelligent uses, I’ve
gram. This person—usually a long- (cid:2) Behaving in ways that are consis- worked with clients who have imple-
term middle manager—often derives tent with these goals mented detailed progress measures
a sense of importance as the reposi- (cid:2) Creating a culture that exposes, that begin with the individual, mea-
tory of organizational knowledge. rather than hides, problems suring actual progress against a plan.
Measurement sheds light on the (cid:2) Looking at the data and asking The measures can be rolled up, lead-
organization’s basic workings; so questions ing to an overall progress assess-
much of the knowledge previously (cid:2) Making decisions and following ment, and they can be drilled down,
held in that person’s head now be- through with action to the level of teams or individuals,
comes an organizational asset acces- (cid:2) Expecting lower-level managers to supporting a detailed assessment of
sible by all. That’s good news for the do the same problem areas. Such an approach
organization but can be threatening lets managers hold individuals ac-
to the particular individual who Effective measurement will ex- countable for completing assign-
might lose status as the company’s pose an organization’s warts. To im- ments as planned. There’s nothing
resident sage. prove a situation, you must first un- negative about this.
derstand where you are. In some
Senior-level sponsorship and
ways, things might seem to get Don’t go overboard trying to
leadership are critical
worse before they get better. They be perfect
Although this one might be so ob- aren’t really worse, but you are now, Anyone who has gotten down and
vious that it really shouldn’t qualify perhaps for the first time, bringing dirty with data quickly realizes the
as a secret, it’s absolutely key and of- problems to light. Dealing with this importance of understanding what
ten neglected. Remember that it’s challenge effectively takes courage the data represent. Even seemingly
not about the metrics; it is about ar- and fortitude. straightforward data can be ambigu-
September/October 2002 IEEE SOFTWARE 13
MANAGER
ous. One of my early consulting en- between size and defects and you’ll US$340,000. Within this organiza-
gagements in capturing milestone see a very large spread—so large that tion, it makes monetary sense to min-
dates brought this point home to me. these data are typically represented imize turnover.
When I asked for the date of a design in logarithmic scales. If you can un-
review, I was asked, in turn, “Are derstand what’s behind the variation,
you asking for the date the review you’ll understand a lot.
was held or the date the customer I once had a client who was em-
I
signed off on it nine months later?” It barking on a process improvement mplementing an effective measure-
is very important to understand what initiative. They wanted to baseline ment program is full of challenges.
the data represent. where they were at the beginning to Overcoming these challenges is
By the same token, keep in mind establish a comparison point for as- worthwhile because measures pro-
that “the good is the enemy of the sessing the impact of their improve- vide insight supported by hard data.
perfect.” You must continually bal- ment activities over time. In typical Measurement provides a vehicle for
ance clarity of definition with the fashion, the relationship between size improving your ability to plan and
need to get started. In my view, it’s and effort varied across projects by track progress and for addressing
best to get started and work to an order of magnitude. They mea- risks and problems earlier. You’ll
improve the measurement process sured a number of characteristics know where you are and where you’re
over time. about each project, including the going. You still have to set the direc-
project’s percentage of personnel tion and do the steering, but measure-
Understanding the reasons turnover. In this organization, turn- ment wil be an important tool in nav-
for variability in the data over had a major impact on produc- igating the road to success.
provides a powerful decision tivity. When turnover increased from
tool 12 percent to 24 percent per year, the
One of the striking characteristics associated effort increased by 36 per- Betsy Clarkis President of Software Metrics, a Virginia-
of real data is its huge variation. cent. In dollar terms, if a project with based measurement consulting company she co-founded in
1983. She received her BA from Stanford University and PhD
Look at any graph showing the rela- low turnover costs US$250,000, then
from the University of California, Berkeley, both in cognitive
tionship between size and effort or one with high turnover would cost psychology. Contact her at [email protected].
NEW FOR 2002
the IEEE Computer & Communications Societies present
IEEE PERVASIVE COMPUTING
The exploding popularity of mobile Internet access, third-generation wireless
communication, and wearable and handheld devices have made pervasive
computing a reality. New mobile computing architectures, algorithms,
environments, support services, hardware, and applications are coming online
faster than ever. To help you keep pace, the IEEE Computer Society and IEEE
Communications Society are proud to announce IEEE Pervasive Computing.
This new quarterly magazine aims to advance mobile and ubiquitous
computing by bringing together its various disciplines, including peer-reviewed
articles on
• Hardware technologies
• Software infrastructure
• Real-world sensing and interaction
• Human–computer interaction
• Security, scalability, and privacy
Editor in Chief
M. Satyanarayanan
Carnegie Mellon Univ. and Intel Research Pittsburgh
SUBSCRIBE NOW!
Associate EICs
Roy Want, Intel Research; Tim Kindberg, HP Labs;
Deborah Estrin, UCLA; Gregory Abowd, GeorgiaTech.;
Nigel Davies, Lancaster University and Arizona University
http://computer.org/pervasive
requirements
Editor: Suzanne Robertson (cid:2) The Atlantic Systems Guild (cid:2) [email protected]
Requirements and Testing:
Seven Missing-Link Myths
Dorothy Graham
Testing expert Dorothy Graham asserts that we can save a great deal of time and money if testers
are involved in testing requirements. If the requirements have some consistent quality criteria,
testers can raise questions and find problems before we turn them into code. —Suzanne Robertson
A
strong link between testing and re- They are designing their acceptance tests. The
quirements engineering can benefit act of test design highlights what they really
both sides, but often this link is miss- want the system to do. If they had designed
ing. Let’s examine the seven most their tests early (left side of Figure 1), they
common myths or misconceptions be- could have discovered these problems before
hind this missing link. they were built into the system.
Getting users involved in both require-
Myth 1: Requirements at ments and testing is crucial. Have you ever
the beginning, testing bought a used car? Would you go to the
at the end salesperson and say, “You know more about
“We don’t need to think about cars than I do, so take the test drive for me”?
testing yet. Let’s just concentrate If you do, you deserve what you get. Simi-
on requirements.” This attitude larly, users often say to techies, “You know
guarantees that you will have a more about computers than we do, so do the
rough time at the end of your acceptance testing for us.” Caveat emptor!
project. Of course, getting good
requirements is important, but Myth 2: Testing isn’t possible until
getting testers involved during the system exists
requirements analysis is one of the best ways “We can’t do any testing because nothing
toensure good requirements. has been built yet. Testers just play with the
As Figure 1 shows, you should perform system and see what happens. Anyway, you
test design activities as soon as there is can’t test a piece of paper.” Three things are
something to design tests against—usually wrong with this sentiment.
during the requirements analysis for system First, testing is more than just seeing
and user acceptance tests. what happens. It’s far more rigorous and
A common problem, especially for testers, systematic than that. Second, it’s more than
is the impact of late changes on requirements. just executing tests. As Figure 2 shows, exe-
Suppose you’re in the last weeks of system cuting tests and checking results is part of
testing, and user acceptance tests are sched- the fundamental test process, but other im-
uled to start running in two weeks. Suddenly, portant activities exist as well. Third, you
your users say, “By the way, we’d like the sys- can and should test written requirements
tem to do this differently,” which is extremely documents against business or project objec-
frustrating and happens more often than it tives for completeness and correctness. If
should. But, what are the users really doing? you don’t test requirements on paper, you
0740-7459/02/$17.00 © 2002 IEEE September/October 2002 IEEE SOFTWARE 15
REDQEUPITR ETMITELNETS
quirements analysis benefit from having this
Test des feedback loop in place. Good requirements
Business Acceptance engineering produces better tests; good test
requirements testing analysis produces better requirements.
Test des
Project System integration
Myth 4: If writing tests is difficult,
specification testing
it’s solely a test problem
Test des
System System “The testers seem to have problems writing
specification testing tests from our requirements—maybe we should
Test des
get some better testers.” Not all requirements
Design Component
are created equal from a tester’s perspective.
specification integration testing
Test des Specifying tests for some of them is easy;
Component for others, identifying exactly what the system
Code
Design testing Run should do (and thus identifying tests to verify
tests tests that it can do these things) is a nightmare.
Specifying testable nonfunctional require-
ments such as usability or performance is
Figure 1. A V-model difficult.1 Phrases such as easy to use, user
for early test design. will build errors into the system that you friendly, very reliable, or acceptable perfor-
could have easily removed much earlier. manceare not specifications: they are vague,
ethereal intentions. I subscribe to Tom Gilb’s
Myth 3: Requirements are used in law: “Anything can be made measurable in
testing, but not vice versa a way that is superior to not measuring it at
“You don’t test requirements—you test all.”2Note that it is not made measurable in
from them.” A tester’s mindset differs from a perfect way but a useful way. Suzanne and
a developer’s. It’s fairly easy to write a re- James Robertson’s “fit criteria” show specif-
quirement that’s a bit vague and ambiguous ically how to make requirements measurable
but appears to be OK. However, when good and therefore testable.3
testers look at a requirements specification,
they devise specific test cases to flush out Myth 5: Minor changes in
vague, ambiguous, or unclear requirements. requirements won’t affect the
When you try to explain an abstract con- project (much)
cept to someone, you say “for example” and “Just add a couple more spaces to this in-
illustrate the idea with concrete and specific put field. There’s plenty of room on the
cases to clarify the concept. Tests are the “for screen. It’s a minor change; you won’t need
examples” for requirements. Think of “what to test it because it’s so small.” A change
if” use cases or business scenarios. If you con- that appears to be minor from a require-
sider how a particular user will use the sys- ments viewpoint could have a far-reaching
tem, the system functionality that seemed ab- impact, especially in testing. Suppose that
stract when first described becomes specific adding two more characters to a field means
for that particular user. Both testing and re- that the database where this field is defined
must be rearranged. What if this field corre-
sponds to similar information held else-
where in the system? What if the routines
Policy and strategies that check this field also check other fields
that you have not increased in length? Do
Test planning
you now need two checking routines?
(at each level)
You must test all such changes to confirm
P
Identify conditions Test roc that the system is now doing the right thing
Design test cases process ess in every situation affected by this change. In
Build tests imp addition, some unexpected side effects
Execute (run) tests rove could arise, so you should also do regres-
m sion testing to ensure that the system has
Check results e
n
t not regressed in any other areas. How much
Check exit criteria, test report testing you do depends on the risks of a
Figure 2. What is change having both known and unknown
“testing”? impacts on the system. Testing can also help
16 IEEE SOFTWARE September/October 2002
REDQEUPITR ETMITELNETS
mitigate the risk of change by giving confi- test plans, test specifications, and so on, the
dence that such impacts are low. testware actually becomes the only require-
ment documentation in the project. So with
Myth 6: Testers don’t really need good enough tests, who needs requirements
requirements at all? Do the testers become the require-
“I know we don’t have good require- ments engineers? Is this a good idea?
ments for this system, but test it as best you If requirements are poor or nonexistent,
can—just see what the system does.” A testers must do the best testing they can un-
tester’s job is to adjudicate between what a der less than ideal circumstances. Testing is
system does and what it should do. The sys- far more rigorous if it is based on good re-
tem should help the business accomplish a quirements, and tester involvement early on
goal, so what the system actually does can help produce them.
should be compared with those goals.
I
There is an oracle assumption in testing hope I’ve convinced you that testers have
(which has nothing to do with databases or the much to offer in producing better require-
companies that supply them—rather, it is ments. Here’s how to achieve it in practice:
based on the oracle of Delphi, who could pre-
dict the future with unerring accuracy). The or- (cid:2) Invite testers to participate in require-
acle assumption states that the tester routinely ment reviews and inspections
knows what the correct answer is supposed to (cid:2) Begin planning testing in parallel with re-
be, which is fundamental to testing. A test quirements analysis
comprises the test inputs, preconditions, and (cid:2) Ask for sample test conditions and test
expected outcomes. How do you know what cases to use as examples in the require-
the expected outcome should be? A require- ments specification
ment specification is this test basis, or oracle. (cid:2) Include in the requirements document
So, yes, testers do need requirements; other- any specific cases that you had in mind
wise, you could argue that it’s not really a test. when analyzing requirements
(cid:2) Use business scenarios and use cases to
Myth 7: Testers can’t test without give specific examples of how the system
requirements should work
“Because requirements form the basis for (cid:2) Set measurable criteria for both func-
tests, obviously we can’t do any testing un- tional and nonfunctional requirements
til we have decent requirements.” This is
also a common tester’s misconception. Testing is challenging in two ways: it’s a re-
Sometimes changes are made to systems warding intellectual activity, but it also chal-
where requirements are inadequate or lenges whatever the tests are based on. Make the
nonexistent. This makes the testing more link between requirements and testing. If you ac-
difficult, but you shouldn’t just throw your cept and encourage the challenges that testers
hands up and say that you can’t do it. make to your requirements, you will avoid these
Without requirements, testers still need misconceptions and will end up with signifi-
some kind of test oracle—maybe users who cantly better requirements and tests. Good
are familiar with the way the system works,
requirements
the old system, user manuals, or the tester’s Acknowledgments
own opinions. What happens if the test or- Thanks for comments on drafts of this article from Clive engineering
acle is the tester? Instead of merely compar- Bates, Mark Fewster, Robin Goldsmith, and Dot Tudor.
produces
ing a system against a document, the testers
are judging the system against their per- References better tests;
1. B. Lawrence, K. Weigers, and C. Ebert, “The Top Ten
sonal view of what it should do. (Actually, Risks of Requirements Engineering,” IEEE Software, good test
testers should always do some of this any- vol. 18, no. 6, Nov./Dec. 2001, pp. 62–63.
analysis
way, but that’s another story.) 2. T. Gilb, Principles of Software Engineering Manage-
ment, Addison Wesley, Boston, 1988.
Some would say that without a specifica- produces
3. S. Robertson and J. Robertson, Mastering the Require-
tion, you are not testing but merely explor- ments Process, Addison Wesley, Boston, 1999.
better
ing the system. This is formalized in the ap- 4. C. Kaner, J. Bach, and B. Pettichord, Lessons Learned in
proach known as exploratory testing, Software Testing, John Wiley & Sons, New York, 2002. requirements.
designed for situations with inadequate re-
quirements and severe time pressure.4 Dorothy Grahamfounded Grove Consultants in the UK, a company
that provides consultancy, training, and inspiration in all aspects of software
If you end up with a good set of testware, testing. Contact her at [email protected].
September/October 2002 IEEE SOFTWARE 17
design
Editor: Martin Fowler (cid:2) ThoughtWorks (cid:2) [email protected]
How .NET’s Custom
Attributes Affect Design
James Newkirk and Alexei A. Vorontsov
I
n its first release of the .NET Frame- rializable, then it must implement the inter-
work, Microsoft has provided a de- face as follows:
fined method for adding declarative in-
formation (metadata) to runtime enti- public class MyClass implements
ties in the platform. These entities in- Serializable
clude classes, methods, properties, and
instance or class variables. Using .NET, you Serialization might have certain behav-
can also add declarative information to the iors associated with it that the class devel-
assembly, which is a unit of deployment that oper wants to control. However, Java doesn’t
is conceptually similar to a .dll or .exe file. explicitly associate such behavior with the
An assembly includes attributes that de- interface that represents the serialization
scribe its identity (name, version, and cul- contract. At runtime, when the program
ture), informational attributes that provide tells the JVM to serialize this class, it looks
additional product or company informa- to see if the class has implemented the inter-
tion, manifest attributes that describe con- face. It also looks to see if the class has de-
figuration information, and strong name at- fined any special methods associated with
tributes that describe whether the assembly the serializable interface but not directly de-
is signed using public key encryption. The clared in it, such as readResolve, read-
program can retrieve this metadata at run- Object, or writeObject.
time to control how the program interacts The JVM relies on a naming convention
with services such as serialization and secu- and method signatures to locate the methods
rity. Here, we compare design decisions via reflection; if it finds them, it invokes
made using custom attributes in .NET with them. The interface itself does not specify
the Java platform. any methods, because implementors might
then unnecessarily implement methods in the
Marker interfaces simplest case. Because the interface doesn’t
In the Java platform there is a common explicitly specify the methods used to control
design trick called marker interfaces. A the process and thus might incorrectly spec-
marker interface has no methods or fields ify the method signature, this mechanism is
and serves only to identify to the Java Vir- prone to failure. Unfortunately, no compile
tual Machine (JVM) a particular class at- time check will identify this as an error.
tribute. Here is one example: .NET solves this problem by being ex-
plicit. In the simplest case, where the pro-
public interface Serializable {} grammer wants to rely on the provided ca-
pability to serialize an object, there is a
If the class that you are writing must be se- class-level attribute called Serializable
18 IEEE SOFTWARE September/October 2002 0740-7459/02/$17.00 © 2002 IEEE
DESIGN
that marks a class as having that ca- gram finds and calls
pability. For example, testSuccess. [Serializable()]
The code in Figure public class MyClass : ISerializable
[Serializable()] 2b demonstrates a {
public class MyClass {} common design id- public MyClass(
iom used in JUnit SerializationInfo info,
Marking a class serializable implies when the program- StreamingContext context)
nothing else. If the programmer mer wants to verify {
wants to completely control the seri- that the code throws // ...
alization process, then he or she must an exception. Unfor- }
also implement an interface called tunately, the pro- public void GetObjectData(
ISerializable, specifying the meth- grammer will dupli- SerializationInfo info,
ods used to control serialization (see cate such code in StreamingContext context)
Figure 1). At runtime, when the pro- every test case that {
gram tells the Common Language expects an exception, // ...
Runtime to serialize a class, the CLR and the idiom is not }
looks to see if the class was marked as intuitive as you }
with SerializableAttribute. might expect.
The Java and .NET approaches Having the testing
are similar in intent, but .NET’s use framework support Figure 1. Implementing the IISSeerriiaalliizzaabbllee
of attributes is more explicit. Con- such a common case interface, which specifies the methods for
trary to an interface’s basic purpose, directly would be controlling serialization.
the marker interface reuses an exist- nice. However, rely-
ing language construct interface to ing on the naming convention could rivative of JUnit, supports all lan-
represent what the attribute repre- lead to some variation of the code in guages in the .NET framework and
sents. According to the Java Lan- Figure 2c. In this case, we use a nam- uses attributes at the class and
guage Specification (2nd ed., Addi- ing convention to specify not only a method levels. The class attribute is
son-Wesley, 2000), test method but also additional infor- called TestFixture; it tells the pro-
mation about how to interpret the gram that runs the tests to look for
An interface declaration intro- test result. We expect that this test methods in this class. A Test at-
duces a new reference type whose method’s execution will throw MyEx- tribute then identifies test methods.
members are classes, interfaces, ception. This example might seem This overall solution makes for a
constants and abstract methods. somewhat ridiculous, but it demon- more consistent approach.
This type has no implementation, strates the limitations of naming con- In addition, this solution is more
but otherwise unrelated classes can ventions, because of how much infor- extensible because more than one at-
implement it by providing imple- mation the name itself can convey. In tribute can be associated with a
mentations for its abstract methods. fact, JUnit doesn’t implement the method, and attributes can have ad-
functionality to check boundry condi- ditional data. For example, Nunit
tions in this way. Other approaches has another attribute defined for a
Stylistic naming patterns used in Java (such as JavaDoc tags) method that expects an exception.
At the method level, it is common in can provide additional information. This leaves the name not only unen-
the Java platform to use naming con- However, they are not present at run- cumbered by the context in which it
ventions to identify a special method. By time and usually require preprocess- is run but also more relevant to what
virtue of the name, the program finds ing the code to identify and process is being tested (see Figure 3b).
the method at runtime using reflection. the tags.
Once found, the executing program spe- In .NET, stylistic naming patterns
cially interprets this method. For exam- are not needed because, in addition
A
ple, when a programmer defines to attributes that the Framework ttributes in .NET provide an ele-
a test method in JUnit—a popular unit- specifies, a programmer can create gant, consistent approach to
testing framework for Java (www. custom attributes that are defined adding declarative information to
junit.org)—the first four letters of a test and used in the same way. These at- runtime entities. Because the runtime
method must be test (see Figure 2a). tributes are not just names but are entities interact with the supporting
The program that executes the tests first instances of classes that might have services via declarative information,
verifies that the class inherits from additional data. Figure 3a shows a the set of services and supporting at-
TestCase. Then, using reflection, it similar test class defined with Nunit tributes does not have to be closed.
looks for any methods that start with (www.nunit.org), a unit testing tool By providing a standard mechanism
Test. In the code in Figure 2a, the pro- for the .NET platform. Nunit, a de- to extend built-in metadata with cus-
September/October 2002 IEEE SOFTWARE 19
DESIGN
tom attributes, .NET lets program-
mers develop applications that can
public class MyClass extends TestCase
interact with services not yet defined
{
public void testSuccess() or supported by CLR. In fact, Nunit
{ /* ... */ } version 2.0 was written with custom
} attributes and provides much of the
(a) flexibility we’ve demonstrated here.
In contrast, the most common ad
public class MyClass extends TestCase hoc mechanisms in Java to add de-
{
clarative information include marker
public void testMyException()
interfaces, stylistic naming patterns,
{
and JavaDoc tags. These inconsis-
try {
tently solve the problem of adding
/* code that throws exception */
declarative information to runtime
fail(“Code should have thrown MyException”);
} entities. They are also error prone
catch(MyException e) and too simplistic for today’s appli-
{ /* expected exception — success */ } cations. The Java community recog-
} nizes this limitation and has started
} working on JSR-175 (see www.jcp.
(b) org/jsr/detail/175.jsp), which speci-
fies a similar facility for Java that is
public class MyClass extends TestCase
already in .NET.
{
public void testSuccess_ExpectException_MyException()
James Newkirkis a software project manager for
{ /* ... */ }
Thoughtworks. He has been working with the .NET Framework
} since its introduction in the summer of 2000. Contact him at
[email protected].
(c)
Alexei A. Vorontsovis a software technical lead for
Figure 2. (a) A test method in JUnit (the method’s first four letters Thoughtworks. He has worked on an enterprise transforming
must be tteesstt); (b) a test for the boundary conditions that verify that application for the past three years. Contact him at alexei@
nunit.org.
an exception is thrown when expected; (c) a naming convention to
specify not only a test method but also some additional information
about how to interpret the test result. IEEE
[TestFixture]
public class MyClass
{
[Test]
FFUUTTUURREE TTOOPPIICCSS::
public void Success()
{ /* ... */ }
} TTVVhheeii BBssuussiiiittnn ee uusssss sooff
(a)
SSooffttwwaarree EEnnggiinneeeerriinngg
oonn tthhee
[TestFixture]
public class MyClass SSooffttwwaarree IInnssppeeccttiioonnss
wweebb
{ UUssaabbiilliittyy
[Test]
[ExpectedException(typeof(MyException))]
IInntteerrnnaattiioonnaalliizzaattiioonn
public void Success()
{ /* would throw my exception */ }
}
(b)
Figure 3. A test class (a) defined with Nunit and (b) with another
attribute defined for a method that expects an exception.
http://computer.org/software
20 IEEE SOFTWARE September/October 2002
memorial
Senior Lead Editor: Dale Strok (cid:2) [email protected]
From Goto-less to Structured Programming:
The Legacy of
Edsger W. Dijkstra
Peter P. Chen
D
id you know that Edsger I am a “programmer!” In 1972, Dijkstra published “Notes
Dijkstra just passed away?” The first time I saw Dijkstra was on Structured Programming” (Struc-
When I first heard the news, I when he delivered his Turing Award tured Programming, O.J. Dahl, E.W.
was shocked. “How could acceptance speech. I was one of the Dijkstra, and C.A. Hoare, eds., Acad-
this happen?!” I asked my- many people who stood for an hour emic Press, 1972). This triggered the
self. Last year (but it seemed to listen to that speech because all the Structured Programming movement,
just yesterday) when Edsger and I sat seats were filled. It was worth it: he which helped many of us improve our
together on a small bus leaving told us a story I will never forget. practices.
the Software Pioneers Conference in When he applied for a wedding li- A survey of more than 1,000 col-
downtown Bonn, Germany, to return cense in 1957, Dutch law required him lege professors identified the 38 most
to our hilltop hotel, he looked to declare his profession. Filling in the influential papers in computer science
healthy. On that bus ride, we dis- form, Dijkstra stated he was a “pro- (Great Papers in Computer Science, P.
cussed the interesting difficulties he grammer.” The Amsterdam authorities Laplante, ed., West Publishing Co., 1996;
had faced early on in his career. Al- claimed there was no such profession www.csc.lsu.edu/~chen/greatpapers.
though he had run into obstacles, he and rejected his initial application. As a htm), and Dijkstra authored five of
could now laugh about them since he result, his marriage certificate stated his them. In June 2001, at the Software
had discovered ways to overcome profession as “theoretical physicist.” Pioneers Conference, about 1,200
them and change history. Today as I What struck me 30 years ago and still software professionals saw Dijkstra
recall his face and soft voice, I see the resonates in my mind today is how speak for the last time. Fortunately,
smile of a man who revolutionized Dijkstra was proud to be a program- that speech is preserved in streaming
software development. mer instead of a theoretical physicist. video (www.sdm.de/conf2001/index_
This is the kind of person software de- e.htm) and book/DVD (Software Pio-
A short biography velopment needs; being proud of one’s neers: Contributions to Software Engi-
Edsger W. Dijkstra was born in profession is one of the most crucial neering, M. Broy and E. Denert, eds.,
the Netherlands in 1930 and died 6 psychological steps toward better- Springer-Verlag, 2002) format.
August 2002. After receiving his PhD quality work.
E
in computing science from the Uni- dsger Dijkstra is one of the most in-
versity of Amsterdam, he worked as Major contributions fluential figures in computer sci-
a programmer at the Mathematical Dijkstra’s most famous paper is ence. His teachings (www.cs.utexas.
Centre in Amsterdam, a math profes- probably “Goto Statement Considered edu/users/EWD) will resonate through
sor at Eindhoven University of Tech- Harmful” (Comm. ACM, Mar. 1968, the work of software developers for
nology, a research fellow at the Bur- pp. 147–148), which brought consid- many years to come.
roughs Corp., and the Schlumberger erable attention to the problem of
Centennial Professor of Computer software developers’ careless usage of
Science at the University of Texas at the Goto statement. As a result, pro-
Peter P. Chenis the Foster Distinguished Professor at
Austin. He received the ACM Turing grammers today use it more carefully Louisiana State University and the inventor of the Entity-
Award in 1972. or not at all. Relationship model. Contact him at [email protected].
0740-7459/02/$17.00 © 2002 IEEE September/October 2002 IEEE SOFTWARE 21