Тема 4. АВТОМАТИЗОВАНА ПІДТРИМКА ПРИЙНЯТТЯ ПРОЕКТНИХ РІШЕНЬ

Як було зазначено у темі 1, першочерговим призначенням CASEсистем, зокрема нормальних, є автоматизація аналізу і проектування, від успішного проведення яких головною мірою залежить успіх ІТпроекту.

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

На підставі сказаного можна дійти двох висновків. З одного боку, головною вимогою до системи автоматизації аналізу і проектування є підтримка щонайменше одного з методів проектування, серед яких найрозвиненішими є структурні методи, що мають багато формалізованих нотацій і нормативних керівництв, та різноманітні методи, ґрунтовані на об’єктноорієнтованому підході (див. тему 5). З іншого боку, система аналізу і проектування має тісно інтегруватися з іншими CASEзасобами для забезпечення неперервності процесів розробки ІС. Сучасні тенденції автоматизації розробки ІС ведуть до певного розмивання меж між окремими видами CASEсистем.

До сучасних засобів автоматизації аналізу та проектування висувають такі функціональні вимоги:

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

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

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

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

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

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

3) підтримка навігації. Ця функція важлива, оскільки паралельне використання кількох подань (views) і діаграм у моделі ускладнює переходи між ними. Система має забезпечувати пересування між діаграмами, перехід від діаграми до розширеного опису елемента, відстеження використання окремого елемента в різних діаграмах та функції пошуку. Кожен елемент повинен мати гіперпосилання, що не показуються на роздруківці, але доступні у середовищі інструментального засобу. Операції та можливості навігації мають бути доступні з контекстного меню. Частини діаграм можуть бути розгорнуті для детального ознайомлення і згорнуті для вивчення оточуючих пакетів. Інший підхід до роботи зі складною діаграмою — використання фільтрів, які дозволяють виокремити частину інформацію, що має цінність для користувача, наприклад, зв’язки або класи певного типу;

4) підтримка колективної роботи — система має підтримувати одночасну роботу кількох користувачів над однією моделлю без втручань у роботу одне одного і конфліктів. Як правило, користувач, що працює над діаграмою, блокує на цей час доступ до неї для інших користувачів. У подальшому система має виокремлювати зміни, що вносяться до елементів у репозиторії із сумісним доступом, а рішення щодо прийнятності змін мають приймати користувачі. Відтак виникає необхідність у використанні системи керування конфігурацією;

4)генерування коду — удосконалені засоби спроможні перетворювати інформацію щодо моделі з репозиторію на чорновий код, що використовується як основа на етапі реалізації. Ескіз коду генерується цільовою мовою. Передусім це такі об’єктноорієнтовані мови програмування, як C++ або Java, а також SQL (Structured Query Language, мова структурованих запитів) для визначення схеми реляційної бази даних або IDL (Interface Definition Language, мова визначення інтерфейсу) для CORBAсумісних систем. Здебільшого це статична інформація — декларації класів, включно з атрибутами, і декларації методів. Тіло методів, що містить реальний програмний код, залишається пустим, згодом його має заповнити програміст, хоча теоретично можливе перетворення на код динамічних моделей. Таким чином має бути передбачено можливість підключення до системи генераторів кодів або компіляторів моделей.

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

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

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

Сполучення генерування коду зі зворотним інжинірингом позначається терміном «круговий/повторний інжиніринг» (roundtrip engineering). При цьому визначається модель, генерується код, його вивчають і змінюють у середовищі розробки, а згодом здійснюють зворотний інжиніринг для отримання моделі. Таким чином відбувається ітеративний процес розробки;

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

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

— засоби документування, що автоматично генерують документи і статистичну звітність за вмістом репозиторію;

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

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

— засоби специфікації вимог. Система моделювання може вибирати функціональні і нефункціональні вимоги з системи керування вимогами;

— засоби керування проектами і підтримки процесів. Оскільки розробка становить значну частину проекту, для успішного керування ним менеджер повинен мати можливість відстежувати перебіг проектування.