Traditionally, most work in program comprehension focuses on understanding the inner workings of software systems. However, for many software maintenance tasks, not only a sound understanding of a system's implementation but also comprehensive and accurate information about the way users actually use a system's features is of crucial importance. Such information e.g. helps to determine the impact that a specific change has on the users of a system. In practice, however, this information is often not available. We propose an approach called feature profiling as a means to efficiently gather usage information to support maintenance tasks that affect the user interface of a software system. Furthermore, we present tool support for feature profiling and report on a case study in the insurance domain. In this study, we profiled the features of an application that is used by 150 users in 10 countries over a period of five months.

Due to their pivotal role in software engineering, considerable effort is spent on the quality assurance of software requirements specifications. As they are mainly described in natural language, relatively few means of automated quality assessment exist. However, we found that clone detection, a technique widely applied to source code, is promising to assess one important quality aspect in an automated way, namely redundancy that stems from copy&paste operations. This paper describes a large-scale case study that applied clone detection to 28 requirements specifications with a total of 8,667 pages. We report on the amount of redundancy found in real-world specifications, discuss its nature as well as its consequences and evaluate in how far existing code clone detection approaches can be applied to assess the quality of requirements specifications in practice.

More than 20 years of research has created a large body of ideas, concepts, and theories for model-based development of embedded software-intensive systems. These approaches have been implemented by several tools and successfully applied to various development projects. However, the everyday use of model-based approaches in the automotive and avionic industries is still limited. Most of the time, the engineers work with a predefined set of isolated tools, and therefore adapt their engineering methods and process to the available tools. Today, the industry achieves tool integration by demand-driven, pragmatic, and ad-hoc composed chains of a priori existent commercial tools. Nevertheless, these tool chains are not (and cannot be) seamless, since the integration that can be achieved is not deep enough. This hampers the reuse and refinement of models, which subsequently leads to problems like redundancy, inconsistency, and lack of automation. In the end, these deficiencies decrease both the productivity and quality that could be provided by model-based approaches. To overcome these problems, a deep, coherent, and comprehensive integration of models and tools is required. Such an integration can be achieved by the following three ingredients: 1) a comprehensive modeling theory that serves as a semantic domain for the models, 2) an integrated architectural model that holistically describes the product and process, and 3) a manner to build tools that conform to the modeling theory and allow the authoring of the product model. We show that from a scientific point of view, all ingredients are at our hands to do a substantial step into an integrated process and tool world. Further, we illustrate why such a solution has not been achieved so far, and discuss what is to be done to get a step closer to seamless model-based engineering.

Architecture defines the components of a system and their dependencies. The knowledge about how the architecture is intended to be implemented is essential to keep the system structure coherent and thereby comprehensible. In practice, this architectural knowledge is explicitly formulated only in the documentation (if at all), which usually gets outdated very soon. This leads to a growing amount of implicit knowledge during evolution that is especially volatile in projects with high developer fluctuation. In this paper we present a case study about the loss of architectural knowledge in three industrial projects to answer the following research questions: 1) to what degree is the architectural documentation kept in conformance with the code? 2) how well does the documentation reflect the intended architecture?, 3) how big is the architectural decay?, and 4) what are the causes for nonconformances? We answer these questions by investigating the architecture documentation, the source code, and by performing interviews with developers. The most important outcomes of our study are: the informal documentation and the source code are not kept in conformance with each other, none of them completely reflects the intended architecture, and even developers taken individually are not completely aware of the intended architecture. Quantitatively, between 70% and 90% of these nonconformances are caused by flaws in the documentation and between 10% and 30% represent architectural violations in the code.

Libraries are the most widespreaded form of software reuse. In order to properly use a library API, its clients should fulfill a series of (many times implicit) assumptions made by the API programmers. Failing to fulfill these assumptions leads to a misuse of the library and thereby to defects in the client's code. In this paper we present a method for checking a well-behaved usage of an API through a set of context-sensitive syntactic constraints over the API clients. These constraints restrict the set of programs that can be written with an API only to programs that fulfill the API assumptions and thereby represent a well-behaved and valid usage of the API. In this paper we present a set of typical assumption classes made by API providers about their clients. We define a framework for formalizing the context- sensitive constraints over the API client code and propose a typical constraint for each class of assumptions. Thereby we provide a mechanism that allows the provider of an API to describe the knowledge of how an API is intended to be used in an automatically checkable form. We present our experience with parts of the Java Standard APIs.