Mining the User Interface and Navigation

from a Legacy Application

Michael Oara

CEO, System Renewal, Inc.

As we look at a legacy application, we may want to discover not only potential services, which form the flexible lower layer of a modern SOA architecture, but also the user interface and the screen navigation. If we can identify this “upper” layer and externalize it in a form that could be consumed by other modern tools, the road is open for a re-implementation in a new environment.

The table bellow illustrates the way in which the legacy artifacts are savaged and either re-implemented or used in a new architecture.

Layer	Legacy	Modern
Client facing	User interface (green screens) Navigation (via CICS or IMS transfer of control)	Browser or other user interfaces
Intermediate	Business rules imbedded in the code	Business Rule Engine
Data facing	Programs or program routines specialized in I/O operations	Web Services

Relativity’s SOA Analyzer gives us the tooling needed to address both the bottom layer and the top layer. In this chapter I will explain how the user interfaces and the screen navigation could be harvested with the aid of the SOA Analyzer. For better illustration, I used as an example a small application called Order Entry.

Tools needed:

· RMW Analyst

· RMW SOA Analyzer

RMW Analyst is the basic tool used to parse the application code and store all the information in a repository, for further access. The SOA Analyzer will be used to perform the actual user interface and navigation mining.

After I have registered the Order Entry application code to RMW and parsed the code, I can open the SOA Analyzer and immediately see the classification of the legacy artifacts into the proper layers. A more complete explanation of this classification is given in the Mining Services section of this book and now we’ll pay attention mainly at the screens.

We notice that under the User interface node we can find

• Transactions -  which are the CICS transactions that the user can invoke in order to access various screens
• Screens, classified as
• Screens without access to data – most probably ‘menu’ screens
• Screens with access to data – from which the user performs various operations against the persistent data of the application

Now we can explore the position or role of the screen in the application. We can see the image of the screen itself, as well as a vertical slice and a horizontal slice through the application, both centered in the selected screen.

As I select the screen ORDSET1.ORDMAP1, I can look at its image, just as the user of the application would see it.

It is easy to understand that this is a screen on which an operator enters the details of a customer order.

A vertical slice through the application architecture reveals the following diagram:

Some important facts could be immediately understood:

• Screen ORDSET1.ORDMAP1 is accessed by two “client” programs, ORDENT1 and ORDERR1. The name of the last one suggests that it deals with exceptions from normal processing of an order.
• The two ‘client’ programs that access the screen and call other programs to fulfill some tasks
• Some service programs, like NUMEDIT or GETINV. NUMEDIT is not accessing any persistent data, while GETINV is reading and updating the DD01.INV.CONTROL file.

A horizontal slice for the same screen, ORDSET1.ORDEMAP1 will show navigation from and to other screens.

It indicates that one arrives to this screen from MENSET1.MENMAP1 and ORDSET1.ORDMAP1 (itself), and could move to the same screen.

Once we have this general understanding of the functional role of the screen as well as of its position in the overall architecture, we can move to the next steps, of which the first one is to specify the events that lead to these transitions between screens. A right click on the node for the screen prompts us with a popup menu, from which we can select “Screen Events.” This will lead us to a new window.

On the left pane, this window lists all possible transitions from this screen to other screens. If I select one of these transitions – for example that to screen MENSET1.MENMAP1 – the right pane displays the image of the source and target screens of a particular transition. On the left pane, next to the target screen, I can write the name of an event that leads to it. In this particular case, I specify an event named ‘Return,’ to indicate that from the order entry screen I return to the menu screen MENSET1.MENMAP1. For the transition between the screen and itself, I indicate the event ‘Update,’ as an update request would place the order items in the file and re-display the same screen. I can specify multiple events for the same transition. For example, it may be that from MENSET1.MEMMAP1 I can both update and insert new items for an order, in which case I would specify the events separated by commas, like ‘Update,Add’.

We can repeat this event specification for each screen in the application, the same way as in this example. Once all the events were specified, we can select the Tools/Screen navigation menu of the SOA Analyzer in order to see a complete screen navigation diagram, as the one bellow.

This diagram gives a complete picture of what the operator can do.

• From the ‘main menu’ screen MENSET1.MENMAP, the operator can request to view or maintain customer information, or to enter a customer order.
• On the ‘customer inquiry’ screen INQSET1.INQMAP1 the operator may view the customer information.
• From the ‘customer maintenance’ screen MNTSET1.MNTMAP1, the operator can delete the customer, or move to the ‘customer data’ screen MNTSET1.MNTMAP2, where the customer information may be added or changed.

At this point we have a clear picture of the screen navigation, which can be exported in XML format (using the File/Export navigation) menu. This will create an XML file that describes not only the layout of the screens, but also the events that control the navigation. This file can be used to generate the user interface and the navigation on another platform. Users of the SOA Analyst tool receive a sample XSLT file that defines a simple transformation from the this file to an HTML format that renders the screens as exactly as they appear in their native environment. For example, the screen ORDSET1.ORDMAP1 to which we have looked above, will appear in an internet browser as bellow.

You may notice that the events that can be executed from this screen (Update and Return) appear at the bottom as buttons. This is necessary because some of the mainframe specific events, such as those implemented through PF keys, are not available or are assigned to other function in the internet browser.

The XSLT file used here is shown bellow.

<?xml version="1.0" encoding="ISO-8859-1"?>

<xsl:stylesheet version = "1.0" xmlns:xsl = "http://www.w3.org/1999/XSL/Transform">

    <xsl:template match = "/">

        <html>

            <body style = "background-color:black">

                <xsl:for-each select = "Screen/Fields/Field">

                        <xsl:choose>

                       <xsl:when test = "@Protected = 'No'">

                             <div>

                                     <xsl:attribute name = "style">position:absolute;border:1p solid red;top:<xsl:value-of select = "25 *@Line"/>;left:<xsl:value-of select = "15 *@Column"/></xsl:attribute>

                             <input>

                                   <xsl:attribute name="type">text</xsl:attribute>

                                   <xsl:attribute name="size"><xsl:value-of select="@Length"/></xsl:attribute>

                             </input>

                             </div>

                        </xsl:when>

                        <xsl:otherwise>

                              <div> <xsl:attribute name = "style">color:green;font-weight:bold;position:absolute;top:<xsl:value-of select = "25 *@Line"/>;left:<xsl:value-of select = "15 *@Column"/></xsl:attribute>

                                        <xsl:value-of select = "@name"/>

                                         <xsl:value-of select = "@Value"/>

                               </div>

                       </xsl:otherwise>

                     </xsl:choose>

                 </xsl:for-each>

                <center>

                 <div><xsl:attribute name = "style">position:absolute;top:625;left:0;width=1200</xsl:attribute>

                 <xsl:for-each select = "Screen/Events/Event">

                             <input>

                                   <xsl:attribute name="type">button</xsl:attribute>

                                   <xsl:attribute name="onclick">window.location='<xsl:value-of select="@TargetName"/>.html'</xsl:attribute>

                                   <xsl:attribute name="value"><xsl:value-of select="@Name"/></xsl:attribute>                                

                                  <xsl:attribute name="style">background-color:while;color:blue;border:1px solid black</xsl:attribute>

                             </input>

                   </xsl:for-each>         

                   </div>

                   </center>

            </body>

        </html>

    </xsl:template>

</xsl:stylesheet>

The XSLT may be modified to suit the needs of the new platform on which the UI is implemented.