IB-ARM Version 4 - Information Balanceinfobal.com/wp-content/uploads/2014/09/ARM-V4... · h. user guide – provides online ... February, 2013 Application Road Map (ARM) Version 4.5

IB-ARM Version 4.5 Sample Screen Shots

Information Balance, Inc. February, 2013

Screen shots are based on Version 4.5. Copyright 2013 Information Balance, Inc.

Information Balance, Inc.

Application Road Map (ARM) Version 4.5 - Sample Screens 2 February, 2013

The typical ARM screen consists of three distinct areas: (1) The main viewing area is the primary display for

repository content.

(2) The Table of contents provides an organized list (inventory) of all components in the Repository. It is highly customizable and clients can apply a variety of organizing principles / criteria.

(3) The menu bar provides access to tool functionality

a. show/hide toc - takes away the Table of contents to provide a larger viewing area for information content

b. dashboard – invokes dashboard metrics pages

c. search – allows users to do a quick search (see later)

d. advanced search – invokes the advanced search facility (see later)

e. impact analysis - invokes that functionality f. print – prints the content of the main viewing

area g. settings – environment settings h. user guide – provides online access to ARM’s

User Guide

Table of Contents

Main Viewing Area

Menu Bar

Analyst Workbench



When a component is selected from the Table of contents, the tool displays its “home” screen, the Relationships view. This view is based on the underlying meta model for the particular install (reflecting the technologies in scope). It provides a list of all the directly related components.

Analyst Workbench



In this example, one can immediately see for the program JQ31000T: • The 6 DB2 tables it accesses; • The 8 Copybooks it uses; • The Load Module in which it is included; • The JCL and the PROC that execute it; • The 2 programs that it is calling; • That it is NOT called by any other programs • • Etc. etc. etc… Notice that all referenced components are hyperlinked (blue underline) which provides direct navigation to the component.

Analyst Workbench



The Relationship View can be filtered to include all relationships or only the active relationships. The Relationship Diagram is a graphical representation of the active relationships for the selected component.



This example illustrates the All Relationships view for a Java Class. One can immediately see: • the Package it belongs to • its Constructor • its 6 Fields • its 13 Methods • the 1 Class that it inherits from • the 2 Classes it is inherited by

Analyst Workbench



For any component that has source code associated with it, the source is accessible from the {Source} drop-down. For component types that include other components (e.g. COBOL program including Copybook, JCL including PROC) both the original source and the expanded source is available. Analysts do not need access to a separate source management tool.

Analyst Workbench



The Source and Expanded Source are colorized to allow key language elements to be easily identified. The main colourized elements are: - External components, such as other program objects or database tables, are hyperlinked (blue underline) - Comments are in green text - Language instructions are red text - Variables and fields are blue text

Analyst Workbench



Additional colourizing features for the Expanded Source are: - Included copybooks and procs are highlighted in green - For Cobol, Dead Code appears in highlighted in grey.

Analyst Workbench



The Call Tree for a given program is accessible from the {Diagrams} drop-down. The Call Tree provides a contextual display for the selected component by showing the call sequence that leads to the component and the subsequent calls that originate from the component. In the above example, the call sequence to JQ31000T originates in JCL JQ31LETC; and the program subsequently calls two other programs; HFCM000 and USERCODE. Each box representing a component in the diagram is hyperlinked to the component’s “home” page.

Analyst Workbench



Call Tree-s can become quite large and extensive. Viewing is aided by functionality that allows the user to zoom-in, zoom-out, reposition and search the diagram. In this example, one can see that program CS01100T calls many programs. Modules that appear multiple times in a Call Tree are shown in grey after the first call instance (from left-to-right, top-to-bottom).

Analyst Workbench



The Flowchart option from the {Diagrams} drop-down displays the internal program structure for the selected program. For COBOL, each box represents a paragraph and is hyperlinked to the precise starting position of the paragraph within the source code. Note that this diagram (and all other diagrams within ARM) is dynamically generated, so it always reflects the actual source in production.

Analyst Workbench



If the user clicks on 3000-GEN-CCIN-NOTIFICATION, a new window will open displaying the source code at the line of the selected paragraph.

Analyst Workbench



The Dependencies option from the {Diagrams} drop-down (available for JCL Jobs) displays jobs, events that must precede and / or follow a selected JCL Job component (JQ22RPTR in this example). The diagram is color coded to easily identify dummy jobs, external jobs, triggering, predecessor and successor relationships. This view is based on information parsed out of a Job Scheduler (examples: CA7, Maestro, Control M, JobTrac, etc.).

Analyst Workbench



For Java Classes, the Inheritance option from the {Diagrams} drop-down displays a dynamically generated inheritance diagram for the selected component.

In the diagram, the names of packages, classes, fields and methods are all hyperlinked for easy, direct navigation to the referenced component.

Analyst Workbench



The Data Access option from the {Impact} drop-down displays the various data accesses the component makes and the type of access: CRUD (Create, Read, Update, Delete) . In this example, one can see that program JQ31000T reads 6 different database tables and performs update and delete operations on one of them. The program also creates a sequential file and reads 24 columns from the database tables. The Data Access option is available for Programs, JCL’s, Load Modules as well as inversely for files, tables and databases.

Analyst Workbench



This example displays the Data Access view from a specific DB2 table’s perspective (JQ_COMPANY). In one summary view, one can see all the components that directly and indirectly use this table, along with the type of usage. The Data Access information is directly parsed from the underlying source code and escalated to higher level components.

Analyst Workbench



This example illustrates how simple search works for a specific component in Source code. The search for the variable <jq-audit-oper-id> locates 8 components that contain that variable. Each line of code where the variable is located is displayed for each component. The number of matches within the component is indicated example: (5 matches).

From any of the found components, one can directly navigate to the various views available for that component In the case of a COBOL program, this includes: • Relationships, All Relationships, Relationship Diagram and Properties • File, table or database accesses (Data Access) • Calls to and calls by the program (Call Tree) • Program structure (Flowchart) • Source code as saved in the library (Source) • Expanded source code (with copybooks expanded) (Expanded)

Analyst Workbench



To search meta data, the user enters the component name (full or partial) in the search box and selects Name search. In this example a meta data (component) search is initiated for all components named PolicySearch. The search then returned 12 components including a Database table, Java Class, Java Constructor, Java Method and 7 Java Fields.

Analyst Workbench



Search expressions can be quite complex and can include wild cards, Boolean operators, exclude/include indicators, etc. This example illustrates a search for programs that contain OPEN INPUT, OPEN OUTPUT, READ and WRITE statements within the Procedure Division, but not CLOSE….in effect, programs that open files without closing them.

Analyst Workbench



Advanced Search accommodates one or more filters for the search. Filters provide for reducing the base result set by a variety of pre-defined criteria. One or more filters can be provided. Based on the number of filters and the filtering criterion the user can construct low, medium and high complexity searches. For non-Java platforms, the user can specify the type of filter (application, type, name, language group, etc.), the criterion (is, is not, contains, etc.) and the value to be matched. Each of the three drop-downs is configurable based on the content of the ARM Repository. Multiple filters can be created by clicking on the + sign to the right of the last specified filter. When multiple filters are used the filters are strung together with either a Boolean AND (Match all criteria) or with a Boolean OR (Match any criterion). For searching Java applications ARM provides Java-specific filtering.

The Advanced Search page also allows for changing various parameters that control the behavior of the search and the presentation of the results.

Analyst Workbench



Extended Search provides an extended view from a selected component to all the components it is related to. In the example, a search for program variable JQ-COMP-NO can be extended to the copybook that contains the variable, DB2 tables defined by the copybook, programs that use the copybook through to JCL and transactions that execute the programs. This feature is available for program variables, DB2 tables, IMS databases and files.

Analyst Workbench



Search History saves each and every search query that the user has specified. The saving of search queries is automatic. Searches can be organized into personalized folders. This feature allows for the quick re-execution of frequently needed searches.

Analyst Workbench



Impact Analysis is a sophisticated extension of the tool’s extended search capability. For a given variable, Impact Analysis identifies a series of related components – connected either directly or transitively and either syntactically or semantically - that satisfy specific impact analysis rules. Impact analysis is performed in an iterative series of analysis steps using the Impact Analysis Worksheet – illustrated here. In this example, the user is looking for all downstream components that may be impacted by a contemplated change to variable LW90-PROG-ID.



Once the Impact Analysis project is complete, the Estimation View assists the Analyst in creating a work estimate for the contemplated change. For each affected component the required action and effort can be specified (standard estimation metrics can be configured during install). The resulting worksheet can then be easily exported to Excel and shared with project team members.



Application metrics (size, complexity, quality) are directly derived from the parsed source code. The findings are presented on the tool’s Dashboard both in tabular and graphical formats. Metrics are reported at the portfolio level and for each of the individual applications.

Analyst Workbench



Administrator Workbench

The Administrator Workbench automates the creation of repository content (refresh) and provides for a variety of housekeeping functionality such as user administration, logging, and tool configuration

IB-ARM Version 4 - Information Balanceinfobal.com/wp-content/uploads/2014/09/ARM-V4... · h. user guide – provides online ... February, 2013 Application Road Map (ARM) Version 4.5

Documents