RE: (ROSE) At what level should you stop breaking up use cases (with example s)

[Angay, Huseyin (Huseyin)** CTR **]

> ----------
> From:         Vermette, Paul[SMTP:[EMAIL PROTECTED]]
> Reply To:     Vermette, Paul
> Sent:         30 January 2001 13:10
> To:   Rose_Forum (E-mail)
> Subject:      (ROSE) At what level should you stop breaking up use cases
> (with example s)
> 
> Hi Guys, 
> 
> I have a big question, at what point do you want to break up use cases...
> For example lets say your an administrator of a web-based application that
> requires users to "register" and "sign in" in order to use your web
> application. For an administrator of the web application there will have
> to be some sort of user management interface.
> 
> For instance I figure I would have the following system use cases... 
> 
> Admin --> Ban User UC 
> Admin --> Add a User UC 
> Admin --> Delete a User UC 
> Admin --> Change User Password UC 
> 
> 
I would gather these use cases under a single "System Administration"
package. You can then fragment the use cases as much as you want (within
reason), and still keep them as a coherent whole. THis gives you both the
high level view (by looking at them as a single package) and the detail.

> or should it something a little bit more high level: 
> 
> Admin --> Manager Web Application Users UC 
> 
> The thing is, you could probably can do it both ways but have the second
> one with multiple Scenarios.. The problem with that is I see a Scenario as
> a way to accomplish the same thing in a different way (alternative flow)
> or to describe if something is wrong with the system (exceptional flow)
> and of course the main scenario being the basic flow.
> 
> 
Unless you have good reasons for it, it's not such a good idea to mix
scenarios with different outcomes in one use case. One "good reason" might
be that all the scenarions are very trivial, and they all share a theme.


Regards,
Huseyin Angay
Karabash Ltd.
www.karabash.co.uk



> My use case template looks like this... 
> 
> 1. Brief Description 
> 2. Flow of Events 
> 2.1 Basic Flow 
> 2.2 Alternative Flow - Name 
> 2.3 Exceptional Flow - Name 
> 3. Pre conditions 
> 4. Post Conditions 
> 5. Special Requirements 
> 
> Note that this is a SoDA templates and more information is imported from
> the model. What I think is funny is you normally have a "happy" scenario.
> If you go with the second option, you really can't just have one happy
> scenario (unless you use subflows??). Each use case does bring back an
> observable result to the actor.
> 
> Another quick example is say there are system configuration parameters.
> Should we have the following 
> 
> Admin --> Enable Option 1 
> Admin --> Disable Option 1 
> Admin --> Configure Transaction Log Size 
> etc... 
> 
> or 
> 
> Admin --> Modify System Configuration 
> 
> Again same idea... I have read many books and papers on use cases... I am
> just trying to check with other practitioners to see what their comments
> would be on this.
> 
> 
> Sincerely, 
> Paul 
> 
> Paul Vermette 
> Software Architect 
> Spielo Gaming International 
> 1.506.852-7450 
> mailto:[EMAIL PROTECTED] 
> 
> 
> 
************************************************************************
* Rose Forum is a public venue for ideas and discussions.
* For technical support, visit http://www.rational.com/support
*
* Admin.Subscription Requests: [EMAIL PROTECTED]
* Archive of messages: 
http://www.rational.com/products/rose/usergroups/rose_forum.jtmpl
* Other Requests: [EMAIL PROTECTED]
*
* To unsubscribe from the list, please send email
*
* To: [EMAIL PROTECTED]
* Subject:<BLANK>
* Body: unsubscribe rose_forum
*
*************************************************************************