Rancangan perangkat lunak

8,800 views

Published on

Published in: Education
  • Be the first to comment

Rancangan perangkat lunak

  1. 1. Rancangan Perangkat Lunak By M. Ainul Yaqin, S.Si, M.Kom
  2. 2. Definisi <ul><li>Rancangan didefinisikan dalam IEEE Standard Glossary of Software Engineering Terminology : </li></ul><ul><ul><li>Proses mendefinisikan arsitektur, komponen, interface, dan karakteristik lain dari suatu sistem atau komponen. </li></ul></ul><ul><ul><li>Hasil dari proses tersebut </li></ul></ul><ul><li>Dipandang sebagai suatu proses, rancangan perangkat lunak adalah aktifitas siklus hidup rekayasa perangkat lunak dalam menganalisa kebutuhan perangkat lunak dalam rangka menghasilkan deskripsi struktur internal perangkat lunak yang akan menjadi dasar konstruksinya. </li></ul><ul><li>Lebih tepatnya, rancangan perangkat lunak harus menjelaskan arsitektur perangkat lunak – yaitu bagaimana perangkat lunak didekomposisi dan diorganisasi ke dalam komponen – dan berhubungan dengan komponen-komponen tersebut. </li></ul>
  3. 3. Definisi <ul><li>Rancangan perangkat lunak terdiri dari dua aktifitas yaitu : </li></ul><ul><ul><li>Rancangan arsitektural perangkat lunak : menjelaskan struktur dan organisasi tingkat atas perangkat lunak dan mengidentifikasi berbagai komponen </li></ul></ul><ul><ul><li>Rancangan detail perangkat lunak : menjelaskan tiap komponen secara memadai untuk memungkinkan pembangunan </li></ul></ul>
  4. 4. Area Pengetahuan Perancangan Perangkat Lunak
  5. 5. Konsep Perancangan Secara Umum <ul><li>Konsep, notasi, dan terminologi diperkenalkan di sini membentuk suatu dasar pemahaman peran dan lingkup perancangan perangkat lunak. </li></ul><ul><li>Perangkat lunak tidak hanya meliputi perancangan saja. Dalam pengertian umum, perancangan dapat dipandang sebagai suatu bentuk pemecahan masalah </li></ul><ul><li>Sejumlah notasi dan konsep lain juga berkepentingan dalam memahami perancangan dalam pengertian umumnya : tujuan, batasan, alternatif,representasi, dan solusi </li></ul>
  6. 6. Konsep Perancangan Perangkat Lunak <ul><li>Untuk memahami peranan perancangan perangkat lunak adalah penting untuk memahami konteks yang sesuai, yaitu siklus hidup rekayasa perangkat lunak. </li></ul><ul><li>Dengan demikian, penting untuk memahami karakteristik umum dari analisis kebutuhan perangkat lunak terhadap konstruksi perangkat lunak terhadap pengujian perangkat lunak </li></ul>
  7. 7. Proses Perancangan Perangkat Lunak <ul><li>Perancangan perangkat lunak umumnya terdiri dari 2 tahap proses : </li></ul><ul><ul><li>Perancangan arsitektural : menjelaskan bagaimana perangkat lunak dijabarkan dan diorganisasikan ke dalam komponen (arsitektur perangkat lunak) </li></ul></ul><ul><ul><li>Perancangan terinci : menjelaskan kelakukan spesifik dari komponen-komponen tersebut </li></ul></ul>
  8. 8. Enabling Techniques <ul><li>Menurut kamus Inggris Oxford, prinsip adalah “suatu kebenaran dasar atau hukum umum yang digunakan sebagai dasar pemikiran atau panduan untuk bertindak” </li></ul><ul><li>Prinsip perancangan perangkat lunak disebut juga Enabling Techniques , adalah pengertian kunci yang dianggap mendasar pada beberapa pendekatan dan konsep perancangan perangkat lunak yang berbeda </li></ul><ul><li>Teknik yang memungkinkan adalah sebagai berikut : </li></ul><ul><ul><li>Abstraksi </li></ul></ul><ul><ul><li>Coupling and cohesion </li></ul></ul><ul><ul><li>Dekomposisi dan modularisasi </li></ul></ul><ul><ul><li>Enkapsulasi </li></ul></ul><ul><ul><li>Pemisahan interface dan implementasi </li></ul></ul><ul><ul><li>Kecukupan, kelengkapan, dan keprimitifan. </li></ul></ul>
  9. 9. Abstraksi <ul><li>Abstraksi adalah proses melipakan informasi sehingga hal-hal yang berbeda dapat diperlakukan seolah-oleh mereka adalah sama </li></ul><ul><li>Dalam konteks perancangan perangkat lunak ada dua mekanisme abstraksi kunci, yaitu parameterisasi dan spesifikasi </li></ul><ul><li>Abstraksi dengan spesifikasi ke tiga jenis abstraksi utama, yaitu : </li></ul><ul><ul><li>Abstraksi prosedural </li></ul></ul><ul><ul><li>Abstraksi data </li></ul></ul><ul><ul><li>Abstraksi kontrol </li></ul></ul>
  10. 10. Coupling and Cohesion <ul><li>Coupling didefinisikan sebagai kekuatan hubungan antar modul </li></ul><ul><li>Cohesion didefinisikan oleh bagaimana elemen-elemen yang membentuk sebuah modul yang terkait </li></ul>
  11. 11. Dekomposisi dan Modularisasi <ul><li>Dekomposisi dan modularisasi perangkat lunak besar menjadi beberapa bagian independen yang lebih kecil, biasanya dengan tujuan menempatkan fungsionalitas atau tanggung jawab dalam komponen yang berbeda </li></ul>
  12. 12. Enkapsulasi <ul><li>Enkapsulasi berarti bahwa pengelompokan dan pengemasan elemen-elemen dan detail internal dari abstraksi dan membuat rincian-rincian tersebut tidak dapat diakses </li></ul>
  13. 13. Pemisahan Interface dan Implementasi <ul><li>Pemisahan interface dan implementasi meliputi mendefinisikan suatu komponen dengan menetapkan sebuah interface publik, diketahui oleh klien, terpisah dari rincian tentang bagaimana komponen tersebut direalisasikan </li></ul>
  14. 14. Kecukupan, Kelengkapan, dan Keprimitifan <ul><li>Mencapai kecukupan, kelengkapan, dan keprimitifan berarti memastikan bahwa komponen perangkat lunak mendapatkan semua karakteristik penting dari sebuah abstraksi, tidak lebih </li></ul>
  15. 15. Isu Kunci dalam Perancangan Perangkat Lunak <ul><li>Sejumlah isu pokok yang harus ditangani diataranya adalah kualitas, dekomposisi, organisasi, dan paket komponen perangkat lunak </li></ul><ul><li>Selain itu ada beberapa isu lintas sektor yang juga harus ditangani dintaranya adalah concurrency , pengendalian dan penanganan kejadian ( event ), distribusi komponen, penanganan error , eksepsi, dan toleransi fault, interaksi dan presentasi, dan data persistence </li></ul>
  16. 16. Concurrency <ul><li>Bagaimana men-dekomposisi perangkat lunak ke dalam proses, task , dan thread dan menangani isu yang terkait dengan efisiensi, atomicity , sinkronisasi, dan penjadwalan </li></ul>
  17. 17. Pengendalian dan Penanganan Event <ul><li>Bagaimana mengorganisasi data dan mengendalikan alirannya </li></ul><ul><li>Bagaimana menangani event reaktif dan temporal melalui berbagai mekanisme seperti implicit invocation dan call-backs </li></ul>
  18. 18. Distribusi Komponen <ul><li>Bagaimana mendistribusikan perangkat lunak pada perangkat keras </li></ul><ul><li>Bagaimana komponen berkomunikasi </li></ul><ul><li>Bagaimana middleware dapat digunakan untuk menangani perangkat lunak heterogen </li></ul>
  19. 19. Penanganan Error dan Eksepsi, dan Toleransi Fault <ul><li>Bagaimana mencegah dan mentoleransi faults , dan menangani kondisi eksepsional </li></ul>
  20. 20. Interaksi dan Presentasi <ul><li>Bagaimana interaksi struktur dan organisasi dengan pengguna dan presentasi informasi (misalnya : pemisahan logika presentasi dan bisnis dengan menggunakan pendekatan model-view-controller) </li></ul>
  21. 21. Data Persistence <ul><li>Bagaimana menangani data selamanya </li></ul>
  22. 22. Struktur dan Arsitektur Perangkat Lunak <ul><li>Arsitektur perangkat lunak adalah deskripsi dari beberapa subsistem dan komponen dari sistem perangkat lunak dan hubungan diantara mereka </li></ul><ul><li>Struktur internal adalah cara dimana sesuatu dibangun atau diorganisasi dari perangkat lunak yang dihasilkan </li></ul><ul><li>Konsep-konsep yang berguna selama </li></ul><ul><ul><li>Desain arsitektur : gaya arsitektur </li></ul></ul><ul><ul><li>Desain rinci : pola desain tingkat rendah </li></ul></ul>
  23. 23. Struktur dan Sudut Pandang Arsitektural <ul><li>Aspek ini sering disebut sudut pandang : Sudut pandang merupakan aspek parsial dari sebuah arsitektur perangkat lunak yang menunjukkan sifat spesifik dari sistem perangkat lunak </li></ul><ul><li>Pandangan ini berbeda pada berbagai masalah yang berkaitan dengan perancangan perangkat lunak – misalnya pandangan logis (pemenuhan kebutuhan fungsional) sehubungan dengan pandangan proses (isu concurrency ) dibandingkan dengan pandangan fisik (isu distribusi) dari pandangan pengembangan (bagaimana rancangan dibagi menjadi unit-unit implementasi) </li></ul><ul><li>Gaya arsitektur adalah satu set kendala pada arsitektur yang mendefinisikan satu set atau keluarga yang memenuhinya </li></ul><ul><li>Gaya arsitektur dapat dianggap sebagai metamodel yang dapat memberikan organisasi tingkat tinggi perangkat lunak (arsitektur mikro-nya) </li></ul>
  24. 24. Struktur dan Sudut Pandang Arsitektural <ul><li>Berbagai penulis mengidentifikasi sejumlah gaya arsitektur utama : </li></ul><ul><ul><li>Struktur umum </li></ul></ul><ul><ul><li>Sistem terdistribusi </li></ul></ul><ul><ul><li>Sistem interaktif </li></ul></ul><ul><ul><li>Sistem yang dapat beradaptasi </li></ul></ul><ul><ul><li>Dan lain-lain </li></ul></ul>
  25. 25. Pola Rancangan (Pola Mikroarsitektur) <ul><li>Pola : solusi umum untuk masalah umum dalam konteks tertentu </li></ul><ul><li>Gaya arsitektur dapat dipandang sebagai pola yang mendeskripsikan organisasi perangkat lunak tingkat tinggi (makroarsitektur-nya), pola desain lainnya dapat digunakan untuk mendeskripsikan detil di tingkat rendah, tingkat lokal (mikroarsitektur-nya) </li></ul><ul><ul><li>Pola kreasional (contoh : builder, pabrik, prototype) </li></ul></ul><ul><ul><li>Pola struktural (contoh : adapter, proxy, bridge) </li></ul></ul><ul><ul><li>Pola perilaku (contoh : command, interpreter, template) </li></ul></ul>
  26. 26. Keluarga dari Program dan Kerangka Kerja <ul><li>Pendekatan yang memungkinkan untuk menggunakan kembali rancangan dan komponen perangkat lunak dapat dilakukan dengan mengidentifikasi kemiripan antara anggota keluarga dan dengan menggunakan komponen yang reusable dan customizable . </li></ul><ul><li>Dalam pemrograman berorientasi objek notasi kunci yang berhubungan adalah yang dari kerangka kerja : subsistem perangkat lunak yang lengkap secara parsial dapat diperluas dengan plug-in yang sesuai. </li></ul>
  27. 27. Evaluasi dan Analisis Kualitas Rancangan Perangkat Lunak <ul><li>Bagian ini meliputi sejumlah masalah kualitas dan evaluasi yang secara khusus berhubungan dengan perancangan perangkat lunak </li></ul>
  28. 28. Atribut Kualitas <ul><li>Berbagai atribut biasanya dianggap penting untuk mendapatkan rancangan perangkat lunak, diantaranya adalah : </li></ul><ul><ul><li>Maintanability </li></ul></ul><ul><ul><li>Portability </li></ul></ul><ul><ul><li>Testability </li></ul></ul><ul><ul><li>Traceability </li></ul></ul><ul><ul><li>Correctenss </li></ul></ul><ul><ul><li>Robustness termasuk fitness of purpose </li></ul></ul><ul><li>Atribut kualitas discernable pada saat runtime </li></ul><ul><ul><li>Performance </li></ul></ul><ul><ul><li>Security </li></ul></ul><ul><ul><li>Availability </li></ul></ul><ul><ul><li>Functionality </li></ul></ul><ul><ul><li>Usability </li></ul></ul>
  29. 29. Atribut Kualitas <ul><li>Atribut kualitas yang tidak discernable pada saat runtime </li></ul><ul><ul><li>Modifiability </li></ul></ul><ul><ul><li>Portability </li></ul></ul><ul><ul><li>Reusability </li></ul></ul><ul><ul><li>Integrability </li></ul></ul><ul><ul><li>Testability </li></ul></ul><ul><li>Atribut kualitas yang berhubungan dengan kualitas intrinsik arsitektur </li></ul><ul><ul><li>Conceptual integrity </li></ul></ul><ul><ul><li>Correctness </li></ul></ul><ul><ul><li>Completeness </li></ul></ul><ul><ul><li>Buildability </li></ul></ul>
  30. 30. Teknik Evaluasi dan Analisis Kualitas <ul><li>Berbagai alat dan teknik yang dapat membantu memastikan kualitas rancangan perangkat lunak </li></ul><ul><ul><li>Tinjauan rancangan perangkat lunak : informal atau semiformal, sering berbasis kelompok, teknik-teknik untuk memverifikasi dan memastikan kualitas artefak perancangan (contoh : tinjauan arsitektur, tinjauan rancangan, dan inspeksi, teknik berbasis skenario, pelacakan kebutuhan) </li></ul></ul><ul><ul><li>Analisis statik : analisis statik formal atau semiformal yang dapat digunakan untuk mengevaluasi suatu rancangan </li></ul></ul><ul><ul><li>Simulasi dan prototyping : teknik dinamis untuk mengevaluasi suatu rancangan (contoh : kinerja simulasi atau kelayakan prototipe) </li></ul></ul>
  31. 31. Pengukuran <ul><li>Pengukuran dapat digunakan untuk menilai atau memperkirakan secara kuantitatif berbagai aspek ukuran, struktur atau kualitas rancangan perangkat lunak </li></ul><ul><li>Pengukuran-pengukuran berikut ini diklasifikasikan ke dalam dua kategori : </li></ul><ul><ul><li>Pengukuran rancangan function-oriented (terstruktur) : struktur rancangan, sebagian besar didapatkan melalui dekomposisi fungsional, biasanya direpresentasikan sebagai bagan struktur pada berbagai pengukuran yang dapat dihitung </li></ul></ul><ul><ul><li>Pengukuran rancangan berorientasi objek : struktur rancangan keseluruhan yang sering direpresentasikan sebagai diagram class pada berbagai pengukuran yang dapat dihitung </li></ul></ul>
  32. 32. Notasi Perancangan Perangkat Lunak <ul><li>Notasi-notasi khusus digunakan terutama dalam rancangan arsitektural dan rancangan terinci </li></ul>
  33. 33. Deskripsi Struktural (Pandangan Statik) <ul><li>Notasi-notasi berikut ini, sebagian besar grafis, menjelaskan dan merepresentasikan aspek struktural dari rancangan perangkat lunak </li></ul><ul><ul><li>Architecture Description Languages (ALDs) : tekstual, terkadang firmal, bahasa yang digunakan untuk menjelaskan arsitektur perangkat lunak dalam hal komponen dan konektor </li></ul></ul><ul><ul><li>Diagram Objek dan Class : digunakan untuk merepresentasikan sekumpulan class (dan objek) dan hubungannya </li></ul></ul><ul><ul><li>Diagram Komponen : digunakan untuk merepresentasikan sekumpulan komponen dari sebuah sistem yang cocok dan menyediakan realisasi sekumpulan interface dan hubungannya </li></ul></ul><ul><ul><li>Class Responsibility Collaborate Cards (CRCs) : digunakan untuk menunjukkan nama komponen (class), tanggung jawabnya, nama komponen yang berkolaborasi </li></ul></ul>
  34. 34. Deskripsi Struktural (Pandangan Statik) <ul><ul><li>Deployment Diagrams : digunakan untuk merepresentasikan sekumpulan nodes (fisik) dan hubungannya, dan demikian juga pada aspek fisik sistem </li></ul></ul><ul><ul><li>Entity Relatinship Diagram (ERD) : digunakan untuk merepresentasikan model konseptuan dari data yang tersimpan dalam sistem informasi </li></ul></ul><ul><ul><li>Interface Description Languages (IDLs) : bahasa programming-like digunakan untuk mendefinisikan interface dari komponen perangkat lunak </li></ul></ul><ul><ul><li>Diagram Struktur Jackson : digunakan untuk menjelaskan struktur data dalam hal urutan, pemilihan, dan iterasi </li></ul></ul><ul><ul><li>Bagan Struktur : digunakan untuk menjelaskan struktur pemanggilan program </li></ul></ul>
  35. 35. Deskripsi Kelakuan (Pandangan Dinamis) <ul><li>Notasi dan bahasa, beberapa grafis dan tekstual berikut ini digunakan untuk menjelaskan kelakuan dinamis dari perangkat lunak dan komponen </li></ul><ul><ul><li>Activity Diagrams : digunakan untuk menunjukkan kendali aliran dari aktifitas yang satu ke aktifitas yang lain </li></ul></ul><ul><ul><li>Collaboration Diagrams : digunakan untuk menunjukkan interaksi yang timbul diantara kelompok objek, dimana penekanannya pada objek dan link-nya </li></ul></ul><ul><ul><li>Data Flow Diagrams (DFDs) : digunakan untuk menunjukkan aliran data diantara sekumpulan proses </li></ul></ul><ul><ul><li>Diagram dan tabel keputusan : digunakan untuk merepresentasikan kombinasi komplek dari kondisi dan tindakan </li></ul></ul><ul><ul><li>Flowcharts dan Structured Flowcharts : digunakan untuk merepresentasikan aliran kendali dan tindakan yang berhubungan yang akan dilakukan </li></ul></ul>
  36. 36. Deskripsi Kelakuan (Pandangan Dinamis) <ul><ul><li>Sequence Diagrams : digunakan untuk menunjukkan interaksi diantara sekelompok objek, dengan penekanan pada urutan waktu pesan </li></ul></ul><ul><ul><li>State Transition dan statechart diagram : digunakan untuk menunjukkan aliran kendali dari state ke state dalam sebuah state machine </li></ul></ul><ul><ul><li>Bahasa spesifikasi formal : bahasa tekstual yang menggunakan notasi dasar dari matematik (contoh : logic, set, sequence ) untuk mendefinisikan kelakuan dan interface komponen perangkat lunak secara abstrak dan teliti </li></ul></ul><ul><ul><li>Pseudocode dan Program Design Languages (PDLs) : bahasa structured-programming-like digunakan untuk menjelaskan, secara umum pada tahap rancangan terinci, kelakuan prosedur atau metode. </li></ul></ul>
  37. 37. Metode dan Strategi Peracangan Perangkat Lunak <ul><li>Ada berbagai strategi umum yang digunakan untuk membantu proses perancangan </li></ul><ul><li>Metode lebih spesifik menawarkan dan menyediakan satu set notasi yang digunakan dengan metode. Sebuah deskripsi proses yang digunakan ketika mengikuti metode dan menetapkan pedoman dalam penggunaan metode </li></ul>
  38. 38. Strategi Umum <ul><li>Beberapa contoh startegi umum yang berguna dalam proses perancangan adalah </li></ul><ul><ul><li>Divide-and-conquer dan stepwise refinement </li></ul></ul><ul><ul><li>Top-down dan bottom-up </li></ul></ul><ul><ul><li>Abstraksi data dan penyembunyian informasi </li></ul></ul><ul><ul><li>Penggunaan heuristik </li></ul></ul><ul><ul><li>Penggunaan pola dan bahasa pola </li></ul></ul><ul><ul><li>Penggunaan pendekatan iteratif dan incremental </li></ul></ul>
  39. 39. Rancangan Function-Oriented (Terstruktur) <ul><li>Merupakan metode kalsik dari perancangan perangkat lunak dimana dekomposisi sebagai pusat identifikasi sebagian besar fungsi perangkat lunak dan kemudian menjelaskan dan menyempurnakan secara top-down </li></ul><ul><li>Desain terstruktur umumnya digunakan setelah analisis terstruktur yang menghasilkan DFD dan deskripsi proses yang terkait </li></ul>
  40. 40. Rancangan Object-Oriented <ul><li>Bidang rancangan object-oriented adalah kata benda = objek, kata kerja = metode, kata sifat = atribut </li></ul><ul><li>Inheritance dan polimorfisme memainkan peranan kunci dimana meta-informasi dapat didefinisikan dan diakses </li></ul>
  41. 41. Rancangan Data-Structured-Centered <ul><li>Rancangan data-structured-centered mulai dari struktur data sebuah program yang memanipulasi fungsi yang dikerjakannya </li></ul><ul><li>Struktur data input dan output terlebih dahulu dijelaskan dan kemudian mengembangkan struktur kendali program yang berdasar pada diagram struktur data </li></ul>
  42. 42. Rancangan Component-Based <ul><li>Sebuah komponen perangkat lunak adalah sebuah unit independen, memiliki interface dan dependensi yang jelas yang dapat disusun dan didistribusikan secara independen </li></ul><ul><li>Rancangan component-based membahas isu-isu yang terkait dengan penyediaan, pengembangan, dan integrasi komponen untuk meningkatkan penggunaan kembali ( reuse ) </li></ul>
  43. 43. Metode Lainnya <ul><li>Pendekatan lainnya adalah metode formal and rigorous , dan metode transformasional. </li></ul>

×