7 Aralık 2015 Pazartesi

Dijital Çağda Eğitim

1. Giriş

Dijital teknolojilerin yaşamımıza izin beklemeden girdikleri bir çağ bu. Günlük eylemlerimizin neredeyse tamamı 10 sene öncekinden farklı bir şekilde gerçekleşmekte. Mobil gereçler ile sürekli biçimde internete bağlı olmak, hem yakın çevremizle, hem bütün bir dünya ile kurduğumuz ilişkileri kökten değiştirmekte. Sanal dünyada gerçek alış veriş yapılıyor, gazete ve dergiler dijital olarak okuyucularına ulaşıyor. Dijital dönüşüm hızlanarak sürmekte. 2025 yılında dünya çapında 50 milyar gerecin (şey/thing) birbirine bağlanmış olacağı ön görülüyor. Şeylerin interneti (internet of things / IOT) denilen gelişme şimdiden başlamış durumda. Giyilebilir gereçlerden, akıllı arabalardan bahsediyoruz. Arabamızın garaja yaklaşması ile, ısıtma sistemlerinin çalışmaya başlayacağı, kahve makinasının taze bir kahve hazırlamak için harekete geçeceği bir çağ gelmekte.

Eğitim yaşamının bu gelişmelerden etkilenmemesi olası değil. Dijital çağ, daha önceki dönemlerde kıymetli olan meslek sahibi olmayı önemsiz kılmıyor ama salt bu amaca dönük çabanın yetersiz kalacağı bir geleceği ima ediyor. Yetişmekte olan yeni kuşakların kariyerleri boyunca ortalama altı meslek (iş yeri, pozisyon değil meslek) değiştirecekleri ön görülüyor. Meslek edindirmeyi önceleyen eğitim amaçlarımızın gözden geçirilme zamanı geldi, geçiyor.

Dijital dünyaya hazırlayacağımız çocuklarımızın, gençlerimizin, dijital okur yazarlıklarının yükseltilmesi, eğitim emeğinin rasyonel kullanımını zorunlu kılmakta. Öğretmenin hem bir rol model olarak, hem yol gösterici olarak önemi artmakta. Kadim dünyanın “tartışılamaz” az sayıda ki kaynağına dayalı eğitim çabası artık yerini namütenahi ancak tartışılabilir kaynağa bırakmış durumda. Muazzam bilgi yığını içinden değerli olanı seçebilmek, sunulanı başka referanslar ile karşılaştırıp, doğrulamak ya da yanlışlamak, hiç olmadığı kadar gerekli. Öğretmen, doğruları vaz eden otorite konumundan, doğrulara giden yolların kapısını gösteren kişi olmaya evriliyor. Bu kapıların hepsi değilse dahi pek çoğu dijital yollara açılmakta.

Eğitim emeğinin rasyonel kullanımı ve yaklaşan yeni çağ için gerekli becerilerle donanmış kuşaklar yetiştirme sorumluluğu eğitim alanında dijital teknolojilerin kullanımını zorunlu kılmakta. Yazının devamında bu alanda ki kimi çözümleri tartışmaya çalışacağım.


2. Eğitimde Dijital Teknoloji Kullanımı

Sınıf içinde teknoloji kullanımı eğitim çabası ortaya çıktığından bu yana var. Antik Yunan akademisi içinde bahçede yapılan yürüyüşler boyu verilen eğitim çabasında bile. Diyalektik denilen, tartışmaya, zıtlıkları bulup, onları gideren bir sonuca varmayı hedefleyen yöntemin kendisi bir teknoloji. Elle tutulup, gözle görülen bir şey olmamasına karşın, bu gün batı medeniyeti dediğimiz şeyin kendisi bu antik teknolojinin bir ürünü. Daha yakın dönemlerde kullanageldiğimiz sıra, masa, sandalyeden başlayıp, tahta, tebeşir, gönye, pergel, harita gibi pek çok teknolojik araca sahibiz. Ders kitapları, defter kalem, kırtasiye gereçleri de var.

Dijital çağ, sınıf içinde kullanabileceğimiz pek çok gereci sunmakta. Öğretmenin kullandığı bilgisayar, bu bilgisayar ekranının perdeye yansıtılması ile, geleneksel tahta kullanımının yeni bir forma kavuşması mümkün. Hatta salt bu amaç için geliştirilmiş, geniş ve yüksek çözünürlüklü akıllı tahtalar bulunmakta. Bu teknoloji ile ilk seviye eğitim kurumlarımızın epeyi bir kısmı Fatih projesi kapsamında tanışmış durumda. Öğrencilerin sınıf içinde kullanabilecekleri bir bilgisayara sahip olmaları, öğretmenin anlattıklarını kendi ekranlarında izleyebilmeleri bir diğer imkan. Gene öğrencilerin bilgisayar yerine tablet kullanarak benzer bir ders izleme sürecini takip etmeleri mümkün. Fatih projesi ile bu yönde de adımlar atılmış durumda. Eksikliklerine karşın, proje, edinilen tecrübeler ışığında yürütülmeli, genişletilmeli.

Sınıf içinde öğretmen-öğrenci etkileşimini dijital ortamda sağlamak üzere geliştirilmiş yazılım çözümlerinden biri de NetSupport School. Bu yazılım ile öğretmen öğrencilerin ekranlarını izleyebilmekte, kendi ekranını öğrencilere gönderebilmekte, sınavlar hazırlayıp, gerçekleştirebilmekte. NetSupport School, sınıf içinde öğretmen/öğrenci etkileşiminin bütün yönleri düşünülerek geliştirilmiş. Öğrenci, sorularını kendi bilgisayarı üstünden sorabilmekte, öğretmen soruları bütün sınıfa ya da yalnızca soran öğrenciye yanıtlayabilmekte. Öğretmen, kendi makinasından öğrencilerin makinalarına dosya gönderimi yapabilmekte, öğrencilerin makinasında programları çalıştırabilmekte. Öğretmen isterse, öğrencilerin dikkatini kendilerine vermelerini sağlamak amacıyla, öğrencilerin ekranlarını karartabilmekte.

NetSupport School yazılımı ile, öğrenci makinalarında ancak izin verilen programların çalışması sağlanabilmekte. Gene istenirse izlenilebilecek web siteleri belirlenebilmekte. NetSupport School, sınıf içinde eğitim amacıyla kullanıldığı gibi, uzaktan eğitim amacıyla da kullanılabilecek özelliklere sahip. Bu durumda öğretmen, vereceği dersin saatini ve konusunu duyuruyor, öğrenciler, yurttan, kütüphaneden, evlerinden o saatte derse kaydolup dersi izleyebiliyorlar. Sınıf içinde olduğu gibi, uzaktan eğitimde de öğretmen yukarıda anlatılan işlevleri yerine getirebiliyor. Esasen sınıf içi yerel ağ ortamında çalışmak üzere geliştirilmiş olmasına karşın, uzaktan erişim imkanları ile internet bağlantısının olduğu her yerden derse bağlanabilmeyi olanaklı kılıyor.

NetSupport School yazılımı ülkemizde de bilinen ve yaygın olarak kullanılan bir ürün. Pek çok orta ve yüksek öğrenim kurumunda NetSupport School kullanılmakta. Fatih projesi kapsamında okullara dağıtılan akıllı tahtaların içinde de, NetSupport School yazılımı yüklü gelmekte ancak tek kullanıcı lisansı ile geldiği için, etkin biçimde kullanılabilmesi için ek lisanslar alınması gerekiyor.


3. Eğitimde Dijital Teknoloji Kullanımı İçin Zorunluluk: Eğitim İçeriği Geliştirme

Eğitimde kullanılacak teknolojinin kendisinden daha önemli olan zorunluluk ise eğitim içeriğinin geliştirilmesi. Bu olmaksızın ne kadar ileri teknolojiler kullanılırsa kullanılsın, beklenen faydanın alınabilmesi mümkün değil. Maalesef içerik geliştirme, bütün sürecin en çok emek, yatırım, katılım isteyen kısmı. Ders kitaplarında olduğuna benzer şekilde bir içerik hazırlama sektörü oluşmuş değil. Kaldı ki, böylesi bir sektörün oluşması ve olgunlaşması dahi alınması gereken yolun ancak yarısı. Dijital teknoloji, namütenahi içeriğin hazırlanmasını ve bunun sürekli tarzda yenilenmesini, zenginleştirilmesini gerektiriyor. Bu ise, eğitimcilerin geniş ölçekli katılımı ile yapılabilir durumda. Anılan görevin üstesinden gelebilmek için, eğitimcilerin ve dijital teknoloji uzmanlarının birlikte çalışmasına, iki tarafın bir birinin dilinden anlar hale gelmesine ihtiyaç bulunmakta. Açıkçası bu uzun bir süreçtir. Uzun olması, hemen başlanılması gerektiğini de ima ediyor.

Eğitim içeriğinin dijital olarak hazırlanması için pek çok yöntem bulunmasına karşın, bu gün, hem ortak bir format olması, platformlardan bağımsızlığı nedeniyle, zengin html sayfaları kullanımı popüler hale gelmekte. Esasen salt eğitim alanında değil ama hemen bütün alanlarda içerik oluşturmada aynı yönelimde.

HTML içerik geliştirme denildiğinde bu gün HTML5, JavaScript ve CSS kullanımı anlaşılmakta. Bu üçlü, salt statik içerik için değil ama aynı zamanda dinamik içeriğe sahip web uygulamalarının da altında yatan teknoloji. Bu teknoloji tabletler ve telefonlar için geliştirilen (mobil) uygulamalarında en çok kullanılan geliştirme yöntemi.

İçerik geliştirme sonuç aldıkça, üretilen içeriğin yönetilmesi, amaca uygun biçimde sunulması önem kazanmakta. İçerik yönetim sistemleri (Content Management System CMS) bu noktada devreye girmekte. İçeriğin, özgünleştirilmiş kullanıcı deneyimleri sunacak tarzda sunulması, kolaylıkla yeni içerik eklenmesi kadar, var olan içeriğin değiştirilmesi, genişletilmesi amacıyla CMS kullanılmakta. Telerik Sitefinity, içerik yönetimi alanında zengin imkanlar sunan bir ürün. Birden çok editörün aynı anda (kendi sorumluluk sahaları içinde) içeriğe katkıda bulunmaları, sahadan gelen kullanıcı deneyimlerine göre sunumu yeniden şekillendirebilmelerine olanak tanıyor.


4. Son Söz:

Eğitim alanında ki emeğin verimli kullanımı, geçmiş üretimlerin değerlendirilebilmesi, öğrencilerin eğitim içeriğine sınırsız erişimi için, eğitim çabasında dijital teknolojilerin kullanımının önemi açık. Ülkemiz gibi, genç nüfusa sahip, eğitim ihtiyacı katlanarak büyüyen, bu alanda ki yatırımlarından hızlı sonuçlar almaya zorunlu toplumlar için, bu konu gerçekten yaşamsal önemde.

Türkiye, eğitim alanında kendine has ve çok başarılı olmuş projelere sahip. Açık öğretim, uzaktan eğitim alanında pek çok mütekabil ülkeye göre çok ilerde tecrübeler edinmiş durumda. Bu alanda ki deneyimlerin ileriye taşınabilmesi, yerel ölçekte projeler ile zenginleşebilmesi pek ala mümkün. Gereken ise, bu alanda vizyon sahibi, girişimci eğitim liderleri.

27 Kasım 2015 Cuma

MindManager 2016 Sürümünde Özel Alan Kullanımı



MindManager 2016 sürümü ile gelen harita elemanlarına özel alanlar tanımlayabilme, formül oluşturma olanakları zihin haritası kullanım deneyimini zenginleştiriyor.

Bu sürüme kadar elemanlar ancak MİndManager tarafında tanımlı özelliklere sahip olabiliyorlardı. Şekil, renk, resim, açıklama gibi temel özelliklerin yanısıra, dosya ekleme, köprü kullanma, eğer eleman bir iş adımını gösteriyor ise kimin sorumlu olduğu, başlangıç ve bitiş tarihleri, tamamlanma oranı gibi özellikler içermekte idi. Esasen klasik zihin haritalamanın parçası olmayan iş adımı özellikleri zihin haritalarının iş/proje yönetiminde kullanabilmesinin önünü açmıştı.

2016 sürümünde ise harita elemanlarına istediğiniz kadar özellik verebilmek, bunları kullanarak formüller yazabilmek mümkün. Bu olanak zihin haritası kullanımını iş süreçlerinin başka alanlarında da kullanabilmenin önünü açıyor. Örneğin iş adımlarını gösteren elemanlarımızı artık maliyet, bütçe gibi alanlarla zenginleştirebilmek ve formüller kullanarak kolaylıkla takip edebilmek mümkün.

Aşağıdaki videoda tatil planlaması için yapılan bir haritada özel alanların ve formüllerin kullanımını izleyebilirsiniz.



23 Kasım 2015 Pazartesi

XAF Ortamında İş Modelini Çoklu Kalıtım Kullanarak Tasarlamak 2

Bir önceki yazıda, XAF ortamında çoklu kalıtım konusuna giriş yapmış, devam edeceğimizi söylemiştim. Bu yazıda, ara yüzler kullanılarak tasarlanan, çoklu kalıtıma dayalı iş modelimizin veri tabanı yapısının nasıl değiştirilebileceği ve iş mantığının yardımcı sınıflar aracılığı ile nasıl uygulanabileceği üzerinde duracağız.

Hatırlayacağınız gibi, çoklu kalıtım kullanılarak yapılan tasarımın, XAF tarafından oluşturulan veri tabanı üzerindeki yansısı, tasarımımızda ki nesne hiyerarşisinin tekrarlanması şeklinde olmakta idi. Bir başka deyişle, modelimizde kullandığımız ICari, IBanka, IStok, IPersonel gibi nihai elemanlar ve IAdres, IHesap, IMemo, IKodluEleman gibi paylaşılan elemanların her biri için ayrı bir veri tabanı tablosu oluşturulmakta ve bunlar OID anahtarlarının aynılığı üzerinden biribirlerine bağlanmakta idi. Bunun XAF altında kullanıldığında, esasen bizim açımızdan transparan olduğundan, bununla ilgilenmemize gerek olmayacağından ancak aynı veri tabanı başka uygulamalar tarafından da kullanılacaksa sorun olacağından söz etmiştik.

Tasarım aşamasında çoklu kalıtım kullanarak avantajlarından yararlanmak ancak veri tabanı üzerinde daha standart bir şema elde etmek nasıl mümkün olur? Standart haliyle XAF ara yüz tanımlarının kendisine bildirilmesi ile her kalıcı eleman (persistent) için bir veri tabanı tablosu yaratmaktadır. Eğer ilgili alanların soyutlama amacıyla yaratılmış eleman arayüzlerine ait ayrık tablolarda değil de, doğrudan nihai elemanların tabloları içinde tutulmasını istiyorsak, yapacağımız şey, soyutlama amacıyla kullandığımız elemanların kalıcı olmadığını bildirmektir. Bu bildirimi "NonPersistent" özelliğini kullanarak sağlayabiliriz.


[DomainComponent]
[NonPersistentDc]
public interface IAdres
{
     ...

}

[DomainComponent]
[NonPersistentDc]
public interface IKodluEleman
{
     ...
}

[DomainComponent]
[NonPersistentDc]
public interface IMemo
{
     ...
}

[DomainComponent]
[NonPersistentDc]
public interface IHesap
{
     ...
}

Soyutlama amaçlı kullandığımız elemanlar artık veri tabanı içinde barındırılmayacakları için XAF'e bildirilmeleri de gerekmemektedir. Bu durumda "Setup" fonksiyonu içinde ki kodlarımızı aşağıda ki şekle getirmemiz gerekecektir:

using DevExpress.Persistent.BaseImpl;
// ... 
public override void Setup(XafApplication application) {
    base.Setup(application);
    XafTypesInfo.Instance.RegisterEntity("Personel", typeof(IPersonel));

    XafTypesInfo.Instance.RegisterEntity("Cari", typeof(ICari));
    XafTypesInfo.Instance.RegisterEntity("Stok", typeof(IStok));
    XafTypesInfo.Instance.RegisterEntity("Banka", typeof(IBanka));
}

Bu adımlar sonucunda XAF veri tabanı üzerinde yalnızca nihai elemanlar için tablolar yaratacak, soyutlama ara yüzlerinde tanımlanmış olan alanları, kullanıldıkları nihai elemanlara ait tablolar içinde barındıracaktır.

İş Mantığı (Domain Logic)

Modelimiz, salt veriyi içeren sınıflar üzerine kurulu ise, buraya kadar tartıştığımız özellikler işimizi görmemize yetecektir, ama pek çok durumda, yarattığımız model sınıfları içinde o sınıfa özgü fonksiyonlar, olaylar ve olay karşılayıcıları, ilgili nesne özellikleri üzerinde operasyon yapan metodlar bulunacaktır. XAF'i sınıf tanımlamaları üzerinden kullandığımız (ve tekli kalıtımla yetinmeye razı olduğumuz durumlarda) sorun yok, gereken fonksiyonları, olay karşılayıcılarını o sınıf üstünde yazabiliriz. Örneğin Cari elemanına mail göndermek için kullandığımız bir fonksiyon ihtiyacımız olduğunu düşünelim. Bu fonksiyonu doğrudan Cari sınıfı içine yazabiliriz:
public class Cari : TicariIsletme
{

     ...

     public void SendMailToMe(string Title, string Message)
     {
         ...
     }

}

Ancak eğer çoklu kalıtım olanaklarından yararlanmak için "Domain Component" kullanmaya karar verdi isek, elimizde yalnızca ara yüz bildirimleri kalmaktadır. Açıktır ki, ara yüz bildirimleri içine uygulama (implementation) yazamayız. Yazdığımız ara yüzlerin uygulandığı sınıfları bulup onlar içine yazmak akla gelebilir ama bu, öncelikle bu sınıflar, XAF tarafından çalışma anında (runtime) tanımlandıkları, tasarım anında var olamdıkları için imkansızdır. Dahası, mümkün olsa idi dahi, ara yüzün uygulandığı bütün sınıfları bulmak ve yazmak istediğimiz kodu her bir sınıf içinde tekrarlamak zorunda kalacak idik ki, nesne tabanlı paradigmanın vaat ettiklerine tam anlamıyla ters bir iş yapıyor olacaktık. XAF bu problemi aşmak için "DomainLogic" denilen bir yardımcı sınıf kullanımına olanak verir. DomainLogic sınıfları düz birer sınıftırlar ve istediğimiz fonkiyonları vb. barındırabilirler. Ara yüz içine koyamadığımız uygulama kodlarını DomainLogic sınıfı üzerine koyabiliriz. Yarattığımız DomainLogic sınıfını ilgili olduğu ara yüz ile ilintilendirmek için DomainLogic özelliği ile donatmamız yeterli olacaktır. Örnek olarak IHesap elemanımız için Borç, Alacak bilgilerini sıfırlayacak bir işlev ihtiyacımız olduğunu düşünelim. 

[DomainComponent]
public interface IHesap
{
     double Borc{get;set;}
     double Alacak{get;set;}

     void ClearValue(IHesap instance);}

[DomainLogic(typeof(IHesap))]
public class IHesapLogic
{
     public static void ClearValues(IHesap instance)
    {
      instance.Borc = 0;
      instance.Alacak = 0;
     }        
}

Görüldüğü gibi IHesapLogic sınıfı DomainLogic özelliği ile IHesap ara yüzüne bağlanmıştır. XAF IHesap ara yüzünü uygulayan sınıfların her bir nesnesi için bir IHesapLogic nesnesi yaratacak ve uygulayan sınıf üstünden çağrıların yapılmasına olanak verecektir. Örneğimizde IHesap ara yüzünü uygulayan ICari elemanımız için ClearValues işlevi geçerli olacaktır.

Çoklu kalıtım model ağacımızın basitleşmesine, daha modüler kod geliştirebilmeye olanak sağlayan yöntem olarak çok vaatkar görünmekte. Kuşkusuz gerçek bir proje ile uğraşırken ayrıntılar önemli olacaktır. Ayrıntılar ve daha çok öğrenmek için aşağıdaki link yardımcı olacaktır:

https://documentation.devexpress.com/#eXpressAppFramework/CustomDocument113261




21 Kasım 2015 Cumartesi

XAF Ortamında İş Modelini Çoklu Kalıtım Kullanarak Tasarlamak 1

Yazılım geliştirme süreçlerinin olmazsa olmazı, uygulamaya özgü bir model oluşturmaktır. Küçük ölçekli, ya da kısa süreli bir kullanım ömrüne sahip olacağı beklenen projelerde, model oluşturma adımının "adhoc" tarzda yapıldığına şahit olsak ta, genellikle bu adım dikkatli ve kurallı bir şekilde yapılmak zorundadır. Model, yazılımın kodlanması, kullanım performansı, kullanıcı deneyimi, yazılımın uzun vadede bakımı açısından merkezi bir önemdedir.

Nesne tabanlı tasarım paradigması yazılım geliştime süreçlerinde baskın olmaya başladığından bu yana, yazılımcılar nesne tabanlı dünyaları ile, nesnelerin kayıt altına alındığı ve genelikle nesne tabanlı olmayan yapılar (veri tabanları, dosya sistemi, vb) arasındaki ilişkiyi kurmakla yükümlü oldular. "Serializer" yardımına kavuşmadan önce, uygulama geliştimenin önemli bir bölümünü, bu alanda yapılması gerekenler oluşturmakta idi. Nesne tabanlı geliştirme dünyamız ile, kullandığımız teknoloji arasında ki bu boşluğu doldurmak için epeyi emek harcadık. Bu gün bu alanda iki temel yardımcımız var. İlki özellikle bilimsel, mühendislik uygulamarında kullanımı artan nesne tabanlı veri tabanları. NoSQL veri tabanlarının giderek web ve büyük veri alanında yaygınlık kazanmaları da gelecekte farklı olanaklara sahip olacağımızı ima ediyor. İkinci olarak ise nesne tabanlı geliştirme ortamı ile çizelge temelli ilişkisel veri tabanları arasındaki yaklaşım farklarını gidermeyi hedefleyen nesne-ilişkisel bağıntılama (object relational mapping - ORM) yöntemi. ORM katı kodlama dünyasındaki nesnel yaklaşımı, kalıcı hale getirme, yeni nesneleri kalıcı ortamdan okuyarak yaratma, kalıcı hale getirilmiş nesneler üzerinde sorgulama yapabilme gibi pek çok işlevi, ilişkisel veritabanlarına karşı nesne ara yüzü üzerinden kullanabilmemize olanak vermekte. ORM katı için gerek açık kaynak kodlu, gerek değişik ticari şekiller altında pek çok ürün bulmak mümkün. En yaygın olanları arasında Hybernate, Entity Framework bulunmakta.

Devexpress firması, kullanıcı arayüzü bileşenleri alanındaki ürünleri ile tanınıyor. Bunun yanısıra, yazılımcılara XPO (Express Persistent Object) denilen bir ORM katını da sunmakta. Devexpress bileşen çözümleri yanı sıra, çoklu platform uygulama geliştirme çerçevesi olarak XAF (Express Application Framework) ürününü geliştirmiş. XAF ile aynı kod tabanını kullanarak, hem Windows masaüstü, hem Web uygulamaları geliştirmek mümkün. İş uygulamaları geliştirmek amaçlı bir çerçeve uygulama olarak tanımlamak mümkün. XAF, ORM katı olarak ya XPO ya da Entity Framework kullanımına olanak tanımakta.

ORM kullanarak, veri tabanı işlemlerini, nesne tabanlı bir şekilde halletmek, gereken bütün ara dönüşümlerin ORM tarafından yapılması, yazılımcı olarak bizi oldukça rahatlatan ve asıl işimize, uygulamanın konu aldığı problemin çözümüne odaklanmamızı sağlayan bir olanak. XAF altında uygulama geliştirmenin en önemli adımlarından biri model tasarımının yapılması. XAF model tarafından belirlenen bir uygulama büyük ölçüde. Modeli tanımlamış olmakla, temel işlevlere sahip bir uygulama XAF altında hazır hale gelebilmekte. Modelin XAF uygulamasında merkezi rolü nedeniyle artan önemi, nesne tabanlı tasarım imkanları ile birleştiğinde, model tasarımına farklı yaklaşmamızı gerektirmekte.

Nesne tabanlı paradigmanın önemli imkanlarından birisi kalıtım mekanizması. Sınıfları birbirlerinden türeterek, yüksek seviyede soyutlamalar yapabilmeyi, bu sayede daha yalın kod üretebilmeyi mümkün kılan kalıtım imkanı, model tasarımına da uzanmakta. XAF (kullandığı ORM katının olanaklarını kullanarak) modelimizin bir sınıf hiyerarşisi olarak tanımlanabilmesini sağlamakta.

Örnek olarak, iş yazılımlarında sıklıkla kullanılan kimi elemanlar düşünebiliriz. Cari elemanı (sınıfı) çoğunlukla bir ticari işletmeyi göstermektedir. Bir başka deyişle Cari elemanı TicariIsletme elemanından türetilebilir. TicariIsletme elemanı ise esas olarak Adres elemanından türetilebilir.

Örnek:


public class Cari : TicariIsletme
{

     public double Borc;
     public double Alacak;

}

public class TicariIsletme : Adres
{

     public string VergiDairesi;
     public string VergiNo;

}

public class Adres:XPObject
{

     public string BinaNo;
     public string DaireNo;
     public string Sokak;
     public string Cadde;
     public string Mahalle;
     public string Ilce;
     public string Il;
     public string Ulke;
     public string PostaKodu;

}

Modelin kalıtım/türetme yoluyla belirlenmesi burada anmamızı gerektirmeyecek avantajlara sahiptir. Kısaca soyutlamanın gerek tasarım, geliştirme gerek bakım safhalarında hayatımızı kolaylaştırdığını söyleyip geçelim.

Yukardaki nesne hiyerarşisinin veri tabanı tablolarında ki yansısı nasıl olacak? ORM yazılım katı nesneleri birebir veri tabanı şemasına (yapısına) yansıttığında beklentimiz aşağıdaki gibi bir veri tabanı yapısı olacaktır :



İlişkisel cebir esasen bu tür bir yapıya karşıt olmadığı gibi tersine bunu önerir. Normalleştirmenin "aynıların aynı yerde olması" kuralı, elde ettiğimiz veri tabanı yapısını ima etmektedir. Gene de bu yapının çok alışık olduğumuz türde olmadığını teslim etmeliyiz. Bir cari kaydını okuyabilmek için üç tablo arasında join kullanmak zorunda olmak ürkütücü görünmektedir. Hele hele raporlama aşamasında. Bu konuda bir çok tartışma yapılmakta. Bu günün veri tabanları için ortaya çıkacak başarım farkının minimal olduğu, bu farkın istendiğinde veri tabanı sunucusuna ek kaynak tahsisi ile aşılabileceği söylenebilir. İtirazların haklı olduğunu kabul etsek dahi, tasarımın aynı zamanda bir stil meselesi olduğu ortadadır. Kİmi durumlarda nesne hiyerarşisini yansıtan bir veri tabanı yapısını istememiz, kimi durumlarda, nesne hiyerarşisinin sonuçlarını yansıtan, örneğimizdeki Cari elemanının kalıcı hale getirileceği veri tabanı tablosunun gereken bütün alanları barındırdığı (daha klasik) bir yapı istememiz mümkündür. XPO altında bu "attribute" kullanımı ile kolaylıkla sağlanabilir. Kodumuzu aşağıdaki gibi bir parça değiştirirsek, istediğimiz sonucu elde edebiliriz:


[MapInheritance(MapInheritanceType.ParentTable)]
public class Cari : TicariIsletme
{

     public double Borc;
     public double Alacak;

}

[MapInheritance(MapInheritanceType.ParentTable)]
public class TicariIsletme : Adres
{
     public string VergiDairesi;

     public string VergiNo;

}

public class Adres:XPObject
{
     public string BinaNo;
     public string DaireNo;
     public string Sokak;
     public string Cadde;
     public string Mahalle;
     public string Ilce;
     public string Il;
     public string Ulke;
     public string PostaKodu;
}

Bu durumda TicariIsletme ve Adres elemanlarımız kendi başlarına veri tabanı içinde saklanmalarına gerek yoktur. Bütün gereken alanlar zaten Cari tablosunun içinde yer alacaktır. Bu nedenle bu elemanları kalıcı olmayacak şekilde işaretlememiz gerekir.

[MapInheritance(MapInheritanceType.ParentTable)]
public class Cari : TicariIsletme
{
     public double Borc;

     public double Alacak;

}

[NonPersistent]
[MapInheritance(MapInheritanceType.ParentTable)]
public class TicariIsletme : Adres
{
     public string VergiDairesi;


     public string VergiNo;

}

[NonPersistent]
public class Adres:XPObject
{
     public string BinaNo;
     public string DaireNo;
     public string Sokak;
     public string Cadde;
     public string Mahalle;
     public string Ilce;
     public string Il;
     public string Ulke;
     public string PostaKodu;


     
}

Böylelikle alışageldiğimiz (klasik) yapıya dönmüş olduk. Artık veri tabanımızda yalnızca Cari tablosu, gereken bütün alanları ile birlikte bulunacaktır.

Veri tabanı yapısının ORM katı yardımıyla, nesne tabanlı bir şekilde tasarlanması işlerimizi kolaylaştırmaktadır ama isteklerimizin burada kalması söz konusu değildir. Kalıtım gerçek gücünü ancak çoklu kalıtım altında gösterebilir. Tekli kalıtım altında kurulan nesne hiyerarşileri ister istemez karmaşık olmak, pek çok vekil (proxy) nesne tanımı barındırmak ve derin olmak dezavantajlarına sahiptirler. Çoklu kalıtım, soyutlamayı birden çok eksen üzerinden yapabilmeyi, neticede daha yalın nesne hiyerarşileri ile tasarımı bitirebilme şansını sunmaktadır. Problemimiz, yaygın kullanılan nesne tabanlı dillerin pek çoğunun çoklu kalıtımı desteklememesinde yatmaktadır. Özellikle dotNET altında çoklu kalıtım söz konusu değildir. XAF ise bir dotNET uygulama çerçevesidir. Devexpress tam bu noktada gerçek bir "hack" kullanarak sorunu aşıyor. "Domain Component" diye adlandırdığı teknolojiyi kullanarak dotNET ortamında -yalnızca iş modeli sınıflarımız için- çoklu kalıtım imkanlarını sunuyor. 


"Domain Component" teknolojisi bir kaç adımdan oluşuyor. İlki sınıflar yerine arayüz (interface) tanımları üzerinden çalışmak gerekiyor. İkincisi, yalnızca arayüzleri yazdığımız ama bu arayüzleri uygulayan sınıfları yaz(a)madığımız için, gereken sınıf tanımlarının XAF tarafından oluşturulmasını sağlamak üzere, yazdığımız arayüzlerin XAF'e bildirilmesi (register edilmesi) adımı. Bu iki adım ile yalnızca alanlardan (field/property) oluşan bir tasarımı bitirmek mümkün. Arayüzleri yazıyoruz, XAF'e bildiriyoruz, o sınıf tanımlarını ve bunların saklanacağı veri tabanı yapısını oluşturuyor. Sanırım fark ettiniz, burada eksik kalan bir nokta var. Eğer iş modelinde yer alan sınıflarımız kendilerine has işlevler, olaylar vb. sahibi iseler ne olacak? Yazdığımız arayüzler salt birer bildirim oldukları için gereken iş mantığı (business logic) nerede uyguılanacak, yazılacak. Arayüzlerden sınıf üretimi XAF tarafından çalışma anında (runtime) yaratılacakları için bu sınıflara müdahale edebilmemiz olanaksız durumda. Bu noktadaki zorluk, DomainLogic diye adlandırılan bir yardımcı sınıfın yazılması ve bu sınıfın ilgili arayüzün iş mantığı olarak XAF'e bildirilmesi ile çözülüyor.

Bir parça karışık ve anlaşılmaz gelmesinden ürkülecek bir şey yok. Bir örnekle görünür kılmaya çalışalım. İş modelimizde pek çok eleman hem bir kod hem bir isim taşımakta olsunlar. Cari ve Stok gibi elemanlar bu tür örnekler. Gene bir çok eleman, adres bilgisi taşımakta olsun. Personel, Cari gibi. Modelimizde pek çok eleman, ayrıntılı açıklamalar girilebildiği bir tipte olsunlar. Stok, Cari gibi. Gene hemen dikkatimizi çekecek bir başka ortaklık, Cari, Stok, Kasa, Banka gibi pek çok elemanın giren/çıkan/kalan bilgilerinin tutulduğu alanlara sahip olması. Böylesi bir yapıyı tasarlarken, bu özelliklerin her birinin ayrı birer eksende soyutlanması ve nihai (sonul) elemanların bu soyutlama nesnelerinden türetimi işimizi çok kolaylaştırabilecektir.

Öncelikle soyutlamamız neticesinde elde ettiğimiz eleman tanımlarını ara yüz biçiminde yazalım :


[DomainComponent]
public interface IAdres
{
     string BinaNo{get;set;}
     string DaireNo{get;set;}
     string Sokak{get;set;}
     string Cadde{get;set;}
     string Mahalle{get;set;}
     string Ilce{get;set;}
     string Il{get;set;}
     string Ulke{get;set;}
     string PostaKodu{get;set;}
}

[DomainComponent]
public interface IKodluEleman
{
     string Kod{get;set;}
     string Ad{get;set;}
}

[DomainComponent]
public interface IMemo
{
     [Size(SizeAttribute.Unlimited)]
     string Memo{get;set;}
}

[DomainComponent]
public interface IHesap
{
     double Borc{get;set;}
     double Alacak{get;set;}
}

Bu temel elemanları kullanarak Cari, Stok, Banka, Personel gibi elemanları tasarlamak artık daha kolay olacaktır:

[DomainComponent]
public interface ICari:IKodluEleman,IMemo,IHesap,IAdres
{
     string Yetkili{get;set;}
     string VergiDairesi{get;set;}
     string VergiNo{get;set;}
}

[DomainComponent]
public interface IStok:IKodluEleman,IMemo,IHesap
{
     ICari Saglayıcı{get;set;}
     boolean Emtia{get;set;}     
}

[DomainComponent]
public interface IBanka:IKodluEleman,IMemo,IHesap,IAdres
{
     string HesapNo{get;set;}
     string HesapDovizi{get;set;}     
}

[DomainComponent]
public interface IPersonel:IMemo,IHesap,IAdres
{
     string Ad{get;set;}
     string Soyad{get;set;}
     string SSKNo{get;set;}
     string Unvan{get;set;}
     datetime DogumTarihi{get;set;}
     datetime IseGirisTarihi{get;set;}
     datetime IstenCikisTarihi{get;set;}
}

Bu aşamada gereken arayüzlerimizi XAF'e bildirmek. Uygulama'nın başlangıç kodlarının içinde bunu yapabiliriz:

using DevExpress.Persistent.BaseImpl;
// ... 
public override void Setup(XafApplication application) {
    base.Setup(application);
    XafTypesInfo.Instance.RegisterEntity("Personel", typeof(IPersonel));
    XafTypesInfo.Instance.RegisterEntity("Cari", typeof(ICari));
    XafTypesInfo.Instance.RegisterEntity("Stok", typeof(IStok));
    XafTypesInfo.Instance.RegisterEntity("Banka", typeof(IBanka));


    XafTypesInfo.Instance.RegisterSharedPart(typeof(IMemo));
    XafTypesInfo.Instance.RegisterSharedPart(typeof(IKodluEleman));
    XafTypesInfo.Instance.RegisterSharedPart(typeof(IAdres));
    XafTypesInfo.Instance.RegisterSharedPart(typeof(IHesap));



}

Elemanların XAF'e bildirilmesi (register) sırasında sonul eleman olarak kullanmak istediğimiz Cari, Stok gibi elemanların bildirimi ile birden çok elemanın yapı taşı olarak kullanılacak soyut elemanların bildirimleri arasındaki farka dikkat etmek önemli. Paylaşılan elemanlar RegisterSharedPart ile bildirilirken, nihai elemanlar RegisterEntity  ile bildirilmekte.

XAF çoklu kalıtım kullanılan "Domain Component" bildirimleri uyarınca veri tabanı yapısını oluştururken, bildiğimizin biraz dışında bir yapı oluşturacaktır. Veri tabanında gerek nihani elemanlar, gerek paylaşımlı olarak kullanılan elemanların her biri için ayrı bir tablo açılacak ve ilgili alanlar bu tabloların içinde bulunacaktır. Bu tablolardan veriyi çekip, sonul elemanları yaratmak için ise XAF her bir kayıt ile tutulan OID alanlarının değerlerini kullanmaktadır. Örneğin belirli bir carinin OID'si "AAA" ise, bu Cari'nin türediği IMemo, IKodluEleman, IAdres, IHesap tanımlarının ilgili tablolarındaki ilgili kayıtlar da "AAA" OID'sine sahip olacaklardır. XAF bir Cari kaydını okurken hem Cari tablosunu hem paylaşılan tiplerin ilgili tablolarını aynı OID üzerinden sorgulayarak okumakta ve toplu sonucu bir Cari nesnesi olarak döndürmektedir.

Tasarım sürecimizi daha yalın bir hale getirmesine karşın, saptanmış haliyle oluşan veri tabanı yapısı standart olmaktan uzaktır. XAF kullandığımız sürece, veri tabanından kayıtların okunması bizim konumuz olmadığından bu duruma katlanılabilir ama eğer aynı veri tabanına XAF dışında bir ortamdan erişim gerekiyorsa, ortaya çıkan tasarım o tarafta işleri kolaylaştırmak bir yana daha da zorlaştıracaktır.

XAF altında çoklu kalıtım kullanarak veri tabanı yapısının nasıl daha standart bir hale getirilebileceği ve iş mantığının "Domain Logic" kullanarak nasıl uygulanacağını "
XAF Ortamında İş Modelini Çoklu Kalıtım Kullanarak Tasarlamak 2" başlıklı yeni bir blogta tartışacağım.