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.