Diplomski - Milorad Teodorovic - Ispravljenov2

УНИВЕРЗИТЕТ У БЕОГРАДУ
ФАКУЛТЕТ ОРГАНИЗАЦИОНИХ НАУКА
ЗАВРШНИ РАД
Тема: Софтверски систем за

резервацију позоришних
представа у Јава окружењу
Ментор: Студент:
доцент Душан Савић Милорад Теодоровић 142/12
Београд, 2017
Садржај
Попис слика ........................................................................................................................ ii
Попис дијаграма ................................................................................................................ iii
1 Увод ................................................................................................................................. 1
2. Преглед коришћених технологија ................................................................................. 2
2.1 Јава програмски језик.............................................................................................. 2
2.2 Java 2 Platform, Standard Edition .............................................................................. 3
2.3 Андроид (оперативни систем) ................................................................................. 4
2.4 Netbeans IDE ............................................................................................................. 6
2.5 Android Studio ............................................................................................................ 7
2.6 Gradle build систем ................................................................................................... 8
2.7 Гит – систем за верзионисање кода ........................................................................ 8
2.7.1 Системи за контролу верзија ............................................................................ 8
2.7.2 Како је настао Гит .............................................................................................. 9
2.7.3 Верзионисање кода ........................................................................................... 9
3 Студијски пример .......................................................................................................... 12
3.1 Фаза прикупљања корисничких захтева ............................................................... 13
3.1.1 Вербални опис ................................................................................................. 13
3.1.2 Спецификација захтева помоћу модела случајева коришћења ................... 14
3.2 Фаза анализе .......................................................................................................... 21
3.2.1 Понашање софтверског система – Системски дијаграми секвенци ............ 22
3.2.2 Понашање софтверског система – Дефинисање уговора о системским
операцијама .............................................................................................................. 34
3.2.3 Структура софтверског система – Концептуални модел .............................. 36
3.2.4 Структура софтверског система – Релациони модел ................................... 37
3.3 Пројектовање .......................................................................................................... 46
3.3.1 Пројектовање корисничког интерфејса .......................................................... 47
3.3.2 Пројектовање апликационе логике ................................................................. 63
3.3.3 Пројектовање складишта података ................................................................ 68
3.3.4 Коначан изглед архитектуре софтверског система ....................................... 71
3.4 Имплементација ..................................................................................................... 72
3.5 Тестирање ............................................................................................................... 73
4. Закључак ................................................................................................................... 74
5. Литература ................................................................................................................ 75
i
Попис слика
Слика 1 Компајлирање и извршавање Јава кода[2] ........................................................ 2
Слика 2 Јава компајлирање .............................................................................................. 4
Слика 3 Далвик компајлирање .......................................................................................... 5
Слика 4 Формирање апк фајла ......................................................................................... 5
Слика 5 Верзионисање кода коришћењем Гит-а ........................................................... 10
Слика 6 Случајеви коришћења ....................................................................................... 14
Слика 7 Концептуални модел ......................................................................................... 36
Слика 8 Пословна логистика софтверског система ...................................................... 45
Слика 9 Тронивојска архитектура ................................................................................... 46
Слика 10 Структура корисничког интерфејса ................................................................ 47
Слика 11 Активност за логовање .................................................................................... 48
Слика 12 Приказ позоришта ............................................................................................ 51
Слика 13 Приказ репертоара .......................................................................................... 52
Слика 14 Грешка приликом приказа репертоара ........................................................... 53
Слика 15 Приказ детаља представе............................................................................... 54
Слика 16 Грешка приликом приказа детаља представе ............................................... 55
Слика 17 Активност за регистрацију ............................................................................... 56
Слика 18 Грешка приликом регистровања корисника ................................................... 57
Слика 19 Грешка приликом уноса постојећег корисничког имена ................................ 58
Слика 20 Резервација карата .......................................................................................... 59
Слика 21 Успешна резервација карата .......................................................................... 60
Слика 22 Грешка приликом резервације карата ............................................................ 61
Слика 23 Структура контролера корисничког интерфејса ............................................ 62
Слика 24 Апликациона логика ......................................................................................... 63
Слика 25 Архитектура софтверског система након пројектовања пословне логике ... 64
Слика 26 Класа ОпштаСО ............................................................................................... 65
Слика 27 Класе одговорне за извршавање СО наслеђују општу класу ....................... 66
Слика 28 Складиште података - Табела Participant ...................................................... 68
Слика 29 Складиште података -Табела Performance .................................................... 68
Слика 30 Складиште података - Табела Theater ........................................................... 68
Слика 31 Складиште података - Табела Setting ............................................................ 69
Слика 32 Складиште података - Табела User................................................................ 69
Слика 33 Складиште података - Табела UserPrivileges ................................................ 69
Слика 34 Складиште података - Табела Reservation .................................................... 70
Слика 35 Складиште података - Табела Repertoire ...................................................... 70
Слика 36 Складиште података - Табела Role ................................................................ 70
Слика 37 Архитектура целокупног система.................................................................... 71
ii
Попис дијаграма
Дијаграм 1 ДС1 Пријава корисника на систем ............................................................... 22
Дијаграм 2 ДС2 Приказ активних позоришта ................................................................. 23
Дијаграм 3 - ДС2 Приказ активних позоришта - Алтернативни сценарио 1 ................. 24
Дијаграм 4 ДС3 Приказ репертоара позоришта............................................................. 25
Дијаграм 5 ДС3 Приказ репертоара позоришта - Алтернативни сценарио 1 .............. 26
Дијаграм 6 Приказ детаља представе ............................................................................ 27
Дијаграм 7 ДС4 Приказ детаља представе - Алтернативни сценарио 1 ..................... 28
Дијаграм 8 ДС5 Регистрација корисника ........................................................................ 29
Дијаграм 9 ДС5 Регистрација корисника - Алтернативни сценарио 1 .......................... 30
Дијаграм 10 ДС5 Регистрација корисника - Алтернативни сценарио 2 ........................ 31
Дијаграм 11 ДС6 Резервација карата ............................................................................. 32
Дијаграм 12 ДС6 Резервација карата - Алтернативни сценарио 1............................... 33
iii
1 Увод
Мобилне апликације су апликацијски софтвери који су направљени да раде

на паметним телефонима (енгл. smartphones), таблет рачунарима и другим
мобилним уређајима. Многе мобилне апликације већ долазе инсталиране на самим
уређајима, а могу се преузети и/или актуализовати код дистрибутивних платформи
од њихових произвођача, као што су: App Store, Блекбери App World и друге,
беслатно или уз наплаћивање.[1]
Првобитно су се користиле за брзу проверу електронске поште, али је њихова
велика потражња довела до експанзије и у другим областима као што су игре
за мобилне телефоне и ГПС, разговори, гледање видео садржаја и претрага
интернета.
Тржиште мобилних апликација данас је веома развијено и налази се у сталном
порасту.
Развој мобилних апликација је доста сложен из више разлога. Наиме, мобилни
уређаји, за разлику од рачунара, поседују слабије процесоре, иако подржавају многе
операције и функционалности попут откривања локације, коришћења камере и
слично. Осим тога, мобилни уређаји долазе у доста облика, различитих резолуција,
величина екрана и конфигурација, што је узроковано јаком конкуренцијом на
мобилном тржишту.
Овим радом је представљен процес креирања софтверског система са Андроид

системом у улози клијента.
У другом поглављу се налази кратак опис технологија и окружења коришћених у
пројекту. Након тога је представљен преглед свих фаза упрошћене Ларманове
методе и њихови резултати.
У последњем поглављу је обављен кратак осврт на саму апликацију, њену улогу и
значај.
1
2. Преглед коришћених технологија
У овом поглављу ћемо обавити преглед коришћених технологија као и окружења уз
помоћ којих је пројекат реализован.
2.1 Јава програмски језик
Јава је објектно-оријентисани програмски језик који развија компанија Sun

Microsystems још од почетка 1990-их година. Јава је прављена тако да буде
платформски независна, а при том има једноставније управљање меморијом него
слични језици попут Ц или Ц++.
Сав изворни код се чува у фајловима са екстензијом .јава. Програми писани у Јава
језику се не компајлирају директно у машински код, већ се прво преводе у бајт-код
(са екстензијом .цласс), а потом се, за разлику од превођења у машински код у
сличним програмским језицима, бајт-код интерпретира користећи Јава Виртуелну
Машину (ЈВМ). На слици 1 је објашњен начин на који се обезбеђује платформска
независност, тако да се један бајт-код може извршавати на сваком оперативном
систему на коме је инсталирана Јава Виртуелна Машина.[3]
СЛИКА 1 КОМПАЈЛИРАЊЕ И ИЗВРШАВАЊЕ ЈАВА КОДА [2]
Основне карактеристике Јава програмскиг језика:

1. Објектна орјентисаност - програми су лакши за разумевање и једноставнији
јер симулирају спољашњи свет и једноставније се проширују и одржавају.
2
2. Платформска независност – "пиши једном, извршавај било где". Ова особина
омогућава да се програми писани у Јави могу компајлирати на једној
рачунарској платформи, а извршавати на другим. За разлику од неких других
језика, чији је утицај током времена постао безначајан, утицај Јаве постаје све
јачи. Кључни разлог за успех Јаве је њена прилагодљивост. Од првобитне
верзије, непрестано се прилагођава променама у окружењу за програмирање
и начину на који програмери пишу програме. Јава платформа је назив за
рачунарско окружење или платформу Сун Мицросyстемс-а у коме се може
извршити апликација која је развијена коришћењем Јава програмског језика и
скупа развојних алата. У овом случају платформа није специфичан хардвер
или оперативни систем. То је извршни механизам који је реализован преко
виртуелне машине и скупа стандардних библиотека које обезбеђују жељену
функционалност. Постоје три издања Јава платформе.[4]
То су:
• Java 2 Platform, Standard Edition ili J2SE

• Java 2 Platform, Enterprise Edition ili J2EE
• Java 2 Platform, Micro Edition ili J2ME
2.2 Java 2 Platform, Standard Edition
Ј2СЕ је развојно окружење које обезбеђује Јава АПИ (Application Programming

Interface) и алата за креирање, тестирање и извршавање Јава програма. Ј2СЕ
састоји се из два основна производа: [4]
• Java SE Runtime Environment – ЈРЕ се састоји из Јава виртуелне машине,
Ј2СЕ АПИ-а и скупа технологија, као што су нпр. Јава Wеб Старт и Јава
плагин које подржавају извршавање Јава програма. Ј2СЕ АПИ се састоји од
много технологија: Abstract Window Toolkit, Swing, Java Database Connectivity...
ЈРЕ је основа за Ј2ЕЕ технологију.
• Java SE Development Kit (JDK) – обезбеђује развојне алате (компајлере и
дибагере) за развој и тестирање Јава програма. ЈРЕ је укључен у ЈДК.
3
2.3 Андроид (оперативни систем)
Андроид је оперативни систем за мобилне платформе, који развија компанија

Гоогле. Базиран је на Линуx кернелу и првобитно му је главна примена била
имплементација на мобилним уређајима (паметни телефони и таблети) где су
корисници могли манипулисати подацима једноставним додиром екрана, међутим
након куповине од стране Гоогле компаније, бива даље развијан тако да Андроид
оперативне системе данас налазимо у телевизорима, аутомобилима, кућним
уређајима и сл.
Андроид апликације проширују могућности ''паметних'' уређаја тако што му додају
функционалности. Апликације су написане користећи Android Software Development
Kit (Android SDK) као и Java Development Kid(JDK) уз нараво Јава програмски језик у
већини случајева (могућ је развој апликација и у Котлину, Скали). [5]
Андроид је јединствен јер је open-source што омогућава јако разноврсне промене и

функционалности од стране компанија. На тај начин данас постоји јако велики број
варијација Андроид система зависно од произвођача тако да се разнолики Андроид
системи могу наћи на уређајима водећих компанија мобилне индустрије (Сони,
Самсунг, Хуавеи, …).
Најновија Андроид достигнућа откривају моћ технологије Виртуелне Реалности (ВР)
коју Гугл развија од почетка 2016. године.
Саме Андроид апликације се компалирају мало другачије него класичне Јава
апликације. Наиме, Андроид Јава код се прво преводи из .јава у .class фајлове уз
помоћ Јава компајлера (javac). Овде се огледа прва разлика јер Андроид поседује
сопствени бајт-код формат под називом Далвик.
СЛИКА 2 ЈАВА КОМПАЈЛИРАЊЕ
4
На овај начин, помоћу Dalvik dx команде, систем ће, не само .class fajlove, већ и .jar
фајлове, превести у јединствени classes.dex fajl, што је и објашњено на слици 4.
СЛИКА 3 ДАЛВИК КОМПАЈЛИРАЊЕ
На самом крају се classes.dex фајл помоћу Android Asset Packaging Tool (AAPT)
пакује u .apk фајл, приказано на слици 5, што представља финални пакет који је
спреман за дистрибуцију.
СЛИКА 4 ФОРМИРАЊЕ АПК ФАЈЛА
5
2.4 Netbeans IDE
Интегрисано развојно окружење (ИРО) је софтверска апликација која пружа

свеобухватне погодности програмерима за развој софтвера. ИРО се обично састоји
од уређивача изворног кода, уграђену аутоматизацију алатки и отклањивач грешака.
Већина модерних ИРО-а има подршку за интелигентну допуну кода.
Неки ИРО-ови садрже компајлер и интерпретатор, или оба, као што су Netbeans и
Eclipse.
Netbeans је платформа за развој апликација писаних првенствено Јава програмским
језиком иако постоји подршка и за PHP, C/C++, Python, HTML5 и други. Ова
платформа је коришћена за израду серверског дела апликације.
Поред Netbeans платформе, доступне су и бројне друге алтернативе попут Eclipse,

InteliJ IDEA Community Edition, Enide Studio, BlueJ, DrJava и други.
6
2.5 Android Studio
Базиран на JetBrains InteliJ IDEA алату, Android Studio се користи за развој Андроид
апликација почев од своје прве верзије објављене маја 2013. чиме је заменио до
тада актуелни Eclipse Android Development Tools који је до тада важио за
најстабилнију платформу за развој Андроид апликација.
Након што је преузео примат у развоју Андроид апликација, првобитно нестабилни
Android Studio, постаје једна од најбоље развијених JetBrains ИДЕ платформи.
Функционалности Android Studio-а могу се проширити инсталацијом разних додатака
па се тиме могу олакшати тестирања, верзионисање, писања апликације и слично.
Само окружење садржи јако широк спектар алата за праћење извођења апликације,
стога се могу пронаћи алати за праћење утрошка меморије уређаја, интернет проток
као и детаљни Android Device Monitor (АДМ) где је могуће пратити животне циклусе
програмских нити, као и активности и целокупног дизајна апликације.
За само тестирање Андроид апликација, Андроид Студио нуди Андроид Виртуелне
Уређаје (АВД) који може симулирати било који Андроид уређај. За комуникацију са
уређајима, Андроид Студио нуди комплетан графички интерфејс, међутим
комуникација је могућа и преко Android Debug Bridge пакета који омогућава
управљање уређајима из командне линије.
7
2.6 Gradle build систем
Билд системи представљају софтверске алате који служе да аутоматизују процес

компајлирања. Иако им је примарни циљ ефикасна израда извршних делова
апликације, често се користе и за секундарне задатке.
Међу популарнијим билд системима налазе се Make, Ant, Scons, CMake, Jam и
други.
Градле представља моћан билд систем за компајлирање, покретање апликације, као
и за управљање екстерним и интерним библиотекама које пројекат користи. Написан
је у Јава програмском језику и покреће се на ЈВМ. За разлику од претходних
претходника Апаче Мавен билд система, Градле не користи XМЛ форму већ је
заснован на систему базираном на Груви сцрипт језику као обласно-специфичном
језику (Domain-Specific language). Уз помоћ Гроовy језика, дефинишу се функције које
Градле извршава. Редослед задатака Gradle утврђује служећи се принципом
усмереног ацикличног графа. Градле упити се могу извршавати и из командне линије
оперативног система. Уз комбинацију кључних речи могуће је извршити различите
билдове пројекта различитим задацима или функцијама. Најједноставнији пример је
основна поставка Gradle функција за основне две верзије Андроид апликације
(debug и release).
2.7 Гит – систем за верзионисање кода
2.7.1 Системи за контролу верзија
Системи за контролу верзија представљају алате који служе као подршка тимовима
и појединцима у праћењу развоја и одржавању пројеката. Користећи ове системе сви
подаци су сигурнији, боља је синхронизација између чланова тима, смањује се
могућност грешке и побољшава се сам процес вођења пројекта. Постоје две врсте
система за контролу верзија – централизовани (CVCS) и дистрибуирани (DVCS).
Првој врсти припадају алати као што су СВН, Перфорце и ЦВС док у другу врсту
спадају Mercurial, Bazaar, Darcs и Git. Код CVCS сви подаци о верзијама се налазе на
централизованом серверу док клијенти имају доступну само тренутну верзију на којој
раде. Ово је свакако лакше за одржавање и администрирање али у случају отказа
овог система губе се све информације о пројекту. Код DVCS клијенти поред
последње верзије преузимају и комплетну базу о свим верзијама на том
8
репозиторијуму. У случају било каквог отказа система довољно је да један од
клијената постави податке на сервер и сви проблеми су врло брзо решени.
2.7.2 Како је настао Гит
Гит је алат који је развио Линус Торвалдс да би му олакшао вођење једног великог и
комплексног пројекта – Линукс кернела. У почетку то није био програм с данашњом
наменом, Линус је замислио да гит буде основа другим окружењима за развијање
кода. Други алати су требали развијати своје верзије на основу гита. Медутим, као с
многим другим пројектима отвореног кода, људи су га почели користити таквог какав
јесте, а он је органски растао са захтевима корисника. Резултат је програм који има
другачију терминологију у односу на друге сличне, али милиони програмера широм
света су га прихватили. Настале су бројне платформе за хостинг пројеката, као што
је Гитхаб , а већ постојећи су морали додати гит једноставно зато што су то њихови
корисници тражили (Google Code , Bitbucket , Sourceforge, па чак и Мајкрософтов
CodePlex).
2.7.3 Верзионисање кода
Код Гита као представника DVCS приликом клонирања неког репозиторијума копира
се целокупна база о пројекту а не само последња верзија. То значи да су нам
локално расположиве све верзије фајлова – од прве до последње. Будући да се сви
подаци налазе у локалу одзив је неупоредиво бржи када су нам потребне
информације о репозиторијуму и фајловима у њему. Генерално говорећи већина
операција се одвија локално без потребе за комуникацијом са сервером. Гит има
потпуно различит принцип чувања података од свих осталих система. Сваки пут када
му се подаци проследе на чување сачува се целокупно стање система, снима се тзв.
снапшот сваког фајла, приказано на слици 5. Уколико неки фајл није промењен онда
се чува показивач на његово претходно стање. Ово у пракси значи да можемо читав
систем да преузмемо у одређеној верзији.
9
СЛИКА 5 В ЕРЗИОНИСАЊЕ КОДА КОРИШЋЕЊЕМ ГИТ-А
Остали системи чувају информације о основном, првом прослеђеном фајлу, а затим

воде рачуна о променама које су се на њему десиле. За очекивати је да је простор
који заузима пројекат који је на Гит-у много већи од истог тог пројекта на СВН-у али
то није случај – напротив – много је мањи. Три главне компоненте Гит-а су
Репозиторијум (Git repository), Радни директоријум (Working directory) и Простор
припреме (Staging area).
Када неко преузме пројекат, копира му се комплетан репозиторијум. Радни

директоријум представља локални фолдер у коме мењамо и креирамо фајлове који
су обухваћени верзионисањем. Сви фајлови пре него што се комитују морају да буду
припремљени за то. Место где се они смештају јесте Простор припреме. Само они
фајлови који се налазе овде биће комитовани. Будући да Гит прави снапшот свих
фајлова приликом комита сасвим је логично постојање припремног дела јер ћемо
најпре овде смештати фајлове и на тај начин систем неће морати да прави снапшот
кад год имамо спреман неки фајл. Фајлови у Гит репозиторијуму могу имати два
стања: праћени (tracked) и непраћени (untracked).
Праћени су сви фајлови под контролом Гит-а. Они могу бити измењени,
неизмењени, и припремљени (modified, unmodified и staged).
Непраћени у оквиру репозиторијума могу бити фајлови који нису под контролом и
над њима Гит нема никаквог утицаја. Све нове фајлове које креирамо унутар или
прекопирамо у репозиторијум имају у старту овај статус. Ове фајлове само једна
команда дели од тога да постану праћени. Имамо и могућност да конфигурацијом
подесимо одређене типове фајлова које ће сам Гит по аутоматизму да игнорише.
10
Тако можемо стећи сигурност да осетљиви фајлови, који могу садржати корисничка
имена и лозинке (пример: подешавање Виртуалне Приватне Мреже у Интегрисаном
Развојном Окружењу).
Што се тиче заступљености Еклипс фондација је пријавила у свом годишњем

истраживању да је од маја 2014. године, Гит најраспрострањенији алат за
управљање изворним кодом, где 42,9% професионалних програмера наглашава да
користи Гит као њихов примарни систем контроле извора, у поређењу са 36,3% у
2013. години, 32% у 2012. години; искључујући коришћење ГитХуб -а: 33.3% у 2014.
години, 30,3% у 2013. години, 27,6% у 2012. и 12,8% у 2011. години [6.] Директоријум
отвореног кода Black Duck Open Hub извештава сличан однос међу пројектима
отвореног кода. [7]
Британски веб-сајт за послове у области информационих
технологија itjobswatch.co.uk извештава да се од краја септембра 2016. године,
29.27% од свих отворених конкурса на позиције за развој софтвера у Великој
Британији наводе Гит, [8 ] испред 12.17% за Мајкрософтов Team Foundation Server,
[9.] 10.6% за Apache Subversion, [10.] 1.3% за Меркуријал, [11] и 0.48% за Visual
SourceSafe. [12]
11
3 Студијски пример
У овом поглављу описане су фазе развоја софтвера коришћењем упрошћене

Ларманове методе. Имплементација студијског примера извршења је у претходно
описаним технологијама. Ларманова метода састоји се из следећих 5 фаза:
[4]
1. Прикупљање корисничких захтева

Ова фаза се састоји од дефинисања функционалних и нефункционалних
захтева које софтверски систем треба да задовољи. Функционални захтеви су
све захтеване функције система, које се описују моделом случаја коришћења,
док су нефункционални сви они остали захтеви као што су употребљивост,
поузданост, перформансе и подрживост система.
2. Анализа
У фази анализе се описује пословна логика софтверског система која се
састоји од структуре и понашања система. Структура система се описује преко
концептуалног (доменског) и релационог модела, док се понашање система
описује помоћу секвенцних дијаграма и системских операција.
3. Пројектовање
Описује се тронивојска архитектура софтверског система која се састоји од:
корисничког интерфејса, апликационе логике и складишта података. У оквиру
пројектовања корисничког интефејса пројектују се екранске форме и
контролер корисничког интерфејса. Пројектовање апликационе логике
подразумева пројектовање контролера апликационе логике, пословне логике и
брокера базе података. Складиште података подразумева креиране табеле и
релације, за чување ентитета.
12
4. Имплементација
У фази имплементације врши се кодирање софтверског система у неком од
програмских језика.
5. Тестирање
Тестирање је последња фаза у којој се праве тест случајеви, тест процедуре и
тест компоненте помоћу којих се врши тестирање софтверског система.
3.1 Фаза прикупљања корисничких захтева
3.1.1 Вербални опис
Потребно је креирати апликацију која ће омогућити евиденцију и резервисање места

за извођење позоришних представа (као и других догађаја) у позориштима у четири
највећа града: Београд, Нови Сад, Ниш и Крагујевац. Такође, апликација са друге
стране мора подржавати унос, измене и брисање одговарајућих представа,
позоришта, актера представе и репертоара.
Да би корисници могли добити преглед евиденције као и могућност резервације

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

Корисници са ауторским правима ће имати дозволу за измене садржаја базе.
Корисници без администраторских права имаће могућност прегледа тренутног
репертоара свих позоришта као и резервацију карата за одабрану представу.
13
3.1.2 Спецификација захтева помоћу модела случајева коришћења
Случај коришћења описује скуп сценарија, односно скуп жељених коришћења

система одстране актора. Из тога произилази да сценарио описује једно жељено
коришћење система одстране актора. Сценарио је описан преко: секвенце акција и
интеракција између актора И система. Случај коришћења се састоји из главног и
алтернативних сценарија. Сценарија дефинишу жељене фукције система које, када
се извршавају, позивају поодређеном редоследу основне функције система.
У конкретном случају идентификовани су следећи случајеви коришћења:
1. Пријава корисника на систем
2. Приказ активних позоришта
3. Приказ репертоара позоришта
4. Приказ детаља представе
5. Регистрација корисника
6. Резервација карата
СЛИКА 6 СЛУЧАЈЕВИ КОРИШЋЕЊА
14
Случај коришћења 1: Пријава корисника на систем
Назив ск: Пријава корисника на систем
Актори ск: Корисник
Учесници ск: Корисник и систем
Предуслов: Систем је укључен и приказује форму за логовање.
Основни сценарио ск:
1. Корисник уноси податке за аутентификацију корисника (АПУСО)
2. Корисник позива систем да пронађе корисника са задатим подацима (АПСО)
3. Систем претражује кориснике (СО)
4. Кориснику се омогућава приступ систему (ИА)
Alternativna scenarija
4.1. Уколико систем не може да нађе корисника, приказује кориснику форму за

регистрацију корисника (ИА)
15
Случај коришћења 2: Приказ активних позоришта
Назив ск: Приказ активних позоришта
Предуслов: Систем је укључен и приказује форму за приказ позоришта. Учитана је

листа градова.
1. Корисник бира град за приказ позоришта. (АПУСО)
2. Корисник позива систем да прикаже расположива позоришта у граду (АПСО)
3. Систем проналази изабран град и активна позоришта. (СО)
4. Систем приказује листу позоришта кориснику (ИА)
Алтернативна сценарија
4.1. Уколико систем не може да пронађе активна позоришта за изабрани град

приказује се порука ''Could not retrieve theater list'' (ИА)
16
Случај коришћења 3: Приказ репертоара позоришта
Назив ск: Приказ репертоара позоришта
Предуслов: Систем је укључен и приказује форму за приказ репертоара. Учитане су

представе изабраног позоришта. Учитана је листа свих расположивих позоришта.
1. Корисник бира позориште. (АПУСО)
2. Корисник позива систем да прикаже репертоар изабраног позоришта (АПСО)
3. Систем проналази репертоар. (СО)
4. Систем приказује листу представа у датом позоришту кориснику (ИА)
4.1. Уколико систем не може да пронађе активне представе за изабрано

позориште приказује се порука ''Could not retrieve repertoire'' (ИА)
17
Случај коришћења 4: Приказ детаља представе
Назив ск: Приказ детаља представе
Предуслов: Систем је укључен и приказује форму за приказ детаља представе.
1. Корисник позива систем да прикаже детаље изабране представе (АПСО)
2. Систем проналази представу. (СО)
3. Систем приказује кориснику детаље изабране представе репертоара. (ИА)
3.1. Уколико систем не може да пронађе детаље представе приказује се порука

''Could not retrieve performance details'' (ИА)
18
Случај коришћења 5: Регистрација корисника
Назив ск: Регистрација корисника
Предуслов: Систем је укључен и приказује форму за регистрацију корисника.
1. Корисник уноси податке потребне за регистрацију корисника (АПУСО)
2. Корисник позива систем да региструје корисника са унетим подацима (АПСО)
3. Систем чува податке о новом кориснику (СО)
4. Систем омогућава кориснику приступ систему (ИА)
4.1. Уколико систем не може да региструје корисника приказује поруку: ''Error while
registering'' (ИА)
4.2. Уколико је корисничко име већ у бази, систем приказује поруку: Username
taken, please choose other'' (ИА)
19
Случај коришћења 6: Резервација карата
Назив ск: Резервација карата
Предуслов: Систем је укључен и приказује форму за резервацију карата представе.
1. Корисник уноси податке потребне за резервацију карата (АПУСО)
2. Корисник позива систем да изврши унос резервације у систем (АПСО)
3. Систем чува податке о новој резервацији (СО)
4. Систем приказује поруку ''Reservation successful'' (ИА)
4.1. Уколико систем не може да изврши унос резервације, приказује поруку: ''Error
while reserving'' (ИА)
20
3.2 Фаза анализе
Фаза анализе описује логичку структуру и понашање софтверског система (пословну

логику софтверског система).
Понашање софтверског система је описано помоћу системских дијаграма секвенци,

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

модела.
21
3.2.1 Понашање софтверског система – Системски дијаграми секвенци
3.2.1.1 ДС1:Дијаграм секвенци случајева коришћења – Пријава корисника на систем
Д ИЈАГРАМ 1 ДС1 ПРИЈАВА КОРИСНИКА НА СИСТЕМ
Са наведених секвенцних дијаграма уочава се 1 системска операција коју треба

пројектовати:
1. Сигнал checkUserRole(User)
22
3.2.1.2 ДС2: Дијаграм секвенци случајева коришћења – Приказ активних позоришта
Д ИЈАГРАМ 2 ДС2 ПРИКАЗ АКТИВНИХ ПОЗОРИШТА
3.1. Уколико систем не може да врати листу позоришта, приказује поруку: ''Could not
retrieve theater list'' (IA)
23
ДИЈАГРАМ 3 - ДС2 ПРИКАЗ АКТИВНИХ ПОЗОРИШТА - АЛТЕРНАТИВНИ СЦЕНАРИО 1

1. Сигнал getTheaters(City city)
24
3.2.1.3 ДС3: Дијаграм секвенци случајева коришћења – Приказ репертоара позоришта
Д ИЈАГРАМ 4 ДС3 ПРИКАЗ РЕПЕРТОАРА ПОЗОРИШТА

25
ДИЈАГРАМ 5 ДС3 ПРИКАЗ РЕПЕРТОАРА ПОЗОРИШТА - АЛТЕРНАТИВНИ СЦЕНАРИО 1

2. Сигнал getRepertoire(Theater theater)
26
3.2.1.4 ДС4: Дијаграм секвенци случајева коришћења – Приказ детаља представе
ДИЈАГРАМ 6 ПРИКАЗ ДЕТАЉА ПРЕДСТАВЕ
27

ДИЈАГРАМ 7 ДС4 ПРИКАЗ ДЕТАЉА ПРЕДСТАВЕ - АЛТЕРНАТИВНИ СЦЕНАРИО 1
Sa navedenih sekvencnih dijagrama uočava se 1 sistemska operacija koju treba

projektovati:
1. Signal getParticipants(Setting setting)
28
3.2.1.5 ДС5:Дијаграм секвенци случајева коришћења – Регистрација корисника на
систем
ДИЈАГРАМ 8 ДС5 РЕГИСТРАЦИЈА КОРИСНИКА
29
ДИЈАГРАМ 9 ДС5 РЕГИСТРАЦИЈА КОРИСНИКА - АЛТЕРНАТИВНИ СЦЕНАРИО 1
30
ДИЈАГРАМ 10 ДС5 РЕГИСТРАЦИЈА КОРИСНИКА - АЛТЕРНАТИВНИ СЦЕНАРИО 2

1. Сигнал registerUser(User)
31
3.2.1.6 ДС16:Дијаграм секвенци случајева коришћења – Резервација карата
ДИЈАГРАМ 11 ДС6 РЕЗЕРВАЦИЈА КАРАТА
4.1. Уколико систем не може да изврши унос резервације, приказује поруку: ''Error
while reserving'' (ИА)
32
ДИЈАГРАМ 12 ДС6 РЕЗЕРВАЦИЈА КАРАТА - АЛТЕРНАТИВНИ СЦЕНАРИО 1
Као резултат анализе сценарија добијено је укупно 6 системских операција које

треба пројектовати:
1. Сигнал checkUserRole(User)
2. Сигнал registerUser(User)
3. Сигнал getTheaters(City)
4. Сигнал getRepertoire(Theater)
5. Сигнал getParticipants(Setting)
6. Сигнал makeReservation(Reservation)
33
3.2.2 Понашање софтверског система – Дефинисање уговора о системским
операцијама
УГОВОР УГ1: checkUserRole
Операција: checkUserRole(User): сигнал;
Веза са СК: СК1
Предуслови: Мора бити задовољено просто вредносно ограничење над објектом

User.
Структурно ограничење над објектом User мора бити задовољено.
Постуслови: /
УГОВОР УГ2: registerUser
Операција: registerUser(User): сигнал;

User.
Структурно ограничење над објектом User мора бити задовољено.
Постуслови: Корисник је сачуван у систему.
УГОВОР УГ3: getTheaters
Операција: getTheaters(City): сигнал;
Предуслови: -
Постуслови: -
УГОВОР УГ4: getRepertoire
Операција: getRepertoire (Theater): сигнал;
Веза за СК: СК3
34
УГОВОР УГ5: getParticipants
Операција: getParticipants (Setting): сигнал;
УГОВОР УГ6: makeReservation
Операција: makeReservation(Reservation): сигнал;

Reservation.
Структурно ограничење над објектом Reservation мора бити задовољено
Постуслови: Rezervacija je sačuvana u sistemu.
35
3.2.3 Структура софтверског система – Концептуални модел
Концептуални модел, који се још назива и доменски или модел објекне анализе,
садржи доменске класе и асоцијације између њих. На слици 7 дат је концептуални
модел помоћу којег је описана структура софтверског система.
СЛИКА 7 КОНЦЕПТУАЛНИ МОДЕЛ
36
3.2.4 Структура софтверског система – Релациони модел
На основу концептуалног модела са слике 7, креиран је и одговарајући релациони

модел:
Reservation (reservation_id, numberOfTickets, repertoire_id, user_id)

User (username, password, name, surname, phone, email, user_role)
UserPrivileges (username, category)
Repertoire (id_repertoire, dateAndTime, performance_id, theater_id)
Theater (id_theater, name, address, phone, city)
Performance (id_performance, performance_title, performance_description)
Setting (id_setting, participant_id, performance_id, role_id)
Participant (id_participant, name, surname)
Role (id_role, role_name)
37
Следи појединачни приказ табела из базе података као и њихових атрибута:
Табела резервација – Садржи податке о резервацијама корисника за одабране

представе.
Табела Reservation Просто вредносно Сложено вредносно Структурно

ограничење ограничење ограничење
Атрибути Име Тип Вредност Међуз. Међуз. INSERT
атрибута атрибута атрибута атрибута RESTRICTED
једне више Repertoire,
табеле табела User
Reservati Integer Not null and
on_id >0
UPDATE
numberOf Integer Not null and
Tickets >0 CASCADES
Repertoire Integer Not null and /
_ >0
id RESTRICTED
User_id String Not null Repertoire,
User
DELETE
RESTRICTED
/
38
Табела клијент – Садржи податке о регистрованим корисницима.
Табела User Просто вредносно Сложено вредносно Структурно

Атрибути Име Тип Вредност Међузав. Међузав. INSERT
једне више /
табеле табела
username String Not null UPDATE
password String Not null CASCADES
name String Not null
surname String Not null Reservation
phone String Not null RESTRICTED
email String Not null
User_role Integer Not null /
and > 0
DELETE
CASCADES
Reservation
RESTRICTED
Reservation
39
Табела корисничких привилегија – Служи за пружање привилегија корисницима у
смислу приступа систему.
Табела Просто вредносно Сложено вредносно Структурно

UserPrivileges ограничење ограничење ограничење
Атрибути Име Тип Вредност Међузав. Међузав.
атрибута атрибута атрибута атрибута INSERT /
једне више
табеле табела UPDATE
User_id Integer Not null CASCADES
and > 0
RESTRICTED
category Integer Not null
/
DELETE
RESTRICTED
/
Табела позоришта – Садржи податке о активним позориштима за градове Београд,

Нови Сад, Крагујевац и Ниш.
Табела Theater Просто вредносно Сложено вредносно Структурно

Атрибути Име Тип Вредност Међузав. Међузав. INSERT /
атрибута атрибута атрибута атрибута
једне више UPDATE
табеле табела CASCADES
theater_id Integer Not null Repertoire
and > 0
RESTRICTED
address String Not null /
phone String Not null
city String Not null
DELETE
RESTRICTED
Repertoire
40
Табела представа – Чува податке о представама на репертоару активних
позоришта.
Tabela Performance Просто вредносно Сложено Структурно

ограничење вредносно ограничење
ограничење
Performance_id Integer Not null Repertoire,
and > 0
Setting
Performance_title String Not null
Performance_description String Not null RESTRICTE
D
/
DELETE
RESTRICTE
D
Repertoire,
Setting
41
Табела поставки – Свака поставка представља триплет Учесник – Представа –
Улога, чиме се обезбеђује уникатност улога у представи.
Tabela Setting Просто вредносно Сложено Структурно

једне више Participant,
табеле табела Performance,
Id_setting Integer Not null Role
and > 0
Participant Integer Not null
_id UPDATE
Performance_id Integer Not null CASCADES
Role_id Integer Not null
/
RESTRICTED
Participant,
Performance,
Role
DELETE
RESTRICTED
/
42
Таbela Participant Просто вредносно Сложено вредносно Структурно
Id_ Integer Not null Setting
participant and > 0
RESTRICTED
surname String Not null /
DELETE
RESTRICTED
Setting
Табела улога – Представља могуће улоге учесника у представи. Тренутно су то

улоге: глумац, редитељ и музика.
Tabela Role Просто вредносно Сложено вредносно Структурно

Id_role Integer Not null Setting
and > 0
RESTRICTED
category Integer Not null
DELETE
RESTRICTED
Setting
43
Tabela repertoara – Сваки репертоар се садржи из одговарајуће представе и
позоришта у ком се дата представа одиграва.
Tabela Repertoire Просто вредносно Сложено Структурно

једне више Performance,
табеле табела Theater
Repertoire_ Integer Not null
Id and > 0
UPDATE
dateAnd Date Not null
Time CASCADES
Performance_id Integer Not null /
Theater_ Integer Not null
Id RESTRICTED
Performance,
Theater
DELETE
RESTRICTED
/
44
Као резултат анализе сценарија СК и прављења концептуалног модела добија се
логичка структура и понашање софтверског система:
СЛИКА 8 ПОСЛОВНА ЛОГИСТИКА СОФТВЕРСКОГ СИСТЕМА
45
3.3 Пројектовање
Фаза пројектовања описује физичку структуру и понашање софтверског система
(архитектуру софтверског система).
Архитектура софтверског систем је тронивојска и састоји се од следећих нивоа:
• Кориснички интерфејс
• Апликациона логика
• Складиште података
Ниво корисничког интерфејса је на страни клијента, а апликацаиона логика и

складиште података на страни сервера.
СЛИКА 9 ТРОНИВОЈСКА АРХИТЕКТУРА
46
3.3.1 Пројектовање корисничког интерфејса
Korisnički interfejs predstavlja realizaciju ulaza i/ili izlaza softverskog sistema i sastoji se
od ekranske forme i kontrolera korisničkog interfejsa.
СЛИКА 10 С ТРУКТУРА КОРИСНИЧКОГ ИНТЕРФЕЈСА
На десктоп прозорима налазе се екранске форме које прихватају податке које уноси
корисник, прихватају догађаје које уноси корисник, и позивајући клијентског
контролера те исте податке прослеђују или приказују податке пристигле од
клијентског контролера након обраде.
47
3.3.1.1 Пројектовање активности
Кориснички интерфејс је дефинисан преко скупа xмл докумената који представљају
запис елемената на активностима апликације. Сценарија коришћења тих активности
су директно повезани са сценаријима случајева коришћења.
Случај коришћења 1: Пријава корисника на систем
Назив СК: Пријава корисника на систем
Актори СК: Корисник
Учесници СК: Корисник и систем
Предуслов: Систем је укључен и приказује активност за логовање.
СЛИКА 11 АКТИВНОСТ ЗА ЛОГОВАЊЕ
48
3. Систем претражује кориснике (СО)
4.1. Уколико систем не може да нађе корисника, приказује кориснику активност за

регистрацију корисника.(ИА)
49
Случај коришћења 2: Приказ активних позоришта
Назив ск: Приказ активних позоришта
Предуслов: Систем је укључен и приказује форму за приказ позоришта. Учитана је

листа градова.
3. Систем проналази изабран град и активна позоришта. (СО)
50
СЛИКА 12 ПРИКАЗ ПОЗОРИШТА
4.1. Уколико систем не може да пронађе активна позоришта за изабрани град

приказује се порука ''Could not retrieve theater list'' (ИА)
51
Случај коришћења 3: Приказ репертоара позоришта
Назив ск: Приказ репертоара позоришта
Предуслов: Систем је укључен и приказује форму за приказ репертоара. Учитане су

представе изабраног позоришта. Учитана је листа свих расположивих позоришта.
СЛИКА 13 ПРИКАЗ РЕПЕРТОАРА
52

СЛИКА 14 ГРЕШКА ПРИЛИКОМ ПРИКАЗА РЕПЕРТОАРА
53
Случај коришћења 4: Приказ детаља представе
Назив ск: Приказ детаља представе
Предуслов: Систем је укључен и приказује форму за приказ детаља представе.
СЛИКА 15 ПРИКАЗ ДЕТАЉА ПРЕДСТАВЕ
54

СЛИКА 16 ГРЕШКА ПРИЛИКОМ ПРИКАЗА ДЕТАЉА ПРЕДСТАВЕ
55
Случај коришћења 5: Регистрација корисника
Назив ск: Регистрација корисника
СЛИКА 17 АКТИВНОСТ ЗА РЕГИСТРАЦИЈУ
Предуслов: Систем је укључен и приказује форму за регистрацију корисника.
56
Osnovni scenario sk:
СЛИКА 18 ГРЕШКА ПРИЛИКОМ РЕГИСТРОВАЊА КОРИСНИКА
57
СЛИКА 19 ГРЕШКА ПРИЛИКОМ УНОСА ПОСТОЈЕЋЕГ КОРИСНИЧКОГ ИМЕНА
58
Случај коришћења 6: Резервација карата
Назив ск: Резервација карата
Предуслов: Систем је укључен и приказује форму за резервацију карата представе.
СЛИКА 20 РЕЗЕРВАЦИЈА КАРАТА
59
СЛИКА 21 У СПЕШНА РЕЗЕРВАЦИЈА КАРАТА
60
Уколико систем не може да изврши унос резервације, приказује поруку: ''Error while
reserving'' (ИА)
СЛИКА 22 ГРЕШКА ПРИЛИКОМ РЕЗЕРВАЦИЈЕ

КАРАТА
61
3.3.1.2 Пројектовање контролера корисничког интерфејса
Контролер корисничког интерфејса се понаша као посредник између графичких
елемената корисничког интерфејса и самог софтверског система.
Он има улогу да:

• прихвати податке које шаље форма са wеб странице
• конвертује податаке (који се налазе у графичким елементима) у објекат који
представља улазни аргумент системске операције
• пошаље захтев за извршење системске операције до апликационог сервера
(софтверског система)
• прихвати објекат (излаз) софтверског система који настаје као резултат
извршења системске операције
• конвертује објекат у податке графичких елемената
СЛИКА 23 С ТРУКТУРА КОНТРОЛЕРА КОРИСНИЧКОГ ИНТЕРФЕЈСА
62
3.3.2 Пројектовање апликационе логике
У оквиру апликационе логике се пројектују контролер апликационе логике, пословна

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

система и пројектује се независно од корисничког интерфејса и обрнуто. Другим
речима, апликациона логика (која представља Модел у МВЦ патерну) нема знања о
томе где се налази кориснички интерфејс (која представља View у МВЦ патерну).
СЛИКА 24 АПЛИКАЦИОНА ЛОГИКА
Контролер је одговоран да прихвати захтев за извршење системске операције од

клијента и да га проследи до пословне логике која је одговорна за извршење
системске операције.
Део за комуникацију подиже серверски сокет који даље ослушкује мрежу. Када
клијент успостави конекцију сервер генерише нит која де бити одговорна за
двосмерну везу са клијентом. Клијент шаље захтев за извршење неке од системских
операција, клијентска нит прихвата захтев и прослеђује га до контролера
апликационе логике. Након извршења системске операције контролер врада
резултат клијентској нити . Резултат извршења операције се затим прослеђује
клијенту.
63
3.3.2.1 Контролер апликационе логике
Контролер апликационе логике прихвата захтеве за извршење системских операција

и исте прослеђују до конкретне системске операције. Након извршења системске
операције контролер прихвата одговор и враћа назад позиваоцу – клијентској нити.
Контролер је одговоран да прихвати захтев за извршење системске операције од

клијента и да га проследи до пословне логике која је одговорна за извршење
системске операције.
Како је у фазама прикупљања захтева и анализе дата спецификација структуре и

понашања софтверског система, односно спецификација пословне логике
софтверског система, следећа слика даје опис система након фаза пројектовања
комуникације са клијентима и контролера апликационе логике.
СЛИКА 25 АРХИТЕКТУРА СОФТВЕРСКОГ СИСТЕМА НАКОН ПРОЈЕКТОВАЊА ПОСЛОВНЕ ЛОГИКЕ
64
3.3.2.2 Пословна логика
Као што је већ речено, пословна логика је описана структуром коју чине доменске
класе и понашањем које се састоји из системских операција.
3.3.2.2.1 Пројектовање понашања софтверског система
Преко класе контролера прихватају се захтеви од клијента за извршавање

системских операција, које се затим прослеђују до одговарајућих класа које су
задужене за извршавање системских операција. За сваку системску операцију прави
се софтверска класа која реализује конкретну операцију.
Конкретне системске операције наслеђују апстрактну класу ''ОпштаСО'' која садржи
одговарајуће методе за повезивање са брокером базе података и извршење упита
над базом. На слици ?? је дат пример класе ОпштаСО:
СЛИКА 26 КЛАСА ОПШТАСО
У фази анализе за сваку системску операцију дефинисан је један уговор о

системским операцијама који описује шта конкретна операција треба да ради, али не
и како то ради. У фази пројектовања се за сваку системску операцију пројектује
концептуално решење које може бити представљено преко објектног псеудокода,
дијаграма сарадње, дијаграма секвенци, дијаграма активности, дијаграма прелаза
стања, или дијаграм структуре. За сваку системску операцију креирана је класа која
наслеђује класу ОпштаСО и реализује конкретну системску операцију.
65
СЛИКА 27 КЛАСЕ ОДГОВОРНЕ ЗА ИЗВРШАВАЊЕ СО НАСЛЕЂУЈУ ОПШТУ КЛАСУ
66
3.3.2.3 Брокер базе података
Класа ДбБрокер је одговорна за комуникацију између пословне логике и складишта

података и пројектује се како би се обезбедио перзистентни сервис објектима
доменских класа које се чувају у бази података. Ова класа конекцију са базом
остварује преко библиотеке com.mysql.jdbc.Driver. Класа ДбБрокер представља
перзистентни оквир који посредује у свим операцијама над базом података и
реализује следеће методе:
• connect()
• disconnect()
• commitTransaction()
• rollbackTransaction()
• closeConnection()
• insert(IGenericDomainObject obj)
• select(IGenericDomainObject obj)
• selectAll(IGenericDomainObject obj)
• selectAllWithContidion(IGenericDomainObject obj)
67
3.3.3 Пројектовање складишта података
Za projektovanje baze podataka korišćena je MySQL (Structured Query Language) baza

podataka sa sledećim tabelama:
Табела Participant:
СЛИКА 28 СКЛАДИШТЕ ПОДАТАКА - ТАБЕЛА PARTICIPANT
Табела Performance:
СЛИКА 29 СКЛАДИШТЕ ПОДАТАКА -ТАБЕЛА PERFORMANCE
Табела Theater:
СЛИКА 30 СКЛАДИШТЕ ПОДАТАКА - ТАБЕЛА T HEATER
68
Табела Setting:
СЛИКА 31 СКЛАДИШТЕ ПОДАТАКА - ТАБЕЛА S ETTING
Табела User:
СЛИКА 32 СКЛАДИШТЕ ПОДАТАКА - ТАБЕЛА U SER
Табела UserPrivileges:
СЛИКА 33 СКЛАДИШТЕ ПОДАТАКА - ТАБЕЛА U SERPRIVILEGES
69
Табела Reservation:
СЛИКА 34 СКЛАДИШТЕ ПОДАТАКА - ТАБЕЛА RESERVATION
Табела Repertoire:
СЛИКА 35 СКЛАДИШТЕ ПОДАТАКА - ТАБЕЛА REPERTOIRE
Табела Role:
СЛИКА 36 СКЛАДИШТЕ ПОДАТАКА - ТАБЕЛА ROLE
70
3.3.4 Коначан изглед архитектуре софтверског система
До сада су приказани појединачно делови софтверског система. На следећој слици

се може видети целокупна архитектура, јасна раздвојеност корисничког интерфејса,
апликационе логике и складишта података, као и начин комуникације међу њима.
СЛИКА 37 АРХИТЕКТУРА ЦЕЛОКУПНОГ СИСТЕМА
71
3.4 Имплементација
Андроид апликација настала као резултат овог рада развијена је у програмском

језику Јава. Као развојно окружење серверске стране коришћен је NetBeans IDE 8.2и
апликација се извршава на Glassfish 4.1 серверу. Као систем за управљање базом
података коришћен је MySQL уз имплементацију библиотеке за креирање и
одржавање конекције. Клијентска страна апликације развијана је у Андроид Студију.
72
3.5 Тестирање
Као последња етапа Ларманове методе вршено је тестирање.
Нису писани тест случајеви, него је тестирање извршено путем симулирања рада
корисника система. Приликом уношења вредности (како тачних тако и погрешних)
праћен је рад система као и реакција система на грешку и обрада грешке.
73
4. Закључак
На почетку рада је, након увода и кратког осврта на Јава програмски језик, дат
преглед Јавиних платформи. Даље су у раду описане одабране технологије и њихов
значај за пројектовање Андроид апликације.
Након описаних технологија, кроз студијски пример, детаљно је описан развој
софтвера уз помоћ упрошћене Ларманове методе која се састоји из пет фаза: фаза
прикупљања захтева, анализе, пројектовања, имплементације и тертирања. Свака
од ових фаза има своју сврху и крајњи резултат, што показује слика целокупне
архитектуре софтверског система која је приказана на крају.
Андроид апликације добијају све више на значају, савремено пословање се заснива

све више на интернету. То омогућава корисницима да више не морају одлазити у
продавнице или банке, већ су им све те услуге доступне на дохват руке. Приликом
пројектовања оваквих аплиакције све више технологија је на располагању
програмерима, са различитим функционалностима и перформансама, али за све
њих је заједничко да се жели постићи што боља функционалност са што мање кода.
Мобилне апликације представљају садашност, а несумњиво и будућност

софтверских система. Осим апликацијама намењених мобилним платформама, у
повоју су технологије ИоТ (InternetOfThings) што означава уређаје који су повезани
преко интернет везе, а не служе за директну обраду или презентацију података. У
преводу, ИоТ су све оне ствари од тостера, преко фрижидера све до болничких
кревета или чак јавних путева. Предвиђања су да ће ИоТ технологије у следећих
неколико година преплавити свет, смањити потребу за огромним државним
администрацијама и службеницима, сигурно ће променити наше животе. Светла ће
се палити и гасити по просторијама ако сензор региструје да је неко присутан, што
ће важити и за грејање или проветравање. Све ово ће бити оствариво захваљујући
могућности да сваком малом апарату или компликованијој машини доделимо ИП
адресу преко које ће моћи да размењује податке преко интернета.
Могућности и границе мобилних апликација су немерљиве, на нама је само прво да
научимо да користимо дату технологију тако да нам служи, а не да од нас прави
модерне робове, оптерећене још једним новитетом на тржишту, а без неке конкретне
користи.
74
5. Литература
[1] MobileApp, https://en.wikipedia.org/wiki/Mobile_app, datum pristupa Septembar 2017.
[2] Java introduction,
http://www.znanje.org/knjige/computer/Java/ib01/Java_introduction/java_about.htm,
datum pristupa Septembar 2017.
[3] Programiranje Internet Aplikacija,
http://rti.etf.bg.ac.rs/rti/ir4pia/materijali/predavanja/PIA_Lekcija4_JSF.pdf,
[4] Dr Siniša Vlajić Dušan Savić, Vojislav Stanojević, Ilija Antović, Miloš Milić,
Projektovanje softvera – napredne Java tehnologije, FON, Beograd, 2008.
[5] Android operating system, https://en.wikipedia.org/wiki/Android_(operating_system),
[6] Results of Eclipse Community Survey 2012
[7] Compare Repositories – Open Hub
[8] Git (software) Jobs, Average Salary for Git Distributed Version Control System Skills
[9] Team Foundation Server Jobs, Average Salary for Microsoft Team Foundation Server
(TFS) Skills
[10] Subversion Jobs, Average Salary for Apache Subversion (SVN) Skills
[11] Mercurial Jobs, Average Salary for Mercurial Skills
[12] VSS/SourceSafe Jobs, Average Salary for Microsoft Visual SourceSafe (VSS) Skills
75

Diplomski - Milorad Teodorovic - Ispravljenov2

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Diplomski - Milorad Teodorovic - Ispravljenov2

Uploaded by

Copyright:

Available Formats

УНИВЕРЗИТЕТ У БЕОГРАДУ

ФАКУЛТЕТ ОРГАНИЗАЦИОНИХ НАУКА

Тема: Софтверски систем за

Мобилне апликације су апликацијски софтвери који су направљени да раде

Овим радом је представљен процес креирања софтверског система са Андроид

2.1 Јава програмски језик

Јава је објектно-оријентисани програмски језик који развија компанија Sun

СЛИКА 1 КОМПАЈЛИРАЊЕ И ИЗВРШАВАЊЕ ЈАВА КОДА [2]

Основне карактеристике Јава програмскиг језика:

• Java 2 Platform, Standard Edition ili J2SE

2.2 Java 2 Platform, Standard Edition

Ј2СЕ је развојно окружење које обезбеђује Јава АПИ (Application Programming

Андроид је оперативни систем за мобилне платформе, који развија компанија

Андроид је јединствен јер је open-source што омогућава јако разноврсне промене и

СЛИКА 2 ЈАВА КОМПАЈЛИРАЊЕ

СЛИКА 3 ДАЛВИК КОМПАЈЛИРАЊЕ

СЛИКА 4 ФОРМИРАЊЕ АПК ФАЈЛА

Интегрисано развојно окружење (ИРО) је софтверска апликација која пружа

Поред Netbeans платформе, доступне су и бројне друге алтернативе попут Eclipse,

Билд системи представљају софтверске алате који служе да аутоматизују процес

2.7 Гит – систем за верзионисање кода

2.7.1 Системи за контролу верзија

2.7.2 Како је настао Гит

2.7.3 Верзионисање кода

Остали системи чувају информације о основном, првом прослеђеном фајлу, а затим

Када неко преузме пројекат, копира му се комплетан репозиторијум. Радни

Што се тиче заступљености Еклипс фондација је пријавила у свом годишњем

У овом поглављу описане су фазе развоја софтвера коришћењем упрошћене

1. Прикупљање корисничких захтева

3.1 Фаза прикупљања корисничких захтева

3.1.1 Вербални опис

Потребно је креирати апликацију која ће омогућити евиденцију и резервисање места

Да би корисници могли добити преглед евиденције као и могућност резервације

Апликација садржи засебне форме за кориснике са администраторским правима.

Случај коришћења описује скуп сценарија, односно скуп жељених коришћења

У конкретном случају идентификовани су следећи случајеви коришћења:

1. Пријава корисника на систем

2. Приказ активних позоришта

3. Приказ репертоара позоришта

4. Приказ детаља представе

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

Назив ск: Пријава корисника на систем

Актори ск: Корисник

Учесници ск: Корисник и систем

Предуслов: Систем је укључен и приказује форму за логовање.

Основни сценарио ск:

1. Корисник уноси податке за аутентификацију корисника (АПУСО)

2. Корисник позива систем да пронађе корисника са задатим подацима (АПСО)

3. Систем претражује кориснике (СО)

4. Кориснику се омогућава приступ систему (ИА)

4.1. Уколико систем не може да нађе корисника, приказује кориснику форму за

Назив ск: Приказ активних позоришта

Актори ск: Корисник

Учесници ск: Корисник и систем

Предуслов: Систем је укључен и приказује форму за приказ позоришта. Учитана је

Основни сценарио ск:

1. Корисник бира град за приказ позоришта. (АПУСО)

2. Корисник позива систем да прикаже расположива позоришта у граду (АПСО)

3. Систем проналази изабран град и активна позоришта. (СО)

4. Систем приказује листу позоришта кориснику (ИА)

4.1. Уколико систем не може да пронађе активна позоришта за изабрани град

Назив ск: Приказ репертоара позоришта

Актори ск: Корисник