На діаграмі кооперації при записі повідомлень також можуть використовуватися стереотипи, На діаграмі кооперації при записі повідомлень також можуть використовуватися стереотипи, розглянуті раніше при побудові діаграми послідовності. Їхня семантика й синтаксис залишаються без зміни, оскільки визначені в нотації мови UML
Приклад побудови діаграми кооперації
Як приклад розглянемо побудову діаграми кооперації для моделювання процесу телефонної розмови з використанням звичайної телефонної мережі (див. главу ф. Нагадаємо, що об'єктами в цьому прикладі є два абоненти а й Ь, два телефонних апарати з і </, комутатор і сама розмова як об'єкт моделювання. При цьому як комутатор, так і розмова є анонімними об'єктами.
На початковому етапі зобразимо всі об'єкти й зв'язки між ними на діаграмі кооперації за допомогою відповідних позначень. Помітимо, що перший телефонний апарат зображений як активний об'єкт, а другий - як пасивний.
Надалі необхідно специфікувати всі зв'язки на цій діаграмі, указавши на їхніх кінцях необхідну інформацію у формі ролей зв'язків. Доповнений у такий спосіб варіант діаграми кооперації зображений нижче. Помітимо, що для об'єкта "Розмова" зазначене позначене значення {transient}, що означає, що цей об'єкт створюється в процесі виконання загального процесу й знищується до його завершення. Нагадаємо, що позначені значення (tagged values) є стандартними елементами мови UML.
Нарешті, на діаграму кооперації необхідно нанести всі повідомлення, указавши їхній порядок і семантичні особливості. Остаточний фрагмент діаграми кооперації зображений на мал. 9.13 і містить, строго говорячи, модель кооперації тільки для початку розмови. Ця діаграма може бути доповнена повідомленнями, необхідними для закінчення розмови, що читачам пропонується виконати самостійно як вправа.
Як неважко помітити, діаграма кооперації для приклада з телефонною розмовою не містить ні тимчасових особливостей передачі повідомлень, ні особливостей життєвого циклу об'єктів, що беруть участь у даній кооперації. Тому може бути ухвалене рішення про те, що вона є надлишковою при наявності побудованої діаграми послідовності. Цей факт не викликає сумнівів у тих випадках, коли структура взаємодіючих об'єктів є досить тривіальною.
Якщо ж взаємодіючі об'єкти утворять між собою різні типи відносин-асоціацій (композиція, агрегація), то діаграма кооперації виявляється необхідним поданням моделі на всіх її рівнях.
Заключні рекомендації з побудови діаграм кооперації
Побудова діаграми кооперації можна починати відразу після побудови діаграми варіантів використання. У цьому випадку кожний з варіантів використання може бути специфікований у вигляді окремої діаграми кооперації рівня специфікації. Ця діаграма сприяє більше . повному розумінню особливостей реалізації функцій системою, хоча й не може містити всю інформацію, необхідну для їхньої реалізації.
Надалі, після побудови діаграми класів, кожна з діаграм кооперації може уточнюватися у вигляді відповідної діаграми рівня прикладів. Важливо розуміти, що діаграма кооперації цього рівня може містити ті й тільки ті об'єкти й зв'язки, які вже визначені на побудованій раніше діаграмі класів. У противному випадку, якщо виникає необхідність включення в діаграму кооперації об'єктів, які створюються на основі відсутніх класів, що відповідають діаграми класів повинні бути модифіковані явним описом цих класів.
Варто пам'ятати, що на діаграмі кооперації зображуються тільки ті об'єкти, які безпосередньо в ній беруть участь. При цьому об'єкти можуть виступати в різних ролях, які повинні бути явно зазначені на відповідних кінцях зв'язків діаграми. Застосування стереотипів уніфікує кооперацію, забезпечуючи її адекватну інтерпретацію як з боку замовників, так і з боку розроблювачів. Проте, доцільно розрізняти термінологію, використовувану на діаграмах кооперації рівня специфікації й рівня прикладів.
Так, при побудові діаграм кооперації рівня специфікації бажано застосовувати найбільш зрозумілому замовникові термінологію, уникаючи технічних фраз і словосполучень. Наприклад, "оформити замовлення", "відвантажити товар", "представити звіт", "розробити план" і т.д. Такі відомі розроблювачам слова як "сервер", "захищений протокол", "закрита операція класу", а також стереотипи й позначені значення на цьому рівні застосовувати не рекомендується. На рівні специфікації потрібно прагнути досягти по можливості повного взаєморозуміння між замовником і командою розроблювачів всіх варіантів використання проектованої системи в контексті їхньої кооперації.
При побудові діаграм кооперації рівня прикладів термінологія повинна найбільше точно відбивати всі аспекти реалізації відповідних об'єктів і зв'язків. Оскільки діаграма цього рівня є документацією для розроблювачів системи, тут припустимо використовувати весь арсенал стереотипів, обмежень і позначених значень, що є в мові UML. Якщо типових позначень недостатньо, розроблювачі можуть доповнити діаграму власними елементами, використовуючи механізм розширень мови UML.
Процес побудови діаграми кооперації рівня прикладів повинен бути погоджений із процесами побудови діаграми класів і діаграми послідовності. У першому випадку, як ми вже відзначали, необхідно стежити за використанням тільки тих об'єктів, для яких визначені їхні класи, що породжують. У другому випадку потрібно погоджувати послідовності переданих повідомлень. Мова йде про те, що не допускається різний порядок проходження повідомлень для моделювання того самого взаємодії на діаграмі кооперації й діаграмі послідовності. Таким чином, діаграма кооперації, з одного боку, забезпечує концептуально погоджений перехід від статичної моделі діаграми класів до динамічних моделей поводження, що представляється діаграмами послідовності, станів і діяльності. З іншого боку, діаграма цього типу визначає особливості реалізації моделі на діаграмах компонентів і розгортання, які є предметом розгляду у двох наступних главах книги
Практичне заняття №11
Тема: Адміністративна контрольна робота.
Мета: Перевірка отриманих за семестр знань.
(див документ Адміністративна контрольна робота №1 )
Практичне заняття №12
Тема: Підсумкове заняття. Узагальнення вивченого матеріалу за семестр.
Мета: Узагальнення вивченого матеріалу за семестр. Аналіз контрольної роботи.
Узагальнення вивченого матеріалу відбувається на базі аналізу результатів виконання адміністративної контрольної роботи у вигляді тестового контролю знань, або дискусійного обговорення питань, що пов’язані з перспективами розвитку конструювання програмних продуктів.
Приклади тестових питань:
1. До якого поняття відноситься твердження: послідовність команд комп'ютера для вирішення завдань
1) додаток
2) програма
3) програмне забезпечення
4) алгоритм
2. До якого поняття відноситься твердження: програмна реалізації на комп'ютері рішення конкретного завдання
1) додаток
2) програма
3) алгоритм
4) програмне забезпечення
3. До якого поняття відноситься твердження: сукупність програм і необхідної документації
1) блок-схема
2) програмне забезпечення
3) додаток
4) програма
4. Яка з характеристик не відноситься до промислового програмного продукту?
1) продається на ринку
2) має серійне виробництво
3) розробляється для власних потреб
4) має документацію
5. Яке із тверджень не відноситься до завдань технології програмування?
1) підвищення продуктивності праці програмістів
2) забезпечення захисту програм від злому
3) підвищення якості програмних продуктів
4) прискорення розробки програм
6. Про який вид користувачів програм йде мова: розробляють і налагоджують програми для вирішення конкретних завдань
1) системні програмісти
2) системні програмісти
3) мережні адміністратори
4) прикладні програмісти
7. Про який вид користувачів програм йде мова: мають навички по використанню програм
1) адміністратори баз даних
2) прикладні програмісти
3) користувачі
4) оператори ПК
8. Про який вид користувачів програм йде мова: відповідають за роботу мережі
1) мережні програмісти
2) мережні адміністратори
3) мережні користувачі
4) адміністратори баз даних
9. Про який вид користувачів програм йде мова: забезпечують підтримку баз даних
1) адміністратори баз даних
2) мережні адміністратори
3) системні адміністратори
4) системні програмісти
10. До якого з показників якості програм відноситься твердження: дружній інтерфейс, розвинена довідка й документація
1) мобільність
2) врахування людського фактору
3) модифікуємість
4) ефективність
11. До якого з показників якості програм відноситься твердження: незалежність від платформи, операційної системи й т.і.
1) ефективність
2) надійність
3) мобільність
4) комунікативність
12. До якого з показників якості програм відноситься твердження: інтеграція з існуючими програмами
1) комунікативність
2) ефективність
3) надійність
4) мобільність
13. До якого з показників якості програм відноситься твердження: стійкість, точність виконання функцій
1) ефективність
2) мобільність
3) облік людського фактору
4) надійність
14. До якого з видів ПЗ з погляду ліцензування відноситься твердження: умовно-безкоштовні, обмежені за часом
1) freeware
2) demo
3) shareware
4) opensource
15. До якого з видів ПО з погляду ліцензування ставиться твердження: вбудовані, що поставляються з конкретним комп'ютером
1) freeware
2) license
3) alfa
4) OEM
16. До якого з видів ПЗ з погляду ліцензування відноситься твердження: поширюються з вихідним кодом
1) opensource
2) demo
3) OЕM
4) freeware
17. До якого з видів ПЗ з погляду ліцензування відноситься твердження: безкоштовна, урізана по можливостях версія
1) freeware
2) demo
3) opensource
4) beta
18. До якого з видів ПЗ з погляду ліцензування відноситься твердження: комерційна, оплачена, легальна програма
1) opensource
2) freeware
3) license
4) demo
19. До якого з видів ПЗ з погляду ліцензування відноситься твердження: безкоштовні, вільно розповсюджувані програми
1) beta
2) freeware
3) demo
4) alfa
20. Якщо прийняти увесь час розробки ПЗ за 100 %, скільки відсотків часу йде на проектування
1) 30%
2) 40%
3) 50%
4) 60%
21. Якщо прийняти увесь час розробки ПЗ за 100 %, скільки відсотків часу йде на аналіз вимог до системи
1) 5%
2) 10%
3) 15%
4) 30%
22. Якщо прийняти увесь час розробки ПЗ за 100 %, скільки відсотків часу йде на повне тестування продукту
1) 30%
2) 40%
3) 50%
4) 60%
23. Яке з наведених визначень підходить під визначення такого етапу життєвого циклу розробки ПЗ як аналіз вимог
1) визначення функцій ПЗ
2) уточнення й деталізація функцій ПЗ. Проектування плану-графіка виконання робіт
3) створення структур баз даних і зовнішнього вигляду інтерфейсу
4) проектування систем допомоги й документації
24. Який з перерахованих етапів розробки ПЗ не відноситься до водоспадної моделі життєвого циклу
1) аналіз вимог
2) супровід
3) аналіз ризиків
4) проектування
25. Серед наведених переваг виберіть ту, яка не відноситься до водоспадної моделі життєвого циклу
1) дана модель представляє дискретний, розбитий на кроки процес, по завершенню кожного кроку можна проконтролювати й повторити етап спочатку
2) не можна переходити до наступного етапу доти, поки не буде повністю закінчений попередній
3) неможливо точно передбачити час закінчення проекту
4) створюється чітка й повна документація на кожному кроці, що дозволяє швидше розробляти в майбутньому подібні проекти
26. Серед наведених недоліків виберіть той, який не відноситься до водоспадної моделі життєвого циклу
1) чим раніше допущена помилка в проекті, тем пізніше вона буде виявлена й тим дорожче її усунення
2) розроблювач може упустити деякі елементи програми
3) розробляти проектну документацію нудно
4) дана стратегія підходить тільки до невеликих, в основному прикладних проектів
27. Серед наведених недоліків виберіть той, яке не відноситься до спіральної моделі розробки ПЗ
1) відсутність статистики по ефективності стратегії
2) підвищені вимоги до замовника програмного продукту
3) труднощі по визначенню часу закінчення проекту
4) замовник може побачити результат розробки тільки наприкінці, коли що-небудь змінити вже неможливо
28. По наведеній характеристиці визначите назву моделі проектування ПЗ. На першому етапі створюється версія з мінімальним набором функцій. Кожна наступна версія підвищує функціональність програми. На початку розробки відомі не всі вимоги до системи
1) водоспадна модель
2) макетування
3) модель швидкої розробки
4) спіральна модель
29. Яка з характеристик не відноситься до моделі RAD?
1) невелика команда виконавців
2) короткий пророблений графік
3) чим раніше буде допущена помилка, тим пізніше її виявлять
4) ітераційний підхід до розробки
30. Який з етапів життєвого циклу не відноситься до моделі RAD?
1) тестування
2) реалізація
3) аналіз і планування
4) впровадження
31. Яке із тверджень не відноситься до моделі RAD?
1) застосування CASE засобів
2) неповне завершення робіт на етапах життєвого циклу
3) відмова від етапу проектування
4) участь користувачів у розробці
32. Яка основна особливість XP-процесів?
1) простота реалізації системи
2) легкість тестування
3) швидка розробка
4) відсутність стадії проектування
33. З наведених тверджень приведіть ту, яка не відноситься до принципів XP-процесів
1) безперервне тестування й інтеграція
2) проста при написанні коду
3) детальне проектування
4) постійний зв'язок із замовником
34. Який із принципів не відноситься до ХР-процесів?
1) використання стандартів кодування
2) докладне документування
3) колективне володіння кодом
4) парне кодування
ІІ семестр
Лекція №1,2
Тема: Поняття тестування та налагодження програмного продукту. Види тестування. Етапи тестування. Створення тестових даних. Проведення тестування. Визначення кількості тестових проходів. Модульне тестування.
Мета: Придбання знань з виконання технологічнх процесів тестування та налагодження програмних продутів.
Перелік питань, що розглядаються на лекції:
1. Поняття налагодження та тестування програмного продукту.
2. Принципи та види налагодження.
3. Аксіоми налагождення.
4. Автономне налагоодження модуля.
5. Комплексне налагождення програмного продукту.
Налагодження ПЗ - це діяльність, спрямоване на виявлення й виправлення помилок у ПЗ із використанням процесів виконання його програм.
Тестування ПЗ - це процес виконання його програм на деякому наборі даних, для якого заздалегідь відомий результат застосування або відомі правила поведінки цих програм. Зазначений набір даних називається тестовим або просто тестом. Таким чином, налагодження можна представити у вигляді багаторазового повторення трьох процесів: тестування, у результаті якого може бути констатована наявність у ПЗ помилки, пошуку місця помилки в програмах і документації ПЗ і редагування програм і документації з метою усунення виявленої помилки. Іншими словами:
Налагодження = Тестування + Пошук помилок + Редагування.
