3. Системні вимоги

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

Специфікація системних вимог може будуватися на основі різних системних моделей, таких, як об'єктна модель або модель потоків даних. Різні моделі, використовувані при розробці специфікації системних вимог.

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

1. Первісна архітектура системи допомагає структурувати специфікацію вимог. Системні вимоги повинні описувати підсистеми, з яких складається розроблювальна система.

2. У більшості випадків розроблювальна система повинна взаємодіяти із уже існуючими системами. Це накладає певні обмеження на архітектуру нової системи.

3. У якості зовнішньої системної вимоги може виступати умова використання для розроблювальної системи спеціальної архітектури.

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

Щоб уникнути подібних проблем, розроблені методи опису вимог, які структурують специфікацію і зменшують розмитість визначень. Ці методи представлені в табл. 3.3. Крім цього, розроблені інші підходи, наприклад спеціальні мови опису вимог, які використовуються відносно рідко.

Таблиця 3.3. Способи запису специфікацій вимог

Структурована мова специфікацій

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

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

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

Приклад 3.8. Специфікація системної вимоги, що використовує стандартну форму

Екліпс/АРМ/Засоби/DE/RD/3.5.1

Функція. Додавання структурних елементів у схему.

Опис. Додавання структурних елементів в існуючу схему системної архітектури. Користувач вибирає тип структурного елемента і його місце розташування. Після вставки в схему структурний елемент стає виділеним (поточним структурним елементом). Користувач визначає місце розташування елемента шляхом переміщення курсору по області схеми.

Вхідні дані. Тип елемента, позиція елемента, ідентифікатор схеми.

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

Вихідні дані. Ідентифікатор схеми.

Пункт призначення. База даних проекту. Ідентифікатор схеми міститься в базу даних проекту по завершенню виконання даної функції.

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

Постумови. Схема, за винятком вставки нового структурного елемента, не змінюється.

Побічні ефекти. Немає.

Специфікація: Єкліпс/АРМ/Засоби/DE/RD/3.5.1

Стандартні форми, використовувані для специфікування функціональних вимог, повинні містити наступну інформацію.

1. Опис функції або об'єкта.

2. Опис вхідних даних і їх джерела.

3. Опис вихідних даних із вказівкою пункту їх призначення.

4. Вказівка, що необхідна для виконання функції.

5. Якщо це специфікація функції, необхідний опис попередніх умов (передумов), які повинні виконуватися перед викликом функції, і опис заключної умови (постумов), яка має бути виконане після завершення виконання функції.

6. Опис побічних ефектів (якщо вони є).

Використання структурованої мови знімає деякі проблеми, властиві специфікаціям, написаною природньою мовою, оскільки знижує “варіабельність” специфікації і більш ефективно її структурує. Разом з тим деяка “розмитість” визначень і описів у специфікації залишається. Альтернативою використанню структурованої природньої мови може служити спеціальна мова опису специфікацій, яка повністю знімає проблему нечіткості опису вимог. Але з іншого боку, неспеціаліст знайде таку специфікацію важкою для читання і розуміння.

Створення специфікацій за допомогою PDL

Для зменшення властивої природній мові нечіткості понять при описі системних вимог використовується спеціальна мова опису програм (program description language ‒ PDL). Ця мова подібна таким мовам програмування, як Java і Ada, але більш абстрактна. Перевагою застосування PDL для створення специфікації є те, що в такій специфікації можна перевірити синтаксис і семантику існуючими програмними засобами. Ці перевірки дозволяють вилучити помилки і непогодженість в описі вимог.

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

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

2. Якщо необхідно специфікувати апаратні або програмні інтерфейси, тому що практично у всіх специфікаціях системних вимог доводиться описувати інтерфейси.

Лістинг 3.1. Специфікація системи керування банкоматами

class ATM {

// декларативна частина

public static void main (String args[]) throws Invalidcard{

try {

thiscard.read ();

//може породити виняткову ситуацію Invalidcard

pin = Keypad.readpin ();

attempts = 1;

while (!thiscard.pin.eguals (pin) & attempts < 4)

{ pin = Keypad.readpin();

Attempts = attempts + 1;

}

if ( !thiscard.pin.eguals (pin))

throws new Invalidcard ("Неправильний PIN-код") ;

thisbalance = thiscard.getbalance();

do ( Screen.promt ("Будь ласка, виберіть сервіс");

service = Screen.touchkey ();

switch (service) {

САSЕ Services.withdrawalwithreceipt:

receiptrequired = true;

САSЕ Services.withdrawalnoreceipt:

amount = Keypad.readamount ();

if (amount > thisbalance)

{ Screen.printmsg ("Рахунок перевищений");

break;

}

Dispenser.deliver (amount);

newbalance = thisbalance - amount;

if (receiptrequired)

Receipt.print (amount, newbalance);

break;

//далі опис інших сервісів

default: break ;

}

}

while (service != Services.quit);

thiscard.returntouser ("Будь ласка, заберіть картку");

}

catch (Invalidcard e )

{ Screen.printmsg ("Недійсна картка або PIN-код") ;

}

//далі обробка інших виключень

}//main ()

}//ATM

Разом з тим підхід до побудови специфікацій, заснований на PDL, має свої недоліки.

1. PDL, використовуваний для написання специфікації, може не мати достатніх засобів для опису всіх системних функцій.

2. Специфікації, створені за допомогою PDL, зрозумілі тільки людям, що мають певні знання мов програмування.

3. Системна архітектура, отримана на основі такої специфікації, не є системною моделлю, яка допомогла б користувачеві розібратися в структурі системи.

Найбільш ефективним способом розробки специфікацій є комбінація підходу, заснованого на PDL, з використанням структурованої природньої мови. У цьому випадку формалізовані записи природньою мовою використовуються для опису системи в цілому, a PDL ‒ для опису послідовностей керуючих дій або для деталізованого опису інтерфейсів.

Специфікація інтерфейсів

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

Розрізняють три типи спеціфіцікуємих інтерфейсів.

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

2. Структури (інтерфейсні формати) даних, які пересилаються від однієї підсистеми до іншої. У цьому випадку може використовуватися PDL, заснований мовою програмування Java, який дозволяє описати класи даних з відповідними полями, що формують структуру даних.

3. Спеціальні представлення даних, наприклад у вигляді впорядкованої послідовності двійкових розрядів. Мова Java не підтримує такі детальні описи даних не рекомендується в такому разі використовувати PDL, заснований мовою Java.

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

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

Лістинг 3.2. Опис інтерфейсу сервера друку за допомогою PDL

interface Printserver {

// визначення абстрактного сервера друку

// потрібно: інтерфейс Printer, інтерфейс Printdoc

// надає функції: initialize (ініціалізація),

// print (друк),

// displayprintqueue (відображення черги на друк),

// cancelprintjob (видалення файлу із черги),

// switchprinter (перемикання між принтерами)

void initialize (Printer р);

ЗМІСТ 3

Опис навчальної дисципліни “Технологія проектування програмних систем" ………… 3

4 3

Тематика і зміст лекцій .………………………………………………………….………….. 3

5 3

Практичні заняття по дисципліні "Технологія проектування програмних систем" …….. 3

6 3

7 3

8 3

9 3

30 3

48 3

61 3

74 3

88 3

1.  Моделі процесу створення ПЗ. Каскадна модель. Еволюційна модель розробки. Формальна розробка систем. Розробка ПЗ на основі раніше створених компонентів 5

Вимоги до програмного забезпечення 5

Прототипування програмних систем 5

Формальні специфікації ПЗ 5

Проектування систем реального часу 6

Усього годин 6

3.  Вимоги до програмного забезпечення 8

5.  Прототипування програмних систем 8

6.  Формальні специфікації ПЗ 8

8.  Проектування систем реального часу 8

1.Моделі процесу створення ПЗ 10

Каскадна модель 10

2. Ітераційні моделі розробки ПЗ 15

Програмування і налагодження 21

5.Атестація програмних систем 22

6.   Еволюція програмних систем 24

7.   Автоматизовані засоби розробки ПЗ 25

1.Функціональні і нефункціональні вимоги 31

Приклад (3.1.) нефункціональних вимог 34

Вимоги до продукту 34

Організаційні вимоги 34

Зовнішні вимоги 34

Приклад 3.2. Системні цілі і перевірка вимог. Системна мета 34

Нефункціональна вимога, що перевіряється 34

Приклад 3.3. Приклад вимог предметної області 36

2.  Користувацькі вимоги 36

Приклад 3.4. Вимога до бази даних для середовища програмування Ada 36

Приклад 3.5. Приклад користувацької вимоги 37

Приклад 3.6. Опис засобу відображення сітки 37

Приклад 3.7. Користувацька вимога по створенню структурних елементів схеми 38

1.Додавання структурних елементів у схему 38

2.Редактор повинен мати засіб, що надає користувачеві можливість додавати в схему нові структурні елементи обраного типу 38

3.  Системні вимоги 38

Приклад 3.8. Специфікація системної вимоги, що використовує стандартну форму 40

Екліпс/АРМ/Засоби/DE/RD/3.5.1 40

Лістинг 3.1. Специфікація системи керування банкоматами 41

Специфікація інтерфейсів 42

42

Лістинг 3.2. Опис інтерфейсу сервера друку за допомогою PDL 42

4.  Документування системних вимог 45

1.   Прототипування в процесі розробки ПЗ 50

55

2.   Технології швидкого прототипування 55

2.  Специфицирование інтерфейсів 65

1.   Проектування систем 76

4.   Системи збору даних 85

void switchprinter (Printer printrinter p2, Printdoc d);

}//Printserver

Специфікація, наведена в лістингу 3.2 ‒ абстрактна модель сервера друку без деталізації інтерфейсних частковостей. Інтерфейсні функції можна описати за допомогою структурованої природньої мови (як показано в прикладі 3.6), за допомогою PDL, заснованого мовою програмування Java (лістинг 3.1), або за допомогою формальних нотацій.