Özet. Farklı paydaşların farklı ilgilerini gösteren mimari görünümleri modellemek için birçok mimari bakış açısı yaklaşımı ortaya konulmuştur. Mimari bakış açılarında sistem ilgileri ile beraber kalite ilgileri de ele alınmalıdır. Bu bağlamda mimari görünümlerdeki kalite ilgilerini gösterebilmek için mimari perspektifler tanımlanmıştır. Bir mimari perspektif, istenen kalite ilgisinin gerçekleştirilebilmesi için uygulanması gereken aktiviteleri, taktikleri ve ilkeleri içerir. Her bir perspektif, birden fazla mimari görünüm tarafından ele alınabilir. Bazı kalite ilgileri için literatürde farklı mimari perspektifler sunulmuştur. Yazılım emniyeti perspektifi, Rozanksi ve Woods'un perspektif tanımına göre emniyet ilgilerini mimari görünümlerde ele alabilmek için daha önceki bir çalışmamızda tanımlanmıştır. Yazılım emniyeti, emniyet-kritik sistemler için önemli bir ilgi olup, emniyet-kritik durumlardaki risklerin azaltılması ya da ortadan kaldırılması için mimari analiz sürecinin başlangıç aşamasından itibaren değerlendirilmesi gerekir. Bu çalışmada yazılım emniyeti perspektifinin Görünümler ve Ötesi mimari çerçevesine uygulanması sunulmaktadır. Yazılım emniyeti perspektifinin Görünümler ve Ötesi mimari çerçevesine uygulanması, emniyet ilgileriyle alakalı tasarım ve analiz kararlarında sistem ve yazılım mimarlarına yardımcı olmaktadır. Yazılım emniyeti perspektifinin uygulaması gerçek bir endüstriyel uygulama kullanılarak açıklanmaktadır. Anahtar Kelimeler: Yazılım mimari tasarımı, yazılım mimari modelleme, yazılım mimari analizi, emniyet-kritik sistemler
Tasarım aşamasında karar alınırken farklı paydaşlar için mimari görünümlerin
(architectural views) modellenmesi, yazılım mimari tasarımında kullanılan yaygın
pratiklerden birisidir [
Kalite ilgilerini adresleyebilmek için, genel olarak, mimari çerçeve yaklaşımlarında ayrı birer mimari görünüm sunulmamıştır. Örneğin, ISO/IEC 42010 standardı [6] farklı ilgileri adreslemek için özel bakış açıları tanımlamamıştır. Görünümler ve Ötesi yaklaşımında ise tanımlanan her bir görünümde kalite ilgileri dolaylı olarak ifade edilse de, kalite ilgilerini tanımlamak için ayrı görünümler sunulmamıştır. Bu kapsamda, mimari görünümlerdeki kalite ilgilerini adreslemek için, Rozanski ve Woods tarafından mimari perspektif (architectural perspective) yaklaşımı [11] ortaya konulmuştur. Bir mimari perspektif istenen kalite ilgisini gerçekleştirebilmek için uygulanması gereken aktiviteleri, taktikleri ve ilkeleri içerir ve birden fazla mimari görünüm tarafından dikkate alınır. Rozanski ve Woods güvenlik, performans, ölçeklenebilirlik, erişilebilirlik gibi bazı kalite ilgileri için mimari perspektifler tanımlamıştır.
Emniyet-kritik sistemlerdeki bir aksama ya da işlev bozukluğu ölümlere, insanlar üzerinde ciddi yaralanmalara ya da çevresel hasarlara neden olabileceği için, bu sistemler tasarlanırken yazılım emniyeti önemli bir ilgi haline gelmektedir. Riskleri azaltmak ya da ortadan kaldırmak için emniyet ilgisinin gerçekleştirim yapılmadan önce tasarım aşamasının başlangıcından itibaren değerlendirilmesi kritik bir önem arz etmektedir. Emniyet ilgisini ele alabilmek için birçok standart ve gerçekleştirim yaklaşımları tanımlanmış, fakat hiçbiri emniyet ilgisini mimari modelleme düzeyinde göz önünde bulundurmamıştır. Bu sebeple, daha önceki çalışmamızda emniyet ilgisini mimari düzeyde adresleyebilmek için Rozanski ve Woods yaklaşımındaki kılavuza göre yazılım emniyet perspektifini tanımlanmıştır [2][3]. Emniyet perspektifi emniyet ilgileriyle alakalı tasarım ve analiz kararlarının alınmasında sistem ve yazılım mimarlarına yardımcı olmaktadır. Bu çalışmada yazılım emniyet perspektifinin Görünümler ve Ötesi mimari çerçevesine uygulaması sunulmaktadır. Yazılım emniyeti perspektifinin uygulaması gerçek bir endüstriyel örnek uygulama kullanılarak açıklanmaktadır.
Bu çalışmanın kalanı şu şekilde organize edilmiştir: Bölüm 2'de yazılım mimarisi modelleme ile ilgili teorik altyapı anlatılmaktadır. Yazılım emniyet perspektifi Bölüm 3'te açıklanmaktadır. Bölüm 4'te yazılım emniyet perspektifinin Görünümler ve Ötesi yaklaşımına uygulaması sunulmaktadır. Bölüm 5'de gerçek bir endüstriyel uygulama kullanılarak yazılım emniyet perspektifinin uygulanması anlatılmaktadır. Bölüm 6, ilgili çalışmaları sunmaktadır. Son olarak Bölüm 7 çalışma sonuçlarını paylaşmaktadır. 2 2.1
Yazılım
Görünümler ve Ötesi Mimari Çerçevesi
Görünümler ve Ötesi (Views&Beyond) mimari çerçevesi [
Modül görünümünde modüller birbiriyle tutarlı sorumlulukları gerçekleyen birincil sistem elemanlarıdır. Bu görünüm kapsamında ayrıştırma (decomposition), kullanım (uses), genelleştirme (generalization), katmanlı (layered), ilgiler (aspects), veri modeli (data model) stilleri tanımlanmıştır. Ayrıştırma stili sistemdeki gerçekleştirim birimlerinin modül ve alt-modül olarak nasıl ayrıldığını ve sistemdeki sorumlulukların modüller ve alt-modüller arasında nasıl paylaştırıldığını gösterir. Kullanım stili modüller ve alt-modüller arasındaki bağımlılıkları gösterir. Genelleştirme stili modüller arasındaki kalıtım ilişkisini gösterir. Katmanlı stil, birbiriyle ilgili modülleri katman adı verilen bir yapıda toplayarak, katmanlar arasındaki kullanılabilirlik ilişkisini tanımlar. Bir katmandan diğer katmana kullanabilir ilişkisi tanımlanmışsa, birinci katmandaki herhangi bir modül ikinci katmandaki herhangi bir modülü kullanabilir demektir. İlgiler stili enine kesen ilgileri gerçekleyen modülleri ve bu modüllerin sistemdeki diğer modüllerle birlikte nasıl ilişkilendirildiğini gösterir. Veri Modeli stili ise veri varlıklarının yapılarını ve birbirleri arasındaki ilişkileri tanımlar.
Bileşen&bağlantılar görünümünde bileşenler sistemdeki çalışma birimleri olarak ele alınmıştır. Bu görünüm sistemin çalışma zamanı açısından ele alınmasını sağlar. Bu görünüm kapsamında çağrı-dönüş (call-return), veri akışı (data flow), olaytabanlı (event-based) ve depo (repository) ana stilleri tanımlanmış ve sıklıkla kullanılan stiller bu stiller altında kategorize edilerek tanımlanmıştır. Çağrı-Dönüş stili bileşenler tarafından sağlanan servisleri ve bu servisleri eşzamanlı bir şekilde başlatan diğer bileşenleri gösterir. Çağrı-Dönüş stili altında istemci-sunucu (client-server), noktadan noktaya (peer-to-peer) ve servis odaklı mimari (service-oriented architecture) stilleri tanımlanmıştır. Veri Akışı stili sistemdeki veri akışını modeller. Veri Akışı stili kapsamında borular ve filtreler (pipe-and-filters) stili tanımlanmıştır. Olay-Tabanlı stili eşzamanlı olmayan olay ve mesajlar üzerinden etkileşimde bulunan bileşenleri gösterir. Bu stil kapsamında yayımla-abone ol (publish-subscribe) stili tanımlanmıştır. Depo stili büyük miktarda kalıcı ve paylaşılan veriler üzerinden etkileşimde bulunan bileşenleri gösterir. Depo stili kapsamında paylaşılan veri (shared data) stili tanımlanmıştır. Bütün bu stillerin yanında çok katmanlı (multi-tier) stili de tanımlanmıştır. Bu stilde bileşenler katman (tier) adı verilen yapılarda gruplandırılarak gösterilir.
Tahsis Görünümü'nde sistemdeki yazılım elemanları ve bu yazılım elemanlarının geliştirme ve çalıştırma ortamları arasındaki ilişkisi tanımlanmıştır. Bu görünüm kapsamında konuşlandırma (deployment), kurulum (install), iş ataması (work assignment) stilleri tanımlanmıştır. Konuşlandırma stili yazılım bileşenleri ve bağlantıları ile yazılımın üzerinde çalıştığı donanımlar arasındaki eşleştirmeyi belirtir. Kurulum stili mimarideki bileşenler ile çalışma ortamındaki dosya sistem yapıları arasındaki eşleştirmeyi tanımlar. İş Ataması stili yazılım bileşenleri ile bu bileşenlerin geliştirilmesinden sorumlu çalışanlar, takımlar ve çalışma birimleri arasındaki eşleştirmeyi tanımlar. 2.2
Mimari Perspektifler
Mimari tasarımı desteklemek için Rozanski ve Woods yedi farklı bakış açısı içeren bir mimari çerçeve ortaya koymuştur [11]. Rozanski ve Woods kalite ilgilerinin tanımlanan mimari bakış açılarını çapraz kestiklerini (crosscutting) ve her bir kalite ilgisi için farklı birer bakış açısı tanımlamanın anlamlı olmadığını belirtmiştir. Bu sebeple Rozanski ve Woods istenilen kalite ilgilerinin gerçekleştirilebilmek için uygulanması gereken aktiviteleri, taktikleri ve ilkeleri içeren mimari perspektif kavramını sunmuştur. Sistem genelinde kalite ilgilerini ele alabilmek için tanımlanan her ilgili perspektif birden fazla bakış açısına uygulanabilir. Böylelikle mimari görünümler mimariyi tanımlarken, mimari perspektifler sistemin istenen kalite özelliklerini sağladığını garantilemek için mimariyi analiz etmeye ve üzerinde değişiklikler yapmaya olanak sağlar. Rozanski ve Woods güvenlik (security), performans & ölçeklenebilirlik (performance & scalability), kullanılırlık & dayanıklılık (availability & resilence), evrim (evolution), erişilebilirlik (accessibility), geliştirim kaynağı (development resource), uluslararasılaştırma (internationalization), yerleşim (location), düzenleme (regulation) ve kullanılabilirlik (usability) perspektiflerini tanımlamıştır. Her bir perspektif ilgili olduğu kalite ilgisini gerçekleştirmektedir. 3
Daha öncede belirtildiği gibi emniyet-kritik sistemler için emniyet önemli bir ilgidir. Emniyet ilgisini gerçekleştirebilmek için uygulanması gereken taktikleri ve ilkeleri mimari tasarım düzeyinde ele alabilmek için daha önceki çalışmamızda [2][3] Rozanski ve Woods'un perspektif tanımları referans alınarak, literatürde var olmayan yazılım emniyeti perspektifi tanımlanmıştır. İstenen Kalite Uygulanabilirlik İlgiler Aktiviteler Mimari Taktikler Problemler ve Tuzak Noktalar
Emniyet ile ilgili kararlar hakkında bilgi sağlamak ve ciddi hasarlara ve tehlikelere yol açabilecek sistem işlevlerini denetlemek ve kontrol etmek Tehlikeli ve emniyet-kritik işlevler içeren tüm sistemler Hata (Failure), Tehlike (Hazard), Risk, Hata Toleransı (Fault Tolerance), Kullanılırlık (Availability), Güvenilirlik (Reliability), Doğruluk (Accuracy), Performans Tehlikelerin belirlenmesi, Risklerin tanımlanması, Emniyet gereksinimlerinin belirlenmesi, Emniyet modelinin oluşturulması, Emniyet gereksinimlerine göre değerlendirme yapılması Hataları ve tehlikeleri önleme, Hataları tespit etme yöntemlerini tanımlama, Oluşan hataların sonuçlarını azaltma Hata Toleransını tanımlama, Emniyet modelinin ya da gereksinimlerinin açık bir şekilde tanımlanmamış olması, Azımsanmış emniyet problemleri
Tablo 1. Yazılım Emniyet Perspektifi Tanımı
Tablo 1 emniyet perspektifinin tanımını sunmaktadır. Yazılım emniyet perspektifi
ile emniyet ile ilgili kararlar hakkında bilgi sağlamak ve ciddi hasarlara ve tehlikelere
yol açabilecek sistem işlevlerini denetlemek ve kontrol etmek amaçlanmaktadır. Bu
perspektif tehlikeli ve emniyet-kritik işlevler içeren tüm sistemlerin tasarım
aşamasında bir kılavuz olarak kullanılabilir. Emniyet perspektifi tarafından adreslenen
ilgiler literatür taraması ile belirlenmiş ve Tablo 1'de gösterilmiştir. Mimari tasarım
aşamasında emniyet perspektifinin uygulanması için gereken aktiviteler ise aşağıdaki
gibi sıralanmıştır:
1. Tehlikelerin belirlenmesi: Emniyet gereksinimlerinin belirlenebilmesi için tehlike
analizi gerçekleştirilerek sistemdeki olası tehlikeler, tehlikelere sebep olabilecek
durumlar, tehlikelerin sonuçları ve sistemdeki her bir tehlike için tehlikenin şiddeti
[
Tanımlanan mimari perspektif tarafından adreslenen kalite özellikleri istenen düzeyde sağlanmadığında tanımlanan mimari taktikler ile yazılım tasarımına katkıda bulunulmaya çalışılmıştır. Bu çerçevede, yazılım emniyeti tasarımını destekleyebilmek için hataları ve tehlikeleri önleme, hataları tespit etme yöntemlerini tanımlama, oluşan hataların sonuçlarını azaltma taktikleri tanımlanmıştır. Yazılım tasarımı yapılırken, emniyet ilgisinin gösterilmesi ile ilgili olası sorunlar ve zorluklar hata toleransının tanımlanması, emniyet modelinin ya da gereksinimlerinin açık bir şekilde tanımlanmamış olması, azımsanmış emniyet problemleri olarak belirlenmiştir. 4
Yazılım Emniyet Perspektifinin Görünümler ve Ötesi Mimari Çerçevesine Uygulanması
Tablo 2 yazılım emniyeti perspektifinin Görünümler ve Ötesi mimari çerçevesine uygulamasını göstermektedir. Mimari Stil Ayrıştırma Kullanım Genelleştirme Katmanlı Depo Konuşlandırma Kurulum İş Ataması İlgiler Veri Modeli Çağrı-Dönüş Veri Akışı Olay-tabanlı
Yazılım emniyetinin önemli olduğu alanlardan bir tanesi de aviyonik alanıdır. Aviyonik sistemlerde oluşan hataların ölümcül sonuçlara neden olan kazalara sebep olduğu görülmüştür. Aviyonik alanındaki yazılımların geliştirilmesi ve sertifikalanması için yapılması gereken aktiviteleri anlatan DO-178C [12] gibi çeşitli standartlar bulunmaktadır. Özellikle ticari aviyonik sistemlerin bu standartlara uygun olarak geliştirilmesi ve sertifikalanması gerekmektedir. Bu bölümde, yazılım emniyeti perspektifinin uygulaması gerçek bir endüstriyel aviyonik uygulama kullanılarak açıklanmaktadır. Endüstriyel aviyonik uygulama gerçekte binlerce gereksinim içermektedir. Bu bölümde anlatılan uygulama için Tablo 3’de verilen örnek bir gereksinim kümesi seçilmiştir. 1. Tehlikelerin belirlenmesi:
Emniyet mühendisliği çalışmaları kapsamında ilk olarak tehlike analizi yapılarak tehlikeler belirlenir. Bu analiz emniyet mühendisleri, sistem mühendisleri ve ilgili alandaki uzmanlarla (aviyonik mühendisleri ve pilotlar) beraber gerçekleştirilir. Örnek uygulamamız için bu analiz sonucunda belirlenen tehlikeler, olası nedenleri, sonuçları ve tehlikenin şiddeti gibi bilgilerle beraber Tablo 4’de verilmiştir. TH1, TH2, TH3 ve TH4 olarak numaralandırılan tehlikelerin şiddeti ölümcül olarak belirlenmiştir. Çünkü bu tehlikelerin olası sonucu hava aracı kazasıdır. Örneğin doğru yakıt miktarı yerine yüksek bir yakıt miktarının gösterilmesi, pilotları yanlış yönlendirecek ve gidecekleri yere yakıt miktarı yetersiz olsa bile ulaşabilecekleri gibi yanlış bir izlenim edinmelerine sebep olabilecektir. TH5 olarak numaralandırılan tehlikenin şiddeti ise ihmal edilebilir olarak belirlenmiştir çünkü bu hata sadece yer istasyonu ile iletişim hatasına neden olabilir.
Gereksinim Kalan yakıt miktarının gösterilmesi Yüksekliğin gösterilmesi Konumun gösterilmesi Durumun (attitude) gösterilmesi Radyo frekansının gösterilmesi
Açıklama Hava aracında kala yakıt miktarı, bütün yakıt tanklarında kalan yakıt miktarlarının toplamıdır.
Hava aracının yüksekliği deniz seviyesinden olan yükseklik olarak tanımlanır. Pilotlar özellikle iniş sırasında gösterilen yükseklik bilgisine güvenerek hareket ederler.
Hava aracının konumu GPS’den (Global Positioning System) alınan enlem ve boylam koordinatlarıdır. Hava aracının konum bilgisi rota yönetimi tarafından kullanılır ve rotadaki diğer noktaların konumları ile beraber pilotlara gösterilir. Rotadan sapma olupolmadığını veya ne kadar sapıldığını pilotlar bu şekilde görebilirler.
Hava aracının durumu, hava aracının X, Y ve Z eksenleri ile olan açılarıdır. Bu açılar yunuslama (pitch), sapma (yaw) ve yuvarlanma (roll) açıları olarak isimlendirilir. Genellikle, yunuslama ve yuvarlanma açıları Durum Yön Göstergesi (Attitude Director Indicator) ile gösterilir.
Radyo frekansı, yer istasyonu ile iletişim kurulan frekanstır.
Tablo 3. Örnek Uygulama için Seçilen Gereksinimler Tehlike Olası Nedenleri Sonuçları Şiddeti Olasılığı [TH1] Yakıt Yakıt sensörünün kaybı/hatası Hava aracı Ölümcül Olası miktarının yanlış Yakıt sensörü ile iletişim kaybı/hatası kazası olmayan gösterilmesi Gösterge cihazının hatası [TH2] Yükseklik Yükseklik cihazının kaybı/hatası Hava aracı Ölümcül Olası bilgisinin yanlış Yükseklik cihazı ile iletişim kaybı/hatası kazası olmayan gösterilmesi Gösterge cihazının hatası [TH3] Konum GPS cihazının kaybı/hatası Hava aracı Ölümcül Olası bilgisinin yanlış GPS cihazı ile iletişim kaybı/hatası kazası olmayan gösterilmesi Gösterge cihazının hatası [TH4] Durum Cayroskop cihazının kaybı/hatası Hava aracı Ölümcül Olası bilgisinin yanlış Cayroskop cihazı ile iletişim kaybı/hatası kazası olmayan gösterilmesi Gösterge cihazının hatası [TH5] Radyo Radyo cihazının kaybı/hatası Yer istasyo- İhmal Nadiren frekansının yanlış Radyo cihazı ile iletişim kaybı/hatası nu ile ileti- edilebilir gösterilmesi Gösterge cihazının hatası şim hatası
Tablo 4. Örnek Uygulama için Tehlikelerin Belirlenmesi ve Risklerin Tanımlanması 2. Risklerin tanımlanması:
Her bir tehlike için tehlikenin olasılığı ve risk değerlendirmesi de Tablo 4’de verilmiştir. Genel olarak tasarım kriteri, ölümcül kategoride olan bütün tehlikelerin olasılığını “olası olmayan” şekilde tasarlamaktır. TH1, TH2, TH3 ve TH4 olarak numaralandırılan tehlikelerin risk kategorisi orta olarak belirlenmiştir, TH5 olarak numaralandırılan tehlikenin riski ise düşüktür.
Riski Orta Orta Orta Orta Düşük 3. Emniyet gereksinimlerinin belirlenmesi:
Tehlike analizi tamamlandıktan sonra emniyet gereksinimleri belirlenir. Örnek olarak, sonraki aktivitelerde de kullanılmak üzere, TH1 ile ilgili emniyet gereksinimleri Tablo 5’de listelenmiştir. Benzer emniyet gereksinimleri diğer tehlikeler için de belirlenebilir. EG1 (Emniyet Gereksinimi) yakıt miktarı bilgisinin en az iki bağımsız yakıt sensöründen alınmasını, EG2 alınan yakıt miktarı bilgilerinin karşılaştırılmasını ve karşılaştırma sonucuna göre gösterilmesini veya uyarı verilmesini, EG3 ise yakıt miktarı bilgisinin en az iki bağımsız göstergede gösterilmesini istemektedir. No EG1 EG2 EG3
Tanım Yakıt miktarı bilgisi en az iki tane bağımsız sensörden alınmalıdır.
Eğer iki tane bağımsız sensörden alınan yakıt miktarları arasında belirlenen bir değerden daha fazla fark varsa, yakıt miktarı bilgisi gösterilmemelidir ve bununla ilgili bir uyarı verilmelidir. Yakıt miktarı bilgisi en az iki tane bağımsız göstergede gösterilmelidir.
Tablo 5. Örnek Uygulama için Emniyet Gereksinimleri
Bu aktivitede belirlenen emniyet gereksinimlerine uygun olarak tasarım yapılır. Tasarım süreci yinelemeli bir süreçtir. İlk olarak modeller oluşturulur ve bu modellerin bir sonraki aktivitede de anlatıldığı gibi emniyet gereksinimlerine uygun olupolmadığı değerlendirilir. Bu değerlendirme sonuçlarına göre eğer tasarım emniyet gereksinimlerine uygun değilse modeller güncellenir. Bu yinelemeli süreç, tasarımın uygun bulunmasına kadar devam eder. Bu bölümde, örnek uygulamamızın mimari tasarımının iki versiyonu anlatılmaktadır. Birinci versiyon, emniyet gereksinimleri belirlenmeden önceki versiyondur. İkinci versiyon ise birinci versiyonun emniyet gereksinimlerine uygun olarak güncellenmesi sonucunda oluşan versiyondur. Yapılan güncellemeler ve güncellemelerin nedenleri bir sonraki aktivitede anlatılmaktadır.
Şekil 1. Örnek uygulama mimari modeli birinci versiyon Örnek uygulamamız için oluşturulan yazılım mimarisi modelinin birinci versiyonu Şekil 1'de verilmiştir. Birinci versiyonda bir tane yakıt sensörü ve bir tane grafik cihazı bulunmaktadır. YakitYon, yakıt sensörünün yöneticisidir ve yakıt sensöründen aldığı yakıt miktarı bilgisini platform yöneticisine sağlar. YukseklikYon, yükseklik cihazının yöneticisidir ve yükseklik cihazından aldığı yükseklik bilgisini seyrüsefer yöneticisine sağlar. GpsYon, GPS cihazının yöneticisidir ve GPS cihazından aldığı konum bilgisini seyrüsefer yöneticisine sağlar. CayroYon, cayroskop cihazının yöneticisidir ve cayroskop cihazından aldığı durum (attitude) bilgisini seyrüsefer yöneticisine sağlar. RadyoYon, radyo cihazının yöneticisidir ve radyo cihazından aldığı frekans bilgisini haberleşme yöneticisine sağlar. PlatformYon isimli yönetici yakıt miktarı bilgisini yakıt yöneticisinden alır ve grafik yöneticisine sağlar. SeyruseferYon isimli yönetici yükseklik, durum ve konum bilgilerini ilgili cihaz yöneticilerinden alır ve grafik yöneticisine sağlar. HaberlesmeYon isimli yönetici frekans bilgisini radyo cihazı yöneticisinden alır ve grafik yöneticisine sağlar. GrafikYon isimli yönetici grafik cihazının yöneticisidir. Yakıt miktarı, yükseklik, durum, konum ve frekans bilgilerini ilgili yöneticilerden alır ve grafik cihazında gösterilmek üzere gönderir.
Örnek uygulamamız için oluşturulan yazılım mimarisi modelinin ikinci versiyonu Şekil 2'de verilmiştir. İkinci versiyonda sisteme emniyet gereksinimlerini sağlamak amacıyla ikinci bir yakıt sensörü ve ikinci bir grafik cihazı eklenmiştir. Yakit1Yon ve Yakit2Yon isimli yöneticiler yakıt sensörleri 1 ve 2’nin yöneticileridir. Yakıt yöneticileri, ilgili yakıt sensöründen yakıt miktarı bilgisini alır ve bu bilgileri platform yöneticisine sağlar. Grafik1Yon ve Grafik2Yon isimli yöneticiler grafik cihazları 1 ve 2’nin yöneticileridir. Yakıt miktarı, yükseklik, durum, konum ve frekans bilgilerini ilgili yöneticilerden alır ve grafik cihazlarında gösterilmek üzere gönderir. PlatformYon isimli yönetici her iki yakıt yöneticisinden gelen yakıt miktarını alacak şekilde güncellenmiştir. Şekil 2' de emniyet kritik olan modüller SC (Safety Critical) stereotipi ile işaretlenmiştir. Böylece emniyet kritik modüller ve emniyet kritik olmayan modüller ayırt edilebilmektedir.
Şekil 2. Örnek uygulama mimari modeli ikinci versiyon
Son aktivite ile oluşturulan mimari tasarımın emniyet gereksinimlerine uygun olup-olmadığı değerlendirilir. Örnek uygulamamızın ilk versiyonunda bir tane yakıt sensörü ve bir tane grafik cihazı bulunduğu için EG1 ve EG3 numaralı emniyet gereksinimleri sağlanamamaktadır. Bu nedenle tasarıma birer tane daha yakıt sensörü ve grafik cihazı eklenerek güncelleme yapılmış ve ikinci versiyon oluşturulmuştur. Böylece EG1 ve EG3 gereksinimleri yedeklilik taktiği kullanılarak ikinci versiyonda sağlanmaktadır.
İkinci versiyondaki platform yöneticisi iki ayrı yakıt yöneticisinden yakıt miktarı bilgisini alacak ve EG2 gereksiniminde belirtildiği gibi iki yakıt miktarını karşılaştıracak ve aralarındaki fark belli bir miktardan fazla ise yakıt miktarı gösterilmeyecek ve yakıt miktarı ile ilgili bir uyarı verilecek şekilde güncellenmiştir. Birinci versiyonda böyle bir karşılaştırma yapılamadığı için birinci versiyon EG2 gereksinimini yerine getirememektedir. Bu güncelleme ile EG2 gereksinimi de ikinci versiyonda gerçekleştirilmiştir. İkinci versiyonda modüllerin çalışmasını kontrol eden bir hata kontrol yöneticisi (DurumMonitoru) de eklenmiştir. Bu yönetici, diğer modüllerin düzgün çalışıpçalışmadığını kontrol etmektedir ve çalışmayan modülleri yeniden başlatabilmektedir. 6. Görünümlere uygulanması:
Bu bölümde, emniyet perspektifinin örnek uygulamamıza uygulanması ile oluşan stiller anlatılmaktadır. Bu stillerin hangileri olduğu kısa bir açıklama ile beraber Tablo 6'da verilmiştir. Bu stiller bir önceki bölümde anlatılan mimari tasarımın ikinci versiyonuna göre oluşturulmuştur.
Stil Ayrıştırma Kullanım Katmanlı Veri Akışı Konuşlandırma
Açıklama Emniyet kritik modüller ve emniyet kritik olmayan modüller işaretlenmiştir(bkz. Şekil 3) Emniyet kritik modüllerin kullandığı modüller gösterilmiştir. (bkz. Şekil 3) Her katmanda emniyet kritik modüller ve emniyet kritik olmayan modüller gösterilmiştir. (bkz. Şekil 3) Emniyet kritik bir veri olan yakıt miktarı bilgisinin ele alındığı emniyet kritik modüller gösterilmiştir. (bkz Şekil 4) Emniyet kritik bir veri olan yakıt miktarı bilgisinin iki ayrı sensörden alınması ve iki ayrı göstergeye gönderilmesi. (bkz Şekil 2)
Tablo 6. Emniyet Perspektifinin Uygulanması Şekil 3. Örnek Uygulama için Ayrıştırma, Kullanım ve Katmanlı Mimari Stili Örnek uygulamamız için modül görünümlerinden ayrıştırma, kullanım ve katmanlı stillere göre olan çizim Şekil 3’de verilmektedir. Sayfa limiti nedeniyle bu üç stil bir arada gösterilmiştir. Şekil 3’deki modüller arasındaki bağlantılar ve katmanlar gösterilmediğinde ayrıştırma stili elde edilmektedir. Ayrıştırma stilinde emniyet kritik modüller ve emniyet kritik olmayan modüller “SC” stereotipi ile işaretlenmiştir. Şekil 3’de modüller arasındaki bağlantılar kullanım durumunu gösteren bağlantılardır ve bu bağlantılar ile modüller bir arada gösterildiğinde kullanım stili elde edilmektedir. Bu stilde hangi emniyet kritik modüllerin hangi emniyet kritik modülleri kullandığı görülmektedir. Emniyet kritik modüller sadece emniyet kritik modülleri kullanabilir. Örnek uygulamamızda üç katmanlı bir mimari bulunmaktadır. Şekil 3’de gösterildiği gibi birinci katmanda cihaz/sensör yöneticileri, ikinci katmanda platform, seyrüsefer ve haberleşme yöneticileri ve üçüncü katmanda da grafik yöneticileri bulunmaktadır. Katman bilgileri de görünüme eklendiğinde katmanlı stil elde edilmektedir. Bu stilde hangi katmanlarda hangi emniyet-kritik modüllerin olduğu görülmektedir.
Bileşen ve bağlantılar görünümünden veri akışı stilinin örnek uygulamamız için kullanım örneği Şekil 4’de verilmektedir. Bu çizimde yakıt miktarı bilgisinin veri akışı gösterilmektedir. Yakıt miktarı bilgisi emniyet kritik bir veri olduğu için bu verinin işlendiği modüllerin de emniyet kritik modül olması gerekmektedir. Ayrıca veri akışını gösteren oklar da emniyet kritik veri olduğunu belirten “SC” stereotipi ile işaretlenmiştir.
Şekil 4. Örnek Uygulama için Veri Akışı Mimari Stili
Tahsis görünümünden konuşlandırma stili, emniyet modelinin oluşturulması aktivitesinde de anlatılmakta ve Şekil 2'de verilmektedir. Konuşlandırma stili emniyet kritik modüller için gerekli olan donanım elemanlarını belirtir. Şekil 2'de emniyet kritik bir veri olan yakıt miktarı verisinin alındığı yakıt sensörleri ve ilgili yakıt sensörü ile iletişim kuran yakıt sensör yöneticileri diğer cihazlar ve yöneticiler ile beraber gösterilmiştir. 6
İlgili Çalışmalar
Daha önceki çalışmalarımızda emniyet ve kurtarılabilirlik (recoverability) kalite ilgileri için mimari bakış açıları tanımlanmıştır. Kurtarılabilirlik ilgisi için yapılan çalışmada [15] mimarinin farklı şekillerde ayrıştırılmasını gerektirdiği için, bakış açısı tanımında bu ayrıştırmayı sağlayabilecek ilgili mimari elemanlar ve ilişkiler tanımlanmıştır. Emniyet ilgisi için yapılan çalışmada [2][4] ise emniyet-kritik sistemlerin tasarımını analiz etmek ve desteklemek için bir mimari çerçeve sunulmuştur. Böylece farklı kalite ilgileri tasarım aşamasının başlangıcından itibaren mimari seviyede ele alınabilmiş ve tasarım ile ilgili kararlar verilirken farklı tasarım alternatifleri değerlendirilmiştir.
Tasarımı yazılım emniyeti açısından değerlendirmek ve analiz etmek için
literatürde bazı teknikler sunulmuştur. Hata ağacı analizi (fault tree analysis) bu yöntemlerden
birisidir. Hata ağacı analizinde tasarımdaki hangi hataların sistemde hangi hatalara
neden olabileceği analiz edilir ve mantıksal kapılar kullanılarak gerçekleştirilir [
Yazılım emniyeti planlama ve tasarımı için birçok standart tanımlanmıştır.
RTCA DO-178C [12], MIL-STD-882D [