DOCSLIB.ORG

Practical API Design: Confessions Practical API Design of a Java™ Framework Architect

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Practical API Design: Confessions Practical API Design of a Java™ Framework Architect CYAN YELLOW MAGENTA BLACK PANTONE 123 C BOOKS FOR PROFESSIONALS BY PROFESSIONALS® THE EXPERT’S VOICE® IN JAVA™ TECHNOLOGY Companion eBook Available Practical API Design: Confessions API Design Practical of a Java™ Framework Architect Dear Reader, Maybe you’re standing in a bookstore, holding this book in your hand, and ask- ing yourself, “Should I buy it?” Here is your answer. If you’ve ever written code and handed it to others to let them compile their code against yours, then you’re ready to enter the API design world and this book will help you explore it. Practical However, this book doesn’t attempt to “teach API design in five easy lessons.” It cannot be read in “only three days!” If you’re looking for a quick handbook, this book is probably not for you. On the other hand, if you’re interested in a deeper knowledge of API design, in knowing not only the how, but also the why, let me introduce myself to you before you put this book back on the shelf. My name is Jaroslav Tulach and I am the founder and initial architect of the NetBeans™ project, which is not just a well-known IDE, but also the first modu- lar desktop application framework written in the Java™ language. This book is based on notes that I’ve collected over the last ten years, while designing and API Design maintaining NetBeans APIs and transferring this knowledge to the rest of our developers. It’s a journal from the heart of the NetBeans laboratory, describing our problems, our growing understanding of them, the solutions we’ve chosen, ™ and the conclusions we made after applying them. Although our knowledge has Confessions of a Java Framework Architect been gathered while working on NetBeans, it’s general enough to be useful for most software projects. Knowledge of proper API design is essential for the successful creation of 21st century software. Let this book be your guide while exploring the big wide world of API design. Jaroslav Tulach API design done right, from one of the Java™ community’s most experienced API designers. RELatED TITLES Companion eBook See last page for details on $10 eBook version Tulach ISBN 978-1-4302-0973-7 Jaroslav Tulach SOURCE CODE ONLINE 9 0 0 0 0 www.apress.com Founder of the NetBeans™ Platform Shelve in Software Development User level: Intermediate–Advanced 9 781430 209737 this print for content only—size & color not accurate 7" x 9-1/4" / CASEBOUND / MALLOY (0.8125 INCH BULK -- 416 pages -- 50# Thor) 0973-7 FM.qxd 6/26/08 11:25 AM Page i Practical API Design Confessions of a Java Framework Architect Jaroslav Tulach 0973-7 FM.qxd 6/26/08 11:25 AM Page ii Practical API Design: Confessions of a Java Framework Architect Copyright © 2008 by Jaroslav Tulach All rights reserved. No part of this work may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording, or by any information storage or retrieval system, without the prior written permission of the copyright owner and the publisher. ISBN-13: 978-1-4302-0973-7 ISBN-13 (electronic): 978-1-4302-0974-4 Printed and bound in the United States of America 9 8 7 6 5 4 3 2 1 Trademarked names may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, we use the names only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. Java™ and all Java-based marks are trademarks or registered trademarks of Sun Microsystems, Inc., in the US and other countries. Apress, Inc., is not affiliated with Sun Microsystems, Inc., and this book was writ- ten without endorsement from Sun Microsystems, Inc. Lead Editor: Clay Andres Editorial Board: Clay Andres, Steve Anglin, Ewan Buckingham, Tony Campbell, Gary Cornell, Jonathan Gennick, Matthew Moodie, Joseph Ottinger, Jeffrey Pepper, Frank Pohlmann, Ben Renow-Clarke, Dominic Shakeshaft, Matt Wade, Tom Welsh Project Manager: Kylie Johnston Copy Editor: Susannah Davidson Pfalzer Associate Production Director: Kari Brooks-Copony Production Editor: Ellie Fountain Compositor: Gina Rexrode Proofreader: Liz Welch Indexer: Broccoli Information Management Artist: Kinetic Publishing Services, LLC Cover Designer: Kurt Krames Manufacturing Director: Tom Debolski Distributed to the book trade worldwide by Springer-Verlag New York, Inc., 233 Spring Street, 6th Floor, New York, NY 10013. Phone 1-800-SPRINGER, fax 201-348-4505, e-mail [email protected], or visit http://www.springeronline.com. For information on translations, please contact Apress directly at 2855 Telegraph Avenue, Suite 600, Berkeley, CA 94705. Phone 510-549-5930, fax 510-549-5939, e-mail [email protected], or visit http://www.apress.com. Apress and friends of ED books may be purchased in bulk for academic, corporate, or promotional use. eBook versions and licenses are also available for most titles. For more information, reference our Special Bulk Sales–eBook Licensing web page at http://www.apress.com/info/bulksales. The information in this book is distributed on an “as is” basis, without warranty. Although every precaution has been taken in the preparation of this work, neither the author(s) nor Apress shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the information contained in this work. The source code for this book is available to readers at http://www.apress.com. 0973-7 FM.qxd 6/26/08 11:25 AM Page iii 0973-7 FM.qxd 6/26/08 11:25 AM Page iv Contents at a Glance About the Author . xiii Acknowledgments . xv Prologue: Yet Another Design Book? . xvii PART 1 Theory and Justification ICHAPTER 1 The Art of Building Modern Software . 5 ICHAPTER 2 The Motivation to Create an API . 15 ICHAPTER 3 Determining What Makes a Good API . 27 ICHAPTER 4 Ever-Changing Targets . 41 PART 2 Practical Design ICHAPTER 5 Do Not Expose More Than You Want. 69 ICHAPTER 6 Code Against Interfaces, Not Implementations. 87 ICHAPTER 7 Use Modular Architecture . 99 ICHAPTER 8 Separate APIs for Clients and Providers . 131 ICHAPTER 9 Keep Testability in Mind . 149 ICHAPTER 10 Cooperating with Other APIs . 159 ICHAPTER 11 Runtime Aspects of APIs . 185 ICHAPTER 12 Declarative Programming . 225 PART 3 Daily Life ICHAPTER 13 Extreme Advice Considered Harmful . 239 ICHAPTER 14 Paradoxes of API Design . 249 ICHAPTER 15 Evolving the API Universe . 261 ICHAPTER 16 Teamwork. 291 ICHAPTER 17 Using Games to Improve API Design Skills. 303 ICHAPTER 18 Extensible Visitor Pattern Case Study. 333 CHAPTER 19 End-of-Life Procedures . 355 iv I 0973-7 FM.qxd 6/26/08 11:25 AM Page v IEPILOGUE The Future . 363 IBIBLIOGRAPHY. 373 IINDEX . 375 v 0973-7 FM.qxd 6/26/08 11:25 AM Page vi 0973-7 FM.qxd 6/26/08 11:25 AM Page vii Contents About the Author . xiii Acknowledgments . xv Prologue: Yet Another Design Book? . xvii PART 1 Theory and Justification ICHAPTER 1 The Art of Building Modern Software. 5 Rationalism, Empiricism, and Cluelessness . 5 Evolution of Software So Far . 7 Gigantic Building Blocks. 9 Beauty, Truth, and Elegance . 10 More Cluelessness!. 12 ICHAPTER 2 The Motivation to Create an API . 15 Distributed Development . 15 Modularizing Applications . 17 Nonlinear Versioning . 20 It’s All About Communication . 22 Empirical Programming . 23 The First Version Is Always Easy. 25 ICHAPTER 3 Determining What Makes a Good API . 27 Method and Field Signatures. 27 Files and Their Content. 28 Environment Variables and Command-Line Options. 29 Text Messages As APIs. 31 Protocols . 32 Behavior . 34 I18N Support and L10N Messages. 35 Wide Definition of APIs . 36 vii 0973-7 FM.qxd 6/26/08 11:25 AM Page viii viii ICONTENTS How to Check the Quality of an API . 36 Comprehensibility . 37 Consistency. 38 Discoverability . 38 Simple Tasks Should Be Easy . 39 Preservation of Investment. 39 ICHAPTER 4 Ever-Changing Targets . 41 The First Version Is Never Perfect . 41 Backward Compatibility . 42 Source Compatibility . 42 Binary Compatibility.
Load more

Recommended publications
  • Introduction to API Documentation Workbook July 28, 2018 Peter Gruenbaum
    Introduction to API Documentation Workbook July 28, 2018 Peter Gruenbaum Table of Contents Exercise 1: Markdown............................................................................................................ 3 Exercise 2: Create a JSON file ................................................................................................. 4 Exercise 3: Document JSON files............................................................................................. 7 Exercise 4: Making REST Requests ........................................................................................ 11 Exercise 5: Documenting Method and URL ........................................................................... 16 Exercise 6: Using Query Parameters ..................................................................................... 17 Exercise 7: Documenting Query Parameters ......................................................................... 19 Discounts for Online Classes ................................................................................................ 21 Schedule for July 28, 2018 8:30 Registration and Introduction 9:00 Markdown 9:30 Data Types and JSON 10:15 Documenting JSON 11:00 Break 11:15 Structured Data for Docs 11:30 REST: Methods 12:15 Lunch 12:45 REST: URLs 1:30 REST: Query parameters 2:15 Break 2:30 Tools and Next Steps 2:45 Q&A © 2018 SDK Bridge, all rights reserved 2 Exercise 1: Markdown Follow these steps: 1. Go to https://stackedit.io/ 2. Click on Start Writing at the top 3. Delete any text that currently
    [Show full text]
  • Backup Server Archive API Company
    REFERENCE MANUAL | PUBLIC SAP Adaptive Server Enterprise 16.0 SP03 Document Version: 1.0 – 2019-01-15 Reference Manual: Backup Server Archive API company. All rights reserved. All rights company. affiliate THE BEST RUN 2019 SAP SE or an SAP SE or an SAP SAP 2019 © Content 1 Overview.................................................................. 3 1.1 Syntax.....................................................................3 1.2 Byte Stream Archive Command Options.............................................4 2 Application Programming Interface..............................................5 3 API Routines............................................................... 8 3.1 syb_defineapi................................................................8 3.2 syb_queryapi................................................................9 3.3 set_params................................................................ 10 3.4 syb_open..................................................................10 3.5 syb_close..................................................................11 3.6 syb_read.................................................................. 12 3.7 syb_write..................................................................13 4 Error Messages.............................................................15 4.1 Localization................................................................ 15 4.2 Error and Informational Messages................................................ 15 5 Dynamically Loadable Library..................................................17
    [Show full text]
  • Application/Json Headers Content-Type: Application/Json
    Documenting APIs with Swagger TC Camp Peter Gruenbaum Introduction } Covers } What is an API Definition? } YAML } Open API Specification } Writing Documentation } Generating Documentation } Alternatives to Swagger and the Open API Specification } Presentation and workbook at sdkbridge.com/downloads © 2018 SDK Bridge Peter Gruenbaum } PhD in Applied Physics from Stanford } Commercial Software Developer } Boeing, Microsoft, start-ups } C#, C++, Java, JavaScript, Objective-C } API Writer } Brought together writing and technology } Since 2003 } President of SDK Bridge } Teacher: Programming at middle, high school, and college © 2018 SDK Bridge API Definition } Swagger and the Open API Specification are ways to define an API } What is an API? } What can you do with an API definition? © 2018 SDK Bridge What are APIs? } Application Programming Interface } It defines how two pieces of software talk to each other } For this seminar, we are talking about Web APIs © 2018 SDK Bridge Web APIs API request API response Creative Commons Attribution 3.0. webdesignhot.com Creative Commons Attribution 3.0. Not a full web page ─ just the data! openclipart.org The API definition describes: • What requests are available • What the response looks like for each request © 2018 SDK Bridge REST } Swagger and the Open API Specification are designed for RESTful APIs } REST is a type of web API REpresentational State Transfer © 2018 SDK Bridge REST Requests and Responses Please send me the state of my feed API request API response I am transferring to you some data
    [Show full text]
  • Technical Writer
    Technical writer A technical writer (also called a technical communicator) is a professional writer who designs, writes, creates, maintains, and updates technical documentation. This documentation includes online help, user guides, white papers, design specifications, system manuals, and other documents. Engineers, scientists, and other professionals may also produce technical writing, usually handing their work to a professional technical writer for proofreading, editing, and formatting. A technical writer produces technical documentation for technical, business, and consumer audiences. Contents 1 Skill set 2 Qualifications 3 Methodology 4 Environment 5 Career growth 6 See also 7 References 8 External links Skill set In addition to solid research, language, and writing skills, a technical writer may have skills in: Information design Information architecture Training material development Illustration Typography Technical writing may be on any subject that requires explanation to a particular audience. A technical writer is not usually a subject matter expert (SME), but possesses and applies expertise to interview SMEs and conduct research necessary to produce accurate, comprehensive documents. Companies, governments, and other institutions typically hire technical writers not for expertise in a particular subject, but for expertise in technical writing, i.e., their ability to gather information, analyze subject and audience and produce clear documentation. A good technical writer creates documentation that is accurate, complete, unambiguous, and as concise as possible. Technical writers create documentation in many forms: printed, web-based or other electronic documentation, training materials, and industrial film scripts. Qualifications Technical writers work under many job titles, including Technical Communicator, Information Developer, Data Development Engineer, and Technical Documentation Specialist. In the United Kingdom and some other countries, a technical writer is often called a technical author or knowledge author.
    [Show full text]
  • What Is Api Documentation 6
    SEPTEMBER 2014 THE MAGAZINE OF THE SOCIETY FOR TECHNICAL COMMUNICATION WHAT IS API DOCUMENTATION 6 HOW DO YOU BREAK INTO API DOCUMENTATION? 9 WHAT FACTORS CONTRIBUTE TO GOOD API DOCUMENTATION? 12 LESSONS LEARNED AS A NOVICE API WRITER 16 HOW TO WRITE HELPFUL CODE SAMPLES 19 HOW MUCH PROGRAMMING DO YOU NEED TO KNOW TO WRITE API DOCUMENTATION? 23 API DOCUMENTATION How Do You shutterstock.com/Kutlayev Dmitryshutterstock.com/Kutlayev Break into API Documentation? By MARY CONNOR | Member The Market Government APIs (data.gov, http://catalog.data.gov/ Large numbers of us broke into technical writing by dataset?res_format=api&_res_format_limit=0) documenting software that runs on personal computers. Open APIs (Wikipedia, http://en.wikipedia.org/wiki/ Over the years, we have watched sales of those machines List_of_open_APIs) and their software packages stagnate. The manuals and Just how successful these APIs are has everything to do help that we created grew gaunt under the relentless with how quickly and easily programmers can become pressure to do it faster, cheaper, and lighter. With the power users of these new interfaces, and so everything rise of support-written knowledge bases (think ZenDesk, to do with documentation and tutorials, and us! That’s www.zendesk.com/) and community-generated content, the good news: the job market for programmer writers many wondered if conventional documentation jobs were has become habañero hot. Since I’ve put full-time API destined to fade. documentation experience on my profile, I’ve started Now we’re witnessing dizzying growth in high tech, receiving an eye-popping stream of unsolicited invitations driven by the shift to ubiquitous computing through for positions with tech companies that are everyday names mobile devices and by distributed, cloud-based storage to the wired crowd.
    [Show full text]
  • The Dart Programming Language This Page Intentionally Left Blank the Dart Programming Language
    The Dart Programming Language This page intentionally left blank The Dart Programming Language Gilad Bracha Boston • Columbus • Indianapolis • New York • San Francisco • Amsterdam • Cape Town Dubai • London • Madrid • Milan • Munich • Paris • Montreal • Toronto • Delhi • Mexico City Sao Paulo • Sidney • Hong Kong • Seoul • Singapore • Taipei • Tokyo 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 the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. For information about buying this title in bulk quantities, or for special sales opportunities (which may include electronic versions; custom cover designs; and content particular to your business, train- ing goals, marketing focus, or branding interests), please contact our corporate sales department at [email protected] or (800) 382-3419. For government sales inquiries, please contact [email protected]. For questions about sales outside the United States, please contact [email protected]. Visit us on the Web: informit.com/aw Library of Congress Control Number: 2015953614 Copyright c 2016 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copy- right, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photo- copying, recording, or likewise.
    [Show full text]
  • Application Programming Interface
    Application programming interface “API” redirects here. For other uses, see API (disam- nent. This specification is presented in a human read- biguation). able format in paper books or in electronic formats like For the MediaWiki (the software used by Wikipedia) eBooks or as man pages. For example, the math API on API, see mw:API Unix systems is a specification on how to use the math- ematical functions included in the math library. Among In computer programming, an application program- these functions there is a function, named sqrt(), that can be used to compute the square root of a given number. ming interface (API) is a set of routines, protocols, and tools for building software applications. An API The Unix command man 3 sqrt presents the signature of expresses a software component in terms of its opera- the function sqrt in the form: tions, inputs, outputs, and underlying types. An API de- SYNOPSIS #include <math.h> double sqrt(double X); fines functionalities that are independent of their respec- float sqrtf(float X); DESCRIPTION sqrt computes the tive implementations, which allows definitions and im- positive square root of the argument. ... RETURNS plementations to vary without compromising the inter- On success, the square root is returned. If X is real and face. A good API makes it easier to develop a program positive... by providing all the building blocks. A programmer then puts the blocks together. This description means that sqrt() function returns the In addition to accessing databases or computer hardware, square root of a positive floating point number (single or such as hard disk drives or video cards, an API can ease double precision), as another floating point number.
    [Show full text]
  • Bradford Harrison's Resume
    Bradford Thomas Harrison 902 N. Spruce St. Gunnison, Colorado 81230 970-596-8073 [email protected] 9/2015 – Present: Self Employed, Gunnison, CO Developer and Founder, Newsflanks.com. Develop and maintain news Website visited by news seekers who want to see both sides (flanks) of a news story or trending issue. Technologies used: MongoDB, Express, Bootstrap, Nunjucks and Node.js on a Linux server (linode.com). Support “mobile first” by leveraging browser standards (HTML, JavaScript, CSS) and Node.js functionality instead of creating apps that get installed. Use Adobe and Microsoft tools mostly, including Photoshop, Illustrator, Visual Studio, Flash and Visio. Source code hosted at http://github.com/bradfordharrison. 1/2013 – 8/2015: Vast Broadband, Sioux Falls, SD Network Operations Center (NOC) Tech. Monitored and performed troubleshooting on Vast’s Internet, video and phone networks. Triaged cases from the call center, declaring outages or escalating as necessary. Wrote technical documentation for the NOC. Participated in 24x7 on-call schedule. Dispatched cable techs to repair residential and commercial network problems in the field. Vast spun off from Wide Open West (WOW!) in 2014, creating the need for a separate Vast NOC. 2/2006 – 10/2012: Siriusware Inc., Gunnison, CO QA and Documentation Manager. Responsible for tracking release development and ensuring adequate testing before deployment. Managed four testers and a technical writer. Developed more than 10,000 pages of technical documentation as HTML (WebWorks Help) and PDF. Implemented and maintained knowledge database (Google Mini). Member of the after-hours emergency technical support team. Siriusware was purchased by Accesso in 2013. 10/2000 – 9/2005: Adobe Systems Corp., San Jose, CA Sr.
    [Show full text]
  • API Specifications FP7-ICT-2009-5 257103
    Deliverable D3.2 FP7-ICT-2009-5 257103 June 2011 D3.2: webinos phase I device, network, and server-side API specifications FP7-ICT-2009-5 257103 D3.2: webinos phase I device, network, and server-side API specifications page: 2 of 396 Project Number : FP7-ICT-2009-5 257103 Project Title : Secure WebOS Application Delivery Environment (webinos) Deliverable Type : Public Deliverable Number : D 3.2 Contractual Delivery Date : June, 30th, 2011 Actual Date of Delivery : June, 30th, 2011 Title of Deliverable : webinos phase I device, network, and server-side API specifications Contributing Work Package : WP 3 Nature of Deliverable : Report Editor : SonyEricsson Authors : Fraunhofer FOKUS, Deutsche Telekom, ERCIM, Telecom Italia, TNO, BMW F+T, SonyEricsson., ISMB, Document History Version Date Author (Partner) Remarks 0.9 01/07/2011 SonyEricsson Initial version created from Wiki 1.0 α 04/07/2011 Fraunhofer FOKUS Updated, Word-formatted version This work is partially funded by webinos, an EU-funded project under the EU FP7 ICT Programme, No 257103. FP7-ICT-2009-5 257103 page: 3 of 396 D3.2: webinos phase I device, network, and server-side API specifications Abstract This deliverable covers the APIs to be implemented by a webinos device. According to the use cases and requirements defined in WP2 and the common components introduced in task 3.1, task 3.2 has defined a set of application programming interface specifications (APIs) to make the desired functionalities available to webinos applications. Due to earlier or ongoing standardization and implementation activities, e.g. within W3C and WAC, some needed APIs are already specified and available in modern browsers.
    [Show full text]
  • How to Write Doc Comments for the Javadoc Tool
    5.6.2018 How to Write Doc Comments for the Javadoc Tool Menu Sign In Country/Region Call Oracle Technology Network / Java / Java SE / Documentation Overview Java SE Downloads Java EE Documentation Community Java ME Technologies Java SE Advanced & Suite Training Java Embedded How to Write Doc Comments for the Javadoc Tool Javadoc Home Page Java DB Web Tier This document describes the style guide, tag and image conventions we use in documentation comments for Java programs written at Java Software, Oracle. It does not rehash related material covered elsewhere: Java Card For reference material on Javadoc tags, see the Javadoc reference pages. Java TV For the required semantic content of documentation comments, see Requirements for Writing Java API Specifications. New to Java Contents Introduction Community Principles Java Magazine Terminology Source Files Writing Doc Comments Format of a Doc Comment Doc Comment Checking Tool Descriptions A Style Guide Tag Conventions ( @tag) Documenting Default Constructors Documenting Exceptions with @throws Tag Package-Level Comments Documenting Anonymous Inner Classes Including Images Examples of Doc Comments Troubleshooting Curly Quotes (Microsoft Word) Introduction Principles At Java Software, we have several guidelines that might make our documentation comments different than those of third party developers. Our documentation comments define the official Java Platform API Specification. To this end, our target audience is those who write Java compatibility tests, or conform or re-implement the Java platform, in addition to developers. We spend time and effort focused on specifying boundary conditions, argument ranges and corner cases rather than defining common programming terms, writing conceptual overviews, and including examples for developers.
    [Show full text]
  • 2015 Technical Communication Summit Proceedings
    Society for Technical Communication Summit Proceedings 21–24 June 2015 Columbus, Ohio #STC15 www.stc.org summit.stc.org1 Notice The papers published in these Proceedings were reproduced from originals furnished by the authors. The opinions expressed and integrity of the informa- tion are the responsibility of the authors and not the Society for Technical Communication (STC). STC grants permission to educators and academic libraries to distribute articles from these Proceedings for classroom purposes. There is no charge to these institutions provided they give credit to the author, the Proceedings, and STC. All others must request permission. All product and company names herein are the property of their respective owners. © 2015 Society for Technical Communication Contact Information Society for Technical Communication 9401 Lee Highway Suite 300 Fairfax, VA 22031 +1.703.522.4114 +1.703.522.2075 (fax) www.stc.org Colophon This publication was produced using Adobe InDesign CS6. The heading typefaces used are Helvetica, Helvetica Condensed, and Helvetica Ultra Condensed by Linotype and licensed through Adobe. The text is set in Georgia, which is licensed through Microsoft. This Proceedings publication was com- piled and designed by Michael Opsteegh. 2015 Technical Communication Summit Committee The Society for Technical Communication’s 62nd Annual Conference focuses on important trends in our profession. This publication contains papers submitted in support of the 2015 Summit conference sessions. This year’s conference is the result of the
    [Show full text]
  • Sustainable Technologies for Mobile Applications
    Sustainable Technologies for Mobile Applications Approved: ____________________________________________ Date: _________________ Prof. Dr. Christoph Wentzel - Committee Chair Approved: ____________________________________________ Date: _________________ Prof. Qi Yang, Ph.D. - Committee Member Approved: ____________________________________________ Date: _________________ Prof. Dr. Bernhard Kreling - Committee Member Sustainable Technologies for Mobile Applications A Thesis presented to the Graduate Faculties University of Wisconsin Platteville (UWP) and University of Applied Sciences Darmstadt (h_da) In Partial Fulfillment of the Requirement for the Degree Master of Science By Simon Heckmann Committee Chair: Prof. Dr. Christoph Wentzel (h_da) Committee Member: Prof. Dr. Bernhard Kreling (h_da) Committee Member: Prof. Qi Yang, Ph.D. (UWP) Start date: 02/16/2011 End date: 08/16/2011 Statement of Authorship Statement of Authorship I hereby declare that this thesis is written on my own solely by using the sources quoted in the thesis body. All contents (including text, figures, and tables), which are taken from sources, both verbally and in terms of meanings, are clearly marked and referenced. The thesis has not been previously submitted to any other examination board, neither in this nor in a similar form. ___________________________________ Simon Heckmann i Acknowledgments Acknowledgments First of all I would like to thank my advising professors, Dr. Wentzel, Dr. Yang and Dr. Kreling for helping me with this thesis. The great discussions about my ideas, results and findings helped me a lot during the entire creation process of this document. Secondly, I owe special thanks to my supervisors and colleges at Merck for their great sug- gestions and support. Especially, I would like to thank Dr. Michaela Bühler and Matthias Feldmann for their professional guidance and continuous motivation to tackle the challenges of this thesis.
    [Show full text]