Use Case Diagram -Help
i am using Use Cases for the first time for Design.I am really confused about
what goes in the use case and what goes in the sub flows ?
let me give u the example :
a user ftps a file which is then processed and commited to the database.as
its getting processed it generates the commit report and after it has finished
processing it sends out an automatic notification via email at an address
which was stored in the ftp file.now how do i represent this ?
i can clearly find that the user is an actor now and the use case is ftp
batch.now what the system does like validating the file, shredding it into
records and then commiting to the database, generating report and then sending
notification will that be considered a use case ? Please suggest !!
Re: Use Case Diagram -Help
"Vish" <firstname.lastname@example.org> wrote:
>i am using Use Cases for the first time for Design.I am really confused
>what goes in the use case and what goes in the sub flows ?
>let me give u the example :
>a user ftps a file which is then processed and commited to the database.as
>its getting processed it generates the commit report and after it has finished
>processing it sends out an automatic notification via email at an address
>which was stored in the ftp file.now how do i represent this ?
>i can clearly find that the user is an actor now and the use case is ftp
>batch.now what the system does like validating the file, shredding it into
>records and then commiting to the database, generating report and then sending
>notification will that be considered a use case ? Please suggest !!
The use case would be "ftp batch". The details are held within the use case's
description, unless those details will be re-used elsewhere, in which case
you'll take the common functionality and place it in it's own use case. This
use case would then "include" the new use case.
A use case "describes one aspect of usage of the system *without presuming
any specific design or implementation*". Based on this, "shredding into
a recordset and committing to a database" are definitely "specific design/implementation"
features and shouldn't be included in the use case.
A use case is more "what needs to be done" and not "how it will be accomplished".
Implementation details such a shredding into a recordset and committing to
a database will be methods of an object. Sequence diagrams will capture
these methods. Remember that, at the use case level, you are basically capturing
how the system and user interact with each other. Don't get bogged down
in implementation details yet. Perhaps think "only document the system's
responses that have an effect on the user's ability to accomplish their goal".
Such thing as exceptions to the user's inputs fall into this category.
Use cases should also be named from the perspective of the user, not the
system. "FTP-Batch" is a system perspective. I don't know what the purpose
of submitting a file via FTP is, but the name should reflect the user's goal.
So if the user's goal is to 'update their song list' name the use case as
such. I believe one of the goals of use case modelling is to create a model
that the user can understand and therefore validate.
So you can basically reduce this to "user ftp's the file", "validate the
file", "generate a report" and "send notification".
USE CASE: FTP BATCH (give a better name)
DESCRIPTION: Use case starts when the user ftps a file to the system. A report
is generated and the user notified.
PRIMARY (happy) PATH: User logs into the ftp system. User uploads a file
to the system, the system validates the file, a commit report is generated
and the user is notified via the email address supplied in the file.
ALTERNATIVE PATH(S): None.
1)FTP login fails - system displays a failure message - three failed logins
in a row locks out the account.
2)Validation of the file fails - system emails a failure notification to
3)Email notification bounces - cannot do anything in this case(?).
You may want to check out http://www.sdmagazine.com/uml/ for some articles
on use cases. There are many good articles.
Top DevX Stories
Easy Web Services with SQL Server 2005 HTTP Endpoints
JavaOne 2005: Java Platform Roadmap Focuses on Ease of Development, Sun Focuses on the "Free" in F.O.S.S.
Wed Yourself to UML with the Power of Associations
Microsoft to Add AJAX Capabilities to ASP.NET
IBM's Cloudscape Versus MySQL