letters to the editor
DOI: 10.1145/1516046.1516049
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 several functions?

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

author’s Response:

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 functions.

Daniel Jackson, Cambridge, MA

Corrections

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 [e-mail].

© 2009 acm 0001-0782/09/0600 $10.00