DOCSLIB.ORG

Software Fault Tolerance Based on Design Diversity Is Expensive and Hence Does Not Get Used Extensively

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Fault Tolerance Based on Design Diversity Is Expensive and Hence Does Not Get Used Extensively How Does Software Fail and What Should be Done About It? DCIT; Nov. 2015 Prof. Kishor Trivedi Duke High Availability Assurance Lab (DHAAL) Department of Electrical and Computer Engineering Duke University, Durham, NC 27708-0291 E-mail: [email protected] URL: www.ee.duke.edu/~ktrivedi Copyright © 2015 by K.S. Trivedi 1 Duke University Research Triangle Park (RTP) Duke UNC-CH NC state North USA Carolina Copyright © 2015 by K.S. Trivedi 2 Duke High Availability Assurance Laboratory (DHAAL) Kishor Trivedi Dept. of Electrical & Computer Engineering Duke University Email: [email protected] URL: www.ee.duke.edu/~ktrivedi Internationally connected with groups in USA, Germany, Italy, Japan, China, Brazil, New Zealand and Spain Copyright © 2015 by K.S. Trivedi 3 DHAAL . Dhaal means “Shield” in Hindi/Gujarati . DHAAL research is about shielding systems from various threats Copyright © 2015 by K.S. Trivedi 4 Books Update n Probability and Statistics with Reliability, Queuing, and Computer Science Applications, 1982; Second edition, John Wiley, 2001 (Blue book) – Chines translation has just appeared n Performance and Reliability Analysis of Computer Systems: An Example-Based Approach Using the SHARPE Software Package, Kluwer, 1996 (Red book) n Qeuing Networks and Markov Chains, 1998 John Wiley, second edition, 2006 (White book) n Reliability and Availability Engineering, Cambridge University Press, 2016 (green book) Copyright © 2015 by K.S. Trivedi 6 Outline Motivation Real System Examples Software Fault Classification Environmental Diversity Methods of Mitigation Software Aging and Rejuvenation Conclusions Copyright © 2015 by K.S. Trivedi 7 Pervasive Dependence on Computer Systems Need for High Reliability/Availability Communication Health & Medicine Avionics Banking Entertainment Copyright © 2015 by K.S. Trivedi 8 Basic Definitions n Steady-state availability (Ass) or just availability u Long-term probability that the system is available when requested: MTTF A = ss MTTF + MTTR u MTTF is the system mean time to failure, a complex combination of component MTTFs u MTTR is the system mean time to recovery F may consist of many phases Copyright © 2015 by K.S. Trivedi 9 Motivation Basic Definitions n Downtime in minutes per year u In industry, (un)availability is usually presented in terms of annual downtime. u Downtime = 876060 (1- Ass) minutes. u In Industry it is common to define the availability in terms of number of nines F 5 NINES (Ass = 0.99999) 5.26 minutes annual downtime F 4 NINES (Ass = 0.9999) 52.56 minutes annual downtime Copyright © 2015 by K.S. Trivedi 10 Motivation Number of Nines– Reality Check n 49% of Fortune 500 companies experience at least 1.6 hours of downtime per week u Approx. 80 hours/year=4800 minutes/year u Ass=(8760-80)/8760=0.9908 u That is, between 2 NINES and 3 NINES! n This study assumes planned and unplanned downtime, together Copyright © 2015 by K.S. Trivedi 11 Motivation Some real examples from High Tech companies Jan. 2014 , Gmail was down for 25 – 50 min. Oct. 2013, Unavailable services like post photos and “likes” Feb. 2013, Windows Azure down for 12 hours Jan. 2013, AWS down for an hour approx. Sept. 2012 - GoDaddy (4 hours and 5 millions of websites affected) Copyright © 2015 by K.S. Trivedi 12 Motivation More examples of failures Oct. 2012 Amazon Webservices - 6 hours (Memory leak) Amazon EC2 - 2 hours T h e Sept. 2011 - Google Docs service outage (1 hour) - A memory leak s due to a software update a m e Sept. 2011 - Microsoft Cloud service outage (2.5 hours) w e e k n These examples indicate that even the most advanced tech companies are offering less than five NINES of availability • And only considering one failure!!!! Copyright © 2015 by K.S. Trivedi 13 Motivation Software is the problem Jim Gray’s paper titled “Why do computers stop and what can be done about it?” pointed out this trend in 1985, followed by his paper “A census of tandem system availability between 1985 and 1990” 2005 1985 Across different industries…. Copyright © 2015 by K.S. Trivedi 15 Motivation High Reliability/Availability: Software is the problem n Hardware fault tolerance, fault management, reliability/availability modeling relatively well developed n System outages more due to software faults Key Challenge: Software reliability is one of the weakest links in system reliability/availability Copyright © 2015 by K.S. Trivedi 16 Motivation Increasing SW Failure Rate? Planetary Missions Flight Software: A. Nikora of JPL The interval between the first and last launch: 8.76 years. The interval between successive launches ranges from: 23 to 790 days. Mars Pathfinder CASSINI Mars Mars Stardust Mars Genesis Mars Deep Mars Global Climate Polar Odyssey Exploration Impact Reconnaissance Surveyor Orbiter Lander Rover Orbiter Mission Name (in launch order) Copyright © 2015 by K.S. Trivedi 17 Motivation TAKE AWAY MESSAGES n Today's complex systems (including CPS and IoT) are mostly software with some hardware thrown in. Software failures are a major cause of system undependability. n The focus so far has been on software faults; we need to pay attention to failures caused by software and the recovery from these failures. Or focus so far has been on software reliability; we need to pay attention to software availability as well. n Software failures during operation are a fact that we need to learn to deal with. Traditional method of software fault tolerance based on design diversity is expensive and hence does not get used extensively. Software fault tolerance based on inexpensive environmental diversity should be exploited. Copyright © 2015 by K.S. Trivedi 20 Conclusions Software Reliability: Known Means n Fault prevention or Fault avoidance n Fault Removal n Fault Tolerance Copyright © 2015 by K.S. Trivedi 21 Motivation Software Reliability n Fault prevention or Fault avoidance u Good software engineering practices F Requirement Elicitation (Abuse Case Analysis – TCS SSA) F Design Analysis / Review F Secure Programming Standard & Review F Secure Programming Compilation F Software Development lifecycle F Automated Code Generation Tools (IDE like Eclipse) u Use of formal methods F UML, SysML, BPM F Proof of correctness F Model Checking (SMART, SPIN, PRISM) n Bug free code not yet possible for large scale software systems u Impossible to fully test and verify if software is fault-free “Testing shows the presence, not the absence, of bugs” - E. W. Dijkstra n Yet there is a strong need for failure-free system operation Copyright © 2015 by K.S. Trivedi 22 Motivation Software Reliability n Fault prevention or Fault avoidance n Fault Removal n Fault Tolerance Copyright © 2015 by K.S. Trivedi 23 Motivation Software Reliability n Fault removal u Can be carried out during F the specification and design phase F the development phase F the operational phase u Failure data may be collected and used to parameterize a software reliability growth model(SRGM) to predict when to stop testing n Software is still delivered with many bugs either because of inadequate budget for testing , very difficult to reproduce/detect/localize/correct bugs or inadequacy of techniques employed/known Copyright © 2015 by K.S. Trivedi 24 Software Reliability n Fault prevention or Fault avoidance n Fault Removal n Fault Tolerance Copyright © 2015 by K.S. Trivedi 25 Motivation High Reliability/Availability: Software is the problem Software fault tolerance is a potential solution to improve software reliability in lieu of virtually impossible fault-free software Copyright © 2015 by K.S. Trivedi 26 Software Fault Tolerance Classical Techniques Design diversity u N-version programming u Recovery block Copyright © 2015 by K.S. Trivedi 27 Motivation Software Fault Tolerance Classical Techniques • N-version programming • Recovery blocks Design • … diversity Expensive not Yet there are used much in stringent requirements for practice! failure-free operation Challenge: Affordable Software Fault Tolerance Copyright © 2015 by K.S. Trivedi 28 TAKE AWAY MESSAGES n Today's complex systems (including CPS and IoT) are mostly software with some hardware thrown in. Software failures are a major cause of system undependability. n The focus so far has been on software faults; we need to pay attention to failures caused by software and the recovery from these failures. Or focus so far has been on software reliability; we need to pay attention to software availability as well. n Software failures during operation are a fact that we need to learn to deal with. Traditional method of software fault tolerance based on design diversity is expensive and hence does not get used extensively. Software fault tolerance based on inexpensive environmental diversity should be exploited. Copyright © 2015 by K.S. Trivedi 29 Conclusions Outline Motivation Real System Examples Software Fault Classification Environmental Diversity Methods of Mitigation Software Aging and Rejuvenation Conclusions Copyright © 2015 by K.S. Trivedi 30 Real Systems Example of a real systems and their High availability implementations Copyright © 2015 by K.S. Trivedi 31 High availability SIP Application Server Configuration on IBM WebSphere Blade Chassis 1 More details in PRDC 2008 AS 1 Replication Domain 1 and ISSRE 2010 papers AS 2 Replication Domain 2 Replication Blade 2 AS 3 Replication Domain 3 AS 4 SIP Proxy 1 Blade 3 DM Group3 AS 5 Blade 1 AS 6 Test Driver - Blade 4 IP SIBpMra yLeo-rad Test drivers Balancer SIP IBM PC Blade Chassis 2 Test Driver AS 1 Replication Domain 4 AS 4 SIP Proxy 1 Blade 2 AS1 thru AS6 are Blade1 AS 2 Application Server Replication Domain 5 AS 5 Proxy1's are Stateless Proxy Server Blade 3 AS 3 Replication Domain 6 AS 6 Blade 4 Blade 4 A Real System Copyright © 2015 by K.S. Trivedi 32 High availability SIP Application Server configuration on WebSphere Hardware configuration: Two BladeCenter chassis; 4 blades (nodes) on each chassis (1 chassis sufficient for performance) Software configuration: 2 copies of SIP/Proxy servers (1 sufficient for performance) 12 copies of WAS (6 sufficient for performance) Each WAS instance forms a redundancy pair (replication domain) with WAS installed on another node on a different chassis The system has hardware redundancy and software redundancy.
Load more

Recommended publications
  • Software Rejuvenation Model for Cloud Computing Platform
    International Journal of Applied Engineering Research ISSN 0973-4562 Volume 12, Number 19 (2017) pp. 8332-8337 © Research India Publications. http://www.ripublication.com Software Rejuvenation Model for Cloud Computing Platform I M Umesh System Analyst, Department of Information Science & Engineering, Rashtreeya Vidyalaya College of Engineering, Mysuru Road, Bengaluru, Karnataka, India. Orcid Id: 0000-0002-7595-5501 Dr. G N Srinivasan Professor, Department of Information Science & Engineering, Rashtreeya Vidyalaya College of Engineering, Mysuru Road, Bengaluru, Karnataka, India. Orcid Id: 0000-0003-1059-5952 Matheus Torquato Professor, Federal Institute of Alagoas (IFAL), Campus Arapiraca - AL, Brazil. Orcid Id: 0000-0003-3211-7951 Abstract leading to resource exhaustion. Aging effects are the result of Cloud computing has emerged as one of the most needed error accumulation that leads to resource exhaustion. This technologies that houses software systems and relevant status of softwares makes the system gradually shift from functional entities resulting in complex, multiuser, healthy state to failure prone state. The system performance multitasking and virtualized environments. However, metrics needs to be monitored in order to find the aging reliability of such high performance computing systems patterns while the system is running. The accurate prediction depends both on hardware and software. Virtualization is the of time of aging needs to be forecasted to initiate the technology that many cloud service providers rely on for necessary actions to counter the aging effects. The software efficient management and coordination of the resource pool. aging consequences can be avoided by using the technique The software systems, during operation accumulate errors or called software rejuvenation. garbage leading to software aging which may lead to system Software rejuvenation is the proactive technique proposed to failure and associated consequences.
    [Show full text]
  • The Past, Present, and Future of Software Evolution
    The Past, Present, and Future of Software Evolution Michael W. Godfrey Daniel M. German Software Architecture Group (SWAG) Software Engineering Group School of Computer Science Department of Computer Science University of Waterloo, CANADA University of Victoria, CANADA email: [email protected] email: [email protected] Abstract How does our system compare to that of our competitors? How easy would it be to port to MacOS? Are users still Change is an essential characteristic of software devel- angry about the spyware incident? As new features are de- opment, as software systems must respond to evolving re- vised and deployed, as new runtime platforms are envis- quirements, platforms, and other environmental pressures. aged, as new constraints on quality attributes are requested, In this paper, we discuss the concept of software evolu- so must software systems continually be adapted to their tion from several perspectives. We examine how it relates changing environment. to and differs from software maintenance. We discuss in- This paper explores the notion of software evolution. We sights about software evolution arising from Lehman’s laws start by comparing software evolution to the related idea of software evolution and the staged lifecycle model of Ben- of software maintenance and briefly explore the history of nett and Rajlich. We compare software evolution to other both terms. We discuss two well known research results of kinds of evolution, from science and social sciences, and we software evolution: Lehman’s laws of software evolution examine the forces that shape change. Finally, we discuss and the staged lifecycle model of Bennett and Rajlich. We the changing nature of software in general as it relates to also relate software evolution to biological evolution, and evolution, and we propose open challenges and future di- discuss their commonalities and differences.
    [Show full text]
  • SWARE: a Methodology for Software Aging and Rejuvenation Experiments
    Journal of Information Systems Engineering & Management, 2018, 3(2), 15 ISSN: 2468-4376 SWARE: A Methodology for Software Aging and Rejuvenation Experiments Matheus Torquato 1*, Jean Araujo 2, I. M. Umesh 3, Paulo Maciel 4 1 Federal Institute of Alagoas (IFAL), Campus Arapiraca, Arapiraca, AL, BRAZIL 2 Federal Rural University of Pernambuco (UFRPE), Campus Garanhuns, Garanhuns, PE, BRAZIL 3 Bharathiar University, Coimbatore, INDIA 4 Federal University of Pernambuco (UFPE), Center of Informatics (CIn), Recife, PE, BRAZIL *Corresponding Author: [email protected], [email protected] Citation: Torquato, M., Araujo, J., Umesh, I. M. and Maciel, P. (2018). SWARE: A Methodology for Software Aging and Rejuvenation Experiments. Journal of Information Systems Engineering & Management, 3(2), 15. https://doi.org/10.20897/jisem.201815 Published: April 07, 2018 ABSTRACT Reliability and availability are mandatory requirements for numerous applications. Technical apparatus to study system dependability is essential to support software deployment and maintenance. Software aging is a related issue in this context. Software aging is a cumulative process which leads systems with long-running execution to hangs or failures. Software rejuvenation is used to prevent software aging problems. Software rejuvenation actions comprise system reboot or application restart to bringing software to a stable fresh state. This paper proposes a methodology to conduct software aging and software rejuvenation experiments. The approach has three phases: (i) Stress Phase - stress environment with the accelerated workload to induce bugs activation; (ii) Wait Phase - stop workload submission to observe the system state after workload submission; (iii) Rejuvenation Phase - find the impacts caused by the software rejuvenation.
    [Show full text]
  • Software Evolution of Legacy Systems a Case Study of Soft-Migration
    Software Evolution of Legacy Systems A Case Study of Soft-migration Andreas Furnweger,¨ Martin Auer and Stefan Biffl Vienna University of Technology, Inst. of Software Technology and Interactive Systems, Vienna, Austria Keywords: Software Evolution, Migration, Legacy Systems. Abstract: Software ages. It does so in relation to surrounding software components: as those are updated and modern- ized, static software becomes evermore outdated relative to them. Such legacy systems are either tried to be kept alive, or they are updated themselves, e.g., by re-factoring or porting—they evolve. Both approaches carry risks as well as maintenance cost profiles. In this paper, we give an overview of software evolution types and drivers; we outline costs and benefits of various evolution approaches; and we present tools and frameworks to facilitate so-called “soft” migration approaches. Finally, we describe a case study of an actual platform migration, along with pitfalls and lessons learned. This paper thus aims to give software practitioners—both resource-allocating managers and choice-weighing engineers—a general framework with which to tackle soft- ware evolution and a specific evolution case study in a frequently-encountered Java-based setup. 1 INTRODUCTION tainability. We look into different aspects of software maintenance and show that the classic meaning of Software development is still a fast-changing environ- maintenance as some final development phase after ment, driven by new and evolving hardware, oper- software delivery is outdated—instead, it is best seen ating systems, frameworks, programming languages, as an ongoing effort. We also discuss program porta- and user interfaces. While this seemingly constant bility with a specific focus on porting source code.
    [Show full text]
  • Software Design Introduction
    Software Design Introduction Material drawn from [Godfrey96,Parnas86,Parnas94] Software Design (Introduction) © SERG Software Design • How to implement the what. • Requirements Document (RD) is starting point. • Software design is a highly-creative activity. • Good designers are worth their weight in gold! – Highly sought after, head-hunted, well-paid. • Experience alone is not enough: – creativity, “vision”, all-around brilliance required. Software Design (Introduction) © SERG Software Design (Cont’d) • Some consider software design to be a “black art”: – difficult to prescribe how to do it – hard to measure a good design objectively – “I know a good design when I see it.” Software Design (Introduction) © SERG Requirements Engineering: An Overview • Basic goal: To understand the problem as perceived by the user. • Activities of RE are problem oriented. – Focus on what, not how – Don’t cloud the RD with unnecessary detail – Don’t pre-constrain design. • After RE is done, do software design: – solution oriented – how to implement the what Software Design (Introduction) © SERG Requirements Engineering: An Overview • Key to RE is good communication between customer and developers. • Work from Requirements Document as guide. Software Design (Introduction) © SERG Requirements Engineering • Basically, it’s the process of determining and establishing the precise expectations of the customer about the proposed software system. Software Design (Introduction) © SERG The Two Kinds of Requirements • Functional: The precise tasks or functions the system is to perform. – e.g., details of a flight reservation system • Non-functional: Usually, a constraint of some kind on the system or its construction – e.g., expected performance and memory requirements, process model used, implementation language and platform, compatibility with other tools, deadlines, ..
    [Show full text]
  • On the Aging Effects Due to Concurrency Bugs: a Case Study on Mysql
    On the Aging Effects due to Concurrency Bugs: a Case Study on MySQL Antonio Bovenzi∗, Domenico Cotroneo∗, Roberto Pietrantuono∗, Stefano Russo∗y, ∗Dipartimento di Informatica e Sistemistica, Universita´ di Napoli Federico II, Via Claudio 21, 80125, Naples, Italy. yLaboratorio CINI-ITEM “Carlo Savy”, Complesso Universitario Monte Sant’Angelo, Via Cinthia, 80126, Naples, Italy. fantonio.bovenzi, cotroneo, roberto.pietrantuono, [email protected] Abstract—This study investigates software aging effects and fragmentation problems (e.g., file system and physical caused by the activation of concurrency bugs in a well- memory). known database management system (DBMS), namely MySQL. ARBs are difficult to reproduce in a systematic way Experiments with different workloads are performed in order to reproduce the most likely conditions for concurrency bugs during the testing phase, because they require a long time activation. Besides the typical aging effects observed in many to manifest their effects. For these characteristics, they are operational systems (i.e., a gradual degradation over time), considered as a subclass of Mandelbugs [4]. Mandelbugs are results highlight that both available resources and DBMS those software faults that are difficult to isolate, and whose performance (e.g. service rate, service time, and connection activation and/or error propagation are considered “com- latency) can decrease with time in a hard-to-predict way. We observed that, due to the activation of concurrency bug, the plex” because: i) they depend on indirect factors (e.g., timing DBMS enters a degraded state in which: i) the estimation of and/or sequencing of operations or inputs, interactions with Time-To-Failure (TTF) by means of memory depletion trend system-internal environment), and/or ii) there is a time lag analysis is highly inaccurate, and ii) the failure rate does not between the fault activation and the failure manifestation.
    [Show full text]
  • User Experienced Software Aging: Test Environment, Testing and Improvement Suggestions
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Trepo - Institutional Repository of Tampere University User Experienced Software Aging: Test Environment, Testing and Improvement Suggestions Sayed Tenkanen University of Tampere School of Information Sciences Interactive Technology M.Sc. thesis Supervisor: Professor Roope Raisamo December 2014 ii University of Tampere School of Information Sciences Interactive Technology Sayed Tenkanen: User Experienced Software Aging: Test Environment, Testing and Improvement Suggestions M.Sc. thesis, 48 pages December 2014 Software aging is empirically observed in software systems in a variety of manifestations ranging from slower performance to various failures as reported by users. Unlike hardware aging, where in its lifetime hardware goes through wear and tear resulting in an increased rate of failure after certain stable use conditions, software aging is a result of software bugs. Such bugs are always present in the software but may not make themselves known unless a set of preconditions are met. When activated, software bugs may result in slower performance and contribute to user dissatisfaction. However, the impact of software bugs on PCs and mobile phones is different as their uses are different. A PC is often turned off or rebooted on an average of every seven days, but a mobile device may continue to be used without a reboot for much longer. The prolonged operation period of mobile devices thus opens up opportunities for software bugs to be activated more often compared to PCs. Therefore, software aging in mobile devices, a considerable challenge to the ultimate user experience, is the focus of this thesis.
    [Show full text]
  • The Fundamentals of Software Aging
    The Fundamentals of Software Aging Michael Grottke*, Rivalino Matias Jr.‡, and Kishor S. Trivedi‡ *University of Erlangen-Nuremberg, Germany; [email protected] ‡Duke University, USA; {rivalino, kst}@ee.duke.edu Abstract 2. Physics of software failures Since the notion of software aging was introduced thirteen Software aging is usually a consequence of software years ago, the interest in this phenomenon has been in- faults. This section therefore revisits the body of knowl- creasing from both academia and industry. The majority edge related to the taxonomy of faults and other depend- of the research efforts in studying software aging have ability concepts. In Section 3, we will discuss the specific focused on understanding its effects theoretically and em- nature of these concepts in the context of software aging. pirically. However, conceptual aspects related to the According to system theory, a system is a collection of foundation of this phenomenon have not been covered in inter-operating elements (or components); the system the literature. This paper discusses foundational aspects of boundary separates the system from its environment. For the software aging phenomenon, introducing new concepts example, a single software system includes the hardware, and interconnecting them with the current body of knowl- the operating system (OS) and the applications as its ele- edge, in order to compose a base taxonomy for the ments; however, the users and other software systems are software aging research. Three real case studies are pre- part of its environment. Each system can itself be an ele- sented with the purpose of exemplifying many of the ment of another (higher-level) system.
    [Show full text]
  • Important Java Programming Concepts
    Appendix A Important Java Programming Concepts This appendix provides a brief orientation through the concepts of object-oriented programming in Java that are critical for understanding the material in this book and that are not specifically introduced as part of the main content. It is not intended as a general Java programming primer, but rather as a refresher and orientation through the features of the language that play a major role in the design of software in Java. If necessary, this overview should be complemented by an introductory book on Java programming, or on the relevant sections in the Java Tutorial [10]. A.1 Variables and Types Variables store values. In Java, variables are typed and the type of the variable must be declared before the name of the variable. Java distinguishes between two major categories of types: primitive types and reference types. Primitive types are used to represent numbers and Boolean values. Variables of a primitive type store the actual data that represents the value. When the content of a variable of a primitive type is assigned to another variable, a copy of the data stored in the initial variable is created and stored in the destination variable. For example: int original = 10; int copy = original; In this case variable original of the primitive type int (short for “integer”) is assigned the integer literal value 10. In the second assignment, a copy of the value 10 is used to initialize the new variable copy. Reference types represent more complex arrangements of data as defined by classes (see Section A.2).
    [Show full text]
  • Memory Degradation Analysis in Private and Public Cloud Environments
    Memory Degradation Analysis in Private and Public Cloud Environments Ermeson Andrade∗, Fumio Machiday, Roberto Pietrantuonoz, Domenico Cotroneoz ∗Department of Computing, Federal Rural University of Pernambuco, Recife, Brazil, [email protected] yDepartment of Computer Science, University of Tsukuba, Tsukuba, Japan, [email protected] zUniversity of Naples Federico II, Naples, Italy, froberto.pietrantuono, [email protected] Abstract—Memory degradation trends have been observed In order to investigate the causality of software aging in many continuously running software systems. Applications in cloud computing environments, we conduct a set of ex- running on cloud computing can also suffer from such memory periments targeting an image processing system deployed degradation that may cause severe performance degradation or even experience a system failure. Therefore, it is essential to on private or public cloud systems and statistically analyze monitor such degradation trends and find the potential causes to the processes’ memory consumption contributing to software provide reliable application services on cloud computing. In this aging. For the private cloud system, We build a CloudStack paper, we consider both private and public cloud environments environment, while for the public system we employ Google for deploying an image classification system and experimentally cloud platform. On the cloud systems, image classification investigate the memory degradation that appeared in these environments. The degradation trends in the available memory tasks are processed continuously for 72 hours with three statistics are confirmed by the Mann-Kendall test in both cloud different workload intensities (i.e., low, middle, and high). We environments. We apply causal structure discovery methods to collect several system metrics and apply the Mann-Kendall process-level memory statistics to identify the causality of the ob- test [7] with Sen’s slope estimate [8] to confirm the trends in served memory degradations.
    [Show full text]
  • Re-Engineering Legacy Code with Design Patterns: a Case Study in Mesh Generation Software
    Re-engineering Legacy Code with Design Patterns: A Case Study in Mesh Generation Software Chaman Singh Verma Ling Liu Dept. of Computer Science Dept. of Computer Science The College of William & Mary The College of William & Mary Williamsburg, VA 23185 Williamsburg, VA 23185 [email protected] [email protected] Abstract— Software for scientific computing, like other soft- However, while generic programming is a well-established ware, evolves over time and becomes increasingly hard to practice in scientific software, today we lack evidence that maintain. In addition, much scientific software is experimental design patterns can significantly improve such code without in nature, requiring a high degree of flexibility so that new algorithms can be developed and implemented quickly. Design adversely affecting performance. patterns have been proposed as one method for increasing the In this paper, we explore how design patterns can be applied flexibility and extensibility of software in general. However, to to re-engineer legacy code to increase the flexibility of the date, there has been little research to determine if design patterns system. We have applied twelve design patterns from the can be applied effectively for scientific software. In this paper, literature [1] to an existing mesh generation software system. we present a case study in the application of design patterns for the re-engineering of software for mesh generation. We We characterized the design patterns in terms of three primary applied twelve well-known design patterns from the literature, design criteria: static and dynamic extendibility, reliability, and and evaluated these design patterns according to several criteria, clean design of the system.
    [Show full text]
  • Software Evolvability Measurement Framework During an Open Source Software Evolution
    Master of Science in Software Engineering February 2017 Software Evolvability Measurement Framework during an Open Source Software Evolution Jianhao Zhang and Xuxiao Chen Faculty of Computing Blekinge Institute of Technology SE-371 79 Karlskrona Sweden This thesis is submitted to the Faculty of Computing at Blekinge Institute of Technology in partial fulfillment of the requirements for the degree of Master of Science in Software Engineering. The thesis is equivalent to 20 weeks of full time studies. Contact Information: Authors: Jianhao Zhang E-mail: [email protected] Xuxiao Chen E-mail: [email protected] University advisor: Bodgan Marculescu Department of Computing Faculty of Computing Internet : www.bth.se Blekinge Institute of Technology Phone : +46 455 38 50 00 SE-371 79 Karlskrona, Sweden Fax : +46 455 38 50 57 Abstract Context ： Software evolution comes with the increasing growth of software applications both in size and complexity. Unlike the software maintenance, software evolution addresses more on the adaption of the new fast-changing requirements. Then the term of “software evolvability” comes with its importance for evaluating the evolution status of the software. However, it is not clearly identified especially in the context of open source software (OSS). Besides the most studies are about the description of software evolvability as a quality attribute, and very few research have done on the measurement of software evolvability during the software evolution process. Objectives： In this study we perform an in-depth investigation on identification of the OSS evolvability, and figure out the appropriate metrics used for measuring the OSS evolvability. Based on that we finally proposed the open source software evolvability measurement framework (OSEM) which could be used for measuring the software evolvability generally in an OSS context.
    [Show full text]