Bir Endüstriyel Nesnelerin İnterneti Mimarisinin ATAM Yaklaşımı ile Değerlendirilmesi Evaluation of an IIoT System Using ATAM

Abstract

This paper presents the ATAM based architectural analysis of a monitoring and control system that collects data from thousands of end devices for recording, analysis and display. Risks, sensitivity points and tradeoffs identified during scenario based analysis are being handled during development phase of the project.

Keywords

• ATAM
• Industrial Internet of Things
• Micro Service

-

ASELSAN Ulaşım, Güvenlik, Enerji ve Otomasyon Sistemleri Sektör Başkanlığı (UGES) her tür şebeke yönetimini (enerji, doğal gaz, su vb.) hedeflediği bir altyapı projesini gerçekleştirmektedir. Geliştirilecek mimarinin uygulandığı ilk alan olarak elektrik şebeke yönetimi (Enerji Dağıtım, Üretim, İletim Sistemleri) hedeflenmektedir. Bu kapsamda tasarım, yazılım geliştirme ve testlerin icra edilmesi işleri için yazılım mühendisliği alanında hizmet sağlayıcı olan ICterra Bilgi ve İletişim Teknolojileri A.Ş ile projenin altyüklenicisi olarak çalışmaktadır.

Referans mimarisi Şekil-1 de verilen sistemde uç sistemler ASELSAN tarafından geliştirildiği gibi, mimari desteklediği uluslararası standartlar sayesinde farklı firmaların uç birimleriyle de veri alış verişi yapabilmektedir. Merkezde çalışacak olan yazılım, sahadan veri alınacak uç birim sayısından ve bu birimlerden alınan verilerin yoğunluğundan bağımsız, kesinti yaşanmadan erişilebilir olmalıdır. Bu isterin sağlanabilmesi için, sistemin gerçek zamanda dinamik olarak, yatayda aşağı ya da yukarı yönde ölçeklendirilebilmesi ve servis hatalarının birbirinden izole tutulabilmesi gerekmektedir. Bunun yanında sistemde bulunan servislerin işlediği verilerin servisler bazında homojen olmaması, her servisin bir diğerinden bağımsız olarak ölçeklendirilebilmesini gerektirmektedir. Mikro servislerin birbirinden bağımsız şekilde konteyner altyapıları kullanılarak kurulumları ve yedekli çalışmaları beklenmektedir. Tüm bu isterlerin yerine getirilebilmesi için, mikro servis[ 1,2 ] mimari tasarım kalıbı kullanılmıştır. Uygulamanın genel amacı, uç birimlerden ilgili protokoller üzerinden alınan verilerin, ortak veri modeline dönüştürülerek kaydedilmesi, analiz edilmesi ve ilgili kullanıcılara sunulmasıdır. Uç birimlerin entegrasyonu ile birlikte tüm sistem milli olarak geliştirilen Endüstriyel Nesnelerin İnterneti (Industrial Internet of Things) [ 3 ] uygulaması olacak ve büyük çaplı görev kritik projeler için kullanılabilir bir altyapı oluşturacaktır. Şekil 1 Üst Seviye Mimarisi Bölüm 2’de mimari tasarım süreci ve bu sürecin bir parçası olan ATAM tabanlı analiz yaklaşımı anlatılmaktadır. Analiz süreci girdisi olan iş hedefleri Bölüm 3’te verilmiştir. Bölüm 4’te mevcut sistem mimarisinin ATAM sürecine göre analizi anlatılmaktadır. Sonuç bölümünde yapılan çalışma değerlendirilmiş ve gelecek dönem çalışmaları özetlenmiştir. 2

Mimari Tasarım ve Analiz Yaklaşımı

Yazılım mimarisi geliştirme süreci Şekil 2’de verildiği gibi döngülü bir süreçtir. 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) [ 4,5,6 ]. ATAM metodu endüstride gerek savunma projelerinde gerekse IT projelerinde başarı ile kullanılmıştır [ 7,8,9,10 ]. ATAM yaklaşımı savunma sanayinde kullanılan detaylı tasarım gözden geçirme aşamalarında kullanılabildiği gibi [ 7 ] gibi CMMI sürecinin bir parçası olan mimari Karar Analizi ve Çözümleme süreci kapsamında da kullanılabilmektedir [ 8 ]. Çevik geliştirme yönetimi [ 11, 12 ] ile geliştirilen ve veri yoğunluğu bakımından kritik olan şebeke yönetim yazılımının mimari kararlarının değerlendirilmesi amacı ile tercih edilmiştir. Bu kapsamda ASELSAN proje teknik lideri, ICterra proje teknik lideri ve ICterra Kıdemli Yazılım Mimarı’nın yanı sıra ICterra Uzman Yazılım Mimarı, ICterra Grup Yöneticisi ve ASELSAN UGES Yazılım Mühendisliği Müdürü seviyesinde katılım sağlanarak projenin analizi yapılmıştır.

Şekil 2 Yazılım Mimari Tasarım Süreci ( [ 7 ]’ den adapte edilmiştir.) ATAM incelenen mimarinin potansiyel risklerini, ödünleşim ve duyarlılık noktalarını tespit eden bir yazılım mimarisi değerlendirme ve analiz etme yöntemidir. ATAM, alınan tasarım kararlarının sonuçlarını sistemden beklenen kalite öznitelikleri [ 13 ] doğrultusunda değerlendirmeyi amaçlar. ATAM çalışması sonucunda, değerlendirilen sistemin; • Kalite öznitelikleri, gereksinimleri açıkça tanımlanmış, • Yazılım mimari dokümantasyonu oluşturulmuş, • Tasarım kararları gerekçelendirilmiş, • Mimari riskleri tespit edilmiş, • Paydaşları arasında iletişim geliştirilmiş olunması hedeflenmektedir. Kavramsal ATAM süreci akışı Şekil 3’te verilmiştir. Bu süreç öncelikli olarak iş hedeflerinin belirlenmesi ile başlar. Bu aşamada sistemin işin kapsamı, fonksiyonel beklentiler, varsa teknik veya yönetsel kısıtlar ve mimariyi şekillendiren temel kalite gereksinimleri belirlenir. Bununla eş zamanlı olarak planlanan mimarinin ve sistemden beklenen kalite niteliklerinin öngörülen mimari tasarım ile nasıl gerçekleştirileceği belirlenir.

Daha sonraki aşamada sistem için önemli olan kalite nitelikleri belirlenir, bu nitelikler senaryolaştırılır ve senaryolar kendi içlerinde “önem” ve “zorluk” kıstaslarına göre önceliklendirilir.

Sonraki aşamada geliştirilen senaryolardan yüksek öncelikli olanlar analiz edilir. Bu adımda mimari riskler, duyarlılık noktaları ve ödün noktaları tespit edilir. Bu süreç sonucu yapılan çalışma raporlanır ve ihtiyaca göre projenin ileriki aşamalarında güncellenir. Tespit edilen risk konularına göre mimari geliştirme ve değerlendirme süreci tekrarlanır. Şekil 3 ATAM Tabanlı Mimari Analiz Kavramsal Akışı (SEI web sitesinden adapte edilmiştir.)

Kavramsal olarak yukarıda verilen ATAM sürecinin Tablo 1’de belirtilen adımlar halinde ilerlemesi beklenmektedir [ 4 ]:

Tablo 1. Atam Süreci

Sunum Aşaması:

1. ATAM’ın Sunulması 2. İş Hedefi Girdilerinin Sunulması 3. Mimarinin Sunulması

Araştırma ve Analiz Aşaması:

4. Mimari Yaklaşımların Tanımlanması. 5. Kalite Faktörleri Ağacının Oluşturulması. 6. Mimari Yaklaşımların Analiz Edilmesi

Test Aşaması

7. Senaryo Önceliklendirilmesi 8. Mimari Yaklaşımların Analiz Edilmesi

Raporlama aşaması:

9. Sonuçların Sunulması

Bu sürecin geniş katılımcı paydaşlarla toplantılar halinde yapılması öngörülmekle birlikte [ 4 ] bu toplantıların çevik süreç uygulayan projelerde uygulanmasının getirdiği zorluklar değerlendirilerek süreç adapte edilmiş ve ön çalışmalar sonrası yarım günlük bir toplantı ile paydaş analizi yapılmıştır. [ 6 ]. Proje kapsamında bu yaklaşım kullanılmış, çekirdek kadro tarafından hazırlanan ATAM analizi yarım günlük bir toplantı ile değerlendirilmiş ve toplantıda alınan görüşlere göre analiz raporu güncellenmiştir. Süre kısıtlarından dolayı sınırlı sayıda senaryo dikkate alınmış ve buna göre çalışma yapılmıştır. Yine çevik model ile uyumlu ATAM sürecinde anlatıldığı üzere daha sonraki proje aşamalarında farklı senaryolar (örneğin güvenlik) ele alınarak ilgili senaryolar ile mimarinin analiz edilmesi hedeflenmektedir. 3 3.1 İş Hedefleri Girdileri

Paydaşlar ve Mimariye Etkileri:

ASELSAN UGES Sektör Başkanlığı: Ürün ve mimari tasarım sahibi. Ürünü, birden fazla projede kullanılabilir bir altyapı olarak hedeflemektedir. Sistem gereksinimlerini belirlemekte, mimariyi oluşturmakta ve yönlendirmektedir. Yazılım geliştirme faaliyetlerini teknik olarak yönlendirmekte ve belirli alanlarda yazılım geliştirme faaliyetlerine katılmaktadır.

ICterra: Yazılım mimari tasarım faaliyetlerini ASELSAN ile birlikte yürütmekte ve yazılım geliştirme faaliyetlerini yürütmektedir.

Son Müşteri: Şebeke yönetim operatörleridir. 3.2

İşin Kapsamı: Proje Kapsamında mimari tasarıma girdi olarak sunulan iş hedefleri aşağıda verilmiştir:

Referans mimari her tür şebeke yönetimini (enerji, doğal gaz, su vb.) hedeflemektedir.

Mimarinin ilk uygulandığı alan olarak elektrik şebeke yönetimi (Enerji Dağıtım, Üretim, İletim Sistemleri) hedeflenmektedir.

Yeni teknolojinin getirdiği esneklik, birlikte çalışabilirlik ve kolay kurulum özellikleri ürünün pazarlana bilirliğini arttıracaktır. Ürüne orta vadede gelişmiş yüksek hacim analitiği ve makine öğrenmesi gibi en ileri kabiliyetlerin de eklenebilir olması öngörülmektedir.

Yüksek servis sürekliliği sağlayan bir ürün geliştirerek görev kritik sistemler için de kullanılabilir olması planlanmaktadır. 3.3

Mimariyi etkileyen Ana Kullanım Durumları

Proje Kapsamında mimari tasarımı etkileyecek kullanım durumları aşağıda verilmiştir: 1. KD-1 Uç cihazlardan gelen verinin gerçek zamanlı gösterilmesi 2. KD-2 Uç cihazlardan gelen verinin veri tabanına kaydedilmesi 3. KD-3 Kayıtlı veriden grafiklerin oluşturulması 4. KD-4 Gelen verilerden alarm koşullarının oluşturulması ve sergilenmesi 5. KD-5 Uç birimlere ilgili protokolleri kullanarak komut veya konfigürasyon verisi gönderilmesi 6. KD-6 Toplanan veriler üzerinde veri analitiği algoritmaları işletilmesi 3.4

Mimari Kaygılar

Proje paydaşları tarafından dile getirilen mimari kaygılar değerlendirilmiş ve aşağıda listelenmiştir: 1. 2. 3. 4. 5. 6. 7. 8.

Sistemin hem bulut üzerinde hem de yerel sunucularda çalışması beklenmektedir.

Farklı büyüklükteki projeler için ölçeklenebilir olmalıdır. (Küçük projeler için maliyet etkin çözüm olması önemlidir.) Sistemin performans sorunu olmadan 7/24 çalışması beklenmektedir. Yedekli çalışabilecek alt yapıda tasarlanması beklenmektedir.

Dağıtık (cluster) çalışabilecek alt yapıda tasarlanacaktır. Dinamik olarak genişleyebilecektir/daralacaktır.

Dış ara yüzlerde yeni protokolleri destekleyebilecek esnek tasarım altyapısına sahip olacaktır. İzlenebilirlik yüksek olacaktır. Servislerin hata/sağlık vb. durumlarının izlenebilmesi için kayıt altyapısı sağlayacaktır.

Farklı projelerde farklı dış ara yüzler ve yapılandırılabilir edilebilir yetenekler olabilecektir. Farklı projelerde yeni yazlım servislerinin eklenmesine olanak tanımlamalı. Bunun için diğer modüllerde değişiklik gerekmemelidir. Kullanılması istenmeyen servislerin sistemde kapatılabilmesi sağlanmalıdır.

Sınırlamalar

Paydaşların belirttiği ve yazılım mimarisini etkileyebileceği öngörülen proje sınırlamaları aşağıdaki gibidir: 1. Referans mimari ile ilk çalışabilir prototip yazılımın proje tasarım aşamasının başlangıcından itibaren bir sene içinde çıkması gerekmektedir. 2. Ürünün CIM [ 14 ] standart veri modelini desteklemesi beklenmektedir. 3. İşletim sisteminden bağımsız olarak çalışması beklenmektedir. 4. Farklı şirketlerde çalışan birden fazla ekip tarafından paralel geliştirilme yapılabilecektir. 5. Lisanslı yazılımlar yerine projede aynen kullanım kısıtı bulunmayan (GPL,

LGPL, Apache gibi) açık kaynak yazılım kütüphaneleri tercih edilecektir. 4

Kalite Öznitelikleri Senaryoları ve Mimari Analiz

Mimari analiz çalışması olarak kalite öznitelikleri senaryoları oluşturulmuş ve üzerinde analiz çalışması yapılmıştır. Bu kapsamda ortaya çıkan senaryolar, proje açısından önem ve yazılım geliştirme açısından zorluk derecelerine göre değerlendirilmiştir (Tablo 2).

Tablo 2. Kalite Öznitelikleri

NO

Kalite Özniteliği

Senaryo

Perf-1

Sür-1 Değ-1

Performans-sunum zamanı Süreklilik

Değiştirilebilirlik Değ-2

Değiştirilebilirlik Klş-1

Kullanışlılık Bkm-1

Bakım yapılabilirlik

Uç birimlerden gelen verilerin kayıpsız işlenmesi. Sunucu yazılımları yedekli çalışabilmeli.

Sisteme farklı protokol üzerinden konuşan yeni uç sistem ve/veya farklı merkezler entegre edilebilmesi.

Sisteme yeni yetenekler eklenebilecek ve/veya mevcut servisler kapatılabilecektir. Minimum sayıda operatör ile izleme ve yönetim.

Servislerin hata/sağlık vb. durumlarının izlenebilmesi için kayıt altyapısı sağlanması. Önem Y: Yüksek O:

Orta D: Düşük

Y Y Y Y O O

Zorluk

Y: Yüksek

O: Orta D: Düşük

Y Y O O O D Seçilen örnek senaryolar için detaylı kalite öznitelikleri analizleri aşağıdaki Tablo 3Tablo 8’de verilmiştir. Her bir senaryoyu gerçeklemek üzere seçilen mimari kararlar dokümante edilmiştir. Bununla birlikte mimari riskler, duyarlılık noktaları ve ödün noktaları tespit edilmiş ve sunulmuştur.

Tablo 3. Performans Senaryosu

Senaryo #: Perf-1

Trafolardan gelen verinin kayıpsız işlenmesi Ortam: Sistemin entegre sahada çalışma ortamı Uyarıcı (Stimulus): Örnek kullanım durumunda verilen sayıda istasyonun sisteme öngörülen frekansta veri sağlaması Tepki (Response): Verilerin kayıpsız şekilde veri tabanına kaydı ve alarm koşullarının kayıpsız şekilde tespiti.

Tepki Ölçüsü (Response Measure): Kayıpsız veri için referans yük durumu: Örnek bir kullanım durumu: 15000 İstasyon, her istasyonda 3500 ölçüm noktası, her ölçüm noktasından ortalama 64 byte veri (zaman, tipi, ölçüm değeri vb.), 10 dakikada bir güncelleme

Mimari kararlar

Çok yüksek hacimdeki verilerin etkin şekilde saklanabilmesi için kullanılacak disk sistemi de önemlidir Benzer şekilde veri kayıt periyodu dikkate alınarak disk boyutu belirlenmeli.

Performans açısından en kritik olan ölçüm verisinin işlenmesi ve modüller arası aktarılması optimize şekilde yapılmalı.

Tablo 4. Süreklilik Senaryosu

Risk olmayan husus RO

Senaryo #: Değ-1 Sisteme farklı protokoller üzerinden konuşan yeni uç sistemlerin ve/veya farklı merkezlerin entegre edilmesi.

Ortam: Yeni Proje/Operasyonel sistem

Uyarıcı (Stimulus):

- Mevcut Altyapının yeni proje için yeniden kullanılması - Mevcut sisteme yeni tür bir uç birim entegre edilmesi - Mevcut sistemin başka bir sistem ile entegre edilmesi Tepki (Response): Yeni uç birimin/karşı sistem ile veri alışverişi sağlaması Tepki Ölçüsü (Response Measure): Mevcut servislerin en az şekilde etkilenmesi.

Mimari kararlar

CIM veri modeli hala gelişmekte olan bir standarttır ve veri modelinde gelişmeler olmaktadır. Uygulanacak projede daha yeni bir CIM versiyonu istenmesi durumunda, yazılım modüllerinde geniş çaplı değişiklik gerekecektir.

Yeni entegre edilen trafoda daha önceden işlenmemiş veri /kontrol verisi olmaması durumunda birden fazla modül etkilenebilecektir. Modüllerin yeni veriler/mesajlar eklenebilir yapıda geliştirilmesi gerekmektedir.

Yeni protokolleri desteklemek için farklı 3. Parti kütüphane kullanmak gerekebilecektir. Farklı kütüphanelerin entegrasyonu için uygun altyapı kurulması gerekmektedir.

T1 RO-1

Storm kullanıldığı için Apache Storm’un desteklendiği dillere bağımlılık bulunmaktadır. Diğer dillere mecbur olunduğu takdirde mesaj kuyruğuna veri aktaran adaptör tanımlanması gerekecektir.

Yeni entegre edilen trafoda daha önce işlenmiş bir veri için bütün alanlar dolu olmayabilir. Bu durumda varsayılan değerler kullanılacaktır.

Senaryo #: Sür-2

Ortam: Sahada çalışan istasyon Uyarıcı (Stimulus) : Donanım hatası, güç kesilmesi, yazılım hatası Tepki (Response) : Sistemin kapanma sonrası yeniden başlatılması

Tepki Ölçüsü (Response Measure) : Mevcut görevin devam edebilmesi

Tablo 5. Değiştirile bilirlik Senaryosu -1

Sunucu yazılımları yedekli çalışabilmeli

Mimari kararlar

Hassasiyet

(Sensitivity) Ödün (Tradeoff)

Risk Hususları

Risk

Olmayan Hususlar

Mesaj kuyruğu (Message Queue) yapısının kullanılması

Gerekçe:

Yazılımlarda problem olduğu zaman (istenmeden sonlanma, elektrik kesintisi vb. ) mesaj kuyruğu veriyi diskte tutarak veri kaybını önleyecektir.

Hassasiyet /Ödün/ Risk/Risk Açıklama olmayan

Tablo 6. Değiştirile bilirlik Senaryosu

Senaryo #: Değ-2

Yeni bir servisi mevcut servisleri değiştirmeden ekleme

Ortam: Bakım ve garanti dönemi Uyarıcı (Stimulus): Yeni bir fonksiyon ihtiyacı Tepki (Response): Mevcut servisler değiştirilmeden yeni bir servisin eklenmesi

Tepki Ölçüsü (Response Measure): Değiştirilen servis sayısı

Mimari kararlar

Hassasiyet

(Sensitivity) Ödün deoff) (Tra

Risk

hususları

Risk olmayan husus

Mikro servis

mimarisi

Rabbit MQ Mesaj Kuyruğu

Konteyner ya

H1 pısı Gerekçe: Yeni servisler mikro servis olarak tasarlanacaktır. Yeni servisler konteyner ile kurularak diğer servisleri olumsuz etkilememesi sağlanacaktır. Yeni servisler RabbitMQ üzerinden verilere erişebilecektir.

Hassasiyet/Ödün/ Açıklama

Risk/Risk olmayan

H1

Kapatılması muhtemel servislere bağımlı başka servislerin olmamasına özen gösterilecektir.

Tablo 7. Kullanışlılık Senaryosu Minimum sayıda (1-2) operatör ile izleme ve yönetim

Senaryo #: Klş-1

Ortam: Operasyonel sistem

Mimari kararlar

Web Tabanlı Tek sayfa Uygulaması (React Node JS) Filtre Tasarımları

Hızlı ekran tasarımı

Analiz/alarm altyapısı

Uyarıcı (Stimulus): Binlerce uç cihazdan veri gelmekte, alarm koşulları oluşmakta Tepki (Response): Alarm durumlarının kaçırılmaması, zamanında operasyonel tepki verebilme Tepki Ölçüsü (Response Measure): Hata durumunun kolaylıkla tespiti. Gerekli verinin olması

Hassasiyet (Sensitivity) Ödün (Tradeoff)

Risk olmayan husus RO1

R1 Önceliklendirilmiş alarm altyapısı Gerekçe: İzleme sistemlerinde operasyonel maliyeti düşürmek üzere az sayıda operatör ile işletilmesi hedeflenmektedir. Bu durumda mevcut operatörlerin ekranlarının aşırı yüklenmemesi ve oluşan alarmların kayıpsız şekilde operatöre iletilmesi beklenmektedir.

Hassasi- Açıklama yet/Ödün/Risk/Risk olmayan

R1

Mevcut algoritmalar verilerin limit değerini incelemekte ve limit dışı her durum için alarm üretmektedir. Bu durumda bir uç

RO-1 sistemde oluşacak ve birden fazla veriyi etkileyecek durum için aynı anda onlarca alarm üretilebilir. Bu durum operatörün aşırı yüklenmesine sebep olabilir.

Risk giderme yöntemi 1: Yüksek hacimli analitiği ve makine öğrenmesi gibi en ileri kabiliyetlerin de eklenebilir olması öngörülmektedir.

Web tabanlı tek sayfa uygulamaları üzerinde sade ekranlar UX tasarımcıları tarafından tasarlanmakta ve operatöre verinin etkin bir şekilde sunulması öngörülmektedir.

Tablo 8. Bakım Yapılabilirlik Senaryosu

Senaryo #: Bkm-1

Sistemin hata/sağlık vb. durumlarının izlenebilmesi

Ortam: Operasyonel sistem Uyarıcı (Stimulus): Yazılım hatası/beklenmeyen veri/ durum Tepki (Response): Hata durumunun tespiti için kullanıcıya/geliştiriciye gerekli logların sağlanması

Tepki Ölçüsü (Response Measure): Hata durumunun kolaylıkla tespiti. Gerekli verinin olması

Mimari kararlar

Hassasiyet

(Sensitivity) Ödün (Tradeoff)

Belirli aralıklarla eski logların yedeklenip silinmesi öngörülmeli. 5

Sonuç Yapılan mimari analiz çalışması ile müşteriden gelen iş hedefleri, mimari kaygılar ve teknik kısıtlar dikkate alınarak oluşturulan mimarinin senaryo tabanlı analizi yapılmıştır. Senaryo seçiminde mikro servis mimarisi dikkate alınarak en kritik görülen performans, değiştirilebilirlik ve süreklilik ön planda tutulmuştur. Bu yaklaşım [ 11 ]’de anlatılan endüstri verileri ile de tutarlıdır. Bu çalışmada ayrıca kullanışlılık ve bakım yapılabilirlik ön planda tutulmuş ve analiz edilmiştir. Proje kapsamında ortaya çıkartılan teknik riskler, hassasiyet noktaları ve ödünler dikkate alınarak proje prototip çalışması devam etmektedir. Prototip sonrası mevcut mimari analiz dokümanı prototip sonuçlarına göre güncellenecek ve proje yazılım geliştirme faaliyetleri bu dokümana uyumlu bir şekilde yapılacaktır. Önümüzdeki dönemde mevcut senaryoların daha detaylı analizi yapılacak ve güvenlik kalite özniteliği senaryoları üzerinde çalışmalar yapılacaktır. Projenin sonraki aşamalarında depolanan verilerin derin öğrenme, büyük veri analizi, makine öğrenmesi gibi tekniklerle analiz edilerek karar destek sistemlerinin ortaya çıkması hedeflenmektedir.

Referanslar

References

1. Erl , T. : SOA Design Patterns . Pearson Education , Boston, MA, USA ( 2009 ).

2. Newman , S. : Building Microservices: Designing Fine-Grained Systems. O'Reilly Media , 1st edn . ( 2015 ).

3. https://www.iiconsortium.org/vertical-markets/energy-utility.htm, Last Accessed November 2018 .

4. Kazman , R. , Klein , M. , Clements , P. : ATAM: Method for Architecture Evaluation , TECHNICAL REPORT CMU/SEI-2000-TR-004.

5. Cervantes H. , Kazman R. : Designing Software Architectures A Practical Approach , Addison-Wesley, ( 2016 ).

6. Bass L. , Clements , P. , Kazman , R.: Software Architecture in Practice , 3rd ed., Addison-Wesley , ( 2012 )

7. Byrnes , C. , Kyratzoglou , I. : Applying Architecture Tradeoff Assessment Method (ATAM) As Part Of Formal Software Architecture Review , Technical Report 07- 0094 , The MITRE Corporation, ( 2007 )

8. Kutluca , H. Emre Çetin, İ., Çakır , U. , Kılıç , M. : GEMKOMSİS Savaş Yönetim Sistemi Yazılımının AR-GE Projesi Olarak Geliştirilmesi , Deniz Platformları için Sunduğu Ortak Altyapı ve Sahil Güvenlik Arama Kurtarma Gemisi Uygulaması, Yazılım Kalitesi ve Yazılım Geliştirme Araçları Sempozyumu , İstanbul ( 2008 ).

9. Uyanıksoy , G. , Oğuztüzün , H. , Yazıcı , A. : Bir Çoklu Ortam Veri Yönetim Sistemi Mimarisinin ATAM ile Değerlendirilmesi, Ulusal Yazılım Mühendisliği Sempozyu , İzmir ( 2013 ).

10. Toth , S.: An Inverse Evaluation of Netflix Architecture Using ATAM , SEI Architecture Technology User Network Conference , San Diego ( 2016 ).

11. Bellomo S. , Gorton I. , Kazman R. : Toward Agile Architecture: Insights from 15 Years of ATAM Data , IEEE Software , ( September 2015 ).

12. Ambler S. , Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise , IBM Press, ( 2012 ).

13. ISO IEC 25010: 2011 , https://www.iso.org/standard/35733.html, last visited November 2018 .

14. DMTF Common Information Model (CIM) . http://dmtf.org/standards/cim, Last Accessed November 2018 .