HASIL DAN ANALISIS
Setelah dilakukan observasi, sistem pencarian kerja dan tenaga kerja pada sektor informal dengan memanfaatkan teknologi jaringan ponsel dapat dibangun dengan memperhatikan beberapa hal. Prototip sistem ini dirancang, untuk membuktikan sistem ini dapat berjalan dengan baik hanya dengan memanfaatkan teknologi jaringan ponsel dan algoritma pemrograman yang baik tanpa memerlukan dukungan teknologi pendukung seperti server terpusat. Sistem ini memiliki kelebihan
dan juga kekurangan jika dibandingkan dengan sistem yang menggunakan server
terpusat.
4.1. Hasil observasi pemilihan spesifikasi sistem
Observasi pemilihan spesifikasi sistem bertujuan untuk menghasilkan spesifikasi sistem yang sesuai dengan situasi dan kondisi di lapangan. Observasi meliputi observasi terhadap pengguna sistem, cara aksesibilitas sistem, teknologi pendukung sistem dan ketergantungan sistem.
4.1.1. Hasil observasi pengguna sistem
Setelah dilakukan observasi untuk mengetahui latar belakang para buruh bangunan maka didapatkan umumnya upah perhari mandor adalah Rp. 80.000, upah
tukang Rp. 60.000, dan kenek Rp. 40.000. Waktu yang diperlukan untuk mendapatkan suatu proyek pekerjaan berkisar antara 1 sampai 2 minggu. Kriteria yang mempengaruhi pencarian kerja meliputi upah kerja, wilayah kerja dan jenis keahlian tukang. Hasil observasi juga menunjukkan pengaruh ponsel yang besar dalam mendukung pencarian kerja. Setiap buruh bangunan umumnya memiliki ponsel pribadi untuk menunjang pekerjaan mereka. Untuk jenis ponsel yang digunakan oleh para buruh bangunan merupakan ponsel biasa dengan harga berkisar
rata-data Rp. 500.000 dan bukan merupakan ponsel smartphone. Jenis layanan yang
sering digunakan oleh para buruh bangunan adalah SMS dan juga layanan voice.
4.1.2. Hasil observasi cara aksesibilitas sistem
Aksesibilitas ponsel biasa lebih terbatas dibandingkan dengan ponsel
smartphone. Umumnya konektivitas ponsel biasa hanya meliputi SMS, GPRS dan
Voice. Pada penelitian ini cara aksesibilitas yang dipilih adalah SMS karena SMS didukung oleh semua jenis ponsel dan operator yang ada di Indonesia. Tidak membutuhkan setting khusus seperti GPRS dan tidak semahal voice.
4.1.3. Hasil observasi teknologi pendukung sistem
Penelitian ini menggunakan konsep database terdistribusi. Namun ponsel biasa memiliki keterbatasan sumber daya sehingga tidak memungkinkan penggunaan
Salah satu solusinya adalah dengan memanfaatkan ruang memori lokal yang terdapat
4.1.4. Hasil observasi ketergantungan sistem
Sistem di bangun dengan teknologi Java ME. Java ME dipilih karena umumnya ponsel yang beredar di Indonesia mendukung teknologi Java. Konfigurasi yang dipilih merupakan konfigurasi untuk ponsel dengan keterbatasan sumber daya yaitu CLDC (Connected Limited Device Configuration) atau bukan konfigurasi untuk ponsel dengan kemampuan tinggi. Untuk mendukung agar sistem dapat berjalan secara otomatis tanpa terlalu membutuhkan campurtangan pengguna sistem, maka ponsel yang digunakan harus mendukung push registry. Push registry hanya dapat dijalankan oleh ponsel dengan profil MIDP 2.0 keatas. MIDP merupakan singkatan dari Mobile Information Device Profile.
4.2. Hasil Perancangan Sistem Terdistribusi
Observasi perancangan sistem terdistribusi bertujuan untuk menghasilkan pilihan kebijakan yang sesuai. Dimana kebijakan ini dapat mempengaruhi efisiensi sistem dalam mendistribusikan maupun untuk mengumpulkan kembali data global dari setiap ponsel. Terdapat empat kategori observasi yaitu cara alokasi data, cara transmisi data dan pemrosesan query, manajemen direktori, dan konfigurasi jaringan.
4.2.1. Hasil observasi cara alokasi data dan manajemen direktori
fragmentasi dan replikasi. Ada beberapa tabel yang direplikasi secara utuh tapi ada
juga tabel yang difragmentasi kemudian di replikasi. Gambar 4.1 menampilkan
ilustrasi tabel-tabel yang terdapat pada masing-masing pengguna sistem. Dengan penjelasan sebagai berikut, garis merah menunjukkan hubungan relasi antar tabel,
garis biru tabel yang difragmentasi sedangkan garis hijau adalah tabel yang
direplikasi secara utuh.
Metode penggabungan dilakukan untuk meningkatkan efisiensi penyimpanan dan sinkronisasai data. Tabel 3.2 direplikasi secara utuh ke semua ponsel anggota karena
tabel ini merupakan sentral dari alamat pengiriman token. Setiap ponsel bertugas
untuk mengedarkan token dimana nomor ponsel penerima token berdasarkan urutan
NoId dari Tabel 3.2 ini. Dengan adanya Tabel 3.2 di semua ponsel menyebabkan pengambilan isi tabel berlangsung secara lokal sehingga lebih efisien daripada harus mengambil data dari ponsel yang berbeda.
Tabel 3.3 difragmentasi berdasarkan kebutuhan sistem. Koordinator dan mandor memiliki Tabel 3.3 secara utuh. Namun ponsel tukang hanya menyimpan fragmentasi dari tabel ini yaitu yang berisi data tukang lainnya dengan spesifikasi pekerjaan yang sama. Hal ini berkaitan dengan Tabel 3.6 yang dimiliki ponsel tukang. Setiap mendapatkan proyek pekerjaan, ponsel tukang hanya perlu mensinkronisasikan ke Tabel 3.6 tukang lainnya yang memiliki spesifikasi pekerjaan yang sama. Dengan hanya menyimpan fragmentasi data yang dibutuhkan akan meningkatkan efisien dalam hal penyimpanan ruang memori ponsel. Sedangkan koordinator dan mandor memiliki replikasi tabel yang utuh untuk keperluan ketersediaan data jika ada ponsel
tukang yang membutuhkan informasi tentang tukang dengan spesifikasi keahlian yang berbeda.
4.2.2. Hasil observasi konfigurasi jaringan, transmisi data dan pemrosesn query
Beberapa faktor yang mempengaruhi pilihan konfigurasi adalah kompleksitas dan efisiensi biaya. Pada penelitian ini konfigurasi jaringan yang dipilih adalah konfigurasi ring network karena lebih sederhana dan murah. Instruksi dikirim secara hop by hop sehingga biaya pengiriman tidak ditanggung oleh hanya 1 pihak saja.
Pilihan transmisi data untuk ponsel CLDC tidaklah sebanyak cara transmisi data untuk ponsel kategori smartphone. Pada penelitian ini, cara transmisi data yang dipilih adalah SMS dengan pertimbangan SMS merupakan layanan yang dapat dijalankan oleh setiap jenis ponsel dan semua operator selular yang ada di Indonesia. Pada sistem ini, SMS merupakan media untuk menjalankan MIDlet secara otomatis. Untuk membedakan dengan layanan SMS biasa, SMS pada sistem ini dilakukan dengan cara mengakses port tertentu. Port yang dipilih haruslah port yang tidak digunakan oleh sistem standar ponsel. Pada penelitian ini port yang dipilih yaitu port 8888.
Pada penelitian ini, transaksi dikirim ke dan diolah di lokasi data. Hal ini disebabkan karena cara ini lebih efisien dibandingkan jika data yang dikirim terutama untuk data dengan kapasitas besar. Untuk itu dibuatlah suatu aturan transaksi dengan algoritma yang sesuai agar sistem dapat berjalan dengan baik, akurat dan efisien.
Setiap SMS terdiri dari header pesan, informasi pengirim dan data. Header
pesan terdiri dari 4 bit data biner yang merupakan kode instruksi yang harus
dijalankan oleh sistem. Informasi pengirim berisi 4 bit data biner yang merupakan kode pengirim apakah mandor, koordinator atupun tukang dengan keahlian tertentu. Sedangkan data berisi data yang akan dieksekusi. Panjang pesan binari yang dapat dikirimkan dan diterima oleh suatu ponsel bervariasi. Namun secara umum suatu
ponsel hanya mampu menerima atau mengirim 133 byte data per sekali SMS. Untuk
itu pada sistem ini panjang data pesan maksimal 132 byte karena 1 byte digunakan untuk header + informasi pengirim. Jika panjang data melebihi 132 byte maka pesan
akan dikirimkan dalam beberapa sesi dengan kode header tersendiri. Untuk lebih
jelasnya, penjelasan header dan kode pengirim dapat dilihat pada Tabel 4.1 dan Tabel 4.2.
Tabel 4. 1 Daftar instruksi header pesan
Header Pesan
Instruksi
0000 Pendaftaran / konfirmasi pendaftaran anggota komunitas baru
0001 Konfirmasi penambahan anggota baru kepada anggota komunitas lainnya
0010 Update / konfirmasi update data anggota komunitas
0011 Konfirmasi update data anggota komunitas kepada anggota komunitas
lainnya
0100 Pesan sambungan jika pesan yang dikirimkan lebih dari kapasitas 1 kali
SMS
0101 Cek apakah dapat mengirim token
0110 Konfirmasi token dapat dikirim
0111 Pengiriman token
Tabel 4. 2 Informasi kode pengirim
Kode Pengirim
Penjelasan
0000 Koordinator
0001 Tukang rangka baja
0010 Tukang kayu
0011 Tukang listrik /instrumen
0100 Tukang besi 0101 Tukang keramik 0110 Tukang batu 0111 Tukang pipa 1000 Lain-lain 1001 Mandor
Setiap header akan membawa data pesan yang berbeda karena setiap header
akan dibahas pada algoritma aturan transaksi.
4.3. Algoritma Aturan Transaksi
Aturan transaksi dibuat agar sistem dapat menjalankan instruksi dengan tepat. Berikut ini akan dibahas tentang algoritma aturan transaksi pada penelitian ini.
a. Algoritma pendaftaran anggota komunitas baru
Pendaftaran anggota komunitas baru dilakukan oleh tukang/mandor yang ingin bergabung dengan komunitas ini dengan cara mengisi formulir pendaftaran yang terdapat pada ponsel mereka yang terdiri dari kolom NoKTP, Nama, Alamat dan Kode Keahlian. Selanjutnya algoritma pendaftaran anggota komunitas baru dapat dilihat di bawah ini.
1. Pertama sistem di ponsel tukang/mandor membuatTabel 3.1.
2. Lalu sistem di ponsel tukang/mandor menginput data pribadi
tukang/mandor ke dalam Tabel 3.1, dimana untuk NoId anggota masih kosong (0) karena menunggu balasan dari ponsel koordinator.
3. Sistem juga membuat sebuah Tabel 3.3, pada baris pertama diisi
dengan kode keahlian tukang/mandor yang bersangkutan.
4. Kemudian sistem mengirimkan instruksi kepada ponsel mandor yang
terdiri dari 4 bit header pendaftaran (0000), 4 bit kode keahlian tukang, dan maksimal 74 byte data pribadi tukang.
5. Menanti konfirmasi dari ponsel koordinator
6. Jika pesan konfirmasi dari ponsel koordinator masuk, sistem akan
mengecek pesan yang terdiri dari 4 bit header pesan (0000) + 4 bit kode pengirim koordinator (0000) + Data yang terdiri dari 2 byte NoId tukang, 12 byte dikalikan jumlah anggota yaitu data seluruh data no ponsel tukang yang telah bergabung, 2 byte untuk data jumlah anggota
yang memiliki keahlian yang sama dengan tukang, 2 byte dikalikan
jumlah anggota dengan keahlian sama yaitu daftar NoId anggota lainnya yang memiliki keahlian yang sama, 1 byte data boolean yaitu konfirmasi apakah pesan bersambung atau tidak, pesan bersambung jika data yang dikirim melebihi 133 byte.
7. Insert NoId ke dalam baris pertama Tabel 3.1.
8. Membuat Tabel 3.2 dan mengisi dengan NoId dan No ponsel seluruh
anggota komunitas yang didapat dari ponsel koordinator.
9. Mengisi baris kedua Tabel 3.2 dengan daftar NoId anggota komunitas
lainnya yang memiliki kode keahlian tukang yang bersangkutan.
10. Menampilkan pesan konfirmasi kepada user bahwa telah terdaftar
sebagai anggota komunitas.
b. Algoritma konfirmasi pendaftaran anggota komunitas baru
koordinator setelah mendapatkan pesan dengan header 0000 yang dikirimkan oleh para tukang/mandor. Setiap ada anggota komunitas yang bergabung, selain mengkonfirmasi kepada tukang/mandor yang mendaftar, koordinator juga harus mengkonfirmasi kepada seluruh anggota komunitas lainnya. Adapun algoritma konfirmasi pendaftaran anggota komunitas baru dapat dilihat pada langkah-langkah berikut ini.
1. Sistem menerima pesan masuk dengan header 0000, sistem lalu memecah
pesan yang terdiri dari 4 bit header (0000), 4 bit kode keahlian tukang yang mendaftar dan maksimal 74 byte data pribadi tukang/mandor yang mendaftar. Sistem lalu memanggil function anggota daftar();.
2. Sistem menambah record baru pada Tabel 3.2 yang menampung data pribadi
anggota yang mendaftar. Nomor record baru inilah yang menjadi NoId bagi
tukang/mandor yang baru mendaftar tesebut.
3. Sistem mengecek kode keahlian tukang dan membuka Tabel 3.3 pada baris
yang sesuai dengan keahlian tukang tersebut. Sistem kemudian memecah isi baris berdasarkan byte array-nya, byte array yang pertama berisi jumlah anggota pada keahlian ini dan yang byte array kedua berisi daftar NoId tukang yang terdapat pada keahlian ini. Isi byte array jumlah anggota di tambah 1 dan isi byte array kedua ditambahkan dengan NoId tukang yang baru terdaftar tersebut.
5. Sistem kemudian mengambil seluruh data NoId dan NoPonsel anggota yang ada dalam Tabel 3.2, di tuangkan dalam suatu variabel bertipe string, setiap data ponsel dipisahkan dengan tanda semi colon (;).
6. Sistem juga membuka Tabel 3.3 dan mengambil isi baris yang sesuai dengan
kode keahlian tukang.
7. Sistem mengirimkan konfirmasi kepada tukang/mandor yang baru mendaftar
dengan komposisi pesan : pesan yang terdiri dari 4 bit header pesan (0000) + 4 bit kode pengirim koordinator (0000) + Data yang terdiri dari 2 byte NoId tukang, 12 byte dikalikan jumlah anggota yaitu data seluruh data no ponsel tukang yang telah bergabung, 2 byte untuk data jumlah anggota yang memiliki keahlian yang sama dengan tukang, 2 byte dikalikan jumlah anggota dengan keahlian sama yaitu daftar NoId anggota lainnya yang memiliki keahlian yang
sama, 1 byte data boolean yaitu konfirmasi apakah pesan bersambung atau
tidak, pesan bersambung jika data yang dikirim melebihi 133 byte.
c. Algoritma konfirmasi penambahan anggota baru kepada anggota komunitas
lainnya.
Setiap ada anggota komunitas yang baru bergabung, koordinator harus mengkonfirmasikannya kepada seluruh anggota komunitas lainnya. Adapun algoritmanya dapat diihat pada penjelasan berikut ini.
1. Sistem di ponsel koordinator membuat suatu paket data yang terdiri dari
komposisi pesan yaitu 4 bit header pesan (0001), 4 bit informasi kode
yang baru bergabung, 2 byte berisi NoId anggota baru tersebut, 2 byte berisi kode keahlian tukang baru, 2 byte berisi jumlah anggota komunitas terbaru untuk kriteria yang sama dengan kode keahlian tukang baru, 2 byte dikalikan jumlah berisi daftar NoId anggota yang memiliki kode keahlian yang sama dengan anggota baru tersebut.
2. Paket data dikirimkan ke seluruh anggota komunitas
d. Konfirmasi update data anggota komunitas kepada anggota komunitas lainnya.
Setiap menerima paket data dengan header 0001 sistem di ponsel
tukang/mandor akan melakukan beberapa langkah berikut ini.
1. Membuka paket data.
2. Membuka Tabel 3.2.
3. Menambahkan no ponsel anggota baru kedalam Tabel 3.2.
4. Membuka Tabel 3.3.
5. Membandingkan kode keahlian tukang pemilik ponsel dengan kode
keahlian yang dikirim oleh koordinator. Jika kode keahlian sama maka akan dilakukan peng-update-an Tabel 3.3.
6. Jika kode keahlian tidak sama, maka Tabel 3.3 di ponsel tukang
tersebut tidak di update.
e. Algoritma mengecek apakah dapat mengirim token
Peredaran token dimulai dari ponsel koordinator kepada NoId pertama dari Tabel 3.2. Selanjutnya token akan diedarkan oleh NoId pertama
ke NoId kedua begitu seterusnya. Sebelum token diedarkan, dilakukan suatu
pengecekan untuk memastikan ponsel penerima token dalam keadaan aktif.
Algoritmanya dapat dilihat pada penjabaran berikut ini.
1. Buka Tabel 3.2, ambil NoId anggota penerima token.
2. Membuat paket data yang terdiri dari 4 bit header 0101 dan 8 byte
data berisi informasi waktu pengiriman token.
3. Menyimpan waktu pengiriman token ke dalam suatu tabel sementara.
Menunggu pesan konfirmasi selama 5 menit dengan header 0110.
4. Jika pesan konfirmasi masuk, token dapat dikirim
5. Jika pesan konfirmasi tidak masuk maka diasumsikan ponsel tujuan
tidak dapat menerima token dan ponsel akan mengambil NoId
selanjutnya dari Tabel 3.2.
f. Algoritma konfirmasi token dapat dikirim
Ponsel tukang/mandor yang menerima paket data dengan header 0101 akan melakukan algoritma sebagai berikut.
1. Membandingkan waktu pengiriman pesan dengan waktu sekarang.
2. Jika selisih waktu pengiriman lebih kecil dari 5 menit, maka ponsel
tukang/mandor mengirimkan konfirmasi token dapat dikirimkan
dengan komposisi pesan 4 bit header 0110.
3. Jika selisih waktu lebih besar dari 5 menit, diasumsikan pesan telah
kadaluarsa dan ponsel tukang/mandor yang menerima paket ini tidak akan mengirimkan konfirmasi token dapat dikirimkan.
g. Algoritma mandor penerima token
Ada perbedaaan antara algoritma penerima token untuk mandor dan
tukang. Jika mandor menerima token maka mandor akan mengirimkan daftar
cari pekerja kepada para tukang yang memiliki kriteria yang sama dengan
pekerja yang dicari oleh mandor tersebut. Algoritma mandor penerima token
dapat dilihat sebagai berikut.
1. Ponsel mandor menerima pesan dengan header 0111
2. Membuka Tabel 3.5, ambil salah satu record dan melihat kriteria
pekerja yang dibutuhkan.
3. Sistem di ponsel mandor kemudian membuka Tabel 3.2.
4. Mengirim salah satu record dari Tabel 3.5 ke semua anggota
komunitas yang memiliki kriteria yang sama dengan yang dicari oleh mandor.
5. Sistem kemudian mengirimkan token ke NoId anggota berikutnya.
h. Algoritma tukang penerima token
Sedangkan jika token diterima oleh tukang maka ponsel tukang akan membandingkan Tabel 3.5 yang dikirimkan oleh mandor dengan Tabel 3.4 yang ada diponselnya. Untuk lebih jelasnya algoritma penerimaan token dapat dilihat sebagai berikut.
1. Ponsel tukang menerima pesan dengan header 0111
3. Sistem membuka Tabel 3.5.
4. Sistem kemudian membandingkan kedua tabel
5. Jika sama, sistem lalu menghapus data pekerjaan di Tabel 3.5 dan
menyimpannya ke dalam Tabel 3.6.
6. Sinkronisasikan Tabel 3.6 kepada mandor yang memberikan kerja
7. Sinkronisasikan Tabel 3.5 yang baru kepada semua tukang yang
memiliki kriteria yang sama
8. Sistem mengirimkan token ke NoId anggota berikutnya.
4.4. Skenario Sistem
Pada sistem ini terdapat beberapa skenario sistem yaitu skenario pendaftaran anggota baru dan skenario pencarian kerja/pekerja.
4.4.1. Skenario pendaftaran anggota baru dan update data pribadi
Untuk mendaftar sebagai anggota komunitas maupun untuk meng-update
data pribadi, seorang mandor/tukang dapat menjalakan menu daftar/update yang
terdapat pada ponsel mereka masing-masing. Pengguna sistem akan mendapatkan konfirmasi jika mereka berhasil daftar/update .
Sistem menampilkan transparansi kepada pengguna dengan menyembunyikan kerumitan sistem. Dimana proses yang terjadi sebenarnya adalah SMS untuk
daftar/update dari pengguna akan masuk di port 8888 pada ponsel koordinator,
aplikasi akan mengecek 4 bit pertama dari pesan yang merupakan header pesan.
Dimana header pesan 0000 merupakan pendaftaran anggota baru dan 0010 untuk
meng-update data.
Urutan pendaftaran anggota baru diawali dengan tukang/mandor mengisi form
pendaftaran yang terdapat di ponselnya meliputi nomor KTP, nama, alamat, nomor telepon dan spesifikasi keahliannya. Aplikasi di ponsel tukang/mandor akan menyimpan nomor KTP, nama, alamat, nomor telepon di dalam Tabel 3.1 dan
mengirim header 0000 + 4 bit kode spesifikasi keahlian tukang ke ponsel
koordinator. Setelah mendapatkan pesan ini, ponsel koordinator akan menambahkan data tukang/mandor tersebut ke dalam Tabel 3.2 dan membangkitkan sebuah NoId untuk tukang/mandor baru tersebut. Aplikasi di ponsel koordinator kemudian akan
meng-update Tabel 3.3 dengan cara menambahkan NoId anggota baru tersebut ke
dalam baris Tabel 3.3 yang memiliki kode spesifikasi tukang yang sama. Setelah itu aplikasi di ponsel koordinator akan membuat paket pesan yang terdiri dari 4 bit header 0000 + 2 byte NoId tukang/mandor yang baru dibangkitkan + isi Tabel 3.2 + fragmentasi Tabel 3.3 yaitu baris tabel yang berisi tentang kode spesifikasi tukang tersebut.
mendaftar tersebut. Aplikasi di ponsel tukang/mandor akan menyimpan NoId ke dalam Tabel 3.1 dan meng-update Tabel 3.2 serta Tabel 3.3 sesuai dengan pesan yang didapat dari ponsel koordinator. Jika panjang pesan yang dikirimkan lebih dari 133 byte maka pesan akan dikirim dalam beberapa sesi dengan header 0100. Selanjutnya
aplikasi di ponsel koordinator juga akan mensinkronisasi perubahan Tabel 3.2 dan
Tabel 3.3 kepada seluruh anggota komunitas dengan mengirim pesan yang terdiri dari header 0010 + 3 byte NoId Anggota baru + 4 bit kode keahlian spesifikasi tukang baru tersebut.
Anggota komunitas juga dapat mengubah data yang terdapat pada Tabel 3.1 dengan cara memilih update data pada form update yang terdapat di ponsel mereka. Jika data yang diubah adalah nomor KTP, nama dan alamat maka perubahan hanya bersifat lokal yaitu hanya pada Tabel 3.1 di ponsel anggota tersebut. Namun jika yang diubah adalah spesifikasi keahlian maka perubahan harus di sinkronisasikan kepada seluruh anggota komunitas. Untuk proses sinkronisasi, pertama sekali aplikasi di ponsel tukang akan mengirim pesan yang terdiri dari header 0010 + NoId anggota + kode spesifikasi keahlian lama + kode spesifikasi keahlian baru. Selanjutnya ponsel tukang/mandor dapat mensinkronisasi Tabel 3.3 berdasarkan pesan ini. Diagram aktivitas dari proses ini dapat dilihat pada Gambar 4.3.
Gambar 4.2 Diagram aktivitas penerimaan anggota baru
Tukang / Mandor Koordinator
Menunggu Pesan di port 8888
Cek Header pesan (4 bit pertama)
Add NoHp pengirim ke Tabel 3.2, NoHp mendapatkan sebuah NoId
Mengirim header 0000 + NoId + Tabel 3.2 + fragmentasi Tabel 3.3
Update Tabel 3.3
Baca kode keahlian pengirim (4 bit berikut setelah header)
Kirim sinkronisasi kepada seluruh anggota lainnya :
Header (0011) + NoId + Kode Keahlian lama + kode keahlian baru
Update Tabel 3.2 dan Tabel 3.3 Menerima pesan dengan header 0000 [pesan masuk] [pesan tdk masuk] [0010] [0000]
Baca NoId pengirim (3 byte berikut), kode keahlian lama (4 bit berikutnya) dan kode keahlian baru (4 bit terakhir)
Update Tabel 3.3
Kirim sinkronisasi kepada seluruh anggota lainnya :
Header (0001) + NoId + Kode Keahlian
4.4.2. Skenario sistem pencarian kerja / pekerja
Skenario sistem pencarian pekerja dilakukan oleh mandor dengan mengisi suatu form di ponsel mandor. Form tersebut meliputi spesifikasi keahlian pekerja yang dibutuhkan, upah, wilayah kerja, waktu kerja dan jumlah pekerja yang dibutuhkan dimana data ini di simpan dalam Tabel 3.5 pada ponsel mandor. Ketika
ponsel mandor mendapatkan giliran token, maka aplikasi di ponsel mandor akan
mengirimkan data pada Tabel 3.5 ini ke ponsel para tukang yang memiliki kode spesifikasi keahlian yang sama. Pesan yang dikirim dari aplikasi mandor terdiri dari 4 bit header yaitu pengiriman token 0111 + 4 bit kode mandor yaitu 1001 + 1 byte
id_proyek yang terdiri dari NoId mandor digabung dengan autonumber kode proyek
+ 4 bit kode keahlian yang dicari + 2 bit kode wilayah + 2 bit kode upah + 3 byte tanggal mulai proyek + 3 byte tanggal akhir proyek + 1 byte jumlah yang dibutuhkan.
