Разработка службы Windows "Контроль приложений" - Программирование, компьютеры и кибернетика курсовая работа

Главная

Программирование, компьютеры и кибернетика
Разработка службы Windows "Контроль приложений"

Разработка на языке C++ службы, осуществляющей контроль набора выполняющихся приложений. Проектирование, кодирование, отладка, тестирование и сопровождение службы Windows. Взаимодействие службы и приложения. Интерактивность разрабатываемой службы.


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
3.3 Взаимодействие службы и приложения
Разработка службы Windows: «Контроль приложений», осуществляющей контроль набора выполняющихся приложений и, возможно, управление ими. Кроме разработки службы, необходимо разработать приложение, которое будет осуществлять управление этой службой.
Целью данного курсового проекта является развитие и закрепление навыков разработки системных приложений.
Объект проектирования в данной работе - служба Windows: «Контроль приложений».
Для более полного понимания объекта рассмотрим определения службы.
Служба Windows (англ. Windows Service, сервисы) - приложения, автоматически запускаемые системой при запуске Windows и выполняющиеся вне зависимости от статуса пользователя [1].
Служба - это Windows-приложение, содержащая дополнительную инфраструктуру, которая позволяет ServiceControlManager (SCM) - компоненту, работающему на всех windows-машинах, - управлять этим приложением [2].
Данный программный продукт разрабатывался на языке C++ с использованием среды разработки Builder C++ XE2, позволяющей оптимизировать процесс его создания.
Согласно заданию необходимо создать приложение, осуществляющие контроль приложений, но в задании не указаны конкретные требования по реализации данного приложения. Следовательно, разработчик данного программного продукта сам решает какой язык программирования выбрать и как будет выглядеть готовый программный продукт (его функции).
Для реализации данного проекта был выбран язык С++, так как в наличии имеется среда разработки, и соответствующие знания данного языка.
Реализация службы возможна в двух вариантах:
2) с использованием встроенного класса vcl TService в Builder C++ XE2.
Использование 2-го варианта наиболее оптимально, так как работа с сервисом значительно упрощается.
Рассмотрим необходимость интерактивности разрабатываемой службы. Интерактивные службы - службы, осуществляющие взаимодействие с пользователем. Службы предназначены для непрерывной работы в отсутствии пользователей, поэтому дожидаться, пока оператор (пользователь) нажмёт «OK», можно очень долго. Но, тем не менее, возможности существуют. Поэтому постараемся избежать интерактивности в разрабатываемой службе.
В задании указано, что помимо самой службы необходимо разработать приложение, которое будет осуществлять управление этой службой. Под управлением подразумевается установка, удаление, запуск и остановка непосредственно разрабатываемой службы.
Существуют два варианта реализации приложения:
1) графическое приложение с использованием визуальных компонент;
2) консольное приложение, работающее с командной строкой.
В среде разработке Builder C++ XE2 возможна реализация обоих вариантов, но исходя из соображений, что обычный пользователь редко занимается установкой служб и их запуском самостоятельно, то выберем консольный вариант реализации.
Для удобства использования будет разработана система меню, удобная в использовании и включающая в себя справку.
Основной целью данного этапа является получение проектных решений.
На первом этапе проектирования рассмотрим саму службу.
Определим функционал разрабатываемого сервиса:
1) создание лог файла, в который будут заноситься сведенья о запушенных процессах. При запуске и завершении процесса добавляется соответствующая запись;
2) при бездействии операционной системы запускать дефрагментацию основного раздела жесткого диска.
Существуют два варианта подхода в проектировании службы.
Вариант первый: стартует служба, начинает что-то делать, время от времени уведомляя систему о своём состоянии, потом служба останавливается.
Вариант второй: стартует служба, создаёт рабочие потоки. По уведомлению от системы потоки останавливаются и служба выключается.
Обычно в службах используется второй вариант, поэтому остановимся именно на этом варианте.
Для формирования лога необходимо создать структуру, в полях которой будут храниться данные о процессе (время создания/завершения, идентификатор (pid), имя процесса, указатель процесса), передаваемую в качестве параметра в функцию записи в лог файл.
Сам процесс формирования лог файла происходит в несколько этапов:
1) служба получает список запушенных процессов в данный момент;
2) сверяет со списком запущенных процессов, полученным ранее, если существуют процессы, отсутствующие в данном списке, затем происходит заполнение структуры данных о процессе и добавление в этот список и вызов функции формирования записи в лог файле о запуске процесса;
3) поиск в списке, полученном во втором пункте, процессов, которые отсутствуют в списке из первого пункта и формирование записи о завершении данного процесса, удалении его из списка.
Сам процесс записи в лог файл будет осуществляться с использованием потоков.
Для определения бездействия системы необходимо выяснить загрузку процессора, если она достаточно мала, то запускается встроенный дефрагментатор системы Windows.
На втором этапе рассмотрим управляющие приложение.
Данное приложение необходимо для установки, удаления службы и ее настройки во время установки.
Для управления сервисами в Windows существует Service Сontrol Manager (SCM). Для корректного управления службой при ее модификации или смене состояний необходимо каждый раз сначала получать указатель SCM и лишь затем указатель самой службы. Закрытие указателей происходит в обратном порядке.
Меню данного приложения можно реализовать в виде бесконечного цикла while c использованием условной конструкции switch предусматривающая возможность выхода из данного цикла. В данном меню необходимо будет реализовать 5 пунктов:
3) запуск и завершение работы сервиса;
4) помощь по использованию приложения;
В первом пункте необходимо предусмотреть возможность ввода ключей для выбора функционала и проверку на правильность их ввода.
Основной целью данного этапа является реализация программного продукта.
При создании проекта службы были автоматически созданы два метода:
TServiceController __fastcall TControlProcess::GetServiceController(void)
return (TServiceController) ServiceController;
void __stdcall ServiceController(unsigned CtrlCode)
ControlProcess->Controller(CtrlCode);
Эти два метода никогда изменяться не будут, так как за ними скрывается процесс взаимодействия с SCM менеджером.
Согласно проектному решению в основном потоке службы осуществляется только взаимодействие с SCM, а функционирование службы происходит в созданном ею потоке.
Для создания потока воспользуемся встроенным в Builder C++ XE2 классом TThread. Создадим потомка данного класса TSparkyThread.
class TSparkyThread: public TThread {
void __fastcall Execute();/*главным методом объекта TThread. В теле метода должен содержаться код, который представляет собой программу потока*/
fastcall TSparkyThread(bool CreateSuspended); /*конструктор созданого класса */ };
Win32 предоставляет несколько способов перечисления запущенных процессов:
с помощью библиотеки Process Status Helper (PSAPI);
с помощью недокументированной функции ZwQuerySystemInformation;
с использованием интерфейсов Windows Management Instrumentation.
Был выбран первый вариант, т.к для перечисления процессов библиотека PSAPI предоставляет функцию EnumProcesses, которая возвращает массив идентификаторов запущенных процессов, и в отличии от других методов не извлекается избыточная информация о процессах, а необходимая информация извлекается с использованием указателей процессов.
__out DWORD *pProcessIds,//указатель на массив идентификаторов
__out DWORD *pBytesReturned//число возвращенных байтов
Для хранения информации о процессах создадим структуру ProcesInfo следующего вида:
DWORD PID; //идентификатор процесса
HANDLE hProcess; //указатель процесса
TCHAR szProcessName[MAX_PATH]; //имя процесса
SYSTEMTIME ST[2]; // время создания и завершения
Для сохранения списка используем ассоциативный массив (map):
typedef map ProcessList;
где ключом является идентификатор процесса, а хранимой информацией структура ProcesInfo.
Отслеживание запуска и завершение программы осуществляется согласно решению, полученному на этапе проектирования. Связи с этим, в потоке, создающемся при запуске службы, объявим два ассоциативных массива: ProcessList Old и ProcessList New.
Для заполнения структуры ProcesInfo создадим функцию:
void FillingProcesInfo(ProcesInfo &PrInfo,DWORD &aProcesses);
Параметрами, передаваемыми в данную функцию, являются сама структура и идентификатор процесса(PID), который будет позже сохранен в поле структуры. Указатель процесса может быть получен при помощи стандартной функции OpenProcess
__in DWORD dwDesiredAccess, // флаг доступа
__in BOOL bInheritHandle, //параметр дескриптора наследования
__in DWORD dwProcessId // идентификатор процесса
dwDesiredAccess - устанавливает уровень доступа к объекту процесса. Этот параметр может состоять из одного нескольких прав доступа к процессу. Из всех возможных были выбраны следующие параметры:
1) PROCESS_QUERY_INFORMATION - необходим, чтобы извлечь некоторую информацию о процессе;
2) PROCESS_VM_READ - необходим, чтобы читать память в процессе, используя функцию ReadProcessMemory.
Выбраны именно эти параметры, так как для того, чтобы узнать имена процессов, нужно вызвать EnumProcessModules и GetModuleBaseName.
EnumProcessModules перечисляет все модули процесса, а GetModuleBaseName просто возвращает имя модуля. Данные права доступа необходимы функции PSAPI EnumProcessModules, с помощью которой извлекается имя процесса.
__in HANDLE hProcess, //дескриптор процесса
__out HMODULE *lphModule, // Массив, который получает список
__in DWORD cb, // Размер массива lphModule, в байтах.
__out LPDWORD lpcbNeeded /*Число байтов, требуемых сохранить
все дескрипторы модуля в массиве lphModule. количество байт*/
__in HANDLE hProcess,// дескриптор процесса
__in_opt HMODULE hModule, /* Дескриптор к модулю. Если этот параметр - NULL, эта функция возвращается, имя процесса*/
__out LPTSTR lpBaseName, /* Указатель на буфер, который получает базовое имя модуля*/
__in DWORD nSize // Размер буфера lpBaseName, в символах.
Время создания и завершения процесса узнается при помощи функции GetProcessTimes.
Время работы процессора можно вычислить по следующей формуле:
Для получения этих временных характеристик воспользуемся
NTSTATUS WINAPI NtQuerySystemInformation (
__ in SystemInformationClass SYSTEM_INFORMATION_CLASS,
/* Одно из значений SYSTEM_INFORMATION_CLASS, которые указывают на вид информации о системе, которая будет получена.*/
__ inout PVOID SystemInformation,/* Указатель на буфер, который получает требуемую информацию. Размер и структура этой информации изменяются в зависимости от значения параметра SystemInformationClass:*/
__ in SystemInformationLength ULONG,
В качестве первого параметра используем SystemProcessorPerformanceInformation, который возвращает массив структур SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION, один для каждого процессора, установленного в системе.
Для второго параметра определим структуру:
struct_SYSTEM_PROCESSOR_PERFORMANCE_INFORMATION {
LARGE_INTEGER IdleTime; /* количество времени, которое система была неактивна */
LARGE_INTEGER KernelTime;/* количество времени, которое система потратила выполнение в Привилегированном режиме (включая все потоки во всех процессах, на всех процессорах)*/
LARGE_INTEGER UserTime;/* количество времени, которое система потратила выполнение в Непривилегированном режиме (включая все потоки во всех процессах, на всех процессорах)*/
Таким образом, возможно определить загрузку одного процессора. В современных компьютерах не редко встречается многопроцессорная архитектура, поэтому бездействие системы можно определить как некое суммарное число бездействия каждого из процессоров.
Запускать дефрагментацию постоянно во время простоя неэффективно, так как при длительном бездействии процесс дефрагментации будет запушен несколько раз подряд, что повысит энергопотребление и загрузку центрального процессора, что не очень хорошо особенно для ноутбуков которые не были подключены к сети питания и работают от внутреннего источника - аккумуляторной батареи ресурс которой ограничен. К тому же помимо нашей службы в фоновом режиме может работать антивирус, проверяющий файловую систему во время бездействия ОС, в то время как наши действия снизят эффективность проверки и увеличит продолжительность данного действия.
Поэтому добавим в нашу службу компонент таймер. В свойствах данного компонента укажем время срабатывания 12 часов, который будет активировать флаг дефрагментации в службе, при активации которого возможен запуск дефрагментации.
Для установки и удаления службы необходимо получать дескриптор SCM. Для этого воспользуемся OpenSCManager(
SC_MANAGER_ALL_ACCESS); // полный доступ
Данная функция как раз и возвращает данный дескриптор.
Установка службы осуществляется вызовом функции CreateService, которая создаёт объект сервиса и добавляет его в базу данных менеджера управления сервисами (SCM).
SC_HANDLE hSCManager, /*Дескриптор базы данных менеджера управления сервисами (SCM)*/
LPCTSTR lpServiceName, /* Указатель на строку (завершающуюся нулём), содержащую имя создаваемого сервиса. Максимальная длина строки не должна превышать 256 символов. В имени сервиса нельзя использовать символы "/" и "\". */
LPCTSTR lpDisplayName, /* Указатель на строку (завершающуюся нулём), содержащую имя, которое будет отображаться в пользовательских приложениях */
DWORD dwDesiredAccess, /* Тип доступа к сервису. Перед тем, как разрешить запрашиваемый доступ, система проверит привелегии вызвавшего процесс*/
DWORD dwServiceType, /* Тип сервиса */
DWORD dwStartType, /* Тип запуска сервиса*/
DWORD dwErrorControl, /* Степень контроля ошибок, а так же действия, которые будут предприняты, в случае ошибки запуска сервиса. */
LPCTSTR lpBinaryPathName, /* Указатель на строку (заканчивающуюся нулём), которая содержит полный путь к исполняемому файлу сервиса. */
LPCTSTR lpLoadOrderGroup, /* Указатель на строку (заканчивающуюся нулём), которая содержит имя группы, членом которой является сервис. Если сервис не является членом группы, то можно указать NULL или пустую строку. */
LPDWORD lpdwTagId, /* казатель на переменную, в которую будет записан уникальное значение тэга, которое идентифицирует группу, указанную в параметре lpLoadOrderGroup. Если Вы не собираетесь менять существующий тэг, то укажите в этом параметре NULL. */
LPCTSTR lpDependencies, /* Указатель на массив (завершающийся двумя нулями) имён (разделённых нулями) сервисов или групп сервисов, которые система должна запустить до запуска этого сервиса. Если сервис не зависит от других сервисов, то в этом параметре нужно указать NULL или пустую строку.*/
LPCTSTR lpServiceStartName, /* Указатель на строку (завершающуюся нулём), которая содержит имя аккаунта, с правами которого будет запущен сервис. */
LPCTSTR lpPassword/* Указатель на строку (заканчивающуюся нулём), которая содержит пароль к аккаунту, указанному в параметре lpServiceStartName. Если аккаунт не имеет пароля либо если сервис запускается с правами LocalService, NetworkService, или системы, то можно указать на пустую строку*/
Для удобства использования, в качестве второго и третьего параметра, передадим одну и ту же строку содержащую имя сервиса.
Четвертым параметром передадим права доступа SERVICE_ALL_ACCESS, так как для работы со службой нужны права администратора.
Пятым параметром передадим значение SERVICE_WIN32_OWN_PROCESS, что означает что служба запускается в своем собственном процессе.
Следующим параметром передадим SERVICE_AUTO_START, благодаря которому сервис запускается автоматически диспетчером управления службами в ходе запуска системы.
Седьмым параметром зададим степень контроля ошибок SERVICE_ERROR_NORMAL. Программа запуска регистрирует ошибку и показывает всплывающее окно сообщения, но продолжает операцию запуска.
Восьмым параметром является путь расположения исполняемого файла службы - "C:\\PrControlProcess.exe".
Оставшимся параметрам присвоим значение NULL.
Сами действия, производимые над службой, осуществляются с помощью следующей функции:
__in SC_HANDLE hSCManager,//дескритор scm
__in LPCTSTR lpServiceName,// имя службы
__in DWORD dwDesiredAccess// права доступа
При разработке сервиса использовались следующие права доступа:
SERVICE_START - требует вызвать функцию StartService, чтобы запустить службу;
SERVICE_STOP - требует вызвать функцию ControlService, чтобы остановить службу;
3) DELETE - требует вызвать функцию ControlService для удаления службы.
3.3 Взаимодействие службы и приложения
Перед установкой службы приложение просит пользователя ввести ключи, если пользователь ввел их корректно, тогда происходит процесс установки службы, следующим действием является передача службе этих ключей.
Так как используется vcl служба, то передать напрямую параметры не удастся, так основной поток службы скрыт в классе TService. Но существует альтернативный метод передачи ключей через реестр.
SCM хранит базу данных служб в ключе реестра:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
Удобно все параметры службы хранить в ключе:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Имя-Службы(свойство Name)\Parameters.
Служба может считывать свои параметры оттуда при запуске, а приложение-конфигуратор -- писать в этот ключ настройки [3].
Однако на этом не остановимся, и упростим работу службы, добавив в ней флаг mode. Именно его значение мы и будем записывать в реестр в ветку:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Имя-Службы(свойство Name)\mode.
Для этого воспользуемся следующими функциями: RegCreateKeyEx и RegSetValueEx. Первая функция предназначена для создания ветви реестра, если она отсутствует, а вторая для записи определенного значения.
HKEY hKey, // дескриптор открытого ключа
LPCTSTR lpSubKey, // адрес имени подключа
LPTSTR lpClass, // адрес строки класса
DWORD dwOptions, // флаг особых опций
REGSAM samDesired, // желаемый доступ безопасности
LPSECURITY_ATTRIBUTES lpSecurityAttributes, // адрес структуры ключа безопасности
PHKEY phkResult, // адрес буфера для открытого ключа
LPDWORD lpdwDisposition // адрес буфера характерного значения);
LPCTSTR lpValueName,// адрес имени установливаемого значения
CONST BYTE *lpData, // адрес данных для установки
Считывание значение реестра службой осуществляется RegQueryValueExA.
LPDWORD reserved, // зарезервировано
создание лога и запуск дефрагментации;
Выбор режима в службе осуществляется с помощью конструкции switch.
Помимо этого в реестре создается ключ Description, содержащий описание службы.
Описание функций были взяты с официального сервера корпорации майкрософт [4].
Кодом программы представлен в Приложениях А,Б,В.
Отладка и тестирование служб очень трудоемкий процесс. Он значительно отличается от отладки обычного приложения. Есть несколько вариантов выхода из данной ситуации. Воспользуемся наиболее простым. Суть его в том, что проверить функциональность основного кода службы можно и в приложении, если ошибок не обнаружено, то перенести его в службу и затем проверять ее функционирование. Как правило, при таком подходе на последней стадии ошибок не возникает.
Проведем планирование нашего тестирования.
На первом этапе проверим правильность работы приложения по установке и удалению службы. На втором этапе проверим ее функционирование. И на последнем проверим правильность обработки неправильного ввода пользователя.
Приступим к первому этапу тестирования:
Рисунок 1. Список служб до установки службы
Попробуем установить службу при помощи разработанного приложения
Посмотрим вновь список установленных служб:
Рисунок 3. Список служб после установки сервиса
В перечне служб появилась новая служба ControlProcess- это и есть установленная служба, то есть в процессе установки ошибок обнаружено не было.
Теперь удалим нашу службу, используя консоль, и посмотрим список установленных сервисов:
Рисунок 4. Список служб после удаления
Службы ControlProcess больше нет в данном списке, что очень наглядно отображает правильность функционирования.
Установим сервис с ключом /l, что обеспечивает только запись в лог файл информации о процессах. И запустим ее при помощи консольного приложения:
Рисунок 5. Запуск службы из приложения
Проверим функционирование службы наличием лог файла в C:\WINDOWS\system32
Рисунок 6. Содержимое каталога C:\WINDOWS\system32
Просмотрим содержимое данного файла
Для проверки правильности работы запустим и закроем браузер internet explorer
Рисунок 8. Содержимое лог файла с записями о запуске и закрытии internet explorer-а
Как видно были добавлены соответствующие записи.
Теперь проверим правильность работы запуска дефрагментации с помощью разработанной службы. Для этого переустановим службу с параметрами запуска дефрагментации и созданием лога
Рисунок 9. Содержимое лог файла с записями о запуске и завершении дефрагментатора
Из данного рисунка отчетливо видно запуск процесса дефрагментации и его завершение.
Проверка режима дефрагментации осуществляться не будет, так как там происходит идентичный вызов функций, за исключением функций создания лог файла.
Отметим так же возможность пользователя запускать и завершать работу службы из SCM.
Проверим приложение на правильность ввода ключей
Рисунок 10. Проверка на ввод некорректных ключей
При вводе некорректных ключей выводиться соответствующее предупреждение.
На данный момент служба не корректно ведет себя в ОС Windows 7 и Windows Vista планируется устранить данный недостаток в следующей версии.
Скопируйте исполняемый файл PrControlProcess в корень диска С:\.
Запустите консольное приложение menu.exe с правами администратора.
Для установки службы выберете первый пункт меню. Перед установкой службы введите ключи, более подробно ключи описаны в разделе help. Если ключи не были введены, тогда служба ставиться с параметрами по умолчанию (включены все функции)
Для запуска или завершения работы службы воспользуйтесь третьим пунктом меню или SCM.
Удаление службы происходит при выборе второго пункта. После успешного удаления службы удалите исполняемый файл из корня диска С:\.
Полученный программный продукт может использоваться в учебных заведениях, в компьютерных клубах, в местах, где пользование компьютерами общедоступно и просто на компьютере пользователя. В общественных заведениях данная служба поможет проследить какие приложения пользуются большой популярностью (для компьютерного клуба), а в учебных заведениях вести контроль за действиями пользователей. Для локального компьютера эта служба будет полезна тем, что можно выявить скрытые процессы, которые запускаются во время работы компьютера, что явно помогает обнаруживать вредоносные программы.
Недостаток разработанной службы заключается в том, что она рассчитана на работу в Windows XP и не работает в Windows 7 и Windows Vista. Это вызвано тем, что функции PSAPI не совсем корректно работают на новой платформе.
В процессе выполнения курсового проекта, были закреплены и углублены теоретические знаний, также приобретены практические умения и навыки в самостоятельном проектировании программных продуктов и составлении документов подобного рода.
Проектирование, кодирование и отладка службы Windows: "Контроль приложений", осуществляющей контроль набора приложений и управление ими; разработка приложения, управляющего этой службой. Взаимодействие службы и приложения; тестирование и сопровождение. курсовая работа [1,1 M], добавлен 22.05.2013
Проектирование службы Windows и приложения для управления этой службой, которое позволит контролировать данные приложения - запускать и завершать определенные процессы по желанию пользователя через определенные промежутки времени. Инструкция по установке. курсовая работа [2,8 M], добавлен 05.01.2013
Службы Windows — приложения, автоматически включаемые системой при запуске. Характеристика концепции демонов в Unix. Диспетчер автоподключений удаленного доступа, логических дисков, отгрузки, очереди печати. Организация доступа к HID-устройствам. контрольная работа [112,7 K], добавлен 01.03.2011
Общая характеристика Microsoft Windows Server 2008: особенности, гибкость, защита, контроль. Усовершенствования операционной системы: Server Core, службы терминалов, Windows PowerShell, самовосстанавливающаяся NTFS, Server Manager, улучшение надежности. реферат [452,3 K], добавлен 15.12.2009
Архитектура IT сервисов, роль инженеров поддержки в обеспечении доступности систем. Структура многоуровневой службы технической поддержки. Моделирование мониторинга элементов информационной инфраструктуры. Тестирование сценариев запуска, остановки службы. дипломная работа [1,4 M], добавлен 03.07.2017
Проектирование и отладка Windows-приложений для работы с внешними источниками данных. Функциональная блок-схема взаимодействия программных модулей. Описание связей между таблицами. Тестирование программного средства. Требования к техническому обеспечению. курсовая работа [2,7 M], добавлен 17.05.2011
Проектирование системы управления базами данных. Особенности реализации в MS SQL. Разработка пользовательского интерфейса. Тестирование и отладка приложения. Руководство пользователя и системного администратора. Анализ и методы разработки приложений. курсовая работа [867,9 K], добавлен 16.07.2013
Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д. PPT, PPTX и PDF-файлы представлены только в архивах. Рекомендуем скачать работу .

© 2000 — 2021



Разработка службы Windows "Контроль приложений" курсовая работа. Программирование, компьютеры и кибернетика.
Реферат по теме Развіццё феадальнай гаспадаркі на Беларусі ў ХІІІ–ХVІІ стагоддзяў
Реферат по теме Материя как временной резонанс эфира. Гипотеза времени
Курсовая Работа На Тему Становление И Развитие Мерчандайзинга В России
Реферат: Великое княжество Литовское и первые литовские князья
Дипломная Работа На Тему Инновационно-Инвестиционный Процесс В Переходной Экономике России
Проектные Организации Реферат
Реферат по теме Живопись
Машинное Обучение Эссе
Реферат: Поняття мотивації та класифікація мотиваційних теорій
Курсовая Работа На Тему Реализация Генетических Алгоритмов Нейрокомпьютерами
Сочинение На Тему Каким Человеком Нужно Быть
Контрольная работа по теме Сегменты рынка недвижимости и их характеристика
Дипломная работа по теме Выбор технических средств для системы сбора данных и управления и разработка программы на базе SCADA 'Genie'
Общество Как Целостная Система Реферат
Реферат: Предмет і значення дисципліни Основи екології Наукові основи раціонального природокористування
Реферат Про Компас
Как Правильно Делать Сноски В Курсовой Работе
Реферат: История культуры Казахстана
Сочинение По Русскому Мой Любимый Предмет
Спор Базарова И Кирсанова Кратко Для Сочинения
Розвиток культури ХХ століття - Культура и искусство презентация
Нарушение звукопроизношения у умственно отсталых детей - Педагогика дипломная работа
Вьетнам в XVI-XIX вв. - История и исторические личности курсовая работа