593801.ndraskovic-diplomski

SVEUČILIŠTE U DUBROVNIKU ODJEL ZA ELEKTROTEHNIKU I RAČUNARSTVO

STUDIJ POSLOVNO RAČUNARSTVO

Niko Drašković

DIPLOMSKI RAD

INFORMACIJSKI SUSTAV ZA EVIDENCIJU KOMUNIKACIJSKIH UREĐAJA NA BRODOVIMA

Dubrovnik, rujan 2012.

Sadržaj Uvod ....................................................................................................................... 1

1 Projektiranje informacijskih sustava ................................................................ 2

1.1 Programsko inženjerstvo ................................................................. 3

1.1.1 Modeli razvoja informacijskog sustava ...................................... 4

1.2 Korištene tehnologije ....................................................................... 8

2 Satelitske komunikacije u pomorstvu .............................................................. 9

2.1 Inmarsat .......................................................................................... 9

2.2 Posrednici ...................................................................................... 12

3 Informatizacija poslovanja ............................................................................. 13

3.1 Postojeće stanje informatizacije .................................................... 13

3.2 Trenutni problemi informacijskog sustava ..................................... 13

3.3 Ciljevi informatizacije ..................................................................... 14

3.4 Specifikacije zahtjeva .................................................................... 15

3.4.1 Slučajevi korištenja .................................................................. 15

3.4.2 Funkcionalni zahtjevi ............................................................... 25

3.4.3 Nefunkcionalni zahtjevi ............................................................ 28

3.4.4 Što sustav neće raditi .............................................................. 28

4 Modeli sustava .............................................................................................. 29

4.1 Model funkcija ............................................................................... 29

4.2 Model procesa ............................................................................... 30

4.2.1 Dijagram konteksta .................................................................. 30

4.2.2 Pregledni dijagram .................................................................. 32

4.2.3 Razrada procesa preglednog dijagrama .................................. 34

5 Modeli podataka ............................................................................................ 36

5.1 Dijagram entiteti - veze .................................................................. 36

5.2 Relacijski model baze podataka .................................................... 40

5.2.1 Upotreba LINQ to SQL-a ......................................................... 40

6 Dizajn programske podrške ........................................................................... 43

6.1 Strukturna karta za funkciju aktivacije usluga ................................ 43

6.2 Dijagram slijeda za proces aktivacije usluga ................................. 44

6.3 Dijagrami aktivnosti ....................................................................... 46

6.4 Dijagram razreda ........................................................................... 48

7 Izrada sustava ............................................................................................... 52

7.1 Provjera ispravnosti ....................................................................... 52

7.2 Upotreba sustava .......................................................................... 53

7.2.1 Administratorska uporaba sustava .......................................... 53

7.2.2 Korisnička uporaba sustava .................................................... 54

7.3 Buduća nadogradnja ..................................................................... 58

Zaključak .............................................................................................................. 60

Reference i literatura ............................................................................................ 61

Sažetak ................................................................................................................ 63

Summary .............................................................................................................. 63

Popis oznaka i kratica

AA Računovodstvene uprave (Accounting Authorities)

BI Poslovna inteligencija (Business Intelligence)

BLL Poslovni sloj sustava (Business Logic Layer)

DAL Podatkovni sloj, sloj pristupa podacima (Data Access Layer)

DLL Dinamički povezujuća biblioteka (Dynamic Link Library)

ER dijagram Dijagram entiteti veze (Entity-Relationship diagram)

GMDSS Globalni pomorski sustav za sigurnost i nuždu (Global Maritime

Distress and Safety System)

IMN Brojevi Inmarsatovih mobilnih terminala (Inmarsat Mobile Number)

IMO Međunarodna pomorska organizacija (International Maritime

Organization)

ISN Serijski broj Inmarsat uređaja (Inmarsat Serial Number)

ISP Pružatelj Inmarsat usluga (Inmarsat Service Provider)

LES Zemaljska postaja (Land Earth Station)

LESO Operator zemaljske postaje (Land Earth Station Operator)

LINQ Tehnologija upita ugrađenih u jezik (Language-integrated Query)

MMSI Identifikator broda u pomorskim komunikacijama (Maritime Mobile

Service Identity)

NCS Stanica za koordinaciju mreže (Network Co-ordination Station)

NOC Centar za mrežne operacije (Network Operations Center)

PSA Točka aktivacije usluge (Point of Service Activation)

SARF Formular zahtjeva za aktivaciju (Service Activation Request Form)

SOLAS Međunarodna konvencija o sigurnosti života na moru (International

Convention for the Safety of Life at Sea)

SQL Strukturirani jezik upita (Structured Query Language)

SSN Serijski broj SIM kartice (SIM card Serial Number)

SUBP Sustav za upravljanje bazom podataka

UI Prezentacijski sloj, korisničko sučelje (User Interface)

USDP Unificirani proces razvoja softvera (Unified Software Develompent

Process)

WPF Microsoftova tehnologija izrade grafičkih sučelja (Windows

Presentation Foundation)

XAML Jezik za modeliranje aplikacija (XML Application Modelling

Language)

1

Uvod

Informacijski sustavi imaju potencijal da tvrtkama olakšaju poslovanje,

ubrzaju poslovni proces i da srednjem i gornjem menadžmentu pomognu pri

donošenju odluka. Dobro osmišljeni i dobro realizirani sustavi su obično skupi jer

je potrebno da tim koji izrađuje sustav vrlo dobro poznaje poslovni proces, što je

obično rezultat dugotrajne i detaljne analize poslovanja.

Izrada i održavanje informacijskog sustava osim same cijene nosi sa sobom

i rizik od neuspjeha, bilo nedovršenjem projekta ili lošom realizacijom, što

potencijalno može nanijeti štetu. Zbog toga se informacijski sustavi naručuju samo

onda kada je očekivana dobit puno veća od troška i rizika izrade, pa je izrada

takvih sustava uglavnom isplativa samo većim tvrtkama.

Ako je dio poslovnog sustava koji informacijski sustav modelira dovoljno

jednostavan, onda i male tvrtke mogu imati koristi od izrade takvog informacijskog

sustava ako je cijena dovoljno niska. Ovaj rad opisuje izradu jednog takvog

informacijskog sustava.

Informacijski sustav koji ovaj rad opisuje služi evidenciji komunikacijskih

uređaja na brodovima. Opisana je problematika evidencije, praćenja, aktivacije i

deaktivacije komunikacijskih uređaja kao i postojeće stanje informatizacije te

problemi s kojima se korisnik susreće.

U teorijskom dijelu ovoga rada se govori o načinima izrade informacijskih

sustava s naglaskom na odabrani pristup izrade, te se ukratko opisuju i tehnologije

korištene pri izradi. Navedeni su funkcionalni i nefunkcionalni korisnički zahtjevi, a

sustav je opisan raznim modelima, odnosno dijagramima.

Praktični dio rada uključuje realizaciju informacijskog sustava. Informacijski

sustav je realiziran kao aplikacija izrađena u C# .NET-u, a kao sustav za

upravljanje bazom podataka se koristi SQL Server 2008 R2 Express. Aplikacija,

izvorni kod i popratni dokumenti su dani na CD-u kao dio ovog rada.

Rad uključuje i upute za korištenje sustava s korisničkog stajališta (kreiranje

i izmjena zapisa, aktivacija, deaktivacija i slično) kao i s administratorskog

stajališta (instalacija, postavljanje baze podataka i slično).

2

1 Projektiranje informacijskih sustava

Informacijski sustav je dio poslovnog sustava koji daje podatkovnu sliku

procesa iz realnog sustava [3], a obično podrazumijeva bilo koju kombinaciju

informacijske tehnologije i ljudskih aktivnosti koja podržava operativni rad,

rukovanje i donošenje odluka u sustavu [4].

Pod pojmom informacijskog sustava najčešće podrazumijevamo one

sustave koji su podržani računalom, iako to mogu biti i sustavi koji se ne oslanjaju

na računala ali obrađuju informacije. Kada govorimo o informacijskim sustavima

podržanim računalom, onda govorimo o uređenju ljudi, podataka, procesa, sučelja,

mreža i tehnologija koji međusobno djeluju sa svrhom podrške i poboljšanja

svakodnevnih poslovnih aktivnosti, kao i podrške rješavanju problema i donošenju

odluka [3].

Informacija u poslovnom sustavu je barem jednako bitna kao i vlasništvo,

ljudski resursi ili kapital neke organizacije [3]. Organizacije posluju na osnovu

raspoloživih informacija - na temelju analize mogu donijeti odluke koje će povećati

uspješnost organizacije i donijeti profit. Informacije im daju sliku trenutnog stanja

organizacije, te su potrebne za obavljanje njihove osnovne poslovne djelatnosti -

nije moguće klijentu isporučiti proizvod dok ne znate njegovu adresu.

Gubitak, neispravnost, nepravovremenost i nedozvoljeni pristup

informacijama mogu uzrokovati velike financijske (kao i pravne) probleme, narušiti

ugled, pa čak i dovesti do propasti organizacije. Informacijski sustavi koji pogrešno

analiziraju informacije i daju pogrešne prijedloge također mogu uzrokovat velike

gubitke. Informacijski sustavi koji ne poboljšavaju obavljanje poslovnog procesa

organizacije su gubitak sami po sebi. Zbog toga je vrlo važno da informacijski

sustavi budu kvalitetni, da funkcioniraju ispravno, i da ispunjaju one ciljeve zbog

kojih su i uvedeni.

Oko 70% informacijskih sustava u svijetu se smatra neuspješnim. U

prosjeku se troškovi i rokovi za izradu sustava prekorače za oko duplo, a oko

trećine projekata se prekine prije dovršenja [6, 13]. Loše planiranje ili projektiranje

novog sustava će gotovo sigurno rezultirati neuspjehom, pa je pri izradi

informacijskih sustava potrebno pristupiti s inženjerskog stajališta.

3

1.1 Programsko inženjerstvo

Programsko inženjerstvo je primjena sistematskog, discipliniranog,

mjerljivog pristupa razvoju, operativnom radu, i održavanju softvera; odnosno,

primjena inženjeringa na softver [7]. Područje programskog inženjerstva je

sustavna primjena alata i tehnika na čitav proces razvoja programske opreme

(softvera), a sastoji se od planiranja, analiziranja i pobližeg opisivanja

(specifikacije) informacijskog sustava kojeg treba izraditi, arhitekture, dizajna i

izrade programskog rješenja, zatim provjere valjanosti, pisanja dokumentacije,

uvoda u rad te održavanja sustava tijekom rada [5, 23].

U kontekstu programskog inženjerstva se govori o životnom ciklusu razvoja

informacijskog sustava (odnosno, razvojnom procesu [10]), koji definira faze i

aktivnosti koje nužno treba obaviti tijekom razvoja bez obzira na veličinu sustava

koji se gradi [23]. Postoje različiti modeli (pristupi) razvoju informacijskih sustava,

no većina ih ima sve faze, a to su: [24]

• Planiranje:

o Snimka stanja i inicijalna strategija;

o Studija izvodljivosti;

o Planiranje projekta.

• Analiza:

o Analiza zahtjeva;

o Specifikacija zahtjeva.

• Arhitektura i dizajn:

o Dizajn sustava, modeliranje;

o Detaljni dizajn, razrada rješenja.

• Implementacija i testiranje:

o Izrada programskog rješenja;

o Testiranje komponenti;

o Integracija i provjera sustava.

• Uvođenje i održavanje:

o Uvođenje, održavanje, obuka osoblja i potpora.

• Pregled:

o Revizija sustava kada su potrebne veće izmjene.

4

1.1.1 Modeli razvoja informacijskog sustava

Model razvoja opisuje konkretan razvojni proces kroz nekoliko faza razvoja,

a pojedini modeli su pogodni za rješavanje neke određene vrste problema [23].

Svaki od modela ima svoje prednosti i nedostatke, a na razvojnom timu je da

odluči koji model, ili kombinaciju modela, da primjeni [26].

Generalno, modeli razvoja opisuju slijed prolaska kroz faze razvoja,

aktivnosti koje se obavljaju u pojedinim fazama i njihove rezultate, te uvjete

potrebne za prelazak u sljedeću fazu razvoja.

1.1.1.1 Vodopadni model

Vodopadni model razvoja je najstariji sustavni pristup razvoju softvera, a

smatra se da je nastao u 60-tim godinama 20. stoljeća kao posljedica tada

uobičajenog hardverskog pristupa razvoju gdje su promjene kasnije u razvoju

skupe [24].

Vodopadni model se zasniva na slijednom odvijanju faza razvoja; sljedeća

faza može početi tek kad je prethodna završila, s tim da se teško vratiti na

prethodnu fazu. Ovakav model je primijenjen velikim projektima gdje su zahtjevi

vrlo dobro definirani, i gdje se ne očekuju izmjene [5]. Također ga je moguće

primijeniti u novim sustavima kada razvojni tim ima malo iskustva, a problematika

je koncepcijski dobro objašnjena [24].

Slika 1 - Vodopadni (lijevo) i evolucijski (desno) modeli razvoja

5

Vodopadni model se ne primjenjuje na projekte koji imaju loše definirane

zahtjeve, odnosno u kojima se očekuju izmjene u zahtjevima. Također se ne

primjenjuje kada se radi evolucija postojećeg sustava, odnosno kada se u razvoju

novog sustava otkrivaju dodatni zahtjevi [24].

Prednosti vodopadnog modela su to što je jednostavan, a pošto se model

zasniva na tomu da se zahtjevi ne mijenjaju, neće doći do problema u kasnijoj

razvojnoj fazi radi dodatnih zahtjeva.

Nedostaci vodopadnog modela su baš u slučaju pogrešaka ili novih

odnosno promijenjenih zahtjeva. Greška pronađena kasno u razvoju je vrlo skupa

za ispraviti, a nepraktičnost povratka na prethodne faze nove zahtjeve čini teškima

za primijenit. Dodatni nedostatak je što sustav nije upotrebljiv dok nije u potpunosti

gotov, a klijentu je teško stvoriti predodžbu o sustavu na temelju pisane

specifikacije [5].

Da bi se uklonili neki od nedostataka klasičnog vodopadnog modela

razvijeni su takozvani pseudostrukturni i radikalni vodopadni modeli, koji

dozvoljavaju povratak u bilo koju od prethodnih faza razvoja i promjenu rezultata

prethodnih faza, kao i obavljanje aktivnosti različitih faza istovremeno [5].

Vodopadni model je odabran kao model izrade sustava opisanog ovim

radom. Razlog tomu je što je problematika koju sustav rješava dobro definirana,

odnosno jer se novi sustav zasniva na dodatnoj informatizaciji postojećeg sustava.

Također, razvojnom timu je ovo prvo pravo iskustvo u izradi informacijskog

sustava pa je vodopadni model korišten radi svoje jednostavnosti.

1.1.1.2 Evolucijski model

Primjena informacijskog sustava mijenja predodžbu korisnika, čije se

potrebe mijenjaju (rastu) tijekom primjene. Evolucijski model se zasniva na izradi

prototipova koji služe provjeri zahtjeva, te se često nakon prikupljanja grubo

definiranih zahtjeva odmah kreće u posao [23].

Evolucijski model razvoja je primjenjiv onda kada zahtjevi nisu dobro

definirani ili kada se očekuje da će se zahtjevi korisnika često mijenjati. Primjenjuje

se za male projekte ili dijelove sustava, kada sustav raste s organizacijom koju

podržava, ili kada se radi o vidljivoj funkcionalnosti (grafičkim sučeljima) [23].

6

1.1.1.3 Iterativni model

Iterativni model kombinira elemente vodopadnog modela s iterativnim

pristupom evolucijskog modela [24].

Slika 2 - Iterativni model razvoja

Iterativni model u prvoj iteraciji daje jezgreni proizvod, te kroz iteracije

omogućuje stalnu provjeru valjanosti rezultata različitih faza. Koristan je kada je

odnos s naručiteljem fleksibilan, odnosno kada su moguće (i očekivane) promjene

zahtjeva u hodu [23].

1.1.1.4 Spiralni model

Spiralni model kombinira ideju iterativnog razvoja sa sistematskim

pristupom vodopadnog modela [23]. Zasniva se na inkrementalnoj izgradnji

sustava prolaskom kroz spiralu (slika 3).

Kod spiralnog modela je značajno to što se na početku svake faze provodi

procjena rizika; nastoji se utvrditi moguće rizike i razriješiti ih prije nastavka, bilo

ukidanjem ili svođenjem na najmanju moguću mjeru. U slučaju da je rizik prevelik,

projekt se prekida [5]. Spiralni model razvoja ima sve faze kao i vodopadni model

razvoja, s tim da su odvojene planiranjem, procjenom rizika, izgradnjom prototipa i

simulacijom sustava [24].

Spiralni model se većinom koristi kod vrlo velikih projekata kada provođenje

analize rizika ne predstavlja prevelik relativni trošak [23].

7

Slika 3 - Spiralni model razvoja

1.1.1.5 USDP model

USDP model (Unified Software Development Process) je iterativni model

razvoja koji se dijeli u cikluse, s tim da svaki ciklus isporučuje kompletno rješenje

na određenoj razini detaljnosti [14]. Ciklusi USDP modela su:

1. Početak (engl. inception) - Određuju se ciljevi i opseg projekta,

slučajevi korištenja, ključni zahtjevi, identificiraju se rizici te se daje

procjena trajanja i troška izrade.

2. Razrada (engl. elaboration) - Nastoji se prikupiti većina zahtijeva na

sustav, riješiti poznate rizike, te uspostaviti osnovnu arhitekturu.

3. Izrada (engl. construction) - Rezultat izrade je funkcionalni sustav,

programski kod i sva popratna dokumentacija.

4. Prijelaz (engl. transition) - Završena je izrada sustava, koji se u ovoj

fazi prenosi iz razvojnog u operativno okruženje. U ovoj fazi se

obavlja učitavanje poslovnih podataka, obuka korisnika i slično.

8

1.1.1.6 Agilni modeli i metode

Agilne metode su razvijene kao reakcija na formalne procese koji

zahtijevaju mnogo dokumentacije prije izrade samog programskog rješenja.

Zasnivaju se na isporuci funkcionalnog programskog koda kroz iterativan proces s

kratkim iteracijama. Naglasak je na osobnom kontaktu između sudionika, te je

potrebna neprekidna uključenost korisnika u rad razvojnog tima [24].

Agilne metode su primjenjive na manje projekte koji nisu kritični a zahtjevi

im se često mijenjaju, i onda kada je razvojni tim sastavljen od manjeg broja

iskusnih programera. Agilne metode nisu primjenjive na velike projekte s većim

brojem ljudi u razvojnom timu, ili kada se razvojni tim ne nalazi na jednom mjestu.

Također nisu primjenjive za kritične sustave koji ne smiju otkazati [23].

1.2 Korištene tehnologije

Tehnologije korištene pri razvoju sustava opisanog ovim radom su:

• .NET framework - Microsoftova implementacija zajedničke jezične

infrastrukture (CLI - Common Language Infrastructure), koja se

sastoji od zajedničke izvršne okoline (Common Language Runtime,

CLR), biblioteka (engl. libraries) i jezika [16].

• C# - Objektno-orijentirani programski jezik koji se izvršava unutar

CLR (engl. managed code).

• LINQ - Skup funkcionalnosti koji proširuju sintaksu .NET jezika

dodajući sposobnosti izvođenja složenih upita nad podacima [21].

• LINQ to SQL - Proširenje nad LINQ-om koje omogućuje upravljanje

podacima relacijske baze podataka putem objekata bez gubitka

sposobnosti postavljanja upita [17].

• SQL Server 2008 R2 - Sustav za upravljanje bazom podataka.

• Windows Presentation Foundation (WPF) - sustav za izgradnju

naprednih grafičkih sučelja pomoću XAML-a, jezika za opisivanje

sučelja zasnovanog na XML-u [20].

• ClickOnce - komponenta Visual Studia (razvojnog okruženja) koja

omogućuje jednostavnu isporuku i instalaciju programskog rješenja,

uz mogućnost automatskog ažuriranja na novu verziju [18].

9

2 Satelitske komunikacije u pomorstvu

Komunikacijski uređaji na brodovima su potrebni ne samo za komercijalne,

već i za sigurnosne svrhe. Međunarodna pomorska organizacija (International

Maritime Organization - IMO) propisuje međunarodnu konvenciju o sigurnosti

života na moru (International Convention for the Safety of Life at Sea - SOLAS,

1974.) u kojoj stoji da su svi putnički i transportni brodovi teži od 300 tona bruto

obavezni primjenjivati GMDSS (Global Maritime Distress and Safety System) [8].

GMDSS podrazumijeva raznu opremu, propise i procedure sa svrhom poboljšanja

razine sigurnosti na moru, kao i lakšeg spašavanja brodova, brodica i zrakoplova u

nevolji [15].

U GMDSS su uključeni sustavi satelitskog pozicioniranja radio farova u

nuždi (engl. satellite emergency position indicating radio beacons - EPIRB),

transponderi za potragu i spašavanje (engl. search and rescue transponders -

SART) [8], MF, HF i VHF radio primopredajnici koji imaju mogućnost digitalnog

selektivnog pozivanja (engl. Digital Selective Calling - DSC), te Inmarsat sustavi

za satelitsku komunikaciju [15].

Pošto SOLAS putem GMDSS-a neposredno uvjetuje postojanje uređaja za

satelitsku komunikaciju, brodske kompanije koje se bave međunarodnim

prijevozom tereta ili putnika su dužne na svojim brodovima (onima koji su

obuhvaćeni GMDSS-om) imati takve uređaje. Brodovi koji nisu dužni imati takve

uređaje, poput manjih jahti i jedrilica, ih često ipak imaju radi vlastite sigurnosti (a

dijelom i luksuza).

Između brodskih kompanija i davatelja usluga satelitskih komunikacija

posreduje nekoliko različitih vrsta kompanija. Informacijski sustav koji ovaj rad

opisuje je orijentiran Inmarsat satelitskim komunikacijskim rješenjima, pa je

potrebno opisati način na koji Inmarsat obavlja svoje poslovanje.

2.1 Inmarsat

Inmarsat je dugo godina bio sinonim za satelitske komunikacije u

pomorstvu. Proteklih godina se pojavilo mnogo alternativnih komunikacijskih

sustava. Unatoč tomu Inmarsat je i dalje najrasprostranjeniji satelitski sustav čije

se usluge najčešće korisnicima prodaju od strane ISP-ova.

10

Inmarsat trenutno posjeduje i rukuje s 10 satelita, te nudi razna govorna,

podatkovna i IP satelitska komunikacijska rješenja u pomorstvu, aeronautici i na

kopnu [9]. Inmarsat upravlja svojim satelitima iz svog satelitskog kontrolnog centra

(Satellite Control Center) u Londonu, koji je odgovoran da se sateliti nalaze na

ispravnim pozicijama i da su u funkciji [27].

Komunikacija se obavlja tako da pozivi s Inmarsat mobilnog terminala idu

direktno do nekog od satelita, odakle se preusmjeravaju na jednu od zemaljskih

postaja (engl. Land Earth Station - LES) koja ih zatim prosljeđuje u javnu

telekomunikacijsku mrežu [27].

Slika 4 - Pojednostavljeni Inmarsat sustav

Centar za mrežne operacije (engl. Network Operations Center - NOC)

nadzire i upravlja tokom komunikacija kroz Inmarsatovu komunikacijsku mrežu, a

podupiru ga postaje za mrežnu koordinaciju (engl. network co-ordination stations -

NCS). Postoji po jedan NCS za svaku oceansku regiju te za svaki od Inmarsatovih

sustava, a uloga im je da komuniciraju s operatorima zemaljskih postaja (engl.

11

Land Earth Station Operators - LESO), ostalim NCS-ovima te s NOC-om u svrhu

raspodjele operacijskih informacija kroz sustav [27].

Prije nego što je moguće koristiti Inmarsatov mobilni terminal za

komunikaciju, potrebno je obaviti proces aktivacije usluge. Aktivacija usluge je

formalni proces registriranja Inmarsatovih terminala, a sastoji se od

administrativne registracije podataka o opremi krajnjeg korisnika, te uključivanja

Inmarsat terminala na Inmarsatov satelitski komunikacijski sustav od strane

LESO-a [12].

Aktivacija usluga na Inmarsat mobilnim terminalima se obavlja putem

takozvanih točaka za aktivaciju usluga (engl. Point of Service Activation - PSA).

PSA je entitet koji na osnovu ugovora s Inmarsatom obavlja aktivaciju te održava

zapise i račune Inmarsatovih mobilnih terminala. Brodske kompanije (direktno ili

posredno) od PSA traže aktivaciju usluga na svojim uređajima putem obrasca za

zahtjev za aktivacijom usluga (engl. Service Activation Request Form - SARF).

PSA se brine da su svi podaci na zahtjevu ispravni, te da podliježu raznim

financijskim, pravnim i ugovornim uvjetima za registraciju, što uključuje nacionalne

i međunarodne propise [12].

Da bi PSA odobrio zahtjev za aktivacijom usluge mora imati potvrdu da je

kompanija dogovorila način plaćanja korištenja usluge putem računovodstvenih

uprava (engl. Accounting Authority - AA) ili davatelja Inmarsatovih usluga (engl.

Inmarsat Service Providers - ISP). AA je organizacija koja se bavi naplatom

komunikacijskih usluga za Inmarsatove terminale, a svrha joj je da radi kao

posrednik između LESO-a i klijenata. ISP je entitet koji ima ugovor s jednim ili više

LESO-a da promovira i prodaje njegove usluge. ISP namijenjen kao alternativa AA

za one terminale koji će se koristiti samo u komercijalne svrhe, a ne u svrhe

sigurnosti ili u slučajevima nužde [12].

Po uspješnoj aktivaciji PSA prosljeđuje klijentu Inmarsat mobilni broj (engl.

Inmarsat Mobile Number - IMN), koji je sličan telefonskom broju u tom što se

putem njega mogu pozivati različiti Inmarsat terminali [12]. Uređaji se deaktiviraju

tako da se PSA proslijedi IMN sa zahtjevom da se deaktivira.

Osim pružanja usluge komunikacije putem svojih LES-a, LESO-i također

imaju pravo onemogućiti pojedinim terminalima pristup Inmarsatovoj

12

komunikacijskoj mreži, obično u slučaju neplaćanja računa od strane vlasnika

terminala. Osim neplaćanja računa, LESO može blokirati terminale ako korisnici

ne poštuju uvjete korištenja, ako uzrokuju smetnje normalnoj operaciji Inmarsatove

komunikacijske mreže ili u slučaju da je terminal prijavljen kao izgubljen ili

ukraden. Blokiranje komunikacije ne utječe na pozive u nuždi, bez obzira na razlog

blokiranja uređaja [12].

Brodari obično imaju posrednike koji se bave komunikacijskim uređajima, a

informacijski sustav koji ovaj rad opisuje je rađen za jednog takvog posrednika.

2.2 Posrednici

Tvrtka za koju je rađen informacijski sustav opisan ovim radom je privatna

tvrtka koja se bavi posredovanjem između brodskih kompanija (brodara) i pitanja u

pogledu satelitskih komunikacija na brodovima. Brodari obično nemaju vremena

proučavati najnovije tehnologije, pravila i propise u svijetu satelitskih komunikacija,

pa imaju koristi od posrednika koji to rade za njih.

Posrednik svojim klijentima nudi razna savjetovanja u vezi satelitskih

komunikacija, primjerice o preporučenim uređajima (odnosno sustavima) za

pojedine brodove, o preporučenim uslugama i naplatnim tarifama koje će se

koristiti na tim uređajima, zatim preporučuje PSA i AA (odnosno ISP) ovisno o

područjima plovidbe brodova, namjeni korištenja uređaja i slično. Posrednik

također klijentima nudi obuku u vezi satelitskih komunikacija (osnove satelitskih

komunikacija, načini i uvjeti korištenja, pravne napomene, obuka za slučaj nužde i

slično).

U ime, odnosno na zahtjev svojih klijenata, posrednik aktivira i deaktivira

komunikacijske uređaje, te pomaže u slučaju nastanka problema pri radu uređaja,

obavljanju komunikacija i plaćanju usluga.

13

3 Informatizacija poslovanja

Da bi uspješno obavljala svoje poslovanje, tvrtka drži evidenciju svih bitnih

podataka o svojim klijentima, njihovim uređajima te o raznim procesima (kao što

su aktivacije i deaktivacije usluga na uređajima). Osim podataka o klijentima, vodi

se i evidencija podataka o raznim davateljima usluga (PSA, AA, ISP), kao i o

proizvođačima uređaja te o samim uređajima, odnosno Inmarsat sustavima.

3.1 Postojeće stanje informatizacije

Evidencija podataka o raznim poslovnim objektima se vodi u Microsoft

Excel, Microsoft Word i u PDF dokumentima. Pošto je hijerarhija poslovnih

objekata složena, ponekad je potrebno da se dijelovi istih zapisa nalaze u više

različitih Excel dokumenata istovremeno.

Svo unošenje informacija u Excel dokumente se obavlja ručno, a ti podaci

se po potrebi koriste za izradu Word dokumenata, na primjer pri aktivaciji usluge

SARF-om. Za neke procese, poput aktivacije usluga na uređajima, čuvaju se

pojedinačni zapisi stanja dokumenta u svakoj pojedinoj fazi (obično u PDF

formatu): originalni SARF, SARF potpisan od strane klijenta, SARF potpisan od

strane AA ili ISP, te SARF odobren od strane PSA s odgovarajućim IMN.

Dokumenti se između tvrtke, klijenta, AA/ISP-a i PSA šalju elektroničkom

poštom, a čuvaju se i elektroničke i isprintane verzije. Za neke od bitnijih Excel

dokumenata se također čuvaju isprintane verzije, a sigurnosne kopije podataka se

obavljaju jednostavnim kopiranjem na vanjski uređaj za pohranu, s navedenim

datumom izrade sigurnosne kopije.

3.2 Trenutni problemi informacijskog sustava

Trenutni problem u informacijskom sustavu je što se svi podaci trebaju

unositi ručno u Excel tablice, odnosno Word dokumente. Pri dodavanju zapisa za

pojedini poslovni objekt potrebno je prvo pronaći odgovarajući dokument, zatim

unutar dokumenta pronaći logičku poziciju za taj zapis (često na osnovu nekog

proizvoljnog pravila), te zatim dodati taj novi redak i unijeti odgovarajuće podatke.

Za većinu dodanih zapisa potrebno je proces ponoviti za neki drugi Excel

dokument u kojemu se nalaze povezani zapisi.

14

Kako se nad zapisima u Excel dokumentima ne vrši normalizacija, ti

dokumenti sadrže mnogo redundantnih podataka. Osim što su podaci redundantni

unutar jednog dokumenta, redundantni su i preko onih dokumenata u kojima se

ponavljaju. Osim što je zbog redundancije unošenje i izmjena zapisa dugotrajan

proces, postoji mogućnost da korisnik zaboravi izmijeniti podatke u nekim od

dokumenata što uzrokuje nekonzistentnost.

Nekonzistentnost se također može pojaviti zbog greške u unosu podataka u

nekom od dokumenata. Excel dokumenti dopuštaju korisniku da unosi kakve god

podatke želi, a na njemu je da zna primijeniti razna poslovna pravila i ograničenja

pri unosu podataka. Ako korisnik sam ne primijeti grešku pri unosu ili narušavanje

nekog pravila, taj zapis će ostati pogrešan. Slično, za proces aktivacije uređaja

korisnik mora popunit SARF tako da pronađe podatke sadržane u više Excel

dokumenata, što je dugotrajan proces tijekom kojeg se znaju događati greške.

3.3 Ciljevi informatizacije

Svrha informacijskog sustava je olakšavanje poslovnog procesa tvrtke tako

da se omogući jednostavna evidencija i obrada poslovnih objekata. Uvođenjem

novog sustava bi se umjesto različitih Excel dokumenata za evidenciju trebala

koristiti jedna aplikacija u kojoj će biti moguće obaviti unose, izmjene i uvid u sve

potrebne zapisa.

Jedan od ciljeva je da se uspostavi sustav u kojem će se podaci za pojedini

entitet unositi na samo jednom mjestu, i to tako da se ne unose redundantni

podaci. To bi trebalo omogućiti brži unos i izmjene zapisa, dok u isto vrijeme

osigurava konzistentnost podataka.

Osim bržeg i efikasnijeg evidentiranja podataka, informacijski sustav bi

trebao olakšati korisniku unos na način da primjenjuje poslovna pravila za

validaciju unesenih vrijednosti. Tako korisnik sustava neće moći unijeti one

vrijednosti koje krše poslovna pravila, što će uvelike smanjiti potencijalne greške

pri unosu.

Novi sustav bi također trebao olakšati pronalaženje zapisa na osnovu

različitih kriterija, te omogućiti korisniku brz i jednostavan pristup svim podacima

koji se vežu na pojedini entitet.

15

Dodatno, cilj je olakšati korisniku izradu potrebnih dokumenata (u ovom

slučaju SARF dokumenta i popisa IMN-a u scenariju deaktivacije usluge) tako da

se takav proces automatizira. Uz automatizaciju pojedinih procesa, novi sustav bi

trebao omogućiti jednostavan ispis bitnih dokumenata te zapisa odabranih na

osnovu različitih kriterija.

3.4 Specifikacije zahtjeva

Specifikacija zahtjeva je izrađena na osnovu zahtjeva naručitelja,

prikupljene dokumentacije, te analize slučajeva korištenja i dokumenata koji

opisuju dio poslovnog procesa tvrtke. Dokumenti su javno dostupni na stranicama

Inmarsata, a to su upute za aktivaciju [12], SARF [11], te upute za popunjenje

SARF dokumenata [10].

3.4.1 Slučajevi korištenja

Slučajevi korištenja služe opisu funkcionalnosti sustava kroz interakciju

korisnika sa sustavom. Opisuju se grafičkim dijelom (dijagramom slučajeva

korištenja) i tekstualnim djelom (najčešće scenarijima) [22].

Slika 5 - Dijagram slučajeva korištenja

16

Slučajevi korištenja koriste se tijekom više faza razvoja sustava. U početnim

fazam modeliranja potrebna funkcionalnost se preslikava u funkcionalnost novog

sustava. U kasnijim fazama, scenariji slučajeva korištenja su vrlo efikasan alat za

testiranja kojim se provjerava da li sustav zadovoljava traženu funkcionalnost.

Slika 5 prikazuje najvažnije slučajeve korištenja sustava opisanog u ovom

radu. Pojam "evidencija" u ovom modelu podrazumijeva skup operacija nad

podacima koji uključuje pregled, unos i izmjene podataka. Jednostavnije radnje

poput mogućnosti ispisa podataka i odabira pogleda na podatke (filtriranje i

sortiranje) se podrazumijevaju, pa nisu opisane pojedinačnim slučajevima

korištenja. U nastavku ovog poglavnja opisani su scenariji navedenih slučajeva

korištenja.

3.4.1.1 Scenarij "evidencija kompanija"

Zaposlenik želi unijeti ili izmijeniti podatke za brodsku kompaniju.

Glavni sudionik:

• Zaposlenik (posrednik).

Ostali sudionici i njihovi interesi:

• Brodar / klijent - daju svoje podatke posredniku, tako da posrednik

može na zahtjev obavljati pojedine poslove u njihovo ime.

Preduvjeti:

• Pojavila se potreba za unosom ili izmjenom podataka kompanije.

Uvjeti uspješnog završetka:

• Podaci kompanije sačuvani su u sustavu.

Glavni scenarij:

1. Zaposlenik otvara pregled postojećih kompanija.

2. Zaposlenik pronalazi i bira kompaniju čije podatke želi izmijeniti, ili

bira opciju za unos nove kompanije.

3. Zaposlenik unosi podatke kompanije (naziv kompanije te razne

kontaktne informacije).

4. Zaposlenik bira opciju pohrane podataka kompanije.

17

5. Sustav pohranjuje podatke kompanije.

6. Ako zaposlenik želi izmijeniti ili unijeti podatke sljedeće kompanije

vraća se na točku 2.

7. Korisnik prekida postupak unosa ili izmjene podataka kompanije.

Alternativni scenarij:

*a) Prilikom rada sustava se dogodila greška.

1. Sustav javlja poruku o grešci.

2. Zaposlenik ispravlja grešku i nastavlja s radom.

*a2a) Korisnik ne može utjecati na nastavak rada.

1. Sustav prekida rad.

4a) Opcija pohrane podataka je onesposobljena.

1. Zaposlenik pregledom podataka pronalazi podatke

označene crveno.

2. Zaposlenik ispravlja greške opisane uz označene

podatke.

3. Nakon ispravka svih greški, zaposlenik se vraća na točku

4 glavnog scenarija.

3.4.1.2 Scenarij "evidencija brodova"

Zaposlenik želi unijeti ili izmijeniti podatke broda.

Glavni sudionik:



• Klijent - daje svoje podatke posredniku, tako da posrednik može na

zahtjev obavljati pojedine poslove u njegovo ime.

Preduvjeti:

• Pojavila se potreba za unosom ili izmjenom podataka broda.


• Podaci broda sačuvani su u sustavu.

Glavni scenarij:

18

1. Zaposlenik otvara pregled postojećih brodova.

2. Zaposlenik bira opciju izmjene ili unosa novih podataka brod.

3. Zaposlenik unosi podatke broda (naziv broda, pozivni znak, IMO

broj, MMSI (engl. Maritime Mobile Service Identity), tip broda, vrstu

korištenja broda, bruto tonažu, kapacitet za osobe, zemlju

registracije, luku registracije i zastavu).

4. Zaposlenik bira kompaniju koja je vlasnik broda.

5. Zaposlenik bira opciju pohrane podataka broda.

6. Sustav pohranjuje podatke broda.

7. Ako zaposlenik želi izmijeniti ili unijeti podatke sljedećeg broda vraća

se na točku 2.

8. Korisnik prekida postupak unosa ili izmjene podataka brodova.

Alternativni scenarij (dodatno postoje isti alternativni scenariji kao i kod

evidencije kompanija koji zbog ponavljanja nisu navedeni u ostalim scenarijima):

4a) Kompanija koju zaposlenik želi odabrati nije evidentirana

1. Zaposlenik bira opciju unosa nove kompanije.

2. Zaposlenik ide na točku 3 scenarija evidencije kompanija.

3. Zaposlenik se vraća na točku 5 glavnog scenarija.

3.4.1.3 Scenarij "evidencija uređaja i usluga"

Zaposlenik želi unijeti ili izmijeniti podatke uređaja i usluga.

Glavni sudionik:



• Klijent - daje svoje podatke posredniku, tako da posrednik može na

zahtjev obavljati pojedine poslove u njegovo ime.

Preduvjeti:

• Pojavila se potreba za unosom ili izmjenom podataka uređaja ili

usluga na njima.


• Podaci uređaja i usluga sačuvani su u sustavu.

19

Glavni scenarij:

1. Zaposlenik otvara pregled postojećih uređaja ili postojećih usluga.

2. Zaposlenik bira opciju za izmjenu ili unos novih podataka uređaja ili

usluga.

3. Zaposlenik unosi podatke uređaja (razni serijski brojevi, podaci o

instalaciji, odabranom PSA i AA/ISP), odnosno usluge (kod usluge,

broj teleprintera ako je primjenjiv, itd.).

4. Zaposlenik bira model uređaja i brod na kojem je instaliran, ili bira

uređaj na koji se usluga odnosi, kao i vrstu usluge.

5. Zaposlenik bira opciju pohrane podataka uređaja ili usluge.

6. Sustav pohranjuje podatke uređaja ili usluge.

7. Ako zaposlenik želi izmijeniti ili unijeti podatke sljedećeg uređaja ili

usluge vraća se na točku 2.

8. Korisnik prekida postupak unosa ili izmjene podataka uređaja ili

usluge.


4a) Brod, model, uređaj ili tip usluge koju zaposlenik želi odabrati

nije evidentirana.

1. Zaposlenik bira opciju unosa novog broda, modela,

uređaja ili tipa usluge.

2. Ovisno o kojem unosu se radi, zaposlenik ide na točku 3

tog scenarija.


3.4.1.4 Scenarij "evidencija proizvođača i modela"

Zaposlenik želi unijeti ili izmijeniti podatke proizvođača, odnosno nekog

modela uređaja.

Glavni sudionik:



20

• Proizvođač - objavljuju svoje podatke kao i podatke o modelima

uređaja koje proizvode, kako bi se ti uređaji mogli promovirati i

prodavati brodskim kompanijama.

Preduvjeti:

• Pojavila se potreba za unosom ili izmjenom podataka proizvođača ili

modela uređaja.


• Podaci proizvođača ili modela sačuvani su u sustavu.

Glavni scenarij:

1. Zaposlenik otvara pregled postojećih proizvođača ili modela

2. Zaposlenik pronalazi i bira proizvođača ili model koji želi izmijeniti, ili

bira opciju za unos novog proizvođača ili modela.

3. Zaposlenik unosi podatke proizvođača (naziv kompanije, skraćenicu,

te razne kontaktne informacije) ili modela (naziv modela te Inmarsat

sustav koji koristi).

4. Zaposlenik za model bira proizvođača tog modela.

5. Zaposlenik bira opciju pohrane podataka proizvođača ili modela.

6. Sustav pohranjuje podatke proizvođača ili modela.

7. Ako zaposlenik želi izmijeniti ili unijeti podatke sljedećeg proizvođača

ili modela vraća se na točku 2.

8. Korisnik prekida postupak unosa ili izmjene podataka proizvođača ili

modela.


4a) Proizvođač modela nije evidentiran u sustavu

1. Zaposlenik bira opciju unosa novog proizvođača.

2. Zaposlenik ide na točku 2 scenarija evidencije

proizvođača.


3.4.1.5 Scenarij "evidencija PSA"

Zaposlenik želi unijeti ili izmijeniti podatke PSA.

21

Glavni sudionik:



• PSA - objavljuju svoje podatke tako da bi brodari mogli koristiti

njihove usluge.

Preduvjeti:

• Pojavila se potreba za unosom ili izmjenom podataka PSA.


• Podaci PSA sačuvani su u sustavu.

Glavni scenarij:

1. Zaposlenik otvara pregled postojećih PSA.

2. Zaposlenik pronalazi i bira PSA za izmijenu, ili unosi novi PSA.

3. Zaposlenik unosi podatke PSA (naziv, broj, te razne kontaktne

informacije).

4. Zaposlenik bira opciju pohrane podataka PSA.

5. Sustav pohranjuje podatke PSA.

6. Ako zaposlenik želi izmijeniti ili unijeti podatke sljedećeg PSA vraća

se na točku 2.

7. Korisnik prekida postupak unosa ili izmjene podataka PSA.

3.4.1.6 Scenarij "evidencija AA / ISP"

Zaposlenik želi unijeti ili izmijeniti podatke AA / ISP.

Glavni sudionik:



• AA / ISP - objavljuju svoje podatke tako da bi brodari mogli koristiti

njihove usluge.

Preduvjeti:

• Pojavila se potreba za unosom ili izmjenom podataka AA/ISP.

22


• Podaci AA/ISP sačuvani su u sustavu.

Glavni scenarij:

1. Zaposlenik otvara pregled postojećih AA/ISP.

2. Zaposlenik pronalazi i bira AA/ISP za izmijenu, ili unosi novi AA/ISP.

3. Zaposlenik unosi podatke AA/ISP (naziv, kod, te razne kontaktne

informacije).

4. Zaposlenik bira opciju pohrane podataka AA/ISP.

5. Sustav pohranjuje podatke AA/ISP.

6. Ako zaposlenik želi izmijeniti ili unijeti podatke sljedećeg AA/ISP

vraća se na točku 2.

7. Korisnik prekida postupak unosa ili izmjene podataka AA/ISP.

3.4.1.7 Scenarij "aktivacija usluge"

Klijent želi da mu se aktiviraju određene komunikacijske usluge na uređaju.

Glavni sudionik:



• Klijent - uređaji koje posjeduje se aktiviraju za komunikaciju.

• PSA - obavlja administrativne procedure vezane uz aktivaciju

uređaja u ime Inmarsata, te dodjeljuje IMN-e.

• AA/ISP - vrše naplatu komunikacije.

Preduvjeti:

• Klijent je zatražio da mu se aktiviraju određene komunikacijske

usluge na uređajima.


• PSA je potvrdio aktivaciju usluge dodjelom IMN, koji su prosljeđeni

korisniku te pohranjeni u sustavu.

Glavni scenarij:

1. Zaposlenik otvara pregled uređaja.

23

2. Zaposlenik pronalazi i bira uređaj čije će se usluge aktivirati, te bira

opciju aktivacije uređaja.

3. Zaposlenik bira usluge koje će se aktivirati, te unosi zemlju aktivacije

i ime osobe u čije ime se zahtijeva aktivacija.

4. Zaposlenik bira opciju aktivacije usluga.

5. Sustav odabrane usluge označuje kao usluge koje su u procesu

aktivacije, pohranjuje podatke te generira SARF.

6. Zaposlenik pregledava SARF, te utvrđuje ispravnost podataka.

7. Zaposlenik prosljeđuje SARF klijentu, koji ga potpisuje, čime se slaže

da su podaci ispravni.

8. Klijent prosljeđuje SARF AA/ISP, koji ga potpisuju, čime se slažu da

su pristali vršit proces naplate u ovom slučaju.

9. Klijent vraća potpisani SARF zaposleniku.

10. Zaposlenik prosljeđuje SARF PSA, koji utvrđuje legalnu i

administrativnu ispravnost unesenih podataka.

11. PSA dodjeljuje IMN-e uslugama, upisuje ih u SARF, te ispunjeni

SARF prosljeđuje zaposleniku.

12. Zaposlenik bira opciju unosa IMN-a za usluge u procesu aktivacije.

13. Zaposlenik unosi IMN-e za odgovarajuće usluge, te bira opciju

aktivacije usluga.

14. Sustav označuje usluge kao aktivirane te pohranjuje podatke.

15. Zaposlenik prosljeđuje IMN-e korisniku.

16. Zaposlenik pohranjuje potrebne dokumente, te završava proces

aktivacije.


3a) Ne postoji niti jedna usluga koja se može odabrati.

1. Zaposlenik bira opciju za unos nove usluge.

2. Zaposlenik ide na točku 3 scenarija za evidenciju usluga.


6a) Zaposlenik utvrđuje da u SARF-u postoji greška.

1. Zaposlenik u popisu usluga koje čekaju aktivaciju

pronalazi usluge koje su se koristile u ovoj aktivaciji.

24

2. Zaposlenik za svaku uslugu bira opciju poništavanja

aktivacije.

3. Zaposlenik identificira zapise koji sadrže greške, te ih u

sustavu pronalazi i ažurira.


*b) Klijent ili PSA su ustvrdili da podaci u SARF-u nisu ispravni.

5. Klijent ili PSA obavještavaju zaposlenika o greškama.

6. Zaposlenik ide na točku 1 alternativnog scenarija 6a.

3.4.1.8 Scenarij "deaktivacija usluge"

Klijent želi da mu se deaktiviraju određeni uređaji.

Glavni sudionik:



• Klijent - uređaji koje posjeduje se deaktiviraju.

• PSA - obavlja administrativne procedure vezane uz deaktivaciju

uređaja, te obavještava AA / ISP o prestanku rada (naplate) usluge.

Preduvjeti:

• Klijent je zatražio da mu se deaktiviraju određeni uređaji.


• PSA je potvrdio deaktivaciju uređaja.

Glavni scenarij:

1. Zaposlenik otvara pregled uređaja.

2. Zaposlenik pronalazi i bira uređaj za deaktivaciju, te bira opciju

deaktivacije uređaja.

3. Zaposlenik potvrđuje deaktivaciju uređaja.

4. Sustav ispisuje popis IMN-a za deaktivaciju.

5. Zaposlenik prosljeđuje IMN-a PSA.

6. PSA potvrđuje deaktivaciju navedenih brojeva.

7. Zaposlenik obavještava klijenta o uspješnoj deaktivaciji te pohranjuje

potrebnu dokumentaciju.

25

3.4.2 Funkcionalni zahtjevi

Funkcionalni zahtjevi opisuju što bi sustav trebao raditi. Navedeni zahtjevi

su većinom izvedeni iz zatjeva naručitelja, dok je dio postavljen na osnovu

strukovnog znanja, odnosno iskustva. Većina ovih zahtijeva je realizirana u

trenutnoj verziji sustava.

Funkcionalni zahtjevi su:

• Omogućiti unos i izmjene podataka za sljedeće kategorije:

o Brodske kompanije;

o Brodove u posjedu tih kompanija;

o Uređaje za satelitsku komunikaciju na tim brodovima;

o Aktivirane i deaktivirane usluge za komunikaciju;

o PSA entitete;

o AA entitete;

o ISP entitete;

o Proizvođače uređaja za satelitsku komunikaciju;

o Modele uređaja za satelitsku komunikaciju.

• Za kategorije zapisa koji su niže u logičkoj hijerarhiji omogućiti odabir

zapisa koji je iznad njega. Primjerice da bi se navela kompanija u

zapisu broda, trebalo bi moći odabrati postojeću kompaniju (s njenim

podacima). Prilikom odabira zapisa koji je iznad u hijerarhiji potrebno

je, u slučaju da ne postoji, omogućiti stvaranje takvog zapisa bez

odbacivanja unesenih podataka za trenutni zapis.

• Omogućiti opširno vođenje kontaktnih podataka za one kategorije

zapisa za koje je to relevantno, a to uključuje:

o Adresne informacije (ulica i broj, grad, regija, ZIP, zemlja);

o Broj telefona (poslovni, osobni i za slučaj nužde);

o Broj telefaksa;

o Adresu elektroničke pošte (e-mail);

o Internetsko sjedište (website);

o Različite podatke za operativna pitanja, pitanja naplate usluga

i za slučajeve nužde, tamo gdje je to primjenjivo.

26

• Pri izmjeni zapisa potrebno je čuvati sve verzije starih podataka s

datumima kada su promjene nastale, te primijeniti jednostavan način

prepoznavanja dijelova zapisa koji su izmijenjeni. Zahtjev trenutno

nije ispunjen jer se povijesni zapisi tiču ne tiču operativnog dijela

sustava već analitičkog, odnosno to su podaci koji ne spadaju u

transakcijsku bazu podataka već u skladište podataka.

• Na unos i izmjene podataka je potrebno primjenjivati poslovna

pravila, te u što većoj mjeri onemogućiti unos neispravnih ili

nepotpunih podataka.

o Ako je unos određenog podatka za neki zapis obavezan,

korisniku će na jasan način biti naznačeno polje za unos tog

podatka.

o Ako se za neke podatke zna kakav im treba biti oblik, korisnik

će u slučaju pogrešnog unosa biti obaviješten na koji način

može tu grešku ispraviti, odnosno koji je očekivani oblik

podatka koji se u to polje unosi.

o Korisnik neće moći pohraniti zapis ako postoji prepoznata

greška u nekom od polja unosa.

• Omogućiti jednostavan pregled podataka, i to:

o Prikazati podatke odabrane kategorije u tabličnom prikazu;

o Za odabrani pojedini zapis prikazati detaljne informacije.

• Omogućiti brz ugnježđen pristup nižim razinama podataka, primjerice

odabirom pojedine kompanije u tablici kompanija bi se trebalo brzo i

jednostavno moći prikazati tablica sa svim brodovima koje ta

kompanija posjeduje. Trenutno nije primijenjeno zbog previda.

• Omogućiti filtriranje tablica zapisa određene kategorije na osnovu

bilo kojeg podatka koji je direktno ili hijerarhijski vezan uz taj zapis.

Filtriranje bi trebalo omogućiti po više kriterija istovremeno, i to uz

odabir kriterija usporedbe (npr. jednako, veće, manje, slično itd.).

• Za bilo koju kategoriju zapisa omogućiti odabir podataka koji će se

prikazati u tablici. Podaci koji će se prikazivati se trebaju moći

izabrati iz trenutne ili hijerarhijski nadređene kategorije zapisa, te se

trebaju moći proizvoljno poredati.

27

• Zapisi prikazani u tablicama bi se trebali moći poredati (sortirati) po

različitim kriterijima, na osnovu bilo kojih podataka koji su direktno ili

hijerarhijski vezani uz kategoriju zapisa koji se prikazuju. Uzlazni ili

silazni način sortiranja se bira na razini podatka.

• Zapise u tablicama bi trebalo prikazivati djelomično, odnosno na više

stranica onda kada je prikazan veći broj zapisa. Stranicama

podataka bi trebalo moći pristupati slijedno, te na osnovu odabira

stranice. Trebalo bi biti naznačeno koliko stranica podataka trenutno

ima (prilikom pregleda pojedinih tablica), te koliko je ukupno zapisa

(na osnovu trenutnog pogleda, odnosno filtera).

• Tablice bi trebalo moći ispisati, i to s onim podacima koji su trenutno

prikazani. Širine pojedinih stupaca u tablici bi trebale biti

proporcionalne širinama stupaca na tiskanoj verziji, s tim da treba

postojati mogućnost izmjene širine stupaca. Prije ispisa podataka

omogućiti pregled dokumenta za ispis (engl. print preview).

• Omogućiti automatsko ispunjavanje SARF dokumenta pri aktivaciji,

te popisa IMN-a pri deaktivaciji uređaja.

o Pristup generiranju SARF-a pri aktivaciji, te popisa IMN-a pri

deaktivaciji se obavlja nad postojećim uređajima.

o SARF dokumenti i popisi IMN-a se moraju moći ispisati.

o Prije ispisa korisnik mora moći pregledati podatke, te u slučaju

grešaka otkazati ispis te proces ponoviti nakon ispravke

grešaka.

o Nakon aktivacije odnosno deaktivacije uređaja potrebno je

moći vratiti uređaj u prethodno stanje, odnosno poništiti

procese.

• Omogućiti pregled usluga koje su u procesu aktivacije, odnosno koje

čekaju unos IMN-a, te osigurati brz pristup takvim uslugama za

unošenje odgovarajućih IMN-a.

• Potrebno je moći označiti zastarjele zapise (za primjer, deaktivirane

uređaje) tako da se takvi ne prikazuju u tablicama. Unatoč oznaci

zastarjelosti, potrebno je moći na zahtjev pregledati i takve zapise.

Omogućiti i brisanje podataka za slučaj greške ili testiranja.

28

3.4.3 Nefunkcionalni zahtjevi

Nefunkcionalni zahtjevi za razliku od funkcionalnih ne opisuju što će sustav

raditi, već kakav će sustav biti. To su uglavnom oni zahtjevi koji se ne tiču cilja

zbog kojeg se uvodi sustav, već koji se tiču samog sustava.

• Omogućiti izradu sigurnosne kopije podataka instalacijom alata za

izradu sigurnosnih kopija, ili postavljanjem datoteke baze podataka

na dostupnu lokaciju.

• Omogućiti konzistentan način rada sa sustavom u svrhu olakšanja

korištenja. Ekrani sustava bi se trebali moći upotrebljavati na sličan

način kroz cijeli sustav.

• Sustav bi se trebao moći jednostavno instalirati i deinstalirati od

strane korisnika, uz odgovarajuće upute. Dodatno, sustav bi se

trebao moći instalirati na postojeću opremu naručitelja.

• Sustav bi se u budućnosti trebao moći nadograditi eventualnim

dodatnim funkcionalnostima, te bi trebao imati mehanizam za

održavanje i nadogradnju kao što je mogućnost automatskog

ažuriranja na novu verziju putem interneta.

• Sustav bi trebao sadržavati upute za rad, s korisničke kao i s

administratorske perspektive.

3.4.4 Što sustav neće raditi

U svrhu bržeg i jeftinijeg razvoja potrebno je navesti funkcionalnosti koje

neće biti primijenjene u trenutnoj verziji sustava [25]. Odluke o tomu što se neće

primijeniti se postižu u dogovoru s naručiteljem.

• Sustav neće imati mehanizam za prijavu korisnika u sustav, odnosno

mehanizme autentikacije i autorizacije.

• Sustav neće podržavati višekorisnički distribuirani rad. Ipak, zbog

mogućih nadogradnji u budućnosti, potrebno je sustav napraviti tako

da se prijava na sustav i višekorisnički rad mogu relativno

jednostavno implementirati, primjerice upotrebom višeslojne

arhitekture sustava.

• Sustav neće imati podsustav poslovne inteligencije.

29

4 Modeli sustava

Modelima sustava opisujemo dijelove sustava da bismo mogli donijeti

odluke o tome kako ga izgraditi. Pomoću njih preciziramo doseg projekta, a

pomažu pri razumijevanju problema i usuglašavanju percepcije sustava i stavova

između sudionika (korisnika i informatičara) [5].

4.1 Model funkcija

Modeliranje funkcija obavljeno je pomoću dijagrama dekompozicije funkcija.

Na dijagramu prikazanom na slici 6 predstavljeni su osnovni podsustavi i osnovne

poslovne funkcije informacijskog sustava.

Slika 6 - Dijagram dekompozicije funkcija

30

Poslovni proces modeliran sustavom se može podijeliti na dvije funkcije:

upravljanje zapisima i registracija usluga.

Funkcija upravljanja zapisima se odnosi na vođenje evidencije o raznim

poslovnim objektima. Postoje tri podfunkcije upravljanja zapisima: zapisi klijenta,

zapisi davatelja usluga i zapisi tipova i poslovnih objekata.

Funkcija zapisa klijenta se odnosi na evidenciju onih zapisa koji se tiču

klijenta, a to su zapisi o kompanijama (klijentima), brodovima, uređajima i

uslugama koje se koriste na uređajima. Funkcija zapisa davatelja usluga se odnosi

na zapise PSA, AA ili ISP i proizvođača uređaja. Funkcija zapisa modela i tipova

usluga se odnosi na matične zapise modela, tipova usluga, kao i razni zapisi poput

načina upotrebe brodova, ili korištenog Inmarsat sustava. Ovi zapisi se većinom

sastoje od jedne ili dvije stavke, te se u načelu rijetko mijenjaju.

Funkcija registracije usluga se odnosi na dio sustava koji se bavi

aktivacijom i deaktivacijom usluga na uređajima. Dijeli se na podfunkciju aktivacije

usluga i podfunkciju deaktivacije usluga.

Funkcija aktivacije usluga se odnosi na odabir uređaja, odnosno usluga na

tim uređajima za koje će se tražiti aktivacija, generiranje SARF dokumenta, te

unošenje IMN-a za usluge nakon uspješne aktivacije. Funkcija deaktivacije usluga

se odnosi na odabir usluga za deaktivaciju, te generiranje dokumenta s popisom

IMN-a usluga za koje će se tražiti deaktivacija.

4.2 Model procesa

Modelom procesa prikazujemo način na koji tvrtka kao proces komunicira s

vanjskim entitetima i spremištima podataka. Model procesa se modelira

dijagramom toka podataka, odnosno predstavljen je kroz skupove podataka koji se

kreću kroz sustav [5].

4.2.1 Dijagram konteksta

Dijagram konteksta (slika 7) prikazuje entitete s kojima tvrtka kao proces

komunicira, kao i značajne tokove informacija, odnosno materijala. Dijagram

konteksta prikazuje sustav na najvišoj razini, te definira okruženje sustava i

31

područje analize [5]. Sustav je prikazan kao proces P0. Tokovi informacija su

označeni punim, a tokovi materijala iscrtkanim strelicama.

U poslovnom procesu tvrtke sudjeluje 5 vanjskih entiteta:

• AA / ISP (engl. Accounting Autority / Inmarsat Service Provider);

• Proizvođači uređaja;

• Brodske kompanije;

• Klijenti;

• PSA (engl. Point of Service Activation).

Tvrtka posluje tako da prikuplja informacije od raznih entiteta, te koristi

informacije za pružanje usluga klijentu.

Slika 7 - Dijagram konteksta

32

Brodske kompanije na početku suradnje daju posredniku potrebne podatke

o sebi te postaju klijenti. Kao klijenti, kompanije traže usluge aktivacije ili

deaktivacije uređaja, pri čemu trebaju dati podatke o brodu na kojemu se uređaj

nalazi, o samom uređaju, te podatke o uslugama koje žele aktivirati ili deaktivirati

na uređaju.

Proizvođači daju informacije o modelima uređaja (mogućnosti uređaja, koje

usluge i Inmarsat sustave podržava i slično), računovodstvene uprave (AA / ISP)

daju informacije potrebne za naplatu usluge klijentu, a PSA daje informacije

potrebne za aktiviranje odnosno deaktiviranje usluga. Uz to, PSA je zadužen za

samu aktivaciju i deaktivaciju usluga na uređajima, odnosno provjeru dali je

podneseni SARF ispravno popunjen te dali su dane informacije u skladu s

važećim pravnim propisima. Po uspješnoj aktivaciji usluga, PSA je zadužen za

raspodjelu IMN-a: brojeva potrebnih za obavljanje komunikacije.

4.2.2 Pregledni dijagram

Pregledni dijagram (slika 8) detaljnije prikazuje poslovni proces tvrtke tako

što prikazuje tokove podataka i materijala između značajnih procesa, vanjskih

entiteta i skladišta podataka.

Na dijagramu je prikazano 8 procesa i 11 skladišta podataka. Procesi se

odnose na vođenje evidencije o poslovnim objektima i subjektima, te na pružanje

usluge aktivacije i deaktivacije uređaja, odnosno komunikacijskih usluga. Procesi

P1, P4, P5, P6, P7 i P8 su slični u tomu što se odnose na prikupljanje podataka o

raznim poslovnim objektima i subjektima, i na spremanje (evidentiranje) tih

podataka u raznim skladištima podataka.

Proces P2 je najznačajniji proces, a odnosi se na prikupljanje dostupnih

podataka o poslovnim objektima i subjektima, izradu aktivacijskog obrasca

(SARF), prosljeđivanje obrasca klijentu zatim PSA za aktivaciju, zatim zaprimanje,

evidenciju i prosljeđivanje aktiviranih IMN-a klijentu, te naposljetku arhiviranje

dokumentacije. Valja napomenuti da arhiviranje dokumentacije nije direktno

obuhvaćeno informacijskim sustavom; korisnik se brine o tomu da su dokumenti

generirani aplikacijom spremljeni na odgovarajuću lokaciju.

33

Proces P3 je sličan procesu P2, s razlikom što je potrebno manje podataka;

PSA već ima potrebne podatke koji se vežu na aktivirane usluge, pa je bitno

poslati samo IMN-e koji će se deaktivirati. Slično kao i kod procesa P2, korisnik se

brine o arhiviranju potrebne dokumentacije.

Slika 8 - Pregledni dijagram

34

4.2.3 Razrada procesa preglednog dijagrama

Na sljedećim dijagramima (slika 9 i slika 10) su razrađena dva procesa

preglednog dijagrama. Pošto su procesi evidentiranja raznih poslovnih objekata

slični, izrađen je samo jedan dijagram procesa evidentiranja, P5, koji je

reprezentativan za tu vrstu procesa. Drugi dijagram se odnosi na proces aktivacije

usluga na uređajima, P2.

4.2.3.1 Razrada procesa P5 - Evidencija uređaja i usluga

U procesu evidencije uređaja i usluga (slika 9), klijent daje informacije o

uređajima i uslugama koje želi dodati ili izmijeniti. Proces započinje provjerom je li

taj uređaj već evidentiran. Ako je uređaj evidentiran podaci se ažuriraju novim

podacima, a ako nije onda se dodaju podaci za novi uređaj.

Podaci koji su potrebni za evidenciju uređaja su i podatak o brodu na kojem

se uređaj nalazi, podatak o modelu uređaja, o Inmarsat sistemu koji koristi, kao i

podaci o odabranom AA / ISP, i PSA-u koji će se koristiti za aktivaciju usluga na

tom uređaju. Nakon evidentiranja uređaja na sličan način se evidentiraju (dodaju ili

izmjenjuju) i usluge koje će se na tom uređaju koristiti.

Slika 9 - Dijagram procesa evidencije uređaja i usluga

35

4.2.3.2 Razrada procesa P2 - Aktivacija usluga

Proces aktivacije usluga (slika 10) započinje odabirom uređaja čije se

usluge žele aktivirati, a zatim se u listi raspoloživih usluga biraju usluge koje će biti

aktivirane. Obično se odaberu sve raspoložive neaktivirane usluge. Nakon odabira

uređaja i usluga, generira se SARF dokument. Podaci koji se koriste u generiranju

SARF dokumenta su podaci o kompaniji, brodu, uređaju i odabranim uslugama,

zatim o modelu uređaja, proizvođaču i Inmarsat sistemu koji uređaj koristi, tipu

usluge za odabrane usluge, te podaci o odabranom AA / ISP, kao i o PSA kod

kojeg će se usluge aktivirati.

Po izradi, SARF dokument se šalje klijentu na potpisivanje. Nakon što

klijent vrati potpisani SARF, jedna kopija se evidentira, a druga se šalje PSA na

aktivaciju. Po uspješnoj aktivaciji, PSA kao povratnu informaciju šalje aktivirane

brojeve usluga (IMN), koji se evidentiraju i prosljeđuju klijentu.

Slika 10 - Dijagram procesa aktivacije usluga

36

5 Modeli podataka

Modeliranje podataka je tehnika organiziranja i dokumentiranja podataka

sustava, a vrlo je bitna jer su strukture podataka i njihova svojstva trajniji i stabilniji

od procesa. Podaci su resurs koji se dijeli između većeg broja procesa i zbog toga

moraju biti organizirani na način koji je prilagodljiv poslovnim zahtjevima [5].

Modeli podataka su korisni za komunikaciju s korisnicima i utvrđivanje

nazivlja, kao i za lakše određivanje dosega projekta [5]. U ovom radu podatke

modeliramo pomoću dijagrama entiteti-veze i relacijskog modela baze podataka.

5.1 Dijagram entiteti - veze

Dijagram entiteti veze (engl. entity-relationship, ER diagram) je

specijalizirani dijagram koji služi opisivanju odnosa između entiteta u bazi

podataka [1]. Entitet predstavlja nešto što postoji u stvarnom svijetu i posjeduje

značajke koje ga opisuju i po kojima se razlikuje od svoje okoline. Veze pokazuju

odnos između entiteta, a može izražavati i ulogu entiteta koji povezuje. ER

dijagram također može sadržavati i atribute koji predstavljaju neka obilježja ili

značajke entiteta, kao i ključeve koji predstavljaju atribute koji jednoznačno

identificiraju entitete [5].

Slika 11 prikazuje dijagram entiteti-veze sustava opisanog u ovom radu.

Dijagram je prikazan Chenovom notacijom [1]. Entiteti su označeni kvadratima,

dok su veze označene dijamantima. Poduplani kvadrati označuju takozvane "slabe

entitete": entitete koji ne mogu postojati nezavisno od nekih drugih entiteta. Na

primjer, brod ne može biti evidentiran u sustavu ako nije evidentirana kompanija

koja je vlasnik tog broda.

Na dijagramu su označene i kardinalnosti veza. Na primjer, oznaka "1, 1 - 0,

N" između kompanije i broda znači da za pojedinu kompaniju može biti vezano

nula ili više brodova, dok za pojedini brod mora biti vezana točno jedna kompanija.

Dijagram također pokazuje da neki entiteti, kao što je kontakt, mogu imati

više uloga. Kontakt ima vezu s čak 4 druga entiteta, dok s entitetom kompanija

ima dvije veze koje predstavljaju dvije različite uloge - operacijski kontakt i

sigurnosni kontakt.

37

Na dijagramu radi razumljivosti nisu prikazani atributi koji se vežu na

entitete. Sami atributi (odnosno polja) i ključevi entiteta su prikazani relacijskim

modelom baze podataka (slika 12).

Slika 11 - Dijagram entiteti-veze

38

Pošto je jedan od ciljeva izrade modela podataka utvrđivanje nazivlja u

svrhu lakše komunikacije s korisnicima, za pojedine entitete je potrebno ukratko

opisati njihove atribute, odnosno podatke koji se u njima evidentiraju. Podaci koji

se evidentiraju entitetom kompanije su:

• Naziv kompanije;

• Operacijski kontakt;

• Kontakt za slučaj nužde;

• Kontakt za naplatu.

Podaci koji se evidentiraju entitetom broda:

• Naziv broda;

• Kompanija koja je vlasnik broda;

• Pozivni znak;

• IMO broj;

• MMSI;

• Tip broda;

• Način upotrebe broda;

• Bruto tonaža;

• Kapacitet osoba;

• Informacije o registraciji broda ako je registriran:

o Zemlja registracije;

o Luka registracije;

o Zastava.

Podaci koji se evidentiraju entitetom uređaja:

• Brod na kojem je uređaj instaliran;

• Model uređaja;

• ISN (Inmarsat serial number) za uređaje koji ne koriste SIM;

• SSN (SIM card serial number) za uređaje koji koriste SIM;

• PSA;

• AA (Accounting Authority) ili ISP (Inmarsat Service Provider);

• Informacija o tomu dali je uređaj dio GMDSS instalacije;

• Za uređaje koji nisu primarni uređaji, ISN primarnog uređaja;

39

• Dodatni serijski brojevi za uređaje koji ih podržavaju;

• Datum zadnje aktivacije, deaktivacije i podatak je li uređaj trenutno

aktiviran.

Podaci koji se evidentiraju entitetom usluge:

• Uređaj za koji je zapis evidentiran;

• Tip usluge;

• Kod usluge ako postoji;

• Telex answerback - broj teleprintera, ako je podržan;

• Informacije o aktivaciji:

o Datum aktivacije;

o IMN (Inmarsat Mobile Number).

Podaci koji se evidentiraju entitetima proizvođača uređaja, AA / ISP i PSA

su slični, a odnose se na:

• Naziv PSA, AA, ISP ili proizvođača;

• PSA broj, AA / ISP kod ili skraćeni naziv proizvođača;

• Kontaktne informacije.

Podaci koji se evidentiraju entitetima modela su:

• Naziv modela;

• Proizvođač modela;

• Inmarsat sistem koji model koristi.

Podaci koji se evidentiraju entitetima Inmarsat sistema, tipovima usluga i

načinima upotrebe broda su matični zapisi koji se sastoje od podatka o nazivu i

skraćenici naziva.

Entiteti kontakt i adresa sadrže razne kontaktne podatke, poput brojeva

telefona, telefaksa, adrese elektroničke pošte, internetskog sjedišta (website),

adresne informacije i slično.

Za svaki od entiteta se također vodi i informacija o tomu dali je taj entitet

povijesni zapis (ako entitet ima oznaku povijesnog zapisa, onda se trenutno ne

koristi te nije prikazan u popisima), a dodatno se vodi i bilješka u koju korisnik

može upisati razne napomene.

40

5.2 Relacijski model baze podataka

Relacijski model baze podataka (slika 12) prikazuje logičku raspodjelu

podataka u bazi podataka, prilagođenih za postavljanje upita i manipulaciju putem

sustava za upravljanje bazom podataka (SUBP) [2]. Nazivi tablica i atributa su radi

razumljivosti prevedeni s engleskog (jezika implementacije) na hrvatski.

Relacijski model podataka je normaliziran do 3. normalne forme, zatim

djelomično denormaliziran u svrhu jednostavnosti upravljanja. Normalizacija je

postupak strukturiranja sheme relacijske baze podataka tako da se ukloni što više

neodređenosti (zalihosti). Postoji pet stupnjeva normalizacije kroz takozvane

"normalne forme", od 1NF do 5NF, no većina dizajnera se zaustavlja na 3NF [5].

1NF se zasniva na tomu da nema ponavljajućih grupa, odnosno da je

definiran primarni ključ [5]. Model je normaliziran na 1NF tako što su se

ponavljajuće grupe izdvojile u zasebne tablice. Na primjer, tablica uređaja ne

sadrži ponavljajuće podatke o imenu i pozivnom znaku broda - podaci o brodu su

izdvojeni u zasebnu tablicu.

2NF se zasniva na tomu da su svi neključni atributi u potpunosti zavisni o

čitavom primarnom ključu. Pošto su svi primarni ključevi modela jednodijelni, 2NF

nije primjenljiva. 3NF se zasniva na tomu da je svaki neključni atribut neposredno

zavisan samo o primarnom ključu [5]. Model je normaliziran na 3NF tako što su se

atributi koji su bili zavisni o drugim neključnim atributima izdvojili u zasebne

tablice. Na primjer, tablica modela je sadržavala podatke o nazivu Inmarsat

sistema i skraćenoj verziji naziva Inmarsat sistema, koji su zbog 3NF izdvojeni u

zasebnu tablicu.

Denormalizacija je vršena u pogledu na primarne ključeve tablica, gdje su

uvedeni surogatni ključevi sa samopovećavajućim vrijednostima.

5.2.1 Upotreba LINQ to SQL-a

Tradicionalno, za pristup podacima putem SUBP-a se koristi strukturirani

upitni jezik (SQL) ili pohranjene procedure (engl. stored procedures). SQL je jezik

četvrte generacije (4GL) specifično izrađen za učinkovito korištenje SUBP-a.

SUBP vrši složenu optimizaciju upita prilikom dohvata podataka SQL naredbom,

čime ubrzava vrijeme dohvata podataka, pa se upiti pisani SQL-om mogu izvoditi

41

5-20 puta brže od odgovarajućih upita napisanih u nekom od jezika treće

generacije (poput C, C++) [5].

Slika 12 - Relacijski model baze podataka

42

Zbog fleksibilnosti postavljanja upita nad podacima, mogućnosti SUBP-a da

optimizira upite, i zbog cijene prijenosa podataka između aplikacije i SUBP-a, pri

pristupu i manipulaciji podacima se nastoji što više posla prepustiti SUBP-u. Tako

aplikacije često u svrhu performansi dio logike sustava kodiraju u SQL-u, bilo u

pohranjenim procedurama ili u dinamički izgrađenim upitima. No, problem s tako

pisanim kodom je to što je često teži za održavati nego kod pisan u programskom

jeziku 3. generacije, te nema koristi od raznih pogodnosti i alata razvojnih

okruženja poput automatskog popunjenja (npr. IntelliSense), provjere tipova

podataka (za jezike poput C#), debugiranja i slično.

LINQ to SQL, dio .NET-a 3.5, je napravljen u svrhu upravljanja relacijskim

podacima putem objekata, bez gubitka mogućnosti postavljanja upita. Zasnovan je

na tomu da se upiti pisani LINQ-om prevode u SQL za izvođenje u bazi podataka,

a rezultate upita prevodi u objekte [17]. Infrastruktura LINQ-a omogućuje

dinamičku izgradnju složenih upita, koristeći sve pogodnosti Visual Studio

razvojnog okruženja. Kako su i sami LINQ upiti zapravo podaci, moguće ih je

modularno graditi kroz više metoda, te je moguće različite dijelove logike upita

pisati u drugim slojevima sustava, primjerice u poslovnom sloju.

Pristup podacima u LINQ to SQL-u se obavlja na objektno-orijentirani način

putem objekata mapiranih na relacijsku bazu podataka. Umjesto stranim

ključevima objekti su povezani referencama, pa pojedini objekti mogu sadržavati

kolekcije drugih objekata, čineći takozvani "graf objekata" (engl. object graph).

Pošto graf objekata može biti velik, LINQ to SQL obavlja odgođeno učitavanje

(engl. deferred loading) - učitava podatke (obavlja dodatne upite) samo onda kada

su zatraženi. Dodatno, kako se LINQ izrazi prevode u SQL, moguće ga je koristiti

s različitim SUBP-ima bez potrebe za prilagodbu koda upita [28].

Implementacija ovog sustava koristi LINQ to SQL za obavljanje složenih

upita na bazu. Dio zahtjeva na sustav je da se podaci mogu filtrirati i sortirati po

bilo kojim povezanim kriterijima, da se prikazuju bilo koji povezani podaci (stupci),

te da se obavlja djelomičan dohvat podataka (po stranicama). U tu svrhu se

pomoću generičkih metoda (primjenljivih na bilo koju tablicu podataka) grade

dinamički LINQ to SQL upiti na osnovu odabranih postavki (filtriranje, sortiranje,

stranica), te se njihovim izvođenjem iz baze podataka prenose samo oni podaci

koji su zatraženi, odnosno koji će biti prikazani.

43

6 Dizajn programske podrške

Dizajn programske podrške je proces pretvorbe zahtjeva na programsku

podršku u oblik koji omogućuje programiranje [5]. Program modeliramo s nekoliko

različitih dijagrama, opisujući razne događaje, odnosno aktivnosti u sustavu.

Konkretno, to su dijagrami aktivnosti, dijagrami slijeda i strukturne karte.

6.1 Strukturna karta za funkciju aktivacije usluga

Strukturnom kartom modeliramo program tako što prikazujemo kako se

pojedina funkcija treba obaviti. Strukturna karta je slična dijagramu toka podataka,

s tim da razliku od njega ne prikazuje što treba napraviti, nego kako to treba

napraviti [5].

Slika 13 - Strukturna karta za funkciju aktivacije usluga

44

Strukturna karta za funkciju aktivacije usluga (slika 13) prikazuje način na koji

program obavlja aktivaciju usluga. Na osnovu odabranih kriterija filtriranja,

korisniku se prikazuju zapisi o uređajima, od kojih korisnik odabere uređaj na

kojemu se usluge žele aktivirati. Sustav zatim na osnovu odabranog uređaja

pronalazi i prikazuje sve usluge zapisane za taj uređaj (što je napravljeno

procesom evidencije uređaja i usluga), pa korisnik bira one usluge koje će se

aktivirati.

Sustav na osnovu odabranih podataka obavlja funkciju generiranja SARF

dokumenta. U SARF se upisuju podaci o kompaniji, brodu, uređaju, modelu,

proizvođaču, PSA i AA / ISP, a zatim se upisuju podaci o uslugama iteracijom

kroz kolekciju odabranih usluga. Nakon završenog upisivanja podataka u SARF,

ažuriraju se metapodaci o aktivaciji uređaja (datum aktivacije), kao i podaci o

stanju aktivacije.

Korisniku se prikazuje SARF dokument spreman za pregled i printanje (bilo

fizički ili u PDF dokument). Dio procesa aktivacije koji se odnosi na upis aktiviranih

brojeva usluga (IMN-a) za pojedine usluge po uspješnoj aktivaciji nije opisan ovim

dijagramom jer se odnosi na jednostavnu funkcionalnost ažuriranja podataka o

uslugama.

6.2 Dijagram slijeda za proces aktivacije usluga

Dijagram slijeda prikazuje interakcije objekata u vremenskom slijedu, pa je

izrazito pogodan za modeliranje sustava kod objektno orijentiranog razvoja. [22]

Dijagram slijeda za proces aktivacije usluga je prikazan slikom 14. Dijagram

je grafički prikaz scenarija za slučaj korištenja "aktivacija usluga", s naglaskom na

razmjenu poruka između različitih objekata (bilo objekata unutar sustava ili

vanjskih entiteta) u određenom vremenskom redoslijedu.

Zaposlenik sa skladištima podataka za uređaje i usluge "komunicira" putem

sustava, dok s klijentima i PSA komunicira direktno. Životnim linijama (engl.

lifelines) je predstavljena aktivnost pojedinih objekata u različitim fazama procesa.

Primjerice, sustav ne treba biti aktivan za vrijeme razmjene SARF-a s klijentima i

PSA. Dijagram ima i elemente uvjetnog i ponavljajućeg izvođenja dijelova slijeda.

45

Slika 14 - Dijagram slijeda procesa aktivacije usluga

46

6.3 Dijagrami aktivnosti

Dijagram aktivnosti prikazuje tok rada između objekata nekog slučaja

korištenja, ili tok upravljanja za neku operaciju [22].

Dijagram aktivnosti za evidenciju brodova (slika 15) predstavlja slučaj

korištenja evidencije brodova. Prikazani su uvjeti po kojima se grana izvođenje

radnji, kao i pod-aktivnosti koje predstavljaju druge slučajeve korištenja - unos

kompanija i kategorija načina korištenja broda. Dijagrami aktivnosti za ostale vrste

evidencija su slični ovom, pa nisu posebno obrađeni.

Slika 15 - Dijagram aktivnosti za proces evidencije brodova

Dijagram aktivnosti za proces aktivacije usluga (slika 16) prikazuje slučaj

korištenja aktivacije usluga, a osim raznih uvjetnih grananja prikazuje i paralelizam

izvođenja radnji prilikom dodjele aktiviranih IMN. Osim glavnog scenarija, ovim

dijagramom su prikazani i neki alternativni scenariji, kao što su dodavanje uređaja

i usluga ako nisu pronađeni, i poništavanje aktivacije u slučaju pogreške.

47

Slika 16 - Dijagram aktivnosti za proces aktivacije usluga

48

6.4 Dijagram razreda

Dijagram razreda je prikaz statičke strukture sustava, odnosno njegovih

elemenata (razreda, tipova, itd.), te njihovih međusobnih odnosa [22].

Slika 17 prikazuje dijagram razreda za informacijski sustav opisan ovim

radom. Dijagram je zapravo pojednostavljena verzija dijagrama razreda iz pravog

sustava, s tim da su elementi grupirani u smislene cjeline kako bi se što bolje

prikazala suština sustava. Nazivi elemenata su prevedeni na hrvatski jezik radi

jednostavnosti pregleda, a za pojedine tipove su prikazani samo oni članovi (polja i

metode) koji su reprezentativni za njih.

Dijagram prikazuje i način na koji su elementi logički grupirani, a to su:

• Infrastruktura;

• Prezentacijski sloj (engl. Presentation Layer, User Interface - UI);

• Poslovni sloj (engl. Business Logic Layer - BLL);

• Podatkovni sloj (engl. Data Access Layer - DAL);

• Vanjski elementi.

Pristupi između slojeva aplikacije (UI - BLL - DAL) se obavljaju putem

definiranih sučelja, a koristi se oblikovni obrazac lociranja usluga (engl. service

locator design pattern). Dodatno, svaka razina pristupa samo razini direktno ispod

nje (UI poziva BLL, BLL poziva DAL), te nijedna razina nije svjesna da postoje

razine iznad, što je u skladu s višeslojnom arhitekturom sustava.

Namjena infrastrukturnog dijela aplikacije je definicija elemenata koji su

zajednički za sve slojeve aplikacije (UI, BLL i DAL). Tu spadaju elementi koji

prelaze sve slojeve aplikacije kao što su poslovni objekti, definicije sučelja kao što

su sučelja slojeva, te elementi čija bi se logika mogla koristiti iz različitih slojeva,

kao što je izgradnja dinamičkih upita. Infrastruktura sadrži elemente kao što su:

• Poslovni objekti - definicije razreda koji se odnose na poslovne

objekte kao što su kompanija, brod, uređaj i slično.

• Sučelja BLL i DAL - definiraju način pristupa nižim razinama.

• IValidator - generičko sučelje koje definira pristup elementima koji

služe provjeri ispravnosti unesenih podataka za poslovne objekte.

49

Slika 17 - Dijagram razreda

50

• Elementi odabira prikaza - razredi koji služe odabiru prikaza

podataka, kao što su filteri, načini poretka i odabira projekcije.

• ElementiProjekcije i ParsiranjeProjekcije - elementi koji služe

učitavanju mogućnosti projekcije (koja polja će se inicijalno prikazati,

po kojim poljima će se sortiranje, filtriranje i projekcija moći obavljati,

itd.) iz konfiguracijskih datoteka.

• DinamičkiUpiti - definira generičke metode za dinamičku izgradnju

upita koristeći složene filtere, načine poretka, itd.

Prezentacijski sloj (UI) se odnosi na one elemente koji služe prikazu, unosu

i odabiru podataka, odnosno elemente putem kojih korisnik "upravlja" aplikacijom.

Prezentacijski sadrži elemente kao što su:

• PrikazPodataka - generička kontrola koja služi prikazu podataka za

pojedine poslovne objekte u rešetci podataka (engl. data grid).

• Prozori unosa - prozori putem kojih se obavlja unos podataka za

razne poslovne objekte, i u kojim se poziva validacija unosa.

• ProzorOdabiraZapisa, ProzorAktivacije - prozori koji koriste

PrikazPodataka za prikaz popisa poslovnih objekata koje korisnik

može odabrati. ProzorAktivacije je proširena verzija prozora odabira

zapisa, s tim da se dodatno prikazuju i neka polja unosa te se

pokreće generiranje SARF dokumenta.

• Prozori odabira prikaza - služe odabiru filtera, poretka zapisa i

odabiru elemenata koji će se u rešetci prikazati.

• Aktivacijski dokumenti - kontrole koje služe generiranju dokumenata

kao što je SARF.

• PreglednikDokumenata - služi pregledu dokumenata spremnih za

ispis, kao što su generirani SARF dokumenti, popis IMN-a, ili zapisi

iz PrikazPodataka koji se trebaju ispisati.

Poslovni sloj (BLL) se odnosi na kod koji sadrži poslovnu logiku, a to su

elementi:

• PoslovniSloj - primjenjuje sučelje poslovnog sloja, odnosno daje

logiku pristupa podacima, logiku dobavljanja validatora za pojedine

51

objekte, i logiku učitavanja konfiguracijskih datoteka za elemente

prikaza.

• Validatori - primjenjuju sučelja validatora za pojedine poslovne

objekte, odnosno daju logiku potrebnu za odredit ispravnost

unesenih podataka.

Podatkovni sloj (DAL) se odnosi na logiku pristupa podacima (odnosno bazi

podataka), a sastoji se od elemenata:

• PodatkovniSloj - primjenjuje sučelje podatkovnog sloja, odnosno daje

generičke metode pristupa podacima, a koristi dinamičku izgradnju

upita za filtriranje i sortiranje podataka, i straničenje (engl. paging) za

dohvat pod-skupa rezultata.

• BazaPodataka - generirani razred koji nasljeđuje LINQ to SQL

KontekstPodataka (DataContext) razred, a služi mapiranju

generičkog pristupa na pojedine tablice baze podataka.

Vanjski elementi se odnose na one elemente koji su dio vanjskih biblioteka

koda, u ovom slučaju .NET-a, a prikazani su da bi se predočilo gdje LINQ to SQL i

WPF igraju ulogu u programu. Svi prozori i kontrole se grade nad WPF-om, a

poslovni objekti se mapiraju na podatke pojedinih tablica putem LINQ to SQL-a.

Dobar dio razreda programa koristi elemente generičkog programiranja.

Generičko programiranje (engl. generics), podržano u .NET-u od verzije 2.0+,

dozvoljava definiranje tipova na takav način da nisu ovisni o specifičnom tipu

podatka. Tako je moguće pisati algoritme koji se neće mijenjati bez obzira na

promjenu tipova podataka kojim ti algoritmi manipuliraju [19].

Program je dizajniran tako da se manipulacija poslovnih objekata obavlja

generički - tamo gdje je moguće napisana je samo jedna metoda koja vrijedi za

bilo koji objekt. Primjerice razred PodatkovniSloj nema referencu na poslovne

objekte - kompletna izgradnja dinamičkih upita i dohvat podataka iz baze se

obavljaju generički, bez poznavanja tipa podataka u vremenu izgradnje programa

(engl. compile time). Slično vrijedi i za kontrolu PrikazPodataka u UI sloju.

Mapiranje generičkih metoda na stvarne tipove se obavlja pri odabiru

prikaza u UI sloju, a konfiguracija načina na koji se ti tipovi mogu upotrebljavati je

definirana u XML datoteci koja se putem parsera dobavlja u poslovnom sloju.

52

7 Izrada sustava

Uzevši u obzir da je posrednička tvrtka mala firma kojoj se ne isplati velika

investicija u informatizaciju, aplikacija sustava je rađena tako da koristi što manje

opreme, odnosno u obliku debelog klijenta. Tvrtka trenutno ima samo jednog

zaposlenika (ujedno i vlasnika), i ne očekuje se da će ih biti više, odnosno da će

biti potreban distribuirani rad. Tvrtki se ne isplati ni nabava pune verzije sustava za

upravljanjem bazom podataka, pa se koristi besplatna verzija, Microsoft SQL

Server 2008 R2 Express, koja je ograničena na 10GB podataka po bazi, što bi

trebalo biti dovoljno za potrebe tvrtke u bližoj budućnosti.

Aplikacija sustava je izrađena u C# .NET 4.0 kroz Microsoft Visual Studio

2010 razvojno okruženje. Elementi sustava su raspodijeljeni u Visual Studio

projekte kao na slici 17 (dijagram razreda), pa se aplikacija sastoji od 3 biblioteke

(engl. dynamic-link library - DLL):

• BLL.dll - poslovni sloj aplikacije;

• DAL.dll - podatkovni sloj aplikacije;

• Infrastructure.dll - infrastruktura aplikacije.

te od izvršne datoteke, DBClient.exe, koja je WPF UI aplikacija.

Izrađena aplikacija se isporučuje putem ClickOnce sustava za publiciranje,

koji omogućuje jednostavnu instalaciju i uklanjanje, a baza podataka se inicijalno

stvara izvršavanjem SQL skripte.

7.1 Provjera ispravnosti

Provjera ispravnosti izrađenog sustava se obavljala kroz sve faze izrade.

Prilikom pisanja pojedinih metoda vršilo se testirane jedinki (engl. unit testing)

koristeći i strukturalno (engl. white-box testing) testiranje pomoću debuggera (engl.

step-in debugging) i funkcionalno testiranje (engl. black-box testing) pozivanjem

metoda i provjerom rezultata u debuggeru (engl. step-over debugging).

Slično se testiranje provodilo i za veće komponente sustava, odnosno za

različite DLL-ove. Testiranje komponenti BLL i DAL je olakšano činjenicom da se

sav pristup obavlja preko definiranih sučelja. Elementi UI-a su testirani tako što se

pokušavalo namjerno izazvati grešku neprirodnim korištenjem korisničkog sučelja.

53

Testiranje samog sustava se odvijalo po planu, koji je u suštini provjera

funkcionalnih i nefunkcionalnih zahtjeva u specifikaciji. Za većinu zahtjeva sustav

je prošao testiranje, ali je pronađeno i nekoliko zahtjeva koji nisu ispunjeni.

Zahtjev koji se odnosi na spremanje povijesnih podataka, i zahtjev koji se

odnosi na brzi ugniježđeni pristup podacima su funkcionalni zahtjevi koji nisu prošli

test. Brzi ugniježđeni pristup podacima trenutno nije primijenjen zbog previda, a

spremanje povijesnih podataka nije primijenjeno jer logički spada u kategoriju koja

je trenutno izvan opsega sustava (skladišta podataka i poslovna inteligencija).

Od nefunkcionalnih zahtjeva, izrada sigurnosnih kopija i povratak na neku

od prethodnih verzija je djelomično primijenjen, odnosno moguće ga je izvesti ali

ne kroz samu aplikaciju sustava. Kako se administrativne radnje baze podataka

inače i rade izvan same aplikacije, smatra se da je ovaj test prošao.

Nefunkcionalni zahtjev brzine odziva sustava je prošao test na manjem broju

podataka, ali se smatra da će držati za bilo koju količinu podataka koju tvrtka

može imati. Nefunkcionalni zahtjev mogućnosti instalacije na trenutnoj opremi nije

prošao test. Iako se potrebni programi mogu instalirati (SQL Server, .NET 4.0) na

postojeći OS (Windows XP) i teoretski bi WPF aplikacija trebala raditi na njemu,

instalacija aplikacije na Windows XP jednostavno nije uspjela, bez naznake kako

ispraviti grešku. Rješenje za ovaj problem nije pronađeno, pa sustav trenutno nije

isporučen klijentu.

7.2 Upotreba sustava

Upotreba sustava je detaljno dokumentirana s administratorske i korisničke

strane u XPS dokumentu (na engleskom jeziku) koji se isporučuje uz aplikaciju, a

može mu se brzo pristupiti putem preglednika dokumenata u samoj aplikaciji.

7.2.1 Administratorska uporaba sustava

Administratorska uporaba sustava se tiče obavljanja zadataka koji se tiču

same aplikacije sustava, kao što su instalacija i održavanje.

Instalacija sustava se obavlja nakon instalacije potrebnih programa, a to su

.NET Framework 4.0+ i Microsoft SQL Server 2008 R2 Express, koji su besplatno

dostupni na Microsoftovim internetskim stranicama. Inicijalno je potrebno napraviti

odgovarajuću mapu na definiranoj lokaciji na disku i u nju kopirati instalacijske

54

datoteke. Prije instalacije same aplikacije sustava pokreće se SQL skripta koja na

instanci SQL Servera stvara bazu podataka s potrebnim tablicama. Skripta se

otvara u SQL Server Management Studio Express aplikaciji koja dolazi kao dio

instalacije SQL Servera. Potrebno je osigurati da je pokrenut servis koji predstavlja

instancu SQL Servera na lokalnom računalu.

Po uspješnoj konfiguraciji baze podataka pokreće se ClickOnce instalacija

aplikacije (setup.exe), koja instalira aplikaciju bez potrebe za dodatnom

konfiguracijom. Potrebno je pobrinuti se da antivirusni program ne sprječava rad

aplikacije. Kada je konfigurirano, automatsko ažuriranje podataka se obavlja ako

je nova verzija dostupna pri pokretanju aplikacije, pa nije potrebna korisnička

intervencija.

Datoteke baze podataka se nalaze u unaprijed definiranoj instalacijskoj

mapi, a izrada sigurnosne kopije se može obaviti jednostavnim kopiranjem

datoteka. Pri kopiranju datoteka baze podataka potrebno je privremeno zaustaviti

instancu servisa baze podataka na lokalnom računalu. Dodatno, moguće je

koristiti SQL Server Management Studio Express za napredne mogućnosti izrade

sigurnosnih kopija (inkrementalne sigurnosne kopije itd.), no zbog male količine

podataka to za sada nije potrebno. Povratak na podatke iz sigurnosne kopije

(engl. restore) se obavlja na sličan način.

Uklanjanje aplikacije sustava se obavlja putem konfiguracije instaliranih

programa u kontrolnom panelu operacijskog sustava (engl. program control,

control panel). Ako se deinstalira i SUBP (ako ga druge aplikacije ne koriste), onda

je potrebno napraviti posljednje sigurnosne kopije datoteka baze podataka prije

deinstalacije. .NET Framework nije moguće jednostavno ukloniti, niti se njegovo

uklanjanje preporučuje.

7.2.2 Korisnička uporaba sustava

Uporaba sustava iz korisničke perspektive se odnosi na razne poslove

evidencija kao i obavljanje procesa aktivacije i deaktivacije usluga. Nakon

instalacije aplikacija sustava se pojavljuje u Program Files izborniku. Glavni prozor

aplikacije se sastoji od glavnog izbornika s lijeve strane, od prostora za podatke s

desne strane, te od gornjeg padajućeg izbornika za dodatne radnje.

55

Glavni izbornik je podijeljen u 4 dijela, a to su:

• Zapisi vezani uz klijenta:

o Zapisi kompanija;

o Zapisi brodova;

o Zapisi uređaja;

o Zapisi usluga.

• Zapisi vezani uz druge poslovne entitete:

o Zapisi PSA;

o Zapisi AA / ISP;

o Zapisi proizvođača uređaja.

• Zapisi poslovnih objekata:

o Modeli uređaja.

• Zadaci:

o Usluge koje čekaju aktivaciju.

Odabirom nekog od elemenata izbornika, u desnom dijelu glavnog prozora

se prikazuju podaci za taj element u podatkovnoj rešetci (engl. data grid). Slika 18

prikazuje primjer pregleda podataka za upisane kompanije. Zbog povjerljivosti

podataka, u primjerima aplikacije sustava se ne prikazuju stvarni poslovni podaci.

Slika 18 - Pregled podataka

56

Odabirom pojedinog elementa u prikazu podataka prikazuju se detalji

izabranog zapisa. Stupci koji se prikazuju u pregledu podataka, koji podaci su

prikazani i način na koji su podaci poredani se inicijalno postavlja u

konfiguracijskoj datoteci aplikacije. Opcijama izmjene filtera, načina poretka i

prikazanih podataka se izmjenjuju načini na koji se podaci u rešetci prikazuju.

Slika 19 prikazuje prozor izmjene načina poretka podataka.

Slika 19 - Opcije sortiranja prikaza

Korisnici mogu stvoriti složene filtere i načine poretka za prikaz podataka, i

odabrati koji će se podaci u rešetci prikazivati, što je detaljnije pojašnjeno u

korisničkoj dokumentaciji.

Slika 20 - Unos podataka

57

Unos podataka se obavlja odabirom opcije za unos novog entiteta ili opcije

za izmjenu postojećeg entiteta u donjem desnom dijelu prikaza podataka, ispod

detalja. Slika 20 daje primjer unosa podataka za brod.

Prilikom unosa postoje tri različita načina unosa podataka - izravno

upisivanje podataka, izbor iz pripremljenog popisa, i označavanje vrste podatka

kvačicama (engl. checkbox). Za pojedina polja u koje se podaci upisuju postoje

pravila kako taj podatak mora biti oblikovan, što je definirano poslovnom logikom.

U slučaju neispravnog unosa izmjenu nije moguće prihvatiti, a neispravna polja se

označuju crvenom bojom. Prelaskom miša preko nekog od neispravnih polja

prikazuje se uputa kako pogrešku ispraviti. Slika 20 prikazuje primjer neispravnog

unosa IMO polja i uputu za ispravak pogreške.

Za polja odabira se otvara novi prozor u kojem je prikazan popis

odgovarajućih zapisa od kojih je jednog potrebno odabrati. Ako takav zapis ne

postoji, u ovom prozoru je moguće otvoriti dodatni prozor unosa i stvoriti novi

zapis. Polja odabira su često obavezna, pa se također označuju crvenom bojom

ako nijedan zapis nije odabran.

Aktivacija usluga se obavlja odabirom opcije za aktivaciju u detaljima

pojedinih uređaja. Slika 21 prikazuje prozor aktivacije, koji daje korisniku izbor

usluga koje će se za taj uređaj aktivirati.

Slika 21 - Aktivacija usluga

58

Po odabiru usluga i aktivacije, generira se SARF dokument i prikazuje se u

pregledniku dokumenata. Slika 22 prikazuje primjer generiranog SARF-a.

Slika 22 - Generirani SARF prikazan u pregledniku dokumenata

Usluge za koje je generiran SARF ulaze u stadij čekanja aktivacije,

odnosno čekaju da im se dodjeli IMN prije nego u sustavu postanu aktivirane.

Usluge koje čekaju aktivaciju su prikazane u odgovarajućem izborniku, a pri

pokretanju aplikacije se prikazuje broj usluga koje čekaju aktivaciju i poveznica na

prikaz tih usluga.

Usluge koje čekaju aktivaciju se mogu poništiti (zbog pogreške pri unosu i

slično), čime se vraćaju u stadij neaktiviranih usluga. Deaktivacija se obavlja na

sličan način kao i aktivacija.

7.3 Buduća nadogradnja

Sustav je dizajniran tako da daje mogućnosti budućoj nadogradnji. Pošto

ClickOnce podržava automatsko ažuriranje softvera na najnoviju verziju, sustav

ima mogućnost da se ažurira putem interneta, bez potrebe prisutnosti sistemskog

inženjera (odnosno osobe koja obavlja administratorske dužnosti). Ovaj način

raspodjele sustava pojednostavljuje proces ispravljanja pogrešaka i omogućuje

djelomičnu nadogradnju. ClickOnce je primjenjiv samo na aplikaciju - za sve

59

izmjene vezane za bazu podataka je potrebno izvesti odgovarajuće SQL skripte

ručno, pa "veće" promjene nisu moguće samo putem ClickOnce.

Kako je pristup podacima sustava rađen u LINQ to SQL-u, teoretski je

moguće koristiti drugi SUBP (primjerice Oracle) bez potrebe za izmjenom koda

koji generira upite, upotrebom besplatno dostupnih biblioteka [28]. Ako bi se htio

koristit SUBP koji nije podržan besplatno dostupnim bibliotekama, bilo bi potrebno

napraviti posebni pružatelj za LINQ to SQL na taj SUBP, što je vrlo opsežan posao

koji iziskuje detaljno poznavanje LINQ to SQL-a, .NET-a i korištenog SUBP-a.

Promjene SUBP-a se ne mogu obavljati automatski putem ClickOnce, jer ih je

potrebno individualno instalirati i konfigurirati na korisničkom računalu.

Sustav je rađen u slojevima da olakša eventualni prijelaz na višekorisnički

rad. Ukoliko bi se sustav koristio s više računala, između UI i BLL-a bi bio ubačen

dodatni sloj pristupa mreži, koji bi povezivao klijenta sa serverom u klijentsko-

poslužiteljskoj (engl. client-server) arhitekturi sustava. Metode svih slojeva bi

mogle ostati iste, no u mrežnom i UI sloju bi trebalo dodatno dodati mehanizme za

autentikaciju i autorizaciju korisnika, kao i odgovarajuće tablice u bazi podataka,

uz dodatne zapise praćenja pristupa podacima.

Ako bi se prešlo na klijentsko-poslužiteljsku arhitekturu, server koji sadrži

poslovnu logiku i logiku pristupa podacima (i po mogućnosti bazu podataka ako

nije izmještena na drugi server) bi trebao biti stalno dostupan na mreži. Za javno

dostupnu mrežu bi bile potrebne značajne investicije u opremu ako bi se odlučilo

kupiti server, a dodatno bi bilo potrebno osigurati solidnu brzinu slanja podataka

(engl. upload) i registrirati dediciranu IP adresu kod operatera. Alternativno, bilo bi

potrebno iznajmiti server (i bazu podataka) na nekom online hostingu.

Ako bi operacija ikada prešla na vrlo veliki broj korisnika raspodijeljenih po

različitim regijama, bilo bi potrebno uvesti distribuirane baze podataka (od kojih bi

svaka sadržavala podatke bitne za tu regiju) koje zbog složenosti iziskuju

nabavljanje komercijalnih verzija SUBP-a, što je značajna investicija. Slično,

ukoliko bi se htio uvesti sustav poslovne inteligencije (BI) koji koristi napredne

analitičke mogućnosti skladišta podataka u SUBP, bilo bi potrebno kupiti

komercijalnu verziju SUBP-a. Ove vrste proširenja su daleko izvan opsega

studentskog projekta.

60

Zaključak

Rad je pokazao primjer izrade informacijskog sustava primjenom

programskog inženjerstva. Na početku rada je objašnjena potreba za

informacijskim sustavima u današnjem poslovanju, a zatim su u teoretskom dijelu

objašnjeni pristupi projektiranju informacijskih sustava.

Kako se radi o projektiranju specifičnog sustava ukratko je pojašnjena i

problematika, odnosno način obavljanja satelitske komunikacije u pomorstvu

pomoću Inmarsatovog komunikacijskog sustava. Pojašnjene su i zainteresirane

strane u procesu obavljanja satelitskih komunikacija.

Naručitelj sustava je dao objašnjenje kako sustav komunikacija funkcionira

te njegovu viziju što bi u informacijskom sustavu trebalo biti napravljeno, no tek je

analiza poslovne dokumentacije (SARF-a, Inmarsatovih uputa za aktivaciju, itd.)

pokazala kakav sustav treba biti. Izrađeni su i scenarijima detaljno opisani

slučajevi korištenja sustava. Na temelju zahtjeva, analize, slučajeva korištenja i

iskustva, izrađena je specifikacija zahtjeva.

Modeliranje sustava, podataka i događaja je pomoglo razvojnom timu u

smislu olakšane komunikacije unutar i izvan tima te u smislu boljeg vlastitog

shvaćanja sustava. Dobro definiran model podataka znatno olakšava izradu

sustava, a modeli događaja u programu (dijagrami slijeda, aktivnosti itd.) daju

detaljan opis koraka pojedinih radnji.

Iako je dizajn sustava uvelike olakšao njegovu izradu, tijekom programiranja

su ipak nastale određene greške. Testiranjem je dio grešaka uklonjen, no za neke

nije pronađeno rješenje. Kako postoje neki zahtjevi koji još nisu ispunjeni

(konkretno, mogućnost instalacije sustava na postojeću opremu), sustav trenutno

nije isporučen klijentu u operativnu upotrebu.

Na kraju, planiranje mogućnosti budućih izmjena pri odabiru arhitekture je

ostavilo mogućnost za nadogradnje. Može se zaključiti da je primjena

programskog inženjerstva iznimno korisna prilikom projektiranja manjih, a

neophodna prilikom projektiranja većih informacijskih sustava.

Reference i literatura

[1] Chen, P. P., The Entity-Relationship Model: Toward a Unified View of Data,

ACM Transactions on Database Systems, 1, 1976.: 9-36

[2] Codd, E. F., The Relational Model for Database Management: Version 2,

Addison-Wesley, 1990.

[3] Čerić, V., Varga, M., Informacijska tehnologija u poslovanju, Element,

Zagreb, 2004.

[4] Denning, P. J., Computer science: The discipline, in Encyclopedia of

Computer Science, 4th ed, Wiley, 2003.

[5] Fertalj, K., Kalpić, D., Predavanja iz kolegija Projektiranje Informacijskih

Sustava, akad. god. 2006/7, FER. URL: (14. 08. 2012)

http://www.zpr.fer.hr/zpr/Portals/0/Predmeti/PIS/PIS-Predavanja.pdf

[6] Gheorghiu F., Why companies fail on the way to implementing project

management methodology, Project Management Today 8(10), 2006.

[7] IEEE, IEEE Standard Glossary of Software Engineering Terminology, Std

610.12-1990, URL: (16.08.2012)

http://trempet.uqam.ca/Enseignement/Normes/IEEE_STD610_12-1990.pdf

[8] IMO, International SOLAS Convention, URL: (10. 08. 2012)

http://www.imo.org/About/Conventions/ListOfConventions/Pages/Internation

al-Convention-for-the-Safety-of-Life-at-Sea-%28SOLAS%29,-1974.aspx

[9] Inmarsat, About Inmarsat, URL: (11. 08. 2012)

http://www.inmarsat.com/About/?language=EN&textonly=False

[10] Inmarsat, Notes for completing the Maritime form, URL:

http://www.inmarsat.com/Downloads/English/Support/Sarfs/Inmarsat_mariti

me_notes.pdf (12. 08. 2012)

[11] Inmarsat, SARF for Maritime terminals, URL:

http://www.inmarsat.com/Downloads/English/Support/Sarfs/Inmarsat_mariti

me.pdf (12. 08. 2012)

[12] Inmarsat, Service Activation - Inmarsat C, URL:

http://www.inmarsat.com/Support/Inmarsat_C/Activation.aspx (11. 08. 2012)

[13] Kaplan B., Harris-Salamone, K., Health IT success and failure:

Recommendations from literature and AMIA workshop, Journal of the

American Medical Informatics Association 16(3), 2009.: 291-299.

[14] Kendall, S., The unified process explained, Addison-Wesley Longman

Publishing Co, 2002.

[15] Krile, S., Elektroničke komunikacije u pomorstvu – Mobilne satelistke veze,

Sveučilište u Dubrovniku,Dubrovnik, 2004.

[16] Mayo, J., C#, Biblioteka Ekspert, Miš d.o.o, 2002.

[17] MSDN, .NET Language-Integrated Query for Relational Data, URL:

http://msdn.microsoft.com/en-us/library/bb425822.aspx (17. 08. 2012)

[18] MSDN, ClickOnce Deployment, URL: http://msdn.microsoft.com/en-

us/library/t71a733d%28v=vs.80%29.aspx (17. 08. 2012)

[19] MSDN, Introduction to Generics, URL: http://msdn.microsoft.com/en-

us/library/ms379564%28v=vs.80%29.aspx (25. 08. 2012)

[20] MSDN, Introduction to Windows Presentation Foundation, URL:

http://msdn.microsoft.com/en-us/library/aa970268.aspx (17. 08. 2012)

[21] MSDN, LINQ (Language-Integrated Query), URL:

http://msdn.microsoft.com/en-us/library/bb397926.aspx (17. 08. 2012)

[22] OMG, OMG Unified Modeling Language Superstructure, ver. 2.3, May

2010., URL: http://www.omg.org/spec/UML/2.3/Superstructure/PDF/

(20.08.2012.)

[23] Pressman, R., Software Engineering: A Practitioner's Approach, 7th ed.,

McGraw-Hill, 2009.

[24] Sommerville, I., Software Engineering, 8th ed., Pearson Education, 2007.

[25] Spolsky, J., Painless Funcional Specifications, Joel on Software URL:

http://www.joelonsoftware.com/articles/fog0000000035.html (14. 08. 2012)

[26] Wikipedia, Software development process, URL:

http://en.wikipedia.org/wiki/Software_development_process (16. 08. 2012)

[27] World Communication Center, How the Inmarsat System Works, URL:

http://www.wcclp.com/index.asp?pgid=32 (11. 08. 2012)

[28] ***, DbLinq, LINQ provider for Oracle, URL:

http://code.google.com/p/dblinq2007/ (21. 08. 2012)

Sažetak

Ovaj rad opisuje izradu informacijskog sustava za evidenciju uređaja za

satelitsku komunikaciju u pomorstvu primjenom discipline programskog

inženjerstva. U radu se govori o potrebi informacijskih sustava u današnjem

poslovanju i o modelima razvoja informacijskih sustava, a zatim se obrađuje

problematika poslovnog procesa evidencije poslovnih objekata i aktivacije /

deaktivacije uređaja za satelitsku komunikaciju. Opisani su scenariji korištenja

sustava i izrađena je specifikacija zahtjeva, a sustav i podaci su opisani s nekoliko

modela. Opisana je realizacija aplikacije, i načini upotrebe sustava s korisničkog i

administratorskog stajališta, a govori se i o mogućnostima izmjena i nadogradnje

sustava u budućnosti.

Ključne riječi: programsko inženjerstvo, projektiranje informacijskih

sustava, satelitske komunikacije u pomorstvu, modeliranje sustava, baze podataka

Summary

This paper is about the application of software engineering techniques in

the development of an information system for recording data related to maritime

satellite communication equipment. Arguments are given in favor to the necessity

of information systems in todays businesses, and the theoretical part of the paper

describes various models of system development, as well as the basic principles

of maritime satellite communications. Use cases are described with scenarios, and

the requirements specification for the system is given. The system and its data are

described with various models. The information system has been implemented as

an application, so the paper also gives usage instructions with respect to both the

user and the administrator perspective. A brief section discusses the possibilities

of future changes or upgrades to the system.

Keywords: software engineering, information systems design, maritime

satellite communications, system modeling, database systems

593801.ndraskovic-diplomski

Documents