ooa-ood

recent posts related to object oriented design and programming

The best UML “Use Case” definition I know

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 mentioned the term.

The best UML “Use Case” definition

Here’s the best Use Case definition I know:

A Java Model View Controller example (Part 3)

<< Back to Part 2 of our Java MVC Example

MVC - Handling data-changing events

Whenever the user adds, edits, or deletes data, such as our Process data, all the proper GUI components need to be notified of this event so they can properly update their displays. In this application, when a user adds a new Process, this means that we need to update our MainProcessTable. We implement this as follows:

UML sequence diagram - how to show a web service call

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.

UML use case diagram - visually show processes alvin November 17, 2005 - 5:40pm

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.

 

Use Case UI tip - Keep UI assumptions out of Use Cases

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.

OOA/OOP Koan: No end user

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. ;)