Giriş
Yazılım arayüzleri için hazırlanan belgelere bir çok farklı isim verilebiliyor. Software Interface Control Document (ICD), Interface Design Document (IDD) gibi isimler farklı yerlerde karşımıza çıkabilir. Hepsi üç aşağı beş yukarı aynı şeyi yani formatlı mesajları kast eder. Ben bu yazıda "ICD" kelimesini kullandım.
Interface Control Document Nedir?
Interface Control Document (ICD) genellikle elektriksel arayüzler için kullanılır.Yazılım arayüzleri için hazırlanan belgelere de Software ICD deniliyor.
IDD Nedir?
Interface Design Document yazılım arayüzünü belirtir.
Data Transfer Object Nedir?
Ben ICD ile
Data Transfer Object (DTO) kavramını birbirine çok yakın buluyorum. DTO klasik kullanımında yazılım servisleri veya katmanları arası veri aktarımı için tanımlanır. ICD ise farklı sistemler arası veri aktarımı için kullanılır. DTO'nun Serialize(), Deserialize() metodları olması gerekmez.
Bitwise ICD
Bir çok iletişim yolu düşük bant genişliğine sahip olduğu için formatlı mesajları sıkıştırmak gerekir. Bu yüzden mesaj alanları bit bit tanımlanırlar. Bitleri engineering formata çevirmek için iki yöntem var.
Low Level ve High Level ICD tanımlamak
Bu yöntemde Low Level ICD bit seviyesinde mesajları okuma yazma işleminden sorumludur.
High Level ICD ise Low Level ICD mesajlarını resolution ve offset değerleri ile çarpıp bölerek engineering formata çevirir. Ben bu yöntemi daha doğru buluyorum.
Not : Resolution (bazı projerlerde scale de deniyor ki bence scale başka bir şeyi ifade eder) bir bit ile temsil edilebilen en küçük değer anlamına gelir.
Low level ve High Level'ı birleştiren tek bir ICD tanımlamak
Bu yöntemde her bir mesaj alanı bir struct veya class olarak tanımlanır. Bu sınıfların scale ve offset alanları vardır. Sınıfa değer atanınca scale ve offset değerleri ile çarpıp bölerek engineering formata çevirir. Örnek bir sınıf aşağıda.
class MyInt32 {
public :
int32_t m_Value;
double m_Scale;
double m_Offset;
void operator= (int value){
m_Value = (value * m_Scale) + m_Offset;
}
}
Bytewise ICD
Bantgenişliği düşük olmayan iletişim yollarında bytewise ICD tanımlanır. Bu ICD mesajlarında int, double gibi büyük tipler kullanılabilir.
ICD ve Protokol
Bir çok iletişim protokolü gerçek verinin yanında ek şeyler de gönderir. Örneğin gerçek veri zarflanabilir, daha küçük parçalara ayrılabilir vs. ICD mesajlarını iletişim protokolüne çevirmek için protokolü gerçekleştiren sınıflar yazmak gerekebilir.
Header Örneği
Message ID : Hangi mesaj olduğunu anlamak için kullanılır. Aşağıda bu alanı kullanan basit bir
örnek var.
protected void decode(UnparsedPacket msg, List<Object> out) throws Exception {
switch(msg.id){
case FooPacket.ID:
FooPacket fooPacket = new FooPacket(msg.frame);
out.add(fooPacket);
break;
case BarPacket.ID:
BarPacket barPacket = new BarPacket(msg.frame);
out.add(barPacket);
break;
}
}
Message Size : Mesajın byte cinsinden toplam büyüklüğü. Eğer UDP gibi parçalanmaya izin vermeyen bir transport kullanılıyorsa bu alana gerek olmayabilir. TCP gibi transportlarda bu alan ileride ICD'nin değişebileceği de düşünülerek konulursa faydalı olur.
ICD Mesaj Sınıfları
Genellikle sadece Serialize (Stream s), Deserialize (Stream s), ToString() gibi metodlara sahip olan sınıflardır. Kullanılan programlama diline göre stream sınıf hiyerarşisini de kodlamak gerekebilir.
BitStream, LittleEndianStream, BigEndianStream gibi streamleri bazı programlama dillerinde mevcut olmayabiliyor. Bu durumda hiyerarşiyi kendimiz kurmak zorunda kalırız.
Ayrıca ICD mesajlarını, abstract bir sınıf veya arayüzden türetmek te programlamayı kolaylaştırır.
Serialize Metodu
C++ için yazıyorsak
void MyMessage::Serialize (
stream& s);
şeklinde yazılabilir.
ToString metodu
C++ için yazıyorsak
void MyMessage::ToString (
stringstream& s);
şeklinde yazılabilir.
ICD ve Range Check
Eğer mesajların hatalı gelebileceği düşünülüyorsa, ICD mesajlarına hatalı durumları yakalayan range check kodları eklenir
ICD ve Logical Check
Bu tür mantıksal kontrolleri ICD mesajlarına eklemek kolay olmayabilir. Gerekirse ICD mesajlarını işleyen katmana dahil edilmelidir.
ICD ve Request Response
Bazı ICD'lerde gönderilen isteğe karşılık Response gönderilir. Bu tür belgelerde hangi isteğe hangi cevap gönderildiğini gösteren bir akış diagramı (sequence diagram) faydalı olur.
İstek ve cevabı eşleştirmek için istek içine sırayla artan bir RequestID yazılır. Gönderilen cevap içine de aynı RequestID yazılarak istek ve cevap eşleştirilir.
ICD ve Surrogate Key
Bazı ICD'ler nesneler üzerinde CRUD işlemi için kullanılır. Eğe karşı sistem, benim yazılımımda CRUD işlemi yapıyorsa, her nesneye bir
SurrogateKey verilmesi iyi olur. Benim sistemim ile karşı sistemin yarattığı nesneleri birbirlerinden ayırmak için Surrogate Key iki kısma bölünebilir. Öreğin 0- 100 arası değerler benim, 100-200 arası değerler karşı sistemin olabilir.
ICD ve Acknowledgement
Bazı ICD'lerde gönderilen komuta karşılık Acknowledgement gönderilmesi istenir. ACK mesajında mesajın alındığı belirtilir. Bazen de Response gönderilmeyen durumlarda mesajın işlenip işlenemediği belirtilir.
Internal Mesaj Yapısına Çevirmek
Formatlı ICD mesajı okunduktan sonra yazılımda bir şekilde saklanması gerekir.
Clone Yöntemi
Kullanılabilecek en kolay yöntem ICD mesajını ve Internal mesajı ortak bir sınıftan türetmek olabilir.
---->BaseClass<----
| |
ICDClass InternalClass
Bu yöntemde ICDClass kendisi kullanmasa bile InternalClass'ın ihtiyaç duyduğu alanları da görür ve bilir.
Field Copy Yöntemi
Biraz daha zor bir yöntem ise ICD mesajlarını dizi şeklinde çekirdeğe iletmek. Bu yöntemde çekirdek ICD mesajlarını kendi içindeki yapılara yapıştırır.
ICD Arayüz Bileşeni --- ICD mesaj Dizisi ----> Çekirdek
Bu yöntem ise çekirdek kodunda Clone() yerine teker teker nesnenin alanlarının kopyalaması yapıldığı için hata yapmaya müsaittir.
ICD Arayüzü İçin Yazılım Bileşeni
Yazılımın çekirdeği ile arayüz arasına ICD Arayüzü Yazılım Bileşeni yerleştirmek iyi bir fikir. Böylece çekirdek işlev ICD değişikliklerinden mümkün olduğunca yalıtılmış olur.
SIU
Sub-System Interface Unit : Genellikle sadece mesaj dönüşümü yapan, akıllı olmayan yazılımlardır
SAU
Sub-System Adaptation Unit : SIU'dan akıllı olan yazılımlardır. Mesajları gerekirse parçalar veya birleştirebilirler.
ICD Mesaj Dizisinin Kısmi Gelmesi
Özellikle bant genişliğinin düşük olduğu sistemlerde ICD mesaj dizisi örneğin 5 parçadan oluşsa bile tasarruf için sadece güncellenmek istenen parçanın gönderilmesi söz konusu olabilir. Bu durumda ICD arayüz sisteminin önceden gelmiş olan bilgiyi kaybetmemek için ICDClass nesnesini doldurmaya başlamadan önce mevcut son halini okuması ve yeni gelen mesaj ile doldurulmuş nesneyi güncellemesi gerekebilir.
ICD Mesajlarının Gönderilmesi
Havadan yapılan iletişim sistemlerinde genellikle aynı paket bir kaç defa tekrarlanır. Farklı zamanlarda yapılan bu gönderimin amacı herkesin mesajı alabilmesini sağlamaktır. ICD arayüz yazılımı bir aktarım kuyruğu kullanarak mesajların gönderilmesi zamanını ve kalan sayacı tutabilir. Adil kullanım kotası koyarak gönderenleri yavaşlatabilir. Daha fazla para ödeyene öncelik tanıyabilir vs.
Bridge Yazılımlar
Bazı yazılımlar sadece iki ICD arasında dönüşüm yapmak için vardır. Bu tür yazılımlara bridge (köprü) denir. Statefull ve stateless olabilirler.
Statefull Sistem
Statefull sistemler genellikle belleklerinde tuttukları bilgiyi süzerek daha küçük listeler halinde karşı sisteme gönderirler. Liste gönderimi periyodik veya sorguya dayalı olabilir.
Stateless Sistem
Stateless sistemler belleklerinde bilgi tutmazlar. Gelen mesajı dönüştürerek bir kuyruğa atarlar. Kuyruğu okuyan bir başka thread ise diğer sisteme gönderir.
ICD Toplantıları
Toplantı öncesinde konuşulacak konular ve çözüm önerileri hazırlanırsa süreç hızlanır. Bir çok toplantı gündem ve çözüm önerisi hazırlanmadığı için faydasız hale geliyor.
Toplantılarda Toplantı Katılım Formu ve Toplantı tutanağı doldurulur.
