A generalized multi-view approach
Lecture Notes in Computer Science
It is advocated here that integrating abstraction and modularity into the concept of point of view, and extending the view concept to the process itself (and not only to data used by processes), provides an uniform conceptual framework for aspects like agent point of view, quality models and process monitoring.. No multi-view formalism meet these requirements. In Tempo , views are applied in the product only, in  views are not enactable, in MVPL , they do not share process instances.
... nce views can overlap, there is a risk that different views may define the same activity inconsistently. Since views are enactable, the same activity can be carried out twice. It is not easy to ensure consistency between the different views [3, 4]. The following requirements are particularly important: • Process overlap should be detected. • It should not be possible to duplicate activities, • It should not be possible to define the same process in an inconsistent way. An example of our approach is the following. Let there be a validation process (valid), and a quality assurance (QA) process. The former executes the technical validation activities; the later sees a part of these technical activities and also records, for measure and traceability purposes, some selected events, computes some values and displays the corresponding results. The real validation process is the union of these two processes. Each process sees only a sub-set of the activities and artifacts: libraries, the debugger and object codes are seen only by the validator; effort drawing, resource allocation reports and history records are visible only to the QA process). No formalism has currently achieved a consensus, and different Process Engines (PEs) are available, each of which focuses on a given aspect of software process modelling and support. In the architecture we propose, views are modelled "independently" (see "The Méta-Process." on page 3) but all views are compiled together to produce the "real process model" in the Internal Formalisms. These internal formalisms are interpreted by different Process Engines which create and maintain different execution contexts for the internal enacting processes. For each defined view, the PSE is in charge of maintaining the corresponding monitoring and interaction interface, based on the view model and the different execution contexts. Process Interface Our approach is based on the fact that each process fragment has an interface. The concept of interface is borrowed from programming languages. A process interface is the visible part of a process; it defines the process functionalities both in an abstract non executable way and in a formal way; and the consumed and produced artifacts. The private part contains the implementation. It describes the sub-processes needed, how sub-processes are composed (their ordering.) and coordinated, and how they cooperate. Compiler, analyser, .. PE1 PE2 PEn PSE PSE Valid QA QA Internal Formalisms Viewn Valid Process Engines Interaction Manager Modelling Support Execution. Contexts Execution Support View Models Enacted Views Collaboration (object synchronization) is supported by the Adele Work Space Manager , while cooperation is supported by Work Context . The Méta-Process. Our méta-process follows the following steps. Model Building A model can be built from existing process fragments (their interface). The goal here is essentially to reuse existing fragments. The concepts of interface and process dependency allows technology developed for Software Configuration Management to be reused: automatic computation of process configuration which ensures the corresponding model will be complete and consistent and that reuse of existing process fragments is maximized. Defining Views on a Process. Once the model has been built, it is worth defining the view(s) needed on this (real) process. At this point in time, the model is indeed a complete model. The agent(s) which will use that process may not need to see the complete process, but only an executable abstraction of it i.e. an operational view. A view is a new process interface built starting from the real process interface, and hiding part of the interface. Some parts are renamed; other composed, i.e. a connex sub part of the process can be abstracted as a single entity, under a single name.