Т Е Х Н О Л О Г І Ї 4 страница

Уніфікований процес був розроблений тими ж фахівцями, які створили UML: Греді Бучем (Grady Booch), Айвором Джекобсоном (Ivar Jacobson) і Джеймсом Рембо (James Rumbaugh). Іноді цю концепцію називають раціональним уніфікованим процесом (Rational Unified Process, за назвою компанії, в якій його було розроблено) або уніфікованим процесом розроблення ПЗ.

Уніфікований процес розроблення ПЗ поділяється на чотири етапи: початок; удосконалення; побудова; передача.

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

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

Рис. 24.2. Етапи уніфікованого процесу розроблення ПЗ

Кожна ітерація включає свою власну послідовність етапів аналізу, планування, реалізації і тестування. Ітерації можуть повторюватися кілька разів. Метою ітерації є створення працюючої частини системи.

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

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

Етап удосконалення зазвичай за основу бере технологію варіантів використання (use case). Це відправна точка детального розроблення системи. З цієї причини уніфікований процес розроблення ПЗ називають прецедентним. У наступному підрозділі ми розглянемо цю технологію, а потім застосуємо її до проекту, узятого нами як приклад.

24.2. Моделювання варіантів використання

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

У моделюванні варіантів використання застосовуються дві основні сутності: діючі суб'єкти і варіанти використання. Давайте з'ясуємо, хто є хто.

24.2.1. Поняття про діючі суб'єкти

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

Насправді більш відповідною назвою, ніж "діючий суб'єкт" або "актор", є, можливо, "роль". Тому що один користувач може в різних життєвих ситуаціях грати різні ролі. Приватний підприємець Петренко може з ранку бути продавцем у своєму маленькому магазині, а увечері – бухгалтером, що вводить дані про продаж за день. Навпаки, один діючий суб'єкт може представлятися різними людьми. Протягом робочого дня Василь і Василина Петренки є продавцями в своєму магазинчику.

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

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

● чи вводять вони дані;

● чи чекають приходу інформації від системи;

● чи допомагають іншим діючим суб'єктам.

24.2.2. Поняття про варіанти використання

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

У більшості ситуацій, як ми вже сказали раніше, варіанти використання генеруються діючими суб'єктами, але іноді їх ініціює сама система. Наприклад, комп'ютерна система ЛьвівЕнергоЗбуту може прислати на Вашу адресу нагадування про те, що пора заплатити за споживання електроенергії. Електронна система (після вбудовування її у Ваш "запорожець") може повідомити про перегрів двигуна, наприклад, запаленням контрольної лампи на панелі приладів.

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

24.2.3. Поняття про сценарії

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

● книга є наявною на складі; комп'ютер виводить на екран номер полиці, на якій вона стоїть;

● книга відсутня, але система дає клієнту можливість замовити її з видавництва;

● навчального посібника не тільки немає на складі, її немає взагалі. Система інформує клієнта про те, що йому не повезло.

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

24.2.4. Застосування діаграм варіантів використання

За допомогою UML можна будувати діаграми варіантів використання. Діючі суб'єкти представляються чоловічками, варіанти використання – еліпсами. Прямокутна рамка оточує всі варіанти використання, залишаючи за своїми межами діючих суб'єктів. Цей прямокутник називається межею системи. Те, що знаходиться всередині, – програмне забезпечення, яке розробник намагається створити. На рис. 24.3 показана діаграма варіантів використання для комп'ютерної системи книжкового магазину.

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

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

Рис. 24.3. Діаграма варіантів використання для книжкового магазина

24.2.5. Описи варіантів використання

На діаграмі варіантів використання немає місця для розміщення детального опису усіх варіантів використання, тому доводиться виносити описи за її межі. Для створення цих описів можна використовувати різні рівні формалізації, залежно від масштабів проекту і принципів, якими керуються розробники. У більшості випадків потрібен детальний опис усіх сценаріїв у варіанті використання. Простою реалізацією опису діаграми варіантів використання є просто один-два абзаци тексту. Іноді використовується таблиця, що складається з двох колонок: діяльність діючого суб'єкта і реакція на неї системи. Більш формалізований варіант може включати такі деталі, як передумову, умову поста, детальний опис послідовності кроків. Діаграма UML, що називається діаграмою дій, яка є не що інше як різновидом блок-схеми, іноді використовується якраз для того, щоб графічно зображати послідовність кроків у варіанті використання.

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

24.2.6. Перехід від варіантів використання до класів

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

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

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

Діаграму класів UML (вона обговорювалася в попередніх розділах) можна використовувати для того, щоб показати класи і їх взаємостосунки. Варіант використання реалізується послідовністю повідомлень, що посилаються одними об'єктами іншим. Можна використовувати ще одну діаграму UML, що називається діаграмою взаємодії, для детальнішого представлення цих послідовностей. Насправді для кожного сценарію варіанту використання застосовується своя діаграма взаємодії. У подальших підрозділах ми розглянемо приклади діаграм послідовностей, що є різновидом діаграми взаємодій.

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

24.3. Предметна область програмування

Програма, яку ми створюватимемо в нашому прикладі, називається landlord – ДОМОВЛАСНИК. Ви можете поважати або не поважати свого домовласника, але необхідно цілком уявляти собі ті дані, з якими йому доводиться працювати: плата за житло і витрати. Ось такий нехитрий бізнес. Його ми і описуватимемо в нашій програмі.

Уявіть собі, що Ви є незалежним експертом з ведення домашнього господарства і з мови програмування C++, і до Вас зайшов замовник на ім'я Степан Полатайко. Полатайко – дрібний власник, у його веденні знаходиться будівля по вул. Левандівка, що складається з 12 кімнат, які він здає в оренду студентам. Він хоче, щоб Ви написали програму, яка спростила б його нелегку працю з реєстрації даних і друкування звітів про свою фінансову діяльність. Якщо Ви зможете домовитися із Степаном Полатайком про ціну, терміни і загальне призначення програми, то можете вважати, що Ви задіяні до процесу розроблення ПЗ.

24.3.1. Рукописні форми

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

● перелік мешканців;

● доходи від оренди;

● витрати;

● річний звіт.

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

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

Табл. 24.1. Місячний дохід від оренди приміщень, грн.

Номер кімнати	Січень	Лютий	Березень	Квітень	Травень	Червень	Липень	Серпень

У таблиці Поточні витрати записано обов'язкові та поточні платежі. Вона нагадує чекову книжку і містить такі стовпці: дата, отримувач (компанія або користувач, на чиє ім'я виписується чек) і сума платежу. Окрім того, є стовпець, в який Степан Полатайко вносить види або категорії платежів: Сплата за заставу, ремонт, комунальні послуги, податки, страховка і т.д. Результати поточних витрат показано в табл. 24.2.

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

Табл. 24.2. Поточні витрати

Дата	Отримувач	Сума	Категорія
1/3	Перший Megabank|	5 187.30	Застава
1/8	Міська Вода	963.10	Користь
1/9	Стійка Держава	4 840.00	Страхування
1/15	P.G. & E.	727.23	Користь
1/22	Технічні Засоби Сема	54.81	Постачання
1/25	Ерні Glotz|	150.00	Ремонти
2/3	Перший Megabank|	5 187.30	Застава
2/7	Міська Вода	845.93	Користь
2/15	P.G. & E.	754.20	Користь
2/18	Plotx| & Skeems|	1 200.00	Юридичні грошові збори
3/2	Перший Megabank|	5 187.30	Застава
3/7	Міська Вода	890.27	Користь
3/10	Країна Springfield	9 427.00	Властивість Texes|
3/14	P.G. & E.	778.38	Користь
3/20	Кур'єр Gotham|	26.40	Рекламування
3/25	Ерні Glotz|	450.00	Ремонти
3/27	Живопис вищої Крапки	600.00	Обслуговування
4/3	Перший Megabank|	5 187.30	Застава

Табл. 24.3. Річний звіт

	ПРИБУТОК
	Орендна плата	102 264.00
	ПОВНИЙ ПРИБУТОК	102 264.00
	ВИТРАТИ
	Застава	62 247.60
	Податки на нерухоме майно	9 427,00
	Страхування	4 840.00
	Користь	18 326,76
	Постачання	1 129,23
	Ремонти	4 274.50
	Обслуговування	2 609.42
	Юридичні грошові збори	1 200,00
	Створення штучного ландшафту	900.00
	Рекламування	79,64
	ЗАГАЛЬНІ ВИТРАТИ	105 034,15
	ЧИСТИЙ ДОХІД АБО (ВТРАТА)	(2 700.15)

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

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

24.3.2. Прийняття допущень і спрощень

Звичайно, ми вже зробили декілька допущень і спрощень. Є ще велика кількість даних, пов'язаних з веденням справ зі здачі в оренду приміщень, таких, як застава за збиток, амортизація, іпотечна вигода, доходи від запізнілих внесків (з нарахуванням пені) і прокату пральних машин. Але під час розгляду даного прикладу ми не вдаватимемося в ці подробиці, тобто приймемо деякі допущення і спрощення.

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

24.4. Програма landlord: етап удосконалення

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

24.4.1. Встановлення діючих суб'єктів

Спочатку потрібно визначити, хто буде діючими суб'єктами? Хто вводитиме інформацію? Хто запрошуватиме? Чи буде хто-небудь ще взаємодіяти з програмою? Чи буде сама програма взаємодіяти з іншими?

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

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

24.4.2. З'ясування варіантів використання

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

● почати роботу з програмою;

● додати нового мешканця в перелік;

● ввести значення орендної плати в таблицю доходів від оренди;

● ввести значення в таблицю витрат;

● вивести перелік мешканців;

● вивести таблицю доходів від оренди;

● вивести таблицю витрат;

● вивести річний звіт.

Таким чином, діаграму варіантів використання, яка отримується внаслідок наведеного переліку дій, можна представити так, як це показано на рис. 24.4.

Рис. 24.4. Діаграма варіантів використання для програми landlord

24.4.3. Опис варіантів використання

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

Почати програму

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

Додати нового мешканця: сценарій 1

На екрані має відобразитися повідомлення, у якому програма просить користувача ввести ім'я мешканця і номер кімнати. Ця інформація повинна заноситися в таблицю. Перелік автоматично сортується за номерами кімнат.

Ввести орендну плату: сценарій 1

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

Ввести витрату

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

Вивести перелік мешканців

Програма має виводити на екран перелік мешканців, кожен рядок переліку складається з двох полів: номера кімнати і імені мешканця.

Вивести таблицю доходів від оренди

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

Вивести таблицю витрат

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

Вивести річний звіт

Програма виводить річний звіт, що складається з:

● загальної орендної плати за минулий рік;

● переліку усіх витрат по кожній бюджетній категорії;

● підсумкового річного балансу (доходи/збитки).

24.4.4. Передбачення додаткових сценаріїв

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

Додати нового мешканця: сценарій 2

На екрані з'являється екран введення нового мешканця. Введений номер кімнати вже зайнятий деяким іншим мешканцем. Користувачу виводиться повідомлення про помилку.

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

Ввести орендну плату: сценарій 2

Під час введення даних про орендну плату користувач повинен ввести ім'я мешканця, місяць оплати і її суму. Програма проглядає перелік мешканців, але не знаходить введене прізвище. Виводиться повідомлення про помилку.

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

24.4.5. Використання діаграм дій UML

Діаграми дій UML використовуються для моделювання варіантів використання. Цей тип діаграм демонструє керівні потоки від одних дій до інших. Він нагадує блок-схеми, які існували з найперших днів удосконалення технологій програмування. Але діаграми дій повністю формалізовані і мають додаткові можливості.

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

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

Дата добавления: 2014-11-29