Обработка файлов

Спецификация требований для ПО загрузки
файлов с коммутационного оборудования
File Processing Framework,
Выпуск 1.0
Спецификация требований для ПО загрузки файлов
СОДЕРЖАНИЕ
Ведение .................................................................................................. 3
Назначение документа ............................................................................ 3
Функции продукта .................................................................................. 3
Общее описание ..................................................................................... 4
Глоссарий .............................................................................................. 4
Общий взгляд ......................................................................................... 4
Операционная среда ............................................................................... 5
Ограничения дизайна и реализации ......................................................... 5
Документация для пользователей ............................................................ 5
Функции системы ................................................................................... 5
Функциональные требования ................................................................... 5
Нефункциональные требования............................................................ 7
Требования к интерфейсам..................................................................... 10
Интерфейсы пользователей .................................................................... 10
Интерфейсы оборудования ..................................................................... 11
Версия 01.00
Стр. 1 из 12
Ведение
Назначение документа
Данная спецификация описывает функциональные и нефункциональные требования
к ПО (системе) для обработки файлов, получаемых преимущественно с
телекоммуникационного оборудования.
Все указанные требования относятся к выпуску 1.0.
Рабочее название проекта File Processing Framework (Система).
Функции продукта
act File Processing Framew ork
Предобработка
Логирование
Обработка
Постобработка
Конфигурирование
Система должна поддерживать следующие основные наборы функций:
1.
Предварительная обработка (предобработка или приемка файла): набор
процессов, которые исполняются с момента, когда Система узнает о наличии файла
(-ов) для обработки и до момента, когда система определяет формат файла и его
содержимое (см. ФТ-1.).
Примерами таких процессов могут служить следующие процессы:
a. Резервное копирование.
b. Валидация (без проверки внутреннего формата файла, например,
проверка контрольных сумм).
c. Разархивирование/расшифровка.
d. Уведомление заинтересованных сторон о поступлении файлов.
2.
Обработка (разбор принятых файлов и загрузка в BSS): набор процессов,
связанных с декодированием формата файла и операциями с его содержимым (см.
ФТ-2.).
Примерами таких процессов могут служить следующие процессы:
a. Валидация (проверка на соответствие внутреннему формату, на
полноту информации и корректности заполнения).
b. Загрузка записей из CDR-файлов в BSS (биллинговую систему).
c. Выборочная загрузка записей из CDR-файлов в BSS.
d. Статистический анализ файла.
e. Преобразование данных.
f. Перекодирование в другой формат.
3.
Постобработка (передача необходимой информации загруженных файлов из
базы данных BSS на требуемые ресурсы): набор процессов, исполняемых после
обработки (разбора, загрузки) файла до момента завершения работы с файлом (см.
ФТ-3.).
Примерами таких процессов могут служить следующие процессы:
a. Передача исходного (или трансформированного)
сервисам.
b. Уведомление об окончании обработки файлов.
c. резервное копирование.
файла
другим
Так же система должна поддерживать ряд вспомогательных процессов, связанных
с конфигурированием ее работы и логированием результатов:
4.
Конфигурирование (см. ФТ-4.).
a. Возможность удаленного конфигурирования.
b. Возможность загрузки конфигурации из CMDB/сервера конфигураций.
c. Возможность декларативного (с помощью xml и/или скриптовых
языков) изменения последовательности выполнения процессов в
рамках группы процессов.
d. Возможность изменения конфигурации на лету.
e. Возможность рестарта на лету.
f. возможность удаленного запуска/остановки.
5.
5.).
Логирование: запись отчетов всех действий по обработке файлов (см. ФТa. Возможность локальной/удаленной записи логов.
b. Возможность выборочной записи логов (по группе процессов, по
важность, серьезности, по типу файлов).
c. Возможность раздельного ведения error/performance/audit-логов.
d. Поддержка SNMP для отчетности о производительности.
Общее описание
Глоссарий
О-1.
Файл
–
файл,
сгенерированный
коммутационным
оборудованием,
информацию из которого необходимо загружать в базу данных BSS, для возможности
тарификации услуг связи (преимущественно), предоставленных абонентам.
О-2.
Ресурс для приема файлов – специальное место, доступное и известное
Системе (например, диск на сервере), на котором размещаются файлы для обработки
Системой.
О-3.
BSS – биллинговая система. Синоним – АСР (автоматизированная система
расчетов).
Общий взгляд
В настоящее время файлы с коммутационного оборудования обрабатываются
многочисленными программами–загрузчиками (около 50 шт.), реализованными в
виде исполняемых файлов. Каждая программа настроена на работу с файлами только
определенного формата и не может быть настроена на одновременную работу с
файлами нескольких форматов или с файлами одного и того же формата, но
расположенных на разных ресурсах для приема файлов.
Программный код существующих программ-загрузчиков в большинстве
случаев дублируется, но по некоторым причинам, например, из-за того, что
программы написаны в разное время и разными авторами, программный код
несколько варьируется. При появлении изменений в механизме работы с файлами
требуется вносить изменения в программный код каждой программы отдельно, при
этом, по причине того, что базовый код каждой программы может различаться,
требуется индивидуальный подход к отдельным программам-загрузчикам при
внесении изменений.
Разработка Системы планируется для создания единой платформы – File Processing
Framework – на базе которой должны реализовываться все приложения по обработке
файлов.
Готовая Система позволит:
1. Стандартизовать и унифицировать процесс обработки файлов, загружаемых в
систему BSS (а возможно, и в другие системы).
2. Упростить конфигурирование и администрирование процесса обработки
файлов.
3. Снизить затраты на сопровождение существующего программного кода для
обработки файлов.
Операционная среда
ОС-1.
ОС-2.
WinServer 2003, WinServer 2008, WinServer 2008 R2
NET Framework 4.0
Ограничения дизайна и реализации
ОДР-1. Документация системы по конструкции, коду и сопровождению должна
содержать следующие документы:
1. Диаграмму классов (в стандарте UML).
2. Описание интерфейсов.
3. Описание процессов.
4. Описание форматов:
a. Конфигурационных файлов.
b. log-файлов.
ОДР-2. Код системы должен соответствовать стандарту C# .NET 4.0
Документация для пользователей
ДП-1.
Документация для пользователей должна быть оформлена в виде связанных
wiki-страниц.
Функции системы
Функциональные требования
Перечень модулей внутри системы:
ФТ-1. Модуль приемки файлов. Осуществляет все действия по приему файлов,
поступивших на Ресурс для приема файлов.
ФТ-1.1. Модуль должен принимать информацию об изменениях в файловой
системе на Ресурсах для приема файлов каким-либо способом:
a. С помощью собственных механизмов сканирования Ресурсов для
приема файлов с настраиваемым интервалом времени (см. Модуль
настроек и конфигурирования системы).
b. В виде оперативных уведомлений от операционной системы об
изменениях в файловой системе на Ресурсах для приема файлов. После
чего, инициировать собственный механизм сканирования Ресурсов для
приема файлов.
ФТ-1.2. Модуль должен уметь сохранять поступившие на ресурсы файлы в
Системе, а копии этих файлов – на специальном ресурсе для Резервных
копий. Также Модуль должен удалять на этом Ресурсе устаревшие файлы.
Критерий удаления устаревших файлов должен определяться в
настройках Системы.
Настройки путей до всех используемых Системой ресурсов, а также
настройки структуры каталогов, которые Модуль должен автоматически
создавать при записи файла на ресурс, определяются Модулем настроек и
конфигурирования системы.
ФТ-1.3. Модуль должен уметь проводить процедуру первичной валидации для
поступивших на ресурсы файлов (без проверки внутреннего формата файла.
Например, только проверку контрольных сумм).
ФТ-1.4. После подтверждения валидности поступившего файла и по окончанию
всех операций по преобразованию файла (группы файлов) Модуль должен
уведомлять в режиме реального времени другие заинтересованные
(соучастные) Модули о поступлении нового файла (Модуль загрузки файлов,
Модуль логирования).
ФТ-2. Модуль обработки файлов. Осуществляет все действия по разбору и
загрузке файлов в BSS.
ФТ-2.1. Модуль должен получать уведомления от других Модулей о наличии
файлов
для
обработки.
Также
должна
быть
предусмотрена
функциональность, позволяющая Модулю самостоятельно определять
наличие файлов для обработки.
ФТ-2.2. Модуль должен проводить процедуру полной валидации файла,
принятого Модулем приемки файлов: определение и проверка внутреннего
формата файла, проверка полноты и коррекции информации в файле.
Критерии проверки должны быть настройками системы.
ФТ-2.3. Модуль должен извлекать информацию из файлов по схеме разбора,
настраиваемой для каждого формата файлов (см. Модуль настроек и
конфигурирования системы), и загружать эту информацию полностью,
выборочно, в исходном или преобразованном виде в BSS, в зависимости от
текущей конфигурации Системы (см. Модуль настроек и конфигурирования
системы).
ФТ-2.4. Модуль не должен загружать в BSS файлы с ошибочными записями.
Модуль должен сохранять такие файлы на специальном ресурсе для
Инвалидных файлов. Настройки путей до всех используемых Системой
ресурсов, а также настройки структуры каталогов, которые Модуль должен
автоматически создавать при записи файла на ресурс, определяются
Модулем настроек и конфигурирования системы.
ФТ-2.5. Модуль должен сохранять успешно загруженные файлы в Архиве
долгого хранения. Настройки путей до всех используемых Системой
ресурсов определяются Модулем настроек и конфигурирования системы.
ФТ-2.6. При незапланированных перерывах или сбоях в работе Системы,
необработанные (не до конца обработанные) файлы не должны потеряться.
При возобновлении работы Системы такие файлы должны попадать в
очередь на обработку.
ФТ-2.7. Модуль должен исключать повторные загрузки одних и тех же файлов
в BSS.
ФТ-2.8. Модуль должен исключать многократный процессинг одного и того же
файла (зацикливание) Например, в ситуациях, когда по каким-либо
причинам невозможно загрузить файл в BSS.
ФТ-2.9. Модуль должен сохранять в BSS дополнительную информацию о
файле. Перечень дополнительных полей должен быть настройкой в Системе.
ФТ-2.10. Модуль должен уметь уведомлять в оперативном режиме другие
соучастные Модули о результате разбора и загрузки файла в BSS (Модуль
постобработки, Модуль логирования).
ФТ-3. Модуль постобработки файлов. Осуществляет все действия по передаче
файлов, загруженных в BSS, на сторонние ресурсы или сервисы.
ФТ-3.1. Модуль должен получать уведомления от других Модулей о наличии
файлов
для
обработки.
Также
должна
быть
предусмотрена
функциональность, позволяющая Модулю самостоятельно определять
наличие файлов для обработки.
ФТ-3.2. Модуль должен сохранять файлы, загруженные в BSS, в Систему
Длительного Хранения. Настройки путей до всех используемых Системой
ресурсов определяются Модулем настроек и конфигурирования системы (см.
Модуль настроек и конфигурирования системы).
ФТ-3.3. Модуль должен быть наделен функциональностью, которая позволила
бы
передавать
файлы,
загруженные
в
BSS,
в
исходном
или
трансформированном виде, на сторонние ресурсы (например, на ресурс
файлов для ФСБ). Настройки путей и режимов передачи файлов до всех
используемых Системой ресурсов определяются Модулем настроек и
конфигурирования системы.
ФТ-4. Модуль настроек или конфигурирования Системы. Обеспечивает доступ
к конфигурационным параметрам для всех компонентов Системы для чтения и
записи (выборочно).
ФТ-4.1. Модуль должен быть наделен функциональностью чтения настроек
конфигураций Системы из СУБД, файла или другого возможного ресурса и
передачи этих настроек другим Модулям (по запросу).
ФТ-4.2. Модуль должен предоставлять возможность записи новых и изменения
существующих настроек Системы.
ФТ-4.3. Модуль должен уметь оперативно уведомлять другие соучастные
Модули об изменении настроек Системы (Модуль приемки файлов, Модуль
обработки файлов, Модуль Постобработки файлов).
ФТ-4.4. Должен быть определен единый интерфейс для обращения к Модулю
других Модулей Системы.
ФТ-5. Модуль логирования. Осуществляет запись отчетов всех действий по
работе Системы.
ФТ-5.1. Модуль должен получать уведомления от других Модулей о наличии
информации
для
записи.
Также
должна
быть
предусмотрена
функциональность, позволяющая Модулю самостоятельно определять
наличие информации для обработки.
ФТ-5.2. Модуль должен взаимодействовать со всеми Модулями Системы и
получать от них в режиме реального времени отчеты о состояние
выполняемых в Системе процессов.
ФТ-5.3. Модуль должен фильтровать поступающую информацию о работе
Системы, и, в зависимости от параметров информации (настройка Системы),
записывать ее на тот или иной ресурс (например, в СУБД, в файл и т.п.).
ФТ-5.4. Модуль должен быть наделен возможностями записи информации в
разных режимах (вся информация полностью, только ошибки и т.п.), исходя
из текущей конфигурацией Системы.
ФТ-5.5. Модуль должен позволять дополнять его различными механизмами
записи информации о работе системы (например, запись с поддержкой
SNMP-протокола).
ФТ-5.6. В случае невозможности записи отчетов в СУБД, Модуль должен уметь
записывать эту информацию в файл или иной ресурс для записи отчетов о
работе Системы.
ФТ-5.7. Модуль
должен
предоставлять
интерфейс
для
мониторинга
поступающей информации Администратором (см. интерфейс Мониторинга).
ФТ-5.8. Модуль должен быть снабжен механизмом отправки уведомлений о
событиях в Системе Администратору Системы через средства сервера, по
электронной почте или другой канал информирования (см. интерфейс
уведомлений).
Типы событий, о которых необходимо уведомлять, периодичность
отправки уведомлений, а также способы отправки должны быть настройками
Системы.
Нефункциональные требования
Общие
НТ-1. Система должна быть модульной.
НТ-2. В каждом Модуле должен быть независимый набор классов, представляющий в
совокупности интерфейс для обращения к функционалу Модуля.
НТ-3. Расширение функциональности Системы должно осуществляться путем
добавления новых Модулей (классов) без модификации существующих базовых
Модулей (классов). Допускаются использование механизмов динамической
загрузки и компиляции кода
НТ-4. При запуске какого-либо экземпляра программы должна осуществляться
проверка на уникальность запущенного экземпляра. Критерий проверки на
уникальность должен быть настраиваемой в Системе сущностью.
НТ-5. Система должна предоставлять функционал для обработки параметров
командной строки.
НТ-6. Система должна иметь встроенную систему обмена сообщениями между
запущенными экземплярами Системы.
НТ-7. Системе должна уметь реагировать на ситуации нарушения уникального
ключа. Выбор поведения Системы в такой ситуации должен быть настройкой
Системы.
Обработка файлов
НТ-8. Обработка файлов: обработка файлов в Системе должна вестись в несколько
потоков.
НТ-9. Обработка файлов: в Системе должна быть реализована возможность
обработки одним экземпляром программы однотипных файлов с разных
коммутаторов (с разным LOC) или с разных Ресурсов для приема файлов.
НТ-10.
Обработка файлов: размещение файлов с одинаковыми именами,
полученных с разных Ресурсов для приема файлов должно быть организованно в
разные каталоги хранения файлов.
Хранение файлов
НТ-11.
Для каталогов хранения файлов (Архив, Резервные копии, Инвалидные
файлы, Система длительного хранения) должна быть реализована гибкая система
механизмов формирования имен файлов и подкаталогов (например, по префиксам
и суффиксам для файлов, по дате модификации или обработки файлов, по пути
до Ресурса для приема файлов).
Логирование
НТ-12.
Логирование: процесс записи отчетов о работе Системы должен быть
возможен с распределением по уровням или категориям. В случаях записи отчета
по нескольким уровням Модуль логирования должен уметь вести параллельную
запись по нескольким уровням. Разделение на уровни в Системе должно быть
настраиваемой сущностью.
НТ-13.
Логирование: при записи отчетов о работе Системы (логирование) во
всех сообщениях должен четко указываться идентификатор источника (Модуля,
класса, потока) от которого получена записываемая информация.
Также должна быть указана следующая информация (в разумных
количествах1):
a. [логин@]база_данных
b. версия приложения
где
логин – логин пользователя для запуска программы;
база данных – наименование базы данных, с которой в данный момент
работает Система;
версия приложения – текущая версия Системы.
НТ-14.
Логирование: система должна обеспечивать вывод всех параметров
приложения считываемых из конфигурации (при начальном считывании и при
каждом последующем изменении параметров) в сообщения отчетов о работе
Системы. Если какой-то из параметров отсутствует, то это должно быть отражено,
даже если для него есть значение по умолчанию.
Требования к производительности
Требования к безопасности
ТБ-1. Система должна запрашивать параметры доступа для всех своих компонентов
при запуске или уметь считывать эти параметры из конфигурационного файла.
Параметры доступа в конфигурационном файле должны храниться в
зашифрованном виде.
1
Например, если для потока база данных одна и та же, достаточно упомянуть её один
раз.
Атрибуты качества ПО
АК-1. Система должна быть реализована в виде одной (единой) программы
(приложения) или сервиса.
Допускается наличие нескольких экземпляров (копий) программы, в случае
приложения. В случае сервиса – наличие двух исполняемых файлов: файл
сервиса и файл с GUI-приложением для управления сервисом (или набором
сервисов) и для мониторинга его (их) работы.
АК-2. Система должна работать по расписанию. Расписание должно являться
настройкой системы.
АК-3. Система должна принимать файлы со всех Ресурсов приема файлов.
АК-4. Система должна обрабатывать все форматы файлов, загружаемые в BSS.
АК-5. Система должна иметь удобные интерфейсы взаимодействия с Пользователем
(см. Интерфейсы пользователя).
АК-6. Для
настроек
конфигураций
Системы
должна
быть
предусмотрена
возможность хранения их в СУБД, в файле. Настройки должны подразделяться на
две группы: автосохраняемые параметры (интерфейс, логины и т.п.) и
статические настройки приложения (app.conf – read only для приложения,
app.rw.conf – read&write для приложения).
Для каждой группы настроек должно быть отдельное хранилище с отдельными
правами доступа.
Перечень настроек:
АК-6.1. Приемка файлов: данные о Ресурсах приема файлов (входные
каталоги).
АК-6.2. Приемка файлов: данные о частоте сканирования файлов с
ресурсов приема файлов.
АК-6.3. Обработка файлов: данные о местах загрузки и режимах
загрузки информации из файлов в BSS.
АК-6.4. Обработка файлов: данные о ресурсах складирования файлов:
Архив, Резервные копии, Инвалидные файлы, Система длительного
хранения и прочие необходимые для работы системы каталоги. В том
числе структура подкаталогов для записи на перечисленные ресурсы
(например, наименование папки, содержащее дату записи файла в
папку/дата формирования файла/).
АК-6.5. Обработка файлов, Приемка файлов: критерии, правила
хранения файлов на перечисленных выше ресурсах (например,
удаление файла по истечению срока давности создания файла).
АК-6.6. Обработка файлов: данные о частоте reconnect-а к базе данных.
АК-6.7. Обработка файлов: данные о схемах разбора всех форматов
файлов, с которыми будет работать Система, связь формата файла и
DLL для обработки файла.
АК-6.8. Обработка файлов: критическое время обработки файла.
АК-6.9. Обработка файлов: критерии проверки корректности полей
файлов, загружаемых в BSS (например, соответствие размеров
значений на соответствие размерам полей в базе данных BSS).
АК-6.10. Обработка файлов: поля дополнительной информации о файле,
которая должна быть записана в базу данных BSS:
a. LOC (коммутатор)
b. Дата модификации файла
c. Дата обработки файла
d. Статус обработки файла (не загружен/загружен)
e. Контрольная сумма (MD5, SHA)
f. Размер файла
g. Ресурс приема файла
h. Процент обработки | смещение в файле | порядковый номер записи
АК-6.11. Логирование: данные о путях к ресурсам записи информации о
работе Системы, структуре подкаталогов для записи эти ресурсы.
АК-6.12. Логирование: зависимость ресурсов для записи информации о
работе Системы, полученной от Модулей, от параметров информации:
a. КАКИЕ КРИТЕРИИ?
АК-6.13. Логирование: режимы записи информации:
a. Полная запись информации полученных отчетов: включает в себя все
записи.
b. Выборочная запись информации: по группе процессов, по важность
файла, по типу файла.
c. Раздельная запись информации: в разные файлы или таблицы в
зависимости от уровня или категории записываемой информации
(error/performance/audit).
АК-6.14. Логирование:
типы
событий,
для
которых
необходимо
отправлять уведомления.
АК-6.15. Логирование: периодичность отправки уведомлений для разных
типов событий.
АК-6.16. Логирование: механизм отправки уведомлений (через средства
сервера, по электронной почте).
АК-6.17. Логирование: список подписчиков на уведомления с привязкой к
экземплярам программы, а также к конкретным коммутаторам.
АК-6.18. App.Title (свойство, хранящее заголовок приложения или
системное имя сервиса).
АК-6.19. MainForm.Caption (заголовок главного окна или отображаемое
имя сервиса).
АК-6.20. App.Hint (всплывающая подсказка у иконки в области
уведомлений).
АК-6.21. Интерфейсные параметры (например, логины в базу данных).
АК-6.22. Критерий проверки на уникальность запущенного экземпляра
программы (например, проверка уникальности пути до приложения,
проверка уникальности путей до обрабатываемых файлов, проверка
уникальности коммутатора, с которого обрабатываются файлы).
АК-6.23. Расписание работы программы (например, периоды активности
приложения).
АК-7. Система должна автоматически восстанавливать работу при сбое и
продолжать работу с того места, на котором закончила работать до сбоя.
Периодичность reconnect-а к базе данных BSS должна быть настройкой Системы.
АК-8. Система должна обрабатывать ситуации interrupted (прерванные операции):
прервать обработку файла, закончить все открытые транзакции на некотором
месте, а при следующем запуске по возможности возобновить обработку этого же
файла с того места, на котором произошла остановка, или начать обработку
заново.
Требования к интерфейсам
Интерфейсы пользователей
ПИ-1. Для Системы должны быть синхронизированы App.Caption и MainForm.Caption.
ПИ-2. Интерфейс мониторинга работы системы. Система должна быть снабжена
интерфейсом взаимодействия с Администратором системы, в котором в режиме
реального времени будут отображена подробная информация о всех процессах,
выполняемых системой.
В интерфейсе Мониторинга работы системы должны быть отображены следующие
разделы:
ПИ-2.1. Количество файлов, успешно загруженных в BSS за период.
ПИ-2.2. Количество файлов, записанных в хранилище Инвалидных
файлов за период.
ПИ-2.3. Процентный показатель обработки файла (для случаев долгой
обработки файла). Критическое время обработки файла должно быть
настройкой Системы.
ПИ-2.4. Объем использования памяти.
ПИ-2.5. Перечень используемых (задействованных) DLL.
ПИ-2.6. Показания производительности работы Системы.
Перечень разделов и отображаемая в них информация должны быть настройками
системы.
ПИ-3. Интерфейс уведомлений. Система должна быть снабжена механизмом
оперативного уведомления Администратора о событиях в Системе:
Для механизма уведомлений должны быть реализованы следующие
возможности:
ПИ-3.1. Подписка пользователей на уведомления о незагруженных
файлах с привязкой к конкретным коммутаторам (LOC).
ПИ-3.2. Выбор механизма отправки уведомлений подписчику.
ПИ-4. Интерфейс управления настройками системы. Система должна быть
снабжена интерфейсом управления Администратора настройками Системы.
ПИ-5. Интерфейс для работы с логами. Система должна быть снабжена
интерфейсом для работы Администратора с логами, записанными Системой.
Интерфейсы оборудования
Программные интерфейсы
НТ-15.
Все классы, реализующие процессы внутри Модулей должны
основываться на единых интерфейсах.
НТ-16.
Взаимодействие между Модулями Системы должно быть реализовано на
основе единых интерфейсов.
НТ-17.
Система
должна
иметь
интерфейс
для
добавления
новой
функциональности в Систему.
Интерфейсы передачи данных