Is there such a thing anymore as a software system that doesn't need to be secure? Almost every softwarecontrolled system faces threats from potential adversaries, from Internet-aware client applications running on PCs, to complex telecommunications and power systems accessible over the Internet, to commodity software with copy protection mechanisms. Software engineers must be cognizant of these threats and engineer systems with credible defenses, while still delivering value to customers. In this paper, we present our perspectives on the research issues that arise in the interactions between software engineering and security.

Abstract—Bounded exhaustive testing (BET) is a verification technique in which software is automatically tested for all valid inputs up to specified size bounds. A particularly interesting case of BET arises in the context of systems that take structurally complex inputs. Early research suggests that the BET approach can reveal faults in small systems with inputs of low structural complexity, but its potential utility for larger systems with more complex input structures remains unclear. We set out to test its utility on one such system. We used Alloy and TestEra to generate inputs to test the Galileo dynamic fault tree analysis tool, for which we already had both a formal specification of the input space and a test oracle. An initial attempt to generate inputs using a straightforward translation of our specification to Alloy did not work well. The generator failed to generate inputs to meaningful bounds. We developed an approach in which we factored the specification, used TestEra to generate abstract inputs based on one factor, and passed the results through a postprocessor that reincorporated information from the second factor. Using this technique, we were able to generate test inputs to meaningful bounds, and the inputs revealed nontrivial faults in the Galileo implementation, our specification, and our oracle. Our results suggest that BET, combined with specification abstraction and factoring techniques, could become a valuable addition to our verification toolkit and that further investigation is warranted. Index Terms—Formal methods, program verification, testing and debugging. 1

Her research interests are in architecture-based, component-based and service-oriented test methodologies, as well as methods for analysis of non-functional properties.

In program profiling to assess test set adequacy, a challenge is to select code to be included in the assessment. Current mechanisms are coarse-grained; biased to dominant modularizations; require tedious, error-prone manual selection; and leave tester intent implicit in inputs to testing tools. Aspect-oriented constructs promise to improving testing in two ways: by improving our ability to select the code to include in adequacy criteria, and by documenting selection intentions in declarative form in the code itself. One problem is that current join point models do not reveal program behavior in enough detail to support white-box coverage analysis. Our contribution is the formulation, prototyping, and evaluation of a language-and-tool-based approach to white-box coverage adequacy analysis that we call concern coverage. We develop and evaluate one instance of the general idea in which branches, in particular, are exposed as join points to support branch coverage analysis of crosscutting concerns. Our results are consistent with the claim that the idea has the potential to improve test coverage analysis. Categories and Subject Descriptors D.2.5 [Testing and Debugging]: Testing tools – code coverage analysis, testing. D.3.3 [Programming Languages]: Language constructs and features – generalized join point model, generalized advice.

We present a method for static program analysis that leverages tests and concrete program executions. State abstractions generalize the set of program states obtained from concrete executions. A theorem prover then checks that the generalized set of concrete states covers all potential executions and satisfies additional safety properties. Our method finds the same potential errors as the mostprecise abstract interpreter for a given abstraction and is potentially more efficient. Additionally, it provides a new way to tune the performance of the analysis by alternating between concrete execution and theorem proving. We have implemented our technique in a prototype for checking properties of C # programs.

Abstract. The topic of software architecture (SA) based testing has recently raised some interest. Recent work on the topic has used the SA as a reference model for code conformance testing, to check if an implementation fulfills (conforms to) its specification at the SA level. In this context, on previous papers, we have analyzed: i) how suitable test cases can be “selected ” from the SA specification and ii) how they may be “refined ” into concrete tests executable at the code level. While the selection stage has been done systematically, the refinement step has been left to be done manually, based on the software engineer knowledge on how to map “abstract values of the specification to the concrete values of the implementation”. In this paper, we extend previous approaches, by providing a systematic way to perform the refinement step. We show how choosing a specific architectural style, which supports implementation and facilitates the mapping among SA-based and code-based test cases, a completely systematic SA-based testing approach can be delivered. 1

Abstract. SAs provide a high-level model of large, complex systems using suitable abstractions of the system components and their interactions. SA dynamic descriptions can be usefully employed in testing and analysis. We describe here an approach for SA-based conformance testing: architectural tests are selected from a Labelled Transition System (LTS) representing the SA behavior and are then refined into concrete tests to be executed on the implemented system. To identify the test sequences, we derive abstract views of the LTS, called the ALTSs, to focus on relevant classes of architectural behaviors and hide away uninteresting interactions. The SA description of a Collaborative Writing system is used as an example of application. We also briefly discuss the relation of our approach with some recent research in exploiting the standard UML notation as an Architectural Description Language, and in conformance testing of reactive systems. 1

This paper reports on our practical experience in using AOSD for security. In particular we describe one of our past case studies, which focused on the security measures of an existing FTP server implementation.

{liny, zhangj, gray} @ cis.uab.edu As models and model transformations are elevated to first-class artifacts within the software development process, there is an increasing need to introduce core software engineering principles into modeling activities. In this position paper, we identify model comparison algorithms as a key toward addressing best practices associated with model transformation testing and version control of models. 1.

Nowadays many system designers choose to use commercial off-the-shelf (COTS) operating systems as building blocks in their systems, to achieve lower development costs and shorter time-to-market. However, these OSs are designed