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".
  • Business Object Design and Implementation
    adequately addressed by the current product release Bugs defects customer requested enhancements competitive product functionality competitive edge functionality and technology upgrades are backlog items Release Enhancement backlog items that at that point in time represent a viable release based on the variables of requirements time quality and competition Packets Product components or objects that must be changed to implement a backlog item into a new release Scrum teams a team of several individuals responsible for implementing a set of backlog items in a new release Changes Changes that must occur to a packet to implement a backlog item Problems Problems that occur and must be solved to implement a change Issues Overall project and project issues that are not defined in terms of packets changes and problems Release Project Team The team that works on the new release includes full time developers and external parties who will be affected by the new release such as marketing sales and customers In traditional release processes these three groups are kept away from development teams for fear of over complicating the process and allowing unnecessary interference The Scrum approach however welcomes and facilitates their controlled involvement at set intervals as this increases the probability that release content and timing will be appropriate useful and marketable The following teams are formed for each new release Management Led by the Product Manager it defines initial content and timing of the release then manages their evolution as the project progresses and variables manifest Management deals with backlog and issues Development teams Development teams are small with each containing equal numbers of developers documenters and quality control staff Multiple teams of between three and six people may be used Each is assigned a set of packets or objects including all backlog items related to each packet The team defines changes required to implement the backlog item in the packets and manages all problems regarding the changes Teams can be either functionally derived assigned those packets that address specific sets of product functionality or system derived assigned a specific part of the program for enhancement The members of each team are selected based on their knowledge and expertise regarding sets of packets Scrum Phases Scrum has three phases Planning Definition of a new release based on currently known backlog Development Development of the new release functionality with constant respect to the variables of time requirements quality and competition Interaction with these variables defines the end of development cycles Closure Preparation for release including final documentation pre release staged testing and release Each of the phases has the following steps Planning Development of a comprehensive backlog list Definition of the delivery date and functionality of one or more releases Selection of the release most appropriate for immediate development Mapping of product packets for backlog items in the selected release Definition of project team s for the building of the new release Review and possible adjustment of backlog items and packets Estimation of release cost including development collateral material marketing

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


  • Business Object Design and Implementation
    95052825A ENG The purpose of this project is to promote and standardize a general object oriented framework for manufacturing Business objects are a very broad class of which manufacturing objects are only a part However manufacturing plays a major role in the economy Every business is a consumer of manufactured products and many businesses are in manufacturing As a result it is important that a CIM framework be closely integrated into any larger business or enterprise framework Successful integration is based on well defined and widely accepted interfaces Thus the object oriented approach with its emphasis on interface specification is well adapted to integration Unfortunately specification of interface signatures as with CORBA IDL is only a necessary but not sufficient condition for integration to be successful The more difficult question is how to specify what an interface does without overly constraining possible implementations We suggest that this is significant problem for this workshop to address Stages of Development for a Framework In our report we defined for stages of development for a framework Developing a Specification Reaching Consensus Standardization Testing and Certification These stages are in logical order but generally their execution will overlap to a large degree Results from any one stage will feed both backwards and forwards to the other stages We also developed recommendations for how to carry out such a program While some of the recommendations are quite specific to the project at hand many can be restated for more general frameworks Here are recommendations that we believe might be applicable to a wide range of business application frameworks Adopt a single source electronic specification management approach Involve users and suppliers in both specification and certification development Give reference implementation high priority Make the interface between client and server objects neutral Reach consensus on certification business

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

  • Business Object Design and Implementation
    the business logic that is implemented as business object classes With such a definition of business objects it is more likely that they can be reused between applications The second goal was to provide an automatic mechanism to transfer business object data from a relational database into object memory and from the object memory to the screen and vice versa Many business applications do nothing more than display data from the database on the screen Complex computations are rather seldom but movement of data is quite frequent A third goal was to provide a means for manipulating large database tables It is not possible to use a Smalltalk collection to manipulate the set of all customers of a large organisation Object sets with more than a million entries are not so seldom in business data processing Design Concepts and Patterns An important design pattern implemented by the GBO framework is that of a sortable and filtered list called EntityList That is a type checked collection that can contain business objects The EntityList can be declared as persistent In that case it directly maps a table in the database Adding a new business object to it causes inserting its data into the database updating a business object that is contained in a persistent EntityList causes transparent updates on the database and removing an object causes a delete operation on the database A filter can be used in combination with an EntityList to define criteria that must hold true for all elements of the list If an EntityList does contain business objects that do not satisfy the filter condition they are excluded from any iterator operation One or more attributes of an EntityList can be declared as sorting criteria affecting the order how iteration is done There are derivations of EntityList LargeList and UnlimitedList that are especially tailored for handling large amounts of data big tables Both of them are persistent by default and provide a similar protocol to access their contents They do only keep a part of their whole set of business objects in main memory EntityLists build a convenient base for implementing scrolling windows as they are needed for typical database maintenance applications In fact the GBO Framework contains several classes that implement such scrolling windows that can be used for any business object class and for updating any database table A simple mapping mechanism eases the task to transfer business objects data to the controls of a data entry update window and back So the GBO framework provides the Smalltalk developer with 4GL like functions that allow rapid application development Compared with a traditional 4GL the framework offers the advantage that it can be enhanced and modified in any direction and does not limit the developer in any way The framework also implements the pattern of a layout The layout classes are used to produce listings on the printer A layout is a structure that defines how elements of a printout text bitmaps lines are to be placed

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

  • Business Objects
    high impact and or costly legacy applications first a smooth transition can be made Existing Business Objects Many existing applications are built or being built on the principles of business objects Any business application derived from object oriented modeling or design Any business application derived from object oriented software engineering Most business systems based on CORBA or any other distributed object framework Any application that exposes business entities as independent objects Most applications built with an object oriented framework Other than just the user interface These existing business object systems may be constructed with a custom or proprietary application framework Such systems will be very easy to convert to the BAA once it is available Businesses may want to review existing applications and development projects to see where such techniques are being used Application built with business object methods can be expected to have a longer life and shorter development cycle than other applications due to their use of object design an implementation techniques such as encapsulation and polymorphism The OMG BOMSIG is surveying such existing systems we hope businesses will provide us with information on theirs Please contact the OMG BOMSIG for a copy of the survey questionnaire Note that there is no direct correlation between using an object oriented language and building a business object system Many business object systems have been implemented in procedural languages and unfortunately object oriented languages have been used to implement non object oriented designs An object oriented language makes it easier and more natural to build business objects but it is not required What Is the OMG Business Application Architecture The OMG Business Application Architecture BAA represents an application architecture and a protocol for cooperative business The BAA together with an appropriate implementation will provide a architecture in which business object attributes relationships business rules and application rules can be implemented Objects implemented in this way will then be interoperable with other business objects All information systems have an architecture That architecture may be formalized and structured or it may be informal and implied But for a system to operate there must be agreed to conventions structures and protocols this is the architecture Most application development systems combine an application architecture with tools and sometimes a language to help implement that architecture The architecture becomes part of the way you use the system The application architecture can be thought of as that layer between the high level business objects being implemented and the low level languages operating systems object request brokers and DBMS systems As part of the architecture a protocol exists for the components of that architecture to interact For the architecture to be standardized the interfaces must be defined Within OMG interfaces are defined in IDL The BAA is not a standard business model it does not attempt to specify the standard or common components object structures or processes in a business It is a standard way to represent any business model as a structure of objects How Does the BAA Fit with Tools and Languages The business application architecture does not attempt to specify the correct or best method for implementing business objects Any combination of computer languages 4GLs design tools frameworks rule based systems and expert systems may be employed to create the business object Frameworks and other forms of tools and components are anticipated as products which assist the developer or user in defining and implementing business objects that enable the business object protocol The BAA and underlying technologies provides an interoperably layer that allows these differing systems to work together It is expected that higher level interfaces will be provided so as to shield application experts from the highly technical IDL interfaces These higher level tools and frameworks will provide the BAA IDL interface standard interfaces as a package that application developers can use more easily The high level frameworks and tools will provide interfaces appropriate for directly defining business objects attributes relations and business rules In that these high level interfaces may interoperate via the BAA protocol we do not expect these interfaces to require standards Note It is possible for developers to create business objects that directly implement the BAA protocol however this protocol must expose some of the complexities inherent in a distributed object system and for this purpose implementation frameworks and intermediary components are useful in simplifying the job of the application developer However developers are free to use or extend the BAA protocol directly for special needs For support of legacy systems business object frameworks may be built for COBOL RPG II IMS and CICS While the source code for these systems would appear completely different the resultant application architecture would be the same and the objects would be interoperable How does the BAA fit with other application architectures Many applications architectures exist for both business and non business applications In that such architectures must be able to co exist with each other and the BAA the BAA must be sufficiently general to facilitate the interaction of applications with other architectures The wrapping facility previously discussed provides the capability to implement the BAA protocol in conjunction with other architectures it is not an exclusive option Thus the BAA in intended to be the interaction protocol for application components in a variety of architectures Architectures for applications outside of the business domain generally become part of the implementation of business concepts represented as business objects For example a software development company may have the source code to its application in a configuration management system using its own application architecture such as PTCE the business system may refer to a single entity which is the software project The implementation of the project business object may use the configuration management system to provide business information such as project status to the business application It is unclear at this time whether the BAA can be sufficiently general to represent ALL business applications It is our hope that other architectures can be built as extensions to the BAA as opposed to alternatives to the BAA Such a determination can only be made after further work is done in this area Advantages of OMG Business Objects and the BAA Flexibility By maintaining a simple standard interface to objects relevant to your business your information facility becomes much more flexible Changes in your business policies or structure can be reflected directly by the business objects and applications based on these will frequently adapt automatically to the changes New business objects and business structures can be developed and deployed while still maintaining the old interfaces for a cross over period Since the implementations of business objects directly reflect the structure of your business the business objects and applications are easier to produce and maintain giving you a more responsive information processing facility A single place to put your business rules The rules policies and procedures of an enterprise can become quite complex and interrelated By having a single known place to put each rule and express it only once the management and evolution of your rules procedures and policies become much less complex High level The business objects operate at a high level one that is understood by business people Your entire organization and in particular top management can participate in the design of its information model and business rules without having to be burdened by implementation details Business Objects use business names and terms Works with legacy systems Legacy systems and data can be wrapped as business objects to become part of the new generation of applications without discarding the value of the legacy applications Insulates you from insufficient or transient standards Standards which were intended to insulate the business from becoming dependent on a particular vendor tend to be insufficient for real world implementations As a result the information systems department must depend on proprietary extensions and features that again lock you in With business objects the enterprise s own information model becomes the standard insulated from the DBMS or tool du jour Advances in technology and new standards can be more easily integrated with your working system Open architecture The business object architecture is open and extensible Interfaces and capabilities can be added as required for the business s need Even the business architecture itself can be implemented on top of any distributed object standard As standards come into place business objects become interoperable and tools can be provided to create and maintain them Any type of tool can be used to implement business objects or exploit their existence Advanced Business Process Re engineering tools Workflow systems CASE tools 4GLs or 3GLs can all be employed to create or use business objects The high level nature of business objects makes them ideal for advanced decision support systems and report writers Scaleable Since business objects can employ advanced distribution mechanisms behind the scenes and the same or a related business object can be distributed across multiple systems the architecture is infinitely scaleable The applications are insulated from changes made to scale the system Reusable components Business objects represent well defined reusable components for application development Reusable components leverage design and development efforts increasing responsiveness and reducing costs Some business objects may even be purchased from third party vendors and integrated into an existing system Since business objects directly represent the business model reuse becomes natural The business model and objects which have a natural order become the library of reusable components Opens system to power users Since business objects are visible to the desktop any program or user can access and safely manipulate the objects of the business Power users and end users get unprecedented accessibility to enterprise resources Business objects are safe to manipulate because data integrity and business rules are enforced by the business objects Ideal for business process re engineering Business process re engineering BPR is heavily dependent on a strong and flexible information system Business objects are an ideal way to implement an information system that supports BPR The type of analysis done to re engineer a company can produce the kind of business model that business objects can implement Ivar Jacobson in his excellent book Object Advantage shows how BPR and object oriented analysis can be combined and complementary Ease of use By providing a pre built application framework the user is in a better position to concentrate on the application problems Users who are forced to build an application framework from the ground up can face a huge effort in design and implementation that has nothing to do with their business problems A well thought out proven and standard framework can save massive amounts of work Combine this with the possibility of purchasing pre built objects and pre built tools and the user s work is really leveraged Business objects use business terms in ways that business people understand Keeping the terminology in line with the business makes the entire system more understandable Business objects are happening Business objects are a hot topic The press is talking about them standards bodies like the Object Management Group OMG are talking about them IS professionals are asking for the functionality Vendors are implementing them Users who currently are trying to use two level client server systems know they need them Standards and the OMG While products based around this architecture are attractive standards will make it an industry By standardizing on the Business Object Architecture objects created in diverse systems can interoperate and companies can provide specialized tools to create and maintain the business objects The lower technology layer is already available and standard The next layer of standardization can provide the higher level business object protocol We expect the infrastructure and interface to become standardized by the OMG sometime next year Once this happens the now uncoordinated efforts being put into business objects can become cooperative technologies supporting a common application architecture How the BAA fits into a business Diagram BAA 1 Your business model The basis for any business object system is the model of your business This model is built using abstract business objects and processes and or more specialized versions of these abstract objects This model should include every person place thing event or transaction that needs to be captured in the information system The business processes are likewise identified and modeled as business process objects Once complete this business model becomes a valuable reference to how your business is organized and operates Business objects and implementation components Each object in your business model is used to create an executable representation of that object in your computer system This executable object will contain and encapsulate the information and rules associated with that object and its relationships to other objects Some business objects may be implemented on top of existing applications as wrappers exposing the legacy application as business objects Other objects may be implemented using Workflow tools computer languages or 4GLs Provided all of the tools and wrappers can speak the BAA protocol consistency of implementation environment is not required When used with a traditional DBMS the executable objects sit between the DBMS and the user interface providing an object oriented 3 tier client server system Presentation and system interfaces Given the executable business objects user interfaces are generated to allow users and other applications to view and manipulate the business objects The business object user interface becomes the new look and feel for your applications Desktop application may also interface with the business objects through interfaces such as OPENDOC and OLE II The direct representation of the business model as executable and user accessible objects is the essence of the business object concept The outdated concept of application With a system comprised of a set of cooperative business objects the outmoded concept of monolithic applications becomes unnecessary Instead you information system is comprised of semi autonomous but cooperative business objects which can be more easily adapted and changed This type of component assembly and reuse has been recognized as a better way to build information systems The Requirement for OMG Standards Options for an application architecture and framework Given that an organization wishes to implement a business application there must be an application architecture That architecture may be custom proprietary or standard Each approach has its advantages and disadvantages Custom A custom architecture provides maximum flexibility to the enterprise The applications can be designed and tuned to the organization s needs Since the organization has developed much of its own infrastructure it is not dependent on as many external suppliers unless such dependencies are built into the custom framework Creating a custom architecture is not a small job Experience has shown that a highly capable and specialized development team requires one to two years to field a stable infrastructure for applications development in a distributed environment The application infrastructure like all software will also require costly maintenance and future development Of course the application created in a custom environment will not interoperate with external software considerable effort must be expended to integrate other software and data Proprietary A proprietary application framework may be purchased from a vendor frequently with some standard business applications This solves the problems of producing a custom framework but it does not solve the problems inherent in integrating the system with software that uses another framework Many organizations are also concerned about being locked in to a proprietary framework vendor since the organization may become very dependent on the provider However with a good provider relationship a proprietary framework may be very productive Standard A standard framework solves the problems of creating a custom framework and vendor lock in The organization may deal with multiple vendors to supply and support the standard framework The standard framework will have a much larger support base and as such will probably be worked out and debugged to a greater degree The most important factor in a standard framework is commercial support Given a standard framework it is practical to purchase pre built business objects in an open market Pre built objects can be used as is or enhanced using standard object oriented techniques vastly leveraging development On the tool side the organization can purchase design and implementation tools data analysis tools languages libraries and utilities to help use and build applications in a standard framework Standard desktop applications can interface with the architecture components A standard framework also leverages training A development organization will be better able to find employees and consultants who already understand how the business system operates The only down side to a standard framework may be flexibility The framework may not do just what is required in very special conditions But the object oriented paradigm helps here as well since the standard framework can be extended as can all object systems In short a standard framework can foster an industry of business objects Goals of standardization The reasons to standardize components of the BAA are directly reflected in the purpose of the OMG a to promote a single object oriented applications integration environment based on appropriate industry standards b to promote a framework for compatible and independent development of applications c to enable coordination among applications across heterogeneous networked systems in a multinational multilingual environment d to adopt a core of commercially available implementations of this framework and to promote international market acceptance and use e to actively influence the future direction and development of these core products and technologies and f to foster the development of tools and applications that conform to and extend this framework and to provide a mechanism for certifying compliance with the core technologies Article I of the OMG by laws Such a purpose for OMG and the BAA will have a range of advantages Synergy To synergize the work being done in creating business applications and distributed object components into a cooperative industry effort Interoperability To make independently developed business objects interoperable with a minimum of effort Federation of systems To allow diverse business systems to be

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


  • Behavior As a property of a business object the actions a business object is capable of performing to fulfill its purpose including recognizing events in its environment changing its attributes and interacting with other business objects Note The OMG term for behavior is services and behavior is implemented in program code by an object s methods Business Definition As a property of a business object a statement of the meaning and purpose assigned to a business object by business experts Business Entity Object A business object which represents which represents a business noun or actor A business entity object is a specialization type of business object Business Object A representation of a thing active in the business domain including at least its business name and definition attributes behavior relationships and constraint s A business object may represent for example a person place or concept The representation may be in a natural language a modeling language or a programming language Note BOMSIG s use of the term business object is equivalent to business object type Business Name As a property of a business object the term used by business experts to classify a business object Business Process A process in the context of business organizational structure and policy for the purpose of achieving clear business objectives Source Workflow Management Coalition Business Process Object A business object which represents a business process A business process object is a specialization type of business object The following words are intended to convey the difference between business object and business process object but are not literal synonyms action set of steps business verb control object routings workflow Business Rule As a property of a business object a constraint which governs the behavior relationships and attributes of a business object Instance An object created by instantiating

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

  • OOPSLA'96 Analysis Patterns and Business Objects
    later I took many of these patterns and used them on a project for corporate financial analysis for a large US manufacturer The patterns proved to be a very valuable starting point for our work and although some changes were needed the business financial analysis model was still recognizably based on the health care model Indeed many of the changes can be used in health care Analysis Patterns and Business Objects So what are the differences and similarities between analysis patterns and business objects The key difference to me is that Business Objects are prescriptive while patterns are suggestive If I buy business objects for accounting I have to use them in exactly the way they are written I can make some changes by appropriate subclassing and modification but the changes are very much based on what the writer of the business object allows me to alter An analysis pattern is a model and a discussion of why the model is the way it is and its strengths and weaknesses I am free to tweak the pattern in any way I like before implementing it If the pattern comes with sample code then I can use the code but again I m free to make any alterations I like The really important thing about a pattern is not the model or code but the rationale behind it Thus Business Objects have a lot strengths over analysis patterns All you have to do to use a business object is to buy and install it while with a pattern you are just given the idea and have to implement it yourself Even sample code is meant more as an explanation than as a useful unit on its own Business objects also help more in integration If two systems are based on the same business objects integration should be easy However being based on the same pattern means little The basic idea the classes and interactions will be similar but names would probably be all different and so the integration would still be hard work There are still advantages in the using the same pattern the similarities will make it much easier to understand what is going on So business objects seem so much better than analysis patterns that you wonder why we might need analysis patterns I have two reasons Firstly analysis patterns can document the business objects They can show why the business objects are they way they are and why they work the way they do That makes them easier to use The second reason is more depressing Business objects require you to at least some extent buy into their way of doing things I ve spent much of my career around people who have been trying to come up with standard plans for businesses such as corporate data models On the whole they don t work A colleague of mine remembers a case in a large corporation when they tried to come up with a standard definition of account

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

  • OOPSLA'96 Business Objects, Business Patterns
    to make a profit And because of the ongoing nature of the response the business reflects a corporate culture that shapes its actions over time Another part of the Context was that a key requirement in modeling a business should be to separate the organization from the business The internal organization is NOT the business but rather the machinery that the business uses to provide resources and money to support business activities The underlying organizational and functional views merely clarify and support the aspects of the business model Internal processes and activities e g creating a budget scheduling training allocating staff are organization activities not business events at the strategic i e core process level Finally although recognizing that the model should be driven by the business and NOT by any potential system solution or way of conceptualizing a solution there is a need to be able to bridge the gap from business to possible systems in a way that is as simple and consistent as possible To us that meant that a solution would have to accommodate three elements as a minimum modeling structure Business Events a specific interaction between the business and the outside world which initiates a business process calls corporate forces and resources into play to respond additional internal business events may be needed to support the particular business implementation of the process e g decisioning authorizations etc Business Processes triggered by a business event the activities detailing the solution to the problem opportunity represented by the business event Business Objects following the Object Management Group definition a representation of a thing active in the business domain for example a person place or concept extended to include business processes as objects e g tasks and workflows and perhaps business functions as well the nexus of resource and organization Our Solution was A Business Model based on business patterns business processes and business objects that explains why the business is in business defines how it does business establishes what it considers serious business like behavior In particular we came up with a structure that resembles the proposed means for incorporating patterns into the emerging Unified Modeling Language a classification of patterns into frameworks a microarchitecture that provides reuse in the large mechanisms structures where objects collaborate to satisfy a requirement of the problem domain to solve common problems in common ways and idioms an expression peculiar to a certain organizational culture which supports reuse in the small an extended form of use cases to reference and leverage patterns A Business Pattern Framework Following Alexander s approach a Business Pattern is expressed in the form problem context solution At the level of mechanisms Business Patterns can extend system design patterns that are already acknowledged as useful The obvious example is Gamma s chain of responsibility described by Booch as often found in event driven systems especially GUI systems a client sends a message to a handler asking it to handle some request That handler is actually part of

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

  • OOPSLA'96 Models of Business Objects: Accounts
    Transactions model the pieces of paper that flow between businesses usually describing either the flow of money and goods or commitments of money and goods Accounts model the books the documents that describe the state of the business Thus they describe how much inventory you have how much you owe your venders and your net worth Transactions are fairly simple basically a record with a date Accounts are much more complex since their attributes change over time You don t ask for the amount you owe a vendor you must ask for the amount that you owe a vendor at a particular point in time because the amount you owe changes from day to day Accounts transactions are related to database transactions but are not the same because a single Accounts transaction might turn into several database transactions In the same way an account in Accounts can model an account in an accounting system but is not the same In Accounts an account can have many values For example an inventory account might keep track of the on hand inventory the amount on order the cost of goods sold for the each month and year and the sales for any time period Also an accounting system should enforce double entry transactions but an inventory system does not need to Accounts uses more direct means of enforcing consistency though it can support true double entry bookkeeping One of the most important features of Accounts is the way it enforces relationships between transactions and accounts Transactions are posted to accounts and the value of an attribute of an account is a function of the transactions that have been posted to that account Most business transaction processing systems enforce these relationships with an update program usually written in COBOL that reads transactions and updates the master file of accounts The business rules are hard coded in the update program and changing one of them requires a new version of the program It can be hard to undo a transaction or to execute them out of order because you have to make sure that you are using the right version of the update program In contrast Accounts enforces relationships between transactions and accounts by defining each attribute of an account as a function of the transactions posted to that account For example the total sales attribute of an inventory account is the total of the sales field of all transactions posted to that account the total purchases attribute is the total of the purchases field and the on hand attribute is defined to be total purchases total sales total shrinkage This model has many advantages It is easier to specify how to process a transaction Business rules are time stamped so it is easy to process transactions out of order and to use the correct set of business rules It is also easy to undo them It is easy to decide that a business rule will change as of a certain date This makes

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



  •