The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architec-ture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements-- that is, the constraints on the elements. The ratio-nale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system:requirements. We discuss the compo-nents of the model in the context of both architectures and architectural styles and present an extended exam-ple to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, sum-marizing our contributions, and relating our approach to other current work.

Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest. The familiar software project, at least as seen by the nontechnical manager, has something of this character; it is usually innocent and straightforward, but is capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet--something to make software costs drop as rapidly as computer hardware costs do. But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity. In this article, I shall try to show why, by examining both the nature of the software problem and the properties of the bullets proposed. Skepticism is not pessimism, however. Although we see no startling breakthroughs--and indeed, I believe such to be inconsistent with the nature of software--many encouraging

The problems of designing large software systems were studied through interviewing personnel from 17 large projects. A layered behavioral model is used to analyze how three lgf these problems-the thin spread of application domain knowledge, fluctuating and conflicting requirements, and communication bottlenecks and breakdowns-affected software productivity and quality through their impact on cognitive, social, and organizational processes.

Agent-oriented techniques represent an exciting new means of analysing, designing and building complex software systems. They have the potential to significantly improve current practice in software engineering and to extend the range of applications that can feasibly be tackled. Yet, to date, there have been few serious attempts to cast agent systems as a software engineering paradigm. This paper seeks to rectify this omission. Specifically, it will be argued that: (i) the conceptual apparatus of agent-oriented systems is well-suited to building software solutions for complex systems and (ii) agent-oriented approaches represent a genuine advance over the current state of the art for engineering complex systems. Following on from this view, the major issues raised by adopting an agent-oriented approach to software engineering are highlighted and discussed. 1.

Abstract not found

Scripting languages such as Perl and Tcl represent a very different style of programming than system programming languages such as C or JavaTM. Scripting languages are designed for "gluing " applications; they use typeless approaches to achieve a higher level of programming and more rapid application development than system programming languages. Increases in computer speed and changes in the application mix are making scripting languages more and more important for applications of the future.

Software reuse is the process ofcreating software systems from existing software rather than building software systems from scratch. ‘l’his simple yet powerful vision was introduced in 1968. Software reuse has, however, failed to become a standard software engineering practice. In an attempt to understand why, researchers have renewed their interest in software reuse and in the obstacles to implementing it. This paper surveys the different approaches to software reuse found in the research literature. It uses a taxonomy to describe and compare the different approaches and make generalizations about the field of software reuse. The taxonomy characterizes each reuse approach interms of its reusable artifacts and the way these artifacts are abstracted, selected, speciahzed, and integrated. Abstraction plays a central role in software reuse. Concise and expressive abstractions are essential if software artifacts are to be effectively reused. The effectiveness of a reuse technique can be evaluatedin terms of cognztzue dwtance-an intuitive gauge of the intellectual effort required to use the technique. Cognitive distance isreduced in two ways: (l) Higher level abstractions ina reuse technique

Studying the design and implementation of a number of computer has led to some general hints for system design. They are described here and illustrated by many examples, ranging from hardware such as the Alto and the Dorado to application programs such as Bravo and Star. 1.

This paper surveys the design of embedded computer systems, which use software running on programmable computers to im-plement system functions. Creating an embedded computer system which meets its performance, cost, and design time goals is a hardware-software co-design problewhe design of the hard-ware and software components influence each other. This paper emphasizes a historical approach to show the relationships be-tween well-understood design problems and the as-yet unsolved problems in co-design. We describe the relationship between hard-ware and sofhvare architecture in the early stages of embedded system design. We describe analysis techniques for hardware and software relevant to the architectural choices required for hard-ware-software co-design. We also describe design and synthesis techniques for co-design and related problems.

AbstractÐWhile empirical studies in software engineering are beginning to gain recognition in the research community, this subarea is also entering a new level of maturity by beginning to address the human aspects of software development. This added focus has added a new layer of complexity to an already challenging area of research. Along with new research questions, new research methods are needed to study nontechnical aspects of software engineering. In many other disciplines, qualitative research methods have been developed and are commonly used to handle the complexity of issues involving human behavior. This paper presents several qualitative methods for data collection and analysis and describes them in terms of how they might be incorporated into empirical studies of software engineering, in particular how they might be combined with quantitative methods. To illustrate this use of qualitative methods, examples from real software engineering studies are used throughout.