diff --git a/docs/userGuide/userGuide.tex b/docs/userGuide/userGuide.tex
index f9fd03e4fe40288814a9ffb9aa06fdd508fb026f..d4cdeea4dd2ad9d581d72c193fed7fc17fcb7b09 100644
--- a/docs/userGuide/userGuide.tex
+++ b/docs/userGuide/userGuide.tex
@@ -280,21 +280,59 @@ Many data structures are defined as a n-tuple where the components are of differ
 
 \subsection{Component as a base of datastructure}
 
-Using the component requires to derive your datatype from a templated class \emph{code::Components}. The \emph{code::Components} class uses the \emph{Curiously recurring template pattern} by its first template parameter. Next parameters come three at a time. The first of the triplet is defining the internal datatype of the component, the second is the component behavior scheme, and the third is a name of the component.
+Using components requires to derive your datatype from a templated class \emph{code::Components}. The \emph{code::Components} class uses the \emph{Curiously recurring template pattern} in its first template parameter. Next parameters come three at a time. The first of the triplet is defining the internal datatype of the component, the second is the component behavior scheme, and the third is a name (or names) of the component.
 
 template < class SymbolType, class StateType >
 class DFA final : public AutomatonBase, public core::Components < DFA < SymbolType, StateType >, ext::set < SymbolType >, component::Set, InputAlphabet, ext::set < StateType >, component::Set, std::tuple < States, FinalStates >, StateType, component::Value, InitialState >
 
+In this example the deterministic finite automaton is constructed from set of symbols represented by InputAlphabet component, two sets of states represented by States and FinalStates components, and a state represented by InitialState component.
+
 The internal type of the component must provide common interface required by the component behavior scheme. So far supported schemes are \emph{component::Set} and \emph{component::Value}. The component set scheme expects the internal datatype to implement interface of a set from the standard library. The componet value scheme expects the internal datatype to behave like primitive type.
 
 The name of the component can be specified in two ways. Either it can be specified by class name, where typically the class used here is incomplete. Or more names can be given at once to signal there are more components having the same structure and behavior in the datatype definition. If more names are provided, the resulting components are instanciated for each name in a set and they are therefore independent instances.
 
 \subsection{Access to component content}
 
-Depending on the behavior scheme of the component, each component provides some simplified inteface to the underlying data type.
+Depending on the behavior scheme of the component, each component provides some simplified inteface to the underlying data type. The common operations of all components are \emph{get} and \emph{set}, to get the data and set the data as a whole.
+
+The \emph{component::Set} scheme additionally supports \emph{empty}, \emph{remove}, and \emph{add}, where these are equivalent to standard set operations \emph{empty}, \emph{erase}, and \emph{insert}.
 
 \subsection{Constraint specification}
 
+To maintain consistency of datatypes constructed from components, some constraints need to be specified. These constraints are specified by additional code inside a class specialized with the concrete data type and component name. Given the component behavior scheme the constraints may differ.
+
+The \emph{component::Value} behavior scheme requires existence of available and valid static methods inside the \emph{ElementContraint} class. The method available represents check that the value to be set is available in other related components. The method valid represents additional check for validity of the setted object, if needed the method is supposed to throw an exception.
+
+template<class SymbolType, class StateType >
+class ElementConstraint< automaton::DFA<SymbolType, StateType>, StateType, automaton::InitialState > {
+public:
+	static bool available ( const automaton::DFA<SymbolType, StateType> & automaton, const StateType & state ) {
+		return automaton.getStates ( ).count ( state );
+	}
+
+	static void valid ( const automaton::DFA<SymbolType, StateType> &, const StateType & ) {
+	}
+
+};
+
+The \emph{component::Set} behavior scheme requires existence of used, available, and valid static methods inside the \emph{SetContraint} class. The methods available and valid are the same as in case of the \emph{component::Value} behaviour sheme. The additional method used is representing check whether removed object from the set component is used in other related components.
+
+template<class SymbolType, class StateType >
+class SetConstraint< automaton::DFA<SymbolType, StateType>, StateType, automaton::FinalStates > {
+public:
+	static bool used ( const automaton::DFA<SymbolType, StateType> &, const StateType & ) {
+		return false;
+	}
+
+	static bool available ( const automaton::DFA<SymbolType, StateType> & automaton, const StateType & state ) {
+		return automaton.getStates ( ).count ( state );
+	}
+
+	static void valid ( const automaton::DFA<SymbolType, StateType> &, const StateType & ) {
+	}
+
+};
+
 \section{Normalisation}
 \label{section:normalisation}