Activity Diagrams kill Use Case Diagram

[fperedo]

Hi!
This is just a philosophical question but... I have just realized.. anything that can be represented in an Use Case diagram can be represented in an Activity Diagram (and Activity Diagrams have IMHO lots of advantages over Use Case Diagrams). Since every use case can be represented as a step in an activity diagram...
Why should I make Use Case Diagrams? (They seem redundant to me)
Note that I think that writing (or diagramming) "use cases" isa good idea, but why should I diagram them using a use case diagram, if an activity diagram is far more expressive...?

[thomaskilian]

Well, not going into detail as this has been discussed in broad all over the web: UC diagrams give you a more abstract picture. They focus on the outcome, not on the how-to. Very roughly said...

[Jan ´Bary´ Glas]

You may ask two questions What do I use the system for? (Use Cases - considers goal) How does the system work? (Activity, sequence, collaboration, interaction overview)
And the business asks Why do I need such a system... but that is different question.

[fperedo]

Hi!
Thanks for your answers.
I also believed that UC diagrams were more abstract, but... a high level activity diagram is "as abstract" as any UC diagram (and I really can't see any disadvantage of using it that way)

If use cases are like folders with a "what name" on which we store an activity diagram (explaining "how")... the problem is that the steps of the "how" aren't (can't be) always and the lowest level (binary code)... so the steps in the "how" are "whats", and each "what" will have and internal "how" described in other "whats":

List of What
How for each What
The How is a List of What of lower level of abstraction
How for each What...

So, if a particular "activity" (or use cases) is a what or a how.. it depends on the particular level of abstraction you are currently thinking... but the artificial separation between UC diagrams (what) and Activitiy diagrams (how) doesn't seem help a lot with this...

I think the problem of making it easier to solve complex problem using a "fractal" of hows & whats, was structured programming... and activity diagrams match structured programming a lot better than UC diagrams... and UC diagrams arent really that much object oriented (they are very procedural to me)... so... Am I really wrong to think that the whats and the hows are really just the same thing (depending on you level of abstaction)? (and that UC diagrams... are just an unnatural construct?)

[jaimeglz]

Hi:

Activity diagrams are direct descendants of the flow charts created in 1947 by Von Newmann and Goldstine for the ENIAC programmers. These charts are a great way of introducing you to algorithmic thinking, and oftentimes work well as communication vehicles for simple flows. (They are not so good when the flow gets somehow involved and convoluted.)

The reason many people like them is that they seem to "naturally" model a flow. However, if you try to model with them anything beyond a few simple flows they are (in the words of Fred Brooks in The Mythical Man-Month) "an obsolete newsance". The current world-wide consensus in systems modeling is that Brooks is 100% right on that one.

Use cases (as ugly and strange as they seem at first) are seven-league boots that enable you to model a whole modern, object-oriented, system's behaviour in a matter of minutes (of course, if you ommit detailing them).

You cannot model many OO features, or user interface behaviour, with flow charts or activiy diagrams. For example, it is quite hard to model a modern menu with an activiy diagram, but with use cases you can do it in a jiffy.

Use cases permit you to naturally distribute work in a project, estimate project size, specify pre- and post-conditions, re-use, inherit, specify scenarios with text or with sequence diagreams, and (besides many other features) help a great deal with your tests.

Of course, if they don't make sense to you, don't try to force them into your project, and use whatever you find most useful and adequate.

There's a lot of dogma going around UML these days, so be careful not to do things just because some important sounding manual says it ought-to be so.

Hope this helps,

jaimeglz

[jeshaw2]

Actually, Activity Diagrams are derived from  Pitri Nets, not flow charts, no matter how much they look like them.  But let's not get into that issue in this thread.

Personally, I would not want to substitute an Activity Diagram for a Use Case.  The Use Case describes an interface that a system presents to an actor.  (This is closer to the old "story board" approach than it is to an Activity Diagram.)  At this level, we are more concerned with the nature of that interface, not with how the system's behavior is implemented.

When I  associate a diagram with a use case, I use a Protocol State chart.  It makes clear the nature of the messaging between the system and the actor(s) and the conditions under which those messages may flow.  This is not the stuff of Activity Diagrams.

-Jim

[jaimeglz]

Jim:

1. Petri-nets were invented in 1962 (around 15 years after flow charts), and no-matter how much mathematical formality they have, they still use Goldstine and Von Newmann's arc and node fundamentals.

2. Yes, I know the formalistic explanation given for activity diagrams in the UML 2.0 specification: but let's not miss the point. The question that started this thread was: Why use use-case diagrams, if you have activity diagrams? We must give a simple, straight-forward answer, and not make things more complicated.

3. Remember why the so called "structured methodologies" repelled people?: Because with all that rigoristic jargon, system analysis and design were not getting anywhere. It was, however, just absolutely de rigueur to pretend to have all these ultraprecise mathematical concepts underlying a modest model. Productiviy went down, and projects just went down the drain because of analysis-paralysis.  

Cheers,

jaimeglz

[mikewhit]

Remember why the so called "structured methodologies" repelled people?:

Hang on, I thought OOA, in particular the Shlaer-Mellor approach, was very appealing and productive ! And previously, I enjoyed doing the Yourdon-Constantine stuff !

So speak for yourself !!!



And don't listen to the Agile FUDmeisters - or at least, listen critically

[thomaskilian]

3. Remember why the so called "structured methodologies" repelled people?: Because with all that rigoristic jargon, system analysis and design were not getting anywhere. It was, however, just absolutely de rigueur to pretend to have all these ultraprecise mathematical concepts underlying a modest model. Productiviy went down, and projects just went down the drain because of analysis-paralysis.  

Firstly, welcome back aboard

Of course the "structured" method mostly leads to analysis paralysis. But unfortunately UC modeling does not necessarily prevent us from the same fate. It's unfortunately so that Computer Scienctist are teached more like Engineers, not like Artists. Nowadays people are soooo much dependent on numbers. They seem to loose contact to Reality.

[sl@sh]

My experience with use cases is that they take less effort to design and are better suited as a basis to discuss requirements with the stakeholders than activity diagrams.

The latter can be just as informative, but only to those who are already familiar or at least comfortable with a flow-of-events type of diagram.

IME the algorithmic nature of activity diagrams tend to make designers include some aspects of the solution, and that shouldn't be part of the requirements. It's already hard enough to make the stakeholders think in requirements, not solutions - so don't make them think in algorithms! (at least, not from the start)

[mikewhit]

I see Use Case as being in the Requirements/Analysis sector ("what"), whereas Activity Diagrams live more in the Analysis/Design region ("how").

Different focus.

[«Midnight»]

I'll go with Mike here.

Look at it this way. If you don't have something that needs doing (the "what") then work on doing something (the "how") represents wastes resources.

This does not imply that you cannot have a valid model if you don't have a use case. It does mean that you should be able to answer the "what" questions before you embark on resolving the "how" issues.

David

[jeshaw2]

Remember why the so called "structured methodologies" repelled people?:

Harrumph! None of my stakeholders were repelled by Structured Methodologies;  we all remembered the snake-pit logic that preceded them. And, analysis-paralysis is the fault of the analyst, not the methodology.  

[fperedo]

Hi!
Thanks of all the answers (this discussion is getting interesting)
First I would like to clarify somethings about my initial post... i do like (and think is good an important) to have use cases describing the behavior of a system.
The thing I don't like is the use cases "diagram".
A funny thing about use case diagrams is... that they don't describe how a use case works... instead of that they describe "the list of use cases you have". So... use case diagrams are... for describing the internal behavior of a system... at "relationships between use cases level"

But... when someone says "I am going to describe one use case" he is not going to use a use case diagram (strange thing don't you think?), to describe the behavior inside that one use case he is going to use communication, or sequence, or activity diagrams, or plain text...

So.. we have 2 kinds of diagrams (domain specific languages?): use case diagrams for relationships between use cases, and "whatever you want" for  the "inner workings" of each use case.

But... as we all know, if there are relationships between use cases, is because some of them "extend" or "include" or "inherit" or "invoke" from other use cases...  and that happens because their "inner workings".
So, you may realize that 5 use cases include a "common abstract use case" because after you modeled those 5 use cases, you realized that a good part of their internal description was pretty much the same, and you decided to "extract to" the common functionality.

The fundamental question here is: "if 2 use cases are somehow related at the use case diagram level... how is that relationship represented inside each one of those 2 use cases" What is the official equivalent, in communication, activity or sequence diagrams for an "include" relationship? and for a "extends" relationship? and for inheritance? I believe there is none... so, our use case diagrams have no foundation (the internal descriptions inside use cases just don't justify the existence of the external relationships represented at the use case diagram level).

To put it more clearly... imagine that you have a activity or sequence diagram, that describes 1 use case... and that you could select a part of that diagrams, right click and select "extract to <<included>> use case", and have all the selected elements automatically extracted, moved inside a separated use case, have an <<include>> relationship create between the old use case and the recently extracted, and represent that <<include>> relationship inside the sequence or activity diagram... how?

(I know refactoring for UML might be too much to ask for, and I don't expect to see such functionality in the near future, but, before being able to do it automatically, UML should have at least enough expressivity to do it "by hand", don't you think? is there a way to do it? or a just should live thinking that use case diagrams should be done even if they have no foundation?)

I think activity diagrams kill use case diagrams, because there is a known and established way to "nest" activity diagrams using composite activities, and ways to call activities in one activity diagrams from another... it is always the same language (you just make it less and less abstract as you get closer to implementation details, but you are always "talking" in activity language, but, with use cases, things get disrupted because you can't call an use case "ball" form inside an activity diagram (or a sequence diagram, or an communication diagram)... or can you?)

[jaimeglz]

Hi all!

Let’s suppose you are at the stage of your project when you have not yet committed to architecture, but you have to create a model with the crucial functional requirements (the “what”, as some contribs. to this thread have pointed out). You would need, for example, to model some behavior to log into the system, and behavior for every one of the main menu items (lets say: Planning, Progress Reporting, Results, Follow-Up, tons of administrative stuff, so on). At this stage, you don’t know if you are going to develop through programming, buying packages, borrowing from legacy, prototyping, or whatever.
Inspired by something you just read in the EA Forum, you hop into your model-1947 flow chart vehicle, or its (not-so-different but more sophisto) activity diagram model. After about a month or so, you come out proudly with a humongous quantity of diamond-decision-studded diagrams. But (chucks!) after all that work, it is decided that Windows XP natural log-in is sufficient, and makes life easier for the users. Something similar happens to your beautiful model of the menu: some bum comes out with the news that the customer already has all the licensing to use Share Point, so the menu will not have to be programmed. And then... (“No! Not my flow model of Gantt-chart behavior! Please!”), but change is relentless, and it goes on, and on, and on.
Suppose, instead, that you have chosen to model this behavior with use cases: an Enter the System (or Log-in) use case, a Planning use case, and so on... What would be lost after deciding on architecture? Nothing, or close to nothing: use cases derive very well to whatever technical solution is given.
When you get to design, things get better still: your use case model has permitted you to identify reusable behavior that shortens the tons of administrative data entry interfaces to just a few use cases: you solve one, and you solve a whole family. You have a list of items you need to be able to display, update or delete? You do one use case called “Display list”, and either do a text description, a sequence diagram or even a GUI prototype, and re-use it every time you need it. It represents the same sequence of events, and you can parameterize your prototype until it solves a whole family of problems.
Sequence diagrams and sequence fragment reuse is solved at the use case level, through inheritance, use, extend, and so forth. Keep in mind also, that interaction diagrams work very well to model Services Oriented
Architectcure.
Of course: there will be situations where you need an algorithmic, step by step, modeling, and activity diagrams are the best solution for them. UML is a huge tool box now, so you have lots of choices.
BTW, Jim: I’m sure you did some fine structured modeling. The point I was trying to make was not against what worked well with structured SW engineering models, but with what failed and created paralysis (and the same, or worse, happened with many OO efforts).

Cheers!

jaimeglz