Support Stereotype & Producer/Consumer concepts

Due to a mistake on my side recent discussion between me an Paolo has not been tracked on the mailing list.
Here's a transcript of the discussion:


Paolo&Heiko about the behaviour model (in reverse order):
--------------------------------------------------------------------------

that's the problem!

Apparently I produced all the pictures, but then I did not save the
vpp. :-(((( I should then reproduce the vpp from the pictures

I am sending you the zip with all the pictures. As I said, I did not
add attributes or operations, as these were meant  to be integrated
with the specifications for classes with the same name in the previous
model .

also, the hierarchies are incomplete and used only to give examples of
how they would develop

best
paolo

---

Thanks, that explains a lot.

I don't have access to any diagram that shows the full picture, hence some
of the ideas you proposed haven't been obvious to me.  But I agree, we are
on the same page.

I think we need a shared space to exchange and operate on the diagrams. I am
fine with vpp, but any exchange format would do as well. I would suggest we
put it under version control on a centrally hosted repository (i.e.
github.com), so that anybody who wants to participate can have access to the
designs.

In the meantime: would it be possible that you send me your vpp files in
preparation for todays call?

Regards, Heiko

On Jan 10, 2013, at 12:26 PM, Paolo Bottoni <bottoni@di.uniroma1.it> wrote:

I would have to consider your examples in detail, but I think we might
be on the same frequency
For example, it might be that an event triggers a behaviour whose
conclusion triggers a navigation which must result in the substitution
of the previous presentation resources with those needed for the next
activities,

In another case, a navigation can be directly triggered by a navigation
event

In any case, it is the responsibility of the behaviour to consume and
produce the proper resources, not of the interface. Note that in my
view Behaviours can refer to different things: the progress of a
workflow, a transaction, a complex computation, the
generation/enabling/disabling of parts of the interface, of which
navigation is a special case.

Since we might have several event supports associated with the same
interaction unit, several things can occur at a time.

In general, yes, I think your last observation is correct.


---

Thanks, that explains a lot.

I don't have access to any diagram that shows the full picture, hence some of the ideas you proposed haven't been obvious to me.  But I agree, we are on the same page. 

I think we need a shared space to exchange and operate on the diagrams. I am fine with vpp, but any exchange format would do as well. I would suggest we put it under version control on a centrally hosted repository (i.e. github.com), so that anybody who wants to participate can have access to the designs.

In the meantime: would it be possible that you send me your vpp files in preparation for todays call?

Regards, Heiko

---


Hi Heiko

Thanks for the explanation Paolo.
One question though: If there is only the "supports" concept, how would you
model the "producing" and the "consuming" side of things? Maybe I am
complete off track, but my lines of thinking come from the question how the
model and it's realisation as CUI can be validated. It seems to me that the
direction of these relationship matters.

Let me say that I just sketched the names of the classes, and left a
few things implicit.

So, of course a Producer is characterised by a produce():Resource
operation. EventSupport is a realisation of Producer and so it is its
responsibility to implement this operation. More specifically, the
different specialisations of EventSupport will produce Events of
specific type. There might be some casting involved here, as producers
only produce resources, but the specific behaviours would know what
types of resources, or more specifically of events, they would need to
consume. This discussion can be mirrored on the presentation side,
where the specific PresentationSupport would know what types of
resources they would need to consume (or read). For example a list
selector would consume list resources.

I would have to consider your examples in detail, but I think we might
be on the same frequency
For example, it might be that an event triggers a behaviour whose
conclusion triggers a navigation which must result in the substitution
of the previous presentation resources with those needed for the next
activities,

In another case, a navigation can be directly triggered by a navigation event

In any case, it is the responsibility of the behaviour to consume and
produce the proper resources, not of the interface. Note that in my
view Behaviours can refer to different things: the progress of a
workflow, a transaction, a complex computation, the
generation/enabling/disabling of parts of the interface, of which
navigation is a special case.

Since we might have several event supports associated with the same
interaction unit, several things can occur at a time.

In general, yes, I think your last observation is correct.

best
paolo


--- 

Thanks for the explanation Paolo.
One question though: If there is only the "supports" concept, how would you model the "producing" and the "consuming" side of things? Maybe I am complete off track, but my lines of thinking come from the question how the model and it's realisation as CUI can be validated. It seems to me that the direction of these relationship matters.

From my point of view any distinct relation between structure and behaviour will always be unidirectional and qualified by the consumed resource type. 

Typical examples are:

- Trigger (structure) leads to function call (behaviour)
- Navigation (behaviour) leads to activation of interaction unit (structure)
- Functional Call (behaviour) leads to navigation (behaviour)
- System event (context of use) leads to activation of interaction unit (structure)
- [...]

IMO these relationships, their direction and qualifier (resource: event, data, etc) would need to be expressed within the abstract model that covers structure and behaviour. It's necessary to support the reification across abstraction levels. Especially when moving from abstract UI to concrete/final UI.

Does that make sense?

Heiko


---


Dear Heiko,

thank you for your message.

Sorry for the late reply, but I was out the whole day, and I will also
be tomorrow.

Also, I seem to have not saved the vpp project where I had drawn a
full proposal, and the pictures which summarised it are only at the
office. I should have sent the collection of class diagrams some time
again, though.

In any case, the idea was that the EventSupport was an abstract class
from which ConcreteSupports for concrete events were specialised. An
AIU had a composition relation with any number of EventSupports
(symmetrically we can have a notion of PresentationSupport).
Specialisation for EventSupport might be InputSupport,
SelectionSupport, TriggerSupport, etc. What an EventSupport generates
is an event of the corresponding type. This constitutes the bridge
with the notion of Behaviour, as behaviours produce and consume
resources, events are a special type of resource, and interactive
behaviours consume interactive events, for example as triggers, or
input data to be transformed.

I hope these lines, without the support of diagrams, sound consistent to you.

Please note that the current version of the AUI model on the googledoc
does not reflect this view. I already wrote to Jean about this,

best

paolo

--- 


Paolo,

in one of your earlier drafts there used to be the concept of "producer/consumer" and "resource". In the newer versions the "support" stereotype has been introduced. How does "support" relate to "producer/consumer"? Do we keep the notion of directed associations whereas a "resource" is "produced" and "consumed"? 

Regards, Heiko

Received on Thursday, 10 January 2013 11:50:03 UTC