These stereotypes denote the structure of a text document, not the structure of an application system.
Well I can't really agree with you. Why can't those stereotypes be used while modelling an application system? The system use-cases idea states that the use cases document the iteractions between the actors and the system. And, therefore, one can use the 'extend' relationship when from a level of one interaction with the system (e.g. use case "browse invoices") he/she may invoke another iteraction (e.g. use case "download invoice documents")
Also note that you don't 'call' a use case in the same sense as you do a subroutine. Nor does the use case take parameters or return a result, at least not in the sense of a subroutine hierarchy.
You mean the function decomposition? Because, AFAIK, the use cases DO act "similar to calling a function or invoking an operation within source code" (Scott W. Ambler's article on reuse in use case model:
http://www.agilemodeling.com/essays/useCaseReuse.htm).
As far as the preconditions are concerned, I agree it is a brilliant solution to most of the authorisation/login problems. Though, in my application there will be various authorisation levels and the application will have to check user's authorisation level every time a "protected" operation would be accessed by him. Unluckily, this check often takes place in the middle of a use-case logic and according to our project methodology (maybe not the best one) we want to describe the use cases at such a detail level that we want to know when the authorisation level checking takes place (e.g. because very often we display a higher-level-authorisation-form then).
And thanks for your replies

.