Pramati Design viewer is a J2EE Application visualization tool for providing a rich graphical image of the J2EE application. The Design Viewer provides auto generated visual documents of the application by appropriately parsing the sources according to the web application framework in the application.

Overview: http://www.pramati.com/product/viewer10/index.htm

The Rationale:
Why A New Modeling Product?
...because J2EE development demands more.
...because we don't want you to throw the model out.
...because it's hard to handle a complex diagram.
...because nobody tackles the web-tier better.
...because it will be useful through the lifecycle and get all involved.
...because your applications now need maintenance.

Presentations [PDF]:
Modeling J2EETM Apps: We make it better
Take a look at a sample rendering of the familiar JavaTM Pet Store application

Register for Early Bird Programme:
http://www1.pramati.com/LicenserWeb/license.jsp?downloadType=PDView10reg

All said and done, Can Pramati guys say how good their tool is compared to the standard UML design tools industry from Rational,Borland JBuilder,Oracle J-Developer so on..

Unless there is a competitive analysis against some of the leading tools ...It doesn't convince one ,leave alone the price..

Rob

I believe MDA has a better and larger role to play in the J2EE applications design modelling related areana and many companies are focussing on developing MDA based tools for business models/ J2EE design (Ex.OptimalJ)and this is important considering the fact that J2EE application servers are moving towards a process centric architecture

Probably such tools have more value to offer both in terms of simplifying the design models [business and technology wise] than these tools.

Please read the post before you waste time. It's indicated in the post The Rationale: Why A New Modeling Product?

Rajinikanth

So,Is IBM(Rational),Borland(TogetherJ),Oracle and the likes dreaming in the market without a knowledge of this?

Rob

> Rationale: Why A New Modeling Product?

The rationale is full of holes that I am surprised how they had the audacity to refer to it in Serverside.

Lack of time prevents me from listing the numerous flaws and misrepesentations in their rationale. here are some in brief:

For one thing, they seriously misrepresent the state of the art in modeling tools. There are many tools supporting round-trip engineering for J2EE. And tools like Together and Rational XDE can reverse-engineer not just class diagrams but interaction diagrams as well.

Support for J2EE components and concepts is provided using stereotypes and
tagged values in most tools. Thus forward engineering is not a problem for
J2EE components if you are using UML stereotyping. This is one error that
the "rationale" keeps making all over.

Learning UML is not as difficult as they make it out to be. And it no more
difficult or complex than their properietary notation. UML is being potrayed
as inadequate for J2EE modeling and complex - none of which is true.

Putting aside all their misrepresentations and corny lines ("the source is the
mode" - what a breakthrough from Pramati!), can someone from Pramati tell us
what is they are providing that other popular tools are not (using UML). They
need to be more specific to substantiate their arguments.

Till then, i would maintain the this tool and the white paper are no more than
a fig leaf for Pramati to cover up their weakness in modeling and lack of integration/bundling with other modeling tools.

Kalyan

Looks like they have get trained in UML first.Perhaps IBM-Rational design tools mey help them

"For one thing, they seriously misrepresent the state of the art in modeling tools."

The state of the art in modeling tools is quite pathetic in my opinion. These tools are useless to me if they can't help me design (and visualize the design of) my software properly, and none of the "modeling tools" out there even comes close. I am convinced that this is an outgrowth of supporting UML just to support UML (most of these tools don't even fully support UML). The companies that produce these tools seem to forget what developers are actually looking for: not necessarily a good UML tool but a good design tool. To achieve this, they will have to provide things that UML currently does not support (although basing their notations on some of what UML provides would be advisable).

I have had some success using UML as a convenient notation for conveying certain aspects of my design, but I really don't need a massively expensive "modeling tool" for that. If Pramati's objective is to help people design better software through useful visualization techniques, then more power to them! We'll see once they release it.

Don't be a slave to UML. Use it where it makes sense, free yourself when it doesn't.

"but I really don't need a massively expensive "modeling tool" for that."

N There are many really good,proven tools fitting everyone's pocket. ..Magicdraw from Nomagic to open source tools that comes free......

Rob

seems like a good tool to create visual documentation of a project. I doubt this tool is meant to be a serious modeling tool, more of a design visualizer.

Hi all,

I think visualizations of the J2EE applications is important in the context of real usage. Simply painting a picture seems like a nice little toy to play with for a few minutes but after that what do you do with it.

From what I can see this tool merely provides a visualization of the application and nothing else. It could be useful for someone joining a new project already up and running for months so that they can understand the overall structure very quickly. After that, unless this product does more and finds a real problem, sadly its not going to make much of an impact (sales and usage). This tool needs to be part of a bigger product.

Jeremy, its good to see people trying different visualization techniques and applying them to J2EE management but can I provide some simple advice:

"For non-data-ink, less is more. For data-ink, less is a bore." Edward R. Tufte

Don't let your tool turn into one of Edward's "Ugly Ducks".


All the best,

William Louth
JDBInsight 2.0 EA 1 Now Available !!
www.jinspired.com

Heard that 'the vendor' doesn't has much of a value addition to offer to customers without a UML modelling tools integrated in the J2EE studio while the 'Vendor's competitors' offer the much needed UML design tools integrated in their studio.

So looks like ,While 'the vendor' is either not able to integrate third party UML tools or self develop is finding alternate route to get some marketing attention....

William,

Thanks for the advice. I know what you are getting at.

Trouble is how do you convey the quality of a product diagramatically, with ink on paper? I'm trying to give the user the impression that they are interacting with product itself, I want them to be able to make an intuitive assessment of the quality of the system they are dealing with, a visual assessment and an interactive assessment.

Last thing I'm trying to do is compete with any existing development methodology or language, I want to compliment them if I can. UML is fine, can't fault it, marvelous it is, until you have to communicate its intricacies with someone who doesn't understand the language, a bit like Latin with pictures.

"I'm trying to give the user the impression that they are interacting with product itself, I want them to be able to make an intuitive assessment of the quality of the system they are dealing with, a visual assessment and an interactive assessment."

- How can a developer make an intuitive assessment of the Quality of the system which in our case an Application server through a Design Viewer? QOS of the System (J2EE Server) that a developer and ultimately the end user would be dealing with has no relevance here.

"Last thing I'm trying to do is compete with any existing development methodology or language, I want to compliment them if I can. UML is fine, can't fault it, marvelous it is, until you have to communicate its intricacies with someone who doesn't understand the language, a bit like Latin with pictures"

- Who uses UML as a part of J2EE application development? Isnt it Modelling/design/development folks? If they find UML like Greek and Latin , they cannot becompetitive or survive in today's world?These days atleast many of them ought to know or get trained in UML... .

The same "someone" also cannot be business users because they also dont understand J2EE well? So How does design Viewer kind of tool help?

If they are business users who typically model business for J2EE applications ,then MDA (OptimalJ kind of tool)or even UML at a complex level is highly suitable.

Rob

You're right, but I wasn't refering to the Pramati Design Viewer I was refering to the tool on my website which visualises deployed applications using the JSR77 Management model, so the model is vendor neutral. It is not intended as a development tool, it is aimed at the wider user community including the end user and customer.

Yes, inside the development community everyone should be talking UML.

By illustrating the coupling between deployed components an assessment of the quality of the architectural design can be made.

How can a developer make an intuitive assessment of the Quality of the system which in our case an Application server through a Design Viewer?

Most architects agree that simplicity is the metric which best indicattes quality. Complexity is bad, and a diagram can expose complexity. Ultimately bugzilla is the most reliable view of an application's readiness.

If they are business users who typically model business for J2EE applications ,then MDA (OptimalJ kind of tool)or even UML at a complex level is highly suitable.

Agreed, except that the applicability of UML or MDA is still greatly limited by lack of fine grained process diagraming. Even though modern diagram languages mostly ignore it, the bulk of software design is process modeling. Ie, control and data flow diagrams. Without such action semantics, UML or MDA doesn't make complete sense. So for now most developers rightly doubt the lasting value of model sketches which usually lag behind the code and don't document an application's algorithms.

UML is fine, can't fault it, marvelous it is, until you have to communicate its intricacies with someone who doesn't understand the language, a bit like Latin with pictures.

Of course there are simpler diagram notations which allow for completely specified execution, such as with Shlaer-Mellor. But humanity has never invented a schematic that layfolk could read. A learning curve is inherently unavoidable. A diagram notation's goal isn't to be appealing to outsiders. The goal of a diagram notation is to minimize cognitive load during maintenance. UML has done this well enough, and Shlaer-Mellor has done it best.

Plain vanilla stuff..

Its all the better to focus on some serious stuff out there

Rosalind

Vanilla stuff??! oh come on!
Ever tried serious j2ee development? you would not be making such comments.

Designviewer - looks good conceptually. Lets see what the real stuff delivers!

R

"Vanilla stuff??! oh come on!
Ever tried serious j2ee development? you would not be making such comments.
Designviewer - looks good conceptually. Lets see what the real stuff delivers! "

Until anything is proven to be seriously helping developers like us in their day to day work which I mean in a needs driven scenario can be a 'plain valnila stuff' and one has to seriously look else where...

I am looking seriously for modeling tools which i need to work on from 'tomorrow' and I cant work on plain , yet to be proven stuff...

Let me know when the real stuff gets delivered,i will see then

Rosalind

Requested URI:/LicenserWeb/thankyouLicense.jsp Description:

null
java.lang.NullPointerException
at com.pramati.jsp.generated.thankyouLicense_pmt_0._jspService(thankyouLicense_pmt_0.java:179)
at com.pramati.jsp.runtime.HttpJspSuper.service(HttpJspSuper.java:87)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.pramati.web.servlet.core.PramatiRequestDispatcher.forward(PramatiRequestDispatcher.java:112)
at com.pramati.jsp.runtime.PageContextImpl.forward(PageContextImpl.java:78)
at com.pramati.jsp.generated.sendEmail_pmt_0._jspService(sendEmail_pmt_0.java:925)
at com.pramati.jsp.runtime.HttpJspSuper.service(HttpJspSuper.java:87)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.pramati.web.servlet.core.PramatiRequestDispatcher.forward(PramatiRequestDispatcher.java:112)
at com.pramati.jsp.runtime.PageContextImpl.forward(PageContextImpl.java:78)
at com.pramati.jsp.generated.license_pmt_0._jspService(license_pmt_0.java:358)
at com.pramati.jsp.runtime.HttpJspSuper.service(HttpJspSuper.java:87)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.pramati.web.interceptors.ServiceInterceptor$ServiceAction.run(ServiceInterceptor.java:294)
at com.pramati.security.util.JAASSecurityHelper.doAs(JAASSecurityHelper.java:145)
at java.lang.reflect.Method.invoke(Native Method)
at com.pramati.services.security.spi.SecurityHelper.doAs(SecurityHelper.java:130)
at com.pramati.web.interceptors.ServiceInterceptor.preProcess(ServiceInterceptor.java:141)
at com.pramati.web.interceptors.core.DefaultInterceptor.process(DefaultInterceptor.java:47)
at com.pramati.web.interceptors.core.InterceptorChainImpl.processNext(InterceptorChainImpl.java:48)
at com.pramati.web.interceptors.FilterInterceptor.process(FilterInterceptor.java:92)
at com.pramati.web.interceptors.core.InterceptorChainImpl.processNext(InterceptorChainImpl.java:48)
at com.pramati.web.interceptors.core.DefaultInterceptor.process(DefaultInterceptor.java:48)
at com.pramati.web.interceptors.core.InterceptorChainImpl.processNext(InterceptorChainImpl.java:48)
at com.pramati.web.interceptors.core.DefaultInterceptor.process(DefaultInterceptor.java:48)
at com.pramati.web.interceptors.core.InterceptorChainImpl.processNext(InterceptorChainImpl.java:48)
at com.pramati.web.interceptors.core.DefaultInterceptor.process(DefaultInterceptor.java:48)
at com.pramati.web.interceptors.core.InterceptorChainImpl.processNext(InterceptorChainImpl.java:48)
at com.pramati.web.interceptors.core.DefaultProcessContainer.process(DefaultProcessContainer.java:88)
at com.pramati.web.core.WorkerThread.run(WorkerThread.java:54)
at com.pramati.web.core.AcceptorThread.run(AcceptorThread.java:121)

There's no download for this thing that I can see. The early bird says "July 15th". Go figure.

The release of the DesignViewer 1.0 has been delayed by 2weeks. Download will be available by the July 30th. But continue registering! :-)

I had a look at the sample view and note that it only presents the petstore.ear part of the Petstore application, it doesn't show the OPC, Admin and Supplier application parts.

I'm just wondering that if the diagram included the entire petstore application and it was shown on a single screen would we be able to read anything? I see no attempt to layer the detail, for example if I zoomed out far enough should I be able to assess the dependencies between the 4 applications that make up the Petstore Sample Application.

Oddly enough I have been developing a j2ee visualisation tool that isn't mda or uml based (its black-box component-based) and have been using the Petstore Sample Application to illustrate its capabilities. The tool is a JSR77 compliant Management Application, using a Java3D based graphics engine to generate j2ee models rendered in 3d space.

My thinking is that such a tool would be useful not so much as a development tool but more as a medium through which developers can communicate the complexity of the systems they develop, lifting the bonnet and showing the spagetti beneath. I want to give the viewer the impression that they are actually interacting with the system rather than just a graphical representation of the system so the 3d model is interactive and navigation is automated by the model itself.

see

http://www.jpitten.btinternet.co.uk

for some snapshots