Pragmatic Application Building: Step by Step

1. Pragmatic Application Building: Step by Step Jay Sissom Principal Systems Analyst Indiana University jsissom@indiana.edu

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

3. Agenda • Overview • Tools • Architecture • The Steps!

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

5. 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

6. 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

7. 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

8. Overview Banks Purchasing PDP SIS Direct Deposit Libraries Other Check Printing

9. Tools - Application Frameworks • OJB 1.0 - Object/Relational Mapping • Spring Framework 1.0 - Application Framework • Struts 1.1 - User Interface Framework • Log4j 1.2 - Debug Logging • jUnit 3.8 - Testing Framework

10. Tools - Development Tools • Java 1.4 - Java Virtual Machine • Eclipse 3.0 - Integrated Development Environment • MyEclipse 3.8 - Web/XML plugin to Eclipse • Tomcat 5.0 - Servlet Container • CVS - Source Code Version Control

11. Tools - Server Platform • RedHat Advanced Linux - Operating System • Sun JDK 1.4 - Java Virtual Machine • Tomcat 5.0 - Servlet Container • Apache 2.0 - Web Server

12. 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

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

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

15. 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

16. 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

17. 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

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

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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!

25. 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

26. 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

27. 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

28. 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

29. 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

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

31. 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

32. 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

33. 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

34. 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

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

36. 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