Kimbo:
With Use Cases, whatever functions happen to pop into the analyst's mind, he/she puts down on paper. There is nothing about a use case in of itself that prods the analyst to discover what he/she is missing. An easy way to visualize this is to ask oneself "How do I know that I am done with my use case diagram?". Answer: There is no way of telling by looking at the diagram. With use cases, and to a little lesser of a degree, activity diagrams, what the analyst is doing is trying to do is force fit reality into his/her limited understanding. That is what data flow diagrammers call a forced, artificial partitioning. DeMarco used to call such an approach a lie.
Analysis is largely about partitioning. Properly utilized, data flow diagrams employ a logical, natural partitioning. If we go way back in time to forced, artificial partitioning, I really don't see progress. In fact, I see the opposite.
Tony
Tony,
You seem to think that UML is just use cases and use case diagrams with perhaps a bit of activity diagram.
I always start from a process point of view, with each activity in the process being a use case, use case package or another process. Use cases are either manual or automated. Model the whole thing from a process point of view identifying the functions along the way and then work down. The data is very much a sideline of this approach and in my opinion is starting way too low. I think you'll potentially miss the big picture if you concentrate on data. But here's the thing, I acknowledge that both approaches can work! It depends more on the analyst.
Anway like I said, I don't think we're going to change each other's mind any time soon. Once last thing before I stop, try counting the number of BA jobs out there looking for UML skills and those looking for DFD skills. I think you'll see that my dinosaur comment, although rather rude, is probably valid.
Kimbo
Off course the UML is more than use cases and activity diagrams.
Anyways, we both agree to start from "a process point of view". Where we disagree is that I believe that identification of the data flows between processes is the lithmus test of completedness of process modeling. And data flows can be used for this lithmus test at the highest levels - that is fundamental to dfds. Use cases do not employ a lithmus test of completedness.
On other matters, Kimbo, alot of people tell me my approach is old. And alot of people tell me that I should focus on what others are doing and follow suit. I see myself as very focused on the essential. Am I right or wrong? I ask you to consider the current norm of the BA community: While analysis is largely about proper partitioning of a system, just say the word "partition" to most BAs and they react like it is some sort of pie-in-the-sky thing that only egg heads at MIT contemplate. Proper partitioning (and this is just one example) is not pie-in-the-sky. It is a basic and relatively simple fundamental of analysis.
Hi Tony, I think you and I had this same conversation a while back...
So, current thoughts: Use Case Diagrams are not a partitioning technique, they show how identified use cases relate to the actors and each other, if that is a useful communication artifact. I use Use Cases all the time, but not the diagram. I too start with a process and decompose it into distinct activities based on timing and who does the work, and describe each activity in a use case format.
While I have been typing this, it has occured to me it would be fun, or at least interesting, if we could take a common domain problem and have different people model it with their technique(s) of choice, like a case study from an analysis course; then we could all see what the differences in the approaches are, rather than just debate them. If anyone reading this has non-proprietary example we could use, do reply and maybe we can get something going here.
David:
Bingo! Absolutely correcto mundo! You win TWO cuppie dolls! Use Cases are not a partitioning technique (or at most, they are a very poor one). The BIG problem of course is that analysis is largely about proper partitioning and use cases are often viewed as a "state of the art" analysis technique. (Same problem goes with user stories.) This is one of the primary reasons why I believe the BA community needs to get back to basics and figure out what analysis is. The BA community largely thinks that analysis is some sort of rough-cut design activity, and when you mention the word "partitioning" to about 98% of BA's their eyes glaze over.
I could argue that, as a process is defined by its inputs and outputs, partitioning (decomposing) needs to focus first on such, but for now I just want to savor your comment.
Problem with Experiments: The need for proper partitioning is especially great on large-scale efforts. Another "grip" of mine is the strong tendency of the experts - especially the experts in academia - to apply an analysis technique on a smallish system project and then, when they have success, to declare that the technique can be also successful on large-scale efforts. What works on smallish systems will often not work well on larger efforts.
brought to you by enabling practitioners & organizations to achieve their goals using: