I do not understand well following topic since it is a bit ambiguous from what I read:
Inlcude is like a reference to next part, the usecase is not completed without it. This part should be referenced from more places otherwise its use has no sense.
But I have seen an example when there is "include" only in some IF statement is true, like:
Add new product--->include--->Add new manufacturer. //Adds only when doesnt exist. Why there isnt "extend"? Is it because somewhere else could be "Add new manufacturer" used once again?
Thanks
Exactly. Once you extend another use case you've reached the end of your current use case. However, you can have extend inside an if. Imagine the following.
1) The driver asks if his guests want Wendys or Burger King
2) The guests choose they want Burger King [extend to eating at Burger King (use case 5)]
3) The guests choose they want Wendys [extend to eating at Wendys (use case 9)]
An include doesn't end a use case, it uses another use case and then returns. An include is similar to a function call. You perform the actions in the other function and then you return and continue. You can also have an include without an if statement.
1) The driver orders the food
2) The driver drives to the first window
3) The driver pays the cashier (include handling a credit card transaction (use case 3)]
4) The driver drives to the second window
5) The driver gets the food
Notice that in the above an extend wouldn't work. This is because the driver still needs to go to the second window and get the food. If we extended to use case 3 then we would never return to this use case.
Here's an explanation from the following topic: UML Use Case Diagrams: Reference at http://msdn.microsoft.com/en-us/library/dd409427%28VS.100%29.aspx
Include: An including use case calls or invokes the included one. Inclusion is used to show how
a use case breaks into smaller steps. The included use case is at the arrowhead end.
Extend: An extending use case adds goals and steps to the extended use case. The extensions
operate only under certain conditions. The extended use case is at the arrowhead end.
Include and Extend relationships on a use case diagram http://i.msdn.microsoft.com/Dd409427.UML_UCOvStructure(en-us,VS.100).png
Related
So I have 2 scenarios....one starts out
Given I have 1 car
The other starts out
Given I have 2 cars
I'd like them to use the same step definition - ie something like this
Given('I have {int} (car|cars)',
I know it's possible to do specify 2 possible values (ie car or cars), but I can't for the life of me remember how. Does anyone know? I'm using typescript, protractor, angular, selenium.
Have also tried
Given(/^I have {int} (car|cars)$
Within cukeExp, the () become optional characters. That is what you want.
So your expression would be
Given('I have {int} car(s)')
Happy to help - More information can be found here: https://cucumber.io/docs/cucumber/cucumber-expressions/ - Switch to JS code at the top.
Luke - Cucumber contributor.
Luke's answer is great and is definitely standard practice when cuking.
I would (and do) take a different approach. I would strongly argue that the complexity of even a single expression like the one he uses isn't worth the step duplication. Let me explain and illustrate.
The fundamental idea behind this approach is that the internals of each step definition must be a single call to a helper method. When you do this you no longer need expressions or regex's.
I would prefer and use in my projects
module CarStepHelper
def create_car(amount: 1)
Lots of stuff to create cars
end
end
World CarStepHelper
Given 'I have one car' do
create_car
end
Given 'I have two cars' do
create_car(amount: 2)
end
to
Given('I have {int} car(s)')
lots of stuff to create cars
end
because
the step definitions are simpler (no regex, no cucumber expression
the stuff to create the cars is slightly simpler (no processing of the regex or expression)
the helper method supports and encourages a wider range of expression e.g.
Given Fred has a car
Given there is a blue car and a red car
the helper method encourages better communication between steps because you can assign its results relative to the step definition e.g.
Given Fred has a car
#freds_car = create_car
end
Given there are two cars
[#car1, #car2] = create_car(amount: 2)
end
Cucumber expressions and cucumbers regex's are very powerful and quite easy to use, but you can Cuke very effectively without ever using them. Step definition efficiency is a myth and often an anti-pattern, if you ensure each step def is just a single call you no longer have to worry about it, and you will avoid the mistake many cukers fall into which is the writing over-complicated step definitions with lots of parameters, regex's and|or expressions.
As far as I know, your step definition should be as below for it to work.
Given(/^I have "([^"]*)?" (car|cars)*$/, (number, item) => {
You can still simplify the first regular expression.
Cheers!
We are learning in school that behavioral State diagram's transition has syntax:
list of events [guard condition] / list of actions
But I couldn't find any example on Internet where is used transition with multiple events. Is it really possible? If yes, how does it behave? Does it mean that transaction is realized when one of this events occurs (and of course condition is fulfilled)?
Yes, a transition can be triggered by one of many events in a list. You would use such a construct to avoid multiple lines between states, making a tidier diagram.
Here is what the 2.5 spec says:
14.2.3.9.2 Enabled Transitions
A Transition is enabled if and only if:
[ . . . ]
At least one of the triggers of the Transition has an Event that is matched by the Event type of the dispatched Event occurrence.
These logically OR'ed transitions are specified textually as a comma-separated list on the transition, as specified in §14.2.4.9:
[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
Unfortunately the UML spec is not specific in that respect (I thought, but Jim has the right answer). Anyway:
14.2.4.9 Transition
The default textual notation for a Transition is defined by the following BNF expression:
[<trigger> [‘,’ <trigger>]* [‘[‘ <guard>’]’] [‘/’ <behavior-expression>]]
Where is the standard notation for Triggers (see sub clause 13.3.4), is a Boolean expression for a guard, and the optional is an expression specifying the effect Behavior written in some vendor- specific or standard textual surface language (see sub clause 16.1). The trigger may be any of the standard trigger types. SignalEvent triggers and CallEvent triggers are not distinguishable by syntax and must be discriminated by their declaration elsewhere.
There are other places in the specs where this paragraph appears in similar way, but without explaining how multiple triggers will be treated. I assume that it's an OR-condition. But that's only an assumption. Alas, since you have not seen examples (me neither) it is probably an unknown fact. Just don't use it - that's indeed possible ;-) And if you happen to find an example, just ask the author what he meant. UML is about talking to each other.
Is it legal to draw up an include relationship between two use cases that are each associated with a different actor?
Yes this is legal, but I think it should not interpreted as #vainolo suggested.
Suppose this scenario
In this case Actor X has direct access to Use Case A and because Use Case B is included by Use case A Actor X also executed the behavior described in Use CAse B
But only Actor Y has direct access Use Case B.
Actor A only has indirect access through Use Case A
At least that is how I interpret it. The UML specs will only tell you this is a valid UML syntax but will not say much about the meaning of such a scenario.
It's completely legal. What this means is that if the including use case calls the included use case, the actor that is connected to this use case is required.
Lets say i have Use Case A (Cancel Consultation),B (Destroy Patient Image) and Actor C (Patient).
Use Case A includes Use Case B, and Actor C triggers Use Case A to happens. My question is, do i need to add a <> from the Actor C to Use Case B ? I was thinking ,Use Case B happens only if Use Case A fires, which means Actor C ONLY triggers Use Case A.
Not so sure that if Use Case A includes Use Case B, and Use Case A triggers by Actor C, therefore Use Case A and B has the primary actor of Actor C ???
From description I'd say you don't need a relation between Actor C & Use Case B.
Rationale: A link between an Actor and a Use Case should represent a meaningful unit of value to the Actor. From your description, "Cancel Consultation" is that meaningful unit of value; it's what the Patient sets out to accomplish.
Destroying the image is a necessary requirement of cancelling the consultation. However - at least in this example - the Patient doesn't set out just to destroy the image. Hence no link between Patient & Destroy Image.
Of course: that could change. As you explore the domain, you might find a scenario in which it's valid for a Patient (or perhaps another Actor) to destroy an image. Perhaps a Radiographer would destroy an image if it didn't focus correctly (dunno, I'm making this up).
All comes back to the User intent. You should link Actors with Use Cases that capture their goals, not sub-steps within those goals.
hth.
can two use cases extend or include each other at the same time?
A extend/include B and B extend/include A
I'm pretty sure the answer is "NO".
You've just described the digital equivalent fo the chicken and egg problem.
Circular references are [almost] always Bad Things (tm). The only place I know it to not be horrible is in the context of a linked list, in which each entry has a pointer to another of its own type.
If (A includes/extends B and B includes/extends A) then A = B
Admitting that if A extends/includes B then A >= B
It seems likely not, though I'm sure you could do it if you went generic [and useless] enough. Do you have a specific example? There are always exemptions to the rules and I'd be curious to see one.
below is the senario for business use case (business modelling) not system use case:
USE Case A: Service Vehicle
Use Case B: Authorise Additional repair
Use Case C: Repair Vehicle
Additional repair could be identified during initial repair.
or repair could be identified as a new repair during service,
in both case, customer authorisation is required?
A extend B and B extend C (authorisation and start of repair identified during service)
C extend B (authorisation for additional repair identified during repair)
It's rare but in the general case, there's nothing that prevents use cases from including/using each other.
the answer is no. extend and include are mutually-exclusive relationship types. Most likely the use-cases are incorrectly factored/separated, or you've misunderstood the extend/include relationship definitions, or both.
given the example you posted (fyi it is better for you to edit the question rather than post an answer that does not answer the original question) i would venture that B extends A and B extends C, since in both cases A and C additional repairs (case B) may be identified.
alternately, use cases A and C could conditionally include use case B
offhand, i would model this as Work On Vehicle, which is a composition of 2 use-cases, Obtain Customer Authorization, and Service Vehicle, where the latter includes any kind of service or repair and requires the output of the former before starting the work. The notion of 'additional repairs' is just another instance of Work On Vehicle.
but i don't know the full business context, so your mileage may vary ;-)
EDIT: you wrote "but in this case: work is being carried out and further authorisation is required during the course of work", but i don't see how that really matters.
the first step is to eliminate the confusion about includes and extends. Try modeling each use-case completely and independently, and then look at what is common to see if includes/extends is warranted
"YES" - Checked the Spec.
I just read through the UML specification section for use cases:
http://www.omg.org/spec/UML/2.1.2/Superstructure/PDF/
There was no rule that would prevent doing this that I could find. Many people may conceptually have a problem with this, but that is ok, as you are just instinctively trying to objectize or structure use cases logically. Use Cases are a behavior (or set) and are not like classes/"objects". We are not talking about Java objects.
Even in Rational Software Modeler (IBM) allows this "circular reference".
In practice and in trying to map this to Java or other Object languages it may not make sense or get confusing.