DOCSLIB.ORG

PDF (Dissertation.Pdf)

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Kind Theory Thesis by Joseph R. Kiniry In Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy California Institute of Technology Pasadena, California 2002 (Defended 10 May 2002) ii © 2002 Joseph R. Kiniry All Rights Reserved iii Preface This thesis describes a theory for representing, manipulating, and reasoning about structured pieces of knowledge in open collaborative systems. The theory's design is motivated by both its general model as well as its target user commu- nity. Its model is structured information, with emphasis on classification, relative structure, equivalence, and interpretation. Its user community is meant to be non-mathematicians and non-computer scientists that might use the theory via computational tool support once inte- grated with modern design and development tools. This thesis discusses a new logic called kind theory that meets these challenges. The core of the work is based in logic, type theory, and universal algebras. The theory is shown to be efficiently implementable, and several parts of a full realization have already been constructed and are reviewed. Additionally, several software engineering concepts, tools, and technologies have been con- structed that take advantage of this theoretical framework. These constructs are discussed as well, from the perspectives of general software engineering and applied formal methods. iv Acknowledgements I am grateful to my initial primary adviser, Prof. K. Mani Chandy, for bringing me to Caltech and his willingness to let me explore many unfamiliar research fields of my own choosing. I am also appreciative of my second adviser, Prof. Jason Hickey, for his support, encouragement, feedback, and patience through the later years of my work. If Jason had not appeared at Caltech in Autumn of 1999, I may well have not finished my Ph.D. I am very much in debt to Joseph Goguen whose inspiring work started me on the path of using algebras and categories. José Meseguer and Francisco (Paco) Duran have been of tremendous help and inspiration in my use of Maude and rewriting logic. Thanks also go to fellow graduate students and research group members Daniel Zimmer- man, Eve Schooler, Michel Charpentier, Roman Ginis, Paolo Sivilotti, John Thornley, and Berna Massingill, and Adam Rifkin—the original reason for my coming to Caltech. I am one that would loose my head if it wasn't screwed on at times, so administrative assistance is appreciated. To that end, I am in debt to Diane Goodfellow and Jeri Chittum, two of the key folks that keep Caltech Computer Science running. I am most grateful to the Caltech Computer Science community for providing such an open, stimulating, and quality environment in which to do “way-out” work. Influential members of my community are, besides those fellow students mentioned above: Eric Bax, Eitan Grinspun, Rajit Manohar, Alexander Nicholson, Mika Nyström, Steven Schkolne, and Zoë Wood. Life is not complete without friends, and I am lucky enough to have too many to list. Of particular importance over these past five years are Chara Williams and Mary Baxter. A large cadre of best friends, most nonlocal, have kept me sane, healthy, and high-spirited over the years: John Greene, Dara Thompson, Amy Wilkinson, Cici Koenig, Cynthia Fay, Patricia Wong, Robert Pastor, Robert Stacy, and the BoDO gang: Mark Baker, Nelson Minar, and last but not least, Ron Resnick. Academic encouragement came from many fronts. First and foremost I thank Doug Lea for his subtle background influence in furthering my academic career—you are my invisible adviser. I also thank my various academic advisers over the years: Gregory Riccardi, David Kopriva, Steven Leach, and Charles Weems. Thanks also go to John Thornley for providing v remote encouragement when I needed it most and Eric Klavins for filling in as a last-second committee member. Several teachers, instructors, and professors have had an enormous impact on me over the years. I think this is unavoidable for someone who has lived through five degrees, three uni- versities, and numerous research stints at various places. I'd like to acknowledge the following individuals, some of whom might remember me with a smile, and others with a cringe. From Ft. Myers High School: Janet Marderness, Bruce Conover, and Barbara Kepler. From Florida State University: Theodore Baker, Paolo Aluffi, Steven Bellenot, Jim Gaunt, Robert Gilmer, Sam Huckaba, David Loper, Joe Mott, Daniel Oberlin, and Euliquio Young. From the University of Massachusetts at Amherst: James Kurose, Eliot Moss, Jack Wileden, Steven Cook, and Teresa Kellogg. From the Open Software Foundation: John Bowe, Murray Mazer, Ira Goldstein, and Ron Rebeiro. Finally, I'd like to thank my family for all of their support, encouragement, faith, and love. vi Abstract My contribution, described in this thesis, is a theory that is meant to assist in the construction of complex software systems. I propose a notion of structure that is independent of language, formalism, or problem domain. I call this new abstraction a kind, and its related formal system, kind theory. I define a type system that models the structural aspects of kind theory. I also define an algebra that models this type system and provides a logic in which one can specify and execute computations. A reflective definition of kind theory is reviewed. This reflective specification depends upon a basic ontology for mathematics. By specifying the theory in itself, I provide an example of how one can use kind theory to reason about reuse in general formal systems. I provide examples of the use of kind theory in reasoning about software constructs in several domains of software engineering. I also discuss a set of software tools that I have constructed that realize or use kind theory. A logical framework is used to specify a type theoretic and algebraic model for the theory. Using this basic theorem prover one can reason about software systems using kind theory. Also, I have constructed a reuse repository that supports online collaboration, houses software assets, helps search for components that match specifications, and more. This repository is designed to use kind theory (via the logical framework) for the representation of, and reasoning about, software assets. Finally, I propose a set of language-independent specification constructs called semantic properties which have a semantics specified in kind theory. I show several uses of these con- structs, all of which center on reasoning about reusable component-based software, by giving examples of how these constructs are applied to programming and specification languages. I discuss how the availability of these constructs and the associated theory impact the software development process. vii Notation Nearly all mathematical presentation constructs (e.g., theorems, axioms, etc.) are independently numbered. The only exception is corollaries which are numbered according to their associated theorem. Proofs are denoted by a leading Proof. or Proof of Theorem Title and are ended by a box. Logical rules are written in the standard style: Modus Ponens (MP) U U ) V V A rule named with an asterisk is reversible and summarizes two rules. Variables in rules are written in the default font if they represent arbitrary free entities. The basic Boolean values of true and false are denoted as > and ? respectively. The set of Boolean values is denoted by the symbol 2 = f>; ?g. We denote a ternary truth value of unknown with the symbol ?. The set of ternary truth values is specified by the symbol 3 = f>; ?; ?g. Arbitrary sets are written as A; B; C; : : : in italics. Algebraic sorts are written in the typeface Boolean; Int; Float; : : : and types are written in the typeface Boolean; Integer; Float; : : :. Models are written in calligraphic font M; N; O; : : :. Kinds are written as Poset; Universal; List; : : : and instances use the standard font I; J; : : :. Functions are named with lowercase roman and Greek letters or basic symbols as in f ; γ; : : :; choice of symbol will be made clear in the presentation. Functions are written inline in the <p typical fashions: <p: Kind ! Kind or, occasionally, Kind ! Kind. The identity function on an object X is idX : X ! X, or id : X ! X. Composition of functions f : X ! Y and g : Y ! Z is written g· f . viii Contents Acknowledgements iv Abstract vi List of Figures xix List of Tables xxi 1 Introduction 1 1.1 Motivation . 1 1.2 Aspects of Software . 2 1.2.1 Core Notions Derived from Software . 2 1.2.2 Subjectivity in Software . 3 1.2.3 Aspects of Information . 4 1.3 Related Work . 5 1.3.1 General Classification Theories . 5 1.3.2 Knowledge Theories . 6 1.3.2.1 Conceptual Spaces . 7 1.3.3 General Theoretical Foundations . 7 1.3.3.1 Category Theory . 7 1.3.3.2 Model Theory . 8 1.3.3.3 Paraconsistent and Other Deviant Logics . 8 1.3.4 Knowledge Representation . 10 1.3.5 Software Reuse . 10 1.3.5.1 Reuse Models . 10 1.3.5.2 Reuse Theories . 11 1.3.5.3 Reuse Technologies . 11 1.3.5.4 Asset Repositories . 12 1.3.6 Formal Methods . 13 1.3.7 Components and Composition . 14 ix 1.3.7.1 Concepts to Drive New Kinds . 14 1.3.7.2 Semantic Composition . 15 1.3.8 Knowledgeable Software Environments . 16 1.4 Contributions . 16 1.4.1 Theoretical . 16 1.4.2 Analysis of Existing Software Engineering Constructs . 17 1.4.3 Definition of New Constructs . 17 1.4.4 Tools . 18 1.4.5 Summary . 18 1.5 Overview . 18 1.5.1 A Classification of Kind Theory . 19 1.5.2 Theoretical Models . 19 1.5.3 Practical Models . 20 1.5.4 Systems . 21 1.6 Thesis Structure .
Recommended publications
  • Metaobject Protocols: Why We Want Them and What Else They Can Do

    Metaobject Protocols: Why We Want Them and What Else They Can Do

    Metaobject protocols: Why we want them and what else they can do Gregor Kiczales, J.Michael Ashley, Luis Rodriguez, Amin Vahdat, and Daniel G. Bobrow Published in A. Paepcke, editor, Object-Oriented Programming: The CLOS Perspective, pages 101 ¾ 118. The MIT Press, Cambridge, MA, 1993. © Massachusetts Institute of Technology All rights reserved. No part of this book may be reproduced in any form by any electronic or mechanical means (including photocopying, recording, or information storage and retrieval) without permission in writing from the publisher. Metaob ject Proto cols WhyWeWant Them and What Else They Can Do App ears in Object OrientedProgramming: The CLOS Perspective c Copyright 1993 MIT Press Gregor Kiczales, J. Michael Ashley, Luis Ro driguez, Amin Vahdat and Daniel G. Bobrow Original ly conceivedasaneat idea that could help solve problems in the design and implementation of CLOS, the metaobject protocol framework now appears to have applicability to a wide range of problems that come up in high-level languages. This chapter sketches this wider potential, by drawing an analogy to ordinary language design, by presenting some early design principles, and by presenting an overview of three new metaobject protcols we have designed that, respectively, control the semantics of Scheme, the compilation of Scheme, and the static paral lelization of Scheme programs. Intro duction The CLOS Metaob ject Proto col MOP was motivated by the tension b etween, what at the time, seemed liketwo con icting desires. The rst was to have a relatively small but p owerful language for doing ob ject-oriented programming in Lisp. The second was to satisfy what seemed to b e a large numb er of user demands, including: compatibility with previous languages, p erformance compara- ble to or b etter than previous implementations and extensibility to allow further exp erimentation with ob ject-oriented concepts see Chapter 2 for examples of directions in which ob ject-oriented techniques might b e pushed.
  • Chapter 2 Basics of Scanning And

    Chapter 2 Basics of Scanning And

    Chapter 2 Basics of Scanning and Conventional Programming in Java In this chapter, we will introduce you to an initial set of Java features, the equivalent of which you should have seen in your CS-1 class; the separation of problem, representation, algorithm and program – four concepts you have probably seen in your CS-1 class; style rules with which you are probably familiar, and scanning - a general class of problems we see in both computer science and other fields. Each chapter is associated with an animating recorded PowerPoint presentation and a YouTube video created from the presentation. It is meant to be a transcript of the associated presentation that contains little graphics and thus can be read even on a small device. You should refer to the associated material if you feel the need for a different instruction medium. Also associated with each chapter is hyperlinked code examples presented here. References to previously presented code modules are links that can be traversed to remind you of the details. The resources for this chapter are: PowerPoint Presentation YouTube Video Code Examples Algorithms and Representation Four concepts we explicitly or implicitly encounter while programming are problems, representations, algorithms and programs. Programs, of course, are instructions executed by the computer. Problems are what we try to solve when we write programs. Usually we do not go directly from problems to programs. Two intermediate steps are creating algorithms and identifying representations. Algorithms are sequences of steps to solve problems. So are programs. Thus, all programs are algorithms but the reverse is not true.
  • Journal of Applied Logic

    Journal of Applied Logic

    JOURNAL OF APPLIED LOGIC AUTHOR INFORMATION PACK TABLE OF CONTENTS XXX . • Description p.1 • Impact Factor p.1 • Abstracting and Indexing p.1 • Editorial Board p.1 • Guide for Authors p.5 ISSN: 1570-8683 DESCRIPTION . This journal welcomes papers in the areas of logic which can be applied in other disciplines as well as application papers in those disciplines, the unifying theme being logics arising from modelling the human agent. For a list of areas covered see the Editorial Board. The editors keep close contact with the various application areas, with The International Federation of Compuational Logic and with the book series Studies in Logic and Practical Reasoning. Benefits to authors We also provide many author benefits, such as free PDFs, a liberal copyright policy, special discounts on Elsevier publications and much more. Please click here for more information on our author services. Please see our Guide for Authors for information on article submission. This journal has an Open Archive. All published items, including research articles, have unrestricted access and will remain permanently free to read and download 48 months after publication. All papers in the Archive are subject to Elsevier's user license. If you require any further information or help, please visit our Support Center IMPACT FACTOR . 2016: 0.838 © Clarivate Analytics Journal Citation Reports 2017 ABSTRACTING AND INDEXING . Zentralblatt MATH Scopus EDITORIAL BOARD . Executive Editors Dov M. Gabbay, King's College London, London, UK Sarit Kraus, Bar-llan University,
  • Lecture 2: Variables and Primitive Data Types

    Lecture 2: Variables and Primitive Data Types

    Lecture 2: Variables and Primitive Data Types MIT-AITI Kenya 2005 1 In this lecture, you will learn… • What a variable is – Types of variables – Naming of variables – Variable assignment • What a primitive data type is • Other data types (ex. String) MIT-Africa Internet Technology Initiative 2 ©2005 What is a Variable? • In basic algebra, variables are symbols that can represent values in formulas. • For example the variable x in the formula f(x)=x2+2 can represent any number value. • Similarly, variables in computer program are symbols for arbitrary data. MIT-Africa Internet Technology Initiative 3 ©2005 A Variable Analogy • Think of variables as an empty box that you can put values in. • We can label the box with a name like “Box X” and re-use it many times. • Can perform tasks on the box without caring about what’s inside: – “Move Box X to Shelf A” – “Put item Z in box” – “Open Box X” – “Remove contents from Box X” MIT-Africa Internet Technology Initiative 4 ©2005 Variables Types in Java • Variables in Java have a type. • The type defines what kinds of values a variable is allowed to store. • Think of a variable’s type as the size or shape of the empty box. • The variable x in f(x)=x2+2 is implicitly a number. • If x is a symbol representing the word “Fish”, the formula doesn’t make sense. MIT-Africa Internet Technology Initiative 5 ©2005 Java Types • Integer Types: – int: Most numbers you’ll deal with. – long: Big integers; science, finance, computing. – short: Small integers.
  • All That Math Portraits of Mathematicians As Young Researchers

    All That Math Portraits of Mathematicians As Young Researchers

    Downloaded from orbit.dtu.dk on: Oct 06, 2021 All that Math Portraits of mathematicians as young researchers Hansen, Vagn Lundsgaard Published in: EMS Newsletter Publication date: 2012 Document Version Publisher's PDF, also known as Version of record Link back to DTU Orbit Citation (APA): Hansen, V. L. (2012). All that Math: Portraits of mathematicians as young researchers. EMS Newsletter, (85), 61-62. General rights Copyright and moral rights for the publications made accessible in the public portal are retained by the authors and/or other copyright owners and it is a condition of accessing publications that users recognise and abide by the legal requirements associated with these rights. Users may download and print one copy of any publication from the public portal for the purpose of private study or research. You may not further distribute the material or use it for any profit-making activity or commercial gain You may freely distribute the URL identifying the publication in the public portal If you believe that this document breaches copyright please contact us providing details, and we will remove access to the work immediately and investigate your claim. NEWSLETTER OF THE EUROPEAN MATHEMATICAL SOCIETY Editorial Obituary Feature Interview 6ecm Marco Brunella Alan Turing’s Centenary Endre Szemerédi p. 4 p. 29 p. 32 p. 39 September 2012 Issue 85 ISSN 1027-488X S E European M M Mathematical E S Society Applied Mathematics Journals from Cambridge journals.cambridge.org/pem journals.cambridge.org/ejm journals.cambridge.org/psp journals.cambridge.org/flm journals.cambridge.org/anz journals.cambridge.org/pes journals.cambridge.org/prm journals.cambridge.org/anu journals.cambridge.org/mtk Receive a free trial to the latest issue of each of our mathematics journals at journals.cambridge.org/maths Cambridge Press Applied Maths Advert_AW.indd 1 30/07/2012 12:11 Contents Editorial Team Editors-in-Chief Jorge Buescu (2009–2012) European (Book Reviews) Vicente Muñoz (2005–2012) Dep.
  • Stephen Cole Kleene

    Stephen Cole Kleene

    STEPHEN COLE KLEENE American mathematician and logician Stephen Cole Kleene (January 5, 1909 – January 25, 1994) helped lay the foundations for modern computer science. In the 1930s, he and Alonzo Church, developed the lambda calculus, considered to be the mathematical basis for programming language. It was an effort to express all computable functions in a language with a simple syntax and few grammatical restrictions. Kleene was born in Hartford, Connecticut, but his real home was at his paternal grandfather’s farm in Maine. After graduating summa cum laude from Amherst (1930), Kleene went to Princeton University where he received his PhD in 1934. His thesis, A Theory of Positive Integers in Formal Logic, was supervised by Church. Kleene joined the faculty of the University of Wisconsin in 1935. During the next several years he spent time at the Institute for Advanced Study, taught at Amherst College and served in the U.S. Navy, attaining the rank of Lieutenant Commander. In 1946, he returned to Wisconsin, where he stayed until his retirement in 1979. In 1964 he was named the Cyrus C. MacDuffee professor of mathematics. Kleene was one of the pioneers of 20th century mathematics. His research was devoted to the theory of algorithms and recursive functions (that is, functions defined in a finite sequence of combinatorial steps). Together with Church, Kurt Gödel, Alan Turing, and others, Kleene developed the branch of mathematical logic known as recursion theory, which helped provide the foundations of theoretical computer science. The Kleene Star, Kleene recursion theorem and the Ascending Kleene Chain are named for him.
  • Fashion Designers' Decision-Making Process

    Fashion Designers' Decision-Making Process

    Iowa State University Capstones, Theses and Graduate Theses and Dissertations Dissertations 2013 Fashion designers' decision-making process: The influence of cultural values and personal experience in the creative design process Ja-Young Hwang Iowa State University Follow this and additional works at: https://lib.dr.iastate.edu/etd Part of the Art and Design Commons Recommended Citation Hwang, Ja-Young, "Fashion designers' decision-making process: The influence of cultural values and personal experience in the creative design process" (2013). Graduate Theses and Dissertations. 13638. https://lib.dr.iastate.edu/etd/13638 This Dissertation is brought to you for free and open access by the Iowa State University Capstones, Theses and Dissertations at Iowa State University Digital Repository. It has been accepted for inclusion in Graduate Theses and Dissertations by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Fashion designers’ decision-making process: The influence of cultural values and personal experience in the creative design process by Ja -Young Hwang A dissertation submitted to the graduate faculty in partial fulfillment of the requirements for the degree of DOCTOR OF PHILOSOPHY Major: Apparel, Merchandising, and Design Program of Study Committee: Mary Lynn Damhorst, Co-Major Professor Eulanda Sanders, Co-Major Professor Sara B. Marcketti Cindy Gould Barbara Caldwell Iowa State University Ames, Iowa 2013 Copyright © Ja Young Hwang, 2013. All rights
  • Theoretically Comparing Design Thinking to Design Methods for Large- Scale Infrastructure Systems

    Theoretically Comparing Design Thinking to Design Methods for Large- Scale Infrastructure Systems

    The Fifth International Conference on Design Creativity (ICDC2018) Bath, UK, January 31st – February 2nd 2018 THEORETICALLY COMPARING DESIGN THINKING TO DESIGN METHODS FOR LARGE- SCALE INFRASTRUCTURE SYSTEMS M.A. Guerra1 and T. Shealy1 1Civil Engineering, Virginia Tech, Blacksburg, USA Abstract: Design of new and re-design of existing infrastructure systems will require creative ways of thinking in order to meet increasingly high demand for services. Both the theory and practice of design thinking helps to exploit opposing ideas for creativity, and also provides an approach to balance stakeholder needs, technical feasibility, and resource constraints. This study compares the intent and function of five current design strategies for infrastructure with the theory and practice of design thinking. The evidence suggests the function and purpose of the later phases of design thinking, prototyping and testing, are missing from current design strategies for infrastructure. This is a critical oversight in design because designers gain much needed information about the performance of the system amid user behaviour. Those who design infrastructure need to explore new ways to incorporate feedback mechanisms gained from prototyping and testing. The use of physical prototypes for infrastructure may not be feasible due to scale and complexity. Future research should explore the use of prototyping and testing, in particular, how virtual prototypes could substitute the experience of real world installments and how this influences design cognition among designers and stakeholders. Keywords: Design thinking, design of infrastructure systems 1. Introduction Infrastructure systems account for the vast majority of energy use and associated carbon emissions in the United States (US EPA, 2014).
  • Fiendish Designs

    Fiendish Designs

    Fiendish Designs A Software Engineering Odyssey © Tim Denvir 2011 1 Preface These are notes, incomplete but extensive, for a book which I hope will give a personal view of the first forty years or so of Software Engineering. Whether the book will ever see the light of day, I am not sure. These notes have come, I realise, to be a memoir of my working life in SE. I want to capture not only the evolution of the technical discipline which is software engineering, but also the climate of social practice in the industry, which has changed hugely over time. To what extent, if at all, others will find this interesting, I have very little idea. I mention other, real people by name here and there. If anyone prefers me not to refer to them, or wishes to offer corrections on any item, they can email me (see Contact on Home Page). Introduction Everybody today encounters computers. There are computers inside petrol pumps, in cash tills, behind the dashboard instruments in modern cars, and in libraries, doctors’ surgeries and beside the dentist’s chair. A large proportion of people have personal computers in their homes and may use them at work, without having to be specialists in computing. Most people have at least some idea that computers contain software, lists of instructions which drive the computer and enable it to perform different tasks. The term “software engineering” wasn’t coined until 1968, at a NATO-funded conference, but the activity that it stands for had been carried out for at least ten years before that.
  • Theory and Educational Strategy

    Theory and Educational Strategy

    40th International Conference on Environmental Systems AIAA 2010-6174 Space Architecture – Theory and Educational Strategy Ondrej DouleI International Space University (ISU), Illkirch-Graffenstaden, 67400, France Czech Technical University, Faculty of Architecture (CTU FA), Prague, 16634, Czech Republic This paper proposes a strategy for Space Architecture education based on joint research performed at the International Space University (ISU) in Strasbourg and at the Faculty of Architecture of the Czech Technical University (CTU FA) in Prague. The proposed strategy arranges a Space Architecture curriculum according to the Universal Architecture theory i.e. connecting space and terrestrial architecture disciplines for the benefit of both. Nomenclature CAD = Computer Aided Design CTU FA = Czech Technical University Faculty of Architecture CRM = Crew Resource Management ECLSS = Environmental Control and Life Support System EDL = Entry Descent Landing HMI = Human Machine Interface ISRU = In Situ Resource Utilization ISU = International Space University LEED = Leadership in Energy and Environmental Design SA = Space Architecture SICSA = Sasakawa International Center for Space Architecture UA = Universal Architecture I. Introduction ecent research on human workforce in the space industry identified a demand for specific soft skills which are R inherent in the architecture profession (see Appendix I.). A worldwide survey on Space Architecture (see Appendix II.) was started in April 2009 and over a period of 3 months data was collected from an
  • On a New Notion of Partial Refinement

    On a New Notion of Partial Refinement

    On a New Notion of Partial Refinement Emil Sekerinski Tian Zhang McMaster University McMaster University Hamilton, Canada Hamilton, Canada [email protected] [email protected] Formal specification techniques allow expressing idealized specifications, which abstract from re- strictions that may arise in implementations. However, partial implementations are universal in soft- ware development due to practical limitations. Our goal is to contribute to a method of program refinement that allows for partial implementations. For programs with a normal and an exceptional exit, we propose a new notion of partial refinement which allows an implementation to terminate ex- ceptionally if the desired results cannot be achieved, provided the initial state is maintained. Partial refinement leads to a systematic method of developing programs with exception handling. 1 Introduction In software development, specifications are meant to be concise by stating abstractly only the intention of a program rather than elaborating on a possible implementation. However, practical restrictions can prevent idealized specifications from being fully implemented. In general, there are three sources of partiality in implementations: there may be inherent limitations of the implementation, some features may intentionally not (yet) be implemented, or there may be a genuine fault. As an example of inherent limitations of an implementation, consider a class for the analysis of a collection of integers. The operations are initialization, inserting an integer, and summing all its elements. Assume that int is a type for machine-representable integers, bounded by MIN and MAX, and machine arithmetic is bounded, i.e. an overflow caused by arithmetic operations on int is detected and raises an exception, as available in x86 assembly language [11] and .NET [20].
  • Philosophy of Design: a Meta- Theoretical Structure for Design Theory

    Philosophy of Design: a Meta- Theoretical Structure for Design Theory

    Philosophy of design: a meta- theoretical structure for design theory Terence Love, Praxis Education, 21 Spiers Rd, Quinns Rocks, Western Australia This paper focuses on the structure and dynamic of theory in design research. Problems with existing theory are explored, and a new meta- theoretical method is suggested for assisting the critical analysis, comparison and formulation of design theories and concepts. This meta- theoretical method contributes to building a simplifying paradigm of design research by providing a means to clarify the existing state of design theory in the field, to assist with the establishment of coherence and compatibility between concepts in disparate theories, to validate theory and concepts, and to uncover ‘hidden’ aspects of design theories. 2000 Elsevier Science Ltd. All rights reserved Keywords: philosophy of design, design theory, epistemology, ontology, design philosophy his paper is a contribution to the study of Philosophy of Design. In it, a critical overview is taken of the structure and dynamic of Tdesign theory. This overview leads to a method to assist with the critical analysis of design theories and their associated concepts. If we consider ‘design theory’ as an artefact to be designed, this paper’s role is in the part of the design process often called ‘problem analysis’. Under- pinning what is presented in this paper is an assumption that the act of designing by human agents is central to the academic study of design. This theoretical standpoint, that what is described as design always implicates humans, together with the understanding that any theories, theorising or theory interpretation has meaning only in a human context, is the basis for the analyses presented below.