Повторне використання коду (модульне програмування)

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

Модульне програмування.Головний принцип модульного програмування складався у виділенні таких фрагментів і оформленні їх у вигляді модулів. Кожен модуль забезпечувався описом, у якому встановлено правила його використання - інтерфейс модуля. Інтерфейс ставив зв'язку модуля з основною програмою - зв'язки за даними і зв'язку з управління. При цьому можливість повторного використання модулів визначалася кількістю і складністю цих зв'язків, або наскільки ці зв'язки вдалося погоджувати з організацією даних і управління основної програми. Найбільш простими в цьому відношенні виявилися модуль рішення математичних задач: рішення рівнянь, систем рівнянь, задач оптимізації. До теперішнього часу накопичений і успішно використовуються великі бібліотеки таких модулів.

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

Для її рішення розробляються спеціальні форми (структури) подання моду-лий та організації їх інтерфейсів.

Зростання складності програм (структурне програмування)

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

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» також не змінюється - він продовжує вважати, що працює з об'єктом «Зарплата».

Структура звіту з  лабораторної роботи № 2

1. Титульна сторінка (див. Додаток А)

2. Тема, мета, завдання.

3. Лістинг програми із внесеними змінами.

4. Копії екранів з результатами виконання програми до внесення змін.

5. Копії екранів з результатами виконання програми після внесення змін.

6. Висновок.

Основні запитання

1. Особливості модульного, структурного, об’єктно-орієнтованого програмування.

2. Що таке інкапсуляція, унаслідування, поліморфізм?

3. Що таке public, private, protected?

4. Використання якого методу програмної інженерії є найбільш ефективним при зміні вимог до програми.

5. Для якого методу програмної інженерії характерне дублювання програмного коду.

Лабораторна робота № 3

Тема: Дослідження особливостей середовищ для аналізу вимог до ПЗ.

Мета:Дослідити особливості середовищ для аналізу вимог до ПЗ.

Завдання:

1. Створити дві діаграми бізнес процесів IDEF0 та дві діаграми потоків даних DFD в середовищі BPwin відповідно до варіанта.

2. Створити таблицю стрілок контекстної діаграми (див. теоретичні відомості, п. 3.1.13).

Теоретичні відомості

IDEF0— Function Modeling — методологія функціонального моделювання і графічного описання процесів, призначена для формалізації і опису бізнес-процесів. Особливістю IDEF0 являється її акцент на ієрархічне представлення об'єктів, що значно полегшує розуміння предметної області. В IDEF0 розглядаються логічні зв'язки між роботами, а не послідовність їх виконання в часі (WorkFlow). Так само відображаються всі сигнали управління. Дана модель являєтеся однією з найбільш прогресивних моделей і використовується в організації бізнес проектів і проектів, що базуються на моделюванні всіх процесів як адміністративних, так і організаційних.

Діаграма потоків даних (англ. Data Flow Diagram) — графічне представлення потоків даних в інформаційній системі. Діаграма потоків даних також може використовуватись для представлення обробки даних (структурна розробка). Вважається звичайним, для розробника, з початку креслити ДПД рівня контексту, завдяки чому буде показано взаємодію системи із зовнішніми модулями. Ця ДПД рівня контексту, потім розширюється, для того, щоб показати розроблювану систему детальніше. Діаграми потоків даних містять чотири типи графічних елементів: процеси, що представляють собою трансформацію даних в рамках системи, що описується, репозиторії (сховище даних), зовнішні по відношенню до системи сутності та потоки даних між елементами трьох попередніх типів.