The terminological framework that I propose in the MASSIVE method is therefore based on so-called views. Views (sometimes also referred to as "viewpoints" or "viewports") establish to a terminological framework where each view is a representation of a different perspective onto the system. However, although all of these approaches share the same terminology, they still have different ideas of what is meant by a "view". Several different approaches to set-up generic view systems have been proposed. Balzert, for example, differentiates between four different views that a developer can have on the target system. As shown in the following figure, these four views are the Data view}, the Function view, the Dynamics view and the User Interface view. Although it is claimed that the above views can be applied to any application, I will later argue why I think that a more specific system of views that is oriented at the basic requirements of the problem class is more adequate.
Sommerville lists other possible interpretations of the term: a viewpoint is either a data source or sink within a system, a receiver of services, i.e. viewpoints are external to the system and receive system services or provide data for performing these services or it is a representation framework such as an Entity-Relationship model or a Finite-State Machine that describes a (sub-)set of the system properties.
Because of these difficulties, I have decided to approach the problem of decomposing the system into several views from the direction of the design process. During the development of the system design, the designer will soon discover that some design aspects are more closely related to one another then to other aspects. These "natural" collections of aspects seem to be characteristic for a particular class of applications and it therefore suggests itself that these empirical decompositions capture the nature of an application class quite well. For these reasons, my personal idea of a view is therefore to see a view as an collection of aspects that cross-cut functional boundaries as different representations.
Any software system is modeled in several external representations and that are manipulated by the software development process. Ideally, these different representations are semantically isomorphic and differ only in their external form although in practical situations it is a major problem to keep the different representations synchronized.
Adding, e.g. four, views to the different representations shown above, we get the following picture that shows how these views vertically cross the two representations of the target system. Views are thus a general concept of grouping things together under a common semantic concept
Ideally, the target system can be decomposed in several independent views with well defined interfaces. In MASSIVE, each view represents a set of conceptually linked aspects, a view is thus a projection of the design onto a particular subject. This interpretation is supported by results from programming experiments in cognitive psychology were it was found that different abstractions (views) are used for different sub-tasks of the software development process. A collection of views that achieves a logical decomposition of the target system is called a view system, the interfaces between the views are modeled as explicit connections.
View-oriented analysis is a two-step iterative process that is related to viewport analysis introduced elsewhere:
In the first step of a view-oriented analysis, the analyst will try to identify potential views. A technique that has shown to be quite effective for this task are simple brainstorming sessions were every aspect that comes to mind and that is related to the problem area should be written down. Customers and end users should participate in these sessions as far as possible because their input is very important for starting with the right thing. In the next phase of the view analysis, the aspects that have been identified during the brainstorming sessions are grouped together according to their conceptual distance. Obviously, this is a fuzzy process as there is no real measure that can be applied to decide how related two aspects are. Nevertheless, it is usually possible to allocate each aspect to a particular conceptual abstraction and these abstractions are then the views that separate the various aspects of the system. Aspects that cannot be allocated to a particular view or that could be allocated to several views at the same time are usually a sign for a missing view. Furthermore, aspects that have been overseen earlier may become obvious later. Therefore, the entire process is iterated until a stable state is reached. A general rule in the view-oriented analysis process is that the granularity of the resulting view system should neither be too coarse nor too fine.
In the previous paragraph, I have explained view-oriented analysis as it would be done for a particular problem under consideration. But this is only one aspect where view-oriented analysis can be applied successfully. As I have said above, it is often possible to find generic view systems for entire classes of applications and here, view-oriented analysis can be used as a tool to analyze such an application class in order to find a generic view system that covers most systems in that class. In the next section, I will present such a generic view system for multiagent systems that was found during the analysis of several multiagent applications.
As an example for the view-oriented analysis, consider the above figure where I have depicted an excerpt of the analysis map that lead to the generic view system for multiagent systems. According to the previously explained process model, this analysis map is the result of a brainstorming session for the view identification process. In the second step of the view-oriented analysis, the relevant aspects of the system under consideration are grouped together according to their semantic relation. In the above figure, for example, the terms role, role assignment, capabilities and responsibilities are closely interrelated and are thus grouped together under the overall concept of a role view onto the system. Another example is the interaction view that covers things such as protocol specifications, message types and message transport. These initial groupings are then extended in subsequent iterations of the process when new aspects are discovered either by adding to existing concepts or by introducing a new general concept.
The major point in developing a general purpose view system for multiagent systems is to take specific applications and to abstract away from domain specific aspects while preserving the generic ones. The careful analysis of various application that are discussed in this book has finally lead to the generic view system that I shall present in the next section.
Views are a general concept to arrange knowbbles with respect to a logical decomposition of the application class and I will now instantiate the general framework for the application class of multiagent systems. Before doing so, however, I will define some basic requirements that the resulting view system should comply to. First of all, the view system should help the designer to analyze the system with respect to the four fundamental questions: what, where, who and how? However, the focus of these questions is very broad and thus we need a more fine-grained conceptual framework that separates the aspects of the target system as far as possible and that covers all relevant aspects of the target system. As a starting point, we can use the following classification scheme for partial models:
Using the product models of the multiagent specific software develepment methods as guideline, we can derive the following requirements for a view system for multiagent systems.
Later, we can use this set of high level requirements to assess the MASSIVE view system.