Activity Diagrams kill Use Case Diagram

[sargasso]

[size=10]OK I've been good. I've been quiet.[/size]

Let's say I want to build the average 3BR house in Upper Kumbuckta West.  So I go the an architect and say, "I want you  to design and construct me a 3BR house."

Now if he says, "Well, this is how we lay the bricks and this how we install the wiring and this how we connect the plumbing... " before he asks, "Well, certainly Mr Smith, what type of house are you looking for and what sort of usage do you want out of it?",  I'd be a bit suspicious.

But if he did and then after I said "It's a weekender for me, her good self, the kids and their friends.", went on to  continue with "Well, this is how you'll park the car and this how the kids will connect their Xboxes ... ", I'd still be a tad miffed (if not quite confused.

Am I making sense here?  I can shout if necessary*.


bruce

* It's about [size=18]communication[/size] UTSL

[fperedo]

Hi! (this gets even more interesting)
1) jaimeglz, I somehow fail to see why it is worse to come after a month or so with activity diagrams... than coming with use case diagrams... (I think here the problem is that you took a lot of time to model, and didn't worry a lot about feedback). Of course you can describe a big system with a few simple high level use cases..., but... why an activity digram can't be high level too? After all, this diagrams http://www.sparxsystems.com.au/EAUserGuide/index.html?businessmodelling.htm are some kind of activity diagrams.. aren't they? and IMHO they are high level, flow diagrams, and more expressive than Use Cases.. or not?

2) sargasso... sorry... I am not sure if I understood your example... but I am guessing is about high level (kind of house), and low level (wiring, plumbing) description of the solution... two questions... why an activity diagram cant be high level (as in http://www.sparxsystems.com.au/EAUserGuide/index.html?businessmodelling.htm )and... two, after you put lots of bricks together, it will start looking (or not) like a house, and AFAIK there are specific rules in architecture on how to put every piece so that the end result is an structure with a good foundation... ¿where are the rules to build the foundation for my use case diagrams? (the sequence diagrams that describes a use case doesn't have a way to represent the "extends" or "inherits" relationship of that use cases with another use case... or does it?

I agree use case diagrams are nice for communication, to give an overview about how the system is going to be built.. but, as you start filling the gaps, you realize that there a just no rules to link you bricks with your blueprint... I mean, you activity/sequence/communication diagrams with your use case diagrams...  and they seem to be written in 2 completely different and unconnected languages...

A little off topic note: some days I really miss yourdon data flow diagrams... .. they somewhat remind me of iconix robustness diagrams...  

[thomaskilian]

Hi! (this gets even more interesting)
1) jaimeglz, I somehow fail to see why it is worse to come after a month or so with activity diagrams... than coming with use case diagrams... (I think here the problem is that you took a lot of time to model, and didn't worry a lot about feedback). Of course you can describe a big system with a few simple high level use cases..., but... why an activity digram can't be high level too? After all, this diagrams http://www.sparxsystems.com.au/EAUserGuide/index.html?businessmodelling.htm are some kind of activity diagrams.. aren't they? and IMHO they are high level, flow diagrams, and more expressive than Use Cases.. or not?
  

Well, these don't fit in anywhere. They are a kind of mock-up. IMO UML is not worth while talking about business modelling (yet). I'd anyway prefer ARIS over UML.

You can of course mount a tow coupling on your 911...

[jaimeglz]

fperedo: Now it turns out that you were talking about business process modeling! So I have no further comments.  

Anyway, I hope everyone enjoyed the discussion.

Cheers!

jaimeglz

[Chris Kriel]

I share the originator's concern about the validity of using "what" and "how" to clearly differentiate between levels of abstraction. There is mostly gray and very little black and white in this business. For example, I find it fascinating that people can confidently see a clear demarcation between "requirements" and "design". If you say "the system shall.." are you not designing it at a high-level? When we do have something that provides a reliable level of abstraction, we should cherish it.

To me the value of use cases should be more that it defines a definite level of abstraction rather than as a general technique and notation to specify functionality. It is no accident that we draw a little man as the actor. Mostly the level of abstraction is the human perceivable functionality of the system under discussion. As  a good idea it got overused and lost its focus as a definite level of abstraction.

There is great value in documenting the externally perceivable functionality of the "system under discussion" in a technology neutral way. Having a specific notation dedicated to this specification is justified and should guide you to stick to that level of abstraction.

I believe that you should move away from use cases as soon as you leave this "actor" level of abstraction. Currently, in practice, when you look at a use case, it is dangerous to assume a level of abstraction. Another technique down the drain!

[Chris Kriel]

I share the originator's concern about the validity of using "what" and "how" to clearly differentiate between levels of abstraction. There is mostly gray and very little black and white in this business. For example, I find it fascinating that people can confidently see a clear demarcation between "requirements" and "design". If you say "the system shall.." are you not designing it at a high-level? When we do have something that provides a reliable level of abstraction, we should cherish it.

To me the value of use cases should be more that it defines a definite level of abstraction rather than as a general technique and notation to specify functionality. It is no accident that we draw a little man as the actor. Mostly the level of abstraction is the human perceivable functionality of the system under discussion. As  a good idea it got overused and lost its focus as a definite level of abstraction.

There is great value in documenting the externally perceivable functionality of the "system under discussion" in a technology neutral way. Having a specific notation dedicated to this specification is justified and should guide you to stick to that level of abstraction.

I believe that you should move away from use cases as soon as you leave this "actor" level of abstraction. Currently, in practice, when you look at a use case, it is dangerous to assume a level of abstraction. Another technique down the drain!

[Chris Kriel]

I share the originator's concern about the validity of using "what" and "how" to clearly differentiate between levels of abstraction. There is mostly gray and very little black and white in this business. For example, I find it fascinating that people can confidently see a clear demarcation between "requirements" and "design". If you say "the system shall.." are you not designing it at a high-level? When we do have something that provides a reliable level of abstraction, we should cherish it.

To me the value of use cases should be more that it defines a definite level of abstraction rather than as a general technique and notation to specify functionality. It is no accident that we draw a little man as the actor. Mostly the level of abstraction is the human perceivable functionality of the system under discussion. As  a good idea it got overused and lost its focus as a definite level of abstraction.

There is great value in documenting the externally perceivable functionality of the "system under discussion" in a technology neutral way. Having a specific notation dedicated to this specification is justified and should guide you to stick to that level of abstraction.

I believe that you should move away from use cases as soon as you leave this "actor" level of abstraction. Currently, in practice, when you look at a use case, it is dangerous to assume a level of abstraction. Another technique down the drain!