Translator Model Specification version 0.1.0

02-Oct-1999

Translator Model is a model of user interface (UI) programming of Jini service. This specification describes the design of it.

Organization of this specification

This specification is divided into 2 sections:

Idea of Translator Model. This section gives readers a picture about the model, but it should not be considered as the design of the model.
The design of Translator Model. This section specifies the design of translator model.

Another document, Translator Model Design Supplementary, gives explanations about why the model is designed in a such way that as specified by this specification. However, the supplementary is not a part of specification. All the specification of Translator Model is described in this document.

Language used in this specification

The section "The Design of Translator Model" is written as precise as possible. Some terms and phases of Mathematical Language are used in this section.

Section 1: The Idea of Translator Model

First, take a look on the following picture:

The upper part of the picture above shows today's UI-Programming-Model. Program side communicates to API directly (that's why programmers needs to learn Swing or AWT, the APIs of GUI), and then the API talks to IO devices and finally, a UI appears.

Translator model requires program side to talk to a translator, but not API. The content of communication between translator and program is not depended on any API. And then let the translator to talk to API, API talk to IO devices and finally a UI appears.

The picture below explains more about the mechanism of translation:

Let's focus on the upper part first.

The mechanism starts from the point when a program wants to communicate with human. Program side talks to translator via a communication object, which contains the content of communication.

Then, translator is responsible to communicate with human. To do so, the translator must get a way to talk to human, hence, the translator must construct a UI (user interface). There may be many works behind the process of constructing UI, e.g. Select IO devices, select API and design outlook of UI, but from the point of view of program side, all of these are jobs of translator.

Finally, translator is responsible to tell program the feedback of human (if any).

We can imagine there are three men, Mr. P (program), Mr. T (translator) and Mr. H(human). Mr. P and Mr. H communicates to each other through a translator, Mr. T.

Mr. P does not care "how Mr. T talks to Mr. H", Mr. P simply trusts Mr. T will tell Mr. H what he says, and trusts Mr. T will tell him what Mr. H says.

Here are the possible scenarios of the communication between Mr. P, Mr. T and Mr. H:

Mr. P talks to Mr. H

Mr. T may not understand what Mr. P said, like the following picture.

If, on the other hand, Mr. T understands what Mr. P said, then Mr. T will talk to Mr. H:

Now, there may be several different endings. One of the endings is Mr. H has listened to what Mr. T said, and gives feedback. Then Mr. T talks back to Mr. P:

Another ending is when Mr. T and Mr. H are talking, Mr. P asks for stopping the communication.

The final ending is Mr. H asks to discuss another issue:

The pictures above is a metaphor of the design of Translator Model. These pictures explain the possible scenarios of communication between program, translator and Human.

The design of Translator Model is specified in the next section.

Section 2: The Design of Translator Model

Requirement

The requirements of UI of Jini services are:

The UI of services must be able to run on different kinds client machine such that the IO devices of the client machines can be very different. .....(R1)
The UI of services must be able to run on the client machines such that the IO devices of these client machines do not exist when the services are being coded. ......(R2)
Adaptive UI [Remark] should be considered, even if adaptive UI is not planned to be implemented right now. .....(R3)

Remark: Adaptive means "a system is called adaptive if it is able to change its own characteristics automatically according to the user's needs" [Oppermann]

Terminology

UI: a UI is a medium for communication between human and service.

UI component: a UI component is a single unit in a UI.

UI-API-independent: UI-API here refers to the API of particular kind of UI or IO device, For example, but not limited to, Swing (API of GUI). Hence, UI-API-independent means a piece of code (about a UI or a UI component) which is not written in any particular API of particular kind of UI or IO device.

Client machine: The machine that runs a Jini service.

Assumption

Assumption A1:

For all u, u is a UI component, the function of u can be described by either of the following:

u presents some information to human; or
u presents some information to human and asks human feedback.

Assumption A2:

For all d, d is belonged to the description of either kind in A1, d is UI-API-independent.

Note:

A1 and A2 implies that for any u, u is a UI component, there exists a way to describe function of u such that the description is UI-API-independent.

Mechanism of Translator Model

Communication between human and machine is modeled as:

a Jini service wants to communicate with human;
The Service constructs a Communication Object, which contains the content of communication, and passes this object to translator;
Translator, supplied by client machine, accepts the Communication Object and constructs a UI based on the content of Communication Object;
Human interacts with the UI constructed by Translator;
Translator passes the human feedback, if any, to Service side.

Constraints about Communication Object

The design of Translator Model is specified by constraints which are all listed in this section.

For all UI of service which applies Translator Model, it must obey all the constraints specified in this specification.

Constraint 1.1.0

Communication Object is defined as an object such that the content of contains only:

the information Program Side to present; and
the feedback Program side asks human to give.

Comment:

This constraint is derived from Assumption A1.

Constraint 1.1.1

The content of Communication Object is UI-API-independent.

Comment:

This constraint is derived from Assumption A2.

Constraints about Translator

Constraint 2.1.0

A Translator is defined as a unit which has the responsibilities:

interprets the content of Communication Object;
constructs a UI based on the content;
presents the UI to human; and
passes feedback made by Human or response of Human active request[remark] to the service side.

Remark: "response of Human active request" will be explained by the Constraints about Human Active Request.

Constraint 2.2.0

Translator is supplied by client machine.

Comment:

Service side knows nothing about the translator. A service just assume that the API of Translator Model exists on client machine.

Constraint 2.3.0

Translator must translate the original meaning of information of Communication Object correctly.

Constraint 2.3.1

Other than Constraint 2.3.0, there exists no any restriction on the process of translating information of Communication Object to UI. For example, but not limited to, translator has the rights to decide language, selection of I/O devices, APIs, forms and outlook of UI to be constructed.

Comment:

This constraint makes a room for adaptive UI to be possible.

Constraint 2.4.0

Translator must translate the information made by human, in other words: feedback, to service side correctly.

Constraint 2.4.1

Other than Constraint 2.4.0, there exists no any restriction on the process of translating human feedback to service side.

Comment:

This constraint makes a room for adaptive UI to be possible.

Constraint 2.5.0

Translator decides when to terminate a UI.

Comment:

The idea behind this constraint is that UI is the object used for communication between translator and human. Hence, it is the job of translator to terminate a UI.

This constraint implies that translator must be able to know when human has finished the feedback action or has finished receiving information presented by a UI.

Constraints about Human Active Request

Constraint 3.1.0

Whenever translator and human are communicating, human can ask for starting options other than the task(s) of current UI. Such requests of human are called Human Active Request.

Comment:

In the traditional model of UI, human is standing at a passive position. Human can only choose the options provided by program side.

The Translator Model, however, allows (and forces) human can make requests actively. When user does not want to go on the tasks on the current UI (in other words, user does not want to go on the task/issue program side is doing), user can ask for giving up the current communication (or say UI) and start another task/issue (or say start other options).

Constraint 3.1.1

ActiveResponse is defined as the list of all possible responses to the human active requests.

Comment:

Note that the content of ActiveResponse object can vary all the time. That means at different moment of process of communication, service side is free to give different response to human's active requests.

Constraint 3.1.2

Translator must provide a way for human to make active requests.

Comment:

In practical, "how to do so" is left for client machine.

Constraint 3.1.3

After human makes an active request, translator must decide which response, the responses are provided by the ActiveResponse object (passed to translator as a parameter of method beginConversation() ), to be selected, in the process of this decision, translator can ask human to pick a choice or can make the decision by itself.

Constraint 3.2.0

If ActiveResponse object is null, it means service side, at the current moment, does not response to human's active requests. In such case, it is the responsibility of translator to tell human that no active request is allowed.

Constraint 3.3.0

If human have made an active request, then all human feedback to the questions asked by service should be considered as not valid.

Constraints about API-- Package translator.model.core

Constraint 4.1.0

Client machine must provide all interfaces and abstract classes and classes of the package translator.model.core and no any modification is allowed to be made on all interfaces and abstract classes and classes in this package.

package translator.model.core;

public interface Presentation
{
}

Constraint 5.1.0

A Presentation object is defined as a unit which contains the information presented by service and no any human feedback is required.

package translator.model.core;

public interface Question
{
public String helpInfo();
}

Constraint 6.1.0

A Question object is defined as a unit which contains the information presented by service and requires human feedback.

package translator.model;

import translator.model.core.CommObject;
import translator.model.activeComm.ActiveResponse;
import translator.model.exception.CannotTranslateException;
import translator.model.exception.CommunicatingException;

public interface BasicTranslator

{
static int HumanFeedbackOK = 0;
static int HumanActiveRequest = 1;

public int beginConversation(CommObject commobj, ActiveResponse actresp)
throws CannotTranslateException, CommunicatingException;
public void stopConversation();

}

package translator.model.core;

import translator.model.core.Presentation;
import translator.model.core.Question;
import translator.model.commContent.presentation.Brief;
import translator.model.commContent.question.Confirmation;
import translator.model.exception.ConfirmationConstraintException;
import translator.model.exception.BriefConstraintException;
import translator.model.exception.CommContentException;public class CommObject

public class CommObject
{
     public CommObject(Brief brief, Presentation[] presents, Question[] quests)
               throws translator.model.exception.ConfirmationConstraintException,
               translator.model.exception.BriefConstraintException,
               translator.model.exception.CommContentException
     { ....}

public Brief brief()
{....}

public Presentation[] presentations()
{ ....}

public Question[] questions()
{ .... }
}

Remark: the implementations are omitted.

Constraint 7.1.0

A CommObject object is defined as a unit which contains the information of communication.

Constraint 7.2.0

For the parameters of constructor of CommObject, the following cases are allowed:

presents is null and quests is not null; or
presents is not null and question is null; or
both presents and quests are not null.

and Brief can always be null.

The following case is not allowed:
both presents and quests are null. In such case, CommContentException will be thrown.

Constraint 7.3.0

The method brief() returns the parameter brief of constructor.

Constraint 7.4.0

The method presentations() returns the parameter presentation array of constructor.

Constraint 7.5.0

The method questions() returns the parameter question array of constructor.

Constraints about API-- Package translator.model

Constraint 8.1.0

Client machine must provide all interfaces and abstract classes and classes of this package.

Constraint 8.1.1

Implementation of all the classes in this package is left for individual client machines.

package translator.model;

import translator.model.core.CommObject;
import translator.model.activeComm.ActiveResponse;
import translator.model.exception.CannotTranslateException;
import translator.model.exception.CommunicatingException;

public class Translator
{
   public void beginConversation(CommObject commobj, ActiveResponse activeresp)
                     throws CannotTranslateException, CommunicatingException
{
   }

   public void stopConversation()
   {
   }
}

Constraint 9.1.0

For all implementation of Translator, it must implement the BasicTranslator interface.

Constraint 9.2.0

Translator is responsible for holding conversation with human based on the content of communication required by service. Hence the method beginConversation(CommObject commobj).

Constraint 9.2.1

Based on Constraint 2.5.0, Translator is responsible for determining when to exit the method beginConversation(CommObject commobj).

Constraint 9.2.2

Translator is responsible for stopping a conversation whenever service side calls for stop. Hence the method stopConversation().

Comment:

stopConversation() should be called by service side only.

Constraint 9.3.0

For the parameter CommObject of constructor of Translator cannot not be null, otherwise, CannotTranslateException will be thrown.

Constraints about API-- Package translator.model.commContent.presentation

Constraint 10.1.0

Client machine must provide all interfaces and abstract classes and classes of this package.

Constraint 10.1.1

Individual client machine has right to overwrite the implementation of classes of this package.

package translator.model.commContent.presentation;

import translator.model.core.Presentation;

public class Brief implements Presentation
{
public Brief(String info)
{ ....}

public String info()
{....}
}

Remark: implementations are not listed.

Constraint 11.1.0

Brief is defined as the brief of content of communication.

Constraint 11.1.1

The content of a Brief must be written in a such way that no any part of the information of a communication content will be missed if brief is not presented to human. Translator has no right to omit a Brief of CommObject object, however.

Constraint 11.2.0

A CommObject can contain at most one brief object only, otherwise, BriefConstraintException will be thrown.

Comment:

This constraint implies that the parameter presents of constructor cannot contain any Brief object.

Constraint 11.3.0

The parameter info of constructor of Brief cannot be null, otherwise, CommContentException will be thrown when a such Brief object is passed to construction of CommObject object.

Constraint 11.3.1

The parameter info of constructor of Brief carries the information of brief.

Constraint 11.4.0

The method String info() returns the parameter info of constructor.

package translator.model.commContent.presentation;

import translator.model.core.Presentation;

public class GenInfo implements Presentation
{
public GenInfo(String info)
{....}

public String info()
{....}
}

Remark: implementations are not listed.

Constraint 12.1.0

GenInfo is defined as a peice of information to be presented to human.

Constraint 12.2.0

The parameter info of constructor of GenInfo cannot be null, otherwise, CommContentException will be thrown when a such GenInfo object is passed to construction of CommObject object.

Constraint 12.2.1

The parameter info of constructor of GenInfo carries the information of GenInfo object.

Constraint 12.3.0

The method String info() returns the parameter info of constructor.

package translator.model.commContent.presentation;

import translator.model.core.Presentation;

public class Keypoint implements Presentation
{
    public Keypoint(String info)
    {
    ....
    }

   public String info()
    {
    ....
    }
}

Remark: implementations are not listed.

Constraint 13.1.0

Keypoint is defined as the key point of a certain paragraph of informaiton.

Constraint 13.2.0

The parameter info of constructor of Keypoint cannot be null, otherwise, CommContentException will be thrown when a such Keypoint object is passed to construction of CommObject object.

Constraint 13.2.1

The parameter info of constructor of Keypoint carries the information of key point.

Constraint 13.3.0

The method String info() returns the parameter info of constructor.

Constraints about API-- Package translator.model.commContent.question

Constraint 14.1.0

Client machine must provide all interfaces and abstract classes and classes of this package.

Constraint 14.1.1

Individual client machine has right to overwrite the implementation of classes of this package.

package translator.model.commContent.question;

import translator.model.core.Question;

public class Confirmation implements Question
{
/*
* question: the question to ask human.
* yes: the string representing yes.
* no: the string representing no.
* helpinfo: help information about Confirmation
*
*/
public Confirmation(String question, String yes, String no, String helpinfo)
{....}

public String question()
{....}

public String yes()
{....}

public String no()
{....}

public String helpInfo()
{....}

/*
* This method should be called by translator.
*
*/
public void setConfirmed(boolean isConfirmed)
{....}

public boolean isConfirmed()
{....}
}

Remark: implementations are not listed.

Constraint 15.1.0

Confirmation is defined as a unit which asks human to confirm something and human can only answer yes or no.

Constraint 15.1.1

A CommObject can contain one Confirmation object only. If a CommObject contains a Confirmation object, it cannot contain any other question object.

If this constraint is not obeyed, then ConfirmationConstraintException will be thrown.

Constraint 15.2.0

The parameters question, yes and no of constructor of Confirmation cannot be null, otherwise, CommContentException will be thrown when a such Confirmation object is passed to construction of CommObject object.

Constraint 15.2.1

The parameter helpinfo of constructor of Confirmation can be null.

Constraint 15.2.2

The parameter question of constructor of Confirmation is the question asking human to confirm.

Constraint 15.2.3

The parameter yes of constructor of Confirmation is the string for displaying option of positive asnwer.

Constraint 15.2.4

The parameter no of constructor of Confirmation is the string for displaying option of negative asnwer.

Constraint 15.2.5

The parameter helpinfo of constructor of Confirmation is help information.

Constraint 15.3.0

The method String question() returns the parameter question of constructor.

Constraint 15.4.0

The method String yes() returns the parameter yes of constructor.

Constraint 15.5.0

The method String no() returns the parameter no of constructor.

Constraint 15.6.0

The method String helpInfo() returns the parameter helpInfo of constructor.

Constraint 15.7.0

The method setConfirmed() should be called by translator only. This method receives the feedback of human.

Constraint 15.8.0

The method isConfirmed() tells whether human confirms yes (return true) or no (return false). For a newly instanciated Confirmation object, this method returns false.

package translator.model.commContent.question;

import translator.model.core.Question;

public class Openend implements Question
{
/*
* question: the question to ask human, cannot be null.
* defaultAnswer: the default answer of quesiton, can be null.
* helpinfo: help information about Confirmation, can be null
*
*/
public Openend(String question, String defaultAnswer, String helpinfo)
{....}

public String question()
{....}

public String defaultAnswer()
{....}

public String helpInfo()
{....}

/*
* This method should be called by translator.
*
*/

protected void setAnswer(String answer)
{....}

public String answer()
{....}

}

Constraint 16.1.0

Openend is defined as an openend quetsion.

Constraint 16.2.0

The parameter question of constructor cannot be null, otherwise, CommContentException will be thrown when a such Confirmation object is passed to construction of CommObject object.

Constraint 16.2.1

The parameters defaultAnswer and helpinfo of constructor can be null.

Constraint 16.2.2

The parameter quetsion of constructor is the question asking human.

Constraint 16.2.3

The parameter defaultAnswer of constructor is the default answer of the question.

Constraint 16.2.4

The parameter helpinfo of constructor is the help information.

Constraint 16.3.0

The method String question() returns the parameter question of constructor.

Constraint 16.4.0

The method String defaultAnswer() returns the parameter defaultAnswer of constructor.

Constraint 16.5.0

The method String helpInfo() returns the parameter helpInfo of constructor.

Constraint 16.6.0

The method setAnswer() should be called by translator only. This method receives the feedback of human.

Constraint 16.7.0

The method returns the feedback of human (if any). For a newly instanciated Openend object, this method returns null.

Reference

Oppermann:

Adaptive User Support Ergonomic Design of Manually and Automatically Adaptable Software, edited by Reinhard Oppermann, page 2.