aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Is priciples like reusability could be used in figuring out UCs? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Is priciples like reusability could be used in figuring out UCs?" Watch "Is priciples like reusability could be used in figuring out UCs?" New topic
Author

Is priciples like reusability could be used in figuring out UCs?

Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
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.

Thanks in advance
Manohar
Nilesh Pereira
Ranch Hand

Joined: Apr 14, 2003
Posts: 53
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.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
<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>


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
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
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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?
Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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
Jayadev Pulaparty
Ranch Hand

Joined: Mar 25, 2002
Posts: 662
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.
Manohar Karamballi
Ranch Hand

Joined: Jul 17, 2001
Posts: 227
Hi folks,
Thanks all for ur valuable tips..things are more clearer now..
Cheers
Manohar
Fintan Conway
Ranch Hand

Joined: Apr 03, 2002
Posts: 141
What I have found is that we get reuse from use Cases across projects. That is functionality like 'Logon' is the same from one project to another
Regards,
Fintan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Is priciples like reusability could be used in figuring out UCs?