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, which aid in the integration of medical applications and information systems. Concerto is a front for many of these programs, and provides a web interface that can be used by different roles of hospital staff, to access information that is relevant to them, and provides functionality for sending messages and organising patients. Layering on top of existing data structures, a unified view portal solution can provide single view capabilities for physicians, providing simplified, real-time access to a selected patient's clinical information, wherever it may reside [1]. 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 additionally 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 existing 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 achieved 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 [2] 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’ (or PIT) 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.

Figure 1: Concerto Portal 6.6

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. Currently Concerto Portal is comprised of over 150,000 lines of code. The Java programming language 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 [3].

4.1.1. Generics

Adding generics was the most time consuming of the language features 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 developer 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 reference to 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 that 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. For example, this loop using an iterator,

may 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 wrapper 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. Miscellaneous 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, with the use of source formatting and styling templates in Eclipse, were automatically added where methods overrode super class methods. An example of this is the ‘equals’ method again. An ‘@Override’ was added above the method signature to signify that the method had to override a defined method from a super class.

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. When we made changes to part of the class structure, these methods stopped functioning as they were expected to, and had to be altered. As we made further changes to the code base, we eventually reverted these methods to their original implementation.

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.

Figure 2: Eclipse JUnit Plugin 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 of this last point include the use of an incrementing variable i.e. i++, as well as a standard iterator in the loop constructor, as well as ‘resolveRefrence’ calls. Usually a loop would have only one value, which changes for each iteration of a loop. In Concerto Portal there exist loops which make use of an incrementing loop count as an iterator passes over a list. These were easy to miss when refactoring (ergo the added visibility of this behaviour is one of the benefits of refactoring,) and the unit tests helped us to catch these mistakes.

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 a 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 [4]. 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. Both of these XML files make up WATFO tests and the components help to abstract the ruby implementation.

While working with the Concerto code base, we used WATFO to automatically open a browser and drive Concerto. This ran through the previously manual use case tests, to test that Concerto Portal 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 compiled to platform independent byte code, which is then interpreted by a virtual machine. As a result, this code can run on many different platforms. Concerto can run on Linux, Mac OS, Windows and others. The main benefit for using 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 [5]. Many tedious programming features such as memory management and garbage collection is handled natively by java, and there is also plenty of support in the form of tools.

6.2. Eclipse

Eclipse is an Integrated Development Environment for Java, which was originally created by IBM. Figure 3: Eclipse 3.3 IDE Eclipse is now an open source tool [6], 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 [7], 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 [8]. 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 [9]. 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 of 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. Figure 4: Eclipse Subclipse Plugin 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 [10]. Figure 5: Zimbra 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 on a Confluence wiki. Figure 6: Confluence Wiki By documenting all the work that is done in the wiki, anyone within the company may, comment on or improve ideas. We found the wiki (or Woki, Where Orion Keeps Information) useful for understanding the tools and frameworks we used, as well as how to fix problems we came across which had been encountered by others.

6.7.3. Jira

Jira is an issue and bug tracking portal, which Orion Health uses to assign units of work. Much of the development was focused towards resolving and managing tickets which had been raised in Jira. Figure 7: Jira Bug Tracking Portal We used Jira to find out information on problems we were trying to fix, such as removing interfaces from the Concerto Portal. We also used Jira for issues such as requesting a product license for use while working on Concerto.

7. Conclusion

As a result of our work at Orion Health, the Concerto Portal code base has wide use of generics and Java 5 language features. Interfaces, which were cluttering up the code base unnecessarily, have been removed and future development has been made potentially easier and less time consuming.

7. 1. Concerto Portal Accomplishments

During my time working at Orion Health, our CSI Academy team succeeded in refactoring most of the Concerto Portal code base. I gained valuable experience working with Java, and all the development tools, which are used to coordinate a software product of Concerto Portals scale. A large amount of specific experience was gained in the use and implementations of the Hibernate framework for persisting Java objects.

7. 2. Perl Accomplishments

We successfully created a reusable perl script for string replacement in Java source files. Using this we updated all the copyright statements within the Concerto Portal source files. Using this script, we reduced coding time by automating some repetitive refactoring actions.

7. 3. Testing Accomplishments

Using the ruby programming language, XML, and the WATFO framework, I developed a couple of tests and components for driving an instance of Concerto automatically. While working in the Portal team, I used this experience to fix broken WATFO tests for specific use on the implementation I was working on.

8. Acknowledgements

I would like to specifically thank:

Nicholas Irvine (Second Intern on this project).
Simon Leigh (Concerto Portal Development Team Lead).
Dr. Christof Lutteroth (Academic mentor).
Richard Li (Project Manager).
Orion Health.
CSI Academy.

9. References

[1] “Concerto™ Physician Portal for Organizations”, retrieved 18 February 2008, http://www.orionhealth.com/concerto/organizations.htm

[2] “Welcome to the CSI Academy”, retrieved 20 February 2008, http://www.cs.auckland.ac.nz/research/groups/ict/ict.php?module=home

[3] “Enhancements in JDK 5”, retrieved 20 February 2008, http://java.sun.com/j2se/1.5.0/docs/relnotes/features.html

[4] “Automated Testing”, retrieved 20 February 2008, http://confluence/display/Conc/Test+Automation (Orion’s Local Intranet)

[5] “Java Platform, Enterprise Edition”, retrieved 20 February 2008, http://en.wikipedia.org/wiki/Java_EE/

[6] “Eclipse (Software)”, retrieved 20 February 2008, http://en.wikipedia.org/wiki/Eclipse_IDE/

[7] “Apache Ant”, retrieved 20 February 2008, http://en.wikipedia.org/wiki/Apache_Ant/

[8] “Apache Ivy”, retrieved 20 February 2008, http://en.wikipedia.org/wiki/Apache_Ivy/

[9] “What is Hibernate”, retrieved 20 February 2008, http://confluence/display/IntDev/Hibernate/

[10] “Zimbra – About Us”, retrieved 20 February 2008, http://www.zimbra.com/about/

2008:Orion:Report