ПЕРЕЛІК ДИСЦИПЛІН:
  • Адміністративне право
  • Арбітражний процес
  • Архітектура
  • Астрологія
  • Астрономія
  • Банківська справа
  • Безпека життєдіяльності
  • Біографії
  • Біологія
  • Біологія і хімія
  • Ботаніка та сільське гос-во
  • Бухгалтерський облік і аудит
  • Валютні відносини
  • Ветеринарія
  • Військова кафедра
  • Географія
  • Геодезія
  • Геологія
  • Етика
  • Держава і право
  • Цивільне право і процес
  • Діловодство
  • Гроші та кредит
  • Природничі науки
  • Журналістика
  • Екологія
  • Видавнича справа та поліграфія
  • Інвестиції
  • Іноземна мова
  • Інформатика
  • Інформатика, програмування
  • Юрист по наследству
  • Історичні особистості
  • Історія
  • Історія техніки
  • Кибернетика
  • Комунікації і зв'язок
  • Комп'ютерні науки
  • Косметологія
  • Короткий зміст творів
  • Криміналістика
  • Кримінологія
  • Криптология
  • Кулінарія
  • Культура і мистецтво
  • Культурологія
  • Російська література
  • Література і російська мова
  • Логіка
  • Логістика
  • Маркетинг
  • Математика
  • Медицина, здоров'я
  • Медичні науки
  • Міжнародне публічне право
  • Міжнародне приватне право
  • Міжнародні відносини
  • Менеджмент
  • Металургія
  • Москвоведение
  • Мовознавство
  • Музика
  • Муніципальне право
  • Податки, оподаткування
  •  
    Бесплатные рефераты
     

     

     

     

     

     

         
     
    CASE-мислення: ви готові програмувати інакше ?
         

     

    Інформатика, програмування

    CASE-мислення: ви готові програмувати інакше?

    С. Трофімов

    Фраза, винесена в заголовок, створена за аналогією з "об'єктно-орієнтованим мисленням ". Для того щоб створювати об'єктно-орієнтовані програми, необхідно відмовитися від традиційного процедурного мислення і почати мислити за допомогою об'єктів [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)

    Список літератури

    Для підготовки даної роботи були використані матеріали з сайту http://progcpp.narod.ru/

         
     
         
    Реферат Банк
     
    Рефераты
     
    Бесплатные рефераты
     

     

     

     

     

     

     

     
     
     
      Все права защищены. Reff.net.ua - українські реферати ! DMCA.com Protection Status