Özet. Olay yolu (Event Bus), yazılım bileşenleri arasında Yayımcı-Abone (Publish-Subscribe) tarzına uygun iletişim sağlayan ve bunu yaparken yazılım bileşenlerinin birbirlerinden haberdar olmasını gerektirmeyen bir yapıdır. Bağımlılık iletimi (Dependency Injection) de bileşen bağımlılıklarının dışarıdan iletilerek bileşenlerin yapılandırılabilmesine olanak sağlar. Mimarisi olay yolu üzerine kurgulanmış bir yazılımda bağımlılık iletimi kullanılması durumunda, bu iki yaklaşımın etkileşimi, denetim altına alınması gereken bir husus haline gelir. Bu çalışma kapsamında, sözü edilen denetimin yazılım geliştirme süreci içerisinde nasıl ele alınabileceği tartışılmıştır. Bu bağlamda, geliştirdiğimiz derinlik ölçüm sonarı (iskandil sistemi) grafiksel kullanıcı arayüz (GKA) yazılım mimarisine temel olan “Yolcu” çerçevesi ve ilgili proje kapsamında edinilen kullanım deneyimleri de makale kapsamında verilmiştir. Anahtar Kelimeler. Bağımlılık iletimi, Olay tabanlı yazılım mimarisi, Yeniden Kullanım, Olay yolu.
Yazılım dünyasında üretkenliğin artırılması için ortaya konulan en temel
yöntemlerden biri yeniden kullanımdır. Yeniden kullanımın sistematik olarak desteklenmesi
için yazılım bileşenlerinin tasarım ve geliştirim süreçlerinin, bu temel üzerine
kurulması gerekir. Bu bağlamda yazılım mimarisi, yeniden kullanımı garanti altına almak
(sistematik hale getirmek) için bir araç olarak görülebilir. Yeniden kullanım odaklı bir
mimari tasarımda, nesne yönelimli tasarımın temel ilkelerinin (SOLID) gözetilmesi
gerektiği söylenebilir [
Bu makale kapsamında ele alınan durum çalışması, Aselsan bünyesinde tanımlı,
derinlik ölçüm sonarı grafiksel kullanıcı arayüzü yazılımı geliştirme sürecini
kapsamaktadır. İlgili yazılım, belirli bir proje ailesi (KULAÇ) için ortak kullanılması
öngörülerek geliştirilmiştir. Yazılım geliştirme ve analiz sürecinde yetenek tabanlı
bileşenler (ve yetenek gereksinimleri) çıkartılarak, yeni gelecek benzer projelerde de
bu varlıkların yeniden kullanılması hedeflenmiştir. Burada kurulması (o tarihte)
öngörülen altyapı, kısmen [
Makalenin geri kalanı şu şekilde düzenlenmiştir: İkinci bölümde yeteneklerin varlıklarla nasıl ilişkilendirildiği ve yazılım gereksinim belgesi üzerinde nasıl ifade edildiği verilmiştir (Problem alanının çözümlenmesi). Üçüncü bölüm, bileşenler arası etkileşimlerin mimari seviyede nasıl ele alınacağı tartışılmış ve hemen ardından dördüncü bölümde bu çalışmanın sonucu olarak ortaya konulan yeniden kullanılabilir çerçevenin (Yolcu) detayları ve bileşenler arası etkileşimlerin bu çerçevede nasıl ele alındığı belirtilmiştir. Çalışmanın sonuç ve değerlendirmesi de beşinci bölümde verilmiştir. 2
Yazılım bileşenlerinin etkin yeniden kullanımı için gereksinim yönetimi önemli bir
unsurdur [
Şekil 1. KULAÇ GKA Yetenek Modeli Yetenek Bilgisi (Yetenek Kolonu): Gereksinimlerin ilgili olduğu yetenek(ler), gereksinim yönetim aracı (Doors) üzerinde tanımlı şablona bir özellik olarak eklenmiş ve yeni bir kolonda verilmiştir (bkz. Şekil 2). Bu sayede gereksinimler yetenekler üzerinden sorgulanabilir hale gelmiştir (Doors’un sorgulama altyapısı kullanılarak).
Sürecin temel aldığı şablon J-STD-016 standardına dayanmaktadır [
Şekil 2. Doors Şablonuna Eklenen Yetenek Kolonu2 Yetenek gereksinimlerinin açıkça ifade edilmesi, hem bu yetenekleri sağlayan bileşenlerin gereksinimlerine kolayca erişebilmek, hem de bileşen bağımlılıklarını çıkarabilmek adına yarar sağlamıştır. Yetenek modelinin bir diğer faydası da sıradüzensel bağımlılıkların, gereksinim gerçekleştirim önceliklerini belirlemek için kullanılabilmesidir. Örneğin yetenek ağacındaki her bir yaprak düğümün (leaf node) gerçekleştirim önceliği kendisini köke (temel yetenek) bağlayan düğümlerin gerçekleştirim önceliğine eşit veya düşük olmalıdır. Aynı yorum, doğrudan gerektirme (“requires” türü) bağımlılıkları için de yapılabilir.
Yetenek modellerinin gerçekleştirimine ilişkin önerdiğimiz yaklaşım, [
Şekil 3. Yetenekten Gerçekleştirime Yarı Otomatik Geçiş [
Yazılım
Nesne yönelimli bir mimaride, yazılım bileşenleri arasındaki etkileşimler iki temel
sınıfta ele alınabilir; olgu yaratma ve iş akışı çağrıları:
Olgu Yaratma: Bir nesne, bağımlı olduğu soyutlama (Ör: Arayüz tanımı)
üzerinden bir nesnenin olgusunu yaratamaz. Ayrıca nesnelerin olgularının yaratılması
soyutlama üzerinden yapılsa da nesneye doğrudan bağımlılık oluşturur. Bu durum,
“Soyutlamalara bağımlı ol, gerçekleştirimlere bağımlı olma” ilkesinin ihlali
anlamına gelir [
Olay tabanlı bir mimaride çağrıyı yapan ve çağrıya cevap veren bileşenler arasında doğrudan bir bağımlılık yoktur. İş akışı, “Olay Yolu” üzerinden iletilen “olay”lar ile gerçekleşir (bkz. Şekil 4). Olay yolu, yayınlanan bir olayı, o olayı dinleyen tüm abonelere iletir (Yayımcı-Abone). Bu yaklaşımda, her ne kadar yazılım bileşenlerinin birbirlerine doğrudan bağımlılıkları olmasa da iletişim için ilgili olay türlerini bilmeleri gerekir (Bileşenler olay türlerine bağımlıdır). Bu bağlamda, birbirlerinin arayüzlerini bilmeyen bileşenler arasındaki iletişimi sağlayabilmek için ortak bir dilin tanımlanması ihtiyacı doğmaktadır. Bu dil, olay yolu üzerinden gidip gelecek nesne türlerinin (olay) belirlenmesi ile tanımlanır.
Şekil 4. KULAÇ GKA Yazılımında Olgu Yaratma (A) ve İş Akışı (B) Bileşen Etkileşimleri Olay tabanlı olmayan bir yapıdaki her farklı yöntem çağrısı, olay tabanlı yapıda yeni bir olay türüne karşılık gelmektedir. Bu durum, her ne kadar küçük ölçekli yazılımlar için kabul edilebilir olsa da yazılım ölçeği büyüdükçe çok sayıda olay türü tanımlanması, bazı yan etkilere yol açabilir. Bunlara örnek olarak kodun idame edilebilirliğinin azalması ve hata ayıklamanın zorlaşması verilebilir. Bu problemlerin oluşmasını önlemek adına önerilen çerçevede olay kullanımı kurallarla sınırlandırılmıştır (bkz. 4. Bölüm). 4
Yolcu çerçevesi, veri paylaşımı ve iş akışı tetikleme altyapısı olarak olay yolu kullanımını benimseyen yazılımlar için geliştirilmiş bir çerçevedir. Yolcu çerçevesi kullanılarak geliştirilmiş bir uygulamanın merkezinde üç temel unsur yer alır; “Olay Yolu”, “Kullanıcı Arayüzü Yönetici” (KA Yönetici) ve “İş Yönetici”. Olay yolu, platform ya da kullanıcı kaynaklı olayların ilgili birimlere (aboneler) iletilmesinden sorumludur. “Kullanıcı Arayüzü Yönetici”, yazılımın kullanıcı ile olan etkileşiminden sorumlu bileşenler (veri girişi, veri görüntüleme), “İş Yönetici” ise bir veya birden çok kullanım durumunun (senaryo) gerçekleştirilmesinde rol oynayan, iş mantığının gerçeklendiği ya da alt katman soyutlamalarının kullanımı ve yönetiminden sorumlu bileşenlerdir.
Yolcu çerçevesi temelde çok katmanlı bir grafiksel kullanıcı arayüzü uygulama geliştirme altyapısı sunar (bkz. Şekil 5). En üst seviyede kullanıcı arayüzü katmanı, altta iş mantığı katmanı ve aralarında olay tabanlı iletişimi sağlayan olay yolu bulunur.
Şekil 5. Katmanlı Mimari ve Yolcu Çerçevesinin Yeri Olay yolu için olayı yayınlayan ya da dinleyen yöneticilerin hangi katmanda olduğunun ya da iletişimin hangi yönde olduğunun bir önemi yoktur. İki yönde de olaylar kaynağı ya da hedefi sorgulanmadan iletilir. İletişim yönü için bir kısıt olmaması, gerçekleştirim sırasında döngüsel bağımlılık kurulmasına neden olabilir. Bu ve benzeri sorunların önüne geçmek için Yolcu çerçevesi, yazılım katmanları ve bileşenler arasındaki iletişimi sınırlandırmaktadır. İzin verilen bileşen etkileşimleri ve bu etkileşimlere dair açıklamalar aşağıda verilmiştir:
Şekil 6. Yolcu Çerçevesi Bileşen Etkileşim Kuralları 1. Kullanıcı Arayüz (KA) yöneticilerin yayınladığı olaylardır. Bir iş akışı başlatan kullanıcı girdileri (Ör: Kullanıcının bir menü düğmesine basması), olay olarak yayınlanır. Bir KA yönetici başka bir KA yöneticiye doğrudan erişmez ya da kullanıcı girdilerini ifade etmek için tanımlanmış olayları dinleyemez. KA yöneticilerin kullanım durumları kapsamında yönetim sorumluluğu, iş yöneticilere devredilerek, KA katmanındaki bileşen bağımlılıkları ortadan kaldırılmaya çalışılmıştır. 2. İş yöneticilerin dinlediği olaylardır. İş yöneticiler, kullanım durumu başlatan KA olaylarını ya da diğer iş yöneticilerin yayınladığı olayları dinlerler. 3. KA yöneticiler, iş yöneticilerin yayınladığı olayları dinlerler. Bunlar bir kullanım durumu kapsamında alt iş adımları olabileceği gibi alt katman soyutlamalarından sorumlu iş yöneticilerin yayınladığı olaylar (DDS verileri, seri kanal girdileri vb.) da olabilir. 4. İş yöneticilerin yayınladığı olaylardır. İş yöneticilerin yayınladıkları olaylar hem diğer iş yöneticileri hem de KA yöneticileri ilgilendiriyor olabilir. 5. Kullanım durumu alt adımları doğrudan yöntem çağrısı ile yapılır (zaman uyumsuz olarak yayınlanması gereken bir olay varsa yine yayınlanabilir). Bu bağımlılıklar, arayüzler üzerinden ve bağımlılık iletimi ile (bkz. 3. Bölüm) kurulduğundan, çalışma zamanında KA yönetici gerçekleştirimini değiştirmek de mümkündür. 6. Zaman uyumlu işletilen kullanım durumu adımlarında bir iş yönetici diğer bir iş yöneticiyi doğrudan kullanabilir. Bu bağımlılıklar da yine bağımlılık iletimi yöntemi ile kurulur.
KULAÇ proje ailesi için GKA yazılımı geliştirme işleri kapsamında ortaya konulan ve bu makalede detayları verilen yaklaşımlar ile aşağıdaki kazançlar sağlanmıştır: Yeniden kullanılabilir varlıklar (bileşen ve gereksinimler), yetenek tanımları ile ilişkilendirilerek, üst seviye bir soyutlama ile projeler arası benzerliklerin ele alınabilmesi için ortam hazırlanmıştır. Toplam 316 gereksinim maddesi, 24 yetenek ile ilişkilendirilmiştir. Bu gereksinimlerin 199 adedi temel yetenek ile ilişkilendirilmiştir. Proje ailesinin büyümesi ile yetenek sayısının artacağı ve temel yeteneğin küçüleceği öngörülmektedir. Bileşenlerin olgu yaratma kodları bağımlılık iletimi çerçevesi, iş akışı çağrıları da olay yolu çerçevesi tarafından ele alındığından iş mantığı kodunda önemli bir sadeleşme elde edilmiştir. Ayar ve akış denetim kodlarının (“Boilerplate” kodlar) ortadan kalması, daha okunur ve daha kolay yönetilebilir bir kod yapısı oluşturulabilmesine olanak tanımıştır (bkz. Çizelge 1: KGBYKB, bir su üstü KULAÇ projesi için kodlanmış eski GKA yazılımı. KAYKB, yeni yaklaşımla kodlanmış, hem su üstü hem de su altı projesi için gerekli yeteneklerini kapsayan ortaklanmış GKA yazılımı). KULAÇ KGBYKB (2011) 10.10% 10.03 285 45,133 4,057 88 850 6,798
KULAÇ KAYKB (2013) 16.10% 9.75 200 19,747 1,458 39 341 2,623 İlerleyen dönemde, sözü edilen kazançların başka proje ailelerinde de kullanılabilmesi adına geliştirilen Yolcu çerçevesi ve kullanım ilkelerinin diğer proje ekipleri ile de paylaşılması öngörülmektedir. 3 Ölçümler için “CodePro Analytix” kullanılmıştır. Ölçüm isimleri, tekrarlanabilirliği sağlamak için araçta olduğu haliyle (İngilizce) verilmiştir. Daha ayrıntılı bilgi için: http://developers.google.com/java-dev-tools/code