Every time I read an article or book about UML “Use Cases” I cringe a little bit. Every author says something like “Jacobson left the definition of a Use Case too open,” and then they try to work through some elaborate scheme of what a Use Case means to them. IMHO, the best use case definition was created in the early 1980s, long before Jacobson coined the term.
I recently started to model an application that makes extensive use of web service calls, and my customer asked me to include a UML sequence diagram to show the flow of calls in the system. This prompted me to wonder, "What is the correct way to show distributed systems (like a web service) in a UML sequence diagram?"
If this link is correct, in a UML diagram you show remote systems as actors.
OO Koan: You are assigned to work on a project, but you cannot communicate with the end user -- how do you develop the software?
(Answer: Lots of luck. ;)
I ran into the perfect situation this week that defines why you should not put UI assumptions in Use Case (or task) documentation. A customer decided that they really wanted to change a UI from the proposed tabular approach (with potential popup windows) to a tree view. If the use case mentions things like "double-click", "press OK", and UI phrases of that nature, the use cases would need to be re-written. Without those UI assumptions they should be fine.
Question: I want to visualize the activity in a use case ... what UML diagram can I use to do this?
Use an activity diagram. These UML diagrams are good for visual workflow modeling. Swimlanes in UML activity diagrams can also show the behavior of different actors within a workflow process.
Question: Is there a UML diagram to visually show the processes in a system?
Yes, you can use use case diagrams to represent the use cases (processes) in a software system. Use case diagrams show the actors in a system, and the ways in which these actors use the system.
This is why I use the terms "use cases" and "processes" interchangeably. IMHO, "use case" is a fancy way of saying "process", or perhaps more accurately, user-initiated processes, or event-driven processes.
