UML pratik mi? [kapalı]

Üniversitede çok sayıda tasarım ve UML odaklı kurslar aldım ve UML'nin bir yazılım projesinden, özellikle kullanım durumu haritalamasından yararlanmak için kullanılabileceğini biliyorum, ancak gerçekten pratik mi? Birkaç kooperatif çalışma terimi yaptım ve görünen o ki UML, endüstride yoğun bir şekilde kullanılmıyor. Bir proje sırasında UML diyagramları oluşturmak için zaman ayırmaya değer mi? Ayrıca, sınıf diyagramlarının genellikle kullanışlı olmadığını gördüm, çünkü bir sınıfın başlık dosyasına bakmak daha hızlı. Özellikle hangi diyagramlar en yararlıdır?

Düzenleme: Deneyimim 10 geliştirici projesinin altındaki küçüklerle sınırlıdır.

Düzenleme: Pek çok iyi cevap ve en ayrıntılı olmasa da, seçilenin en dengeli olduğuna inanıyorum.

Yeterince karmaşık bir sistemde , bazılarının UMLyararlı kabul edildiği bazı yerler vardır .

Bir sistem için faydalı diyagramlar, uygulanabilirliğe göre değişir.
Ancak en yaygın kullanılanlar:

• Sınıf Diyagramları
• Durum Diyagramları
• Aktivite Diyagramları
• Sıra Diyagramları

Kendilerine yemin eden ve onları zaman ve çaba kaybı olarak tamamen reddeden birçok işletme var.

Denize düşmemek ve bulunduğunuz proje için en iyisinin ne olduğunu düşünmemek ve uygulanabilir ve mantıklı olan şeyleri seçmek en iyisidir.

UML kullanmak, yürürken ayaklarınıza bakmak gibidir. Genelde bilinçsizce yapabileceğiniz bir şeyi bilinçli ve açık hale getiriyor. Yeni başlayanların ne yaptıkları hakkında dikkatlice düşünmeleri gerekir, ancak profesyonel bir programcı ne yaptıklarını zaten bilir. Çoğu zaman, kodun kendisini yazmak, kod hakkında yazmaktan daha hızlı ve daha etkilidir, çünkü programlama sezgileri göreve ayarlıdır.

Bu sadece ne yaptığınızla ilgili değil. Bundan altı ay sonra gelen ve kodu hızlandırması gereken yeni işe ne olacak? Şu anda proje üzerinde çalışan herkes gittiğinde bundan beş yıl sonra ne olacak?

Projeye daha sonra katılan herkes için bazı temel güncel belgelere sahip olmak inanılmaz derecede yararlıdır. Metot isimleri ve parametreleriyle tam gelişmiş UML diyagramlarını savunmuyorum (YOLDA sürdürmek çok zor), ancak sistemdeki bileşenlerin ilişkileri ve temel davranışları ile temel bir diyagramının paha biçilemez olduğunu düşünüyorum. Sistemin tasarımı büyük ölçüde değişmedikçe, bu bilgiler uygulama değiştirilse bile çok fazla değişmemelidir.

Dokümantasyonun anahtarının ılımlılık olduğunu buldum. Hiç kimse birkaç sayfa içinde uykuya dalmadan tasarım dokümantasyonuna sahip 50 sayfalık tam gelişmiş UML diyagramlarını okumayacak. Öte yandan, çoğu insan 5-10 sayfalık basit sınıf diyagramları sistem bir araya getirildi.

UML'yi yararlı bulduğum diğer durum, kıdemli bir geliştiricinin bir bileşen tasarlamaktan sorumlu olduğu, ancak daha sonra tasarımı uygulaması için küçük bir geliştiriciye verdiği durumdur.

UML kullanmak, yürürken ayaklarınıza bakmak gibidir. Genelde bilinçsizce yapabileceğiniz bir şeyi bilinçli ve açık hale getiriyor. Yeni başlayanların ne yaptıkları hakkında dikkatlice düşünmeleri gerekir, ancak profesyonel bir programcı ne yaptıklarını zaten bilir. Çoğu zaman, kodun kendisini yazmak, kod hakkında yazmaktan daha hızlı ve daha etkilidir, çünkü programlama sezgileri göreve ayarlıdır.

Bunun istisnası, geceleri meşalesiz kendinizi ormanda bulmanızın ve yağmurun başlamasının - o zaman düşmemek için ayaklarınıza bakmanız gerekir. Üstlendiğiniz görevin sezginizin üstesinden gelebileceğinden daha karmaşık olduğu zamanlar vardır ve programınızın yapısını açıkça ifade etmeniz ve yavaşlatmanız gerekir. O halde UML, kullanabileceğiniz birçok araçtan biridir. Diğerleri arasında sözde kod, üst düzey mimari diyagramlar ve garip metaforlar bulunur.

Genel iş akışı ve DFD'ler karmaşık süreçler için çok faydalı olabilir. Deneyimlerime göre diğer tüm diyagramlar (ÖZELLİKLE UML) istisnasız acı verici bir zaman ve çaba kaybı olmuştur.

Katılmam gerekir, UML her yerde kullanılır - bir BT projesinin tasarlandığı her yerde UML genellikle orada olacaktır.

Şimdi iyi kullanılıp kullanılmadığı başka bir konu.

Stu'nun dediği gibi, hem Kullanım Durumlarını (kullanım durumu açıklamaları ile birlikte) hem de etkinlik diyagramlarını geliştirici açısından en yararlı buluyorum.

Kalıcılık gibi nesne niteliklerinin yanı sıra ilişkileri göstermeye çalışırken sınıf diyagramı çok yararlı olabilir. Tek bir özellik veya özellik eklemek söz konusu olduğunda, bunlar genellikle aşırıdır, özellikle de kod yazıldıktan sonra hızla güncelliğini yitirirler.

UML ile ilgili en büyük sorunlardan biri, kod oluşturulduktan sonra onu güncel tutmak için gereken iş miktarıdır, çünkü UML'yi koddan yeniden yapılandırabilecek çok az araç vardır ve yine de bunu iyi yapan çok az araç vardır.

Büyük (IBM benzeri) kurumsal geliştirme ortamlarında deneyimim olmadığını belirterek cevabımı nitelendireceğim.

Ben UML ve görüntülemek yolu Rational Unified Process daha olmasıdır KONUŞMA aslında daha yapacağım şey hakkında YAPMAK yapacaksın buysa.

(Başka bir deyişle, büyük ölçüde zaman kaybıdır)

Sadece benim görüşüme göre atın. UML, fikirleri iletmek için harika bir araçtır, tek sorun, onu sakladığınızda ve sürdürdüğünüzde, çünkü aslında aynı bilginin iki kopyasını oluşturuyorsunuz ve genellikle burada patlıyor. İlk uygulama turundan sonra, UML'nin çoğu kaynak koddan üretilmelidir, aksi takdirde çok hızlı bir şekilde güncelliğini yitirecek veya güncel kalması için çok fazla zaman (manuel hatalarla) gerekecektir.

Okuldaki son iki yarıyılda üst düzey bir gelişim projesi dersini birlikte verdim. Proje, ödeme yapan müşteriler olarak yerel kar amacı gütmeyen kuruluşların olduğu bir üretim ortamında kullanılmak üzere tasarlandı. Kodun beklediğimizi yaptığından ve öğrencilerin müşterilerin ihtiyaçlarını karşılamak için gerekli tüm verileri yakaladığından emin olmalıydık.

Sınıf dışında geçirdiğim zaman olduğu gibi ders saati sınırlıydı. Bu nedenle, her sınıf toplantısında kod incelemeleri yapmak zorundaydık, ancak kaydolan 25 öğrenciyle bireysel inceleme süresi çok kısaydı. Bu gözden geçirme oturumlarında en değerli bulduğumuz araç ERD'ler, sınıf diyagramları ve sıra diyagramlarıydı. ERD'ler ve sınıf diyagramları yalnızca Visual Studio'da yapıldı, bu nedenle onları oluşturmak için gereken süre öğrenciler için önemsizdi.

Diyagramlar çok fazla bilgiyi çok hızlı bir şekilde iletti. Öğrencilerin tasarımlarına hızlı bir şekilde göz atarak, kodlarındaki sorunlu alanları hızla ayırabilir ve yerinde daha ayrıntılı bir inceleme yapabiliriz.

Diyagram kullanmadan, problemleri arayan öğrencilerin kod dosyalarına tek tek gitmek için zaman ayırmalıydık.

Bu konuya biraz geç geliyorum ve birkaç küçük noktayı açıklamaya çalışacağım. UML'nin çok geniş anlamda kullanışlı olup olmadığını sormak. Çoğu kişi soruyu tipik / popüler UML'den bir çizim / iletişim aracı perspektifi olarak yanıtlıyor gibiydi. Not: Martin Fowler ve diğer UML kitap yazarları, UML'nin yalnızca iletişim için en iyi şekilde kullanıldığını düşünmektedir. Bununla birlikte, UML'nin başka birçok kullanımı vardır. Her şeyden önce, UML, mantıksal kavramlara eşlenmiş gösterim ve diyagramlara sahip bir modelleme dilidir. UML'nin bazı kullanımları şunlardır:

• İletişim
• Standart Tasarım / Çözüm belgeleri
• DSL (Etki Alanına Özgü Dil) Tanımı
• Model Tanımı (UML Profilleri)
• Desen / Varlık Kullanımı
• Kod Üretimi
• Modelden Modele Dönüşümler

Pascal tarafından yazılanların üzerindeki kullanımlar listesi göz önüne alındığında yeterli değildir, çünkü yalnızca diyagram oluşturma ile ilgilidir. Yukarıdakilerden herhangi biri kritik başarı faktörüyse veya standart bir çözüme ihtiyaç duyan sorunlu alanlarsa, bir proje UML'den yararlanabilir.

Tartışma, UML'nin ne zaman mantıklı olduğunu veya UML'nin kullanılması gerektiği gibi ürünü / çözümü ne zaman geliştireceğini tartışmak için UML'nin nasıl aşırı öldürülebileceğinden veya küçük projelere uygulanabileceğinden genişlemelidir. Desen Uygulaması veya Kod Oluşturma gibi bir geliştiricinin UML'sinin de algılayabileceği durumlar vardır.

UML yıllarca benim için çalıştı. Başladığımda Fowler's UML Distilled'i okudum ve burada "yeterince modelleme / mimari / vb. Yapın" diyorum . Sadece ihtiyacınız olanı kullanın !

Bir QA Mühendisinin bakış açısından, UML diyagramları mantık ve düşüncedeki potansiyel kusurlara işaret eder. İşimi kolaylaştırıyor :)

UML'nin yararlı olduğunu düşünüyorum, sanırım 2.0 spesifikasyonu bir zamanlar net bir spesifikasyon olanı biraz şişirilmiş ve hantal hale getirdi. Bir boşluğu doldurdukları için zamanlama diyagramlarının vs. baskısına katılıyorum ...

UML'yi etkili bir şekilde kullanmayı öğrenmek biraz pratik gerektirir. En önemli nokta net iletişim kurmak, gerektiğinde model olmak ve ekip olarak model olmaktır. Beyaz tahtalar bulduğum en iyi araçtır. Gerçek bir beyaz tahtanın kullanımını yakalamayı başaran herhangi bir "dijital beyaz tahta yazılımı" görmedim.

Bununla birlikte, aşağıdaki UML araçlarını beğendim:

1. Menekşe - Daha basit olsaydı, bir kağıt parçası olurdu

2. Altova UModel - Java ve C # Modelleme için iyi bir araç

3. MagicDraw - Modelleme için en sevdiğim ticari araç

4. Poseidon - Paranın karşılığını fazlasıyla veren iyi bir araç

5. StarUML - En iyi açık kaynak modelleme aracı

UML diyagramları, gereksinimleri yakalamak ve iletmek ve sistemin bu gereksinimleri karşıladığından emin olmak için kullanışlıdır. Yinelemeli olarak ve çeşitli planlama, tasarım, geliştirme ve test aşamalarında kullanılabilirler.

: Konudan Geliştirme Süreci içinde Modelleri Kullanma de http://msdn.microsoft.com/en-us/library/dd409423%28VS.100%29.aspx

Bir model, sisteminizin çalıştığı dünyayı görselleştirmenize, kullanıcıların ihtiyaçlarını netleştirmenize, sisteminizin mimarisini tanımlamanıza, kodu analiz etmenize ve kodunuzun gereksinimleri karşıladığından emin olmanıza yardımcı olabilir.

Aşağıdaki gönderiye cevabımı da okumak isteyebilirsiniz:

"İyi yazılım tasarımı / mimarisi" nasıl öğrenilir? en /programming/268231/how-to-learn-good-software-design-architecture/2293489#2293489

Bu tartışma uzun süredir etkin olmasa da, aklıma gelen önemli birkaç noktayı eklemem gerekiyor.

Buggy kodu bir şeydir. Aşağıya doğru sürüklenmeye bırakıldığında, tasarım hataları gerçekten çok şişkin ve çirkinleşebilir. Ancak UML, kendi kendini doğrulamaktadır. Bununla demek istediğim, modellerinizi çoklu, matematiksel olarak kapalı ve karşılıklı olarak kontrol eden boyutlarda keşfetmenize izin verirken, sağlam tasarım sağlar.

UML'nin bir başka önemli yönü daha vardır: doğrudan en güçlü yeteneğimiz olan görselleştirme yeteneğimizle "konuşur". Örneğin, ITIL V3 (özünde yeterince basit) UML diyagramları biçiminde iletilmiş olsaydı, birkaç düzine A3 katlamasında yayınlanabilirdi. Bunun yerine, gerçekten İncil boyutlarında birkaç formda ortaya çıktı, bütün bir endüstriyi doğurdu, nefes kesici maliyetler ve yaygın katatonik şok.

Sıralı diyagramların ve aktivite diyagramlarının oldukça sık kullanıldığını görüyorum. Diğer sistemlerle etkileşime giren "gerçek zamanlı" ve gömülü sistemlerle çok iş yapıyorum ve sıra diyagramları tüm etkileşimleri görselleştirmede çok yardımcı oluyor.

Kullanım durumu diyagramları yapmayı seviyorum, ancak değerli olduklarını düşünen çok fazla insanla tanışmadım.

Rational Rose'un UML model tabanlı tasarımdan edindiğiniz uygulama türlerine iyi bir örnek olup olmadığını sık sık merak etmişimdir. Şişirilmiş, adamcağız, yavaş, çirkin ...

UML'nin çok küçük projeler için pek kullanışlı olmadığını, ancak daha büyük projeler için gerçekten uygun olduğunu buldum.

Esasen, ne kullandığınız gerçekten önemli değil, sadece iki şeyi aklınızda tutmanız gerekiyor:

• Bir çeşit mimari planlama istiyorsun
• Ekipteki herkesin proje planlaması için aslında aynı teknolojiyi kullandığından emin olmak istersiniz.

Yani UML tam da şudur: Projelerinizi nasıl planladığınıza dair bir standart. Yeni insanları işe alırsanız, mevcut şirket içi eşyalarınızdan ziyade mevcut standartları (UML, Flowchard, Nassi-Schneiderman vb.) Bilmek daha olasıdır.

Tek bir geliştirici ve / veya basit bir yazılım projesi için UML kullanmak bana aşırı geliyor, ancak daha büyük bir takımda çalışırken, yazılım planlaması için kesinlikle bazı standartlar istiyorum.

UML yararlıdır, evet gerçekten! Yaptığım ana kullanımlar şunlardı:

• Bir yazılım parçasının nasıl çalışması gerektiği hakkında beyin fırtınası yapmak. Ne düşündüğünüzü iletmeyi kolaylaştırır.
• Bir sistemin mimarisini, modellerini ve sınıflarının temel ilişkilerini belgelemek. Takımınıza birisi girdiğinde, ayrılırken ve halefinizin bunu anlayacağından emin olmak istediğinizde ve sonunda o küçük sınıfın ne anlama geldiğini unuttuğunuzda yardımcı olur.
• Yukarıdaki nokta ile aynı nedenlerle tüm sistemlerinizde kullandığınız herhangi bir mimari deseni belgelemek

Michael'a yalnızca tek bir geliştirici ve / veya basit bir yazılım projesi için UML kullanmanın ona aşırı bir şey geldiğini söylediğinde katılmıyorum . Küçük kişisel projelerimde kullandım ve onları UML kullanarak belgelendirmek, yedi ay sonra onlara geri döndüğümde ve tüm bu sınıfları nasıl oluşturduğumu ve bir araya getirdiğimi tamamen unuttuğumda bana çok zaman kazandırdı.

Fowler tarafından "UML Distilled" adlı kitabında anlatıldığı gibi Cockburn tarzı UML balık, uçurtma ve deniz seviyesinde kullanım durumlarını kullanmanın bir yolu olabileceğine inanıyorum. Benim fikrim, kod okunabilirliği için bir yardımcı olarak Cockburn kullanım durumlarını kullanmaktı.

Bu yüzden bir deney yaptım ve burada bununla ilgili "UML" veya "FOWLER" Etiketi olan bir yazı var. C # için basit bir fikirdi. Cockburn kullanım durumlarını programlama yapılarının ad alanlarına yerleştirmenin bir yolunu bulun (sınıf ve iç sınıf ad alanları gibi veya numaralandırma için ad alanlarını kullanarak). Bunun uygulanabilir ve basit bir teknik olabileceğine inanıyorum, ancak yine de soruları var ve kontrol etmek için başkalarına ihtiyaç var. Herhangi bir dil uzantısı olmadan c # kodunun tam ortasında bulunabilen bir tür sözde Etki Alanına Özgü Dile ihtiyaç duyan basit programlar için iyi olabilir.

Lütfen ilgileniyorsanız gönderiye göz atın. Buraya gidin .

UML ile yaşadığım sorunlardan biri, şartnamenin anlaşılabilirliğidir. Belirli bir diyagramın anlamını gerçekten anlamaya çalıştığımda, meta-modeller ve meta-meta-modeller labirentinde çabucak kayboluyorum. UML'nin satış noktalarından biri, doğal dilden daha az belirsiz olmasıdır. Bununla birlikte, iki veya daha fazla mühendis bir diyagramı farklı şekilde yorumlarsa, hedefte başarısız olur.

Ayrıca, birkaç UML forumunda süper yapı belgesi hakkında ve OMG'nin üyelerine çok az sonuçla veya hiç sonuç alamadan belirli sorular sormayı denedim. UML topluluğunun henüz kendini destekleyecek kadar olgun olduğunu düşünmüyorum.

Bir öğrenciden geldiğimde, UML'nin çok az kullanıldığını görüyorum. PROGAMERS'ın gerekli olduğunu söylediğiniz şeyleri otomatik olarak oluşturacak bir program geliştirmemiş olmasını ironik buluyorum. Verilerin parçalarını çekebilen, tanımları arayabilen ve ürün yanıtlarını yeterince arayabilen bir özelliği Visual Studio'da tasarlamak son derece basit olacaktır, böylece herkes ona büyük ya da küçük bakabilir ve programı anlayabilir. Bu aynı zamanda bilgiyi güncel tutacaktır çünkü bilgiyi üretmek için bilgiyi doğrudan koddan alacaktır.

UML, alanları ve yöntemleriyle bir sınıfı temsil ettiğiniz anda kullanılır, ancak bu sadece bir tür UML diyagramıdır.

UML ile ilgili sorun, kurucuların kitabının çok belirsiz olmasıdır.

UML sadece bir dildir, gerçek bir yöntem değildir.

Bana gelince, Açık Kaynak Projeleri için UML şemasının eksikliğini gerçekten can sıkıcı buluyorum. Wordpress gibi bir şey alın, sadece bir veritabanı şemanız var, başka bir şey yok. Büyük resmi elde etmek için kodeks api'de dolaşmanız gerekir.

UML'nin yeri var. Projenin boyutu büyüdükçe önemi giderek artıyor. Uzun süren bir projeniz varsa, her şeyi UML'de belgelemek en iyisidir.

UML, büyük ekiplerin bulunduğu büyük projeler için iyi görünüyor. Ancak iletişimin daha iyi olduğu küçük takımlarda çalıştım.

UML benzeri diyagramları kullanmak, özellikle planlama aşamasında iyidir. Kodla düşünme eğilimindeyim, bu yüzden büyük özellikler yazmayı zor buluyorum. Girdileri ve çıktıları yazmayı ve geliştiricilerin biti ortada tasarlamasını tercih ederim.

UML'nin, insanları sınıfları arasındaki ilişkileri düşünmeye sevk ettiği için faydalı olduğuna inanıyorum. Bu tür ilişkiler hakkında düşünmeye başlamak iyi bir başlangıç ​​noktasıdır, ancak kesinlikle herkes için bir çözüm değildir.

Benim inancım, UML kullanımının, geliştirme ekibinin çalıştığı duruma göre öznel olduğu yönünde.

Tecrübelerime göre:

Anlamlı kod diyagramları oluşturma ve iletme yeteneği, yeni kod geliştiren veya mevcut kodu anlamaya çalışan herhangi bir yazılım mühendisi için gerekli bir beceridir.

UML'nin özelliklerini bilmek - ne zaman kesikli çizgi veya daire uç noktası kullanılmalı - o kadar gerekli değildir, ancak yine de sahip olmak iyidir.

UML iki şekilde kullanışlıdır:

• Teknik taraf: birçok kişi (yönetici ve bazı işlevsel analistler) UML'nin lüks bir özellik olduğunu düşünüyor çünkü Kod dokümantasyondur: hata ayıkladıktan ve düzelttikten sonra kodlamaya başlarsınız . UML diyagramlarının kod ve analizlerle senkronizasyonu sizi müşterinin isteklerini iyi anlamaya zorlar;

• Yönetim tarafı: UMl diyagramları, hatalı olan müşterinin ihtiyaçlarının bir aynasıdır: UML olmadan kodlarsanız, belki de saatler süren çalışmalardan sonra ihtiyaçlarda bir hata bulabilirsiniz. Diyagramlar UML, olası tartışmalı noktaları bulmanızı ve kodlama => planlamanıza yardımcı olmadan önce çözmenizi sağlar.

Genel olarak, UML diyagramları olmayan tüm projelerin yüzeysel bir analizi vardır veya boyutları kısadır.

Linkedin SİSTEM MÜHENDİSLERİ grubundaysanız , eski tartışmama bakın .

Sonunda, UML yalnızca RUP nedeniyle mevcuttur. Java / .Net'i kullanmak için UML'ye veya bununla ilgili herhangi bir öğeye ihtiyacımız var mı? Pratik cevap, yeterli olan ve işimizi yapmamızı sağlayan kendi belgelerine (javadoc vb.) Sahip olmalarıdır!

UML no thanx.

UML, tıpkı junit'in gerekli olduğu gibi kesinlikle faydalıdır. Her şey fikri nasıl sattığına bağlı. Programınız, birim testleri olmadan çalışacağı gibi UML olmadan da çalışacaktır. Bunu söyledikten sonra, kodunuza bağlı olarak do UML oluşturmalısınız, yani UML diyagramlarını güncellediğinizde, kodunuzu günceller veya kodunuzu güncellediğinizde UML'yi otomatik olarak oluşturur. Sadece yapmak uğruna yapmayın.

UML'nin sektördeki yeri kesinlikle vardır. Boing uçağı veya başka bir karmaşık sistem için yazılım geliştirdiğinizi hayal edin. UML ve RUP burada çok yardımcı olacaktır.

UML, insanlar arasındaki iletişim yöntemlerinden sadece biridir. Beyaz tahta daha iyidir.