DOCSLIB.ORG

Functional Design Patterns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Functional Design Patterns Functional Design Patterns @ScottWlaschin fsharpforfunandprofit.com Functional Design PatternsX @ScottWlaschin fsharpforfunandprofit.com Functional Design Patterns @ScottWlaschin fsharpforfunandprofit.com Functional patterns • Apomorphisms • Dynamorphisms • Chronomorphisms • Zygohistomorphic prepromorphisms Functional patterns • Core Principles of FP design – Functions, types, composition • Functions as parameters – Abstraction, Dependency injection – Partial application, Continuations, Folds, • Chaining functions – Error handling, Async – Monads • Dealing with wrapped data – Lifting, Functors – Validation with Applicatives • Aggregating data and operations – Monoids This talk Functional programming is scary Functional programming is scary Object oriented programming is scary OO pattern/principle FP pattern/principle • Single Responsibility Principle • Functions • Open/Closed principle • Functions • Dependency Inversion • Functions, also Principle • Interface Segregation • Functions Principle • Factory pattern • Yes, functions • Strategy pattern • Oh my, functions again! • Decorator pattern • Functions • Visitor pattern • Functions Seriously, FP patterns are different A short and mostly wrong history of programming paradigms Object-Oriented programming • What we envisioned: – Smalltalk • What we got: – C++ “Worse is better” – Object oriented Cobol – PHP – Java Functional programming • What we envisioned: – Haskell, OCaml, F#, etc • What we got: – ?? Please don’t let this happen to FP! Important to understand! CORE PRINCIPLES OF FP DESIGN Core principles of FP design Steal from mathematics Types are not classes Functions are things Function Composition everywhere Core principle: Steal from mathematics “Programming is one of the most difficult branches of applied mathematics” - E. W. Dijkstra Why mathematics Dijkstra said: • Mathematical assertions tend to be unusually precise. • Mathematical assertions tend to be general. They are applicable to a large (often infinite) class of instances. • Mathematics embodies a discipline of reasoning allowing assertions to be made with an unusually high confidence level. “Object-oriented programming is an exceptionally bad idea which could only have originated in California.” E. W. Dijkstra Mathematical functions Domain (int) Codomain (int) … … -1 0 0 1 1 2 2 3 3 4 … Function add1(x) … input x maps to x+1 let add1 x = x + 1 val add1 : int -> int Mathematical functions Domain (int) Codomain (int) … int add1(int input) … -1 { 0 0 switch (input) 1 1 { 2 2 case 0: return 1; 3 3 case 1: return 2; 4 … caseFunction 2: return add1(x) 3; … input case x 3: maps return to 4; x+1 etc ad infinitum } } • Input and output values already exist • A function is not a calculation, just a mapping • Input and output values are unchanged (immutable) Mathematical functions Domain (int) Codomain (int) … … -1 0 0 1 1 2 2 3 3 4 … Function add1(x) … input x maps to x+1 • A (mathematical) function always gives the same output value for a given input value • A (mathematical) function has no side effects Functions don't have to be about arithmetic Customer (domain) Name (codomain) … Name CustomerName(Customer input) … Cust1 { Alice Cust2 switch (input) Bob Cust3 { Sue Cust3 case Cust1: return “Alice”; John … case Cust2: return “Bob”; Pam caseFunction Cust3: CustomerName return “Sue”;(x) … input etc Customer maps to PersonalName } } Functions can work on functions int->int int list -> int list … … add1 eachAdd1 times2 eachTimes2 subtract3 eachSubtract3 add42 eachAdd42 … … Function List.map int->int maps to int list->int list Guideline: Strive for purity The practical benefits of pure functions Pure functions are easy to reason about Reasoning about code that might not be pure: customer.SetName(newName); var name = customer.GetName(); Reasoning about code that is pure: let newCustomer = setCustomerName(aCustomer, newName) let name,newCustomer = getCustomerName(aCustomer) The customer is being changed. The practical benefits of pure functions Pure functions are easy to refactor let x = doSomething() let y = doSomethingElse(x) return y + 1 The practical benefits of pure functions Pure functions are easy to refactor let x = doSomething() let y = doSomethingElse(x) return y + 1 The practical benefits of pure functions Pure functions are easy to refactor let helper() = let x = doSomething() let y = doSomethingElse(x) return y return helper() + 1 More practical benefits of pure functions • Laziness – only evaluate when I need the output • Cacheable results – same answer every time – "memoization" • No order dependencies – I can evaluate them in any order I like • Parallelizable – "embarrassingly parallel" How to design a pure function Pure Awesomeness! How to design a pure function • Haskell – very pure • F#, OCaml, Clojure, Scala – easy to be pure • C#, Java, JavaScript – have to make an effort Core principle: Types are not classes X Types are not classes So what is a type? Set of Set of valid inputs valid outputs Types separate data from behavior Lists Lists List.map List.collect List.filter List.etc Core principle: Functions are things Function Functions as things FunctionThe Tunnel of Transformationapple -> banana A function is a standalone thing, not attached to a class Functions as things let z = 1 1 let add x y = x + y int-> int->int Functions as inputs and outputs let add x = (fun y -> x + y) int int->(int->int) int->int Function as output let useFn f = f() + 1 int->int (int->int)->int int Function as input let transformInt f x = (f x) + 1 int->int Function as parameter int int->int int Core principle: Composition everywhere Function composition Function 1 Function 2 apple -> banana banana -> cherry Function composition Function 1 Function 2 apple -> banana >> banana -> cherry Function composition New Function apple -> cherry Can't tell it was built from smaller functions! Types can be composed too “algebraic types" Product types Alice, Jan 12th Set of people Set of dates Bob, Feb 2nd × = Carol, Mar 3rd type Birthday = Person * Date Sum types Set of Cash values + type PaymentMethod = | Cash Set of Cheque values | Cheque of ChequeNumber + | Card of CardType * CardNumber Set of CreditCard values DDD & DOMAIN MODELLING Domain modelling pattern: Use types to represent constraints Types represent constraints on input and output type Suit = Club | Diamond | Spade | Heart type String50 = // non-null, not more than 50 chars type EmailAddress = // non-null, must contain ‘@’ type StringTransformer = string -> string Instant mockability type GetCustomer = CustomerId -> Customer option Domain modelling pattern: Types are cheap Types are cheap type Suit = Club | Diamond | Spade | Heart type Rank = Two | Three | Four | Five | Six | Seven | Eight | Nine | Ten | Jack | Queen | King | Ace type Card = Suit * Rank type Hand = Card list Only one line of code to create a type! Design principle: Strive for totality Totality Domain (int) Codomain (int) … int TwelveDividedBy(int input) … 3 { 4 2 switch (input) 6 1 { 12 0 case 3: return 4; … … case 2: return 6; casetwelveDividedBy 1: return 12; (x) caseinput x0: return maps to ??; 12/x } } What happens here? Totality Constrain the input NonZeroInteger int … int TwelveDividedBy(int input) … 3 { 4 2 switch (input) 6 1 { 12 -1 case 3: return 4; … … case 2: return 6; casetwelveDividedBy 1: return 12; (x) caseinput x- 1: returnmaps to - 12; 12/x 0 is missing } } 0 is doesn’t have to be handled NonZeroInteger -> int Types are documentation Totality Extend the output int Option<Int> … int TwelveDividedBy(int input) … 3 { Some 4 2 switch (input) Some 6 1 { Some 12 0 case 3: return Some 4; None -1 case 2: return Some 6; … … casetwelveDividedBy 1: return Some(x) 12; caseinput x0: return maps to None; 12/x } } 0 is valid input int -> int option Types are documentation Design principle: Use types to indicate errors Output types as error codes ParseInt: string -> int No nulls ParseInt: string -> int option No exceptions FetchPage: Uri -> String FetchPage: Uri -> SuccessOrFailure<String> LoadCustomer: CustomerId -> Customer LoadCustomer: CustomerId -> SuccessOrFailure<Customer> Use the signature, Luke! Domain modelling principle: “Make illegal states unrepresentable” Types can represent business rules type EmailContactInfo = | Unverified of EmailAddress | Verified of VerifiedEmailAddress type ContactInfo = | EmailOnly of EmailContactInfo | AddrOnly of PostalContactInfo | EmailAndAddr of EmailContactInfo * PostalContactInfo Domain modelling principle: Use sum-types instead of inheritance Using sum vs. inheritance type PaymentMethod = | Cash | Cheque of ChequeNumber | Card of CardType * CardNumber OO version: What goes in here? What interface IPaymentMethod {..} is the common behaviour? class Cash : IPaymentMethod {..} Definition is scattered around class Cheque : IPaymentMethod {..} many locations class Card : IPaymentMethod {..} class Evil : IPaymentMethod {..} Domain modelling principle: Use sum-types for state machines Add Item Add Item Empty Cart Active Cart Paid Cart Pay Remove Item Remove Item type ShoppingCart = | EmptyCartState | ActiveCartState of ActiveCartData | PaidCartState of PaidCartData Domain modelling principle: It’s ok to expose public data It’s ok to expose public data Immutable type PersonalName = { FirstName: String50 Can’t create MiddleInitial: String1 option invalid values LastName: String50 } Domain modelling principle: Types are executable documentation Types are executable documentation type Suit = Club | Diamond | Spade | Heart type Rank = Two | Three | Four | Five | Six |
Load more

Recommended publications
  • Functional Javascript
    www.it-ebooks.info www.it-ebooks.info Functional JavaScript Michael Fogus www.it-ebooks.info Functional JavaScript by Michael Fogus Copyright © 2013 Michael Fogus. 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 Treseler Indexer: Judith McConville Production Editor: Melanie Yarbrough Cover Designer: Karen Montgomery Copyeditor: Jasmine Kwityn Interior Designer: David Futato Proofreader: Jilly Gagnon Illustrator: Robert Romano May 2013: First Edition Revision History for the First Edition: 2013-05-24: First release See http://oreilly.com/catalog/errata.csp?isbn=9781449360726 for release details. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Functional JavaScript, the image of an eider duck, 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 trade‐ mark 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 author assume no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.
    [Show full text]
  • Combinatorial Species and Labelled Structures Brent Yorgey University of Pennsylvania, [email protected]
    University of Pennsylvania ScholarlyCommons Publicly Accessible Penn Dissertations 1-1-2014 Combinatorial Species and Labelled Structures Brent Yorgey University of Pennsylvania, [email protected] Follow this and additional works at: http://repository.upenn.edu/edissertations Part of the Computer Sciences Commons, and the Mathematics Commons Recommended Citation Yorgey, Brent, "Combinatorial Species and Labelled Structures" (2014). Publicly Accessible Penn Dissertations. 1512. http://repository.upenn.edu/edissertations/1512 This paper is posted at ScholarlyCommons. http://repository.upenn.edu/edissertations/1512 For more information, please contact [email protected]. Combinatorial Species and Labelled Structures Abstract The theory of combinatorial species was developed in the 1980s as part of the mathematical subfield of enumerative combinatorics, unifying and putting on a firmer theoretical basis a collection of techniques centered around generating functions. The theory of algebraic data types was developed, around the same time, in functional programming languages such as Hope and Miranda, and is still used today in languages such as Haskell, the ML family, and Scala. Despite their disparate origins, the two theories have striking similarities. In particular, both constitute algebraic frameworks in which to construct structures of interest. Though the similarity has not gone unnoticed, a link between combinatorial species and algebraic data types has never been systematically explored. This dissertation lays the theoretical groundwork for a precise—and, hopefully, useful—bridge bewteen the two theories. One of the key contributions is to port the theory of species from a classical, untyped set theory to a constructive type theory. This porting process is nontrivial, and involves fundamental issues related to equality and finiteness; the recently developed homotopy type theory is put to good use formalizing these issues in a satisfactory way.
    [Show full text]
  • Uusi Hakemisto
    214 6. Tunneling 215 ROCK EXCAVATION HANDBOOK 6.1. GENERAL SELECTING TUNNELING METHODS In modern tunnel and underground cavern excavation, it is possible to select from many dif- ferent methods. The following factors should be taken into consideration when selecting the method: - Tunnel dimensions - Tunnel geometry - Length of tunnel, total volume to be excavated - Geological and rock mechanical conditions - Ground water level and expected water inflow - Vibration restrictions FIGURE 6.1.-2. Range of methods compared to uniaxal compressive strength. - Allowed ground settlements The methods can be divided into drill & blast, and mechanical excavation. Mechanical meth- ods can be split further to partial face (e.g. roadheaders, hammers, excavators) or full face (TBM, shield, pipe jacking, micro tunneling). FIGURE 6.1.-1. Tunneling methods in different rock/soil conditions. The drill & blast method is still the most typical method for medium to hard rock conditions. It can be applied to a wide range of rock conditions. Some of its features include versatile equipment, fast start-up and relatively low capital cost tied to the equipment. On the other hand, the cyclic nature of the drill & blast method requires good work site organization. FIGURE 6.1.-3. Drill and blast cycle. Blast vibrations and noise also restrict the use of drill & blast in urban areas. 216 6. Tunneling 217 ROCK EXCAVATION HANDBOOK Hard-rock TBMs can be used in relatively soft to hard rock conditions, and best when rock DRIFTING AND TUNNELING fracturing & weakness zones are predictable. The TBM is most economical method for longer tunnel lengths, in which its high investment cost and timely build-up can be utilized by the Many mines and excavation sites still plan their drilling patterns manually, but advanced high advance rate of excavation.
    [Show full text]
  • View on 5G Architecture
    5G PPP Architecture Working Group View on 5G Architecture Version 3.0, June 2019 Date: 2019-06-19 Version: 3.0 Dissemination level: Public Consultation Abstract The 5G Architecture Working Group as part of the 5G PPP Initiative is looking at capturing novel trends and key technological enablers for the realization of the 5G architecture. It also targets at presenting in a harmonized way the architectural concepts developed in various projects and initiatives (not limited to 5G PPP projects only) so as to provide a consolidated view on the technical directions for the architecture design in the 5G era. The first version of the white paper was released in July 2016, which captured novel trends and key technological enablers for the realization of the 5G architecture vision along with harmonized architectural concepts from 5G PPP Phase 1 projects and initiatives. Capitalizing on the architectural vision and framework set by the first version of the white paper, the Version 2.0 of the white paper was released in January 2018 and presented the latest findings and analyses of 5G PPP Phase I projects along with the concept evaluations. The work has continued with the 5G PPP Phase II and Phase III projects with special focus on understanding the requirements from vertical industries involved in the projects and then driving the required enhancements of the 5G Architecture able to meet their requirements. The results of the Working Group are now captured in this Version 3.0, which presents the consolidated European view on the architecture design. Dissemination level: Public Consultation Table of Contents 1 Introduction........................................................................................................................
    [Show full text]
  • Httpclient-Tutorial.Pdf
    HttpClient Tutorial Oleg Kalnichevski Jonathan Moore Jilles van Gurp Preface .................................................................................................................................... iv 1. HttpClient scope .......................................................................................................... iv 2. What HttpClient is NOT .............................................................................................. iv 1. Fundamentals ....................................................................................................................... 1 1.1. Request execution ...................................................................................................... 1 1.1.1. HTTP request .................................................................................................. 1 1.1.2. HTTP response ............................................................................................... 2 1.1.3. Working with message headers ........................................................................ 2 1.1.4. HTTP entity .................................................................................................... 3 1.1.5. Ensuring release of low level resources ............................................................ 5 1.1.6. Consuming entity content ................................................................................ 6 1.1.7. Producing entity content .................................................................................. 6 1.1.8. Response
    [Show full text]
  • Tunnel Operations, Maintenance, Inspection, and Evaluation (TOMIE
    Tunnel Operations, Maintenance, Inspection, and Evaluation (TOMIE) Manual July 2015 Publication No. FHWA-HIF-15-005 Tunnel Operations, Maintenance, Inspection, and Evaluation Manual July 2015 Publication No. FHWA-HIF-15-005 Federal Highway Administration Office of Bridges and Structures 1200 New Jersey Avenue, SE Washington DC 20590 1. Report No. 2. Government Accession No. 3. Recipient’s Catalog No. FHWA-HIF-15-005 4. Title and Subtitle 5. Report Date Tunnel Operations, Maintenance, Inspection, and Evaluation July 2015 6. Performing Organization Code (TOMIE) Manual 7. Author(s) 8. Performing Organization Report No. William Bergeson, PE and Steve Ernst, PE (FHWA) 9. Performing Organization Name and Address 10. Work Unit No. Federal Highway Administration 1200 New Jersey Ave, SE 11. Contract or Grant No. Washington, D.C. 20590 12. Sponsoring Agency Name and Address 13. Type of Report and Period Covered 14. Sponsoring Agency Code 15. Supplementary Notes The FHWA would like to acknowledge the contribution of HDR on a draft version of this Manual under Contract DTFH61-07-D-00004. The authors of the draft manual were Brian J. Leshko, P.E. (HDR), Chester L. Allen, P.E. (GF), Mark J. Pavlick, P.E. (HDR). HDR Engineering, Inc. 11 Stanwix Street, Suite 800 Pittsburgh, Pennsylvania 15222 Brian Kozy, PE, PhD and Lubin Gao, PE, PhD (FHWA) provided expert review comments. Gail Edwards (FHWA) provided technical edits. Michelle Cribbs (FHWA) checked this document for Section 508 compliance. 16. Abstract Tunnels represent a significant financial investment with challenging design, construction, and operational issues. Tunnels that are not adequately maintained usually require more costly and extensive repairs.
    [Show full text]
  • Tutorial: Security Patterns and Secure Systems Design Using UML
    Tutorial: Security patterns and secure systems design using UML Eduardo B. Fernandez and Maria M. Larrondo Petrie Dept. of Computer Science and Eng. Florida Atlantic University www.cse.fau.edu/~security ICWMC/ICCGI 2007 {ed, maria}@cse.fau.edu 1 Guadaloupe, French Caribbean, IARIA, 4-9 March 2007 • Professor of Computer Science at Florida Atlantic University, Boca Raton, FL, USA • At IBM for 8 years (L.A. Scientific Center). • Wrote the first book on database security (Addison-Wesley, 1981). • Author of many research papers • Consultant to IBM, Siemens, Lucent,… • MS EE Purdue U, PhD CS UCLA ICWMC/ICCGI 2007 2 Guadaloupe, French Caribbean, IARIA, 4-9 March 2007 • Professor of Computer Science & Engineering and Associate Dean of Academic & International Affairs at Florida Atlantic University, Boca Raton, FL., USA • Executive Vice President of LACCEI (Latin American and Caribbean Consortium of Engineering Institutions) • Authored over 130 research papers on complex systems modeling (environmental, security) • Over US$2.5M in research grants from NATO, IBM, NSF, and South Florida Water Management District ICWMC/ICCGI 2007 3 Guadaloupe, French Caribbean, IARIA, 4-9 March 2007 Abstract • Analysis and design patterns are well established to build high-quality object- oriented software. Patterns combine experience and good practices to develop basic models that can be used for new designs. Security patterns join the extensive knowledge accumulated about security with the structure provided by patterns to provide guidelines for secure system design and evaluation. We show a variety of security patterns and their use in the construction of secure systems. These patterns include Authentication, Authorization, Role-based Access Control, Firewalls, Web Services Security, and others.
    [Show full text]
  • Composing Software an Exploration of Functional Programming and Object Composition in Javascript
    Composing Software An Exploration of Functional Programming and Object Composition in JavaScript Eric Elliott This book is for sale at http://leanpub.com/composingsoftware This version was published on 2019-02-24 This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and many iterations to get reader feedback, pivot until you have the right book and build traction once you do. © 2017 - 2019 Eric Elliott Contents Thank You ................................................... 1 Composing Software: An Introduction ................................. 2 You Compose Software Every Day .................................. 3 Conclusion ................................................. 10 The Dao of Immutability (The Way of the Functional Programmer) .............. 11 Forward .................................................. 11 The Rise and Fall and Rise of Functional Programming (Composable Software) ....... 13 The Rise of Functional Programming ................................. 13 The Fall of Functional Programming ................................. 16 The Rise of Functional Programming ................................. 16 Functional Programming Has Always Been Alive and Well ................... 17 Why Learn Functional Programming in JavaScript? ........................ 18 Pure Functions ................................................ 25 What is a Function? ........................................... 25 Mapping .................................................
    [Show full text]
  • Amity School of Engineering & Technology Amity
    Amity School of Engineering & Technology Amity University Object Oriented System Design Code: CSE416 Prepared By Hari Mohan Pandey Assistant Professor, CSE Department [email protected] Module Notes Department of Computer Science & Engineering ODD Semester 2014 Object Oriented System Design Page: 1/74 UNIT-3 DIAGRAMS 3.1 Sequence diagrams A sequence diagram is an interaction diagram that details how operations are carried out - - what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence. Below is a sequence diagram for making a hotel reservation. The object initiating the sequence of messages is a Reservation window. Figure: Sequence Diagram-1 Object Oriented System Design Page: 2/74 The Reservation window sends a makeReservation () message to a HotelChain. The HotelChain then sends a makeReservation () message to a Hotel. If the Hotel has available rooms, then it makes a Reservation and a Confirmation. Within a sequence diagram, on object is available in the box at the top of a dotted vertical line. Each vertical dotted line is a lifeline, representing the time that an object exists. Each arrow is a message call. An arrow goes from the sender to the top of the activation bar of the message on the receiver's lifeline. The activation bar represents the duration of execution of the message. Each message is labeled at minimum with the message name. In our diagram, the Hotel issues a self call to determine if a room is available.
    [Show full text]
  • Creating High-Performance, Statically Type-Safe Network Applications
    UCAM-CL-TR-775 Technical Report ISSN 1476-2986 Number 775 Computer Laboratory Creating high-performance, statically type-safe network applications Anil Madhavapeddy March 2010 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2010 Anil Madhavapeddy This technical report is based on a dissertation submitted April 2006 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Robinson College. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: http://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 Abstract A typical Internet server finds itself in the middle of a virtual battleground, under constant threat from worms, viruses and other malware seeking to subvert the original intentions of the programmer. In particular, critical Internet servers such as OpenSSH, BIND and Sendmail have had numerous security issues ranging from low-level buffer overflows to subtle protocol logic errors. These problems have cost billions of dollars as the growth of the Internet exposes increasing numbers of computers to electronic malware. Despite the decades of research on techniques such as model-checking, type-safety and other forms of formal analysis, the vast majority of server implementations continue to be written unsafely and informally in C/C++. In this dissertation we propose an architecture for constructing new implementations of stan- dard Internet protocols which integrates mature formal methods not currently used in deployed servers: (i) static type systems from the ML family of functional languages; (ii) model checking to verify safety properties exhaustively about aspects of the servers; and (iii) generative meta- programming to express high-level constraints for the domain-specific tasks of packet parsing and constructing non-deterministic state machines.
    [Show full text]
  • Architecture Styles and Design of Network Based Software
    UNIVERSITY OF CALIFORNIA, IRVINE Architectural Styles and the Design of Network-based Software Architectures DISSERTATION submitted in partial satisfaction of the requirements for the degree of DOCTOR OF PHILOSOPHY in Information and Computer Science by Roy Thomas Fielding Dissertation Committee: Professor Richard N. Taylor, Chair Professor Mark S. Ackerman Professor David S. Rosenblum 2000 © Roy Thomas Fielding, 2000. All rights reserved. The dissertation of Roy Thomas Fielding is approved and is acceptable in quality and form for publication on microfilm: ____________________________________ ____________________________________ ____________________________________ Committee Chair University of California, Irvine 2000 ii DEDICATION To my parents, Pete and Kathleen Fielding, who made all of this possible, for their endless encouragement and patience. And also to Tim Berners-Lee, for making the World Wide Web an open, collaborative project. What is life? It is the flash of a firefly in the night. It is the breath of a buffalo in the wintertime. It is the little shadow which runs across the grass and loses itself in the sunset. — Crowfoot's last words (1890), Blackfoot warrior and orator. Almost everybody feels at peace with nature: listening to the ocean waves against the shore, by a still lake, in a field of grass, on a windblown heath. One day, when we have learned the timeless way again, we shall feel the same about our towns, and we shall feel as much at peace in them, as we do today walking by the ocean, or stretched out in the long
    [Show full text]
  • Protocols and Standards for Simulation and Co-Simulation Doctoral Thesis Doctoral for Demanding Maritime Operations
    Doctoral theses at NTNU, 2021:81 Lars Ivar Hatledal Lars Ivar Hatledal Protocols and Standards for Simulation and Co-simulation Doctoral thesis Doctoral For Demanding Maritime Operations ISBN 978-82-326-5777-3 (printed ver.) ISBN 978-82-326-5231-0 (electronic ver.) ISSN 1503-8181 (printed ver.) ISSN 2703-8084 (online ver.) Doctoral theses at NTNU, 2021:81 theses at NTNU, Doctoral NTNU Engineering Philosophiae Doctor Faculty of Engineering Thesis for the Degree of Thesis for the Degree Department of Ocean Operations and Civil Department of Ocean Operations Norwegian University of Science and Technology Lars Ivar Hatledal Protocols and Standards for Simulation and Co-simulation For Demanding Maritime Operations Thesis for the Degree of Philosophiae Doctor Trondheim, March 2021 Norwegian University of Science and Technology Faculty of Engineering Department of Ocean Operations and Civil Engineering NTNU Norwegian University of Science and Technology Thesis for the Degree of Philosophiae Doctor Faculty of Engineering Department of Ocean Operations and Civil Engineering © Lars Ivar Hatledal ISBN 978-82-326-5777-3 (printed ver.) ISBN 978-82-326-5231-0 (electronic ver.) ISSN 1503-8181 (printed ver.) ISSN 2703-8084 (online ver.) Doctoral theses at NTNU, 2021:81 Printed by NTNU Grafisk senter Abstract There is a strong demand for innovation and efficiency within operations, life cycle services, and design of maritime systems. Modern vessels operate increasingly autonomously through strongly interacting sub-systems. These systems are dedicated to a specific, primary objective of the vessel or may be part of the general essential ship operations. The sub-systems exchange data and make coordinated operational decisions, ideally without any user interaction.
    [Show full text]