aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Conceptual approach: financial software Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Conceptual approach: financial software" Watch "Conceptual approach: financial software" New topic

Conceptual approach: financial software

Katrina Owen

Joined: Nov 03, 2006
Posts: 1358

I am trying to determine a good way to structure an application that I want to build.

I have been struggling with this for some time, drawing faux-UML, crossing stuff out, drawing more faux-UML, uttering mild expletives, crossing more stuff out, etc. and I keep catching myself thinking: There has to be a pattern for this.

I am confused enough that I am pretty sure any explanation of the problem is going to be intolerably messy... here goes:

A person can have
- assets
- liabilities
- income streams
- expense accounts

Each of these are structured differently, and behave differently.

On the other hand, all of these have 'movements' which need to be tracked to specific dates, and I need to be able to generate various displays based on the movements.

These displays will generally be 'monthly', 'quarterly', or 'yearly'.
Or they will be breakdowns by account/category.

I seem to be able to structure my data so that either one or the other option is viable, but not both.

I guess my biggest problem is:
How do I structure the statement and movements so that I can get efficient displays of both separate accounts (breakdown) and overviews by period?

Does anyone have any suggestions as to how to approach this?

Best regards,
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
My advice would be to forget efficiency for now. Find a structure that makes sense from a behavioural point of view - what objects will have what responsibilities, and how they will need to collaborate.

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
You didn't show an entity for "movement" or transaction. I'd expect to see a collection of events that record a history or audit trail of what happened when. They might be very simple with fields for date, amount, from and to.

Once you have those, your displays might come very easily by iterating the collection and accumulating. I used to do a lot of this kind of thing:

That's assuming you want to do it all in memory. If you can create your displays from a database you can probably write a query to do most of the totals and breaks for you.

Does that seem to fit the problem?

A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Peer Reynders

Joined: Aug 19, 2005
Posts: 2922
You should also remind yourself to Apply Patterns Gently.

However Martin Fowler does discuss some recurring financial Analysis Patterns in his book Analysis Patterns: Reusable Object Models (amazon US)

6.12 Balance Sheet and Income Statement (Fig. 6.28)

UML Diagrams for Chapter 6 of Analysis Patterns (pdf)
Martin Fowler's Analysis Patterns articles
Martin Fowler's Accounting Analysis Patterns

However towards design and implementation you will still need to leverage considerable knowledge and insight into your particular business domain (as indicated in Domain Driven Design) - as the devil is often in the details.

Domain Driven Design � Tackling Complexity in the Heart of Software by Eric Evans
amazon US
Domain Driven Design Homepage
[ March 26, 2007: Message edited by: Peer Reynders ]
Katrina Owen

Joined: Nov 03, 2006
Posts: 1358
Thank you all for your suggestions and comments. This gives me a lot to chew on... the devil is indeed in the details!
It is sorta covered in the JavaRanch Style Guide.
subject: Conceptual approach: financial software