Business processes modelling

[Kevin Brennan]

I'm using "complete" to mean that the use case does not necessarily have to be an executable sequence of events in its own right (although I agree with both of you, it does have to be executable in conjunction with the base use case).

That's not to say that it can't be, just that it doesn't have to be.

The main use of an <include> seems to be to place common behaviour somewhere where it can be called by a bunch of other use cases. For instance, a banking system might have a use case Calculate Account Balance which you'd want to call from a bunch of different transaction types. According to the OMG definition you can't put that in an <extend> because the base use case is not allowed to depend on something that happens in an extension for correct execution.

Oh well. I'll make a not of this conversation when I go back to edit that section, since it seems like there's some room to improve the clarity of the relevant discussion.  

[mikewhit]

The trick is to avoid decomposition of presumed functionality and design refactoring, at the requirements stage ...

[sargasso]

The trick is to avoid decomposition of presumed functionality and design refactoring, at the requirements stage ...

a quote which should be tatooed inside the eyelids of every UML modeller!



bruce