Modeling the System-User Dialog Using Interaction Traces Mohammad El-Ramly, Paul Iglinski, Eleni Stroulia, Paul Sorenson Computing Science Department
Bruce Matichuk Celcorp
University of Alberta
2100, 10130 - 103 Street
Edmonton AB, T6G 2H1, Canada
Edmonton AB, T5J 3N9, Canada
{mramly, iglinski, stroulia, sorenson} @cs.ualberta.ca
[email protected]
Abstract It is generally the case that some UI reverse engineering will be needed for every non-trivial reengineering project. Typically, this is done through code analysis, which can be very difficult and/or expensive. When code analysis is not a must, as for wrapping purposes, system-user interaction can be an alternative input for the reverse engineering process. In the CelLEST project, we have developed a prototype, called LeNDI, to test this idea. LeNDI records traces of the legacy screen snapshots and user actions, while the user interacts with the legacy system. Then, it extracts a set of features for every snapshot and employs artificial intelligence methods to build a model of the legacy UI, called the statetransition graph. LeNDI uses two clustering methods to group similar snapshots together as one system screen modeled by one node on the graph. LeNDI uses the user actions recorded in traces to model the behavior of the legacy screens as the graph arcs. Evaluation results of this process are encouraging. The state-transition graph is used to classify each individual snapshot forwarded by the legacy system to the user while he interacts with it and is a main input to the forward engineering phase of the project.
1. Motivation For many organizations, their legacy systems are the backbone of their data processing and business process flow. Business software systems, such as bank finance systems and airline reservation systems, contain a wealth of diverse business policies and decisions. Many such systems were developed using the technologies of the 1970s or 1980s and had many changes by different developers [5]. Their text-based interfaces (TBIs) are non-intuitive, hard to learn, and tedious to use. These proprietary interfaces present a big obstacle in any effort to integrate these systems with each other or to make them web-accessible. For these reasons, many organizations invest in either migrating the whole application to a newer, faster,
and non-proprietary platform, or in wrapping its user interface (UI) with another UI implemented on a new, more accessible platform. UI reengineering is a two-phase process. The first is a reverse engineering phase during which a model of the legacy UI is built or extracted from the existing legacy system code, documentation and user experience. The second is a forward engineering phase during which a new UI is created to replace the legacy front-end. The CelLEST project is a collaborative project between the Software Engineering Research Lab. at the University of Alberta and Celcorp [2]. Celcorp has been involved in the process of legacy application integration for a decade. They developed a state-of-the-art suite of intelligent tools for modeling, reengineering and integrating legacyapplication front-ends. The CelLEST project aims to apply artificial intelligence methods to increase the automation of this process. In this paper, we discuss the UI reverse engineering method developed in the context of CelLEST, which is implemented and tested in a prototype tool, called the LEgacy Navigation Domain Identifier (LeNDI) [12]. Section 2 briefs the traditional UI reengineering approaches and presents the novel approach adopted in the CelLEST project. In Section 3, we discuss the problems that arise in the reverse engineering phase of the CelLEST approach. Section 4 is a presentation of the overall architecture and process of LeNDI. Section 5 provides an example and evaluation of the approach. Section 6 is our future work plan. Finally, Section 7 is the summary and conclusions.
2. Reengineering Legacy User Interfaces Several approaches were proposed to handle the problem of reengineering legacy UIs [7]. For example the original TBI may migrate to a graphical user interface (GUI) platform [1,6], a GUI may be reimplemented on another GUI platform [7], or a GUI may be grafted onto a batch, command-line accessible application [8,15]. Finally, a most
pervasive activity today is the development of webaccessible wrappers for legacy systems UIs [3,14]. All these approaches are static analysis techniques as they adopt code analysis and understanding as the means for system modeling. But the code of a legacy system is usually a very poor expression of its design. It includes “dead” or obsolete code and “glue” code of incremental updates. Thus, it is neither easy nor cost-effective to analyze legacy code. Even worse, in some cases the code is only available in binary form. In such cases, system-user interaction can be an alternative source of information for understanding the behavior of the legacy system. It is a rich source of knowledge and a faithful representation of how the system is currently being used. Hence, it is good candidate input for the UI reengineering process. There is a need for novel, automated or semiautomated, methods for UI migration that use only, or mainly, the system-user interaction. Such codeindependent methods will be significant contributions to the field of UI reengineering. The goal of the CelLEST project is to develop such methods.
After the expert user has verified the model of the legacy UI, the process of analyzing task-specific navigation plans and constructing new interfaces to wrap them can start. Specific user tasks are also reverse engineered and modeled using task-specific traces. Each set of such traces represents multiple executions of a single user task. A model of the task is built with the aid of some user input to identify the information exchange that takes place between the user and the legacy application during the task. This phase employs dynamic analysis techniques for UI reverse engineering using the same concept used for understanding the run-time behavior of objectoriented programs [11,13]. In [11,13], traces of data are collected while a Java or a binary program runs. These traces are then used for performance analysis, class modeling and visualizing the system behavior through scenario and state diagrams. In the CelLEST approach, we collect and analyze data of the systemuser dialog only, and not of the behavior of the program artifacts like objects, classes, threads, etc.
The methodological assumptions underlying the CelLEST UI reengineering approach are as follows: 1. It is required to wrap the legacy system with a task-centered GUI. 2. The legacy system will continue to be used on its current platform. 3. No code will be examined or altered. The main input available for the UI reengineering process is the system-user interaction. 4. Aside from interface optimizations, no major functionality changes or additions will be made. In its reverse engineering phase, the CelLEST process produces a behavioral model of the legacy system using traces of its current use by its users. For legacy systems that use a block-mode data transfer protocol between the system and its user terminals, such as IBM 3270, a trace is a sequence of screen snapshots interleaved with the user actions performed in response to receiving the snapshots on his terminal. The behavioral model produced is a state-transition graph (or an interface map). Each node of the graph corresponds to a distinct legacy system screen-state. Each edge corresponds to a possible user action, that is, a sequence of cursor movements and keystrokes on a particular screen-state that causes a transition to another screen-state. A legacy system screen can have multiple states; each allows the user to perform a certain set of actions. E.g., a screen may allow a data entry action or opening a list of choices in its "normal" state but it allows only an error correction action in its "error" state, when wrong data is entered.
Figure 1: Legacy UI migration: the CelLEST approach. In the forward engineering phase of the CelLEST method, an abstract specification of a GUI for this task is constructed from this task model, which is subsequently “translated” to a platform-specific taskcentered GUI implementation. Figure 1 shows the CelLEST approach to legacy UI migration. A taskcentered GUI can combine the functionality of several legacy screen-states, related to one task in one GUI unit, e.g. a tabbed pane or a form. The new GUI drives the execution of the user tasks through the legacy system using the state-transition graph and an API to the data transfer protocol used. This approach can integrate several legacy systems front-ends in one
GUI. The CelLEST test-bed for the forward engineering phase is a prototype tool called Mathaino [4], which replaced an earlier tool, URGenT [12]. Parallel to these two phases, is a review and inspection process that enables an expert legacy system user to visualize, review, revise and thus validate the various models produced in both phases. The CelLEST reengineering method is powerful in that it constructs a high-level model of the interaction behavior between the legacy system and its users. All the approaches mentioned earlier analyze the legacy code to detect GUI widgets or TBI code to replace them by functionally similar widgets or code in new platforms. Instead of replicating the same interaction with different widgets in new platforms, our method encapsulates interesting behavioral segments of the legacy interface into new UI front-ends on different platforms with fundamentally different widget toolkits, such as WAP devices for example [4].
3. Challenges in the CelLEST User Interface Reverse Engineering Two main problems arise in the effort to map a legacy UI and construct a behavioral model for it. The first is identifying the distinct states in which the system can be and the second is identifying the possible transitions between them. When the legacy system is a transaction-based system, its behavior is driven by the user’s data input. This data may cause queries (or transactions) to the system, whose results are displayed back to the user. For these systems, their internal behavior is mirrored faithfully in their interface: different internal states correspond to different screen-states pushed by the system host to the user terminal. Similarly internal state transitions correspond to the user actions on these screen-states. Each screen-state represents a distinct behavioral state of the legacy system. Thus, the LeNDI process consists of two steps. The first is identifying the unique screen-states of the application UI and the corresponding predicates for evaluating whether a new snapshot is an instance of one of them. The difficulty of this task depends on the screen-state dynamics; i.e., the variability of the content and layout of various snapshots of the same screen-state. Some screen-states are static, such as menus for navigation. Others are very dynamic, such as free-form reports. To recognize the identity of snapshots of the same screen-state, some distinguishing features on these snapshots should be recognized and then used to cluster them together. The second step is the identification of user actions that are possible at each of these screen-states. Different styles of interaction are available in legacy
systems including function-keys, menu-driven, command-driven, and form filling interactions. Moreover, one action can have several formats; e.g. a command keyword may have multiple synonyms.
4. LeNDI Architecture and ReverseEngineering Process Figure 2 shows the main building blocks of LeNDI and their interaction with each other. The flowchart display shapes represent LeNDI’s visualization components. The dotted rounded rectangles are the main steps in LeNDI’s reverse engineering process. First, LeNDI records traces of the system-user dialog. Next, a software engineer configures the subsequent feature extraction process and LeNDI proceeds to extract the configured content and layout features for every snapshot in the trace. Subsequently, LeNDI builds the state-transition graph of the legacy system. The snapshot features provide the basis for evaluating the similarity of the various snapshots and hence for clustering similar snapshots together, as instances of the same screen-state. These clusters correspond to the nodes of the state-transition graph. Next, the user actions possible at every state are modeled, based on the action instances performed on the snapshots of each screen-state cluster. LeNDI can receive user feedback about the correctness of the state-transition graph and modify it accordingly. At any step, the user can preview the intermediate outputs. At this point, the user can validate the accuracy of the interface map of the legacy system by using it to check his/her current location on the legacy interface at any time during an online connection to the legacy host.
4.1 Recording The recorder enables the user to connect to an IBM 3270 or a VT100 host1 and perform his tasks through an emulator, while it captures a trace of the systemuser interaction. This trace includes all the screen snapshots the user retrieved and all the actions performed on them. Typically, several traces of the same system are used to model its TBI. The recorded traces can be reviewed using the trace viewer.
4.2 Feature Extraction The feature extractor extracts the features needed for clustering similar snapshots together. It has a default feature extraction setup, which is also configurable. After reviewing a variety of legacy UIs and consulting domain experts, we developed three sets of distinguishing features: special system keywords, layout features and application-specific features [12]. 1
So far, we focused in LeNDI on data transfer protocols that are native block-mode protocols or can be emulated in block-mode.
1
2 Daily Tasks
Recorder
Traces of Snapshots and Actions
Terminal Legacy System User
Trace Viewer
3 4
Software Engineer
Traces Annotated with Snapshot Features
Screen Identifier
Terminal
Setup
Feature Viewer
Setup and Feedback Software Engineer
Run-time Viewer
Run-time Navigator
Feature Extractor
Legacy System State-transition State-transition Graph Graph
Clustered Snapshots
Action Modeler
Cluster Viewer
Action Model Viewer
Figure 2: The overall architecture and process of LeNDI. The output of the feature extraction process is a feature vector for every snapshot. It is important to notice that the ability of each feature to discriminate between snapshots belonging to different screenstates differs from one legacy system to another depending on the approach followed in designing the legacy TBI. We continue to broaden LeNDI’s feature suite to be able to deal with various legacy interfaces.
4.3 Screen Identification via Top-Down Clustering The screen identifier is responsible for clustering snapshots of the same legacy screen-state together, and thus building a model for this screen-state. LeNDI is equipped with two clustering methods. The first is an incremental clustering algorithm [17] that views the clusters as centered at a representative point, the centroid. A new snapshot belongs to the most similar cluster centroid if its similarity to the centroid of this cluster is above a user-defined threshold; otherwise it is the first member of a new cluster. The similarity measure is a user-defined weighted-sum of the similarity of individual features. After all the snapshots in the recorded traces are clustered, the user can review the results using the cluster viewer, readjust the similarity measure and recluster. If there are still misclustered snapshots, after incremental revising of the similarity measure and
threshold, the user can move these snapshots to the clusters where they belong, through the drag-and-drop interface of the cluster viewer. Based on user feedback, LeNDI infers a signature for every cluster, i.e., a logical combination of feature values that uniquely distinguishes the members of this cluster. An earlier version of this method is described in [12]. To further automate the identification process, and relieve the user from having to decide similarity thresholds and feature-weighting schemes, we have developed a second clustering method for LeNDI. This method is a two-phase top-down clustering algorithm. The first phase is an unsupervised top-down clustering algorithm that takes as input the expected number of clusters. Based on snapshot features, this phase produces a decision tree that can be used to classify the snapshots into screen clusters. The second phase involves getting the user feedback on misclustered snapshots and using it, in the mode of supervised learning, to revise the decision tree. In the following, we present the two phases of this method. In Section 5, we provide an example and compare the two clustering methods against each other and against the standard C4.5 learning algorithm. 4.3.1 Phase 1: Top-Down Unsupervised Clustering The first phase of this algorithm is a form of unsupervised learning, extended so that it can be partially guided by the user. The algorithm, shown in
pseudo-code in Figure 3, requires as input the feature vectors of the snapshots that will be clustered, and an estimate of the number of screen clusters required. Initially, all the snapshots are placed in a single cluster. As long as the number of clusters is less than the expected number of clusters, the algorithm identifies the most “incoherent” cluster and splits it into two new clusters, in a way that minimizes the incoherence of the resulting clusters. Incoherence is measured as the average distance of every instance in a cluster from every other instance in the same cluster. Currently, all the features are treated as having discrete non-ordinal values. Each snapshot has 39 features, by default equally weighted at 1. If two instances have different values for a feature, that feature contributes its weight to the distance measure. The distance between two instances is then simply the sum of the weights of their differing features.
Cluster(Partition p,Integer ! #k)"$% "$$ &('*) +$,-' . /"-021 ,(34 "$5 6 &('7 8 &( :9*$% 8 &( 20 ! 7 15/$ ;"=< $ + !>1 . 1?$ ;"A@2 *B 1 1C 8 &*%> =" . 8 &( : 8 &( 02 8 &( '7 15/$ ;" 8 &** D" . 1# FE GC< $ + !$ 1 'E GC+@2 $ '*0H0B$'
# 8 &( E ;"$"$&(6E ;,(,( '7 $
# 8 &( E I$$"E ;,(,( '7 J 1#F 8 &( E ! "F #"$$ '* 9*$ 8 &( E ! "F "F$ '(' 9*$ 8 &( 20 8 &( 7 J J &*E F B $ "'7 &*E ;,(,( 9*$ 8 &( E ;"$"$&(+'7 &*E ;,(,( 9*$ 8 &( E I$$"+'7 J Figure 3: The pseudo-code for the basic top-down unsupervised clustering algorithm. If the user of LeNDI can estimate the number of unique interface screens, the algorithm can proceed unsupervised to decompose the original set of snapshots into the expected number of clusters. When it is not possible give an estimate, or when the user prefers to have more control on this phase, we have developed an interactive version of the algorithm that can be monitored and guided by the user. The user may step through the algorithm’s split decisions. If,
at some point, a cluster looks close to its desired state, i.e., it contains few snapshots that do not belong there, the user can finalize it, ensuring that the algorithm does not consider it as a candidate for further splitting. Moreover, the user can force the algorithm to split a certain cluster in the next step. After many experiments with different data sets, we found that the best criterion for splitting a cluster is minimizing the maximal internal cluster incoherence using linear distance averaging. We call this splitting criterion the “best-split test”. As an alternative to providing the number of clusters as the determining factor for terminating splitting, the user can specify an incoherence threshold or use a default threshold. Thus, when all (non-finalized) clusters are below the specified threshold, the splitting stops. The default threshold value varies in proportion to the sum of all the feature weights. The output of this phase is a partition of the entire snapshot set, e.g. {{1,2}, {3}} is one possible partition of the trace, {1,2,3}. Associated with the output partition is a decision tree that defines how this partition was constructed and which feature and value were used for splitting at each tree node. 4.3.2 Assessing Cluster Quality Using MoJo Assessing the quality of a clustering algorithm requires a metric that gauges a meaningful distance between the derived partition and an authoritative partition, one that had been constructed and/or verified by an expert user of the legacy system. To obtain such a similarity measure, we have adopted the MoJo metric [16]. MoJo uses a heuristic to approximately count the minimum number of operations that are required to transform one partition to another. MoJo allows only two operations, Moves and Joins. A move consists of moving a single instance from one cluster to another, while a join merges one cluster into another. In our experiments we have noted that the MoJo metric does not adequately reveal the similarity of partitions that contain clear groupings of misclustered instances. In the context of our screen identification problem, we often have a number of potentially pre-grouped snapshots in one cluster that needs to be moved to another cluster. Selecting this easily identifiable group and determining where it should go is not much more effort than relocating a single misclustered instance. To include this fact in the MoJo metric, we added a “multi-move” operation that considers moving a group of instances from one cluster to another as a single operation whose cost is equal to that of a join or a simple single instance move. We call this extension MoJoPlus.
By observing both the MoJo and the MoJoPlus numbers for a generated clustering relative to an authoritative partition, we can obtain a fuller appreciation of how good the generated cluster is. 4.3.3 Phase 2: Decision Tree Extension via Supervised Learning Once a preliminary clustering of snapshots is derived through the unsupervised learning phase, the user can examine the partition through the cluster viewer, drag and drop misclustered snapshots to their correct clusters, and then request an extended decision tree in the supervised learning phase of the algorithm. We developed our own decision tree extension algorithm, which leverages the set of joins and moves discovered by MoJoPlus. The pseudo-code of this algorithm is shown in Figure 4. A MoJoPlus join of cluster A to cluster B simply means changing the leaf node A to B, or if A and B share the same decision node, replacing the decision node with the leaf node B. A MoJoPlus move of instances from A to B requires discovering which features distinguish the moved instances from the other instances in A and/or which features are shared by the moved instances and all the instances in B. The heuristic involved in this decision is to use the strongest and most generalizable distinguishing characteristics detectable. If instances are being moved from a larger cluster to a smaller cluster, the tree-revision algorithm first looks for features shared by the instances in the larger set and not the instances being moved or in the destination set. If the instances are going from a smaller cluster to a larger one, the tree-revision algorithm first looks for features shared by the moved instances and the destination set, but not by the ones in the origin set. If the first of these feature quests fails, the alternative is tried next. If that second quest fails, the algorithm recursively tries again, this time ignoring the features in the destination set. If this still fails, the moved instances are split into groups according to the bestsplit test for minimizing the maximum cluster incoherence, and then each resulting group is checked recursively for distinguishing features. If the algorithm recurses down to a single instance, and no distinguishing feature can be found, the algorithm simply reports the failure and proceeds. This situation is, in fact, seldom encountered in all the legacy system traces that we have tested. The successful identification of distinguishing features guarantees the correct classification of the training set instances. Once a set of distinguishing features has been found, the algorithm currently selects one at random and uses it to create a new decision node to distinguish the instances from their initial classification.
4.4 Action Modeling The purpose of the action modeler is to identify and model the edges of the state-transition graph, i.e., the actions available to the legacy system user for navigating from one screen-state to another. moves) K Revise(TreeNode $$LMN,(* N,HOPQ #tree, N,($R*MoJoPlusMoves 7 #OP RMP *7 15$ ;"D 5B * D B F . 1M B($E +SQ&*$ '*0T0U>V L ' .
#N,(O0+$FE GCL*N,($ B($E " 5O ' '7
#N,($R*0+$FE GCLM,($ B($E " RM ' '7 1M N,(OE &* C '*0H0 N,H$RME &* ' '
N,(OE &* 'E $ N,HO!'7 $
N,(FRME F N,(O!'7 J WHW 34B -3 ! +* 5B $ .
N,HO0+$$E GC6LMN,H$ B FE " 5O ' '7 OX04YB $E " 5O '7 RZ04 B($E " QRM '7 Z04 B($E YB $,( % "$$$ '7 8 &( L*N,($$V! < $ + !$$ OPCR*P '7 J J [$\Q]^`_`a/b(c d;[$efNgd;h;_ij d;[$k l ]i[$_d;jnm-oNp-o!l ' 1# OE qT$ '*)4RME qT$ ' ' . 8 &( :OX D $,215$ + !$ 51COr $,-9(SsRMtT M7 u + !5 r 1# "F"$$$1 !7 8 &( :OX D $,215$ + !$ 51MRMtT 2% $,-9(S/O7 u + !5 r 1# "F"$$$1 !7 J $ . u B $*v-,(1M $Y > r 1M" $$7 J 1# Rxw 0 ! ' . 8 &( LMN,(F$Vn < $ + !$$ OPQ ! P '7 u + !5 7 J 1# ME qTF)>y%' . /yFP MzF'*09*$ 8 &( 2 M7 8 &( LMN,(F$Vn < $ + !$$ OPCR*P /y%'7 8 &( LMN,(F$Vn < $ + !$$ OPCR*P MzF'7 J Figure 4: The pseudo-code for the decision tree extension algorithm. The grammar shown in Figure 5 was developed to describe the various styles of interaction mentioned earlier. But currently, the action modeler can model a combination of function-keys and command-driven interaction styles. In the future, it will be extended to cover the rest. It requires at least three instances of every action in order to infer a model for it. This grammar describes the general “transition model” of LeNDI. According to this model, each transition from a start screen-state to an end screen-state is
caused by an action, which may consist of one or more action items. An action item may involve a data-entry activity, data item, at a particular location of the screen-state, which may be static or dynamic, i.e. varying within a range. An action item may conclude with the press of a control key. A data item can have keywords, arguments and/or options.
K + { 0 8 5 8 "$ |% F)HO"+ #)TH}H , 8 "$ |% F) O"+ ={ 0YO"+% = F )T~ O"+ = ${ 0 HTN"$ + #)YT F ) HTN"$ + #)HH
$Y)HT M C+*>SC) HN"$ + D{ 046 !| SAHN"$ +5 ): u GC$) ϕ !| SAHN"$ + D{ 0Y GCP GC u GC { 04 GCPC GC|> GCP GC ${ 04H>SQ
,H)H5O!5GQ )H?HVn&(+5 )H >SQ
, { 0 8 +5 G ∈ 8 1C&>N$ 9(**SQ
,( O!5GQ 2{ 0 8 +5 G Vn&(+ D{ 0 8 +5 G ∈ 8 1C&>N$ 9( 5&(+ M +>>SA{ 0Y(
