Bab III ANALISA
III.1 Analisa Data Geografi Pemodelan dunia nyata memudahkan manusia di dalam studi area aplikasi yang dipilih dengan cara mereduksi sejumlah kompleksitas yang sebenarnya hadir. Pembawa informasi di dalam model-model data adalah obyek. Obyek ini berhubungan dengan entitas di dalam model-model dunia nyata karena itu dianggap sebagai deskripsi fenomena dunia nyata. Suatu obyek memiliki properti yaitu geometri dan non geometri. Sebagai contoh, suatu gedung ITB memiliki properti koordinat lokasi titik(x,y) (jika dipandang sebuah titik) dan memiliki data non geometri yaitu nama gedung, tahun pendirian, jumlah lantai dan keterangan yang lain.
Data geografi yang digunakan sebagai pewakilan dari obyek-obyek tersebut disimpan dalam sebuah file ataupun database spasial. Sebuah penyimpanan data geografi selanjutnya disebut datastore, terdiri dari data lokasi dan data atribut, terdapat dua format umum yang sekarang ada yaitu datastore yang data lokasi dan data atribut terpisah (fisik penyimpanan) dan datastore yang data lokasi dan data atribut diletakan pada satu tempat yang sama atau lebih dikenal sebagai database spatial. Pada Gambar III-1 adalah contoh dari data store yang data lokasi dan data atribut dibedakan dalam 3 file penyimpanan yaitu a. file pertama adalah file penyimpanan data lokasi b. file kedua adalah file penyimpanan data atribut c. file ketiga adalah file indeks (pengaksesan secara langsung).
Pada Gambar III-2 adalah contoh dari database spasial yang data atribut dan data lokasi disimpan dalam satu tabel, dan salah satu kolom dari tabel tersebut menyimpan data mengenai lokasi tersebut. Pada sub bab di bawah ini (III.1.1 dan III.1.2) dijabarkan dua contoh format datastore data geografi. 15
III.1.1 Shapefile
Setiap shapefile menyimpan informasi geometri dan tekstual dari obyek-obyek spasial yang bertema sama dan mempunyai fungsi yang sejenis. Geometri obyek spasial disimpan sebagai sebuah bentuk (shape) yang disusun oleh himpunan vektor. Shapefile dapat menyimpan bentuk berupa titik, garis dan area. Area direpresentasikan
sebagai
poligon
tertutup
dan
didigitasi
ganda
pada
persinggungan dengan area tetangga. Atribut tekstual disimpan dalam file terpisah dengan format dBase (dbf) yaitu suatu format file dari Inprise Corp untuk menyimpan tabel data relasional. Setiap rekord atribut mempunyai hubungan satu ke satu dengan rekord bentuk berdasarkan urutan kemunculannya. Sebuah datastore shapefile terdiri atas tiga buah file yaitu: 1. shp (suatu file yang digunakan untuk menyimpan data spasial). 2. shx (suatu file yang digunakan untuk mengakses rekord secara langsung. 3. dbf (suatu file yang digunakan untuk menyimpan data atribut).
Gambar III-1 DataStore dalam bentuk shapefile
Gambar III-2 DataStore DBMS Spatial (Postgre/PostGIS)
16
dBase
shp
shx
Table record
FH
RH
FH
IR
RC
Gambar III-3 Hubungan shp, shx dan dbf
dengan : FH : File Header RH : Record Header RC : Record Content IR : Index Record File header (FH) dapat berisi versi format file, jenis figur/bentuk geometri (titik, polyline dan polygon), dan kordinat pembatas (bounding box). Setiap rekord memiliki rekord header dengan panjang tetap (8 byte), berisi informasi id rekord dan panjang isi rekord. Isi rekord menyimpan data sesuai dengan jenis bentuk, diawali dengan satu byte untuk menyatakan jenis bentuk, Jenis bentuk ini harus sesuai dengan jenis bentuk yang dinyatakan dalam file header, namun boleh berisi 0 (tanpa geometri).
Untuk bentuk titik, data disimpan dalam nilai x dan y yang masing-masing berukuran 8 byte. Struktur isi rekord untuk figur titik adalah sebagai berikut : Titik { x:Double; y:Double; }
Untuk figur polyline, data disimpan adalah informasi mengenai bounding box dari polyline, jumlah segmen, jumlah titik, nomor-nomor indeks yang menunjuk pada titik pertama dalam segmen dan nilai-nilai(x,y) sebanyak jumlah titik. Struktur isi rekord untuk figur polyline adalah sebagai berikut: Polyline{ BoundingBox : Double[4] //Kotak pembatas NumPoint : Integer // jumlah segmen NumPoints:Integer // jumlah total titik dari semua segmen Parts:Integer[NumPoint] //Deretan indek ke titik pertama dalam segmen
17
Pointb:Integer[NumPoints] bagian }
//Deretan titik untuk semua
Jenis bentuk geometri dalam file header antara lain adalah 1 (point/titik), 3 (polyline/garis), 5 (polygon/luasan), 8 (multipoint) sedangkan untuk file header dbf (data non geometri) antara lain adalah C (char), N (numeric), F (numeric float) , L (boolean), dan D (date).
Untuk figur poligon, strukturnya sama dengan figur arc/polyline, bedanya hanya terletak pada interpretasi deretan titik, apakah diinterpretasi sebagai segmen garis atau sebuah poligon yang memiliki area (fill area). III.1.2 Database Spatial Postgre/PostGIS
Postgre menggunakan postgis sebagai ekstensinya dalam menangani data geografis. Postgis spasial obyek didefiniskan dengan dua cara yaitu 1. WKT (Well Known Text) 2. WKB (Well Known Binary) WKT lebih mudah digunakan daripada WKB dikarenakan berbentuk file teks. Contoh dari representasi WKT objek spasial adalah : 1. POINT(0 0) 2. LINESTRING(0 0,1 1,1 2) 3. POLYGON((0 0,4 0,4 4,0 4,0 0),(1 1, 2 1, 2 2, 1 2,1 1)) 4. MULTIPOINT(0 0,1 2) 5. MULTILINESTRING((0 0,1 1,1 2),(2 3,3 2,5 4)) 6. MULTIPOLYGON(((0 0,4 0,4 4,0 4,0 0),(1 1,2 1,2 2,1 2,1 1)), ((-1 -1,-1 2,-2 -2,-2 -1,-1 -1))) 7. GEOMETRYCOLLECTION(POINT(2 3),LINESTRING((2 3,3 4))) Pada postgre mengakses rekord-rekord dengan menggunakan perangkat lunak koneksi seperti jdbc (java database connector) ataupun zeos (untuk pascal). Pada postgre data geografi yang terdiri dari data lokasi dan data atribut digabungkan dalam satu tabel ( Gambar III-2).
18
Di bawah ini adalah contoh pengaksesan dengan menggunakan perintah sql : 1. SELECT
"id",
AsText(force_2d("the_geom")),
"name"
FROM
"public"."road" 2. INSERT INTO public.road (id,name, the_geom) VALUES (1,'road test',GeometryFromText('LINESTRING (1 1, 2 2, 4 2, 5 1)', 0 )).
III.2 Analisa MultiFormat Data Geografi Dari contoh dua format data di atas yaitu shapefile (database file) dengan postgre/postgis (database spatial) terdapat beberapa hal yang dapat dicermati dengan baik yaitu walaupun representasi penyimpanan data geografi tersebut berbeda tetapi secara konseptual (konsep) terdapat kesamaan yaitu terdapat dua data utama yaitu : 1. data lokasi (data spasial), atau biasa disebut sebagai data geometri, yaitu data yang menangani keterangan mengenai representasi keterangan mengenai bentuk/shape dari data lokasi. 2. data non lokasi atau biasa disebut sebagai data atribut/tekstual, yaitu data yang menangani keterangan non geometri, misal nama kota, keterangan jumlah penduduk, keterangan luas daerah dan lain-lain yang sifatnya menjelaskan mengenai data lokasi tersebut.
III.3 Analisa Kebutuhan Pengguna Pada analisa kebutuhan pengguna ini dipaparkan tentang analisa keanekaragaman data sekarang dan sistem pelayanan pengeditan data geografi yang dibutuhkan oleh sistem pelayanan yang akan dibangun. Keanekaragaman data geografi yang disebabkan oleh keanekaragaman pengembang dapat menyebabkan kesulitan ataupun persoalan dalam melakukan suatu pengintegrasian ataupun pertukaran data untuk suatu tujuan tertentu, selain data geografi yang beranekaragaman format juga data tersebut bisa berasal dari berbagai lokasi atau dengan kata lain data tersebut tersebar.
19
Gambar III-4 mengilustrasikan 4 kondisi sekarang tentang sistem pengeditan data geografi yaitu : a. Jalur A adalah menunjukan sistem pengeditan data geografi yang sifatnya masih tradisional, yaitu aplikasi hanya mengakses datastore yang bersifat lokal dan hanya satu jenis datastore format yang dipakainya.
Gambar III-4 Analisa pengeditan data geografi sekarang
b. Jalur B tidak dapat dilakukan sebab keseluruhan dari perangkat lunak yang tersedia hanya digunakan untuk satu macam format datastore saja. Kalaupun bisa sering dijumpai adanya ekstensi tambahan dari suatu perangkat lunak lunak untuk mengkonversinya terlebih dahulu. c. Jalur C adalah sig yang di jumpai sekarang (model client-server) dimana datastore tersebut disimpan berbeda dengan perangkat lunak SIG, dan umumnya hanya bersifat menampilkan peta, dan bukan melakukan pengeditan. d. Jalur D tidak dapat dilakukan sebab datastore yang dipakai dalam Jalur D hanya dapat digunakan jika menggunakan datastore dengan format yang sama dengan sistem C. Kalaupun bisa mengaksesnya dibutuhkan suatu ekstensi tambahan yang sifatnya hanya membacanya dan tidak sampai melakukan penulisan ke datastore yang berbeda format.
20
Pada pelayanan pengeditan data geografi sangatlah penting dengan adanya suatu visualisasi dari data geografi tersebut sebab dengan adanya visualisasi aspek kesalahan dalam melakukan perubahan ke data geografi bisa dikurangi, dibandingkan dengan tidak adanya visualisasi.
Lingkungan web dipilih sebab pelayanan nanti akan menggunakan internet browser untuk visualisasi data geografis tersebut. Lingkungan web dari segi perawatan sangatlah lebih baik daripada di lingkungan desktop. Pengguna hanya menggunakan internet browser untuk mengakses aplikasi ini.
Jadi secara ringkas layanan pengeditan data geografi di lingkungan web yang dibangun harus memiliki kriteria sebagai berikut: a. Sistem harus dapat menangani keanekaragaman format data tersebut. b. Sistem harus dapat menangani adanya ketersebaran data geografi tersebut. c. Sistem harus dapat menampilkan secara visual data geografi tersebut, atau dengan bahasa yang mudah sistem harus dapat menampilkan image/peta dari data geografi tersebut. d. Sistem harus dapat melakukan transaksi manajemen data (penambahan feature, pengubahan dan penghilangan) suatu feature/kenampakan di peta/image yang dihasilkan.
III.4 Kebutuhan
Perangkat
Lunak
Pengeditan
Data
Geografi Pembangunan perangkat lunak yang akan digunakan untuk memenuhi kebutuhan pengguna pelayanan pengeditan data geografi dirancang dengan menggunakan metode pembangunan perangkat lunak berorientasi objek. Penggambaran sistem secara dinamik maupun statik mengikuti standar penggambaran untuk konsep yang berorientasi objek. Diagram-diagram yang digunakan pada bab ini seluruhnya mengikuti standar dari Unified Modeling Language (UML). Proses pembangunan sistem dilakukan dengan mengikuti standar Rational Unified Process (RUP) yang mendukung pembangunan sistem berorientasi obyek. 21
III.4.1 Deskripsi Umum Sistem
Sistem ini dikembangkan di lingkungan web (disebarkan/dideploy) dengan menggunakan suatu web server dan memiliki mode (client-server). Gambar III-5 dapat menunjukan secara jelas lingkungan sistem ini. Layanan ini terbagi atas 2 modul yang terkait yaitu a. modul yang menangani data (pembacaan dan penulisan). b. modul yang menangani adanya interaksi dengan pengguna. selanjutnya untuk mempermudah dalam penamaan modul yang sifatnya untuk penanganan data (pembacaan dan penulisan) disebut modul nodemap, sedangkan modul untuk menangani interaksi dengan pengguna disebut modul mapedit.
Gambar III-5 Lingkungan Sistem Pengeditan Data Geografi di Lingkungan Web
Gambar III-6 adalah diagram arsitektur sistem yang lengkap disertai dengan keterangan mengenai masukan, proses dan keluaran. Keterangan mengenai masukan, proses dan keluaran dapat ditampilkan di Tabel III-1. Tabel III-1 Masukan, Proses dan Keluaran Kedua Modul.
Nama Modul Nodemap
Masukan Parameter-parameter dari modul mapedit.
Proses 1. Membaca Permintaan 2. Memproduksi Peta disesuaikan dengan permintaan 3. Melakukan pengeditan disesuaikan dengan permintaan. 4. Melakukan konfigurasi katalog data
22
Keluaran Image peta, xml stream feature Info, pesan transakasi
Nama Modul MapEdit
Masukan Interaksi dengan pengguna layanan
Proses
Keluaran
1. Penampilan peta dalam layer-layer dari file konfigurasi disesuaikan dengan permintaan pengguna 2. Memproses xml stream post kiriman dari nodemap kemudian menampilkannya (Informasi tentang kenampakan dan pesan transaksi)
Parameter (parameter permintaan peta, parameter permintan minta informasi, permintaan untuk melakukan add/edit/delete)
Gambar III-6 Arsitektur Sistem Pengeditan Data Geografi di Lingkungan Web
23
III.4.1.1 Analisa Modul NodeMap
Modul nodemap mempunyai fungsi sebagai berikut : a. Dapat membaca dan menulis ke suatu data geografi dengan berbagai macam format b. Dapat menerima permintaan dari modul mapedit
dan membuat
tanggapan. Permintaan dapat berupa pembuatan image/peta ataupun permintaan melakukan pengubahan kenampakan pada peta yang dihasilkan dengan melakukan aksi dari parameter-parameter yang dikirimkan oleh modul mapedit terhadap modul ini.
Untuk dapat melaksanakan fungsinya yaitu dapat membaca dan menuliskan ke berbagai macam format data, olah pikir yang dibutuhkan adalah : a. Membuat struktur data yang sifatnya umum untuk dapat menangani format data yang berbeda-beda. Untuk dapat membuat struktur data yang sifatnya umum hal yang perlu dilakukan adalah membaca spesifikasi pengembang
format-format tersebut.
data Untuk
geografi data
yang
geografi
diberikan yang
oleh
bertipe
geometri/spasial dapat dibuat kelas-kelas sebagai berikut : 1. Koordinat (suatu kelas yang menangani data x,y) 2. Point (suatu kelas yang menangani tipe data point) 3. LineString (suatu kelas yang menangani tipe data LineString atau sering dinamakan Polyline (Arc)) 4. Polygon (suatu kelas yang menangani tipe data poligon) 5. GeometriCollection
yang
mencakupi
MultiPoint,
MultiLineString dan MultiPolygon.
Untuk data yang sifatnya non geometri dapat digunakan kelas–kelas primitif yang terdapat pada suatu bahasa pemrograman, misalnya untuk tipe data string/char/varchar dapat ditangani oleh kelas string,
24
untuk tipe data integer dapat ditangani oleh kelas integer. Contoh kelas umum untuk menangani data geometri dapat dilihat pada gambar III-7.
Geometry Coordinate
+SRID: int
+x,y: double
LineString
Point
Polygon
GeometryCollection
MultiPoint
LinearRing
MultiLineString
MultiPolygon
Gambar III-7 Contoh Kelas Umum untuk penanganan data geometri
Tabel III-2 menunjukan analisa struktur data yang digunakan oleh berbagai format data geografi dan struktur data umum yang dapat digunakan. Untuk dapat mengetahui struktur data generik yang digunakan beberapa hal yang dapat dilakukan adalah: 1. Untuk format data file, dapat dilihat dari header file menggunakan operasi I/O. 2. Untuk data geografi yang disimpan di suatu DBMS maka dapat digunakan metadata di database tersebut.
Tabel III-2 Struktur Data Berbagai Format DataStore
Format
Struktur Data (nilai dalam bit)
Analisa Struktur Data Generik yang dapat digunakan
.shp
Shapefile
PostGre
1 ( Point ) 3 (Polyline/arc) 5 (Polygon) 8 (MultiPoint) .dbf C N F
Point LineString Polygon MultiPoint String Integer / Long / Double Double
L
Boolean
D
Date
POINT
Point
25
Format
MySQL Spatial
Oracle Spatial
LINESTRING POLYGON MULTIPOINT MULTILINESTRING MULTIPOLYGON GEOMETRYCOLLECTION GEOMETRY
Analisa Struktur Data Generik yang dapat digunakan LineString Polygon MultiPoint MultiLineString MultiPolygon GeometryCollection Geometry
VARCHAR BOOLEAN INTEGER REAL DOUBLE PRECISION DECIMAL DATE TIME
String Boolean Integer Float Double BigDecimal Date Time
POINT LINESTRING POLYGON MULTIPOINT MULTILINESTRING MULTIPOLYGON GEOMETRYCOLLECTION GEOMETRY
Point LineString Polygon MultiPoint MultiLineString MultiPolygon GeometryCollection Geometry
TINY SHORT INT LONG DOUBLE VARCHAR DECIMAL CHAR TEXT BLOB FLOAT
Byte Short Integer Integer Double String String String String String Float
POINT LINE POLYGON MULTIPOINT MULTILINE MULTIPOLYGON
Point LineString Polygon MultiPoint MultiLine MultiPolygon
NUMERIC CHAR VARCHAR BOOLEAN INTEGER
BigDecimal String String Boolean Integer
Struktur Data (nilai dalam bit)
26
Format
Struktur Data (nilai dalam bit) REAL DOUBLE
Analisa Struktur Data Generik yang dapat digunakan Float Double
b. Membuat kode-kode yang dapat membaca dan menulis ke multiformat data tersebut dengan struktur data umum yang telah dibuat. Untuk data geografi yang menggunakan file (file based) dapat menggunakan perintah I/O (Input/Output) dan jika menggunakan database (DBMS) dapat digunakan konektor yang biasanya sudah diberikan misal ODBC
(Open Database
Connectivity) dan JDBC (Java Database Connection). Pada database spatial
(Postgre/Postgis, mysql dan Oracle) terdapat
perbedaan dalam melakukan perintah-perintah sql (structured query language), oleh karena itu dibutuhkan kode-kode dalam penyesuaian perintah sql atau sering dinamakan SQLEncoder atau SQLBuilder. c. Untuk dapat menggabungkan antara data geometri dan data atribut dibutuhkan suatu FID (feature identifier) yaitu suatu pengenal kenampakan, misal sebuah peta gedung ITB, salah satunya gedung teknik informatika yang punya fid yaitu gedung01. d. Untuk mengetahui layer-layer yang terdapat di suatu modul nodemap maka diperlukan suatu katalog datastore (katalog layer). e. Untuk dapat menghasilkan peta maka diperlukan kode-kode untuk menyediakan peta sesuai dengan parameter-parameter kiriman.
Untuk dapat menangkap permintaan dan melakukan tanggapan permintaan (request) dari modul mapedit dibutuhkan beberapa kode yang fungsinya a. Membaca permintaan-permintaan. Permintaan-permintaan dari modul mapedit ada yang berupa xml stream sehingga dibutuhkan kode-kode yang digunakan untuk membaca xml tersebut. b. Memproses
permintaan,
setelah
dibaca
permintaan
maka
dibutuhkan kode untuk mencari kelas layanan yang dibutuhkan untuk memprosesnya.
27
c. Memberikan tanggapan, setelah dilakukan pemrosesan maka modul nodemap
Untuk dapat menangani data geografi yang sifatnya tersebar maka modul nodemap ini pada fase perancangan dan implementasi akan dideploy/disebarkan ke server penyedia datastore tersebut.
III.4.1.2 Analisa Modul Mapedit Modul mapedit mempunyai fungsi sebagai berikut : a. sebagai manager tampilan, atau dengan kata lain digunakan untuk: 1. pengatur hasil peta yang dihasilkan oleh modul nodemap. 2. visualisasi peta yang dihasilkan oleh modul nodemap. 3. melakukan interaksi secara visual dengan pengguna. b. dapat melakukan pengiriman dan penerimaan data dari dan ke modul nodemap, maksud dari pengiriman adalah mengirimkan parameterparameter yang nantinya akan diproses oleh modul nodemap dan data yang dimaksud adalah data peta yang dihasilkan dan xml stream yang dihasilkan oleh modul nodemap. III.4.2 Fitur Utama Perangkat Lunak Di bawah ini dijelaskan mengenai kebutuhan fungsional dan non fungsional pada layanan ini. III.4.2.1 Kebutuhan Fungsional Prototipe pelayanan pengeditan data geografi harus dapat memenuhi kebutuhan fungsional yaitu: 1. dapat melakukan pembacaan dan melakukan penulisan ke berberbagai format datastore. 2. dapat melakukan penyimpanan konfigurasi mengenai format datastore, keterangan mengenai kenampakannya. 3. dapat menampilkan peta/image. 4. dapat menampilkan data atribut mengenai data geografi tersebut. 5. dapat menunjukkan pesan transaksi pengubahan data kepada pengguna.
28
III.4.2.2 Kebutuhan Non-Fungsional
Agar fungsi pengubahan kenampakan dapat secara penuh terlaksana maka sistem dapat melakukan : 1. Dikarenakan layanan yang akan dibangun ini dapat melayani ketersebaran data geografi maka perlu diketahui keadaan penyedia data tersebut. 2. Layanan dapat menampilkan data geografi dalam volume yang besar (lebih dari 10 Mbytes).
III.4.3 Model Kasus Guna dan Sistem
Kasus guna adalah sekumpulan skenario yang saling terhubung untuk menyelesaikan suatu tujuan atau persoalan tertentu. Diagram kasus guna adalah bagian utama dari pemodelan berorientasi objek menggunakan UML, yang menggambarkan aspek dinamis dari sistem dan memperlihatkan perilaku dari suatu sistem, sub-sistem atau kelas. Aktor adalah pengguna dari layanan managemen data geografi ini. Pada layanan ini terdapat 8 buah kasus guna (Gambar III-8) yaitu:
1. Membuka data konfigurasi adalah kasus guna berfungsi untuk membaca data konfigurasi dari modul nodemap ini, konfigurasi yang dimaksud adalah konfigurasi service dan data yang ada. 2. Mengonfigurasi datastore, adalah kasus guna yang berfungsi untuk melakukan konfigurasi terhadap data–data yang akan digunakan, jika file sistem maka konfigurasi akan menanyakan di mana lokasi file tersebut, jika database spasial maka akan menanyakan konfigurasi data tersebut (id, port, user, nama database, password). 3. Mengonfigurasi kenampakan adalah kasus guna yang berfungsi untuk melakukan konfigurasi terhadap kenampakan tersebut antara lain yaitu bounding box (koordinat batas), srs (spatial reference system), style yang digunakan dalam merepresentasikan feature.
29
4. Menyimpan ke data konfigurasi adalah kasus guna yang berfungsi untuk menyimpan hasil konfigurasi tersebut ke bentuk xml konfigurasi yang nantinya akan di load oleh modul nodemap ini. Xml yang dihasilkan adalah xml dari hasil konfigurasi datastore dan feature. 5. Memanajemen layer konfigurasi, adalah suatu kasus guna yang berfungsi untuk penataan layer yang akan ditampilkan pada layanan ini. 6. Mendapatkan peta dan menavigasi adalah suatu kasus guna yang berfungsi untuk menampilkan peta dan perintah navigasi peta tersebut. 7. Mendapatkan informasi kenampakan adalah suatu kasus guna yang berfungsi untuk menampilkan informasi dari kenampakan pada peta tersebut.
Informasi
yang
dimaksud
adalah
informasi
data
non
spasial/atribut dari obyek dalam peta tersebut. 8. Memanajemen kenampakan adalah suatu kasus guna yang berfungsi untuk melakukan
pengubahan
(add,
edit,
dan
delete)
terhadap
obyek
kenampakan pada peta tersebut. System Membuka data konfigurasi
Mengonfigurasi datastore
Penata Data
Mengonfigurasi kenampakan
Menyimpan ke data konfigurasi
Memanajemen layer konfigurasi
Mendapatkan peta dan menavigasi
Pengguna Layanan
Mendapatkan informasi kenampakan
Memanajemen kenampakan
Gambar III-8 Diagram Kasus Guna Layanan
30
Aktor dalam layanan ini ada dua yaitu : 1. Penata Data, penata data berperan pada modul nodemap digunakan untuk menata data untuk pembentukan config modul nodemap (katalog data). 2. Pengguna Layanan, adalah pengguna layanan ini secara umum (tidak berkaitan dengan penata data. Untuk lebih jauh mengenai hubungan antara aktor dan kasus guna dapat dilihat pada Lampiran A. III.4.4 Model Analisis
Penggambaran hasil analisis kebutuhan dilakukan dengan menggunakan jenis diagram interaksi berupa diagram sekuen dan diagram kelas. Pada diagram sekuen, sebuah objek dinyatakan sebagai suatu kotak yang diletakkan di atas garis putus-putus vertikal yang menunjukkan lama hidup dari obyek tersebut dan tanda panah menunjukkan pesan yang dikirim untuk objek lain.
Diagram kelas menggambarkan jenis objek dalam suatu sistem beserta hubungan statik antar objek tersebut, seperti asosiasi dan sub-tipe. Diagram kelas juga menggambarkan atribut dan operasi yang dimiliki oleh kelas tersebut dan juga batasan (constraints) yang berlaku pada saat objek-objek tersebut berinteraksi.
III.4.4.1 Realisasi Kasus Guna Membuka Data Konfigurasi
Diagram sekuensial mengenai kasus guna membuka data konfigurasi terdiri dari 3 obyek utama, yaitu obyek web server, obyek reader dan obyek data. Obyek web server yang dimaksud di sini adalah web server itu sendiri, membuka data konfigurasi dilakukan pada saat aktor penata data memilih start-up pada sebuah web server. Obyek reader adalah obyek yang dihasilkan oleh sebuah kelas yang digunakan untuk membaca file konfigurasi pada modul nodemap. Data hasil pembacaaan config nodemap tersebut kemudian dimuatkan (loading) ke data/memory. Kasus guna membuka data konfigurasi ini dilakukan sepenuhnya di modul nodemap.
31
WebServer
reader
data
<
> 1 2 : loadServices(servicesFile) 3 : loadCatalog(catalogFile)
4 : load(Data)
Gambar III-9 Diagram Sekuensial untuk Kasus Guna Membuka Data Konfigurasi
Diagram kelas analisa (Gambar III-10) menunjukan bahwa sebuah data obyek di nodemap dapat terdiri dari keterangan mengenai datastores dan data kenampakan yang ada.
FeatureTypes
DataStores
Data Reader
Gambar III-10 Diagram Kelas Analisa Kasus Guna Membuka Data Konfigurasi
III.4.4.2 Realisasi Kasus Guna Mengonfigurasi Datastore Pada
Gambar
III-11
terdapat
4
obyek
yaitu
datastoresnewaction,
datastoreseditoraction, userContainer, dan data. Obyek datastoresnewaction adalah sebuah obyek yang digunakan untuk menangani konfigurasi baru mengenai datastore, datastoreseditoraction adalah suatu obyek yang digunakan untuk menangani pengeditan datastore, userContainer adalah sebuah kelas yang menangani data sementara sebelum dimasukan ke data nodemap (obyek data). Kasus guna mengonfigurasi datastore ini dilakukan sepenuhnya di modul
32
nodemap. Diagram kelas realisasi pada kasus guna mengonfigurasi datastore dapat dilihat pada Gambar III-12. datastoresnewAction
datastoreseditoraction
userContainer
data
sd Frame1 Pembuatan Data Stores Baru 5 : user.setDataStoreConfig(newDataStoreConfig)
6 : addDataStore(config)
sd Frame2 8 : addDataStore(config)
Pengeditan DataStores
7 : user.setDataStoreConfig(newDataStoreConfig)
Gambar III-11 Diagram Sekuensial untuk Mengonfigurasi Datastore
Data
DataStoresNewAction
UserContainer DataStoresEditorAction
Gambar III-12 Diagram Kelas Analisa untuk Mengonfigurasi Datastore
III.4.4.3 Realisasi Kasus Guna Mengonfigurasi Kenampakan
Pada
kasus
guna
mengonfigurasi
kenampakan
yang
digunakan
untuk
menambahkan keterangan mengenai kenampakan suatu obyek ke suatu informasi yang nanti dihasilkan oleh nodemap. Pada realisasi kasus guna mengonfigurasi kenampakan terdapat 4 buah obyek yaitu obyek datafeaturetypenewaction yang digunakan untuk menangani suatu request ataupun permintaan untuk penambahan
33
feature baru, obyek datafeaturetypesselectaction yang digunakan untuk menangani pengubahan suatu feature, obyek usercontainer yang digunakan untuk menyimpan secara sementara data feature yang baru sebelum ditambahkan ke suatu obyek data. Kelas analisa yang dapat diberikan terdapat pada Gambar III14, dimana terdapat 4 kelas yang digunakan untuk kasus guna mengonfigurasi kenampakan. Kasus guna mengonfigurasi kenampakan dilakukan oleh aktor penata data dan sepenuhnya dijalankan oleh modul nodemap.
DataFeatureTypesNewAction
DataFeatureTypesSelectAction
userContainer
data
sd Frame3
Pembuatan Feature Baru
10 : addFeatureType(Desc) 9 : setFeatureTypeConfig(ftConfig)
sd Frame4 11 : setFeatureTypeConfig(ftConfig) 12 : addFeatureType(Desc) Edit Feature
Gambar III-13 Diagram Sekuensial untuk Mengonfigurasi Kenampakan
III.4.4.4 Realisasi Kasus Guna Menyimpan ke Data Konfigurasi
Pada kasus guna menyimpan ke data konfigurasi yang digunakan untuk menyimpan hasil konfigurasi data store dan konfigurasi kenampakan dari obyek data ke suatu file xml konfigurasi dengan bantuan obyek XMLConfigWriter. Terdapat 3 obyek yang berperan dalam kasus guna menyimpan ke data konfigurasi ini, yaitu obyek data yang digunakan untuk menampung konfigurasi datastore dan feature, obyek xMLConfigWriter yang digunakan untuk menuliskannya ke file xml konfigurasi dan obyek savexmlaction utuk penangan permintaan penyimpanan ke format xml tersebut, sedangkan message adalah pesan dari proses ini. Diagram kelas dapat dilihat pada Gambar III-16 dimana 34
terdapat 3 kelas analisa yaitu Data, XMLConfigWriter dan SaveXMLAction. Kasus guna menyimpan ke data konfigurasi sepenuhnya dilakukan oleh aktor penata data di modul nodemap.
Data
DataFeatureTypesNewAction UserContainer
DataFetureTypesSelectAction
Gambar III-14 Diagram Kelas Analisa untuk Mengonfigurasi Kenampakan
saveXMLAction
xMLConfigWriter
15 : XMLConfigWriter.store(data) 16 : message
Gambar III-15 Diagram Sekuensial untuk Menyimpan ke Data Konfigurasi
XMLConfigWriter
Data
SaveXMLAction
Gambar III-16 Diagram Kelas Analisa untuk Menyimpan ke Data Konfigurasi
35
III.4.4.5 Realisasi Kasus Guna Memanajemen Layer Konfigurasi
Kasus guna memanajemen layer konfigurasi ini terdapat pada modul mapedit, secara keseluruhan dimana terdapat 2 obyek (Gambar III-17) yang akan digunakan
yaitu
obyek
saveConfigLayerAction
(dari
kelas
SaveConfigLayerAction) yang digunakan untuk penangan adanya permintaan penambahan
layer
baru
dan
obyek
xmlconfigWriter
(dari
kelas
XMLConfigWriter) yang digunakan untuk penulisan data manajemen layer tersebut ke file xml. SaveConfigLayerAction
XmlConfigWriter
20 : savetoconfig(request data)
21 : message
Gambar III-17 Diagram Sekuensial Analisa untuk Memanajemen Layer Konfigurasi
SaveConfigLayerAction XMLConfigWriter
Gambar III-18 Diagram Kelas Analisa untuk Memanajemen Layer Konfigurasi
III.4.4.6 Realisasi Kasus Guna Mendapatkan Peta dan Menavigasi
Kasus guna mendapatkan peta dan menavigasi dilakukan oleh pengguna layanan, dan di dalam kasus guna ini terdapat keterkaitan antara modul nodemap dan mapedit. Modul mapedit mengirimkan parameter permintaan ke modul nodemap,
36
dan di dalam modul nodemap memproses permintaan tersebut kemudian menampilkan hasilnya. mapedit
dispatch
service
Data
response
imageProducer
23 : request
24 : findService(String request) 25 : getData()
26 : dataStoreInfo 27 : getOutputFormat() 28 : produceImage()
29 : image
30 : image
Gambar III-19 Diagram Sekuensial Analisa untuk Mendapatkan Peta dan Menavigasi
Terdapat 6 buah obyek (Gambar III-19) yang dapat digunakan pada kasus guna ini yaitu a. mapedit, obyek mapedit disini dimaksudkan adalah modul mapedit itu sendiri, modul mapedit mengirimkan sebuah request mendapatkan peta yang akan ditangani oleh obyek dispatch. b. Obyek dispatch digunakan untuk penanganan permintaan mendapatkan peta dari modul nodemap, kemudian modul ini mengirimkan pesan ke obyek service untuk mencari service yang diperlukan. c. Obyek service digunakan untuk pencarian service yang diperlukan, dan service yang akan dihasilkan tentu memerlukan data yang tadi diload oleh kasus guna membuka data konfigursi. Obyek service membutuhkan data mengenai datastoreinfo yang terdapat pada obyek data. Datastoreinfo inilah yang nanti kemudian digunakan oleh obyek imageProducer untuk menggambar image.
37
d. Obyek data adalah obyek yang digunakan untuk penyimpan konfigurasi data config suatu modul nodemap (katalog data). e. Obyek response digunakan untuk persiapan dalam melakukan tanggapan terhadap permintaan mendapatkan peta. f. Obyek
imageProducer
dihasilkan
oleh
suatu
kelas
yang
dapat
menghasilkan suatu gambar peta yang nanti akan diberikan/ditampilkan di modul/obyek mapedit. Kelas analisa (III-18) pada kasus guna mendapatkan peta dan menavigasi terdapat 5 buah kelas yang terdapat pada modul nodemap.
Data
Response
ImageProducer
Service Dispatcher
Gambar III-20 Diagram Kelas Analisa untuk Mendapatkan Peta dan Menavigasi
III.4.4.7 Realisasi Kasus Guna Mendapatkan Informasi Kenampakan
Kasus guna mendapatkan
informasi kenampakan dilakukan oleh pengguna
layanan, dan di dalam kasus guna ini terdapat keterkaitan antara modul nodemap dan mapedit. Modul mapedit mengirimkan parameter permintaan ke modul nodemap, dan di dalam modul nodemap memproses permintaan tersebut kemudian menampilkan hasilnya, terdapat 6 buah obyek (Gambar III-22) yang digunakan pada kasus guna mendapatkan informasi kenampakan yaitu a. mapedit, sesuai dengan definisi diatas maka obyek mapedit yang dimaksudkan di sini adalah modul mapedit itu sendiri. b. dispatch, adalah sebuah obyek yang dibuat dari kelas Dispacher yang digunakan
untuk
menangani
kenampakan dari modul mapedit.
38
permintaan
mendapatkan
informasi
c. service adalah suatu obyek yang dibuat oleh kelas Service yang digunakan untuk mencari service mana yang digunakan dalam menangani permintaan ini. d. featureResponse adalah suatu obyek yang dihasilkan oleh
kelas
FeatureResponse yang digunakan untuk menangani xmlstream dari modul mapedit, xmlstream dibentuk dari request stream mapedit. e. data adalah obyek yang dibuat oleh kelas Data yang berisi keterangan mengenai datastore dan feature dari modul nodemap. f. Datastore adalah obyek dari DataStore. g. xmlFeatureResponse
adalah
suatu
obyek
yang
digunakan
untuk
menyampaikan pesan xml ke modul mapedit.
Data
Service FeatureResponse
Dispatcher XmlFeatureResponse
DataStore
Gambar III-21 Diagram Kelas Analisa untuk Mendapatkan Informasi Kenampakan
III.4.4.8 Realisasi Kasus Guna Memanajemen Kenampakan
Kasus guna memanajemen kenampakan dilakukan oleh pengguna layanan, dan di dalam kasus guna ini terdapat keterkaitan antara modul nodemap dan mapedit. Modul mapedit mengirimkan parameter permintaan ke modul nodemap, dan di dalam modul nodemap memproses permintaan tersebut kemudian menampilkan hasilnya kasus guna ini digunakan untuk menanangani adanya permintaan
39
penambahan, pengeditan dan penghapusan feature/kenampakan dalam suatu image terdapat 7 buah obyek (Gambar III-23) yang berperan yaitu : a. obyek mapedit, yaitu modul mapedit itu sendiri. b. obyek dispatch yaitu digunakan untuk menangani permintaan dari obyek mapedit. mapedit
dispatch
service
featureResponse
Data
dataStore
xmlFeatureResponse
31 : request
32 : findService(String service) 33 : execute(request) 34 : getData(String id)
35 : dataFeatureInfo
36 : readDataStore() 37 : results dataStore
38 : prepare(outputFormat, results)
39 : xmstream
Gambar III-22 Diagram Sekuensial Analisa untuk Mendapatkan Informasi Kenampakan
c. obyek service berfungsi untuk mencari service yang akan digunakan untuk penangan add/edit/delete data geografi tersebut. d. obyek transactionFeatureHandler yaitu suatu obyek yang digunakan untuk
membaca
xmlstream
permintaan.
Fungsi
read(request)
menghasilkan subTransactionrequest yaitu suatu obyek yang digunakan untuk menandai apakah perintah yang akan diproses itu penambahan/ pengurangan / pengubahan. e. obyek data digunakan untuk mencari informasi kenampakan dari data di modul nodemap (lokasi file, macam file format).
40
f. Obyek transactionresponse dari kelas TransactionResponse digunakan untuk menangani tanggapan dari transaksi ini. g. Obyek datastore adalah obyek interface yang digunakan untuk penanganan pembacaaan dan penulisan ke datastore tersebut. mapedit
Dispatch
37 : request
service
transactionFeatureHandler
Data
TransactionResponse
dataStore
38 : doPost(request)
39 : read(xmlstream) 40 : getFeatureTypeInfo(String id)
41 : featureInfo 42 : subTransactionRequest
43 : execute(request)
44 : read(request)
45 : write()
46 : xmstream
47 : message
Gambar III-23 Diagram Sekuensial Analisa untuk Memanajemen Kenampakan
Data
Service
Dispatcher
TransactionFeatureHandler
TransactionResponse DataStore
Gambar III-24 Diagram Kelas Analisa untuk Memanajemen Kenampakan
41
III.4.5 Diagram Kelas Keseluruhan Tahap Analisis
Diagram kelas yang dapat dibentuk ( Gambar III-25), dapat di tabelkan (Tabel III3) sesuai dengan jenis obyek yang dihasilkan.
Tabel III-3 Jenis obyek dari semua kasus guna No
Nama Kelas
Jenis
1
DataStores
Entity
2
FeatureTypes
Entity
3
XMLConfigWriter
Boundary
4
SaveXMLAction
Control
5
Reader
Boundary
6
Data
Entity
7
DataStoresNewAction
Control
8
DataStoresEditorAction
Control
9
DataFeatureTypesNewAction
Control
10
UserContainer
Entity
11
DataFeatureTypesSelectAction
Control
12
TransactionFeatureHandler
Control
13
Response
Control
14
ImageProducer
Entity
15
Dispacher
Boundary
16
FeatureResponse
Control
17
Service
Control
18
TransactionResponse
Control
19
DataStore
Entity
20
XmlFeatureResponse
Control
III.4.6 Diagram StateChart Diagram
StateChart
adalah
suatu
teknik
yang
cukup
dikenal
untuk
menggambarkan perilaku dari suatu objek. Diagram StateChart menggambarkan seluruh keadaan yang mungkin dari suatu objek beserta perubahan keadaan objek tersebut. Biasanya diagram StateChart digunakan untuk menggambarkan kehidupan dan perilaku suatu objek dalam suatu kelas tertentu. Dari hasil analisa diatas maka dapat dijabarkan (Gambar III-26) sebagai berikut:
42
SaveXMLAction FeatureTypes
DataStores
SaveConfigLayerAction Reader
XMLConfigWriter
DataStoresNewAction
ImageProducer
Response Data
DataStoresEditorAction
Service
UserContainer
Dispatcher DataFetureTypesSelectAction
FeatureResponse TransactionFeatureHandler
DataFeatureTypesNewAction
XmlFeatureResponse TransactionResponse DataStore
Gambar III-25 Diagram Kelas Analisa untuk semua kasus guna
1. Suatu initial state pada layanan ini adalah dimana layanan ini a. membaca data konfigurasi dari modul nodemap. b. Menerima parameter dari modul mapedit. 2. waiting process adalah suatu kondisi dimana modul akan memproses permintaan dari pengguna, waiting process dibagi menjadi 4 keadaan yaitu a. dispatching yaitu suatu keadaan dimana aplikasi ini membaca permintaan dari pengguna, pembacaannya dapat dilakukan dengan merekonstruksi parameter permintaan (jika bentuknya get) dan merekonstruksi string xml stream jika bentuknya post. b. hasil suatu pembacaan permintaan dari pengguna digunakan untuk aplikasi mencari service/layanan yang akan digunakan, oleh karena itu dinamakan finding service.
43
read xml config/stream
waiting process
dispatching
getService findingService
handleTransaction creatingTransaction
getOutputFormat creatingResponse
responseTransaction
showResponse
Gambar III-26 State Diagram untuk pelayanan pengeditan data geografi
c. Layanan transaksi (penambahan, pengubahan dan penghapusan kenampakan) ditangani oleh kelas-kelas tertentu, oleh karena itu dinamakan creating transaction. d. Layanan dikirim dapat berupa peta ataupun xml hasil transaksi (sukses/gagal), sehingga keadaan ini dinamakan creating Response. 3. Suatu state dianggap final state apabila layanan ini a. Dapat menunjukan peta yang sesuai dengan parameter yang dikirimkan. b. Dapat menerima pesan apabila transaksi yang dilakukan berhasil. c. Dapat menerima keterangan mengenai suatu kenampakan jika berhasil, dan mengirimkan kesalahan jika tidak berhasil.
44
