Arka plan: Ortak çalışanlarımız ve ben akademik bir dergi için bir makale yazıyoruz. Araştırmamız sırasında Java'da bir simülasyon programı yazdık. Simülasyon programını başkalarının kullanabileceği şekilde serbest bırakmak istiyoruz. Kodu bir GitHub deposunda barındırmaya karar verdik. Başkalarının kullanımını kolaylaştırmak için, programımız için aşağıdakiler de dahil olmak üzere iyi belgeler yazmak istiyoruz:

• Her sınıf ve yöntem için Javadoc'lar
• Kod nasıl kullanılır?
• Kodun üst düzey yapısını tanımlama

Üst düzey sorum şu: Bir programın üst düzey yapısını tanımlamak için kullanılabilecek kelimeler ve diyagramlara iyi bir örnek verebilir misiniz? Buna alt sorular da dahildir:

1. Hangi paketlerde hangi sınıfların bulunduğunu nasıl gösteririz?
2. Hangi paketlerin diğer paketlere bağlı olduğunu nasıl gösteririz?
3. Programdaki nesnelerin / sınıfların birlikte nasıl çalıştığını nasıl gösteririz?
4. Kodumun tasarımında alan güdümlü tasarım ilkelerini kullanmaya çalıştık . Etki alanındaki nesnelerle bu nesneleri kodlayan belirli kaynak kodu dosyaları arasındaki yazışmayı nasıl gösteririz? (Aşağıdaki projenin "her yerde bulunan dil" açıklamamı inceleyin.)

Şimdiye kadar ne yaptım

Her yerde kullanılan dil

Kodun bir dosyaya "her yerde bulunan dil" tanımını ubiquitous-language.md, içeriği aşağıda belirttik.

Bu projenin amacı, bir ikmal politikasının tek bir tesise sahip basit bir tedarik zincirinde farklı teslim süresi modelleri, gecikmeler ve talep modelleri altında nasıl bir performans gösterdiğini incelemektir.

Her dönemde aşağıdaki olaylar gerçekleşir:

1. Bir sevkiyatın tesise cari dönemde ulaşması planlanıyorsa, tesisin stok seviyesi X birimleri tarafından artırılır.
2. Eğer zamanlama cari dönem bir raporlama dönemi olduğunu belirtir, ardından tesisin bir gönderdiğinde raporu için satıcı . Tedarikçisi alabilirsiniz raporu tarafından belirtildiği şekilde, birkaç haftalık bir gecikme ile ya, anında zamanlama .
3. Eğer tedarikçi bir aldı raporu ardından dayalı ikmal politikası , bu X'in birimlerinin ikmal miktarını hesaplar. Ürünün X biriminin bir sevkıyatının , 1 dönemlik bir teslim süresinden sonra ulaşması planlanacaktır.
4. Müşteriler tesise gelir ve ürünün X birimini talep eder. Karşılanmayan talepler kaybolur.

Kaynak Kod Yapısı

structure.mdAşağıdaki içeriğe , bir dosyaya kodun eksik "üst düzey" açıklamasını koyuyoruz .

Paket Seviyesi Yapısı

En üst düzeyde, kaynak kodu üç paket halinde düzenlenmiştir

• com.gly.sfsmainYöntemi içeren ana sınıf bu pakette bulunur.
• com.gly.sfs.model Etki alanı modeli sınıfları bu pakette bulunur.
• com.gly.sfs.util Yardımcı sınıflar bu pakette bulunur.

Normalde , tarif ettiğiniz amaç için UML kullanırsınız. UML temel olarak iki tür diyagrama ayrılır: yapısal ve davranışsal.

Yapısal diyagramlar şunları içerir: kompozisyon, dağıtım, paket, sınıf, nesne ve bileşen. Davranışsal diyagramlar şunları içerir: dizi, durum makinesi, iletişim, kullanım durumu, etkinlik ve etkileşime genel bakış.

İletmeye çalıştığınız şeye bağlı olarak, iletmeye çalıştığınız şeyi en iyi temsil eden bu diyagramlardan birkaçını seçersiniz ve böylece konuşmanın "bir üst seviyeye çıkmasına" izin verirsiniz. Yöntemler, parametreler ve kod hakkında konuşmak yerine, etkileşim dizisi veya statik sınıf bağımlılıkları veya oluşturmayı seçtiğiniz diyagramlar hakkında konuşuyorsunuz.

Bir dizi diyagramı (davranış diyagramlarından biri) örneği ekledim. Şahsen sıra diyagramını seviyorum çünkü tasarım yapay işleminin tam ortasında - kabaca eşit sayıda diyagram girdi olarak beklendiği gibi ona bağlı. Girdi diyagramlarının tipik olarak zaten "anlaşıldığını" veya dizi diyagramının zaten varlığını ima ettiğini buluyorum. Ancak, bazen hem statik sınıf diyagramları hem de dizi diyagramları (bir yapısal ve bir davranışsal diyagram) yaparım.

http://omarfrancisco.com/wp-content/uploads/2011/07/sequencediagram.png

Bu diyagramı hayatımda daha önce hiç görmedim, ancak bu sistem hakkında birkaç şey söyleyebilirim. Dört ana bileşen vardır (sisteminizdeki isimler - genellikle sınıflar): Görünüm, Denetleyici, Veri Proxy'si ve Veri Sağlayıcı. Oklar "davranışlar" veya yöntem çağrılarıdır. Bir dizi diyagram temel olarak bir grup bileşen arasında tek bir önemli etkileşimi göstermek için iyidir. Sisteminizdeki her önemli akış için bir dizi diyagramınız vardır. Bu özel diyagramdan "Denetleyici" nin "phoneIsComplete ()" adlı bir yöntemi ortaya çıkardığını söyleyebilirim ki bu da DataProviderProxy'nin "lookupPhone ()" yöntemine bağlıdır ve bu da DataProvider'ın "lookupPhone ()" yöntemine bağlıdır.

Şimdi inliyor ve "uggg ... bu bana sistemin büyük bir resmini vermiyor - sadece sistem üzerinden bireysel etkileşimler" diye düşünebilirsiniz. Sistemin karmaşıklığına bağlı olarak, bu geçerli bir endişe kaynağı olabilir (basit sistemler kesinlikle sadece bir dizi şema koleksiyonu ile elde edilebilir). Yani, yapısal diyagramlara geçiyoruz ve statik sınıf diyagramı gibi bir şeye bakıyoruz:

http://www.f5systems.in/apnashoppe/education//img/chapters/uml_class_diagram.jpg

Sınıf diyagramları iki önemli şeyi anlamamıza yardımcı olur: kardinalite ve sınıf ilişkisi türleri. Sınıflar birbirleriyle farklı şekillerde ilişkilendirilebilir: ilişkilendirme, toplama ve kompozisyon. Teknik olarak konuşursak, "statik sınıf ilişkileri" ile "örnek ilişkileri" arasında bir fark vardır. Ancak pratikte bu çizgilerin bulanık olduğunu görüyorsunuz. Temel fark, statik sınıf ilişkilerinin genellikle kardinalite içermemesidir. Yukarıdaki örneğe bakalım ve neler görebilelim. İlk olarak, "Özel Sipariş" ve "Normal Sipariş" in "Siparişler" (miras) alt türleri olduğunu görebiliriz. Bir Müşterinin N Siparişi olduğunu da görebiliriz ("Normal Siparişler", "Siparişler" veya "Özel Siparişler" olabilir) - Müşteri nesnesi Gerçekten bilmiyorum. Ayrıca birkaç yöntem (her sınıf kutusunun alt yarısında) ve özellikleri (her sınıf kutusunun üst yarısında) görebiliriz.

UML diyagramlarından uzun süre bahsetmeye devam edebilirdim, ama bu temeller. Umarım bu yardımcı olur.

TLDR; Bir davranışsal ve bir yapısal UML diyagramı seçin, nasıl oluşturulacağını öğrenin ve başarmaya çalıştığınız şeyi başaracaksınız.

Programınızın üst düzey yapısının nasıl çalıştığı ve sınıfların birlikte nasıl çalıştığı gibi şeyleri açıklamakta zorluk çekiyorsanız, aşağıdaki özeti göz önünde bulundurun:

A picture is worth a thousand words.

Kodla ilgili bir resmi boyama şekliniz kod örnekleri sağlamaktır. Çoğu. Yeni bir müşteri (kod) bu şekilde oluşturulur. Bir siparişi bu şekilde işlersiniz (kod). Bu sadece kodunuzun tüketicisine başlamak için bir yer sağlamakla kalmaz, aynı zamanda tüm nesnelerin nasıl birbirine bağlandığını ve etkileşime girdiğini gösterir. Kodunuzu kullanıyordum, bana yapabileceğiniz en büyük iyilik, çok sayıda kod örneği sağlamaktır.

Son kullanıcı için bir resmi boyama şekliniz ekran görüntüleri sağlamaktır. Çoğu. Ekran görüntüsünden sonra ekran görüntüsü, bu görevi yapmak istiyorsanız, önce yaptığınız şey budur, bundan sonra yaptığınız şey budur.

UML, yazılım oluşturulmadan önce sıklıkla modellemek için kullanılırken, yararlı olabilir. Kullanım durumlarını, sınıf etkileşimlerini vb. Gösteren birkaç farklı diyagram vardır . Burada daha fazla bilgi görebilirsiniz .

Https://www.websequencediagrams.com/ adresini bir uygulamadaki bileşenler veya dağıtılmış bir uygulamadaki hizmetler arasındaki etkileşimi açıklamak için son derece kullanışlı bir araç olarak görüyorum . Sadece UML dizi diyagramlarını oluşturma ve sürdürme işlemini çok daha kolay hale getirir.

Güzel bir şey, eğer her yaşam çizgisini uygulamanızdaki arayüz veya sınıf olarak görüyorsanız (genellikle sadece büyük oyuncuları modelliyorum), o sınıfa akan her çizgi desteklemeniz gereken bir yöntemi temsil eder.

Ayrıca, görüntüyü almak için bazı indirme seçenekleri vardır. Diyagramı bir wiki'ye gömmenin bazı kolay yolları da vardır. Bu nedenle, bir sistemdeki bileşenler veya hizmetler arasındaki etkileşimi tanımlamak ve bunu ekiple iletişim kurmak için harika bir iletişim aracıdır.