William Kent
Database Technology Department
Hewlett-Packard Laboratories
Palo Alto, California
June 1992
> 1 INTRODUCTION
> 2 DISPERSED AND COHERENT OBJECTS
> 3 THE SITUATION
> 4 SOME QUESTIONS
> 5 A SCENARIO FOR OMG
Many things can be said about many objects (in a technical sense of the term), but few ideas apply to all of them.
An object has behavior and state. While the metaphor of an object as an autonomous unit of behavior and state is appealing in its simplicity, it's too simple to be real. Sometimes an object does act autonomously and spontaneously, as you and I and computer programs often do. But sometimes an object is the passive "object" of activity, like an egg we break or a picture we paint or a document we edit. And sometimes behavior is a collective activity, like shaking hands or dancing or getting married or fighting or any team sport.
Some objects have a sense of physical coherence and spatial integrity, being all in one place like a data structure or a pie chart. Others are diffuse abstractions, like an engine design whose parts lists, design drawings, housing configurations, performance specifications, test data, cost analyses, and manufacturing plans might be widely scattered ? yet all the while remaining a single abstract concept: that particular engine design. Some are visible, like the pie chart, while others are invisible abstractions, like the engine design. Some things seem autonomous and self-contained, like a book, while others are inextricably interlocked with others, like a wall whose inherent functionality is intertwined with other walls, floors, ceilings, windows, doors, and so on.
Those notions don't universally characterize the object paradigm, but there are a few which do, including interfaces, identity, operations, types, and a few others.
[Some discontinuity here needs smoothing.]
Many object models take it for granted that an object is coherent and localized in one or more of the following senses:
While it makes sense to define sets of objects having various combinations of these characteristics, they are by no means true of all objects.
Many sorts of objects are involved in providing services to end users. They can often be organized into "levels", such that operations on objects at one level may be executed in terms of operations on objects at another "lower" level.
End users directly deal with presentation objects to express their requests and receive results. These include such graphic user interface (GUI) constructs as windows, menus, icons, cursors, charts, graphs, pictures, and even sounds. They also include textual constructs such as characters, words, lines, paragraphs, statements, equations, and simple displays of numeric values. A displayed table of alphanumeric data is an example of a complex presentation object. The text of a document as arranged in a window is another.
Presentation objects may be organized in several levels. Manipulation of menus and cursors may be mapped into textual objects before actual operations are requested.
End users are really trying to manage semantic objects. This is what their applications are all about: circuits, engines, bridges, roads, countries, people, companies, departments, documents, designs, and so on. The abstract values of numeric quantities, as distinguished from their representations, are semantic constructs (whether they are objects remains to be discussed).
The "real" activity in a computational system involves data processing (DP) objects: data structures, memory, storage devices, programs, procedures, processes, processors, threads, sessions, nodes, paths, and the specific representations of stored data items. These are the materials from which implementations are constructed.
DP objects may also cascade through several levels. Relational tables in a database may be implemented in terms of operating system constructs like buffers and files. Files in turn may be implemented in device-specific terms such as disk tracks, sectors, and physical records, while buffers are managed in virtual memory which in turn maps to physical memory and storage device constructs.
The general setting is publications management, including such things as document processing, production management, and business management.
The business is spread out over a wide variety of locations (WAN) and facilities within a location (LAN). A large variety of machines and operating systems are used by people in the locations and in the field.
There are many sorts of documents. A magazine issue is a document, and so are the articles, illustrations, advertisements, editorials, letters to the editor, etc. Other documents include letters, memos, contracts, style guides, ... Documents can include other documents, sometimes sharing subcomponents (e.g., illustrations). Certain subdocuments are shared among many issues, such as a masthead, staff list, and statement of editorial policy.
An issue of a magazine may be initially created in the editorial office with an issue number and publication date and not much else. Later the layout department will develop its layout, blocking out the number, types, and sizes of articles, editorials, advertisements, letters to the editor, classified section, indexes, etc.
The business office will eventually decide on how many to print, the production office will handle scheduling of the printing plant, the printing plant will actually handle and track the printing, and the circulation office will handle subscription information and distribution. All of these offices keep histories of what they did with a given issue.
An article may be created with only a topic and a planned issue of publication. It may then acquire a layout in terms of length, fonts, and number and type of illustrations. It may later be assigned to a writer, or several. If the writers are free-lance, the business office will keep track of contracts and payments made for a given article. The article may later get text, revised numerous times, perhaps combined from the input of several field researchers. When finished, there may be a "source" text and a final published version that fits the layout. There are a variety of edit programs which are used by various people on various machines in various locations. An article may get printed in various draft forms, as part of an issue, and as a stand-alone reprint. Things can be printed by themselves (article galleys, reprints) or as part of other things (e.g., an issue).
Portions of the text may be in progress in various offices and various locations. Some portions of text may be included in multiple articles. Illustrations may be handled in various art, graphics, and photo departments. They also can be shared among articles. Versions of an illustration may appear with the article and in the table of contents.
Long after many documents have been created, new processing capabilities may be installed. New programs are added to do spelling checking, grammar checking, style checking of various sorts, abstraction, information retrieval, etc. These may come in many varieties, written in various languages for various platforms and machines.
Extensibility and reusability can be illustrated with a page formatting program, used initially to support printing, later by an interactive browser, and still later by a fax transmitter.
Some operations assign issues and articles to printing presses. A new program might do production planning and load balancing in the print shop. Is it associated with any particular class?
Other programs will produce status reports on the state of progress of various articles and issues, on the present and future workload in the printing plant, on circulation statistics and trends, and so on. Are these applications? Are they associated with any particular classes?
In this context, what are the objects, interfaces, and applications? What are application objects? What would differentiate compliant and non-compliant interfaces?
For a request to edit a particular article, is the object to which this message goes considered to be the article or the edit program? Or are they somehow the same thing?
If a spell-check capability is installed, is that a new object? Or do we say that every document has now been altered to incorporate the spelling check capability?
When an article is assigned to a writer, do we have to choose to say whether the "message" is sent to the article or to the writer? What about when the article is assigned to a printer?
The print shop gets scheduled. Documents get assigned to presses (another multi-operand operation.) What parallel between assigning a document to a writer and having it printed on a printer? Do we say to the document "write yourself" and "print yourself"? Do the messages go to the document, or to the writer and the printer, or what?
Can message routing be dependent on the requested service? For a given article, can we ask the editorial department for the text, the art department for its illustrations, the business department for author payments, the layout department for its placement in an issue, and the circulation department for the number of reprints?
Explore what it means to move a document. It might be from one department to another (Sports vs. News), to a different city, writer, printing press, issue, location within an issue, etc. What gets moved? Text? (Which?) Contract ownership?
If the editorial office has the source text, the layout department has the final text and the illustrations, the business office has the information about contracts and royalties, the planning department has its printing schedule, and the print shop is printing it, where is the document?
A printshop management program might be acquired or developed. (Or several?). It does load balancing, automatically assigning documents to presses. Is this program invoked via object/class paradigms? Ditto for programs that generate status reports on various things.
Another program might trim or reformat articles to fit layout specifications for a given issue. Again, does this fit the object/class invocation paradigm? Does it make a difference if it operates on one article or many? If it is interactive or a fully automated program?
Explore what it means to move a document. It might be from one department to another (Sports vs. News), to a different city, writer, printing press, issue, location within an issue, etc. What gets moved? Text? (Which?) Contract ownership?
What are the objects, applications, interfaces, types, classes, etc. in this scenario?
Is each issue and article an object? Is each editor and spelling checker? Is the printshop scheduler an object?
What does it mean to destroy a document? Or create one?
Things to be illustrated:
Elements of the scenario:
Publications management.
There are many capabilities involved, developed or acquired incrementally over time from different sources, but needing to work well with each other.
Document processing, production management, business management...
Multiple locations (LAN and WAN), multiple machines and environments.
Many kinds of documents: articles, fragments, graphics, magazines (issues), memos, contracts, letters to editor, advertisements,...
Many kinds of editors; same editors implemented on different machines.
Documents exist in different internal formats on different systems.
May be multiple editorial departments with different locations, systems, etc. E.g., sports, business, arts, fiction, etc. Maybe in different cities.
What does it mean to move a document? Among offices in different cities, between editorial locations (e.g., an art story becomes news), from editorial office to print shop.
Different aspects of a document can be in different places.
Complex containment semantics. Some graphics, text shared by several documents.
Documents can exist without text. E.g., planned future issues, articles. There can be info about schedules, contracts, sizes, topics, etc.
What does it mean to delete a document?
Some documents can be printed but not edited: magazine, graphics (at least not text edited). Maybe some can be edited but not printed.
Documents can be printed in various ways. Local printout of draft text. Print article as part of printing magazine. Print article separately as a reprint service.
A document might have source text and published text. Source text = reporters' notes, field research, full text before trimming for layout, original letters to editor.
Circulation dept. Subscribers, deliveries.
People/businesses: employees, authors, advertisers, subscribers, distributors.
Some articles have free-lance authors, with contracts and payments.
Magazine layouts can exist independently of articles.
Services: editing, spell check, grammar check, style check. Generating layouts for articles, adapting to layout of magazine. Abstraction service, information retrieval. Maybe several alternatives available. Cataloguing.
May need a low level interface for many of those services which will extract text objects (words, lines, paragraphs, headings) in common format.
Production planning for the print shop. Assigning magazines to printers. Automatic load balancing.
Advertising dept.
Business management could include status reports (periodic, demand, exception) on everything: number and status of articles for issues in progress; circulation; print shop work load, productivity, etc. May be selective on various criteria: magazine, issue, office, facility, etc.