jagomart
digital resources
picture1_Software Architecture Pdf 186019 | Finalgarlan


 185x       Filetype PDF       File size 0.08 MB       Source: www0.cs.ucl.ac.uk


File: Software Architecture Pdf 186019 | Finalgarlan
software architecture a roadmap david garlan school of computer science carnegie mellon university 5000 forbes avenue pittsburgh pa 15213 412 268 5056 garlan cs cmu edu abstract design regular conferences ...

icon picture PDF Filetype PDF | Posted on 01 Feb 2023 | 2 years ago
Partial capture of text on file.
                                           Software Architecture: a Roadmap
                                                                    David Garlan
                                                            School of Computer Science
                                                            Carnegie Mellon University
                                                                 5000 Forbes Avenue
                                                                Pittsburgh, PA 15213
                                                                    (412) 268-5056
                                                                 garlan@cs.cmu.edu
              ABSTRACT                                                          design, regular conferences and workshops devoted speci-
              Over the past decade software architecture has received           fically to software architecture, a growing number of  com-
              increasing attention as an important subfield of software         mercial tools to aid in aspects of architectural design,
              engineering. During that time there has been considerable         courses in software architecture, major government and
              progress in developing the technological and methodologi-         industrial research projects centered on software architec-
              cal base for treating architectural design as an engineering      ture and an increasing number of formal architectural stan-
              discipline. However, much remains to be done to achieve           dards. Codification of architectural principles, methods,
              that goal. Moreover, the changing face of technology raises       and practices has begun to lead to repeatable processes of
              a number of new challenges for software architecture. This        architectural design, criteria for making principled tradeoffs
              paper examines some of the important trends of software           among architectures, and standards for documenting, re-
              architecture in research and practice, and speculates on the      viewing, and implementing architectures.
              important emerging trends, challenges, and aspirations.
                                                                                However, despite this progress, as engineering disciplines
              Keywords                                                          go, the field of software architecture remains relatively
              Software architecture, software design, software                  immature. While the outlines of an engineering basis for
              engineering                                                       software architecture are becoming clear, there remain nu-
                                                                                merous challenges and unknowns. We can therefore expect
              1    INTRODUCTION                                                 to see major new developments in the field over the next
              A critical issue in the design and construction of any com-       decade – both in research and practice. Some of these de-
              plex software system is its architecture: that is, its gross      velopments will be natural extensions of the current trajec-
              organization as a collection of interacting components. A         tory. But there are also a number of radical new opportuni-
              good architecture can help ensure that a system will satisfy      ties, brought about by the changing face of technology.
              key requirements in such areas as performance, reliability,       In this paper I examine some of the important trends of
              portability, scalability, and interoperability. A bad archi-      software architecture in research and practice. To set the
              tecture can be disastrous.                                        stage, I begin by describing the roles of architecture in
              Over the past decade software architecture has received           software systems development. Next I summarize the past
              increasing attention as an important subfield of software         and current state of research and practice. Finally, after
              engineering.  Practitioners have come to realize that getting     considering some of the forces that are changing the world
              an architecture right is a critical success factor for system     of software systems themselves, I speculate on emerging
              design and development. They have begun to recognize the          trends, challenges, and aspirations.
              value of making explicit architectural choices, and lever-        2   THE ROLES OF SOFTWARE ARCHITECTURE
              aging past architectural designs in the development of new        While there are numerous definitions of software architec-
              products. Today there are numerous books on architectural         ture, at the core of all of them is the notion that the archi-
                                                                                tecture of a system describes its gross structure.  This
                                                                                structure illuminates the top level design decisions, include-
                                                                                ing things such as how the system is composed of interact-
                                                                                ing parts, where are the main pathways of interaction, and
                                                                                what are the key properties of the parts.  Additionally, an
                                                                                architectural description includes sufficient information to
                                                                                allow high-level analysis and critical appraisal.
                                                                                                3.   Construction: An architectural description provides
                Software architecture typically plays a key role as a bridge                         a partial blueprint for development by indicating the
                between requirements and implementation (see Figure 1).                              major components and dependencies between them.
                                                                                                     For example, a layered view of an architecture typi-
                                                                                                     cally documents abstraction boundaries between
                                                                                                     parts of a system’s implementation, clearly identify-
                                          Requirements                                               ing the major internal system interfaces, and con-
                                                                                                     straining what parts of a system may rely on services
                                                                                                     provided by other parts.
                                     Software Architecture                                      4.   Evolution: Software architecture can expose the di-
                                                                                                     mensions along which a system is expected to
                                                                                                     evolve.  By making explicit the "load-bearing walls"
                                               Code                                                  of a system, system maintainers can better under-
                                                                                                     stand the ramifications of changes, and thereby more
                                                                                                     accurately estimate costs of modifications.  More-
                                                                                                     over, architectural descriptions separate concerns
                         Figure 1: Software Architecture as a Bridge                                 about the functionality of a component from the
                                                                                                     ways in which that component is connected to (in-
                By providing an abstract description of a system, the ar-                            teracts with) other components, by clearly distin-
                chitecture exposes certain properties, while hiding others.                          guishing between components and mechanisms that
                Ideally this representation provides an intellectually tracta-                       allow them to interact.  This separation permits one
                ble guide to the overall system, permits designers to reason                         to more easily change connection mechanisms to
                about the ability of a system to satisfy certain requirements,                       handle evolving concerns about performance inter-
                and suggests a blueprint for system construction and com-                            operability, prototyping, and reuse.
                position. For example, an architecture for a signal process-
                ing application might be constructed as a dataflow network                      5.   Analysis:  Architectural descriptions provide new
                in which the nodes read input streams of data, transform                             opportunities for analysis, including system consis-
                that data, and write to output streams. Designers might use                          tency checking [2, 25], conformance to constraints
                this decomposition, together with estimated values for input                         imposed by an architectural style [1], conformance
                data flows, computation costs, and buffering capacities, to                          to quality attributes [9], dependence analysis [42],
                reason about possible bottlenecks, resource requirements,                            and domain-specific analyses for architectures built
                and schedulability of the computations.                                              in specific styles [10, 15, 26].
                To elaborate, software architecture can play an important                       6.   Management:  Experience has shown that successful
                role in at least six aspects of software development.                                projects view achievement of a viable software ar-
                   1.   Understanding:  Software architecture simplifies our                         chitecture as a key milestone in an industrial soft-
                        ability to comprehend large systems by presenting                            ware development process.  Critical evaluation of an
                        them at a level of abstraction at which a system’s                           architecture typically leads to a much clearer under-
                        high-level design can be easily understood [20, 35].                         standing of requirements, implementation strategies,
                        Moreover, at its best, architectural description ex-                         and potential risks [7].
                        poses the high-level constraints on system design, as                3    YESTERDAY
                        well as the rationale for making specific architectural              In the distant past of ten years ago, architecture was largely
                        choices.                                                                                1
                                                                                             an ad hoc affair.   Descriptions relied on informal box-and-
                   2.   Reuse:  Architectural descriptions support reuse at                  line diagrams, which were rarely maintained once a system
                        multiple levels.  Current work on reuse generally fo-                was constructed.  Architectural choices were made in idio-
                        cuses on component libraries.  Architectural design                  syncratic fashion – typically by adapting some previous
                        supports, in addition, both reuse of large components                design, whether or not it was appropriate.  Good architects
                        and also frameworks into which components can be                     – even if they were classified as such within their organiza-
                        integrated. Existing work on domain-specific soft-                                                                             
                        ware architectures, reference frameworks, and ar-                    1 To be sure, there were some notable exceptions.  Parnas
                        chitectural design patterns has already begun to pro-                recognized the importance of system families [33], and
                        vide evidence for this [8, 31].                                      architectural decomposition principles based on informa-
                                                                                             tion hiding [34]. Others, such as Dijkstra, exposed certain
                                                                                             system structuring principles [12].
              tions – learned their craft by hard experience in particular       4   TODAY
              domains, and were unable to teach others what they knew.           Much has changed in the past decade.  Although there is
              It was usually impossible to analyze an architectural de-          wide variation in the state of the practice, generally speak-
              scription for consistency or to infer non-trivial properties       ing, architecture is much more visible as an important and
              about it.  There was virtually no way to check that a given        explicit design activity in software development. Job titles
              system implementation faithfully represented its architec-         now routinely reflect the role of software architect; compa-
              tural design.                                                      nies rely on architectural design reviews as critical staging
              However, despite their informality, architectural descrip-         points; and architects recognize the importance of making
              tions were central to system design.  As people began to           explicit tradeoffs within the architectural design space.
              understand the critical role that architectural design plays in    In addition, the technological basis for architectural design
              determining system success, they also began to recognize           has improved dramatically. Three of the important ad-
              the need for a more disciplined approach.  Early authors           vancements have been the development of architecture de-
              began to observe certain unifying principles in architectural      scription languages and tools, the emergence of product
              design [36], to call out architecture as a field in need of        line engineering and architectural standards, and the codifi-
              attention [35], and to establish a working vocabulary for          cation and dissemination of architectural design expertise.
              software architects [20].  Tool vendors began thinking
              about explicit support for architectural design.  Language         4.1  Architecture Description Languages and Tools
              designers began to consider notations for architectural rep-       The informality of most box-and-line depictions of archi-
              resentation [30].                                                  tectural designs leads to a number of problems.  The
              Within industry, two trends highlighted the importance of          meaning of the design may not be clear.  Informal diagrams
              architecture.  The first was the recognition of a shared rep-      cannot be formally analyzed for consistency, completeness,
              ertoire of methods, techniques, patterns and idioms for            or correctness. Architectural constraints assumed in the
              structuring complex software systems. For example, the             initial design are not enforced as a system evolves. There
              box-and-line-diagrams and explanatory prose that typically         are few tools to help architectural designers with their
              accompany a high-level system description often refer to           tasks.
              such organizations as a "pipeline,'' a "blackboard-oriented        In response to these problems a number of researchers in
              design,'' or a "client-server system.''  Although these terms      industry and academia have proposed formal notations for
              were rarely assigned precise definitions, they permitted           representing and analyzing architectural designs. Generi-
              designers to describe complex systems using abstractions           cally referred to as "Architecture Description Languages''
              that make the overall system intelligible. Moreover, they          (ADLs), these notations usually provide both a conceptual
              provided significant semantic content about the kinds of           framework and a concrete syntax for characterizing soft-
              properties of concern, the expected paths of evolution, the        ware architectures [9, 30].  They also typically provide
              overall computational paradigm, and the relationship be-           tools for parsing, displaying, compiling, analyzing, or sim-
              tween this system and other similar systems.                       ulating architectural descriptions.
              The second trend was the concern with exploiting com-              Examples of ADLs include Adage [10], Aesop [15], C2
              monalities in specific domains to provide reusable frame-          [28], Darwin [26], Rapide [25], SADL [32], UniCon [39],
              works for product families. Such exploitation is based on          Meta-H [6], and Wright [3].  While all of these languages
              the idea that common aspects of a collection of related            are concerned with architectural design, each provides cer-
              systems can be extracted so that each new system can be            tain distinctive capabilities: Adage supports the description
              built at relatively low cost by "instantiating'' the shared        of architectural frameworks for avionics navigation and
              design. Familiar examples include the standard decomposi-          guidance; Aesop supports the use of architectural styles; C2
              tion of a compiler (which permits undergraduates to con-           supports the description of user interface systems using an
              struct a new compiler in a semester), standardized commu-          event-based style; Darwin supports the analysis of distrib-
              nication protocols (which allow vendors to interoperate by         uted message-passing systems; Meta-H provides guidance
              providing services at different layers of abstraction), fourth-    for designers of real-time avionics control software; Rapide
              generation languages (which exploit the common patterns            allows architectural designs to be simulated, and has tools
              of business information processing), and user interface            for analyzing the results of those simulations; SADL pro-
              toolkits and frameworks (which provide both a reusable             vides a formal basis for architectural refinement; UniCon
              framework for developing interfaces and sets of reusable           has a high-level compiler for architectural designs that sup-
              components, such as menus and dialogue boxes).                     ports a mixture of heterogeneous component and connector
                                                                                 types; Wright supports the formal specification and analy-
                                                                                 sis of interactions between architectural components.
              Recently the proliferation of capabilities of ADLs has            tools. But general-purpose object languages suffer from the
              prompted an investigation of ways to integrate the notations      problem that the object conceptual vocabulary may not be
              and tools into larger ensembles. One of the results has been      ideally suited for representing architectural concepts, and
              an architectural interchange language, called Acme, which         there are likely to be fewer opportunities for automated
              provides a simple framework for describing architectural          analysis of architectural properties.
              structure and a flexible annotation mechanism for adding
              semantics to that structure [18]. (Acme can be viewed as          4.2  Product Lines and Standards
              the XML of architectural description.) Acme also supports         As noted earlier, one of the important trends has been the
              the definition of styles and enforcement of design con-           desire to exploit commonality across multiple products.
              straints through its tools.                                       Two specific manifestations of that trend are improvements
                                                                                in our ability to create product lines within an organization
              More ambitious still, a number of researchers have begun          and the emergence of cross-vendor integration standards.
              to look at additional ways of integrating architecture-based
              tools. The result promises to be a flexible "ADL Toolkit’’        With respect to product lines, a key challenge is that a
              that will allow practitioners to create domain-specific ar-       product line approach requires different methods of devel-
              chitectural design environments largely by combining the          opment. In a single-product approach the architecture must
              capabilities of existing tools. Other efforts have sought to      be evaluated with respect to the requirements of that prod-
              integrate architectural development tools with other tool-        uct alone. Moreover, single products can be built independ-
              supported aspects of software development, such as re-            ently, each with a different architecture.
              quirements elicitation and resolution [7].
                                                                                However, in a product line approach, one must also con-
              Languages explicitly designed with software architecture in       sider requirements for the family of systems, and the rela-
              mind are not the only approach.  There has been consider-         tionship between those requirements and the ones associ-
              able interest in using general-purpose object design nota-        ated with each particular instance.  Figure 3 illustrates this
              tions for architectural modeling [8, 24]. Moreover, recently      relationship. In particular, there must be an up-front (and
              there have been a number of proposals that attempt to show        on-going) investment in developing a reusable architecture
              how the concepts found in ADLs can be mapped directly             that can be instantiated for each product. Other reusable
              into an object-oriented notation like UML [29, 23, 17].           assets, such as components, test suites, tools, etc., typically
              These alternatives are illustrated in Figure 2.                   accompany this.
                                     Requirements                                         Product                         Product
                                                                                       Requirements                     Architecture
                                A                    B
                       Architecture        C                                                                  induced
                                                   Architecture                                                   constraint
                        in an ADL                     in UML
                                D                     E                                Product Line                     Product Line
                                                                                       Requirements                     Architecture
                                         Code
                                                                                           Figure 3:  Product Line Architectures
                      Figure 2:  Software Architecture as a Bridge              Although product line engineering is not yet widespread,
                                                                                we are beginning to have a better understanding of the pro-
              Path A-D is one in which an ADL is used as the modeling           cesses, economics, and artifacts required to achieve the
              language. Path B-E is one in which UML is used as the             benefits of a product line approach. A number of case
              modeling notation. Path A-C-E, is one in which an archi-          studies of product line successes have been published. (For
              tecture is first represented in an ADL, but then transformed      example, see [13].)  Moreover, organizations such as the
              into UML before producing an implementation.                      Software Engineering Institute are well on their way to-
                                                                                wards providing concrete guidelines and processes for the
              Using a more general modeling language such as UML has            use of a product line approach [37].
              the advantages of providing a notation that practitioners are
              more likely to be familiar with, and providing a more direct      Like product line approaches, cross-vendor integration
              link to object-oriented implementations and development           standards require architectural frameworks that permit a
The words contained in this file might help you see if this file matches what you are looking for:

...Software architecture a roadmap david garlan school of computer science carnegie mellon university forbes avenue pittsburgh pa cs cmu edu abstract design regular conferences and workshops devoted speci over the past decade has received fically to growing number com increasing attention as an important subfield mercial tools aid in aspects architectural engineering during that time there been considerable courses major government progress developing technological methodologi industrial research projects centered on architec cal base for treating ture formal stan discipline however much remains be done achieve dards codification principles methods goal moreover changing face technology raises practices begun lead repeatable processes new challenges this criteria making principled tradeoffs paper examines some trends among architectures standards documenting re practice speculates viewing implementing emerging aspirations despite disciplines keywords go field relatively immature while out...

no reviews yet
Please Login to review.