menadzment is - ada ciganlija

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

БЕОГРАД

СЕМИНАРСКИ РАД

Управљање развојем софтвера за мерење квалитета воде у куплалиштима ЈП „Ада Циганлија“ у функцији одрживог развоја

Предмет: Менаџмент информационих система

Ментор: Студент: проф. др Небојша Денић Дејан Јовановић

Семинарски рад Садржај

Садржај: 1 УВОД ...................................................................................................................................................................... 3

2 ПЛАВА ЗАСТАВА И ЊЕНА ПРИМЕНА У АНАЛИЗИ КВАЛИТЕТА ВОДЕ ................................................................... 4

3 МЕТОДОЛОГИЈЕ ПЛАНИРАЊА ИНФОРМАЦИОНИХ СИСТЕМА ............................................................................ 5

3.1 ИНФОРМАЦИОНИ СИСТЕМ ............................................................................................................................................ 5 3.2 РАЗВОЈ МЕТОДОЛОГИЈЕ ИНФОРМАЦИОНИХ СИСТЕМА ....................................................................................................... 6 3.3 ОБЈЕКТНО-ОРИЈЕНТИСАНЕ МЕТОДОЛОГИЈЕ РАЗВОЈА ИНФОРМАЦИОНИХ СИСТЕМА .............................................................. 10

3.3.1 Основни концепти објектно-оријентисаног приступа ......................................................................... 10 3.3.1.1 Објекат .....................................................................................................................................................................10 3.3.1.2 Изолација .................................................................................................................................................................11 3.3.1.3 Класа.........................................................................................................................................................................11 3.3.1.4 Удруживање ............................................................................................................................................................12 3.3.1.5 Комуникација ..........................................................................................................................................................13 3.3.1.6 Полиморфност .........................................................................................................................................................13 3.3.1.7 Наслеђивање ...........................................................................................................................................................13

3.3.2 Јединствени језик за моделовање - UML ................................................................................................. 15 3.3.2.1 UML – основни облици ...........................................................................................................................................15

3.3.3 Јединствени процес развоја софтвера .................................................................................................... 18 3.3.3.1 Кључне активности у процесу ................................................................................................................................19 3.3.3.2 Главне фазе процеса ...............................................................................................................................................22

3.4 ПЛАНИРАЊЕ ИНФОРМАЦИОНОГ СИСТЕМА КОРИШЋЕЊЕМ ЈЕЗИКА ЗА МОДЕЛОВАЊЕ ........................................................... 24 3.4.1 Дијаграм начина коришћења ..................................................................................................................... 24 3.4.2 Дијаграм секвенци ...................................................................................................................................... 25 3.4.3 Дијаграм објеката ...................................................................................................................................... 26 3.4.4 Дијаграм класа ............................................................................................................................................ 26 3.4.5 Дијаграм активности ................................................................................................................................ 27 3.4.6 Дијаграм сарадње ....................................................................................................................................... 28 3.4.7 Дијаграм стања .......................................................................................................................................... 28 3.4.8 Дијаграм расподеле .................................................................................................................................... 29 3.4.9 Дијаграм компоненти ................................................................................................................................ 29

4 ЕКОНОМСКИ АСПЕКТ ИНФОРМАЦИОНОГ СИСТЕМА ..........................................................................................30

5 ЛИТЕРАТУРА .........................................................................................................................................................32

6 ПРИЛОЗИ ..............................................................................................................................................................34

ПРИЛОГ 1: СКУП UML ДИЈАГРАМА .................................................................................................................................... 34

2

Семинарски рад Управљање развојем софтвера за мерење квалитета воде

1 УВОД

Међународни програм „Плава застава“ има за задатак да природнa купалишта буду чиста, безбедна и еколошка како би корисници уживали у пријатном окружењу.

Изградња аутоматизованог информационог система за потребе одржања система квалитета „Плава застава“ би омогућила свим укљученим субјектима тренутни и непосредни увид у стање квалитета воде. Уз помоћ информационог система и аутоматског узимања узорака, стварни квалитет воде би био потпуно транспарентан и тренутан.

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

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


2 ПЛАВА ЗАСТАВА И ЊЕНА ПРИМЕНА У АНАЛИЗИ КВАЛИТЕТА ВОДЕ

Програм „Плава застава“ је координисан од стране Фондације за еколошку едукацију (енг. Foundation for Environmental Education - FEE International, у даљем тексту: FEE), који спроводи координацију за плавом заставом (енг. Blue Flag Coordination), са седиштем у Копенхагену, Данска (The Blue Flag Campaign, 10.1.2003). Циљ програма је да обележе квалитетне природне плаже и марине са плавом заставом. То је добро успостављена и поштована еко-ознака што потврђује и признање да је програм је награђен плавом заставом од стране немачког туристичког оператора ТУИ на Туристичкој берзи у Берлину 2001-ве године, која је прихваћена од стране УНЕП-а (енг. United Nations Environment Programme) и Светске туристичке организације.

У FEE је већ укључено у више од 33 земаља: Белгија, Бугарска, Кипар, Естонија, Данска, Финска, Француска, Хрватска, Грчка, Ирска, Италија, Јужна Африка, Удружење Карибских држава, Немачка, Холандија, Португал, Румунија, Словенија, Шпанија , Шведска, Турска и Велика Британија, али интерес показују и друге земље, како у Европи тако и шире.

У државама чланицама FEE неколико свеобухватни програми: Eko schools - Еко школе, Blue Flag - Плава застава и Young Reporters for Environment - млади новинари о животној средини, као и Learning about Forests – Учење о шумама. Еколошку ознаку „Плава застава“ додељује Европска комисија, на предлог Националне комисије сваке државе чланице FEE. Да бисте добили признање „Плава застава“ потребно је да се изврши пријава на основу годишњег конкурса где се кандидују приобалне области без обзира да ли се налазе на обали мора, река или стајаћих вода. Национална комисија и Европски жири могу да повуку своју доделу сертификата плаве заставе у сваком тренутку сезоне уколико постоји неусклађеност са критеријумима по којима је плава застава и додељена. Њихови руководиоци морају осигурати испуњавање низа критеријума подељених у четири категорије:

- еколошко образовање и информисање, - еколошки бизнис - квалитет воде за купање - безбедност и услуге.

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

Европски жири је, на предлог Националне комисије за плаву заставицу, у току 2003-ће године доделио 2161 плавих заставица природним плажама и 729 маринама, што чини укупно 2890 додељених плавих застава, што је највише до те године. У Србији је до сада додељена једна Плава застава и то за плажу на Ади Циганлији под управом ЈП „Ада Циганлија (Београд, Чукарица, N440 47.425 – E200 24.960 WGS84).

4


3 МЕТОДОЛОГИЈЕ ПЛАНИРАЊА ИНФОРМАЦИОНИХ СИСТЕМА

3.1 ИНФОРМАЦИОНИ СИСТЕМ Количина информација сваким даном расте, због чега је се повећавају тешкоће у проналажењу тражене информације у правом тренутку. За лакши приступ до потребних и жељених информација захтева се одговарајућа компјутерска технологија и добро осмишљен информациони систем. Информациони систем је систем у коме се стварају, похрањују и претражују информације. Исто тако информациони систем се може дефинисати и као систем људских активности, које могу да укључују, или не морају, коришћење компјутерских система. [1]. Постојање информационог система је предуслов за функционисање организације. Састоји се од формалног дела, такозване IT инфраструктуре и неформалног дела - рад. Информациона инфраструктура нам говори како су организоване и повезане рачунарске мреже, хардвер, софтвер и базе података [2]. Неформални део представљају појединце/кориснике и односе међу њима. У њему се одвијају процеси који омогућавају решење три основне групе проблема [2].

• проблем премошћавања временске баријере Већина података се не користе у исто време када су настали већ у неком временски удаљеном тренутку. Да би се превазишле разлике у времену, подаци се чувају на различитим физичким медијима.

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

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

5


3.2 РАЗВОЈ МЕТОДОЛОГИЈЕ ИНФОРМАЦИОНИХ СИСТЕМА

У почетној фази, употреба рачунара у пословне сврхе је подразумевала хардвер који је у односу на садашње време малог капацитета. Фокус истраживања је био у проналажењу ефикасних програмских алгоритама који су оптимално користили расположиви капацитет софтверских решења (енг. applications) ограничених могућности. Ова софтверска решења су имала ограничења у погледу садржаја, јер су била реализована од стране програмера чије су вештине пре свега техничке природе и који су били мање упознати са пословним питањима која захтевају решења. Поред тога, они често нису имали развијене комуникационе вештине. Корисници су такође имали проблеме са презентовањем својих потреба програмерима [1]. Сходно томе, проблеми који су се издвојили су:

• понуђена решења често нису успешно задовољавала захтеве корисника • чак и ако решење је прикладно, јер програмер је веома добро сагледао проблем и

структуру решења, спровођење промена је више или мање обиман и дуготрајан посао са дугорочним последицама које се могу појавити у другим деловима система

• решења су често слабо документована.

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

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

• анализу пословних захтева - обавља аналитичар система, • пројектовање система - са задатком испуњења одређених пословних захтева, • програмирање.

Тако се, поред саме имплементације, појављују у две важне фазе у развоју информационих система, анализа и дизајн (енг. design). Следећа реакција на ове проблеме је појава формалних метода за развој рачунарских апликација [1].

Методологија за развој информационих система је, по дефиницији, скуп поступака, техника, алата и документације са циљем дефинисања помоћи програмерима система у њиховим напорима да спроведу нови информациони систем. Под појмом „методологије изградње информационих система“ често се представљају организациона и техничка знања која се користе у дизајну и производњи компјутерских решења [3]. Треба разлучити да методологије варирају у складу са брзином развоја и примене нових технологија, што значи да методологије не могу постојати независно од технологије. Због тога методологије развоја требају да се развијају и ажурирају у складу са најбољим искуствима у одређеним технолошким окружењима [1]. Квалитет информационе методологије за развој система састоји се од низа корака - фаза које дефинишу алате и упутства о томе како их искористи у пројекту. Друго важно питање је подела одговорности и улоге главних учесника у процесу [4]. Методологија се, због наведеног, састоји од фаза, које се даље деле на подфазе које су под надзором водећих систем-програмера који имају делимичну самосталност у избору техника реализације, а које могу да им у свакој фази пројекта помогну у планирању, управљању, праћењу целокупног пројекта информационог система [1]. Методологија обично садржи прописане кораке развоја, технике за израду производа, алата, интегрисану методологију и обрасце, вишекратна докумената и листе за проверу (енг. Checklists) [5].

6

Семинарски рад Управљање развојем софтвера за мерење квалитета воде Циљ методологије која се користи у изградњи информационих система је да се постигне различите циљеве у примени методологије [1] и обухвата:

• тачно вођење евиденције информационих захтева. Методологија треба да помогне у идентификацији и анализи захтева корисника

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

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

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

• мора постојати индикација неопходних измена у најранијој могућој фази процеса развоја. Трошкови накнадних измена су у експоненцијалној зависности од тренутне фазе реализације имплементације система

• реализован информациони систем треба да буде прилагођен корисницима. Ово осигурава његов успех и дуговечност. Као типичан пример како методологија испуњава те услове, следи опис методологије традиционалног животног циклуса развоја информационог система.

Приликом избора методологије коју користимо, можемо користити следеће критеријуме [6]:

1. адекватност методологије за дефинисање услова и покривање свих фаза развоја софтвера;

2. колико програмери имају искуства у примени методолошких параметара; 3. какву подршку има сама методологија 4. једноставност употребе методологије за разумевање.

Добра методологија за развој новог информационог система мора [7]:

• имати структурирани концепт • омогућавати својим корисницима да је једноставно користе • да обезбеди ефикасно управљање пројектом,

Дакле, приликом избора одговарајуће методологије треба обратити пажњу на:

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

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

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

њену стандардизацију • укључује праћење процедура за обезбеђивање безбедности, контроле и ревизије у

новом информационом систему и • постојање алата који подржава методологију и повећава продуктивност програмера.

Методологија треба одвојено да идентификује:

• излазне резултате сваке активности (тј. шта треба да се уради),

7


• процедуре о томе како да се креирају резултати излаза (како би требало да се уради), • примена стандарда филтрирања из добијених излаза.

Постоји неколико врста метода које се користе у зависности од потреба и захтева:

- методологија готових производа који су подржани од стране одговарајућих инструмената и информационих технологија,

- интерне методологије развијене у различитим организацијама и - комбинација обе наведене.

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

Са порастом величине и комплексности IT система брзо се мењају и технологије захтева идући ка све већој формализацији процеса развоја информационог система. Још у раној фази развоја је потребно обратити пажњу на стратешко планирање и логички дизајн информационог система. Формализација у раним фазама развоја омогућава употребу различитих рачунарских алата, названих CASE алати (енг. Computer Aided Software Engineering). CASE алати имају компјутерски разрађену основу која се рефлектује на ефикасније, прецизније и свеобухватније анализе процеса, дизајна, развоја и одржавања информационих система. CASE алати обично садрже модуле за описивање пословних процеса, базе података и програмске структуре, што омогућава стварање форми, извештаја и тест података [2].

Због све већих могућности информационих технологија повећавају се и захтеви корисника информационог система, који захтевају све снажнију подршку, више информација, боље припремљене и представљене информације из све већег броја база података. То захтева промене у природи информационих система. Информациони системи постају све сложенији, повезанији и свеобухватнији. Често се такви информациони системи састоје од читавог мноштва различитих апликација, различитих организација или различитих стандарда који се могу купити на тржишту. Све је више свеобухватних информационих система који повезују све функције организације дозволивши увођење новог концепта организације рада и производних процеса у производњи и трговини [3].

За успешну реализацију свеобухватног решења за веће компаније пре него што се одлучите за куповину или сопствени развој треба пажљиво анализирати постојећи систем, трошкове и време увођења, али и посебно истаћи и формирати свест о позитивним и негативним ефектима имплементације новог система у односу на постојећи [8].

Приликом избора стандарда информационог система предузећа треба да се изаберу две ствари, пре свега то је софтверски пакет који ће омогућити измене и побољшања пословних процеса и избор пословних партнера који ће нам пружати подршку у побољшању система у будућности. Због великог броја присутних интегрисаних решења, важно је да се анализирају пословне понуде и одреде карактеристике и функционалности понуђених система у складу са потребама пословања. Неки општи критеријуми за доношење одлуке о избору одговарајућег стандарда су дати у наставку [8]:

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

8

Семинарски рад Управљање развојем софтвера за мерење квалитета воде У пракси се примењују различите технике моделирања који подржавају процес пројектовања и изградње информационог система. Без обзира на изабрану методологију сваки систем пре или касније пролази кроз фазе животног циклуса, који обухвата фазе анализе, пројектовања, изградње, експлоатације и одржавања информационог система (Слика 1). Од избора методологије зависи и врста модела и како је он представљен.

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

Старије методологије се заснивају на тзв. линеарном приступу. Ово произилази из претпоставке да је изградња информационог система секвенцијални процес, односно низ активности које следе једна за другом у одређеном редоследу што доводи до коначног циља - увођења софтверског решења.

Слика 1: Фазе животног циклуса информационог система [3]

Као резултат слабости линеарног приступа настао је прототип приступ. Када је реч о приступу развоју који, у сарадњи са корисницима, прво произведе прототип система а потом надограђује и развија док не испуни све жеље и захтеве корисника. Последњих година почела је све више да се користи објектна методологија изградње информационих система која има за циљ објектно-оријентисан приступ развоју софтверских решења из понуђених компоненти (објеката). При томе, свака компонента може неколико пута да се примењује за различите намене. Објектно-оријентисани приступ скраћује време развоја нових решења и се побољшава поузданост и квалитет решења чиме позитивне рефлексије има и на одржавање информационих система [3].

У следећем одељку ћемо се ближе упознати са основним карактеристикама објектно-оријентисаних метода развоја информационог система.

9


3.3 ОБЈЕКТНО-ОРИЈЕНТИСАНЕ МЕТОДОЛОГИЈЕ РАЗВОЈА ИНФОРМАЦИОНИХ СИСТЕМА

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

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

3.3.1 Основни концепти објектно-оријентисаног приступа

Основна идеја објектно-оријентисаног приступа је развој информационих система на директним мапирањем реалних објеката (нпр. купац - производ) модела информационог система, који се бави одговарајућом области пословања. Модел служи да поједностави реалност и направљен је за боље разумевање система који смо створили [9]. Модел се може дефинисати као апстракција, представљање реалног света [1]. Основни концепти таквог модела су: објекат, изолација, класа, полиморфност, наслеђивање биће представљени у следећим поглављима.

3.3.1.1 Објекат

Објекат је ентитет који је у стању да складишти информације (статус) и поставља операцију за приказивање или измену тог статуса [10]. Лице се може дефинисати као ствар или догађај који ми посматрамо [11]. Објекат је неки предмет (субјект) из стварног света који садржи податке и особине [11]. Садржај укључује информације и начине да се стање и релације промене. Статус објекта описују атрибути који су дефинисани и вредности атрибута. Понашање објекта дефинишу операције које представљају начин за преглед и промену вредности атрибута и стања објекта. То је суштински нова карактеристика објектно-оријентисаног приступа као јединог извора информација и начина да измените податке. Сваки објекат има јединствени идентификатор (енг. OID – object identifier) који се разликује од других објеката, иако они могу да имају исте вредности атрибута.

10


3.3.1.2 Изолација

У објектно-оријентисан систем, подаци се чувају унутар објекта. Једини начин да се приступи и измени податак је употреба операција које су дефинисане у овом објекту. Објекат садржи све потребне операције за манипулацију подацима у оквиру објекта. Операције се

Слика 2: Објекат садржи податке и операције [12]

спроводе по методама које представљају софтверски код који обавља одређене промене података. Сам објекат поседује све операције за комуникацију са спољним процедурама, док је унутрашња структура и начин спровођења операција из спољног света (из других објеката) сакривена. Механизам за скривање информација из спољашњег света (енг. information hiding) са ексклузивним приступом подацима преко објекта се зове изолација (енг. encapsulation). Остали објекти могу добити информације или променити статус објекта само кроз функције позива објекта. На овај начин штити се садржај од спољних упада у објекат, такође се елиминише потреба да сви знају унутрашњу структуру других објеката [13]. На овај начин је могуће да се локализују промене, јер свака промена у начину обраде података реализује на само једном месту.

3.3.1.3 Класа

Објекти који имају сличне особине и понашање могу да се групишу у типове објеката. Објекти који имају исте операције уз исте унутрашње структуре, групишу се у класе. Класа је једна од (могу бити и многе) имплементација [10]. То је опис скупа објеката који имају исте атрибуте, операције и семантичке везе [9]. Класа представља модел за објекте и дефинише своју унутрашњу структуру. Објекти исте класе имају исту дефиницију структуре и функционисања [10]. Тако примерци објеката (енг. Instance) чине класу.

11


Слика 3. Инстанце класе

На слици се такође показује да су објекти - појединачна предузећа - инстанце класе Корисник за који су дефинисани атрибути и операције. Овај атрибут се зове класа функција која описује све вредности које инстанце могу да садрже. Представљена су и својства која могу да се примене на све вредности што је заједничко свим класама објеката [9]. Операција је имплементација сервиса на друге објекте изабране класе, са циљем да се утиче на њено понашање [9].

3.3.1.4 Удруживање

Удруживање представљају везе између инстанци класа (особе које раде за компанију). На концептуалном нивоу удруживање представљају концептуалне везе између класа [14]. Удруживање је структурални однос, што указује да су објекти повезани са другим објектима [9]. Оно међусобно може да повеже две или више класа. У првом случају то се зове бинарно удруживање, а у другом случају то је Н-арно удруживање. Графички се приказује као пуна линија која међусобно повезује класе. Основне врсте удруживања су представљена следећом структуром:

- „је-део“ (енг. is-part-of) - „је-повезан-са“ (енг. is-associated-with) - "је" (енг. is-a).

Удруживања могу имати своја имена и смерове. Удруживање може бити једносмерно и двосмерно.

Слика 4: Пример удруживања - асоцијација између класа [15]

12

Семинарски рад Управљање развојем софтвера за мерење квалитета воде У примеру се може видети сарадња типа "је-повезан-са" између купца и фактуре и ставке и артикла. У оба случаја, удруживање је двосмерно где, код имплементације, у првом случају треба постојати класа методе фактуре, а у другом класа методе куповине коју одређује купац који је дао налог – фактуру. Треба напоменути да и класа купца има метод којим одређује које фактуре припадају одређеном купцу. Оваква дефиниција се зове полиморфност (енг. cardinality, multiplicity), што нам говори да фактура припада тачно једном купцу, а један корисник може да има више поруџбина. У примеру везе између фактуре и ставке видимо чињеницу да су ставке саставни део фактуре. Ово можемо назвати агрегацијом. Такође је дефинисано удруживање по различитим основама. Конкретан пример је посебан облик агрегације која се назива композитном агрегацијом (енг. composite aggregation) која има додатну функционалност код које не може постојати независни ентитет што у овом примеру значи да брисање фактуре проузрокује брисање свих ставки у овом редоследу. Тип везе "је" генерализација која ће бити представљена са више детаља у опису наслеђивања.

3.3.1.5 Комуникација

Објекти међусобно комуницирају порукама. Пренос порука је једини начин на који објекти сарађују једни са другима. Објекат са поруком из другог објекта захтева спровођење операције. Дакле, нормалан садржај поруке је:

- идентификација објекта да изврши операцију - прималац поруке, - назив операције које треба извршити - параметри операције, ако их има.

Корисник ће спровести операцију и вратиће резултат објекту који је захтев генерисао (пошиљалац). На овај начин се штити интегритет у објекту од стране других објеката.

3.3.1.6 Полиморфност

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

3.3.1.7 Наслеђивање

У случају да у нашем моделу имамо две или више класа са сличним атрибутима и операцијама поступак би могао елиминисати генерализацију заједничких атрибута и операција у свакој класи помоћу механизма наслеђивања. Повезивањем са класама се задржавају само оне особине који имају својства специфичности чиме правимо суперкласу или предка (енг. superclass или ancestor). Насупрот томе, процес специјализације из класе која има одговарајуће карактеристике ствара поткласе или потомке (енг. subclass).

Синоним за потомка је наследник (енг. Descendent) и он је тај који додаје одређене послове или атрибуте који су вам потребни. Понекад, такође у циљу стварања нових подкласа стварају се апстрактне класе које имају само функцију комбиновања особина које су наслеђене од својих предака. Ова класа обично нема копије - потомке. У оквиру посебне

13

Семинарски рад Управљање развојем софтвера за мерење квалитета воде класе такође могу да се додају атрибути и операције чиме се мења смисао и примена одређених операција. Процедура се зове редефиниција (енг. overriding) и веома је ефикасна али деградира транспарентност целог модела, јер на први поглед није видљива функционалност различитих операција са истим именом.

Потомак може да наследи имовину из једног или више предака. У првом случају се ради о једноструком а у другом о вишеструком наслеђивању. Вишеструко наслеђивање такође смањује транспарентност модела и треба да се користи са посебним опрезом. Ако се не користи правилно може да изазове понављање наслеђивања (енг. repeated inheritance) где исте операције постоје у најмање два предка изабране класе [10].

Слика 5: Пример наслеђивања [16]

Слика показује пример неправилног коришћења вишеструког наслеђивања у случају класе „комби“, која би требало да наследи карактеристике аутомобила и камиона. Објекти који су наслеђени из класе „возило“ ће се наследити два пута у истом облику. Ситуација може да се реши новим дефинисањем операција (редефинисањем) када бирамо један или други објект, или у случају да променимо структуру наслеђивања где „комби“ постаје директан потомак класе „возила“. У погледу транспарентности структуре наслеђивања је најбоље последње решење. Класификација је чин уклањања разлике између објеката када можемо видети заједничке карактеристике [17]. Ту треба обратити пажњу на разлику класификације и генерализације.

„Мика је мушкарац (класификација), човек је облик живота (генерализација) у врсти сисара (генерализација)“. У случају ових изјава се види да је фраза „човек је облик живота“, са одговарајућим смислом, док изјава „Мика је облик живота" то није. Генерализација је наследна али ова класификација у овом случају нема потребна својства [14]. Разлика се може направити ако поставите линк „се“ у питању „је врста“.

Када се наслеђивање пажљиво употреби онда оно омогућава ефикасно одржавање, јер су све промене на једном месту, на највишој тачки у хијерархији класа. Дакле, модификовану операцију ће наследити сва њена „деца“. Наслеђивање омогућава широку употребу, јер наслеђивање особина изабране класе додатно увећава потребну функционалност а значајно смањује време имплементације.

14


3.3.2 Јединствени језик за моделовање - UML

Унифицирани језик за моделовање UML (енг. Unified modelling language - UML) настао је спајањем неколико метода за објектно оријентисане анализе и дизајн, међу којима су најважнији били:

- OMT, аутор Jamesa Roumbaugha, - OOSE, аутора Ivarja Jacobsona, - Boochova metodologija, аутора Grady Booch.

UML је у оквиру ОМГ (Object Management Group) стандардизован и дефинисан као стандардни језик за моделирање.

Слика 6: Еволуција UML [18]

UML је језик за моделовање а не методологија за развој информационих система. Аутори (Roumbaugh, Jacobsona, Booch) су поред предложеног језика, који је методолошки независан, у свом процесу развоја информационих система заснованог на постепеном уопштавању модела, дефинисали и јединствени процес развоја софтвера (енг. The unified software development process). UML који је искоришћен у комбинацији са овом процесу може се описати као методологија. UML као језик за моделирање омогућава изградњу различитих типова модела који нам омогућавају да дефинишемо [9]:

- визуелизацију садашњих и/или будућих систем (енг. as-is, to-be) - поглед на структуру и понашање система, - обрасце који нас воде у пројектовању система, - документовање наших одлука.

3.3.2.1 UML – основни облици

UML се састоји од основних градивних блокова:

- елементи (енг. things) - линкови (енг. relationships) - графикони.

Опис блокова је преузет из [9].

15


Елементи

Елементи могу бити дизајнирани тако да опишу структуру (енг. structural things), понашање (енг. behavioral things), групе (енг. grouping things) или напомене (енг. annotational things).

Структурним елеменатима припадају и класе интерфејса (енг. interface), договор (енг. collaboration) и начин коришћења (енг. use case). Класа је опис скупа објеката који имају исте атрибуте, операције и семантику. Класа имплементира један или више интерфејса. Графички је представљен као правоугаоник, који обично садржи име, атрибуте и операције.

Интерфејс је колекција операција која се дефинишу у класи или компоненти. Интерфејс дефинише спецификацију и параметре рада док је спровођење операције сакривено. Графички се приказује као круг.

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

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

Чвор (енг. node) је физички елемент који постоји у време извршавања и представља ресурсе рачунара који понекад има своју меморију и процесорску снагу. Графички се приказује као коцка која садржи своје име.

Елемент описује особину у дијаграму стања (енг. state machine). Интеракција приказује особину елемента који садржи скуп порука који су размењени између објеката у одређеном контексту како би се постигао одређени циљ. Интеракција садржи разне елементе као што су поруке и везе између објеката. Графички се представља као линијски сегмент који готово увек садржи назив операције.

Дијаграм стања представља особину којом се дефинише редослед стања објекта који треба променити у интеракцији, као одговор на догађаје. Укључује стања, прелазе (прелаз из стања у стање), догађаје (које иницирају прелази) и активности (реаговања на прелазе). Графички стање се приказује као правоугаоник са заобљеним угловима који садржи име подстања, ако их има.

Механизам за груписање објеката у UML-у се зове пакет (енг. package). Пакет је општи механизам за груписање елемената. Постоји на концептуалном нивоу за разлику од компоненте која постоји у време извршавања. Графички се приказује као фолдер. За додавање белешке и описа у UML-у користе се одговарајући елементи које називамо напоменама (енг. notes). Белешка може да се прикачи за елемент или групу елемената. Приказује се као закривљени лист.

16

Семинарски рад Управљање развојем софтвера за мерење квалитета воде Линкови

Линкови се у UML-у могу поделити на:

- зависност, - асоцијације - генерализације - реализације.

Зависност (енг. Dependency) је семантичка веза између два елемента у коме промена независног елемента може изазвати промене у зависном елементу. Графички је илустрована испрекиданом линијом.

Асоцијација је структурални однос који описује скуп веза (енг. Links) које повезују објекте. Посебан случај асоцијације је агрегација чији су основни концепти објашњени на почетку поглавља. Асоцијација се моделира као пуна линија између два структурна елемента. У случају агрегације на линији, када је ка елементу представља се као шупљи дијамант, док је у случају композитне агрегације (енг. composite aggregation) то пун дијамант. Пример композитне агрегације је дефинисање документа унутар документа. Генерализација повезује генерализације и специјализације које су такође описане на почетку овог поглавља. Графички се приказује као стрела са шупљим врхом упереног против иницијатора. Реализација семантичких односа између елемената где се функција првог дефинише на основу резултата другог. Налазимо их између интерфејса у класи и компоненти које их имплементирају. Графички се приказује тачкастом линијом са шупљом тачком.

Графикони - дијаграми

UML обезбеђује различите дијаграме који се користе за приказивање различитих погледа на посматрани систем. Овим представљамо јединствени модел на више начина што омогућава посебан приступ решавању проблемима што олакшава обликовање система. На располагању имамо девет различитих дијаграма. Дијаграми који показују статичку структуру система су:

- дијаграми класа, - дијаграми објеката, - дијаграми компоненти, - дијаграми дистрибуције (енг. deployment diagram).

Понашање система моделирамо следећим типовима изведених дијаграма:

• дијаграми начина коришћења • дијаграми интеракција:

- дијаграм секвенци (енг. sequence diagram) - дијаграм сарадње

• дијаграми стања • дијаграми активности

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

17

Семинарски рад Управљање развојем софтвера за мерење квалитета воде О њима ће бити више речи у одељку 6.2, где уводимо UML приступ изградње информационог система за потребе покрета „Плаве заставе“.

3.3.3 Јединствени процес развоја софтвера

Аутори UML језика су као начин изградње информационих система предложили јединствени процес развоја софтвера (енг. The unified software development process) који је идентификован као други део методологије, заједно са јединственим језиком за моделовање. Процес развоја софтвера представља дефиницију скупа активности које су неопходне за промену потреба корисника у циљу стварања конзистентаног скупа производа који представља софтверско решење [9]. Реализација овог процеса се имплементира коришћењем UML језика којим се описује софтвер као скуп међусобно конзистентних модела који приказују различите погледе на систем. Овај процес је представљен као интерактиван и инкременталан. Дакле, цео развојни процес се одвија у две димензије: временској – где се програм посматра као развој у фазама и активностима - које се обављају у оквиру сваке итерације.

Временски дефинисана димензија фазног развоја покрива цео циклус развоја информационог система и то су:

- почетна фаза (енг. inception) - прикупљање информација (енг. elaboration) - конструкција (енг. construction) - затварање пројекта (енг. transition).

Слика 7: Фазе и активности јединственог процеса [9]

не

не

18


3.3.3.1 Кључне активности у процесу

Читав развој је подељен на низ понављања главних фаза процеса. Резултат сваке стазе је нови напредак (енг. inkrement) резултата што се огледа као додатни део кода који је спреман за пласирање, и потпуно интегрисане и проширене моделе који описују различите аспекте пословања што омогућава лакши прелаз на следећу итерацију јер се систем јасно види. У оквиру сваке фазе понавља се низ делатности које су заједничке за све димензије:

- дефинисање услова, - анализа - планирање, - реализација (имплементација) - резултати испитивања.

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

Такви модели су дефинисани на следећи начин:

Слика 8: Модели јединственог процеса [9]

Слика наглашава међузависност између различитих модела. Промена једног модела утиче на други. Дакле, у дефинисању захтева у случају коришћења модела који се користи у анализи дизајна – дизајнира се дистрибутивни модел. Модел реализације указује на спровођење активности, тестирање модела и активности тестирања. Модели укључују дијаграме дефинисане унутар UML-a.

19

Семинарски рад Управљање развојем софтвера за мерење квалитета воде Дефинисање услова

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

Обавезна функционалност се дефинише као опис како да користи систем и које резултате систем треба да пружи корисницима. Важно је да се идентификују све различите апликације које комуницирају са системом како би се дефинисали главне актере. Не-функционални захтеви, као што је одзив система у различитим случајевима коришћења могу бити описани у оквиру њих [9]. Примери апликација су повезани у јединствену целину помоћу дијаграма коришћења. Поред њих, као главних инструмената у дефинисању захтева, дефинишу се и графикони за описивање понашања система као што су дијаграми тока. Исто тако, можемо направити неке прототипове корисничких интерфејса, који помажу детаљном разумевању интеракције корисника и система. С обзиром да је случај коришћења модела оријентисан према кориснику и његовим функционалностима, код дефинисања случајева коришћења може доћи терминологија која је специфична за поједини проблем, тј. у овом случају да помогне дефиницију термина - речника.

Дефинисањем корисничких потреба истовремено одређујемо њихов значај и рангирање у даљем развоју. Дакле, дефинисање главних услова се своди на:

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

На крају потребно је описати модел у целини.

Анализа Анализа представља поглед на начин реализације захтеваних функционалности. Потребно је да се пажљиво анализирају захтеви корисника који су идентификовани у претходном кораку. Модел анализе се разликује од модела начина примене у следећем [9]:

- описан je у формалном језику намењеном програмерима система; - приказује унутрашњи поглед на систем; - састоји се од класа и пакета; - не садржи понављање (редундантност); - показује начин на који функционише систем; - дефинише начин реализације система.

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

20


- дијаграм класа, - дијаграм сарадње.

Зависности између пакета које реализују различите апликације су приказане у дијаграму класа на вишем нивоу апстракције, у којој се виде пакети и њихове међузависности. Модел анализе је приказан на концептуалном нивоу са вишим степеном приказаних детаља реализације.

Планирање

У кораку планирања дефинише се физички изглед модела система који ће бити основа за даљи развој. Дефинисан је дизајн модела и његова дистрибуција. У планирању модела утврђују се класе, везе између њих и динамичко понашање система. Дефинисани атрибути класа опредељују њену видљивост (видљивост се може дефинисати као јавна, приватна и ограничена – енг. public, private, protected) као и опис метода. Метод се може описати у природном језику или псеудо коду, и оставити програмирање за следећи корак, али се могу одмах испрограмирати у изабраном програмском језику. Везе између објеката су постављене у складу са њиховим улогама животне реалности. Такође треба размотрити технологију за складиштење података приликом дизајнирања класа које у својој имплементацији врше упис података у контексту трансакције. Пакети се трансформишу у подсистеме. Неопходно је да се обезбеди смањење зависности између подсистема, идентификују одговарајући интерфејси и да обезбеди да подсистем обезбеђује правилно спровођење операција дефинисаних њеним интерфејсима.

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

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

Реализација

У кораку реализације дефинишемо појединачне софтверске компоненте које спроводе класе и подсистеме који су дефинисани у моделу плана. Класе имплементирају једну компоненту која садржи изворни код. Реализација се састоји од неколико понављања и паралелно, тако да је важно планирати интеграцију после сваке итерације. Одредба за понављање у оквиру које су развијени делови кода су истовремено интегрисани са већ развијеним деловима система из претходне итерације. У оквиру реализације тестирања појединачне компоненте, пре него што су интегрисане, се примењују на одговарајући хардвер - чворишта. Интегрални систем и тестирање врши у кораку тестирања. Модел који се користи у ову сврху је заједнички за реализацију дијаграма компоненти и дистрибуције. Главни резултат је код који имплементира претходне кораке и производе у систем.

21


Резултати испитивања

Циљ испитивања је да се тестира система, како у погледу покривености потребне функционалности, тако и тачности и перформанси на не-функционалне захтеве. Тестирање на нивоу компоненти се врши у кораку реализације и оно се изводи у кораку интеграције и тестирања система. У циљу добијања што реалнијих резултата дефинишимо тестирање модела који садржи [9]:

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

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

3.3.3.2 Главне фазе процеса

Почетна фаза

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

Прикупљање информација

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

22

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

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

Када се уверимо да реализовани модели предвиђају успешну реализацију система који ће задовољити потребну функционалност, настављамо са следећом фазом.

Конструкција

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

Преузимање

Фаза преузимања производа се врши у окружењу корисника. Тада се још једном врше завршна испитивање и прилагођавања. После покретања система могу се појавити проблеми које у фази тестирања нисмо били у могућности да идентификујемо. Ако је одступање веће онда се проблем елиминише у још једној итерацији производње. Мање корекције се извршавају у фази преузимања – на лицу места. Овакав пут реализације модела и тестирања доводи до креирања базе знања развојног тима коју је могуће искористити у следећим пројектима.

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

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

23


3.4 ПЛАНИРАЊЕ ИНФОРМАЦИОНОГ СИСТЕМА КОРИШЋЕЊЕМ ЈЕЗИКА ЗА МОДЕЛОВАЊЕ

3.4.1 Дијаграм начина коришћења

Дијаграм начина коришћења показује случајеве коришћења и учеснике који су у вези са њима. Он изражава кориснички поглед на систем. Кориснички примери су догађаји који доносе жељене резултате учеснику који их је изазвао. Корисник особа или друго лице ван система који су у интеракцији са системом. Корисник није конкретна особа већ представља апстаховану улогу (нпр. представник продаје). Начин коришћења представља описе појединих догађаја у интеракцији корисника и система. Он треба да поседује следеће компоненте [4]:

- назив начина употребе, - кратак опис намене, - одговорно лице - за кога систем реализујемо, - асистент – лице које такође учествује у реализацији - почетак - прва активност посматраног случаја, - крај - последња активност посматраног случаја коришћења, - мерљиви резултати, - ток догађаја - описују позитиван сценарио - алтернативни ток догађаја - када услови за реализацију нису испуњени, - слични примери - напомене.

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

Слика 9: Дијаграм примера коришћења WEB сервера

24

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

3.4.2 Дијаграм секвенци

Секвенцијални дијаграм (енг. sequence diagram) приказује временски след размене порука између објеката система и спољних корисника. Садржи објекте, комуникационе протоколе и поруке. Слика 10 приказује дијаграм секвенци за пренос података са бове у базу података сервера.

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

Вертикална испрекидана линија представља животну линију објекта и показује време интеракције објекта са другим објектима. Животна линија завршава уништењем објекта који је обележен знаком „X“ на месту брисања. Уски вертикални правоугаоници имају за циљ да идентификују време када је објекат активан и контролишу спровођење акције. Стрелице представљају поруке које се размењују између објеката. Поруке приликом имплементације метода су упућене компонентама које обављају захтеване акције унутрашњој структури објекта. Преостали секвенцијални дијаграми приказани су у Прилогу 1.

8. Сигнал

8ц. Статус_уписан

25


3.4.3 Дијаграм објеката

Објектни дијаграм приказује тренутни пресек објеката (енг. Snapshot) система у сваком тренутку рада. Он садржи објекте и њихове везе (енг. Link).

Слика 11: Пример дијаграма објекта

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

3.4.4 Дијаграм класа

Дијаграм класа приказује класе, интерфејсе и њихова међусобне везе.

Поред ових елемената дијаграм класа садржи и пакете који су дизајнирани да групишу главне елементе модела у мање интегрисане целине. Модел показује класу као правоугаоник, коме је додељен назив, атрибути и операције. Везе између класа могу бити асоцијације, агрегације, збирне агрегације и генерализације. Линкови дефинишу смер полиморфности како би се дефинисале улоге (енг. Role), које класа има на сваком крају везе.

26


Слика 12: Пример класног дијаграма - база података за извештавање

3.4.5 Дијаграм активности

Дијаграм активности се користи у приказу сукцесивних и паралелних корака у спровођењу поступка. Дијаграм обухвата активности, везе између њих, одлуке у складу са условима да прође кроз разне следеће активности и усклађивање послова (енг. synchronization lines), у којој се координира примена паралелних токова при преласку на следеће активности када се испуне одређени услови.

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

Елементи, линкови и графикони су основни делови UML-а којим реализујемо жењене моделе информационих система у складу са индивидуалним фазама процеса развоја.

Преостале дијаграми активности су приказани у Прилогу 1.

27


Слика 13: Дијаграм активности у случају посете WEB сајта

3.4.6 Дијаграм сарадње

Дијаграм сарадње је приказ размене порука на другачији начин који ставља већи нагласак на организацију објеката који су укључени у интеракцију. У овом случају то је пренос низа порука које су дефинисане серијским бројевима поруке и која сачињава именовану комуникацију. У дијаграму сарадње су означене конекције (енг. Link) између објеката, који су у дијаграму секвенци приказани одвојено.

Слика 14: Дијаграм сарадње у случају посете WEB сајта

Приказ осталих дијаграма сарадње дат је у Прилогу 1.

3.4.7 Дијаграм стања

Дијаграм стања приказује стања, догађаје и активности. Користи се за приказ промена статуса изабраног објекта у вези са догађајима који су довели до те промене промене.

Слика 15: Дијаграм стања објекта – бова

28


3.4.8 Дијаграм расподеле

Дијаграм расподеле (енг. deployment diagram) показује инсталацију компоненти у чвору, који представљају хардвер на коме су компоненте покренуте. Садржи чворове и везе између чворова, али такође може приказати расподелу компонената између чворова.

Слика 16: Дијаграм расподеле

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

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

Слика 17: Дијаграм компоненти за WEB сервере

29


4 ЕКОНОМСКИ АСПЕКТ ИНФОРМАЦИОНОГ СИСТЕМА

Оквирни инвестициони трошкови уградње мерних инструмената у једну бову дати су у Табели 1.

Табела 1: Процењени инвестициони трошкови бове са неопходним инструментима [19]

1 . бова и пратећа опреме (соларне ћелије, носачи) 13.000,00 EUR

2. опрема за сидрање (ланац, конопац, сидро) 400,00 EUR

3. сензори по спецификацији 15.000,00 EUR

4. опрема за online мерења 2.500,00 EUR

5. опрема за GSM пренос података у централу 4.000,00 EUR

УКУПНО : 34.900,00 EUR

Као што видимо трошкови куповине једне бове заједно са припадајућим инструментима су процењени на 34,900.00 €. На ове трошкове се морају додати и трошкови куповине и инсталирања софтвера за сервер, израду интернет апликације и помоћних програма који очитавају и складиште измерене информације у базу података, који оквирно износе још око 5.000,00 €.

У случају да се користи постојећи систем у Биолошкој станици ЈП „Ада Циганлија“, потребно је размотрити и инвестиционе трошкове закупа простора и опреме.

Из овог би се могло проценити да је укупна инвестиција за инсталацију три бове око 70.000,00 €. Наравно, уз куповину већег броја бова и могућег интересовања других земаља за овај пројекат могуће је одређено смањење трошкове.

Овој процени инвестиције недостају неопходни трошкови одржавања који се такође морају узети у обзир.

Према подацима EuroGOOS-а трошкови одржавања, који укључује калибрацију инструмената, трошкови пословања, одржавање и сертификацију података за једну бову кошта од 15.000 до 80.000 € годишње и она углавном зависи [20] од:

- локација бове (отворено море, у близини обале, слободно-плутајућа) - број људи и техничке опреме неопходне за приступ бови и одржавању, - величини брода/чамца који се користи за приступ бови - карактеристикама и броју инструмената и сензора.

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

30

Семинарски рад Управљање развојем софтвера за мерење квалитета воде За постојећи систем узорковања је индикативна цена једног узетог узорка од 300,00 €, што значи да је власник купалишног простора уколико поштује прописане критеријуме програма Плава застава обавезан да годишње плати само за узорковање воде у току летње купалишне сезоне око 6.000,00 €. Ова цена се одређује на основу уговора између власника купалишта и Градског завода за јавно здравље Београд. Овде смо истакли да се у већини земаља ЕУ анализе узорака вода за купање плаћају било државним било општинским установама.

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

31


5 ЛИТЕРАТУРА [1] Avison D. E., Fitzgerald G.: Information Systems Development: Methodologies, Techniques

and Tools, 2nd ed. London: McGraw-Hill, 1996. 505 str.

[2] Gradišar M., Resinovič G.: Informatika u poslovnom okruženju. Ljubljana: Ekonomska fakulteta, 2001. 508 str.

[3] Kovačič A., Vintar M.: Projektovanje i izgradnja informacionih sistema. Ljubljana: Dzs, 1994. 316 str.

[4] Galliers R.D., et. all.: Strategic Information Management. Second Edition, B.k.: Butterworth Heinemann, 1999. 590 str.

[5] Murch R.: Project Management: Best practices for IT professionals. Upper Saddle River: Prentice Hall, 2001. 247 str.

[6] Lam Josie: Object-Oriented Technology. [URL: http://disc.cba.uh.edu/~rhirsch/spring97/ lam1/hope.htm], 25.12.2001.

[7] Warren J. Donald Jr., et. all: Handbook of IT Auditing. 1998 Edition. Warren, Gorham & Lamont, 1998. 1127 str.

[8] Silič M., et.all.: Jedinstvena metodologija razvoja informacionih sistema, 4-ti tom – Objektni razvoj informacionih sistema. Ljubljana: Vlada Republike Slovenije, Center vlade Republike Slovenije za informatiko, 2000. 198 str.

[9] Booch G., Rumbaugh J., Jacobson I.: The Unified Modeling Language User Guide. Reading: Addison Wesley Longman, Inc. 1999. 482 str.

[10] Jacobson I., Ericsson M., Jacobsson A.: The Object Advantage: Business process reengineering with object technology. New York: ACM Press, 1995, 347 str.

[11] Jaklič J.: Planiranje baze podataka. Slajdovi sa predavanja. Ljubljana: Ekonomski fakultet, 2002. 124 str.

[12] Črv, M.: Objektni pristup reinženjeringu poslovnih procesa i izgradnja informacionog sistema – metodološki aspekti. Doktorska disertacija. Ljubljana: EF, 2000. 202 str.

[13] Taylor D.: Object-Oriented Information Systems: Planning and Implementation. New York: John Wiley & Sons, Inc., 1992. 357 str.

[14] Мартин Фовлер, Кендал Скот: UML дестиловане, друго издање. Њујорк: Аддисон Веслеи Лонгман, 2000. 186 стр.

[15] Shelly G., et. all: System Analysis and Design – Fourth Edition. Boston: Course Technology – Thomson Learning, 2001. 28 cm.

[16] Blanc Miloš: Razvoj logističkog informacionog sistema uz upotrebu metodologije tabelarnog razvoja aplikacija. Magistarski rad. Ljubljana: Ekonomski fakulteta, 2001. 102 str.

32

http://disc.cba.uh.edu/%7Erhirsch/spring97/

Семинарски рад Управљање развојем софтвера за мерење квалитета воде [17] Odell J.: Advanced Object-Oriented Analysis and Design Using UML. Cambridge:

Cambridge university press, 1999. 246 str.

[18] Živkovič A., et. all.: Razvoj sofrvera korišćenjem jezika UML. Uporabna informatika, številka 4, 2000, str. 200-207.

[19] Aanderaa Instruments. [URL: http://www.aanderaa.com/], 25. 3. 2003.

[20] Legrand J., et. all: Monitoring the marine environment Operational practices in Europe - a survey of operational practices in use for the running of environmental monitoring installations in Europe. Atene: 3rd EuroGOOS – The European Global Ocean Observing System - Conference. [URL: http://www.ifremer.fr/dtmsi/publications/presentation/ monitoring.pdf], 20. 12. 2002.

33


6 ПРИЛОЗИ

ПРИЛОГ 1: СКУП UML ДИЈАГРАМА

1.1 Дијаграм случаја употребе за WEB сервер

34


1.2 Дијаграми секвенци

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

35


1.2.2 Дијаграм секвенци за приступ подацима на сајту:

36


1.2.3 Дијаграм секвенци за пренос података из базе „Плава застава“:

37


1.2.4 Дијаграм секвенци снимања података о новом кориснику:

38


1.3 Дијаграм објеката – пријципијелни графикон класа

39


1.4 Дијаграм класа са и без атрибута - подаци за извештавање Дијаграм класа - функционална шема:

- -

40


Дијаграм класа - детањна шема:

41


1.5 Дијаграм активности Дијаграм активности приликом приступа WEB сајту:

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

42

Семинарски рад Управљање развојем софтвера за мерење квалитета воде Дијаграм активности приликом пријављивања новог корисника у базу података:

43


1.6 Дијаграми сарадње Дијаграм сарадње приликом посете WEB сајту:

Дијаграм сарадње приликом преноса података између корисника и базе података:

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

44


1.7 Дијаграм стања Дијаграм стања мерне бове:

Дијаграм стања програма Програм_бова:

Дијаграм стања програма Упис:

45


1.8 Дијаграм дистрибуције

1.9 Дијаграм компоненти за WEB сервер

46

menadzment is - ada ciganlija

Documents