С. Трофімов
Фраза, винесена у заголовок, створена за аналогією з "об'єктно-орієнтованим мисленням". Для того щоб створювати об'єктно-орієнтовані програми, необхідно відмовитися від традиційного процедурного мислення і почати мислити за допомогою об'єктів [1]. Те ж справедливо і для CASE-засобів. Для того щоб почати створювати програмні системи за допомогою сучасних технологій, необхідно інакше поглянути не тільки на процес проектування, а й на програмування.
Труднощі впровадження CASE-технологій при створенні проектів загальновідомі [2], і проектувальники систем повинні бути готові до їх подолання. Але я хочу представити ці проблеми з точки зору програміста, який міцно влаштувався у своєму світі програмного коду і не мислить інших можливостей для написання програм, як "рядок до рядка", коли класи створюються послідовним наповненням методів і атрибутів.
Необхідність використання CASE-технологій безпосередньо розробниками програм менш очевидна ніж для проектувальника системи [3], причому в [2] ми читаємо, що "моделювання складних програмних систем за допомогою CASE-засобів є самостійним і самодостатнім видом діяльності в процесі створення ПЗ", що може спочатку отримати негативну оцінку у програмістів. Мовляв, я пишу програми, а створювати моделі - це ваші труднощі.
Для більшості програмістів при створенні програмних систем більш очевидна необхідність процесу створення коду, ніж моделювання самої системи. До того ж попереднє створення моделі системи включає в себе додаткові затрати праці, результат яких видно тільки через деякий час, і це при тому, що освоєння складних CASE-засобів вимагає значних зусиль.
Основною причиною, що породжує насторожене або, можливо, навіть негативне ставлення до CASE-засобів з боку програмістів, на мою думку - це труднощі переходу зі звичайного мислення до CASE-мисленню. Під ним я маю на увазі подання системи у вигляді об'єктів, які відображаються в термінах CASE-засоби, зазвичай в діаграмах мови UML. Причому, спочатку мається на увазі, що всі об'єкти системи розробляються або, принаймні, мають своє відображення в цих діаграмах.
Для того щоб перейти до створення та супроводу коду за допомогою CASE-засобу, що підтримує мова UML, такого, наприклад, як Rational Rose, програміст повинен перебудувати своє уявлення про створення програм. Необхідно мислити вже в термінах мови UML, мислити діаграмами, а перехід до такого типу мислення вимагає приблизно такого ж зусилля, як перехід від процедурного програмування до об'єктно-орієнтованого.
Буде помилкою вважати, що вивчивши можливості редактора UML (якщо абстрагуватися від додаткових функцій, то таких можна уявити Rational Rose), ви почнете відразу створювати програмні системи. Як стверджується в [1], діаграми не з'являються самі по собі, вони - результат об'єктно-орієнтованого проектування, тобто саме мислення, причому в термінах CASE-засоби.
Тут переплітаються дві абсолютно різні завдання:
1.Изучение мови UML і розвиток CASE-мислення.
2.Изучение можливостей конкретного CASE-засоби, для того щоб легко втілити свої думки в проекті Програми. Для першого я б рекомендував книги [1,4], а для другого можна скористатися, наприклад [5].
Програміст, приступаючи до вивчення Rational Rose, стикається з цими проблемами, які входять у протиріччя з його попереднім досвідом. Вважаючи, що CASE-засіб - це просто програма, яка допомагає ..., автоматизує ..., вирішує ..., він з ентузіазмом намагається в ній розібратися, але впирається в свою ж відсталість, що не дозволяє поглянути на створюване ПЗ з боку .
На відміну від більшості інших програм, де, освоївши деякі прості функції, можна створювати щось нескладне, а потім, якщо знадобиться, поглибити свої знання, тут неможливо навіть почати працювати, не охопивши всіх діаграм цілком, не розібравшись як і для чого вони повинні використовуватися .
Діаграми UML дозволяють показати різні аспекти майбутньої системи, створити її модель, перед тим як з головою кидатися в написання коду. Не усвідомивши до кінця всіх можливостей створення цієї моделі, просто не можна її отримати. Не побудувавши фундамент, не можна будувати стіни, але вже при закладці фундаменту потрібно розраховувати на те, які стіни будуть на ньому стояти. І порушення цього принципу призведе до того, що ви отримаєте не стрункий будівлю програмної системи, а не пов'язані між собою окремі блоки, які нікуди не годяться.
Застосовуючи CASE-мислення, програміст вже зробить свої програми краще, адже багато програмісти не знають ні способу створення хорошої, ні ознак невдалої програмної архітектури [6], а подання програмних об'єктів в діаграмах UML дозволяє наочно побачити помилки і недоробки в отриманій ієрархії, обговорити їх з колегами і, що найприємніше, легко цієї ієрархією маніпулювати, що при ручному кодуванні програміст навряд чи може собі дозволити.
Таким чином, можна підвести підсумок, що успіх впровадження CASE-систем залежить не тільки від зусиль керівника впровадження, а й від здатності програмістів освоїти новий для них CASE-мислення, тобто мислення в термінах впроваджуваної CASE-системи, що вимагає докладання значних зусиль як менеджерів, так і самих програмістів.
Список літератури
Буч Г. Об'єктно-орієнтований аналіз та проектування з прикладами додатків на С + +, 2-е вид. / Пер з англ.-М.: "Видавництво Біном", СПб.: "Невський діалект", 1999 р. -560 з ., іл.
Вендров А. Ніша та впровадження CASE-засобів. "Директору ІС", листопад 2000. (Http://www.interface.ru/CASE/botcase.htm)
Новачків А. Rational Rose для розробників і заради розробників. (Http://www.interface.ru/rational/rose/develop.htm)
Фаулер М., Скотт К. UML у короткому викладі. Застосування стандартного мови об'єктного моделювання: Пер. з англ. - М.: Світ, 1999. - 191 с., Іл.
Трофимов С. CASE-технології: практична робота в Rational Rose - М.: ЗАТ "Видавництво БИНОМ", 2001 р. - 272 с.: Іл. (Http://progcpp.narod.ru/rational/)
Бюрер К. Від ремесла до науки: пошук основних принципів розробки ПЗ (http://www.interface.ru/rational/science.htm)