vchilka.in.ua 1

Модульний контроль №1


«Технологія програмування та створення програмного продукту»

Перелік питань


  1. Класифікація програмного забезпечення.

  2. Етапи та система розробки програмного забезпечення. Види архітектури ПЗ.

  3. Послідовні моделі процесу розробки ПЗ.

  4. Ітераційні моделі процесу розробки ПЗ.

  5. Аналіз вимог до програмних продуктів. Види вимог. Аналіз вимог при об’єк­тному підході.

  6. Парадигми програмування.

  7. Структури та формати даних.

  8. Проектування ПЗ при структурному та об’єктному підходах. Мова UML.

  9. Тестування та відлагодження ПЗ. Надійність ПЗ.

  10. Програмна платформа .NET Framework та її основні складові.

  11. Загальна характеристика та можливості мови С#. Ідентифікатори у С#. Основні прості типи. Перетворення типів.

  12. Похідні типи. Структури. Масиви. Основні методи класу Array.

  13. Робота з рядками в С#. Методи класу String.

  14. Огляд і класифікація операцій у С#

  15. Умовні оператори і циклічні оператори у С#.

  16. Функції у С#. Передача параметрів у функції. Делегати.

  17. Робота з файлами у C#.

  18. Робота з часом і датою у С#.

Література

  1. Брауде Э. Технология разработки программного обеспечения. – СПб.: Питер, 2004.

  2. Гагарина Л. Г., и др. Технология разработки программного обеспечения. – М.:, ИНФРА-М, 2008.

  3. Лавріщева К. М. Програмна інженерія. – К. : Академперіодика, 2008.

  4. Лаврищева Е. М. Методы программирования. Теория, инженерия, практика. – К.: Наукова Думка, 2006.

  5. Лаврищева Е. М., Грищенко В. Н. Сборочное программирование. – К.: Наукова думка, 2009.

  6. Орлик С. Программная инженерия. Конструирование программного обеспечения, 2006.
  7. Соммервилл И. Инженерия программного обеспечения. 6 издание. М.: Вильямс, 2002.



Аналіз вимог до програмних продуктів

Результатом аналізу вимог є документ, який називається специфікацією вимог до ПЗ (SRS — Software Requirement Specification). Вимоги до ПЗ поділяють на функціональні та експлуатаційні [2].

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

  1. Опис зовнішнього інформаційного середовища, з яким буде взаємодіяти ПЗ. Мають бути описані усі ка­нали вводу-виводу та всі інформаційні об’єкти, а також зв’язки між ними.

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

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

Експлуатаційні вимоги визначають характеристики ПЗ, які виявляються у процесі його використання:

  1. правильність — функціонування у відповідності з технічним завданням; Це обов’язкова вимога для будь-якого ПЗ. На практиці мова може йти про певну ймовірність відсутності помилок;

  2. універсальність — забезпечення правильної роботи для будь-яких допустимих даних і захист від неправильних даних;

  3. надійність (завадостійкість) — забезпечення повної повторюваності результатів, тобто забезпечення їх правильності при різноманітних збоях. Для цього наприклад можуть створюватися контрольні точки, в яких проводиться збереження проміжних результатів;
  4. можливість перевірки отриманих результатів. Для потрібно проводити документальну фіксацію вхідних даних та встановлених режимів;


  5. точність результатів — забезпечення похибок не більших за задане граничне значення;

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

  7. програмна сумісність — можливість сумісної роботи з іншими програмами. Наприклад може вима­га­тися функціонування у певній ОС чи обмін даними з іншими програмами;

  8. апаратна сумісність — можливість сумісного функціонування з певними видами обладнання;

  9. ефективність — використання мінімального можливого обсягу ресурсів технічних засобів (зайнятість мікропроцесору, ОЗП, дискової пам’яті) та ОС;

  10. здатність до адаптації — можливість швидкої модифікації з метою пристосування до змінених умов функціонування;

  11. можливість паралельного використання кількома процесами. Для цього необхідно створювати копії даних для кожного процесу;

У [1] Брауде використовує інший принцип класифікації вимог: С-вимоги (вимоги користувача) та
D-вимоги (вимоги розробників ПЗ).
Вибір архітектури ПЗ

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

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

  1. програми — впорядкована послідовність формалізованих інструкцій для розв’язування задач на ЕОМ;
  2. пакети програм — кілька окремих програм, які розв’язують задачі певної прикладної області. Прик­ладом є пакет математичних програм;


  3. програмні комплекси — сукупність програм, які сумісно забезпечують розв’язання невеликого класу задач одної прикладної області. При цьому для виконання задачі програмою диспетчером послідовно викликається кілька програм;

  4. програмні системи — організований набір програм, які сумісно забезпечують розв’язання широкого класу задач.


Структури та формати даних

На етапі формування SRS ПЗ необхідно визначити структуру та формат даних, які використовуються у програмі. Структура даних — це множина елементів даних та зв’язків між ними. Розрізняють фізичну та логічну структуру даних.

Статичні структури даних являють со­бою струк­туровану множину простих типів. Роз­мір пам’яті, яка виділяється для таких даних є пос­тійним.

Напівстатичні структури даних мають змінну довжину, яка може змінюватися у певних межах, не перевищуючи граничне значення.

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