< Попередня  Змiст  Наступна >

1.5. ІНТЕГРОВАНІ CASE-СЕРЕДОВИЩА


Хоча при виконанні окремих робіт з розроблення ІС можна досягти певних переваг за умови використання відокремлених

 

CASEзасобів, найвідчутніший ефект забезпечує їх інтеграція. Інтеграція CASEзасобів створює такі переваги:

 

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

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

— підвищення контрольованості проекту шляхом поліпшення планування, моніторингу та комунікацій;

— удосконалення координації між учасниками великого проекту.

 

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

 

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

 

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

— можливості відстежування впливу змін в одній інформаційній сутності на інші;

— контроль версій та суцільне керування конфігурацією;

— прямий доступ до будьякого засобу середовища;

— стандартизований інженерний підхід із застосуванням сучасної практики та перевірених методів;

— автоматизовану підтримку обраної моделі життєвого циклу ІС;

— інтеграцію CASEзасобів та одиниць конфігурації в єдину структуру розбивки робіт (Work Breakdown Structure, WBS);

— однаковий вигляд та єдиний спосіб роботи для всіх засобів у  рамках стандартизованого людиномашинного інтерфейсу;

— підтримку комунікацій між учасниками проекту;

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

 

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

 

В архітектурі ICASE, як правило, виокремлюють такі основні архітектурні компоненти: баз a даних для зберігання інформації, система керування об’ єктами для керування змінами інформації, система керування засобами для координації використання CASEзасобів, користувацький інтерфейс.

Більшість моделей подають названі компоненти у вигляді чотирьох рівнів (рис. 1.5):

Модель архітектури ICASE

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

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

 

3)  рівень керування об’єктами здійснює функції конфігураційного керування шляхом ідентифікації всіх конфігураційних об’єктів, контролю версій та підтримки контролю змін, обліку та аудиту. Фактично саме цей рівень забезпечує інтеграцію засобів і доступ до репозиторію ICASE;

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

 

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

 

Репозиторій ICASE — це сукупність механізмів і структур даних, які забезпечують інтеграцію у кількох аспектах:

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

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

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

— інтеграція «дані — дані» — встановлення зв’язків між об’єктами даних для виконання інших функцій;

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

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

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

 

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

— опис проблеми, що потребує вирішення;

— опис предметної області;

— розв’язок проблеми;

      — правила та інструкції з обраного процесу розробки ІС (методології);

— план проекту, його ресурси та історія;

— опис організаційного контексту.

Детальний зміст репозиторію подано у табл. 1.2.

Таблиця 1.2

ЗМІСТ РЕПОЗИТОРІЮ CASEСИСТЕМИ

Підприємство

Конструювання

Організаційна структура

Початковий код, об’єктний код

Результати бізнесаналізу

Інструкції з побудови системи

Бізнесфункції

Бінарні зображення

Бізнесправила

Конфігураційні залежності

Моделі процесу (сценарії)

Інформація щодо змін

Інформаційна архітектура

 

Проектування

Перевірка і верифікація

 

Правила методології

План тестування

 

Графічне подання

Набори тестових даних

 

Діаграми систем

Скрипти регресійних тестів

 

Стандарти найменувань

Результати тестування

 

Правила забезпечення посилкової

Результати статистичного аналізу

 

цілісності

Метрики якості ПЗ

 

Структури даних

Управління проектом

 

Визначення процесів

 

План виконання проекту

 

Визначення класів

 

Дерева меню

Структура розбивки роботи (WBS)

 

Критерії продуктивності

Оцінки, розклади

 

Часові обмеження

Завантаження ресурсів

 

Опис екранів

Звіти про проблеми

 

Опис звітів

Запити на зміни

 

Опис логіки

Звіти про статус проекту

 

Поведінкова логіка

Результати аудиту

 

Алгоритми

Системна документація

 

Правила трансформації

 

Документація щодо вимог

 

 

 

 

Зовнішній/внутрішній дизайн

 

 

Керівництво користувача

 

Сильний CASEрепозиторій має виконувати два типи функцій: 1) функції досконалої СКБД (зазвичай реляційної або об’єктноорієнтованої):

 

— зберігання ненадмірних даних — кожен об’єкт записується тільки один раз, але стає доступним усім CASEзасобам;

— високорівневий доступ — немає потреби дублювати засоби керування даними в кожному інструментальному засобі;

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

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

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

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

— забезпечення відкритості — простий механізм введення/виведення для завантаження або передавання великих обсягів даних;

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

 

2) функції, специфічні для CASEсередовища:

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

 

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

 

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

 

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

Наступні функції репозиторію охоплюються і системами конфігураційного керування (див. докладніше тему 6), що увиразнює їхній взаємний зв’язок:

 

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

 

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

 

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

 

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

 

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

 

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

 

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


< Попередня  Змiст  Наступна >
Iншi роздiли:
1.6.1. Процес оцінювання та вибору CASEсистем
1.6.2. Процес упровадження CASEсистем. Результати впровадження
Тема 2. АВТОМАТИЗОВАНЕ КЕРУВАННЯ ПРОЦЕСАМИ ЖИТТЄВОГО ЦИКЛУ ІНФОРМАЦІЙНИХ СИСТЕМ
2.1. КЕРУВАННЯ ПРОЦЕСАМИ ЯК ОБЄКТ АВТОМАТИЗАЦІЇ
2.2. ЗАСОБИ МОДЕЛЮВАННЯ ПРОЦЕСІВ IBM RATIONAL
Дисциплiни

Англійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki