4.2 BNF Syntax

We use a ``graphic BNF'' for defining the graphic abstract grammar of the YAON language. In this context ``graphic'' means that we have terminals and nonterminals which can be icons. Abstract syntax treat the language as a set of trees and it is specified using the same kind of context-free grammar that is used for concrete syntax but without worrying about the ambiguity.

This grammar is defined as a 4-tuple where NT is the set of non-terminals, T is the set of terminals, S is the starting symbol, and P are the production rules. It is verified that:

• $NT \cap T = \emptyset$;
• $S \in NT$;
• $P \subseteq NT \times (NT \cup T)$.

This ``graphic BNF'' is introduced in four steps. First we describe what is a class system with single inheritance. In a second step we define the grammar for interfaces. Later, the clientship relationship is introduced together with the two previous steps and finally the module system is incorporated.

Class System 
First Step 
A class system with single inheritance is nothing but a tree. The nodes are classes with subclasses and the leaves are classes with no subclasses. Formally it is defined as follows:

where:

• $NT = \mbox{ \{$G, \mbox{ $\bullet\bullet\bullet$ }$\} }$

• $T = \left\{\mbox{ \mbox{\scriptsize \begin{tabular}[c]{\vert c\vert}\hline \t... ...0){$\bigtriangleup$ } \put(0, 0){$\ $ } \end{picture}\end{tabular}} } \right\}$

• S = G

• P is the set of productions below.

$\begin{array}[t]{rcl} G & ::= & \mbox{\scriptsize \begin{tabular}[c]{\vert ... ...end{picture}\end{tabular}} \mbox{ $\bullet\bullet\bullet$ }\right. \end{array}$

Second Step 
Now we define the grammar for interfaces. Interfaces can have sub-interfaces just like classes can have subclasses. An interface can extend more than one interface. The grammar for interfaces is as follows:

• $NT = \mbox{ \{$G, \mbox{ $\circ\circ\circ$ }$\} }$
• $T = \left\{\mbox{ \mbox{\scriptsize \begin{tabular}[c]{\vert c\vert}\hline \t... ...0){$\bigtriangleup$ } \put(0, 0){$\ $ } \end{picture}\end{tabular}} } \right\}$
• S = G
• P is the set of productions below.

$\begin{array}[t]{rcl} G & ::= & \mbox{\scriptsize \begin{tabular}[c]{\vert... ...p$ } \end{picture}\end{tabular}} \mbox{ $\circ\circ\circ$ }\right. \end{array}$

Third Step 
In the third step we put together the two previous steps and the clientship relationship arrow (CR) is added. This relationship is allowed between classes or from a class to an interface. New terminals and non-terminals have been added to the grammar in order to define this new relationship. Putting everything together, we get the following grammar:

• $NT = \mbox{ \{$G, \mbox{ $\bullet\bullet\bullet$ }, \mbox{ $\circ\circ\circ$ }, INT, CR, MCR$\} }$
• $T = \left\{ \mbox{\scriptsize \begin{tabular}[c]{\vert c\vert}\hline \textrm... ...{$\ $ }} \put(0, 10){\vector(1, 0){35}} \end{picture}\end{tabular}} \right \}$
• S = G
• P is the set of productions below.

$\begin{array}[t]{rcl} G & ::= & \mbox{\scriptsize \begin{tabular}[c]{\vert... ...hline \\ \hline \\ \hline \end{tabular} \end{tabular} } \right. \end{array}$

Last Step 
Finally, we add to the grammar the concept of package and the import relationship between packages. Packages are a syntactic mechanism to group classes. Also, packages can contain packages. Putting everything together we get the following language:

• $NT = \left\{\mbox{G, \mbox{ $\bullet\bullet\bullet$ }, \mbox{ $\circ\circ\cir... ...0, 0) \put(0, 0){\framebox (50, 50){}} \end{picture} \end{tabular} } }\right\}$
• $T = \left\{\mbox{ \mbox{\scriptsize \begin{tabular}[c]{\vert c\vert}\hline \t... ...} \put(4, 4){\framebox (40, 40){ \ }} \end{picture} \end{tabular} } } \right\}$
• S = G
• P is the set of productions below.

$\begin{array}[t]{rcl} G & ::= & \framebox{ \mbox{\scriptsize \begin{tabular... ...0) \put(0, 0){\line(1,0){28}} \end{picture} } \thinlines \right. \end{array}$

where $\mbox{ $\bullet\bullet\bullet$ }, \mbox{ $\circ\circ\circ$ }, MCR$ and INT are defined as in the previous step.

In this approach, we have presented boxes for classes and arrows for clientship relationships as terminals without taking into account that a class can have a set of visibility modifiers as well as special modifiers as defined in tables 3 and 4. Arrows for clientship relationship have also options as mentioned in subsection 3.2. The optional clientship should be also included in this syntax annotations as defined in 3.3. These have not been done in order to simplify this syntactic approach.