The design stage of domain-specific language development, which includes domain analysis, has not received as much attention compared to the subsequent stage of language implementation. This paper investigates the use of ontology in domain analysis for the development of a domain-specific language. The standard process of ontology development is investigated as an aid to determine the pertinent information regarding the domain (e.g., the conceptualization of the domain and the common and variable elements of the domain) that should be modeled in a language for the domain. Our observations suggest that ontology assists in the initial phase of domain understanding and can be combined with further formal domain analysis methods during the development of a domain-specific language.
The development of a Domain-Specific Language (DSL) requires detailed knowledge
of the domain in which the language is being targeted. Paradigms such as Generative
Programming [
Ontology development is one approach that has contributed to the early stages of
domain analysis [
Chandrasekaran et al. [
An interesting connection can be observed between ontology and DSL design. As
it relates to DSL development [
Not only is an ontology useful in the obvious property of domain terminology, but the
concepts of the domain and their interdependencies or relationships are also part of
the properties of an ontology [
As it relates to the DSL development process as a whole, the insertion of ontology
development in the early stages of DSL development can potentially provide a
structured mechanism in the part of DSL development that is still lacking attention.
The early stages of DSL development (i.e., domain analysis) have not received as
much attention compared to the latter stages of development (i.e., language
implementation). Various DSL implementation techniques have been identified in
[
Ontology development to assist in the design of a DSL is described through a case study in this section. Section 3.1 provides a summary of the air traffic communication problem domain. The ontology and its related competency questions are given in Sections 3.2 and 3.3. The development of a class diagram, object diagram, contextfree grammar, and sample program related to the DSL and obtained from the ontology is given in Section 3.4.
A case study was selected to apply the ontology development process and observe its usefulness in domain analysis related to DSL development. The case study selected focuses on the communication that occurs between the air traffic control (ATC) at an airport and the pilot of an aircraft. More specifically, the communication is between the ground controller that is responsible for the traffic between the runways and the ramps containing gates in an airport, and the pilots of an aircraft that has just arrived or is in the process of departure. The purpose is to develop a DSL that can standardize the language for the communication between the two individuals. English is the standard language in this domain, but more often the controllers or pilots of nonEnglish speaking countries may experience problems communicating in English. A DSL that standardizes the communication can be translated into the native tongue of the controller or pilot for better comprehension. A separate functionality could check and verify the path that is given to a pilot by a ground controller. An example communication sequence that highlights the potential communication problem is given in Listing 1. The controller is asking the captain to hold short of taxiway “MikeAlpha,” but the pilot continually assumes it is taxiway “November.” Listing 1. Example of air traffic communication
ATC:
GroundControl Controller in charge of airport ground traffic Class
Following the ontology development process outlined by Noy and McGuinness [
Both the Ontolingua1 and DAML2 ontology libraries were searched for existing ontologies related to the domain in this case study, but no related instances contained the vocabulary necessary for the domain. Although a new ontology is needed for this case study, the availability of an existing ontology in other cases provides a head start to the development of a domain model as the important terms and relationships have been determined already for the domain and can be used toward the subsequent steps of DSL development. 1 Ontolingua Ontology Library, http://www-ksl.stanford.edu/knowledge-sharing/ontologies/html 2 DAML Ontology Library, http://www.daml.org/ontologies
Description Arriving or departing aircraft Controller in charge of take-offs and landings Available take-off and landing locations Paths connecting runways to ramps Aircraft parking area Passenger embarkation and disembarkation Command to turn Command to hold short of a runway or taxiway Command to contact a separate controller Command to follow behind another aircraft
Slots Name
Description
Name of the airline Flight Number Flight Identification Values Two letters Integer Runway Number Runway Identification 1 – 36 (i.e., runway heading 10° – 360°) Taxiway Name Taxiway Identification One or two letters (digits)
To distinguish parallel Class Left or Right runways Ramp Identification Gate Identification Gate Identification Turning direction String One letter Integer
Taxiway Identification Class Taxiway Runway Identification Class Runway Taxiway Identification Class Taxiway Controller to contact Class Tower or
Aircraft Identification Class Aircraft
Utilizing the tool introduced by Noy and McGuinness [
Table 1 contains a selection of classes and slots of the ontology that was developed in Protégé 2000 for the case study. In addition to the classes and slots in Table 1, instances of these classes were also determined. These instances are based on the information from a simplified diagram of the Birmingham International Airport (BHM) as shown in Figure 1. For example, instances of the Runway class are 6, 24, 18, and 36. Instances of the Taxiway class are A, B, F, G, H, M, A1, A2, A3, A4, B1, G1, H2, and H4. The Ramp class consists of Cargo and Terminal.
The usefulness of the ontology in Table 1 can be measured by how well the ontology assists in answering the previously specified competency questions from Section 3.2. Regarding the first question, the ontology provides the concepts of the domain through the classes. The interdependencies between the concepts can be derived from the constraints of the slots of the classes. For example, the HoldShort class is dependent on either the Runway or Taxiway classes, as this command is always followed by the location in which the pilot is to hold short.
6
A1
H
A Cargo
H2 A2
A
H4 H A3 A4 Gates
C1-C5
F Terminal
Gates B1-B3 B
M
M
A G
G 18 B B A F F B1 G1 B G 36
A 24 Answering the second question related to commonalities and variabilities is less evident if observing only the ontology’s structure of classes and slots. Information regarding the variabilities can be extracted by including the instances of classes, such 3 Protégé 2000, http://protege.stanford.edu as the instances from BHM. Classes Runway and Taxiway consist of many instances, which could mean these classes have the variabilities property. Moreover, instances that represent airports other than BHM will also contain different values for these classes, which could also be interpreted as containing variabilities. The classes not containing instances, such as most of the commands (i.e., Turn, HoldShort, and Contact), could be interpreted as common concepts in all instances. These commands are common in the ATC domain and represent standard commands that are used in all airports. However, the specific airport elements (i.e., collection of instances of runways and taxiways) may change depending on the airport.
The ontology process is similar to the process of object-oriented analysis [
Figure 2 presents a conceptual class diagram that was manually generated from the structural information of the classes in the ontology from Table 1. In this case, the development of the class diagram has been assisted by the information obtained from the ontology. In Figure 2, similar classes are grouped together. For example, classes Gate, Ramp, Runway, and Taxiway represent physical structures in the airport. Such groupings identified the need for a generalized class for each group. A generalized class was included in the diagram for Runway and Taxiway, because from the slot properties of class HoldShort, two possible values can be used (i.e., Runway and Taxiway). In the diagram, this is represented by abstract class Way. The classes at the bottom of the diagram represent communication commands. These are associated with other classes through their respective slot properties. Generalizations such as Command and Way were not part of the original ontology and were only introduced during the development of the class diagram. These classes in turn can be used to update the ontology to further improve the structure of the ontology. This can be seen as part of the process of iteratively refining the ontology to better represent the domain.
From the class diagram in Figure 2, an initial context-free grammar (CFG) for the
DSL can be generated, as shown in Listing 2. This CFG was manually obtained from
the conceptual class diagram to CFG transformation properties defined in [
Runway -number : int -orientation : Direction 0..1
Direction
Airport -Code : string 1..* Way
Taxiway -name : string 1..* 0..*
Ramp -name : string
Gate -letter : char -number : int
1
Air Traffic Control GroundControl
Tower 1..*
Command 1
Turn 0..1 -direction : Direction 1
-taxiway : Taxiway Left
Right
HoldShort -way : Way
Contact
-atc : Air Traffic Control
The transformation of the class diagram into the CFG above, albeit manual, followed
a predefined collection of transformation rules. The manual transformation of the
ontology into the class diagram is less formal, but was done by connecting the
properties of the classes in the ontology with the graphical representation of the class
diagram. In order to provide a more automated transformation between the ontology
and the class diagram, developing a transformation between an Web Ontology
Language (OWL) instance for the ontology and a textual representation of the class
diagram could be considered. Related to this, UML-based ontology development has
been proposed [
Listing 3. Addition of keywords and production refactoring AIRPORT ::= WAYS RAMPS ATC WAYS ::= WAYS WAY | WAY WAY ::= runway RUNWAY | taxiway TAXIWAY RUNWAY ::= number DIRECTION TAXIWAY ::= name RAMPS ::= RAMPS RAMP | RAMP RAMP ::= ramp name GATES GATES ::= GATES GATE | ε GATE ::= gate letter number ATC ::= GROUNDCONTROL | TOWER GROUNDCONTROL ::= COMMANDS COMMANDS ::= COMMANDS COMMAND | COMMAND COMMAND ::= CONTACT | FOLLOW | HOLDSHORT | TURN CONTACT ::= contact ATC FOLLOW ::= follow AIRCRAFT HOLDSHORT ::= hold short WAY TURN ::= turn DIRECTION on TAXIWAY DIRECTION ::= left | right | ε AIRCRAFT ::= airlineID flightNumber
TOWER ::= tower An example of a program written in this DSL is shown in Listing 4 and is based on the CFG of Listing 3. Even from this simple DSL for ground control, it can be seen that some simple verification of aircraft path control can be checked. The development of the DSL has been aided by the ontology that was initially produced, which in turn assisted in the generation of a class diagram. This provided a means to understand the domain in the early stages of DSL development, which provided input to the subsequent structure of the DSL, as seen in the grammar in Listing 2. Listing 4. An example program // description of BHM airport runway 6 runway 24 runway 18 runway 36 taxiway A taxiway A1 taxiway A2 taxiway A3 taxiway A4 taxiway B taxiway B1 taxiway F taxiway G taxiway G1 taxiway H taxiway H2 taxiway H4 ramp Cargo ramp Terminal gate B1 gate B2 gate B3 gate C1 gate C2 gate C3 gate C4 gate C5 // commands from Ground Control turn right on A turn left on M hold short runway 18 contact tower An object diagram of the example program in Listing 4 is illustrated in Figure 3. Airport-related structures such as gates, ramps, runways, and taxiways are represented by multiple objects that will differ among various airports. However, the types of commands issued by the ground control remain the same. The specific attributes of the command objects are based on the objects of the structures of a particular airport, e.g., taxiway A and M, and runway 18. As described in Section 3.3, evaluating the instances of the classes provides information regarding the elements of the domain that are common (or fixed) and those that are variable.
runway1 : Runway number : int = 6 orientation : Direction runway2 : Runway number : int = 24 orientation : Direction runway3 : Runway number : int = 18 orientation : Direction runway4 : Runway number : int = 36 orientation : Direction
airport : Airport Code : string = BHM taxiway1 : Taxiway name : string = A taxiway2 : Taxiway name : string = A1 taxiway3 : Taxiway name : string = A2 taxiway13 : Taxiway name : string = M groundControl : GroundControl
ramp1 : Ramp name : string = Cargo
ramp2 : Ramp name : string = Terminal gate1 : Gate letter : char = B number : int = 1
gate2 : Gate letter : char = B number : int = 2
gate3 : Gate letter : char = B number : int = 3 gate4 : Gate letter : char = C number : int = 1 gate8 : Gate letter : char = C number : int = 5 tower : Tower command1 : Turn direction : Direction = right taxiway : Taxiway = A
command2 : Turn direction : Direction = left taxiway : Taxiway = M command3 : HoldShort way : Way = 18
command4 : Contact atc : Air Traffic Control = tower Section 3 summarized the development of a preliminary ontology using the standard development process as seen in literature using a well-known tool called Protégé 2000. The usefulness of the ontology was measured by answering several competency questions that were selected to match the goals of domain analysis. Domain concepts and their interdependencies were determined. In addition, commonalities and variabilities as they relate to the DSL can be determined by observing the instances of the classes in the ontology. It should be noted that the ontology and class diagram went through several iterations before reaching the state described in Section 3. However, further refinements may help to provide more satisfactory answers to the competency questions. The ontology was then used to manually generate a conceptual class diagram, which in turn produced an initial context-free grammar for the proposed DSL.
The case study has shown the potential usefulness of ontology in the development
of a DSL specifically during the early stages of development. An ontology can
provide a well-defined and structured process to determine the concepts of a domain
and the commonalities and variabilities for a DSL, which can result in the generation
of a class diagram and subsequently a CFG from the information. Two further
observations highlight the benefits of an ontology-based approach. First, if an
ontology is already available for a domain, then this existing ontology can be used to
initiate the development of a DSL without the need to start from scratch. This was not
the case for the air traffic communication domain described in Section 3, but
ontologies for other domains could already exist and be utilized in the DSL
development for those domains. Second, the entire process outlined in Section 3 could
be used as an alternative to a more formal domain analysis technique such as FODA.
In a separate direction, the ontology alone can be combined with formal domain
analysis techniques (e.g., proposed by Mauw et al. in [
De Almeida Falbo et al. describe the use of ontology in domain engineering that has
the purpose of developing software artifacts for reuse [
Gašević et al. describe efforts to associate the two technical spaces of
ModelDriven Architecture (MDA) and ontology, which include the utilization of
MDAbased UML in ontology development [
An initial investigation of the usefulness of ontology in domain analysis in DSL development was described in this paper. A case study demonstrated the insertion of ontology development in the DSL development process, where a class diagram was obtained from the ontology and subsequently a CFG was produced. The ontology assisted in answering questions related to the domain, such as the main concepts and their interdepencies, and the common and variable parts related to the DSL. The ontology also provided a structured input to the subsequent stages of DSL development. Continued exploration of ontology-driven domain analysis may provide further proof of effectiveness in the analysis of domains for DSL development.
The class diagram in Figure 2 that was generated from the ontology can also serve
as the basis for creating a metamodel. Slight adaptations of this diagram could
represent the metamodel for a tool like the Generic Modeling Environment (GME)
[
Acknowledgments. This project is supported in part by NSF grant CPA-0702764.