Software architectures dedicated to interactive software have been pro-posed since the early 1980s and the most known ones are the Seeheim model [10] or the ARCH model [1 ,2]. The ARCH model is an extension of the Seeheim model. We chose the ARCH model because it proposes a generic view of an interactive system. The ARCH model breaks down an interactive system into five components: domain specific component, domain adaptor component, dialogue component, logical presentation component, and physical presentation component. We turn this model into a simple ARCH model within only three components. The first two components are dedicated to the no interactive part of an interactive system and are thus merged in a component called functional core. As we are less concerned with implementation issues than design ones, we have decided to merge presentation components together in a component called presentation component. In our models, questions can be structured according to that architecture and thus related to one of the components: functional core, dialogue, and presentation. This relationship might not be defined and thus a question is not necessarily related to a component to capture, for instance, broader topics.
This structuring supports decomposition of problems adequately when dealing with interactive systems. In addition, it makes it possible for man-aging the argumentation at various levels of abstraction from higher-level phases such as specifications but also at lower level phases such as de-tailed design and implementation phases and this for any of these components.
All the extensions proposed are dedicated to the support of designers’ activities such as structuring of models, editing of models and information retrieval from models. All the extensions supported by TEAM notation are summarized in the entity relationship diagram presented in Fig. 7.1. Additional extensions such as design choices for each node (i.e., questions, options, etc.) connection of arguments…are available in TEAM but have not been presented in the previous sections, as they are standardd extensions in rationale management and not specific to interactive systems. displays the entity relationship model of the TEAM notation. Rectangles represent entities; entity name is the first item in the box and the attributes describing the content of the entity below. Similarly, rounded rectangles represent relationships. Keys attributes are both bold and under-lined while required attributes (at modeling time) are highlighted in bold. A cross in the circle highlights exclusions constraints between relation-ships.
