Spencer Rugaber

Structure, behavior, and function of complex systems: The structure, behavior, and function modeling language

Abstract Teleological modeling is fundamental to understanding and explaining many complex systems, especially engineered systems. Research on engineering design and problem solving has developed several ontologies for expressing teleology, for example, functional representation, function–behavior–structure, and structure–behavior–function (SBF). In this paper, we view SBF as a programming language. SBF models of engineering systems have been used in several computer programs for automated design and problem solving. The SBF language captures the expressive power of the earlier programs and provides a basis for interactive construction of SBF models. We provide a precise specification of the SBF language. We also describe an interactive model construction tool called SBFAuthor.

Recognizing design decisions in programs

The authors present a characterization of design decisions that is based on the analysis of programming constructs. The characterization underlies a framework for documenting and manipulating design information to facilitate maintenance and reuse activities. They identify and describe the following categories of design decisions: composition and decomposition; encapsulation and interleaving; generalization and specialization; representation; data and procedures; and function and relation. The authors discuss how to recognize and represent design decisions.<<ETX>>

Requirements validation via automated natural language parsing

Object oriented analysis (OOA) has become a popular method for analyzing system requirements. Unfortunately however, none of the current versions of OOA have included a validation technique tailored to the object oriented approach. Most, instead, merely recommend document reviews without specifying what kinds of problems to look for. The paper explores the question by applying a natural language parser to a requirements document, extracting candidate objects, methods and associations, composing them into an object model diagram, and then comparing the results to those determined by manual OOA. To do this, we have adapted an automated natural language parser and used it to examine several high level specifications. The results indicate that with a modest amount of effort, our technique can give valuable feedback to the analyst. >

The use of domain knowledge in program understanding

Program understanding is an essential part of all software maintenance and enhancement activities. As currently practiced, program understanding consists mainly of code reading. The few automated understanding tools that are actually used in industry provide helpful but relatively shallow information, such as the line numbers on which variable names occur or the calling structure possible among system components. These tools rely on analyses driven by the nature of the programming language used. As such, they are adequate to answer questions concerning implementation details, so called what questions. They are severely limited, however, when trying to relate a system to its purpose or requirements, the why questions. Application programs solve real‐world problems. The part of the world with which a particular application is concerned is that applications domain. A model of an applications domain can serve as a supplement to programming‐language‐based analysis methods and tools. A domain model carries knowledge of domain boundaries, terminology, and possible architectures. This knowledge can help an analyst set expectations for program content. Moreover, a domain model can provide information on how domain concepts are related. This article discusses the role of domain knowledge in program understanding. It presents a method by which domain models, together with the results of programming‐language‐based analyses, can be used to answers both what and why questions. Representing the results of domain‐based program understanding is also important, and a variety of representation techniques are discussed. Although domain‐based understanding can be performed manually, automated tool support can guide discovery, reduce effort, improve consistency, and provide a repository of knowledge useful for downstream activities such as documentation, reengineering, and reuse. A tools framework for domain‐based program understanding, a dowser, is presented in which a variety of tools work together to make use of domain information to facilitate understanding. Experience with domain‐based program understanding methods and tools is presented in the form of a collection of case studies. After the case studies are described, our work on domain‐based program understanding is compared with that of other researchers working in this area. The paper concludes with a discussion of the issues raised by domain‐based understanding and directions for future work.

Reducing Ambiguities in Requirements Specifications Via Automatically Created Object-Oriented Models

In industry, reviews and inspections are the primary methods to identify ambiguities, inconsistencies, and under specifications in natural language (NL) software requirements specifications (SRSs). However, humans have difficulties identifying ambiguities and tend to overlook inconsistencies in a large NL SRS. This paper presents a three-step, semi-automatic method, supported by a prototype tool, for identifying inconsistencies and ambiguities in NL SRSs. The method combines the strengths of automation and human reasoning to overcome difficulties with reviews and inspections. First, the tool parses a NL SRS according to a constraining grammar. Second, from relationships exposed in the parse, the tool creates the classes, methods, variables, and associations of an object-oriented analysis model of the specified system. Third, the model is diagrammed so that a human reviewer can use the model to detect ambiguities and inconsistencies. Since a human finds the problems, the tool has to have neither perfect recall nor perfect precision. The effectiveness of the approach is demonstrated by applying it and the tool to a widely published example NL SRS. A separate study evaluates the tools domain-specific term detection.

Model-driven reverse engineering

Reverse engineering is the process of comprehending software and producing a model of it at a high abstraction level, suitable for documentation, maintenance, or reengineering. But from a managers viewpoint, there are two painful problems: 1) Its difficult or impossible to predict how much time reverse engineering will require. 2) There are no standards to evaluate the quality of the reverse engineering that the maintenance staff performs. Model-driven reverse engineering can overcome these difficulties. A model is a high-level representation of some aspect of a software system. MDRE uses the features of modeling technology but applies them differently to address the maintenance managers problems. Our approach to MDRE uses formal specification and automatic code generation to reverse the reverse-engineering process. Models written in a formal specification language called SLANG describe both the application domain and the program being reverse engineered, and interpretations annotate the connections between the two. The ability to generate a similar version of a program gives managers a fixed target for reverse engineering. This, in turn, enables better effort prediction and quality evaluation, reducing development risk.

On the knowledge required to understand a program

This paper is concerned with the units of knowledge used in understanding programs. A pilot study was conducted wherein a short, but complex, program was examined looking for knowledge atoms, the units from which program understanding is built. The resulting atoms were categorized along three orthogonal axes of knowledge type, design decision used, and the type of analysis required to uncover the atom. The results are discussed relative to several approaches to program understanding taken from the research literature.

MORALE. Mission ORiented Architectural Legacy Evolution

Software evolution is the most costly and time-consuming software development activity, yet software engineering research is predominantly concerned with initial development. MORALE is a development method specifically designed for evolving software. It features an inquiry-based approach to eliciting change requirements, a reverse engineering technique for extracting architectural information from existing code, an approach to impact assessment that determines the extent to which the existing systems architectural components can be reused in the evolved version, a reflective approach to actually perform the evolution, and a specific technique for dealing with the difficulties that arise when evolving user interfaces. MORALE is described in the context of making a specific change to an existing system: adding user-configurable viewers to Version 2.4 of the Mosaic Web browser. Issues that arise are discussed, and the Esprit de Corps tool-suite is described

Programming with idioms in APL

Idioms are programming language constructs characterized by frequency of occurrence, unity of purpose, ease of recognition, and composability of use. Due to APLs conciseness and functional orientation, the language contains a large vocabulary of idioms. This paper explores the phenomenon of idioms, discusses how they can be used in teaching programming and understanding programs, and includes numerous examples of their use in practical situations.

Understanding interleaved code

Complex programs often contain multiple, interwoven strands of computation, each responsible for accomplishing a distinct goal. The individual strands responsible for each goal are typically delocalized and overlap rather than being composed in a simple linear sequence. We refer to these code fragments as being interleaved. Interleaving may be intentional-for example, in optimizing a program, a programmer might use some intermediate result for several purposes-or it may creep into a program unintentionally, due to patches, quick fixes, or other hasty maintenance practices. To understand this phenomenon, we have looked at a variety of instances of interleaving in actual programs and have distilled characteristic features. This paper presents our characterization of interleaving and the implications it has for tools that detect certain classes of interleaving and extract the individual strands of computation. Our exploration of interleaving has been done in the context of a case study of a corpus of production mathematical software, written in Fortran from the Jet Propulsion Laboratory. This paper also describes our experiences in developing tools to detect specific classes of interleaving in this software, driven by the need to enhance a formal description of this software librarys components. The description, in turn aids in the automated component-based synthesis of software using the library.