3

リアルタイムMIDIアプリケーションを実装するタスクを自分で設定しました。私がこれまでに書いた他のすべてのソフトウェアと同様に、私はコーディングから始めました。Jack Audio Connection Kitとそのクライアントのトランスポート状態を制御できる小さなGUI（GTK2）アプリケーションを実装しました。

私はこれまでリアルタイムアプリケーションを作成したことがなく、マルチスレッドプログラムを1つだけ作成したことがあります。これまでに作成したすべてのソフトウェアでは、最初に設計する必要がなかったため、これらの詳細の両方が組み合わさって、これは私にとって大きな課題になります。私は物事を解決するためにたまにペンと紙が必要でした。

ただし、このプロジェクトでは、コーディングを進めることはできません。しかし、私はソフトウェア設計についてほとんど何も知りません。私は独学で学んでいます（1990年代半ばの2年間のコンピューター研究コースを割引きます）。私は常に段階的に作業し、何かを機能させてからそれを基に構築してきました。

調査中に、Model View Controllerのパターンに出くわしましたが、詳細について考えないことは非常に困難であり、すべてを失敗させる問題を見つけることなく、基盤を構築することはできません。

このブロックを乗り越えるにはアドバイスが必要です。思考の流れを失う気晴らしを見つけるのをやめる必要があります。これは気を散らすものの1つです。このブロックを乗り越えるにはどうすればよいですか？

4

3 に答える 3

3

非常に大まかに言えば、「ソフトウェア設計」とは、目前の問題を一連のモジュールに分解し、各モジュールの責任と、各モジュールが他のモジュールとどのように通信するか（ある場合）を指定するプロセスです。

このアクティビティを進めるには、さまざまな方法があります。これがあなたの最初の試みであることを考慮して、物事をできるだけ単純にしてください：いくつかの紙のシートとペンをつかんでください。

最初のステップ：新しいアプリケーションが実行できる必要があるタスクのリストを書き留めます。この後、論理的に一緒に属していると思われるさまざまなセットにタスクをグループ化してみてください。

サブセットごとに、名前を見つけて空白のシート（サブセット用に1つ）に書き込み、モジュールがどのタイプのデータを処理したり、他のユーザーと交換したりする必要があるかなど、モジュールの動作をもう少し詳しく説明します。それぞれが「モジュール設計書」です

別の空白のシートに、サブセットごとにボックスを描画し、適切な名前でラベルを付けて、あるボックスから別のボックスに矢印を描画してみます。各矢印には名前があり、モジュールの1つが別のモジュールを呼び出していることを表します。これをあなたのモジュール「インターフェースデザインペーパー」と呼びましょう。

モジュールの説明と他のモジュールに提供する必要のあるインターフェイスを再確認し、元のタスクリストを変更する必要があるかどうか、およびこれが管理するデータにどのように影響するかを確認します。

モジュールが複雑すぎたり大きすぎたりする場合は、モジュールを繰り返し細分化することができます。モジュールをサブモジュールに分割する場合は、別のインターフェイスデザインペーパーを作成するだけです。サブモジュールの合計は、モジュールに対して最初に想定したすべてのタスクを実行でき、残りの部分の要求に答えることができるはずです。システム。

詳細については、CRCカードも参照してください。

于 2010-02-26T15:21:50.693 に答える
3

この質問に対してすでに書かれている答えは素晴らしいですが、リアルタイムソフトウェア開発の最もユニークな部分であるリアルタイム技術要件については言及されていません。

ソフトウェアの応答性、保持できるメモリフットプリントの大きさ、起動速度、実行可能ファイルの大きさを正確に把握する必要があります。通常のPCを使用している場合、メモリ要件はそれほど重要ではないかもしれませんが、実行時の速度要件は、ターゲットプラットフォームが何であれ重要になります。

高レベルの技術要件が「ユーザーが満足できるほど十分」である場合は、低レベルの技術要件についてのみ心配する必要があります。基本的には、ターゲットコンピューター、ターゲットOS、および3番目の要件です。パーティライブラリは処理できます。

すでにいくつかの低レベルのコードを書いているようです。エラー状態とハッピーパスの両方について、残りのハードウェア/ OS /ライブラリインターフェイスコードを記述し、各コードの時間を計ることをお勧めします。これにより、コードが各インターフェイスをどのように処理するかについて、はるかに優れたアイデアが得られます。（例：このユーティリティ呼び出しのタイムアウトは、アプリケーションをバックアップするのに十分な長さです！タイムアウトを短縮できるかどうか、または呼び出す前にエラーチェックを改善できるかどうかを確認したほうがよいでしょう！）

最後に、ほとんどのリアルタイムソフトウェアは、次のようなループとして記述されています。

while( program_running )
{
  // This period needs to be long enough for you to do your work
  //  but short enough that your user doesn't think your program
  //  is choppy. Anything better than 50 Hz is usually good enough
  //  for an application with a human interface.
  wait_for_short_period() 
  check_interfaces_for_new_data()
  update_model() // or state machine
  update_outbound_interface() // the speaker, monitor, whatever
}

これにはバリエーションがあります（待機ではなく定期的なコールバック）が、それが一般的な考え方です。

于 2010-03-01T13:19:38.357 に答える
0

1つの方法は、要件について話し合い、デザインパターンとデザインソフトウェアに精通している人と非常に大雑把にデザインをスケッチすることです。このプロセス中に、適用されたデザインパターンの概念について話し合うことができます。

于 2010-02-26T15:08:02.873 に答える