A SpaceCraft Team Defining The Martians Organisational Modelling Notes Concept map

Example

This example has been called the "Hello World" application for Team Programming. It is a toy application to simulate a spacecraft with Martians flying to Earth to greet the Earthlings. A Martian spacecraft is flown in a particular way, which requires a pilot to fly the spacecraft and a crew to look out for the destination. Once at the destination is reported by the crew, the pilot stops flying, and a Martian who is selected for the greeter role, greets the Earthlings.

The point is that the advantage with Team Programming only shows up if there is some complexity to the problem, and in particular, it requires some small amount of organisational structure in order for the team concept to make good sense. Although the example is quite artificial, we can find a number of similar more serious applications. For example, without straining things too much, this kind of application could be a mobile data collector for a sensor network. Such a unit would include similar kinds of separate functions, to deal with mobility, sensing and mission objective in an effective orchestration. Of course in that case the modelling might not stop at the data collection units, but extend across the sensor network, with, perhaps, sensors organised according to geography, function, data etc., and more complex organisation dynamics.

For the "Hello World" example, we draw up the central process model in GORITE for a "visit a planet" goal through a code snippet like the one below. A reader not quite familiar with Java might still make some sense from the code by knowing that the phrase form "new Goal [] { A, B, ... }" simply means an aggregate (an array) of goals A, B, etc. The code snippet, which is actual GORITE code, shows a Java statement using GORITE elements to represent the process model of how to achieve the specified "visit a planet" goal. It is a Goal Oriented process model expressed as a goal hierarchy where a goal is achieved by means of achieving sub goals.

addGoal( new SequenceGoal( "visit a planet", new Goal [] {
  new ParallelGoal( "fly to destination", new Goal [] {
    new TeamGoal( "pilot", "fly spacecraft" ),
    new ControlGoal( "arrived", new Goal [] {
      new TeamGoal( "crew", "look out" )
    } )
  } ),
  new TeamGoal( "greeter", "greet" )
} ) );

The goal hierarchy is formed by using Goal objects, where the top and inner hierarchy nodes represent composite goals that are achieved by means of achieving their sub goals in certain ways. In the snippet above, the top level goal "visit a planet", has two sub goals, "fly to destination" and for the "greeter" to "greet", to be achieved in sequence. The first of them, "fly to destination", has two parallel sub goals: for the "pilot" to "fly spacecraft", and the "arrived" goal of ending "fly to destination" with success when the "look out" goal performed by "crew" succeeds. (The ControlGoal goal has process model semantics beyond success and failure, namely, to force an enclosing parallel goal execution to succeed. See section More Details for further details)

The leaf level nodes in a goal hierarchy are task goals with respect to the modelled process. This simply means that they are defined elsewhere and not within the process model at hand. The leaf goals in the code snippet refer to organisational roles, and they declare that the fillers of the indicated roles should achieve the indicated goals; when the process model is executed and the role filler goals arise, the role fillers are free to choose their methods to achieve their goals, which they do by referring to their own capabilities.

In words, the "visit a planet" process model is set out as follows:

First the Performer that fills the "pilot" role is asked to achieve a "fly spacecraft" goal, and in parallel, the Performer that fills the "crew" role is asked to fill the "look out" goal.
Eventually, when the "crew" "look out" goal succeeds, the "pilot" "fly spacecraft" goal is interrupted, and the "fly to destination" succeeds.
Then the Performer that fills the "greeter" role is asked to achieve the "greet" goal.
When all is achieved in that way, then the "visit a planet" goal has been achieved.

The word Performer is highlighted because it names the GORITE class that is used for representing the entities that fill roles and have capabilities to achieve goals. There is a Team class and a Performer class, both of which are used to, in an object oriented way, define the organisational potential, i.e. the types of entities that the desired organisation involves. The particular organisation is formed by instantiating the appropriate organisational units, and link them into the organisational structure. Conceptually, a Team is an organisational unit that may have sub units, and it is also a Performer, which is an organisational unit that may be a sub unit.

A SpaceCraft Team

Organisational modelling in GORITE has five aspects: two aspects that concern the organisational potential or which types of entities an application make use of, and three aspects that concern the actual formation and deployment of performers for performing goals. This section and the next illustrate these aspects for the example application.

For our example, we are looking a defining a SpaceCraft Team type with a "flight staff" TaskTeam to deploy for the "visit a planet" goal. The code snippet below outlines the SpaceCraft Team type definition. It defines SpaceCraft as a type of Team, which when created, is set up with a "flight staff" TaskTeam that consists of "pilot", "crew" and "greeter" roles, and a process model for achieving a "visit a planet" goal.

public class SpaceCraft extends Team {
  public SpaceCraft(String name) {
    super( name );
    setTaskTeam( "flight staff", new TaskTeam() {{
      new Role( "greeter", new String [] { "greet" } ),
      new Role( "pilot", new String [] { "fly spacecraft" } ),
      new Role( "crew", new String [] { "look out" } )
    }} );

    addGoal( new SequenceGoal( "visit a planet", new Goal [] {
      deploy( "flight staff" ),
      new ParallelGoal( "fly to destination", new Goal [] {
        new TeamGoal( "pilot", "fly spacecraft" ),
        new ControlGoal( "arrived", new Goal [] {
          new TeamGoal( "crew", "look out" )
        } )
      } ),
      new TeamGoal( "greeter", "greet" )
    } ) );
  }
}

We note that the "visit a planet" goal hierarchy includes the initial step to deploy the "flight staff" task team for performing the goal. This additional step establishes which particular performers of the team to use for the particular execution; it dynamically defines the local meaning of the role references "pilot", "crew" and "greeter" in the goal execution.

The types of entities to define include the Team and Performer extensions that represent the organisational unit types. Further it includes defining which groups of roles a team has, to deploy for performing its goals. This is called task team, and is represented by a TaskTeam class, which is instantiated and filled with Role objects in order to represent a role group in a Team. Depending on the complexity of a Team, there will be one or more TaskTeam definitions, and these may be declared upfront or be formed dynamically to deploy for particular goals.

As shown in the code snippet, the "flight staff" TaskTeam includes three roles, and each role is defined to require a filler of a particular ability in terms of goals. Thus, to fill the "pilot" role, a performer must be able to achieve the "fly spacecraft" goal, the "crew" role requires the "look out" goal and the "greeter" must be able to "greet". This is an interface declaration that links the "visit a planet" orchestration with the particular abilities it exercises of its performers.

We note that the code snippet is a complete definition of the SpaceCraft Team type. The example application needs to create one instance of this type for representing one particular spacecraft, and it needs to ask that spacecraft to achieve a "visit a planet" goal.

Defining The Martians

The SpaceCraft Team is attributed with an orchestration plan to achieve the "visit a planet" goal by means of coordinating the Martians in the roles of "pilot", "crew" and "greeter". To this end, the Martians need to be able to perform the functions their roles require.

GORITE includes a Capability class that is used for composing abilities into functional units. For this example, we invent the capabilities SpaceCraftFlying, SpaceGazing and Greeting to cater for the required abilities of the three roles. The following code snippet presents a simple Greeting capability definition, where the "greet" goal is defined as a task goal that is achieved by means of making a line of console output.

The code snippet is also an illustration of the transition from GORITE goal processing to application Java code, which is done by means of re-implementing the "execute" method of the Goal class. We discuss goal processing in more detail later in the More Details section.

public class Greeting extends Capability {
  public Greeting() {
    addGoal( new Goal( "greet" ) {
      public States execute(Data d) {
        System.out.println( "Hello " + d.getValue( "destination" ) );
        return PASSED;
      }
    } ) );
  }
}

The Greeting Capability above is quite simple. In general a capability may include any number of goal hierarchies of any complexity as well as sub capabilities of any complexity, and further, as a Java class, it may include any methods and members that might be needed in order to implement the desired function or functions. Generally speaking, this is where the functional design gets mapped into implementation concepts, which at the end of the day is a collection of capability type definitions. (Capabilities may also be built dynamically, in which case they exist as particular un-named competences rather than types)

Continuing the example, the reader may imagine the three capabilities SpaceCraftFlying, SpaceGazing and Greeting being properly defined. If we then would be short of time, we could use them to create an application in the following way.

public class Main {
  public static void main(String [] args) {
    Team t = new SpaceCraft( "explorer" );
    t.addPerformers( new Performer [] {
      new Performer( "ralph" ) {{
        addCapability( new SpaceCraftFlying() ); }},
      new Performer( "dennis" ) {{
        addCapability( new SpaceGazing() ); }},
      new Performer( "jacquie" ) {{
        addCapability( new Greeting() ); }}
    } );
    ...
  }
}

By that code snippet, which is an application "main" method, three individual performers with individual capabilities are created, and these are added to the "explorer" SpaceCraft. (The ellipsis indicates that there is some code omitted, which includes asking the team to perform the "visit a planet" goal). The three performers are set up as members of the SpaceCraft Team, and these are the ones considered for populating the "flight staff" TaskTeam, where they will be selected to fill roles on the basis of their abilities.

An alternative, more well-designed approach is to define a Martian Performer type, as illustrated by the following code snippet.

public class Martian extends Performer {
  public Martian(String name) {
    super( name );
    addCapability( new SpaceCraftFlying() );
    addCapability( new SpaceGazing() );
    addCapability( new Greeting() );
  }
}

In that definition, a Martian type is introduced as a well-trained Performer that can take on any of the three "flight staff" roles. The corresponding application "main" method would create and add Martian instances to the "explorer" SpaceCraft Team. This is illustrated in the following code snippet.

public class Main {
  public static void main(String [] args) {
    Team t = new SpaceCraft( "explorer" );
    t.addPerformers( new Performer [] {
      new Martian( "ralph" ),
      new Martian( "dennis" ),
      new Martian( "jacquie" )
    } );
    ...
  }
}

We note that in the second modelling alternative, the "flight staff" TaskTeam can be populated in many different ways; any Martian can perform any of the roles. Though, by the default population method, the roles will be filled distinctly by different performers.

Organisational Modelling Notes

As noted above, the GORITE Organisational Modelling involves five aspects, which are:

to define types of organisational units, which is done by defining Java classes that extend Team or Performer;
to define groups of roles, or task teams, within teams, which is done by using the TaskTeam and Role classes;
to build the organisational structure, which is done by adding performers to teams;
to populate task teams, which as in the example, may be done by utilising the default task team population function, or it may be done be explicitly declaring performers to fill roles; and finally,
to establish the role fillers in goals being performed, which as in the example, may be done be means of the "deploy" utility method.

Only the first aspect is strictly a compile-time definition in GORITE, while the other four are made in run-time structures, and the last aspect in particular, which is to deploy a particular task team to achieve a particular goal, typically occurs as part of that goal processing. The diagram below presents a concept map for GORITE with respect to organisational modelling:

The RoleFilling class is generally not used explicitly, but indirectly as part of populating a TaskTeam, where it represents an individual role filling. We note that role filling includes the notion of multi-filled role, where there are multiple fillers to a role. In that case, the fillers are treated as one in the eyes of the team, and goals directed to the role are achieved by all fillers in parallel. This is discussed further here.

The right-hand side of the concept map above shows how the organisational modelling ties in with the process modelling by virtue of the organisational units being capabilities, i.e. having methods for achieving goals. In that way each unit contains the process models by which it operates.

This manner of software design applies an analogy to a human organisation, using the concept of team to represent an organisational unit that on the one hand is regarded as a performer in processes spanning multiple units, and on the other hand achieves its goals through its internal coordination of its sub units.