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 - 10 of 13

Goal Reasoning: Papers from the ACS Workshop

(Georgia Institute of Technology, 2015-05-28) Aha, David W. ; Anderson, Tory S. ; Bengfort, Benjamin ; Burstein, Mark ; Cerys, Dan ; Coman, Alexandra ; Cox, Michael T. ; Dannenhauer, Dustin ; Floyd, Michael W. ; Gillespie, Kellen ; Goel, Ashok K. ; Goldman, Robert P. ; Jhala, Arnav ; Kuter, Ugur ; Leece, Michael ; Maher, Mary Lou ; Martie, Lee ; Merrick, Kathryn ; Molineaux, Matthew ; Muñoz-Avila, Héctor ; Roberts, Mark ; Robertson, Paul ; Rugaber, Spencer ; Samsonovich, Alexei ; Vattam, Swaroop S. ; Wang, Bing ; Wilson, Mark

This technical report contains the 14 accepted papers presented at the Workshop on Goal Reasoning, which was held as part of the 2015 Conference on Advances in Cognitive Systems (ACS-15) in Atlanta, Georgia on 28 May 2015. This is the fourth in a series of workshops related to this topic, the first of which was the AAAI-10 Workshop on Goal-Directed Autonomy; the second was the Self-Motivated Agents (SeMoA) Workshop, held at Lehigh University in November 2012; and the third was the Goal Reasoning Workshop at ACS-13 in Baltimore, Maryland in December 2013.
SoD-TEAM: Teleological reasoning in adaptive software design

(Georgia Institute of Technology, 8/31/2012) Goel, Ashok K. ; Rugaber, Spencer
Collaborative research: earth system curator: spanning the gap between models and datasets

(Georgia Institute of Technology, 2010-10-31) Rugaber, Spencer
A Feature Model of Coupling Technologies for Earth System Models

(Georgia Institute of Technology, 2010) Dunlap, Rocky ; Rugaber, Spencer ; Mark, Leo

Couplers that link together two or more numerical simulations are well-known abstractions in the Earth System Modeling (ESM) community. In the past decade, reusable software assets have emerged to facilitate scientists in implementing couplers. While there is a large amount of overlap in the features supported by software coupling technologies, their implementations differ significantly in terms of both functional and non-functional properties. Using a domain analysis method called feature analysis, we explore the spectrum of features supported by coupling technologies used to build today's production ESMs. The results of the feature analysis will enable automatic code generation of ESM couplers.
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.