GB2460467A

GB2460467A - Specifying a finite state machine by a set of instructions and a set of parameters which are stored in different files.

Info

Publication number: GB2460467A
Application number: GB0809934A
Authority: GB
Inventors: Sorin Basca; Joseph Spracklen
Original assignee: Nokia Oyj; Symbian Software Ltd
Current assignee: Nokia Oyj
Priority date: 2008-05-30
Filing date: 2008-05-30
Publication date: 2009-12-02
Also published as: WO2009144576A1; GB0809934D0

Abstract

Disclosed is a method of specifying a finite state machine. The instructions for instantiating the state machine are specified in an executable application file and parameters relating to the states, events and transitions of the state machine are specified in a resource file, independent of the application file. The parameters specify the characteristics of states and transitions of the state machine. The parameters may specify the permissible transitions and the events causing the transition. The method may include the step of specifying a function to be called on transition from a first state to a second state. The parameters may include an outcome to be reported to a parent, the parent being an application or other state machine responsible for the instantiation of the state machine. The method may include the step of specifying a set of functions, each function having an identifying number associated with it, the list of functions and their identifying numbers are stored in a separate resource file.

Description

STATE MACHINE FRAMEWORK

TECHNICAL FIELD

This invention relates to modelling tools and, in particular, to state machines.

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. 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.

Generally, 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.

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 suffers 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.

SUMMARY OF THE INVENTION

An embodiment of the invention provides a method of specifying a finite state machine, said finite state machine comprising one or more states linked by one or more transitions, said method comprising the steps of: specifying one of more instructions for instantiating the finite state machine; and specifying one or more parameters used by said instructions to instantiate said finite state machine; wherein said parameters are specified separately to said instructions.

By specifying the 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 is 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 recompilation is unnecessary.

The method 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.

Said parameters may specify characteristics of states and transitions of said finite state machine. Preferably said parameters specify, for a given state of said fmite state machine, the 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.

The method may further comprise the step of specifying a function to be called on transition from a first state to a second state.

Said parameters may include an outcome to be reporting to a parent of said state machine, where said outcome is indicative of an operation of said finite state machine. Said parent may be an application or further state machine responsible for instantiation of the state machine.

Said method of specifying a state machine may further comprise the step of specifying an occurrence on receipt by said state machine of an outcome. Said received outcome may be generated by a child state machine or by another instruction. Preferably, said step of specifying an occurrence on receipt of said outcome includes the step of specifying one or more events where each event is dependent upon the received outcome.

A distinct resource file may be used to create said associations between said received outcomes and said corresponding events. Said associations may be related to a state of said state machine.

Said method of specifying said state machine may further comprise the step of specifying an output outcome to be reported on receipt of a received outcome. Preferably said received outcome is reported as said output outcome.

Where said parameters are used to specify different characteristics of said 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 provides a more logical presentation of the relevant parameters and is therefore easier to access.

The method may further comprise the step of specifying a plurality of functions, each of said plurality of functions having associated therewith an ordinal number for identifying a The method may further comprise the step of specifying a plurality of functions, each of said plurality of functions having associated therewith an ordinal number for identifying a corresponding function. In this case a separate resource file may be used to store the list of functions where the functions are identified by corresponding ordinal number.

A further embodiment of the invention provides a method of specifying a finite state machine, said finite state machine comprising one or more states linked by one or more transitions, said method comprising the steps of: specifying one or more instructions for instantiating the 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.

Said outcome may be indicative of an operation of said state machine and may be transmitted to a parent of said state machine. Said parent may be an instantiating application for said state machine or may be a parent state machine.

Said outcome may include an indexed message andlor an exception code. Where said outcome includes an indexed message, an index for said message may be stored in a resource file distinct from instructions specifying said state machine.

Said outcome may include an outcome from a child application or child state machine of said state machine.

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 machine is specified as herein described and wherein said 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.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention will now be described with reference to the accompanying drawings in which: Figure 1 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 1; 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 PREFERRED EMBODIMENTS

Figure 1 is a schematic diagram of a mobile computing device 10 having a casing 12.

The casing 12 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 the operating system of the device 10. In the embodiment shown, the operating system is the Symbian operating system produced by Symbian Software Ltd., U.K. 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 includes many more devices and components than those illustrated here. Mobile computing devices in many forms are known in the art and will therefore not be further described herein.

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 by 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 model a manner in which the kernel 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. Therefore, it is to be realised that the discussion below of embodiments of the invention concerning finite state machines may be applied to various aspects of the mobile computing device 10, as well as other systems and devices not illustrated here, in a manner known in the art.

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 in 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 sate, 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 embodiment of the invention. Step 44 represents the base state in which the finite state machine awaits an input. At step 46 the finite state machine receives an input and, at the next step 48 raises an event. The event will lead to a transition 49, as denoted in Figure 4 by a dashed box. In this 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 at step 48 has been performed, the process will begin the transition 49 by proceeding to step 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 step 52 the state machine determines whether or not a function was specified for that transition (in the maimer described below). If a function has been specified, the process will proceed to step 54 where the specified function is executed. At the following step 56 it is determined whether the execution of the specified function creates an exception. If not, the process will proceed to step 62. If the function does create an exception, the process will proceed to step 58 where the state machine is reverted to the state it was in prior to the corresponding event having been raised at step 48. At step 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 step 52, if no function has been determined, the process will proceed to step 62.

At step 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 step 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 step 44 and await the next input.

Steps 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 step 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 (1.Set Up") occurs. On the occurrence of event connect 76 ("1.Connect") a transition to state connecting 78 ("2.Connecting") occurs. Then, on event connected 80 (2.Connected"), 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 102 ("5.Noting to Send") to state disconnected 98 ("5.Disconnected"); transition on event on error 90 ("7.On Error") to state dealing with error 94 ("6.Dealing With Error"); or on event message sent 84 ("3.Message Sent") undergo transition to receiving state 86 ("4.Receiving"). 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 sub-state 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 transition 92 and transition 96 occur on occurrence of the same event.

The transitions of the 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 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 I is the initialisation function which ensures that the communication stack is ready to receive the message from the messaging application. Table 2 lists the functions used by the state machine of Figure 5 and Table 1 according to the corresponding ordinal number.

As previously stated, state machines according to 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 are 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 reception of that outcome.

It 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.

States _______ __________ ________ ________ Events ________ __________ ______ _________ 0.Start 1.Connect 2.Con-3.Msg 4.Msg 5Noth-6.Discon-7.On 8.Error nected Sent Receiv ing to nected Error Managed _____________ _______ _________ _______ _______ ed Send _________ _____ ________ 0.Initial 1,1 _____________ _________ _________ _________ __________ ____________ _______ ___________ 1.SetUp ______ 2,2 ______ ______ ______ ______ _______ ____ _______ 2.Connecting _______ _________ 3,3 _______ _______ _______ _________ _____ ________ 3.Generating ______ _________ _______ 4,0 _______ 5,4 _________ 6,5 ________ 4.Receiving ______ _________ _______ _______ 3,3 _______ _________ 6,5 ________ 5.Disconnected ______ _________ _______ _______ _______ _______ 1,0,0 _____ ________ 6.Dealing With 0,0 Error _______ _________ _______ _______ _______ _______ _________

Table 1

S

Function Number Function Description

_______________ Name __________________ 1 InitiaLise Initialise the communication stack for reception of message from _________________ _____________ application.

2 Connect Establish a connection between the messaging application and the _________________ ______________ communication stack.

3 Generate Invoke the generating _________________ _____________ sub-state machine 82.

4 Disconnect Disconnect.

Deal With Disconnect and clean ________________ Error up.

Table 2

State Default Outcome Event Outcome Event 0.lriitial I' 1.Setting Up " 2.Connecting ____________________ _________ _______________ __________ ________________ 3.Generating 7 (On Error) 0 3 (Msg Sent) 5000 5 (Nothing to ____________ ___________________ _________ ______________ _________ Send) 4.Receiving 7 (On Error) 0 4 (Msg Rec'd) _________ _______________ 5. Disconnectin 6 (Disconnected) __________ ________________ __________ _________________ 6.Dealing With " Error

Table 3

The generating sub-state machine 82 is illustrated in greater detail in Figure 6. This sub-state machine includes an initial state 110 ("O.Initial") and, on event generate 112 ("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.Notbing to Generate") occurs which results in a transition back to the initial state 110; event generated 122 ("2.Generated") causes transition to state sending 124 ("2.Sending"); or event on error 118 ("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 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 colunm 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).

States ______________ ______________ Events _____________ ______________ 0.Generate 1.Nothing to 2.Generated 3.Msg Sent 4.On Error 0.Initial 1,1 Generate ____________ ___________ 1.Generating ____________ 0,0,5000 2,2 ____________ 3,4* 2.Sending _____________ _____________ ______________ 0,3,0 34*

Table 4

Function Number Function Description

_______________ Name ___________________ 0 Default Do nothing I Initialise Initialise the message _________________ ____________ generation component 2 Generate Generate the message and send to the __________________ _____________ communications stack 4 Error Invoke an error

Table 5

State Default Outcome Event Outcome Event 0. Initial __________________________________ _________________________ _________________ ___________________________ I. Generating 4 (On Error) 0 2 (Generated) 5 1 (Nothing to ______________ _____________________ __________ ________________ __________ Generate) 2. Sending 4 (On Error) 0 3 (Msg Sent) __________ _________________

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 instance, 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.Sending"). 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 will 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 ("6.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 the state machines specified according to 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.Error") and call function number 4, passing the error number as the wildcard (as specified

in Table 4).

An input outcome of p0" generated by the message generating application will cause the event 122 (2.Generated") 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 ("l.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 ("5.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 provides 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. 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. CStatusListener 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. CEmptyinfoContainer 162 is used by the base state machine class when raising events as a result of an outcome.

As stated, CStateMachineBase 150 is the base class for all state machine classes.

Therefore all 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.

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 needs to be dealt with. The loading of this information is done 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 I 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 (not shown in the Figures) are provided for communicating between state machines and for raising new events. NewEventL(TUint aEvent, ClnfoContainerBase* alnfo) is used where only the event and the information corresponding to that event are passed. This method will usually be used for raising events internally, where no reporting is necessary.

NewEventL(TUint aEvent, ClnfoContainerBase* alnfo, CStateMachineBase* aReportingStateMachine) is used where, along with the event and the parameter, a pointer to another state machine will be passed.

NewEventL(TUint aEvent, ClnfoContainerBase* alnfo, TRequestStatus* aClientStatus) is 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 infonnation which the method is passing (e.g. an outcome); and CStateMachineBase* 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 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: CEmptyinfoContainer 162, CintegerinfoContainer 170, CHBufClnfoContainer 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.

Each of these classes is used in a manner known in the art.

The CEmptylnfoContainer class 162 is used by the framework to pass error codes and outcome codes around. This class is called as empty as it does not contain member variables except those it inherits from ClnfoContainerBase.

Events are handled by the method HandleEvent (not shown in the Figures). This method is called from the state machine scheduler (an instantiation of CStateMachineScheduler 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 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 CEmptylnfoContainer 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.

Claims

Claims I. A method of specifying a finite state machine, said finite state machine comprising one or more states linked by one or more transitions, said method comprising the steps of: specifying one of more instructions for instantiating the 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 the step of specifying said parameters in a resource file and said instructions in an executable file.
3. The method according to claim I 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, the 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 step further comprising the step of 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 reporting 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 the step of 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 said step of specifying an occurrence on receipt of said outcome includes the step of 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 11 wherein said dependencies are related to a state of said state machine.
13. The method according to any preceding claim further comprising the step of 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 the step of 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 list of functions and wherein the functions are identified by corresponding ordinal number.
18. A method of specifying a finite state machine, said finite state machine comprising one or more states linked by one or more transitions, said method comprising the steps of: specifying one or more instructions for instantiating the 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 transmittal 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 andlor 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 machine is specified according to any one of claims 18 to 23 and wherein said 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.
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 Ito 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.