360 likes | 494 Views
Pragmatic Application Building: Step by Step. Jay Sissom Principal Systems Analyst Indiana University jsissom@indiana.edu. Code. public interface Presenter() { public String talk(); } public Jay implements Presenter { public String talk() { return “Welcome”; } }. Agenda.
E N D
Pragmatic Application Building: Step by Step Jay Sissom Principal Systems Analyst Indiana University jsissom@indiana.edu
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 Banks Purchasing PDP SIS Direct Deposit Libraries Other Check Printing
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
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
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
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 Interface DAO Interface Service Based Architecture Data Access Objects (DAO) Service Struts Actions Struts Forms Business Objects
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