Yazılım mimarileri-5- Kalite Öznitelikleri Tabanlı Tasarım
Yazılım mimarisi geliştirme yöntemi olarak farklı metotlar önerilmektedir. Bunlar Bakış açısı, Mikrosoft yakalşımı, Rational birleştirişmiş süreci(RUP) ve Kalite Öznitelikleri Tabanlı Tasarım olarak listelenebilir. Biz Kalite Öznitelikleri Tabanlı Tasarım (Attribute Driven Design-ADD) metotunu irdeleyeceğiz.
Yazılım mimarisini yönlendiren ana kullanım durumları, kalite öznitelik senaryoları, mimari kaygılar ve proje sınırlamaları belirlendikten sonra mimari tasarım sürecine geçilir.
Öncelikle tasarım amacımızı iyi biliyor olmalıyız. Neden tasarladığımızı bilirsek nasıl tasarlayacağımıza daha iyi karar veririz. Teklif aşaması için tasarım yapıyor ise ön çözüm oluşturup fiyat tahmini yapılabilecek bir kırılım yeterli olacaktır. Belirli bir takvim ve maliyeti olan bir sistemde sonraki aşamalarda çok fazla değişiklik ve karar değişikliği şansınız olmayacaktır. Genç Yenilikçi ürün geliştiriyor iseniz öncelikle ürünün temel kabiliyetlerini ortaya çıkarıp zamanla gelişebilecek bir sistem tasarlamanız beklenecektir.
Tasarım amacı ile birlikte geliştirilecek sistemin ana fonksiyonel gereksinimlerinin net olarak belirlenmesi önemlidir. Bu fonksiyonel gereksinimler kullanım durumları ve/veya fonksiyonel gereksinim biçiminde tanımlanabilir. Ayrıca geliştirilecek sistemin süreklilik, performans ve değiştirile bilirlik gibi kalite öznitelikleri daha önceki bölümlerde anlatıldığı şekilde kalite senaryo şeklinde belirlenir.
Projenin sözleşmesel olarak kullanılması mecburi teknolojiler, entegre olması gereken sistemler gibi kısıtları yine mimari tasarıma girdi olarak kullanılır. Son olarak verinin doğrulaması, iletişim mekanizmaları, verinin yedeğinin alınması ve hata yönetimi gibi mimari kaygılar tasarım aşamasında dikkate alınacak önemli bir girdidir.
Kalite Öznitelikleri Tabanlı Tasarım öncelikle yukarıda bahsedilen girdilerin değerlendirilmesi ile başlıyor. Bu veriler değerlendirildikten sonra tekrarlı bir şekilde yazılım mimarisi tasarımı üst seviyeden başlanılarak detaylara inilir.
Tasarım problemi daha alt problemlere bölünür. Bu döngüde hangi problemi çözeceğine karar verirsin. Genelde ilk döngüde sistem mimarisinin ana iskeleti oluşturulur. Daha sonra bu iskeleti destekleyecek ek yapılar tasarlanır. İhtiyaç duyulması durumunda üçüncü ve devamındaki döngülerde hala çözüm üretilmemiş problemler çözümlenir.
Döngüde çözülen problemler genelde bilinen mevcut çözümler ile karşılanabilirler. Daha önceden çalıştığı ispatlanmış çözümlerin kullanılması daha hızlı ve az riskli çözüm üretecektir. Burada yaratıcılık sadece problemi doğru analiz edip mevcut çözümler içinde en uygun çözümü seçmektir. Yazılım mimari tasarımda çözüm araçları olarak mimari taktikler, mimari kalıplar, referans mimarileri ve başkaları tarafından geliştirilmiş bileşenler (örneğin ara katman yazılımları) kullanılır.
Tasarım yaklaşımların belirlendikten sonra bunlar arasından uygun olanın seçilmesi gerekmektedir. Bu kapsamda alternatifleri bir tablonun satırlarına koyup mimari kaygı ve senaryolara göre artısı ve eksisi değerlendirilir. Örneğin geliştireceğimiz bir yazılımı WEB uygulaması mı mobil uygulama mı yoksa masa üstü uygulamamı olarak geliştireceğiz. Bu konuda karar analizi yapabiliriz
Eğer karşılaştırma ile aldığınız karar konusunda emin değilseniz prototipleme yaklaşımını tercih edebilirsiniz. Prototipleme yaklaşımı zaman ve geliştirme olarak daha maliyetli olacaktır. Buna karşın prototipleme yaklaşımı ile projenin riskleri erken aşamada giderilmiş olur.
Bileşenlere fonksiyonel kabiliyetler atanır iken aynı zamanda kalite öznitelikleri gereksinimleri de atanır. Örneğin dış bir sistemden veriyi alacak modül için 1 saniyelik kabul edilen toplam gecikmesi 200 milisaniyesi atanabilir. Yazılım bileşenlere ayrıldığı durumda bu bileşenlerin tüm işi birlikte yapabilmek için koordine olmaları gerekecektir. Bu koordinasyonu belirler iken yapılacak işlerdeki sıralama, koşut yapılabilecek işlemler, yapılan işlemin tutarlılığı ve doğruluğu gibi parametreler dikkate alınır.
Bileşenler arası iletişim yöntemi bu iletişimin güvenilir mi yolla mı yapılacağı, senkron olup olmayacağı, toplam gecikme ve kapasitesi gibi parametreler dikkate alınarak uygun çözüm seçilir.
Tasarımda yine çözümlediğimiz bir husus da veri modelidir. Verilerin veri yapılarına karar vermek, bu verilerin hangi biçimde ve hangi ortamda tutulacağına, nasıl işleneceğine karar verilmesi gerekir. Özellikle büyük projelerde bileşenler arası paylaşılan verinin tasarımı önemli bir faaliyet olarak öne çıkmaktadır.
Kaynakların yönetimi kapsamında hangi kaynaklar paylaşılacak bu kaynakların paylaşım yöntemi, kaynak limitleri ve önceliklendirme gibi hususların kararlaştırılması gerekmektedir.
Bağlantı zamanı ise modüllerin ne zaman çalışmaya başlayacağı, yeni bileşenlerin ve veya arayüzlerin sisteme nasıl tanımlanabileceği gibi kararları içerir. Kimi altyapılar dinamik bağlantıyı destekleyerek çalışma zamanında sistemin değiştirilebilirliğini olanaklı kılmaktadır.
Enson olarak teknoloji seçimi ise ürünün maliyet etkin bir biçimde geliştirilmesi için seçilecek araç ve kütüphaneleri içerir. Teknoloji seçiminde şirketteki mevcut bilgi birikimi, ürünün kullanılacağı ortamdaki kısıtlar da dikkate alını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.
Tasarım kararlarının gerekçeleri ile birlikte dokümante edilmesi mimarinin devamlılığı açısından önemlidir. Hatta bu kararları alır iken hangi alternatifler değerlendirildi ve hangi parametreler değerlendirildi gibi önemli noktalarında kayıt altına alınması beklenir.
Mimari gereksinimler doğrultusunda tasarlanan yazılım mimarisinin mimari gereksinimleri karşıladığının ve projenin geliştirilebilir olduğunun eş gözden geçirme süreci ile değerlendirilmesi gerekmektedir. Bu kapsamda öne çıkan gözden geçirme yaklaşımı senaryo tabanlı bir mimari analiz metodu olan Mimari Ödün Analizi Metodudur (Architectural Tradeoff Analysis Method-ATAM). Bu konu daha sonra daha detaylı bir şekilde analiz edilecektir.
Kalite öznitelikleri tabanlı tasarım süreci adım 1–7 ihtiyaç duyulduğu kadar tekrarlanarak mimari oluşturulmuş olur. Bu mimarinin geliştirilmesi, test edilmesi ve sahaya sürülmesi aşamasında mimari yaklaşımlar daha sonra detaylı şekilde irdelenecektir.
Yazılım tasarımı yapılacak sistemler eğer sıfırdan tasarlanıyor olabilir (“Greenfield Systems”=”Sıfırdan Tasarım”). Bu sıfırdan tasarlanan sistemler tamamen yeni bir alanda yapılıyor ise mimari tasarım çok daha yaratıcı ve zorlayıcı olabilmektedir. Örneğin akıllı şebeke sistemleri tüm dünyada yeni gelişmekte ve kendi kendine adapte olabilen bir sistem mimarisi tasarımı daha yaratıcı ve zorlayıcı kararlar almayı gerektirebiliyor. Ama daha önce benzeri uygulamalar çok sayıda yapılmış ise daha oturmuş teknolojiler ve çözüm yaklaşımları bulunacağı için tasarım daha hızlı yapılabilir. Örneğin günümüzde e-okul sitesi tasarlamak nispeten daha az zorlayıcı bir mimari olacaktır. Çoğu zaman sıfırdan tasarım yapmamız mümkün olmayabiliyor. Bu durumda mevcut bir sistemin üzerine sistemin geçmişten gelen tasarımsal kısıtlarını göz önünde tutarak ekleme ve değişiklikler yapılır (“Brownfield System” =”Mevcut Sistemde Tasarım Değişikliği”).
Bir sistemi sıfırdan tasarlıyor isek genelde ilk döngüde kullanılabilecek referans mimari ile yayılım kalıbı seçilir. Referans mimariyi olanaklı kılan ve destekleyen ara katman, veri tabanı ve çerçeve yazılımları (framework) gibi başkaları tarafından geliştirilmiş bileşenler kullanılır.
Bu ilk döngüde sistem mimarisinin ana iskeleti oluşturulmuş olur. Daha sonra bu iskeleti destekleyecek ek yapılar tasarlanır bu amaçla mimari kalıplar ve bu kalıpları geliştirmiş olan başkaları tarafından geliştirilmiş bileşenler kullanılır. Üçüncü ve devamındaki döngüde hala çözüm üretilmemiş problemler yine tasarım kalıpları ve taktikler ile çözümlenir.
Mevcut sistemde tasarım değişikliği yaptığımız durumlarda ilk etapta mevcut sistem mimarisini ve sistemdeki kalite öz niteliklerini anlamakla başlıyoruz. Daha sonraki döngüde yeni eklenecek fonksiyonu, bunun yanında mimari kaygıları ve kalite öz niteliklerini belirleyip bunu karşılayacak çözüm aracı kullanılır. Ana bir yeniden düzenleme yapılmıyor ise ana iskelet kurma işlemi ihtiyacı duyulmuyor.
Mimari tasarım sadece sıfırdan tasarım için yapılmaz. Mevcut sistemde tasarım değişikliği yapıldığında hem mevcut sistemin mimari kaygılarını dikkate alarak yeni ekleme yapıyoruz ve eklemenin mevcut bileşenler ile uyumlu bir şekilde çalıştığına emin oluyoruz. Kimi zamanda mevcut sistemde güvenlik, performans gibi kalite öz niteliklerini iyileştirmeye yönelik tasarım yapıyoruz.
