Размещено на http://www.allbest.ru/

Москва, 2005

Министерство образования и науки Российской Федерации

Московский государственный институт электронной техники (технический университет)

Факультет МП и ТК

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к дипломному проекту

на тему: «Разработка программного модуля для удаленного администрирования и мониторинга RAID-системы»

Исполнитель

Кузнецов А.А.

Руководитель

Федотова Е.Л.

Введение

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

Система, позволяющая делать резервное хранение всей информации на жестких дисках в режиме реального времени, была разработана еще более 10 лет назад. Такая система получила название RAID - Redundant Array of Inexpensive (позднее Independent) Disks - избыточный массив недорогих (независимых) дисков. В основу RAID положена следующая идея: несколько дисков, работая параллельно, используются как для хранения информации, так и для хранения резервных копий всех данных. При этом несколько небольших дисков работают в системе намного быстрее, чем каждый из них отдельно взятый. Вдобавок ко всему такая система с точки зрения компьютера выглядит как один единственный диск.

Для управления дисками и информацией на них используется RAID-контроллер. Он и регулирует весь процесс хранения «горячей копии». Для того чтобы можно было конфигурировать RAID-систему и следить за его работоспособностью данная система должна иметь некую систему управления устройством. Компания-производитель RAID-систем «Fibrenetix» поставила задачу разработать программу, предназначенную для управления и мониторинга RAID-системы.

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

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

Данный дипломный проект состоит из четырех разделов и трех приложений:

  Раздел 1 содержит описание постановки задачи, анализ проведенных предварительных НИР, перечисление требований к программе, описание входных и выходных данных для системы, общий и детальные схемы алгоритмов работы программы, а также результаты испытаний программы;

  Раздел 2 является технологическим разделом и содержит информацию о методике создания данного программного продукта и приемах его отладки.

  Раздел 3 содержит организационно-экономическую часть дипломного проекта, в которой проводится расчет стоимости проекта и планирование разработки;

  Раздел 4 посвящен вопросу организации рабочего места программиста и пользователя ПК.

Приложение 1 включает в себя текст программы.

Приложение 2 - это документация для программиста, описание команд для обмена данными между модулями программы, спецификации контроллеров.

Приложение 3 - руководство пользователя (файл справки программы).

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

1. Специальный раздел

В специальном разделе описаны основные стадии разработки программного продукта GUI RAID MANAGER: постановка задачи, предварительные НИР и техническое задание.

1.1 Исследовательская часть

Постановка задачи

Для компании «Fibrenetix» требовалось оснастить продаваемые RAID-контроллеры программой для удобного управления и мониторинга RAID-системы. Необходимо было создать ПО, чтобы оно позволяло пользователю следить за работой RAID удаленно с любого компьютера и не требовало специальных знаний по управлению RAID.

RAID-контроллеры «Fibrenetix», для которых предназначается данное ПО, построены на базе контроллеров Intel i960, и имеют одинаковые команды управления. Поэтому эту программу можно смело использовать для всего ряда RAID-контроллеров Fibrenetix.

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

Во-первых, программа должна быть удобным средством для управления всей RAID-системой. В связи с этим необходимо было заранее продумать всю схему работы со стороны пользователя, особенно не имеющего навыков работы с RAID-системами. Помимо концепции отдельным образом разрабатывался дизайн программы - интерфейс пользователя. Чтобы привлечь внимание пользователя была придумана яркая графика, анимированные картинки, звуковые эффекты для нотификации, а также при ошибках и сбоях системы.

Для быстрого удобного способа настраивать RAID-массив, было принято решение разработать «Мастер первоначальной загрузки», который будет пошагово сообщать пользователю о его дальнейших действиях.

Во-вторых, система должна предоставлять сведения о работе системы. Пользователь должен наглядно видеть, как работает его RAID-массив в режиме реального времени. А также иметь доступ к информации о работе системы в его отсутствии - log-файлы. Важный момент - многие администраторы управляют серверами удаленно по сети. Поэтому необходимо реализовать возможность доступа к управлению не только с компьютера, к которому подключен RAID-массив, но и любого другого компьютера по сети.

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

По сути, данная система управления RAID-системой является единственным средством для настройки контроллера на нужную работу и для анализа дальнейшей работы этого контроллера.

Именно с этой целью была создана система управления GUI RAID MANAGER.

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

Также особое внимание требовалось уделить написанию документации. Файлы помощи разделены на два раздела - помощь при работе с программой и советы по использованию RAID-массива.

Обзор программных продуктов для управления RAID-системой

Перед началом разработки было необходимо определить концепцию системы. Для этого требовалось провести две работы - оценить работу уже существующих подобных программ и проследить за работой пользователя по установке RAID-системы.

На рынке представлено не так много программ для управления RAID-системами. Для подробного анализа была выбрана единственная программа - GAM (Global Array Manager) компании LSI Logic Corporation. Остальные программы были рассмотрены поверхностно - в основном из описания по данному продукту.

GAM (Global Array Manager)

Программное обеспечение Global Array Manager (GAM) разрабатывалась для компании LSI Logic Corporation. Данное ПО предназначено для администрирования RAID-массивов построенных на базе контроллера Mylex DAC960 - AcceleRAID® и eXtremeRAID®.

Программа использует клиент-серверную структуру - два программных модуля. Первый модуль - сервер - устанавливается на компьютере с RAID-системой и постоянно работает. Другой модуль, называемый клиентом, запускается только во время каких либо действий над RAID-системой.

Используя доступ через протокол TCP/IP, администратор с удаленной станции может отслеживать и конфигурировать сервер, не прерывая его работу. Новые накопители могут быть добавлены в систему при помощи обычной технологии "drag-n-drop". Выбывшие из строя накопители, источники питания и контроллеры могут быть заменены с использованием GAM. Через клиентский интерфейс, системный администратор может получить уведомление о критических событиях происходящих на сервере или периферийном устройстве. Сообщения о любых изменениях попадают в окно сообщений на экране терминала администратора, а также могут быть переданы по электронной почте, на сотовый телефон или факс.

GAM поддерживает все основные операционные системы, в том числе Windows NT, Netware 3.12, Netware 4.x, SCO UNIX, UnixWare, AIX.

Внешний вид программы GAM показан на рис. 1.1



Рис. 1.1. Внешний вид программы GAM

Положительные стороны программы:

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

  Хранение файлов истории. В любой момент можно посмотреть, как работала система за последний период времени. Вся информация о сбоях и сообщениях RAID-системы.

  Менеджер конфигурации RAID-системы. Программа предлагает пошагово пройти настройку системы. В этом случае мала вероятность того, что администратор может упустить некоторые настройки. Каждый шаг подробно описывается документацией, так что будет несложно разобраться даже начинающему администратору.

  Оповещение администратора об ошибке системы. Если вдруг в RAID-системе произошла ошибка, администратор сразу же может получить оповещение на e-mail или свой пейджер. Это очень важная возможность, т.к. при ошибке RAID-системы информация может потеряться и следует немедленно решить проблему.

Отрицательные стороны:

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

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

Из данной программы в первую очередь следует взять идеологию программы - будем разрабатывать приложение типа клиент-сервер. Сервер должен будет запускаться на компьютере с RAID-системой и постоянно быть включен, а клиент может тогда запускаться с любого компьютера и соединяться с сервером по TCP/IP протоколу.

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

Информационные потребности пользователя

В завершении проектирования необходимо проследить за работой пользователя при управлении RAID-системой.

1. Установка RAID. При подключении RAID-системы к компьютеру и после настройки необходимых драйверов, пользователю необходимо настроить работу RAID на нужный режим (RAID0, RAID1, RAID3 и др.). После этого готовое для работы дисковое пространство необходимо разбить на нужные тома (разделы). В завершении настройки необходимо протестировать работу всей системы.

2. Управление/Диагностика RAID. Если пользователю захотелось посмотреть на состояние работы системы либо изменить какие-либо параметры, ПО должно информативно показать состояние работы системы и предоставить удобный интерфейс для изменения настроек системы. При этом как часто бывает, администратор работает с компьютером, на котором установлен RAID, удаленно (например, из дома), поэтому ПО должно обеспечивать авторизированный (защищенный) доступ для управления системой по сети.

3. Обработка ошибок. Система обязана незамедлительно сообщить администратору о возникших ошибках в работе RAID. Так как сам по себе RAID-контроллер не может подать сигнала о неисправности, ПО должно обеспечивать бесперебойный мониторинг RAID на предмет ошибок.

4. Документация ПО. Система должна быть полностью понятна пользователю. Но несмотря на это, при возникших трудностях пользователь должен быстро найти необходимую документацию как о работе ПО, так и о устройстве RAID и режимах его работы.

1.2 Конструкторская часть

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

Исходя из поставленной задачи и проведенных предварительных НИР были сформулированы требования к разрабатываемой системе.

Состав выполняемых функций

Создаваемый программный продукт должен обеспечить выполнение следующих функциональных действий:

  Начальная установка только что приобретенной RAID-системы;

  Ежедневный мониторинг состояния RAID-системы;

  Изменение конфигурации существующей системы (менеджер дисков, управление дисковым пространством, настройки RAID-контроллера);

  Возможность удаленно с другого компьютера производить управление системой;

  Нотификация администратора о неисправностях и сбоях в работе RAID-системы.

Требования к надежности

Так как система должна работать удаленно, должна быть реализована система авторизации и защита от несанкционированного использования системы. Для предотвращения перехвата пароля, передаваемого по сети, все пароли будут храниться в зашифрованном виде.

Условия эксплуатации и требования к составу и параметрам технических средств

При удаленном администрировании RIAD-системой нужно запускать два программных модуля - один на компьютере с RAID системой, другой на компьютере администратора.

Основным требованием для использования системы является необходимость постоянной работы программного модуля запускаемого на компьютере с RAID-системой. Если этот модуль будет остановлен, то без него нельзя будет произвести соединение к RAID-системе и будет невозможным следить за работой RAID (отсылать нотификацию о неисправностях и вести файлы истории работы RAID).

Для связи обоих программных модулей между собой используется протокол TCP/IP. Поэтому для возможности удаленно работать с RAID-системой, необходима настроенная сеть для обоих компьютеров. При администрировании RAID-системы с локального компьютера, подключение к сети не нужно.

Требования к информационной и программной совместимости

По требованию заказчика данное программное обеспечение разрабатывается под платформу Windows. Программа должна работать под основными версиями этой платформы: Windows 98, Windows 2000, Windows XP. Причем серверная часть программы для версий WinNT должна работать как сервис (работать в фоновом режиме).

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

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

Разрабатываемая система управления будет поставляться в комплекте при продаже RAID-контроллера. Она должна быть записана на отдельный CD-диск, на котором будут находиться драйверы системы и необходимая документация к продаваемому контроллеру. Для этого следует учесть, чтобы объем установочных файлов был не более примерно 2/3 стандартного CD-диска (700 Мб).

Специальные требования

Серверная часть программы, которая занимается анализом работы RAID, должна быть всегда запущена на компьютере с RAID-системой. Если этот модуль будет остановлен, то без него нельзя будет произвести соединение к RAID-системе и будет невозможным следить за работой RAID (отсылать нотификацию о неисправностях и вести файлы истории работы RAID).

Структурная схема работы программы

Весь программный проект основан на двух независимых модулях. Как уже упоминалось, один из них запускается отдельно на компьютере с RAID-системой, а второй на компьютере администратора. Для сокращения будем называть первый модуль Агентом, а второй - Менеджером.

Менеджер - пользовательская сторона программы, содержащая в себе интерфейс программы, мастер начальной установки, раздел справки. Менеджер будет управлять RAID-системой посредством Агента.

Агент в основном служит для передачи команд от Менеджера RAID-системе и обратно. Также Агент будет заниматься мониторингом RAID (ведение log-файла) и нотификацией администратора при ошибках.

Основная структура работы всей работы в целом представлена на рис. 1.2. На нем показаны различные варианты работы двух модулей Агент и Менеджер:

  Агент (C3) запущен на компьютере и анализирует работу RAID-массива R2;

  Менеджер с удаленного компьютера (С2 или С4) может соединяться по сети с Агентом (С3) для управления работой RAID-массива R2;

  Менеджер и Агент запущены на одном компьютере С1 для управления работой RAID-массива R2. При таком варианте подключение к сети не требуется.

Структура входных и выходных данных

Основной обмен данными в системе в целом происходит по двум каналам:

  между Менеджером и Агентом по сети по протоколу TCP/IP (команды Менеджера и ответы Агента);

  между Агентом и RAID-контроллером через интерфейс RS-232 (опрос контроллера и ответы от него).

Формат данных между Менеджером и Агентом, а также между Агентом и RAID-контроллером описан в параграфе «Формат данных модуля Агент» данного раздела.

Моей задачей в этом проекте является разработка модуля Агент. Поэтому рассмотрим подробнее обмен данных в модуле Агент между Менеджером и RAID-контроллером.

На данной схеме показано, что данные между Менеджером и Агентом проходят через модуль приема и передачи данных по сети. Для проверки подключения Менеджера этот модуль использует блок авторизации. Все принимаемые данные анализируются в блоке обработчика команд Менеджера. В зависимости от типа команды информация поступает либо в блок настроек, либо в блок файла истории либо в модуль опроса состояния RAID. Последний служит для того чтобы посылать команды RAID-контроллеру и получать от него ответы. Если при запросе возникает ошибка либо ответ контроллера содержит критическое сообщение, модуль нотификации оповестит администратора о данной ошибке.

Общая схема алгоритма работы модуля Менеджер

На рисунке 1.6 представлена общая схема алгоритма работы модуля Менеджер. Не вдаваясь в подробности, так как этот модуль разрабатывался не мной, заметим, что помимо основного окна программы, есть еще вспомогательные интерфейсы для первоначальной установки программы, а также специализированный модуль для устранения ошибок. Система сама активизирует эти модули при необходимости. Также можно заметить, что при выходе из программы, есть возможность подключиться к другому RAID-контроллеру, если администратор обслуживает несколько RAID-систем.

Рис. 1.5. Общая схема алгоритма работы модуля Менеджер

Общая схема работы выглядит следующим образом. При запуске программы, модуль Менеджер соединяется с компьютером, на котором установлена RAID-система и происходит авторизация пользователя. После успешной авторизации, если система не была настроена до этого, пользователю предлагается настроить систему с помощью менеджера первоначальной настройки. При появлении ошибок в RAID-системе система вызывает диалог с сообщением об этой ошибке и предлагает способ по устранению этой проблемы. В остальном система позволяет производить мониторинг RAID-системы и производить некоторые настройки работающей системы. После окончания работы с данным RAID-массивом можно подсоединиться к другому RAID-контроллеру.

Схема алгоритма работы модуля Агент

Общая схема алгоритма работы модуля Агент представлена на рисунке 1.6. Более подробные схемы алгоритмов для поиска подключенных RAID-контроллеров, обработки команд Менеджера, и мониторинга RAID-системы будут рассмотрены далее.

Рис. 1.6. Схема алгоритма работы модуля Агент

Данный модуль работает как сервер, поэтому выход из него организован только по принуждению от пользователя либо если не было найдено подключенных RAID-устройств к данному компьютеру. При запуске Агент первым делом проверяет, есть ли уже найденные RAID-контроллеры, подключенные к этому компьютеру. Если таких устройств не обнаружено, активизируется модуль для поиска RAID-контроллеров. Схема работы этого модуля будет рассмотрена ниже. Если поиск не дал положительных результатов, то работа модуля Агент останавливается.

Далее модуль постоянно через указанный в настройках промежуток времени опрашивает RAID-массив и записывает эти данные в файл истории. Если произошла какая-либо ошибка в RAID-системе, то модуль немедленно указанным в настройках методом посылает извещение администратору об этой ошибке. При поступлении запроса на соединение от Менеджера модуль устанавливает соединение и передает данные от Менеджера RAID-контроллеру и обратно.

Более подробно об алгоритмах работы модуля Агент будет рассказано в следующем параграфе.

Схемы алгоритмов модуля Агент

В данном параграфе подробно описаны алгоритмы работы программного модуля Агент.

Поиск подключенных RAID-контроллеров

Данный модуль запускается, если при старте Агента не было найдено файла настроек, либо эти настройки не верны.

Вначале необходимо задать параметры для поиска RAID-контроллера. На следующем шаге программа будет сканировать указанные COM-порты по заданным параметрам. Если поиск окончился неудачно, система предложит произвести поиск заново, изменив параметры поиска. После того как RAID-контроллер был найден, система запишет настройки в определенный файл, который будет использоваться при запуске Агента.

Мониторинг RAID-массива

Мониторинг RAID-массива осуществляется по таймеру. Промежуток времени для мониторинга задается в настройках либо через интерфейс Менеджера, либо Агента.

Рис. Схема алгоритма мониторинга RAID-массива

Основной момент в этом цикле занимает нотификация администратора, если была найдена ошибка. При обнаружении ошибок в работе системы определяем, надо ли отправлять оповещение для администратора о неисправности. Для этого необходимо вначале определить код данной ошибки. В файле настроек для оповещения для каждой категории ошибок указывается тип оповещения: E-mail, Broadcast или в log-файл. Если ошибок не было найдено. В log-файл записывается строка об успешной проверке работы системы.

Формат данных модуля Агент

Рассмотрим подробно формат данных модуля Агент, а также формат команд для обмена информацией между Агентом и Менеджером, и между Агентом и RAID-контроллером.

Файл конфигурации Агента

Файл конфигурации нужен для определения подключенного к компьютеру RAID-контроллера.

[Mail]

TYPE=COM

PORT=1

BAUD=19200

DATABITS=8

STOPBITS=1

PARITY=0

LogFileName=000032599000004.log

LogFileSize=1024

DelayTime1=0

DelayTime2=15

DelayTime3=30

DelayTime4=60

Cnt=1

skin=1

emessage_1=HI

address_1=SAGA

bmessage_1=HI

Формат файла истории

В файл истории записываются все события по формату:

[день/месяц/год(2) часы:минуты:секунды]: сообщение. Пример:

[05/05/09 14:39:18]:New connection opened

[05/05/09 14:39:18]:GUI detected via:127.0.0.1

[05/05/09 14:39:18]:GUI connected at:127.0.0.1

[05/05/09 14:40:08]:Login accepted:127.0.0.1: session opened

Формат команд RAID-контроллера

В таблице 1.1 приведен фрагмент из описания к контроллеру ACS-9900 с описанием команд посылаемых RAID-контроллеру.

Таблица 1.1 Формат командр контроллера ACS-9900

Command	Description
Get page	Get the RAID information page
Edit RAIDi	Edit RAID1~4, If Argument code is No, This Command is Aborted
Set RAIDi Level	Set RAIDi Level---i=1or2or3or4 0--0xi0, 1--0xi1, 3--0xi3, 5--0xi5, 0+1--0xi6, None--else
Select RAIDi Disk Member	Select RAIDi Disk Member (i=1or2or3or4) if xx=01 Disk01 is selected, xx=03 Disk03 is selected.....

Таблица 1.2 Формат ответов контроллера ACS-9900

Message	Meaning
INITIALIZING ARRAY X...:	Initializing Array x
INIT ARRAY ERROR	Error occurred while initializing Array
INIT ARRAY OK	Array initializing successful
ADD(X): ERROR!:	Error occurred while rebuilding Slot x
CHECK ARRAY ERROR!:	Error occurred while checking Array
CHECK ARRAY OK.	Array checked without any problems
HOST CHAN X: TEST OK	Host channel x is ok
HOST CHAN X: TEST FAIL	Error occurred while testing Host channel x

Выбор платформы проектирования

По требованию заказчика данного ПО была выбрана платформа Windows.

Программа должна работать под основными версиями этой платформы: Windows 98, Windows 2000, Windows XP. Причем серверная часть программы для версий WinNT должна работать как сервис (работать в фоновом режиме).

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

Код программы должен быть написан с учетом того чтобы было в последствии несложным его применить для написания такового же модуля для Unix-платформы.

В качестве среды для разработки была выбрана среда MS Visual C++ по нескольким причинам:

  простота и надежность создания и отладки программы;

  использование всех преимуществ операционных систем Windows'98 и Windows NT, включая 32-разрядность, многозадачность, удобный интерфейс и прочее;

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

  наличие мощных, удобных утилит для отладки и тестирования программного обеспечения;

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

  возможность адаптировать C-программный код для написания приложения под Unix-систему.

Microsoft Visual C++ - сегодня является самой распространенной и наиболее емкой средой разработки. В наши дни Visual C++ лидирует среди продуктов для программирования в среде Windows. Visual C++ - это инструмент для программирования в среде Widnows, обладающий поистине фантастическими возможностями. Более того, многие разработчики считают Visual C++ самой мощной из всех программ такого класса. На самом деле Visual C++ представляет собой целый набор из множества инструментов, собранных в одном динамическом пакете, готовом к немедленной работе. Сначала программы для Windows приходилось писать на языке С, а не на С++, и получались они большими и сложными. Даже вывод на экран пустого окна требовал примерно пяти страниц сложного невразумительного кода. Язык С++ позволяет хранить большую часть программного кода внутри самостоятельных объектов, а это сокращает объем больших программ. Помимо этого, фирма Microsoft разработала библиотеку Microsoft Foundation Classes. MFC - замечательный пакет, состоящий из заранее написанного и готового к работе кода. Например, вместо того чтобы самостоятельно писать программу для работы с новым окном, можно просто воспользоваться классом cWnd из MFC, который выполнит всю работу за вас [2]. Возможности, предоставляемые библиотекой классов MFC позволяют конструировать элементы пользовательского интерфейса, легко работать со стандартными типами данных языка С, разрабатывать классы, производные от библиотечных с добавлением новых функциональных возможностей, разрабатывать собственные классы с последующим развитием их функциональности.

Реализация программного модуля Агент

Программный модуль Агент состоит из двух отдельных интерфейсов. Первый служит для поиска подключенных RAID-контроллеров на данном компьютере. Второй - сам непосредственно сервер, который отвечает за связь модуля Менеджер и RAID, а также за нотификацию в случае неисправности.

Реализация модуля для поиска подключенных RAID-контроллеров

Модуль реализован отдельно от серверной части, т.к. он запускается только в момент первоначальной загрузки сервера. Его непосредственная задача - просканировать подключенные RAID-контроллеры на COM-порту. Если сканирование прошло успешно, необходимо записать файл настроек для сервера, в котором будет информация о подключенном RAID-контроллере.

Рис. Интерфейсы поиска подключенных RAID-систем

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

  «Cancel» - отмена действий.

  «Finish» - завершение работы поиска.

  «<< Prev» - переход на шаг назад.

  «Next >>» - переход на шаг вперед.

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

Критерием нахождения контроллера является:

  Успешное соединение по интерфейсу RS232;

  Ответ на команду “GetPage 0;”;

  Наличие в первых трех байтах ответе сигнатуры «ACS».

После успешного поиска система предложит сохранить настройки для сервера. Если файл уже существует, будет выдано предупреждение о перезаписи этого файла.

Реализация сервера Агент

После установки серверной части программы, программный модуль Агент готов к запуску. При первом запуске, а также если файла настроек вдруг было не обнаружено, система предложит воспользоваться модулем для поиска подключенных RAID-контроллеров. Этот же модуль запускается, если RAID-контроллера с настройками, указанными в файле agent.ini, не было найдено.

Рис. Главное окно модуля Агент

При нормальном запуске программа не открывает никаких окон, а просто помещает свою иконку в Traybar (место в панели Windows, где находятся часы). И при сворачивании окна, она также скрывается в Traybar. Если нажать на иконке программы правой кнопкой мыши, всплывет меню, для быстрых настроек.

При двойном щелчке мыши по иконке, всплывет основное окно, в котором можно следить за работой Агента. Данное окно показано на рисунке 1.10. Все действия, которые выполняются данным модулем, показываются на экран в виде строчных сообщений, формата log-файла. С помощью данного экрана можно следить за всеми действиями Агента. При желании можно временно отключить вывод сообщений на экран, хотя в log-файл эти сообщения все равно попадут.

Управлять программой можно через меню или Toolbar (место под меню, с иконками для быстрого запуска команд). Кнопки Toolbar дублируют соответствующие позиции меню, и поэтому далее мы их рассматривать не будем. Рассмотрим функции меню.

File - подменю предоставляет сервис в соответствии с CUA-стандартом:

File|New - очищает экран от дамп-сообщений;

File|Save - позволяет сохранить дамп-сообщения в файл:

File|Send - позволяет отослать дамп-сообщения через Microsoft Exchange;

File|Exit - позволяет завершить работу Агента. Аналогична нажатию на в правом верхнем углу окна. При выходе система спросит подтверждение на завершение работы Агента.

Подменю Edit также предоставляет предоставляет сервис в соответствии с CUA- стандартом:

Edit|Cut, Edit|Copy - предоставляют пользователю возможность сохранять дамп в Clipboard.

Подменю View предоставляет возможность управлять toolbar`ом и statusbar`ом:

View|Toolbar - управляет видимостью toolbar`а;

View|Status Bar - управляет видимостью statusbar`а.

Подменю Options предоставляет возможность управлять дампом, а также проверить работоспособность системы: (Данный пункт меню создавался исключительно для тестирования системы)

Options|Testing - при выборе этой позиции меню отображается немодальное окно, с помощью которого можно имитировать некоторые аварийные ситуации;

Рис. Окно тестирования

Используя Radiobuttons, администратор может записать информационные страницы RAID контроллера на диск, изменить их и заменить ими реальные страницы контроллера. Таким образом, можно имитировать практически любую ситуацию. Более простой способ - изменить состояние CheckBox`ов. В информационных страницах RAID`а принудительно возводятся соответствующие биты и можно проследить работу нотификации и работоспособность GUI.

Options|Test Mail - позволяет проверить отсылку e-mail, сообщение “Test mail” отсылается всем прописанным в ini-файле e-mail клиентам;

Options|Test MS net - позволяет проверить оповещение через MS Network messaging. Сообщение “Test Network” отсылается всем прописанным в ini-файле network клиентам;

Options|Logging - управляет выдачей дампа в главное окно. Если эта позиция меню отмечена, то команды, обрабатываемые Агентом, пишут сообщения в главное меню программы.

Общий вид модуля Менеджер

Данный модуль разрабатывался параллельно с разработкой модуля Агент. Тестирование работоспособности проходило при его непосредственном участии, ведь одна из задач Агента как раз в том, чтобы связать работу Менеджера и RAID-контроллера.

На рисунке 1.13 показан общий вид модуля Менеджер. На втором фоне мы видим, как при этом работает Агент.

Рис. Общий вид модуля Менеджер

Мы не будем рассматривать работу данного модуля глубоко, так как это не входит в рамки этого дипломного проекта.

Установка программного обеспечения

Для установки программного обеспечения на компьютер пользователя, необходимо запустить файл setup.exe, поставляемой вместе с системой. Программа установки не отличается от подобных программ, поскольку была создана при помощи популярной программы InstallShield, и с результатами работы этой программы сталкивался практически каждый пользователь.

По умолчанию, программа устанавливается в каталог C:\Program Files\Accusys\GUIMAN\, однако при установке пользователь имеет возможность выбрать другой каталог.

Рис. Установка программного обеспечения GUIMAN

При установке можно устанавливать либо оба модуля (Агент и Менеджер) сразу, либо по отдельности.

Конфигурация технических средств

Объем оперативной памяти, занимаемой модулем Менеджер равен порядка 10MB, модулем Агент - около 4Мб. Исходя из этих данных и тестированию на различных машинах, были установлены минимальные и рекомендуемые требования для работы ПО. Минимально необходимое оборудование должно иметь технические характеристики, указанные в таблице 1.3.

Таблица 1.3 Минимальные технические характеристики ПО

	Для модуля Менеджер	Для модуля Агент
PC	Pentium II 450 МГц	Pentium II 350 МГц
Оперативная память	64 MB	32 MB
Место на жестком диске	5 Мб	2 Мб
Монитор	SVGA	VGA
Сетевое устройство (только для удаленного администрирования)	Ethernet 10 Mbps	Ethernet 10 Mbps
Дополнительные устройства	-	RAID-массив Fibrenetix на базе контроллера i960

Необходимое программное обеспечение:

  Windows 98 или более поздние версии;

  Драйвера для RAID-контроллера;

  Драйвера для сети (только для удаленного администрирования);

При работе с ПО без удаленного администрирования к компьютеру предъявляются все перечисленные требования за исключением сетевого устройства.

Методика и результаты испытаний программы

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

Общие приемы тестирования

Среди методов, с помощью которых проводилось тестирование программы, можно выделить два основных:

  метод «стеклянного ящика»;

  метод «чёрного ящика».

Тестирование методом «стеклянного ящика» - это тестирование на этапе реализации. Данный метод можно отнести к процессу программирования, т.к. программисты выполняют тестирование на протяжении всего процесса создания ПО. Поскольку программист разрабатывает тесты, зная исходный код программы, он имеет определённые преимущества: направленность тестирования, полный охват кода, управление потоком, отслеживание целостности данных, внутренние граничные точки, тестирование, определяемое выбранным алгоритмом.

При тестировании разрабатываемого программного модуля, в основном применялись следующие способы отладки:

1) Отладка с помощью встроенного отладчика.

В среду программирования MS Visual C++ 6.0 встроен мощный и удобный в использовании отладчик. С его помощью возможно отслеживать значения произвольного количества переменных в процессе работы программы, осуществлять построчное выполнение кода, устанавливать точки останова программы и выхода в режим отладки.

2) Методы силовой отладки.

Под силовой отладкой (brute-force debugging) понимаются методы отладки, основанные не на возможностях отладчиков. При разработке программ часто нет необходимости в полной отладке, просто хочется убедиться в том, что какая-либо функция работает так, а не иначе. В этих случаях проще забыть об отладчике и просто добавить пару строк кода для вывода информации. Методы “силовой отладки”, были эффективны при отладке и тестировании данного программы и использовались наравне со средствами отладчика Visual C++.

3) Вывод отладочной информации на форме.

Один из способов вывода информации -- ее вывод непосредственно в форме. Обычно проще всего создать форму в редакторе ресурсов Visual C++ для непосредственного вывода информации. В таком случае выведенная информация не потеряется даже при перерисовке формы.

4) Использование функции AfxShowMessage.

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

5) Вывод на консоль и запись в лог-файл.

К методам силовой отладки также относятся “Вывод отладочной информации на консоль” и “Запись данных в Log-файл”. В первом случае создается консольное приложение и вывод на него осуществляется с помощью процедур cout и printf. Во втором случае вся информация записывает в файл на диске. В данном проекте информация, полученная из лог-файла, являлась самой ценной, поскольку точно указывала на место возникновения ошибок и неточностей в работе алгоритмов.

Тестирование работоспособности RAID-контроллера

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

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

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

В конструкторской части представлены технические требования к программному продукту, описаны алгоритмы работы ПО GUIRAID, а также модуля Агент, приведена структура входных и выходных данных. Представлены результаты работы программы и описаны методы тестирования и отладки программного обеспечения.

2. Технологический раздел

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

Это в первую очередь принципы объектно-ориентированного программирования. Особое внимание уделено методам и этапам создания программных продуктов и методам отладки, как инструментам создания надёжных программных продуктов.

2.1 Объектно-ориентированное программирование

При написании программы использовался объектно-ориентированный подход. Преимущества такого метода очевидны:

  объектная модель позволяет в полной мере использовать выразительные возможности объектных и объектно-ориентированных языков программирования;

  использование объектного подхода существенно повышает уровень унификации разработки и пригодность для повторного использования не только программ, но и проектов, что, в конце концов, ведет к созданию среды разработки. Объектно-ориентированные системы часто получаются более компактными, чем их не объектно-ориентированные эквиваленты. А это означает не только уменьшение объема кода программ, но и удешевление проекта за счет использования предыдущих разработок, что дает выигрыш в стоимости и времени;

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

  риск при разработке сложных систем уменьшается, поскольку интеграция заложена ещё при проектировании, а не производится в конце разработки.

Основой объектно-ориентированного программирования является объектная модель. Она имеет 4 главных элемента:

  абстрагирование;

  инкапсуляция;

  модульность;

  иерархия.

Кроме главных, имеются ещё 3 дополнительных элемента:

  типизация;

  параллелизм;

  сохраняемость.

Рассмотрим эти составляющие подробнее.

Следуя [2], абстракция выделяет существенные характеристики некоторого объекта, отличающие его от других видов объектов и, таким образом, чётко определяет его концептуальные границы с точки зрения наблюдателя. Абстрагирование концентрирует внимание на внешних особенностях объекта и позволяет отделить самые существенные особенности от несущественных. Важен принцип наименьшего удивления, который гласит, что абстракция должна охватывать всё поведение объекта, но не больше и не меньше, и не привносить сюрпризов или побочных эффектов, лежащих вне сферы её применения.

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

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

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

Иерархия - это упорядочивание абстракций по уровням. Примером иерархии является наследование - важнейший инструмент объектно-ориентированного программирования. Второй важной разновидностью иерархии является агрегация, определяющая отношение “part of”.

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

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

Ну и наконец, последний из элементов объектно-ориентированной модели - сохраняемость. Она представляет из себя способность объекта существовать во времени, переживая породивший его процесс, и (или) в пространстве, перемещаясь из своего адресного пространства.

2.2 Объектно-ориентированное проектирование

Рассмотрим принципы объектно-ориентированного проектирования, которое основано на объектно-ориентированной модели. Обычно процессы программирования и проектирования, отделенный от процесса управления (или микропроцесс в определении Гради Буча), состоит из следующих видов деятельности:

  выявление классов и объектов на данном уровне абстракции;

  выявление семантики этих классов и объектов;

  выявление связей между этими классами и объектами;

  спецификация интерфейса и реализация этих классов и объектов.

При этом в микропроцессе перемешаны фазы анализа и проектирования. Рассмотрим эти процессы более подробно.

Цель выявления классов и объектов состоит в том, чтобы найти границы предметной области. Кроме того, эта деятельность является первым шагом в продумывании объектно-ориентированной декомпозиции разрабатываемой системы. Этот шаг в анализе применяется, когда обнаруживается задача абстракции, составляющие словарь предметной области. Такие действия необходимы при проектировании, когда изобретаются новые абстракции, которые являются составными частями решения.

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

После выполнения этого шага можно переходить к выявлению семантики классов и объектов, то есть определению поведения и атрибутов каждой абстракции. На стадии анализа этот шаг применяется для распределения обязанностей между различными видами поведения системы. На стадии проектирования эта процедура позволяет распределить обязанности между частями реализации. При реализации следует продвигаться от описаний ролей и обязанностей в свободной форме к спецификациям конкретных протоколов для каждой абстракции и, в конечном счёте, - к точным сигнатурам (совокупностям признаков) каждой операции. Результатом становится уточнение словаря данных. В ходе проектирования можно выработать спецификации к каждой абстракции, перечисляя имена операций в протоколе каждого класса. Следующим шагом станет создание интерфейсов этих классов на языке реализации. Примером могут служить заголовочные файлы .h в С++. Также составляются диаграммы объектов и диаграммы взаимодействий, передающие семантику сценариев, создаваемых в ходе микропроцесса.

Целью выявления связей между классами и объектами - уточнить границы каждой ранее обнаруженной в микропроцессе абстракции и опознать все сущности, с которыми она взаимодействует. Это действие формализует концептуальное физическое размежевание между абстракциями, начатое на предыдущем шаге. Этот шаг применяется в анализе для спецификации связей между классами и объектами (включая некоторые важные отношения наследования и агрегации). Существование ассоциации подразумевает некоторую семантическую зависимость между двумя абстракциями и возможность перехода от одной сущности к другой. Этот этап проектирования нужен, чтобы специфицировать взаимодействия, которые формируют механизмы архитектуры и группирование классов в категории и модулей в подсистемы. Результатами этого шага являются диаграммы классов, объектов и модулей.

Реализация классов и объектов доводит существующие абстракции до уровня, достаточного для обнаружения новых классов и объектов, необходимых на следующем уровне абстракции. При проектировании с целью реализации становится создание осязаемого представления абстракций путём выпуска последовательных исполнимых версий системы (макропроцесс). Этот шаг намеренно выполняется позже всех, так как макропроцесс концентрирует внимание на поведении и откладывает решения о представлении. На этом шаге принимается решение о представлении каждой абстракции и об отображении каждой абстракций в физическую модель. В начале процесса разработки формулируются тактические решения о представлении в форме уточненных спецификаций классов. Решения, имеющие общий интерес, или подходящие для повторного использования, документируются на диаграммах классов (показывающих их статическую семантику), состояний или взаимодействия (показывающих их динамическую семантику). Когда становится ясно, на каком языке реализовывать проект, начинается программирование в псевдокоде или исполнимом коде. Для раскрытия связей между логическим и физическим уровнем, вводятся диаграммы модулей, которые затем можно использовать, чтобы показать отображение архитектуры в программную реализацию. С реализацией связано одно главное действие - выбор структур и алгоритмов, которые представляют семантику определённых ранее микропроцессом абстракций. В отличие от первых трех стадий микропроцесса, сосредоточенных на внешних представлениях абстракций, этот этап акцентирует внимание на их внутреннем представлении. На стадии анализа результаты этого действия относительно абстрактны, поскольку разработчик не столько обеспокоен реализацией сколько заинтересован в отыскании новых абстракций, которым можно делегировать обязанности. На стадии проектирования, особенно на поздних стадиях проектирования классов, нужно переходить к практическим решениям.

2.3 Этапы разработки программного обеспечения

Постановка задачи

Задача, которую предстоит решить программисту на ЭВМ, формулируется им самим или выдается ему в виде специального задания на разработку программы. Задание содержит формулировку задачи, необходимые характеристики разрабатываемой программы, требования к взаимодействию с ней. Выдаче такого задания для крупных задач может предшествовать большая работа научно-исследовательского характера.

Задание на разработку программы по форме и характеру должно быть аналогично техническому заданию (ТЗ) на разработку какого-либо технического продукта (см., например, ГОСТ 19.201-78 Единой системы программной документации).

Техническое задание полезно и в том случае, когда заказчик и исполнитель работают в одной и той же комнате или даже являются одним и тем же лицом. Наличие четкой письменной формулировки будет препятствовать подмене или отходу в процессе разработки программы от сформулированных в ТЗ требований в угоду каким-то другим побочным целям. Кроме того, письменно сформулированное задание делает возможным обсуждение, оценку или согласованную с заказчиками (пользователями) корректировку отдельных требований ТЗ в ходе разработки программы, ТЗ препятствует проникновению в программу таких ошибок и противоречий, которые могут быть обнаружены только после разработки большей части программы или уже на стадии анализа полученных результатов счета. Чем более формализованным по характеру будет техническое задание, тем больше шансов, что разрабатываемая программа будет решать именно ту задачу, которую имел ввиду заказчик.