3.1 TUJUAN
Tujuan modul ini, adalah:
• Praktikan dapat menerapkan teknik dalam tahapan perancangan perangkat lunak.
• Praktikan dapat mendokumentasikan hasil perancangan (SDD)
• Praktikan dapat melakukan review dokumen rancangan.
3.2 TEORI
3.2.1 Perancangan Awal (Preliminary Design) 3.2.1.1 Perancangan Data
Perancangan data adalah aktifitas pertama dari empat aktifitas perancangan selama proses rekayasa perangkat lunak. Pengaruh arsitektur data pada struktur program dan kompleksitas prosedural akan berpengaruh juga terhadap kualitas software. Aktifitas utama selama perancangan data adalah menyeleksi representasi logis dari objek data (struktur data) yang diidentifikasikan selama pendefinisian kebutuhan dan fase spesifikasi. Selain itu melakukan identifikasi modul program.
3.2.1.2 Perancangan Arsitektural
Perancangan arsitektural bertujuan untuk mengembangkan sebuah struktur program yang modular dan menunjukan hubungan antar modul. Perancangan ini menyatukan struktur program dan struktur data, menentukan interface yang membaca data bisa mengalir disemua program.
3.2.1.2.1 Proses Perancangan Arsitektural
Perancangan yang berorientasi aliran data adalah metode perancangan arsitektural yang mengijinkan transisi dari model analisis ke sebuah deskripsi perancangan dari struktur program. Transisi dari aliran informasi ke struktur dicapai sebagai bagian
dari proses lima tahapan sebagai berikut : 1. Tipe aliran informasi telah ditetapkan. 2. Batasan aliran telah ditunjuk.
3. DFD dipetakan ke seluruh program.
4. Hirarki kendali didefiniskan oleh “factoring”.
5. Struktur gabungan diperbaiki dengan menggunakan ukuran-ukuran dan usaha-usaha perancangan.
Gambar 3.1 Contoh desain Arsitektural
3.2.2 Perancangan Rinci (Detail Design) 3.2.2.1 Perancangan Prosedur
Idealnya spesifikasi prosedur diperlukan untuk mendefinisikan algoritma yang rinci yang dinyatakan dalam bahasa sehari-hari. Perancangan prosedur harus memberikan prosedur yang rinci dan tidak bermakna ganda. Dengan menggunakan bahasa sehari-hari, kita bisa menuliskan sekelompok langkah-langkah prosedural dalam berbagai cara.
1. Pemrograman terstruktur
Djikstra mengusulkan penggunaan sekumpulan konstruksi logika dimana suatu program bisa berbentuk, terdiri dari :
- Sequence/urutan adalah implementasi dari tahapan pemrosesan yang
merupakan bagian yang esensial dalam spesifikasi dari setiap algoritma.
- Kondisi, memberikan fasilitas untuk proses pemilihan berdasarkan
beberapa kejadian logika.
- Pengulangan, memberikan kesempatan suatu perintah dijalankan
berulang-ulang.
Ketiga konstruksi di atas merupakan dasar dari pemrograman terstruktur yang merupakan teknik perancangan prosedur yang penting.
2. Notasi Perancangan dengan menggunakan grafik
Notasi Flowchart adalah salah satu notasi untuk perancangan prosedur yang banyak digunakan.
Tabel 3.2 Notasi box Diagram/Nassi-Shneiderman Chart (N-S Chart)/Chapin Chart
3. Bahasa perancangan program (Program Design Language/PDL)
PDL disebut juga Structured English or Pseudocode, sepintas Bahasa perancangan program ini mirip dengan bahasa pemrograman modern.
4. Notasi perancangan berbentuk tabel
Dalam beberapa software aplikasi, sebuah modul diinginkan untuk mengevaluasi kombinasi komplek dari kondisi dan harus memilih aksi yang tepat berdasarkan kondisi tersebut. Tabel keputusan (Decision Table) memberikan notasi yang memindahkan aksi dan kondisi ke bentuk tabel.
Tabel keputusan ini dibagi menjadi empat bagian, yaitu : - Bagian kiri atas mengandung daftar dari semua kondisi.
- Bagian kiri bawah berisi aksi yang muncul berdasarkan kombinasi dari kondisi.
- Bagian kanan adalah matriks yang menunjukan kombinasi aksi dan kondisi yang berkaitan, yang akan terjadi untuk kombinasi tertentu. untuk itu setiap kolom dari matrik bisa diinterprestasikan sebagai hukum (rule) pemrosesan.
- Daftarkanlah semua aksi yang berkaitan dengan prosedur khusus.
- Buat daftar kondisi atau pengambilan keputusan selama eksekusi prosedur berlangsung.
- Hubungkan sekumpulan kondisi tertentu dengan aksi tertentu, buanglah kombinasi yang tidak mungkin.
- Tentukan hukum/aturan dengan menunjukan aksi apa yang terjadi untuk sekumpulan kondisi tertentu.
3.2.3 (Lanjutan) Perancangan UML 3.2.3.1 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. Class memiliki tiga area pokok :
1. Nama (dan stereotype) 2. Atribut
3. Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut :
• Private, tidak dapat dipanggil dari luar class yang bersangkutan
• Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya
• Public, dapat dipanggil oleh siapa saja
Class dapat merupakan implementasi dari sebuah interface, yaitu class abstrak yang hanya memiliki metoda.
Interface tidak dapat langsung diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class. Dengan demikian interface mendukung resolusi metoda pada saat run-time.
Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi package. Kita juga dapat membuat diagram yang terdiri atas package.
Hubungan Antar Class
1. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class yang memiliki atribut berupa class lain, atau class yang harus mengetahui eksistensi class lain. Panah navigability menunjukkan arah query antar class.
2. Agregasi, yaitu hubungan yang menyatakan bagian (“terdiri atas..”).
3. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari class lain dan mewarisi semua atribut dan metoda class asalnya dan menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
4. Hubungan dinamis, yaitu rangkaian pesan (message) yang di- passing dari satu class kepada class lain. Hubungan dinamis dapat digambarkan dengan menggunakan sequence diagram yang akan dijelaskan kemudian.
Gambar 3.5 Contoh Class Diagram
3.2.3.2 Statechart Diagram
Statechart diagram menggambarkan transisi dan perubahan keadaan (dari satu state ke state lainnya) suatu objek pada sistem sebagai akibat dari stimuli yang diterima. Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram).
Dalam UML, state digambarkan berbentuk segiempat dengan sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi antar state umumnya memiliki kondisi guard yang merupakan syarat terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku. Action yang dilakukan sebagai akibat dari event tertentu dituliskan dengan diawali garis miring. Titik awal dan akhir digambarkan berbentuk lingkaran berwarna
penuh dan berwarna setengah.
3.2.3.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 3.7 Contoh Activity Diagram tanpa swimlane
3.2.3.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.
Gambar 3.7 Sequence diagram 3.2.3.5 Collaboration Diagram
Collaboration diagram juga menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek dan bukan pada waktu penyampaian message. Setiap message memiliki sequence number, di mana message dari level tertinggi memiliki nomor 1. Messages dari level yang sama memiliki prefiks yang sama.
3.2.3.6 Component Diagram
Component diagram menggambarkan struktur dan hubungan antar komponen piranti lunak, termasuk ketergantungan (dependency) di antaranya.
Komponen piranti lunak adalah modul berisi code, baik berisi source code maupun binary code, baik library maupun executable, baik yang muncul pada compile time, link time, maupun run time. Umumnya komponen terbentuk dari beberapa class dan/atau package, tapi dapat juga dari komponen-komponen yang lebih kecil. Komponen dapat juga berupa interface, yaitu kumpulan layanan yang disediakan sebuah komponen untuk komponen lain.
3.2.3.7 Deployment Diagram
Deployment/physical diagram menggambarkan detail bagaimana komponen dideploy dalam infrastruktur sistem, di mana komponen akan terletak (pada mesin, server atau piranti keras apa), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Sebuah node adalah server, workstation, atau piranti keras lain yang digunakan untuk men-deployn komponen dalam lingkungan sebenarnya. Hubungan antar
node (misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.
3.2.4 SDD (Software Design Document)
SDD adalah hasil akhir dari proses perancangan. SDDmerupakan penjelasan hasil proses perancangan yang termasuk didalamnya perbaikan hasil perancangan tersebut untuk merepresentasikan perangkat lunak yang sedang dibangun. Kerangka SDD adalah sebagai berikut :
Tabel 3.4 Kerangka SDD
Kerangka Dokumen Keterangan
Abstraksi Abstraksi/Rangkuman dokumen
(SDD) Daftar Isi
Daftar Gambar Daftar Tabel
Daftar Isi, Daftar Gambar dan Daftar Tabel dalam SDD
1 Pendahuluan
1.1 Tujuan SDD Tujuan penyusunan dokumen SDD dan menentukan siapa yang akan menggunakan SDD
1.2 Ruang Lingkup SDD Memberikan batasan pembuatan SDD
1.3 Daftar Definisi dan Singkatan
Menjelaskan definisi dan singkatan dalam SDD
1.4 Overview SDD Menjelaskan isi dan organisasi SDD secara singkat
2 Rancangan Lingkungan Implementasi
Menjelaskan hardware, software, basis data dst yang akan digunakan untuk implementasi
3 Perancangan Data
3.1 Daftar Tabel Menjelaskan tabel-tabel yang akan digunakan oleh perangkat keras (nama tabel, primary key, dan deksripsi tabel)
3.2 Conceptual Data Model (CDM)
Menjelaskan CDM atau E-R Diagram 3.3 Dekomposisi Fungsional
Modul
Menjelaskan untuk suatu modul/proses tabel dengan data yang digunakan sebagai masukan dan keluaran untuk modul/proses
tersebut
3.4 Tabel A Menjelaskan struktur tabel A (Identifikasi tabel, dekripsi isi, jenis tabel, volume, laju, primary key, dst)
3.5 Tabel B,… dst Menjelaskan struktur tabel B…dst (Identifikasi tabel, dekripsi isi, jenis tabel, volume, laju, primary key, dst)
4 Perancangan Arsitektural
4.1 Kajian data dan Aliran data Mengindikasikan bagaiman arsitektur program didapatkan dari model analisis
4.2 Struktur Program yang Diperoleh
Menjelaskan bagan struktur (representasi dari struktur program) yang digunakan untuk menunjukkan hirarki modul tersebut
5 Perancangan Prosedural
5.1 Deskripsi Antarmuka Menjelaskan perancangan antarmuka
5.2 Deskripsi Perancangan Bahasa
Menjelaskan bahasa yang digunakan pada perancangan
5.3 Modul-modul yang digunakan
Menjelaskan modul-modul yang digunakan
5.4 Struktur Data Internal Menjelaskan struktur data internal 5.5 Keterangan/Larangan/Batasan Menjelaskan keterangan/larangan/batasan perancangan 6 Perancangan UML
6.1 Use case Diagram Menggambarkan use case diagram dari rancangan menggunakan tools 6.2 Class Diagram Menggambarkan class diagram dari
rancangan menggunakan tools
6.3 Statechart Diagram Menggambarkan statechart diagram dari rancangan menggunakan tools
6.4 Activity Diagram Menggambarkan activity diagram dari rancangan menggunakan tools
6.5 Sequence Diagram Menggambarkan sequence diagram dari rancangan menggunakan tools 6.6 Collaboration Diagram Menggambarkan collaboration
diagram dari rancangan menggunakan tools
6.7 Component Diagram Menggambarkan component diagram dari rancangan menggunakan tools
6.8 Deployment Diagram Menggambarkan deployment diagram dari rancangan menggunakan tools
Lampiran Berisi penjelasan tambahan pada laporan ini