Теме «models@run.time» посвящены пять больших статей и развернутая вводная заметка приглашенных редакторов, которыми на этот раз являются Гордон Блэр (Gordon Blair), Нелли Бенкомо (Nelly Bencomo) и Роберт Франс (Robert France).
От современных критически важных программных систем часто требуется надежная адаптация к изменениям среды их исполнения при отсутствии или минимальном вмешательстве человека.
Исследования в области адаптивных (self-adaptive) систем привели к ряду важных результатов, однако многие проблемы остались нерешенными. Одна из наиболее серьезных проблем касается сложности, которая порождается обилием информации, связанной с выполнением программ. Перспективным подходом, позволяющим справиться с этим, является разработка механизмов, основанных на применении моделей программного обеспечения. Этот подход называется «использование моделей во время выполнения программ» (models@run.time) и предполагает применение моделей, получаемых при использовании управляемой моделями инженерии (model-driven engineering, MDE).
В MDE модель – упрощенное представление системы, создаваемое для специальных целей. Например, технологически независимые модели программного обеспечения описывают приложения с использованием понятий, абстрагирующих имеющиеся компьютерные технологии.
Полезно сопоставить это направление исследований с работами прошлых лет в области рефлексии. Специалисты этой области стремятся к выработке «автопортретов» систем (self-representation), причинно-следственно связанных с ними. Другими словами, модель должна постоянно и точно представлять текущее состояние и поведение системы – при изменении системы должна изменяться модель и наоборот. Одна из основных задач направления models@run.time состоит в нахождении соответствующих «автопортретов», причинно-следственно связанных с системами. Для адаптивных систем это важно по двум причинам:
-
на основе модели должно быть возможно получить актуальную и точную информацию о системе, позволяющую принимать решения о ее последующей адаптации;
-
если модель причинно-следственно связана с системой, то адаптацию можно производить на уровне модели, а не системы.
Из этого можно было бы заключить, что models@run.time является синонимом рефлексии, но это неверно. В области рефлексии пытаются найти модели, внутренне связанные с моделью вычислений. Обычно эти модели основываются на пространствах решений и часто представляются на низком уровне абстракции, где, например, раскрывается процесс передачи сообщений и поддерживаются метаоперации, такие как перехват сообщений. В подходе models@run.time ищутся модели, представляемые на более абстрактном уровне, в частности причинно-следственные модели, относящиеся к пространству задач. Еще одним отличием является то, что такие модели должны быть внутренне привязаны к моделям, производимым в качестве артефактов процесса MDE, и поэтому они должны ассоциироваться с соответствующими методологиями инженерии программного обеспечения. Этот важный симбиоз успешно применяется в области распределенных систем, где имеется подобная строгая связь между разработкой с применением распределенных объектов, например в архитектуре CORBA, и ассоциированными объектно-ориентированными методологиями инженерии программного обеспечения, основанными на UML.
Тем самым подход models@run.time основывается на рефлексии, но ориентирован на перемещение работы из пространства решений в пространство задач, что аналогично тому влиянию, которое оказывают на MDE методологии инженерии программного обеспечения. Итак: model@run.time – это цельное представление системы, ассоциируемое с ней причинно-следственными связями, в котором акцентируются структура, поведение и цели этой системы с точки зрения пространства задач. Однако на пути такого подхода имеется множество вопросов. Насколько отличаются современные технологии, применяемые в процессе разработки программного обеспечения, от методов синтеза, требуемых при использовании моделей времени выполнения? Пригодны ли эти технологии для синтеза динамических моделей? Насколько методы и стандарты определения семантики пригодны для автоматической интерпретации во время выполнения? Какие последствия имеет подход models@run.time для инженерии программного обеспечения и может ли он стимулировать радикальный пересмотр понятий разработки программного обеспечения? Могут ли модели времени выполнения обеспечить поддержку анализа программного обеспечения в стиле «что, если» и предоставить возможность непредвиденных изменений?
Первая статья тематической подборки называется «Использование основанных на моделях трасс в качестве моделей времени выполнения» (Using Model-Based Traces as Runtime Models). Ее написал Шахар Маоц (Shahar Maoz).
В трассах, основанных на моделях, информация о выполнении программы сохраняется с использованием абстракций тех моделей, которые использовались при разработке. Эти трассы включают обильную семантическую информацию о системах, для которых они генерировались, о моделях, на основе которых они выводились, и о связях между системами и моделями, раскрывающихся во время выполнения. С использованием трасс, основанных на моделях, специалисты могут во время выполнения системы отслеживать модели этапа ее разработки, такие как диаграммы последовательностей, диаграммы классов и диаграммы состояний.
Метрики и операции трасс, основанных на моделях, можно использовать как инструменты для получения подробных сведений о структуре и поведении выполняемой системы на уровне абстракции, соответствующем моделям этой системы этапа разработки. Трассу выполнения системы можно считать моделью времени выполнения системы, для которой она генерировалась. В трассе сохраняется информация о выполнении системы на некотором уровне детализации; следовательно, ее можно рассматривать как некоторое абстрактное представление – артефакт, моделирующий некоторые аспекты системы.
Трассу как модель следует формально описывать с использованием некоторого языка, и при наличии его точного синтаксиса специалисты могут проверять правильность построения или корректность трассы. Семантику трассы можно определять на уровне представления конкретного прогона системы, на основе которого она генерировалась, и на уровне представления набора систем (и набора их прогонов), для которого генерировалась трасса. При наличии семантики специалисты могут проверять, согласуется ли синтаксически корректная трасса с конкретным прогоном (является ли данное представление корректным) или, в более общем смысле, является ли данная трасса реализуемой, то есть существует ли система (и некоторый ее прогон), для которого данная трасса генерировалась.
В целом свойства трасс как моделей обеспечивают возможность получения детальной информации о структуре и поведении моделируемой системы, информации, которая может способствовать решению ряда задач инженерии программного обеспечения (тестирования, понимания, развития программных систем и т.п.).
Статью «Самоуправляемый компьютинг на основе повторного использования моделей изменчивости во время выполнения: пример интеллектуального дома» (Autonomic Computing through Reuse of Variability Models at Runtime: The Case of Smart Homes) представили Карлос Цетина (Carlos Cetina), Пау Гинер (Pau Giner), Жоан Фонс (Joan Fons) и Виценте Пелечано (Vicente Pelechano).
Основной проблемой самоуправляемого компьютинга является определение соответствующих абстракций и моделей для понимания самоуправляемого поведения, его контролирования и разработки. В ряде исследований удалось получить результаты, обеспечивающие основные возможности самоуправления, такие как самоконфигурирование с использованием «закрепляющего обучения» (reinforcement learning) и самоадаптация с использованием основанных на сетях Петри моделей. Однако практическое применение этих возможностей чрезмерно усложняет результирующие системы и методы их производства.
Отличаясь от предыдущих исследований и в то же время дополняя их, работа авторов фокусируется на средах массового производства, используемых, например, при создании автомобилей, где основным ограничением является стоимость производства. Сокращение стоимости возможно за счет ограничения уровня индивидуализации продуктов – например, при покупке автомобиля можно выбрать желаемый цвет, но только из ограниченной палитры. В областях массового производства весьма полезными оказываются модели изменчивости (Variability Model), позволяющие максимизировать повторное использование компонентов при разработке набора схожих программных систем (семейства систем). Работа авторов показывает, что самоуправляемого поведения можно достичь за счет использования моделей изменчивости во время выполнения. В предлагаемом подходе существенны два аспекта: повторное использование знаний этапа разработки для обеспечения самоуправляемости; повторное использование существующих технологий управления моделями во время выполнения.
Для реализации операций управления моделями авторы разработали механизм Model-Based Reconfiguration Engine (MoRE), позволяющий определить, как следует изменяться системе для соответствующего изменения архитектуры. Таким образом, знания, зафиксированные в моделях изменчивости, используются в качестве политик, управляющих автономной эволюцией системы во время выполнения.
Разработанный авторами подход применялся для создания интеллектуальных домов (www.autonomic-homes.com) для обеспечения возможностей самовосстановления и самоконфигурирования (рис. 1).
Авторами статьи «Применение подхода models@run.time для поддержки динамической адаптации» (Models@run.time to Support Dynamic Adaptation) являются Брис Морин (Brice Morin), Оливье Бараис Olivier Barais, Жан-Марк Жезекель (Jean-Marc J?z?quel), Франк Флюрей (Franck Fleurey) и Арнор Солберг (Arnor Solberg).
Современное общество все более зависит от программных систем, которые должны быть доступны в режиме 24/7, динамически адаптируясь к изменениям условий среды и требований. Специалисты могут разрабатывать динамически адаптивные системы (Dynamically Adaptive System, DAS) путем определения нескольких точек изменчивости. В зависимости от контекста система динамически выбирает варианты, пригодные для реализации этих точек изменчивости. Категория DAS весьма обширна и включает как небольшие встраиваемые системы, так и крупные системы, как управляемые человеком, так и полностью автономные. Можно представлять DAS как динамическую линейку программных продуктов (Dynamic Software Product Line, DSPL), в которой изменчивость проявляется во время выполнения. Аналогично традиционным SPL, число возможных конфигураций в DSPL комбинаторно возрастает в зависимости от числа точек изменчивости и вариантов. В SPL продукты производятся в соответствии с решениями людей и являются полностью независимыми. В отличие от этого, в DSPL должно поддерживаться управление путями миграции между возможными конфигурациями.
Таким образом, конфигурации, производимые в DSPL, являются чрезвычайно зависимыми: система должна во время выполнения изменить свою текущую конфигурацию на некую новую конфигурацию через некоторый безопасный путь миграции (переход). Эти переходы инициируются изменением контекста, предпочтениями пользователей и т.д. На абстрактном уровне выполнение DSPL можно представить в виде сильно связанной машины состояний, в которой состояниями являются возможные конфигурации системы, а переходами – пути миграции. Полная спецификация этой машины состояний дает возможность разработчикам производить масштабную симуляцию, валидацию и тестирование динамической изменчивости системы до ее реальной реализации. Методы MDE обеспечивают возможность полностью сгенерировать код адаптивных систем на основе спецификации машины состояний. Однако у этого подхода имеются два серьезных недостатка: комбинаторный взрыв числа конфигураций и переходов, которые требуется описать; эволюция адаптивных систем, которая влечет динамическое изменение машины состояний адаптации. Было бы непрактично применять классический подход MDE для генерации всего кода приложения из высокоуровневых спецификаций: систему пришлось бы останавливать и выводить из эксплуатации до тех пор, пока не стало бы возможно развернуть и запустить новую (основанную на модифицированной машине состояний).
В проекте EU-ICT DiVA (Dynamic Variability in complex, Adaptive systems, www.ict-diva.eu), выполняемом авторами статьи, эти недостатки устраняются за счет использования программных моделей как во время выполнения, так и на этапе разработки адаптивных систем.
Следующую статью – «Использование архитектурных моделей для управления адаптацией во время выполнения и ее визуализации» (Using Architectural Models to Manage and Visualize Runtime Adaptation) – представили Джон Джоргас (John Georgas), Андрэ ван дер Хоек (Andre van der Hoek) и Ричард Тейлор ( Richard Taylor).
Все чаще программные приложения разрабатываются как саморегулирующиеся адаптивные системы, которые не только изменяют свое видимое извне поведение при изменении условий выполнения, но и производят это в автономном режиме. Хотя имеется много проблем, связанных с проектированием и реализацией программных систем, адаптируемых во время выполнения, данная статья посвящена проблеме поддержки когнитивного контроля над их адаптацией.
Непрограммные адаптивные системы обычно включают специальные механизмы мониторинга и управления, обеспечивающие оператору полную информацию о состоянии, поведении и эволюции системы. Например, система управления дорожным движением в целом управляется предопределенными параметрами, однако это автономное поведение дополняется центром управления, в котором обеспечивается глобальное представление состояния дорожного движения и операторы которого могут корректировать поведение системы.
В настоящее время эквивалентные механизмы управления программными системами, адаптирующимися во время выполнения, отсутствуют. Традиционные механизмы мониторинга и анализа поведения программ не в состоянии устанавливать, как конфигурация системы влияет на ее поведение в текущем контексте, производить анализ исторической информации о структуре и поведении системы, поддерживать упреждающее управление поведением системы оператором-человеком. В результате непрерывный контроль поведения адаптивных программных систем оказывается почти невозможным, затруднено определение причин отказов систем, и даже понимание адаптивного поведения системы, при котором достигаются поставленные цели, возможно только на интуитивном уровне.
Авторы разрабатывают концепцию центра оперативного управления, позволяющего людям понимать программные системы, адаптирующиеся во время выполнения, и управлять ими. При использовании подхода архитектурного управления конфигурациями во время выполнения (Architectural Runtime Configuration Management, ARCM) создается модель, в которой фиксируются конфигурации адаптивной системы и соответствующее поведение, и эта информация представляется в виде исторического графа конфигураций. За счет дополнения этой модели метаданными о процессе адаптации (например, сколько раз использовалась данная конфигурация или какое время сохранялась эта конфигурация системы) ARCM создает историческую перспективу этого процесса. Операторы могут использовать эту история для понимания поведения системы. Разработчики могут пользоваться ею для совершенствования процесса адаптации.
Последняя статья тематической подборки называется «Отражения смысла: поддержка моделей времени выполнения, пригодных для проверки» (Mirrors of Meaning: Supporting Inspectable Runtime Models) и написана Тони Герлуфсе (Tony Gjerlufs), Мадсом Ингструпом (Mads Ingstrup) и Джаспером Волффом Олсеном (Jesper Wolff Olsen).
При возникновении аварийного отказа системы нам часто непонятно, что происходит, кроме как на очень высоком уровне, например, «система повисает каждый раз, когда пытаешься вставить рисунок». Мы не можем сделать внутреннюю работу системы видимой и пригодной для проверки. В результате достаточно полное понимание поведения системы и цепочек причинно-следственных связей, приводящих к ее сбою, оказывается нереальным и даже недостижимым. Представим себе, как бы изменилась эта ситуация, если бы программное обеспечение создавалось таким образом, что можно было получать данные о его состоянии, структуре и поведении, причем эти данные были бы доступны не только разработчикам, но и пользователям. В последние пять лет авторы изучали способы разработки программных систем, обеспечивающие понимание их выполнения.
Разработчикам предлагается понятным и структурированным образом создавать и раскрывать модель системы времени выполнения, что позволяет им производить системы, пригодные для проверки. Предлагаемый авторами подход опирается на рефлективную структуру данных, называемую H-графом (H-graph – «иерархический граф»); на ней же основана модель программирования. Не менее важно то, что та же структура данных частично может служить основой модели программирования рефлективного программного обеспечения в целом. Внутри этой модели программирования H-графы обеспечивают основную структуризацию разрабатываемых систем и механизм хранения данных.
Вне тематической подборки опубликованы две большие статьи. Кеннет Хосте (Kenneth Hoste) и Ливен Экхаут (Lieven Eeckhout) написали статью «Методология анализа показателей производительности коммерческих процессоров» (A Methodology for Analyzing Commercial Processor Performance Numbers).
Консорциумы и корпорации, проводящие эталонное тестирование, публикуют показатели производительности коммерческих компьютерных систем на основе стандартизированных в индустрии эталонных тестовых наборов, например SPEC (Standard Performance Evaluation Corporation, www.spec.org). Информация, получаемая в результате этих тестовых испытаний, позволяет провести сравнения коммерческих машин от разных производителей, с разными процессорами, на разных приложениях при наличии разных видов рабочей нагрузки. Однако избыток данных затрудняет анализ, для облегчения которого авторы предложили сократить размерность наборов. Для иллюстрации мощности предложенной методологии использовался набор SPEC CPU2000. Результаты статистического анализа визуализируются с применением соответствующего интерактивного инструментального средства, обеспечивающего быструю и интуитивно понятную навигацию по крупным наборам данных о производительности.
Последняя большая статья написана Ахмедом Аббаси (Ahmed Abbas) и Хсинчуном Ченом (Hsinchun Chen) и называется «Сравнение инструментальных средств для обнаружения поддельных сайтов» (A Comparison of Tools for Detecting Fake Websites).
Мошенники создают поддельные сайты (рис. 2) нескольких типов, включая Web-спам, искусственно сфабрикованные (concocted) и мистифицирующие (spoof) сайты. Сайты с Web-спамом направлены на обман поисковых машин для поднятия своего рейтинга. Эти сайты применяются в хакерской оптимизации поисковых машин, в результате которой удается с большей прибылью продать спам-сайты с высоким рейтингом.
В центре рис. 2 показан сайт подложного инвестиционного банка. Назначение таких сайтов состоит в обмане доверчивых пользователей, у которых собираются деньги, после чего сайт исчезает. Подобные сайты обычно выглядят как сайты реальных финансовых, торговых и других компаний. Мистифицирующие сайты являются имитацией реальных коммерческих сайтов и направлены на обман их доверчивых клиентов. К числу наиболее часто подделываемых сайтов относятся eBay, PayPal и сайты различных банков.
Поскольку в обнаружении спам-сайтов достигнут значительный прогресс (см. обзор октябрьского номера журнала Computer за 2005 год, http://www.osp.ru/os/2005/11/380544), в своей статье авторы концентрируются на проблемах обнаружения искусственно сфабрикованных и мистифицирующих сайтов.
Поддельные сайты часто выглядят вполне профессионально и их трудно распознать по внешнему виду, а у предложенных ранее инструментов их разоблачения имеется ряд недостатков. Их основная часть включает справочные системы, основанные на собираемых по информации от пользователей черных списках URL поддельных сайтов. В немногих системах используются упреждающие методы классификации, основанные на упрощенных эвристиках. Кроме того, наибольшее внимание уделяется средствам выявления мистифицирующих сайтов, а искусственно фабрикуемым сайтам уделяется недостаточное внимание, хотя они получают все большую распространенность. Поскольку сфабрикованные сайты не просто имитируют популярные коммерческие сайты, для их успешной идентификации требуется привлечение большего числа методов. Авторы предлагают классифицирующую систему на основе применения метода опорных векторов (Support Vector Machine, SVM), позволяющую выявлять поддельные сайты. Для достижения более высокой эффективности в динамической гибридной системе этот классификатор используется совместно со справочным механизмом.
До встречи в следующем номере, Сергей Кузнецов (kuzloc@ispras.ru).
