Author
Topic: Use Case Alternatives (Read 4487 times)

I am currently writing a harvest management system. It is closely coupled with an existing growers payment system.

To inform the harvesting system of the existance of a particular paddock/field, the user can key in the details OR sync with the growers system. The two use cases share none of the use interface but much of the back-end code.

This discussion brings up an interesting point- how far down into system operation should one go in developing use cases? It seems to me that, with OO design in particular, it should be possible to abstract various parts within a system and treat them as "actors," at least from the perspective of another part of the system.

I am currently working on a design for a fully autonomous embedded data communications system for real-time system control. There is (with the exception of maintenance operations) zero direct interaction with human actors. IMHO, it would be useful to do a fairly comprehensive service-based decomposition, with use cases describing object behavior at each level of decomposition. There is, however, a point of diminishing returns- the question is, when does the design reach that point? In some cases, customer requirements for software documentation may dictate this, but how does one decide when the decision is entirely up to the designer's discretion?

Cheers,Fred Woolsey

Logged

Fred WoolseyInterfleet Technology Inc.

Always be ready to laugh at yourself; that way, you beat everyone else to the punch.

I'm a new guy here so please keep that in mind. But it has been my experience that you should go down as far as you think you'd have to go for the audience of your use case to be satisfied with the implementation. If it is important that the audience know something, you include it. If not, don't.

I frequently design use cases at a very high level for user sign-off. But, I then design "technical" use cases that drill into much more detailed scenarios for consumption by implementers.

I agree. If the requirements aren't documented in a use case, they will need to be documented in some other way... so why not use a consistent methodology? Of course, you could always "just write code," but this doesn't work well in a collaborative development environment.

Cheers,Fred Woolsey

Logged

Fred WoolseyInterfleet Technology Inc.

Always be ready to laugh at yourself; that way, you beat everyone else to the punch.

What we are dealing with here is the fundamental question of model granularity: Just how detailed do you need/want your model to be?

IMHO, granularity does not matter that much in the use case description as such, though it is critical in the next level, which is detailed in interaction diagrams, activity diagrams, state machines, deployment...

What matters most to me in use cases is:

1. To discover the most general path. Example of a "most general" use case: I pick up the phone, wait for the dialing tone, dial, receive the "ringing" tone, someone answers at the other end of the line... [until] we finish our conversation, and hang up. If I solve that general use case successfully, I have solved a very high percentage of a useful phone system, even though there are tons of exceptions, error conditions, useful add-ons, and so forth, which are not covered by it.

My experience is that the most efficient way to detail use cases or scenarios is by means of sequence diagrams (though I don't deny the usefulness of other types of UML artifacts). In other words, I derive sequnces directly from use cases. Why go through all those text details for scenarios, when you are going to model them in sequence diagrams (or, if you wish, in activity diagrams or state machines)?

EA can automatically tansform your sequence diagrams into event lists, either by means of "Toggle report view" in the menu bar, or by generating your HTML or RTF documentation. So why bother in writing detailed scenarios? (The only reason that occurs to me is because another modeler is going to do the blow-by-blow interaction modeling, and you want to specify what this other modeler is going to do.)

Then: How much detail should go into interaction diagrams? In theory, a solid model should go down to the CRUD level (create, read, update, delete data items). In practice, however, you would get yourself bogged down if you try that level of detail, and your project will become prohibitively expensive, or worse...

Of course, there are situations in which you have to plan to go to that kind of level, because that particular piece of the system is just so critical that you want to have a high-precision model before you commit to code. But that is not the usual situation you will have in most commercial systems development.

So, I will go along with Fred in "that you should go down as far as you think you'd have to go for the audience of your use case to be satisfied with the implementation."

Do you have a pretty good communication with the programming staff, or you are doing the programming yourself? Then, you don't need to go to the CRUD level: model just enough so that all requirements and important conditions are covered.

Let me use this opportunity to stress that use cases are not the best way to communicate general models for users: process models should be used for that purpose.

I hope this helps, though I would agree that we have barely scratched the topic.

One of the main uses of use cases for me is to bridge the gulf between the tech guys and the business owners on a particular project. If I need the business guys to be able to read, understand and approve of a particular piece of functionality, it gets a scenario. Even if that means taking the scenario to the CRUD level. So, basically I agree in the majority of circumstances that "detailed" scenarios are not needed. Again, it comes back to being all about the audience and what they need to know.

So, that begs the question, "What do they need to know?" My simplified answer is if not knowing and approving something could cause an interface change down the road, then they need to know. of course this is a rule of thumb and doesn't apply everywhere; YMMV.

You have made a very valid point. However, let me try to remark on something that can save us all time and avoid redundancy in many (if not all) situations:

If you have no urgency to quickly write and present your scenario in text format, you can make a sequence diagram, from which you can automatically generate the corresponding event list. The latter, in my opinon, is just as clear and probably crisper than the text description. Example: customer contacts salesperson; customer inquires about product; salesperson determines availability of product...

The great advantage of doing things this way is that you have a single point for modifying your scenario in the model (namely, your sequence diagram), and an automatic function (HTML or RTF documentation gen) for generating and regenerating your text description.

Otherwise, if you make a text description, and then make a sequence or activity diagram from that scenario, you have two places where you have to introduce modifications in your model: your text description AND your diagrams.

Of course, lets emphasize once again that this is just an exchange of ideas and experiences, and that the most efficient way to do things in certain circumstances is not the the best or prefferable way of doing them in other places.

I'll definitely experiment with what you are suggesting. In situations where I know I'm going to have a sequence diagram for a particular path anyway, it does seem to make good sense to go ahead and make one, even during the "high-level" design stage since EA can generate the event list off of it.

I've got a situation right now on a project where I needed to get to the CRUD level on one particular use case (the business owner provided a much higher level of detail than normal in their requirements with regard to a single algorithm). I've already detailed it out with a scenario, but I think I'll do a sequence diagram as well and compare the results.

Thanks for the discussion and the suggestions. If this works out, it will save a lot of time and make the model easier to maintain. Thanks again,

1) Why go through all those text details for scenarios, when you are going to model them in sequence diagrams (or, if you wish, in activity diagrams or state machines)?

2)How much detail should go into interaction diagrams? In theory, a solid model should go down to the CRUD level (create, read, update, delete data items). In practice, however, you would get yourself bogged down if you try that level of detail, and your project will become prohibitively expensive, or worse...

Hi Jaime,

In response to your 2 questions above, the following is the way that I view use cases and so how I utilise them :1) My use cases capture the *requirements* of my final system so -(i) {Customer sees the Use Cases}I can show my customer the FULL requirements of the system (including all scenarios). When they sign off on these requirements I know that they can not come back and say "Hey I never sanctioned that!".

The customer has confidence that the system will cover every eventuality.

CRUD operations usually appear as one of C,R,U,D as the Basic Flow and the others as Alternative Flows (alternate scenarios). These Alternative Flows are usually uncomplicated to write as variations of the Basic Flow. Therefore it does not take much effort to write them in text version.

If CRUD operations need to be split into separate use cases then the fact that they are so different means that the effort in writing a new use case will be worth it in the end.

(ii) {Test Cases derived from Use Cases}All of my test cases are derived from the Use Cases (with maybe some information from the Supplementary Specification). If I write out all scenarios - then I know that my test cases will give 100% coverage of the system.

Not writing out all scenarios means that my test writers have to "discover" the unwritten scenarios that the Modellers will develop. This could lead to functionality which is not tested for, or new tests for functionality which is not included in the model / code.

(iii) {Modellers derive UML diagrams from Use Cases}Experienced modellers will probably create CRUD UML diagrams automatically. If you have an inexperienced modeller, having ALL requirements specified in the Use Case means that there is no possibility of them 'missing' the unspecified scenario.

(iv) {User Documentation derived from Use Cases}Most often when a user most needs to read the documentation is when they are doing something which is outside how they 'normally' use the system, i.e. alternative scenarios. If these alternative scenarios are not written in the Use Case, the tech writer will have to "discover" all of these to document them for the user.

Essentially you could rely on the "Head Knowledge" of experienced Test Writers, Modellers, Tech Writers for items (ii), (iii) and (iv) - but if one of these gets hit by a bus in the morning (all 3?) it could be difficult to retrieve this information.

2)If you are using EA to generate code then the more detail you have in your UML diagrams the more complete your generated code will be.

If you are not using your UML diagrams to generate code then only put as much information into the diagrams as is required to communicate the idea.

1. Business process use cases2. CRUD use cases3. System admin use cases

"Business Process" use cases define the requirements of a tool (i.e. software system) to support a particular business process. Potential users should immediately understand these use cases and more importantly, recognise the value that they provide.

These use cases should consume the bulk of the use case modelling effort.

"CRUD" use cases ensure that the life cycle of system objects can be fully managed. For example in a video rental store, the business process use cases might be "Acquire video" and "Rent video". There is also a need for "Dispose of video" so that damaged, obsolete or stolen videos can be removed from the system. This use case will also be required to correct data entry errors. However, it is natural that the potential users of the system will see little value in this use case. In some situations they will not even poperly understand the purpose of a CRUD use case.

In some situations, scenarios can be used to reduce the total number of CRUD use cases as the example below illustrates:

1. The system displays the following options 'Add', 'Change' or 'Delete' a ...

Scenario 1: The user selects 'Add' option at step 1...

Scenario 2: The user selects 'Change' option at step 1...

Scenario 3: The user selects 'Delete' option at step 1...

"System admin" use cases are use cases that provide pure system administration functions. For example, if a secure logon is required then some mechanism to add/change/delete user details will be required. Users will most likely be even less interested in these use cases and may really struggle to see much value in them.

The dilema is how to keep the users interest and involved without boring them with lots of use cases that they regard as rather uninteresting?

A simple strategy is to group the use cases into the three categories described above. Each category can be sent to different group of reviewers.

A more radical strategy is to abandon use cases all together for the "CRUD" and "System Admin" categories. Replace them with simple statements of functional requirements. For example:

The system shall allow the deletion of video details.The system shall allow user details to be added, changed and deleted.

Also don't forget the use of patterns. If there are a lot of very similar CRUD style use cases why not describe the basic CRUD interaction and then list the objects that the pattern applies to.