Bu yazının amacı, nesne yönelimli programlama ortamlarında kullanılan bir tasarım kalıbı (design pattern) olan gözlemci tasarım kalıbını (observer design pattern) açıklamak ve kullanımına dair bir örnek vermektir. Nesne yönelimli olmayan programlama dillerinde (örneğin C) aynı yapı, geri çağırım (callback) ismi verilen yaklaşım ile yapılabilir.

Konuya, klasik bir gözlemci tasarım kalıbını açıklayarak başlayalım. Geliştirme ortamı olarak sıklıkla kullandığım Netbeans içerisinde bir observer pattern eklenmesi halinde aşağıdakine benzer bir sınıf diyagramı (class diagram) görülmektedir:

Yukarıdaki kalıpta görüldüğü üzere 4 temel unsur bu kalıbı oluşturmaktadır:

• ConcreteObserver : Somut bir gözlemci
• ConcreteSubject: Somut bir fail (özne)
• Subject : Somut failden (özneden) türemiş olan diğer failler
• Observer: Somut gözlemciden türemiş olan diğer gözlemciler./

Gözlemci tasarım kalıbı, yukarıdaki şekilde görülebileceği üzere, aslında bir Fail / Meful ilişkisi (subject / object, özne /nesne ) üzerine kuruludur. Somut fail ile kastedilen, gözlemci yapısındaki herhangi bir fiile sebep olan (eylemi yapan) faildir (özne). Buna karşılık, nesne yönelimli programlama dillerinde, üzerine bir fiil uygulanan şey genelde nesne olarak ifade edilir. Yani zaten nesne yönelimli dillerde herhangi bir fiil, sadece nesneler üzerine uygulanmaktadır. Bu durumda fail ile kastedilen, yukarıdaki kalıpta concreteSubject ve bu yapıdan türeyen bütün subject sınıfı nesneler, meful ise bu nesnelerin metotlarına parametre olarak geçirilen ve üzerinde işlem yapılan nesnelerdir.

Bu yaklaşımı bir kod örneği üzerinden açıklamaya çalışalım. Öncelikle tasarımımızın sınıf diyagramını (class diagram) vererek konuya başlayalım:

Yukarıdaki şekilde, modelimizde bulunacak olan üç unsur içinde, yani gözlemci, fail ve meful için birer sınıf tanımı yaptık. Bu sınıfların kodu aşağıda verilmiştir:

İlk olarak gözlemci sınıfı (class) ile konuya başlayalım. Sınıfın tanımında, bir main fonksiyonu bulunuyor ve bu main fonksiyonu aslında fail , meful ve gözlemci kavramlarının bir araya geldiği nokta oluyor. Zaten sınıf diyagramında da görüleceği üzere gözlemci bu iki kavramı bir araya getirir. Buna göre fail ve meful sınıflarından üretilen failNesne ve mefulNesne nesneleri (objects) (kodun 20. ve 23. satırlarında), kodun 26. satırında, addObserver fonksiyonu ile birbirine bağlanmıştır. Bu basit işlem, meful üzerinde bir failin gözlemini tanımlar. Ayrıca kodun 29. satırında klasik thread üretmek için kullanılan ve Runnable arayüzü üzerinden Thread çağırımı ile failNesne’mizi bir thread şeklinde başlatıyoruz.

Gelelim Fail sınıfının tanımına:

Yukarıdaki kodda, basit bir şekilde, kulanıcıdan, ekranda yazı okumak için BufferedReader, InputStreamReader’a ve InputStreamReader da System.in’e bağlanmış. Bu sayede, System.in üzerinden girilen bir veri, BufferedReader tarafından okunabilecektir. response ismindeki String değişkeni (variable) bir sonsuz döngü içerisinde (21. satırdaki while) kullanıcıdan veri okumakta ve sırasıyla setChanged() ve notifyObservers() fonksiyonlarını çağırmaktadır. Buradaki notifyObservers fonksiyonu aslında bütün bu yazının kalbini oluşturuyoru. Dikkat edilirse bu fonkisyona klavyeden okuduğumuz response isimli değişkeni parametre olarak veriyoruz.

Kodda dikkat edilecek diğer iki husus ise, Observable sınıfını miras almamız (inheritance) ve bir thread olarak çalışmasını istediğimiz için Runnable arayüzünü (interface) implements etmemizdir.

Son olarak meful sınıfını açıklayıp, kodun çalışmasına bakalım:

Kodda görüldüğü üzere, Meful isimli sınıfımız, basitçe Observer arayüzünü kendi üzerine uygulamıştır (implements).

Meful sınıfının yegane fonksiyonu update fonksiyonudur ve parametre olarak bir Observable nesnesi bir de arg isimli Object tipinde (yani JAVA açısından tipsiz) bir parametre almaktadır.

Burada tipsiz tipler ile ilgili aşağıdaki yazıyı okumakta yarar olabilir

Son olarak update fonksiyonu içerisinde alınan mesaj, tip inkılabı (typecasting) ile Object tipinden String tipine inkılap ettirilmiş ve ardından ekrana basılmıştır.

Şimdi yukarıdaki senaryoyu toparlayacak olursak, gözlemci sınıfımızdaki main fonksiyonu çalıştırılarak bütün senaryo başlamaktadır. Bu main fonksiyonu içerisinde bir fail bir de meful nesnesi üretilmekte ve üretilen nesneler birbirine addObserver fonksiyonu ile bağlanmaktadır. Yani artık meful sınıfından türeyen nesneler, fail sınıfının birer observer’ı olmaktadır. Ardından fail sınıfından üretilen nesne bir thread olarak çalıştırılmakta ve kendi içerisinde bulundurduğu, ve threadlerin ilk çalışan fonksiyonu olan run() fonksiyonunda tanımlı olan kullanıcıdan bir dizgi (String) okuma işlemini gerçekletirmektedir. Hemen ardından okunan mesajı, aslında hiçbir fikri olmayan ismini, ne tür bir parametre aldığını dahi bilmediği notifyObservers () fonksiyonuna parametre geçirmektedir. Bu fonksiyon, bir sevki tabii olarak meful sınıfındaki update isimli fonksiyonu tetiklemektedir. Update fonksiyonu ise kendisine parametre olarak gelen nesneyi String sınıfına çevirmekte ve ekrana bamaktadır.

Yukarıdaki kodu çalışması sonucu ekran görüntüsü aşağıdaki şekildedir:

Görüldüğü üzere kodumuz bir fiil sorusu sormakta ve klavyeden benim yazdığım “merhaba” yazısını ekrana geri basmaktadır. Buradaki mesajı okuyan fail isimli sınıftan türeyen nesne iken, ekrana cevabı yazan meful isimli sınıftan türeyen nesnedir

Yukarıdaki bu tasarım kalıbını, daha gerçekçi bir örnek üzerinden açıklamaya çalışalım.

Örneğin bir müzayede (açık arttırma) ortamını, gözlemci tasarım kalıbı ile modellemek isteyelim. Buna göre müzayedeyi yöneten bir kişi ve bu müzayedeye katılan müzayedeciler bulunacaktır. Buna göre müzayedeyi yöneten kişi bir gözlemci olmakta, müzayedecilerin her biri birer fail (fiili yapan kişi) olmakta ve müzeyede sırasında verilen her teklif (fiyat) bir meful (fiilin etkisindeki değer) olmaktadır.

Bu yaklaşımı aşağıdaki şekilde göstermeye çalışalım:

Yukarıdaki yaklaşımda, muzayede sırasında verilen değerler, gözlemcinin update fonksiyonuna birer parametre olarak geçirilmekte ve nihayetinde gözlemciden bağımsız olarak ilgili fonksiyonlar çağrılmaktadır.

Gözlemci tipi tasarım kalıbının bir dezavantajı, bu noktada çıkmaktadır. Gözlemci tasarım kalıbında, meful yapısında olan ve fiilden etkilenen nesnelerin sistemde etkin rol oynaması beklenir. Diğer bir deyişle, açık arttırmaya katılan her bir katılımcı, fail olarak fiyatlarını belirtirken, gözlemci bu durumu sadece gözlemekte ve bir fiilde bulunmamakta ancak fiileri gözlemektedir. Bu anlamda, gözlemci tasarım kalıbı, çekme iletişim modeli (pull interaction model) olarak düşünülebilir. Alternatifi olan itme iletişim modelleri (push interaction model) failin doğrudan eylemde bulunması ile sonuca ulaşmakta ve dışarıdaki nesneleri çalışmaya zorlamaktadır. Yani gözlemci örüntü modelinde, dışarıda bulunan nesnelerin çalışmaları sonuçları toplanmaktayken, itme iletişim modeli olan diğer kalıplarda, bir nesne, diğer nesnelerin sonuç üretmesini zorlayabilir. Burada, tasarıma bağlı olarak bir seçim yapmak gerekir.

335 views

Bu yazının amacı, bilgisayar dünyasında kullanılan döküman yönetim sistemlerinin genel bir tanımını yapmak ve bir doküman yönetim sisteminin yapısını açıklamaktır.

Genel olarak bir doküman yönetim sistemi (document management system), herhangi bir organizasyondaki dokümanların (yazışmalar, evraklar, formlar veya resimler gibi) takibini yapmayı, tasnif ederek erişimini kolay hale getirmeyi, sorgulamalara ve aramalara cevap vermeyi hedefler.

Daha büyük ölçekte, içerik yönetim sisteminin bir parçası olarak görülebilir.

Bir doküman yönetim sisteminde, şart olmamakla birlikte genelde aşağıdaki öğeler bulunur:

Üst bilgi (Metadata): Bir dokümanın, doğrudan içeriğine ait olmayan ancak dokümanın algılanması ve kullanılması sırasında işe yarayan bilgilerdir. Örneğin bir resmin çekildiği tarih, veya sisteme kaydedildiği tarih, dokümanın üst bilgisidir ancak bu bilgi resmin içnde yer almak zorunda değildir.

Havuz (repository): Doküman yönetim sistemlerinde (document management systems) kullanılan ve dokümanların saklandığı alandır. Basitçe havuza nasıl erişileceği, kimlerin ne kadarına erişeceği veya dokümanların havuzda nasıl tutulacağı, doküman yönetim sistemi tarafından belirlenir. Örneğin dokümanların doğru bir veri tabanı yönetim sistemi tarafından (database management system , DBMS) nasıl kullanılacağı bir havuz problemidir.

Bütünleşme (Integration): Dokümanlar ile uygulamalar arasındaki ilişkidir. Örneğin bir kullanıcı bilgisayarında tuttuğu hesaplama tablolarını bir uygulama üzerinden kullanmaktayken (örneğin MS Excel veya Open Office Calc gibi) bu veriler doküman yönetim sisteminin havuzunda durmaktadır. Kullanıcı şeffaf bir doküman yönetim sisteminde (transparent) sadece uygulama ile muhatap olurken, doküman yönetim sistemi, arka planda kullanıcının verileri ile uygulamayı bütünleştirmektedir.

Fihristleyici (Indexer): Dokümanların kolay erişilmesi için belirli bir fihrist yapısına oturtulmasını sağlayan programdır. Örneğin dokümanların ağaç yapısında (tree) veya özetleme tablolarında (hash table) tutulması, arama sırasında, daha hızlı erişilmesini sağlar. İşte fihristleyici bu görevi üstlenerek uygun veri yapısı üzerinde (data structure) dokümanlara erişim sağlamaktadır.

Getirme (Retrieval): Dokümanın havuzdan getirilmesi işlemidir. Çeşitli sistemlerde oldukça karmaşık yapılara ulaşabilir. Örneğin internet üzerinde arama yapan bir motorun (örneğin google) desteklediği arama cümlelerini kabul eden bir doküman yönetim sisteminin, fihristleyici üzerinde doğru erişimleri yapması ve getirmesi, normalden daha karmaşık algoritmalar gerektirmektedir. Hatta günümüzde doğal dil işleme (natural language processing) kullanılarak, kullanıcıların konuşur gibi, sistemden doküman aramaları ve doküman yönetim sisteminin (DMS) bu dokümanı bulup getirmesi mümkün hale gelmiştir. Ayrıca getirilen sonuçların kullanıcıya gösterilmesi sırasındaki sıralama da ayrıca önem taşımaktadır. Örneğin 100 adet doküman döndüren bir aramanın sonucunda hangi dokümanın ilk sırada gösterileceği, skorlama algoritmaları ile çözülmektedir ve bütün bu işlemler “getirme” (retrieval) olarak geçmektedir.

Dağıtım (Distribution):Bu terim aslında literatürde bilgisayar bilimi temelli kişiler için bir karmaşıklık oluşturmaktadır. Literatürde iki farklı anlamda kullanıldığı görülebilir. Birincisi çok yoğun ve yüksek miktarda verilerin saklandığı ortamlarda, kaynakların verimli kullanılması için dokümanların dağıtılmasıdır. Bu klasik bilgisayar bilimleri tanımı olup tamamen yük kaygısı ile performans arttırma amaçlı yapılan bir işlemdir. Örneğin bir bankanın her şubesinin kendi dokümanını, kendi şubesinde tutması ve verilere erişimde hız kazanması gibi. Öte yandan doküman yönetim sistemlerinde bir dokümanın, taraflar arasında dağıtılması da bir problemdir. Örneğin hukuki bir metni, bütün muhataplarının okumuş olduğunun garanti edilmesi, hatta dijital olarak imzalaması (tebliğ / tebellüğ edilmesi) bir sözleşmenin bütün ilgili ve sadece ilgili kişiler tarafından okunması gibi problemler de dağıtım başlığı altında geçmekte olup bazı doküman yönetim sistemlerinde desteklenen özelliklerdendir.

Güvenlik (Security): Doküman yönetim sistemindeki kullanıcıların kendi yetkileri (authentication) çerçevesinde erişime sahip olması ve dokümanların tam olarak korunuyor olmasıdır.

İş akışı (workflow): Bir dokümanın izlemesi gereken yolları belirtir. Örneğin bir satış işlemi sırasında, önce satış sözleşmesinin taraflarca onaylanması, satıcı tarafın deposuna sevk emrinin geçirilmesi, depodan çıkan ürünlerin taşıyıcı firma tarafından onayı, aradaki sigorta evraklarının tanzimi, alıcı firma tarafından malların alındığını onaylayan dokümanlar ve nihayetinde para transferini onaylayan banka dokümanlarının tamamı doküman yönetim sistemi tarafından takip edilip doğru sıra ile, doğru taraflar tarafından, evrak atlanmadan yapılmış mı diye sorgulanabilir. Elektronik doküman yönetim sistemleri (electronic document management system), bu kontrol işlemlerinin tamamının otomatik olarak yapılmasını ve ilgili kullanıcılara raporlanmasını hedefler.

Sürümleme (Versioning) : Bir doküman üzerinde değişik zamanlarda yapılan çalışmaların takip edilmesini hedefler. Örneğin dokümanda yapılan her işlem yeni bir sürüm numarası ile saklanır ve kullanıcılar gerekli gördükleri durumlarda, eski sürümlere dönerek işlem yapabilir.

Yayınlama (Publishing): Dokümanın tam olarak doğru algılanmasını sağlamak amacıyla, doküman üzerinde, yanlış anlamalara mahal verebilecek bütün eksiklik ve hataların düzeltilmes, tahsis edilmesi ve redaksiyonu işlemidir. Yayına hazırlanan bir dokümanın standartlarının belirlenmesinde ayrıca dokümanlar kullanılmaktadır.

312 views

Bilgisayar kodlamasında, bir kodun okunabilirliğinin düşük olması, yani kod takibinin zor olması durumunda, koda verilen isimdir.

Genellikle yapısal programlama dillerinde (structured programming languages) fonksiyonların bulunması ile birlikte GOTO veya JMP gibi, kodun içerisinde bir yerden başka bir yere atlayan komutların kaldırılması mümkündür.

Bu tip komutların kullanılması durumunda, kodun hem diğer programcılar tarafından okunabilirliği düşer, hem de kodun karmaşıklığı kestirilemez bir hâle gelebilir.

Spagetti kodu engellemek için 3 temel adım kullanılır:

1. Kodda bulunan ve koşula bağlanması istenen satırlar için if bloğu kullanılır
2. Kodda bulunan ve tekrarlanması istenen satırlar için döngü kullanılır
3. Kodda bulunan ve parametrize edilmesi istenen satırlar için (aynı satırların farklı değerlerle çalışması isteniyorsa) fonksiyon kullanılır.

Yukarıdaki bu üç adım tamamlandıktan sonra kodda herhangi bir GOTO satırı kalmamalıdır.

Ayrıca spagetti kodundan esinlenerek katmanlı mimarinin kullanıldığı ve projelerin birden fazla seviyeye bölünerek ele alındığı yaklaşımlara lazanya kod (lasagna code) ; veya özellikle nesne yönelimli programlama dillerinde (object oriented programming languages), program parçalarının birbiri ile olan ilişkisinin asgariye indirildiği ve neredeyse her parçacığın tek başına varlığını sürdürebildiği kodlama yaklaşımlarına da ravioli kod (ravioli code) isimleri verilmektedir.

197 views

Bu yazının amacı, geliştirme ortamlarında kullanılan kodlama standartları için örnek bir doküman oluşturmaktır. Kodlama standardı, daha sonradan yapılacak olan bakım, güncelleme ve ekleme işlemlerinin kolaylaşmasını sağlarken, dokümantasyon ve projeye dahil olan yeni personelin adaptasyonunu hızlandıracaktır. Kurallar, aşağıdaki başlıklar halinde sunulmuştur.

Karakter Kodlaması

Kod geliştirilmesi sırasında, kullanılan isimlerin hiçbirisinde Türkçe karakter tercih edilmemelidir. Kullanılan isimlerin, fonksiyon veya sınıfı tanımlar nitelikte olması ve ayrıca kodun içerisinde yorum satırı şeklinde içeriğine dair bilgi vermesi beklenir.

Deve İsimlendirmesi (Camel Notation)

Bu yazım türünde, birden fazla kelimeden oluşan isimlerin, her kelimesinin ilk harfi büyük diğer harfleri küçük olarak yazılır.

Örnek

DenemeBasligi

Sınıf isimleri

Bütün sınıf isimleri büyük harflerden oluşan bir ön ek alır. Bu ön ek, BoonEX projesi kapsamında yazılması durumunda BX’tir. Bunun dışında, özel bir proje için eklenen sınıflar, projeyi belirten ön ekler alır. Örneğin öğrenci portalı şeklindeki bir proje için OP ön eki eklenebilir. Ayrıca sınıf isimleri yegane olmalıdır (unique) ve deve isimlendirilmesi kullanılmalıdır.

Örnek

OPDenemeSınıfı

Değişken Tanımlama

Bütün değişken isimleri, küçük harf ile başlamalıdır. Ayrıca değişkenin tipine dair bir ön ek almalıdır. PHP dilinde mevcut bulunan değişken tipleri ve bu değişken tiplerine göre eklenebilecek ön ekler aşağıda listelenmiştir.

• i Integer
  
• f Float, Double
  
• s String
  
• a Array
  
• r Resource
  
• b Boolean
  
• is Boolean
  

Örnek:

$sIsim = “Variable Value”;

$iSayi = 0; $iSayi++;

$rPrjDosya = fopen (“dosya.txt”, “r”);

var $isYaz;

Fonksiyon Tanımları

Fonksiyon isimleri, değişken tanımına uymalıdır. Fonksiyonların küme parantezleri, fonksiyonun tanımlandığı satırın sonunda açılmalıdır.

All Function Names should start with a lower case letter, and each word should begin with a capital letter. Curly braces used in the list of parameters must be given on a new line instead of following the brackets.

Örnek:

function denemeFonksiyonu($iSayi, $sIsim){

//kod

}

Yapısal Dil Formatları

PHP diline özgü blok kodları (for, while, do.. while, foreach, if…else gibi), aşağıdaki kurallara uymalıdır.

Language structures such as if … else, for, foreach, while, etc. must be presented in the following manner:

• Bu blokların, parantez ile blok kelimesi arasında bir boşluk olmalıdır.
  
• Blok parantezleri, satır sonunda başlamalıdır.
  
• İşlem kullanılması durumunda, işlem ile operantlar arasında boşluk bulunmalıdır
  

Örnek:

foreach ($aIsimler as $sAnahtar => $sDeger){

//Kod

}

switch yapısı

Bu yapı, kod okunabilirliği açısından kullanılmayacaktır. Bunun yerine if / else blokları kullanılacaktır.

Kod Ekleme Standartları

Kod eklemesi yapılırken, eklemenin ismi, kim tarafından eklendiği ve hangi proje kapsamında yapıldığı yorum satırı olarak kodun başına ve sonuna yazılır.

Örnek:

//Ekleme ismi, kodlayan, proje ismi.//

Kod();

//[Bitti] Ekleme ismi//

Ekleme işlemi yapılmadan önce, orijinal dosyanın yedeği alınmalı ve ekleme işlemi, kopya dosya üzerinde yapılarak orijinal kod saklanmalıdır.

Database Tables

Veri tabanından dosya oluşturulması gerektiği durumlarda, proje ismi ve eklenen modül ismi ön ek olarak konulmalıdır.

Örnek

OPModIsmi_Kullanicilar

229 views

Zeki vekiller (etmenler, ajanlar) kavram olarak, bilgisayar bilimlerine, felsefe, biyoloji ve ekonomi alanındaki çalışmalardan sonra girmiştir. Bu alanlardaki anlamı ve kullanımı, genellikle herhangi bir işin farklı bir vekil tarafından yürütülmesi olarak anlaşılabilir.

Bilgisayar bilimlerin açısından zeki kelimesi, bir vekilin herhangi bir işlemi belirli inisiyatifler kullanarak yerine getirmesidir. Örneğin zeki olmayan bir vekil, her adımda ve her işlemde kullanıcıya bir şeyler sorarken, zeki vekilde daha çok otonom bir yapıdan (autonomous) bahsedilebilir.

Bu anlamda her zeki vekilin (intelligent agent) , çalıştığı ortam ile iletişimini sağladığı ve bu iletişim üzerinde karar verdiği bir mekanizması vardır denilebilir.

Yukarıdaki temsili resimde, bir zeki vekil, çizgili alanda gösterilen üç ana unsurdan ibarettir. Bunlar kısaca vekilin çalıştığı ortamı gözlediği algı (perception) , vekilin bu ortamda bir işlem yapmasını sağlayan eylem (action) ve vekilin bu ortamdaki algısına göre nasıl bir eylem yapacağına karar vermesini sağlayan karar mekanizmasıdır. Bu karar mekanizması çoğu zaman bir kurallar listesi (rule base) olabileceği gibi bazı durumlarda basit bir if – else bloğu da olabilmektedir.

Russel ve Norving tarafından 2003 yılında yayınlanan yapay zeka kitabında, zeki vekiller 5 seviyede listelenmiştir. Bu seviyeleri basitten karmaşığa doğru aşağıdaki şekilde sıralayabiliriz:

1. Fiil-i Münakıs Vekiller (reflex agents)
2. Fiil-i Münakıs Kalıp Vekiller (Model-based reflex agents)
3. Hedef vekilleri ( goal-based agents)
4. Fayda vekilleri ( utility-based agents)
5. Öğrenen vekiller ( learning agents)

Reflex Agents

Basit bir koşul ve eylem sıralamasından ibaret olan vekiller. Belirlenen koşul gerçekleşince yine daha önceden belirlenen fiili yerine getirir. Kurulu bir düzenek olarak düşünülebilir. Örneğin fare kapanı, bir insan için fareyi yakalayan bir vekildir ve farenin peyniri yemesiyle birlikte fareyi yakalar. Buradaki peynir yenmesi koşul ve farenin yakalanması fiil olarak düşünülebilir. Bazı refleks ajanlarında durum takibi de yapılabilir. Örneğin fare kapanı misalinde olduğu gibi kapanın kurulu olma durumu, kapanın fareyi yakalamış olma durumu gibi durumlar ayrı ayrı tahlil edilebilir.

Model Bazlı Refleks etkenler

Bu tip ajanlarda (etkenlerde) ise içinde çalışılan ortam modellenir. Yani ajan kendi yapısına göre ortamı anlamaya ve bir modelini kendi hafızasında tutmaya çalışır. Bu ajanlar modeldeki durumlara göre davranış sergilerler. Yani bir önceki tipte olan refleks ajanlarının ortamdan aldıkları doğrudan koşullarından farklı olarak bu ajanların modellerinde bazı refleksler tanımlıdır.

Hedef Güdümlü Vekiller

Bu vekiller ise belirli bir hedefe ulaşmak için bir dizi şart-fiil gerçekleştirirler. Basit bir durum-geçiş diyagramı (state transition diagram) olarak düşünülebilecek yapılarına göre, ortamı algılayarak mevcut yapılarındaki bir duruma benzetir ve bu durumu ulaşmak istedikleri hedefe en uygun şekilde eylemlerle değiştirmeye çalışır.

Çıkar Amaçlı Vekiller

Hedef amaçlı vekillerden farklı olarak, durumlar arasındaki geçişin oransal olması durumudur. Yani hedef güdümlü ajanlarda bir durumdan her zaman diğer duruma geçiş hedeflenir. Çıkar amaçlı vekillerde bundan farklı olarak oransal bir fonksiyon kullanılması söz konusudur. Bu fonksiyona çıkar fonksiyonu ( fayda fonksiyonu, utility function) ismi verilir.

Öğrenen Etkenler

Bu etken tipinde, ortamda yapılan bazı eylemlerin beklenen sonuca nasıl hizmet ettiğine göre yeni kurallar tanımlanır. Ajanın çalıştığı ortamın bilinmemesi halinde kullanılışlıdırlar. Kendi kurallarını ve durum makinelerini oluşturabilir veya değiştirebilirler.

296 views

Bilgisayar bilimlerinde özellikle yazılım mühendisliği (Software engineering) konusunda kullanılan ve bileşen (component) ve mesaj (message) temelli yazılım geliştirmeyi amaçlayan bir üsluptur.

C2 tasarım kültüründe yazılım bileşenler şeklinde ele alınır ve yazılımı oluşturan bu bileşenler üzerinden bir ağ (network) çizilir. Bu ağda bileşenler arası haberleşme gösterilir. Bu sayede tasarlanan bir bileşenin daha verimli ve tekrar tekrar kullanılması mümkün olmuş olur.

1996 yılında bu yaklaşımı ilk kez ortaya koyan Nenad Medvidovic, Peyman Oreizy, Jason E. Robbins, ve Richard N. Taylor, “Using Object-Oriented Typing to Support Architectural Design in the C2 Style (C2 stili ile nesne yönelimli ve destek mimarili tasarım)” isimli makalelerinde bu nesneler arası ilişkiyi aşağıdaki şekille temsil etmişlerdir:

Yukarıdaki şekilde görüleceği üzere her bileşen C harfi ile temsil edilmiş ve bağlar birer çizgiyle gösterilmiştir. Ayrıca kalın çizgiler ana bağlantı noktalarını göstermektedir.

Bu yazı şadi evren şeker tarafından yazılmış ve bilgisayarkavramlari.com sitesinde yayınlanmıştır. Bu içeriğin kopyalanması veya farklı bir sitede yayınlanması hırsızlıktır ve telif hakları yasası gereği suçtur.

Yine aynı makalede bulunan bir C2 bileşeninin iç yapısını aşağıdaki şekilde Türkçe terminoloji ile gösterebiliriz:

Yukarıdaki şekilde anlatılmak istenen bir nesnenin bir kılıf içerisinde ele alındığıdır. Yani C2 tasarımında bileşen olarak görülen herşey aslında nesne yönelimli programlamada bir nesne(object) ile karşılanır ancak bu nesneye bir kılıf giydirilmiş olarak kabul edilebilir. Nesne ile iletişim ayrıca bir arayüz ile yaıpılırken nesnenin dışarıya doğrudan erişimi bulunmaktadır. Bu durum kılıftan çıkan ve talepler (request) yönünde olan bir ok ile temsil edilmiştir.

Doğrudan kılıf (wrapper) dışına erişim yapabilen nesnenin yanında bütün uyarılar (notifications) iletişim ve kısıtlama nesnesi üzerinden iç nesneye erişebilmektedir. Aslında tasarım olaran nesne yönelimli programlamanın kapsülleme (encapsulation) mantığına oldukça yakın olan bu durumda, ayrıca nesnelerin hepsinin kendi adreslerinde çalıştıklarını düşünebiliriz. Kendi adres alanlarında (own address space) çalışan nesneler değişken paylaşımı (Shared variable) korunmuş olacağı için, çok kullanıcılı (multiuser) , çok işlemli (multiprocessing/threading) ve eşzamanlı (concurrent) modellemeleri desteklemektedir.

60 views

JML ingilizce Java modelling language kelimelerinin baş harflerinden oluşan bir kısaltmadır. Basitçe bir java kaynak koduna eklenen ilave satırlar ile progam doğruluğunu (program correctness) sağlamayı amaçlar (program verification).

İlave olarak eklenecek satırlar java kodunun içerisine yorum satırı gibi ilave edilir. Normal java yorum satırlarından tek farkı ilave olarak konulan @ işaretidir.

Örneğin

//@ örnek jml satırı

veya

/*@ örnek

çoklu jml

satırı @*/

şeklinde java koduna ilave edilebilirler.

Aslında bütün jml komutlarını basit üç grupta toplamak mümkündür:

1. Önkoşullar (preconditions)
2. Sonkoşullar (postconditions)
3. Değişmezler (invariants)

Yukarıdaki bu üç grubtan ilk ikisi hoare mantığındaki ön ve son koşullara benzetilebilir. Üçüncü grup ise döngülere özgü kullanılan bir koşuldur. Bu gruplardaki komutları ve kullanımlarını aşağıdaki örneklerden inceleyelim:

static void arraycopy (int[] src, int srcPos,int[] dest, int destPos,int len);

Örnek olarak yukarıdaki dizi (array) kopyalama fonksiyonunu ele alalım. Burada amaç, src dizisinden dest dizisine derin kopyalama yapmaktır. (deep copy). Ancak bu satırda yaşanabilecek bazı programlar aşağıdaki şekildedir:

• src dizisi null olabilir
• dest dizisi null olabilir
• src dizisinin izin verilen eleman sayısının dışına programcı tarafından çıkılabilir (örneğin 10 elemanlı bir dizinin 10. elemanına erişilebilir (java terminolojisi olarak arrayindexoutofboundsexception olabilir))
• dest dizisinin izin verilen eleman sayısının dışına programcı tarafından çıkılabilir.

Bu yazı şadi evren şeker tarafından yazılmış ve bilgisayarkavramlari.com sitesinde yayınlanmıştır. Bu içeriğin kopyalanması veya farklı bir sitede yayınlanması hırsızlıktır ve telif hakları yasası gereği suçtur.

Yukarıdaki bu olası problemleri çözmek için fonksiyonu yazarken başına ilave olarak bu requires komutu ile ön koşullarımızı ekliyoruz.

/*@ requires src != null && dest != null &&
0 <= srcPos && srcPos + len < src.length &&
0 <= destPos && srcPos + len < dest.length;
@*/
static void arraycopy (int[] src, int srcPos,int[] dest, int destPos,int len);

Yukarıdaki yeni kodda ilave olarak src ve dest’in null olamayacakları ve kopyalama sırasında kullanılan indis değişkeni olan srcPos’un 0 ile src.length ve dest.length arasında olacağı belirtilmiştir.

Yukarıdaki ön koşula ilave olarak diğer bir isteğimiz fonksiyon çalıştıktan sonra src ile dest dizilerinin elemanlarının birebir aynı olmalarıdır. Bu son koşulu (postcondition) kontrol etmek için ilave bir jml satırı daha eklememiz gerekir:

/*@ requires src != null && dest != null &&
0 <= srcPos && srcPos + len < src.length &&
0 <= destPos && srcPos + len < dest.length;
ensures (\forall int i; 0 <= i && i < len;dest[dstPos+i] == src[srcPos+i] )
@*/
static void arraycopy (int[] src, int srcPos,int[] dest, int destPos,int len);

Yukarıdaki yeni jml satırı olan ensures ile son koşul kontrolü yapılıyor.  Burada yeni kullanılan \forall döngüsü sayesinde 0′dan len değişkenine kadar olan değerler için (döngü değişkeni i olarak) bütün dizi içeriği karşılaştırılıyor ve ancak aynıysa son koşul sağlanmış oluyor.

129 views

Bilgisayar bilimlerinde bir programın istenen özellikleri yerine getirip getirememesine verilen isimdir. Buna göre şayet bir program, beklenen özellikleri tam ve eksiksiz yerine getiriyor, istenmeyen sonuçlar ortaya çıkmıyor ve program başladıktan sonra her durumda başarılı bir şekilde bitiyorsa bu programa tam doğru ( total correctness) ismi verilir.

Durma probeleminden (halting problem) bilindiği üzere bir programın bitip bitmemesinin test edilmesi ayrı bir muammadır. Dolayısıyla tam doğru bir programın elde edilmesi veya ispatlanması farklı güçlükleri beraberinde getirir. Şayet bir program, kendinden beklenen özellikleri başarılı bir şekilde yerine getiriyor ancak bitip bitmemeyi garanti edemiyorsa (bir programın biteceği ispatlanamıyorsa) bu durumda programa kısmi doğru (partial correctness) ismi verilir.

Aslında programların doğruluğu (correctness), karar problemlerinin (decision problems) çözülmesidir.

Tam bu noktada bilgisayar bilimleri konusunda veciz sözleri ile konuya aydınlık getiren Dijkstranın bir sözünü hatırlamakta yarar var. “Testler hataların varlığını gösterebilir ama yokluğunu gösteremez.”

Bu yazı şadi evren şeker tarafından yazılmış ve bilgisayarkavramlari.com sitesinde yayınlanmıştır. Bu içeriğin kopyalanması veya farklı bir sitede yayınlanması hırsızlıktır ve telif hakları yasası gereği suçtur.

Örneğin doğal sayılar kümesi üzerinde sayıların asal olup olmadığını test eden bir program yazdığımızı düşünelim. Bu program basitçe bir sayıyı alacak ve sayının çarpanlarını bulacaktır. Şayet sayının kendisi ve 1 dışında başka çarpanı yoksa bu sayıyı asal sayı ilan edecektir. Bu şekilde bir program yazmamızda herhangi bir sorun yoktur ancak programın biteceğini garanti edemeyiz. Elbette buradaki problem doğal sayıların bir sonu olup olmadığıdır. Yani program bütün asal doğal sayıları bulmaya çalışırsa sonsuz sayıda işlem yapması gerekir (ya da sonsuz bilinen bir değerse sonlu sayıda). Bu noktada bilgisayarın hafıza gibi kısıtları devreye girer. Yani sonsuz sayı işleyecek bir hafıza kapasitesi henüz bilgisayarlarda bulunmamaktadır.

Bu ispat sırasında programın bir lambda cebirine (lambda calculus) çevrilmesi ve bu cebirde doğruluğunun ispatlanması mümkündür. Bu tip ispat yöntemlerine program çıkarımı (program extraction) ismi verilir. Örneğin Curry Howard karşılığı (curry howard correspondence) yaklaşımı buna bir örnek olarak gösterilebilir.

Bir programın doğruluğunun tetkikine, program tetkiki (program verification) ismi verilir.

Program doğrulamanın kullanıldığı yerler

Program doğrulama, bir programın geliştirilme sürecinde, son adım olan test aşamasına gelinmeden hataların bulunması ve programın kodlanma hatta tasarım aşamasında hatalarının yakalanmasını sağladığı için oldukça önemlidir. Örneğin bitmiş bir programdaki bir hatanın test ile bulunması bütün tasarım ve kodlama adımlarına geri dönülmesini ve dolayısıyla hatanın telafisi için harcanan maliyetin yüksek olmasını sağlarken, daha henüz kodlama aşamsında hatanın tespiti maliyeti düşürmektedir.

Ayrıca yazılan programın hatasının test aşamasında hiçbir zaman bulunamaması da söz konusu olabilir. Bu ihtimale karşı programın matematiksel olarak doğruluğunun ispatlanması çok önemlidir.

92 views

Çok klasik bir mühendislik yaklaşımıdır. Bu yaklaşım sistemi analiz ederken sistemin içeriğin görmezden gelerek sisteme girenler ve çıkanların analiz edilmesini söyler.

Yukarıdaki temsili resimde gösterildiği üzere, tahlil edilen sistem bir kara kutya benzetilerek sisteme giren ve çıkanlar incelenir.

Bu anlamda yazılım mühendisliğinde sıklıkla kullanılan kara kutu yaklaşımında sistem önce büyük bir kara kutu olarak düşünülüp ardından alt kutulara bölünebilir:

Sistemde bulunan her kutu kendi başına incelenip ardından sistemin tamamının incelenmesi mümkündür. Buradaki her kutuyu ayrı bir sistem gibi düşünmek ve ardından bu sistemlerin birbiri ile olan bağlantısını düşünmek mümkündür.

Örneğin yazılım testlerinde her alt sistem ayrı ayrı test edilip (unity test) ardından bu alt sistmlerin birbiri ile olan uyumu ayrıca test edilebilir (integrity test).

Yazılım mühendisliğinde ayrıca giriş işlem çıkış (input process output) kelimelerinin baş harflerinden oluşan IPO terimi de tam bir kara kutu (black box) yaklaşımıdır.

IPO modellemesinin biraz daha gelişmiş hali olarak kabul edilebilecek olan HIPO (hierarchy input process output veya bazı kaynaklarda hierarchy plus input process output yada hierearchical input process output olarak da geçmektedir) yaklaşımında ise sisteme hiyerarşik bir yapı kazandırılmaktadır. Yani sistemde bulunan kara kutular arasında hiyerarşik bir yapı oluşturulabilir.

Bu yazı şadi evren şeker tarafından yazılmış ve bilgisayarkavramlari.com sitesinde yayınlanmıştır. Bu içeriğin kopyalanması veya farklı bir sitede yayınlanması hırsızlıktır ve telif hakları yasası gereği suçtur.

Aşağıda bir hiyerarşi grafiği örneği ile konuyu açıklamaya çalışalım:

Yukarıdaki hiyerarşi grafiğinde çeşitli hiyerarşik seviyedeki varlıklar modellenmiştir. Buna göre örneğin en altta bulunan analiz bölümü genel müdürlük altında bir bölümdür ancak arada iki seviye bulunmaktadır.

Yazılım modellemsinde bu hiyerarşik yapılanmadan faydalanılabilir. Örneğin bir yazılımı alt sistemlere bölerken seviye seviye bölümlemeye gidilebilir.

Bu durumu internette rast gele bulduğum bir yemek tarifi üzerinden anlatmaya çalışayım.  Yemektarifi.com sitesinde Ispanaklı kiş isminde bir yemek aşağıdaki şekilde anlatılmış:

Malzemeler:

1 Kg ıspanak
500 Gr mantar
200 Gr dilimlenmiş kaşar peyniri
500 Gr rendelenmiş havuç
2 Çay kaşığı tuz
2 Çorba kaşığı kekik
5 Yaprak Miflöy hamuru
2 Çorba kaşığı süt
1 Yumurta
Sos İçin:
2 Su bardağı süt
4 Çorba kaşığı un
2 Soğan
4 Kahve fincanı margarin

Hazırlanışı:

• Ispanakları yıkayıp az haşlayın.
• Kevgirle süzüp bekletin.
• Mantarı ince ince doğrayarak az haşlayın.
• Haşladığınız ıspanakları doğrayıp mantarla karıştırın.
• Tuz ve kekik ilave edip bekletin.
• Sosu hazırlamak için soğanı ince kıyın.
• Tavada margarini eritip soğanları pembeleşinceye kadar kavurun.
• Unu ekleyip tekrar kavurduktan sonra sütü ekleyin ve muhallebi kıvamına gelinceye kadar pişirin.
• Hazırladığınız sosa ıspanak ve mantar karışımını ekleyip karıştırın.
• Miflöy hamurlarını hafif açın ve tepsisine yayarak tamamını kaplayın.
• Üzerine hazırladığınız ıspanak karışımının yarısını ilave edin.
• Üzerine havuç ve kaşar dilimlerini yerleştirin.
• Kalan ıspanak karışımını da ekledikten sonra 200 dereceye ayarlı fırında 30 dakika pişirin.
• Bir kapta 2 çorba kaşığı sütü ve 1 yumurtayı çırpın.
• Ispanaklı kişin pişmesine 5 dakika kala fırından alıp üzerlerine süt ve 5 dakika daha pişirip sıcak olarak servis yapın.

Şimdi yukarıdaki açıklamayı modellemek istersek  aslında bir kara kutu yaklaşımı ile bu işlemi (Ispanaklı kiş hazırlama işlemini) aşağıdaki şekilde modelleyebiliriz:

Yukarıdaki kara kutu yaklaşımında sistemi “Ispanaklı Kiş hazırlanışı” olarak görmek ve sisteme girenler olarak yemek tarifimizdeki malzelemeleri ve çıkan olarak da Ispanaklı Kiş görmek doğru bir yaklaşım olur.

Bu sistemi hiyerarşik olarak bölecek olursak alt kademeeleri bulunmaktadır. Örneğin sos hazırlanması, ıspanakların hazırlanması, soğanların kavrulması gibi alt işlemler tanımlanabilir.

Yukardaki hiyerarşik ilişki içerisindeki her kutu aslında bir kara kutu olarak düşünülebilir. Örneğin Mantar ve Ispanağın hazırlanması aşamasında

• Ispanakları yıkayıp az haşlayın.
• Kevgirle süzüp bekletin.
• Mantarı ince ince doğrayarak az haşlayın.
• Haşladığınız ıspanakları doğrayıp mantarla karıştırın.
• Tuz ve kekik ilave edip bekletin.

İşlemleri yapılmaktadır. Dolayısıyla girenler : “ıspanak, mantar, tuz ve kekik” olarak sıralanabilir. Ve bu işlemde örneğin Ispanakların yıkanması, Mantarların doğranması, Ispanak ve mantarların karıştırılması, Tuz ve kekik ilavesi gibi alt kutulara (işlemlere) bölünebilir.

Sonuçta bütün bu işlemleri ve bu işlemlerin seviye seviye gösterildiği analiz yöntemine hipo ismi verilmektedir.

329 views

Bağlam yönelimli programlama (Aspect oriented programming) konusunda kullanılan en önemli yapı taşlarındandır. Basitçe bir programın akışı içerisinde bağalam noktaları (joinpoints) belirlendikten sonra bu noktalara hangi bağlamların (Aspects) bağlanacağını belirleyen kümedir.

Yani nesne yönelimli bir ortamda yazılan programımız üzerine örmek istediğimiz (aspect weaving) bağlamları (aspects) kod üzerindeki birleşim noktaları (joinpoints) ile belirliyoruz. Belirlenen bu noktaları tutan ve hangi noktaya hangi bağlamın bağlanacağını belirleyen kümeye ise noktakesici (pointcut) ismi verilir.

Yapı olarak nokta kesicileri (pointcuts) iş mantığına daha yakın görmek mümkündür. Yani mantıksal bir tasarım sırasında bir bağlamı belirten bir nokta kesici bulunur ve bu nokta kesici birden fazla birleşim noktasından oluşabilir.

Örneğin program geliştirme sırasında sıkça kullanılan işlemlerden birisi kullanıcıdan bir form doldurmasını istemek ve doldurulan bu formu veri tabanına kaydetmektir. Bu eylem başlı başına bir bağlamdır (Aspect) ve bu olayı meydana getiren birleşme noktaları bir nokta kesici (pointcut) belirler. Örneğin formdaki her alan, bu alanların doğrulanması veya veritabanına kayıt yapan metotlar birer birleşim noktası (join point) olabilir.

122 views