Fwd: Support Stereotype & Producer/Consumer concepts

Begin forwarded message:

> From: Paolo Bottoni <bottoni@di.uniroma1.it>
> Subject: Re: Support Stereotype & Producer/Consumer concepts
> Date: January 10, 2013 12:26:21 PM GMT+01:00
> To: Heiko Braun <ike.braun@googlemail.com>
> 
> Hi Heiko
> 
> 2013/1/10 Heiko Braun <ike.braun@googlemail.com>:
>> 
>> 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
> 
> 
>> 
>> 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?
>> 
>> On Jan 8, 2013, at 10:51 PM, Paolo Bottoni <bottoni@di.uniroma1.it> wrote:
>> 
>> . 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.
>> 
>> 
> 
> 
> 
> -- 
> Paolo Bottoni
> 
> Associate Professor of Computer Science
> 
> Email: bottoni@di.uniroma1.it
> 
> Website: http://w3.uniroma1.it/dipinfo/scheda_docente.asp?cognome=Bottoni&nome=Paolo
> 
> Phone: +39 06 49255369
> 
> Fax: + 39 06 8541842
> 
> 
> 
> Important conferences:
> 
> http://www.etaps.org/
> 
> http://vlhcc2012.di.unisa.it/
> 
> http://www.informatik.uni-bremen.de/icgt2012/