2008:Orion:Report

CSI Academy Concerto Portal Development

Mark Alan MacKinnon Gardiner Department of Electrical and Computer Engineering, University of Auckland. mgar059@ec.auckland.ac.nz

Abstract

Concerto Portal is a web-based system for integrating hospital information systems. Work was carried out for Orchestral Developments Limited through the Centre for Software Innovation Academy. The work centred on code refactoring for the Concerto medical applications portal, and extended to test automation and prototyping of new unit testing frameworks. The work was carried out in a team of two students from the University of Auckland. Development was mainly done with Java, however work was done with perl, ruby, and XML.

1. Introduction

1.1. Background Orion Health produces a range of software solutions for the integration of medical applications. Concerto is a front for many of these programs, and provides a web interface that can be used by different rolls of hospital staff, to access information that is relevant to them, and provides functionality for sending messages and organising patients. The concerto portal is written in Java and uses a wide range of frameworks and third part code libraries. As the Java language has evolved, new language features have been introduced which provide make code easier to write and read. In order to reduce development time and increase the understandability of their code, Orion Health has set their coding standards to conform to Suns Java 5 standards.

1.2. Objectives The main objective of this project was to bring the Concerto Portal inline with the Java 5 standards. This includes language features and enhancements such as generics, enhanced for loops, and autoboxing. The secondary objectives were to migrate the unit testing framework from JUnit to TestNG, and finish by helping the portal team with performance testing.

1.3. Overview Refactoring of the Concerto Portal was archived with the aid of some common programming tools, such as a Subversion code repository, the Eclipse IDE, and even a few scripts we wrote (using regular expressions in perl,) for replacing parts of code. We introduced generic types, were it was possible to do so, and replaced many loops which used iterators, to instead use the enhanced for loop construct. We spent a lot of time ensuring the correctness of our code with the help of unit tests, automated sanity tests, and general smoke tests.

2. Project Management

This project was carried out under the guidance of the CSI Academy. This is a managed internship program which comprised of a team of two Students, Nicholas Irvine and myself, an industry mentor Simon Leigh, and an academic mentor Dr. Christof Lutteroth. The program involved weekly progress reports, where progress was documented on a university ‘wiki’ page. There were weekly meetings where students from different teams attended seminars on industry and academic development.

Work on the Concerto Portal was carried out at Orion House in Mt Albert. The Auckland office is home to around 150 staff. Orion Health utilises an open plan work environment where most of the software development is done in two rooms on the ground floor. These rooms have around 80 people in one and 40 in the other. We were situated in the smaller of the two rooms and were amongst the ‘Package Integration and Testing’ and ‘Orders’ Teams. Each of us had a desk with a computer and network access. We were able to communicate with our industry mentor and developers in the other room by using Skype and an intranet.

The Portal team has a couple of weekly meetings, in which weekly progress and direction is discussed. We also attended meetings where we heard head a clinician’s perspective of using Concerto Portal and information about how new frameworks would work with Concerto Portal.

3. Concerto Portal Concerto Portal is one of a few software products produced by Orion Health, which make up a software solution for organising hospital information systems. Concerto Portal is a web-based application written in Java. Many hospitals have a range of programs and databases they use, from looking up patients x-rays, lab results, or immunisation records. Each of these programs may have to be run separately and requite a different login. Not only is this a hassle, but this can be slow and lives are literally at risk. Concerto Portal acts as a centralised interface for logging in and using these different systems.

With Concerto, clinicians or doctors can log in to the system once, and the authentication can be shared amongst the different medical applications that user has access too. Where in the past, a clinician may have had to search for a patient on one system to get a few details such as their medical history, and then switch to a different system to find their lab results, concerto can allow the clinician to search for the patient once and can switch between the patients documents and lab results without having to switch programs. Concerto also provides a consistent interface between these applications, which make finding information faster and more intuitive. Concerto even supports messages between users of the system and the interface can be customised to the specific needs of each hospital and user.

4. Code refactoring 4.1. Concerto Portal Refactoring is the process of taking code and making it easier to read and understand, without changing what it actually does. Concerto Portal is a relatively mature piece of software, and as such was in development before many of the improvements, which have been made to the technologies it uses. Java for example is constantly evolving and it is important of the Concerto Portal code base to keep up with the latest standards and frameworks. Our task was to refactor the Concerto Portal code base so that it made use of the new language features that were introduced with Java 5. This would help improve the readability and understandability of the code, making it easier for developers to modify and maintain in the future.

A few of the features that were introduced with Java 5 are Generics, Enhanced for Loops, Autoboxing and Annotations.

4.1.1. Generics Generics was the most time consuming language feature to implement. There is frequent use of collections, sets, and maps within the concerto source. Without generics it is hard to know what is in these collections. They could be a list of objects representing patients, or a map of objects containing both message objects and user objects. The danger with this ambiguity is when a programmer tries to get a message object from a list of patient objects, the Java virtual machine is unable to get any message related information out of a patient object. As this operation is just not possible, it will stop Concerto from functioning correctly. To fix this, instead of having raw collections of information, for example;

We could look through the code to find where the collection is being created or added too and see what kind of objects are being put into the collection. Once we have determined that the collection only contains DeliveryMethodBeans, we can add a tag to the collection to notate what kind of objects are stored within it i.e.

This allows the compiler to check at compile time, that the types of objects going into collections are the same as the type of objects being taken out of those collections. In this case, the compiler can check that deliveryMethods is never taking in anything but instances of DeliveryMethodBeans. Wherever we take an object out of deliveryMethods in the source code, there is the added perk that we do not need to convert the object coming out of the collection with a cast. Casting takes up space in the code as well as the danger of getting the type of object wrong. We found that many variables which were created, just to hold the variable coming out of a collection, could be removed. This is because the added context created by generics made it clear what kind of objects were in the collection and there was no longer a need to cast the object coming out of that collection. The code is easier to expand on because wherever a collection or class of objects which could contain specific types of objects are defined, the developer can see what is in that class without searching through code.

4.1.2. Enhanced for Loop Enhanced for loops were used to reduce the need for iterators, which can be prone to errors and take up a large amount of code. Iterators are also often hard to read and understand. This loop using an iterator:

can be re-written to use the enhanced for each loop so that it becomes: The enhanced for each loop is much easier to understand, and can even be read naturally as ‘for every DataAppenderEntry using the name entry within dataAppenderEntries’. It also uses less code leaving less room to make mistakes. There were some cases where we were unable to implement enhanced for loops however. An example of this is where non-generic external libraries were used. The classes that were used to return queries are an example of this. As we could not give an object type to the elements coming back in the list from the query, we were unable to for-each over an implementation which may not extend iterable.

4.1.3. Autoboxing Autoboxing allowed us to remove redundant ‘toObject’ methods. Before Java 5, primitive types could not be added to a collection, and if you wanted to put primitives into a collection, you hade to first convert them to their corresponding object class. For instance an ‘int’ would be converted to an ‘Integer’ and a ‘char’ would become a ‘Character’. With Java 5 this is no longer necessary, and as such previously needed ‘toObject’ methods could be removed.

4.1.4. Other changes Other minor changes we made to the Concerto code base includes: moving blocks of code, such as the ‘equals’ method, up the class definition hierarchy so that a single super class could implement equals. This would then be inherited by all child classes and removed some duplication of code. This also means that if the equals method was to be changed, it would only have to be modified in one place and all the child classes would be changed too. Unfortunately, we found that due to the desired behaviour of the ‘equals’ method, where it only compares objects of the same class, the ‘equals’ methods did have to be re-implemented in many child classes. Annotations were automatically added where methods overrode super class methods. An example of this being the ‘equals’ method again. Another place changes had to be made were in the ‘preDelete’ methods. These methods ensure that when an object, such as a user on the system, is deleted, every object belonging to that user is deleted before the user is deleted. This came about due to a change in the structure of all the objects which are persisted to the database. This method was also reverted to its original implementation eventually.

4.2. Portal Interface Removal After converting the Portal code to use Java 5 language features, the next task for us was to remove superfluous interfaces. Every object, which is persisted to the database, has an interface associated with it. These are identified by files ending in Bean.java. The Bean interfaces exist so that it may be possible to switch persistence implementations. As future implementations are likely to be implemented with hibernate or a combination of plain Java objects combined with annotations. Either of these future approaches would mean that the interfaces are not essential, and are just unnecessarily cluttering up the code base. With the help of perl scripts and the Eclipse IDE, we removed all the bean interfaces and made all references to them point to their concrete implementations.

4.2.2. Automated changes This task was made easier by the use of a perl script we made. The script was first made to search through all the Java source files and replace old copyright statements with new ones. The script uses a regular expression to identify old copyright statements (of which there were a few variants) and replace them with a standardised new statement. This same file then proved useful a few more times and was used to change class signatures as well as modify references from Bean interfaces to their concrete classes.

5. Testing 5.1. Unit tests A significant amount of our time was spent running unit tests and tracking down the specific errors they found. The Concerto Portal has suites of tests written in JUnit. JUnit is a unit testing framework for Java. Once we had modified concerto to be largely generic, we ran the unit tests to ensure none of the functionality was broken. The unit tests were broken up into suites and each suite tested a package of the code base. Many bugs were found, such as problems with ‘preDelete’ and ‘equals’ methods, class cast exceptions from adding generics, and there were even places where changing from an iterator to an enhanced for loop lost some logic. Examples include the use of an incrementing variable i.e. i++, in the loop constructor, as well as ‘resolveRefrence’ calls.

5.2. JUnit and TestNG One of our goals was to change the unit testing framework to use TestNG as opposed to JUnit. TestNG provides benefits such as grouping of tests where the setup and teardown code is only run once. This would be beneficial to Orion Health because actions like creating a database connection would only have to be down once, greatly improving speed. TestNG also has other nice features such as use of annotations and ways of grouping tests. Some prototyping of TestNG tests was done, however the task appeared to be to time consuming and work was instead directed towards more modifications of the Concerto Portal source.

5.3. Automated sanity tests. In the first week of work at concerto, most of my work was focused on Orion Health’s automated testing framework. Orion Health has I lengthy set of use case tests that were used to manually test the Concerto Portal. In the past, this has taken a lot of time, and it is a process that very suited towards automation. Orion Health considered many different automated testing frameworks before deciding to make their own. Orion created WATFO(Web Application Testing For Orion). WATFO is programmed in ruby and uses the WATIR framework for driving an Internet Explorer browser. WATFO aims to abstract the WATIR API and ruby, by using XML to create tests. This means that very little knowledge about either of these is required to create a test for WATFO. WATFO is still new however and quite a lot of work was done trying to write XML components, which sit between the WATFO tests and ruby code, for use by XML tests. While working with the concerto code base, we used WATFO to automatically open a browser and drive Concerto to test that it was working at a user level.

6. Tools and Frameworks 6.1. Java Concerto portal is written in Java. There are many good reasons for this. Java is interpreted and as a result can run on many different platforms. Concerto can run on Linux, Mac OS, Windows and others. The main benefit for Java is that there is a lot of support for it. Concerto uses many different open source frameworks to reduce the amount of development required. The Application Programming Interface for Java is rich and includes libraries which provide functionality for programs running on an application server. Many tedious programming features such as memory management and garbage collection is handled natively by java, and there also is plenty of support in the form of tools.

6.2. Eclipse Eclipse is an Integration Development Environment for Java, which was originally created by IBM. It is now a free tool which is widely used and supported. We used it extensively throughout our work at Orion Health. We used eclipse to identify parts of the code base which needed refactoring. Eclipse generates a list of compiler warnings that identify what parts of code could be potentially unsafe and where generics could be added, and even underlines the specific parts of the code. There was the possibility for eclipse to attempt automatic refactoring, however this was largely not useful. There are a wide range of keyboard shortcuts and an inbuilt debugging interface that was useful. From within eclipse we could compile and run Concerto, and even the ruby WATFO framework and tests.

6.2.1. Ant Ant is similar to the more common ‘make’ program, and is used to automate the build process for compiling Concerto. Concerto is made up of many different packages and libraries, having Ant manage these made building Concerto much simpler. Ant uses an XML file that contains a list of different actions that can be preformed. We used it to build the mapping files for objects to be persisted in a database, for cleaning the database, running unit tests, and for compiling Concerto.

6.2.2. Ivy Ivy is a dependency manager for java. Ivy works with Ant to resolve references to libraries. These dependencies are automatically resolved at build time. There is an eclipse plugin we used called IvyDE, which generates libraries, and allows them to be resolved within eclipse.

6.3. Hibernate Hibernate is used within the Concerto Portal to simplify the process of taking Java Objects and storing them in a relational database. Within the database, tables correspond to an object and the columns correspond to the fields within that object. Hibernate allows the developer to forget about most of the programming needed to persist objects. SQL is automatically generated, and hibernate can control the way objects are cached and synchronised between the database and memory.

6.4. JMX Concerto is designed to work with multiple different systems. JMX or Java Management Extensions, allows administrators to connect to a running Concerto instance directly and manage the system. When concerto starts up it goes through various stages or operability. It may not completely start up if it does not have a fully set up database for example. JMX is used to allow a connection into concerto for managing it, if it has not successfully started. We used JMX to set up the database to get concerto into a runnable state.

6.5. Subversion The Concerto Portal code base is stored and controlled by a subversion repository. This allowed us to synchronise the changes we were making in different areas of the code and work on it simultaneously. A major benefit from this was the ability to access the repository from within eclipse. We used an Eclipse plugin called Subclipse. Subclipse allowed us to compare the changes we made with previous versions in the repository. These changes would be highlighted and we could easily see if we had lost some code in the changes or allow us to revive methods we had removed.

6.7. Orion Intranet Orion has a company wide intranet with tools for communication, getting information, management, tracking bugs, and accessing code.

6.7.1. Zimbra Zimbra is open source email server software which caters for email access and meeting or document collaboration. We used Zimbra to organise meeting times with our industry mentor, and it would notify us about events such as the monthly Concerto Group meetings. 6.7.2. Confluence Orion health has a great wiki culture. All the information from the development teams and management are available and regularly updated. By documenting all the work that is done in the wiki, anyone within the company may, Same as the uni wiki we are using for CSI. First week, getting up to speed with the products. Install information. Should have all information you need. Latest updates 6.7.3. Jira Jira is a web interface which provides bug tracking, issue tracking and project management functionality. 99. http://www.cs.auckland.ac.nz/research/groups/ict/ict.php?module=home http://www.orionhealth.com/ http://en.wikipedia.org/wiki/Refactoring http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html http://confluence/display/Conc/Test+Automation http://jira/browse/CPO-4971 http://en.wikipedia.org/wiki/JUnit http://en.wikipedia.org/wiki/Apache_Ant http://en.wikipedia.org/wiki/Apache_Ivy http://www.practicalembeddedjava.com/language/WhyUseJava.pdf http://www.zimbra.com/ http://en.wikipedia.org/wiki/Java_Platform%2C_Enterprise_Edition http://confluence/display/Conc/Overview