- PR -

勘定系・業務系アプリの画面構成・推移について

投稿者投稿内容
さかもと
ぬし
会議室デビュー日: 2004/05/14
投稿数: 586
投稿日時: 2006-05-30 09:08
さかもとと申します。

継承フォームのサイズ変更について

という別スレッドから、つなげて質問させて頂きたい内容がこちらの会議室向きになってきたのでこちらに新しく立てました。

あちらのフォームでは「継承フォームは使うか?(ちょっと違うけど)」という話題でしたが、皆様のご意見を伺いたいのは業務アプリの画面構成(画面推移)はどのようなものが一般的か?(よく使うか?)ということです。

私の場合(今までの会社で経験した範囲内では)

1:起動画面(利用者ID,パスワードの入力)
 1−1:ログオン情報をDBへセットし、ローカルドライブにIDを特定のファイルに書き込     んでおく
 1−2:ホストの場合はエミュレーター利用が多いのでホスト側だけで管理

2:業務選択画面(○○管理、○○処理、○○印刷)など
 画面構成としては
 2−1:画面にボタンを配置し、そこから業務画面を呼び出す 
 2−2:画面左にTreeViewを配置し、その中の各ノードから業務画面を呼び出す 
 2−3:業務選択画面には他オペレーターへの連絡事項などを表示させる機能を
     付けたりする

3:テーブルを管理するための画面
 3−1:各テーブルに対する検索画面1つ(検索結果をグリッドへ表示)
     そのグリッドをクリックさせて該当レコードの詳細画面を出す
     検索&詳細 で1セットとし、必要なテーブル分作成
     ※お客様にSQL文を叩いてもらいデータ検証をする手間を省くために使う
     ※テーブルが増えるとこの管理画面の作成がとても面倒

 3−2:テーブル管理画面は複数あり、ボタンコントロールから画面を呼び出すと
     ボタンが増えすぎるので、TreeViewかコンボボックスなどを配置した親MDI
     画面として作っておいて、各管理画面を子として画面右側などに表示

汎用機のオンライン画面となるとコントロールの変わりにコマンドだったりするわけですが、1,2,3の構成はそう大きくは変わってないような気がします。
もちろん、先人の残した資産を使わざるを得ない場合が多いのでこのようなパターンにはまるのかもしれませんが。

色々な構成があるかとは思いますが、使い勝手のよい画面構成とはどのようなものなのでしょうか・・・。

皆様はどのような画面構成・推移がよいと思いますか?

R・田中一郎
ぬし
会議室デビュー日: 2005/11/03
投稿数: 979
投稿日時: 2006-05-30 09:57
引用:

さかもとさんの書き込み (2006-05-30 09:08) より:

色々な構成があるかとは思いますが、使い勝手のよい画面構成とはどのようなものなのでしょうか・・・
皆様はどのような画面構成・推移がよいと思いますか?


自分は低コストと汎用性を考えて表上で編集させたり印刷させる方法を好みます。
この方法で殆どの機能を実現させられますし、実際、同じ画面を使いまわすため、低コストでシステムを提供できました。

しかし、使い勝手はあまり良いとは言えません。

ユーザーの好みによっても変わってくると思います。
未だに汎用機と同様のインターフェースをウィンドウズアプリケーションに求めてくるお客様もいました。

結局、最近はケースバイケースだよなぁ〜、って思います。(ミモフタモナイ・・・)
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-05-30 10:36
引用:

さかもとさんの書き込み (2006-05-30 09:08) より:

あちらのフォームでは「継承フォームは使うか?(ちょっと違うけど)」という話題でしたが、皆様のご意見を伺いたいのは業務アプリの画面構成(画面推移)はどのようなものが一般的か?(よく使うか?)ということです。


初めに... ですが、ピンポイントに一般論は語れないと思います。
だからこそ、向こうでもユーザーコントロールの話題を出しました。
(そんなわけで、デザイン部分については、良いか悪いかを書かないようにします)

引用:

1:起動画面(利用者ID,パスワードの入力)
 1−1:ログオン情報をDBへセットし、ローカルドライブにIDを特定のファイルに書き込んでおく


ローカル ディスクのファイルに書き込んでおくのですか?
ログオンの意味がないように思えますが...

引用:

2:業務選択画面(○○管理、○○処理、○○印刷)など
 画面構成としては
 2−1:画面にボタンを配置し、そこから業務画面を呼び出す 
 2−2:画面左にTreeViewを配置し、その中の各ノードから業務画面を呼び出す


これは、良く見かけるタイプですね。
ひとつのデザインなので、良い悪いはないと思います。

むしろ、その各処理がどういうアセンブリ構成になっているかが気になります。
ひとつのアセンブリで統合されているのか、または、クラス ライブラリなのか? など。

引用:

3:テーブルを管理するための画面
 3−1:各テーブルに対する検索画面1つ


「管理」とあるので、管理者・保守員用の「マスタ メンテナンス」のことでしょうか?

引用:

そのグリッドをクリックさせて該当レコードの詳細画面を出す
検索&詳細 で1セットとし、必要なテーブル分作成


これも、ひとつのデザインだと思うので、良い悪いはないと思います。

引用:

※テーブルが増えるとこの管理画面の作成がとても面倒


これは、何故でしょうか?
私は、管理画面 (フォームのことですよね?) はひとつしか用意しません。
各項目は、デシリアライズして動的に作成します。
あとは、そのファイルをメンテナンスするだけです。

引用:

汎用機のオンライン画面となるとコントロールの変わりにコマンドだったりするわけですが、1,2,3の構成はそう大きくは変わってないような気がします。
もちろん、先人の残した資産を使わざるを得ない場合が多いのでこのようなパターンにはまるのかもしれませんが。


お客さんの都合で "はまる" 場合が多いと思います。

ただ、'画面構成' は変えられなくとも、'作り込み' や '方法' まで、
汎用機の頃と同じノリにする必要はないですよね?

# 移行組の方は、この枠を取り払える視野の広さがないと、厳しいでしょうね。

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
さかもと
ぬし
会議室デビュー日: 2004/05/14
投稿数: 586
投稿日時: 2006-05-30 11:12
さかもとです。

R・田中一郎様
います、ホスト系の画面にしてくれというお客さま、そしてそうしようと言い張るうちの会社の年齢上の方・・・。
今担当している内の一つも「新規リプレイス案件だ!」と言いつつ汎用機⇒新しい汎用機という単なるハード乗せ換えになりそうだったし・・・。

じゃんぬねっと様

>ログオンの意味がないように思えますが...

説明が下手でした、実際にはシステムにログオンしたかどうかということではなく、その端末を現在使っている(その端末の画面にログオンしている)ユーザーIDなどを保持しておいて、画面上から更新をした場合に、そのIDを更新者として利用するためこのように利用しています。

ログオン日時や、現在のログオン状況などはDB側で保持しておいて多重ログインなどを防いでいます。


そして、あちらのスレッドでお聞きしようかと迷ったのですが、

>私は、管理画面 (フォームのことですよね?) はひとつしか用意しません。
>各項目は、デシリアライズして動的に作成します。
>あとは、そのファイルをメンテナンスするだけです。

これは具体的にはどのように実装するのでしょうか?全く検討が付きません・・・。おっしゃる通りフォームのことですが、汎用機からの移行組として正しく間違えた方法をいまだに使っております・・・。



[ メッセージ編集済み 編集者: さかもと 編集日時 2006-05-30 11:21 ]
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-05-30 11:21
引用:

さかもとさんの書き込み (2006-05-30 11:12) より:

説明が下手でした、実際にはシステムにログオンしたかどうかということではなく、その端末を現在使っている(その端末の画面にログオンしている)ユーザーIDなどを保持しておいて、画面上から更新をした場合に、そのIDを更新者として利用するためこのように利用しています。


ユーザーID などを保持しているのが、このファイルなんですか...? (;^-^)

引用:

これは具体的にはどのように実装するのでしょうか?
全く検討が付きません・・・。


では、私が意味を取り違えている可能性もありますね。

引用:

3:テーブルを管理するための画面
 3−1:各テーブルに対する検索画面1つ(検索結果をグリッドへ表示)
     そのグリッドをクリックさせて該当レコードの詳細画面を出す
     検索&詳細 で1セットとし、必要なテーブル分作成
     ※お客様にSQL文を叩いてもらいデータ検証をする手間を省くために使う
     ※テーブルが増えるとこの管理画面の作成がとても面倒


この内容を読む限り、「マスタのメンテナンス」のことだと思っています。
先のレスでも、

> 「管理」とあるので、管理者・保守員用の「マスタ メンテナンス」のことでしょうか?

と、確認をお願いしたつもりだったのですが... (*_ _)

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
さかもと
ぬし
会議室デビュー日: 2004/05/14
投稿数: 586
投稿日時: 2006-05-30 11:44
さかもとです。

じゃんぬねっと様
すいません・・・。
おっしゃる通り、管理者・保守員用の「マスタ メンテナンス」の事です。
混乱させてしまい申し訳有りません。


ログオン時のID保持・・・の件ですが、言葉足らずですいません。
説明が悪いですね。

「ユーザーIDを保持」ですが、以下の流れとなっています

1:ログオン処理(パスワード一致?など)
2:正確にログオンできたらDBから該当ユーザーのID、業務権限を返してもらい、それをローカルファイルを作成し一時的に書き込んでおく
3:該当ユーザーがそのシステムを利用している間はそのIDを更新者として利用。又権限を見て業務画面の表示非表示などで利用する
4:ログオフしたら該当のファイルを削除

正確には「一時的に該当ユーザーの情報のみ保持」です。
(「保持」という表現が不適切?)
この方法自体もおかしい部分があればご指摘頂ければ幸いです。

説明下手ですいません、日々痛感してます・・・。


[ メッセージ編集済み 編集者: さかもと 編集日時 2006-05-30 11:51 ]
じゃんぬねっと
ぬし
会議室デビュー日: 2004/12/22
投稿数: 7811
お住まい・勤務地: 愛知県名古屋市
投稿日時: 2006-05-30 11:58
引用:

さかもとさんの書き込み (2006-05-30 11:44) より:

おっしゃる通り、管理者・保守員用の「マスタ メンテナンス」の事です。


フォームに、「コントロールを動的に作成する」ということです。
どんな項目があって、どんな表題で、どんな長さで... を保持しているのが設定ファイルです。
(フォームの大きさはそれに合わせて変えます)

マスタ メンテナンスって、追加、削除、更新(論理削除も含む) などが基本ですよね?
すべて、ファイルの設定から動的に項目が設定できれば、このあたりの組み立ても自動化できます。

もちろん、特殊なものには対応できません。
が、そんなものは普通は作らないでしょうし、作ったとしても数は多くないでしょう。

引用:

「ユーザーIDを保持」ですが、以下の流れとなっています

1:ログオン処理(パスワード一致?など)
2:正確にログオンできたらDBから該当ユーザーのID、業務権限を返してもらい、それをローカルファイルを作成し一時的に書き込んでおく
3:該当ユーザーがそのシステムを利用している間はそのIDを更新者として利用。又権限を見て業務画面の表示非表示などで利用する
4:ログオフしたら該当のファイルを削除

正確には「一時的に該当ユーザーの情報のみ保持」です。
この方法自体もおかしい部分があればご指摘頂ければ幸いです。


何故、アプリケーション内で保持しないのですか?
別アセンブリへの値の引き渡し方が、これしか思い浮かばなかったということでしょうか?

ところで、そのファイルって、書き換え可能ですか...? (かなり危険なように思えます)

引用:

説明下手ですいません、日々痛感してます・・・。


大丈夫です、そんなに何度も謝らなくても良いですよ。(*_ _)

_________________
C# と VB.NET の入門サイト
じゃんぬねっと日誌
まいるどきゃっと
大ベテラン
会議室デビュー日: 2004/08/12
投稿数: 135
お住まい・勤務地: 群馬
投稿日時: 2006-05-30 12:02
引用:

さかもとさんの書き込み (2006-05-30 11:44) より:

2:正確にログオンできたらDBから該当ユーザーのID、業務権限を返してもらい、それをローカルファイルを作成し一時的に書き込んでおく



ファイルに保存する必要はないのでは?

ファイルに保存しなければ

引用:

4:ログオフしたら該当のファイルを削除



この処理も要らなくなりますね。

# かぶった …… orz

[ メッセージ編集済み 編集者: まいるどきゃっと 編集日時 2006-05-30 12:02 ]

スキルアップ/キャリアアップ(JOB@IT)