23398

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

Лабораторная работа

Информатика, кибернетика и программирование

підпис прізвище €œ ____ €œ _____________ 2011 року ЛАБОРАТОРНЕ ЗАНЯТТЯ № 8 з навчальної дисципліни __моделювання комп’ютерних мереж напряму підготовки _______інформаційні технології________ освітньокваліфікаційного рівня ____cпеціаліст_____________ спеціальності _____ ком’пютерні системи та мережі_________ Тема Уніфікована мова моделювання UML повна назва лекції Лабораторне заняття №8 розроблено стар. ПЛАН ПРОВЕДЕННЯ ЗАНЯТТЯ ТА РОЗРАХУНОК ЧАСУ Вступ...

Украинкский

2013-08-03

125 KB

2 чел.

МІНІСТЕРСТВО   ІНФРАСТРУКТУРИ   УКРАЇНИ

Державний університет інформаційно-комунікаційних технологій

КАФЕДРА           інфокомунікацій____________

ЗАТВЕРДЖУЮ

Завідуючий кафедрою

_______________ Костік Б.Я.

       (підпис, прізвище)

“ ____ “  _____________  2011  року

ЛАБОРАТОРНЕ ЗАНЯТТЯ №  8

з навчальної дисципліни __моделювання компютерних мереж 

напряму підготовки _______інформаційні технології________

освітньо-кваліфікаційного рівня ____cпеціаліст_____________

спеціальності _____ компютерні системи та мережі_________

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

                                                 (повна назва лекції)

Лабораторне заняття №8 розроблено стар. викл каф. Інф. Срочинська Г.С.

(вчена ступінь та звання,  прізвище та ініціали автора)

Обговорено на засіданні кафедри (ПМК)

Протокол № __________

“ ____ “ _____________ 2011 року

Київ


Навчальні цілі: Вивчення основних понять моделювання, ознайомлення з поняттями системи та моделі, співвідношенням між моделлю та системою, класифікацією  моделей,  видами  моделей, технологію моделювання;

Виховні цілі: Формування у студентів інженерно-технічного кругозору, методами  імітаційного моделювання для побудови  комп’ютерних систем та мереж, вміння ставити та вирішувати складні інженерні задачі, проводити аналіз, аргументовано робити висновки.       

Час  90 хв.

ПЛАН ПРОВЕДЕННЯ  ЗАНЯТТЯ ТА РОЗРАХУНОК ЧАСУ

Вступ                                                                                                   10  хвилин

Навчальні питання

  1.  Методики об’єктно-орієнтованого моделювання                   20хвилин
  2.  Завдання UML                                                                          20хвилин
  3.  Загальна структура мови                                                                20хвилин

Заключення                                                                                           10  хвилин

ЛІТЕРАТУРА:

(рекомендована для студентів)

1. В.Г. Кривуца, В.В. Барковський, Л.Н. Беркман. Математичне моделювання телекомунікаційних систем: Навч. посібник. –К.: Звязок, 2007.

НАВЧАЛЬНО-МАТЕРІАЛЬНЕ ЗАБЕЗПЕЧЕННЯ

(наочні посібники, схеми, таблиці, ТЗН та інше)

Діапроектор, дидактичні слайди


НАВЧАЛЬНІ МАТЕРІАЛИ

Вступ

При створенні складних інженерних систем прийнято використовувати прийоми моделювання. Складність більшості створюваних сьогодні програмних систем не поступається складності багатьом інженерним спорудженням, тому моделювання програмних систем є досить актуальним завданням. Більш того, у таких концепціях, як MDA (Model Driven Architecture - архітектура на основі моделей) і MDD (Model Driven Development - розробка на базі моделей), моделям приділяється центральна роль у процесі створення програмного продукту. Основною ідеєю цих концепцій є представлення процесу створення програмного продукту у вигляді ланцюжка трансформацій його вихідної моделі в готову програмну систему.

Майже у всіх інструментальних засобах, що втілює ідеї MDD, як мова моделювання використовується мова UML (Unified Modeling Language - уніфікована мова моделювання), цілком або які-небудь його частини.

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

  1.  
    Методики об’єктно-орієнтованого моделювання

Розвиток об’єктно-орієнтованих мов моделювання в 1980-х 1990-х роках призвів до появи великого числа об’єктно-орієнтованих підходів до моделювання. Зокрема, у період з1989 по 1994 роки загальна кількість відомих мов моделювання зросло з 10 до більш ніж 50.[3]. Кожна з мов мала свої достоїнства й недоліки також як і свою нотацію. Той самий символ у різних нотаціях найчастіше міг мати абсолютно різне значення.

Це ситуація суворої конкуренції між методиками моделювання дістала назву «війни методів».

«Війна методів» обумовила необхідність створення єдиної мови, що поєднувала би сильні сторін відомих методів. І в жовтні 1994 року почалося створення мови UML, основу якої склали кілька об'єктно-орієнтованих методів, що зарекомендували себе щонайкраще на практиці, але кожний з яких був націлений не рішення окремого завдання аналізу й проектування.

- метод Граді Буча, умовна назва BOOCH ( Booch'91, BooCH Lite, Booch'93) вважався найбільш ефективним на етапах проектування й розробки програмних систем [ 1].

- метод Джеймса Рамбо, Object Modeling Technique (ОМТ, ОМТ-2) – оптимально походив для аналізу процесів обробки даних в інформаційних системах [5]; (Rumbaugh, et al., 1991);

- метод Айвара Джекобсона (Ivar Jacobson), Object-Oriented Software Engineering (OOSE) – містив засоби представлення варіантів використання, що мають істотне значення на етапі аналізу вимог у процесі проектування бізнес-додатків [6]. [Jacobson, et al., 1993].

Спочатку Г. Буч і Д. Рамбо з компанії Rational Software Corporation почали роботу з уніфікації своїх методів. Незважаючи на те, що самі по собі ці методи були досить популярні, спільна робота їх була спрямована на вивчення всіх відомих об’єктно-орієнтованих методів з метою виявлення їхніх достоїнств. Восени того ж року до них приєднався Айвар Якобсон, головний технолог компанії Objectory AB,, до того, щоб інтегрувати свій метод OOSE із двома вищезгаданими. Протягом усього року творці займалися збором відкликань від основних компаній, що працюють в області створення ПО. За цей час стало ясно, що більшість таких компаній, що працюють в області створення , порахувала UML мовою, що має стратегічне значення для їхнього бізнесу.

У результаті був створений консорціум UML, у який увійшли організації, що виявили бажання надати ресурси для роботи, спрямованої на створення повної специфікації UML. Версія 1.0 мови з'явилася в результаті спільних зусиль компаній Digital Equipment Corporation, Hewlett Packard, I-Logix, Intellicprp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle, Rational, Texas Instruments _ Unisys. UML 1.0 виявився добре визначеною, виразною, потужною мовою, що може бути застосованою для рішення великої кількості різноманітних завдань.

На протязі декількох років спеціальна робоча група OMG (OMG Revision Task Force) підтримувала просування проекту UML. Були створені версії 1.3, 1.4, і 1.5. За 2000-2003 була розроблена версія UML 2.0.у листопаді 2007 випущена поточна версія UML2.1.2.

  1.  
    ЗАВДАННЯ UML

Мова UML призначена для рішення наступних завдань:

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

2. передбачити внутрішні механізми розширюваності й спеціалізації базових концепцій мови;

3. забезпечити максимальну незалежність проекту створення програмного забезпечення від конкретних мов програмування й процесів розробки;

4. забезпечити формальну основу для однозначної інтерпретації мови;

5.стимулювати розширення ринку об’єктно-орієнтованих інструментальних засобів створення програмного забезпечення;

6. інтегрувати кращий практичний досвід використання мови й реалізації програмних засобів його підтримки.

У значній мірі мова UML не залежить від процесу розробки програмного забезпечення. Уніфікований процес розробки ПЗ (Rational Unified Process, RUP) [Kruchten, 2004] - це один з підходів до організації життєвого циклу ПЗ, який особливо добре сполучається з UML. Цей комерційний продукт задає строгий регламент розподілу завдань і відповідальності між виконавцями в процесі розробки ПЗ.

3. ЗАГАЛЬНА СТРУКТУРА МОВИ

Підсумую, UML ( Unified Modeling Language — уніфікована мова моделювання) — мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення. UML є мовою широкого профілю, це відкритий стандарт, що використовує графічні позначення для створення абстрактної моделі системи, називаною UML моделлю. UML був створений для визначення, візуалізації, проектування й документування здебільшого програмних систем.

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

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

Семантика мови UML визначається для двох видів об'єктних моделей: структурних і поведінкових. Структурні (статичні) моделі описують структуру сутностей або компонентів системи, включаючи їхні класи, інтерфейси, атрибути й зв'язки. Моделі поводження (динамічні) описують поведінку або функціонування об'єктів системи, включаючи їхні методи, взаємодію (співробітництво) між ними, а також процес зміни станів окремих компонентів і системи в цілому [4]. (Буч,1994)

Формальний опис мови UML ґрунтується на наступній загальній ієрархічній структурі модельних подань, що складається із чотирьох рівнів абстракції:

- позначка-метамодель,

- метамодель,

- модель,

- об'єкти користувача [16].

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

Основою представлення UML на метамодельнім рівні є опис трьох його логічних блоків (пакетів):

- основні елементи,

- елементи поводження

- загальні механізми [16].

Концептуальна модель мови

Концептуальна модель мови включає основні будівельні блоки, правила їхні сполучення й загальні механізми [13, 17, 18].

Словник мови UML містить сутності (абстракції, що є основними елементами моделі) і відносини (основні сполучні будівельні блоки), Сутності й відносини за певними правилами з'єднуються в конструкції - діаграми.

В UML визначено чотири типи сутностей [13]:

структурні сутності,

що поділяються на основні

клас (Class), інтерфейс (Interface)

кооперація (Collaboration),

прецедент (Use case),

активний клас (Active class),

компонент (Component),

вузол (Node)

різновиди основних

актор (Actor),

сигнал (Signal),

утиліта (Utility, вид класів),

процес (Process),

нитка (Thread, вид активних класів))

інші

додатка (Application),

документ (Document),

файл (File), бібліотека (Library),

сторінка (Page),

таблиця (Table, вид компонентів));

сутності поводження (Behavioral things)

взаємодія (Interaction)

автомат (State machine);

сутності, що групують, - пакет (Packages);

анотаційні сутності – примітка (Note).

Основними типами відносин в UML є відносини:

залежності (Dependency),

асоціації(Association) (різновидом асоціації є

відношення агрегації (Aggregation)),

узагальнення(Generalization)

реалізації (Realization).

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

Для побудови коректно оформленої моделі в UML визначені правила, що дозволяють коректно й однозначно визначати:

(1) імена сутностей, відносин і діаграм,

(2) область дії імен (контекст, у якому ім'я має деяке значення),

(3) видимість імен (для використання іншими елементами),

(4) цілісність (правильність і погодженість співвідношення елементів),

(5) виконання моделі [13].

Ефективність і спрощення застосування мови забезпечується використанням певних угод, так званих, загальних механізмів:

- специфікацій (Specifications),

- доповнень (Adornments),

- прийнятих розподілів (Common divisions

- механізмів розширення (Extensibility mechanisms) [7, 17, 18].

Кожний елемент нотації UML має унікальне графічне позначення й специфікацію - текстове подання синтаксису й змістовної семантики відповідного будівельного блоку.

Практично всі будівельні блоки характеризуються дихотомією “клас/ об'єкт” і“інтерфейс / реалізація”. Це основні підходи розподілу реальності при об’єктно-орієнтованом моделюванні систем.

UML допускає контрольовані розширення для адаптації мови до конкретних потреб. Наявність внутрішніх механізмів розширення принципово відрізняє UML від таких засобів моделювання як IDEF0, IDEF1X, IDEF3, DFD і ERM [37], що є замкнутими й не допускають расширення засобами самої мови.

До механізмів розширення UML ставляться:

- стереотип (Stereotype), що розширює словник мови (дозволяє створювати з існуючих блоків нові, специфічні для конкретного розв'язуваного завдання);

- тег-значення (Tagged value), що розширює властивості будівельного блоку (дає можливість включати нову інформацію в специфікацію елемента);

-обмеження (Constraint), що розширює семантику будівельного блоку (дозволяє додавати нові або модифікувати існуючі правила за допомогою семантичних обмежень, заданих природною мовою або формальною мовою OCL). Деякі розширення придбали таку популярність, що були внесені в стандарт поточної версії UML [7, 21, 18].

Діаграми

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

В UML використовуються наступні види діаграм (для виключення неоднозначності приведу також позначення англійською мовою):

Structure Diagrams:

Class diagram

Component diagram

Composite structure diagram

Collaboration (UML2.0)

Deployment diagram

Object diagram

Package diagram

Behavior Diagrams:

Activity diagram

State Machine diagram

Use case diagram

Interaction Diagrams:

Communication diagram (UML2.0) / Collaboration (UML1.x)

Interaction overview diagram (UML2.0)

Sequence diagram

Timing diagram (UML2.0)

Структурні діаграми:

Класів

Компонентів

Композитної/складеної структури

Кооперації (UML2.0)

Розгортання

Об'єктів

Пакетів

Діаграми поводження:

Діяльності

Станів

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

Діаграми взаємодії:

Комунікації (UML2.0) / Кооперації (UML1.x)

Огляду взаємодії (UML2.0)

Послідовності

Синхронізації (UML2.0)

Діаграма класів (Class diagram) — статична структурна діаграма, що описує структуру системи, вона демонструє класи системи, їхні атрибути, методи й залежності між класами.

Діаграма компонентів (Component diagram) — статична структурна діаграма, показує розбивку програмної системи на структурні компоненти й зв'язки (залежності) між компонентами. Як фізичні компоненти можуть виступати файли, бібліотеки, модулі, що виконуються файли, пакети й т.п. 

Діаграма композитної/складеної структури (Composite structure diagram) — статична структурна діаграма, демонструє внутрішню структуру класів і, по можливості, взаємодію елементів (частин) внутрішньої структури класу.

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

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

Діаграма розгортання (Deployment diagram) — служить для моделювання працюючих вузлів (апаратних засобів, node) і артефактів, розгорнутих на них. В UML 2.0 на вузлах розвертаються артефакти (англ. artifact), у той час як в UML 1.0 на вузлах розверталися компоненти. Між артефактом і логічним елементом (компонентом), що він реалізує, установлюється залежність маніфестації.

Діаграма об'єктів (Object diagram) — демонструє повний або частковий знімок моделируємої системи в заданий момент часу. На діаграмі об'єктів відображаються екземпляри класів (об'єкти) системи із вказівкою поточних значень їхніх атрибутів і зв'язків між об'єктами.

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

Діаграма діяльності (Activity diagram) — діаграма, на якій показане розкладання деякої діяльності на її складові частини. Під діяльністю (activity) розуміється специфікація поводження, що виконується, у вигляді координованого послідовного й паралельного виконання підлеглих елементів - вкладених видів діяльності й окремих дій ( action), з'єднаних між собою потоками, які йдуть від виходів одного вузла до входів іншого.

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

Аналогом діаграм діяльності є схеми алгоритмів.

Діаграма автомата (State Machine diagram) (діаграма кінцевого автомата, діаграма станів) — діаграма, на якій представлений кінцевий автомат із простими станами, переходами й композитними станами.

Кінцевий автомат (State machine) — специфікація послідовності станів, через які проходить об'єкт або взаємодія у відповідь на події свого життя, а також відповідні дії об'єкта на ці події. Кінцевий автомат прикріплений до вихідного елемента (класу, кооперації або методу) і служить для визначення поведінки його екземплярів.[40]

Діаграма прецедентів (Use case diagram) (діаграма варіантів використання) — діаграма, на якій відбиті відносини, що існують між акторами і прецедентами.

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

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

Діаграма комунікації (Communication diagram) (в UML 1.x — діаграма кооперації, collaboration diagram) — діаграма, на якій зображуються взаємодії між частинами композитної структури або ролями кооперації. На відміну від діаграми послідовності, на діаграмі комунікації явно вказуються відносини між елементами (об'єктами), а час як окремий вимір не використовується (застосовуються порядкові номери викликів).

Діаграма послідовності (Sequence diagram) — діаграма, на якій зображене впорядковане в часі взаємодія об'єктів. Зокрема, на ній зображуються об'єкти, що беруть участь у взаємодії, і послідовність повідомлень, якими вони обмінюються.

Діаграма огляду взаємодії (Interaction overview diagram) — різновид діаграми діяльності, що включає фрагменти діаграми послідовності й конструкції потоку керування.

Діаграма синхронізації (Timing diagram) — альтернативне подання діаграми послідовності, що явно показує зміни стану на лінії життя із заданою шкалою часу. Може бути корисна в додатках реального часу.[15,40]


II. МЕТОДИЧНІ ВКАЗІВКИ

           Дисципліна “ Моделювання комп’ютерних систем ”- це теоретичні основи принципів вивчення основних понять імітаційного моделювання, ознайомлення з поняттями системи та моделі, співвідношенням між моделлю та системою, класифікацією  моделей,  видами  моделей, технологію моделювання; побудовою  імітаційної моделі персонального комп’ютера; технологічних етапів випробування та експлуатації імітаційних моделей.

Основні форми поточного контролю – спостереження за діями студентів, проведення модульного контролю.

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

III. ВИКОРИСТАНА ЛІТЕРАТУРА

1. В.Г. Кривуца, В.В. Барковський, Л.Н. Беркман. Математичне моделювання телекомунікаційних систем: Навч. посібник. –К.: Звязок, 2007.

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

___                          Срочинська Г.С.

(підпис, прізвище)

“ ____ “  _____________  2011  року

PAGE  12


 

А также другие работы, которые могут Вас заинтересовать

77101. Единство и многообразие общественной жизни 110 KB
  Представление о мире как о замкнутой сфере перенесенное на развитие общества привело к идеям согласно которым общество развивается не бесконечно а в ограниченном круге повторяя уже пройденные в определенном ритме этапы Пифагор.
77104. Отбор кадров 25.56 KB
  Чтобы правильно определить критерии отбора, следует ясно сформулировать качества работника, необходимые для соответствующего вида деятельности. Критерии следует формировать так, чтобы они всесторонне характеризовали работника: опыт, здоровье и личностные характеристики
77105. Реформи «прогресивної ери» 62.5 KB
  Міцним імпульсом, який посилив втручання держави в економіку вже в умовах мирного часу, стала світова економічна криза 30-х років. Вона поставила перед американським суспільством завдання пошуку шляхів подальшого еволюційного розвитку капіталізму...
77107. Календарные системы в Европе 216.95 KB
  За основу этого нового календаря был взят действующий календарь жрецов Египта. Юлий Цезарь его несколько изменил таким образом появился всем известный Юлианский календарь. Запретить старый календарь и ввести новый Юлианский.
77108. Реформаторская деятельность Петра І 66.17 KB
  По мнению С. Ф. Платонова, разделяемому большинством историков, Петр проводил свои реформы без четкого плана, отзываясь на первоочередные потребности. Главным стимулом его деятельности были военные нужды. Россия должна была стать мощной обороноспособной державой европейского уровня.
77109. Реформы здравоохранения в современной России 89.5 KB
  Тема, которую я собираюсь описать в данной работе, актуальна и по сей день. По мере развития общества, было создано здравоохранение. Буквально – это охрана здоровья граждан в какой-либо стране.