Collaborative articulation of how abstraction and language is employed in the computational manifestation of numbers -- including analysis of the role of syntax, semantics, and meaning in the specification and use of software interfaces.

Recent Items
Numbering Peano: Annotated
Annotating Peano Numbers

Archives
2004-05-30
2004-06-06
2004-06-13
2004-06-27
2004-08-22
2004-08-29

A Fine Kettle of Fish

A Fine Kettle of Fish

Assuming Contexts and Meanings.  How did we get in this fix?  I'll answer locally, not globally.

Fussing about Interface Contracts.  Anderbill and I talk about interface contracts a lot.  We have noticed for a long time that interface contracts are not anywhere to be found in the way interface descriptions are handled in the most heavily-used computer programming languages, whether object-oriented or not.  Except for some minor syntactical matters, the computer is not a party to the contract at all.  The contract is an out-of-band agreement and it is so far out of band that it is maintained among people, not machines.  This may be well-understood, except that people don't speak about interfaces and API definitions as if it is.  So our mutual abstraction-abuse alarms go off when we run into various statements that are at best misleading.

Background

Here's a little context in terms of the relationship of the Numbering Peano exercise to a wider topic: engineering of enterprise application systems based on models, whether used in computer-assisted development or not.  This does not have to be understood to gain an appreciation of the Java interface middle-level example.

Riding on the MDA.  The other day, I remarked on Model-Drive Architecture (MDA), an OMG-sponsored initiative that is intended to move software engineering to a level where enterprise applications are defined and expressed in a Platform Independent Model (PIM).  To enact the application, MDA tools are used to (semi-)automatically translate the PIM expression of the application to one in a Platform Specific Model (PSM).  This translation involves what I tend to think of as design rules, and my sense of it is that this is still very much black (and proprietary) art.

Different Abstraction Levels.  What is important to understand is that, in the general case, the PIM and the PSM are at different levels of abstraction.  One is not merely a refinement of the other.  The models can be different in kind, not just detail.  An easy way to retain this distinction is to consider that

• Platform Independent Models are about what is being done in operation of the enterprise.  This is about roles, business rules, abstracted activities, and identified information entities.
     
• Platform Specific Models are about what is being used to do it.  This might be limited to the automated and computer-assistend parts.  The PIM is in terms of facilities, services, data architectures, components, and methods of integration for coordinated operation.
     
• Maintenance is at the PIM level.  Even system management is conceived to be in PIM terms.  This is where it becomes all right to reduce programming as a labor-intensive activity.

This is still speculative technology at this time, although some impressive early-adoption results have been claimed.  Not all approaches to MDA are so extreme, and there are intermediate semi-automatic approaches.

Diving Under the Outerware.  MDA and similar initiatives are important.  We're going to learn a lot.  We might learn far more than we want about coordinating between abstractions at different levels.  This area is what I have in mind when speaking of the Application Semantics and Situated Use track's being where we find the outerware.  This is a complex and unruly area.  But some of its nuances can be illustrated at a much simpler and revealing level.  That's where Java APIs come in.

Java APIs?  Following Dan Haywood's critique of MDA, there has been extensive discussion-list commentary.  The juxtaposition of two comments there inspired my post about a possible confusion of abstraction levels and the exchange of comments that anderbill and I made in follow-up.  The trigger for me is Jon Kofal's comment about the Java API.  There's more context, but these two sentences caught my eye and exceded my abstraction-abuse threshhold:

• "I too find it quite ridiculous when existing APIs in our implementation platform have to be 'ported up' to the PIM ... ."
• "Also, doesn't Java provide platform-independence?"

I don't think Java is platform-independent at all, in the sense meant for the MDA PIM. In fairness, Jon answers his own question with "I believe I can live with this level of platform independence" based on his experience on easy transporting of Java software from one (Java) platform to another. Either way, we are now in a position to discuss interfaces, used as Java APIs, as part of a PSM that will be the target of a Platform Independent Model.

Considering Java Interfaces

We're going to establish an interface agreement to some platform-specific behavior.  One might say that the interface is somewhat more independent of the platform than the software that delivers it.  We'll look at how that might be so.  We are operating in the middle muddle: This interface, as "platform-independent" as it might seem to be, is intended exclusively for use by other software living in that same platform regime: a Java machine.  You won't have to be a Java programmer to see what we are doing.  Just follow along.

Using Java Interfaces.  Interfaces are a feature of the Java Language.  Interface techniques are established for other computer languages too.  Here's what you need to know about the interfaces we'll discuss here:

• An interface declaration is typically created by a programmer in a text file.  You can read the text of the declaration, and it is important that programmers and others be able to do that.
     
• The file containing the declaration is submitted to a Java compiler and the part that matters in Java software development is distilled into a Java .class file.  This is usually not readable as text and programmers or anyone else rarely look at them.  The interface-declaration .class file is an artifact of the Java system.  It's only necessary to remember that the interface .class file is simply a Java-friendly version of the essential information from the original interface declaration created in a text file.  The text version is convenient for people; the .class version is computer-efficient.
     
• Programs that offer the interface -- honor the interface contract for operations they supply -- are recorded in text files.  Programs specify the interfaces they implement by name.  The Java compiler matches the implementation to the interface by consulting the interface .class file.
     
• Programs specify the interface they use by including declarations for their use of interfaces, by name.  The Java compiler verifies the mention and use of the interface by consulting the interface .class file.
     
• It is important to notice that the use of an interface can be verified without any concern for programs that implement the interface.  Likewise, implementation of an interface is without any dependency on use of that interface by a particular program.
     
• When the pieces of programs -- all .class files, including the interface .class files -- are put together, the several implementations of a given interface are delivered for use in accordance with statements written into the programs.

Inventing a Peano Numeral Interface

The Peano Numeral interface is being invented (or articulated).  There are three versions of it so far.  It is useful to simply look them over, notice the constant parts and see what parts seem to be involved in the invention process.

An Example in Mind.  I created a kind of pseudo-Java trial as a way to express some ideas about what we could use as a demonstration of interface concepts.  I added a set of questions and more discussion.  The initial sketch for the interface declaration looks like this:

interface com.orcmid.cs.pa.Num
{
/* That is, defined in package com.orcmid.cs.pa
*/

com.orcmid.cs.pa.Num next();

com.orcmid.cs.pa.Num pred();

Boolean is0();
} // Num

Seems Like the Simplest Thing.  Anderbill takes a look at the sketch and the discussion around it, coming up with a Java interface declaration that is acceptable to Java compilers and produces a perfectly-good interface .class file (named Num.class in this case):

package com.orcmid.cs.pa;

public interface Num
{

    public int next();

    public int pred();

    public boolean is0();
}

The "colorizing" and difference in font appearance is provided by a text editor designed for Java programs.  These are meant to provide visual cues for particular kinds of Java constructs and their usage, based on rules of the Java language.

Uh, Just a Minute.  Orcmid is fascinated by Bill's response, and offers a different interface declaration that is closer to what he had in mind:

// package com.orcmid.llc.pa.pn;

public interface Num
{

    public Num next();

    public Num pred();

    public boolean isOrigin();
}

That's it.  This is close to the bare essence of what one needs to specify in Java to have an usable interface declaration.  There is much more, but it starts at this level.

If you're still here, you probably have questions.

posted by orcmid at 6/5/2004 05:46:43 PM