- •3. Аналіз вимог і визначення специфікацій програмного забезпечення
- •3.1. Визначення вимог до програмних продуктів
- •3.1.1. Функціональні вимоги
- •3.1.2. Експлуатаційні вимоги.
- •3.2. Вибір архітектури програмного забезпечення
- •3.3. Структура і формат даних. Статичні, напівстатичні і динамічні структури
- •3.3.1. Класифікація структур даних
- •3.3.2. Прості структури даних
- •3.3.3. Статичні структури даних
- •3.3.4. Напівстатичні структури даних
- •3.3.5. Динамічні структури даних
- •3.4. Модульне програмування
- •3.4.1. Поняття модуля
- •3.4.2. Основні характеристики програмного модуля
- •3.4.3. Модульна структура програмних модулів
- •3.4.4. Методи розробки при модульному програмуванні
- •Ціленаправлена конструктивна реалізація
- •3.5. Аналіз вимог і визначення специфікацій при структурному підході
- •3.5.1. Специфікації процесів
- •3.5.2. Словник термінів
- •3.5.4. Функціональні діаграми
- •3.5.5. Діаграми потоків даних (dfd)
- •3.5.6. Діаграма сутність-зв’язок
- •3.6. Аналіз вимог і визначення специфікацій при об’єктному підході
- •3.6.1. Деякі теоретичні відомості про uml
- •3.6.2. Визначення прецедентів (варіантів використання)
- •3.6.3. Побудова концептуальної моделі предметної області
3.6. Аналіз вимог і визначення специфікацій при об’єктному підході
При об’єктному підході до програмування моделі розроблюваної системи ґрунтуються на предметах і явищах навколишнього світу.
Модель – спрощене представлення реальності. З точки зору програмування модель – це креслення системи. Моделювання необхідне для наступних задач [4]:
візуалізація системи;
визначення її структури і поведінки;
отримання шаблону, який потім дозволить сконструювати систему;
документування прийнятих рішень, використовуючи отримані моделі.
Для розв’язання цих задач при описанні поведінки програмного забезпечення в наш час використовується UML (Unified Modeling Language) – уніфікована мова моделювання.
3.6.1. Деякі теоретичні відомості про uml
В основі об’єктного підходу до розробки програмного забезпечення лежить об’єктно декомпозиція, тобто представлення розроблюваного програмного забезпечення у вигляді сукупності об’єктів, в процесі взаємодії яких через передачу повідомлень відбувається виконання необхідних функцій.
Для створення моделей аналізу і проектування об’єктно-орієнтованих програмних систем використовують мови візуального моделювання, самою поширеною з яких у наш час є UML.
Специфікація розроблюваного програмного забезпечення при використанні UML об’єднує декілька моделей: логічну, використання, реалізації, процесів, розгортання [1].
Модель використання містить описання функцій програмного забезпечення з точки зору користувача.
Логічна модель описує ключові поняття програмного забезпечення (класи, інтерфейси і т.д.), тобто засоби, які забезпечують його функціональність.
Модель реалізації визначає реальну організацію програмних модулів у середовищі розробки.
Модель процесів визначає організацію обчислень і дозволяє оцінити робото здатність, масштабованість і надійність програмного забезпечення.
Модель розгортання показує, яким чином програмні компоненти розміщуються на конкретному обладнанні.
Всі разом вказані моделі, кожна з яких характеризує визначену сторону проектованого продукту, складають повну модель розроблюваного програмного забезпечення.
Всього UML пропонує дев’ять діаграм, які доповнюють одна одну і входять в різні моделі:
діаграми варіантів використання;
діаграми класів;
діаграми пакетів;
діаграми послідовності дій;
діаграми кооперації;
діаграми діяльності;
діаграми станів об’єктів;
діаграми компонентів;
діаграми розміщення.
На етапі аналізу постановки задачі і вимог до системи використовують діаграми прецедентів, діаграми діяльностей для розшифровки вмісту прецедентів, діаграми станів для моделювання поведінки об’єктів зі складним станом, діаграми класів для виділення концептуальних сутностей предметної області задачі і діаграми послідовності дій.
3.6.2. Визначення прецедентів (варіантів використання)
Розробку специфікацій програмного забезпечення починають з аналізу вимог до функціональності, вказаних в технічному завданні. У процесі аналізу виявляють зовнішніх користувачів розроблюваного програмного забезпечення і перелік основних аспектів його поведінки в процесі взаємодії з конкретними користувачами.
Прецеденти (варіанти використання – Use Cases) – це детальні процедурні описання варіантів використання системи всіма зацікавленими особами, а також зовнішніми системами, тобто всі, хто (або що) може розглядатись як актори (actors) – дійові особи. Це свого роду алгоритми роботи з системою з точки зору зовнішнього світу. Прецеденти є основою функціональних вимог до системи, дозволяє описувати межі проектованої системи, її інтерфейс, а потім стають основою для тестування системи замовником.
У системі від цілі виконання конкретної задачі розрізняють наступні варіанти використання [1]:
основні, забезпечують виконання функцій системи;
допоміжні, забезпечують виконання налаштувань системи та її обслуговування;
додаткові, служать для зручності користувача (реалізуються тільки в тому випадку, якщо не вимагають серйозних затрат будь-яких ресурсів ні при розробці, ні при експлуатації).
Приклад 3.3. Аналіз функціональних вимог і користувачів системи тестування (модуль навчальної системи).
Система тестування перш за все потрібна наступним зацікавленим особам:
студенту;
хто складає тести (викладачу);
викладачу, який приймає іспит;
співробітнику деканату, який здійснює контроль за успішністю;
адміністратору мережі і баз даних навчального закладу.
На початковому етапі створення системи ми можемо обмежитись двома важливими для нас ролями діючих осіб:
студент (той хто тестується);
адміністратор (викладач, укладач тестів);
Відповідно основні прецеденти (варіанти використання) для нашої системи наступні:
Прецедент для студента:
П1 – пройти тестування.
Прецеденти для адміністратора:
П2 – створити/змінити тест;
П3 – подивитись результати тестування;
П4 – добавити/змінити користувачів та ін.
Варіант використання можна описати коротко чи детально. Коротка форма описання містить назву варіанта використання, його ціль, дійових осіб, тип варіанту використання (основний, другорядний чи додатковий) і його коротке описання [1].
Коротке описання варіанту використання для даного прикладу:
Назва варіанту |
Проходження тесту |
Ціль |
Отримання оцінки |
Дійові особи (актори) |
Студент |
Коротке описання |
Реєстрація студента, запуск тесту, вибір відповіді з декількох запропонованих чи введення відповіді, завершення тесту, отримання оцінки |
Тип варіанту |
Основний |
Детальне описання варіанту використання Проходження тесту
Дії користувача |
Реакція системи |
1. Студент вводить свої дані (ФІО, Група), тобто реєструється в системі |
2. система створює на диску файл з результатом тестування і пропонує вибрати тест |
3. Студент вибирає тест |
4. Система запускає тест |
5. Студент послідовно відповідає на запитання |
6. Система реєструє правильні і неправильні відповіді |
7. Студент завершує тестування |
8. Система підраховує процент правильних відповідей |
9. Студент очікує результат |
10. Система демонструє результат і пропонує зберегти його |
11. Студент вирішує, зберегти результат чи ні |
12. Якщо вибрано збереження, система записує результат у файл |
13. Студент завершує роботу |
14. Система завершує роботу |
Для більшої наочності використовують діаграми варіантів використання
Діаграми варіантів використання
На рис. 3.38 показано умовні позначення, які використовують при зображенні діаграм прецедентів [48].
Діаграма прецедентів для вищеописаного прикладу буде мати вигляд (рис. 3.39).
Відповідно, всі варіанти використання визначити, як правило, не вдається: нові варіанти фіксують постійно, навіть в процесі експлуатації. Але чим більше варіантів виявлено в процесі уточнення специфікацій, тим краще, так як при цьому отримують більш точну модель предметної області, що зменшує ймовірність її перегляду при додаванні функцій.