Симулационни диаграми. UML: от теория към практика

04.09.2021

Прочетете също

Преносимо аудио оборудване (слушалки, акустика, радио) - тестове Честотна характеристика Marshall Major II Bluetooth

UML е графичен езикинструмент за моделиране с общо предназначение за спецификация, визуализация, дизайн и документиране на всички артефакти, създадени по време на разработката софтуерни системи.

Има много добри книги, които описват подробно UML (понякога дори много подробно), бих искал да събера на едно място основните понятия за диаграми, обекти и връзки между тях за бързо припомняне, нещо като измамнически лист.

Бележката използва материали от книги: Иванов Д. Ю., Новиков Ф. А. Унифициран език за моделиране UMLИ Леоненков. Урок за UML.

Да започнем с редактора. Под Linux пробвах различни UML редактори, най-много ми хареса UMLet, въпреки че е написан на Java, се движи много бързо и повечето празни обекти са в него. Има и ArgoUML, междуплатформен UML редактор, също написан на Java, функционално богат, но забавящ повече.

Спрях се на UMLet, инсталирайте го под Arch LinuxИ ubuntu:

# под Arch Linux yaourt -S umlet # под Ubuntu sudo apt-get install umlet

В UML всички обекти могат да бъдат разделени на следните типове:

структурни;
поведенчески;
групиране;
анотационен;

UML използва четири основни типа релации:

Зависимост- показва, че промяната на независимия обект засяга по някакъв начин зависимия обект. Графично връзката на зависимост се изобразява като пунктирана линия със стрелка, сочеща от зависимия обект към независимия обект.

Асоциация- има място, ако една единица е пряко свързана с друга (или с други - асоциацията може да бъде не само бинарна). Графично асоциацията се изобразява като плътна линия с различни добавки, свързващи свързани обекти.

Обобщениее връзка между две единици, едната от които е частен (специализиран) случай на другата. Графично обобщението се изобразява като линия с триъгълна незапълнена стрелка в края, насочена от конкретното (подклас) към общото (суперклас).

Реализации- релацията на изпълнение показва, че един обект е изпълнение на друг. Графично изпълнението се изобразява като пунктирана линия с триъгълна незапълнена стрелка в края, насочена от изпълняващия обект към изпълнявания.

IN UML 2дефинирани 13 типове диаграми. По стандарти всяка диаграма трябва да има граница с правоъгълник (долния десен ъгъл скосен) вляво горен ъгъл, който указва ИД на диаграмата (таг) и заглавие.

Диаграми за изобразяване на структурата на системата:

Диаграма на компонент (диаграма на компонент, етикет компонент);
Диаграма на разгръщане (диаграма на разгръщане, етикет разгръщане);
Диаграма на клас (диаграма на клас, етикет клас);
Диаграма на обект (диаграма на обект, етикет обект);
Диаграма на вътрешната структура (диаграма на съставна структура, етикет клас);

Диаграми за изобразяване на поведението на системата:

Диаграма на синхронизация (диаграма на взаимодействие, етикет синхронизация);
Диаграма на дейността (диаграма на дейността, етикет дейност);
диаграма на последователност (диаграма на последователност, етикет sd);
Комуникационна диаграма (комуникационна диаграма, етикет ком);
Диаграма на автомат (диаграма на автоматична машина, етикет държавна машина);
Диаграма за преглед на взаимодействието, етикет взаимодействие);

Графиките се открояват:

Диаграма на случаите на използване (диаграма на случаите на използване, етикет за случаи на използване);
Диаграма на опаковката (диаграма на опаковката, етикет пакет);

Диаграма на използване

Диаграма на използване(диаграма на случаи на използване) е най-общото представяне на функционалното предназначение на системата.

Разглеждайки диаграма на случаи на използване като модел на система, човек може да я асоциира с модел на черна кутия. Всеки случай на използване дефинира последователност от действия, които трябва да бъдат извършени от проектираната система, когато взаимодейства със съответния актьор.

Диаграмата на използване използва два типа основни обекти: случаи на използване и актьори, между които се установяват следните основни типове връзки.

асоциативна връзка- Тази връзка установява каква конкретна роля играе даден актьор, когато взаимодейства с екземпляр на случай на употреба. Връзката на асоцииране се обозначава с плътна линия между актьора и случая на употреба. Този ред може да има допълнителни конвенции, като име и множественост.

Релация на разширение- дефинира връзката между екземпляри на единичен случай на употреба с по-общ случай на употреба, чиито свойства се определят въз основа на начина, по който тези екземпляри се комбинират заедно. По този начин, ако има връзка на разширение от случай на употреба A към случай на употреба B, това означава, че свойствата на екземпляр на случай на употреба B могат да бъдат допълнени поради наличието на свойства в случай на разширена употреба A.

Връзка на разширение между случаи на употреба се обозначава с пунктирана линия със стрелка (случай на връзка на зависимост), сочеща встрани от случая на употреба, който е разширение на оригиналния случай на употреба.

Отношение на обобщениеслужи за указване на факта, че някакъв случай на употреба A може да се обобщи до случай на употреба B. В този случай случай на употреба A ще бъде специализация на случай на употреба B. В този случай B се нарича предшественик или родител на A и използва A е потомък на случай на употреба B използване на V.

Графично тази връзка е представена от плътна линия с отворена триъгълна стрелка, която сочи към родителския случай на употреба.

Връзка на обобщение между случаите на употреба се използва, когато е необходимо да се отбележи, че случаите на употреба деца имат всички атрибути и поведение на случаите на употреба родител.

Връзка на включванемежду два случая на употреба показва, че определено поведение за един случай на употреба е включено като компонент в последователността на поведение на друг случай на употреба.

Връзка на включване, от случай на употреба A до случай на употреба B, показва, че всеки екземпляр на случай на употреба A включва функционалните свойства, посочени за случай на употреба B.

Графично тази връзка е представена от пунктирана линия със стрелка (вариант на връзката на зависимост), сочеща от основния случай на употреба към включения случай на употреба.

класова диаграма

класова диаграма(диаграма на класове) - основният начин за описание на статичната структура на системата.

Класовата диаграма използва един основен тип обекти: класове (включително множество специални случаи на класове: интерфейси, примитивни типове, асоциативни класове и т.н.), между които се установяват следните основни типове връзки: зависимости, асоциации, обобщения, имплементации.

Отношение на зависимостобикновено показва някаква семантична връзка между два моделни елемента или две групи от такива елементи, която не е асоциация, обобщение или връзка на изпълнение. Връзката на зависимост се използва в ситуация, в която някаква промяна в един елемент на модела може да изисква промяна в друг зависим елемент на модела.

Връзката на зависимост е графично представена чрез пунктирана линия между съответните елементи със стрелка в единия край, като стрелката сочи от клиентския клас на зависимостта към независимия или изходния клас.

Над стрелката може да има специални ключови думи(стереотипи):

"достъп" - служи за указване на наличието на публични атрибути и операции на изходния клас за клиентските класове;
"bind" - клиентският клас може да използва някакъв шаблон за последващата си параметризация;
"derive" - атрибутите на клиентския клас могат да бъдат изчислени от атрибутите на изходния клас;
"импорт" - публичните атрибути и операции на изходния клас стават част от клиентския клас, сякаш са декларирани директно в него;
"refine" - показва, че клиентският клас служи като усъвършенстване на изходния клас по исторически причини, когато Допълнителна информацияв хода на проекта.

асоциативна връзкасъответства на наличието на някаква връзка между класовете. Тази връзка се обозначава с плътна линия с допълнителни специални символи, които характеризират отделните свойства на конкретна асоциация. Като допълнителен специални символиможе да се използва името на асоциацията, както и имената и множеството ролеви класове на асоциацията. Името на асоциация е незадължителен елемент от нейното обозначение.

Отношение на агрегираневъзниква между няколко класа в случай, че един от класовете е обект, който включва други обекти като компоненти. Използва се за представяне на системни връзки от типа "част-цяло".

Съставна връзкае частен случай на релация на агрегиране. Тази връзка служи за подчертаване на специална форма на връзката част-цяло, при която съставните части са в известен смисъл в рамките на цялото. Спецификата на връзката между тях се състои в това, че частите не могат да действат изолирано от цялото, т.е. с разрушаването на цялото се унищожават и всички негови съставни части.

Отношение на обобщениее връзка между по-общ елемент (родител или предшественик) и по-специфичен или специален елемент(дете или потомък). Приложено към диаграма на класове, тази връзка описва йерархичната структура на класовете и наследяването на техните свойства и поведение. Това предполага, че класът наследник има всички свойства и поведение на класа предшественик, а също така има свои собствени свойства и поведение, които не присъстват в класа предшественик.

схема на автомат

схема на автомат(диаграма на държавната машина) или диаграма на състояниетов UML 1 (диаграма на диаграмата на състоянието) е един от начините за подробно описание на поведението в UML. По същество автоматните диаграми, както подсказва името, са графики на състояния и преходи. държавна машиназареден с много допълнителни подробности и детайли.

Диаграмата на състоянието описва процеса на промяна на състоянията само на един клас или по-скоро на един екземпляр от определен клас, т.е. моделира всички възможни промени в състоянието на конкретен обект. В този случай промяната в състоянието на даден обект може да бъде причинена от външни влияния от други обекти или отвън. Използват се диаграми на състоянието, за да се опише реакцията на даден обект на такива външни влияния.

В автоматната диаграма се използва един основен тип същност - състояния, и един тип връзка - преходи, но и за двете има много разновидности, специални случаи и допълнителни обозначения. Автоматът представя динамичните аспекти на симулираната система под формата на насочен граф, чиито върхове съответстват на състояния, а дъгите съответстват на преходи.

Първоначално състояниепредставлява специален случайсъстояние, което съдържа не вътрешни действия(псевдосъстояния). Обектът е в това състояние по подразбиране в началния момент от време. Той служи за указване на диаграмата на състоянието на графичната област, от която започва процеса на промяна на състоянията.

Окончателен (окончателен)състояние е частен случай на състояние, което също не съдържа никакви вътрешни действия (псевдосъстояния). Обектът ще бъде в това състояние по подразбиране след завършване на автомата в крайния час.

диаграма на дейността

Когато се моделира поведението на проектирана или анализирана система, става необходимо не само да се представи процесът на промяна на нейните състояния, но и да се уточнят подробно характеристиките на алгоритмичното и логическо изпълнение на операциите, извършвани от системата.

диаграма на дейността(диаграма на дейността) е друг начин за описване на поведение, което визуално наподобява добра стара блок-схема на алгоритъм. Използва се за симулиране на процеса на извършване на операции.

Основната посока на използване на диаграми на дейности е визуализиране на характеристиките на изпълнението на операциите на класа, когато е необходимо да се представят алгоритми за тяхното изпълнение.

В диаграмата на активността се използват един основен тип същности – действие, и един тип връзка – преходи (прехвърляне на управление). Използват се и такива конструкции като вилици, сливания, връзки, разклонения. Препоръчва се като име просто действиеизползвайте глагол с обяснителни думи.

диаграма на последователността

диаграма на последователността(диаграма на последователност) е начин за описване на поведението на системата "чрез примери".

Всъщност диаграмата на последователността е запис на протокола на определена сесия на системата (или фрагмент от такъв протокол). В обектно-ориентираното програмиране най-същественото нещо по време на изпълнение е предаването на съобщения между взаимодействащи обекти. Това е последователността на изпращане на съобщения, която се показва на тази диаграма, откъдето идва и името.

В диаграмата на последователността се използва един основен тип същности – екземпляри на взаимодействащи си класификатори (основно класове, компоненти и актьори), и един тип взаимоотношения – връзки, чрез които се обменят съобщения.

Възможни типове съобщения (изображението е взето от larin.in):

Комуникационна диаграма

Комуникационна диаграма(комуникационна диаграма) - начин за описание на поведението, семантично еквивалентен на диаграма на последователност. Всъщност това е същото описание на последователността за обмен на съобщения на взаимодействащи екземпляри на класификатори, само изразено с други графични средства.

По този начин в комуникационната диаграма, както и в диаграмата на последователността, се използват един основен тип същности - екземпляри на взаимодействащи класификатори и един тип отношения - връзки. Тук обаче акцентът не е върху времето, а върху структурата на взаимоотношенията между конкретни инстанции.

Диаграма на компонентите

Диаграма на компонентите(компонентна диаграма) - показва връзката между модулите (логически или физически), които изграждат симулираната система.

Основният тип обект в диаграмата на компонентите са самите компоненти, както и интерфейсите, чрез които се посочва връзката между компонентите. В диаграмата на компонентите се прилагат следните отношения:

имплементации между компоненти и интерфейси (компонентът имплементира интерфейса);
зависимости между компоненти и интерфейси (компонентът използва интерфейс);

Диаграма на поставяне

Диаграма на поставяне(диаграма на разгръщане), заедно с показването на състава и връзките на системните елементи, показва как те са физически поставени върху изчислителните ресурси по време на изпълнение.

В диаграмата на разположение, в сравнение с диаграмата на компонента, се добавят два типа обекти: артефакт, който е имплементация на компонента и възел (може да бъде или класификатор, който описва типа възел, или конкретен екземпляр), както и асоциативна връзка между възли, показваща, че възлите са физически свързани по време на изпълнение.

Диаграма на обекта

Диаграма на обекта(обектна диаграма) - е екземпляр на класова диаграма.

В обектната диаграма се използва един основен тип същности: обекти (инстанции на клас), между които са посочени специфични връзки (най-често инстанции на асоциация). Обектните диаграми са от спомагателен характер - всъщност това са примери (може да се каже, изхвърляния на паметта), които показват какви обекти съществуват и връзките между тях в определен момент от работата на системата.

Диаграма на вътрешната структура(диаграма на съставна структура) се използва за по-подробно представяне на структурни класификатори, предимно класове и компоненти.

Структурен класификатор е показан като правоъгълник с името на класификатора в горната част. Вътре има части. Може да има няколко части. Частите могат да взаимодействат една с друга. Това се показва от различни видове съединители. Мястото на външния ръб на частта, към която е прикрепен конекторът, се нарича порт. Портовете също са разположени на външната граница на структурния класификатор.

Диаграма за преглед на взаимодействието(обзорна диаграма на взаимодействие) е вид диаграма на дейността с разширен синтаксис: като елементи на обща диаграма на взаимодействие могат да действат връзки към взаимодействия (използване на взаимодействие), определени от диаграми на последователности.

Времева диаграма

Времева диаграма(времева диаграма) е специална форма на диаграма на последователност, в която се обръща специално внимание на промяната в състоянията на различни екземпляри на класификатори и тяхната времева синхронизация.

Диаграма на опаковката

Диаграма на опаковката(пакетна диаграма) е единственият инструмент, който ви позволява да управлявате сложността на самия модел.

Основните елементи на нотацията са пакети и зависимости с различни стереотипи.

Модел субект-връзка (ER-модел)

аналогов класови диаграми(UML) може да бъде ER модел, който се използва при проектирането на бази данни (релационен модел).

Моделът на субект-връзка (ER-модел) е модел на данни, който ви позволява да опишете концептуалните схеми на предметната област. ER моделът се използва при проектиране на база данни от високо ниво (концептуален). С негова помощ можете да маркирате ключовите обекти и да посочите връзките, които могат да бъдат установени между тези обекти. уикипедия

Всеки фрагмент от предметната област може да бъде представен като набор от обекти, между които има набор от връзки.

Основни понятия:

Същност(субект) е субект, който може да бъде идентифициран по някакъв начин, който го отличава от други субекти, например, КЛИЕНТ 777. Един обект всъщност е набор от атрибути.

Набор от обекти(entity set) - набор от обекти от един и същи тип (с еднакви свойства).

Връзка(връзка) е асоциация, установена между множество обекти.

Домейн(домейн) - набор от стойности (домейн) на атрибута.

Има три вида двоични връзки:

едно към едно- единичен екземпляр на обект от един клас е свързан с единичен екземпляр на обект от друг клас, например РЪКОВОДИТЕЛ – ОТДЕЛ;
1 до Nили един към много- единичен екземпляр на обект от един клас е свързан с много екземпляри на обект от друг клас, например ОТДЕЛ - СЛУЖИТЕЛ;
N до Mили много към много- много екземпляри на обект от един клас са свързани с много екземпляри на обект от друг клас, например СЛУЖИТЕЛ - ПРОЕКТ;

Речник на основните понятия в UML

обект- образувание, което има уникалност и капсулира състоянието и поведението.

клас- описание на набор от обекти с общи атрибути, определящи състояние и операции, определящи поведение.

интерфейс- наименуван набор от операции, който определя набор от услуги, които могат да бъдат заявени от потребителя и предоставени от доставчика на услуги.

Сътрудничество- набор от обекти, които си взаимодействат за постигане на някаква цел.

актьор- субект, който е извън моделираната система и директно взаимодейства с нея.

компонент- модулна част от системата с добре дефиниран набор от необходими и предоставени интерфейси.

Артефакт- елемент от информация, който се използва или генерира по време на процеса на разработка софтуер. С други думи, артефактът е физическа единица на изпълнение, получена от моделен елемент (като клас или компонент).

Възел- изчислителен ресурс, върху който се поставят артефакти и, ако е необходимо, се изпълняват.

Поведенческите субекти имат за цел да опишат поведението. Има само две основни поведенчески единици: състояние и действие.

състояние- период от жизнения цикъл на обект, в който обектът отговаря на определено състояние и извършва собствена дейност или чака настъпването на някакво събитие.

действие- примитивно атомно изчисление.

машинае пакет, който дефинира набор от концепции, необходими за представяне на поведението на моделирания обект като дискретно пространство с краен брой състояния и преходи.

класификаторе дескриптор за набор от обекти от същия тип.

Допълнително четене

Фаулър М. UML. Основи, 3-то издание
Буч Г., Рамбо Д., Джейкъбсън И. UML език. Упътване за употреба

UML сега е стандартната нотация за визуално моделиране на софтуерни системи, приета от Object Managing Group (OMG) през есента на 1997 г. и поддържана от много обектно-ориентирани CASE продукти.

Стандартът UML предлага следния набор от диаграми за моделиране:

Диаграма на случаите на използване (диаграма на случаи на използване) - за моделиране на бизнес процесите на организация или предприятие и определяне на изискванията към създаваната информационна система;

диаграма на класове (диаграма на класове) - за моделиране на статичната структура на класовете на системата и връзките между тях;

диаграма на поведение на системата (диаграми на поведение);

диаграми на взаимодействие;

Диаграми на последователности - за моделиране на процеса на обмен на съобщения между обекти в рамките на един use case;

диаграма на сътрудничество (диаграма на сътрудничество) - за моделиране на процеса на обмен на съобщения между обекти в рамките на един и същи случай на използване;

statechart diagram - за моделиране поведението на системните обекти при преход от едно състояние към друго;

диаграма на активността - за моделиране на поведението на системата в рамките на различни случаи на използване или дейности по моделиране;

диаграма на внедряване (диаграми на внедряване):

Диаграми на компоненти (диаграми на компоненти) – за моделиране на йерархията на компоненти (подсистеми) на информационна система;

диаграма на разгръщане (диаграма на разгръщане) - за моделиране на физическата архитектура на проектираната информационна система.

На фиг. 1.1 представя интегриран модел на информационната система, включително основните диаграми, които ще бъдат разработени в този курсов проект.

Ориз. 1. Интегриран модел на информационна система в нотацията на езика UML

4.2. Диаграма на случаите на използване

Случаят на използване е поредица от действия, извършвани от системата в отговор на събитие, задействано от някакъв външен обект (актор). Случаят на употреба описва типично взаимодействие между потребител и система. В най-простия случай случаят на използване се определя в процеса на обсъждане с потребителя на функциите, които той би искал да внедри в тази информационна система. В UML случай на използване е изобразен, както следва:

Фиг.2. Случай на употреба

Актьорът е роля, която потребителят играе по отношение на системата. Актьорите представляват роли, а не конкретни хора или длъжности. Въпреки че са изобразени като стилизирани човешки фигури в диаграми на случаи на употреба, актьорът може да бъде и външен. информационна система, който се нуждае от информация от дадената система. Трябва да показвате актьори в диаграма само когато те наистина се нуждаят от някои случаи на употреба. В UML актьорите са представени като форми:

Фиг.3. персонаж (актьор)

Актьорите са разделени на три основни типа:

Потребители

системи;

Други системи, взаимодействащи с тази;

Времето става актьор, ако от него зависи задействането на някакви събития в системата.

4.2.1. Връзки между случаите на употреба и актьорите

В UML диаграмите за случаи на използване поддържат няколко типа връзки между елементите на диаграмата:

Комуникация (комуникация),

Включване (включва),

разширение (разширяване),

обобщение.

комуникация комуникацияе връзката между случая на употреба и актьора. В UML комуникационните връзки се показват с помощта на еднопосочна асоциация (плътна линия).

Фиг.4. Пример за комуникационна връзка

Включване връзкаизползвани в ситуации, в които има част от системното поведение, което се повтаря в повече от един случай на употреба. С помощта на такива връзки обикновено се моделира функция за многократна употреба.

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

Фиг.5. Пример за връзка на включване и разширение

Комуникационна генерализацияпоказва, че няколко актьори или класове имат общи свойства.

Фиг.6. Пример за обобщаваща връзка

4.3.

Диаграми на взаимодействиеописват поведението на взаимодействащи групи от обекти. Обикновено диаграмата на взаимодействие обхваща само поведението на обекти в рамките на един случай на употреба. Такава диаграма показва редица обекти и съобщенията, които те обменят помежду си.

съобщениее средството, чрез което обектът изпращач изисква от обекта получател да изпълни една от неговите операции.

Информационно (информативно) съобщениее съобщение, което предоставя на получаващия обект информация за актуализиране на неговото състояние.

Съобщение за заявка (въпросително)е съобщение, изискващо извеждане на някаква информация за обекта получател.

Императивно съобщениее съобщение, което изисква от получателя да извърши някакво действие.

Има два типа диаграми на взаимодействие: диаграми на последователност и диаграми на сътрудничество.

4.3.1. Диаграми на последователности

диаграма на последователносттаотразява потока от събития, възникващи в рамките на един случай на употреба.

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

В диаграмата на последователността обектът се изобразява като правоъгълник, от който се изчертава пунктирана линия надолу. вертикална линия. Тази линия се нарича спасителна линия на обект . Това е фрагмент от жизнения цикъл на даден обект в процеса на взаимодействие.

Всяко съобщение е представено като стрелка между жизнените линии на два обекта. Съобщенията се появяват в реда, в който се показват на страницата отгоре надолу. Всяко съобщение е маркирано поне с името на съобщението. По желание можете също да добавите аргументи и известна контролна информация. Можете да покажете самоделегиране, съобщение, което даден обект изпраща до себе си, като стрелката на съобщението сочи към същата спасителна линия.

Ориз. 7. Пример за диаграма на последователност

4.3.2. Диаграма на сътрудничество

Диаграми на сътрудничествопоказване на потока от събития в рамките на конкретен сценарий (случай на използване). Съобщенията са подредени по време, въпреки че диаграмите за сътрудничество се фокусират повече върху връзките между обектите. Диаграмата на сътрудничество показва цялата информация, която има диаграма на последователност, но диаграмата на сътрудничество описва потока от събития по различен начин. От него е по-лесно да се разберат връзките, които съществуват между обектите.

В диаграма за сътрудничество, точно както в диаграма на последователност, стрелките представляват съобщенията, които се обменят в рамката. тази опцияизползване. Тяхната времева последователност е обозначена чрез номериране на съобщенията.

Ориз. 8. Пример за диаграма на сътрудничество

4.4. класова диаграма

4.4.1. Главна информация

класова диаграмадефинира типовете системни класове и различни видове статични връзки, които съществуват между тях. Диаграмите на класове също показват атрибути на класа, операции на класа и ограничения, които са поставени върху връзките между класовете.

Класовата диаграма в UML е граф, чиито възли са елементите на статичната структура на проекта (класове, интерфейси), а дъгите са връзките между възлите (асоциации, наследяване, зависимости).

Класовата диаграма показва следните елементи:

· Пакет (package) – набор от елементи на модела, логически свързани помежду си;

· Клас (class) - описание на общи свойства на група подобни обекти;

· Интерфейс (interface) - абстрактен клас, който определя набор от операции, които обект от произволен клас, свързан с даден интерфейс, предоставя на други обекти.

4.4.2. Клас

Класе група от субекти (обекти), които имат подобни свойства, а именно данни и поведение. Отделен член на клас се нарича обект на класа или просто обект.

Поведението на обект в UML се отнася до всички правила за взаимодействие на обект с външния свят и с данните на самия обект.

В диаграмите класът се изобразява като правоъгълник с плътна граница, разделен с хоризонтални линии на 3 секции:

Горната секция (секция с име) съдържа името на класа и други общи свойства (по-специално стереотипа).

Средната секция съдържа списък с атрибути

В долната част има списък с операции на класа, които отразяват неговото поведение (действия, извършвани от класа).

Нито един от разделите за атрибути и операции може да не се показва (или и двете). За липсващия раздел не е необходимо да рисувате разделителна линия и по някакъв начин да посочите наличието или отсъствието на елементи в него.

Допълнителни раздели, като например Изключения, могат да бъдат въведени по преценка на конкретна реализация.

Ориз. 9. Пример за диаграма на клас

4.4.2.1.Класови стереотипи

Стереотипизирането на класа е механизъм за класифициране на класовете в категории.

UML дефинира три основни класови стереотипа:

Граница (граница);

Субект (субект);

Контрол (управление).

4.4.2.2.Гранични класове

Граничните класове са тези класове, които са разположени на границата на системата и цялото заобикаляща среда. Това са дисплеи, отчети, интерфейси с хардуер (като принтери или скенери) и интерфейси с други системи.

За да намерите гранични класове, трябва да проучите диаграмите на случаите на използване. Всяко взаимодействие между актьор и случай на употреба трябва да има поне един граничен клас. Именно този клас позволява на актьора да взаимодейства със системата.

4.4.2.3.Класове на обекти

Класовете обекти съдържат съхранена информация. Те имат най-голямо значение за потребителя и затова в наименованията им често се използват термини от предметната област. Обикновено за всеки клас обект се създава таблица в базата данни.

4.4.2.4.Контролни часове

Контролните класове отговарят за координирането на действията на другите класове. Обикновено всеки случай на употреба има един контролен клас, който контролира последователността от събития за този случай на употреба. Контролният клас отговаря за координацията, но не носи никаква функционалност сам по себе си, тъй като другите класове не го изпращат Голям бройсъобщения. Вместо това самият той изпраща много съобщения. Класът мениджър просто делегира отговорността на други класове, поради което често се нарича клас мениджър.

Може да има други контролни класове в системата, които са общи за няколко случая на употреба. Например, може да има клас SecurityManager, отговорен за наблюдение на събития, свързани със сигурността. Класът TransactionManager управлява координацията на съобщенията, свързани с транзакциите в базата данни. Може да има други мениджъри, които да се занимават с други елементи от работата на системата, като споделяне на ресурси, разпределена обработка на данни или обработка на грешки.

В допълнение към стереотипите, споменати по-горе, можете да създадете свои собствени.

4.4.2.5.Атрибути

Атрибутът е информация, свързана с клас. Атрибутите съхраняват капсулирани данни за клас.

Тъй като атрибутите се съдържат в класа, те са скрити от други класове. Поради това може да се наложи да посочите кои класове имат право да четат и променят атрибути. Това свойство се нарича видимост на атрибута.

Атрибутът може да има четири възможни стойности за този параметър:

Публично (общо, открито). Тази стойност за видимост предполага, че атрибутът ще бъде видим за всички други класове. Всеки клас може да преглежда или променя стойността на атрибут. В съответствие с UML нотацията общият атрибут се предхожда от знак "+".

Частен (затворен, секретен). Съответният атрибут не е видим за никой друг клас. Частният атрибут се обозначава със знак "-" в съответствие с UML нотацията.

Защитен (защитен). Такъв атрибут е достъпен само за самия клас и неговите наследници. UML нотацията за защитен атрибут е знакът "#".

Пакет или внедряване (партида). Да приемем, че даденият атрибут е споделен, но само в неговия пакет. Този тип видимост не се обозначава със специална икона.

С помощта на затвореност или сигурност е възможно да се избегне ситуацията, когато стойността на атрибута се променя от всички класове на системата. Вместо това логиката за модификация на атрибута ще бъде обвита в същия клас като самия атрибут. Опциите за видимост, които задавате, ще повлияят на генерирания код.

4.4.2.6.Операции

Операциите реализират свързано с класа поведение. Операцията има три части - име, параметри и тип на връщане.

Параметрите са аргументите, които операцията получава като вход. Типът връщане се отнася до резултата от действието на операцията.

Диаграмата на класа може да показва както имената на операциите, така и имената на операциите заедно с техните параметри и тип на връщане. За да се намали натоварването на диаграмата, е полезно на някои от тях да се показват само имената на операциите, а на други - пълният им подпис.

В UML операциите имат следната нотация:

Име на операция (аргумент: тип данни на аргумент, аргумент2: тип данни на аргумент2,...): тип връщане

Има четири различни вида операции, които трябва да се вземат предвид:

Операции по внедряване;

Управленски операции;

Операции за достъп;

Спомагателни операции.

Операции по внедряване

Операциите на внедрителя изпълняват някои бизнес функции. Такива операции могат да бъдат намерени чрез изследване на диаграми на взаимодействие. Диаграми от този тип се фокусират върху бизнес функции и всяко съобщение в диаграмата най-вероятно може да бъде свързано с операция по внедряване.

Всяка операция по внедряване трябва лесно да се проследи до съответното изискване. Това се постига на различни етапи от симулацията. Операцията се извлича от съобщението в диаграмата на взаимодействие, от което идват съобщенията Подробно описаниепоток от събития, който се създава въз основа на случая на използване, а последният се основава на изискванията. Възможността да се проследи цялата тази верига помага да се гарантира, че всяко изискване е внедрено в кода и всяка част от кода изпълнява някакво изискване.

Управленски операции

Операциите на мениджъра управляват създаването и унищожаването на обекти. Конструкторите и деструкторите на класове попадат в тази категория.

Операции за достъп

Атрибутите обикновено са лични или защитени. Други класове обаче понякога трябва да преглеждат или променят своите стойности. За това има операции за достъп. Този подход прави възможно безопасното капсулиране на атрибути в клас, защитавайки ги от други класове, но все пак им позволява да бъдат контролиран достъп. Създаването на операции Get и Set (получаване и промяна на стойност) за всеки атрибут на клас е стандарт.

Спомагателни операции

Спомагателни (помощни операции) са тези операции на даден клас, които са му необходими, за да изпълни своите отговорности, но за които другите класове не трябва да знаят нищо. Това са частни и защитени класови операции.

За да идентифицирате транзакции, направете следното:

1. Изследване на диаграми на последователност и кооперативни диаграми. Повечето от съобщенията в тези диаграми са операции по внедряване. Светлоотразителните съобщения ще бъдат спомагателни операции.

2. Помислете за контролни операции. Може да се наложи да добавите конструктори и деструктори.

3. Обмислете операциите за достъп. За всеки атрибут на клас, с който другите класове ще трябва да работят, трябва да създадете операции Get и Set.

4.4.2.7.Връзки

Връзката е семантична връзка между класове. Той дава възможност на класа да научи за атрибутите, операциите и връзките на друг клас. С други думи, за да може един клас да изпрати съобщение до друг в последователност или кооперативна диаграма, трябва да има връзка между тях.

Има четири типа връзки, които могат да бъдат установени между класовете: асоциации, зависимости, агрегации и обобщения.

Комуникационна асоциация

Асоциацията е семантична връзка между класове. Те са начертани на класовата диаграма като обикновена линия.

Ориз. 10. Комуникационна асоциация

Асоциациите могат да бъдат двупосочни, както в примера, или еднопосочни. В UML двупосочните асоциации се изчертават като проста линия без стрелки или със стрелки от двете страни на линията. Еднопосочна асоциация има само една стрелка, показваща нейната посока.

Посоката на асоциацията може да се определи чрез изследване на диаграми на последователности и кооперативни диаграми. Ако всички съобщения в тях се изпращат само от един клас и се получават само от друг клас, но не и обратното, между тези класове има еднопосочна комуникация. Ако поне едно съобщение е изпратено в обратната посока, връзката трябва да е двупосочна.

Асоциациите могат да бъдат рефлексивни. Рефлексивната асоциация означава, че един екземпляр от клас взаимодейства с други екземпляри от същия клас.

Комуникационна зависимост

Отношенията на зависимост също отразяват връзката между класовете, но те винаги са еднопосочни и показват, че един клас зависи от дефиниции, направени в друг. Например клас A използва методи от клас B. Тогава, когато клас B се промени, е необходимо да се направят съответните промени в клас A.

Зависимостта е представена чрез пунктирана линия, начертана между два елемента на диаграмата, а елементът, закотвен в края на стрелка, се казва, че е зависим от елемента, закотвен в началото на тази стрелка.

Ориз. 11. Комуникационна зависимост

При генериране на код за тези класове няма да се добавят нови атрибути към тях. Въпреки това ще бъдат създадени специфичните за езика оператори, необходими за поддържане на комуникацията.

Комуникационно агрегиране

Агрегациите са по-тясна форма на асоцииране. Агрегацията е връзката между цялото и неговата част. Например, може да имате клас автомобил, както и класове двигател, гума и класове за други части на автомобила. В резултат на това обект от клас Car ще се състои от обект от клас Engine, четири обекта от Tyres и т.н. Агрегациите се визуализират като линия с ромб за клас, който е цяло число:

Ориз. 11. Комуникационно агрегиране

В допълнение към простото агрегиране, UML въвежда по-силна форма на агрегиране, наречена композиция. Според композицията част от предмета може да принадлежи само към едно цяло и освен това, като правило, жизнен цикълчасти съвпада с цикъла на цялото: те живеят и умират с него. Всяко премахване на цялото се разпростира върху неговите части.

Това каскадно изтриване често се счита за част от определението за агрегиране, но винаги се подразбира, когато множествеността на ролите е 1..1; например, ако даден клиент трябва да бъде изтрит, тогава това изтриване трябва да се разпространи към поръчките (и на свой ред редовете за поръчки).

UML или Unified Modeling Language е език за графично описание за моделиране на обекти в областта на разработката на софтуер. Но използването на UML не се ограничава до ИТ, друга голяма област на практическо приложение на UML е моделирането на бизнес процеси, системния дизайн и картографирането на организационните структури. UML позволява на разработчиците на софтуер да се споразумеят за графична нотация за представяне. общи понятияи се фокусира върху дизайна и разработката.

Предимства на UML

UML използва графични символи за елементите на моделираната система, а UML диаграмите са сравнително лесни за разбиране;
UML дава възможност да се опишат системи от почти всяка възможна гледна точка, като се вземат предвид различни аспекти;
UML е обектно-ориентиран: неговите методи за анализ и конструиране са семантично близки до методите за програмиране, използвани в съвременните ООП езици;
UML е отворен стандарт. Стандартът се развива и еволюира от версия във версия, отговаряйки на най-съвременните изисквания за описание на системи;
съдържа механизъм за разширение, който ви позволява да въвеждате допълнителен текст и графични видове, което прави възможно използването на UML не само в сферата на ИТ.

Видове UML диаграми

В UML има 14 типа диаграми. Те могат да бъдат разделени на 2 категории:

структуренпредставляващ информационна структура;
поведенчески, представящи поведението на системата и различни аспекти на взаимодействията. Отделен подвид диаграми на поведение са диаграми на взаимодействие.

Йерархия на типовете UML диаграми,
представена чрез класова диаграма

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

класова диаграмае ключов елемент в обектно-ориентираното моделиране. С помощта на тази диаграма (всъщност чрез класове, техен атрибути, методии зависимости между класове) описва модела на домейна и структурата на моделираната система.
Диаграма на компонентитепоказва разделянето на програмния код на големи блокове (структурни компоненти) и показва зависимостимежду тях. Компонентите могат да бъдат пакети, модули, библиотеки, файлове и др.
обектна диаграмапоказва пълно или частично изрязване на симулираната система в даден момент от време. Той представлява екземпляри на клас (обекти), тяхното състояние ( текущи стойностиатрибути) и връзката между тях.
Диаграма на съставна структурадемонстрира вътрешната структура на класовете и, ако е възможно, взаимодействията между елементите на тази структура.
Диаграма на опаковкатапоказва пакетите и връзките между тях. Този тип диаграма служи за опростяване на структурата на модела (и съответно на работата с него) чрез комбиниране на елементите на модела в групи по определени критерии.
Диаграма на разполаганевнедряване на модели софтуерни компоненти (артефакти) върху изчислителни ресурси/хардуерни компоненти ( възли).
Диаграма на профилаописва механизъм за разширяване, който позволява UML да бъде адаптиран към различни предметни области и области на дейност.

Пример за UML диаграма на клас

Диаграми на поведение

диаграма на дейносттапоказва действия ( действия), от които някои дейности ( дейност). Диаграмите на активността се използват за моделиране на бизнес процеси, технологични процеси, серийни и паралелни изчисления.
Диаграма на случаите на използване(или диаграма на случаите на използване) описва връзката между актьори (актори) и случаи на използване на симулираната система (нейните възможности). Основната цел на диаграмата е да бъде универсален инструмент за клиенти, разработчици и крайни потребители, с помощта на който да може съвместно да се обсъжда системата - нейните възможности и поведение.
Диаграма на състояниетоизобразява динамичното поведение на даден обект, показвайки как този обект, в зависимост от текущото си състояние, реагира на различни събития. Всъщност това е диаграма на състоянието от теорията на атомите.
Комуникационна диаграма(В ранни версии диаграма на сътрудничество) показва взаимодействията между частите на съставната структура и ролите на сътрудничеството. Диаграмата изрично показва връзката между елементите (обектите).
диаграма на последователносттаизползвани за визуализиране на последователността от взаимодействия на обекти. Показва жизнения цикъл на даден обект и взаимодействието на актьорите (актьори) в рамките на някакъв случай на използване, последователността от съобщения, които те обменят.
Диаграма за преглед на взаимодействиетовключва част от диаграмата на последователността и конструкцията на контролния поток. Помага да се разгледа взаимодействието на обектите от различни гледни точки.
Времева диаграма- отделен подвид диаграми на взаимодействие, специализирани във времето. Диаграмите от този тип се използват за изследване на поведението на обекти за определен период от време.

Мисля, че всеки е чувал в детството такава поговорка като " Седем пъти мери режи един път". В програмирането е същото. Винаги е по-добре да мислите за внедряването, преди да отделите време за изпълнението му. Често трябва да създавате класове по време на изпълнението, да измисляте тяхното взаимодействие. И често визуалното представяне на това може да помогне за решаването на проблема по най-правилния начин.Тук помагаме UML.

Какво е UML?

Ако погледнете снимките в търсачки, става ясно, че UML- това е нещо за схеми, стрелки и квадрати. Важното е, че UML се превежда като унифициран език за моделиране. Думата Unified е важна тук. Това означава, че нашите снимки ще бъдат разбрани не само от нас, но и от други, които познават UML. Оказва се, че това е такъв международен език за рисуване на диаграми.

Както казва Wikipedia

UML е език за графично описание за моделиране на обекти в областта на разработката на софтуер, моделиране на бизнес процеси, системно инженерство и картографиране на организационни структури.

Най-интересното нещо, за което не всеки мисли или се досеща е, че UML има спецификации. Освен това има дори UML2 спецификация. Повече информация за спецификацията можете да намерите на уебсайта на Object Management Group. Всъщност тази група се занимава с разработването на UML спецификации. Интересно е също, че UML не се ограничава до описание на структурата на класовете. Има много видове UML диаграми. Кратко описание на типовете UML диаграми можете да видите в същата Wikipedia: UML диаграми или във видеото на Тимур Батиршинов Преглед на UML диаграми. UML също се използва широко при описване на различни процеси, например тук: Единично влизане с помощта на JWT. Връщайки се към използването на UML диаграми на класове, заслужава да се отбележи книгата Head First: Design Patterns, в която моделите са илюстрирани от същите тези UML диаграми. Оказва се, че UML наистина се използва. И се оказва, че познаването и разбирането на приложението му е доста полезно умение.

Приложение

Нека да видим как можете да работите с този UML от IDE. Като IDE, вземете IntelliJ Идея. Ако използвате IntelliJ Idea Ultimate, тогава ще инсталираме приставката „извън кутията“ Поддръжка на UML". Позволява ви автоматично да генерирате красиви диаграми на класове. Например чрез Ctrl + N или елемента от менюто "Навигация" -> "Клас" отидете на класа ArrayList. Сега, през контекстно менюпо име на клас изберете "Диаграма" -> "Покажи изскачащ прозорец на диаграма". В резултат на това получаваме красива диаграма:

Но какво ще стане, ако искате да нарисувате себе си и дори няма Ultimate версия на Idea? Ако използваме IntelliJ Idea Community Edition, тогава нямаме друг избор. За да направите това, трябва да разберете как работи такава UML схема. Първо трябва да инсталираме Graphviz. Това е набор от помощни програми за визуализация на графики. Използва се от плъгина, който ще използваме. След инсталирането трябва да добавите директория кошчеот инсталираната директория graphviz V променлива на средатазаобикаляща среда ПЪТЕКА. След това в IntelliJ Idea изберете File -> Settings от менюто. В прозореца „Настройки“ изберете категорията „Добавки“, щракнете върху бутона „Преглед на хранилища“ и инсталирайте приставката за интегриране на PlantUML. Защо този е толкова добър PlantUML? Той използва език за описание на графики, наречен " точка" и това му позволява да бъде по-гъвкав, т.к даден езикне се използва само PlantUML. Освен това всичко, което ще направим по-долу, можем да направим не само в IDE, но и в онлайн услуга planttext.com. След като инсталираме приставката PlantUML, ще можем да създаваме UML диаграми чрез "Файл" -> "Ново". Нека създадем диаграма на "UML клас". По време на това автоматично се генерира шаблон с пример. Нека изтрием съдържанието му и създадем свое собствено, въоръжени със статия от Habr: Класови отношения - от UML до код. И за да разберем как да изобразим това в текста, нека вземем ръководството за PlantUML: plantuml class-diagram. В него в самото начало има табличка с описание на връзките:

За самите връзки все още можем да надникнем тук: "Връзки между класове в UML. Примери". Въз основа на тези материали, нека започнем да създаваме нашата UML диаграма. Добавете следното съдържание, описващо двата класа: @startuml клас ArrayList ( ) клас LinkedList ( ) @enduml За да видите резултата в Idea, изберете "Преглед" -> " Инструмент Windows" -> "PlantUML". Ще получим само два квадрата, обозначаващи класове. Както знаем, и двата класа реализират интерфейса List. Тази връзка на класовете се нарича имплементация (реализация). Стрелка с пунктирана линия се използва за изобразяване такава връзка.Нека я нарисуваме: интерфейс List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о частен пакет element array: ~ Object elementData Сега искаме да покажем, че ArrayList съдържа някои обекти. В този случай типът на връзката ще бъде - агрегиране(обединяване). Агрегатът в този случай е ArrayList, защото съдържа други обекти. Ние избираме агрегиране, защото обектите в списъка могат да живеят без списъка: те не са неразделна част от него. Техният живот не е обвързан с живота на списъка. Единицата от латински се превежда като "събрана", тоест нещо, съставено от нещо. Например в живота има помпена единица, която се състои от помпа и двигател. Самото устройство може да бъде разглобено, оставяйки някои от компонентите му. Например да продадете или поставите друга единица. Значи е в списъка. И това се изразява под формата на празен ромб в единицата и непрекъсната линия. Нека го кажем по следния начин: class Object () ArrayList o- Object Сега искаме да покажем, че за разлика от ArrayList, класът LinkedList съдържа Node - контейнери, които препращат към съхранени данни. В този случай възлите са част от самия LinkedList и не могат да живеят отделно. Node не е директно съхранено съдържание, а съдържа само препратка към него. Например, когато добавим ред към LinkedList, добавяме нов възел, който съдържа връзка към този ред, както и връзка към предишния и следващия възел. Този тип връзка се нарича състав(композиция). За да се покаже композит (такъв, който се състои от части), се изчертава запълнен робик, непрекъсната линия води до него. Сега нека напишем това като текстово показване на връзката: class Node ( ) LinkedList * -- Node И сега трябва да научим как да показваме друг важен тип връзка - пристрастяване(отношение на зависимост). Използва се, когато един клас използва друг, като класът не съдържа използвания клас и не е негов наследник. Например LinkedList и ArrayList могат да създадат ListIterator. Нека покажем това като пунктирани стрелки: клас ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

Можете да детайлизирате колкото е необходимо. Всички обозначения са изброени тук: "PlantUML - Диаграма на класове". Освен това няма нищо свръхестествено в рисуването на такава схема и когато работите върху задачите си, можете бързо да я нарисувате на ръка. Това ще развие уменията за обмисляне на архитектурата на приложението и ще помогне да се идентифицират недостатъците в структурата на класа на ранен етап, а не след като вече сте прекарали един ден в внедряване на грешен модел. Мисля, че това е добра причина да опитате?)

Автоматизация

Яжте различни начиниавтоматично генериране на PlantUML диаграми. Например в идеиИма плъгин SketchIT, но не ги рисува правилно. Например внедряването на интерфейси е начертано неправилно (показва се като наследство). Има и примери онлайн за това как да вградите това в жизнения цикъл на компилация на вашия проект. Да кажем за Мейвънима пример с използване на uml-java-doclet. За да покажем как е, ще използваме архетипа на Maven, за да бързо създаванепроект maven. Нека изпълним командата: mvn archetype:generate По въпроса за избора на филтър ( Изберете номер или приложете филтър) оставете по подразбиране, като просто натиснете Enter. Винаги ще бъде" maven-archetype-бърз старт". Избираме най-новата версия. След това отговорете на въпросите и завършете създаването на проекта:

Тъй като Maven не е фокусът на тази статия, отговорите на вашите въпроси относно Maven могат да бъдат намерени в Центъра за потребители на Maven. В генерирания проект отворете файла с описание на проекта за редактиране, pom.xml. Ще копираме съдържанието от описанието на инсталирането на uml-java-docklet в него. Артефактът, използван в описанието, не може да бъде намерен в централното хранилище на Maven. Но това работи за мен с това: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. Тоест в това описание просто трябва да замените groupIdс " info.leadinglight" На " com.chfourie"и сложи версия" 1.0.0 ". След това можем да изпълним в директорията, където се намира файлът pom.xmlтези команди са: mvn clean install и mvn javadoc:javadoc. Сега, ако отворим генерираната документация (explorer target\site\apidocs\index.html), ще видим UML диаграми. Между другото, внедряването вече е показано правилно тук)

Заключение

Както можете да видите, UML ви позволява да визуализирате структурата на вашето приложение. Освен това UML не се ограничава само до това. С помощта на UML можете да опишете различни процеси във вашата компания или да опишете бизнес процеса, в рамките на който работи функцията, която пишете. От вас зависи да решите доколко UML е полезен за вас лично, но все пак ще е полезно да намерите време и да го опознаете по-подробно. #Viacheslav Руска версия на тази публикация: UML диаграма Java на CodeGym

всичко UML диаграмимогат условно да се разделят на две групи, първата от които е общи диаграми. Общите диаграми са практически независими от предмета на моделиране и могат да се използват във всеки софтуерен проект без оглед на предметната област, областта на вземане на решения и т.н.

1.5.1. Диаграма на използване

Диаграмата на използване има за цел да отговори на основния въпрос за моделиране: какво прави системата във външния свят?

В диаграмата на използване се използват два типа основни обекти: случаи на използване 1 и актьори 2, между които се установяват следните основни типове връзки:

асоциация между актьор и случай на използване 3;
обобщение между актьорите 4 ;
обобщение между случаите на използване 5 ;
зависимости ( различни видове) между случаите на употреба 6 .

Диаграмата на използване, както всяка друга, може да има коментари 7 . Освен това силно се препоръчва да направите това, за да подобрите четливостта на диаграмите.

Основните елементи на обозначението, използвано в диаграмата на използване, са показани по-долу. Подробно описаниедадени в раздел 2.2.

1.5.2. класова диаграма

класова диаграма(диаграма на класове) е основният начин за описание на структурата на системата.

Това не е изненадващо, тъй като UML е предимно обектно-ориентиран език и класовете са основният (ако не и единственият) градивен елемент.

В диаграмата на класовете се използва един основен тип обекти: класове 1 (включително множество специални случаи на класове: интерфейси, примитивни типове, асоциативни класове и много други), между които са установени следните основни типове връзки:

асоциация между класове 2 (с много допълнителни подробности);
обобщение между класовете 3 ;
зависимости (от различни видове) между класове 4 и между класове и интерфейси.

Някои елементи от нотацията, използвана в класовата диаграма, са показани по-долу. Подробно описание е дадено в глава 3.

1.5.3. схема на автомат

схема на автомат(диаграма на държавна машина) е един от начините за подробно описание на поведението в UML въз основа на изричното разпределение на състоянията и описанието на преходите между състоянията.

По същество автоматните диаграми, както подсказва името, са графика на прехода на състоянието (вижте Глава 4), заредена с много допълнителни детайли и подробности.

В автоматната диаграма се използват един основен тип същности - състояния 1 , и един тип релации - преходи 2 , но и за двата са дефинирани множество разновидности, специални случаи и допълнителни обозначения. Изброяването им всички в уводен преглед няма смисъл.

Подробно описание на всички варианти на автоматни диаграми е дадено в раздел 4.2, а следващата фигура показва само основните елементи на нотацията, използвана на автоматната диаграма.

1.5.4. диаграма на дейността

диаграма на дейността(диаграма на активността) - начин за описване на поведение въз основа на индикацията на контролни потоци и потоци от данни.

Диаграмата на активността е друг начин за описване на поведение, който визуално наподобява добра стара блок-схема. Въпреки това, благодарение на модернизираната нотация, съобразена с обектно-ориентирания подход, и най-важното, поради новия семантичен компонент (свободна интерпретация на мрежите на Петри), UML диаграмата на дейност е мощен инструмент за описание на поведението на системата.

В диаграмата на активността се използват един основен тип обекти - действие 1 и един тип връзка - преходи 2 (трансфери на контрол и данни). Също така се използват такива конструкции като разклонения, сливания, връзки, разклонения 3 , които са подобни на обекти, но всъщност не са, а са графичен начин за изобразяване на някои специални случаи на многоместни връзки. Семантиката на елементите на диаграмата на активността е разгледана подробно в Глава 4. Основните елементи на нотацията, използвана в диаграмата на активността, са показани по-долу.

1.5.5. диаграма на последователността

диаграма на последователността(диаграма на последователност) е начин за описване на поведението на системата въз основа на индикацията за последователността на предаваните съобщения.

В диаграмата на последователността се използва един основен тип същности – екземпляри на взаимодействащи си класификатори 1 (главно класове, компоненти и актьори), и един тип взаимоотношения – връзки 2 , чрез които се обменят съобщения 3 . Има няколко начина за изпращане на съобщения, които в графичен запис се различават под формата на стрелка, съответстваща на релация.

Важен аспект на диаграмата на последователността е изричното показване на изтичането на времето. За разлика от други типове диаграми, с изключение може би на диаграмите за синхронизация, в диаграмата на последователността има значение не само наличието на графични връзки между елементите, но и относителната позиция на елементите върху диаграмата. А именно, счита се, че има (невидима) времева ос, по подразбиране насочена отгоре надолу, а съобщението, което се изпраща по-късно, е нарисувано отдолу.

Времевата ос може да бъде насочена хоризонтално, като в този случай се счита, че времето тече отляво надясно.

Следващата фигура показва основните елементи на нотацията, използвана в диаграма на последователност. За обозначаване на самите взаимодействащи обекти се използва стандартната нотация - правоъгълник с името на екземпляр на класификатор. Пунктирана линия, излизаща от нея, се нарича линия на живота (lifeline) 4 . Това не е обозначение на връзка в модела, а графичен коментар, предназначен да насочи читателя на диаграмата в правилната посока. Фигурите под формата на тесни ленти, насложени върху линията на живота, също не са изображения на симулирани същности. Това е графичен коментар, показващ продължителността на времето, през което даден обект притежава събитие за изпълнение 5 или с други думи се извършва активиране на обект. Стъпките на комбинирано взаимодействие (комбиниран фрагмент) 6 позволяват диаграмата на последователността да отразява алгоритмичните аспекти на протокола за взаимодействие. Вижте глава 4 за повече подробности относно нотацията на диаграмата на последователността.

1.5.6. Комуникационна диаграма

Комуникационна диаграма(комуникационна диаграма) - начин за описание на поведението, семантично еквивалентен на диаграма на последователност.

Всъщност това е същото описание на последователността за обмен на съобщения на взаимодействащи екземпляри на класификатори, само изразено с други графични средства. Освен това повечето инструменти могат автоматично да преобразуват диаграми на последователности в комуникационни диаграми и обратно.

По този начин в комуникационната диаграма, както и в диаграмата на последователността, се използват един основен тип същности - екземпляри на взаимодействащи класификатори 1 и един тип отношения - връзки 2 . Тук обаче акцентът не е върху времето, а върху структурата на взаимоотношенията между конкретни инстанции.

Фигурата показва основните елементи на нотацията, използвана в комуникационната диаграма. За обозначаване на самите взаимодействащи обекти се използва стандартната нотация - правоъгълник с името на екземпляр на класификатор. Взаимното разположение на елементите на диаграмата на сътрудничество няма значение – важни са само връзките (най-често случаи на асоциации), по които се предават съобщения 3 . За показване на реда на съобщенията във времето се използва йерархично десетично номериране.

1.5.7. Диаграма на компонентите

Основният тип обекти в диаграмата на компонентите са самите компоненти 1 , както и интерфейсите 2 , чрез които се посочва връзката между компонентите. В диаграмата на компонентите се прилагат следните отношения:

имплементации между компоненти и интерфейси (компонентът имплементира интерфейса);
зависимости между компоненти и интерфейси (компонентът използва интерфейс) 3 .

Фигурата показва основните елементи на нотацията, използвана в компонентната диаграма. Подробно описание е дадено в глава 3.

1.5.8. Диаграма на поставяне

По този начин в диаграмата на разположение, в сравнение с диаграмата на компонентите, се добавят два типа обекти: артефакт 1, който е имплементацията на компонент 2 и възел 3 (може да бъде или класификатор, описващ типа на възела, или конкретен екземпляр), както и асоциативна връзка между възли 4, което показва, че възлите са физически свързани по време на изпълнение.

Фигурата показва основните елементи на нотацията, използвана в диаграмата за поставяне. За да се покаже, че един обект е част от друг, се използва или връзка на зависимост „разгръщане“ 5, или формата на един обект се поставя във формата на друг обект 6 . Подробно описание на диаграмата е дадено в глава 3.