archive-org.com » ORG » J » JEFFSUTHERLAND.ORG

Total: 379

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • OOPSLA'95 Workshop: Business Object Design and Implementation I
    gate net Glenn Hollowell glenn hollowell sematech org Joaquin Miller jmiller shl com Dilip Patel dilip vax sbu ac uk Submissions Tony Bailetti and J R Callahan Carleton University Cory Casanave Data Access Corporation Tom Digre Texas Instruments Michael Gorman ANSI X3H2 SQL Database Technical Committee Thomas Grotehen and Rene Schwarb Swiss Bank Corporation SYSTOR William Hertha Canadian Imperial Bank of Commerce Rainer Kossmann Bell Northern Research Ltd William E McCarthy Michigan State University Bruce Miner Koba Software Inc St eacute phane Poirier and Colin Ashford Bell Northern Research Ltd Guus Ramackers Oracle Corporation Ken Schwaber Advanced Development Methods Seldon L Stewart and James A St Pierre NIST Gerald D Zincke GMO Austria Date Monday October 16 1995 E Mail jeff sutherland computer org Call for Participation The goal of this workshop is to facilitate development of design patterns and frameworks for building business object systems A common business object infrastructure is essential to an object oriented software platform that enables systematic reuse of components across an enterprise Of particular concern is the infrastructure required for supporting domain specific business object models At a recent Object Management Group meeting the Business Object Managment SIG outlined three layers of object technology for standardization Distributed object layer CORBA OLE COM Infrastructure layer Business Object type Business Process Object and Business Entity Object subtypes generic functionality subtypes of Business Process Objects generic data specification subtypes of Business Entity Objects Domain specific layer Customer or Part as subtype of generic functionality object Order as subtype of generic data specification object Domain specific application frameworks will need to have a consistent infrastructure to be widely used within and across industries The concepts for this infrastructure are just beginning to emerge as standards for the distributed object layer are stabilized by the Object Management Group and individual software vendors This Workshop is jointly sponsored by the ANSI X3H7 Object Information Management Technical Committee and OMG BOMSIG An objective of X3H7 is to harmonize emerging object model standards in order to facilitate industry acceptance and utilization of object technology The Committee is currently working on an ISO RM ODP Companion Standard for Business Object Modeling which offers a pathway for the OMG Business OMG BOMSIG to move business object standards through the ISO accredited standards process This workshop will impact the work of ANSI Committees X3H7 X3T3 and X3J21 and OMG BOMSIG Topics of Interest The specification of a business object Do we need a large grained object design pattern How do we identify a business object discriminating tests What design techniques are useful for business object modeling What is the relation of business process reengineering to business objects How do we enhance reuse What application frameworks are already available How will business objects communicate Be distributed Interoperate How do we version business objects Make them persistent What about dynamic evolution of business objects How should transactions be handled Where do we put business rules Control structures Presentation Shared data How do business objects interface with legacy

    Original URL path: http://jeffsutherland.org/oopsla/oo95wrkf.html (2016-04-27)
    Open archived version from archive

  • Business Object Design and Implementation II
    of Reusable Object Oriented Software What are components How should they be specified Visualized What common components should be implemented to support multiple application domains Are there common design patterns that cross domains How can these components be assembled into domain specific frameworks What are appropriate architectures mechanisms for implementing these frameworks as distributed object systems What organizational and development process issues need to be addressed to successfully deliver these systems Is this approach an effective means for deploying enterprise application solutions What actual distributed object systems of this nature exist today in production Impact of the Intranet To say that there has been an explosive uptake of the Internet or the WWW would be an understatement However simultaneously there has been a parallel interest in the Intranet or the EWW Enterprise Wide Web Most corporations make extensive use of this facility for a number of reasons This culture provides an ideal environment conducive to business object design and implementation The Intranet can be used to deliver software and up dates immediately to users across the corporate network This will gain momentum as new technologies such as Java become more widely available and allows the creation and distribution of objects What issues are raised by the Intranet or Internet for design implementation and distribution of Business Object Components Publication of Workshop Proceedings It is anticipated as in the 1995 Business Object Workshop that papers will be published as a book by Springer Verlag through a review and revision process during and after the Workshop Submission Prospective participants are solicited to submit a 2 3 page position paper or experience report preferably in Word or RTF format by e mail to jeff sutherland idx com no later than August 15 1996 All submissions must include the full contact information of at least one author Position papers will be converted to HTML and placed on the World Wide Web for review see Business Object Workshop I Attendance Attendance to the workshop is limited to facilitate lively discussions and the exchange of ideas Participation will be by invitation only based on the organizing committee s evaluation of the submissions Accepted participants will be notified in September 1996 Agenda The successful and intensive process used for Business Object Workshop I will be used in Workshop II Papers will be presented in 15 minute segments followed by a 10 minute question and answer period throughout the day Approximately 12 papers will be presented Order of presentation will be in reverse order of interest level generated by World Wide Web hits on the position paper There will be a summary and conclusions session at the end of the day Instruction for submission and review of papers for publication by Springer Verlag will be presented Position papers submitted but not presented may still be published via the review process after the Workshop Background The Second Annual OOPSLA Workshop on Business Object Design and Implementation is jointly sponsored by the Accredited Standards Committee X3H7 Object Information Management Technical

    Original URL path: http://jeffsutherland.org/oopsla96/index.html (2016-04-27)
    Open archived version from archive

  • OOPSLA'97 Business Object Design and Implementation III
    of interoperable plug and play distributed Business Object components Clarify the design and implementation of object oriented workflow systems particularly systems in which workflow is an inherent part of a larger architecture rather than an addon Assess the emerging standards for component design particularly responses to the OMG Business Object Domain Task Force RFP on a Business Object Facility and Common Business Objects Contribute to emerging architectures for business object component design for Intranet Internet applications particularly those applications that integrate business objects web servers object and relational databases and new approaches to client delivery of content Results from 1995 Business Object Workshop I The 1995 workshop led to a consensus on several important issues In the future cycle time will be the most critical issue for business operations Products and services will be increasingly supported by software components Most of these components must be reused from previous development efforts in order to meet required cycle times A radical reversal in the current approach to software engineering is required to meet market demands In the future Business Process Reengineering methods will be tightly coupled with object oriented analysis and design System components will be loosely coupled to support plug and play Advances in the software development process are required to dramatically improve productivity in a component based development environment Component based architectures will be built from replaceable units of functionality that reduce the surface area of systems that are doubling in complexity each year There are specific design patterns that should be implemented throughout business systems that will substantially improve reusability and rigor in business systems logic The Give Take pattern that has been standardized by accounting research should be rigorously implemented in all business systems and mandated in all accounting systems Results from 1996 Business Object Workshop II Building on the experience of the 1995 Business Object Workshop consensus was extended in the following areas Analysis patterns can be of enormous benefit Participants in the Workshop viewed patterns as the best way to introduce high quality analysis and design artifacts into the development environment This is because they are design ideas not prescriptions and are more readily adopted by developers The general consensus was that patterns should precede standardization of object frameworks The OMG Business Object Facility may be the next place to standardize as this will be a very generic set of patterns It is better to buy than to build The current Workflow Coalition WFC standard is not suitable for OMG standardization The REA Accounting Pattern should be implemented as a prototype for the next workshop Interconnectivity between Business Object components is needed Issues worthy of further discussion Year 2000 is a major issue Expect 10 of systems worldwide to fail Electronic Data Interchange is worthy of strong support as a strategy for reduction of costs and integration of systems across enterprises Focus of This Year s Workshop The OMG Business Object Domain Task Force has issued an RFP on Common Business Objects and Business Object Facility

    Original URL path: http://jeffsutherland.org/oopsla97/index.html (2016-04-27)
    Open archived version from archive

  • OOPSLA'98 Business Object Workshop IV

    (No additional info available in detailed archive for this subpage)
    Original URL path: /oopsla98/index.html (2016-04-27)


  • OOPSLA'98 Business Object Workshop IV

    (No additional info available in detailed archive for this subpage)
    Original URL path: /oopsla99/index.html (2016-04-27)


  • OOPSLA 2000 XML, Processes and Objects Symposium (XPO)
    30 am 12 00 noon Next Generation Workflow Processes Products Standards and Research Chair Fred Cummins EDS Over the past several years message queuing and XML have emerged as key elements for the integration of enterprise applications Recently these technologies have been extended to business to business electronic commerce These transfers of information represent links in enterprise and inter enterprise business processes Workflow management supported by industry standards will extend these technologies to provide greater flexibility control and automation of business processes This session will explore these frontiers of workflow management XML in Workflow Fred Cummins EDS PDF IE DARPA Agent Markup Language DAML Paul Kogut Lockheed Martin 1 30 pm 3 00 pm Portability and Interoperability Across Internet Marketplaces Chair Matthew Fuchs CommerceOne One of the strongest growth areas among E Business applications is the B2B Marketplace XML interfaces have made it possible for multiple customers and suppliers to trade online However one of the serious roadblocks to the future growth of E Business is the incompatibility between the XML messages and workflow processes supported by marketplace vendors This session will provide the latest information on attempts to overcome this problem by vendors to the automotive manufacturers and other vertical industries There will also be a presentation on the status of XML based business message standards across marketplaces Interoperability Across Marketplaces Mary Loomis CommerceOne PDF IE B2B and M2M Connectivity and Emerging Dynamic eCommerce Daniel M Dias IBM PDF XML Standards for Business Messages David Connelly Open Applications Group PDF IE 3 30 5 00 pm Simple Object Access Protocol SOAP Alternate Viewpoints Chair Jeff Sutherland VIRTMED Corp The Simple Object Access Protocol SOAP is a new application to application communication transport based on XML over HTTP Several leading analysts have predicted that SOAP will be one of the

    Original URL path: http://jeffsutherland.org/oopsla2000/xpo/index.html (2016-04-27)
    Open archived version from archive

  • A Case study in Application Integration
    be called at a certain point in time etc Client applications register on events with the engine to tell them when there is work for them to do Each client has a specific role that determines for which activities it receives events The history and analysis component keeps track of the current state of all processes in order to determine what happens next to be able to recover in case of a failure and for auditing reasons Conductor also provides a graphical tool that allows developers to draw the process description as a set of activities connected by lines that represent the flow of control Control flow design is supported by features like recursion routing rules triggers and timers In our architecture we use the conductor workflow engine to interact with the backoffice and frontoffice through adapters The details about these adapters are explained in the next section 3 3 Adapters By using intelligent adapters i adapters all details about the interaction of the workflow system with other applications are kept out of the workflow layer Each separate system that interacts with the workflow engine requires a specific adapter An adapter logs in on the conductor engine with a dedicated role The role links the adapter to the process engine and makes sure that the adapter only receives tasks the underlying application can handle The adapters can be divided in two categories backoffice and frontoffice adapters 3 3 1 Backoffice adapter As shown in figure 2 a backoffice adapter consist of a robotic client an integration workflow MQSeries Integrator and the MQSeries messaging service 4 A backoffice adapter is coupled to the workflow system through a robotic client RBC The coupling is based on a contract that defines a complete XML interface for the services offered by the backoffice application The contract defines the input parameters the output parameters and possible exceptions It fulfills a central role in the integration architecture Without an agreement on the structure and content of the XML messages an unambiguous communication would not be possible The robotic client automatically receives tasks from the workflow engine whenever they become available All information needed to call the specific service in the backoffice is supplied by the workflow engine as an XML message The robotic client will validate the ingoing and outgoing messages against the contract so errors are discovered early in the processing If the message is valid the robotic client will start a specific activity like for example retrieving customer information from the backoffice application The operation that the robotic client wants to execute on the backoffice requires itself a sequence of steps that are modeled as a workflow the integration workflow This workflow typically deals with issues like error handling but it could also be used to extend the functionality of the backoffice application As before the integration workflow will delegate operations to robotic clients but in this case the operations are such that they can be executed directly on the backoffice i e they

    Original URL path: http://jeffsutherland.org/oopsla2000/hoeymissen/hoeymissen.htm (2016-04-27)
    Open archived version from archive

  • Business Object Components
    componentry and business objects Various attempts to dispel syntactic class fragility have been made Some of these such as the run time method dispatch of Smalltalk 80 Brad Cox Software ICs 26 or IBM s SOM System Object Model 27 only provide partial solutions and in doing so incur a more or less serious performance penalty to boot In the Java Virtual Machine JVM syntactic fragility is avoided by suspending 1 name re so lu tion to link time which happens either at load time or at run time and 2 the deter mi na tion of the storage layout of ob jects to run time 28 Un for tu nate ly the con sider able load time run time per form ance penalty implied by this approach will have to be paid afresh every time a Java pro gramme is exe cuted and will grow con sider ably worse with code size and code com plexity 29 The success of Java is largely a con sequence of the security benefits of the virtual machine approach for the not very performance critical browser based execution of code snippets down loaded over the Internet On the other hand if the JVM approach is abandoned for com pi la tion to native code as is often sug gested when the per form ance problems of Java are de bated or performance critical application areas such as web server or embedded systems programming are considered syn tactic fragility will ne cessarily re appear Microsoft s COM Compo nent Object Model eschews syn tactic fragility through the convention that published COM inter faces must be im mut able 30 Finally Newi s co operative business ob jects 31 which rely on semantic messaging for intercom munica tion are not liable to syn tactic fragility at all since dispatch is made dyna mi cal ly at message time in a message loop Although this kind of semantic messag ing is much slower than ordinary method calls the granularity of Newi s busi ness objects will en sure that inter object messaging will be comparatively rare primarily hap pen ing due to direct user inter action 32 Notably both COM and Newi introduce a layered programming model where inter com po nent calls differ significantly from intra com po nent calls This two layered approach allows both these technologies to pro vide language inde pen dence through the definition of a binary interface at the upper component business object echelon 2 3 Semantic Fragility Semantic fragility is much more elusive in nature than its syntactic sibling as it arises from evo lu tionary changes not to the interface of a class but to its im ple mentation It may show up when ever a new version of a base class from which sub classes have been derived through im plementa tion in herit ance is introduced pro vided the base class makes a direct or in di rect poly morphic self re cursive down call Since every poly morphic self call may po ten tially be resolved into a down call we can just as well say that the problem is latently overhanging in any class that makes at least one poly morphic self call In addition it may show up upon revision of a base class the in stance data of which are directly accessed from a sub class Mikhajlov and Se ke rinski who have investi gated this pro blem at length dis cern five dis tinct cases of it some of which are quite in volved 33 These cases will not need to be retold here the bottom line is that whenever a base class is revised any unmodified code taking advantage of the base class through subclassing may unexpectedly start to malfunction although care has been taken to en sure that the modifications in the base class will be entirely behaviour preserving 34 This will cause a breakdown of release to release semantic com pati bility and will compel subclass programmers to get access to and analyse the source code of base classes Just like the lack of release to release binary com pati bility this will of course seriously undermine the software componentry and business objects visions Since implementation inheritance is a crucial feature of object oriented languages and these languages eo ipso are liable to semantic fragility the problem has attracted con siderable attention by researchers Two kinds of countermeasures against se mantic fragility that have been suggested are to discipline implementation inheritance by the establish ment of a set of rules to abandon implementation inheritance alto gether The former avenue which has been dealt with in a number of research papers seems to lead up to awkward and byzantine schemes that will force pro gram mers to per form complex analyses of the source code inter de pen dencies of methods method group ings self calls etc 35 Further more these schemes presume that the subclass pro gram mer has access to the source code of super classes which will be highly unde sir able in com po nent business objects scenarios The latter avenue of forgoing imple men tation in heritance altogether taken for instance in Microsoft s COM will raise the hackles of many ad vocates of ob ject orientation accustomed to the reliance on inheritance as a handy ex tensi bility mechanism 3 Encapsulated Programming and Business Objects Elsewhere we have suggested that the clash of ob ject orienta tion and com po nent orienta tion can be resolved through en cap sulated pro gram ming a new programming style designed so as to be im pervious to all kinds of class fragility while still re tain ing sup port for a restricted dis ciplined form of im ple men tation in herit ance 36 En cap su lated programming is based on two basic mandates Firstly syntactic fragility is to be eschewed in one way or the other be it through a semantic messaging mechanism as in Newi an interface immutability con vention as in COM or the postponement to load time run time of name lookup and of the computation of object layout as in JVM 37 Secondly semantic fragility is to be addressed through the espousal of en cap su lated in herit ance which modi fies im ple men ta tion in herit ance by banning poly morphic self re cursive down calls and direct access to superclass data 38 In our terminology an object that avoids syntactic fragility and sup ports en cap sulated inheritance is called a capsule Since in our view at least class fragility must be overcome if the visions of software compo nents and business objects are not to remain on the drawing board capsules should provide a suitable shape for the im ple mentation of components and business objects We will now try to clarify how encapsulated pro gram ming will affect business ob jects using Newi style business objects Java objects and COM components as examples We have chosen to look at Java and COM because of their current im portance on the market overt whereas Newi will be con sidered both because of its historical impact on the business object com mun ity through the writings of Oliver Sims the father of busi ness objects and because of its principal im port ance 3 1 Newi style business objects Newi s semantic messaging mecha nism effectively immunised Newi classes against syn tactic fragility although by virtue of its support for im ple mentation in herit ance and poly morphic self re cursive down calls its objects were amenable to se man tic fragility However this was some what mitigated by the fact that sub classes and clients did not have direct access to super class data Thus by removing the possi bility of sending messages to self but of course not to super from the Newi infra struc ture Newi could easily have been made to support encapsulated inheri tance and the en capsulated programming para digm 3 2 Java and JavaBeans Java code executed in the Java Vir tual Ma chine is not liable to syntactic fragility although the virtual machine approach may imply a significant performance penalty This can be countered through dy na mic linking and com pi l ing with cach ing which is a scheme that re fines the JVM approach by cach ing the linked and verified byte codes as well as any snip pets of binary code re sult ing from dynamic com pilation in a cached image that after a version control can be taken advantage of on sub sequent exe cu tion of the code 39 This approach will I believe reduce the performance pe nalty of the virtual machine approach considerably and still steer clear of syntactic fragility In order to avoid semantic fragility the Java inheritance mechanism needs an over haul so as to provide support for encapsulated in heritance Two minor measures will suf fice Firstly all data members should be made private thus one should not be al lo wed to use the access modifiers protected and public on data members Secondly poly morphic self calls of methods that are neither final nor private should be dis al lowed As the Java designers will not be likely to accept such bold reformation of their language one may instead choose to use these rules as guidelines for the de sign of Java or JavaBeans classes intended as reusable components or business objects In this context it should be noted that encapsulated pro gramming clashes with the workings of white box frameworks which tend to make heavy use of polymorphic down calls in accordance with the so called Hollywood principle don t call us we call you Although certainly controversial giving up the current frame work reliance of the ob ject oriented approach appears to us a both necessary and highly bene ficial step In our experience the chief cause for the low productivity and steep learn ing curves of object oriented pro grammers as compared to developers that work with com po nent based RAD tools stems from the reliance on appli cation frame works which have an extremely high surface area 40 and thus are very dif ficult to master and use Application frameworks also violate funda mental prin ciples of soft ware engineer ing such as en cap sulation infor ma tion hiding and the mi ni misation of cross module coupling and thus tend to breed code complexity undermine main taina bility and create dangerously tight couplings between appli cation code and frame works 41 The Java approach is however highly framework oriented and the thickets of frame works surrounding the Java language tend to grow increasingly dense every day For the Java programmer it will not be a realistic option to dispense with all these frameworks He can however use a two layer strategy to mitigate the problems by abiding by the prin ciples of encapsulated pro gram ming in Java and JavaBeans classes in tended as re usable components or business objects while still taking ad vantage of the Java frame works internally in these 3 3 COM COM is already immune both to syntactic and to se man tic fragility but lacks sup port for implementation inheritance It seems that COM would gain much by getting support for a simple to use extension mechanism such as encapsulated in herit ance since the extension mechanisms presently available to the COM programmer dele ga tion and aggregation tend to be both un wieldy and difficult to use correctly 42 4 Conclusions If business objects are to be objects in the object oriented sense and also capable of being used as plug and play com po nents the problems of class fragility caused by the flawed in herit ance mechanism of today s ob ject oriented approach must be addressed We have argued that the fragility problems can be ex punged through the adoption of en cap su lated pro gramming and outlined how techno logies such as Newi Java and COM can be modified so as to adhere to this style Business objects being software representations of the things and entities of the real world will need to be much more large grained and flexible than the ordinary objects of object oriented programming Although the Newi product now seems to have faded out of sight in the hands of SSA I believe that Newi style large granular directly user mani pul able com po nents interoperating through se mantic messaging as envisioned by Oliver Sims in his first book 43 still hold great promise as the proper shape for busi ness ob jects in particular if modified according to the lines suggested above For one thing various on going de ve lop ments such as the rise of XML and SOAP and the possibly im mi nent arrival of 3 D user interfaces may make for a better apprecia tion of this vision of busi ness objects By re liance not on proprietary niche technology but on the rapidly matur ing COM Java or CORBA techno logy com pages as infra structural under pin nings such business ob jects should be able to gain in attractiveness in the market place In the Panopeus project of which this essay is a spin off I am cur rent ly in the pro cess of de ve lop ing and ex ploring the agenda of realistic com puting on the basis of this kind of large grained business objects semantic messaging 3 D user interface techno logy and en cap sulated programming 44 5 Acknowledgements This research has been supported by Crafoordska stiftelsen and Helge Ax son John sons stiftelse 6 References Berr95 G Berrisford How the Fuzziness of the Real World Limits Reuse by Inheritance between Bu si ness Objects in J Murphy B Stone eds OOIS 95 1995 International Con fer ence on Object Oriented Information Systems Proceedings Springer Verlag 1996 pp 3 18 Betz94 M Betz Interoperable Objects Dr Dobb s Journal October 1994 pp 18 39 BM98 J Bosch S Mitchell eds Object Oriented Technology ECOOP 97 Workshop Reader ECOOP 97 Workshops Jyväskylä Finland June 1997 Proceedings Lecture Notes in Computer Science 1357 Springer Verlag 1998 BMMB99 J Bosch P Molin M Mattsson P O Bengtsson Object Oriented Frameworks Problems Experiences in FSJ99 pp 55 82 see also see http www ipd hk r se bosch papers ex frame ps Booc87 G Booch Software Components with Ada Benjamin Cum mings 1987 Booc94 G Booch Object Oriented Analysis and Design 2 nd ed Addison Wesley 1994 Broc95 K Brockschmidt Inside OLE 2 nd ed Microsoft Press 1995 Chap96 D Chappell Understanding ActiveX and OLE A Guide for Developers Managers Micro soft Press 1996 CN91 B Cox A J Novobilski Object Oriented Programming An Evolutionary Approach 2 nd ed Addison Wesley 1991 Coll95 D Collins Designing Object Oriented User Interfaces Benjamin Cummings 1995 Cook89 S Cook ed ECOOP 89 Proceedings of the Third European Conference on Object Oriented Programming British Computer Society Workshop Series Cambridge University Press 1989 Cox86 B J Cox Object Oriented Programming An Evolutionary Approach Addison Wesley 1986 CV65 F J Corbató V A Vyssotsky Introduction and Overview of the Multics System in AFIPS Conference Proceedings of the 1965 Fall Joint Computer Conference AFIPS Press 1965 pp 185 196 CW85 L Cardelli P Wegner On Understanding Types Data Abstraction and Polymorphism Com puting Surveys Vol 17 No 4 December 1985 pp 471 522 DLS97 K De Hondt C Lucas P Steyaert Reuse Contracts as Component Interface Descriptions in WBS97 pp 43 49 and BM98 pp 338 342 DN66 O J Dahl K Nygaard SIMULA An Algol Based Simula tion Language Communications of the ACM Vol 9 No 9 pp 671 678 1966 Duga94 B Dugan Simula and Smalltalk A Social and Political History 1994 see http www cs washington edu homes brd history html FCDR95 I R Forman M H Conner S H Danforth L K Raper Release to Release Binary Com patibility in SOM in OOPSLA 95 Tenth Annual Conference on Object Oriented Pro gram ming Systems Languages and Applications ACM SIGPLAN Notices Vol 30 No 10 October 1995 pp 426 438 Fran97 M Franz Dynamic Linking of Software Components Computer March 1997 pp 74 81 see also http dlib computer org co books co1997 pdf r3074 pdf Free87 P Freeman ed Tutorial Software Reusability IEEE Computer Society Press 1987 FSJ99 M E Fayad D C Schmidt R E Johnson eds Building Application Frameworks John Wiley Sons 1999 GHJV94 E Gamma R Helm R Johnson J Vlissides Design Patterns Elements of Reusable Object Oriented Software Addison Wesley 1996 GJS96 J Gosling B Joy G Steele The Java Language Specification Addison Wesley 1996 see also ftp ftp javasoft com docs specs langspec 1 0 pdf GM96 J Gosling H McGilton The Java Language Environ ment A White Paper May 1996 see http java sun com docs white langenv GR83 A Goldberg D Robson Smalltalk 80 The Language and its Implementation Addison Wesley 1983 Hami97 J Hamilton Programming with DirectToSOM C John Wiley Sons 1997 Hauc93 F Hauck Inheritance Modeled with Explicit Bindings in OOPSLA 93 Eight Annual Conference on Object Oriented Pro gramming Systems Languages and Applications ACM SIG PLAN Notices Vol 28 No 10 October 1993 pp 231 239 Ichb83 J D Ichbiah On the Design of Ada in R E A Mason ed Information Processing 83 Proceedings of the IFIP 9 th World Computer Congress Paris France September 19 23 1983 IFIP Congress Series Volume 9 Participants Edi tion North Holland 1983 reprinted in Free87 pp 59 68 Jell97 T Jell ed CUC96 Component Based Software Engineering SIGS Books 1997 JF88 R E Johnson B Foote Designing Reuseable Classes Journal of Object Oriented Pro gramming Vol 1 No 2 June July 1988 pp 22 35 Kay93 A C Kay The Early History of Smalltalk

    Original URL path: http://jeffsutherland.org/oopsla2000/persson/persson.htm (2016-04-27)
    Open archived version from archive



  •