1960'lı yılların sonuna doğru ortaya çıkan Nesne Tabanlı Programlama (Object–Oriented Programming) yaklaşımı, o dönemin yazılım dünyasında beliren bir bunalımın sonucudur. Yazılımların karmaşıklığı ve boyutları sürekli artıyor, ancak belli bir nitelik düzeyi korumak için gereken bakımın maliyeti zaman ve çaba olarak daha da hızlı artıyordu. Nesne tabanlı programlamayı bu soruna karşı bir çözüm haline getiren ana özelliği yazılımda birimselliği (modularity) benimsemesidir.
Nesne tabanlı programlamanın altında yatan birimselliğin ana fikri, her bilgisayar programının, etkileşim içerisinde olan birimler veya nesneler kümesinden oluştuğu varsayımıdır. Bu nesnelerin her biri, kendi içerisinde veri işleyebilir, ve diğer nesneler ile çift yönlü veri alışverişinde bulunabilir. Halbuki nesne tabanlı programlama önce var olan tek yaklaşımda (yordamsal programlama), programlar sadece bir komut dizisi veya birer fonksiyon kümesi olarak görülmektedirler.
Bu temele dayanan nesne tabanlı programlamanın, bilimsel çevreler tarafından geçmişe göre daha yüksek esneklik ve bakım kolaylığı sunduğu iddia edilmektedir, ve bu nedenle günümüzde geniş çaplı yazılım geliştirme tasarılarında yaygınca kullanılmaktadır.
UML nesne yönelimli sistem dizaynlarını tanımlama amaçlı kullanılan text ve notasyon gösterimini içeren görsel bir modelleme dilidir. UML nin çok büyük popülarite kazanmasına ve hızla nesne yönelimli sistem tasarımında standart olmasına rağmen, kullanımının çok zor olduğu ve söz verdiği gibi yeteri kadar tatmin edici olmadığını düşünenler de vardır. UML hakkında sıkça duyulan şikayetler çok büyük ve karmaşık olduğu, anlamsal olarak muğlak olduğu, standart olmayan tarzda gerçekleştirildiği, sınırlı olarak özelleştirilebildiği, bileşen tabanlı geliştirmede yeterli desteğe sahip olmadığı, model diyagramları arasında kolayca birbirine çevrilemediğidir. UML kullanımı ile ilgili var olan kaynakların çoğu bu tür kısıtlamalar üzerine odaklanmıştır. Bununla birlikte UML’nin performans etkileri ve güncel kullanım dokularını tanımlayan çok az deneysel kanıt mevcuttur. UML’nin güncel olarak nasıl kullanıldığını, kullandığı hangi özellikler yoluyla nasıl fark
edildiğini, hangi özellik, görev ve organizasyonel faktörlerin kullanımına etki ettiğini tanımlayan deneysel araştırmalara ihtiyaç vardır. Bu ihtiyaca cevap vermek için yapılan bir araştırmanın sonuçlarını inceleyerek UML ‘nin yazılım sürecine etkilerini görmeye çalışalım. Martin Grossmana, Jay E. Aronsonb, Richard V. McCarthy tarafından yapılan bu inceleme, orjinali Goodhue ve Thompson tarafından geliştirilen ve devamında diğer araştırmalarla genişletilen yapıdan yararlanılarak yapılmıştır.
Örnek populasyon UML, OO analiz, dizayn tooları, yazılım geliştirme metodolojileri ile ilgili çeşitli online haber gruplarına erişim yoluyla oluşturulmuştur.(UML Forum, UML Cafe,Objects by Design Forum, UML Zone, The Precise UML Newsgroup, Rational Unified Process Forum, Sparx System Forum, Rose Forum, Object Technology User Group ) UML kullanıcılarının email adresleri bu tartışma grupları ve diğer kaynakların arşivlerinden toplanmış ve veritabanına girilmiştir. Hedef kullanıcılar, yazılım geliştirme projelerinde genellikle UML kullanan bilgi teknoloji profesyonellerini içermektedir. Sadece bu bireylerin ciddi UML kullanıcıları olduklarına inanılmaktadır ve bu nedenle araştırma için seçilmişlerdir. Bu tür inceleme araştırmalarında doğası gereği kesin bir ön yargı seviyesi vardır. Veri tabanındaki tüm bireylere UML kullanımı üzerine yapılan incelemeye gönüllü olarak katılıp katılmayacaklarını soran email atılmıştır.
İlk olarak gönderilen 1507 emailden 133 tanesi alıcıya ulaşmamış ve geri dönmüştür. Kalan 1374 emailden 131 tanesi incelemeyi cevaplamıştır.(Tüm cevapların %83 u mail gönderildikten sonraki 72 saat içinde gelmiştir.)Bu da cevap oranının %10.91 olduğunu göstermektedir. İncelemeyi tamamlaması için katılımcılara herhangi bir parasal mükafat önerilmediğini hesaba katılınca cevaplama oranın oldukça iyi ve mantıklı olduğu görülmektedir. Bu çalışmadaki cevap oranı davet edilen UML kullanıcılarından oluşan hedef grubun ilgi seviyeleri ile de alakalıdır. İncelemede ekstra yorum ekleyen (%28.2) ve gelecekte yapılacak çalışmalara katılmada istekli ve gönüllü olduklarını belirten(%58.8) kullanıcıların yüzdesine dayanarak incelemeyi cevaplayan bireylerin inatla UML kullanımını desteklediği ve görüşlerini açıklamada istekli oldukları söylenebilir.
UML hakkında katılımcılardan yararlı bilgiler alabilmek için orjinali Goodhue ve Thompson tarafından geliştirilen ve devamında diğer araştırmalarla genişletilen yapıdan yararlanılarak 8 kriter belirlenmiş ve bu çerçevede sorular yöneltilmiştir. Fakat sorular kritere göre gruplamadan rastgele sırada sorulmuştur.
Kriterler; Doğru Veri Kesinlik Uyumluluk Esneklik Anlaşılabilirlik Detay Seviyesi Eğitim Belirsizlik
Cevapların incelenmesi literatürde bulunan UML hakkındaki negatif tanımlamalar ışığında ilginç bulguları ortaya çıkarmaktadır. Örneğin UML’nin karmaşıklığı sık sık kullanımına engel olarak gösterilmektedir. Oysa anlaşılabilirlik değişkeni ile ilgili inceleme öğelerindeki cevaplara dayanarak katılımcıların çoğunun böyle hissetmediği görülmektedir. Benzer şekilde kesinlik ve esneklik öğelerindeki cevaplar da katılımcıların büyük bir kısmının oldukça olumlu bir algıya sahip olduklarını göstermektedir. İncelemedeki geliştiricilerin çoğunluğunun karşılaştıkları ihtiyaçları gidermek için UML’yi katı(esnek olmayan) ve kusurlu buluyorlar gibi görünmüyor. Bazı inceleme öğeleri için katılımcılar oldukça büyük oranda negatif yüzde sergilemişlerdir. Örneğin uyumluluk ve belirsizlik konularında birkaç soru için büyük oranda negatif cevaplar elde edilmiştir. İncelemeye katılanların %62 si UML’nin yanlış anlamaya izin verecek şekilde yetersiz tanımlandığını konusuna katılıyorlar.
İncelemede katılımcılara UML kullanımındaki asıl amaçları sorulmuştur. Katılımcıların çoğu Fowlerin dediği gibi “UML by sketch” (sketch=kroki,taslak)(öncelikle iletişime yardımcı UML yapılarından faydalanan, modellemeye dinamik ve informal yaklaşım getiren) kullanmaktadırlar. UML yi bu
biçimde kullanmak “UML by programming language” kullanımı ve “UML by blueprint”(blueprint=ayrıntı,plan) kullanımına karşın tanımlama kuralları
ile ilgili katı zorlamalar gerektirmez, diğer yaklaşımlar daha sıkı ve daha bütünlük merkezlidir.
Cevap Frekans Yüzde
Gereksinim belirleme 74 56.5
Kod geliştirmeye rehberlik 39 29.8
Reverse Engineering 13 9.9
Diğer 5 3.8
Şekil 5.10 : UML Kullanımı
UML nispeten yeni bir teknolojidir ve hala herkes adapte olamamıştır. Katılımcıların %44 UML yi tek tük kullanırken sadece %27.5 i UML yi birincil geliştirme yaklaşımı olarak kabullenip tutarlı bir şekilde tüm projelerinde kullanmaktadır.
UML Kullanımı Frekans Yüzde
Cevap Yok 1 0.8
Diğer 14 10.7
Tutarlı bir şekilde tüm geliştirme projelerinde kullanıyorum
36 27.5
Sadece büyük projelerde kullanıyorum 22 16.8 Yönetimden emir gelmedikçe
tek tük kullanıyorum
58 44.3
Toplam 131 100.0
Katılımcıların %28 i incelemeye yorum eklemiştir. İstatistiksel olarak analiz edilmemesine rağmen UML’nin nasıl kullanıldığına dair ek bir görüş ve bakış açısı sağlaması nedeniyle bu yorumlar önemlidir. Verilen cevaplar UML’nin görsel notasyonlarla iletişimi kolaylaştıran bir yol olduğunu desteklemektedir.
UML gereksinim tanımlama ve yazılım sistem dizaynı hakkında tam ve kapsamlı bir çözüm değildir fakat faydalı ve değerli bir tekniktir. Bir marangozun ihtiyacı olan tek aygıtın çekiç olmaması gibi analist ve dizaynırın ihtiyacı olan tek teknik değildir.
Bu yorumlar UML’nin sadece bir notasyon topluluğu olduğu ve sistem analiz ve dizaynının temelini oluşturan esas işlemler için yeterli olmadığını, UML’nin üzerinde dikkatle tekrar durulması gerektiğini düşünen metodoloji yandaşlarının yazdıklarını içermektedir.
Diğer yorumlar ise bazı yazarlarından iddia ettikleri gibi karmaşık sistemleri yeteri kadar inşa edebilmek için hala oldukça eksik olduğu görüşünü savunmaktadır.
Yorumların bazıları UML gibi yeni teknolojilere adaptasyondaki zorluklardan bahsetmektedir.
UML proje ekibine kod yazmaya başlamadan önce çözüm hakkında yeteri kadar bilgi sağlar. UML konuşma ve el hareketleri ile anlatmanın çok karmaşık olduğu fikirleri anlatmada kullanılabilir. Kod yazmaya başlamak için yeterli bilgi sağlandığında UML çizimleri bırakılmalı ve yazılan kod UML diyagramından daha fazlasını öğrettiği an diyagrama geri dönülüp güncellenmelidir.
Şirketler daha verimli yazılım geliştirmeye yardımcı olacak ümidiyle UML ye yatırım yapmaya başlamıştır. UML kullanımı sonucunda arzulanan kazancın her zaman sağlanacağı söylenemez. UML kullanımının organizasyonel çevre ve şartlarla uyuşup uyuşmadığını anlamak için cevaplanması gereken sorular vardır:UML nasıl kullanılacak?Ör:rastgele mi özenle detaylandırılarak mı? ,UML nin karmaşıklığını anlayacak derecede OO deneyimi var mı ve başarılı bir şekilde kullanabiliyorlar mı?,Yönetim UML kullanımını destekliyormu ve/veya şirkette taraftarı varmı?,Uygun kullanışlı eğitimler varmı?
Kısaca UML kullanımda organizasyonel çevreyi oluşturan çok sayıdaki karmaşık faktörü de hesaba katmak gerekmektedir.