Hi Folks, Hope everyone are doing great. I have one question regarding Requirements --> UC phase.. Is priciples like reusability could be applied while finding out UCs itself? For ex: I have a requirement where customer views his trasaction. I call this as ViewTransaction UC. This ViewTransaction contains 2 steps. Search for Transaction and View. But my system requires search for transactions at many places. So is it better to have separate UC SearchTransactions? If so, Is it not we are focussing on some development aspects which should be put out of requirements phase? If not, are we not introducing redundancy in UCs namely SearchTransactions flow and hence in all subsequent stages which are based on UCDs? I appreciate comments on this.
The "includes" asscociation is used for just that purpose. It is quite common to introduce a use case that encapsulates common logic required by several use cases and have that use case included by the ones that require it.
It is also very common to overuse use case associations and spend more time discussing wether to use "includes" or "uses" etc. than actually discussing the requirements. Always remember: Use cases should be simple and should just contain enough information to go the next step. For a rough first estimation, for example, it might totally suffice to use what Cockburn calls "one bit use cases", that is, only their names accompanied by some discussion.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
<starting-to-get-a-bit-off-topic> I've often found myself in a situation where the discussion has drifted from the design itself into arguing about the definition of some specific visual notation by the UML specification. Not just use case diagrams. This has happened with every diagram type I've encountered... It's the engineer mind that gets stuck with petty details and it's not easy to drop that perfectionist behavior - it's natural with engineers. You know what they say, programmers know the English syn... I mean grammar better than English students. I'm always adding commas etc. into whatever document I'm reading. </starting-to-get-a-bit-off-topic>
Hello all, The above discussion provided info but it does not precisely answer to my question. Namely, Whether we should think of reusability or not? TIA Manohar
Joined: Jan 23, 2002
Personally, I am in favor of the Experience Factory approach where projects don't explicitly try to create reusable components but aim to fulfill requirements and only the requirements (with the help of readily available experiences provided by the EF). Refactoring existing components into reusable ones (well, I guess the definition of a component already contains the word "reusable"...) should be left to a parallel process independent of the projects. I am not too clear about what you mean by "reusability and UCs" - could you shed some more light on that?
Joined: Jan 23, 2002
After re-reading your original question, this came to mind: Start small. Don't think about reusability from the beginning but first try to get all the pieces on the table - even if it contains serious redundancy. Then start refactoring. Combine, separate, add, remove. After a while, you should have a reasonably well "refactored" set of UCs with not much overlapping. On the other hand, it is not necessarily too wise to think about code reusability when you're still in the process of refining functionality and requirements. The early design will handle the redundancies just fine. In fact, two partially overlapping UCs overlap only in their description, not in their implementation. If the redundant documentation seems to be distracting, go ahead and extract the common functionality into a separate UC.
I have seen abstract use cases that give the salient points of a process. For search, maybe User enters criteria System displays first 'n' matching results User requests next 'n' results System displays next 'n' results User selects one or more items from results User indicates search complete Any number of concrete use cases can reference the abstract one, specify the criterea and results. This would help you build consistent searches across the system. One posting above really rang true - you can spend forever arguing about use case relationships and is this allowed in RUP, is this object oriented, and so on. None of that matters. What counts is discovering requirements and getting them down in a friendly, easy to read fashion so every participant in the project can understand them. Missing one matters. Having it in the "wrong" document matters much less.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
What counts is discovering requirements and getting them down in a friendly, easy to read fashion so every participant in the project can understand them.
Very much true. I was trying to get used to use cases ,and in the process of understanding their use, was already trying to think smart by thinking about abstractions, re-use, etc. (typical symptoms of an OOPS guy ) I too think, as Stan already pointed out, use cases should focus on capturing the business requirements accurately and everything else should be of secondary priority. Doing things in a bit smarter way always helps, but we should never lose focus of the intended purpose, otherwise they will become useless cases Guys have a good weekend.
Joined: Jul 17, 2001
Hi folks, Thanks all for ur valuable tips..things are more clearer now.. Cheers Manohar