Which View to Choose on Use Case...

[Tryst]

Hi all, I have to create a Synchronisation application where users can create jobs, individual tasks that can be run under a job, a schedule for a job, and alerts for jobs to be generated based on certain criteria (its a bit like the Jobs section in MS SQL Server).

Now, the application will allow a user to create, edit, delete and view these - so applying these main functions into a use case is not too difficult. But, when the application triggers a job to execute, I am now in a different view/state of the system in that the jobs are now executing, along with its assigned steps, and alerts can be triggered.

I am confused as to how I should really model these two views . Should they all be in one USE CASE diagram, or as a separate USE CASE diagram? (as I have the application interface that lets users set up jobs, and then these jobs are triggered based on time events)

Thanks

Tryst

[mikewhit]

A Use Case just describes an interaction with the system being modelled.

I try to take the approach that a use case accomplishes one of the requirements goals of the system.

If there are goals which are simply variations of each other, then they can reside on the same diagram when they have other elements in common.

Where there are distinct behaviours represented, they should be on different diagrams.

I would say your two views should be on different diagrams.

You shouldn't be trying to draw a system flow diagram, just stating what has to get done in terms of the high-level behaviour. Don't forget you can use a subdiagram if you really want to say what other jobs a use case consists of.

Alternatively you can use a 'system actor' to represent the scheduler, and then have another use case in which the scheduler takes part.

The examples in EAExample.eap are not very good on this, unfortunately, but have a look if you have not done so.

[Tryst]

Yeah, i've got down the '2 diagram' route.

Thanks

Tryst