% % GENERATED FROM http://acme.able.cs.cmu.edu % by : anonymous % IP : ec2-44-213-75-78.compute-1.amazonaws.com % at : Thu, 28 Mar 2024 18:17:24 -0400 GMT % % Selection : Year = 1995 % @InProceedings{Schmerl1995, AUTHOR = {Schmerl, Bradley and Marlin, Chris}, TITLE = {Configuration management for dynamically bound systems}, YEAR = {1995}, MONTH = {April}, BOOKTITLE = {Proceedings of the 5th Workshop on Software Configuration Management}, ADDRESS = {Seattle, WA} } @InCollection{Schmerl1995a, AUTHOR = {Schmerl, Bradley and Marlin, Chris}, TITLE = {Designing configuration management facilities for dynamically bound systems}, YEAR = {1995}, BOOKTITLE = {Software Configuration Management: ICSE SCM-4 and SCM-5 Workshops - Selected Papers}, VOLUME = {1005}, PAGES = {88-100}, EDITOR = {Estublier, Jacky}, SERIES = {Lecture Notes in Computer Science}, PUBLISHER = {Spring-Verlag} } @Article{Garlan95TSE-intro, AUTHOR = {Garlan, David and Perry, Dewayne}, TITLE = {Introduction to the Special Issue on Software Architecture}, YEAR = {1995}, MONTH = {April}, JOURNAL = {IEEE Transactions on Software Engineering}, KEY = {Garlan}, VOLUME = {21}, NUMBER = {4}, PDF = {http://www.cs.cmu.edu/afs/cs/project/able/ftp/saintro-tse95/saintro-tse95.pdf}, ABSTRACT = {A critical aspect of the design for any large software system is its gross structure represented as a high-level organization of computational elements and interactions between those elements. Broadly speaking, this is the software architectural level of design. The structure of software has long been recognized as an important issue of concern. However, recently software architecture has begun to emerge as an explicit field of study for software engineering practitioners and researchers. Evidence of this trend is apparent in a large body of recent work in research such as module interface languages, domain specific architectures, architectural description languages, design patterns and handbooks, formal underpinnings for architectural design, and architectural design environments. This IEEE Transactions on Software Engineering Special Issue on Software Architecture presents seven papers that illustrate many of these emerging research areas.}, KEYWORDS = {Software Architecture} } @InProceedings{Garlan95Dagstuhl, AUTHOR = {Garlan, David}, TITLE = {What is Style?}, YEAR = {1995}, MONTH = {February}, BOOKTITLE = {Proceedings of the Dagstuhl Workshop on Software Architecture}, KEY = {David Garlan}, ADDRESS = {Saarbruecken, Germany}, PDF = {http://www.cs.cmu.edu/afs/cs/project/able/ftp/style-iwass95/style-iwass95.pdf}, PS = {http://www.cs.cmu.edu/afs/cs/project/able/ftp/style-iwass95/style-iwass95.ps}, ABSTRACT = {A central aspect of architectural design is the use of recurring organizational patterns and idioms- or architectural styles. Examples include generic system organizations such as those based on dataflow or layers, as well as specific organizational structures such as the classical decomposition of a compiler, the OSI communication stack, and the MVC user interface paradigm. The principled use of architectural styles has a number of practical benefits. First, it promotes design reuse: routine solutions with well-understood properties can be reapplied to new problems with confidence. Second, it can lead to significant code reuse: often the invariant aspects of an architectural style lend themselves to shared implementations. Third, it is easier for others to understand a system's organization if conventionalized structures are used. For example, even without giving details, characterization of a system as a 'client-server' organization immediately conveys a strong image of the kinds of pieces and how they fit together. Fourth,use of standardized styles supports interoperability. Examples include CORBA object-oriented architecture, and event-based tool integration. Fifth, by constraining the design space, an architectural style often permits specialized,style-specific analyses. For example, it is possible to analyze pipe-filter systems for schedulability, throughput, latency, and deadlock-freedom. Such analyses might not be meaningful for an arbitrary, ad hoc architecture - or even one constructed in a different style. Sixth, it is usually possible to provide style-specific visualizations: this makes it possible to provide graphical and textual renderings that match engineers' domain-specific intuitions about how their designs should be depicted. }, KEYWORDS = {Architectural Style, Software Architecture} } @InProceedings{Allen96IWSSD, AUTHOR = {Allen, Robert}, TITLE = {Formalism and Informalism in Architectural Style: A Case Study}, YEAR = {1995}, MONTH = {April}, BOOKTITLE = {Proceedings of the First International Workshop on Architectures for Software Systems}, KEY = {Garlan}, ABSTRACT = {Increasingly, developers look to software architecture to help them control the complexity of their systems. When developing a particular system, designers tend not to explore all possible alternatives for its architecture. Instead, they use specific patterns and idioms that are effective for the domain in which they are working. We term such a collection of patterns and idioms an architectural style. Unfortunately, with few exceptions current exploitation of architectural style is informal and ad hoc. In this paper we consider an alternative to the ad hoc description of architectural styles, a formal description based on the inherent structure of software architectures. We explore this solution by describing Justo and Cunha's message passing style in Wright, an architecture description language based on CSP. }, KEYWORDS = {Architectural Style, Software Architecture} } @InProceedings{Garlan95ICSE-17, AUTHOR = {Garlan, David and Allen, Robert and Ockerbloom, John}, TITLE = {Architectural Mismatch, or, Why it's hard to build systems out of existing parts}, YEAR = {1995}, MONTH = {April}, BOOKTITLE = {Proceedings of the 17th International Conference on Software Engineering}, KEY = {Garlan}, PAGES = {179-185}, ADDRESS = {Seattle, Washington}, PDF = {http://www.cs.cmu.edu/afs/cs/project/able/ftp/archmismatch-icse17/archmismatch-icse17.pdf}, ABSTRACT = {Many would argue that future breakthroughs in software productivity will depend on our ability to combine existing pieces of software to produce new applications. An important step towares this goal is the development of new techniques to detect and cope with mismatches in the assembled parts. Some problems of composition are due to low-level issues of interoperability, such as mismatches in programming languages or database schemas. However, in this paper we highlight a different, and in many ways more pervasive, class of problem: architectural mismatch. Specifically, we use our experience in building a family of software design environments from existing parts to illustrate a variety of types of mismatch that center around the assumptions a reusable part makes about the structure of the application in which is to appear. Based on this experience we show how an architectural view of the mismatch problem exposes some fundamental, thorny problems for software composition and suggests possible research avenues needed to solve them.}, NOTE = {A revised and extended version of this paper appeared in <a href=http://ieeexplore.ieee.org/iel1/52/9910/00469757.pdf><i>IEEE Software</i>, Volume 12, Issue 6, Nov. 1995 (pp. 17-26)</a>. This paper was awarded an ACM SIGSOFT Impact Paper Award in 2011.}, KEYWORDS = {Architectural Style, Landmark, Software Architecture} } @Article{IEEE1995/reuse, AUTHOR = {Garlan, David and Allen, Robert and Ockerbloom, John}, TITLE = {Architectural Mismatch: Why Reuse is so Hard}, YEAR = {1995}, JOURNAL = {IEEE Software}, VOLUME = {12}, NUMBER = {6}, PAGES = {17-26}, KEYWORDS = {Software Architecture} } @Article{Abowd1995, AUTHOR = {Abowd, Gregory and Allen, Robert and Garlan, David}, TITLE = {Formalizing Style to Understand Descriptions of Software Architecture}, YEAR = {1995}, MONTH = {October}, JOURNAL = {ACM Transactions on Software Engineering and Methodology}, VOLUME = {4}, NUMBER = {4}, PAGES = {319-364}, PDF = {http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/ftp/styleformalism-tosem95/styleformalism-tosem95.pdf}, PS = {http://www.cs.cmu.edu/afs/cs.cmu.edu/project/able/ftp/styleformalism-tosem95/styleformalism-tosem95.ps}, ABSTRACT = {The software architecture of most systems is usually described informally and diagrammatically by means of boxes and lines. In order for these descriptions to be meaningful, the diagrams are understood by interpreting the boxes and lines in specic, conventionalized ways. The informal, imprecise nature of these interpretations has a number of limitations. In this paper we consider these conventionalized interpretations as architectural styles and provide a formal framework for their uniform denition. In addition to providing a template for precisely dening new architectural styles, this framework allows for analysis within and between dierent architectural styles.}, KEYWORDS = {Architectural Analysis, Architectural Style, Landmark, Software Architecture} } @InCollection{Shaw1995, AUTHOR = {Shaw, Mary and Garlan, David}, TITLE = {Formulations and Formalisms in Software Architecture}, YEAR = {1995}, BOOKTITLE = {Computer Science Today: Recent Trends and Developments}, VOLUME = {1000}, PAGES = {307-323}, EDITOR = {Van Leeuwen, Jan}, SERIES = {Lecture Notes in Computer Science}, PUBLISHER = {Spring-Verlag}, PDF = {http://www.cs.cmu.edu/afs/cs/project/able/ftp/saformalisms-lncs1000/saformalisms-lncs1000.pdf}, PS = {http://www.cs.cmu.edu/afs/cs/project/able/ftp/saformalisms-lncs1000/saformalisms-lncs1000.ps}, ABSTRACT = {Software architecture is the level of software design that ad- dresses the overall structure and properties of software systems. It provides a focus for certain aspects of design and development that are not appropriately addressed within the constituent modules. Architectural design depends heavily on accurate specications of subsystems and their interactions. These specications must cover a wide variety of properties, so the specication notations and associated methods must be selected or developed to match the properties of interest. Unfortunately, the available formal methods are only a partial match for architectural needs, which entail description of structure, packaging, environmental assumptions, representation, and performance as well as functionality. A prerequisite for devising or selecting a formal method is sound understanding of what needs to be formalized. For software architecture, much of this understanding is arising through progressive codication, which begins with real-world examples and creates progressively more precise models that eventually support formalization. This paper explores the pro- gressive codication of software architecture: the relation between emerging models and the selection, development, and use of formal systems.}, KEYWORDS = {Software Architecture} } @InCollection{Garlan1995, AUTHOR = {Garlan, David and Shaw, Mary}, TITLE = {An Introduction to Software Architecture}, YEAR = {1995}, BOOKTITLE = {Advances in Software Engineering and Knowledge Engineering}, VOLUME = {2}, EDITOR = {Ambriola, V and Tortora, G}, SERIES = {Series on Software Engineering and Knowledge Engineering}, PUBLISHER = {World Scientific Publishing Company}, PDF = {http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf}, PS = {http://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.ps}, 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. }, NOTE = {Also available as: Carnegie Mellon University Technical Report CMU-CS-94-166, January 1994. Reprinted in CMIS 460: Software Design and Development Faculty Course Guide, University of Maryland, Office of Instructional Development, Summer 1995}, KEYWORDS = {Architectural Style, Software Architecture, Software Engineering} }