• 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
  • Paul Clapham
  • Ron McLeod
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Rob Spoor
  • Devaka Cooray
  • Jeanne Boyarsky
Saloon Keepers:
  • Jesse Silverman
  • Stephan van Hulst
  • Tim Moores
  • Carey Brown
  • Tim Holloway
Bartenders:
  • Jj Roberts
  • Al Hobbs
  • Piet Souris

question on Use Case Diagram

 
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all,
Supposed that a Use Case has a couple of flows of event. There are 2 Actors(say A & B), actor A can execute all flows; actor B can only execute some of the flows. The question is that in Use Case Diagram, how to show the difference between actor A & B. Should I put these 2 actors in the Use Case Diagram?
Thanks & Regards
Waldle
 
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can furthur sub-divide the usecases based on the flows. Say initially u had a usecase named
read&write. And you have different flows for read and write. Now u divide this use-case into
1. read
2. write.
usecase read contains the flow for read and the write contains the flow of events for write.
Now design a usecase diagram where-in you include both these use cases and the required actors.
Now map the usecases to the relevant actors.
Hope im clear,
Vijay
 
Waldle Cai
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vijay
If Use Cases are sub-divided in this way, they will become too fine-grained. Each flow of event may end up becoming a Use Case. And it's hard to manage Use Case Specifications.
Thanks
 
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
And it's hard to manage Use Case Specifications.
Which begs the question: why are you producing them, then?
Anything like this should only be used where it is adding value to the overall development process. Ask yourself, who are you writing your use cases for, and what do they want to gain from studying them.
When you have an answer to this qiuestion, write just enough use case to convey what your readers are interested in learning, then stop.
If you can't find an answer to this question, you are probably wasting your time writing complicated use case documents, and should spend your effort understanding the business needs first.
I apologise if any of this sounds harsh, but there really is no point spending time on documentation if you don't know who its for and what they want from it.
 
Vijayanandh
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Waldle,
I agree with you that if we go on dividing the usecases like this, it may become too fine grained and large in number.
I would like to comment more depending on your audience of your usecases.
Kindly let us know if it is for the End-User(the clients) or for the low level design team else its common for both.
 
Waldle Cai
Ranch Hand
Posts: 34
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Vijay,
RUP is adopted for my project. The client requested that we delivered all major artifacts, one of which is Use Case Model. Off course the Use Case Diagram is also for our designer team's reference. Pls give your comment.
Thanks & Regards
Waldle
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Waldle Cai:
RUP is adopted for my project. The client requested that we delivered all major artifacts, one of which is Use Case Model.


Why did the client request this?

Off course the Use Case Diagram is also for our designer team's reference. Pls give your comment.


So, what is the designer team expecting to get from the use case diagram?
You might also want to take a look at http://www.objectmentor.com/resources/articles/Use_Cases_UFJP.pdf and
http://www.agilemodeling.com/principles.htm (especially the "Model With A Purpose" part)
 
Ranch Hand
Posts: 269
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Be careful with the terminology you are using... Use case model and Use case diagram are not the same thing. A Use case diagram is an UML artifact giving a global and summarized view of the functionalities the system is offering from the actors point of view.
This diagram should be completed with a textual description of the use case, while describing the steps of the scenario.
I advise you not to think of your use cases in terms of flow, but rather ask yourself why is A using the system? Why is B using the system.
For example, on a computer system, you have users. Among these users, there may be administrators. Administrators should be able to act as a normal user , but they also have superpowers (that is to take your terminology actor A can execute all flows; actor B can only execute some of the flows. ).
Some use cases may be:
User use cases
==============
-User logs on the system
-User changes its password
-User opens a file
...
Administrator use cases
=======================
-Administrator consults the log file
-Administrator changes the rights on a file
...

W.
[ July 30, 2002: Message edited by: Wilfried LAURENT ]
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Just my thoughts:
Human actors should be identified by role. However if the purpose of the use cases is to record the requirements and the stakeholders interests, showing the actor that drives all the scenarios seems enough.
[ July 31, 2002: Message edited by: Jose Botella ]
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic