Thread Local Storage

Thread Local Storage
Thread Local Storage konusu gördüğüm tüm işletim sistemlerinde var.

POSIX
Tüm örneği buradan aldım. POSIX her zamanki gibi kullanması çok zor, karmaşık metodlar sunuyor.

pthread_key nesnesi
Bu nesne bir çeşit key-value eşleştirmesi yapan bir tablo. Şöyle tanımlanıyor. Bu tablo bir çeşit global değişken aslında. Uygulama içinde bir kere tanımlanması gerekir. Storage process için bir kere açılıyor.

pthread_key_t glob_var_key;

pthread_key_create metodu
Yukarıda tanımlanan tablonun ilklendirilmesi gerekir. Bunun için pthread_key_create metodu kullanılıyor.

pthread_key_create(&glob_var_key,NULL);

Thread bitince, bu metod ile belirtilen destructor metodu da çağırılır.

pthread_set_specific

Bu metod ile yukarıda tanımlanan tablonun anahtar alanına malloc ile yaratılmış bir alan atanıyor.

void* thread_func(void *arg)
{
    int *p = malloc(sizeof(int));
    *p = 1;
    pthread_setspecific(glob_var_key, p); //Tabloya değer ata
    do_something();
    do_something();
    pthread_setspecific(glob_var_key, NULL); //Tablodaki değeri sil
    free(p);
    pthread_exit(NULL);
}

pthread_get_specific
Bu metod ile tablo aynı bir array gibi kullanılıyor.

void do_something()
{
    //get thread specific data
    int* glob_spec_var = (int*) pthread_getspecific(glob_var_key);
    printf("value is %d\n", *glob_spec_var);
    *glob_spec_var += 1;
    printf("value is %d\n", *glob_spec_var);
}

Java
ThreadLocal Sınıfı yazısına taşıdım.

C#
Java gibi ThreadLocal isimli bir sınıf kullanıyor.

MIL STD 498

Not : Bu yazı ile ilgili olarak CMMI başlıklı yazıyı okuyabilirsiniz.

MIL-STD-498

Savunma sanayimizin öncü kuruluşlarından olduğunu iddia eden bir çok firmada kullanılan yazılım geliştirme standardı MIL-STD-498. Vakti zamanında (1994 yılında) başlatılan bu standart 1998 yılında iptal edilmiş olmasına rağmen, maalesef iç piyasamızda halen kullanım görmekte. Bu sürecin yerini IEEE 12207 aldı. IEEE 12207,  daha fazla yaşam döngüsü odaklı.

Sürecin ne kadar High Ceremony ( ki bence hantal kelimesinin daha kibarca söylenmiş hali ) olduğunu gösteren bir şekli buradan aldım.

Süreç boyunca üretilen bazı dokümanları gösteren bir şekli ise buradan aldım.

Her ne kadar yukarıdaki şekilde iterative (tekrarlamalı/yinelemeli) yaklaşımdan bahsedilse bile hiç bir zaman kullanıldığına şahit olmadım.

2012 yılında bile yazılımların şelale modelinde geliştirilmesine sebep olan bu süreci kullanmaya devam eden (bir doküman bir kere onaylanınca kimse geriye dönüp onunla bir daha oynamak istemiyor, dolayısıyla ister istemez şelale yöntemine doğru kayılıyor) firmaları anlayamıyorum !

Türk Silahlı Kuvvetlerini Güçlendirme Vakfı firmaları (Aselsan, Roketsan, Havelsan, İşbir, Aspilsan) sırtlarını vakfa dayadıkları için ticari kaygıları diğer firmalara göre daha az. Ancak vakıfın iştiraki olmayan ticari müesseselerin bu hantal model ile esnekliklerini kaybetmelerine rağmen, ısrarla bu alışkanlıktan vazgeçmemeleri bence çok yazık !.

Data Item Description (DID)
DID üretilmesi beklenen belge anlamında düşünülebilir. MIL-STD-498 tam 22 tane DID tanımlıyor. Her DID'in içeriği ve şekli belirli. Her ne kadar belgenin şeklini değiştirmek mümkün olsa da, tüm DID'lerin gerçekten işe yaradığını söyleyebilmek ve hakkını vererek yazıldığını söyleyebilmek çok zor. Bu DID'lerden hangilerinin müşteriye teslim edileceği, CDRL belgesinden tanımlanır.

Örnek Proje Takvimi

• Proje Başlangıcı : T0
• SRR (Sistem Gereksinimlerini Gözden Geçirme Toplantısı) : T0 + 3
• PDR (Ön Tasarım Gözden Geçirme Toplantısı) : T0 + 6
• CDR (Kritik Tasarım Gözden Geçirme Toplantısı) : T0 + 8
• Ön Entegrasyon 1 : T0 + 10
• Ön Entegrasyon 2 : T0 + 13
• FAT : T0 + 19
• Kesin Kabul : T0 + 27

Bazı Kelimeler ve Türkçeleri

SDP : Software Development Plan
SDP başlıklı yazıya göz atabilirsiniz.

CSCI : Computer Software Configuration Item. Official definition of CSCI (Computer Software Configuration Item) başlılı soruya göz atılabilir. Aselsan'da Yazılım Konfigürasyon Birimi (YKB) kelimesi kullanılıyor. Kabaca geliştirilen uygulama anlamına geliyor. Bir proje altında birden fazla uygulama olabilir Her CSCI CSC'lerden oluşur. Her CSCI için SRS ve SDD gerekir.

CSCI versiyon numaraları genellikle X.Y.Z (Major.Minor.Patch) şeklinde verilir. Açıklaması ise aşağıda.

Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version.

ICD : Interface Control Document. Yazılım Arayüzü başlıklı yazıya göz atabilirsiniz.

IDD : Interface Design Document. Yazılım Arayüzü başlıklı yazıya göz atabilirsiniz.

Sözleşme : Kontrat, Tender Document gibi isimlerle anılır. Sözleşme bir çok eklerden oluşabilir. Bir çok gereksinimim, çıkış noktası sözleşme ve ekleridir.

ECP: Engineering Change Proposal. Mühendislik Değişikliği Önerisi. Sözleşme kapanmadan yapılan değişikliği belirtir. ECP'ler ECP-1, ECP-2 olarak adlandırılır. Toplantı tutanağıyla kayıt altına alınır.

MKN : Mühendislik Koordinasyon Notu

FAR : Fault Analysis Report

SRS :
Software Requirements Specification başlıklı yazıya taşıdım.

SSDD: System/Subsytem Design Document
SSDD başlıklı yazıya taşıdım.

SDD :
SDD başlıklı yazıya taşıdım.

SBM : Software Build Manual. CM tarafından adım adım takip edilerek doğrulanır. Bazı şirketler SBM belgesinde izlenebilirlik istiyorlar. Ayrıca SBM gözden geçirilir ve yayınlanır.


CDR :
CDR başlıklı  yazıya taşıdım.

UITD : Unit Integration Test Description

UTD :
Unit Test Description başlıklı yazıya taşıdım.

STP :
Software Test Plan başlıklı yazıya taşıdım.

STD :
Software Test Document başlıklı yazıya taşıdım.

STR : Software Test Report. Aselsan'da Yazılım Test Raporu (YTER) kelimesi kullanılıyor. Koşturulan testler ve sonuçlarını gösteren rapor.

Kısaltmalardan sonra akışa bir göz atacak olursak aşağıdakine benzer bir silsile izleniyor. Aşamalar projelere göre farklı isimler alabiliyor. Farklı yöntemler de izlenebilir. Sadece örnek olsun diye yazıyorum.

Belgelerde Kullanılan Gizlilik Seviyeleri
Çok Gizli -> Top Secret
Gizli -> Secret
Özel -> Confidential
Hizmete Özel -> Restricted
Tasnif Dışı -> Unclassified

----------------------------------------------------------------------------------------------------
T0 (Proje Başlangıcı) --> Genellikle bir avans alınır.

SRR (System Requirements Review. Türkçesi Sistem Gereksinimleri Gözden Geçirme Toplantısı)
Sistem gereksinimlerinin ortaya konulduğu aşama
SRR'da teslim edilen bazı belgeler şunlar.

SSS : System/Subsystem Specification

PDR (Preliminary Design Review. Türkçesi Ön Tasarım Gözden Geçirme Toplantısı)
Ön Tasarım yapıldıktan sonra gelinen aşama. PDR'da teslim edilen bazı belgeler şunlar.

SSDD : System/Subsystem Design Document
SRS : Software Requirements Specification
ICD : Interface Control Document

Not : PDR'dan önce bu belgelerde izlenebilirlik (traceability ) bilgisinin olması, gözden geçirilmiş olup, baseline yapılmış olması gerekir. Baseline (anahat) için bazen aşağıdaki kelimeler de kullanılır.

Functional Baseline (SSS)
Allocated Baseline (SRS,IRS)
Design Baseline (SSDD,SDD)
Product Baseline (Nihai ürün)

Müşteri ile gerçek PDR toplantısı yapmadan önce, ekip içinde çatlak ses çıkmaması için bir prova yapılmasında fayda var.


Bu aşamada yazılım gereksinimleri doğrulanır. PDR genellikle ödeme kilometre taşıdır. Bazen seçilen donanımın onayı da bu aşamada verilir. Projenin %25-30 arası bedeli bu kilometre taşı geçildikten sonra ödenir. Dolayısıyla güvenilirlik ve maddi açıdan önemlidir. PDR tamanlanınca ve açık işlem maddeleri kapatılınca, resmi yazı ile PDR'ın başarı ile tamamlandığı bildirilir.

PDR'ı takiben CDR yapılır.


CDR  (Critical Design Review. Türkçesi Kritik Tasarım Gözden Geçirme Toplantısı)

Müşteri ile gerçek CDR toplantısı yapmadan önce, ekip içinde çatlak ses çıkmaması için bir prova yapılmasında fayda var.

Bazı projelerde CDR aşamasında artık nihai karar verildiği için sistemle/yazılımla ilgili ölçümler verilebilir veya talep edilebilir.

Development -->
Bir çok farklı test kademesi kullanmak faydalı. Özellikle pahalı donanımların olduğu projelerde gerçek donanıma gelmeden önce mümkün olduğunda simülatör, emülatörlerle testler koşturmak gerekir.

Ön Entegrasyon : FAT testinden önce yapılan tümleşim testi. Sistemi daha küçük parçalar halinde birleştirmek için kullanılır. Ön entegrasyon testinden önce kod için ayrı bir branch açmak iyi bir fikir olabilir. Geliştirme devam ederken, testte çıkan hatalar da branch üzerinde düzeltilebilir. Ön entegrasyon testi bittikten sonra tutanak tutulur.

FAT (Fabrika Kabul Test) : Fabrika/Laboratuvar ortamında yapılan test provası --> Tüm paydaşların hazır olduğu noktada başlanabilir. Geciken bir paydaş, tüm takvimi öteleyebilir.

FAT-SYS, SEL vs. gibi farklı isimler olan bir aşama : Bu aşamada tüm sistem bir araya getirilerek gerçek sensörler simüle ediliyorlar. Bu aşamaya projesine göre farklı isimler veriliyor.-->
Konuyu FAT Testi yazısına taşıdım.

HAT : Eğer gerekiyorsa gerçek sensörlerin kullanıldığı aşama -->

SAT (Örneğin geminin denize açılıp test yapması veya mevzide test yapılması). SAT testleri genelde stresli olurlar. Bu aşamada konu başlıklarına göre testlerin yapılması işleri hızlandırabilir.

Donanım Tederaik Aşaması:
Önce RFQ (Request for Quote) istenir. RFQ yanıtları sonrası BAFO (Best and Final Offer)

GUI ve Thread

GUI çatısılarının tamamı tek thread'le çalışırlar. Dolayısıyla arka planda çalışan bir thread'den GUI'yi güncellemek her zaman dikkatli olmayı gerektirir. Aşağıda konuyla ilgili bazı notlarım var.

.Net

WPF
Aşağıdaki örnekler WPF ile ilgili

QueueUserWorkItem metodundan UI thread'e mesaj yollamak

UI Thread'e mesaj yollamak için Dispatcher.Invoke() veya Dispatcher.BeginInvoke() metodlarından birisi kullanılabilir. 

Burada sorusunda da açıklandığı gibi System.Windows.Threading.Dispatcher.BeginInvoke(Delegate) metodu worker thread içinde çağırılınca UI thread'e bir mesaj yollar. Mesaj UI thread içinde çalıştırılır. Worker thread ise BeginInvoke metodundan sonraki kodu çalıştırmaya devam eder.

Bir başka örnek:

WPF'i Başka Bir Thread İçinde Çalıştırmak

Burada birden fazla WPF Dispatcher threadini başlatma yolu gösteriliyor. Open window inside a thread başlıklı yazı da okumaya değer.

WinForms

Winforms bileşenlerini sadece belli metodları başka bir thread içinde çağırılabilir. Bunlar Invoke(), BeginInvoke(),EndInvoke() ve CreateGraphics() metodlarıdır.

BackgroundWorker

BackgroundWorker yazısına taşıdım.

Thread Sınıfından GUI'ye Mesaj Yollamak

Control sınıfının Invoke metodu kullanılır. Örnek:

public class MyFormControl : Form
{
    public delegate void AddListItem();
   
    public MyFormControl()
    {
        myDelegate = new AddListItem(AddListItemMethod);
    }
    public void AddListItemMethod()
    {
    }
}

public class MyThreadClass
{
    public void Run()
    {
        myFormControl1.Invoke(myFormControl1.myDelegate);
    }
}

Control sınıfı Örnekleri

CheckForIllegalCrossThreadCalls alanı

Bu alana false değeri atanırsa, bir baaşka thread'den GUI'ye erişildi uyarısı alınmaz.

sed komutu

sed ve execute
Örnekte sed komutu s ile substitude yaptıktan sonra çıktı /e verildiği için çalıştırılıyor.

echo AAA | sed -r 's/A/echo B/ge'

Komut aslında şuna denk

echo AAA | sed -r 's/A/echo B/g' | sh

sed ve delete
sed substitude s/a/b/g şeklinde çalışıyor. Delete ise /a/,/b/d şeklinde çalışıyor. Aradaki virgüle dikkat!

Blokları şeklinde silmek için örnek. History kelimesini içeren ilk satır ile Date kelimesini içeren ilk satır bloğu silinir.

$ sed -i '/History/,/Date/d' file

History kelimesinden sonra gelen 5 satırı silmek için şöyle yapılır

$ find . -print0 -name *.h | xargs -0 sed -i '/History/{N;N;N;N;N;d;}' file

sed ve substitude
substitute ve ayraç
sed komutunda substitude için kullanılan örüntü şu şekilde. s harfinden sonra gelen ilk karakter ayraç (delimeter) olarak algılanıyor. İlk ayraçtan sonra gelen düzenli ifade aranılan şey, ikinci ayraçtan sonra gelen kelime ise yer değiştirmesi istenen değer. Ayraç olarak aranan ifade içinde olmayan herhangi bir karakter kullanılabilir.
Ayraç olarak pipe kullanımı

sed -i "s|$line|$line_new|g" /etc/myconfig

Ayraç olarak yüzde karakterinin kullanımı

sed -i "s%$line_old%$line_new%g" /etc/myconfig

Ayraç olarak diyez kullanımı

sed -i "s#DONEDIRECTORY#$DoneDirectory#" *TestFile*

substitude - yer değiştirme amaçlı
Basit bir örnek
test kelimesini real ile değiştirme

find . - name "*.cpp" | xargs sed -i "s/test/real"

substitude - silme amaçlı
Satırdaki tüm eşleşmeleri silmek
Örnek:
Aranan şey 3 veya 4'ü takip eden : karakteri ile başlayan bir kelime.
\b ile word boundary ile başlaması sağlanır \S ile non-space ile devam etmesi ve daha sonra \s ile boşluk ile devam etmesi sağlanır. Eşleşme sağlayan bir örnek 3:11 olabilir.

sed 's/\b[34]:\S*\s*//g' file

Satırdaki Belirli Bir Eşleşmeyi Silmek

İkinci virgülü silmek için örnek: g2 ile her satırdaki ikinci eşleşme belirtilir.

$ sed 's/,//g2' file

C++ ve Operator

Giriş
C++ ile bir sınıfa tanımlanabilecek çok sayıda operator var. Aşağıda notlarım var.

Operator Sadece İfadenin Bir Tarafı Bizim Sınıfımız İse Kullanılabilir
Operator overloadin için ifadening sağ veya sol tarafından birisi user defined bir tip olmalı. Her iki tarafı da int olan bir ifadede örneğin / operatörünü overload edemeyiz.

== (Eşitlik) operatörü
Eşitlik operatörü iki şekilde kullanılabiliyor. Bunlar sınıfın == metodu olarak tanımlanması veya global bir metod olarak tanımlanması.

Sınıfın İçine Tanımlama
Metod parametresi ve metodun kendisi const olmalı
Örnek:  

bool operator == (const ContourEdgeIndexes& rhs) const {} 

Global Tanımlama
Örnek:

bool operator == (var const& v1, var const& v2)
{
    return (v1.name == v2.name) && (v1.value == v2.value);
}

= (Değer Atama ) operatörü
Değer atama öperatörü eğer kodlanmamışsa derleyici tarafından otomatik üretilir.

Üretilen Operatör Nasıl Çalışır
Her bir elemanı teker teker diğer değişkene kopyalar.

The implicitly-defined copy assignment operator for class X performs memberwise assignment of its subobjects. ... Each subobject is assigned in the manner appropriate to its type

Kopyalanan değişken value array ise
Value array olsa bile doğru çalışır.

if the subobject is an array, each element is assigned, in the manner appropriate to the element type

Örnek'te struct1 ve struct2'nin sahip oldukları num dizisi deep copy olacak şekilde kopyalanır. struct1'in num dizisini değiştirsek bile struct2 etkilenmez.

struct myStruct {int num[3];};
myStruct struct1={{1,2,3}};
myStruct struct2;
struct2 = struct1;

Assignment Operatörü 3 Kısımdan Oluşur

Assignment operatörü 3 kısımdan oluşur.
l-value, assignment operator, value veya r-value. Normalde assignment operator C++, Java, C# gibi dillerde expression (yani ifade) olarak kabul edilir. Bazı daha az kullanılan dillerde ise Expression değil Statement olarak kabul edilir. Expression ve Statement (yani deyim) arasındaki fark şudur

Expression: Something which evaluates to a value. Example: 1+2/x
Statement: A line of code which does something. Example: GOTO 100

Aşağıdaki örnekte expression sonucunda bir değer çıkar ve x değişkeni z'nin değerini alır.

x = (y = z);    // ok, 'x' gets the value of 'z'

Assignment ve Initialization Farklı Şeylerdir

Değer atama operatörü çoğunlukla ilklendirme (initialization) aşamasında kafa karşıklığına sebep oluyor. Aşağıdaki kural netliği sağlar.

Initialization is not assignment.

Nesne ilk defa yaratılıyorsa = operatörü ile değer atansa bile, operatör metodu değil, constructor çağırılır. Örneğin aşağıdaki kodda std::string nesnesinin constructor'ı işletilir.

std::string a = "foo";

Bu kod parçası ise operatörü çağırır.

std::string a; a = "foo";

Assignment ve std::pair

std::pair için özel tanımlanmış  = operatörü bulunuyor.

Bu atama operatörü ile
std::pair <int,int> bar = std::make_pair (10.5,'A'); //ok: implicit conversion from pair<double,char>
yapılabilir.


-> operatörü
Bir sınıfı sarmalayan başka bir sınıf için tanımlanır.

MyObject* MyWrapper::operator -> ()
{
  return m_ptr;
}

++operatörü
Bu operatör aşağıdaki gibi tanımlanabilir.

Eğer pointer bir sınıfa pointer varsa ve ++operatörünü çağırmak istiyorsak aşağıdaki gibi yapabiliriz.

std::atomic_uint64_t* counter;
counter->operator++();

Dönüşüm Operatörleri - Conversion Operator
Dönüşüm operatörleri - Conversion Operator yazısına taşıdım.

Yazılım Ürün Hattı (Software Product Line)

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?

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.
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.

İşte burada ne can alıcı bir noktaya değinilmiş. Projenin kapsamı ortaya çıkmış.

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.