Обща характеристика на езика UML. UML диаграма. Видове UML диаграми uml слой диаграма

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

Кратка история на UML

До средата на 90-те години няколко десетки методи за моделиране на ОО бяха предложени от различни автори, всеки от които използваше своя собствена графична нотация. В същото време всеки от тези методи имаше своите силни страни, но не позволи да се изгради достатъчно пълен PS модел, за да се покаже „от всички страни“, т.е. всички необходими проекции (вижте статия 1). В допълнение, липсата на стандарт за OO моделиране затруднява разработчиците да изберат най-подходящия метод, което възпрепятства широкото използване на OO подхода към разработването на софтуер.

По искане на Object Management Group (OMG) - организация, отговорна за приемането на стандарти в областта на обектните технологии и бази данни, неотложният проблем с унификацията и стандартизацията беше решен от авторите на трите най-популярни OO метода - G. Booch , Д. Рамбо и А. Джейкъбсън, които комбинираха усилия, създадоха UML версия 1.1, одобрена от OMG през 1997 г. като стандарт.

UML е език

Всеки език се състои от речник и правила за комбиниране на думи, за да се направят смислени конструкции. Така, по-специално, езиците за програмиране са подредени, като UML. Неговата отличителна черта е, че речникът на езика се формира от графични елементи. Всеки графичен символ има специфична семантика, така че модел, създаден от един разработчик, може да бъде недвусмислено разбран от друг, както и от инструмент, който интерпретира UML. От това, по-специално, следва, че PS модел, представен в UML, може да бъде автоматично преведен на OO език за програмиране (като Java, C ++, VisualBasic), тоест с добър инструмент за визуално моделиране, който поддържа UML, от изграждане на модел, ние също ще получим празен код на програмния код, съответстващ на този модел.

Трябва да се подчертае, че UML е език, а не метод. Обяснява от какви елементи да създавате модели и как да ги четете, но не казва нищо за това кои модели и в какви случаи трябва да бъдат разработени. За да създадете метод, базиран на UML, е необходимо да го допълните с описание на процеса на разработка на PS. Пример за такъв процес е Rational Unified Process, който ще бъде обсъден в следващите статии.

UML речник

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

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

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

  • Пристрастяванепоказва такава връзка между две същности, когато промяна в една от тях - независима - може да повлияе на семантиката на другата - зависима. Зависимостта е представена от пунктирана стрелка, сочеща от зависимия обект към независимия обект.
  • Асоциацияе структурна връзка, показваща, че обектите на един обект са свързани с обекти на друг. Графично асоциацията се показва като линия, свързваща свързаните обекти. Асоциациите се използват за навигация между обекти. Например асоциацията между класовете "Поръчка" и "Продукт" може да се използва за намиране на всички продукти, посочени в определена поръчка - от една страна, или за намиране на всички поръчки, които съдържат този продукт - от друга. Ясно е, че съответните програми трябва да внедрят механизъм, който осигурява такава навигация. Ако се изисква навигация само в една посока, това се обозначава със стрелка в края на асоциацията. Специален случай на асоцииране е агрегацията - връзка от формата "цяло" - "част". Графично е подчертано с ромб в края близо до цялостното цяло.
  • Обобщениее връзка между родителски обект и дъщерен обект. По същество тази връзка отразява свойството на наследяване за класове и обекти. Обобщението е показано като линия, завършваща с триъгълник, сочещ към родителския обект. Детето наследява структурата (атрибути) и поведението (методи) на родителя, но в същото време може да има нови структурни елементи и нови методи. UML позволява множествено наследяване, когато даден обект е свързан с повече от един родителски обект.
  • Внедряване- връзката между обекта, който определя спецификацията на поведението (интерфейс) с обекта, който определя изпълнението на това поведение (клас, компонент). Тази връзка обикновено се използва при моделиране на компоненти и ще бъде описана по-подробно в следващите статии.

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

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

Контролен изглед на модела. Пакети.

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

Какво предлага UML.

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

И последното…

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

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

Защо е нужна тя?

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

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

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

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

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

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

  • Идеен. В този случай UML диаграмата на класовете описва модела на конкретна предметна област и предоставя само класове от приложни обекти.
  • Специфични. Диаграмата се използва в процеса на проектиране на различни информационни системи.
  • Внедряване. Класовата диаграма включва всички видове класове, които се използват директно в програмния код.

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

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

Диаграма на композитна/композитна структура

UML съставната/композитната структурна диаграма също е статична структурна диаграма, но се използва за показване на вътрешната структура на класовете. Ако е възможно, тази диаграма може да демонстрира и взаимодействието на елементи, които са във вътрешната структура на класа.

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

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

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

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

Между артефакта и компонента, който внедрява, се формира проявление на зависимост.

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

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

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

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

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

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

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

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

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

Този изглед се нарича и малко по-различно - UML диаграма на състоянието. Има представена държавна машина с прости и съставни състояния, както и преходи.

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

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

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

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

Ако в процес на моделиране на системата се използва UML диаграма на случаи на използване, тогава анализаторът ще:

  • Ясно отделете моделираната система от нейната среда.
  • Идентифицирайте участниците, начините за тяхното взаимодействие с тази система, както и нейната очаквана функционалност.
  • Задайте в речника като предметна област различни понятия, които се отнасят до подробно описание на функционалността на тази система.

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

Комуникации

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

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

Този тип се отличава с абсолютно свободен формат за подреждане на няколко обекта и връзки по същия начин, както се прави в диаграма на обект. Ако има нужда от поддържане на реда на съобщенията в този безплатен формат, те се номерират хронологично. Четенето на тази диаграма започва с първоначалното съобщение 1.0 и впоследствие продължава по посоката, в която съобщенията се предават от един обект към друг.

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

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

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

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

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

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

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

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

Това са UML диаграми, които принадлежат към тип диаграми на дейности и включват както елементи на последователност, така и конструкции на контролен поток.

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

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

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

Какви са предимствата?

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

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

недостатъци

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

  • съкращаване. В по-голямата част от случаите критиците казват, че UML е твърде голям и сложен и често това е неоправдано. Той включва доста излишни или почти безполезни конструкции и диаграми и най-често такава критика отива към втората версия, а не към първата, тъй като в по-новите ревизии има повече „комитетски“ компромиси.
  • Различни неточности в семантиката. Тъй като UML се дефинира чрез комбинация от себе си, английски и OCL, му липсва твърдостта, която е присъща на езиците, които са точно дефинирани от формални техники за описание. В определени ситуации абстрактният синтаксис на OCL, UML и английския започват да си противоречат, докато в други случаи те са непълни. Неточността на описанието на самия език засяга както потребителите, така и доставчиците на инструменти, което в крайна сметка води до несъвместимост на инструментите поради уникалния начин, по който се третират различните спецификации.
  • Проблеми в процеса на внедряване и проучване. Всички горепосочени проблеми създават определени трудности в процеса на внедряване и изучаване на UML и това е особено вярно, когато ръководството принуждава инженерите да го използват, когато им липсват предварителни умения.
  • Кодът отразява кода. Друго мнение е, че не са важни красивите и атрактивни модели, а директно работещите системи, тоест кодът е проектът. Според това мнение има нужда от разработване на по-ефективен начин за писане на софтуер. UML се цени в подходи, които компилират модели за повторно генериране на изпълним файл или изходен код. Но в действителност това може да не е достатъчно, защото на езика липсват свойства за пълнота на Тюринг и всеки генериран код в крайна сметка ще бъде ограничен от това, което инструментът за интерпретиране на UML може да приеме или определи.
  • Несъответствие на товара. Този термин идва от теорията на системния анализ, за ​​да се определи неспособността на входа на дадена система да възприеме изхода на друга. Както при всяка стандартна нотация, UML може да представи определени системи по по-ефективен и стегнат начин от други. По този начин разработчикът е по-склонен към онези решения, които са по-удобни за вплитане на всички силни страни на UML, както и на други езици за програмиране. Този проблем е по-очевиден, ако езикът за разработка не отговаря на основните принципи на обектно-ориентираната ортодоксална доктрина, тоест не се опитва да работи в съответствие с принципите на ООП.
  • Опитва се да бъде многостранен. UML е език за моделиране с общо предназначение, който се стреми да бъде съвместим с всеки съществуващ в момента език за обработка. В контекста на конкретен проект, за да може дизайнерският екип да постигне крайната цел, е необходимо да се изберат приложимите характеристики на този език. В допълнение, възможните начини за ограничаване на обхвата на използване на 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 е създаден от хаоса около разработването на софтуер и документацията. През 90-те години имаше няколко различни начина за представяне на софтуерни системи. Имаше нужда от по-унифициран визуален UML начин за представяне на тези системи и в резултат на това беше разработен през 1994-1996 г. от трима софтуерни инженери, работещи в Rational Software. По-късно беше приет като стандарт през 1997 г. и остана такъв до днес само с няколко актуализации.

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

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

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

  1. Изявления на езика за програмиране.
  2. Актьорите описват ролята, която играе потребителят или всяка друга система, която взаимодейства с обекта.
  3. Дейностите, които трябва да бъдат извършени за изпълнение на договора за работа и да бъдат представени в диаграми.
  4. Бизнес процес, който включва набор от задачи, които създават специфична услуга за клиентите, визуализирана чрез блок-схема на последователни действия.
  5. Логически и повторно използваеми софтуерни компоненти.

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

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

Предлага се голямо разнообразие от UML инструменти за моделиране за опростяване на моделирането, включително IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner и Dia.

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

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

UML не е самостоятелен език за програмиране като Java, C++ или Python, но с правилните инструменти може да се превърне в UML псевдо-език за програмиране. За да се постигне тази цел, цялата система трябва да бъде документирана в различни диаграми и с помощта на правилния софтуер диаграмите могат директно да бъдат преведени в код. Този метод може да бъде полезен само ако времето, прекарано в чертане на диаграмите, отнема по-малко време от писането на действителния код. Въпреки че UML е създаден за системно моделиране, той е намерил няколко приложения в бизнес области.

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

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

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

Различните типове са разбити, както следва:

  1. Не всички от 14-те различни типа UML диаграми се използват редовно при документиране на системи и архитектури.
  2. Принципът на Парето се прилага и при използването на UML диаграми.
  3. 20% от диаграмите се използват от разработчиците през 80% от времето.

Най-често използваните елементи в разработката на софтуер са:

  • диаграми на използване;
  • класови диаграми;
  • последователности.

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

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

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

Крайъгълният камък на системата - използва се за анализ на изискванията за системно ниво. Тези изисквания са изразени в различни случаи на употреба. Трите основни компонента на UML диаграма са:

  1. Функционални - представени като случаи на използване.
  2. Глагол, който описва действие.
  3. Актьори – за взаимодействие със системата. Участниците могат да бъдат потребители, организации или външен иск. Отношенията между участниците са представени с прави стрелки.

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

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

Временно

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

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

Основните компоненти на времевата диаграма са:

  1. Lifeline е индивидуален член.
  2. Времева линия на състоянието - единственият жизнен път може да премине през различни състояния в рамките на един процес.
  3. Ограничение на продължителността - ограничение на времеви интервал, което представлява продължителността на ограничението, необходимо за изпълнение.
  4. Времеви лимит - Ограничаване на интервала от време, през който даден участник трябва да изпълни нещо.
  5. Поява на унищожаване - Появата на съобщение, което унищожава отделен член и изобразява края на жизнения цикъл на този член.

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

Една много проста диаграма на състоянието на машината би била в игра на шах. Типичната игра на шах се състои от ходове, направени от белите и ходове, направени от черните. Белите имат първия ход, като по този начин започват играта. Краят на играта може да настъпи независимо от това дали белите или черните печелят. Играта може да завърши с мач, отказ или равенство (различни състояния на колата). Диаграмите на състоянията се използват главно в прав и обратен UML дизайн на различни системи.

Последователен

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

За повече информация, моля, вижте примера на UML диаграма на последователност по-долу.

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

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

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

Обекти

Когато обсъждате UML структурни диаграми, трябва да се задълбочите в концепции, свързани с компютърните науки. В софтуерното инженерство класовете се считат за абстрактни типове данни, докато обектите са екземпляри.Например, ако има "Car", който е общ абстрактен тип, тогава екземплярът на класа "Car" ще бъде "Audi".

UML диаграмите на обекти помагат на разработчиците на софтуер да проверят дали генерираната абстрактна структура е жизнеспособна структура, когато се прилага на практика, т.е. когато се създават обекти. Някои разработчици смятат това за вторично ниво на проверка на точността. Той показва екземпляри на клас. По-точно, генеричният клас „Клиент“ вече има действителен клиент, например с име „Джеймс“. James е екземпляр от по-общ клас и има същите атрибути, но с дадени стойности. Същото беше направено и със сметката „Сметки и спестявания“. И двата са обекти на съответните си класове.

Внедрявания

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

Типична опростена схема за внедряване на уеб приложение ще включва:

  1. Възли (сървър на приложения и сървър на база данни).
  2. Диаграма на артефактите на клиентското приложение и базата данни.

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

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

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

Те обикновено попадат в следните основни категории:

  1. Хартия и химикал е лесно. Вземете хартия и химикал, отворете UML синтаксисен код от мрежата и начертайте какъвто тип диаграма искате.
  2. Онлайн инструменти – Има няколко онлайн приложения, които могат да се използват за създаване на диаграма. Повечето от тях предлагат платен абонамент или ограничен брой диаграми в безплатното ниво.
  3. Безплатните онлайн инструменти са почти същите като платените. Основната разлика е, че платените предлагат и уроци и готови шаблони за конкретни диаграми.
  4. Настолно приложение - Типичното настолно приложение, което да използвате за диаграми и почти всяка друга диаграма, е Microsoft Visio. Той предлага разширени функции и функционалност. Единственият недостатък е, че трябва да платите за него.

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

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

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

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

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

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

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

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

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

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

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

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

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