Тема: Специфікації програмного забезпечення при структурному підході

Лекція 8.

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

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

• вимога точності означає, що специфікації повинні однозначно сприйматися як замовником, так і розробником.

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

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

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

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

Методології структурного аналізу і проектування, засновані на моделюванні потоків даних, зазвичай використовують представлення проектованого програмного забезпечення у вигляді наступних моделей [11]:

• діаграм потоків даних (DFD - Data Flow Diagrams), що описують взаємодію джерел і споживачів інформації через процеси, які повинні бути реалізовані в системі;

• діаграм «суть-зв'язок (ERD - Entity-Relationship Diagrams)», що описують бази даних системи, що розробляється;

• функціональних діаграм (методологія SADT);

• діаграм переходів станів (STD - State Transition Diagrams), що характеризують поведінка системи в часі;

• специфікацій процесів;

• словника термінів.

Взаємозв’язок елементів такої узагальненої моделі показаний на рис.8.2.

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

Взаємозв’язок елементів такої узагальненої моделі показаний на рис.8.2.

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

Незалежно від вибраної нотації специфікація процесу повинна починатися з ключового слова (наприклад @СПЕЦПРОЦ ). Необхідні вхідні і вихідні дані повинні бути специфіковані таким чином:

@ВХІД = <ім'я символу даних>

@ВИХІД = <ім'я символу даних>

@ВХІДВИХІД = <ім'я символу даних>

де < ім'я символу даних> - відповідне ім'я із словника Даних.

Ці ключові слова повинні використовуватися перед визначенням СП, наприклад

@ВХІД = СЛОВА ПАМ'ЯТІ

@ВИХІД = ЗНАЧЕННЯ, ЩО ЗБЕРІГАЮТЬСЯ

Дата добавления: 2014-12-07