Информатика, вычислительная техника
и управление
Автоматизация и управление технологическими процессами и производствами
Карасев Д.И., аспирант Московского государственного университета инженерной экологии
СПЕЦИФИЦИРОВАНИЕ ФУНКЦИОНАЛЬНЫХ ТРЕБОВАНИЙ К ИНФОРМАЦИОННО-АНАЛИТИЧЕСКОЙ СИСТЕМЕ
Введение
Регламент эксплуатации некоторых видов технологических объектов предписывает непрерывный мониторинг заданной линейки параметров специальными средствами контроля. Для визуализации и анализа этих параметров, переданных по каналам связи с удаленных объектов в специализированные интеграционные центры, используются информационно-аналитические системы (ИАС). Они обеспечивают сбор и накопление эксплуатационных данных, а также автоматический контроль за изменением их трендов.
Существующие централизованные ИАС эксплуатационного контроля удаленных объектов нуждаются в совершенствовании и расширении их функциональных возможностей в связи с возрастающей комплексностью этих систем. Однако модернизация программной структуры ИАС, выполненной по устаревшим технологиям, как правило, неэффективна по экономическим и технологическим критериям. Это предопределяет необходимость создания ИАС на основе разработки новых подходов к их построению для достижения универсальности и наличия механизма расширения функциональных свойств системы.
Согласно современным тенденциям программной инженерии при создании подобных систем целесообразен перенос основного акцента в разработке с программирования на проектирование. При этом в проектной модели ИАС закладываются все необходимые функциональные свойства системы и механизмы их расширения.
В данной статье рассматриваются некоторые вопросы объектно-ориентированного анализа информационно-аналитических систем, связанные с формализацией всей совокупности информации по функциональным требованиям.
Описание информационно-аналитической системы
Разрабатываемая система предназначена для обеспечения контроля и предоставления информации о состоянии технологической установки. Программное обеспечение системы будет работать в режиме «только отображение», т.е. не посылает никаких управляющих сигналов. Новая система должна будет работать совместно с существующей системой архивации, и использовать в качестве входных данных информацию из электронного архива состояний, данные в который поступают по каналам связи от средств контроля технологической установки.
Система должна выполнять следующие функции:
• автоматическая архивация поступающих данных;
• автоматическая численная обработка данных в соответствии с алгоритмами вычисления технологических параметров эксплуатации установки;
• запись вычисленных технологических параметров установки в базу данных;
• автоматическая аналитическая обработка технологических параметров путем сравнения с их уставочными значениями;
• автоматическое фиксирование отклонения технологических параметров от уставок в журнале состояний;
• сравнение оператором текущих параметров установки с сохраненными ранее в архиве для изучения динамики их изменения;
• графическая обработка технологических параметров в заданном временном диапазоне по запросу оператора;
• выдача по запросу оператора справки об узлах технологической установки по сгенерированным запросам к базе данных;
• поддерживать политику безопасности и разграничение прав для эксплуатации ИАС.
Разрабатываемая система должна создаваться в соответствии с архитектурой «клиент-
сервер» для работы под управлением операционной системы Windows 2000/ХР.
Специфицирование функциональных требований к ИАС
Разработка спецификации программного обеспечения, определяющей все функции и действия, которые будет выполнять система, является одним из фундаментальных процессов технологии разработки программных продуктов [1,2]. Этот процесс формирования, анализа, документирования и проверки этих функциональных возможностей и ограничений, называемый в терминологии программной инженерии «разработка требований», является критическим этапом в создании программного обеспечения, поскольку ошибки, допущенные на этом этапе, ведут к возникновению проблем на этапах проектирования и разработки ИАС.
Высокоуровневые обобщенные требования к системе выражаются в пользовательских требованиях, описанных на естественном языке и отраженных в поясняющих диаграммах. Детализированное описание системных функций и ограничений представляется в системных требованиях (функциональной спецификации). Обобщенным описанием структуры программной системы является проектная системная спецификация, дополняющая и детализирующая спецификацию системных требований, и являющуюся мостом между этапом разработки требований и этапом проектирования системы [3].
При разработке информационно-аналитической системы для спецификации требований выбрано инструментальное объектно-ориентированное CASE-средство - Rational Rose, основанное на стандартизованном языке моделирования Unified Modeling Language (UML). Взаимодействие между пользователем и системой в объектно-ориентированном представлении описывается совокупностью сценариев, каждый из которых является прецедентом (вариантом использования системы).
В результате проведенного анализа бизнес-процессов и в соответствии с постановкой задачи были определены основные акторы (исполнители, внутренние и/или внешние системы, взаимодействующие с ИАС).
Выделены следующие основные акторы:
• оператор - пользователь с правом доступа к технологической информации, ее обработке;
• администратор - пользователь с правом изменения настроек и конфигурации системы;
• модуль сигнализации - программный модуль системы, который в автоматическом режиме контролирует параметры на предмет выхода за уставки и ведет журнал событий;
• модуль архивации - программный модуль системы, который в автоматическом режиме сохраняет данные на жестком диске;
• модуль отображения - программный модуль системы, который в автоматическом режиме отображает графическую информацию на экране монитора;
• таймер - программный модуль системы, запускающий другие программные модули в соответствии с настройками.
В соответствии с процессом Rational Unified Process (RUP) прецеденты для разрабатываемой ИАС были представлены в шаблоне с базовой формой, учитывающей предусловия событий, основные и альтернативные потоки событий, постусловия событий [4].
Приведем пример описания прецедента «Контроль параметров», выполненного по шаблону тр.
1. Название прецедента: Контроль параметров.
1.1. Краткое описание
Данный прецедент выполняет автоматическую проверку контролируемых параметров на соответствие технологическим уставкам.
1.2. Актор
Таймер.
2. Поток событий:
2.1. Основной поток
2.1.1. В соответствии со списком контролируемых параметров система запрашивает из базы соответствующие им данные.
2.1.2. Система запрашивает из базы соответствующие технологические уставки.
2.1.3. Система последовательно сравнивает каждый параметр с его уставкой.
2.1.4. Если параметр вышел за пределы уставок, то система выводит соответствующее сообщение пользователю
2.1.5. Запись в журнал событий......................
2.2. Альтернативные потоки
Нет.
3. Специальные требования
Нет.
4. Предусловия
Должен быть выполнен прецедент проведен «Расчет».
5. Постусловия
Запускается прецедент «Отображение».
6. Точки расширения.
Отсутствуют.
По данной схеме были документированы все прецеденты, выявленные в результате анализа функциональных требований. Ниже приводятся краткие описания основных прецедентов ИАС.
• Идентификация. Этот прецедент позволяет пользователю идентифицироваться в системе и получить необходимые ему права доступа.
• Проверка обновления. Проверяется время и дата создания файлов данных о состоянии установки. Это нужно для того, чтобы старые данные не записывались в архив многократно, и по ним не проводился расчет.
• Архивация. Производится автоматическая архивация данных о состоянии установки.
• Расчет. После обновления базы данных происходит расчет параметров безопасности установок.
• Контроль параметров. Данный прецедент выполняет автоматическую проверку контролируемых параметров на предмет соответствия технологическим уставкам.
• Отображение. Система отображает текущую информацию на экранной форме. Обновление информации происходит после выполнения прецедентов «Проверка обновления», «Архивация», «Расчет», «Контроль параметров». Так же на форме выводятся все сообщения и предупреждения пользователю.
• Прореживание журнала. Производится удаление записей месячной давности из журнала состояний.
• Изменение списка контролируемых параметров. Данный прецедент позволяет администратору редактировать список контролируемых параметров.
• Корректировка расчетных констант. Позволяет администратору менять значения констант.
• Сравнение состояний. Этот прецедент позволяет оператору сравнивать основные параметры двух различных состояний установки.
• Сравнение с уставкой. Позволяет оператору сравнивать параметры с их уставочны-ми значениями.
• Справка по каналу. Оператор может запрашивать справку по любому из технологических узлов установки.
• Просмотр журнала. Прецедент предоставляет возможность оператору просмотреть журнал событий системы. Это нужно для контроля работы системы. Оператор может видеть все сбои происходившие в системе и анализировать их причины.
• Вывод графика. Оператор может выводить на экран графики параметров с заданным диапазоном дат и временным интервалом.
• Изменение настроек системы. Позволяет администратору менять системные настройки (конфигурировать систему).
Визуальное моделирование прецедентов ИАС, выполненное в Rational Rose в виде диаграммы прецедентов (Use case diagram), представлено на рис. 1. Данная диаграмма дает графическое представление активных субъектов (акторов), взаимодействующих с системой посредством тех или иных прецедентов.
По сути, данная диаграмма описывает поведение системы, отражает все функциональные требования к ИАС.
Последующая разработка системы, направленная на реализацию ее функциональных свойств, заключается в создании динамической модели. Динамичес
Для дальнейшего прочтения статьи необходимо приобрести полный текст. Статьи высылаются в формате PDF на указанную при оплате почту. Время доставки составляет менее 10 минут. Стоимость одной статьи — 150 рублей.