Policy Nodes. Next to presentation issues, also the interaction with the
application contains cooperative aspects. The question is what to do when
multiple people are triggering one method? In such a case, the input of the users
must be interpreted before a method in the application logic can be called. An
example is a situation where multiple users can vote for one certain type of
pizza to be ordered. Depending on what the 'majority' chooses, the correct type
of pizza will be ordered. For this, simple rules in the "If
Roles. Modeling the roles has a direct relation with the Access Control and the Policy Nodes. For the Access Control, the role indicates what part of the information is available. The relation with the Policy Nodes is that the roles of the users involved in a cooperative session are used in the interpretation of triggers before the method in the application is called. In the Role Modeller the developer indicates what roles are involved in the cooperative tasks: names, types of users, etc.
Architecture. The cooperative features need to be incorporated in the architectural design of the Task Modeling environment. The architecture needs to be extended with Access Control, Policy Nodes and Roles. These aspects have a direct relation with the Presentation Components, which are based on the task model leaf nodes. At development time the task models should be used to indicate what the access rights and input interpretations are. At runtime, this information must be used as filter between the UI manager and the Presentation Components.
Gareth Brinley Smith ( 1995). "A Shared Object Layer to Support Cooperative User Interfaces", Computing Department, Lancaster University, UK.
Richard Michael Bentley ( 1994), "Supporting Multi-User Interface Development for Cooperative Systems", Department of Computing, Lancaster University, England.
Paternò F., Mancini C., Meniconi S. ( 1997), "ConcurTaskTrees: A Diagrammatic Notation for Specifying Task Models", Proceedings Interact '97, Chapman&Hall, pp.362-369