Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Paul D

Pages: [1]
General Board / Re: Problems with latest version under XP
« on: March 14, 2003, 03:28:25 am »
Hi Tim

I'm using XP Pro (no service pack) with 605, desktop edition, but haven't come across any problems. If you give me a specific for instance, (does it happen every time or only on certain menus) I'll compare with my setup...

Uml Process / Re: Hierarchical Decomposition of Use Cases
« on: March 26, 2003, 06:16:13 am »
Just a quick addendum to what I wrote there....

The main attraction for me (and I think this is what Tjerk was getting accross) of having use cases organised in a proper hierarchy, is that the broad view of actors (as human users) roles' that it communicates.

For example, suppose I have an actor 'Site Administrator' and another 'Content Manager'. There might be a top level use case called 'Administer Site' which the site administrator uses, and another called 'Manage Content' which the content manager uses. At this level, these actors are not associated with any other use cases.

Then the 'Administer Site' use case may be decomposed into 'Manage Users', 'Manage Workflow Settings' etc.. etc.., and there may be various  uses, includes, and extends relations between them as appropriate. These may be further decomposed in to subusecases until the appropriate level is reached. A similar tree would be developed for the 'Content Manager'.

Okay, this might sound like overkill. But the advantage that I can perceive is that the top level use case, along with its notes, requirements etc., immediately communicates to anyone looking at the model for the first time (client, developer etc.) exactly what the actor's role is "in general". This is especially useful for clients who are not UML/technically literate.

The example I gave is not the best -- it is fairly obvious that a Content Manager's role is to manage content!! .. but it isn't difficult to imagine problem domains where the actors names don't convey this information. Without having a hierarchy (however shallow) of use cases, the only real way to glean the sum total of an actors role is to survey all the use cases it iteracts with, and for systems with a large number of use cases this can be time consuming..


Uml Process / Re: Hierarchical Decomposition of Use Cases
« on: March 26, 2003, 01:53:37 am »
Phil, Tjerk, Thanks for the responses.

However, Phil, though I do realise that use case are semantically quite different from functions, I'm pretty sure that there is a UML compliant way of arranging them hierarchically. Looking at the UML in a Nutshell book, the terms 'superordinate use case' and 'subordinate use case' are used repeatedly, and there is even a diagram showing a tree of use cases, but the associations are not described....

... anyways. I may go straight to the horses mouth and scour the UML specification (I'm just like that!). Cheers for the feedback.

Uml Process / Hierarchical Decomposition of Use Cases
« on: March 25, 2003, 02:43:55 pm »
Hi All,

I've scoured all postings regarding use cases but can't find any explicit discussion of this...

Basically, I'm at the stage of use case modelling for a reasonably large website, and I'm trying to come up with the "best" / "correct" way to hierarchically decompose high level use cases in to sub-use cases. My only reference unfortunately is the excellent, though sometimes cryptic 'UML in a Nutshell' by O'Reilly [...looking at chapter 8 here].

I'm trying to find the right association/stereotype to define the relation between a superordinate use case and its immediate subordinate use cases. Working from the above text, my best guesses so far are: [Assuming that a use case 'X' is superordinate to use cases 'a', 'b', and 'c'...]

(a) There exist generalisation associations from a,b,c to x with the <<realise>> stereotype

(b) There exist dependency associations from a,b,c to x with the <<refine>> stereotype

(c) a,b,c are contained (directly) in a package, p, and there exists a dependency from p to x with a <<refine>> stereotype

(d) avoid using any form of superordinate use cases at all. All use cases are 'bottom level', and the hierarchy is imposed by using packages nested appropriately.

I don't like (d) for the simple reason that I would like to be able to describe 'general' high level tasks in use case form so that the client (and I!) can see the wood for the trees. Plus the O'Reilly text does suggest that there is a proper, UML compliant, way to do this.

I *know* I should buy a more prosaic text (and I will), but I'm in a bind at the moment, so if anyone has thoughts or ideas, I'd greatly appreciate them...


Pages: [1]