Ръководство за създаване на UML диаграми и моделиране на бази данни

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

Диаграма на профил. Това е по-скоро език, отколкото диаграма. Диаграмата на профил помага за създаването на нови свойства и семантика за UML диаграми чрез дефиниране на персонализирани стереотипи, обозначени стойности и ограничения. Тези профили ви позволяват да персонализирате UML метамодел за различни платформи (например Java Platform, Enterprise Edition (Java EE) или Microsoft .NET Framework) и домейни (например моделиране на бизнес процеси, архитектура, ориентирана към услугите, медицински приложения и др.). 

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

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

Диаграма за общ преглед на взаимодействието. Тази диаграма, която често е сложна, е подобна на диаграмата на дейността, тъй като и двете показват поредица от дейности „стъпка по стъпка“. Но диаграмата за общ преглед на взаимодействието е диаграма на дейност, съставена от различни диаграми за взаимодействие. Те използват същите анотации като при диаграма на дейност (първоначална, окончателна, решение, обединяване, разклонителна скобка и свързващи възли) с добавянето на елементи като взаимодействие, използване на взаимодействие, ограничение на времето и ограничение на продължителността. 

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

• Продължителност на живот: отделен участник 

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

• Ограничение на продължителността: време, необходимо за изпълнение на ограничение 

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

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

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

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

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

Модели на бази данни  

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

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

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

• Йерархичен модел на база данни. Стара, но добра идея – данните на този модел са организирани в структура, подобна на дърво. Дървото се състои от няколко групи, наречени сегменти. То използва релация „един към много“. Достъпът до данни също е предсказуем. 

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

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

• Релационен модел. Тук данните са структурирани с помощта на релации или математически структури, подобни на мрежата, които имат колони и редове. Това в общи линии представлява таблица. 

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

• Модел „зависимост-обект“. Той се състои от типове обекти (хора, места или неща). Показва релации, които могат да съществуват между тях. Като дефинира обектите, техните атрибути и показва релациите между тях, диаграмата „зависимост-обект“ (ER) илюстрира логическата структура на базите данни. 

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

• Модел „обект-атрибут-стойност“. В модела „обект-атрибут-стойност“ (EAV) или в схемите на отворени модели, данните се записват като три колони:  
  • Обектът (каквото се описва)  

   

  • Атрибутът или параметърът (напр. име, описание, тип данни) 

   

  • Стойността на атрибута 

• Схема „Звезда“. Това е най-простата версия на модел с измерения, в който данните са подредени във вид на измерения и факти. Използва се в бизнес разузнаването и за съхранение на данни, тъй като е подходящ за заявки към набори от големи обеми данни. 

Опростяване със софтуер 

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

• Създавате професионални диаграми с готови шаблони и хиляди фигури в „екосистемата на съдържание“, която отговаря на отрасловите стандарти като UML 2.5, както и на BPMN 2.0 и IEEE. 

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

• Сътрудничете си с други хора чрез съавторство, коментиране и анотация. 

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

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