組み込みソフトウェアの設計

私はRTOSを使用して組み込みソフトウェアプログラミングを始めています。私はすでにデスクトップアプリケーションの開発者なので、アクティビティ図、シーケンス図、ユースケースなどのUML図を使用して組み込みソフトウェアをモデル化するのはどのようなものか疑問に思っていました。

組み込みソフトウェアは、デスクトップアプリケーションと同じように、UMLを使用して設計されていますか？それは最良の選択肢ですか、それとももっと良い選択肢がありますか？いくつか例を挙げてもらえますか？

これを行う特定のツールはありますか？

UMLにはReal Time Extensionsがあり、その名前が今のところ私から逃れている会社によって普及しています。私は数年前にそれについて論文を書いたことを覚えています。Bruce Powell Douglassは、UMLを使用した組み込みシステムのモデリングに関する本を何冊か書いていますが、私が考えているのは彼の会社ではありません。

とは言っても、ウーターを思い起こさせるには、組み込みソフトウェア自体について特別なことは何もありません。私は、Pentiumクラスのプロセッサーで実行されるシステム用の組み込みソフトウェアを毎日作成しています。UMLは非常に適切です。また、制御ソフトウェアの多くの側面が時間の経過とともにUMLに追加されたことを覚えておいてください：シーケンス図で応答時間と共に同期または非同期イベントを指定する構文があり、ペトリネットタイプの動作はアクティビティ図で確認できます、ステートチャートモデルの動作はさらに優れています状態図などよりも

OTOH、多くの人々は、構造化設計とデータフローの概念を使用して組み込みソフトウェアをモデル化することを好みます。それはすべて、設計しているシステムのタイプと、最も効果的に機能するものについてです。

RTOSに目を向けるとき、私たちは通常、それぞれが期限に間に合うように、またはリソースを安全に共有するために最適にスケジュールする必要のある多数の同時タスクを持つアプリケーションを扱います。選択したRTOSフレームワークはタスクスケジューラを実装し、ジョブは（通常）特定のプロパティセット（期間、優先度など）を使用してこれらの個々のタスクを記述し、それをスケジューラに渡します。したがって、ドキュメンテーションの場合、私が取るアプローチは、各タスクを注意深く文書化することです。

ほとんどの組み込みソフトウェアと、私が知る限り、ほとんどのRTOSはオブジェクト指向言語で書かれていないため、たとえばクラス図などに向けられた多くのことから利益を得られない可能性があります。

ただし、RTOSタスクを文書化する場合は、タスクを適切に説明する図が非常に役立ちます。たとえば、各タスクのシーケンス図が非常に役立つと思います。それに加えて、期間/頻度、優先度、使用する可能性のあるすべての共有リソース、プリエンプション要件などのハード要件を指定できます。また、RTOSとおそらく状態をどのように設定したかを文書化することも重要です。そのスケジューリングアルゴリズムのマシン。

このアドバイスはどれでも好きです。私は大学時代からRTOSのことをいじっていませんし、実際にその作業を「文書化」したこともありません。

モデリングはすべてです

• アプリケーションのどの側面が困難で複雑であるかを知ること、

• その側面に適したモデリングツール/言語/抽象化/慣習/表記法を見つける

• その側面を設計する

したがって、すべての状況に適したモデリングツール/アプローチなどはありません。衛星は、おそらく複数のプロセッサを備えたリアルタイムマルチタスクシステムになるでしょう。タスク構造図、STD、およびシーケンス図はおそらく役に立ちます（ほんの数例を挙げると）。プロジェクトがCで行われている場合、クラス図はあまり役に立ちません（非常に役立つことが判明した場合、Cの選択はおそらく間違っていました）。私はUseCasesがあまり好きではなく、衛星an-sichにはユーザーがいません。使用例は、システムの要件を技術者でないユーザーと話し合いたい場合に最適です。それがあなたが衛星プロジェクトにいる状況であるならば、何かが間違っています。

スペースに適したものは何も設計していません。しかし、私は国防総省（DoD）の航空宇宙の下請け業者に勤務しており、私の設計の多くは飛行認定を受けていました。彼らはあなたのデザインに関する多くのドキュメントを必要とし、彼らが見たいものを正確に詳述するデータアイテム記述（DID）を提供します。

DoD ASSISTクイック検索を使用して、[タイトルの単語]フィールドに「ソフトウェア」と入力し、[送信]をクリックした場合に必要になる可能性のあるドキュメントのすべてのDIDを表示できます。（DoDサイトが証明書のセキュリティ警告をスローするのはおかしいですが、安全であることを保証します）。

設計ドキュメントについて具体的に尋ねたので、これがソフトウェア設計記述（SDD）DIDです。彼らはデザインの各部分を説明する言葉の使用を強調しています。ただし、UML、状態図、フローチャート、疑似コードなどを使用して設計の理解を深めることができる場合は、もちろんそれを含めてほしいと考えています。

他の人が述べたように、どのモデリング方法を選択するかは、設計によって異なります。しかし、プロジェクトは宇宙に関連しているため、航空宇宙ソフトウェアのDIDを確認すると、設計ドキュメントを作成するのに役立つと思いました。