**8. System usage patterns**

One of the basic patterns that we would like to know is how frequently a system is being used or accessed over each cycle (with sufficiently long periods between cycles). Then if we can compare this for several consecutive cycles, we can capture more details on how the

Dynamics of System Evolution 41

Node3.1 (insert)

Node4.1 (view-list) Node4.1.1 (details)

*p*=0.33

*p*=0.33

*p*=0.33

Node4.1.2 (update)

Node4.1.3 (delete)

Fig. 6. Example of a mapped graph of partial workflow nodes in ADMIN-ROLES

*p*=1.0

*p*=1.0

Node2 (profile)

*p*=0.2

Node1 (login)

*p*=0.2

*p*=0.2

*p*=0.2

*p*=0.2

Node3 (new role)

Node4 (browse roles)

Node5 (downloads)

Node5 (reporting)

to adjust the pre-assigned probabilities to these three leaf nodes in the graph.

Fig. 7. Usage activities of specific features comparing to estimated probabilities

Table 5. Regression Analyses three ADMIN-ROLES Features

**ADMIN-ROLES R2 sERR sigF p-Value Correlation**  ACT\_INS 0.2066 0.1745 0.1375 0.0243 0.4546 ACT\_UPD 0.7529 0.3415 0.0002 0.0000 0.8677 ACT\_DEL 0.4149 0.0812 0.0237 0.0002 0.6441

Therefore, the chance of utilizing feature of *Node4.1.2* will be, p=0.2 x 1.0 x 0.33 = 0.066. Figure 7 compares the scenario for three activities; ACT\_INS, ACT\_UPD and ACT\_DEL.

As we can see from the regression analyses (see table 5), there are close correlations between the actual usage patterns and the expected usage patterns. This experiment reveals that our expected usage pattern of ACT\_UPD is almost 8.7 times higher, although the relative usage rates coincide with each other. (Notice the R2, *p*-Value and Correlation for this activity in table 5). For ACT\_INS and ACT\_DEL the outputs look correct in terms of estimations. Therefore, the result suggests that in order to achieve the expected system behavior we need

behavior is changing over a period of time along with possible causes. For example, figure 5 demonstrates such activities over the last four years. If we closely observe the changing patterns we can summarize that ADMIN-ROLES has had *horizontal shifts,* meaning that users have changed their habit of system usage time over the yearly cycle even though the overall access volume remained same. For APPTRACK we see that there had been *vertical shifts* over the last several years indicating that the system has become more/less popular. For GTA-WS and ITAP systems, there are clear signs of seasonal activities that repeat over each yearly cycle.

These access rates can be superimposed with the accumulated USI values that are related to applying new changes into the system. This would represent a more meaningful output of overall system values as demonstrated in figure 4. We present another example of system usage patterns that compares the actual usage versus the expected usage patterns. As proposed in figure 3, we can assign the probabilities of using certain features in the workflow paths. Figure 6 demonstrates such mapping of partial workflow paths of the system ADMIN-ROLES. Initially we would expect that under normal circumstances, a user may take one of the five possible options (so 0.2 is the probability to access one option). Then at the next level (from *Node4* to *Node4.1*), there is just one possibility with probability 1.0; and from Node4.1 there are three options with probability 0.33 probability each.

Fig. 5. Various patterns of system access frequencies

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

behavior is changing over a period of time along with possible causes. For example, figure 5 demonstrates such activities over the last four years. If we closely observe the changing patterns we can summarize that ADMIN-ROLES has had *horizontal shifts,* meaning that users have changed their habit of system usage time over the yearly cycle even though the overall access volume remained same. For APPTRACK we see that there had been *vertical shifts* over the last several years indicating that the system has become more/less popular. For GTA-WS and ITAP systems, there are clear signs of seasonal activities that repeat over

These access rates can be superimposed with the accumulated USI values that are related to applying new changes into the system. This would represent a more meaningful output of overall system values as demonstrated in figure 4. We present another example of system usage patterns that compares the actual usage versus the expected usage patterns. As proposed in figure 3, we can assign the probabilities of using certain features in the workflow paths. Figure 6 demonstrates such mapping of partial workflow paths of the system ADMIN-ROLES. Initially we would expect that under normal circumstances, a user may take one of the five possible options (so 0.2 is the probability to access one option). Then at the next level (from *Node4* to *Node4.1*), there is just one possibility with probability 1.0; and from Node4.1 there are three options with probability 0.33 probability

each yearly cycle.

each.

Fig. 5. Various patterns of system access frequencies

Fig. 6. Example of a mapped graph of partial workflow nodes in ADMIN-ROLES

Therefore, the chance of utilizing feature of *Node4.1.2* will be, p=0.2 x 1.0 x 0.33 = 0.066. Figure 7 compares the scenario for three activities; ACT\_INS, ACT\_UPD and ACT\_DEL.

As we can see from the regression analyses (see table 5), there are close correlations between the actual usage patterns and the expected usage patterns. This experiment reveals that our expected usage pattern of ACT\_UPD is almost 8.7 times higher, although the relative usage rates coincide with each other. (Notice the R2, *p*-Value and Correlation for this activity in table 5). For ACT\_INS and ACT\_DEL the outputs look correct in terms of estimations. Therefore, the result suggests that in order to achieve the expected system behavior we need to adjust the pre-assigned probabilities to these three leaf nodes in the graph.

Fig. 7. Usage activities of specific features comparing to estimated probabilities


Table 5. Regression Analyses three ADMIN-ROLES Features

Dynamics of System Evolution 43

ThisSystem SystemConfiguration(WrapperSystem) // dynamically configure the system

// in tabular format, collect the complete system workflow paths

// prepare equivalent graph model from the system with initial weights SystemGraph GenerateGraphModel(SystemControlFlowPath, Node\_Weights,

Setup\_TaskActivity\_Stations(SystemControlFlowPath, TaskRequest\_Template,

// formulate model: identify stock (or accumulations) & info flows (rates)

RETURN SystemDynamics(NewSpecs)

CASE "SYSVALUE\_INC": // save data on incremental SV

prevCHANGE, TimeStampNow) thisCHANGE thisINC CASE "SYSVALUE\_DEC": // save data on declining SV

> prevCHANGE, TimeStampNow) thisCHANGE thisDEC

NewSpecs GenerateNewSpec(Knowledgebase) Apply\_New\_Changes(PrevSpecs, NewSpecs)

// save changes resulting from model-based updates Knowledgebase Record\_New\_Changes(PrevSpecs, NewSpecs)

Prep\_Inception\_Phase(Knowledgebase, ThisSystem)

thisINC Generate\_Change\_Report(Knowledgebase,

thisDEC Generate\_Change\_Report(Knowledgebase,

SystemControlFlowPath GetControlFlow(ThisSystem)

// interconnect the flow with feedback loops (circular causality)

sysUsage GetSystemUsage(TimestampNow) sysTasks GetSystemTasks(TimestampNow)

// get system status for evaluation

CASE "EVOLUTION":

CASE "INCEPTION":

Prep\_Next\_Iteration(Knowledgebase)

Prep\_Next\_Cycle(ThisSystem, SystemSpecifications-Revised)

Setup\_Probing\_Stations(SystemControlFlowPath, SystemGraph) // environment setup: collect update/change requests

// get dynamic system behavior and state (feedback loops)

Knowledgebase Record\_System\_Dynamics(sysState, sysUsage, sysTasks)

 PrevSpecs SystemSpecifications-Initial // derive policy insights

// recursive call

CASE "NOCHANGE": continue loop

SystemStatus SystemEvaluation(Knowledgebase, TimeStampNow)

Status SystemDynamics(SystemSpecifications-Initial)

System\_Initialization(ThisSystem)

Edge\_Values)

WHILE (System is running)

BEGIN

END SWITCH

END FOR

END WHILE

END

RETURN SystemStatus

WrapperSystem SetupMetaStructure(SystemSpecifications-Initial)

// environment setup: System Usage

TaskCompletion\_Template)

FOR EACH [TIME-CYCLE] IN System-Lifecycle

SWITCH (SystemStatus)

sysState GetSystemState(TimestampNow)

BEGIN

BEGIN

END

BEGIN

BEGIN

Fig. 8. A high-level pseudo-code for a generalized process of system evolution

Although the majority of systems fall under these scenarios, there are a number of other classes of systems where a meta-structure either cannot be established or the establishment of such a structure would be cost-prohibitive. For these classes of systems, such evaluations may not support the discovery of system behavior or impact based on updated request history.

In summary, we may follow these experiments to calibrate the processes, thereby adapting the values of multiplicative constants, probabilities, etc. to the empirical data for the environment of our particular system. However, over a longer period of time the environment itself may change significantly. Therefore, these calibrated values need to be reviewed and re-adjusted recurringly as the system evolves over time.
