Yazılım Geliştirme’de Modelleme: Modellemeli mi Modellememeli mi?

Yazılım projelerinde modellemeye ihtiyaç olup olmadığı, ihtiyaç varsa da hangi düzeyde ve ne kadar modelleme yapılacağı bir tartışma konusudur. Ben de değişik vesilelerle bulunduğum ortamlarda bu konuda sorulara muhatap oluyorum. Dolayısıyla bu noktayı hızlıca açıklığa kavuşturmak gerekli.

Önce modelin ne olduğundan başlayalım. Kavramı hiç te karmaşıklaştırmadan, herkesin anlayacağı şekilde tanımladığımızda, model, gerçekliğin bir basitleştirilmesidir. Bu anlamda modelleme, insan zihninin her an yapmakta olduğu şeydir. Bizler gördüklerimizi, işittiklerimizi, dokunduklarımızı vs. ancak belli basitleştirmeler ve filtrelerle anlamlandırabiliriz. Dolayısıyla modeller aslında çok daha karmaşık olan şeyleri, zihnimizin kavrayabileceği formlara dönüştürür. Bu basitleştirme ve filtreler ya bizim doğuştan gelen zihni yapımızdan kaynaklanır ya da çevremizin, içinde yaşadığımız toplumun bize öğrettiklerinden. Bundan dolayı elimizdeki bir meyvayı, boyutları ve rengi gibi çok temel özellikleriyle algılar ve örneğin kırsal kesimde yetişmişsek, belki koklayarak ya da belli yerlerine bakarak kalitesini anlamaya çalışırız. Meyvayı, boyutlarıyla algılamak, doğuştan gelen yeteneklerimizi, koklayıp, örneğin sapının ne kadar yeşil olduğuna bakmak ise çevremizin bize kazandırdığı yeteneklerimizi kullanarak, o meyvanın zihnimizde bir modelini çıkarmaktır. Bu anlamda zihnimizdeki her şey aslında bir modeldir. Dolayısıyla model, kavramsaldır, soyuttur, fiziksel gerçeklikten çok farklı bir noktadadır.

Peki niye modelleriz? Öncelikle elimizde olmadığı için, zihnimiz öyle çalıştığı için yani. Çünkü gerçeklik sonsuz karmaşıklıktadır. Gerçeklik her yönde sonsuz derinliği ve detayı içerir. Dolayısıyla bu halimizle zihnimizin, gerçekliğin bütün karmaşıklığını, herhangi bir basitleştirme ve filtreleme yapmadan bütün detayıyla algılaması mümkün değildir. Zihnimiz gerçeklikle ilgili pek çok detayı elemesine rağmen, çoğu zaman modeller ile doğru kararlar verebilmektedir. Örneğin elimize aldığımız bir karpuzu satın almaya karar verebilmek için yukarıda bahsettiğim 3-4 değişkenli bir model, örneğin karpuzların DNA yapısı üzerine doktora yapmıyorsak, yeterlidir.

“… karpuzların DNA yapısı üzerine doktora yapmıyorsak yeterlidir.” cümlesi aslında modelin bir başka özelliğini açığa çıkarıyor: Modeller mutlak değildir. Yani herşeyin, bulunduğumuz noktaya göre değişen çok farklı modelleri olabilir. Bulunduğumuz noktayı çevremizin bize öğrettiği/dayattığı şeyler belirlediği gibi, biz de insiyatif alıp bir niyet ile duruşumuzu belirleyebiliriz. Karşı karşıya kaldığımız durumu algılarken bizim için önemli olan açılardan bakarız ve modelimizi bu önemli açıları göz önüne alarak geliştiririz. Dolayısıyla modeller zaten basitleştirme olduklarından doğru değillerdir ve teoride aynı nesnenin ya da durumun sonsuz sayıda modeli vardır. Bir modeli diğerine üstün kılan şey, olsa olsa, üstün olan modelin bizim ilgi alanımıza ya da kaygılarımıza daha fazla hitap ediyor olmasıdır. Yani modelin, gerçekliği, bizim niyetimize göre doğru bir şekilde basitleştirip basitleştirmediğidir aslolan.

Tabi ki bütün bu tartışmayı yaparken ben de bir model kurdum gerçeklikle alakalı ve gerçekliği, bizden ötede duran bir nesne gibi varsaydım: Gerçeklik bizden uzakta orada duruyor ve ben onu modellerim yardımıyla algılıyorum. -Her ne kadar koskoca modernite böyle çok temel bir algı üzerine kurulmuşsa da- bu da doğru değil aslında, çünkü gerçekliğin çoğunu zihinlerimiz oluşturur zaten: Metre ya da kilogram gibi ölçü birimlerimiz, yarattığımız gerçekliğin en açık olan parçalarındandır. Biraz üzerine eğildiğimizde korkularımız, ümitlerimiz, değer yargılarımız, sosyal kurumlarımız vs., pek çoğu insan zihninin eseri olduğunu farkederiz. Bu noktada, zihnimizdeki modelin mi gerçeklikten oluştuğu yoksa gerçekliğin mi zihnimizdeki modelden ortaya çıktığı çok kadim bir soru olup, karmaşıklığı benim boyumu aşmaktadır. Örneğin, renk kavramının zihnimizdeki bir modelden mi neşet ettiği yoksa tecrübemizden mi ortaya çıktığını sorgulamak, bu kadim sorunun cevabının hiç te kolay olmadığını anlamak açısından yeterli bir örnektir. Ancak şunu söyleyebilirim ki mutlak gerçek sandığımız pek çok şey aslında zihnimizin ürünüdür ve başka şartlara sahip kişiler için bunlar hiç te gerçek olmayabilir.

Esas konumuza dönersek, yazılım zaten tamamen insan zihninin bir ürünüdür, aynı zamanda çok büyük oranda soyuttur ve kavramsaldır. Ve daha da önemlisi, yazılımın kendisi bir modelleme aracıdır, bir gerçeklik oluşturma ortamıdır: Yazılım, günlük dilde ifade edilebilen bir iş sürecini, bir işi yapışı, bilgisayar dediğimiz makinalar yardımıyla daha hızlı ve otomatik olarak yapabilmenin bir  aracıdır. Günlük dil zaten bir gerçeklik alanıdır, bilgisayarlar ise başka bir gerçeklik alanı. Yazılım ise bir modeldir, öyle ki günlük dilde ifade edileni, bilgisayar ortamında ifade edilebilecek ya da çalışabilecek şekilde dönüştürür. Lakin bu dönüştürme öyle bir seferde yapılabilecek kadar da kolay değildir. Yani günlük dilde ifade edilen bir iş süreci, örneğin Fahrenheit ile ifade edilen bir sıcaklığın Celcius’da neye karşılık geldiğini bulmak kadar kolay bir şey ise, biraz programlama tecrübesi olan kişi, bu ifadeyi, hemen hiç hatasız ve bir kerede yazılım olarak kodlayıp, çalışır hale getirebilir. Fakat daha karmaşık iş süreçlerinden bahsediyorsak ya da birden fazla iç içe girmiş, pek çok kullanıcısı olan, insan olan ve olmayan farklı aktörlere sahip iş süreçlerini ele alıyorsak, yukarıdaki F-C çeviricide olduğu gibi bir seferde bu süreçleri yazılım olarak ifade etmemiz imkansızdır. Öte taraftan yazılım ürünü çok kavramsal ve görünmez bir nitelikte olduğundan algılanması, ifade edilmesi ve aktarılması zaten zor olan bir şeydir. Dolayısıyla yazılım, günlük dilde ifade edilen ve gerçek hayatta el ile yapılan işlerden çok farklı bir gerçeklik düzeyindedir. Yazılımda “for” döngüleri ya da “if” yapıları vardır örneğin ve bu yapılar gerçek hayattaki tekrarlamalara ya da karar mekanizmalarına karşılık gelse bile gerçek dünyadakine göre çok daha formal ve matematikseldirler, yani sokaktan çevirdiğimiz herhangi bir insanın anlayabileceğinden çok daha soyut seviyede ifade edilirler, sanki düz yazıya karşılık şiir gibi, daha soyut ve daha yoğun anlamlı… Dolayısıyla operasyonel iş yapış şekillerini, bu iş yapışları yönlendiren iş kurallarını, bu işler yapılırken süreçlere dahil olan insan, sistem, donanım vs. tipindeki farklı aktörleri ve bu aktörlere karşı sistemde olması gereken arayüzleri yakalayıp, iç bütünlüğü yüksek olarak ve daha sonra yapılacak değişimlere kolay el vererecek şekilde bir yazılıma dönüştürmek F-C çeviricide olduğu kadar kolay olmayacaktır. Bu yüzden böyle bir dönüşümü bir seferde yapmak yerine birkaç seferde yapmayı ve her seferinde operasyonel çalışmayı ifade eden dilsel ifade alanından uzaklaşıp yazılım alanına daha fazla yaklaşmayı çalışırız öyle ki birkaç adım sonra elimizde son ürünümüz olan yazılımız olsun ve bu yazılım operasyonel iş süreçlerini başarıyla yerine getirsin.  Dolayısıyla ele alınan işin yapısı, süreçleri, kuralları, aktörleri vs. sayı olarak ne kadar çok ve karmaşıksa, bu ara adımların sayısı o kadar çok olacak ve her adımda o kadar çok iş ya da dönüştürme yapılacak demektir.

Şimdi ilk sorumuzun karşılığını verebiliriz. Yazılım projelerinde modelleme gerekli midir? Bir zihnin tüm detaylarını kavramaktan aciz olduğu her yazılım projesi için modelleme gereklidir. Burada modellemenin bir süreç olduğunu ve yapıldıkça, kişinin modellenen alan ile ilgili bilgi ve tecrübesinin arttığını ve böylece modelin gittikçe daha iyi hale geldiğini ifade etmek gerekir. Öte taraftan yazılım projesinde yer alan kişi sayısı arttıkça da modele başvurmak gereklidir. Çünkü modeller, dilden daha fazla kesinlik içeren bir iletişim aracıdır ve özellikle daha teknik insanlar modeller sayesinde çok daha iyi anlaşırlar.

Modellemeye ihtiyacımız olduğunu düşünüyorsak, yani projemizin yukarıda ifade ettiğimiz F-C çeviricisinden daha karmaşık olduğunu biliyorsak, hangi tür modelleri kurgulamamız gereklidir? Bir yazılım projesinde en temelde iki tür model olduğunu söyleyebiliriz: İhtiyaçların modeli ile bu ihtiyaçları yerine getiren çözümün modeli.

İhtiyaçların modeli, ortaya çıkacak yazılım sisteminin yerine getirmesi gereken fonksiyonel olan ve olmayan ihtiyaçların, müşteriden yani sistem kullanıcıları ve diğer paydaşlardan toplandıktan sonra, kullanım şekli (use-case) ve domain modeli gibi daha formal yapılarla modellenmesini ifade eder. Bu noktada kullanım şekilleri, süreçleri, kullanıcı açısından ve onun anlayabileceği bir formda modellerken, domain modeli gibi yapılar daha matematiksel olup ilkel bir tasarım hüviyetindedirler. (İhtiyaç analizinde tabi olarak çok farklı modeller geliştirilmiş ve uygulanmaktadır. Burada kullanım şekillerinden bahsetmemizin sebebi, kullanım şekillerinin doğru uygulandığında, herbiri birer süreç olan müşterinin iş yapış şekillerini ele almada ve müşteri gözüyle modellemede çok başarılı olmalarıdır. Farklı yaklaşımlarda farklı modeller pekala başarıyla kullanılabilir.) Domain modellemesi genel olarak, fonksiyonel  ihtiyaçlardan yola çıkarak en temel soyutlamaları ve nesneleri bulmayı amaçlar. Bu anlamda domein modeli en temelde, ihtiyaçların bir nesne modelini içerir. Proje grubu bu modellerle ihtiyaçlarla alakalı bilgilerini arttırdığı gibi ihtiyaçlardaki eksiklik ya da zıtlık gibi muhtemel sıkıntıları ortaya çıkarırlar. Domain modellemesi, bir nesne-merkezli çözümleme/analiz (object-oriented analysis) çalışması olup, kullanım şekilleri, senaryolar, iş kuralları, sistem vs. ihtiyaçları ile ifade edilmiş toplam ihtiyaç kümesinin, bir nesne-merkezli çözüme geçiş sağlayacak şekilde yorumlanmasından başka bir şey değildir. Bu anlamda domain modeli çok önemlidir ve yazılım projesindeki belki de en kritik geçiş olan ihtiyaç alanı –> çözüm alanı bağlantısının sağlıklı bir şekilde yapılmasını sağlar. Böyle bir modelin bir diğer pozitif etkisi de ihtiyaçları algılamakta zorluk çeken ve genel olarak programcılardan oluşan çözüm takımının (Bu son cümlemizle zaten analist-programcı ayrımı yapmış olup, projede bu iki tipten grup çalışanın olduğunu kabul ediyoruz. Programcıların aynı zamanda analist olarak davranıp, projedeki ihtiyaçları ortaya çıkarma faaliyetine de giriştikleri durumlarda bu geçişin daha sağlıklı olduğu iddia edilmekle birlikte böyle bir yapılanmanın hatırı sayılır büyüklükteki bir projede nasıl sıkıntılar yaratabileceği bir başka yazının konusudur.) ihtiyaçları anlamasını kolaylaştırmasıdır. Ben çok sıklıkla developerların yazdıkları analiz dokümanlarını, ne kadar detaylı ve sistemli olursa olsun, okumadıklarından yakınan analistler ya da yöneticilerle karşılaşıyorum.

Dünyadaki ve ülkemizdeki pratik, bize ihtiyaçların modellemesinin çok az yapıldığını göstermektedir. Genel olarak yapılan ihtiyaçların toplanmasıdır, modellemesi es geçilir, ya da daha doğru ifadeyle pek çoğumuz “yazılımda modelleme”den ihtiyaçların modellemesini anlamayız. Bu durumda analist olarak çalışanlar da projede çoğunlukla bir postacıdan öteye gidemezler. Bu durum, analizden sonraki safhaya daha fazla yük bindirir ve hataların sayısını arttırır.

Çözümün modeli, temel olarak ihtiyaç modeli üzerine kurulur ve kullanım şekli merkezli ihtiyaçlar ile bu ihtiyaçları gerçekleştirecek çalışan kod arasında bir köprü görevi görürler. Fonksiyonel ve mimari tasarım olarak iki parçadan oluşan çözüm modelinde, kod yazmadan, kodun bileşenleri olan nesneler arasındaki ilişkileri, statik, dinamik, fiziksel yerleşim vb. farklı açılardan betimleriz. Bu da bir modeldir ve bu modelin güzel tarafı, doğru yapıldığında kendisinden üretilecek olan kodun doğruluğunu büyük ölçüde garanti altına almasıdır. Şunu unutmayalım, kodun doğru yazılması ile doğru kodun yazılması farklı şeylerdir: Kodun doğru yazılması, kendi içinde bir tutarlılık gerektirir. Doğru kodun yazılması ise sadece koda bakarak anlaşılacak birşey değildir. Ve problemlerin çoğu da kodun doğru yazılmamasından değil, doğru olsa da yanlış kodun yazılmasından kaynaklanmaktadır.

Modeller ne işe yararlar sorusuna şu cevapları verebiliriz artık?

• Modeller, üzerinde çalıştığımız alanla alakalı bilgimizi arttırırlar, zihnimizin bu alanı içselleştirmesine yardımcı olurlar.
• Modeller, doğru zamanda doğru açıda durmamızı ve doğru detayı ele almamızı sağlarlar. Hiçbir insan zihni, ne kadar zeki olursa olsun, örneğin Java dili ile program yazarken, yani dil detayında odaklanmışken, daha önce düşünmediği, ama koduna sağlıklı bir şekilde devam edebilmek için hallolması gereken örneğin bir iş süreci seviyesine çıkıp, onu halledip tekrar dil seviyesine inecek lükse sahip değildir kanımca. Zihni böyle bir konuma itmek ona haksızlıktır. Aynı konuda daha önce 5-10 defa karşılaşmamışsanız, önünüze ilk defa gelen bir konuda zihninizden bu kadar çevik davranmasını ve sonuçta doğru karar vermesini bekleyemezsiniz. Sonuçta iki şeyi kaçırmanız işten bile değildir: Gerekli bilgiye sahip olmayabilrisiniz ve bu kadar çevik bir iniş çıkışta bunun farkına bile varamazsınız. Zihnin farklı detay seviyeleri arsında gidiş gelişi ya da context switching, sanıldığı kadar da kolay değildir. Birden kendinizi Inception seyreder gibi hissedebilirsiniz: Kaçıcı seviye rüyadayız şimdi?
• Modeller, çok iyi bir iletişim aracıdırlar. Çünkü modeller formaldir ve soyuttur, dolayısıyla kesinlikleri dilden daha fazla ve ifade ettikleri şey düz yazıdan çoktur. Örneğin UML gibi bir model dilinin temel soyutlamaları bilenler UML ile yapılmış bir modeli kullanarak, kullanmayanlara göre çok daha doğru ve hızlı anlaşırlar. Pek aynı dili konuşan, aynı kelimeleri kullanan insanların yazılımdan bahsederken birbirlerini kendisini anlamamakla suçladıklarına çok şahit olmuşumdur. Sonra tutar birisi tahtada görsel bir kaç betimeleme yapar, ya da yalancı kod (pseudo code) cinsinden birşeyler yazar, sular durulur.
• Paradoksal gelebilir ama modeller, soyut olan, yani tamamen zihinsel olan yazılımı, daha görülen, elle tutulabilen hale getirirler. Yazılım soyut, modeller dhaa da soyut diye düşünülebilir. Ama doğru olan şey, modellerin, karmaşıklığı algılanabilir kılma gücüdür. Modeller, geçekliği algılanabilir kılıyorsa, yazılımı haydi haydi algılanabilir kılarlar, yeter ki doğru modeller ve yaklaşımlar tercih edilsin.
• Modeller tekrar kullanılabilirler. Tekrar kullanım denildiğinde ilk akla gelen kodun tekrar kullanımıdır. Unutmayalım ki düzgün bir modelleme süreciyle üretilmemiş kodların tekrar kullanılabilmesi, tamamen şansa bağlıdır.

Yazılım, ancak modelleme ile, ağırlıklı olarak bir programlama aktivitesi olarak görülmekten çıkıp, süreç odaklı bir mühendislik disiplini haline gelebilir. Modelleme yapmadığımız müddetçe, kartlarımzıda, pozisyonlarımızda “Yazılım Mühendisi” yazmasının bence çok fazla bir anlamı yok. Modelleme yapmadığımız müddetçe, üniversiteye giriş sınavında ilk bilmem kaça girdiğimizin ya da ne kadar kaliteli bir bölümden mezun olduğumuzun da hiçbir önemi yok. Çünkü iddia ediyorum ki geri kalan, akıllı bir lise öğrencisinin yapabileceği şeyler. Sizce okullarımızda, yoğun geçen bir Matematik dersinin sonunda öğrencilerin, “hocam bu konular gerçek hayatta ne işimize yarayacak” diye sormaları ve pek çok hocanın traji komik bir biçimde bu soruya tatmin edici bir cevap verememesi ile işlerimizde modellere çok az yer vermemiz arasında bir ilişki var mıdır?

Bol modelli günler dilerim 🙂

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