LaQuSo is an activity of 3TU and Radboud Universiteit Nijmegen Maintainability of Front-End commissioned by drs. Reinier Post dr. Serguei Roubtsov Peter

LaQuSo is an activity of 3TU and Radboud Universiteit Nijmegen

Maintainability of Front-Endcommissioned by

drs. Reinier Postdrs. Reinier Postdr. Serguei Roubtsovdr. Serguei Roubtsov Peter SchachtschabelPeter Schachtschabeldr. Alexander Serebrenikdr. Alexander Serebrenik

Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008

Input

Implementation

081117_AS_DLL 2/15

Technology

General

Recomm. and conclusions

The Front-End System

The System: ≈ 15 years old web application

client side: HTML/JavaScript, Java, C++ server side: Oracle 9, PL/SQL

size: 1756 files 61 database table

“environment”: 2317 more files even more languages (C, COBOL, Oracle Forms) links through common use of database


Input

Implementation

081117_AS_DLL 3/15

Technology

General


Approach and First results

Assignment: Review maintainabilityDocumentation:

Consistent Internally? With respect to the implementation?

Implementation Architecture Technology used

General risks implied Addressed adequately?

General analyses Dead code Metrics Dependencies

Discrepancies between:Different documentsDocuments vs. implementationFiles vs. DB

Oracle

HTML/JS

Java


Input

Implementation

081117_AS_DLL 4/15

Technology

General


Inspection: Architecture

Presentation

Business logic

Storage

Presentation

StorageBusiness

logic

2 tiers 3 tiers

Efficiency

Reuse, maintainability and portability

The System Modern approaches (J2EE)


Input

Implementation

081117_AS_DLL 5/15

Technology

General


Implementation: Risks involved

Technology maintainability risksRisks ≠ problems

Problems = not (adequately) addressed risks

PL/SQL HTML JS Java DB

modifi-cation

modu-larity

porta-bility

dyna-micity

skills triggers

coding conven-

tions

code duplica-

tion

propri-etary tags

inspec-tion

n/a inspec-tion

How are the risks addressed?


Input

Implementation

081117_AS_DLL 6/15

Technology

General


Therefore, approach

Documentation: review, comparison.Architecture: inspectionImplementation:

Technology-related: Code duplication detection Coding conventions assessment Use of proprietary tags

General Dead code detection Metrics calculation Dependency analysis


Input

Implementation

081117_AS_DLL 7/15

Technology

General


Modification: Code duplication: SQL


Input

Implementation

081117_AS_DLL 8/15

Technology

General


Specific maintainability problems

Maintenance effort concentration: P.R. *.phtml, 2005-2008, 185/190 modifications *.sql, 2005-2008, 479/603 modifications

Language: Dutch Risk for outsourcing / maintenance by a non-Dutch

speaking person Contradicts the official language policy

Annual maintenance: at least 2 maintainers Computed using backfiring function points

Metrics High McCabe’s complexity, low MI


Input

Implementation

081117_AS_DLL 9/15

Technology

General


Dependencies

1) All subsystems are affected except for DIT.2) Layered system organization.3) HTML: calls only inside a group.4) DB tables are invoked from different layers: no

DB abstraction layer.

1)

2)3)

4)


Input

Implementation

081117_AS_DLL 10/15

Technology

General


Fan-in, fan-out and cross-dependencies

30 files with fan-in ≥ 3 (max: 55)30 files with fan-out ≥ 5 (max: 14)

Cycles involving files with both high fan-in and high fan-out


Input

Implementation

081117_AS_DLL 11/15

Technology

General


Dependencies

Green “bubbles” – internal calls: arguments as part of a name rel_6_1_f instead of rel(6,1,f)


Input

Implementation

081117_AS_DLL 12/15

Technology

General


Summary: Strong and week points

Strong points Organized in a layered way Provided with useful comments in code Supported by many coding conventions

Weaknesses Overview documentation is missing Documentation, code and DB are

inconsistent Code is polluted by duplication and high

complexity Conventions can neither be automatically

checked nor enforced.


Input

Implementation

081117_AS_DLL 13/15

Technology

General


Recommendations

Document: Structure, dependencies and assumptions. Coding and naming conventions. Consider switching to English.

Code: Discrepancies: database diagrams vs. files. Refactor modules with significant code duplication and high metric values.

Maintenance process: Integrate development supporting tools Separate versions: Involve additional maintainers.

Longer run: Consider migrating to a three-tiered architecture.

Short term


Input

Implementation

081117_AS_DLL 14/15

Technology

General


Case conclusions

We support the decision to continue supporting the system

3-5 years

Identified maintainability problems.Suggested a way to address them.


Input

Implementation

081117_AS_DLL 15/15

Technology

General


Looking back: How did it go?

We spent 30 days Required for tool development and

refinement Reusable for new PL/SQL cases

Findings led to a maintenance plan

3 weeks later we got a new assignment the customer is the same new and large system (700 KLOC)