Pragmatic Application Building: Step by Step Jay Sissom Principal Systems Analyst Indiana University

Code public interface Presenter() { public String talk(); } public Jay implements Presenter { public String talk() { return “Welcome”; }

Agenda Overview Tools Architecture The Steps!

Quote "Things should be made as simple as possible, but no simpler.” Albert Einstein

Overview Developing Enterprise Applications is HARD! IU has developed 10+ Enterprise Applications in Java in the last 3 years Teams were made up of 1 to 10 developers Most developed using the Rational Unified Process RUP didn’t work well for our developers We were looking for a better way to build applications

Methodologies Problems with previous methodologies  Process driven  Difficult to keep up with changes  Time consuming  Inefficient  Sometimes less than satisfactory results  Inflexible – requirements do change

Overview A new Methodology was used to build the Pre-Disbursement Processor application We had a team of five to build this application  Project Manager  Lead Java Developer  Java Developer  Batch Developer  Project Consultant

Overview Other Libraries SIS Purchasing PDP Banks Direct Deposit Check Printing

Tools - Application Frameworks OJB Object/Relational Mapping Spring Framework Application Framework Struts User Interface Framework Log4j Debug Logging jUnit Testing Framework

Tools - Development Tools Java Java Virtual Machine Eclipse Integrated Development Environment MyEclipse Web/XML plugin to Eclipse Tomcat Servlet Container CVS - Source Code Version Control

Tools - Server Platform RedHat Advanced Linux - Operating System Sun JDK Java Virtual Machine Tomcat Servlet Container Apache Web Server

Architecture Key Objectives  Design highly functional and flexible software  Technology choices based on industry standard, open source, and “proven” solutions  Deliver applications via loosely-coupled components and services with clearly defined APIs  Leverage core “IT assets”  Emphasize code re-use/reduce redundancy

Service Based Architecture Services are loosely coupled Services have well-defined interfaces and are reusable Focus on business processes

Service Based Architecture Data Access Objects (DAO) Data Access Objects (DAO) Service Struts Actions Struts Actions Struts Forms Struts Forms Business Objects Service InterfaceDAO Interface

DAO - Data Access Object DAO’s talk to datasources to create, retrieve, update and delete data No business logic allowed All JDBC, SQL and/or OJB features should be contained within these objects No JDBC, SQL and/or OJB objects should be exposed Generally one DAO per entity

DAO Interface Java interfaces for DAO objects Services should only be aware of the interface, not actual DAO implementation The interface allows the use of Mock objects when testing

Service Used for business logic Call DAO’s to access data Should not contain SQL, JDBC or web specific information Each method will be a single database transaction

Server Interface Java interfaces for Service objects The interface allows the use of Mock objects when testing

Struts Actions Web user interface logic No business logic Call Services for business logic Generally should only call a single method in a service object

Struts Forms Only used when a user posts a form to the server All user edited fields are String properties Validation should just validate that fields have the proper format Validation in the Struts Action should call business logic Action Forms can contain Business Objects

Business Object A Business object is a Javabean (POJO) There should be a business object for each entity in the application Business objects can be used in any tier of the application In most cases, Business objects will be OJB data objects Entity specific business logic can be in Business objects

Isolation Each tier should be isolated from other tiers A tier shouldn’t have knowledge of how a different tier is implemented A tier should only communicate to another tier through a Java interface The Spring framework can handle dependencies so each tier is truly isolated

Dependency Injection Spring will pass dependant objects via calls set methods on managed objects so client objects don’t need to know details about how a dependant object works The dependencies are built into Spring’s context.xml file

Declarative Transactions Spring will manage transactions if they are defined in the context.xml No code is required to begin, rollback or commit a transaction No code is required to open and close database connections Spring handles this automatically Less code to maintain is a good thing!

Declarative Transactions Each method call into a service object is a transaction Spring automatically begins the transaction before the method call and ends it after If the method throws a runtime exception, Spring rolls back the transaction

Exceptions Runtime Exceptions  Use when situation is non-recoverable Checked Exceptions  Use when situation is recoverable Best Practice - fail as soon as possible  The closer the failure to the problem, the easier it is to find the problem Best Practice - fail big  Hidden failures make it more difficult to fix the problem

The Steps An Application is a collection of Use Cases One Use Case is implemented at a time Only develop functionality for the current use case - resist developing for future use cases

Step One: Review Use Case Review the Use Case  Do you understand it?  Is it complete? Work with functional people until it is clear and has all the information required for development

Step Two: Build a Prototype Users want to see what will be developed Most users can’t “visualize” a use case Update the use case based on the approved prototype, if necessary The HTML from the prototype can be used in your implementation

Step Three: Build an Outline Create all the objects/methods required for the use case Don’t implement the methods yet

Step Four: Test/Implement You can give this task to your less experienced developers Build unit tests first, then implement OR Build the implementation, then unit tests Make sure to do both

Step Five: Refactor Look for duplicate code Look for common functionality Look for unclear code Refactor to fix these problems Unit tests will make sure nothing broke

Step Six: User Testing Let the end user test the implemented use case They will probably find problems with the use case they wrote! Make sure this use case works the way the users want it to work

Next Steps Repeat these steps for each use case When there are no more use cases, your application is done! Refactoring and testing are the keys to this methodology

Quote - Revisited "Things should be made as simple as possible, but no simpler.” Albert Einstein

Summary The PDP application was built within the allotted time and budget It is possible to follow a simple methodology to build enterprise applications This is one methodology that can be used to successfully complete your applications