We think you have liked this presentation. If you wish to download it, please recommend it to your friends in any social system. Share buttons are a little bit lower. Thank you!
Presentation is loading. Please wait.
Published byJayde Gladish
Modified about 1 year ago
© 2010 IBM Corporation APIs - Lines in the Sand Jim des Rivières, IBM
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec
3 Modules, abstractions, APIs, … These notions are Ubiquitous Economically important Thriving Not new
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Why so important? Inner working of human-built computer system need to be understandable Individual human mind has limited working capacity Teams of humans can only design and build systems they are able to understand APIs and abstractions are the only known way to achieve understandability at any scale Divide and conquer Scales linearly in size of program Essential aspect of all large software systems API stacks, built abstraction upon abstraction, layer upon layer - like coral reefs
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Programmers struggle with APIs APIs and abstractions take work Programmers constantly struggle with them Why? What can we do about it?
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Struggles with APIs Theme for talk Sampler of our struggles 1. Our tools 2. Drawing API lines 3. Our methodologies 4. Our natures
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Vocabulary Client Component A Implementation Component B API UsesImplements API = specified programmatic interface between components
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Vocabulary API = Application Programmer Interface Specified programmatic interface between components API spec is statement of intent Captures how API is supposed to work Establishes contracts between parties API mediates interaction between client and implementation Controls inter-component coupling API spec and implementation play complementary roles Both critically important
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Struggles with APIs - Our tools Relentlessly refactor code to improve understandability Refactoring tools help us Tool has awareness of language semantics Can apply meaning-preserving transformations
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Bull in a china shop Refactoring tools are dangerous where APIs are involved Will propose refactoring across API boundaries Will propose changes to API signatures Tools are blind to this important aspect of program
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec What can we do about it? Tools can be more helpful if they are API-aware Programmer can map out where APIs are Example: Eclipse PDE has map for plug-in’s APIs Eclipse nightly build compares APIs to baseline Report API changes, and classify as potentially breaking Refactoring tool can use API map when proposing refactorings
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Struggles with APIs - Drawing API lines Common question: How to add API to existing program? Program not written with API in mind They can identify a subset of classes and methods they feel comfortable letting consumers call Mark these public; mark rest private Add Javadoc They can write unit tests Is there anything else?
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec It's not a lie. It's a gift for fiction. API is like spy’s cover story in a spy novel Make cover story compelling so you won’t have to reveal truth Self-consistent, no gaps, no gaffs
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec A Convenient Fiction Designing API and writing spec is constructing believable story for consumers Consumers take story at face value Implementation is constrained to observable behavior Story appears true as far as consumers can tell Implementation can be arbitrarily complex E.g., JIT compiler implementing bytecode interpreter Have cake and eat it too
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Mixing genres Adding an API to existing program - hard Adding an API to existing program without breaking existing clients – next to impossible Bad to let shape of program dictate shape of API API will be harder for consumers to use API will not provide enough cover for implementation
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec What do we do about it? Set existing code base to the side temporarily Design API to give consumer what they really need Write test suites Cannibalize existing code base for the new implementation If an API is strategically important, usually cheaper to do it from outset rather than later API First methodology
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Struggles with APIs - Our methodologies Write program sketch – stubs for classes and methods Write unit tests that check program has desired behavior Write implementation of desired behavior Loop Run tests Exit if all tests green Debug program End To later change desired behavior Update tests to reflect behavior now desired Update implementation Rerun test-debug loop Development method maintains invariant Program implements desired behavior Test suite capable of verifying program implements desired behavior
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Beating around the bush Good – unit tests capitalize on programmer’s skill at writing programs Not so good – intended behavior is captured implicitly How does a consumer learn of program behavior? Read program code? Read test suites? Fails to address what consumers need to use the program
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec What can we do about it? Recognize central role played by API specs Spec explicitly captures intent in form consumer can use Design API by writing API specs (Javadoc) for classes, methods, etc. Write unit tests from specs Write implementation from specs Perform test-debug loop until tests run green To later change API Update API specs to reflect behavior now desired Update unit tests and implementation based on revised specs Rerun test-debug loop Development method maintains invariant Full API specs providing story for consumers Program implementing API to spec Test suite verifying program implements API to spec Test First methodology -> API First methodology
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Struggles with APIs - Our natures
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Programmers have natural bias for action We are professional programmers We get paid to BUILD systems that DO something
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Guerilla programming Task: write program to extract data for a one-time report Data is in these databases Accessible through unfamiliar API Deadline: tomorrow How would you go about it?
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Would you? A.Carefully read API doc so you could use API correctly B.Handle rare conditions that do not arise during execution C.Write test suites D.Design new APIs and abstractions E.Write documentation F.None of the above
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Or would you? Cobble together snippets from example programs that use API Write and debug and experiment on the fly Improvise
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Programmer’s psyche Recognize in yourself this powerful attraction Purely mechanistic side of programming Nothing except “here” and “now” No rules other than what works Understandability is minor consideration
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Commercial/industrial programming What we do day-to-day as programmers is not unrelated Circumstances differ from guerilla programming Program execution context “there and then” vs. “here and now” Program development context Write, test, and debug out of context vs. in context *Program size Large vs. small *Program lifetime Long-lived vs. one-shot *Development team Teams of programmers vs. solo programmer * Last 3 push on understandability
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Programmer recidivism Common cause of low quality code: Programmer falls back on guerilla programming practices in context where inappropriate Insufficient familiarity with APIs they are using Omit handling for rare program conditions Insufficient testing Unaware of API boundaries already in place Insufficient concern for program understandability
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Other Symptoms Procrastination on defining an API Disengagement from writing specifications No process for maintaining and evolving API
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec What can we do about it? Acknowledge that some programmers are drawn more strongly to mechanistic side of programming than others Provide training, practice, support Choose/assign programming tasks accordingly Tasks relying heavily on non-mechanistic aspects Designing and evolving APIs Tasks relying more on mechanistic aspects Implementing APIs Testing, debugging
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Concluding remarks APIs, abstractions, modules etc. are crucial to most everything we do In many cases, more lasting value in API spec that in code for implementations or clients; e.g. HTTP spec APIs are “soft” properties of computer system, not “hard” (mechanistic) ones Do not appeal to programmer’s bias for action Many practices, tools, methodologies are colored by same bias for action No surprise - developed by programmers for programmers But they can be improved to help with APIs too Challenge: Analyze your own individual and team work habits. Are there places where a bias for action is downplaying APIs?
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Questions?
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Thank you
© 2010 IBM Corporation – APIs: Lines in the Sand- Jim des Rivières – UFSC– Dec Some API-related Resources API First PIFirst.pdf PIFirst.pdf Eclipse APIs: Lines in the Sand entations/02_des_Rivieres.pdf entations/02_des_Rivieres.pdf How to Use the Eclipse API rules.html rules.html Effective Java, by Josh Bloch Evolving Java-based APIs Eclipse API Central
Object-Oriented Programming with Java Lecture 1: Introduction Autumn, 2007.
From Module Breakdown to Interface Specifications Completing the architectural design of Map Schematizer.
David Streader Computer Science Victoria University of Wellington Copyright: David Streader, Victoria University of Wellington Debugging COMP T1.
Well-behaved objects Main concepts to be covered Testing Debugging Test automation Writing for maintainability Objects First with Java - A Practical.
Software Engineering and Design Principles Chapter 1.
What is Testing? Testing is the process of finding errors in the system implementation. –The intent of testing is to find problems with the system.
Objects First With Java A Practical Introduction Using BlueJ Well-behaved objects 2.1.
ECE450 - Software Engineering II1 ECE450 – Software Engineering II Today: Introduction to Software Architecture.
API Design CPSC 315 – Programming Studio Fall 2008 Follows Kernighan and Pike, The Practice of Programming and Joshua Bloch’s Library-Centric Software.
© 2006 Pearson Addison-Wesley. All rights reserved2-1 Chapter 2 Principles of Programming & Software Engineering.
Computer Science 340 Software Design & Testing Design By Contract.
CSPC 464 Fall 2014 Son Nguyen. Attendance/Roster Introduction ◦ Instructor ◦ Students Syllabus Q & A.
11-Jun-14 The assert statement. 2 About the assert statement The purpose of the assert statement is to give you a way to catch program errors early The.
What is Enterprise Architecture? Set of models –Describe the technical implementation of an organization’s business strategy and business processes “Form.
SWE 4743 Abstract Data Types Richard Gesick. SWE Abstract Data Types Object-oriented design is based on the theory of abstract data types Domain.
What is Software Engineering? the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software”
© 2006 Pearson Addison-Wesley. All rights reserved 2-1 Chapter 2 Principles of Programming & Software Engineering.
Code Correctness, Readability, Maintainability Svetlin Nakov Telerik Corporation
Unit-V -SOFTWARE QUALITY. To develop and deliver robust system, we need a high level of confidence that Each component will behave correctly Collective.
Acceptance Testing. What Is Acceptance Testing Customers write acceptance tests to determine if the system is doing the right things. Acceptance tests.
ANU COMP2110 Software Design in 2003 Lecture 10Slide 1 COMP2110 Software Design in 2004 Lecture 12 Documenting Detailed Design How to write down detailed.
Test Driven Development An approach to writing better code Jimmy Zimmerman Intel Corporation.
(1) Test Driven Development Philip Johnson Collaborative Software Development Laboratory Information and Computer Sciences University of Hawaii Honolulu.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
Test Driven Development Derived from Dr. Fawcett’s notes Phil Pratt-Szeliga Fall 2009.
1 Chapter 1 Software and Software Engineering Software Engineering: A Practitioner’s Approach, 6th edition by Roger S. Pressman.
Lecture 2 1 Introduction to Software Engineering.
Classification & Your Intranet: From Chaos to Control Susan Stearns Inmagic, Inc. E-Libraries E204 May, 2003.
Design Model Lecture p6 T120B pavasario sem.
1 Curriculum Renewal Part I Developing a Dynamic Curriculum Renewal Process Modify File name here using "Insert" "Header and Footer": Format is Full_File_Name_Updated_2013.XX.XX.
16-1 Copyright © 2015 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.
CS223: Software Engineering Lecture 4: Software Development Models.
Chapter 7 The Practices: dX. 2 Outline Iterative Development Iterative Development Planning Planning Organizing the Iterations into Management Phases.
Well-behaved objects Improving your coding skills 1.0.
Eclipse as a Teaching Platform for Kenya Student: Thomas Timbul (MEng 4) Supervised by: Robert Chatley.
Clean Code “Keep it Clean, Your Mother Doesn’t Work Here”“Keep it Clean, Your Mother Doesn’t Work Here” William PenberthyWilliam Penberthy Application.
Design and Programming Chapter 7 Applied Software Project Management, Stellman & Greene See also:
Design by Contract. Design by contract is the process of developing software based on the notion of contracts between objects, which are expressed as.
Component Technology. Challenges Facing the Software Industry Today’s applications are large & complex – time consuming to develop, difficult and costly.
Annoucements Next labs 9 and 10 are paired for everyone. So don’t miss the lab. There is a review session for the quiz on Monday, November 4, at 8:00.
© 2007 Pearson Education, Inc. Publishing as Pearson Addison-Wesley 1 Detailed Design Overview and Mid-Level Class Modeling.
SoftwareEngineering Foundations of Computer Science Cengage Learning.
Testing. Have you contacted your project members lately?
Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University 1 Pittsburgh, PA Dennis Smith, David Carney and Ed Morris DEAS.
Chapter 38 Persistence Framework with Patterns 1CS6359 Fall 2011 John Cole.
Chapter 1 An Overview of Computers and Programming Languages.
1 Introduction to Software Engineering Lecture 1.
© Janice Regan, CMPT 102, Sept CMPT 102 Introduction to Scientific Computer Programming The software development method algorithms.
© 2017 SlidePlayer.com Inc. All rights reserved.