АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомДругоеЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция

Примітка. При дослівному перекладі терміна RUP губиться деяке додаткова семантика, пов'язана із двозначним тлумаченням англійського Ratіonal

Читайте также:
  1. Примітка
  2. Примітка
  3. Примітка
  4. Примітка
  5. Примітка
  6. Примітка
  7. Примітка
  8. Примітка
  9. Примітка
  10. Примітка
  11. Примітка
  12. Примітка

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

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

Висновки

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

1. Призначення мови UML

2. Загальна структура мови UML

3. Пакети в мові UML

4. Основні пакети метамоделі мови UML

5. Специфіка опису метамоделі мови UML

6. Особливості зображення діаграм мови UML


РОЗДІЛ 18. Діаграма варіантів використання (use case diagram)

à Варіант використання

à Актори

à Інтерфейси

à Примітки

à Відношення на діаграмі варіантів використання

à Рекомендації з розроблення діаграм варіантів використання

 

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

Розроблення діаграми варіантів використання переслідує такі цілі:

· Визначити загальні межі і контекст модельованої предметної області на початкових етапах проектування системи.

· Сформулювати загальні вимоги до функціональної поведінки проектованої системи.

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

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

Суть цієї діаграми полягає в наступному: проектована система представляється у вигляді множини сутностей або акторів, що взаємодіють із системою за допомогою так званих варіантів використання. При цьому актором (actor) або дійовою особою називається будь-яка сутьність, що взаємодіє із системою ззовні. Це може бути людина, технічний пристрій, програма або будь-яка інша система, яка може служити джерелом дії на модельовану систему так, як визначить сам розробник. У свою чергу, варіант використання (use case) служить для опису сервісів, які система надає акторові. Іншими словами, кожний варіант використання визначає деякий набір дій, що здійснюється системою під час діалогу з актором. При цьому нічого не говориться про те, яким чином буде реалізовано взаємодію акторів з системою.


1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 39 | 40 | 41 | 42 | 43 | 44 | 45 | 46 | 47 | 48 | 49 | 50 | 51 | 52 | 53 | 54 | 55 | 56 | 57 | 58 | 59 | 60 | 61 | 62 | 63 | 64 | 65 | 66 | 67 | 68 | 69 | 70 |

Поиск по сайту:



Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Студалл.Орг (0.003 сек.)