Qt + MVP + QThread。 自転車を作る

すべての人に良い一日を！



最近、一片の鉄と通信するためのユーザーインターフェイスを作成するという、かなり興味深い仕事に直面しました。 彼女との通信は、COMポートを介して行われました。 作業はWindowsオペレーティングシステムのリアルタイムシステム（これと同じハードウェア）を使用することになっているため、GUIの速度が低下しないようにするため、COMポートを使用する作業を別のストリームに入れることにしました。 システム自体の要件は絶えず変化していたため、修正を最小限に抑え、高速化するために、MVP設計パターンを使用して記述することも決定しました。 Qtが開発環境として選択されました。 私はこの媒体とその機能が好きだからです。 それで、Qt + MVP + Qthreadの束が判明しました。 誰がそれのすべてを気にかけ、どのような熊手に行ったのか、猫をお願いします。

計画中

COMポートを介して通信する特定のデバイスがあります。 さらに、タスクを少し複雑にします。キーボードから入力されたコマンド「ala-console」の助けを借りて、およびデバイスへのリクエストがタイマーで送信される自動モードの両方で通信​​したいです。 また、デバイスからの応答を受け入れて処理し、フォームに表示する必要があります。 COMポートへのメッセージの送受信に関するすべての作業は、個別のスレッドで実行する必要があります。 さらに、プログラムのさまざまな場所からコンピューターに接続されたデバイスにメッセージを送信できる必要があります。 また、テスト（hi TDD）を作成できることが望ましいです。



Qt + MVPバンチに関するHabréの記事はすでにありました[1] 。 Qtでスレッドを使用することに関するいくつかの記事もあります[2] 、 [3] 。 つまり、MVPの本質は、アプリケーションロジックがその外観から分離されていることです。これにより、ユニットテストを使用してこのロジックをプログラムの残りの部分から個別にテストし、他のアプリケーションで使用し、変化する要件を満たすために変更を迅速に行うことができます。



用語について少し：

表示 -プログラムの表示を担当します。これがフォームになります。

モデル -プログラムのロジックを担当し、そこからメッセージがCOMポートに送信され、着信応答パケットがその中で分析されます。

プレゼンターは、ビューとモデルの間のリンクです。

これについて簡単に説明すると、 こちらとこちらで詳しく読むことができます 。 コードに取り掛かる時です。

小さなアプリケーション（最後に完成したプロジェクトへのリンク）を作成し、作成時に記事のタイトルに配置されているものを実装します。

モデル

私は、インターフェイスではなくロジックでプログラムを書き始めるのが好きです。

そのため、ModelComPortクラスを記述することから作業を開始します。

最初に、COMポートへのメッセージ送信を実装します。



私たちのクラスは：

1. システムで使用可能なCOMポートを自動的に検出します。
2. 指定した速度で、指定したCOMポートとの接続を確立します。
3. COMポートにメッセージを送信します。
4. COMポートから受信したメッセージを解読します。

表示は次のとおりです。



ご覧のとおり、変更される可能性のあるプロパティについては、getメソッドとsetメソッドを設定します。 現時点では、ComPortThreadなどのオブジェクトに注意を払わないでください。以下で説明します。



ModelComPort.cppファイルは引用しません。いくつかのニュアンスのみを説明します。



ご覧のとおり、デザイナーで、デフォルトの通信パラメーターをすぐに構成し、システムにインストールされているCOMポートを判別します。 配列に入れたすべての利用可能なCOMポートの名前。 これが行われる理由を説明させてください。 事実、将来接続パラメータを表示するフォームは、システムで使用可能なCOMポートについて何も知らず、その能力はありません。 ただし、ユーザーに接続する特定のCOMポートを選択する必要があるため、今後このリストをフォームに転送します。



利用可能なCOMポートを決定する方法は非常に簡単です。

 void ModelComPort::searchComPorts() { foreach (const QSerialPortInfo &info, QSerialPortInfo::availablePorts()) { m_listPorts.append(info.portName()); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

次に、接続を作成する方法を検討します。





ここではすべてが簡単です。 まず、すでに接続されているかどうかを判断します。 これは、同じボタンをクリックすると、ユーザーがポートに接続し、ポートから切断できるようにするためです。 つまり、たとえば、ブート時に無効になります。 接続ボタンを1回押すと接続され、接続ボタンを2回押すと切断されます。 そして円で。

次に、接続先のCOMポートの名前を知っているかどうかを判断します。 次に、ポートで動作するスレッドを開始したかどうかを確認します。 スレッドが実行されていない場合は、作成して開始し、すでにCOMポートに接続されています。 ここで、おそらく、詳細に停止する価値があります。 実際には、別のスレッドでCOMポートを操作するには、この同じスレッドが操作中に接続を作成する必要があります。 したがって、ModelComPortクラスでは、自分で接続を作成するのではなく、接続を作成し、接続するパラメーターを渡すことをストリームに伝えます。

次に、スレッドに接続を作成する時間を与え、接続を作成できたかどうかを確認します。 すべて順調であれば、接続されているというフラグを設定します。



最後に、現在の接続設定を確立または取得できるメソッドと、現在の接続状態を取得できるメソッドがあります。



条件の1つはタイマーとコンソールの両方からコマンドを自動的に送信できることであったため、コンソールからテキストコマンドを受信し、それを解読してCOMポートに送信するメソッドが必要です。

入力メソッドは、コンソールから行を受け取り、対応するコマンドを送信します。

 void ModelComPort::onCommand(QString command) { if (command == "On") { sendommand(ON); } else if (command == "Off") { sendommand(OFF); } .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

私たちが持っているすべてのコマンドは、別のファイルに配置され、3桁のコードを持ちます。

 Enum Commands { ON = 101, OFF = 102 .... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

さて、sendommandメソッドはパケットを形成し、送信のためにスレッドに渡します：



文字列thread.transactionの数値250（バッファ、250）。 これは、パッケージを送信するミリ秒単位の時間です。 この時間中にパケットを送信できなかった場合、デバイスとの通信がないと見なし、エラーを表示します。

ModelComPortクラスにはすべてのものがありますが、次にPresenterComPortクラスの作成に進みます。

発表者

前述のように、PresenterはViewとModelの中間です。 つまり、二重の機能があります。 一方では、このクラスはGUIで実行されるすべてのユーザーアクションに応答する必要があります。 一方、すべてのビューとモデルの同期を提供する必要があります。 つまり、複数のビューがある場合、それらに表示される一般情報は同じである必要があります。 これは、第一に、第二に、（私たちの）ビューに入力されるデータは、モデルが動作するデータと同期する必要があるということです。

プレゼンターをご覧ください。



ご覧のとおり、パブリックメソッドは1つしかありません。これは、（私たちの）ビューをPresenterにバインドするために使用されます。 ビューを単一のオブジェクトとして操作するには、すべてのビューを1つのインターフェイスから継承する必要があります。 この場合、1つのビューを使用し、それをIViewComPortインターフェイスから継承します。 この実装の詳細については、こちら[1]をご覧ください 。 appendView（）メソッドをより詳細に検討してください。



その中に、送信されたビューがリストされ、プレゼンターはこのビューから来る信号に接続されます。 これは、フォーム上のすべての変更についてプレゼンターに知らせるためだけに行われます。



すべてのメソッドについては説明しません。コードはそこで複雑ではありません。接続パラメーターを（私たちの）ビューに設定する1つのメソッドの例に焦点を当てます。 上記で述べたように、フォームはシステム内のCOMポートを認識しませんが、ユーザーは接続する前にこの情報を表示する必要があります。 このすべてがメソッドを作ります



ご覧のとおり、モデルからすべてのCOMポートのリストを要求し、この情報をフォームに入力します。

私は可能な接続速度を厳密に修正しました;私の仕事ではほとんどの場合9600を使用しますが、念のためさらにいくつか追加しました。

残りのコードは、記事の最後にレイアウトされているプロジェクトで見ることができますが、それ以外の場合は、すでに非常に拡張されており、さらに多くのことが議論されています。

表示する

フォームには、接続設定を設定するための2つのコンボボックスと、COMポートへの接続/切断を担当する1つのボタンがあります。 また、コマンドを書き込むコンソールも用意されます。 また、接続の現在のステータスを表示するLEDもあります。 接続されている場合、緑色に点灯します。



最終的なフォームビューを以下に示します。





フォームコード自体は特に重要ではありません。各ComboBoxで選択された項目が変更されたときに信号を送信し、接続ボタンが押されたときに信号を送信します。

これらの信号はすべてプレゼンターによってインターセプトされ、さらに処理するためにデータをモデルに送信します。



スレッドの実装に移りましょう。スレッドの実装は、COMポートの操作を担当します。

Qtのスレッドでの作業をより良く整理する方法については、いくつかの意見があります。 誰かがスレッドを作成してそこにデータを入れ、誰かがQthreadから継承してrun（）メソッドを再定義します。 それぞれの方法には長所と短所があります。 この場合、2番目の方法に進み、Qthreadから継承します。

ComPortThread

それでは、ComPortThreadクラスを見てみましょう。



ご覧のように、モデルからCOMポートへの接続設定、モデルから送信されるCOMポートの現在の状態（接続されているかどうか）、およびステージ（接続/切断）があります。



実装に移ります。



ここでは、同期スレッドを使用したことのある人や、同期スレッドに慣れていない人にとっては新しいことはないと思います。Qtのドキュメントを参照することをお勧めします。

接続方法に移動します。



ご覧のとおり、ここでは接続を作成するのではなく、ワークフローがあるかどうかを確認し、ない場合は新しいスレッドを作成し、接続を作成するインテントフラグを設定します。切断したい意図を明らかにします。 スレッドによって行われるすべての作業はrun（）メソッドで行われ、オーバーライドされます。



フロー変数を変更する前に、ストリームをブロックしてから、ロックを解除する必要があることに注意してください。 変更をすぐに有効にしたい場合は、彼を起こしてください。



すべての有用な作業が実行されるメインメソッドに戻ります。



まず、ローカル変数を作成します。ローカル変数には、フロー中に変化する可能性のある情報を入力します。 次に、終了したいフラグを設定するまでストリームが回転する無限のサイクルに入ります。

ストリームを回転させながら、フラグを確認し、フラグに従って特定のアクションを実行します。 一種のステートマシン。 つまり、COMポートに接続することを示すフラグがある場合は、接続してこのフラグをリセットし、別のコマンドが発行されるまでスリープ状態になります。 さらに、COMポートにメッセージを送信するコマンドが到着すると、スレッドが起動し、送信する必要のあるメッセージを受け取り、指定された時間内に送信を試みます。 送信できなかった場合、ストリームは外部オブジェクトがサブスクライブできる信号を送信し、送信が失敗したことを確認します。

送信が成功した場合、ストリームは指定された時間だけ応答を待機します。 答えが得られない場合、ストリームは信号を送信しますが、これもすべてのオブジェクトがサブスクライブできるため、鉄片が応答していないことがわかり、すでに対処しています。

回答が受信されると、ストリームは再びデータの準備ができているという信号を発し、それらを取得して処理することができます。

すくい

一般的に、言葉では簡単に聞こえますが、ニュアンスがあります。 実際、モデルは信号を受信できません。 つまり、パッケージが届きましたが、Modelはそれを知りません。 一方、Presenterは信号を受信できます（Qobjectから継承されているため）が、PresenterはCOMポートで動作するストリームにアクセスできません。 2つの解決策があります（おそらく、コメントを書いて知っている人もいます）、最初のオプションはPresenterでストリームを操作することです。 あまり良いアイデアではないように思えました。そのため、Presenterへのメッセージのパック/アンパックの作業も行う必要があります。つまり、プログラムロジックの一部はモデルではなくPresenterにあります。 私はこの考えを捨てました。 2番目のオプションは、クラスComPortThread Singletonを作成することです。 そして、Presenterをシグナルにサブスクライブし、Modelですべての処理を実行しますこれを行うには、ComPortThreadクラスを少しやり直す必要があります。



デザイナーとデストラクタを外部アクセスから隠し、リンクを取得するメソッドを実装し、ModelComPortクラスとPresenterComPortクラスでコンストラクタに行を追加します。

 thread = ComPortThread::getInstance();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのクラスのデストラクタに行を追加することを忘れないでください：

 if (thread) { thread->free(); thread = 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スレッドオブジェクトのfree（）メソッドはそれ自体への参照をカウントし、ゼロになるとすぐに削除を許可します。 これは、ダングリングリンクが可能なオブジェクトの削除を防ぐために行われます。 したがって、ComPortThreadオブジェクトを使用したすべてのクラスで、オブジェクトの宣言をポインターの宣言に変更し、ポインターを介してストリームを操作します。 詳細はソースにあります。



最後に、すべてをまとめて、main.cppファイルを作成します

おわりに

まあ、それがすべてです。



あなたのフィードバック、提案、批判は興味深いです。



ボリュームが非常に大きいことが判明したため、できるだけ多くの実装の詳細を強調したいので、質問があればコメントで答えようとします。 PMのエラーについて書いてください。



私からは、この実装は絶対に正しいと主張するのではなく、それを作成する方法に関するオプションの1つの説明です。 この記事は私にとって最初のものですので、あまり蹴らないでください。 約束されたプロジェクトコードは、 ここで取得できます 。



PSコメントで尊敬されているkulinichとsemlanikによって与えられたコードに関する小さなコメントを修正しました。



PPSディスカッションの最中に、尊敬されるSingerofthefallによって提供されたパート1とパート2のリンクのおかげで、記事で説明されているストリームを操作するアプローチは、常にプログラマーの期待に応えることができず、意図したとおりに動作しないことが判明しました。

最初のコメントで推奨されているように、スレッドの操作にはQobject.moveToThread（）メソッドを使用する方が安全です。