\subsubsection{Dependency}
\label{dependencies}

A \dependencys is specified by the following definitions: \\

(1) It  models an interaction
between two software entities which has an impact upon the scheduling of the
system. One of those entity is called the sink entity and the other is the source entity.\\

(2) Software entities handled in a \dependencys component can 
either be \tasks , and or \resources and or \buffers and or \messages.\\

\begin{center}
	Standard attributes
\end{center}

$Type_-of_-dependency$ : It specifies the kind of dependency component.\\

A dependency is a kind of union component : depending on its type, a dependency
has different attributes described in the sequel.\\


\begin{center}
	Legality rules
\end{center}

(L1) The dependency name must have a type.\\

\begin{center}
	Annexes
\end{center}


(A1) The types of \dependencys are :\\

\indent \indent (A11) $Precedence_-Dependency$ :  this dependency
models a precedency relationship between two \task components. With this dependency,
the sink task must wait for the completion of the source task before being released by the scheduler. \\

\indent \indent (A12) $Queuing_-Buffer_-Dependency$ :  this dependency
models a producer/consumer relationship between \task components and a \buffer component.
When the source component is a task and the sink component is a buffer, the dependency models the producer side.
When the sink  component is a task and the source component is a buffer, the dependency models the consumer side.\\
This dependency assume a fixed buffer size. A data  can be read once
 and we assume that no
data can be lost.\\


\indent \indent (A13) $Asynchronous_{-}Communication_{-}Dependency$ :  
this dependency models  asynchronous exchanges of \messagess between \task components. 
When the source component is a task and the sink component is a message, the dependency models the emitter side.
When the sink  component is a task and the source component is a message, the dependency models the receiver side.\\
Different protocols explain how and when messages are sent of received.
The attribute $Asynchronous_-Communication_-Prococol_-Property$ models such a semantics and allows
to express two protocols:
\begin{itemize}
	\item  $First-Message$ protocol : the receiver task is released 
	when at least 
	one message of any of its sender is available in the queue. Releasing the 
	receiving task leads to read this message and  to  remove it  from the queue.

	\item  $All_-Messages$ protocol : the receiver task is released 
	when at least one message of each its sender is available. Releasing the 
	receiving task leads to read one message per sender and removing them from the queue.

\end{itemize}

\indent \indent (A14) $Time_-Triggered_-Communication_-Dependency$ :  this dependency
models a  synchronous communication between two \task components. 
Data/messages are read on task release and sent on task completion.
 Three protocols exist for such dependency:
\begin{itemize}
	\item  $Sampled_-Timing$ :  with this protocol, emitters and receivers send/receive synchronous messages at their own rate.
	Messages are not queued : only the last sent message can be read by receivers. This protocol does not imply any constraint
	on task releases and data consistency. 
	From a scheduling point of view,  tasks are independent.
	\item $Immediate_-Timing$ :  with this protocol,  when an emitter completes its 
	execution, its message is send and the receiver task is immediately released.
	The actual time at which the receiving task is run depends on the scheduling, e.g this protocol  enforces that the receiver task
	can not be released and  run before completion time of the sending task.  From a scheduling point of view, this dependency is equivalent
	to a precedence dependency.
	\item $Delayed_-Timing$ :  with this protocol,  when an emitter completes its 
	execution, the protocol enforces that the receiver will be released
	on the next activation of the emitter task. This delay is expressed by the offset of the sink task.
	From a scheduling point of view, those tasks are independent as we only change task release times by offsets.\\
\end{itemize}

The protocol is set by the attribute $Time_-Triggered_-Timing_-Property$.

\indent \indent (A15) $Resource_-Dependency$: this dependency
models a shared memory access  between several \task components and a \resource  component.


\indent \indent (A16) $Black_-Board_-Buffer_-Dependency$:  this dependency
models a producer/consumer relationship between \task components and a \buffer com-ponent.
When the source component is a task and the sink component is a buffer, the dependency models the producer side.
When the sink  component is a task and the source component is a buffer, the dependency models the consumer side.
This dependency assume a buffer size of  1. A message can be read several times or never, e.g. consumers read the last written message
produced by producers. 
From a scheduling point of view, tasks accessing a black board are independent.\\

\begin{center}
	Implementation
\end{center}

The figure \ref{dtd_dep} gives the DTD of entity \dependencys.


\begin{figure}{}
	\begin{lstlisting}{}
	
	<!ELEMENT dependencies (dependency)+>
	<!ELEMENT dependency (type_of_dependency | 
	precedence_sink | precedence_source | 
	buffer_dependent_task | buffer_orientation | 
	buffer_dependency_object | 
	asynchronous_communication_dependent_task | 
	asynchronous_communication_orientation | 
	asynchronous_communication_dependency_object |
	asynchronous_communication_protocol_property |
	time_triggered_communication_sink | 
	time_triggered_communication_source | 
	time_triggered_timing_property | 
	resource_dependency_resource | 
	resource_dependency_task | 
	black_board_dependent_task | 
	black_board_orientation | 
	black_board_dependency_object)*>
	
	\end{lstlisting}
	\caption{The DTD of entity \dependencys}
	\label{dtd_dep}
\end{figure}

\begin{center}
	Examples
\end{center}

The figure \ref{example_dependency} gives examples of 
\dependencys.

We illustrate with an example of $QUEUING_-BUFFER_-DEPENDENCY$, 
$RESOURCE_-DEPENDENCY$, $ASYNCHRONOUS_-COMMUNICATION_-DEPENDENCY$ and  
$PRECEDENCE_-DEPENDENCY$

\begin{figure}{}
	\begin{lstlisting}{}
	
	<dependencies>
	<dependency>
	<type_of_dependency>QUEUING_BUFFER_DEPENDENCY
	</type_of_dependency>
	<buffer_dependent_task ref=" 42" />
	<buffer_orientation>FROM_TASK_TO_OBJECT
	</buffer_orientation>
	<buffer_dependency_object ref=" 46" />
	</dependency>
	
	<dependency>
	<type_of_dependency>RESOURCE_DEPENDENCY
	</type_of_dependency>
	<resource_dependency_resource ref=" 44" />
	<resource_dependency_task ref=" 42" />
	</dependency>
	
	<dependency>
	<type_of_dependency>ASYNCHRONOUS_COMMUNICATION_DEPENDENCY
	</type_of_dependency>
	<communication_dependent_task ref=" 43" />
	<communication_orientation>FROM_TASK_TO_OBJECT
	</communication_orientation>
	<asynchronous_communication_protocol_property>ALL_MESSAGES
	</asynchronous_communication_protocol_property>
	<communication_dependency_object ref=" 45" />
	</dependency>
	
	<dependency>
	<type_of_dependency>PRECEDENCE_DEPENDENCY
	</type_of_dependency>
	<precedence_sink ref=" 42" />
	<precedence_source ref=" 43" />
	</dependency>
	
	</dependencies>
	
	\end{lstlisting}
	\caption{Examples of \dependency}
	\label{example_dependency}
\end{figure}