DO-178B - Object Oriented Technology in Aviation

Giriş
DO-178B ile Object Oriented Teknology kullanılması düşünülüyorsa Handbook for Object Oriented Technology in Aviation kitapları mutlaka okunmalı.

Hanbook for Object Oriented Technology in Aviation Nedir?
4 ciltten oluşur. Ciltleri okuduktan sonra resmen OOT kullanmak istediğinize pişman olacağınızı hissedersiniz.

• Cilt 1 : Handbook Overview - OOT Background anlatılır
• Cilt 2 : Considerations and Issues - OOT Kullanmadan Önce Dikkate Alınması Gereken Noktalar ve Sıkıntıları özetler
• Cilt 3: Best Practices - Önerileri içerir
• Cilt 4: Certification Process

Bir de tüm problemlerin listelendiği Issues and Comments About Object Oriented Technology in Aviation (IL) dosyası var.

Bazı Maddeler
Multiple Inheritance
Özet olarak Multiple Inheritance kullanılması tavsiye edilmiyor. Sebeplerini aşağıda açıklamaya çalıştım.

Cilt 3'te Multiple Inheriance 3 başlık altında inceleniyor.

1. Multiple Interface Inheritance
2. Multiple Implementation Inheritance
3. Mixed Multiple Inheritance

1 numaralı Multiple Interface Inheritance daha masum görünse de IL'de kullanılması unclear intent gerekçesiyle tavsiye edilmiyor.

IL dosyasında şu maddeler var.

* Multpile Inheritance should be avoided in safety critical certified systems (IL 38) -> Yani multiple Inheritance kullanılması tavsiye edilmiyor
* How can we enforce the rules that restrict the use of specific OO features (IL 58)-> Yani multiple inheritance kullanılmadığı static analiz yapılarak doğrulanmalı.

Multiple Inheritance ile gelen belirsizliğin (ambiguity) sebepleri şunlar:

The ambiguity shows up in a few different ways:

1. If you have two base classes with the same field x, and the derived type asks for x, what does it get? 
• If the two x variables have incongruent types, you could infer it.
• If they're the same type, you could try to merge them into the same variable.
• You could always expose them as weird fully qualified names.
2. If you have two base classes with the same function f with identical signatures, and someone calls f, which gets called?
• What if the two base classes share another common virtual ancestor (the diamond problem).
• What if the function has different, but compatible signatures?
3. When you construct a class with two base classes, which of the base classes' constructor is called first? When you destroy the object, which is killed?
4. When you lay out the object in memory, how do you do it consistently?
5. How do you handle all of these cases with 3 base classes? 10?

STL Container

STL container'ları zaten kullanılmıyor. Bir sebep şöyle. Yani dynamic memory allocation yapılması.

Think of it: you are coding some safety-critical embedded software (e.g. for train braking, autonomous vehicles, autonomous drones, big oil platform or oil refinery, missiles, etc...). You naively use some C++ standard container, e.g. some std::map<std::string,long>. What should happen for out of memory conditions? How do you "prove", or at least "convince", to the people working in organizations funding a 100M€ space rocket, that your embedded software (including the compiler used to build it) is good enough? A decade-year old rule was to forbid any kind of dynamic heap allocation.

Template Kod
Normal template kodlarda ise bir sebep kodun varlığını izah etmek. Elimizde şöyle bir kod olsun

template<class T>  fun(T t){
   do_some_thing(t);
}

Açıklaması şöyle. Sanırım kast edilen şey template kod ile kullanılan tüm tipler için ayrı ayrı gereksinim ve test yazmak.

In the classic way to specify a safety system you have to provide a complete description of each and every function and structure of your code. That means you are not allowed to have any code without specification. That means you have to give a complete description of the functionality of the template in its general form. For obviously reasons that is not possible. That is btw. the same reason why function-like macros are also forbidden. If you change the idea in a way that you describe all actual instantiation of this template you overcome this limitation but you need a proper tooling to prove that you really described all of them.