Bab IV Rekayasa Ulang Perangkat Lunak

Bab IV Rekayasa Ulang Perangkat Lunak Pada Bab 4 ini memberikan solusi yang dipecahkan untuk mengatasi masalah-masalah smell yang terjadi pada program setelah dideteksi bad smell-nya. Suatu bagian program dapat pula memiliki lebih dari satu smell dan pemecahan masalah suatu smell dapat pula sekaligus untuk menangani smell lain. Smell yang sama pada lebih dari satu kasus, penyelesaiannya dapat saja berbeda tergantung dari pertimbangan. Setelah bad smell pada suatu program diatasi, maka langkah selanjutnya untuk memigrasikan sebagian fungsi dari perangkat lunak ini agar dapat diakses melalui perangkat nirkabel untuk mencapai aksesibilitasnya. Urutan penyelesaian bad smells ini dimulai dari Dead Code sebelum masalah duplikasi, karena duplikasi kode dapat terjadi pada bagian kode yang merupakan Dead Code. Jadi, jika penyelesaian mulai dari duplikasi, maka usaha yang besar akan sia-sia karena ternyata kode tersebut tidak terpakai. Penyelesaian Dead Code secara otomatis dapat menyebabkan ukuran kelas mengecil dan secara tidak langsung dapat mengatasi Large Class.

Smells yang ditangani terlebih dahulu adalah yang berhubungan dengan kode, lalu smells yang berhubungan dengan kelas. Pada saat mengatasi masalah yang berhubungan dengan kelas, maka harus dipastikan smells yang berhubungan dengan kode harus sudah diatasi. Tahap selanjutnya setelah penanganan smells yaitu mengorganisir kelas-kelas yang sudah ada agar lebih teratur dan maknanya lebih terlihat dengan jelas.

IV.1 Penanganan Code Smell IV.1.1 Mengatasi Masalah Penamaan Tidak Konsisten Penanganan masalah refactoring yang paling mudah adalah penamaan, dengan bantuan tools bernama VB Refactor yang telah terintegrasi dengan Ms Visual Studio.NET. Setelah nama method (signature tidak berubah) atau field diubah, maka bagian-bagian yang menggunakan method/field itu secara otomatis akan mengubah namanya. Teknik penanganannya dengan tools 49

ini dipilih karena cukup mudah dan sederhana karena tidak perlu tidak perlu menggunakan fasilitas “Find and replace” pada tiap-tiap bagian program. Penamaan yang tidak konsisten terlihat pada kelas BranchView yaitu Office dan SalesPersonName, sedangkan kelas lain menggunakan Branch dan Adviser. Branch dengan Office itu semantiknya sama, SalesPersonName dengan Adviser juga semantiknya sama. Nama Office diganti dengan Branch dan nama SalesPersonName diganti dengan Adviser. Pada AdviserView terdapat field yang secara semantik sama dengan field yang dimiliki oleh kelas ClientCategoryChange, yaitu: 1. ServiceCategory dengan CurrentClientCategory. 2. NewServiceCategory dengan NewClientCategory. Untuk mengatasinya, maka field ServiceCategory dan NewServiceCategory mengikuti nama field yang ada pada ClientCategoryChange.

IV.1.2 Mengatasi Duplikasi Kode Dari kasus yang telah disebutkan pada bagian III.7.3 dari point a sampai i, bahwa: 1. Untuk kasus a, b, c, f dan g diselesaikan dengan inline method yaitu menyatukan beberapa method menjadi satu dan method baru yang terbentuk diberi suatu parameter khusus. Pada kasus ini lebih dari satu method memiliki jumlah baris kode yang sama dan perintah yang serupa, perbedaan hanyalah nilai pada baris tertentu. 2. Untuk kasus h, pengulangan terjadi antara dua method. Method pertama mengambil sebagian kode dari method kedua ditambah dengan bagian kode yang khusus untuk method pertama. Penyelesaian tetap dengan inline method dan membuat suatu parameter baru bertipe boolean. Di dalam method yang baru tersebut terdapat aksi kondisional jika suatu parameter bernilai true atau false, maka akan menjalankan kode-kode tambahan dari method itu. 3. Pada kasus d, penyelesaian dengan mengekstrak method baru dan satu superclass beserta turunannya. Nama method lama tetap ada, hanya saja memanggil method baru yang telah terbentuk dengan nilai parameter yang berbeda antara kedua method. Satu method tambahan lagi memiliki parameter bertipe kelas. 50

4. Pada kasus e, penyelesaian dengan mengekstrak method baru dan satu superclass beserta turunannya. Pada bagian ini terdapat method baru yang parameternya adalah berupa sebuah kelas. Solusi pada kasus ini dapat termasuk replace conditional with polymorphism. Rincian mengenai tahap-tahap penyelesaian masalah duplikasi tersebut, dapat dilihat pada Lampiran N. Penyelesaian pada lampiran tersebut ditunjukkan dengan mendeteksi bagian program mana yang menggunakan method itu (bantuan tools bernama Reflector), usulan method baru, dan cara pemanggilan method yang baru. Bagian program yang menggunakan method lama itu (yang ditunjukkan oleh Reflector) harus menyesuaikan diri dengan pemanggilan method yang baru. Khusus nomor 3 diatas, method lama tetap dipertahankan walaupun isinya lebih sedikit dan langsung mengacu ke method baru sedangkan yang lainnya menggunakan cara pemanggilan method yang baru. Usaha-usaha yang dilakukan dalam penanganan duplikasi kode cukup besar, karena dengan mengganti nama method atau menambah jumlah parameternya, maka harus diketahui bagianbagian program lain yang menggunakan kode itu sehingga tiap-tiap bagian program yang menggunakannya harus mengganti kode tersebut. Walaupun usaha yang dilakukan cukup besar, ini dapat menyebabkan jumlah baris kode berkurang dan kode akan bersifat fleksibel. Jika terdapat penambahan kebutuhan baru di masa mendatang, maka method yang sudah ada dapat dipanggil kembali tanpa harus mengulang kode yang sama. IV.1.3 Mengatasi Feature Envy Method

GetChangeCategory_for_sent_to_GM

dan

InsertToChangeCategory

pada

AdviserView harusnya dipindahkan ke kelas ClientCategoryChange.

Gambar IV.1 Hasil Analyzer untuk method GetChangeCategory_for_sent_to_GM dan InsertToChangeCategory

51

kelas

Berdasarkan analisis, maka hanya hanya method itu saja yang terpengaruh jika method itu dipindah ke kelas ClientCategoryChange. Field _newServiceCategory dan _ServiceCategory pada AdviserView setelah dipindahkan ke kelas ClientCategoryChange harus diganti namanya menjadi _newClientCategory dan _CurrentClientCategory. Parameter _User yang tidak terdapat di ClientCategoryChange tidak ada dan harus ditambah dengan membuat field baru yaitu _UserRequest. Setelah method dipindah, maka ada field-field yang tidak terpakai lagi di kelas AdviserView yaitu newServiceCategory. Method ComparingDate dan CustomDate pada AdviserView seharusnya dipindah ke modul umum yang dapat diakses oleh semua kelas pada proyek itu. Langkah yang dilakukan hanyalah memindahkan saja ke ModulUmum.vb yang berisi fungsi-fungsi utama secara umum. Masalah method GetLatestNRD dan GetLatestDLS yang terdapat pada ClientList.aspx, penyelesaian masalah yaitu dengan memindahkan ke ModulUmum.vb, kemudian setelah itu variabel ConnSupport pada kedua method itu diganti dengan PConn. Penyelesaian masalah method CentralProcessChangeCategory dan ChangeCategory

pada

CentralView yaitu dengan memindahkan method itu ke kelas ClientCategoryChange, tetapi akan mempengaruhi method GantiClientCategory pada ClientDetail.aspx jika dipindah. Method ChangeCategory yang pada awalnya tanpa parameter sekarang menjadi satu parameter yaitu ClientID. Yang akan berpengaruh berikutnya yaitu harus mengganti nama field yang merupakan masukan

terhadap

method

itu,

seperti

NewServiceCategory

harus

diganti

menjadi

NewClientCategory. Public Sub ChangeClientCategory(ByVal clientid As SqlString) Dim Comm As New SqlCommand Comm.CommandText = "SrvX_CtrView_ChangeClientCategory" Comm.CommandType = CommandType.StoredProcedure Comm.Connection = PConn Try Comm.Parameters.Add(New SqlParameter("@code", SqlDbType.VarChar, 50, ParameterDirection.Input, False, 0, 0, "", DataRowVersion.Proposed, clientid)) Comm.Parameters.Add(New SqlParameter("@clientcategory", SqlDbType.VarChar, 20, ParameterDirection.Input, False, 0, 0, "", DataRowVersion.Proposed, _NewClientCategory)) PConn.Open() Comm.ExecuteNonQuery() Catch ex As Exception

52

Logger.LogException(ex) Finally PConn.Close() Comm.Dispose() End Try End Sub

IV.1.4 Mengatasi Divergent Change Kode untuk method lstBranch, lstAdviser, getCurrentPeriod beserta method lain yang mengikutinya selalu tersebar di beberapa page, solusi yang akan digunakan yaitu menggunakan suatu komponen yang reusable. Visual Studio.NET menyediakan fasilitas untuk pembuatan komponen, termasuk komponen untuk webform yang disebut dengan User Control. User Control yang akan digunakan adalah gabungan dropdownlist dan textbox yang menunjukkan periode dan dropdownlist berisi daftar nama-nama adviser dan branch yang biasanya banyak dipakai di aplikasi web lainnya dalam lingkungan Financial Partners International, Ltd. Dengan adanya penggunaan komponen yang reusable, maka duplikasi dapat dihindari dan untuk ke depannya jika ada kebutuhan baru maka hal yang dilakukan adalah memanggil User Control tersebut. Jika terdapat perubahan tentang peraturan untuk memuat data-data yang ada pada kontrol itu, maka hal yang dilakukan adalah dengan memfokuskan pada User Control itu tanpa harus mengganti banyak kode pada tiap-tiap bagian program.

IV.2 Penanganan Class Smell IV.2.1 Mengatasi Duplikasi Field Untuk menangani duplikasi pada field, maka field-field di tiap kelas harus didaftarkan membentuk matriks seperti pada Lampiran F. Pada lampiran ini semua field telah didaftarkan, jika ada dimiliki oleh kelas tertentu maka akan diberi angka 1 dan sisanya diberi angka 0. Kolom paling kiri dari matriks itu menunjukkan berapa jumlah kelas yang memiliki field itu. Field yang dimiliki oleh semua kelas itu akan naik menjadi superclass membentuk hubungan is-a, sedangkan untuk kelompok field yang dimiliki oleh kelas tertentu saja dapat membentuk hubungan has-a. Kelas diagram sementara yang terbentuk dapat dilihat pada Gambar IV.2.

53

Penyelesaian dengan disain kelas diagram pada Gambar IV.2 masih belum cukup. Dari beberapa kelas yang ada sebenarnya dapat dibentuk kelas entitas baru. Servicing Database berkaitan erat dengan manajemen data-data klien dan jadwal, maka berdasar analisis dapat dibentuk kelas entitas baru, yaitu Client dan Schedule.

A Adviser Branch

B ClientCategory ClientName Comments

C MonthYear CentralView CentralComments CreatedDate Delay Diff Frequent HariIniS LastSR LevelLog NewNextReviewDate Nilai NRDCount SignOff SrReceived AddingNewSchedule() CheckAnotherSF002KeyInSF001() CheckMoreThanOneYearNoSR() CountUncompleteSchedule() GetDateLastSeen() getIDByAdviserClientBranch() getNextUncompleteSchedule() JustMoveSchedule() ListOfActionRequiredAll() ListOfActionTaken() ListOfBranch() ListOfClientPlusNRD() ListOfClientWOSRInAYear() ListOfDataDetail() ListOfDelayedSR() ListOfFollowingActionTaken() ListOfSF003Data() ListOfSF003Details() ListOfSRDateOnly() ListOfSRGeneral_SubReport() ListOfZeroServicingPeriod() RemoveSRDate() SingleClientMasterData() UpdateClientDetail() UpdateClientFrequent()

ClientCategoryChange AmountRevenue CentralHasProcess CurrentClientCategory GMHasProcess NewClientCategory ReasonRequest

Feeding UpDatesBy UserUpdate DeleteSF002() Ext_UpdateClientCategoryIfNull() Ext_UpdateClientCategoryOnlySpecial() Ext_UpdateClientWOClientCategory() Ext_UpdateOnlyClientCategoryNotSpecial() FrequentAdjustment() MemilihNextReviewDate() Y_InsertClientBaseOnExcel() Y_InsertSchedule() Y_ReActivateDropOff() Y_RemoveDropOffSchedule() Y_SetToDropOff() Y_UpDateClientBaseOnExcel() Y_UpDateColumnSF001()

BranchView

AB Code

UserID getAdviserData() GetDistinctAdviserByBranch() GetNewSF002Data()

AC ActionRequired ActionTaken DateLastSeen NextReviewDate NextStep ReqByAdv SrDate

BC DateIn DateOut SRAttached

Gambar IV.2 Diagram Kelas Sementara Tahap 1

54

ChangeCategoryData() RejectChange() GetChangeCategory_for_sent_to_GM() InsertToChangeCategory()

AdviserView AmountRevenue AUM NextReviewDateOld NRD ReasonRequest SchemeContrib ServiceCategory SpecialCaseNotes tickDeclineSR User Warna getClientData() getDefaultList() InsertToDeclineSR() UpdateClientFrequent() UpdateSchedule()

Langkah pertama adalah mengelompokkan method dengan menandai mana yang merupakan Client dan Schedule. Dengan menggunakan tools bernama Reflector, maka akan dapat diketahui field mana yang dibutuhkan untuk method itu. Method-method itu diambil dari kelas BranchView, AdviserView dan CentralView. Contohnya pada Gambar IV.3 pada method yang ada kemudian pilih analyze, kemudian klik “Depends On”, maka akan terlihat field yang dibutuhkan. Pada contoh Gambar IV.3, field yang dibutuhkan dalam kelas BranchView yaitu: Adviser, Branch, ClientCategory dan UserID. PConn tidak termasuk karena merupakan shared variable yang dapat diakses oleh kelas-kelas lain.

Gambar IV.3 Hasil Analyzer pada method GetAdviserData mendeteksi dependensi

Setelah method dikelompokkan, langkah selanjutnya yaitu Move Method. Method dibawah ini dipindah dari : 1. BranchView a. GetNewSF002Data (ke Schedule) 2. CentralView a. AddingNewSchedule (ke Schedule) b. CheckAnotherSF002KeyInSF002 (ke Schedule) c. CheckMoreThanOneYearNoSR (ke Client) d. CountUncompleteSchedule (ke Schedule) e. GetDateLastSeen (ke Schedule) f. getIDByAdviserClientBranch (ke Client) g. getNextUncompleteSchedule (ke Schedule) h. JustMoveSchedule (ke Schedule) 55

i. ListOfClientPlusNRD (ke Client) j. ListOfClientWOSRInAYear (ke Client) k. ListOfDataDetail (ke Client) l. ListOfDelayedSR (ke Schedule) m. ListOfSF003Data (ke Schedule) n. ListOfSF003Details (ke Schedule) o. ListOfSRDateOnly (ke Schedule) p. ListOfSRGeneral_SubReport (ke Schedule) q. ListOfZeroServicingPeriod (ke Schedule) r. RemoveSRDate (ke Schedule) s. SingleClientMasterData (ke Client) t. UpdateClientDetail (ke Client) 3. AdviserView a. GetClientData (ke Client) b. GetDefaultList (ke Client) c. InsertToDeclineSR (ke Schedule) d. UpdateClientFrequent (ke Client) e. UpdateSchedule (ke Schedule)

Seluruh method pada AdviserView dipindah, berarti field yang ada juga ikut dipindah. Ini dapat menyebabkan kelas AdviserView menjadi tidak terpakai kembali. Kelas baru yang terbentuk beserta method yang telah dibentuk, dapat dilihat pada Lampiran H. Kelas entitas yang terdapat pada lampiran tersebut adalah kelas-kelas setelah method dipindahkan, sedangkan field-nya dipakai jika dibutuhkan dalam method itu dan belum ada hubungan antarkelas. Setelah dikelompokkan beberapa method dan field ke kelas baru, maka yang menggunakan method itu harus menyesuaikan ke pemanggilan kelas yang baru, hanya nama method dan signature tetap sama. Untuk mengetahui bagian program mana yang menggunakan method itu, maka dengan Reflector dapat diketahui dengan mengklik bagian “Used By”.

56

Pengelompokkan beberapa method dan field ke kelas entitas baru terlihat lebih baik karena menghindari duplikasi field di banyak kelas walaupun masih saja ada duplikasi beberapa field di antara kelas-kelas baru dan kelas lama itu. Setelah terbentuk kelas baru pada Lampiran H, maka beberapa field yang ada pada tiap kelas harus diidentifikasikan bahwa field yang ada itu sebenarnya merupakan milik kelas mana, dapat berupa kelas Client, Schedule atau diluar dari keduanya. Usulan kelas baru yang dapat dibentuk lagi yaitu: 1. ActionTakenRequired: properti dari kelas ini dapat dilihat pada kelas M_ActTakenCode dan akan berelasi dengan klien yang telah memiliki jadwal. 2. Adviser: kelas ini akan berinteraksi dengan Client walaupun properti yang dimiliki sangat sedikit. 3. SystemUser: kelas ini memiliki beberapa properti diluar semua kelas, properti ini dibutuhkan ketika pengguna melakukan login ke sistem untuk menggunakan sistem ini.

Tabel IV.1 Field pada kelas Client yang akan dipindah

Nama field

Pindah ke kelas

Alasan pindah

ActionRequired

ActionTakenRequired

Bukan properti asli dari klien, tetapi muncul jika ada jadwal

ActionTaken

ActionTakenRequired


Adviser

Adviser

properti

disini

adalah

nama

adviser yang akan berelasi dengan klien, bukanlah properti asli dari klien Branch

Adviser

properti disini adalah branch dari adviser yang akan berelasi dengan klien, bukanlah properti asli dari klien

CommentA

Schedule

Muncul karena berelasi dengan 57

Tabel IV.1 Field pada kelas Client yang akan dipindah (lanjutan)

Nama field

Pindah ke kelas

Alasan pindah jadwal

DateLastSeen

Schedule

Muncul karena berelasi dengan jadwal

HariIniS

SystemUser

Bukan properti asli dari klien, melainkan dari sistem atau sesi

LevelLog

SystemUser


MonthYear

SystemUser


NB

Schedule


NextReviewDate

Schedule


NewNextReviewDate

Schedule


NextStep

ActionTakenRequired


Nilai

Schedule

Muncul karena berelasi dengan jadwal, nilai sendiri adalah selisih hari antara SRDate dengan tanggal hari ini

ReqByAdv

ActionTakenRequired


SignOff

SystemUser


SRAttached

Schedule


SRDate

Schedule

Muncul karena berelasi dengan 58

Tabel IV.1 Field pada kelas Client yang akan dipindah (lanjutan)

Nama field

Pindah ke kelas

Alasan pindah jadwal

User

SystemUser


NRD

Schedule


NRD_Count

Schedule


Warna

Schedule

Muncul karena berelasi dengan jadwal,

warna

itu

sendiri

menunjukkan indikator mengenai umur jadwal yang belum dipenuhi Tabel IV.2 Field pada kelas Schedule yang akan dipindah

Nama field ActionRequired

Pindah ke kelas ActionTakenRequired

Alasan pindah Bukan properti asli dari jadwal, tetapi

muncul

jika

berinteraksi

dengan klien ActionTaken

ActionTakenRequired

Bukan properti asli dari jadwal, tetapi

muncul

jika

berinteraksi

dengan klien Adviser

Adviser

properti disini adalah nama adviser yang akan berelasi dengan klien yang memiliki jadwal, bukanlah properti asli dari jadwal

Branch

Adviser

properti disini adalah branch dari adviser yang akan berelasi dengan klien

yang

memiliki

jadwal,

bukanlah properti asli dari jadwal ClientCategory

Client

Muncul karena berelasi dengan klien 59

Tabel IV.2 Field pada kelas Schedule yang akan dipindah (lanjutan)

Nama field

Pindah ke kelas

Alasan pindah

ClientName

Client

Muncul karena berelasi dengan klien

Code

Client


Comments

Client


CreatedDate

SystemUser

Bukan properti asli dari jadwal, melainkan dari sistem atau sesi

DateInSystem

SystemUser


Frequent

Client


LevelLog

SystemUser


MonthYear

SystemUser


NB

Client


NextStep

ActionTakenRequired


muncul

jika

berinteraksi

dengan klien ReqByAdv

ActionTakenRequired


muncul

jika

berinteraksi

dengan klien SignOff

SystemUser


User

SystemUser


Isi properti dan method untuk kelas BranchView lebih cocok untuk kelas Adviser secara keseluruhan, maka kelas tersebut dapat berubah menjadi kelas Adviser. Setelah nama kelas tersebut berubah, maka properti bernama Adviser harus diganti menjadi AdviserName dan bagian program yang menggunakannya juga harus menggunakan nama kelas yang baru. 60

Pada kelas CentralView, field bernama ActionTaken dan ActionRequired adalah field untuk kelas ActionTakenRequired. Method ListOfActionRequiredAll, ListOfActionTaken dan ListOfFollowingActionTaken

adalah

method

yang

seharusnya

dimiliki

oleh

kelas

ActionTakenRequired. Sisanya adalah field bernama Branch dan method ListOfBranch akan menjadi bagian dari kelas SystemUser. Dengan pindahnya semua kelas dan method, kelas CentralView akan menjadi hilang dan tidak akan digunakan lagi. Hasil dari analisis ini akan didapat diagram kelas pada Gambar IV.4.

Gambar IV.4 Diagram Kelas Akhir

61

IV.2.2 Mengatasi Data Class Setelah diagram kelas terbentuk pada Gambar IV.4, langkah berikutnya adalah menentukan diantara field-field yang ada apakah membutuhkan method setter/getter atau tidak. Jika ada field yang membutuhkan method setter, maka harus ditentukan batasan nilai yang diperbolehkan dari field. Daftar kriteria field pada tiap-tiap kelas yang berisi tipe data, nilai yang diperbolehkan dan kebutuhan setter/getter-nya dapat dilihat pada Lampiran J. Suatu field harus diatur constraintnya agar lebih memiliki makna dan nilainya valid. Dari Lampiran J terdapat beberapa jenis constraint, yaitu: 1. Nama orang: digunakan untuk nama adviser atau nama klien. Huruf yang diperbolehkan alfabet ditambah tanda baca seperti koma, titik, kutip satu, kutip dua, strip dan underscore. 2. Periode (yyyymm), misalnya bulan Mei tahun 2008, berarti ditulis 200805. 3. Karakter bebas: digunakan untuk komentar atau userid (untuk login ke sistem). 4. Bit: angka 0 atau 1, dapat sebagai pengganti true (angka 1) atau false (angka 0). 5. Money: untuk bilangan pecahan, biasa untuk nilai uang. 6. Bilangan bulat/integer positif: untuk jumlah yang dapat dihitung, seperti nilai dan NRD_Count. 7. Nama cabang/branch: menunjukkan nama negara, rata-rata menggunakan alfabet. 8. Alfanumerik: campuran huruf dan angka, untuk userid pada klien. 9. Tanggal (dd/mm/yyyy):untuk data yang mengandung tanggal, misalnya 12 Juli 2008 ditulis dengan 12/07/2008. 10. Bilangan bulat terbatas 0-12: digunakan untuk Frequent. 11. Char: untuk ClientCategory yang bernilai A,B,C,D,E,F dan tidak menutup kemungkinan ada kategori baru seperti G,H,I,J,K,dan seterusnya jika ada permintaan perubahan.

Berdasarkan Lampiran J, ada beberapa field yang memerlukan setter saja, getter saja, setter dan getter ataupun tidak memiliki sama sekali. Tidak semua field boleh diberikan setter atau getter. Jika pada penggunaan tidak digunakan, sebaiknya fitur setter atau getter tidak perlu ditampilkan. Pada kebutuhan berikutnya, diantara setter atau getter dapat saja dimunculkan. Kesimpulan mengenai kriteria field, yaitu: 62

1. Setter saja: nilai field sudah pasti didapatkan dari method yang ada di dalam kelas itu sendiri dan nilai field dapat dimodifikasi dari luar kelas itu tanpa melakukan perolehan nilai terhadap field itu. 2. Getter saja: nilai field sudah pasti didapatkan dari method yang ada di dalam kelas itu sendiri dan nilai field dapat diperoleh dari luar kelas tanpa ada modifikasi dari luar kelas itu. 3. Setter dan getter: nilai field sudah pasti didapatkan dari method yang ada di dalam kelas itu sendiri, selain itu nilai field dapat diperoleh/dimodifikasi dari luar kelas itu sendiri. 4. Tidak memiliki setter dan getter: nilai field didapatkan dari method yang hanya di dalam kelas itu sendiri dan tidak pernah dilakukan modifikasi ataupun perolehan nilai dari luar dari kelas itu sendiri.

IV.3 Evaluasi Penanganan Class Smell dan Code Smell Metode penanganan duplikasi pada kode dapat dilakukan dengan melihat pola-pola yang serupa pada bagian kode. Beberapa method dapat menjadi satu method saja dan ditambahkan suatu parameter di dalam method itu. Penanganan duplikasi ini dapat membutuhkan usaha yang besar jika banyak bagian kode dari suatu halaman web yang menggunakan kode itu, tetapi ini dapat membuat suatu kode bersifat fleksibel. Jika ada penambahan kebutuhan baru, maka tidak perlu untuk membuat method dengan style code yang sama lagi, melainkan dengan menggunakan method yang sudah ada hanya saja parameternya berbeda. Metode Extract Class/Subclass/Superclass biasanya dilakukan untuk menangani smell yang berhubungan dengan kelas, metode ini dapat juga untuk menangani duplikasi pada kode, masalah kondisional if-else. Kelas yang awalnya merupakan kelas-kelas besar, setelah ditangani melalui beberapa metode refactoring yang ada, maka secara otomatis akan menyebabkan ukuran kelas mengecil bahkan beberapa kelas ada yang akhirnya dihapus atau berubah namanya. Teknik-teknik refactoring yang telah dilakukan ini menyebabkan struktur program yang berorientasi objek ini menjadi lebih baik daripada program yang sebelum di-refactor. Struktur 63

program yang baik ini membuat suatu aplikasi ini mudah dirawat jika pada suatu saat terjadi perubahan terhadap perangkat lunak ini.

IV.4 Solusi Aksesibilitas Aplikasi Servicing Database selama ini diakses hanya melalui web saja yang biasa dilakukan melalui PC Desktop atau notebook. Mobilitas yang sangat tinggi dan munculnya teknologi mobile computing dapat menyebabkan muncul usulan agar aplikasi ini dapat diakses melalui handphone. Pengaksesan informasi melalui handphone dibagi menjadi dua cara, yaitu melalui SMS dan WAP.

IV.3.1 Disain Berbasis WAP Halaman WAP memiliki keterbatasan dengan halaman web biasa, yaitu dari segi tampilan dan fitur-fitur teknologi dalam bahasa pemrograman. Fungsi-fungsi yang akan disajikan di dalam WAP ini hanyalah untuk melihat report-report saja yang bersifat urgent.

Report pada halaman web dapat diekspor dalam bentuk lain yang dapat dicetak, tidak seperti halaman WAP yang hanya untuk dilihat saja. Nilai-nilai data yang tertera pada halaman WAP dapat sama seperti halaman web walaupun berbeda dari segi tampilan.

Antarmuka layar antara pengguna dengan sistem dibuat semirip mungkin dengan antarmuka berbasis web. Jika pengguna sudah terbiasa menggunakan antarmuka yang berbasis web, maka dengan kemiripan antarmuka tersebut akan memudahkan untuk menggunakan sistem yang berbasis WAP. Keseluruhan disain tampilan WAP dapat dilihat pada Lampiran L yang dikelompokkan berdasarkan kelas pengguna, kemudian berdasarkan menu yang dimiliki. Struktur menunya adalah sebagai berikut: 1. Adviser a. Home b. Schedule Aging c. Log Off 2. Branch 64

a. Home b. SF002 c. Log Off 3. Central a. Home b. Client List Plus NRD c. Client List Without SR d. Reschedule Report e. SF001 f. SF002 g. SF003 h. List Of Execution Only i. SR General Report j. Log Off

Kelas diagram untuk aplikasi berbasis web (Gambar IV.4) dapat berlaku untuk aplikasi berbasis WAP, hanya saja nama method yang mengandung kata “update”, “add”, “delete” dan “insert” tidak dibutuhkan karena pada aplikasi berbasis WAP hanya bersifat readonly. Ada beberapa method dan field yang pada akhirnya tidak digunakan setelah melalui beberapa proses analisis menggunakan tools. Diagram kelas pada akhirnya dihasilkan menjadi seperti Gambar IV.5. Fitur dalam teknologi bahasa pemrograman terbatas untuk membuat halaman yang berbasis WAP. Beberapa kontrol yang terbatas dapat dimanfaatkan semaksimal mungkin agar menyerupai halaman web. Fitur autopostback pada halaman WAP ini tidak didukung, contohnya halaman yang mengandung dropdownlist pada Branch yang seharusnya akan menampilkan daftar nama-nama adviser pada dropdownlist adviser jika pilihan pada dropdownlist Branch berubah. Oleh karena itu pengguna memilih Branch terlebih dahulu, kemudian klik hyperlink untuk memuat daftar nama-nama adviser pada dropdownlist adviser.

65

Gambar IV.5 Diagram Kelas Servicing Database Versi WAP

IV.3.2 Disain Berbasis SMS Informasi yang disajikan dalam SMS seharusnya informasi yang bersifat singkat, padat dan jelas. Bentuk informasi bersifat tekstual untuk yang berbasis SMS, tidak seperti aplikasi web/desktop yang disajikan tidak hanya berupa tekstual, tetapi juga bersifat grafikal. Keterbatasan fasilitas SMS ini dapat dimanfaatkan semaksimal mungkin untuk mencapai aksesibilitas dalam mengakses informasi yang ada dalam aplikasi. Pada aplikasi berbasis sms ini terdiri atas paket-paket: 1. Basis Data: mengurus masalah koneksi ke basis data. 2. Komunikasi Modem GSM: mengatur komunikasi antara komputer dengan modem GSM untuk terima/kirim sms. 3. Pengolah String: mengolah token string yang diterima, mengatur tampilan pesan SMS balasan yang akan dikirim kepada pengirim sms. SMS yang dikirim ke nomor SMS Gateway itu akan diterima melalui suatu paket nomor 2, kemudian pesan yang diterima itu diolah oleh paket nomor 3 untuk dikenali perintah66

perintahnya. Jika membutuhkan suatu data yang mengambil dari basis data, paket nomor 3 akan memanggil paket nomor 1. Hasil query diterima dari paket 1 ke paket 3, kemudian paket 3 akan mengatur tampilan sms yang akan dikirim kepada pengirim. Setelah tampilan sms siap, maka paket 3 akan memanggil paket 2 untuk mengirimkan sms balasan kepada pengirim.

Gambar IV.6 Diagram alur kerja SMS Server

Disain berupa flowchart pada Lampiran K menggambarkan logika mengenai pengenalan perintah pesan sms yang diterima dan aksi-aksi apa saja yang akan dilakukan.

Tidak semua informasi dalam perintah sms diperbolehkan untuk semua kelas pengguna (Central, Adviser, Branch) karena masing-masing kelas pengguna memiliki hak akses tertentu, maka pseudocode yang mendukung untuk beberapa perintah sms:

A.Yang diikuti Client if akses=Central then BolehAksesSemua

67

elseif akses=Branch then Branch yang boleh mana saja? Periksa branch dari klien itu Jika klien ada di branch tsb, akses diperbolehkan elseif akses=Adviser then Apakah klien tersebut milik adviser tsb? Jika iya,akses diperbolehkan

B.Yang diikuti MonthYear if akses=Central then BolehAksesSemua elseif akses=Branch then Periksa branch dari adviser itu Jika branch adviser sesuai dengan hak akses,akses diperbolehkan elseif akses=Adviser then jika adviser=dirinya sendiri, akses diperbolehkan

C.Yang diikuti ListClient if akses=Central then BolehAksesSemua elseif akses=Branch then Periksa branch dari adviser itu Jika branch adviser sesuai dengan hak akses,akses diperbolehkan elseif akses=Adviser then jika adviser=dirinya sendiri, akses diperbolehkan

Paket Komunikasi Modem GSM sudah tersedia fungsinya, maka kelas-kelas tambahan yang dibutuhkan yaitu: 1. Kelas FungsiSQL: menyimpan variabel dan fungsi global untuk koneksi ke basis data. 2. Kelas SesiUser: menyimpan session terhadap pengguna yang melakukan pemintaan informasi melalui sms. 3. Kelas QueryClient dan turunannya: melakukan query dengan input berupa userid dari seorang klien. 4. Kelas StringUtils: melakukan pengolahan terhadap suatu String. Spesifikasi dari kelas-kelas perancangan SMS Server, dapat dilihat lebih rinci pada Lampiran I. Pada lampiran ini, tiap-tiap kelas perancangan disebutkan visibility dan keterangan tentang field yang digunakan dan operasinya. Dari spesifikasi, maka akan terbentuk kelas diagram pada Gambar IV.7.

68

Gambar IV.7 Diagram Kelas Untuk SMS Server

69

Bab IV Rekayasa Ulang Perangkat Lunak

Recommend Documents