Talk:Use case diagram

From Wikipedia, the free encyclopedia

Todo: Use "37 Things that Don't Work in Object-Oriented Modelling with UML" to discuss the issues with Extends and Uses notation.

[edit] This article needs a lot of work

Difficult to know where to start really. Would anyone care to defend what I think is a very dodgey use case diagram for the restaurant?

• Wait staff order food, not the patron
• The chef prepares food for no obvious reason
• The cashier pays for food as well as the patron
• ...

--Malleus Fatuarum 17:43, 22 August 2007 (UTC)

That's not how I read the diagram. Each line between objects is a different relation. Thus the cashier might accept $ from the Pay for Food use case. Similarly, the Wait Staff might accept the order.

And you have identified a missing relationship between Order and Chef.

Ideally, one labels the lines between objects with a verb, to highlight the differences between relationships.

Thus the criticism is really about the diagram's state of completeness. And you have identified that the diagram is not yet ready for the workgroup to critique, as it remains incomplete or unapproved.

Yet where do we draw the line; it is possible to get bogged down when the developer or other user can still prototype parts of the diagram and highlight what remains to be completed.

--Ancheta Wis (talk) 17:12, 6 December 2007 (UTC)

I think you misunderstand the notation for, and the purpose of, the use case diagram. It is a black box view, there are no objects in a use case diagram. The ovals represent use cases, not objects. --Malleus Fatuorum (talk) 20:25, 6 December 2007 (UTC)