Fluent Essays

Read the article carefully and then answer the 2 questions An Introduction to Software Architecture David Garlan and Mary Shaw January 1994 CMU-CS-94-166 School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213-3890 Also published as “An Introduction to Software Architecture,” Advances in Software Engineering and Knowledge Engineering, Volume I, edited by V.Ambriola and G.Tortora, World Scientific Publishing Company, New Jersey, 1993. Also appears as CMU Software Engineering Institute Technical Report CMU/SEI-94-TR-21, ESC-TR-94-21. ©1994 by David Garlan and Mary Shaw This work was funded in part by the Department of Defense Advanced Research Project Agency under grant MDA972-92-J-1002, by National Science Foundation Grants CCR-9109469 and CCR-9112880, and by a grant from Siemens Corporate Research. It was also funded in part by the Carnegie Mellon University School of Computer Science and Software Engineering Institute (which is sponsored by the U.S. Department of Defense). The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the U.S. Government, the Department of Defense, the National Science Foundation, Siemens Corporation, or Carnegie Mellon University. Keywords: Software architecture, software design, software engineering Abstract As the size of software systems increases, the algorithms and data structures of the computation no longer constitute the major design problems. When systems are constructed from many components, the organization of the overall system—the software architecture—presents a new set of design problems. This level of design has been addressed in a number of ways including informal diagrams and descriptive terms, module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. In this paper we provide an introduction to the emerging field of software architecture. We begin by considering a number of common architectural styles upon which many systems are currently based and show how different styles can be combined in a single design. Then we present six case studies to illustrate how architectural representations can improve our understanding of complex software systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions. Contents 1. Introduction ..................................................................................................... 2 2. From Programming Languages to Software Architecture ..................... 3 2.1. High-level Programming Languages ................................................................... 3 2.2. Abstract Data Types........................................................................................... 4 2.3. Software Architecture ........................................................................................ 4 3. Common Architectural Styles...................................................................... 5 3.1. Pipes and Filters ................................................................................................ 6 3.2. Data Abstraction and Object-Oriented Organization ........................................... 8 3.3. Event-based, Implicit Invocation ........................................................................ 9 3.4. Layered Systems ................................................................................................ 11 3.5. Repositories ....................................................................................................... 12 3.6. Table Driven Interpreters ................................................................................... 13 3.7. Other Familiar Architectures............................................................................. 14 3.8. Heterogeneous Architectures............................................................................... 15 4. Case Studies ...................................................................................................... 16 4.1. Case Study 1: Key Word in Context ..................................................................... 16 4.2. Case Study 2: Instrumentation Software .............................................................. 22 4.3. Case 3: A Fresh View of Compilers ..................................................................... 26 4.4. Case 4: A Layered Design with Different Styles for the Layers ........................... 28 4.5. Case 5: An Interpreter Using Different Idioms for the Components ........................ 30 4.6. Case 6: A Blackboard Globally Recast as Interpreter ........................................... 33 5. Past, Present, and Future ............................................................................... 36 Acknowledgements .................................................................................................... 37 Bibliography ................................................................................................................. 37 Garlan & Shaw: An Introduction to Software Architecture 1 List of Figures 1 Pipes and Filters ....................................................................................................... 7 2 Abstract Data Types and Objects............................................................................ 8 3 Layered Systems ..................................................................................................... 11 4 The Blackboard ....................................................................................................... 13 5 Interpreter................................................................................................................ 14 6 KWIC - Shared Data Solution ............................................................................. 18 7 KWIC - Abstract Data Type Solution ................................................................. 19 8 KWIC - Implicit Invocation Solution ............................................................... 20 9 KWIC - Pipe and Filter Solution ........................................................................ 20 10 KWIC - Comparison of Solutions ...................................................................... 21 11 Oscilloscopes - An Object-oriented Model........................................................ 23 12 Oscilloscopes - A Layered Model ........................................................................ 24 13 Oscilloscopes - A Pipe and Filter Model............................................................ 24 14 Oscilloscopes - A Modified Pipe and Filter Model.......................................... 25 15 Traditional Compiler Model ............................................................................... 26 16 Traditional Compiler Model with Shared Symbol Table ............................. 26 17 Modern Canonical Compiler .............................................................................. 27 18 Canonical Compiler, Revisited........................................................................... 27 19 PROVOX - Hierarchical Top Level..................................................................... 28 20 PROVOX - Object-oriented Elaboration ............................................................ 29 21 Basic Rule-Based System ...................................................................................... 31 22 Sophistocated Rule-Based System...................................................................... 32 23 Simplified Rule-Based System............................................................................ 33 24 Hearsay-II ................................................................................................................. 34 25 Blackboard View of Hearsay-II ............................................................................ 35 26 Interpreter View of Hearsay-II ............................................................................ 36 Garlan & Shaw: An Introduction to Software Architecture 2 1. Introduction As the size and complexity of software systems increases, the design problem goes beyond the algorithms and data structures of the computation: designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives. This is the software architecture level of design. There is a considerable body of work on this topic, including module interconnection languages, templates and frameworks for systems that serve the needs of specific domains, and formal models of component integration mechanisms. In addition, an implicit body of work exists in the form of descriptive terms used informally to describe systems. And while there is not currently a well-defined terminology or notation to characterize architectural structures, good software engineers make common use of architectural principles when designing complex software. Many of the principles represent rules of thumb or idiomatic patterns that have emerged informally over time. Others are more carefully documented as industry and scientific standards. It is increasingly clear that effective software engineering requires facility in architectural software design. First, it is important to be able to recognize common paradigms so that high-level relationships among systems can be understood and so that new systems can be built as variations on old systems. Second, getting the right architecture is often crucial to the success of a software system design; the wrong one can lead to disastrous results. Third, detailed understanding of software architectures allows the engineer to make principled choices among design alternatives. Fourth, an architectural system representation is often essential to the analysis and description of the high- level properties of a complex system. In this paper we provide an introduction to the field of software architecture. The purpose is to illustrate the current state of the discipline and examine the ways in which architectural design can impact software design. The material presented here is selected from a semester course, Architectures for Software Systems, taught at CMU by the authors [1]. Naturally, a short paper such as this can only briefly highlight the main features of the terrain. This selection emphasizes informal descriptions omitting much of the course’s material on specification, evaluation, and selection among design alternatives. We hope, nonetheless, that this will serve to illuminate the nature and significance of this emerging field. In the following section we outline a number of common architectural styles upon which many systems are currently based, and show how Garlan & Shaw: An Introduction to Software Architecture 3 heterogeneous styles can be combined in a single design. Next we use six case studies to illustrate how architectural representations of a software system can improve our understanding of complex systems. Finally, we survey some of the outstanding problems in the field, and consider a few of the promising research directions. The text that makes up the bulk of this article has been drawn from numerous other publications by the authors. The taxonomy of architectural styles and the case studies have incorporated parts of several published papers [1, 2, 3, 4]. To a lesser extent material has been drawn from other articles by the authors [5, 6, 7]. 2. From Programming Languages to Software Architecture One characterization of progress in programming languages and tools has been regular increases in abstraction level—or the conceptual size of software designers building blocks. To place the field of Software Architecture into perspective let us begin by looking at the historical development of abstraction techniques in computer science. 2.1. High-level Programming Languages When digital computers emerged in the 1950s, software was written in machine language; programmers placed instructions and data individually and explicitly in the computer's memory. Insertion of a new instruction in a program might require hand-checking of the entire program to update references to data and instructions that moved as a result of the insertion. Eventually it was recognized that the memory layout and update of references could be automated, and also that symbolic names could be used for operation codes, and memory addresses. Symbolic assemblers were the result. They were soon followed by macro processors, which allowed a single symbol to stand for a commonly-used sequence of instructions. The substitution of simple symbols for machine operation codes, machine addresses yet to be defined, and sequences of instructions was perhaps the earliest form of abstraction in software. In the latter part of the 1950s, it became clear that certain patterns of execution were commonly useful—indeed, they were so well understood that it was possible to create them automatically from a notation more like mathematics than machine language. The first of these patterns were for evaluation of arithmetic expressions, for procedure invocation, and for loops and conditional statements. These insights were captured in a series of early high-level languages, of which Fortran was the main survivor. Higher-level languages allowed more sophisticated programs to be developed, and patterns in the use of data emerged. Whereas in Fortran data types served primarily as cues for selecting the proper machine instructions, Garlan & Shaw: An Introduction to Software Architecture 4 data types in Algol and it successors serve to state the programmer’s intentions about how data should be used. The compilers for these languages could build on experience with Fortran and tackle more sophisticated compilation problems. Among other things, they checked adherence to these intentions, thereby providing incentives for the programmers to use the type mechanism. Progress in language design continued with the introduction of modules to provide protection for related procedures and data structures, with the separation of a module’s specification from its implementation, and with the introduction of abstract data types. 2.2. Abstract Data Types In the late 1960s, good programmers shared an intuition about software development: If you get the data structures right, the effort will make development of the rest of the program much easier. The abstract data type work of the 1970s can be viewed as a development effort that converted this intuition into a real theory. The conversion from an intuition to a theory involved understanding • the software structure (which included a representation packaged with its primitive operators), • specifications (mathematically expressed as abstract models or algebraic axioms), • language issues (modules, scope, user-defined types), • integrity of the result (invariants of data structures and protection from other manipulation), • rules for combining types (declarations), • information hiding (protection of properties not explicitly included in specifications). The effect of this work was to raise the design level of certain elements of software systems, namely abstract data types, above the level of programming language statements or individual algorithms. This form of abstraction led to an understanding of a good organization for an entire module that serves one particular purpose. This involved combining representations, algorithms, specifications, and functional interfaces in uniform ways. Certain support was required from the programming language, of course, but the abstract data type paradigm allowed some parts of systems to be developed from a vocabulary of data types rather than from a vocabulary of programming-language constructs. 2.3. Software Architecture Just as good programmers recognized useful data structures in the late 1960s, good software system designers now recognize useful system organizations. Garlan & Shaw: An Introduction to Software Architecture 5 One of these is based on the theory of abstract data types. But this is not the only way to organize a software system. Many other organizations have developed informally over time, and are now part of the vocabulary of software system designers. For example, typical descriptions of software architectures include synopses such as (italics ours): •“Camelot is based on the client-server model and uses remote procedure calls both locally and remotely to provide communication among applications and servers.”[8] •“Abstraction layering and system decomposition provide the appearance of system uniformity to clients, yet allow Helix to accommodate a diversity of autonomous devices. The architecture encourages a client- server model for the structuring of applications.”[9] •“We have chosen a distributed, object-oriented approach to managing information.” [10] •“The easiest way to make the canonical sequential compiler into a concurrent compiler is to pipeline the execution of the compiler phases over a number of processors. . . . A more effective way [is to] split the source code into many segments, which are concurrently processed through the various phases of compilation [by multiple compiler processes] before a final, merging pass recombines the object code into a single program.”[11] Other software architectures are carefully documented and often widely disseminated. Examples include the International Standard Organization's Open Systems Interconnection Reference Model (a layered network architecture) [12], the NIST/ECMA Reference Model (a generic software engineering environment architecture based on layered communication substrates) [13, 14], and the X Window System (a distributed windowed user interface architecture based on event triggering and callbacks) [15]. We are still far from having a well-accepted taxonomy of such architectural paradigms, let alone a fully-developed theory of software architecture. But we can now clearly identify a number of architectural patterns, or styles, that currently form the basic repertoire of a software architect. 3. Common Architectural Styles We now examine some of these representative, broadly-used architectural styles. Our purpose is to illustrate the rich space of architectural choices, and indicate what are some of the tradeoffs in choosing one style over another. To make sense of the differences between styles, it helps to have a common framework from which to view them. The framework we will adopt is to treat an architecture of a specific system as a collection of computational Garlan & Shaw: An Introduction to Software Architecture 6 components—or simply components-—together with a description of the interactions between these components—the connectors. Graphically speaking, this leads to a view of an abstract architectural description as a graph in which the nodes represent the components and the arcs represent the connectors. As we will see, connectors can represent interactions as varied as procedure call, event broadcast, database queries, and pipes. An architectural style, then, defines a family of such systems in terms of a pattern of structural organization. More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints on how they can be combined. These can include topological constraints on architectural descriptions (e.g., no cycles). Other constraints—say, having to do with execution semantics—might also be part of the style definition. Given this framework, we can understand what a style is by answering the following questions: What is the structural pattern—the components, connectors, and constraints? What is the underlying computational model? What are the essential invariants of the style? What are some common examples of its use? What are the advantages and disadvantages of using that style? What are some of the common specializations? 3.1. Pipes and Filters In a pipe and filter style each component has a set of inputs and a set of outputs. A component reads streams of data on its inputs and produces streams of data on its outputs, delivering a complete instance of the result in a standard order. This is usually accomplished by applying a local transformation to the input streams and computing incrementally so output begins before input is consumed. Hence components are termed “filters”. The connectors of this style serve as conduits for the streams, transmitting outputs of one filter to inputs of another. Hence the connectors are termed “pipes”. Among the important invariants of the style, filters must be independent entities: in particular, they should not share state with other filters. Another important invariant is that filters do not know the identity of their upstream and downstream filters. Their specifications might restrict what appears on the input pipes or make guarantees about what appears on the output pipes, but they may not identify the components at the ends of those pipes. Furthermore, the correctness of the output of a pipe and filter network should not depend on the order in which the filters perform their incremental processing—although fair scheduling can be assumed. (See [5] for an in-depth discussion of this style and its formal properties.) Figure 1 illustrates this style. Common specializations of this style include pipelines, which restrict the topologies to linear sequences of filters; bounded pipes, which restrict the amount of data that can reside on a pipe; and typed pipes, which require that the data passed between two filters have a well-defined type. Garlan & Shaw: An Introduction to Software Architecture 7 Data flowASCII stream filter Computation Figure 1: Pipes and Filters A degenerate case of a pipeline architecture occurs when each filter processes all of its input data as a single entity.1 In this case the architecture becomes a “batch sequential” system. In these systems pipes no longer serve the function of providing a stream of data, and therefore are largely vestigial. Hence such systems are best treated as instances of a separate architectural style. The best known examples of pipe and filter architectures are programs written in the Unix shell [16]. Unix supports this style by providing a notation for connecting components (represented as Unix processes) and by providing run time mechanisms for implementing pipes. As another well-known example, traditionally compilers have been viewed as a pipeline systems (though the phases are often not incremental). The stages in the pipeline include lexical analysis, parsing, semantic analysis, code generation. (We return to this example in the case studies.) Other examples of pipes and filters occur in signal processing domains [17], functional programming [18], and distributed systems [19]. Pipe and filter systems have a number of nice properties. First, they allow the designer to understand the overall input/output behavior of a system as a simple composition of the behaviors of the individual filters. Second, they support reuse: any two filters can be hooked together, provided they agree on the data that is being transmitted between them. Third, systems can be easily maintained and enhanced: new filters can be added to existing systems and old filters can be replaced by improved ones. Fourth, they permit certain kinds of specialized analysis, such as throughput and deadlock analysis. Finally, they naturally support concurrent execution. Each filter can be implemented as a separate task and potentially executed in parallel with other filters. But these systems also have their disadvantages.2 First, pipe and filter systems often lead to a batch organization of processing. Although filters can 1In general, we find that the boundaries of styles can overlap. This should not deter us from identifying the main features of a style with its central examples of use. 2This is true in spite of the fact that pipes and filters, like every style, has a set of devout religious followers—people who believe that all problems worth solving can best be solved using that particular style. Garlan & Shaw: An Introduction to Software Architecture 8 process data incrementally, since filters are inherently independent, the designer is forced to think of each filter as providing a complete transformation of input data to output data. In particular, because of their transformational character, pipe and filter systems are typically not good at handling interactive applications. This problem is most severe when incremental display updates are required, because the output pattern for incremental updates is radically different from the pattern for filter output. Second, they may be hampered by having to maintain correspondences between two separate, but related streams. Third, depending on the implementation, they may force a lowest com- mon denominator on data transmission, resulting in added work for each filter to parse and unparse its data. This, in turn, can lead both to loss of performance and to increased complexity in writing the filters themselves. 3.2. Data Abstraction and Object-Oriented Organization In this style data representations and their associated primitive operations are encapsulated in an abstract data type or object. The components of this style are the objects—or, if you will, instances of the abstract data types. Objects are examples of a sort of component we call a manager because it is responsible for preserving the integrity of a resource (here the representation). Objects interact through function and procedure invocations. Two important aspects of this style are (a) that an object is responsible for preserving the integrity of its representation (usually by maintaining some invariant over it), and (b) that the representation is hidden from other objects. Figure 2 illustrates this style.3 obj obj obj obj obj obj objobj op op op op op op op op op op op op op op op op obj is a manager op is an invocation ADTManager Proc call Figure 2: Abstract Data Types and Objects 3We haven't mentioned inheritance in this description. While inheritance is an important organizing principle for defining the types of objects in a system, it does not have a direct architectural function. In particular, in our view, an inheritance relationship is not a connector, since it does not define the interaction between components in a system. Also, in an architectural setting inheritance of properities is not restricted to object types—but may include connectors and even architectural styles. Garlan & Shaw: An Introduction to Software Architecture 9 The use of abstract data types, and increasingly the use of object-oriented systems, is, of course, widespread. There are many variations. For example, some systems allow “objects” to be concurrent tasks; others allow objects to have multiple interfaces [20, 21]. Object-oriented systems have many nice properties, most of which are well known. Because an object hides its representation from its clients, it is possible to change the implementation without affecting those clients. Additionally, the bundling of a set of accessing routines with the data they manipulate allows designers to decompose problems into collections of interacting agents. But object-oriented systems also have some disadvantages. The most significant is that in order for one object to interact with another (via procedure call) it must know the identity of that other object. This is in contrast, for example, to pipe and filter systems, where filters do need not know what other filters are in the system in order to interact with them. The significance of this is that whenever the identity of an object changes it is necessary to modify all other objects that explicitly invoke it. In a module- oriented language this manifests itself as the need to change the “import” list of every module that uses the changed module. Further there can be side- effect problems: if A uses object B and C also uses B, then C's effects on B look like unexpected side effects to A, and vice versa. 3.3. Event-based, Implicit Invocation Traditionally, in a system in which the component interfaces provide a collection of procedures and functions, components interact with each other by explicitly invoking those routines. However, recently there has been considerable interest in an alternative integration technique, variously referred to as implicit invocation, reactive integration, and selective broadcast. This style has historical roots in systems based on actors [22], constraint satisfaction, daemons, and packet-switched networks. The idea behind implicit invocation is that instead of invoking a procedure directly, a component can announce (or broadcast) one or more events. Other components in the system can register an interest in … Software architecture We began last week by talking about definitions of quality, and now we are going to begin discussing design and how design affects quality. Software Architecture is a popular topic in software design, and having the right architecture for the problem at hand can make a huge difference in product quality. This week we will begin with an overview of software architecture, which will frame a few design case studies we will examine this semester. To read • [required] David Garlan and Mary Shaw. Sections 1-3. An Introduction to Software Architecture, Carnegie Mellon University, Tech Report CMU-CS-94-166, 1994, pp. 1-15. • [required] Nenad Medvidovic and Richard N. Taylor. Separating fact from fiction in software architecture. In Proceedings of the Third International Workshop on Software Architecture, ACM Press, 1998, pp. 105-108. • [optional] George H. Fairbanks. Chapter 1. Just Enough Software Architecture [textbook]. Marshall & Brainerd, 2010, pp. 1-11. To turn in Prepare a brief (no more than one page) written answer to the following two questions. Write up your answer using MS Word or LaTex. One well- presented paragraph for each question is sufficient. 1. What are the important similarities and differences between an "architectural style" and a "programming paradigm" (like functional programming, logic programming, dataflow, etc.)? 2. How do you think "architectural style" affects software quality? Software architecture To read To turn in Nenad Medvidovic Dept. of Information and Computer Science University of California, Irvine Irvine, California 92697 +l -949-824-3100 neno @I ics.uci.edu 1. ABSTRACT Explicit focus on architecture has shown tremendous potential to improve the current state-of-the-art in soft- ware development. Relatively quickly, software architec- ture research has produced credible results. However, some of this initial success has also resulted in unrealistic expectations and failure to recognize the limits of this line of research, which can result in backlash when the unre- alistic expectations are not met. One solution is to attempt to clearly delineate the boundaries of applicability and effectiveness of software architectures. This paper repre- sents a step in that direction: it dispels some common mis- conceptions about architectures and discusses problem areas for which architecture is well suited and those for which it is not.’ 2. INTRODUCTION Software architecture has become an area of intense research in the software engineering community. A number of architecture modeling notations and support tools, as well as new architectural styles, have emerged. Explicit focus on architecture has shown tremendous potential to improve the current state-of-the-art in software development and alleviate many of its problems. Architecture addresses an essential difficulty in software engineering-complexity-via abstraction and its promise of supporting reuse. At the same time, one fact should not be overlooked: software architecture is not a “silver bullet” [3], and simply introducing it into an existing development lifecycle will not fully exploit this potential for improvement. In a few short years, software architecture research has ’ Effort sponsored by the Defense Advanced Research Projects Agency, and Rome Laboratory, Air Force Materiel Command, US- AF, under agreement number F30602-97-2-0021. The U.S. Gov- ernment is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright annotation thereon. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily represent- ing the official policies or endorsements, either expressed or im- plied, of the Defense Advanced Research Projects Agency, Rome Laboratory or the U.S. Government. Permission to make digital or hard copies ofall or part ofthis work for prrsonal or classroom use ib granted without fee provided that copies arc not made or dlstnhuted for prolit or commercial advantage and that copies hear this notice and the full citation on the first page. To copy otherwise. to republish. to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ISAW Orlando Florida USA Copyright ACM 1998 l-581 13-OSI-3/98/11...$5.00 Separating Fact from Fiction in Software Architecture Richard N. Taylor Dept. of Information and Computer Science University of California, Irvine Irvine, California 92697 +l -949-824-6429 taylor8 ics.uci.edu produced credible, if not impressive, results. However, some of this initial success has also resulted in overblown claims and “hype,” unrealistic expectations, and occasional failure to recognize the shortcomings and limits of this line of research. While such an attitude may be useful in gathering the initial momentum needed to put a young discipline on the map, it has the potential downside of resulting in backlash when the unrealistic expectations are not met. We believe that, as the “first generation” of architecture research projects has become mature enough to have its actual impact evaluated, some backlash is indeed beginning to emerge. The reasons are numerous. Some projects have promised more than they have been able to deliver. Architecture is still largely an academic notion, and little resulting technology has been transitioned to industry. The focus of the research itself is often misunderstood. Architecture is sometimes incorrectly equated with architecture description languages (ADLs) and with design. As such misconceptions take hold, a danger emerges that some real benefits and positive results of architecture research will be dismissed. It is up to software architecture researchers to alleviate this problem. We must recognize that we have failed to exploit a lot of the potential in those areas for which architecture is best suited, while promising too much, too quickly in the areas for which it is not. We must make clear that there are certain problem areas that architecture research will not be able to address and thus make explicit the boundaries of this field. This paper attempts to do so. It is partly a result of our experience with a specific project, C2 [15], and partly an extrapolation of lessons learned from an extensive study of the existing architecture work [6, 81. While this paper may well not be the first place where some of the ideas will have appeared, they seem to have been forgotten and we believe that it is crucial to raise them again in the consciousness of architecture researchers. The remainder of the paper is organized as follows. Section 3 addresses some common misconceptions about architectures. Sections 4 and 5, respectively, discuss the types of tasks for which architecture is well suited and those which are largely outside its scope. Discussion and conclusions round out the paper. 3. COMMON MISCONCEPTIONS Architecture is often equated with architecture description languages (ADLs), which are only an enabler to achieve its benefits, and not the end product. Architecture is also equated with design; though related, their foci are quite different. 105 Finally, existing research has focused to a large degree on architecture-based analysis. This section discusses why these are incomplete, if not incorrect, notions of architecture. 3.1 Architectures and ADLs Software architecture is a high-level view of a system that focuses on structure, communication protocols, assignment of software components and connectors to hardware components, and so forth. Every software system has an architecture, although it may not be explicitly modeled. An ADL, on the other hand, can be viewed as a notation that helps architects model an aspect of the architecture. Therefore, multiple ADLs may be used to model a single architecture. ADLs may be formal, semi-formal, or informal. Their purpose is not the same as that of programming languages: they are meant to provide a basis for early analysis of a system and for its design and implementation, but also for communication and understanding among stakeholders in a project. ADLs may be general-purpose or special-purpose modeling languages. 3.2 Architecture and Design Current literature leaves the issue of the relationship between architecture and design ambiguous, allowing for several interpretations: . architecture and design are the same; l architecture is at a level of abstraction above design, so it is simply another step (artifact) in a software development process; and l architecture is something new and is somehow different from design (but just how remains unspecified). The second interpretation is closest to the truth. To some extent, architecture serves the same purpose as design. However, its explicit focus on system structure and interconnections distinguishes it from traditional software design, such as object-oriented (00) design, which focuses more on modeling lower level abstractions, such as algorithms and data types. As a (high level) architecture is refined, its connectors may lose prominence by becoming distributed across the (lower level) architecture’s elements, eventually resulting in the transformation of the architecture into a design. 3.3 Architecture and Analysis A large fraction of architecture research to date has focused on the architecture as a vehicle for early system analysis. Early understanding of the properties of an application is indeed invaluable. On the other hand, there are several unresolved issues associated with architecture-level analysis. Addressing these may require a shift in the current mentality. In order to enable formal analysis, ADLs must supply appropriate formal constructs. Performing meaningful analyses may require introduction of constructs into an ADL that are perhaps premature for the current abstraction level. This is also likely to hamper the different stakeholders’ understanding of the architecture. A more balanced approach for evaluating an architecture, which couples informal “inspections” of the architecture with more powerful formal analyses may be preferable: it would result in a less formal architectural model that would focus attention on the “quality,” elegance, and suitability of the architecture for the given problem. Another critical issue is that, once a property of an architecture is established, one must also ensure that that property will be preserved in the design and implementation. Existing architecture research has mostly failed to address this problem. Better and more practical refinement techniques that would ensure consistency among the architecture, design, and implementation are needed. 4. WHAT ARCHITECTURE IS GOOD AT In this section we discuss the tasks that arise in the process of software development for which architectures are well suited. These are the strengths of architectures and should be the primary focus of researchers and practitioners. In general, architecture provides a solid basis for large-scale development of distributed applications, using off-the-shelf components and connectors, implemented in multiple programming languages. It also has a number of additional benefits. Several are discussed below. Architectures are a good communication facilitator among the different stakeholders in a project. They are at a sufficiently high level of abstraction to enable understanding by the non-technical stakeholders, such as managers or customers. Architecture arises from an analysis of the requirements and of application domain characteristics and is the earliest model of a solution to the customer needs [16]. For this reason, it is important that architectural descriptions be simple, understandable, and possibly graphical, with well understood, but not necessarily formally defined, semantics. Architectural models can also present multiple views of the same architecture [4], e.g., a high level graphical view, a lower level view with formal specifications of components and connectors, a conceptual architecture, one or more implementation architectures, the corresponding development process, the data or control flow view, and so on. Different stakeholders (e.g., architects, developers, managers, customers) may require different views of the architecture. The customer may be satisfied with a high-level, “boxes and arrows” description, the developers may want detailed component and connector models, while the managers may require a view of the development process. One of the greatest benefits of architectures is their separation of computation from interaction in a system. Software connectors are elevated to a first-class status, and their benefits have been demonstrated by a number of existing approaches [ 1, 13, 151. Explicit connectors remove from components the responsibility of knowing how they are interconnected and minimize component interdependencies. Changes to a system’s functionality are thus limited to the components. All decisions regarding communication, mediation, and coordination in a system are isolated inside connectors [ 121. Architectures are an ideal platform for supporting course- grain software evolution. This includes adding, removing, and replacing components and connectors, while ensurin f structural and behavioral properties of an application. 106 Architecture-based evolution can occur both at system specification time [9] and at its execution time [lo]. Although individual components and connectors can also evolve using approaches such as subtyping or inheritance [5, 71, architecture is generally not a good foundation for fine-grain evolution that requires replacement of individual source code statements. Architecture affords software engineers a lot of flexibility because of its separation from implementation. This allows an architect to experiment with various configurations (architectural plug-and-play) and enact “what if’ scenarios rather inexpensively. Architectural analysis tools can then indicate potential problems early enough in the lifecycle so as to minimize the costs of correcting them. In order to fully exploit this separation, a reliable mapping from the architecture to the implementation is needed. This is related to architectural refinement, discussed Section 3.3, and remains an open area of research. Finally, architecture is the appropriate level of abstraction at which invariant properties of a problem domain or rules of a compositional style (i.e., an architectural style) can be exploited and should be elaborated. Doing so for domain- specific architectures (DSSAs) results in a reference architecture that is reused across applications in the domain. Doing so for a style results in a set of heuristics that, if followed, will guarantee a resulting system certain desirable properties. DSSAs and styles also enable easier communication among stakeholders. For example, just saying that a system is in the “client-server” or “pipe and filter” style implies a certain structure and a set of properties without having to discuss its details. DSSAs and styles have the potential to enable code generation for canonical components and connectors, as well as the “glue” code to compose them in a system. Substantial experience in a particular domain and/or style can be used as a basis for generalizing the given approach to other problem areas [ 141. 5. WHAT ARCHITECTURE IS NUT GOOD AT The previous section has outlined a set of benefits developers can derive from an explicit architectural focus. However, all of a project’s needs may not be addressible by architecture. Architecture alone certainly cannot compensate for problems in requirements acquisition, project scheduling and budgets, organizational issues, such as poorly trained employees, inefficient process, and so forth. There are also some technical areas for which architecture is not well suited. As already discussed, architecture cannot be effectively employed to support @e-grain evolution. Architecture assumes that applications are constructed from building blocks that are above the level of a source statement. If the evolution of a given system predominantly occurs at the source code statement level, then architecture is not the appropriate abstraction for supporting that evolution. In general, architecture cannot guarantee the properties of the implemented system. Properties like reliability or ’ Batory and O’Malley quite appropriately refer to this as the “Lego paradigm” in software development [2]. performance cannot be fully assessed at the architectural level, although the characteristics of the architecture and/or the style can provide an indication of how the system will behave. A system’s implementation can be modified independently of its architecture; many modifications (e.g., evolution at the source code level) will not have any effect on the underlying architecture, thus the architecture will not aid developers in preventing errors. If we disallow the direct modification of an implementation, we essentially reduce architecture-based software development to a variant of transformational programming [ 111, thus inheriting all of its problems and limitations, with the added problem of scale. Also, unless specific techniques are developed to support architecture-based evolution, and particularly runtime evolution, a system may have to be entirely regenerated every time its architecture is modified. A related issue is source code optimization. Architecture is not the correct abstraction level for this task; the right place to do so is code itself. Simply employing an explicit architecture does not guarantee a development process that will ensure the quality of the resulting system. “Architecting” is only a step in the software engineering lifecycle. Certainly, architecture can be a guide for the process in that it contains a conceptual, high level view of the system. However, enacting an effective and efficient process to transform that architecture into a running system then becomes the responsibility of the management and developers. A problem that is actually exacerbated by architectures is traceability across the different aspects (views) of a system and different levels of abstraction. As discussed above, a software architecture often consists of multiple views and may be modeled at multiple levels of abstraction (Figure 1). We call a particular view of the architecture at a given level of abstraction (i.e., a single point in the two-dimensional space of Figure 1) an “architectural cross-section.” It is critical for changes in one cross-section to be correctly reflected in others. A particular architectural cross-section can be considered “dominant,” so that all changes to the architecture Architectural View t implementation + development process control Row data flow t cross-section graphical - - - - - - n I textual t I Level of Abstraction --- - requirements high level detailed source architecture architecture code Figure 1: Two-dimensional space of architectural views and levels of abstraction. The vertical axis is a set of discrete values with a nominal ordering. The horizontal axis is a continuum with an ordinal ordering of values, where system requirements are considered to be the highest level of abstraction and source code the lowest. One possible dominant cross-section (graphical view of the high level architecture) is shown. 107 are made to it and then reflected in others. More frequently, changes will be made to the most appropriate or convenient cross-section. Traceability support will hence need to exist across all pertinent cross-sections. However, the relationships among architectural views are not always well understood. For example, while it is typically straight forward to provide support for tracing changes between textual and graphical views, it may be less clear how the data flow view should affect the development process view. In other cases, changes in one view (e.g., process) should never affect another (e.g., control flow). An even bigger hurdle is providing traceability support across both architectural views and levels of abstraction simultaneously. Finally, although much research has been directed at methodologies for making the transition from requirements to design (e.g., 00), this process is still an art form. Further research is especially needed to understand the effects of changing requirements on architectures and vice versa. Finally, we revisit an issue discussed earlier: formalism. Formalism has been extensively adopted and employed in architecture research to date, resulting in a number of benefits. However, too often this has been at the expense of understanding, communication, and cognitive support for developers. As a bridge between requirements and design, architecture is the artifact that will need to be understandable to a very diverse set of stakeholders. By removing ambiguity, formalism can aid understandability. On the other hand, some decisions will purposely be left unspecified at the architectural level; formalism typically does not allow for such incompleteness. Additionally, it is still unclear how much formalism is adequate at the level of architecture and what types of formal methods are best suited for the needs of architecture modeling. 6. CONCLUSIONS Software architectures show great potential for reducing development costs while improving the quality of the resulting software. However, this potential cannot be fulfilled simply by explicitly focusing on architectures, just like a new programming language cannot by itself solve the problems of software engineering. A programming language is only a tool that allows (but does not force) developers to put sound software engineering principles and techniques into practice. Similarly, one can think of software architectures as tools that also must be supported with specific techniques to achieve desired properties. As is typically the case with tools, software architectures are much better suited to solving some types of problems than others. Understanding the types of problems to which architectures can be applied most effectively will help practitioners maximize the benefits of an architecture-centered approach to software engineering. 7. REFERENCES [I] R. Allen and D. Garlan. A Formal Basis for Architectural Connection. ACM Transactions on Sofhvare Engineering and Methodology, July 1997. [2] D. Batory and S. O’Malley. The Design and Implementation of Hierarchical Software Systems with Reusable Components. ACM Transactions on Software Engineering and Methodology, October 1992. [3] F. P. Brooks, Jr. Essence and Accidents of Software Engineering. IEEE Computer, April 1987. [4] P. B. Kruchten. The 4+1 View Model of Architecture. IEEE Software, November 1995. [5] N. Medvidovic, P. Oreizy, J. E. Robbins, and R. N. Taylor. Using Object-Oriented Typing to Support Architectural Design in the C2 Style. In Proceedings of the Fourth Symposium on the Foundations of Software Engineering, San Francisco, CA, October 1996. [6] N. Medvidovic and D. S. Rosenblum. Domains of Concern in Software Architectures and Architecture Description Languages. In Proceedings of the USENZX Conference on Domain-Specific Languages, Santa Barbara, CA, October 1997. [7] N. Medvidovic, D. S. Rosenblum, and R. N. Taylor. A Type Theory for Software Architectures. Technical Report, UCI-ICS-98-14, Department of Information and Computer Science, University of California, Irvine, April 1998. [8] N. Medvidovic and R. N. Taylor. A Framework for Classifying and Comparing Architecture Description Languages. In Proceedings of the Sixth European Software Engineering Conference together with the Fifth ACM SIGSOFT Symposium on the Foundations of Software Engineering, Zurich, Switzerland, September 1997. [9] N. Medvidovic, R. N. Taylor, and D. S. Rosenblum. An Architecture-Based Approach to Software Evolution. In Proceedings of the International Workshop on the Principles of Sofiware Evolution, Kyoto, Japan, April 1998. [lo] F? Oreizy, N. Medvidovic, and R. N. Taylor. Architecture- Based Runtime Software Evolution. In Proceedings of the 20th International Conference on Software Engineeting (ICSE’98), Kyoto, Japan, April 1998. [ 111 H. Partsch and R. Steinbruggen. Program Transformation Systems. ACM Computing Surveys, September 1983. [ 121 D. E. Perry. Software Architecture and its Relevance to Software Engineering. Coord’97, September 1997. [ 131 M. Shaw, R. DeLine, D. V. Klein, T. L. Ross, D. M. Young, and G. Zelesnik. Abstractions for Software Architecture and Tools to Support Them. ZEEE Transactions on Software Engineering, April 1995. [ 141 R. N. Taylor. Generalization from domain experience: The superior paradigm for software architecture research? In Proceedings of the Second Internutional Software Architecture Workshop (ISAW-2), San Francisco, CA, October 1996. [ 151 R. N. Taylor, N. Medvidovic, K. M. Anderson, E. J. Whitehead, Jr., J. E. Robbins, K. A. Nies, I’, Oreizy, and D. L. Dubrow. A Component- and Message-Based Architectural Style for GUI Software. IEEE Transactions on Software Engineering, June 1996. [ 161 W. Tracz. DSSA (Domain-Specific Software Architecture) Pedagogical Example. ACM SIGSOFT Software Engineering Notes, July 1995. 108