Başarılı bir proje için UML diyagramları ne kadar önemlidir? [kapalı]

Bir projenin ortasındayım ve UML diyagramları yazmam istendi (kullanım durumları, sınıf diyagramı vb.). Proje çok karmaşık değil.

Bunun zamanımı boşa harcadığını mı merak ediyordum? Kod yazmak gibi başka eğlenceli şeyler de yapmalı mıyım? Ve ne zaman bütün kavramsal aşamalardan geçmeden bir şeyler inşa etmek uygun değildir? Her şey karmaşıklıkla mı ilgili? Ve eğer öyleyse, nasıl ölçülür?

Bir süre önce UML'nin büyük bir hayranıydım. Ben bile OMG sertifikam var. İçinde bulunduğum büyük kurumsal projelerde yaygın olarak kullandım.

Bugün neredeyse tamamen UML'yi durdurdum. Bazen, sistemler arasındaki etkileşimi tanımlamak için çok yararlı bulduğum dizi diyagramını kullanırım, ancak başka diyagramlar kullanmıyorum.

Şimdi, kullanıcı hikayeleriyle çalışmayı tercih ediyorum, hem (sadece) hem de ürün sahibi (veya analistler) tarafından yazılan gerekli dokümantasyonla desteklenmiş ve onun (gerektiği gibi) daha fazla ayrıntı vermesi için geliştirme ekibine bağlılığı.

UML kullanabileceğiniz bir araçtır, ancak projelerinizin başarısı için kesinlikle kritik bir faktör değildir. Uzun yıllar sonra, hangi araçları kullandığı önemli değil, kritik faktörün geliştirme ekibi olduğunu düşünüyorum.

Planlama kritik, ancak ünlü stratejist Carl von Clausewitz'in uyardığı gibi

Hiçbir kampanya planı düşmanla ilk temasta hayatta kalamaz

Bu yüzden başlangıçta sorunlara nasıl saldırılacağını planlamak için büyük bir zaman kaybı değil. Ancak gelecekteki programcılar için kodunuzu belgelemek için zaman kaybı olabilir. Askeri bir metafor kullanmak için bir savaş planına ihtiyacınız var, ancak bu planı tarihçilere eylem sonrası bir rapor olarak kullanmayacaksınız.

Daha somut olarak, bu şemaları ekibinizle niyetlerinizi iletmek ve proje öncesi ve sırasında saldırı planı hakkında düşünmek için kullanabilirsiniz. Fakat olasılıklar, ortaya çıktıklarınızın kod yazarken ve sorun hakkında daha fazla bilgi edinirken ince ayarlanması gerektiğidir. Neredeyse her zaman ilk planınızın / tasarımınızın değişmesi gerekir, çünkü öndeki her şeyi bilemezsiniz.

UML diyagramlarının yalnızca , kodunuzdan daha yüksek bir soyutlama düzeyindeki bir şeyi ifade etmeleri durumunda yararlı olabileceğini düşünüyorum .

UML'yi yazmak sadece UML yazmak uğruna gereksiz bürokrasiye dönüşür ve projeyi ve kodu, hiçbir yararı olmadan değişikliklere daha az adapte eder hale getirir.

Örneğin, bir paketteki tüm sınıfları, özniteliklerini ve yöntemlerini - kolayca otomatik olarak oluşturulabilecek bir şey - gösteren, tüm değerleri gösteren bir UML sınıf diyagramı hiç bir değer sağlamaz: kodunuzla aynı düzeyde soyutlama yapar . Ayrıca, kod kesinlikle bu bilgi için daha iyi bir kaynak olacaktır, çünkü her zaman güncel olacaktır ve muhtemelen hangi yöntemlerin / niteliklerin / şeylerin daha önemli olduğunu bilmek daha kolay bir şekilde belgelendirilecek ve organize edilecektir.

Öte yandan, kodda ifade edilebilecek olandan daha yüksek bir soyutlama seviyesine sahipseniz, bunları bir diyagramda belgelemek iyi bir fikir olabilir.

Örneğin, karmaşık bir sistemdeki üst düzey soyut modülleri, bağımlılıklarıyla ve belki de sorumluluklarının küçük bir tanımını ve kaynak kodunda hangi paket / ad alanlarını haritaladıklarını gösteren yeni bir ekip üyesi için gerçekten yararlı olabilir. Projeye tanıtılması gereken veya yeni bir sınıfın / işlevselliğin nereye atılması gerektiğini bulmak için de kullanılabilir.

Yararlı bir diyagramın bir başka örneği, bir iletişim protokolünde atılacak olan yüksek seviyeli adımları gösteren bir dizi diyagramı olabilir. Belki bunların her adımı küçük tuhaflıklar ve karmaşıklıklara sahiptir, ancak bunları kodun içinde tanımlamak muhtemelen yeterlidir. Daha yüksek seviye şeması, bir programcının her etkileşimin karmaşıklığı hakkında endişelenmenize gerek kalmadan şeylerin "büyük resmini" kolayca anlamasına yardımcı olabilir.

Neyse, bunlar sadece bazı örnekler; Basit bir diyagramın çok yardımcı olabileceği birçok durum vardır. Sadece bunları yalnızca kodun içindeki bir şeyi ifade edemediğiniz zaman yapmanız gerektiğini unutmayın. Kendinizi kaynak kodun kendisini açıklamak için UML diyagramlarını kullanarak bulursanız, soruce kodunu daha çok kendi kendine belgeleyin.

Son olarak, koda uygulanan genel kurallardan bazıları diyagramlara da uygulanabilir: kendinizi tekrar etmekten kaçının, basit tutun, bir şeyleri değiştirmekten korkmayın (yalnızca bir UML diyagramında belgelendiği için yapamazsınız anlamına gelmez) değiştirilmeli) ve her zaman gelecekte bu diyagramları kimin yazacağını / sürdüreceğini düşünün (muhtemelen gelecekteki kendiniz) bunları yazarken :)

Ekip üyelerinin toplu olarak anlamaları ve tasarım kararlarını özetlemenin ve iletmenin yararlı bir yolu olarak görmeleri halinde UML'nin değeri vardır. Hepsini bilmenize gerek yok, sadece ekibin yararlı bulduğu altküme.

Ayrıca, mükemmel ve parlak diyagramlar çizmenize gerek yoktur. Bir beyaz tahta üzerinde kabaca kabataslak bir dizi diyagramı veya sınıfların o beyaz tahtaya yapışmış notları içeren bir sınıf diyagramı içeriğe bağlı olarak yeterli olabilir.

Bir keresinde, denizaşırı bir sözleşmeli geliştirici ekibini yönetmem gereken bir iş üzerinde çalıştım.

Ürettikleri malzemelerin bazıları oldukça korkunçtu (uzak sözleşmeli kodlayıcıların ortak bir belirtisi - kodunuz için pek fazla önemsemiyorlar, sadece hızlı bir şekilde yapılmasını istiyorlar).

Projeyi yönetmek için kendimi UML diyagramları oluştururken ve kodlamada onlara teslim ederken buldum. Çok başarılı oldu - UML'de, Java'dan çok daha hızlı bir program yazmak benim için uzun sürmedi ve müteahhitlerin takip edebileceği ve ölçülebileceği bir şeydi.

Bir uyarı - bazen yaratıcı olmak ve modellerimden sapmak istiyorlardı, ancak bu durumlarda gerçekten haklıydılar ve UML'nin tümü nihai ürünün kalitesini arttırdı

Birisi sizden UML diyagramları hazırlamanızı istedi ve birileri maaşınızı ödüyorsa, o zaman gerçekten zaman kaybı olmaz. Bu birinin zamanını boşa harcayabilir veya olmayabilir.

Eğer birisi sizin UML diyagramlarınızı okuyarak projenizi anlamayı planlıyorsa, muhtemelen zaman kaybı değildir.

İlk tasarım aşamasında kağıt üzerinde veya beyaz tahtada fikir edinmek için faydalı buluyorum. Genel olarak UML sınıf diyagramlarını, standartlara sıkı sıkıya bağlı kalmadan kullandım. UML'nin özgün tasarımını, projenin bir parçası olarak ve ayrıca projenin sonunda yeniden ziyaret etmenizde fayda var. Bir kod tabanına sadece kod okuyarak yapabileceğiniz daha yüksek bir soyutlama seviyesinden bakmamda yardımcı oldu ve hatta potansiyel hataları saptamaya da yardımcı oldu.

Yapmış iyi nokta var burada tarafından ragu.pattabi UML'den iki çeşit arasındaki fark yaratmanın ...

Bence çevik lezzet UML (örneğin, ani beyaz tahta kroki) arasında daha başarılı şelale lezzet (örneğin belge anlayışlı yöneticileri mutlu etmek için dokümantasyon için tüm kanlı detay, kod üretimi, vb ile ayrıntılı diyagram) UML'den.

UML 'olması gereken' bir yetenek olarak görüldüğünde (10 yıl veya daha fazla), muhtemelen o zamanki pek çok taraftarının kanaatine dayanan görüşleri nedeniyle buna karşıydım. Ama şimdi, bunun lehine düştüğü için, kendimi ne olduğuna göre görüyorum - hak eden ama yazılım geliştirmenin gümüş mermisi olmayan kullanışlı bir araç.

Yapmak üzere olduğumuz bir şey hakkında arkadaşlarımla konuştuğumda UML kullanıyorum (veya UML'ye benzer :)). Fikirleri tartışmak. Benim için kodunu otomatik olarak oluşturacak UML projesi hazırlamak değil. Sınıflarımı UML'de oluşturduktan sonra kod oluşturduğumu ve daha sonra ayarlamayacağımı hayal edemiyorum. Bu asla olmaz. Bu yüzden koddan UML'ye değişiklikler getirmeniz gerekecek. Ve UML kullandığımda beyaz tahta veya kağıda çizerim. Enterprise Architect gibi bir alette asla.

Kodumun tamamını UML'de belgelemek için tek neden müşterinin talep ettiği bir sözleşme olacaktır. Örneğin, yazılımın bir bölümü tamamlandıktan sonra yazılım mağazasını değiştirme seçeneğine sahip olmak istediğinde.

Proje çalışması dokümantasyonu profesyonel bir projenin temel bir teslimatıdır. Ne kadar yeterli? Tabii ki birçok faktöre bağlı. Ancak benim görüşüme göre, kullanım durumları, sınıf diyagramları, işlem akış diyagramları vb. Hiç zaman kaybı değildir. Çeşitli proje aşamalarında değeri var. Belgeleme ile ilgili tek sorun genellikle kaynaklardır.

Bazı programcılar belgelerin zaman kaybı olduğunu düşünüyor. Ama bu doğru değil. Dokümantasyonunuzu tasarımınızın ve sistem kurallarınızın bir göstergesi olarak zarif ve açık bir şekilde görüntülerseniz, daha fazlasını takdir edebilirsiniz. Ayrıca, bir kişinin kendini, sistemi sürdürmesi gereken insanların konumuna getirmesi gerekir. 500 kod dosyası atılması ve bunlarla ilgili problemleri çözmesinin istenmesi biraz kötü ama nadir değildir.

Projenize zaman ayırmanızı ve diyagramları döngü halinde oluşturmanızı öneririm. Birincisi, projenizin üst düzeylerini kapsayacak ve daha sonraki seviyeler ayrıntılarda daha fazla durabilecek.

Özellikle kullanım durumları koddan kolayca çıkarılamaz (bir sistemin diğer birçok yönünün aksine). Bunları yaptığından emin ol.

UML, bir araçtır, başka bir şey değildir ve faydalı olup olmadığına bakılmaksızın, sadece geliştirme ve tasarım iş akışınıza bağlıdır. Roma'ya giden birçok yol var ve bazıları UML'yi içeriyor, bazıları ise yok.

İş akışınız, mimarinizi belgelemek veya planlamak için UML'ye dayanıyorsa, bırakma aptalca olacaktır. UML, proje yapısını diğer ekip üyelerine (daha geniş anlamda) iletmenin mümkün olan en iyi yoluysa, elbette, kullanın. Ancak proje UML'siz iyi çalışıyorsa, sadece UML şemalarını yapmak sadece saçmalıktır.

Bununla ilgili bazı düşüncelerim var. Dil kullanılabilir ve kötüye kullanılabilir, zorlayıcı ve dikkat dağıtıcı, tetikleyici ve sessiz olabilir. UML, belirli bir dizi sorun için uygun olan başka bir dildir ve diğer dillerde olduğu gibi, akıcı bir şekilde konuşmayı ve doğru bir şekilde anlamayı öğrenmek zaman ve çaba harcar.

Neyin iletişim kurulacağına ilişkin karar, iletişim kurulduğu dilden inanılmaz derecede daha önemlidir. UML, kötü tasarımlarınızı sihirli bir şekilde anlaşılabilir hale getirmez. Tıpkı diğer dillerde olduğu gibi, ayrıntılarda kaybolmak veya hayal gücünüze çok fazla şey bırakmak kolaydır.

UML, sayısız korkunç IDE'den dolayı kötü bir isim yaptı ve bu sayede çift yönlü prototip oluşturma, yoğun tıklama gerektiren grafik işleme ve herhangi bir şeyi değiştirmenin zorluğuna izin verdi. UML 2.0, belirli akademisyenleri tatmin edecek kadar karmaşık olabilir, ancak meta modeli pek çok pratik uygulamayı etkilemiyor gibi görünüyor.

Yine de, zaman zaman UML kullanıyorum. Üst düzey bir tasarımı değerlendirmek (iyi bir tasarımın saçaklarda karmaşıklığı ve merkezde sadeliği vardır). Bir fikri meslektaşınıza iletmek ve geri bildirim almak. Gizli ilişkileri bulmak, normalleştirmek vb. Ama bu her zaman kafamda olan bir şeyin yansımasıdır. Genellikle, UML'yi kalem ve kağıtla, tercihen herhangi bir bilgisayardan uzağa çizerim. Gerekirse, bir tasarım kristalleştiğinde, çizim programında görsel bir sunum yapıyorum.

UML, sınıf diyagramını kullanarak mimarinizin grafiksel görüntüsünü elde etmek için kesinlikle harikadır. Dizi diyagramı kullanarak etkileşim benim için sihirdir. Sorun bu nedenle UML değil, benim için MDD.

Yani, UML kodun bir izleyicisiyse, dokümantasyon için gerçekten yararlıdır, ancak kesinlikle kod oluşturma için değildir. Proje kod merkezli olmalı ve kesinlikle Model odaklı merkezli olmamalıdır. UML, uygulama aşamasında bir canlı kod ve model senkronizasyonu kullanarak kullanılmalıdır.

Onları çok abartılı buluyorum. Bin kelime çizmeyen tek resim onları düşünüyorum.

UML, yalnızca sistemi tasarlayan kişiler kodu kendileri yazamazsa değerlidir. yani, UML mimari kavramları başkalarına ileten bir 'dildir', şimdi kodu tasarlayan ve uygulayan kişiyseniz, o zaman neden kendinize ne yapacağınızı göstermeniz gerekir ?! Git ve yerine kodlama için düz gidin. Daha sonra yaptıklarınızı belgelemeniz gerekecek, ancak genel verimlilik daha hızlı.

Ancak, dış kaynaklı geliştirici ekibinize ne istediğinizi söylemek isteyen bir sistem mimarı olsaydınız, o zaman bir şekilde onlara söylemelisiniz, ve bu da UML'nin geldiği yer. Ancak, çok sayıda alternatif performans aracı olduğunu düşünüyorum. Günümüzde bu görev ve açıkçası, UML şemasının karmaşıklığı herkesin okumayı anlaması gerektiği anlamına gelir;

Hiç bir UML hayranı olmadım, ancak sistemler veya görevler arasındaki etkileşimi tanımlamak için iyi bir dizi diyagramına değer verdim.

Ancak, sınıf diyagramı doğmadan önce eskidir. Kaba bir tasarım UML gerektirmez ve ayrıntılı bir belge kod tabanından otomatik olarak daha iyi çıkarılır (canlı). Javadoc ve Doxygen, manuel sınıf diyagramlarına duyulan ihtiyacı tamamen ortadan kaldırdı.

Belgeleme ile ilgili mesele şu ki iki seviye var:

• yüksek seviyeli (mimari) kararlar elle belgelenmelidir
• düşük seviyeli (varlık ilişkileri) gerçekler otomatik olarak çıkarılmalıdır

Genellikle kod ve UML diyagramları arasında yinelenirim. Diyagramların büyük resmi ve ileriye giden sağlam bir yolu göstermeye yardımcı olduğunu ve meseleler keşfedildiğinde oldukça hızlı bir şekilde değiştirilebileceklerini buldum. Ayrıca, diyagramlara sahip olduğumda kodlama önemsiz hale geldi.

Bunun tersine, resimlerdeki kodu çizdiğim zaman bağımlılık sorunları ortaya çıkarır ve tasarım geliştirme fırsatlarını bariz bir şekilde açık kılar, bu da çalışacak kodun olması durumunda muhtemelen fark edilmezdi. Özellikle, eğer çizmek bir acı ise, o zaman kodlanacak bir acı ve sürdürmek için bir kabus da olacaktır.

Yinelemenin gerekli olduğunu buldum, çünkü sadece resimlerin çizilmesi her zaman önemli yönleri özlüyor, sadece sorunlu tasarımlarda kodlama yapıyor.

Ancak, başka bir afişin dediği gibi, her şey insanlara kayıyor. UML şemalarını "kullanma" konusunda ustaları varsa UML paha biçilmezdir. Olmazlarsa, diyagramların değeri yoktur.

Bu nedenle, sorunuzun cevabı gerçekten de "bağlı" dır. Bu durumda, insanlara, projenin karmaşıklığına ve sistemin düzgün çalışmasının ne kadar önemli olduğuna bağlıdır.

Deneyimlerime göre UML, geliştiriciler arasındaki kod kalıpları hakkında iletişim için ve uygulama genelindeki mimari için önemlidir.

Diyagramları seviyorum, ancak bir tane yapmam istense (özellikle UML!), İki soru sorardım:

1. Kimin icin?
2. Şimdi ihtiyaçları var mı?

Diyagramlar hemen güncel değil. Yani şimdi birisiyle iletişim kurmak için kullanmıyorsanız, sadece çürümeye başlayacaktır. Ve iletişim kurduğunuz kişi bir metin açıklaması veya telefon görüşmesi veya beyaz tahtadaki gayrı resmi bir programla daha iyisini yaparsa, bunun yerine bunu önerin.

Şimdiye kadar kullandıklarını gördüğüm gibi UML diyagramları hakkında benim için en büyük kavramalardan biri, çoğunlukla birisinin duvarında "güzel resimler" olarak ya da bir yere bağlanan katlanmış bir sayfa olarak görülme eğiliminde olmaları ve nadiren bir taban çizgisi görevi görmeleridir. bir üretim kodu için.

Bu tür senaryoda - UML diyagramları (veya hangi modelleme dilini kullanırsanız kullanın), zaman geçtikçe ve proje ilerledikçe alaka düzeyi kaybına maruz kalma eğiliminde olduklarından, uzun vadede nadiren faydalıdır. Bu ilk çizimler birkaç yıl içinde çoğunlukla işe yaramaz ve yanlıştır ve etraflarında dolaşmak çoğunlukla zararlıdır.

Bununla birlikte, modelleme araçlarının (zorunlu olarak UML'nin kullanılması), modeller gerçek çalışma koduna gerçek canlı ve ilgili girdi sağlarsa, tamamen işe yaramaz bir uygulama değildir. Model açıklaması kodun yararlı bir eseriyse, kod olarak ele alınmalıdır:

Ya modellenmiş konseptlere dayalı dinamik kararlar almak için doğrudan bir meta veri kaynağı olarak kullanmak ya da fiili çalışma kodunda kullanılan statik kod artefaktlarını üretmek için kod oluşturmayı kullanmak.

Sorunun UML'nin değeri ile mi, yoksa programların mimarisini tasarlamanın esası ile mi ilgili olduğunu bilmiyorum.

UML hakkında. Genelde yalnızca ihtiyacınız olanları kullanın: vakaları, sınıf diyagramlarını ve dizi diyagramlarını kullanın. Basit ve kolaydır, kesinlikle kendi diyagramlarınızla yapabilirsiniz. Bu bakımdan UML herkesin anlayacağı bir standarttır.

Program tasarlama hakkında.

1. Planlamasanız bile her programın bir tasarımı vardır. Kod yazıldığında, sadece tersine mühendislik. Eğer planlamadıysan, iddiaya göre kötü bir tasarım olacak.

2. Tasarım, tekrarlayan problemler için bilinen kalıpları kullanarak size zaman kazandıracak.

3. Bir ekip içinde çalışıyorsanız, çözümleri tartışmak, fikirlerini iletmek için tasarım yapmak ve işi dağıtmak için çok pratik ancak zorunludur.