Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In projects with many use cases, it's valid to create different use case diagrams, one for each screen? Or I shouldn't guide myself on the GUI of the software to make this, why?

As a clarification, the software does already exist, and I'm just documenting it for my undergraduation final project.

share|improve this question
add comment

3 Answers

up vote 3 down vote accepted

As there is no inherent relation between a use-case and a GUI screen, it does not really make sense to divide use-case diagrams the GUI screen they relate to.

To elaborate, a use-case describes how an external actor (either a machine or a human) interacts with a system to achieve a particular goal for that external actor. If the use-case does not involve an interaction with a human, there are no GUI screens involved either. And if the use-case does involve a human actor, then the GUI could be anything from a single button (e.g. to print the current document to the default printer) to multiple screens (e.g. a class creation wizard in an IDE).

Good use-cases don't even mention the existence of a GUI. It just specifies that actor X provides A, B and, optionally C pieces of information and leaves the how for the design team.

If there are many use-cases, then it can be good to split them into multiple diagrams, but that should not be based on a design choice (how the GUI is organised). Better lines of division are

  • having use-cases that deal with similar functionality on the same diagram
  • having use-cases that interact with the same actor on the same diagram
share|improve this answer
add comment

I think you'll run into trouble as you design an application by thinking there is a strong relationship between the tasks requirements of an application and the number of screens (forms, web pages, etc). Even simple CRUD apps have that one requirement with too much complexity to handle this way.

Take the example of a simple data entry grid with the ability to edit the data inline. Easy enough to have some update button, the controls are editable and there are save and cancel buttons. For whatever reason, this is confusing to the users, so you decide to have a separate pop-out screen of the updated record. I don't see why you would have to go back and change the use case diagram since the user is accomplishing the same task.

What if you start to use an outside data provider (stock pricing site) that will update these data through a service? That requires you to create another use case, but there are no additional screens.

Many developers can get into this trap with data base design as well. You don't automatically create a new data entry form for every table and every form doesn't require a database table.

share|improve this answer
add comment

I agree with Bart - use cases are not broken down by screen, it's about what you want to accomplish. For example, you may have a use case that describes what data a customer supplies to create a customer profile or what data the user would supply to make a payment.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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