Evet sevgili yazılımperver dostlarım, bir kaç yazımda da bahsettiğim üzere uzun süredir bir yandan geliştirmeye devam ettiğim Uygulama İzleme Yazılımı (Application Monitoring Tool, AMT)’na ilişkin ilk çalışabilir ve anlamlı sürümü ilgili Gitlab reposunu dahil ettim. İlgili repoya aşağıdaki adresten ulaşabilirsiniz:

https://gitlab.com/yazilimperver/applicationmonitoringtool

Bu sürüm ile birlikte bu yazılım için planladığım/öngördüğüm temel kabiliyetleri eklemiş oldum. Tabi bu uygulamaya ilişkin yazılarıma sene başında başlamış ve dört yazı ile devam ettirmiştim. Konuya daha iyi vakıf olabilmek için, eğer okumadıysanız aşağıda yazılarıma göz atmanızı şiddetle tavsiye ediyorum. Ama ilerleyen satırlarda, bu yazılarda, nelerden bahsettiğimi kısaca sizlere aktaracağım.

Uygulama İzleme Yazılımı

Uygulama İzleme Yazılımı 2 – Başlangıç

Uygulama İzleme Yazılımı Serisi 3 – Utility, Birim Testler, Sürekli Entegrasyon

Uygulama İzleme Yazılımı 4 – Qt Ayarlamaları

Öncelikle bu yazılımı geliştirmekteki amacım neydi ona isterseniz bir göz atalım. Burada, hiç eğip bükmeden, hatta “paraphrase” bilen yapmadan, aşağıya kopyala yapıştır ile ilk yazımdan ekliyorum. İlaveten ortaya koyduğumuz zihin haritasını da ekliyorum, keza, sürekli entegrasyon ve diğer bir kaç hususu orada ifade etmişim:

Fark edeceğiniz üzere, bu yazılımı geliştirmek istememde öne çıkan amacım daha önce bir kaç kere yazılarımda bahsettiğim (ya da planladığım) teknolojileri (CMake, vb) ve benzeri kavramları birinci elden kullanarak deneyimlemek, göstermek ve sizler ile paylaşmak. Bunu da elbette, C++ ve QT/QML kullanarak yapıyor olacağız.

Sanırım amacımı gayet net bir şekilde ortaya koymuşum 😀 Şunu da, söyleyebilirim ki, yukarıda sizler ile de paylaştığım dört yazı ile birlikte bu amacıma büyük bir oranda gerçekleştirdiğimi düşünüyorum, ama bitti mi, hayır. Şimdi bu, dört yazımda nelere değindiğimi kısaca sizler ile paylaşayım:

• İlk yazımda: Genel motivasyon ve amaç
• İkinci yazımda: Uygulamanın genel proje dizin yapısı, gitlab ve alternatifleri, birden fazla projeden oluşan uygulamalar için CMake yapılandırması ve önemli komutları,
• Üçüncü yazımda: Sürekli entegrasyon nedir, önemli noktaları,  birim testler (ve CMake ile kullanımı), CMake’e ilişkin bir takım notlar, “Utility” kütüphanesi ve size sundukları,
• Dördüncü yazımda: Ağrılıklı olarak QT/QML ve CMake kullanımı, proje yapısı, alt projeler (her ne kadar altları o zaman dolu değilse bile işlevleri belliydi), QT ile dinamik kütüphane kullanımı.

Peki, bu ve sonraki yazılarımda neye değineceğim. Bu yazımı açıkçası bir hatırlatma gibi görmenizi rica ediyorum. Onun için çok uzun tumayacağım. Bunun ile birlikte genel yazılım mimarisine göz atacağız, bunu yaparken de, “Kapsam Diyagramı”‘larından bahsedeceğim. Öncelikle, geliştirdiğim birçok yazılımda kullandığım bağlam diyagramlarından bahsetmek istiyorum.

Bağlam diyagramları, bir diğer ifade ile, sistem bağlam diyagramları, bir sistem ya da sistemin parçası ile çevresi arasındaki etkileşimi göstermek için kullanılan diyagramdır. Bazı kaynaklarda seviye-0 veri-akış (Data Flow) diyagramı olarak da adlandırılabilmektedir. Eğer sizler de, birçok dış sistem ile haberleşen yazılımlar geliştiriyorsanız, yazılımınız ve bu sistemler/yazılımlar ile olan arayüzler ve alınıp/verilen verilerin gösterilmesinin ne kadar kritik olduğunu bilirsiniz.

Bağlam diyagramlarını çizmek için ihtiyaç duyacağınız iki önemli husus var:

1. Öncelikli olarak, sistemin/yazılımın etkileşim halinde bulunduğu dış unsurları tespit etmeliyiz,
2. Sonrasında ise, bunlara ilişkin veri akışını belirlemeliyiz.

Peki bağlam diyagramları bize neyi sunar:

• Öncelikli olarak üst seviyede, uygulama/sistemimizin sınırlarını ve kapsamını, etkileşim halinde bulunduğu dış unsurlar ile sunar,
• Genel olarak çok teknik olmadığı için kolay bir şekilde anlaşılabilir,
• Yukarıda, ihtiyaç duyuluan iki husus belirlendikten sonra kolay bir şekilde çizilebilir,
• İhtiyaca göre detaylandırılabilir,
• Gerek yazılımcı gerekse diğer farklı paydaşlar tarafından kolayca kullanılabilir.

Aşağıda, wikipedia’dan alınan bir örneği görebilirsiniz:

Ben genelde yazılım mimarilerimi belirlerken ve dokümante ederken Simon Brown’un C4 yaklaşımını takip ediyorum. Daha önce bazı yazılarımda da bu yaklaşımdan bahsettiğimi hatırlıyorum (bu konuya da ayrıca bir yazı ayırmak iyi fikir olabilir 😉 ) En azından bu konu ile ilgili iki kitabından bahsetmişimdir (elektronik kopyalarını satın alarak muhakkak okumanızı tavsiye ederim). Bence oldukça sade ve kullanışlı bir yaklaşım. Temel olarak yazılım mimarinin göreselleştirilmesini 4 temel seviyede yapmakta. Bunlar:

• Seviye 1: Sistem Bağlam Diyagramları
• Seviye 2: Konteyner Diyagramları
• Seviye 3: Bileşen Diyagramları
• Seviye 4: Sınıf Diyagramları

İsminden de anlaşılacağı üzere seviye 1, benim burada bahsettiğim bağlam diyagramları ile birebir ilintili. C4 içerisinde de, bu diyagram büyük resmi göstermek ve merkezde bulunan yazılım sistemi ile dış kullanıcı ve diğer sistemlerinin etkileşimi göstermektedir. Burada da vurgu, bu diyagramın genel bir kuş bakışı görüntü ve teknik olmayan insanlar için de girdi olabilmesidir. Aşağıda da, C4 sayfasından bu diyagrama ilişkin bir örnek görebilirsiniz:

Şimdi gelelim uygulama izleme yazılımımız için hazırlayacağımız bağlam diyagramına.

Çok da karmaşık değil ne dersiniz? Bu yazılım için olan diyagramın, oldukça sade olacağını eminim tahmin etmişsinizdir 🙂

Evet, gite dahil ettiğim son kod ile birlikte AMT ve AMT’yi test etmek için eklediğim istemci test uygulamasını (ClientTestApp) çalıştırdığınızda aşağıdaki gibi bir QML ve bir QT uygulaması görüyor olacaksınız. Bunların detaylarına, etkileşimlerine ve kullanımına sonraki yazılarımda değineceğim, şimdilik sadece ağızlarınıza bal çalayım 😀

Şimdi gelelim, Uygulama İzleme Yazılımımızın (AMT) mevcut haline ilişkin sınıf diyagramımıza:

Daha önce de ifade ettiğimi gibi, AMT yazılımı, QML uygulaması. Aşağıda sizler ile paylaşacağım HostBackendApp sınıfı aslında bu QML (main.qml) içerisinde yer alıyor.

Bu yazımı kısaca bu sınıfların neler yaptığından bahsederek tamamlayacağım, sonraki yazılarda daha detaylı bu sınıflara girebiliriz (elbette detaylar için sizleri gitlab reposuna hemen de alabiliriz, tabi ki yorumlar kısmından ya da mail ile sorularınızı iletebilirsiniz)

• HostBackendApp:
  • Aslında AMT’nin kalbini oluşturuyor ve genel konteyner sınıf olarak da değerlendirilebilir,
  • Yukarıdaki figürde görüneceği üzere temel işlevleri kordine ediyor,
  • Bu sınıf aslında, QML (main.qml) içerisinde yer alıyor,
• ClientListModel ve ClientDataModel:
  • C++ ile QML dünyaları arasında istemcilerin ve bu istemcilere ilişkin verilerin QT dünyasındaki Model/View (QAbstractTableModel) altyapısına göre paylaşmamıza olanak sağlayan sınıflar,
  • Bunlar sayesinde, C++ tarafından beslediğimiz veriler doğrudan QML arayüzünde görüntülenebilmektedir,
  • Bu sınıflar sizler için de daha önceli QML/C++ entegrasyon yazımda bahsettiğim etkileşim ihtiyacı için referans olabilir,
• IMsgProtocol, DefaultCommProtocol:
  • İstemciler ile AMT arasında için kullanılabilecek olan mesaj protokolünü temsil eder. Bir diğer ifade ile, haberleşme kanallarından gelen ham byte verilerini anlamdırmamızı sağlar,
  • IMsgProtocol buna ilişkin arayüz ve DefaultCommProtocol de ilk etapta tanımladığım basit bir mesaj protokolü,
  • Bu bize ne sağlıyor? Uygulamanın genelini değiştirmeden farklı mesajlaşma protokollerini kullanabilmemize olanak sağlıyor (ki buna ilişkin ileride örneklere bakıyor olacağız),
  • Benzer şekilde bu protokol, haberleşme protokolünden de bağımsız ve habersiz,
• ConnectionBase, DefaultUDPConnection:
  • İstemciler ile AMT arasında için kullanılabilecek olan haberleşme protokolünü temsil eder,
  • ConnectionBase buna ilişkin temel sınıf ve DefaultUDPConnection de ilk etapta tanımladığım basit ve UDP tabanlı bir haberleşme protokolü,
  • Bu bize ne sağlıyor? Uygulamanın genelini değiştirmeden, mesajlaşma protokolünü değiştirmeden farklı haberleşme protokollerini (TCP, seri kanal) kullanabilmemize olanak sağlıyor,
  • Haberleşme protokolü her ne kadar, gelen ham veriyi anlamlandırmak için bir mesajlaşma protokolüne ihtiyaç duysa da, spesifik bir protokole bağımlı değil,
  • Bu ve önceki sınıflar için özel bir yazı yazıyor olabilirim 😉
• ConnectedClientList, ConnectedDataList, CollectedData:
  • İsimlerinden de anlaşılacağı üzere, bu sınıflar, AMT uygulamasına kayıt olan istemci, onların kaydettiği veri tipleri ve bu veri tiplerine ilişkin verileri tutan ve yöneten sınıflardır,
• IMsgListener, DecodedMsgListener:
  • İlki, haberleşme kanalları üzerinden gelen ve bu kanaldan alınan ham verilerin dinleyicilere aktarılması için kullanılacak olan arayüzdür,
  • İkincisi ise, ilk arayüz aracılığı ile alınan verileri uygulamaya, tanımlı mesaj nesnelerine (BaseMessage) dönüştürülerek aktarılmasından sorumludur.

Evet, sevgili yazılımperver dostlarım, uygulama izleme yazılımı (AMT)’ye ilişkin önemli bir aşamayı daha geçmiş oluyoruz. Bu hali ile artık basit bir örnek kodtan, elle tutulur bir uygulamaya dönüşmüş oldu. Buradan bu uygulamayı alıp bambaşka yerlere taşımak sizlerin elinizde. Önümüzdeki yazılarda bunu birlikte yapıyor olacağız ama artık AMT için de tünelin sonu görünmeye başladı, umarım faydalı olur. Bir sonraki yazımda görüşmek üzere, bol kodlu günler.

NOT: AMT’nin gitlab pipeline’ınında çıkan hatayı çözebilecek arkadaşlara benden şimdiden teşekkür. Her ne kadar VS2019 ile sıkıntı olmadan çalıştırabilsem de, bir şekilde Docker üzerinde alet derlenmiyor.