UI が SDI のシステム画面遷移について思うこと - 同時に複数画面を開けないか?

2020年10月25日日曜日

システム開発 閑話

t f B! P L

今回はシステム開発についての閑話です。

 

技術的知識が無くても読めます。

 

 

Windows のアプリ開発においては、昔からMDIとSDIという画面デザインの規格があり、用途に応じて使い分けていた。

MDIはマルチドキュメント インターフェイスの略で、一つのウインドウ枠の中に複数のサブウインドウを表示する事で、複数の情報(ファイルなど)を同時に表示するウインドウレイアウトだ。

 

SDIはシングル ドキュメント インターフェイスの略で、一つの情報(ファイルなど)は、一つのウインドウでしか表示しないウインドウレイアウトだ。

複数の情報を表示する時は、アプリを二重起動する。

 

昔は、アプリも業務システムもMDIが主流で、SDIはテキストエディタなど、扱うデータの規模が小さいアプリで利用されていた。

Excelも昔はMDIで開発されていて、複数のExcelファイルは一つのExcelのMDIウインドウの中に複数のサブウインドウを表示する事で閲覧していた。

Word,PowerPointと併用するとき、ExcelだけMDIウインドウに纏まってしまうので使い難かった。

 

Excel2013からはSDIに変わり、この点は使いやすくなった。

 

時代の流れとして、ウインドウレイアウトはSDIが主流になりつつある。

PCのリソースが潤沢になりアプリの二重起動が苦も無くできるようになった事と、複数のアプリを併用する事が増えたせいだと思う。

 

先のExcelの話と同様に、Word,Excel,PowerPointを併用するなら全部SDIの方が、閲覧しやすい。

また、スマホやタブレットの普及の影響も大きい。スマホやタブレットではMDIは扱えない。

 

なぜ一度に一つの画面しか使用できない画面遷移にするのか

 

業務システムの世界では長い間MDIが採用されてきた。

今でもクライアントサーバータイプのシステムでは、MDIで開発されている業務システムは多い。

業務システムのMDIは一見SDIに似ている。

しかし、通常は最初にログイン画面でユーザー認証してから、メインメニュー画面へ遷移し、そこから各種の作業用画面を開くスタイルになっている。

 

システムによって一つずつしか画面が開けないものも多く、複数開けても、親ウインドウからサブウインドウを開く形式になっている。

 

画面遷移の実装も、プログラム的に親ウインドウをまず起動して、そこからサブウインドウを起動する作り方をする。

完全にMDIの作り方が定着している。

 

WEBアプリケーションの場合はSDIスタイルになるが、システムによっては画面遷移を厳しく制限していて、一度に一つの画面しか開けないものも多い。

 

なぜこのように一度に一つの画面しか開けなかったり、MDI的に親ウインドウからサブウインドウを開く形式で開発するのかと言えば、システムの信頼性を確保しやすい作り方だからだ。

 

一度に一つの画面しか開けないので、複数画面が同時に非同期で使用された場合の「排他制御」を必要としない。

もし、複数画面が同時に非同期で使用された場合は、テストケースが膨大になってしまい、開発コストが高騰してしまう。

だからシステム発注者もあまり、この機能を強く要望しない。

 

複数ユーザー間のデータベースの排他制御はトランザクション制御というDBMS(Oracle,SQL Server, PostgreSQL,MySQLなどの事)の機能で実現されている。

ユーザー単位で排他制御を行うので、同じユーザーが使用する複数の画面間での排他制御は、通常は想定していない。

セッション単位でトランザクション管理をしているので、同時書き込みはしないが、データの整合性は保証できない。

設計段階で想定する必要がある。

 

だから一度に一つの画面しか開けない画面遷移の仕様は、システム開発者に取っては楽に信頼性の高いシステムを作りやすい仕様なのだ。

 

ユーザーは一度に複数の画面を閲覧したい

 

しかし、これはユーザーの利便性を考えると好ましい画面遷移ではない。

 

以前、製造業の原材料所要量集計のシステムを開発したとき、ユーザーがどのようにシステムを使用しているかの話になったとき、「ユーザーはシステムをわざわざ二重起動して、パラメータの異なる複数の所要量集計結果を同時に複数開き、比較照合している」と聞いたとき、「ユーザーはやはり複数の画面を同時に閲覧したいのだろうな」と思った。

 

こんな場面には何度も遭遇している。

 

昔はコンピュータリソースが貧弱だったので「一つの画面に出来るだけ多くの情報を表示して欲しい」というニーズが強かった。

 

極端な話、多くのユーザーは「一つの画面で全部の業務ができるようにして欲しい」と思っている。

実際そんな要求を受けたこともある。

 

現実には、情報量や信頼性の面で実現できないから、複数の画面を表示している。

 

画面遷移と排他制御の考え方を変える必要がある

 

ECショップなどのWEBアプリケーションの場合は、同時に複数の画面を開く事ができるようになっていて、利便性に優れている。

 

しかし、業務手順の複雑な業務システムの場合は、前手順から後手順の画面まで進んだ時点で、既に完了しているはずの前手順の画面が開かれると、前手順を使用できないように制御しなければならない。

結局、一度に一つの画面しか使用できないのと、あまり変わらなくなる。

 

ECショップなどのWEBアプリケーションの場合は、利便性に優れるが画面レイアウトはかなり制約があるはずである。

 

ランダムにどの画面から開いても問題の無い画面デザインになっている。

 

業務手順の複雑な業務システムではとても採用できない。

 

最近はWindowsのUWPという技術を使用するのだが、これはスマホやタブレットに対応するため、完全なSDIになっている。

これは、従来のようなMDIスタイルの画面遷移が採用できない。

 

だから、一度に一つの画面しか表示できない。

複数の画面を開きたければ二重起動するしかない。

 

システムによっては信頼性の面から二重起動を禁止するものも多い。

スマホやタブレットで使用するならこれでも良いのだが、PCでは生産性が落ちてしまう。

 

今はデュアルスクリーンでPCを使用する時代だ。

画面も大きい。4Kスクリーンを使用する人も居る。

 

こんな時代に従来の画面遷移の考え方を継続するのは、時代遅れではないかと思う。

 

UWPなどを使用するシステム開発の場合、二重起動により複数画面の同時表示を前提に開発すべきだ。

 

ログイン認証はActive Directory認証など、起動の度にログイン認証しなくても良い方式にすべきだろう。

二重起動が容易になる。

 

その上で、一人のユーザーが複数の画面を同時に開き操作することを可能にすべきだろう。

 

データの排他制御はユーザー単位の排他制御ではなく、「ユーザー + 画面ID」単位の排他制御を行い、どの順番に画面が呼び出されても問題なく動作するようにすべきだろう。

 

ただ、このようなシステム開発は通常の業務システムでは採用されない。

無駄にコストが掛かるからだ。

 

そのような開発ノウハウも無いことが多い。

 

実際、私もこのような画面遷移を作った事がない。

 

実際につくるとどのぐらい難しいのか、どんな課題が出てくるのか、その内に簡単なサンプルでも作って考えてみようかと思っている。

その結果は多分、ブログやGitHUBなどで公開すると思う。

 

まあ、時間と体力に余裕があって気が向いたらやる。

閑話でした。

このブログを検索

Translate

人気の投稿

自己紹介

自分の写真
オッサンです。実務経験は Windows環境にて C#,VB.NET ,SQL Server T-SQL,Oracle PL/SQL,PostgreSQL,MariaDB。昔はDelphi,C,C++ など。 趣味はUbuntu,PHP,PostgreSQL,MariaDBかな ?基本無料のやつ。

QooQ