yazılım

Yazılımı Anlamak Üzerine

Bilgisayar Bilimleri, Yazılım Mühendisliği , , , , ,

C++’ın babası olan Bjarne Stroustrup, “The C++ Programming Language” isimli kitabında şöyle der: “Design and programming are human activities; forget that and all is lost.” ya da Türkçesiyle: “Tasarım ve programlama insani işlerdir; bunu unutun, herşey kaybolur. ”

Ben bu cümleyi eskiden bu yana şöyle anlıyorum: Yazılımı tasarlamak olsun, programlamak olsun, öyle uzaylıların yaptıkları işler değildir, tamamen insani faaliyetlerdir, fırıncının ekmeğini yapması gibi ya da futbolcunun futbolunu oynaması ya da bir öğretmenin öğrencilerini eğitmesi gibi, doğrusuyla, yanlışıyla, tamamen insan ve tabi çevresinin işin içinde olduğu faaliyetlerdendir. Eğer bu geçeği unutursak, yazılımı geliştirmeyi, elit, ayrık yani doğal insani ortamından koparılmış gibi ele alırsak, ortada yazılım falan kalmaz. Nitekim üstad bu cümleyi şöyle bir paragrafta söylüyor:

“Too often, we forget the human aspects of system building and consider the software development process as simply ‘‘a series of welldefined steps, each performing specific actions on inputs according to predefined rules to produce the desired outputs.’’ The very language used conceals the human involvement! Design and programming are human activities; forget that and all is lost.”

Yani

“Çok sıklıkla, sistem inşa etmenin insani taraflarını unutuyoruz ve yazılım geliştirmeyi “önceden tanımlanmış kurallara göre girilen verilerden istenen çıktıları üretmek için özel işlemleri yapacak şekilde kurgulanmış, her biri iyi tanımlanmış adımlardan oluşan bir seri” gibi düşünüyoruz. Kullanılan programlama dilinin kendisi, insanın katkısını saklıyor. Tasarım ve programlama insani işlerdir; bunu unutun, herşey kaybolur.”

Evet yazılımı tasarlarken ya da geliştirirken, fildişi kulelerde, her türlü şeyin düşünüldüğü, son derece formal ortamlarda çalışmıyoruz biz. Bakkal Hasan amcanın kendi ortamında bir problemi çözerken kullandığı araçlar ve yöntemlere benzer şeyler kullanıyoruz biz de. Durum Amerikan filmlerinde gördüğümüz şu cümleyle de güzel bir şekilde açıklanabilir: “It is not rocket science!”

Stroustrup’un yukarıdaki paragraftaki şu cümlesi bizim yazılıma sanki uzaydan gelme bir şeymiş, rocket sciencemış gibi davranmamızın sebebini açıklıyor sanırım: “Kullanılan programlama dilinin kendisi, insanın katkısını saklıyor.” Yani kullandığımız programlama dilleri, araçlar, sistemler vs. aşırı karmaşık ve matematiksel yapısından dolayı olayı yani yazılım geliştirmeyi, mistik, kaotik ve esoterik, sadece ehlinin anlayacağı bir iş, olarak görmemize, kurgulamamıza ve dışarıya yansıtmamıza sebep oluyor. Yani yazılımcılar olarak bizler sanki sabah akşam kapalı kapılar ardında, orta çağın büyücüleri gibi, başkalarının gördüğünde “vuuuuuuu, çok etkilendiiimmm” cinsinden laflar söyleyeceği işler yapıyoruz. Halbuki üstad diyor ki, bu bir yanlış anlamadır, kullandığımız dil vb. araçlar böyle bir algı oluşturabilir ama bu yanlıştır. Her insani faaliyet gibi yazılım geliştirme de son derece insanidir. Örneğin şunu diyor Stroustrup:

“…

–  There are no ‘‘cookbook’’ methods that can replace intelligence, experience, and good taste in design and programming.

–  Experimentation is essential for all nontrivial software development.

…

It is easy –  and typically expensive –  to underestimate any of these points. It is hard to transform the abstract ideas they embody into practice. The need for experience should be noted. Like boat building, bicycling, and programming, design is not a skill that can be mastered through theoretical study alone.”

Yani

“…

–  Tasarım ve programlamada insan zekası, tecrübesi ve estetiğinin yerine geçebilecek hiç bir reçete metot yoktur.

–  Deneme – yanılma, basit olmayan her yazılım projesi için asıldır.

…

Bu noktaları gözden kaçırmak kolaydır ve sıklıkla pahalıdır. Soyut fikirleri pratiğe dökmek zordur. Tecrübeye olan ihtiyacımıza dikkat edilmelidir. Gemi inşa etme, bisiklete binme ve programlama gibi tasarım da sadece teorik çalışmayla elde edilebilecek bir yetkinlik değildir.”

Peki neden durup dururken bunlardan bahsediyorum ki? Yazılım ile ilgili olarak çalışırken, tasarlarken ya da programlarken sıklıkla, bağlamımızı aşırı soyut tuttuğumuzu ve bu durumun da problemi anlamakta dolayısıyla da doğru düzgün bir çözüm üretmekte bize sıkıntı çıkardığını görüyorum. Eğer problemimizi bir insani durumun sonucu olarak ele alıp, daha anlaşılır bir ifadeyle, problemimizi yeryüzüne indirip, tamamen günlük hayattan figürlerle ifade edemediğimizde, durumu anlamakta ciddi bir sıkıntıya girdiğimizi hatta doğrudan problemi ıskaladığımızı düşünüyorum.

Ne demek istediğimi size bir örnekle açıklayayım: Yazılımla alakalı kavramları ya da teknikleri anlatırken, bu kavram ve teknikleri ne kadar örneğin benimle çevremdeki insanlar arasındaki ilişkiler ya da iyi bilinen bir filmde resmedilmiş ve akılda kalmış sahne cinsinden ifade edebilirsem, insanların beni o kadar rahat anladıklarını görüyorum. Daha anlaşılır şekilde örneğin, sıklıkla tasarım kalıplarını (design patterns) hem anlatma hem de uygulama durumunda kalıyorum, eğitimlerde ya da danışmanlıklarda. Proxy (vekil) tasarım kalıbını ele alalım mesela. Bu kalıbı, tamamen yazılım kavramları üzerinden anlatmaya çalıştığımda, insanların, yazılımcıların yani, anlar gibi görünmelerine rağmen, gerçekte anlamadıklarını farkediyorum. Nasıl anlıyorum bunu? Onlara bir problem verip bunu az önce anlattığım proxy kalıbıyla çözmelerini istediğimde, yazılımcıların yarısından fazlası çözmekte zorlanıyor. Ama aynı kalıbı buradaki örnekte olduğu gibi, başbakan ve vatandaşlar cinsinden anlattığımda ise aynı kişilerin daha başarılı bir şekilde bu çözümü yeni durumlara uygulayabildiklerini farkettim. Bu durum Stroustrup’un şu cümlesiyle daha rahat anlaşılabilir: “Soyut fikirleri pratiğe dökmek zordur. Tecrübeye olan ihtiyacımıza dikkat edilmelidir. Gemi inşa etme, bisiklete binme ve programlama gibi tasarım da sadece teorik çalışmayla elde edilebilecek bir yetkinlik değildir.”

Evet yazılım soyuttur ama neticede bu dünyadandır ve zihnimizin “benzerlikler üzerinden çalışma” yeteneğinden faydalanarak, soyut olan yapıları somut, elle tutulan ve gözle görülenler cinsinden ifade ederek, daha insani boyuta indirgeyebiliriz. Çünkü proxy tasarım kalıbının çözdüğü şey ile bir insanın bir başka insana örneğin bir avukata vekalet vererek çözdüğü aslında aynı şeydir, aynı problemdir. Tıpkı, visitor (ziyaretçi) kalıbının çözdüğü problemin, örneğin bir evdeki kişilerin hepsinin ayrı ayrı terziye giderek ölçü verip elbise diktirmeye kalkmalarının yarattığı enerji kaybı ve bürokrasiyi ortadan kaldırmak amacıyla, terziyi eve çağırmalarıyla aynı olması gibi.

Tüm bu “insani” yaklaşımlar, problemin kendisini anlamaya yönelik çalışmalardır. Yazılımın soyut bir yapıda olması, yazılımı anlamak ve çözümlemek için tamamen soyut yapılardan hareket etmemizi gerektirmez. En azından problemi tanımlayıncaya ve ona her boyutuyla hakim oluncaya kadar, problemi soyut düzlemden somut ve insani düzleme çekebiliriz. Böyle bir yaklaşım bize daha aşina olduğumuz bir zeminde hareket etme kabiliyeti vereceği gibi “Deneme – yanılma, basit olmayan her yazılım projesi için asıldır.” şeklindeki prensipleri, hem yazılıcıların hem de yöneticilerinin anlamalarını sağlayacaktır.

Üstadlardan öğreneceğimiz çok şey var.

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

Seminerler

Java, Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği , , ,

Vemekte olduğum seminerlerle ilgili sayfaya blogumun sağ üstteki bağlantısından ya da buradan ulaşabilirsiniz.

Seminerlerim bedelsiz olup, sunumunu kurumlarda (yazılım şirketleri, BT birimi bulunan kurumlar, dernek vs. bir araya gelinen yerler ile üniversiteler) sağladığı yerlerde yapmaktayım. İTÜ Teknokent yönetiminin desteğiyle ARI-3 konferans salonunda da verdiğim bu seminerleri, buradan da duyuracağim.

Seminerleri hem tanışma, hem teknik sohbet hem de tanıtım amaçlı olarak yapmaktayım. Ben keyif alıyorum ve katılımcılardan öğreniyorum.

Davet edin, geleyim, tanışalım ve keyifli bir sohbet yapalım 🙂

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

Genç Yazılımlılar İçin – II: Master yapmak ya da yapmamak.

Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği , , ,

Çok komik… Aslında traji komik… Bakın anlatayım:

Üniversiteli gençlerle hemen her buluşmamda bana sorulan sorulardan birisi de “hocam master yapalım mı?” oluyor. Çocuklarının kafasını daha lisedeyken “doktora yapma” fikriyle yıkamış bir adama sorulacak soru mu bu? Ya da yaşı 40’nı geçmesine rağmen, bir de Felsefe masterı yapsam diye düşünen bir adamın bu soruya cevabı ne olabilir ki? Dolayısıyla bu soruya, “tabi ki yapın” ya da “sadece master değil doktora da yapmalıyız” şeklinde cevaplar veriyorum. Toplumumuzun eğitim seviyesinin yükselmesi, sektörde bilgi birikiminin olması, herşeyden önce bilgi ve bilgi sevgisi kültürünün yaygınlaşması vb. tonla sebepten dolayı master ve doktora yapmanın önemli olduğuna inanıyorum. Tabi ki bu işin bir vechesi. Diğer vechesi ise o kadar da zevkli değil malesef.

Şöyle bir soru sorsam size: Ülkemizdeki BT sektörünün ihtiyacı açısından, ortalama bir BT çalışanının ne kadar eğitime ihtiyacı vardır? Zor soru tabi. Ama cevap kesinlikle “üniversite lisans eğitimi” değil bence.  Ülkemiz BT sektöründe var olan yerleşik yazılım geliştirme kültürü ve pratiği açısından ele alındığında, benim iddiam şudur: Akıllı bir lise mezunu, var olan işlerin ezici çoğunluğunu, makul miktarda iş başı eğitim ve yol gösterme ile başarabilir. Efendim BT sektöründe çalışanlar zaten liselerden gelen en zeki çocuklardanmış, ÖSS’de ilk bilmem kaça girenler bu sektörde çalışıyorlarmış, yok lisedeyken fizik olimpiyatlarına katılmışlarmış ya da yazılım sektörü çok analitik bir zeka istiyormuş, falan filan… Bence hepsi hikaye. Bunun, heyecanlı Bilgisayar Mühendisliği öğrencilerinin canını sıkacak bir iddia olduğunun farkındayım ama bence durum bu kadar vahim. Bence sadece bizim sektörde değil, pek çok mühendislikte durum bu kadar vahim: İnşaat Mühendisliği ve “bina inşa etme” kültürümüzde de durum pek farklı değil. Ya da bakın, ortalık Endüstri Mühendisliği mezunu dolu ama görüyor musunuz süreç tabanlı bir çalışma? Ben görmüyorum…  Kadın, “Endüsti Mühendisliği mezunuyum ve 10 senedir falan bankada iş analisti olarak çalışıyorum” diye tanıtıyor kendini. Soruyorum, “nasıl iş analizi yapıyorsunuz?” diye. Cevap veriyor “işte, müşterimiz iç müşteri oluyor her zaman. Onlardan istek geliyor. Gidip görüşüyorum onlarla, sonra görüşmeden çıkardıklarımdan bir Word dokümanı oluşturuyorum. Ayrıca PowerPoint’de ekran tasarımı yapıyorum.” “Peki” diyorum içimden ve soruyorum kendi kendime: Burada “analiz” nerede?: PowerPoint ile yapılan şeyin analiz olmadığı kesin çünkü zaten adında “tasarım” var. Geriye kalıyor “Word dokümanı”. Oradan birşeyler çıkarmaya çalışıyorum, çünkü kadının anlatımından “Word dokümanına yazılan şey, iş analizidir” ya da “cümleleri, analitik yapan şey, onların bir Word dokümanına yazılmış olmasıdır” (!) şeklinde birşey çıkıyor. Soruyorum,” o Word dokümanındaki temel kısımlar, başlıklar nelerdir?” Ya da “herhangi bir diyagram çiziyor musunuz” diye, ama nafile. Tek derdim, “iş analisti” olarak çalışan Endüstri Mühendisi arkadaşımızın zihninde “iş” ve “analiz” ile ilgili bir kırıntı var mı onu anlamak. Belli ki iş analisti olarak çalışan herkes kendine göre bir “analitik” 🙂 süreç izliyor.Ve Word dokümanına yazılan şeyler bir şekilde “analiz” oluyor ama dokümanda herhangi bir yapısallık bile yok. Peki söyler misiniz bana böyle bir işi akıllı bir lise mezunu niye yapamasın? Bu işin neresinde analitik bir işlem var? Bu işin postacılıktan ya da sekreterlikten ne farkı var? Postacılıktan farkı yok, çünkü analitik bir katma değer olmadan sadece bilgiyi taşıma söz konusu, herhangi bir çözümleme ve dönüştürme yok. Sekreterlikten farkı yok çünkü Word dokümanına geçiriliyor anlatılanlar. Halbuki, işi soyut olarak bir süreç olarak ifade etme, gerçek olaylardan oluşan senaryolarla, bu soyut süreci kurgulama ve doğrulama, iş kurallarını farklı kriterlerle yakalayıp ifade etme, nesne-merkezli bir yaklaşım söz konusuysa bir kavramsal nesne modeli çıkarma vb. yaklaşım ve tekniklerden bahsetmesi gerekirdi. Literatürde ve pratik uygulamada tonla “iş ve ihtiyaç analizi” (business and requirements analysis) yaklaşımı, tekniği, şablonu (patterns), diyagramları (örneğin UML), en iyi uygulamaları (best practices) vs. var. Var mı uygulayan? Olsa, bir Endüstri Mühendisliği disiplininin sağladığı alt yapıya ihtiyaç olurdu. Ve siz de derdiniz ki “bu işi ancak bir Endüsti Mühendisi” yapabilir.

Tonla iş analistine eğitim verdim, bir tanesinin de zihninde “ihtiyaç tipleri” gibi bir ayırım görmedim. Hatta analiz ile tasarım arasındaki farkı bilene bile pek rastlamadım. Her eğitimde ya da danışmanlıkta Karl Wiegers’ın nefis Software Requirements kitaplarını ebook olarak dağıttım, nefis örneklerinden verdim… Çünkü ihtiyacınızı ya da işinizi analitik olarak ele alıp, çözümlemezseniz, ne istediğinizi ya da nasıl iş yaptığınızı tarif edemiyorsunuz demektir. Bunu yapamadığınızda, hangi yazılımı, hangi en ileri teknoloji ile geliştirdiğinizin hiç bir önemi yoktur. Yazılım projelerinde, ne yapacağınızı bilmediğinizde, ne kadar adam-gün, ne zaman, ne kadar maliyet vb. hiçbir soruya yanılma payıyla bile olsa cevap veremezsiniz. Ne proje planı yapabilirseniz ne de test. Yaparsanız, sadece “yaptım oldu” olur. “Dostlar sizi PMP’lerinizle proje planı yaparken görsün”den öteye gidemezsiniz. İşimizi ve ihtiyacımızı tarif etmeyi bu şekilde algıladığımzıda ne master yapmış bir Endüstri Mühendisi’nin katma değer sağlaması mümkündür ne de bu duruma master sahibi olmak tercih sebebidir.

Aynı durum, yazılım geliştiren programcılar için de geçerli. Tonla Bilgisayar, Endüstri, Matematik vb. mühendisin çalıştığı bir yazılım geliştirme ortamında en temel kavram “ekran” nasıl olur? “Ekran aşağı, ekran yukarı”. Her şey sadece ve sadece ekran ile anlatılıyor. O yukarıda bahsettiğim ünlü Word dokumanını, tamamen ekran tasarımı ve üzerindeki arayüz elemanlarının özelliklerini yazarak oluşturan ve buna “iş analizi” diyen iş analistleri de gördüm bu ülkede ben. Herşeyin ekran üzerinden anlatıldığı bir yerde “iş” ve “analiz” nerede Allah aşkına? En önemli soyutlamanın “ekran” olduğu bir iş ortamının anlamlı olması için orasının, CRT ya da LCD ekran geliştiren bir elektronik vb. bir AR-GE birimi olması gerekmez mi? 🙂 Yazılım gibi tamamen süreç odaklı bir işi, “ekran” kavramı etrafında kurgulamamız için ne kadar eğitim almamız gerekiyor? Bunun için ne kadar Matematik, ne kadar differantial equations, ne kadar operating systems, ne kadar algorithms, ne kadar artificial intelligence öğrenmemiz gerekiyor?

Bakın ilanlara, pek çok ilanda Bilgisayar Mühendisi ile başlanır, sonra Elektronik Mühendisliği vb. mühendislikler sıralanır. Yahu BM’in yapacağı iş için niye EM ya da “ilgili bölümler” gibi ortaya karışık bir şey söylenir? Sebebi şu: Aslında aranılan şey, biraz mürekkep yalamış adam. Ne okuduğu çok da önemli değil. Gerçek bu.

Dolayısıyla “master yapalım mı” sorusunun cevabı yine tamamen kendi içinizde yatıyor. Kimse sizden master yapmış olmanızı beklemez bu ülkede, ama siz kendinizden bekliyorsanız ona saygı duyarım. Dolayısıyla bilgi sizin için önemliyse, master da yapın doktora da. Yok “erken kalkan yol alır” derseniz, bir an önce işe girin, nasıl olsa masterlı olmak çok da fazla bir avantaj sağlamayacak.

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

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

Yazılım Modelleme, Yazılım Mühendisliği , , , , , , , , ,

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ı: 3405

1 2