UML’i Nasıl Kullanabiliriz? – I

Bir önceki yazımızda “UML Nedir?” sorusunu cevaplamıştık.  Bu yazımızda da “UML’i projelerimizde nasıl etkin olarak kullanabiliriz?” sorusunu cevaplayalım.

İşin açıkçası ben UML’dan çok UML araçlarını kullandım 🙂 Ne demek şimdi bu? UML araçlarını Rational Rose ve TogetherJ ile ta UML’in ilk çıktığı günlerden bu yana kullanıyorum. Türkiye’ye döndükten sonra da yukarıdaki iki araç ve başka UML araçlarını kullandım. UML araçları sadece UML diyagramları ile modelleme yapmanızı sağlamaz, pek çoğu aynı zamanda “reverse-engineering” yapmanıza da izin verir. Yani bu araçlara, hali hazırda yazılmış olan kodu örneğin Java kaynak kodunuzu gösterirseniz size kaynak kodundan yola çıkarak bazı UML diyagramlarını çıkarır. Bu da muhtemelen çok az ve eskimiş, güncel olmayan dokümentasyona sahip olan kod yapısını anlayabilmek için en etkin yöntemdir. Pek çok programcı böyle durumlarda debugger kullanır; halbuki reverse-engineering ile oluşturulmuş özellikle sequence diyagramları, kodun akışını istediğiniz detayda göz önüne serer, çok daha yüksek seviyeli bir bakış kazandırır. Benzer şekilde class diyagramları ile de hem tip hiyerarşilerini (is-a) hem de bilme/sahip olma (association, has-a) yapılarını, tiplerin arayüzlerini vs. ortaya koyduğunuzda sistemin çalışmasını anlamanız kolaylaşır. (Bu amaçla debugger kullanmak çoğu zaman aşırı detaya girmeye sebep olduğundan çok zaman alır. Kod devralmış developerlara tavsiyem, önce böyle bir araçla büyük resmi görmeleri sonra gerekiyorsa debugger kullanmalarıdır.) Benim “UML’den çok UML araçlarını kullandım” cümlemden kastettiğim, UML’i modellemek amaçlı değil de malesef daha çok zaten yazılmış kodun modelini geri doğru çıkarma amaçlı kullanmış olduğumdur. Bu durum insanı daha çok “UML okur” yapar, faydalıdır, özellikle danışmanlık amacıyla gittiğiniz yerlerde var olan dokümantasyonsuz kodu anlamak için sihirli değnektir. Ama işin açıkçası UML’i kullanmaktan kastettiğimiz “UML yazar” olmaktır. Yani projenizde baştan başa UML’i kullanmaktır.

Peki UML’i baştan başa nasıl kullanırız sorusundan önce bir kaç şeyi daha açıklamam gerekli. Öncelikle şunu tespit edelim: UML modelleme araçlarına sahip olmak hatta UML kullanmak kaliteli yazılım geliştirmek anlamına gelmez. Ben bu ülkede, özellikle parası bol olan kurumlarda, Rational gibi UML modelleme araçları, ihtiyaç analizi yönetim sistemleri, test vb. yazılım kalitesi yönetimi yapan tonla aracı içeren suitlere deli gibi para akıtıldığına şahit oldum. (Rational şirketi 2002 yılında IBM tarafından satın alındı ve ürünleri artık IBM ürün kümesine katıldı. Zaten piyasaya çok farklı ve değişik yetkinlik ve fiyatta pek çok UML aracı da çıktığından artık Rational’ın ürünleri eski popülerliğine sahip değildir.) Bu masraflar hem lisans için hem de eğitim için yapılmakta. Ama benim şahit olduğum kurumların hiç birisi tonla para verdiği bu UML araçlarını ve UML modelleme çalışmalarını, yazılım geliştirme süreçlerine entegre edemedi. Sebebini araştırdığınızda ise genelde aynı cevapla karşılaştım: UML ile modelleme yapmak zaman alıyor! Buradan modelleme konusunda ciddi bir tecrübe sahibi olmadan ve modellemenin mahiyetini bilmeden dostalr alış-verişte olsun diye doğrudan teknoloji satın almanın ne kadar yanlış bir başlama noktası olduğunu da anlıyoruz.

İşin açıkçası her teknoloji gibi UML’in kendi başına hiç bir değeri yoktur. UML çalışıp size bir şey üreten bir yapı değildir, bir derleyici gibi bile değildir. UML, yazılım geliştirme ile ilgili zihninizdeki düşüncelerinizi, herkesin anlayabileceği standart bir dile ve anlamlı görsellere dökmenin yoludur. Bu yüzden UML kullanmak zaman almaz, zaman alan şey düşünmektir. Düşünmenin maliyeti yanında UML’i kullanmanın getirdiği ekstra yük ne kadar olabilir ki? Sonuçta yazılımı zihinde modelleyebilmenin de bir sınırı vardır, bir yerlere zihninizdeki modelleri yazmanız gerekli ki zihniniz düşünmeye devam edebilsin ve düşündüklerini farklı zihinlerle paylaşılabilsin. Dolayısıyla bu topraklarda UML aracı almaktan ziyade düşünmeye vakit ayırmaya başlamak daha önemli bir iştir. Yazılım hakkında, projemizin ya da ürünümüzün ihtiyaçları, riskleri, tasarlanması üzerine düşünelim, ama UML kullanmayalım, dert değil. Bir beyaz tahtaya farklı renkte kalemlerle düşündüklerimizi çizip takım arkadaşlarımızla paylaşalım, bu çizimler üzerinden tartışalım, başkaları da başka çizimler yapsın örneğin. İşte böyle bir yazılım geliştirme kültürüne sahip olalım ve inanın UML’e olan ihtiyaç kendiliğinden ortaya çıkacaktır. Herkes farklı notasyonlar kullanacak ve bir notasyon karmaşası dolayısıyla da iletişim problemi oluşacaktır. Bu durumda muhakkak UML gibi standart bir notasyon dilinin herkes tarafından öğrenilmesi son derece makul bir ihtiyaç haline gelecektir.

Tam da bu sebepten, sıklıkla karşılaştığım “Biz 2 günde UML öğrenmek istiyoruz” şeklinde istekler malesef UML’in doldurmaya çalıştığı boşlukla uyuşmuyor. Yazılımı modellemenin ne olduğunu bilmeyen, yazılım geliştirmeyle ilgisi sadece program yazmak noktasında kalmış kişilerin ya da takımların, “biz sadece UML öğrenmek istiyoruz” demeleri, araç kullanmadan “ben sadece ehliyet almak istiyorum” demekten ya da bir arkadaşımım deyişiyle “kişinin ihtiyacı okuma-yazma olduğu halde ben sadece harfleri öğreneyim” demesinden” farklı bir durum değildir.

UML ile ilgili bir diğer konu da UML’in bir yazılım geliştirme metodolojisi olmadığı gerçeğidir. UML kullanmak, kaliteli yazılım geliştirmenin garantisi değildir. Ya da UML, doğrudan herhangi bir nesne-merkezli yazılım geliştirme metodolojisi sunmaz, o tarafı size bırakır. Bu anlamda UML sadece bir araçtır. Dolayısıyla UML’i kullanmak iyi bir süreç işletmek anlamına gelmeyecektir. UML’i verimli bir şekilde kullanmak, eğer kısıtlı zaman ve imkan varsa olabildiğince yüksek katma değer sağlayacak şekilde kullanmak, UML’den sağlanacak faydayı arttıracaktır.

UML’i bir süreç içerisinde kullanmaktan kastım ise, en basitinden var olan 10 küsür diyagramın hepsini her zaman kullanmaya çalışmanın anlamsızlığıdır. Şu çok açık: UML 100 kişinin çalıştığı ve 3 senelik bir proje için farklı kullanılırken 5 kişinin kodu bir başkasından devralıp, geliştirmeye çalıştıkları bir başka proje için farklı kullanılmalıdır. Bu ise hem geliştirme sürecini hem de UML’in nerede nasıl katma değer yaratacağını bilmekten geçer. Ve bu da tamamen bilgi ve tecrübe sonucunda elde edilir, UML aracı ve eğitimi pazarlayanların, “UML kullanın bütün dertleriniz bitsin” şeklindeki sloganlarla değil.

Bir sonraki yazıda UML’in ve bileşenlerinin nasıl kullanılabileceğini ele almak üzere iyi günler diliyorum.

Toplam görüntülenme sayısı: 2989