letters to the editor
share the threats
Othman El moulat’s comment
“What Role for Computer
Science in the War on Ter-
ror?” (Apr. 2009) concern-
ing the article “The Topolo-
gy of Dark Networks” by Jennifer Xu and
Hsichun Chen (Oct. 2008) that the views
and articles in Communications should
have no bearing on or bias toward any
agenda, political or religious, is a point
well taken. However, in light of the se-
curity breaches occurring throughout
the digital world, any information that
exposes threats should indeed be well
received and published wherever it is
relevant to technologists and security
specialists, as in Communications.
It is reasonable to suspect that poten-
tial terrorist cells or factions willingly
and wantonly seek ways to destroy West-
ern technologies and organizations. An
article aimed at exposing threats or edu-
cating the public on future threats does
not in any way target a specific race,
creed, or religion.
I applaud the authors of “The Topol-
ogy of Dark Networks” and hope Com-
munications continues to keep us up to
date with factual articles of this nature.
Organizations that are concerned with
their own beliefs, traditions, and ob-
jectives should be willing to transpar-
ently share their interests with the rest
of the world.
John Orlock, Il
Virtualization still evolving
Kirk L. Kroeker’s news article “The Evolution of Virtualization” (Mar. 2009)
took a limited view of its subject. I contrast it with how my company uses virtual machines for several quite practical purposes:
Software testing. Rather than build a
test environment, then rebuild it after a
series of tests, we set it up with a set of
baseline virtual machines (perhaps client/server), then run our tests. This way
when we finish testing, we copy back
over the baseline virtual machine and
are ready for the next round of testing;
Customer support. We look to mimic
customer configurations in a set of vir-
tual machines, aiming to verify or refute
a problem a customer might be having
and possibly provide a workaround or
new build of the software. If this scenario turns out to be common, we roll it
into our testing sandbox;
Project services. When trying to remotely configure and build a solution
for a customer, we first build it in a virtual machine, then apply the solution
and test. This process also greatly improves delivery of the solution; and
Software demonstration. We build
our demos in a virtual machine, making it much easier for us to get them out
to field personnel.
Jerry Walter, Troy, OH
how to Define the Granularity
of Properties and functions
I was confused about the discussion
of properties and functions in Daniel
Jackson’s review article “A Direct Path
to Dependable Software” (Apr. 2009).
Jackson seemed to be saying that properties are more fine-grain than functions yet also that a property cuts across
several functions at the same time.
Doesn’t this imply that properties are
coarse-grain, assuming they transcend
Trying to resolve my questions with
the help of Webster’s dictionary, I
learned that a function is a “factor” and a
property is any attribute or characteristic.
So functions and properties can be both
fine- and coarse-grain, depending on
the assumptions of abstraction inherent in the mind of the author.
Does Jackson view a “function” as a
modularity construct in a programming
language? Does he mean that properties
are those factors or attributes (“
functions” if you will) that are independent
of the software’s special-case implementation?
I may still be confused, but trying
to infer Jackson’s meaning led me to
conclude the following: Fine-grain attention to the software’s behavior-level
characteristics (including properties,
functions, or whatever abstractions a
developer is using) is important in de-
fining an effective dependability case.
Is this correct?
CJ fearnley, Upper Darby, PA
Requirements traditionally break the
behavior of a system into a collection of
functions, each describing in full some
feature of the system. A radiotherapy
machine might, for example, offer
functions to recall a patient’s prescribed
dose from a database; set the equipment
to deliver a given dose; activate the
equipment; and so on. Prioritizing functions
isn’t very useful, because the critical
aspects of a system typically involve many
functions, though often not in their entirety.
A property, on the other hand, describes
an expected observation of the system’s
behavior and can be expressed at any level
of granularity: that, for example, some
of the dose delivered to a patient never
exceeds some fixed limit; that a patient
receives his or her prescribed dose within
some tolerance; that the dose delivered
and the dose logged always match; and
so on. So a property can at the same
time be more fine-grain than a single
function (since it describes the function
only partially) and cut across multiple
Daniel Jackson, Cambridge, MA
In the Q&A “Our Dame Commander”
(Apr. 2009), Leah Hoffmann described
Wendy Hall as “the third female president of ACM.” Hall is the sixth, preceded by: Jean Sammet (1974–1976),
Adele Goldberg (1984–1986), Gwen Bell
(1992–1994), Barbara Simons (1998–
2000), and Maria Klawe (2002–2004).
The photographs of the Rebooting
Computing Summit (Apr. 2009) were
taken by Richard P. Gabriel (page 2) and
by Mary Bronzan (page 19).
Communications welcomes your opinion. to submit a Letter
to the editor, please limit your comments to 500 words or
less and send to firstname.lastname@example.org.
© 2009 acm 0001-0782/09/0600 $10.00