Birleştirilmiş Modelleme Dili - Unified Modeling Language

"UML" Burada yönlendirir. Diğer kullanımlar için bkz. UML (anlam ayrım) .
UML logosu

Unified Modeling Language ( UML ) genel amaçlı, gelişimsel olduğu modelleme dil alanında yazılım mühendisliği bir sistemin tasarımını görselleştirmek için standart bir yol sağlamak üzere tasarlanmıştır.

UML'nin yaratılması, başlangıçta, farklı gösterim sistemlerini ve yazılım tasarımına yaklaşımları standartlaştırma arzusuyla motive edildi. Hiç de geliştirildi Akılcı Software 1996 ile onlara önderlik daha da geliştirilmesi ile, 1994-1995 yılları arasında.

1997 yılında UML, Object Management Group (OMG) tarafından bir standart olarak kabul edildi ve o zamandan beri bu organizasyon tarafından yönetiliyor. 2005 yılında UML, Uluslararası Standardizasyon Örgütü (ISO) tarafından da onaylanmış bir ISO standardı olarak yayınlanmıştır. O zamandan beri standart, UML'nin en son revizyonunu kapsayacak şekilde periyodik olarak revize edilmiştir. Yazılım mühendisliğinde çoğu uygulayıcı UML kullanmaz, bunun yerine resmi olmayan elle çizilmiş diyagramlar üretir; Ancak bu diyagramlar genellikle UML'den öğeler içerir.

Tarih

Nesne yönelimli yöntemlerin ve gösterimin tarihçesi

UML 1.0'dan önce

UML 1990'ların ikinci yarısından beri gelişmektedir ve kökleri 1980'lerin sonunda ve 1990'ların başında geliştirilen nesne yönelimli programlama yöntemlerine dayanmaktadır . Zaman çizelgesi (resme bakın), nesne yönelimli modelleme yöntemleri ve gösterim tarihinin önemli noktalarını gösterir.

Orijinal olarak Booch yöntemi , nesne modelleme tekniği (OMT) ve tek bir dile entegre ettiği nesne yönelimli yazılım mühendisliği (OOSE) notasyonlarına dayanmaktadır .

Rational Software Corporation , 1994 yılında General Electric'ten James Rumbaugh'u işe aldı ve bundan sonra şirket, günün en popüler nesne yönelimli modelleme yaklaşımlarından ikisinin kaynağı oldu: Rumbaugh'un nesne modelleme tekniği (OMT) ve Grady Booch'un yöntemi. Kısa bir süre sonra çabalarında , 1995 yılında Rational'de onlara katılan nesne yönelimli yazılım mühendisliği (OOSE) yönteminin yaratıcısı Ivar Jacobson tarafından desteklendiler .

UML 1.x

Bu üçünün (Rumbaugh, Jacobson ve Booch) teknik liderliği altında, Unified Modeling Language (UML) spesifikasyonunu tamamlamak ve standardizasyon için Object Management Group'a (OMG) önermek için 1996 yılında UML Partners adlı bir konsorsiyum düzenlendi . Ortaklık ayrıca ilgili diğer tarafları da içeriyordu (örneğin, HP , DEC , IBM ve Microsoft ). UML Partners'ın UML 1.0 taslağı, Ocak 1997'de konsorsiyum tarafından OMG'ye önerildi. Aynı ay içinde UML Ortakları , spesifikasyonu tamamlamak ve diğer standardizasyon çabalarıyla bütünleştirmek için, Cris Kobryn başkanlığında ve Ed Eykholt tarafından yönetilen dil yapılarının tam anlamını tanımlamak üzere tasarlanmış bir grup oluşturdu . Bu çalışmanın sonucu olan UML 1.1, Ağustos 1997'de OMG'ye sunulmuş ve Kasım 1997'de OMG tarafından kabul edilmiştir.

İlk sürümden sonra, dili geliştirmek için 1.3, 1.4 ve 1.5 gibi birkaç küçük revizyon yayınlayan bir görev gücü oluşturuldu.

Ürettiği standartlar (ve orijinal standart) belirsiz ve tutarsız olarak kaydedilmiştir.

kardinalite gösterimi

Veritabanı Chen, Bachman ve ISO ER diyagramlarında olduğu gibi , bazı yazarlar ( diğerlerinin yanı sıra Merise , Elmasri & Navathe) roller için aynı tarafı veya "buraya bak"ı tercih etse de , sınıf modelleri "karşıya bakma" kardinalitelerini kullanacak şekilde belirtilir. ve hem minimum hem de maksimum kardinaliteler. Son zamanlardaki araştırmacılar (Feinerer, Dullea ve diğerleri), UML ve ER diyagramları tarafından kullanılan "karşıya bakma" tekniğinin kesinlikle 2'den büyük n- ary ilişkilere uygulandığında daha az etkili ve daha az tutarlı olduğunu göstermiştir.

Feinerer şöyle diyor: "UML ilişkilendirmeleri için kullanılan bakış açısı semantiği altında çalışırsak sorunlar ortaya çıkar. Hartmann bu durumu araştırır ve farklı dönüşümlerin nasıl ve neden başarısız olduğunu gösterir." ve: "İlerideki birkaç sayfada göreceğimiz gibi, karşılıklı bakış yorumlaması, basit mekanizmaların ikili ilişkilerden n -ary ilişkilere genişletilmesini engelleyen çeşitli zorluklar ortaya çıkarır."

UML 2

UML 2.0 ana revizyonu, 2005'te, dilin özelliklerinin kullanımıyla ilgili yeni deneyimi yansıtacak şekilde daha da geliştirmek için genişletilmiş bir konsorsiyum ile geliştirilen sürüm 1.5'in yerini aldı.

UML 2.1 hiçbir zaman resmi bir belirtim olarak yayımlanmamasına rağmen, 2.1.1 ve 2.1.2 sürümleri 2007'de çıktı, ardından UML 2.2 Şubat 2009'da yayınlandı. UML 2.3 resmi olarak Mayıs 2010'da yayımlandı. UML 2.4.1 resmi olarak Ağustos 2011'de yayımlandı. UML 2.5 Ekim 2012'de "Devam ediyor" versiyonu olarak yayınlandı ve resmi olarak Haziran 2015'te yayınlandı. Resmi sürüm 2.5.1 Aralık 2017'de kabul edildi.

UML 2.x belirtiminde dört bölüm vardır:

  • Diyagramlar ve bunların model elemanları için gösterimi ve semantiği tanımlayan Üstyapı
  • Üstyapının dayandığı çekirdek üst modeli tanımlayan Altyapı
  • Nesne Kısıtlama Dil modeli elemanları için kurallar tanımlamak için (OCL)
  • UML 2 diyagram düzenlerinin nasıl değiş tokuş edildiğini tanımlayan UML Diyagram Değişimi

UML 2.4.1'e kadar bu standartların en son sürümleri şunlardı:

  • UML Üstyapı sürüm 2.4.1
  • UML Altyapısı sürüm 2.4.1
  • OCL sürüm 2.3.1
  • UML Diyagram Değişimi sürüm 1.0.

2.5 sürümünden bu yana, UML Spesifikasyonu basitleştirilmiştir (Üstyapı ve Altyapı olmadan) ve bu standartların en son sürümleri şu anda:

  • UML Spesifikasyonu 2.5.1
  • OCL sürüm 2.4

Dille ilgili sorunları çözen revizyon görev gücü tarafından güncellenmeye ve geliştirilmeye devam ediyor.

Tasarım

UML, bir sistemin mimari planlarını bir diyagramda görselleştirmenin bir yolunu sunar, bunlara aşağıdakiler gibi unsurlar dahildir:

Başlangıçta nesne yönelimli tasarım dokümantasyonu için tasarlanmış olmasına rağmen, UML daha geniş bir tasarım dokümantasyon setine (yukarıda listelendiği gibi) genişletilmiştir ve birçok bağlamda faydalı bulunmuştur.

Yazılım geliştirme yöntemleri

UML kendi başına bir geliştirme yöntemi değildir; ancak, OMT , Booch yöntemi , Objectory ve özellikle Rational Software'de çalışmaya başladığında kullanılması amaçlanan RUP gibi zamanının önde gelen nesne yönelimli yazılım geliştirme yöntemleriyle uyumlu olacak şekilde tasarlanmıştır .

modelleme

UML modeli ile bir sistemin diyagramları seti arasında ayrım yapmak önemlidir. Diyagram, bir sistem modelinin kısmi grafik temsilidir. Diyagram setinin modeli tamamen kapsaması gerekmez ve bir diyagramın silinmesi modeli değiştirmez. Model, model öğelerini ve diyagramlarını (yazılı kullanım durumları gibi) yönlendiren belgeleri de içerebilir.

UML diyagramları, bir sistem modelinin iki farklı görünümünü temsil eder:

UML modelleri , XML Meta Veri Değişimi (XMI) formatı kullanılarak UML araçları arasında değiştirilebilir .

UML'de davranış modelleme için en önemli araçlardan biri, OOSE'nin neden olduğu kullanım durumu modelidir . Kullanım durumları, bir sistemin gerekli kullanımlarını belirtmenin bir yoludur. Tipik olarak, bir sistemin gereksinimlerini, yani bir sistemin yapması gereken şeyi yakalamak için kullanılırlar.

diyagramlar

UML diyagramı türleri
Yapısal UML diyagramları
Davranışsal UML diyagramları

UML 2, iki kategoriye ayrılan birçok diyagram türüne sahiptir. Bazı türler yapısal bilgileri temsil eder ve geri kalanı , etkileşimlerin farklı yönlerini temsil eden birkaçı da dahil olmak üzere genel davranış türlerini temsil eder . Bu diyagramlar, aşağıdaki sınıf diyagramında gösterildiği gibi hiyerarşik olarak kategorize edilebilir:

Bir sınıf diyagramı olarak gösterilen UML 2.2 Diyagramlarının Hiyerarşisi

Bu diyagramların tümü, kullanım, kısıtlama veya amacı açıklayan yorumlar veya notlar içerebilir.

Yapı diyagramları

Yapı diyagramları sistemin statik yönlerini temsil eder. Modellenen sistemde olması gerekenleri vurgular. Yapı diyagramları yapıyı temsil ettiğinden , yazılım sistemlerinin yazılım mimarisini belgelemede yaygın olarak kullanılırlar . Örneğin, bileşen diyagramı , bir yazılım sisteminin bileşenlere nasıl bölündüğünü açıklar ve bu bileşenler arasındaki bağımlılıkları gösterir.

davranış diyagramları

Davranış diyagramları sistemin dinamik yönünü temsil eder. Modellenen sistemde ne olması gerektiğini vurgular. Davranış diyagramları bir sistemin davranışını gösterdiğinden, yazılım sistemlerinin işlevselliğini tanımlamak için yaygın olarak kullanılırlar. Örnek olarak, etkinlik diyagramı , bir sistemdeki bileşenlerin iş ve operasyonel adım adım faaliyetlerini açıklar.

Etkileşim diyagramları

Davranış diyagramlarının bir alt kümesi olan etkileşim diyagramları, modellenen sistemdeki şeyler arasındaki kontrol ve veri akışını vurgular . Örneğin, sıra diyagramı , nesnelerin bir dizi mesajla ilgili olarak birbirleriyle nasıl iletişim kurduğunu gösterir.

metamodelleme

Ana madde: Meta-Nesne Tesisi
Meta-Nesne Tesisinin İllüstrasyonu

Nesne Yönetim Grubu (OMG), UML'yi tanımlamak için Meta-Nesne Tesisi adı verilen bir meta modelleme mimarisi geliştirdi . MOF, sağdaki resimde gösterildiği gibi dört katmanlı bir mimari olarak tasarlanmıştır. En üstte M3 katmanı adı verilen bir meta-meta modeli sağlar. Bu M3-modeli, Meta-Object Facility tarafından M2-modelleri adı verilen metamodeller oluşturmak için kullanılan dildir.

Layer 2 Meta-Object Facility modelinin en belirgin örneği, UML'nin kendisini tanımlayan UML metamodelidir. Bu M2 modelleri, M1 katmanının öğelerini ve dolayısıyla M1 modellerini tanımlar. Bunlar, örneğin UML ile yazılmış modeller olabilir. Son katman, M0 katmanı veya veri katmanıdır. Sistemin çalışma zamanı örneklerini tanımlamak için kullanılır.

Meta-model, stereotipleme adı verilen bir mekanizma kullanılarak genişletilebilir . Bu, Brian Henderson-Sellers ve Cesar Gonzalez-Perez tarafından "UML 1.x ve 2.0'da Stereotip Mekanizmasının Kullanımları ve Suistimalleri"nde yetersiz / savunulamaz olarak eleştirildi .

Benimseme

UML birçok bağlam için pazarlanmıştır.

Zaman zaman, sorunlara yol açan bir tasarım gümüş mermisi olarak ele alındı . UML kötüye kullanımı, aşırı kullanımı (gereksiz olan, sistemin her parçasını onunla tasarlamak) ve acemilerin onunla tasarım yapabileceğini varsaymayı içerir.

Birçok yapıya sahip büyük bir dil olarak kabul edilir . Bazı insanlar ( Jacobson dahil ), UML'nin boyutunun onu öğrenmeyi (ve dolayısıyla kullanmayı) engellediğini düşünüyor.

Ayrıca bakınız

Referanslar

daha fazla okuma

Dış bağlantılar