IBM R&D Labs in Israel

Abstract: The proposal that software development should be a profession modeled on the engineering disciplines was widely discussed in the 1960s. At that time, most computer scientists had been trained as physical scientists or mathematicians. Engineers developed the hardware but left the software development to others (computer users). Many of the scientists and mathematicians who were developing software realized that their job was more like engineering than science. They had been taught to create and organize knowledge, but software development was producing tools that they (and others) would use. This talk "takes stock" of the progress since that time and identifies what remains to be done.

Computers today can perform services that were unimaginable in the '60s. However, many problems remain. Software products commonly have a number of "bugs" and other problems that we would not accept in a physical product. A close look shows that many of the notable advances are made possible by improvements in hardware, not improvements in the way we construct software.

Three things that are considered essential for a mature profession are missing in software development:

• Rigid entrance standards for the profession
• Education that prepares students to meet those standards
• Professional documentation standards similar to those used in other engineering disciplines

The least discussed of these three topics is documentation. It is viewed as a nontechnical skill that is not a suitable subject for research for computer scientists. The talk shows how we can use structured mathematical notation to provide precise documentation that is demonstrably complete, and unusually useful to developers, reviewers, and maintainers. It then makes some suggestions for turning software development into a mature engineering profession.

Abstract: We present a views specification language, which we call ArcV, for the structure of component and connector architectures. ArcV views are under-specified, partial models, which serve to represent the concerns of interest of and the incomplete knowledge about the structure of the system available to different stakeholders involved in the system development process. As such, they provide several powerful means for abstraction and may cross-cut the hierarchical, implementation-oriented decomposition of systems to sub-systems. An ArcV specification consists of a Boolean expression over ArcV views, allowing one to specify, e.g., positive views, which should be satisfied; negative ones, which should not be satisfied; disjunctions, to allow one to express alternative designs; and implications, to allow one to express dependencies between design decisions.

We define and solve two problems for ArcV: formal verification and synthesis. Examples and a prototype implementation demonstrate the usefulness of ArcV and its unique contribution to the state-of-the-art and practice in the formal specification and analysis of software architectures.

Additional details are available here:
http://www.se-rwth.de/materials/arcv/
http://www.se-rwth.de/materials/arcvsynth/

Abstract: Software systems are becoming more and more complex. However, to maintain competitiveness, there is constant pressure to reduce the cost associated with developing such systems. One way of preserving quality while reducing cost is to optimize the testing process. We propose an automated mechanism for identifying the more error-prone components, so that the limited available testing resources can be mostly allocated for these components during early testing phases. The problem of software error-proneness has been extensively explored by Ostrand and Weyuker. Our work investigates one of the major questions Ostrand and Weyuker raise - persistence and distribution of faults. Our work both corroborates their findings on new, significantly larger and diverse data, and extends their line of research as follows. We study new statistical techniques. These techniques require less data to derive similar results. We find that the same analyses are applicable not only to defect data but also to code additions. We extend the analyses to the software component level. This is in contrast to the focus on files by Ostrand and Weyuker. Analysis at the level of le aggregations is important for practitioners because it makes it possible to identify the people who should act upon it (component owners).

Abstract: In behavioral programming, scenarios are used to program the behavior of reactive systems. Behavioral programming originated in the language of live sequence charts (LSC), a visual formalism based on multi-modal scenarios, and supported by a mechanism for directly executing a system described by a set of LSCs. In an exploratory experiment, we compare programming using LSCs with procedural programming using Java, and seek the best interface for creating the visual artifact of LSCs. Several interfaces for creating LSCs were tested, among them a novel interactive natural language interface (NL). Our preliminary results indicate that even experts in procedural programming preferred the LSCs NL interface over the Java alternative, and their implementation times were comparable to those of the other interfaces tested. The results indicate that the NL interface, combined with the scenario-based essence of LSCs, may be a viable alternative to conventional programming. Note: to appear in VL/HCC 2012.

Abstract: Modern Q&A websites, such as Stack Overflow, use social media to provide concise answers, and offer rich technical context with quality assessment capabilities. Although some of the answers may include executable code snippets, they are entangled in free text and are not easily extracted. Q&A websites are not designed for such direct code reuse.

We present Example Overflow, a code search and recommendation tool which brings together social media and code recommendation systems. Example Overflow enables crowd-sourced software development by utilizing both textual and social information, which accompany source code on the Web. Its browsing mechanism minimizes the context switch associated with other code search tools. In this paper, we describe the development of the tool, provide preliminary evaluation, and discuss its contribution to an example centric programming paradigm.

Abstract: We present a decentralized-control methodology and a tool set for developing interactive user interfaces. We focus on the common case of developing the client side of Web applications. Our approach is to combine visual programming using Google Blockly with a single-threaded implementation of behavioral programming in JavaScript. We show how the behavioral programming (BP) principles can be implemented with minimal programming resources, i.e., with a single-threaded environment using coroutines. We give examples of how BP is instrumental in addressing common issues in this application domain, e.g., that it facilitates separation of graphical representation from logic and handling of complex inter-object scenarios. The implementation in JavaScript and Blockly expands the availability of BP capabilities, previously implemented in LSC, Java, Erlang, and C++, to audiences with different skill sets and design approaches.

Abstract: Most people now agree that "software engineering" should take its rightful place among the established engineering disciplines such as civil engineering and electrical engineering. However, most would also agree that we are not there yet. This panel addresses the question: What do we need to change to give software engineering the status and recognition of other engineering disciplines?

We asked each of the panelists to focus their opening presentations on the following points:

• Are there different types of software engineering, or even software engineers?
• How has this changed in the past 40 years?
• How is software engineering similar to established engineering disciplines? How is it different?
• Which differences are beneficial and which detrimental?
• What are the qualities we would like software engineering to have so it could be seen as a true engineering discipline?
• What are the qualities we would like software engineers to have?
• What can be done to the theory, practice, and education of software engineering to bring it those qualities?