Overview of the Flight Bonus example

This is a simple flight booking program, which exists in different versions.

Flight booking - bare application

Package

flightbooking is available only as jar file (

Referenced Libraries/booking.jar).

Running: This regular Java application can be invoked like a regular Java program (e.g., by click the link run the sample on the welcome sheet at the right). The main method is in

flightbooking.Main. It has a simple GUI which will direct you through the relevant transactions. Note that this variant does not include collecting bonus points.

Bonus and FlightBonus

The first scenario of adaptation concerns the definition of a bonus programme for frequent flyers. Two team classes are involved. The purpose of each team class is:

bonussystem/Bonus:: Define an abstract, re-usable concept of Subscribers that may collect credits, and BonusItems that are acquired by a Subscriber and give a specific amount of credits.
fbappication/FlightBonus:: Bind the abstract team Bonus to the flightbooking package. Other than class and method bindings, this team only adds one method implementation for calculating the credit for booking a flight segment.

Integrating the application

In order to integrate the new functionality into the GUI, even another team class exists:

GUIConnector. It adapts the original GUI in booking.jar.

Running: To invoke the variant with bonus apply the supplied launch configuration

FlightbookingWithBonus.launch. Looking at this launch configuration you will find these relevant settings:

On tab "JRE" two options are checked: Enable OTRE and Java 5 JPLIS Launching
On the tab " Team Activation" the team GUIConnector is selected for instantiation and activation.
Optional:
1. You may additionally select the team WindowPlacer which ensures that new windows are always centered with respect to the desktop/their parent.
  Note, that this team requires the "Java 5 JPLIS Launching" option (see above), because it adapts class java.awt.Window which is not adaptable using the old launch mode.

The most important step is to add a method binding to flightbooking.PassengerList.add().
The following line in fbapplication.GUIConnector.Controller is responsible for this (it's a callin binding):

queryRegisterForBonus <- after add;

Whenever a passenger is added to that list (an internal "repository"), the user is asked, whether the passenger wants to participate in the bonus programme. If so, a new FlightBonus instance is created and the passenger is implicitly registered (cf. the implementation of fbapplication.BonusGUI.Controller.queryRegisterForBonus). After that all bookings for this passenger will also give bonus credits to the passenger.

Collecting credits will be reported by a new dialog box — the nested team fbapplication.GUIConnector.FlightBonusDialog. This team defines another layer over the team FlightBonus, observing the behaviour of its roles.

OT/J concepts used

The following concepts are demonstrated and documented in the source code (

numbers refer to paragraphs in the language definition):

team inheritance and implicit inheritance of roles ( 1): There are two team inheritance relations: FlightBonus extends Bonus and GUIConnector extends BonusGUI. In both cases the contained roles are further specialized in the sub-team.
Implicit inheritance works accross levels ( 1.5): the nested team FlightBonusDialog implicitly inherits all roles from its implicit super team of the same name. The inner most roles recursively inherit from their implicit super roles.
You may want to try the special hierarchy view (F4) for exploring this implicit inheritance.
callin method bindinds ( 4): The FlightBonus and the GUIConnector teams are both triggered via callin bindings, by which they hook into the underlying system. In the case of the FlightBonusDialog the base classes are roles, too. This means roles are used to intercept events at some other roles.
callout method bindinds ( 3): Most roles access features of their base class using callout bindings.
role files ( 1.2.5): fbapplication.BonusGUI.FlightBonusDialog and fbapplication.GUIConnector.FlightBonusDialog. Each role file resides in a team package that has the same name as the enclosing team (i.e., a team is a class and a package).
team activation ( 5): The 'bootstrap' team GUIConnector is activated via the launch configuration ( 5.5). By this technique it is possible to adapt the flight booking application without changing a single line of source code. In the sequel the GUIConnector creates instances of FlightBonus and FlightBonusDialog, both of which invoke activate() ( 5.2(b)) from their constructor in order to enable all callins of contained roles.
Roles FlightBonus.Subscriber and BonusGUI.Collector restrict activation to specific instances using a guard predicate ( 5.4).
lifting ( 2.3): The constructor FlightBonus(Passenger as Subscriber s) uses declared lifting ( 2.3.2) to force creation of a subscriber role for each passenger to be registered.
The constructor FlightBonusDialog(FlightBonus fb) is a lifting constructor, which means it will implicitly be used by the lifting operation, but it can also be invoked explicitly, to create a new role for a given base instance (cf. method queryRegisterForBonus).