Desain perangkat lunak dengan pseudocoding?

Apakah Anda tahu cara yang baik untuk merancang (mis. Menulis) perangkat lunak dengan metode berdasarkan pseudocode?

Saya baru mengenal desain perangkat lunak dan membaca beberapa informasi tentang UML. Hirarki kelas saya yang sederhana sejauh ini bagus, namun, setelah menjadi kompleks, saya perhatikan bahwa dengan gambar "melihat keseluruhan" saya bisa menggunakan struktur yang berbeda untuk perpanjangan masa depan. Karena Python baik untuk membuat prototipe, saya hampir baik-baik saja dengan hanya mulai menulis, tetapi tidak cukup.

Jadi saya mencoba diagram kelas UML, tetapi mereka sepertinya tidak banyak membantu saya. Masalah yang saya selesaikan di sana bisa saya lakukan sepele di kepala saya. Tetapi saya memperhatikan persyaratan desain tambahan begitu saya mulai mengkode metode yang sebenarnya.

Jadi jika Anda ingin mendesain dengan pseudocode, bagaimana Anda melakukannya? Saya percaya bagi saya metode yang kira-kira 1-ke-1 dengan kode berfungsi paling baik. Tetapi sebagian besar perangkat lunak UML bahkan tidak menunjukkan kode metode (tidak seperti gambar di misalnya GoF).

Seseorang mengklaim UML hanya untuk dokumentasi dan presentasi dan tidak terlalu bagus untuk desain? Saya juga mendapatkan perasaan itu. Saya pikir UML murni dan beberapa sketsa papan tulis sederhana adalah cara untuk merancang perangkat lunak sampai googling saya menemukan Envision APDT.

Jadi, apakah pengembangan tangkas adalah sesuatu yang harus saya perhatikan atau mereka secara acak menyebutnya tangkas - saya pikir tangkas hanya tentang jadwal? Atau apakah saya salah mendesain (dengan UML) - apakah ada yang mendesain dengan pseudocode? Bagaimana saya bisa menemukan alat yang bagus untuk itu?

 I thought agile is about schedule only?

Ini bukan hanya perencanaan. Pengembangan perangkat lunak tangkas lebih lanjut tentang menjadi pengembangan evolusi dan pengiriman berulang waktu dengan perencanaan adaptif yang mendorong respons fleksibel terhadap perubahan yang diminta oleh pemilik produk.

 Or am I designing incorrectly (with UML) - does anyone design by pseudocode? 

Dalam pengalaman saya, bagan jauh lebih mudah dipahami dari sudut pandang stand klien. Mereka menarik secara visual dan sering kali sangat berwarna dan mudah diikuti. Namun, sangat sulit untuk mempertahankan grafik karena sifat pemutusan dengan kode aplikasi yang sebenarnya. Setiap kali perubahan dilakukan dalam aplikasi, pengembang harus meluangkan waktu untuk memperbarui semua dokumentasi termasuk grafik. Namun, masalah itu dapat dengan mudah dihilangkan begitu ada BA di tim atau perusahaan, yang memahami proses bisnis klien dengan baik dan dapat mengelola diagram UML.

Alat seperti UML dapat membuat proses ini lebih mudah tetapi hanya berfungsi dengan baik dengan pemrograman berorientasi objek. Kode semu jauh lebih mudah untuk tim teknis. Proses pembuatan kode ini sangat meningkatkan kecepatan fase pengembangan bahasa pemrograman yang sebenarnya.

Ada beberapa alternatif lain yang mungkin Anda perhatikan:

• Diagram Alir Data
• State Diagram
• Diagram Alir Proses

Referensi yang bagus untuk dilihat: Tutorial Desain Perangkat Lunak . Selain itu, saya pribadi akan menyarankan untuk membaca blog yang bagus di Pseudocode atau Code? diposting oleh Coding Horror - blog favorit saya untuk dibaca :)

Secara keseluruhan, ada beberapa trade-off yang perlu Anda pertimbangkan.

Saat pemrograman dalam bahasa assembly, menulis pseudo-code sangat masuk akal. Algoritme dapat diverifikasi sebelum mengeluarkan upaya untuk menerjemahkannya secara manual ke bahasa assembly dan kemudian debug terjemahan. Masih masuk akal untuk bahasa yang dikompilasi generasi pertama seperti FORTRAN IV, di mana satu-satunya konstruk kontrol adalah GOTO, semua variabel (kecuali argumen formal) bersifat global, dan nama variabel dibatasi hingga enam karakter.

Hari ini kami melakukan sangat sedikit pemrograman dalam bahasa assembly, dan saya melihat sedikit nilai dalam menulis pseudo-code daripada hanya menulis kode. Dalam bahasa yang layak, kode aktual akan mengikuti kode semu hampir kata demi kata, dan kode semu hanya membuang-buang waktu.

Namun, saya tidak memulai pengkodean di bagian bawah. Saya mengikuti TDD dan mulai dengan tes. Kemudian saya mulai coding di bagian atas, dan secara bertahap bekerja ke bawah sesuai kebutuhan untuk mendapatkan tes untuk lulus.

Alternatif untuk pseudo-code bukanlah menulis 1000 baris kelas tingkat rendah. Alih-alih mulai dari atas, panggil API yang ideal tetapi tidak ada untuk domain Anda. Kemudian bangun API.

Saya menemukan diagram kelas hampir tidak sepadan dengan usaha, bahkan ketika Anda melewatkan daftar semua metode dan hanya menunjukkan hierarki warisan. Sequence diagram itu baik, tetapi merasa canggung ketika saya menggambar mereka (mungkin hanya saya).

Saya menemukan diagram alir data dan bagan struktur menjadi lebih berguna (meskipun bagan struktur umumnya terkait dengan BDUF dan karena itu tidak disukai saat ini). DFD sangat berguna untuk dekomposisi fungsional. Setiap "gelembung" dalam DFD dapat dipecah menjadi DFD sendiri hingga Anda mencapai tingkat detail apa pun yang Anda inginkan.

Saya pikir alat grafis lebih baik daripada pseudocoding, tetapi UML sangat rumit sehingga menggabungkan yang buruk dalam metode tersebut :-)

Untuk menjadi lebih jelas: Saya pikir pemrograman sebagian besar merupakan cara untuk menganalisis masalah tertentu, pisahkan untuk komponen yang lebih kecil dan interaksinya. Ini adalah "perjalanan, bukan tujuan", Anda terus meningkatkan pengetahuan Anda tentang masalahnya, sehingga grafik komponen berubah: lapisan muncul dan menghilang, fungsi dan item data bergerak naik dan turun, dll.

Alat alami untuk mengikuti proses ini adalah sketsa, sesederhana mungkin, tetapi cukup kompleks untuk membantu pemahaman cepat (warna, bentuk, panah yang sama untuk makna logis yang sama). Saya belum menemukan peluru perak, dan mungkin suatu hari saya akan menulis sendiri, tetapi sekarang saya menggunakan gliffy ; dikombinasikan dengan fitur zoom prezi itu akan hampir sempurna.

Kenapa tidak pseudocoding? Pseudocoding adalah satu langkah maju untuk implementasi, "bentuk serial dari komponen grafik", ketika Anda belum membentuk ide-ide Anda. Tidak bagus, batasi kepala Anda. Dalam pengalaman saya, saya menemukan bahwa semakin saya mulai coding, semakin sedikit kode yang harus saya buang ...

Tapi mungkin ini karena saya telah menulis semua kode yang dibuang, jadi saya tidak harus menulisnya sekarang, pengalaman yang saya dapatkan dari mereka adalah dengan saya ketika mendesain sistem? Yah, saya harus mengubah pernyataan itu.

Jika Anda hilang dengan grafik Anda, dan melihat banyak solusi setara yang mungkin, pergi ke pseudocode, atau bahkan menulis kode itu dengan benda tiruan - di Jawa, itu hampir tidak ada perbedaan. Lihat kode, rasakan struktur dan kegunaan komponen-komponen itu, ini akan membantu Anda memperbaiki grafik Anda dan membuat keputusan. Tapi ini HANYA berfungsi jika Anda siap untuk membuang kode itu jika Anda merasa itu buruk. Saya pikir ini adalah keuntungan dari pseudocode: semakin sedikit godaan untuk menyimpannya ketika bekerja, tetapi itu salah dalam struktur (dan seperti biasa, Anda tidak punya cukup waktu). :-)