Joseph E. Hollingsworth

Reasoning about Software-Component Behavior

The correctness of a component-based software system depends on the component client’s ability to reason about the behavior of the components that comprise the system, both in isolation and as composed. The soundness of such reasoning is dubious given the current state of the practice. Soundness is especially troublesome for component technologies where source code for some components is inherently unavailable to the client. Fortunately, there is a simple, understandable, teachable, practical, and provably sound and relatively complete reasoning system for component-based software systems that addresses the reasoning problem.

Developing a common format for sharing programming assignments

Computer science educators spend a lot of effort designing programming assignments, and many are willing to share the results of this investment. However, sharing of programming assignments occurs primarily in an ad hoc manner through informal channels. There are no widely used mechanisms that support instructors in finding and sharing such resources. Often, the additional work required to prepare and self-publish assignment resources in a way that others can then adapt or reuse is a significant inhibitor. Also, other instructors may have to spend an inordinate amount of time and effort to reshape a potential assignment into something that can be used in their own courses. This working group report proposes a common format for packaging assignments for sharing. This format is easy for instructors to create (requiring no specialized tools), is extensible and flexible enough to handle assignments written for any programming language at any level of proficiency, supports appropriate metadata, and is easily manipulated by software tools. As more and more instructors use automated grading tools to process student submissions, it is our hope that such an interchange format can lead to a community practice of sharing resources in a way that overcomes existing barriers to such reuse.

Toys are us: presenting mathematical concepts in CS1/CS2

Presentation and use of formally-specified software components in CS1/CS2 presents interesting pedagogical challenges. Specifications may involve unfamiliar mathematical concepts and notation. We have found that the use of toys, such as stacking plastic cups and Lego(C) blocks, to be amazingly effective in helping students develop mental models for mathematical concepts. With the aid of these mental models, students are able to understand the behavior of software components through cover stories (their specifications), without knowing the implementations of the components.

Specification and reasoning in SE projects using a Web IDE

A key goal of our research is to introduce an approach that involves at the outset using analytical reasoning as a method for developing high quality software. This paper summarizes our experiences in introducing mathematical reasoning and formal specification-based development using a web-integrated environment in an undergraduate software engineering course at two institutions at different levels, with the goal that they will serve as models for other educators. At Alabama, the reasoning topics are introduced over a two-week period and are followed by a project. At Clemson, the topics are covered in more depth over a five-week period and are followed by specification-based software development and reasoning assignments. The courses and project assignments have been offered for multiple semesters. Evaluation of student performance indicates that the learning goals were met.

Part III: implementing components in RESOLVE

The organization is as follows. First we present some example realization modules with little elaboration. Then we discuss many aspects of realization modules in general, using the examples for illustration. Finally, we give an overview of the basis for modular verification of the correctness of realizations. The focus throughout is on the software component engineering rationale for some slightly unusual language features.

The location linking concept: a basis for verification of code using pointers

While the use of pointers can be minimized by language mechanisms for data abstraction, alias avoidance and control, and disciplined software development techniques, ultimately, any verifying compiler effort must be able to verify code that makes use of them. Additionally, in order to scale, the verification machinery of such a compiler must use specifications to reason about components. This paper follows a natural question that arises from combining these ideas: can the general machinery of specification-based component verification also be used to verify code that uses instances of types that are more traditionally built-in, such as arrays and pointers? This paper answers the question in the affirmative by presenting a Location_Linking_Template, a concept that captures pointer behavior, and uses it to verify the code of a simple data abstraction realized using pointers. In this deployment, pointers have a specification like any other component. We also note that the concept can be extended and realized so that different systems can plug in alternative implementations to give programmers the flexibility to choose, e.g., manual memory management or automatic garbage collection depending on their performance concerns.

Teaching Mathematical Reasoning Principles for Software Correctness and Its Assessment

Undergraduate computer science students need to learn analytical reasoning skills to develop high-quality software and to understand why the software they develop works as specified. To accomplish this central educational objective, this article describes a systematic process of introducing reasoning skills into the curriculum and assessing how well students have learned those skills. To facilitate assessment, a comprehensive inventory of principles for reasoning about correctness that captures the finer details of basic skills that students need to learn has been defined and used. The principles can be taught at various levels of depth across the curriculum in a variety of courses. The use of a particular instructional process is illustrated to inculcate reasoning principles across several iterations of a sophomore-level development foundations course and a junior-level software engineering course. The article summarizes how learning outcomes motivated by the inventory of reasoning principles lead to questions that in turn form the basis for a careful analysis of student understanding and for fine-tuning teaching interventions that together facilitate continuous improvements to instruction.

Part IV: RESOLVE components in Ada and C++

Ada and C++, while superficially quite different from each other in many respects, are about equally well-suited (perhaps we should say poorly-suited) substitutes for the RESOLVE realization language. Each language has a number of interesting features that we simply do not use, because we do not know how to modularly reason about code that uses these features and/or because we do not need to use them to imitate RESOLVE realizations. The RESOLVE/Ada and RESOLVE/C++ disciplines — strictly followed — are therefore conservative: If you follow our advice then you should be able to reason modularly about your programs; if not, then you still might be able to reason modularly if you know what you are doing and why, and if you understand the pitfalls that can disturb modularity and avoid them even while violating the discipline.

Teaching mathematical reasoning across the curriculum

It is all too often the case that CS students learn concepts of mathematical reasoning in a required discrete math course, but fail to apply what they have learned to their CS courses. This may occur because the courses are taught in different departments with little communication between faculty members, so that different terminology may be used in the math course from what is used in the CS curriculum, making it seem as though these two areas are not connected. Even when discrete math faculty collaborate with CS course instructors, students may not carry over what they learned into their CS curriculum.

A systematic approach to teaching abstraction and mathematical modeling

The need for undergraduate CS students to create and understand mathematical abstractions is clear, yet these skills are rarely taught in a systematic manner, if they are taught at all. This paper presents a systematic approach to teaching abstraction using rigorous mathematical models and a web-based reasoning environment. It contains a series of representative examples with varying levels of sophistication to make it possible to teach the ideas in a variety of courses, such as introductory programming, data structures, and software engineering. We also present results from our experimentation with these ideas over a 3-year period at our institution in a required course that introduces object-based software development, following CS2.