Software Architecture - an Overview of the State-Of-The-Art

Research Report 8/98 Software Architecture - An Overview of the State-of-the-Art by Jan Bosch (Editor) Department of ISSN 1103-1581 Computer Science and Business Administration ISRN HK/R-RES98/8SE University of Karlskrona/Ronneby S-372 25 Ronneby Sweden Software Architecture - An Overview of the State-of-the-Art by Jan Bosch (Editor) ISSN 1103-1581 ISRN HK/R-RES98/8SE Copyright © 1998 the authors All rights reserved Printed by Psilander Grafiska, Karlskrona 1998 Table of Contents Introduction..........................................................................................................................3 Jan Bosch Architecture Description Software Architecture Notations..........................................................................................5 Anders Ive Using Formal Languages to Describe Software Architecture...........................................13 Patrik Persson Architecture Evaluation Evaluating Software Architectures: Techniques................................................................23 Magnus Broberg Evaluating Quality Attributes of Software Architectures..................................................35 Charlie Svahnberg Architecture Design The Role of Styles and Patterns in Software Architectures...............................................45 Daniel Einarson Software Architecture Design Methods.............................................................................55 PO Bengtsson Software Architecture Applications Software Product-Line Architecture..................................................................................63 Michael Mattsson DSSA: Object-Oriented Frameworks................................................................................71 Christer Lundberg Birds of Different Feather - An Essay on Components and Components.........................81 Erik Persson 1 Introduction Jan Bosch University of Karlskrona/Ronneby Department of Computer Science and Business Administration S-372 25 Ronneby, Sweden E-mail: [email protected] WWW: http://www.ide.hk-r.se/~bosch/ 1 Software Architecture mented, tests are performed to determine whether the requirements are fulfilled. If not, parts of the system are During recent years, the architecture of software systems redesigned. Since the system architects often are experi- has been treated more explicit than earlier and has become enced in building systems in the domain, experience helps recognised as a research topic. Software systems have them to decrease the required amount of system redesign. always had architectures, but most software engineers and Nevertheless, redesigns are often needed and tend to be researchers focused on different aspects, although excep- very costly. Computer science and software engineering tions exist, e.g. [Parnas 72]. In [Bass et al. 98], software research, on the other hand, has spent considerable effort on architecture is defined as follows: several of the quality requirements, e.g. the real-time systems research community has put much focus on hard real- The software architecture of a program or time systems and the object-oriented research community computing system is the structure or struc- has studied software reuse. The problem is, we believe, that tures of the system, which comprise software each research community only studies a single quality sys- components, the externally visible properties tem requirement and, consequently, not addresses the com- of those components, and the relationships position of its solutions with the solutions proposed by among them. research communities studying different quality requirements. However, real systems never have only a single qual- Often a parallel is made to building architecture, where the ity requirement to fulfil, but generally have to achieve architect has a similar task of defining an underlying struc- multiple of these requirements. For instance, most real-time ture and style for a building that has to fulfil the require- systems should be reusable and maintainable to achieve ments expressed by the various stakeholders. cost-effective operation and usage, whereas fault-tolerant systems also need to fulfil other requirements such as time- The reason for this increased focus on software architecture liness and maintainability. No pure real-time, fault-tolerant, is caused primarily of two issues. First, an explicit software high-performance or reusable computing systems exist, architecture provides an important meeting point for the even though most research literature tends to present sys- stakeholders of a software systems and allows them to iden- tems as being such archetypical entities. All realistic, prac- tify differences in interpretation and intention early in the tical computing systems have to fulfil multiple quality development process. Second, the ability of a system to ful- requirements. However, constructing such systems is hard fil its quality requirements, e.g. reliability, maintainability, because the quality requirements tend to be conflicting. etc., is heavily influenced by its architecture. The architec- Reusability and performance are generally considered to be ture chosen for the software system has associated upper contradicting, as well as fault-tolerance and real-time com- limits to many quality requirements. To give a simple exam- puting, to name a few. For a more extensive discussion, I ple, in an architectural design that we evaluated there was a refer the reader to [Bosch & Molin 97]. central entity in the system that played a role in most com- putations. This bottleneck entity caused theoretical and practical upper limits on the performance and reliability of the system. A redesign of the architecture removed the bot- 2 The Course tleneck and allowed for considerably better upper limits. Based on the above, it is safe to conclude that research in In software industry, our experience is that quality require- software architecture is an important topic in the domain of ments are generally dealt with by a rather informal process software engineering. Especially if one considers that archi- during architecture design. Once the system is imple- tectural design mistakes are generally very expensive to fix. 3 Again, the parallel to building architecture is obvious: if different path at similar concepts. In the CBSE community, changes are required to the fundamental structures of a the notion of component frameworks has now generally building, it basically means starting again from scratch. The been accepted as a necessary element in successful compo- industrial relevance of software architecture and the fact nent-based software development. Component frameworks, that it is an emerging topic in software engineering research however, explicitly define a software architecture of an called for doctoral course on the topic. application or a part of it. Due to this relation, the common- alities and differences between CBSE and approaches in the The domain of software architecture can be divided into software architecture community were investigated. two main categories, i.e. core technology and instantia- tions. Core technology defines, as the name implies, the necessary principles, techniques and methods has three sub- categories related to describing, evaluating and designing 3 The Report architectures. Architecture description can be approached The research report that you’re currently holding represents from two ends, i.e., notations used for communication part of the result of the course. Other parts, hopefully, between software engineers and with other stakeholders include the increased knowledge and deepened understand- and architecture description languages used for automated ing of the participating PhD students. Each student selected architecture evaluation and verification and code genera- one of the nine topics discussed above. The student was tion. Architecture evaluation can also be treated from two supposed to get acquainted with the selected topic by read- perspectives. First, one can take a technique perspective ing articles from the compendium and articles found and develop and study various techniques for architecture through active searching, and, based on the acquired knowl- evaluation. Second, the various quality requirements com- edge, prepare a two-hour lecture and lead a two-hour dis- munities, e.g., real-time, reuse, etc., have developed assess- cussion. Finally, each student has written an article ment and evaluation techniques and one can try to lift these presenting the state-of-the-art for the selected topic. During techniques to the architectural level. Finally, even architec- the final seminar, the students presented their article for a tural design can be addressed from two ends. First, consid- wider audience. erable effort have been spent on identifying and describing architectural styles and patterns. These structures support or The chapters in this research report, thus, provide an over- inhibit associated properties and during architectural view of the most prominent work in software architecture. design, the software engineer selects a style matching clos- Each of the papers has been carefully prepared to facilitate est with the requirements that the software system has to the reader to efficiently get an accurate overview and an fulfil. The second dimension in architectural design is understanding of the research issues. We hope you enjoy formed by methods. These architecture design methods reading the articles and find that they contain relevant con- provide

Load more