DOCSLIB.ORG

Black-Box Composition of Mismatched Software Components

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Black-Box Composition of Mismatched Software Components UCAM-CL-TR-845 Technical Report ISSN 1476-2986 Number 845 Computer Laboratory Black-box composition of mismatched software components Stephen Kell December 2013 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 http://www.cl.cam.ac.uk/ c 2013 Stephen Kell This technical report is based on a dissertation submitted December 2010 by the author for the degree of Doctor of Philosophy to the University of Cambridge, Christ’s 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 Black-box composition of mismatched software components Stephen Kell Summary Software is expensive to develop. Much of that expense can be blamed on difficulties in combining, integrating or re-using separate pieces of software, and in maintaining such compositions. Conventional development tools approach composition in an inherently narrow way. Specifically, they insist on modules that are plug-compatible, meaning that they must fit together down to a very fine level of detail, and that are homogeneous, meaning that they must be written according to the same conventions and (usually) in the same programming language. In summary, modules must have matched interfaces to compose. These inflexibilities, in turn, motivate more software creation and concomitant expense: they make programming approaches based on integration and re-use unduly expensive. This means that reimplementation from scratch is often chosen in preference to adaptation of existing implementations. This dissertation presents several contributions towards lessening this problem. It centres on the design of a new special-purpose programming language, called Cake. This language is specialised to the task of describing how components having mismatched in- terfaces (i.e. not plug-compatible, and perhaps not homogeneous) may be adapted so that they compose as required. It is a language significantly more effective at captur- ing relationships between mismatched interfaces than general-purpose programming lan- guages. Firstly, we outline the language’s design, which centres on reconciling interface differences in the form high-level correspondence rules which relate different interfaces. Secondly, since Cake is designed to be a practical tool which can be a convenient and easily-integrated tool under existing development practices, we describe an implementa- tion of Cake in detail and explain how it achieves this integration. Thirdly, we evaluate Cake on real tasks: by applying it to integration tasks which have already been performed under conventional approaches, we draw meaningful comparisons demonstrating a smaller (quantitative) size of required code and lesser (qualitative) complexity of the code that is required. Finally, Cake applies to a wide range of input components; we sketch extensions to Cake which render it capable of composing components that are heterogeneous with respect to a carefully identified set of stylistic concerns which we describe in detail. Acknowledgments Research is never finished. Rather than thanking people for anything they helped me complete, I’d like to thank a lot of people without whom I either couldn’t have started or couldn’t have continued. Firstly, I thank my supervisor, David Greaves, for the keen interest he showed in my research goals, balanced with a quiet faith in letting me find out where they led. I am grateful for his patient feedback when it became time to put this dissertation together. I thank Steven Hand for letting me through the door, finding funding, and always being available to offer honest and insightful feedback. Jon Crowcroft deserves special thanks, for his boundless positivity and ability to give sound feedback at a moment’s notice. Alan Mycroft also provided generous feedback at several decisive points. I also thank Sandy Fraser for his generosity and encouragement during a valuable summer in Princeton. Certain people deserve special mention. Michael Dales, Alastair Reid and Simon Ford gave me early encouragement which, unbeknownst to them, was essential in convincing me that I could and should pursue my research ambitions. Michael Hicks appeared at a critical time; his insight and positivity were vital in keeping me going. Somewhat later, Yvonne Coady rescued me from a trough out of which I might otherwise not have emerged. My many hugely talented colleagues and friends in the Atlas Room have indulged my eccentricities on a daily basis over the years. In particular, I thank Chris Purcell, Henry Robinson, Steven Smith, Theodore Hong, Mark Williamson, Derek Murray, Nishanth Sastry, Periklis Akritidis, Chris Smowton, Malte Schwarzkopf and Malcolm Scott. I also thank all the other members of the Networks and Operating Systems group for their willingness to listen to my increasingly off-topic ideas, and the Cambridge Programming Research Group, especially Dominic Orchard, Robin Message, Max Bolingbroke and Boris Feigin, for letting me pretend to belong to their group when it suited me. Finally, a PhD student needs post-docs: Scott Owens, Kathy Gray, David Evans, David Eyers, Mike Dodds and Alan Lawrence all gave vital advice and encouragement. Vaughan Wittorff, while not a post-doc, belongs in this list too. I thank the Computer Laboratory support staff for the department’s efficiency and generous resourcing; EPSRC and Cambridge Philosophical Society for essential funding; Christ’s College, ACM SIGPLAN, ACM SIGSOFT, EuroSys and the Royal Academy of Engineering for equally essential travel funding. I also thank various constituencies of Christ’s College for enhancing my life in various ways, with special mentions to the Graduate Society, the porters and the catering staff. Finally, I thank my family and friends for their support, for providing distractions, and generally for being more important than the contents of this dissertation. ‘If we succeed in making an Intergalactic Network, then our main problem will be learning to communicate with Aliens.’ J.C.R. Licklider Contents 1 Introduction 23 1.1 Diversityandchange .............................. 23 1.2 Existingpractice ................................ 25 1.2.1 Library-baseddevelopment. 25 1.2.2 Abstractionlayers............................ 27 1.2.3 Reimplementation . 27 1.2.4 Non-implementation .......................... 28 1.2.5 Standardisation ............................. 29 1.2.6 Information hiding and modular programming . 29 1.2.7 Porting ................................. 30 1.2.8 Automatedsourcecodetransformation . 31 1.2.9 Gluecoding ............................... 31 1.3 Examining tool support for glue coding . 32 1.3.1 Aptitudes of conventional languages . 32 1.3.2 Plug-compatibility assumptions . 34 1.3.3 Homogeneityassumptions . 35 1.3.4 The separation of functionality from integration . 35 1.4 Researchapproaches .............................. 36 1.4.1 Clean-slate versus adoptable solutions . 36 1.4.2 White-box versus black-box approaches . 36 1.5 Goals....................................... 39 1.5.1 Listofgoals............................... 39 1.5.2 Non-goals ................................ 39 1.6 Thesisstatement ................................ 40 1.6.1 Stateoftheart ............................. 41 CONTENTS CONTENTS 1.7 Approach .................................... 42 1.8 Contributions .................................. 43 1.9 Technicalbackground.............................. 44 1.9.1 Challenges of C and C++ programs .................. 44 1.9.2 Tools manipulating binaries . 45 1.10 Outlineofsubsequentchapters. .. 47 2 The Cake language 49 2.1 Motivation.................................... 49 2.2 ThedesignofCake ............................... 51 2.2.1 Designapproach ............................ 52 2.2.2 High-level view . 52 2.2.3 Introducingtherunningexample . 53 2.2.4 Insights ................................. 54 2.2.5 Requirements .............................. 55 2.2.6 Characterising Cake-generated code as a transducer . .... 56 2.2.7 Toolchaincontext............................ 56 2.2.8 Syntacticconventions. 58 2.2.9 Simplecorrespondences. 58 2.2.10 RemarksonsimpleCakeusage . 59 2.2.11 Correspondences for free: name matching . .. 61 2.3 MorepowerfulfeaturesofCake . 62 2.3.1 Corresponding sequences of events: event context . .... 62 2.3.2 Generating data-dependent call sequences: stubs . .... 64 2.3.3 Practicalities . 65 2.3.4 Many-to-manyvaluecorrespondences . 68 2.3.5 Quantificationandguards . 71 2.3.6 Relating individual values . 71 2.3.7 Inputandoutputparameters . 72 2.3.8 Arraysandlists............................. 73 2.3.9 Functionpointers ............................ 74 2.3.10 Completingtheexample . 75 2.4 Semanticquestions ............................... 76 2.4.1 Component-managedstate. 76 CONTENTS CONTENTS 2.4.2 Run-timeerrors............................. 76 2.4.3 Dynamic matching and binding . 78 2.4.4 Ruleprecedence............................. 80 2.5 Summary .................................... 81 3 Limitations of the Cake language 83 3.1 Event context predicate connectives . ... 83 3.2 Cakeandclassesofformallanguage. 84 3.3 Cross-cuttinglogic ............................... 85 3.4 Callingconventions ............................... 85 3.5 Controlstructures................................ 86 3.5.1 Proceduralbias ............................. 86 3.5.2 Threadedcontrolmodels . 86 3.5.3 Blocking versus nonblocking calls . 86 3.5.4 Conversationaladaptations . 87 3.5.5 Callsequencingconstraints. 87 3.5.6 Generalisedsequencemappings
Load more

Recommended publications
  • CHERI C/C++ Programming Guide
    UCAM-CL-TR-947 Technical Report ISSN 1476-2986 Number 947 Computer Laboratory CHERI C/C++ Programming Guide Robert N. M. Watson, Alexander Richardson, Brooks Davis, John Baldwin, David Chisnall, Jessica Clarke, Nathaniel Filardo, Simon W. Moore, Edward Napierala, Peter Sewell, Peter G. Neumann June 2020 15 JJ Thomson Avenue Cambridge CB3 0FD United Kingdom phone +44 1223 763500 https://www.cl.cam.ac.uk/ c 2020 Robert N. M. Watson, Alexander Richardson, Brooks Davis, John Baldwin, David Chisnall, Jessica Clarke, Nathaniel Filardo, Simon W. Moore, Edward Napierala, Peter Sewell, Peter G. Neumann, SRI International This work was supported by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C-0237 (“CTSRD”) and HR0011-18-C-0016 (“ECATS”). The views, opinions, and/or findings contained in this report are those of the authors and should not be interpreted as representing the official views or policies of the Department of Defense or the U.S. Government. This work was supported in part by the Innovate UK project Digital Security by Design (DSbD) Technology Platform Prototype, 105694. This project has received funding from the European Research Council (ERC) under the European Union’s Horizon 2020 research and innovation programme (grant agreement No 789108), ERC Advanced Grant ELVER. We also acknowledge the EPSRC REMS Programme Grant (EP/K008528/1), Arm Limited, HP Enterprise, and Google, Inc. Approved for Public Release, Distribution Unlimited. Technical reports published by the University of Cambridge Computer Laboratory are freely available via the Internet: https://www.cl.cam.ac.uk/techreports/ ISSN 1476-2986 3 Abstract This document is a brief introduction to the CHERI C/C++ programming languages.
    [Show full text]
  • Optimizing the Use of High Performance Software Libraries
    Optimizing the Use of High Performance Software Libraries Samuel Z. Guyer and Calvin Lin The University of Texas at Austin, Austin, TX 78712 Abstract. This paper describes how the use of software libraries, which is preva- lent in high performance computing, can benefit from compiler optimizations in much the same way that conventional computer languages do. We explain how the compilation of these informal languages differs from the compilation of more conventional computer languages. In particular, such compilation requires precise pointer analysis, requires domain-specific information about the library’s seman- tics, and requires a configurable compilation scheme. Finally, we show that the combination of dataflow analysis and pattern matching form a powerful tool for performing configurable optimizations. 1 Introduction High performance computing, and scientific computing in particular, relies heavily on software libraries. Libraries are attractive because they provide an easy mechanism for reusing code. Moreover, each library typically encapsulates a particular domain of ex- pertise, such as graphics or linear algebra, and the use of such libraries allows program- mers to think at a higher level of abstraction. In many ways, libraries are simply in- formal domain-specific languages whose only syntactic construct is the procedure call. This procedural interface is significant because it couches these informal languages in a familiar form, which is less imposing than a new computer language that introduces new syntax. Unfortunately, while libraries are not viewed as languages by users, they also are not viewed as languages by compilers. With a few exceptions, compilers treat each invocation of a library routine the same as any other procedure call.
    [Show full text]
  • SSC Reference Manual SDK 2017-1-17, Version 170
    SSC Reference Manual SDK 2017-1-17, Version 170 Aron Dobos and Paul Gilman January 13, 2017 The SSC (SAM Simulation Core) software library is the collection of simu- lation modules used by the National Renewable Energy Laboratory’s System Advisor Model (SAM). The SSC application programming interface (API) al- lows software developers to integrate SAM’s modules into web and desktop applications. The API includes mechanisms to set input variable values, run simulations, and retrieve values of output variables. The SSC modules are available in pre-compiled binary dynamic libraries minimum system library de- pendencies for Windows, OS X, and Linux operating systems. The native API language is ISO-standard C, and language wrappers are available for C#, Java, MATLAB, Python, and PHP. The API and model implementations are thread- safe and reentrant, allowing the software to be used in a parallel computing environment. This document describes the SSC software architecture, modules and data types, provides code samples, introduces SDKtool, and describes the language wrappers. Contents 2 Contents 1 Overview4 1.1 Framework Description.............................. 4 1.2 Modeling an Energy System........................... 4 2 An Example: Running PVWatts5 2.1 Write the program skeleton ........................... 6 2.2 Create the data container ............................ 6 2.3 Assign values to the module input variables.................. 7 2.4 Run the module.................................. 7 2.5 Retrieve results from the data container and display them.......... 8 2.6 Cleaning up.................................... 8 2.7 Compile and run the C program ........................ 9 2.8 Some additional comments............................ 9 3 Data Variables9 3.1 Variable Names.................................. 10 3.2 Variable Types .................................
    [Show full text]
  • Pygtk 2.0 Tutorial
    PyGTK 2.0 Tutorial John Finlay October 7, 2012 PyGTK 2.0 Tutorial by John Finlay Published March 2, 2006 ii Contents 1 Introduction 1 1.1 Exploring PyGTK . .2 2 Getting Started 5 2.1 Hello World in PyGTK . .7 2.2 Theory of Signals and Callbacks . .9 2.3 Events . 10 2.4 Stepping Through Hello World . 11 3 Moving On 15 3.1 More on Signal Handlers . 15 3.2 An Upgraded Hello World . 15 4 Packing Widgets 19 4.1 Theory of Packing Boxes . 19 4.2 Details of Boxes . 20 4.3 Packing Demonstration Program . 22 4.4 Packing Using Tables . 27 4.5 Table Packing Example . 28 5 Widget Overview 31 5.1 Widget Hierarchy . 31 5.2 Widgets Without Windows . 34 6 The Button Widget 35 6.1 Normal Buttons . 35 6.2 Toggle Buttons . 38 6.3 Check Buttons . 40 6.4 Radio Buttons . 42 7 Adjustments 45 7.1 Creating an Adjustment . 45 7.2 Using Adjustments the Easy Way . 45 7.3 Adjustment Internals . 46 8 Range Widgets 49 8.1 Scrollbar Widgets . 49 8.2 Scale Widgets . 49 8.2.1 Creating a Scale Widget . 49 8.2.2 Methods and Signals (well, methods, at least) . 50 8.3 Common Range Methods . 50 8.3.1 Setting the Update Policy . 50 8.3.2 Getting and Setting Adjustments . 51 8.4 Key and Mouse Bindings . 51 8.5 Range Widget Example . 51 9 Miscellaneous Widgets 57 9.1 Labels . 57 9.2 Arrows . 60 9.3 The Tooltips Object .
    [Show full text]
  • Javascript and OOP Once Upon a Time
    11/14/18 JavaScript and OOP Once upon a time . Jerry Cain CS 106AJ November 12, 2018 slides courtesy of Eric Roberts Object-Oriented Programming The most prestigious prize in computer science, the ACM Turing Award, was given in 2002 to two Norwegian computing pioneers, who jointly developed SIMULA in 1967, which was the first language to use the object-oriented paradigm. JavaScript and OOP In addition to his work in computer Kristen Nygaard science, Kristen Nygaard also took Ole Johan Dahl an active role in making sure that computers served the interests of workers, not just their employers. In 1990, Nygaard’s social activism was recognized in the form of the Norbert Wiener Award for Social and Professional Responsibility. Review: Clients and Interfaces David Parnas on Modular Development • Libraries—along with programming abstractions at many • David Parnas is Professor of Computer other levels—can be viewed from two perspectives. Code Science at Limerick University in Ireland, that uses a library is called a client. The code for the library where he directs the Software Quality itself is called the implementation. Research LaBoratory, and has also taught at universities in Germany, Canada, and the • The point at which the client and the implementation meet is United States. called the interface, which serves as both a barrier and a communication channel: • Parnas's most influential contriBution to software engineering is his groundBreaking 1972 paper "On the criteria to be used in decomposing systems into modules," which client implementation laid the foundation for modern structured programming. This paper appears in many anthologies and is available on the web at interface http://portal.acm.org/citation.cfm?id=361623 1 11/14/18 Information Hiding Thinking About Objects Our module structure is based on the decomposition criteria known as information hiding.
    [Show full text]
  • Porting FUSE to L4re
    Großer Beleg Porting FUSE to L4Re Florian Pester 23. Mai 2013 Technische Universit¨at Dresden Fakult¨at Informatik Institut fur¨ Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann H¨artig Betreuender Mitarbeiter: Dipl.-Inf. Carsten Weinhold Erkl¨arung Hiermit erkl¨are ich, dass ich diese Arbeit selbstst¨andig erstellt und keine anderen als die angegebenen Hilfsmittel benutzt habe. Declaration I hereby declare that this thesis is a work of my own, and that only cited sources have been used. Dresden, den 23. Mai 2013 Florian Pester Contents 1. Introduction 1 2. State of the Art 3 2.1. FUSE on Linux . .3 2.1.1. FUSE Internal Communication . .4 2.2. The L4Re Virtual File System . .5 2.3. Libfs . .5 2.4. Communication and Access Control in L4Re . .6 2.5. Related Work . .6 2.5.1. FUSE . .7 2.5.2. Pass-to-Userspace Framework Filesystem . .7 3. Design 9 3.1. FUSE Server parts . 11 4. Implementation 13 4.1. Example Request handling . 13 4.2. FUSE Server . 14 4.2.1. LibfsServer . 14 4.2.2. Translator . 14 4.2.3. Requests . 15 4.2.4. RequestProvider . 15 4.2.5. Node Caching . 15 4.3. Changes to the FUSE library . 16 4.4. Libfs . 16 4.5. Block Device Server . 17 4.6. File systems . 17 5. Evaluation 19 6. Conclusion and Further Work 25 A. FUSE operations 27 B. FUSE library changes 35 C. Glossary 37 V List of Figures 2.1. The architecture of FUSE on Linux . .3 2.2. The architecture of libfs .
    [Show full text]
  • Chapter 4: PHP Fundamentals Objectives: After Reading This Chapter You Should Be Entertained and Learned: 1
    Chapter 4: PHP Fundamentals Objectives: After reading this chapter you should be entertained and learned: 1. What is PHP? 2. The Life-cycle of the PHP. 3. Why PHP? 4. Getting Started with PHP. 5. A Bit About Variables. 6. HTML Forms. 7. Building A Simple Application. 8. Programming Languages Statements Classification. 9. Program Development Life-Cycle. 10. Structured Programming. 11. Object Oriented Programming Language. 4.1 What is PHP? PHP is what is known as a Server-Side Scripting Language - which means that it is interpreted on the web server before the webpage is sent to a web browser to be displayed. This can be seen in the expanded PHP recursive acronym PHP-Hypertext Pre-processor (Created by Rasmus Lerdorf in 1995). This diagram outlines the process of how PHP interacts with a MySQL database. Originally, it is a set of Perl scripts known as the “Personal Home Page” tools. PHP 4.0 is released in June 1998 with some OO capability. The core was rewritten in 1998 for improved performance of complex applications. The core is rewritten in 1998 by Zeev and Andi and dubbed the “Zend Engine”. The engine is introduced in mid 1999 and is released with version 4.0 in May of 2000. Version 5.0 will include version 2.0 of the Zend Engine (New object model is more powerful and intuitive, Objects will no longer be passed by value; they now will be passed by reference, and Increases performance and makes OOP more attractive). Figure 4.1 The Relationship between the PHP, the Web Browser, and the MySQL DBMS 4.2 The Life-cycle of the PHP: A person using their web browser asks for a dynamic PHP webpage, the webserver has been configured to recognise the .php extension and passes the file to the PHP interpreter which in turn passes an SQL query to the MySQL server returning results for PHP to display.
    [Show full text]
  • Data Abstraction and Encapsulation ADT Example
    Data Abstraction and Encapsulation Definition: Data Encapsulation or Information Hiding is the concealing of the implementation details of a data object Data Abstraction from the outside world. Definition: Data Abstraction is the separation between and the specification of a data object and its implementation. Definition: A data type is a collection of objects and a set Encapsulation of operations that act on those objects. Definition: An abstract data type (ADT) is a data type that is organized in such a way that the specification of the objects and the specification of the operations on the objects is separated from the representation of the objects and the implementation of the operations. 1 2 Advantages of Data Abstraction and Data Encapsulation ADT Example ADT NaturalNumber is Simplification of software development objects: An ordered sub-range of the integers starting at zero and ending at the maximum integer (MAXINT) on the computer. Testing and Debugging functions: for all x, y belong to NaturalNumber; TRUE, FALSE belong to Boolean and where +, -, <, ==, and = are the usual integer operations Reusability Zero(): NaturalNumber ::= 0 Modifications to the representation of a data IsZero(x): Boolean ::= if (x == 0) IsZero = TRUE else IsZero = FALSE type Add(x, y): NaturalNumber ::= if (x+y <= MAXINT) Add = x + y else Add = MAXINT Equal(x, y): Boolean ::= if (x == y) Equal = TRUE else Equal = FALSE Successor(x): NaturalNumber ::= if (x == MAXINT) Successor = x else Successor = x +1 Substract(x, y): NaturalNumber ::= if (x <
    [Show full text]
  • Index Images Download 2006 News Crack Serial Warez Full 12 Contact
    index images download 2006 news crack serial warez full 12 contact about search spacer privacy 11 logo blog new 10 cgi-bin faq rss home img default 2005 products sitemap archives 1 09 links 01 08 06 2 07 login articles support 05 keygen article 04 03 help events archive 02 register en forum software downloads 3 security 13 category 4 content 14 main 15 press media templates services icons resources info profile 16 2004 18 docs contactus files features html 20 21 5 22 page 6 misc 19 partners 24 terms 2007 23 17 i 27 top 26 9 legal 30 banners xml 29 28 7 tools projects 25 0 user feed themes linux forums jobs business 8 video email books banner reviews view graphics research feedback pdf print ads modules 2003 company blank pub games copyright common site comments people aboutus product sports logos buttons english story image uploads 31 subscribe blogs atom gallery newsletter stats careers music pages publications technology calendar stories photos papers community data history arrow submit www s web library wiki header education go internet b in advertise spam a nav mail users Images members topics disclaimer store clear feeds c awards 2002 Default general pics dir signup solutions map News public doc de weblog index2 shop contacts fr homepage travel button pixel list viewtopic documents overview tips adclick contact_us movies wp-content catalog us p staff hardware wireless global screenshots apps online version directory mobile other advertising tech welcome admin t policy faqs link 2001 training releases space member static join health
    [Show full text]
  • A Proposal for a Revision of ISO Modula-2 2
    A Proposal for a Revision of ISO Modula-2 Benjamin Kowarsch, Modula-2 Software Foundation ∗ May 2020 (arXiv.org preprint) Abstract The Modula-2 language was first specified in [Wir78] by N. Wirth at ETH Z¨urich in 1978 and then revised several times. The last revision [Wir88] was published in 1988. The resulting language reports included ambiguities and lacked a comprehensive standard library. To resolve the ambiguities and specify a comprehensive standard library an ISO/IEC working group was formed and commenced work in 1987. A base standard was then ratified and published as IS 10514-1 in 1996 [JTC96]. Several conforming compilers have since been developed. At least five remain available of which at least three are actively maintained and one has been open sourced. Meanwhile, various deficiencies of the standard have become apparent but since its publication, no revision and no maintenance has been carried out. This paper discusses some of the deficiencies of IS 10514-1 and proposes a limited revision that could be carried out with moderate effort. The scope of the paper has been deliberately limited to the core language of the base standard and therefore excludes the standard library. 1 ISO/IEC Standardisation [II20] describes ISO/IEC standardisation procedures, summarised in brief below. 1.1 Organisational Overview The International Organisation for Standardisation (ISO) and the International Electrotechnical Commission (IEC) operate a joint technical committee (JTC1) to develop, publish and maintain information technology standards. JTC1 is organised into subcommittees (SC) and working groups (WG). The subcommittee for programming languages is JTC1/SC22. The working group that developed the ISO Modula-2 standard was JTC1/SC22/WG13.
    [Show full text]
  • C++: Data Abstraction & Classes
    Comp151 C++: Data Abstraction & Classes A Brief History of C++ • Bjarne Stroustrup of AT&T Bell Labs extended C with Simula-like classes in the early 1980s; the new language was called “C with Classes”. • C++, the successor of “C with Classes”, was designed by Stroustrup in 1986; version 2.0 was introduced in 1989. • The design of C++ was guided by three key principles: 1. The use of classes should not result in programs executing any more slowly than programs not using classes. 2. C programs should run as a subset of C++ programs. 3. No run-time inefficiency should be added to the language. Topics in Today's Lecture • Data Abstraction • Classes: Name Equivalence vs. Structural Equivalence • Classes: Restrictions on Data Members • Classes: Location of Function declarations/definitions • Classes: Member Access Control • Implementation of Class Objects Data Abstraction • Questions: – What is a ‘‘car''? – What is a ‘‘stack''? •A data abstraction is a simplified view of an object that includes only features one is interested in while hiding away the unnecessary details. • In programming languages, a data abstraction becomes an abstract data type (ADT) or a user-defined type. • In OOP, an ADT is implemented as a class. Example: Implement a Stack with an Array 1 data 2 3 size top . Example: Implement a Stack with a Linked List top -999 top (latest item) -999 1 2 Information Hiding •An abstract specification tells us the behavior of an object independent of its implementation. i.e. It tells us what an object does independent of how it works. • Information hiding is also known as data encapsulation, or representation independence.
    [Show full text]
  • Data Abstraction and Object-Oriented Languages; Ada Case Study
    CS323 Lecture: Data Abstraction and Object-Oriented Languages; Ada Case Study 2/4/09 Materials: Handout of Ada Demonstration Programs + Executable form (first_example, ascii_codes, rationals, stack, exception_demo, oo_demo) I. Introduction - ------------ A. As we have discussed previously, the earliest programming language paradigm (to which many languages belong) is the imperative or procedural paradigm. However, within this paradigm there have been some important developments which have led to modern languages being significantly better than older members of the same family, as well as to the development of the object-oriented paradigm. 1. One such development is "structured programming" which focussed on the control flow of programs. A major outcome of this work has been the presence, in most modern languages regardless of paradign, of certain well-defined control structures (conditional; definite and indefinite iteration). 2. A second major development has been the evolution of the idea of DATA ABSTRACTION. a. In the early days of computer science, most attention was given to algorithms and to language features to support them - e.g. procedural abstraction and control structures. b. In the late 1960's, Donald Knuth published a three volume work called "The Art of Computer Programming" which focussed attention on the fact that data structures are an equally important part of software design. i. His book is really responsible for the birth of the idea that a "Data Structures" course should be part of the CS curriculum. ii. Historically, coverage of data structures migrated from being an upper-level course in the CS major (300 level) to being a core part of the introductory sequence.
    [Show full text]