* Be as specific as possible
* Indicate the general kinds of problems that interest you
* Explain why thoughtfully, accurately, concisely and establish your ability to think independtly and creatively.
``Software Architect.'' I've tried using this title for a few years now. At first, it was just a title that captured the aesthetics, engineering rigor, and professional relationships of building large software systems in a way that Program Designer or Systems Analyst can't.
For the last few months, I've been searching for the common thread to the diverse set of CS topics that intrigue me. It took a long time to realize that the answer was already on my calling card.
One of the first things we can identify in Architecture is the notion of style: Classical, Gothic, Structural, Modern, Organic, and so on. What can we say about styles of software, such as Relational Database, Pipe & Filter, Object-Oriented, or Functional? I have a rough hypothesis in Figure 1 that classifies styles by separating of Data, Process, and Control. It might be tempting to portray these in a hierarchy: concurrency Control arbitrates between Processes that modify Data.
Figure 1 Classical Styles of Software Architecture
Continuing the analogy to architectural styles, software styles should express software designs according to different models. An ``architectural sketch'' of electronic publishing (Figure 2) enumerates design alternatives and examples of real systems in each style, such as NNTP's distributed broadcast.
Figure 2 Example: Electronic Publication
This merely describes a distributed OO system. There are some more interesting properties that follow from the analogy of Space. Physical space is a persistent container, so we need a network-wide OO database (MIT's Thor) and class repositories (CORBA, System Object Model). Space mediates communication and maintains integrity, so we need provably correct distributed algorithms for naming, mutual exclusion, LARCH-like verification of modified classes, and constraint propagation.
Space also allows different perspectives. A notion of protocol calculus can allow us to separate the description of a class's implementation (type) from its supported behaviors (protocol), and then reason about objects solely by their behavior. A formal protocol spec can be used to adapt one kind of interface to another, sometimes called subject-oriented programming. In such a Space, an object can adapt to its context: a FAX file can be adapted to TIFF, a meeting in a scheduler, or a text object, using OCR. A bank's full-fledged Stock object could be adapted to a personal finance application's Investment, so now we can reason about exchanging higher-order concepts other than mere C data types like float and char. In fact, other adaptors might automatically articulate a graphical interface for such objects, binding together the computation, visualization, and distribution -- the leap from NII to Cyberspace.
Why is oSpace a useful model? oSpace is a synthesis of ideas reflected in eText, as well as in several emerging approaches to large-scale distributed software architecture. Besides, it helps answer the question I ask myself, ``How did eText manage to take five rewrites and almost two years?''
eText does not fit one of the classical styles. It is primarily OO, but distributing it over a network and enforcing the conservation laws that articulate the interface add a strong element of Control. I also see new patterns in precisely how complexity arises. eText is a very large application, so a great deal of complexity is embedded just in its features: actually handling images, editing text, playing audio, and creating hypertext links. There is an additional layer of complexity hidden in the creation and enforcement of the rules of eText-Space,though. For example, a Navigator may list the title of a DocInfo; if it changes, it must propagate to the Navigator. Traditionally, both objects would have to explicitly cooperate; putting the burden on the oSpace is difficult, but cleanly separates each. This kind of enforcement problem has emerged in frameworks, patterns and other advanced OO architectures -- Taligent CommonPoint's notification system is its patented crown jewel, for example.
Like real space, eText mediates interaction (through the core services and naming), can contain other objects persistently, and conserves certain invariants. Physical space uses photons (virtual and otherwise) to mediate exchanges; eText uses messages on relations like ``Save all open documents.'' Real space transparently enforces the Pauli exclusion principle; eText enforces ``exactly one DocInfo for every Document,'' ``What's on the screen is in the computation'' (synchronization), and ``exactly one Component per File'' (OO filesystem). oSpace simplifies the problem consederably, as shown in Fig 2.
A certain proverb of grantsmanship holds, ``An interesting question is far more useful than an answer.'' I don't profess to have any answers. There are several productive directions outlined on the path to oSpace, through formal specifications, OODB, distributed naming, language design, automatic UI articulation, organizational use of information. My graduate will hopefully let me develop a philosophy of software architecture, and perhaps take the first steps towards oSpace.