Use Case questions

[pab233]

Hi All,

I have a problem with use case diagrams and can't come up with a sensible answer.  So, time to ask the world!

Basically, I am trying to model a system where a set of configuration data is translated to create a file which is then uploaded to a database.  The main application then continually monitors a directory for new data files for uploading.

I am having problems identifying my actors for this system.  The only obvious actor I can see is a user, who initiates the configuration translation.  Any suggestions as to what actor can represent the continual monitoring of files?  (This action will be implemented using timers, but that doesn't seem the right thing to do on a use case diagram!)

Hopefully somebody can make some useful suggestions as this is driving me mad.

Thanks in advance
Paul

[mbc]

Hi Paul

I think your problem is about boundaries.

If I understand you correctly, you want one use case that results in a data file and another use case that discovers the creation of that file and then does something with it.

To me, that looks like you have already made an implementation decision, which is premature in the use case stage. Isn't the goal of the user just to get his configuration data into the database? I don't think he really cares if it is done through a file or by other means. If I am right, then this implementation detail should be left out of the use case. That leaves you the freedom to choose the best solution in the design stage. Use cases are not meant for functional break-down.

If I am wrong, and you have some compelling reason that there MUST be a file there, then I think you are looking at 2 systems that interact.
Actor 1 initiates a use case in System 1 called "Translate configuration". System 1 then becomes an actor, which initiates a use case in System 2 called "Add configuration data". The latter use case is initiated just by adding a file to a directory.

The trick is that the system boundaries should only contain those things that you are actually designing. If interfaces (such as the transfer of data through your file) are already decided, then they constitute a new system boundary with new use cases.

I hope this helps
Mikkel

[pab233]

Hi Mikkel,

Thanks for the reply.  Before I respond, I'd like to say that this is making modifications to an existing system so some of the implementation decisions are effectively pre-made.  For info, there are (at least) 4 separate applications at work here.

To a certain extent you are correct - I do have a scenario where one use case creates a file and another use case discovers it.  However, I was able to model this along your first suggestion as I have obvious actors in place (the user and the database).

What complicates things, and something that I realise I omitted from my original post, is that the same application that monitors for new configuration files also has to monitor for other events (actually the creation of other data files) that do not occur as a result of any predictable event.

As an example, we deal with traffic management.  One of our products is the control box that sits beside traffic lights and contains all the hardware necessary to drive the lights.  If a fault should occur with any of this hardware, the box automatically dials into our central system and reports the fault.  This causes a file to be generated which needs to be interpreted and added into the database.  This is where I was having trouble with identifying an obvious actor.

Your second suggestion is probably the way that I am going to have to go, even though it means that I will end up with several inter-connected use case diagrams.  I think that a lot of my problem has been with trying to get it all into a single diagram and the only way this would be possible would be to have use cases that didn't have any directly associated actors.

cheers
Paul

[pab233]

Mikkel,

Further to my previous reply, what would you suggest is the best way for showing the various bits?

• A single diagram with each application (set of use cases) linking in on to the use case of the next application?
  

• A single diagram, but with each application separated so that it has an actor icon and a system boundary?
  

• Multiple diagrams, one for each application?
  

Thanks
Paul

[mbc]

If it doesn't get too large, I think I would go with option number 2, otherwise 3. I think it is mostly a matter of taste.

I don't like option number 1 because it shows design.

The purpose of a use case diagram is to capture requirements of a system. It takes a lot of discipline for a software developer to stick strictly with requirements and avoiding design decisions, because we automatically get design ideas popping into our heads while considering requirements. When you already have a partly finished systems, it might even be harder. But remember, although the design is already partly settled, the use case diagram is still not the proper place to show it.

As I see it, you have 2 systems with different requirements:

System 1 is required to take some user input and output a file.

System 2 is required to take some input as a file and upload it to the database. The fact that system 2 may also monitor other kinds of files from other sources is not really relevant to this use case. Simply put, use cases just describe things that the actor (which can be a person or another system) wants the system to do.

You could have separate use cases "Add configuration file", "Add recipe for soup", etc. that are separate purposes seen from the user's point of view. The fact that the designer may later decide that they can all be implemented as one single routine that monitors any kind of files doesn't matter to the user or the use cases.
The fact that you already know that it will be implemented this way doesn't matter either. The use case should only show the requirements.

Also remember that use cases are mostly about writing, not about drawing diagrams.

Mikkel

[pab233]

Thanks Mikkel,

Option 2 was the way I thought best as well.  Option 3 would just be silly as there would never be an easy way to see everything.

And you're right - as a software engineer I do spend time thinking ahead of myself and designing as I go - probably because I just want to get on and code it all!   And yes, it does seem to be harder when there is already a system in place as you start wondering whether you can reuse what is already there, add to it, or completely replace it.

Anyway, thanks again.

Cheers
Paul