n階層システム設計の考慮点

第4回 各コンポーネントの設計について(2)

この記事を読むのに必要な時間:およそ 7 分

前回はプレゼンテーションレイヤの設計と配布について解説しました。今回はこれを踏まえて,Windows FormベースおよびWeb Formベースそれぞれのユーザインターフェイスコンポーネントの設計について説明していきます。

ユーザインターフェイスコンポーネントとユーザインターフェイスプロセスコンポーネント

画像

まず,プレゼンテーションレイヤを構成する「ユーザインターフェイスコンポーネント」「ユーザインターフェイスプロセスコンポーネント」について,簡単に説明しましょう。

ユーザインターフェイスコンポーネント

ユーザインターフェイスコンポーネントは,ユーザに対して画面や帳票,音などの情報を出力したり,画面やマウスなどの入力・操作をするユーザインターフェイス(入力デバイス)を通してユーザとの対話を管理します。これはユーザへのデータやグラフ,図形,サウンドなどを表示・出力し,ユーザからのデータの取得,ユーザインターフェイスの状態の変更,ユーザ操作の流れやタスクの進行の手助けを行います。

ユーザインターフェイスプロセスコンポーネント

ユーザインターフェイスコンポーネントから呼び出され,ユーザインターフェイスコンポーネントの要素の表示をコントロールします。また,アプリケーション内で使用する文字コードの統一,ビジネスレイヤの呼び出し,データ受け渡しやエラー処理などを行います。

ユーザインターフェイスコンポーネントの設計について

画像

① Windows Formベースのユーザインターフェイスコンポーネントの設計について

Windows Formベースのユーザンターフェイスコンポーネントの設計では,以下の点に注意して設計します。

状態の表示

業務の要件によっても異なりますが,Windows Formアプリケーションはサーバ等に接続された状態だけでなく,出張中などでサーバに接続できない環境での使用も想定されます。そのため,現在の使用環境を操作者に明確に判断できるように設計したほうがよいでしょう。

データの同期

同時に開かれた複数のWindows Form間でデータのやり取りをする場合は,データ連結もしくはWindows Communication Foundation(以降WCFと略します)を用いて同期します。これによりデータの同期のためのコードを大幅に省略することができます。

エラー対応

Windows Form内でもエラーハンドラを実装し,.NET Frameworkが表示する例外画面およびメッセージボックスを表示しないようにします。これらの例外画面内に表示される情報をフォーム内のロジックでキャッチし,操作者に操作の続行を判断させたり,イベントログやアプリケーションログに出力し,障害情報の収集,原因究明のための情報を蓄積するのに役立てるようにします。私がこれまで参加した複数のプロジェクトで得た経験として,正常ケースよりエラーとなるケースのほうが数~数十倍多くなることが多いです。これらのエラーケースにいかに適切に対応できるかによってエンドユーザにとってアプリケーションの信頼性が上がるといっても過言ではないでしょう。

ユーザ操作

ユーザインターフェイスコンポーネントでは,ユーザへのデータのフォーマットの変更,操作の補助,入力値の制限,検証やエラー表示を行います。

データのフォーマットでは,金額の表示項目では通貨記号や桁区切りの挿入,日付項目では「年,月,日」「/」の自動挿入などがあります。しかし,表示だけではなく,値の入力時には桁区切りや「/」は入力させず,入力確定時に自動挿入させる場合もあります。

フォーマットの例

フォーマットの例

ユーザ操作の補助では,マウスやキーボードでの操作やタブキー,カーソルキーなどによる項目の移動や入力,選択項目にあった項目の表示,入力範囲の制限などを行い,業務の流れにあった操作を促し,操作しやすくします。

入力値の制限の一般的な一例としては,日付の入力項目では「昭和」を年号として選択した場合,年の入力値として「1」「64」の間しか入力できないようにします。これ以外の値(たとえば「70」など)をほかの項目などからコピー・ペーストで入力した場合も入力値の検証でエラーとします。

ユーザ入力制限・補助でよく使用されるのが,DropDownListやListBoxです。しかし,これらの選択項目に対する配慮が欠けている場合があります。たとえば,西暦の選択や日付の選択において,DropDownListではデフォルトでPageUp,PageDownでは28文字送られます。この場合,日付入力で「1日」が表示されている状態でPageDownボタンを押下すると「29日」が表示されていしいます。そこで,移動数を10ずつに変更すると「13日」「22日」が選択しやすくなります。わずかなことですが,ユーザにとってはキー操作の回数が減るため,操作効率の向上につながります。

必須入力,選択項目については,アプリケーションのポリシーを作成しアプリケーション内で統一したほうがよいでしょう。ただし,必須項目のポリシーをきつくしてしまうと操作性が落ち,操作者の生産性の低下や不満が多くなることがあります。これらは外部設計時に実際の操作者に意見を聞き,同意を得るなどの方法も検討するようにします。

入力値の検証では,上記例のほかに入力または表示された項目間での値の妥当性チェックや,不正な操作を引き起こすSQLインジェクションなどを防ぐ必要があります。一般にSQLインジェクションなどの攻撃は,Webアプリケーションに起こるものと考えられがちですが,Windowsアプリケーションでも発生する可能性があるため,防御する必要があります。

エラー表示については,システムエラー,アプリケーションエラーや,入力・選択項目に関するエラーなどが考えられます。それぞれのエラーの深刻度によってエラー表示の方法が異なってきます。また,入力・選択項目のエラーでは,一画面内で複数個所エラーがある場合のエラー表示方法もポリシーを立て,アプリケーション内で統一したほうがよいでしょう。いずれにしてもいきなりアプリケーションが無反応になる状態やアプリケーションが閉じるなどの現象になることはないように設計する必要があります。

コントロールの作成

アプリケーション固有のコントロールやコントロール群を纏めたカスタムコントロールを作成する場合は,必要となるプロパティ,イベントハンドラ,メソッドのみを公開するようにします。これにより,カスタムコントロールのオブジェクトとしての強度が上がり,汎用性,再利用性,保守性が向上します。また,カスタムコントロールの設計時に,汎用性を高めるためにさまざまなコントロールや機能を追加したくなりますが,結果的にロジックが複雑になったり,再利用性が落ちたりすることが多くなります。カスタムコントロールはできるだけシンプルな構造で設計するようにします※1)。

データベース接続

Windows Form上でComboBoxのListBox等に設定する値をデータベースなどから取得する場合のみ,Windows Formから直接データレイヤのデータベースに接続を許すようにします。これ以外の場合はビジネスレイヤを経由するようにします。ここで,Windows Form上の個別のコントロールから直接データベースに値を取得する方式を採用した場合,複数のクライアントPCからデータベースへの接続回数,同時接続数が増え,データベースへの負荷が増えることとなります。また,SQLインジェクションなどのデータベースへの攻撃の脅威が増えることとなります。これらを踏まえてプレゼンテーションレイヤからデータレイヤに直接接続する場合はよく検討してから設計する必要があります。

作業中のデータ

Windows Formで入力途中の業務データは,それぞれのクライアントPC内で保持するように設計する必要がある場合があります。業務によっては一回の入力では完了せずに複数回,複数日かかることもあります。これらの業務データはどこかに保持しておかなければなりません。そのため,クライアントPC内にデータを保持する方式を検討します。

ここで,1つのシナリオを考えてみましょう。旅行代理店の店舗向けアプリケーションで,ある旅行商品の見積もり業務で複数の交通機関を使用する旅行商品があるとしましょう。この場合,それぞれの交通機関に対してオンラインもしくは電話などで予約をすることになります。一般的に,それぞれの交通機関向けに予約画面が作成されると思われます。店舗係員は予約受付業務で複数の業務画面にわたり操作を行い,最終的にすべての予約が確保されたか確認します。しかし,1つの交通機関だけ予約が確保できないため,全旅程が成立できなかったとします。

それぞれの画面で入力されたデータをデータベースに登録していた場合,すべてのデータを削除しなければなりません。また,上記のシナリオでクライアントPCが停電などでシャットダウンし,再起動が必要になった場合,データベースに残ったデータは誰も消すことはできません。このようなデータを残さないためにも入力途中の業務データはクライアントPC内で保持するように設計します。また,上記のようにクライアントPCで障害が発生した場合,クライアントPCに残った業務データはPCの起動時や業務開始の初期処理で削除するように設計します。

※1

以前担当したプロジェクトでは,画面のほとんどをカスタムコントロールで構成し,それらの表示位置やイベント制御をユーザインタフェイスプロセスコンポーネントでコントロールしたことがあります。開発当初はカスタムコントロールの抽出,グループ化や作成に時間がかかっていましたが,基本的なカスタムコントロール群が出来てしまえば,画面開発の効率は格段に向上しました。約1200画面を約15人で開発し,組み合わせテスト完了まで3ヶ月で行ったプロジェクトもありました。

著者プロフィール

露木敏博(つゆきとしひろ)

1966年神奈川県横浜市生まれ。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。

流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。

マイクロソフトMVPアワードプログラムよりDevelopment Platforms - ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。

コメント

コメントの記入