I think that in this discussion the suggestions still lead to a
functional decomposition.
For me the use cases would be "Add employee", "Remove employee", and,
possibly, "Modify employee data" because that is what an employee
administrator (actor) wants to do and where he needs the support of a
system. This means that your system will have to be able to "maintain
employee records" which will be designed and eventually implemented by
the usual functions "add/delete/update employee record(s)".
The reasons for problems with the definition of use cases are:
- the people who write them
- the names you give them
People: In many cases the use cases are written by the implementors:
they think of bits, bytes, records: the use cases become implementation
oriented instead of problem domain oriented.
Names: The administrator (actor) does not (and possibly should not) know
anything about "records": thus he can only request a system
functionality like "Add employee" but not "Add employee record".
I think that use cases (or at least a first draft) should be written by
the users.
Klaus Jantzen
K+K Jantzen Software Services GmbH
"Eric D. Tarkington" wrote:
>
>
>
> "CHIAM CHOON YEE, LSD" wrote:
> >
> > Packaging related use cases looks neat to me. However, how would I present
> > "Maintain Employee Records" in the main use case diagram? Or would I be
> > forced to place all the real use cases in the main use case diagram? In
> > this case, the diagram would be cluttered (when I start putting in other use
> > cases as well) which is what I want to avoid.
>
> IMO, you probably shouldn't present all details about "Maintain Employee
> Records" in the main use case diagram. You would not put all use cases
> into the main, either. You can make a very simplified main use case
> diagram, create a package corresponding to each of the few use cases in
> the main diagram, and put additional diagrams into that package
> detailing the relationships with that use case.
>
> -Eric
************************************************************************
* 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
*
*************************************************************************
