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.
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-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 Table record FH RH RC FH IR dBase shp shx
Pointb:Integer[NumPoints] //Deretan titik untuk semua bagian
}
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).
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.
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.
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.
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 Masukan Proses Keluaran
Nodemap Parameter-parameter dari modul mapedit. 1. Membaca Permintaan 2. Memproduksi Peta disesuaikan dengan permintaan 3. Melakukan pengeditan disesuaikan dengan permintaan. 4. Melakukan konfigurasi katalog data Image peta, xml stream feature Info,
Nama
Modul Masukan Proses Keluaran
MapEdit Interaksi dengan pengguna layanan
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)
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 format-format data geografi yang diberikan oleh pengembang tersebut. Untuk data geografi yang 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,
untuk tipe data integer dapat ditangani oleh kelas integer. Contoh kelas umum untuk menangani data geometri dapat dilihat pada gambar III-7.
Geometry
+SRID: int Coordinate +x,y: double
LineString
LinearRing
Point Polygon GeometryCollection
MultiPoint 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
Shapefile .shp 1 ( Point ) Point 3 (Polyline/arc) LineString 5 (Polygon) Polygon 8 (MultiPoint) MultiPoint .dbf C String
N Integer / Long / Double
F Double L Boolean D Date
Format Struktur Data (nilai dalam bit) Analisa Struktur Data Generik yang dapat digunakan
LINESTRING LineString POLYGON Polygon MULTIPOINT MultiPoint MULTILINESTRING MultiLineString MULTIPOLYGON MultiPolygon GEOMETRYCOLLECTION GeometryCollection GEOMETRY Geometry VARCHAR String BOOLEAN Boolean INTEGER Integer REAL Float
DOUBLE PRECISION Double
DECIMAL BigDecimal DATE Date TIME Time MySQL Spatial POINT Point LINESTRING LineString POLYGON Polygon MULTIPOINT MultiPoint MULTILINESTRING MultiLineString MULTIPOLYGON MultiPolygon GEOMETRYCOLLECTION GeometryCollection GEOMETRY Geometry TINY Byte SHORT Short INT Integer LONG Integer DOUBLE Double VARCHAR String DECIMAL String CHAR String TEXT String BLOB String FLOAT Float Oracle Spatial POINT Point LINE LineString POLYGON Polygon MULTIPOINT MultiPoint MULTILINE MultiLine MULTIPOLYGON MultiPolygon NUMERIC BigDecimal CHAR String VARCHAR String BOOLEAN Boolean INTEGER Integer
Format Struktur Data (nilai dalam bit) Analisa Struktur Data Generik yang dapat digunakan
REAL Float DOUBLE 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.
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 parameter-parameter 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.
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.
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
Penata Data
Pengguna Layanan
Membuka data konfigurasi
Mengonfigurasi kenampakan Mengonfigurasi datastore
Menyimpan ke data konfigurasi
Memanajemen layer konfigurasi
Mendapatkan peta dan menavigasi
Mendapatkan informasi kenampakan
Memanajemen kenampakan
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.
reader data WebServer 1 <<create>> 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.
Reader
DataStores FeatureTypes
Data
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
nodemap. Diagram kelas realisasi pada kasus guna mengonfigurasi datastore dapat dilihat pada Gambar III-12.
Frame1
sd
Frame2
sd
datastoresnewAction datastoreseditoraction userContainer data
Pembuatan Data Stores Baru
Pengeditan DataStores
5 : user.setDataStoreConfig(newDataStoreConfig)
6 : addDataStore(config)
7 : user.setDataStoreConfig(newDataStoreConfig)
8 : addDataStore(config)
Gambar III-11 Diagram Sekuensial untuk Mengonfigurasi Datastore
Data
UserContainer DataStoresNewAction
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
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 III-14, 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.
Frame3 sd Frame4 sd data userContainer DataFeatureTypesNewAction DataFeatureTypesSelectAction 9 : setFeatureTypeConfig(ftConfig) 10 : addFeatureType(Desc) 11 : setFeatureTypeConfig(ftConfig) Pembuatan Feature Baru
Edit Feature
12 : addFeatureType(Desc)
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
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
UserContainer
DataFeatureTypesNewAction
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
Data
XMLConfigWriter
SaveXMLAction
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
XMLConfigWriter
SaveConfigLayerAction
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,
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.
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.
ImageProducer Response
Data
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 permintaan mendapatkan informasi kenampakan dari modul mapedit.
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.
Dispatcher Service Data FeatureResponse 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
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).
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.
transactionFeatureHandler service
mapedit Dispatch Data TransactionResponse dataStore
37 : request
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
Dispatcher Service Data TransactionFeatureHandler TransactionResponse DataStore
III.4.5 Diagram Kelas Keseluruhan Tahap Analisis
Diagram kelas yang dapat dibentuk ( Gambar 25), dapat di tabelkan (Tabel III-3) 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:
Reader DataStores FeatureTypes Data UserContainer XMLConfigWriter DataStoresNewAction DataStoresEditorAction DataFeatureTypesNewAction DataFetureTypesSelectAction SaveXMLAction SaveConfigLayerAction Response ImageProducer Service Dispatcher FeatureResponse XmlFeatureResponse DataStore TransactionFeatureHandler TransactionResponse
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.
waiting process dispatching findingService creatingResponse read xml config/stream getService getOutputFormat showResponse creatingTransaction handleTransaction responseTransaction
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,
