Person:
Rugaber, Spencer

Associated Organization(s)
Organizational Unit
ORCID
ArchiveSpace Name Record

Publication Search Results

Now showing 1 - 10 of 13
Thumbnail Image
Item

Goal Reasoning: Papers from the ACS Workshop

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.

Thumbnail Image
Item

A Feature Model of Coupling Technologies for Earth System Models

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.

Thumbnail Image
Item

Dynamic Assembly from Models (DYNAMO)

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.

Thumbnail Image
Item

An Example of Program Understanding

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.

Thumbnail Image
Item

SoD-TEAM: Teleological reasoning in adaptive software design

8/31/2012 , Goel, Ashok K. , Rugaber, Spencer

Thumbnail Image
Item

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

2008-12-20 , Harrold, Mary Jean , Rugaber, Spencer , Rehg, James M.

Thumbnail Image
Item

DYNAMO Design Guidebook

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.

Thumbnail Image
Item

Collaborative research: earth system curator: spanning the gap between models and datasets

2010-10-31 , Rugaber, Spencer

Thumbnail Image
Item

Comparison of Metaprogramming and Template Programming Solutions for Invariant Maintenance through Implicit Invocation

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.

Thumbnail Image
Item

MASTERMIND project final report

1998 , Rugaber, Spencer