MBUI Telecon 2012 November 22

From W3C Wiki
Jump to: navigation, search

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

  • ...

Decisions