Author Topic: 1995 Desription of Ptech technology  (Read 955 times)

0 Members and 1 Guest are viewing this topic.

Offline Dig

  • All eyes are opened, or opening, to the rights of man.
  • Member
  • *****
  • Posts: 63,090
    • Git Ureself Edumacated
1995 Desription of Ptech technology
« on: December 01, 2010, 07:03:55 am »

Oopsla Issue Build on Legacy or Start Over

"THE BASIC PROBLEM IS that the irresistible force of the new paradigm is meeting up with a 2 trillion to 3 trillion installed base of legacy systems." That, in a nutshell, is the main question facing the object-oriented community today, according to a white paper distributed by Digitalk, one of the more than 50 exhibitors at the Ninth Conference on Object-Oriented Programming Systems, Languages, and Applications. Can industry pile new objects on top of existing systems Or is it better to build new object-oriented systems from the ground up

Irene Greif, director of workgroup technologies at Lotus Development, contended that object-oriented technology need not be applied from scratch. In fact, although object-oriented methodologies have been developing since the 1970s, she said, "there are virtually no major products that can claim to have been developed fully within this paradigm." Lotus, of course, designed its spreadsheet for use by individuals. Greif is responsible for modifying it to use e-mail and shared database technology in workgroup settings.

Greif's talk was itself an illustration of shared technology. Her speech was transmitted to OOPSLA via satellite from the Conference on Computer-Supported Cooperative Work in Raleigh, North Carolina. At the same time, her video and slide presentation was transmitted via an ISDN link using Intel Proshare.

Greif's organization has been finding ways to layer objects on top of existing applications so that they work in a group situation. "What we learned is that we can take an evolutionary approach toward adding objects to existing code, to a legacy product," she said. "We preserved the original code base."

At the other end of the spectrum are the proponents of business-process reengineering, such as Ptech, another exhibitor. To Ptech, an organization is "a set of operational processes that are built on top of information bases and that cause and respond to events." These processes must be dynamic because the environment within which the business operates evolves rapidly and often unpredictably. Therefore, decades-old legacy code hardly meets fast-changing needs. What business really needs are processes implemented by a software technology like object technology, which can be modified as the environment changes.

Nancy Leveson, of the University of Washington, said she is not sure that object-oriented systems necessarily meet all environmental requirements, particularly those for safety. For example, reuse can actually be antagonistic to safety. A set of components that is safe when used in one context can be unsafe when used in another. Reuse might lull people into thinking they are going to do something safely when, in fact, they are not.

OOPSLA program chair J. Eliot B. Moss, of the University of Massachusetts, said he invited Leveson to expose the object-oriented community to these issues. "Object orientation might let you build systems more quickly, meet functional goals, maybe meet reliability goals; that is, the system continues to run and perform the functions it was designed to do," Moss said. "Safety requires a different analysis; for example, what are the potential problems in a bad situation" The initial requirements should reflect these issues, he said, and if safety concerns are not adequately dealt with at this point, the reuse of previously reliable objects won't make the new system safe.

Hiding the details of an implementation in a black box with a standard interface is now almost traditional. With object orientation, however, that standard interface may not always be sufficient. For instance, the performance characteristics of a window system, whether it is very fast or very slow, may be based on assumptions about the user. A later system that tries to reuse the same objects might be based on different assumptions. We need ways to design systems so that later designers or even clients can modify the standard interface.

This aim might be accomplished through a second interface, which Gregory Kiczales of Xerox Palo Alto Research Center calls a "metainterface." Moss calls it a "control interface." What makes a metainterface a good one and how you tell a good one from a bad one are still research issues. One of Kiczales' aims is to outline a terminology for thinking about these issues.
All eyes are opened, or opening, to the rights of man. The general spread of the light of science has already laid open to every view the palpable truth, that the mass of mankind has not been born with saddles on their backs, nor a favored few booted and spurred, ready to ride them legitimately