Detecting behavioral conflicts among crosscutting concerns

Aspects have been successfully promoted as a means to improve the modularization of software in the presence of crosscutting concerns. Within the Ideals project, aspects have been shown to be valuable for improving the modularization of idioms (see also Chapter 1). The so-called aspect interference problem is considered to be one of the remaining challenges of aspect-oriented software development: aspects may interfere with the behavior of the base code or other aspects. Especially interference among aspects is difficult to prevent, as this may be caused solely by the composition of aspects that behave correctly in isolation. A typical situation where this may occur is when multiple advices are applied at the same, or shared, join point. In this chapter we explain the problem of behavioral conflicts among aspects at shared join points, illustrated by aspects that represent idioms: Parameter checking and Error propagation. We present an approach for the detection of behavioral conflicts that is based on a novel abstraction model for representing the behavior of advice. The approach employs a set of conflict detection rules which can be used to detect both generic conflicts as well as domain or application specific conflicts. One of the benefits of the approach is that it neither requires the application programmers to deal with the conflict models, nor does it require a background in formal methods for the aspect programmers

Evaluating testing methods by delivered reliability

There are two main goals in testing software: (1) to achieve adequate quality (debug testing), where the objective is to probe the software for defects so that these can be removed, and (2) to assess existing quality (operational testing), where the objective is to gain confidence that the software is reliable. Debug methods tend to ignore random selection of test data from an operational profile, while for operational methods this selection is all-important. Debug methods are thought to be good at uncovering defects so that these can be repaired, but having done so they do not provide a technically defensible assessment of the reliability that results. On the other hand, operational methods provide accurate assessment, but may not be as useful for achieving reliability. This paper examines the relationship between the two testing goals, using a probabilistic analysis. We define simple models of programs and their testing, and try to answer the question of how to attain program reliability: is it better to test by probing for defects as in debug testing, or to assess reliability directly as in operational testing? Testing methods are compared in a model where program failures are detected and the software changed to eliminate them. The “better” method delivers higher reliability after all test failures have been eliminated. Special cases are exhibited in which each kind of testing is superior. An analysis of the distribution of the delivered reliability indicates that even simple models have unusual statistical properties, suggesting caution in interpreting theoretical comparisons

Microwave vs optical crosslink study

The intersatellite links (ISL's) at geostationary orbit is currently a missing link in commercial satellite services. Prior studies have found that potential application of ISL's to domestic, regional, and global satellites will provide more cost-effective services than the non-ISL's systems (i.e., multiple-hop systems). In addition, ISL's can improve and expand the existing satellite services in several aspects. For example, ISL's can conserve the scarce spectrum allocated for fixed satellite services (FSS) by avoiding multiple hopping of the relay stations. ISL's can also conserve prime orbit slot by effectively expanding the geostationary arc. As a result of the coverage extension by using ISL's more users will have direct access to the satellite network, thus providing reduced signal propagation delay and improved signal quality. Given the potential benefits of ISL's system, it is of interest to determine the appropriate implementations for some potential ISL architectures. Summary of the selected ISL network architecture as supplied by NASA are listed. The projected high data rate requirements (greater than 400 Mbps) suggest that high frequency RF or optical implementations are natural approaches. Both RF and optical systems have their own merits and weaknesses which make the choice between them dependent on the specific application. Due to its relatively mature technology base, the implementation risk associated with RF (at least 32 GHz) is lower than that of the optical ISL's. However, the relatively large antenna size required by RF ISL's payload may cause real-estate problems on the host spacecraft. In addition, because of the frequency sharing (for duplex multiple channels communications) within the limited bandwidth allocated, RF ISL's are more susceptible to inter-system and inter-channel interferences. On the other hand, optical ISL's can offer interference-free transmission and compact sized payload. However, the extremely narrow beam widths (on the order of 10 micro-rad) associated with optical ISL's impose very stringent pointing, acquisition, and tracking requirements on the system. Even if the RF and optical systems are considered separately, questions still remain as to selection of RF frequency, direct versus coherent optical detection, etc. in implementing an ISL for a particular network architecture. These and other issues are studied

Completeness, robustness, and safety in real-time software requirements specification

This paper presents an approach to providing a rigorous basis for ascertaining whether or not a given set of software requirements is internally complete, i.e., closed with respect to questions and inferences that can be made on the basis of information included in the specification. Emphasis is placed on aspects of software requirements specifications that previously have not been adequately handled, including timing abstractions, safety, and robustness