BAB I PENGENALAN REKAYASA PERANGKAT LUNAK

Rekayasa Perangkat Lunak

BAB I PENGENALAN REKAYASA PERANGKAT LUNAK

1. Perangkat Lunak 1. Pengertian Perangkat Lunak Gambaran perangkat lunak pada sebuah buku teks mungkin mengambil bentuk berikut : (1) perintah (program komputer) yang bila dieksekusi memberikan fungsi dan unjuk kerja seperti yang diinginkan. (2) Struktur data yang memungkinkan program memanipulasi informasi secara proporsional, dan (3) dokumen yang menggambarkan operasi kegunaan program. 2. Karakteristik Perangkat Lunak Perangkat lunak lebih merupakan elemen logika dan bukan merupakan elemen fisik. Dengan demikian, perangkat lunak memiliki ciri yang berbeda dari perangkat keras. Ciri-ciri yang membedakan tersebut antara lain : 1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam bentuk yang klasik. Meskipun terdapat kesamaan antara pembuatan perangkat keras dan pengembangan perangkat lunak, yaitu kualitas yang tinggi bisa dicapai melalui perancangan yang baik, tetapi di dalam fase pembuatan perangkat keras selalu saja ditemukan masalah kualitas yang tidak mudah disesuaikan dengan perangkat lunak. 2. Perangkat lunak tidak pernah usang kematian segera

usang

Tingkat Kegagalan

Waktu

Gambar 1.1. Kurva Kegagalan Perangkat Keras Gambar 1.1 menggambarkan laju kegagalan sebagai fungsi waktu untuk perangkat keras, disebut ‘kurva bathtub”, menunjukkan bahwa perangkat keras mengalami laju kegagalan yang sangat tinggi pada awal hidupnya, yang disebabkan

1


oleh perancangan atau cacat pembuatannya. Setelah diperbaiki maka laju kegagalan menurun, kemudian naik lagi pada saat komponen perangkat keras terkena penumpukkan debu, getaran, suhu tinggi, serta pengaruh lingkungan yang lain. Secara singkat dapat dikatakan bahwa perangkat keras sudah mulai usang. Sedangkan perangkat lunak tidak rentan terhadap pengaruh lingkungan yang merusak dan menyebakan perangkat keras menjadi usang. Gambar 1.2 secara teoritis menggambarkan tingkat kegagalan perangkat lunak. Kesalahan-kesalahan yang tidak ditemukan akan menyebabkan tingkat kegagalan tinggi pada awal hidup program, tetapi itu dapat diperbaiki sehingga kurvanya menjadi datar. Secara singkat perangkat lunak tidak usang, meskipun pada kenyataannya semakin lama makin memburuk.

Pada tingkat yang sama sampai usang

Tingkat Kegagalan

Waktu

Gambar 1.2. Kurva Kegagalan Perangkat Lunak

Selama masa hidupnya, perangkat lunak mengalami perubahan (pemeliharaan). Sewaktu perubahan dibuat, kesalahan lain akan muncul yang menyebabkan kurva kegagalan naik secara cepat. Lihat Gamabr 1.3. Setelah semua kesalahan diperbaiki maka kurva akan menjadi normal kembali. Kemudian secara perlahan tingkat laju kesalahan minimum mulai naik – perangkat lunak mulai memburuk sehubungan perubahan yang dilakukan.

2


Gambar 1.3. Kurva Kegagalan Aktual Perangkat Lunak Aspek lain dari keusangan yang membedakan antara perangkat keras dan lunak adalah bila perangkat keras telah usang maka bisa diganti dengan suku cadangnya, tetapi tidak demikian dengan perangkat lunak. 3. Sebagian besar perangkat lunak dibuat secara custom-built, serta tidak dapat dirakit dari komponen yang sudah ada. Perhatikan bagaimana perangkat keras komputer dirancang dan dibuat. Pengembang desain menggambar skema sederhana dari rangkaina digital, melakukan serangkaian analisis dasar untuk memastikan bahwa fungsi yang tepat dapat dicapai serta kemudian menyesuaikan ke katalog komponen digital. Setiap IC (chip) mempunyai nomor tersendiri, sebuah fungsi yang telah tervalidasi, interface yang didefinisikan dengan baik, serta rangkaian standar tuntunan integrasi. Setelah masing-masing komponen diseleksi, perangkat keras bisa dipesan secara terpisah. Tidak demikian dengan pengembangan perangkat lunak, katalog komponen perangkat lunak tidak ada. Memang memungkinkan memesan perangkat lunak secara terpisah, tetapi tetap merupakan satu kesatuan yang lengkap, bukan sebagai komponen yang dapat dipasang ke dalam program-program yang baru.

3


3. Evolusi Perangkat Lunak. Pada awal tahun 1990-an Toffler menggambarkan adanya pergeseran kekuatan dimana struktur kekuatan lama (pemerintah, pendidikan, industri, dan militer) mengalami disintegrasi ketika komputer membawa ke arah demikratisasi pengetahuan. Sedangkan pada tahun 1992 Yourdon mengkawatirkan perusahaan-perusahaan Amerika akan kehilangan sisi kompetitif mereka di dalam bisnis yang berhubungan dengan perangkat lunak dan meramalkan penurunan serta jatuhnya para pemrogram Amerika. Tahun 1993 Hammer dan Champy berpendapat bahwa teknologi informasi akan memainkan peranan sentral dalam pengembangan kerjasama. Pada pertengahan tahun 1990 daya tembus komputer dan perangkat lunak menimbulkan banyak pendapat bahwa komputer menekankan sisi legitimasi tetapi mengabaikan keuntungan besar yang diperoleh. Perkembangan perangkat lunak bisa digambarkan pada Gambar 1.4. Pada masa awal era komputer, perangkat lunak dilihat hanya sebagai suatu permenungan. Pemrogram komputer menjadi sebuah seni “seat-of-pants” dimana di situ terdapat beberapa metode yang sistematis. Perkembangan perangkat lunak sebenarnya tidak bisa diatur sampai terjadi jadwal yang bergeser, atau biaya yang mulai melonjak. Para pemrogram kemudian berusaha untuk membuat semuanya benar kembali, dan dengan cara yang heroik akhirnya mereka berhasil. Pada masa itu perangkat lunak dirancang secara khusus untuk aplikasi tertentu saja dan hanya memiliki areal distribusi yang terbatas. Produk perangkat lunak yang dijual kepada pelangan atau masyarakat masih langka. Kebanyak dikembangkan dan digunakan oleh orang atau organisasi yang sama, dibuat untuk dipakai sendiri. Era kedua evolusi sistem komputer antar pertengahan tahun 1960 dan 1970-an. Sistem multiprogram dan multiuser memperkenalkan konsep baru interaksi manusia dan mesin. Teknik interaktif membuka sebuah dunia aplikasi yang baru serta tingkat kecanggihan perangkat lunak dan perangkat keras yang baru pula. Sistem real-time mampu melakukan pengontrolan dalam menghasilkan output tidak lagi dalam skala menit, melainkan detik. Kemajuan dalam penyimpanan on-line membawa ke generasi pertama sistem mamajemen database.

Pada era kedua ini juga ditandai dengan

kehadiran software-house. Produk perangkat lunak didistribusikan ke pasar yang lebih luas dan multidisiplin. Program mainframe dan minikomputer didistribusikan kepada

4


masyarakat luas. Pengusaha, pemerintah, industri, serta akademisi masing-masing mengembang-kan paket perangkat lunak paling mewah dengan mengeruk banyak uang.

Tahun-tahun

Era kedua

Era Ketiga

Era keempat

awal - Orientasi batch - Distribusi

- Multi user

- Realtime

terbatas - Perangkat lunak

- Database

kustomasi

- Sistem terdistribusi - embedded

- Sistem desk-top bertenaga kuat - Teknologi berorientasi

intelegence - Perangkat keras biaya rendah

- Perangkat

objek

- Sistem pakar

- Jaringan saraf tiruan

lunak produk

- Komputasi paralel - Komputer jaringan

1950

1960

1970

1980

1990

2000

Gambar 1.4. Evolusi Perangkat Lunak

Era ketiga evolusi sistem komputer dimulai pertengahan tahun 1970-an dan berlangsung lebih dari satu dekade penuh. Sistem terdistribusi dan multikomputer menambah kompleksitas sistem berbasis komputer. Jaringan area global dan lokal, jaringan komunikasi digital dengan bandwidh yang tinggi serta pertambahan permintaan untuk akses “sesaat” sangat mendongkrak perkembangan perangkat lunak. Era ketiga ini juga ditandai dengan kehadiran dan penyebaran pemakaian mikroprosesor, sehingga produkproduk pintar, seperti automobil, microwave, robot sampai peralatan kedokteran bisa dihasilkan. Yang paling penting pada era ini adalah munculnya komputer personal (PC = Personal Computer).

5


Evolusi sistem komputer era keempat menjauhkan kita dari komputer individual dan program komputer untuk menuju pengaruh kolektif dari komputer dan perangkat lunak. Mesin desktop yang kuat yang dikontrol oleh sistem operasi yang canggih, jaringan lokal dan global, serta didukung dengan aplikasi perangkat lunak yang maju, menjadi sebuah aturan. Arsitektur penghitungan berubah dari lingkungan mainframe yang terpusat ke lingkungan klien/server yang terdesentralisasi. Dan yang paling penting pada era ini adalah internet sudah dapat dilihat sebagai perangkat lunak yang dapat diakses oleh para pemakai individual. Tetapi selama era evolusi sistem berbasis komputer, serangkaian masalah yang berhubungan ddengan perangkat lunak masih muncul dengan intensitas yang terus bertambah, misalnya : 1. Kemajuan perangkat keras terus berlajut, melampaui perkembangan perangkat lunak yang sesuai dengan perangkat keras yang ada. 2. Kemampuan pengembangan perangakt lunak tidak cukup sepat untuk memenuhi kebutuhan bisnis dan pasar. 3. Pemakaian komputer yang semakin luas membuat masyarakat semakin tergantung pada perangkat lunak yang reliabel. 4. Sistem desain dan sumberdaya untuk mengembangkan perangkat lunak kurang memadai, sehingga masih sulit untuk dibagun perangkat lunak dengan reliabilitas dan kualitas yang tinggi.

4. Aplikasi Perangkat Lunak Perangkat lunak dapat diaplikasikan ke berbagai situasi dimana serangakaian langkah prosedural (seperti algoritma) telah didefinisikan. Kandungan (content) dan determinasi informasi merupakan faktor penting dalam menentukan sifat aplikasi perangkat lunak. Content mengarah pada arti dan bentuk informasi yang masuk dan keluar. Misalnya, banyak aplikasi bisnis memakai data input dengan struktur data lebih tinggi (misal database) dan mengahasilkan laporan yang sudah terformat. Perangkat lunak yang mengontrol mesin otomatis menerima bentuk data diskrit dengan struktur yang terbatas dan menghasulkan perintah mesin individual dalam ekskusi yang cepat. Sedangkan determinasi informasi merujuk pada predikbilitas urutan dan timing informasi.

6


Berikut beberapa jenis aplikasi perangkat lunak : a. Perangkat lunak sistem. Sekumpulan program untuk melayani program–program lain, misalnya sistem operasi, kompiler, editor, utilitas pengatur file, driver, prosesor telekomunikasi. b. Perangkat lunak real-time. Program-program untuk mengontrol/menganalisis/ memonitor kejadian dunia nyata pada saat terjadinya. Misalnya program untuk mengontrol mesin industri. c. Perangkat lunak bisnis. Program untuk pemrosesan informasi di dunia bisnis, mulai dari payroll, account payable, inventory, post system, sampai perangkat lunak sistem informasi manajemen yang bisa mengakses satu atau lebih database. d. Perangkat lunak teknik dan ilmu pengetahuan. Jangkauan aplikasinya meliputi, asmronomi, vulkanologi, kedokteran, analisis otomotif, biologi, mesin-mesin pabrik, sampai pada perangkat bantu dalam perancangan (computer aided design) untuk konstuksi bangunan, komponen elektronik, rancangan mesin, simulasi sitem, dan lain-lain. e. Embeded Software. Program yang disertakan dalam suatu perangkat dan berfungsi untuk mengontrol hasil serta sistem perangkat tersebut. Contoh : key pad control untuk microwave, fungsi digital pada automobil (pengontrol bahan bakar, penampilan dash board, sistem rem, dll). f. Perangkat lunak komputer personal. Program–program yang bisa dijalankan pada komputer personal. Contoh : pengolah kata, multimedia, hiburan, manajemen database, aplikasi keuangan bisnis, dll. g. Perangkat lunak kecerdasan buatan dan jaringan syaraf tiruan. Sistem pakar atau disebut juga sistem berbasis pengetahuan. Program yang digunakan untuk menggerakkan/mengontrol robot, permainan game, pengolah gambar dan pola (image dan voice).

7


2. Rekayasa Perangkat Lunak 1. Pengertian Rekayasa Perangkat Lunak Pada tahun 1969 Fritz Bauer memberikan definisi rekayasa perangkat lunak adalah sebagai berikut : “The establishment and use of sound engineering principles in order to obtain economically software that is reliable and work efficiently on real machines.” Hampir setiap pembaca tergoda untuk menambah sendiri definisi tersebut, karena definisi tersebut hanya menyinggung sedikit saja tentang aspek teknis dan kualitas perangkat lunak, dan tidak secara langsung menyinggung kebutuhan dan kepuasan pelanggan, pengabaikan pencamtuman pentingnya pengukuran dan matriks, tidak menyinggung pentingnya sebuah proses. Apakah sound enginnering aplication yang dapat diaplikasikan kepada pengembangan komputer? Bagaimana kita secara ekonomis membangun perangkat lunak sehingga menjadi dapat diandalkan dan reliable? Apakah yang dibutuhkan untuk menciptakan program komputer yang bekerja secara efisien pada lebih dari satu mesin riril yang berbeda? Pertanyaan-pertanyaan ini masih terus menjadi tantangan bagi pengembangan perangkat lunak. Pada tahun 1985 Richard Fairly mendefinisikan rekayasa perangkat lunak sebagai berikut : “The technological and managerial dicipline concernment with systematic production and maintenance of software products that are developed and modified on time and within cost estimates.” Definisi ini sudah menyinggung aspek teknis pengembangan perangkat lunak, pengelolaan tim yang terlibat dalam pengembangan tersebut, pemeliharaan perangkat lunak yang telah dikembangkan, serta waktu serta biaya pengem-bangan. Kemudian pada tahun 1993, IEEE mengembangkan definisi yang lebih komprehensif yaitu sebagai berikut : Rekayasa perangkat lunak adalah : (1) Aplikasi dari sebuah pendekatan kuantifiabel, disiplin, dan sistematis terhadap pengembangan, operasi, dan pemeliharaan perangkat lunak; yaitu aplikasi dan rekayasa perangkat lunak; (2) Studi tentang pendekatan-pendekatan tentang (1).

8


2. Lingkup Rekayasa Perangkat Lunak Lingkup rekayasa perangkat lunak bisa digambarkan seperti Gambar 1.5. Rekayasa perangkat lunak merupakan suatu kegiatan untuk menghasilkan suatu produk, sehingga harus berada pada satu komitmen dasar menuju kualitas. Untuk itu fokus kualitas menjadi batu landasanya. Lingkup kedua adalah proses. Proses-proses rekayasa perangkat lunak adalah perekat yang menjaga bentangan teknologi secara bersama-sama dan memungkinkan perkembangan perangkat lunak yang tepat waktu dan rasional. Proses-proses tersebut membatasi kerangka kerja untuk serangkaian area proses kunci yang harus dibangun demi keefektifan penyampaian teknologi pengembangan perangkat lunak. Area proses kunci ini membentuk dasar bagi kontrol manajemen proyek pengembangan perangkat lunak serta membangun kontek dimana metode teknis diaplikasikan sehingga sebuah produk yang berkualitas bisa dihasilkan.

perangkat bantu metodologi proses Fokus kualitas

Gambar 1.5. Lingkup Rekayasa Perangkat Lunak. Lingkup berikutnya adalah metodologi, yaitu sekumpulan metode untuk melaksanakan setiap tahap pengembangan perangkat lunak, yang meliputi : perencanaan dan estimasi proyek, analisa kebutuhan, prosedur algoritma dan arsitektur program, menulis program (coding), pengujian (testing), dan pemeli-haraan (maintenance). Terakhir adalah perangkat bantu (tools). Perangkat bantu yang dimaksus adalah suatu perangkat, baik lunak atau keras, otomatis maupun semi-otomatis yang bisa digunakan untuk proses pengembangan perangkat lunak. Tools untuk rekayasa perangkat lunak disebut computer-aided sofware engineering (CASE). CASE ini terus dikembangkan untuk menciptakan lingkungan rekayasa perangkat lunak sehingga analog dengan CAD/CAE (computer-aided design/engineering) pada pengembangan perangkat keras.

9


3. Paradigma Rekayasa Perangkat Lunak Untuk menyelesaikan masalah aktual didalam sebuah seting industri, rekayasa perangkat lunak atau tim perekaysa harus menggabungkan strategi pengembangan yang mencakup semua lingkup rekayasa perangkat lunak seperti yang digambarkan pada Gambar 1.5 tersebut . Strategi ini sering disebut paradigma atau model proses rekayasa perangkat lunak. Perkembangan perangkat lunak bisa dianggap sebagai lingkaran pemecahan masalah dimana terdapat empat keadaan berbeda, yaitu status quo, definisi masalah, perkembangan teknis pemecahan masalah, dan integrasi pemecahan menyampaikan hasil (dokumen, program, data, fungsi bisnis baru, produk baru) kepada yang membutuhkan hasil/produk tersebut. Lihat Gambar 1.6. Lingkaran pemecahan masalah tersebut digunakan pada tingkat makro ketika bagian dalam aplikasi dipakai; pada tingkat tengah ketika komponen program direkayasa; dan pada tingkat mikro ketika baris-baris kode ditulis. Masing-masing keadaan di dalam pemecahan masalah tersebut berisi lingkaran yang identik. Lihat Gambar 1.7. Tanpa memperdulikan model proses yang dipilih untuk suatu proyek rekayasa perangkat lunak, semua keadaan tersebut -- status quo, definisi masalah, perkembangan teknis pemecahan masalah, dan integrasi pemecahan – secara simultan hidup berdampingan pada beberapa tingkatan / tahapan detail. Dalam subbab ini akan dibahas beberapa model proses yang berbeda pada rekaya perangkat lunak. Definisi masalah

Pengembangan Teknis

Status Quo

Penyatuan Solusi

Gambar 1.6. Fase lingkaran pemecahan masalah

10


Definisi masalah

Status Quo

Pengembangan Teknis Penyatuan Solusi

Definisi masalah

Status Quo

Status Quo


Definisi masalah

Status Quo


Gambar 1.7. Fase-fase di dalam lingkaran pemecahan masalah

a. Siklus Hidup Klasik Paradigma siklus hidup klasik untuk rekayasa perangkat lunak diilustrasikan seperti pada Gambar 1.8. Disebut juga sebagai “model air terjun”. Beberapa kelebihan model ini adalah : 1) Titik awal dan titik akhir yang eksplisit 2) Setiap tahapan didefinisikan dengan jelas 3) Setiap akhir suatu tahap, disesuikan kembali dengan tahap sebelumnya, sehingga kesalahan yang mungkin terjadi bisa ditemukan dan diselesaikan lebih dini.

11


4) Incremental release, lingkup kerja untuk tahapan-tahapan berikutnya menjadi lebih kecil, dan tugas yang lebih mudah. Jika tahap awal dilakukan dengan benar maka akan mempermudah tahap berikutnya. Software Enginering Analysis Design Coding Testing Maintenance

Gambar 1.8. Paradigma Siklus Hidup Klasik : “Model Air Terjun” Aktivitas setiap tahapannya adalah : 1) System Engineering : Pengumpulan kebutuhan seluruh elemen sistem 2) Sofware Requirements Analysis : Pengumpulan kebutuhan dengan berfokus pada perangkat lunak, meliputi : domain informasi, fungsi, unjuk kerja, antar muka 3) Design, meliputi : Perancang struktur data, arsitektur perangkat lunak, rincian prosedural, karakteristik antar muka 4) Coding : penerjemah perancang ke bentuk yang dapat dimengerti oleh mesin 5) Testing, mencakup kegiatan : penguji lojikal, penguji fungsional, menemukan kesalahan dan memastikan suatu masukan diproses menjadi keluaran yang sesuai dengan yang diinginkan 6) Maintenance, bagian terujung dari siklus pengembangan dan dilakukan setelah perangkat lunak dipergunakan. Kegiatan adalah corrective maintenance, yaitu mengkoreksi kesalahan pada perangkat lunak, yang baru terdeteksi pada saat perangkat lunak dipergunakan

12


Model air terjun adalah paradigma rekayasa perangkat lunak yang paling luas dipakai dan paling tua. Tetapi kritik terhadap paradigma tersebut menyebabkan banyak pihak yang mempertanyakan kehandalannya. Masalah-masalah yang timbul ketika model tersebut diterapkan adalah : 1. Meskipun dalam prosesnya model ini bisa mengakomodasi iterasi, tetapi tidak dilakukan secara langsung, akibatnya perubahan-perubahan dapat menyebabkan keraguan pada saat tim proyek berjalan. 2. Kadang-kadang pelanggan sulit untuk menyatakan semua kebutuhannya secara eksplisit, sehingga sulit untuk mengakomodasi ketidakpastian tersebut. 3. Pelanggan harus bersikap sabar, karena masa pakai dari program tidak akan diperoleh sampai akhir waktu proyek berakhir. Akibatnya bisa saja terdapat kesalahan yang tidak tedeteksi sampai program tersebut tiba masanya untuk dikaji ulang. 4. Pengembang sering melakukan penundaan yang tidak perlu, karena seringnya beberapa anggota tim proyek harus menunggu anggota lain untuk melengkapi tugas yang saling ketergantungan.

b. Model Prototype Sering kali seorang pelanggan mendefinisikan serangkaian umum bagi perangkat lunak yang dibutuhkan, tetapi tidak mengidentifikasi kebutuhan output, pemrosesan, maupun input secara detail. Pada kasus lain, pengembang tidak memiliki kepastian terhadap efisiensi algoritma, kemampuan penyesuaian dari sebuah sistem operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi manusia dan mesin. Dalam hal ini, paradigma prototipe menawarkan pendekatan yang terbak. Paradigma ini dimulai dengan mengumpulkan kebutuhan. Pengembang dan pelanggan bertemu untuk mendefinisikan obyektif keseluruhan dari perangkat lunak. Kemudian dilakukan perancangan kilat yang berfokus pada penyajian dari aspek-aspek perangakt lunak yang akan nampak oleh pelanggan/pemakai (misal format input dan outputnya). Perancangan kilat tersebut membawa kepada konstruksi prototipe. Prototipe ini dievaluasi oleh pelanggan/pemakai dan dipakai untuk menyaring kebutuhan pengembangan perangkat lunak yang dibutuhkan. Iterasi terjadi pada saat prototipe

13


disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang sama memungkinkan pengembang untuk secara lebih baik memahami apa yang harus dilakukan. Prototipe bisa berfungsi sebagai “sistem awal”. Tetapi pada beberapa proyek yang dibangun dengan prototipe, saat penggunaan pertama sistem awal yang baru dibangun tersebut, mungkin akan terasa terlalu pelan, terlalu besar, janggal dalam pemakaian, atau bahkan tiga hal tersebut semua terjadi. Jika terjadi demikian maka tidak ada pilihan lain kecuali memulai lagi untuk membangun versi yang baru dimana masalah yang muncul bisa diselesaikan.

c. Model RAD (Rapid Aplication Development). RAD adalah merupakan model proses pengembangan perangkat lunak adaptasi kecepatan tinggi dari model sekuensial linier yang menekankan siklus perkembangan yang sangat pendek. Perjalanan pengembangannya sangat cepat dengan menggunakan pendekatan konstruksi berbasis komponen, yang memungkinkan tim pengembang bisa menciptakan sistem fungsional secara utuh dalam waktu 60 s.d. 90 hari. Pada umumnya digunakan pada aplikasi sistem konstruksi. Pendekatan RAD melingkupi fase-fase sebagai berikut : 1) Businnes modelling. Pemodelan dari aliran informasi diantara fungsi-fungsi bisnis. 2) Data modelling. Mengidentifikasi serangkaian objek data yang dibutuhkan dan karakteristik masing-masing objek tersebut, serta mendefinisikan hubungan antara objek-objek tersebut. 3) Proses modelling. Mentransformasikan hasil data modelling untuk mencapai aliran informasi yang perlu bagi implementasi fungsi-fungsi prosesnya. Gambaran proses dibuat untuk menambah, memodifikasi, menghapus, atau mendapatkan kembali sebuah objek data. 4) Aplication generation. RAD mengasumsikan pemakaian teknik generasi keempat (4GL), lebih banyak memakai komponen program yang sudah ada, juga menciptakan komponen yang bisa dipakai lagi. 5) Testing and turnover. Karena proses RAD menekankan pada pemakaian kembali, maka setiap komponen baru harus diuji untuk mengurangi keseluruhan waktu pengujian

14


Kelemahan model RAD : 1) Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber daya manusi yang memadai untuk menciptakan jumlah tim RAD yang baik. 2) RAD menuntut pengembang dan pelanggan memiliki komitmen tinggi di dalam aktivitas pengembangan. Tim #3 Pemodelan

bisnis

Tim #2

Pemodelan

Pemodelan bisnis

Tim #1

data Pemodelan data

Pemodelan bisnis

Pemodelan

Proses Pembentukan

Pemodelan Proses

Pemodelan data

aplikasi Pengujian

Pembentukan aplikasi

Pemodelan Proses

& turnover

Pengujian & turnover

Pembentukan aplikasi Pengujian & turnover

Gambar 1.9. Model RAD

Disamping tiga model di atas, masih banyak lagi model proses rekayasa perangkat lunak yang lain, yaitu : 1) Model Proses Rekayasa Perangkat Lunak Evolusioner, antara lain : a) Model Pertambahan b) Model Spiral c) Model Rakitan Komponen d) Model Perkembangan Konkuren

15


2) Model Formal 3) Teknik Generasi Keempat (4GL) Model-model itu bisa anda baca di buku “Software Engineering” yang ditulis oleh Rogers. Pressman, PhD.

3. Rekayasa Sistem Komputer Dengan melihat definisi dari Webster’s, kita mendefinisikan sistem berbasis komputer sebagai: “serangkaian atau tatanan elemen-elemen yang diatur untuk mencapai tujuan yang ditentukan sebelumnya melalui pemrosesan informasi” Tujuannya adalah untuk mendukung berbagai fungsi bisnis atau untuk mengembangkan suatu produk yang dapat dijual untuk menghasilkan keuntungan bisnis. Untuk mencapai tujuan tersebut, sistem berbasis komputer menggunakan berbagai elemen sistem: a) Perangkat lunak, program komputer, struktur data, dan dokumen yang berhubungan yang berfungsi untuk mempengaruhi metode logis, prosedur, dan kontrolyang dibutuhkan. b) Perangkat

keras,

perangkat

elektronik

yang

memberikan

kemampuan

penghitungan, dan perangkat elektromekanik (misalnya: sensor, rotor, pompa)yang memberikan fungsi dunia eksternal. c) Manusia, pemakai dan operator perangkat lunak dan perangkat keras. d) Database, kumpulan informasi yang besar dan terorganisasi yang diakses melalui perangkat lunak. e) Dokumentasi, manual, formulir, dan informasi deskriptif lainnya yang menggambarkan penggunaan dan pengoprasian sistem. f) Prosedur, langkah-langkah yang menentukan penggunaan khusus dari masing elemen sistem atau konteks prosedural dimana sistem berada. Satu karakteristik sistem berbasis komputer yang rumit adalah bahwa elemen yang berisi satu sistem juga dapat mewakili satu elemen makro dari suatu sistem yang sangat besar. Elemen makro adalah suatu sistem berbasis komputer yang merupakan bagian dari sistem berbasis komputer yang lebih besar lagi. Peran rekayasa sistem adalah membatasi elemen-elemenuntuk sistem berbasis komputer tertentu dalam konteks keseluruhan hirarki sistem (elemen makro). Berikut adalah tugas-tugas yang merupakan rekayasa sistem komputer: 16


Sistem Otomasi Pabrik

Sistem Pemanufakturan

Sistem Inventori

Sistem Aliran Material

Sel pemenufakturan

Mesin NC

Robot

Perangkat Entry Data

Gambar 1.10. Sistem dari banyak sistem

17

Sistem Informasi


BAB II DASAR ANALISIS KEBUTUHAN

2.1. Lingkup Analisis a) Pengenalan Permasalahan b) Evalusi dan Sintesis c) Pemodelan d) Spesifikasi e) Peninjauan Ulang Perancangan

Analisis

Apa ?

Bagaimana ?

Gambar 2.1 Hubungan Antara Analisis dan Perancangan Dalam menemukan area permasalahan, perlu adanya komunikasi yang intensif dengan user. Hal yang perlu diperhatikan dalam berkomunikasi adalah menghindari salah interpretasi. Pertanyaan pertama memfokuskan pada pengertian dasar permasalahan : 1. Menemukan yang membutuhkan software tersebut : a. Siapa yang membutuhkan sistem (serta personal di belakangnya?) b. Siapa yang akan menggunakan solusi c. Apa yang akan menjadi keuntungan ekonomis dari solusi yang baik d. Adakah sumber lain dari solusi yang dibutuhkan 2. Bentuk solusi yang diinginkan a. Bagaimana user mengkarakteristikkan suatu output sistem yang baik yang akan dihasilkan oleh solusi yang benar b. Masalah-masalah apa yang akan dicarikan solusinya? c. Lingkungan solusi yang akan digunakan d. Adakah isukah isu atau kendala khusus yang berdampak kepada solusi 3. Efektifitas a. Mendapatkan person yang benar/berhak atas jawaban pertanyaan, b. Apakah pertanyaan yang diajukan relevan dengan permasalahan c. Adakah personal lain yang dapat menambah informasi 18


d. Adakah hal lain yang perlu ditambahkan? Jenis Kebutuhan: 1) Kebutuhan Fungsional Pendefinisian layanan yang harus disediakan, bagaimana reaksi sistem terhadap input dan apa yang harus dilakukan sistem pada situasi khusus (Kebutuhan sistem dilihat dari kacamata pengguna) 2) Kebutuhan Non-Fungsional Kendala pada pelayanan atau fungsi sistem seperti kendala waktu, kendala proses pengembangan, standard, dll. Contoh: kehandalan, waktu respon dan kebutuhan storage. Contoh kendala seperti: Keterbatasan kemampuan peralatan I/O, representasi sistem dll. 2.2. Sistem Analis a) Dituntut untuk dapat memiliki Kemampuan : a. Pemimpin Proyek b. Mediator c. Inovator d. Arkeolog b) Nama Lain : System Engineer, Chief System Designer, Programmer/Analyst dsb

Clien t

Pengem bang Konsultan/Specifi er

Gambar 2.2 Cara Kerja Sistem Analis

(Perancang Senior)

c) Prinsip-Prinsip Analisis :

a. Domain Informasi dari masalah harus dapat direpresentasikan dan mudah dimengerti b. Harus ada model yg dpt mengambarkan fungsi dan perilaku sistem c. Model dan masalah harus dapat dibuat bertingkat (dipartisi) perinciannya

19


d. Proses Analisis harus berpindah dari informasi dasar ke perincian implementasi

2.3. Domain Information Tirdiri dari 3 pandangan : Information Flow, Information Content, dan Information Sructure a) Information Flow mempresentasikan bagaimana data dan kontrol berubah dalam perjalananannya melalui sistem b) Information Content merepresentasikan item-item individual dari data dan kontrol yang lebih besar c) Information Structure merepresentasikan organisasi internal dari item-item data kontrol

Output

Input

information

information Intermediate information

Transfrom 2

Transform 1

Data Store

Gambar 2.3 Struktur Informasi

2.4. Pemodelan Harus dapat memodelkan informasi yang diolah oleh perangkat lunak, fungsi dan sub fungsi yang memungkinkan pengolahan dan perilaku sistem ketika pengolahan dilakukan. Dapat berupa notasi grafis atau tekstual. 1. Peranan Model : a) Membantu analisis dalam pemahaman informasi fungsi dan dan prilaku sistem sehingga aktivtas analisis kebutuhan menjadi lebih mudah dan lebih sistematis

20


b) Merupakan poin kritis untuk peninjauan ulang yang penting untuk kelengkapan, konsistensi dan ketetapan dari spesifikasi c) Merupakan dasar untuk tahap perancangan dengan menyediakan kepada perancang representasi dasar perangkat yang dapat dipetakan ke dalam konteks implementasi. 2. Pembagian a) Berguna untuk penyederhanan b) Proses pembagian a. pembagian vertikal untuk memperinci fungsi b. pembagian horisontal untuk dekomposisi fungsi

2.5. Informasi Dasar dan Implementasi Informasi Dasar merepresentasikan fungsi yang ingin dicapai dan informasi yang akan diproses dengan mengabaikan perincian implementasi. Perincian implementasi merepresentasikan manifestasi dunia nyata dari fungsi pemrosesan dan struktur informasi 1. Kebutuhan Perangkat Lunak Dapat dinyatakan dalam berbagai bentuk : a) Gambar di atas kertas b) Gambar di komputer ( dengan CASE Tool) c) Prototype d) Bahasa spesifikasi formal

2. Spesifikasi a) Merupakan

proses

representasi

dari

kebutuhan

sistem

untuk

suksesnya

implementasi perangkat lunak b) Balzer dan Goldman memberikan 8 prinsip spesifikasi yang bagus, yaitu : a. pisahkan fungsionalitas dari implementasi. Pusatkan pada ‘apa’ bukan ‘bagaimana’ b. dibutuhkan bhs spesifikasi sistem yang berorientasi pada proses c. spesifikasi harus mencakup sistem dimana perangkat lunak adalah salah satu komponen

21


d. spesifikasi harus meliputi lingkungan dimana sistem beroperasi e. spesifikasi sistem merupakan model kognitif f. spesifikasi harus dapat dioperasionalkan g. spesifikasi sistem harus toleran terhadap ketidaklengkapan dan penambahan h. spesifikasi harus terlokalisasi dan loosely coupled.

22


BAB III ANALISA TERSTRUKTUR

3.1. Sejarah Analisa Terstruktur 1

Dipopularkan oleh DeMarco (1979)

2

Dikembangkan lebih lanjut oleh Page-Jones (1980), Gane dan Sarson (1982)

3

Dikembangkan untuk sistem waktu nyata (Real Time) oleh Ward dan Mellor (1985) kemudian Hatley dan Pirbhai (1987)

4

Merupakan teknik pemodelan information flow dan information content

3.2. Data Flow Diagram (DFD) DFD atau yang sering disebut juga Bubble Chart, Bubble Diagram, model proses, diagram alur kerja, atau model fungsi, merupakan suatu diagram yang menggambarkan aliran data dalam sebuah sistem. Komponen DFD terbagi menjadi 4: 1) Terminator atau External Entity External Entity adalah lingkungan luar dari sistem tetapi dia memiliki pengaruh terhadap sistem. External Entity bisa digambarkan sebagai individu, kelompok, atau sistem lain (bukan orang). Notasi :

Konsumen

2) Proses Proses berfungsi untuk mentransformasikan data secara umum. Karena proses melakukan pekerjaan, maka dalam menamai sebuah proses dimulai dengan kata kerja dan diikuti objek. Suatu proses harus memiliki input dan output. Suatu proses juga dapat dihubungkan dengan komponen External Entity, Data Store, atau Proses lain melalui Aliran Data.

23


Notasi :

1

1 Periksa Pesanan

Periksa Pesanan

Model DeMarco/Yourdon

Model Gane & Sarson

3) Data Store Data Store berfungsi menyimpan data/ file. Data store biasanya berkaitan dengan penyimpanan-penyimpanan secara komputasi, contoh: harddisk, disket, dvd disc, namun bisa juga berupa seperti buku, alamat, agenda. Data Store hanya dapat dihubungkan dengan komponen Proses melalui Alur Data, tidak dengan komponen DFD lain. Notasi :

Pesanan

Pesanan

Model DeMarco/Yourdon

Model Gane & Sarson

4) Alur Data Alur Data menggambarkan aliran data dari suatu proses ke proses lainnya. Alur Data dapat merepresentasikan data/informasi yang berkaitan dengan komputer seperti bit, bilangan real, karakter, maupun yang tidak seperti nama, nim, alamat. Notasi : Pesanan_barang

Diagram aliran data (DFD) memungkinkan perekayasa perangkat lunak untuk mengembangkan model domain informasi dan domain fungsional pada saat yang sama. Pada saat DFD disaring kedalam tingkah detail yang lebih tinggi, analis melakukan suatu dekomposisi fungsional implisit dari sistem, sehingga memenuhi prinsip analisis

24


operasional keempat. Pada saat yang sama, penyaringan DFD menghasilkan suatu penyaringan yang sesuai dari data pada saat dia bergerak melalui proses yang membentuk aplikasi. Beberapa tuntunan sederhana dengan tak terukur dapat membantu selama derivasi sebuah diagram alir data: 1) Diagram aliran data tingkat 0 (Nol) harus menggambarkan perangkat lunak/sistem sebagai gelembung tunggal. 2) Input dan output utama harus dicatat secara hati-hati. 3) Penyaringan harus dimulai dengan mengisolasi proses calon, objek data, dan penyimpanan yang akan direpresentasikan pada tingkat selanjutnya. 4) Semua anak panah dan gelembung harus diberi label dengan nama yang berarti. 5) Satu gelembung pada suatu saat harus disaring.

Diagram Aliran Data Bertingkat 1. Dasar Pemikiran a) ROSS Pikiran manusia dapat menerima segala bentuk kerumitan, asalkan disajikan dalam susunan yang terdiri bagian-bagian kecil yang mudah dimengerti b) GEORGE MILLER Pikiran manusia paling banyak dapat mengerti sesuatu yang terbagi menjadi 7 + 2 bagian dan tetap masih dapat mengerti konsep dari sesuatu tadi secara keseluruhan .

2. Jenis DAD dalam DAD Bertingkat a) Diagram konteks ( Context Diagram ): Diagram paling atas, terdiri dari satu proses dan mengambarkan ruang lingkup sisrtem. b) Diagram Prinsif Fungsional ( Functional Primitive ): Diagram-diagram paling bawah, yang tidak dapat dibagi lagi atau memiliki masukan tunggal dan keluaran tunggal atau telah sangat sederhana ( narasi untuk deskripsi dapat dituliskan secara singkat ). c) Diagran tengah: Diagram-diagram yang terletak antara Diagram Konteks dan Primitif Fungsional.

25


3. Penyusunan DAD a. Penomoran a) Diagram konteks biasanya diberi nomor 0 b) Proses-proses pada DAD paling atas diberi nomor mulai dari 1 dan seterusnya sampai semua proses bernomor c) Pada saat setiap proses dipecah menjadi DAD dengan tingkat yang lebih rendah, maka proses pada DAD tersebut diberi nomor sesuai dengan nomor proses tadi d) Setiap proses diberi nomor yang merupakan kombinasi dari nomor diagram diikuti dengan nomor urut dalam tingkay yang bersangkutan.

b. Bentuk Umum Diagram Konteks :

TI

R O T3

SISTEM T2

S Gambar 2.5 Bentuk umum diagram konteks a) Nomor Diagram “ ANAK” harus diawali dengan nomor proses pada diagram ‘ ORANG TUA “ yang terkait,

Diagram 0

Diagram 3 X

1

X

3.1

Z

A AAA

R

A

3

S

2 Y

Y

3.2

3.3 B

Gambar 2.6 Penomoran diagram konteks

26

Z


b) Dengan menyebutkan nomor diagram “ANAK “ yang sesuai dengan nomor proses diagram pada diagram “ ORANG TUA ‘ yang terkait . Nomor proses pada diagram ‘ ANAK “ boleh tidak diawali dengan nomor proses diagram ‘ ORANG TUA ‘ c) Aturan Keseimbangan ( Balancing ) Semua aliran data yang masuk dan keluar diagram “ ORANG TUA’ harus ada/sama pada diagram ‘ ANAK’

Diagram 0

Diagram 3 X

1

X

.1

Z

A AAA A

R

3

S

2

Y

Y

.2

.3

Z

B Gambar 2.7 Balancing DFD

4. Kamus Data Sebuah daftar terorganisasi dari komposisi setiap elemen data, aliran data, dan penyimpanan data yang digunakan dalam sebuah DAD, serta spesifikasi lojik dari proses juga modul dan dekripsi modul dari Bagan Susunan dari daftar dari Entitas dan Relasi yang digunakan didalam Diagram E-R Nama lain : Requirements Dictionary, Data Dictionary, Encylopedia. Mengapa diperlukan ? Karena adanya kebutuhan untuk mendifinisikan isi dari : a) Aliran Data ( DAD ) b) Penyimpanan Data c) Proses ( DAD ) d) Entitas ( ERD ) e) Relasi (ERD)

27


5. Notasi Kamus Data Tabel 2.1 Simbol notasi kamus data SIMBOL

ARTI

=

Terdiri dari

+

Dan

{}

Iterasi

[]

Pilihan salah Satu

()

Boleh ada, boleh tidak

* *

Komentar

Contoh Kamus Data a) Data : Nomor Telepon Name aliases where used/low used

: telephon number : none : access against set-up (output) dial phone (input)

description : Telephone number = [ lokal extension | outside number ] Lokal extension = [ 2001 | 2002 | …..| 2999 ] Outside number = 9 + [ local number | long distance number ] Local number = prefix + access number Long distance number = ( 1 ) + area code + local number Prefix = [ 795 | 799 | 874 | 877 ] Access number = *any four number strings “

28


b) Arus Data : Surat Pengeluaran Barang Nama Arus

: Sales Order

Alias

: SO

Bentuk Data

: Cetakan komputer

Arus Data

: Pelanggan – Proses pemesanan barang Proses pemesanan – Data Store

Penjelasan

: Untuk mencatat pemesanan barang

Periode

: Setiap ada pesanan

Volume

: Rata – rata tiap hari adalah 35

Struktur Data <Surat Pesanan Barang> = HEADER + ISI + FOOTER HEADER = No_SO + Tanggal + Tgl-PO + No PO Costumer + Nama_Pelanggan + Alamat + Telp - No_SO

: * Terdiri dari lima belas digit *

- Tanggal

: Tanggal + Bulan + Tahun

- Nama_Plangan

: (Titel) + Nama_depan + Nama_belakang

- Alamat

: Jalan + Nomor + Kota

- Telepon

: * Maksimal 14 digit *

ISI = 1 {KD_Item + Item + Nama_Barang + Satuan + Quantity + Harga/Unit Disc (%) + Jumlah} 20 - item

: * Nomor urut *

- Nama Barang

: * Jenis barang yang dipesan *

- Satuan

: * Maximal tiga digit *

- Harga/unit

: * Dalam Rupiah *

-Quantity

: * Dihitung dari unit dikali harga satuan dikurangi discount *

FOOTER = Total - Total

: * Total semua penjualan *

3.3. Entity Relationship Diagram (ERD) Komponen dari ERD ada 6 yaitu 1) Entitas (Entity)

29

+


Entitas adalah suatu objek yang dapat dibedakan dari objek lain. Suatu entitas haruslah bersifat fakta. Entitas dapat berupa fisik, contoh: Mobil, Rumah, Gedung, dan dapat berupa konsep, contoh: Pekerjaan, Perusahaan. 2) Atribut (Attribute) Atribut merupakan properti yang dimiliki setiap entitas yang datanya akan disimpan. Contoh : atribut MAHASISWA -> NIM, Nama, Alamat. 3) Relasi(Relationship) Asosiasi antara satu atau lebih entitas. Berupa kata kerja. 4) Kardinalitas (Cardinality)

Gambar 3.1 Kardinalitas 5) Kardinalitas menunjukkan banyaknya objek yang terlibat dengan objek lain pada suatu relasi. Ada 3 kombinasi yang mungkin terjadi, diantaranya : 1:1 (One to One), 1:N (One to Many), dan N:M (Many to Many). 6) Modalitas (Modality) Partisipasi sebuah entitas pada suatu relasi. 0 berarti partisipasi parsial. 1 berarti partisipasi total. Diagram hubungan entitas memungkinkan seorang perekayasa perangkat lunak untuk secara penuh menspesifikasikan objek data yang merupakan input dan output dari sistem, atribut yang mendefinisikan sifat dari objek tersebut, dan hubungan antar objek. Seperti kebanyakan model analisis elemen, ERD dikonstruksi didalam cara yang iteratif. Pendekatan berikut ini diambil: 1) Selama pengumpulan persyaratan, pelanggan diminta untuk mendaftar “hal-hal” yang akan ditujuoleh proses bisnis dan aplikasi. “hal-hal” ini dimasukan kedalam sebuah daftar objek data input dan output dan entitas eksternal yang menghasilkan atau mengkonsumsi informasi.

30


2) Dengan mengambil objek satu pada satu saat, analis dan pelanggan mendefinisikan apakiah ada sambungan (tidak diberi nama pada tahap ini) ada diantara objek data dan objek lain. 3) Dimanapun sambungan ada, analis dan pelanggan menciptakan satu pasangan hubungan objek atau lebih. 4) Untuk masing-masing pasangan hubungan objek, dicari kardinalitas dan modalitas. 5) Langkah 2 sampai 4 dilanjutkan secara iteratif sampai semua pasangan hubungan objek sudah dudefinisikan. Sudah menjadi kebiasaan untuk menemukan penghilangan pada saat proses ini berlanjut. Objek dan hubungan baru akan ditambahkan pada saat jumlah iterasi bertambah. 6) Atribut dari masing-masing entitas didefinisikan. 7) Diagram hubungan entitas diformulasikan dan dikaji. 8) Langkah 1 sampai 7 diulang sampai pemodelan data terlengkapi.

3.4. State Transition Diagram (STD) STD merupakan diagram yang memodelkan tingkah laku (behaviour) sistem berdasarkan pada definisi satu bagian dari keadaan sistem. STD sering dipakai untuk menggambarkan kinerja sistem. Komponen STD dibagi menjadi 4 :

a. State State merupakan kondisi dari suatu sistem. State dapat dikategorikan menjadi 2 macam, yaitu : State Awal dan State Akhir. State Awal hanya boleh berjumlah 1 state, dan State Akhir boleh memiliki jumlah lebih dari satu state. b. State Change (Tanda Panah) Menyatakan perubahan state dari sistem. c. Kondisi Kondisi menyatakan suatu kejadian pada lingkungan eksternal yang dapat dideteksi oleh sistem, contoh: sinyal.

31


d. Aksi sistem melakukan sesuatu sehingga terjadi perubahan state atau merupakan suatu reaksi terhadap kondisi.

32


BAB IV ANALISA DAN PERANCANGAN BERORIENTASI OBJEK

4.1. Konsep Umum Metodologi Berorientasi Objek Ada beberapa tema yang mendasari teknologi berorientasi objek. Meski tema-tema ini tidak unik pada sistem berorientasi objek, mereka sangat didukung pada metoda analisis, perancangan serta implementasi dengan metodologi berorientasi objek. Tematema object oriented: 1. Kelas Kelas membungkus (encapsulating) objek-objek. Suatu kelas tunggal dapat digunakan untuk menciptakansejumlah objek-objek. Selain itu, suatu kelas juga dapat digunakan untuk menciptakan kelas-kelas lain yang mewarisi (inheritance) sebagian atau seluruh data serta fungsi yang dimiliki oleh kelas yang disebutkan terdahulu. 2. Abstraksi Abstraksi adalah menemukan hal-hal yang esensial pada suatu objek dan mengabaikan hal-hal yang sifatnya insidental. Maksudnya adalah menangkap sesuatu yang berarti untuk dituangkan sistem/perangkat lunak alih-alih menangkap seluruh fakta yang ada. Penggunaan konsep abstraksi selama analisis berarti “jangan pernah melakukan perancangan dan implementasi sebelum persoalan benar-benar dipahami”. 3. Pembungkusan (Encapsulation) dan Pengiriman Pesan (Message Passing) Pembungkusan berarti meninggalkan aspek eksternal dari objek yang dapat dimasuk (diakses) oleh objek lain dan memfokuskan diri pada implementasi internal suatu objek. Keuntungan pembungkusan adalah kita dapat mengharapkan suatu objek melakukan metoda apa yang kita inginkan tanpa harus tahu bagaimana objek itu melakukannya. Kita ibaratkan suatu objek dengan televisi. Kita tidak perlu tahu bagaimana televisi melakukan suatu tugas tertentu, misalnya menayangkan gambar tertentu, yang perlu kita ketahui adalahtombol mana pada remote control yang harus ditekan, kemudian televisi akan berfungs. Penekanan tombol pada remote control mengirim pesan tertentu ( baca Message) pada televisi,

33


memberitahu metode apa yang akan dilakukan (pindah saluran,mengeraskan suara, meningkatkan intensitas warna tertentu dan sebagainya). 4. Generalisasi dan Polimorfisme Generalisasi memungkinkan kelas-kelas berbagi data serta perilaku yang sama. Pada konteks pemrograman ini memungkinkan penguranganukuran kode dan menyediakan kemungkinan pengembangan sistem/perangkat lunak yang lebih mudah dipelihara. Polimorfisme mengijinkan penyesuaian berbagai kode untuk memenuhi keadaan tertentu. 5. Penggabungan Data (Atribut) dan Perilaku (Fungsi) 6. Sharing 7. Penekanan pada struktur objek, bukan pada struktur prosedur Teknologi berorientasi objek menekankan pada apa itu objek, bukan pada bagaimana objek itu digunakan. 8. Sinergis Identitas, klasifikasi, polimorfisme serta pewarisan adalah karakteristik utama dari bahasa pemrograman berorientasi objek.

4.2. Konsep Dasar Analisis Berorientasi Objek

Kelas : Mebel

Obyek inheritan pada semua atributnya kelas

Harga Dimensi Berat Lokasi Warna

Obyek : Kursi Harga Dimensi Berat

Lokasi Warna

Gambar 4.1 Konsep dasar analisis berorientasi objek

34


Konsep Dasar: Object merupakan Entitas yang memiliki data yang menyatakan kondisi pada suatu saat, dan sekumpulan operasi yang dapat mengakses dan mengubah kondisi tersebut. Object, dapat berupa: a. External Entities: sistem lain, alat atau orang yang memberi atau memakai informasi yang digunakan oleh sistem b. Things: laporan tampilan, sinyal yang merupakan bagian dan domain informasi dari masalah. c. Events or occurences: selesainya gerak robot. d. Roles: manajer, staf teknik, staf pemasaran yang berperan sebagai orang berinteraksi dengan sistem. e. Unit organisasi: divisi, kelompok. Tim yang berhubungan dengan sistem.

4.3. Analisis Berorientasi Objek Analisis berorientasi objek (OOA- Object Oriented Analysis) adalah tahapan perangkat lunak dengan menentukan spesifikasi sistem dan mengidentifikasi kelas-kelas serta hubungannya satu terhadap yang lain. Ivar Jaobson (dikutif dari buku Object Oriented System Development tulisan Ali Bahrawi, 1999) memperkenalkan konsep use case sebagai skenario untuk mrnjelaskan interaksi pengguna dengan sistem

Analisis berorientasi objek memiliki 5 (lima) aktivitas: 1. Finding Class & Objects 2. Identifying Structures 3. Identifying Subjects 4. Defining Attributes 5. Defining Service

Ada 5 (lima) lapisan dalam analisis berorintasi objek: 1. Subject layer 2. Class & Onject layer 3. Structure layer

35


4. Attribute layer 5. Service layer Identifikasi struktur dalam analisis berorientasi objek 1. Generalization Specialialization. (Gen-Spec) Structure dapat dianggap sebagai ‘is a’ atau ‘is a kind of’.

2. Whole Part Struktur dapat dianggap sebagai ‘has a’

Whole Part a) Sebuah pesawat merupakan assembly dari 0-4 mesin. Dan sebuah mesin merupakan bagian dari 0-1 pesawat Pesawat 04

0-1

Mesin

b) Sebuah organisasi merupakan kumpulan dari 0-n staf. Dan seorang staf merupakan bagian dari tepat 1 organisasi Organisasi 0-n

1

Staf

36


4.3.1. Subject a. Masalah yang besar sebaiknya dibagi-bagi dalam lingkup masalah yang lebih kecil lagi. b. Begitu pula dalam OO, kelas-kelas yang ada dapat di kumpulkan dalam satu domain masalah tertentu. c. Notasi : 1. Subject

1

1

1

1

1

1

4.3.2. Hubungan antar Kelas 2 jenis hubungan antar kelas a) Intance Connection merupakan suatu hubungan antar objek, dimana suatu objek membutuhkan objek lain untuk memenuhi tanggung jawabnya. b) Message Connection memodelkan suatu ketergantungan objek. Dimana suatu objek membutuhkan suatu service darri objek lain (biasanya dari class yang beda) untuk memenuhi tanggung jawabnya.

4.4. Perancangan Berorientasi Objek Ada 4 aktivitas dalam perancangan berorientasi objek yaitu 1. Designing the Problem Domain Component 2. Designing the Human Interaction Component 3. Designing the Task Management Component

4. Designing the Data MC Ada 4 komponen dalam perancangan berorientasi objek yaitu 1. Problem Domain Component (PDC) 2. Human Interaction Component (HIC) 3. Task Management Component (TMC) 4. Data Management Component (DMC)

37


Managemant Component terdiri dari: Subject Class & Object Structure Attribute Service Gambar 4.2 Management component Bahasa Pemprograman Berorientasi Objek (C++) 1. Dikembangkan oleh AT&T Bell Lab. 2. Merupakan evolusi dari bahasa C. 3. Merupakan superset dari bahasa C. 4. Dikembangkan untuk : a) mempertahankan efisiensi dan portabilitas bahasa C b) mempertahankan kompatibilitas dengan bahasa C. c) menutupi kekurangan pada bahasa C. d) mempertajam penerapan konsep information hidding. 5. DEKLARASI “CLASS” a) Makna pernyataan STRUCT diubah menjadi CLASS Contoh :

class ostream { public: FILE ‘file: int nextchar: char buf[128]: } b) Kata public menyebabkan ‘file, nextchar, buf’ dapat diakses oleh semua object dalam kelas yang sama. c) Bila kata public tidak dinyatakan maka data ‘file, nextchar, buf’ bersifat private. 6. MEMBER FUNCTION 7. DEKLARASI FUNGSI 8. BASE CLASS 9. DRIVED CLASSES

38


BAB V PEMODELAN DATA

Metode pemodelan data menggunakan ERD (Entity Relationship Diagram). Dengan ERD memungkinkan perekayasa perangkat lunak mengidentifikasi objek data dan hubungannya dengan menggunakan notasi grafis. ERD hanya berfokus pada data, dengan menunjukan “jaringan data” yang ada untuk suatu sistem yang diberikan. ERD sangat berguna bagi aplikasi dimana data dan hubungan yang mengatur data sangatlah kompleks.tidak seperti diagram alir data, pemodelan data melihat secara independen dari pemprosesan yang memtransformasikan data tersebut. 1.

ERD merupakan model jaringan yang menggunakan susunan data yang disimpan dalam sistem secara abstrak

2.

Diagram E-R berupa model data konseptual, yang merepresentasikan data dalam suatu organisasi.

3.

ERD menekankan pada struktur dan relationship data, berbeda dengan DFD(Data Flow Diagram) yang merupakan model jaringan fungsi yang akan dilaksanakan sistem

4.

Biasanya digunakan oleh profesional sistem untuk berkomunikasi dengan pemakai eksekutif tingkat tinggi dalam perusahaan yang tidak tertarik pada pelaksanaan operasi sistem sehari-hari, namun lebih kepada : a.

Data apa saja yang diperlukan untuk bisnis mereka?

b.

Bagaimana data tersebut berelasi dengan data lainnya?

c.

Siapa saja yang diperbolehkan mengakses data tsb?

39


Notasi Yang digunakan pada perancangan E-R diagram ENTITAS

Kardinalitas: Selalu hanya satu

Hubungan

Satu atau banyak Atribut

Nol atau satu Nol, satu, atau banyak

Gambar 5.1 Simbol-simbol ERD Contoh ER diagram terlampir. PELANGGA N PEMASOK

Mengirim

Memasok

KIRIMAN

Memasok

Mengirim

PESANAN

BARANG Beris i Digunakan_

PRODUK

pada

Gambar 5.2 Contoh ERD

latihan Rancanglah diagram E-R dari kasus aplikasi database sederhanauntuk sistem informasi akademis suatu universitas. Dengan ketentuan sebagai berikut : Entities yang dimuat adalah : 1. mahasiswa: menyimpan semua informasi pribadi mengenai semua mahasiswa 2. dosen: menyimpan semua informasi pribadi mengenai semua dosen

40


3. mata_kuliah: menyimpan semua informasi mengenai semua mata kuliah yang ditawarkan 4. ruang: menyimpan semua informasi mengenai ruang kelas yang digunakan

41


BAB VI DASAR-DASAR PERANCANGAN PIRANTI LUNAK

6.1. Prinsip Dasar Perancangan Perangkat Lunak Perancangan Perangkat Lunak merupakan proses penerjemahan dari kebutuhan menjadi perangkat lunak. Hasil dari perancangan adalah : 1. Rancangan data yang memetakan model domain informasi pada saat analisis menjadi struktur data yang dibutuhkan untuk implementasi perangkat lunak. 2. Rancangan arsitektural yang mendefinisikan hubungan dari komponen-komponen struktural utama dari program. 3. Rancangan prosedural yang memetakan komponen-komponen struktural ke deskripsi prosedur perangkat lunak

ABSTRACTION ( Wasserman ) 1. Pada rancangan secara modular, beberapa tingkatan abstraksi dapat diperoleh, sehingga perancang dapat mengkonsen- trasikan pada setiap tingkatan abstraksi yang lebih terinci. 2. Pada level paling tinggi, solusi dinyatakan secara global dengan bahasa pada lingkungan masalah. Dan pada abstraksi paling bawah, solusi dinyatakan dalam bahasa yang dapat langsung diimplementasikan. Contoh Abstraksi Program dan Abstraksi Data : PROGRAM ABSTRACTION

DATA ABSTACTION

Abstraksi tingkat pertama : CAD Software Task User interface Task 2-D Drawing Creation Task ……… end.

TYPE drawing IS STRUCTURE DEFINED Number IS INTEGER Icon IS ICON_STRUCTURE Notes IS STRING LENGTH (225) Versi IS STRING LENGTH ( 10 ) …………… end

Abstraksi tingkat kedua : PROCEDURE User interface ……… …… End

42


MODULARITY & SOFTWARE ARCHITECTURE 1. Perangkat lunak dibagi atas beberapa modul. 2. Sebuah modul dapat dibagi lagi atas beberapa sub-modul 3. Modul memiliki nama yang unik. 4. Sebuah modul dapat memanggil modul lainya.

S1

S2 S3

S4

S5 Software “solution”

“Problem” to be solved via software Gambar 6.1 Struktur Evolusi

P S1 “Problem”

S1

S2

S3

S4

S5

Structure 1

S4

S4

S3

S1

S2

S3

Structure 2

Gambar 6.2 Struktur Berbeda

43

S5 S2

Structure 3

S5


M

a

Depth

d

b e

f

Fan-out c l

k

g

h

i

j

n

m p

o r

q

Fan-in

Width Gambar 6.3 Struktur Terminologi HIRARKI KONTROL ( STRUKTUR PROGRAM ) 1. Menunjukkan organisasi dari modul-modul program dan menunjukan hirarki kontrolnya. Tidak merepresentasikan aspek prosedural dari perangkat lunak seperti urutan proses, keputusan, atau perulangan. 2. Kedalaman dan lebar menunjukkan jumlah tingkatan kontrol dan seluruh cakupan kontrol 3. Fan-out menunjukkan jumlah modul yang secara langsung dikontrol oleh modul lain 4. Fan-in menunjukkan jumlah modul yang mengontrol modul yang bersangkutan 5. Modul yang mengontrol modul yang lain disebut superordinate 6. Modul yang dikontrol modul yang lain disebut subordinate

FAN-OUT 1. Fan-out dari sebuah modul adalah banyaknya subordinate langsung dari modul tersebut 2. Perluasan kontrol dari sebuah modul sebaiknya tidak melebihi 7 + 2 ( kecuali pada pusat-pusat transaksi ) 3. Hindarkan Fan-out yang bersifat main-line (satu boss, dengan modul-modul lain sebagai subordinate ) 44


4. Sebuah modul dengan Fan-out yang banyak biasanya sukar dipelihara. 5. Untuk memecahkan fan-out yang banyak gunakan modul-modul antara

FAN-IN 1. Fan-in

dari

modul

adalah

banyaknya

modul

lain

yang

(

boss

)

menggunakan/memanggil modul tersebut. 2. Jika mungkin Fan-in harus dilakukan sebanyak-banyaknya. 3. Fan-in yang banyak menghindari pengulangan pembuatan modul yang sama atau serupa 4. Fan-in yang banyak mempermudah pemeliharaan karena menempatkan suatu fungsi yang sama dalam satu modul

STRUKTUR DATA Refresentasi lojikal dari hubungan antara elemen-elemen data.

A scalar item

… A scalar item

A linked list

…   

…

A hierarchical tree

An N-dimensional space

Gambar 6.4 Struktur Data Klasik

45


PROSEDUR PERANGKAT LUNAK Struktur program hanya mendefinisikan hirarki kontrol tanpa memperhatikan urutan proses. Prosedur perangkat lunak berfokus pada rincian proses dari setiap modul.

INFORMATION HIDING ( by Pamas ) Prinsip dasar dalam pembentukan modul dimana hanya data yang benar-benar perlu, yang dikenalkan dan dapat diakses oleh sebuah modul. Module A

Module A Prosedur di dalam suatu modul

Gambar 6.5 Prosedur Berlapis

46


6.2. PERANCANGAN YANG MODULAR 1. Keuntungan : a) menurunkan kompleksitas b) mempermudah pengubahan c) implementasi yang lebih mudah karena bagian-bagian yang berbeda dapat dibuat dengan paralel 2. Evaluasi dari hubungan antar modul dapat dinilai dengan melihat kohesi dan koplingnya ( Steven, Myers, dan Constantine )

KOPLING 1. Kopling adalah tingkat saling ketergantungan antara dua modul. 2. Kita menghendaki modul dengan kopling rendah yaitu modul-modul yang sedapat mungkin tidak saling bergantungan. 3. Kopling yang rendah adalah tanda dari pembagian sistem yang baik, dimana sesuatu yang tidak berhubungan dipisahkan. 4. Jika sedikit atau tidak ada interaksi dua modul disebut loosely coupled (kopling rendah) dan jika sebaliknya disebut tighty coupled (kopling tinggi) 5. Makin tinggi kopling yang ada makin sulit sebuah program untuk dimengerti. 6. Jika dua modul memiliki kopling yang rendah, maka sebuah modul dapat diubah tanpa perlu mengubah modul yang lain. 7. Mengapa kopling yang rendah diperlukan ? Untuk menghilangkan ripple effect (perubahan pada sebuah modul dapat berpengaruh pada modul lain). Sehingga dapat memelihara atau mengubah suatu modul dengan resiko yang minimal untuk mengubah modul lainnya. Jika mungkin kita ingin dapat bekerja dengan modul A tanpa perlu mengetahui tentang apapun dalam modul B. 8. Faktor-faktor yang berpengaruh pada kopling antara dua modul adalah : a) Jumlah item data yang disalurkan diantara dua modul (makin banyak data yg disalurkan makin tinggi kopling yang terjadi). b) Jumlah data kontrol yang disalurkan diantara dua modul (makin banyak data kontrol yang disalurkan makin tinggi kopling yang terjadi)

47


c) Jumlah elemen data global yang digunakan bersama-sama oleh beberapa modul (makin banyak data global yang digunakan, makin tinggi kopling yang terjadi)

KOHESI 1. Melekatkan hal-hal yang berkaitan didalam modul yang sama, akan mengurangi lalu-lintas diantara modul-modul . 2. Apa yang terjadi diantara modul-modul (kopling) dipengaruhi oleh apa yang terjadi dalam modul-modul tersebut secara individual (kohesi) 3. Kohesi adalah ukuran kekuatan asosiasi antar elemen didalam suatu modul. 4. Elemen yang dimaksud adalah : sebuah instruksi, sekumpulan intruksi, atau pemanggilan ke modul lain. 5. Kohesi tinggi jika sebuah modul hanya bertanggung jawab terhadap satu pekerjaan saja. Lalu lintas jalan

X

Y

X

Y Kopling rendah Kohesi tinggi

Lalu lintas jalan

Y

X

X

Y Kopling tinggi Kohesi rendah

Gambar 6.6 Kohesi 6.3. RANCANGAN DATA 1.

Rancangan

data yang bagus dapat membuat struktur program lebih baik,

modularitas efektif dan menurunkan kompleksitas prosedural 2.

Beberapa petunjuk : a) Semua struktur data dan operasi yang mengolahnya harus didefinisikasi b) Selalu gunakan kamus data

48


c) Rancanagan data yang bersifat low-level harus ditunda sampai akhir dari proses perancangan d) Bentuk keputusan dan struktur data dan operasi-operasi yang mengolahnya e) Bahasa pemrograman harus mendukung spesifikasi dan realisasi dari tipe data abstrak. 6.4. PERANCANGAN ARSITEKTURAL Tujuan dari perancangan arsitektural adalah untuk membangun struktur program yang modular dan membentuk hubungan kontrol antar modul. Rancangan arsitektural menggabungkan struktur program dan struktur data serta mendefinisikan interface yang membuat data melalui program. Dan dinyatakan dalam bentuk Bagan Susunan atau diagram Wamier/Orr.

BAGAN SUSUNAN (Structured Chart) 1. Bagan susunan merupakan susunan hirarki dari modul-modul 2. Bagan susunan menunjukkan a) pembagian sistem menjadi modul-modul b) hirarki dan organisasi modul-modul c) komunikasi antar modul ( masukan dan keluaran ) d) nama modul, yang berarti juga fungsi modul. 3. Bagan Susunan tidak menunjukkan : a) Mekanik didalam modul ( seperti ukuran pemanggilan modul lain, loops dsb ) b) Data internal dari modul Simbol-simbol yang digunakan : 1

: Nama Modul / Proses

2

: hubungan

3

: pengulangan

4

: Seleksi / pemilihan

5



: Kopel Kontrol

6



: Kopel Data

Gambar 6.7 Simbol-simbol bagan terstruktur

49


Contoh :

Menunjukkan suatu model dengan nama “Hitung Potongan”.

Modul A memanggil modul B. Setelah proses dari modul B selesai, maka proses kembali ke modul A yang memanggilnya.

Modul A memanggil modul B dan elemen data P dikirimkan dari modul A ke modul B. Hasil proses dari modul B mengirimkan elemen data Q dan elemen kontrol Flag ke modul A.

50


Modul A memanggil modul B bila kondisi yang diseleksi di modul terpenuhi. Modul A juga memanggil modul C berulang kali yang ditunjukkan oleh simbol perulangan. Model Bagan Terstruktur Terdapat dua model dari bagan terstruktur, yaitu transformed-centered dan transaction centered. Bagan terstruktur dapat berbentuk model transformed-centered saja atau transaction centered saja atau kombinasi dari keduanya. Model yang digunakan ini tergantung dari diagram arus data yang telah dibuat, karena bagan terstruktur digambarkan berdasarkan diagram arus data (DAD). a. Transformed-centered Bagan terstruktur dengan model transformed-centered menggambarkan sistem dalam 3 cabang utama, yaitu sebagai berikut : 1. Cabang input (input branch) atau disebut juga dengan affrerent branch, merupakan cabang yang menerima input dan membentuk input kedalam suatu status yang siap untuk diproses. 2. Cabang proses (process branch) atau disebut juga dengan cabang transformasi (transform branch) atau disebut juga dengan central transform, merupakan cabang yang akan melakukan fungsi utama dari sistem, yaitu memperoses input yang dikirim dari cabang input. 3. Cabang output (output branch) atau disebut juga dengan efferent branch, merupakan cabang yang akan memformat data menjadi output.

51


Gambar 6.8 Model dasar bagan terstruktur transformed-centered

b. Transaction-centered Seringkali diagram arus data menggambarkan suatu sistem yang menangani beberapa tipe transaksi yang mempunyai jalur yang berbeda. Diagram tersebut mungkin akan sulit dipilah-pilah berdasarkan transformasinya. Untuk diagram alur data tersebut, dapat dibuat bagan terstruktur model transaction-centered.

52


Gambar 6.9 Model bagan terstruktur jenjang dari transaction-centered Contoh :

53


TABEL KEPUTUSAN Tabel keputusan (decision table) adalah tabel yang digunakan sebagai alat bantu untuk menyelesaikan logika dalam program

 Condition Stub ◦

Bagian ini berisi kondisi yang akan diseleksi.

 Condition Entry ◦

Bagian ini berisi kemungkinan dari kondisi yang diseleksi, yaitu terpenuhi (diberi simbol ‘Y’) dan tidak terpenuhi (diberi simbol ‘N’).

◦

Bila ada kondisi X diseleksi, terdapat N Kemungkinan terjadi N = 2X

 Action Stub ◦

Action stub berisi pernyataan-pernyataan yang akan dikerjakan baik kondisi yang diselesi terpenuhi maupun tidak terpenuhi.

 Action Entry ◦

Action entry digunakan untuk memberi tanda tindakan mana yang akan dilakukan dan mana yang tidak akan dilakukan

54


DIAGRAM KEPUTUSAN Merupakan model dari sebuah fungsi diskrit dimana nilai dari sebuah variabel ditentukan; berdasarkan nilai ini beberapa tindakan dilakukan

55


BAHASA TERSUSUN Konteks Logik :

 BIT/SE merupakan jembatan antara analisis perancangan dan pengkodean  BIT/SE adalah bahasa spesifikasi yang menggunakan perbendaraan kata dan sintaks yang terbatas  Perbendaharaan katanya hanya terdiri dari : ◦

Kata kerja perintah/Imperative language verb.

◦

Istilah yang didefinisikan dalam Kamus Data.

◦

Reserved Word tertentu untuk formulasi logik.

Contoh : JIKA

MASA-KERJA LEBIH DARI 15 TAHUN

MAKA BONUS = 100.000 SELAIN ITU BONUS = 50.000 AKHIR JIKA

56


DIAGRAM ALIR/FLOWCHART

BOX DIAGRAM/N-S CHART

57


Contoh :

58


6.5. RANCANGAN PROSEDURAL Rancangan prosedural dilakukan setelah struktur program dan data telah dibentuk. Beberapa bentuk pernyataan : 1. pemrograman terstruktur 2. notasi grafis : flowchart, box diagram/N-S charts 3. bentuk tabel 4. PDL

KARAKTERISTIK NOTASI PERANCANGAN 1. Mendukung modularistas 2. Sederhana 3. Mudah diubah 4. Dapat dibaca oleh mesin 5. Dapat dipelihara 6. Structured enforcerment 7. Code-to-ability 8. Dapat diverifikasi

Beberapa Pedoman 1. Pemakai sistem harus selalu mengetahui apa yang mesti dilakukan berikutnya a) beritahu pemakai apa yang diharapkan oleh sistem sekarang Contoh : SIAP, MASUKKAN PERINTAH, MASUKKAN PILIHAN atau MASUKKAN DATA. b) Beritahu pemakai bahwa data telah dimasukkan dengan benar, Bisa berupa perpindahan kursor ke data berikutnya atau pesan : MASUKKAN VALID c) Beritahu pemakai bahwa pemasukkan data salah. Pemberitahuan format yang benar lebih baik. 2. Bentuk pemakaian alasan adanya delay dalam pemrosesan. Contoh : SORTING, PLEASE STAND BY, INDEXING, PLEASE WAIT, THIS MAY TAKE A FEW MINUTES, TUNGGU SEBENTAR, Adanya pesan membuat pemakai mengetahui bahwa sistem tidak gagal.

59


3. Beritahu pemakai sebuah pekerjaan selesai atau tidak selesai dilakukan Contoh : PRINTING, COMPLETE, PRINTER NOT READY – PLEASE CHECK AND TRY AGAIN.

Rancangan Layar : 1. Layar sebaiknya diatur agar beberapa tipe informasi, intruksi dan pesan selalu muncul di area yang konsisten. Ini akan membantu pemakai mencari informasi yang spesifik 2. Perancangan layar yang terlalu “ norak “ 3. Berikan kesempatan pemakai menghemat pengetikan dengan function keys 4. Jika memungkinkan, berikan harga baku 5. Antisipasi kesalahan yang mungkin dibuat oleh pemakai. a. Contoh : YAKIN DIHAPUS ? 6. Selalu Konsisten 7. Kurang jumlah informasi yang harus diingat diantaranya aksi

Penulisan Program 1. Cobalah untuk langsung menggunakan keistimewaan yang ada pada bahasa pemrograman 2. Cobalah untuk menggunakan library dan fungsi-fungsi yang telah ada pada bahasa pemrograman 3. Jangan mengabaikan pesan-pesan peringatan ( warning message )

Beberapa pedoman Bahasa 1. Sederhana, dan benar secara aturan bahasa. o Bahasa percakapan lebih baik daripada bahasa tulisan 2. Jangan berusaha melucu atau “ sok imut “. o jika penggunaan harus memakainya 25x seharai. Akan tidak lucu lagi. 3. Jangan menyinggung intelegensia pemakai

60


Penulisan Pemrograman 1. Jumlah perintah dalam suatu subprogram sebaiknya 5 – 100 perintah 2. Jumlah paremeter yang di-pass sebaiknya <= 5 3. Hindari penggunaan GO TO 4. Gunakan identitasi 5. Kedalaman pernyataan bersarang sebaiknya < 5. Pengecualian untuk penggunaan fungsi rekursif. 6. Kemampuan program untuk dibaca lebih penting dari pada efesiensi program 7. Gunakan nama-nama yang punya arti

Komentar 1. Berilah komentar pada program anda. 2. Hindari komentar yang terlalu panjang 3. Komentar merupakan jawaban dari pertanyaan pembaca program 4. Berilah komentar setiap variabel 5. Komentar bukan terjemahan dari program anda.

Perbaikan Program 1. Lupakan semua tentang efisiensi sampai program anda dapat bekerja dengan benar. 2. Jangan mencoba untuk memperbaiki sampai anda mengerti benar programnya 3. Jangan mengorbankan kemampuan untuk dibaca demi efisiensi

Pemilihan Bahasa 1. Jika dibutuhkan struktur data yang kompleks : PASCAL, C 2. Jika kinerja, kemampuan real-time : ADA 3. Jika perlu efisiensi memori :C 4. Banyak report & banyak manipulasi berkas : COBOL, 4GL, RPG 5. Akan lebih mudah jika hanya satu bahasa tersedia atau sudah ditemukan oleh pemakai. Pada banyak kasus mengikuti sistem yang sudah ada 6. Beberapa de-facto : a) C untuk sistem software b) Ada, C, Modula-2 untuk aplikasi real-time

61


c) COBOL, 4GL untuk aplikasi bisnis d) FORTRAN untuk aplikasi sains dan teknik e) PASCAL, C untuk program-program aplikasi di PC f) LISP, PROLOG untuk kecerdasan buatan

62


BAB VII PENGANTAR UML (Unified Modeling Language)

7.1. Definisi UML Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah menjadi standar dalam industri untuk visualisasi, merancang dan mendokumentasikan sistem piranti lunak. UML menawarkan sebuah standar untuk merancang model sebuah sistem. Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi piranti lunak, dimana aplikasi tersebut dapat berjalan pada piranti keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Tetapi karena UML juga menggunakan class dan operation dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak dalam bahasa berorientasi objek seperti C++, Java, C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan untuk modeling aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa lainnya, UML mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagram piranti lunak. Setiap bentuk memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana bentuk-bentuk tersebut dapat dikombinasikan. Notasi UML terutama diturunkan dari 3 notasi yang telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design), Jim Rumbaugh OMT (Object Modeling Technique), dan Ivar Jacobson OOSE (Object-Oriented Software Engineering). Sejarah UML sendiri cukup panjang. Sampai era tahun 1990 seperti kita ketahui puluhan metodologi pemodelan berorientasi objek telah bermunculan di dunia. Diantaranya adalah: metodologi booch [1], metodologi coad [2], metodologi OOSE [3], metodologi OMT [4], metodologi shlaer-mellor [5], metodologi wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang metodologi (method war) dalam pendesainan berorientasi objek. Masing-masing metodologi membawa notasi sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila kita bekerjasama dengan group/perusahaan lain yang menggunakan metodologi yang berlainan. Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson, yang merupakan tiga tokoh yang boleh dikata metodologinya banyak digunakan mempelopori usaha untuk penyatuan metodologi pendesainan berorientasi objek. Pada tahun 1995 direlease draft pertama dari UML (versi 0.8). Sejak tahun 1996 pengembangan tersebut 63


dikoordinasikan oleh Object Management Group (OMG – http://www.omg.org). Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru adalah versi 1.5 yang dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun tiga buku serial tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML telah menjelma menjadi standar bahasa pemodelan untuk aplikasi berorientasi objek.

7.2. Konsep Dasar UML

Gambar 7.1 Konsep Dasar UML Abstraksi konsep dasar UML yang terdiri dari structural classification, dynamic behavior, dan model management, bisa kita pahami dengan mudah apabila kita melihat gambar diatas dari Diagrams. Main concepts bisa kita pandang sebagai term yang akan muncul pada saat kita membuat diagram. Dan view adalah kategori dari diagaram tersebut. Lalu darimana kita mulai ? Untuk menguasai UML, sebenarnya cukup dua hal yang harus kita perhatikan: 1. Menguasai pembuatan diagram UML 2. Menguasai langkah-langkah dalam analisa dan pengembangan dengan UML Tulisan ini pada intinya akan mengupas kedua hal tersebut. Seperti juga tercantum pada gambar diatas UML mendefinisikan diagram-diagram sebagai berikut: a) use case diagram b) class diagram

64


c) statechart diagram d) activity diagram e) sequence diagram f) collaboration diagram g) component diagram h) deployment diagram

7.2.1. Use Case Diagram Use case diagram menggambarkan fungsionalitas yang diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaimana”. Sebuah use case merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila kita sedang menyusun requirement sebuah sistem, mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem. Sebuah use case dapat meng-include fungsionalitas use case lain sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use case yang di-include akan dipanggil setiap kali use case yang meng-include dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik keluar fungsionalitas yang common. Sebuah use case juga dapat meng-extend use case lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain. Contoh use case diagram:

65


Gambar 7.2 Contoh Use Case 7.2.2. Class Diagram Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Contoh class diagram:

Gambar 7.3 Contoh Class Diagram

66


7.2.3. Activity Diagram Activity diagrams menggambarkan berbagai alir aktivitas dalam sistem yang sedang dirancang, bagaimana masing-masing alir berawal, decision yang mungkin terjadi, dan bagaimana mereka berakhir. Activity diagram juga dapat menggambarkan proses paralel yang mungkin terjadi pada beberapa eksekusi. Activity diagram merupakan state diagram khusus, di mana sebagian besar state adalah action dan sebagian besar transisi di-trigger oleh selesainya state sebelumnya (internal processing). Oleh karena itu activity diagram tidak menggambarkan behaviour internal sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level atas secara umum. Sebuah aktivitas dapat direalisasikan oleh satu use case atau lebih. Aktivitas menggambarkan proses yang berjalan, sementara use case menggambarkan bagaimana aktor menggunakan sistem untuk melakukan aktivitas. Sama seperti state, standar UML menggunakan segiempat dengan sudut membulat untuk menggambarkan aktivitas. Decision digunakan untuk menggambarkan behaviour pada kondisi tertentu. Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal. Activity diagram dapat dibagi menjadi beberapa object swimlane untuk menggambarkan objek mana yang bertanggung jawab untuk aktivitas tertentu. Contoh activity diagram tanpa swimlane:

Gambar 7.3 Contoh Activity Diagram

67


7.2.4. Sequence Diagram Sequence diagram menggambarkan interaksi antar objek di dalam dan di sekitar sistem (termasuk pengguna, display, dan sebagainya) berupa message yang digambarkan terhadap waktu. Sequence diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa yang dihasilkan. Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class. Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali dengan diterimanya sebuah message. Untuk objek-objek yang memiliki sifat khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller dan persistent entity. Contoh sequence diagram:

Gambar 7.4 Contoh Sequence Diagram

68


7.2.5. Tool Yang Mendukung UML Saat ini banyak sekali tool pendesainan yang mendukung UML, baik itu tool komersial maupun opensource. Beberapa diantaranya adalah: 1) Rational Rose (www.rational.com) 2) Together (www.togethersoft.com) 3) Object Domain (www.objectdomain.com) 4) Jvision (www.object-insight.com) 5) Objecteering (www.objecteering.com) 6) MagicDraw (www.nomagic.com/magicdrawuml) 7) Visual Object Modeller (www.visualobject.com)

69


BAB VIII PENGUJIAN PERANGKAT LUNAK

Saat ini sudah banyak berkembang berbagai metode untuk pengujian perangkat lunak. Metode-metode tersebut memberikan pendekatan yang sistematik untuk pengujian perangkat lunak kepada pengembang. Selain itu, metode-metode tersebut memberikan mekanisme yang dapat membantu memastikan kelengkapan pengujian dan memberikan kemungkinan tertinggi untuk mengungkap kesalahan pada perangkat lunak. Semua produk yang direkayasa dapat diuji dengan satu atau dua cara, yaitu: 1) Dengan mengetahui fungsi yang ditentukan untuk dilakukan oleh suatu produk, pengujian dapat dilakukan untuk memperlihatkan bahwa masing-masing fungsi beroperasi sepenuhnya dan pada waktu yang sama mencari kesalahan pada setiap fungsi 2) Dengan mengetahui kerja internal suatu produk, maka pengujian dapat dilakukan untuk memastikan bahwa seluruh operasi internal bekerja sesuai spesifikasi dan semua komponen internal telah diamati dengan memadai Pendekatan pengujian pertama disebut sebagai pengujian black-box dan pengujian kedua disebut sebagai pengujian white-box. Pengujian black-box berkaitan dengan pengujian yang dilakukan pada antarmuka perangkat lunak. Meskipun dirancang untuk mengungkap kesalahan, pengujian black-box digunakan untuk memperlihatkan bahwa fungsi-fungsi perangkat lunak dapat beroperasi, bahwa input diterima dengan baik dan output dihasilkan dengan tepat, dan integritas informasi eksternal (seperti file data) dipelihara. Pengujian black-box menguji beberapa aspek dasar suatu sistem dengan memperhatikan sedikit struktur logika internal perangkat lunak tersebut. Pengujian white-box didasarkan pada pengamatan yang teliti terhadap detail prosedural. Jalur-jalur logika yang melewati perangkat lunak diuji dengan memberikan kasus uji yang menguji serangkaian kondisi dan atau loop tertentu. Status program tersebut dapat diuji pada berbagai titik untuk menentukan apakah status yang diharapkan sesuai dengan status yang sebenarnya. Sekilas terlihat bahwa pengujian white-box yang sangat teliti akan membawa kepada program yang benar 100%. Yang diperlukan adalah menentukan semua jalur logika, mengembangkan kasus uji untuk mengujinya, dan mengevaluasi hasil, yaitu

70


memunculkan kasus uji untuk menguji logika program secara mendalam. Namun sesuai dengan prinsip pengujian, pengujian secara mendalam akan menimbulkan masalah logistik. Bahkan untuk program yang kecil, dapat dibangkitkan jumlah jalur logika yang besar. Tetapi pengujian white-box tidak boleh dianggap tidak praktis. Sejumlah jalur logika yang penting dapat dipilih dan digunakan. Struktur-struktur data yang penting dapat diperiksa validitasnya. Atribut pengujian black-box dan white-box dapat digabungkan untuk memberikan pendekatan yang memvalidasi antarmuka perangkat lunak, dan secara selektif menjamin bahwa kerja internal perangkat lunak itu benar.

8.1. White-Box Testing White-box testing (kadang-kadang disebut sebagai glass-box testing) adalah metode desain kasus uji yang menggunakan struktur kontrol desain prosedural untuk memperoleh kasus uji. Dengan menggunakan metode pengujian white-box, perekayasa sistem dapat melakukan kasus uji yang: 1) Memberikan jaminan bahwa semua jalur independen pada suatu modul telah digunakan paling tidak satu kali 2) Menggunakan semua keputusan logis pada sisi true dan false 3) Mengeksekusi semua loop pada batasan mereka dan pada batas operasional mereka 4) Menggunakan struktur data internal untuk menjamin validitasnya Muncul pertanyaan tentang mengapa menghabiskan waktu dan sumber daya untuk menguji logika jika dapat memastikan bahwa persyaratan program telah dapat dipenuhi dengan lebih baik. Jawaban dari pertanyaan ini ada pada sifat cacat perangkat lunak seperti: a) Kesalahan logis dan asumsi yang tidak benar berbanding terbalik dengan probabilitas jalur program yang akan dieksekusi. Kesalahan cenderung muncul pada saat perancangan dan implementasi fungsi, kondisi, atau kontrol yang berada di luar mainstream b) Kepercayaan bahwa jalur logika mungkin tidak akan dieksekusi bila pada kenyataannya mungkin dieksekusi pada basis reguler. Aliran logika dari program kadang bersifat konterintuitif, artinya asumsi yang tidak disadari

71


mengenai aliran dan data kontrol dapat menyebabkan kesalahan perancangan yang akan terungkap setelah pengujian jalur dimulai c) Kesalahan tipografi sifatnya acak. Bila sebuah program diterjemahkan ke dalam source code bahasa pemrograman, maka dimungkinkan akan terjadi banyak kesalahan pengetikan. Beberapa kesalahan dapat ditemukan melalui mekanisme pengecekan sintaks, namun yang lainnya tidak akan terdeteksi sampai dilakukan pengujian Sifat cacat tersebut sangat mungkin ditemukan dengan menggunakan pengujian whitebox sedangkan pengujian black-box tidak dapat menemukannya seberapa cermat pun pengujian black-box dilakukan. Alasan inilah yang mendasari mengapa pengujian white-box dilakukan. Jenis pengujian White-Box testing antara lain: 1. Basis path testing 2. Control Structure Testing, yang terdiri dari: - Condition Testing - Data Flow Testing - Loop Testing UJI COBA BASIS PATH Uji coba basis path adalah teknik uji coba white box yg diusulkan Tom McCabe. Metode ini memungkinkan perancang test case mendapatkan ukuran kekompleksan logical dari perancangan prosedural dan menggunakan ukuran ini sbg petunjuk untuk mendefinisikan basis set dari jalur pengerjaan. Test case yg didapat digunakan untuk mengerjakan basis set yang menjamin pengerjaan setiap perintah minimal satu kali selama uji coba. a) Notasi diagram alir

Gambar 8.1 Notasi diagram alir

72


Untuk menggambarkan pemakaian diagram alir diberikan contoh perancangan prosedural dalam bentuk flowchart.

Gambar 8.2 Diagram alir flowchart

Selanjutnya diagram alir diatas dipetakan ke grafik alir

Gambar 8.3 Diagram grafik alir

73


Lingkaran/node : Menggambarkan satu/lebih perintah prosedural. Urutan proses dan keputusan dapat dipetakan dalam satu node. Tanda panah/edge : Menggambarkan aliran kontrol. Setiap node harus mempunyai tujuan node Region : Adalah daerah yg dibatasi oleh edge dan node. Termasuk daerah diluar grafik alir.

Contoh menterjemahkan pseudocode ke grafik alir

1: 2: 3:

4: 5 6 7a: 7b: 8:

do while record masih ada baca record if record ke 1 = 0 then proses record simpan di buffer naikan kounter else if record ke 2 = 0 then reser kounter proses record simpan pada file endif endif enddo end

Nomor pada pseudocode berhubungan dengan nomor node. Apabila diketemukan kondisi majemuk (compound condition) pada pseudcode pembuatan grafik alir menjadi

74


rumit. Kondisi majemuk mungkin terjadi pada operator Boolean (AND, OR, NAND, NOR) yg dipakai pada perintah if. Contoh :

if A or B then procedure x else procedure y endif Node dibuat terpisah untuk masing-masing kondisi A dan B dari pernyataan IF A OR B. Masing-masing node berisi kondisi yg disebut predicate node dan mempunyai karakteristik dua atau lebih edge darinya. b) Cyclomatic Complexity Cyclomatic complexity adalah metrik PL yang menyediakan ukuran kuantitatif dari kekompleksan logikal program. Apabila digunakan dalam kontek metode uji coba basis path, nilai yang dihitung untuk cyclomatic complexity menentukan jumlah jalur independen dalam basis set suatu program dan memberi batas atas untuk jumlah uji coba yang harus dikerjakan untuk menjamin bahwa seluruh perintah sekurangkurangnya telah dikerjakan sekali. Jalur independent adalah jalur yang melintasi atau melalui program dimana sekurangkurangnya terdapat proses perintah yang baru atau kondisi yang baru. Dari gambar 8.3 : Path 1 : 1 - 11 Path 2 : 1 - 2 - 3 - 4 - 5 - 10 - 1 - 11 Path 3 : 1 - 2 - 3 - 6 - 8 - 9 ...: 10 - 1 - 11

75


Path 4 ': 1 - 2 - 3 - 6 - 7 - 9 - 10 - 1 - 11 Path 1,2,3,4 yang telah didefinisikan di atas merupakan basis set untuk diagram alir. Cyclomatic complexity digunakan untuk mencari jumlah path dalam satu flowgraph. Dapat dipergunakan rumusan sbb : 1. Jumlah region grafik alir sesuai dengan cyclomatic complexity. 2. Cyclomatix complexity V(G) untuk grafik alir dihitung dengan rumus: V(G) = E - N + 2 dimana: E = jumlah edge pada grafik alir N = jumlah node pada grafik alir 3. Cyclomatix complexity V(G) juga dapat dihitung dengan rumus: V(G) = P + 1 dimana P = jumlah predicate node pada grafik alir Pada Gambar 8.3 dapat dihitung cyclomatic complexity: 1. Flowgraph mempunyai 4 region 2. V(G) = 11 edge - 9 node + 2 = 4 3. V(G) = 3 predicate node + 1 = 4 Jadi cyclomatic complexity untuk flowgraph Gambar 8.3 adalah 4 c) Melakukan Test Case Metode uji coba basis path juga dapat diterapkan pada perancangan prosedural rinci atau program sumber. Pada bagian ini akan dijelaskan langkah-langkah uji coba basis path. Prosedur rata-rata pada bagian berikut akan digunakan sebagai contoh dalam pembuatan test case.

PROCEDURE RATA-RATA INTERFACE RESULT rata, total, input, total.valid INTERFACE RESULT nilai, minim, max TYPE NILAl (1:100) IS SCALAR ARRAY; TYPE rata, total. input, total.valid, max.minim, jumlah IS SCALAR; TYPE I IS INTEGER; I = 1; total. input = total. valid = 0;

76


jumlah = 0; DO WHILE nilai(i) <> -999 .and. total.input < 100 tambahkan total.input dengan 1; IF nilai(i) >= minimum .and. nilai(i} <=max; THEN tambahkan total.valid dengan I; jumlah=jumlah + nilai(i); ELSE skip; END IF tambahkan i dengan 1; ENDDO IF total. valid> 0 THEN rata =jumlah/total. valid; ELSE rata = -999; ENDIF END Langkah-Iangkah pembuatan test case: 1. Dengan mempergunakan perancangan prosedural atau program sumber sebagai dasar, digambarkan diagram alirnya.

Gambar 8.4 Diagram grafik alir prosedure rata-rata 2. Tentukan cyclomatic complexity untuk diagram alir yang telah dibuat: V (G) = 6 region . V(G) = 17 edge - 13 node + 2 = 6 77


V(G) = 5 predicate node + 1 = 6 3. Tentukan independent path pada flowgraph Dari hasil perhitungan cyclomatic complexity terdapat 6 independent path yaitu: path 1 : 1-2-10-11-13 path 2 : 1-2-10-12-13 path 3 : 1-2-3-10-11-13 path 4 : 1-2-3-4-5-8-9-2-.. path 5 : 1-2-3-4-5-6-8-9-2-.. path 6 : 1-2-3-4-5-6-7-8-9-2-... 4. Buat test case yang akan mengerjakan masing-masing path pada basis set. Data yang dipilih harus tepat sehingga setiap kondisi dari predicate node dikerjakan semua. d) Graph Metrik Graph metrik merupakan PL yang dikembangkan untuk membantu uji coba basis path atau struktur data. Graph metrik adalah matrik empat persegi yang mempunyai ukuran (sejumlah baris dan kolom) yang sama dengan jumlah node pada flowgraph. Masing-masing baris dan kolom mempunyai hubungan dengan node yang telah ditentukan dan pemasukan data matrik berhubungan dengan hubungan (edge) antarnode. Contoh sederhana pemakaian graph matrik dapat digambarkan sbb :

Gambar 8.5 Graph Metrik

78


Pada gambar flowgraph masing-masing node ditandai dengan angka clan edge dengan huruf kecil, kemudian diterjemahkan ke graph matrik. Contoh hubungan node 3 dengan node 4 pada graph ditandai dengan huruf b. Hubungan bobot menyediakan tambahan informasi tentang aliran kontrol. Secara simpel hubungan bobot dapat diberi nilai 1 jika ada hubungan antara node atau nilai 0 jika tidak ada hubungan. Dapat juga hubungan bobot diberi tanda dengan: 

kemungkinan link (edge) dikerjakan



waktu yang digunakan untuk proses selama traversal dari link



memori yang diperlukan selama traversal link



sumber daya yang diperlukan selama traversal link

Gambar 8.6 Hubungan bobot Koneksi : 1–1=0 2–1=1 2–1=1 2–1=1 3 + 1 = 4 cyclomatic complexity

PENGUJIAN LOOP Loop merupakan kendala yang sering muncul untuk menerapkan algoritma dengan tepat. Uji coba loop merupakan teknik pengujian white box yg fokusnya pada validitas dari loop. Kelas loop yaitu :

79


a. Loop Sederhana, pengujian loop sederhana dilakukan dgn mudah, dimana n jumlah maksimum yg diijinkan melewati loop tsb. 1. Lewati loop secara keseluruhan 2. Hanya satu yg dapat melewati loop 3. m dapat melewati loop dimana m< n b. Loop Tersarang, pengujian loop ini menggunakan pendekatan loop sederhana. Petunjuk pengujian loop tersarang : 1. Dimulai dari loop paling dalam. Atur semua loop ke nilai minimum. 2. Kerjakan dgn prinsip loop sederhana untuk loop yg paling dalam sementara tahan loop yang di luar pada parameter terkecil (nilai kounter terkecil) 3. Kemudian lanjutkan untuk loop yg diatasnya. 4. Teruskan sampai semua loop selesai di uji. c. Loop Terangkai, pengujian loop ini menggunakan pendekatan loop sederhana bila masing-masing loop independen, tetapi bila dua loop dirangkai dan pencacah loop 1 digunakan sebagai harga awal loop 2 maka loop tersebut jadi tidak independen, maka pendekatan yg diaplikasikan ke loop tersarang direkomendasikan. d. Loop Tidak Terstruktur, Kapan saja memungkinkan, loop ini didisain kembali agar mencerminkan penggunaan komsepsi pemrograman terstruktur.

Gambar 8.7 Macam-macam loop

80


8.2. Black-Box Testing Pengujian ini fokus kepada persyaratan fungsional perangkat lunak. Pengujian ini memungkinkan pelaku RPL mendapatkan serangkaian kondisi input yang memenuhi persyaratan fungsional suatu program. Pengujian ini berusaha menemukan kesalahan dengan kategori sebagai berikut: 1. Fungsi-fungsi yang salah atau hilang 2. Kesalahan antarmuka 3. Kesalahan struktur data atau akses basisdata eksternal 4. Kesalahan kinerja 5. Kesalahan inisialisasi atau terminasi Pengujian ini cenderung untuk dilakukan pada tahap akhir pengujian berbeda dengan white-box testing. Penguji dituntut untuk menjawab pertanyaan-pertanyaan berikut: a) Bagaimana validitas fungsional diuji? b) Kelas input apa yang akan membuat kasus uji menjadi baik? c) Apakah sistem sangat sensitif terhadap nilai input tertentu? d) Bagaimana batasan suatu data diisolasi? e) Berapa kecepatan dan volume data yang dapat ditolerir sistem? f) Apa pengaruh kombinasi tertentu dari data terhadap operasi sistem? Dengan mengaplikasikan teknik pengujian ini, penguji membuat serangkaian kasus uji yang: a) Mengurangi jumlah kasus uji tambahan yang harus dirancang untuk mencapai pengujian yang benar b) Memberi tahu mengenai ada atau tidaknya kesalahan Contoh pengujian Black-Box testing antara lain: a) Graph Based Testing Method b) Equivalence Partitioning c) Boundary Value Analysis d) Comparison Testing e) Orthogonal Array Testing

81


8.3. Strategi Pengujian Perangkat Lunak Proses pengujian perangkat lunak dapat digambarkan sebagai berikut:

Gambar 8.8 Strategi Pengujian Perangkat Lunak Spiral di atas menggambarkan bagaimana rekayasa sistem membangun sebuah perangkat lunak dimulai dari penentuan kebutuhan perangkat lunak, kemudian (spiral bergerak ke dalam) proses dilanjutkan ke dalam bentuk rancangan, dan akhirnya ke pengkodean (di pusat spiral). Strategi pengujian serupa dengan hal tersebut, namun bergerak dimulai dari pusat menuju keluar spiral. Dimulai dengan unit testing di pusat spiral

di

mana

masing-masing

modul/unit

dari

perangkat

lunak

yang

diimplementasikan dalam source code menjadi sasaran pengujian. Kemudian bergerak keluar spiral, dilakukan integration testing dengan fokus pengujian adalah desain dan konstruksi arsitektur perangkat lunak. Bergerak lagi keluar, dilakukan validation testing dengan sasaran pengujian adalah kesesuaian dengan kebutuhan perangkat lunak yang telah ditentukan di awal. Terakhir pada lingkaran terluar spiral sampai pada system testing, di mana perangkat lunak dan keseluruhan elemen sistem diuji. PENGUJIAN UNIT Unit testing (uji coba unit) fokusnya pada usaha verifikasi pada unit terkecil dari desain PL, yakni modul. Uji coba unit selalu berorientasi pada white box testing dan dapat dikerjakan paralel ayau beruntun dengan modul lainnya. a. Pertimbangan Pengujian Unit Interface diuji cobakan untuk menjamin informasi yg masuk atau yg ke luar dari unit program telah tepat atau sesuai dgn yg diharapkan. Pertama diuji coba adalah interface karena diperlukan untuk jalannya informasi atau data antar modul. Myers mengusulkan checklist untuk pengujian interface:

82




Apakahjumlah parameter input sama dengan jumlah argumen?



Apakah antara atribut dan parameter argumen sudah cocok?



Apakah antara sistem satuan parameter dan argumen sudah cocok?



Apakah jumlah argumen yang ditransmisikan ke modul yang dipanggil sama dengan jumlah parameter?



Apakah atribut dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan atribut parameter?



Apakah sistem unit dari argumen yang ditransmisikan ke modul yang dipanggil sama dengan sistem satuan parameter?



Apakah jumlah atribut dari urutan argumen ke fungsi-fungsi built-in sudah benar?



Adakah referensi ke parameter yang tidak sesuai dengan pain entri yang ada?



Apakah argumen input-only diubah?



Apakah definisi variabel global konsisten dengan modul?



Apakah batasan yang dilalui merupakan argumen?

Bila sebuah modul melakukan I/O ekstemal, maka pengujian interface tambahan harus dilakukan. 

Atribut file sudah benar?



Pemyataan OPEN/CLOSE sudah benar?



Spesifikasi format sudah cocok dengan pernyataan I/O?



Ukuran buffer sudah cocok dengan ukuran rekaman?



File dibuka sebelum penggunaan?



Apakah kondisi End-of-File ditangani?



Kesalahan I/O ditangani?



Adakah kesalahan tekstual di dalam informasi output?

Kesalahan yang umum di dalam komputasi adalah: 

kesalah-pahaman atau prosedur aritmatik yang tidak benar



operasi mode yang tercampur



inisialisasi yang tidak benar

83




inakurasi ketelitian



representasi simbolis yang tidak benar dari sebuah persamaan.

Test case harus mengungkap kesalahan seperti 

perbandingan tipe data yang berbeda



preseden atau operator logika yang tidak benar



pengharapan akan persamaan bila precision error membuat persamaan yang tidak mungkin



perbandingan atau variabel yang tidak benar



penghentian loop yang tidak ada atau tidak teratur



kegagalan untuk keluar pada saat terjadi iterasi divergen



variabel loop yang dimodifikasi secara tidak teratur.

b. Prosedur Pengujian Unit Program sumber telah dikembangkan, ditunjang kembali dan diverifikasi untuk sintaksnya, maka perancangan test case dimulai. Peninjauan kembali perancangan informasi akan menyediakan petunjuk untuk menentukan test case. Karena modul bukan program yang berdiri sendiri maka driver (pengendali) dan atau stub PL harus dikembangkan untuk pengujian unit. Driver adalah program yg menerima data untuk test case dan menyalurkan ke modul yg diuji dan mencetak hasilnya. Stub melayani pemindahan modul yg akan dipanggil untuk diuji.

PENGUJIAN INTEGRASI Pengujian terintegrasi adalah teknik yg sistematis untuk penyusunan struktur program, pada saat bersamaan dikerjakan uji coba untuk memeriksa kesalahan yg nantinya digabungkan dengan interface. Metode pengujian 

top down integration



buttom up integration

a. Top Down Integration Merupakan pendekatan inkrmental untuk penyusunan struktur program. Modul dipadukan dgn bergerak ke bawah melalui kontrol hirarki dimulai dari modul

84


utama. Modul subordinat ke modul kontrol utama digabungkan ke dalam struktur baik menurut depth first atau breadth first. Proses integrasi: 

modul utama digunakan sebagai test driver dan stub yang menggantikan seluruh modul yg secara langsung berada di bawah modul kontrol utama.



Tergantung pada pendekatan perpaduan yg dipilih (depth / breadth)



Uji coba dilakukan selama masing-masing modul dipadukan



Pada penyelesaian masing-masing uji coba stub yg lain dipindahkan dgn modul sebenarnya.



Uji coba regression yaitu pengulangan pengujian untuk mencari kesalahan lain yang mungkin muncul.

b. Bottom Up Integration Pengujian buttom up dinyatakan dgn penyusunan yang dimulai dan diujicobakan dengan atomic modul (modul tingkat paling bawah pada struktur program). Karena modul dipadukan dari bawah ke atas, proses yang diperlukan untuk modul subordinat yang selalu diberikan harus ada dan diperlukan untuk stub yang akan dihilangkan. Strategi pengujian : 

Modul tingkat bawah digabungkan ke dalam cluster yang memperlihatkan subfungsi PL



Driver (program kontrol pengujian) ditulis untuk mengatur input test case dan output



Cluster diuji



Driver diganti dan cluster yg dikombinasikan dipindahkan ke atas pada struktur program

85


Gambar 8.9 Bottom Up Integration UJI COBA VALIDASI Setelah semua kesalahan diperbaiki maka langkah selanjutnya adalah validasi testing. Pengujian validasi dikatakan berhasil bila fungsi yg ada pada PL sesuai dgn yg diharapkan pemakai. Validasi PL merupakan kumpulan seri uji coba black box yg menunjukkan sesuai dgn yg diperlukan. Kemungkinan kondisi setelah pengujian: 1. Karakteristik performansi fungsi sesuai dgn spesifikasi dan dapat diterima. 2. Penyimpangan dari spesifikasi ditemukan dan dibuatkan daftar penyimpangan.

Pengujian BETA dan ALPHA Apabila PL dibuat untuk pelanggan maka dapat dilakukan acceptance test sehingga memungkinkan pelanggan untuk memvalidasi seluruh keperluan. Test ini dilakukan karena memungkinkan pelanggan menemukan kesalahan yang lebih rinci dan membiasakan pelanggan memahami PL yg telah dibuat. a. Pengujian Alpha Dilakukan pada sisi pengembang oleh seorang pelanggan. PL digunakan pada setting yang natural dgn pengembang “yg memandang” melalui bahu pemakai dan merekam semua kesalahan dan masalah pemakaian. b. Pengujian Beta

86


Dilakukan pada satu atau lebih pelanggan oleh pemakai akhir PL dalam lingkungan yang sebenarnya, pengembang biasanya tidak ada pada pengujian ini. Pelanggan merekam semua masalah (real atau imajiner) yang ditemui selama pengujian dan melaporkan pada pengembang pada interval waktu tertentu.

UJI COBA SISTEM Pada akhirnya PL digabungkan dgn elemen sistem lainnya dan rentetan perpaduan sistem dan validasi tes dilakukan. Jika uji coba gagal atau di luar skope dari proses daur siklus pengembangan system, langkah yang diambil selama perancangan dan pengujian dapat diperbaiki. Keberhasilan perpaduan PL dan system yg besar merupakan kuncinya. Sistem testing merupakan rentetan pengujian yang berbeda-beda dengan tujuan utama mengerjakan keseluruhan elemen sistem yang dikembangkan. a. Recovery Testing Adalah system testing yg memaksa PL mengalami kegagalan dalam bermacammacam cara dan memeriksa apakah perbaikan dilakukan dengan tepat. b. Security Testing Adalah pengujian yg akan melalukan verifikasi dari mekanisme perlindungan yg akan dibuat oleh system, melindungi dari hal-hal yang mungkin terjadi. c. Strees Testing Dirancang untuk menghadapi situasi yg tidak normal pada saat program diuji. Testing ini dilakukan oleh system untuk kondisi seperti volume data yang tidak normal (melebihi atau kurang dari batasan) atau frekuensi.

87


DAFTAR PUSTAKA

Anonim, (2013). Analisis Terstruktur. http://soft-to-gine.blogspot.com/2011/09/analisisterstruktur.html. Diakses 30 Januari 2013. Darwiyanti, Sri dan Wahono Satrio Romi. Pengantar Unified Modeling language. http://setia.staff.gunadarma.ac.id /Downloads /files/6039/MateriSuplemenUml.pdf. Diakses 5 Februari 2013. Pressman, S, R. (2002). Rekayasa Perangkat Lunak. Andi. Yogyakarta. Jogiyanto,H.(1990).Analisis dan Design Sistem Informasi: Pendekatan Terstruktur Teori dan Praktek Aplikasi Bisnis. Yogyakarta : ANDI Publisher. Nugroho P E, Ratnasar K, Ramadhani N K, dan Putro L B. (2013 ). Rekayasa Perangkat Lunak http://courseware.politekniktelkom.ac.id/BUKU_MI/Semester%203/IS213%20 Rekayasa%20Perangkat%20Lunak/Rekayasa%20Perangkat%20Lunak.pdf. Diakses 5 Februari 2013. Verdi Yasin, Rekayasa Perangkat Lunak Berorientasi Objek, Mitra Wacana Media, Jakarta 2012.

88

BAB I PENGENALAN REKAYASA PERANGKAT LUNAK

Recommend Documents