русс | укр

Мови програмуванняВідео уроки php mysqlПаскальСіАсемблерJavaMatlabPhpHtmlJavaScriptCSSC#DelphiТурбо Пролог

Компьютерные сетиСистемное программное обеспечениеИнформационные технологииПрограммирование


Linux Unix Алгоритмічні мови Архітектура мікроконтролерів Введення в розробку розподілених інформаційних систем Дискретна математика Інформаційне обслуговування користувачів Інформація та моделювання в управлінні виробництвом Комп'ютерна графіка Лекції


Приклад побудови діаграми варіантів використання


Дата додавання: 2014-10-07; переглядів: 1856.


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

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

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

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

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

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

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

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

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

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

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

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

Побудова діаграми варіантів використання є найпершим етапом процесу об’єктно-орієнтованого аналізу й проектування, ціль якого - представити сукупність вимог до поводження проектованої системи. Специфікація вимог до проектованої системи у формі діаграми варіантів використання являє собою самостійну модель, що у мові UML одержала назву моделі варіантів використання й має своє спеціальне стандартне ім'я або стереотип "useCaseModel".

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


<== попередня лекція | наступна лекція ==>
Варіант використання | Рекомендації з розробки діаграм варіантів використання


Онлайн система числення Калькулятор онлайн звичайний Науковий калькулятор онлайн