semeta Swiki

When an emerging scientific theory is applied to a new problem,
it is often not clear exactly how to apply the theory to the
problem [Kuhn 1970, p. 29]. In these circumstances,
scientists must perform experiments to choose among the alternative
ways of articulating the theory in the new context. Such
experiments are not designed to confirm or refute the theory,
but rather to resolve ambiguities that arise when trying to
apply an accepted theory to a new problem. Resolving these
ambiguities permits the application of the theory to problems
to which heretofore the theory had only drawn attention.

Kuhn identifies three categories of empirical
research that contribute to the articulation
of a (paradigm) theory:

1. Building an apparatus to determine the value of
   a physical constant that is named (but not yet
   defined) by the paradigm;
   
2. Efforts to determine new quantitative laws,
   such as Boyle's law relating gas pressure
   to volume (which was enabled by the paradigm
   theory that gasses are fluids); and
   
3. To choose among alternative ways to apply
   a paradigm to a new area of interest.
   

I believe that this third category can well describe
some of the work that bridges OO with higher-level
design concepts, such as information hiding, design
for extension/contraction, etc. Batory's work, for
example, articulates design for extension and contraction
in a way that seems to ``fit'' well with object-oriented
programming. For example, consider a symmetric component,
i.e., a component in realm R that is parameterized by
the same realm R. Symmetric components are viewed
as the key to large-scale reuse (which is connected to
extension in Parnas' sense). Given a symmetric component
c[R] R,
we might say that c ``is-a'' R; and that for some
other component d R,
we could say c[d] ``is-a''
d. Now the ``is-a'' relationship in OO is implemented by
class generalization and inheritance. When a symmetric component
is implemented as a mixin layer, which means that each class in
the interface of c[R] is defined to specialize (inherit from) a
corresponding class in the R component used to
instantiate c, then an ``is-a'' link between two components
is implemented using a collection of ``is-a'' links
between corresponding classes. That's one of many nice
fits that the GenVoca theory affords.

Related to your idea about establishing a common vocabulary
for patterns and such: Realms and GenVoca components are
implemented using a vocabulary that includes OO frameworks.
In fact, in [Batory & O'Malley, TOSEM'92], they claim that
a realm interface is an object-oriented framework
and that a component in a realm defines a set of
classes that instantiate the framework.
Were OO frameworks not a ``primitive concept'' in the
design vocabulary, the theory of realms and components
would be much more difficult to formalize.

We explain theory articulation and the role of
experimentation through an example. A textbook
software-engineering problem is to decouple an
application's user interface (UI) from its underlying
computation (or functional core (FC)). The decoupling is
motivated by the desire to reuse both the FC and the UI.
However, if the UI must present a consistent view of
the FC during an interaction in which the status of the
FC changes, then the UI- and FC-component interfaces
may become very complex. Without a rigorous theory
to guide the design and implementation of these
interfaces, a designer might unintentionally
couple the components by making the interfaces
too specific. I recently proposed a solution
that represents the interface to the
FC component, not as an unstructured collection of
services, but rather as a state diagram that
represents services as events whose invocation
status is represented explicitly in the states
of the diagram [Stirewalt ASE'99].
This approach extends the FC interface with status
information without tightly coupling the FC to
a particular UI. Such an approach is one articulation of
the general theory: It shows how the general priniciples
are applied to maximize view consistency and reusablity.
By articulating the theory in different contexts, we make the
theory easier to apply, which is the primary goal of much of
this type of research.

Seriously, though, I'll give it a try:


>Likewise, I would like to see a definition of "articulating".

Kuhn does not provide an explicit definition; however the term
is introduced in the following paragraph [p. 27]:

1. Research to identify the value of physical constants,
   such as big "G";
   
2. Research to identify useful quantitative laws, such
   as Boyle's law relating gas pressure to volume; and
   
3. The category I describe in the first paragraph
   of kuhn.pdf
   

Moreover, GenVoca introduces a new concept called
the symmetric component, which seems to be the key
to design for extension and large-scale reuse.
Parnas' principles said nothing about symmetric
components, but the concept is quite practical
as a design goal. It suggests that we can design
for extension/contraction by identifying realms
that contain symmetric components. I personally
find this to be more concrete, or articulate
than "try to identify useful subsets". The search
for realms with symmetric components is a nice
way to "try to identify useful subsets".

>In reference to the last paragraph, can you give an example of when
>the UI would have to present a consistent view when the FC changes?

Sure, if the FC is monitoring some external (physical)
device and an event from this device causes a change
in the state of the FC, such as when a temperature
sensor reports a temperature above some threshold.
Another example would be in a file-system browser:
Files are represented by icons in the GUI; when a
file is deleted, which might occur as a side
effect of computations in the FC, the icon needs
to go away. Of course a million variations are
possible: Perhaps the icon reflects the read/write
permissions of the file, and these change when another
user in the system locks the file.


>How does using an event-interface buy you more than a functional
>(calling) interface?

>Can we develop a theory of extensibility? Are there different kinds
>of extensions?

That's an excellent question. I would hope to one day have
a robust, empirically validated theory of extensibility.
My gut reaction is that there must be different kinds
of extensions; however, I don't have anything near
a taxonomy in mind yet. Assuming that someone has thought
about this issue, it might be nice to try and characterize
"what kinds" of extension are afforded by the GenVoca theory.

>Where do you think we are in the general process of understanding
>how to do software design?

>Some interesting design measures:
> + purity (Halstead)
> + transparency (Parnas)
> + orthogonality
> + leverage/compositionality

• Spencer -