3.2. Еволюція розробки програмного продукту.

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

• статичний перегляд

• суміжний контроль

• призначений для користувача контроль

• ручна імітація.

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

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

Призначений для користувача контроль зовнішнього опису виражає участь користувача (замовника) в ухваленні рішень при розробці зовнішнього опису і його контролі. Якщо розробка вимог до ПС велася під управлінням користувача, то призначений для користувача контроль зовнішнього опису, по-существу, означає його суміжний контроль згори. Проте, якщо представникові користувача виявляється важко самостійно розібратися в зовнішньому описі, створюється спеціальна група розробників, виконуюча роль користувача (і що взаємодіє з ним) для проведення такого контролю.

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

3.3. Структурне програмування. Об'єктно-орієнтоване проектування.

Структурне програмування це методологія й технологія розробки серйозних програмних комплексів, заснована на наступних принципах:

- програмування повинне здійснюватися зверху-униз;

- увесь проект повинен бути розбитий на модулі з одним входом і одним виходом (оптимальний розмір модуля — кількість рядків на екрані дисплея);

- логіка алгоритму й програми повинна допускати тільки три основні структури: послідовне виконання, розгалуження й повторення. Неприпустимий оператор передачі керування в будь-яку крапку програми;

- при розробці документація повинна створюватися одночасно із програмуванням, у вигляді коментарів до програми.

Ціль структурного програмування — підвищення надійності програм, забезпечення супроводу й модифікації, полегшення й прискорення розробки.

Метод об'єктно-орієнтованого проектування грунтується на:

- ·моделі побудови системи як сукупності об'єктів абстрактного типу даних;

- ·модульній структурі програм;

- ·спадному проектуванні , використовуваному при виділенні об'єктів.

Об'єктно-орієнтований підхід використовує наступні базові поняття:

- ·об'єкт;

- ·властивість об'єкта;

- ·метод обробки;

- ·подія ;

- ·клас об'єктів.

Об'єкт - сукупність властивостей (параметрів) визначених сутностей і методів їх обробки (програмних засобів).

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

Властивість - характеристика об'єкта, його параметр. Всі об'єкти наділені певними властивостями, що у сукупності виділяють об'єкт із множини інших об'єктів.

Об'єкт має якісну визначеність, що дозволяє виділити його з множини інших об'єктів і обумовлює незалежність створення й обробки від інших об'єктів.

Наприклад, об'єкт можна представити перерахуванням властивих йому властивостей:

ОБ'ЄКТ_ A (властивість-1, властивість-2,...., властивість-k).

Властивості об'єктів різних класів можуть "перетинатися", тобто можливі об'єкти, що мають однакові властивості:

ОБ'ЄКТ _B (...властивість-n, властивість-m,...властивість-r,...) ОБ'ЄКТ_ C (...властивість-n,.., властивість-r,...).

Одним із властивостей об'єкта є метод його обробки.

Метод - програма дій над об'єктом чи його властивостями.

Метод розглядається як програмний код, пов'язаний з певним об'єктом; здійснює перетворення властивостей, змінює поведінку об'єкта.

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

В міру розвитку систем обробки даних створюються стандартні бібліотеки методів, до складу яких включаються типізовані методи обробки об'єктів певного класу (аналог - стандартні підпрограми обробки даних при структурному підході), які можна запозичати для різних об'єктів.

Подія - зміна стану об'єкта.

Зовнішні події генеруються користувачем (наприклад, клавіатурне введення чи натискання кнопки миші, вибір пункту меню, запуск макроса ); внутрішні події генеруються системою.

Об'єкти можуть поєднуватися в класи (групи чи набори - у різних програмних системах можлива інша термінологія).

Клас - сукупність об'єктів, що характеризуються спільністю застосовуваних методів чи обробки властивостей.

Один об'єкт може виступати об'єднанням вкладених у нього по ієрархії інших об'єктів.

Існує кілька підходів до проектування програмного забезпечення, але найпоширенішими сьогодні є структурний, або функціонально-модульний, та об’єктно-орієнтований. Вони відрізняються за способом декомпозиції складних програмних систем. У першому випадку структура системи описується як ієрархічна система інформаційно пов’язаних модулів, що реалізують її функції. У другому використовується об’єктна декомпозиція, коли статична структура системи описується в термінах об’єктів і зв’язків між ними, а її поведінка — в термінах обміну повідомленнями.

Практично всі поширені методи структурного підходу ґрунтуються на таких основних принципах:

• «поділяй і владарюй»;

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

• абстрагування (виділення суттєвих аспектів системи і відкидання несуттєвих);

• несуперечливість (узгодженість елементів системи);

• структурованість даних.

Структурний підхід використовує дві групи засобів, що описують функціональну структуру системи та відношення між даними. Кожній з груп відповідають певні моделі, такі як:

• DFD — діаграма потоків даних;

• SADT (метод структурного аналізу та проектування) — моделі та функціональні діаграми;

• ERD — діаграми «сутність—зв’язок», найбільш популярні в CАSE-засобах.

На кожному етапі життєвого циклу програмного забезпечення використовуються і відповідно інтерпретуються свої діаграми.

На етапах аналізу вимог до ПЗ і відповідного визначення специфікацій використовуються SADT-моделі.

Моделі ERD використовуються для описання даних на концептуальному рівні, не залежному від засобів СКБД.

На етапі проектування використовуються моделі DFD і ERD для описання структури проектованої системи ПЗ, які можуть уточнюватись, доповнюватись новими конструкціями для представлення даних на логічному рівні.

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

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