File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes Problems understanding large scale JEE applications Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Problems understanding large scale JEE applications" Watch "Problems understanding large scale JEE applications" New topic
Author

Problems understanding large scale JEE applications

Dave McQueen
Greenhorn

Joined: May 22, 2009
Posts: 29
Hi,
I'm not the most experienced or skill java programmer (although am certified) so i'd be interested to have the opinions of others who are if possible?
I currently find it extremely difficult to understand large scale jEE applications. For instance, in my workplace we're given applications that we're 'reps' on, and we're expected to understand how they work. However the applications are typically, as an order of magnitude estimate, 100,000 lines of code in length, with large chunks being reused. What's more, the application in the file system is not in order of use, it's stored alphabetically according to packages then classes.
The task to digest this conceptually can be conservatively compared to taking a book the size of Lord of the Rings, cutting up all of the paragraphs, messing them up, then giving these to someone who's never read the book to sort them in the correct order and/or figure out what the plot is and who the main players are.
I'd be interested to know, why this problem exists? Is OO code supposed to simlify this? I actually find OO makes things harder to understand than procedural sometimes as for a particular use case for example, it's hard to see what method in this use case, affected my object of interest, as it's correctly been reused throughout the application. Then you have to repeat this to find the method calling the method that you've found, and so on etc.
I've been unsure about asking this question previously in case it's trivialised with a response along the lines of 'you should always be able to tell what method is calling your object in your particular use case', but I just don't find this is the case in practise. Plus with decoupling structures like Spring, Hibernate and Struts, this kind of thing can be even harder.
So enough preamble, does anyone know whether this problem is due to bad design, a lack of tools to simplify this, like something that abstracts and generalizes a code and splits up parts like a flow diagram according to use cases, or something else entirely?
Idle speculation to wildly imaginative visions of future technologies - and everything in between - are welcome!


Before you criticize someone, try walking a mile in their shoes. That way you'll be a mile away from them. And you'll also have their shoes.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Dave McQueen wrote:as an order of magnitude estimate, 100,000 lines of code in length, with large chunks being reused.

That's very small, by the way.
The task to digest this conceptually can be conservatively compared to taking a book the size of Lord of the Rings, cutting up all of the paragraphs, messing them up, then giving these to someone who's never read the book to sort them in the correct order and/or figure out what the plot is and who the main players are.

Not true at all: there are sets of well-known entry points into JEE apps: the web.xml, framework configuration information, etc.
Plus with decoupling structures like Spring, Hibernate and Struts, this kind of thing can be even harder.

From some standpoints, yes. From others, no.

There are any number of tools, metrics, etc. you can use to help understand large-scale architecture, but the primary amongst those is the documentation that should have been generated by the architects. If you don't have that, then it becomes a matter of determining interactions, data flows, application entry points, and so on.

I write a lot of custom tools to help aid discovery, but those tools, beyond the obvious things (config files and annotations) are usually application-specific, depending on what manual investigation reveals.

I agree it's an overall problem, one which I spend a lot of time trying to understand, and automate. But there are a ton of ways to ferret out the places to start looking.
Dave McQueen
Greenhorn

Joined: May 22, 2009
Posts: 29
David, thanks for your response - useful stuff.
I guess I'm just wondering, why isn't there a tool or application that allows you to see the java rules and data flow in some sort of flow-chart way, diagrammatically, pictorially, more abstract and general but quicker to read through, rather than having to go through code line by line, then through configuration code by line, and backwards and forwards?
It'd be great if a java application could be defined like this somehow (not sure if it can), with a series of flowcharts, perhaps at different levels, so that you could perhaps double click on a 'diamond shaped boolean section (like the parts that have 'yes' coming off one corner and 'no' off another)' and 'zoom in' on the code that's present there?
Does that even make sense? It just feels unnecessary to have to read through code when all you want to see is *where* the application can go, and not necessarily *how* it goes there (in terms of code).
A benefit would be that the business wouldn't need to understand the code and could just write flow charts, and the IT function wouldn't need to understand the business (which if my work is the norm, is pretty much a definite). They could define the business rules using a flow chart and the programmer could 'zoom in' on each flow chart section and write the code.
I'm just surprised something this obvious doesn't exist?
 
Consider Paul's rocket mass heater.
 
subject: Problems understanding large scale JEE applications
 
Similar Threads
OOP is POO the functions are comming
Rich Object Model versus Anemic Object Model
Wicket - next big thing?
Java discourages intelligent use of database technology: Discuss.
Newbie in EJB