5
2.1 Rekayasa Perangkat Lunak
Istilah software engineering, pertama kali digunakan pada akhir tahun 1950-an dan sekitar awal 1960-an. Pada tahun 1968, NATO menyelenggarakan konfrensi tentang software engineering di Jerman dan kemudian dilanjutkan pada tahun 1969. Rekayasa Perangkat Lunak (RPL) adalah satu bidang profesi yang mendalami cara-cara pengembangan perangkat lunak termasuk pembuatan, pemeliharaan, manajemen organisasi pengembangan perangkat lunak dan manajemen kualitas. IEEE Computer Society mendefinisikan rekayasa perangkat lunak sebagai penerapan suatu pendekatan yang sistematis, disiplin dan terkuantifikasi atas pengembangan, penggunaan dan pemeliharaan perangkat lunak, serta studi atas pendekatan-pendekatan ini, yaitu penerapan pendekatan engineering atas perangkat lunak.
Banyak orang menyamakan istilah perangkat lunak dengan program komputer. Sesungguhnya, perangkat lunak tidak hanya mencakup program, tetapi juga semua dokumentasi dan konfigurasi data yang berhubungan, yang diperlukan untuk membuat agar program beroperasi dengan benar. (Sommerville, 2003)
Sedangkan rekayasa perangkat lunak menurut Sommerville (2003) adalah disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan.
Proses perangkat lunak adalah serangkaian kegiatan dan hasil-hasil relevannya yang menghasilkan perangkat lunak. Ada empat kegiatan proses dasar yang umum bagi seluruh kegiatan proses perangkat lunak, yaitu :
1. Spesifikasi perangkat lunak.
Fungsionalitas perangkat lunak dan batasan kemampuan operasinya harus didefinisikan.
2. Pengembangan perangkat lunak.
Perangkat lunak yang memenuhi spesifikasi tersebut harus diproduksi. 3. Validasi perangkat lunak.
Perangkat lunak harus divalidasi untuk menjamin bahwa perangkat lunak melakukan apa yang diinginkan oleh pelanggan.
4. Evolusi perangkat lunak.
Perangkat lunak harus berkembang untuk memenuhi kebutuhan pelanggan yang berubah-ubah.
2.1.2 Model Proses Perangkat Lunak
Model perangkat lunak merupakan deskripsi yang disederhanakan dari proses perangkat lunak yang direpresentasikan dengan sudut pandang tertentu (Sommerville, 2003). Model, sesuai sifatnya, merupakan penyederhanaan, sehingga model proses perangkat lunak merupakan abstraksi dari proses sebenarnya yang dideskripsikan. Model proses bisa mencakup kegiatan yang merupakan bagian dari proses perangkat lunak, produk perangkat lunak, dan peran orang yang terlibat pada rekayasa perangkat lunak.
Beberapa contoh jenis model perangkat lunak yang dapat dihasilkan di antaranya:
1. Model aliran kerja (workflow).
Menunjukkan urutan kegiatan pada proses bersama dengan input, output dan ketergantungannya.
2. Model aliran data (data flow).
Merepresentasikan proses sebagai satu set kegiatan yang masing-masing melakukan transformasi data.
3. Model peran/aksi.
Model ini merepresentasikan peran orang yang terlibat pada proses perangkat lunak dan kegiatan yang menjadi tanggung jawab mereka. Ada sejumlah model atau paradigma umum pada pengembangan perangkat lunak:
1. Pendekatan air terjun (waterfall).
Model ini mengambil kegiatan proses dasar seperti spesifikasi, pengembangan, validasi dan evolusi lalu merepresentasikannya sebagai fase-fase proses yang berbeda seperti spesifikasi persyaratan, perancangan perangkat lunak, implementasi, pengujian dan seterusnya.
Gambar 2.1 Siklus hidup perangkat lunak (Sommerville 43)
2. Pengembangan evolusioner.
Pendekatan ini berhimpitan dengan kegiatan spesifikasi, pengembangan, dan validasi. Suatu sistem awal dikembangkan dengan cepat dari spesifikasi abstrak. Sistem ini kemudian diperbaiki dengan masukan dari pelanggan untuk menghasilkan sistem yang memuaskan bagi kebutuhan pelanggan.
Gambar 2.2 Pengembangan evolusioner (Sommerville 45) 3. Pengembangan sistem formal.
Pendekatan ini didasarkan atas pembuatan spesifikasi sistem matematis dan pentransformasian spesifikasi ini, dengan memakai metode matematis, untuk membangun program.
2.3 Pengembangan sistem formal (Sommerville 46)
4. Pengembangan berdasarkan pemakaian ulang.
Pendekatan ini didasarkan atas adanya komponen yang dapat dipakai ulang dalam jumlah yang signifikan. Proses pengembangan sistem terfokus pada integrasi komponen-komponen ini kedalam suatu sistem, dan bukan mengembangkannya dari awal.
Gambar 2.4 Pengembangan berorientasi pemakaian ulang (Sommerville 48)
2.1.3 Metode Rekayasa Perangkat Lunak
Metode rekayasa perangkat lunak merupakan pendekatan terstruktur terhadap pengembangan perangkat lunak yang bertujuan memfasilitasi produksi perangkat lunak kualitas tinggi dengan cara yang efektif dalam hal biaya. Pendekatan-pendekatan yang berbeda sekarang telah diintegrasikan menjadi satu pendekatan gabungan yang dibangun berdasarkan Unified Modeling Language (UML).
2.2 Unified Modeling Language
Unified Modeling Language (UML) adalah bahasa spesifikasi standar untuk mendokumentasikan, menspesifikasikan, dan membangun sistem perangkat lunak. UML merupakan kesatuan dari bahasa permodelan yang dikembangkan oleh Booch, Object Modeling Technique (OMT) dan Object Oriented Software Engineering (OOSE). Metode Booch dari Grandy Booch sangat terkenal dengan nama metode Design Object Oriented. Metode ini menjadikan proses analisis dan design ke dalam empat tahapan interatif, yaitu: identifikasi kelas-kelas dan objek-objek, identifikasi semantik dari hubungan objek dengan kelas tersebut, perincian interface dan implementasi.
Unified Modeling Language adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi objek (Fowler, 2003).
Lebih lanjut Fowler (2003) menjelaskan pada UML 2 yang diterima oleh komite terkait pada bulan Juni 2003 terdapat 13 jenis diagram resmi yaitu:
Tabel 2.1. Jenis diagram resmi UML (Fowler 17)
Diagram Kegunaan Turunan
Activity Behavior prosedural dan paralel Di UML 1
Class Class, fitur, dan hubungan-hubungan Di UML 1
Communication Interaksi antar objek; penekanan pada jalur
Diagram kolaborasi UML 1
Component Struktur dan koneksi komponen Di UML 1
Composite Structure Dekomposisi runtime sebuah class Baru di UML 2
Deployment Pemindahan artifak ke node Di UML 1
Interaction Overview Campuran sequence dan activity diagram Baru di UML 2
Object Contoh konfigurasi dari contoh-contoh Tidak resmi di UML 1
Package Struktur hirarki compile-time Tidak resmi di UML 1
Sequence Interaksi antar objek; penekanan pada
sequence Di UML 1
State Machine Bagaimana even mengubah objek selama
aktif Di UML 1
Timing Interaksi antar objek; penekanan pada
timing Baru di UML 2
Use case Bagaimana pengguna berinteraksi dengan
sebuah sistem Di UML 1
2.2.1 Activity Diagram
Activity diagram adalah teknik untuk menggambarkan logika prosedural, proses bisnis, dan jalur kerja. Dalam beberapa hal, diagram ini memainkan peran mirip dengan sebuah diagram alir, tetapi perbedaan prinsip antara diagram ini dan notasi diagram alir adalah diagram ini mendukung behavior paralel. (Fowler 163)
Activity diagram seperti sebuah flowchart. Activity diagram menunjukkan tahapan, pengambilan keputusan dan percabangan. Diagram ini sangat berguna untuk menunjukkan operation sebuah obyek dan proses bisnis (Munawar 118)
Gambar 2.5 Activity Diagram (Fowler 164)
Tabel 2.2. Simbol-simbol yang sering digunakan pada saat pembuatan activity diagram (Munawar 109)
Simbol Keterangan
Titik awal
Titik akhir
Activity
Pilihan untuk pengambilan keputusan
Fork; digunakan untuk menunjukkan kegiatan yang dilakukan secara paralel atau untuk menggabungkan dua kegiatan paralel menjadi satu
Rake; menunjukkan adanya dekomposisi
Tanda waktu
Tanda pengiriman
Tanda penerimaan
2.2.2 Class Diagram
Class diagram mendeskripsikan jenis-jenis objek dalam sistem dan berbagai macam hubungan statis yang terdapat di antara mereka. Class diagram juga menunjukkan properti dan operasi sebuah class dan batasan-batasan yang terdapat dalam hubungan-hubungan objek tersebut. UML menggunakan istilah fitur sebagai istilah umum yang meliputi properti dan operasi sebuah class. (Fowler 53)
.
Gambar 2.6 Class Diagram (Fowler 54)
2.2.3 Communication Diagram
Communication diagram adalah sejenis dengan diagram interaksi, yang lebih menekankan pada link data diantara bermacam-macam participant pada interaksi tersebut. (Munawar 143)
sebuah garis alir dan menunjukkan pesan-pesan dengan arah vertikal seperti yang dilakukan sequence diagram, tetapi memungkinkan untuk menempatkan partisipan-partisipan secara bebas, untuk menggambar hubungan-hubungan yang menunjukkan bagaimana partisipan berhubungan, dan menggunakan nomorisasi untuk menunjukkan bagian dari pesan-pesan. (Fowler 181)
Gambar 2.7 Communication Diagram (Fowler 182)
2.2.4 Component Diagram
Component diagram merepresentasikan dunia riil item yaitu component software. Component software menetap di komputer bukan di benak para analis. (Munawar 124)
Gunakan component diagram saat anda memecah sistem anda menjadi komponen-komponen dan ingin menampilkan hubungan-hubungan mereka dengan antarmuka atau pemecahan komponen menjadi struktur yang lebih rendah. (Fowler 191)
Gambar 2.8 Component Diagram (Fowler 190)
2.2.5 Composite Structure Diagram
Diagram composite structure adalah diagram untuk menunjukkan dekomposisi secara hirarkis sebuah class ke sebuah struktur internal. Hal ini memungkinkan untuk memecah obyek yang kompleks menjadi bagian-bagian kecil. (Munawar 148)
Composite structure merupakan hal baru dalam UML 2, meskipun metode-metode yang terdahulu juga memiliki beberapa ide yang sama. Cara terbaik untuk membedakan antara paket-paket dengan kelompok yang sedang berjalan. Karena itu, mereka sesuai untuk menunjukkan komponen dan bagaimana mereka dipecah menjadi bagian-bagian. (Fowler 187)
Gambar 2.9 Composite Structure Diagram (Fowler 186)
2.2.6 Deployment Diagram
Deployment diagram menunjukkan susunan fisik sebuah sistem, menunjukkan bagian perangkat lunak mana yang berjalan pada perangkat keras mana. (Fowler 137)
Deployment diagram menyediakan gambaran bagaimana sistem secara fisik akan terlihat. Sistem terdiri dari node-node dimana setiap node diwakili untuk sebuah kubus. (Munawar 127)
.
Gambar 2.10 Deployment Diagram (Fowler 138)
2.2.7 Interaction Overview Diagram
Interaction overview diagram merupakan hasil pencangkokan dari activity diagram dan sequence diagram. Anda dapat menganggap interaction overview diagram baik sebagai activity diagram dengan activity yang diganti sequence diagram, atau sebagai sebuah sequence diagram yang dipecah menggunakan notasi activity diagram yang menunjukkan aliran kontrol. (Fowler 197)
Gambar 2.11 Interaction Overview Diagram (Fowler 198)
2.2.8 Object Diagram
Object diagram merupakan gambaran tentang objek-objek dalam sebuah sistem pada satu titik waktu. Karena lebih menonjolkan perintah-perintah daripada class, object diagram lebih sering disebut sebagai diagram perintah. (Fowler 125)
Menurut Munawar (135), object diagram adalah gambaran obyek-obyek secara ringkas di sebuah sistem pada suatu waktu. Lebih lanjut Munawar (135) menambahkan, object diagram bisa digunakan untuk memodelkan pandangan dari rancangan atau proses yang statis dari suatu sistem. Termasuk disini adalah
pemodelan sistem secara ringkas pada suatu waktu dan membuat serangkaian obyek, state dan relasinya.
Gambar 2.12 Object Diagram (Fowler 126)
2.2.9 Package Diagram
Sebuah package adalah sebuah bentuk pengelompokan yang memungkinkan anda untuk mengambil setiap bentuk di UML dan mengelompokkan elemen-elemennya dalam tingkatan unit yang lebih tinggi. (Fowler 127)
Package diagram menunjukkan package-package dan saling ketergantungan diantara mereka. Saling ketergantungan diantara dua elemen ada jika perubahan pada satu elemen mengakibatkan perubahan pada elemen yang lain. (Munawar 131)
Package diagram sangat berguna pada sistem berskala besar untuk mendapatkan sebuah gambaran ketergantungan antar elemen-elemen besar dalam sistem. Diagram-diagram ini mendukung struktur pemrograman umum. Membuat
mengontrol ketergantungan sebuah aplikasi. (Fowler 135)
Gambar 2.13 Package Diagram (Fowler 131)
2.2.10 Sequence Diagram
Sebuah Sequence diagram, secara khusus, menjabarkan behavior sebuah skenario tunggal. Diagram tersebut menunjukkan sejumlah objek contoh dan pesan-pesan yang melewati objek-objek ini di dalam use case. (Fowler 81)
Sequence diagram digunakan untuk menggambarkan perilaku pada sebuah scenario. Diagram ini menunjukkan sejumlah contoh obyek dan message (pesan) yang diletakkan diantara obyek-obyek ini di dalam use case. (Munawar 87)
Gambar 2.14 Sequence Diagram (Fowler 85)
2.2.11 State Machine Diagram
State machine diagram adalah teknik yang umum digunakan untuk menggambar behavior sebuah sistem. Berbagai bentuk state diagram telah ada sejak tahun 1960-an dan teknik berorientasi objek yang paling awal mengadopsinya untuk menampilkan behavior. (Fowler 151)
State diagram bagus untuk menggambarkan behavior sebuah objek saat melewati beberapa use case. State diagram tidak terlalu bagus dalam menggambarkan behavior yang melibatkan sejumlah objek yang berkolaborasi. (Fowler 160)
Gambar 2.15 State Machine Diagram (Fowler 152)
2.2.12 Timing Diagram
Timing diagram merupakan bentuk lain interaction diagram, dimana fokusnya adalah batasan waktu untuk sebuah objek tunggal ataupun, menjadi lebih berguna, untuk sekelompok objek. (Fowler 199)
Timing diagram sangat penting guna menunjukkan factor pembatas waktu guna menunjukkan perubahan state pada obyek yang berbeda. Timing diagram ini bisa dipakai untuk obyek tunggal maupun kumpulan obyek. (Munawar 153)
Gambar 2.16 Timing Diagram (Fowler 200)
2.2.13 Use Case Diagram
Use case adalah teknik untuk merekam persyaratan fungsional sebuah sistem. Use case mendeskripsikan interaksi tipikal antara para pengguna sistem dengan sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana sistem tersebut digunakan. (Fowler 141).
Dan menurut Munawar (71), use case adalah konstruksi untuk mendeskripsikan bagaimana system akan terlihat di mata pengguna potential. Use case terdiri dari sekumpulan skenario yang dilakukan oleh seorang actor (orang, perangkat keras, urutan waktu atau system yang lain). Sedangkan use case diagram memfasilitasi komunikasi diantara analis dan pengguna serta diantara analis dan klien.
Gambar 2.17 Use Case Diagram (Fowler 147)
2.3 Visual Basic
Visual Basic adalah aplikasi pemrograman yang dikeluarkan oleh microsoft. Visual Basic pertama kali dirilis tahun 1991 dan terus menerus dikembangkan. Visual Basic versi 6.0 dirilis pada tahun 1998, versi ini adalah versi yang sangat banyak digemari oleh para programmer karena kemudahan dan kompatibilitasnya. Visual Basic 6.0 dirilis dalam 3 edisi, yaitu :
1. Standart Edition atau edisi dasar.
2. Profesional Edition yang berisi tambahan Microsoft Jet Data Access Engine dan pembuatan server OLE Automation.
3. Dan Enterprise Edition merupakan edisi yang diperuntukkan untuk pembuatan aplikasi client-server.
Visual Basic 6.0 memiliki antarmuka yang dapat disesuaikan dengan selera penggunanya, namun secara default memiliki antarmuka seperti pada gambar dibawah ini.
Gambar 2.18 Antarmuka visual basic Antarmuka Visual Basic 6.0 secara default terdiri dari:
1. Title Bar
Berfungsi menunjukkan nama proyek yang sedang dibuat. 2. Menu Bar
Berisi menu-menu utama yang dimiliki Visual Basic 6.0, misalnya menu File, Edit, View, Project, Run dan lain-lain. Pada masing-masing menu ini terdapat beberapa submenu lagi.
3. Main Toolbar
Adalah toolbar utama, berisi ikon-ikon yang dapat diklik oleh pengguna untuk melakukan suatu perintah secara cepat.
4. Form
Adalah tempat untuk merancang tampilan dari program aplikasi yang kita buat.
referensi cepat pada berbagai elemen yang terdapat pada sebuah proyek. Elemen dari sebuah proyek yang mungkin terdiri dari beberapa form, class, data report, module dan lainnya dapat dengan mudah 6. Properties Window
Jendela ini biasanya terletak dibawah jendela project explorer, jendela ini menampilkan berbagai karakteristik atau properti dari sebuah obyek yang dipilih. Form dan kontrol mempunyai properti baik yang terlihat langsung pada obyek seperti ukuran dan warna maupun tidak terlihat langsung seperti jeda waktu . Properti dari sebuah obyek akan dapat dilihat di jendela ini.
7. Form Layout Window
Berfungsi untuk melihat dan mengatur posisi form pada layar saat program dijalankan.
8. Toolbox
Toolbox berisi serangkaian kontrol yang dapat diletakkan pada form, kontrol ini nantinya digunakan untuk berinteraksi dengan pengguna. 9. Code Window
Adalah jendela yang digunakan untuk melihat atau mengetikkan kode program. Setiap form memiliki sebuah code window sendiri.
2.4 Port Paralel
Port paralel biasa juga disebut port printer terdiri dari tiga bagian yang masing-masing diberi nama sesuai dengan tugasnya dalam melaksanakan
pencetakan ke printer. Tiga bagian tersebut adalah Data Port (DP), Printer Control (PC) dan Printer Status (PS). DP digunakan untuk mengirimkan data yang harus dicetak, PC digunakan untuk mengirimkan kode-kode kontrol dari komputer ke printer, misalnya kode untuk menggulung kertas, dan PS digunakan untuk mengirimkan kode-kode status printer ke komputer, misalnya menginformasikan bahwa kertas telah habis. (Prasetia dan Catur 49)
Gambar 2.19 Port Paralel
Alamat umum dari port paralel LPT1 pada komputer adalah 888 (378h) dan LPT2 biasanya 632 (278h). Alamat tersebut adalah alamat yang umumnya digunakan, tergantung dari jenis komputer. Tepatnya kita bisa melihat pada peta memori tempat menyimpan alamat tersebut, yaitu memori 0000.0408h untuk base address LPT1 dan memori 0000.040Ah untuk base address LPT2.
masing-masing seperti yang dapat dilihat pada tabel dibawah ini:
Tabel 2.3. Konfigurasi pin dan nama sinyal konektor paralel standar DB-25 (Prasetia dan Catur 51)
Nomor Pin Nama Sinyal Arah Register Komplemen
1 Strobe In/Out Control bit 0 Ya
2 Data 0 Out Data bit 0
3 Data 1 Out Data bit 1
4 Data 2 Out Data bit 2
5 Data 3 Out Data bit 3
6 Data 4 Out Data bit 4
7 Data 5 Out Data bit 5
8 Data 6 Out Data bit 6
9 Data 7 Out Data bit 7
10 Ack In Status bit 6
11 Busy In Status bit 7
12 Paper-Out /
Paper-End In Status bit 5
13 Select In Status bit 4
14 Auto-Linefeed In/Out Control bit 1 Ya 15 Error / Fault In Status bit 3
16 Initialize In/Out Control bit 2 17 Select-Printer
/ Select-in In/Out Control bit 3 Ya
