I'm building a news aggregation system that collects news articles from several websites, then classifies them into categories, tags them with keywords and saves them to a database. All actions are activated in the same sequence, begins with news scraping. Everything is put in a loop that runs every 5 minutes.

Trying to model my system using use case analysis, I found only one use-case, with the Timer/Scheduler as an actor. Is that possible, or am I applying the method wrong?

  • Is the data in the database used for anything? – TZHX May 19 '19 at 5:51
  • Yes, the database is shared with another system to query, but my system only does only mentioned actions. – Dong Nguyen Chi May 19 '19 at 6:05
  • 3
    Then you may only have one use case because you’ve only selected a single use case from the wider system to be part of the development. As I understand it, use cases are a tool for helping determine requirements... it may still be worthwhile to you to find more about the consumers of the data so that you can verify that what you’re producing matches their expectations. – TZHX May 19 '19 at 6:09
  • I understand what I need to do. I'm just writing requirement analysis document, and use case diagram with only one use case look quite strange to me. Thanks! – Dong Nguyen Chi May 19 '19 at 6:29
  • Is the database part of your system? Then the other systems which query the database are actors and the various types of query are use cases. If not, then the database may be regarded as an actor paricipating in your single use case. Also think about functionality your system may need to offer to application managers, like parameter settings. – www.admiraalit.nl May 19 '19 at 7:31

Yes, systems can have just one use case. That is quite normal for systems with very specialized, automatic tasks and no human user. This reveals, however, that for such kind of systems, "use case analysis" does not bring you much benefit (except from the result there is only one).

The purpose of this method is to split larger requirements into smaller ones, starting from a "users perspective". For systems like yours that perspective does not help, you probably have to change to a different perspective and split your task into technical operations.

A method which has served me way better than use case analysis over the last 30 years is data flow modeling, and I would heavily recommend that for your problem as well.

Don't let you irritate by the fact text books usually show examples with multiple use cases - text books usually demonstrate a method by using examples where the method works well.

| improve this answer | |
  • I'm writing analysis document for my system and saw everyone around me uses UML, which contains use case diagram. So I just tried to apply UML to my system. Thank you for your great answer. I'll give data flow modeling a try. – Dong Nguyen Chi May 19 '19 at 8:28
  • 2
    @DongNguyenChi: IMHO one of the biggest failures of UML is, the demand for data flow modeling was ignored over several years. And because everyone believes UML is "the only valid standard, so everything else must be crap", data flow modeling (which is quite older than UML) is often ignored. In UML 2.0 the designers finally introduced "information flow diagrams" which might be the best approximation we find in UML today - but it has still not gotten the popularity it deserves.. – Doc Brown May 19 '19 at 12:20
  • The term no real user doesn't make much sense here. Systems interact at least with a single Actor. This in turn must not be a real human but can be anything, even some dead mechanics. – qwerty_so Jul 26 '19 at 17:33
  • 1
    @qwerty_so: ok, I exchanged real by human. Better now? – Doc Brown Jul 26 '19 at 19:15

In this case you have one actor, the timer/scheduler. But you can say you have one use case with all the action involved or separate them, like scrap news, tag news, because this are complex operations.

| improve this answer | |
  • 1
    I just followed use-case checklist here "Is each use case independent of the others? If two use cases are always activated in the same sequence, you should probably merge them into one use case.". So I merged all those operations into one use-case. – Dong Nguyen Chi May 19 '19 at 6:22
  • @DongNguyenChi and that was absolutely correct approach here. – Ister May 19 '19 at 11:56

One use case? Don't stop there. What about systems without a use case?

The ideal automated system has no use case. It just works. Anything that is used is semi-automatic at best.

Your refrigerator keeps your food cool. Puting your food in and taking it out is independent from the system's behavior, that is not a use case. The cooling part is totally autonomous.

Use cases are modeling aids for interactive systems but not all systems are interactive in nature.

| improve this answer | |

This answer is based on the additional information from the comments.

If the database is part of your system then whenever other system requests those data, your system has to offer them (let's disregard for a moment how is it done - this is true also if other system reaches directly to the database1). So from perspective of your system if other system asks for data, your system has to provide that data. So for your system the other system is an actor and the use case would be something like "Provide news data" (or anything you seem relevant).

If your system had sent the aggregated data to some other system as part of your first use case then quite theoretically it may be the only UC you have.

On the other hand you may also consider some sort of administration tasks that has to be done. Those may create additional use cases as well (e.g. add "new newsfeed" or "manage client privileges").

As a rule of thumb if your data comes in, they have to go out. If one use case has only inflow of data there must be at least one other use case which offers the outbound flow of data.

1 One can argue that this is no use case because it is automatically handled by the database engine. This is not true. As already mentioned, database is part of your system. Even if the direct access to the data is offered by database engine, it is also part of your system (even if a legacy one) so your system offers that.

Of course that is a poor way of designing system. The access to the data should be controlled by the system in a more manageable way. So I would definitely recommend building an interface for that. Anyway, you have a use case.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.