Nursing Information System Reengineering a Mobile Nursing Information Application

1. Nursing Information System Reengineering a Mobile Nursing Information Application Prepared by Larry LeFever For Software Engineering Seminar II Pace University White Plains, NY Spring 2003

2. - Technology employed: J2ME/MIDP - Targeted Device: Palm Pilot - Primary Purpose: Nursing students make note of physical assessments of patients on the mobile device, then save them to the desktop, where professors may review them - Prior versions developed by other development teams - Objective: current team (just myself) to enhance the project to enable multiple patients’ data to be managed on the device at once; and hopefully fix performance-problems

3. - Results: new use-cases implemented: - New Patient - List All Patients - Select Patient By ID - Delete Patient By ID - Issues: Lack of “Pattern-Awareness” causing: - robustness problems (memory-errors) - UI-performance problems - scalability problems - code-maintenance problems - “code-rot” - Recommendations: - radical re-design, applying certain GoF Design Patterns

4. Unfortunately, the NIS project is an excellent example of the adverse consequences of a lack of “pattern-awareness” in software-design. There has been anticipation of the project soon nearing completion and being ready for release and possible marketing. However, the v1.0 codebase lacks the design-sophistication required for it to be production-ready. The “bugs” in the latest version are attributable to design-errors more than to implementation-errors.

5. So, the central theme of this presentation is not: - developing software for mobile devices Or - developing software for the healthcare field

6. Design Patterns

7. Best Practices

8. What is a “Design Pattern”? “Christopher Alexander says, ‘Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.’[AIS+77, page x]” [GOF;2]

9. Designing for Change: “The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements … unanticipated changes are invariably expensive … Design patterns help you avoid this by ensuring that a system can change in specific ways.” [GOF; 23-24]

10. Loose Coupling: “Each design pattern lets some aspect of system structure vary independently of other aspects, thereby making a system more robust to a particular kind of change.” [GOF; 24]

11. Toolkits vs. Frameworks: Toolkit: - code-reuse - OO subroutine-library Framework: - design-reuse - “captures design-decisions … common to … application domain” [GOF;27]

12. A software-design maxim of my own: For all but the simplest software projects (such as single-class single source-file ad-hoc utilities), write every application as a reference-implementation of a new framework. Later, others will have the option of using only the framework or substituting their own components for some of those of your reference implementation.

13. Anti-Patterns: Recurring design-errors, expressed abstractly, much as are design-patterns; typically associated with one or more design patterns cited as recommended fixes for the errors in question.

14. Main NIS v1.0 Anti-Pattern: “The Leak Collection” [TATE; sec 6.4]: “Whenever we have a collection with a long life cycle that has the potential to contain objects that aren’t removed, we have the possibility of a memory leak.”

15. “Memory Leaks” in Java? Yes. Whereas in, e.g., C++ a memory leak occurs when one loses one’s last reference to an allocation, in Java, memory leaks occur when a non-obvious reference is accidently retained.

16. Relevant “Leak Collection” Scenario: “User interfaces: Most modern user interfaces are collections of windows and components. Many times, these potentially massive collections have persistent anchors … Whenever a user interface is attached to an anchor with a long life cycle, (Java-style memory-leaks are possible).” [TATE; sec 6.4]

17. Relevant Anti-Pattern “Force”: “References are in clusters, so the impact of leaks is greater. … If you forget to remove a critical reference to a single object, it may reference many other objects. A Java interface developed with the Swing component library can have references to dozens or even hundreds of child classes. Further, since the classes also have back pointers, references to a child class can make an entire user interface tree reachable.” [TATE; sec 6.2.2] http://developer.java.sun.com/developer/Books/javaprogramming/bitterjava/bitterjavach06.pdf

18. … the GUI presents only the information that the user requests to see; the BOOP layer only keeps in memory the relationship and structure logic of the system currently in view; and the DataStorage layer preserves all other information on file, writing systems that are coming “out of view” to file, and reading and building the new systems as they are requested to come “into view.” The dynamic presentation abilityallows the NIS to exist on a small footprint device.The dynamic businessand datastorage abilityallows the program to create a physical assessment of unlimited size and variation – so the program can evolve and adapt to the user’s needs. [NIS1;pg.1.3]

19. @files = glob("*.java"); foreach $file (@files) { open(INFILE, $file) || die "could not open " . $file . "\n"; open(OUTFILE, ">out/$file") || die "could not open out-file " . $outDir . "\\" . $file . "\n"; print STDOUT "******* processing " . $file . " ********\n\n"; $currClass = "NoneFound!"; while(<INFILE>) { if(/class\s\s*(\w\w*)/) { $currClass = $1; print OUTFILE; next; } # (... so, it's not a class-decl line...) if(/\s*(public|private|protected|static|synchronized|final){1,3}\s+\w+\[?\]?\s+(\w+)\s*\([^\)]*\)\s*{/ || /(\s*)(${currClass})[^{]*{/) { $currMeth = $2; $_ .= "if(NISApplication.DEBUG) System.out.println(\"in " . $currClass . "\." . $currMeth . "\");\n"; print OUTFILE; next; } …

20. in BodyTouch.BodyTouch in BodyTouch.initializeData in PatientInfo.PatientInfo in NTextField.NTextField in NTextBox.NTextBox ... in NTextBox.NTextBox in Body.Body in BodyBuilder.BodyBuilder in PatientInfo.PatientInfo in NTextField.NTextField ... in AnatomySystem.setAssessment in AnatomySystem.setPhysicalExam in AnatomySystem.setTreatmentPlan in Body.addAS Finished the building ======================================================= lefever@COMPUTER ~/emulator-win $ egrep -c '([A-Za-z][A-Za-z]*)\.\1' STDOUT_2.txt 377 <==== wow! 377 ctor-calls on start-up!

21. 2. Reusing and recycling objects to avoid the memory expense of new object creation. For example, instead of creating 15 List screens, one for each anatomy system (head, neck, etc.), only one instance of the GList class is created and it is redrawn and rewritten as needed. [NIS1; pg.1.9] 3. Releasing resources once they are used. This includes setting objects to null and calling the system garbage collector (System.gc()) when necessary, allowing memory to be freed up for new operations. [NIS1; pg.1.9]

22. private class DataTimer extends TimerTask { NISApplication nisa; Display d; public DataTimer(NISApplication nisa, Display dis){ d = dis; this.nisa = nisa; } public final void run(){ BodyTouch BT = new BodyTouch(nisa, d); BT.initializeData(); BT.setDisplay(d); d.setCurrent(BT); // !!!! Object-model “anchored” in display !!!! //finally, cancel this timer task? cancel(); } }//end DataTimer From: NISApplication.java

23. public void generateList(String ASname) { if(NISApplication.DEBUG) System.out.println("in BodyTouch.generateList"); bbuilt = BB.returnBody(); // Getting already loaded “object-model”!! GL = new GList(display); // repeatedly instantiating UI-object !! try { AnatomySystem as = bbuilt.getAnatomySystem(ASname); //***STEN ADDED CHANGE HERE-CALL TO // buildGList takes String!! GL.buildGList(as, ASname); }//END try catch (Exception ignored){}//END catch backtoBody = new Command("Body", Command.BACK, 0); GL.addCommand(backtoBody); GL.setCommandListener(this); }//END generateList From: BodyTouch.java

24. AxillaeBreastsReviewofSystems.addCondition(DoesBSERegularly);AxillaeBreastsReviewofSystems.addCondition(DoesBSERegularly); AxillaeBreastsReviewofSystems.addCondition(WantsBSEInformation); … AxillaeBreastsReviewofSystems.addNTextField(LastMammogram); … AnatomySystem ABAS = new AnatomySystem("Breast/Axillae",AXILLAEBREASTS); ABAS.setReviewofSystems(AxillaeBreastsReviewofSystems); … ABAS.setTreatmentPlan(AxillaeBreastsTreatment); B.addAS(ABAS); //voiding the objects - hopefully to save some space DoesBSERegularly = null; // ineffective! Not setting ref-counts to zero WantsBSEInformation = null; // since, per preceding lines, objects have been Tenderness = null; // passed to other objects held long-term BreastSurgery = null; // in the “object-model”, anchored in the display NippleDischarge = null; SkinLesion = null; SurgicalScars = null; … return B; From: BodyBuilder.java

25. Principal Recommended Design Patterns: - Flyweight: - reuse, in most cases, one of each relevant type of widget, prepping each with relevant data from a domain-object (in some cases, one needs to maintain a pool of a given widget-type, to be able to display multiple at once) - Visitor: - implement the RecordWriter as a Visitor - keep track of “dirty” domain-objects - have RecordWriter pass itself to each “dirty” domain-object, to have latter persist itself.

29. Thank you