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'96 Controlled Chaos : Living on the Edge
    Small working teams that maximize communication minimize overhead and maximize sharing of tacit informal knowledge Adaptability to technical or marketplace user customer changes to ensure the best possible product is produced Frequent builds or construction of executables that can be inspected adjusted tested documented and built on Partitioning of work and team assignments into clean low coupling partitions or packets Constant testing and documentation of a product as it is built Ability to declare a product done whenever required because the competition just shipped because the company needs the cash because the user customer needs the functions because that was when it was promised Scrum and empirical development are recommended as enabling processes for developing new software or software that already is object oriented or has clean interfaces Work objects or subsystems with high cohesion and low coupling are grouped into packets Teams are assigned one or more packets maximizing a team s ability to work independently Scrum is applicable for any size project Applicable to Small Simple and Large Complex Software Systems Prior to Scrum large complex systems had to be built using either a waterfall or modified waterfall processes A defined stepwise approach provided task level controls for managing the process However many of these projects failed because they were unresponsive to changing technology and user requirements and the adequacy of the deliverables from the tasks couldn t be determined A Scrum software project is controlled by establishing maintaining and monitoring key measurements as controls These controls replace task and time reporting controls used in the waterfall and other defined development processes These controls are critical when a software development project is viewed as an empirical process that encompasses an unknown quantity of instability and unpredictability Use of these controls is the backbone of the Scrum development process Through the formalized controls of Scrum the empirical development process becomes formally scaleable Using an initial systems architecture and design work can be partitioned and assigned to as many teams as required and managed at the team and rollup levels Overall and team risk workload problems and other measurements are always known assessed and managed During the design and system architecture phase of Scrum the designers and architects divide the project into packets Packets are assigned to teams based on priority and scheduling constraints Based on the degree of coupling between packets groups of up to six teams are organized into a management control cluster This continues upwards until a top level cluster has been created Empirical software development has been used to build systems as large as Windows NT approximately 4 million lines of C and C code and the Norfolk Southern Railway freight tracking system Empirical software development has also been used to rapidly get sophisticated functionally rich products to market such as Borland s Quattro Pro for Windows and Advanced Development Method s process management software MATE approximately 4 100 function points Scrum has also been used for short simple development projects Scrum Productivity Compared to other development processes Scrum delivers Scrum was compared to other popular development processes by Capers Jones from Software Productivity Group Scrum methodology similar to the iterative methodology but assumes that all requirements are not known in advance and that the fastest path to surfacing and implementing all requirements will be discovered empirically during the development process Careful control mechanisms are used to assure on time delivery of a high quality product while allowing maximum flexibility of small tightly coupled development teams Requires a well motivated team and good leadership to implement effectively Productivity gains of 600 have been seen repeatedly in well executed projects The Inner Workings of Scrum Scrum consists of development processes and measurements that are used to control the development processes The key to the success of Scrum is using measurements to maximize flexibility and risk while maintaining control Most projects try to avoid risk Yet risk is an inherent part of software development Scrum embraces risk by identifying and managing risk so that the best possible product can be built A Scrum software project is controlled by establishing maintaining and monitoring key control parameters These controls are critical when a software development encompasses an unknown quantity of uncertainty unpredictable behavior and chaos Use of these controls is the backbone of the Scrum development process The variables in the systems development project are risk functionality cost time and quality These variables can be roughly estimated at the start of a project Each variable will start changing from the moment the project starts Variables are traded off against each other as the project progresses improved functionality for later time and more money etc The controls used in Scrum are Backlog an identification of all requirements that should be fulfilled in the completed product Objects Components self contained reusable things Packets a group of objects within which a backlog item will be implemented Coupling between the objects in a packet is high Coupling between packets is low Problems what must be solved by a team member to implement a backlog item within an object s includes bugs Issues Concerns that must be resolved prior to a backlog item being assigned to a packet or a problem being solved by a change to a packet Solutions the resolution of an issue or problem Changes the activities that are performed to resolve a problem Risks the risk associated with a problem issue or backlog item These controls are measured correlated and tracked The main controls are backlog and risk Backlog should start relatively high get higher during planning and then be whittled away as the project proceeds either by being solved or removed until the software is completed Risk will rise with the identification of backlog issues and problems and fall to acceptable levels when the software is complete and delivered The Scrum methodology consists of three distinct processes Planning and System Architecture Product functionality and estimated delivery requirement are planned based on current backlog and assessed risk The result of this

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


  • OOPSLA'96 The Evolution of Enterprise Information Systems
    the jurors Lewis Carroll Alice s Adventures in Wonderland Business patterns are powerful high level constructs that provide a natural and well structured way of both understanding and specifying businesses and their rules To be of use business specifications have to be presented in an abstract and precise manner and this paper shows how to do just that Key concepts include business invariants and operations and a higher level notion of business pattern Specification built in this way can be parameterized and reused in various business contexts Business patterns in particular promise to be extremely helpful as a basis for systematic businesss analysis and subsequent implementation of the results of the analysis We have successfully used these concepts and constructs in our engagements with insurance customers Kilov et al 1996 The motivation for our work is to allow the production of complete rigorous business specifications understandable by both business users and system developers These specifications require rigorouse expressions of semantics that is assertions rather than loose intuitive descriptions We present different kinds of reusable and abstract specification fragments patterns such as information gathering and joint ownership Unlike typical programming constructs instantiations of business patterns are inherently interactive and so must

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

  • OOPSLA'96 Coda: OMG Rationale for Choosing the Classical Object Model
    the specifications which they and others can then implement In order to ensure that these specifications will be rapidly implemented and deployed in products OMG s rules again written by its members insist that the specifications are based on well understood technology not paper designs using new and untried design concepts OMG is not a research organisation The first version on the Object Management Architecture Guide was written during the first year of OMG s formal existence to document the architectural vision Amongst other things it contained a glossary of terms to ensure that the members technical representatives attending OMG meetings shared a common vocabulary overall technical objectives for the group and a top level architecture called the reference model This top level architecture served to identify the major components that OMG set out to specify A common middleware component enabling interaction between separate objects potentially written in different programming languages and running on separate machines The term Object Request Broker ORB was coined to name this relatively new concept The ORB is not itself an object but is instead the mechanism by which objects transparently communicate with each other A number of categories of object components that communicate with each other via the ORB including application objects and the so called Object Services that provide commonly required functions such as naming security and transactions The first technology specification solicited and then adopted by OMG in 1990 91 was naturally enough that of the Object Request Broker Because it handles all communication between all objects in an OMA compliant system the ORB implicitly defines the OMA s object model Therefore the object model laid out in the first revision of the Object Management Architecture Guide published in September 1990 and therefore pre dating the adoption of specific ORB technology was

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

  • OOPSLA'96 Integrating Java, Objects, Databases, and the Web
    software to obtain some of the benefits of Moore s Law seen in IC chip fabrication Cox 1986 Some projects have achieved major productivity benefits For example a Maintenance Management System at General Motors originally written in PL I was rewritten under EDS contract in Smalltalk and achieved a 14 1 increase in productivity of design coding and testing Taylor 1992 Detailed analysis of this project showed 92 fewer lines of code 93 fewer staff months of effort 82 less development time 92 less memory needed to run and no performance degradation While there are many isolated projects that used object technology to achieve dramatic productivity gains during the past decade this success has not translated into broad improvements across the software industry In 1995 META Group reported that despite the promise of reusable objects most IT organizations have realized a scant 10 30 productivity improvement from object technology OT Failure to achieve larger productivity gains was attributed to Data centric task oriented application development Methodologies and cultures that do not promote reusability Few linkages between BPR defined business processes and IT support initiatives Meta Group 1992 While productivity gains from object technology in recent years have been limited some companies have been able to achieve dramatic returns on investment by bringing products to market sooner with the flexibility necessary for rapid tuning of the products to meet changing market conditions For example a recent analysis of return on investment ROI from object oriented development of robotics software by Marcam Corporation showed a 56 5M return on a 6M investment Return was calculated by multiplying the value of an improvement by the estimated probability of its occurrence and dividing by the cost of the improvement The following spreadsheet was generated Software Magazine 1996 Perceived Advantage Advantage Improvement Probability of Occurrence Incremental Cost ROI Time to Market 100M 4 3M 37M Flexibility 100M 2 2M 18M Productivity 2M 8 300K 1 3M Quality 1M 9 200K 700K Other Costs 0 500K 500K Code Size 0 0 0 Reuse Requirements 0 9 10K 10K TOTAL 6M 56 5M Table 2 MARCAM Return on Investment for OO Project corrected Business Objects are designed to support a clearly defined relationship between BPR defined business processes and software implementation of these components Using an object oriented development methodology yields quick time to market and good object oriented design allows for rapid evolution of Business Objects in response to market conditions The bottom line is that object technology is a necessary but not sufficient condition for large returns on investment It must be combined with focus on delivering Business Object Components that enable fast and flexible delivery of new or enhanced products in the marketplace The Need for a Business Object Architecture As business models are renewed software architectures must be transformed A Business Object Architecture BOA is an effective solution for dynamic automation of a rapidly evolving business environment Dynamic change requires reuse of chunks of business functionality A BOA must support reusable plug compatible business components The two primary strategies now being used for implementing client server systems to support reengineering of business processes are visual 4th Generation Languages and classical object technology While both of these approaches are better than COBOL neither of them can effectively implement Business Objects Building Business Object Components A group of objects is the ideal unit of reuse These groups of objects should behave as a higher level business process and have a clearly specified business language interface Business components are encapsulated with a protocol that allows efficient communication with other objects on the network Consider a typical client server application like an order entry system This system takes a Purchase Order as input and produces a validated order as output The internals of this component should be a black box to the external world The resulting order is input for another subsystem or alternatively an exception condition is raised if the Purchase Order is not valid for processing Figure 1 An Order Entry Business Object To support plug compatible reuse a business component must be encapsulated in two directions The external world must not know anything about component internals and the internals must not know anything about external components other than allowing interested objects to register for notification of specific events or exception conditions The internals of a business component are made of other encapsulated business components For example when a Purchase Order passes through the membrane of the Order Entry business object an internal component must see it validate it look up customer information inventory availability and catalogue pricing and build an order that is consistent with business rules and procedures Each of these tasks is accomplished by embedded components many of them communicating with external data sources External databases must be encapsulated as Business Objects or reuse will not be easily achievable There must be a database access component that causes values from any kind of database to materialize as objects inside the business component Whether object oriented relational or other database access is required a set of class libraries designed to automate this interface will result in a major savings in development resources Sutherland et al 1993 An Order Entry business object will typically have multiple user interfaces A clerk may be taking the order over the phone entering purchase information validating customer records and credit data and reviewing an order for consistency and customer acceptance Other users may require different presentation screens User interfaces are difficult and time consuming to build at the code level Today much of this process can be automated They should be encapsulated as separate objects that communicate by message passing to the Order Entry object Failure to do this will limit reuse and waste valuable programmer time on laborious time consuming maintenance tasks Users should be able to create interface objects with simple object oriented tools Subsequently the programmer should be able to easily snap user interface objects onto the Order Entry object A simple Order Entry client

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

  • Business Object Management Architecture
    Modelling Approach to develop a Customer Services Framework to Enable Horizontal Reuse across Industries I Choudhry D Patel 9 30 Accounting as Romance Patterns of Unrequited Love and Incomplete Exchanges in Life and in Business Software Guido Geerts and William E McCarthy 9 45 Discussion 10 00 Session 2 Workflow Issues 10 00 Radically Distributed Supply Chain Systems R Haugen 10 15 Essential Requirements for a Workflow Standard S Paul E Park J Chaar 10 30 11 00 Break Coffee 11 00 A light distributed OO Workflow Management System for the creation of Enterprise Architecture in BPR environments M Beedle 11 15 Fitting the Workflow Management Facility into the Object Management Architecture W Schulze 11 30 Discussion 11 45 Session 3 Enterprise Architectures 11 45 Business Object Management Architecture C Marshall 12 00 1 30 Lunch 1 30 OMG BOF Update Fred Cummins 1 40 X3H7 ODP Update Joaquin Miller 1 45 Business Process and Workflow Management in an Enterprise Resource Planning Context M G Rine le Comte 2 00 EMPOWER An Object oriented Business Information Systems Framework for Learning Organisation N Phillips D Patel 2 15 Discussion 2 30 Session 4 Business Objects 2 30 Beyond Business Objects C

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

  • BOMA Business Object Management Architecture
    Diagram Establish Purpose Design Process Basic Workflow Loop Process Model Business Process Workflow Processes Resources Resource Interaction Resources Roles Processes Roles Selection of Resources Process Metamodel Design Organization Organization Roles Enterprise Metamodel Data Warehouse Ledger Business Process in Java Persistence DBMS Generated JDBC Persistence User Interfaces Generated UI Complex UI Generated HTML HTTP UI Documents Reports Generated HTML Document HTML Document Template User Help Documentation Javadoc Help Specification Views of

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

  • Reflections on Workshop and Conference
    So overcomplicating in practice in the way even Francis modifed form accepts the old three tier model Some greater revolution is surely indicated And can in fact be so much simpler Francis has nonetheless most appropriately put his finger on the heart of the elephant hidden but pulsing throughout the big beast s body as it will do ever more strongly in the future CSTs in the network centric business environment that generalize into theoretically indefinite interconnectedness but with practical interactions with all their emergent properties and entities Why some have asked have I been talking to Business Object people rather than to the OO Architecture elite There you have a nicely encapsulated answer Santanu well reminded us of the pervasive asynchronicity of that network of autonomous agents world That also corrects the impression of synchronicity that I might have created with the pulsing heart image We may further recall the common observation of how badly the conventional program centric OO architectures cater for asynchronicity Hence also my much mentioned relativistic realtime so well accommodating the diversity that Santanu also called for Riné pointing out that Workflow management systems too have become more popular lately especially with the renewed interest in business process re engineering BPR further observes that A shortcoming of first generation workflow management systems is that those systems typically are implemented as a layer on top of existing applications not at the heart of them This approach gives rise to all kinds of integration problems Well said Riné When you say Distribution can be implemented using RMI Corba and DCOM I ll assume that you really mean just implemented and not architected Workflow or activity management is indeed not an add on but must be the integrated driver and hence shaper of our applications Harel s lengthy introduction to his talk building on his state roots of course just clamoured for an integrated treatment of behaviour The systemic aspects should predominate over the narrow and distorting programming perspective But the picture has long ceased to be that of an operating system running monolithic programs Event drivenness has transformed it Cf Alan Kay s great practical legacy but also Peter Wegner s theoretical picture The dynamic picture should also encompass the ad hoc varieties of interoperation reuse through refinement and version migration all of whose provision is still so glaringly lacking from conventional architectures Such qualities cannot emerge cleanly and reliably from the island class basis of the classical object model that underlies Corba and Java etc In MACK they derive nicely from the axiomatic conceptual structure When in my latest paper I proclaimed a basis of coherence and truth it was more than a rhetorical trick it described a logical and at the same time dynamic structure I must expand the scope of my comments to the whole OOPSLA conference Jeff s Workshop last year and surrounding topical issues What about Java I would call attention to my comments on Mark Baker s BO Workshop II paper in which a year ago now I ventured this heretical prediction I expect that Java s evolution will get progressively slower and more ineffective from all the divergent tugs Eventually the various more successful Java growth directions will be seen to be merely yet more limbs of the evolutionary tree and because of their degrees of success even in the face of complexity problematic branches of the Charybdian figtree too The Sun Microsoft lawsuit with its underlying agendas has rather clinched my case For more chaos look at the JOS Java Operating System effort Read their mailing list archive to appreciate it Mere vibrancy rather than chaos Rather it too illustrates that only imperialism will win if there is an inappropriate conceptual foundation Find Java in many of my pages on Jeff s site to see various aspects of my dismissal of it as a Distributed Object Architecture And one can surely take the interest in Squeak to mean that not everyone wants to fall under Java s sway anyway Doug Lea s excellent recent paper on Design for Open Systems in Java in which Mark Baker had a hand well highlights though not necessarily meaning to do so some of the many complications that procedural language object models bring as baggage in illustration of my usual diagnosis of the confusion of algorithm time and real time The island class of conventional OO cannot but imply an agglomeration of algorithm islands as that is what conventional encapsulation demands of it But as complexity grows it is ever more impractical for such islands to be neatly unified into a coherent realtime That viewpoint too demands some overarching yet integrated realtime manager such as what has conventionally been called a Workflow system Thank you Mark Wilson whom some of you may remember from last year as my prematurely wise young friend for pointers such as to JOS and Doug Lea Meanwhile Web Java is still the hot fashion combo Mark Baker this year told us about the planned HTML to XML evolution but Sorry Mark you re just the unlucky one who seems to be the innocent bearer of news on the butts of my scorn it reminds me of RPG s evolution from a mere Report Program Generator into a would be all purpose programming language which worked though not cleanly XML will retrace that path The market s momentum will give it much life but I can t see how anyone but unconditional converts will like it for long or that anyone will do it well The Web medium has entirely the wrong shape and style Document centrism like the classical object model has an initial appeal but they are both Scyllan they cannot scale up to meet ever more complex needs The elephant is not made of skin and other parts so easily touched And Java s uniqueness goes no deeper than the capillaries We need a real Distributed Object Architecture Neither RMI nor Javaspaces help it qualify with

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

  • Instructions for Prepareation of a Camera-ready Article
    1 0 line spacing 2 Typography The editors of the proceeding recommend the use of 1 0 single line spacing However when typing complicated and mathematical text it is important to increase the space between text lines in order to prevent sub and super script fonts overlapping one another and making your printed matter illegible Title sub titles and abstract should follow the instructions However authors who wish to set off to enhance a term can do it using italic or bold style 2 1 Format Length 5000 6000 words Font size 12 points style Times Format page width 165 mm page long including footnotes 245 mm All text should be justified except title author names author s addresses figure captions table titles and table columns which should be centred 2 2 Titles and sub titles 2 2 1 The title of the paper Titles should be typed using a 18 point Times in lower case 2 2 2 The author Surname and firstname should be typed using a bold 12 point Times in lower case the full professional address should be typed using a light italic 12 point Times in lower case Please let two lines of spaces between the name and title and one line before the address 2 2 3 The abstract and the key words They should be typed between 2 horizontal lines using a light italic 12 point Times in lower case Please leave one line of space between the abstract and the keywords 2 2 4 The inter or subheadings These should be left justified and numbered using decimal numeration First level is typed using a bold 12 point Times in lower case e g 2 Typography Second level is typed using a bold italic 12 point Times in lower case e g 2 1 Format The third level is typed using a light italic 12 point Times in lower case e g 2 2 2 The author Leave a 1 line space above and a 1 line space below each inter or subheading 2 3 The footnotes They should be typed at the foot of the pages using a 10 point Times and numbered from 1 to n inside the paper separated from the main text by two lines of spaces and crowned by an horizontal line of 20mm long 2 4 Tables and illustrations Tables and illustrations should be arranged throughout the text preferably being included on the same page as they are first discussed They should have a self contained caption and be positioned in flush left alignment with the text margin 2 5 Equations Equations should be placed flush left with the text margin and should be preceded and followed by one line space If they are numbered please ensure that they are numbered consecutively Numbers should be placed in parentheses flush with the right hand margin of your text and level with the last line of the equation 2 6 References References should be collected at the end of

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



  •