The realisation of the ViewPoints concept is developed as a prototype tool called the Viewer (Nuseibeh, 1994). In the Viewer, a problem is composed of a set of ViewPoints. A ViewPoint merely is a self-contained partial specification of the problem.

The Viewer supports two phases of system development - the first phase is Method Design, the second phase is Method Use. Method Design is to specify a method in terms of ViewPoint templates. A ViewPoint template elaborates development techniques, i.e. representation styles and work plans, for a method fragment or a method. Method Use is to instantiate ViewPoint templates to construct a specification.

Figure 2 illustrates the architecture of VOSE in the Viewer. A method is described as a collection of ViewPoint templates, while a specification is described as a collection of ViewPoints. Symbolic links between a method and a specification represent the instantiation of method templates to construct ViewPoint specifications. Thus a ViewPoint is an instance of a ViewPoint template. According to the ViewPoint structure illustrated in Figure 1, the style slot and the work plan slot are instantiated in Method Design whereas the domain slot, the specification slot and the work record slot are instantiated in Method Use.

Representation styles of ViewPoints can be highly heterogeneous. Thus constructing a consistency checking procedure for the ViewPoints is not a simple task. One of possible ways to make the ViewPoints understand each other is to employ a number of translation rules. As shown in Figure 3, n different ViewPoint representation styles would require a significant number, n(n-1), of translation rules. Another possible solution is to provide a canonical form of those representation styles. This can reduce the number of translation rules required, but it is difficult to identify a single canonical form which can express all possible representation styles. A number of approaches have been proposed to tackle the difficulties found in integrating multi-views (Meyers, 1991; Delugach, 1992a; Delugach, 1992b). Each of them offers different benefits but there is no consensus about which is the most useful.

We propose an alternative solution to construct a consistency checking procedure in a ViewPoints-based framework. We have built the Viewer+CG which is the modified version of the Viewer to support the use of CGs for ViewPoint consistency checking. We have augmented the Viewer+CG with CGs as two 'dimensions'. Firstly, we employ CGs as a meta-representation language to describe representation styles and consistency checking rules of ViewPoints (c.f. section 4). Secondly, we construct a consistency checking procedure based on the resulting meta-representation and rules (c.f. section 5).

3. THE SCENARIO

We present a scenario to demonstrate the application of CGs in the Viewer+CG environment. Our scenario demonstrates the construction of a ViewPoint template, namely Structure and Component Identification, and the development of a specification based on the template. The template describes the process and the representation styles of a design step in the Constructive Design Approach (Kramer, et al., 1990). The CDA was launched as a design technique for distributed systems exploiting the CONIC (Magee, et al., 1989) facilities for distributed programming. The CDA emphasises design mechanism for decomposing a system into a set of components. The principle of the CDA is that a structure of potential distributed components of a specification should be maintained throughout analysis and design process, thereby enhancing reconfiguration for the specification.

The Structure and Component Identification step is to identify processing components and their decomposition to produce a structural description of a distributed application. Data flows are also identified to provide the details of the structure. By applying this development step in a ViewPoints-based framework, the structure of each component can be constructed separately and jointly managed. This enables separation of concerns, thereby reducing complexity in the specification construction of the application. The scenario will show how the specification of each distributed component can be safely and independently developed through the use of a consistency checking procedure in our tool, the Viewer+CG. In subsequent sections, we will present a series of windows which are the results of developing the scenario in the tool.

4. CGs AS META-REPRESENTATION LANGUAGE FOR VIEWPOINTS

In this section, we demonstrate the use of CGs as a meta-representation language to describe the representation style and the work plans of the Structure and Component Identification template in the scenario. The process of constructing a ViewPoint template consists of two main steps. First step is to describe the representation style of the template. Second step is to specify the work plans of the template. These steps are performed in Method Design of the Viewer+CG.

4.1 Expressing Representation Styles

A ViewPoint representation style consists of a set of style components, each of which expresses description, and a graphical component of the style. To express a representation style of a ViewPoint, we firstly employ CGs as a language to constitute concepts and relations in the style. Secondly, we use the identified concepts and relations to construct meta-representation binding of the style components. This meta-representation binding forms the basis, i.e. a set of CGs, for constructing work plan definition of the ViewPoint. The construction of work plan definition will be explained in section 4.2.

4.1.1 Component Styles

4.1.1.1 Built-in Concept and Relation Type Hierarchies

To express meta-representation of ViewPoints in the Viewer+CG, we define built-in concept type and relation type hierarchies as in Figure 4 and Figure 5 respectively. Built-in concept type hierarchy represents the structure of concept types for style components in ViewPoint templates. Built-in relation type hierarchy represents the structure of relation types for the defined concept types. Double angle-brackets depict abstract types in the hierarchies. Abstract types classify related groups of concept and relation types in the hierarchies. They are not tangible types that can be used to construct meta-representation of ViewPoint representation styles.

Built-in concept types are divided into attribute concept types and style concept types. Attribute concept types represent attributes of style components. Style concept types represent style components. Each group of the types is further divided into basic structure types and user-defined types. Basic structure concept types are ad hoc concept types for constructing ViewPoint-based environment architecture. User-defined concept types are concept types which are added in the process of method construction by method designers. Basic structure style concept types consist of viewpoint concept type. Basic structure attribute concept types are name, domain, and method concept types. These attributes are initially defined for viewpoint concept type, but they can also be used for user-defined component styles.

Built-in relation types are also divided into basic structure relation types and user-defined relation types. Similar to basic structure concept types, basic structure relation types are for the environment construction. An attribute relation describes the relation between a style concept type and an attribute concept type. Examples of attribute relations will be illustrated in the next section. A hold relation describes ViewPoint ownership. For instance, a ViewPoint may hold a collection of components in its specification. The hold relation is also used to describe the ownership of a ViewPoint and its consistency checking rules. Examples of hold relations for the rules will be illustrated in Figure 18.

As defined in (Sowa, 1984), a concept of CGs can be either generic or instantiated. A generic concept is a concept without referents. An instantiated concept represents an individual concept of a particular type. For instance, [component] refers to a generic concept type component. [component: a] refers to an instance of concept type component that is identified by a referent a. A referent can be either an identifier or a variable. This definition will be applied throughout CGs dialogs in this work.

4.1.1.2 Component Styles and their Attributes

A component style is described in terms of its graphical notations and its attributes. The meta-representation language in the Viewer+CG captures a component style and an attribute of the style into a style concept type and an attribute concept type respectively. Figure 6 shows the component styles of the Structure and Component Identification template. The template expresses two types of component styles, component and dataflow.

A relation between a style concept type and its attribute concept type is expressed as the following general form of a CG.

In the Structure and Component Identification template, a component is identified by its name, status and description. A component status can be either primitive or non-primitive. A non-primitive component can be decomposed into subcomponents whereas a primitive component cannot be decomposed further. A dataflow is identified by its name. The pop-up menu in Figure 6 shows an attribute list of a style concept type, named component. Figure 7 illustrates the CGs representing relations between style concept types and attribute concept types in the Structure and Component Identification template. 

In the following, we employ the identified concept types to construct meta-representation binding of the Structure and Component Identification template.

4.1.2 Meta-Representation Binding

Meta-representation binding of a ViewPoint representation style is expressed as a collection of CGs. The graphs specify relationships among style components.

Figure 8 depicts the meta-representation binding of the Structure and Component Identification template. The window for Meta-Representation Binding consists of three parts. The left part displays the subjects, i.e. component styles, of the binding. The middle part displays the relevant relations of the subjects. The right part displays the relevant objects, i.e. component styles, of the relations. A binding clause is read horizontally. For instance, the highlighted meta-presentation binding clause in the figure illustrates a binding between a dataflow concept type and a component concept type by a relation type named from. The clause specifies that a dataflow can be sent from a component.

Generally, a binding clause is defined as a conceptual relation from a style component to another style component. The clause is written as the following general form of a CG.

Each binding clause is constructed by using the dialog illustrated in Figure 9. The pop-up menu in the figure shows a list of concept types which can be used to construct meta-representation binding of the Structure and Component Identification template. These concept types are identified by the steps in previous section.

Figure 10 depicts the CGs which represent the meta-representation binding of the Structure and Component Identification template. A relation from between a component concept type and a dataflow concept type represents the dataflow sending from the component. A relation to between a component concept type and a dataflow concept type represents the dataflow sending to the component. A relation decomposition between a component concept type and a viewpoint concept type represents the ViewPoint as a decomposition of the component.

Figure 11 depicts the complete CGs of the representation style of the Structure and Component Identification template. The graphs when instantiated produce an abstract view, i.e. an instance of meta-representation, of a ViewPoint specification using the template.

In the following, we use the resulting CGs from the meta-representation binding of the Structure and Component Identification template to establish assembly actions and consistency checking rules of the template.

4.2 Expressing Work Plans

ViewPoint work plans describe process knowledge, i.e. a series of actions and rules that are required for the construction of ViewPoint specifications. Here CGs are employed in two aspects. Firstly, we interpret an assembly action as a sequence of CGs operations. The operations are employed to implicitly transform a ViewPoint specification into CGs through the construction of the specification in Method Use (c.f. section 5.1). Secondly, we establish consistency checking rules of ViewPoints by using CGs.

4.2.1 Assembly Actions

An assembly action is interpreted as a sequence of graph operations. The sequence provides guidance to method designers to implement the action accordingly.

We specify the following types of graph operations to constitute assembly actions.
(1) Add operation is to add a CG.
(2) Delete operation is to delete a CG.
(3) Retrieve operation is to perform a query on a CG.
(4) Update operation is to retrieve a CG, and save the changes which might be made.

Figure 12 illustrates a ViewPoint template for assembly actions of the Structure and Component Identification step. The left part of the Meta-Representation of Actions/Rules window displays a list of the actions. The middle part of the window displays a list of graph operations for a selected action. From the figure, an action Add Component is interpreted as a sequence of graph operations for adding a component concept, and the attribute concepts of the component concept.

4.2.2 Consistency Checking Rules

As a result of expressing representation styles as CGs, we are able to establish consistency checking rules using the graphs. We define a general form of the rules as follows.

where Conditions and Assertions are conjunctions of CGs. The Assertions must be hold if the Conditions are hold.

In this scenario, we specify two consistency checking rules for the development of a specification using the Structure and Component Identification template. Firstly, we specify the Invalid Component Status rule which enforces that only components with non-primitive status can be decomposed. Secondly, we specify the Input Decomposition Checking rule to verify the consistency of input flows between a component and its decomposition. The first rule is defined as an in-ViewPoint rule as it requires only information within the ViewPoint in which the rule is invoked. The second rule is defined as an inter-ViewPoint rule as the rule requires information across ViewPoints. The following sections elaborate how the rules are constructed.

4.2.2.1 In-ViewPoint Rules

Consider the definition of the Invalid Component Status rule. The rule states that for any component which has a decomposition, the status of that component should be specified as Non-Primitive.

Figure 14 depicts a dialog representing the definition of the Invalid Component Status rule. The assertion clause in the figure is constructed by using the dialog in Figure 13.

To compose an in-ViewPoint checking rule, a method designer is required to define three types of CGs clauses. The first type represents the conditions of the rule. The second type represents the assertions of the rule. The third type defines output graphs of the rule. Output graphs illustrate missing assertions that we want to identify as a result of consistency checking procedure. A possible set of output graphs is therefore derived from assertion clauses. The use of output graphs will be illustrated in section 5.2.

Figure 15 illustrates a ViewPoint template for in-ViewPoint checking rules. The left part of the Meta-Representation Actions/Rules window displays a list of in-ViewPoint rule names. The middle part of the window displays assertion clauses of a selected rule. The right part of the window displays condition clauses of the rule. In this example, the Graph View of the selected rule, i.e. the Invalid Component Status rule, will be expanded to Figure 16. Figure 16 depicts CGs representing the rule. The top part of the window in the figure illustrates CGs of the rule's assertions, while the bottom part of the window shows CGs of the rule's conditions.

4.2.2.2 Inter-ViewPoint Rules

Consider the definition of the Input Decomposition Checking rule. The rule states that if a component has a decomposition ViewPoint, the inputs of the component must be delegated to the ViewPoint. This rule ensures a consistent parent-child relation between the component and its decomposition. Relations between ViewPoints are established from the ViewPoint specifications which hold assertions and conditions of the rule.

The process of composing an inter-ViewPoint rule is similar to that of an in-ViewPoint rule. Figure 17 depicts the dialog for constructing the definition of the Input Decomposition Checking rule. Figure 18 illustrates CGs of the rule.

In the next section, we will illustrate how to use the CGs definition of representation styles and work plans to automate the process of consistency checking in ViewPoints.

5. CONSISTENCY CHECKING PROCEDURE

In this section, we employ the template definition of the Structure and Component Identification step (c.f. section 4) to construct two ViewPoints representing the main system and its decomposition of a distributed application. Then we perform consistency checking between the ViewPoints. This part of the scenario is carried out in Method Use of the Viewer+CG. We do not intend to provide details of Method Use functions here. Readers should refer to (Nuseibeh, 1994) for further explanation of Method Use.

5.1 Transformation of ViewPoints Specification to CGs

Figure 19 illustrates a ViewPoint VP1 representing main processing of a distributed application. In this scenario, the application contains two main processing components, a and b. The data flows, named in and out, ab, in the figure represent the interaction between the components and external entities and the interaction among the components themselves.

To construct the specification of VP1, we perform the following steps.

Figure 22 depicts the complete transformation of the ViewPoint specification in Figure 19, including the attribute declaration of style components, to CGs.

We further develop the ViewPoint VP2 which is the decomposition of the component b. The component b is decomposed into two components, namely c and d. The dataflows for the decomposition are illustrated as in Figure 23.

Figure 24 illustrates the transformation of the specification of VP2 into CGs.

In a multiperspective development environment, the ViewPoints VP1 and VP2 may be independently constructed by two different developers. As a consequence, the relations between the ViewPoints need to be verified by performing consistency checking between the ViewPoints.

5.2 Reasoning

To ensure consistency of the specification that we have built in section 5.1, we perform consistency checking according to the rules defined in section 4.2.2. Firstly, we invoke in-ViewPoint checking at the ViewPoint VP1. Then we invoke inter-ViewPoint checking to validate the relations between VP1 and VP2.

In-ViewPoint checking process performs the logical reasoning between selected rules and the CGs of the ViewPoint specification in which the check is invoked. Figure 25 illustrates the result of in-ViewPoint Checking on VP1. The checking process performs the logical reasoning between the CGs of VP1 (c.f. Figure 22) and the CGs representing the Invalid Component Status rule (c.f. Figure 16). The result in Figure 25 shows that the status attribute of component b is invalid. Component b was decomposed into ViewPoint VP2, therefore, the status of the component should be non-primitive. The top right part of the window in the figure shows a possible inconsistency handling action by means of CGs for this rule. As described earlier, the inconsistency action is instantiated from output graphs of the rule. The graphs can be transformed into ViewPoint actions. The transformation, however, is out of the scope of this work

Next, consider that we perform inter-ViewPoint checking, in particular Input Decomposition Checking rule, at VP1. The process of inter-ViewPoint checking is similar to that of in-ViewPoint checking, but it performs the checking on two or more ViewPoint specifications. The number of the specifications depends on the instantiation of ViewPoint relations according to the inter-ViewPoint rules during the execution of the check.

To perform the Input Decomposition Checking rule, the consistency checking procedure firstly inputs the CGs of VP1 and VP2 (c.f. Figure 22 and Figure 24, respectively) as its assertions. Then it performs logical reasoning on the assertions and the CGs of the Input Decomposition Checking rule (c.f. Figure 18).

Figure 26 shows the result of the inter-ViewPoint checking on VP1. In this scenario, the input ab is missing from VP2. Therefore, there is an error of input decomposition checking between VP1 and VP2. As seen in the figure, the resulting output graphs of this check imply that dataflow ab should be defined as an input to a component in the ViewPoint VP2. Thus an inconsistency handling action can be carried out by adding a dataflow ab to one of the components in VP2.

6. SUMMARY AND DISCUSSION

In this paper, we have presented a way of conducting a consistency checking procedure in a ViewPoints-based framework. We avoid the use of a single exhaustive canonical form to translate the entire semantic sets of various representational styles. Instead, we provide an abstract way to capture semantic compatibility among ViewPoints by using CGs as a meta-representation language. The CGs are employed for the following tasks:

(1) To visualise concepts and relations that are expressed by a method or a method fragment.
(2) To establish meta-representation binding of the concepts and the relations.
(3) To interpret an assembly action as a sequence of CGs operations. The operations are employed to implicitly transformed a ViewPoint specification into CGs.
(4) To establish in-ViewPoint rules and inter-ViewPoint rules of ViewPoints by using the resulting concepts and relations in (1).
(5) To perform logical reasoning on CGs transformation of ViewPoints specifications and the rules.
 
Consistency checking and integration of multiple views have been tackled by a number of researchers. The work of (Meyers, 1993) applied Semantic Program Graphs (SPGs) for representing software systems in a multiple-viewed development environment. However, the work is concerned with multiple views of program development techniques rather than those of analysis and design of specifications. Compared with CGs, the notion of SPGs is less appropriate to be used as a meta-representation language. Some SPGs notations, such as ones for scopes, name binding, and looping structure, are not encountered in the stages of the development process in a ViewPoints-based framework.

Although descriptive and logic-based consistency checking rules for ViewPoints have been proposed (Nuseibeh et al., 1993; Finkelstein, et al., 1994; Hunter, and Nuseibeh 1995), there is yet to be a generalized procedural mechanism to do so. CGs can be used as a bridge between the logic-based rules and the descriptive rules. The graphs provide intuitive notations to describe consistency checking rules and expressive power to transform the rules for logical reasoning.

The work of (Delugach, 1992a; Delugach, 1992b) presented the abilities of CGs to translate various representation styles of ViewPoints. However, it can be exhaustive to implement a number of translation rules using a canonical form as such for the ViewPoints. Alternatively, we employ CGs as a meta-representation language to describe ViewPoints. The resulting ViewPoint meta-representation forms a basis to establish consistency checking rules for different ViewPoint representation style. By doing so, we can resolve many of the difficulties found in using canonical forms and translation rules. The use of meta-representation enables method designers to establish semantic compatibility among different ViewPoint representation styles without implementing the translation rules of the styles.

By abstracting a ViewPoint specification up one level to CGs, we are able to augment the ViewPoints-based framework with an automated consistency checking procedure which is independent of ViewPoint representation styles. In addition, CGs provide an efficient foundation for communication between ViewPoints in a distributed environment as they can be served as a knowledge interchange format. An ongoing research of this work is to employ the Viewer+CG to further construct a configuration-oriented development methodology. The methodology is the synthesis of Constructive Design Approach (Kramer et al., 1990) and object-oriented UML-based notations (Booch, et al., 1997). Together with the consistency checking procedure in the Viewer+CG that we have presented, the methodology enables a team of software developers to safely and expediently decompose a distributed application, the analysis and design tasks for the application into different ViewPoints of configurable distributed components. By making the development process of a distributed application itself distributed, this resolves the difficulties, expenses and time involved in analysis and design process of the application.

6. REFERENCES

Booch, G., Jacobson, I., and Rumbaugh, J. (1997). The Unified Modeling Language for Object-Oriented Development, Rational Software Cooperation, September, Documentation Set Version 1.1.

Delugach, H. S. (1992a). Analysing Multiple Views of Software Requirements, in T. E. Nagle, J. A. Nagle, L. L. Gerholz, and P. W. Eklund (Eds), Conceptual Structures: Current Research and Practice, Ellis Horwood.

Delugach, H. S. (1992b). Specifying Multiple-Viewed Software Requirements with Conceptual Graphs, Journal of System Software, Vol. 19, pp. 207-224.

Finkelstein, A., Kramer, J., Nuseibeh B., Finkelstein, L., and Goedicke, M. (1992). Viewpoints: A Framework for Integrating Multiple Perspectives in System Development, International Journal of Software Engineering and Knowledge Engineering, Vol. 2(1), World Scientific Publishing Co., March, pp. 31-58.

Finkelstein, A., Gabbay, D., Hunter, A., Kramer, J., and Nuseibeh, B. (1994). Inconsistency Handling in Multi-Perspective Specifications, IEEE Transactions on Software Engineering, Vol. 20(8), December, pp. 569-578.

Hunter, A., and Nuseibeh, B. (1995). Managing Inconsistent Specifications: Reasoning, Analysis and Action, Technical Report Number 95/15, Department of Computing, Imperial College, London, UK, October.

Kramer, J., Magee J., and Finkelstein, A. (1990). A Constructive Approach to the Design of Distributed Systems, Proceedings of the 10th IEEE ICDCS, Paris, May.

Leite, J. C. S. P. (1989). Viewpoint analysis: A Case Study, Proceedings of 5th International Workshop on Software Specification and Design, ACM SIGSOFT, Vol. 14, Pittsburgh, Pennsylvania, USA, May 19-20, pp. 111-119.

Magee, J., Kramer, J., and Sloman, M. (1989). Constructing Distributed Systems in CONIC, IEEE TSE 15, June 6.

Meyers, S. D. (1991). Difficulties in Integrating Multiview Development Systems, IEEE Software, January, pp. 49-57.

Meyers, S. D. (1993). Representing Software Systems in Multiple-View Development Environments, PhD. Thesis, Department of Computer Science, Brown University, May.

Mullery, G. (1979). CORE - a method for controlled requirements expressions, Proceedings of the 4th International Conference on Software Engineering (ICSE-4), IEEE Computer Society Press, pp. 126-135.

Nuseibeh, B., Kramer, J., and Finkelstein, A. (1993). Expressing the Relationships Between Multiple Views in Requirements Specification, Proceedings of the 15th International Conference on Software Engineering, IEEE CS Press, Baltimore, USA, May.

Nuseibeh, B. (1994). A Multi-Perspective Framework for Method Integration, PhD. Thesis, Department of Computing, Imperial College, University of London.

Sowa, J. F. (1984). Conceptual Structures: Information Processing in Mind and Machine, Addison-Wesley, Reading, MA.