Hamlet III.iv.207 (on significant use cases)

[sargasso]

[glb]"For 'tis the sport to have the engineer'
Hoist with his own petard."                 *[/glb]

Greetings Urfbeings.

About a solar circumnavigation or so ago, I rant'd, rav'd and ratted on about "Log In" not being a significant use case.  The wonderful thing about history is how often the bugger sneaks up behind you [size=16]and bites you on the arse.[/size]

I, currently

"have this machine, a dream of a machine" (S. Lem "The Cyberiad")...

that contains a putative use case selectProject.  Now, according to my internal high-priestess, this use case  has no outcome of significance to the user.  It "merely" alters the scope of view that the system presents to the user for subsequent, more functionally significant, use cases.

Fine - OK - mea culpa - I have no problem with that.  

What I do have a problem with is that, like history, this damn thing keeps reappearing throughout the system with design implications.  In short, the "use case" is invocable at the user's whim, regardless of and with due or undue disrespect to, the current state of both the system itself and of it's data state.  The implementation answer is simple (or not, depending on the implementation) - be it event.throw, jRaise(_event) or even Win32.DisplayBSOD.exec  ...

What I want to know is how does one convey to a bunch of lazy, good for nothing, overpaid, careless, sub-moronic code-lathe using, apprentice cutters that they have to consider and possibly cope with this event throughout each and every one of their feeble attempts to turn my "Eroica" manuscipt into some VB/C++/.Net rap performance.

In other words, HTF do I model such a non-significant use case with such important design/develop implications?

Any thoughts

bruce

p.s.

p.p.s. I forgot what the p.s. i was going to add was  


* For those of you with interest in the origins and specificity of Angle-ish see
http://www.leoyan.com/global-language.com/enfolded/output4.php?file=HWORKS2500/HW-2577+6cn.xml

[mikewhit]

What are the use-cases of your "internal high priestess" - that's what I want to know ... is she trapped in a man's body ?

[jeshaw2]

Greetings thou heisted engineer  

Now, according to my internal high-priestess, this use case  has no outcome of significance to the user.  It "merely" alters the scope of view that the system presents to the user for subsequent, more functionally significant, use cases.

I'm not sure that I agree with your high priestess for this certainly represents a context shift in the users mental activities.  I should think that, in an automobile, shifting from forward to reverse gear enables certain useful behaviors of the vehicle and that would be a significant outcome to me as the driver of said vehicle (particularly in rush hour traffic).  But, I want to reflect on this a bit more....

Moving on to the the broader issue...  I think that a State machine would work here. I'm thinking of two or more project applications, each diagrammed as Harel orState machines nested in a containing state machine.  The containing state machine would exhibit project switching behavior in response to the selectProject event.  The project level orState machines would demonstrate persistence through the use of history pseudo-state elements.

[Paolo F Cantoni]

bruce,

isn't Log in an example of a cross-cutting concern from [size=13]Aspect-oriented programming[/size]?

For example, I go onto this (Sparx) web site, I come on as a Guest, I want to do something else - Sparx says "you got to log on now...".  If I was previously logged-in, it wouldn't ask...

Doesn't selectProject fall into the same boat?   For some things, you need to have a project selected - for others you don't if you need to check at teh right time.

If you agree, then we have the generic problem of how best to model cross-cutting concerns in a system?

Paolo

[sargasso]

[size=10]Mike, I dunno - she's an instance of class ethicsMonitor and therefore has no significant use cases to speak of.[/size]

Jim,
I'm getting to like this state machine idea, but it seems like a lot of work to have to state it for each and every activity that it applies to.

Paolo,
"we have the generic problem of how best to model cross-cutting concerns in a system" ... Yes!


By way of an example of what I am exactly trying to avoid:

#Setup
In EA create a package containing two classes, AA and BB.
In the same package create two class diagrams, d1 and d2.
Open both diagrams.
Drag-n-plonk both classes onto d1.
Drag-n-plonk class AA onto d2.

#Test
In d1, open the Operations editor for class AA.
Still in d1, click on class BB, then AA, then BB ...
Note how the Operations form follows the selected class!
Now ensure you have BB selected and ...

Click on d2 in the diagrams tab.
Select class AA in the diagram. (The Operations box correctly shows AA).

Finally, click on the diagram tab for d2.

#Expected
The Operations form will reflect the item selected in the diagram.

#Actual Result
The Operations form is still working on AA even though class BB is selected in the form.
#End

Before anyone starts, this is not about the UUI..

Its an example of exactly what I am trying to avoid!


bruce

[«Midnight»]

Bruce,

Coincidentally this old zombie has come back to life in my world over the last day. Very suspicious if you ask me...

I need to revisit my old position about this - it largely involved "think it through" and never got much traction. I'll get back to the thread on this if and as.

But... If you've truly brought this back from the dead to haunt us, we will have words.

David

[Paolo F Cantoni]

[size=10]Paolo,
"we have the generic problem of how best to model cross-cutting concerns in a system" ... Yes!

bruce,

Try:
Aspect-Oriented Software Development with Use Cases.
Some sample chapters are   [size=13]here[/size]

Without Jacobson's input, I'd stereotype the cross-cutting Use case as «aspect» and the dependency as «crossCuts».

HTH,
Paolo

[sargasso]

Now that I've got over the nausea from

"a revolutionary new way to think"

and

"this highly anticipated new book"

on the links, I've just got to duck out for a few minutes to the local bookshop.


At first glimpse this looks quite promising.

Thanks Paolo!!


bruce


p.s. SIDEBAR DISSPPEARING NOW!

[sargasso]

Without Jacobson's input, I'd stereotype the cross-cutting Use case as «aspect» and the dependency as «crossCuts».

I should think that, in an automobile, shifting from forward to reverse gear enables certain useful behaviors of the vehicle and that would be a significant outcome to me as the driver of said vehicle (particularly in rush hour traffic

[size=16]Update:

It's looking good and proper.  Looks like I might get Easter off after all!

1) Paolo, that was the clue.  I have read most of the book now and I reckon it may just be a fairly great step forward.  Qualification reserved until I try the same principals on a  different project.

2) Jim,  .....  this is kinda ... sorta ... hard to write .... Oh! OK.  ...  ...  aarrgh...[/size]
[size=10]The system does change in state when this behaviour is invoked and you're right this is an outcome of value to the user.    
_{;-) Looks like "Log In" may be a use case after all
Ow! Ouch! Ow, ow, ow!}
... " Mummmmmmmm!"[/size]


[Colour=seasick]OK, I've said it.  Don't publish it.[/Colour]


[size=16]bruce[/size]

[Paolo F Cantoni]

Glad to be of help...  I haven't actually read the book.  How about a review on the EA Wiki?

Paolo