DOCSLIB.ORG

Software Architecture

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Software Architecture 2016 Software Architecture Software Architecture Thinking §.§. The quality and longevity of a software- reliant system is largely determined by Architecture is of its architecture. enduring §.§. Recent US studies identify architectural importance issues as a systemic cause of software because it is the right abstraction problems in government systems (OSD, for performing NASA, NDIA, National Research ongoing analyses Council). throughout a ’ system s §.§. High-level system design providing system-level lifetime. structural abstractions and quality attributes, which help in managing complexity §.§. Makes engineering tradeoffs explicit 1 Quality Attributes Central Role of Architecture Quality attributes IMPLEMENT AND EVOLVE §.§. properties of work products or goods by which stakeholders judge their quality §.§. stem from business and mission goals. DESIGN IMPLEMENT §.§. need to be characterized in a system-specific way BUSINESS AND Quality attributes include MISSION GOALS ARCHITECTURE SYSTEM §.§. Performance §.§. Availability SATISFY CONFORM §.§. Interoperability §.§. Modifiability §.§. Usability §.§. Security SATISFY §.§. Etc. One View: Architecture-Centric Engineering Advancements Over the Years §.§. Architectural patterns §.§. Component-based approaches §.§. Company specific product lines §.§. Model-based approaches §.§. Frameworks and platforms §.§. Standard interfaces 2 What HAS Changed? Technology Trends §.§. Increased connectivity §.§. Scale and complexity − decentralization and distribution https://www.flickr.com/photos/simononly/ − “big data” https://www.flickr.com/photos/c − increased operational tempo − inter-reliant ecosystems − vulnerability − collective action §.§. Disruptive and emerging technologies 10 Software Development Trends Technical Challenges §.§. Application frameworks §.§. Open source §.§. Cloud strategies §.§. NoSQL §.§. Machine Learning §.§. MDD §.§. Incremental approaches §.§. Dashboards §.§. Distributed development environments §.§. DevOps 3 The Intersection and Architecture State of the Practice At the intersections there are difficult Focus is on tradeoffs to be made §.§. culture and teaming in structure, process, §.§. time, and cost. process and practices − value stream mapping − continuous delivery practices Architecture is the Lean thinking enabler for tradeoff − analyses. §.§. tooling, automation, and measurement − tooling to automate repetitive tasks − static analysis − automation for monitoring architectural health − performance dashboards Architecture and Scale Two Perspectives of Software Architecture in Cloud Computing n §.§. Cloud strategies n §.§. Cloud strategies for mobility n §.§. Big data Two potentially different sets of = business “Scale Changes Everything” goals and quality attributes 4 Mobile Device Trends Architecture Trends: Cyber-Foraging §.§. Edge Computing §.§. Using external resource-rich surrogates to augment the capabilities of resource-limited devices − code/computation offload − data staging §.§. Industry is starting to build on this concept to Nokia Siemens Networks improve mobile user experience and decrease Liquid Applications network traffic. §.§. Our research: cloudlet-based cyber- foraging Cisco Systems Fog Computing − brings the cloud closer to the user Big Data Systems Big Data – State of the Practice “The problem is not solved” §.§. Two very distinct but related technological thrusts Building scalable, assured big data systems is hard. − Data analytics − Infrastructure §.§. Analytics is typically a massive data reduction exercise – “data to decisions.” Building scalable, assured big data systems is expensive. §.§. Computation infrastructure necessary to ensure the analytics are − fast − scalable − secure easy to use − 40 5 Big Data Survey Architecture and Big Data §.§. System costs must grow more slowly than system capacity. §.§. Approaches − scalable software architectures − scalable software technologies − scalable execution platforms §.§. Scalability reduces as implementation complexity grows. §.§. NoSQL models are not created equal. §.§. You can’t manage what you http://visual.ly/cios-big-data don’t monitor. Architecture-Centric Summary Quality Attribute Analyses Single Annotated Architecture Model Addresses Impact Across Operational Quality Attributes n §.§. Software architecture Architecture Model principles and their Safety Reliability Security • MTBF • Intrusion importance persist. • FMEA • Integrity n §.§. Change brings new • Hazard Analysis • Confidentiality challenges. Auto-generated n §.§. Software architecture analytical models practices and research are Resource Data Quality key to meeting these Consumption • Data precision/accuracy Real-time Performance challenges. • Bandwidth • • Temporal correctness Execution time/deadline n §.§. Much remains to be • CPU time • Confidence • Deadlock/starvation done. • Power consumption • Latency 6 What to do with the data SW Stack: Architecture,Standards IoT Landscape EVERY Where 7 Class Book & References Other Referenced Sites n Classics: n Primary References: q Mary Shaw & David Garlan, Software Architecture: Perspectives on an Emerging q http://portal.acm.org/dl.cfm?coll=portal&dl=ACM&CFID=3943453&CFTOKEN=26992569 Discipline;, Prentice Hall, 1996. n (ACM Copyrighted Papers) q http://ieeexplore.ieee.org/Xplore/DynWel.jsp q Many IEEE, ACM, ELSEVIER, and Open Source papers n (IEEE Copyrighted papers) n Other references actively used: q http://www.sciencedirect.com/ q Evaluating Software Architectures: Methods & Case Studies, Addison-Wesley, ISBN n (Elsevier Copyrighted material) 020170482X. q http://citeseer.nj.nec.com/cs (Lots of open source materials) q Design & Use of Software Architectures: Adopting and Evolving a Product Line Approach: q http://www.sei.cmu.edu/str/ (Lots of open source materials) ISBN: 0201674947 q http://www-2.cs.cmu.edu/~able/publications/ (Lots of open source materials) q SEI Selected Papers: http://www.sei.cmu.edu/architecture/ q http://www.sei.cmu.edu/staff/rkazman/SE-papers.html (Lots of open source materials) q USC Selected Papers: http://sunset.usc.edu q http://www.cs.ukc.ac.uk/people/staff/cr3/bib/bookshelf/Modules.html n q UCI Selected Papers: http://www.ics.uci.edu (A ton of open source materials) q http://www2.umassd.edu/SECenter/SAResources.html (Links to other sites) n Other References & Standards discussed: q http://www.cgl.uwaterloo.ca/~rnkazman/SA-sites.html (Links to other sites) q IEEE 1471, ISO RM-ODP q http://www-ksl-svc.stanford.edu:5915/ (Ontologies) q n http://www.dstc.edu.au/Research/Projects/ODP/ref_model.html http://www.sei.cmu.edu/architecture/adl.html (Architecture Definition Languages) q IEEE 1220, EIA-632, EIA-731, DO-178B, J-STD-016-1995 29 30 Other Referenced Sites Other Referenced Sites n Secondary References Used: n Tools: q http://www-2.cs.cmu.edu/afs/cs/academic/class/17655-s02/www/ q http://www.isr.uci.edu/projects/xarchuci/ (xADL 2.0 ) (Garlan’s Class on SA) q http://www.isr.uci.edu/projects/xarchuci/tools-overview.html q http://www.softwaresystems.org/architecture.html q http://www.isr.uci.edu/projects/archstudio/setup-rundevelop.html (xADL) q http://www-old.ics.uci.edu/pub/arch/ q http://www.isr.uci.edu/projects/archstudio/ q http://cora.whizbang.com/ q http://www.kc.com/products/iuml/lite.html (xUml) q http://selab.korea.ac.kr/selab/resources/se/architecture.htm#Web q http://www-2.cs.cmu.edu/~able/software.html (ACME SW) q http://www.cebase.org/ q http://www-2.cs.cmu.edu/~Compose/html/tools.html q http://www.afm.sbu.ac.uk/ q http://pavg.stanford.edu/rapide/ (RAPIDE) q http://www.wwisa.org q http://www.afm.sbu.ac.uk/z/ (Z) q http://www.dacs.dtic.mil/databases/url/key.hts?keycode=71:2024&islowerlevel=1 q http://www.cs.colorado.edu/serl/arch/Papers.html q http://www.cetus-links.org/ 31 32 8 Further Reading Further Reading n Evaluating Software Architectures: Methods and Case n Design and Use of Software Architectures : Adopting Studies, P. Clements, R. Kazman and M. Klein, 2001. and Evolving a Product-Line Approach, Jan Bosch, n Documenting Software Architectures: Views and 2000 Beyond, Clements, Paul, Felix Bachmann, Len Bass, n Applied Software Architecture, Hofmeister Christine, David Garlan, James Ivers, Reed Little, Robert Nord and 1999 Judith Stafford, 2002. n Software Architecture: Organizational Principles and n The Art of Software Architecture: Design Methods and Patterns, Dikel, David, D. Kane and J. Wilson, 2001. Techniques, S. T. Albin, 2003 n Large-Scale Software Architecture : A Practical Guide n Software Architecture in Practice, L. Bass, P. using UML, Jeff Garland and Richard Anthony, 2002. Clements and R. Kazman, 2003. n Designing Software Product Lines wtih UML: From Use Cases to Pattern Based Software Architectures, H, Gomma, 2005. n Essential Software Architecture, Ian Gorton, 2006. 33 34 Further Reading Contents Topic 0 - Overview Topic 1 - History and Definition of Software Architecture Topic 2 - Modern Software Architecture Topic 3 - Software Architecture and the Built Environment n Topic 4 - Masterplans and Piecemeal Growth Software Architecture: Foundations, Theory, and Topic 5 - Architecture Description Languages Practice, Richard N. Taylor, Nenad Medvidovic and Topic 6 - Architectural Styles Topic 7 - Architecture Patterns Eric Dashofy Topic 8 - Domain Specific Software Architecture Topic 9 - Discipline of Software Architecture n Essential Software Architecture, Ian Gorton, 2006. Topic 10 - Software Architecture and the UML Topic 11 - Architecture and Component Based Development n 97 Things Every
Recommended publications
  • Revealing the Secrets of David Parnas

    Revealing the Secrets of David Parnas

    Revealing the Secrets of David Parnas H. Conrad Cunningham Department of Computer and Information Science University of Mississippi March 7, 2014 Those of us in the fast-changing field of computing often dismiss anything writ- ten more than five years ago as obsolete. Yet several decades-old papers by David L. Parnas [1, 4, 5, 6, 7, 8] are as timely as those published in recent issues of the top journals. Parnas articulates the timeless software design concepts known as information hiding and abstract interfaces. Most programmers would describe a module as a unit of code such as a sub- routine or class. Parnas focuses on the programmers rather than the programs. He defines a module as \a work assignment given to a programmer or group of programmers" as a part of a larger software development project [7]. His goals are to enable programmers to develop each module independently, change one module without affecting other modules, and comprehend the overall system by examining one module at a time [5]. Programmers often design a software system by breaking the required pro- cessing into steps and making each step a module. Instead, Parnas uses in- formation hiding to decompose the system into modules that satisfy his goals (2); each module keeps its own secreta design decision about some aspect of the system (e.g., choice of a data structure). A modules design decision can change but none of the other modules should be affected. If some aspect is unlikely to change, the design can distribute this knowledge across several modules and the interfaces among them.
  • Declarative Immutability in Java

    Declarative Immutability in Java

    International Journal of Computer and Systems Engineering Volume 1 Issue 1 Article 4 July 2020 Declarative Immutability in Java John Crowley Boston College, University of Pennsylvania, [email protected] Follow this and additional works at: https://digitalcommons.fairfield.edu/ijcase Recommended Citation Crowley, John (2020) "Declarative Immutability in Java," International Journal of Computer and Systems Engineering: Vol. 1 : Iss. 1 , Article 4. Available at: https://digitalcommons.fairfield.edu/ijcase/vol1/iss1/4 This item has been accepted for inclusion in DigitalCommons@Fairfield by an authorized administrator of DigitalCommons@Fairfield. It is brought to you by DigitalCommons@Fairfield with permission from the rights- holder(s) and is protected by copyright and/or related rights. You are free to use this item in any way that is permitted by the copyright and related rights legislation that applies to your use. For other uses, you need to obtain permission from the rights-holder(s) directly, unless additional rights are indicated by a Creative Commons license in the record and/or on the work itself. For more information, please contact [email protected]. Declarative Immutability in Java Online at https://digitalcommons.fairfield.edu/ijcase/ Published by Fairfield University, DigitalCommons@Fairfield © 2020 Vol. 1, No. 1, 2020 Declarative Immutability in Java by John D. Crowley ABSTRACT A pervasive mechanism is proposed to declare that variables and object instances are mutable or immutable, and whether methods mutate instances. These declarations are integral to the type structure of the language and allow the developer to declare, and the reader (and compiler) to determine, if a variable or instance is immutable (even if other instances of the Class are mutable) or that an instance is immutable throughout the application (a Pure instance).
  • Scala for the Impatient Second Edition This Page Intentionally Left Blank Scala for the Impatient Second Edition

    Scala for the Impatient Second Edition This Page Intentionally Left Blank Scala for the Impatient Second Edition

    Scala for the Impatient Second Edition This page intentionally left blank Scala for the Impatient Second Edition Cay S. Horstmann Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at [email protected] or (800) 382–3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the United States, please contact [email protected]. Visit us on the Web: informit.com/aw Library of Congress Control Number: 2016954825 Copyright © 2017 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise.
  • The Pragmatic Programmer Your Journey to Mastery

    The Pragmatic Programmer Your Journey to Mastery

    Extracted from: The Pragmatic Programmer your journey to mastery 20th Anniversary Edition Boston • Columbus • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo The Pragmatic Programmer your journey to mastery 20th Anniversary Edition Dave Thomas Andy Hunt Boston • Columbus • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City São Paulo • Sydney • Hong Kong • Seoul • Singapore • Taipei • Tokyo Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. "The Pragmatic Programmer" and the linking g device are trademarks of The Pragmatic Programmers, LLC. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, training goals, marketing focus, or branding interests), please contact our corporate sales department at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the U.S., please contact [email protected].
  • Keeping Secrets Within a Family: Rediscovering Parnas

    Keeping Secrets Within a Family: Rediscovering Parnas

    Keeping Secrets within a Family: Rediscovering Parnas H. Conrad Cunningham Cuihua Zhang Yi Liu Computer Science Computer & Information Systems Computer Science University of Mississippi Northwest Vista College University of Mississippi University, MS, 38677 San Antonio, TX 78251 University, MS 38677 Abstract of related programs. The motivation for product lines and frameworks is to take advantage of the David Parnas wrote several papers in the 1970’s commonalities among the members of the product line and 1980’s that are now considered classics. The to lower the overall cost of producing and maintaining concepts he advocated such as information hiding and a group of related software systems. use of abstract interfaces are generally accepted as Since the foundation of software product lines and the appropriate way to design nontrivial software frameworks is what Parnas proposed in his papers, an systems. However, not all of what he proposed has examination of the concepts in these papers (collected been fully appreciated and assimilated into our in [5]) can still reveal much of value to current-day practices. Many of his simple, elegant ideas have software developers and researchers. Many of the been lost amongst the hype surrounding the lessons taught in these works should also be technologies and methods that have arisen in the past incorporated into our college-level teaching. two decades. This paper examines Parnas’s ideas, This paper examines several of the lessons on the especially his emphasis on program families, and design of program families taught by Parnas that are proposes that college-level computing science and still important for contemporary students to learn.
  • Study on Eiffel

    Study on Eiffel

    Study on Eiffel Jie Yao Anurag Katiyar May 11, 2008 Abstract This report gives an introduction to Eiffel, an object oriented language. The objective of the report is to draw the attention of the reader to the salient features of Eiffel. The report explains some of these features in brief along with language syntax. The report includes some code snippets that were written in the process of learning Eiffel. Some of the more detailed tutorials, books and papers on Eiffel can be found at www.eiffel.com 1 Contents 1 Introduction 3 2 Eiffel Constructs and Grammar 3 2.1 ”Hello World” . 3 2.2 Data Types . 3 2.3 Classes . 3 2.4 Libraries . 4 2.5 Features . 4 2.6 Class relations and hierarchy . 4 2.7 Inheritance . 4 2.8 Genericity . 5 2.9 Object Creation . 5 2.10 Exceptions . 6 2.11 Agents and Iteration . 6 2.12 Tuples . 6 2.13 Typing . 6 2.14 Scope . 7 2.15 Memory Management . 7 2.16 External software . 7 3 Fundamental Properties 7 3.1 ”Has” Properties . 8 3.2 ”Has no” Properties . 9 4 Design principles in Eiffel 10 4.1 Design by Contract . 10 4.2 Command Query Separation . 11 4.3 Uniform Access Principle . 11 4.4 Single Choice Principle . 11 5 Compilation Process in Eiffel 11 6 Exception Handling in the compiler 12 7 Garbage Collection for Eiffel 12 7.1 Garbage Collector Structure . 12 7.2 Garbage Collector in Action . 13 8 Eiffel’s approach to typing 13 8.1 Multiple inheritance .
  • Stephan Goericke Editor the Future of Software Quality Assurance the Future of Software Quality Assurance Stephan Goericke Editor

    Stephan Goericke Editor the Future of Software Quality Assurance the Future of Software Quality Assurance Stephan Goericke Editor

    Stephan Goericke Editor The Future of Software Quality Assurance The Future of Software Quality Assurance Stephan Goericke Editor The Future of Software Quality Assurance Editor Stephan Goericke iSQI GmbH Potsdam Germany Translated from the Dutch Original book: ‘AGILE’, © 2018, Rini van Solingen & Manage- ment Impact – translation by tolingo GmbH, © 2019, Rini van Solingen ISBN 978-3-030-29508-0 ISBN 978-3-030-29509-7 (eBook) https://doi.org/10.1007/978-3-030-29509-7 This book is an open access publication. © The Editor(s) (if applicable) and the Author(s) 2020 Open Access This book is licensed under the terms of the Creative Commons Attribution 4.0 Inter- national License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence and indicate if changes were made. The images or other third party material in this book are included in the book’s Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the book’s Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.
  • Software Quality / Modularity

    Software Quality / Modularity

    Software quality EXTERNAL AND INTERNAL FACTORS External quality factors are properties such as speed or ease of use, whose presence or absence in a software product may be detected by its users. Other qualities applicable to a software product, such as being modular, or readable, are internal factors, perceptible only to computer professionals who have access to the actual software text. In the end, only external factors matter, but the key to achieving these external factors is in the internal ones: for the users to enjoy the visible qualities, the designers and implementers must have applied internal techniques that will ensure the hidden qualities. EXTERNAL FACTORS Correctness: The ability of software products to perform their tasks, as defined by their specification. Correctness is the prime quality. If a system does not do what it is supposed to do, everything else about it — whether it is fast, has a nice user interface¼ — matters little. But this is easier said than done. Even the first step to correctness is already difficult: we must be able to specify the system requirements in a precise form, by itself quite a challenging task. Robustness: The ability of software systems to react appropriately to abnormal conditions. Robustness complements correctness. Correctness addresses the behavior of a system in cases covered by its specification; robustness characterizes what happens outside of that specification. There will always be cases that the specification does not explicitly address. The role of the robustness requirement is to make sure that if such cases do arise, the system does not cause catastrophic events; it should produce appropriate error messages, terminate its execution cleanly, or enter a so-called “graceful degradation” mode.
  • Systems Development Life Cycle

    Systems Development Life Cycle

    Systems Development Life Cycle From Wikipedia, the free encyclopedia Jump to: navigation, search For other uses, see SDLC (disambiguation). Model of the Systems Development Life Cycle with the Maintenance bubble highlighted. The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. The concept generally refers to computer or information systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system[1]: the software development process. Contents y 1 Overview y 2 History y 3 Systems development phases o 3.1 Requirements gathering and analysis o 3.2 Design o 3.3 Build or coding o 3.4 Testing o 3.5 Operations and maintenance y 4 Systems development life cycle topics o 4.1 Management and control o 4.2 Work breakdown structured organization o 4.3 Baselines in the SDLC o 4.4 Complementary to SDLC y 5 Strengths and weaknesses y 6 See also y 7 References y 8 Further reading y 9 External links [edit] Overview Systems and Development Life Cycle (SDLC) is a process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance.[2] Computer systems are complex and often (especially with the recent rise of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors.
  • Polymorphic Identifiers: Uniform Resource Access in Objective-Smalltalk

    Polymorphic Identifiers: Uniform Resource Access in Objective-Smalltalk

    Polymorphic Identifiers: Uniform Resource Access in Objective-Smalltalk Marcel Weiher Robert Hirschfeld Hasso Plattner Institute, University of Potsdam Hasso Plattner Institute, University of Potsdam [email protected] [email protected] Abstract compose these identifiers, use them on the LHS and RHS and In object-oriented programming, polymorphic dispatch of opera- partially use them for indirect access. Computational abstraction tions decouples clients from specific providers of services and al- is handled separately. lows implementations to be modified or substituted without affect- Object-oriented programming languages such as Smalltalk, ing clients. Java and Objective-C mostly maintain the distinction between The Uniform Access Principle (UAP) tries to extend these qual- computational and storage abstraction, with polymorphism and ities to resource access by demanding that access to state be indis- most other abstraction mechanisms only applying to computational tinguishable from access to operations. Despite language features abstraction. Access to storage, when not mediated via a method, supporting the UAP, the overall goal of substitutability has not been defeats encapsulation and makes code brittle against changes or achieved for either alternative resources such as keyed storage, files subclassing, which is why convention moved toward having all or web pages, or for alternate access mechanisms: specific kinds of access to state (instance variables) mediated by methods. resources are bound to specific access mechanisms and vice versa. The Uniform Access Principle (UAP) [22] was coined by Meyer Changing storage or access patterns either requires changes to both to formalize this convention: access to state should be indistin- clients and service providers and trying to maintain the UAP im- guishable from computation.
  • Best Practices in Software Development: Principles of Good

    Best Practices in Software Development: Principles of Good

    Best Practices in Software Development: Principles of Good Design Ansgar Fehnker Based on slides by: Arend Rensink, Christoph Bockisch, Mira Mezini, Lodewijk Bergmans What is Good Software? . External criteria . Correctness, robustness, extensibility, efficiency, ease of use ... Stakeholders: . end user, e.g., a travel agent using a flight reservation system . persons who purchase the software, e.g., an airline executive acquiring or commissioning flight reservation systems . Internal criteria . Modularity, readability, reusability, ... Stakeholders: . IT professionals with access to the source . Only external factors matter in the end . but the key to achieving them is in the internal ones Patterns of Software Development 2 External vs. Internal Criteria Patterns of Software Development 3 External Criteria: Correctness . What is correctness? . the ability of a software product to perform its task . as defined by its specification . Examples of (in-)correct systems? Application . Due to complexity, methods for ensuring correctness will usually be conditional or layered . each layer relying on lower ones Hardware Patterns of Software Development 4 External Criteria: Robustness . What is robustness? . the ability of software to react appropriately to abnormal conditions . Examples of (non-)robust systems? . Difference robustness/correctness? . Correctness addresses the behavior of a system in cases covered by its specification . Robustness characterizes what happens outside of that specification Patterns of Software Development 5 External Criteria: Efficiency . What is efficiency? . place as few demands as possible on hardware resources: . processor time, memory, bandwidth, power . Examples of (in-)efficient systems? . A software case of split personality . Mr. Microsecond: shows an exaggerated concern for micro- optimisation. “Premature optimization is the root of all evil” .
  • Inspection's Role in Software Quality Assurance

    Inspection's Role in Software Quality Assurance

    focusguest editors’ introduction Inspection’s Role in Software Quality Assurance David L. Parnas, University of Limerick Mark Lawford, McMaster University espite more than 30 years’ effort to improve software quality, companies still release programs containing numerous errors. Many major products have thousands of bugs. It’s not for lack of D trying; all major software developers stress software quality as- surance and try to remove bugs before release. The problem is the code’s complexity. It’s easy to review code but fail to notice significant errors. Researchers have responded to these prob- lems by studying methods of formal correct- ness verification for programs. In theory, we now know how to prove programs correct with the same degree of rigor that we apply to mathematical theorems. In reality, this is rarely practical and even more rarely done. Most research papers on verification make simplifying assumptions (for example, a 1:1 correspondence between variables and vari- able names) that aren’t valid for real pro- grams. Proofs of realistic programs involve long, complex expressions and require pa- tience, time, and diligence that developers don’t think they have. (Interestingly enough, they never have time to verify a program be- fore release, but they must take time to re- spond to complaints after release.) Inspection methods can be more effective than informal reviews and require less effort than formal 16 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/03/$17.00 © 2003 IEEE proofs, but their success depends on having a I The TSE papers do communicate the re- sound, systematic procedure.