Flowcharting dan Metode Panggilan


11

Saya melakukan beberapa diagram alur dan bertanya-tanya apakah saya mendekati ini dengan benar. Intinya, saya memiliki beberapa pemanggilan metode dan saya masing-masing flowchart secara terpisah. Namun, beberapa metode ini membuat panggilan metode untuk beberapa info dan kemudian melanjutkan. Lihat contoh ini:

masukkan deskripsi gambar di sini

Saya memiliki 3 metode lain yang juga memanggil GetQueue () dan saya bertanya-tanya apakah saya mewakili ini dengan benar. Aliran AddQueue () secara visual sepertinya rusak.

CATATAN: Perubahan yang dibuat dalam diagram alur saya:

masukkan deskripsi gambar di sini


Apakah level detail gambar ini benar-benar diperlukan? Saya tahu bahwa, pada satu waktu, diagram alur seperti ini sangat populer, tetapi mereka tampaknya tidak disukai lagi sekarang karena berbagai alasan ... Pada dasarnya mereka adalah bentuk dokumentasi yang berlebihan; Anda harus tetap memperbaruinya, dan kode tersebut harus sudah cukup mewakili apa yang ditampilkan dalam diagram alur (artinya: waktu lebih baik dihabiskan untuk menghasilkan lebih banyak kode).
Robert Harvey

Itu diminta dari saya sebelum saya pindah ke klien lain.
Keith Barrows

@Robert Harvey: Diagram alir berguna di masa lalu, ketika orang menulis kode mesin atau assembler secara langsung. Mereka mungkin berguna bagi programmer FORTRAN dan BASIC awal, yang tidak memiliki susunan struktur kontrol yang baik. Saat ini, yah, satu-satunya alasan saya melakukannya adalah jika klien menginginkannya sebagai barang yang dapat dikirim dan bersedia membayar saya secara memadai.
David Thornley

Ketika mengembangkan ini dari awal, saya merasa sangat membantu menggunakan perekat kuning, memutar 90 derajat untuk mengambil keputusan. Ini memungkinkan Anda memindahkannya dan menyisipkan proses di antara. Ketika Anda semua don, maka masukkan ke dalam perangkat lunak Anda.
Michael Riley - AKA Gunny

Saya masih menggunakan diagram alur sesekali, meskipun saya menemukan unit test sering lebih baik untuk tujuan yang sama. Mereka bukan kiriman, meskipun; Saya menggunakannya untuk mendapatkan aliran kontrol tepat di kepala saya.
Michael K

Jawaban:



2

Saya baru-baru ini melakukan beberapa diagram alur dan berjuang dengan masalah yang sama, bagaimana menyajikan panggilan subrutin, atau mungkin metode dan fungsi-panggilan seperti yang Anda sebut hari ini.

Saya memutuskan pada konvensi bahwa saya memisahkan PANGGILAN subrutin dari REFERENSI subrutin. Untuk yang pertama saya menggunakan kotak biasa menunjukkan panggilan dengan argumen yang dibuat, menggunakan variabel apa pun yang berlaku pada saat itu dalam eksekusi program.

Saya menggunakan persegi panjang "proses yang telah ditentukan" dua sisi hanya sebagai referensi ke diagram alur lain yang berisi definisi fungsi atau sub-rutin. Persegi panjang sub-rutin tidak perlu menunjukkan argumen sub-rutin karena itu adalah bagian dari diagram alir dari sub-rutin yang dimaksud, tetapi mungkin bermanfaat untuk menambahkannya dalam referensi sudah jadi siapa pun yang membacanya dapat lihat arti argumen aktual yang digunakan dalam panggilan.

Ini meningkatkan jumlah persegi panjang tetapi membuatnya lebih jelas bahwa diagram alur lain ada untuk mencari definisi dari beberapa fungsi yang dipanggil. Seringkali jika suatu fungsi sederhana, saya tidak akan membuat diagram terpisah untuk itu tetapi hanya mendokumentasikannya secara lisan.

Saya juga menggunakan simbol "dokumen" untuk mengatakan bahwa detail harus dilihat dari daftar kode.

Maksud dari diagram alur bagi saya bukanlah untuk membuat program, tetapi untuk membuatnya lebih mudah bagi orang lain untuk memahami suatu program. Saya pikir bantuan itu sebagai pandangan mata burung dan tujuan mereka harus selalu diingat. Mereka bukan untuk menggambarkan secara visual SETIAP detail program Anda, detail terlihat dari kode bila diperlukan. Diagram alir hanyalah satu gambar program Anda dari sudut pandang tingkat tinggi.

Menjaga bagan alur tingkat tinggi juga berarti ada sedikit kebutuhan untuk menjaga mereka tetap up-to-date karena kode dimodifikasi.

Itu adalah gambar. Seperti halnya dokumentasi perangkat lunak cerita bagus harus memiliki gambar juga yang memberikan sudut pandang alternatif untuk kode.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.