Include or extend?

[mikewhit]

My point was that with so many of these issues [in UML], there are as many opinions as modellers ...

[sshearer]

Since there seems to be a wide variety of, ah, interpretations (or implementations anyway), and since EA is a design tool which, with enough detail, can generate some level of source code ...

Would it be more helpful to ask:

What source code differences will we see between classes which are based on 'included' use-cases vs. those which are based on 'extended' use-cases ?

Or are we all (including me) still working at an altitude with insufficient oxygen ?  

thanks,
Steven.

[Bruno.Cossi]

Hi Steven,

likely none, as no code is generated based on Use Case and relationships between them.

Bruno

What source code differences will we see between classes which are based on 'included' use-cases vs. those which are based on 'extended' use-cases ?

[Bill Egge]

What do you think of this?

I followed the rule:  If the use case is a required step then its an "include" and if its an alternative then its an "extend".

What are your thoughts?
(Edit: There is a small mistake in the diagram, entering the wsdl is not required if choosing from the other ways.)

The below use case is for a new application I am creating which is used to call a web service for testing purposes.

[thomaskilian]

Hi Bill,
it looks like an analysis of your coding, not like a use case diagram.  What is explicitly missing: the Actors. Without Actors a Use Case diagram isn't one. Looking at "Call Method" I'd delete this Use Case (simply because I can't imagine that this is really a Use Case for there is no value it can deliver to an Actor) and replace it with the Actor (some machine or person) that acutally interacts with the four included Use Cases.

My suggestion: add the Actors an we'll have the next look

[Bill Egge]

I left the actors out as being implicit, by assuming that any "open" use case was used by an actor and also there is only one kind of actor in the system, the developer.

Here is the updated diagram, but you said I should remove the call method use case.  I don't understand why because calling a web service method is one of the things the developer uses the program for.  Isn't that what a use case means or "what is a use case"?

[thomaskilian]

I'd look at "Call Method" like on "Do It". It's too global in what it is telling. The actual Use Cases are the four included ones. Developer should be associated directly with these. Now to the rest of the included/extended Use Cases. None of them can stand alone and give any value to the Developer. They are just parts of scenarios/alternatives inside the 5 main Use Cases.  You should end up with only these 5 main Use Cases directly associated with Developer.  

Next you should do is a short narrative text that tells the use of the Use Case. Take a form like "Actor Developer starts UC <x> by  doing <event>" or "..by being triggered by <event>". Then all sunny day events simply separated by hyphens and where and why the use case ends.

In a later stage you would detail this text by explicitly writing down all alternatives/exceptions.

My best advice: do not make use of include/extend until you have successfully mastered some Use Case documentation scenarios.

BTW: my first Use Case diagrams looked pretty much like your example

[Bill Egge]

I am not grasping what you are trying to tell me.

Are you familiar with Web Services and how to use them?

Can you give your definition of a use case?

This is what I am reading you as saying:  If I were to create a use case for a system which involved someone having to create a document, I would not say "Create Document" because that would be too global.  Instead you should have "Reopen last document", or "Click File|New", etc.

That doesnt make sense because ultimatly all those things are reducable to very specific mouse movements and clicking.  But if you just wrote all that instead of the abstract meaning then it would not be understood.  It would be like giving driving directions to the store by giving you steps for turning the steering wheel and pressing down the accelarator 3 inches etc.

(In fact at my job we have a guy that explains things that way and its taxing to follow him)

[mikewhit]

As Thomas said in another thread, there is a danger of over-analysing (and straying into design) too early on in the process.

However, my understanding is that you may well have a sequence of high-level steps (perhaps with alternate paths of logic to cope with 'exceptions') required to accomplish one or more of the basic functionalities of your intended system.

Perhaps another approach is to record these steps for each of the functionalities, and then note if there are any subsets which are common between them.

You may then parcel up any self-contained subsets into use-case bubbles, give each bubble a 'goal-directed' name, and consider that you have performed a slightly 'bottom-up' use case analysis, by looking first at the steps in the scenarios.

Alternate/optional path subsets might then be 'extend's whereas common path subsets would be 'include's.

There is little point in subsetting into an include if that subset is not reused, or is not a 'component' in some other way.

Or perhaps other homines might have other opinions ...

[thomaskilian]

It would be like giving driving directions to the store by giving you steps for turning the steering wheel and pressing down the accelarator 3 inches etc.

This is the scenario. The Use Case would be called Drive or Fetch Item (depending on what your boundary is).

[Bill Egge]

Is this the final use case?

If it is, it omits an answer to the question "Why?" for the bottom 4 and does not show they are related to the same purpose.  It also omits a lot of ways a person will use the program.

But, is this the correct use case?

[thomaskilian]

From my point of view this looks okay. You should ask yourself: what is the value the system returns to the user. Doing it this and that way does not change the value, it only tells you that there are different paths to reach it. I have to confess that you have to get used to that. Especially when you are an analyst. Then you tend to break down each and everything in bits and pieces. But these won't give you additional information regarding the VALUE.

Just believe me and give it a try with being thrifty when using Use Cases.

[Bruno.Cossi]

Hi Bill,

my prospective is a bit different. When I look at your Use Case diagram, I see that your system uses web services, I see that the developer can fill in parameters, submit calls etc. I do not see why would rthe developer do that. Would the user ever say "I am going to login to the system so I can choose a method, fill in parameters, submit a call and view call results? Probably not.
Let's say that your system, for example's sake, provides access to online bank statements. Sure, you use web service, you have a method that pulls up the statement information based on the parameters you fill in etc. But the ultimate purpose of this is to display the statement. I would see here one Use Case, Display Statement.
Let's say that your system also  allows the user to electronically apply for a loan. Technically, you would still use web services, methods, what have you. But from the users' prospective, it is a different process, a different thing. I would see another Use Case, "Apply for a loan".
To a person with a technical background (as is probably most of us in this forum), this seems like an overlap, a duplication. What we have to realize that the typical audience for the Use Case diagrams is non-technical. And typically, people that give you the information you use in building your use case diagrams are non-technical as well.
In fact, at the stage when you are building use case diagrams, you typically do not even know HOW are you going to develop the system.

A little trip to history - the use cases have developed from something called "user stories". A modeller would spend time with the users/future users of the system and they would describe to him what the system does/should do. The users are certainly not developers, the system to them is pretty much a black box. They would describe the way they use the system, what goes in and what comes out. Whether there are web services, steam engine or gnomes with calculators, makes no difference to the users.

My first impression is that at least some of your use cases are really operations on classes - classes that you will define only after you have finished your use case diagram.

The beauty of this is that you will have a simple, easily understandable Use Case model that you can present to the non-technical personnel, and a detailed diagrams great for the developers.

Perhaps if you told us more about the system you are trying to model (WHAT it does, as opposed ti HOW is it implemented), we could try to come up with a Use Case diagram together.

Hope this helps!
Bruno

Is this the final use case?

If it is, it omits an answer to the question "Why?" for the bottom 4 and does not show they are related to the same purpose.  It also omits a lot of ways a person will use the program.

But, is this the correct use case?

[Bill Egge]

You should ask yourself: what is the value the system returns to the user. Doing it this and that way does not change the value, it only tells you that there are different paths to reach it.

I see!  , I think  .  The value stays the same but the method is not written in stone.  The use cases specify the value while the application specifies the method.  Thus the use case is void of method and thus references to the "how" i.e. the application design.

Is that correct?

So then my use case for testing web services would look like this:

[Bill Egge]

I do not see why would the developer do that.

Perhaps if you told us more about the system you are trying to model (WHAT it does, as opposed ti HOW is it implemented), we could try to come up with a Use Case diagram together.

Here are 2 angles.  The first on WHAT, the second on VALUE.

What:

• The program will return results from a method call and optionally format them so they can be read easier. (Its not always desirable to format the results)
  
• It will provide a way for you to call those methods rather than you having to build a client.
  
• It will host a web service DLL so you can run it under your debugger.
  

Value
From a value perspective, these are reasons for the last use case I posted.  (The one with only 3 use cases)

1.  View web service call results.  This is used to verify that the web service is working correctly.  Another reason is to see the actual xml of the return so you can create xsl sheets for the results.  The value in seeing that the web service is working correctly should be an obvious value.  The value in creating xsl style sheets is for converting a web service result into a web page using xsl.  But that is outside the scope of this application.

2. Invoke web service calls.  This is for 3 reasons.  

• so you can get to use case #1.  
  
• The other reason is so you can get to use case #3.  
  
• The last reason is so you do not have to build your own web service client to invoke a web service - Basically the value is saving time.
  

3. Setting breakpoints in the web service DLL.  If you are a software developer, the value in this should be obvious.