Akış şeması ve Yöntem Çağrıları

Bazı akış şemaları yapıyorum ve buna doğru yaklaşıp yaklaşmadığımı merak ediyorum. Özünde, birkaç yöntem çağrım var ve her biri ayrı ayrı akış şeması oluşturuyorum. Ancak, bu yöntemlerden birkaçı bazı bilgiler için bir yöntem çağrısı yapar ve sonra devam eder. Bu örneğe bakın:

resim açıklamasını buraya girin

Ayrıca GetQueue () çağıran diğer 3 yöntem var ve bu doğru temsil mi merak ediyorum. AddQueue () akışı görsel olarak bozuk gibi görünüyor.

NOT: Akış çizelgemde yapılan değişiklikler:

resim açıklamasını buraya girin

flowchart

— Keith Barrows
kaynak

Bu resimsel ayrıntı düzeyi gerçekten gerekli mi? Bir keresinde, böyle bir akış şemasının popüler olduğunu biliyorum, ancak günümüzde birçok nedenden dolayı gözden düşmüş gibi görünüyorlar ... bunları güncel tutmanız gerekir ve kod zaten akış şemasında gösterilenleri zaten yeterince temsil etmelidir (yani: daha fazla kod üretmek için daha iyi zaman harcanır).

— Robert Harvey

Başka bir müşteriye geçmeden benden talep edildi.

— Keith Barrows

@Robert Harvey: Akış şemaları, insanların doğrudan makine veya montajcı kodu yazdığı eski günlerde yararlıydı. İyi bir kontrol yapıları dizisi olmayan erken FORTRAN ve BASIC programcıları için yararlı olabilirler. Günümüzde, onları yapmamın tek nedeni, bir müşterinin onları teslim edilebilir olarak istemesi ve bana yeterince ödemeye istekli olmasıydı.

— David Thornley

Bunları sıfırdan geliştirirken, kararlar için 90 dereceyi çevirerek sarı yapışkanlar kullanmanın çok yararlı olduğunu gördüm. Bu, onları hareket ettirmenizi ve aralarına işlemler eklemenizi sağlar. Hepiniz don olduğunuzda, bunları yazılımınıza girin.

— Michael Riley - AKA Gunny

Yine de arada sırada akış şemaları kullanıyorum, ancak birim testin genellikle aynı amaç için daha iyi olduğunu düşünüyorum. Yine de bunlar teslim edilemez; Onları kafamda bir kontrol akışı elde etmek için kullanıyorum.

— Michael K

Yanıtlar:

Bir kullan altprogram sembolü yöntemi çağrısı (önceden tanımlanmış süreci) için

resim açıklamasını buraya girin

— Robert Harvey
kaynak

Son zamanlarda bazı akış şemaları yaptım ve aynı sorunla, alt rutin çağrıları nasıl sunabileceğimizi veya belki de bugünlerde onları adlandırabileceğiniz gibi yöntem ve işlev çağrılarını zorladım.

Alt rutin ÇAĞRILAR'ı alt rutin REFERANSLAR'dan ayırdığım konvansiyona karar verdim. Birincisi için, program yürütmedeki o noktada geçerli olan değişkenleri kullanarak, yapılan argümanlarla çağrıyı gösteren sıradan bir dikdörtgen kullanıyorum.

Çift taraflı "önceden tanımlanmış işlem" dikdörtgeni basitçe bu işlevin veya alt rutinin tanımını içeren başka bir akış şemasına başvuru olarak kullanıyorum. Alt rutin dikdörtgenin, alt rutinin argümanlarını göstermesi gerekmez, çünkü bu, söz konusu alt rutinin tanımlayıcı akış şemasının bir parçasıdır, ancak bunları zaten okuyabilmesi için referansa eklemek yararlı olabilir. çağrıda kullanılan gerçek argümanların anlamlarına bakınız.

Bu, dikdörtgen sayısını arttırır, ancak bu diğer akış şemalarının, çağrılan işlevlerin bazılarının tanımını aramak için var olduğunu daha açık hale getirir. Genellikle bir işlev basitse, bunun için ayrı bir diyagram oluşturmayacağım, sadece sözlü olarak belgeleyeceğim.

Ayrıca ayrıntıların kod listesinden bakılması gerektiğini söylemek için "belge" sembolünü kullanıyorum.

Bir akış şemasının amacı bir program yaratmak değil, başkalarının bir programı anlamasını kolaylaştırmaktır. Bence kuş bakışı bir yardım ve bu amaç akılda tutulmalıdır. Programınızın HER ayrıntısını görsel olarak tanımlamak için değildir, ayrıntılar gerektiğinde koddan görülebilir. Akış şeması, programınızın üst düzey bakış açısından yalnızca bir resmi.

Akış şemalarını yüksek seviyede tutmak, kod değiştirildikçe bunların güncel tutulmasına daha az ihtiyaç olduğu anlamına gelir.

Onlar resim. İyi bir hikaye gibi yazılım belgelerinde de koda alternatif bir bakış açısı veren resimler olmalıdır.

— Panu Mantık
kaynak