Makale Özeti

UML i önceki makale de tanıdık, ancak hep iyi tanıdık, kısacası beyaz dünyasını gördük, bu makale ile UML in güçlü güçsüz yönlerini görecek, UML i kullanırken dikkat etmemiz gereken noktaları anlamaya çalışacağız.

Makale

UML’in Gerçek Dünyası

Bir önceki Makalemizde bir modelleme mantığına neden ihtiyaç duyulduğuna, bize kazandıracağı hız, bütünsel görüş, hataları önceden görüp azaltmak gibi özelliklerinden bahsettik. Bu makale de bu özelliklerin üzerinde biraz daha durup, aslında UML toz pembe dünyasından, bütün kitaplarda makalelerde yazılan “UML harika, öyle iyi böyle iyi” modundan sizi çıkartıp, biraz daha arkadaşımızı tanımamız, iyi yanlarını kötü yanlarını görmemizi sağlamaya çalışacağım…

Eski şirketlerimde UML kullanmıştım, tabiî ki kullanmadan önce çokça okuyup, nasıl bir şey odluğu ile ilgili örnekler karıştırıp, kendimce tecrübemi arttırmıştım.  Bir analizi yaparken de UML i kullanarak ilerlemeyi denedim, ancak sürekli çok da hâkim olamadığımı hissettim, acaba nasıl yapmak gerekiyordu. Tecrübesizliğime verdim ve daha da pekiştirmek için daha çok asıldım. Ama sürekli bir şeyler istediğim gibi olmuyordu. Özelliklede programcılık geçmişi olan birisi olarak, “çalıştırırım, ya çalışır ya çalışmaz” diye bakıyordum, ancak UML biraz daha “çalışabilir” durumundaydı.

Sonra bir arkadaşımla şirkette UML uygulamalımıyız, uygulamamalıyız ı düşündük, arkadaşımla şöyle bir makale bulduk. İncelemenizi tavsiye ederim. Hele de yazan kişinin Martin Fowler olmasından dolayı ilgilemenizi kesinlikle tavsiye ediyorum.

http://martinfowler.com/bliki/UnwantedModelingLanguage.html

Unwanted Modelling Language (İstenmeyen Modelleme dili). Ben kesinlikle böyle düşünmüyorum bu arada, aksine ben kendisini istiyorum. Ancak dünyamızdaki her şey gibi, bilgisayar dünyası gibi, diğer bütün diller gibi, UML de kusursuz değil, önemli olan bu problemli yanlarını görüp, ona göre hareket etmek en doğrusu olacaktır. Bu yüzden bu makalede aslında enine boyuna UML i inceleyeceğiz.

UML in dünyadaki yazılım evlerindeki kullanımı %20 civarındaymış, bu istatistiği aslında biraz kulaktan dolma bilgilerle veriyorum. Bir kaynağa dayandıramayacağım. Aslında amacım oranın düşük olduğunu anlatmak. Neden düşük bu oran diye sorarsanız buyurun aşağıdaki maddeleri inceleyin, hem UML in gerçek dünyası ile tanışın, hem de elimden geldiğince açıklamaya çalışacağım bu negatif yönlerinin kendimce çözümlerini öğrenin…

Öncelikle şunu belirteyim, UML çok esnektir. Sizi birçok konumda sınırlandırmaz, bundan dolayı herhangi bir UML diyagramı çizmek çok kolaydır, çok eğlencelidir. Ama sizi sıkmadığı için çizim tarzınızda farklılaşır. Temel bir nasıl çizeceğiniz bilgisi vardır. Ama bu temelin üzerine çok az çıkılmıştır. Dolayısı ile üst noktanızı bazen kestiremeyebilirsiniz. üst noktanızı kestiremediğiniz anda ise problemler başlar, bir kere siz çizimi yaparken, zorlanmaya sıkılmaya başlarsınız, zira bir şey yapmışsınızdır ama bu doğrusumudur ? gerçekten demek istediğinizi anlatmışmısınızdır ? bunu bir kere sizin tartmanız bile çok zordur. İşin diğer ilginç noktası da aslında bunu tartacak tek kişi o modellemeyi okuyacak, anlamaya çalışacak kişidir. Bu  yüzden UML i bilmek, UML i çizebilmek çok önemli değildir. UML i takım olarak biliyor, okuyabiliyor olmanız gerekmektedir. Takımınızdaki bir kişi bile UML okuyamaz durumdaysa, UML ile modelleme yapmanın çok esprisi olmayacaktır.

Bunu aslında birinci nokta olarak düşünebiliriz, UML standarttır, ama sizin için biraz daha standartlaştırmak gereklidir. Bütün takımın UML i sizin bildiğiniz standartta bilmesi gerekir, aksi takdirde süslü şekillerden başka bir şey kalmaz.

UML bir modellemedir dedik, peki bu makale neden bu kadar sıkıcı ? neden bir iki model serpiştirmiyorum araya ? çünkü bir modellemeyi aslında sadece ve sadece model ile anlatamamamız. Bütün UML belgelerinde şu açıklamayı görürsünüz (bir önceki makalede bende yazdım :) “UML standarttır, herkes baktığında aynı şeyi anlar, dolayısı ile diyagramı çizen ile okuyanın aynı dili bilmesine gerek bile yoktur” üzülerek söylüyorum ki bu durum hiçte böyle değil, zaten UML in hangi diyagramını çizerseniz çizin yazıya ihtiyacınız var. UML in esas üzerindeki belgeleri yazabilmek için dünya üzerinde standart olan İngilizceyi kullandınız diyelim ki, ülkemizdeki İngilizce bilmeyenleri de geçiyorum ama bunun yanında UML diyagramlarında çok fazla not ekleme ihtiyacınız olacaktır. Üstteki konuyla da bağlamak gerekirse UML diyagramı çizerken esas soru hangi derinlikte, hangi detayda çizeceğinizle çok alakalıdır. Eğer detay seviyesini biraz arttırırsanız çok fazla obje içerecek, anlatmak istediğiniz şeyi çok güzel anlatacaksınızdır, ancak çizebilmek çok zor olacaktır. Çok uğraş vermeniz gerekecektir. Bundan dolayı genele insanlar temel özellikleri şekil ile anlatıp, onun üzerine gerekli yerlere notlar ekleyerek diyagramları çiziyor.

İkinci noktası da, birinci nokta ile ilintili olarak, sırf şekilden ibaret bir diyagram oluşturamıyorsunuz, yine yazı paralelde yazı kullanmak durumunda kalıyorsunuz. Eh birde diyagramdakileri yazıya dökme gibi bir işiniz varsa, UML kullanmak biraz lüks kaçıyor. Çözüm olarak seviyeyi düzgün belirleyip, belli bölümlerin not ile anlatılması gerekliliğini kabul etmek gerekir. Dokümantasyon olarak da daha az yazılar yazılıp, ana fokusu diyagramlarda tutmak gereklidir.

Bir diğer değinilecek konuşulacak konu ise UML diyagramlarınızı güncel tutmak ile ilgili. Müşteriniz daha yazılıma başlamadan size isteklerini iletir. Müşterinin istekleri ile ilgili analizi yapar, yazılım için bir süre belirlersiniz. Ancak müşteri analiz biter bitmez isteklerini değiştirme, geliştirme eğilimindedir. Bu yine biraz daha yönetilebilir bir durumdur, ancak yazılım esnasında, yazılımın bitmesine yakın, hatta yazılım bittikten sonra bile müşteri istekleri devam etmektedir. Analizi yaparken bir UML modeli çıkarttınız, çok uğraştınız, her şeyi anlatıyor. Ancak müşterinin istekleri değiştiğinde sizinde bu diyagramları geliştirmeniz gerekmekte, diyagramları geliştirmek te, bazı durumlarda metinleri değiştirmekten çok daha zor olabiliyor, zira bir diyagram aslında üç tane noktaya bağlı olabiliyor. İşin açıkçası, müşterinin bir değişiklik isteğinin nereleri etkilediğini çok kolay görebiliyorsunuz diyagramlarınızda, ama müşterinin ufak bir sözü ile 4 diyagramı güncellemekte her zaman yoğunlukta çok mümkün değil. Değiştirmeseniz, yazılım farklı dokümanları farklı durumda olacak ki bu çok daha yanlış bir durum. Mecburen, müşteriyi sınırlayıp, belki yapılması çok da zor olmayacak bir iş için ikinci hatta n inci fazı müşteriye bekletmek zorunda kalıyorsunuz.

UML in hayatımızı beklide en çok zorlaştırdığı konu burası, çünkü direk bir çözümü yok. Üçüncü nokta olarak bu konuyu konuşalım. Tek çözümü biraz daha sistemli çalışmak aslında. UML diyagramlarınızı birbirleri ile ilişkilendirip, her diyagramınızı küçük alt parçacıklara ayırabilirseniz, biraz daha kolay yönetebilirsiniz. Çok alternatif olmuyor ama Microsoft’un Visual Studio 2005 ile birlikte gelen “Class Diagram” kod ile diyagram arasındaki bağı biraz sağlıyor ama bu da çok küçük bir bölümü. Aslında burada şunu da belirteyim, UML modellemesini kullanmayıp yazmış olsaydınız da çok fazla zamanınız gidecekti, ama metini değiştirmek daha kolay.

Son olarak problem konusunda değineceğim konu ise UML modellemesi yapacağınız araç. Çok fazla UML modelleyebileceğiniz uygulama var aslında. Ama her uygulamanın kendi artı ve eksileri mevcut. Bundan dolayı direk bu iyidir bu kötüdür denemiyor maalesef, aynısını UML modelini çıkartırken de yaşıyorsunuz. Ben burada kişisel görüşümü dile getireceğim. Kızan bozulan olabilir, aşağıda mailim var :) ama amacım asla tool tartışmak değil, bu kullanım şeklinde, tercihlere göre değişir. İlk değineceğim tool, aslında bu işin dünyada en çok kullanılan, en çok beğenilen, ilk çıkan toolu. İlgili arkadaşlar zaten tahmin etmişlerdir. Java dili ile yazılmış, şimdilerde bir Java editörüne plug – in olarak eklenen bir tool. Bu toolu uzun zamanlar kullandım, çok gelişmiş ve zeki özellikleri var, ama kullanıcıyı bir o kadar da çok boğuyor. Açılması, çalışması bir işlemenizden sonra size tepki vermesi çok yavaş. Birde benim şu anda kullandığım versiyonunda hizalar sürekli karmaşık ve düzelmiyor. Alternatif olarak başka bir tool daha var, buda baya bilinen meşhur bir tool aslında. Ancak o da yine oldukça yavaş ve hayatınızı kolaylaştıracağı yerde zorlaştırıyor maalesef. En son olarak değineceğim tool ise canımız kanımız Visio. Kendisi basit, Office bilen birisinin kullanmayı öğrenmesi çok kısa sürüyor. Daha hızlı çalışıyor ve oldukça fazla işinizi görüyor.

Dördüncü ve son olarak değindiğim büyük problem UML in toolu. Çok alternatif var, hatta UML in resmi sitesinde bile tool önerileri mevcut. (http://www.uml.org/ da en altlarda “Other Lists of UML Tools (1.X and 2.0)” başlığı ile bulabilirsiniz.) ancak Visio yu öneririm. Hem gelişmiş özellikleri var, hem de basit olarak işinizi yapmanızı sağlayan özellikleri. Artı diğer toollara göre çok daha ucuz.

UML ile ilgili birkaç problemli durumdan da hızlıca bahsetmek istiyorum.

·         UML çok fazla geliştirilen bir mantık değil, 1997 yılında 1.0 versiyonu çıktık tan sonra 2004 yılında 2.0 versiyonu çıkmış, en son versiyonu bir önceki makalede de belirttiğim gibi, 2.1.2. versiyonu oda 2007 nin 11. ayında çıkmış.

·         UML in çok fazla diyagram tipi var, aslında işinizi görecek olanları 4 5 tanesi ancak diğer diyagram tiplerinin hem anlaşılması zor hem de hatırlanması. Uzun zaman sonra ihtiyacınız olduğunda sürekli bir UML kitabını açmanız gerekiyor. Bazı durumlarda hangisini çizeceğinizi bilemiyorsunuz bile

·         UML in iş süreçlerini yönetmek için, yazılım alanını yönetmek için, mimari alanları yönetmek için farklı diyagram tipleri var. Bu diyagramların farklı kişiler tarafından çizilmesi gerekiyor, ancak aynı uygulamayı anlatması biraz zor oluyor.

·         Bazı konular için toolların yetenekleri özelleşmiş, bir tool bir diyagram tipinde iyi iken diğer diyagram tipinde çok zorlayabiliyor.

·         Bazı firmalar yazılım işlerini outsource ediyorlar. Kendi içlerinde istedikleri yazılımın süreçlerini analiz edip, bir firmaya yazdırıyorlar. Burada UML i uçtan uca kullanamadıkları için, belli bir noktada kullanmaları çok işlerine yaramıyor.

·         UML ile teknik anlamda sadece OO ile ilgili modellemeleri yapabiliyorsunuz, OO olmayan yada daha önemli Veritabanı ile ilgili olan nesneleri modellemek diye bir şey UML de yok.

Şimdi biraz daha UML i açalım, diyagram tiplerini inceleyelim ki ilerideki makalelerde neler öğreneceğimizi görelim.

UML’in 1 versiyonu ile 11 adet diyagram tipi geldi, UML in 2 versiyonu ile 2 yeni diagram tipi daha geldi ve sayısı 13 e çıktı, ancak yoğun olarak kullanılan aslında 4 yada 5 tanesidir. İlerleyen makalelerde bunları anlatmaya çalışacağım.

Bu 13 diyagram tipi üç ana kategoriye ayrılır, aşağıdaki listede bu kategorileri göreceksiniz.

Statik diyagramlar, sistemin genel anlamda yapısını modellemeye yararlar.

    • Class diyagram
    • Component diyagram
    • Composite structure diyagram
    • Deployment diyagram
    • Object diyagram
    • Package diyagram
  • Uygulamanın
    • Aktivite diyagramı
    • State Machine diyagram
    • Use case diyagram    
  • Dinamik diyagramlar
    • Communication Diyagramı
    • Interaction overview diyagram (UML 2.0)
    • Sequence diyagram
    • UML Timing Diyagram (UML 2.0)

Şimdi bu diyagram tiplerinin önemli olanlarını inceleyelim,

Use Case Diyagram :

Daha önce okuduğum kadarı ile (nereden okuduğumu hatırlamıyorum :) bu diyagram UML e son anda eklenmiş bir diyagram, ancak en önemli diyagramlarından bir tanesi, uygulamayı kuş bakışı modellemenizi sağlayan, en tepeden baktığınızda kimin ne iş yaptığını anlatan diyagram.

Aktivite Diyagramı :

En çok kullanılan diyagram tiplerinden bir tanesi, yazılım ile uzaktan alakası olan kişiler bile bu diyagram tipini biliyordur. Hatta belki kullanmıştır. Farklı aktörler (domainler) arasındaki adımların neler olduğunu, uygulamanın hangi işleri hangi adımda yapacağını anlatan bir diyagram.

Class Diyagram :

OO (Object Oriented = Nesneye Dayalı) program geliştiriyorsanız, Class lara çok aşinasınızdır zaten. Class diyagram uygulamanızdaki class ları modellemenizi ve bu model üzerine kodlama yapmanızı sağlayacak ve size uygulamanızın modellemesine tepeden bakarak, kodların tekrar kullanılabilirliğinden tutunda, OO özelliklerini sonuna kadar kullanmanıza olanak verecek bir diyagram tipidir.

Sequence Diyagram :

Türkçeye Sekans diyagramı diye geçmiş olsa da, Aktivite (Activity) diyagramının telefuzu kadar kabul görmemiş bir diyagram :) Class lar arasındaki mesajlaşma yapısını gösteriyor. Çok güçlü bir diyagramdır. Eğer düzgün çizilirse, memory yönetimini bile bu diyagramdan yapabilirsiniz. Çok önemli bir diyagram tipidir.

Yukarıda saydığım diyagram tipleri aslında en çok kullanılan tipler, diğer diyagram tipleri de oldukça çok kullanılıyordur. Ancak benim gördüğüm en çok kullanılan diyagram tipleri bunlar. Diğer diyagram tipleri özellikle belirli bir işi modellemeniz için gereken tipler. Bu yukarıda değindiğim diyagramlar ile ilgili daha detaylı makaleler yazmayı planlıyorum.

Bu makalemizde özellikle UML in gerçek dünyasını göstermeye çalıştım, kusursuz olmadığını, bazı sıkıntılarının olduğunu bilerek UML dünyasına girmeniz hızlı ilerlemeniz ve demotive olmamanız için çok önemli. Bir sonraki makalede UML in Use Case diyagramı ile ilgileneceğiz…

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

Levent Cenk ÇAĞLAR

levent@cenkcaglar.com