State Diagram Sample Clauses

State Diagram. This diagram type precisely specifies the behaviour of an individual class in terms of its states. It provides a dynamic view of the object under examination, through the use of events, states, state transitions, guards, and actions. State diagrams will be used in the INESS model to represent the functionality of the interlocking specification and thus they are correspondingly complex. Each identified class will be given a state diagram in which the functionality most appropriate for that element will be placed. In general the name of the class guides and the attributes of the class provide the input for the functionality for the state machine, but the actual ‘positive’ functions of the class are specified in the actions of the state diagram itself. The main feature of this diagram type is in the states and the transitions between them. The initial state transition occurs by virtue of the birth event, which causes the initialisation of an object of that class as well as the first transition from the birth state. What happens subsequent to that is entirely dependent on the functionality of the object in question and can be read in the various examples of this diagram type that follow. Track/ 'direction' := #none; '/failed' := (in_state(#'active'.'failure'.'failed')); '/occupied' := (in_state(#'active'.'physically'.'occupied')); '/fouling' := ('/occupied' and not exists 'fouling mitigator' is_true ('fouling_mitigated')); physically <dv> not occupied/ pending occupied Entry/out(type, 'id', '<s> occupied'); <dv> occupied/ when( in_state(#'active'.'logically'.'not occupied') )/ <dv> TVP not detected/ <ic> logically unoccupied/ undetected not occupied Entry/out(type, 'id', '<s> undetected'); / Entry/out(type, 'id', '<s> not occupied'); failure <dv> occupied/ / not failed failed <dv> not occupied/ <dv> TVP failed/ logically / not occupied when( '/logically_occupied' )/ occupied Entry/say (type, 'id', 'fouled'); when( not '/logically_occupied' )/ send '<ic> logically unoccupied'; <ic> set track direction/'direction' := 'pTrack_direction'; active

State Diagram. Figure 5 illustrates diverse states that a customer QoS request can experience during its lifetime. When a request is submitted to the system, the new request goes to the new state and the upgrade request goes to the upgrade state. Both new and upgrade requests can go to the rejected state if a SaaS provider cannot gain the expected profit. If service start deadline is achievable with available resources, the request goes to the inserting state. If there is no resource available immediately but some existing requests will finish before the service start deadline, then the request goes to the waiting state. When the Scheduler detects that a new resource needs to be initiated for the request, either because there is no existing resource available before the service start deadline, but new resource can be initiated for the request, then the request goes to the provisioning state. For inserting, waiting and provisioning requests, after the request has been assigned to the VM, the states goes to the running state, which means a customer starts to use the service for enterprise software as a service or a task starts to execute for bag of task service. Also, changes in state may happen every time a request contract expires and then the resource capability is recalculated. For both new and upgrade requests, the finished state is reached in three different situations: (i) contract expires; (ii) system failure; and (iii) the customer cancelled the request