DOCSLIB.ORG

Resilience Design Patterns a Structured Approach to Resilience at Extreme Scale - Version 1.0

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Resilience Design Patterns a Structured Approach to Resilience at Extreme Scale - Version 1.0 ORNL/TM-2016/687 Resilience Design Patterns A Structured Approach to Resilience at Extreme Scale - version 1.0 Saurabh Hukerikar Christian Engelmann Approved for public release. October 2016 Distribution is unlimited. DOCUMENT AVAILABILITY Reports produced after January 1, 1996, are generally available free via US Department of Energy (DOE) SciTech Connect. Website: http://www.osti.gov/scitech/ Reports produced before January 1, 1996, may be purchased by members of the public from the following source: National Technical Information Service 5285 Port Royal Road Springfield, VA 22161 Telephone: 703-605-6000 (1-800-553-6847) TDD: 703-487-4639 Fax: 703-605-6900 E-mail: [email protected] Website: http://classic.ntis.gov/ Reports are available to DOE employees, DOE contractors, Energy Technology Data Ex- change representatives, and International Nuclear Information System representatives from the following source: Office of Scientific and Technical Information PO Box 62 Oak Ridge, TN 37831 Telephone: 865-576-8401 Fax: 865-576-5728 E-mail: [email protected] Website: http://www.osti.gov/contact.html This report was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor any agency thereof, nor any of their employees, makes any warranty, express or implied, or assumes any legal lia- bility or responsibility for the accuracy, completeness, or usefulness of any information, apparatus, product, or process disclosed, or rep- resents that its use would not infringe privately owned rights. Refer- ence herein to any specific commercial product, process, or service by trade name, trademark, manufacturer, or otherwise, does not nec- essarily constitute or imply its endorsement, recommendation, or fa- voring by the United States Government or any agency thereof. The views and opinions of authors expressed herein do not necessarily state or reflect those of the United States Government or any agency thereof. ORNL/TM-2016/687 Computer Science and Mathematics Division Resilience Design Patterns A Structured Approach to Resilience at Extreme Scale version 1.0 Saurabh Hukerikar Christian Engelmann Date Published: October 2016 Prepared by OAK RIDGE NATIONAL LABORATORY Oak Ridge, TN 37831-6283 managed by UT-Battelle, LLC for the US DEPARTMENT OF ENERGY under contract DE-AC05-00OR22725 CONTENTS LIST OF FIGURES . iv LIST OF TABLES . v ACKNOWLEDGMENTS . vii ABSTRACT . viii 1. Introduction . 1 2. Resilience Terminology and Concepts . 4 2.1 Reliability . 4 2.2 Availability . 4 2.3 Systems . 4 2.4 Faults . 5 2.5 Errors . 5 2.6 Failures . 6 2.7 The Relationship between Faults, Errors and Failures . 7 2.8 Resilience Capabilities . 7 2.8.1 Detection . 7 2.8.2 Containment . 8 2.8.3 Masking . 8 2.9 Resilience Metrics . 8 2.9.1 Reliability Metrics . 8 2.9.2 Availability Metrics . 9 2.9.3 Error and Failure Detection Metrics . 10 2.9.4 Mean Time to Failure . 11 3. The Resilience Challenge for Extreme-Scale HPC Systems . 12 4. Survey of HPC Resilience Techniques . 14 4.1 Hardware-based Techniques . 14 4.2 Software-implemented Techniques . 14 4.2.1 Operating System & Runtime-based Solutions . 14 4.2.2 Message Passing Library-based Solutions . 15 4.2.3 Compiler-based Solutions . 15 4.2.4 Programming Model Techniques . 16 4.2.5 Algorithm-Based Fault Tolerance . 17 4.3 Cooperative Hardware/Software Approaches . 18 5. Design Patterns for Resilience . 19 5.1 Introduction to Design Patterns . 19 5.2 Design Patterns for HPC Resilience Solutions . 19 5.3 Anatomy of a Resilience Design Pattern . 20 6. Classification of Resilience Design Patterns . 21 7. The Resilience Pattern Catalog . 23 7.1 Describing Design Patterns . 23 7.2 Strategy Patterns . 25 7.2.1 Fault Treatment Pattern . 25 7.2.2 Recovery Pattern . 26 7.2.3 Compensation Pattern . 28 7.3 Architectural Patterns . 29 7.3.1 Fault Diagnosis Pattern . 29 7.3.2 Reconfiguration Pattern . 30 3 7.3.3 Checkpoint Recovery Pattern . 32 7.3.4 State Diversity Pattern . 33 7.3.5 Design Diversity Pattern . 34 7.4 Structural Patterns . 35 7.4.1 Monitoring Pattern . 35 7.4.2 Prediction Pattern . 37 7.4.3 Restructure Pattern . 38 7.4.4 Rejuvenation Pattern . 39 7.4.5 Reinitialization Pattern . 40 7.4.6 Roll-back Pattern . 41 7.4.7 Roll-forward Pattern . 42 7.4.8 N-modular Redundancy Pattern . 44 7.4.9 N-version Design Pattern . 45 7.4.10 Recovery Block Pattern . 46 7.5 State Patterns . 47 7.5.1 Persistent State Pattern . 47 7.5.2 Dynamic State Pattern . 48 7.5.3 Environment State Pattern . 49 7.5.4 Stateless Pattern . 50 8. Building Resilience Solutions using Resilience Design Patterns . 52 8.1 Features of Resilience Solutions . 52 8.2 Design Spaces . 52 9. Case Study: Checkpoint and Rollback . 54 10. Case Study: Proactive Process Migration . 56 11. Case Study: Cross-Layer Hardware/Software Hybrid Solution . 58 12. Summary . 60 iii LIST OF FIGURES 1 Relationship between fault, error and failure . 7 2 Anatomy of a Resilient Design Pattern . 20 3 Classification of resilience design patterns . 21 4 Elements of a resilience solution for HPC systems and applications . 52 5 Design Spaces for construction of resilience solutions using patterns . 53 6 Resilience Solution Case Study: Checkpoint & Restart using BLCR . 54 7 Resilience Solution Case Study: Process Migration . 56 8 Resilience Solution Case Study: Cross-Layer Design using ECC with ABFT . 58 iv LIST OF TABLES 1 Availability measured by the “nines” . 10 v ACKNOWLEDGMENTS This material is based upon work supported by the U.S. Department of Energy, Office of Science, Office of Advanced Scientific Computing Research, Early Career Research Program under contract number DE-AC05-00OR22725. vii ABSTRACT Reliability is a serious concern for future extreme-scale high-performance computing (HPC) systems. Pro- jections based on the current generation of HPC systems and technology roadmaps suggest that very high fault rates in future systems. The errors resulting from these faults will propagate and generate various kinds of failures, which may result in outcomes ranging from result corruptions to catastrophic application crashes. Practical limits on power consumption in HPC systems will require future systems to embrace innovative architectures, increasing the levels of hardware and software complexities. The resilience challenge for extreme-scale HPC systems requires management of various hardware and software technologies that are capable of handling a broad set of fault models at accelerated fault rates. These techniques must seek to improve resilience at reasonable overheads to power consumption and performance. While the HPC community has developed various solutions, application-level as.
Load more

Recommended publications
  • Automating Testing with Autofixture, Xunit.Net & Specflow
    Design Patterns Michael Heitland Oct 2015 Creational Patterns • Abstract Factory • Builder • Factory Method • Object Pool* • Prototype • Simple Factory* • Singleton (* this pattern got added later by others) Structural Patterns ● Adapter ● Bridge ● Composite ● Decorator ● Facade ● Flyweight ● Proxy Behavioural Patterns 1 ● Chain of Responsibility ● Command ● Interpreter ● Iterator ● Mediator ● Memento Behavioural Patterns 2 ● Null Object * ● Observer ● State ● Strategy ● Template Method ● Visitor Initial Acronym Concept Single responsibility principle: A class should have only a single responsibility (i.e. only one potential change in the S SRP software's specification should be able to affect the specification of the class) Open/closed principle: “Software entities … should be open O OCP for extension, but closed for modification.” Liskov substitution principle: “Objects in a program should be L LSP replaceable with instances of their subtypes without altering the correctness of that program.” See also design by contract. Interface segregation principle: “Many client-specific I ISP interfaces are better than one general-purpose interface.”[8] Dependency inversion principle: One should “Depend upon D DIP Abstractions. Do not depend upon concretions.”[8] Creational Patterns Simple Factory* Encapsulating object creation. Clients will use object interfaces. Abstract Factory Provide an interface for creating families of related or dependent objects without specifying their concrete classes. Inject the factory into the object. Dependency Inversion Principle Depend upon abstractions. Do not depend upon concrete classes. Our high-level components should not depend on our low-level components; rather, they should both depend on abstractions. Builder Separate the construction of a complex object from its implementation so that the two can vary independently. The same construction process can create different representations.
    [Show full text]
  • (MVC) Design Pattern Untuk Aplikasi Perangkat Bergerak Berbasis Java
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Diponegoro University Institutional Repository Model-View-Controller (MVC) Design Pattern Untuk Aplikasi Perangkat Bergerak Berbasis Java Panji Wisnu Wirawan Program Studi Teknik Informatika, Universitas Diponegoro [email protected] Abstrak Design pattern merupakan salah satu teknik mendesain komponen perangkat lunak yang bisa digunakan kembali. MVC design pattern merupakan design pattern untuk komponen perangkat lunak yang memisahkan secara tegas antara model data, tampilan, dan kendali perangkat lunak. Artikel ini akan membahas MVC design pattern disertai kesesuaiannya dengan aplikasi perangkat bergerak berbasis Java. Bagian akhir artikel ini menunjukkan bagaimana MVC design pattern untuk aplikasi bergerak berbasis Java. Kata Kunci : MVC, design pattern , aplikasi perangkat bergerak berbasis Java ulang sehingga dapat meminimalkan usaha 1. Pendahuluan pengembangan aplikasi perangkat bergerak. Pada umumnya, aplikasi perangkat bergerak menggunakan Komponen perangkat lunak sudah semestinya GUI. Penggunaan MVC diharapkan bermanfaat untuk didesain dan diimplementasikan sehingga bisa pembuatan komponen perangkat lunak untuk aplikasi digunakan ulang ( reused ) pada perangkat lunak yang bergerak yang bisa digunakan ulang. [6] lain . Sebagai contoh penggunaan komponen perangkat lunak yang dapat digunakan ulang adalah Salah satu penelitian mengenai design pattern penggunaan text box , drop down menu dan untuk aplikasi perangkat bergerak berbasis Java telah sebagainya. dilakukan oleh Narsoo dan Mohamudally (2008). Narsoo dan Mohamudally (2008) melakukan Contoh lain dari komponen perangkat lunak identifikasi design pattern untuk mobile services adalah pola-pola tertentu untuk menyelesaikan menggunakan Java 2 Mobile Edition (J2ME). Mobile masalah yang disebut sebagai design pattern . Pola- services tersebut termasuk dalam behavioral pattern pola tersebut akan tetap sama untuk aplikasi yang yaitu add , edit , erase dan search .
    [Show full text]
  • Principles of Programming Languages
    David Liu Principles of Programming Languages Lecture Notes for CSC324 (Version 2.1) Department of Computer Science University of Toronto principles of programming languages 3 Many thanks to Alexander Biggs, Peter Chen, Rohan Das, Ozan Erdem, Itai David Hass, Hengwei Guo, Kasra Kyanzadeh, Jasmin Lantos, Jason Mai, Sina Rezaeizadeh, Ian Stewart-Binks, Ivan Topolcic, Anthony Vandikas, Lisa Zhang, and many anonymous students for their helpful comments and error-spotting in earlier versions of these notes. Dan Zingaro made substantial contributions to this version of the notes. Contents Prelude: The Study of Programming Languages 7 Programs and programming languages 7 Models of computation 11 A paradigm shift in you 14 Course overview 15 1 Functional Programming: Theory and Practice 17 The baseline: “universal” built-ins 18 Function expressions 18 Function application 19 Function purity 21 Name bindings 22 Lists and structural recursion 26 Pattern-matching 28 Higher-order functions 35 Programming with abstract syntax trees 42 Undefined programs and evaluation order 44 Lexical closures 50 Summary 56 6 david liu 2 Macros, Objects, and Backtracking 57 Object-oriented programming: a re-introduction 58 Pattern-based macros 61 Objects revisited 74 The problem of self 78 Manipulating control flow I: streams 83 Manipulating control flow II: the ambiguous operator -< 87 Continuations 90 Using continuations in -< 93 Using choices as subexpressions 94 Branching choices 98 Towards declarative programming 101 3 Type systems 109 Describing type systems 110
    [Show full text]
  • Behavioral Patterns
    Behavioral Patterns 101 What are Behavioral Patterns ! " Describe algorithms, assignment of responsibility, and interactions between objects (behavioral relationships) ! " Behavioral class patterns use inheritence to distribute behavior ! " Behavioral object patterns use composition ! " General example: ! " Model-view-controller in UI application ! " Iterating over a collection of objects ! " Comparable interface in Java !" 2003 - 2007 DevelopIntelligence List of Structural Patterns ! " Class scope pattern: ! " Interpreter ! " Template Method ! " Object scope patterns: ! " Chain of Responsibility ! " Command ! " Iterator ! " Mediator ! " Memento ! " Observer ! " State ! " Strategy ! " Visitor !" 2003 - 2007 DevelopIntelligence CoR Pattern Description ! " Intent: Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. ! " AKA: Handle/Body ! " Motivation: User Interfaces function as a result of user interactions, known as events. Events can be handled by a component, a container, or the operating system. In the end, the event handling should be decoupled from the component. ! " Applicability: ! " more than one object may handle a request, and the handler isn't known a priori. ! " Want to issue a request to one of several objects without specifying the receiver !" 2003 - 2007 DevelopIntelligence CoR Real World Example ! " The Chain of Responsibility pattern avoids coupling the sender of a request to the receiver, by giving more than one object a chance to handle the request. ! " Mechanical coin sorting banks use the Chain of Responsibility. Rather than having a separate slot for each coin denomination coupled with receptacle for the denomination, a single slot is used. When the coin is dropped, the coin is routed to the appropriate receptacle by the mechanical mechanisms within the bank.
    [Show full text]
  • TH`ESE DE DOCTORAT Software Engineering Techniques For
    THESE` DE DOCTORAT de L’UNIVERSITE´ DE NICE – SOPHIA ANTIPOLIS Sp´ecialit´e SYSTEMES` INFORMATIQUES pr´esent´ee par Matthias Jung pour obtenir le grade de DOCTEUR de l’UNIVERSITE´ DE NICE – SOPHIA ANTIPOLIS Sujet de la th`ese: Software Engineering Techniques for Support of Communication Protocol Implementation Soutenu le 3 Octobre 2000 devant le jury compos´e de: Pr´esident Dr. Walid Dabbous Directeur de Recherche, INRIA Rapporteurs Dr. Wolfgang Effelsberg Professeur, Universit´e de Mannheim Dr. B´eatrice Paillassa Maˆıtre de Conf´erence, ENSEEIHT Membre Invit´e Dr. Vincent Roca Charg´e de Recherche, INRIA Directeur de Th`ese Dr. Ernst W. Biersack Professeur, Institut Eur´ecom ii Acknowledgements Thanks to my supervisor Ernst Biersack for his trust and his honesty, his encouragement, and the many things I’ve learned during the last three years. Thanks to Stefan B¨ocking and the people from Siemens Research (ZT IK2) for their financial support, which gave me the opportunity to follow my PhD studies at Eur´ecom. Thanks to the members of my jury – Walid Dabbous, Wolfgang Effelsberg, B´eatrice Paillassa, and Vincent Roca – for the time they spent to read and comment my work. Thanks to Didier Loisel and David Tr´emouillac for their permanent cooperation and competent help concerning hardware and software administration. Thanks to Evelyne Biersack, Morsy Cheikhrouhou, Pierre Conti, and Yves Roudier for reading and correcting the french part of my dissertation. Thanks to the btroup members and to all people at Eur´ecom who contributed to this unique atmosphere of amity and inspiration. Thanks to Sergio for his open ear and for never running out of cookies.
    [Show full text]
  • Behavioral Patters
    11. Behavioral Pattern Venkat Subramaniam BDP-1 Behavioral Patters • Concerned with algorithms & assignment of responsibilities • Patterns of Communication between Objects Venkat Subramaniam BDP-2 Chain of Responsibility Pattern —Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it“ Venkat Subramaniam BDP-3 Example that would benefit from Chain Of Responsibility Pattern • Various types of Controls are used in an application. Controls handle certain events while they do not handle others. Each control may be invoked from other controls. An event not handled by a control must be passed on to its parent control. Venkat Subramaniam BDP-4 Example using Chain of Responsibility Pattern Client Event Handler handleEvent() Control1 Control2 handleEvent() handleEvent() Venkat Subramaniam BDP-5 When to use Chain Of Responsibility Pattern • More than one object may handle a request, and the handler isn‘t known ahead of time. • One of several objects may be the intended receiver • Set of objects that handle request is dynamic Venkat Subramaniam BDP-6 Consequences of using Chain Of Responsibility • Reduced Coupling • Flexibility in assigning responsibilities œ Distributes responsibilities among objects • Receipt isn‘t guaranteed Venkat Subramaniam BDP-7 Chain Of Responsibility Vs. Other Patterns • Often used with Composite œ Parent acts as Successor Venkat Subramaniam BDP-8 Iterator Pattern —Provide
    [Show full text]
  • Scala by Example (2009)
    Scala By Example DRAFT January 13, 2009 Martin Odersky PROGRAMMING METHODS LABORATORY EPFL SWITZERLAND Contents 1 Introduction1 2 A First Example3 3 Programming with Actors and Messages7 4 Expressions and Simple Functions 11 4.1 Expressions And Simple Functions...................... 11 4.2 Parameters.................................... 12 4.3 Conditional Expressions............................ 15 4.4 Example: Square Roots by Newton’s Method................ 15 4.5 Nested Functions................................ 16 4.6 Tail Recursion.................................. 18 5 First-Class Functions 21 5.1 Anonymous Functions............................. 22 5.2 Currying..................................... 23 5.3 Example: Finding Fixed Points of Functions................ 25 5.4 Summary..................................... 28 5.5 Language Elements Seen So Far....................... 28 6 Classes and Objects 31 7 Case Classes and Pattern Matching 43 7.1 Case Classes and Case Objects........................ 46 7.2 Pattern Matching................................ 47 8 Generic Types and Methods 51 8.1 Type Parameter Bounds............................ 53 8.2 Variance Annotations.............................. 56 iv CONTENTS 8.3 Lower Bounds.................................. 58 8.4 Least Types.................................... 58 8.5 Tuples....................................... 60 8.6 Functions.................................... 61 9 Lists 63 9.1 Using Lists.................................... 63 9.2 Definition of class List I: First Order Methods..............
    [Show full text]
  • HEDGEHOG: Automatic Verification of Design Patterns in Java
    HEDGEHOG: Automatic Verification of Design Patterns in Java Alex Blewitt I V N E R U S E I T H Y T O H F G E R D I N B U Doctor of Philosophy School of Informatics University of Edinburgh 2006 Abstract Design patterns are widely used by designers and developers for building complex systems in object-oriented programming languages such as Java. However, systems evolve over time, increasing the chance that the pattern in its original form will be broken. To verify that a design pattern has not been broken involves specifying the original intent of the design pattern. Whilst informal descriptions of patterns exist, no formal specifications are available due to differences in implementations between programming languages. This thesis shows that many patterns (implemented in Java) can be verified automatically. Patterns are defined in terms of variants, mini-patterns, and artefacts in a pattern description language called SPINE. These specifications are then processed by HEDGEHOG, an automated proof tool that attempts to prove that Java source code meets these specifications. iii Acknowledgements I am indebted to Alan Bundy who has given me the freedom to work on this thesis whilst at the same time guiding me towards the final production and presentation of these results. I not would have been able to achieve this without Alan’s support through a sometimes difficult, but always busy part of my life. This project, and especially the production of this thesis, would not have been possible without the care and attention that Alan provided. Ian Stark has provided invaluable feedback on all aspects of this thesis, from the low-level technical intricacies of Java’s design patterns through to the high-level structure of the thesis as a whole.
    [Show full text]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]
  • Design Pattern- Structural Pattern 2015
    Design Pattern- Structural pattern 2015 Adapter Intent: Change the interface of a class into another interface which is expected by the client. Also Know As: Wrapper Motivation Structure (Class) Structure (Object) Applicability • Use an existing class whose interface does not match the requirement • Create a reusable class though the interfaces are not necessary compatible with callers • Want to use several existing subclasses, but it is impractical to subclass everyone. (Object Adapter Only) Participants Target (Shape) 1 | P a g e Almas Ansari Design Pattern- Structural pattern 2015 defines the domain-specific interface that Client uses. Client (DrawingEditor) collaborates with objects conforming to the Target interface. Adaptee (TextView) defines an existing interface that needs adapting. Adapter (TextShape) adapts the interface of Adaptee to the Target interface. Collaborations Clients call operations on an Adapter instance. In turn, the adapter calls Adaptee operations that carry out the request. Consequences Here are other issues to consider when using the Adapter pattern: 1. How much adapting does Adapter do? Adapters vary in the amount of work they do to adapt Adaptee to the Target interface. 2. Pluggable adapters. A class is more reusable when you minimize the assumptions other classes must make to use it. 3. Using two-way adapters to provide transparency. A potential problem with adapters is that they aren't transparent to all clients. Implementation 1. Implementing class adapters in C++. In a C++ implementation of a class adapter, Adapter would inherit publicly from Target and privately from Adaptee. Thus Adapter would be a subtype of Target but not of Adaptee. 2.
    [Show full text]
  • UNIT-I TUTORIAL QUESTIONS 1. Explain the Concept of Design Pattern? 2
    UNIT-I TUTORIAL QUESTIONS 1. Explain the concept of design pattern? 2. Explain the advantages and disadvantages of structural patterns? 3. Explain proxy design pattern in detail? 4. Explain the concept of design pattern relationship? 5. Explain the state pattern in detail? UNIT-I UNIVERSITY QUESTIONS 1. Explain the template of a design pattern? 2. Explain the state pattern in detail? 3. Explain proxy design pattern in detail? 4. Explain the features of structural pattern? 5. Explain the concept of design pattern relationship? UNIT-I DESCRIPTIVE QUESTIONS 1. Explain the template of a design pattern? 2. Explain the state pattern in detail? 3. Explain proxy design pattern in detail? 4. Explain the features of structural pattern? 5. Explain the concept of design pattern relationship? UNIT-I ASSIGNMENT QUESTIONS 1. Explain the template of a design pattern? 2. Explain the state pattern in detail? 3. Explain proxy design pattern in detail? 4. Explain the features of structural pattern? 5. Explain the concept of design pattern relationship? UNIT-I OBJECTIVE QUESTIONS 1. A pattern in general refers to layout 2. A Design pattern can be considered as Reusable solution 3. The concept of design pattern was introduced by Christopher Alexander 4. Essential elements of D.P are Pattern Name,Problem,Solution,Consequences 5. Catalog consists of Abstract factory,Adapter,Bridge 6. Creation Patterns are Factory method, Builder, Prototype 7. Structural Patterns are Factory method, Builder, Prototype 8. Design Patterns specify Object implementation 9. Design Patterns specify Object Interfaces 10. Design Patterns specify Appropriate Objects UNIT-I SEMINAR TOPICS 1. Template of D.P 2.
    [Show full text]
  • A Pattern Language for Designing Application-Level Communication Protocols and the Improvement of Computer Science Education Through Cloud Computing
    Utah State University DigitalCommons@USU All Graduate Theses and Dissertations Graduate Studies 5-2017 A Pattern Language for Designing Application-Level Communication Protocols and the Improvement of Computer Science Education through Cloud Computing Jorge Edison Lascano Utah State University Follow this and additional works at: https://digitalcommons.usu.edu/etd Part of the Computer Sciences Commons Recommended Citation Lascano, Jorge Edison, "A Pattern Language for Designing Application-Level Communication Protocols and the Improvement of Computer Science Education through Cloud Computing" (2017). All Graduate Theses and Dissertations. 6547. https://digitalcommons.usu.edu/etd/6547 This Dissertation is brought to you for free and open access by the Graduate Studies at DigitalCommons@USU. It has been accepted for inclusion in All Graduate Theses and Dissertations by an authorized administrator of DigitalCommons@USU. For more information, please contact [email protected]. A PATTERN LANGUAGE FOR DESIGNING APPLICATION-LEVEL COMMUNICATION PROTOCOLS AND THE IMPROVEMENT OF COMPUTER SCIENCE EDUCATION THROUGH CLOUD COMPUTING by Jorge Edison Lascano A dissertation submitted in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY in Computer Science Approved: ______________________ ____________________ Stephen W. Clyde, Ph.D. Curtis Dyreson, Ph.D. Major Professor Committee Member ______________________ ____________________ Haitao Wang, Ph.D. Young-Woo Kwon, Ph.D. Committee Member Committee Member ______________________ ____________________ Luis Gordillo, Ph.D. Mark R. McLellan, Ph.D. Committee Member Vice President for Research and Dean of the School of Graduate Studies UTAH STATE UNIVERSITY Logan, Utah 2017 ii Copyright © Jorge Edison Lascano 2017 All Rights Reserved iii ABSTRACT A Pattern Language for Designing Application-Level Communication Protocols and the Improvement of Computer Science Education through Cloud Computing by Jorge Edison Lascano, Doctor of Philosophy Utah State University, 2017 Major Professor: Stephen W.
    [Show full text]