Giriş
2010 UYMK konferansında ASELSAN'ın yazılım ürün hattı bildirileri ön plana çıkmış. Önemli buluğum bazı cümleleri not aldım . Yazılım ürün hattı prensibine göre geliştirilen bir projenin ismi "Teknik Ateş Destek Sistemleri Yazılım Ürün Hattı"
Yazılım Ürün Hattı Ne Değildir?
Kodu veya component'leri tekrar kullanmak (re-use) yazılım ürün hattı olmayı sağlamaz!
Yazılım Ürün Hattı Nedir?
Yani yazılım ürün hattında birden çok yazılım olabilir. Aslında yazılım ürün hattının bir diğer ismi ise sistem ailesidir. (system families)
Variance ve Feature
Değişkenlikler (variance) işlevsel (functional) veya donanımla alakalı olabilir. Değişkenlikleri ele alabilmek için feature denilen bir kavram kullanılıyor.
Ürün Hattı Temel Varlıklarını Oluşturma
Burada dikkatimi çeken şey her analiz işleminde olduğu gibi önce temel varlıkların çıkartılması işlemi ile başlanmış. Temel varlıklar kullanılarak ürün zaten geliştiriliyor ve daha sonra var olan ürünler ürün hattına dönüştürülüyor.
Temel varlıkların oluşturma sürecini gösteren bir şekli buradan aldım.
Ürün Hattı Temel Varlıklarını Oluşturma aşamasında önce bir İşletme Konsepti dokumanı hazırlanmış. Bu dokümanda ürün hattı yaklaşımına geçişin nedenleri, öngörülen çalışmalar ve yaklaşıma geçişin adımları
ifade edilmiş. Aslında yazılım mühendisliği açısından bu dokümanın bir çok SEI dokümanında olduğu gibi fazlaca bir önemi, bence bulunmamakta. Ama yine de not almak istedim.
Daha sonra planlama safhasında çıktı olarak bir "Kapsam Dokümanının" hazırlanmasına karar verilmiş.
Bu adımdan sonra "Alan Mühendisliği" ve "Uygulama Mühendisliği" safhasına geçilmiş. Bu durumu gösteren bir şekli buradan aldım.
Daha sonra ise bir "Ürün Ağacı" oluşturulmuş. Bu ürün ağacında zorunlu ve seçilebilir özellikler sıralanmış.
Alan Mühendisliği Nedir?
Yukarıdaki yazıda da belirtildiği gibi, alan mühendisliği temel varlıklara dayanıyor.
Bu konuda güzel bir yazı ise Çağatay Çatal tarafından kalem alınmış "Geleneksel Yazılım Mühendisliğinden Alana Özel Yazılım Mühendisliğine Doğru" başlıklı yazı. Bu yazıda Alana, İşletme ve Teknoloji boyutu da katılmış. Teknoloji ve İşletme boyutları bence işi çok daha karmaşık hale getiriyor. Bu yüzden bu yazıda ele almak istemiyorum. Şekildeki Alana Özel Yazlım Mimarisi konusuna da şu anda değinmeyeceğim.
Alana Özel Yazılım Mühendisliği Süreci
Yukarıdaki "Alan Mühendisliği" ve "Uygulama Mühendisliği" şeklinde Alan'ı geliştirirken izlenecek klasik yazılım mühendisliği adımları gösterilmiş. İşin esas can alıcı yerini gösteren şekili ise Çağatay Çatal'ın yazısından alıntı yaparak aşağıya ekledim.
Alan Modeli Nedir?
Alan Modeli (Domain Model) bir alan hakkında bilgiler içeren çıktılar kümesi. Yukarıda bahsedilen temel varlıkların belirlendiği etli butlu kısım.Alan modelinde bulunması arzu edilen elemanları gösteren bir şekil ise aşağıda.
Bilgi Modeli Nedir?
Bilgi Modeli (Information Model) denilince, insanlar UML ile çizilmiş şekilleri düşünüyorlar. Bilgi modeli daha üst seviyeden kavramsal bir bakış sunuyor. Örneğin UML ile çizimiş Nesne Diyagramı (Object Diagram) ile Varlık Ilışki Diyagram (E-R diagram) farklı modelleme dilleri kullanılarak geliştiriliyorlar, ancak ikisi de Bilgi Modeli kapsamına girer. Yani Bilgi Modeli herhangi bir dil ve araçtan bağımsızdır.
Sistem ve Yazılım Gereksinimleri
Ürün hattı ve ve projeye mahsus sistem/yazılım gereksinimleri ayrı olmalı.
Referans Mimari
Bu konuyu şimdilik es geçiyorum.
Yeniden Yapılandırılabilir Bileşenler
2011 yılındaki bir başka bildiride ise daha alt seviyeye inerek Yeniden Yapılandırılabilir Bileşenlerden bahsediliyor. Örneklerde Fabrika (Factory) Tasarım örüntüsü kullanılıyor. Bence AbstractFactory de bileşenler için vazgeçilmezlerden birisi.Fabrikanın kullanacağı yapılandırma bilgisi ile bir arayüz aracılığıyla kolayca atanabiliyor.
Bir başka yöntem ise C'deki ifdef'ler ile derleme esnasında bazı özelliklerin eklenip çıkarılması.
Ben ifdef yöntemini tercih etmiyorum.
Arayüzler
Sistemde bileşen sayısı arttıkça ve dağınık hale geldikçe, birleştirme daha da güçleşiyor. Bu konuda iki yaklaşım var.
İlk yaklaşım dikişsiz birleştirme (seamless integration) yöntemi. Tüm bileşenlerin arayüzden gelen bilgisi çevirmeden kendi iç veri yapısında kullanması.
İkinci yöntem ise kendi iç veri yapısına dönüştürmesi.
Bu konuyu daha sonra detaylandırmam lazım.
Ürün Hattının İdamesi ve Geliştirilmesi
Şekilden ürün hattının zaman içinde çok farklı donanım ve işletim sistemlerinde çalışması gerektiği görülebilir.
2010 UYMK konferansında ASELSAN'ın yazılım ürün hattı bildirileri ön plana çıkmış. Önemli buluğum bazı cümleleri not aldım . Yazılım ürün hattı prensibine göre geliştirilen bir projenin ismi "Teknik Ateş Destek Sistemleri Yazılım Ürün Hattı"
Yazılım Ürün Hattı Ne Değildir?
Kodu veya component'leri tekrar kullanmak (re-use) yazılım ürün hattı olmayı sağlamaz!
Yazılım Ürün Hattı Nedir?
Yazılım Ürün Hattı Yaklaşımında belli bir ürün ailesine mensup yazılımlar, bu ürün ailesinin ortaklıkları ve değişkenlikleri göz önünde bulundurularak, önceden oluşturulmuş ürün yapıtaşlarının bir araya getirilmesiyle oluşturulur. Bu bir araya getirme işlemi klasik yazılım geliştirme yönteminden daha çok bir yazılım entegrasyonuna benzer.Ürün ailesi için - Groups of similar products - terimi de kullanılıyor.
Yani yazılım ürün hattında birden çok yazılım olabilir. Aslında yazılım ürün hattının bir diğer ismi ise sistem ailesidir. (system families)
Yazılım ürün hattına geçiş, genelde üç adımda gerçekleştirilmektedir. Bu adımlar "Ürün
Hattı Temel Varlıklarını Oluşturma", "Temel Varlıkların İdamesi ve Ürün Geliştirme" ve
"Ürün Hattının İdamesi ve Geliştirilmesi" olarak ifade edilmektedir
Variance ve Feature
Değişkenlikler (variance) işlevsel (functional) veya donanımla alakalı olabilir. Değişkenlikleri ele alabilmek için feature denilen bir kavram kullanılıyor.
Ürün Hattı Temel Varlıklarını Oluşturma
Burada dikkatimi çeken şey her analiz işleminde olduğu gibi önce temel varlıkların çıkartılması işlemi ile başlanmış. Temel varlıklar kullanılarak ürün zaten geliştiriliyor ve daha sonra var olan ürünler ürün hattına dönüştürülüyor.
Temel varlıkların oluşturma sürecini gösteren bir şekli buradan aldım.
Ürün Hattı Temel Varlıklarını Oluşturma aşamasında önce bir İşletme Konsepti dokumanı hazırlanmış. Bu dokümanda ürün hattı yaklaşımına geçişin nedenleri, öngörülen çalışmalar ve yaklaşıma geçişin adımları
ifade edilmiş. Aslında yazılım mühendisliği açısından bu dokümanın bir çok SEI dokümanında olduğu gibi fazlaca bir önemi, bence bulunmamakta. Ama yine de not almak istedim.
Daha sonra planlama safhasında çıktı olarak bir "Kapsam Dokümanının" hazırlanmasına karar verilmiş.
Kapsam Dokümanı: Temelde yazılım ürün hattının hangi ürünleri içereceğini belirler.İşte burada ne can alıcı bir noktaya değinilmiş. Projenin kapsamı ortaya çıkmış.
TADES kapsamında Teknik Ateş Destek Yazılımları olarak geliştirilmiş ve
geliştirilecek olan ürünler müşteri bakış açısıyla ve teknik benzerlikleri açısından QFD
Analizi yöntemi kullanılarak değerlendirilmiş ve kapsam belirlenmiştir.
Bu adımdan sonra "Alan Mühendisliği" ve "Uygulama Mühendisliği" safhasına geçilmiş. Bu durumu gösteren bir şekli buradan aldım.
Daha sonra ise bir "Ürün Ağacı" oluşturulmuş. Bu ürün ağacında zorunlu ve seçilebilir özellikler sıralanmış.
Alan Mühendisliği Nedir?
Yukarıdaki yazıda da belirtildiği gibi, alan mühendisliği temel varlıklara dayanıyor.
Bu konuda güzel bir yazı ise Çağatay Çatal tarafından kalem alınmış "Geleneksel Yazılım Mühendisliğinden Alana Özel Yazılım Mühendisliğine Doğru" başlıklı yazı. Bu yazıda Alana, İşletme ve Teknoloji boyutu da katılmış. Teknoloji ve İşletme boyutları bence işi çok daha karmaşık hale getiriyor. Bu yüzden bu yazıda ele almak istemiyorum. Şekildeki Alana Özel Yazlım Mimarisi konusuna da şu anda değinmeyeceğim.
Alana Özel Yazılım Mühendisliği Süreci
Yukarıdaki "Alan Mühendisliği" ve "Uygulama Mühendisliği" şeklinde Alan'ı geliştirirken izlenecek klasik yazılım mühendisliği adımları gösterilmiş. İşin esas can alıcı yerini gösteren şekili ise Çağatay Çatal'ın yazısından alıntı yaparak aşağıya ekledim.
Alan Modeli Nedir?
Alan Modeli (Domain Model) bir alan hakkında bilgiler içeren çıktılar kümesi. Yukarıda bahsedilen temel varlıkların belirlendiği etli butlu kısım.Alan modelinde bulunması arzu edilen elemanları gösteren bir şekil ise aşağıda.
Bilgi Modeli (Information Model) denilince, insanlar UML ile çizilmiş şekilleri düşünüyorlar. Bilgi modeli daha üst seviyeden kavramsal bir bakış sunuyor. Örneğin UML ile çizimiş Nesne Diyagramı (Object Diagram) ile Varlık Ilışki Diyagram (E-R diagram) farklı modelleme dilleri kullanılarak geliştiriliyorlar, ancak ikisi de Bilgi Modeli kapsamına girer. Yani Bilgi Modeli herhangi bir dil ve araçtan bağımsızdır.
Sistem ve Yazılım Gereksinimleri
Ürün hattı ve ve projeye mahsus sistem/yazılım gereksinimleri ayrı olmalı.
Referans Mimari
Bu konuyu şimdilik es geçiyorum.
Yeniden Yapılandırılabilir Bileşenler
2011 yılındaki bir başka bildiride ise daha alt seviyeye inerek Yeniden Yapılandırılabilir Bileşenlerden bahsediliyor. Örneklerde Fabrika (Factory) Tasarım örüntüsü kullanılıyor. Bence AbstractFactory de bileşenler için vazgeçilmezlerden birisi.Fabrikanın kullanacağı yapılandırma bilgisi ile bir arayüz aracılığıyla kolayca atanabiliyor.
Bir başka yöntem ise C'deki ifdef'ler ile derleme esnasında bazı özelliklerin eklenip çıkarılması.
Ben ifdef yöntemini tercih etmiyorum.
Sistemde bileşen sayısı arttıkça ve dağınık hale geldikçe, birleştirme daha da güçleşiyor. Bu konuda iki yaklaşım var.
İlk yaklaşım dikişsiz birleştirme (seamless integration) yöntemi. Tüm bileşenlerin arayüzden gelen bilgisi çevirmeden kendi iç veri yapısında kullanması.
İkinci yöntem ise kendi iç veri yapısına dönüştürmesi.
Bu konuyu daha sonra detaylandırmam lazım.
Ürün Hattının İdamesi ve Geliştirilmesi
Şekilden ürün hattının zaman içinde çok farklı donanım ve işletim sistemlerinde çalışması gerektiği görülebilir.
Hiç yorum yok:
Yorum Gönder