ANALISIS DAN PERANCANGAN
3.1.7 Pemodelan Use Case
3.1.7.4 Skenario Use Case
3.1.7.4.11 Skenario Use Case Mengunduh Data Historis Saham Manual
Skenario normal dari use case Mengunduh Data Historis Saham Manual dapat dilihat pada Gambar 3.12.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Gambar 3.12 Activity Diagram untuk Use Case Mengunduh Data Historis Saham Manual
Proses pada Activity Diagram dimulai dengan pengecekan data di tabel pada database berdasarkan masukan (input) saham dan rentang waktu yang diinginkan pengguna. Jika data tersedia maka tidak perlu mengunduh data saham itu lagi. Sedangkan jika data tidak tersedia, maka dilakukan proses memformat URL untuk situs yang selanjutnya yaitu membangun koneksi ke dilakukan konfigurasi jaringan terlebih dahulu yaitu dengan melakukan setting proxy.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Jika koneksi ke situs dapat diunduh, sedangkan jika koneksi gagal maka file yang error akan dicatat dalam file log kemudian diberitahukan kepada pengguna. Setelah data historis saham berhasil diunduh maka data tersebut disimpan dalam format file csv. Kemudian data historis saham dalam format file csv tersebut dimasukkan ke dalam tabel historis saham yang terdapat di database. Jika data historis saham berhasil dimasukkan ke dalam database maka proses pada Activity Diagram ini akan selesai, sedangkan jika gagal maka akan dicatat dalam file log.
3.2 Perancangan
Pada bagian ini akan dijelaskan perancangan perangkat lunak yang akan dibangun, dengan berdasarkan pada analisis perangkat lunak di atas. Perancangan yang akan dilakukan meliputi perancangan kelas, perancangan antarmuka dan perancangan logika data dari perangkat lunak yang akan dibangun.
Perancangan Kelas
Sebelum masuk ke perancangan Class Diagram, sebaiknya kita memahami terlebih dahulu bagaimana sebenarnya proses yang terjadi antara client dan server pada aplikasi berbasiskan web. Dengan memahami cara kerjanya tentunya akan lebih mudah untuk menentukan pola (patterns) yang benar-benar sesuai sebagai dasar untuk melakukan perancangan aplikasi secara keseluruhan.
HTTP Requests
HTTP Request merupakan kejadian (event) yang dikirimkan oleh client untuk meminta satu atau lebih resources kepada server. Dalam konteks aplikasi berbasiskan web, resources yang diminta biasanya berupa file terformat yang dapat diterjemahkan langsung oleh browser, seperti HTML dan javascript. Selain itu, resources juga dapat
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
berupa file dalam format gambar (contoh: *.jpeg, *.gif, *.png) dan bahkan bisa juga berupa executable-file (contoh: *.exe, *.sh), compressed-file (contoh: *.rar, *.zip) dan sebagainya.
Berdasarkan metode pengiriman datanya, HTTP Request dapat dikategorikan kedalam dua jenis yaitu GET atau POST. Gambar di bawah memperlihatkan bagaimana HTTP Request ini terjadi antara client dan server.
Gambar 3.13 HTTP Request diperlihatkan sebagai suatu kejadian inisialisasi antara client dan server
Dari gambar diatas terlihat bahwa client mengirimkan kejadian (event) berupa HTTP Request yang diinisialisasi melalui browser kepada antar muka aplikasi yang ada di server, dimana metode pengiriman yang dilakukan dapat berupa GET atau POST. Dari gambar kita mengidentifikasi antar muka aplikasi sebagai lapisan presentasi yang merupakan bagian dari server process.
Event Evaluation
HTTP Request yang dikirim oleh client selanjutnya tidak akan diproses oleh antar muka aplikasi tetapi akan diteruskan dan dievaluasi terlebih dahulu oleh server process yang lainnya untuk menentukan resources yang sesuai dan jika diperlukan akan dilakukan kolaborasi dengan objek-objek database. Evaluasi ini tentunya akan
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
melibatkan interaksi terhadap proses bisnis dari aplikasi. Sangat dianjurkan bahwa proses bisnis dari sistem harus dievaluasi dan dimengerti terlebih dahulu sebelum fisik sistem diimplementasikan, itulah mengapa kita memerlukan tahapan analisis di bab sebelumnya.
Lapisan yang bertugas mengevaluasi HTTP Request ini akan diidentifikasi sebagai lapisan bisnis dan lapisan yang nantinya berinteraksi dengan objek-objek database diidentifikasi sebagai lapisan data. Gambar di bawah memperlihatkan bagaimana lapisan presentasi mengirimkan pesan kepada lapisan bisnis yang berhubungan langsung dengan lapisan data untuk mengevaluasi input yang tepat untuk setiap HTTP Request yang dikirimkan oleh client.
Gambar 3.14 Interaksi antara lapisan presentasi, bisnis dan data
Pemisahan setiap server process kedalam lapisan presentasi, bisnis dan data akan memudahkan dalam perancangan, implementasi dan perawatan sebuah aplikasi. Bila terjadi kesalahan atau ada bagian tertentu yang ingin diubah, misal di bagian antar muka, maka hanya lapisan presentasinya saja yang perlu dirubah tanpa harus menyentuh atau memodifikasi lapisan bisnis ataupun data.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Output States
Selain menangani input oleh client, lapisan presentasi juga bertanggung jawab untuk mengirimkan kembali output yang sesuai (biasanya adalah halaman HTML) beserta interaksinya kepada client. Setiap response yang berasal dari lapisan di bawahnya akan dikirimkan kembali kepada client berupa HTTP Response. HTTP Response ini selanjutnya akan dikirimkan kembali ke client dan diformat oleh browser untuk ditampilkan outputnya. Gambar dibawah memperlihatkan response dari server process kepada client.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Untuk menentukan output yang sesuai, lapisan presentasi memerlukan akses ke informasi bisnis. Ini dimungkinkan dengan cara mengirimkan pesan kepada lapisan bisnis yang kemudian akan diteruskan kepada lapisan pengolahan data, kemudian data yang diperoleh dari lapisan data akan dikirimkan kembali ke lapisan presentasi untuk dikirimkan kemudian diformat dan ditampilkan oleh browser client.
Perancangan Class
Berdasarkan konsep di atas, dapat diidentifikasi proses yang terjadi di server ke dalam tiga lapisan yang memiliki tanggung jawabnya masing-masing. Dalam konteks perancangan aplikasi berbasiskan web, pemisahan server process tersebut ke dalam tiga lapisan dikenal luas sebagai pola Model-View-Controller (MVC patterns) dimana pola ini sangat popular dan yang paling banyak digunakan sebagai framework standar untuk pembuatan aplikasi web modern. Gambar di bawah memperlihatkan bagaimana pola MVC ini diilustrasikan.
Gambar 3.16 Penerapan pola MVC
Lapisan pada konsep di sub bab sebelumnya dapat dianalogikan sebagai berikut ke dalam pola MVC:
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
1. Lapisan Data: Model 2. Lapisan Presentasi: View 3. Lapisan Bisnis: Controller
Setiap kejadian akan menyebabkan controller untuk merubah model, view bahkan bisa juga keduanya. Ketika Controller merubah model data, seluruh view yang terkait akan secara otomatis memperbaharui keadaannya. Demikian juga ketika Controller merubah View, View akan mengambil data langsung ke Model untuk memperbaharui keadaannya secara langsung.
Pada saat perancangan sistem, baik Model, View maupun Controller akan diimplementasikan masing-masing ke dalam sebuah Class. Berikut adalah gambar dari Class yang akan menjadi dasar perancangan sistem.
Gambar 3.17 Struktur Class Diagram dasar
Pada gambar terlihat bahwa View dan Controller memiliki ketergantungan kepada Model dan Controller juga memiliki ketergantungan dengan View. Dalam class diagram, hubungan tersebut diperlihatkan sebagai tanda panah putus-putus.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Selanjutnya struktur class dasar tersebut akan diperluas dengan menambahkan class bantu yang membantu dan melengkapi class dasar di atas. Gambar di bawah memperlihatkan struktur class diagram yang telah disempurnakan.
Gambar 3.18 Struktur Class Diagram yang sudah disempurnakan
Dari gambar terlihat bahwa terdapat tiga class tambahan yaitu Object Loader, Error Handler dan Data Access. Adapun maksud dan tujuan penambahan class tersebut adalah sebagai berikut:
1. Object Loader berfungsi membantu Controller untuk berinteraksi dengan Model dan objek-objek eksternal dari sistem seperti file konfigurasi, pustaka (library) pendukung dan script-script eksternal lainnya.
2. Error Handler berfungsi menampilkan pesan-pesan kesalahan terhadap request dan response yang mungkin terjadi selama pemrosesannya di Controller.
3. Data Access berfungsi sebagai jembatan yang memudahkan Model berinteraksi dan berkomunikasi dengan database.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Struktur class diagram di atas selanjutnya akan menjadi framework (kerangka kerja) dalam pembuatan fungsi-fungsi spesifik yang akan diimplementasikan oleh aplikasi SAFIRA.
Selanjutnya akan diaplikasikan framework tersebut ke dalam aplikasi itu sendiri. Perancangan terhadap pemodelan aplikasi dilakukan dengan memanfaatkan class yang ada pada framework dengan cara menurunkan (mewariskan) class di level framework kepada class di level aplikasinya. Untuk lebih jelasnya berikut diberikan gambar pemisahan class di level framework dan di level aplikasi.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
diturunkan oleh class di level aplikasi, sedangkan class View tidak akan diturunkan kepada class manapun tetapi akan diimplementasikan sebagai file template dalam format HTML. Untuk class-class lainnya tidak akan digunakan secara langsung di level aplikasi, karena akan diatur penggunaan dan aksesnya oleh level framework. Kelas-kelas pada level aplikasi merupakan kelas-kelas turunan dari kelas framework yang digunakan untuk merealisasikan fungsi-fungsi khusus untuk aplikasi SAFIRA ini.
Dengan memisahkan model kedalam konteks framework dan aplikasi akan memudahkan kita dalam pengembangan aplikasi kedepannya. Level framework akan terus berlaku konsisten dalam implementasi aplikasi, sedangkan level aplikasi akan terus bertambah dinamis tergantung kompleksitas dan skalabilitas aplikasi.
Perancangan Antarmuka
Desain antarmuka pengguna merupakan proses perancangan yang paling ringan dan implementasinya juga tidak memakan waktu yang lama. Berikut ini akan membahas fitur-fitur yang akan diimplementasikan sebagai antarmuka aplikasi yang berinteraksi langsung dengan pengguna. Adapun langkah untuk melakukan perancangan antarmuka perangkat lunak ini dibagi ke dalam dua tahapan, yaitu:
1. Memetakan navigasi antarhalaman aplikasi.
2. Merancang dialog untuk setiap kejadian yg mungkin dilakukan oleh pengguna.
Navigasi Antarhalaman
Sebuah antarmuka pengguna tentunya akan melibatkan banyak screen yang dalam konteks aplikasi web sering disebut sebagai halaman web. Sebuah antarmuka aplikasi harus dapat mengkoordinasikan halaman-halaman tersebut sehingga akan diperoleh ketersambungan informasi antara halaman yang satu dengan halaman yang lainnya.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Untuk itulah diperlukan gambar konsep yang dapat menjelaskan bagaimana keterkaitan antarhalaman tersebut. Pada Tugas Akhir ini, statechart diagram akan digunakan untuk memperlihatkan koordinasi antarhalaman tersebut sehingga akan jelas tergambar navigasi dari aplikasi SAFIRA. Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima, dimana dalam hal ini halaman merupakan objek dari class view.
Gambar 3.20 Statechart diagram memperlihatkan navigasi dari aplikasi
Gambar kotak pada gambar di atas memperlihatkan sebuah kedaan (state) yang dalam konteks perancangan antarmuka nantinya akan diimplementasikan sebagai sebuah halaman web. Anak panah menggambarkan aliran kontrol dan akan menggerakkan kejadian yang menyebabkan sebuah halaman menjadi aktif atau menerima fokus. Anak panah juga menggambarkan bagaimana urutan munculnya halaman-halaman tersebut. Jenis halaman pada gambar dapat juga kita bedakan
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
berdasarkan stereotypenya yg diberi simbol <<nama_stereotype>> pada bagian atas kotak. Adapun stereotype yg bisa diidentifikasi adalah sebagai berikut:
1. <<index>>
Halaman yang pertama sekali dibuka oleh pengguna setiap pertama sekali mengakses aplikasi. Dalam tahapan implementasi, stereotype ini akan lebih dikenal sebagai homepage.
2. <<screen>>
Halaman-halaman spesifik fungsi lainnya penyusun aplikasi SAFIRA yang tentunya dapat berinteraksi dengan halaman-halaman lain dan memungkinkan juga untuk berinteraksi dengan halaman <<index>>.
3. <<form>>
Bagian yang tidak dapat terpisahkan dari <<screen>> ataupun <<index>> yang tidak dapat berdiri sendiri sebagai sebuah halaman.
Perancangan Dialog Halaman
Pada dasarnya layout yang digunakan adalah sama untuk seluruh halaman. Setiap halaman harus memiliki tiga elemen penyusun antarmukanya, yaitu:
1. Bagian Kepala (header)
Seluruh elemen yang berkaitan dengan identitas dari aplikasi diletakkan pada bagian ini, seperti: Logo aplikasi, link ke halaman utama.
2. Bagian Isi (contents)
Bagian utama dari aplikasi yang berfungsi menampilkan isi sebenarnya dari aplikasi, seperti: data saham, hasil analisis dalam bentuk tabel dan hasil analisis dalam bentuk grafik, dan sebagainya.
3. Bagian Kaki (footer)
Bagian yang berisi informasi yang sifatnya opsional, seperti informasi mengenai developer, versi dari aplikasi dan engine pembangun aplikasi ini.
Adapun konsep perancangan antarmuka aplikasi ini digambarkan seperti gambar di bawah ini:
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Gambar 3.21 Layout yang konsisten digunakan untuk setiap halaman
Rancangan Halaman Utama
Halaman yang pertama sekali ditampilkan ke pengguna setiap mereka membuka aplikasi SAFIRA. Pada halaman ini akan ditampilkan seluruh daftar Indeks Harga Saham Gabungan (IHSG) berdasarkan kawasan yang terpilih (secara default akan diset sebagai kawasan Asia) dan diurutkan berdasarkan nama indeks saham. Informasi pergerakan indeks saham yang ditampilkan adalah harga pada posisi terakhir sekali yang didownload oleh aplikasi.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Gambar 3.22 Rancangan Halaman Utama Aplikasi
Untuk dapat melihat informasi detail setiap indeks saham pada halaman ini akan disediakan link ke halaman berikutnya. Link tersebut pada gambar di atas diperlihatkan sebagai indeks-1 sampai dengan indeks-n.
Rancangan Halaman Dashboard IHSG
Halaman ini menampilkan informasi lebih detail mengenai indeks saham yang terpilih pada halaman utama. Halaman ini akan menampilkan informasi secara lebih rinci, lengkap dan informatif terhadap data indeks saham, seperti harga indeks saham pada posisi terakhir didownload beserta grafik pergerakan indeks saham selama satu hari. Di bagian paling bawah dari elemen contents akan diberikan dua buah tombol yang fungsinya untuk melihat data historis dari indeks dan melihat daftar saham apa saja yang menyusun indeks tersebut.
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Gambar 3.23 Rancangan Halaman Dashboard IHSG
Rancangan Halaman Historis IHSG
Halaman ini berfungsi menampilkan data historis atau data penutupan (closing) indeks saham dalam periode (rentang waktu) tertentu. Pengguna dapat memilih periode (rentang waktu) indeks saham yang diinginkan dengan memilihnya dari masukan tanggal mulai dan tanggal selesai. Untuk kembali ke halaman sebelumnya, nantinya pengguna dapat melakukannya dari link navigasi yang berada di bagian paling atas dari elemen contents.
Gambar 3.24 Rancangan Halaman Historis IHSG
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
Halaman ini diakses ketika pengguna mengklik tombol Daftar Saham pada halaman Indices Dashboard. Halaman ini dimaksudkan untuk menampilkan daftar saham mana saja yang menyusun Indeks Harga Saham Gabungan (IHSG) tersebut. Informasi yang ditampilkan adalah harga pergerakan saham pada posisi terakhir sekali yang didownload oleh aplikasi.
Gambar 3.25 Rancangan Halaman Daftar Saham
Untuk dapat melihat informasi detail setiap saham pada halaman ini akan disediakan link ke halaman berikutnya. Link tersebut pada gambar di atas diperlihatkan sebagai Saham-1 sampai dengan Saham-n.
Rancangan Halaman Dashboard Saham
Halaman ini menampilkan informasi lebih detail mengenai saham yang terpilih pada halaman Daftar Saham. Halaman ini akan menampilkan informasi secara lebih rinci,
Shafira Guslina : Perancangan Perangkat Lunak Prediksi Pergerakan Harga Saham Dengan Metode Relative Strength Index (RSI), 2009.
lengkap dan informatif terhadap data saham, seperti harga saham pada posisi terakhir didownload beserta grafik pergerakan saham selama satu hari. Di bagian paling bawah dari elemen contents akan diberikan dua buah tombol yang fungsinya untuk melihat data historis dari saham dan tombol untuk melakukan analisis teknikal menggunakan metode RSI.
Gambar 3.26 Rancangan Halaman Dashboard Saham