Pragmatic Application Building: Step by Step

emptyslowInternet και Εφαρμογές Web

12 Νοε 2013 (πριν από 3 χρόνια και 9 μήνες)

89 εμφανίσεις

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

Data

Access

Objects

(DAO)

Service

Struts

Actions

Struts

Forms

Business Objects

Service Interface

DAO 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