«ТЕОРЕТИКО-КАТЕГОРНЫЕ МОДЕЛИ И МЕТОДЫ ПРОЕКТИРОВАНИЯ БОЛЬШИХ ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ ...»

Всего в работе построено и исследовано 5 нетривиальных формальных технологий, описывающих проектирование ключевых составляющих информационно-управляющих систем. Из них 3 оказались аспектно нетривиальными (и в работе подробно рассмотрены их аспектноориентированные расширения). Основные свойства исследованных технологий перечислены в следующей таблице (Таблица 1).

Таблица Назначение формальной Раздел работы Структурируема (определение 2.5) Скоординирована (определение 2.7) Поддерживает параллелизм (определение 2.8) (Ко)однородна (определения 2.11, 2.12) Поддерживает трассирование (определение 4.1) Элементарна (определение 4.2) Аспектно тривиальна (определение 4.6) Аспектно универсальна (определение 4.14) Аспектно полна (определение 4.17) L-трансформационна для некоторого L (определение 5.2)

Глава 1. СИСТЕМНЫЙ АНАЛИЗ ЖИЗНЕННОГО ЦИКЛА БОЛЬШИХ

ИНФОРМАЦИОННО-УПРАВЛЯЮЩИХ СИСТЕМ

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

Для составных сущностей важно проследить их мереологические связи вида «часть–целое» – представить в системе все их части (и/или сущности более высокого порядка, в которые они входят в качестве частей). Способность сущностей описывать другие сущности (выступать в роли «метаданных») порождает дескриптивные связи, ответственные за рост сложности информационной структуры системы. Сущности, обладающие функциональностью, вступают в телеологические связи вида «цель–средство», замыкание которых (например, включение обеспечивающих процессов в контур автоматизации наряду с основными) приводит к росту количества функций системы и появлению конфликтующих целей.

Перечисленные типы связей, вместе с масштабными факторами и примерами массивов данных, приобретающих «большой» размер вследствие замыкания, приведены в таблице (Таблица 2).

Таблица Топологическая Близость Распределенность Реестр абонентов Каузальная Причина–следствие Историчность Журнал документооборота Мереологическая Часть–целое Иерархичность Организационная Дескриптивная Абстрактное–конкретное Сложность Классификатор видов Телеологическая Цель–средство Многофункциональность Реестр оборудования Чтобы быть большой, система не обязана обладать большими значениями всех масштабных факторов. Например, исторически первой сверхбольшой системой является глобальная сеть Интернет. Она предназначена для обмена данными в квазиреальном времени между узлами – аппаратными единицами, подключенными к каналам связи пропускной способностью 103– 109 бит/с, охватывающим большинство мест присутствия человека и техники. Каналы образуют иерархию сегментов – подсетей (subnets), выражающуюся в позиционной структуре сетевого адреса узла [53]. В 2012 г. Интернет насчитывал почти 109 узлов [198] и 5105 подсетей верхнего уровня [164]. Таким образом, сеть Интернет обладает большими значениями распределенности и иерархичности. Значения остальных факторов невелики, поскольку история, структура и функциональность узлов не имеет значения с точки зрения доступности сети. Тем не менее, даже в региональном масштабе создание и эксплуатация сегментов сети Интернет ставит ряд нетривиальных технических задач. В их решении на территории Сибирского региона принимал участие автор [149, 150, 151].

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

Для увеличения полезного эффекта от информационных систем их нагружают поддержкой разнообразных процессов сбора и обработки информации. Процессом в теории систем называется целое, части которого образуют непрерывные причинно-следственные цепочки и сами являются процессами [102, с.151]. Если видов процессов немного и они достаточно коротки (так что общее количество функций системы исчисляется десятками), то они привносят в большую информационную систему только один дополнительный масштабный фактор – историчность, вызванную необходимостью хранить результаты и журналы исполнения процессов.

Такие системы называются транзакционными (transaction processing systems), в отечественной литературе их также называют автоматизированными системами обработки данных (АСОД) [111]. К ним относятся международные платежные системы и магазины, электронные средства массовой информации, системы мониторинга, среды распределенных вычислений и др. На концептуальном уровне мы предлагаем рассматривать их как совокупности каналов сбора и распространения информации, образующих виртуальную сеть [86]. Такой подход развивает концепцию измерительного канала, зафиксированную в метрологических стандартах [35]: здесь каналы выполняют не только передачу данных, но и (де)мультиплексирование, перевод на разные языки и в разные форматы, журналирование, архивирование, резервирование системных ресурсов. Каждому процессу сопоставляется некоторая конфигурация таких функционально богатых информационных каналов. При участии автора был разработан ряд транзакционных систем такого типа в области автоматизации научно-исследовательской деятельности: портал математических ресурсов MathTree [16], электронный атлас мониторинга окружающей среды «Атмосферные аэрозоли Сибири» [36, 39, 212, 215], система коллективной разработки онтологий предметных областей ONTOGRID [45, 46, 47, 48], единый каталог сотрудников научных организаций [104].

Чтобы превратить транзакционную систему в полноценную информационноуправляющую, в контур автоматизации необходимо включить все процессы, происходящие на объекте: основные, обеспечивающие и управляющие (а также обеспечивающие для обеспечивающих и т.д.). Если объект достаточно велик, то они характеризуются многочисленностью, разнонаправленностью, глубокой иерархической/сетевой организацией, поэтому автоматизированная система приобретает большие значения всех пяти масштабных факторов. К числу таких объектов относятся протяженные разветвленные сети производства, распространения, хранения, переработки, потребления потоков ресурсов: энергии, сырья, грузов. В качестве субъектов управления выступают энергоснабжающие организации, крупные предприятия нефтегазового сектора, металлургические холдинги полного цикла, железнодорожные монополии, муниципалитеты больших городов и др.

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

например некоторые потребители стремятся экономить – получать как можно меньше ресурса.

Кроме того, большой размер объекта вынуждает разделять его на сегменты, передаваемые в управление разным организационным единицам. Границы сегментов обычно проводятся исходя из распределения собственности, истории взаимоотношений и т.п., поэтому часто не совпадают с естественными границами технологических участков. Возникает концептуальный разрыв между уровнем управления технологическими процессами («уровень АСУТП») и уровнем корпоративного управления («уровень АСУП»), усугубляющий разноречивость требований участников процессов. Часто не удается выработать даже единый язык общения между ними: реестр технологических узлов объекта значительно отличается от бухгалтерского реестра основных средств. Тем не менее, критерии эффективности необходимо балансировать, поскольку автоматизируемые процессы объединяют участников, несмотря на различия их функциональной и административной подчиненности, и имеют сквозной характер [43, с.26].

Количественный «портрет» типичной информационно-управляющей системы для большого сетевого объекта выглядит следующим образом. Фактор распределенности задается составом объекта и насчитывает 103–107 единиц. Глубина хранения истории обычно составляет 103–105 записей на единицу, в зависимости от периода измерения показателей состояния объекта. Иерархия и структурная сложность насчитывают по 101–102 уровней (эти значения можно считать «большими», поскольку человеческий мозг очень плохо справляется с навигацией по уровням целостности и абстрактности [101]). Количество функций составляет 103–104 штук.

Характерным примером системы такого масштаба служит Smart Grid («умная» сеть) – система сквозной автоматизации крупной электроэнергетической сети, направленная на балансирование экономических интересов и технических возможностей поставщиков электроэнергии с разноречивыми настроениями потребителей [142].

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

Эта схема помогает увидеть основную концептуальную проблему, связанную с поддержкой больших значений масштаба. Дело в том, что артефакты процессов инженерии информационных систем могут вступать друг с другом только в отношения «часть–целое» и «абстрактное–конкретное». Действительно, все действия, выполняемые в процессе создания системы, сводятся к (де)композиции составных артефактов (например, детализация требований, сборка приложения из объектных модулей) и трансформации (refinement) абстрактных артефактов в конкретные (например, реализация спецификации на языке программирования) [244]. В то же время сущности, составляющие объект управления, связаны отношениями всех пяти типов.

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

Для топологических и каузальных связей эту проблему можно решить путем сохранения их в базе данных: они отображаются на мереологические связи структур данных. Эффективность их хранения и обработки в большом масштабе достигается путем экстенсивного наращивания количества и мощности вычислительных узлов, параллельно выполняющих навигацию по ним согласно потребностям автоматизированных функций. Разнообразные средства разработки таких узлов предоставляются технологиями параллельных и распределенных вычислений [26]. Однако с телеологическими связями поступить подобным образом в общем случае не удается, поскольку с ростом масштаба они неизбежно приобретают конфликтность, запутанность и изменчивость. В свою очередь, схемы данных рассчитаны на относительно редкие изменения, поэтому оформление изменчивых отношений «цель–средство» явными ссылками между информационными объектами приводит к необходимости постоянно производить ресурсоемкие, длительные, чреватые ошибками операции перестройки хранилища данных. Не менее трудно выразить крупномасштабные телеологические связи через иерархию сборки модулей в систему, поскольку модуль создается для автоматизации заранее заданных задач, имеет заранее заданный интерфейс доступа и поставляется в виде цельного фрагмента исполняемого кода. При заранее фиксированных и медленно меняющихся требованиях к системе разделение на модули приводит к уменьшению сложности и ускорению создания системы [95]. Однако чтобы получать полезную отдачу от модулей в априори не известных и постоянно меняющихся условиях их использования, приходится проникать в их внутреннюю структуру в обход интерфейса и даже принудительно «рассеивать» их по системе.

1.2. Ограничения качества больших информационно-управляющих Несмотря на трудности выявления требований в условиях роста масштаба, для любой сколь угодно большой системы должны быть заданы свойства, определяющие ее функциональное назначение и качество [258]. Они характеризуют ее способность удовлетворять потребности пользователей – готовность к разнообразным воздействиям, которым она подвергается со стороны внешнего окружения в течение эксплуатации. По отношению к информационноуправляющей системе, как и к любому автомату, важнейшим воздействием служит запрос на выполнение той или иной функции. Однако ничуть не меньшее значение имеют другие, «нефункциональные», воздействия: инсталляция, изучение, модификация, наложение ограничений по ресурсам и даже нанесение вреда [78]. Иллюстрацией их важности служит печально известный пример системы автоматизации работы лондонской службы «скорой помощи». Эта система вела себя в полном соответствии с функциональными требованиями, но оказалась непригодной к практическому использованию из-за несоответствия пользовательского интерфейса привычкам диспетчеров и постоянных потерь данных в ненадежной среде городских беспроводных коммуникаций [157].

При формулировке нефункциональных требований пользователи обычно испытывают значительные затруднения. Это связано с отсутствием достаточного опыта работы с информационно-управляющими системами, который позволял бы на интуитивном уровне чувствовать баланс между его возможностями и ограничениями. Например, заказчик веб-портала требует от него способности одновременно обслуживать 1 млн запросов с задержкой не более 1 мс. При этом он выделяет более чем скромный сервер и удивляется, что разработчики не могут его «как следует настроить». В отношении материальной продукции дело обстоит иначе, поскольку необходимый опыт накоплен в течение многих тысячелетий жизни в физическом мире. Так что нефункциональные требования даже при «небольшом» масштабе плохо поддаются точному описанию и проверке, часто не допускают количественной оценки, вступают в противоречие с функциональными и друг с другом. Чтобы формулировать, обеспечивать и проверять требования к программной продукции, нужны специальные подходы, учитывающие ее специфику по сравнению с материальными изделиями. Наиболее широко распространенные из таких подходов становятся основой стандартов качества программного обеспечения (software quality).

Рассмотрим международный стандарт ISO/IEC 9126 «Information Technology – Software Product Evaluation – Software Quality Characteristics and Guidelines for their use» (в России он принят под названием ГОСТ Р ИСО 9126-93 «Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению» [32]). Он предписывает задавать требования качества (quality requirements) как ограничения на значения показателей (attributes), подлежащих выявлению и измерению. Обычно требование имеет вид рейтинга (rating level), когда диапазон значений делится на поддиапазоны, задающие степень «качественности» изделия. Процедура оценки качества, которую проходит законченное изделие либо версия, сводится к измерению и ранжированию всего набора показателей, по результатам которого составляется заключение. В стандарте ISO/IEC 9126 показатели сгруппированы в шесть характеристик (characteristics), соответствующих готовности к типовым видам воздействия на программное обеспечение, выявленным из накопленного опыта его эксплуатации: функциональные возможности, надежность, практичность (удобство), эффективность, сопровождаемость, мобильность (переносимость). В качестве приложения к стандарту приведены рекомендации по выделению 21 подхарактеристики (subcharacteristics), к которым относятся конкретные показатели.

Систематическое применение стандартов качества особенно важно в процессе создания больших систем, в который вовлекается большое количество разнородных разработчиков. Здесь выявление состава и диапазонов допустимых значений показателей качества осложняется ввиду проблем, описанных в разд.1.1. Из-за них многие показатели попадают на «метауровень», характеризуя не обеспечение конкретных потребностей, а возможность удовлетворить широкий класс разноречивых требований [237]. Достижение высоких значений таких показателей придает системе сходство с живым организмом: в ней появляются механизмы ассимиляции, самовосстановления, целенаправленного поведения.

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

Однако потребительский эффект от их реализации не будет достигнут, если не удастся организовать потоки выполнения функций «вдоль» изменчивых сквозных процессов. Чисто функциональная организация системы не позволяет обеспечить управляемость большим объектом, поскольку вне системы практически невозможно проверять факты выполнения функций многочисленными исполнителями, относящимся к разным организационным единицам. Необходимо встроить в систему средства компоновки схем исполнения и контроля сквозных процессов, причем должна быть предусмотрена возможность изменять ход выполнения уже идущего процесса (в рамках, не нарушающих его корректность) [167]. Конкретные функциональные требования следует формулировать в привязке к шагам процессов, их входам и выходам.

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

Уровень практичности большой системы определяется возможностью предоставить информацию каждому пользователю в каждый момент времени в формате и объеме, не превосходящем порог постижимости и в то же время достаточном для выполнения его действий. Система должна защищать пользователя от «лавины данных» (data deluge) [195], постоянно поступающих из ее многочисленных компонентов-«сенсоров». Для этого необходимо вести текущий контекст действий пользователя и в соответствии с ним фильтровать терминологию и наполнение информационных видеокадров. Вместе с тем, следует постоянно показывать пользователю индикаторы и напоминания, фокусирующие его внимание на самых важных данных. Также целесообразно визуализировать мнемонические схемы объектов и процессов с переменной степенью детализации (zoom) – от очень грубого эскиза объекта управления в целом «с высоты птичьего полета» до детального изображения той части, которая в данный момент интересует пользователя [112].

Интенсивность «лавины данных» также оказывает критическое влияние на эффективность больших систем. Длительность циклов обработки данных, затрагивающих систему в целом, как правило, достаточно велика – от часа до месяца (103–106 с), поскольку более оперативные циклы отрабатываются внутри компонентов низкого уровня [160]. Однако большое количество источников данных (до 107 ед.) приводит к необходимости параллельно выполнять соответствующее количество циклов. Такой параллелизм в сочетании с пространственной распределенностью источников требует распараллеливания функций хранения и обработки данных.

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

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

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

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

Таблица Характеристика качества Порождающий показатель по ISO/IEC Функциональные Поддержка изменчивых сквозных процессов возможности (functionality) Надежность (reliability) Способность функционировать в условиях постоянных Практичность (usability) Динамическая подстройка визуализации информации Эффективность (efficiency) Параллельное выполнение циклов сбора и обработки данных Сопровождаемость Способность к непрерывной ассимиляции компонентов (maintainability) Мобильность (portability) Совместное функционирование компонентов, В настоящее время Международная организация стандартов ISO разрабатывает обновленную целостную модель описания и оценки качества, известную под названием ISO SQuaRE («Systems and software Quality Requirements and Evaluation» – «Требования качества к программному обеспечению и их оценка»). В частности, в 2011 г. стандарт ISO/IEC 9126 был заменен стандартом ISO/IEC 25010:2011 «Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models». В нем характеристика «Функциональные возможности» расщеплена на три: функциональная пригодность (functional suitability), совместимость (compatibility), защищенность (security). В стандарте ISO/IEC 9126 они выступали в качестве подхарактеристик характеристики «Функциональные возможности». Соответственно, порождающий показатель этой характеристики можно расщепить на три: один характеризует качество средств автоматизированной поддержки отдельных шагов процессов, другой – возможности сборки этих средств в комплексы автоматизации сквозных процессов, третий – разграничение прав участников процессов в точном соответствии с их функциями в процессе. Другие отличия стандарта ISO/IEC 25010:2011 от ISO/IEC 9126, такие как уточнение наименований некоторых характеристик и добавление/удаление подхарактеристик, не требуют существенной переработки нашей типовой модели качества.

Значения показателей качества должны постоянно измеряться и проверяться на предмет нахождения в допустимом диапазоне в течение всего жизненного цикла системы. Процедуры измерения, проверки и внесения корректировок при нарушениях становятся все более трудоемкими по мере роста масштаба системы, поэтому нуждаются в автоматизации. Чтобы она была возможной, необходимо построить формальную модель качества (quality model) – описать структуру показателей на формальном языке, не допускающем многозначных толкований. Для записи показателей можно использовать те или иные формальные методы инженерии программного обеспечения [73], однако наибольший интерес представляют специализированные языки, совместимые со стандартами качества. Среди таких языков мы выделим NoFun [156], основанный на стандарте ISO/IEC 9126. Он предоставляет выразительные средства для структурированного типизированного описания показателей качества, а также для формулировки требований в виде ограничений на значения (метрики) этих показателей. Нотация напоминает декларативный фрагмент современного языка программирования. Система типов (domains) включает примитивные типы (Boolean, Integer, Real, String), перечисления (enumeration), структуры (tuple), множества (set) и даже функции (function). Можно задавать подтипы (например, положительные числа) путем наложения ограничений. Характеристики качества изделий объединяются в модули (modules), допускающие иерархическую организацию путем наследования.

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

Чтобы упростить реализацию средств машинной обработки моделей качества, нами разработана структурная нотация представления конструкций языка NoFun, основанная на языке XML [216]. Здесь для записи арифметических и теоретико-множественных конструкций, с помощью которых задаются метрики и ограничения, привлекается стандартная XML-нотация MathML [223]. Рассмотрим его применение для описания показателей надежности информационно-управляющей системы. Например, время восстановления, измеряемое в часах, задается числовой функцией, определенной на иерархически организованном множестве классов (видов, типов, экземпляров) компонентов. Предположим, что для класса «измерительный комплекс»

оно составляет 1 час. «Зная» это значение, система может автоматически по факту прекращения поступления результатов измерений составить расписание оповещений эксплуатирующего персонала и корректирующих действий, таких как переход на резервные приборы. Приведем для этого случая (частичные) декларации трех модулей: тип компонентов, показатели качества, требования надежности. В них элементы нотации xNoFun набраны жирным шрифтом.

Classes of system components D_System_components Data_metering_complex A_Recovery_time A_Recovery_time D_System_components A_Recovery_time A_Recovery_time Data_metering_complex Полное формальное описание модели качества в таком ключе можно рассматривать как машинно-читаемую спецификацию целей системы. Поэтому ее наличие открывает богатые возможности для привлечения агентных технологий и платформ. Для этого модель качества должна быть дополнена набором терминов и знаний о предметной области объекта управления, достаточным, чтобы агенты могли эффективно взаимодействовать и принимать решения о достижении целей [237]. Такие наборы называются онтологиями (ontology) [185]. Формирование онтологии является чрезвычайно сложной и ресурсоемкой процедурой, которую невозможно провести в рамках цикла разработки отдельной системы, даже большой. Для этого организуются специальные научные исследования, результаты которых фиксируются в международных стандартах, содержащих готовые формальные описания онтологий. В настоящее время такие исследования активно ведутся в областях, обладающих собственными формализованными языками: математика, химия и т.д. Предлагаются нотации представления онтологий в виде, удобном для применения в информационных технологиях, среди которых на роль стандарта претендует структурный язык Web Ontology Language (OWL) [231], основанный на языке XML. Онтологии, составленные на языке OWL, легко расширяются новыми фрагментами при помощи ссылочных связей (принцип «открытого мира»).

Существуют средства автоматизации процесса разработки онтологии, например графический редактор OWL-документов Protg [217], предоставляющий визуальную среду для просмотра и изменения онтологии. Однако он изначально не был приспособлен для коллективной работы распределенных групп экспертов, которые могут одновременно редактировать разные фрагменты онтологии, рецензировать результаты других экспертов, и даже конфликтовать за один и тот же фрагмент. Только в результате такой коллективной работы могут создаваться онтологии, заслуживающие доверия. Ясно, что ее эффективное выполнение невозможно без полномасштабной автоматизации: здесь требуется распределенная транзакционная система типа электронного документооборота, оперирующая с предложениями на изменение фрагментов онтологии и периодически консолидирующая взаимно согласованные наборы реализованных предложений в стабильные версии готовой онтологии. Чтобы обеспечить высокую динамику вовлечения групп, работающих в разных странах и в разнородном системном окружении, автор и его коллеги реализовали такую систему на базе технологий Grid, оформив ее компоненты в виде грид-сервисов [45, 46, 47, 48]. Отметим, что в настоящее время инструмент для коллективной разработки онтологий предлагают и создатели редактора Protg [257].

В качестве примера рассмотрим разработанный нами фрагмент онтологии предметной области «управление большим объектом», описывающий измерение физических величин – одну из ключевых базовых функций системы управления [72]. Источником терминов для нее естественным образом служит метрология – наука о выполнении измерений. Ее положения стандартизованы и изложены в нормативных документах, в частности ключевые термины и определения зафиксированы в стандарте ГОСТ Р 8.596-2002 «Метрологическое обеспечение измерительных систем. Основные положения» [35]. Он определяет измерительную систему (Measuring_system) как совокупность компонентов (Component): измерительных (Measвычислительных связующих uring_component), (Connecting_component), вспомогательных (Auxiliary_component), комплексных (Complex_component), образующих измерительные каналы. Измерительный канал (Measuring_channel) – это часть измерительной системы, выполняющая законченную функцию от восприятия измеряемой физической величины (Physical_quantity) до получения результата ее измерения (эта функция обозначается отношением (). Точка измерения на объекте управления – это место подключения измерительного канала-источника первичных данных, так что измерительные каналы выступают в роли контейнеров метаданных результатов измерения. Каждый измерительный канал входит в систему (), а компонент – в один или несколько каналов (). Физически компоненты (Measuring_instrument), непосредственно измеряющих величины (), причем измерительная система как целое также является сложным средством измерений.

Каждая из вышеназванных сущностей является вещью (Thing) – базовым понятием языка OWL.

Общая схема получившейся базовой онтологии представлена на рисунке: понятия обозначены овалами, классификационные отношения «частное–общее» (is-a) – сплошными линиями, прочие отношения – пунктирными линиями.

Отношения между понятиями используются в качестве «строительного материала» для формирования правил вывода предметных знаний. Логическое исчисление, позволяющее записывать правила на языке OWL, называется дескриптивной логикой (descriptive logic). Например, условие физической реализуемости измерительного канала задается следующей импликативной конструкцией: если канал измеряет некоторую физическую величину, то он содержит компонент, реализованный средством измерения, непосредственно измеряющим ее [85]. Символически это правило выглядит так:

M, Q: Measures(M, Q) С, I: BelongsToChannel(C, M) & Чтобы иметь возможность описать все классы задач и свойств информационноуправляющей системы, к базовой онтологии подключаются другие [72]. Например, понятие физической величины конкретизируется понятиями, зафиксированными в онтологии физических величин и единиц измерения согласно Международной системе единиц. Общее понятие средства измерений конкретизируется видами и техническими характеристиками приборов. Для задач управления энергообеспечением большой набор онтологий разработан в рамках модели CIM [143]. Чтобы можно было описывать задачи уровня АСУП, добавляются онтологии понятий организационного и процессного управления, основанные на международных стандартах электронного обмена деловой информацией типа ebXML [210]. Благодаря им, в частности, появляется возможность задавать организационную принадлежность измерительных каналов и процессы управления их жизненным циклом, наделяя систему функциями класса CALS (Continuous Acquisition and Lifecycle Support [105]).

1.3. Принципы рационального проектирования больших систем Решения о наиболее рациональных способах организации системы, обеспечивающих заданные значения показателей качества, принимаются в ходе ее проектирования. Цель проектирования состоит в формировании архитектуры системы. Понятие архитектуры применительно к программным системам определено в стандарте ISO/IEC/IEEE 42010:2011 «Systems and software engineering – Architecture description» следующим образом: архитектура – это «фундаментальные концепции и свойства системы, находящейся в своем окружении, воплощенные в ее элементах, отношениях и принципах ее конструирования и развития» (fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution) [199, п.3.2]. Архитектура фиксируется в разнообразных описаниях – «осязаемых» результатах работ проектировщиков. Выбор нотации для каждого описания обусловлен стилем проектирования. В [130, с.80] перечислены следующие стили:

стиль взаимодействия, выражающий взаимодействие в виде диаграмм вариантов использования, схем процессов и т.п.;

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

информационно-ориентированный стиль, описывающий модели данных в виде диаграмм «сущность–связь»;

потоковый стиль, фиксирующий потоковую структуру системы в диаграммах потоков данных.

Каждый стиль отвечает одному из четырех способов работы c информацией, доступных программам: ввод/вывод, аналитическая обработка, хранение, передача [102]. Многие технологии программирования специально ориентированы на поддержку того или иного стиля. Они предоставляют средства переработки моделей, выполненных в этом стиле, в компоненты различных видов: сервисы, агенты, драйверы, портлеты, компоненты EJB (Enterprise Java Beans), библиотеки, хранилища данных и др. Компоненты снабжаются интерфейсами – специально подготовленными частями, предназначенными для интеграции с другими компонентами, в том числе разработанными при помощи других технологий. Система как целое комплексируется из компонентов, обращающихся друг к другу через интерфейсы [129].

Стиль взаимодействия применяется для проектирования компонентов большой информационно-управляющей системы, которые обслуживают три вида ее контрагентов: измерительные приборы и регуляторы, пользователей, смежные автоматизированные системы управления. Контрагенты находятся вне границ системы, поэтому каждый сеанс взаимодействия контролируется компонентами защиты информации. Компоненты взаимодействия с приборами предназначены для сбора информации о физическом окружении системы и телеуправления исполнительными устройствами. Они относятся к уровню АСУТП, поэтому реализуются на базе средств критического (dependable) характера, таких как системы класса SCADA. Компоненты взаимодействия с пользователями отвечают за требования эргономики (удобства), среди которых важную роль играет доступность, поэтому в качестве среды для их развертывания выбирается портал на базе web-технологий. Взаимодействие со смежными системами обычно выполняется на уровне АСУП, поэтому для его реализации привлекаются интеграционные платформы на базе сервисно-ориентированной архитектуры, организующие обмен структурированными электронными документами. При помощи таких платформ целесообразно также организовывать взаимодействие между компонентами системы, принадлежащими разным крупным архитектурным единицам (подсистемам). Источником корректных терминов для наименований элементов протоколов взаимодействия, форм пользовательского интерфейса и структурных единиц документов способна выступать онтология предметной области. Например, в XMLформате 80020, предназначенном для обмена данными о потреблении электрической энергии [1], тег, к которому привязываются значения количества энергии, называется measuringchannel.

Алгоритмические компоненты в основном предназначены для расчета и анализа данных в целях формирования достоверной картины состояния объекта и выработки управляющих воздействий на него. Основной цикл расчета воспроизводит подход системного анализа «в количественном выражении»: вычисляются показатели эффективности автоматизированных процессов, выявляются недопустимые расхождения между их фактическими и возможными значениями, рассчитываются наиболее рациональные корректирующие воздействия [106]. Дополнительно решаются вспомогательные расчетные и аналитические задачи. Здесь привлекаются разнообразные вычислительные средства, даже простое перечисление которых выходит далеко за рамки настоящей работы. Чтобы обеспечить эффективность, целесообразно развертывать их в динамической гетерогенной среде распределенных вычислений типа Grid или облака (cloud).

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

Основным информационным компонентом системы является информационная модель объекта управления (ИМОУ) – всеобъемлющее хранилище метаданных автоматизированных процессов. Она может быть получена из онтологии предметной области, путем трансформации в диаграмму «сущность–связь», реализуемую средствами реляционной СУБД. В состав модели объекта входят реестры организационной структуры, оборудования и приборов, каналов измерения и управления, процессов, расчетных алгоритмов [9], поэтому ее также называют паспортом объекта. Для нормирования записей реестров заводятся всевозможные справочники и классификаторы. Например, базовая онтология, приведенная в разд.1.2, порождает реестр измерительных каналов, диаграмма «сущность–связь» которого представлена ниже [72].

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

MCC MC MI PQ MCCT,

MCCT (Measuring channel component types) – множество типов компонентов.

Для выборки информации из модели целесообразно предусмотреть универсальный программный интерфейс – профиль выборки данных [64]. Он представляет собой реляционную структуру, описывающую совокупность извлекаемых сущностей путем явного перечисления и/или по ограничительным критериям (например «все трансформаторы, установленные на заданной подстанции»). Каждый профиль имеет наименование и целевую функцию (класс задач, для которых требуется выборка). Посредством профилей можно задавать контрольные списки доступа субъектов к информации (access control lists), наборы технических средств для группового управления, предпочтения пользователей, правила заполнения генерируемых отчетов, входные данные для алгоритмов расчета и анализа, шаблоны обработки событий. Чтобы составлять сложные профили, реализуются теоретико-множественные операции над ними. Компонент извлечения данных, удовлетворяющих заданному профилю, представляет собой, по существу, решатель задач в ограничениях (constraint solver), реализованный средствами реляционной СУБД. Он может быть достаточно ресурсоемким, поскольку выполняет, в частности, навигацию по связям, ответственным за большие значения масштабных факторов.

При извлечении данных из хранилища большой системы возникает проблема обеспечения их взаимной согласованности. Она вызвана нестабильностью большого объекта управления: для достаточной широкой выборки часто выполняется соотношение где Tстаб – характерный период времени, в течение которого ни одна из выбранных сущностей не изменяет свое состояние, Tвыб – характерное время жизни выборки, Tизм – характерная длительность полного цикла изменения участка объекта. Иными словами, выборка строится и обрабатывается настолько медленно, что нельзя пренебречь изменением состояния объекта в течение времени ее жизни, и вместе с тем настолько быстро, что нельзя считать изменения атомарными и целостными. Сходная проблема встречается при проектировании средств синхронизации в больших распределенных системах: невозможно установить глобальное время, единое для всех компонентов [122]. Решатель профилей выборки данных должен обнаруживать и игнорировать частичные, незавершенные изменения, формируя самосогласованный условнопостоянный образ запрашиваемой части объекта, пригодный в качестве полной информационной базы для выполнения задачи выборки [7, 141]. Конечно, это может привести к снижению уровня актуальности решения задачи (например, прогноз потребления энергоустановки может не учесть аварию, вызвавшую ее полное отключение), однако позволяет избежать трудноуловимых ошибок, вызванных несовместимостью состояний различных элементов выборки.

Рассмотрим применение потокового стиля при проектировании большой системы. В ходе выполнения автоматизированных процессов ее компоненты взаимодействуют между собой, обмениваясь данными и командами. Существует два основных потока обмена: «восхождение»

параметров состояния объекта управления с уровня АСУТП на уровень АСУП, и «нисхождение» управляющих воздействий в обратном порядке [111]. По ходу потоков информация форматируется и нормируется, сохраняется в базах данных, агрегируется и детализируется, фильтруется в соответствие с политикой безопасности, визуализируется в разнообразных представлениях для пользователей. Потоки можно представить виртуальными каналами сбора и обработки данных, как в транзакционных системах, только необходимо предусмотреть мощные средства динамической перестройки топологии и функциональности каналов. Для этого применяется событийная модель, согласно которой система снабжается компонентами мониторинга состояния и реагирования на события. Они обеспечивают ведение единого всеобъемлющего журнала событий, отражающих изменения состояния системы, и оперативное оповещение компонентов обработки событий о фактах их возникновения [90, 91]. Предметом мониторинга являются не только узлы объекта управления, но и компоненты самой системы, в отношении которых проверяется работоспособность, время отклика и другие показатели качества. Богатый набор правил оповещения и средств их обработки позволяет придать системе высокий уровень автономности – способности автоматически оптимизировать свою конфигурацию при изменениях во внешнем окружении, например переходить на резервную аппаратную единицу в случае отказа основной. Для реализации подобных функций можно применять технологии автономных вычислений [228].

Компоненты и потоки данных образуют следующую «порождающую» типовую крупноблочную функциональную архитектуру большой информационно-управляющей системы [6].

Проектирование средств автоматизации конкретного процесса состоит в его отображении на типовую архитектуру, так что она служит своего рода «системой координат» для проектировщиков. В результате отображения реализация задач, составляющих процесс, рассредоточивается по компонентам, выполненным в разных стилях. Например, автоматизация технического обслуживания и ремонта оборудования требует и поддержки взаимодействия с исполнителем работ (обмена юридическими и техническими документами), и расчета оптимального графика ремонтов, и расширения информационной модели объекта. Ни один стиль не может быть выбран в качестве доминирующего, поэтому проектное решение рассеивается по равноправным разнородным составляющим. В больших системах составляющие обычно многочисленны и сложно связаны друг с другом, поэтому для обеспечения полноты автоматизированной поддержки процесса необходимо тщательно трассировать требования – явно прослеживать их воплощение в архитектурных единицах. Трассирование является важнейшим способом обеспечения результативности процесса реализации задач, поскольку оно устанавливает сквозную двунаправленную взаимосвязь между разнородными артефактами жизненного цикла системы – характеристиками качества, спецификациями, моделями архитектуры, программным кодом, массивами данных, тестами, электронными документами, экранными формами [205]. Эта взаимосвязь в общем случае носит характер отношения «многие-ко-многим»: не только реализация одной задачи входит в несколько артефактов, но и один артефакт реализует много задач. Поэтому в качестве источников и назначений трасс лучше всего использовать не цельные артефакты, а их фрагменты, каждый из которых реализует одну задачу. Разбиение артефактов на такие фрагменты способно радикально улучшить показатели сопровождаемости системы, поскольку именно на фрагменты направлены типовые воздействия, выполняемые при сопровождении (согласно стандарту ISO/IEC 9126, к ним относятся анализ функционирования системы, модификация функций, локализация изменений, тестирование [32]). Если удается выделить фрагменты компонента в самостоятельные единицы сборки системы, то возможно эффективно проводить ассимиляцию компонента, размещая каждый фрагмент по месту потребности в нем.

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

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

Разноречивость целей приводит к тому, что задачи перемешиваются (tangle) друг с другом – не всегда можно строго провести границы между ними. Хуже того, реализация задачи может рассеиваться (scatter) по системе, пересекая (crosscut) границы единиц модульной архитектуры (процедур, классов, таблиц базы данных) и глубоко «погружаясь» в контекст своего исполнения. Качество автоматизации такой задачи зависит не только от качества средства ее реализации, но и от полноты его проникновения во все части системы. Такие рассеянные задачи порождаются как функциональными возможностями (например, ведение информационной модели объекта, верификация данных), так и нефункциональными требованиями (ведение журналов, защита информации и т.д.) [235]. Границу такой задачи невозможно записать при помощи традиционных нотаций проектирования и инструментов (CASE-средств), поскольку они трактуют каждую модульную единицу как элементарную (неделимую). Кроме того, CASE-средства, специализированные для частных технологий проектирования, плохо транслируют трассировочную информацию на артефакты других технологий, поэтому не удается автоматически прослеживать трассы. В результате обеспечение полноты трассирования с достаточно мелкой гранулярностью требует значительных затрат ручного труда [205].

Для снижения затрат мы предлагаем трассировать только наиболее важные требования к реализации задач, причем на достаточно грубом уровне. В этом мы следуем подходу, известному как трассируемость, основанная на значимости (value-based requirements traceability) [171].

Поскольку сопровождаемость большой системы критическим образом зависит от ассимилируемости компонентов, мы предлагаем трассировать в первую очередь интеграционные интерфейсы артефактов, описывающие возможности встраивания в систему [76]. Такое трассирование порождает разметку интерфейсов классами задач, которую целесообразно оформлять как дополнительную структуру артефактов (такое оформление трассировочной информации принято в большинстве современных автоматизированных инструментов поддержки трассирования [138]). Например, журнал событий системы оснащается разметкой классами задач, выполнение которых приводит к их возникновению [6]. В терминах разд.1.1 можно сказать, что крупно гранулированные телеологические связи задач погружаются в дескриптивные связи артефактов, путем повышения уровня структурной сложности последних. Технологии проектирования должны расширяться механизмами преобразования дополнительной структуры в ходе разработки артефактов компонентов и комплексирования в системы (и одновременно сужаться путем исключения действий, разрушающих дополнительную структуру). Эти механизмы должны поддерживать рассеяние задач и работать однотипно в разнообразных технологиях.

Выработка таких механизмов входит в число целей аспектно-ориентированного программирования (АОП) [208] – парадигмы, предложенной в конце 1990-х годов для поддержки реализации рассеянных задач. Изначальная мотивация его создателей состояла в отсутствии в традиционных языках программирования конструкций, позволяющих выполнять разделение ответственности (separation of concerns) – разделять перемешанный исходный код по классам задач. Технологии аспектно-ориентированной разработки программ (aspect-oriented software development, AOSD) отличаются способами разделения, но сходятся в стремлении обеспечить сквозную трассируемость. Они имеют вид расширений традиционных технологий (в первую очередь, объектно-ориентированных): сначала «локальные» (нерассеянные) задачи реализуются обычными модулями, а затем в них вставляются аспекты – самостоятельные артефакты, реализующие рассеянные задачи. Вставка аспектов выходит за рамки традиционной компоновки модулей (linking), не позволяющей модифицировать поток исполнения программы, поэтому она называется связыванием (weaving). Связывание может выполняться как на этапе компиляции, путем генерации перемешанного кода, так и в процессе исполнения, путем вызова предварительно скомпилированных аспектов.

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

Распространена практика обращаться к этим задачам по окончании реализации основных функций, поэтому возможность реализовать их отдельными артефактами и затем автоматически вставить в готовые функциональные модули приводит к значительному уменьшению затрат (по сравнению с ручной модификацией модулей). Вставлять аспекты действительно можно автоматически, если удается задать места обращения к ним на синтаксическом уровне – как точки выполнения операторов определенного вида (присваивание, вызов метода и т.п.). Приведем наглядный пример на языке AspectJ (это аспектно-ориентированное расширение языка Java [166]) – распечатка всех вызовов методов, наименования которых начинаются со слова init (инициализировать). Ручная реализация такой задачи включает поиск этого слова в текстах всех программ системы, умозрительное отделение вызовов методов (от наименований переменных, комментариев и др.) и вписывание обращения к функции печати после них. Компилятор AspectJ выполняет всю эту работу автоматически, получив на вход аспект следующего вида:

public aspect methodCallLogging { // Регулярное выражение, задающее точки вставки кода аспекта в исходную программу pointcut methodCalled(): execution(public * init*(..));

// Действие, вставляемое после каждой точки after(): methodCalled() { System.out.println("Method call: " + Примеры такого рода свидетельствуют, что рассеяние присуще задачам обеспечивающих процессов, включенных в контур автоматизации. Если ассортимент этих процессов исчерпывается техническим обслуживанием системы, так что их связь с основными можно выразить в программно-технических терминах, то эффект применения классических технологий АОП очевиден. В связи с этим даже предлагалось формально сопоставлять аспекты всем нефункциональным требованиям качества программных изделий [263]. Однако в больших информационно-управляющих системах автоматизируемые обеспечивающие процессы выходят далеко за рамки программно-технических: они обладают значительным разнообразием, оказывают заметное влияние на показатели результативности основных процессов почти на каждом шаге и в то же время плохо совмещаются с ними на понятийном уровне. Потребность в технологии типа АОП обостряется, поскольку привязка средств их автоматизации к основным в условиях применения традиционных «модульных» подходов сопряжена со значительными затратами ручного труда [24]. В качестве примера рассмотрим задачу ведения информационной модели (паспорта) объекта управления. Информация, подлежащая занесению в паспорт, формируется по ходу многих процессов, например:

сведения о собственности задаются в рамках процедур корпоративного управления;

технические характеристики оборудования устанавливаются в процессах пусконаладки и технического обслуживания;

разнообразные коды назначаются в ходе процессов кодирования и инвентаризации;

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

В традиционных средствах ведения информационных моделей каждому элементу сопоставляется монолитный набор атрибутов («карточка»), отражающий его участие во всех процессах без разделения по ним. Именно такое проектное решение диктуется «модульными» подходами к проектированию информационных систем, в том числе объектно-ориентированным подходом. Информацию об элементе можно ввести/получить только путем полного заполнения/чтения всей карточки, причем часто эти действия атомарны – не разделимы между многими пользователями. Но на достаточно крупном объекте нет и не может быть одного пользователя, владеющего информацией из всех процессов, поэтому приходится формировать карточки вне системы (например, рассылая по электронной почте файлы формата Excel) и далее передавать их оператору системы для однократного ввода. Значения многих атрибутов выяснить таким путем, в отрыве от контекста процесса-источника, не удается, и они заполняются «мусором». В итоге степень достоверности паспорта в целом неуклонно снижается, в конечном счете делая его непригодным к использованию. Нет возможности управлять качеством паспорта, заполняя карточки частично – в объеме, достаточном для поддержки выполнения заданного подмножества процессов.

Таким образом, обеспечение актуальности и достоверности паспорта требует разметки его атрибутов процессами-источниками значений, а задача ведения паспорта должна рассеиваться по артефактам, реализующим соответствующие шаги процессов. Самая мощная система ведения паспорта, оснащенная высокоинтеллектуальными алгоритмами анализа и корректировки данных, не принесет никакой пользы, если информация не будет поступать непрерывно по мере изменения объекта. Возникает естественное поле применения аспектно-ориентированного подхода, только не на этапе программирования, а раньше – при проектировании задачи ведения паспорта. Оформить в виде аспекта нужно модель этой задачи в подходящей нотации и автоматически вставить ее в модели процессов. Инструменты для такого аспектно-ориентированного моделирования существуют (например, инструмент WEAVR, позволяющий изобразить аспекты в виде действий и связать их с диаграммами состояний языка UML [264]), но в целом такое моделирование развито гораздо слабее, чем АОП. Дело в том, что современные аспектноориентированные технологии не имеют единой семантической базы, которая позволила бы обеспечить их совместимость друг с другом, прямой переход к реализации средствами АОП, формальную проверку корректности [238]. Как отмечается в [247], эти технологии «имеют разное происхождение и преследуют различные цели при поддержании характерных возможностей аспектно-ориентированного подхода». Поэтому для получения значимого эффекта от применения АОП в ходе проектирования необходимо создать его универсальную семантическую модель.

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

Здесь аспект представляет собой не что иное, как средство реализации одного класса задач – артефакт, интерфейс которого размечен единственной меткой. Связывание описывается как присоединение аспектов, выполняемое по одной и той же специальной структурной схеме на уровне «модульных» основ и разметок связываемых артефактов. Правила построения этой схемы не зависят от выбора технологии проектирования. В большой информационноуправляющей системе целесообразно реализовать такую схему на базе событийной модели, оформляя каждый аспект как обработчик некоторой совокупности событий, вызываемый динамически по факту регистрации событий [6]. Таким образом, аспектно-ориентированный подход позволяет обеспечить достижение одного из ключевых функциональных показателей качества системы – способности динамически подстраивать ход исполнения процессов [193]. Как показано в разд.5.3, для задачи ведения паспорта объекта таким путем удается спроектировать рассеяние с сохранением разметки элементов задачами-источниками. Получается совместная модель данных и процессов, размеченных в результате трассирования, которая изображена «с высоты птичьего полета» на следующей концептуальной схеме. Здесь разметка обозначена цветовой раскраской: различным задачам соответствуют разные цвета, которыми окрашены как шаги процессов выполнения задач, так и данные, модифицируемые в ходе выполнения задач. Каждый элемент данных снабжается ссылкой на шаг процесса, в ходе которого он был изменен (поэтому в одном массиве данных могут встречаться элементы, размеченные разными задачами).

К числу рассеянных функциональных задач, возникающих в обеспечивающих процессах, относятся также оповещение участников процессов о ходе их выполнения, оперативная оценка эффективности процессов, проверка правильности действий пользователей и компонентов системы, перевод информации на разные языки и в разные форматы, и т.д. Но аспектноориентированный подход способствует снижению затрат на ассимиляцию компонентов не только в случае, когда требуется рассеивать их по системе. Дело в том, что аспектное связывание позволяет модифицировать модуль путем вставки аспектов внешним образом, в обход штатного интерфейса управления его структурой и поведением, на этапе сборки системы и даже «на лету» во время исполнения. Так можно реализовать модули, предназначенные для многократного использования в конфигурациях, различающихся наличием/отсутствием нескольких изменчивых задач, оформляемых как аспекты [226]. Еще одной областью такого применения связывания является интеграция унаследованных модулей (legacy), не доступных в исходных кодах и потому не допускающих модификацию путем редактирования [137].

В заключение раздела отметим, что в традиционной инженерии материальных систем раздельное решение рассеянных задач (separation of concerns) является давно устоявшейся практикой. Рассмотрим в качестве примера проектирование зданий – область, из которой системные инженеры заимствовали много идей. Модульную архитектуру здания составляют подъезды, этажи, комнаты, а аспектную – интенсивно пересекающие их системы освещения, водоснабжения, отопления и др. [158] Проект каждого из таких аспектов документируется в форме отдельного плана и отдается на реализацию отдельной бригаде специалистов. Связывание аспектов по ходу строительства, включая разрешение всевозможных технологических и процедурных конфликтов, входит в число рутинных задач прораба.

1.4. Организация жизненного цикла больших информационноуправляющих систем Подход к проектированию во многом предопределяет характер всего жизненного цикла любой системы. Жизненным циклом (life cycle) называется развитие системы начиная с разработки концептуального решения о ее создании и заканчивая прекращением ее применения. Базовые концепции, связанные с жизненным циклом, зафиксированы в международном стандарте ISO/IEC 12207-2008 «Systems and software engineering – Software life cycle processes» (в России принят под названием ГОСТ Р ИСО/МЭК 12207-2010 «Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств» [33]). В этом стандарте жизненный цикл представлен в виде совокупности взаимосвязанных процессов, участниками которых являются заказчики системы, поставщики, разработчики, операторы, сопровожденцы, менеджеры и пользователи [33, разд.1.2]. Для каждого процесса указывается его наименование, цель, выходы, действия и задачи (как ни странно, входы процессов не указаны).

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

процессы соглашения (agreement processes);

процессы организационного обеспечения проекта (organizational project-enabling processes);

процессы проекта (project processes);

технические процессы (technical processes);

процессы реализации программных средств (software implementation processes);

процессы поддержки программных средств (software support processes);

процессы повторного применения программных средств (software reuse processes).

При наличии модели качества, указанные в ней диапазоны допустимых значений показателей естественным образом применяются в процессах жизненного цикла в качестве ограничений. Заказчикам они позволяют точнее сформулировать свои ожидания от системы, поставщикам – обосновать пригодность своей продукции, разработчикам и специалистам по сопровождению – принять правильные проектные решения по созданию и развитию системы, операторам и пользователям – сформировать корректную модель поведения при работе с системой, менеджерам – найти основания для выполнения разнообразных управляющих воздействий. Критерии эффективности управления процессами жизненного цикла в ограничениях качества, как правило, имеют экономический характер – они состоят в минимизации затрат финансовых средств, труда и времени. По такому принципу организуются тендеры и аукционы, направленные на отбор наиболее компетентных исполнителей тех или иных процессов. (К сожалению, на практике этот принцип часто доводится до абсурда, но это – тема для отдельного рассмотрения вне рамок настоящей работы.) В целях снижения затрат в инженерии информационных систем, как и в других областях техники, были выработаны разнообразные технологии – шаблоны (модели) выполнения процессов жизненного цикла, наиболее рационального в определенных условиях, таких как заданная область применения изделия, значения масштабных факторов, парадигма программирования и др. Технологии регламентируют состав и порядок работ процессов, вид и формат результатов, структуру коммуникаций между исполнителями, применение CASE-средств. Многие технологии способствуют выполнению задач, регламентированных стандартом ISO/IEC 12207Хорошо проработанные и многократно апробированные технологии приобретают статус продукции промышленного масштаба, потребителями которой являются исполнители процессов жизненного цикла. Например, широко применяются технология объектно-ориентированной разработки Rational Unified Process (RUP) [134] и технология быстрого создания малых изделий eXtreme Programming (XP) [13].

Однако, как указывалось в разд.1.1, в жизненном цикле большой системы непосредственно использовать традиционные технологии не удается, поскольку они предъявляют высокие требования к ясности и определенности постановки входных задач. В условиях, когда невозможно подать технологиям на вход исчерпывающий перечень автоматизируемых функций, применяется предметный подход: ставится задача реализовать в системе сущности и взаимосвязи, наиболее характерные и наиболее существенные для автоматизируемой предметной области [55]. К ним привязываются «инвариантные» высокоуровневые пользовательские цели (goals), способы достижения которых подбираются и оптимизируются по мере функционирования и развития системы [237]. Чтобы выявить и разделить сущности на небольшие технологические «кусты», для реализации которых пригодны традиционные методы, необходимо провести полномасштабную системно-инженерную проработку предметной области. Ее результатами являются модели и средства, предназначенные для многократного применения в «прикладных» процессах создания и модификации отдельных компонентов (процессы реализации программных средств) и системы в целом (технические процессы) [76]. Согласно стандарту ISO/IEC 12207-2008 такая проработка проводится в рамках процесса инженерии предметной области (domain engineering, в ГОСТ Р ИСО/МЭК 12207-2010 – «проектирование доменов»).

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

Процесс инженерии предметной области изображен на следующей схеме [130].

Согласно этой схеме, процесс уровня предметной области состоит из этапов, присутствующих почти во всех технологиях создания программных изделий: анализ, проектирование, реализация. Специфика состоит в том, что их результаты часто находятся на метауровне по отношению к традиционным технологиям: это разнообразные «порождающие» модели, языки описания частей предметной области (domain-specific languages, DSL), генераторы программ.

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

По-видимому, здесь самой трудной задачей, критическим образом влияющей на техникоэкономические показатели всего жизненного цикла, является ответ на вопрос, что не нужно включать в рассмотрение при создании задуманной системы. По результатам выявления предметной области проводится ее моделирование, включающее сбор, систематизацию и формализацию информации о ней, поступающей из разных источников. Здесь существует ряд технологий, нацеленных на построение доменных моделей (domain models) различных видов. Так, FODA (Feature-Oriented Domain Analysis) и родственные методы позволяют представить предметную область в виде диаграммы характеристик (feature model) – элементарных свойств, допустимые сочетания которых образуют конфигурации средств автоматизации [130]. Метод RSEB (Reuse-driven Software Engineering Business) [201] задает правила объектно-ориентированной декомпозиции предметной области с фиксацией результатов на языке UML. В контексте подхода, изложенного в разд.1.2, особый интерес представляют методы, в основе которых лежит онтология предметной области, например ODE (Ontology Domain Engineering) [173]. Онтология служит источником терминов и условий корректности для модели качества большой системы и детализирующих понятийных моделей (процессов, организационной структуры и т.д.).

В совокупности все артефакты анализа предметной области формируют пространство задач (problem space) системы. Оно служит источником входных данных для этапов проектирования и реализации, формирующих пространство решений (solution space). В результате проектирования, как мы видели в разд.1.3, формируется архитектура системы в целом и ее функциональных подсистем, выполненных в разных стилях. В качестве основных входов работ по построению архитектуры подсистем выступают части пространства задач. Соответствие частей подсистемам приведено в следующей таблице (Таблица 4) вместе с примерами задач, относящихся к процессу учета энергоресурсов.

Таблица пространства подсистема задач Онтология Информационная модель Информационный Хранение реестра измерительобъекта управления ных каналов Модель процессов Подсистема мониторинга Потоковый Управление режимом опроса Каталог форм Подсистема обмена до- Взаимодействия Генерация справки о расходе Эскизы Подсистема пользова- Взаимодействия Визуализация графиков энергопользовательского тельских интерфейсов потребления Протоколы Подсистема сбора ин- Взаимодействия Сбор показаний с измерительвзаимодействия с формации и телеуправле- ных приборов устройствами ния (ПСИ) Каталог Подсистема расчета и Алгоритмический Расчет суммарного объема порасчетных анализа данных (ПРАД) требления энергоресурсов по В соответствие с моделями архитектуры реализуются средства, многократно используемые в непрерывных процессах уровня прикладной инженерии, по мере развития большой системы. Они бывают как предметно-ориентированными, автоматизирующими частные задачи (например компонент расчета потерь электроэнергии в линиях электропередачи), так и программно-инфраструктурными, реализующими общие концепции автоматизированного управления (например компонент ведения журнала событий). Большой вклад в уменьшение трудозатрат прикладного уровня вносят «родовые» компоненты – базы для создания предметноориентированных компонентов решения определенных классов задач путем метапрограммирования (например абстрактный драйвер опроса произвольного измерительного прибора, способный интерпретировать предметно-ориентированный язык описания протоколов опроса). От компонентов требуется максимальная сочетаемость и минимальная избыточность. Построение любой конфигурации системы сводится к конструированию моделей всех охватываемых ею процессов и объектов, комплексированию и адаптации набора компонентов, реализующих эти модели.

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