Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст


НазваУніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст
Дата конвертації26.02.2013
Розмір445 b.
ТипПрезентации


Уніфікована мова моделювання UML. Загальна характеристика

  • 2003-2010


Зміст

  • Виникнення UML

  • Призначення UML у розрізі проектування ПС

  • Види діаграм

  • Спрощена стратегія використання UML-діаграм при моделюванні ПС

  • Засоби розширення UML:

    • стереотипи (stereotype);
    • помічені значення (tagged value);
    • обмеження (constraint).
  • Профілі предметних областей



Уніфікована мова моделювання UML

  • UML (Unified Modeling Language – Уніфікована Мова Моделювання) – це стандартна нотація візуального моделювання програмних систем (але не тільки програмних систем!).

  • На сьогодні вона підтримується багатьма об'єктно-орієнтованими інструментальними системами (CASE-системами).

  • UML – уніфікована мова, вона:

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

  • CASE — Computer Aided Software Engineering



Передумови виникнення UML

  • На середину 1990-х років існувало більше 50 різних об'єктно-орієнтованих методів чи мов моделювання.

  • У цей же період часу оновлюються версії таких досить розповсюджених методів як: Booch'93, OMT-2 (Object Modelling Technique) Джима Рамбо (Jim Rumbaugh), Fusion, OOSE (Object-Oriented Software Engineering) Айвера Якобсона (Ivar Jacobson).

  • І розроблювачів ПС, і замовників охоплювало занепокоєння при виборі методу проектування ПС, кожен із яких до того ж, як правило, спирався на власну нотацію.

  • Отже, на часі визріла проблема в стандартизації та уніфікації підходів до моделювання.



Виникнення UML

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

  • Трохи згодом, у тому ж 1995 році, до роботи приєднався Айвер Якобсон (Ivar Jacobson), залучаючи до процесу інтеграції й уніфікації ще один метод – власний метод OOSE.

  • Таким чином, на першому концептуальному етапі UML отримав трьох авторів: Буча, Рамбо і Якобсона, кожен із яких був ідеологом свого власного об'єктно-орієнтованого методу візуального моделювання.



Виникнення UML. The Three Amigos. (Terry Quatrani «Introduction to the Unified Modeling Language» - www.rational.com)



Деяка хронологія виникнення UML



UML та Object Managing Group (OMG)

  • Розвитком UML опікується консорціум Object Managing Group (OMG).

  • OMG опублікував запит на пропозиції щодо створення загальної метамоделі опису переважно ПС.

  • Rational Software Corporation представив специфікацію UML 1.0 (січень 1997) і після її опрацювання членами OMG, групою було створено і прийнято версію UML 1.1 (вересень 1997) .



Object Managing Group (OMG)

  • Консорціум OMG засновано у 1989 році одинадцятьма компаніями (в основному це були виробники комп'ютерних систем різного рівня й інтегратори зі світовим ім'ям). Основною задачею створення OMG було просування проекту CORBA. OMG пропагує CORBA під девізом "Middleware that's Everywhere" ("Середня ланка – всюди").

  • Зараз у консорціум входять більш ніж 1000 компаній. Серед них такі, наприклад, як IBM, DEC, Hewlett-Packard, Canon, Sun Microsystems, 3M, Fujitsu, Oracle, Bank of America, Chevron, Ford, Boeing, Hitachi, Xerox, VISA, AT&T, NT&T тощо. Варто зауважити, що більше 40% членів не є розроблювачами програмного забезпечення.

  • Штаб квартира OMG знаходиться у США (більш ніж 60% членів OMG знаходяться у США та Канаді).

  • Microsoft якийсь час тримався осторонь від OMG, проте підтримав UML1997 році році затвердження UML фактично як стандарту) і наступного 1998 року вступив у консорціум.



Статичні та динамічні об'єктні моделі. Моделі представлень архітектури

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

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

    • представлення (статичної) структури;
    • представлення (динамічної) поведінки;
    • представлення управління моделями.


Призначення UML у розрізі проектування ПС

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


Діаграми UML

  • Діаграма UML – це зображення у вигляді графа з вершинами (сутностями) і ребрами (відношеннями).

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

  • Діаграму належить розглядати як деякий зріз системи. При цьому один і той самий елемент може бути присутнім у кількох діаграмах (у кількох моделях).

  • В UML визначено вісім видів діаграм, кожна з яких може містити елементи певного типу. Типи можливих елементів і відношень між ними залежать від виду діаграми.



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



Види діаграм UML. Коротка характеристика. Діаграми прецедентів

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

  • Діаграми прецедентів виступають основою для подальшої деталізації системи у формі логічних і фізичних моделей. (Управління прецедентами є одним з наріжних каменів RUP).

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

  • Окрема діаграма прецедентів складається з прецедентів та акторів, а також можливих відношень між ними.



Ще раз про концептуальність моделі прецедентів

  • Промені зірки RUP представляють основні ідеї, закладені у RUP



«Перетікання» прецедентів у різних моделях основних потоків робіт

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



Види діаграм UML. Коротка характеристика. Діаграми класів

  • Діаграми класів (class diagrams) описують статичну структуру класів. Дозволяють (на концептуальному рівні) формувати "словник предметної області" та (на рівні специфікацій і рівні реалізацій) визначати структуру класів у програмній реалізації системи.

  • Діаграми класів можуть використовуватись для генерації каркасного програмного коду (в реальній мові програмування).



Види діаграм UML. Коротка характеристика. Діаграми поведінки та діаграми реалізації

  • Для опису динаміки використовуються діаграми поведінки (behavior diagrams), що поділяються на

    • діаграми взаємодії (interaction diagrams), які у свою чергу поділяються на
      • діаграм послідовності (sequence diagrams);
      • діаграм кооперації (співробітництва) (collaboration diagrams).
    • діаграми станів (statechart diagrams);
    • діаграми діяльності (активності) (activity diagrams);
  • І, нарешті, діаграми реалізації (implementation diagrams) поділяються на

    • компонентні діаграми· (діаграми компонентів) (component diagrams);
    • діаграми розгортання· (deployment diagrams).


Представлення системи (архітектури) та діаграми UML



Спрощена стратегія використання UML-діаграм при моделюванні ПС

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

  • Подальша робота над проектом може здійснюватись на основі моделі прецедентів. Зокрема, за прецедентами доцільно розробити (2) діаграми взаємодії, якими уточнюється динамічні аспекти системи. Паралельно виявляються задіяні в такій реалізації прецедентів об'єкти і, враховуючи відношення між ними, розробляються (3) діаграми класів. Діаграми класів можуть використовуватись для (4) генерації каркасного програмного коду.



Спрощена стратегія використання UML-діаграм при моделюванні ПС (прод.)

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

  • Розподіл об'єктів по програмних модулях фіксується (5) компонентними діаграмами, а розподіл програмних модулів по вузлах (комп'ютерах) мережі – (6) діаграмами розгортання.



Засоби розширення UML. Профілі предметних областей

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

  • Засобами розширення є:

    • стереотипи (stereotype);
    • помічені значення (tagged value);
    • обмеження (constraint).
  • Приклади профілів UML (стани профілів різні: зареєстровані в UML OMG, опубліковані, направлені на експертизу - обговорення, реалізовані у CASE-системах, у стадії розробки):

    • профіль для розробки ПС;
    • профіль для ділового моделювання;
    • профіль для моделювання даних;
    • профіль для web-моделювання.


Засоби розширення UML. Стереотипи

  • прикордонні (boundary) або інтерфейсні класи;

  • класи-сутності (entity);

  • управляючі (control) класи (класи-менеджери).

  • Stereotype Display (RationalRose):

    • Decoration;
    • Icon;
    • Label.


UML мова ділового моделювання. (UML-профіль ділового моделювання).

  • Маємо приклад, коли методи моделювання, що народилися і дозріли у сфері програмування, ефективно використовуються також в діловій сфері.

  • Для визначення елементів ділових моделей RUP використовуються стереотипи стандартних елементів UML:

      • <<business use case>> (на основі “use case”);
      • << business actor>> (на основі “actor”);
      • << business worker>> (на основі “class”);
      • << business entity>> (на основі “class”).
  • Перші два елементи <<business use case>> та << business actor>> є основними “цеглинами” моделей ділових прецедентів, два останніх – << business worker>> та << business entity>> – моделей ділових об'єктів.



Перехід від ділових моделей до моделей інформаційних систем





Засоби розширення UML. Помічені значення

  • Помічені значення дозволяють додавати деяку інформацію до специфікації UML-елементів.

  • Формат помічених значень (tagged value):

  • {tag = value}.

  • Наприклад, класу можна поставити у відповідність фірму чи ім'я розробника:

  • Ще приклади: {надійний клас}, {застарілий клас}



Засоби розширення UML. Обмеження (constraint)

  • Обмеження дозволяють задавати нову (розширену) семантику UML-елементів шляхом визначення нових (чи зміни існуючих) правил побудови ПС чи її частини.

  • Наприклад, можна застосовувати правила стосовно того, “як можна чи як не можна розробляти ПС”.

  • Формат обмежень:

  • {будь-який текст}.



Засоби розширення UML. Обмеження. Приклади “традиційних” обмежень (complete, incomplete ) для відношення узагальнення



Засоби розширення UML. Обмеження. Приклади “традиційних” обмежень (overlapping, disjoint ) для відношення узагальнення



Література

  • Боггс У., Боггс М. UML Rational Rose … . М.: Лори, ...

  • Кватрани Т. Rational Rose 2000 и UML. Визуальное моделирование. - М.: ДМК, 2001.

  • Ахмед Х.З., Амриш К.Е. Разработка корпоративных Java-приложений с помощью J2EE и UML . К.: Вильямс, 2002.

  • Буч Г., Рамбо Д., Джекобсон А. Язык UML. Руководство пользователя. - М.: ДМК, 2000.

  • Рамбо Д., Якобсон А., Буч Г. UML: Специальный справочник. - С-П.: Питер, 2002.

  • Леоненков А. Самоучитель UML. - С-П.: БХВ, 2001.

  • Эммерих В. Конструирование распределенных объектов. - М.: Мир, 2002.



Додаток



Моделі ділових прецедентів

  • Модель описує ділову сферу в термінах ділових акторів та ділових прецедентів.

  • Діловий актор представляє роль, яку хтось чи щось відіграє в діловій сфері.

  • Діловий прецедент є засобом специфікації ділової сфери з точки зору отримання діловими акторами деяких істотних для них результатів. (Порівняйте: прецеденти є засобом специфікації програмної системи з точки зору отримання акторами деяких істотних для них результатів).

  • Сукупність ділових прецедентів представляє всі можливі способи використання ділової сфери (організації, підприємства).

  • Діаграма ділових прецедентів містить ділових акторів, ділові прецеденти та зв'язки між ними.



Моделі ділових об'єктів

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

  • Опис реалізується в термінах двох стереотипів класів: business worker (діловий працівник, діловий виконавець) та business entity (ділова сутність) .

  • Діловий виконавець (ділова роль, діловий працівник) представляє абстракцію людини, що діє в межах ділової сфери.

  • Ділові сутності представляють “речі”, що обробляються чи використовуються діловими працівниками при “виконанні” ділового прецеденту.



Перехід від ділових моделей до моделей інформаційних систем

  • 1. Кожному діловому прецеденту, що має підтримуватися ІС, слід поставити у відповідність прецедент чи підсистему (чи навіть окрему систему) у системній моделі.



Перехід від ділових моделей до моделей інформаційних систем

  • 2. Кожному діловому виконавцю, що має підтримуватися ІС ставляться у відповідність:

    • актор (із тим же іменем, що мав діловий працівник);
    • прецедент (чи декілька прецедентів) для тих операцій (відповідальностей) ділового працівника, які підлягають автоматизації в ІС (рекомендується прецедент називати іменем тієї відповідальності, яку він підтримує);
    • асоціації між актором та кожним із зазначених прецедентів.
  • (Окремий випадок – повна автоматизація ділового виконавця).



Перехід від ділових моделей до моделей інформаційних систем

  • 2.а. Випадок повної автоматизації ділового виконавця.

  • У цьому випадку не потрібно вводити відповідного актора та, зрозуміло, його зв'язки. (Зв'язки з прецедентами будуть “передаватись” іншому актору: треба розглянути, хто ініціював операції ділового виконавця у діловій моделі).



Перехід від ділових моделей до моделей інформаційних систем

  • 3. Ділові актори належить розглянути у такий само спосіб, як і ділових виконавців (пункт 2). Звісно, про автоматизацію тут мова не може вестись. Кожний діловий актор стосовно розроблюваної системи буде просто актором (безпосереднім користувачем ІС).

  • Називати актора ІС доцільно іменем ділового актора.



Перехід від ділових моделей до моделей інформаційних систем

  • 4. Кожній діловій сутності, що повинна підтримуватися системою, в моделі аналізу ПС ставиться у відповідність клас-сутність (entity-клас).



Перехід від ділових моделей до моделей інформаційних систем. Приклад (автоматизація роботи клерка).



Перехід від ділових моделей до моделей інформаційних систем. Приклад (автоматизація роботи клерка).



Схожі:

Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconУніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст
На сьогодні вона підтримується багатьма об'єктно-орієнтованими інструментальними системами
Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconУніфікована мова моделювання uml. Загальна характеристика 2005 Уніфікована мова моделювання uml
У цей же період часу оновлюються версії таких досить розповсюджених методів як: Booch'93, omt-2 (Object Modelling Technique)
Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconУніфікована мова моделювання uml та її використання 2003 Уніфікована мова моделювання uml
У цей же період часу оновлюються версії таких досить розповсюджених методів як: Booch'93, omt-2 (Object Modelling Technique), Fusion,...
Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconУніфікована мова моделювання uml. Загальна характеристика 2007 Зміст
На сьогодні вона підтримується багатьма об'єктно-орієнтованими інструментальними системами
Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconУніфікована мова моделювання uml. Загальна характеристика 2007 Зміст
На сьогодні вона підтримується багатьма об'єктно-орієнтованими інструментальними системами
Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconУніфікована мова моделювання uml. Діаграми прецедентів 2004 Уніфікована мова моделювання uml
У цей же період часу оновлюються версії таких досить розповсюджених методів як: Booch'93, omt-2 (Object Modelling Technique), Fusion,...
Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconДіаграми прецедентів uml 2003-2010 Зміст
Організація прецедентів. Відношення залежності між прецедентами. Відношення включення
Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconМоделювання даних (ще один профіль uml/RR) 2005

Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconДіаграми прецедентів uml 2010 Зміст
Організація прецедентів. Відношення залежності між прецедентами. Відношення включення
Уніфікована мова моделювання uml. Загальна характеристика 2003-2010 Зміст iconЗагальна характеристика Загальна характеристика
В минулому була колонією Великобританії, після Другої Світової війни добилась незалежності

Додайте кнопку на своєму сайті:
dok.znaimo.com.ua


База даних захищена авторським правом ©dok.znaimo.com.ua 2013
звернутися до адміністрації
dok.znaimo.com.ua
Головна сторінка