Makale Özeti

UML Ne demektir, nasıl doğmuştur, ne gibi faydaları vardır. bu makaledeki amaç UML in iyi yönlerini ortaya koymak ve UML i tanımaktır.

Makale

UML’in Beyaz Dünyası

Uzun zamandır UML ile ilgili yazmak istiyordum. Yazgelistir de UML ile makale olmaması, özelliklede Yazılım Mühendisliği editörlerinden birisi olarak, UML makalesi olmaması beni rahatsız ediyordu. Sonunda biraz vakit buldum ve UML ile ilgili bir makale dizisi yazmaya karar verdim, umarım faydalı olur.

Öncelikle tabiî ki UML in tarihçesini inceleyeceğiz, neden UML e gerek duyulduğuna bakacağız, daha sonra UML i biraz daha tanıdıktan sonra daha da detaylara ineceğiz.

UML in tarihçesi

1970 ler de oluşturulan ilk yazılımlar tek kullanıcılı, kapsam olarak çok az iş yapabilen yazılımlardı. 1970 lerin sonlarına doğru kişisel bilgisayarların geliştirilmesi ile bilgisayarlar evlere girmeye başladı. Donanım teknolojisinin gelişmesine paralel yazılım teknolojisinin gelişmesi de ivmelendi ve yazılım geliştirmek önceye göre daha popüler hale geldi. Yazılım geliştirme teknolojileri geliştikçe, kullanıcılara daha fazla imkanlar verilmeye başlandı ve kullanıcıların istekleri daha rahat yerine getirilmeye başlandı. Kullanıcılarda bu gelişmelere paralel olarak daha çok şey istediler.

1980 lerin başında kullanıcıların istekleri arttıkça, önceden tek kişinin yazdığı uygulamaları artık tek kişi yazamamaya, yetiştirememeye, yorumlayamamaya başladı. Bundan dolayı daha çok kişinin çalışması gereken yazılımlar gerekti. 1980 lerin ilk yıllarında paket programlar oluşmaya başlandı. Bir bilgisayar mağazasından bilgisayar alıp, yanında birde paket yazılımla, hemen bilgisayarı kullanmaya başlayabiliyordunuz. Ancak paket yazılımlar türedikçe, her paket yazılımın herkese uymadığı gerçeği ortaya çıktı. Önceden bir geliştirme istediğinizde sizin için çalışan yazılım geliştirici, birkaç günde istediğiniz geliştirmeyi yaparken artık paketin bozulmaması adına bu geliştirmeler yapılamadı ve versiyonlama yöntemlerine gidilmeye başlandı. Versiyonlama yöntemlerinide yönetmek çok kolay değildi, bir herkezin mutlu olacağı bir özelliği eklemek için çok yoğun çalışmak, kapsamı belirlemek, süreçleri oturtmak gerekiyordu. İşte bu şekilde yazılım mühendisliği doğmaya başladı.

Paket yazılımlar ile birlikte, yazılımı kullan kişiler ile yazılımı geliştiren kişiler ayrışmaya başladı. Bir süreç işletiliyor ancak bu süreç ne kadar başarılı olup müşterinin işi görüyor bilgisi önem kazanmaya başladı. Müşterinin işini görsün diye sürekli tekrar tekrar geliştirilen yazılımlarda, iterasyon mantığı oturmaya başladı, böylece de yazılımın yaşam döngüsü (development cycle) kavramı yazılımcıların dünyasına girdi.

Yazılımların iterasyonları arttıkça, yazılımların özellikleri, yetenekleri, işlevleri de arttı, artık bir yada iki yazılımcının takip edemeyeceği hale geldi yazılımların yetenekleri. Yazılım takımları da gittikçe büyümeye başlıyordu, çünkü kullanıcılar sürekli yeni özellikler istiyorlardı yazılımlardan, yazılımcılar bir yandan yazılımı geliştirip, diğer yandan da kullanıcıların isteklerini anlamaya çalışıyorlardı, hali ile bu da çok vakit kaybı oluşturuyordu.

Bundan dolayı müşterinin ne istediğini anlamak için eski yazılımcılar, yoğun kod yazma işlerini gençlere bırakarak, tecrübeleri ile birlikte müşterileri dinlemeye başladılar. Müşteriden aldıkları istekleri de yazılım geliştiricilere aktarmaya başladılar. Kullanıcılarda onları dinleyen kişileri görünce daha da çok özellik istemeye başladı :) bu kişiler artık ayrı bir şekilde çalışıyorlardı ve amaçları işin nasıl yapılacağını çözümlemekti, yani analiz yapmaktı.

Daha sonrası zaten oldukça hızlı ilerledi, özellikle inşaat sektöründen geçen (gerçekten!) proje yöneticileri, yazılımın iç dinamiklerini öğrendi, buna göre kendilerini geliştirdi, analiz rolü oturdu, yazılım geliştirme rolü oturdu, yazılımcı kendi yazdığı programı rahat test edemediği için bazı yazılımcılar kontrol işini üstlendiler, test grupları oluştu.

Yazılımın dünyasının nasıl geliştiğini hangi evreleri geçirdiğini inceledik, peki UML neresinde diyorsanız, biraz daha beklemeniz gekecek..:)

Analist dediğimiz kişiler öncelikle müşteriyi dinliyor, dinledikleri ile ilgili notlar alıp, yazılımcıya iletiyorlardı. Ancak yazılım kadrosunun artması, analist kadrosunun artması ile analiz yapma işi de evrim geçirmeye başladı, her analist aynı şekilde bakamıyor, aynı şekilde düşünmüyordu, donanımlar büyüyor, network sistemleri gelişiyor, kısacası uygulamaların yapması istenilen yetenekler artıyordu. Bundan dolayı analiz için, analiz yapan kişilerin ortak dili konuşmaları adına şirketler bazı not alma standartları belirlediler. İşi kimin yaptığı, neden yaptığı gibi bilgiler bir şablonda olacak ve bu şablon her analiz için doldurulacaktı. Ancak yinede kelimelerle anlatmak algıda farklılıklar yaratıyor. Analist ya demek istediğini doğru anlatamıyor, ya da yazılım geliştirici analistin demek istediğini tam olarak anlamıyordu.

Bu gibi sıkıntılardan dolayı, diyagramsal gösterimler yaygınlaşmaya başladı. Ama her yazılım firması kendisine göre bir standart uyguluyor, bir yazılımcı diğer firmaya geçtiği zaman, belli bir süre bu diyagramların ne olduğunu, ne anlatmaya çalıştığını öğrenmek için zaman kaybetmeye başladı. Ama modele dayalı yazılım geliştirme vizyonunu artık öğrenilmiş ispatı yapılmıştı. bundan sonraki adım aslında bilgisayar dünyasına çok gördüğümüz bir davranışla ilerledi, var olan birçok sistem incelendi, en iyisi standartlaştırıldı. İşte UML 1997 yılında bu standartlaştırmanın bir ürünü olarak doğdu.

UML (Unified Modelling Language = Birleştirilmiş Tasarlama Dili), OMG grup (www.omg.org) tarafından tasarlanan ve geliştirilen, farklı modelleme şablonları olan, en son versiyonu 2007 nin 11. ayında 2.1.2 olan bir modelleme dilidir. UML yoğun olarak Nesneye dayalı programlar (Object Oriented Programing) için kullanılır. UML Bir modelleme standardizasyonudur, bizim bildiğimiz .Net te yazdığımız dillerden birisi değildir.

UML e şöyle bakmak gerekiyor aslında, bir inşaat mühendisini ya da mimarı düşünün, bilmesi gereken çok fazla konu var, inşaat mühendisi için fizik, dinamik, statik bilmeli örneğin ve bu konularda aslına bakarsanız çok kolay konular değil. Bu kadar yoğunluktaki dersleri öğreniyor aynı zamanda nasıl çizim yapacağını nasıl modelleme yapacağını da öğreniyor. Yani inşaat mühendisi olmak sadece bu hesaplamaları yapmak değil aynı zamanda bir tasarımda yapmak, bu tasarım ile hesaplamaları daha kolay yapabilmek.

Yazılım dünyası da aynı mantıkla ilerliyor aslında, ama yazılım dünyası maalesef elle tutulur bir şey ortaya koyulmadığı için bu mantıklar daha hızlı geçiliyor. Bir bina yıkılırsa maddi masrafı karşısında insanlarda zarar göreceği için daha dikkatli inceleniyor ancak bir yazılım başlangıcında ya da bittikten sonra çökerse sadece maddi başarısızlıklar dikkat çekiyor. Günümüz yazılımlarında bu maddi kayıplarda büyük rakamlar olmaya başladı ve rekabet ortamında maddi kaybı yine bir şekilde göze alabiliyorsunuz ancak müşteri kaybı kolay kolay cesaret edilecek bir durum değil.

Modelleme yapmanın öneminden bahsetmeye devam edecek olursak, internette çok farklı versiyonlarını bulabileceğiniz bir imajı eklemek istiyorum, MVP olan arkadaşlarımdan Oğuz Bayram da bir makalesinde eklemiş, iletişimin (iletişimsizliğin mi demeliydim) ne sonuçlar doğuracağını gösteriyor…

Peki UML kullanacaksınız diyelim ki UML size ne kazandıracak biraz da bu konuyu konuşalım. Eğer yapacağınız iş küçük bir iş ise, tekrar yapmak sizi fazla yormayacak ise o işi yapmak için çok fazla efor harcamazsınız, o işi planlama ihtiyacı duymasınız, tekrar yapmak sizin için çok fazla vakit kaybı oluşturmayacaktır. Elinizde sonuçta bir çıktı olacaktır, gerekirse bu çıktıyı geliştirmek için vakit harcayabilirsiniz, ama yazılım projelerinde özellikle de çok fazla kişinin çalıştığı projelerde, tekrar düzenlemeniz büyük vakit ve maliyetlere yol açar. UML kullanmanın avantajları bir işi planlama adımın da görmenizi sağlar. UML görsel olduğu için önünüzdeki tablo size gerçeği yansıtacak en önemli resimdir.

UML in standart olduğunu konuşmuştuk, UML standart olduğundan herkes bir UML diyagramına baktığında aynı şeyi anlar. (bir sonraki makale de bu bölümü biraz daha açacağım) dolayısı ile kelimelerin önemi kalmaz, kelimeleri yanlış anlamak gibi bir sorun kalmaz. Hatta bilmediğiniz bir yabancı dildeki modellemeyi bile okuyabilirsiniz. (bu biraz iyimser bir bakış açısı, yine önümüzdeki makalelerde değineceğiz)

Yazılım projelerinin, özelliklede büyük olanlarında UML in size vereceği güç biraz daha fazladır. Öncelikle büyük bir fonksiyonaliteyi bir bakışta görebilmek önemlidir, yazı ile ne yaparsanız yapın maalesef bunu sağlayamayacaksınız. Büyük projeler, aynı zamanda uzun süren projelerdir de, elinizde eğer bir UML modeli varsa, daha önceden geliştirdiğiniz yada analizini yaptığınız bir bölüme ekleme yapmanız çok kolay olacaktır. Bu bölümü modele bakarak, okumaya ve anlamaya göre çok daha rahat şekilde hatırlarsınız.

UML in sağlayacağı diğer artılarına da bakacak olursak;

·         Bütün sistemi tasarladığınız için, sistemde bir hata çıkma olasılığı zorlaşacak, çıkarsa da bulmak kolaylaşacaktır.

·         Bütün sistemin tasarımını çıkarttığınız için ortak olacak component ler belirlenecek ve böylece o bölümleri tekrar tekrar yazmayacaksınız.

·         Uygulama daha analiz aşamasında tasarlanacağı için, ne yazılacağını düşünmek zorunda kalmazsınız. Direk kodlamaya başlayabilirsiniz.

·         Bir den çok analist ve yazılımcının yer aldığı projelerde ortak dil sağlandığı için daha rahat anlaşacaksınız, birisinin bıraktığı bir yazılımı diğer bir yazılımcı devralıp, devam edebilir olacaktır.

UML’in beyaz dünyası” isimli makaleyi özellikle az grafik, çok laf şeklinde yazmak istedim. Özelliklede UML in bir çok avantajını vurgulamaya çalıştım, makelenin adı aslında bu yüzden “UML’in beyaz dünyası”  bir sonraki makalede UML e biraz daha yakından bakacağız, biraz daha yakından bakacağımız içinde biraz daha problemlerini görüyor olacağız, işte bu yüzden bir sonraki makalenin adı, “UML’in gerçek dünyası”

İstek eleştiri ve önerileriniz için aşağıdaki mail adresimi kullanabilirsiniz. 

Levent Cenk ÇAĞLAR 

levent@cenkcaglar.com