Kodunuzun nasıl düzenleneceğini planlamak için UML diyagramlarını kullanmak neden uygunsuz?


9

Yani, evet, diyagramlar zaman zaman uygunsuz olabilir. Ne zaman uygunsuzlar? Onları doğrulamak için kod olmadan oluşturduğunuzda ve ardından bunları izlemeyi planladığınızda. Bir fikri keşfetmek için bir diyagram çizmenin yanlış bir yanı yoktur.

Çevik Yazılım Geliştirme: İlkeler, Desenler ve Uygulamalar - Robert C. Martin

Bununla tam olarak ne demek istiyor? UML , " dalmadan " önce kodunuzu nasıl yapılandıracağınızı planlamaya yardımcı olmak için tasarlanmamış mı ? Geldiğiniz diyagramlara uymazsanız bunu kullanmanın anlamı nedir?

Bağlam: Bu bölümde, Bob Amca bir Bowling oyununun Skor Kalecisi için bir UML diyagramı yapar. Daha sonra UML diyagramına danışmadan programı test odaklı bir şekilde geliştirmeye devam ediyor. Ortaya çıkan program UML diyagramına benzemez ve Bob Amca yukarıda alıntılanan sonuca gelir.


4
Bob Amca'nın amacı, Test Odaklı Geliştirme'den ortaya çıkan mimarinin UML diyagramından kökten farklı olabileceğidir.
Robert Harvey

1
Ayrıca tasarım ölü mü? Martin fowler tarafından bu konunun ve çevik hareketin dengeli bir tartışması için
Eliezer Steinbock

4
@RobertHarvey ve arkadaşlarının önemli ve faydalı bir soruyu kapatmak için oylamadaki zayıf yargısına yanıt olarak bu sorunun üstesinden gelinmesi.
David Arno

3
@DavidArno Nelerin kapatılması veya kapatılmaması gerektiği konusunda güçlü görüşleriniz varsa, meta sitemizdeki tartışmalara katılmanızı şiddetle tavsiye ederim. Şu anda orada bulunan (ben dahil) herkes birkaç SE çalışanı dışında muhtemelen "@RobertHarvey et al" altına giriyor ve temsil edilmeyen başka bir bakış açısı olduğundan endişe duyduk, ancak şimdiye kadar hiç kimse bunu temsil etmedi. .
Ixrec

1
@Ixrec, cevaplarda kendi açık kaynak kütüphanelerime başvurabildiğimi kontrol etmek için daha önce meta tartışmalarıyla hiç ilgilenmedim (bunun cevabı, yapabileceğimdi). Belki de tavsiyeni almalıyım ve daha fazla katılmalıyım. Önerin için teşekkürler.
David Arno

Yanıtlar:


19

Bunu doğru bir şekilde açıklamak için kısa bir tarih dersine ihtiyacımız var. Yazılım mühendisliğinin ilk günlerinde, sık kullanılan bir benzetme bir ev inşa etmekti. Bir mimar ve yapı mühendisi planları bir müşteriyle tartışır ve bir tasarım ortaya çıkarır. İnşaatçılar daha sonra gerçek evi inşa etmek için bu tasarımı takip ederler. Yazı kodu, gerçek evi inşa etmekle eşdeğer olarak görülüyordu. Bu nedenle, bu yapı gerçekleşmeden önce ön tasarım için algılanan bir ihtiyaç vardı. UML bunlardan biri olan çeşitli grafiksel tasarım araçları oluşturuldu.

Başlangıçta UML ile ilgili fikir, bir sistemin UML ile tamamen tasarlanması ve daha sonra bu tasarımı koda dönüştürmesi için kodlayıcılara teslim etmesi fikriydi. Gerçekte, bu işe yaramaz ve programcıların "tasarımcılar" yerine "uygulayıcılar" olarak görülmesine, projelerin geç kalmasına, tasarımların tamamlanması beklendikten sonra sürekli değişmek zorunda kalmasına neden olur.

Nedeni basit. Kodlama tasarımdır . Ev benzetmesi ile kod, mimarın çizimleri. Derleyici, bu tasarımları alan ve onlardan bir program oluşturan oluşturucudur. Bu gerçekleşme daha sonra çevik tekniklere, TDD vb. Doğmasına yol açtı: bu kod tasarımının kalitesini artırmaya yardımcı olan araçlar.

Bir mimarın, ekibinin ve ekibinin genel tasarımı görselleştirmesine yardımcı olmak için ön eskizler üretebilmesi gibi, bir geliştirici gerekli tasarımı görselleştirmeye yardımcı olmak için UML'yi veya diğer araçları kullanabilir. Bu eskizlerin körü körüne takip edilmemesi gibi UML'nin de körü körüne takip edilmemesi gerekir. Kod tasarımı çevik yinelemelerden ve TDD kullanarak gelişmelidir. Aynı şekilde, bir mimar gibi ve ekibinin çizimleri görselleştirmesine yardımcı olmak için evin bir modelini oluşturabilir, böylece UML kod yapısını görselleştirmek için kullanılabilir.

Bob Amca'nın dediği gibi, UML'yi doğrulayamazsınız, sadece kodu doğrulayabilirsiniz. Bu nedenle kod ana tasarım dokümanlarıdır ve eğer kullanılırsa UML sadece ikincil dokümantasyondur.


7
Bu yılın başlarında evimin çatısının bir bölümünü kaldırdım ve oldukça eğiticiydi. Mimar, artık nihai ürünün neye benzemesi gerektiğini çizecek bir şey yapmadı. Zor hesaplamaları ve yapısal tasarımı bir inşaat mühendisine verdi. İnşaatçılar daha sonra teorik tasarımları evin gerçekliğiyle eşleştirmek zorunda kaldılar (alçıpan kapandıktan sonra, kirişler biraz farklı yerlerde bulundu), bu nedenle tasarım her adımda gerçekleşiyordu.
Jaydee

1
Bu yararlı bir cevaptır, ancak yine de bazı yönleri basitleştirir. UML'nin "yüksek seviyeli tasarım gösterimi" olarak iyi çalışmamasının ana nedenlerinden biri, IMHO'nun mucitlerinin bir veri akış diyagramı eklemek için çok inatçı olmalarıdır. Bu, üst düzey tasarıma uygun olan, farklı bileşenler arasındaki bileşenler ve arayüzler için soyutlamaları ifade etmeyi sağlayan ve aynı zamanda kod için iyi tanımlanmış bir haritalamaya sahip olabileceğini bildiğim tek tür gösterimdir. Bunun yerine, UML, kimsenin gerçekten ihtiyaç duymadığı birçok saçmalık içeriyor.
Doc Brown

3

Her programlama deyiminin (veya tasarımın veya kodun) UML'ye uymadığını tahmin ediyorum (ki sadece birkaç kitap okuduğumu bilmiyorum - hiç kullanmadım ve muhtemelen beğenmedim).

Düz C kodu (örneğin Linux çekirdeğinin kaynak kodu) UML tarafından tam olarak modellenmemiş olabilir .

Ocaml kodu (modülleri ve işlevleri ile) veya hatta C ++ 11 kodu (lambdas ve şablonlarla) UML'ye sığmayabilir.

Çok aşamalı programlama à la MetaOcaml muhtemelen UML'ye uymuyor.

Prolog kodu veya Common Lisp kodu muhtemelen UML'ye uymuyor.

Ayrıca bu cevaba ve bu soruya da bakınız .

Scott'ın Programlama Dili Edimbilim ve Van Roy'un Kavramları, Teknikleri ve Bilgisayar Programlama Modelleri kitaplarını okuyun, sonra kendinize oradaki her programlama modelinin UML'ye uyup uymadığını sorun.

Ayrıca bakınız Martin Fowler'ın Tasarım Öldü mü? Blog.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.