Hi,

Is anyone know any opensource & paid tool which will help to maintain
class hierarchy.
Also suggest some tools, which helps to "Software Architect" for
maintaining the system flows.

Regards,
Mahendra Bhandarkar

On 18 Mrz., 06:04, manoj <mahendrabhandar...@gmail.com> wrote:

> Is anyone know any opensource & paid tool which will help to maintain
> class hierarchy.

There are a ton of UML tools out there, if you want coupling of Java
and UML you need to look for "reverse engineering" or "roundtrip"
capabilities.  Examples:

http://www.borland.com/de/products/together/
http://www.gentleware.com/new-poseidon-for-uml-8-0.html

Find more with
http://www.google.com/search?q=uml+%22reverse+engineering%22+java
http://www.google.de/search?q=uml+roundtrip+java

> Also suggest some tools, which helps to "Software Architect" for
> maintaining the system flows.

Not sure what you mean by "system flows".

If you only need a drawing tool my preferred choice is Visio with
custom stencils
http://www.softwarestencils.com/uml/index.html#Visio2003

Kind regards

robert

On Mar 18, 9:52=A0am, Robert Klemme <shortcut...@googlemail.com> wrote:
> On 18 Mrz., 06:04, manoj <mahendrabhandar...@gmail.com> wrote:
>
> > Is anyone know any opensource & paid tool which will help to maintain
> > class hierarchy.
>
> There are a ton of UML tools out there, if you want coupling of Java
> and UML you need to look for "reverse engineering" or "roundtrip"
> capabilities. =A0Examples:
>
> http://www.borland.com/de/products/together/
>http://www.gentleware.com/new-poseidon-for-uml-8-0.html

They don't seem so opensource...
and by my experience, all communities editions of this kind of
software are almost useless.

On 18-03-2011 08:22, Hole wrote:
> On Mar 18, 9:52 am, Robert Klemme<shortcut...@googlemail.com>  wrote:
>> On 18 Mrz., 06:04, manoj<mahendrabhandar...@gmail.com>  wrote:
>>
>>> Is anyone know any opensource&  paid tool which will help to maintain
>>> class hierarchy.
>>
>> There are a ton of UML tools out there, if you want coupling of Java
>> and UML you need to look for "reverse engineering" or "roundtrip"
>> capabilities.  Examples:
>>
>> http://www.borland.com/de/products/together/
>> http://www.gentleware.com/new-poseidon-for-uml-8-0.html
>
> They don't seem so opensource...

They are not.

But it seems reasonable to expect "opensource & paid tool"
to really mean "open source or commercial" not "open source and
commercial".

> and by my experience, all communities editions of this kind of
> software are almost useless.

I believe it is the concept not the tool that has a problem.

Arne

On 18-03-2011 01:04, manoj wrote:
> Is anyone know any opensource&  paid tool which will help to maintain
> class hierarchy.
> Also suggest some tools, which helps to "Software Architect" for
> maintaining the system flows.

Why?

You want your UML models to provide overview at a higher level
than the code.

There are not much point in having UML and code providing the
same info at the same level of complexity.

And since tools are not very good at deciding what is so
important that it needs to be in an overview, then ...

Write you UML youself, because you know what is important
and what is not.

Arne

On 19.03.2011 01:08, Arne Vajh=F8j wrote:
> On 18-03-2011 01:04, manoj wrote:
>> Is anyone know any opensource& paid tool which will help to maintain
>> class hierarchy.
>> Also suggest some tools, which helps to "Software Architect" for
>> maintaining the system flows.
>
> Why?
>
> You want your UML models to provide overview at a higher level
> than the code.
>
> There are not much point in having UML and code providing the
> same info at the same level of complexity.
>
> And since tools are not very good at deciding what is so
> important that it needs to be in an overview, then ...
>
> Write you UML youself, because you know what is important
> and what is not.

I don't believe in roundtrip engineering (or graphical programming)=20
either.  There are too many issues with keeping an UML model and a set=20
of classes consistent that it's usually harder to work that way than=20
with separate models.

Also, an UML model alone does not tell much.  For me UML is a means that =

helps communicating because there is a standard way of expressing=20
certain aspects of a system.  That is best used in a meeting on a=20
whiteboard or piece of paper and in documents which mix UML and text=20
explaining what's going on.  For that it is usually also good to have a=20
tool which gives you plenty of freedom and is not too strict about=20
enforcing UML model consistency.  That's why I prefer Viso with this=20
custom set of stencils.

Kind regards

	robert

--=20
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

Robert Klemme wrote:
> Arne Vajhøj wrote:
>> manoj wrote:
>>> Is anyone know any opensource& paid tool which will help to maintain
>>> class hierarchy.
>>> Also suggest some tools, which helps to "Software Architect" for
>>> maintaining the system flows.

>> Why?
>>
>> You want your UML models to provide overview at a higher level
>> than the code.
>>
>> There are not much point in having UML and code providing the
>> same info at the same level of complexity.
>>
>> And since tools are not very good at deciding what is so
>> important that it needs to be in an overview, then ...
>>
>> Write you UML youself, because you know what is important
>> and what is not.

> I don't believe in roundtrip engineering (or graphical programming) either.
> There are too many issues with keeping an UML model and a set of classes
> consistent that it's usually harder to work that way than with separate models.
>
> Also, an UML model alone does not tell much. For me UML is a means that helps
> communicating because there is a standard way of expressing certain aspects of
> a system. That is best used in a meeting on a whiteboard or piece of paper and
> in documents which mix UML and text explaining what's going on. For that it is
> usually also good to have a tool which gives you plenty of freedom and is not
> too strict about enforcing UML model consistency. That's why I prefer Viso
> with this custom set of stencils.

+1.

Even if UML->Java->UML worked correctly, I question its value.  Should we 
program in Java or in UML?  I say, "in Java".

UML is, AFAIK, not intended to be a substitute for coding.  Its highest 
purpose is what Robert said, to facilitate design and architecture conversations.

I once got in (and then out of) trouble for designing a set of interfaces and 
class stubs (stubs!) so that I could generate UML for a project.  They were 
all, like, "It's time for diagrams, not for coding!"  So I was all, like,, 
"But this is how I get UML diagrams.  It's not really coding!  This /is/ 
design phase, right?"  And they were all, like, "So you're writing in code but 
you're not coding?" and I'm all, like, "Exactly!"

Stupid waterfall bimbos.

-- 
Lew
Honi soit qui mal y pense.

On 11-03-19 04:19 AM, Robert Klemme wrote:
> On 19.03.2011 01:08, Arne Vajh�j wrote:
>> On 18-03-2011 01:04, manoj wrote:
>>> Is anyone know any opensource& paid tool which will help to maintain
>>> class hierarchy.
>>> Also suggest some tools, which helps to "Software Architect" for
>>> maintaining the system flows.
>>
>> Why?
>>
>> You want your UML models to provide overview at a higher level
>> than the code.
>>
>> There are not much point in having UML and code providing the
>> same info at the same level of complexity.
>>
>> And since tools are not very good at deciding what is so
>> important that it needs to be in an overview, then ...
>>
>> Write you UML youself, because you know what is important
>> and what is not.
> 
> I don't believe in roundtrip engineering (or graphical programming)
> either.  There are too many issues with keeping an UML model and a set
> of classes consistent that it's usually harder to work that way than
> with separate models.
> 
> Also, an UML model alone does not tell much.  For me UML is a means that
> helps communicating because there is a standard way of expressing
> certain aspects of a system.  That is best used in a meeting on a
> whiteboard or piece of paper and in documents which mix UML and text
> explaining what's going on.  For that it is usually also good to have a
> tool which gives you plenty of freedom and is not too strict about
> enforcing UML model consistency.  That's why I prefer Viso with this
> custom set of stencils.
> 
> Kind regards
> 
>     robert
> 
What I mostly dislike here are the UML design _tools_. I don't care how
good they are (my most recent work experience has been with SPARX
Enterprise Architect), and in fact the *better* they are the worse the
(perceived by me) problem gets.

So I'm absolutely onside with the Visio suggestion. I use Omnigraffle
Pro and the UML stencils it has, for example. The beauty of this
approach is because you're not reverse-engineering diagrams from source,
and you have to actually _draw_ your diagrams, it's more of a
program-assisted pencil& paper session where you stick to essentials.
You don't get carried away with dozens of useless diagrams. You don't
have all sorts of IDE dialogs that can generate complex UML pictures for
you - you have to think through what you really need and draw them yourself.

For me UML, as a good notation, has incredible expressive power when
it's used to articulate a high or medium-level design problem. "Can I
make this use case work with these objects talking to each other in this
manner at these times" kind of thing. It has rather less utility - again
to me - when it's used to codify (and hence make rigid) all the
low-level details of methods and data.

More on that latter point: I've often seen people with UML tools
generate hundreds of class diagrams that detail internal structure right
down to the last field, for every "value" object they've got. Plus the
package structure of same. I'm sorry, but I don't really need this.
Especially when it's often the first UML product in a project. It is so
missing the point of design. How about doing some hard work with dynamic
UML to work through interesting use case paths, and maybe then we can
start talking interfaces?

Never seems to happen that way. :-)

AHS
-- 
The user's going to pick dancing pigs over security every time.
-- Bruce Schneier

On Sat, 19 Mar 2011 11:16:39 -0300, Arved Sandstrom wrote:

> For me UML, as a good notation, has incredible expressive power when
> it's used to articulate a high or medium-level design problem. "Can I
> make this use case work with these objects talking to each other in this
> manner at these times" kind of thing. It has rather less utility - again
> to me - when it's used to codify (and hence make rigid) all the
> low-level details of methods and data.
>
I have no problems with designers using Use Cases at that level and agree 
with your objection to creating use cases down to the field updating 
level just as, in earlier days, I hated people drawing flowcharts down to 
the same level. However, some of the nastiest specifications I've seen 
have been the result of a 'designer' thinking he'd finished the job when 
he'd produced a use case and a half page of description. 

The problem was that these use cases described a financial message switch 
where each message could contain one or more transaction details and 
guess what - the use cases made no mention of message validation checks 
and no attempt to describe invalid message handling. An then, of course, 
said 'designer' couldn't understand why we had problems designing a 
regression test suite.
  

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Martin Gregorie wrote:
> Arved Sandstrom wrote:
>
>> For me UML, as a good notation, has incredible expressive power when
>> it's used to articulate a high or medium-level design problem. "Can I
>> make this use case work with these objects talking to each other in this
>> manner at these times" kind of thing. It has rather less utility - again
>> to me - when it's used to codify (and hence make rigid) all the
>> low-level details of methods and data.
>>
> I have no problems with designers using Use Cases at that level and agree
> with your objection to creating use cases down to the field updating
> level just as, in earlier days, I hated people drawing flowcharts down to
> the same level. However, some of the nastiest specifications I've seen
> have been the result of a 'designer' thinking he'd finished the job when
> he'd produced a use case and a half page of description.
>
> The problem was that these use cases described a financial message switch
> where each message could contain one or more transaction details and
> guess what - the use cases made no mention of message validation checks
> and no attempt to describe invalid message handling. An then, of course,
> said 'designer' couldn't understand why we had problems designing a
> regression test suite.

These excellent observations figure into my support (at times but nominal, 
alas) for "TDD" (Test-Driven Dezignlopement) and for the use of "use case" as 
a term to include proper diligence in test-case specification.

I note that Martin's anecdote grounds itself in the notion that test design is 
part of design at the ground, middle and outline levels.  Were the villain in 
the piece to have worked from that ground of being, he'd've had his quotes 
removed.

-- 
Lew
Honi soit qui mal y pense.

On 11-03-19 01:15 PM, Martin Gregorie wrote:
> On Sat, 19 Mar 2011 11:16:39 -0300, Arved Sandstrom wrote:
> 
>> For me UML, as a good notation, has incredible expressive power when
>> it's used to articulate a high or medium-level design problem. "Can I
>> make this use case work with these objects talking to each other in this
>> manner at these times" kind of thing. It has rather less utility - again
>> to me - when it's used to codify (and hence make rigid) all the
>> low-level details of methods and data.
>>
> I have no problems with designers using Use Cases at that level and agree 
> with your objection to creating use cases down to the field updating 
> level just as, in earlier days, I hated people drawing flowcharts down to 
> the same level. However, some of the nastiest specifications I've seen 
> have been the result of a 'designer' thinking he'd finished the job when 
> he'd produced a use case and a half page of description. 

The low-hanging fruit for lazy and/or less than scrupulous BAs and
architects and designers, many of whom are consultants, is use cases,
the highest-level system diagrams, and data models. Doesn't matter if
the rendition is diagrams or text or a mix thereof. This is the easiest
stuff to do, and although this may sound heretical, I think all that
stuff to be the least valuable to an implementer.

The high-level system architecture pictures are pretty and all, and they
are good for impressing the business types, but the technical folks
already know all that stuff. Data models - I am less and less inclined,
as years go by, to see any need to pin down the structure of value
holder classes in stages earlier than detailed, detailed, nitpicking
design. And even then only formally describe what the outside world
needs to know about.

And use cases - this is my opinion - are *only* useful when the
interesting paths are described in detail. Dynamic UML diagrams, text
descriptions, I don't care - just do it. Sounds like your "designer"
forgot his job description...which is to design, not churn out use cases
which is the job of business analysts. Of course, doing the detail work
on use case interesting paths is also hard work...which is why a lot of
people don't do it, and assume that the coders will "get" it.

> The problem was that these use cases described a financial message switch 
> where each message could contain one or more transaction details and 
> guess what - the use cases made no mention of message validation checks 
> and no attempt to describe invalid message handling. An then, of course, 
> said 'designer' couldn't understand why we had problems designing a 
> regression test suite.

I see important information lost at various stages pretty routinely.
It's often because there's been little or no conversation between BAs
and architects and designers and coders and testers as to what the
signoff expectations are on product. How often do you see a situation
where the coders can tell the designers that their work is crap and to
take it back and fix it? Not often, the people for earlier stages
usually have more seniority and more clout than the people who receive
the various deliverables. That should be turned on its head.

AHS
-- 
The user's going to pick dancing pigs over security every time.
-- Bruce Schneier

On 19-03-2011 03:19, Robert Klemme wrote:
> On 19.03.2011 01:08, Arne Vajh�j wrote:
>> On 18-03-2011 01:04, manoj wrote:
>>> Is anyone know any opensource& paid tool which will help to maintain
>>> class hierarchy.
>>> Also suggest some tools, which helps to "Software Architect" for
>>> maintaining the system flows.
>>
>> Why?
>>
>> You want your UML models to provide overview at a higher level
>> than the code.
>>
>> There are not much point in having UML and code providing the
>> same info at the same level of complexity.
>>
>> And since tools are not very good at deciding what is so
>> important that it needs to be in an overview, then ...
>>
>> Write you UML youself, because you know what is important
>> and what is not.
>
> I don't believe in roundtrip engineering (or graphical programming)
> either. There are too many issues with keeping an UML model and a set of
> classes consistent that it's usually harder to work that way than with
> separate models.
>
> Also, an UML model alone does not tell much. For me UML is a means that
> helps communicating because there is a standard way of expressing
> certain aspects of a system. That is best used in a meeting on a
> whiteboard or piece of paper and in documents which mix UML and text
> explaining what's going on. For that it is usually also good to have a
> tool which gives you plenty of freedom and is not too strict about
> enforcing UML model consistency. That's why I prefer Viso with this
> custom set of stencils.

I also occasionally use Vision for UML, but it is still a drawing
tool not a modeling tool.

Arne

On Sat, 19 Mar 2011 15:10:15 -0300, Arved Sandstrom wrote:

> Data models - I am less and less inclined,
> as years go by, to see any need to pin down the structure of value
> holder classes in stages earlier than detailed, detailed, nitpicking
> design. And even then only formally describe what the outside world
> needs to know about.
>
We may differ somewhat here. I attach a lot of value to the ERD if a 
database is a significant part of the design, mainly because a bright, 
hands-on sponsoring end user can typically be taught to read and 
understand one in about half a day. At this point the ERD on a white 
board becomes a very useful design and scoping tool. The most complex 
database design I've been involved in was evolved over about six weeks by 
four of us doing exactly that (the four were the project manager, 
sponsoring user, myself (designer) and an assistant designer. At the end 
of that process, everybody involved were convinced that the database 
would support the system requirements and could be implemented. 
Throughout this stage the only attributes mentioned were keys - the rest 
came out of screen and report designs at a later stage - as you'd expect.
 

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On Sat, 19 Mar 2011 12:51:02 -0400, Lew wrote:

> I note that Martin's anecdote grounds itself in the notion that test
> design is part of design at the ground, middle and outline levels.  Were
> the villain in the piece to have worked from that ground of being,
> he'd've had his quotes removed.
>
Quite. I like to be involved in a project from initial design through 
implementation, testing and the initial stages of live running.

If I design library code I expect to specify the regression tests as well 
as the API and would not be put out if asked to write the test harness 
since doing so may smoke out design errors. Same goes for a larger 
project: if I design it I expect to be involved in integration, system 
and performance testing. I have very little respect for 'designers' who 
walk away as implementation is starting. IMO and IME they deserve their 
quote marks: you could say they earned them.
  

-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 11-03-19 04:38 PM, Martin Gregorie wrote:
> On Sat, 19 Mar 2011 15:10:15 -0300, Arved Sandstrom wrote:
> 
>> Data models - I am less and less inclined,
>> as years go by, to see any need to pin down the structure of value
>> holder classes in stages earlier than detailed, detailed, nitpicking
>> design. And even then only formally describe what the outside world
>> needs to know about.
>>
> We may differ somewhat here. I attach a lot of value to the ERD if a 
> database is a significant part of the design, mainly because a bright, 
> hands-on sponsoring end user can typically be taught to read and 
> understand one in about half a day. At this point the ERD on a white 
> board becomes a very useful design and scoping tool. The most complex 
> database design I've been involved in was evolved over about six weeks by 
> four of us doing exactly that (the four were the project manager, 
> sponsoring user, myself (designer) and an assistant designer. At the end 
> of that process, everybody involved were convinced that the database 
> would support the system requirements and could be implemented. 
> Throughout this stage the only attributes mentioned were keys - the rest 
> came out of screen and report designs at a later stage - as you'd expect.
>  
We probably don't differ by much. I think (and I trust that _you think_)
that you've got to understand the requirements well before you assemble
such a dream team to work on an ERD. In turn there's no question that
detailed design work on an ERD helps stress and refine earlier design work.

On the subject of databases specifically, and also ORMs, I'm now firmly
of the opinion also that no later than some stage of design - not
coding, but design - you've got to have honest-to-God DBAs (for your
target RDBMS) and ORM experts involved. I can think of a one-page
checklist of questions surrounding transactions and caching and locking
and database security and auditing, among other things, that need to be
pinned down as early in the game as you can...not when you're coding.
All of these actually flow directly from business requirements that
business reps can answer directly. I've seen 11th hour decisions that
impacted on all of these seemingly low-level technical factors -
business changing their mind on entity class locking, or simply making
up their mind about data auditing - that end up costing millions of
dollars extra.

AHS
-- 
The user's going to pick dancing pigs over security every time.
-- Bruce Schneier

Hole <h0leforfun@gmail.com> writes:
> On Mar 18, 9:52 am, Robert Klemme <shortcut...@googlemail.com> wrote:
>> On 18 Mrz., 06:04, manoj <mahendrabhandar...@gmail.com> wrote:
>>
>> > Is anyone know any opensource & paid tool which will help to maintain
>> > class hierarchy.
>>
>> There are a ton of UML tools out there, if you want coupling of Java
>> and UML you need to look for "reverse engineering" or "roundtrip"
>> capabilities.  Examples:
>>
>> http://www.borland.com/de/products/together/
>>http://www.gentleware.com/new-poseidon-for-uml-8-0.html
>
> They don't seem so opensource...
> and by my experience, all communities editions of this kind of
> software are almost useless.

For maintaining class/package/er-schema for mid-sized projects I've
been using umbrello and it works just all right. Doesn't have all
features that rose has but does its job as UML drawing tool ; some features
like code import actually work much better compared to rose.

You install it in your favourite linux distribution by adding package
umbrello. 

It might be available somehow inside windows-kde project too but never tried
in m$ platform. 

-- 
Costello the Warrior        St:18/09 Dx:14 Co:18 In:8 Wi:12 Ch:7  Neutral
Dlvl:16 $:0  HP:129(129) Pw:52(52) AC:-6 Xp:14/83896 T:19462 Satiated

On Mar 18, 1:04=A0am, manoj <mahendrabhandar...@gmail.com> wrote:
> Hi,
>
> Is anyone know any opensource & paid tool which will help to maintain
> class hierarchy.
> Also suggest some tools, which helps to "Software Architect" for
> maintaining the system flows.
>

Eclipse.

NetBeans.

JDeveloper.

....

--
Lew

On Mar 18, 8:22=A0am, Hole <h0lefor...@gmail.com> wrote:
> On Mar 18, 9:52=A0am, Robert Klemme <shortcut...@googlemail.com> wrote:
>
> > On 18 Mrz., 06:04, manoj <mahendrabhandar...@gmail.com> wrote:
>
> > > Is anyone know any opensource & paid tool which will help to maintain
> > > class hierarchy.
>
> > There are a ton of UML tools out there, if you want coupling of Java
> > and UML you need to look for "reverse engineering" or "roundtrip"
> > capabilities. =A0Examples:
>
> >http://www.borland.com/de/products/together/
> >http://www.gentleware.com/new-poseidon-for-uml-8-0.html
>
> They don't seem so opensource...
> and by my experience, all communities [sic] editions of this kind of
> software are almost useless.
>

As Arne pointed out, open source is not a requirement.

Which community editions do you find useless?  I find that community
editions and other open source UML tools are about as useful as UML
tools can be.  Would you please list the ones you find "almost
useless" and what you found wrong with them that the more expensive
versions fixed?

Visio is still among the best of breed for UML, though.

--
Lew