Обгрунтування вибору засобів і середовища розробки програмного засобу. Цп автоматизовані системи управління та промислова безпека

Інтегроване середовище розробки (ІСР) - це система програмних засобів, яка використовується програмістам для розробки програмного забезпечення. В англійською таке середовище називається Integrated development environment або скорочено IDE.

ІСР зазвичай включає в себе текстовий редактор, компілятор, інтерпретатор, засоби автоматизації розробки і збірки програмного забезпечення і відладчик. Іноді також містить засоби для інтеграції з системами управління версіями і різноманітні інструменти для спрощення конструювання графічного інтерфейсу користувача. Багато сучасні середовища розробки також включають вікно перегляду програмних класів, інспектор об'єктів і діаграму ієрархії класів - для використання при об'єктно-орієнтованої розробки ПЗ. Більшість сучасних ІСР призначені для розробки програм на кількох мовах програмування одночасно.

Один з окремих випадків ІСР - середовища візуальної розробки, які включають в себе можливість візуального редагування інтерфейсу програми.

Основним вікном, є текстовий редактор, який використовується для введення вихідного коду в ІСР і орієнтований на роботу з послідовністю символів в текстових файлах. Такі редактори забезпечують розширену функціональність - підсвічування синтаксису, сортування рядків, шаблони, конвертацію кодувань, показ кодів символів і т. П. Іноді їх називають редакторами коду, так як основне їхнє призначення - написання вихідних кодів комп'ютерних програм.

Підсвічування синтаксису - виділення синтаксичних конструкцій тексту з використанням різних кольорів, шрифтів і накреслень. Зазвичай застосовується в текстових редакторах для полегшення читання вихідного тексту, поліпшення візуального сприйняття. Часто застосовується при публікації вихідних кодів в Інтернет.

Поняття трансляції, компілятора й інтерпретатора було дано в попередніх лекціях.

Одна з найбільш важливих частин ІСР - відладчик, який являє собою модуль середовища розробки або окремий додаток, призначене для пошуку помилок в програмі. Усунення несправностей дозволяє виконувати покрокову трасування, відстежувати, встановлювати або змінювати значення змінних в процесі виконання програми, встановлювати і видаляти контрольні точки або умови зупинки і т. Д.

Найбільш поширеними отладчиками є:

- GNU Debugger - відладчик програм від проекту GNU;

- IDA - дизассемблер і низькорівневий відладчик для операційних систем сімейства Windows і GNU / Linux;

- Microsoft Visual Studio - середовище розробки програмного забезпечення, що включає засоби налагодження від корпорації Microsoft;

- OllyDbg - безкоштовний низькорівневий відладчик для операційних систем сімейства Windows;

- SoftICE - низькорівневий відладчик для операційних систем сімейства Windows;

- Dr. Watson - стандартний відладчик Windows, дозволяє створювати дампи пам'яті;

- WinDbg - безкоштовний відладчик від корпорації Microsoft.

Основним процесом налагодження є трасування. Трасування - це процес покрокового виконання програми. У режимі трасування програміст бачить послідовність виконання команд і значення змінних на даному етапі виконання програми, що дозволяє легше виявляти помилки. Трасування може бути розпочато і закінчено в будь-якому місці програми, виконання програми може зупинятися на кожній команді або на точках зупинки, трасування може виконуватися з заходом в процедури / функції і без заходження.

Найбільш важливим модулем ІСР при спільній розробці проектів середнього і високого ступеня складності є система управління версіями. Система управління версіями (англійська абревіатура CVS) - програмне забезпечення для полегшення роботи зі змінною інформацією. Вона дозволяє зберігати кілька версій одного і того ж документа, при необхідності, повертатися до попередніх версій, визначати, хто і коли зробив ту чи іншу зміну і багато іншого.

Такі системи найбільш широко застосовуються при розробці програмного забезпечення, для зберігання вихідних кодів програми, що розробляється. Однак вони можуть з успіхом застосовуватися і в інших областях, в яких ведеться робота з великою кількістю безперервно змінюються електронних документів, зокрема, вони все частіше застосовуються в САПР, зазвичай в складі систем управління даними про виріб. Управління версіями використовується в інструментах конфігураційного управління різних пристроїв і систем.

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

Більшість систем управління версіями використовують централізовану модель, коли є єдине сховище документів, кероване спеціальним сервером, який і виконує велику частину функцій з управління версіями. Користувач, який працює з документами, повинен спочатку отримати потрібну йому версію документа зі сховища; зазвичай створюється локальна копія документа, так звана «робоча копія». Може бути отримана остання версія або будь-яка з попередніх, обрана за номером версії або датою створення, іноді і за іншими ознаками. Після того, як в документ внесені потрібні зміни, нова версія поміщається в сховище. На відміну від простого збереження файлу, попередня версія не стирається, а також залишається в сховище і може бути отримана звідти в будь-який час. Сервер може використовувати дельта-компресію - спосіб зберігання документів, при якому зберігаються тільки зміни між послідовними версіями, що дозволяє зменшити обсяг збережених даних.

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

Часто буває, що над одним проектом одночасно працюють кілька людей. Якщо дві людини змінюють один і той же файл, то один з них може випадково скасувати зміни, внесені іншим. Системи управління версіями відстежують такі конфлікти і пропонують засоби їх вирішення. Більшість систем може автоматично об'єднати (злити) зміни, зроблені різними розробниками. Однак таке автоматичне об'єднання змін, можливо зазвичай тільки для текстових файлів і то, тільки за умови, що змінювалися різні (непересічні) частини цього файлу. Таке обмеження пов'язане з тим, що більшість систем управління версіями орієнтовані на підтримку процесу розробки програмного забезпечення, а вихідні коди програм зберігаються в текстових файлах. Якщо автоматичне об'єднання виконати не вдалося, система може запропонувати вирішити проблему вручну.

Часто виконати злиття неможливо ні в автоматичному, ні в ручному режимі, наприклад, в разі, якщо формат файлу занадто складний або взагалі невідомий. Деякі системи управління версіями дають можливість заблокувати файл в сховище. Блокування не дозволяє іншим користувачам отримати робочу копію або перешкоджає зміні робочої копії файлу (наприклад, засобами файлової системи) і забезпечує таким чином винятковий доступ тільки тому користувачеві, який працює з документом.

Інші можливості системи управління версіями полягають:

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

Веденні журналу змін, куди користувачі можуть записувати пояснення про те, що і чому вони змінили в цій версії;

Контролює права доступу користувачів, дозвіл або заборону читання або зміни даних в залежності від того, хто запитує цю дію.

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

Коли користувач такої системи виконує звичайні дії, такі, як витяг певної версії документа, створення нової версії тощо, він працює зі своєю локальною копією сховища. У міру внесення змін сховищ, що належать різним розробникам, починають різнитися, і виникає необхідність в їх синхронізації. Така синхронізація може здійснюватися за допомогою обміну патчами або так званими наборами змін (англ. Change sets) між користувачами.

Основна перевага розподілених систем полягає в їх гнучкості. Кожен розробник може вести роботу незалежно, так, як йому зручно, зберігаючи проміжні варіанти документів і передаючи результати іншим учасникам, коли вважатиме за потрібне. При цьому обмін наборами змін може здійснюватися по різними схемами. У невеликих колективах учасники роботи можуть обмінюватися змінами за принципом «кожен з кожним», за рахунок чого відпадає необхідність у створенні виділеного сервера. Велике співтовариство, навпаки, може використовувати централізований сервер, з яким синхронізуються копії всіх його учасників. Можливі й більш складні варіанти, наприклад, зі створенням груп для роботи за окремими напрямами всередині більшого проекту.

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

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

branch (гілка) - напрям розробки, незалежне від інших. Гілка є копією частини (як правило, одного каталогу) сховища, в яку можна вносити свої зміни, які не впливають на інші гілки. Документи в різних гілках мають однакову історію до точки розгалуження і різні - після неї.

check-in, commit, submit - створення нової версії, публікація змін. Поширення змін, зроблених в робочій копії, на сховище документів. При цьому в сховище створюється нова версія змінених документів.

C heck-out, clone - витяг документа зі сховища і створення робочої копії.

C onflict - конфліктна ситуація, коли кілька користувачів зробили зміни одного і того ж ділянки документа. Конфлікт виявляється в разі, коли один користувач уже опублікував свої зміни, а другий тільки намагається їх опублікувати і система сама не може коректно злити конфліктуючі зміни. Оскільки програма може бути недостатньо розумна для того, щоб визначити, яка зміна є «коректним», другого користувачеві потрібно самому вирішити конфлікт (resolve).

M erge, integration (злиття) - об'єднання незалежних змін в єдину версію документа. Здійснюється, коли двоє людей змінили один і той же файл або при перенесенні змін з однієї гілки в іншу.

R epository (сховище документів) - місце, де система управління версіями зберігає всі документи разом з історією їх зміни та іншої службової інформацією.

R evision (версія документа). Системи управління версіями розрізняють версії за номерами, які призначаються автоматично.

T ag, label (мітка) - яку можна привласнити певної версії документа. Мітка являє собою символічне ім'я для групи документів, причому описує вона не тільки набір імен файлів, але і ревізію кожного файлу. Ревізії включених в мітку документів можуть належати різним моментам часу.

T runk, mainline (ствол) - головна галузь розробки проекту. Політика роботи зі стовбуром може відрізнятися від проекту до проекту, але в цілому вона така: більшість змін вноситься в стовбур; якщо потрібно серйозна зміна, здатне привести до нестабільності, створюється гілка, яка зливається зі стовбуром, коли нововведення буде в достатній мірі випробувано; перед випуском чергової версії створюється «релізний» гілка, в яку вносяться тільки виправлення.

U pdate, sync (оновлення, синхронізація) - синхронізація робочої копії до деякого заданого стану сховища. Найчастіше це дія означає оновлення робочої копії до найсвіжішого стану сховища. Однак при необхідності можна синхронізувати робочу копію і до більш старого стану, ніж поточний.

W orking copy (робоча копія) - робоча (локальна) копія документів.

Розглянемо можливості ІСР на прикладі найбільш доступних і популярних версій.

Eclipse (від англ. Затемнення) - вільна інтегроване середовище розробки модульних кроссплатформенних додатків (рисунок 69). Розвивається і підтримується некомерційною організацією Eclipse Foundation (http://www.eclipse.org/).

Спочатку Eclipse розроблялася фірмою «IBM» в якості корпоративного стандарту ІСР для розробки на різних мовах під платформи від даної компанії. За відомостями «IBM», проектування і розробка коштували 40 млн. Дол. Вихідний код був повністю відкритий і зроблений доступним після того, як Eclipse був переданий для подальшого розвитку незалежного від «IBM» спільноті.

В основі Екліпс лежать фреймворк OSGi і SWT / JFace, на основі яких розроблено наступний шар - RCP (Rich Client Platform, платформа для розробки повноцінних клієнтських додатків). RCP є основою не тільки для Екліпс, а й для інших RCP-додатків, наприклад, Azureus і File Arranger. Наступний шар - сам Екліпс, що представляє собою набір розширень RCP: редактори, панелі, перспективи, модуль CVS і модуль Java Development Tools (JDT).

Екліпс - в першу чергу, повноцінна Java ІСР, націлена на групову розробку: підтримка CVS входить в поставку Екліпс, активно розвиваються кілька варіантів SVN-модулів, існує підтримка VSS та інших. В силу безкоштовності і високої якості, Екліпс у багатьох організаціях є корпоративним стандартом для розробки додатків.

Друге призначення Екліпс - служити платформою для розробки нових розширень, ніж він і завоював популярність: будь-який розробник може розширити Екліпс своїми модулями. Вже існують C / C ++ Development Tools (CDT), що розробляються інженерами QNX спільно з «IBM», і кошти для мов COBOL, FORTRAN, PHP і інші від різних розробників. Безліч розширень доповнює середу Екліпс менеджерами для роботи з базами даних, серверами додатків і ін.

малюнок 69 . Інтерфейс головного вікна Екліпс

Екліпс написана на Java, тому є платформо-незалежним продуктом, за винятком бібліотеки SWT, яка розробляється для всіх поширених платформ. Бібліотека SWT використовується замість стандартної для Java бібліотеки Swing. Вона повністю спирається на базову лінію у платформу (операційну систему), що забезпечує швидкість і натуральний зовнішній вигляд призначеного для користувача інтерфейсу, але іноді викликає на різних платформах проблеми сумісності і стійкості додатків.

Основою Eclipse є платформа розширеного клієнта (RCP - від англ. Rich client platform). Її компоненти:

OSGi (стандартному середовищі поставки комплектів (англ. Bundles));

SWT (портіруемость інструментарій віджетів);

JFace (файлові буфери, робота з текстом, текстові редактори);

Робоче середовище Екліпс (панелі, редактори, проекції, майстри).

Іншою популярною вільної ІСР є КДевелоп (http://www.kdevelop.org, рис. 70). КДевелоп (англ. KDevelop) - вільне середовище розробки програмного забезпечення для UNIX-подібних операційних систем. Проект стартував в 1998 році. КДевелоп поширюється згідно ліцензії GNU (General Public License).

Малюнок 70. інтерфейс KDevelop

KDevelop не включає до свого складу компілятор, замість цього він використовує будь-який компілятор для створення виконуваного коду.

Поточна стабільна версія підтримує велика кількість мов програмування, таких як Ада, Bash, C, C ++, Фортран, Java, Pascal, Perl, PHP, Python, Ruby і SQL.

КДевелоп використовує вбудований компонент - текстовий редактор - через технологію KParts. Основним редактором є Kate.

Функції КДевелоп:

Підсвічування вихідного коду з урахуванням синтаксису мови програмування, який визначається автоматично;

Менеджер проектів для проектів різного типу, таких як Automake, qmake для проектів базуються на технологіях Qt і Ant для проектів, які базуються на Java;

Навігатор класів (Class Browser);

Front-end для GNU Compiler Collection;

Front-end для GNU Debugger;

Помічників для генерації і оновлення визначення класів і платформи (framework);

Автоматична система завершення коду (Сі / C ++);

Вбудована підтримка системи документування вихідних кодів (Doxygen);

Одна з систем контролю версій: SCM, CVS, Subversion, Perforce і ClearCase;

Функція Quick Open дозволяє швидко переміщатися по файлах.

KDevelop являє собою «підключається» архітектуру. Коли розробник робить зміни, він повинен лише скомпілювати плагін. Передбачена можливість збереження профілів, що вказують які плагіни повинні бути завантажені.KDevelop не поставляється з вбудованим текстовим редактором, Він підключається як плагін.KDevelop не залежить від мови програмування і від платформи, на якій він запускається, підтримуючи KDE, GNOME і багато інших технологій (наприклад, Qt, GTK + та wxWidgets).

вбудований відладчикKDevelop дозволяє працювати графічно з усіма засобами налагодження, такими як точки зупину і трасування. Він також може працювати з динамічно модулями плагінами, на відміну від консольного gdb.

На даний момент існує приблизно від 50 до 100 плагінів для даної IDE. Серед найбільш корисних - persistent project-wide code bookmarks, Code abbreviations, що дозволяють швидко розгортати текст, Source formatter, який переформатує текст для style guide до збереження, пошук за регулярними виразами і project-wide пошук / заміна.

Останньою розглянутої ІСР єMicrosoft Visual Studio (Microsoft Visual Studio, рис. 71). По суті,Microsoft Visual Studio є лінійкою продуктів компанії «Майкрософт», що включають інтегроване середовище розробки програмного забезпечення і ряд інших інструментальних засобів.

Малюнок 71. Інтерфейс Microsoft Visual Studio

Microsoft Visual Studio включає один або кілька компонентів з наступних: Visual Basic.NET, Visual C ++, Visual C #, Visual F #, Microsoft SQL Server, Visual InterDev, Visual J ++, Visual J #, Visual FoxPro, Visual Source Safe.

Одним з головних переваг Майкрософт Визуал Студія є висока якість документування процесу розробки і опису можливих проблем в MSDN Library. Однак найбільш цікава для професіонала частина, присвячена тонкощам розробки, існує тільки на англійській мові.

Також компанія «Майкрософт» пропонує безкоштовний аналог продукту Visual Studio Express.

В даний час з кожною системою програмування зв'язуються не окремі інструменти (наприклад, компілятор), а деяка логічно пов'язана сукупність програмних і апаратних інструментів підтримують розробку та супровід ПС на даній мові програмування або орієнтованих на якусь конкретну предметну область. Таку сукупність будемо називати інструментальної середовищем розробки і супроводу ПС. Для таких інструментальних середовищ характерно, по-перше, використання як програмних, так і апаратних інструментів, і, по-друге, певна орієнтація або на конкретну мову програмування, або на конкретну предметну область.

Інструментальне середовище не обов'язково повинна функціонувати на тому комп'ютері, на якому повинно буде застосовуватися розробляється за допомогою її ПС. Часто таке поєднання буває досить зручним (якщо тільки потужність використовуваного комп'ютера дозволяє це): не потрібно мати справу з комп'ютерами різних типів, в розроблювану ПС можна включати компоненти самої інструментального середовища. Однак, якщо комп'ютер, на якому повинно застосовуватися ПС, недоступний для розробників цього ПС (наприклад, він постійно зайнятий іншою роботою, яку не можна переривати, або він знаходиться ще в стадії розробки), або незручний для розробки ПС, або потужність цього комп'ютера недостатня для забезпечення функціонування необхідної інструментальної середовища, то застосовується так званий інструментально-об'єктний підхід. Сутність його полягає в тому, що ПС розробляється на одному комп'ютері, званим інструментальним, А застосовуватися буде на іншому комп'ютері, званим цільовим(або об'єктним).

Розрізняють три основні класи інструментальних средразработкі і супроводу ПС (рис. 16.1): ·

середовища програмування, ·

робочі місця комп'ютерної технології, ·

інструментальні системи технології програмування.

Середовище програмуванняпризначена в основному для підтримки процесів програмування (кодування), тестування і налагодження ПС. Робоче місце комп'ютерної технологіїорієнтоване на підтримку ранніх етапів розробки ПС (специфікацій) і автоматичної генерації програм за специфікаціями. Інструментальна система технології програмуванняпризначена для підтримки всіх процесів розробки і супроводу протягом всього життєвого циклу ПС і орієнтована на колективну розробку великих програмних систем з тривалим життєвим циклом. Для таких систем вартість супроводу зазвичай перевищує вартість розробки.

Мал. 16.1. Основні класи інструментальних середовищ розробки і супроводу ПС.

Інструментальні середовища програмування.

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

Розрізняють такі класи інструментальних середовищ програмування (див. Рис. 14.2): ·

середовища загального призначення, ·

мовно-орієнтовані середовища.

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

Ріс.16.2. Класифікація інструментальних середовищ програмування.

Мовно-орієнтованаінструментальне середовище програмування призначена для підтримки розробки ПС на якомусь одному мовою програмування і знання про цю мову істотно використовувалися при побудові такого середовища. Внаслідок цього в такому середовищі можуть бути доступні досить потужні можливості, які враховують специфіку даного мови. Такі середовища поділяються на два підкласу: ·

інтерпретують середовища, ·

синтаксично-керовані середовища.

інтерпретуєінструментальне середовище програмування забезпечує інтерпретацію програм на даній мові програмування, тобто містить перш за все інтерпретатор мови програмування, на який це середовище орієнтована. Таке середовище необхідна для мов програмування інтерпретує типу (таких, як Лісп), але може використовуватися і для інших мов (наприклад, на інструментальному комп'ютері). Синтаксично-керованаінструментальне середовище програмування базується на знанні синтаксису мови програмування, на який вона орієнтована. В такому середовищі замість текстового використовується синтаксично-керований редактор, що дозволяє користувачеві використовувати різні шаблони синтаксичних конструкцій (в результаті цього розробляється програма завжди буде синтаксично правильної). Одночасно з програмою такий редактор формує (в пам'яті комп'ютера) її синтаксичне дерево, яке може використовуватися іншими інструментами.

Поява Makefile можна вважати першим кроком зі створення систем програмування. Мова Makefile став стандартним засобом, Єдиним для компіляторів всіх розробників. Це було зручне, але досить складне технічний засіб, Що вимагає від розробника високого ступеня підготовки і професійних знань, оскільки сам командний мову Makefile був за складністю можна порівняти з простою мовою програмування.

Така структура засобів розробки існувала досить довгий час, А в деяких випадках вона використовується і до цього дня (особливо при створенні системних програм). Її широке поширення було пов'язане з тим, що сама по собі вся ця структура засобів розробки була дуже зручною при пакетному виконанні програм на комп'ютері, що сприяло її повсюдного застосування в епоху mainframe з операційними системами типу Unix.

4.5. Інтегровані середовища розробки

Visual Studio 97 - перша випущена версія Visual Studio. У ній вперше були зібрані разом різні засоби розробки ПЗ. Система була випущена в двох версіях: Professional і Enterprise. Вона включала в себе Visual Basic 5.0, Visual C ++ 5.0, Visual J ++ 1.1, Visual FoxPro 5.0, вперше з'явилося середовище розробки ASP - Visual InterDev. Visual Studio 97 була першою спробою Microsoft створити єдине середовище для розробки на різних мовах програмування: Visual C ++, Visual J ++, Visual InterDev і MSDN використовували одну середу, звану Developer Studio. Visual Basic і Visual FoxPro застосовували окремі середовища для розробки.
Visual Studio 6.0 вийшла в червні 1998 р .. Це остання версія Visual Studio, що працює на платформі Win9x. Як і раніше популярна серед програмістів, що використовують Visual Basic. Дана версія була основним середовищем розробки додатків під Windows від Microsoft, до появи платформи.NET.
Visual Studio .NET (кодове ім'я Rainier; внутрішня версія 7.0) випущена в лютому 2002 року (включает.NET Framework 1.0). Service Pack 1 для Visual Studio .NET (2002) випущений в березні 2005 р
Visual Studio .NET 2003 (кодове ім'я Everett; внутрішня версія 7.1) з'явилася в квітні 2003 року (включает.NET Framework 1.1). Service Pack 1 для Visual Studio .NET 2003 випущений 13 вересня 2006 р
Visual Studio 2005 (кодове ім'я Whidbey; внутрішня версія 8.0) випущена в кінці жовтня 2005 року, остання офіційно працює на Windows 2000 (включает.NET Framework 2.0). На початку листопада 2005 року також вийшла серія продуктів в редакції Express: Visual C ++ 2005 Express, Visual Basic 2005 Express, Visual C # 2005 Express та ін. 19 квітня 2006 р редакція Express стала безкоштовною. Service Pack 1 для VS2005 і всіх Express-редакцій випущено 14 грудня 2006 року. Додатковий патч для SP1, вирішальний проблему сумісності з Windows Vista випущений 6 березня 2007 р
Visual Studio 2008 (кодове ім'я Orcas) випущена 19 листопада 2007 р одночасно с.NET Framework 3.5. Націлена на створення додатків для ОС Windows Vista (але підтримує і XP), Office 2007 і веб-додатків. Включає в себе LINQ, нові версії мов C # і Visual Basic. До студії не ввійшов Visual J #. З 28 жовтня 2008 року вперше доступна версія російською мовою.
Visual Studio 2010 року (кодове ім'я Hawaii, для Ultimate - Rosario) випущена 12 квітня 2010 роки разом с.NET Framework 4.0. Visual Studio включає підтримку мов C # 4.0 і Visual Basic .NET 10.0, а також мови F #, який був відсутній в попередніх версіях.

Середа Visual Studio 2010 дозволяє ефективно створювати складні додатки протягом короткого періоду часу. Модель даного середовища істотно багатший ранніх версій і використовує такі поняття, як рішення (solution), проект, простір імен (namespace) і збірка (assembly). Поняття проекту присутня в багатьох середовищах, наприклад, в середовищі Delphi. Файл проекту містить перерахування вихідних файлів і інших ресурсів, з яких система буде будувати додаток. У рішення середовища Visual Studio входять кілька проектів, які можуть бути залежними або незалежними один від одного. виділяється стартовий проект. Поняття збірки виходить з загальномовного виконавчої середовища CLR (Common Language Runtime). Середа CLR є найбільш революційним винаходом, з появою якого процес написання і виконання додатків ставати принципово іншим.

Компілятор перетворює файли з вихідними кодами в коди на проміжному мовою MSIL ( Microsoft Intermediate Language). Разом з метаданими ці коди записують PE-файли (Portal Executable), що мають розширення exe або dll в залежності від типу проекту. Також може бути отриманий модуль з розширенням netmodule, який не містить метаданих.

Усього є 12 типів проектів. При завантаженні PE-файли "на льоту" транслюються в команди реального процесора. Каркас Framework. NET, що забезпечує виконання програм, не входить в Visual Studio, а є налаштуванням над операційною системою. Це аналог віртуальної Java-машини.

Збірка є мінімальною одиницею для розгортання додатків. Кожен тип збірки характеризується унікальним ідентифікатором, ідентифікується цифровим підписом автора та унікальним номером версії. Між складками і просторами імен існує наступне співвідношення. Збірка може містити кілька просторів імен. У той же час простір імен може займати кілька збірок. Збірка може мати в своєму складі як один, так і декілька файлів, які об'єднуються в так званому маніфесті або описі збірки.

На рівні мови C # простору імен, аналогічно пакетам в Java, служать для структурування проекту. Простір імен включає один або кілька класів. В одному вихідному файлі може визначатися кілька просторів імен і в той же час один простір імен може визначатися в декількох файлах. І навіть клас може розташовуватися в декількох файлах (partial classes).

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

Цікавою і перспективною виглядає операційне середовище Eclipse, розроблена в фірмі IBM. Первинною метою проекту було створення корпоративного стандарту IDE для розробки програм на різних мовах під різні платформи. Потім проект був перейменований в Eclipse і виділений у відкритий доступ. Ліцензія дозволяє безкоштовно використовувати код і середовище розробки і при цьому створювати закриті комерційні продукти. Завдяки цьому система отримала широке поширення і для багатьох організацій стала корпоративним стандартом для розробки додатків.

Екосистема Eclipse відноситься до консолідованих технологій, роком широкого поширення якої є 2007-й. Система реалізована на мові Java і спочатку являла собою повноцінну інтегровану середу для мови Java. Надалі стали підтримуватися і інші мови. Перші версії були незручні, оскільки цільовий продукт змушене включав зайву функціональність. Починаючи з третьої версії була перероблена архітектура всієї системи з метою максимального поділу модулів і взаємозв'язку між ними. При цьому модулі Eclipse, утворені з узгоджених наборів класів, давали функціональність цілих підсистем, таких як підсистеми допомоги, оновлення продукту, навчання, презентації, багатомовної підтримки і безліч інших. Розробляючи додаток, тепер можна поступово нарощувати функціональність, підключаючи вже готові безкоштовні компоненти. У термінології Eclipse ці компоненти називаються "модулями", або "плагінами" (Plugins). Така технологія стає типовою для розвинених операційних середовищ. Платформа на основі цієї технології отримала назву

Інструментальні засоби розробки програмних агентів формують середовище, яке оптимізована для випуску певного типу додатків, зі специфічною архітектурою.

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

Можна виділити найбільш відомі і популярні середовища розробки агентів:

АВЕ (Agent Building Environment);

Розглянемо більш докладно перераховані інструментальні середовища розробки програмних агентів.

1. Інструментальне середовище AgentBuilder надає для розробників кошти розробки та середовище виконання агентного додатки. Технологія створення інтелектуального агента в середовищі AgentBuilder представлений на малюнку 2.1.

Мал. 2.1

Засоби розробки і середовище виконання написані на мові програмування Java, що дозволяє їм працювати на всіх платформах, де встановлена \u200b\u200bJava середу. Агент, створений за допомогою інструментарію AgentBuilder, може виконуватися на будь-якій платформі з віртуальною машиною Java (версії 1.1 і вище).

Засоби розробки представляють собою зручний графічний інтерфейс для аналізу предметної області розробляється МАС і специфікації бажаного поведінки агентів, що розробляються за допомогою графічних редакторів. У даній інструментальному середовищі передбачені наступні етапи побудови багатоагентного програми:

визначення складу агентства;

створення агентів, яке передбачає побудову онтології, використовуваної для виконання делегованих агенту повноважень, і ментальної моделі (переконання, здібності, зобов'язання, правила поведінки);

створення протоколів для специфікації взаємодії представників цього агентства;

генерація спеціального файлу опису агента на мові RADL, який, в кінцевому підсумку, являє ментальну модель і бажане поведінку агента.

Середовище виконання агентного додатки складається з агентной програми і процесора виконання агента. Процесор використовує ефективні процедури логічного висновку шляхом зіставлення правил поведінки агента з переконаннями агента, обумовленими поточної ментальної моделлю, і вхідними повідомленнями. На основі проведених міркувань процесор виконує певні дії, пов'язані з повноваженнями агента. Агентна програма являє собою визначення агента у вигляді файлу на мові RADL разом з укомплектованої бібліотекою класів проекту. Агентна програма спільно з процесором утворюють виконуваного агента. При запуску середовища виконання, инициализируется процесор агента, який використовує RADL-модель і онтологію агента, представлену у вигляді бібліотеки класів проекту (Project Accessories Library). Для цього необхідні визначення агента (файл RADL, який забезпечує агента здатністю міркування і початкової ментальної моделлю) і бібліотека класів проекту (допоміжні класи проекту PACs з бібліотеки класів проекту) - ці об'єкти використовуються для відображення предметної області завдання.

2. У середовищі Bee-gent розробка агентно-орієнтованих додатків виконується за методологією специфікації поведінки агентів розподіленої системи з використанням МАС - бібліотеки, реалізованої на мові Java. На основі запропонованих системою Bee-gent графічних засобів, можлива чітка структуризація поведінки кожного агента у вигляді графа станів і визначення протоколів взаємодій агентів. Графи станів агентів будуються на підставі життєздатності ролей, визначених у вигляді регулярних виразів на етапі агентно-орієнтованого аналізу (наприклад, за методологією Gaia). Приклад фрагмента графа поведінки агента Студент навчальної системи показаний на малюнку 2.2.

Мал. 2.2

Граф станів реєструє всі імена станів, в яких агент може знаходитися. На наступному кроці розробки визначаються класи для кожного стану. Кожне стан в графі є екземпляром класу AwrIPState з агентной бібліотеки фірми Toshiba, реалізованої на мові Java. У конструкторі класу визначаються перед і пост умови, тобто умови, які повинні бути виконані агентом в поточному стані для того, щоб виконати дії, визначені класом стану, і визначити перехід в наступний стан. Потім специфицируются дії, які повинні бути виконані в кожному стані (включаючи власні процеси агента і взаємодії з іншими агентами). Для початкового і кінцевого станів також створюються класи "INIT" і "END". Якщо агент взаємодіє з іншими агентами, то при специфікації окремих станів система Bee-gent передбачає визначення протоколу взаємодії. Протокол повинен відображати всі лінії поведінки агента в даному стані. У кожному стані діяльність агента спрямована на виконання протоколів взаємодії з метою реалізації планованої лінії поведінки. Діяльність кожного агента в МАС визначається, наприклад, моделлю послуг, розробленої на етапі агентно- орієнтованого аналізу за методологією Gaia.

Кожна лінія поведінки документується діаграмою взаємодії агентів із зазначенням вмісту повідомлень і їх черговості. На малюнку 2.3 наведено приклад діаграми взаємодії для стану "Вивчення дисципліни" агента Студент. Формат повідомлень визначається мовою XML / ACL, який є розвитком мови комунікації KQML.

Мал. 2.3 Діаграма взаємодії агента Студент в стані "Вивчення дисципліни"

Таким чином, на основі розроблених логічних моделей, система Bee-gent автоматично генерує на мові Java скелет програмного коду багатоагентної системи, який доповняться необхідним програмним кодом, що забезпечує заданий "життєвий цикл" агентів. В системі Bee-gent, на відміну від AgentBuilder, при описі поведінки агентів не застосовуються правила, що визначають реакцію агента на зовнішні події і його внутрішній стан.

3. JACK TM Intelligent Agents (JACK) являє собою агентно-орієнтоване середовище розробки, яка побудована на основі мови програмування Java. JACK є надбудовою Java у вигляді розширення синтаксису Java конструкціями для програмної реалізації властивостей, пов'язаних з поняттям інтелектуального агента. Мова програмування агентів JACK пропонує наступні можливості:

визначає нові основні класи, інтерфейси і методи;

розширює синтаксис Java для підтримки нових агентно-орієнтованих класів, визначень і операторів;

надає розширення семантики (особливо при виконанні) для підтримки моделі виконання, необхідної агентно-орієнтованої програмної системою.

Всі розширення мови реалізовані як plug-in, що робить мову максимально розширюваним і гнучким в агентно-орієнтованому програмуванні.

На рівні класів введено 5 головних конструкцій:

агент, який в JACK моделює інтелектуальні суті;

здатність, яка збирає в одне ціле функціональні компоненти (події, плани, безліч переконань і ін. здатності), для використання їх агентами;

подія, для моделювання ситуацій і повідомлень, на які агент повинен бути здатний відповісти;

план, який призначений для моделювання процедурного опису того, як агент керує цією подією (всі вжиті агентом дії заздалегідь передбачені і описані в його планах);

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

Слід зазначити, що бажана поведінка агента инкапсулируется в модульних одиницях, визначених цими класами, а класи містять всі необхідні для незалежного виконання структури і методи, які програмісти на мові JACK можуть використовувати. Для встановлення відносин між згаданими вище класами існує набір декларацій.

Для встановлення відносин між згаданими вище класами надано набір декларацій. Нижче наведено фрагмент коду для реалізації конструкції плану, написаного на JACK (елементи синтаксису, які належать JACK, виділені жирним шрифтом):

plan MovementResponse extends Plan (

#handles event RobotMoveEvent moveresponse;

#uses agent implementing RobotInterface robot;

static boolean relevant (RobotMoveEvent ev)

context () (...)

#reasoning method

У цьому прикладі визначається план дій програмного агента успадковує свої основні виконувані функції від класу JACKPlan. Крім того, за допомогою декількох декларацій для планів мови JACK вказується, яким чином план буде використовуватися. Кожна декларації передує символом "#" для того, щоб відрізнити їх від елементів синтаксису Java. Декларація #handles event визначає мету або подія, на яке цей план відповідає. Декларація #uses agent implementing закріплює агента (ів), які можуть використовувати цей план. План в прикладі можуть виконувати тільки ті агенти, які реалізують зазначений інтерфейс (RobotInterface). У фігурних дужках міститься звичайний код Java.

Крім декларацій мову JACK для опису міркувань і поведінки, що вживаються агентом при виконанні плану, надає свої оператори методів міркування, які виділяються попереднім символом "@".

Для підтримки виконання агентно-орієнтованої програмної системи JACK надає наступні додаткові мовні розширення, що забезпечують наступну семантику:

Нить вбудована в ядро \u200b\u200bі виведена з-під контролю програміста.

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

Введена нова структура даних, названа логічний елемент (logical member), значення якого залежить від результату запиту до безлічі переконань агента.

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

Компонент середовища розробки JACK (JACK Development Environment) дає можливість малювання оглядових діаграм, по яких серед генерує скелет програмного коду і стежить за тим, щоб зміни, вироблені в коді, відображалися і на діаграмах.

Агенти, що створюються в JACK, мають архітектуру, притаманну інтелектуальним агентам. Таким чином, можливо моделювання розумного поведінки, відповідно до теоретичної моделлю BDI- архітектури агента, заснованої на переконаннях, бажання і наміри.

Згідно BDI-архітектурі, інтелектуальні агенти JACK - це автономні програмні компоненти, які можуть проявляти розумне поведінку на основі проактивности (цілеспрямованість) і реактивності (направляється подіями) на вхідні сигнали. Кожен такий агент має:

переконання (це його набір даних про світ);

бажання (набір подій на які він буде реагувати і набір цілей, досягнення яких він може бажати);

наміри (набір планів, які описують як він може управляти виникаючими цілями і планами).

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

стійку цілеспрямованість - агенти зосереджені на цілях, а не на вибраних методах для їх досягнення;

контекстну залежність в реальному часі - агенти будуть стежити за варіантами, які застосовні в кожен момент часу і приймати рішення щодо подальших дій, на основі наявних умов;

твердження правильності підходу в реальному часі - агент буде гарантувати, що він слід обраному курсу дій до тих пір, поки певні умови продовжують бути істинними;

одночасність - Агентна система є багатопотокової. Якщо виникають нові цілі і події, то агент здатний визначити пріоритети на вимогу багатозадачності.

JACK додаток являє собою вихідний код, який реалізує характерні для агентно-орієнтованого підходу поняття: агентів, здібностей, події, плани, переконання, view (запити), а також Java клас з функцією main (), яка є точкою входу для віртуальної машини Java, і будь-які інші Java необхідні файли. Файли, які створюються для цих понять, повинні мати таке ж ім'я, як і у об'єкту, що визначається у файлі. Вони мають розширення, що визначає тип JACK поняття. Компілятор агентів JACK конвертує вихідні файли на мові агентів JACK в код на мові Java, який потім компілюється в код віртуальної машини Java для виконання на цільовій системі.

4. Програмне середовище JADE (Java Agent Development Framework) отримала широке застосування для розробки многоагентних систем. Вона повністю реалізована на мові Java і підтримує FIPA - стандарти для створення інтелектуальних агентів. Мета створення середовища JADE - спростити процес розробки за допомогою стандартизації способів взаємодії агентів у всеоохвативающей середовищі системних сервісів.

Для досягнення цієї мети JADE пропонує програмістів-розробнику агентних систем такі можливості:

агентно платформу FIPA-compliant Agent Platform, засновану на FIPA і включає обов'язкові типи системних агентів для управління, по-перше, агентной платформою (AMS), по-друге, каналом комунікації (ACC) та служби каталогів (DF) (ці типи агентів автоматично активуються при запуску платформи);

розподілену Агентно платформу Distributed Agent Platform, яка може використовувати кілька хостів, при чому на кожному вузлі запускається тільки одна Java Virtual Machine. Агенти виконуються як Java- потоки. Залежно від місцезнаходження агента, що посилає повідомлення, і того, хто його отримує, для доставки повідомлень використовується відповідний транспортний механізм.

Multiple Domains support - ряд заснованих на FIPA DF-агентів можуть об'єднається в федерацію, таким чином реалізуючи МультиДоменні Агентно середу.

Multithreaded execution environment with twolevel scheduling. Кожен JADE-агент має власний потік управління, але він також здатний працювати в багатопотоковому режимі. Java Virtual Machinе проводить планування завдань, що виконуються агентами або одним з них.

Object-оriented programming environment. Більшість концепцій, властивих FIPA- специфікації, представляються Java-класами, що формують інтерфейс користувача.

Library of interaction protocols. Використовуються стандартні інтерактивні протоколи fipa request і fipa-contract-net. Для того, щоб створити агента, який міг би діяти відповідно до таких протоколів, розробникам прикладних програм потрібно тільки імплементувати специфічні доменні дії, в той час як вся незалежна від прикладної програми протокольна логіка буде здійснюватися системою JADE.

Administration GUI. прості операції управління платформою можуть виконуватися через графічний інтерфейс, що відображає активних агентів і контейнери агентів. Використовуючи GUI, адміністратори платформи можуть створювати, знищувати, переривати і відновлювати дії агентів, створювати ієрархії доменів і мультиагентні федерації DF (фасилітаторів).

JADE базується на технологіях Java RMI, Java CORBA IDL, Java Serialization і Java Reflection API. Розробка МАС в цьому середовищі спрощується завдяки використанню FIPA-специфікацій і ряду інструментів підтримки фази налагодження та розгортання системи. Ця Агентна платформа може встановлюватися на комп'ютерах з різними операційними системами, і її можна конфігурувати через віддалений GUI-інтерфейс. Процес конфігурації цієї платформи досить гнучкий: її можна змінити навіть під час виконання програм, за допомогою переміщення агентів з однієї машини на іншу. Єдиною вимогою для роботи системи є установка на машині Java Run Time 1.2.

Кожен запущений екземпляр середовища JADE є контейнером, тому що може містити кілька агентів. Група активних контейнерів утворюють платформу. Головний контейнер завжди повинен бути активний, а всі інші контейнери повинні бути зареєстровані їм при їх створенні. Тому, перший контейнер, запущений на платформі є основним контейнером, а всі інші - звичайними контейнерами і повинні отримати вказівки про те, де знаходиться їх основний контейнер, на якому вони повинні бути зареєстровані. Якщо в мережі запускається ще один основний контейнер, то він являє собою іншу платформу, на якій нові звичайні контейнери мають можливість зареєструватися. На рисунок 2.4 показані наведені вище концепції платформи і контейнера і показує сценарій з двома JADE платформами, що складаються з трьох і одного контейнера відповідно.

Мал. 2.4 Середовище "існування" агентів JADE

JADE агенти повинні мати унікальні імена, знати імена один одного і, завдяки цьому, вони можуть спілкуватися безпосередньо, незалежно від їх фактичного місцезнаходження, тобто всередині одного контейнера (наприклад, агенти A2 і A3), в різних контейнерах усередині однієї платформи (наприклад, A1 і A2) або в різних платформах (наприклад, A4 і A5). Основний контейнер відрізняється від звичайних тим, що містить систему управління агентами і маршрутизатор, які автоматично запускаються при запуску основного контейнера. Система управління агентами AMS (Agent Management System), являє собою "влада" в платформі (створення / видалення агентів в віддалених контейнерах, запитуваних через AMS) і забезпечує службу іменування агентів. Маршрутизатор каталогів DF (Directory facilitator), який забезпечує сервіс "Жовтих сторінок", допомагає знайти агенту інших агентів, для отримання від них необхідних послуг, необхідних йому для досягнення своїх цілей.

Для здійснення комунікації архітектура середовища надає гнучкий і ефективний процес обміну повідомленнями, в якому JADE створює чергу і управляє потоком ACL-повідомлень, які є приватними для кожного агента. Агенти здатні звертатися до черги за допомогою комбінації декількох режимів своєї роботи: блокування, голосування, перерва в роботі і зіставлення з еталоном (якщо це стосується методів пошуку). інструментарій платформа Мультиагентний

В останніх версіях системи використовується Java RMI, event-notification і IIOP. Однак, можна легко додати і інші протоколи. Також передбачена можливість інтеграції SMTP, HTTP і WAP. Більшість комунікаційних протоколів, які вже визначені міжнародною спільнотою розробників агентних середовищ, доступні і можуть ілюструватися на конкретних прикладах після визначення поведінки системи і її основних станів. Разом з підтримкою певних користувачем тематичних мов, реалізовані онтології управління агентами, а також онтології, які можуть бути реалізовані і зареєстровані агентами і використані системою. З метою суттєвого розширення працездатності JADE, передбачена можливість інтеграції з JESS і Java-оболонкою CLIPS.

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

Таблиця 4

Порівняльний аналіз можливостей інструментальних середовищ для розробки програмних агентів

Можливості інструментальних середовищ
Засоби побудови агентств
Засоби управління проектом
Графічне середовище для визначення специфікацій агентів
Механізм контролю цілісності
Засоби побудови онтології
Бібліотека для розробки МАС
Механізм міркувань агента про свої здібності і здібності інших агентів
Формальна мова комунікації
Кошти налагодження взаємодії агентів
Механізм пошуку агентів з заданими здібностями

Мал. 2.5

На підставі порівняння характеристик розглянутих інструментальних середовищ можна зробити висновок про те, що найбільш потужними і гнучкими технологіями реалізації поняття "агент", є підходи, запропоновані інструментарієм AgentBuilder і середовищем JACK.

Необхідно звернути увагу на те, що для платформи JADE існує додаткове BDI розширення - середовище Jadex. Це середовище передбачає гібридну реактивно-делібератівную архітектуру, в якій агент розглядається як "чорний ящик", який бере і відправляє повідомлення. Грунтуючись на результатах обробки повідомлень, внутрішніх і зовнішніх подій, делібератівний механізм приймає рішення про перехід до нового плану дій або продовження старого. Чинний план може посилати повідомлення іншим агентам, змінювати базу переконань, формувати нові цілі і викликати внутрішні події. Система використовує бібліотеку планів, які обробляються як Java-класи.

Одним з головних переваг розробки інтелектуальних агентів на платформі Jadex є те, що не потрібно вивчення нових мов програмування. Замість цього агенти кодуються на базі об'єктно-орієнтованого програмування в інтегрованому середовищі розробки (IDEs), типу Eclipse і Intellij IDEA.

Ще одним важливим аспектом є незалежність сполучного програмного забезпечення, оскільки Jadex незалежно з його модулями може використовуватися в абсолютно інших сценаріях на верхньому рівні платформи. Орієнтовані на агента програми додають явні властивості автономних діючих елементів, які беруть участь в процесі прийняття рішень, до пасивних об'єктів. В цьому відношенні агенти надають активні компоненти до індивідуальних можливостей взаємодії з компонентами.

Jadex розроблений як самостійний механізм прийняття рішень, адаптовані для роботи з будь-якими сполучними системами, які виконують взаємодію з агентом щодо його власного управління і отримання повідомлень.

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

Проведений аналіз найбільш відомих інструментальних систем дозволив вибрати ефективну і доступну середу Jadex.

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

Розробка додатків в сучасних ІТ-проектах

Сучасний період розвитку засобів автоматизації та інформатизації вітчизняних підприємств можна охарактеризувати як час масового переходу від стихійної автоматизації окремих областей діяльності компаній до єдиних інтегрованим рішенням, що охоплює всі аспекти їх існування. Це не могло не відбитися на складі і обсязі найбільш часто виконуються ІТ-проектів і на методах їх виконання.

Особливості сучасних ІТ-проектів

Якщо ще п'ять-сім років тому були широко поширені проекти, пов'язані з замовний розробкою унікальних додатків (і дещо рідше - рішень на основі готових компонентів, призначених для конкретної предметної області) і виконувані силами ерудованих програмістів широкого профілю, які володіють та суміжні професії (наприклад, вміють адмініструвати локальні мережі і СУБД), то сьогодні в першу чергу замовляються проекти впровадження готових бізнес-додатків і ERP-систем, в рамках яких нерідко виконуються проекти по розробці рішень на базі все тих же готових бізнес-додатків. Причиною цього є, з одного боку, усвідомлення керівниками більшості компаній того факту, що, як би їх компанія ні претендувала на унікальність в своєї маркетингової стратегії, по суті і її виробництво, і окремі аспекти її діяльності є цілком типовими, а з іншого боку - усвідомлення виробниками бізнес-додатків неунікальності бізнес-процесів більшості компаній і створення ними широкого спектру типових рішень з одночасним наданням послуг з їх впровадження, супроводу та оновленню своїми силами або силами партнерів.

Перехід до поділу праці в проектах по розробці ПЗ

Подібна ситуація не могла не відбитися на кадровому складі ІТ-компаній, серед яких останнім часом переважають системні інтегратори (іноді мають свій відділ розробки, але спеціалізуються в основному на комплексних проектах, що включають не тільки розробку додатків), а компаній, що спеціалізуються виключно на розробці додатків, небагато. В останніх повним ходом йде процес спеціалізації, які розділили групу розробників на бізнес-аналітиків, системних аналітиків, програмістів, технічних письменників і керівників проектів. При цьому нерідко системний аналітик не вміє програмувати, бізнес-аналітик не керує проектами, а керівник проекту займається тільки організаційною роботою і не цікавиться ні архітектурою додатки, ні тим більше предметною областю. Це відображає факт переходу від малотиражного виробництва ексклюзивного програмного забезпечення до масового промислового виробництва типових рішень, затребуваних сучасними користувачами.

Зміна вимог до додатків

Говорячи про проекти з розробки додатків і про пов'язані з розробкою додатків частинах комплексних ІТ-проектів, слід зауважити, що сьогодні найбільш актуальним стає створення корпоративних рішень на основі не тільки СУБД, але і інших продуктів - офісних додатків, GIS- і CAD-систем, засобів бізнес-аналізу, спеціалізованих серверних продуктів, систем управління підприємством та інших бізнес-додатків. Вимоги до захищеності створюваних рішень також помітно відрізняються від тих, що існували ще три роки тому. Нарешті, однією з важливих тенденцій є зростання інтересу до додатків для мобільних пристроїв і додатків, здатних працювати автономно і при необхідності синхронізуватися з інформаційною системою підприємства.

З інших тенденцій, що проявилися останнім часом в області розробки корпоративних рішень, слід зазначити зростаючу потребу підприємств у засобах бізнес-аналізу, що входять до складу наявних рішень чи існуючих у вигляді окремих інструментів. Незважаючи на те що створення додатків із застосуванням бізнес-аналітики утруднено через те, що сьогодні питання стандартизації доступу до даних багатовимірних сховищ і мови запитів до них залишаються актуальними, в руках розробників вже є достатньо коштів вирішення подібних завдань для найбільш популярних аналітичних платформ як від постачальників самих аналітичних платформ (наприклад, Oracle, Microsoft і Hyperion), так і від компаній, що спеціалізуються на інструментах аналізу даних (Cognos, ProClarity і Business Objects). Крім того, кошти бізнес-аналізу (Business Intelligence and Report Tools, BIRT) доступні і для платформи Eclipse, що займає зараз половину ринку засобів розробки Java-додатків.

Залучення замовника в процес розробки

Оцінка вкладу розробників додатків в успіх бізнесу компанії-замовника, так само як і оцінка якості самого процесу розробки і його результату завжди була спірним питанням і приводом для непорозуміння і конфліктів. Однак останнім часом з'явилися методи оцінки зрілості процесів розробки і рекомендації, засновані на моделі Capability Maturity Model Integration (CMMI), а також ряд методологій розробки додатків, що надає замовнику додатки можливість контролювати хід процесу розробки. Модель CMMI дозволяє оцінити і вдосконалити процеси розробки додатків і скористатися вдалими прикладами постановки подібних процесів, і наявність оцінки того чи рівня зрілості відповідно до цієї моделі у компанії-розробника певною мірою є гарантією якості кінцевого результату процесу розробки продукту в цій компанії.

Сімейство методологій розробки додатків під загальною назвою Agile methodologies (що включає, зокрема, методологію екстремального програмування, про яку ми писали кілька місяців тому) надає «рецепти» для щоденного управління проектною командою, включаючи, поряд з іншими, принцип розробки, керованої тестуванням (Test -Driven Development, TDD), зарекомендував себе як засіб отримання високоякісного коду. Особливістю даного сімейства методологій є залученість замовника в процес розробки з тим, щоб він міг його контролювати на всіх етапах.

Найпопулярніші архітектури і платформи

Архітектура, орієнтована на сервіси

Одна з сучасних тенденцій розвитку ІТ-інфраструктури сучасних підприємств і архітектур корпоративних додатків - перехід до архітектури, орієнтованої на сервіси (Service Oriented Architecture, SOA). Дана архітектура припускає створення і впровадження розподілених додатків і служб, заснованих на застосуванні різних технологій, наприклад веб-служб (так, подібні технології широко підтримуються платформою Eclipse і засобами розробки від Borland і Microsoft).

Найбільш популярні платформи

Одна з найбільш помітних тенденцій останнього часу проявляється в уніфікації платформ, для яких створюється більшість додатків, і виділення серед них двох лідерів - Windows / Microsoft .NET і Java / J2EE. Це багато в чому обумовлено здатністю зазначених платформ забезпечити можливість створення додатків, ступінь захисту даних в яких, так само як і можливості створення користувацьких інтерфейсів і забезпечення доступу до сервісів і даних, відповідають сучасним вимогам. Втім, зазначена тенденція вже давно ні для кого не нова.

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

Зростання популярності мобільних платформ

Сьогодні мобільні додатки розробляються приблизно для півтора десятка платформ. Відповідно до проведеного в кінці минулого року дослідницькою компанією Evans Data Corp. опитуванням декількох сотень розробників мобільних додатків, Основними лідерами в цій галузі являются.NET Compact Framework і Java 2 Mobile Edition (J2ME), а також інші платформи Microsoft для мобільних пристроїв і Embedded Linux (рис. 1).

Мал. 1. Популярність мобільних платформ серед розробників (джерело - Developers 'Choice Wireless Platforms. Definitive Rankings of Wireless Platform by Developers Worldwide - Evans Data Corp., September 2005)

Проте, згідно з тим же опитуванням, в плані задоволення розробників якістю інструментів і рівнем підтримки спільноти розробників перше місце зараз займає платформа Nokia Series 60. За прогнозами тієї ж Evans Data Corp., на ринку мобільних платформ очікується зростання частки Embedded Linux.

Що стосується коштів розробки додатків, для платформи Windows Mobile інструменти від Microsoft існують вже протягом декількох років. Інструменти компанії Borland доступні для платформ.NET Compact Framework, Symbian і J2ME. Крім того, є деякі інструменти розробки мобільних додатків компанії Sybase, а також ряду інших виробників.

Інструменти для розробників сьогодні

Вузька спеціалізація розробників привела до активного розвитку протягом останніх п'яти років так званих засобів підтримки життєвого циклу додатків, призначених для великих колективів розробників. До подібних засобів відносяться засоби управління вимогами, моделювання бізнес-процесів, додатків і даних, тестування і оптимізації додатків, управління колективною роботою, контролю версій, управління змінами. Проводять такі інструменти багато провідних постачальники ПО: IBM, Computer Associates, Borland, Microsoft, Oracle та ряд інших.

Останнім часом багато хто інструментів подібного призначення стали приділяти багато компаній, які раніше спеціалізувалися на створенні середовищ розробки (зокрема, IBM, Computer Associates, Borland, Microsoft, Oracle та Sybase). Потреба у взаємній інтеграції всіх цих «важких» інструментів призвела до створення цілих платформ для рольової розробки програмного забезпечення та управління життєвим циклом додатків - такі платформи зараз виробляються компаніями Borland, IBM, Microsoft і рядом інших.

Як правило, застосування подібних інструментів вимагає розгляду процесу розробки програмного забезпечення як виробничого процесу і відповідно створення і впровадження методик управління цим процесом, схожих з методиками управління процесами матеріального виробництва. Впровадження подібних методик часто здійснюється шляхом реалізації окремих (і не дешевих!) ІТ-проектів по впровадженню в компаніях - розробників інтегрованих платформ розробки додатків з метою автоматизації та оптимізації процесів, які супроводжують розробку, включаючи постановку завдань, управління вимогами, досягнення відповідності стандартам якості.

Безкоштовні версії комерційних інструментів

Якщо згадати, що відбувалося з інструментами для розробки в останні два роки, можна помітити, що останнім часом досить активно проявилася тенденція випуску провідними виробникам засобів розробки їх безкоштовних версій (причому з непоганими функціональними можливостями) З метою привернути увагу розробників до потенціалу і можливостям повнофункціональних продуктів і платформ, для яких вони призначені. Зокрема, компанія Borland вже приблизно три роки випускає безкоштовні версії деяких своїх коштів розробки. Корпорацією Microsoft недавно було випущено сімейство продуктів Express, що включає кілька інструментів для розробки додатків Windows Forms і ASP .NET. Корпорація Oracle, в свою чергу, також надала вільний доступ розробників до інструменту Oracle JDeveloper 10g.

Інструменти з відкритим кодом

Спостерігається ще одна тенденція, характерна для сучасного ринку засобів розробки, - активне зростання популярності платформ та інструментів з відкритим вихідним кодом, в розвиток яких зараз інвестується чимало коштів комерційними компаніями, в тому числі такими відомими виробниками платформ, як IBM, Novell і Oracle. Серед найбільш яскравих прикладів слід відзначити активний розвиток середовища Eclipse - універсальної відкритої платформи розробки, сумісної з безліччю мов, платформ розгортання і технологій, а також проекту Mono реалізації частини платформи.NET для операційної системи Linux (для останньої зараз активно випускаються компілятори і інші інструменти) .

Початок проекту Eclipse було покладено в 1998 році корпорацією IBM, яка поставила перед собою мету створення інтегрованої середовища Java-розробки нового покоління, що розширюється за рахунок вбудованих в неї інтегруються інструментів, силами кількох постачальників Java-інструментів. З цією метою корпорація IBM в кінці 2001 року надала спільноті Open Source частина вихідного коду свого кошти розробки Java-додатків WebSphere Studio Workbench і сформувала консорціум Eclipse (що включав представників компаній Borland, IBM, MERANT, QNX Software Systems, Rational Software, Red Hat, SuSE , TogetherSoft і Webgain) для управління подальшим розвитком цього середовища розробки, перетворений в подальшому в незалежну некомерційну організацію Eclipse Foundation, яка налічує сьогодні 115 членів.

Сьогодні, після п'яти років з моменту її створення, платформа Eclipse стала настільки популярна, що почала витісняти з ринку широко застосовувалися комерційні інструменти (наприклад, деякі засоби Java-розробки). Сьогодні частка ринку засобів розробки Java-додатків, яку займає Eclipse, становить приблизно 50%. При цьому протягом попереднього року явно спостерігалася тенденція перетворення Eclipse з середовища Java-розробки в платформу інтеграції інструментів для всього життєвого циклу розробки додатків - недавно в рамках консорціуму Eclipse були розпочаті такі проекти, як створення графічного середовища моделювання, інструментів для архітектури, орієнтованої на сервіси , а також випущені оновлені версії інструментів тестування, бізнес-аналізу, засобів створення web-додатків.

Що стосується власне засобів розробки додатків, на основі платформи Eclipse зараз створені середовища розробки для PHP, Fortran, Macromedia Flex; планується випуск ряду інструментів для розробки додатків для вбудованих і мобільних платформ. Для платформи Eclipse існують і комерційні засоби розробки компаній IBM, Borland і SAP.

Найпопулярніші середовища розробки

Згідно з опитуванням 1200 розробників, проведеним у червні цього року дослідницькою компанією Evans Data Corp., найбільш широко використовуваною середовищем розробки виявилася Microsoft Visual Studio .NET (рис. 2).

Мал. 2. Частота використання середовищ розробки (джерело - Developers 'Choice IDE Scorecard - Evans Data Corp., June 2006)

За даними того ж опитування, найбільш популярною в плані функціональності середовищем розробки додатків виявилася IBM Rational Application Developer, визнана учасниками опитування найкращою в якості інструменту моделювання і складання додатків і володіє кращим набором прикладів (рис. 3).

Результати даного опитування відображають вже згадані тенденції переважання двох найбільш популярних платформ (Windows / Microsoft .NET і Java / J2EE - практично всі популярні середовища розробки призначені для цих платформ) і зростання популярності коштів і платформ розробки з відкритим кодом (Про що свідчить присутність Eclipse в п'ятірці найпопулярніших середовищ розробки).

Отже, сучасні тенденції розвитку технологій розробки додатків включають зменшення частки розробки додатків в ІТ-проектах, поступовий перехід від малотиражного виробництва ексклюзивного програмного забезпечення до масового промислового виробництва типових рішень, все більш активне застосування засобів підтримки життєвого циклу розробки додатків (включаючи проекти впровадження інтегрованих платформ для розробки додатків). Останнім часом також посилився інтерес до створення додатків для мобільних платформ. Характерною тенденцією останніх років є також поява високоякісних інструментів з відкритим кодом. Не виключено, що названі тенденції збережуться ще протягом як мінімум кількох років.