Discussions

News: MaintainJ Version 1.0 is out

Bookmark and Share Get thread feed

  1. MaintainJ Version 1.0 is out (18 messages)

    MaintainJ, an Eclipse plug-in, generates sequence and class diagrams for a use case, helping the users to quickly understand a complex Java or J2EE application. MaintainJ logs runtime method execution sequence to a file and uses that trace file to render sequence and class diagrams. MaintainJ Instrumentation Wizard instruments a Java/J2EE application and MaintainJ UML Editor renders sequence and class diagram from the trace file. The following features make MaintainJ a unique and useful tool for Java developers. Source Untouched: The application code is not changed in anyway; application is rebuilt using AspectJ compiler to capture the method execution sequence at runtime. Collapsible Calls: Method calls in sequence diagram are collapsible. Developers can easily explore a complex sequence diagram by collapsing and expanding calls as necessary. Focused Diagrams: Only application classes are shown in the diagrams. The classes in the diagram can further be narrowed by instrumenting only the packages of interest. Runtime Diagrams: All classes shown in the diagrams are concrete runtime classes. No Loop Calls: All repeat calls occurring in a loop except the first call are removed. Recursive calls also are removed. Eclipse Integration: Double clicking a method call or class opens matching method or class in Eclipse. Outline Views: Outline views in both diagrams make navigating a complex diagram simpler. Print or Export: Diagrams can be printed or exported as JPEG images.
    Reply to this

    Threaded Messages (18)

  2. Re: MaintainJ Version 1.0 is out[ Go to top ]

    Maybe I'm missing something but this seems like a lot of overhead (i.e. requiring you to deploy the app and physically execute various use cases) just to get sequence diagrams and other UML diagrams. I'm pretty sure I've used other tools in the past (e.g. TogetherJ) which could do the same thing by either simply introspecting the source code or even the compiled jar file(s) .
    Reply to this Reply to original

  3. Re: Seems like lot of overhead[ Go to top ]

    James, Thanks for your comments. I agree that it has some overhead. But when someone is trying to quickly understand a complex application with lot of runtime binding, it can be very frustrating. I don't think any static time code introspecting tool can produce quality sequence diagrams that can really help a developer to debug a complex application. Developers, including those working on the same system for years, spend lot of time to understand existing code. MaintainJ helps this situation by its ability to quickly generate focused sequence and class diagrams for a given use case. Using MaintainJ Instrumentation Wizard, one can quickly instrument the application, generate the diagrams and revert the workspace to the uninstrumented code. All this is done without leaving Eclipse and without having to write any code. Regards, Choudary Kothapalli. MaintainJ Inc.
    Reply to this Reply to original

  4. Re: MaintainJ Version 1.0 is out[ Go to top ]

    Maybe I'm missing something but this seems like a lot of overhead (i.e. requiring you to deploy the app and physically execute various use cases) just to get sequence diagrams and other UML diagrams.

    I'm pretty sure I've used other tools in the past (e.g. TogetherJ) which could do the same thing by either simply introspecting the source code or even the compiled jar file(s) .
    Well it's only true for class diagram not object diagrams. Without running the application it's impossible to only see a specific scenario. You always see the whole picture and it's can be harder IMO to understand the code this way.
    Reply to this Reply to original

  5. Re: MaintainJ Version 1.0 is out[ Go to top ]

    I have personally found it much easier to understand flows based on context than just the code - the data and state is much more revealing to the reason for the flow direction than the flow pattern itself. It is for this reason I designed and built probably the first scalable contextual distributed profiling solution for CORBA & Java EE component architectures. Lately I am spending more of my time trying to design visualizations that can merge these 3 aspects (code flow, data, and component state) together into a consolidated view. I do agree that one gains a greater understanding of an application by looking at its execution patterns per use case - what is completely missing here is the fact that outside of the IDE usage scenario the execution flow of a thread is not independent of the execution of other concurrent threads. regards, William
    Reply to this Reply to original

  6. Re: Data and state is much more revealing[ Go to top ]

    William, I do agree that context helps to get a much better understanding than just the flow pattern. That will be my next major enhancement. MaintainJ could be used outside IDE though it would slow down the application a little, just like any other instrumented code. I didn't see much difference for a single user scenario, though. I wouldn't recommend it for deployment time at this moment anyway. I observe that developers spend lot more time in understanding the code(in an IDE or otherwise) than in profiling a deployed application. Once an application is deployed and running well, developers typically don't spend that much time to fix performance issues. On the other hand, for every small enhancement, the application needs to be understood and this effort gets multiplied with each new developer added to the team. For some strange reason, managers and developers take this effort, which can be as much as 30-50% of the maintenance effort, for granted. MaintainJ aims to reduce this effort. Regards, Choudary Kothapalli. MaintainJ Inc.
    Reply to this Reply to original

  7. Re: Data and state is much more revealing[ Go to top ]

    "I didn't see much difference for a single user scenario, though." Are you talking about overhead or the relevance of multi-threaded execution analysis? Nothing runs in isolation - at least today. State changes on shared components, classes and resources can be the cause for a particular execution pattern occurring. When I look at the component execution pattern and transactional histories of a J2EE application having problems (performance, scalability, and reliability) I look to see how much the request data or system/component state has an impact on the execution flows. In general I do not have a problem reading JEE code and determining the major interaction points. The problem for me is combining this mental model with contextual data (requests), state and state transitions. I have a particular interest in transaction integrity of business transactions mapped to resource transactions which is impossible to see in any code specific visualizations. Granted I am trying to solve a much larger and more difficult problem that is not everyones "cup of tea". regards, William Louth - JXInsight Product Architect http://www.jinspired.com
    Reply to this Reply to original

  8. Re: Data and state is much more revealing[ Go to top ]

    "I didn't see much difference for a single user scenario, though."

    Are you talking about overhead or the relevance of multi-threaded execution analysis
    I was talking about the overhead; not the relevance of multi-threaded execution analysis. I do agree that application flow without context data helps only to a certain extent. Regards, Choudary Kothapalli. MaintainJ Inc.
    Reply to this Reply to original

  9. MaintainJ Version 1.0 is out[ Go to top ]

    Before some days i was looking for the same tool. i will try it out. IS there any other OpenSource UML tool ? Sudhir Nimavat
    Reply to this Reply to original

  10. I like the idea[ Go to top ]

    I like the idea. Certainly worth trying.
    Reply to this Reply to original

  11. Spring[ Go to top ]

    Sounds great, I have been looking for such kind of application from a long time. Would it run for a Spring?
    Reply to this Reply to original

  12. Spring[ Go to top ]

    Ridvan, I haven't tried it with a Spring sample, but it should work as MaintainJ is designed for any Java/J2EE application. Regards, Choudary Kothapalli. MaintainJ Inc.
    Reply to this Reply to original

  13. Re: MaintainJ Version 1.0 is out[ Go to top ]

    It'd be interesting to see how it does this cleanly; TogetherJ has had a feature like this for many years but it's only done static code analysis. The runtime code analysis would have the benefit of capturing dynamic bindings, which is increasingly common these days... J.
    Reply to this Reply to original

  14. It'd be interesting to see how it does this cleanly[ Go to top ]

    Julian, MaintainJ generates sequence diagrams with the runtime classes and the diagrams are clean. Install it and check the samples to see it yourself. Regards, Choudary Kothapalli MaintainJ Inc.
    Reply to this Reply to original

  15. How to run outside of Eclipse?[ Go to top ]

    It's certainly a very useful tool. How can I gather all the runtime call trace using MaintainJ for an application running outside of Eclipse? Appreciate any feedback. -yogesh
    Reply to this Reply to original

  16. Re: How to run outside of Eclipse?[ Go to top ]

    Yogesh, MaintainJ needs the application code to be instrumented using AspectJ. This can either be done in Eclipse using MaintainJ Instrumentation Wizard or outside Eclipse using Ant scripts. But if you have an already running application that you cannot build, MaintainJ wouldn't help. Regards, Choudary Kothapalli.
    Reply to this Reply to original

  17. Considered TPTP?[ Go to top ]

    Interesting. Have you considered adding your UML views as enhanced Eclipse TPTP views? (extensions to existing UML2 Class/Object Views) That would make it possible to use TPTP's existing call statistics collectors, which would in turn save the developer yet another setup stage. Best regards Mike Wilson
    Reply to this Reply to original

  18. Considered TPTP?[ Go to top ]

    I have not looked at TPTP for a long time. I need to take a look at it. Thanks a lot for your suggestions. Regards, Choudary Kothapalli.
    Reply to this Reply to original

  19. Re: Considered TPTP?[ Go to top ]

    For a glimpse of the UML2 views you can have a look at "Quick tour of TPTP" http://www.eclipse.org/tptp/home/documents/tutorials/viewlets/v4.1/EW-profile/EW-profile/EW-profile_viewlet_swf.html frames 112-125 (link found on http://www.eclipse.org/tptp/home/documents/index.html) Best regards Mike Wilson
    Reply to this Reply to original