MBUI Telecon 2012 November 22
Scribed by Vivian
Present
- Vivian Motti
- Jean Vanderdonckt
- Pascal Beaujeant
- Jérémie Melchior
- Nesrine Mezhoudi
- Fabio Paterno
- Davide
- Carmen Santoro
- Joelle Coutaz
- Gaelle Calvary
- Gerrit Meixner
- Nikolas Kaklanis
- Paolo Bottoni
- Javier Rodríguez
- Cristina González
- Jaroslav
- Sebastian Feuerstack
Regrets
- Heiko Braun
- Ignacio Marín
- Dave Raggett
Scribe
- Vivian Motti
Minutes
We started the discussions based on the emails previously sent by Heiko, Sebastian and Paolo (concerning modelling producer - consumer)
- Open issues of the AUI documents
Modelling behaviors, events and producer-consumer relationship
- Section meta-model: new version of the meta-model for configuration (pictures to be moved to another document)
- Everything is linked to the configuration
- Unify the definition (uniform names)
- The UI commons will be a separate document (exclusive)
- 1st drawing: configuration meta-model
- Its configuration concerns a set of models (not 'just' a mapping model): composition of items
- Items can be codes, models, i.e. any artifact that is general to any model
- Definition compliant with configuration software management
- Jean: we focus on the models
- A configuration associates versions of the models: AUI, task, domain...
- Davide: move the configuration to the Introduction document and call within the AUI doc?
- Jean: Yes, in principle we can have an integrated view, but later, this should be moved to another document.
- locate the packages, but they will be separate definitions
- Jean: regarding Heiko's comments, in summary, keep behavior as event-condition-action patter
- links action direct to producer, and behavior to the consumer
- this pair (P,C) then connected by an interaction unit
- Paolo says an action can be connected to both producer and consumer of a resource (new or existing)
- understood by types
- Paolo agrees
- Heiko's proposal defends that producer is connected to the input, and the consumer linked to the interaction unit
- further clarifications needed
- For Jean, Paolo's model is symmetric and more general
- because an action is linked to both: P and C of a resource
- Joelle doesn't understand the link between producers and consumers
- in Paollo's version (blue background)
- Fabio: further clarifications needed for the role of P and C
- Paollo: minutes updated (last call-meeting) -> motivations, issues raised
- Connections between interaction units and behaviors
- Several types of behaviors that are connected (navigations, ...)
- how to model the notion of behavior?
- with Producer, Consumer?
- with Listener and Senders?
- Resources can be consumed: data, ...
- Beside the behavior model
- Action: could use resources, consume resources
- Behavior: collection of actions, can be connected to a unit that supports its behavior
- Notion provides an underline specification (abstract approach to consider behaviors' types)
- overall view
- Jean: listeners can be seem as consumers, and senders as producers, however it is a more general definition
- Paolo agrees
- Jean: event is a sub-class of resources
- Joelle: says why? it is unusual
- Davide: asks whether one resource only is associated with several resources
- Paolo: says it is a good question, 2 perspectives are involved
- Consumers can be seem as an interface that collects resources (not specific class)
- there is a method to consume a resource
- consumer: group of elements that consume a set of resources
- how events are shared or propagated (are consumed) among the members
- event is actually consumed by the first action
- 1st action reproduces the event, it is propagated until the last one consumes it
- 2 ways of seeing it
- not the single action, but the overall behavior consumes it
- action guarantees the behavior is still valide
- Events: as a sub-class of a resource
- resource is a type (we do not imposed anything specific to be relied)
- Way of characterizing resources (as P or C)
- Jean: another example than an event as a particular type of resources
- Paollo: not physically consumed (credential of the badget ?)
- Paollo: reader checks the presence of a resource that is consuming it
- Davide: Heiko's propose producer may be only Input interaction unit, shouldn't it be any type? and also external entities?
- Paollo: general model for defining behavior: producers and consumers may have specific inputs
- Paollo: not particulary happy with this definition, model should connect unit and behavior via an event support (input of the user, but not only... other ways of generating events too), a person enters the room and triggers an event for example
- characterize how an event is tiggered (not necessarily with a user input)
- Joelle: IU can be both a producer and a consumer, right? To check. Support this.
- Paollo: actually a P and a C are the behaviors, a IU can support the triggering of a generation of an event, and the consequences of the behavior (e.g. if a new resource is available)
- Fabio: an output or a container cannot be a producer (according to the diagram)
- Jean, Joelle concerns
- Paollo: does not agree with such definition
- Fabio: specific design, expressed by the diagram of Sebastian
- Paollo: to be discussed, not yet agreed
- Paollo: consumer produces, only on the side of a behavior, not the intermediate way of relating IUs and behaviors (representation support)
- Jean: behavior directly connected to the IU, definition of the behavior via this channel
- Paollo: not the behavior, but the event
- Jean: one IU linked to one or to many behaviors (attached to it), link in this way (before in the abstract user interface model class)
- Paollo: different issue, syntactic feedback, related to the UI model, behaviors related to the AUI model or to the task model (one are directly connected to the unit, others not)
- Jean: link between behavior model should go direct to the UI commons package
- Paollo: connections are really through the notion of events, way of relating unit to the events
- events support: present and connected to events, update the version because the units could also support presentation to the user or the effects of a behavior
- Jean: explained in the action part, do not want to impose a particular vocabulary now
- to proceed: diagram from Paollo: more general, so define a separated behavior model linked to the UI commons model, connects to the AUI model (express behavior correctly)
- Joelle: please create a consolidated version of the models, according to the discussion
- Jean: Paollo's model is more general
- idea: concentrating the behavior in a different model (across levels), this proposal supports this
- the separate model and package must check whether the links are enough between the behavior and UI commons (for AUI, domain, task model...)
- applicable to anythig, e.g. DRY principle
- concentrate behavior at one place
- declinate them depending on the requirements
- span across abstraction levels
- Gaelle: any impacts at the task meta model?
- Paollo: yes
- Fabio: two different abstraction level, logical activities, better not to mix the two aspects, understandable description of the concepts
- Jean: could we also express a behavior at the task level?
- Gaelle, Paollo agrees
- Fabio: difference between task and an action: not describe low level implementation
- Gaelle: do we use the behavior model to model the temporal relationships between tasks?
- Fabio: now the temporal relations are describe with operators
- Joelle: Jean will do a consolidation (behavior from the top level comments) then we see how it applies to the other levels (task, etc)
- Paollo: task model is primarily to describe organization and the temporal relations
- at the general level it also describes a transformation of the resources (like in the task), at the CTT environment this is also modelled
- Jean: like information passing?
- Paollo: represent the reflected transformation, I do not see a direct impact on the task meta model, but it is related...
- Joelle: we will see what happens after a consolidation
- more clear the models in focus
- Paollo: check the minutes
- Joelle: cannot understand the minutes, follow the discussions currently
- Jean: direction to separate things
- Joelle: advice will come later, clean version of the AUI, consensus Jean and Paollo
- be careful with last minute changes... hard to follow, analyse...
- Jean: Abstract behavior model (sent via emails)
- Joelle: hard to follow the discussion, does it serve both as a Consumer and a Producer, check and assure this (this is the case in real life)
- Jean: now we have realizations and dependencies at the UML class diagram
- Fabio: separate the behavior into a separate model?
- Jean: yes, following Lyon's decision
- Fabio: one single place describing what the AUI is, clean, focused,
- Jean: yes, it follows Lyon's proposal, a class diagram for both proposals can be done, and then compared (behavior integrated or separated)
- Fabio: agrees, it sounds good
- Jean: ok, both options will be then discussed next week
- Gerritt: for the next week: use cases descriptions are already better now, and is the topic for discussing next week
- Jean: further references to reinforce the usage of model-based, more references are still needed though
- Gerritt: yes, more references would better support, please add them in the Introduction document
- Jean: next version of the model by next Wednesday (email will be sent notifying it)
Actions
- ...