Уніфікована мова моделювання UML 2013 АВТОММАТИЗАЦІЯ ПЕРІОДИЧНИХ ТЕХНОЛОГІЧНИХ
Скачать презентацию Уніфікована мова моделювання UML 2013 АВТОММАТИЗАЦІЯ ПЕРІОДИЧНИХ ТЕХНОЛОГІЧНИХ
16172-lekts_uml.ppt
- Количество слайдов: 51
Уніфікована мова моделювання UML 2013 АВТОММАТИЗАЦІЯ ПЕРІОДИЧНИХ ТЕХНОЛОГІЧНИХ ПРОЦЕСІВ КАФЕДРА АВТОМАТИЗАЦІЇ ТА КОМП’ЮТЕРНО-ІНТЕГРОВАНИХ ТЕХНОЛОГІЙ
UML – 2006 2 Уніфікована мова моделювання UML UML (Unified Modeling Language – Уніфікована Мова Моделювання) – це стандартна нотація візуального моделювання програмних систем. На сьогодні вона підтримується багатьма об'єктно-орієнтованими CASE (англ. Computer-Aided Software Engineering) системами, зокрема Rational Rose, Umbrello UML Modeller. UML – уніфікована мова, вона: не залежить від методології, що використовується при розробці проекту; може підтримувати будь-яку об'єктно-орієнтовану мову програмування. В UML можна змістовно описувати об'єкти й компоненти в різних предметних областях.
UML – 2006 3 Передумови виникнення UML На середину 1990-х років існувало більше 50 різних об'єктно-орієнтованих методів моделювання. Розповсюдженими методами були: Booch'93 Греді Буча (Grady Booch), OMT-2 (Object Modelling Technique) Джима Рамбо (Jim Rumbaugh), OOSE (Object-Oriented Software Engineering) Айвера Якобсона (Ivar Jacobson). Вони мали різну нотацію. Тому виникла проблема в стандартизації й уніфікації підходів до моделювання.
UML – 2006 4 Виникнення UML Початком розробки UML вважається жовтень 1994 року, коли у Rational Software Corporation силами Греді Буча (Grady Booch) і Джима Рамбо (Jim Rumbaugh) була започаткована робота з уніфікації їх власних методів Booch'93 та OMT. У 1995 році, до роботи приєднався Айвер Якобсон (Ivar Jacobson), залучаючи до процесу інтеграції й уніфікації ще один метод – власний метод OOSE. Отже, на концептуальному етапі UML отримала трьох авторів: Буча, Рамбо і Якобсона,
UML – 2006 5 Виникнення UML. The Three Amigos. - www.rational.com.
UML – 2006 6 Object Managing Group (OMG) Підтримкою UML займається Object Managing Group (OMG). Консорціум OMG засновано у 1989 році виробниками комп'ютерних систем різного рівня й комп’ютерними інтеграторами зі світовим ім'ям. Зараз у консорціум входять більш ніж 1000 компаній. Серед них такі, як IBM, DEC, Hewlett-Packard, Canon, Sun Microsystems, 3M, Fujitsu, Oracle, Bank of America, Chevron, Ford, Boeing, Hitachi, Xerox, VISA, AT&T, NT&T тощо. Штаб квартира OMG знаходиться у США (більш ніж 60% членів OMG знаходяться у США та Канаді). Microsoft якийсь час тримався осторонь від OMG, проте підтримав UML і у 1998 року вступив у консорціум.
UML – 2006 7 Статичні та динамічні об'єктні моделі. В UML інтегровані різноманітні засоби візуального моделювання. Зокрема, два визначальних види об'єктних моделей: структурних (або статичних) моделей – де описується структура сутностей системи, включаючи класи, інтерфейси, відношення, атрибути; моделей поведінки (або динамічних моделей) – де описується поведінка (функціонування) об'єктів системи, включаючи методи, взаємодію, процес зміни станів окремих компонент чи всієї системи.
UML – 2006 8 Моделі представлень архітектури UML забезпечує моделювання різних представлень архітектури систем: представлень структури системи; представлень динамічної поведінки системи; представлень управління моделями.
UML – 2006 9 Призначення UML при проектування ПС Надати користувачу засоби візуального моделювання ПС різного призначення з метою розробки та отримання документації. Забезпечити користувачів засобами розширення та спеціалізації з метою більш точного опису конкретних предметних областей. В UML уведено механізм розширення базових понять. Підтримувати таку специфікацію моделей, яка, з одного боку, була б незалежною від конкретних мов програмування і, з іншого боку, забезпечувала б потенційні можливості їх реалізації.
UML – 2006 10 Стадії розробки ПС Об'єктно-орієнтований аналіз (analysis) – спосіб аналізу, що вивчає вимоги до системи з точки зору класів і об'єктів, грунтуючись на словнику предметної області. Об'єктно-орієнтоване проектування (design) – спосіб проектування, що включає опис процесу об'єктно-орієнтованої декомпозиції і об'єктно-орієнтовану нотацію для опису різних моделей системи (логічної, фізичної, статичної і динамічної). Об'єктно-орієнтоване програмування – це метод реалізації, в основі якого лежить ідея представлення програмної системи у вигляді набору взаємодіючих об'єктів, кожен з яких є екземпляром деякого класу, а класи об'єднані в ієрархію спадкоємства.
UML – 2006 11 Об'єктно-орієнтований підхід до моделювання Ідея об'єктно-орієнтованого підходу така: програмна система представляється у вигляді множини самостійних сутностей (об'єктів), що взаємодіють один з одним. Кожна сутність сама відповідає за зберігання інформації, необхідної для її життя, і реалізує свою власну поведінку. Інкапсуляція – це принцип, що полягає в побудові оболонки довкола деякого набору даних і коду, що оброблює ці дані. Профілі UML профіль для розробки ПС; профіль для ділового моделювання; профіль для моделювання даних; профіль для web-моделювання.
UML – 2006 12 Діаграми UML Основними засобами UML є діаграми. Діаграма UML – це зображення у вигляді графа з вершинами (сутностями) і ребрами (відношеннями). Основна мета діаграм – візуальне моделювання розроблюваної системи чи архітектури, причому моделювання із різних точок зору на систему. Діаграму належить розглядати як певний зріз системи. При цьому один і той самий елемент може бути присутнім у кількох діаграмах . В UML визначено вісім видів діаграм, кожна з яких може містити елементи певного типу. Типи можливих елементів і відношень між ними залежать від виду діаграми.
UML – 2006 13 Види діаграм в Rational Rose Діаграма варіантів використання (Use case diagram). Діаграма класів (Class diagram). Діаграма станів (Statechart diagram). Діаграма активності (Activity diagram). Діаграма взаємодії (Interaction diagram); Цей вид діаграм складається з двох: Діаграма послідовності дій (Sequesnce diagram); Діаграма співробітництва (Collaboration diagram). Діаграма компонентів (Component diagram). Діаграма розгортання (Deployment diagram).
UML – 2006 14 Діаграми структури та діаграми поведінки Діаграми структури та діаграми поведінки
UML – 2006 15 Представлення архітектури системи
UML – 2006 16 Модель архітетури ПС Архітектура - це сукупність суттєвих рішень стосовно: організації програмної системи; вибору структурних елементів, що складають систему, і їх інтерфейсів; поведінки елементів, специфікованих в коопераціях з іншими елементами; складання з структурних і поведінкових елементів все більш великих підсистем; архітектурного стилю, що направляє і визначає всю організацію системи: статичні і динамічні елементи, їх інтерфейси, кооперації і спосіб об'єднання.
UML – 2006 17 Діаграми прецедентів Діаграми прецедентів або діаграми використання (use case diagrams). Задають концептуальну модель ПС. Визначають загальні кордони та контекст програмної системи, уточнють її зовнішню функціональну поведінку. Вони утворюють первісну документація, яка використовується розробниками, замовниками, користувачами та іншими – стейкхолдерами. Діаграми прецедентів виступають основою подальшої деталізації системи. Прецеденти дозволяє визначити функціональні вимоги, на основі яких розробляється технічне завдання.
UML – 2006 18 Діаграма прецедентів Окрема діаграма прецедентів складається з прецедентів, акторів та відношень між ними. Вона показує варіанти взаємодії користувачів із самою системою, задає вимоги до зовнішнього інтерфейсу системи.
UML – 2006 19 Діаграма прецедентів ІС “Дипломні роботи”
UML – 2006 20 Діаграми класів Діаграми класів (class diagrams) описують статичну структуру системи. Дозволяють на концептуальному рівні формувати "словник предметної області" та (на рівні специфікацій і рівні реалізацій) визначати структуру класів у програмній реалізації системи. Діаграми класів використовувються для генерації каркасного програмного коду мовою програмування.. Клас – це суть, що описує сукупність об'єктів зі схожою структурою, поведінкою і зв'язками з іншими об'єктами. У UML існують такі різновиди класу: сутність, інтерфейс, утиліта.
UML – 2006 21 Зображення класу Назва класу Атрибути класу Операції класу Інтерфейс - це сукупність операцій, що надаються класом або компонентом. Інтерфейс описує поведінку класу або компоненту, видиму ззовні, але не визначає фізичні реалізації операцій. Інтерфейс- клас що не має власних атрибутів.
UML – 2006 22 Атрибути класу Атрибут задається у вигляді текстового рядка: <видимість> <ім'я>:<тип> = <початкове_значення> {<властивості>} <видимість> має: Відкритий атрибут (public), позначається символом +; Захищений атрибут (protected), позначається символом #; Закритий атрибут (private), позначається символом -.
UML – 2006 23 Операції класу Операція задається текстовим рядком: <видимість><им’я>(<список_параметрів>):<тип_возвращаемого_значения> {<властивості>} <видимість> і <ім'я> - що і для атрибуту. <тип_возвращаемого_значения> – залежний від мови реалізації, що повертається функцією. Якщо воно не вказане, то передбачається, що функція повертає значення (void для C/C++). <список_параметров> – список формальних параметрів, розділених комами: <вигляд> <ім'я>:<тип> = <значення_за _замовчуванням> <вигляд> – одне з in (вхідний параметр), out (вихідний параметр), або inout (змішаний, тобто і вхідний і вихідний), за умовчанням in.
UML – 2006 24 Асоціації класів У UML асоціації позначаються лініями, що з’єднують класи. Крім того, вказуються роль і розмірність кожного з учасників зв’язку. Розмірність показується у вигляді діапазону [мін..макс] невід’ємних чисел, (зірочка (*) позначає нескінченність. Ієрархія обмежень на “класові” відношення: залежність; асоціація; агрегація; композиція.
UML – 2006 25 Агрегування класів
UML – 2006 26 Наслідування класів
UML – 2006 27 Розширення класів прикордонні (boundary) або інтерфейсні класи; класи-сутності (entity); управляючі (control) класи (класи-менеджери). Stereotype Display (RationalRose): Decoration; Icon; Label.
UML – 2006 28 Діаграма класів ІС “Дипломні роботи”
UML – 2006 29 Діаграми послідовності дій Діаграма послідовності дій (sequence diagram) відображає взаємодію об'єктів, впорядковану за часом. На ній показують об'єкти і класи, що використовуються в сценарії, і послідовність повідомлень (тобто виклик методів), якими обмінюються об'єкти. Діаграми послідовності дій відповідають реалізаціям прецедентів в логічному представленні системи. На діаграмах послідовностей об’єкти показують вертикальними штриховими лініями (лініями життя) із назвами об’єктів над ними. Вісь часу має вертикальний напрямок, її спрямовано вниз, повідомлення, які надсилаються від одного об’єкта до іншого, позначають стрілками із назвами операції і параметрів.
UML – 2006 30 Діаграма послідовності дій ІС “Дипломні роботи”
UML – 2006 31 Діаграми співпраці ( кооперації) На діаграмах співпраці показується взаємодія між об’єктами, які беруть участь у певній події. На діаграмах співпраці показують всі повідомлення, що відбуваються між об’єктами. Повідомлення надіслані від одного з об’єктів до іншого позначаються стрілочками, поряд з якими показано назву повідомлення, параметри і послідовність повідомлення. Діаграми співпраці служать для показу специфічного перебігу виконання або ситуацій у програмі. Ці діаграми є засобом для швидкого показу і пояснення окремого процесу у програмній логіці.
UML – 2006 32 Приклад діаграми кооперації
UML – 2006 33 Діаграми станів Діаграма станів (Statechart diagram) – служить для опису станів об’єкта та умов переходу між ними. Опис станів дозволяє точно описати модель поведінки об’єкта при отриманні різних повідомлень та взаємодій з іншими об’єктами. Діаграма станів використовується для аналізу кінцевих автомататів ( англ. State machine ) – які відоражають специфікацію послідовності станів, через які проходить об'єкт або взаємодія у відповідь на події свого життя, а також відповідні дії об'єкта на ці події. На діаграмах стану об’єкти розглядаються як машини станів або скінченні автомати.
UML – 2006 34 Діаграма станів ІС “Університетські курси”
UML – 2006 35 Приклад діаграми станів АТМ
UML – 2006 36 Діаграми активності (діяльності) Діаграма активності (Activity diagram) – це подальший розвиток діаграми станів. Головне призначення цієї діаграми в тому щоб відображати бізнес-процеси об’єктів. На діаграмі діяльності показано послідовність актів дій системи на основі - діяльностей. Діяльність є окремим кроком у процесі. Одній діяльності відповідає окремий стан у системі з внутрішньою діяльністю і вихідна транзакція. Діаграми діяльності – своєрідні блок-схеми. Головна відмінність між Activity та Statechart diagram полягає у тому, що в першому випадку головне – це дія, а в другому – статичний стан. При цьому Activity diagram більше підходить для моделювання послідовності дій, а Statechart diagram для моделювання дискретних станів.
UML – 2006 37 Потоки подій Прецедентам співставляюь потоки подій, які описують поведінку системи в процесі отримання необхідного результату. Потоки подій описуються мовою предметної області, а не в термінах реалізації. Найчастіше для опису потоку подій пропонується наступна структура: заголовок (наприклад, “Потік подій для прецеденту <Зняти гроші>”); короткий опис потоку (наприклад, “Дозволяє клієнту зняти гроші з його рахунку”); передумови (pre-conditions) (діаграми прецедентів не дозволяють відображати послідовний характер використання прецедентів!); головний потік подій та, можливо, його підпотоки; альтернативні потоки подій; постумови (post-conditions).
UML – 2006 38 Приклад діаграми активності
UML – 2006 39 Діаграма компонентів Діаграма компонентів, Component diagram - статична структурна діаграма, показує розбиття програмної системи на структурні компоненти і зв'язки (залежності) між компонентами. Як фізичні компонент можуть виступати файли, бібліотеки, модулі, виконувані файли, пакети і т.п.
UML – 2006 40 Приклад діаграми компонентів
UML – 2006 41 Діаграма розгортання Діаграма розгортання Deployment diagram - служить для моделювання працюючих вузлів і апаратних засобів, розгорнених на них. В UML на вузлах розгортаються артефакти (англ. artifact), та компоненти. Між артефактом і логічним елементом (компонентом), який він реалізує, встановлюється залежність маніфестації.
UML – 2006 42 Діаграма розгортання
UML – 2006 43 Спрощена стратегія використання UML-діаграм при моделюванні ПС Спочатку для проектованої ПС варто розробити (1) діаграму прецедентів, яка виступає концептуальною моделлю системи (визначаються загальні кордони та контекст програмної системи, уточнюється її зовнішня функціональна поведінка і, зокрема, уточнюються функціональні вимоги до ПС, саме тут з'являється первісна документація, яка може використовуватись для предметного обговорення розробниками, замовниками, користувачами та іншими зацікавленими сторонами – стейкхолдерами). Подальша робота над проектом може здійснюватись на основі моделі прецедентів. Зокрема, за прецедентами доцільно розробити (2) діаграми взаємодії, якими уточнюється динамічні аспекти системи. Паралельно виявляються задіяні в такій реалізації прецедентів об'єкти і, враховуючи відношення між ними, розробляються (3) діаграми класів. Діаграми класів можуть використовуватись для (4) генерації каркасного програмного коду.
UML – 2006 44 Спрощена стратегія використання UML-діаграм при моделюванні ПС (прод.) Для визначення поведінки класів із складною динамікою реагування на події можуть бути задіяні діаграми станів та діаграми діяльності. Розміщення об'єктів по програмних модулях фіксується (5) компонентними діаграмами, а розташування програмних модулів стосовно вузлів (комп'ютерів) мережі – (6) діаграмами розгортання.
UML – 2006 45 Засоби розширення UML. Профілі предметних областей В UML закладено механізм розширення, який дозволяє визначати для моделювання нові елементи, враховуючи специфіку предметної області, яка розглядається. Засобами розширення є: стереотипи (stereotype); помічені значення (tagged value); обмеження (constraint). Приклади профілів UML (стани профілів різні: зареєстровані в UML OMG, опубліковані, направлені на розглядання, реалізовані у CASE-системах, у стадії розробки): профіль для розробки ПС; профіль для ділового моделювання; профіль для моделювання даних; профіль для web-моделювання.
UML – 2006 46 Засоби розширення UML. Стереотипи прикордонні (boundary) або інтерфейсні класи; класи-сутності (entity); управляючі (control) класи (класи-менеджери). Stereotype Display (RationalRose): Decoration; Icon; Label. Стереотипи дозволяють створювати нові будівельні блоки як похідні від існуючих, але більш специфічні для розв’язуваної задачі. Стереотипи розширюють словник UML. Приклад. (Профіль для розробки ПС). Стереотипи класів для етапу аналізу ПС:
UML – 2006 47 UML – мова ділового моделювання. (UML-профіль ділового моделювання). Маємо приклад, коли методи моделювання, що народилися і дозріли у сфері програмування, ефективно використовуються також в діловій сфері. Для визначення елементів ділових моделей RUP використовуються стереотипи стандартних елементів UML: стереотип <
UML – 2006 48 Результат трансформації та кодогенерації.
UML – 2006 49 Засоби розширення UML. Помічені значення Помічені значення дозволяють додавати деяку інформацію до специфікації UML-елементів. Формат помічених значень (tagged value): {tag = value}. Наприклад, класу можна поставити у відповідність фірму чи ім'я розробника:
UML – 2006 50 Засоби розширення UML. Обмеження (constraint) Обмеження дозволяють задавати нову (розширену) семантику UML-елементів шляхом визначення нових (чи зміни існуючих) правил побудови ПС чи її частини. Наприклад, можна застосовувати правила стосовно того, “як можна чи як не можна розробляти ПС”. Формат обмежень: {будь-який текст}.
UML – 2006 51 Література Боггс У., Боггс М. UML Rational Rose … . М.: Лори, ... Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование. - М.: ДМК, 2001. Ахмед Х.З., Амриш К.Е. Разработка корпоративных Java-приложений с помощью J2EE и UML . К.: Вильямс, 2002. Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. - М.: ДМК, 2000. Рамбо Д., Якобсон А., Буч Г. UML: Специальный справочник. - С-П.: Питер, 2002. Леоненков А. Самоучитель UML. - С-П.: БХВ, 2001. Эммерих В. Конструирование распределенных объектов. - М.: Мир, 2002.