\documentclass[10pt]{llncs}
\usepackage{epsfig}
\usepackage{rotating} % for sidewaystable
\usepackage{multirow}
\usepackage{amsmath}
\usepackage{amssymb}
\title{A Viewpoint-Based Framework for Discussing the Use of Multiple Modelling Representations}
\author{Nigel Stanger}
\institute{University of Otago, Department of Information Science, \\ PO Box 56, Dunedin, New Zealand \\ \email{nstanger@infoscience.otago.ac.nz}}
%================================================================================
% command definitions
% misc shorthand
\newcommand{\ER}{\mathit{E\textrm{-}R}}
\newcommand{\Martin}{\mathit{ERD_{Martin}}}
\newcommand{\Chen}{\mathit{ERD_{Chen}}}
\newcommand{\FD}{\mathit{FuncDep}}
\newcommand{\Smith}{\mathit{FDD_{Smith}}}
\newcommand{\RM}{\mathit{Relational}}
\newcommand{\SQL}{\mathit{SQL/92}}
% notation
% a representation, i.e., R(T,S); second form has a subscript as second argument
\newcommand{\Representation}[3]{\ensuremath{\mathfrak{#1}(#2,#3)}}
\newcommand{\RepresentationS}[4]{\ensuremath{\mathfrak{#1}_{#2}(#3,#4)}}
\newcommand{\Rep}[1]{\ensuremath{\mathfrak{#1}}}
\newcommand{\RepS}[2]{\ensuremath{\mathfrak{#1}_{#2}}}
% a description, i.e., D(V,T,S)
\newcommand{\Description}[4]{\ensuremath{#1(#2,#3,#4)}}
% a construct name
\newcommand{\domain}[1]{\textsc{#1}}
% elements D[e] and D[e:C]
\newcommand{\Element}[2]{\ensuremath{ #1 \left[ #2 \right] }}
\newcommand{\Elementt}[3]{\ensuremath{ #1 \left[ #2 : \domain{#3} \right] }}
% constructs R[C] and R[C:X]; lowercase ones don't have the calligraphic 'R' on front
\newcommand{\construct}[2]{\ensuremath{ #1 \left[ \domain{#2} \right] }}
\newcommand{\Construct}[2]{\ensuremath{ \mathfrak{#1} \left[ \domain{#2} \right] }}
% gigantic `}'s for use in tables
\newlength{\BIGlen}
\newcommand{\BIGL}[2][0cm]{
\setlength{\BIGlen}{#1} \divide\BIGlen by 2
$\left\}\text{ \rule[-\BIGlen]{0cm}{#1}#2}\right.$}
% table notes environment
\newcommand{\tabnote}[1]{\textrm{\textsuperscript{#1}}}
\newcounter{tnote}
\renewcommand{\thetnote}{\alph{tnote}}
\newenvironment{tabnotes}[1]%
{ \vspace{\baselineskip}
\begin{minipage}{0.95\columnwidth}
\textbf{#1}
\begin{list}{\thetnote}%
{ \setlength{\topsep}{0pt}
\setlength{\itemsep}{0pt}
\setlength{\parsep}{0pt}
\usecounter{tnote}
\renewcommand{\makelabel}[1]{\hfil{\textsuperscript{##1}}}
}
}%
{ \end{list}
\end{minipage}
}
%================================================================================
\begin{document}
\pagestyle{empty}
\maketitle
\begin{abstract}
When modelling a real-world phenomenon, it can often be useful to have multiple descriptions of the phenomenon, each expressed using a different modelling approach or \emph{representation}. Different representations such as entity-relationship modelling, data flow modelling and use case modelling allow analysts to describe different aspects of real-world phenomena, thus providing a more thorough understanding than if a single representation were used. Researchers working with multiple representations have approached the problem from different directions, resulting in a diverse and potentially confusing set of terminologies. In this paper is described a viewpoint-based framework for discussing the use of multiple modelling representations to describe real-world phenomena. This framework provides a consistent and integrated terminology for researchers working with multiple representations. An abstract notation is also defined for expressing concepts within the framework.
\end{abstract}
%================================================================================
\section{Introduction}
\label{Sec:Introduction}
In this paper is described a framework for discussing the use of multiple modelling approaches or \emph{representations} to describe a real-world phenomenon. This framework is derived from work on \emph{viewpoint-oriented design}, and provides a consistent and integrated terminology for researchers working with multiple modelling representations. An abstract notation for expressing various concepts within the framework is also defined.
There are several reasons for using multiple modelling representations to describe the same phenomenon, such the ability to provide a more complete description of the phenomenon in question, and because some representations are better suited to particular problems than others. Use of multiple representations and associated issues are discussed in Sect.~\ref{Sec:MultipleRepresentations}.
The framework described in this paper is primarily derived from earlier work in the area of viewpoint-oriented design methods. The basic concepts of viewpoint-oriented design methods are introduced in Sect.~\ref{Sec:Viewpoints}, and a lack of clarity is identified with respect to the definitions of some fundamental concepts (in particular, the meaning of the term `representation').
The author's framework arose out of research into translating models among different modelling representations. There was a need to clarify the definitions of various terms and also to integrate and simplify the potentially confusing range of pre-existing terminologies. The framework is discussed in Sect.~\ref{Sec:Framework}. In particular, the terms `representation', `technique' and `scheme' are clarified, and the new terms `description', `construct' and `element' are defined.
The author has also developed an abstract notation for expressing various framework concepts in a concise manner. This notation is defined in Sect.~\ref{Sec:Notation}, and the paper is concluded in Sect.~\ref{Sec:Conclusion}.
%================================================================================
\section{Using Multiple Representations to Describe a Phenomenon}
\label{Sec:MultipleRepresentations}
There are many different types of information to be considered when designing an information system, and a wide variety of modelling approaches and notations have been developed to capture these different types of information: entity-relationship diagrams (ERDs), data flow diagrams (DFDs), use case diagrams, the relational model, formal methods and so on. Problems can arise when useful information is omitted from a design. Consider an information system whose data structures are designed using entity-relationship diagrams and are implemented in a relational database. Data entry forms derived from these models are then built. Good design practices are followed throughout, yet the finished application is difficult to use. Some of the commonly used data entry forms have multiple states, but the transitions between these states are unclear to users because state information was not included in the system design.
While this is a purely theoretical example, it serves to illustrate an important point. Information systems are typically built to handle the data processing requirements of some real-world phenomenon. Such real-world phenomena may often be too complex to describe using a single modelling approach, or \emph{representation}. This is supported by the plethora of different representations in existence \cite{Hull:R:1987,Tsic:D:1982}, including those that model data structures (such as entity-relationship modelling), and those that model data movements (such as data flow diagrams). This implies that in order to completely model a phenomenon, multiple descriptions of the phenomenon are required, expressed using different representations.
Using multiple representations to describe a phenomenon is also important in other ways:
\begin{itemize}
\item if multiple developers are working on a project, each may prefer or be required to use a different representation to describe their particular part \cite{Atze:P:1996:EDBT};
\item particular subproblems may be better described using some representations than others \cite{East:SM:1991:PhD}; and
\item multiple representations are important when integrating heterogeneous data sources to form a federated or distributed system \cite{Atze:P:1996:EDBT}, as each data source may potentially use a different logical data model.
\end{itemize}
The idea of using multiple representations to model a phenomenon is not new. Grundy et al. examined the issues associated with building multi-view editing systems and integrated software development environments \cite{Grun:JC:1993:PhD,Grun:JC:1997:IJAST}. Their work was derived from earlier work on multi-view editing systems for software engineering \cite{Jaco:DA:1995:MultiView,Meye:S:1991:IEEE}.
Atzeni and Torlone \cite{Atze:P:1997:MDM} suggested the idea of translating between different representations as a means of facilitating the use of multiple representations. They proposed a formal model based on lattice theory that allowed them to express many different data modelling approaches using primitive constructs of a single underlying representation.
Su et al. \cite{Su:SYW:1993} used multiple representations to assist in integrating heterogeneous data sources to build federated and distributed databases. Their approach is similar in many respects to that taken by Atzeni and Torlone, except that the underlying representation is object-oriented rather than mathematically based.
The Unified Modeling Language \cite{OMG:1999:UML} also supports the use of multiple representations, and is oriented toward object-oriented modelling and development.
All of these approaches were developed independently of each other during the 1990's, and approached the use of multiple modelling representations from different starting points, resulting in a diverse and potentially confusing set of terminologies (see Table~\ref{Tab.MultipleRepresentations.Terminology}).
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% a few lengths to use in \multirow commands
\newlength{\wEG}
\newlength{\wFink}
\newlength{\wEast}
\newlength{\wDnS}
\newlength{\wAtze}
\newlength{\wSu}
\newlength{\wUML}
\newlength{\wGrun}
\newlength{\wA}
\begin{sidewaystable}[p]
\centering
\caption{Comparison of viewpoint/representation terminologies}
\label{Tab.MultipleRepresentations.Terminology}
\scriptsize
\settowidth{\wEG}{~relational model~}
\settowidth{\wFink}{\textbf{Finkelstei}}
\settowidth{\wEast}{\textbf{Easterbrook}}
\settowidth{\wDnS}{\textbf{Shanks [7]}}
\settowidth{\wAtze}{\textbf{Torlone [2]}}
\settowidth{\wA}{model}
\settowidth{\wSu}{\BIGL[2.8cm]{\parbox{\wA}{data model}}}
\settowidth{\wUML}{metaobject$^{b}$}
\settowidth{\wGrun}{component}
\medskip\hrule\smallskip
\begin{tabular}{cp{3.5cm}cccccccc}
& & & \multicolumn{7}{c}{\textbf{Corresponding term used by:}} \\
\cline{4-10}
\textbf{Term used} & & & \textbf{Finkelstein} & \textbf{Easterbrook} & \textbf{Darke \&} & \textbf{Atzeni \&} & \textbf{Su \emph{et al.}} & \textbf{UML} & \textbf{Grundy} \\
\textbf{by the author} & \textbf{Meaning} & \textbf{Example} & \textbf{\cite{Fink:ACW:1989}} & \textbf{\cite{East:SM:1991:PhD}} & \textbf{Shanks \cite{Dark:P:1995}} & \textbf{Torlone \cite{Atze:P:1997:MDM}} & \textbf{\cite{Su:SYW:1992}} & \textbf{\cite{OMG:1999:UML}} & \textbf{\emph{et al.} \cite{Grun:JC:1997:IJAST}} \\
\\
perspective & A description of a real-world pheno\-menon that has internal consistency and an identifiable focus. & -- & -- & perspective & perspective & -- & -- & -- & -- \\
\\
viewpoint & The formatted description of a perspective. & -- & ViewPoint & viewpoint & viewpoint & -- & -- & (use case)\tabnote{\ref{TermB}} & -- \\
\\
technique & A collection of abstract constructs that form a modelling `method'. & ~relational model~ & \multirow{10}{\wFink}{\BIGL[2.8cm]{style}} & \multirow{10}{\wEast}{\BIGL[2.8cm]{style}} & technique & \multirow{10}{\wAtze}{\BIGL[2.8cm]{model}} & \multirow{10}{\wSu}{\BIGL[2.8cm]{\parbox{\wA}{data model}}} & \multirow{10}{\wUML}{\BIGL[2.8cm]{\parbox{\wA}{meta\-model}}} & -- \\
\\
scheme & A collection of concrete constructs that form a modelling `notation'. & SQL/92 & & & scheme & & & & -- \\
\\
representation & The combination of a particular technique and scheme. & \parbox[t]{\wEG}{\centering relational model +~SQL/92} & & & \parbox[t]{\wDnS}{\centering represen\-tation} & & & & \parbox[t]{\wGrun}{\centering represen\-tation} \\
\\
description & An instantiation of a representation. & SQL/92 schema & \parbox[t]{\wFink}{\centering specifi\-cation} & description & -- & scheme & schema & model & view \\
\\
construct & The basic unit of a representation. & a relation & -- & -- & -- & construct & class\tabnote{\ref{TermD}} & metaobject\tabnote{\ref{TermD}} & -- \\
\\
element & An instantiation of a construct within a particular description. & \textsf{Staff} table & -- & -- & -- & (varies)\tabnote{\ref{TermA}} & object & object & component \\
\end{tabular}
\begin{tabnotes}{Notes on Table~\ref{Tab.MultipleRepresentations.Terminology}:}
\item\label{TermB} This could be interpreted in one of three ways: first, a single use case could represent the complete viewpoint of a stakeholder with respect to a particular role; second, the complete viewpoint of a stakeholder could comprise the union of all their associated use cases; or third, a use case could merely be another representation used \emph{within} a viewpoint.
\item\label{TermD} Also `construct'.
\item\label{TermA} Terms used include `component', `element' and `concept'.
\item[] `--' indicates that a term is not used by that author.
\end{tabnotes}
\smallskip\hrule
\end{sidewaystable}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
In addition, viewpoint researchers first suggested using multiple representations to describe viewpoints over a decade ago \cite{Fink:ACW:1989}. A viewpoint is effectively a formalisation of the perceptions of stakeholders with respect to some real-world phenomenon. Since we are dealing with the use of multiple representations to describe real-world phenomena, viewpoints provide a useful framework within which to discuss such use \cite{Stan:N:1997:ECIS97}. The author's framework will be described in Sect.~\ref{Sec:Framework}, but first basic viewpoint concepts must be defined.
%================================================================================
\section{Viewpoint Concepts}
\label{Sec:Viewpoints}
A \emph{viewpoint} can be thought of as a formalisation of the perceptions of a stakeholder group with respect to some real-world phenomenon that is being modelled. The first viewpoint-oriented approach was introduced in 1979 \cite{Mull:G:1979}, but the concept of a viewpoint was not formalised until ten years later \cite{Fink:ACW:1989}.
Viewpoint-oriented methods were originally developed to assist with requirements definition in a software engineering environment \cite{Mull:G:1979}, and subsequent research has followed a similar direction \cite{East:SM:1991:PhD,Koto:G:1996,Nuse:B:1994}. The focus of the author's research has been on how to facilitate the use of multiple representations to describe a single viewpoint, in particular by performing translations among descriptions expressed using different representations \cite{Stan:N:1999:PhD,Stan:N:2000:dp2000-11,Stan:N:1997:ECIS97}.
In Fig.~\ref{Fig.Background.Terminology} are shown the relationships between the concepts of view\-point-oriented methods. This initial framework was derived by the author \cite{Stan:N:1997:ECIS97} from the work of Finkelstein et al. \cite{Fink:ACW:1989}, Easterbrook \cite{East:SM:1991:PhD} and Darke and Shanks \cite{Dark:P:1995}. Their terminologies are also summarised in Table~\ref{Tab.MultipleRepresentations.Terminology}.
%%%%%%%%%%%%%%%%%%%%
\begin{figure}[htb]
\centering
\epsfig{file=BaseFramework.eps,width=\columnwidth}
\caption{Relationship between perspectives, viewpoints and representations}
\label{Fig.Background.Terminology}
\end{figure}
%%%%%%%%%%%%%%%%%%%%
%================================================================================
\subsection{Perspectives and Viewpoints}
\label{Sec:Background:Viewpoints:Perspectives}
Easterbrook \cite{East:SM:1991:PhD} defines a \emph{perspective} as ``a description of an area of knowledge which has internal consistency and an identifiable focus of attention''. During the requirements definition phase of systems analysis, developers may encounter many different perspectives on the problem being modelled. Perspectives may overlap and/or conflict with each other in various ways.
Finkelstein et al. \cite{Fink:ACW:1989} describe a \emph{viewpoint} as comprising the following parts:
\begin{itemize}
\item ``a \emph{style}, the representation scheme in which the ViewPoint [\emph{sic}] expresses what it can see (examples of styles are data flow analysis, entity-relationship-attribute modelling, Petri nets, equational logic, and so on);
\item a \emph{domain} defines which part of the `world' delineated in the style (given that the style defines a structured representation) can be seen by the ViewPoint (for example, a lift-control system would include domains such as user, lift and controller);
\item a \emph{specification}, the statements expressed in the ViewPoint's style describing particular domains;
\item a \emph{work plan}, how and in what circumstances the contents of the specification can be changed; [and]
\item a \emph{work record}, an account of the current state of the development.''
\end{itemize}
Easterbrook \cite{East:SM:1991:PhD} simplifies this description by defining a viewpoint as ``the formatted representation of a perspective'', noting that a perspective is a ``more abstract version of a viewpoint''. In effect, a viewpoint is the formalisation of a particular perspective, so there is a one-to-one correspondence between a viewpoint and the perspective it formalises, as illustrated in Fig.~\ref{Fig.Background.Terminology}.
The term `viewpoint' is very similar to the term `view' as used in multi-view editing systems \cite{Grun:JC:1993:PhD,Jaco:DA:1995:MultiView,Meye:S:1991:IEEE}. These terms refer to different concepts, however: a `view' is more akin to the concept of a \emph{description}, which will be introduced in Sect.~\ref{Sec:Framework}. The similarity of the two terms has led to some confusion: the terms `viewpoint' and `view' have been used interchangeably in the past \cite{Jaco:DA:1995:MultiView}.
Darke and Shanks \cite{Dark:P:1995} define two main types of viewpoint:
\begin{enumerate}
\item \emph{user viewpoints} that capture ``the perceptions and domain knowledge of a particular user group, reflecting the particular portion of the application domain relevant to that group''; and
\item \emph{developer viewpoints} that capture ``the perceptions, domain knowledge and modelling perspective relevant to a systems analyst or other developer responsible for producing some component of the requirements specification''.
\end{enumerate}
Since a viewpoint is the formalisation of a perspective, some form of model is required to provide the formalised structure. The concept of a \emph{representation} provides this.
%================================================================================
\subsection{Representations}
\label{Sec:Background:Viewpoints:Representations}
Darke and Shanks \cite{Dark:P:1995} note that viewpoints may be described using different representation \emph{techniques}, within each of which there may be available a number of representation \emph{schemes}. Neither Darke and Shanks nor Finkelstein et al. \cite{Fink:ACW:1989} clearly define the terms `representation', `technique' or `scheme'; rather, they introduce each term by example. This has led to some confusion in the use of this terminology. Darke and Shanks use the terms `representation' and `representation technique' interchangeably, while Finkelstein et al., as can be seen in their definition of a `style', use the term `representation scheme' in a similar way.
The intent appears to be that a \emph{representation} should be thought of as a structured modelling approach that can be used to describe the content of a viewpoint. In order to clarify the confusion in terminology, the author has refined this informal definition and defined a representation as the combination of a particular technique and scheme to describe a viewpoint (see Sect.~\ref{Sec:Framework}).
Finkelstein et al. \cite{Fink:ACW:1989} first mooted the idea of using multiple representations to describe a viewpoint in 1989, but there seems to have been little work in this area since. Darke and Shanks \cite{Dark:P:1996:RE} reviewed twelve different viewpoint development approaches and found only two that supported multiple representations to describe a single viewpoint: the Soft Systems methodology \cite{Chec:PB:1981:SSM} and Scenario Analysis \cite{Hsia:P:1994:Scenario}, which are both user viewpoint approaches.
The author's own research \cite{Stan:N:1999:PhD,Stan:N:1997:ECIS97} has followed the approach of using multiple representations to describe a single \emph{developer} viewpoint, and uses an integrated terminology framework derived from viewpoint-oriented methods.
%================================================================================
\section{The Extended Viewpoint Framework}
\label{Sec:Framework}
Looking at Table~\ref{Tab.MultipleRepresentations.Terminology}, there is fairly clear separation between the three viewpoint-oriented terminologies on the left of of the table and the four multiple-view-oriented terminologies on the right. The viewpoint-oriented terminologies deal more with `high level' concepts and tend to ignore how representations are internally structured; conversely, the multiple-view-oriented terminologies deal more with constructs within representations and tend to ignore higher-level structures. The two sets of terminology are clearly related, yet the only real overlap between them is at the representation level.
The UML comes closest to providing a full set of terms. It was designed from the outset to support multiple representations, and includes a viewpoint-like formalism (use cases). It is, however, deliberately restricted to nine specific representations, whereas the author's framework could be applied to any combination of representations (including those of the UML).
There are also several synonyms in Table~\ref{Tab.MultipleRepresentations.Terminology}. For example, the terms `style', `representation', `model' and `data model' all refer to similar concepts. Conversely, the terms `scheme' and `model' are both used to refer to completely different concepts. Such variation can lead to confusion, so there is a definite need to develop a consistent and integrated terminology framework.
The initial framework shown in Fig.~\ref{Fig.Background.Terminology} needs to be refined. The author has addressed the confusion in terminology by clearly defining the terms `representation', `technique' and `scheme', and has extended the original framework with the concepts of \emph{descriptions}, \emph{constructs} of representations and \emph{elements} of descriptions (see Fig.~\ref{Fig.MultipleRepresentations.Terminology}).
%%%%%%%%%%%%%%%%%%%%
\begin{figure}[htb]
\centering
\epsfig{file=ExtendedFramework.eps,width=\columnwidth}
\caption{The extended terminology framework}
\label{Fig.MultipleRepresentations.Terminology}
\end{figure}
%%%%%%%%%%%%%%%%%%%%
%================================================================================
\subsection{Representations}
\label{Sec:MultipleRepresentations:Representations:Representations}
Informally, a data modelling representation can be thought of as comprising two main parts:
\begin{enumerate}
\item a \emph{generic} part that specifies the generic constructs that may be used to describe a viewpoint, such as entities, relations, and so on; which determines
\item a \emph{specialised} part that specifies the constructs peculiar to the representation, along with their visual appearance or notation, such as boxes for entities, SQL \texttt{CREATE TABLE} statements for relations, and so on.
\end{enumerate}
Finkelstein et al.'s \cite{Fink:ACW:1989} concept of a `style' does not clearly distinguish between these two parts, as opposed to the `techniques' and `schemes' of Darke and Shanks \cite{Dark:P:1995}. It is therefore proposed to use the term \emph{technique} to refer to the generic part of a representation, and the term \emph{scheme} to refer to the specialised part of a representation. In practical terms, a technique can be thought of as a modelling `approach', such as the entity-relationship approach or the relational model, and a scheme can be thought of as a particular `notation' within that approach, such as Martin E-R notation or relational calculus. Another way to think of this is that a scheme is an `instantiation' of a particular technique.
A \emph{representation} can thus be defined as the combination of a particular technique with a particular scheme. In general, a technique may have one or more associated schemes, but each combination of a technique and a scheme forms a distinct representation. For example, the relational model is a technique, with $\mathit{SQL}$ and $\mathit{QUEL}$ as two possible schemes, but the combinations $(\RM,\mathit{SQL})$\footnote{In practice, the many dialects of SQL will form many different representations. This has been ignored here in the interests of clarity.} and $(\RM,\mathit{QUEL})$ form two distinct representations. Similarly, the entity-relationship approach ($\ER$) is a technique, with $\Martin$ and $\Chen$ as two possible schemes. The combinations $(\ER,\Martin)$ and $(\ER,\Chen)$ again form two distinct representations.
It is expected that a technique will not attempt to specify all possible concepts for all possible schemes within that technique. Rather, a technique defines the `base' model, which is then specialised and extended by schemes to form a representation. This implies that a scheme may provide new constructs to a representation that have no direct analogue in the technique. For example, the relational technique \cite{Codd:EF:1970} does not include general constraints, but they are an important feature of the relational scheme SQL/92. Similarly, type hierarchies are not part of the base E-R technique \cite{Chen:PP:1976}, but they do appear in some E-R schemes.
%================================================================================
\subsection{Descriptions}
\label{Sec:MultipleRepresentations:Representations:Descriptions}
Representations are an abstract concept, so they must be instantiated in some way in order to describe the content of a viewpoint. One way to view the instantiation of a representation is as a set of `statements' that describe a viewpoint or some subset thereof. Finkelstein et al. \cite{Fink:ACW:1989} refer to this as a `specification' or `description'; Easterbrook \cite{East:SM:1991:PhD} also refers to this concept as a description. The author has adopted the term `description' as it emphasises the idea that they are used to \emph{describe} a viewpoint.
A viewpoint is thus specified by a set of \emph{descriptions}, each expressed using some representation, as shown in Fig.~\ref{Fig.MultipleRepresentations.Terminology}. Each description may describe either all or some subset of the viewpoint; this is analogous to the concept of a `view' in multi-view editing systems \cite{Grun:JC:1993:PhD,Jaco:DA:1995:MultiView,Meye:S:1991:IEEE} or a `model' in the UML. For example, a developer viewpoint might be specified by the union of these four descriptions:
\begin{enumerate}
\item an object class description expressed using UML class diagram notation \cite{OMG:1999:UML};
\item a functional dependency description expressed using Smith functional dependency diagram notation \cite{Smit:HC:1985,Stan:N:1999:Smith};
\item a relational description expressed using SQL/92; and
\item a data flow description expressed using Gane \&~Sarson data flow diagram notation \cite{Gane:C:1979}.
\end{enumerate}
Descriptions may be distinct from each other, or they may overlap in a manner similar to viewpoints. Such redundancy can be useful in exposing conflicts both between descriptions and between viewpoints \cite{East:SM:1991:PhD}.
%================================================================================
\subsection{Constructs and Elements}
\label{Sec:MultipleRepresentations:Representations:Constructs}
Every representation comprises a collection of \emph{constructs}. These may be divided into generic constructs associated with the technique and specialised constructs associated with the scheme, as shown in Fig.~\ref{Fig.MultipleRepresentations.Terminology}. The nature of a construct is defined by its \emph{properties}, which include both its \emph{relationships} with other constructs, and its \emph{attributes}, such as name, domain or cardinality.\footnote{The terms `property', `attribute' and `relationship' come from the Object Data Management Group's object model \cite{Catt:RGG:2000:ODMG3}.} For instance, as illustrated in Fig.~\ref{Fig.MultipleRepresentations.Properties}, a data store in a data flow diagram might have the attributes \emph{name} (the name of the data store), \emph{label} and \emph{fields} (a list of data fields in the data store). The \emph{flows} relationship specifies an association between the data store construct and a list of data flow constructs.
%%%%%%%%%%%%%%%%%%%%
\begin{figure}[htbp]
\centering
\epsfig{file=Properties.eps}
\caption{Properties of a construct}
\label{Fig.MultipleRepresentations.Properties}
\end{figure}
%%%%%%%%%%%%%%%%%%%%
In the same way that a description is an instantiation of a representation, an \emph{element} is an instantiation of a construct; elements are combined to build descriptions. Examples of constructs include object classes, processes and attributes; elements corresponding to these constructs could be \textsf{Order}, \textsf{Generate invoice} and \textsf{address}.
%================================================================================
\section{A Notation to Express Representations, Descriptions, Constructs and Elements}
\label{Sec:Notation}
It can be cumbersome to discuss representations and descriptions using natural language, for example, `the \textsf{Staff} regular entity element of the description $D_{1}$ (expressed using Martin entity-relationship notation) of the managers' viewpoint'. The author has therefore developed a concise abstract notation (modelled in part on the data transfer notation of Pascoe and Penny \cite{Pasc:RT:1995}) for expressing representations, descriptions, constructs of representations and elements of descriptions. Using the notation, the statement above could be expressed as:
\[ \Elementt{\Description{D_{1}}{V_{mgrs}}{\ER}{\Martin}}{\mathit{staff}}{RegularEntity}\text{.} \]
The notation is summarised in Table~\ref{Tab.MultipleRepresentations.Notation}. The author has defined additional notations for expressing translations of descriptions from one representation to another \cite{Stan:N:1999:PhD}. For example, the expression:
\[ \Description{D_{1}}{V_{t}}{\FD}{\Smith} \rightarrow \Description{D_{2}}{V_{t}}{\ER}{\Martin}
\]
denotes the translation within viewpoint $V_{t}$ of a functional dependency description $D_{1}$ into an entity-relationship description $D_{2}$. Such additions are beyond the scope of this paper, however.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% column widths
\newlength{\wNot}
\newlength{\wTerm}
\settowidth{\wNot}{\Elementt{\Description{D_{i}}{V}{T}{S}}{e}{con},}
\settowidth{\wTerm}{\textbf{Associated term}}
\begin{table}[htb]
\centering
\caption{Summary of the abstract notation}
\label{Tab.MultipleRepresentations.Notation}
\hrule\smallskip
\begin{tabular}{clp{5.9cm}}
\textbf{Notation} & \textbf{Associated term} & \textbf{Definition} \\
\\
$V$ & Viewpoint & A formatted expression of a perspective on a real-world phenomenon \\
\\
$T$ & Technique & A collection of generic constructs that form a modelling `method', for example, the relational model or object modelling \\
\\
$S$ & Scheme & A collection of specialised constructs that form a modelling `notation', for example, SQL/92 or UML class diagram notation \\
\\
\Representation{R}{T}{S} or \Rep{R} & Representation & Representation \Rep{R} comprises constructs defined by the combination of technique~$T$ and scheme~$S$ \\
\\
\Description{D_{i}}{V}{T}{S} or $D_{i}$ & Description & Description $D_{i}$ of viewpoint $V$ is expressed using constructs of technique~$T$ and scheme~$S$ \\
\\
\parbox[t]{\wNot}{\centering \construct{\Representation{R}{T}{S}}{con}, \Construct{R}{con}, or \domain{con}} & \parbox[t]{\wTerm}{\raggedright Construct of a representation} & \domain{con} specifies a construct of representation \Representation{R}{T}{S} \\
\\
\parbox[t]{\wNot}{\centering \Elementt{\Description{D_{i}}{V}{T}{S}}{e}{con}, \Elementt{D_{i}}{e}{con}, or \Element{D_{i}}{e}} & \parbox[t]{\wTerm}{\raggedright Element of a description} & $e$ specifies an element (instantiated from construct \domain{con}) of description \Description{D_{i}}{V}{T}{S} \\
\end{tabular}
\smallskip\hrule
\end{table}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%================================================================================
\subsection{Description and Representation Notation}
The notation \Description{D_{i}}{V}{T}{S} denotes that description $D_{i}$ of viewpoint $V$ is expressed using constructs of technique $T$ and scheme $S$ (this may be abbreviated to $D_{i}$ when $V$, $T$ and $S$ are clear). Thus, \Description{D_{1}}{V_{p}}{\ER}{\Martin} denotes a description $D_{1}$ of the viewpoint $V_{p}$ that is expressed using constructs of the entity-relationship technique ($\ER$) and the Martin ERD scheme ($\Martin$).
The notation \Representation{R}{T}{S} denotes a representation \Rep{R} that comprises a collection of constructs defined by the combination of technique $T$ and scheme $S$ (this may be abbreviated to \Rep{R} when $T$ and $S$ are clear). Thus, \RepresentationS{R}{e}{\ER}{\Martin} denotes the representation \RepS{R}{e} formed by combining the constructs of the entity-relationship technique ($\ER$) with the Martin ERD scheme ($\Martin$).
Representations may differ in both the technique and scheme used, or they may share the same technique and differ only in the scheme. For example, consider a viewpoint $V_{q}$ that has three descriptions $D_{1}$, $D_{2}$ and $D_{3}$. $D_{1}$ is expressed using the entity-relationship technique and the Martin ERD scheme, and is denoted by \Description{D_{1}}{V_{q}}{\ER}{\Martin}. $D_{2}$ is expressed using the object modelling technique and the UML class diagram scheme, and is denoted by \Description{D_{2}}{V_{q}}{\mathit{Object}}{\mathit{Class_{UML}}}. $D_{1}$ and $D_{2}$ differ in both the technique and the scheme used. $D_{3}$ is expressed using the entity-relationship technique and the Chen ERD scheme, and is denoted by \Description{D_{3}}{V_{q}}{\ER}{\Chen}. $D_{3}$ differs from $D_{1}$ only in the scheme used.
If the viewpoint, technique or scheme are unspecified, they may be omitted from the notation. Thus, the notation \RepresentationS{R}{r}{\RM}{} denotes any relational representation, and \Description{D_{1}}{}{Object}{Class_{UML}} denotes a UML class diagram in an unspecified viewpoint.
%================================================================================
\subsection{Construct and Element Notation}
Constructs are the fundamental components of a representation, whereas elements are the fundamental components of a description. Given a representation \Representation{R}{T}{S}, a construct \domain{con} of \Rep{R} is denoted by \construct{\Representation{R}{T}{S}}{con}, or, if $T$ and $S$ are clear, simply \Construct{R}{con}. Often \Rep{R} may also be clear from the context, allowing the \Construct{R}{} notation to also be omitted, leaving just \domain{con}. The name of the construct itself is denoted by \textsc{small caps}.
The construct \domain{con} can be thought of as analogous to the concept of a relational domain in that it specifies a pool of possible `values' from which an element $e$ may be drawn. The notation $e:\domain{con}$ denotes that $e$ is a member of the set of all possible elements corresponding to the construct \domain{con}.
Now consider a description \Description{D_{i}}{V}{T}{S}. An element $e$ of $D_{i}$ (instantiated from construct \Construct{R}{con}) is denoted by \Elementt{\Description{D_{i}}{V}{T}{S}}{e}{con}, or, if $V$, $T$ and $S$ are clear, simply \Elementt{D_{i}}{e}{con}. The construct may also be omitted if it is clear from the context, that is, \Element{D_{i}}{e}. The representation \Rep{R} is omitted from the construct \domain{con} because \Rep{R} is implied by $T$ and $S$ in the description and would therefore be redundant.
Examples of construct and element expressions include:
\begin{itemize}
\item \construct{\RepresentationS{R}{e}{\ER}{\Martin}}{EntityType}, denoting the generic entity type construct of the E-R/Martin representation \RepS{R}{e};
\item \Elementt{\Description{D_{1}}{V}{\FD}{\Smith}}{s}{SingleValued}, denoting a functional dependency element in the Smith notation functional dependency description~$D_{1}$;
\item \Elementt{\Description{D_{2}}{V}{\RM}{\SQL}}{c_{1}, \ldots, c_{n}}{Column}, denoting a collection of column elements in the SQL/92 description $D_{2}$; and
\item \(\RepresentationS{R}{s}{\mathit{Object}}{\mathit{Statechart_{UML}}}[\domain{State},\domain{Event}]\), denoting the state and event constructs of the object modelling/UML statechart diagram representa\-tion~\RepS{R}{s}.
\end{itemize}
%================================================================================
\section{Conclusion}
\label{Sec:Conclusion}
In this paper has been described a framework for discussing the use of multiple modelling representations to describe a viewpoint. Earlier work on the use of multiple representations has produced a diverse and potentially confusing set of terminologies, none of which provides a complete set of terms covering all concepts in the area (with the possible exception of the UML). Viewpoint concepts provide a useful framework within which to discuss the use of multiple representations, but there is a lack of clarity over the definitions of the terms `representation', `technique' and `scheme'.
To remedy these issues, the author has clarified the definitions of `representation', `technique' and `scheme', and extended the viewpoint framework with the concepts of \emph{description}, \emph{construct} of a representation and \emph{element} of a description. Also described was an abstract notation for writing representation, description, construct and element expressions.
The framework described in this paper provides a consistent, integrated terminology and notation for researchers working on the use of multiple representations to describe a viewpoint.
%================================================================================
\bibliographystyle{plain}
\bibliography{ER2000}
\end{document}
