Date post: | 21-Dec-2015 |
Category: |
Documents |
View: | 220 times |
Download: | 0 times |
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 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