UML neden çoğu özgür yazılımda kullanılmıyor (örneğin Linux'ta)?


29

UML'nin çoğu ücretsiz yazılım projesinde neden kullanılmadığını anlamaya çalışıyorum . Örneğin, Debian / Linux sistemim muhtemelen on binden fazla ücretsiz yazılım paketine sahip ve açık UML çerçevesi ve metodolojisi kullanılarak geliştirilen birini bile adlandıramıyorum . Örneğin, Qt , GCC , Linux çekirdeği , bash , GNU make , Ocaml , Gnome , Unison , lighttpd , libonion , docker (AFAIK) UML'den hiç bahsetmeyen ücretsiz yazılım projeleridir.

(Benim tahminim UML çok iyi gelişme görevleri resmi taşeronluk için uygun olmasıdır ve olmasıdır değil gelişmiştir nasıl özgür yazılım)

UML ile ilgili bazı materyaller okuduğumda, bunu iyi anladığımı iddia etmediğime dikkat edin.

Aslında, UML'nin kullanıldığı özgür bir yazılımı kolayca adlandıramıyorum (belki de özgür yazılım olarak uygulanan bazı UML araçları hariç). Belki turnuva bir istisnadır (orada UML'den bahseden bir şey).

(eski özgür yazılım projeleri bile, başladıktan sonra UML'yi benimsemiş olabilir, ancak yapmadılar)


Papirüs'te çalışan bazı meslektaşlar, özgür yazılım projelerinin çoğunun başlangıçta açıkça (ve yeterince derin) resmi bir modele sahip olmadığını belirtti. Ayrıca, UML, Java ile ilgili olduğunu iddia ettiğinden çok daha fazla görünüyor (Tamamen Ocaml veya Common Lisp veya Haskell veya Javascript için ve hatta C ++ 11 için anlamlı olacağından emin değilim). Belki çevik bir yazılım geliştirme çok UML dostu değildir.

Ayrıca bir şekilde ilgili bir soruya bu cevaba bakınız . M.Fowler'in blogu Design Dead mi? anlayışlı.

PS. Bunun esasen bir fikir meselesi olduğunu sanmıyorum; nedenini açıklayan bazı objektif sebepler ve özgür yazılımın bazı temel özellikleri olmalı. UML'nin yalnızca resmi taşeronluk için yararlı olduğunu ve yalnızca özel yazılımlarda olduğu gibi, yalnızca geliştirilen yazılımın bir kısmı gizlendiğinde yararlı olacağını tahmin ediyorum. Bu doğruysa, UML , özgür yazılım geliştirme ile uyumlu olmaz .

Not: Ben kendim UML hayranı değilim. UML'yi yalnızca kağıt belgeler olarak değil, yazılım araçları için [meta-] veri formatı olarak da tanımlarım.


30
Belki de UML saçmalıyordur? Yoksa çoğu özgür yazılım iyi bir dokümantasyona sahip olmadığı için mi?
BЈовић

19
Etrafta başka bir yol var. UML'yi kullanmak için başka bir yol değil, nesnel bir sebep olmalı. FOSS UML kullanmaz, nesnel bir sebep yoktur veya tüm nedenler FOSS topluluğu tarafından kabul edilmez.
Öforik

18
Listelenen bazı projeler için nedenler çok açık: çünkü zaman yolculuğu henüz icat edilmedi. UML ilk olarak 1997'de standardize edildi. GNU projesi 1983, GCC 1987, Bash 1988, GNU yapımı 1989, Qt 1991, OCaml 196, Gnome 1997'den yapıldı. OCaml'de C ve Unison'da yazılmıştır, her ikisi de UML'de iyi tanımlanamayan dillerdir. Ayrıca, Özgür Yazılım geliştiricileri genellikle harici araçların yardımı olmadan anlaşılabileceği şekilde kod yazmaya inanır.
Jörg W Mittag

26
UML, açık veya kapalı kaynak yazılım geliştirmede çok fazla kullanılmamaktadır . Çoğunlukla yazılım geliştirme hakkında konuşan insanlar tarafından kullanılır .
Karl Bielefeldt

16
Aynı sebep UML, özgür olmayan yazılım geliştirmede pek kullanılmaz. Kağıt üzerinde kulağa hoş geliyor ama pratikte herhangi bir gerçek fayda sunmuyor gibi görünüyor.
JohnB

Yanıtlar:


37

UML'yi kullanmanın farklı yolları vardır. Martin Fowler bu UML modlarını çağırır : ve tanımlar dört Notes gibi UML'yi , Sketch olarak UML , Blueprint olarak UML ve bir Programlama Dili olarak UML .

Bir Programlama Dili olarak UML hiçbir zaman gerçekten kalkmadı. Bu alanda Model Driven Architecture veya Model Based Software Engineering gibi farklı isimler altında bazı çalışmalar yapılmıştır . Bu yaklaşımda, yazılım sisteminizin oldukça ayrıntılı modellerini yaratır ve bu modellerden kodu oluşturur. Bu yaklaşımın faydalı olduğu bazı durumlar olabilir, ancak genel yazılım için değil, özellikle de bu yaklaşıma güç sağlayan araçları sağlayabilecek büyük şirketlerin dışında değil. Aynı zamanda zaman alıcı bir işlemdir - bir sınıfın kodunu, uygulamak için gerekli tüm grafik modelleri oluşturabileceğimden daha hızlı yazabilirim.

Blueprint olarak UML, genellikle "önden büyük tasarım" projesinin bir göstergesidir. Tabii ki olmak zorunda değil. Model, belirli bir artış için de tamamen tanımlanabilir. Ancak fikir, zamanın UML modelleri biçiminde bir tasarım oluşturmak için harcanması ve daha sonra koda dönüştürülmesi için birine teslim edilmesidir. Tüm detaylar açıklanmıştır ve koda dönüşüm daha mekanik olma eğilimindedir.

Çizim olarak UML ve Notlar olarak UML doğaya benzer, ancak ne zaman kullanıldıklarına göre farklılık gösterir. Taslak olarak UML'yi kullanmak, UML notasyonlarını kullanarak tasarımları taslak haline getireceğiniz anlamına gelir; Notes olarak UML benzerdir, ancak modeller kod tabanını anlamada yardımcı olmak için koddan sonra oluşturulur.

Bunu düşündüğünüz zaman, yukarıdaki her şeyin herhangi bir modelleme gösterimi için doğru olduğunu düşünüyorum. Bunu varlık-ilişki şemalarına, IDEF şemalarına, iş süreci modelleme notasyonuna vb. Uygulayabilirsiniz. Modelleme gösterimi ne olursa olsun, ne zaman uygulayacağınızı (şartnameden önce, alternatif gösterimlerden sonra) ve ne kadar detayı (anahtar yönlerin tam detayı) seçebilirsiniz.


Bunun diğer tarafı açık kaynak kültürü.

Genellikle, açık kaynaklı projeler, bir bireyin (veya bugün bir şirketin) yaşadığı bir sorunu çözmeye başlar. Bir birey tarafından piyasaya sürülürse, geliştiricilerin sayısı 1'dir. Bu durumda, iletişim yükü son derece düşüktür ve gereksinimler ve tasarım hakkında iletişim kurmaya çok az ihtiyaç vardır. Bir şirkette küçük bir takım olması muhtemeldir. Bu durumda, muhtemelen tasarım olanaklarını aktarmanız ve takasları tartışmanız gerekecektir. Ancak, tasarım kararlarınızı verdikten sonra, kod tabanınız zaman içinde değiştiği için modellerinizi korumanız veya onları atmanız gerekir. In Çevik Modelleme açısından, "Belge sürekli" ve korumak "bilginin tek kaynağı" .

Kısaca, kodun tasarım olduğu ve modellerin tasarımın alternatif görüntüleri olduğu fikri var. Jack Reeves tasarım olarak kod üzerinde üç denemeler yazdı , ve C2 wiki tartışmaları bu fikirleri tartışırken, hem de orada kaynak kod tasarım , tasarım kaynak kodu ve kaynak kodu ve modelleme . Bu inanca (benim yaptığım) abone olursanız, kaynak kod doğrudur ve herhangi bir şema sadece kodu ve daha da önemlisi kodun ne olduğunun ardındaki mantığı anlamak için mevcut olmalıdır.

Bahsettiğiniz gibi başarılı bir açık kaynaklı projenin, dünya genelinde katkıları var. Bu katkı sağlayanlar, yazılımı destekleyen teknolojilerde teknik olarak yetkin olma eğilimindedir ve muhtemelen yazılımın kullanıcıları da olabilirler. Katkıda bulunanlar, kaynak kodunu modeller kadar kolay okuyabilen kişilerdir ve kodu anlamak için araçları (IDE'ler ve tersine mühendislik araçları) kullanabilirler (ihtiyaç duyarlarsa modelleri oluşturma dahil). Ayrıca, akışın eskizlerini kendi başlarına da oluşturabilirler.


Fowler'ın açıkladığı dört moddan, modelleme dillerini programlama dilleri veya planları olarak kullanan açık kaynaklı bir proje veya pek çok yerde proje bulacağınızı sanmıyorum. Bu not bırakır ve UML için mümkün olduğu kadar eskiz. Katkıda bulunan için katkıda bulunan tarafından notlar oluşturulacak, muhtemelen onları hiçbir yere yüklemeyeceksiniz. Kodlar daha eksiksiz hale geldiğinden ve katılımcılar için çaba sarf edeceğinden, muhtemelen sürdürülmeyeceğinden eskizler değer olarak azalır.

Açık kaynak kodlu birçok projede, katma değer yaratmadığı için uygun modeller bulunmaz. Ancak, bu, modellerin projenin başlarında biri tarafından yaratılmadığı veya bireylerin sistemin kendi modellerini oluşturmadığı anlamına gelmez. Kaynak kodu: Bir tasarım bilgisi kaynağını korumak sadece daha etkilidir: kaynak kodu.

Tasarım bilgisi alışverişinde bulunan kişileri bulmak istiyorsanız, katkıda bulunanlar tarafından kullanılan herhangi bir foruma veya posta listesine bakmanızı tavsiye ederim. Genellikle, bu forumlar ve posta listeleri projeler için tasarım dokümantasyonu görevi görür. Resmi UML'yi bulamayabilirsiniz, ancak burada tasarım bilgilerinin ve modellerin bir tür grafik gösterimini bulabilirsiniz. Proje için sohbet odalarına veya diğer iletişim kanallarına da girebilirsiniz - insanları tasarım kararları hakkında konuşurken görürseniz, grafik modellerle iletişim kuruyor olabilirler. Fakat iletişimdeki amaçlarına hizmet ettiklerinde değerli olmadıklarından büyük olasılıkla havuzun bir parçası olmayacaklar.


1
Çok fazla metin var ama sadece son fakat bir paragraf aslında soruyu yanıtlıyor. Ayrıca, soruyu yanıtlayabilmeniz için yeniden açtınız mı?
Öforik

6
@Euphoric Son paragraf soruyu cevaplasa da, geri kalanını arka plan ayarlamak ve terimler ve kavramlar üzerinde normalleştirmek için gereklidir. Ve hayır, zaten 4 tekrar oy kullandı - 5. oyu kullandım ve cevapladım.
Thomas Owens

3
+1 Çok kapsamlı cevap. Benim düşünceme göre, önceki paragraflar sonucu açıklar. Aferin!
Andres F.

8

Örnek olarak Linux kullanalım

  • Bu, Nesne Yönelimli bir proje değil, VFS gibi bazı bölümler UML'de modellenebilir, ancak diğerleri çok etkili olamazlar veya çok etkili olamazlar, yani temelde sadece structilişkisiz bir sınıf diyagramına düz bir çeviri .
  • UML dokümantasyon için iyidir, bir projeye yeni bir tane getirmek için hızlanır. Bu gerçekten Linux tarafından karşılanan bir şey değil, insanların kendileri öğrenmesi bekleniyor.
  • Hangi UML aracını kullanacağından emin değilim, insanlar korunacaksa bir konuda anlaşmaya varırlar. Bunun için ücretsiz bir java uygulaması vardı, ancak pek çoğunun kullanmak isteyeceğini sanmıyorum.
  • 90'lı yıllarda GUI hala Linux'ta zordu. Sadece posta listesi arşivini kazın, bahse girerim açılışta gösterilecek Linux için logodan başka bir tür grafik bulamazsınız. Düz metin, tercih edilen formattır.
  • Hiç kimsenin tasarıma değer vermediğini sanmıyorum. İnsanlar özellikleri önemsiyorlar ve kabul edilirlerse kodlar incelenecek. Kullanım durumları yine de en iyisidir, tıpkı POSIX ve SUS gibi standartların nasıl yazıldığı gibi.
  • İşletim sistemleri alanındaki birçok nesne topluluk içinde iyi anlaşılmış ve standardize edilmiştir. Örneğin, insanlar nasılstruct in_addr bellekte göründüğünü , hiçbir diyagram bunu daha net gösteremezdi.
  • UML, bellek ayırıcı, zamanlayıcı, kesme işleyicileri vb. Gibi modelleme algoritmalarına pek yardımcı olmaz. Kaynakların anlaşılması daha kolaydır.

Bunlar Linux proje ayarlarında düşünebileceğim şeyler. Bu pratiklik hakkında daha fazla, sanırım. Merakla, Tanenbaum'un OSx kitabında Minix'i tarif ederken herhangi bir UML kullandığını hatırlamıyorum .

Muhtemelen bahsetmeye değer, ayrıca iş yerinde UML kullanmıyorum. Muhtemelen birlikte çalıştığım kişilerin% 20'si UML'nin bir alt kümesini biliyor.


4
Linux kullanımı yapar bu sadece bir nesne yönelimli kullanmaz, nesne yönelimini dili . Doğru, linux ayrıca çok yordamsal bir tarzda yazılmış bölümler de içeriyor, ancak çekirdek modül arayüzü gibi diğer bölümler kesinlikle nesne yönelimli.
cmaster

UML'de sınıf diyagramlarından daha fazlası var.
Michael Dorner

Her büyük yazılım projesi nesneye yönelik tasarım gerektirir.
Kais

Katkıda bulunanların proje üzerinde çalışmaya başlamadan önce standart bir modelleme dilini anlamaları gerekir ve bu da UML, SysML, IDEF0, ODL veya OCL'de bir yazılım modelleme belgesine olan ihtiyacı doğrular.
Kais

2

UML bir temsildir, bu nedenle bir dil şeklidir ve argüman uğruna, amacının zihinsel bir modeli bir kişiden diğerine iletmek olduğunu varsayalım.

Bir dilde aradığım şey, kişinin zihinsel modelindeki değişiklikleri yakalamadaki etkinliği. Birinin modelinin açıklamasını yazdıktan sonra küçük bir değişiklik yapılması gerektiğini varsayalım. Temsilde ne kadar büyük bir değişiklik yapılması gerekiyor? Metinsel bir dilde bunu ölçmenin bir yolu,diff önce ve sonra kod arasında ve farklılıkları saymaktır. Bir grafik dilde, farkı ölçmek için benzer bir yol olmalıdır.

IMHO, bakım maliyetini ve hataları azaltmada bariz faydaları olan yukarıdaki önlemi en aza indirdiği dereceye "etki alanına özgü" bir dil (DSL) diyorum. DSL nasıl yapılır? Birkaç yol var. En basitlerinden biri sadece veri yapılarını ve yöntemlerini mevcut bir programlama dilinde tanımlamaktır. Bu, temel dile isimler ve fiiller ekleyerek istediğini söylemeyi kolaylaştırır. (Not: Bir öğrenme eğrisine sahip olmayan bir DSL aramıyorum. Bir DSL okuyucusunun bir kerelik öğrenme maliyetini yatırması gerekebilir.)

Önemli nokta şudur: Her durumda DSL, modelini ifade eden terimleri içermeli ve modelde uygun değişiklikleri yapmalıdır. Olası alan adlarının açık bir sınırı olmadığından, tek bir DSL hepsine hizmet veremez.

UML izlenim benim için çalıştığı şey.

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.