Uygulamadan önce veya sonra Sınıf Diyagramları oluşturmalı mısınız?

Avantajı elde etmeden önce bir tane oluşturursanız, gördüğüm şekilde:

• İlerisini planlamak
• Projeye genel bakış

ama kaybedersin:

• Zaman (iş yaparken muhtemelen kod yazarken tekrarlanırsınız)

Öte yandan, sadece gelecekteki geliştiriciler için bir referans olarak tutmak için kodumu yazdıktan sonra hepsini oluşturabilirim.

Hangisi sınıf diyagramlarının amacına hizmet eder ve hangisi daha avantajlıdır?

Onları daha önce oluşturursanız, tasarım aşamasının bir parçası olurlar.

Bunları daha sonra oluşturursanız, bunları dokümantasyon için kullanabilirsiniz. Ancak bunu tasarım ve kodlama sırasında yaparsanız dokümantasyon daha iyi ve daha hızlı olur.

Bu arada, tasarım yaparken zaman kaybetmezsiniz! Kodlama kısmı daha hızlı olacaktır. Ve daha iyi.

Sonuçta, bir gökdelenin veya bir köprünün tasarımını yapmanın sadece inşa etmeye başlamak yerine zaman kaybı olduğunu mu düşünüyorsunuz?

Bir uzlaşma, tasarım aşamasında bazı kukla kodlar oluşturmaya başlamaktır (sadece sınıfların / işlevlerin prototipleri) ve sınıf şemalarını oluşturmak için bu kod iskeletini kullanmaktır.

Kodlamadan önce bunları oluşturduğumda, bunları "geçici" belgeler olarak görüyoruz. Yani, diyagramları yaratırız ve düşüncelerimizi kağıda dökürüz. Kodlamaya bu sınıf diyagramlarından başlıyoruz. Sonra onları dışarı atıyoruz. Kodlama başladıktan sonra onları korumak için zaman harcamaya değmez. Güncel sınıf modelleri istiyorsanız, bunları koddan oluşturmak için bir araç kullanın.

Her iki durumda da, belgelerin bir parçası olarak takılırlar. Uygulamada değişiklik yapıldığında kimse bunları güncellemeyecektir. Diyagramların üzerinde tarihler olmayacaktır, bu nedenle kodun hangi sürümüne başvurduklarını bile bilmeyeceksiniz. Projeye yeni bir kişi eklendiğinde ona "Tasarım veya uygulama sırasında bir noktada oluşturulan bazı diyagramlar. Ne kadar güncel olduklarını bilmiyoruz" diyen diyagramlar vereceksiniz.

Bu tasarımın bir parçasıdır ve bu nedenle uygulamadan önce oluşturulmalıdır. Bu, uygulama sırasında / sonrasında mevcut uygulamalar durumunu yansıtacak şekilde geliştirilemeyecekleri anlamına gelmez.

Uygulamadan sonra bir tasarım sağlamak, "kovboy kodlama" olarak adlandırdığım şeydir ve vahşi vahşi batıda başarılı olabileceğinizden emin olun, ancak kovboyların genellikle bir noktada veya sonunda öldüğünü unutmayın.

Tasarımın derinliğine bağlıdır. Bazı insanlar en önemsiz sınıflar için bile sınıf diyagramları yazmakta ısrar ediyorlar, çünkü “bu iyi bir uygulamadır”. Bence nasıl uygulanacağını tam olarak bildiğinizde bir şeyler çizmek zaman kaybı. Ne zaman oluşturarak yeni bir tasarıma, alışılmadık bir şeyi, ilk bazı diyagramlar çizmek kesinlikle yararlıdır.

UML araçlarını asla kullanmıyorum, çünkü tasarım genellikle uygulama sırasında çok fazla değişiyor, şemayı yeniden çizmem gerekiyor. İyi bir iki yönlü araç bu değişikliklerle başa çıkacaktı, ama asla iyi bir araç kullanmadım (sadece ücretsiz olanları kullandım). Bunun yerine, tasarıma göre sıralama yapmama yardımcı olmak için kağıda veya beyaz tahtaya çiziyorum. Uyguladıktan ve makul olduğundan emin olduktan sonra, daha resmi bir diyagram yapacağım.

Ayrıca, diğer diyagram türlerini de unutmayalım. Her zaman dizi diyagramlarını en kullanışlıları arasında buldum ve bileşenler arasında çok fazla iletişim olduğunda bunları sık sık kullanıyorum.

Uygulamadan Önce. Eski iş arkadaşlarımdan birinin bir zamanlar 'kodlamaya başlamadan önce mümkün olduğunca fazla programlama yapmaktan hoşlanıyorum' dediğine göre, bence bu iyi bir yaklaşım.

Bir diyagram çizme eyleminin genellikle beni eksik bilgiler konusunda uyardığını düşünüyorum. Bu, sadece şemayı çizmeden bir kod düzenleyicide yazıyorsam da olur, ancak örnekler daha da aralıklı olacaktır (çünkü algoritmaları ve hesaplamaları ve testleri ve benzeri yazma zaman harcayacağım) ve bu yüzden daha fazla zaman ayırabilirim eksik bilgilerimi almadan önce gidin.

Ayrıca, kafanızda belirsiz bir şekilde sahip olduğunuz tasarım bok gibi görünüyorsa, önce diyagram çizerseniz bunu daha hızlı fark edeceksiniz. Bu yüzden en azından hızlı ve gayri resmi bir şey çiziyorum. Başkalarının referans olarak kullanabileceği elektronik bir şemaya dönüşüp dönüşmeyeceği projeye bağlı olacaktır.

Sınıf diyagramı oluşturma işlemi sırasında ve sonrasında yapılmalıdır, çünkü model kod ve gereksinim değişiklikleri ile etkileşimli olmalıdır. Öncelikle projenizi başlatmak için bir sınıf diyagramı oluşturmanız gerekir. Nesnelerinizin daha yüksek bir soyutlama düzeyinde görselleştirmeye yardımcı olacaktır. İstikrarlı ve akıllı bir yazılım mimarisi oluşturabileceksiniz. Daha sonra kodlamanız gerekir ve bazen UML'de iyi görünen mimarinin kodda gerçekten mümkün olmadığını fark edersiniz. Daha sonra kod ve mimariyi değiştirirsiniz. Son olarak modelinizi kod değişikliği ile güncelleyip dokümantasyon oluşturuyorsunuz.

Son projemde karar vericiler geçen yıl gereksinimlerimi 50'den fazla değiştirdi. Gerçekten acı vericidir ve UML değişikliklerin izlenebilirliğini ve nedenini korumama yardımcı olur. UML, model ve kodun her zaman yinelemeli bir şekilde (örneğin koddan modele, modelden koda, her ikisinden, yeniden düzenleme sonrası koddan vb.) Herhangi bir zamanda izin vermelidir ... Helios için Omondo EclipseUML kullanıyorum ve gerçekten çok mutluyum bu araç. En sevdiğim özellik, model bilgilerimi kaybetmeden modelimi istediğim zaman güncellememi sağlayan model birleştirme. Ayrıca doğrudan sınıf diyagramında modelleme varlıkları gibi ve stereotip ve hazırda bekletme kullanarak veritabanı oluşturmak. Gerçekten güçlü ve nesneden veritabanına komple !!

Önce : düşüncelerinizin niyetinizi düzenlemesine ve iletmesine yardımcı olacaktır. Burada ayrıntılara girmeyin.

Sonra : açıkça, oluşturma işleminin bir parçası olarak koddan oluşturulur (uml, uml'ye çok fazla bağlı olmadığınızı umarız)

Her ikisi de faydalıdır, ancak önceki şeyler uygulandığı anda atılabilir ... zaten bu noktada zaten eskimiş.

Topcased ile tasarım aşamasında sınıf diyagramlarımı oluşturuyorum. Sonra benim uygulama bir tuval üretmek için "Kod oluştur" düğmesine tıklayın. Sonra yer tutucuları kodla dolduruyorum.

Cevap için oy vereceğim (C) Rahatsız etme.

Büyük ölçüde gereksizdirler. Şahsen, sağlandıklarında onlara bakmak için hiç uğraşmam.

Geliştirilmeden önce gereksizler, çünkü tasarım yine de değişecek. Ve sınıflarınızın tasarımının değişeceğini düşünmüyorsanız, zaten kendinizi kelepçeliyorsunuz ve gelecekteki kendinizin sorunu düzgün bir şekilde çözmesini önlüyorsunuz. Önceden var olan bazı sınıf diyagramlarına bağlı kalmanız gerektiğini düşünüyorsanız, ya NASA için çalışıyorsunuz ya da kendinizi ayağınızdan çekiyorsunuz.

Daha sonra, gereksiz belgelerdir. Sınıfların ne yaptığını veya küçük bir kod incelemesi ile birbirleriyle nasıl ilişkili olduklarını anlayamıyorsanız, beceri geliştiricinizde bir yazılım geliştiricisi olarak bir delik vardır.

Tabii ki, bu cevap gerçekten kibirli ve kibirli görünüyor; Oh iyi.

Eiffel ve ilişkili araçlarla bu, aynı temel dosyalara işaret eden bir bakış açısı farkıdır.