Темі «[email protected]» присвячені п'ять великих статей і розгорнута вступна замітка запрошених редакторів, якими на цей раз є Гордон Блер (Gordon Blair), Неллі Бенкомо (Nelly Bencomo) і Роберт Франс (Robert France).

Від сучасних критично важливих програмних систем часто потрібна надійна адаптація до змін середовища їх виконання за відсутності або мінімальному втручанні людини.

Дослідження в області адаптивних (self-adaptive) систем привели до ряду важливих результатів, однак багато проблем залишилися невирішеними. Одна з найбільш серйозних проблем стосується складності, яка породжується великою кількістю інформації, пов'язаної з виконанням програм. Перспективним підходом, що дозволяє впоратися з цим, є розробка механізмів, заснованих на застосуванні моделей програмного забезпечення. Цей підхід називається «використання моделей під час виконання програм» ([email protected]) і передбачає застосування моделей, одержуваних при використанні керованої моделями інженерії (model-driven engineering, MDE).

У MDE модель - спрощене уявлення системи, що створюється для спеціальних цілей. Наприклад, технологічно незалежні моделі програмного забезпечення описують додатки з використанням понять, абстрагується наявні комп'ютерні технології.

Корисно порівняти цей напрям досліджень з роботами минулих років в області рефлексії. Фахівці цієї області прагнуть до вироблення «автопортретів» систем (self-representation), причинно-слідчо пов'язаних з ними. Іншими словами, модель повинна постійно і точно представляти поточний стан і поведінку системи - при зміні системи повинна змінюватися модель і навпаки. Одна з основних завдань напрямки [email protected] полягає в знаходженні відповідних «автопортретів», причинно-слідчо пов'язаних з системами. Для адаптивних систем це важливо з двох причин:

• на основі моделі повинно бути можливо отримати актуальну і точну інформацію про систему, що дозволяє приймати рішення про її подальшої адаптації;

• якщо модель причинно-слідчо пов'язана з системою, то адаптацію можна виробляти на рівні моделі, а не системи.

З цього можна було б зробити висновок, що [email protected] є синонімом рефлексії, але це невірно. В області рефлексії намагаються знайти моделі, внутрішньо пов'язані з моделлю обчислень. Зазвичай ці моделі ґрунтуються на просторах рішень і часто представляються на низькому рівні абстракції, де, наприклад, розкривається процес передачі повідомлень і підтримуються метаопераціі, такі як перехоплення повідомлень. У підході [email protected] шукаються моделі, що представляються на більш абстрактному рівні, зокрема причинно-наслідкові моделі, що відносяться до простору задач. Ще однією відмінністю є те, що такі моделі мають бути внутрішньо прив'язані до моделей, вироблених в якості артефактів процесу MDE, і тому вони повинні асоціюватися з відповідними методологіями інженерії програмного забезпечення. Цей важливий симбіоз успішно застосовується в області розподілених систем, де є подібна сувора зв'язок між розробкою із застосуванням розподілених об'єктів, наприклад в архітектурі CORBA, і асоційованими об'єктно-орієнтованими методологіями інженерії програмного забезпечення, заснованими на UML.

Тим самим підхід [email protected] ґрунтується на рефлексії, але орієнтований на переміщення роботи з простору рішень в простір завдань, що аналогічно тому впливу, який чинять на MDE методології інженерії програмного забезпечення. Отже: [email protected] - це цілісне уявлення системи, асоційоване з нею причинно-наслідковими зв'язками, в якому акцентуються структура, поведінка і цілі цієї системи з точки зору простору задач. Однак на шляху такого підходу є безліч питань. Наскільки відрізняються сучасні технології, що застосовуються в процесі розробки програмного забезпечення, від методів синтезу, необхідних при використанні моделей часу виконання? Чи придатні ці технології для синтезу динамічних моделей? Наскільки методи і стандарти визначення семантики придатні для автоматичної інтерпретації під час виконання? Які наслідки має підхід 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 ).

Авторами статті «Застосування підходу [email protected] для підтримки динамічної адаптації» ([email protected] 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), що дозволяє виявляти підроблені сайти. Для досягнення більш високої ефективності в динамічної гібридній системі цей класифікатор використовується спільно з довідковим механізмом.

До зустрічі в наступному номері, Сергій Кузнецов ( [email protected] ).

Мал. 1. Модель елементів інтелектуального будинку. Елементи ієрархічно пов'язані в деревоподібну структуру зв'язками мінливості