Повторне використання коду (модульне програмування)
Проблема. На перших етапах становлення програмної інженерії (навіть коли вона так ще не називалася) було відзначено, що висока вартість програм пов'язана з розробкою однакових (або схожих) фрагментів коду в різних програмах. Викликано це було тим, що в різних програмах як частини цих програм вирішувалися однакові (або схожі) завдання: рішення нелінійних рівнянь, розрахунок заробітної плати, ... Використання при створенні нових програм раніше написаних фрагментів обіцяло істотне зниження термінів і вартості розробки.
Модульне програмування.Головний принцип модульного програмування складався у виділенні таких фрагментів і оформленні їх у вигляді модулів. Кожен модуль забезпечувався описом, у якому встановлено правила його використання - інтерфейс модуля. Інтерфейс ставив зв'язку модуля з основною програмою - зв'язки за даними і зв'язку з управління. При цьому можливість повторного використання модулів визначалася кількістю і складністю цих зв'язків, або наскільки ці зв'язки вдалося погоджувати з організацією даних і управління основної програми. Найбільш простими в цьому відношенні виявилися модуль рішення математичних задач: рішення рівнянь, систем рівнянь, задач оптимізації. До теперішнього часу накопичений і успішно використовуються великі бібліотеки таких модулів.
Для багатьох інших типів модулів можливість їх повторного використання виявилося проблематичним на увазі складності їх зв'язків з основною програмою. Наприклад, модуль розрахунку зарплати, написаний для однієї фірми, може не підійти для іншої, тому що зарплата в цих фірмах розраховується не у всьому однаково. Повторне використання модулів зі складними інтерфейсами є досить актуальною і донині.
|
|
|
Для її рішення розробляються спеціальні форми (структури) подання моду-лий та організації їх інтерфейсів.
Зростання складності програм (структурне програмування)
Проблема. Наступний етап зростання вартості ПО був пов'язаний з переходом від розробки відносно простих програм до розробки складних програмних комплексів. До числа таких складних програм будь-яка система управління космічними об'єктами, управління оборонним комплексом, автоматизації великого фінансового установи і т.д. Складність таких комплексів оцінювалася наступними показниками:
1. Великий об'єм коду (мільйони рядків)
2. Велика кількість зв'язків між елементами коду
3. Велика кількість розробників (сотні осіб)
4. Велика кількість користувачів (сотні і тисячі)
5. Тривалий час використання
Для таких складних програм виявилося, що основна частина їх вартості припадає не на створення програм, а на їх впровадження і експлуатацію. За аналогією з промислової технологією стали говорити про життєвий цикл програмного продукту, як про послідовність певних етапів: етапу проектування, розробки, тестування, впровадження та супроводу.
|
|
|
Структурне програмування. Етап супроводу програмного комплексу включав дії з виправлення помилок в роботі програми та внесення змін у відповідності зі зміненими вимогами користувачів. Основна причина високої вартості (а часом і неможливість виконання) етапу супроводу полягала в тому, що програми були погано спроектовані - документація була не зрозуміла і не відповідала програмного коду, а сам програмний код був дуже складний і заплутаний. Потрібна технологія, яка забезпечить «правильне» проектування та кодування. Основні принципи технології структурного проектування та кодування:
1. Спадний функціональне проектування, при якому в системі виділяються основні функціональні підсистеми, які потім розбиваються на підсистеми і т.д. (Принцип «розділяй і володарюй»)
2. Застосування спеціальних мов проектування і засобів автоматизації використання цих мов
3. Дисципліна проектування та розробки: планування та документування проекту, підтримка відповідність коду проектної документації
|
|
|
4. Структурний кодування без goto
Модифікація програм (ООП)
Проблема. Наступна проблема зростання вартості програм була викликана тим, що зміна вимог до програми стали виникати не тільки на стадії супроводу, але і на стадії проектування - проблема замовника, який не знає, що він хоче. Створення програмного продукту перетворилося на його перманентне перепроектування. Виникло питання як проектувати і писати програми, щоб забезпечити можливість внесення змін в програму, не змінюючи раніше написаного коду.
Об'єктно-орієнтоване програмування. Рішенням цієї проблеми стало використання підходу чи методу, який стали називати об'єктно-орієнтованим проектуванням і програмуванням. Суть підходу полягає в тому, що вводиться поняття класу як розвиток поняття модуля з певними властивостями і поведінкою, що характеризують обов'язки класу. Кожен клас може породжувати об'єкти - екземпляри даного класу. При цьому працюють основні принципи (парадигми) ООП:
1. Інкапсуляція - об'єднання в класі даних (властивостей) і методів (процедур обробки).
2. Унаслідування - можливість виведення нового класу зі старого з частковою зміною властивостей і методів
|
|
|
3. Поліморфізм - визначення властивостей і методів об'єкта по контексту
Проілюструвати можливості принципів ООП можна на наступному прикладі. В організації, що складається з трьох відділів треба нараховувати заробітну плату. У програмі кожен відділ представлений своїм модулем - об'єктом, а нарахування зарплати - об'єктом «Зарплата». При необхідності розрахунку зарплати об'єкту «Відділ» передається екземпляр об'єкта «Зарплата». Об'єкт «Відділ» передає об'єкту «Зарплата» необхідні дані і потім за допомогою методів об'єкта «Зарплата» виконує необхідні розрахунки.
У відділі 3 частково змінилися правила нарахування зарплати. У цій ситуації при об'єктно-орієнтованому підході з класу «Зарплата» виводиться клас «Зарплата 1», який успадковує незмінних правил нарахування зарплати і перевизначають що змінилися. Тут при розрахунку зарплати об'єктам «Відділ 1» і «Відділ 2» буде пере-даватися об'єкт «Зарплата», а об'єкту «Відділ 3» - об'єкт «Зарплата 1». При таких змінах:
1. Спрацьовує принцип спадкування: код «Зарплата», «Відділ 1» і «Відділ 2» залишаються без зміни, а код «Зарплата 1» змінюється рівно настільки, наскільки це необхідно.
2. Спрацьовує принцип поліморфізму: код «Відділ 3» також не змінюється - він продовжує вважати, що працює з об'єктом «Зарплата».
Дата добавления: 2018-05-13; просмотров: 657; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!