DOCSLIB.ORG

ARCHITECTURAL STABILITY of SELF-ADAPTIVE SOFTWARE SYSTEMS By

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
ARCHITECTURAL STABILITY of SELF-ADAPTIVE SOFTWARE SYSTEMS By ARCHITECTURAL STABILITY OF SELF-ADAPTIVE SOFTWARE SYSTEMS by MARIA MOURAD EBEID MELEKA SALAMA A thesis submitted to The University of Birmingham for the degree of DOCTOR OF PHILOSOPHY School of Computer Science College of Engineering and Physical Sciences The University of Birmingham July 2018 University of Birmingham Research Archive e-theses repository This unpublished thesis/dissertation is copyright of the author and/or third parties. The intellectual property rights of the author or third parties in respect of this work are as defined by The Copyright Designs and Patents Act 1988 or as modified by any successor legislation. Any use made of information contained in this thesis/dissertation must be in accordance with that legislation and must be properly acknowledged. Further distribution or reproduction in any format is prohibited without the permission of the copyright holder. Abstract Stakeholders and organisations are increasingly interested in software longevity, given the increasing dependence on software systems. Stability is a long-term property of utmost strategic importance for any software system throughout its whole lifecycle, from design and implementation to actual operation, management, maintenance and evolution. A system, if engineered and developed with stability in mind, can provide a good basis for supporting runtime operation, technical changes and cost-effective maintenance and evolution. As architectures have a profound effect on the operational lifetime of the software and the quality of service provision, architectural stability could be considered a primary criterion towards achieving the longevity of the software. This thesis studies the notion of stability in software engineering with the aim of understanding its dimensions, facets and aspects, as well as characterising it. The thesis further investigates the aspect of behavioural stability at the architectural level, as a property concerned with the architecture's capability in maintaining the achievement of expected quality of service and accommodating runtime changes, in order to delay the architecture drifting and phasing-out as a consequence of the continuous unsuccessful provision of quality requirements. The research aims to provide a systematic and methodological support for analysing, modelling, designing and evaluating architectural stability. The novelty of this research is the consideration of stability during runtime operation, by focusing on the stable pro- vision of quality of service without violations. As the runtime dimension is associated with adaptations, the research investigates stability in the context of self-adaptive soft- ware architectures, where runtime stability is challenged by the quality of adaptation, which in turn affects the quality of service. The research evaluation focuses on the effec- tiveness, scale and accuracy in handling runtime dynamics, using the self-adaptive cloud architectures. To all those from whom I have learnt... D´edi´e`ala m´emoire de mon p`ere et ma grand-m`ere... Acknowledgements First and foremost, my enormous gratitude and thanks go to the Almighty God for his ever blessings. I am perpetually indebted in thanks to my supervisor Dr. Rami Bahsoon for his dedicated supervision, helpful and endless support, patience and motivation. His guidance has provided me with great help throughout my PhD and in every aspect of my research work. His kindness and care have encouraged me to stay on track. His outlook and comments have inspired me. My sincere thanks to my external supervisor Prof. Rajkumar Buyya for his support, insights and encouragements on my research. This work would never have been com- pleted without his support, warm welcome and dedication during the research visit and afterwards. His kindness, prudence and work of ethics have made me enjoy the research work with him. Special thanks to the members of my Thesis Group who took time to provide guidance. I would like to thank Prof. Xin Yao for his timely comments, and Dr. Dave Parker for his insightful and encouraging comments. Their critical eye, words of insight and perspective have greatly guided my research and helped in paving the way. I am also deeply indebted and grateful to Prof. Patricia Lago for lending me time with her great knowledge. Her enthusiasm for doing research, helpful cooperation and genuinely constructive comments were valuable and informed my research, in more ways than one. Acknowledges are given to all the administrative staff of the School of Computer Sci- ence for their great support, kindness and welcome throughout the PhD course, especially Patrycja Adams, Sarah Brookes and Helen Whitby. Thanks also to Peter Hancox, Dave Parker and Steve Vickers for their role as Research Students Tutor, as well as Jon Rowe and Andrew Howes for their role as Head of School. Thanks to the Research Committee for their support and listening, especially Achim Jung. Thanks to the people I have been fortunate to have throughout this fascinating journey. I would like to thank Dr. Tao Chen and Dr. Abdessalam Elhabbash for the stimulating and useful discussions. I would like also to thank Khulood, Bram, Mohab, Sara, Wad, Carlos and Satich, who made this period of my life so enjoyable. Special thanks to the people I met during my research visits. Thanks to the CLOUDS Lab at the University of Melbourne, especially Dr. Maria Rodriguez and Dr. Rodrigo Calheiros for the useful discussions. Thanks also to Dr. Giuseppe Procaccianti and Dr. Nelly Condori-Fernandez from the Software and Services research group at Vrije Universiteit Amsterdam for their support. The experience that I gained during those visits was very worthwhile and everyone there was very welcoming and always willing to help. Many thanks also to Dr. Amir Zeid for his continuous mentorship regardless of distance and busyness. I would like to express my sincere appreciation to Father John Yanny, who was always standing by my side, for his kindness, unconditional love and sincere support. Warm thanks to my friends who were always there, understanding and supportive during these years. Gratitude and sincere appreciation to my family for their continuous support. Im- mense thanks beyond measure to my mother for her dedicated and moral support. My gratefulness goes to my sister for her continuous encouragements. Never to forget my father, whom I owe where I am today. I acknowledge the School of Computer Science for providing me with the scholar- ship to pursue my doctoral studies. The research visit to the University of Melbourne was supported by the U21 PhD Scholarship and the CLOUDS Lab. The visits to Vrije Universiteit Amsterdam were supported by Stevie Jivani Student Development and the Software Architecture Summer School scholarships. Contents List of Figures ix List of Tables xii 1 Introduction 1 1.1 Motivation . .1 1.2 Research Problem and Questions . .2 1.3 Research Methodology . .4 1.4 Thesis Contributions . .5 1.4.1 Thesis Roadmap . .5 1.4.2 Summary of Contributions . .7 1.4.3 Publications . .9 1.5 Organisation of the Thesis . 10 2 Stability in Software Engineering: Taxonomy and Survey of the State- of-the-Art 12 2.1 Introduction . 12 2.2 Background . 13 2.2.1 Preliminaries and Basic Concepts . 13 2.2.2 Self-Adaptive Software Architectures . 15 2.3 The Notion of Stability . 16 2.4 The Survey Method . 18 2.5 Taxonomy for Characterising Stability as a Software Property . 19 2.6 Defining and Characterising Stability . 22 2.6.1 Definitions of Stability . 22 2.6.2 Related Quality Attributes . 26 2.6.3 Related Software Engineering Practices . 30 2.7 Stability in Software Engineering . 32 2.7.1 Analysis Results of Primary Studies . 32 2.7.2 Levels, Aspects and Purposes of Stability . 35 2.7.3 Main Observations and Findings . 46 2.8 Engineering Practices Supporting Architectural Stability . 49 2.8.1 Architecture Analysis and Design . 49 2.8.2 Architecture Evaluation for Stability . 50 2.9 Gap Analysis . 55 2.10 Related surveys . 57 2.11 Summary and Conclusion . 57 iv 3 Characterising the Notion of Stability in Software Engineering 59 3.1 Introduction . 59 3.2 A Working Definition for Stability . 60 3.3 A Multi-Dimensional Perspective for Characterising Stability . 60 3.3.1 Dimensions of Stability . 61 3.3.2 Engineering Stability as a Software Property . 61 3.4 Requirements for Realising Stability at the Architecture Level . 64 3.4.1 Design-time Requirements . 65 3.4.2 Runtime Requirements . 67 3.4.3 Support-related Requirements . 70 3.5 Conceptual Design for Capturing Behavioural Stability . 71 3.6 Summary . 72 4 Analysing Architectural Stability 73 4.1 Introduction . 73 4.2 Stability Analysis . 74 4.3 Methodological Support for Analysing Behavioural Stability . 76 4.4 An Evaluation of Applicability . 77 4.4.1 Architecture Domain . 77 4.4.2 Application of the Analysis Model . 78 4.4.3 Discussion . 80 4.5 Related Work . 81 4.6 Summary . 81 5 Modelling Behavioural Stability of Architectures 82 5.1 Introduction . 82 5.2 Stability Modelling . 83 5.2.1 Stability Probabilistic Model . 84 5.2.2 Stability Runtime Inference . 86 5.2.3 Complexity Analysis of the Model . 87 5.3 Methodological Support for Modelling Behavioural Stability . 88 5.4 An Evaluation of Applicability . 90 5.4.1 Building the Stability Model . 90 5.4.2 Pre-experiments Setup . 90 5.4.3 Results of the Stability Model . 94 5.5 Experimental Evaluation . 99 5.5.1 Experiments Setup . 99 5.5.2 Results of Stability Goals . 100 5.5.3 Results of Adaptation Properties and Overhead . 101 5.5.4 Complexity and Runtime Overhead . 103 5.5.5 Discussion . 104 5.6 Related Work . 105 5.7 Summary . 105 v 6 Reference Architecture and Goals Modelling for Stability 107 6.1 Introduction . 107 6.2 Background . 109 6.2.1 Self-Awareness and Self-Expression . 109 6.2.2 Runtime Goal Models . 110 6.3 Self-aware Reference Architecture for Stability .
Load more

Recommended publications
  • (Perry & Wolf 92) Software Architecture (Garlan & Shaw
    ICS 221, Winter 2001 Software Architecture Software Architecture (Perry & Wolf 92) “Architecture is concerned with the selection of architectural elements, their interactions, and the Software Architecture constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.” David S. Rosenblum ICS 221 “Design is concerned with the modularization and detailed interfaces of the design elements, their Winter 2001 algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.” Software Architecture Software Architecture (Garlan & Shaw 93) (Shaw & Garlan 96) “Software architecture is a level of design that goes “The architecture of a software system defines beyond the algorithms and data structures of the that system in terms of computational computation; designing and specifying the overall components and interactions among those system structure emerges as a new kind of problem. Structural issues include gross organization and components. … In addition to specifying the global control structure; protocols for communication, structure and topology of the system, the synchronization, and data access; assignment of architecture shows the correspondence functionality to design elements; physical between the requirements and elements of distribution; composition of design elements; scaling the constructed system, thereby providing and performance; and selection among design some rationale for the design decisions.” alternatives.” Analogies with Differences Between Civil and Civil Architecture Software Architecture Civil Engineering and Civil Architecture “Software systems are like cathedrals—first we are concerned with the engineering and design of build them and then we pray.” civic structures (roads, buildings, bridges, etc.) — Sam Redwine ! Multiple views ! Civil: Artist renderings, elevations, floor plans, blueprints ! Physical vs.
    [Show full text]
  • Designing Software Architecture to Support Continuous Delivery and Devops: a Systematic Literature Review
    Designing Software Architecture to Support Continuous Delivery and DevOps: A Systematic Literature Review Robin Bolscher and Maya Daneva University of Twente, Drienerlolaan 5, Enschede, The Netherlands [email protected], [email protected] Keywords: Software Architecture, Continuous Delivery, Continuous Integration, DevOps, Deployability, Systematic Literature Review, Micro-services. Abstract: This paper presents a systematic literature review of software architecture approaches that support the implementation of Continuous Delivery (CD) and DevOps. Its goal is to provide an understanding of the state- of-the-art on the topic, which is informative for both researchers and practitioners. We found 17 characteristics of a software architecture that are beneficial for CD and DevOps adoption and identified ten potential software architecture obstacles in adopting CD and DevOps in the case of an existing software system. Moreover, our review indicated that micro-services are a dominant architectural style in this context. Our literature review has some implications: for researchers, it provides a map of the recent research efforts on software architecture in the CD and DevOps domain. For practitioners, it describes a set of software architecture principles that possibly can guide the process of creating or adapting software systems to fit in the CD and DevOps context. 1 INTRODUCTION designing new software architectures tailored for CD and DevOps practices. The practice of releasing software early and often has For clarity, before elaborating on the subject of been increasingly more adopted by software this SLR, we present the definitions of the concepts organizations (Fox et al., 2014) in order to stay that we will address: Software architecture of a competitive in the software market.
    [Show full text]
  • Software Engineering (SE) 1
    Software Engineering (SE) 1 SE 352 | OBJECT-ORIENTED ENTERPRISE APPLICATION DEVELOPMENT SOFTWARE ENGINEERING | 4 quarter hours (Undergraduate) (SE) This course focuses on applying object-oriented techniques in the design and development of software systems for enterprise applications. Topics SE 325 | INTRODUCTION TO SOFTWARE ENGINEERING | 4 quarter hours include component architecture, such as Java Beans and Enterprise (Undergraduate) Java Beans, GUI components, such as Swing, database connectivity and This course introduces students to the activities performed at each object repositories, server application integration using technologies stage of the development process so that they can understand the full such as servlets, Java Server Pages, JDBC and RMI, security and lifecycle context of specific tasks such as coding and testing. Topics will internationalization. PREREQUISITE(S): CSC 301. include software development processes, domain modeling, requirements CSC 301 is a prerequisite for this class. elicitation and specification, architectural design and analysis, product SE 356 | SOFTWARE DEVELOPMENT FOR MOBILE AND WIRELESS and process level metrics, configuration management, quality assurance SYSTEMS | 4 quarter hours activities including user acceptance testing and unit testing, project (Undergraduate) management skills such as risk analysis, effort estimation, project This course will focus on the unique aspects of developing software release planning, and software engineering ethics. applications for mobile and wireless systems, such as personal digital CSC 301 or CSC 393 is a prerequisite for this class. assistant (PDA) devices and mobile phones. Topics will include user SE 330 | OBJECT ORIENTED MODELING | 4 quarter hours interface design for small screens with restricted input modalities, data (Undergraduate) synchronization for mobile databases as well as wireless programming Object-oriented modeling techniques for analysis and design.
    [Show full text]
  • Composition of Software Architectures Christos Kloukinas
    Composition of Software Architectures Christos Kloukinas To cite this version: Christos Kloukinas. Composition of Software Architectures. Computer Science [cs]. Université Rennes 1, 2002. English. tel-00469412 HAL Id: tel-00469412 https://tel.archives-ouvertes.fr/tel-00469412 Submitted on 1 Apr 2010 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Composition of Software Architectures - Ph.D. Thesis - - Presented in front of the University of Rennes I, France - - English Version - Christos Kloukinas Jury Members : Jean-Pierre Banâtre Jacky Estublier Cliff Jones Valérie Issarny Nicole Lévy Joseph Sifakis February 12, 2002 Résumé Les systèmes informatiques deviennent de plus en plus complexes et doivent offrir un nombre croissant de propriétés non fonctionnelles, comme la fiabi- lité, la disponibilité, la sécurité, etc.. De telles propriétés sont habituellement fournies au moyen d’un intergiciel qui se situe entre le matériel (et le sys- tème d’exploitation) et le niveau applicatif, masquant ainsi les spécificités du système sous-jacent et permettant à des applications d’être utilisées avec dif- férentes infrastructures. Cependant, à mesure que les exigences de propriétés non fonctionnelles augmentent, les architectes système se trouvent confron- tés au cas où aucun intergiciel disponible ne fournit toutes les propriétés non fonctionnelles visées.
    [Show full text]
  • Download Distributed Systems Free Ebook
    DISTRIBUTED SYSTEMS DOWNLOAD FREE BOOK Maarten van Steen, Andrew S Tanenbaum | 596 pages | 01 Feb 2017 | Createspace Independent Publishing Platform | 9781543057386 | English | United States Distributed Systems - The Complete Guide The hope is that together, the system can maximize resources and information while preventing failures, as if one system fails, it won't affect the availability of the service. Banker's algorithm Dijkstra's algorithm DJP algorithm Prim's algorithm Dijkstra-Scholten algorithm Dekker's algorithm generalization Smoothsort Shunting-yard algorithm Distributed Systems marking algorithm Concurrent algorithms Distributed Systems algorithms Deadlock prevention algorithms Mutual exclusion algorithms Self-stabilizing Distributed Systems. Learn to code for free. For the first time computers would be able to send messages to other systems with a local IP address. The messages passed between machines contain forms of data that the systems want to share like databases, objects, and Distributed Systems. Also known as distributed computing and distributed databases, a distributed system is a collection of independent components located on different machines that share messages with each other in order to achieve common goals. To prevent infinite loops, running the code requires some amount of Ether. As mentioned in many places, one of which this great articleyou cannot have consistency and availability without partition tolerance. Because it works in batches jobs a problem arises where if your job fails — Distributed Systems need to restart the whole thing. While in a voting system an attacker need only add nodes to the network which is Distributed Systems, as free access to the network is a design targetin a CPU power based scheme an attacker faces a physical limitation: getting access to more and more powerful hardware.
    [Show full text]
  • Introduction to Software Architecture
    Introduction to Software Architecture Imed Hammouda Chalmers | University of Gothenburg Who am I? • Associate Professor of Software Engineering, previously in Tampere, Finland • Research interests – Software Architecture, Open Source, Software Ecosystems, Software Development Methods and Tools, Variability Management • Developing and supporting open software architectures • Studying socio-technical dependencies in software development • Software ecosystems • Coordinates: [email protected], [email protected] • Room 416, floor 4, Jupiter building, Campus Lindholmen • Phone +46 31 772 60 40 Introduction to Software Architecture 2 • What is software architecture? • Architectural drivers • Addressing architectural drivers • Architectural views • Example system Introduction to Software Architecture 3 What is Software Architecture? • Software Architecture is the global organization of a software system, including – the division of software into subsystems/components, – policies according to which these subsystems interact, – the definition of their interfaces. T. C. Lethbridge & R. Laganière Introduction to Software Architecture 4 What is Software Architecture? • "The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them." Len Bass Introduction to Software Architecture 5 What is Software Architecture? • “fundamental concepts or properties of a system in its environment
    [Show full text]
  • The Software Architect -And the Software Architecture Team
    The Software Architect -and the Software Architecture Team Philippe Kruchten Rational Software, 650 West 41st Avenue #638, Vancouver, B.C., V5Z 2M9 Canada pbk@ rational. com Key words: Architecture, architect, team, process Abstract: Much has been written recently about software architecture, how to represent it, and where design fits in the software development process. In this article I will focus on the people who drive this effort: the architect or a team of architects-the software architecture team. Who are they, what special skills do they have, how do they organise themselves, and where do they fit in the project or the organisation? 1. AN ARCHITECT OR AN ARCHITECTURE TEAM In his wonderful book The Mythical Man-Month, Fred Brooks wrote that a challenging project must have one architect and only one. But more recently, he agreed that "Conceptual integrity is the vital property of a software product. It can be achieved by a single builder, or a pair. But that is too slow for big products, which are built by teams."' Others concur: "The greatest architectures are the product of a single mind or, at least, of a very small, carefully structured team."2 More precisely: "Every project should have exactly one identifiable architect, although for larger projects, the principal architect should be backed up by an architecture team of modest size."3 1 Keynote address, ICSE-17, Seattle, April1995 2 Rechtin 1991 , p. 22 3 Booch 1996, p. 196 The original version of this chapter was revised: The copyright line was incorrect. This has been corrected. The Erratum to this chapter is available at DOI: 10.1007/978-0-387-35563-4 35 P.
    [Show full text]
  • Um Livro-Texto Para O Ensino De Projeto De Arquitetura De Software
    Universidade Federal de Campina Grande Centro de Engenharia Elétrica e Informática Curso de Pós-Graduação em Ciência da Computação Um Livro-texto para o Ensino de Projeto de Arquitetura de Software Guilherme Mauro Germoglio Barbosa Dissertação submetida à Coordenação do Curso de Pós-Graduação em Ciência da Computação da Universidade Federal de Campina Grande - Campus I como parte dos requisitos necessários para obtençãodograu de Mestre em Ciência da Computação. Área de Concentração: Ciência da Computação Linha de Pesquisa: Engenharia de Software Jacques P. Sauvé (Orientador) Campina Grande, Paraíba, Brasil !c Guilherme Mauro Germoglio Barbosa, 04/09/2009 FICHA CATALOGRÁFICA ELABORADA PELA BIBLIOTECA CENTRAL DA UFCG B238l 2009 Barbosa, Guilherme Mauro Germoglio Um livro-texto para o ensino de projeto de arquitetura de software / Guilherme Mauro Germoglio Barbosa. ! Campina Grande, 2009. 209 f. : il. Dissertação (Mestrado em Ciência da Computação) – Universidade Federal de Campina Grande, Centro de Engenharia Elétrica e Informática. Referências. Orientadores: Prof. Dr. Jacques P. Sauvé. 1. Arquitetura de Software 2. Engenharia de Software 3. Projeto 4. Ensino I. Título. CDU – 004.415.2(043) Resumo Aarquiteturadesoftwareéaorganizaçãofundamentaldeumsistema, representada por seus componentes, seus relacionamentos com o ambiente, e pelos princípios que conduzem seu design e evolução. O projeto da arquitetura é importante no processo de desenvolvimento, pois ele orienta a implementação dos requisitos de qualidadedosoftwareeajudanocontrole intelectual sobre complexidade da solução. Além disso, serve como uma ferramenta de comunicação que promove a integridade conceitual entre os stakeholders. No entanto, os diversos livros adotados em disciplinas de Projeto de Arquitetura de Soft- ware assumem que o leitor tenha experiência prévia em desenvolvimento de software.
    [Show full text]
  • Modeling and Simulating a Software Architecture Design Space Charles W
    University of Massachusetts Amherst ScholarWorks@UMass Amherst Computer Science Department Faculty Publication Computer Science Series 1997 Modeling and Simulating a Software Architecture Design Space Charles W. Krueger Carnegie Mellon University Follow this and additional works at: https://scholarworks.umass.edu/cs_faculty_pubs Part of the Computer Sciences Commons Recommended Citation Krueger, Charles W., "Modeling and Simulating a Software Architecture Design Space" (1997). Computer Science Department Faculty Publication Series. 61. Retrieved from https://scholarworks.umass.edu/cs_faculty_pubs/61 This Article is brought to you for free and open access by the Computer Science at ScholarWorks@UMass Amherst. It has been accepted for inclusion in Computer Science Department Faculty Publication Series by an authorized administrator of ScholarWorks@UMass Amherst. For more information, please contact [email protected]. Modeling and Simulating a Software Architecture Design Space Charles W. Krueger December 1997 CMU-CS-97-158 School of Computer Science Computer Science Department Carnegie Mellon University Pittsburgh, PA Thesis Committee: A. Nico Habermann, deceased, Co-Chair David Garlan, Co-Chair Jeannette Wing Mahadev Satyanarayanan Lori Clarke, University of Massachusetts at Amherst Submitted in partial fulÞllment of the requirements for the Degree of Doctor of Philosophy © 1997 by Charles W. Krueger This research was sponsored by the Wright Laboratory, Aeronautical Systems Center, Air Force Materiel Command, USAF, and the Defense Advanced Research Projects Agency (DARPA) under grant number F33615-93-1-1330; by the Defense Advanced Research Projects Agency, and Rome Laboratory, Air Force Materiel Command, USAF, under agreement number F30602-97-2-0031; by the Defense Modeling and Simulation OfÞce; by ZFE of Siemens Corporation; and by National Science Foundation Grant No.
    [Show full text]
  • An Introduction to Software Architecture
    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.
    [Show full text]
  • Foundations for the Study of Software Architecture
    ACM SIGSOFT SOFTWARE ENGINEERING NOTES vol 17 no 4 Oct 1992 Page 40 Foundations for the Study of Software Architecture Alexander L. Wolf Dewayne E. Perry Department of Computer Science AT&T Bell Lab oratories University of Colorado 600 Mountain Avenue Boulder, Colorado 80309 Murray Hill, New Jersey 07974 [email protected] [email protected] c 1989,1991,1992 Dewayne E. Perry and Alexander L. Wolf ABSTRACT more toward integrating designs and the design pro cess into the broader context of the software pro cess and its management. One result of this integration was that The purp ose of this pap er is to build the foundation many of the notations and techniques develop ed for soft- for software architecture. We rst develop an intuition ware design have b een absorb ed by implementation lan- for software architecture by app ealing to several well- guages. Consider, for example, the concept of supp ort- established architectural disciplines. On the basis of ing \programmming-in-the-large". This integration has this intuition, we present a mo del of software architec- tended to blur, if not confuse, the distinction b etween ture that consists of three comp onents: elements, form, design and implementation. and rationale. Elements are either pro cessing, data, or The 1980s also saw great advances in our abilityto connecting elements. Form is de ned in terms of the describ e and analyze software systems. We refer here to prop erties of, and the relationships among, the elements | that is, the constraints on the elements. The ratio- such things as formal descriptive techniques and sophis- nale provides the underlying basis for the architecture in ticated notions of typing that enable us to reason more terms of the system constraints, which most often derive e ectively ab out software systems.
    [Show full text]
  • Debugging Software Architectures (SATURN 2008)
    Debugging Software Architectures Kyungsoo Im and John D. McGregor School of Computing Clemson University Clemson, SC 29634 Outline • Motivation • Related Work • Research Approach • Summary & Future Work 1 Motivation • An incorrect software architecture can lead to problems during development • Architecture descriptions are becoming larger and more detailed ‐> more possibility of bugs – Ex) Avionics Display System: 21,000 lines • Expensive to correct the software architecture in later stages • Goal: aid the software architect in locating known defects in software architectures Motivation Cost to fix defect Defect detected Image from CodeComplete 2nd edition by Steve McConnell 2 Related Work • Much work exists on software architecture analysis – Most only point out existence of defect and not its location • Debugging UML Designs • Little work on debugging software architectures – Visualization of event traces, Monitoring of events, Simulation – No clear definition, process, or method to debugging software architectures Research Approach • Define debugging at the architectural level • Develop a classification of architectural defects • Develop techniques for tracing a defect to its cause through debugging 3 Definitions • Mirror debugging at program level Test case Failure / Error Defect symptoms reveals caused by Debug to find location of defect Definitions • Software Architectural Error ‐ Difference exist between actual and expected software architecture • Software Architectural Failure ‐ Inability of a software architecture to meet a functional
    [Show full text]