Is it possible some how to assign a Dialogflow intent to contexts with disjunction union.
I.e. I need an intent Test<A | B> to be triggered whatever single of contexts A or B are being active even if solely.
Since I don't want to duplicate a whole the intent with the only difference in theses context references.
This is not possible at the moment, but you can open a Feature Request by following this link.
Related
I would like to use StateMachineConfig in https://github.com/stateless4j/stateless4j to configure various transitions of states based on events received from kafka. However in order to evaluate the conditions in either .permitIfElseIgnore (FuncBoolean guard) or .permitDynamic (Func interface), I would need to take the state of the objects into account, since we are unable to rely exclusively on the event type itself. Can this be accomplished with the stateless4j lib? Somehow define functions to the configuration and have the parameters evaluated at runtime in order to determine the correct transition?
I have a question regarding modeling on an Activity Diagram that has been bothering me for some time and I was not able to find any answers / Convention anywhere.
Here is an example to better understand my question:
Let say that I have two class named "flat" and "house". both are a generalization of the class "housing".
housing contain an attribute "residents" for the person living in it.
flat contain an attributes "floor" that says at which floor the flat is.
Here is the class diagram:
In an activity diagram, I want to represent the action of giving persons a housing.
this action can take either house or flat as input (so the use of "housing" type for the input pin is correct I think) as well as an undefined number of people.
I want this action to give an updated house or flat as output (not an updated housing as this would mean that information specific to the house or flat would be lost.
I don't really know if I must create two actions (one for house and another for flats) or if there is a way to reuse the action for both class and have a correct output out of it.
Here is the activity Diagram:
My question is: how to represent in an activity diagram, an action that is the same for different type of Object flows as input, and that give the updated Object flow as output (that may be therefore of different type)?
nb:
all type of object flow are class and inherit from a same other class.
I'm representing this in modelio but first had this issue in Cameo.
I'm Trying to fit as best as I can within the rules of UML Language.
Cameo is right in rejecting this model. Give Flat Floor expects a Flat and will not work with a House, but Assign Resident to Housing could return a House. I know, in your context it can only return a Flat, but how should the tool know that?
The correct way to capture this fact would be to add a postcondition to Activity Assign Resident to Housing that states that the type of the input and output pin will be the same.
However, it would be really hard to define a complete set of compatibilty rules that takes into account all the global and local pre- and postconditions and the tools would also be hard pressed to validate a model according to these rules. Therefore the UML specification choose the easy road and simply doesn't allow to connect the pins.
The solution is to use the transformation property of the ObjectFlow. Just assign an OpaqueBehavior that casts the Type House to the Type Flat. Cameo will then accept the model. It is the modelers responsibility to ensure, that this cast will always work, since no exception handling can be defined here. Maybe this should be documented with a local postcondition.
In your specific example there is an even easier solution: simply fork the ObjectFlow of Type Flat and omit the OutputPin of Assign Resident to Housing.
As a side note: Due to a bug in Cameo, you can change the type of the OutputPin to a more specific Type than that of the ActivityParameter. This is correct for InputPins, but should be the opposite for OutputPins. You could use this to let the Parameter be of type House, but the OutputPin-Type would be Flat.
The two flows (top object and lower control) in the blue frame could stay as they are. Give flat floor would commence only when it receives a Flat object and the control token is sent. In order to make the right action sort of optional I would just use the object flow, thus only triggering when a Flat object is passed. That would just be enough and no additional control flow is needed.
To make things clear I would also add a guarded flow from the Assign action to an exit reading [ house was assigned ] or the like.
I'm building a chatbot that asks users for symptoms, one at a time.
There is a single entity #symptom, which is a list. I'd like to figure out how to append each new symptom into the symptoms parameter list from existing contexts.
For example,
Bot: Please type in your 1st symptom.
User: Cough
symptoms = ['cough']
Bot: Please type in your 2nd symptom.
Fever: Fever
symptoms = ['cough', 'fever']
Bot: Please type in your 3rd symptom.
User: Breathlessness
symptoms = ['cough', 'fever']
How do I go about building such a flow?
(N.B. I know I can simply have one intent that asks user to type out all the symptoms in one line, but I'd prefer for the symptoms to be asked one by one so I can ensure data cleansing before inserting the symptom into the list)
This too is more of a design issue:) You can roughly achieve what you have described with Follow-up intents and contexts, but a better way would be to more clearly separate the intent and parameter matching from any kind of further backend processing.
You should, if you haven't already, define your symptom entity as a Developer mapping entity. This gives you the option to map an arbitrary number of synonyms to one reference value:
reference value: fever
synonyms: fever, feverishness, high temperature, febricity, febrility
The user can now enter any of the synonyms, you will always get the reference value as the parameter (and list of these values if the parameter is a list). The reference value doesn't even have to be a normal word, it can be any unique identifier (e.g. a primary key from database of symptoms). It is only matched if it itself is included in the list of synonyms.
This structure would ensure that you will always get a parameter from a clearly defined set of values, even if the actual user input has a much greater variability. Any further processing of these parameters should be part of your backend code and not be tied to the Dialogflow agent. Ideally you would think of the reference values as the API between the user input and you backend business logic.
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.
Object B contains a bunch of public events.
Object A subscribes to these events.
What is the UML relationship between these?
Currently I have a directed association from Object A to Object B. Is that correct? Or should the direction go the other way?
It depends on what you want to express.
Logically, the subscriber A must know the publisher B, and the other way round, so you have a bidirectional relationship.
Technically, often the subscriptions are not managed by the publisher B but by some dispatcher D. The subscriber A knows the dispatcher D and the other way round. But the publisher B doesn't know A and, depending on the platform offering the broadcasting mechanism, maybe not even the dispatcher D. So, if you have a particular platform in mind, find out which types of objects need instance variables to reference other objects, and model the relationships according to that.
There should be a dependency relationship from A to B (a dashed arrow pointing from A to B). Chapter 7.8.4.1 of the UML spec version 2.5 reads:
A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other model Elements for their specification or implementation.
In your case, A requires B to exist, but B does not require A to exist. Maybe B requires A to implement a particular interface. In that case, B depends on the interface, but not on A itself.
You propose to have an association from A to B. An association is stronger than a dependency. It means that A has a property of type B (well, the definition is a bit more complex, see chapter 11.5.3.1 of the UML spec). This implies that A depends on B, like a dependency, but a dependency does not require A to have a property of type B.
To summarize:
The arrow should point from A to B, not from B to A (unless your particular implementation of B depends on the existence of a class called A, which is unlikely).
A dependency is enough, but if you want A to have a property of type B, then you may draw an association (solid line) instead of a dependency (dashed line).
Both A and B probably maintain references to one another. A may want to unsubscribe, and B certainly has to be able to notify A of events. Thus, I would model it as a bidirectional relationship. You might even want B to compose all the subscribing instances. Check out the well known Observer Pattern.