Lehrgebiet Informationssysteme

The CONCORD processing model captures design dynamics by taking each of the above mentioned activity control aspects (cooperation, design flow, transactions) into account. In order to provide an encompassing activity support, CONCORD emphasizes both, the exploitation and adaptation of well-known concepts from the areas of cooperation support, work flow management and transaction processing (horizontal aspect), and the integration and interplay of these components within the activity management framework (vertical aspect). Therefore, CONCORD distinguishes three different levels of activity management.

At the highest level of abstraction (Administration/Cooperation Level, AC Level), we reflect the more creative and administrative part of design work. There, the focus is on the description and delegation of design tasks as well as on a controlled cooperation among the design tasks. The key concept at this level is the design activity (DA). A DA is the operational unit representing a particular design task or subtask. During the design process, a DA hierarchy can be dynamically constructed resembling (a hierarchy of) concurrently active tasks. All relationships between DAs essential for cooperation are explicitly modelled, thus capturing task-splitting (cooperation relationship type delegation), exchange of design data (cooperation relationship type usage), and negotiation of design goals (cooperation relationship type nego- tiation). The inherent integrity constraints and semantics of these cooperation relationships are enforced by a central system component, called cooperation manager.

Looking inside a DA reveals the DC level (Design Control Level). There, the organization of the particular actions to be performed in order to fulfill a certain (partial) design task is the subject of consideration (design flow). At this level, the execution plan (state/transition graph) of a particular design activity is of major interest. It models the control/data flow among several design actions performed within a DA. Usually, these actions are design tool applications. The operational unit serving for the execution of a design tool is the design operation (DOP). In order to control the actions within the scope of a single DA, but without restricting the designers' creativity, flexible mechanisms for specifying the design flow for a DA are provided. The correctness of tool invocations is guaranteed by a system component, called design manager. The design manager does also provide for recoverable design-flow executions that is needed for level-specific and isolated failure handling. Design tools are applied to improve existing design states in order to finally reach at a design state that completes the current (partial) design task. Design (object) states are captured by means of the Object and Version Data Model (OVDM, see above). The derivation of versions by means of tool applications is supported by the concepts provided at the TE level.

From the viewpoint of the DBMS or data repository, a DOP is a long transaction. A DOP has the properties of conventional transactions. Because of long duration, it is internally structured by save/restore and suspend/resume facilities to be able to rollback the design at the application level and to continue the design work after breaks. A DOP processes design object versions in three steps. First, the input versions are checked out from the integrated data repository, and cached in an object buffer at the workstation for efficiency reasons. Second, the design data is mapped to in-memory storage structures tailored to the application needs. It is processed by one or more design tools. Third, the finally derived new versions are propagated back to the data repository (check-in operation). The derivation of schema-consistent and persistent design object versions is guaranteed, again, by a central system component, called transaction manager. It is also responsible for the isolated execution of DOPs and for recoverable DOP executions that are, again, necessary for a level-specific and isolated failure handling. The transaction manager employs mechanisms provided by the advanced DBMS which manages the integrated data repository. Since long transactions are involved, incompatible lock requests on data already locked for an expectable long duration cannot be handled by usual wait mechanisms, but require a notification concept.

The three mentioned abstractional layers are provided on top of a design data repository. We are currently realizing a CONCORD prototype consisting of the collaborating activity management components mentioned above and exploiting the VStore system as data repository.