• 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

Reverse Engineering from code

 
Ranch Hand
Posts: 80
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am currently working on an application that is written in java.
I have been asked to take over this application and enhance this.
I feel if there is good documentation in terms of the design, like what classes are there the methods in each class and what each method does, it will be good for someone to read this and understand what the application is doing instead of going through the code.
I know that design shouldve been done before writing the code, but as we all know, is not always the case in real life :-) So I want to start documenting it so that the next person will find it easier to maintain this code.

One way I can think of is, writing the classes, methods in each, dependencies between classes. But this approach has me confused because it goes on and on, with one calling the other and that calling the next and so on.
Is there any clean approach to this kind of thing? Are there any steps to do this?
I know that there are features in some design tools to generate design from code, but unfortunately I have only MS word :-)
Let me know if any of you have done this or have any thoughts on this kind of thing.

Thanks
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I find much more valuable then design documents are tests - both unit and acceptance tests. After all, for what classes and methods there are, I *can* read the code (and with a modern IDE that might be even more convenient than a design document, especially since I wouldn't trust the latter to be up to date anyway). What I need to know additionally is what the code is supposed to do, and wether I broke something with my changes.

So I'd probably concentrate on writing those tests instead of design documentation.
 
Ranch Hand
Posts: 906
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Each time you think about creating design documentation, I would suggest to ask yourself the question :
"Who is going to benefit from this design documentation - Which level of granularity is sufficient for them ?"
Even if you are designing your application before implementing it, you should not go into to much details if there is not a specific identified need for it.
For instance, do you need an UML representation of all the classes (class diagram) of your system ? Maybe yes, maybe no. You have to decide based upon what you know of your organization, the way people use to work, the kind of doc they are comfortable with...
Maybe it's more important to depict the dynamic aspects through sequence diagrams ?
Mayge a high level UML doc is sufficient (Analysis diagrams of the RUP methodology), as Java IDEs now provide a really good way to document your system (the code is a good documentation, no ??)

This is also true when you are doing reverse engineering. It is not because a tool allows you to do it that the result will be useful for you. As Ilja said, the testing aspect could be far more interesting, and they document what you really want to do with your system.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Exactly. This idea is captured in Agile Modeling's Model With A Purpose principle. Many developers worry about whether their artifacts -- such as models, source code, or documents -- are detailed enough or if they are too detailed, or similarly if they are sufficiently accurate. What they're not doing is stepping back and asking why they're creating the artifact in the first place and who they are creating it for. With respect to modeling, perhaps you need to understand an aspect of your software better, perhaps you need to communicate your approach to senior management to justify your project, or perhaps you need to create documentation that describes your system to the people who will be operating and/or maintaining/evolving it over time. If you cannot identify why and for whom you are creating a model then why are you bothering to work on it all? Your first step is to identify a valid purpose for creating a model and the audience for that model, then based on that purpose and audience develop it to the point where it is both sufficiently accurate and sufficiently detailed. Once a model has fulfilled its goals you're finished with it for now and should move on to something else, such as writing some code to show that the model works. This principle also applies to a change to an existing model: if you are making a change, perhaps applying a known pattern, then you should have a valid reason to make that change (perhaps to support a new requirement or to refactor your work to something cleaner). An important implication of this principle is that you need to know your audience, even when that audience is yourself. For example, if you are creating a model for maintenance developers, what do they really need? Do they need a 500 page comprehensive document or would a 10 page overview of how everything works be sufficient? Don't know? Go talk to them and find out.

The easiest way to accomplish this is to model with others. When you Model With a Purpose you often find that you are modeling to understand something, that you are modeling to communicate your ideas to others, or you are seeking to develop a common vision on your project. This is a group activity, one in which you want the input of several people working together effectively. You will often find that your development team needs to work together to create the core set of models critical to your project. For example, to develop the metaphor or architecture for you system, you will often need to model with a group of people to develop a solution everyone agrees on as well as one that is as simple as possible. Most of the time the best way to do this is to talk the issue through with one or more people.

- Scott
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey vivek,
there is a reflect class in java that gives you name of all methods, all constructors and many more things. You can refer to that.
and there eis another way also to do this:
first is jsut generate javadoc for getting details of the classes or there is another opiton of using pdf doclet that generates javadoc in pdf of any no of packages you want.
if u need any hellp you can contact me at hemantn@outlinesys.com
i've worked on it.
thx

Originally posted by vivek ja:
I am currently working on an application that is written in java.
I have been asked to take over this application and enhance this.
I feel if there is good documentation in terms of the design, like what classes are there the methods in each class and what each method does, it will be good for someone to read this and understand what the application is doing instead of going through the code.
I know that design shouldve been done before writing the code, but as we all know, is not always the case in real life :-) So I want to start documenting it so that the next person will find it easier to maintain this code.

One way I can think of is, writing the classes, methods in each, dependencies between classes. But this approach has me confused because it goes on and on, with one calling the other and that calling the next and so on.
Is there any clean approach to this kind of thing? Are there any steps to do this?
I know that there are features in some design tools to generate design from code, but unfortunately I have only MS word :-)
Let me know if any of you have done this or have any thoughts on this kind of thing.

Thanks

 
Do the next thing next. That’s a pretty good rule. Read the tiny ad, that’s a pretty good rule, too.
create, convert, edit or print DOC and DOCX in Java
https://products.aspose.com/words/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!