Software architecture lies at the heart of system thinking skills for software. Teaching software architecture requires contending with the problem of how to make the learning realistic -- most systems which students can learn quickly are too simple for them to express architectural issues. We address here the ten years' history of teaching an undergraduate software architecture course, as a part of a bachelor's program in software engineering. Included are descriptions of what we perceive the realistic goals to be, of teaching software architecture at this level. We go on to analyze the successes and issues of various approaches we have taken over the years. We finish with recommendations for others who teach this same subject, either as a standalone undergraduate course or integrated into a software engineering course.

Novice programmers often learn programming by implementing well-known algorithms. There are several challenges in the process. Recommendation systems in software currently focus on programmer productivity and ease of development. Teaching aides for such novice programmers based on recommendation systems still remain an under-explored area. In this paper, we present a general framework for recognizing the desired target for partially-written code and recommending a reliable series of edits to transform the input program into the target solution. Our code analysis is based on graph matching and tree edit algorithms. Our experimental results show that efficient graph comparison techniques can accurately match two portions of source code and produce an accurate set of source code edits. We provide details on implementation of our framework, which is developed as a plugin for Java in Eclipse IDE.

Java objects are required to honor an equality contract in order to participate in standard collection data structures such as List, Set, and Map. In practice, the implementation of equality can be error prone, resulting in subtle bugs. We present a checker called EQ that is designed to automatically detect such equality implementation bugs. The key to EQ is the automated extraction of a logical model of equality from Java code, which is then checked, using Alloy Analyzer, for contract conformance. We have evaluated EQ on four open-source, production code bases in terms of both scalability and usefulness. We discuss in detail the detected problems, their root causes, and the reasons for false alarms.

Learning to use a software framework and its API (Application Programming Interfaces) can be a major endeavor for novices. To help, we have built a critic to advise the use of an API based on the formal semantics of the API. Specifically, the critic offers advice when the symbolic state of the API client code triggers any API usage rules. To assess to what extent our critic can help solve practical API usage problems and what kinds of API usage rules can be formulated, we manually analyzed 150 discussion threads from the Java Swing forum. We categorize the discussion threads according to how they can be helped by the critic. We find that API problems of the same nature appear repeatedly in the forum, and that API problems of the same nature can be addressed by implementing a new API usage rule for the critic. We characterize the set of discovered API usage rules as a whole. Unlike past empirical studies that focus on answering why frameworks and APIs are hard to learn, ours is the first designed to produce systematic data that have been directly used to build an API support tool.

It is well-known that APIs can be hard to learn and use. Although search tools can help find related code examples, API novices still face other significant challenges such as evaluating the relevance of the search results. To help address the broad problems of finding, understanding, and debugging API-based solutions, we have built a critic system that offers recommendations, explanations, and criticisms for API client code. Our critic takes API usage rules as input, performs symbolic execution to check that the client code has followed these rules properly, and generates advice as output to help improve the client code. We demonstrate our critic by applying it to a real-world example derived from the Java Swing Forum.

Objects in Object-Oriented languages such as Java are required to implement an equality predicate using the equals(Object) method in order to be compared with each other. This is particularly important when these objects interact with lists, sets, and maps from the Java Collection Framework. There are several considerations that must be taken in the implementation of this method, which, if ignored, will lead to subtle bugs. We present a tool called EQ that analyzes the source code to find such bugs.

Programmers encounter many difficulties in using an API to solve a programming task. To cope with these difficulties, they browse the Internet for code samples, tutorials, and API documentation. In general, it is time-consuming to find relevant help from the plethora of information on the web. While programmers can use search-based tools to help locate code snippets or applications that may be relevant to the APIs they are using, they still face the significant challenge of understanding and assessing the quality of the search results. We propose to investigate a proactive help system that is integrated in a development environment to provide contextual suggestions to the programmers as the code is being read and edited in the editor.

Scattered concerns, design features whose implementations span multiple program units, can pose extra difficulty for developers to locate, understand, modify, and extend. In particular, since successful application frameworks tend to be widely used by many developers, the impact of scattered concerns on framework usability can be especially significant. Ideally, every scattered concern present at the framework interface should be carefully evaluated to justify its introduction. If it cannot be avoided, it should at least be well-documented to facilitate its use. To gain insights into how scattered concerns are actually designed and documented in industrial frameworks, a method for documenting and evaluating scattered concerns is proposed, and a manual pilot study on the JFC swing JTree is performed. In this method, concerns are identified and documented in a structured manner, listing not only those items which an application must directly depend on, but other methods and classes that indirectly contribute to the design of a concern. The documented concerns are compared with the framework architecture in order to justify their existence. Concerns that map nicely to the architecture are deemed to be acceptable as they fit within the design and were explicitly traded off for other quality attributes. Those that show a mismatch indicate a place where the concern could cause problems for application developers, and thus should be either refactored or well-documented. Concerns are also evaluated using design criteria like cohesion and coupling. While it is not always possible to identify design flaws in a scattered concern, at the least, documenting these concerns will make them easier to use. The JTree study results in 12 concerns, 7 of which are missing or only partially documented in the official swing tutorial. 4 framework usability flaws are identified, which, if addressed, would lead to the removal of 2 of the 12 documented concerns and improvements to another 2. Thus, the proposed method has the potential to be useful to framework development teams.