Alt prosesli yazılım mimarisi

[G.Sungur]

Teşekkürler Zafer Bey. AMC ve OOP mimarileri üzerine yoğunlaşacağım.

[G.Sungur]

Zafer Bey Merhaba,

Bu posttan sonra OOP üzerine çalışmalar yaptım. Sizin tecrübelerinize istinaden bir kaç sorum olacaktı. Cevaplayabilirseniz memnun olurum. 

-G# OOP alt yapısını kullandığınızı söylemiştiniz. GOOP4(GDS) alt yapısına göre neden G# alt yapısını tercih ettiğinizi öğrenebilir miyim?

-Ayrıca eskilerden geliştirilmiş dqGOOP alt yapısını buldum. Ancak bu toolkiti sitesinden indiremedim. Siz bu yapıyı kullandınız mı ve elinizde bu toolkit mevcut mudur?

-Son olarak bu soru OOP ile alakalı değil ama kafama takılan bir konu araştırmama rağmen pek bir şey bulamadım. Global Variables run-time engine de çalışıyor mu? Yapmış olduğum bir uygulamada çalışmamıştı. Belki exe oluştururken bir şeyleri atlamış olabilirim.

Şimdiden teşekkürler.

İyi çalışmalar.

[Zafer.Depe]

Merhaba,

*GOOP4(GDS) de kullanmıştım. Hatta  ilk önce bu kütüphaneyi kullanmıştım. Ancak G# kütüphanesindeki metotlara bakarsanız daha esnek ve çeşitli olduğunu görebilirsiniz. GOOP4, G#'ın daha hafif sürümü gibi geldi bana açıkçası. Aynı temel üzerine oluşturulmuş iki kütüphane diyebiliriz. (GOOP vs G#...) Şu an ikisi de yüklü ve menüleri karma olarak kullanıyorum. Ama nesneleri G# olarak oluşturuyorum.

*Neden eski bir kütüphane indirmek istediğinizi anlamadım. Zira G# (GDS) üzerinde çalışmalar ve geliştirmeler devam ediyor. Yeni sürüm LV desteklerinde de sorun yok. Eski bir sürümde karşılaşacağınız sorun yada kısıtlama geliştirmenizde engel çıkarabilir. Projeyi hangi alt yapı ile kurduysanız onun üzerine devam etmeniz gerekecek. Bir sıkıntı çıkarsa her şeyi en baştan yapmak durumunda kalabilirsiniz.

*Global değişkenler elbette run-time engine üzerinde çalışır. Projeyi exe yaparken bu değişkenleri eklemeniz ve otomatik deploy etmeniz gerekiyor sanırım. İlk başladığım zamanlar hariç artık global değişken kullanmadığım için şu an nasıl kullanılıyor bilemedim açıkçası 🙂 Bence global değişken yerine FGV (functional global variable) kullanın. Global değişkenler "race condition"a açıktır ve farklı iş parçacıkları üzerinde takibi zordur. FGV'ler daha esnek ve kontrollü oluyor. Tabiki mimari kullandığınızda kolay kaçış yolu dışında bu ikisine de ihtiyacınız yok 🙂

[G.Sungur]

Evet haklısınız. Mimari üzerine yazılım inşa etmeye başladıktan sonra benimde GV ve FGV ihtiyacım kalmadı. 🙂

Eski kütüphane bana daha sade anlaşılır geldi. OpenGOOP ve GOOP eski sürümlerine alternatif performans açısından geliştirilmiş. Bir örnek uygulamada gördüğüm için bu kütüphaneyi araştırdım. LV yerel fonksiyonları kullandığı için ileri ki sürümlerde sorun çıkarır mı bilmiyorum. Ancak dediğiniz gibi yeni kütüphaneye odaklanmak daha doğru olacaktır. Peki Zafer Bey G# alt yapıları için özellikle kullandığınız performansı iyi tasarım kalıpları (Design patterns) var mıdır?

[Zafer.Depe]

Mimariyi kurmadan (Desing Pattern) e geçmişsiniz 🙂 Eğer başka dillerde tecrübeniz varsa ilk işinizde dahi böyle bir seçim yapmanız doğru bir yol. Ben orada bulunan hazır patternlerden birini kullanmıyorum. En son projemde MCV (Model-Control-View) uyarlaması yaptım, onu kullanıyorum. Actor Framework'ün "Actor Core" kısmında ara yüz tasarlamamak ve controlleri Actor nesnesine eklememek için kolay bir çözüm oldu. Arayüzü ayrı bir nesnesden kalıtıyorum ve PreLaunch Init kısmında ilgili arayüzü yüklüyorum. Böylece bağımlılık da azalıyor. MCV için The Controller-Model-View principle videosuna bakınız. Dr.Powell'ın örneği de olacaktı sitede.

[G.Sungur]

Az zamanda çok iş yapabilmek için bu Zafer Bey 🙂 Çalışmalara başlayacağız bakalım neler olacak. Önerileriniz için tekrar teşekkür ederim. İyi çalışmalar. 

[Zafer.Depe]

Rica ederim, çalışmalarınızda başarılar. Başka destek isterseniz de yardımcı olmaya çalışırım 🙂

[G.Sungur]

Teşekkür ederiz. İleride illaki bazı sorunlar çıkacaktır olursa yine bu post üzerinden sorarım 🙂 

[G.Sungur]

Zafer Bey Merhaba,

Size dinamik VI lar hakkında bir sorum olacaktı. Dinamik olarak çağrılacak bir VI var. Bu VI asenkron olarak farklı sub panellerde çalıştırılması gerekiyor. Buraya kadar sıkıntı yok bildiğiniz üzere Open VI Reference 0x08 flagı ve reentrant kullanılarak farklı sub panellerde çalıştırılıyor. Ancak bu VI fonksiyonunun 2 ayrı sub panelde de farklı bir arayüz tarzında gösterilebilme ihtimali var mıdır? Farklı arayüzden kastım kontrol indikatör vs. değiştirilmiyor da mesela boyutları büyütülüyor konumları değiştiriliyor olarak düşünebilirsiniz. Bu VI iki farklı sub panelde farklı arayüz boyutları ile lazım yani. Hangi sub panelin buyuk arayüzü hangisinin küçük arayüzü alacağı da belli. Aslında bu olay farklı iki VI tasarlanarak çözülebilir ancak ben tek VI kullanarak bu işi yapabilir miyim diye merak ediyorum. Ayrıca VI'ı çağırmadan önce VI script fonksiyonları kullanılabilir diye düşünüyorum ama daha kolay yolu olabilir. Bu konudaki fikrinizi öğrenebilir miyim? Teşekkürler.

[Zafer.Depe]

Öncelikle 0xC0 bayrağı kullanın. Hem call&forget (0x80) hem de simultaneous calls on reentrant (0x40) çalıştırmanızı sağlar. Aynı VI'ı çağırdığınız için görsel fark ancak tasarımda yapacağınız değişikliklere bağlıdır. 0xC0 bayrağı ile çağırdığınızda aynı VI'ın tam kopyaları oluşur. Aynı anda birden çok noktadan çağırırsanız birden çok kopyanız olacak demektir. Yalnız her çağrıda ilk değer atamaları (initialize) veya sonlandırma (finalize) bölümleri yapmazsanız arayüz bir sonraki çağrıda eski haliyle gelebilir.

*Aynı VI için birden çok arayüz yapmak için çeşitli yöntemler sunulabilir;

-Çok kaba bir yöntemle arayüzün farklı çağrıları için denetimleri (propertiler ile) ayarlayan birden çok stil oluşturabilirsiniz. Bunu arayüzü açmadan önce uygularsanız farklı görünümlü ara yüzleriniz olur.

-Sekmeler şeklinde tasarlayabilirsiniz. Ama bu yine sabit bir yapı oluşturur. Bağlı olduğu veri bloğu ilişkisiz veriler içermiyorsa pek ihtiyacınız olmaması lazım.

-Arayüzü dinamik değişecek şekilde tasarlayabilirsiniz. Bu daha ziyade yerleşim (boyutlandırma) için uygun olur. Yatay ve düşey ayırıcılar (splitter) kullanarak yapabilirsiniz. Oldukça kullanışlı, görselliği olan ve farklı çözünürlüklere uyarlanabilen arayüzler için ayırıcı kullanmak olmazsa olmazdır.

-Üst sınıftan kalıtacağınız alt sınıflarla farklı arayüzler tasarlarsınız. Ama sanırım istediğiniz bu değil.

-İç içe subPanel kullanarak daha dinamik ara yüzler tasarlayabilirsiniz.

***Benim tavsiyem iç içe panellerden oluşan ve boyutlarını panele göre ayarlamak istediğiniz denetimleri ayırıcılar (splitter) ile sınırladığınız ara yüzler hazırlamanız yönünde. Otomatik büyüme/küçülme ve sabitleme ayırıcılarla mümkün.

VI Script run-time engine üzerinde çalışmıyor maalesef. NI bu kütüphaneyi kodlama yaparken tekrarlanan kısımlar için kolaylık olsun diye ekledi. Run-time üzerinde dinamik VI oluşturabildiğimiz halde diğer nesneleri maalesef oluşturamıyoruz. İlerideki LV sürümlerinde ekleneceğini ümit ederek bekliyoruz 🙂