(docs): заментировал старую документацию

docs/DocPages/Concept.dox

@@ -13,14 +13,14 @@
 - \ref sec_Cnpt_Process
   
 
-	\section sec_Cnpt_Object Объект
+	\section sec_Concept_Object Объект
 В разных местах описаний, в зависимости от контекста,
 под "объектом" подразумевается либо объект класса так или иначе наследующегося
 от базового класса библиотеки UniSetObject, либо
 некий концептуальный программный  объект способный 
 получать и обрабатывать сообщения.
 
-  \section sec_Cnpt_ObjectTypes Основные типы объектов
+  \section sec_Concept_ObjectTypes Основные типы объектов
 В библиотеке произведено условное деление на следующие типы объектов:
   - (простые) объекты - наследуются от класса UniSetObject
   - контроллеры - являются наследниками класса IOController
@@ -28,7 +28,7 @@
   - узлы        - в строгом смысле, не являются объектами,
                   но обладают уникальным идентификатором.
 
-	\section sec_Cnpt_Message Сообщения
+	\section sec_Concept_Message Сообщения
 Вся система взаимодейтсвия между объектами в основном
 построена на использовании сообщений (передаваемых
 путём удаленного вызова специальных функций,
@@ -53,9 +53,9 @@ UniSetTypes::Message::TheLastFieldOfTypeOfMessage.
 \endcode
 
 
-	\section sec_Cnpt_ObjectId Идентификатор объекта
+	\section sec_Concept_ObjectId Идентификатор объекта
 Каждый объект, которому необходимо взаимодействовать с другими объектами
-(в том числе датчиками см. \ref sec_Cnpt_Sensor) должен обладать уникальным
+(в том числе датчиками см. \ref sec_Concept_Sensor) должен обладать уникальным
 идентификатором. В качестве идентификатора выступает любое число типа \b UniSetTypes::ObjectId.
 Зарезервированным числом является UniSetTypes::DefaultObjectId.
 Минимальное требование - это уникальность в рамках одного узла.
@@ -170,9 +170,9 @@ UniSetTypes::Message::TheLastFieldOfTypeOfMessage.
 не сложными скриптами).
 
  
-	\section sec_Cnpt_Repository Репозиторий объектов
+	\section sec_Concept_Repository Репозиторий объектов
 
-	\section sec_Cnpt_Sensor Датчик
+	\section sec_Concept_Sensor Датчик
 Датчик - это одно из базовых понятий при построении систем на основе libuniset.
 Датчик - это информационная единица. Практически любая информация
 (о событиях, о состоянии того или иного процесса, объекта, сообщение оператору и т.п.) 
@@ -195,7 +195,7 @@ UniSetTypes::Message::TheLastFieldOfTypeOfMessage.
 на передачу цифровой информации (не текстовой).
 Например CAN, ModbusRTU, ModbusTCP и т.п.
 
-	\section sec_Cnpt_Process Процесс
+	\section sec_Concept_Process Процесс
 Под процессом в документации чаще всего подразумевается системный
 процесс (запущенная программа) выполняющий те или иные функции управления
 и обменивающийся для этого с другими процессами сообщениями или

docs/DocPages/Configuration.dox

-/*!
+/* OBSOLETE DOC!!!
 	\page ConfigurationPage Конфигурирование системы
 
 	- \ref ConfigurationPage_secCommon
@@ -16,13 +16,14 @@
 	функции main. Например так:
 \code
 ...
-#include "ObjectsMap.h"
+#include <Configuration.h>
 using namespace UniSetTypes;
+
 int main(int argc, char **argv)
 {
     try
     {
-		conf = new Configuration(argc, (const char**)argv, "configure.xml", (ObjectInfo*)ObjectsMap);
+		uniset_init(argc, argv, "configure.xml");
 		...
 		...
 		

docs/DocPages/commitpage.dox → docs/DocPages/commonpage.dox

-<<<<<<< HEAD
-/*! OBSOLETE DOC!!
- \page CommitPage Общее описание библиотеки UniSet 
+/* OBSOLETE DOC!!
+ \page CommonPage Общее описание библиотеки UniSet
 
   - \ref secSection1
-  	- \ref subIO
+	- \ref subIO
 	- Алгоритмы управления
 	- \ref UniSetGraphics
 	- \ref subInfoServer
 	- \ref UniDiag
 	- \ref subTimer
-	
+
   - \ref secSection2
 	- \ref subTransfer
 	- \ref subDBSave
 
-  - \ref secDetail	
-  	- \ref subObjects
+  - \ref secDetail
+	- \ref subObjects
 	- \ref subProcesses
   - \ref secResourses
   - \ref secDirStruct
-  
+
   \section secSection1 Назначение
   Библиотека предназначена для разработки распределенных систем управления. В ней собраны основные компоненты из которых
   строятся подобные системы (базовые интерфейсы для разработки процессов управления, процессов управления вводом/выводом,
   менеджеров сообщений и т.п.). Любую систему управления можно поделить на относительно независимые объекты рещающие
   следующие задачи:
-  	- ввод/вывод (опрос физических датчиков, обмен с другими устройствами)
+	- ввод/вывод (опрос физических датчиков, обмен с другими устройствами)
 	- алгоритмы управления тем или иным устройстов или группой устройств
 	- отображение информации (графический интерфейс пользователя)
 	- накопление и хранение информации
 	- просмотр накопленной информации
 	\par
-	Для каждой из задач в библиотеке разработан определенный компонент(группа компонентов). 
+	Для каждой из задач в библиотеке разработан определенный компонент(группа компонентов).
 	И разработаны универсальные механизмы взаимдействия объектов между собой.
-	
+
   \section secSection2 Общие принципы работы
-  	Библиотека позволяет объектам системы обмениватся сообщениями, а так же непосредственно вызывать функции друг-друга. В системе объектами
+	Библиотека позволяет объектам системы обмениватся сообщениями, а так же непосредственно вызывать функции друг-друга. В системе объектами
 	управляют менеджеры. Которые позволяют управлять (через этот) менеджер сразу набором подчиненных ему объектов. Менеджер может
 	содержать в себе в качестве подчиненного объекта другой менеджер, что позволяет строить довольно гибкую иерархическую структуру
 	управления. Всё взаимодейтсвие объектов( сетевое и межпроцессовое) строится на базе CORBA-ы.
 
 	\subsection subTransfer Взаимодействие объектов системы
-	 	Взаимодействие объектов между собой происходит через ObjectRepository. Каждый объект становится доступным другим объектам только
-	после регистрации в репозитории. Для получения доступа к другому объекту (даже удаленному) необхоимо знать его идентификатор(UniSetTypes::ObjectId) 
+		Взаимодействие объектов между собой происходит через ObjectRepository. Каждый объект становится доступным другим объектам только
+	после регистрации в репозитории. Для получения доступа к другому объекту (даже удаленному) необхоимо знать его идентификатор(UniSetTypes::ObjectId)
 	и при помощи репозитория получить на него ссылку, с которой можно работать как с указателем на объект.
 		...
 		Каждый узел по возможности должен работать с максимальной автономностью. Т.е. все основные сервисы (TimerService, InfoServer, DBServer)
 	должны быть запущены локально. Минимизирован объем данных передаваемых между узлами системы.
-	
+
 	\subsection subDBSave Система накопления информации
 		Хранение накопленной информации реализовано на основе БД. Для этого предусмотрен специальный процесс(сервис)
 	называемый DBServer, обладающий специальным интерфейсом, скрывающим детали работы с конкретной БД. Основная идея состоит
 	в том, что данный сервис запускается на каждом узле и все процессы, которым необходимо сохранять в БД информацию работают,
-	с всегда доступным локальным DBServer-ом. В свою очередь этот локальный DBServer при необходимости пересылает всю 
+	с всегда доступным локальным DBServer-ом. В свою очередь этот локальный DBServer при необходимости пересылает всю
 	информацию на другие узлы, на которых производится реальная запись в БД. Помимо это локальный DBServer может обеспечивать
 	буферизацию данных на время недоступности других узлов.
-		\sa \ref secDBServer	
+		\sa \ref secDBServer
 
 	\subsection subInfoServer Система оповещения
 		Некоторым алгоритмам требуются сообщать о том или ином событии оператору. Для этой цели служит InfoServer.
 	Идея заключается в следующем: Все объекты, которым необходимо послать информацию, работают с локальным зараннее известным
-	объектом InfoServer. Все сообщения посылаются ему. В его задачи входит переслать это сообщение объекту отображающему 
+	объектом InfoServer. Все сообщения посылаются ему. В его задачи входит переслать это сообщение объекту отображающему
 	информацию на экране, а также переслать сообщение на другие узлы(в случае необходимости). Помимо этого InfoServer пересылает
 	сообщения DBServer-у для сохранения их в БД. То что этот объект является локальным, гарантирует, что он будет
 	доступен...
 		\sa \ref secInfoServer
-	
+
 	\subsection subIO Ввод/вывод
-		Процессы ввода/вывода строятся на основе классов IOController и IONotifyController. 
-	  	\par IOController 
+		Процессы ввода/вывода строятся на основе классов IOController и IONotifyController.
+		\par IOController
 			Это унифицированный интерфейс для сохранения и получения информации о состоянии дискретных и
 	аналоговых датчиков.
 		\par IONotifyController
@@ -82,8 +81,8 @@
 
 	\subsection UniSetGraphics Графический интерфейс пользователя
 		...
-		
-	\subsection	UniDiag	Просмотр накопленной информации	
+
+	\subsection	UniDiag	Просмотр накопленной информации
 		Для большей универсальности слежение за работой системы, диагностирование и просмотр накопленной информации
 	сделаны в виде web-интерфейса написанного на PHP. \a в \a процессе \a разработаки...
 
@@ -91,9 +90,9 @@
 
 	\subsection subObjects Объекты, Менеджеры, Активаторы
 	\par Объекты (UniSetObject)
-		Объекты являются пасивными единицами, так как не могут функционировать без менеджера или активатора. Для того, чтобы объект 
+		Объекты являются пасивными единицами, так как не могут функционировать без менеджера или активатора. Для того, чтобы объект
 		мог принимать сообщения и предоставлять свои функции другим объектам он должен быть зарегистрирован в менеджере объектов
-		(ObjectsManager) или напрямую в активаторе (ObjectsActivator) при помощи функции ObjectsManager::addObject(...). 
+		(ObjectsManager) или напрямую в активаторе (ObjectsActivator) при помощи функции ObjectsManager::addObject(...).
 	\par Менеджеры (ObjectsManager)
 		Менеджеры используются для управления сразу группой объектов, а также сами являются объектами и могут быть
 		зарегитстрированы в другом менеджере (или активаторе). Они тоже являются пасивными единицами, так как не могут функционировать без
@@ -102,7 +101,7 @@
 		Активатор предназначен для активизации объектов и менеджеров. Он обладает свойствами менеджера (позволяет регистрировать в себе
 		другие объекты и менеджеры) и свойствами объекта (может быть зарегистрирован в другом активаторе или менеджере). Обычно для
 		запуска достаточно одного активатора.
-	
+
 	\subsection subProcesses Процессы и потоки
 		Для активизации объектов должен быть создан хотя-бы один активатор. После вызова функции ObjectsActivator::run( thread ) он
 		активизирует свои подчиненные объекты. В зависимости от заданного параметра функции ObjectsActivator::run()
@@ -117,21 +116,17 @@
 		обработки старого. На время помещения или извлечения сообщения из очереди, очередь блокируется.
 		\par
 			Менеджер, так как сам является объектом, может самостоятельно функционировать по своему алгоритму, принимать сообщения,
-		предоставлять свои функции для удаленного доступа.			 
-		\par 
-			Если обобщить все выше сказанное то: в программе порождается поток для каждого объекта, и один для каждого активатора 
+		предоставлять свои функции для удаленного доступа.
+		\par
+			Если обобщить все выше сказанное то: в программе порождается поток для каждого объекта, и один для каждого активатора
 		(поток для "распихивания" приходящих сообщений по объектам). Хотя активатор может не порождать отдельного потока, а работать
 		в основном потоке программы. А также несколько потоков для orb.
-			
-			
 
-	
-	
   \section secResourses Используемые библиотеки
 	- libmysqlclient, libtcpwrapGK 	- работа с MySQL
 	- linomniORB3(4) - реализация CORBA (удаленный доступ к объектам)
-	
-  
+
+
   \section secDirStruct Структура каталогов
 	- \b /conf - общие конфигурационные файлы библиотеки UniSet
 	- \b /Documents - документация к библиотеке
@@ -141,5 +136,5 @@
 	- \b /src - сс-файлы
 	- \b /Tests - отладочные и тестовые программы
 	- \b /Utilities - вспомогательные утилиты входящие в состав UniSet
-	  
+
 */

docs/DocPages/depends.dox

@@ -2,7 +2,9 @@
  \page DependsPage Зависимости между датчиками
 
 	Механизм зависимостей реализован в классе IOController.
-	В configure.xml настривается 
+
+	Пример записи "зависимости" в configure.xml:
+\code
 	<item textname="...." iotype="..." .../>
 		<consumers>
 		<consumers>
@@ -11,7 +13,7 @@
 			<depend name="Sensor2" filter2="val1" />
 		</depends>
 	</item>
-	
+\endcode
 	При считывании конф. файла можно задавать фильтры.
 	
 	

docs/DocPages/mainpage.dox

@@ -5,9 +5,7 @@
 
     \section MainSection Оглавление
  
-		- \ref CommitPage
+		- \ref CommonPage
 		- \ref page_Concept
 		- \ref UniSetLibStylePage
-		- \ref DebugPage
 */  
-