to split or not to split

[mchiuminatto]

Hi

From time to time when I face the problem of reflect in a use case model the entity maintenance (customer, invoice etc) which requires a Create New, Modify an Delete existent entities,   a question come to my mind:

"do I reflect this as a single Use Case, called Entity Maintenance or do I split it down into three use cases: Create New, Modify and Delete?"

I'd like to know someone else approaches to answer once for all that question.

Thanks

Thaks

[fluxtah]

I have recently been playing with the use case metrics and am wondering this myself.

If you had a use case, Manage Customer, you could extend this use case with Add Customer, Update Customer, Delete Customer.

You could also remove the Manage Customer and make a subsystem called manage customer using a boundary with the remaining use cases part of this.

These are two ways I would probably do it, I would like to hear more :]

- Fluxtah

[sargasso]

Some food for thought:
http://www.evanetics.com/conferences/UC-Part1-demo.pdf

[mchiuminatto]

Well Sargasso, it is clear for me that I'm an use case killer, but this is the first step to move the wheel to point to the right direction.

It's clear for me now that when I'm modeling use cases  I have to put the technical glasses on the table and wear my self the with  business glasses.

But my mind it's a little bit slow to react and I still feel the temptation to define three scenarios to the Entity Administration Use Case:

Scenario 1: Add Entity
Scenario 2: Retrieve Entity
Scenario 3: Update entity.
Scenario 4: Delete Entity.

This sound for me like I'm not removing the mistake but moving it.

(Killing instincts are difficult eradicate)

I think I have to read a little more and think for a while.

Thanks a lot.

[Bruno.Cossi]

Ciao,

this is a hard one to adjust to, especially if one has a technical background.
In Use Case diagram, there are instances when you would want to explicitly define a Use Case for modification and/or removal of something... for example, modification of an Invoice may be a complext process with impact to the business - you need to check whether the accounting period is still open or not, whether the Invoice has been posted or not, entries in the accounting system needs to be changed etc. The same with cancelling an Invoice. As there is complex business process and consequences to the business, existence of the Use Case is justified.
What you are thinking could have its place in the Class Diagram, where on each class you ca define the operations that can be performed on it... so the class Customer could have an operation for its modification, deletion etc.

Bruno

[fluxtah]

Being still really new to Use Case and UML,

where exactly would the Add/Remove/Update/Delete type operations be specified if they do not warrant their own use case? with exception to the above when a simple process such as delete could actually be a long complex business process.

- Fluxtah

[Bruno.Cossi]

A Class Diagram, where you can on each Class define its Operations.

Bruno

[fluxtah]

I was hoping there was somewhere within the requirements or Use Case I could define such information, or at least somewhere within the requirements (which ussualy are in the written requirements I get) so I can then realize it later with low-level diagrams.

take the following requirement.

'We Would like to be able to publish articles to our web-site, but would also need the ability to remove and edit the articles."

Something like this has me stumped.. also with my techie background not helping me much.

first use case I would take from that is Publish Article

I would probably have Remove Article and Edit Article as seperate Use Case... but I am a newbie at this

[sargasso]

Now that is a good example.  Here we are talking about business level transactions that "happen" to have similar names to technical functions.
There are, as you say three use cases.  However I would name them slightly differently just to illustrate my points:
1) Put article on website
2) Remove article from website
3) Maintain article material
The first two are fairly straighforward, moving a source file to or from a live server from or to the users personal workspace. The third I will treat a little later.

Now lets think about UC1 - is that all there is to it? Just a technical file movement function?  Are there any business rules that apply to the situation (or are there likely to be any in the near future)?  Is is a copy or a move? Does the user expect any validation to be done during the move, if so how are exceptions to be handled? Can anyone move anything at all to the server?  Does any material associated with the article have to be moved at the same time (graphics, stylesheets, etc)?  Does the article have to be reformatted to fit into the website (framewidths, etc)? Are there any links that have to be set up on the server to make the article active?  ..... etc
Not quite as simple as it looked.  
Similarly, UC2 can, once its analysed become more than just a simple file movement function.
To return to UC3, one has to wonder what the user expects by "would like to edit the articles"?  Whose articles can a user edit - anyones? What tools do they expect to use to "edit" the articles?  ...etc
Leaving these questions unanswered, and assuming the user can edit any article at all using whatever tool they desire the UC can still be broken down into UC3.1 Create a new article and UC3.2 Edit an existing article.
UC3.1 can be implemented through the following scenario:

[1]User creates article using their favourite tool
[2] User saves article as a local file
[3] User transfers article to website using UC1

Thus, if the above scenario is acceptable to the user, UC3.1 requires no implementation, all functionality is provided elsewhere.
UC3.2 on the other hand requires still more analysis.  The niaive interpretation is that the UC involves moving the article from the website, allowing them to change it, and re-adding it to the website.  Is this true?  Do they expect the article to be unavailable on the site while it is being editted? What needs to be done if this is the case?  Is it to be removed completely - as if it never existed - or is it to be replaced with a redirect to a "temporaily unavailable" notice?  If the latter, what happens if they never return it? ...etc

So, although I have raised a couple of business usage questions about the system, I have not delved into any of the technical issues. Nor have I become concerned about the rules and regulations of use cases in UML.
The three use cases I started with have been converted to a possible four cases.  But before I get stuck into the design of the system, I will just nip back to Mr User and get a couple of these questions answered.

Hope this helps.
Bruce

[sargasso]

Fluxtah,

I just realised I didn't provide a direct answer in that.

The use case provides us with a framework in which to derive detailed requirements. The effort above was an attempt to show how the initial use cases - derived directly from the user "needs statement" - rapidly expands into a set of detailed requirements that can be implemented in a variety of ways.

Both the detailed requirements and the implementation thereof need to be carefully examined by the user and approved as meeting their needs.

So, it is "alright" to start with a set of use cases that "look" like system functions - but the idea is to use these as a means to deriving the true, complete and unambiguous requirements of the system.

[fluxtah]

ah thanks sargasso! That was a good example and has helped a lot, I think what I need to do is be more questionable about requirements which is something I lack due to a non-business background, however I have worked under pressure as a programmer on mainly web projects.

From such an ambigous example I gave (which clients do give for web applications!) you were able to break it down and create more specific requirements, which I need to learn to do.

regards

Fluxtah

[Rob_M]

Might I also suggest UML2 for Dummies by Chonoles and Schardt. They have a good section on Use Cases for beginners, and speak quite a bit about CRUD.

Rob

[fluxtah]

Cool, cheers looks like a good book! I have also been looking at Writing Effective Use Cases  by Alistair Cockburn, the review says it approaches Use Case in written form.

- Fluxtah

[mchiuminatto]

My dear friends I've found this:

http://www.umlchina.com/Indepth/howto.htm

Now it's clear for me that I was focused on the user interface and not on user goals.

So, finally, I will model the Customer Administration Use Case which goal is: to centralize and make available for other subsystems a valuable customer database by mean creating, reading, updating and deleting customers.

My conclusion, this time is :”not to split”, and I say this time because I think it will always depend on user point of view, use Case Model scope (Business, System, Application or whatever) and other factors.

Later, in the analysis and design activities  I will create a class called customer with four services: add, read, update and delete and maybe a boundary class representing a JSP page that will allow the user to interact with this class etc, etc.

Regards.

[fluxtah]

I must say after reading that article several times it's become more clear, also a good google search on 'CRUD Use Case' brings back quite a few results with some ok info.

- Fluxtah