Use Case - regarding the systems memory...

[fluxtah]

Hi,

I am having this problem with use cases where I dont feel everything is entirely described.

The question I have is, is the system 'remembering' some value or number or something the actor gives to the system, part of the UC description? I am begining to think it is... when I perform robustness analysis on suspected ambigous UC, I see a lot of areas missing from 'what' the system does in response to 'what' the actor does. It seems that me and the other UC writers are assuming the system is going to do things automatically, completely avoiding what the system actually does.... IMO if the system is to remember a list of 'things' that have been defined or set by the actor, then it should be in the UC description

For example:

'The system remembers what option the user selected, and adds this to a list of previously selected options'

The reason I put this in the UC description is because further on in the UC this list of remembered things is needed to see the UC through to the end.

The 'list of remembered things' or better put it 'Selected Option List' would be a transient object that is not an object of the problem domain, but one discovered writing UC descriptions.

any thoughts on this is greatly appreciated!

regards

Fluxtah

[thomaskilian]

Hi fluxtah,
I guess it depends - again - on the boundaries. When talking in business terms, there is not really a distinction between transient and persistent objects (you can refer to the well known student/teacher example). As this is my main environment modelling of technical systems as you do is not quite familiar to me. But I guess that technical terms like "remember selected options" can be modelled as such. Some time ago I started a topic about use case and activities. I was not quite shure which quality made up an activity and which a use case. The boundary should tell you where the UC is located and where the activity. However, this boundary is NOT a thin line but more a rather broad band. In that respect you are probaly free in defining Use Cases that other people would look at as Activities (in your example "remeber option").

Honestly speaking, I'm not quite happy with use cases. They are meant to model business, but I always fall in the same pits (overloading use cases). Actually I try to minimize my use case model as far as possible. I've read about the ICONIX process and will try that in comparison - I'm curious whether this will bring me further.

Cheers,

Thomas

[fluxtah]

Cheers Thomas, mainly I am modelling web-sites, this particular problem I have the system displays information with less or more options depending on what the actor chooses in the system.

So if the actor chooses a particular option, the system will generate a suitable response for the actor based on that option, further on in the use case, the system will use the options that the actor selects to determine other reactions of the system.

Generally, from a business point of view, if we where to completely disregard what the system is doing with the information presented to it, and to understand why it responds in a certain way to what we give it, we need to know what the system knows at a particular time, in order for the system to respond in a correct manner, to meet the business needs...

I still am unsure to wether I am going the correct way, though a technique that can be used, in order to minimise any misunderstanding to what the UC is to achieve is to use Sub Flows, to describe stuff that would possibly throw the UC reader off.

regards

ian

[sargasso]

Woah there guys!

There is no law against talking abut the system in a use case.  The only "law" is to talk about the use case from the user's perspective - not the systems perspective.

The intent is to describe what the user is trying to achieve through the system in a manner that
1) is comprehensible to non-technical readers
2) does not constrain design of the system by prescribing technical details (unless they are real requirements)
3) relates a single use of the system by (a single or set of) users that achieves an outcome of value to the user.

Consider the use case "Cook Dinner" which uses the system "Automatic Oven".

Notes:  
Bad form - The Cook Dinner use case begins when the user invokes the Set Parameters extension use case and ends at the completion of the include use case Heat Cavity.

Good form - The Cook Dinner use case begins when the cook has prepared the ingredients and placed them in the oven cavity and ends when the cooked meal is removed from the oven for serving.

In the good form we have set the scope of the use case in a manner that is clearly understandable by the user - all actions and reactions by the system between these two points are what is covered in the use case

Scenario (Basic):  
Bad form - 1. The chef sets the parameters of the system relating to the proposed cooking session through the user interface elements. The parameters accessible are limited to Session Start Time, Session End Time and Target Cavity Temperature.
2. At the trigger event fired when the Session Start Time is reached, the system initiates the Regulate Cavity Temperature(Target Cavity Temperature) system include use case.
3. The Regulate Cavity Temperature use case executes in a synchronous manner until the trigger event fired when the Session End TIme is reached, when control is returned to this use case.
4. System invokes the Ring Bell extesion use case.

Good form - 1. The chef selects the Set Program action on the control panel.
2. The system prompts the user for the desired cooking temperature on the control panel display.
3. The chef sets the temperature using the digital input panel.
... the other parameters ...
6. When the Session Start Time is reached the system begins heating the oven and controls the cavity temperature close to the desired temperature until the Session End Time is reached.  (Further detail is explained in the included use case - "Regulate Cavity Temperature"
7. The system alerts the chef that the session is complete by ringing a bell.

(I believe the good form adequately describes the fact that the system has remembered certain parameters of the operation without having to resort to technical language)

I believe that Intent 1 is met.
I believe that the technical constraints that the specifier wanted (digital control panel) are adequately expressed
without limiting design freedom.  Even though I did mention a functional decomposition of the control panel into the display and input sub-components.
I believe that the use case description and scenario presents a complete case of value to the user.

I also reckon that the use case is fairly well expressed to provide a framework for technical analysis and design work to follow - and thats where we will start discussing the things in the "bad" forms above.

hth
Bruce

[thomaskilian]

Hi Bruce,
thanks for this detailed explanation. As you state that Use Cases shall be written from the Actors point of view, this does not seem to true for the Activities in your scenario above. Some are describing the system, not what the Actor is seeing from outside. So here's probably the place where to place the state/persistence and what else Ian was needing. Right?

Cheers,

Thomas

[Stephen]

Campaign for Simple Use Cases

Who reads your use cases? If you try to capture everything in (essentially) as textual format, are your clients sufficiently technically savvy to understand all the nuances? If your use-cases become too detailed they may not work for your Clients anymore, just help to steer your developers. Then you need to manage some other document to capture client requirements (CRC's?), which you then have to trace into your UC's.
Keep the UC's simple, stash away a couple of activity diagrams or communication diagrams (state machine diagrams if in a very decomposed OO environment) for the developers to get there extra detail. Building these models may also help ensure the robustness step gets done.

I no fan of useless documentation, but I keep reading comments on this site and others, that use-cases are developed in detail and other diagrams are perhaps sketched out and discarded on an ad-hoc basis.

Assuming the essential systems architecture is reasonably fixed (and understood), what is needed is a documentation standard for non-technical readers (Clients); something to get the development team started (which will be a living model/repository including all the little alterations); some method to automatically analyse what the developers have produced - probably back to a series of UML docs (easy to do structural diagrams, behaviour is a bit more tricky!); which can then be annotated by developers explaining how and why the system looks the way it does. (won't ask them for too much or we won't get it, but make sure they cover the behaviour.)

The real problems are with change and configuration management and apply just as much to the model as to the system....

[fluxtah]

Cool! Thanks Sargasso, very useful, specially this:

2. The system prompts the user for the desired cooking temperature on the control panel display.
3. The chef sets the temperature using the digital input panel.
... the other parameters ...

One thing I was failing to do in my use case was specify 'every named parameter' that the user is required to give to the system in sequence, i was trying to be generic and almost generalise the parameters into one 'some' parameter, oops :/

Also I learned here.. I could use subflows for all the ... the other parameters ... which will essentially allow the parameter inputing have no particular order?

could I also say for instance:

1. The chef selects the Set Program action on the control panel.
2. The System hides the Set Program action ?mechanism? ?option? from the actors view.
3. The system prompts the user for the desired cooking temperature on the control panel display.

Stephen, thanks for that info, really useful! my use cases do need watering down after reading that but then at the moment only I read my use cases.

I work in the web industry as a programmer , the only requirements I get from my superiors is a functional specification doc, it basically just show's all the screens they want, mainly forms to input/output data on a web site, and a site map of the pages, with yellow notes on what each drop down list or other UI element should be populated with, however you can get a lot from it and is good enough for me to UC with enough questioning and tweaking, though would be dangerous to code straight from

regards

Ian

[sargasso]

Thomas,

Yes and no.  My point is, and has been through previous threads on use case textual content, that at the end of the day you cannot completely ignore the systems exisitence in describing use cases and use case scenarios.  After all the desired behaviour of the system is what we are trying to explore here.  To be even more specific, it is the behaviour of the system as perceived by the involved actors (both initators and subscribers).

Continuing the oven metaphor, review the "good form" scenario.  Lets say that the initiator, the chef, is reasonably concerned about certain facets of his new oven and is diligent in the review of the scenario.  At first review, yes it looks like what he has specified and perhaps raised his curiosity as to what the control panel interface will look like.  That is, I have written the scenario in a manner that raises interest (queries, concerns, panic?) in exactly where I want him to go next in our requirements gathering sessions.  He is focussed on the interface not on the internal design and operation of the software that will control the oven.  I strongly believe in getting their attention away from the internals and back to the interface as early as possible.  Otherwise, we end up with user requirements that constrain the internal design of the system.  An example of what I mean:

The oven shall implement all prompts and other textual displays using an external resouce file that can be loaded at the point of manufacture so that the oven can be built and sold in more than one country

"Aargh!" He's not only constraining architecture and design but also the implementation process, regardless of whether we could build the damn thing anywhere using a global resource file and -perhaps- make the language end-user selectable.

But, back to the interface...
Where I want the specifier to go is into further detail about the requirements.  By getting into the interface we can focus him/her yet again on what they percieve and not on "how" the system does it.  For example, I have the following questions I want answered in this session:
1) 12hr/24hr clock display? Requirement or doesn't matter?  
2) Date rollover?  Do you want to start the oven at 23:45 and end at 01:15 for example?
3) Degree of accuracy of the temperature setting display? 1^o, 5^o, etc?
etc etc
Oh, and I have one last issue to raise with him.
While the oven is actually cooking, do you want some indication that it is "Regulating the Cavity Temperature"?

Bruce

[sargasso]

Stephen,

C-SUC! Where do I join?

Ian and Thomas' original thread (and others that I have joinned into) are very much associated with that wonderfully grey area - moving from requirements gathering into analysis.

One thing we have talked about/around is how use cases are used to explore what the Analyst doesn't know about the system (or the requirements) and how the textual content can be used to bring these things to the Anlysts attention.

By writing down - as detailed as necessary at the time - the inner workings of the use case I am very frequently surprised at how many assumptions I make as to how it will work.  My typing (and retyping) speed probably helps here as I have time to think through each step of the use case and what it means.

However, it is certainly true that this can often be taken too far - and we (all) start designing the system inside the use case!

I wish I knew a way to "ring the oven bell"  when the use case is sufficiently cooked.  The only guideline I have is to go back to the specifier when I have 3 to 5 questions at the scenario level and certainly before I have more than 7.

As you say, many times the answers to the questions are material to the UML design artifacts, not the use case models.

One of the things that I think is great about EA is the Maintenance Items. It is where I record these questions and their answers - and manage the changes to the other models.  Our standard doco's are set up as virtual documents and all include element defects, issues etc so these things dont ever go away until they are fully resolved.

B

[sargasso]

Ian,

Why is it important to state that the system hides the "Set Program" thingy?  Do you have some issue with that step you want to explore further?  Does it add value to the process? OTOH Does it detract value from what you are trying to describe?

.... or are you just trying to remember that the design models have to include that step?  

Bruce

[fluxtah]

Hi Sargasso,

the important thing is.. I guess so the chef can not choose that option again  

I am trying to relate it to the wine bottle thingy :]

[thomaskilian]

Hi Bruce,
I think I got the point (another one of these zillion points  ) - so thanks again. Really kind of funny that there is no mainstream methodology on top of UML  :-/. I suggest you to gather your comments and place it in a book. Probably there's a big market outside  

Cheers, Thomas

[fluxtah]

Thomas, I highly recommend http://www.usecasemodeling.com

Forward by Ivar Jacobson and book written by 2 rational dudes :]

regards

Ian

[sargasso]

so the chef can not choose that option again  

Then it sounds like an expressed requirement and therefore the inclusion represents the proposed solution to the requirement. Therefore it is a design level aspect. Therefore:
if you are using the use cases to reiterate the design aspects back to the stakeholder put it in the use case,
otherwise (if you are trying to be pure) I would tend to put in an action diagram associated with the use case.

In our courses, we talk about an iceberg "view" of our standard inhouse UML models.  Only 20% of the iceberg is above the "waterline" and that is the material we make sure that the non-technical reader can understand.  In that  20% we focus on the business issues and (try to) keep any technical jargon or technical issues out.  We also try to be "pure" in this area so that business level models across teams have a similar flavour - thus lessening the confusion amongst the natives that could occur when two different IT teams present business level models in different UML "dialects".

"Below the waterline" is a different matter.  We use UML as a tool to solve design problems.  Flexibility in usage, adequately explained, gets us to the desired result - an unambiguous expression of the system design.  

Now, before you start on "to a man with a new hammer - everything is a nail" let me explain.  You (Ian) seem to be working very much below the waterline with your use cases.  The points you raise are relevant both in terms of usage and  content.  In your environment I see no reason to constrain yourself to "pure" usage.

However, remember this.  Your models will be used later than you intend.  Either by others who have to support your grand design in operation or by yourself sometime when you look at your system and think "Why the bloody hell did I do it that way?".  So when you have solved all your design issues, go back and edit the models into a formal "above the waterline" view and a formalised "below the warterline" view.  Do not let them tell you there is no budget for this.... (no I'd better not get into that argument - its bleedin obvious why there should be a budget for it and what happens if ther isn't).

hmmm - I seem to have strayed somewhat from the original issue here.  So what, its Friday here and I'm not going to recant - so there!

Bruce

[thomaskilian]

Ian- thanks for the hint. Just ordered the book  
Bruce - I like this iceberg "view". IMO the things below the waterline are rather clear. They are related to technical issues which can be solved by technicians. The difficulty is the part above the waterline. This is "the interface to real world" - and nothing is more difficult than real world things. What must be done is finding an abstraction in a way that a) the real world users and b) the analyst can understand what is meant. And here UML is weak. When you go into business nobody really thinks about "value". People think in "Activities". The way for finding the abstraction with UML does not really support the analysis. Or maybe I'm simply not wise enough and should have read more (like the book Ian suggested).

Probably this forum should have a main topic "UML Philosophers"  

Cheers, Thomas