Gömülü Yazılım Tasarlama

Bir RTOS kullanarak gömülü yazılım programlamaya başlıyorum ve zaten masaüstü uygulamaları için bir geliştirici olduğum için, Gömülü yazılımı Etkinlik Diyagramları, Sıra Diyagramları, Kullanım Durumları gibi UML diyagramlarını kullanarak modellemenin nasıl bir şey olduğunu merak ettim.

Gömülü yazılım UML kullanılarak tasarlanmış mı, masaüstü uygulamalarında olduğu gibi mi? En iyi seçenek mi yoksa daha iyi bir seçenek mi? Bazı örnekler alabilir miyim?

Bunu yapan belirli bir araç var mı?

Adı şu anda kaçan bir şirket tarafından popüler hale getirilen UML'ye Gerçek Zamanlı uzantılar var. Birkaç yıl önce üzerinde bir kağıt yaptığımı hatırlıyorum. Bruce Powell Douglass, UML kullanarak gömülü sistemleri modelleme konusunda birkaç kitap yazdı, ancak şirketi düşündüğüm kişi değil.

Bununla birlikte, Wouter'ı yankılamak için, gömülü yazılım hakkında özel bir şey yoktur. Pentium sınıfı işlemcilerde çalışan bir sistem için her gün gömülü yazılım yazıyorum; UML oldukça uygulanabilir. Ayrıca, kontrol yazılımının birçok yönünün zaman içinde UML'ye eklendiğini unutmayın: Senkron Şemalarda yanıt süresiyle birlikte senkron veya asenkron olayları belirtmek için sözdizimi vardır, Petri net türü davranışı Etkinlik Diyagramları, Statecharts modeli davranışında daha da iyi bulunabilir Durum Diyagramları vb.

OTOH, birçok kişi Gömülü yazılımı Yapılandırılmış Tasarım ve Veri Akışı kavramlarını kullanarak modellemeyi tercih eder. Her şey tasarladığınız sistem türü ve neyin en iyi çalıştığı ile ilgilidir.

Bir RTOS'a dönerken, genellikle her birinin son teslim tarihlerini zamanında karşılayabilmesi veya kaynakları güvenli bir şekilde paylaşabilmesi için en uygun şekilde planlanması gereken birçok eşzamanlı görevi olan bir uygulama ile uğraşıyoruz. Seçtiğiniz RTOS çerçevesi bir görev zamanlayıcı uygular ve işiniz (genellikle) bu bireysel görevleri belirli bir özellik kümesiyle (nokta, öncelik vb.) Yazmak ve daha sonra zamanlayıcıya teslim etmektir. Dolayısıyla dokümantasyon için benim atacağım yaklaşım her bir görevi dikkatle belgelemek olacaktır.

Çoğu gömülü yazılım ve bildiğim kadarıyla RTOS'ların çoğu nesne yönelimli bir dilde yazılmamıştır ve bu nedenle örneğin bu sınıf diyagramlarına yönelik birçok şeyden yararlanamayabilir.

Ancak RTOS görevlerinizi belgelediğinizde, görevi iyi tanımlayan herhangi bir diyagram büyük yarar sağlayacaktır. Her görev için bir dizi diyagramının örneğin çok yardımcı olabileceğini hayal ediyorum. Bunun yanı sıra, periyodu / sıklığı, önceliği, kullanabileceği paylaşılan kaynaklar, ön yeterlilik gereksinimleri gibi zor gereksinimlerini de belirtebilirsiniz. Ayrıca RTOS'u ve belki de bir durumu nasıl yapılandırdığınızı belgelemek de önemli olabilir. programlama algoritması.

İstediğiniz gibi bu tavsiyeden herhangi birini alın, üniversite günlerimden beri RTOS'larla uğraşmadım ve işi gerçekten "belgelemedim".

Modelleme tamamen

• uygulamanızda hangi yönün zor ve karmaşık olduğunu bilmek,

• bu yönüne uygun bir modelleme aracı / dil / soyutlama / konvansiyon / gösterim bulma

• bu yönü tasarlamak

Bu nedenle, hiçbir modelleme aracı / yaklaşımı / vb. Tüm durumlar için uygun değildir. Bir uydu, muhtemelen birden fazla işlemciye sahip gerçek zamanlı bir çoklu görev sistemi olacaktır. Görev yapısı diyagramları, cinsel yolla bulaşan hastalıklar ve dizi diyagramları muhtemelen yararlıdır (sadece birkaçını belirtmek için). Eğer proje C'de yapılırsa, bir sınıf diyagramı daha az kullanışlı olur (eğer çok faydalı olduğu ortaya çıkarsa, C seçimi muhtemelen yanlıştır). UseCases'i çok sevmiyorum ve an-sich'in hiçbir uydusu yok. Kullanım durumları, sisteminizle ilgili gereksinimleri teknik olmayan bir kullanıcıyla tartışmak istediğiniz bir durumda en uygun olanlardır. Bir uydu projesinde bulunduğunuz durum buysa, bir şeyler ters gitti.

Mekana uygun bir şey tasarlamadım. Ancak bir Savunma Bakanlığı (DoD) havacılık taşeronu için çalıştım ve tasarımlarımın çoğu uçuşa uyguntu. Tasarımlarınızla ilgili çok fazla belge gerektirirler ve tam olarak görmek istediklerini ayrıntılandıran Veri Öğesi Açıklamaları (DID) sağlarlar.

"Başlıklardaki Kelime" alanına "yazılım" yazar ve Gönder'i tıklarsanız, gerekli olabilecek belgelerin tüm DID'lerini görmek için DoD ASSIST Hızlı Arama'yı kullanabilirsiniz. (Bir DoD sitesinin sertifika güvenlik uyarısı verdiğini komik buluyorum, ancak sizi temin ederim, güvenli).

Özellikle bir Tasarım Belgesi hakkında sorduğunuz için, burada Yazılım Tasarım Açıklaması (SDD) DID. Tasarımın her bir parçasını tanımlamak için kelimelerin kullanımını vurgularlar. Ancak, UML, Durum Diyagramları, akış şemaları, sözde kod vb.

Diğerlerinin belirttiği gibi hangi modelleme yöntemini seçtiğiniz, tasarımınıza bağlıdır. Ancak havacılık yazılımı için bir DID görmenin, projeniz alanla ilgili olduğu için Tasarım Belgenizi yazmanıza yardımcı olabileceğini düşündüm.