Recent Industrial Applications of VDM in Japan

This paper describes the industrial use of the Vienna Development Method (VDM and VDM++) technology in Japan since the acquisition of VDMTools by CSK Systems in 2003. This acquisition followed a very successful application of VDM++ in the development of two subsystems of the TradeOne back office system for securities trading. Subsequently, FeliCa Networks has also successfully applied VDM++ in the development of a new generation IC chip for use as an electronic purse which can be embedded in a cellular telephone. This paper provides a short overview of some of the most important industrial applications of VDM in Japan in recent years. It also reports about the main lessons learned, particularly regarding quality and cost. Finally, the future prospects for this kind of technology in Japan are considered.


INTRODUCTION
Most industrial applications of formal methods to date have taken place in Europe [1,2,3,4] and US [5,6].This paper demonstrates that Japan has been moving forward strongly in this area in recent years.Many of the results have so far been published in Japanese, typically at the Japanese Software Symposium, so this paper aims to provide an English-language update on the recent achievements.Having worked with Japanese engineers for more than a decade makes us believe that we will see a substantial increase of the industrial take-up of formal methods in the coming years in Japan.
The work reported here exploits the Vienna Development Method (VDM) [7,8,9].This is one of the longest established model-oriented formal methods, having originated in the IBM laboratories in Vienna at the beginning of the 1970s.VDM supports modelling and analysis at various levels of abstraction, using a combination of implicit and explicit definitions of functionality.VDM has a strong record of industrial application [3,10,11,12,13], in many cases by practitioners who are not specialists in the underlying formalism or logic.Experience from these projects suggests that the effort expended on formal modeling and analysis can be recovered in reduced cost of rework arising from design errors [14,15].The projects discussed in this paper support that result.
In the middle of the 1990s, cooperation began between the Railway Technical Research Institute (RTRI) [16,17] and IFAD, the Danish company that had spent over a decade developing VDM technology to industrial standards [18].This initial work used VDM-SL [8].Correctness of railway systems has been a major goal for RTRI for a long time.Natsuki Terada, one of their engineers, spent two full years at IFAD in Denmark in order to take advantage of the proof support then being developed for VDM in the EU-supported PROSPER project [19].
CSK Systems (at that time Japan Future Information Technology & Systems Co., Ltd.(JFITS), a part of the CSK Group) decided to purchase the VDMTools technology from IFAD.JFITS had been using the technology successfully on two of the subsystems of the TradeOne system, and saw the potential for further exploitation.
This paper provides a very brief review of the use of VDM++ in the TradeOne project (Section 2) and in a more recent and larger project carried out by FeliCa Networks (Section 3).In each case, we give a brief presentation of the application and the metrics that have been gathered.The paper ends with a few concluding remarks and predictions about future expectations.

THE TRADEONE PROJECT
TradeOne is a back-office solution aiming to lower the general operating costs in trading securities.A detailed description of the use of VDM++ in TradeOne has been provided elsewhere ( [20], Chapter 11).Here we will give a flavour of the development and discuss some of the metrics from the VDM++ development.

A High-level Project Description
The users of the TradeOne system are securities companies and brokerage houses trading in securities.A security is a certificate attesting credit or the ownership of stocks, options, bonds, etc.An option is a contract that entitles its owner to either buy or sell a security or an index at a certain price before a certain date.The dates at which securities should be exercised, cancelled or agreed are critical to successful business in this domain.In trading companies, significant resources are therefore devoted to keeping track of the dates for securities.To remain competitive in a worldwide trade market, it is necessary to optimise the trader's business model and deal with the complexity of older traditional systems and TradeOne does that.
TradeOne's functionality covers several areas, shown informally in Figure 1.Two of these have been developed using the object-oriented extension of VDM (VDM++): the tax exemption subsystem and the option subsystem.The former automates the handling of Japanese tax regulations, previously a manual and error-prone task.The latter is responsible for handling the business process related to trading options.This kind of automated support is necessary to accommodate business process change, for example, to reduce the securities transaction settlement date.

The Tax Exemption Subsystem
The tax exemption subsystem was developed by a small team of developers during 2000.There were six people in this development team, averaging four people per month for three and a half months.The development started with an initial design phase in which a system architect derived an initial framework for the VDM++ models.After this, four VDM++ experts developed models in parallel.All the VDM++ models were reviewed by all the members of the project team.Finally two expert programmers implemented the system manually from the VDM++ model.
All the developers were over 40 years old and each had been developing software for more than 20 years.However, for all of them it was their first development using C++ and Java.For all but one the developers it was also their first application in the financial domain.Four members of the team had some basic prior knowledge of formal methods and so had little difficulty applying VDM++ on this subsystem.An external consultant was also used for the development of this subsystem.

The Option Subsystem
The option subsystem was developed by a larger team of ten developers during 2001.The development started with a group of domain experts writing functional requirements for the subsystem in Japanese.In parallel, one of the VDM experts from the tax exemption subsystem taught three new programmers VDM++ (in less than one week).
It is worth remarking that a Japanese version of VDMTOOLS supporting Japanese language identifiers was used in the option subsystem development.This was considered important because a larger group of people was involved in the VDM++ modelling.On average, 9.5 person-months were spent per calendar month.

Metrics Gathered
To permit comparisons between TradeOne and other projects, standard measuring principles based on the constructive cost model (COCOMO) [21] were followed.In COCOMO the size of an application can be measured in "delivered source instructions" (DSI).DSIs for the overall TradeOne system and the parts modelled using VDM++ are given in Table 1.On the productivity side, the COCOMO estimates for man-months (MM) as well as duration are compared against the real effort spend and duration in Table 2.The corresponding VDM++ models were in total 11,757 DSI for the tax exemption subsystem and 68,170 DSI for the option subsystem.These figures include a test bed, test cases and informal comments explaining the VDM++ models.In total 3000 test cases were produced covering 100 % of the VDM++ model.In the option subsystem model more than 30,000 lines are dedicated to test cases alone.
From a quality perspective, the defect rates at integration test were 0.65/kDSI for the tax exemption subsystem was and 0.71 defects/kDSI for the option subsystem.These defects were readily fixed and are believed to have originated in the requirement gathering phase.No defects have been identified in the running implementations of these subsystems.The TradeOne product as a whole had a defect rate of 1.12 defects/kDSI at integration test and 0.67 defects/kDSI in the running implementation.This is in itself better than normal industrial standards.To compare to defect rates elsewhere, the order of defects in NASA software is reputed to be around around 0.1 defects/kDSI, and at least 10 times normal development costs are required to reach this level of correctness.For normal-quality commercial released code, the figure is around 30 defects per 1000 DSI.This comparison suggests that the correctness reached in the two subsystems developed using VDM++ is impressive.

High-level Project Description
In the production of a new generation of IC chip for electronic payment with an electronic purse FeliCa Networks decided to use VDM++ for the development of the operating system software (the firmware inside the chip).This new generation IC chip contains new features and so is more complex than previous generations.The new generation IC chip must operate to the strict timing requirements provided by earlier generations despite the increase in complexity.
During the development of this product there have been 50 to 60 people affiliated with this project, with an average age of a little over 30 years.No members had knowledge of or experience with the formal method at the time of project launch.VDM training in Japanese was provided for the development team by CSK.
In addition an external VDM consultant from CSK Systems was used throughout the project.This version of the firmware took about three years to develop and it was delivered on schedule and millions of IC chips have been distributed.

Project Teams and Metrics Gathered
The development team was divided into groups: one responsible for validation and verification, and one for implementation.Subsequently the members of each group completed questionnaires assessing their impression of the use of VDM++.In addition an interview was held with the twelve team members who most frequently referred to the formal VDM++ model.This feedback showed that none of the groups had negative reactions to using VDM++ but the members from the implementation team did not see the benefit of it as much as the others.VDM++ was felt to be an efficient communication tool between the team members and between the teams.They all acknowledged that new knowledge was required but also that there is a substantial difference between the skills required in writing and reading a formal model.In general it was felt that advanced mathematics was not necessary for writing or validation the VDM++ model.
The main results related to specification development were: • A 383 page protocol manual written in natural language (Japanese).This is a manual for other departments within the company as well as for outside customers.• A 677 page external specification document written in VDM++ (approximately 100 kDSI including comments).Approximately 60 % of that can be considered as test cases formulated in VDM.
The specification includes the specification of 86 different commands in the firmware and the file system security specification.From this VDM++ model a C/C++ code implementation of approximately 110 kDSI, including comments, was implemented by hand as firmware for a single IC chip.
The validation team developed a large collection of VDM++ test cases that were executed using the VDMTools interpreter.Using the VDMTools test coverage analysis facility, it was possible to display test coverage information on the VDM++ model after executing the entire test suite.Here 82 % of the VDM++ model was covered, and the remaining parts of the model were manually inspected.In order to support this development with an extremely high number of test cases, the speed of the interpreter was improved by CSK Systems by more than a factor of 100.
From a quality perspective more errors were found in the early phases of the development than in other similar projects at FeliCa Networks.In total 440 defects were detected in the requirements and the specifications.Of these, 278 were directly a result of the use of VDM++.Of these, 162 were found by review of the model whereas 116 were discovered using the VDMTools interpreter with test cases against the executable VDM++ model.It is important also to note that, at the time of writing, no defect has been discovered since release.

CONCLUDING REMARKS AND FUTURE EXPECTATIONS
The figures derived using the COCOMO model productivity metrics in the TradeOne project are very impressive.From a cost perspective these results are outstanding from a first project using formal methods, in particular since most of the people involved had limited practical prior knowledge of formal techniques.In addition, the metrics for defect rates are also very encouraging.In the FeliCa Networks project it is felt that the first application using VDM++ did not change the overall cost expectations.However, the period for the specification development became longer than in any similar project in FeliCa Networks.This increased level of effort in early design stages is widely anticipated when formal methods are employed.It is important to manage the expectations of project management in this regard.FeliCa Networks feels that their main advantage in this project has been the improved quality and they expect that long-term productivity gains will follow later.
Communication is the key to software development (in particular between specification, implementation and validation teams), and VDM++ appears to have become a valuable communication tool.It is important that management, project owners and project members are fully aware of this and that they understand that it is not a method that will replace existing methods but rather one that needs to be used to complement other techniques such as UML.Finally, it is important that various methods and improvements are combined and established as part of the corporate and organizational culture.Thus, the next generation of the FeliCa Networks firmware is also currently being developed using VDM++.This is done primarily because of the improvements in communication between the different teams as well as the high quality resulting from this approach.
Several characteristics of the VDM technology have, we believe, contributed to its success in recent applications.These include the emphasis placed on developing robust tools which are open to linkages with existing tool sets supporting, for example, UML design.We have also focussed on analysis approaches, such as the use of test scenarios and test coverage, that provide a route into the use of a formalism without presenting a high initial hurdle to users.Our expectation is that this will lead on the use of tools supporting more advanced static analysis, proof support and test generation.
Significant extensions to VDMTools have been made in the area of distributed, embedded and real-time systems [22,23,24,25].With these in mind, it is expected that we will see more new applications in in domains such as automotive systems in Japan in the future.

Figure 1 :
Figure 1: Overview of the TradeOne system

Table 1 :
Size of TradeOne