Yazılım sistemlerini modellemenin ve hepsini kodda yapmanın faydaları nelerdir?

Çoğu, tanıdığım tüm BT insanları değilse, kodlamadan önce UML veya diğer diyagram türleriyle yazılım modellemenin yararlı olduğuna inanıyorlar. (Sorum özellikle UML ile ilgili değil, yazılım tasarımının herhangi bir grafik veya metinsel açıklaması olabilir.)

Bundan pek emin değilim. Temel nedeni: Kod yalan söylemez. Derleyici veya yorumlayıcı tarafından kontrol edilir. Umarım otomatik testlere sahiptir ve statik kod analizini geçmesi gerekir. Bir modül başka bir modülle doğru şekilde arabirim oluşturmazsa, hata mesajı aldığınız için genellikle kodda açıkça görülür.

Tüm bunlar diyagramlar ve diğer belgelerle yapılamaz. Evet, UML'yi kontrol eden araçlar var, ancak şimdiye kadar gördüğüm her şey çok sınırlı. Bu nedenle, bu belgeler eksik, tutarsız veya basit yanlış olma eğilimindedir.

Diyagramların kendileri tutarlı olsa bile, kodun gerçekte bunları uyguladığından emin olamazsınız. Evet, kod üreteçleri vardır, ancak hiçbir zaman kodu üretmezler.

Bazen, kodlamanın kaçınılmaz olarak, büyük resmi elde eden mimarların, tasarımcıların veya diğer iyi ücretli insanların uğraşmaması gereken anlaşılmaz bir karışıklık olması gerektiği varsayımından kaynaklanan modelleme saplantısı gibi hissediyorum. Aksi takdirde çok pahalı olurdu. Bu nedenle, tüm tasarım kararları koddan uzaklaştırılmalıdır. Kodun kendisi, onu yazabilen (ve belki de okuyabilen) ancak başka bir şeyle uğraşmak zorunda olmayan uzmanlara (kod maymunları) bırakılmalıdır. Montajcı tek seçenek olduğunda bu muhtemelen mantıklıydı, ancak modern diller çok yüksek bir soyutlama düzeyinde kod yazmanıza izin veriyor. Bu yüzden artık modelleme ihtiyacını gerçekten görmüyorum.

Yazılım sistemlerini modellemek için hangi argümanları kaçırıyorum?

Bu arada, diyagramların yazılım tasarımının belirli yönlerini belgelemek ve iletmek için harika bir yol olduğuna inanıyorum, ancak bu, yazılım tasarımını bunlara dayandırmamız gerektiği anlamına gelmez .

Açıklama:

Soru belirsiz olarak askıya alındı. Bu yüzden biraz açıklama yapmama izin verin:

Yazılımı yazılım tasarımı ile ilgili gerçeğin ana kaynağı olarak modelleyen (kodsuz) belgeleri kullanmanın mantıklı olup olmadığını soruyorum. Kodun önemli bir kısmı bu belgelerden otomatik olarak oluşturulduğu durumda yok. Durum böyleyse, belgelerin kendilerini model olarak değil kaynak kod olarak kabul ederdim.

Bu prosedürün dezavantajlarını, neden bu kadar çok insanın (deneyimlerime göre) yazılım tasarımı yapmanın tercih edilen yolu olarak düşündüğünü merak etmemi sağladım.

Kodlamada yazılım sistemlerini modellemenin yararı: Modeli beyaz tahtaya sığdırabilirim.

Ben bir kağıt üzerinde iletişim kurma büyüsüne inanıyorum. Beyaz tahtaya kod koymaya çalışsaydım, sistemimize yeni kodlayıcılara öğretirken, beyaz tahtaya uyan gerekli soyutlama düzeyinde herhangi bir kod yoktur.

Bahsettiğiniz modelleme takıntısını biliyorum. İnsanlar bir şeyler yapıyor, çünkü neden yaptıklarını düşünmeden daha önce böyle yapılıyorlardı. Ben buna formalizm diyorum. Gayri resmi çalışmayı tercih ederim çünkü geleneklerin arkasındaki saçmalıkları gizlemek daha zordur.

Bu, arada sırada bir UML taslağını kırmayacağım anlamına gelmez. Ama asla kod yazmadan önce bir UML belgesini açmanızı talep eden kişi olmayacağım. 5 dakika sürmenizi ve ne yaptığınızı açıklamak için BAZI bir yol bulmanızı isteyebilirim, çünkü sadece bir kişinin anladığı kodun varlığına dayanamıyorum.

Fowler, insanların UML modlarını kullandığı UML'yi farklı şekillerde tanımladı . Hepsiyle ilgili tehlikeli olan şey, yararlı işler yapmaktan saklanmak için kullanılabilmeleridir. Eğer fareyi kullanarak kodlama yapıyorsanız, birçok deneme gördüm. Kimsenin gerçekten işe yaradığını görmedim. İletişim kurmak için yapıyorsanız, başkalarının sizi anladığından emin olmalısınız. Eğer bunu tasarlamak için yapıyorsanız, çalışırken problemleri bulmak ve düzeltmek daha iyidir. Her şey yolunda giderse ve zamanınızın çoğu okların güzel görünmesi için harcanıyorsa, onu kapatın ve işe geri dönün.

En önemlisi, bir günden fazla geçerli olmasını beklediğiniz diyagramlar üretmeyin. Eğer bir şekilde yapabilirsen, başarısız oldun. Çünkü yazılım yumuşak olmalı. Diyagramları doğru yapmak için haftalar harcamayın. Bana neler olduğunu anlat. Gerekirse, bir peçete kullanın.

Bununla birlikte, UML'lerini ve tasarım modellerini bilen kodlayıcıları tercih ediyorum. İletişim kurmak daha kolay. Diyagram üretmenin tam zamanlı bir iş olmadığını bildikleri sürece.

Yazılımı yazılım tasarımı ile ilgili gerçeğin ana kaynağı olarak modelleyen (kodsuz) belgeleri kullanmanın mantıklı olup olmadığını soruyorum

Hayır. Bu hiç mantıklı değil. Kodunuz birincil tasarım belgenizdir, yani "yazılım tasarımı ile ilgili gerçeğin birincil kaynağı". Yalnızca kod, derleyici bu tasarımı aldığında ve uygulamayı kendisinden oluştururken uygulamanın tam olarak ne yaptığını açıklar.

Tabii ki, ek tasarım belgeleri olarak diyagramları kullanın, ancak koddan otomatik olarak oluşturulmamışlarsa, gerçek tasarıma farklı bir hikaye anlatmalarına dikkat edin. UML teknenizi yüzüyorsa kullanın. Değilse, başka bir şey kullanın.

Bazı insanlar kod yazmaya başlamadan önce düşüncelerini şema formunda çizmeyi yararlı bulmaktadır. Ama Bob Amca'nın bu konuda söylediklerini hatırlayın:

" Evet, şemalar zaman zaman uygunsuz olabilir. Ne zaman uygunsuzlar? Onları doğrulamak için kod olmadan oluşturduktan sonra onları takip etmek istediğinizde. Bir fikri keşfetmek için bir şema çizerken yanlış bir şey yoktur. "

Bir tasarımı keşfetmek için UML'yi kullanırsanız, kodlamaya başladığınızda bunları atın. Bir test yazın, ardından geçmesi için bir kod yazın. Tekrar et. Bu şekilde, onaylanmış bir tasarım elde edersiniz. UML size tasarımınızın aynı düzeyde doğrulamasını sunamaz.

Çoğu, tanıdığım tüm BT insanları değilse, kodlamadan önce UML veya diğer diyagram türleriyle yazılım modellemenin yararlı olduğuna inanıyorlar.

Tanıdığınız tüm insanların buna inandığını kabul etmiyorum, ancak bunun genel olarak yaygın bir şey olduğunu düşünmüyorum. 1970'de Winston Royce, yazılım geliştirmenin tasarım ve kod faaliyetleri arasında bir miktar yinelemeye sahip olduğunu biliyordu. 1992'de Jack Reeves, kodlamanın gerçek tasarım etkinliği olduğunu yazdı ( C2 Wiki'de de tartışıldı ).

Bu, insanların modele dayalı geliştirme araçları yapmaya çalıştıkları anlamına gelmez. UML modellerinden kod üretmeye çalışan araçlar vardır (ve sadece sınıf diyagramları değil, çeşitli diyagram türlerini birbirine bağlama ve onlardan kod oluşturma). Ama bunlar, en azından gördüğüm kadarıyla, yaygın olarak kullanılan araçlar değil.

Bu aynı zamanda gereksinimlerden doğrudan kod yazmanız gerektiği anlamına gelmez. Erken doğru yapılması için kritik olan bazı tasarım kararları vardır ve herkesin seçenekleri, etkilerini anladığından ve iletişim kurabildiğinden emin olmak için bir miktar modelleme faydalı olabilir. Bazı insanlar (ben dahil) buna "yazılım mimarisi" diyorlar .

Kod yalan söylemez. Derleyici veya yorumlayıcı tarafından kontrol edilir. Umarım otomatik testlere sahiptir ve statik kod analizini geçmesi gerekir. Bir modül başka bir modülle doğru şekilde arabirim oluşturmazsa, bir hata mesajı aldığınız için genellikle kodda açıkça görülür.

Bu gerçekten Çevik Modelleme'nin bazı yönlerinin, özellikle de Yürütülebilir Spesifikasyonların ve Tek Bilgi Kaynağının kalbidir . TDD ile mutlaka aynı fikirde değilim, ancak kodunuzun ve ilgili testlerin (üniteden kabul testlerine kadar, tercihen otomatik testler olarak yakalanan) sahip olması fikri tek doğru kaynaktır.

Diyagramların kendileri tutarlı olsa bile, kodun gerçekte bunları uyguladığından emin olamazsınız. Evet, kod üreteçleri vardır, ancak hiçbir zaman kodu üretmezler.

Genel bir kural olarak, model-> kodundan gitmek yanlış bir yol olduğunu düşünüyorum. Bunun yerine, kod modeller üretmelidir. Yani, araçlar kodları inceleyebilmeli ve mühendisler etraflarına metin yazdıkça daha da geliştirilebilecek grafik ve tablo gösterimleri oluşturabilmelidir. Koddan üretilen bu modeller, oluşturma ve yayınlama sürecinin kesintisiz bir parçası olmalıdır.

Değişen derecelerde bunu çeşitli diller için destekleyen araçlar vardır. Dillerin ve paradigmaların doğası göz önüne alındığında, bazıları için diğerlerinden daha kolaydır.

Bu prosedürün dezavantajlarını, neden bu kadar çok insanın (deneyimlerime göre) yazılım tasarımı yapmanın tercih edilen yolu olarak düşündüğünü merak etmemi sağladım.

Bu insanların yazılım mühendisliğini ve yazılım tasarımını mutlaka anladıklarını sanmıyorum. Bu insanların diğer mühendislik disiplinlerinin neler yaptığını incelediklerini ve yazılım mühendislerinin yapmaları gerektiğini düşündükleri şeylerle eşleştirdiklerini düşünüyorum. Ama büyük bir farkı görmezden geliyorlar. Diğer mühendislik disiplinleri önce modeller ve simülasyonlar oluşturur, çünkü gerçek ürünü oluşturmak son derece pahalı ve zaman alıcıdır. Yazılım mühendisliğinde, tasarımımızın parçalarını alabilir ve gerçek dünya ortamında çok kısa sürede ve çok az maliyetle test edilebilir bir şey üretebiliriz. Ekonomi çok farklı.

Yazılım sistemlerini modellemenin ve hepsini kodda yapmanın faydaları nelerdir?

Son derece karmaşık bir yazılım sisteminiz olduğunda, modellere sahip olmak, anlaşılması daha kolay bir şeye sahip olmak anlamına gelir. Farklı bir soyutlama seviyesi, insanların sisteminizin çeşitli yönlerini anlamalarına yardımcı olacak bir şey. Farklı paydaşların yazılım sistemini hızlı ve kolay bir şekilde anlamalarını sağlamak için her bir modelleme dili veya gösterimi tarafından izin verilen çok sayıda farklı modelleme dili ve farklı model türleri bulunmasının nedenlerinden biridir.

Yazılımı yazılım tasarımı ile ilgili gerçeğin ana kaynağı olarak modelleyen (kodsuz) belgeleri kullanmanın mantıklı olup olmadığını soruyorum. Kodun önemli bir kısmı bu belgelerden otomatik olarak oluşturulduğu durumda yok. Durum böyleyse, belgelerin kendilerini model olarak değil kaynak kod olarak kabul ederdim.

Çok sayıda kod dışı belge, taslak olarak yararlıdır . Yani, tasarımın "gerçeği" bu yönü izlemelidir. Bir tasarımın yerine getirmesi gereken unsurları modellemenin bir yolu. Onlara gereksinim belgeleri diyebilirsiniz, ancak verebileceğim tüm örneklerde bu çok güçlü olabilir. Bunları üretmek için PlantUMext üzerinden PlantUML kullandım .

• Kullanım senaryoları, kullanıcılarla veya harici sistemlerle amaçlanan özellikleri ve etkileşimleri gösterebilir.

• Etkinlik diyagramları, bir yazılımın desteklemesi gereken iş süreçlerini gösterebilir.

• Durum diyagramları bir web sitesinde amaçlanan dinamiği gösterebilir:

• Dörtlü Gang tasarım desenleri statik ve dinamik modeller olarak sunulmaktadır. Örneğin, Memento:
  
  

Bu prosedürün dezavantajlarını, neden bu kadar çok insanın (deneyimlerime göre) yazılım tasarımı yapmanın tercih edilen yolu olarak düşündüğünü merak etmemi sağladım.

UML'nin deneyiminizin dışında kullanımı hakkında bazı gerçek bilgilerle ilgileniyorsanız, yapılan bazı çalışmalar var (ödeme duvarı olmayan makalelere bağlantılar bulmaya çalıştım):

• Petre, Marian (2013). Uygulamada UML . İçinde: 35. Uluslararası Yazılım Mühendisliği Konferansı (ICSE 2013), 18-26 Mayıs 2013, San Francisco, CA, ABD, s. 722-731.
• N. Mangano, TD LaToza, M. Petre ve A. van der Hoek (2015). Yazılım Tasarımcılarının Beyaz Tahtadaki Eskizlerle Etkileşimi . In: Yazılım Mühendisliği IEEE İşlemleri, cilt. 41, hayır. 2, sayfa 135-156.
• Forward ve Timothy C. Lethbridge. 2008. Model merkezli ve kod merkezli yazılım geliştirme için problemler ve fırsatlar: yazılım uzmanları . 2008 Uluslararası yazılım mühendisliğinde Modeller çalıştayı (MiSE '08). ACM, New York, NY, ABD, 27-32.

Geliştiriciler, dünyamızı açıklamak için görüntüleri kullanmayı seviyorlar, bu yüzden bir araba üretimi ile ilgili:

• Araç, kod için aynı olan üretim zincirinin sonucudur (elbette dağıtım sürecini ekleyin).
• Aracın tasarım belgesi, yazılımın tasarım belgesi ile aynıdır.

Dünyalarımızda, genellikle tasarım belgesini tasarlayan ve yapanlardan, kodu üreten ile aynıdır. Diğer alanlarda bu doğru değil. Ancak bu, hepsini bir arada yaparak gerçekten aynı seviyede kalite elde edebileceğiniz anlamına gelmez.

Bu belgeyi kodlamadan önce yaparak (açlık için bir kavram kanıtı gibi herhangi bir şey hariç ...):

• Yapmadan önce düşüneceğinizden eminsiniz, ne yapmanız gerektiğini bildiğinizde kodlama KOLAY.
• Daha deneyimli insanlara yazılımınızın en zor kısmına odaklanabilirsiniz: tasarım, algoritma / matematik çok özel bir amaç (gömülü, gerçek zamanlı, montaj) dışında herhangi bir şeydir.
• Daha az deneyimli insanlara kodlama sürecinin iyi bir bölümünü devredebilirken, daha deneyimli insanlar sadece yeteneklerinin seviyesine ihtiyaç duyan en kritik kısma odaklanırlar. Daha az deneyimli insanlar bu konuda çok şey öğrenecekler.
• IT olmayan kişilerle tasarım belgenizin görüntüsü aracılığıyla görüşebilirsiniz, ancak yalnızca kodunuz olsaydı, yaptığınız şeyin bir görüntüsünü çıkarmak zorunda kalacaksınız, bir şeyi unutmak için tüm risk (bir yerde unutulmuş bir dinleyici ...). İletişim hakkında daha fazla bilgi için CandiedOrange'ın cevabına bakınız.
• Yazılımınızın gelişmesi gerektiğinde, neyin etkili olacağını daha iyi tahmin edebilirsiniz.
• Tasarım, yazılımınızın bir parçasının kesilmesini ve yazılımınızın bir parçasının aynı anda geliştirilmesini kolaylaştıracaktır.
• Kod kolay olmadan önce kodu kodlayan bir TDD yaklaşımında, kodlama sırasında tüm vakaları kapsamakla ilgili baş ağrısına sahip olmanız gerekmediğinde, bu lanet reberbatif birim testini yazmak çok daha kolay olacaktır.
• ...

Not: Bu onaylama, kodun gerçekten tasarımın yansıması olduğunu ve her ikisinin de güncel kaldığını varsayar ...