Re: Structure Behaviour Relationship

Dear colleagues,

sorry for not participating the last two telcos. I just arrived back
this weekend from traveling and i am now trying to catch up with the
discussion.

I really like the idea to specify the consumer/producer part by
interfaces and types as proposed by Paolo as it better separates
behavior and eases re-usability in other models.

Further on, i am in favor of separating input from output to ease user
interface distribution to output-only platforms. Thus, only input
interaction units should be allowed to produce events and a selection is
an input in my understanding.

Looking at Heiko's contribution i really like the straight-forward class
naming (container, output, input, edit, selection). For me Heiko's model
seems to be much more self-explainable than our current one in the document.

As Dave mentioned at the meeting in Lyon we require implementation
reports to proof support from the community. I think the more attributes
and concepts we include in the first document the higher will
be the barrier for others to support our proposal.

Maybe it would be worth to publish a first AUI document using a
condensed "core" AUI model just with the basic classes and "required"
attributes only?

By extended AUI models we then could specify advanced features such as
localization, constraints, documentation and so on as well as show
additional features of specific implementations of the model to help
readers to figure out an implementation that fits their needs.

Attached three images: a condensed core model based on Heiko's and
Paolo's suggestions, and two extended models: the extension to match the
current AUI document model(just the differences without attributes) and
the one that shows how our approach (MINT) considers the condensed model.

Cheers,
Sebastian



On 17.11.2012 08:24, Paolo Bottoni wrote:
> Dear all,
> 
> thanks to Heiko for this contribution. 
> 
> I am not completely convinced by it, though.
> 
> As I was saying during the telco, I see actions as both producers and
> consumers of resources of some kind, events being such a type of
> resource. Behaviours are specific structurings of actions, and one can
> also specify the global production and consumption of resources they
> entail. 
> 
> So, I see things roughly as described in the picture below. I use here
> interfaces rather than classes, as the way in which actions or
> behaviours produce or consume resources can be arbitrary. As I said, I
> see this as the foundation for a general view of the semantics of
> interaction, common to both AUI, CUI, Tasks, and Domain models. That is
> also the reason why I would see actions and resources as types, rather
> than actual classes, as they can actually be realised in different ways,
> e.g. by hardware components or physical elements, and not necessarily by
> software elements.
> 
> best
> paolo
> Immagine in linea 1
> 
> 2012/11/15 Heiko Braun <hbraun@redhat.com <mailto:hbraun@redhat.com>>
> 
> 
>     As a followup for todays telco:
> 
>     An attempt to model the relationship between structure and behaviour
>     along the lines of "produce/consume" or "send/listen" semantics:
> 
> 
>     It's merely food for thought, but maybe helps to fuel the discussion.
> 
> 
>     Regards, Heiko
> 
> 
> 
> 
> -- 
> 
> Paolo Bottoni
> 
> Associate Professor of Computer Science
> 
> Email: bottoni@di.uniroma1.it <mailto: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/
> 
> 
> !DSPAM:50a7662431501772216651!


-- 
Sebastian Feuerstack
Department of Computer Science
Federal University of Sao Carlos - Brazil
http://www.feuerstack.org

Check out MINT 2010 - the Multimodal INTeraction Framework
http://www.multi-access.de