Model Nedir ve Neden Modelleriz?

Model, gerçeğin basitleştirilmiş halidir. Yani, karmaşık bir sistemi modelleyerek onu daha basit bir dille ifade edebiliriz; böylece geliştirmekte olduğumuz sistemi daha iyi anlayabilir ve olası hatalarımızı uygulamaya geçirmeden görebiliriz.

Aslında, kendimiz için küçük bir kulübe yapmak istersek birkaç ağaç, biraz da saman yeterli olacak ve sonunda işe yarar bir yapı çıkacaktır. Ufak tefek hatalar olsa da bu çok sorun olmayacaktır, çünkü bu sorunu başlangıçtaki isteklerimizden biraz kısararak, ya da işe en baştan başlayarak çözebiliriz. Fakat iş büyük çapta bir bina yapımına geldiğinde, o bina için mimari plan çıkarmak zorunlu hale gelir. Artık işe en baştan başlama gibi bir olanağımız yoktur, istekler biz binanın yapımına başladığımızdan sonra bile değişebilir veya müşteri yeni isteklerle gelebilir. Bu bina yapımına da kulübe gibi başlayabiliriz tabi. Ama bu işi tek başımıza yapamayacağımıza göre, binayı istenen şekilde, işe yarar bir biçimde bitirebilmek için doğru zamanda, doğru yerde olan ve doğru bilgilere sahip çalışma arkadaşlarımız olmalı. Ancak, gerçek hayatta böyle çalışma arkadaşları pek fazla bulunmuyor.

Büyük ve karmaşık yazılım projeleri için de durum çok farklı değildir. Başarısız projelerin hepsi değişik sebeplerden ötürü, kendilerine has bir biçimde çökerken, başarılı kurumların sahip olduğu en önemli özelliklerden birisi doğru modellemenin kullanılmasıdır. Modelleme yapılırken şu 4 ilke dikkate alınmalıdır,

  • Modeller iyi seçilmeli, doğru modeller en karmaşık problemleri çözmede yardımcı olabileceği gibi, yanlış model seçimi sizi yanıltabilir ve ilgisiz konulara odaklanmanıza neden olabilir.
  • Farklı detay seviyelerine sahip modelleriniz olmalı, bazen binanıza üstten bakarak genel yapısını incelemeniz gerekebilir, bazen de bir odanın yer döşemesiyle ilgilenirsiniz.
  • En iyi modeller gerçekle bağlantılı olanlardır, binanız için tasarladığınız fiziksel bir model gerçek hayatta olması gerektiği gibi davranmıyorsa, o modelin pek de değeri yoktur.
  • Yalnız bir model hiçbir zaman yeterli değildir, örneğin bir bina yapıyorsanız, zemin planlarının yanında elektrik, ısınma ve su gereksinimleri için de planlar oluşturmalısınız.

UML ve Tarihçesi

UML (Unified Modelling Language, Birleşik Modelleme Dili) yazılım modellenmesi ve planlanması için kullanılan standart bir dildir. UML, yazılım ağırlıklı bir sistemi ve bu sistemin parçalarını gözde canlandırmak, belirtmek, kurmak ve belgelemek için kullanılabilir. Kurumsal bilgi sistemlerinden, dağıtımlı ağ-tabanlı uygulamalara ve gerçek zamanlı gömülü sistemlere kadar birçok sistemi modellemek için uygun bir dildir. UML bir programlama ya da yazılım geliştirme dili değil, sistem modellemelerinde kullanılan yöntemlerin bir araya getirilmiş halidir. UML hangi modelleri kullanmanız gerektiğini söylemez, sadece iyi biçimlendirilmiş modelleri anlamanızı ve yaratmanızı öğretir. Yazılım mühendisliğinde önemli bir yere sahip olan UML’nin ortaya çıkışı kısaca şöyle özetlenebilir:

1989-1994 yılları arasında yazılım dünyasında sistemleri modellemek için onlarca modelleme dili kullanılıyordu. Bu dilleri kullanan yöntemler belirli tip sistemler için tasarlanmıştı ve yazılım yaşam döngüsünü tam olarak tanımlyamıyorlardı. Bu yöntemlerden zaman içinde en çok tercih edilenleri Booch, OMT (Object Modelling Technology, Nesne Modelleme Teknolojisi) ve OOSE (Object Oriented Software Engineering, Nesne Yönelimli Yazılım Mühendisliği) oldu. Booch, Nesne Yönelimli Tasarım konusunda; OMT, Nesne Yönelimli Analiz gerektiren sistemlerde mükemmeldi. OOSE yöntemi ise sistemin genel yapısını anlamayı çok kolaylaştıran Kullanım Senaryosu (Use-Case) adlı güçlü bir tekniği içeriyordu.

1994 yılında Grady Booch (Booch yönteminin yaratıcısı) ve Jim Rumbaugh (OMT yönteminin yaratıcısı) Rational firmasının çatısı altında sahip oldukları iki yöntemi tekrar gözden geçirerek birleşik bir yöntem yaratmak için çalışmaya başladılar. Firmaya 1995 yılında Ivar Jacobson’ın (OOSE yönteminin yaratıcısı) da katılmasıyla, 3 Amigolar olarak bilinen grup, kendi yöntemlerinin güçlü yönlerini birleştirip eksiksiz bir sistem modelleme dili yaratmak üzere çalışmaya başladılar.

1996 yılında 3 Amigoların önderliğinde, Unified Modelling Language (UML) ismi verilen birleşik modelleme dilinin sonuçlandırılması amacıyla UML Partners isimli bir şirkeler birliği kuruldu. Microsoft, IBM, Oracle, Hewlett-Packard, Texas Instruments gibi dev şirketleri de içeren birlik üyeleri UML’yi kendi modellemelerinde kullanmaya başladılar. UML 1.0, taslak olarak 1997 Ocak ayında OMG’ye (Object Management Group, nesne yönelimli sistemler için standartlar belirlemek amacıyla kurulan, kar gütmeyen bir organizasyon) tanıtıldı. Birkaç aylık bir çalışmanın ardından UML 1.1, Ağustos’ta OMG’ye sunuldu ve Kasım ayında kabul edilerek, belirli bir kişi ya da şirkete ait olmayan bir modelleme dili yazılım dünyasına kazandırılmış oldu.

UML 2.0 ve Diyagramlar

UML 1997’den bu yana 1.1, 1.3, 1.4 ve 1.5 gibi versiyonların ardından 2005’te çıkan 2.0 versiyonu ile birçok yönden geliştirilmş, dildeki eksikler tamamlanmış ve hatalar ortadan kaldırılmıştır. Son versiyonu UML 2.1.2, 2007 Kasım ayında çıkmıştır. Grafiksel bir dil olan UML, modelleme için değişik diyagramlar kullanır. Diyagramlar, bir sistem modelini kısmen tarif eden grafiklerdir. UML diyagramları bir sistem modelini 3 farklı açıdan ele alırlar. Modelin,

  • İşlevsel gereksinimler açısında, kullanıcının bakış açısından sistemin gereksinimleri vurgulanır. Kullanım Senaryosu (Use-Case) diyagramını içerir.
  • Statik yapısal açısında, nesneler, nesnelere ait özellikler ve ilişkiler kullanılarak sistemin statik yapısı incelenir. Sınıf (Class) ve Birleşik Yapı (Composite Structure) diyagramlarını içerir.
  • Dinamik davranış açısında, nesneler arası ortak çalışmalar ve nesnelerin durumlarındaki değişiklikler gösterilerek sistemin dinamik davranışı incelenir. Sıralama (Sequence), Faaliyet (Activity) ve Durum (Statechart) diyagramlarını içerir.

UML 2.0, 3 ana bölüme ayırabileceğimiz 13 çeşit diyagram içerir. Yapısal diyagramlarda modellenen sistemde nelerin var olması gerektiği vurgulanır. Davranış diyagramlarında modellenen sistemde nelerin meydana gelmesi gerektiğini belirtir. Davranış diyagramlarının bir alt kümesi olan Etkileşim diyagramlarında ise modellenen sistemdeki elemanlar arasındaki veri ve komut akışı gösterilir.

Yapısal Diyagramlar

  • Sınıf (Class) diyagramı, sistemin yapısını anlatmak için sistemde var olan sınıfları, sınıfların özelliklerini ve sınıflar arası ilişkileri kullanır. Nesneye yönelik sistemleri modellemede kullanılan en yaygın diyagramdır.
  • Nesne (Object) diyagramı, modellenen sistemin yapısının belirli bir andaki bütün ya da kısmi görünüşü tarif edilir.
  • Bileşen (Component) diyagramı, bir yazılım sisteminin hangi tür bileşenlere ayrıldığını ve bu bileşenlerin nasıl birbiriyle ilişkili olduğunu betimler. Bir bileşen genellikle bir veya birden fazla sınıf, arayüz ve iletişime karşılık gelir.
  • Paket (Package) diyagramı, bir sistemin hangi mantıksal gruplara bölündüğünü ve bu gruplar arasındaki bağımlılıkları betimler.
  • Dağılım (Deployment) diyagramı, sistemde kullanılan donanımları, bu donanımların içinde yer alan bileşenleri ve bu bileşenlerin arasındaki bağlantıları gösterir.
  • Birleşik Yapı (Composite Structure) diyagramı, bir sınıfın iç yapısını ve bu yapının mümkün kıldığı iletişimleri tarif eder.

Davranış Diyagramları

  • Kullanım Senaryosu (Use-Case) diyagramı, modellenen sistem tarafından sağlanan işlevselliği sistemde yer alan aktörleri, aktörlerin sahip olduğu kullanım senaryolarını ve bu senaryolar arasındaki bağımlılıkları göstererek açıklar.
  • Durum (Statechart) diyagramı, bilgisayar programlarından iş süreçlerine kadar birçok sistemi tarif eden standartlaşmış bir gösterimdir. Durumlar, geçişler, olaylar ve faaliyetler gösterilir.
  • Faaliyet (Activity) diyagramı, modellenen sistemdeki iş akışını adım adım gösterir. Faaliyet diyagramı kapsamlı bir komut akışını tarif eder. Faaliyetler arası akışı gösteren Durum diyagramıdır.

Etkileşim Diyagramları

  • Sıralama (Sequence) diyagramı, nesnelerin birbiriyle nasıl iletişim sağladıklarını sıralı iletiler şeklinde gösterir. Ayrıca nesnelerin yaşam süreleri de gösterilir.
  • İletişim (Communication) diyagramı, nesneler ve parçalar arasındaki etkileşimi sıralı iletiler olarak gösterir. Sınıf, Sıralama ve Kullanım Senaryoları diyagramlarındaki bilgileri kullanarak sistemin hem statik yapısını hem de dinamik davranışını gösterir.
  • Etkileşime Bakış (Interaction Overview) diyagramı, farklı etkileşim diyagramları kullanarak, bunlar arasındaki komut akışını gösterir. Bir başka deyişle, elemanları etkileşim diyagramları olan faaliyet diyagramlarıdır.
  • Zaman Akış (Timing) diyagramı, odağın zaman kısıtlamarı olduğu etkileşim diyagramıdır.

UML Ne Kazandırır?

Modelleme ihtiyacımızdan kısaca bahsettikten sonra, bu ihtiyacı karşılamak üzere UML’nin nasıl ortaya çıktığından bahsettik. UML’nin modellemeye bakış açısını ve UML diyagramlarının neler olduğunu gördüğümüze göre, artık büyük bir bina yapımına kulübe yapar gibi başlamayacağız. Peki UML kullanarak yapacağımız sistem modellemesi bize ne kazandırır?

  • Takım çalışmasında yardımcı olur, UML standartlaşmış uluslararası bir dildir ve bu dili bilen herkes diyagramlardan aynı şeyleri anlar. Müşteri ve teknik sorumlular diyagramlar üzerinden rahatça iletişim kurabilirler. Ekibinizde yer alan çalışma arkadaşlarınızla uyumlu bir şekilde çalışabilirsiniz ve ekibe yeni giren bir çalışan da projeye rahatlıkla dahil edilebilir.
  • Kodlamayı kolaylaştırır, UML ile uygulamanızın tasarımı analiz aşamasında yapıldığı için, modellemeniz bittikten hemen sonra kod yazmaya başlayabilirsiniz.
  • Hataları en aza indirir, UML ile bütün sistem tasarlandığı için sistemde hata çıkma olasılığı azdır. Çıkan hataları düzeltmek ise çok daha kolaydır.
  • Tekrar kullanılabilir bileşenleriniz artar, UML ile tüm sistem ve sistemin bileşenleri daha baştan belirlendiği için, o bölümler tekrar tekrar yazılmayacaktır.
  • Program kararlılığı artar, UML ile ayrıntılı gereksinim analizleri yapıldıktan sonra senaryolar belirlenir. Senaryoların baştan belirli olması programınızı daha kararlı hale getirmenizde size yardımcı olur.

Kaynaklar: