WO2009144576A1

WO2009144576A1 - Instantiating a state machine

Info

Publication number: WO2009144576A1
Application number: PCT/IB2009/005787
Authority: WO
Inventors: Sorin Basca; Joseph Spracklen
Original assignee: Nokia Corporation
Priority date: 2008-05-30
Filing date: 2009-06-01
Publication date: 2009-12-03
Also published as: GB2460467A; GB0809934D0

Abstract

A method of specifying a finite state machine so instructions for instantiating the state machine am specified in an application file and parameters relating to the states, events and transitions of the state machine arc specified in a resource file, independent of the application file. Furthermore, a method of specifying a state machine so that the state machine is capable of passing information sυch as return messages as a result of undergoing a transition. A plurality of state machines capable of passing information between one another.

Description

INSTANTUTTNG A STATE MACHINE

TECHNICAL FIELD

Embodiments of this invention relate to instantiating state machines. Some embodiments also relate to modelling tools.

BACKGROUND TO THE INVENTION

State machines, in the form of finite state machines (where the states are enumerable and known), are used as models for modelling a number of systems, e.g. Software code components and analogue electronics.

SUMMARY OF THE INVENTION

An example embodiment of the invention provides a method comprising: specifying one or more instructions for instantiating a finite state machine; and specifying one or more parameters used by said instructions to describe characteristics of said finite state machine; wherein said parameters are specified separately to said instructions.

A further embodiment of the invention provides a method comprising: specifying one or more instructions for instantiating a finite state machine; and specifying at least one parameter used by said instructions to implement said finite state machine, said parameter including characteristics of said states and said transitions, and at least one outcome transmitted on transition from at least one of said states to another of said states.

According to a further embodiment of the invention, a method of specifying a plurality of finite state machines is provided where at least a first of said state machines is specified as herein described and wherein the method includes the step of specifying a second of said state machines so that said second state machine receives said outcome from said first state machine and reports said outcome to a parent of said second state machine.

According to a further embodiment of the invention, a specification for a state machine is provided, said specification being compiled according to the methods herein described.

According to a further embodiment of the invention, an operating system for a computing device is provided, said operating system comprising a plurality of applications, at least one of said applications instantiating a state machine, wherein said state machine is specified according to any one of the methods herein described.

According to further embodiments, the invention provides one or more of the following: apparatus comprising: a processor; and memory comprising computer code, the memory and the computer code configured to, with the processor, cause the apparatus to perform: specifying one or more instructions for instantiating a finite state machine; and specifying one or more parameters used by said instructions to describe characteristics of said finite state machine; wherein said parameters are specified separately to said instructions; and apparatus comprising: a processor; and memory comprising computer code, the memory and the computer code configured to, with the processor, cause the apparatus to perform: specifying one or more instructions for instantiating a finite state machine; and specifying at least one parameter used by said instructions to implement said finite state machine, said parameter including characteristics of said states and said transitions, and at least one outcome transmitted on transition from at least one of said states to another of said states.

In other embodiments, processor means may be provided, which can be implemented as one or more processor cores.

Embodiments of the invention may be implemented in software, or in a combination of software and hardware.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described by way of example with reference to the accompanying drawings in which:

Figure J is a schematic diagram of a mobile computing device suitable for carrying out an embodiment of the invention;

Figure 2 is a schematic diagram of portions of the computing device of Figure 1 ; Figure 3 is a schematic illustration of a portion of the mobile computing device of Figure l;

Figure 4 is a process diagram illustrating the manner of operation of a finite state machine according to an embodiment of the invention;

Figure 5 is a schematic diagram of a finite state machine of a portion of a messaging system;

Figure 6 is a schematic diagram of a finite state machine of a further portion of the messaging system of Figure 4; and Figure 7 is class diagram depicting class relationships according to an instantiation of an embodiment of the invention.

DESCRIPTION OF EMBODIMENTS

In what follows reference is made to the use of state machines in software engineering, but it is to be realised that the discussion is equally applicable to other applications of finite state machines such as analogue electronics. In one example, a finite state machine includes a list of possible states in which the modelled system can exist, transitions between those states and the events which cause the transitions between states. Transitions are precipitated by events causing a change in state of the system. When implemented in software, the system under consideration is often a class of an object-orientated language, It is to be realised however that an object specified in an object-orientated programming language may, and very often does, correspond to a real-life object or system.

Figure 1 is a schematic diagram of a mobile computing device 10, which represents an example of a device that may benefit from using embodiments of the invention. The device TO has a casing 12, which encapsulates a keypad 14, a screen 16, a speaker 18 and a microphone 20. The device 10 further includes an antenna 22. The mobile computing device 10 illustrated in Figure 1 may function as a phone and, in this instance, sends and receives telecommunication signals via antenna 22.

Figure 2 is a schematic illustration of certain components of the mobile computing device 10. Device 10 includes a kernel 12 which represents part of an operating system of the device 10. In the embodiment shown, the operating system is the Symbian operating system. The kernel 12 is connected to a volatile system memory 26 which is controlled by means of a memory management unit 34. Device drivers 18, 20 and 22 are connected to the kernel 12 and control the behaviour of, and communication with, respective hardware devices: keyboard 14, display 16 and network card 24. It is to be realised that the mobile computing device 10 of this example includes many more devices and components than those illustrated here. The kernel 12 controls the operation of the mobile device 10 by regulating input received from the hardware devices such as keyboard 14, display 16 and network card 24 and hy controlling the execution of applications and access of data stored on the volatile system memory 16.

As stated, embodiments of the present invention relate to finite state machines and the specification and instantiation of such state machines. Such finite state machines are often involved in application specification in that they are used by a software engineer when coding a software application and as a tool for modelling the operations of a software application. However, finite state machines may also be used to mode] a manner in which the kemet 12 communicates with, receives input from, and directs output to, the hardware devices of the mobile computing device 10 and other mobile computing devices. Furthermore, state machines may be used when designing and manufacturing printed circuit boards (which may, in turn, be used in the manufacture of the mobile computing device 10) and in other known applications. Figure 3 illustrates a portion of the mobile computing device illustrated in Figures 1 and 2. Figure 3 depicts the kernel 12 and the file system 26. The information of the file system 26 is arranged into a plurality of files. In the embodiment illustrated, an executable file 30 stores an application which, when run, directs the operation of the mobile computing device as controlled by the kernel 12. The kernel 12 will cause the instructions in the executable file 30 to be executed in a known manner which results in application 34 as illustrated by arrow 32. In the embodiment shown, the application 34 includes a Finite state machine, the instructions for the instantiation of which are specified in the executable file 30. The finite state machine includes a number of states and transitions between the states caused by events in a manner known in the art and as further described below. However, the present embodiment differs from known finite state machines in that the arguments taken by the instructions of the executable file 30 are specified in a data file 38, also stored in the file system 26 but distinct from, and tn a file separate to, executable file 30. These arguments define the states, transitions between states, events causing the transitions and any outcomes to be reported to the parent. Therefore, during operation of the application 34 reference is made to the data file 38 (as represented by arrow 36) by instructions of the application 34 to determine characteristics of the finite state machine contained in the application 34.

In the embodiment shown, the data file 38 maintains a list of the states of the finite state machine and the acceptable events which cause transitions between states as well as possible outcomes for the operation of the state machine. The data file contains a specification of states and, for each state, a list of acceptable events and their corresponding transitions (identified by resultant states). The data file may also optionally specify a function to be called on the occurrence of a transition. Furthermore, the data file may create a correspondence between outcomes of operations requested by the state machine and events so that input to the state machine dictates an operation of the state machine. Figure 4 is a process diagram illustrating the operation of a finite state machine specified according to an example embodiment of the invention. Block 44 represents the base state in which the finite state machine awaits an input. At block 46 the finite state machine receives an input and, at the next block 48 raises an event. The event will lead to a transition 49, as denoted in Figure 4 by a dashed box. In this example embodiment, the state machine will always perform a transition, even if that transition is to the same state. However, in an alternative embodiment, the state machine will determine whether a transition is specified and only perform the transition where a different target state is specified. As described below, the transition comprises updating the state running any specified function, dealing with exceptions and any outcomes. The input to the state machine which results in an event will depend on the implementation of the state machine. Any suitable occurrence may be specified as an input for a state machine. For example, the previous transition of the state machine may serve as the input which leads to the event precipitating the next transition of the state machine. In other examples, the transition of a parent state machine or a result of a parent application may cause the transition in the child state machine through the passing of a parameter from the parent to the child in the form of an outcome, as described below. Once the event has been raised ar block 48 has been performed, the process will begin the transition 49 by proceeding to block 50 where the current state of the state machine is updated to the new state (which may be the same as the old state).

In the example of Figure 4, in block 52 the state machine determines whether or not a function was specified for that transition (in the manner described below). If a function has been specified, the process will proceed to block 54 where the specified function is executed. At the following block 56 it is determined whether the execution of the specified function creates an exception. If not, the process will proceed to block 62. If the function does create an exception, the process will proceed to block 58 where the state machine is reverted to the state it was in prior to the corresponding event having been raised at block 48. At block 60 the exception is reported to the parent (the instantiating object: application or other state machine which instantiates the state machine of Figure 4) of the state machine. At block 52, if no function has been determined, the process will proceed to block 62.

At block 62 it is determined whether the specified transition has an outcome associated therewith. As used herein the term "outcome" denotes information to be reported to or from the parent of the state machine. An "input outcome" indicates an outcome received by the state machine, whereas an "output outcome" denotes an outcome generated by the state machine and reported to the parent of the state machine. If an output outcome has been specified, this is ' reported to the parent at block 64. Alternatively, if there is no outcome specified or determined, or once the outcome has been reported to the parent, the process will revert back to block 44 and await the next input.

Blocks 50, 52 and 62 involve a reference to the data file 38 (Figure 3) where the specification of the function and the outcome are contained. The instructions determining the process illustrated in Figure 4 are contained in the executable file 30. The transition of block 48 may involve the invocation of a sub-state machine. In this instance, the parent state machine will pause in its operations, invoke the sub-state machine and wait for the sub-state machine to complete before continuing, queuing any events which may be input for the parent state machine.

Figures 5 and 6 illustrate an embodiment of the invention in which a finite state machine 101 is used to model a messaging application. The finite state machine 101 comprises a number of states and transitions between the states. In Figures 5 and 6, states are depicted as oblongs and transitions by arrows between oblongs. The events causing the corresponding transition are provided as labels to the arrows of the transitions.

Referring to Figure 5, state 70 is the default initial state. In Figures 5 and 6, each of the states have been given a label comprising an integer followed by a descriptive term. Therefore state 70 is labelled "O.Initial" where the integer "0" is a reference to the ordinal of that state and the label "Initial" is a descriptive label. Similar labels have been given to the other states and events of the state machines of these Figures. On start event 72 ("O.Start") a transition to the set up state 74 (" I .Set Up") occurs. On the occurrence of event connect 76 (" 1.Connect") a transition to state connecting 78 ("2.Coπnecting") occurs. Then, on event connected 80 (2.Coπnected"), the state machine transitions to sub-state machine generating 82 which is described below in greater detail with reference to Figure 6 and which is represented in Figure 5 by state 82 ("3.Generating").

The generating sub-state machine 82 may return one of three parameters which, from the perspective of state machine 82 constitute input outcomes and, depending on the value of this parameter, a corresponding event will be generated: the state machine 101 will undergo transition on event nothing to send J 02 ("5.Noting to Send") to state disconnected 98 (^.Disconnected"); transition on event on error 90 ("7.On Error") to state dealing with error 94 ("β.Dcaling With Error"); or on event message sent 84 ("3.Message Sent") undergo transition to receiving state 86 ("4.Receiving"). In this example the correspondence between the input outcome received and the event generated in response thereto is specified in the resource file, as described in greater detail below.

Transition on event message received 88 ("4.Msg Received") describes a change of state from receiving state 86 ("4.Receiving") back to the sυb-statc machine generating 82, whereas a transition on event error 92 ("7.On Error") occurs between state receiving 86 and state dealing with error 94 ("6.Dealing with Error"). Transition on event error managed 96 ("7.On Error") occurs between the dealing with error state 94 and the disconnected state. It is to be realised that in this example transition 92 and transition 96 occur on occurrence of the same event.

The transitions of the example state machine of Figure 5 may be represented in tabular form as represented by Table 1. Each of the rows in Table 1 represents a state of state machine 101 and each of the columns of the table represents an event. An entry in a cell contains two or three numbers separated by commas and corresponds to a transition of the state machine. The first of these numbers represents the state to which a transition will occur when that event occurs for the corresponding state (row). The second of these numbers represents the ordinal of the function to be called when that transition occurs. The third number (when present) specifies the output outcome to be reported to the parent of the state machine. In the messaging application state machine of Figure 5 and Table 1, each transition has a corresponding function number which, in this example embodiment, represents the function to be called for that transition. The numeral "0" is used to indicate that no function is to be called. In contradistinction to this, the third numeral representing the output outcome is left blank where there is no outcome to report. A function may be any appropriate set of methods for the transition involved. For example, the transition from the initial state 70 to the setup state 74 on start event 72 involves the calling of function 1. Function 1 is the initialisation function which ensures that the communication stack is ready to receive the message from the messaging application. Table 2 2009/005787

lists the functions used by the state machine of Figure 5 and Table I according to the corresponding ordinal number.

State machines according to some embodiments of the invention are capable of nesting: a parent state machine can call a child state machine. The child state machines produce outcomes which are reported back to the parent state machines and influence the operation of the parent state machine. Furthermore, state machines according to embodiments of the invention may be capable of accepting input from sources other than state machines. For example, where a function called as a result of the transition results in the invocation of an external application, this external application will deliver results back to the state machine. In this instance the state machine is the parent and it is necessary to specify how the receipt of an outcome will influence the operation of the parent state machine. Furthermore, in this example, the results delivered are numbers.

State machine 101 of Figure 5 is the parent state machine to state machine 82 of Figure 6. Table 3 lists the possible outcomes the parent state machine 101 expects the child state machine 82 to produce for each of the states of the state machine 101. An empty or null outcome is denoted by: " ". For each non-null outcome, a corresponding state is listed. The listed state is the state to which the state machine will transition on receipt of that outcome. Jt should be noted that the event of Table 3 will cause the corresponding function in Table 1 to be called and, if applicable, a corresponding outcome to be reported to the application instantiating the state machine corresponding to Table 1. If none of the expected outcomes is received, the default event will occur. If a null outcome is listed and an outcome is nonetheless received, it is a matter of implementation how this is dealt with. In one example, this input outcome is ignored, whereas in another example, the input outcome is reported to the state machine's parent.

Table 1

Table 2

Table 3

The generating sub-state machine 82 is illustrated in greater detail in Figure 6. This example sub-state machine includes an initial state 110 ("O.Initial") and, on event generate 1 12 ("O.Generate"), a transition to state generating 116 ("1. Generating") occurs. Depending on an input received by the state machine 82 when in state generating 116, either event nothing to generate 114 ("1. Nothing to Generate") occurs which results in a transition back to the initial state 110; event generated 122 ("2.Gcnerated") causes transition to state sending 124 ("2.Sending"); or event on error 1 18 ("4.On Error") results in transition to state error 120 ("3.Error"). State sending 124 can transition back to state initial 110 on occurrence of event message sent 128 ("3.Message Sent") or to state error 120 on occurrence of event on error 126 ("4.On Error").

The example sub-state machine 82 is able to return one of two values, or pass an error code, back to its parent state machine 101, depending on how the operation of the sub-state machine proceeded. The value returned will determine which event is registered by the parent state machine which, as described, determines which transition will occur (one of nothing to send 102, on error 90 or message sent 84).

Table 4 is a representation of the sub-state machine 82 illustrated in Figure 6. Similarly to Table 1 , a transition is represented by entry at the corresponding row For the state and column for the event. In the same manner as illustrated in Table 2, the functions of the transitions of sub- state machine 82 are identified by ordinal number as illustrated in Table 5. Furthermore, the outcomes which may be received by the state machine 82 are identified according to their ordinal number as shown in Table 6. For state machine 82, these outcomes are generated by the applications responsible for generating the message and for sending the message. These outcomes are received by the state machine 82 (i.e. "input outcomes" in respect of state machine 82).

Table 4

Table 5

Table 6

The sub-state machine 82 both receives and reports parameters. The wildcard parameter "*", denoted in Table 4 is used to pass the received parameter back to the parent state machine 101. In this example, the wildcard parameter is specified as the output outcome for occurrence of events 118 and 126 in corresponding state 116 ("1.Generating") and state 124 ("2.Sendiπg"). Both of these events correspond to the occurrence of an error and in this embodiment, implemented in Symbian C++, the occurrence of an error is accompanied by the generation of an. integer representative of that error. An external list may be consulted to determine the error from the generated integer. , The occurrence of the error and the corresponding error integer are reported to the sub- state machine 82. The occurrence of the wildcard in the corresponding state and event in Table 4 indicate that this input outcome is to be reported back to the parent of this sub-state machine. In this example, the parent of sub-state machine 82 is state machine 101 and therefore the error integer is reported to parent state machine 101 as an input outcome. It wil) be noted from Table 3 that the default behaviour for state 82 ("3.Generating") of state machine 101 is event 90 ("7.On Error") which will then accept the input outcome of the error integer and deal with this error in resultant state 94 ("ό.Dealing with Error").

Therefore, use of the wildcard allows the transfer of information from one state machine to another where that information is generated by the operation of the child state machine. Although the wildcard symbol "*" has been used in Table 4 to denote the input and corresponding output, it is important to note that some state machines specified according to embodiments of the invention are capable of passing messages from the execution of an instruction which a particular state machine instantiates to a parent (application or state-machine) of that particular state machine. Generally, Tables 3 and 6 specify the manner in which the respective state machines 101 and 82 deal with incoming outcomes. For example, when state machine 82 is in state 116 ("1-Generating") the state machine awaits the outcome from the application responsible for generating the message. In this state the default event is event 90 ("4.On Error") and this is the event which will be raised unless the outcome from the application dictates an alternate event according to Table 6. Event 90 will cause the state machine to transition to state 120 ("3.Etτor") and call function number 4, passing the error number as the wildcard (as specified in Table 4).

An input outcome of "0" generated by the message generating application will cause the event 122 ("2-Generaled") to occur and the state machine will transition to state 124 ("2.Sending") as a result thereof. Alternatively, if the outcome "5000" is generated by the message generating application, the event 114 (" 1.Nothing to Generate") will occur and the state machine 82 will transition to state 110 ("O.Intial"), calling no function and returning the output outcome "5".

As it is the state machine 101 which instantiated the state machine 82 an input outcome received by parent state machine 101 of "5000" when in state 82 ("3.Generating") will, according to Table 3 result in event 102 ("5-Noting to Send") being raised, causing state machine 101 to transition to state 98 ('^.Disconnected") and calling the disconnect function number 4 according to Tables 1 and 2.

Since Table 1 and Table 4 are similar as are Tables 2 and 5; and Tables 3 and 6, similar tables may be located in the same resource file, but separate resource files being maintained for each of the table types. This can provide a more logical presentation of the relevant parameters and is therefore easier to access.

Figure 7 is a class diagram for classes of a framework for implementing state machines of the type hereinbefore described. In this embodiment, the framework has been implemented for the Symbian Operating System, but it is to be realised that the framework may be implemented for other operating systems with appropriate modifications. In the example, the framework is structured around the CStateMachineBase class 150. CStateMachineScheduler 156 is a singleton and operates to schedule the handling of events. CMappingsTable 152 and CStateTable 172 are the classes used for obtaining the right event when an outcome is reported and for selecting the correct transition on an event. CStarusListener 160 is an active object used by the state machine to make asynchronous calls. The container classes 166, 168 and 170 are used by the state machine. CEraptylnfoContainer 162 is used by the base state machine class when raising events as a result of an outcome.

CStateMachineBase 150 is the base class for all state machine classes in this example. Therefore the APIs for this class are protected and can only be used by the derived class. Methods in the API are implemented to construct finite state machines according to the information from the resource file; raise new events and handle events; handle outcomes; obtain a TRequestStatus object for waiting for a request complete; and to reset the derived finite state machine.

In an embodiment of the invention when a state machine object is constructed an initial state and a name for that state machine are provided. The name will also be used for logging purposes.

At construction, the necessary information is read from the corresponding resource file and the state machine is constructed accordingly. If necessary, the associated Active Object will be dealt with. The loading of this information is done in accordance with this embodiment using the classes CStateTable 172 and CMappingsTable 152. These two classes can be built directly from the information in the resource file, which gets parsed and converted into the internal representation on construction. Information relating to the following is read from the resource file; the state-event matrix (as depicted in Tables 1 and 3 of type CStateTable 172, for example); the names of the states (used for logging); the names of the events (also used for logging); the mappings between outcomes reported and events to be raised for any state that needs to have this (as depicted in Table 5 of type CMappingsTable, for example). This will include an indication of the default event i.e. the event to be raised where no other event is specified. Methods are provided for communicating between state machines and for raising new events. NewEventL(TUint aEvent, CTnfoContaiπerBase* alnfo) is used where only the event and the information corresponding to that event arc passed. This method is used in some embodiments for raising events internally, where no reporting is necessary.

NewEventL(TUint aEvent, ClnfoContainerBasc* alnfo, CStateMachineBasc* aReportingStatcMachine) is used in some embodiments where, along with the event and the parameter, a pointer to another state machine will be passed.

NewEventL(TUint aEvent, CInfoContainerBase* alnfo, TRequestStatus* aClientStatus) can be used to pass a pointer to a TRequestStatus object.

In these methods, TUnit is the ordinal number for the specified event; CInfoContainerBase is a pointer to the information which the method is passing (e,g. an outcome); and CStateMachiπeBase* identifies another state machine to be called where necessary.

Parameters are passed by means of containers which are derived from CInfoContainerBase 164. This class provides the functionality to check that the object is of the expected type.

The base class of an embodiment further contains an error value which is set to 0 by default (indicating that no error exists), but if an error is passed together with an event this value should be set to the error being passed. In this embodiment, a separate lookup table is provided for the errors. There are a few common information containers defined in the framework of this example embodiment: CEmptylnfoContainer 162, CIntegerlnfoContainer 170, CHBufCInfoContainer 166, CBoollnfoContainer 168. Class 170 is used to contain integer parameters, class 166 contains a buffer of fixed length, allocated on the heap, and class 168 stores Boolean parameters. The CEmptylnfoContainer class 162 is used by the framework to pass error codes and outcome codes around. This class is called empty as it does not contain member variables except those it inherits from CInfoContainerBase. In an embodiment events are handled by the method HandleEveπt. This method is called from the state machine scheduler (an instantiation of CStateMachineScheduIer 156). The method gets the next event from a queue maintained by the scheduler together with the corresponding information container and refers to the state table (a table corresponding to Table 1 above, for example) to determine the appropriate transition and corresponding function. The method then updates the state and calls the transition function passing the information container as input to the function. Once the transition has been completed, the method checks to determine whether reporting is required and fulfils this where necessary.

If the transition fails the method will reset the state machine and report the corresponding error code to the parent (the instantiating application which may feed the error code into another state machine).

Any outcomes (from calling the functions) are handled according to this embodiment by a call to method HandleOutcomeL (not shown in the Figures). This method will determine the event corresponding to the particular outcome for the current state and raise this event. This method will then create a CEmpty InfoCon tainer object and set the error member thereof to be the received outcome. After that it will queue the event together with the information container and enable the state machine to handle events again.

Known implementations of state machines use an array or other table-type structure specified in the code of the corresponding application to define the states of the machine and the applicable transitions. This type of implementation can suffer from the disadvantage that for a complex state machine the corresponding implementation can become unwieldy and difficult to update or modify. Furthermore, to update or change the state machine it is often necessary to update the code and recompile it.

The terms "finite state machine" and "state machine" are used interchangeably herein and both terms are intended to denote a state machine with finite, enumerable states.

In some embodiments of the invention, the method may be a method of specifying a finite state machine, with the finite state machine comprising one or more states linked by one or more transitions.

By specifying instructions for instantiating the state machine independently of the parameters used by the instructions to describe characteristics of the state machine, the amount of redundant code can be kept to a minimum. Furthermore, it is relatively easy to change and update a state machine specified in this manner as only the resource file need be updated and recompilatioπ is unnecessary.

The method of some embodiments of the invention may further comprise the step of specifying said parameters in a resource file and said instructions in an executable file.

The security of a system such as this may be enhanced by providing different security policies for executable files and read-only files (such as the resource file). If desired, the resource file may be stored at a location remote from the executable file and accessed over a network, for example.

Where parameters are used to specify different characteristics of the finite state machine, the parameters may be arranged in separate files where parameters are grouped into files according to the characteristics to which they pertain. This can provide a logical presentation of the relevant parameters and is therefore relatively easy to access.

Any combinations of the features and advantages of the described embodiments may be used in accordance with the invention, and it will be appreciated that many modifications, additions and omissions to the described embodiments are conceivable within the scope of the invention.

Claims

WHAT IS CLAIMED IS

1. A method comprising; specifying one or more instructions for instantiating a Finite state machine; and specifying one or more parameters used by said instructions to describe characteristics of said finite state machine; wherein said parameters are specified separately to said instructions.

2. The method according to claim 1 further comprising specifying said parameters in a resource file and said instructions in an executable file.

3. The method according to claim 1 or claim 2 wherein said parameters specify characteristics of states and transitions of said finite state machine.

4. The method according to claim 3 wherein said parameters specify, for a given state of said finite state machine, permissible transitions and the events which will result in each transition wherein said transitions are identified by the corresponding event and the corresponding resultant state.

5. The method according to any preceding claim further comprising specifying a function to be called on transition from a first state to a second state.

6. The method according to any preceding claim wherein said parameters include an outcome to be reported to a parent of said state machine, where said outcome is indicative of an operation of said finite state machine.

7. The method according to claim 6 wherein said parent is an application or further state machine responsible for instantiation of the state machine.

8. The method according to any preceding claims further comprising specifying an occurrence on receipt by said state machine of an outcome.

9. The method according to claim 8 wherein said received outcome is generated by a child state machine or by another instruction.

10, The method according to claim 8 or claim 9 wherein specifying an occurrence on receipt of said outcome includes specifying one or more events where each event thus specified is dependent upon the received outcome.

11. The method according to any one of claims 8 to 10 wherein a distinct resource file is used to create said dependencies between said received outcomes and said corresponding events.

12. The method according to claim 10 or claim 1 1 wherein said dependencies are related to a state of said state machine.

13. The method according to any preceding claim further comprising specifying an output outcome to be reported on receipt of a received outcome.

14. The method according to claim 13 wherein said received outcome is reported as said output outcome.

15. The method according to any preceding step wherein said parameters are used to specify different characteristics of said finite state machine, the parameters being arranged in separate files where parameters are grouped into files according to the characteristics to which they pertain.

16. The method according to any preceding claim further comprising specifying a plurality of functions, each of said plurality of functions having associated therewith an ordinal number for identifying a corresponding function.

17. The method according to claim 16 where a separate resource file is used to store the ltst of functions and wherein the functions are identified by corresponding ordinal number.

18. A method comprising: specifying one or more instructions for instantiating a finite state machine; and specifying at least one parameter used by said instructions to implement said finite state machine, said parameter including characteristics of said states and said transitions, and at least one outcome transmitted on transition from at least one of said states to another of said states.

19. The method according to claim 18 wherein said outcome is indicative of an operation of said state machine and is for traπsmittal to a parent of said state machine.

20. The method according to claim 19 wherein said parent is an instantiating application for said state machine or is a parent state machine.

21. The method according to any one of claims 18 to 20 wherein said outcome includes an indexed message and/or an exception code.

22. The method according to claim 21 further comprising the step of storing an index for said message in a resource file distinct from a storage of said instructions specifying said state machine.

23. The method according to any one of claims 18 to 22 wherein said outcome includes an outcome from a child application or child state machine of said state machine.

24. A method of specifying a plurality of finite state machines where at least a first of said state machines is specified according to any one of claims 18 to 23 and wherein said method includes specifying a second of said state machines so that said second state machine receives said outcome from said first state machine and reports said outcome to a parent of said second state machine.

25. A specification for a state machine wherein said specification is compiled according to any one of the preceding methods.

26. A state machine specified according to any one of claims 1 to 24.

27. An operating system for a computing device, said operating system comprising a plurality of applications, at least one of said applications instantiating a state machine according to claim 26.

28. Apparatus comprising: a processor; and memory comprising computer code, the memory and the computer code configured to, with the processor, cause the apparatus to perform: specifying one or more instructions for instantiating a finite state machine; and specifying one or more parameters used by said instructions to describe characteristics of said finite state machine; wherein said parameters are specified separately to said instructions.

29. Apparatus comprising: a processor; and memory comprising computer code, the memory and the computer code configured to, with the processor, cause the apparatus to perform: specifying one or more instructions for instantiating a finite state machine; and specifying at least one parameter used by said instructions to implement said finite state machine, said parameter including characteristics of said states and said transitions, and at least one outcome transmitted on transition from at least one of said States to another of said states.