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

Other

Libraries

SIS

Purchasing

PDP

Banks

Direct Deposit

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 Based Architecture

DataAccessObjects(DAO)

DataAccessObjects(DAO)

ServiceService

StrutsActionsStruts

Actions

StrutsFormsStrutsForms

Business ObjectsBusiness Objects

Ser

vice

Inte

rfac

e

DA

O In

terf

ace

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