SOA, Service Oriented Architecture, yani Hizmet Tabanlı Mimari. Yazılım geliştirme sürecinde ilk başlarda analiz yaparken ortaya çıkan "iş senaryolarının" ayrı birimler olarak ele alınması ve kendi başına var olabilecek hizmetler olarak tasarlanması olarak yorumlayabiliriz. Her hizmet kendi başına bir iş halleder. Nesne Yönelimli Analiz metodu olarak ne kullanırsanız kullanın (Shlaer-Mellor, Hatley-Pirbhai, UML vesaire.) sonuçta elinizde bir kaç katmana yayılmış hizmetler olacaktır. Veritabanından, grafik arabirime (sunum katmanı) kadar uzanan bu katmanlar birbirleri arasında veri alışverişi yaparak istenilen operasyonu başarmaya çalışır. SOA mimarisi ile tasarlanmış bir uygulamada bakım ve onarım işleri daha ucuza mal olur diyebiliriz. Arayüzlere dokunmadıkça ve giriş çıkış veri formatını değiştirmedikçe içeride her türlü değişikliği yapabiliriz. Ayrıca SOA ile tekrar kullanımı arttırıyoruz ki bu da tekrar eden işlemler için aynı programın tekrar tekrar yazılmasını ortadan kaldırıyor.

İyi bir SOA tasarımının kalitesi ilk etapta yapılan analizin kalitesine bağlıdır. Benim değinmek istediğim konu bir Analyst Developer'ın gerekli araçları temin ederek bu analiz aşamasından yüzünün akı ile çıkmasıdır. Kalitenin anlaşılabilmesi için bazı ölçülere de burada değineceğim.

1- Metodu belirleyin

Analiz aşamasında takip edeceğiniz metod size analizin yapılması için gerekli izlenecek yolu verir. Bu metoda uyduğunuz sürece hata yapma yada bazı adımları atlama olasılığınız en aza inmiş olacaktır. Metodu kendi isteğinize göre de değiştirebilirsiniz fakat yapılan değişikliklerin verimliliği nasıl etkilediği test edilmeli ve metoda kattığı artılar gözler önüne serilmelidir. Belli bir metod ile analiz yapmak ilk etapta yorucu gelebilir (daha önce gelişi güzel analiz yapanlar için), doldurulması gereken formlar ve yazılması gereken belgeler yük olabilir ama yarın bir şeylere ihtiyacınız olduğunda cevaplar bu belgelerde ve formlarda saklı olacaktır ayrıca ortaya çıkacak üründe müşteri gereksinimlerini tam olarak karşılayacak bir ürün olacaktır.

2- Seçtiğiniz metoda uygun bir modelleme aracı kullanın.

Örneğin Hatley-Pirbhai ile analiz yapmaya karar verdiniz. Elinizdeki uygulamanın Data Flow (Veri Akışı) şemalarını çizebiliyor olması gerekir. Çizilen şemaların ekip tarafından paylaşılabilmesi ve yorumların online olarak girilebilmesi gerekir. Böylece ekipten gelecek yorumlar hızlı bir şekilde modellere yansıtılabilinir. Modellerin sürekli el altında olması gerekir.

3- Karmaşık operasyonları bölün

Normalize her aşamada uygulanabilecek bir yöntem. Karmaşık operasyonlar atomize parçalara ayrılarak kodlama süresi kısaltılabilir. Ayrıca hata ayıklama da ve testlerde problemlerin kaynağının doğru olarak bulunmasını kolaylaştırır. Servisleri mümkün olduğunca bölün ve en ufak atomik parçaya varıncaya kadar katmanlar oluşturmaktan korkmayın. Emin değilseniz diğer ekip elemanları ile tartışarak en iyi çözüme ulaşmaya çalışın.

4- Hazır modülleri araştırın

Eğer firmanın yapısı ve müşterinin istekleri izin veriyorsa açık kaynak projelerden yararlanmaya çalışın. Açık kaynak projelerin lisans anlaşmalarını iyi inceleyin ve açık kaynak kullanacağınız projelerin sahiplerini bu konuda haberdar edin. Projelerin tamamını olmasada bazı parçalarını kullanabilirsiniz.

5- Veritabanı ve grafik arayüz değişebilir

Yaptığınız tasarımın hedeflerinden biri de zaman içinde veritabanının ve grafik arayüzün değişimlerinden etkilenmemesidir. Tasarım tamamı ile modüler olmalı ve sadece iş kurallarını uyguladığınız katman sizin için önemli olmalıdır. Veritabanı ve Grafik arayüz tümden çöpe atılıp yeniden geliştirilebilmeli ve iş kurallarını uygulayan katmana kolayca eklenebilmelidir. İşte hizmet tabanlı mimarilerin önemi burada ortaya çıkıyor.

Bir işi analiz ederken veritabanı tablolarını ve grafik arayüzü düşünüyorsanız, büyük ihtimalle ortaya çıkacak dizayn da veritabanına ve grafik arayüze sıkı sıkıya bağlı olacaktır. Unutmayın yarın öbürgün teknoloji ilerler ve veritabanları ile grafik arabirimleri değişebilir (oldu bile, işte Vista ile Avalon geliyor). Bu aşamada programınızın tamamını mı yazmak daha kolay olur yoksa sadece veritabanı ile grafik arayüzünü mü değiştirmek kolay olur? Teknoloji ne kadar ilerlese de işin işleyiş kuralları değişmemiştir. İş gene olduğu gibi gider. Tabii ki özel sektör işleri, devlet birimlerine göre biraz daha statik yapıdadır. Eğer özel sektöre program yazıyorsanız (örneğin bir hava yoluna bilet satış işlerini koordine edecek bir program yazıyorsunuz) iş kuralların değişmesi nadirdir. Fakat devlet birimlerine yazılan programlarda ki iş kuralları genelde değişime uğrar. Yasa değişiklikleri, yeni yasaların gelmesi, bürokrasi ve işleyiş değişiklikleri iş kurallarının değişmesine neden olur. Buda hizmet katmanınızdaki hizmetlerin değişmesi demek olacaktır. Bu durum da SOA mimarisi pek elverişli olmaz. O zaman iş kurallarının parametre haline getirilmesi ve hizmetlerin bu parametreler ile güdümlü olarak çalışması gerekir. Neyse konuyu dallandırmayalım, devlete program yazmak işlerin temelinden başlanmasını gerektirir ve analizlerin çok uzun sürmesi de bundandır. Bu paragrafı toparlarsak; bir işi modellerken sadece işin verdiği tepkileri ve girdi çıktıları modelleyin. Veritabanı ve grafik arayüz en son gelmelidir. Analist Yazılım Uzmanının yapması gereken hem işi bu şekilde modellemek hemde modellere uygun sistemi oluşturmaktır.

SOA mimarilerinde koddan müşteri gereksinimlerine yani geriye doğru takip çok kolaydır. Bu tür bir özellik testlerin yazılmasını da kolaylaştırır ve kaliteyi arttırır. Her servis belli bir işi yapar ve belli iş kurallarını uygular. Her servisin bir belgesi vardır. Belgenin formatı az çok İş Senaryoları belgesine benzer fakat biraz daha teknik bir belgedir. Belgede bulunması gerekenleri aşağıda listeledim. Her belgede olması gereken, içindekiler, değişiklik yönetimi, onay ekibi ve dağıtım listesini geçiyorum.

Servis Dizayn

Alt başlık: Servisin ismi

Bu alt başlıkta kısaca servisin ne yaptığını yazmak gerekir.

Alt Başlık: Tip

Servislerde kendi aralarında katmanlara ayrılabilir. Eğer bir DFD şeması varsa katmanları görmek kolaylaşır, yada iş ve sistem senaryoları olarak ikiye ayrılmış senaryoları gerçekleyen servisler tiplerine göre isimlendirilebilir.

İş Kuralları

Bu servisde uygulanan iş kurallarının bir listesi yada iş kurallarının bulunduğu dökümana link verilebilir.

Servisin Girdileri

Burada servisin işleyeceği verinin yapısı anlatılır. Ne tür bir girdi olacak tablo halinde yazılmalıdır. Eğer veritabanı şekillenmeye başladı ise verinin tipide belirmeye başlamıştır.

Servisin Çıktıları

Servisten beklenen verinin yapısıda burada yazılır.

Varsayımlar

Eğer servisin çalışması için gerekli varsayımlar varsa burada listelenir. Önceden var olması gereken koşullar yada çalışmış olması gereken servisler burada listelenir.

Oluşabilecek Hatalar

Servisin oluşturacağı hataların listesi (exception yada bir hata listesi olabilir) burada listelenir. İleride servisi kullanacak olan programcı (yada bizzat siz) servisin geriye döndüreceği hataları kontrol etmekle hükümlüdür.

Çağırılan Diğer Servisler

Bu servisden çağırılan diğer servisler burada listelenir ve Servis İçerik belgelerine link verilir. Tabii her çağırılan servisin bir de geriye döndürdüğü hata durumları var ve bunların kontrol edilmesi gerekiyor. Eğer bu servisden 100 adet servis çağırıldıysa kontrol edilecek hata listesi bini geçecektir. Bu durumda oluşan hataların yönetimi için bir sistem oluşturulup her servis de uygulanmalıdır. Hazır hata kontrol modülleri mevcuttur, yada açık kaynak bu tür projeler de var.

Akış Şeması

Firma genelinde kullanılan metoda göre burada bir şema yer almalı ve servisin yaptığı işi anlatmalıdır. Servisi kodlarken kullanılacak en önemli kısımlardan biridir. Bu bölümü yazarken kesinlikle programlama dilinden uzak durmanız gerek, aksi takdirde yanlış yorumlamalara yada iş akışında oluşacak farklı durumlara sebebiyet verilmiş olunur. Eğer yukarıda belirttiğim gibi modelleri oluşturmak için bir araç kullanıyorsanız ve modeller iç-örütbağı üzerinden erişilebilir ise, bu servisin ilişkili olduğu modele bir link te verebilirsiniz. Bakımı daha kolay olur.

Test Senaryoları

Yukarıda bu servisin geriye döndüreceği hata durumlarını yazdınız, şimdide bu hata durumlarını meydana getirecek durumları listelemeniz gerekiyor. Servis kodlanıp test aşamasına geldiği zaman bu test senaryolarında bulunan senaryolar kullanılacaktır. Eğer TDD (Test Driven Development - Test Güdümlü Yazılım Geliştirme (felaket bir çevirim oldu :-)) ) yapıyorsanız kodlamaya bu test modelinden başlayacaksanız demektir. Testler için kullanılacak veriyide tablolar halinde yazın.

Kullanıldığı Yerler

İlerleyen zamanlarda bu servisin çağırıldığı servisler buraya kaydedilir. Yada link verilebilir. Söz konusu servis değişikliğe uğradığında buradaki listede bulunan servisler de bu değişiklikten haberdar edilmelidir. Böylece değişikliklerden kimler etkilenecek sorusunun yanıtını anında alabilirsiniz başımızdaki saçlar da yerinde daha uzun durur.

Görüldüğü gibi bazı kurallara uyarak yazılım geliştirmek gerçekten de hatırı sayılır bir kaliteye ulaşmamızı sağlıyor. Ortaya çıkan belgelerin ve modellerin yönetimi, erişimi, kontrolü ve değişimi ne kadar kolay ve sorunsuz ise yapılan işin kaliteside o kadar artıyor.

Kaliteli günler dilerim.

Reklamlar


Bu girdiye atılan yorumlar:

# SOA ve Proje Analizi | Yakup Bu??ra

SOA ve Proje Analizi | Yakup Bu??ra

Pingback/TrackBack tarafından  9/9/2009 12:16 AM tarihinde atılmıştır.
# re: SOA ve Proje Analizi

babacan ellerine sağlık. zor bulunan bir konuda güzel bilgilere ulamışsın.

Doğan tarafından  12/4/2009 9:45 PM tarihinde atılmıştır.
# SOA: Service Oriented Architecture (Servis Odakl?? Mimari) « Base Teknoloji

SOA: Service Oriented Architecture (Servis Odakl?? Mimari) « Base Teknoloji

Pingback/TrackBack tarafından  1/24/2010 10:46 AM tarihinde atılmıştır.

Yorumunuzu buradan giriniz

Yorumlar onaylandıktan sonra yayınlanacaktır

*


*


 (Görüntülenmeyecek)


 (İsminizde link olarak görüntülenecek)


*
Bold Italic Underline Blockquote Hyperlink Hyperlink

 

Please add 4 and 7 and type the answer here:

Yorum Önizleme:

 

Arama



Hakkımda

Merhaba, ben Gürkan Yeniçeri. 10 yılı aşkın süredir özel sektör ve hükümet iştiraklerinde yazılım mühendisliği yapıyorum. Bu sitede 2005 Mart ayından beri genelde yazılım mühendisliği ve hobilerim hakkında yazmaktayım. Profesyonel iş geçmişim hakkında daha fazla bilgiyi aşağıdaki Linkedin.com linkinden alabilirsiniz.
Gürkan Yeniçeri'nin profilini görmek için tıklayın

Kontak

Soru sormak veya öneride bulunmak isterseniz buradaki kontak formunu kullanın. Mesajlarınıza en kısa zaman içinde cevap vermeye çalışacağım. Ayrıca Windows Live Messenger kullanarak gyeniceri {AT} hotmail {DOT} com adresinden bana ulaşabilirsiniz.

Eğer İngilizce blogumu okumak isterseniz buraya buyrun.
Blogumu RSS Bandit gibi bir RSS okuyucusu ile de takip etmek için kullanın.
Ayrıca aşağıdaki linklerden hakkımda ayrıtılı bilgi alabilirsiniz.
Twitter
Friendfeed
Facebook

RSS 2.0

Reklamlar


Vezir

Vezir Proje Danışmanı
Sitede birde Vezir isminde wikimiz var. Bu wikiyi yazmayı düşündüğüm bir kitap için oluşturmuştum daha sonra herkese açmaya karar verdim. Vezir yazılım firması kurmak isteyenlere tavsiyeler vermek için hazırlandı. Ayrıca UML ve Modül Tabanlı Geliştirme hakkında da bilgiler mevcut. Vakit buldukça yeni eklemeler yapıyorum. Değişikliklerden haberdar olmak için RSS çıktısına üye olabilirsiniz.

Tag Bulutu

Tüm taglar...
www.flickr.com
This is a Flickr badge showing public photos from gurkanyeniceri. Make your own badge here.
Bu blogda 265 yazı ve 509 yorum var. Diğer sitelerden 26 adet link gelmiş.

Reklamlar