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

2. 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

3. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 3/15 Technology General Recomm. and conclusions Approach and First results Assignment: Review maintainability Documentation: 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 documents Documents vs. implementation Files vs. DB Oracle HTML/JS Java

4. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 4/15 Technology General Recomm. and conclusions Inspection: Architecture Business logic 2 tiers 3 tiers Efficiency Reuse, maintainability and portability The SystemModern approaches (J2EE)

5. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 5/15 Technology General Recomm. and conclusions Implementation: Risks involved Technology  maintainability risks Risks ≠ problems Problems = not (adequately) addressed risks PL/SQLHTMLJSJavaDB modifi- cation modu- larity porta- bility dyna- micity skillstriggers coding conven- tions code duplica- tion propri- etary tags inspec- tion n/ainspec- tion How are the risks addressed?

6. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 6/15 Technology General Recomm. and conclusions Therefore, approach Documentation: review, comparison. Architecture: inspection Implementation: Technology-related:  Code duplication detection  Coding conventions assessment  Use of proprietary tags General  Dead code detection  Metrics calculation  Dependency analysis

7. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 7/15 Technology General Recomm. and conclusions Modification: Code duplication: SQL

8. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 8/15 Technology General Recomm. and conclusions 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

9. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 9/15 Technology General Recomm. and conclusions 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)

10. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 10/15 Technology General Recomm. and conclusions 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

11. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 11/15 Technology General Recomm. and conclusions Dependencies Green “bubbles” – internal calls: arguments as part of a name rel_6_1_f instead of rel(6,1,f)

12. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 12/15 Technology General Recomm. and conclusions 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.

13. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 13/15 Technology General Recomm. and conclusions 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

14. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 14/15 Technology General Recomm. and conclusions Case conclusions We support the decision to continue supporting the system 3-5 years Identified maintainability problems. Suggested a way to address them.

15. Copyright © LaQuSo Eindhoven, Enschede, Delft, Nijmegen 2008 Input Implementation 081117_AS_DLL 15/15 Technology General Recomm. and conclusions 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)