\documentclass{llncs}
\usepackage{graphics}
\usepackage{amsmath}
\usepackage{graphicx}
\usepackage{epsfig}
\usepackage {listings}
\usepackage {keyval}
\usepackage{rotating}
\usepackage{amssymb}
\setcounter{tocdepth}{3}
\usepackage{graphicx}


\begin{document}
\mainmatter 
\title{Ontological Analysis for Generating  Baseline  Architectural Descriptions}

\author{Arvind W. Kiwelekar \and Rushikesh K. Joshi} 
\institute{Department of Computer Science and Engineering\\
Indian Institute of Technology Bombay\\ Powai, Mumbai-400076, India \\
 awk@cse.iitb.ac.in, rkj@cse.iitb.ac.in} 


\maketitle


\begin{abstract}
Mapping elements from an application domain
to architectural abstractions is a significant architecture description 
activity from the point of view of seamlessness in descriptions. 
For establishing such a mapping of domain elements to architectural abstractions, 
an approach based on {\em ontological analysis} is presented.
The  central idea of the approach is to establish
the mapping through a uniform framework of understanding that is applicable
over the problem domain as well as the solution domain. 
The reference ontology used is an adaptation of Bunge-Wand-Weber (BWW) ontology. 
Typically, an element from an application domain is mapped with an architectural abstraction 
when both represent the same phenomena from BWW ontology. 
The  approach is realized as a model-driven transformation process.
\end{abstract}




\section{Introduction}
Domain understanding is one of the concerns that needs
to be addressed  while deriving 
architectural descriptions from requirements \cite{Reqproblems}.
Some of the challenges faced while understanding application domains are-
(i) Different models are used to represent outcomes of the activities of requirement
analysis and architecture design.
(ii) Domain requirements are elaborated through domain terminology.
(iii) Correspondence among requirements and architectural viewpoints is undefined.

In this paper, an {\em ontological analysis  technique}  to  guide the transition from requirements 
to architecture is presented. 
The technique aims to understand application domains
and architectural abstractions  through a universal
language formalism. 
The BWW ontology
\cite{ontobook,ISOnto}
is used to interpret domain elements and architectural abstractions.
The reason for selecting  this ontology was that  it
has been applied
to evaluate the expressive power of various  modeling languages such
as  UML \cite{umlevaluation},  and ebXML \cite{ebxml}, and
it is a generic ontology capturing diverse phenomena.
The outcomes of the application of the analysis technique  
include identification of architecturally significant domain elements
specific to Component-Connector (C\&C) viewpoints, and 
an initial architectural configuration 
aligned with interactions among domain elements.
The technique assumes the availability of domain 
descriptions in  natural language text
or scenario descriptions. 

Earlier approaches  that derive architectural descriptions from requirements vary
in terms of  analysis models used. 
Analysis models such  as goal oriented analysis \cite{reqarch3,drama},
global analysis \cite{archReqEngg,reqarch6}, and
quality attribute based analysis \cite{drama} 
are some of the techniques used  earlier.
In this paper, it is proposed to perform ontological analysis of
application domains for describing domains in terms of ontological
categories.
Some of the earlier approaches  such as 
the collaborative approach called CBSP   \cite{reqarch1} 
target the component-connector (C\&C) view.
The CBSP approach analyzes requirements in terms of components,
 buses, systems and properties. 
A limitation of this approach is that a given requirement may be mapped to
a component or a connector by different analysts. 
The conflicts on the choice of abstraction is resolved through a voting process that
lacks analytical reasoning. 
The approach presented in this paper also targets C\&C views.
An element from an application domain is mapped with an architectural abstraction 
only when both represent the same phenomena from BWW ontology. 
The approach presented in this paper  also attempt to address the problem of
vagueness  \cite{taxnomy} in semantics of components and connectors.
The problem is handled  by performing  ontological analysis of
components and connectors.
The distinctness of these abstractions is brought out by showing that
components are the representations of {\em Things} and connectors represent
{\em Coupled Events}. {\em Things} and {\em Coupled Events} are two different
phenomena from the reality.



The next section  describes the reference model based on BWW ontology. 
Section 3 presents an overview of the process with various artifacts involved.
Ontological interpretations of architectural abstractions and also of domain elements are presented in Section 4. Section 5 discusses transformation rules that transform
the output ontological analysis to components and connector specifications.



\begin {figure*}[t]
\begin {center}
\includegraphics [scale=0.225]{bwwNewMeta}
\end {center}
\begin {center}
\caption{An Object Oriented meta-model for BWW Ontology}\label{bwwmeta}
\end {center}
\end {figure*} 

\section{BWW Reference Model}\label{bwwmetaS}
Bunge's original 
ontology \cite{ontobook} is considered as a general system 
theory. Later,  Wand and Weber \cite{wwpaper1} subsequently adapted it 
to model information systems. The adapted version is referred to BWW ontology. 
An {\em ontological category} 
capturing a real world phenomenon 
is a high-level generic notion defined in an ontology.
Ontological categories are valuable conceptual abstractions to analyze a
particular domain because they can be used to identify the roles played by
domain abstractions and  relationships among them.
BWW  ontology includes a  comprehensive set of ontological categories that model static and dynamic features of reality. 
Earlier we developed a classification scheme 
for ontological categories and a
meta-model for BWW ontology 
that  have been reported in \cite{sweckapaper}.
The ontological categories and the relationships among them are represented through
a UML meta-model is summarized in Figure \ref{bwwmeta}.
The meta-model has been formalized through type-theoretic notations.
By specifying the meta-model through type theoretic notations, we learnt that
the ontological categories are generic types and they can play the roles of {\em types} 
to describe elements from application domains.

\begin{table*}[t]

\begin{tabular}{p{5in}}

\begin{center}
\begin{tabular}{|p{1in}|p{1in}||p{1in}|p{1.5in}|}
\hline
 \textbf{Architectural Abstractions} & \textbf{BWW Category}  & 
\textbf{Architectural Abstractions}  & \textbf{BWW Category} \\ \hline
Component & Thing & Port & Attributes representing Binding Mutual property \\ \hline
Connector & Coupled Process &  Roles & Mutual Binding Property  \\ \hline 
System & System  &  Representation & System Composition  \\ \hline
Property & BWW Property &
Attachments &  Representation relation between mutual property and attributes  \\ \hline  
\end{tabular}
\end{center} \\ 
\textbf{ (a) Interpretation Mapping for Architectural Abstractions} \\
\begin{center}
\begin{tabular}{|p{0.25in}|p{1.5in}|p{0.5in}||p{0.25in}|p{1.5in}|p{0.5in}|}
\hline
 \textbf{Sr. No.} & \textbf{Domain Element} & 
\textbf{BWW Category}  & 
\textbf{Sr. No.} & \textbf{Domain Element} & 
\textbf{BWW Category} \\ \hline
1. & Meeting Initiator & Thing & 2. & Meeting Attendee & Thing \\ \hline
3. & To Ask all for exclusion set & Coupled-event  &
4  & To ask all for preference set & Coupled-event \\ \hline
5. &  Exclusion Set & Property & 6. & Preference set & Property  \\ \hline
7. & Meeting Date & Property & 8. & To ask for special Equipment & Coupled Event \\ \hline
9. & To ask for preferred location & Coupled Event  &
10.& The proposed meeting date should belong to the stated date range and to none of the exclusion 
sets & Law    \\ \hline
\end{tabular} 
\end{center} \\ 
\textbf{ (b) Interpretation Mapping for  Example Domain Elements from Meeting Scheduler Problem} \\ 
\end{tabular}
\caption {\textbf{Interpretation Mappings}} \label {imap}
\end{table*}
\begin {figure*}[t]
\begin {center}
\includegraphics [scale=0.25]{m1}
\end {center}
\begin {center}
\caption{Meta-model for Architectural Abstractions }\label{ACMEmeta}
\end {center}
\end {figure*}

\section{The Process and its Artifacts} Two different types of modeling artifacts are needed.  Firstly, a {\em domain ontology model} describes an application domain through BWW ontological
categories. This model is  manually developed after performing
ontological analysis of requirements. 
The second model is automatically generated and it is referred to as a {\em baseline architectural description}. 
It consists of  a set of architecturally
significant elements from application domain.
Baseline architectural abstractions i.e., abstractions present 
in baseline architectural descriptions can be further refined into full-fledged 
architectural abstractions by adding features found in software modeling
languages. For example, in  $Meeting\ Scheduler$ domain \cite{prob}, {\em getting a preferred date
for meeting} is an element of the domain that can be considered as a 
baseline connector. This baseline connector can be further refined to 
a full-fledged software connector by adding non-functional features such as distribution, concurrency and
security around the baseline connector.
Earlier, we have used the concept of the {\em baseline connector} to extract C\&C views 
from the UML models of existing systems \cite{compsacpaper}. A baseline connector becomes a {\em full-fledged} connector by adding non-functional properties
to it.


\section{Interpreting Architectural Abstractions and Domain Elements through BWW Ontology} \label{c2metaS}

The existing practices and taxonomies   \cite{taxnomy,reqarch2}
provide guidelines to represent  solution-domain specific entities 
through architectural abstractions. 
For example, computational processes or database entities
can be represented through components.
The interaction entities such as pipes, semaphores and communication protocols 
can be represented through connectors. 
These guidelines are convenient to describe  architectures of many software systems.
But they offer  little assistance to derive architectural abstractions from domain descriptions.
The interpretation mappings   are developed to provide an  
assistance by relating the architectural abstractions with
the generic types of domain elements.
In this context, the ontological categories 
play the roles of generic types.
The architectural abstractions from ACME ADL \cite{acmepaper} are considered
as the reference model for architectural abstractions
in the process of developing interpretation mappings.



As shown in Table \ref{imap}, two different types of interpretation mappings are defined.
The {\em abstraction mapping} relates the ACME abstractions with the BWW ontological categories.
The prevalent usages of the architectural abstractions and 
their intended meanings  are the criteria used to establish
the correspondence. The architectural abstractions and the relationships among  them  are
represented through a UML meta-model as shown in Figure \ref{ACMEmeta}. 
The  {\em domain mapping} assigns exactly one category to a domain element 
because each domain element represents a single phenomenon from the reality.
A noun, or a noun phrase, a verb or a verb phrase or a single sentence 
describing domain requirements is considered as   a domain element. 
The domain mapping is also referred to as {\em domain ontology
model} and it is described as an XMI document.
The BWW ontological categories are the tags in XMI document. 
The XMI document describing application domain follows the schema
presented in the meta-model of the reference BWW ontology shown in Figure \ref{bwwmeta}. 
The mapping from domain elements to BWW ontology is  depended on an application domain and it is defined every time for each domain. The mapping from architectural abstractions to BWW ontology is  independent of
application domains  and it is  defined only once as a reusable process. The metamodel represented in Figure \ref{ACMEmeta} is used
as schema for the output description.

\section{Transformation Rules} \label{rules}
Transformation rules are defined to 
create architectural abstractions from a
domain ontology model. 
A C\&C view described in ACME is the output model
that the transformation rules generate.
Transformation rules are invoked based on the ontological types of  domain elements.  
Things, Properties, Coupled Events and BWW System are some types of
domain elements. They are transformed to ACME Components
Properties, Connectors and System respectively.
The type of ACME abstraction to be created is guided by
the interpretation mapping defined in Table \ref{imap}(a).
Transformation rules are realized in ATLAS Transformation Language (ATL). 
One example of a transformation rule for transforming coupled event to connector
is included below.


\lstset{tabsize=1,basicstyle=\small,showstringspaces=false}
\begin{center}
\begin{tabular}{|p{2.4in}|p{2.4in}|}
\hline
\begin{lstlisting}
1rule ce2con{
2  from
3   ce:BWWOntology!CoupledEvent
4  to
5 --Constructing new connector.
6  con:C2ADL!Connector(
7   name<- ce.name,
8   ownedRoles<- Sequence{}),
9  -- Constructing Properties 
10 p: C2ADL!Property(
11  name <- 'Parameters',
12  value<- ce.parameter,
13  ownedElement<- Sequence{}
14     ->append(ce)),
15 -- Constructing Roles
16 role1: C2ADL!Role(
17  name<-ce.name+'Requester'),
18 role2: C2ADL!Role(
19  name<-ce.name + 'Replier'),
\end{lstlisting} &
\begin{lstlisting}
20    --  Constructing Ports 	
21	port1: C2ADL!Port(
22	  name<-ce.name + 'RepPort',
23	  owner<- ce.agent),
24	port2: C2ADL!Port(
25	  name<-ce.name + 'ReqPort',
26	  owner<- ce.patient),
27	binding1 : C2ADL!Attachment(
28	  port<- port2,
29	  role<- role2),
30	binding2 : C2ADL!Attachment(
31	  port<- port1,
32	  role<- role1)
33	do{
34	con.ownedRoles<- con.
35	ownedRoles->append(role1);
36	con.ownedRoles<- con.
37	ownedRoles->append(role2);
38	}}
\end{lstlisting} \\ \hline
\end{tabular}
\end{center}
\begin {figure*}[t]
\begin {center}
\includegraphics [scale=0.2]{mssC2Diagramdia}
\end {center}
\begin {center}
\caption{Generated Architectural Configuration for Meeting Scheduler Problem}\label{f2}
\end {center}
\end {figure*} 
An instance of a connector is created when the ontological type of  
a domain element is {\em Coupled Event}.
Steps involved in creating new instance of connectors are
(i) defining properties of connectors,
(ii) constructing roles of connectors, 
(iii) creating ports in the components playing the
roles of connectors, and 
(iv) binding ports to roles through attachments.
Connectors, Ports, Roles and Attachments  are created as a result of processing of
instances of {\em Coupled Events}. In some cases, though
the number of connectors, ports, roles and attachments can be 
minimized by merging all coupled events that share their participant things,
this may be undesirable from the point of view of losing flexibility.
For example, in Figure \ref{f2}, the instances of coupled events
{\em askAllPrefSet} and {\em askAllExSet} are not
merged to form a single connector instance. 
It can be noted that non-functional properties of interactions 
may depend on the semantics of interactions among things
and not on the participant types.
In interaction such as {\em withdraw meeting}, 
an acknowledgment or reply may not be expected,
while in the interaction {\em askAllPrefSet}
an acknowledgment and reply are expected.
Coupled events that need an acknowledgment may use
a {\em reliable}  communication protocol.
In this context,  reliability is a  non-functional property.

The transformation rules generate a XMI document that
conforms to the XMI schema representing meta-model of 
architectural abstractions. 
The baseline architectural configuration for {\em Meeting Scheduler Problem} 
as generated by the approach is shown in Figure \ref{f2}.
An earlier C\&C-based architectural model of
{\em Meeting Scheduler problem} can be found in \cite{umladlpaper}. 
The appropriateness of the generated architectural description is checked
by comparing it with the existing architectural description.

\section{Conclusion}

A process of mapping domain elements
to produce $C\&C$ based  architectural descriptions
was discussed in this paper.
The outcomes of the process include  identification of
architecturally significant domain elements and 
an architectural configuration aligned to interactions among
things present in the domain.
Usefulness of the approach comes from  the 
definition of  transformation rules to create an architectural configuration.
The transformation rules maintain  traceability links
between domain requirements and architectural abstractions.
By introducing the concept of {\em baseline architectural descriptions} 
the approach achieves a separation of 
application domain specific concerns from
software specific concerns. 
Currently, the task of interpreting domain elements
in terms of BWW ontological categories is manually performed
by mapping the decisions depend on the judgment of a domain expert.
The approach can be explored further-(i) by considering non-functional properties,
(ii) validating the approach through non-trivial software systems and  (iii) evaluating
the approach from scalability point of view and by (iv) developing 
knowledge-based automated techniques to assist the process.

\bibliographystyle{splncs}
\bibliography{paper} 
\end{document}
