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
Deja Double Vu
Blog Restored
Unorganized set of references: to be evaluated
Document-centric integration; perils of API's
Libraries and Platform Independence
"External" Interface Contracts
Interfaces, Protocol Extensibility, and Versioning
A Fine Kettle of Fish, indeed.
What Is a Model?
A Fine Kettle of Fish

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

Numbering Peano: Annotated

Numbering Peano: Annotated

astraendo - Exploring Abstraction.  The decks are now cleared for the Numbering Peano discussion project.  Let collaborative blogging begin.

We are going to demonstrate, with a completed software project, how little meaning there is in computer programs and how much of what is valuable about software is not found in the software itself.  We're using this technique as an avenue to communal articulation of something that matters.

Levels of Conversation.  The exploration is directed toward three areas

• Interface (API) Agreement.  We'll start out illustrating a simple interface agreement using Java Language Object-Oriented Technology.  It will be annotated and comprehensible enough to anyone.  I promise.  This is the middle(ware) layer.
     From here we can look underneath the interface to see how one delivers software that honors the agreement.  We can also look upward to see what the agreement is when viewed from the outside, with no consideration for the implementation in the underware.
    
• Application Semantics and Situated Use.  This is the higher level, the outerware and beyond.
     We will look further at how the interface is used and how it is known what the guaranteed behavior--the contract--is.   Beyond that, we want to account for what an use could be for.  We want to see where a higher-level abstraction is not just more-abstracted, it is of a different kind.
    
• Computer Implementations. We're going to build software that delivers the interface. This is the underware layer.
     We'll talk about the implementation a little, and show its use.  We won't build it here.  The development of the software will happen in a separate place organized for that purpose.  There we can dig into all of the geeky details with complete abandon.  It will be interesting to see how much detail there is, and we'll offer observations about that from time to time.

Materials.  The materials produced for and in this discussion consist of

• Numbering Peano, this web log and its archives, along with an Atom feed that provides syndication access to complete entries
• Astraendo project materials compiled for/from the discussion
• com.orcmid software packages for sample software and reference implementations

Fragmentary now, the material will be expanded and refined as the discussion progresses.

Participation.  Who is this discussion for? Who are the players?

• Initial Team Members are orcmid and anderbill.  Others can join.  Send an e-mail request to orcmid.
• Anyone can comment.  References to other material, especially articles and discussions available on the web, are welcome.
• Disagreement is tolerated.  There is a theme here, and objections to it are all right.  Errors in expressing what we intended to say will be corrected.  We may not change course just because you think we should.  Be happy that we get what your objection is.  Repeating it loudly is not productive.
• Change is the Constant.  Associated materials are updated early and often.  Blog entries are also updated as part of webbing it all together.  If you subscribe to the feed, this means you will see full re-issues of pages from time to time.  We'll work to minimize that, and it will happen.

Listening to:

Eros Ramazzotti Estilolibre, BMG (2000), Interactive CD via Media Player 9
Bonnie Raitt Luck of the Draw, CD, Capitol Records (1999)
Diana Krall "Narrow Daylight" from The Girl in the Other Room, performed live in Lisbon, MSN Windows Media Exclusive
Radio L'Olgiata.Net via Windows Media Player 9: Luca Carboni "Mi ami davvero"; Laura Pausini "E ritorno da te"; Tiziano Ferro "Xdono"; Velvet "Boy Band"; Giorgia "Di sole e d'azzuro"; Laura Pausini "Tra te e il mare"; Gina Paoli "Per una storia (d'amore)"; Pooh "Stai con me"; Pino Daniele "Sara"; Eros Ramazzotti & Cher "Più che puoi"; Eros Ramazzotti "Fuoco nel fuoco"; Matia Bazar "Questa nostra grande storia d'amore"; Michele Zarrillo "L'acrobata"; Renato Zero "Non cancellate il mio mondo"; Anna Tatangelo "Doppiamente fragili"

2004-06-05-14:04: I have been procrastinating this note for two days.  It's time to quiet the inner dork and post something.  Anything.  I'm now publicly on-the-hook for this.

posted by orcmid at 6/5/2004 04:43:07 PM

Annotating Peano Numbers

Annotating Peano Numbers

This is a new blog created specifically for a collaborative-articulation project.  The idea is to develop an understanding of abstraction, syntax, semantics, and meaning of programming-language interfaces.  We will undertake that using a concrete manifestation of Peano Numbers.  This will also be revealing about the application of mathematical abstractions in connection with engineered artifacts -- computers and programs -- and their behavior.

This post is simply to prime the pump and ensure that everything is working properly.

posted by orcmid at 6/1/2004 12:21:00 AM