X Код для використання на сайті:
Ширина px

Скопіюйте цей код і вставте його на свій сайт

X Для завантаження презентації, скористайтесь соціальною кнопкою для рекомендації сервісу SvitPPT Завантажити собі цю презентацію

Презентація на тему:
Уніфікована мова моделювання UML. Діаграми прецедентів

Завантажити презентацію

Уніфікована мова моделювання UML. Діаграми прецедентів

Завантажити презентацію

Презентація по слайдам:

Слайд 1

Уніфікована мова моделювання UML. Діаграми прецедентів 2004 (Курс “Інформаційні технології”) UML. Діаграми прецедентів

Слайд 2

Уніфікована мова моделювання UML UML (Unified Modeling Language – Уніфікована Мова Моделювання) – це стандартна нотація візуального моделювання програмних систем (але не тільки програмних систем!). Прийнята консорціумом Object Managing Group (OMG) восени 1997р. На сьогодні вона підтримується багатьма об'єктно-орієнтованими CASE системами, включаючи Rational Rose. UML – дійсно уніфікована мова, вона: не залежить від методології, що використовується при розробці проекту; може підтримувати будь-яку об'єктно-орієнтовану мову програмування. На UML можна змістовно описувати класи, об'єкти й компоненти в різних предметних областях, що можуть суттєво відрізнятись одна від одної. Важлива характеристика UML – її відкритість, UML має засоби розширення свого базового ядра. UML. Діаграми прецедентів

Слайд 3

Передумови виникнення UML У середині 90-х існувало більше 50 різних об'єктно-орієнтованих методів чи мов моделювання. У цей же період часу оновлюються версії таких досить розповсюджених методів як: Booch'93, OMT-2 (Object Modelling Technique), Fusion, OOSE (Object-Oriented Software Engineering). І розроблювачів ПС, і замовників охоплювало занепокоєння при виборі метода проектування ПС, кожен із яких до того ж, як правило, спирався на власну нотацію. Отже, на часі визріла проблема в стандартизації й уніфікації підходів до моделювання. UML. Діаграми прецедентів

Слайд 4

Виникнення UML Початком розробки UML вважається жовтень 1994 року, коли у Rational Software Corporation силами Греді Буча (Grady Booch) і Джима Рамбо (Jim Rumbaugh) була започаткована робота з уніфікації їх власних методів Booch'93 та OMT. Перша версія Уніфікованого Метода (Unified Method 0.8) була опублікована в жовтні 1995. Трохи згодом, у тому ж 1995 році, до роботи приєднався Айвер Якобсон (Ivar Jacobson), залучаючи до процесу інтеграції й уніфікації ще один метод – власний метод OOSE. Таким чином, на першому концептуальному етапі UML отримав трьох авторів: Буча, Рамбо і Якобсона, кожен із яких був ідеологом свого власного об'єктно-орієнтованого метода візуального моделювання. UML. Діаграми прецедентів

Слайд 5

Виникнення UML UML. Діаграми прецедентів

Слайд 6

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

Слайд 7

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

Слайд 8

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

Слайд 9

Діаграми UML: діаграми структури та діаграми поведінки UML. Діаграми прецедентів

Слайд 10

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

Слайд 11

Види діаграм UML. Коротка характеристика Для опису динаміки використовуються діаграми поведінки (behavior diagrams), що підрозділяються на діаграми станів (statechart diagrams); діаграми діяльності (активності) (activity diagrams); діаграми взаємодії (interaction diagrams), що у свою чергу підрозділяються на діаграм послідовності (sequence diagrams); діаграм кооперації (співробітництва) (collaboration diagrams). І, нарешті, діаграми реалізації (implementation diagrams) поділяються на компонентні діаграми· (діаграми компонентів) (component diagrams); діаграми розгортання· (deployment diagrams). UML. Діаграми прецедентів

Слайд 12

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

Слайд 13

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

Слайд 14

Діаграми прецедентів або діаграми використання (use case diagrams) Значення. Діаграми варіантів використання є первісним, концептуальним представленням (концептуальною моделлю) ПС в процесі її проектування й розробки. Вони виступають основою подальшої деталізації системи у формі логічних і фізичних моделей. Розробка діаграм варіантів використання переслідує такі конкретні цілі: визначити загальні кордони та контекст системи; сформулювати загальні вимоги до функціональної поведінки системи; отримати первісну документацію для предметної взаємодії розроблювачів системи з її замовниками й користувачами. Управління прецедентами є одним з наріжних каменів RUP. UML. Діаграми прецедентів

Слайд 15

Управління прецедентами в RUP UML. Діаграми прецедентів

Слайд 16

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

Слайд 17

Варіанти використання, прецеденти (иsе сазе). Моделювання вимог до системи Прецеденти є засобом специфікації системи с точки зору отримання діячами деяких істотних для них результатів. Тобто, прецедентами задаються сервіси (функціональні можливості) системи, якими може скористатись діяч. Як саме визначати прецеденти? Відповідь може бути такою. Стосовно кожного діяча слід розглянути типові (узагальнюючі) варіанти сервісів (функцій), які мають підтримуватись системою і якими може скористатись діяч. (Можливо, для цього доведеться спочатку провести ділове моделювання.) Виділеним сервісам і мають співставлятись прецеденти. Фактично визначенням прецедентів забезпечується моделювання вимог до системи. Прецеденти специфікують поведінку розроблюваної системи (що має робити система), не визначаючи реалізацію цієї системи (яким чином вона це має робити). Вони дозволяють досягти взаєморозуміння між розроблювачами, замовниками, експертами і кінцевими користувачами. Крім того, прецеденти допомагають перевіряти й контролювати архітектуру системи у процесі її розробки. UML. Діаграми прецедентів

Слайд 18

Прецеденти. Специфікація прецедентів у Rational Rose У діаграмах прецедент зображується еліпсом. Як правило, для іменування прецедентів використовуються дієслова чи короткі дієслівні фрази (“Створення таблиці”, “Створити таблицю”). UML. Діаграми прецедентів

Слайд 19

Прецеденти. Потоки подій Прецедентам рекомендується співставляти потоки подій, які описують поведінку системи в процесі отримання необхідного результату. Потоки подій описуються мовою предметної області, а не в термінах реалізації. Найчастіше для опису потоку подій пропонується наступна структура: заголовок (наприклад, “Потік подій для прецеденту ”); короткий опис потоку (наприклад, “Дозволяє клієнту зняти гроші з його рахунку”); передумови (pre-conditions) (діаграми прецедентів не дозволяють відображати послідовний характер використання прецедентів!); головний потік подій та, можливо, його підпотоки; альтернативні потоки подій; постумови (post-conditions). UML. Діаграми прецедентів

Слайд 20

Потоки подій. Ще одна структура опису X. Потік подій для прецеденту . // X - номер потоку (прецеденту) X.1. Передумови (pre-conditions). X.2. Головний потік. X.3. Підпотоки (S-1, S-2, …). X.4. Альтернативні потоки (E-1, E-2, ). X.5. Постумови (post-conditions). UML. Діаграми прецедентів