DOCSLIB.ORG

A Functional Pattern System for Object-Oriented Design

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Functional Pattern System for Object-Oriented Design A Functional Pattern System for Object-Oriented Design Thomas Kuhne ¨ ♦ A child does not dis- cover the world by learning abstract rules. Instead it learns by looking at concrete examples. An example contains the rules as well. In contrast to rules, the recognition of examples can be based on tangible reality. The knowledge extracted from an example serves as a Pattern that is used to remember facts and to construct new solutions. When grown-ups are about to learn something or have to apply unknown tools, they are put into a child’s position again. They will favor concrete examples over abstract rules. The rules will happily be gen- erated automatically, for this is how the brain works. ♦ Thesis iii Thesis Design patterns inspired by functional programming concepts can advance object- oriented design. Problem The object-oriented paradigm has undoubtfully raised our ability to design and maintain large complex software systems. However, it does not seem to have meet the high expectations concerning reuse and ease of evolution which have been pro- moted ever since its commercial success. There are many potential reasons for the above observation such as unquali- fied staff, immature languages, inadequate methodologies, inappropriate business processes, etc. The view presented here is that although the object-oriented paradigm is a pow- erful basis, it is incomplete in its inherent concepts and therefore restricts the design space to inappropriate solutions. It is assumed that both software development and language design are restrained from achieving their full potential when restricted to a purely object-oriented world view. Solution Since the complementary paradigm to object-orientation is represented by func- tional programming, I investigate high-level, well-known to work functional con- cepts and examine their suitability to enhance object-oriented design. I explore the software engineering relevance of each concept and present its intent, applicability, implementation, and consequences in the literate form of a design pattern. My approach clearly motivates functional techniques for object-oriented design from a software engineering point of view. This is different to the usual procedure of designing a new language with an “ad-hoc” conglomeration of functional and object-oriented features. The latter case requires excellence in language design and makes it hard to find out and evaluate uses of the new language. In contrast, design patterns are already widely used to improve design. As func- tional concepts constitute a powerful paradigm by themselves, it is more than sug- gestive to assume that design patterns expressing successful functional concepts will enhance the object-oriented paradigm with new capabilities. iv Thesis Contribution Feasibility I demonstrate the feasibility of using functional techniques in object-oriented de- signs which are to be implemented by ordinary object-oriented programming lan- guages. This is done at the level of a calculus comparison and in concrete design pattern implementation descriptions. I demonstrate synergetic effects caused by concept integration, which together with the advantages of functional patterns, thus, show the utility of the approach. Software production Object-oriented practitioners hopefully will use the names of functional design pat- terns as a vocabulary to discuss solutions in a new design space. I present a system of patterns which are connected by relations that describe how individual patterns may interact and collaborate with each other. This system, consisting of state-of- the-art mini-architectures, may allow thinking and designing beyond restrictions imposed by a dogmatic object-oriented approach. As a result, the quality of soft- ware is hoped to improve. Language Design Using functional patterns for object-oriented design can be regarded as dual- paradigm design. In this light, functional design patterns appear as language id- ioms that lift an object-oriented language to a dual paradigm implementation lan- guage. It is very instructive to verify how well an object-oriented language supports the implementation of these idioms, since limiting properties are expected to interfere in other attempts to produce flexible and maintainable software as well. Unless one is restricted to use a certain existing language, it is, however, only natural to consider direct language support in order to avoid the repetitive im- plementation of these idioms. A holistic language that encompasses both object- oriented and functional paradigms should provide more ease of use, increased safety, better initial execution efficiency, and higher optimization potential. I consider each presented design pattern for its contribution to language con- structs that support a dual paradigm language. The software engineering consid- erations, contained in each design pattern description, help to avoid “featurism” in favor of conceptually founded language principles. Ultimately, impulses initiated by the functional pattern system lead to a reeval- uation of the role distribution between a programming language and its associated environment. The result allows transcending the limitations of each paradigm by providing the optimal paradigm view on demand. Preface v Preface Example is the school of mankind, and they will learn at no other. – Edmund Burke A number of people directly or indirectly influenced my work and I am grateful for their contributions. Norbert Ihrig made my early years in school a worthwhile experience and with- out him my way would have been much harder. Gregor Snelting proposed an interesting master thesis to me and, thus, opened up the subsequent opportunity for a research position at the institute for “Praktis- che Informatik” at the Darmstadt University of Technology. I enjoyed his lectures and am thankful for his continued support. Thilo Kielman introduced me to the world of being a scientist. I owe him many hints, paper reviews, and enjoyable hours. Alberto Pardo was my roommate over a long period and shared many stimulat- ing discussions with me. I would like to express my gratitude for his ever present willingness to help and for a lot of advice in the areas of calculi and algebras. He and Nick Dyson helped to improve the chapter on functional programming. John Sargeant invested considerable effort to discuss the Void Value pattern with me and provided useful information on UFO. Dirk Koschorek provided invaluable last minute advice on SMALLTALK. Many scientists, who I had the honor to meet at workshops or conferences, dis- cussed aspects of my work with me and made me reflect about it. Gillian L. Lovegrove and Jurgen ¨ Ebert accepted to be external examiners and I am indebted to their timely efforts. I would like to thank Jurgen ¨ Ebert for his invitation to the “Bad Honnef” workshop series and for his personal interest in my work. Finally, I would like to express my gratitude to my thesis supervisor Wolfgang Henhapl. He gave me all the freedom I could wish for and stimulated my work on several occasions. He asked the question to which function objects present an an- swer and challenged me to conceive the Translator design. Numerous discussions with him created an abundance of insights for me. I am honestly grateful to the nameless cosmic particles that hit me when I had the idea of function objects, to replace Nil with a type specific value, to solve the forces of internal and external iteration with multiple consumable intermediate streams, to express functional ideas by devising a pattern system, and to rethink the roles of languages and their environments based on the notion of tiles. vi Preface Many thanks to Cordon Art for granting permission to use the images by M.C. Escher “Circle Limit IV”, “Space Filling”, and “Day and Night”. 1998, Cordon Art B.V., Nieuwstraat 6, P.O.Box 101, 3740 AC Baarn, Holland. Last but not least, my appreciation goes to to Donald E. Knuth who developed TEX and put it into the public domain, Frank Mittelbach for LATEX2ε, Linus Torvald for LINUX, and all their companions and successors who enabled me to produce this document with copylefted software only. Contents vii Contents Thesis iii Preface v Prologue 1 I Foundation 7 1 Functional programming 9 1.1 Worldview ................................. 9 1.2 Concepts . ................................. 10 1.2.1 Functional decomposition . ................... 10 1.2.2 Reduction Semantics . ................... 11 1.2.3 Higher-Order Functions . ................... 12 1.2.4 Lazy evaluation .......................... 14 1.2.5 Pattern Matching . ................... 16 1.2.6 Type inference . .......................... 17 1.3 Review . ................................. 17 1.3.1 Pro ................................. 17 1.3.1.1 Programming Discipline . ............ 18 1.3.1.2 Concise programs ................... 18 1.3.2 Contra . .......................... 21 1.3.2.1 Functional decomposition . ............ 21 1.3.2.2 Reduction semantics . ............ 21 1.3.2.3 Deceptive Clearness . ............ 26 2 Object-orientation 29 2.1 Worldview ................................. 29 2.2 Concepts . ................................. 31 2.2.1 Object-oriented decomposition . ............ 32 2.2.2 Encapsulation . .......................... 32 2.2.3 Inheritance . .......................... 33 2.2.4 Subtyping . .......................... 34 2.2.5 Dynamic Binding . ................... 35 viii Contents 2.2.6 Identity . .......................... 37 2.3 Review . ................................. 38 2.3.1 Pro ................................
Load more

Recommended publications
  • Ece351 Lab Manual
    DEREK RAYSIDE & ECE351 STAFF ECE351 LAB MANUAL UNIVERSITYOFWATERLOO 2 derek rayside & ece351 staff Copyright © 2014 Derek Rayside & ECE351 Staff Compiled March 6, 2014 acknowledgements: • Prof Paul Ward suggested that we look into something with vhdl to have synergy with ece327. • Prof Mark Aagaard, as the ece327 instructor, consulted throughout the development of this material. • Prof Patrick Lam generously shared his material from the last offering of ece251. • Zhengfang (Alex) Duanmu & Lingyun (Luke) Li [1b Elec] wrote solutions to most labs in txl. • Jiantong (David) Gao & Rui (Ray) Kong [3b Comp] wrote solutions to the vhdl labs in antlr. • Aman Muthrej and Atulan Zaman [3a Comp] wrote solutions to the vhdl labs in Parboiled. • TA’s Jon Eyolfson, Vajih Montaghami, Alireza Mortezaei, Wenzhu Man, and Mohammed Hassan. • TA Wallace Wu developed the vhdl labs. • High school students Brian Engio and Tianyu Guo drew a number of diagrams for this manual, wrote Javadoc comments for the code, and provided helpful comments on the manual. Licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) version 2.5 or greater. http://creativecommons.org/licenses/by-sa/2.5/ca/ http://creativecommons.org/licenses/by-sa/3.0/ Contents 0 Overview 9 Compiler Concepts: call stack, heap 0.1 How the Labs Fit Together . 9 Programming Concepts: version control, push, pull, merge, SSH keys, IDE, 0.2 Learning Progressions . 11 debugger, objects, pointers 0.3 How this project compares to CS241, the text book, etc. 13 0.4 Student work load . 14 0.5 How this course compares to MIT 6.035 .......... 15 0.6 Where do I learn more? .
    [Show full text]
  • 1. Domain Modeling
    Software design pattern seminar sse, ustc Topic 8 Observer, Mediator, Facade Group K 1. The observer pattern (Behavioral pattern, chapter 16 and 17) 1) the observer is an interface or abstract class defining the operations to be used to update itself 2) a solution to these problems A. Decouple change and related responses so that such dependencies can be added or removed freely and dynamically 3) solution A. Observable defines the operations for attaching, de-attaching and notifying observers B. Observer defines the operations to update itself 4) liabilities A. Unwanted concurrent update to a concrete observable may occur Figure 1 Sample Observer Pattern 2. The mediator pattern (Behavioral pattern, chapter 16 and 17) 1) the mediator encapsulates how a set of objects interact and keeps objects from referring to each other explicitly 2) a solution to these problems A. a set of objects communicate in well-defined but complex ways. The resulting interdependencies are unstructured and difficult to understand B. reusing an object is difficult because it refers to and communicates with many other objects C. a behavior that's distributed between several classes should be customizable without a lot of subclassing 3) solution A. Mediator defines an interface for communicating with Colleague objects, knows the colleague classes and keep a reference to the colleague objects, and implements the communication and transfer the messages between the colleague classes 1 Software design pattern seminar sse, ustc B. Colleague classes keep a reference to its Mediator object, and communicates with the Mediator whenever it would have otherwise communicated with another Colleague 4) liabilities A.
    [Show full text]
  • Automatic Verification of Java Design Patterns
    Automatic Verification of Java Design Patterns Alex Blewitt, Alan Bundy, Ian Stark Division of Informatics, University of Edinburgh 80 South Bridge, Edinburgh EH1 1HN, UK [email protected] [email protected] [email protected] Abstract 2. Design patterns There are a number of books which catalogue and de- Design patterns are widely used by object oriented de- scribe design patterns [4, 1, 6] including an informal de- signers and developers for building complex systems in ob- scription of the key features and examples of their use. ject oriented programming languages such as Java. How- However, at the moment there are no books which attempt ever, systems evolve over time, increasing the chance that to formalise these descriptions, possibly for the following the pattern in its original form will be broken. reasons: We attempt to show that many patterns (implemented in Java) can be verified automatically. Patterns are defined 1. The implementation (and description) of the pattern is in terms of variants, mini-patterns, and constraints in a language-specific. pattern description language called SPINE. These specifi- 2. There are often several ways to implement a pattern cations are then processed by HEDGEHOG, an automated within the same language. proof tool that attempts to prove that Java source code 3. Formal language descriptions are not common within meets these specifications. the object oriented development community. Instead, each pattern is presented as a brief description, and an example of its implementation and use. Designers and developers are then expected to learn the ‘feel’ of a pat- 1.
    [Show full text]
  • The Command Dispatcher Pattern Benoit Dupire and Eduardo B Fernandez {[email protected], [email protected]}
    The Command Dispatcher Pattern Benoit Dupire and Eduardo B Fernandez {[email protected], [email protected]} Department of Computer Science and Engineering. Florida Atlantic University Boca Raton, FL 33431 Can also be called: Command Evaluator Pattern. Intent This pattern increases the flexibility of applications by enabling their services to be changed, by adding, replacing or removing any command handlers at any point in time without having to modify, recompile or statically relink the application. By simulating the command-evaluation feature common in interpreted languages, this pattern supports the need for continual, incremental evolution of applications. Example Autonomous Underwater Vehicles (AUVs) are small, unmanned, untethered submersibles. There are numerous applications for AUVs, such as oceanographic surveys, operations in hazardous environments, underwater structure inspection and military operations. We implement the high level controller of this AUV as a Hierarchical Finite State Machine (Figure 1). A state of the Finite State Machine (FSM) represents a mode of the system, in which some tasks have to be executed, as described in the mission plan. The system takes transitions based on the results of these actions and the progression of the AUV. The system is programmed with high-level commands of the style "set depth 3" state1 state2 action 1.1 action 2.1 Figure 1: Simplified Finite State Machine for the AUV. The FSM must be able to fire any type of actions, without knowing anything about them. This problem is addressed by the Command Pattern [GOF95], which encapsulates an action as an object, thereby letting you parameterize clients with different actions.
    [Show full text]
  • Design Case Study: Java Swing
    Principles of Software Construction: Objects, Design, and Concurrency Part 2: Design case studies Design case study: Java Swing Charlie Garrod Chris Timperley 17-214 1 Administrivia • Reading due today: UML and Patterns 26.1 and 26.4 • Homework 4b due Thursday, October 17th https://commons.wikimedia.org/wiki/File:1_carcassonne_aerial_2016.jpg 17-214 2 Key concepts from Thursday • Observer design pattern • Introduction to concurrency – Not enough synchronization: safety failure – Too much synchronization: liveness failure • Event-based programming • Introduction to GUIs 17-214 3 GUI programming is inherently multi-threaded • Swing event dispatch thread (EDT) handles all GUI events – Mouse events, keyboard events, timer events, etc. • No other time-consuming activity allowed on the EDT – Violating this rule can cause liveness failures 17-214 4 Swing has many event listener interfaces • ActionListener • MouseListener • AdjustmentListener • TreeExpansionListener • FocusListener • TextListener • ItemListener • WindowListener • KeyListener • … class ActionEvent { int when; String actionCommand; int modifiers; Object source(); int id; … interface ActionListener { } void actionPerformed(ActionEvent e); } 17-214 5 Aside: lambdas vs. explicit class declarations? //static public void main… JFrame window = … JPanel panel = new JPanel(); window.setContentPane(panel); panel to hold the button JButton button = new JButton(“Click me”); button.addActionListener(new ActionListener() { public void actionPerformed(ActionEvent e) { System.out.println(“Button
    [Show full text]
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Reversible Programming with Negative and Fractional Types
    9 A Computational Interpretation of Compact Closed Categories: Reversible Programming with Negative and Fractional Types CHAO-HONG CHEN, Indiana University, USA AMR SABRY, Indiana University, USA Compact closed categories include objects representing higher-order functions and are well-established as models of linear logic, concurrency, and quantum computing. We show that it is possible to construct such compact closed categories for conventional sum and product types by defining a dual to sum types, a negative type, and a dual to product types, a fractional type. Inspired by the categorical semantics, we define a sound operational semantics for negative and fractional types in which a negative type represents a computational effect that “reverses execution flow” and a fractional type represents a computational effect that“garbage collects” particular values or throws exceptions. Specifically, we extend a first-order reversible language of type isomorphisms with negative and fractional types, specify an operational semantics for each extension, and prove that each extension forms a compact closed category. We furthermore show that both operational semantics can be merged using the standard combination of backtracking and exceptions resulting in a smooth interoperability of negative and fractional types. We illustrate the expressiveness of this combination by writing a reversible SAT solver that uses back- tracking search along freshly allocated and de-allocated locations. The operational semantics, most of its meta-theoretic properties, and all examples are formalized in a supplementary Agda package. CCS Concepts: • Theory of computation → Type theory; Abstract machines; Operational semantics. Additional Key Words and Phrases: Abstract Machines, Duality of Computation, Higher-Order Reversible Programming, Termination Proofs, Type Isomorphisms ACM Reference Format: Chao-Hong Chen and Amr Sabry.
    [Show full text]
  • Addison Wesley, 2000, Pp
    ------==Proudly Presented by MODELER==------ preface.fm Page xv Wednesday, June 6, 2001 4:18 PM Preface Design patterns and object-oriented programming. They hold such promise to make your life as a software designer and developer eas- ier. Their terminology is bandied about every day in the technical and even the popular press. But it can be hard to learn them, to become proficient with them, to understand what is really going on. Perhaps you have been using an object-oriented or object-based language for years. Have you learned that the true power of objects is not inheritance but is in “encapsulating behaviors”? Perhaps you are curious about design patterns and have found the literature a bit too esoteric and high-falutin. If so, this book is for you. It is based on years of teaching this material to software developers, both experienced and new to object orientation. It is based upon the belief—and our experience—that once you understand the basic principles and motivations that underlie these concepts, why they are doing what they do, your learning curve will be incredibly shorter. And in our discussion of design patterns, you will under- stand the true mindset of object orientation, which is a necessity before you can become proficient. As you read this book, you will gain a solid understanding of the ten most essential design patterns. You will learn that design pat- terns do not exist on their own, but are supposed to work in con- cert with other design patterns to help you create more robust applications.
    [Show full text]
  • Enterprise Development with Flex
    Enterprise Development with Flex Enterprise Development with Flex Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Enterprise Development with Flex by Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Copyright © 2010 Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary E. Treseler Indexer: Ellen Troutman Development Editor: Linda Laflamme Cover Designer: Karen Montgomery Production Editor: Adam Zaremba Interior Designer: David Futato Copyeditor: Nancy Kotary Illustrator: Robert Romano Proofreader: Sada Preisch Printing History: March 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Enterprise Development with Flex, the image of red-crested wood-quails, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein.
    [Show full text]
  • A Mathematical Approach to Object Oriented Design Patterns
    06.2006 J.Natn.Sci.FoundationObject oriented design Sripatterns Lanka 2008 36 (3):219-227 219 RESEARCH ARTICLE A mathematical approach to object oriented design patterns Saluka R. Kodituwakku1*and Peter Bertok2 1 Department of Statistics and Computer Science, Faculty of Science, University of Peradeniya, Peradeniya. 2 Department of Computer Science, RMIT University, Melbourne, Australia. Revised: 27 May 2008 ; Accepted: 18 July 2008 Abstract: Although design patterns are reusable design the distribution of responsibilities. For ease of learning elements, existing pattern descriptions focus on specific and reference, in1, design patterns are organized into a solutions that are not easily reusable in new designs. This paper catalogue. introduces a new pattern description method for object oriented design patterns. The description method aims at providing a The catalogue is formed by two criteria: purpose more general description of patterns so that patterns can be and scope. According to their purpose, design patterns readily reusable. This method also helps a programmer to are classified into creational, structural and behavioural, analyze, compare patterns, and detect patterns from existing software programmes. whereas the scope divides patterns into class patterns and object patterns. Class patterns capture relationships This method differs from the existing pattern description between classes and their subclasses; object patterns deal methods in that it captures both static and dynamic properties with relationships between objects. of patterns. It describes them in terms of mathematical entities rather than natural language narratives, incomplete graphical Software patterns provide reusable solutions to notations or programme fragments. It also helps users to recurring design problems. Even if we have reusable understand the patterns and relationships between them; and solutions they may not be effectively reused, because select appropriate patterns to the problem at hand.
    [Show full text]
  • Lecture 1 for Chapter 8, Object Design: Reusing Pattern Solutions
    Object-Oriented Software Engineering Using UML, Patterns, and Java Chapter 8, Object Design: 8, Object Chapter Reuse and Patterns I and Patterns Reuse Object Design Object design is the process of adding details to the requirements analysis and making implementation decisions The object designer must choose among different ways to implement the analysis model with the goal to minimize execution time, memory and other measures of cost Requirements Analysis: Use cases, functional and dynamic model deliver operations for object model Object Design: Iterates on the models, in particular the object model and refine the models Object Design serves as the basis of implementation System Development as a Set of Activities System Problem Application objects Analysis Solution objects Design Custom objects - Object Design Off-the-Shelf Components - System Design Existing Machine Examples of Object Design Activities Identification of existing components Full definition of associations Full definition of classes (System Design => Service, Object Design => Subsystem interfaces/API) Choosing algorithms and data structures Identifying possibilities of reuse Detection of solution-domain classes Optimization Increase of inheritance Decision on control …… A More Detailed View of Object Design Activities Select Subsystem Specification Reuse Identifying missing Identifying components attributes & operations Specifying visibility Adjusting components Specifying types & signatures Identifying patterns Specifying constraints Specifying exceptions
    [Show full text]
  • The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools
    The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools Andreas Harrer, Catholic University Eichstatt-Ingolstadt,¨ Germany, Niels Pinkwart, Clausthal University of Technology, Germany, Bruce M. McLaren, Carnegie Mellon University, Pittsburgh PA, U.S.A., and DFKI, Saarbrucken,¨ Germany, and Oliver Scheuer, DFKI, Saarbrucken,¨ Germany Abstract For many practical learning scenarios, the integrated use of more than one learning tool is educationally beneficial. In these cases, interoperability between learning tools - getting the pieces to talk to one another in a coherent, well-founded manner - is a crucial requirement that is often hard to achieve. This paper describes a re-usable software design that aims at the integration of independent learning tools into one collaborative learning scenario. We motivate the usefulness and expressiveness of combining several learning tools into one integrated learning experience. Based on this we sketch software design principles that integrate several existing components into a joint technical framework. The feasibility of the approach, which we name the “Scalable Adapter” design pattern, is shown with several implementation examples from different educational technology domains, including Intelligent Tutoring Systems and collaborative learning environments. IEEE keywords: J.m Computer applications, H.5.3 Group and Organization interfaces, K.3.m Computers in Education A short version of this paper appeared in the Proceedings of the Conference on Intelligent Tutoring Systems 2008 1 The Scalable Adapter Design Pattern: Enabling Interoperability Between Educational Software Tools1 I. INTRODUCTION hypothesis and plans. In order to help the student or student In the field of educational technology, there have been groups during the different steps of this inquiry procedure, it numerous attempts in recent years to connect differently makes sense to enable them to have hypotheses, experimenta- targeted learning environments to one another.
    [Show full text]