Communications of the ACM

Letters to the editor

Share the Threats

By CACM Staff
Communications of the ACM, June 2009, Vol. 52 No. 6, Page 9
10.1145/1516046.1516049
Comments

Othman El Moulat's comment "What Role for Computer Science in the War on Terror?" (Apr. 2009) concerning the article "The Topology 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 security 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 potential terrorist cells or factions willingly and wantonly seek ways to destroy Western technologies and organizations. An article aimed at exposing threats or educating the public on future threats does not in any way target a specific race, creed, or religion.

I applaud the authors of "The Topology of Dark Networks" and hope Communications continues to keep us up to date with factual articles of this nature. Organizations that are concerned with their own beliefs, traditions, and objectives should be willing to transparently 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 virtual 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 defining 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).

Back to Top

The Digital Library is published by the Association for Computing Machinery. Copyright © 2009 ACM, Inc.