Разработка информационной подсистемы тестирования встроенного программного обеспечения PLC-модемов для ЗАО "КИЭП "Энергомера" - Дипломная работа

Предпроектное обследование ЗАО "КИЭП "Энергомера", г. 1.1 Постановка задачи предпроектного обследования.2.2 Организационная структура предприятия 1.2.3 Организационно-управленческая модель 1.3 Технические и программные средства ЭИВТ предприятия 1.3.1 Задачи, решаемые с использованием средств ЭИВТ 1.3.5 Организация доступа к мировым информационным сетям2.1 Обоснование выбора программного обеспечения 2.2 Проектирование и разработка БД 2.2.2 Определение зависимостей между сущностями 2.2.3 Определение атрибутов сущностей, создание первичных и внешних ключей 2.3 Проектирование и разработка модуля тестирования и сбора данных3.1 Общие сведения о программном продукте 3.2 Функциональное назначение программного продукта 3.3 Описание логической структуры программного продукта 3.4 Требования к техническому обеспечению 3.4.4 Требования к наличию свободного места на жестком диске4. Технико-экономическое обоснование проекта4.2 Трудоемкость выполняемых работ5.1 Общая характеристика опасных, вредных факторов на рабочем месте оператора информационной подсистемыОАО "Концерн Энергомера" выпускает широкий спектр оборудования и программного обеспечения для создания автоматизированных систем коммерческого учета электроэнергии (АСКУЭ) в любом секторе электроэнергетики, ЗАО "КИЭП "Энергомера", которое является филиалом ОАО "Концерн Энергомера", принимает активное участие в разработках АСКУЭ. Для передачи данных по технологии PLC используются PLC-модемы, от надежности и качества работы которых, зависит конечный результат процесса сбора данных, поэтому, перед использованием на объектах АСКУЭ, PLC-модемы должны быть тщательно протестированы, для чего и разрабатывается информационная подсистема тестирования встроенного программного обеспечения PLC-модемов. В первом разделе пояснительной записки описаны: общая структура предприятия, задачи предприятия, структура ЛВС предприятия, информационные системы предприятия, выявлены проблемные ситуации и выбрана одна для решения. В качестве основной информационной системы рассматривается информационная система отслеживания ошибок в программном обеспечении, и будут проанализированы следующие характеристики: - функции, выполняемые системой; Организационно-управленческая модель предприятия представлена в виде таблицы-матрицы (таблица 1.4) связывающей между собой ответственных лиц (подразделения) и номера задач, представленными в таблице 1.3.Каждое тестирование проводится от имени пользователя, которого представляет сущность User, так же пользователи имеют разные права доступа к системе, поэтому выделена сущность USERTYPE, которая представляет тип пользователя (администратор, просто пользователь и другие). Наименование атрибута Тип поля NULL nncl_test_id nncl_test_mode begin end command_count error_count no_answer_count user_login end_code input_data INT(11) INT(11) DATETIME DATETIME INT(11) INT(11) INT(11) VARCHAR(30) INT(11) INT(11) Нет Нет Нет Нет Нет Нет Нет Нет Нет Нет Наименование АТРИБУТАТИП ПОЛЯNULL nncl_log_id nncl_test nncl_log_file nncl_log_type description INT(11) INT(11) VARCHAR(255) INT(11) VARCHAR(255) Нет Нет Нет Нет Да Ключи таблицы: end_code_id (первичный ключ), по полю end_code_id; Наименование АТРИБУТАТИП ПОЛЯNULL at_log_id at_test at_log_type at_log_file description INT(11) INT(11) INT(11) VARCHAR(255) VARCHAR(255) Нет Нет Нет Нет Да Ключи таблицы: at_log_id (первичный ключ), по полю at_log_id; Название процедуры Описание процедуры get_at_logs_list Возвращает список журналов, "прикрепленных" к тестам AT-команд get_at_test_info Возвращает информацию о выбранном тесте AT-команд get_at_tests_list Возвращает список тестирований AT-команд get_end_codes_list Возвращает список кодов завершения get_log_types_list Возвращает список типов журналов get_nncl_logs_list Возвращает список журналов, "прикрепленных" к тестам команд протокола NNCL get_nncl_test_info Возвращает информацию о выбранном тесте команд протокола NNCL get_nncl_tests_list Возвращает список тестов команд протокола NNCL get_test_modes_list Возвращает список режимов тестирования команд протокола get_user_info Возвращает информацию о выбранном пользователе get_users_list Возвращает список пользователей attach_file Добавляет файл в базу данныхСистема предназначена для автоматизации процесса тестирования встроенного программного обеспечения PLC-модемов, предварительной обработки результатов тестирования, сохранения результатов тестирования в базу данных и виде отчетов, предоставление пользователям необходимой информации о проведенных тестах, для базовой настройки PLC-модемов. Основная информация о тестах команд протокола NNCL, предоставляемая пользователям: тип теста, режим теста, время начала тестирования, время завершения тестирования, результат завершения тестирования, информация о пользователе (проводившем тестирование), количество запросов, количество ошибок, процент ошибок, количество неполученных ответов, процент неполученных ответов. Основная информаци

. Предпроектное обследование ЗАО "КИЭП "Энергомера", г. Ставрополь. Формулировка задач проектирования

1.1 Постановка задачи предпроектного обследования

1.1.1 Объект и методы проведения предпроектного обследования

1.1.2 Программа проведения обследования

1.1.3 План-график выполнения работ обследования

1.2 Характеристика предприятия ЗАО "КИЭП "Энергомера"

2. Разработка информационной подсистемы PLCTESTER

2.1 Обоснование выбора программного обеспечения

2.2 Проектирование и разработка БД

2.2.1 Определение сущностей

2.2.2 Определение зависимостей между сущностями

2.2.3 Определение атрибутов сущностей, создание первичных и внешних ключей

2.2.4 Создание физической модели данных

2.2.5 Разработка хранимых процедур

2.2.6 Создание пользователей и распределение привилегий

2.3 Проектирование и разработка модуля тестирования и сбора данных

2.3.1 Проектирование модуля

2.3.2 Разработка модуля TNNCL.dll

2.3.3 Разработка модуля TAT.dll

2.3.4 Разработка модуля PLCTESTER.exe

2.4 Разработка web-приложения3. Информационная подсистема PLCTESTER

3.1 Общие сведения о программном продукте

3.2 Функциональное назначение программного продукта

3.3 Описание логической структуры программного продукта

3.4 Требования к техническому обеспечению

3.4.1 Общие требования

3.4.2 Требования к центральному процессору

3.4.3 Требования к оперативному запоминающему устройству

3.4.4 Требования к наличию свободного места на жестком диске

3.4.5 Требования к монитору

3.4.6 Прочие требования

3.5 Вызов программы

3.5.1 Установка ПО

3.5.2 Запуск программы

3.6 Входные данные

3.7 Выходные данные

3.8 Описание тестовых прогонов

3.8.1 Общие сведения

3.8.2 Тестирование модуля PLCTESTER

3.8.3 Тестирование web-приложения4. Технико-экономическое обоснование проекта5. Безопасность и экологичность проекта

5.1 Общая характеристика опасных, вредных факторов на рабочем месте оператора информационной подсистемы

5.2 Обеспечение безопасности на рабочем месте оператора информационной подсистемы

5.3 Расчет защитного зануления на отключающую способностьНа этапе предпроектного обследования предприятия были изучены и проанализированы: организационная структура (предприятие имеет сложную, иерархическую структуру);

модель управления предприятием;

информационные системы, функционирующие на предприятии;

локальная сеть предприятия и прочие программно-технические средства.

Выявлены проблемные ситуации и найдены возможные варианты их решений. Принято решение разработать информационную подсистему тестирования PLC-модемов, для решения проблемной ситуаций (недостаточной автоматизации).

2. РАЗРАБОТКА ИНФОРМАЦИОННОЙ ПОДСИСТЕМЫ PLCTESTER

2.1 Обоснование выбора программного обеспечения

Информационная подсистема тестирования встроенного программного обеспечения PLC-модемов (диаграмма размещения в приложении Б) состоит из трех основных модулей: - базы данных;

- модуля тестирования и сбора данных (результатов тестирований);

web-приложения (для передачи обработанной информации из базы данных пользователю).

К тому же, некоторые модули являются составными, для проектирования и разработки каждого из них необходимо использовать различные инструментальные средства.

В качестве СУБД выбрана MYSQL, это свободная, кроссплатформенная система управления базами данных, MYSQL является собственностью компании Oracle Corporation, распространяется под GNU General Public License или под собственной коммерческой лицензией.

Гибкость СУБД MYSQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MYISAM, поддерживающие полнотекстовый поиск, так и таблицы INNODB, поддерживающие транзакции на уровне отдельных записей. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MYSQL постоянно появляются новые типы таблиц.

Обычно MYSQL используется в качестве сервера, к которому обращаются локальные или удаленные клиенты.

MYSQL является решением для малых и средних приложений.

Для разработки и администрирования базы данных выбраны следующие программные продукты: DBFORGE Studio for MYSQL (имеет и коммерческую и свободную лицензии), для ОС Windows;

MYSQL Administrator - кроссплатформенное средство для администрирования СУБД MYSQL;

PHPMYADMIN - web-приложение с открытым кодом, написанное на языке PHP и представляющее собой web-интерфейс для администрирования СУБД MYSQL, позволяет через браузер осуществлять администрирование сервера MYSQL, запускать команды SQL и просматривать содержимое таблиц и баз данных. Приложение пользуется большой популярностью у web-разработчиков, так как позволяет управлять СУБД MYSQL без непосредственного ввода SQL команд, предоставляя дружественный интерфейс.

Модуль тестирования и сбора данных является составным: PLCTESTER.exe (разрабатывается на платформе .NET, язык C#);

TAT.dll (разрабатывается на языке C/C );

TNNCL.dll (разрабатывается на языке C/C ).

Для реализации модуля PLCTESTER.exe выбрана интегрированная среда разработки SHARPDEWELOP - свободная среда разработки для C#, Visual Basic .NET, Boo, IRONPYTHON, IRONRUBY, F#, C .

Для разработки модулей TAT.dll и TNNCL.dll и web-приложения выбрана NETBEANS IDE - свободная интегрированная среда разработки приложений на языках программирования Java, JAVAFX, Python, PHP, JAVASCRIPT, C , Ада и ряде других.

Для разработки программ в среде NETBEANS IDE и для успешной инсталляции и работы самой среды NETBEANS IDE должен быть предварительно установлен Sun JDK или J2EE SDK подходящей версии. Среда разработки NETBEANS по умолчанию поддерживала разработку для платформ J2SE и J2EE. Начиная с версии 6.0 Netbeans поддерживает разработку для мобильных платформ J2ME, C (только g ), PHP и Ruby без установки дополнительных компонентов.

Проект NETBEANS IDE поддерживается и спонсируется компанией Oracle.

Однако разработка NETBEANS ведется независимо сообществом разработчиков-энтузиастов (NETBEANS Community) и компанией NETBEANS Org.

Для реализации и исполнения web-приложения выбраны язык программирования php и HTTP-сервер Apache.

Apache является свободным, кроссплатформенным ПО, поддерживает операционные системы Linux, BSD, Mac OS, Microsoft Windows, Novell NETWARE, BEOS.

Основными достоинствами Apache считаются надежность и гибкость конфигурации. Он позволяет подключать внешние модули для предоставления данных, использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках и т. д. Поддерживает IPV6.

В целом, выбор сделан в пользу свободного и кросплатформенного (где это необходимо) программного обеспечения. Целевой операционной системой для модуля тестирования и сбора данных выбрана Microsoft Windows, а СУБД и web-приложение могут работать и на других операционных системах (планируется дистрибутив Linux Debian 6.0, который считается одним из самых надежных дистрибутивов Linux, используемых в качестве операционных систем на серверных машинах).

2.2 Проектирование и разработка БД

2.2.1 Определение сущностей

Областью применения информационной подсистемы является тестирование PLC-модемов, и основной задачей, является удовлетворение конкретных информационных потребностей пользователей в рамках предметной области. Информационная подсистема тестирования PLC-модемов, в общем смысле, должна предоставлять информацию о проведенных тестах и их результатах, соответственно, одной из основных сущностей является сущность тест.

В системе, производятся тесты двух, принципиально разных типов: тестирование команд протокола NNCL;

тестирование AT-команд.

NNCL - Nero Network Control Level, протокол обмена ПК (или УСПД - устройством сбора и передачи данных) с PLC-модемом по последовательному порту. Этот протокол используется в управлении сетью из PLC-модемов, построенной на протоколе NNL (Nero Network Level).

Каждый тип теста будет представлен отдельной сущностью: NNCLTEST;

ATTEST.

Каждый тест, независимо от типа, должен проводиться, как минимум в двух режимах: режим функционального тестирования;

режим нагрузочного тестирования.

Сущность, описывающая режим тестирования - TESTMODE.

Результат теста представлен сущностью ENDCODE.

К каждому тесту может прилагаться дополнительная информация, например, в виде журналов, сущности: NNCLLOG и ATLOG.

Для разделения журналов на типы представлена сущность LOGTYPE.

Для тестирования команд протокола NNCL используются дополнительные входные данные, которые представлены сущностью NNCLINPUTDATA.

Каждое тестирование проводится от имени пользователя, которого представляет сущность User, так же пользователи имеют разные права доступа к системе, поэтому выделена сущность USERTYPE, которая представляет тип пользователя (администратор, просто пользователь и другие).

2.2.2 Определение зависимостей между сущностями

Зависимости между сущностями обычно представляют в виде ER-диагаммы (рисунок 2.1). ER-диаграмма представлена в нотации "Crow"s Foot". Данная нотация была предложена Гордоном Эверестом (англ. Gordon Everest) под названием Inverted Arrow ("Перевернутая стрелка"), однако сейчас чаще называемая Crow"s Foot ("Воронья лапа") или Fork ("Вилка").

Согласно данной нотации, сущность изображается в виде прямоугольника, содержащем ее имя, выражаемое существительным. Имя сущности должно быть уникальным в рамках одной модели. Имя сущности - это имя типа, а не конкретного экземпляра данного типа. Экземпляром сущности называется конкретный представитель данной сущности.

Рисунок 2.1 - ER-диаграмма базы данных в нотации "Crow"s Foot"

Диаграмма, на рисунке 2.1 , представлена в неполном виде, потому что на данном этапе моделирования важно показать связи между сущностями, а подробные описания сущностей будут представлены на более поздних этапах, в частности в приложении В. Все связи имею тип "один ко многим".

2.2.3 Определение атрибутов сущностей, создание первичных и внешних ключей

Сущность NNCLTEST имеет следующие атрибуты: nncl_test_id - первичный ключ;

begin - дата и время начала тестирования;

end - дата и время завершения тестирования;

input_data - входные данные для теста (внешний ключ);

nncl_test_mode - режим теста (внешний ключ);

command_count - количество отправленных команд;

error_count - количество ошибок;

no_answer_count - количество запросов, оставшихся без ответа;

end_code - код завершения (внешний ключ);

user_login - логин пользователя (внешний ключ).

Сущность ATTEST имеет следующие атрибуты: at_test_id - первичный ключ;

begin - дата и время начала тестирования;

end - дата и время завершения тестирования;

at_test_mode - режим теста (внешний ключ);

end_code - код завершения (внешний ключ);

user_login - логин пользователя (внешний ключ).

Сущность TESTMODE имеет следующие атрибуты: test_mode_id - первичный ключ;

test_mode_name - наименование типа тестирования;

description - описание;

nncl_only - принадлежность режима теста к типу теста.

Сущность ENDCODE имеет следующие атрибуты: end_code_id - первичный ключ;

end_code_name - наименование кода завершение;

description - описание.

Сущность NNCLLOG имеет следующие атрибуты: nncl_log_id - первичный ключ;

nncl_test - тест, к которому относится лог (внешний ключ);

nncl_log_file - прикрепляемый файл;

nncl_log_type - тип прикрепляемого файла (внешний ключ);

description - описание.

Сущность ATLOG имеет следующие атрибуты: at_log_id - первичный ключ;

at_test - тест, к которому относится лог (внешний ключ);

at_log_file - прикрепляемый файл;

at_log_type - тип прикрепляемого файла (внешний ключ);

description - описание.

Сущность LOGTYPE имеет следующие атрибуты: log_type_id - первичный ключ;

log_type_name - наименование;

description - описание.

Сущность NNCLINPUTDATA имеет следующие атрибуты: nncl_input_id - первичный ключ;

first_mac - MAC-адрес первого модема в списке тестировании;

last_mac - MAC-адрес последнего модема в списке тестировании;

host_mac - MAC-адрес host-модема, участвующего в тестировании;

Сущность User имеет следующие атрибуты: login - логин пользователя (первичный ключ);

password - пароль пользователя;

email - адрес электронной почты пользователя;

user_type - тип пользователя (внешний ключ);

first_name - имя пользователя;

second_name - фамилия пользователя;

third_name - отчество пользователя.

Сущность USERTYPE имеет следующие атрибуты: user_type_id - первичный ключ;

user_type_name - имя типа пользователя;

description - описание;

can_add - возможность добавлять информацию;

can_delete - возможность удалять информацию.

Функциональные зависимости представлены на рисунках 2.2 - 2.10.

Рисунок 2.2 - Функциональные зависимости между атрибутами сущности NNCLTEST

Рисунок 2.3 - Функциональные зависимости между атрибутами сущности TESTMODE

Рисунок 2.4 - Функциональные зависимости между атрибутами сущности ATTEST

Рисунок 2.5 - Функциональные зависимости между атрибутами сущности ENDCODE

Рисунок 2.6 - Функциональные зависимости между атрибутами сущности NNCLLOG

Рисунок 2.7 - Функциональные зависимости между атрибутами сущности LOGTYPE

Рисунок 2.8 - Функциональные зависимости между атрибутами сущности ATLOG

Рисунок 2.9 - Функциональные зависимости между атрибутами сущности NNCLINPUTDATA

Рисунок 2.10 - Функциональные зависимости между атрибутами сущностей USERTYPE и User

На основании выявленных функциональных зависимостей идентифицирующие атрибуты, которые в реляционной модели данных используются в качестве первичных ключей реляционных отношений, видны и однозначны.

2.2.4 Создание физической модели данных

В таблицах 2.1 - 2.9 представлены составы таблиц базы данных. Для каждого поля таблицы указан тип данных (столбец "Тип поля"). Для некоторых полей введен запрет на использование неопределенных значений (столбец "NULL"). Примечание - Если в столбце "NULL" указано значение "Нет", это означает, что данное поле, при заполнении таблицы в базе данных, не может иметь неопределенные значения, в противном случае поле может иметь неопределенные значения.

Таблица 2.1 - Состав таблицы NNCLTEST

Наименование атрибута Тип поля NULL nncl_test_id nncl_test_mode begin end command_count error_count no_answer_count user_login end_code input_data INT(11) INT(11) DATETIME DATETIME INT(11) INT(11) INT(11) VARCHAR(30) INT(11) INT(11) Нет Нет Нет Нет Нет Нет Нет Нет Нет Нет

Ключи таблицы: nncl_test_id (первичный ключ), по полю nncl_test_id;

FK_nncltest_endcode_end_code_id, по полю end_code;

FK_nncltest_user_login, по полю user_login;

FK_nncltest_nnclinputdata_nncl_input_id, по полю input_data;

FK_nncltest_testmode_test_mode_id, по полю nncl_test_mode.

Таблица 2.2 - Состав таблицы ATTEST

Наименование АТРИБУТАТИП ПОЛЯNULL at_test_id at_test_mode begin end end_code user_login INT(11) INT(11) DATETIME DATETIME INT(11) VARCHAR(30) Нет Нет Нет Нет Нет Нет

Ключи таблицы: at_test_id (первичный ключ), по полю at_test_id;

FK_attest_endcode_end_code_id, по полю end_code;

FK_attest_user_login, по полю user_login;

FK_attest_testmode_test_mode_id, по полю at_test_mode.

Таблица 2.3 - Состав таблицы TESTMODE

Наименование атрибута Тип поля NULL test_mode_id test_mode_name description nncl_only INT(11) INT(11) VARCHAR(255) BOOL Нет Нет Да Нет

Ключи таблицы: test_mode_id (первичный ключ), по полю test_mode_id.

Таблица 2.4 - Состав таблицы ENDCODE

Наименование АТРИБУТАТИП ПОЛЯNULL end_code_id end_code_name description INT(11) VARCHAR(50) VARCHAR(255) Нет Нет Да Ключи таблицы: end_code_id (первичный ключ), по полю end_code_id.

Таблица 2.5 - Состав таблицы NNCLLOG

Наименование АТРИБУТАТИП ПОЛЯNULL nncl_log_id nncl_test nncl_log_file nncl_log_type description INT(11) INT(11) VARCHAR(255) INT(11) VARCHAR(255) Нет Нет Нет Нет Да Ключи таблицы: end_code_id (первичный ключ), по полю end_code_id;

FK_nncllog_logtype_log_type_id, по полю nncl_log_type;

FK_nncllog_nncltest_nncl_test_id, по полю nncl_test.

Таблица 2.6 - Состав таблицы LOGTYPE

Наименование АТРИБУТАТИП ПОЛЯNULL log_type_id log_type_name description INT(11) VARCHAR(50) VARCHAR(255) Нет Нет Да Ключи таблицы: log_type_id (первичный ключ), по полю log_type_id.

Таблица 2.7 - Состав таблицы ATLOG

Наименование АТРИБУТАТИП ПОЛЯNULL at_log_id at_test at_log_type at_log_file description INT(11) INT(11) INT(11) VARCHAR(255) VARCHAR(255) Нет Нет Нет Нет Да Ключи таблицы: at_log_id (первичный ключ), по полю at_log_id;

FK_atlog_attest_at_test_id, по полю at_test;

FK_atlog_logtype_log_type_id, по полю at_log_type.

Таблица 2.8 - состав таблицы NNCLINPUTDATA

Наименование атрибута Тип поля NULL nncl_input_id first_mac last_mac host_mac INT(11) INT(11) INT(11) INT(11) Нет Нет Нет Нет

Ключи таблицы: nncl_input_id (первичный ключ), по полю nncl_input_id.

В таблицах 2.9 и 2.10 представлены описания таблиц User и USERTYPE, представляющие одноименные сущности.

Таблица 2.9 - состав таблицы User

Наименование атрибута Тип полей NULL login password email user_type first_name second_name third_name VARCHAR(30) VARCHAR(50) VARCHAR(100) INT(11) VARCHAR(255) VARCHAR(255) VARCHAR(255) Нет Нет Нет Нет Нет Нет Нет

Ключи таблицы: login (первичный ключ), по полю login;

FK_user_usertype_user_type_id, по полю user_type.

Таблица 2.10 - состав таблицы USERTYPE

Наименование атрибутов Тип поля NULL user_type_id user_type_name description can_add can_delete INT(11) VARCHAR(30) VARCHAR(255) BOOL BOOL Нет Нет Да Нет Нет

Единственный ключ таблицы - login (первичный ключ), по полю login.

2.2.5 Разработка хранимых процедур

Некоторые действия с базой данных необходимо выполнять особенно часто, например, приходится выполнять практически одинаковые или совсем одинаковы запросы, и такие действия удобно вынести в отдельные единицы, для этого хорошо подходят хранимые процедуры.

Так же хранимые процедуры обладают рядом преимуществ: повторное использование кода;

сокращение сетевого трафика;

безопасность;

простота доступа.

Список разработанных ранимых процедур и их описание приведены в таблице 2.11.

Таблица 2.11 - Описание хранимых процедур

Название процедуры Описание процедуры get_at_logs_list Возвращает список журналов, "прикрепленных" к тестам AT-команд get_at_test_info Возвращает информацию о выбранном тесте AT-команд get_at_tests_list Возвращает список тестирований AT-команд get_end_codes_list Возвращает список кодов завершения get_log_types_list Возвращает список типов журналов get_nncl_logs_list Возвращает список журналов, "прикрепленных" к тестам команд протокола NNCL get_nncl_test_info Возвращает информацию о выбранном тесте команд протокола NNCL get_nncl_tests_list Возвращает список тестов команд протокола NNCL get_test_modes_list Возвращает список режимов тестирования команд протокола get_user_info Возвращает информацию о выбранном пользователе get_users_list Возвращает список пользователей attach_file Добавляет файл в базу данных

Код описанных хранимых процедур представлен в приложении Г.

2.2.6 Создание пользователей и распределение привилегий

СУБД MYSQL является многопользовательской. Это означает, что для доступа к таблицам базы данных могут быть созданы различные учетные записи с разным уровнем привилегий. Такой подход используется для повышения уровня безопасности.

Для доступа к базе данных созданы два пользователя, которые описаны в таблице 2.12.

Таблица 2.12 - Описание пользователей базы данных

Пользователь Привилегии Описание plc_tester INSERT, SELECT Используется для доступа к базе данных модулем тестирования php_user SELECT, EXECUTE Используется для доступа к базе данных web-приложением

Следует отметить, что учетная запись является составной и принимает форму username@host, где username - имя пользователя, а host - наименование/адрес узла, с которого пользователю username разрешено обращаться к базе данных. Соответственно, администратор сервера, на котором установлена база, данных должен указать фактические адреса машин (можно использовать символ %, который выполняет туже функцию, как и в операторе LIKE).

Для создания пользователя используется оператор CREATE USER, который имеет следующий синтаксис: CREATE USER user [IDENTIFIED BY [PASSORD] password], оператор создает учетную запись user с необязательным паролем password.

Привилегии задаются оператором GRANT. Привилегии INSERT, SELECT и EXECUTE позволяют выполнять добавление данных, выборку данных и выполнять хранимые процедуры, соответственно. Лишить привилегий пользователя можно командой REVOKE.

2.3 Проектирование и разработка модуля тестирования и сбора данных

2.3.1 Проектирование модуля

Модуль тестирования и сбора данных должен производить тестирования PLC-модемов, обрабатывать результаты тестов и сохранять их в базу данных. В информационной подсистеме тестирования PLC-модемов рассматриваются два вида тестов: команд протокола NNCL и AT-команд, поэтому принято решение модуль тестирования и сбора сделать составным.

Модуль TNNCL.dll выполняет тестирование команд протокола NNCL, а TAT.dll - AT-команд. Модули TNNCL.dll и TAT.dll между собой никак не взаимодействуют, и связаны только с модулем PLCTESTER.exe, это представлено на диаграмме компонентов (рисунке 2.11), в нотации UML.

Рисунок 2.11 - Диаграмма компонентов модуля тестирования/сбора данных в нотации UML

Во время тестирований, подмодули TNNCL.dll и TAT.dll отправляют запросы модемам, принимают ответы от них и передают данные подмодулю PLCTESTER.exe. Для обеспечения межмодульного взаимодействия используются именованные каналы.

В Windows дизайн именованных каналов смещен к взаимодействию клиент-сервер, и они работают во многом как сокеты: помимо обычных операций чтения и записи, именованные каналы в Windows поддерживают явный "пассивный" режим для серверных приложений. Windows 95 поддерживает клиенты именованных каналов, а системы ветви Windows NT могут служить также и серверами.

К именованному каналу можно обращаться в значительной степени как к файлу. Можно использовать функции Windows API CREATEFILE, CLOSEHANDLE, READFILE, WRITEFILE, чтобы открывать и закрывать канал, выполнять чтение и запись. Функции стандартной библиотеки C такие как fopen, fread, fwrite и fclose, тоже можно использовать, в отличие от сокетов Windows, которые не реализуют использование стандартных файловых операций в сети.

PLCTESTER.exe создает экземпляр именованного канала, к которому подключается один из подмодулей TNNCL.dll или TAT.dll.

При завершении тестирования PLCTESTER.exe обрабатывает результаты сохраняет их в базу данных.

2.3.2 Разработка модуля TNNCL.dll

Модуль TNNCL.dll реализован как библиотека динамической компоновки - понятие операционных систем Microsoft Windows и IBM OS/2; динамическая библиотека, позволяющая многократное применение различными программными приложениями.

Инициализация тестирования производится функцией модуля TNNCL.dll TNNCLCONSTRUCTOR, которая в параметрах получает входные данные для теста и служебную информацию (настройки последовательного порта, имя именованного канала, дескриптор главного окна приложения). Принудительное завершение тестирование производится вызовом функции TNNCLDESTRUCTOR (того же модуля). Сам процесс тестирования выполняется в отдельном потоке операционной системы, выполняясь после завершения TNNCLCONSTRUCTOR.

Функции TNNCLCONSTRUCTOR и TNNCLDESTRUCTOR вызываются модулем PLCTESTER.exe.

Модуль TNNCL.dll собирает пакет в соответствии с протоколом NNCL, после чего упаковывает его в кадр SLIP, при необходимости производится процедура байтстаффинга.

Границей SLIP-кадра является уникальный флаг END (0XC0). Уникальность этого флага поддерживается байт-стаффингом (byte stuffing) внутри кадра с ESC-последовательностью 0XDB, причем байт END (0XC0) заменяется последовательностью (0XDB, 0XDC), а байт ESC (0XDB) - последовательностью (0XDB, 0XDD).

После этого кадр отправляется модему, и ожидается ответ. При получении ответа, производятся обратные действия, и данные передаются модулю PLCTESTER.exe.

Обмен данными с модемом производятся через последовательный порт. Для открытия порта используется функция Windows API CREATEFILE, после чего порт настраивается функцией SETCOMMSTATE. Запись и чтение производятся функциями READFILE, WRITEFILE. Закрывается порт функцией CLOSEHANDLE. Весь кадр, отправляется сразу целиком. Получение ответа производится по более сложному алгоритму, чтение данных из порта будет продолжаться, до тех по пока не будет получен второй байт "0XC0" либо пока не выйдет время таймаута (таймаут задается при вызове функции, отвечающей за получение данных).

Модуль реализован на языке программирования C , в среде программирования NETBEANS IDE с компилятором "MINGW".

2.3.3 Разработка модуля TAT.dll

Модуль TAT.dll работает аналогично модулю TNNCL.dll. Основным отличием является то, что данные передаются модулю PLCTESTER.exe в более простой форме и отправляются не SLIP-кадры а AT-команды.

AT-команды (набор команд Hayes) - набор команд, разработанных в 1977 году компанией Hayes для собственной разработки, модема "Smartmodem 300 baud". Набор команд состоит из серий коротких текстовых строк, которые объединяют вместе, чтобы сформировать полные команды операций, таких как набор номера, начала соединения или изменения параметров подключения.

Для того чтобы модем распознал эти команды, они должны быть записаны в специфической форме. Каждая команда всегда начинается буквами AT или at (от англ. ATTENTION, за что и получили свое название), дополненных, командой и завершаемой в конце возвратом каретки. Команды воспринимаются модемом только тогда, когда он находится в командном режиме.

AT-команды обычно отправляются модему посредством коммуникационного программного обеспечения, но также могут быть введены пользователем вручную, с компьютерной клавиатуры.

Стандартизация набора команд Hayes (и AT-команд) выразилась в документе под названием Data Transmission Systems and Equipment - Serial Asynchronous Automatic Dialing and Control, известном как TIA/EIA-602.

Данные модулю PLCTESTER.exe передаются в виде строки, первый символ которой является "управляющим", возможные значения: "S" (данные переданы модему);

"R" (данные получены от модема).

Модуль реализован на языке программирования C , в среде программирования NETBEANS IDE с компилятором MINGW.

2.3.4 Разработка модуля PLCTESTER.exe

Данный модуль связан с базой данных, его основными задачами являются: обработка данных, полученных от модулей TNNCL.dll и TAT.dll;

сохранение данных в базу данных на сервере.

В дополнение к этому, модуль выполняет базовое конфигурирование модемов, планирует задачи, поставленные пользователем, и реализует функции простого терминала, для отправки AT-команд вручную.

Для работы с базой данных используются классы из пространства имен MYSQL.Data.MYSQLCLIENT: MYSQLCONNECTION (для соединения с базой данных);

MYSQLCOMMAND (команда для выполнения SQL-запроса);

MYSQLDATAREADER (для чтения результатов SQL-запросов);

MYSQLEXCEPTION (для обработки исключений).

Для работы с именованными каналами используются класс NAMEDPIPESERVERSTREAM из пространства имен System.IO.Pipes.

Для работы с последовательным портом используется класс SERIALPORT из пространства имен System.IO.Ports.

Для записи настроек и экспорта результатов тестирований на диск (в энергонезависимую память) используются классы пространств имен System.IO и System.Runtime.Serialization.Formatters.Binary: FILESTREAM, BINARYFORMATTER.

Основными экранными формами приложения (модуля PLCTESTER.exe) являются: форма входа в систему (соединения с базой данных и авторизации пользователя);

главная форма (на ней располагаются все основные инструменты);

формы сохранения результатов в базу данных.

Так же используются вспомогательные формы: форма настройки последовательного порта;

форма просмотра информации о задачах, поставленных в очередь на выполнение;

форма менеджера файлов входных данных;

форма настроек запуска внешних приложений.

Для удобства, элементы интерфейса пользователя главной формы размещены на пяти вкладках: "Тестирование команд протокола" - тестирование команд протокола NNCL;

"Тестирование AT-команд" - тестирование AT-команд;

"Планирование задач и настройки" - настройки приложения и планирование задач;

"Конфигурирование модема" - базовая конфигурация модема;

"Произвольные команды" - терминал.

При инициализации и выполнения процесса тестирования запускается отдельный поток, которой проверяет именованный канал на наличие данных в нем. Как только данные поступают в именованный канал, производится их считывание, обработка и вывод на главную форму.

Чтение данных из именованного канала аналогично чтению из файла.

Выполнять более одного тестирования одновременно невозможно (контролируется программой), но возможно выполнение тестирования и конфигурирование модема/отправка произвольных команд.

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

Данные о задачах, поставленных в очередь, после завершения работы приложения сохраняются в файле на диске.

При конфигурировании модемов реализованы функции чтения и записи конфигурации, а так же записи настроек по умолчанию. Настраиваются модемы AT-командами.

Для работы с потоками в .NET используется класс Thread пространства имен System.Threading.

Для корректной работы и полной функциональности модуль PLCTESTER.exe использует конфигурационные файлы на жестком диске, это показано на диаграмме компонентов в нотации UML (рисунок 2.12).

Рисунок 2.12 - Диаграмма компонентов модуля тестирования/сбора данных в нотации UML

Данная диаграмма отражает только взаимодействие модуля PLCTESTER.exe с конфигурационными файлами. Описание файлов приводится в таблице 2.13. Функции представленных файлов очень похожи, все они хранят настройки приложения.

Таблица 2.13 - Описание основных файлов настроек

Имя файла Описание

Actions.ats Хранит информацию о задачах, поставленных в очередь на выполнение

ATINPUTDATA.atc Хранит входные данные для тестирования AT-команд

DBCONNECTIONSETTINGS.dbst Хранит данные для соединения с базой данных

PROTOCOLINPUTDATA.tc Хранит входные данные для тестирования команд протокола NNCL

RUNSETTINGS.rst Хранит настройки для запуска внешних приложений

Default.mc Хранит основные настройки приложения

PPORTSETTINGS.ps Хранит настройки последовательного порта для тестирования команд протокола NNCL

ATPORTSETTINGS.ps Хранит настройки последовательного порта для тестирования AT-команд

CPORTSETTINGS.ps Хранит настройки последовательного порта для конфигурирования модемов

Модуль PLCTESTER.exe реализован в виде Windows-приложения, написан на языке программирования C# в интегрированной среде разработки SHARPDEVELOP.

2.4 Разработка web-приложения

Основная задача web-приложения - предоставлять пользователю необходимую информацию о проведенных тестированиях в удобной форме. Приложение разрабатывается на языке PHP.

Web-приложение все необходимые данные извлекает из базы данных, посредством SQL-запросов. Для работы с базой данных используются следующие функции PHP: mysql_connect(string $hostname, string $user, string $password), для соединения с базой данных и авторизации пользователя (все параметры - необязательные);

mysql_close(int $connect_id), для закрытия соединения (параметр connect_id необязательный);

mysql_select_db(string $db, int $id), для выбора базы данных, с которой нужно работать (параметр id необязательный);

mysql_query(string $query), для выполнения запросов к базе данных;

mysql_errno(int $id), для получения кода ошибки;

mysql_error(int $id), для получения описания ошибки.

Для обработки результатов запросов используются следующие функции: mysql_result - полчить нужный элемент из набора записей;

mysql_fetch_array - занести запись в ассоциативный массив или числовой массив;

mysql_fetch_row - занести запись в массив;

mysql_fetch_assoc - занести запись в ассоциативный массив;

mysql_fetch_object - занести запись в объект;

mysql_num_row - узнать, сколько записей содержит результат выполнения запроса.

PHP предоставляет еще несколько полезных функций, которые позволяют узнать дополнительную информацию о результате выполнения запросов: mysql_field_name(int $result, int $offset) - возвращает имя поля, находящегося в результате $result по индексу $offset;

mysql_filed_type(int $result, int $offset) - возвращает тип поля с индексом $offset в результате $result.

Для передачи данных из формы в сценарий используется методы POST и GET.

Оба метода похожи, и по большому счету отличаются лишь формой передачи данных (метод GET является более открытым - данные передаются через адресную строку).