There's a question on the test that asks if it's valid to mix Actor interactions with System interactions on the same line. Craig Larman's book shows them seperate and that's the recommended reading, but every other method I've seen combines them. Any clue?
I took a look at "UML Distilled" by Martin Fowler, "Applying Use Cases" by Geri Schneider and Jason Winters and "Writing Effective Use Cases" by Alistair Cockburn. They all show pretty much the same style recommended by Larman: Actor and System actions are listed as separate steps in the use case. J.Lacar
I read "Writing Effective Use Cases" by Alistair Cockburn. And he combines the user and system interactions, in fact we use the RUP at work and the RUP template combines them as well. I definitly don't see that being a popular methodology. Allistair encourages they be on the same line, in fact he sometimes combines mulptiple interactions on the same line.
I have only skimmed through Alistair's book so could you please tell me on which page does he encourage that interactions be placed on the same line. I looked at section where he describes the RUP template (pg. 123) and the example use case provided by Rational Software Corp. states each step as being performed by either Actor or System. It seems that putting the actor and system actions on the same line would violate his Guideline 1: Use Simple Grammar (Subject...verb...direct object...prepositional phrase). Or maybe I misunderstand what you mean by "interactions on the same line". J.Lacar
Joined: Nov 03, 2000
You are correct. I reviewed his text and found I never even noticed the two being seperated. I assumed that summary level use cases would combine the two, but they are not. Thanks, for your help, the guideline definitly answers the question. What a relief that Larman's info matches Cockburns...
I guess the question is this: What is wrong with the following analysis use case? ( see http://certify.torolab.ibm.com/figures/test486F3.gif ) a) The actor's actions and system responses are not separated. b) There is nothing wrong with this use case. c) There are design details intermixed with the requirements. d) "Sell goods" is too broad to be a use case.
Single Select - Please select the best answer (one and only one choice must be selected).
I think the separation is recommended but not required, I would say (b) there is nothing wrong with this use case. Any input is welcomed.
[This message has been edited by Caroline Iux (edited May 15, 2001).]
The question states that this is an analysis use case. There is, however, mention of several design/implementation details, e.g., cash register, scanned, "Void item" button. Answer then would be C: There are design details intermixed with the requirements. Junilu
[This message has been edited by JUNILU LACAR (edited May 15, 2001).]
I agree with Junilu, there is a design mix in the analysis use case.I would lean towards c. -- Sandeep
<b>Sandeep</b> <br /> <br /><b>Sun Certified Programmer for Java 2 Platform</b><br /> <br /><b>Oracle Certified Solution Developer - JDeveloper</b><br /><b>-- Oracle JDeveloper Rel. 3.0 - Develop Database Applications with Java </b><br /><b>-- Object-Oriented Analysis and Design with UML</b><br /> <br /><b>Oracle Certified Enterprise Developer - Oracle Internet Platform</b><br /><b>-- Enterprise Connectivity with J2EE </b><br /><b>-- Enterprise Development on the Oracle Internet Platform </b>
Joined: May 14, 2001
C would be my gut feeling choice. I guess it depends on how you define "analysis use case". These design details are valid in real use case. If a real use case is not an "analysis use case", then c is definitly the answer.
Joined: Apr 02, 2001
Originally posted by Caroline Iux: If a real use case is not an "analysis use case", then c is definitly the answer.
Real use cases is one of the artifacts of Design Phase.See Chapter 37, Figure 37.10, Applying UML and Patterns, Craig Larman Hope this helps, -- Sandeep