Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How to find Classess 3

Status
Not open for further replies.

vasudev123

Programmer
Oct 11, 2005
8
IN
Hi All,

I am beginner to OOAD. Please do not feel bad if it is a dumb question.

Please suggest me easy process to identify classes for requirements. Other than identifying noun and noun phrases technique.

Thanks.
 
Ok, I'm getting your point here (I think). The use cases shouldn't be described in terms of the interactions with a screen, rather they should be described in terms of the actions that those interactions represent. So, in my example, "user presses button x" should really be just "x", where x is what pressing button x accomplishes. And, if pressing button x presents another screen to the user, the choices on that screen are implementations of extensions to use case x.

How does that sound?

Bob
 
Correct. Notice that Alan Cooper, inventor of VB and self styles GUI guru in the US uses the term 'Butcon' to imply something selectable, because all the normal terms have implementational implications.

Although the difference seems trivial, the impact is often enormous in practice. Allowing a little bit of 'How' into the use case very quickly cause the work to generate into specifying functions and NOT use cases. Then the <<includes>> and <<excludes>> dont work consistently and all the analysis part implied by UML falls away. It degenerates into an inconsistant documentation technique. When that happens, I have seen developers take UML and convert it into Yordon diagrams to sort out the mess.

This is why I fight for keeping that subtle and appaently trivial difference.

Gil
 
I would say you're quite right to do so, too, so perhaps my example was a bad one. I've given myself a little refresher course on use cases (it's easy to do) and I'm seeing that it's easy to confuse the diagram with the use cases themselves. A UCD shows the use cases themselves and how they relate to one another, but the steps to accomplish each use case are usually documented as well. Use case scenarios will each trace a single path through these steps, and can be each represented by either a sequence or collaboration diagram. There is naturally some debate over how much documenting of use case scenarios with sequence diagrams there should be, from doing every possible scenario to sticking to the important ones to not doing any.

Some good links are

Of course, there are lots more.

Bob
 
As far as I'm concerned, this has been a very interesting and instructive discussion, and I don't recall having to be patient! Thanks Gil.

Bob
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top