Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: wolfgang.uhr on May 18, 2006, 05:58:36 am
-
Hello
I've added a scan of a use case example of the book "Writing effective use cases" (http://applikationssoftware.de/Sonstiges/UseCase.jpg). An now my Idea is to insert thoose data in an EA-use-case. Then I have the following problems:
Scope
In the book it is a free text and in EA only "public, protected, private, package" are availiable
Level
I cannot find in EA
Context of use
May be the note field?
Primary Actor:
I cannot find in EA
Preconditions
Ok - Precondition constraint
Trigger
I cannot find in EA
I think, that this will be enough, because you should kwno, what I mean.
Best Regards
Wolfgang
-
Scope
In the book it is a free text and in EA only "public, protected, private, package" are availiable
You may use a tagged value
Level
I cannot find in EA
dito
Context of use
May be the note field?
Yes. Or again a Tag
Primary Actor:
I cannot find in EA
You might try a stereotype <<primary>> in the association
Preconditions
Ok - Precondition constraint
Yes. There's a thread about the internal/external conditions I can't find right now.
Trigger
I cannot find in EA
Constraint as Pre-Condition
I think, that this will be enough, because you should kwno, what I mean.
Best Regards
Wolfgang
-
I'll try to answer a few of these Wolfgang.
UML defines the four scope values that EA presents. Some tools ask - or allow - you to type them in freehand. Of these tools, some then validate what you typed, so you have to use one of the defined values, and some allow the value to remain as typed. This is useful for non-English models, but can wreck havoc when you move to code engineering. Note that UML does not provide for all scopes in use by major languages and development platforms, so many tools allow extensions here.
Level may refer to how far you have to drill down to the use case. It is not - to the best of my knowledge - a value from UML. Hopefully the gurus will correct me if I'm mistaken here.
Yes, the notes would be good for context. You would want to explain, if it was not obvious to your audience - why, how and when this use case might come about.
Primary actor. This is to distinguish an Actor from a Secondary Actor. This is not a formal UML distinction, but is very useful in some cases. Some methodologies, or modelling approaches in a less formal sense, identify as actors systems or roles that affect (or are affected by, or participate in) the use case in some indirect manner. You sometimes see secondary actors indicated by the rectangle notation with an <<actor>> stereotype shown and the primary actors as the common "stick men." [I personally find this quite useful, particularly when I present to less technical audiences.]
An example of primary and secondary actors would be the "Withdraw cash" use case for an ATM controller. The customer is a primary actor, and participates directly in the use case. The use case itself scoped to the ATM (this would be in your context) but must have some interoperation with the bank's account management system; however the bank's systems are not within scope, nor will the builders of the ATM be designing or modifying the bank's systems. The bank, or its account management system (depending on your level of detail) is involved however, and the use case depends on interaction with the bank. Thus, the bank, or its system, is a secondary actor in this case.
Preconditions - yes, you've got it.
Trigger. Similar to the context stuff. What event or circumstance causes this use case to be invoked? In the case of lower-level use cases this can be important. In a small system or one with straightforward interactions, you may not bother with this. For example, Enter Data, Maintain Database, etc. might be fairly obvious for the bowling league's game tracking system. But, in the case of a multi-user distributed, Web-based system you may really need to know why this use case should happen (context) and what specifically caused it (trigger) before the scenario makes sense.
HTH,
David
-
Hello David
Thank you very much for that short explanation. The problem I have. In German there is a difference between "trigger" and "precondition"
trigger means that the use case stars imedeately after this event.
precondition means that the use case is able to start if this condition is fullfilled but it does not start.
But normaly I would think, it should be the same in English, isn't it?
Best regards
Wolfgang
-
No, it is the same in English. I would however say that if the precondition were true it would not necessarily start. That is, the precondition is necessary but not sufficient to start the use case.
-
No, it is the same in English. I would however say that if the precondition were true it would not necessarily start. That is, the precondition is necessary but not sufficient to start the use case.
Ah yes... that beautiful phrase...
necessary but not sufficient
Too often people confuse necessary with sufficient!
Paolo
-
Yes. My Pre-condition shot was a bit too fast. Symply saying: I write the trigger in the notes text of the Use Case along with other general information. I live luckily with that solution.
-
I write the trigger in the notes text of the Use Case along with other general information. I live luckily with that solution.
You are right. That might be the best way to handle this. I'll delete my post in "Suggestions and Requests".
Thanks and best regards.
Wolfgang