• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ranch Hand
Posts: 53
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
<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>
 
Manohar Karamballi
Ranch Hand
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 662
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 227
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi folks,
Thanks all for ur valuable tips..things are more clearer now..
Cheers
Manohar
 
Ranch Hand
Posts: 150
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
reply
    Bookmark Topic Watch Topic
  • New Topic