Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Lekcii_OPI_2sem.doc
Скачиваний:
153
Добавлен:
23.02.2016
Размер:
3.72 Mб
Скачать

3.6. Аналіз вимог і визначення специфікацій при об’єктному підході

При об’єктному підході до програмування моделі розроблюваної системи ґрунтуються на предметах і явищах навколишнього світу.

Модель – спрощене представлення реальності. З точки зору програмування модель – це креслення системи. Моделювання необхідне для наступних задач [4]:

  1. візуалізація системи;

  2. визначення її структури і поведінки;

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

  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).

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

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]