Gömülü Yazılım ve Tasarım Kalıpları

Başlatan volkanunal, 02 Eylül 2020, 14:44:44

mylord92

Alıntı yapılan: volkanunal - 04 Eylül 2020, 11:34:19Örnek vermeniz mümkünse nasıl bir senaryoda hangi tasarım kalıbına nasıl bir ihtiyaç oluştu hocam, örnek vermeniz mümkün müdür ?

Sürekli bir maliyet iyileştirme, yeni ürün çalışmalarının olduğu bir senaryoda tekrar kullanılabilir kodlar önem kazanıyor. Örneğin bugün X üreticisinin ürettiği bir mcu ile yaptığımız işi yarın daha ucuz diye Y üreticisinin ürettiği bir mcu ile yada yine X üreticisinin ürettiği ama farklı bir seri mcu ile yapmamız gerekebiliyor. Bu noktada tüm mcu driverlarını tekrar taşımak yerine yazdığımız frameworkün port dosyalarını yeni mcu ya göre doldurarak ve kodun aplikasyon tarafında hiç bir değişiklik yapmadan kullanıyoruz. Hatta iş öyle bir noktada ki mcu modelleri için port dosyalarınıda framework içine işliyoruz ve definelar ile kullanacağımız mcuyu belirterek sürücülerini dahil ediyoruz :)

Katmanları şöyle düşünebilirsin;

1) Mcu Sürücüleri
2) Framework IO, COM, Complex veya Memory sürücüleri
3) Gerekliyse 2 numarayı bağlayabileceğimiz algoritmalar.(Örneğin IO için bir debounce modülü, ADC için ortalama alan bir modül, optimizasyon veya kestirim modülleri vs.)
4) Middleware
5) Aplikasyon

Hiyerarşik olarak her katman bir altı veya bir üstü ile konuşabilir. Bu hiyerarşi kırılmadığı sürece oldukça esnek bir geliştirme ortamı sağlıyor.

Dezavantajı nedir diye sorarsan belki birkaç kB kadar kodun boyutunu arttırıyor olabilir.

volkanunal

Alıntı yapılan: mylord92 - 05 Eylül 2020, 20:26:43Sürekli bir maliyet iyileştirme, yeni ürün çalışmalarının olduğu bir senaryoda tekrar kullanılabilir kodlar önem kazanıyor. Örneğin bugün X üreticisinin ürettiği bir mcu ile yaptığımız işi yarın daha ucuz diye Y üreticisinin ürettiği bir mcu ile yada yine X üreticisinin ürettiği ama farklı bir seri mcu ile yapmamız gerekebiliyor. Bu noktada tüm mcu driverlarını tekrar taşımak yerine yazdığımız frameworkün port dosyalarını yeni mcu ya göre doldurarak ve kodun aplikasyon tarafında hiç bir değişiklik yapmadan kullanıyoruz. Hatta iş öyle bir noktada ki mcu modelleri için port dosyalarınıda framework içine işliyoruz ve definelar ile kullanacağımız mcuyu belirterek sürücülerini dahil ediyoruz :)

Katmanları şöyle düşünebilirsin;

1) Mcu Sürücüleri
2) Framework IO, COM, Complex veya Memory sürücüleri
3) Gerekliyse 2 numarayı bağlayabileceğimiz algoritmalar.(Örneğin IO için bir debounce modülü, ADC için ortalama alan bir modül, optimizasyon veya kestirim modülleri vs.)
4) Middleware
5) Aplikasyon

Hiyerarşik olarak her katman bir altı veya bir üstü ile konuşabilir. Bu hiyerarşi kırılmadığı sürece oldukça esnek bir geliştirme ortamı sağlıyor.

Dezavantajı nedir diye sorarsan belki birkaç kB kadar kodun boyutunu arttırıyor olabilir.

Bu bahsettiğiniz yapıya bir tasarım kalıba demek mümkün müdür hocam ?
Yani siz callbackler ile aslında bir donanım soyutlama yapıyorsunuz diye düşündüm ben ya da makrolar ile işlemci ailesine göre bir derleme yapıyorsunuz. Bu durumda bir çok 3.parti kütüphane tasarım kalıbı oluyor. Bence bahsettiğiniz yapı ile tasarım kalıbı arasında ince bir çizgi var.

berat23

design patterns, object oriented vs. bunları tek başına teknik olarak yorumlayıp, bir sonuca varmanız olası değil. teknik olarak bakarsanız tamamı gereksiz, kodu büyüten, yavaşlatan, geliştirmeyi zorlaştıran yapılar. ama kazın ayağı öyle değil.

işe biraz daha proje bakışıyla bakarsanız, yani büyük bir işi en hatasız, çok geliştiriciyle harmonik biçimde, yenliklere ve başka gözlere açık biçimde geliştirmelisiniz. profesyonel kod, gayet anlaşılır, belirli kalıplarda ve iyi dokümante olmalıdır. sadece geliştiricisi anlayabiliyorsa isterse harikalar yaratsın o aslında "bitirme projesidir". metrik olarak bilemem ama 2-3 geliştiricinin yaptığı bir projede böyle süreçlere elbette gerek olmayabilir. ya da piyasa tipi gömülü sistemler(endüstüriyel kontrol vs.) için framework vs. fazla maliyetli olur.  ama o kodun üzerinde 20 kişi çalışıyorsa bunları ancak aynı şekilde geliştirterek harmonize edebilirsiniz.

Erol YILMAZ

İlla ki büyük projeler düşünmek gerekmiyor bence,

Bir kodun sistematik şekilde, belli bir şablon üzerinden yazılması birçok avantaj sunacaktır.

Mcu'da kod yazmanın, kalemle çizgi çizmek olduğunu varsayalım...
Peki cetvel ile kalem bir araya gelirse neler olur? Konu yürümeye başlar...

brandice5

07 Eylül 2020, 17:36:29 #19 Son düzenlenme: 07 Eylül 2020, 17:38:26 brandice5
Ingilizcede "overengineering" denen bir kavram var.

https://en.wikipedia.org/wiki/Overengineering

Alıntı yapılan: undefinedOverengineering (or over-engineering, or over-kill) is the act of designing a product to be more robust or have more features than often necessary for its intended use, or for a process to be unnecessarily complex or inefficient.

Yani Turkcesi

Alıntı yapılan: undefinedAşırı mühendislik bir ürünü amaçlanan kullanımı için genellikle gerekenden daha fazla özelliğe sahip veya daha sağlam olacak şekilde veya gereksiz şekilde karmaşık veya verimsiz olacak şekilde tasarlama eylemidir.

C ile design pattern yapmaya calismak tam olarak "overengineering" dir.

Bu konuda kitap yazilmis olmasi bunun dogru oldugu anlamina gelmez.

volkanunal

Alıntı yapılan: brandice5 - 07 Eylül 2020, 17:36:29Ingilizcede "overengineering" denen bir kavram var.

https://en.wikipedia.org/wiki/Overengineering

Yani Turkcesi

C ile design pattern yapmaya calismak tam olarak "overengineering" dir.

Bu konuda kitap yazilmis olmasi bunun dogru oldugu anlamina gelmez.


Mühendisliği yapıldıda overı kaldı hocam :)

LukeSkywalker

Overengineering deyince aklıma w124 geldi.

superconductor

Alıntı yapılan: brandice5 - 07 Eylül 2020, 17:36:29C ile design pattern yapmaya calismak tam olarak "overengineering" dir.

Bu konuda kitap yazilmis olmasi bunun dogru oldugu anlamina gelmez.

Mesela linux kernel aşırı mühendislik mi? Binlerce kişinin yıllardır geliştirdiği linux kernelde design pattern olmadan geliştirme yapıldığını düşünün..

https://lwn.net/Articles/336224/

brandice5

@superconductor daha onceki mesajlarimi okumadiniz sanirim. ben sizin isinizi kolaylastirip buraya koyayim.

AlıntıTasarim kaliplarina gelirsek, bunu hakkiyla kullanabilmek icin C++ gibi object oriented bir dil kullanmak gerekli.
Gomulu sistemlerde C hala yaygin sekilde kullanildigi icin, C ile yazdiginiz kodda cok verim alacaginizi sanmiyorum.

Alıntıcalistiginiz platform sadece C derleyici destekliyorsa (ki boyle olsa bile yukaridaki sebeplerden ben yine tercih etmezdim) kullanmakta ozgursunuz ama C++ ile DP yapmak varken C ile tirmalamak gereksiz ve zaman kaybi.

Birincisi, Linux kernel design pattern denen kavramin tanimlanmasindan daha once 1991 de C ile baslanmis ve hala C ile devam eden bir proje. Yukarida yazdigim gibi sadece C kullanilma gibi bir durum var. Ayrica adamlar o kodlari yazarken "dur surada su design pattern i kullanayim" diye yola cikmamis. Yani bilincli bir design pattern kullanimi yok.

Ikincisi aslinda bilincsiz bir design pattern kullanimi da yok. Linkini verdigin makalenin 3 partini da inceledim. Birinci partta "reference counting" anlatilmis. Bu C++11 den once bizimde kullandigimiz bir yontemdi, smart pointers eklentisinden sonra kendi implementasyonumuzu kullanmayi biraktik. Ikinci partta "linked list" anlatilmis, ucuncu partda da "function pointer".

Simdi bu "reference counting", "linked list" ve "function pointer" konularina ne kadar "design pattern" denir tartisilir. Ben design pattern deyince bir "factory" ya da bir "observer" patterni bekliyorum. O 3 parttan olusan makaleler daha cok RAII ve data structures konulari. Yine OOP a en yakin konu "function pointer" olmus ki bu da design pattern degil bir OOP implementasyonu.

Konuyu daha da uzatmak istemiyorum, isteyen istedigini kullansin.

kantirici

Aslında "tasarım desenleri" konusu konuşulunca akademik bir durum /kitabi bir bilgi/formül gibi geliyor insanın aklına. Özellikle nesne yönelimli dillerle geliştirilen yöntemlerin gerektirdiği dil özelliklerinden dolayı da sanki bu dillerin kullanımını mecburi kılıyor gibi düşünülüyor. Aslında bazı yöntemlerde evet zorunlu; mesela "state pattern".

Fakat tasarım desenlerinin tanımına baktığımızda "best practices" durumlarından başka şeyler değiller. Ayrıca herkes kendi "design pattern"ini geliştirebilir. Yani uygulanan yaklaşımın bir tasarım deseni olması için ille bir kitapta veya kaynakta gösterilmesi gerekmez. Siz bir yöntemi benimser ve bunu paylaşırsanız bu sizin adlandırdığınız bir tasarım kalıbı olur. Eğer gerçekten iyi bir yöntem/yaklaşım ise topluluk tarafından benimsenir ve kitaplara konu olur.

C ile tasarım desenlerini uygulamanın "aşırı mühendislik" olması durumu yukarıdaki tanımlarla daha iyi anlaşılıyor. Eğer siz C ile "state pattern" yapmaya çalışırsanız mantıklı olmayabilir. Fakat tasarım deseni kullanmak üzerinde yaklaşırsak sorun olmaz.