DOCSLIB.ORG

Real-Time Middleware

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Real-Time Middleware Design Patterns and Component Framework for Building RTSJ-Based Real-Time Middleware Mohammed Fathi Alrahmawy PhD The University of York Computer Science Department YORK, UK September 2010 Abstract The middleware is a software layer located on top of the operating system that uses its facilities, integrates with it, and extends its functionality in order to support the development of effective and reliable distributed systems; however, the architectures of most of the conventional middleware solutions, e.g. Java RMI, do not either offer the predictability required to support the real-time behaviour in these systems, or the reconfigurablity required for these middleware solutions to be applicable in a wide range of distributed systems. Java has a great support for building distributed systems; however, due to its unpredictability, Java does not support building distributed real-time systems and middleware solutions. Hence, this thesis argues that the RTSJ can be used to build reusable and reconfigurable software components and design patterns that have high levels of predictability and reliability. These proposed real-time components and design patterns can be used for building real-time middleware solutions in Java. Therefore, the RTSJ has to be used as a base for modifying the existing reconfigurable and reusable software patterns and components for distribution models. It could also be used to create a new set of these patterns and components, in order to support the real-time behaviour and the predictability in the real-time middleware. The key contributions in this thesis include the presentation of a component framework design model for building RTSJ-based middleware and distributed systems; this framework focuses mainly on the memory model, the communication model of building the components and it also provides the management mechanism of these components, which uses a set of design patterns that integrates with these models. This includes a memory model for the RTSJ components associated with a set of reusability and life-management sub-components that support building real-time components in the RTSJ. Also, we provided a design of a real-time reconfigurable communication component based on the RTSJ that can be used to support predictable low level remote communications in distributed real-time Java applications and we showed how this component could be integrated within the component model as a sub-component, to provide communication services within the component model. Also, we presented our own model of integrating both the framework and the component model within the RMI architecture to provide a reconfigurable real-time Java RMI middleware based on the RTSJ. Table of Contents Abstract ............................................................................................................... Chapter 1 .......................................................................................................... 1 1.1 Overview of Distributed Real-Time Systems ..................................... 3 1.1.1 Definitions of Real-Time Systems ................................................. 4 1.1.2 Classification of Real-Time Systems ............................................. 5 1.1.3 Definition of Distributed Real-Time Systems ................................ 7 1.2 Overview of Real-time Middleware .................................................... 8 1.2.1 Definition of Middleware ............................................................... 8 1.2.2 Middleware Characteristics ............................................................ 9 1.2.3 Middleware Classifications .......................................................... 10 1.3 Motivations and Research Scope ...................................................... 13 1.4 Thesis Goals, Hypothesis and Contribution ...................................... 15 1.5 Thesis Structure ................................................................................. 17 1.6 Summary ........................................................................................... 20 Chapter 2 ........................................................................................................ 21 2.1 Message Passing Paradigm ............................................................... 22 2.2 The Client Server Paradigm .............................................................. 26 2.3 The Peer-to-Peer Paradigm ............................................................... 27 2.4 The Message System Paradigm ......................................................... 30 2.5 Remote Procedure Call Paradigm (RPC) .......................................... 34 2.6 The Distributed Object Paradigms .................................................... 34 2.6.1 Remote Method Invocation (RMI) ............................................... 35 2.6.2 The Network Service Paradigm ................................................... 35 2.6.3 The Object Request Broker Paradigm (ORB) .............................. 36 2.7 Component Oriented Architecture (COA) Paradigm ........................ 36 2.8 The Application Server Paradigm ..................................................... 37 2.9 The Tuple Space (Object Space) Paradigm ....................................... 38 2.10 The Collaborative Application (Groupware) Paradigm .................... 41 2.11 Summary ........................................................................................... 42 Chapter 3 ........................................................................................................ 45 3.1 Java and Real-Time systems ............................................................. 45 3.2 Overview of Java RMI System Architecture..................................... 48 3.2.1 RMI Layers .................................................................................. 49 3.2.2 RMI Distributed Garbage Collection (DGC) ............................... 51 3.3 RMI Framework Implementation ...................................................... 52 3.3.1 RMI Client Implementation ......................................................... 52 3.3.2 RMI Server Implementation ......................................................... 53 3.4 Problems and Requirements of RMI in RT Systems ......................... 55 3.4.1 Java and JVM Requirements ........................................................ 55 3.4.2 RTSJ Support................................................................................ 57 3.4.3 RMI Tools .................................................................................... 58 3.4.4 RMI programming model ............................................................. 58 3.4.5 RMI Implementation .................................................................... 60 3.5 Levels of Integrating RTSJ and RMI................................................. 62 3.5.1 Level-0 Integration: Minimal Integration ..................................... 63 3.5.2 Level-1 Integration: Real-Time RMI ........................................... 63 3.5.3 Level-2 Integration: Distributed Real time threads ...................... 64 3.6 RT-RMI (Level-1) Models ................................................................ 68 3.6.1 Adaptations in the RMI-HRT ....................................................... 69 3.6.2 Adaptations in the RMI-QoS ........................................................ 72 3.7 RT-CORBA ....................................................................................... 75 3.7.1 RT-CORBA Features ................................................................... 75 3.7.2 RT-CORBA and the RTSJ ........................................................... 76 3.8 Summary ............................................................................................ 79 Chapter 4 ......................................................................................................... 81 4.1 Real-time Java ................................................................................... 81 4.2 Real-time Java Enhancements ........................................................... 82 4.2.1 Threads and Scheduling ............................................................... 82 4.2.2 Memory Management in the RTSJ ............................................... 84 4.3 Component Based Software Engineering .......................................... 90 4.3.1 Component Definition .................................................................. 91 4.3.2 Characteristics of the Components ............................................... 92 4.3.3 Disadvantages of Components ..................................................... 93 4.3.4 Basics of Component Based Systems ........................................... 94 4.3.5 Components in Real-time Systems ............................................... 97 4.3.6 Components Models in Java for Distributed Systems ................ 101 As we mentioned in the last chapters, Java language supports middleware for distributed systems mainly in Java RMI and CORBA. The component technology found its way in these two middleware solutions, to support components in distributed systems. There are mainly two component models built over these two middleware solutions. These two models are: ............................................... 101 4.3.7 Components in Real–time Java .................................................. 101 4.4 Software Patterns ............................................................................. 103 4.4.1 Definition of the Software Pattern
Load more

Recommended publications
  • Srm University Faculty of Engineering and Technology
    SRM UNIVERSITY FACULTY OF ENGINEERING AND TECHNOLOGY SCHOOL OF COMPUTING DEPARTMENT OF SWE COURSE PLAN Course Code : CS0373 Course Title : DESIGN PATTERNS Semester : VII Course Time : July – December 2014 C Day Hour Timing Day 1 6 2.20 to 3.10 Day 3 5 1.30 to 2.20 Day 5 3,5 10.35 to 11.25 and 1.30 to 2.20 Location : S.R.M.E.C – University Building (12 th Floor) Faculty Details Sec. Name Office Office hour Mail id Ms. Cinza Susan University Monday to Friday [email protected] Abraham Building Required Text Books: TEXT BOOK 1Alan Shalloway, James Trott, “Design Patterns Explained: A New Perspective on Object- Oriented Design”,Addison-Wesley, 2005 2. Joshua Kerievsky, “Refactoring to Patterns”, Addison-Wesley, 2004 REFERENCE BOOKS 1. Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, “Design Patterns : Elements of Reusable Object-Oriented Software”, Addison-Wesley, 1995. 2. Eric Freeman, Elisabeth Freeman, Kathy Sierra, Bert Bates, “Head First Design Patterns”, O'Reilly Media, Inc., 2004. 3. Martin Fowler, Kent Beck, John Brant, William Opdyke, Don Roberts.“Refactoring: Improving the Design of Existing Code”, Addison-Wesley, 1999. Prerequisite : Software Engineering Principles Software Architecture Software Design Objectives This course introduces the students to 1. Understand and be able to apply incremental/iterative development 2. Understand common design patterns 3. Be able to identify appropriate design patterns for various problems 4. Be able to refactor poorly designed program by using appropriate design patterns. Assessment Details Cycle Test 1 : 10 Marks Cyle Test II : 10 Marks Model Exam : 20 Marks Surprise Test : 5 Marks Attendance : 5 Marks Test Schedule S.No.
    [Show full text]
  • Design Patterns. Introduction
    DESIGN PATTERNS COURSE 1 OGANIZATION q Course q Each week 2 hours, Room 050A q Laboratory q Each odd/even school week, Room 050A q Presence q Course: minimum 50% q Laboratory: minimum 50% q Grade q Written exam 50% q Course activity 1%+ laboratory activity 24% q Presentation of a pattern 10% q Project 15% ORGANIZATION q Course & laboratories q available at http://staff.fmi.uvt.ro/~flavia.micota/ q Contact q e-mail: [email protected] q cab. 046B q Classroom q 1rcgcs COURSE CONTENT q Design patterns q Creational q Structural q Behavioral q Refactoring q Anti-patterns q Students presentations of a pattern WAY YOU CHOSE THIS COURSE? WAY YOU CHOSE THIS COURSE? q Some reasons from http://www.ida.liu.se/~chrke55/courses/SWE/bunus/DP01_1sli de.pdf q I could get some easy points. q Everybody is talking about so it must to be cool. q If I master this I can added it to my CV. q Increase my salary at the company. q Applying patterns is easier than thinking q A great place to pick up ideas to plagiarize. DESIGN CHALLENGES q Designing software with good modularity is hard! q Designs often emerge from a lot of trial and error q Are there solutions to common recurring problems? q A Design Pattern is a Tried and True Solution To a Common Problem q Basically, people, who have done this a lot, are making a suggestion! SOURCE CODE QUALITY q What characteristics should be respected in order to deliver a quality sorce code for a project? SOURCE CODE QUALITY q What characteristics should be respected in order to deliver a quality sorce code for a project? q Easy to read/understood – clear q Easy to modify – structured q Easy to reuse q Simple (complexity) q Easy to test q Implements patterns for standard problems SOURCE CODE QUALITY q What influence source code quality? q Development time q Costs q Programmer experience q Programmer abilities q Specifications clarity q Solution complexity q Requirements change rate, team, … PATTERNS q A pattern is a recurring solution to a standard problem, in a context.
    [Show full text]
  • Applying the Proactor Pattern to High-Performance Web Servers
    APPLYING THE PROACTOR PATTERN TO HIGH-PERFORMANCE WEB SERVERS James Hu Irfan Pyarali Douglas C. Schmidt [email protected],edu [email protected] [email protected] Department of Computer Science, Washington University St. Louis, MO 63130, USA This paper is to appear at the 10th International Confer- 1 INTRODUCTION ence on Parallel and Distributed Computing and Systems, IASTED, Las Vegas, Nevada, October 28-31, 1998. Computing power and network bandwidth on the Internet has increased dramatically over the past decade. High- speed networks (such as ATM and Gigabit Ethernet) and high-performance I/O subsystems (such as RAID) are be- ABSTRACT coming ubiquitous. In this context, developing scalable Web servers that can exploit these innovations remains a Modern operating systems provide multiple concurrency key challenge for developers. Thus, it is increasingly im- mechanisms to develop high-performance Web servers. portant to alleviate common Web server bottlenecks, such Synchronous multi-threading is a popular mechanism for as inappropriate choice of concurrency and dispatching developing Web servers that must perform multiple oper- strategies, excessive filesystem access, and unnecessary ations simultaneously to meet their performance require- data copying. ments. In addition, an increasing number of operating sys- Our research vehicle for exploring the performance im- tems support asynchronous mechanisms that provide the pact of applying various Web server optimization tech- benefits of concurrency, while alleviating much of the per- niques is the JAWS Adaptive Web Server (JAWS) [1]. JAWS formance overhead of synchronous multi-threading. is both an adaptive Web server and a development frame- This paper provides two contributions to the study of work for Web servers that runs on multiple OS platforms high-performance Web servers.
    [Show full text]
  • Designpatternsphp Documentation Release 1.0
    DesignPatternsPHP Documentation Release 1.0 Dominik Liebler and contributors Jul 18, 2021 Contents 1 Patterns 3 1.1 Creational................................................3 1.1.1 Abstract Factory........................................3 1.1.2 Builder.............................................8 1.1.3 Factory Method......................................... 13 1.1.4 Pool............................................... 18 1.1.5 Prototype............................................ 21 1.1.6 Simple Factory......................................... 24 1.1.7 Singleton............................................ 26 1.1.8 Static Factory.......................................... 28 1.2 Structural................................................. 30 1.2.1 Adapter / Wrapper....................................... 31 1.2.2 Bridge.............................................. 35 1.2.3 Composite............................................ 39 1.2.4 Data Mapper.......................................... 42 1.2.5 Decorator............................................ 46 1.2.6 Dependency Injection...................................... 50 1.2.7 Facade.............................................. 53 1.2.8 Fluent Interface......................................... 56 1.2.9 Flyweight............................................ 59 1.2.10 Proxy.............................................. 62 1.2.11 Registry............................................. 66 1.3 Behavioral................................................ 69 1.3.1 Chain Of Responsibilities...................................
    [Show full text]
  • Lecture 26: Creational Patterns
    Creational Patterns CSCI 4448/5448: Object-Oriented Analysis & Design Lecture 26 — 11/29/2012 © Kenneth M. Anderson, 2012 1 Goals of the Lecture • Cover material from Chapters 20-22 of the Textbook • Lessons from Design Patterns: Factories • Singleton Pattern • Object Pool Pattern • Also discuss • Builder Pattern • Lazy Instantiation © Kenneth M. Anderson, 2012 2 Pattern Classification • The Gang of Four classified patterns in three ways • The behavioral patterns are used to manage variation in behaviors (think Strategy pattern) • The structural patterns are useful to integrate existing code into new object-oriented designs (think Bridge) • The creational patterns are used to create objects • Abstract Factory, Builder, Factory Method, Prototype & Singleton © Kenneth M. Anderson, 2012 3 Factories & Their Role in OO Design • It is important to manage the creation of objects • Code that mixes object creation with the use of objects can become quickly non-cohesive • A system may have to deal with a variety of different contexts • with each context requiring a different set of objects • In design patterns, the context determines which concrete implementations need to be present © Kenneth M. Anderson, 2012 4 Factories & Their Role in OO Design • The code to determine the current context, and thus which objects to instantiate, can become complex • with many different conditional statements • If you mix this type of code with the use of the instantiated objects, your code becomes cluttered • often the use scenarios can happen in a few lines of code • if combined with creational code, the operational code gets buried behind the creational code © Kenneth M. Anderson, 2012 5 Factories provide Cohesion • The use of factories can address these issues • The conditional code can be hidden within them • pass in the parameters associated with the current context • and get back the objects you need for the situation • Then use those objects to get your work done • Factories concern themselves just with creation, letting your code focus on other things © Kenneth M.
    [Show full text]
  • 8 Lecture 1 Introduction to the Class Diagram
    ECE 573 1st Edition Exam # 1 Study Guide Lectures: 1 - 8 Lecture 1 Introduction to the Class diagram, Inheritance and Association Class Diagram The final code was supplemented with a diagram describing the relationships between classes. The intermediate classes of the code are related by objects. This is what is represented in a class diagram. The Class diagram basically consists of “a Class name”, “attributes” and “operation”. Given this basic graphical notation, it is possible to show the following kinds of relationships between classes: Inheritance Association Encapsulation Inheritance It is denoted using open triangle between Superclass and its Subclass. The triangle “points" to the superclass, and extends to the subclass (es). Inheritance fulfills the IS-A definitions. A derived class can be treated like a base class object under all circumstances. Association General binary relationships between classes. It is commonly represented as direct or indirect references between classes. Associations are shown by a line in the class diagram, with optional role names and multiplicities. Multiplicities can be i) I..u closed ii) I singleton range iii) 0..* entire nonnegative integer. An association may also be specialized by a particular class. This Association class may provide more attributes to describe the association. Encapsulations Encapsulation is a special kind of association, which is denoted using a diamond and extending line. There are two kinds of encapsulation i.e. Aggregation and Composition. Aggregation is a special form of association representing has-a and part-whole relationship. Distinguishes the whole (aggregate class) from its parts (component class). No relationship in the lifetime of the aggregate and the components (can exist separately).
    [Show full text]
  • Table of Contents
    Table of Contents ± -—T^jTp^om Object-Oriented to Functional Programming 5 Chajava- an introduction 5 java programming paradigms 6 CO imperative programming CD Real-life imperative example Object-oriented paradigm 7 Objects and classes 7 Encapsulation 7 Abstraction 8 Inheritance 8 Polymorphism 9 Declarative programming 10 Functional programming 11 Working with collections versus working with streams 11 An introduction to Unified Modeling Language 12 Class relations 14 Generalization 15 Realization 15 Dependency 16 Association 16 Aggregation 16 Composition 17 Design patterns and principles 17 Single responsibility principle 18 Open/closed principle 20 Liskov Substitution Principle 20 Interface Segregation Principle 22 Dependency inversion principle 23 Summary 24 Chapter 2: Creational Patterns 27 Singleton pattern 27 Synchronized singletons 29 Synchronized singleton with double-checked locking mechanism 30 Lock-free thread-safe singleton 30 tu * y and lazy loacling 31 i he factory pattern 31 Simple factory pattern 32 Table of Contents Static factory 33 Simple factory with class registration using reflection 34 Simple factory with class registration using Product.newlnstance 35 Factory method pattern 36 Anonymous concrete factory 38 Abstract factory 38 Simple factory versus factory method versus abstract factory 40 Builder pattern 40 Car builder example 41 Simplified builder pattern 43 Anonymous builders with method chaining 44 Prototype pattern 45 Shallow clone versus deep clone Object pool pattern Summary аэоэсБ Chapter 3: Behavioral Patterns
    [Show full text]
  • IC Coder's Club Design Patterns (In C++)
    Andrew W. Rose Simple exercise You have been tasked to move this pile from A to B Simple exercise You have been tasked to move this pile from A to B You have three resources available to you: a) Bare hands b) A stack of timber c) A horse and cart Simple exercise You have been tasked to move this pile from A to B You have three resources available to you: a) Bare hands b) A stack of timber c) A horse and cart How do you achieve the task in the quickest, least-painful way, which won’t leave you up-to-your-neck in the produce you are moving, nor smelling of it? Software analogy a) Bare hands b) A stack of timber c) A horse and cart Software analogy a) Bare hands b) A stack of timber c) A horse and cart Do a task manually Software analogy a) Bare hands b) A stack of timber c) A horse and cart Design Do a task the tools manually yourself Software analogy a) Bare hands b) A stack of timber c) A horse and cart Benefit from Design Do a task someone the tools manually else’s yourself hard work Software analogy a) Bare hands b) A stack of timber c) A horse and cart Benefit from someone else’s This is the purpose of design patterns! hard work Motivation I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important: Bad programmers worry about the code; good programmers worry about data structures and their relationships.
    [Show full text]
  • A Design Framework for Highly Concurrent Systems
    A Design Framework for Highly Concurrent Systems Matt Welsh, Steven D. Gribble, Eric A. Brewer, and David Culler Computer Science Division University of California, Berkeley Berkeley, CA 94720 USA mdw,gribble,brewer,culler @cs.berkeley.edu f g Abstract In addition to high concurrency, Internet services have three other properties which necessitate a fresh Building highly concurrent systems, such as large-scale look at how these systems are designed: burstiness, Internet services, requires managing many information flows continuous demand, and human-scale access latency. at once and maintaining peak throughput when demand ex- Burstiness of load is fundamental to the Internet; deal- ceeds resource availability. In addition, any platform sup- ing with overload conditions must be designed into the porting Internet services must provide high availability and be able to cope with burstiness of load. Many approaches system from the beginning. Internet services must also to building concurrent systems have been proposed, which exhibit very high availability, with a downtime of no generally fall into the two categories of threaded and event- more than a few minutes a year. Finally, because ac- driven programming. We propose that threads and events cess latencies for Internet services are at human scale are actually on the ends of a design spectrum, and that and are limited by WAN and modem access times, an the best implementation strategy for these applications is important engineering tradeoff to make is to optimize somewhere in between. for high throughput rather than low latency. We present a general-purpose design framework for build- ing highly concurrent systems, based on three design com- Building highly concurrent systems is inherently dif- ponents | tasks, queues, and thread pools | which encapsu- ficult.
    [Show full text]
  • NET Design Patterns
    .NET Design Patterns Duration: 3 days CAC Noida is an ISO 9001:2015 certified training center with professional experience that dates back to 2005. The vision is to provide professional education merging corporate culture globally to the youth through technology resourcing and knowledge consulting with emerging technologies. Quality assurance parameters for each stage of training and development are ensured at all levels. The operating office is solely based Noida (U.P) India. CAC Noida is the well-known .NET Design Patterns training center in Noida with high tech infrastructure and friendly environment. We provide hands on practical knowledge and full job assistance with basic as well as advanced level CAC Noida is one of the best .NET Design Patterns training institute in Noida with 100% placement record. CAC Noida has well defined courses and modules with training sessions for developers. At CAC Noida, .NET Design Patterns training is conducted by specialist Trainers having experience of more than 10+ years. CAC Noida is well-equipped .NET Design Patterns training center in Noida and we offer job oriented .NET Design Patterns training program keeping an eye on industry requirements and future prospects. Each and every one who is part of “CAC Noida” is important to us. Every student has the freedom to discuss and learn. We always take care that right student choose right course. .NET Design Patterns is the one of high in demand course today and CAC Noida provides practical exposure to all the concepts, contents are well-structured to meet the industry requirements. We are confident that .NET Design Patterns training we deliver is at a fantastic standard and are constantly striving to improve and become even better.
    [Show full text]
  • Leader/Followers a Design Pattern for Efficient Multi-Threaded I/O
    Leader/Followers A Design Pattern for Efficient Multi-threaded I/O Demultiplexing and Dispatching Douglas C. Schmidt and Carlos O’Ryan g fschmidt,coryan @uci.edu Electrical and Computer Engineering Dept. University of California, Irvine, CA 92697, USA Michael Kircher Irfan Pyarali [email protected] [email protected] Siemens Corporate Technology Department of Computer Science, Washington University Munich, Germany St. Louis, MO 63130, USA 1 Intent The front-end communication servers are actually “hybrid” client/server applications that perform two primary tasks. The Leader/Followers design pattern provides a concurrency First, they receive requests arriving simultaneously from hun- model where multiple threads can efficiently demultiplex dreds or thousands of remote clients over wide area commu- events and dispatch event handlers that process I/O handles nication links, such as X.25 or the TCP/IP. Second, they vali- shared by the threads. date the remote client requests and forward valid requests over TCP/IP connections to back-end database servers. In contrast, the back-end database servers are “pure” servers that perform 2 Example the designated transactions. After a transaction commits, the database server returns its results to the associated commu- Consider the design of a multi-tier, high-volume, on-line trans- nication server, which then forwards the results back to the action processing (OLTP) system shown in the following fig- originating remote client. ure. In this design, front-end communication servers route FRONT--END BACK--END The servers in this OLTP system spend most of their time COMM.. SERVERS DATABASE SERVERS processing various types of I/O operations in response to re- quests.
    [Show full text]
  • Introduction to Patterns and Frameworks
    OO Patterns Douglas C. Schmidt Patterns and Frameworks Introduction to Patterns and Frameworks Motivation for Patterns and Frameworks Douglas C. Schmidt What is a Pattern? A Framework? Professor Department of EECS Pattern Categories [email protected] Vanderbilt University www.cs.wustl.edu/ schmidt/ (615) 343-8197 Pattern Examples Vanderbilt University 1 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Motivation for Patterns and Frameworks Overview of Patterns and Frameworks DX Developing software is hard BLOB Patterns support reuse of software architecture and design STORE Developing reusable – Patterns capture the static and dynamic structures and ATM software is even harder collaborations of successful solutions to problems that arise when LAN DIAGNOSTIC STATIONS building applications in a particular domain Proven solutions include patterns and frameworks Frameworks support reuse of detailed design and code ATM www.cs.wustl.edu/ schmidt/ – A framework is an integrated set of components that collaborate MAN CLUSTER patterns.html to provide a reusable architecture for a family of related ATM BLOB LAN STORE applications Together, design patterns and frameworks help to improve software MODALITIES CENTRAL quality and reduce development time (CT, MR, CR) BLOB STORE – e.g., reuse, extensibility, modularity, performance Vanderbilt University 2 Vanderbilt University 3 OO Patterns Douglas C. Schmidt OO Patterns Douglas C. Schmidt Patterns of Learning Becoming a Chess Master First learn the rules Successful solutions to many areas of human endeavor are deeply rooted in patterns – e.g., names of pieces, legal movements, chess board geometry and orientation, etc. – In fact, an important goal of education is transmitting patterns of learning from generation to generation Then learn the principles – e.g., relative value of certain pieces, strategic value of center In a moment, we’ll explore how patterns are used to learn chess squares, power of a threat, etc.
    [Show full text]