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.

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

Abstract: Software architecture is one of the most important tools for designing and understanding a system, whether that system is in preliminary design, active deployment, or maintenance. Scenarios are important tools for exercising an architecture in order to gain information about a system’s fitness with respect to a set of desired quality attributes. This paper presents an experiential case study illustrating the methodological use of scenarios to gain architecture-level understanding and predictive insight into large, real-world systems in various domains. A structured method for scenario-based architectural analysis is presented, using scenarios to analyze architectures with respect to achieving quality attributes. Finally, lessons and morals are presented, drawn from the growing body of experience in applying scenario-based architectural analysis techniques.

Maintenance tends to degrade the structure of software, ultimately making maintenance more costly. At times, then, it is worthwhile to manipulate the structure of a system to make changes easier. However, it is shown that manual restructuring is an error-prone and expensive activity. By separating structural manipulations from other maintenance activities, the semantics of a system can be held constant by a tool, assuring that no errors are introduced by restructuring. To allow the maintenance team to focus on the aspects of restructuring and maintenance requiring human judgment, a transformation-based tool can be provided---based on a model that exploits preserving data flow-dependence and control flow-dependence---to automate the repetitive, errorprone, and computationally demanding aspects of re...

Software engineering research has focused mainly on software construction and has neglected software maintenance and evolution. Proposed is a shift in research from synthesis to analysis. Reverse engineering is introduced as a possible solution to program understanding and software analysis. Presented is reverse engineering technology developed as part of the Rigi project. The Rigi approach involves the identification of software artifacts in the subject system and the aggregation of these artifacts to form more abstract architectural models. Reported are some analyses on the source code of SQL/DS, performed by the authors while visiting the Program Understanding project at the IBM Centre for Advanced Studies in Toronto.

To help us identify and focus on pragmatic and concrete issues related to the role of software architecture in the design and development of large systems, we conducted a survey of a variety of software systems used in industrial applications. Our premise, which guided the examination of these systems, was that software architecture is concerned with capturing the structures of a system and the relationships among the elements both within and between structures. The structures we found fell into several broad categories: conceptual structure, module structure, code structure, and execution structure. These categories address different engineering concerns. The separation of such concerns, combined with specialized implementation techniques, decreased the complexity of implementation, and improved reuse and reconfiguration. We observed that in practice, software architecture played an important role throughout the development process: specification, design, functional decompo...

An important goal in software engineering is to describe complex software systems at an architectural level of abstraction. While there are many useful architectural paradigms (pipes, blackboards, etc.) they are typically understood only idiomatically and applied in an ad hoc fashion. We show how a formal model allows us to say precisely what we mean by a software architecture, explore its properties, and systematically describe instances of the architecture. We illustrate the approach using the well-known example of pipe-filter architectures. This research was sponsored by the National Science Foundation under Grants CCR-9109469 and CCR-9112880, and by Siemens Corporate Research, Inc. The views and conclusions contained in this document are those of the author and should not be interpreted as representing the official policies, either expressed or implied, of Siemens or the U.S. Government. Keywords: Dataflow Systems, Pipes and Filters, Software Architecture, Software Engineering, S...

Factory Design Pattern Handbook of Software Engineering and Knowledge Engineering 7 view provided a focus for the system's stakeholders in determining division of labor, testing, integration, and maintenance. 3.1.4. Concurrency View When a complex system is deployed, it is typically packaged into a set of processes or threads which are deployed onto some computational resources. The concurrency view is a necessary step for reasoning about what processes or threads will be created and how they will communicate and share (or compete for) resources. So the components of this view---processes and threads---interact with each other via data flow, events, and synchronization on shared resources. The users of this view are people who worry about deploying the system, who are concerned with the performance and availability of the system, as well as integrators and testers. This view is used to reason about performance, availability, and deployment. An example of a concurrency view is giv...

As the size and complexity of software systems increases, the design and specification of overall system structure -- or software architecture -- emerges as a central concern. Architectural issues include the gross organization of the system, protocols for communication and data access, assignmentof functionality to design elements, and selection among design alternatives. Currently system designers have at their disposal two primary ways of defining software architecture: they can use the modularization facilities of existing programming languages and module interconnection languages; or they can describe their designs using informal diagrams and idiomatic phrases (such as "client-server organization"). In this paper we explain why neither alternative is adequate. We consider the nature of architectural description as it is performed informally by systems designers. Then we show that regularities in these descriptions can form the basis for architectural description languages. Next we ...

Abstract not found