Matthew Kaplan

Specifying subject-oriented composition

Subject-oriented programming supports composition of object-oriented programs or program fragments called subjects. This article presents an approach to specifying desired compositions in a convenient and concise manner. We motivate the need for subject composition, and illustrate the key issues. We define a low-level model in which composition is controlled by detailed attributes. We then describe higher-level composition rules as collections of attributes that, together, provide some desired aspect of composition functionality. Compositions are specified by means of composition expressions written as collections of rules, typically a general rule along with rules specifying exceptions. A rule library is thus an open-ended collection of useful abstractions in terms of which to define compositions. We give definitions of a few common rules, Including merge and override, as a first step towards a generally useful composition rule library. We also outline an object-oriented framework for implementing our composition approach, which we are currently building as part of our support for subject-oriented programming in C++.

Toward Engineered, Useful Use Cases

We explore common problems that exist in the practice of use case modeling: lack of consistency in defining use cases, misalignment between the UML metamodel and the textual representations of use cases expounded in the literature, and the lack of a semantics that allows use cases to be executable and analyzable. We propose an engineering approach to the issues that can provide a precise foundation for use case development. We next discuss four potential uses of such a foundation and identify the research problems that must be addressed to support these applications.

Less is More: A Minimalistic Approach to UML Model-Based Conformance Test Generation

We present a minimalist approach to model-based test generation. Our approach leverages the information provided in the domain and behavioral models of an application under test to produce a small yet effective set of test cases without additional user input. The domain model consists of UML class diagram with invariants, while the behavioral model consists of UML use cases. Each use case flow has an associated guard condition and a set of updates (to the domain object diagram and the output parameters). We treat the model invariants to enable a novel specify once, test everywhere paradigm. Our approach frees the modeler from the responsibility of specifying appropriate alternate flows on use cases affected by each invariant - our analysis augments the specified use cases with appropriate alternate flows. Our approach then produces suitable testing goals which are refinements of the guard conditions on the augmented flows using a set of fault models. Another salient feature of our approach is generation of verification sequences to ensure that the object diagram updates associated with a given flow are implemented correctly. Our technique uses a novel set of fault models to mutate an object diagram and a novel algorithm which distinguishes between the original and the mutated object diagrams. We describe the techniques used in our test generation approach.

Requirements Modeling and Validation Using Bi-layer Use Case Descriptions

Extension of the modeling notations and formal languages for use case description are the commonly suggested solutions for adding precision to use case models. Practitioners have often argued against adoption of such techniques citing reasons like the steep learning curve for formal languages; and the quickness in using imprecise use case descriptions for communicating to different stake-holders of the system. In this paper we introduce the Archetest modeling environment, which through a unique bi-layer approach accepts use case descriptions in their imprecise form and then assists in adding precision through a wizard driven process. Thereby, it lends itself to both quick and precise modeling. Also the two forms of the use case models are self contained and cross-linked. This allows different modelers, the precise and the imprecise, to collaborate and also supports stake-holder specific feedbacks of the automated analysis. We describe the structure of Archetests use case models, and show how these models are amenable to automated processing. We present a case study which reports on typical modeling times using Archetest and demonstrates its scalability.

The Feasibility of Automated Feedback-Directed Specification-Based Test Generation: A Case Study of a High-Assurance Operating System

In this paper, we describe results of a case study to establish the feasibility of deriving mappings between an abstract user level specification and the code elements in a concrete implementation of a highly secure smart card operating system. Such a mapping is necessary for feedback-directed specification-based test generation to improve code coverage, needed by the stringent criteria for high-assurance systems. We used test cases generated from the user level specification to identify the executed code elements and attempted to use static analysis to map the unexecuted code elements to the corresponding elements in the user level specification. Our primary result is evidence that, given a sufficiently expressive user level specification and a test generation system that is able to effectively use such a specification, the resulting tests will cover the vast majority of the code branches that are able to be covered. Therefore, the benefit of a feedback-directed system will be limited. We further provide evidence that the static analysis required to generate feedback in these cases tends to be difficult, involving inferring the semantics of the internal implementation of data structures. In particular, we observed that the internal states at the implementation level in a high security application pose significant challenges to this mapping process.

Test Machine Scheduling and Optimization for z/ OS

We describe a system for solving a complex scheduling problem faced by software product test organizations. Software testers need time on test machines with specific features and configurations to perform the test tasks assigned to them. There is a limited number of machines with any given configuration, and this makes the machines scarce resources. Deadlines are always short. Thus, testers must reserve time on machines. Managing a schedule for a large test organization is a difficult task to perform manually. Requirements change frequently, making the task even more onerous, yet scheduling is done by hand in most teams. Our scheduling system is able to take into account the many and varied constraints and preferences that a team of human users inevitably has