Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

all u need are use case, sequence, class & collaboration

 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I feel all we need is use case diagrams, sequence diagrams, class diagrams and collaboration diagrams to go at a deliverable.
We can always go onto delivery related UML diagrams at the end of the cycle.
What you experts think??
Kishore.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not following you. Could you rephrase a bit?
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Kishore Dandu:
I feel all we need is use case diagrams, sequence diagrams, class diagrams and collaboration diagrams to go at a deliverable.

If you want to say that you need to produce all these before starting to code, I would say you might need much less.
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I mean is those are all the diagrams/discussions about main parts of the system to realize a production worthy system.
(assuming u have very good coders handy, if not it does not matter which way you go).
Kishore.
 
Tonny Tssagovic
Ranch Hand
Posts: 226
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How about non-functional requirements? like performance, and the illities like maintability .. how about other info like delivery date, and the technologies/methods/standards that must be follwed..where are u gonna put them, so one could "test" your system up against them?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I like to think a lot about packaging, too. And we are forced to diagram deployment - how many servers in how many sites, what kind of state synchronization or data replication, etc.
You might enjoy Scott Ambler's Agilemodeling.com. He talks a lot about building only the models you really need, how to know what they are, good reasons for documentation and bad reasons. It all sounds related to your original questions.
 
Kishore Dandu
Ranch Hand
Posts: 1934
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see not much enthusiasm for deployment related diagrams. What many high profile clients do is, hire a full time/consultant who is good at figuring out merits of partitioning, clustering and network management and go that route than wasting time of so called deployment diagrams.
I am not sure if there is a big practise to look into any performance related diagrams. But, I would consider them to be more looked upon when the actual implementation is 80% completed.
Kishore.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Tonny Tssagovic:
How about non-functional requirements? like performance, and the illities like maintability

Those need to be addressed, certainly. But do they need to be formally documented?
.. how about other info like delivery date,

A release plan, regularly updated, is important, I'd think. I very much like the XP approach for this.
the technologies/methods/standards that must be follwed

I don't think those need to be documented, but lived (and adopted) by the team. Your mileage may vary...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic