Adam Hinx
Adam Hinx

Reputation: 215

Use Case Diagram <<extend>>

I've created the below diagram for my proposed system but have a couple of questions.

The project has three components: Program (Java), Website, and Database.

Using the program, the user can generate data and submit it to the database. This can then be viewed by the user through the web interface.

As you can see from the diagram, I have "Export Data" <<extend>> "Pass information to website". (the database retrieves the data from the database through PHP). Does this mean that "Export data" needs to be in the "Website interface boundary".

Also, if i were to add a third boundary - is that bad practise?

Proposed Use Case

Upvotes: 0

Views: 1741

Answers (1)

Steph
Steph

Reputation: 2049

To answer specifically your main question, there is no strong requirement concerning links between use cases (such as extend) and use case containment (such as packages or system boundaries)

But apart from that, allow me to say a few things about your diagram that seem very awkward :

  • We should have this information in the diagram: which actor performs this use case? Here I suppose database is not the performer, so except the three use cases at the bottom, no use case in this diagram respect this rule.
  • You can draw lines only between an actor and a use case, not between two use cases. Here, between Export data and Query database for instance, what do you mean? If you mean that part of the export data process will query the database, then you need an <<include>> relationship, with the arrow pointing to Query database, which means Query database is a mandatory sub use case of import data. But well, it is a wild guess...
  • I am not sure your <<extend>>s are correct either. Here what it means is that when you grant permission, optionnally, you may check credentials, and when you pass information to website, optionnally, you may Export data. I am pretty sure it is not what you mean.

To summarize on the last two points:

Main use case ------------> sub use case
              <<include>>

Main use case <------------ optional sub use case
               <<extend>>

It is quite a pain that in UML syntax, the arrows are inverted between include and extend, but it is how it works. Not my fault :)

Upvotes: 1

Related Questions