Yazılım Mimarileri-6. Mimari Dokümantasyon
Tasarlanan yazılım mimarisi dokümante edilir. Mimari dokümantasyon sistemin geliştirilmesi için temel oluşturur. Sistemde bulunan bileşenler bu bileşenler arası iletişim ve kalite öz niteliklerini karşılamak üzere seçilen tasarım kalıpları ve taktikler ile mimari kararlar ve gerekçeleri mimari dokümantasyon olarak görülür. Yazılımcılar için her zaman projenin angaryası olarak görülen bu bilgiler eğer yazılımcı kendisi sonradan ilgili projeye geldiyse eksikliği yada tutarsızlığı konusunda şikayet edilir. Temiz kod prensipleri ile okunabilir kodlar yazmak tabi ki sonradan gelen yazılımcı için kolay adaptasyonu sağlıyor fakat bu tek başına yeterli değildir.
Mimari dokümantasyonun detaylarına girmeden neden hazırlıyoruz bunu bilmekte fayda var:
Mimari dokümantasyon kullanılarak mimarinin analiz edilmesi sağlanır. Mimari kararlarda uyumsuzluk mevcut mu, seçilen yaklaşımlar gereksinimleri karşılıyor mu bu doküman kullanılarak eşdeğer gözden geçirme ve/veya daha sonra detaylı anlatılacak mimari ödünleşim yaklaşımı ile analiz edilir.
Mimari doküman aynı zamanda projenin paydaşları arasında iletişim için gereklidir. Mimari bileşenler üzerinden paydaşların kaygılarının ve kalite öznitelikleri gereksinimlerinin nasıl karşılanacağı anlatılır. Örneğin yerleştirme bakış açısı ile yazılım hedef ortamda nasıl çalışacak, güvenliği nasıl sağlanacak gibi sorular cevaplanır.
Yazılım mimari dokümanı yazılımı geliştirecek yazılımcılar, test mühendisleri ve özellikle ekibe yanı katılacak mühendisler için projeyi öğrenme yoludur. Bunun ötesinde hızlı bir personel geçişinin olduğu sektörde geliştirilmiş yazılımı daha sonraki yıllarda o yazılımda hata düzeltmek isteyen ya da yeni özellikler eklemek isteyen yazılım geliştiricileri için de referans olacaktır.
Mimari Gösterim
Mimari gösterim geliştirilen yazılımın statik ve dinamik ilişkilerini grafiksel olarak gösterme yöntemidir. Mimari gösterimde üç farklı yaklaşım vardır. Öncelikle standart olmayan kuralsız grafikler ile mimariyi ifade edebiliriz. Bu yaklaşımda genelde renklendirilmiş kutular ve bu kutularda açıklayıcı metinler yer alır.
Yarı kurallı gösterimde ise standart bir gösterim olmasına karşın anlamsal tanımlar tam olarak ifade edilmezler. UML yarı kurallı diyebileceğimiz bir yaklaşımdır. Bunun bir ötesi olarak resmi gösterimlerde matematiksel ifadelerle ihtiyaç kurallı olarak ifade edilir. Bu alanda ADL dediğimiz farklı Arcihtecture Desrciption Language dilleri önerilmiş olmasına karşılık, zorluğundan dolayı yaygın bir kullanım alanı bulamamıştır. Günümüzde UML en yaygın kabul edilen gösterim aracıdır.
Tasarladığımız mimaride bileşenlerimizi ve bu bileşenler arası ilişkileri belirmek üzere UML tabanlı tasarım araçlarından faydalanıyoruz. Modül yapıları ile geliştirme aşamasındaki bileşenler, kütüphaneler, dosyaları, sınıflar ve bunlar arası ilişkileri belirtiyoruz. Bileşen ve Bağlantı modeli ile çalışma zamanı görevler ve bunlar arası ilişkiler çizilir. Yerleştirme modeli ile çalışma zamanında görevlerin, veri tabanları ve dosyaların hangi bilgisayarlar üzerinden çalışacağını tanımlıyoruz.
Modül bakışı ile geliştirilecek yazılımın geliştirilecek birimleri ifade edilir. UML de bulunan paket ve sınıf diyagramları bu amaçla kullanılır. Yazılım paketleri ve bu paketlerin alt paketleri, bağımlı olduğu paketler paket dyagramı ile gösterilir. Daha detayda sınıf seviyesi tasarım gösterilecek ise sınıf diyagramları ile sınıfın metodları, diğer sınıflarla Bağlantı İlişkisi (Association), Genelleme/Kalıtım İlişkisi (Generalization/Inheritance), Bağımlılık İlişkisi (Dependency, Aggregation, Composition) gösterilir.
Bileşen diyagramları ise çalışma zamanındaki çalıştırılabilir (executable) ve kütüphane bileşenleri (DLL) ve bu bileşenler arası ilişkiler gösterilir. Bileşen diyagramları ile aynı zamanda bileşenler arası arayüzler sağlanan ve gereken arayüzler şeklinde belirtilir.
Son olarak yerleştirme bakışı ile sistemin hedef ortama kurulumu ile ilgili bilgileri içerir. UML de bulunan yerleştirme diyagramları ile ifade edilebilir. Sistemde yer alacak bilgisayarlar, ethernet anahtarları ve yazıcı gibi donanım unsurları ile bilgisayarlar üzerinde çalışacak yazılım bileşenleri gösterilir.
Bir sistemin kullanıcısının sistemle ve sistemin diğer sistemlerle etkileşimini ya da kendi iç akışlarını ardışık işlem (sequence) ve durum (state) diyagramları ile gösterebiliriz.
Hangi bakış açısının ekleneceğine karar verir iken bu dokümanı kimler kullanacak, hangi standartlara uymanız gerekecek, her bir paydaşın ihtiyacı olacak bilgiler nelerdir buna karar vermek gerekir.
Arayüz Tanımlama
Projelerde iç ve dış arayüzler de dokümante edilecek önemli mimari bilgilerdendir. Bu kapsamda veritabanı şemaları ve dağıtık uygulamalar arası paylaşılan veriler ya da servis arayüzleri benze şekilde dokümante edilmelidir. Veritabanı şemaları ve arayüz tanımları UML şemaları olarak gösterilebileceği gibi, IDL ve Graph-QL benzeri bir tanımlama dili ile de ifade edilebilir. IDL olarak tanımlanan arayüzler IDL derleyici tarafından yazılım geliştirilen programlama dillerinin yapısına çevrilir. Arayüz bilgileri bazen kod parçası yada tablo olarak ta ifade edilebilinmektedir. Bu arayüz veya veritabanı tanımlamalarında verinin ismi ve tipi bilgisinin yanında birimi(metre, mil, knot vb, referans noktası (yere göre, platforma göre), tipi (kartezyen, açı-mesafe gibi), limitleri (0–90 derece gibi) gibi bilgiler de yer almalıdır.
Mimari Kararlar ve Gerekçelerinin Dokümante Edilmesi
Mimari kararlar dokümante edilir iken gerekçeleri ile birlikte dokümante edilir. Eğer gerekçeler doğru şekilde yansıtılmaz ise aldığınız kararın doğruluğu çok sık sorgulanır. Bu sebeple hangi kalite öz niteliğini dikkate aldığınızı, hangi teknik ya da idari kısıtlar kararınızı etkilediğini ve bu koşullar altında neden kararınızın en uygun olduğunu (yafa iyileştirilebileceğini) belirtmelisiniz.
Mimari kararların dokümante edilmesi konusunda endüstride en olgun yaklaşım Mimari Karar Kayıtları (Architecture Decision Record-ADR) olarak bilinmektedir. Bu kapsamda her bir karar için aşağıdaki başlıklar doldurulur:
Başlık: Kararı ifade eden kısa bir başlık
Durum: Kararın mevcut durumu (Önerildi, Kabul edildi, Geçersiz gibi)
Bağlam: Hangi tasarım problemini çözmeyi hedefliyoruz.
Karar: Ne gibi bir tasarım kararı alındı, ne yapılması bekleniyor.
Sonuçları: Kararın ne gibi olumlu ya da olumsuz etkileri olabilir.
Ayrıca bu başlıklar dışında ilgili gereksinimler, ilgili tasarım kararları, tartışmalar gibi ek başlıklarla bu karar dokümantasyonu zenginleştirmek mümkündür. Bu kapsamda daha geniş bilgi ve taslaklara https://adr.github.io/ adresinden erişebilirsiniz.
Mimari Doküman Standartları
Mimari dokümantasyon konusunda en olgun standart ISO/IEC 42010–2011(Systems and Software Engineering — Architecture description ) standardıdır. Bu doküman içerisinde paydaşlar, paydaşların kaygıları, ve mimari bakışlar (viewpoints) belgelenir. En sık kullanılan bakışlar fonksiyonel, kod/bileşen, geliştirme, koşut zaman(görev/tread), yerleştirme, kullanıcı etkileşimi ve veri olarak sıralanmaktadır.
Savunma sanayi projelerinde sistem seviyesi tasarımı belgelemek üzere Sistem altsistem tasarım Dokümanı (SSDD: System/Subsytem Design Document) kullanılıyor. Bu tür projelerde yazılım mimarisi bu doküman içinde yer alır. Aynı yaklaşımda yazılım alt birim olan yazılım konfigürasyon birimlerine bölündükten sonra Yazılım Tasarım Dokümanı (Software design Description SDD) içinde belgelenir.
Çevik projelerde müşteri tarafından ayrıca tasarım dokümanı beklenmiyor ise bu tasarımın herkesin erişeceği bir ortamda bulunması önemlidir. Örneğin Confluence bu amaçla tercih edilen bir araçtır. Çevik projelerde Jira ile birlikte yaygın olarak Confluence kullanıldığı için tüm ekip üyelerinin erişeceği şekilde, kalite öznitelikleri senaryoları, mimari diyagramlar, mimari kararlar ve gerekçeleri, seçilen tasarım kalıpları ve diğer mimari kılavuz ve yönergeler burada yer alabilir.
