The mid-1990s saw the design of programming languages for software architectures, which define the high-level aspects of software systems including how code components were composed to form full systems. Our paperAbstractions for Software Architecture and Tools to Support Thempresented a conceptual view of software architecture based on abstractions used in practice to organize software systems, a language that supported these abstractions, and a prototype implementation of this language (Shaw et al., 1995). By invitation, we reflect on the paper’s principal ideas about system-level abstractions, place the work in a historical context of steadily increasing abstraction power in software development languages and infrastructure, and reflect on how progress since the paper’s 1995 publication has been influenced, directly or indirectly, by this work. We describe current manifestations of architectural ideas and current challenges. We suggest how the strategy we used to identify and reify architectural abstractions may apply to current opportunities.

Social media provide a steady diet of dire warnings that artificial intelligence (AI) will make software engineering (SE) irrelevant or obsolete. To the contrary, the engineering discipline of software is rich and robust; it encompasses the full scope of software design, development, deployment, and practical use; and it has regularly assimilated radical new offerings from AI. Current AI innovations such as machine learning, large language models (LLMs) and generative AI will offer new opportunities to extend the models and methods of SE. They may automate some routine development processes, and they will bring new kinds of components and architectures. If we're fortunate they may force SE to rethink what we mean by correctness and reliability. They will not, however, render SE irrelevant.

The Software Engineering Body of Knowledge (SWEBOK), published in 2004, and now under revision, has influenced many software engineering graduate programs worldwide. In 2009, guidelines were published for graduate programs in software engineering (GSWE2009). GSWE2009, now sponsored by both the IEEE Computer Society and the Association for Computing Machinery, strongly rely on the SWEBOK but also recommends specific systems engineering knowledge for students to master. Today, an international team is creating a rigorous Systems Engineering Body of Knowledge (SEBoK) with the help of the IEEE Computer Society and the International Council on Systems Engineering and other professional societies. As it matures, the SEBoK should influence future versions of GSWE2009 and graduate program curricula worldwide. This panel will examine the influence of bodies of knowledge on both the creation of new graduate software engineering programs and the evolution of existing ones.

Software Architecture emerged in the 1990's as an important sub-field of software engineering. While good architectural design had long been recognized as critical to the success of any complex software system, before then the practice of architecting had relied largely on ad hoc, uncodified, and idiosyncratic techniques and knowledge. By the 2000's the field had matured to the point where there were widely-recognized taxonomies of architectural patterns, techniques for formally representing and analyzing architectures, methods for reviewing an architectural design, widespread adoption of architectural product lines and composition frameworks, and techniques for ensuring conformance between an architecture and an implementation of it. In this talk we reflect on the key enablers of a discipline of software architecture that led to these advances, the central ideas that form its core, and its enduring principles that continue to shape the field of software engineering. We consider both the important concepts on which it builds, as well as those that have built on top of it. Finally, we examine some of the important new trends and challenges that are likely to have an impact on how software architecture will evolve in the future.

When users combine data from multiple sources into a spreadsheet or dataset, the result is often a mishmash of different formats, since phone numbers, dates, course numbers and other string-like kinds of data can each be written in many different formats. Although spreadsheets provide features for reformatting numbers and a few specific kinds of string data, they do not provide any support for the wide range of other kinds of string data encountered by users. We describe a user interface where a user can describe the formats of each kind of data. We provide an algorithm that uses these formats to automatically generate reformatting rules that transform strings from one format to another. In effect, our system enables users to create a small expert system called a "tope" that can recognize and reformat instances of one kind of data. Later, as the user is working with a spreadsheet, our system recommends appropriate topes for validating and reformatting the data. With a recall of over 80% for a query time of under 1 second, this algorithm is accurate enough and fast enough to make useful recommendations in an interactive setting. A laboratory experiment shows that compared to manual typing, users can reformat sample spreadsheet data more than twice as fast by creating and using topes.

The conventional wisdom of software engineering holds that software systems are developed by software professionals, that they have knowable (if evolving) requirements, that project managers control system configurations, that results can be computed directly, and that the systems can, at least in principle, be validated.

Repositories of code written by end-user programmers are beginning to emerge, but when a piece of code is new or nobody has yet reused it, then current repositories provide users with no information about whether that code might be appropriate for reuse. Addressing this problem requires predicting reusability based on information that exists when a script is created. To provide such a model for web macro scripts, we identified script traits that might plausibly predict reuse, then used IBM CoScripter repository logs to statistically test how well each corresponded to reuse. We then built a machine learning model that combines the useful traits and evaluated how well it can predict four different types of reuse that we saw in the repository logs. Our model was able to predict reuse from a surprisingly small set of traits. It is simple enough to be explained in only 6-11 rules, making it potentially viable for integration in repository search engines for end-user programmers.

No abstract available.

Programmers often omit input validation when inputs can appear in many different formats or when validation criteria cannot be precisely specified. To enable validation in these situations, we present a new technique that puts valid inputs into a consistent format and that identifies "questionable" inputs which might be valid or invalid, so that these values can be double-checked by a person or a program. Our technique relies on the concept of a "tope", which is an application-independent abstraction describing how to recognize and transform values in a category of data. We present our definition of topes and describe a development environment that supports the implementation and use of topes. Experiments with web application and spreadsheet data indicate that using our technique improves the accuracy and reusability of validation code and also improves the effectiveness of subsequent data cleaning such as duplicate identification.

End-user programming tools for creating spreadsheets and webforms offer no data types except "string" for storing many kinds of data, such as person names and street addresses. Consequently, these tools cannot automatically validate these data.

Quantitatively-based risk management can reduce the risks associated with field defects for both software producers and software consumers. In this paper, we report experiences and results from initiating risk-management activities at a large systems development organization. The initiated activities aim to improve product testing (system/integration testing), to improve maintenance resource allocation, and to plan for future process improvements. The experiences we report address practical issues not commonly addressed in research studies: how to select an appropriate modeling method for product testing prioritization and process improvement planning, how to evaluate accuracy of predictions across multiple releases in time, and how to conduct analysis with incomplete information. In addition, we report initial empirical results for two systems with 13 and 15 releases. We present prioritization of configurations to guide product testing, field defect predictions within the first year of deployment to aid maintenance resource allocation, and important predictors across both systems to guide process improvement planning. Our results and experiences are steps towards quantitatively-based risk management.

Information workers such as administrative staff, consultants, and their managers constitute one of the largest groups of end users, yet little research about their usage of programming features is available to guide development of end user programming tools. In this paper, we describe our survey of over 800 information workers and our analysis of their feature usage in applications such as spreadsheets, browsers, and databases. Our factor analysis reveals three clusters of features - macro features, linked structure features, and imperative features - such that information workers with an inclination to use a feature in each cluster also were inclined to use other features in that cluster, even though each cluster spans several tools. We discuss the implications for research aimed at providing end user programming tools for information workers

An important domain for autonomic systems is the area of ubiquitous computing: users are increasingly surrounded by technology that is heterogeneous, pervasive, and variable. In this paper we describe our work in developing self-adapting computing infrastructure that automates the configuration and reconfiguration of such environments. Focusing on the engineering issues of self-adaptation in the presence of heterogeneous platforms, legacy applications, mobile users, and resource variable environments, we describe a new approach based on the following key ideas: 1) explicit representation of user tasks allows us to determine what service qualities are required of a given configuration; 2) decoupling task and preference specification from the lower level mechanisms that carry out those preferences provides a clean engineering separation of concerns between what is needed and how it is carried out; and 3) efficient algorithms allow us to calculate in real time near-optimal resource allocations and reallocations for a given task

Software has jumped "out of the box" - it controls critical systems; it pervades business and commerce; it is embedded in myriad mechanisms; it infuses entertainment, communication, and other activities of everyday life. Designs for these applications are constrained not only by traditional considerations of capability and performance but also by economic, business, market, and policy issues and the context of intended use. The diversity of applications requires adaptability in responding to client needs, and the diversity of clients and contexts requires the ability to discriminate among criteria for success.As a result, software designers must also get out of their boxes: in addition to mastering traditional software development skills, they must understand the contextual issues that discriminate good solutions from merely competent ones. Current software engineering education, however, remains largely "in the box": it neglects the rich fabric of issues that lie between the client's problem and actual software development. At Carnegie Mellon we have addressed this major shortcoming with a course that teaches students to understand both the capabilities required by the client and the constraints imposed by the client's context.This paper presents our view of the engineering character of software engineering, describes the content and organization of our new course, reports on our experience from the first three offerings of our course, and suggests ways to adapt our course for other educational settings.

Open source software systems are critical infrastructure for many applications; however, little has been precisely measured about their quality. Forecasting the field defect-occurrence rate over the entire lifespan of a release before deployment for open source software systems may enable informed decision-making. In this paper, we present an empirical case study often releases of OpenBSD. We use the novel approach of predicting model parameters of software reliability growth models (SRGMs) using metrics-based modeling methods. We consider three SRGMs, seven metrics-based prediction methods, and two different sets of predictors. Our results show that accurate field defect-occurrence rate forecasts are possible for OpenBSD, as measured by the Theil forecasting statistic. We identify the SRGM that produces the most accurate forecasts and subjectively determine the preferred metrics-based prediction method and set of predictors. Our findings are steps towards managing the risks associated with field defects

In 1995, Boehm predicted that by 2005, there would be "55 million performers" of "end user programming" in the United States. The original context and method which generated this number had two weaknesses, both of which we address. First, it relies on undocumented, judgment-based factors to estimate the number of end user programmers based on the total number of end users; we address this weakness by identifying specific end user sub-populations and then estimating their sizes. Second, Boehm's estimate relies on additional undocumented, judgment-based factors to adjust for rising computer usage rates; we address this weakness by integrating fresh Bureau of Labor Statistics (BLS) data and projections as well as a richer estimation method. With these improvements to Boehm's method, we estimate that in 2012 there will be 90 million end users in American workplaces. Of these, we anticipate that over 55 million will use spreadsheets or databases (and therefore may potentially program), while over 13 million will describe themselves as programmers, compared to BLS projections of fewer than 3 million professional programmers. We have validated our improved method by generating estimates for 2001 and 2003, then verifying that our estimates are consistent with existing estimates from other sources.

Good research ideas often arise from critical observation of inconsistencies between researchers’ assumptions about software development and practical reality. This dissonance creates a kind of friction that can spark research ideas. This is the text for the Stevens Award Lecture on November 8, 2005. The Stevens Award was created to recognize outstanding contributions to the literature or practice of methods for software and systems development.

In the software architecture education session, we discussed four main issues: how to make a software architecture course sufficiently realistic, how to teach non-technical competencies of software architects, the place of such a course in a university curriculum, and how to grow software architects beyond the university. The session resulted in a first sketch of software architecture knowledge areas, and the extent to which these are deemed required for certain classes of software professionals.

An important emerging requirement for computing systems is the ability to adapt at run time, taking advantage of local computing devices, and coping with dynamically changing resources. Three specific technical challenges in satisfying this requirement are to (1) select an appropriate set of applications or services to carry out a user's task, (2) allocate (possibly scarce) resources among those applications, and (3) reconfigure the applications or resource assignments if the situation changes. In this paper, we show how to provide a shared infrastructure that automates configuration decisions given a specification of the user's task. The heart of the approach is an analytical model and an efficient algorithm that can be used at run time to make near-optimal (re)configuration decisions. We validate this approach both analytically and by applying it to a representative scenario.

Defect-occurrence projection is necessary for the development of methods to mitigate the risks of software defect occurrences. In this paper, we examine user-reported software defect-occurrence patterns across twenty-two releases of four widely-deployed, business-critical, production, software systems: a commercial operating system, a commercial middleware system, an open source operating system (OpenBSD), and an open source middleware system (Tomcat). We evaluate the suitability of common defect-occurrence models by first assessing the match between characteristics of widely-deployed production software systems and model structures. We then evaluate how well the models fit real world data. We find that the Weibull model is flexible enough to capture defectoccurrence behavior across a wide range of systems. It provides the best model fit in 16 out of the 22 releases. We then evaluate the ability of the moving averages and the exponential smoothing methods to extrapolate Weibull model parameters using fitted model parameters from historical releases. Our results show that in 50% of our forecasting experiments, these two naïve parameter-extrapolation methods produce projections that are worse than the projection from using the same model parameters as the most recent release. These findings establish the need for further research on parameter-extrapolation methods that take into account variations in characteristics of widely-deployed, production, software systems across multiple releases.

Software engineering researchers solve problems of several different kinds. To do so, they produce several different kinds of results, and they should develop appropriate evidence to validate these results. They often report their research in conference papers. I analyzed the abstracts of research papers submitted to XSE 2002 in order to identify the types of research reported in the submitted and accepted papers, and I observed the program committee discussions about which papers to accept. This report presents the research paradigms of the papers, common concerns of the program committee, and statistics on success rates. This information should help researchers design better research projects and write papers that present their results to best advantage.

Much of the software we use for everyday purposes incorporates elements developed and maintained by someone other than the developer. These elements include not only code and databases but also dynamic data feeds from online data sources. Although everyday software is not mission critical, it must be dependable enough for practical use. This is limited by the dependability of the incorporated elements.It is particularly difficult to evaluate the dependability of dynamic data feeds, because they may be changed by their proprietors as they are used. Further, the specifications of these data feeds are often even sketchier than the specifications of software components.We demonstrate a method of inferring invariants about the normal behavior of dynamic data feeds. We use these invariants as proxies for specifications to perform on-going detection of anomalies in the data feed. We show the feasibility of our approach and demonstrate its usefulness for semantic anomaly detection: identifying occasions when a dynamic data feed is delivering unreasonable values, even though its behavior may be superficially acceptable (i.e., it is delivering parsable results in a timely fashion).

Over the past decade, software architecture research has emerged as the principled study of the overall structure of software systems, especially the relations among subsystems and components. From its roots in qualitative descriptions of useful system organizations, software architecture has matured to encompass broad explorations of notations, tools, and analysis techniques. Whereas initially the research area interpreted software practice, it now offers concrete guidance for complex software design and development. We can understand the evolution and prospects of software architecture research by examining the research paradigms used to establish its results. These are, for the most part, the paradigms of software engineering. We advance our fundamental understanding by posing research questions of several kinds and applying appropriate research techniques, which differ from one type of problem to another, yield correspondingly different kinds of results, and require different methods of validation. Unfortunately, these paradigms are not recognized explicitly and are often not carried out correctly; indeed not all are consistently accepted as valid. This retrospective on a decade-plus of software architecture research examines the maturation of the software architecture research area by tracing the types of research questions and techniques used at various stages. We will see how early qualitative results set the stage for later precision, formality, and automation and how results build up over time. This generates advice to the field and projections about future impact.

Summary form only given, as follows. The complete presentation was not made available for publication as part of the conference proceedings. Modern computing technology is creating a growing infrastructure for high performance, nearly ubiquitous computing and communication. This infrastructure extends the reach of computation and information beyond the traditional framework of a computer application running on a fixed set of machines. The architectures that suffice for such traditional software do not address the challenges of highly distributed, dynamically reconfigured software systems that depend on resources controlled by someone other than the developer. I will discuss the architectural challenges of this new setting, describe some promising approaches to handling those challenges, and suggest some research strategies for exploring and developing solutions.

Software component consumers are entitled to trusted components. This panel addresses the criteria for trusted components and presents generally accepted definitions for all terms used to describe both software components and the methods and processes required to verify trusted software components.

Software architects use a number of commonly-recognized "styles" to guide their design of system structures. Each of these is appropriate for some classes of problems, but none is suitable for all problems. How, then, does a software designer choose an architecture suitable for the problem at hand? Two kinds of information are required: (1) careful discrimination among the candidate architectures and (2) design guidance on how to make appropriate choices. In this paper, we support careful discrimination with a preliminary classification of styles. We use a 2D classification strategy with control and data issues as the dominant organizing axes. We position the major styles within this space and use finer-grained discriminations to elaborate variations on the styles. This provides a framework for organizing design guidance, which we partially flesh out with rules of thumb.

Software often evolves from batch to interactive use.Because these two usage styles are so different, batch systems usually require substantial changes to support interactive use.Specific issues that arise during conversion include assumptions about duration of system execution, incremental and partial processing, scope of processing, unordered and repeated processing, and error handling.Addressing these issues affects the implementation in the areas of memory management, assumptions and invariants, computational organization, and error handling.We use as a working example our conversion of the batch processor .for the UniCon architecture description tool into an interactive architecture development tool.To capture the lessons for practitioners undertaking this type of conversion, we summarize with a checklist of design and implementation considerations.

Architectures for software use rich abstractions and idioms to describe system components, the nature of interactions among the components, and the patterns that guide the composition of components into systems. These abstractions are higher level than the elements usually supported by programming languages and tools. They capture packaging and interaction issues as well as computational functionality. Well-established (if informal) patterns guide the architectural design of systems. We sketch a model for defining architectures and present an implementation of the basic level of that model. Our purpose is to support the abstractions used in practice by software designers. The implementation provides a testbed for experiments with a variety of system construction mechanisms. It distinguishes among different types of components and different ways these components can interact. It supports abstract interactions such as data flow and scheduling on the same footing as simple procedure call. It can express and check appropriate compatibility restrictions and configuration constraints. It accepts existing code as components, incurring no runtime overhead after initialization. It allows easy incorporation of specifications and associated analysis tools developed elsewhere. The implementation provides a base for extending the notation and validating the model.>

Architectures are the structuring paradigms, styles and patterns that make up our software systems.They are important in many ways: they allow us to talk usefully about systems without talking about their detail; a knowledge of them gives us design choices; attention to this level can make systems and families of systems have the non-functional properties we want, especially changeability.Each panelist will address the following issues: l What is architecture?l What is the value you have had so far from this concept?l What is the next step for you?l What is the next step for the community?

No abstract available.

Interactive user interfaces depend critically on underlying computing system facilities for input and output. However, most computing systems still have input-output facilities designed for batch processing. These facilities are not adequate for interfaces that rely on graphical output, interactive input, or software constructed with modern methodologies. This paper details the deficiencies of batch-style input-output for modern interactive systems, presents a new model for input-output that overcomes these deficiencies, and suggests software organizations to take advantage of the new model.

The nature of computing, and hence of computer science, is changing rapidly. Many topics that now seem interesting will be obsolete or irrelevant within ten years, and our perspective on other topics will change. If a curriculum designed now is to remain effective through 1990 or beyond, we must try to understand the forces that are shaping the field and to anticipate the roles that computing and computer science will play in the future.

No abstract available.

Abstract Four programming languages (Fortran, Cobol, Jovial and the proposed DoD standard) are compared in the light of modern ideas of good software engineering practice. The comparison begins by identifying a core for each language that captures the essential properties of the language and the intent of the language designers. These core languages then serve as a basis for the discussion of the language philosophies and the impact of the language on gross program organization and on the use of individual statements.

In this paper we study the problem of designing and specifying standard program components applicable to a wide variety of tasks; we choose for this study the specific problem domain of data structures for general searching problems. Within this domain Bentley and Saxe [1] have developed transformations for converting solutions of simple searching problems to solutions of more complex problems. We discuss one of those transformations, specify precisely the transformation and its conditions of applicability, and prove its correctness; we accomplish this by casting it in terms of abstract data types–specifically by using the Alphard form mechanism. The costs of the structures derived by this transformation are only slightly greater than the costs of the original structures, and the correctness of the transformation definition together with the correctness of the original structure assure the correctness of the derived structure. The transformation we describe has already been used to develop a number of new algorithms, and it represents a new level of generality in software engineering tools.

Mathematics has been called “the critical filter” for entrance into most scientific professions — a filter through which many female students do not pass and one which may also be screening out members of ethnic minorities. Changes in the mathematics pre-requisites for computer science courses form a major difference between Curriculum 78, the recommendations of the ACM Committee on Curriculum for the undergraduate program in computer sciences, and its predecessor, Curriculum 68.

Traditionally, the first two programming courses have emphasized basic techniques and skills—the details of a programming language, basic problem solving and program development, “structured programming”, the manipulation of simple data structures and files, basic sorting and searching algorithms, etc.

The programming language Alphard is designed to provide support for both the methodologies of "well-structured" programming and the techniques of formal program verification. Language constructs allow a programmer to isolate an abstraction, specifying its behavior publicly while localizing knowledge about its implementation. The verification of such an abstraction consists of showing that its implementation behaves in accordance with its public specifications; the abstraction can then be used with confidence in constructing other programs, and the verification of that use employs only the public specifications.

A family of new algorithms is given for evaluating the first m derivatives of a polynomial. In particular, it is shown that all derivatives may be evaluated in 3 n - 2 multiplications. The best previous result required 1/2 n ( n + 1) multiplications. Some optimality results are presented.