2012_Посібник_з_дисципліни_ТКП
.pdfТаблиця 2.1 – Опис типів прецедентів
ТИП |
Рівень |
Назва виду |
Джерела |
Назва документа |
Порядок |
Вид тесту |
Відповідальний за |
|
|
вимог |
|
|
кількості |
|
створення/контроль |
|
|
|
|
|
вимог |
|
реалізації |
|
|
|
|
|
|
|
|
Чорний |
Підприємство/ |
Бізнес |
Менеджер |
Обгрунтування потреби |
5 |
Досвідно- |
Менеджер проекту |
ящик |
ринок |
потреби |
компанії, Ринок |
(Business Case) |
|
промислова |
|
|
|
|
|
експлуатація |
|
||
|
|
Business |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Needs |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Замовник |
Бізнес- |
Замовник, |
Концепція |
25 |
Пакети |
Бізнес-аналітик, |
|
|
вимоги |
Експерт |
(Vision) |
|
приймальних |
Менеджер продукту |
|
|
|
предметної |
|
тестів «Показ» |
|
|
|
|
Властивості |
|
|
|
||
|
|
області, |
|
|
|
|
|
|
|
продукту |
|
|
|
|
|
|
|
Маркетолог |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Користувач |
Вимоги |
Користувач |
Вимоги до ПО |
100 |
Приймальні |
Системний аналітик |
|
|
користувача |
|
(Software Requirements |
|
тести |
|
|
|
|
|
|
(Acceptance |
|
|
|
|
|
|
Specification):Прецеденти, неф |
|
|
|
|
|
|
|
|
Test) |
|
|
|
|
|
|
вимоги |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Білий |
Система |
Вимоги до |
Стандрати, |
Документ архітектури(Software |
150 |
Системні тести |
Архітектор |
ящик |
|
системи |
Архітектурні |
Architecture Document): рівні, |
|
(System Test) |
|
|
|
|
шаблони |
пакети, зовнішні інтерфейси. |
|
|
|
|
|
|
|
|
|
|
|
|
Підсистема |
Вимоги до |
Шаблони |
Модель проектування (Design |
1000 |
Інтерграційні |
Проектувальник |
|
|
підсистеми |
проектування |
model):компоненти, класи, |
|
тести |
|
|
|
|
|
інтерфейси |
|
()Integration |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tests) |
|
|
|
|
|
|
|
|
|
|
Модуль |
Вимоги до |
Згода про |
Специфікація модуля: методи, |
2000 |
Модульний |
Програміст |
|
|
модуля |
кодування, |
сигнатури |
|
тест(Unit Test) |
|
|
|
|
Алгоритми |
|
|
|
|
|
|
|
обчислення |
|
|
|
|
|
|
|
|
|
|
|
|
Елементарний бізнес-процес (ЕВР) - завдання, що виконується однією людиною, в одному місці, у відповідь на деяку бізнес-подію, що додає вимірюване бізнес-значення і переводить дані в якийсь стійкий стан.
Алгоритм виділення ЕВР:
1.Визначте рамки системи.
2.Ідентифікуйте основних виконавців.
3.Для кожного виконавця визначте його завдання. Складіть ієрархію відповідно до рекомендацій по виділенню ЕВР.
4.Визначте прецеденти, що задовольняють потреби кожного виконавця, і надайте їм імена відповідно до завдань.
5.Питання, що задаються при визначенні виконавців:
а. Хто запускає і вимикає систему? б. Хто є системним адміністратором?
в. Хто здійснює управління користувачами і безпекою?
г. Чи відноситься час до числа виконавців, іншими словами, чи повинна система виконувати будь-які дії у відповідь на події часу?
д. Хто контролює діяльність і продуктивність системи, оновлення ПЗ, аналіз ...
Таблиця 2.2 - Приклад визначення завдань
Виконавець |
Завдання |
|
|
Касир |
Оформляє продаж |
|
Оформляє кредити |
|
Виконує повернення товару |
|
Реєструє виручку |
|
|
Системний адміністратор |
Додає користувачів |
|
Змінює параметри користувачів |
|
Видаляє користувачів |
|
Управляє безпекою |
|
Управляє системними таблицями |
|
|
Стилі опису прецедентів
Базовий. Передбачає виклад на рівні намірів користувача та обов'язків системи, а не на рівні їхніх конкретних дій. При такому стилі опису не потрібно заглиблюватися в деталі технології і механізму реалізації, особливо при розгляді питань, пов'язаних з інтерфейсом користувача.
Конкретний. При такому стилі опису проектні рішення, пов'язані з інтерфейсу. У тексті опису можуть, наприклад, навіть міститися копії екранів, описуватися елементи управління та інші елементи призначеного для користувача інтерфейсу.
Ступінь формалізації опису прецедентів
Стиснутий - анотація у вигляді одного абзацу. Зазвичай вона описує тільки головний успішний сценарій.
Вільний - неформальний стиль опису. Опис прецеденту займає кілька абзаців і охоплює різні сценарії.
Розгорнутий - найбільш детальний стиль опису. При такому підході детально описуються всі кроки і варіанти розвитку сценарію, а також передумови і результати.
33
Передумови і постумови
Передумови (preconditions) - це перелік передумов, які завжди повинні виконуватися до початку сценарію прецеденту.
Постумови (postconditions). Описують, які умови обов'язково повинні виконуватися в разі успішного завершення сценарію.
Методи опису прецедентів а. В одну колонку.
б. У кілька колонок.
Підхід «під управлінням прецедентів» (use-case driven development)
Вимоги в основному формулюються при описі прецедентів.
Прецеденти - важливий етап ітеративного планування. На кожній ітерації реалізуються деякі сценарії або цілі прецеденти. Описи прецедентів вносять істотний внесок в оцінювання результату.
Розробка програми полягає в реалізації прецедентів. Тобто група розробників продумує способи взаємодії об'єктів або архітектуру підсистем для реалізації прецедентів.
Діаграми послідовності
Для певного сценарію прецеденту показує генеруються зовнішніми виконавцями події, їх порядок, а також події, що генеруються всередині самої системи.
При цьому всі системи розглядаються як "чорний ящик".
Призначення даної діаграми - відображення подій, що передаються виконавцями системі через її кордони. Сценарій прецеденту - це його окремий випадок чи реальний шлях його реалізації.
Діаграма послідовності будується на підставі опису прецеденту
|
34 |
|
|
SequenceDiagram_1 |
|
|
|
Пристрій зчитування карточки з банкомату |
Екран банкомату |
Рахунок клієнта |
Касовий апарат |
Клієнт |
|
|
|
Отримання карточки пристроєм |
|
|
|
Читанння інформації про карточку |
|
|
|
Ініціалізація екрана |
|
|
|
Запит PIN-коду |
|
|
|
Введення PIN-коду |
|
|
|
|
|
Відкриття рахунку |
|
|
Перевірка PIN-коду |
|
|
Запит на проведення операції |
|
|
|
Вибір операції зняття грошей() |
|
|
|
Запит про суму зняття грошей |
|
|
|
Введення суми (100грн) |
|
|
|
|
Зняття грошей з рахунку (100грн) |
|
|
|
|
Перевірка суми (100грн) |
|
|
|
Зняття суми з рахунку(100грн) |
|
|
|
Видача готівки(100грн) |
|
|
|
Запит на видачу чека |
|
Запит на видачу чека |
|
|
|
Вибір операції "Видача чека" |
|
|
|
|
|
Видача чека |
|
|
Видача карточку клієнту |
|
|
Рисунок 2.2 – Приклад діаграми послідовності |
|
||
Питання для самоперевірки
1.Опишіть прецеденти типу «чорний ящик».
2.Алгоритми виділення елементарних бізнес-процесів (ЕВР).
3.Що таке передумова та постумова ?
4.З якою метою здійснюють перелік передумов та постумов?
5.Яке основне призначення діаграми послідовності ?
Література: [2, с.73-97];
Завдання на СРС: [3, с. 183-195].
|
|
|
35 |
|
|
2.2 |
Діаграми послідовності. Діаграми комунікації. |
|
|
||
|
Структура теми : |
|
|
|
|
|
– |
Діаграми послідовності. |
|
|
|
|
– |
Діаграми комунікації. |
|
|
|
|
Діаграма послідовності |
|
|
|
|
SequenceDiagram_1 |
|
|
|
||
|
|
Пристрій зчитування карточки з банкомату |
Екран банкомату |
Рахунок клієнта |
Касовий апарат |
|
Клієнт |
|
|
|
|
|
|
Отримання карточки пристроєм |
|
|
|
|
|
Читанння інформації про карточку |
|
|
|
|
|
Ініціалізація екрана |
|
|
|
|
|
Запит PIN-коду |
|
|
|
|
|
Введення PIN-коду |
|
|
|
|
|
|
Відкриття рахунку |
|
|
|
|
|
Перевірка PIN-коду |
|
|
|
|
Запит на проведення операції |
|
|
|
|
|
Вибір операції зняття грошей() |
|
|
|
|
|
Запит про суму зняття грошей |
|
|
|
|
|
Введення суми (100грн) |
|
|
|
|
|
|
Зняття грошей з рахунку (100грн) |
|
|
|
|
|
|
Перевірка суми (100грн) |
|
|
|
|
|
Зняття суми з рахунку(100грн) |
|
|
|
|
|
Видача готівки(100грн) |
|
|
|
|
Запит на видачу чека |
|
|
|
|
Запит на видачу чека |
|
|
|
|
|
Вибір операції "Видача чека" |
|
|
|
|
|
|
Видача чека |
|
|
|
|
|
Видача карточку клієнту |
|
|
|
|
Рисунок 2.3 - Приклад діаграми послідовності |
|
||
Діаграми комунікації.
Діаграми комунікацій (до UML 1.4 називалася Collaboration diagrams - діаграма кооперації) акцентує увагу на організації об'єктів, що приймають участь у взаємодії.
36
Рисунок 2.4 - Діаграми послідовності
Рисунок 2.5 - Діаграма комунікації
Відмінності від діаграми послідовності:
Перше - це показ шляху. Для опису зв'язку одного об'єкта з іншим є можливість приєднати стереотип шляху.
Порядковий номер повідомлення. Для позначення вкладеності використовується десяткова нотація Дьюї:
Нотація Дьюї:
1 - перше повідомлення;
1.1 - перше повідомлення, вкладене в повідомлення 1;
1.2-друге повідомлення, вкладене в повідомлення 1 і т.д.). Рівень вкладеності не обмежений. Для кожного зв'язку можна показати кілька повідомлень (ймовірно, що посилаються різними відправниками), і кожне з них повинно мати унікальний порядковий номер.
37
Рисунок 2.6 - Діаграма комунікації
Рисунок 2.7 - Діаграма послідовності
38
Рисунок 2.8 - Елементи діаграми комунікації у CASE засобі Enterprise Architect
Питання для самоперевірки
1.Які основні елементи діаграми послідовності ?
2.Які основні елементи діаграми комунікації?
3.Що спільного між діаграмою послідовності та комунікації?
4.Які основні відмінності між діаграмою послідовності та діаграмою комунікації?
Література: [2, с.98-146]; [3, с.194-231];
Література на СРС: [9, с. 262-299].
39
2.3 Модель предметної області
Структура теми :
–Представлення моделі предметної області.
–Концептуальні класи.
–Стратегії ідентифікації концептуальних класів
Представлення моделі предметної області
Основна ідея моделі предметної області:
1.Модель предметної області являє класи понять реального світу, а не програмні компоненти.
2.Це не набір діаграм, що описують програмні класи або програмні об'єкти з їх обов'язками
3.Модель предметної області - це візуальне подання концептуальних класів або об'єктів реального світу в термінах предметної області.
4.Такі моделі називають також концептуальними моделями об'єктів предметної області або об'єктними моделями аналізу
Мовою UML модель предметної області представляється у вигляді набору діаграм класів, на яких не визначені жодні операції. Модель предметної області може відображати наступне:
1.Об'єкти предметної області або концептуальні класи.
2.Асоціацію між концептуальними класами.
3.Атрибути концептуальних класів.
Рисунок 2.9 - Модель предметної області
Модель предметної області ілюструє концептуальні класи або словник предметної області.
40
Неформально, концептуальний клас - це уявлення ідеї або об'єкта.
Якщо говорити більш строго, то концептуальний клас можна розглядати в термінах символів, змісту та розширення.
Символи (symbol) - слова або образи, що представляють концептуальний клас. Зміст (intension) - визначення концептуального класу.
Розширення (extension) - набір прикладів, до яких застосовується концептуальний
клас.
Рисунок 2.10 - Елементи концептуальних класів
Моделі предметної області та декомпозиція
Програмні системи можуть бути дуже складними, тому декомпозиція (за принципом ''розділяй і володарюй ") - це загальна стратегія боротьби зі складністю проблеми за рахунок її поділу на дрібні складові частини.
Знову про відмінність від структурного підходу
При структурному підході до проектування систем завдання розбивається на процеси або функції. При об'єктно-орієнтованому - на основні поняття або сутності предметної області.
Не слід виключати з розгляду концептуальні класи тільки на тій підставі, що з аналізу вимог не слід очевидна необхідність їх запам'ятовування.
Цей критерій часто застосовується при розробці реляційних баз даних, проте не годиться для створення моделей предметної області) або концептуальний клас не має атрибутів.