Person:

Rugaber, Spencer

Permanent Link

https://hdl.handle.net/1853/71653

Associated Organization(s)

Organizational Unit

College of Computing

Full item page

Publication Search Results

Now showing 1 - 9 of 9

HDCCSR: software self-awareness using dynamic analysis and Markov models

(Georgia Institute of Technology, 2008-12-20) Harrold, Mary Jean ; Rugaber, Spencer ; Rehg, James M.
Comparison of Metaprogramming and Template Programming Solutions for Invariant Maintenance through Implicit Invocation

(Georgia Institute of Technology, 2006) Rugaber, Spencer ; Gdalevich, Jonathan

Large software systems commonly contain multiple interdependent components. When independent components change, dependent components must change as well in order to establish system invariants. This scheme leads to a variety of approaches for components to communicate with each other to maintain the invariants. One promising way to do so is to automatically generate implicit invocation code for maintaining the invariant between dependent and independent components. However, since a complex system could have many invariants and performance requirements, the generated code must have a small runtime overhead. This paper explores eight separate approaches for the implementation of implicit invocation invariant maintenance in C++ using compile-time metaprogramming via OpenC++ and generative programming with C++ templates.
Dynamic Assembly from Models (DYNAMO)

(Georgia Institute of Technology, 2005) Rugaber, Spencer ; Stirewalt, R. E. Kurt

The DYNAMO project is concerned with assembling high-assurance systems from components, and, specifically, with guaranteeing correct interaction of sets of large, heterogeneous components. Several problems must be overcome to provide such guarantees: 1) dealing with the sheer complexity of the individual components and their interoperation; 2) maintaining design integrity and information hiding in the individual components; 3) providing the desired guarantees; and 4) not compromising efficiency while accomplishing the other goals. DYNAMO addresses these problems with several techniques: 1) a layered, implicit-invocation architecture limits complexity by reducing the quantity and nature of allowed interactions; 2) a declarative specification mechanism abstracts away low-level details such as event dispatch and handling and variable updates; and 3) compile- time component wrapper generation removes expensive, inter-layer procedure calls.
DYNAMO Design Guidebook

(Georgia Institute of Technology, 2002) McNeely, Corinne ; Rugaber, Spencer ; Stirewalt, R. E. Kurt ; Zook, David

The DYNAMO project is concerned with the assembly of components of interactive systems. It includes a design method, described in this guidebook, and a set of tools that support it. The DYNAMO design method starts with a declarative model of the assembly expressed using a graphical UML CASE tool. From the declarative model, DYNAMO tools automatically generate C++ wrapper classes that glue the components together. The DYNAMO design method comprises three-phases that refine a conceptual model of a proposed assembly into interrelated components organized into layered mode components. In Phase 0, the environment in which the assembly executes is described in terms of external actors, the assembly itself, the communication among them, and the behavioral properties that the assembly guarantees to maintain. Phase 1 asks the designer to partition the assembly into its constituent components and their relationships, assigning responsibility for external actions and guarantee-maintenance to the components appropriately. Finally, Phase 2 asks the designer to layer the constituents as mode components, where lower-level components communicate status changes upward, and higher-level components make specific service requests of lower-level components. For each phase, the guidebook provide a purpose, a diagrammatic representation that describes the resulting design artifact, a set of steps to create that diagram, and a set of guidelines or design rules for making appropriate design decisions. Each phase is illustrated using the example of a simple text browser assembly. At the end of the document, a glossary of all DYNAMO-related terms is provided.
MASTERMIND project final report

(Georgia Institute of Technology, 1998) Rugaber, Spencer
An Example of Program Understanding

(Georgia Institute of Technology, 1998) Rugaber, Spencer

What does it mean to understand a program? What sorts of questions can be answered about a program? What background knowledge is required to answer them? What tools can help the process? To answer questions like these, we will look at an example of program understanding in action. Imagine the following scenario: You are assigned responsibility for maintaining a program you have never seen before. It is written in the FORTRAN language and is concerned with finding the roots of function. We will assume that you know the FORTRAN language but are not an expert at it. That is, you still have to occasionally look at the reference manual to answer questions about the language. We will also assume that you have a computer science background, either through formal education or by on-the-job experience, so that you know how to design and compose programs similar to the one you are about to maintain. Finally, we will assume that you have a passing acquaintance with numerical analysis, possibly from a course you took. Hence, you are familiar with the idea of finding a root of a function, but you would have to look up an actual algorithm in order to write a root-finding program yourself. As you are responsible for long-term maintenance of the program, you want to understand it better. So you decide to systematically read it. This is distinct from the situation where you have a specific task to accomplish, such as finding a bug, adding a new feature, or updating the program to conform to a change in the language or operating environment. In these cases, instead of systematic reading, you might direct your efforts to accomplishing the specific task. Here, we will assume that you are going to make a single, sequential pass through the program text, with perhaps a few side trips to answer small questions as they arise. The following program text is taken directly from its source [1]. We have added three digits of line numbers in the left margin for expository purposes; they are not part of the program itself. We will annotate each line in the program as we come to it. The idea is to express some idea of what that line is there for. Sometimes we will raise questions, sometimes we will generate hypotheses that need to be confirmed, and sometimes we will speculate about the application domain. The intent is to get a feel for the kinds of knowledge required to understand a program on a line-by-line basis.
Automating UI Generation by Model Composition

(Georgia Institute of Technology, 1998) Stirewalt, R. E. Kurt ; Rugaber, Spencer

Automated user-interface generation environments have been criticized for their failure to deliver rich and powerful interactive applications. To specify more powerful systems, designers need multiple, specialized modeling notations. The model composition problem is concerned with automatically deriving powerful, correct, and efficient user interfaces from multiple models specified in different notations. Solutions balance the advantages of separating code generation into specialized code generators with deep, model-specific knowledge against the correctness and efficiency obstacles that result from such separation. We present a solution that maximizes the advantages of separating code generation. In our approach, highly specialized, model-specific code generators synthesize run-time modules from individual models. We address the correctness and efficiency obstacles by formalizing composition mechanisms that code generators may assume and that are guaranteed by a run-time infrastructure. The mechanisms operate to support run-time module composition as conjunctions in the sense defined by Zave and Jackson.
Automating the Design of Specification Interpreters

(Georgia Institute of Technology, 1996) Stirewalt, R. E. Kurt ; Rugaber, Spencer ; Abowd, Gregory D.

In this paper, we demonstrate the use of model checking in an automated technique to verify the operationalization of a declarative specification language. We refer to an interpreter synthesizer as a software tool that transforms a declarative specification into an executable interpreter. Iterative approaches to synthesizer generation refine initial synthesizer designs by validating them over a test suite of specifications. Carefully chosen test suites and structural constraints enable inductive reasoning with support from a model checker to assert the correctness of generated interpreters. This iterative approach to synthesizer generation occurred naturally in our work on developing interpreters for declarative human-computer dialogue languages as part of the DARPA MASTERMIND project. We will discuss the issues underlying the translation, operationalization and verification of the hierarchical task language for MASTERMIND. We will also discuss the importance of this semi-automated, iterative approach for assessing non-functional design tradeoffs.
The MASTERMIND User Interface Generation Project

(Georgia Institute of Technology, 1996) Browne, Thomas ; Davila, David ; Rugaber, Spencer ; Stirewalt, R. E. Kurt

Graphical user interfaces are difficult to construct and, consequently, suffer from high development and maintenance costs. Automatic generation from declarative descriptions can reduce costs and enforce design principles. MASTERMIND is a model based approach to user interface generation. Designers model different aspects of an interface using declarative modeling languages, and tools synthesize these models into run-time code. The design process begins with user task and application modeling. These models are then refined into dialogue, presentation, and interaction models and an application API. These latter models drive the synthesis of run-time code. A design tool called Dukas is employed to support the refinement of task models into dialogue models.