Architecting an Evolvable System by Iterative Object-Process Modeling

Abstract

Long term evolutionary needs for a system to be able to meet new and emerging requirements are often left unnoticed, since the complete picture is not apparently visible at the time of analysis. Therefore, over a long period of time, many of these systems become obsolete, because their lifecycles cannot be extended or are very expensive to re-engineer into a reusable system that could actually meet the new requirements. To overcome such difficulties, we present a methodology to build a wrapper-system based on the iterative Object-Process Modeling scheme. The purpose of the wrapper-system is to coordinate three stages of iteration: first, to collect the evolving factors from the system behavior; second, to update system state, and third, to apply necessary changes to the system to meet new requirements. Based on our analyses of the system usage activity logs and detailed update-request history of several projects over two to three years of time, we show that this iterative scheme can be effectively applied for architecting evolvable systems with longer life expectancy.

Low overhead high yield integrated surveys

“…Table 2 lists few of the system areas from where such data items can be collected. Figure 2 shows an example system with its underlying workflow paths built with system processes (P i ) and branching decisions (D i ); it delineates a different perspective from an object-process model [6], rather it splits an entity to detail the positioning of respective probes and feature rank calculators. A probing station (PS) is instrumented at the entry point of a process that lies on one of the branching points of the system.…”

“…However, in our case, we are concerned about lowering of survey overheads from both ends. Unlike designing survey questionnaires [1,10] for traditional surveys, we first analyze the scope of the survey and split this up into granular levels and map into respective areas in the workflow, that can be implemented into the system either with probing stations [6] or by formulating micro-surveys, as described in the previous section. The system workflow paths can be gracefully utilized to place probing stations at all points of interests along the branches to cover up the scope of the survey as much as possible.…”

“…The automated sampling process can be based on various parameters in the system-usage patterns at probing stations [6] and respective feature ranks. There can be a large number of micro-surveys in a system, but while the system is being used, only a few may popup; thus collectively they will accumulate survey data into a complete set of responses, as it is done for a completed survey.…”