Mengapa kita tidak dapat menangkap desain perangkat lunak dengan lebih efektif? [Tutup]

Sebagai insinyur, kita semua "merancang" artefak (bangunan, program, sirkuit, molekul ...). Itu adalah aktivitas (desain-kata kerja) yang menghasilkan semacam hasil (desain-kata benda).

Saya pikir kita semua sepakat bahwa desain-kata benda adalah entitas yang berbeda dari artefak itu sendiri.

Aktivitas utama dalam bisnis perangkat lunak (memang, dalam bisnis mana pun di mana artefak produk yang dihasilkan perlu ditingkatkan) adalah memahami "desain (kata benda)". Namun kita, sebagai sebuah komunitas, tampaknya gagal total dalam merekamnya, sebagaimana dibuktikan dengan banyaknya upaya yang dilakukan orang untuk menemukan kembali fakta-fakta tentang basis kode mereka. Minta seseorang untuk menunjukkan kepada Anda desain kode mereka dan lihat apa yang Anda dapatkan.

Saya pikir desain untuk perangkat lunak memiliki:

• Spesifikasi eksplisit untuk apa yang seharusnya dilakukan perangkat lunak dan seberapa baik melakukannya
• Versi eksplisit dari kode (bagian ini mudah, semua orang memilikinya)
• Penjelasan untuk bagaimana setiap bagian kode berfungsi untuk mencapai spesifikasi (misalnya, hubungan antara fragmen spesifikasi dan fragmen kode)
• Sebuah alasan mengapa kode adalah cara itu (misalnya, mengapa pilihan tertentu daripada yang lain)

Apa yang BUKAN desain adalah perspektif tertentu pada kode. Misalnya [tidak memilih secara khusus] diagram UML bukan desain. Sebaliknya, mereka adalah properti yang dapat Anda peroleh dari kode, atau bisa dibilang, properti yang Anda harapkan dapat berasal dari kode. Tetapi sebagai aturan umum, Anda tidak dapat memperoleh kode dari UML.

Mengapa setelah 50+ tahun membangun perangkat lunak, mengapa kita tidak memiliki cara reguler untuk mengekspresikan ini? (Jangan ragu untuk membantah saya dengan contoh-contoh eksplisit!)

Bahkan jika kita melakukannya, sebagian besar komunitas tampaknya sangat fokus pada mendapatkan "kode" sehingga desain-kata benda hilang pula. (IMHO, sampai desain menjadi tujuan rekayasa, dengan artefak diekstraksi dari desain, kita tidak akan menyiasati ini).

Apa yang Anda lihat sebagai sarana untuk merekam desain (dalam arti saya telah menggambarkannya)? Referensi eksplisit untuk makalah akan baik. Menurut Anda mengapa cara spesifik dan umum belum berhasil? Bagaimana kita bisa mengubahnya?

[Saya punya ide sendiri yang menyempurnakan sudut pandang di atas, tapi saya tertarik dengan jawaban orang lain ... dan sulit untuk mengimplementasikan skema saya [[dan mungkin itulah masalah sebenarnya: -]]]

EDIT 2011/1/3: Salah satu utas jawaban mengisyaratkan bahwa "dokumentasi" (mungkin tekstual, khususnya yang tidak formal) mungkin memadai. Saya kira saya harus mengklarifikasi bahwa saya tidak percaya ini. Alat CASE muncul di tempat kejadian mulai tahun 80-an, tetapi alat awal kebanyakan hanya menangkap piksel untuk diagram apa pun yang Anda gambar; sementara alat-alat itu bisa dibilang sukses secara komersial, mereka benar-benar tidak sangat membantu. Wawasan utama adalah, bahwa jika artefak "desain" tambahan tidak dapat ditafsirkan secara formal, Anda tidak dapat memperoleh bantuan alat yang serius. Saya percaya wawasan yang sama berlaku untuk setiap bentuk penangkapan desain yang berguna dalam jangka panjang: jika tidak memiliki struktur formal, itu tidak akan ada gunanya. Dokumen teks cukup gagal dalam tes ini.

Saya pikir ada beberapa alasan mengapa kita masih tidak pandai dalam hal ini.

1. Orang-orang untuk waktu yang lama meskipun perangkat lunak seperti rumah, dan menggunakan proses dan ide dari konstruksi. "Arsitek perangkat lunak" adalah judul yang diinginkan semua programmer. Selama sepuluh tahun terakhir, arsitek perangkat lunak hampir mati. Gagasan proses air terjun di mana Anda pertama kali memiliki arsitek yang mengatakan bagaimana perangkat lunak harus bekerja dan terlihat, dan kemudian membuat orang membuat diagram tentang bagaimana itu harus dibangun dan terakhir memiliki kode monyet yang mengimplementasikan alur kerja yang bagus ini / diagram UML untuk menentukan, ide ini adalah sekarang banyak diejek. Jadi sebenarnya, seluruh industri menggonggong ke jalur yang salah selama 40 tahun.

2. Alat yang kami gunakan selalu berubah dan ditingkatkan. Pemrograman adalah teka-teki logis, dan kami datang dengan ide-ide dan teknik yang lebih baik untuk abstrak teka-teki itu dan membuatnya dimengerti. Cara kita memodelkan ini harus berkembang pada kecepatan yang sama, tetapi masih tertinggal. Teknik yang ditingkatkan untuk abstrak teka-teki pemrograman juga berarti kita dapat meningkatkan kompleksitas. Dan begitulah yang kita lakukan. Pemrograman selalu terletak di tepi kompleksitas yang kita sebagai pemrogram dapat tangani.

3. Membuat cara untuk menggambarkan program adalah semacam abstraksi. Jika kita dapat menemukan cara yang bagus untuk mengabstraksikan perangkat lunak, kita juga bisa memasukkan abstraksi itu langsung ke alat pengembangan, dan karenanya menambahkan abstraksi / penyederhanaan lain ke pemrograman. Ini telah terjadi berulang kali. Contoh abstraksi tersebut adalah fungsi, kelas dan perpustakaan.

4. Karena itu; Jika Anda memiliki model perangkat lunak yang sukses dan akurat , model itu akan setara dengan perangkat lunak. Yang agak membuat seluruh upaya sia-sia, yang pada gilirannya menguatkan poin 1 di atas: Pemodelan perangkat lunak jauh lebih berguna daripada yang diperkirakan sebelumnya. Lebih baik mengekstrak data tentang perangkat lunak dari kode. Membuat model UML dari tampilan kode sebenarnya jauh lebih mencerahkan daripada membuat model UML dan mencoba menerapkan model teoretis itu.

Anda mungkin tertarik meninjau literatur penelusuran perangkat lunak. Tanpa urutan tertentu:

• CUBRANIC, D., MURPHY, GC, SINGER, J., DAN BOOTH KELLOGG, S. Hipikat: memori proyek untuk pengembangan perangkat lunak. Transaksi pada Rekayasa Perangkat Lunak 31, 6 (2005), 446-65.
• TANG, A., BABAR, MA, GORTON, I., DAN HAN, J. Sebuah survei penggunaan dan dokumentasi alasan desain arsitektur. Dalam Proc dari Konferensi IEEE / IFIP Kerja ke-5 tentang Arsitektur Perangkat Lunak (2005).
• RAMESH, B., POWERS, T., STUBBS, C., DAN EDWARDS, M. Menerapkan persyaratan keterlacakan: Sebuah studi kasus. Dalam Proc of the Int'l Symp on Requirements Engineering (York, 1995).
• HORNER, J., DAN ATWOOD, ME Rasional desain: rasional dan hambatan. Dalam Proc dari Konferensi Nordic ke-4 tentang Interaksi Manusia-Komputer: Mengubah Peran (Oslo, Norwegia, 2006).
• CLELAND-HUANG, J., SETTIMI, R., ROMANOVA, E., BERENBACH, B., DAN CLARK, S. Praktik terbaik untuk keterlacakan otomatis. Komputer 40, 6 (Juni 2007), 27–35.
• ASUNCION, H., FRANÇOIS, F., DAN TAYLOR, RN Alat penelusuran perangkat lunak industri end-to-end. Dalam Proc dari Pertemuan Gabungan ke-6 dari Konf Perangkat Lunak Eropa dan ACM SIGSOFT Int'l Symp tentang Yayasan Rekayasa Perangkat Lunak (ESEC / FSE) (Dubrovnik, 2007).

Perhatikan bahwa ini hanyalah puncak gunung es, dan saya yakin saya telah meninggalkan beberapa dokumen penting.

Pada catatan terpisah, pekerjaan saya sendiri di Arcum adalah sarana bagi pemrogram untuk mengekspresikan kepada IDE penggunaan idiom desain crosscutting. Setelah diekspresikan, programmer kemudian dapat mengubah kode sumber mereka untuk menggunakan implementasi alternatif:

• Macneil Shonle, William G. Griswold, dan Sorin Lerner. Beyond refactoring: kerangka kerja untuk pemeliharaan modular dari idiom desain crosscutting . Dalam Prosiding Pertemuan Gabungan ke-6 Konferensi Rekayasa Perangkat Lunak Eropa dan Simposium ACM SIGSOFT tentang Fondasi Rekayasa Perangkat Lunak (ESEC-FSE '07; 3-7 September 2007). 175-184.

Kebetulan, Arcum juga terkait dengan pekerjaan DMS Anda.

UML adalah untuk program apa rencananya untuk bangunan dalam pandangan saya yang rendah hati. Rencana saja bukan desain tentunya, Anda memerlukan spesifikasi bahan (alat kode yang digunakan) untuk itu, pandangan umum bangunan (beberapa representasi skematis dari seluruh perangkat lunak, termasuk desain GUI), bagaimana bangunan ditanam di sekitarnya (skema yang jelas tentang bagaimana perangkat lunak berinteraksi dengan orang lain / ditanam di dalam OS), bagaimana berdiri dengan iklim dan tanah (interaksi dengan perangkat keras), ... Banyak buku tentang desain mencoba untuk mendefinisikannya, tetapi seperti begitu banyak hal dalam sains, setiap ilmuwan memiliki sedikit definisi sendiri.

Sekarang, saya juga tidak setuju dengan pengamatan Anda bahwa Anda tidak dapat memperoleh kode dari UML. Anda dapat, jika Anda memiliki informasi tambahan yang disebutkan. Tetapi kode sebenarnya bukan desain lagi, itu artefak. Anda juga tidak dapat mengekstraksi batu dan beton asli dari rencana, tetapi Anda membutuhkan rencana untuk meletakkan batu dan beton asli dalam bentuk dan tempat yang benar.

Dalam terang itu, saya menemukan artikel berikut yang menarik (saya bertemu dalam konteks yang berbeda ketika saya sedang mencari perangkat lunak grafik, tetapi tetap saja ...). Pendekatan grafik untuk mendeskripsikan desain masuk akal bagi saya, walaupun - lagi - ini hanya bagian dari desain menurut saya. Hal yang menarik adalah bahwa pendekatan ini memberikan kerangka kerja untuk memahami dan mereformasi desain (sebagai lawan refactor perangkat lunak), seperti yang ditunjukkan dalam makalah berikut:

• Wermelinger dan Fiadeiro

• Tsantalis et al

Ada banyak pendekatan lain untuk menggambarkan (bagian dari) desain, seperti desain terstruktur (HIPO Charts) atau desain program terintegrasi , pola desain , ...

Namun, selama tidak ada standar industri yang ditetapkan, tidak mungkin untuk mendapatkan cara "biasa" untuk mengekspresikan ini. Bahkan setelah 50+ tahun. Dan jujur, jika perusahaan Anda menemukan cara yang baik untuk mengekspresikan desain, apakah Anda akan membagikannya kepada dunia?

Dari pengalaman pribadi saya, saya berpendapat bahwa kita baik menangkap desain perangkat lunak. Kami memiliki database dokumen persyaratan dan desain untuk setiap fitur tunggal yang pernah kami terapkan pada platform kami. Saya kira keadaan saya mungkin unik. Berikut adalah beberapa hal yang perlu dipikirkan.

Setiap orang di tim saya memiliki gelar teknik ... sebagian besar EE atau CE. Rekayasa mengajarkan Anda desain sebagai bagian dari kurikulum.

Saya pikir ada banyak yang disebut insinyur perangkat lunak yang berasal dari latar belakang CS. Desain perangkat lunak bukan bagian integral dari sebagian besar program CS. Saya tidak mengatakan bahwa semua jurusan CS buruk dalam hal desain, tetapi saya berani bertaruh bahwa sebagian besar tidak memiliki pendidikan formal yang mengajarkannya. Saya pikir banyak orang berasumsi bahwa jika Anda dapat memprogram Anda dapat merancang perangkat lunak, yang tidak benar. Mengingat bahwa banyak programmer tidak memiliki latar belakang teknik, tidak terlalu mengejutkan bahwa banyak proyek perangkat lunak tidak memiliki tim yang pandai menangkap desain.

Saya melihat dua masalah.

Yang pertama adalah bahwa sangat sulit untuk menjaga sinkronisasi kode dan dokumentasi. Jika mereka terpisah, mereka akan berbeda dan dokumentasi akan menjadi tidak berguna. Pemrogram telah mencoba menggunakan alat untuk melakukan pekerjaan menjaga mereka tetap sinkron (seperti alat KASUS), tetapi alat ini didapat antara pemrogram dan kode mereka, yang melakukan lebih banyak kerusakan daripada kebaikan. Salah satu wawasan kunci dari desain berbasis domain (Evans, 2004) adalah bahwa desain yang baik sangat sulit, jadi untuk mendapatkan sesuatu dari itu, Anda harus:

• pilih area sekecil mungkin dari program Anda di mana desain yang baik akan menghasilkan manfaat besar, yang disebut domain inti
• bekerja sangat keras untuk mendapatkan desain yang bagus dalam bentuk bahasa di mana-mana yang semua anggota tim gunakan sepanjang waktu
• sebisa mungkin, buat bagian desain kode

Masalah besar lainnya dengan cara kita melakukan desain, adalah bahwa metode-desain kita tidak cukup matematis. Abstraksi yang bocor tidak memungkinkan mereka untuk mendapatkan kesimpulan yang kuat dari mereka, dan dunia logika yang diterapkan secara ketat dan kebenaran yang jelas disebut matematika, yang sebagian besar programmer hindari.

Beberapa alat matematika yang kita miliki, seperti metode formal, sangat sulit digunakan.

Mengurangi peta adalah contoh matematika yang bagus dalam pemrograman. Ide intinya adalah ini: Ketika Anda memiliki operasi biner asosiatif, Anda dapat mendistribusikan eksekusi dengan sangat mudah. Operasi biner adalah fungsi dengan dua parameter, asosiasi menunjukkan bahwa (a + b) + c = a + (b + c)

a1 + a2 + ... + a99 + b1 + b2 + ... + b99 + c1 + c2 + ... + c99 adalah

(a1 + a2 + ... + a99) + (b1 + b2 + ... + b99) + (c1 + c2 + ... + c99) di mana As, B, dan Cs secara sepele dapat ditambahkan secara sepele pada lokasi yang berbeda, hasilnya dikumpulkan dan diringkas dalam waktu singkat.

Pengurangan peta adalah ide yang sangat sederhana. Itu bisa dijelaskan di selembar kertas. Jika Anda dapat berasumsi bahwa pembaca memiliki pemahaman yang kuat tentang konsep asosiatif, jika cocok dengan selembar kertas yang cukup kecil. Sekarang coba jelaskan pengurangan peta kepada seseorang tanpa menggunakan istilah associativity atau merujuknya secara tidak langsung. Saya menantang Anda.

Desain perangkat lunak tanpa abstraksi matematika seperti mencoba melakukan arsitektur tanpa harus bersusah payah mempelajari geometri.

Mungkin Haskell dapat memperbaikinya seiring waktu. Penggunaan konsep dari teori kategori untuk menggambarkan program terlihat menjanjikan bagi saya. Teori kategori sangat abstrak sehingga bahkan matematikawan tidak banyak menggunakannya, tetapi rupanya kategori, yang abstrak di luar pengakuan, tampaknya cukup abstrak untuk menggambarkan struktur perangkat lunak. Kami akan mencari tahu. Perlahan.