• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

First steps in designing a Java/J2EE application

 
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,

I would like to design a full-blown application with a web interface, using JSP, Servlets, Spring MVC and JDBC. I am confused if I should start by deciding on the database tables required by the application or if I should start by thinking about my classes, their attributes and their methods, and then decide on the tables required?

Thanks.
 
Rancher
Posts: 43011
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you done the detailed requirements analysis yet? That should be the first step, followed by the architectural design. Determining classes and tables would come later.
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks a lot, Ulf. I have not done any requirements analysis yet.

That should be the first step, followed by the architectural design



By architechtural design, do you mean 'spec'ing out the different layers required in the application and deciding on how the data is going to be persisted and retrieved and how it is going to be passed on between the different layers(like deciding whether I will be using an ORM tool or a dataaccesslayer, and whether I will be using Web services etc. ?)
 
Ulf Dittmer
Rancher
Posts: 43011
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I have not done any requirements analysis yet.


In that case you can't even decide on an architecture yet, because you don't know what that architecture will have to support.

By archetechtural design, do you mean 'spec'ing out the different layers required in the application and deciding on how the data is going to be persisted and retrieved and how it is going to be passed on between the different layers(like deciding whether I will be using an ORM tool or a dataaccesslayer, and whether I will be using Web services etc. ?)


By and large, yes. Deciding on an ORM tool is an implementation decision, though. That sort of thing is decided last, after the architecture is in place.
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay, thanks a lot. I will work on those things.
 
Author and all-around good cowpoke
Posts: 13078
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You might want to take a look at the idea of Use Cases to document your requirements.

If you can't explain your requirements documentation to a potential user, you have not finished.

Bill
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, William and Ulf. I am planning to create a banking application. Here are the requirements:

A bank can have any number of customers, and each customer can have multiple checking and/or savings accounts.
Checking: The customer can open or close a checking account. He can deposit or withdraw money. The account balance cannot be negative. If a customer tries to withdraw more than he has in his account, the transaction will be declined
Savings: The customer can open or close a savings account. The minimum balance in the account should be $100. This account accrues interest at 5% compounded daily.
Opening an account: The customer will need to provide some personal details, and have a minimum balance of $100 to open either account.
Closing an account: The customer can close his account at any time. The money has he has in the account at that point will be returned to him. An account once closed can never be reopened.

Eventually, I want this to be a web application and also have persistence, but I am new to all of the these - OO design, designing web application, and connecting to database. So, having written down the requirements, should I just design the system from an OO perspective without taking into consideration the front end (GUI or web) and the back end? The general advice I've got on these forums previously is that an application should work irrespective of the front end.
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Should I just stick to OO design for now and then once I have a working application, build a GUI on top of it?
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Based on advice on this thread, I've started with the design of my classes. I've listed the attributes and methods for all my classes. Kindly review and comment.

Bank
private Map<accountNumber, Customer> customers
public createCustomer(String firstName, String lastName, Date DOB, initialAmount, String accountType), public findCustomer(String accountNumber)

Customer
private String firstName(get,set), private String lastName(get,set), private Date DOB(get,set), private List<Account> accounts

abstract Account
String accountNumber(get,set), double balance, double minimumBalance
void deposit(double amount), void withdraw(double amount), void checkBalance()

CheckingAccount extends Account
No additional fields/methods.

SavingsAccount extends Account
private double interestRate
private calculateInterestRate()

 
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:Should I just stick to OO design for now and then once I have a working application, build a GUI on top of it?



Yes. If you're new to OO design then you're biting off way more than you can chew at the moment. I wouldn't even worry about the GUI too much just try and build a solid functioning text based app first. My own steps in learning java went like this:

OOP design --> GUI --> database --> Servlets --> Jsp and I'm just starting to learn Spring.

I don't think you really have to follow any specific order except you need to learn OO design first, that's absolutely important.
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank you, Tyson. Could someone kindly review my classes and comment?
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If someone can kindly confirm that my design is complete, I will start coding.
 
Tyson Lindner
Ranch Hand
Posts: 211
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Prasanna Raman wrote:If someone can kindly confirm that my design is complete, I will start coding.



I mean its not like you're actually developing this for a commercial bank so whatever functionally you want to include is up to you. I don't really see anything particularly wrong with your design, except its usually better for money values to not be type double since all sorts of weird problems can come up that way.
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd missed out a few methods in my initial design. I've now updated it. Kindly review and comment.

Bank
Attributes - private Map<accountNumber, Customer> customers
Methods - public createCustomer(String firstName, String lastName, Date DOB, initialAmount, String accountType), public findCustomer(String accountNumber), public openAccount(), public closeAccount()

Customer
Attributes - private String firstName, private String lastName, private Date DOB, private List<Account> accounts
Methods - addAccount(Account account), deleteAcccount(Account account), List getAccounts(), getters, setters for name and DOB.

abstract Account
Attributes - String accountNumber, double balance, double minimumBalance
Methods - void deposit(double amount), void withdraw(double amount), double getBalance()

CheckingAccount extends Account
Same as account

SavingsAccount extends Account
Attributes - private double interestRate
Methods - calculateInterest()

I know at some point I will need to override equals method for Customer and Account, but I am just not able to visualise at the moment how or why I will have the need to compare 2 accounts or customers. Could you kindly give me a scenario and help me understand? With my current design, I think it is very difficult or even impossible to compare 2 customers correctly because I don't have a field that uniquely identifies a customer.
 
Prasanna Raman
Ranch Hand
Posts: 442
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, does the class which will interact with the user, the Bank class, have all the action methods (like deposit, withdraw, getBalance, openAccount etc.) that are present in other classes and then call those methods? Or, is it OK to just have a run() method in the bank class which will get all user input and directly call methods like deposit, withdraw in other classes? If I follow the first approach, it feels like there need not be any methods at all in the bank class, but in the 2nd, it feels like the bank class should have all the methods that are in other classes too. I am getting very confused with this. Please help me understand.
 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
One way to know that you're architecture is one that makes sense is: does it follow good design principles such as:

are you encapsulating what varies?
do you favor composition over inheritance?
are you programing to the abstract (either to an interface or abstract class) and not to the implementations?

and especially between your layers: Model / View / Data Access are you striving for loosely coupled designs between the objects that interact?

There are more principles and following them will help determine what design pattern you should follow.
here's a link to 10 of them and an explanation of what they are.

http://javarevisited.blogspot.com/2012/03/10-object-oriented-design-principles.html
 
Ranch Hand
Posts: 542
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Recently i saw in Eclipse there is JBoss plugin which reverse engineer based on the modelling diagram we supply. That is a good feature which provides auto gernerated code for different layers.
 
sai rama krishna
Ranch Hand
Posts: 542
1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I don't really see anything particularly wrong with your design, except its usually better for money values to not be type double since all sorts of weird problems can come up that way.



Based on suggestion from Tyson you may need to modify the type as well.
 
Ranch Hand
Posts: 514
1
Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As I know in javaEE Hibernate is preferred over jdbc.

So, learn Hibernate by coding following their docs.
 
Ulf Dittmer
Rancher
Posts: 43011
76
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

As I know in javaEE Hibernate is preferred over jdbc.


That "knowledge" is doubtful, IMO. If someone wants to use ORM, I think it'd be better to use the JPA API instead. Then one can swap in any JPA implementation one wants, Hibernate or any other. It's also good to remember that using ORM is not always the best choice.
 
CLUCK LIKE A CHICKEN! Now look at this tiny ad:
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!