SOFTWARE DESIGN PENDAHULUAN Desain didefinisikan dalam

SOFTWARE DESIGN
PENDAHULUAN
Desain didefinisikan dalam [IEEE610.12-90] baik sebagai "proses mendefinisikan arsitektur,
komponen, antarmuka, dan karakteristik lain dari sistem atau komponen" dan "hasil [yang]
proses." Dilihat sebagai suatu proses, perangkat lunak
desain adalah rekayasa perangkat lunak siklus hidup kegiatan di mana persyaratan
perangkat lunak dianalisis untuk menghasilkan deskripsi struktur internal perangkat lunak
yang akan berfungsi sebagai dasar untuk konstruksi. Lebih tepatnya, desain perangkat lunak
(hasil) harus menjelaskan perangkat lunak arsitektur-yang, bagaimana perangkat lunak
terurai dan disusun dalam komponen-dan antarmuka antara komponen-komponen. Hal ini
juga harus menjelaskan komponen di tingkat detail yang memungkinkan konstruksi mereka.
Software desain memainkan peran penting dalam pengembangan software: memungkinkan
insinyur perangkat lunak untuk menghasilkan berbagai model yang membentuk semacam
cetak biru dari solusi untuk dilaksanakan. Kita dapat menganalisis dan mengevaluasi modelmodel untuk menentukan apakah atau tidak mereka akan memungkinkan kami untuk
memenuhi berbagai persyaratan. Kami juga dapat memeriksa dan mengevaluasi berbagai
alternatif solusi dan trade-off. Akhirnya, kita dapat menggunakan model yang dihasilkan
untuk merencanakan kegiatan pembangunan berikutnya, selain menggunakan mereka
sebagai masukan dan titik awal konstruksi dan pengujian. Dalam daftar standar proses siklus
hidup perangkat lunak seperti IEEE / EIA 12207 Proses Software Life Cycle [IEEE12207.0-96],
desain perangkat lunak terdiri dari dua kegiatan yang sesuai antara analisis persyaratan
perangkat lunak dan konstruksi perangkat lunak:
 Software architectural design (terkadang disebut toplevel design): menggambarkan
tingkat atas struktur perangkat lunak dan organisasi dan mengidentifikasi berbagai
komponen
 Software detailed design: describing each component sufficiently to allow for its
construction.
Mengenai ruang lingkup Area Software Desain Pengetahuan (KA), deskripsi KA saat ini tidak
membahas setiap topik nama yang mengandung kata Tom DeMarco Dalam terminologi
(DeM99), KA "desain." dibahas dalam bab ini terutama berkaitan dengan D-desain
(dekomposisi desain, perangkat lunak pemetaan menjadi potongan-potongan komponen).
Namun, karena pentingnya di bidang tumbuh arsitektur perangkat lunak, kami juga akan
membahas FPdesign (keluarga pola desain, yang tujuannya adalah untuk membentuk
dieksploitasi kesamaan dalam keluarga perangkat lunak). Sebaliknya, Software Desain KA
tidak alamat I-desain (desain penemuan, biasanya dilakukan selama proses persyaratan
perangkat lunak dengan tujuan konseptualisasi dan menetapkan perangkat lunak untuk
memenuhi kebutuhan ditemukan dan persyaratan), karena topik ini harus dianggap sebagai
bagian dari analisis kebutuhan dan spesifikasi. Desain Software KA keterangan terkait secara
khusus Software Requirements, Software Construction, Software Engineering Management,
Software Quality, and Related Disciplines of Software Engineering.
RINCIAN TOPIK UNTUK DESAIN PERANGKAT LUNAK
1. Software Desain Fundamental
Konsep-konsep, gagasan, dan terminologi diperkenalkan di sini membentuk dasar yang
mendasari untuk memahami peran dan lingkup desain perangkat lunak.
1.1. Umum Konsep Desain
Perangkat lunak tidak hanya bidang dimana desain yang terlibat. Dalam arti umum,
kita dapat melihat desain sebagai bentuk problemsolving. [Bud03: c1] Misalnya,
konsep masalah-masalah jahat tanpa definitif solusi menarik dalam hal memahami
batas-batas desain. Sejumlah gagasan dan konsep lainnya juga sangat menarik dalam
memahami desain dalam arti umum: tujuan, kendala, alternatif, representasi, dan
solusi.
1.2. Konteks Desain Software
Untuk memahami peran desain perangkat lunak, penting untuk memahami konteks
yang sesuai, siklus hidup rekayasa perangkat lunak. Dengan demikian, penting untuk
memahami karakteristik utama dari perangkat lunak analisis persyaratan desain
perangkat lunak vs vs vs konstruksi perangkat lunak pengujian perangkat lunak.
1.3. Software Desain Proses
Software desain umumnya dianggap sebagai proses dua langkah:
1.3.1. arsitektur desain
Desain arsitektur menjelaskan bagaimana software decomposed dan disusun dalam
komponen (arsitektur perangkat lunak)
1.3.2. Detil desain
Detail desain menggambarkan perilaku spesifik dari komponen ini.
Output dari proses ini adalah seperangkat model dan artefak
yang mencatat keputusan besar yang telah diambil.
1,4. Mengaktifkan Teknik
Menurut Kamus Inggris Oxford, prinsipnya adalah "kebenaran dasar atau hukum
umum ... yang digunakan sebagai dasar pemikiran atau panduan untuk bertindak."
Software prinsip-prinsip desain, juga disebut teknik memungkinkan [Bus96], yang
dianggap gagasan kunci mendasar untuk banyak pendekatan desain perangkat lunak
yang berbeda dan konsep. Teknik-teknik yang memungkinkan adalah sebagai
berikut: [
1.4.1. Abstraksi
Abstraksi adalah "proses melupakan informasi sehingga hal-hal yang berbeda dapat
diperlakukan seolah-olah mereka sama." [Lis01] Dalam konteks
perancangan perangkat lunak, dua mekanisme abstraksi kunci parameterization dan
spesifikasi. Abstraksi oleh spesifikasi mengarah ke tiga jenis utama dari
abstraksi: abstraksi prosedural, abstraksi data, dan kontrol (iterasi) abstraksi.
1.4.2. Kopling dan kohesi
Coupling didefinisikan sebagai kekuatan hubungan antara modul, sedangkan kohesi
didefinisikan oleh bagaimana unsur-unsur yang membentuk modul
yang terkait.
1.4.3. Dekomposisi dan modularisasi
Membusuk dan modularizing perangkat lunak besar menjadi beberapa yang
independen yang lebih kecil, biasanya dengan tujuan menempatkan fungsi yang
berbeda atau tanggung jawab dalam berbagai komponen.
1.4.4. Enkapsulasi / informasi persembunyian
Enkapsulasi / informasi persembunyian berarti pengelompokan dan kemasan
elemen dan rincian internal yang abstak dan membuat rincian tidak dapat diakses.
1.4.5. Pemisahan interface dan implementasi
Memisahkan interface dan implementasi mendefinisikan melibatkan komponen
dengan menentukan antarmuka publik, yang dikenal dengan klien, terpisah dari
rincian tentang bagaimana komponen tersebut direalisasikan.
1.4.6. Kecukupan, kelengkapan dan keprimitifan
Pencapaian kecukupan, kelengkapan, dan keprimitifan berarti memastikan bahwa
komponen perangkat lunak menangkap semua karakteristik penting
abstraksi, dan tidak lebih.
3.2. Pola Desain (pola microarchitectural)
Ringkas dijelaskan, pola adalah "solusi umum untuk masalah umum dalam konteks
tertentu." (Jac99) Sementara gaya arsitektur dapat dilihat sebagai pola yang
menggambarkan organisasi tingkat tinggi perangkat lunak (macroarchitecture mereka), pola
desain lainnya dapat digunakan untuk menggambarkan rincian pada tingkat, lebih rendah
lebih lokal (mikroarsitektur mereka).



penciptaan pola (misalnya, pembangun, pabrik,prototipe, dan tunggal)
Struktural pola (misalnya, adaptor, jembatan,komposit, dekorator, façade, kelas
terbang, dan proxy)
Perilaku pola (misalnya, perintah, penerjemah, iterator, mediator, kenang-kenangan,
pengamat, negara, strategi, template, pengunjung)
3.3. Keluarga dan Kerangka Program
Salah satu pendekatan mungkin untuk memungkinkan penggunaan kembali desain
perangkat lunak dan komponen untuk merancang keluarga perangkat lunak, juga dikenal
sebagai lini produk perangkat lunak. Hal ini dapat dilakukan dengan mengidentifikasi
kesamaan di antara anggota keluarga tersebut dan dengan menggunakan komponen dapat
digunakan kembali dan disesuaikan untuk memperhitungkan variabilitas antara anggota
keluarga. Dalam pemrograman OO, sebuah gagasan terkait utama adalah bahwa kerangka:
subsistem perangkat lunak lengkap yang sebagian
dapat diperpanjang dengan tepat instantiating plug-in tertentu (juga dikenal sebagai hot
spot).
4. Software Desain Kualitas Analisa dan Evaluasi
Bagian ini meliputi sejumlah topik kualitas dan evaluasi yang secara khusus berkaitan
dengan desain perangkat lunak. Kebanyakan dibahas secara umum dalam KA Kualitas
Perangkat Lunak.
4.1. Kualitas Atribut
Berbagai atribut pada umumnya dianggap penting untuk mendapatkan desain software
yang baik kualitas berbagai "ilities" (rawatan, portabilitas, testability,
traceability), berbagai "nesses" (kebenaran, ketahanan), termasuk satu perbedaan menarik
"kelayakan tujuan." adalah salah satu antara atribut kualitas discernable pada saat run-time
(kinerja, keamanan, ketersediaan, fungsi,
kegunaan), tidak discernable pada saat run-time (modifiability, portabilitas, usabilitas,
integrability, dan testability) mereka, dan yang berkaitan dengan kualitas intrinsik arsitektur
yang (integritas konseptual, ketepatan, dan kelengkapan,
buildability).
4.2. Kualitas Analisis dan Teknik Evaluasi
Berbagai alat dan teknik yang dapat membantu memastikan kualitas desain perangkat
lunak.
 tinjauan desain Software: informal atau semiformal, sering grup berbasis, teknik
untuk memverifikasi dan memastikan kualitas artefak desain (misalnya, arsitektur
review, tinjauan desain, dan inspeksi, skenario berbasis teknik, persyaratan
pelacakan
 Static analisis: formal atau semiformal statis (nonexecutable)
analisis yang dapat digunakan untuk mengevaluasi
desain (misalnya, kesalahan-pohon analisis atau otomatis
lintas-checking)
 Simulasi dan prototyping: dinamis teknik untuk mengevaluasi sebuah desain
(misalnya, kinerja simulasi atau prototipe kelayakan)
4.3. Tindakan
Tindakan dapat digunakan untuk menilai secara kuantitatif atau untuk memperkirakan
berbagai aspek, struktur desain perangkat lunak kualitas atau ukuran. Langkah yang paling
yang telah diusulkan umumnya bergantung pada pendekatan yang digunakan untuk
memproduksi desain. Langkah-langkah ini diklasifikasikan dalam dua kategori besar:

langkah-langkah desain Fungsi berorientasi (terstruktur): struktur desain, diperoleh
sebagian besar melalui dekomposisi fungsional; umumnya direpresentasikan sebagai

sebuah bagan struktur (terkadang disebut diagram hirarkis) pada berbagai langkah
yang dapat dihitung
berorientasi objek langkah-langkah desain: struktur keseluruhan desain sering
direpresentasikan sebagai diagram kelas, di mana berbagai langkah dapat
dihitung. Tindakan pada sifat-sifat konten internal setiap kelas juga dapat dihitung
5. Software Desain Notasi
Berbagai notasi dan bahasa yang ada untuk mewakili artefak perangkat lunak
desain. Beberapa digunakan terutama untuk menggambarkan struktur organisasi sebuah
desain, yang lain untuk mewakili perilaku perangkat lunak.Notasi tertentu digunakan
terutama dalam desain arsitektur dan lain-lain terutama selama desain rinci, meskipun
beberapa notasi dapat digunakan di kedua langkah. Selain itu, beberapa notasi yang
digunakan terutama dalam konteks metode tertentu (lihat Strategi Desain Software dan
Metode subarea).Di sini, mereka dikelompokkan ke dalam notasi untuk menggambarkan
tampilan (statis) vs struktural tampilan (dinamis) perilaku.
5.1. Deskripsi struktural (melihat statis)
Notasi berikut, sebagian besar (tetapi tidak selalu) grafis, menjelaskan dan mewakili aspek
struktural dari software desain-yaitu, mereka menjelaskan komponen utama dan bagaimana
mereka saling berhubungan (pandangan statis):









bahasa deskripsi Arsitektur (ADL): bahasa tekstual, sering resmi, yang digunakan
untuk menggambarkan arsitektur perangkat lunak dalam hal komponen dan
konektor.
Kelas dan diagram objek: digunakan untuk mewakili ofclasses set (dan objek) dan
antar hubungan mereka.
diagram Komponen : digunakan untuk mewakili satu set komponen ( bagian hysical
dan diganti [s] dari suatu sistem yang [sesuai] untuk dan [memberikan] realisasi satu
set antarmuka dan antar hubungan mereka.
Kelas kartu kolaborator tanggung jawab (CRC): digunakan untuk menunjukkan nama
komponen (kelas), tanggung jawab mereka, dan komponen mereka berkolaborasi
nama.
diagram Deployment : digunakan untuk mewakili satu set (fisik) node dan antar.
hubungan mereka, dan, dengan demikian, untuk model aspek fisik suatu sistem.
Entity-relationship diagram (ERD): digunakan untuk mewakili model konseptual dari
data yang disimpan dalam sistem informasi.
bahasa deskripsi Interface (IDLs): programming like language digunakan untuk
mendefinisikan interface (nama dan jenis operasi diekspor) komponen perangkat
lunak.
diagram struktur Jackson: digunakan untuk menggambarkan struktur data dalam hal
urutan, seleksi, dan iterasi.
grafik Struktur : digunakan untuk menggambarkan struktur memanggil program
(yang panggilan modul, dan disebut oleh yang lain modul).
5.2. Perilaku Deskripsi (pandangan dinamis)
Notasi berikut dan bahasa, beberapa grafis dan beberapa tekstual, digunakan untuk
menggambarkan perilaku dinamis perangkat lunak dan komponen. Banyak dari notasi
berguna kebanyakan, tetapi tidak eksklusif, selama desain rinci.









Activity Diagram : digunakan untuk menunjukkan aliran kontrol dari kegiatan (
Ongoing non-atom eksekusi dalam mesin negara untuk kegiatan
Collaboration Diagram: digunakan untuk menunjukkan interaksi yang terjadi
antara sekelompok objek, di mana penekanannya adalah pada objek, link, dan
pesan yang mereka tukar pada link ini.
Data flow diagram (DFD): digunakan untuk menunjukkan aliran data antara
serangkaian proses
Tabel keputusan dan diagram : digunakan untuk mewakili kombinasi kompleks
dari kondisi dan tindakan.
Flowchart diagram alur dan terstruktur: digunakan untuk mewakili aliran kontrol
dan tindakan yang terkait yang akan dilakukan.
Sequence Diagram: digunakan untuk menampilkan interaksi antara sekelompok
benda, dengan penekanan pada timeordering pesan.
Negara transisi dan diagram statechart: digunakan untuk menunjukkan aliran
kontrol dari negara bagian di mesin negara.
bahasa spesifikasi formal: bahasa tekstual yang menggunakan konsep-konsep
dasar dari matematika (misalnya, logika, set, urutan) harus betul-betul dan
secara abstrak mendefinisikan interface komponen perangkat lunak dan perilaku,
seringkali dalam hal pra-dan pasca-kondisi.
Pseudocode dan bahasa program desain (PDLs): terstruktur pemrograman
seperti bahasa yang digunakan untuk menggambarkan, umumnya pada tahap
desain rinci, perilaku dari prosedur atau metode.
6. Software Desain Strategi dan Metode
Ada ada berbagai strategi umum untuk membantu memandu proses desain. Berbeda
dengan strategi umum, metode yang lebih spesifik dalam bahwa mereka umumnya
menyarankan dan menyediakan satu set notasi untuk digunakan dengan metode ini,
deskripsi proses yang akan digunakan ketika mengikuti metode dan seperangkat
pedoman dalam menggunakan metode ini. Metode tersebut berguna sebagai sarana
untuk mentransfer pengetahuan dan sebagai kerangka umum untuk tim insinyur
perangkat lunak. Lihat juga Software Engineering Peralatan dan Metode KA.
6.1. Strategi Umum
Beberapa contoh yang sering dikutip dari strategi umum berguna dalam proses desain
adalah membagi-dan-menaklukkan dan langkah-langkah penyempurnaan, top-down vs
bottom-up strategi, abstraksi data dan menyembunyikan informasi, penggunaan
heuristik, penggunaan pola bahasa dan pola, penggunaan iteratif dan pendekatan
inkremental.
6.2. Fungsi-Oriented (Terstruktur) Desain
Ini adalah salah satu metode klasik software desain, di mana dekomposisi berpusat pada
mengidentifikasi fungsi software yang besar dan kemudian menguraikan dan
menyempurnakan mereka
dengan cara top-down. Desain terstruktur umumnya digunakan setelah analisis
terstruktur, sehingga menghasilkan, antara lain, diagram aliran data dan proses yang
terkait
deskripsi. Para peneliti telah mengusulkan berbagai strategi (misalnya, transformasi
analisis, analisis transaksi) dan heuristics (misalnya, fan-in/fan-out, lingkup efek vs
lingkup kontrol) untuk mengubah DFD ke dalam perangkat lunak
arsitektur umumnya diwakili sebagai grafik struktur.
6.3. Desain Berorientasi Objek
Sejumlah metode desain perangkat lunak berbasis pada objek telah diusulkan. Bidang
ini telah berkembang dari desain objectbased awal pertengahan 1980-an (kata
benda= benda; kata kerja = metode; kata sifat atribut =) melalui desain OO, di
manapewarisan dan polimorfisme memainkan peran kunci,
untuk bidang komponen berbasis desain, di mana meta-informasi dapat didefinisikan dan
diakses (melalui refleksi,misalnya). Meskipun akar OO desain berasal
dari konsep abstraksi data, tanggung jawab-driven desain juga telah diusulkan
sebagai pendekatan alternatif untuk desainOO.
6.4. Data-Struktur-Centered Desain
Data-struktur berpusat desain (misalnya, Jackson, Warnier-Orr) mulai dari struktur
dataprogram memanipulasi bukan dari fungsi melakukan. itu
software engineer pertama menggambarkan input dan output
data struktur(menggunakan diagram struktur Jackson, misalnya) dan kemudian
mengembangkanstruktur pengendalian program berdasarkan diagram ini struktur
data. Berbagaiheuristik telah diusulkan untuk menangani kasus-khusus untuk contoh,
ketika terdapat ketidaksesuaian antara input dan struktur output.
6.5. Komponen-Based Design (CBD)
Sebuah komponen perangkat lunak adalah unit independen,
memiliki interfacewelldefined dan dependensi yang dapat terdiri dan disebarkan secara
independen.Komponen berbasis desain membahas masalah-masalah terkait
dengan penyediaan, pengembangan, dan
mengintegrasikan komponen tersebut untuk meningkatkan penggunaan kembali.
6.6. Metode lain
Lain pendekatan arus utama menarik tetapi kurang juga ada: metode formal dan
ketatdan metode transformasi.