Bu yüzden üniversitedeyken UML'nin yararı ve kod geliştirme konusundaki geleceği hakkında eğitim aldım.

Ancak sektör tecrübelerime göre şemaları kullanırken - ER şemalarından, sınıf şemalarından, durum şemalarından iş akış şemalarına kadar - bunların iletişim amaçlı olduğunu gördüm.

Başka bir deyişle, kodları otomatik olarak diyagramlardan oluşturmadım ve bir iletişim açısından genel olarak diyagramlarımı olabildiğince basit ve anlaşılması kolay tutmaya çalışıyorum.

Ancak Visio ve Enterprise Architect’e baktığımda, çoğu kullanmadığım birçok farklı grafik, şekil, özellik nesnesi var gibi görünüyor.

İnsanlar kod veya veritabanı oluşturma gibi daha karmaşık şeyler yapmak için UML kullanıyor mu?

Evet, UML CASE araçları 90'lı yılların en popüler ürünlerinden biriydi ... ve teslim edilemedi.

Bunun temel nedeni, UML (veya diğer birçok tür diyagram) diyagramının sorunu ve / veya bunu yalnızca diyagramda çözen programı anlamaya yardımcı olması ve gerçek kodun uygulama ayrıntılarını ortadan kaldırmasıdır . Bu nedenle (önemsiz herhangi bir kod parçası için), anlaşılması kolay bir diyagram kod oluşturmak için kullanışsızdır , çünkü gerekli ayrıntılara sahip değildir. Ve bunun tersi durumda, doğrudan kod oluşturma için kullanılabilen bir şema, programı kodun kendisinden daha iyi anlamanıza yardımcı olmaz . Üretim kodundan ters olarak tasarlanmış bir UML sınıf şeması gördüyseniz, muhtemelen ne demek istediğimi biliyorsunuzdur.

Bildiğim tek potansiyel istisna, yalnızca kendi kodunu içermeyen Varlık-İlişki diyagramlarıdır (sadece adlarının da ima ettiği gibi) veri parçaları ve ilişkileri. Ancak, test edilen ORM gibi özel amaçlı araçlar / alanlar dışında, gerçek kod üretimi için [Güncelleme] - yani sınıf iskeletlerinden ve alıcılar / ayarlayıcılar gibi önemsiz kodlardan daha fazla - herhangi bir UML diyagramını kullanma girişimi hiç duymadım Doc Brown tarafından [/ Güncelleme] altında , ve bunun bir kaza olmadığını düşünüyorum.

Şahsen UML'den nefret etmiyorum - UML diyagramlarının tasarım tartışmaları sırasında niyetinizi ve fikirlerinizi göstermek veya uygulamanızın mimarisini görselleştirmek için harika bir iletişim aracı olabileceğini düşünüyorum . Ancak onları bu konuda tutmak en iyisidir ve iyi olmadıkları şeyler için kullanmaya çalışmayın.

Böylece, üniversitedeyken (bir süre önce), UML'nin geleceği olduğu söylendi, UML programlamanın yerini alacak ve sadece şemalardan kod üretecektik.

Yanılıyorlardı. Bu, insanların konuşmayı bırakıp mağara resmine döndüğü zaman olacak.

Gerçek dünyadaki sorunlar ve bunları çözen programlar, azaltılamayan önemli bir karmaşıklığa sahiptir. Çalışan bir program üretmek için, bu karmaşıklık yakalanabilir ve çalıştırılabilir bir dilde ifade edilmelidir. Soru, bazı şematik programlama dilinin, metinsel bir programlama diline göre daha etkili olup olmadığıdır. Yaklaşık otuz yıldır diyagramatik programlamayı deniyoruz ve şu ana kadar kanıtlar ezici bir şekilde metinsel programlama lehine. Diyagramlardan kod oluşturma ile üretilen önemli bir uygulamanın farkında değilim.

HAYIR

Efsane, şu yazılı başarısız varsayımına dayanıyordu:

class ClassName extends SomeThing
{

}

... zor ve otomasyona ihtiyaç var .

Ara sıra inananları veya inananların kalabalığını hala bulabilirsiniz .
Ama bu, dinler ve kültlerle böyle yürüyor.

Orada bulundum, çok yararlı bulamadım.

Genellikle bunlardan bazı kodlar üretebilecek kadar spesifik olan şemalar, çoğunlukla sınıf şeması, aslında programı anlama yolunda fazla bir şey katmaz ve kullanım durumu ya da genel bakış düzeyinde aktivite gibi genel bakış şemalarından kod oluşturamazsınız. belgeler için çok önemlidir. Anlamak için yararlı olan ve koddan üretilen kodlara sahip olabilecek bir diyagram, durum makinesine gerçekten ihtiyacınız olduğunda kullanışlı olan durum çizelgesidir. Ancak, genellikle bunlardan kaçınmaya çalışmalısınız, çünkü bunlar doğal olarak hataya açıktır.

Bir projede, kodu UML modellerindeki (Rhapsody) tasarlamamız ve oradan oluşturmamız gerekiyordu. Bu tür çalıştı ve muhtemelen başlıkları (C ++) ve prototipleri elle yazmaktan çok daha kolaydı. Bu ikisini otomatik olarak tutarlı tutabilmek biraz kullanışlıydı.

Yöntem gövdelerinin hala el ile doldurulması gerekiyordu, çünkü diyagramlar durum makinesi iskeletlerinin haricinde bunu gerçekten temsil edemezdi.

Öte yandan oldukça karmaşık, bu yüzden çok fazla şey öğrenmek zorundasınız ve daha da önemlisi birleşmesi gereken acıydı. Birleştirme, metin dosyaları için iyi araştırılmış ve onlarla birlikte çalışmaktadır, ancak hiç kimse diyagramlardaki değişiklikleri birleştirmek için kolay bir yol bulamadı. Rhapsody aslında üretilen koddaki bilginin bir kısmını tutar ve geri ayrıştırır, bu yüzden tamamen kullanılamazdı, ama yine de ciddi bir komplikasyondu.

Doğruca UML modellerinden kod üretmek (ve hatta tüm sistemleri oluşturmak) kesinlikle mümkün olsa da, bu şekilde kullanıldığında hiç karşılaşmadım.

Tecrübelerime göre, çoğu şirket bunu gereksinimler için bir iletişim aracı olarak ya da “Diyagram çizme için MS Paint” olarak kullanıyor gibi görünmektedir.

Yapmak istediğim önemli bir ayrım, çoğu UML modelleme aracının sisteminizin tek bir modelini oluşturmanıza izin vermesidir. Örneğin, Visio, UML'nin nasıl çalıştığını oldukça iyi anlıyor ve doğrudan diyagramla ilgili olmayan ekleyebileceğiniz birçok şey var. Gerçek şemalar, modelin bölümleri üzerinde basitçe farklı bakış açılarıdır ve sistemin farklı yönlerini vurgulamanıza olanak tanır.

hepsi (model şemaları) iletişim amaçlıdır

Modelleme, yazılım geliştirme sürecinde 4 önemli kullanım alanına sahiptir:

1. Entegre Tasarım aracı

2. İletişim aracı

3. Yazılım üretimi için bir yardım

4. Gerçek-kelime probleminin karmaşıklığını azaltmanın bir yolu (bunu yukarıdaki kevin cline'nin tepkisinden öğrendim)

5. Modelleme süreci, bazı tasarımcıların kodlama sırasında dikkate alınmayan detaylar hakkında düşünmelerini sağlar (ve bunun tersi de geçerlidir). Tasarım zamanında modelleme, bir yöntemi veya dili bir dilde kodlamaktan daha büyük bir resim düşünmenize olanak sağlar.

Bence modelleme, veri tabanları oluşturmak (ER Diyagramları), proses akışlarını anlamak (Aktivite Diyagramları) ve kullanıcı-sistem etkileşimlerini anlamak için hayati öneme sahiptir (Vaka diyagramlarını kullanın).

İnsanlar kod veya veritabanı oluşturma gibi daha karmaşık şeyler yapmak için UML kullanıyor mu?

Evet kesinlikle. ERD'ler (UML şeması değil) ve Sınıf Şemaları (aracınızın özelliklerine bağlı olarak) aşağıdakileri oluşturmak için kullanılabilir:

1 - Veri Tanımlama Dili (DDL)

2 - CRUD ve Sınıf Diyagramları için tercih ettiğiniz dilde Saklı Prosedürler (ORM araçları bu konuda daha fazla şey yaptığından daha az faydalıdır)

Modelleme araçlarının en değerli özellikleri arasında:

1 - Modelin bütünlüğünü koruyabilme. Bir değişiklik yaparsanız modelde yayılır

2 - Kullanılan soruları cevaplayabilme (modelimde kullanılan 'hesap' nerededir?)

3 - Eşzamanlı kullanıcıların model üzerinde çalışmasına izin verme

4 - Grafiksel gösterimler içinde ara

5 - Baskı kontrolü

6 - Her seferinde bir katmana odaklanabilmeniz için katmanlama (diyagram öğelerinizi katmanlarda düzenleme)

7 - Çeşitli veritabanı sistemleri için veritabanı kodu üretimi

8 - Model doğrulama (tutarlılığı, eksik anahtarları, döngüleri vb. Kontrol eder)

Bu yüzden, modelleme araçları, özellikle de iyi olanlar, Paint'ten çok daha fazlasını yapar.

Yazılım Mimarı'nı, üst düzey tasarımlar yapmak ve eşyalarımızdaki daha eğlenceli bileşen etkileşimlerini belgelemek için kullanıyoruz. Bazen uygulamanın iskeletini diyagramlardan oluştururuz, ancak bu yapıldığında, her ikisini de ayrı tutarız, tamamlandıktan sonra kodu bir diyagrama geri döndürmeye çalışmaz. Küçük programlar için oldukça iyi çalışan Rational XDE adlı bir araç kullanırdım, ancak Swing etkinlik işleyicilerini eklemeye başladığınızda veya Struts ile çalışmaya çalıştığınızda kaybolurdu.

İnsanların UML'de yazmama nedeninin büyük bir kısmı, UML'deki her şeyi tamamen belirtip daha sonra şemanızdan kodu oluşturmak için çok daha fazla çalışmanın gerekli olduğunu düşünüyorum. ABD DoD’unun OMG ile birlikte çalıştığını ve doğrulanmış olan diyagramlardan “kanıtlanmış” kod üretecek bazı araçlar geliştirmek için çalıştığını biliyorum, ama benim izlenimim, gerçek koddan daha fazla meta veri siparişi vereceğinizdir. Muhtemelen iyidir (sonuçta belgeler), ancak meta veri üretmek kod yazmaktan daha hızlı değildir, bu yüzden harcamaları orantılı olarak daha fazla zaman harcarsınız.

UML'nin kendisi bir gösterim sistemidir, böylece iletişim ve belgelemeye neden olur. UML modelinden kod üretmek nadirdir, ancak bunu yapan adamlar var. Muhtemelen kullanıcılar bunu Rose'dan daha sık yaparlar. Zor kısım, model ve kodu senkronize tutmaktır, gerçek projelerin çoğu için maliyeti çok yüksektir.

En son projemde UML-Lab kullanıyorum (https://www.uml-lab.com). Bu, modelin de tersine mühendislik edilmesini sağlayan hoş bir araçtır. Araç, java kodunu ve hatta oldukça doğru olan JPA ek açıklamalarını oluşturur.

Bir takımda çalışırken bunun zorluğu. Model statiktir ve birden fazla geliştirici değişikliği ile senkronize kalmasını biraz zorlaştıran tek bir kaynakta bulunur. Araştırıyorsanız araştırmak ve başkalarıyla karşılaştırmak için iyi bir zaman olan 1 ay boyunca kullanılabilen deneme sürümü vardır.

Bu, kod oluşturma ile birlikte tek seferde Nesne modelleme ve veri modelleme yapan bir ürün gördüm.

Aksi takdirde geçmiş projelerimde her zaman yanlış veya çok detaylı olan eski modeller gördüm.

Geçmiş projelerimde bazen tersine mühendislikle diyagramlar oluşturdum. Diyagramların bulduğum çoğu zaman karışık olduğu ve tüm gürültüyü elle filtreleyerek çizmeyi tercih ettim.

Kod üretmek için UML kullanabiliriz. İş mantığı değil, çünkü iş mantığı standart değildir ve uygulamaya göre değişir. ER diyagramları ile birlikte sınıf diyagramları, arayüzler, sınıflar, kış uykusundaki varlıklar, temel dao yöntemleri, vb. Üretmek için kullanılabilir. Cephe uygulaması, veri tipi dönüştürücüler (örneğin, nesneleri transfer etmek için varlık) gibi diğer boyler kodu da, nesne şekillerinin yardımı ile üretilebilir. .

Ayrıca, önceki yorumlarda belirtildiği gibi, veritabanı şeması, DDL komut dosyaları vb. Modeller kullanılarak üretilebilir.

OAW ve Enterprise Architect gibi modelleme araçlarını kullanarak, daha basit kod üreteçleri yazabiliriz, bu da yapılandırma dosyaları, kalıplaşmış kalıplar ve etiketli değerler kullanarak fabrika kodu üretmeye yardımcı olabilir.

Neden Business Object gibi araçlara sahip iş zekasının neden tüm şirket bilgilerinin analizini yapabildiğini ve faydalanabildiğini anlamıyorum, teknolojik düzeyde hala sadece kod düzeyinde veya UML ile soyut düzeyde çalışıyoruz !!

Sorun UML değil, UML ve MOF arasında model dönüşümü ve bir clas şemasından veya xmi'den şablonlar kullanarak kod üretimidir. UML'nin gerçek dünyaya soyut bir bakış açısı kazandırdığı söylenir, bu nedenle sadece gerçekten neyin önemli olduğunu görürsünüz. UML şeması gerçek dünyanın sadece bir görüntüsü ise, doğru kodun nasıl üretileceğini söylemiştiniz? Bu imkansızdır ve bu nedenle bir modelden kod üreten model odaklı geliştirme başarısız olmuştur.

Çözüm, gerçek dünyayı ve dolayısıyla tüm proje kodlarını tek bir UML modeline eşlemeye dönüştürmektir. Tek bir modele ve proje tam mantığına sahip olmak, daha sonra her seferinde koddan değil modelden görünümler oluşturabilirsiniz. Java / Jee teknolojisinde Omondo tarafından yapılan cesur bir girişim var. Konsept, MOF ve UML'yi doğrudan kod ve ORM ile senkronize eder. UML şeması şimdi tüm projenin haritasını çıkaran modelin sadece yüksek seviyeli bir görüntüsüdür. Projeyi daha iyi anlamak için yüzlerce görünüm oluşturabilir, yüzlerce not ekleyebilir, vb. Kod yalnızca eleman değiştiğinde veya oluşturulduğunda üretilecektir. MOF ve UML arasındaki geleneksel dönüşüm köprüsü olmadan Java Id'nin UML kimliğiyle eşleştirildiği muhteşem teknoloji.

Ayrıca etkileyici olan, etki alanımı UML düzeyinde modelleyebilmek ve ORM ek açıklamalarımı doğrudan koda dahil edebilmek ve bu nedenle Hazırda Bekletme kullanarak kalıcı bir tümleştirmeyle oluşturabilir, silebilir, veritabanımı oluşturabilir, dağıtabilir ... UML, projenin mimarisinin değil tüm mimarinin bir parçasıdır.

Kodla canlı senkronizasyon yapıldığında UML tarafından asla üst düzey izleyici olarak hiç hayal kırıklığına uğramadım, ancak Model güdümlü geliştirme şablonları kod oluşturma ile MDA kullanılarak geleneksel olarak kesinlikle mahvoldu. Modelden kod oluşturma, bir sözcük belgesinden gelen bir HTML sayfası gibidir. Oluşturulduktan sonra nasıl değiştirilir? Güncellemek imkansızdır ve kodu temizlemek için sıfırdan yazmak yerine daha fazla zaman harcarsınız!