Reengineering of an Investment Fund Information Platform by sdfgsg234

VIEWS: 28 PAGES: 66

									                         er3w




              Diploma Thesis


Reengineering of an Investment Fund
       Information Platform



                    Written at the
                 University of Zurich

           Information Systems Institute
           Software Engineering Group
               University of Zurich


                 under the guidance of

     Univ.Prof. Dipl.-Ing. Dr.techn. Harald Gall
               Dipl. -Ing. Martin Pinzger


                          by

                      Peter Ming
                Stampfenbachstrasse 72
                     8006 Zürich
                  ming@icu.unizh.ch
                  Matr.Nr. s99713695
Acknowledgements


First and foremost, I am deeply indebted to my advisors Harald Gall and Martin Pinzger for their
guidance, advice, and patience and for providing constant direction and focus to my research.

I also owe thanks to several current and former members of SHB AG for their cooperation and
numerous interesting discussions.

I would like to thank Margaret Skiber and Benjamin J.J. Voigt for proof-reading my thesis.

Many thanks to my parents for their support and understanding during my studies.

I thank those many others not named here for their assistance and helpful advice during my
graduate studies.

Further I thank the company CAST Software for using their CAST Application Intelligence
Platform for analyses purpose.




                                                                                       Page 2 of 66
Abstract
The application FIP publishes detailed product information about SHB Investment Funds over
the internet and intranet. As a result of a competitor analysis FIP is decided to be adapted to the
new requirements and reengineered.
This thesis is part of the reengineering project and delivers substantial input for it. One part
addresses the evaluation of different portal providers and analyses the existing application with
the application mining tool CAST. Based on the results a decision towards a new solution and a
design recovery of the existing application is made. Accompanying to the reengineering project
the thesis evaluates the reverse engineering ability of CAST. Further gives the thesis a practical
experience report of the usage of the Object Oriented Reengineering Patterns applied in an
industrial reengineering project. The objective of the thesis is to find out the reengineering
potential of the application. Within the scope of this thesis an example of the proposed changes
is implemented to test the feasibility and possible success of the new technology.


Zusammenfassung
Die Applikation FIP stellt aktuelle Produkteinformationen zu allen in ganz Europa zum Vertrieb
zugelassenen SHB Fonds über das Internet und Intranet zur Verfügung. Aufgrund einer
Wettbewerbsanalyse soll FIP an die aktuellen Anforderungen angepasst und reengineered
werden.
Die Diplomarbeit begleitet das Reengineering-Projekt und liefert substantiellen Input dafür. Ein
Teil der Arbeit befasst sich mit der Evaluation verschiedener Portalsoftwareanbieter und
analysiert die existierende Applikation mit CAST. Aufgrund der erhaltenen Resultate wird eine
neue Technologie ausgewählt und ein Design Recovery der bestehenden Applikation
durchgeführt. Begleitend zum Reengineering Projekt wird die Reverse Engineering Fähigkeit
von CAST überprüft. Weiter enthält die Diplomarbeit einen Erfahrungsbericht über die
Anwendung der Objekt Orientierten Reengineering Patterns in einem industriellen reengineering
Projekt. Das Ziel der Arbeit ist das reengineering Potential von FIP heraus zu finden. Im Rahmen
der Diplomarbeit wird ein Beispiel der vorgeschlagenen Änderungen umgesetzt, um damit den
Einsatz der vorgeschlagenen Technologien für die Entwickler zu untermauern.




                                                                                          Page 3 of 66
Table of Contents




1.      Introduction .....................................................................................................................8
1.1     Problem Statement ............................................................................................................8
1.2     Contributions .....................................................................................................................9
1.3     Organization of the thesis..................................................................................................9

2.      FIP...................................................................................................................................10
2.1     What is FIP......................................................................................................................10
2.2     Competitive Upgrade for SHB FIP .................................................................................10
2.3     Technical implementation of FIP 2.0 ..............................................................................11
2.4     Outlook FIP 3.0 ...............................................................................................................13

3.      Portal Software Evaluation ..........................................................................................14
3.1     Initial Position .................................................................................................................14
3.2     Portal Software ................................................................................................................14
3.3     Providers of Portals .........................................................................................................15
3.3.1   Peoplesoft – Enterprise Portal .........................................................................................15
3.3.2   SAP – Enterprise Portal...................................................................................................16
3.3.3   BEA – WebLogic Portal 8.1............................................................................................16
3.3.4   IBM - Websphere Portal V5............................................................................................16
3.3.5   Microsoft - SharePoint Server 2003................................................................................17
3.3.6   Open Source Providers....................................................................................................17
3.3.7   Summary of Providers.....................................................................................................19
3.4     Discussion .......................................................................................................................20

4.      Analysis...........................................................................................................................21
4.1     CAST Software ...............................................................................................................21
4.1.1   CAST Server Manager ....................................................................................................22
4.1.2   CAST Analysis Manager.................................................................................................22
4.1.3   CAST Enlighten ..............................................................................................................23
4.1.4   CAST APM Suite............................................................................................................23
4.2     Metrics.............................................................................................................................25
4.2.1   Five High-Level Indexes .................................................................................................25
4.2.2   Functional Size Index......................................................................................................25
4.2.3   Technical Complexity Index ...........................................................................................26
4.2.4   Artefact Granularity Index ..............................................................................................28
4.2.5   Artefact Coupling Index..................................................................................................29
4.2.6   Standard Violation Index.................................................................................................29
4.3     Analysis of FIP 2.0..........................................................................................................30
4.3.1   Inventory .........................................................................................................................30
4.3.2   Indexes Overview............................................................................................................31



                                                                                                                                   Page 4 of 66
4.3.3   Functional Size Index......................................................................................................32
4.3.4   Technical Complexity .....................................................................................................33
4.3.5   Artefact Granularity Index ..............................................................................................36
4.3.6   Artefact Coupling Index..................................................................................................36
4.3.7   Standard Violation Index.................................................................................................37
4.4     Discussion .......................................................................................................................38

5.      Prototype of FIP 3.0 ......................................................................................................40
5.1     Introduction .....................................................................................................................40
5.2     The Four Options.............................................................................................................40
5.2.1   Alternative I: BEA Weblogic Portal ...............................................................................40
5.2.2   Alternative II: Integration in CE Courses........................................................................41
5.2.3   Alternative III: IBM Websphere Portal (without CE).....................................................42
5.2.4   Alternative IV: Pure Websphere Application .................................................................42
5.3     Decision...........................................................................................................................43
5.4     Architecture of FIP 3.0....................................................................................................43
5.5     Reused Components ........................................................................................................45

6.      Tools................................................................................................................................48
6.1     CAST valuation...............................................................................................................48
6.2     CAST as Reengineering Tool..........................................................................................49
6.3     Object-Oriented Reengineering Patterns.........................................................................51
6.4     Self defined and used Patterns.........................................................................................54

7.      Conclusions ....................................................................................................................56
7.1     Future work .....................................................................................................................56

8.      Appendix ........................................................................................................................57
8.1     Metrics.............................................................................................................................57
8.1.1   5 High-Level Indexes ......................................................................................................57
8.1.2   Functional Size Index......................................................................................................58
8.1.3   Technical Complexity Index ...........................................................................................60
8.1.4   Artefact Granularity Index ..............................................................................................63
8.1.5   Artefact Coupling Index..................................................................................................64
8.1.6   Standard Violation Index.................................................................................................65

9.      References ......................................................................................................................66




                                                                                                                                  Page 5 of 66
Tables Index
Table 1: Overview of the features of the different vendors. .........................................................19
Table 2: Overview of the inventory of FIP 2.0. ............................................................................30
Table 3: Overview of the five high level indexes..........................................................................31
Table 4: Sub metrics of the Functional Size Index........................................................................32
Table 5: Four sub metrics of the Technical Complexity Index. ....................................................33
Table 6: Indicators of the Cyclomatic Complexity. . ....................................................................33
Table 7: Object-Oriented Complexity. .........................................................................................34
Table 8: Indicators of the SQL Complexity Index. . .....................................................................35
Table 9: Artifact Granularity index and the number of artefacts. . ...............................................36
Table 10: Detailed information of the Artifact Coupling Index....................................................36
Table 11: Five conventions on which the Standard Violation Index results. ................................37

Picture Index
Figure 1: Architecture of the existing FIP application. .................................................................11
Figure 2: Print screen of CAST Server Manager. .........................................................................22
Figure 3: Sample project in the Analysis. .....................................................................................22
Figure 4: Print screen of CAST Enlighten. ...................................................................................23
Figure 5: Cost control screen out of CAST APM Suite. ...............................................................24
Figure 6: Five high level indexes pictured in a radar chart. ..........................................................31
Figure 7: Radar chart of the Standard Violation Index. ................................................................38
Figure 8: Overview of the architecture of the old solution in contrast to the new solution. .........45
Figure 9: Code Viewer and graphical component of Enlighten. ...................................................49
Figure 10: Direct linked objects to the performance JSP. .............................................................50
Figure 11: Path from the performance JSP down to the database table. .......................................50

Source Code Index
Code Fragment 1: Example of a simple data access using the QueryTag. ...................................12
Code Fragment 2: Simple way of displaying the returned BaseBean. .........................................12
Code Fragment 3: Parameter Passing. ..........................................................................................46
Code Fragment 4: Assignment of the result of a query into a variable. ........................................46
Code Fragment 5: Compares the IF statement in Sybase T/SQL and Oracle PL/SQL. ................47
Code Fragment 6: Different query languages means also different function names.....................47




                                                                                                                     Page 6 of 66
List of Abbreviations

AIE             Automated IFPUG Estimation
AM              Asset Management
BB              Busines Banking
BFP             Backfired Function Points
CE              Client Environment
CMS             Content Management System
CMS             Content Management Systems
COTS software   Common Of The Shelf software
Courses         Web Application to Provide Prices
EAI             Enterprise Application Integration
FIP             Fund Information Platform
FSI             Functional Size Index
GUI             Graphical User Interface
IFPUG           International Function Point Users Group
JSP             Java Server Page
MVC             Model-View-Controller
NCSS            Non Commented Source Statements
OO              Object Oriented
PL/SQL          Procedural Language/Structured Query Language
SHB             Swiss Home Bank – Changed name of a major Swiss bank
T/SQL           Transaction/ Structured Query Language
UDF             Unadjusted Data Functions
UTF             Unadjusted Transactional Functions
WSRP            Web Services for Remote Portlets




                                                                       Page 7 of 66
1.            Introduction


In this thesis experiences made during an industrial reengineering project of a fund information
platform within a major Swiss bank (SHB) are presented. The application FIP1 publishes fund
information over the internet. To keep on track with other competitors, a comparative analysis
was done on which was decided to improve the application.
The whole project, is in a sense, not a real software reengineering project in which the
functionality of the application remains the same. “If the functionality remains constant and only
the form changes, it is reengineering. If even one minor function is added, deleted or changed, it
is engineering” [SNEED95]. In fact, the project also includes enhancing the functionality of the
application, which is a topic of software engineering. Simultaneously a database reengineering
project is running. This thesis addresses solely the reengineering part of the project, which
includes all activities that are necessary for the migration of the existing solution to a new
environment. Activities, like implementing the new functionality or reengineering the existing
database are not part of this thesis. Also, reasoning regarding whether the reengineering is worth
the effort or if the system should be replaced with a new one is left out. The justification of the
project has taken place in the run-up phase.


1.1           Problem Statement

The additional requirements, resulting from the competitive comparison of web platforms to
other fund vendors, make it necessary to upgrade FIP. Due the fact that the new requirements are
numerous and from a high technological level, a suitable technology must be found for the new
solution. First it must be examined whether the existing technology can meet the new
requirements. If this is not the case a different technology has to be considered. “The choice of
technology will shift the entire productivity curve upward or downward” [LONG]. Therefore a
part of the thesis addresses the evaluation of different portal software technologies to examine an
appropriate technology.
Another part of the thesis addresses the analysis of the existing application with the COTS
application mining software CAST. “If a project is going to be a replacement project for an
existing application then a logical first step would be understand the size (amount of
functionality) of the existing application” [LONG]. The results of the analysis firstly help to
comprehend the existing application and secondly they are used to determine which components
of the existing application have reengineering potential.
Based on the considered technologies and the acquired knowledge of the existing application, a
choice on which technology the new system is built has to be made. After the technology is
chosen a possible architecture for the new implementation is devised.




1
    Name of the application changed. FIP stands for Fund Information Platform.




                                                                                          Page 8 of 66
1.2       Contributions

The major contributions of this thesis are:

•     Experience report of an industrial reengineering project.
•     Evaluating portal vendors and highlight their advantages and drawbacks. Create a decision
      guidance for projects concern using portal technology.
•     Evaluating the COTS software CAST - Operate with software metrics in practise. Examine
      the utility of CAST and its metrics in a reengineering project.
•     Usage of Object Oriented Design Pattern – Practical experience report.


1.3       Organization of the thesis

After the problem description and a statement regarding the contributions of this thesis, the
second chapter introduces FIP and points out why it should be reengineered and shows the
technology on which the current application is implemented. At the end of chapter two an
outlook on the new implementation of FIP is given.
Chapter three first introduces the term “portal software” and explains why there is such a run on
this “new” technology. In a second step different portal vendors are introduced and evaluated.
Finally, a discussion about the most appropriate technology is presented.
Chapter four concentrates on the analysis of the existing application. First the COTS application
portfolio management tool CAST is introduced. Next the five different metrics calculated by
CAST are named and discussed as needed. After having seen how the different metrics are
calculated, the results from the analysis of the existing FIP 2.0 are analysed in more detail. Then
a recommendation regarding what parts of the FIP 2.0 are suitable to be reused is presented.
Chapter five addresses the new implementation of FIP. Firstly, the four solutions which are
considered are introduced and discussed. After having seen the different solutions a decision is
made about which technology FIP 3.0 is built. For the decision the results acquired by evaluating
the portal vendors and the results of the analysis with CAST are taken into account. After a
possible architecture, how the new system is implemented and what its architecture looks like is
presented. In the end the parts which are suitable for reuse are identified and shown in an
example.
Chapter six shows how CAST is used during the project, how the tool influenced the decisions
and what the surplus value is to working with the tool. In a second part of chapter six the
experience made applying the object oriented design patterns and its use is documented.
Finally, chapter seven draws conclusions about the reengineering project. It describes the steps
needed to move from FIP 2.0 to FIP 3.0. It highlights what can be expected by CAST and
recapitulates what the advantages and disadvantages are. Then the used patterns are summed up,
as well as their value in the project. Additionally, some suggestions for future work are provided.




                                                                                          Page 9 of 66
2.         FIP


2.1        What is FIP

FIP 2.0 is a web application available on the internet and SHB intranet that provides customers
and client advisors with detailed information about SHB Investment Funds. The project started
in 1997 and the application was launched in summer 1999 (intranet) and in autumn 1999
(internet).
FIP is the strategic application to display investment fund information on the internet and
intranet. The audience is worldwide, legal and distribution restrictions dependent.
The main purpose of FIP 2.0 was to give an easy access to information about SHB Investment
Funds focused primarily on the Swiss Market. In contrast to SHB Courses where mainly price
information is available, FIP offers a wide range of detailed information about SHB Investment
Funds such as:

-     Key data
-     Prices
-     Performance Data
-     Performance Charts
-     Structures
-     Distribution
-     Authorizations for distribution
-     Publications

Mid 2002, FIP was one of the leading fund information systems in comparison to its main
competitors, especially under the aspect of the possibility of tailor-made queries and the depth of
information provided. The usage statistics for October and November 2002 showed that there
were about 340,000 page hits on the internet per month and about 100,000 on the intranet.


2.2        Competitive Upgrade for SHB FIP

SHB FIP 2.0 was released at the end of 1999 and its functionalities have been continuously
enhanced and maintained. With about 1 million page views per month at the end of 2004, SHB
FIP has established its position as the primary information platform for SHB Funds. SHB FIP is
presently a prominent business channel link on SHB’ web site, which stresses the importance of
this application to SHB clients.

To keep on track with other competitors, a competetive analysis has been performed to compare
both usability and functionality of existing fund information platforms. For the competitive
analysis, three companies were chosen which are strong in the fund market and are known for
their industry leading web platforms. SHB FIP has been compared to the platforms of these three
comapnies. When compared to its competitors, SHB FIP offers average usability with the
functionality in place to search and find all information available for each SHB Fund. For this
reason a reengineering project has been launched to catch up the functional and technological
gap in comparison to the competitors mentioned above.



                                                                                         Page 10 of 66
2.3         Technical implementation of FIP 2.0

FIP 2.0 is a strategic application to display investment fund information on the Internet and
Intranet. It does not create persistent data and so it can be described as a strictly presentation
layer focused application. The primary goal of the architecture of FIP 2.0 was simplicity. FIP 2.0
allowed the use of such architecture because it only displays data, in contrast to an application
that also makes create, read, update and delete transactions on data.
The implementation of FIP 2.0 is mainly done by using the JSP technology. This means that the
JSP files not only contain code for displaying purpose but also code which contains business
logic. As can be seen in Figure 1, each main JSP is split into 3 sections, a data base access
section, a business object section and a user interface section. These sections have a one-to-one
mapping to the three application layers, namely the database access layer, the business object
layer and the user interface layer.


              JSP d e sig n                                 Softwa re la ye rs / da ta flow
                                             C ontrolle r
                                                                       Re q ue st
                                                                       O b je c t



                                             M od e l
                                                               d a ta b a se la ye r
        d a ta b a se a c c e ss se c tion
        < %@ inc lud e file … … .>


                                                                    Ja va Be a n
                                                                     Ob je c ts
                                             M od e l

         busine ss ob je c t se c tion
           < jsp :use Be a n… .>                             b usine ss ob je c t la ye r



                                                                     Ja va Be a n
                                              Vie w                   O b je c ts

          use r inte rfa c e se c tion

                                                              use r inte rfa c e la ye r




Figure 1: Architecture of the existing FIP application.




The main JSP does not directly contain the code of the database access layer. It uses an included
directive to copy a sub JSP into this section. This sub JSP is designed in such a way that other
applications implemented with Java technology can make use of this component, thereby reuse
of these components is achieved without much effort. All replies from the database are
encapsulated in Java Beans which are the most basic business objects. If the information of these
Java Beans is needed for composition of more complex business objects then this is done in the
second layer. The resulting business objects of the second layer get forwarded to the user
interface layer where all HTML/JavaScript output is generated and the values from the business
objects are included. The screens of FIP are hard coded, which represents a drawback of the
application.




                                                                                              Page 11 of 66
The database access layer is implemented using a JSP 1.1 tag set. The tag set uses JDBC 2.0 to
access the database. The access to the database does not use complex stored procedures. Instead,
the data is retrieved unchanged from the database and passed through to the second tier for more
advanced processing. As a result of using the tag set, the queries of the application are physically
located in the JSP files. The business object layer takes the business objects resulting from the
executed database query as input. The business objects are represented in Java classes. The
useBean tag is used as instance of a business object. The methods of the instance are then called
and the resulting objects constitute the output of the business object layer. Properties of the Java
Bean can be set using the setProperty tag. Equally a getProperty tag can be used for retrieving
property values. Methods are called using Java Scripts. The JSP code in the user interface layer
is practically a pure html page. All application values and language specific information are
replaced by JSP scripting elements. These scripting elements either access the business objects
from the business object layer or they access Java Beans with localized strings.
For a better understanding of the implementation Code Fragment 1 shows an example of the
QueryTag. The QueryTag allows executing a SQL query against a data source and manipulates
the result set. The QueryTag executes the select statements in its body and stores the result set in
a Java Bean with the id myTest. Java Beans created by the QueryTag in session or application
scope are cached in a thread safe way. This cache is updated only if the query changes or the
timeout is reached. The update after a simple timeout is running in a background thread not
recognized by the user, who temporarily gets the old data until the new data is loaded.



 <bbt:query jndi="jdbc/mypooledconnection" id="myTest" >
 select keyword, value
 from mytable
 </bbt:query>

Code Fragment 1: Example of a simple data access using the QueryTag.



Next, the myTest BaseBean must be processed. As can be seen in Code Fragment 2 the listLoop
Tag is used to loop over a BaseBean list property. This list property has to be a
java.util.ArrayList instance referring to BaseBean objects only. Each of these BaseBean objects
represents one table row. Their property values represent the column contents.


 <bbt:listLoop name="myTest" id="myRow">
 <bbt:lineNumber/> <bbt:get prop="keyword"/>: <bbt:get prop="value"/>
 out.print(myRow.get("value").toString()+","+ myRow.get("keyword").toString()); %>
 </bbt:listLoop>
 The Result may look like this:
 Row1: Value1, keyword1
 Row2: Value2, keyword2
 Row3: Value3, keyword3
 …



Code Fragment 2: Simple way of displaying the returned BaseBean obtained by the QueryTag.




                                                                                            Page 12 of 66
The example shows how to execute a query on the database and to store the results in a
BaseBean. A problem of this aproach is that the queries can not be debugged during execution
time, which leads to a loss of control and development efficiency.


2.4      Outlook FIP 3.0

The main objective of the competitive upgrade of FIP 2.0 is to keep on track with the other
competing applications in the market. The new requirements of FIP 3.0 are numerous and a
portion of them must be implemented from scratch. This circumstance offers the opportunity to
reengineer the existing system in a first step and then implement the new requirement on top of
it.
To implementing the new FIP, two possibilities are considered. Either the existing FIP 2.0 is
enhanced with the newly required functionality or a new solution has to be built from scratch.
The first solution in which the new requirements are built on top of the existing FIP encounters
design related difficulties. As mentioned above FIP 2.0 is a view-only application. Some of the
new requirements of FIP 3.0 demand the possibility to create, read, update and delete data.
Taking this into account, enhancing the existing system results in almost the same effort as if the
solution is redesigned from scratch. Another fact is that FIP 2.0 has grown historically and
because of this changes affect many parts of the application. The developing and later the
maintenance effort therefore is consequently increased. Also, implementing the CMS
functionality (which is one of the new requirements) in the existing solution requires a lot of
resources and raises the total project costs. Based on these facts it has been decided to re-
implement the application.
The second possibility, building FIP 3.0 from scratch, offers an opportunity for SHB Global
Asset Management to make a change in the used technology. Not only is this change partially
required because the new requirements of the upgrade are easier to implement, but also it offers
the chance to move towards an integrated solution. Further, customer demands are easier
satisfiable with a modern programming languages and development approaches [Koll04].
A part of this thesis focuses on the decision of which technology the new FIP 3.0 is built upon.
Another part concerns what parts of the existing application have a reuse potential.
In the next chapter different portal software vendors are introduces.




                                                                                         Page 13 of 66
3.       Portal Software Evaluation


3.1      Initial Position

Almost one fourth of all big companies are using large company portals. Portal software still are
attractive, even though the predictions in the past years were too optimistic. Companies expect
lower costs from portals, which are achieved through efficient processes and well-informed
employees. The portal hype is a result of the diversity of applications that are used in large
companies. Because of working and signing into on several different applications the
improvement brought along by each single application is diminishing because employees start to
copy important information to their local working stations and divert the data from its intended
use. This results in data inconsistency and poor quality of data. Due to the above information, a
portal seems to be a promising solution in order to prevent these circumstances.
This part of the thesis is intended to analyze portal software systems of different vendors. First,
the term “portal software” is described. Thereafter each provider and its portal solutions are
named and the advantages and disadvantages of each are highlighted. Finally, a discussion which
technology is the most appropriate is hold.


3.2      Portal Software

Enterprise portal software is an evolution of the internet portal [E&Y03]. In the early days of the
internet, portals haven been in great demand. A portal is a company wide integration platform
that is positioned as an entrance to other sites/applications on the internet and intranet. It offers a
single point of entry to users and has typically a main page, catalogue and a search engine. The
look and feel and the page reproduction of all applications contained in the portal are
implemented in the same way. This gives the user a certain orientation and raises the
understanding of the different applications, which results in higher productivity of the employee.
The access of the user can be individualized and is offered at any place and any time. It
simplifies the collaboration within a company, between companies and improves the company
wide processes.
For a better understanding of what exactly portal software is, the reader should be given a
definition of the anti scope of portals. The portal concept does not define any particular process
(i.e. business, development, testing, and support processes). It defines the user interface,
navigation and interaction framework in which a solution can be built. It does not define
individual solutions. The portal concept considers the technical architecture and tries to point out
all proposed features but the goal of the portal concept is not to define the application
architecture. Portal frameworks show an example of how the architecture can be implemented
but this suggestion is not mandatory to adopt, it’s usually considered as a recommendation. Also,
the portal concept does not define technical standards for the implementation of portlets or the
rest of the portal framework. The portal concept also does not deal with the specifics of
authentication, authorization and access control. It just describes parts of the security architecture
that are visible to the user.




                                                                                             Page 14 of 66
3.3           Providers of Portals

Like the pioneers in this domain, company portals work with web standards. At the same time,
most vendors offer a possibility to integrate existing applications through EAI techniques and
bring along an infrastructure environment which provides development tools. Basically, portal
platforms have a three layer architecture which includes a presentation layer, business layer and
data layer. Not all vendors offer all of the components themselves, but rather offer purchased
components which can be included. Portal software provides basic functionality as well as small
add-on applications for the end user, which is termed portlets and I-Views. The basic
functionality offered by portals is CMS, EAI capability, security functionality [IX04]. To enable
interoperability between portlets and portals, a specification is defined in the Java Specification
Request (JSR) 168: Portlet Specification. This specification is supported by several companies in
the software industry. The specification contains a set of APIs for portal computing, addressing
the areas of aggregation, personalization, presentation and security [JSR168]. A problem with
the specification is that the large number of stakeholders delays many of the decisions which
have to be made for the JSR 168 standard specification. JSR 168 and standardization means that
the battle for dominance in the portal market no longer depends upon which vendor has an out-
of-the-box integration. Instead customer risks and costs are reduced. It also means that portal
vendors are no longer selected based on their solution portfolio. Instead, the portal vendor is
chosen when its portal product fits into the customer’s architecture [GRE04].
Clearly the JSR standard signifies that portlets development for one portal vendor can be
deployed in a different vendor’s portal. This standardization also simplifies upgrading existing
systems as well as developing new ones. Most major portal vendors have announced plans to
support the JSR 168 standard [BEA04].
Next, an overview of different portal vendors is given. The most important and largest vendors
of portal software have been chosen. These are: Peoplesoft, SAP, Bea, IBM, Microsoft and
different open source providers. To compare the different solutions vendors the following criteria
catalogue was established:

-      General functionality
-      EAI-functionality
-      Developer environment
-      Functionality concerning security
-      User management
-      Technical environment


3.3.1         Peoplesoft – Enterprise Portal

Peoplesoft2 is a combination of the two companies Oracle and Peoplesoft. They offer a portal
solution which is called “enterprise portal”. In this product they offer so-called portal packs. A
portal pack is a pre-built application object called paglets. A list of the offered portal packs is:
PeopleSoft Customer Relationship Management, PeopleSoft Enterprise Performance
Management, PeopleSoft Financials, PeopleSoft Human Resources Management and PeopleSoft
Supply Chain Management.


2
    www.peoplesoft.com/




                                                                                          Page 15 of 66
The Enterprise portal supports Websphere and Weblogic as application servers. Underneath they
operate with databases such as DB2, Oracle, Informix, Sybase and MS SQL, which is a large
spectrum of database technologies. This fact makes the solution almost database technology
independent and is one of the advantages of this solution. Also, with J2EE, .Net, DCOM and
CORBA the solution supports currently established programming environments.


3.3.2      SAP – Enterprise Portal

SAP3 is a recognized provider of business solutions in a wide range of industries. The offered
portal solution is also named “Enterprise Portal” and is at version 6.0. SAP offers their solution
in so-called “Business Packs”. With SAP Enterprise portal it is possible to integrate SAP
solutions, third-party applications, legacy systems and databases. It uses open standards, Web
services, and tight integration with other SAP NetWeaver components to support heterogeneous
systems.
The SAP portal comes with built-in support of Java, Java 2 Platform Enterprise Edition (J2EE),
and Microsoft .NET technology. This range of supported programming environments makes this
solution widely technologically independent. Supported databases are Oracle, MS SQL and
MaxDB. It also offers so called “iViews” which are basic units of their portal content and can be
seen as the basic building blocks of portal content.
SAP Enterprise portal does also support the JSR 168 Portlet specification.


3.3.3      BEA – WebLogic Portal 8.1

BEA4 WebLogic Portal is another product that provides a framework for building custom portals
rather than a package portal solution. WebLogic Portal is built on top of a three layered
framework and extends the underlying WebLogic Server role and security policy architecture.
WebLogic portal provides the following tools and services: CMS, search, collaboration tools and
some other services.
As databases they support Oracle, DB2, MS SQL, Pointbase and Sybase. With these
technologies they provide a solution for all currently named database technologies. In contrast to
competing portal solutions, the programming environment they support is restricted to J2EE only
which restrains its inflexibility.


3.3.4      IBM - Websphere Portal V5

Websphere portal5 is the portal solution of IBM. Websphere is an application server environment
implemented on Eclipse. It provides tools and middleware for developing and running Web
applications. It is J2EE certified. For developing portlets the portal toolkit is required. With the
Websphere portal Application Integrator (WPAI) developers can create portlets that can access
and manipulate data in an existing enterprise application. In the Websphere Portal catalog,
portlets can be downloaded and integrated in the solution.


3
  http://www.sap.com/solutions/netweaver/enterprisePortal/index.epx
4
  http://www.bea.com/framework.jsp?CNT=overview.htm&FP=/content/products/Portal/
5
  http://www-106.ibm.com/developerworks/websphere/zones/Portal/




                                                                                          Page 16 of 66
The programming language which is used for developing portlets is Java. Supported databases
are Oracle, Sybase, Ms SQL, DB2 and Informix which is a wide range of technologies and they
make the solution widely technology independent.


3.3.5       Microsoft - SharePoint Server 2003

SharePoint Portal6 server is the portal solution of Microsoft. SharePoint Portal Server 2003 is
built upon Windows SharePoint Services and can be used to aggregate SharePoint sites and
applications into a single portal. SharePoint Services also offer a development platform for
creating web applications. Microsoft is the only of the chosen portal vendors which does not
support the JSR 168 Portlet specification. However, it supports WSRP (Which is an OASI
standard and therefore vendor independent): Microsoft's WSRP Web Part Toolkit for SharePoint
Products and Technologies leverages the Web Services for Remote Portlets (WSRP)
specification created by the Organization for the Advancement of Structured Information
Standards (OASIS), of which Microsoft is a member, to enable developers to build portlets that
interact with other portal sites, regardless of the business system they use. A reason for this is
that Microsoft does not provide a solution for building portlets. Microsoft SharePoint Server is a
useful portal solution for those who want to create, manage, and share content within Microsoft
platforms. But the solution is not advisable for those with more or open requirements. SharePoint
does, however, have some good collaboration, document, workflow, version-control and
personalization features and it integrates well with all Microsoft products.
The only database the product supports is MS SQL Server, which makes this solution quite
inflexible. The same applies to the programming languages supported by the solution, which are
only the .Net languages as C# and VB.


3.3.6       Open Source Providers

The open source providers are addressed here for the sake of completeness. For SHB these
solutions are not taken into consideration. Nevertheless exist in the Open Source environment a
couple of ambitious providers of portal initiatives. For example Liferay,7 which is a Java/J2EE
Portal system that provides personalization (like Yahoo), web based email, document libraries,
CMS, message boards and shopping functionalities (e-commerce). The product is built solely on
open source technologies like Struts8, Hibernate9, Lucene10, Velocity11 and Ant12 and runs on
free J2EE servers Tomcat or JBoss. The framework cooperates with different commercial and
non-commercial databases by saving the data temporarily in a meta-data layer.
Jetspeed13 is an Open Source implementation of an Enterprise Information Portal, using Java and
XML and is part of the Apache Jakarta project. The developers of the solutions are participating
at the JSR 168 specification which makes this solution an equivalent portal provider to the
commercial ones. The aim of the project is to make a range of tools available to the developers
with which they can quickly implement a portal application.
6
  http://www.microsoft.com/sharepoint/
7
  http://sourceforge.net/projects/lPortal or http://www.liferay.com
8
  http://struts.apache.org/
9
  http://www.hibernate.org/
10
   http://lucene.apache.org/java/docs/index.html
11
   http://jakarta.apache.org/velocity/
12
   http://ant.apache.org/
13
   http://Portals.apache.org/jetspeed-1/




                                                                                        Page 17 of 66
For the .net developers, there is also a solution available. The Dotnetnuke14 framework is built
on the Microsoft ASP.NET platform and the most recent release is 3.0.13. The solution offers
functionality as CMS, Site hosting, search facilities, security, and membership options. As a
database it supports MS SQL, Sybase, Oracle and some other vendors.




14
     http://www.dotnetnuke.com




                                                                                      Page 18 of 66
  3.3.7            Summary of Providers

  Table 1 shows a tabulation of the above introduced vendors. As mentioned above the open
  source solutions are out of question for the implementation of FIP therefore they are not listed
  here.

Company                            Peoplesoft          SAP                 Bea               IBM               Microsoft
Solution                           Enterprise Portal   Enterprise Portal   Weblogic Portal   Websphere         Sharpoint Server
Version                                                6.0                 8.1               v5                5.2
Technical environment
Databases                          DB2, Oracle,        Oracle, MS SQL,     Oracle,DB2, MS    DB2, Informix,    MS SQL
                                   Informix, Sybase,   Max DB              SQL, Pointbase,   MS SQL, Oracle,
                                   Ms SQL                                  Sybase            Sybase
Application Server                 Weblogic,           SAP WAS 6.4         Weblogic          Websphere         Windows Server
                                   Websphere                                                                   2003
J2EE
.Net                                                   .Net View
DCOM
CORBA                                                  possible
Highlights                                                                 WSRP15, Struts    Struts            Integration with
                                                                                                               MS Office
                                                                                                               products
General functionality
Workflow component
Search functionality
Portlet standard JSR 168
Business process Mgmt.
EAI functionality
Own CMS
Interface to CMS
Connectors to ERP
JCA
Precast Portlets
Development environment
Portlet builder
Application builder
Integration third party products
Security
Authentication                                                                               over Tivoli
Authorization
Single Sign-on
Digital certificates (X.509)
User administration
Role model
Personalization
User driven content creation

  Table 1: Overview of the features of the different vendors [IX04].

  15
       WSRP - http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsrp




                                                                                                                      Page 19 of 66
3.4      Discussion

All of the above mentioned portal vendors deliver value in a different way. For this reason, no
valuation which is the best is made here. In the end it is important that the chosen solution fits
with the existing application portfolio and architecture of a company. The portal solution must fit
in such a way that its scale of benefits integrates and expands the existing applications as is
required. It is also important to bear in mind that the solution should not offer more functionality
than required. As can be seen later in chapter five only two of the five solutions come into
question for the implementation of FIP. But for the sake of completeness all five solutions are
included in the following comparison.
The differences between portal vendors result from the market area they operate in. IBM for
example, which is a server vendor, provides a solution which supports its underlining server
technologies [NUC03]. The same can be said for Microsoft’s SharePoint solution with its IIS
Server. BEA builds its solution on top of its Weblogic application server, while SAP uses its
SAP WAS technology. All the vendors provide solutions which are mainly compatible to the
server technologies they offer. An analog observation can be made by the additional components
they provide and support for their portal solutions. For example, the additional components
offered by Peoplesoft are all of its own product range. The circumstance described above shows
that a decision which portal should be chosen is highly influenced by the existing technology
scenery of a company.
Another criterion is the ROI of a portal investment. It is important that the solution provides the
expected functionality to generate the surplus value. One of the reason portals are used is
because they offer a single point of entry at which users can find information faster and have
tools to accomplish their work in an efficient manner. As a result employee cost savings can be
made. All five vendors offer solutions to generate this surplus value but in the end it depends on
how the portals are deployed and used in the existing framework of a company. It is important
that the chosen solution can increase employee productivity and subsequently reduce head count
costs.
Furthermore, a portal solution should support the Portlet Standard JSR 168 to enable
interoperability between portlets and portals. In an environment in which more then one portal
technology is deployed portlets can be used in all portal environments and as a result
development costs can be reduced. Also, for possible future technology swap, a solution which
supports the JSR 168 standard can be more easily migrated on a technology which also supports
the JSR 168 standard. Except Microsoft’s Share Point Portal all other solutions support the
portlet Standard. This is due to the fact that Microsoft’s solution is not built on the J2EE
architecture. When making a decision, this point has to be taken into account but the support of
the JSR 168 can be seen as the only consideration.
Another point which influences the decision making is the security and user administration
offered by the solution. All portal solutions bring along implemented security features such as
authentication and authorization. A difference between the vendors can be found by the support
of digital certifications. Peoplesoft with its Enterprise Portal and IBM with its Websphere portal
do not offer support for digital certifications. Further, all vendors have implemented integrated
user management. The influence of security and user management on the decision can also be
ignored.
In summary, the ultimate portal solution does not exist. The portal market is quite young and
much evolution is needed in this market. The existing portals are reasonable solutions, but have
shortcomings associated with new technology. The decision for a portal should be based on the
existing technology scenery, the expected ROI and the possibility of future technology swaps.



                                                                                          Page 20 of 66
4.        Analysis


Briand, Differding, and Rombach [BRI96] said that “Despite significant progress in the last 15
years, implementing a successful measurement program for software development is still a
challenging undertaking.” Software measurement is made whit the objective to improve and
control the productivity and quality of complex software development. More and more
companies start to analyse their software with intent to improve productivity and to have better
control of the costs of software development. On the market several commercial reverse
engineering and application mining tools can be found. One of them is the COTS software
CAST.
In this part of the thesis the CAST Software16 (hereafter called CAST) is introduced. First of all
the company CAST and its product are introduced to the reader. Next the five different metrics
which are calculated by CAST and that are used for the analysis are named and discussed
cursorily. Details of the calculation can be found in the appendix. After having seen how the
different metrics are calculated, the results from the analysis of FIP 2.0 are discussed. With these
results in mind a first recommendation is made regarding which parts of the existing FIP 2.0
suitable to be reused.


4.1       CAST Software

CAST is an application mining tool for modern programming languages and makes use of source
code analysis to deliver technical information about applications. CAST Analyzers extract the
technical information from the source code and stores it in a relational database, the CAST
Knowledge Base. The knowledge base can then be accessed through several different user
interfaces such as dashboards, interactive graphical view tools, HTML reporting tools, analytical
tools and file export tools. The analyzers list code elements and determine how they are
structured. CAST Enlighten is a sub solution which gathers, organizes and shares technical
information about software applications. CAST also generates graphical views displaying all the
objects making up an application and their interdependencies. Another functionality provided by
CAST is to generate snapshots of analyses and so allow comparing snapshots to each other
which are made during development on planed intervals. Based on this information the effort
during development can be measured and analyzed using time series and trend discovery is
greatly facilitated.




16
 http://www.castsoftware.com




                                                                                          Page 21 of 66
4.1.1      CAST Server Manager

Figure 2 shows an print screen of CAST Server Manager which is used for managing the
different servers, data warehouses and the licensing. After Server Manager is launched new
connections are added or existing ones edited. Also, the user management is done in the Server
Manager.




Figure 2: Print screen of CAST Server Manager which is used for managing the different repositories.



4.1.2      CAST Analysis Manager

After the connections to database are managed the analysis can be set up and run. For this task
CAST Analysis Manager is used. As can be seen in Figure 3 new projects can be created with
the Analysis Manager. A project represents one or multiple applications. For each project
different analyzers which represent an application are added. An analyzer must be configured
through its settings and then the analysis can be performed. After the analysis has finished the
metrics must be calculated and the repository can be created. In the end, the CAST System
Views must be updated. During this step the information gathered during the analysis and the
calculated metrics are written to the repository from where the information can be accessed.




Figure 3: Sample project in the Analysis.



Here a list of what programming languages and databases that can be analyzed with CAST:

Languages:
- Java
- JSP
- Microsoft Visual Basic
- ASP
- C#
- Oracle Forms
- Powerbuilder
- Delphi




                                                                                                       Page 22 of 66
-   C++
-   C
-   HTML
-   VBscript
-   JavaScript
-   ColdFusion
-   PHP
-   COBOL/CICS/JCL.

 Databases:
- Oracle
- Sybase
- Microsoft SQL Server
- IBM DB2.


4.1.3      CAST Enlighten

With CAST Enlighten the technical structure of an application can be visualized in a graphical
display. As shown in Figure 4 objects can be placed by drag & drop and impact analyses can be
run. CAST enlighten is a tool which helps new developers to understand the source code of an
application but can also be used for documentation reasons. The source of an application can be
browsed intuitively without diving into endless code listings or using text search tools.




Figure 4: Print screen of CAST Enlighten. On the left side different objects are listed. Whit drag and drop these objects can be
drawn to the right side. By doing this the dependences to other objects are shown.




4.1.4      CAST APM Suite

CAST APM Suite is a solution built for managers. Through an internet browser key indicators of
one or more applications are monitored. As shown in Figure 5 calculated metrics are presented in
a clearly arranged manner. CAST APM suite can be configured to benchmark applications and



                                                                                                                   Page 23 of 66
teams when for example the development is outsourced. There is also the possibility to calculate
and observe the cost of a development project.




Figure 5: Cost control screen out of CAST APM Suite.




                                                                                      Page 24 of 66
4.2           Metrics

In this part of the thesis the metrics integrated in CAST Application Management Platform
(AMP) are described superficially. In the appendix can be found a detailed description how the
five indexes are calculated.


4.2.1         Five High-Level Indexes

APM metrics are arranged into five categories and fall under the umbrella of five high-level
indexes.
The purpose of these five indexes is an easy and fully functional way to assess, compare and
monitor over-time maintainability at the application level and the application portfolio level.

The five indexes are namely:

       •    Functional Size Index - Measures the functionalities offer to the end user independent of
            the technical implementation based on two standard measurement methods IFPUG17
            Function Points and backfiring techniques.

       •    Technical Complexity Index - Measures how difficult it is to understand, modify and
            test the application based on standard metrics and technologically specific metrics.

       •    Artefact Granularity Index - Measures complexity introduced by the size of each
            programming element (each element is rated and the distribution of low to very large size
            is measured by the index).

       •    Artefact Coupling Index - Measures the difficulty to change an application due the
            dependencies between programming elements (each element's coupling is rated and the
            distribution of low to very high coupling is measured by the index).

       •    Standard Violation Index - Measures architectural and coding standard rules
            enforcement (Architecture, Performance, Code Documentation, Naming Conventions,
            Best Practices).

All the indexes’ values range from 0 to 10 for an easier comparison over-time and for application
benchmarking.


4.2.2         Functional Size Index

Functional Size Index is based on ‘Function Points’ [ALB83] metrics. The Function Points
metric measures the functionality of software. This is done in the following steps:
First the elementary functionality is counted. In a second step the identifiable processes from a
user perspective are determined. Then they are weighted with a complexity factor and summed
up to get a final number.

17
     http://www.ifpug.org/




                                                                                            Page 25 of 66
Because the selection of the processes is based on the point of view of the users, the result is
independent from the technology and the way how the solution is implemented. Details like
architecture, programming style or programming language for example are ignored by this
measure.


4.2.3      Technical Complexity Index

Technical Complexity Index is a weighted sum of four sub indexes. The weight is distributed in
the following way among the four sub indexes


Technical Complexity Index = CCI × 0.64 + 4GLCI × 0.12 + OOCI × 0.12 + SQLCI × 0.12


Cyclomatic Complexity Index = CCI
4GL Complexity Index = 4GLCI
OO Complexity Index = OOCI
SQL Complexity Index = SQLCI
Formula 1 shows the calculation of the Technical Complexity Index.




4.2.3.1     Cyclomatic Complexity

Introduced by Thomas McCabe [Cabe76] , Cyclomatic Complexity measures the number of
linearly independent paths through a program module. This measure provides a single ordinal
number that can be compared and analysed. In CAST the Cyclomatic Complexity Index is the
weighted sum of 4 sub metrics divided by the sum of the 4 sub metrics themselves. The
Cyclomatic Complexity Index is then calculated as follows:


                                             LCA × 1 + MCA × 5 + HCA × 8 + VVHCA × 10
Cyclomatic Complexity Index =
                                                  (LCA + MCA + HCA + VVHCA)

Low Complexity Artefacts = LCA
Moderate Complexity Artefacts = MCA
H igh Complexity Artefacts = HCA
Very High Complexity Artefacts = VHCA
Formual 2 shows the calculation of the Cyclomatic Complexity Index.




                                                                                        Page 26 of 66
4.2.3.2     4GL Complexity Index

4GL Complexity metrics evaluate the complexity of a user interface based on 4GL Technologies
(PowerBuilder, Visual Basic, .NET, Delphi, Forms). Metrics of this category are related to user
interface forms or windows. Because FIP is a pure web application, a short overview of what is
contained in the 4GL Complexity Index is given.
4GL Complexity Index is the weighted sum of 4 sub metrics:


                                 L4GL * 1 + M4GL * 5 + H4GL * 8 + VH4GL *10
4GL Complexity Index =
                                    (L4GL + M4GL + H4GL + VH4GL)

Low 4GL Complexity Forms = L4GL
Moderate 4GL Complexity Forms = M4GL
High 4GL Complexity Forms = H4GL
Very High 4GL Complexity Forms = VH4GL
Formual 3 shows the calculation of the 4GL Complexity Index.




4.2.3.3     Object-Oriented Complexity Index

Object-Oriented Complexity metrics (hereafter called OO Complexity Index) evaluates the
complexity of an object oriented design of an application. The sub metrics of this category are
related to the classes of an object oriented design.

The OO Complexity Index is also calculated as the weighted sum of four sub metrics divided by
their sum:


                                 LOO * 1 + MOO * 5 + HOO * 8 + VHOO *10
OO Complexity Index =
                                    (LOO + MOO + HOO + VHOO)

Low OO Complexity Classes = LOO
Moderate OO Complexity Classes = MOO
High OO Complexity Classes = HOO
Very High OO Complexity Classes = VHOO
Formual 4 shows the calculation of the OO Complexity Index.




                                                                                     Page 27 of 66
4.2.3.4     SQL Complexity Index

The SQL Complexity Metrics Index evaluates the complexity of both the SQL inside the
database and the embedded SQL. The SQL inside the database is for example in stored
procedures, while embedded SQL is directly contained in the source of an application. The SQL
Complexity Index does not take into account dynamic SQL which is generated during the
execution of an application.

As with the metrics above, the SQL Complexity Index is calculated as the weighted sum of four
sub metrics divided by their sum. The calculation is as follows:


                                  LSQL * 1 + MSQL * 5 + HSQL * 8 + VHSQL *10
SQL Complexity Index =
                                     / (LSQL + MSQL + HSQL + VHSQL

Low SQL Complexity Artefacts = LSQL
Moderate SQL Complexity Artefacts = MSQL
High SQL Complexity Artefacts = HSQL
Very High SQL Complexity Artefacts = VHSQL
Formual 5 shows the calculation of the SQL Complexity Index.




4.2.4      Artefact Granularity Index

This index measures the distribution of an artefact’s size in an application. The growth of
Artefact Granularity in an application is usually a sign of growing complexity. Growing
complexity of an application has a negative impact on its maintainability.
Artefact Granularity Index is the weighted sum of four sub metrics:


                                      SSA * 1 + ASA * 5 + LSA * 8 + VLSA *10
Artefact Granularity Index =
                                            LSA + ASA + LSA + VLSA

Small Size Artefacts = SSA
Average Size Artefacts = ASA
Large Size Artefacts = LSA
Very Large Size Artefacts = VLSA
Formual 6 shows the calculation of the Artefact Granularity Index




                                                                                    Page 28 of 66
4.2.5      Artefact Coupling Index

The Artefact Coupling Index determines the difficulty to change an application due to the
interdependencies between artefacts.
The Artefact Coupling Index is calculated as the weighted sum of four sub metrics:


                                   LCA * 1 + MCA * 5 + HCA * 8 + VLCA *10
Artefact Coupling Index =
                                      (LCA + MCA + HCA + VLCA )

Low Coupling Artefacts = LCA
Moderate Coupling Artefacts = MCA
High Coupling Artefacts = HCA
Very Large Coupling Artefacts = VLCA
Formual 7 shows the calculation of the Artefact Coupling Index




4.2.6      Standard Violation Index

Standard Violation detects and quantifies coding rule exceptions to architecture, best practices,
performance, documentation and naming convention standards. Standard Violation Index and the
attached metrics are derived from the CAST Enforce checks and are based on Compliance Ratio
Standard.




                                                                                       Page 29 of 66
4.3        Analysis of FIP 2.0

In this part of the thesis the snapshot of FIP 2.0 computed by CAST is analysed. The snapshot
was taken mid March 2005. Since then no major changes have been made to the application. The
discussion of the results is in the same order as in the introduction of the metrics above. In
section 4.3.1 a global overview of the inventory information of FIP is given. In section 4.3.3 to
section 4.3.7 the results of the five metrics are discussed and interpreted. Finally, the results are
summarized and a conclusion of the analysis is presented.


4.3.1      Inventory

Table 2 shows an overview of the inventory of FIP 2.0. With 45’541 NCSS FIP 2.0 is a middle
sized application. From 45’541 lines of code 5’031 lines belong to the java files, 1’733 lines are
in the database layer and the remaining 26’947 lines are contained in the JSP files of the
application.




Table 2: Overview of the inventory of FIP 2.0. Snapshot taken mid March 2005.




The fact that more than half of the NCSS is located in the JSP files and more than 80% of the
files are JSP files reflects that FIP implements the business logic in the JSP files of the
application. This allows the assumption that CAST does not consider the way FIP 2.0 is
implemented.
The reason for this high amount of code lines in the web part is because of the way CAST counts
the lines of code. As shown earlier, the queries of FIP 2.0 are contained in the JSP files using the
QueryTag. Similarly, other application logic is included in the JSP files. CAST counts all the
code contained in these “logic” tags as normal JSP lines of code. As a result, the number of
counted code lines deviates from the real number of code lines used for presentation purposes
only. The low number of SQL server NCSSs underlines the fact that CAST counts the business
logic as web part and not as SQL server part. Another reason for the low number of SQL code
lines could be due to the fact that FIP only reads data and so insert, update, delete statements are
not implemented, which keeps the number of SQL code lines at a low level. As can be seen later
when discussing the SQL Complexity it is shown that CAST does not count the queries
contained in the JSP files.




                                                                                           Page 30 of 66
4.3.2       Indexes Overview

Table 3 gives an overview of the five main metrics calculated by CAST. As mentioned above,
CAST rates the indexes from 1 to 10. From this point of view the calculated indexes of the
application do not show remarkable results. Noticeable is the low Functional Size Index of 0.01.
The highest index reached by the Standard Violation Index.




Table 3: Overview of the five high level indexes.




In Figure 6 the indexes are represented on a radio chart. No major derivations can be seen here
except the ones mentioned above.




Figure 6: Five high level indexes pictured in a radar chart.




                                                                                      Page 31 of 66
4.3.3      Functional Size Index

As can be seen in Table 4 the FSI of FG 2.0 is 0.01. The FSI is calculated with the number of
BFP counted in the application. With 860 BFP, the application is below the boundary of 1000
BFP and as a result the FSI of the application is equal to 0.01. For the present application it
makes sense to tune the calculation of the index. This is because a FSI of 0.01 does not predicate
much about the application, the way it is implemented, or how efficiently the developers worked.
In addition, an index of 0.01 can not be compared meaningfully with the indexes stored in the
database from past projects.




Table 4: Sub metrics of the Functional Size Index.




A way to tune CAST’s calculation is to choose different boundaries for the classification of the
different BFP. When changing the boundaries the calculation of the FSI must also be changed.
For example, the boundaries and formula can be set as follows:


-   When BFP > 100 and < 10000 :
      FSI= (LOG ((Backfired Function Points ) / 100)) * 5
-   When BFP < 500:
      FSI = 0.01
-   When BFP > 10000:
      FSI = 10


With these boundaries the FSI results in 4.67. Based on the new calculated FSI more meaningful
predictions and interpretations about the application can be made.
The drawback of changing the calculation of the FSI is that it can not be compared with FSIs of
other applications because the gradient of the graph resulting by the function does not remain the
same. Also, former analyses of FIP can not be compared.
Another outstanding result is the constitution of the AIE. As can be seen in the appendix, the
AIE is the sum of the UDF and UTF. The results of the analysis show that the AIE only consists
of UDF. This indicates that the application consists of tables which are never accessed directly or
indirectly by a user form. The reason for this is that CAST does not interpret the queries included
in the query-tag in a correct sense, as was already mentioned earlier in this chapter.




                                                                                         Page 32 of 66
4.3.4      Technical Complexity

The Table 5 shows an overview of the four sub metrics with which the Technical Complexity
Index is calculated. The weighting of the sub metrics can be found in the Appendix and is not
addressed here. As can be seen, the 4GL Complexity index is not applicable in the analysis. This
is because FIP 2.0 does not use 4GL technologies for its implementation. Another index which
stands out is the OO Complexity.

In the next three sub sections the sub indexes which are relevant for the analysis of FIP are
discussed in detail.




Table 5: Four sub metrics of the Technical Complexity Index.




4.3.4.1     Cyclomatic Complexity

The Cyclomatic Complexity measures the number of linear paths through a program module. In
CAST the Cyclomatic Complexity is made up of a weighted sum of four sub metrics. An
outstanding result obtained by the analysis is that almost 90% of the artefacts are of low
complexity and indicates that FIP 2.0 is not a high complex application. Just one percent of the
artefacts are very high complex. To the very high complexy category belong all files which have
a Cyclomatic Complexity from above 30. In FIP 2.0 functionalities like charting, search
functionality and PDF-files creators possess a Cyclomatic Complexity of this size.




Table 6: Indicators of the Cyclomatic Complexity.


The Cyclomatic Complexity is an indicator of the soundness and confidence of an application.
[EDM97] FIP 2.0, with its low Cyclomatic Complexity is an understandable application and is
amenable for modifications at lower risk and so is convenient for a reengineering.




                                                                                      Page 33 of 66
4.3.4.2     Object-Oriented Complexity Index

The OO Complexity Index measures the complexity of an Object-Oriented design of an
application. The OO Complexity calculated by CAST consists of a bunch of different OO
metrics. First, the numbers of class files are counted. Based on this number the classes are
divided in different complexity categories. In FIP only low and moderate OO Complexity classes
exist, which makes the application capable for reuse and further enhancements. Moreover, the
average numbers of 8.31 methods per class and 2.35 class fields are in an acceptable range. This
can be underlined by the statement that a method is a property of a class and the complexity of a
class is determined by the cardinality of its set of properties. Based on this the number of
methods within a class indicates how much effort is required to maintain an object [SHV91].
Referring to FIP this means that the application is suitable for reuse and at the same time there is
no general need for refactoring.




Table 7: Object-Oriented Complexity




As can be seen in Table 7 are two classes from a high Cyclomatic Complexity. This is the
BaseBean class which offers a standard interface for the property access to extending Java Beans
the ContentTag class which is used to produce PDF documents. The BaseBean class is also
indicated as a high length class. With its 803 lines of code (documentation included) and its 24
methods the BaseBean class is rather to long and because of this is a candidate for a refactoring.


4.3.4.3     SQL Complexity Index

The SQL Complexity of 2.13 does not correspond with the real SQL complexity of FIP. This can
be substantiated by the number of embedded SQL artefacts and artefacts a with Group By
Statement counted by CAST. Both of them are reported as zero which does not correspond with




                                                                                          Page 34 of 66
the real number of embedded SQL Artefacts and Group By statements used in the application.
As already seen, CAST does not count the queries contained in the JSP files. Based on this, the
calculated SQL complexity by CAST is unreliable and useless for further analysis. The only
information which can be said to correspond with the reality are the database SQL elements such
as the number of tables, triggers and views. Essentially uses FIP complex queries which should
result in a high SQL complexity.
As can be seen in Table 8, no views are used in FIP which means that the data is directly
accessed through its tables. Based on the fact that FIP only reads data and does not execute
updates, delete, or insert statements, the data could be provided in views which would avoid the
direct access to tables. It further indicates that update statements are used by the application.
These update statements are contained in the stored procedures which are used for data
maintenance only and are not in a direct relationship with the application. As mentioned in
chapter two FIP is a view-only application that only reads data.




Table 8: Indicators of the SQL Complexity Index.




                                                                                       Page 35 of 66
4.3.5      Artefact Granularity Index

The Artefact Granularity shows the relative size of artefacts and measures the distribution of
them. The size of an artefact is based on the number of code lines. Here, a relevant metric is the
Number of Commented Lines. Just 4.8 % of the lines of code are commented, which indicates
that the source code is not documented enough. This can also be seen by exploring the code
manually. Only the most important classes (e.g. BaseBean) are documented in detail.




Table 9: Artifact Granularity index and the number of artefacts.




4.3.6      Artefact Coupling Index

The Artefact Coupling Index analyses the level of interdependencies between artefacts and
determines the difficulty to change an application due the interdependencies. FIP has an Artefact
Coupling Index of 2.17 which indicates changing the application is possible without
complications. As shown in Table 10, 81 % of the artefacts have less then four callers. This
shows that most of the artefacts used by the application can be adopted in a new solution.
Furthermore, the average number of links per artefact is, at 11.54, a low number which also
indicates a minimal risk to break the application by changing it.




Table 10: Detailed information of the Artifact Coupling Index.




                                                                                        Page 36 of 66
4.3.7      Standard Violation Index

The Standard Violation Index, presented in Table 11, provides the analysis of application related
standards or conventions for architecture, best practices, performance, documentation and
naming convention. This index is important for encouraging high quality and maintainable
software.
The T-SQL Architecture Ratio counts if tables are accessed directly from client-side SQL
queries and not through stored procedures or triggers. Because in FIP 2.0 all the queries are
contained in the JSP files and no stored procedures are used, the T-SQL Architecture
Compliance Ratio results as 34 %. On the other hand, the Java Architecture Ratio is high
because a clear inheritance down the package path is used in FIP 2.0. Three percent is deducted
because four packages contain less then three classes which results in a Java Architecture Ratio
of 97 %.
The Best Practise Compliance Ratio analyses all three layers of the application. In the JSP layer
it checks if the JSP pages use a style sheet. Due to the fact that FIP also has query only JSP files
and not all of the files are used to display content the ratio of only 7% is misleading and falsifies
the Best Practise Ratio. Another criterion in the JSP layer is that each JSP page must use an error
page. Also here the result of 0% is misleading because an error page is used by FIP. Based on
these two examples it can be said that the Best Practise Compliance Ratio for the JSP part does
not fit with the way FIP is implemented and therefore results in non-decisive data.




Table 11: Five conventions on which the Standard Violation Index results.




As mentioned in the introduction of the thesis, FIP is known as high performance application
which can handle a large number of requests. This fact is supported by the Performance



                                                                                           Page 37 of 66
Compliance Ratio calculated by CAST. Apart from the T-SQL performance the system can be
said to be high performance as can be seen in Figure 7.




Figure 7: Radar chart of the Standard Violation Index.




As already mentioned, the documentation of the source code is restricted to a minimum. Only the
most and central classes are documented sufficiently. Almost none of the JSP files are
documented and none of the Java files are documented with Javadoc comments.
Finally, the Naming Convention Compliance Ratio is with its 89 % acceptable but has potential
to advance. The Java part achieves a Naming Convention of 100 % which indicates that no
offenses against standards are made. On the SQL side the results are less positive. The ratio is
dragged down because CAST assumes that names of stored procedures begin with "sp_", names
of triggers start with [I,U,D] and that views and table names do not have more than 12 characters
or contain characters other than [a-Z,0-9,_]. In FIP, all table names use a “_” in it. So do the
stored procedures, which do not really belong to the application, and do not begin with the token
“sp_”. Either an application is implemented in a way that correspond the way CAST assumes it
or the Naming Convention Compliance Ratio is examined as poorly.


4.4        Discussion

The analysis of the 45’541 FIP NCSS with CAST showed that parts of the application are
convenient for a reengineering. This statement is based on the fact that 90% of the artefacts of
FIP are from low Cyclomatic Complexity. Another point which underlines this statement is that
only low and moderate OO Complexity classes are used. Further shows the Artefact Coupling
Index only interdependencies between artefacts at a low level, which is also an indicator of low
reengineering risk. As seen the Standard Violation Index of FIP can be rated as “good”. This can
be determined by looking at the Naming Convention Compliance Ratio which attests that no
offenses against standards are made.
On the other hand, the analysis confirms the lack of source code documentation in FIP.
Furthermore, the Coupling Artefact Index shows that some components are called from up to




                                                                                       Page 38 of 66
124 objects. These components are risky for a reengineering because they are called by this
amount of objects. The fact that one component is called from many objects reflects that the
existing application has grown historically which was already mentioned in the outlook on FIP
3.0.
Besides the above mentioned results, CAST also delivers some results which can not be properly
interpreted. This is because CAST assumes a standard implementation of an application which
leads to these falsified results. For the analysis, CAST should offer the possibility to state the
architecture of an application in which can be declared what architecture the application is using.
As already mentioned above, application logic is contained in the JSP files of FIP. CAST counts
all the code contained in these tags as normal JSP lines of code. As a result, some of the indexes
differ from the reality. For example, the resulting SQL Complexity of 2.13 does not correspond
with the real SQL Complexity of FIP because the queries contained in the JSP files were not
counted. Another drawback of CAST can be seen by the calculation of the Functional Size
Index. CAST determines an FSI of 0.01, which does not predicate much about the application.
CAST should offer the possibility of tuning the calculation of this Index so that the results can be
used for valuable predictions and interpretations. Furthermore, CAST requires that each JSP file
should have an error page implemented. In FIP not all JSP files are used for displaying purpose
and therefore do not have to implement an error page. Because of this circumstance the Best
Practise Compliance Ratio predicts falsified results for FIP.
Recapitulating, it can be said that CAST can be used to get an overview of the state of an
application but for a final decision on if an application is capable for reengineering further
information is needed. The results calculated by CAST must be examined one by one and
checked for accuracy. This is because CAST is a complex tool, even though it is easy to use.
Disregarding to adjust just one of the settings in the analysis leads immediately to erroneous
results. This indicates that, for effective usage of CAST, training and experience is needed.




                                                                                          Page 39 of 66
5.       Prototype of FIP 3.0


5.1      Introduction

This chapter addresses the new implementation of FIP 3.0. As shown in chapter two, expanding
the existing application is not a viable option because of financial and time reasons. From there
the choice requires selecting a new set of technologies. For the implementation of FIP, four
solutions are under consideration. From the five portal providers introduced in chapter three,
only the BEA WebLogic Portal and the IBM Websphere Portal come in the question for
implementing the new FIP. This is due to the fact that these two solutions are already in use by
other projects and from there establish a standard. In this chapter the different solutions are
introduced and discussed. The next step is then to make a decision upon which technology FIP
3.0 is to be built. For this decision the results acquired by evaluating the portal vendors are taken
into account. After coming to a decision on a possible architecture, a short overview how the
new system works and what its architecture looks like is provided. Finally the parts which are
suitable for reuse are identified and shown to test the feasibility and possible success of the new
technology.


5.2      The Four Options

As mentioned above four solutions are under consideration for the implementation of the new
FIP 3.0. The first possibility is to integrate FIP in the BEA Weblogic Portal which is already
used by other web projects within SHB AM Europe and US. The second alternative is to use the
CE framework which is built on top of IBM’s Websphere Portal solution and is used for the SHB
Courses project within SHB. The third possibility is to build the new FIP with the Websphere
Portal as it is provided by IBM without using the CE framework. The last possibility is to build
FIP without a portal solution. Next, the four solutions are explained in more detail.


5.2.1    Alternative I: BEA Weblogic Portal

PORT is a portal solution which is implemented on the BEA Weblogic Portal server. The
framework is being developed by the US AM Team and also deployed in Switzerland for several
applications. The main goal of the project is to provide a portal solution which is a single entry
point for web applications used within AM US and EMEA. The solution uses the BEA Weblogic
Portal and an Oracle instance as a database Server. The architecture of the solution is similar to
the one used by FIP. The only difference is the data access layer which is implemented in stored
procedures instead of using the QueryTag.
Integrating the new FIP on the PORT platform would include all the benefits of using a Portal
solution. The appearance of the different applications would be standardized. Also, the Portal is
already used by other projects and could be argued to be rather robust. Another advantage is the
underlying database technology used by the platform.
On other hand, the developers of FIP are not familiar with the BEA Weblogic technology which
would cost time for training. Another disadvantage is that the main client base of FIP is from the
divisions of BB which are using IBM Websphere Portal solution for their applications and not



                                                                                           Page 40 of 66
the PORT portal solution. This means that the main client base has to use two solutions on
different platforms to accomplish their work. Further is the implementation of the solution highly
complex which leads to problems implementing the new system onto PORT.


5.2.2   Alternative II: Integration in CE Courses

The CE framework is a solution provided by the division BB of SHB and provides common
portal functionality which is used by the workbench applications. The idea behind CE is to
provide a standardized and integrated solution for the most important web applications
(workbenches) within SHB. The CE portal concept deals with all issues that are related to the
way the user experiences a portal. This covers aspects such as navigation, layout and design,
internationalization and accessibility, but also more advanced usability concepts like interaction
patterns and the architecture of a workbench from a user’s point of view.
The development of the CE framework is still in progress and the first official version is
available to the workbench applications at the beginning of the year 2006. At the moment the
only application which is allowed to build on the CE framework is the reengineering project of
SHB Courses. This project has been chosen because it is the application with the most
requirements and the highest user load. When the CE framework can handle this requirements
and this load, it is also applicable for other workbench applications which are planned to be
moved to the CE platform. Because FIP is a related application to CE Courses, there is also the
possibility of integrating the new version on the CE framework before the final version is
released.
CE Courses also uses SHB Widgets. The SHB Widgets do not only implement the complex SHB
Style guide elements like table, group box but also implement the lower level html oriented tags
like CheckBox, and RadioButton. The advantage of using widgets is that all applications would
have a uniform appearance to the user and the components would not have to be implemented
several times.
The requirements of the new FIP were partially originated from CE Courses. Building the new
FIP with the CE framework would provide an added value because the parts originated form CE
Courses are easy to migrate. Another benefit of building the new FIP on the CE framework is the
knowledge transfer from the CE Courses project. Furthermore, the two applications have a
uniform appearance to the user, which obeys the “One Company one Brand” guiding principle.
Another reason is that BB is the biggest customer of AM and FIP is mostly used from the same
internal users using Courses. Building the systems on the same framework would bring a lot of
usability benefits due the same look and feel to the user.
On the other hand, when integrating FIP in the CE framework AM would lose its own portal and
would be dependent on BB. This means that the implementation of FIP is influenced by the
regulations of BB which would make the project more complicated. Compromises would be
necessary because Courses, FIP and later all other workbenches would be shown in the same
portal and would therefore have to use the same navigation framework.
Another point which must be considered for the decision making is the progress of the
reengineering project Courses. The development of CE Courses is running into different
problems. One reason for these problems is that the development of the CE framework has not
been finished yet. Also, issues like session handling, bookmark-able URL’s and other problems
are challenging the reengineering project of Courses. In addition, the project is having problems
with the performance and configuration of the portal server. The reason for this problems is
because the immatureness of the Portal technology.



                                                                                        Page 41 of 66
5.2.3   Alternative III: IBM Websphere Portal (without CE)

Due the problems of the CE framework described above, a third alternative comes up. This third
possibility would be to build the new FIP on top of IBM Websphere Portal server without using
the CE framework and without integrating it in the CE Courses project. Clearly speaking this
means building FIP in the same way as Courses but as a separate application. The underlying
solution is Websphere Portal server as it comes out of the box. The migration on the CE
framework could be done in a later step when the framework is more stable and has been
approved.
With this solution the problems that have turned up with the CE framework would not be an
issue and the independence from BB could be kept. Also, developing on a framework which is
earliest available at the beginning of the year 2006 could be avoided. Another advantage is that
with a new solution the problems that turned up in the CE framework could be avoided at an
early stage.
On the other hand, the same unpleasant experiences encountered by the CE framework project
could turn up. Another drawback of not using the CE framework would be that development
time and configuration effort of the Websphere Portal server would be increased. Configuring
the Websphere Portal server does mean reinventing the wheel and in the end the probability that
the project would run into the same problems as the CE project is there. This is because some of
the problems which turned up in the CE project were adopted from the problems of the
Websphere Portal server. One of the problems of the Websphere Portal server is the URL
handling. IBM Websphere Portal allows mapping „User Friendly URLs“ to portal pages but not
to portlet views. The result of this is that users cannot set bookmarks, search engines can not
provide a URL to the found sites and links from external resources to the portal can not be
provided. Another problem turns up when using more than one application server for load
balancing. The session can get lost by a server swap which ends up in a loss of attributes used by
the session. As a result the user must log on again and the information about his session is lost.


5.2.4    Alternative IV: Pure Websphere Application

The last alternative would be to implement the new FIP on Websphere without using the portal
technology. This solution is similar to the existing implementation of FIP, using JSP and tag
libraries. The new implementation would use the classic MVC (Model-View-Controller) design
paradigm. Besides Java Scripts, Struts are used for the control logic of the application.
Furthermore, Struts-Tiles are used instead of the "include" feature provided by the JSP’s
specification to provide a full-featured, robust framework for assembling presentation pages
from component parts. The old tag-lib of FIP 2.0 would be replaced by a new tag-lib using some
of the old components. In addition, SHB Widgets would be used to get an adapted design to the
CE Courses solution. Some of the Widgets would have to be extended so they could fulfill the
requirements. As database is used an Oracle instance which is the standard technology of BB.
The business logic of the application would be implemented in PL/SQL and not in the JSP files.
The advantage of this solution is that it is based on well known and proven technology. Another
advantage is that this solution would demand moderate hardware requirements. Also, the
developers are confident with the technology and would only have to get training on Struts and
PL/SQL. It would also simplify the navigation issues for the different FIP versions (Internet,
Intranet) and no compromises would have to be made with BB. Also, the login issue could be
handled separately from the CE framework. Furthermore, the presentation of the application by



                                                                                        Page 42 of 66
using SHB Widgets would correspond to SHB standards. Not using the Portal technology does
mean it would avoid the problems with the emerging Portal technology.
A drawback of this solution is the fact that the new solution would not be integrated in the
strategic CE platform. A possibility is to link the new FIP solution into the CE Courses project.
The problem is that users would lose their session by switching between the two applications.


5.3      Decision

There are four alternatives of which Platform upon which the new FIP is to be built. A decision
like this is only slightly influenced by technological arguments, and a good deal more of the
decision is influenced by company policies. These policies dictate a standard which has to be
used to implement a solution. The standard for web applications at SHB BB is Websphere Portal
server. But because the CE project encountered problems and from there the expected ROI was
questionable, a global directive was issued to wait with the integration in the CE framework.
With this directive the boundaries for the reengineering project were set. The application has to
be built in a manner so that it can be integrated in the CE framework in a later step, but until then
acts as stand-alone application.
First, the BEA Weblogic Portal server is considered as a solution. This solution does not
correspond to the SHB BB standard, but because AM is not obligated to use this standard, it is an
alternative. The advantage of this solution is having a portal and thus a single entry point for all
applications within SHB AM. The drawback of this solution is that it differs from the solution
used by the main client base of FIP which is BB. This is the reason the CE framework is
considered as a second alternative. The CE framework is used by the main client base of FIP and
using this framework simultaneously means integrating FIP in to the standardized solution of
BB. But because of the global directive not to use the CE framework, this second alternative is
out of question. For this reason the third alternative, which is to build the solution on the
Websphere Portal server without using the CE framework came up. After some evaluation it
emerged that this solution does not bring the added value, which was expected by the portal
technology. The problems which turned up during the evaluation phase are from the same
derivation as the problems experienced by the CE framework project.
FIP needs a simple framework on which it can be implemented. Based on this consideration the
fourth alternative was considered. This alternative is to implement FIP 3.0 on Websphere,
without using the portal technology which keeps the solution flexible and simple. The integration
in the CE framework can be done in a later step.


5.4      Architecture of FIP 3.0

The new architecture is built in dependence to the PORT architecture. The major difference to
the implementation of PORT is not using BEA Weblogic server and avoiding the high
complexity in the data access layer. As mentioned when introducing the four alternatives, the
new implementation uses the classic MVC design paradigm. Oracle PL/SQL and Java Beans are
used for the model components, Struts represent the controller components and for the view
components JSP technology is used.




                                                                                           Page 43 of 66
Next, the three layers of the application are examined in more detail.

Model Layer:
The used database is an instance of Oracle. A recommendation of Oracle is to put all logic that
deals with data in PL/SQL. “There is no more natural language to interact with SQL data then
PL/SQL” [TOM05]. For FIP this means to put application logic in the application and data rules
and data processing in the database. Another consideration which has to be made is that FIP does
share data with other applications which are implemented with different technologies (e.g. C#
and VB). Implementing the data logic on top of the database assures data integrity for all
applications. By using Java Beans or datasets this integrity is lost. For example, this means that
an application caches its data in a Java Bean or dataset. A second application, which uses the
same data, is writing its content of the Java Bean or dataset back to the database. This leads to
data inconsistency and offends against the ACID principle [HR83]. On the other hand, the data
access could be implemented using a services layer from where the different applications
consume the needed data. However, using the service oriented approach for data access
constricts performance of the application. Furthermore, by using services the points of failures
are multiplied.
The new implementation moves the business logic from the JSP files into PL/SQL stored
procedures. The reason for this is to have better control over data access. Another advantage of
this approach is the debugging feature which it brings along.

Controller Layer:
Struts represent the controller components of FIP 3.0 and are focused on receiving requests from
the client. After receiving a request struts decide what business logic function is to be performed,
and then delegate responsibility for producing the next phase of the user interface to an
appropriate View component. Where struts do not meet the requirements of FIP, JavaScript is
used.

View Layer:
The View components are constructed using JSP’s technology. The old tag-lib of FIP 2.0 is
replaced by a new tag-lib reusing some of the old components. For an adapted design to SHB
standards SHB Widgets are used. Some of the Widgets have to be extended in order to fulfill the
requirements of FIP.




                                                                                          Page 44 of 66
Next a comparison of the new and old FIP solution is given:


         FIP 2.0 / Today                                      FIP 3.0 / Tomorrow



         Presentation JSP’s:                                            Presentation: (JSP)
         - HTML & JSP Tags                                              - UBS Widgets
                                                                        - Custom Widgets        V
                                                                        - Some HTML



         Business JSP’s:                                                US-Framework: (Java)
         - Tags & Java code       Java Script &          Struts as      - Logging
                                  controller.jsp
                                   as requests
                                                        controller of
                                                          requests      - Calling Stored Proc   C
                                    controller                          - Caching
                                                                        - ...


         Database JSP’s:                                                 Stored Procedures:
         - Tags & Java code
                                            Reuse potential
                                                                                                M




            FG Database                                                     FG Database
             (Sybase)                                                         (Oracle)




Figure 8: Overview of the architecture of the old solution in contrast to the new solution.




5.5           Reused Components

The input of which components of the existing application have reuse potential arose from the
experience of the maintainers and developers of the existing application. One part which is
migrated from the existing solution to the new implementation is the logic of the model layer.
In the model layer of the application, all the queries contained in the QueryTag are migrated
from Sybase to PL/SQL. Because the queries are contained in the QueryTags as dynamic SQL
and not in Sybase stored procedures, this task has to be done manually. Different tools are
available on the market which could be used for the automated migration from Sybase stored
procedures to Oracle PL/SQL.18 But, to use this tool the queries contained in the QueryTags first
must be stored in Sybase stored procedures. In a second step the created procedures can be
migrated to PL/SQL. Then their correctness must be validated and adapted in order to perform
the same functionality as before. Further, all table and attribute names must be changed because
the data model of the underlining database has changed. In the end this means almost the same
amount of work as when doing the migration manually.


18
     http://www.gold-software.com/SwisSQL-SybasetoOracleMigrationTool-review20014.htm




                                                                                                    Page 45 of 66
Code Fragment 3 to 6 shows source examples of the manual migration of statements from
Sybase T/SQL to Oracle PL/SQL. On the left side the query before the migration is shown and
the right side shows the query embedded in a stored procedure. The migration is made by copy
manually the query code fragment out of the JSP files to an Oracle package. In a second step the
queries are transformed from Sybase T/SQL to Oracle PL/SQL.


     Existing implementation:                                       New implementation:
1    <%@ taglib uri="/WEB-INF/basebean.tld" prefix="bbt" %>         PROCEDURE prc_perf_fund
     <%@ page import="java.util.Date" %>                                (
     <%--                                                                   dateFrom IN date default sysdate,
     Performance data                                                       dateTo IN date default sysdate,
     --%>                                                                   showBench IN varchar2,
     <jsp:useBean                                                           perfType IN varchar2 default '',
       id = "dateFrom"                                                      country IN varchar2 default 'CH',
       class = "com.ubs.fundgate.BaseBean"                                  refCurr IN varchar2 default 'CHF',
       scope = "request">                                                   chartCurr IN varchar2 default 'CHF',
     </jsp:useBean>                                                         udtfr IN varchar2,
     <bbt:set name="dateFrom" type="java.util.Date" op="strict"/>           udtto IN varchar2,
     <jsp:useBean                                                           pLst IN OUT sys_refcursor);
       id = "dateTo"                                                …
       class = "com.ubs.fundgate.BaseBean"
       scope = "request">
     </jsp:useBean>
     <bbt:set name="dateTo" type="java.util.Date" op="strict"/>
     …

Code Fragment 3: Instead of using useBean and set tag the parameters are passed as “IN” variables.




Code Fragment 3 shows how the parameters are passed before and after the migration. In the
existing solution parameters are passed by using the useBean tag and afterwards the set tag. The
new solution passes the values as IN parameters of a procedure. Further, are statements in Oracle
PL/SQL ended by a semicolon (;). For the migration this means first to replace all the parameters
which are using the useBean and set tag and pass them as IN variables.


2    </jsp:useBean>                                                 -- Check if strategy change happend and
     /* Check if strategy change happend and                        -- explanation / expl. date has to be show
      explanation / expl. date has to be show*/                     select max(hist_dt) + 1 into edisp
     select @edisp = dateadd(day, 1, max(dhist))                    from gfip.v_inst_hist
     from zfdb..vfstamm_hist_verb                                   where inst_id_in = fundId
     where nval_in = @nval                                          and hist_reason_cd = '3';
     and cgrund = '3'


Code Fragment 4: Assignment of the result of a query into a variable.


In Sybase T/SQL the result of a select statement can be assigned by using the equal sign (=). In
Oracle PL/SQL by using the into instruction. Further, as seen in Code Fragment 4 variables



                                                                                                                   Page 46 of 66
names do not begin with an at-sign (@).Therefore is the next step of the migration to replace all
variable names and also to replace the assignments by the into statement.


3        /* Get benchmark instrument, if possible*/                -- Get benchmark instrument, if possible
         if @selbn = 'y'                                           if selbn = 'y' then
          select @inst = ninst_zu                                   select inst_id_to into inst
           from zfdb..vfvergl                                        from gfip.v_inst_rel
           where czuart = 'B'                                        where inst_rel_cd = 'BMK'
               and ninst_von = (select min(ninst)                         and inst_id_from = finst;
           from zfdb..vfinstr                                      end if;
           where tquelc like convert(varchar, @nval))

Code Fragment 5: Compares the IF statement in Sybase T/SQL and Oracle PL/SQL.




Code Fragment 5 shows the difference of the IF statement in Sybase T/SQL and in Oracle
PL/SQL. In Oracle PL/SQL the IF statement uses the then and the end if statement.


4        /* Read user given date range or set                      -- Read user given date range or set
         it to the default range if empty*/                        -- it to the default range if empty
         if @udtfr = '' select @udtf = dateadd(year, -5, @today)   if udtfr = '' then
         else select @udtf = convert(datetime, @udtfr)             select add_months(today, -60) into udtf from dual; else select
                                                                   to_date(udtfr,'DD/MM/YYYY') into udtf from dual; end if;


         if @udtto = '' select @udtt = @today                      if udtto = '' then
         else select @udtt = convert(datetime, @udtto)             udtt := today;
                                                                   else
                                                                   select to_date(udtto,'DD/MM/YYYY') into udtt from dual; end if;

Code Fragment 6: Different query languages means also different function names.




Code Fragment 6 shows the differences in calling functions by the two query languages. The
provided functions mostly provide the same functionality but they are named differently. This
means that all the function names have to be replaced.

Above some examples of the migration from Sybase T/SQL to Oracle PL/SQL are shown.
Because there are many differences between T/SQL and PL/SQL not all of them can be
addressed here. A detailed tabulation of the difference between the two languages can be found
in the internet.19




19
     http://sybernet.sri.com/oracle/Translator.html




                                                                                                                         Page 47 of 66
6.       Tools


In this part of the thesis, the benefits, limitations and influence of using CAST are highlighted.
Further, it is shown how CAST is used during the project and what the surplus value is working
with the tool. In the following, we describe the experience made with CAST as reengineering
tool and show an example how it is used. In the second part we describe our experience applying
the object oriented reengineering patterns in an industrial project.


6.1      CAST valuation

One of the goals of this thesis was to examine the utility of CAST and its metrics in a
reengineering project. Summarized, the results of the analysis helped to understand the existing
application, but they did not deliver substantial input for the reengineering project. As mentioned
in chapter five, the input on which components of the existing application have reengineering
potential arose from the experience of the maintainers and developers of the existing application.
Based on the resulting low indexes (e.g. Cyclomatic Complexity, OO Complexity index,
Artefact Coupling Index and Standard Violation Index) the analysis of FIP showed that the
application is convenient for a reengineering. But because CAST did not come to grips with the
way FIP 2.0 is implemented no further conclusions about the reengineering potential of the
application can be made.
A limitation of CAST is that the application analyzed with CAST must be implemented in an
architecture that is CAST compatible. As seen by the analysis of FIP, CAST did not come to
terms with the dynamic SQL part implemented in the JSP files, even though the architecture of
FIP conforms to the standard of the year 2001, when FIP was implemented. Since 2004 the
Jakarta's standard has been an implementation of JSTL, and DBTags is no longer used. DBTags
has been inactive since then and it is considered as deprecated [JAK01]. Another drawback of
CAST is the way it rates the Standard Violation Index. CAST assumes, for example, that by the
Naming convention Compliance Ratio that names of stored procedures begin with "sp_", names
of triggers start with [I,U,D] and the names of views and tables do not have more than 12
characters or contain characters other than [a-Z,0-9,_]. Either an application is implemented in a
way that corresponds with the way CAST assumes, or the Naming Convention Compliance
Ratio is examined as poor. Another experience which was made with CAST was during the
analysis of the PORT application where CAST crashed and was not able to perform the analysis.
As already mentioned, the implementation of PORT is very complex and the few results
obtained by the analysis with CAST showed a very high complexity ratio.
An interesting functionality provided by CAST is the ability to make snapshots in different time
intervals. These snapshots improve the control over the quality and maintainability of the
progress of internal and outsourced development projects based upon historical data. Another
favorable functionality of CAST are the calculated metrics which predict the quality of the
implementation. With the metrics possible, problematic parts in an application are identified. For
example, components with a high Cyclomatic Complexity are pointed out and then subsequently
improved. Another useful tool provided by CAST is Enlighten which is the graphical component
for viewing projects. Enlighten is helpful in getting to know an application and also for
experienced developers as it helps to keep an overview of the application. Furthermore, CAST




                                                                                         Page 48 of 66
APM Suite is a good manager tool which generates a collection of key maintainability indicators
in a Web-based portal. Another advantage of CAST is that it supports a wide range of
programming languages. Further, are the results stored in a central repository and so does not
increase the load on the database used by the application.
Recapitulating, CAST helps IT organizations to better manage their applications and their
relationships with outsourcers throughout the lifecycle of applications. CAST as an application
intelligence solution helps to reduce costs, improve and control the productivity and quality of
complex software development. But to use CAST in a company it needs an employee who is
responsible and trained to make analysis of the applications. This is because CAST is rather a
complex tool and it needs experience to make useful statements of the results.


6.2        CAST as Reengineering Tool

For the reverse engineering of FIP we applied CAST Enlighten. Next we want to give an
example of how we did use Enlighten to find out how the performance JSP is embedded in the
application. In a first step the performance JSP was dragged to the graphical component of
Enlighten. Using the right mouse button on the added object offers to display the source code of
the object. Enlighten brings along a code viewer in which the source code of each object can be
viewed. Each main page (In the example below performance.jsp) in FIP includes the sub pages
by using the JSP tag. The included objects are marked directly in the code viewer and by using
the right mouse button they can be added to the graphical component as can be seen in Figure 9.




Figure 9: Ability to add objects from the Code Viewer to the graphical component of Enlighten.




                                                                                                 Page 49 of 66
After adding some of objects the relations to the main object are displayed. This way an
overview of the source code and the objects of the application can be obtained. Further, all
dependent objects of a component are graphically displayed as can be seen in Figure 10.




Figure 10: Direct linked objects to the performance JSP.




In a next step we added the database tables which are called by the objects to the graphical
component of Enlighten as can be seen in Figure 11. In this manner the whole application can be
explored and all the dependences between the objects identified. For adding the related objects to
an object the right mouse button has to be used and then the objects can be chosen.




Figure 11: Path from the performance JSP down to the database table.




CAST Enlighten is suited as reverse engineering tool and it helps to find out how an existing
application works and how the objects are associated among each other. With CAST Enlighten
the source code of the application can be analyzed and comprehended in detail. This is a feature
which is especially useful for employees who are new to a project but also helps advanced
developers to retain an overview of the objects. The source of an application can be browsed
intuitively without diving into endless code listings or using text search tools.




                                                                                        Page 50 of 66
6.3     Object-Oriented Reengineering Patterns

Software experts have knowledge of how to solve various problems that they have encountered.
One of the recent trends in software development has been the attempt to capture this knowledge
in a literary form known as patterns. A pattern consists of the solution to a problem in a given
context [ROB99]. Reengineering patterns are recorded knowledge which can be used in
reengineering projects. In contrast to design patterns, reengineering patterns do not choose a
solution to a design problem, instead they have to do with discovering an existing design,
determining what problems it has, and repairing these problems [DEM03].
This part discusses the most valuable patterns applied during the reengineering project. The
patterns are not explained in detail, because this is already done in the OO Reengineering
Patterns book by Demeyer, Ducasse and Nierstrasz [DEM03]. Also, this part does not cover all
the patterns of the book, because not all of them were applicable in the project. Instead the
experiences made using these patterns in an industrial reengineering project are described.


Speak to the Round Table

The first design pattern which we continuously used during the project is the Speak to the Round
Table pattern. The idea of the pattern was to keep the team synchronized and to share knowledge
among each other. Each week we held such a meeting where all project members were invited.
After the project manager gave a general overview of the project status, we discussed general
problems. The project members than gave a proposal how these problems can be solved. When
the discussion took too long and did not come to an end, an offline meeting was organized to
which all relevant team members were invited to solve the concrete problem. Doing this avoided
long and unnecessary discussions during the meeting. In the end of the meeting all project
members informed what they were doing at the moment, where they encountered problems and
what they planed to do until the next meeting.
This weekly meetings were very useful to project members because they were kept up-to-date.
Also it was very important to project leaders who got a feedback about the progress of the
project. Based on this feedback they could adjust the project plan. Further were problems solved
together, which saved time, and knowledge was shared this way.


Chat with the Maintainers

Project members, like us, who were new to a project did know anything about the
implementation of the system. We not even had a knowledge about the underlying technology.
Moreover, documentation of the applications, if it was present, has been from an early project
status and not up to date. Changes made in the mean time to the application and changed
requirements were not documented. The only documentation of this knowledge was found in the
source code of the application. Acquiring the necessary knowledge of the system was difficult.
Because of this it was important for us to Chat with the Maintainers of the application. In our
case, some of the primary developers still were maintaining the application.
Before we started to Chat with the Maintainers about details it was advisable for us, to first get
an overview of the architecture of the application. It would not have brought much value to talk
about the implementation of the system before knowing basics of it. To acquire a basic



                                                                                        Page 51 of 66
knowledge about the system we asked a maintainer and the project leader for documentation.
Based on the information contained in these documents a general overview of the application
was made. In our case, where the technology was unknown, this was also the time to get familiar
with it. For this we used the Get to know the Technology pattern, which is introduced in the next
chapter. After we had acquired some basic knowledge about the application and its technology, a
concrete and directed chat with a maintainer was hold. The maintainer, who spoke about the
system was crucial to the outcome of this pattern, so it was advisable for us to take care when we
selected him. In our case the maintainer of the application pretended not to have time to
introduce us to his application. This was because he really had a lot work to do or because he
wanted to protect his job. Because of this we arranged an official meeting to which the project
leader was invited as an optional attendee. To keep the meeting short and apply Ockam's razor,
we prepared the meeting and sent questions to the maintainer in advance. After the meeting we
worked up the acquired knowledge by using the Complete Documentation pattern, which is
introduced in the next chapter.


Read all the Code in one Hour

The goal of the Read all the Code in one Hour pattern was to get a first impression of the quality
of the source code. First the source code of the application had to be made available to us. After
we acquired a general overview of the code structure, we explored the code in more detail. Here
it was important not stuck in code fragments which were difficult to understand. When such
fragments turned up, they were marked and taken on at a later date when, for example the
application was debugged. Questions which turned up while reading the source code were
written down and later discussed with one of the maintainers.
This pattern was very useful in getting insight to the source of the application. It helped us to get
a general overview of what could be expected from the project. The knowledge acquired this
way was not enough to know all details of the application but the basic ideas of the system was
understood.
To get better results from this pattern it is advisable to apply the Interview during Demo pattern
first. In so doing, a general idea of the functionality provided by the application can be gained
and hence the source code is easier to understand. A deficiency of this pattern is that it is not
possible to read more than 10’000 lines of code in an hour. The human brain also needs a break
after one hour of concentrated working. When reading the source, which has more than 10’000
lines of code, the Read all the Code in one Hour must be split in more time segments.


Skim the Documentation

As seen above, Skim the Documentation gave us a general understanding of the system. Before
starting with reading, access to the documentation had to be organized. The project
documentation has been stored on a shared drive to which all project members had access. A
next step was to get an overview of the different documents and order them by significance. The
documents were from an older date and therefore not up to date. But for acquiring a general
overview and a basic knowledge of the system they were adequate. It also helped to ask a
maintainer or project leader to give us some advices on which documentation is relevant and
which is unsuitable at the beginning.




                                                                                           Page 52 of 66
It is proposed to read the documentation from a high level first and in a second step the more
detailed. Furthermore, when someone is new to the technology and has no experience with it,
documentation from the vendor describing the basics of the technology that has to be skimmed.
This can be done by using the Get to Know the Technology pattern.


Interview During Demo

The Interview During Demo was one of the most valuable patterns in the OO Reengineering
Patterns book. It helped us to get a feeling of the intention and functionality of the present
software system.
This pattern is advisable to perform at an early stage of the project. It is also advisable to repeat
this pattern from time to time to get familiar with the application. In addition, it is useful to
perform this pattern with other patterns (e.g. Read all the Code in one Hour pattern). This helps
to understand the intention of the source code. Further, it is important to get the system
demonstrated by different users as it is described in the book. Viewing the system from different
points of view helps to get a better understanding of it and is also conducive to talking to these
different people in a later point of time.


Do a Mock Installation

We applied the Do a Mock Installation pattern to obtain a general knowledge of the system. In
our case, an installation documentation was available. If this would not have been the case an
experienced developer of the system had to be called in. To work up and to preserve the know-
how of the installation, we made notes during this process. It also was helpful to make print
screens which reflected the different steps of the installation. After having set up the system
together with the experienced project member, it was instructive to repeat the whole installation
process ourselves. Doing this, questions turned up about details which not have been noticed
during the installation demo. Here it was very important to add these details to the notes made
during the demo to complete the installation documentation. After having set up a running
system the Step Through the Execution pattern could be applied.
As mentioned in the book it can be very tediously to install the system. This is because details
which are unknown to someone have an influence on the success of the installation. Another
point is that this task mostly takes more time than planed which seems to be very unproductive.


Step Through the Execution

After having set up a working installation of the system it invited us to explore the system. For
this purpose the Step Through the Execution pattern was adequate. It was to us to use a debugger
for this task because the functionality of the system could be traced step by step. Parts of the
source code, which have not been understood, were understood this way.
As mentioned in the book, it is very time consuming and for this reason impossible to step
through every single statement. Therefore it is advisable to work with breakpoints and other tools
provided by the debugger.




                                                                                           Page 53 of 66
Prototype the Target Solution

After having applied all patterns above, we acquired enough knowledge about the existing
system to start with the reengineering. Next, the Prototype the Target Solution pattern was
applied. This pattern helped us to evaluate the risk of migrating the existing system to a new
platform. It was advantageous to prototype the parts of the existing application with the highest
technical risk first. In so doing it was found out whether the new platform was suitable for the
requirements of the old system. A prototype also helped us to receive an impression of how to
solve different problems and gave an idea what the new file structure could look like. Further,
purchased components could be tested as to whether or not they accomplished the requirements.
(e.g. chart engine, PDF Creator,…). After having finished the prototype it was important to start
from scratch on with implementing the final solution. The temptation to not do this was high, but
the prototype was not a clean solution because it contained hacks.


All in all, these patterns of the OO Reengineering Patterns book are very helpful in the process
of a reengineering project. Some of the patterns discussed in the book primarily target
technologically experienced developers. For junior developers, who do not bring along much
experience these patterns are hardly applicable as is because the required knowledge is missing.
For example, the Read all the Code in one Hour pattern is hardly feasible for someone who is
not familiar with the technology. Further, these patterns assume that all the source code is
implemented in a clear and understandable way. But when the source is a mess or is much longer
than 10’000 lines of code and does not have a clear structure the Read all the Code in one Hour
pattern is hard to accomplish.
Next, some additional patterns that are lacking in the OO Reengineering Patterns book, but were
useful during the reengineering project, are introduced.



6.4     Self defined and used Patterns

In this part, self-defined reengineering patterns are introduced. Some of them expand the above
described patterns, and others bring in new aspects. These patterns are specifically included to
address the issues of junior developers who do not have enough experience to apply some of the
above described patterns. The following patterns describe some experiences made during this
particular reengineering project.


Get to Know the Technology

Because we were new to a technology we first had to get acquainted with the basics of this
technology before we tried to understand the existing system. To do this we first visited the web
site of the current technology vendor. In the beginning it was important to obtain an overview of
the page and to knew where certain information was found. In some cases the information
provided on the vendor’s page was not that useful to us and therefore other sources of
information had to be found. In this case it helped us to search the web for a tutorial on the
technology. In the beginning it was very hard to got a general overview from all of the found
information. After some knowledge had been acquired it made sense to us to first build a small



                                                                                       Page 54 of 66
application which provided some of the functionality of the target system. Doing this ensured us
that the technology really was understood. In a third step, the implementation of the target
application was examined. In the case parts of the source were not clear to us, we searched the
web or asked a maintainer. Here, it must be stressed that it was not important to know all
functionality used by the existing application in detail. It was much more important to know
where the information needed could be found.


Get to Know the Application

The Get to Know the Application pattern is a refinement of the Interview During Demo pattern.
The user who was giving the demo to us was used to the application and because of this, very
fast in showing the functionality of it. At the end of the demonstration, a lot of information had
been seen in a very short time. This is where the Get to Know the Application pattern came into
play. In order that we kept the knowledge of the application and its use gathered during the
demo, we had a continuous look at the application during the project. By doing this additional
information about the functionality of the application was gained. More and more details about
the application were found and knowledge increases. This acquired knowledge was of high
importance for the further success of the project.


Complete Documentation

The Complete Documentation pattern goes hand in hand with the Skim the Documentation
pattern. The pattern counteracts the fact that the documentation of an existing application is
missing or inconsistent. Updating the documentation was difficult for us because knowledge is
lacking, and in some cases the only documentation that was available, was the source code of the
application. For this reason we prepared a list with the documentation which was important for
the reengineering project. The next step was to see which of the documentation were available.
For each document of them a list was updated with the information how the constitution of the
documentation was. Then the missing documents had to be completed. Here it was important to
bring in only the information needed for the reengineering project and not to make up the work
which has been missed in an earlier phase of the project. Especially important here was to bring
the documentation up to date.
It can be argued that this pattern does not make sense because the existing application is
displaced and so no documentation is needed anymore. But reengineering the existing solution
only based on its source code makes a risky project. As well, when more than one person has to
acquire knowledge about the existing solution, this knowledge and the knowledge acquirement
techniques can be shared.




                                                                                        Page 55 of 66
7.       Conclusions


The thesis dealt with the industrial reengineering project of an Investment Fund Information
Platform. In a first part a decision has been made, which technology is applicable for the new
solution. Therefore an evaluation of different portal vendors was made. The evaluation showed
that the existing portals are reasonable solutions, but have shortcomings associated with new
technology. The decision for a portal is based on the existing technology scenery, the expected
ROI and the possibility of future technology swaps in a company. Because the expected ROI of
using a portal solution was questionable, no portal solution was chosen, instead an own solution
built on Websphere was preferred to build the new FIP 3.0.
Beside the choice of the technology an analysis of the existing application by using CAST was
made in order to get an understanding of the application and to identify the parts with a reuse
potential. Because CAST did not come to grasp with the architecture of the existing application
no profound conclusion was feasible. The analysis with CAST showed that parts of the
application are convenient for a reengineering. The input of which components of the existing
application have reuse potential arose from the experience of the maintainers and developers of
the existing application. One part which is migrated from the existing solution to the new
implementation is the logic of the model layer. Because the queries are contained in QueryTags
as dynamic SQL and not in Sybase stored procedures, this task has to be done manually.
The thesis showed that CAST helps IT organizations to better manage their applications and
their relationships with outsourcers throughout the lifecycle of applications. To use CAST in a
company it needs an employee who is responsible and trained to make analysis of the
applications. This is because CAST is rather a complex tool and it needs experience to make
useful statements of the results. Beside this the thesis showed that CAST Enlighten is an
appropriated tool for reverse engineering. With CAST Enlighten the source code of the
application can be analyzed and comprehended in detail.
During the whole thesis the OO Reengineering Patterns were constantly applied. The patterns of
the book are very helpful in the process of a reengineering project. Experiences gained in the
project showed that the patterns have to be used conscientiously and constantly. Using the
patterns this way brings a benefit to the project and helps to keep the project on the right path. It
is important to apply the patterns in the right order, which brings additional value. It does not
help to start with the Migrate System Incrementally pattern before knowing anything about the
system at all. For example it is better to perform the Interview During Demo pattern in an early
stage of the project, to get familiar with the software system and its main functionality.


7.1      Future work

The next step is to migrate the other queries from the JSP files of the existing solution to
PL/SQL. The migration can be done in the same way as showed in the thesis. It also would be
helpful to create a central list with the differences of Sybase T/SQL to Oracle PL/SQL. Further,
an appropriate interface for calling the PL/SQL procedures from the control layer of the
application has to be defined. Another task is to achieve that the OO Reengineering Patterns are
used in a consequent way and based of the experience they constantly are adapted to the
environment.




                                                                                           Page 56 of 66
8.            Appendix


8.1           Metrics

In this part the metrics integrated in CAST Application Management Platform (AMP) is
described and discussed.

8.1.1         5 High-Level Indexes

APM metrics are arranged into 5 categories and fall under the umbrella of 5 high-level indexes.
The purpose of these 5 indexes is an easy and fully functional way to assess, compare and
monitor over-time maintainability at the application level and the application portfolio level.

The 5 indexes are namely:

       •    Functional Size Index - Measures the functionalities offered to end user independent of
            the technical implementation based on two standard measurement methods: IFPUG
            (International Function Point Users Group20) Function Points and backfiring techniques.

       •    Technical Complexity Index - Measures how difficult it is to understand, modify and
            test the application based on standard metrics and technologically specific metrics.

       •    Artefact Granularity Index - Measures complexity introduced by the size of each
            programming element (each element is rated and the distribution of low to very large size
            is measured by the index).

       •    Artefact Coupling Index - Measures the difficulty to change an application due the
            dependencies between programming elements (each element's coupling is rated and the
            distribution of low to very high coupling is measured by the index).

       •    Standard Violation Index - Measures architectural and coding standard rules
            enforcement (Architecture, Performance, Code Documentation, Naming Conventions,
            Best Practices).

All the indexes’ values range from 0 to 10 for an easier comparison over-time and for application
benchmarking.

Each index has a set of metrics attached to it:
Some of the metrics attached are used to compute the index (for example distribution of
complexity in low, average, high, very high), while some other metrics offer additional
information for monitoring the values.



20
     http://www.ifpug.org/




                                                                                           Page 57 of 66
8.1.2         Functional Size Index

Functional Size index is based on ‘Function Points’ metrics. The Function Points metric
measures the functionality of software. This is done in the following steps:
First the elementary functionality is counted. In a second step the identifiable processes from a
user perspective are determined. Then they are weighted with a complexity factor and summed
up to get a final number.
Because the selection of the processes is based on the point of view of the users, the result is
independent from the technology and the way the solution is to be implemented. Details like
architecture, programming style or programming language, for example, are ignored by this
measure.21

The index is computed the following way:
- When Backfired Function Points > 1000 and < 100000 :
       Functional Size Index = (LOG ((Backfired Function Points ) / 1000)) * 5
- When Backfired Function Points < 1000:
       Functional Size Index = 0.01
- When Backfired Function Points > 100000:
       Functional Size Index = 10

Example:
When Backfired Function Points = 5000, the index is equal to 3.49

8.1.2.1        Estimation Process – Overview

The estimation process is cut into three levels:
• At the module level:
At the module level, the unadjusted data functions are first estimated for database modules. In a
second step the unadjusted transactional functions are estimated for all modules that are not
database modules. In a last step the two estimations of the database and non database modules
are calculated together which results in the Automated IFPUG Function Points Estimation.

• At the application Level:
At the application level the Unadjusted Data Functions, which is the sum of unadjusted data
functions of all the modules, is calculated. The calculation is as follows:
Unadjusted Transactional Functions is equal sum of Unadjusted Transactional Functions of all
the modules of the application.

• At the system Level:
Unadjusted Data Functions is equal the sum of Unadjusted Data Functions of all the
Applications of the System.
Unadjusted Transactional Functions is equal the sum of Unadjusted Transactional Functions of
all the Applications of the System.
Automated IFPUG Function Points Estimation is equal the Unadjusted Data Functions added
with the Unadjusted Transactional Functions.


21
     http://www.ifi.unizh.ch/req/courses/seminar_ws02/reports/Seminar_5.pdf & http://www.ifpug.org/




                                                                                                      Page 58 of 66
8.1.2.2   Estimation Process - Unadjusted Data Functions for Database Modules

Unadjusted Data Functions are computed for a database schema in the following way:
   1. Identification of the Data Entities in database modules
   2. Computation of RET and DET for each Entity
   3. Computation of Function Points for each Entity
   4. Computation of Unadjusted Data Functions

1. Identification the Data Entities in database modules
The estimation engine identifies data entities by grouping master-details tables based on their
foreign key relationships and their naming.
For a given table A, the engine searches attached tables (i.e. having a (1,1)-(x,x) relation with
the table A). If the attached tables share a naming convention with the table A, the attached
tables are set to be the details table of the Master table. A Master table shares a naming
convention with its detail table. The first 4 characters of the Master table are included in the
name of the detailed table. A table prefix is a set of characters that are systematically added at
the beginning of table names like “SYS_” or “APP_”.
For a database schema, the result is a list of data entities, each one being composed of one master
table and 0 or more detail tables.

2. Computation of RET and DET for each Entity
- RET (Record Element Types) = number of tables belonging to the data entity = 1+number of
    detail tables.
- DET (Data Element Types) = number of non-redundant columns for all tables of the data
    entities (redundant columns are columns with same names).

3. Computation of Function Points for each Entity
Unadjusted Data Functions = (Data Entities FP).

The Data Entity’s IFPUG number of Function Points is computed the following way:
                      1 to 19 DET            20 to 50 DET              51 or more DET
0 or 1 RET            Low = 7 FP             Low = 7 FP                Average = 10 FP
2 - 5 RET             Low = 7 FP             Average = 10 FP           High = 15 FP
6 or more RET         Average = 10 FP        High = 15 FP              High = 15 FP

4. Computation of Unadjusted Data Functions
Unadjusted Data Functions = (Function Points of all Data Entities)


8.1.2.3   Estimation Process - Unadjusted Transactional Functions

The Unadjusted Transactional Functions is computed for all modules other than database ones. It
is computed in the following steps:
    1. Identification of the User Forms
    2. Identification of the tables used directly or indirectly by each Form,
    3. Computation of FTR and DET for each Form
    4. Computation of Function Points for each Form
    5. Computation of Unadjusted Transactional Functions



                                                                                         Page 59 of 66
1. Identification of the User Forms
First off all, the User Forms in the application are located and identified.

2. Identification of the tables used directly or indirectly by each Form
For each Form an impact analysis of how many times the tables are used directly or indirectly by
the Form is made.

3. Computation of FTR and DET for each Form
- FTR (File Types Referenced) = Number of tables used directly or indirectly by the Form.
- DET (Data Element Types) = Number of non-redundant columns for all tables used directly
    or indirectly by the Form (redundant columns are columns with same names).

4. Computation of Function Points for each Form
For all the User Forms, the Function Points metrics are computed the following away:
                         1 to 4 DET              5 to 15 DET              16 or more DET
0 or 1 FTR               Low = 3 FP              Low = 3 FP               Average = 4 FP
2 FTR                    Low = 3 FP              Average = 4 FP           High = 6 FP
2 or more FTR            Average = 4 FP          High = 6 FP              High = 6 FP

5. Computation of Unadjusted Transactional Functions
Unadjusted Transactional Functions = (Function Points of all User Forms)

8.1.3     Technical Complexity Index

Technical Complexity Index is a weighted sum of 4 sub indexes. The weight is distributed in the
following way among the 4 sub indexes:


Technical Complexity Index = CCI × 0.64 + 4GLCI × 0.12 + OOCI × 0.12 + SQLCI × 0.12


Cyclomatic Complexity Index = CCI
4GL Complexity Index = 4GLCI
OO Complexity Index = OOCI
SQL Complexity Index = SQLCI

8.1.3.1   Cyclomatic Complexity

Introduced by Thomas McCabe [McCABE76], Cyclomatic Complexity measures the number of
linearly independent paths through a program module. This measure provides a single ordinal
number that can be compared and analysed. In CAST the Cyclomatic Complexity Index is the
weighted sum of 4 sub metrics divided by the sum of the 4 sub metrics themselves. The
weighting is distributed among the sub metrics. The table shows the Cyclomatic Complexity for
all four sub metrics and how they are weighted.

                                                   Cyclomatic                  Weight



                                                                                        Page 60 of 66
                                                Complexity
Low Complexity Artefacts                        <5                      1
Moderate Complexity Artefacts                   >= 5 && <15             5
High Complexity Artefacts                       >= 15 && < 30           8
Very High Complexity Artefacts                  >= 30                   10

The Cyclomatic Complexity Index is then calculated as follows:


                                  LCA × 1 + MCA × 5 + HCA × 8 + VVHCA × 10
Cyclomatic Complexity Index =
                                       (LCA + MCA + HCA + VVHCA)

Low Complexity Artefacts = LCA
Moderate Complexity Artefacts = MCA
H igh Complexity Artefacts = HCA
Very High Complexity Artefacts = VHCA

8.1.3.2   4GL Complexity Index

4GL Complexity Metrics evaluate the Complexity of a user interface based on 4GL
Technologies (PowerBuilder, Visual Basic, .NET, Delphi, Forms). Metrics of this category are
related to user interface forms or windows. Because FIP is a pure web application, a short
overview of what is contained in the 4GL Complexity Index is given.

4GL Complexity Index is the weighted sum of 4 sub metrics:

                         L4GL * 1 + M4GL * 5 + H4GL * 8 + VH4GL *10
4GL Complexity Index =
                            (L4GL + M4GL + H4GL + VH4GL)

Low 4GL Complexity Forms = L4GL
Moderate 4GL Complexity Forms = M4GL
High 4GL Complexity Forms = H4GL
Very High 4GL Complexity Forms = VH4GL


8.1.3.3   Object-Oriented Complexity Index

Object-Oriented Complexity Metrics (hereafter called OO Complexity Index) evaluates the
Complexity of an Object-Oriented design of an application. The sub metrics of this category are
related to the classes of an Object-Oriented design.

The OO Complexity Index is also calculated as the weighted sum of 4 sub metrics divided by
their sum:




                                                                                     Page 61 of 66
                          LOO * 1 + MOO * 5 + HOO * 8 + VHOO *10
OO Complexity Index =
                             (LOO + MOO + HOO + VHOO)

Low OO Complexity Classes = LOO
Moderate OO Complexity Classes = MOO
High OO Complexity Classes = HOO
Very High OO Complexity Classes = VHOO

The different complexity classes are defined under the following rules. A class is in the “Low
OO Complex” category when it is in none of the following categories. Classes are “Moderate
OO Complex” when they are in only one of the following categories. A Class is “High OO
Complex” when it is in two following categories. Finally, a class is “Very High OO Complex”
when it is in at least three of the following categories. The Categories are by name:

   •      High Cyclomatic Complexity Classes (WMC)
   •      High Depth of Inheritance Classes (DIT)
   •      Low Cohesion Classes (LCOM)
   •      High Length or Weight Classes

8.1.3.4    SQL Complexity Index

The SQL Complexity Metrics Index evaluates the complexity of both the database SQL and the
embedded SQL. The database SQL is contained for example in stored procedures, while
embedded SQL is directly contained in the source of an application. The SQL Complexity Index
does not take into account dynamic SQL which is generated during the execution of an
application.

As with the Indexes above, the SQL Complexity Index is calculated as the weighted sum of 4
sub metrics divided by their sum. The calculation is as follows:

                          LSQL * 1 + MSQL * 5 + HSQL * 8 + VHSQL *10
SQL Complexity Index =
                             / (LSQL + MSQL + HSQL + VHSQL

Low SQL Complexity Artefacts = LSQL
Moderate SQL Complexity Artefacts = MSQL
High SQL Complexity Artefacts = HSQL
Very High SQL Complexity Artefacts = VHSQL




                                                                                     Page 62 of 66
An SQL Artefact is said to be complex based on its SQL Complexity. The Artefact SQL
Complexity is rated in a range from 0 to 100. 0 is given to artefacts with lowest complexity and
100 for highest complexity. The fragmentation of the complexity is shown in the table below.

Low SQL Complexity Artefact                        Artefact Complexity < 10%
      SQL
Moderate SQL Complexity Artefact SQL               Artefact Complexity >=10% && < 40%
High SQL Complexity Artefact                       Artefact Complexity >=40% && < 70%
      SQL
Very High SQL Complexity Artefact SQL              Artefact Complexity >=70%

This SQL Artifact Complexity is defined by CAST the following way:

SQL Artifact Complexity =
if(Artifact with a query on more than 4 tables)    + 50%
else if(Artifact with a subquery)    +10%
else if(Artifact with a GROUP BY) +10%
else if(Artifact with a complex SELECT clause)      +10%
else if(Artifact with an UPDATE statement)        +10%
else if(Artifact with row SQL Complexity Higher than) 30     +10%
Formual 8: SQL Artifact Complexity


Examples:
   1. A view containing a query on more than 4 tables (50%) and a complex SELECT clause
      (10%) has an SQL Complexity = 60%.
      It is ranked as a High SQL Complexity Artefact.

    2. A stored procedure containing an UPDATE statement, a GROUP BY and using sub
       queries has an SQL Complexity = 30%. It is ranked as a Moderate SQL Complexity
       Artefact.


8.1.4     Artefact Granularity Index

This index measures the distribution of an artefact’s size in an application. The growth of
Artefact Granularity in an application is usually a sign of growing complexity. Growing
complexity of an application has an negative impact on its maintainability.

Artefact Granularity Index is the weighted sum of 4 sub metrics:




                                                                                      Page 63 of 66
                               SSA * 1 + ASA * 5 + LSA * 8 + VLSA *10
Artefact Granularity Index =
                                     LSA + ASA + LSA + VLSA

Small Size Artefacts = SSA
Average Size Artefacts = ASA
Large Size Artefacts = LSA
Very Large Size Artefacts = VLSA

The size of an artefact is based on the number of code lines. The thresholds for low, average,
large and very large are defined for each in a technologically independent manner. The default
values are set by CAST as the following table shows:

                                                 Number of code lines
Small Size Artefacts                             < 10
Average Size Artefacts                           >= 10 && < 50
Large Size Artefacts                             >= 50 && < 200
Very Large Size Artefacts                        >= 200

8.1.5   Artefact Coupling Index

The Artefact Coupling Index determines the difficulty to change an application due to the
interdependencies between artefacts.

The Artefact Coupling Index is calculated as the weighted sum of 4 sub metrics:


                             LCA * 1 + MCA * 5 + HCA * 8 + VLCA *10
Artefact Coupling Index =
                                (LCA + MCA + HCA + VLCA )

Low Coupling Artefacts = LCA
Moderate Coupling Artefacts = MCA
High Coupling Artefacts = HCA
Very Large Coupling Artefacts = VLCA

The meaning of coupling here is based on the metric “number of callers”.

Thresholds for low, average, large and very large are defined by CAST for each in a
technologically independent manner. Default values are set as following:

                                                 Number of Callers
Low Coupling                                     <4
Average Coupling                                 >= 4 && < 10
High Coupling                                    >= 10 && < 30
Very High Coupling                               >= 30



                                                                                     Page 64 of 66
8.1.6   Standard Violation Index

Standard Violation detects and quantifies coding rule exceptions to architecture, best practices,
performance, documentation and naming convention standards. Standard Violation Index and the
attached metrics are derived from the CAST Enforce checks and are based on CR = Standard
Compliance Ratio.

The Standard Violation Index is calculated as follows:

Standard Violation Index = (LOG(100- CR)*5)/LOG(CR) when 10 < CR < 100,
Standard Violation Index = 0                        when CR = 100,
Standard Violation Index = 10                       when CR < 10.

Compliance Ratio      Index
0                     10.00
10                    9.77
20                    7.31
30                    6.25
40                    5.55
50                    5.00
60                    4.50
70                    4.00
80                    3.42
85                    3.05
90                    2.56
91                    2.44
92                    2.30
93                    2.15
94                    1.97
95                    1.77
96                    1.52
97                    1.20
98                    0.84
100                   0.00




                                                                                       Page 65 of 66
9.           References


[ALB83] Albrecht, Allan J. and John E. Gaffney, Jr., “Software Function, Source Lines of Code,
  and Development Effort Prediction: A Software Science Validation,” IEEE Transactions on
  Software Engineering, Vol. SE-9, No. 6, November 1983 .......................................................26
[BEA04] BEA Systems, Inc., „Flexibility through BEA’s Support for Portal Standards“,
  www.bea.com, Aug 2004 ..........................................................................................................15
[BRI96] Lionel C. Briand, Christiane M. Differding, and H. Dieter Rombach, "Practical
  guidelines for measurement-based process improvement", Technical Report ISERN-96-05,
  Fraunhofer Institute for Experimental Software Engineering,1996 ..........................................22
[E&Y03] Cap Gemini Ernst & Young, “Unternehmensportale – Anwendungsbereiche und
  Implementationserfahrungen”, European e-commerce Academy, IT-Trends-Survey 2003 .....14
[EDM97] Edmond VanDoren, “Cyclomatic Complexity”, Carnegie Mellon University,
  Software Engineering Institute, Jan 1997..................................................................................34
[GRE04] Rachel Greenblatt, „ JSR 168 and WSRP: Setting High Standards”, WebLogicPro,
  Fawcette Technical Publications, Oct 2004 ..............................................................................15
[HR83] Härder, T., Reuter, A., "Principles of Transaction-Oriented Database Recovery", ACM
  Computing Surveys, Vol. 15, No. 4, 1983, pp. 287-317 ...........................................................44
[IX04] Achim Born, Jürgen Diercks, „Integration: Universaleingang: Portale: Hype oder
  Arbeitsumgebungen der Zukunft?“, IX 11/2004, s.109 - 113 .............................................15, 19
[JAK01] The Jakarta Project, “DBTags Tag Library”, jakarta.apache.org, DBTags Status.........48
[JSR168] Alejandro Abdelnur, Stefan Hepper, “JSR 168: Portlet Specification”, Java
  Specification Requests, Java Community Process, Sun Microsystems and IBM, Oct 2003 ....15
[Koll04] Ralf Kollmann, „Experiences With an Industrial Long-Term Reengineering Project”,
  Proc. 11thWorking Conference on Reverse Engineering (WCRE 2004). IEEE, Los Alamitos,
  2004 ...........................................................................................................................................13
[LONG] David Longstreet, "Estimating Software Development", Longstreet Consulting Inc.
  1992 - 2005..................................................................................................................................8
[McCABE76] McCabe, Tom, "A Software Complexity Measure", IEEE Trans. Software Eng.,
  Vol.2, No.6, December 1976, pp.308-320.................................................................................60
[NUC03] Nucleus Research Inc., “ROI Comparison Report: Portals”, Nucleus Research Inc.,
  Research Note D85, 2003..........................................................................................................20
[ROB99] Donald Bradley Roberts, “Practical Analysis for refactoring”, University of Illinois at
  Urbana-Champaign, 1999, p. 22................................................................................................50
[SHV91] Shyam R. Chidamber, Chris F. Kemerer, “Towards a Metrics Suite for Object
  Oriented Design", Massachusetts Institute of Technology, 1991, p. 2002................................34
[SNEED95] Harry M. Sneed, “Software Engineering Service - Planing a reengineering of a
  Legacy System”, IEEE Software or Software Engineering Services, January 1995, p. 24-34 ...8



                                                                                                                                      Page 66 of 66

								
To top