Help with my first Use Case Diagram

[derek73]

Howdy folks!  I need a little help with my first use-case diagram. I've done considerable reading on the web, but I'm still trying to figure out if I'm going in the right direction.  First of all, here is my diagram:



When a "QA Engineer" launches a Test, that puts the actor called "Launcher" at work.  When the "Launcher" initializes the driver, that puts the "Driver" actor to work, and when the use-case "Execute Test Suite" is called, that runs the program created by the actor called "program compiler.

When the "Launcher" executes the Test Suite, that really runs the program  (The "Program" actor) via the Driver, which actually in the class model contains a program object.

So my question is, how do I associate all these use cases and actors, and show the proper relationships between these use cases?  This is where I'm confused.  I know what the different pieces do under different circumstances (or think I do), but there is a flow from top-left to bottom-right.  I know a sequence diagram really conveys the sequence, so obviously what I really want to do is effectively show the relationships between these use cases in this diagram.  

Any help is much appreciated!  Thanks in advance for your time.

[derek73]

I drew some more association lines in this diagram.  Maybe this makes more sense (although the positioning is ugly   )


Is that a work of art, or should I be shot?

[thomaskilian]

Derek,
your UC diagrams should not focus on the HOW but on the WHAT. That means your <<invoke>> are superfluos (/wrong). Just leave it with simple associations. That should be perfect.

Also keep in mind: if your UC diagram looks like a spider web, something is wrong. In that respect you first shot looks better. In the second you have connected two UC's: that's not okay. Either you have an Actor between both or they are related via <<include>>/<<extend>> (search this forum for these keywords).

[Eve]

It looks as if you've drawn actors for parts of your system.  This isn't right either.  You could probably remove all of these actors and all use cases that aren't associated with an actor or <<include>>/<<extend>> another use case.

We'll hold off on the firing squad though.  

[derek73]

Firing squad is okay, as long as you use flamethrowers - trial by fire is how "short" projects get done.  As far as the actors go, I thought an actor could represent a part of the system, but after searching for <<includes>> I might be able to re-organize the use cases.

I started a sequence diagram to lay out my class objects, and found instead that I was diagraming sequences with my use-case objects.  That probably indicates a problem right there, in that if the use cases are tightly ordered but hidden from the "QA Engineer" actor, it should be in some other type of diagram which uses class objects instead.

This is way more difficult (and interesting) than I initially imagined.

Here is my latest changes:

[sargasso]

Still a bit process'y.

For each use case ask yourself - would the boss pay for someone to do perform this use case n times a day?  In the case of "Specify...parameters", would he/she pay for someone to do this and just this all day?  IOW at the end of the day Mr QA Engineer puts in his timesheet with "# Test Suite RunTime Parameters Specified = 2143" and "# Tests Lauched = 1".  According to your diagram he should be applauded.

<<Include>> is a mandatory execution "context provider" - it is used to factor out common behaviour amongst a group of use cases.  IOW <<Include>> should only appear if the included case is used by other use cases in the system.  I dont see any evidence of that inthe diagram.

Use cases say nothing about how a system ("actors + machines") works at all.  Their only concern is what a system does.

I would say your system has one use case "Run Test Suite".  All other things belong in activity and collaboration diagrams.

hth
bruce

[derek73]

Still a bit process'y.

For each use case ask yourself - would the boss pay for someone to do perform this use case n times a day?  In the case of "Specify...parameters", would he/she pay for someone to do this and just this all day?  IOW at the end of the day Mr QA Engineer puts in his timesheet with "# Test Suite RunTime Parameters Specified = 2143" and "# Tests Lauched = 1".  According to your diagram he should be applauded.

Damn, I've been starting to lean in that direction the more I've changed it -- I started thinking, "all this stuff is the underlying implementation and things that happen regardless of what kind of test case or conditions within the Test Program exist".  No matter what, it always gets parsed, compiled, and generated if a test suite is launched.

There are the following use cases within a phase called "write a test suite":  (a) one test case record yields one result, (b) one test case record yields multiple results (we call this a hybrid test).  Even under this circumstance, initiation and end result is the same.  The QA Engineer launches a test, and collects results.

I would say your system has one use case "Run Test Suite".  All other things belong in activity and collaboration diagrams.

hth
bruce

Thanks much Bruce!  I'll try and put the process into an activity or collaboration diagram, and post that for critique.

[derek73]

Alright, here's another attempt at a Use Case diagram:

[derek73]

Uh oh...



Now look what you people made me do!  I hope you can live with yourselves!

[sargasso]

Yes, but at least you can model it correctly now  

(you shouldn't have specified all those test suite parameters.)

bruce

[«Midnight»]

Derek,

Much of the original content of your use case model will still exist in the overall UML Model (that is, the entire suite of Views, Packages, etc. that describe your system).

Things like specification of parameters will be introduced and elaborated as you write scenarios and drill down into the use cases. Much of this will be textual, but some will still be captured in the use case descriptions. You will see certain patterns emerge, which will be modelled via the other UML model types. These patterns may also allow you to see common portions for <<include>> and <<extend>> situations.

As you describe the use cases you will also introduce the Launcher and its various brethren (or other relatives, however distant). This will lead you into elaborating the use case via sequence and class diagrams, and perhaps collaboration diagrams. [I'll duck the discussions of which come first, as it can get pretty evangelistic,  and you have a more basic concern.] More modelling along these lines will quickly follow.

Personally, I've always been a bit concerned that the use case is only weakly linked to the rest of the model - at least compared to the semantic cohesiveness elsewhere in UML. Version 2.0 improves this a lot, but I still find myself a bit queasy. There's a very wide variation in use case modelling skills and styles (not to say this isn't true elsewhere in UML). Some people - including some posters in this forum are wizards; heed what they say. Others, poor sad mortals like myself, have to work at it.

I comfort myself by repeating (endlessly) that as one work through the use cases, the amount of work involved acts as a powerful incentive to identify opportunities for simplification, clarification and consolidation of the resulting models. I even speculate that this could lead to a better system down the road, but perhaps that's just the wine talking...

David

[derek73]

In between searching/browsing this forum and posting to this thread today, I have been attempting to work on my model along with reading the EA help and googling for clues.  I find it easy to get lost in all the tools, connectors, organization and pieces and it can be overwhelming.  I'm sure everyone has been there - it's like trying to understand pointers in C without understanding the relationship between variables and memory.  (I have also been buying new music on iTunes all day because it's a holiday and I'm at home learning UML... /cranks up Oasis's Wonderwall/)

I want to follow through with an activity diagram to flush out the following concepts:

 - The logical flow of what a driver does when it gets initialized
 - how data is parsed and compiled, and how each instruction is associated with a container that holds the results
 - what happens when each test is executed and the flow that puts the result in the container

I have a high-level class diagram that maps the basic relationships between classes.  I didn't even define behaviors (although I have an old Dia diagram that has a lot of that already - don't ask me how many UML tools I played with before landing on EA).  

Do I take the USE CASE objects and paste them into an Activity Diagram as my starting point, and draw the flow from there?  How do I represent what I was basically describing in my second or third examples?

Do I proceed with a State diagram to show basic flow in time?  I've done one of these when playing with Umbrello, and it's a concept I found easy to grasp from an object interaction point of view.

Thanks for all the help and time you guys have provided today.

[thomaskilian]

Derek,
what I do is the following: from the UC I create a new package UC Realizations which holds (normally) a 1:1 copy of the UC as Collaborations with a Realize relationship between (Collab--<<realize>>-->UC). I have a Transformation template to create this automatically. Each Collaboration I set as composite. This creates a diagram inside which opens when the Collab is dbl-clicked. Also I put new diagrams (Sequence, Collab, State, etc.) as sub-diagrams inside. The most important of which is a Robustness diagram (see Google; use a Class Diagram for that). It gives an MVC overview over the realization of the corresponding UC. Try understanding this concept first before going into class/domain modeling in depth.

[GTM]

Derek,
thomaskilian is right (well he is a Guru..).
Anyway, here are just my 2 cents worth to throw in:
The attempts you made in UC Modeling are the usual mistakes developers make when stepping up the HOW to the WHAT. As others said before, you merely have created a functional decomposition rather than the Cockburn-Goal things (or as he said: under-water).
I suggest to read his book, and there are dozens of other good articles on the need to lift the fog.
Search for "Ask Dr. Use Case" , as a starting point.
HTH  

[GTM]

Sorry - the right term to search for is "Dear Dr. Use Case"