1 Конструкторский раздел
1.1 Анализ предметной области и постановка задачи
Анализ предметной области позволяет сформулировать ряд требований выдвигаемых заказчиком к программному продукту, которые можно разделить на три уровня [1]:
Бизнес-требования,
Требования пользователей,
Функциональные и нефункциональные требования.
Бизнес-требования содержат высокоуровневые цели организации или заказчиков программного обеспечения. Как правило, их высказывают те, кто финансирует проект, покупатели программного продукта, менеджер реальных пользователей или отдел маркетинга.
Требования пользователей описывают цели и задачи, которые программный комплекс позволит решить пользователям.
Функциональные требования определяют функциональность программного обеспечения, которую разработчики должны построить, чтобы пользователи могли выполнить свои задачи в рамках бизнес-требований.
Бизнес-правила включают корпоративные политики, правительственные постановления, промышленные стандарты и вычислительные алгоритмы. Они не являются требованиями к программному обеспечению. Однако они часто налагают ограничения, определяя, кто может выполнять конкретные варианты использования, или диктовать, какими функциями должен обладать программный комплекс, подчиняющийся соответствующим правилам. Иногда бизнес-правила становятся источником атрибутов качества, которые реализуются в функциональности.
Нефункциональные требования дополняют функциональные требования. Нефункциональные требования могут содержать:
дополнительное описание функций продукта, выраженное через описание его характеристик, важных для пользователей или разработчиков;
описание взаимодействия между системой и внешним миром;
ограничения дизайна и реализации.
Разработка требований включает три этапа:
Сбор предполагаемых требований путём опроса потенциальных пользователей о разрабатываемом продукте и анализ конкурентных продуктов;
Определение требований путём их материализации в виде письменного документа, интерактивного прототипа пользовательского интерфейса или в какой-либо иной форме;
Анализ требований путём выделения в них общностей и различий с последующим разбиением на важнейшие характеристики.
1.1.1 Межсетевые экраны вPOSIX-совместимых ОС.
Netfilter— это межсетевой экран (брандмауэр), встроеный в ядроLinuxверсий 2.4 и 2.6.Netfilterсостоит из двух больших групп компонентов, первая — компоненты включенные в состав ядра (и выполняющиеся в пространстве ядра), вторая — это команды и утилиты выполняющиеся в пространстве пользователя, сюда можно отнести командуiptables, ряд вспомогательных утилит, библиотеки, страницы справочного руководства и скрипты.
Iptables— название пользовательской утилиты (запускаемой из командной строки) предназначенной для управления системойnetfilter. С её помощью системные администраторы создают и изменяют правила, управляющие фильтрацией и перенаправлением пакетов.
Некоторые авторы под словом netfilterимеют в виду только те элементы межсетевого экрана, которые непосредственно являются частью стека протоколов ядра, а всё прочее (систему таблиц и цепочек) называютiptables. Из‑за не совсем ясной терминологии, иногда весь проект (внутриядерный межсетевой экран вместе с пользовательской утилитой) просто именуется «netfilter/iptables».
До появления iptables, для обеспечения возможностей межсетевого экрана в Linux использовались проекты ipchains в Linux 2.2 и ipfwadm в Linux 2.0, в свою очередь основанный на ipfw из системы BSD. Проекты ipchains и ipfwadm изменяли работу стека протоколов ядра Linux, поскольку до появления netfilter в архитектуре ядра не существовало возможностей для подключения дополнительных модулей управления пакетами. iptables сохранил основную идею ipfwadm — список правил, состоящих из критериев и действия, которое выполняется если пакет соответствует критериям. В ipchains была представлена новая концепция — возможность создавать новые цепочки правил и переход пакетов между цепочками, а в iptables концепция была расширена до четырех таблиц, разграничивающих цепочки правил по задачам: фильтрация, NAT‑трансляция, и модификация пакетов. Также iptables расширил возможности Linux в области определения состояний, позволяя создавать межсетевые экраны работающие на сеансовом уровне.
1.1.2 Группы пользователей
Для разрабатываемого продукта выделен один класс потенциальных пользователей: системные администраторы. Вне зависимости от квалификации, все они должны иметь доступ к одинаковому функционалу и справочному материалу. Предполагается, что даже начинающий администратор POSIX-совместимой ОСимеет представление о сетевых технологиях.
В качестве способа получения информации выбран опрос потенциальных пользователей и дискуссии с ними [1].
1.1.3 Бизнес-требования
Языки программирования, которые можно использовать для реализации проекта, должны иметь компиляторы или интерпретаторы в ОС семейства Linux, давать возможность взаимодействия сiptables, поддержку межпроцессного взаимодействияивозможность выполнения на веб-сервере. Это такие языки какC, Perl, Python, PHP.
Протокол удалённого соединения: HTTPS.
Авторизация пользователей должна проводиться по конфигурационным файлам (по сочетанию логина и пароля, по IP-адресу или имени хоста).
Необходимо учесть возможность блокирования удалённого доступа посредством изменения настроек брандмауэра и предупреждать пользователя в подобных ситуациях.
Только один пользователь одновременно может иметь доступ к изменению конфигурации.
1.1.4 Требования пользователей
Одним из способов представления требований пользователей являются диаграммы вариантов использования (диаграмы прецедентов, use case diagrams) [10], являющиеся частью языкаUML.
UML— язык графического описания для объектного моделирования в области разработки программного обеспечения.UMLявляется языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемойUMLмоделью.UMLбыл создан для определения, визуализации, проектирования и документирования в основном программных систем [8].
Основная задача - представлять собой единое средство, дающее возможность заказчику, конечному пользователю и разработчику совместно обсуждать функциональность и поведение системы [1]. Цель этого общения — выявить и формализовать требования к создаваемой системе.
Сложность разработки программного комплекса заключается во взаимодействии с пользователем, обработке его запросов, контроле корректности и безопасности. Это видно из полученных вариантов использования (см. рисунок 1 и таблицы 1-12). Применение вариантов использования позволяет выявить ту функциональность, с помощью которой пользователи будут выполнять конкретные задачи. Так удастся избежать появления функций, которые в ходе сбора информации могут казаться весьма полезными, однако которые не будет использоваться из-за того, что они не связаны напрямую с решением рабочих задач.
Рисунок 1 — Диаграмма вариантов использования
Таблица 1 — Вариант использования «Авторизация»
|
Название |
Авторизация |
|
Описание |
Пользователь вводит логин и пароль. В случае совпадения с имеющимися данными, пользователь допускается к работе с программным комплексом. |
|
Частота использования |
Является очень часто используемым. |
|
Входные условия |
Запущеные веб-сервер и браузер |
|
Выходные условия |
Загрузка главной страницы |
|
Нормальное направление |
1.0 Авторизация
|
|
Альтернативные направления |
1.1 Провал авторизации (этап 3)
|
|
Исключения |
1.0.И.1 Серверный демон недоступен (этап 5)
|
Таблица 2 — Вариант использования «Таблица правил»
|
Название |
Таблица правил |
|
Описание |
Пользователь просматривает таблицу правил |
|
Частота использования |
Является наиболее часто используемым. |
|
Входные условия |
Авторизация в программном комплексе |
|
Выходные условия |
Отображение страницы со списком правил |
|
Нормальное направление |
1.0 Просмотр таблицы правил
|
|
Альтернативные направления |
Нет. |
|
Исключения |
Нет. |
Таблица 3 — Вариант использования «Конструктор команд iptables»
|
Название |
Конструктор команд iptables |
|
Описание |
Пользователь составляет команду для утилиты iptablesиз составных частей. |
|
Частота использования |
Является часто используемым. |
|
Входные условия |
Авторизация пользователя. |
|
Выходные условия |
Изменённая таблица правил |
|
Нормальное направление |
1.0 Конструирование команды iptables
|
|
Альтернативные направления |
1.1 Недостаточно опций для требуемого правила (этап 5)
|
|
Исключения |
1.0.И.1 Недостаточно модулей для создания правил (этап 3)
|
Таблица 4 — Вариант использования «Просмотр списка модулей»
|
Название |
Просмотр списка модулей |
|
Описание |
Пользователь просматривает список доступных и активных модулей и изменяет их состояние. |
|
Частота использования |
Используется редко. |
|
Входные условия |
Авторизация пользователя. |
|
Выходные условия |
Изменённое состояние окружения сервера |
|
Нормальное направление |
1.0 Просмотр списка модулей
|
|
Альтернативные направления |
Нет. |
|
Исключения |
1.0.И.1 Не удалось изменить статус модуля (этап 10) 1. Скрипт веб-страницы выдаёт сообщение об ошибке. |
Таблица 5 — Вариант использования «Использование системных утилит»
|
Название |
Использование системных утилит |
|
Описание |
Пользователь выполняет системные утилиты диагностики и администрирования из ограниченного набора «первой необходимости» |
|
Частота использования |
Используется со средней частотой. |
|
Входные условия |
Авторизация пользователя. |
|
Выходные условия |
Результат выполнения утилит в виртуальном терминале. |
|
Нормальное направление |
1.0 Использование системных утилит
|
|
Альтернативные направления |
Нет. |
|
Исключения |
Нет. |
Таблица 6 — Вариант использования «Просмотр конфигурации»
|
Название |
Просмотр конфигурации |
|
Описание |
Пользователь просматривает файл конфигурации |
|
Частота использования |
Является редко используемым. |
|
Входные условия |
Авторизация пользователя. |
|
Выходные условия |
Файл конфигурации МСЭ. |
|
Нормальное направление |
1.0 Просмотр файла конфигурации
|
|
Альтернативные направления |
Нет. |
|
Исключения |
Нет. |
Таблица 7 — Вариант использования «Сохранение конфигурации»
|
Название |
Сохранение конфигурации |
|
Описание |
Сохранение текущей конфигурации шлюза в виде файла на машине пользователя. |
|
Частота использования |
Является редко используемым. |
|
Входные условия |
Авторизация пользователя, нахождение пользователя на странице просмотра конфигурации. |
|
Выходные условия |
Файл конфигурации, выданный пользователю для сохранения. |
|
Нормальное направление |
1.0 Сохранение конфигурации
|
|
Альтернативные направления |
Нет. |
|
Исключения |
Нет. |
Таблица 8 — Вариант использования «Загрузка конфигурации»
|
Название |
Загрузка конфигурации |
|
Описание |
Загрузка файла конфигурации с машины пользователя и его применение. |
|
Частота использования |
Является редко используемым. |
|
Входные условия |
Авторизация пользователя, нахождение пользователя на странице просмотра конфигурации. |
|
Выходные условия |
Изменение конфигурации МСЭ в соответствии с полученными данными. |
|
Нормальное направление |
1.0 Загрузка конфигурации
|
|
Альтернативные направления |
Нет. |
|
Исключения |
1.0.И.1 Анализ структуры выявил ошибки (этап 2)
|
Таблица 9 — Вариант использования «Просмотр руководства»
|
Название |
Просмотр руководства |
|
Описание |
Пользователь просматривает справочное руководство программного комплекса. |
|
Частота использования |
Является редко используемым. |
|
Входные условия |
Авторизация пользователя. |
|
Выходные условия |
Справочная информация. |
|
Нормальное направление |
1.0 Просмотр руководства
|
|
Альтернативные направления |
Нет. |
|
Исключения |
Нет. |
Таблица 10 — Вариант использования «Разделы руководства»
|
Название |
Разделы руководства |
|
Описание |
Просмотр раздела справочного руководства. |
|
Частота использования |
Используется со средней частотой. |
|
Входные условия |
|
|
Выходные условия |
Справочная информация. |
|
Нормальное направление |
1.0 Просмотр раздела справочного руководства.
|
|
Альтернативные направления |
1.1 Необходимость более детальной информации (этап 1).
|
|
Исключения |
Нет. |
Таблица 11 — Вариант использования «Просмотр системной справки»
|
Название |
Просмотр системной справки |
|
Описание |
Просмотр системной справки. |
|
Частота использования |
Является редко используемым. |
|
Входные условия |
Авторизация пользователя. |
|
Выходные условия |
Справочная информация. |
|
Нормальное направление |
1.0 Просмотр системной справки.
|
|
Альтернативные направления |
1.1 Вызов в качестве контекстной справки (этап 1).
|
|
Исключения |
Нет. |
Таблица 12 — Вариант использования «Выход»
|
Название |
Выход |
|
Описание |
Аннулирование авторизации. |
|
Частота использования |
Является редко используемым. |
|
Входные условия |
Авторизация пользователя. |
|
Выходные условия |
Аннулирование авторизации. |
|
Нормальное направление |
1.0 Выход
|
|
Альтернативные направления |
Нет. |
|
Исключения |
Нет. |
1.1.5 Функциональные и нефункциональные требования
Были выявлены следующие требования к функциональности программного комплекса:
возможность ввода команд по аналогии с командной строкой и с помощью компоновки опций;
наличие набора часто используемых команд;
наличие примеров конфигурации и возможность автоматического применения этих примеров;
использование защищённого соединения.
Существующие нефункциональные требования к комплексу администрирования:
отображение таблицы команд несколькими способами;
наличие контекстной справки;
сохранение истории авторизации и операций;
возможностьиспользования программного комплекса в образовательных целях.
1.1.6 Требования к производительности
Требования к производительности определяют, насколько быстро и качественно программный комплекс должен выполнять определённые функции. Они определяют такие параметры, как скорость (например, время отклика базы данных), пропускная способность (количество транзакций в секунду), мощность (нагрузка при совместном использовании) и распределение по времени (интенсивные запросы реального времени). Жёсткие требования к производительности сильно влияют на стратегию разработки программного обеспечения, поэтому необходимо определить задачи, касающиеся производительности, для соответствующей операционной среды [1].
Все функции программного продукта, не зависящие от скорости действий пользователя, можно разбить на пять функциональных видов:
авторизация;
отображение справочной информации;
выполнение команды;
отображение таблицы правил;
служебные функции.
Производительность всех функций зависит от пропускной способности линии связи между сервером и компьютером пользователя, а также от загруженности веб-сервера. Предполагается использование минимальной конфигурации, указанной в таблице 12.
Таблица 12 — Требования к аппаратному обеспечению
|
Компонент, характеристика |
Минимально допустимое значение |
|
Процессор, частота |
233 МГц |
|
Оперативная память |
64 Мб |
|
Свободное место на жёстком диске |
10 Мб |
|
Пропускная способность линии связи |
56 Кбит/с |
Выполнение команд также зависит от скорости работы утилиты iptablesи размера обрабатываемых таблиц.
Авторизация связана с чтением зашифрованных данных (паролей) и зависит от метода шифрования.
Отображение таблицы правил зависит от скорости работы утилит и от способа отображения: в случае графической визуализации быстродействие будет значительно ниже, чем при отображении результата работы команды iptables-save.
Быстродействие служебных функций (сохранение и чтение конфигурационных файлов) зависит от скорости работы системы.
Общие требования к быстродействию представлены в таблице 13.
Таблица 13 — Требования к производительности программного комплекса
|
Функциональная нагрузка |
Задержка выполнения |
|
Авторизация |
2-4 сек |
|
Отображение справочной информации |
4-6 сек |
|
Выполнение команды |
< 3 сек |
|
Отображение таблицы правил |
5-12 сек |
|
Служебные функции |
< 2 сек |