Уніфікована мова моделювання uml та її використання 2003 Уніфікована мова моделювання uml


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


Уніфікована мова моделювання UML та її використання

  • 2003


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

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

  • Прийнята консорціумом Object Managing Group (OMG) восени 1997р.

  • На сьогодні вона підтримується багатьма об'єктно-орієнтованими CASE системами, включаючи Rational Rose.

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

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

  • Важлива характеристика UML – її відкритість, UML має засоби розширення свого базового ядра.



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

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

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

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

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



Виникнення UML

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

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

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



Призначення UML

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


Статичні та динамічні моделі. Представлення

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

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

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


Представлення та діаграми UML



Діаграми UML

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

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

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



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

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

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



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

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

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

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


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

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

  • Уся подальша робота над проектом має здійснюватись на основі прецедентів: для кожного прецедента формується опис його динаміки у вигляді серії діаграм взаємодії та діаграм діяльності.

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

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

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



Рекомендації при побудові діаграм

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

  • Усі сутності діаграми мають бути одного концептуального рівня (відповідно до обраного рівня абстрагування).

  • Діаграми не повинні містити суперечливу інформацію (наприклад, не повинно бути елементів з однаковими іменами, але з різними атрибутами – омонімія, так само не повинно бути циклів у графах, що представляють відношення узагальнення чи агрегування).

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

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



Діаграми прецедентів або діаграми використання (use case diagrams)

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

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

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


Діячі (actors). Моделювання контексту системи

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

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

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

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

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

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



Варіанти використання, прецеденти (иsе сазе). Моделювання вимог до системи

  • Прецеденти визначають сервіси (функції), якими може скористатись діяч.

  • Як саме визначати прецеденти? Відповідь може бути така. Стосовно кожного діяча слід розглянути типові (узагальнюючі) варіанти сервісів (функцій), які мають підтримуватись системою і якими може скористатись діяч (зауважимо, що при цьому по суті визначаються вимоги до системи). Саме таким сервісам і мають співставлятись прецеденти.

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

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

  • У діаграмах прецедент зображується еліпсом.



Прецеденти та сценарії як типи й екземпляри

  • Стосовно прецедентів так само, як і у випадку діячів, варто розрізняти “типи” й “екземпляри”.

  • Якщо на прецедент подивитись з “позиції типу”, то екземпляром прецедента виступатиме сценарій (sсепаriо) як послідовність деяких дій.

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



Організація прецедентів. Відношення узагальнення та залежності

  • Прецеденти можна організувати, визначаючи між ними відношення узагальнення, залежності, включення і розширення. (При цьому можна виділяти прецеденти, що допускають повторне застосування).

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

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



Організація прецедентів. Відношення включення

  • Відношення включення (include) між прецедентами означає, що в деякій “точці” базового прецеденту як складова частина використовується поведінка іншого прецеденту. Прецедент, що включається, ніколи не існує автономно, а використовується тільки як частина більш загального прецеденту. Можна вважати, що один прецедент запозичає поведінку іншого прецедента (того, що включаються).

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

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



Організація прецедентів. Відношення розширення

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

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



Актори та відношення

  • Актори можуть пов'язуватись з прецедентами тільки відношеннями асоціації. Наявність асоціації між актором і прецедентом має свідчити про те, що вони спілкуються між собою, можливо, наприклад, посилаючи чи приймаючи повідомлення.

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

  • Асоціація слугує для опису наявності зв'язків між відповідними екземплярами.

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



Діаграми прецедентів. Приклад



Основні складові діаграм прецедентів



Використання діаграм класів



Діаграма прецедентів



Діаграма класів



Діаграма послідовності



Діаграма кооперації



Діаграма діяльності



Діаграма станів



Діаграма компонентів



Діаграма розгортання



Стереотипи відношення залежності та їх зміст



Література

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

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

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

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

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



Схожі:

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

Уніфікована мова моделювання uml та її використання 2003 Уніфікована мова моделювання uml icon21 лютого – день рідної мови
«Мова народу найбільший національний скарб\ О. Гончар «Мова наша, мова мова кольорова в ній гроза травнева, й тиша вечорова»
Уніфікована мова моделювання uml та її використання 2003 Уніфікована мова моделювання uml icon2 Створення анімаційного моделювання у програмі “Power Point” Створення анімаційного моделювання у програмі “Power Point”
Використання анімаційного моделювання істотно покращує сприйняття і осмислення тем, що вивчаються учнями, створює більш комфортні...
Уніфікована мова моделювання uml та її використання 2003 Уніфікована мова моделювання uml iconУкраїнська мова: історія І сучасність план Українська мова серед інших мов світу
...

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


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