|
This project was subcontracted by a German software development company, based in Cologne. The company supplies city with gas and water data management software since 1982, being almost a monopolist in this area in province.
This software is a package of products for very specific management, accounting, calculation and maintenance of gas and water consuming by private person and companies, used in the municipal department.
Project 1. Porting to Oracle and Informix
Our cooperation started already in 1997. At that time, the system was written in COBOL and for storage of data used a library based on an own implementation of CISAM algorithms. The customers (mostly government) started to move their other systems to Oracle and Informix and they were wishing to port the system from CISAM to these more modern DBMS, as well as to have interfaces to exchange data with their systems. Also, internally, company hoped to improve performance of their product, assuming that move to relational database will significantly affect speed of the system. This task was given to us.
The total amount of tables (.DAT and .IDX) files in the system exceeded 450. First of all, we created a corresponding to the structure of the data files data model in Platinum ErWin. We did it trying to minimize differences the existing data storage system and between Oracle, Informix already on data presentation level, to reduce further problems with distinction in SQL. Than, we developed a library of functions providing common interface for work with all three possible alternatives: Oracle, Informix and CISAM-based data storage. The library consisted of two layers: first was an implementation of common API calling functions from the other, database-specific layer, which was develop in Embedded SQL (for DBMS) and with usage of the company's own API to its storage system.
Having this one API, common for all of necessary at that time databases and easily extensible to other, we made other COBOL sources independent of the database level. The next step was to re-write over 400 masks (screens) to have them working with the new API library. That was successfully done within next 8 months. Almost all of this time four-five developers were working on this task, intensively using such Unix utilities as awk, sed and make to automatize many aspects of the development process. Nevertheless, all screens had to be processed manually by developers.
After the development was completed, testing has shown that the usage of DBMS (Oracle and Informix) didn't improve the performance, but made it worse, and for some queries up to 12 times! Average results were: with DBMS the system worked 1.2-4 times more slow than with the ISAM files. The customer blamed us for this, so we started to try to optimize queries and administrate all involved software to achieve better results. We optimized for our needs operation system configuration (Solaris, SCO), (for example shared memory and virtual memory), database parameters (such as cache and read ahead directives, statistics, indexes, queries), somewhere - application's logic. But it didn't provide us with any noticeable results: only some most slow queries became faster. In reality, the reason for this was, that DBMS, being more flexible and having a complex mechanisms for management of relational data, possess a lot of redundant functionality, which cannot compete with direct index file access:
We were able to prove it to client, and it was accepted. Hardware industry did a huge steps in direction of improving capabilities of resources and speed, and this became not a problem anymore. Usage of DBMS was much more preferable because of transaction mechanisms (in comparison to simple locking of data files), backup, maintenance and all the other advantages that DBMS provides.
This development allowed our German customer to sell this system to new clients, enlarging their market. The design, suggested by ourselves for the porting, and its implementation, was so useful, that in 2000 customer ordered us to develop a module (see second layer for database access API library) for DB2, which was successfully performed by two of our developers within just two months.
Project 2. Porting to Visual Basic
In the 1998, with the constant growing of capabilities of hardware, German clients of our customer started to upgrade their computers, installing more and more PC workstations running Windows. The software that the company provided, written in COBOL and having a terminal-based user interface, wasn't comfortable for users and the municipal government ordered a new version with Windows interface.
Porting of that huge amount of COBOL code required a lot of resources, so company decided to start from small subsystems, increasing this amount step by step. We were subcontracted to port one of applications, user's terminal, consisting of about 50 screens. The objective of our task was to keep in Windows-based application possibility to promptly and comfortably enter data by person working with the software.
At that time, we decided to not to look for any specific framework, that could allow us to automatize the porting process. We are convinced that while dealing with two so much different technologies (different also in its age), it is impossible to just automatically process the old code and get exactly the same software but in other technology. Also our customer was convinced of it, because his goal was not just to port but also to improve the present product.
In most screens we were required to change screen's layout, because in fact Windows UI allows to provide to the user more advanced interface than text-mode application does. Therefore this project wasn't just porting, but a lot of new development - without changing the business logic, we were making user interface more comfortable. German client gave us responsibility to do this.
Development environment consisted of Microsoft Visual Basic 5.0, for data access (to Oracle and Informix) we took Intersolve ODBC components and Microsoft DAO 3.0 Object Library (company's proprietary CISAM-based solution wasn't targeted by the new version of product). Interface required a few advanced components such as grid and navigational tree, therefore we used Sheridan (now company's name is Infragistics) OCX's (Microsoft standard components weren't corresponding customer requirements).
For installation program we used InstallShield, because standard Microsoft installation tool shipped with Visual Basic didn't provide all of the required functionality.
To minimize time for loading of meta data from the server, we used a local Access database, so that some often using tables (language resources, descriptions, etc.) were loaded only in case if in database on the server data are newer than in the local database. When application starts, it asks server for time of the last update of these data (which is watched by triggers set on insert and update), and if the data on the server are newer, application automatically loads it from the server. In this way, many parts of the client application are updatable, and it doesn't influent the network traffic and as the result - the speed of work for user.
The project was successfully completed by the end of 1999 and took over 20 man months (2-3 developers were working about 9 months).
Project 3. Providing Web-interface to reporting functionality
In February 2001 we were subcontracted to develop a set of Web-based applications providing possibility to view reports generated on basis of data stored in the GORUS database. At the moment this application is using Oracle only and runs mostly on Unix platforms (Solaris, SCO, Linux) and some mainframes (OS/390).
In order to provide effective implementation and qualitative functionality, we decided to use JSP (Tomcat), Oracle JDBC drivers (type 4) and a set of our applets (Awt.X Treetable, Graph). Also for reporting functions we generate miscellaneous charts and diagrams as GIF images using functionality provided by standard (from JDK 2) Java classes libraries.
The project is nearly completed and till now required over 15 man months.
|
