**4.1 Background of dynamic system behavior**

As mentioned earlier, each dynamic system should consist of one or more loops running over a period of time as a part of its lifecycle. The items that affect other items in the system but are not themselves affected by anything in the system are called exogenous items. These exogenous disturbances are seen as the triggers of system behavior. *Positive loops* tend to amplify any disturbance and to produce exponential growth: if the cause increases, the effect increases and if the cause decreases, the effect decreases. *Negative loops* tend to counteract any disturbance and to move the system toward an equilibrium point: if the cause increases, the effect decreases and vice versa. Stable conditions will exist when negative loops dominate positive loops. Non-linear relationships can cause feedback loops to vary in strength, depending on the state of the rest of the system. The dominating loop might also shift over time; linked non-linear feedback loops form the patterns of shifting loop dominance. Under some conditions one part of the system is very active, and under other conditions, another set of relationships takes control and shifts the entire system behavior; i.e. one particular loop is always responsible for the overall behavior of that system.

The timing of system behavior depends on the presence of system elements that create inertia or delays. These inertial elements are referred to as state variables (see section 4.2). Each state is an accumulation (*stock*) of information. System elements representing the decision, action, or change in a state variable are indicated by a *flow* of information to/from a state variable. Also, there could be time-delays in information flows, and we need to look for any lagged relationships in the system.

Dynamics of System Evolution 31

The primary assumption is that the persistent dynamic tendencies of any system arise from its internal causal structure. With no causes or activities, the system will come back to a stable state. One or more causes will initiate a trigger, which in turn may cause another trigger from that point. Based on the collected data from survey-agents, probing stations and other means (Mubin & Luo, 2010a) the knowledgebase is responsible for identifying a cause in {CT0..CTn}, where CT0 being no cause (nothing significant happened). The influential cause(s) of the transition, as well as the factor(s) in the operational environment, are archived into the knowledgebase for contextual analyses at a later point. Based on further statistical analyses of the current system and past track records each transition is associated with a *transition* probability. This may help the system avoid overshoot issues against a preset threshold value. Out of three different states, there are nine possible state transitions (see table 2) which can be mapped into an "acceptability" matrix, where each cell is a

*Destination State* 

State (S+)

T0+: Good (Highyield)

T-+: Good (Ideal case)

stable state) T++: Good T+-: Bad

Low-Value State (S-)

> T0-: Bad (trigger)

> (trigger)

T--: Bad (trigger)

response-indicator for the current system dynamics of an evolutionary phase.

*Begin State* Stable (S0) High-Value

High-Value State (S+) T+0: Okay (new

Low-Value State (S-) T-0: Good (new stable

**5. Measurement metrics for system evolution** 

Table 2. Evaluation of State Transition Matrix for Acceptability Measure

while and then fine tune these speficications according to their expectations.

T00: Okay (nothing significant happened)

state)

Ideally, we would expect the system to maintain either at a stable state or at a higher-value state. However, due to environmetal factors, we cannot ensure such elevated states. Rather, the system would often experience low-value state over a period of time. Based on all system related feedbacks, new task requests, and applying new changes if a system experiences lowvalue state for a time period, we may need to reconfigure the meta-structure to generate a trigger. System architects, analysts and stakeholders would observe that the system runs for a

We need to be able to instrument a system so that it becomes sensitive to any changes in software characteristics. Any appropriate measurement is a catalyst for improvement, it helps in system advancements, and improves the system's bottom line (Dekkers & McQuaid, 2002). The users' behaviors and contributions towards using a system's service(s) should be the integral measurement collected. A software-driven system's characteristics, usage and task request history, and its surrounding environment are all useful in measuring the quality and

**Transition due to occurrences of a set of causes, in {CT0..CTn}** 

Stable (S0)

### **4.2 Transition of system states**

A system state can be defined as a report on system status from different perspectives for an instant of time. For example, the current performance rate of the system, how well the system is doing in terms of its user satisfaction or system value, or what is the current condition at the workflow nodes in the system graph (i.e. utilization factors) and so on. By observing system states and their transitions over a period of time, we can analyze the causes behind each transition, re-assign edge probabilities in the workflow to fine tune each transition and formulate system behavior accordingly.

As explained in figure 1, after running through one or more recurring cycles during the initialization phase of a system in production, the underlying knowledge base will begin to identify the system's state of transition, in terms of its variations in system value. Based on the specific conditions or causes (such as task requests arrival rates, task completion rates, changes in user satisfaction index, or system access rates) this, in turn, will trigger a state transition and indicate whether any newly captured requirements need to be placed in the service queue. After application of these new changes into the system by the server (a process that performs the new service requests, not necessarily automatic), the wrappersystem will continue to observe the new state and will mark any changes in the system value or in the user satisfaction levels by repeating the process.

Fig. 2. Schematic diagram of an Evolvable System based on concepts of Finite State Machines

To maintain the system in a stable state (and avoid any reduction in system-value), a statemachine, as shown in figure 2, can be established to build an Ordinal Response Model (such as -2, -1, 0, +1, +2 to indicate system status and new transition) so that a state transition can be triggered to notify any inception phase of an upcoming evolution, the end of an evolutionary change or positive/negative loop dominances. There are three states of relative system value: stable state (S0), downward or lower state (S-), and upward or higher state (S+). Based on this, we can deduce nine possible state transitions, labeled with combinations of T[0, -, +], as described in figure 2. Each transition is associated with one or more causes (CT0..Tn). These may include task request arrival rates, task completion rates, delay in addressing requested changes due to complexity, applying new features into the system, changes in system access rates, variations in feature rank, utilization factors, etc.

30 Real-Time Systems, Architecture, Scheduling, and Application

A system state can be defined as a report on system status from different perspectives for an instant of time. For example, the current performance rate of the system, how well the system is doing in terms of its user satisfaction or system value, or what is the current condition at the workflow nodes in the system graph (i.e. utilization factors) and so on. By observing system states and their transitions over a period of time, we can analyze the causes behind each transition, re-assign edge probabilities in the workflow to fine tune each

As explained in figure 1, after running through one or more recurring cycles during the initialization phase of a system in production, the underlying knowledge base will begin to identify the system's state of transition, in terms of its variations in system value. Based on the specific conditions or causes (such as task requests arrival rates, task completion rates, changes in user satisfaction index, or system access rates) this, in turn, will trigger a state transition and indicate whether any newly captured requirements need to be placed in the service queue. After application of these new changes into the system by the server (a process that performs the new service requests, not necessarily automatic), the wrappersystem will continue to observe the new state and will mark any changes in the system

Fig. 2. Schematic diagram of an Evolvable System based on concepts of Finite State Machines

(S0) High-Value

C:T0

T+0

C:T0 C:T-

Low-Value State (S-)

State (S+)

C:T+

C:

C:T

To maintain the system in a stable state (and avoid any reduction in system-value), a statemachine, as shown in figure 2, can be established to build an Ordinal Response Model (such as -2, -1, 0, +1, +2 to indicate system status and new transition) so that a state transition can be triggered to notify any inception phase of an upcoming evolution, the end of an evolutionary change or positive/negative loop dominances. There are three states of relative system value: stable state (S0), downward or lower state (S-), and upward or higher state (S+). Based on this, we can deduce nine possible state transitions, labeled with combinations of T[0, -, +], as described in figure 2. Each transition is associated with one or more causes (CT0..Tn). These may include task request arrival rates, task completion rates, delay in addressing requested changes due to complexity, applying new features into the system,

changes in system access rates, variations in feature rank, utilization factors, etc.

**4.2 Transition of system states**

transition and formulate system behavior accordingly.

value or in the user satisfaction levels by repeating the process.

Stable State

T00

T-0

The primary assumption is that the persistent dynamic tendencies of any system arise from its internal causal structure. With no causes or activities, the system will come back to a stable state. One or more causes will initiate a trigger, which in turn may cause another trigger from that point. Based on the collected data from survey-agents, probing stations and other means (Mubin & Luo, 2010a) the knowledgebase is responsible for identifying a cause in {CT0..CTn}, where CT0 being no cause (nothing significant happened). The influential cause(s) of the transition, as well as the factor(s) in the operational environment, are archived into the knowledgebase for contextual analyses at a later point. Based on further statistical analyses of the current system and past track records each transition is associated with a *transition* probability. This may help the system avoid overshoot issues against a preset threshold value. Out of three different states, there are nine possible state transitions (see table 2) which can be mapped into an "acceptability" matrix, where each cell is a response-indicator for the current system dynamics of an evolutionary phase.


Table 2. Evaluation of State Transition Matrix for Acceptability Measure

Ideally, we would expect the system to maintain either at a stable state or at a higher-value state. However, due to environmetal factors, we cannot ensure such elevated states. Rather, the system would often experience low-value state over a period of time. Based on all system related feedbacks, new task requests, and applying new changes if a system experiences lowvalue state for a time period, we may need to reconfigure the meta-structure to generate a trigger. System architects, analysts and stakeholders would observe that the system runs for a while and then fine tune these speficications according to their expectations.
