Повна версія

Головна arrow Інформатика arrow Інформаційні технології

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

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. Специфікація ОМА

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

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

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

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

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

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

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

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

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

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

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

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

Та бліцу 5.3

№ п / п

Продукт, фірма-розробник

Підтримувані

платформи

використовувані коди

генерація коду

опис

1

Bridge Point (версія 3.2.1), Project Tehnology

Unix,

SIG-Irix

Шлеер /

Меллор

C / C ++

Підтримка повного життєвого циклу в рамках методики "Шлеер / Меллор", генерація коду

2

Grapical Designer (версія 2.0), Advanced Software Technologies

Unix,

Windows NT Windows 95

Г. Буч, І. Джекоб- сон, ОМТ, Шлеер / Меллор, UML.08 і структурна нотація

C / C ++

Генерація коду і реінжиніринг для кожного з підтримуваних мов і методологій. Командна робота. Можливість створення власної нотації

3

Life Model for OOOIE (версія 1), InteliCorp

Unix,

Windows NT

Мартін / Оделл (001Е)

З

Засіб є верхнім рівнем фірмового продукту штучного інтелекту Карра. Прототипування в режимі інтерпретатора, генерація коду, створення екранів і т.д. Можливість програмування на С або на внутрішньому script- мовою типу Prolog

4

ObjectTime, Object Time Ltd

Unix

ROOM

C ++

Створення і візуалізація виконуваних моделей систем реального часу на основі ГО-методології реального часу (ROOM). Внутрішній script-мову - підмножина "Smalltalk"

5

Objectory (версія 3.7), Rational Software

Unix, OS / 2, DOS5, Windows 3.1,95, NT

І. Джекоб - сон

C ++,

Small

talk

Два варіанти: Analysis Workbench для ГО-ана- лізу і Design Workbench для проектування. Зв'язок з VisualWorks і C ++ Softbench. BPR на основі методу Джскобсона. Так як Objectory перейшло до Rational, то невідомо, як довго ще продукт буде підтримуватися

6

Object Partner (версія 2.0), Verilog

Unix

ОМТ

C ++

Поширює Verilog, а також Logiscope і Object- Geode

7

ObjectTeamEnterprisc (версія 1) Cayenne Software

Unix

OMT

C ++

Cayenne об'єднує Cadre і Bachman technology. Користувачам ObjectTeam (метол Шлеер / Меллор) пропонується звернутися до продуктам BridgcPoint

8

Objeci Maker (версія 4.2, 1995) Mark V

Unix, Windows 3.1,95, NT

15 нотацій, зокрема: Г. Буч,

ОМТ, Шлеер / Меллор, Кол / Йор- дон і ін.

Ada

'83, '95, C / C ++, Smalltalk

Загальний репозиторій в мережі, командна робота. Є локальний продукт Object Maker Consulant

9

ParadigmPlus (версія 3.0) Platinum Technology (formerly Proiosoft)

Unix, OS / 2, Windows 3.1, 95, NT

8 нотацій, зокрема:

Г. Буч,

ОМТ, Шлеер / Мсллор, Fusion і т.д.

Ada,

C / C ++,

Smalltalk,

Java

Генерація SQL, ГО і реляційні БД. Реінжиніринг для Forte, PowerBuilder, VisualWorks, Visual Smalltalk Enterprise, VisualAge, ObjectPro. Object- Store. OODB як сховища

10

Ptech (версія 4.0), PtechInc.

Windows 95, NT, Unix

мар-

тин / Оделл

(OOIE)

C ++,

Forte

2.0

Інтегрований з Object- Store, Objectivity, ONTOS. Генерація коду для бібліотек класів Tools.h ++, USL

11

Rational Rose (версія 3.0), Rational Software

Windows 3.1, 95, NT, UNIX

(Solaris, HP UX. AIX)

Г. Буч, ОМТ

Ada,

C ++,

Smalltalk,

Visual

Basic,

Java,

Forte

SQL

Windows,

PowerBu

ilder

Конвертація Буч / ОМТ. Підтримка Java, COBRA. Реінжиніринг коду з Forte SQLWindows, PowerBuilder і ГО-мов. Оголошено про випуск нового засобу роботи з COBRA.

12

System Architect Object (версія 3.1), Popkin Software and System

Windows 3.1. OS / 2

Буча,

ОМТ, Шлеер / Меллор, Кол / йор - дон, CRC, І. Джекоб сон

C ++,

Smalltalk,

Java

Підтримка структурних методологій. BPR на основі IDEF-діаграм. Зв'язок з PowerBuilder

13

Software through Piclurcs / OMT and BUCH (версія 3.2),

Interactive

Development

Environments

Unix

ОМТ або

Г. Буч,

І. Джекобсон

C ++, Smalltalk, Java і OMGI DL

Є продукти для структурних методологій. CASE для BPR. Підтримка, Java, HTML, Netscape Navigator, COBRA, зв'язок Net Links Oibitaze, SNiFF +. реінжиніринг

14

SES / Objcctbench (версія 2.2), Scientific and Engineering Software

Unix

ООА

C / C ++

Об'єктно-орієнтований аналіз

15

Together / C ++,

Object

International

Windows 3.1

Код / Йорлом

C ++

Версія для командної роботи, яка працює і під Windows 3.1

Порівняльний аналіз 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.

 
<<   ЗМІСТ   >>