Лекція 3. Об’єктно-орієнтований аналіз та проектування предметного середовища

Лекція 3. Об’єктно-орієнтований аналіз та проектування предметного середовища засобами UML

Опис предметного середовища та постановка задачі

Для аналізу, візуального моделювання та проектування програмного забезпечення потрібна спеціальна нотація або мова. UML (Unified Modeling Language) - це мова для візуалізації специфікації, конструювання, документування елементів програмних систем. UML - мова загального призначення для об'єктного моделювання. UML

Типи моделей IML UML дозволяє описувати систему такими моделями: Модель функціонування Як описується функціональність системи з точки зору користувача. Об'єктна модель Як виглядає проект системи з точки зору об'єктного підходу. Динамічна модель Як взаємодіють один з одним компоненти системи в динаміці, з часом. Які процеси відбуваються в системі.

Діаграми UML Діаграми UML призначені для візуального відображення моделей та їх компонентів. UML 2.0 має 13 типів діаграм: Структурні діаграми (6) Діаграми поведінки (3) Діаграми взаємодії (4)

Типы диаграмм UML use case (прецедентів) діаграма сlass/object (класів і об’єктів) діаграма behavior (поведінки) діаграми : statechart (станів) діаграма activity (діяльності) діаграма interaction (взаємодії) діаграми : sequence (послідовності) діаграма collaboration (співпраці) діаграма Implementation (реалізації) діаграми : component (компонентів) діаграма deployment (розгортання) діаграма model management (модель управління) діаграма

Поняття UML Для опису структури : Актор, Атрибут, Клас, Компонент, Інтерфейс, Об'єкт, Пакет. Для опису поведінки : Дія, Подія, Повідомлення, Метод, Операція, Стан, Варіант використання. Для опису зв'язків : Агрегація, Асоціація, Композиція, Залежність, Спадкоємство. Деякі інші поняття: Стереотип, Кратність, Роль.

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

Актори і варіанти використання спілкуються за допомогою посилання повідомлень. Повідомлення можуть йти в обидві сторони. Стрілка показує ініціатора спілкування (актор на малюнку) і може бути опущена. Зв'язок акторів і варіантів використання

Діаграма варіантів використання

Приклад use case diagram

Приклад sequence diagram

Приклад package diagram

Приклад activity diagram

Приклад class diagram

Приклад collaboration diagram

Приклад deployment diagram

Постановка задачі Здійснити об’єктно-орієнтований аналіз та об’єктно-орієнтоване проектування програми, що моделює роботу Internet-магазину різних товарів електронної техніки.

Об’єктно-орієнтований аналіз (ООА) предметного середовища

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

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

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

1. Виконати об’єктно-орієнтований аналіз та проектування предметного середовища засобами UML: 1.1. Розробити сценарій поведінки об’єкта (послідовний опис дій об’єкта під час його функціонування). 1.2. Визначити типи взаємодій між користувачем та системою. Побудувати діаграму прецедентів. 1.3. Виконати ідентифікацію класів системи, що моделюється. Створити список іменників, які відповідають класам. Здійснити аналіз іменників з метою вилучення таких, що не відповідають класам задачі. Побудувати UML-діаграму класів, UML-діаграму об’єктів. Програма роботи

1.4. Виконати ідентифікацію атрибутів. Здійснити уточнення списку іменників з метою визначення їх складу. Доповнити діаграму класів даними про атрибути. 1.5. Здійснити ідентифікація операцій (методів). Створити список дієслівних фраз, що відповідають методам класів. Вилучити усі несуттєві дієслівні фрази. Доповнити діаграми класів списком методів. 1.6. Визначити взаємодію між об’єктами. Програма роботи

2. Об’єктно-орієнтоване програмування: 2.1.Розробити файлову структуру програми на С++ для інтерфейсів і реалізацій класів (файли .h, .cpp). 2.2. Розробити сценарій моделювання роботи фізичного об’єкта. 2.3. Розробити тестову програму (у вигляді функції main()), що реалізує сценарій моделювання роботи фізичного об’єкта. Програма роботи

Основні події, що відбуваються під час моделювання роботи Internet- магазину, такі: - Системний адміністратор торгової фірми розміщує на web-сайті дані про товари та їх ціни. Дані оновлюються періодично; - Замовник по web-сайтах здійснює пошук товару, ціна та функціональні параметри якого задовольняють його; - Замовлення на поставку певного товару та дата його доставки оформлюється замовником дистанційно згідно з можливостями web-сайта; - Оплата товару може здійснюватися готівкою та по платіжним карткам через банки замовника та Інтернет-магазину; - Системний адміністратор Інтернет-магазину веде облік покупців і нараховує їм пільги. Аналіз і спрощення задачі

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

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

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

Приклад діаграми прецедентів. Версія 1

Лексичний та семантичний аналіз опису системи Лексичний, синтаксичний та семантичний аналізи опису об’єктного середовища здійснюють з метою визначення класів, атрибутів і методів. Виділяють іменники – претенденти на роль класів Виділяють іменники – претенденти на роль атрибутів Виділяють дієслова – претенденти на роль методів Виділяють дієслова – претенденти на роль зв’язків між класами

Приклад лексичний аналізу опису системи Отримаємо наступний список іменників, які претендують на роль класів:

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

Приклад уточнення іменників

Приклад уточнення іменників

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

Приклад діаграми класів. Версія 01

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

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

Приклад визначення атрибутів каталог продукції є в кожному магазині, тобто входить як складова частина в магазин. каталог має нести інформацію про товари магазину, тому його атрибут - список товарів магазину; магазин зазвичай веде перелік своїх покупців, тобто ведеться список покупців, що теж є складовою магазину; кожному зареєстрованому покупцю відповідає його обліковий запис, що містить інформацію про нього: ім’я, адресу, рейтинг- показник кількості покупок - все це є атрибутами класу Покупець; покупцю в кожному магазині для зручності виділяється «корзина», в якій розміщуються обрані ним товари, тому атрибутом корзини має бути список обраних покупцем товарів; годинник несе інформацію про час в системі моделювання, то виділимо атрибут, що відповідає часу в системі.

Приклад діаграми класів з атрибутами

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

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

Уточнення семантики методів магазин як головний об’єкт моделювання має працювати, тобто має розпочатися моделювання системи; - в каталог продукції персоналом магазину товар можуть бути додано, редаговано та видалено дані про нього; - годинник системи має показувати та змінювати час в системі; - в список покупців персонал магазину може додавати покупця та редагувати дані про нього; - в корзину покупець додає чи видаляє товар; - персонал магазину може очистити корзину при виконанні замовлення; - покупець може переглядати товар, обирати його(відправити в корзину), оплатити(купити) чи повернути.

Приклад діаграми класів з методами

Відносини і їхнє графічне зображення на діаграмі класів Базові відносини, що зображуються на діаграмах класів: Відношення асоціації (association relationship) Відношення узагальнення (generalization relationship) Відношення агрегації (aggregation relationship) Відношення композиції (composition relationship)

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

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

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

Приклад графічного зображення успадкування

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

Приклад графічного зображення відношення агрегації

Композиція (composition) – різновид відносини агрегації, при якій складові частини цілого мають такий самий час життя, що й саме ціле. Ці частини знищуються разом зі знищенням цілого. Відношення композиції – окремий випадок відносини агрегації. Це відношення служить для специфікації більше сильної форми відносини "частина-ціле", при якій складові частини тісно взаємозалежні із цілим. Особливість цього взаємозв'язку полягає в тім, що частини не можуть виступати у відриві від цілого, тобто зі знищенням цілого знищуються й всі його складові частини. Композит (composite) – клас, що зв'язаний відношенням композиції з одним або більшим числом класів. Відношення композиції

Приклад зображення відношення композиції

Відношення між класами Предметна область із казки “Курочка Ряба”

Діаграма класів, яка описує предметну область із казки “Курочка Ряба”

KPI KTV На діаграмі класи пов‘язані між собою. Успадкування : людина – базовий клас дід, баба – нащадки, похідні класи Асоціація: клас «інструмент» асоціюється з класами «дід», «баба» 3. Асоціація: клас «інструмент» асоціюється з класом «яйцо» Композиція: клас «хвіст» є невід’ємною частиною класу «миша» 5. Агрегація – на малюнку відсутня Відношення між класами

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

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

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

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

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

кратність: необхідно додати позначення кратності залежностей; кратність залежностей може мінятися в процесі подальшого аналізу вимог до системи; невраховані залежності повинні бути виявлені й додані в модель. Критерії визначення залежностей між класами

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

Приклад діаграми класів із залежностями

Проектування в середовищі Sybase Power Designer File -> New

Проектування в середовищі Sybase Power Designer View -> Diagram -> New Diagram -> Use Case Diagram,

Проектування в середовищі Sybase Power Designer View -> Diagram -> New Diagram -> Class Diagram

Проектування в середовищі Sybase Power Designer Потрібно вказати назву діаграми, що створюється.

Проектування в середовищі Sybase Power Designer Вводимо імя створенного классу

Проектування в середовищі Sybase Power Designer Вводимо атрибути классу.

Проектування в середовищі Sybase Power Designer Введення визначених для класу методів.

Проектування в середовищі Sybase Power Designer Додавання на діаграму звязку між классами

Програмування в Visual Studion.NET F:\Teaching Students 2009-2011\Methodical materials for disciplines\OOP\ANSI C++ OOP\Prezentation ANSI C++ OOP\2011-2012\lec3\version1.code.doc Просмотр кода Запуск програми "G:\Teaching Students 2009-2012\Methodical materials for disciplines\OOP\ANSI C++ OOP\Prezentation ANSI C++ OOP\2011-2012\OOP lec3 ОOA+UseCAse+ClassDiagram\Internet_Shop_v1\3_program_develop\Internet_shop_Lab_01\debug\InternetShop.exe"

Збір даних про систему на етапі аналізу Розробка діаграми прецедентів, яка описує процес взаємодії користувачів з системою, на підставі даних аналізу. Ідентифікація об’єктів і класів: 3.1. виділення іменників в опису постановки задачі, 3.2. фільтрація списку іменників від таких, що не є частиною системи моделювання 3.3. створення версії 1 діаграми класів Ідентифікація атрибутів класів: 4.1. виділення іменників в опису постановки задачі 4.2. фільтрація списку іменників від таких, що не є характеристикою або властивостями об’єктів 4.3. створення версії 2 діаграми класів Резюме Етапи ОО аналізу та проектування

5. Ідентифікація методів класів: 5.1.Виділення дієслів та їх дієслівних оборотів з опису постановки задачі 5.2. Фільтрація списку дієслів від таких, які не характеризують поведінку об’єктів 5.3. Визначення операцій (методів) класів 5.4. Створення версії 3 діаграми класів Ідентифікація взаємозв’язків між об’єктами та між класами: 6.1. Фільтрація дієслівних оборотів від таких, що не характеризують взаємовідношення між класам и 2. Створення версії 3 діаграми класів для моделювання взаємодій між об’єктами. Резюме Етапи ОО аналізу та проектування

Контрольні запитання

Конец лекции 3.