CASE-технології

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

Функціонально-модульний підхід заснований на принципі алгоритмічної декомпозиції з виділенням функціональних елементів і встановленням суворого порядку виконуваних дій.

Об'єктно-орієнтована підхід заснований на об'єктної декомпозиції з описом поведінки системи в термінах взаємодії об'єктів.

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

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

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

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

Розглянуті раніше (див. Підрозд. 3.1) концепції об'єктно-орієнтованого підходу і розподілених обчислень стали базою для створення консорціуму Object Management Group (OMG), членами якої є понад 500 провідних комп'ютерних компаній (Sun, DEC, IBM, HP, Motorola та ін. ). Основним напрямком діяльності консорціуму є розробка специфікацій і стандартів для створення розподілених об'єктних систем в різнорідних середовищах. Базисом стали специфікації під назвою Object Management Architecture (ОМА).

ОМА складається з чотирьох основних компонентів, що представляють специфікації різних рівнів підтримки додатків (рис. 5.10):

• • архітектура брокера запитів об'єктів (CORBA - Common Object Request Broker Architecture) визначає механізми взаємодії об'єктів в різнорідної мережі;
• • об'єктні сервіси (Object Services) є основними системними сервісами, використовуваними розроблювачами для створення додатків;
• • універсальні засоби (Common Facilities) є високорівневими системними сервісами, орієнтованими на підтримку користувальницьких додатків (електронна пошта, засоби друку та ін.);
• • прикладні об'єкти (Application Object) призначені для вирішення конкретних прикладних завдань.

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

Існує кілька об'єктно-орієнтованих методів, авторами найбільш поширених з них є Буча, Д.Рамбо, І.Джекобсон. В даний час спостерігається процес зближення об'єктно-орієнтованих методів. Зокрема, зазначені вище автори створили і випустили кілька версій уніфікованого методу UML (Unified Modeling Language - уніфікована мова моделювання).

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

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

Сучасні CASE-засоби підтримують процеси інжинірингу та автоматизованого реінжинірингу.

Мал. 5.10. Специфікація ОМА

Мал. 5.11. Ідеальне об'єктно-орієнтоване CASE-засіб

Ідеальне об'єктно-орієнтоване CASE-засіб (рис. 5.11) має містити чотири основні блоки: аналіз, проектування, розробка і інфраструктура [34].

Основні вимоги до блоку аналізу:

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

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

• • підтримка всього процесу проектування програми;
• • можливість роботи з бібліотеками, засобами пошуку та вибору;
• • можливість розробки призначеного для користувача інтерфейсу;
• • підтримка стандартів OLE, ActiveX і доступ до бібліотек HTML або Java;
• • підтримка розробки розподілених або дво- і триланкових клієнт-серверних систем (робота з CORBA, DCOM, Internet).

Основні вимоги до блоку реалізації:

• • генерація кола повністю з діаграм;
• • можливість доопрацювання додатків в клієнт-серверних CASE-засобах типу Power Builder;
• • реінжиніринг кодів і внесення відповідних змін до модель системи;
• • наявність засобів контролю, які дозволяють виявляти невідповідність між діаграмами і генеруються кодами і виявляти помилки як на стадії проектування, так і на стадії реалізації.

Основні вимоги до блоку інфраструктури:

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

У табл. 5.3 наведено огляд найбільш поширених об'єктно-орієнтованих CASE-засобів [34].

Та бліцу 5.3

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

Виділимо основні критерії оцінки та вибору CASE-засобів.

• 1. Функціональні характеристики:
  • • середовище функціонування: проектна среда, програмне забезпечення / технічні засоби, технологічне середовище;
  • • функції, орієнтовані на фази життєвого циклу: моделювання, реалізація, тестування;
  • • загальні функції: документування, управління конфігурацією, управління проектом;
• 2. Надійність;
• 3. Простота використання;
• 4. Ефективність;
• 5. сопровождаемости;
• 6. Переносимість;
• 7. Загальні критерії (вартість, витрати, ефект впровадження, характеристики постачальника).

Дані критерії детально викладені в стандартах IEEE Std 1348-1995. IEEE recommended Practice for the Adoption of Computer - Aided Software Engineering (CASE) Tools і IEEE Std 1209-1992 Recommended Practice for the Evaluation and Selection of CASE Toois.