Makale Özeti

Microsoft Smart Client Software Factory (SCSF) Microsoft Pattern&Practice gurubunun hazırlamış olduğu tüm aplication block'ları entegre bir biçimde kullanan gene aynı gurup tarafından geliştirilen harika bir yazılımdır. SCSF projesinin başlangıç noktası Composite Application Block (CAB)'dır. CAB aslında bizim masaüstü uygulamamızın temelli oluşturmaktadır. Diğer uygulama blokları CAB çevresinden CAB’ı destekleyen yapılardır.

Makale

SCSF-CAB Giriş


Microsoft Smart Client Software Factory (SCSF) microsoft pattern&practice(P&P) gurubunun hazırlamış olduğu tüm aplication block'ları entegre bir biçimde kullanan gene aynı gurup tarafından geliştirilen harika bir yazılımdır. Birbirine çok benzeyen WorkItem, Module, WorkSpace, Shell gibi kavramlardan dolayı ilk bakışta yazılımcılara karmaşık gelen bir yapısı vardır. Gerçektende dependency injection, command patterns, event brokers, model-view-presenter patterns gibi üst seviye kavramların anlaşılması son derece güçtür. Biz bu yazı dizisinde SCSF-CAB ile kullanılan kavramların hepsini ele alıp inceleyeceğiz. Aynı zamanda bu kavramların anlaşılması için Microsoft tarafından yayınlanan dokümanlar oldukça fazladır.

SCSF projesinin başlangıç noktası Composite Application Block (CAB)'dır. CAB aslında bizim masaüstü uygulamamızın temelli oluşturmaktadır. Diğer uygulama blokları CAB çevresinden CAB’ı destekleyen yapılardır.


SCF-CAB Temel Mimarisi.


CAB Nedir?

Composite UI Aplication Block Microsoft P&P grup tarafından karmaşık ve modüler Smart Client uygulamalar geliştirmek üzere kullanıma hazır olarak sunulan bir uygulama bloğudur. İki önemli yeteneği vardır:

  1. Birbirinden bağımsız olarak geliştirilen ve kullanılan bileşenler ile oluşturulan karmaşık ara yüzler dizayn eder. (Module)

  2. Yapılan ara yüz uygulamalarını alır ve bunları ortak bir pencere üzerinde entegre bir biçimde çalıştırır. (Shell)


CAB UseCase Driven Developing yaklaşımını temel alır. CAB mimarisinin öncelikli amacı bizim UseCase diyagramlarımızı gerçekleştirmektir.

Use case diyagramlarınızla 1:1 eşleşen WorkItem düzenleyebilirsiniz. WorkItem eklenen ara yüz işlemleri ve gerekli tüm parçalarla birlikte çalışan bir Use Case kontrolcüsüdür. Kodlama açısından baktığımızda ise WorkItem nesneleri Use Case işlemlerini gerçekleştirecek tüm alt parçalara sahiplik yapan bir üst nesnedir.

WorkItem


Bir senaryo üzerine düşünelim. Bir stok projesi için Back Office uygulamasını yazacaksınız. Use Case diyagramlarını çıkarttınız. Back Office – front Office çalışanı, stok yöneticisi, müşteri gibi çeşitli aktörleriniz olacaktır. Her bir aktörün yetki seviyelerine göre yerine getirebileceği stok isteği, müşteri tanımlama, kredi onaylama gibi birçok hareketleri olacaktır. Her bir aktör bir diğer aktöre ait hareketlerin bir kısmını da kullanacaktır. Mesela stok yöneticisi Back Office çalışana ait müşteri borçlandırma hareketini de işleyebilecektir.

Ortak kullanılan hareket gruplarını bir Sub-Use Case içine toplayalım. Geriye kalan her bir atomik hareket gruplarını da ayrı Sub-Use Case diyagramlarının içine toplayalım. Tüm bu Sub-Use Case diyagramlarını içeren bir Root-Use Case diyagramımız ve bu Root-Use Case içinde bir kısmı ortak bir kısmı sadece kendi aktörü ile çalışan Sub-Use Case diyagramlarımız olacaktır.

İşte size CAB. Bir önce ki kısımda her bir Use-Case ile 1:1 eşleşen ve görevi Use-Case diyagramını gerçekleştirmek olan WorkItem nesnelerini gördük. Seneryomuzda Sub-Use Case ve Root-Use Case diyagramları olması gerektiğini gördük. CAB içerisinde Root-Use Case diyagramını gerçekleştiren bir RootWorkItem vardır. Tüm Sub-Use Case işlerini gerçekleştiren WorkItem nesneleri bu RootWorkItem altında oluşturulurlar.

Şimdi böyle bir yazılımın ihtiyaçlarını düşünelim.

  1. RootWorkItem nesnesi WorkItem nesnelerine ihtiyaç duydukları parçaları sağlamadır. (Injection Pattern – Object Builder)

  2. RootWorkItem nesnesini içeren ortak bir uygulama sağlanmalıdır. Üstünde her biri sadece bir tek WorkItem içeren modüllerden oluşan esnek ve genişleyebilen uygulama yapısı sağlanmalıdır.(Shell – Module)

  3. Arayüz ile iş kodu birbirinden tamamen ayrılmalıdır.(Model-Viewer-Presenter Pattern)

  4. WorkItem nesneleri program kullanıcısıyla doğrudan etkileşime girebilmelidir. (Command Pattern)

  5. WorkItem nesneleri kullanıcı yetkisine göre iş kurallarını işletmelidir. (Action Pattern)

  6. WorkItem nesneleri gerekli durumlarda diğer WorkItem nesneleri ile konuşabilmelidir. (Event Broker)

  7. WorkItem nesneleri ortak kullanılan ToolBar-StatusBar gibi ara yüz elemanlarını erişebilmelidir. (Register-Unregister UI Element)

  8. Ara yüz geliştirirken sadece Visual Studio ile gelen componentlere bağlı kanılamayacağı için genişleyebilir bir mekanizma sağlanmalıdır.(CAB Extansions- Adapter- Factory Pattern)


Tabii bu ihtiyaçlar bizim Use Case güdümlü yazılım mimarimiz için özel ihtiyaçlardır. Birde tüm uygulamalar için ortak ihtiyaçlar vardır. (Application Blocks)

  1. Hata yönetimi

  2. Log

  3. Veri erişimi

  4. Güvenlik

  5. Şifreleme

  6. Veri doğrulama

Tüm bu uygulama bloklarının da kendi uygulamamız içerisinde kullanmamız gerekmektedir. Belki bu uygulama bloklarına kendi iş ihtiyaçlarımıza göre bir takım yeni özellikler eklemek veya yeni bir uygulama bloğu oluşturmak gerekebilir. (Application Block Software Factory)


Bu makalede SCSF-CAB konusuna giriş yaptık. CAB Use-Case güdümlü programlamayı nasıl yerine getirdiğine dair konuştuk. CAB uygulamasının ihtiyaçlarını gördük. Yukarıda ki sıraya göre bu yazılım ihtiyaçlarını CAB nasıl yerine getirmiş P&P serisinde anlatmaya çalışacağım. Bu seri makaleler içinde öğrenme yöntemimiz tümden gelim olacaktır. Perşembe günü biraz uzun bir makale ile benim mühendislik harikası olarak değerlendirdiğim Injection Pattern ile görüşmek üzere.


24.08.2007

Emre COŞKUN

Http://www.emrecoskun.net/