Figure 1. OO Migration Schedule
Dwayne Read, Nautronix Ltd, Western Australia
dwayne@nautronix.com.au or dwayne@ss.com.au
Val Veraart, Murdoch University, Western Australia
vev@cs.murdoch.edu.au
The successful experience of Nautronix Ltd. in migrating to an Object-Oriented software development paradigm has been largely due to "human" factors rather than technological ones. A major advantage that has also accrued from the migration is a set of codified procedures that define the software development process. As with most process improvement efforts, empowering and encouraging the engineers to drive the migration process and establishing an identifiable "ethos" proved decisive.
Object-Oriented, Migration, Software Engineering Process, Methodologies
This paper describes the approach taken by Nautronix Ltd in migrating to an Object-Oriented software development paradigm and the software process improvement activities that were facilitated and resulted in conjunction with this migration.
Nautronix Ltd is an international company, undertaking software development in Western Australia and California, that provides products and services to the offshore oil and gas, and defence industries in the areas of :
Back in December 1993 we were using development environments that included UNIX, Windows 3.1 and some embedded platforms. Most development was done in C, Assembler and BASIC with some C++ on the PC. ISO 9001 procedures were used for the general control of engineering projects under which a variety of commercial and defence systems had been delivered. There was the need to continue to improve the engineering procedures and development environment, particularly for software engineering. We were developing software with little more than the basic coding tools such as compilers, debuggers, Borland's Object Windows Library (OWL) and Revision Control System (RCS) for source code control. The company employed four software engineers and four system engineers; who had no real experience with the Object-Oriented paradigm and little exposure to C++. Also lacking at that time was a connection to the Internet, a facility that was to have a major impact on our process evolution.
We believed that object-orientation would provide us with a well defined approach to addressing the requirements of complex system development. From our clients' perspective, and therefore ours, it was important that we deliver a quality product. The engineering domains that Nautronix Ltd develops for are composed of many real-world objects, eg sensors, beacons, etc and we felt that object-orientation would relate well to these application domains by providing a mapping from real-world objects to objects in the solution space. With the continuing move away from building everything from scratch to using Commercial Off-The Shelf (COTS) software components to shorten the development cycle and improve the economics of development, OO methods appeared to be supported by a number of reusable libraries that were appropriate to our application and development domains.
We were not using any Computer Aided Software Engineering (CASE) tools for analysis and design modelling, however it appeared to be an opportune time introduce such tools to assist with the automation and checking our yet to be selected OOA/D methodology. Since there was evidence of an increasing trend to object-orientation of most major software houses working on new applications, it seemed a sound, economic decision to invest in CASE tools for the emerging technology, rather than the older, structured ones. Initial investigations indicated that there were a number of tools providing support for a range of OO methods. We also anticipated that we would be able to employ skilled method engineers in our home base city of Perth, that expectation was able to be met after much searching and patience.
A further reason for choosing to migrate to OO was the technical interest in it that was being shown by our software engineers. Nautronix Ltd believes that their software engineers should work with the best available tools and techniques. Thus, with OO on the front covers of most major magazines and journals it was highly unlikely that our software engineers would remain satisfied using what they considered were out-dated methods. When taking all these reasons into account, our view was that migration to OO could provide Nautronix Ltd with a significant competitive advantage.
The adoption of the C++ language was the result of a careful evaluation and selection process rather than just accepting it as a common industry de facto solution. In addition to this, economic pragmatism could not be ignored in terms of training and tool costs, and future contracts. Since we were moving to object-orientation, it was important that the language implement the primary features of OO such as classes, inheritance, various levels of encapsulation and polymorphism. In our application domain C++ and Ada were both strong possibilities, however C++ is the more commonly used language, especially in Western Australia. Consequently, we believed that it would be easier to find software engineers with C++ skills, or to provide conversion from C language expertise. As a source of future, graduate software engineers, most of the local Universities now teach courses in using C++, but not Ada.
C++ was already in use in-house, although not in a disciplined OO paradigm. From reviewing literature it appeared that there were a number of existing, well-established tools offering CASE support, not just in the areas of diagrammatic modelling but also for code-generation and reverse-engineering from existing code to design notations. The range of development tools such as cross-compilers, debuggers and test-tools covered the range of platforms that we develop on, a number of reuse libraries were available at reasonable cost, there are many public domain utilities for C++ and, importantly, many COTS packages provided C++ Application Programmer Interfaces (APIs). Finally, where necessary, any assembly language procedures can be described by a C++ function prototype, and therefore can be called from C++ programs.
Nautronix Ltd spent six months evaluating a range of both OO methods and CASE tools that support the methods, assigning equal importance to both methods and tools through their potential to complement each other. The criteria that we applied to method selection included:
In 1994 we seriously evaluated eight different tools that support one or more OO methods. Tools were rejected due to cost, difficulty in use, incomplete support of the method(s) and platform limitations. The two final contenders were Paradigm Plus and Rational Rose/C++. After some initial experience with Paradigm Plus, and feeling that it was not a complete implementation of the methods it supported (in particular Booch), the final decision was to adopt the Windows version of the Rational Rose/C++. The UNIX variant of Rose was not considered a viable option due to lack of any additional features and it still having a basic PC style user interface for significant extra cost.
The overriding principle for applying the OO methodology was to introduce aspects of OO in digestible chunks via development projects. We deliberately avoided going in with the "big bang" approach and imposing a complete OO method from day one. Rather we mirrored the evolution of OO itself in a condensed form by coming out of the structured and entity-relationship design to basic object representation, through to fully attributed class, state and object diagrams and then more recently use-case analysis.
The first project to which aspects of OO were applied commenced in January 1994. Since we were still evaluating both OO methods and tools, the project was a paradigm-hybrid (which many books say you shouldn't attempt) in which some OO techniques were applied as their usefulness became apparent. This first project used Data Flow Diagrams (DFD) and Entity Relationship Attribute (ERA) modelling for analysis and preliminary design and then generic object dependency diagrams at the detailed design stage. For this project we also included the first of our process improvements - design walkthroughs. The most interesting aspect of this project was, however, the use of our CASE tool, Rational Rose, to reverse engineer the class hierarchy at the end of the project. This exercise produced some salutary lessons in what we didn't know about OO design yet!
In July 1994, the second OO project commenced. This used the CASE tool from the start, producing class, state and object diagrams but no interaction diagrams. In this project, it was found to be more efficient at times to make changes at the source level which was then reversed engineered back into the OOA/D model. This worked well and places extra weight on the ability of a CASE tool to perform this task. A third project commenced in July 95 and used the CASE tool from the start producing similar design models.
In October 95 a 4th project commenced, in reality the second phase of the 2nd project. In this project we have introduced the use of Ivar Jacobsons' use-case method. Since we don't have a tool for this, a couple of our engineers are experimenting with the use of Hyper Text Markup Language (HTML) to represent the interactions between elements of scenarios and from these use-cases calling Java prototypes of the related windows. This has much promise as there is the ability to re-use sub-scenarios at both the parent and leaf nodes of the scenario tree, work seemlessly across the Unix and Windows NT platforms, and as a result of using Java be "forced" to design the GUI objects in a more OO way.
Moving to a new paradigm also afforded Nautronix the opportunity to define a software process, in most respects a green-field situation, since there was previously little in the way of defined process activities for software development. The overall software development processes and the migration to OO were addressed together and are complimentary. That is, the procedures indoctrinated the OO method. By indoctrinating the OO method it provided a focus for both management and the engineers. The development of quality procedures was aligned to our corporate objective of delivering a quality product to our clients.
The overseeing Software Development quality procedure establishes that the Booch[1] methodology is the primary and preferred OO analysis and design method, the reference document for this is the Booch textbook, Object-Oriented Analysis and Design with Applications, 2nd Edition. The software development process also includes the following work instructions (WIs):
Nautronix Ltd is continuing to invest in appropriate tools to support our defined software development process. As well as the previously mentioned CASE tool and compilers for both UNIX and PC platforms we have purchased several tools to assist in building graphical user interfaces (GUIs) and a number of C++ reuse libraries, allowing us to use standardised functions across our projects, and a number of test tools to identify common errors. Rational Rose, understandably given its pedigree is the most complete implementation of the Booch method. Generally our adoption of reuse libraries has been successful, although our experience with the Booch reuse components was that they were too complex to use and they applied too much stress to the template facilities of the current generation of C++ compilers that we were using. However, our experience with reuse libraries from Rogue Wave has shown them to be solid, well-priced COTS and we are continuing to invest in tools from this company.
As mentioned in a previous section Nautronix Ltd had a total of eight software/system engineers at the beginning of the transition. We identified a need to train these existing staff as well as putting into place training for new staff joining the company and future contractors working for us. Careful selection of both full-time and contract staff was performed in line with facilitating the OO migration. Mentoring, both formally (ie via walkthroughs, etc) and informally (ie peer discussions at lunch, etc) where key to spreading the OO skills. Interestingly, most of the skilled C++ and OO engineers had gained their OO experience in either the United Kingdom or the United States of America. The majority of these employees were employed as C++ programmers and all had 2 or more years of experience in that role.
Existing staff members acquired their initial understanding from both books and several C++ videos which was then concreted by working with the more experienced OO engineers (mentoring). Later, they attended an extensive Booch OOA/D course, given by the providers of the CASE tool that we had purchased. When employing new software engineers Nautronix Ltd set the criterion of a minimum of 2 years C++ experience, preferably with some OO analysis and/or design experience, either formal or informal. We found that software engineers with an Ada background provided a definite advantage in moving to C++, most likely because Ada somewhat enforces a discipline in which the more OO-like features of the Ada language are used (notably - exceptions and generics). New graduates were selected from Universities that teach the C++ programming language.
Once the decisions on methodology and tool had been taken, Nautronix Ltd implemented the decisions not only by purchasing the tools, but also investing in training courses in the method and applying the method using the tool. We felt this was important if the tool were not to become either "shelf-ware" or to be used merely as an expensive drawing tool, as so many CASE purchases turn out to be. After exploring several avenues for training, our decision was to invest in bringing two experienced consultants from the company supplying the tool from the Eastern States to give a five day training course, two days on analysis and three on design. Two training courses were offered, since it was impractical to release all staff simultaneously to attend a single course. The costs of the courses were shared with two other Perth software engineering companies who were considering, or using, the tool and/or method. All software engineers plus some electrical engineers and technical managers (15 staff in all) undertook the training course. The final cost, in the vicinity of A$20,000 was a very worthwhile investment.
Our company does not believe that a single training course is sufficient incentive to our engineers to maintain and improve their skills. Skills evolution and enhancement is supported by a mentoring process that includes:
We believe that one of the major factors that has contributed to our success to date is the staff ethos that has developed. From its inception our staff have demonstrated a desire to learn, apply, share and improve on the process. This stems, we think from the level of involvement that they have had in developing the processes. The majority of process procedures have been suggested and written by the software engineers themselves, often codifying "their best practices" and taking it as a benchmark. As mentioned previously the company has supported their involvement through the provision of books and journal subscriptions on request and the provision of full internet access. The latter has resulted in access to a large amount of material being available on-line. Consequently, the staff have formed their own working group, to review the highly regarded (internally and externally) Effective C++ [2] reference book to revise our existing work instructions based on the advice of the books author.
One of the advantages that is often suggested to arise from the use of an Object-oriented paradigm is the ability to reuse. However, there are several disadvantages associated with reuse, for example the engineering costs of creating reusable components is higher, and the problems of describing, classifying and retrieving existing components. There is also the necessity to have skilled engineers that can truly create highly reusable frameworks and software modules more cost effectively than what can be purchased off-the-shelf. Nautronix Ltd is adopting a pragmatic approach to reuse and at this stage do not emphasis the reuse of internally created software. We have established a General Reuse Library and, rather than embark on a classification and retrieval scheme, reuse of this software is facilitated when software engineers are assigned to their next project. They take with them knowledge of the components they have created or worked with, and quite often they are able to reuse application design and some implementation software not specifically engineered for reuse. Thus, reuse of any of our code components becomes a bonus. Our major reuse effort comes from the use of the COTS libraries described previously and we see that this will continue in the future. Indications are that the cost of purchasing and updating these libraries is far less than building our own specific components. Given the domain in which Nautronix Ltd operates we feel that reuse of design through defining design patterns has the possibility for greater productivity gains and risk reduction in the future than code reuse.
How long does it take to migrate to OO? Many factors come into play apart form the definition against which one can say "we are an OO development house". The approach Nautronix Ltd has taken and the circumstances in which the migration occurred resulted in a migration to the essential aspects of OO in 18 months. The key factors were introducing aspects of the OO paradigm through projects (thus timings are determined by these); The evaluation and selection process of the fundamental OO method and supporting CASE tool; recruitment of C++ and OO experienced staff (again project resource requirements are a determining factor here). The "bottom line" of the OO definition for Nautronix Ltd is the fact that all software development applies (or attempts to) the selected OO methodology with the various review processes as per the quality procedures and that all software engineers have been trained and applied some aspect of the OO method at least once.
In hindsight, we think that we did not make any major mistakes. We could have been a little more selective about the videos we purchased, and showing them in group sessions, rather than requesting staff to take them home to view would have provoked a greater discussion of the issues that were addressed. We made an error in our original selection of the Booch components, but were able to recover from that, whilst not allowing one mistake to influence against trying other component libraries. The original evaluation of tools and methods was done by only one member of staff, and consequently took too long. With hindsight we should have created a small working group to undertake this task. Such a move would also have mitigated against any personal biases. We could have purchased one version of our favoured tool earlier, purely to use as a drawing tool, however the inherent dangers of such a strategy might have been to bias the outcome of the evaluation process and to set a precedent for purchasing unevaluated tools and adopting unevaluated methodologies.
Initially, most of our work procedures were created as hard-copy rather than being accessible on line. We believe that making them available both on-line and in hardcopy simultaneously would have been a more efficient and effective way to introduce them into our organisation. To achieve this now we can perform some basic word processor to HTML conversion through various tools but a total restructure is still required to have half-decent web pages that can be browsed from all work stations. Another aspect of information being available on-line relates to our software itself in that we did not realise the efficiencies that accrue from making our own reusable and application components on-line earlier, thus preventing occasional reinvention of the wheel, rather we relied on software engineers moving into new projects to take their knowledge of existing with them.
We will provide encouragement to the working group to keep refining the software engineering procedures, and to propose new books for them to work through where appropriate. We also plan to formalise our development with use-case if the current prototyping in HTML and Java proves successful. Given the success, to date, of COTS reuse libraries we will continue evaluating and adopting more libraries into our software process. We will also continue with converting the procedures to an on-line form. This will include, not only pure conversion to HTML form but the inclusion of links to actively cross-reference between documents and to enhance their perceived attractions by the inclusion of iconic interfaces and navigation bars. Finally, whilst we have selected and invested in the Booch OOA/D method we will evaluate the new Unified OOA/D method (Booch, Rumbaugh and Jacobson) and consider if, when, and how, we might migrate/update to that method.
The migration to an OO Paradigm for Nautronix has taken two years to date, and as with all continuous improvement strategies it will hopefully continue to improve. The essence of the migration occurred 18 months after we commenced the journey. The migration has worked remarkably well with the following key approaches proving successful:
Of all the facets that have given the biggest return on investment (effort), ethos stood out as the most critical. Both formal and informal approaches were/are used to establish an ethos within the engineering team . This ethos not only sustains the development environment that has been established but actively improves it to such an extent that one no longer has to "offer" the suggestions on better ways of developing systems.
The second most significant facet to the successful migration was obtaining the best staff "for the job". It pays to keep searching for the key people to facilitate the introduction of any new technology/approach. These key people coupled with formal and informal mentoring approaches enabled the most effective and enduring transition of staff to OO.