Understanding an existing Java project

I have a project with about 10 Classes.  Each class has an average of 15 lines of code.

It is an example explaining polymorphism.   It has interfaces, extends, implements and regular classes.  

When looking at new procedural code, I'd start at the top (main) function and drill down to keep getting a more in depth picture of what the code does.   Once I had some idea of how it works I'd start looking at the subroutines for more details.

I don't know how to examine a new Java or OOPs project.  Do I start looking at main and then drill into the classes?    Should I look at the lowest level classes first.  Maybe they are called concrete classes?   Is there a tool that can make a diagram of the hierarchy of the classes so that I don't have to draw my own road map?  

I'm back to Page 205 out of 700 and it's making a lot more sense this pass.  


Thanks,

Kevin

Step 1 is to always read the manual. Projects usually come with a readme or wiki or user manual. You can't get away with not reading those.

Other than that, for me it depends what I'm using the project for, and why I'm trying to understand it.

If the project is a library that is called by my application directly or indirectly, I set a breakpoint in my own application and then step into the library. That will take me to the part that I'm trying to understand. Then I step deeper and deeper until I'm no longer interested in the details.

Other times, I'm writing my own library and I'm trying to understand how it's being called by another application. Then I set a breakpoint in my library and look at the call stack. Then I bubble up into more abstract layers.

Either way, I tend to analyze other projects by stepping through it with my debugger, and comparing the implementation with the public Javadoc.

If the project implements some sort of specification, then it's always useful to read the specification document as well.

kevin Abel wrote:. . . Do I start looking at main and then drill into the classes? . . .

I wouldn't myself, no.
A real‑life project should have documentation comments and you can start by reading those. If there aren't any, send it back to its creator and ask for those comments. That is rather like Stephan's suggestion to read the manual.
It might be worth drawing a class diagram to show the interrelations between the different types. Find a simple UML tutorial. Basically, put what you think are the superclasses and interfaces at the top and the subclasses at the bottom, drawing a square for each. Draw arrows to show which class implements which interface(s) and which class it extends. Remember that Java® doesn't support multiple inheritance, so a class can implement multiple interfaces but only directly extend one superclass. That is a very simple start which might make it easier to see the relationships.

Stephen and Campbell,

Your answers gave me a good starting point.  I'll look for user documents.

Drawing the class diagram would also be a great idea.  Are there tools where I supply the Java code and it draws the (UML??) for me?

I have been on three projects that used limited OOPs using a form of BASIC in the UFT test tool.   Once a developer left me with thousands of lines of code including classes.  There was no documentation.  I couldn't tell how or if it worked.   I managed to talk with the developer and said he left without documenting it and didn't think someone could unscramble it.   I had to start over.  

I don't think that BASIC was completely OOPS.  It didn't have anything like extends or implements.  

Thanks,

Kevin

kevin Abel wrote:. . .  Are there tools where I supply the Java code and it draws the (UML??) for me? . . .

Yes. Lots. There is an Eclipse plugin that does that.

I don't think that BASIC was completely OOPS. . . .

The last time I wrote any Basic (over fifty years ago), it wasn's object‑oriented at all.

Campbell,

I'm looking around for a UML plug in for Intellij.  I see a video showing how to use Intellij Ultimate.  It is free for students.  I'm not sure what I have to do to show that I'm a student.  
It might help me a lot.

I  was using VBSCRIPT in UFT.  

It let me make classes and change them into objects.  It has a dot operator so I could drill down to an Object on the application in a format that looks like:


Window("the window").Frame("my frame").Button("the button").click        

Each piece was an object.

It was partial OOPs.  I'm not sure what its called.

Thanks,

Kevin