Published on Nov 30, 2023
This paper demonstrates an application of Conceptual Graphs (CGs) in the area of software engineering. We employ CGs as a meta-representation language to enhance consistency checking within a multiperspective development environment, i.e. one which employs and utilises a number of ViewPoints. We have built a ViewPoint-based prototype called the √iewer+CG to show such application of CGs.
A ViewPoint is a loosely coupled, locally managed, self-contained object. It encapsulates representation knowledge, development knowledge, and specification knowledge of a problem domain. ViewPoints constitute partial specifications which can be independently constructed by a group of developers. Thus a complex and large-scale application can be decomposed into, and jointly managed as, a collection of ViewPoints.
Partitioning development tasks and specifications in this manner necessitates a consistency checking procedure to ensure that the ViewPoints can consistently work as an 'integrated' whole. The difficulties in constructing such procedure arise from the diversity of ViewPoint representation styles. We employ CGs to provide meta-representation of ViewPoints.
As CGs form a strong basis for logical reasoning, we are able to use the resulting concepts and relations from the metarepresentation to establish consistency checking rules within and across ViewPoints. By abstracting a ViewPoint specification up one level to CGs, we are able to augment a ViewPointsbased environment with an automated consistency checking procedure which is independent of ViewPoint representation styles.
ViewPoints, or generally written as viewpoints, are used to represent a scope of knowledge or interests of a system. The definition of viewpoints was initially employed to formalise requirement acquisition and elicitation (Mullery, 1979; Leite, 1989). In requirement engineering, viewpoints are seen as, for example, functions, sources and sinks of dataflows.
The word ViewPoint distinguishes this particular notion from other multiperspective approaches. The ViewPoints concept (Finkelstein, et al., 1992) emphasises the partition of perspectives corresponding to actors or roles in a development process. This notion of ViewPoints does not constraint its use only for requirement analysis. It can also be applied to specification analysis and design by partitioning both development tasks and specifications into ViewPoints.
A ViewPoint contains three different types of knowledge, i.e. representation, development and specification knowledge.
The style slot, which specifies the notations or representation styles for a ViewPoint. The notations are instantiated to produce the specification of the ViewPoint.
(2) The work plan slot, which defines the following development actions.
(2.1) Assembly actions, which are basic editing actions to construct the specification
(2.2) Check actions, which are actions for consistency checking of the specification. Check actions are divided into in-ViewPoint and inter-ViewPoint actions. In-ViewPoint actions are for checking consistency within the ViewPoint in which the actions are invoked. Inter- ViewPoint actions are for checking consistency of relations among ViewPoints.
(2.3) Guide actions, which provide guidance to developers. The actions suggest what kinds of actions to do in the circumstances. For example, inconsistency handling actions provide guidance for possible corrections when inconsistency is encountered in a specification.
(3) The domain slot, which is the area of concern, i.e. the problem domain, that the ViewPoint describes.
(4) The specification slot, which is the actual partial specification of the ViewPoint.
(5) The work record slot, which contains the development history, rationale and current development stage of the specification.
The realisation of the ViewPoints concept is developed as a prototype tool called the √iewer (Nuseibeh, 1994). In the √iewer, a problem is composed of a set of ViewPoints. A ViewPoint merely is a self-contained partial specification of the problem.
