% $Id: modeling.tex 5106 2007-01-07 16:59:16Z gokhale $

\subsection{Modeling Dependability Requirements in MDDPro}
\label{sec:modeling}

We now describe how the MDDPro tool addresses Requirements (1) and (2)
described in Section~\ref{sec:factors}.   CQML allows modelers to
annotate the elements modeled with platform-specific details and
different quality of service (QoS) requirements as shown in
Figure~\ref{fig:cqml-sample}.   MDDPro is responsible for the
dependability QoS attributes in CQML.  The artifacts that can be
annotated are component instances, component implementations,
connections between component ports, component assemblies, among
others.   

MDDPro allows an enterprise DRE system deployer to model the
dependability requirements in the QoS view of the DRE system as shown
in Figure~\ref{fig:fou-model}.   The QoS view leverages the basic
structure of the DRE system in terms of the component instances in an
assembly, component ports and their inter connections.  It allows FT
elements to be modeled orthogonally to the system components and
therefore achieves separation of dependability concerns from the
primary system composition and functionality concerns. 

\begin{figure}[htb]
  \centering
  \includegraphics[width=5in,height=5in,keepaspectratio]{figs/FOU}
  \caption{Availability Requirements Modeling in CQML}
  \label{fig:fou-model}
\end{figure}

The following modeling elements are supported within MDDPro: 

\begin{BulletList}

\item \textbf{Failover units (FOUs),} which enable control over the
granularity of protected system components, such as software
components,  component assemblies, or entire component workflows.
Failure of any one element belonging to a FOU is treated equivalent to
the failure of all the elements in the FOU and the system effectively
''fails over'' to another replica of the FOU.  This modeling
abstraction not only captures the failover granularities of system
entities, but also the degree of replication for each FOU and other
systemic requirements, such as the periodicity of liveness monitoring
for FOUs.  The degree of replication is represented as a pair of
numbers representing minimum and maximum number of replicas.

\hspace{0.1in}
Frequently, the liveness of distributed components is monitored using
a ''heart beat'' protocol.  The frequency of the heartbeat is one
configurable parameter in the liveness monitoring, which can be configured
in MDDPro.  The heartbeat itself is configurable in two ways: \emph{push
  model} or \emph{pull model}.  Thus, the directionality of the
heartbeat can also be configured in MDDPro.  In Section~\ref{sec:gen}
we show how modeling of FOUs enable us to automatically synthesize and
configure liveness monitoring components as well as heartbeat
producing components.  Conceptually, a FOU is an abstraction to
capture the availability requirements at the control plane of the
dependability solution.

\item \textbf{Replication groups (RGs),} which allows capturing the
replication requirements of software components within a FOU.  These
models specify replication strategies, such as active, passive or other 
variants, and the state synchronization policies for components.
A replication group captures the configuration parameters related to
the data plane of the deployment solution.  Multiple replicas of the
system components synchronize their state with each other as per the
configuration of the data plane.  For example, data synchronization
frequency of the replicas is configurable.  Moreover, the topology of
state synchronization among replicas is also a data plane level
configuration issue handled in MDDPro.

\item \textbf{Shared Risk Groups (SRGs),} which defines groupings of
the resources in the target network of the applicationon that share
the risk of simultaneous failure.  Application components share the
risk of simultaneous failure by virtue of failure of resources they
share, such as processes, nodes, racks or even data centers on which
they are hosted.  Risk factors are determined by assigning metrics,
such as co-failure probabilities to the hierarchy network resources in
a risk group that impact availability of the system.  The computation
of the co-failure probabilities themselves is beyound the scope of
this paper and is assumed to be done apriori using realiability
engineering methodologies.

\hspace{0.1in}
The primary purpose behind modeling the shared risk groups and
their respective co-failure probabilities is to facilitate automated
deployment decisions of the components in the system such that the 
probability of failure of entire system is minimized thereby
increasing the availability.  In Section~\ref{sec:placement} we show
how the shared risk group model is used by the MDDPro model
interpreter to determine a suitable and effective deployment that
satisfies the availability requirements and minimizes risks of
simultaneous failures.

\end{BulletList}
