Паневропски универзитет АПЕИРОН

Факултет информационих технологија

Бања Лука

UNIFIED MODELING
LANGUAGE - UML

Далибор Дрљача
 Садржај

• ОСНОВНИ ПОДАЦИ UML ЈЕЗИКУ

• АСПЕКТИ UML ЈЕЗИКА
• ОСНОВНИ ЕЛЕМЕНТИ UML JEЗИКА
• ЗАКЉУЧАК
• ЛИТЕРАТУРА
ОСНОВНИ ПОДАЦИ О UML ЈЕЗИКУ
1997. „Тhe Тhree amigos“(три пријатеља) UML Partners:
Ivar Jacobson (Object-Оriented Software Engineering OOSE),
James Rumbaugh (Object-Мodeling Тechnique OMT), i
Grady Booch (Object-Оriented Design OOD)
Унифицурани
O језички (програмерски) и платформски неутралан
O примјењив у више области
O стандардан сет симбола и дијаграма

Моделовање
O омогућава креирање модела одређеног система

Језик
O користи се као визуели језик – графички симболи
и дијаграми
O има своју семантику- значење симбола и синтаксу
- правила уређивања којима се дефинише употреба
ових симбола
O Првенствена намјена - развој SW апликација
O Универзалност језика и вишеструка примјена :
O Пословни информациони системи
O Банкарске и финансијске услуге
O Телекомуникације
O Транспорт
O Одбрана/авионаутика
O Продаја
O Медицинска електроника
O Наука
O Дистрибуисане мрежне услуге
O “Тhe OMG's Unified Modeling Language™ (UML®)
helps you specify, visualize, and document models
of software systems, including their structure and
design, in a way that meets all of these
requirements. (You can use UML for business
modeling and modeling of other non-software
systems too.) Using any one of the large number of
UML-based tools on the market, you can analyze
your future application's requirements and design a
solution that meets them, representing the results
using UML 2.0's thirteen standard diagram
types.” Object Management Group (OMG)
UML

Визуелизација

Спецификовање

Конструисање

Документовање
 UML као језик за визелизовање

O Класичан приступ – програмер држи идеје у глави и

скицама на папиру
O Проблем схватања суштине процеса искључиво
посматрањем изворног кôда
O Проблем комуникације између различитих актера у
процесу развоја
O UML није само скуп графичких симбола већ иза сваког
симбола стоји добро дефинисано значење тог
симбола.
O Овим је омогућена универзалност употребе између
различитик актера у процесу развоја
UML као језик за спецификацију

O спецификовати значи изградити моделе

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

O UML није програмски језик већ ствари представља

графичком облик, док програмски језици представљају
ствари у текстуалном облику
O Модели могу бити повезани са програмским језицима -
Java, C++,Visual Basic
O инжињерство унапријед (engl. Forward engineering) -
генерисање UML модела у кôд програмског језика
O инжињерство унатраг (engl. Reverse engineering) -
реконструисање UML моделa из већ постојећег кôда
O инжињерство у круг (engl. Round-trip engineering) –
комбинација претходна два начина генерисања кôда и
модела
UML као језик за документовање

O документовање архитектуре система и

свих припадајућих детаља:
O Архитектура
O Дизајн
O Програмски кôд
O Пројектни планови
O Тестови
O Прототипови
Основни циљеви UML-a су да:
O Пружи кориснику употребљив и визуелан језик
моделовања којим је могуће развијати и размјењива-
ти моделе, односно језик за општу употребу у
моделовању;
O Моделовање система употребом ОО концепта;
O Пружи механизме проширивости и специјализације
језгра ОО концепта;
O Буде независан од осталих програмских језика, али
омогући интегрисање са осталим програмским
језицима (C++, C#, VB);
O Формализује разумијевање језика моделовања;
O Интегрише најбоље праксе ОО програмирања и
моделовања
O У зависности од тога у који дио развоја система су
укључени, корисници UML-а могу се сврстати у
следеће категорије:
O Систем-аналитичари и крајњи корисници: специфицирају
захтевану структуру и понашање система,
O Архитекте: пројектују систем који задовољава захтеве,
O Развојни инжењери (Developers): трансформишу
архитектуру у извршни код,
O Контролори квалитета (Quality Assurance Personel):
проверавају структуру и понашање система,
O Библиотекари (Librarians): креирају и каталогизирају
компоненте и
O Руководиоци пројеката (Managers): вођење и усмеравање
кадрова и управљање ресурсима.
АСПЕКТИ UML-a
O Функционални аспекти сагледавају
O структуру система (статички опис) и
O интеракцију елемената (динамички опис).

O Нефункционални аспекти сагледавају

O временске одреднице у систему, размјештања,
поузданости и др.
O Организациони аспект сагледава
O организацију и хијерархију система.

O Сваки аспект се представља са његовим

припадајућим дијаграмима који на визуелан
начин допуњују дескриптивни дио.
5 аспеката UML-a према Филипу Кушеру из ИБМ-а

АСПЕКТ АСПЕКТ
ПРОЈЕКТОВАЊА ИМПЛЕМЕНТАЦИЈЕ

АСПЕКТ СЛУЧАЈЕВА КОРИШЋЕЊА

АСПЕКТ АСПЕКТ
ПРОЦЕСА РАЗМЈЕШТАЊА
 1. АСПЕКТ ПРОЈЕКТОВАЊА
(Structural view)

O Аспект пројектовања представља на који начин је

осигурана функционалност система.
O Бави се унутрашњом функционалношћу система
O Статички опис овога аспекта даје се преко
O Дијаграма класа и
O Дијаграма објеката.
O Динамички опис се даје преко
O Дијаграма интеракција,
O Дијаграма промене стања и
O Дијаграма активности.
 2. АСПЕКТ ИМПЛЕМЕНТАЦИЈЕ
(Implementation view)
O Аспект имплементације представља компоненте и фајлове преко
којих се систем физички остварује.
O Описује главне модуле и њихове зависности, алокацију ресурса
или друге административне информације као што су извјештаји
о напретку развоја
O Статички опис овога аспекта даје се преко
O Дијаграма компоненти.
O Динамички опис се даје преко
O Дијаграма интеракција,
O Дијаграма промене стања и
O Дијаграма активности.
 3. АСПЕКТ ПОНАШАЊА-ПРОЦЕСА
(Process view)
O Описује начин одвијања процеса у систему, "нити" процеса,
конкурентност и синхронизацију.
O Описује подјелу система на процесе и процесоре
O Ово је нефункционални аспект који описује процесе и унутар
система и процесе који настају као резултат интеракције са
околином.
O За опис се користе исти дијаграми као и у аспекту пројектовања
и за статички и за динамички опис, а највише се користе
O Дијаграми активности,
O Дијаграми времена, и
O Дијаграми интеракција.
 4. АСПЕКТ РАЗМЈЕШТАЊА
(Deployment view)
O Аспект размјештања представља топологију система
O Показује се како су у овој мрежи размјештене компоненте које
представљају физичку реализацију система
O За статички опис се користе
O Дијаграми размештаја.
O За динамички опис се користе
O Дијаграми интеракција,
O Дијаграми промјене стања и
O Дијаграми активности.
 5. АСПЕКТ СЛУЧАЈЕВА КОРИШЋЕЊА
(Use cases view)

O Описује понашање система са тачке гледишта

корисника првенствено, а користи се у анализи и
тестирању.
O Представља функционалну спецификацију система.
O Статички опис даје се преко
O Дијаграма случајева коришћења,
O Динамички опис - текстуално и
O Дијаграма интеракција,
O Дијаграма промјене стања и
O Дијаграма активности.
Основни елементи UML-a
O Основни градивни елементи UML-a:
O Ствари
O Релације
O Дијаграми
O Механизми
 1. Ствари
O Ствари које се односе на структуру (engl. structural things)
O Ствари које се односе на понашање (engl. behavioral
things)
O Ствари које се односе на груписање (engl. grouping
things)
O Ствари које се односе на појашњавање (engl.
annotational things)
O СТВАРИ КОЈЕ СЕ ОДНОСЕ НА СТРУКТУРУ су именице у
UML моделима. То су најчешће статички дијелови
модела који представљају елементе који могу бити
или концептуални или физички. - класификатори (engl.
classifiers).
O У ову групу спадају:
O Класа (engl. class)
O Интерфејс (engl. interface)
O Сарадња (engl. collaboration)
O Случај коришћења (engl. use case)
O Активна класа (engl. active class)
O Компонента (engl. component)
O Артифакт (engl. artifact)
O Чвор (engl. node)
 1.1. Класа
O Концептуални или физички
дио модела Naziv klase: Student
O Представља скуп објеката
који дијеле исте атрибуте и Atribut 1 – ime
операције, релације и Atribut 2 – prezime

семантику Atribut 3 – broj indeksa

O Може имплементирати један Operacija 1- dodaj
или више интерфејса Operacija 2 - prikaži

O садржи: назив, атрибуте, Operacija 3- izmjeni

операције
 1.2. Интерфејс
O скуп операција које одређују сервисе
класе или компоненте
O потпуно или дјеломично описује „интерфејс“
видљиво понашање класе или ПРОЗОР
компоненте
O кључном ријечи „интерфејс“ изнад
назива Отвори
O атрибути нису битни, осим када се желе Затвори
Премјести
приказати константе Прикажи
O врло ријетко постоји самостално, већ
повезано са класом или компонентом
 1.3. Сарадња
O описује интеракцију објеката у реализацији неке
функције
O описује и контекст (склоп, састав) и интеракцију
O контекст показује групу објеката који сарађују заједно са
њиховим међусобним везама
O интеракција показује комуникацију објеката који сарађују
O класа или објекат могу учествовати у неколико сарадњи

Ланац
одговориности
 1.4. Случај коришћења
O Представља опис акција које систем изводи да би постигао
видљиве резултате који имају одређену вриједност за конкретног
учесника (engl. Actor)
O Даје јасан и конзистентан опис оног шта систем треба да
уради
O Представља низ крајње поједностављених описа (сценарио)
коришћења апликације или функционисања система
O Сценарио обухвата низове догађаја који могу бити иницирани од
стране корисника, неког другог система, аутоматски током
времена
O Детаљи сценарија зависе од величине ризика везаног за дотични
примјер коришћења: ризичнији случајеви изискују детаљније
сценарије

Обрада
података
 1.5. Активна класа
O Активна класа има инстанце
(примјерке) од којих свака извршава
и контролише сопствену нит Активна
O класа чији објекти имају један или класа
више процеса или нити
O иста као и „обична“ класа
O њени објекти представљају елементе
чије је понашање конкурентно с
другим елементима
 1.6. Компонента
O модуларни дио дизајна система
O енкапсулирано физичко паковање логичких
елемената као што су класе, интерфејси и сарадње
O скрива имплементацију иза скупа вањских
интерфејса
O компоненте које дијеле исти интерфејс могу
замијенити једна другу - задржано исто логичко
понашање

Форма
Наручивање
 <<компонента>>

Студенти

Компонента представљена као “black-box”

<<компонента>>

Студенти

ФИТ

ФЗН

Компонента представљена као “white-box”

 1.7. Артифакт
O физички и замјењиви дио система који садржи
физичке информације (битове) - изворне (engl.
source) или извршне (engl. run-time) информације
O представља физички комад информације која се
користи или је произведена у процесу развоја
софтвера
O датотека изворног кода, извршна датотека, скрипт
датотека и сл.

Aртифакт
Prijava_ispita.jar
 1.8. Чвор
O елемент који постоји у вријеме извршавања (engl.
run-time)
O представља рачунарски ресурс, има меморију и
могућност обраде
O у чвору може постојати група компоненти
O компоненте се могу селити с чвора на чвор
O коцкa која обично садржи само име чвора

Сервер
O СТВАРИ КОЈЕ СЕ ОДНОСЕ НА ПОНАШАЊЕ су
динамички дијелови UML модела.
O То су обично глаголи који представљају
понашање у времену и простору.
O Постоје три основне врсте ствари које се
односе на понашање:
O Интеракција (engl. interaction)
O Промјена стања (engl. state machine)
O Активност (engl. activity)
 1.9. Интеракција
O размјена порука
O обухвата скуп порука које се измјењују између групе
објеката или улога, а у склопу одређеног контекста и
у циљу извршавања специфичне сврхе
O садржи читав низ других елемената, као што су
поруке, акције, конектори (везе између објеката)

Студент
Професор
испитује
 1.10. Промјена стања
O представља стање објекта у изолацији, корак у
извршењу
O описује динамичка стања објекта или интеракције
кроз које објекат пролази током свог животног вијека
O одговор на одређене догађаје или утицаје
O када објекат детектује догађај, он одговара на начин
који зависи од његовог стања
O одговор може бити извршење акције или прелазак у
ново стање Чекање
O стање се може карактерисати на три начина.
O Као сет вриједности објекта
O Као период времена током којег објекат чека на догађај
O Као период времена током којег објекат обавља тренутну
активност
 1.11. Активност
O понашање које одређује слијед корака које
рачунарски процес треба извршити
O код активности фокус на току између корака без
обзира на то који објекат извршава који корак
O акција - корак активности

Полагање
испита
O СТВАРИ КОЈЕ СЕ ОДНОСЕ НА ГРУПИСАЊЕ су
организацијски дијелови UML модела.
O То су елементи на које се модел може разложити.
O Једна од основних таквих ствари су пакети (engl.
packages).
O општи механизам за организовање дизајна (класе
се користе за организовање елемената
имплементације)
O могуће смјестити ствари које се односе на
понашање, па чак и на груписање
O пакети су чисто концептуални, што значи да постоје
само за током развоја

Обавезни предмети
O СТВАРИ КОЈЕ СЕ ОДНОСЕ НА ПОЈАШЊАВАЊЕ су,
како им и назив каже, дијелови UML модела који
садрже појашњења.
O Основни облик је напомена (engl. note) која се веже
за неки елемент или групу елемената и поближе их
појашњава

Позвати
студентску
службу
 2. Релације
O Зависност (engl. dependency)
O Асоцијација (engl. association)
O Генерализација (engl. generalization)
O Реализација (engl. realization)
 2.1. Зависност
O веза између два елемента код које промјена на једном
елементу (независни) може утицати на други елемента
(зависни).
O однос у којем један елемент захтјева други како би
функционисао
O Зависност апстракције представља промјену нивоа апстракције
концепта, гдје је један елемент више апстрактан а други више
конкретан
O Зависност одобрења се односи на случај када је једном
елементу потребно одобрење да би користио приватни садржај
другог елемента
O Зависност коришћења се односи на случај када један елемент
користи сервисе другог
1 елемента како
1...* би имплементирао своје
стање
 Студент
одабира
Обавезни
предмети
 2.2. Асоцијација
O структурална веза између класа, гдје је линк повезаност
између објеката које су инстанце класе.
O агрегација је специјални случај асоцијације која
представља структуралну везу између цјелине и њених
дијелова
O композиција је посебан случај агрегиране асоцијације са
додатним ограничењем да објекат може бити дио само
једне цјелине
Професор Студенти

Назив асоцијације са
1 смјером читања ► 1...*
 Оцјена из предмета

Агрегација

Писмени Усмени Семинарски рад

дио испита дио испита

Завршетак
трогодишњег
школовања

Композиција

Положени испити Положени испити Положени испити

прве године друге године треће године
 2.3. Генерализација
O веза типа специјализација/генерализација код које се
специјализирани елемент (дијете елемент) изграђује на бази
спецификације генерализираног елемента (родитељ).
O дијете дијели структуру и понашање свога родитеља, али
може имати и своје атрибуте и методе..

Општа класа

Специјализована
класа
 Универзитет

Фалултет Факултет правних Факултет

информационих наука економских наука
технологија

Одсјек пословна Одсјек Одсјек Одсјек

информатика наставничла банкарство предузетништво
информатика
 2.4. Реализација
O описује структуру или понашање неког елемента без
одређивања начина имплементације
O семантичка веза између класификатора гдје један
класификатор одређује „уговор“ за који други
класификатор гарантује извршење
O ова веза се је у суштини веза између интерфејса и
класа и/или компоненти које их реализују, односно
између случаја коришћења и сарадње која их
реализује
Испит Студент
 3. Дијаграми

O UML дијаграми су специјализовани дијаграми који,

визуелно, уз помоћ стандардизованих графичких
елемената илуструју посебан дио или аспект система
O Један дијаграм, зависно од његовог садржаја, се
може користити за описивање више аспеката:
O концептуални (окренути кориснику, описује апстракцију која
се користи);
O спецификацијски (уско повезани са програм.кôдом);
O имплементацијски(уско повезани са програм.кôдом).
3.1. Дијаграми случаја коришћења
(Use Case Diagrams)

O Описују функционалност система, односно

све актере и везе које постоје међу њима -
сценарио
O Елементи: актери, везе и случај
коришћења
O Употреба за анализу система
 Студирати

Студент
 Провјери распоред
предавања

Уписати
Референт студента
<<укључити>
студентске
>
службе <<проширити>>
Пријави се за
наставу

<<укључити>
Студент >

Платити
школарину Провјерити
подобност за
преддмет
Рачуновођа

Сачини фактуру
за школарину
 3.2. Дијаграми класа
(Class Diagrams)
O Представља статичку структуру класа у
систему
O Односи међу класама:
O могу бити асоциране (повезане једна за
другу),
O могу зависити (једна класа зависи од
употребе друге класе),
O бити специјализоване (једна класа је
специјализација друге), или
O бити упаковане (груписане заједно као
јединица)
Означавање у дијаграму класа

0..1 ниједна или само једна инстанца

1 тачно једна инстанца
0..* or * ниједна или бесконачно много
инстанци
1..* једна или бесконачно много инстанци
(најмање једна инстанца)

+ Public (јавна)
# Protected (заштићена)
- Private (приватна)
~ Package (пакет)
O Агрегација
Професор Разред

+ листаСтудената:листа 1 1...* + Студенти:листа

O Асоцијација

Студент Књиге

0...* куповина 0...*

 3.3. Дијаграми објекта
(Object Diagrams)
O Слично дијаграму класа, али детаљније
O Конкретнији опис ствари тј., класа
O Употреба истих знакова и релација
O Показује комплетну или парцијалну
слику структуре моделованог система у
посебном тренутку
 Студент Компјутер

име: стринг користи процесор: стринг

старост: интеџер 0...1 1...* меморија: интеџер

Кућни:Компјутер

процесор: „Интел“
меморија: 4
Далибор:Студент

име: „Далибор Дрљача“

старост: 40
Пословни:Компјутер

Процесор: „АМД“
меморија: 2
 3.4. Дијаграм секвценце
(Sequence diagrams)
O описује како група објеката проводи процес путем
секвенцијалног сета интеракција
O паралелне вертикалне линије – линије живота –
представљају различите процесе или објекте који се
дешавају истовремено тј., симултано
O хоризонталне стрелице показују поруке које се
размјењују према реду како се и дешавају
O дијаграм секвенце приказује и интеракцију између
објеката односно оно што се дешава у одређеној
тачки рада система
O вријеме тече према доле, тј., прве интеракције се
налазе на врху дијаграма.
 3.5. Дијаграми сарадње
(Communication diagrams)
O показује више структуре него дијаграм секвенце
O дијаграм секвенце се користи у случају када је важно
нагласити секвенцу или вријеме односно када је
потребно приказати више фрагмената интеракције
O дијаграм комуникације користи када се жели нагласити
контекст, односно релације (односи, интеракција) између
објеката
O више наглашава комуникацију између објеката и начин
обављања интеракција између објеката
Студент
1:Овјерава
пријаву

2:Полаже Студентска служба

испит

Испит
 3.6. Дијаграми активности
(Activity diagrams)
O Један од најважнијих дијаграма у UML
O Приказује активности и акције које се одвијају у
систему и описује ток рада система
O Веома важан с аспекта одржавања система – лако
уочавање грешака у функционисању
O Погодан код анализе функционисања и рада
система
O Омогућава правовремено ангажовање
корективних мјера
O Састоји се од активности које могу да настану и као
реакција на неки од „окидача“ из околине система
 3.7. Дијаграм компоненти
(Component diagram)
O Приказује физичку структуру компоненти
програмског кôда
O Компоненте кôда могу бити:
O компоненте изворног кôда,
O бинарне компоненте или
O извршне компоненте

O Компоненте садрже информације о логичким

класама - креирање логичког аспекта система
O Приказује зависности између компоненти кôда и
њихову хијерархију
%
 3.8. Дијаграм распоређивања
(Deployment diagram)

O Описује хардверску структуру у систему

путем чворова и конекција
O Описује физичку повезаност хардвера и
софтвера у систему
O Представља топологију мреже (или
процеса) у систему
 4. Механизми
O Механизми дају додатне информације које се не могу
репрезентовати помоћу основних могућности које
имају елементи модела, односно служе за проширење
језика
O општи механизми:
O Спецификација (enlg. specifications)
O Украси (engl. adornments)
O Коментари (engl. comments)

O механизми проширивости:
O Стереотип (engl. stereotype)
O Означена вриједност (engl. tagged value)
O Ограничење (engl. constraint)
 4.1. Спецификација

O прецизан опис садржаја сваког елемента модела

O комплетни описи елемената - визуални приказ не
мора да садржи цијели опис
O додатна спецификација елемента модела која се не
налази на дијаграмима
O у UML алату, помоћу „specification window” форме,
спецификацији се приступа двоструким кликом на
елемент
 4.2. Украси

O Додају се дијаграму ради потпунијег приказа

елемента и разликовања

PRINTER Accountant
printer
 4.3. Коментари
O могу поставити било гдје у дијаграму
O могу да садрже било какву информацију
O не интерпретира се - нема посебног значења
O улога – даје објашњење или питање моделера
 4.4. Стереотип
O Стереоптип спречава да UML постане сувише комплексан
и да тиме изгуби универзалност
O Користи се када је потребно дефинисати недостајући
елемент модела
O Користи се за специјализацију употребе UML
омогућавајући употребу додатних графичких симбола
O Класа са стереотипом <<Window>> чита се као “класа
‘Window’ стереотипа,” што значи да је то класа ‘window’
типа.
O стереотип <<извршна>> представља извршни програм.
O стереотип <<фајл>> представља било који системски фајл и има
више поткласа.
O стереотип <<библиотека>> је поткласа од <<фајл>> која
представља статичку или динамичку библиотеку.
O стереотип <<документ>> је поткласа од << фајл >> која
показује да тај фајл садржи документацију чији садржај
интерпретира човјек а не машина.
O стереотип <<извор>> показује тип фајла који може бити
компајлиран у извршни након исправке свих грешака насталих
у компајлирању кода .
O стереотип <<script>> назначава фајл који је намјењен
машинској интерпретацији коју систем може интерпретирати
без компајлера
 4.5. Означена вриједност
O проширује особине елемената језика UML
O дозвољава додавање нових информација у
спецификацију елемената
O yносе се између знакова аколаде {} (витичасте
заграде)
O форма уноса је „name=value“
O сваки наредни унос је потребно раздвојити запетом.
 4.6. Ограничење

O Прецизира семантику и/или услове за елементе

модела
O Даје правила која ограничавају семантику једног
или више елемената
O Може бити додјељен/постављен уз класу или објекте,
а често и уз односе-релације
O Ограничава учешће класе или објекта у релацији
 Predefinisano
ograničenje

ISPORUKA * {naručeno} * PROIZVOD

{isporuka ako ≤

100kom}
 Умјесто закључка
O Моделовање је првенствено питање
комуникације и захтијева унифициран
приступ нотацији – означавању
O Објектно-оријентисана парадигма-
садашњост
O UML омогућава визеулизацију,
спецификацију, конструкцију и
документовање
 81

Хвала на пажњи !!!!