Daha onceki projelerde kullandığım ve Imagine Cup 2008 - HCA Software Design Projesi kapsamında yapmayı planladığımız "UML ile Yazılım Modellenmesi" hakkında genel bilgilendirme amacı güden bir yazıdır..
Modelleme kanıtlanmış ve kabul edilmiş bir mühendislik tekniğidir. Model sayesinde karmaşık bir gerçeği daha basit bir dille ifade etme şansımız olur; böylece modellediğimiz gerçeği daha iyi anlayabilir, hataları yolun başında görebiliriz. Aynı gerçekler yazılım için de geçeridir, özellikle büyük ve karmaşık yazılımlar için modelleme, büyük bir bina için mimari planın (blueprint) gerekliliği kadar vazgeçilmez bir olgudur.
Yazılım modellenmesi sayesinde sistem gereksinimlerini ve sistem davranışlarını daha iyi anlarız ve hata riskimiz azalır. Yazılım yaşam döngüsü içinde hatalar ne kadar erken saptanırsa düzeltme maliyeti de o kadar az olur. Çok karmaşık sistemler için bitmiş bir kodda 1 satırlık bir değişiklik yapmanın maliyeti zaman ve risk açısından çok yüksektir. Bu sebeple sistemi doğru anladığımızdan emin olmamız gerekir, bunu da ancak modelleme sayesinde yapabiliriz.
Büyük yazılım projelerinde proje yöneticileri, müşteriler, çözümleyiciler, tasarımcılar, programcılar, testçiler ve teknik yazarlardan herbirinin eğitim düzeylerinin ve alt yapılarının farklı olması kaçınılmazdır, biz burada yazılım kısmı olarak 2 yada 3 kişi olarak çalışacağız ki yukarıdaki bu birçok alanı içine alıcak işler yapıcak bu kısım. Roller farklı olunca bir ekibin elemanlarının birbirleri ile iletişiminin önemi de ortaya çıkar. Çözümleyicilerin aylar süren görüşmeler sonunda elde ettikleri bütün bilgileri yazılı olarak tasarımcıya veya teyid alabilmek için müşteriye verdiğini düşününebiliyor musunuz? Oysaki sistem, çözümleyici tarafından müşteriye, tasarımcıya veya testçiye hepsinin anladıkları ortak bir dille modellenirse, çok karmaşık anlatımlar basitleşebilir ve iletişim metin ile desteklenen çeşitli diyagramlar ile maksimum düzeyde tutulabilir. Böylece müşteri sistem gereksinimleri raporunu okurken veya teknik yazarlar kullanıcı kılavuzu yazarken veya test senaryoları hazırlanırken bu ortak dilden faydalanılmış olur.
Tasarımcı, çözümleyicinin hazırladığı bazı diyagramları detaylandırıp teknik açıdan kodlamanın yolunu açabilir. Bütün bunlar projelerde yazılım kalitesini artırmanın yanı sıra, proje ekibindeki eleman değişikliğinde yeni elemanların sistemi kolayca kavrayamamasından kaynaklanacak zaman kaybını, yani maliyeti de düşürecektir.
Her yazılımın modellenmesi için mükemmel olan tek bir yöntem yoktur. Bir şirket için mükemmel olan bir modelleme yöntemi diğeri için berbat olabilir. Yapılan işin niteliğine göre farklı diyagramlara ihtiyaç duyulacaktır. Modellemede önemli olan yazılım sektöründeki herkesin ortak bir dili kullanmasıdır olmalıdır. Doğal olarak da her tür ihtiyaca cevap verebilir nitelikte bir modelleme diline ihtiyaç vardır. Müziği düşünecek olalım, 8 notayı bir araya getirerek muhteşem bir eser yaratabiliriz. Yarattığımız eseri ister flüt ile çalarız ister piyanoyla, çaldığı müzik aleti ne olursa olsun orkestranın her elemanı aynı dili anlamaktadır. Sonuçta müzik, nota dediğimiz sembollerin çeşitli şekillerde bir araya gelerek bir bütünü oluşturması ve dünyanın her köşesinde anlaşılabilir bir dilde ifade edilmesidir. Müziğin güzelliği ise besteyi yapanın yeteneğiyle sınırlıdır. Yazılım sektörü için de yazılımın parçalarını ifade edecek modelleme dili müziğin notaları gibidir. Sistemin mükemmelliği, sistemi tasarlayanların yetenekleriyle, bilgi ve tecrubeleriyle ilgilidir.
UML'ye gelince, Unified Modelling Language yazılım mühendisliğinde nesne tabanlı sistemleri modellemede kullanılan açık standart olmuş bir görsel modelleme dilidir. Büyük ve karmaşık sistemleri modellemede başarısı kanıtlanmış mühendislik tecrübeleriyle oluşmuştur. UML'nin yazılım mühendisliğindeki yerini anlayabilmek için tarihçesine söyle bir bakalım:
1989-1994 yılları yazılım mühendisliğinde Metod savaşları olarak bilinen dönemdir. Bu dönemde 50'den fazla modelleme dili paralel bir şekilde aynı şeyleri farklı yöntemlerle ifade ediyorlardı. Herbiri bazı sistemler için mükemmelken, bazıları için işe yaramaz durumdaydı ve hemen hemen hepsi yazılım yaşam döngüsünün bazı adımlarını tanımlamakta yetersiz kalıyordu. 90'lı yılların ortalarına doğru en çok tercih edilen 3 yöntem ön plana çıktı: Booch, OMT (Object Modelling Technology) ve OOSE (Object Oriented Software Engineering). Bunlardan Booch, tasarım ve gerçekleştirim konusunda mükemmeldi. OMT analiz ve veri yoğunluğu çok yüksek olan sistemlere uyuyordu. OOSE ise Use-Case adı verilen bir modelleme yöntemi ile tüm sistemin davranışını kolayca anlamayı sağlayan güçlü bir teknik içeriyordu.
1994 yılında OMT'nin yaratıcısı Jim Rumbaugh, Rational firmasının çatısı altında Booch metodunun yaratıcısı Grady Booch ile birlikte çalışmaya başladı. Daha sonra 1995'de onlara OOSE'nin yaratıcısı Ivar Jacobson da katıldı. 3 Amigolar olarak bilinen bu grup kendi yöntemlerinin olumlu taraflarını birleştirerek, komple bir yazılım projesinde sistemi modellemede kullanılabilecek eksiksiz bir modelleme dili geliştirmeye başladılar. Microsoft, Oracle, HP gibi büyük firmaların da katıldığı bir UML konsorsiyumu kuruldu ve bu şirketler UML'yi modellemelerinde kullanmaya başladılar. Nihayet 1997'de OMG (Object Management Group, kar gütmeyen, bilgisayar endüstrisi standartlarını oluşturan bir organizasyon ) UML'yi sahiplendi ve açık standart olarak geliştirmeye başladı. Doğal olarak UML herhangi bir şirkete veya kişiye ait bir modelleme dili değildir. UML şu an Rational, MS Visio, Together Soft,.. vb birçok modelleme aracı tarafından sunulmaktadır., bizde bu ortamlardan biri ile tasarım aşamasındaki en büyük adımımızı atacağız.
Yazılımın yaşam döngüsü içinde farklı görev gruplarının projeye ve sisteme farklı bakışları vardır. Müşteriyi hangi işin hangi sırayla yapılacağı, sisteme neler verip sistemden neler alacağı veya işler arası ilişkiler ilgilendirirken bir fonksiyonun detayları ilgilendirmemektedir, Çözümleyici açısından bir nesnenin özellikleri, fonksiyonları ve alacağı parametreler yeterli iken tasarımcı açısından parametrelerin veri tipleri veya fonksiyonun ne kadar bir sürede cevap üretmesi gerektiği, bir nesnenin ne zaman etkin olacagi, yaşam süresi gibi bilgiler de önemli olmaktadır. Teknik yazar ise sistemin nasıl davranacağı ve ürünün işleyişi ile ilgilenmektedir. Bu sebeplerle UML çeşitli bakış açılarını ifade eden diyagramlar içermektedir. Projeye dahil olan herkesin faydalanacağı bir veya daha fazla diyagram vardır. Yazılım geliştirme işinde rol alan kişileri özetleyecek olursak: Çözümleyiciler, tasarımcılar, programcılar, testçiler, kalite sorumluları, müşteriler / kullanıcılar, teknik yazarlar. Bunlardan her biri sistemin değişik yönleriyle farklı bakış açılarıyla ve farklı detayda ilgilenirlerken farklı UML diyagramlarından faydalanırlar.
Sistem gereksinimlerinin anlatılmasında Use-Case diyagramlar kullanılır. Bu diyagram sistemin çok basit bir şekilde modellenmesini ve işlerin detayının (senaryonun) metin olarak anlatılmasını içerir, sistemin işleyişini anlattığı için de yukarda listelenen rollerden hepsinin sıklıkla başvuracağı bir diyagramdır.
Kavramsal (conceptual) model dediğimiz Class diyagramları, gereksinimlerin müşteriye özetlenmesinde kullanılabildiği gibi, asıl olarak tasarımda kullanılmaktadır. Class diyagramları, bazı detayları saklanmış şekilde müşteri-çözümleyici iletişimini desteklerken, detaylı haliyle de tasarımcıya ve programcıya hitap etmektedir. Class diyagramların tasarımı ilgilendiren kısmı oldukça kapsamlıdır, nesne tabanlı sistemlerin doğru tasarlanması tamamen tasarımcının tecrübe ve bilgisi ile ilgilidir, bu sebeple tasarlanacak class diyagramlarında, inheritance (türetme), abstract class'lar, class hiyerarşileri, kullanılacak design pattern'lar gibi detayların düşünülmesi gerekmektedir. Bu noktada UML'nin "doğru tasarım nasıl yapılır?" sorusuna cevap vermediğini sadece bir modelleme dili olduğunu tekrar belirtmek gerekir. Sistemin performansı veya gelecekte yüzleşeceğimiz güncelleme ve bakım sorunları, yazılan kodun başka projelerde veya ek modüllerde yeniden kullanılabilir olması (code reuse) gibi detaylar tasarımcı açısından çok önemli olmalıdır. Nesne tabanlı sistemlerde doğru tasarım yöntemleri başlı başına incelenmesi gereken bir konudur.
Colloboration Diyagram dediğimiz nesneler arası etkileşim ve işbirliği diyagramları, nesneler arası akan verileri ve bunların zamana bağlı numaralanmış akış sırasını ifade eden diyagramlardır. Sequence Diyagram ise işbirliği diyagramının ifade ettiği şeyin aynısını bir zaman çizgisi üzerinde farklı bir gösterimle ifade etmektedir. Bu iki diyagram (colloboration ve sequence diyagramlar) biri hazırlanınca diğeri otomatik üretilebilen diyagramlardır.
State Diyagramları (Durum Diyagramları) ise nesnelerin durum değişikliklerini ifade etmekte kullanılırlar, trafik ışıklarının renkler arası geçişi gibi, bir nesneye ilişkin durum değişiklikleri bu diyagramlar ile ifade edilir.
Package Diyagramları (Paket Diyagramları) büyük yazılımlarda sistemi oluşturan alt yazılımlar veya etkileşimde bulunulan yan sistemler olduğu durumda bu paketler arası etkileşimi gösteren kısaca sistem mimarisinin paket yönünü özetleyen kavramsal bir diyagramdır.
Component Diyagramları (Bileşen Diyagramları) ise Paket diyagramlarının fiziksel anlatımıdır. Basitçe paketler yerine, paket içinde yer alan .dll, exe gibi dosyaları ve bunlar arası etkileşimin gösterildiği bir diyagramdır. Paket diyagramlar sistemin analizi ve tasarımı aşamasında kullanılabilirken Bileşen diyagramları programlama bittikten sonra sistemi tarif eder niteliktedir.
Deployment Diyagramları (Dağıtım Diyagramları) yazılımın nasıl dağıtılacağının planlandığı aşamada yardımcı olurlar. Yazılımın kurulacağı bilgisayarların konfigürasyonu, ağ ve yazıcı bağlantıları gibi detayları kapsamaktadır.
Yukarda kısaca anlatılan diyagramlar sayesinde büyük bir yazılımın yaşam döngüsü içinde her adımı kapsayan, ve sisteme çeşitli gözlerden bakış açısı sunan bir modelleme tekniği olarak UML günümüzün nesne tabanlı bir yazılım projesinin paydaşlarını konuşturan en kapsamlı ve en basit ortak dildir düşüncesini taşıyorum.
