Component-level design, atau juga dikenal dengan procedural design, baru ada setelah data, arsitektur dan rancangan antarmuka dibuat terlebih dahulu. Component-level design tujuannya adalah untuk menterjemahkan model design ke bentuk software yang akan dibuat. Namun dikarenakan abstraksi model design yang sudah ada relatif tinggi sedangkan abstraksi tingkat program operasionalnya rendah, maka proses penterjemahannya ini menjadi sebuah tantangan tersendiri. Menurut Edsgar Dijkstra, dalam perlkuliahannya mengatakan [DIJ72]:
“Software ini berbeda dibanding dengan produk lain, dimana aturannya adalah semakin tinggi kualitas akan berdampak pada harga. Orang yang benar-benar ingin memperoleh software yang dapat diandalkan akan percaya bahwa mereka harus bisa menemukan suatu alat/cara untuk menghindari memulai suatu sistem dengan bug, dan hasilnya adalah, proses programming menjadi lebih murah . . . programmer efektif . . . tidak boleh menghabiskan waktunya untuk memperbaiki debugg—mereka seharusnya tidak boleh mengenalkan bug untuk memulai membuat suatu sistem.”
Walaupun kalimat di atas diucapkan beberapa tahun yang lalu, namun sampai saat ini masih terbukti benar. Ketika model design diterjemahkan ke dalam bentuk source code, kita harus mengikuti aturan prinsip design yang tidak hanya menterjemahkan namun, juga tidak boleh “mengenalkan bug untuk memulainya.”
SEKILAS MENGENAI COMPONENT-LEVEL DESIGN
Data, arsitektu, dan desain antarmuka harus diterjemahkan ke dalam software yang akan dibuat. Untuk menyelesaikannya, rancangan yang dibuat harus dapat dibaca dan dimengerti oleh sang programmer. Component-level design berbentuk rincian algoritma yang dibutuhkan untuk memanipulasi struktur data, komunikasi antara komponen software melalui antarmukanya, dan membuat algoritma untuk masing-masing komponen.
Siapa yang melakukannya? Software engineer.
Mengapa ini perlu dilakukan? Karena anda harus memastikan benar bahwa program tersebut dapat berjalan sebelum anda membangunnya. Component-level design merupakan rancangan software secara lebih terperinci yang dapat dipergunakan sebagai dokumen agar software yang dibuat tetap konsisten dan benar sesuai dengan perencanaan yang telah dibuat sebelumnya(misalnya data, arsitektur, dan desain antarmuka). Bisa juga digunakan sebagai alat untuk menguji apakah struktur data, interface, dan algoritmanya bisa berjalan sebagaimana mestinya.
Apa saja tahapannya? Merancang data, arsitektur, dan interface sebagai fondasi untuk component-level design. Proses analisa kebutuhan dari sumber user kemudian diterjemahkan ke dalam bentuk model procedural design bisa menggunakan bentuk grafik, tabular, atau tulisan text.
16.1 STRUCTURED PROGRAMMING
Component-level design ditemukan pada awal tahun 1960an kemudian disempurnakan kembali oleh Edsgar Dijkstra dan teman-temannya ([BOH66], [DIJ65], [DIJ76]). Pada akhir tahun 1960an, Dijkstra dan kawan-kawan memperkenalkan sekumpulan kontruksi logika yang dapat merubahnya menjadi sebuah bahasa pemrograman. Konstruksinya dititikberatkan pada "maintenance of functional domain." Oleh karena itulah, setiap konstruksi mempunyai struktur logika yang dapat diprediksikan, yang dimasukkan pada bagian awal statement dan ditutup dibagian bawah statement, sehingga pembaca dapat dengan mudah mengikuti alur prosedurnya.
Konstruksi merupakan urutan, kondisi dan pengulanan. Urutan (Sequence) menggambarkan langkah-langkah proses yang menentukan di dalam spesifikasi suatu algoritma.. Kondisi (Condition) untuk memilih proses berdasarkan beberapa logika yang ada, dan pengulangan (repetition) memungkinkan untuk melakukan looping. Ketika konstruksi ini sangat penting dalam structured programming — sebagai sesuatu yang mendasar dalam teknik component-level design. Kontruksi-konstruksi terstruktur ini dimaksudkan untuk membatasi prosedural perancangan software menjadi bagian terkecil yang dapat diprediksi. Metrix kompleksitas menjelaskan bahwa penggunaan konstuksi terstruktur dapat mengurangi kerumitan suatu program sehingga program yang dibuat menjadi lebih readability, testability, and maintainability. Penggunaan konstruksi logikal yang lebih sedikit juga membantu manusia untuk lebih memahaminya yang dalam istilah phisikologi disebut dengan chunking. Untuk mempermudah pengertian tersebut, coba perhatikan cara anda membaca halaman ini. Anda tidak membacanya huruf per huruf namun dibaca per kata atau per kalimat. Konstruksi terstruktur adalah
sekumpulan logika yang memungkinkan pembacanya dapat mengenali elemen-elemen prosedur pada suatu modul, dibanding jika harus membaca kode baris per baris.
16.1.1 Graphical Design Notation
"Sebuah gambar setara dengan 1000 kata," namun perlu juga dilihat gambar yang mana dan 1000 kata yang mana. Tidak dapat dipungkiri lagi bahwa dengan media gambar seperti flowchart atau box diagram, dapat memberikan penjelasan prosedur secara lebih rinci. Namun demikian apabila gambar yang disajikan salah, maka akibatnya adalah software yang dibuat juga akan tidak sasuai.
(masih berlanjut...)
“Software ini berbeda dibanding dengan produk lain, dimana aturannya adalah semakin tinggi kualitas akan berdampak pada harga. Orang yang benar-benar ingin memperoleh software yang dapat diandalkan akan percaya bahwa mereka harus bisa menemukan suatu alat/cara untuk menghindari memulai suatu sistem dengan bug, dan hasilnya adalah, proses programming menjadi lebih murah . . . programmer efektif . . . tidak boleh menghabiskan waktunya untuk memperbaiki debugg—mereka seharusnya tidak boleh mengenalkan bug untuk memulai membuat suatu sistem.”
Walaupun kalimat di atas diucapkan beberapa tahun yang lalu, namun sampai saat ini masih terbukti benar. Ketika model design diterjemahkan ke dalam bentuk source code, kita harus mengikuti aturan prinsip design yang tidak hanya menterjemahkan namun, juga tidak boleh “mengenalkan bug untuk memulainya.”
SEKILAS MENGENAI COMPONENT-LEVEL DESIGN
Data, arsitektu, dan desain antarmuka harus diterjemahkan ke dalam software yang akan dibuat. Untuk menyelesaikannya, rancangan yang dibuat harus dapat dibaca dan dimengerti oleh sang programmer. Component-level design berbentuk rincian algoritma yang dibutuhkan untuk memanipulasi struktur data, komunikasi antara komponen software melalui antarmukanya, dan membuat algoritma untuk masing-masing komponen.
Siapa yang melakukannya? Software engineer.
Mengapa ini perlu dilakukan? Karena anda harus memastikan benar bahwa program tersebut dapat berjalan sebelum anda membangunnya. Component-level design merupakan rancangan software secara lebih terperinci yang dapat dipergunakan sebagai dokumen agar software yang dibuat tetap konsisten dan benar sesuai dengan perencanaan yang telah dibuat sebelumnya(misalnya data, arsitektur, dan desain antarmuka). Bisa juga digunakan sebagai alat untuk menguji apakah struktur data, interface, dan algoritmanya bisa berjalan sebagaimana mestinya.
Apa saja tahapannya? Merancang data, arsitektur, dan interface sebagai fondasi untuk component-level design. Proses analisa kebutuhan dari sumber user kemudian diterjemahkan ke dalam bentuk model procedural design bisa menggunakan bentuk grafik, tabular, atau tulisan text.
16.1 STRUCTURED PROGRAMMING
Component-level design ditemukan pada awal tahun 1960an kemudian disempurnakan kembali oleh Edsgar Dijkstra dan teman-temannya ([BOH66], [DIJ65], [DIJ76]). Pada akhir tahun 1960an, Dijkstra dan kawan-kawan memperkenalkan sekumpulan kontruksi logika yang dapat merubahnya menjadi sebuah bahasa pemrograman. Konstruksinya dititikberatkan pada "maintenance of functional domain." Oleh karena itulah, setiap konstruksi mempunyai struktur logika yang dapat diprediksikan, yang dimasukkan pada bagian awal statement dan ditutup dibagian bawah statement, sehingga pembaca dapat dengan mudah mengikuti alur prosedurnya.
Konstruksi merupakan urutan, kondisi dan pengulanan. Urutan (Sequence) menggambarkan langkah-langkah proses yang menentukan di dalam spesifikasi suatu algoritma.. Kondisi (Condition) untuk memilih proses berdasarkan beberapa logika yang ada, dan pengulangan (repetition) memungkinkan untuk melakukan looping. Ketika konstruksi ini sangat penting dalam structured programming — sebagai sesuatu yang mendasar dalam teknik component-level design. Kontruksi-konstruksi terstruktur ini dimaksudkan untuk membatasi prosedural perancangan software menjadi bagian terkecil yang dapat diprediksi. Metrix kompleksitas menjelaskan bahwa penggunaan konstuksi terstruktur dapat mengurangi kerumitan suatu program sehingga program yang dibuat menjadi lebih readability, testability, and maintainability. Penggunaan konstruksi logikal yang lebih sedikit juga membantu manusia untuk lebih memahaminya yang dalam istilah phisikologi disebut dengan chunking. Untuk mempermudah pengertian tersebut, coba perhatikan cara anda membaca halaman ini. Anda tidak membacanya huruf per huruf namun dibaca per kata atau per kalimat. Konstruksi terstruktur adalah
sekumpulan logika yang memungkinkan pembacanya dapat mengenali elemen-elemen prosedur pada suatu modul, dibanding jika harus membaca kode baris per baris.
16.1.1 Graphical Design Notation
"Sebuah gambar setara dengan 1000 kata," namun perlu juga dilihat gambar yang mana dan 1000 kata yang mana. Tidak dapat dipungkiri lagi bahwa dengan media gambar seperti flowchart atau box diagram, dapat memberikan penjelasan prosedur secara lebih rinci. Namun demikian apabila gambar yang disajikan salah, maka akibatnya adalah software yang dibuat juga akan tidak sasuai.
(masih berlanjut...)
Comments
My blog
My blog
My blog
My blog