Mimari Biçemleri: Modül Görünüş Tipinin Biçemleri - Kullanım Biçemi

Kullanım Biçemi

Kullanım Biçemi modül mimari tipi içerisinde gösterilen modüllerin, kendi aralarındaki kullanım özelliklerini, izinleri ve yasakları göstermektedir. Bir modül kendi kullanımı için üst modülleri ya da alt modülleri kullanabilir. Kullanma işlemi burada önem kazanmaktadır çünkü bir modül işlemini tamamlayabilmek için bir alt modülden gelen işlem sonuçlarını bekleyebilir. Bu durum modüller arası bağımlılık ve üst modüller ile alt modüllerin etkilişiminin bir yoludur. Bu şekilde tanımlanan kullanım işlemini içeren modüller ve alt modüllerinin gösterildiği biçem kullanım biçemidir.
Kullanım biçemi içerisinde temel yapıtaşı (element) olarak modüller kullanılmaktadır.

Mimari Biçemleri: Modül Görünüş Tipinin Biçemleri

Bir önceki konuda bahsedildiği gibi Modül Görünüş Tipinin temelde 4 farklı ilişki etrafına örüldüğünü görmekteyiz. Bu ilişkiler bu görünüş tipi için stilleri meydana getirmekte ve modül görünüş tipini oluşturulurken aranan birer özellik olarak karşımıza çıkmaktadır.

Ayrıştırma Görünüşü

Ayrıştırma işlemi Modül Görünüş Tipinin oluşturulma aşamasında gerçekleştirilmektedir. Ayrıştırma işleminin için tanımlanan Ayrıştırma Görünüşü, modüllerin nasıl alt modüllere ayrıldığını, sistemin sorumluluklarının nasıl diğer modüllerle paylaşıldığını göstermeye yarar . Ayrıştırma işlemi tüm mimariler için temel bir işlemdir. Bir modül ayrıştırma işlemi sonucunda daha detaylı işlemler yapan alt modüllere ayrıştırılarak, daha kaliteli bir sistem elde edilmekte, dışarıdan sağlanacak hizmetler kullanılarak geride kalan işlerin paylaşımı gerçekleştirilebilmekte ve benzer modüllerin tekrardan yaratılmasının önüne geçilmektedir.

Ayrıştırma Görünüşü içerisinde gösterilen alt sistemler, belirli özellikler içermedikleri sürece alt sistemler olarak ele alınmazlar ve ayrıştırılmazlar. Bir alt sistem uyumlu bir alt küme olmalıdır. Yani kendi bağımsızlığından haberdar olmalı ve bağımsız işletilmelebilmelidir. Bu şekilde belirlenen alt sistemler, ayrıştırma görünüşü içerisinde artan bir şekilde geliştirilerek ve uygulanarak sistem alt sistemlere ayrıştırılır. Bu şekilde belirlenen ve ayrıştırılan alt sistemler Ayrıştırma Görünüşü içerisinde belirtilmektedir.

Bu mantıkla ayrıştırılan alt sistemlerin ve sistemlerin Ayrıştırma görünüşü içerisinde hangi özellikleri ve ilişkileri ile betimlendiğinden bahsedelim. Ayrıştırma görünüşü temelde yapı taşı (element) olarak modülleri almaktadır. Görünüş içerisinde modüller arası ilişki parçasıdır (is-part-of) ilişkisidir. Ayrıştırma Görünüşü içerisinde bu ilişkiyi içeren modüller ve alt modüller gösterilir. Parçasıdır ilişkisi içeren modüller ve alt modüller arasında geçişlilik (transitive) ilişkisi bulunmasına rağmen simetrik özelliğine sahip olmadığından, bu ilişki ile oluşturulan ağlar içerisinde döngülerin bulunmaması gerekmektedir.

Notasyon

Basitçe gösterim yapıldığında ayrıştırma işlemi bir modülün diğer modülü kapsadığı durumlar için kullanılmaktadır. Bu sebeple bir kutunun diğer kutuyu içine aldığı basit gösterimler yeterli olmaktadır.
UML ile gösterim yapıldığında ise farklı şekilde gösterim yapılabilmektedir. Bir gösterim içerisinde bir modül diğerinin içine çizilerek ayrıştırma görünümü oluşturulur. Diğer bir gösterimde ise bir modül parçasıdır ilişkisi ile bağlı olduğu modüle bağlanır ve aşağıdaki şekilde gösterilir.

Şekil -1 : Ayrıştırma Görünüşü

Bu şekil içerisinde Modül1'e bağlı olan diğer modüller birden çoğa ilişkisi içeren parçasıdır ilişkisi ile bağlı olarak gösterilmektedir. Bu şekilde gösterilen modüller ve alt modüllerin oluşturduğu görünüş Ayrıştırma Görünmünü oluşturmakta ve sistemin mimarisi içerisindeki modüller arasındaki ayrıştırma sonucunda oluşan yapıyı göstermektedir.

Mimari Görünümleri : Modül Görünüm Tipi

Modüller yazılım dünyası içerisinde yazılım mimarilerinin ortaya çıkması sonucunda ortaya atılmıştır. Modüllerin oluşturulması işlemine modülasrizasyon denir.
Modülarizasyon :

• Değiştirilebilme


• Taşınabilirlik


• Tekrardan kullanım

özellikleri yazılım birimlerine uygulanarak modüller oluşturulmaktadır. Modül GörünümTipi temelde 4 farklı işlemin sonucunda oluşan 4 görünümten oluşmaktadır.

• Ayrıştırma (Decomposition) : Modüller arası içerme işleminin belirlenmesi ve gerekli modüllerin ayrıştırılması.
• Kullanım (Uses) : Modüller arasındanki işlevsel bağımlılık ilişkilerinin tanımlanması ve gösterimi
• Genelleştirme (Generalization) : Özelleştirme işlemlerinin gerçekleştirilmesi ve ilişkilerin gösterilmesi
• Katmanlar (Layers) : "Kullanabilme" izininin tanımlanması ve bu sayede farklı görünümlerin birbirleri arasındaki seviyelerin gösterimi

Modül Görünüm Tipi bu farklı görünümlerin bütününden oluşmakta ve yazılım mimarilerini açıklamaktadır. Modül Görünüm Tipi, modüller arasında 4 farklı ilişki tanımlamaktadır. Yazılım uygulamaları içerisinde sınıfların kendi aralarındaki ilişkileri incelendiğinde, temelde bu dört ilişkinin modülleri tanımlamak ve modüller arası ilişkileri betimlemek için yeterli olduğu görülür. Bu ilişkilere bakacak olursak;

İlişkiler : parçasıdır(is-part-of) , bağlıdır(depends-on), aynısıdır(is-a), ek olarak kullanabilme (allowed-to-use)

Modül Görünüm Tipi bu özelliklerin yanı sıra birer hiyerarşiyi açıklayacak bir isim, modüllerin sorumlulukları (Birbirine karışmayan ve detaylı bir şekilde açıklanmış modül rolleri ve kimlikleri), modülün arayüzünün görünülürlüğü(kapsandığı modülün arayüzünden mi yoksa kendi arayüzünden mi haberleşeceği) ve uygulanma bilgisi (Cod parçalarına işaret eden, test, uygulanma kısıtlarını ve yönetim bilgileri) içermektedir.

İlişkiler ise kendi özelliklerine sahiptir.

parçasıdır : Görünürlük özelliği

bağlıdır : Bağlı durumdaki modüllerin arasındaki koşullar

aynısıdır : Uygulama özelliği ; A --inherits--> B

Modül Görünüm Tipi bu özelliklere sahip olmakla birlikte, bir çok farklı gösterim yolu ile gösterilebilmektedir. Genel olarak bakıldığında mimari şekilleri içerisinde modüller, baloncuklar, kutular ile gösterilmekte, ilişkiler ise çizgiler ile belirtilmektedir. Modüllerin özellikleri ise düz yazı ile açıklanmaktadır. Genel gösterimin dışında UML(Unified Modeling Language) ile de gösterilmektedir. Modül Görünüm Tipinin içerisinde yer alan modüller ve aralarındaki ilişkiler UML olarak Şekil-1 içerisinde gösterilmektedir.

Şekil-1 : Modül Görünüm Tipi elementleri ve ilişkileri

Anlamsal Web Portal Mimarisinin Anlatımı : Mimari Görünüşlerinin Eklenmesi

1. Giriş
   Anlamsal Web Portal geliştirme süreci içerisinde diğer Anlamsal Web Portal mimarileri incelendiğinde karşımıza çıkan mimarilerde genel eksiklik mimarilerin tüm özelliklerinin ve içeriğinin yansıtılmamasıdır. Bu eksikliği gidermek için Documenting Software Architectures kitabı içerisinde bahsedilen görünüş ve diğer yapılardan burada kısaca bahsedilecektir.
2. Gereksinimler ve Kısıtlamalar
   Anlamsal Web Portal Mimarilerinin genel yapısı içerisinde en önemli özellik ontoloji kavramıdır. Ontolojilerin gösterimi ve saklanması işlemleri, ontolojilerin içeriklerinin farklı şekillerde web portal içerisinde etki edebilmesi, Anlamsal Web Portal kavramının temel özelliklerinden birisidir. Ontolojiler bu özellikleri nedeniyle mimari içerisinde farklı yerlerde (katmanlarda) kullanılmaktadır. Bu durum ise ontolojilerin bilgi katmanı dışında üst katmanlar içerisinden erişilmesi gerekliliğini doğurur. Üst katmanların ontolojileri kullanabilmesi, katmanlı mimariler içerisindeki soyutlama gerekliliğini de içermek zorundadır.
3. Mimari Görünüşleri

• Mantıksal Görünüşü (Logical View)

Mantıksal görünüş içerisinde davranışsal gereksinimler gösterilere oluşturulan mimarinin son kullanıcıya nasıl bir hizmet sunacağı belirtilmektedir. Mantıksal görünüş ilgi alanında olan bilginin kullanıcının anlayabileceği bir seviyeye çekilmesi, yani davranışların modellenmesi için gerekli olan soyutlamanın gösterildiği görünüştür.

• İşlem Görünüşü (Process View)

İşlem görünüşü anlatılan mimarinin dağıtık ve kararlı yapısının anlatıldığı görünüştür. İşlem görünüşü kararlı yapısı içerisinde sistemin bütünlüğü ve hataya toleransı gösterilmektedir. Sistemin bütünlüğü ve olabilecek hataların belirlenmesinde temel alınması gereken birimler mantıksal görünüş içerisinde ortaya konan sınıflardır. Bu sınıflar bir kontrol iş parçağı tarafından denetlenerek, her bir sınıf içerisindeki her bir operasyon bu denetlemeden geçirilmektedir. İşlem görünüşü temel olarak bu hata kontrolünü gerçekleştirirken sadece oluşacak işlem hatalarını değil, aynı zamanda donanım hatalarını da kontrol etmektedir.

• Geliştirme Görünüşü (Development View)

Geliştirime görünüşü yazılım modüllerinin organizasyonun gösterildiği görünüştür. Bu görünüş içerisinde her bir yazılım parçacığı küçük birimler içerisinde gösterilmektedir. Geliştirme görünüşü bu şekilde büyük yazılımların küçük parçacıklara bölüştürülmesi ve çalışma gruplarına dağıtılmasında kullanılmaktadır. Bu görünüşün tam olarak gerçekleştirilmesi amacıyla bütçe oluşturma, planlama ve proje işleminin gözlemlenmesi gibi yazılım mühendisliği tekniklerinin kullanılması gerekmektedir.

• Fiziksel Görünüş(Physical View)

Fiziksel görünüş yukarıda belirtilen tüm görünüşlerin bir bütün halinde çalıştığının gösterildiği görünüştür. Fiziksel görünüş içerisinde diğer görünüşlerde belirtilen tüm yapılar çalışan bir işlem olarak gösterilmekte ve uygunluk, performans, ölçeklenebilirlik ve hataya tolerans gibi işlemleri ele almaktadır.

Yoğunluk

Bugün yoğun çalışma programı ve yarınki yüksek lisans sunumu sebebiyle buradaki yazımı yazamıyorum. Çarşamba günü devam edeceğim.

Dynamic Object Model-Dinamik Nesne Modeli (Uygulama)

Dinamik Nesne modelinde şu ana kadar açıklanan tüm sınıfların burada kod olarak java dilinde nasıl oluşturulacağından bahsedeceğim.

İlk olarak bir önceki gönderi içerisinde tanımlanan müşteri-müşteri özellikleri mimarisinin sınıflarını oluşturacak olursak elimizde bir mevduatHesabı sınıfımız olsun.

public class SavingsAccount

{

  protected Money balance;

  protected Percentage interestRate;

  ...

  public Money getBalance() {

  return balance;

}

public synchronized Money deposit(Money deposit) {balance+= deposit;}

public synchronized Money withdraw(Money amount) {

    Money newBalance = balance - amount;

    if (newBalance >= 0) {

      balance = newBalance;

   }

}

public void accrueDailyInterest() 

{

    Money interest = InterestCalculator.calcDailyInterest((), getInterestRate());

    deposit(interest);

}

...

}

Basit şekilde mevduatHesabı sınıfını tanımladıktan sonra işlem olarak faiz oranının hergün eklendiği düşünelim. Ancak bu durumda her bir müşteri için faiz oranının ayrı ayrı olmasının kontrol edilmesi sorunu ortaya çıkmaktadır. Daha önce bahsedildiği gibi bu sorun müşteriler için mevduatHesabıTipi sınıfının oluşturulmasıyla çözümlenir.

public class SavingsAccountType 

{

protected Percentage interestRate;

...

public Percentage getInterestRate() 

{

return interestRate;

}

public synchronized void setInterestRate(Percentage ir) 

{

interestRate = ir;

}

...

}

Geriye yönelik olarak Müşteri sınıfındaki faiz oranını müşteriTipi sınıfından alındığını düşünürsek;

public class SavingsAccount

 {

...

protected SavingsAccountType type;

...

public SavingsAccountType getType()

 {

return type;

}

public void accrueDailyInterest() 

{

Percentage interestRate= getType().getInterestRate();

Money interest = InterestRateCalculator.calcDailyInterest(getBalance(),interestRate);

deposit(interest);

}

...

}

Bu andan sonra birde KrediHesabı olduğunu düşünelim. KrediHesabı ile MevduatHesabı sınıflarının ortak bir Hesap sınıfından türediğini varsayarsak, süpersınıf olarak hesap sınıfını tanımlarız.

public class Account 

{

protected PartyId ownerId;

protected Money balance;

protected AccountType type;

...

public String getTypeName() {

return type.getName();

}

...

}

public class AccountType 

{

protected String name;

...

public String getName() { return name;}

...

}

Ancak tüm sınıflar için tüm alanlar birbirinin aynı olamayacağından herbir hesap için bir overwriting işlemi ile yeni metodlar ve tipler tanımlanması gerekmektedir. Bu durumda herbir özel durum için bir overwriting işlemi yapılması özellikle büyük verilerin olduğu durumlarda ve farklı tipte hesapların çoğaldığı uygulamalarda sorunlar çıkarmaktadır. Bu sebeple özelliklerin tutulması için bir özellik listesi tutulması ve özelliklerin ortak bir sınıftan oluşturulması daha doğru olacaktır. Bu sayede bu listenin elemanları için farklı özellikler tutulabilecektir.

class Account 

{

protected PartyId ownerId;

protected Money balance;

protected Hashtable properties;

...

public Money getBalance() 

{

return balance;

}

public Object getProperty(String name) 

{

Object result= getFieldProperty(name);

if (result == null) 

{

result= getListProperty(name);

}

return result;

}

protected Object getFieldProperty(String name) 

{

if (name.equals("balance")) 

{

return getBalance();

}

...

}

protected Object getListProperty(String name) 

{

return properties.get(name);

}

public synchronized void setProperty(String name, Object value) 

{

if (isFieldPropertyName(name)) 

{

setFieldProperty(name, value);

}

else 

{

setListProperty(name, value);

}

}

protected void setFieldProperty(String name, Object value) 

{

// no code for balance, but for other properties.

...

}

protected void setListProperty(String name, Object value) 

{

properties.put(name, value);

}

...

}

Bu noktadan geriye dönüp baktığımızda ilk olarak özelleştirilmiş bir hesabı modelledikten sonra ardından abstraction ile hesapları modelledik ve ardından hesapların farklılıklarından yola çıkarak Tip-Nesne Desenini kullarak hesap tiplerini oluşturduk. Ardından farklı hesapların farklı özellikler içereceğini düşünerek özellikleri özellik listesi desenine uygun olarak listelerde tuttuk. Son olarak farklı özelliklere sahip olan hesaplar gibi aynı özelliklere sahip hesaplarında olabileceğini düşündüğümüzde özellikler içinde bir tip tanımının yapılması gerektiği ortaya çıkmıştır.

class PropertyType 

{

protected String name;

protected Class type;

protected boolean isMandatory;

...

public String getName()

 {

return name;

}

public boolean isSupertypeOf(Class type) 

{

return type.isAssignableFrom(type);

}

public boolean isValidValue(Object value) 

{

// check value, possibly delegate to a strategy

}

...

}

Tanımladığımız özellik listesi özelliklerin tutulduğu hesap tipi sınıfını etkileyeceğinden bu durumda hesap tipi sınıfı tekrardan yazıldığında;

class AccountType 

{

protected String name;

protected Hashtable propertyTypes;

...

public boolean hasPropertyType(String name) 

{

return propertyTypes.containsKey(name);

}

public boolean isValidProperty(String name, Class type, Object value) 

{

if (!hasPropertyType(name)) 

{

return false;

}

PropertyType pt = getPropertyType(name);

return pt.isSupertypeOf(type) && pt.isValidValue(value);

}

...

}

Pazartesi günü bu modellerin bir tasarım içerisinde nasıl yer alacağını ve Anlamsal Web içerisinde nasıl Dinamik Nesne Modeli ile bir uygulama geliştirileceğini açıklayacağım.

Dynamic Object Model-Dinamik Nesne Modeli (Devam)

Dinamik yapının oturtulması farklı tasarım deseninin bir araya getirilmesi sonucunda olur. Aynı zamanda ortaya bir yapının çıkması sonucunda dinamik olarak nesnelerin değiştirilmesi sağlanabilir. Bu durum sağlanırken belirli tasarım desenlerini içeren bir yapının oluşturulması gerekmektedir. 

Örneğin bir satış işleminin yönetildiği sistem tasarladığımızı düşünelim. İlk olarak müşterinin bilgisinin saklandığı bir müşteri sınıfı olsun. Müşterilerin farklı tiplere sahip olacağını düşünelim.

 Bu durumda Tip-Nesne desenini kullanarak MüşteriTipi sınıfını tanımlarız ve Müşteri sınıfı ile aralarında tip ilişkisi olduğunu belirtiriz (Şekil-1).

Şekil-1 : Tip-Nesne Tasarım Deseni

Bu andan sonra tek bir müşteri tipi olmadığı, birçok müşteri tipi olduğunu kabul etmekle birlikte, aynı zamanda her bir müşteri için bir müşteri tipi tanımlamak ve birçok farklı özellik tanımlamaktayız. Tüm bu özellikler MüşteriTipi sınıfını şişireceği için özellikleri sınıflardan ayırarak özellik, özellik tipi ve nesne üçlüsünü içeren Özellik listesi ve Değer Tutma Desenlerini birleştirmekteyiz. 

Şekil-2 : Değer Tutma ve Özellik Listesi Desenleri

Özellik Listesi sayesinde bir müşterinin seçtiği özellik için belirttiği değer aralığının geçerliliğini kontrol etmekteyiz. 

Şimdi bu yapıyı daha model haline getirdiğimizi düşünelim ve Dinamik Nesne Modelinin temelini oluşturan Sınıf/Sınıf Tipi ve Özellik/Özellik tipi sınıflarından oluşan yapıyı oluşturalım.(Şekil-3)

Şekil-3 : Dinamik Nesne Modeli için sınıf diyagramı

Bu yapı içerisinde üç farklı tasarım desenini birleştiren Dinamik Nesne Modeli tanımladığı özellik tutma ve değiştirme işlemlerini gerçekleştirmek için SınıflandırıcıRol'den faydalanmaktadır. Sınıflandırı rol bir nesnenin yürütme anında rolü belirtmek için kullanılmaktadır. Bir sınıf (ve nesneleri) tanımladığı sınıflandırı rol içerisinden bir değer almaktadır. Bir sınıflandırıcı rol başında "/" sonunda ":" imleçlerini alarak gösterilmektedir. 

Dinamik Nesne Modeli içerisinde açık dünya anlayışını destekleyen yapının ortaya konması için sınıflandırıcı roller tanımlanmıştır. Sınıflandırıcı roller Şekil 3 içerisindeki Dinamik Nesne Modeline uygulandığında kullanıcı nesnelerinin farklı değerler alabilmesi ve özelliklerin de farklı değerler alabilmesi sağlanmaktadır. 

Özellik listesi desenine Sınıflandırıcı rol uygulandığında bu durumda özellikler sadece sahibi olan sınıfa ait olmamakta aynı zamanda çalışma anında oluşan nesneler tarafından da erişilebilir olmaktadır. Özellikler dinamik olarak get ve set yapılabilmekte, aynı zamanda yeni özellikler tanımlanması sağlanabilmetedir. Bu sayede çalışma anında nesne içerisinden sahibi olan sınıfın özellikleri genişletilebilmektedir.(Şekil-4)

Şekil-4 : Özellik Listesi deseni için sınıflandırıcı Rol

Tip-Nesne desenini incelediğimizde bir nesnenin tip tanımları içerisine yeni bir davranış tanımladığını görmekteyiz. Sınıflandırıcı rol sayesinde müşteriye ait bir nesne sadece sınıfın sahip olduğu özelliklere bağlı kalmamaktadır. Çalışma anında yeni müşteri özellikleri de tanımlanabilmektedir.(Şekil 5)

Şekil 5 : Tip-Nesne deseni için sınıflandırıcı rol

Son olarak değer saklayan desen temelde değerlerin saklanması ve modellenmesi amacıyla kullanılır. Sınıflandırıcı rol sayesinde nesneler direk olarak değerlere erişebilmekte ve bu sayede değerleri değiştirmekle kalmayıp tiplerini ve bağlı olduğu nesneleri de değiştirebilmektedir.(Şekil 6)

Şekil 6 : Değer Tutucu desen için sınıflandırıcı rol

Sınıflandırıcı rolleri tanımladıktan sonra Şekil-3 içerisinde tanımladığımız Dinamik Nesne Modeline geri dönersek, bu sınıflandırıcı roller içerisinden hangi sınıfların hangi rollere atandığını tanımlarız. 

Bileşen : 

• Bileşen sınıfı  Özellik sınıfının nesneleri için Sahip dir. /Özellik:Özellik
• Bileşen sınıfı Özellik sınıfının değer tutan rolü için bir istemcidir. Çünkü değerleri özellik sınıfına sormaktadır.
• Bileşen sınıfı BileşenTipi sınıfının tip rolü için bir nesnedir. Çünkü kendisine ait tipler temelde diğer sınıftan gelmektedir.
• Bileşen sınıfı BileşenTipi sınıfının tip rolü için bir istemcidir. Çünkü kendisine ait tiplerin özelliklerini bu sınıfa sormaktadır.

Özellik : 

• Özellik sınıfı Bileşen sınıfının sahip rolü için bir özelliktir. 
• Özellik sınıfı ÖzellikTipi sınıfının tip rolü için bir nesnedir.
• Özellik sınıfı Değer sınıfının değer rolü için bir değer tutucudur.

Değer sınıfı : 

• Değer sınıfı Özellik sınıfının değer tutucu rolü için bir değerdir.

Bileşen Tipi :

• Bileşen Tipi sınıfı Bileşen sınıfının sahip rolü için bir istemcidir. Çünkü sahip olacağı tipler Bileşen sınıfı içerisinden tanımlanmaktadır.
• Bileşen Tipi sınıfı Bileşen sınıfının nesne rolü için bir tipdir. Çünkü Bileşen sınıfına ait tipler Bileşen Tipi içerisinde saklanmaktadır.
• Bileşen Tipi sınıfı ÖzellikTipi sınıfının özellik rolü için bir sahiptir. Çünkü Özellik Tipi sınıfı Bileşen Tipi sınıfının tanımladıkları dışında tip bulunduramaz.
• Bileşen Tipi sınıfı Özellik Tipi sınıfının özellik rolü için bir istemcidir. Çünkü Bileşen Tipi içerisindeki tip tanımları Özellik Tipi içerisindedir.

Özellik  Tipi :

• Özellik Tipi sınıfı Bileşen Tipi sınıfının sahip rolü için bir özelliktir.
• Özellik Tipi sınıfı Özellik Tipi sınıfının nesne rolü için bir tiptir. Kendi kendisi içerisinde tanımlanan tipleri kullanarak yeni tipler oluşturabileceğinden kendisinin tipidir.
  

Dynamic Object Model-Dinamik Nesne Modeli

Dinamik Nesne Modeli nesnelerin çalışma zamanında tiplerinin değişmesini destekleyen bir nesne modelidir. Bu özelliği ile Anlamsal Web uygulamalarında kullanılır.
Anlamsal Web açık bir dünyadır. Açık bir dünyada, bir varlık hakkındaki bilgi sadece bilinen kadar olduğu kabul edilir. Eldeki bilgiden yola çıkarak, bu varlık ile ilgili diğer bilgilerin doğruluğu ya da yanlışlığı bilinemez. Bu tip bir yaklaşıma Açık Dünya Yaklaşımı denmektedir. Anlamsal Web kendi içerisinde varlıkları paylaşabilen bir dünyadır. Bu sebeple bir varlık ile ilgili bilgi farklı yerlerde tutulabilmektedir. Bu sebepten Anlamsal Web'de bir varlık hakkındaki bilginin erişilen uzay kadar olduğu kabul edilmez. Erişilen uzay sadece varlıkla ilgili bilginin bir kısmı olduğu yani açık bir uzayda sadece bir galaksiyi gözlemleyebildiğimiz kabul edilmektedir.
Programlama yöntemleri ve paradigmalarına baktığımızda ise açık bir dünya aksine olabildiğince net ve belirli bir uzayla karşılaşırız. Kapalı dünya yaklaşımına sahip programlama yöntemleri ve dilleri, temelini aldığı lojik diller ile birlikte Anlamsal Web ile karşıtlık içerisindedir. Bu sebepten üst düzey programlama dillerinin açık dünya yaklaşımına sahip ontolojileri modellerken kullanılması ve ontolojik kavramları anlamsal olarak saklayabilmesi için açık dünya yaklaşımına olmaları gerekir.
Dinamik Nesne Modeli bu noktada devreye girerek, Anlamsal Web ile Nesneye Dayalı Programlama arasında bir köprü oluşturmaktadır.
Dinamik Nesne Modeli temelde önceden belirlenmiş ve oluşturulmuş nesne çatılarını dinamik hale getirerek, çalışma anında yeni tiplerin yaratılmasını ya da varolanların değiştirilmesini veya varolan nesneler arası ilişkilerin değiştirilmesini sağlamaktadır.
Dinamik Nesne Modeli temelde bir bileşik desendir. Tip-Nesne, Özellik listesi ve Değer Saklayan Desenlerinin birleşiminden oluşmaktadır.

Reification-Maddeleştirme

Reification temelde birçok bilim dalında geçse bile Anlamsal Web içerisinde kullanımında en uygun tanım psikolojide yapılan tanımdır;

Soyut veya metaforik bir kavramı, formülasyonu, vb. sanki gerçek veya somut bir nesneymiş gibi değerlendirme. Örneğin aşka duyulan özlemi bir hastalıkmış gibi, ya da soyut 'renk' kavramına sanki renkli nesneden bağımsız olarak varolan bir şeymiş gibi değerlendirmek buna bir örnektir. [Psikoloji Sözlüğü]

Reification (Maddeleştirme) Anlamsal Web içerisinde cümleciklerin maddeleştirilmesine denilir. Reification, RDF (Resource Description Identifier) dili kullanılarak açıklanan cümlecikler içerisindeki Özne-Yüklem-Nesne üçlülerindeki yapıyı desteklemektedir. Bu yapı içerisinde yapılan "Ali sinemaya gitti" cümlesinin üçüncü bir şahıs tarafından bize iletildiğini ele alalım. Bu durumda cümle: "Ahmetin söylediğine göre Ali sinemaya gitmiş" şeklinde olacaktır. Bu noktada reification önem kazanmaktadır. Ali'nin sinemaya gidip gitmediği bir üçlü değildir. Bu cümle içerisinde düşünüldüğünde bir nesne olması gerekmektedir. RDF dili içerisinde üçlülerin bir nesne olarak kullanılması gerekliliği ortaya çıkmakta, RDF dili içerisinde reification yapısı sayesinde bu cümlenin üçlü olarak saklanması sağlanabilmektedir.
Soyut kavramlar düşünüldüğünde bir cümle içerisinde nesne olarak ya da betimlemelerde soyut kavramlar kullanıldığı görülmektedir. Bu durumda kullanılan her rengin ya da soyut kavramın öznesinden bağımsız olarak bir nesne olarak varolabilmesi gerekmektedir. Bu durumu bir örnekle incelersek;
"Ali ekmeği kızarttı." cümlesini ele alır ve bu durumu bir üçlü olarak bir graf içerisine yerleştirdiğimizi düşünelim.
kızarmak

Ali ----------> Ekmek

Bu durumda artık bir üçlü elde etmiş oluruz. Ancak eğer bu cümle daha farklı betimlemelerde içerseydi nasıl yapılandırılmalıydı?
Cümlemiz "Ali ekmeği salı günü tavada kızarttı." olsaydı bu durumda elimizdeki üçlü yapısı bu betimleme için yetmeyecektir. Graf içerisinde bu betimleme şöyle olacaktır.

         Kızartmak eylemi
       /\
      /  \
     /    \
    /      \
   /        \
  /Kızartmak \
Tom -------> Ekmek

Bu durumda elimizdeki cümlenin anlamsal olarak kayba uğramaması amacıyla bu betimleme içerisine salı günü ve tavayı eklememiz gerekmektedir. Bu zarfların özne ya da nesne ile ilgili olmadığını düşünürsek, zarfları yüklem içerisinde betimlememiz gerekmektedir. Bu rudumda Kızarmak eylemini tanımlarız. Bu eylem içerisinde zarfları tanımlamak ve anlamsal olarak kaybı engellemek mümkün olur.

tavada -------- kızartmak eylemi
           /  /\
salı günü --+  /  \
            /    \
           /      \
          /        \
         /Kızartmak \
       Ali -------> Ekmek

Bu yeni durumda Kızartmak eylemi genel durumdan kurtulmuş ve özelleşmiş olarak tutulur. Kızartmak yüklemi yerine yeni tanımlanan kızartmak eylemi saklanmalıdır. Bu sayede reification yapılabilmekte ve anlamsal kayıp olmadan bilgi eksiksiz saklanabilmektedir. Çıkarsama işlemlerinde önemli bir yere sahip olan bu bilgiler sayesinde çıkarsama işlemleri genel durağanlığından kurtulmuş olur [Newcomb, S. R.].

Anlamsal Web Çalışmaları

Herkese merhabalar,
Anlamsal Web Çalışmaları blogunda size Anlamsal Web ile ilgili yaptığım çalışmaları, okuduğum makaleleri özetlemeye çalışacağım. Blog içerisinde tüm yazılar türkçe olacak ve bu sayede türkçe bir dökümantasyon elde etmek ve sizlerinde Anlamsal Web konusunda bilgi edinmenizi sağlamayı amaçlamaktayım.