web-dev-qa-db-ja.com

デスクトップからウェブ-ユーザーインタラクティブワークフローの扱い方

私はこの夏、新しいバージョンのプロジェクトを開始しました。これには、独自仕様のデスクトップERPのWebバージョンの開発が含まれます。

私の会社の主な目標は、ERPのWebバージョンを提案できるようにすることです。これには、それが伴うすべての利点があります（機動性、販売の可能性SaaSバージョン、最新の外観とコンポーネント...） 、ビジネス機能を失うことなくこれにより、私たちの開発者はアプリのビジネス側をやり直すことができなくなります。主な目標は同じプロセスをWebアプリケーションに変換できます。

古いバージョンのビジネスレイヤーは、本当にGUIに依存しているため、直接再利用できません。これらのビジネスプロセスはUMLダイアグラムとして書き直され、新しいアプリを開発するためのサポートとして使用されます。

私が遭遇する問題は、ユーザーとの対話を必要とするプロセスを処理する方法がわからないということです。例えば ​​：

販売注文の検証時に、検証プロセスは、含まれるすべての製品をチェックし、利用可能な在庫があるかどうかを確認してから、さまざまな操作を実行します。在庫がない場合、ユーザーは注文をキャンセルするか、この製品を削除するか、同等のものを選択するかを尋ねられます。これは、Javascript alertまたはconfirmのように機能します。現在の「スレッド」（つまり、検証プロセス）は保留中で、ユーザーの操作を待機しています。ユーザーが選択すると、現在の製品の処理が終了し、次の製品の検証が続きます。

この種のプロセスをWebアプリケーションで処理するにはどうすればよいですか？この種のビジネスプロセスを記述し、そのように開始および保持できるフレームワーク、デザインパターン、またはその他のものはありますか？

ソリューションは、これらのビジネスプロセスをより小さなものに分割することです。私の例では、2つのサブプロセスがあります。最初のプロセスはすべての製品をチェックし、問題のある製品にフラグを付けます。次に、ユーザーはフラグが立てられた製品で何をするかを決定する画面を持ち、検証します。この時点で、すべての製品に問題がないことを確認しています。2番目のサブプロセスを開始して、他の操作を実行できます。

この例の問題は、この例ではかなり単純ですが、実際にはもっと複雑になる可能性があるということです。一部のプロセスは、このような多くのユーザーインタラクションがあり、10個のサブパートに分割できます。先ほど述べたように、ビジネスプロセスを変更したり再考したりせず、何も失わないようにしたり、新しいビジネスバグを導入したりしないようにします。

誰かがそれについて経験がありますか？このようなデスクトップからWebへの開発に対処する方法を知っていますか？

EDIT 15/07/14

この投稿については誤解がありましたが、確かに私の貧しい英語の表現と語彙に関連しています。

問題を要約すると：

UMLダイアグラムに記述された一連のビジネスワークフローを取得しました。彼らは巨大な30年前のCAMM（生産管理ERP）から来ています。プロジェクトは、JavaWeb環境でこのアプリケーションを再開発することです。重要な点は、これらのワークフローの一部はユーザーに依存するということです。これは、処理の途中でユーザーとの対話が必要になるためです。 Webアプリケーションはクライアント/サーバーアーキテクチャに基づいているため、移植方法がわかりません。これらのワークフローのやり直しや再考案は、時間がかかりすぎるため、オプションではありません。 Wt のように、Webアプリケーションでデスクトップアプリケーションをシミュレートする方法が必要ですが、Javaの場合（UIについてではなく、ワークフローの開発方法についてです） ）、またはこれらのユーザー依存のワークフローをWeb互換にするルールを定義します。

web-applicationsbusinessjava-eebusiness-logic
6
OlivierH

私が感じる主な問題は、古いアプリケーションの非常に直線的なワークフローとカスタムワークフローの間に不一致があり、Webで一般的なユーザー操作ワークフローと一致しないことです。

ビジネスロジックを含むサーバーアプリケーションと対話するWebアプリケーションは、要求/応答メッセージングスタイルで通信します。クライアントブラウザーと、ビジネスロジックを持つアプリケーションを実行するサーバーは、別のプロセスです。クライアントはリソース（htmlページ、jpg画像、JSONデータなど）を要求し、サーバーはそのリソースを本質的にstatelessの方法で提供します。これは、ユーザーセッションのグローバル状態の概念を持つ自己完結型デスクトップアプリケーションとは大きく異なるパラダイムです。デスクトップアプリケーションのユーザーセッションは、ワークステーションで実行中のプロセスによって有効になり、終了します。

したがって、基本的には常にクライアント/サーバー関係を持つWebアプリケーションで状態の維持を処理する方法が2つあります。

サーバー中心

サーバー中心のWebアプリケーションは、個々のユーザーのセッションのステートフル情報を維持します。これは通常、ユーザーが認証されるとセッションCookieを提供することによって行われます。クライアントアプリケーション（ブラウザ）は、各リクエストに固有のセッショントークンを含めます。これにより、サーバーは、クライアントがこのクライアントのリクエストを最後に受信したときからのクライアントの状態に関するステートフルな情報を取得できます。

さらに、サーバーには、一般的なビジネスユーザーが実現したいと考えるアクションの実行の背後にあるビジネスロジックのほとんどが含まれます。これは、実際のビジネス価値を持つアクションです。これは、プレゼンテーションロジックと混同しないでください。これは、特定のメニューを非表示にするなどのユーザーインターフェイス操作を実行するほとんどのクライアント側コード（Javascriptなど）です。特定のチェックボックスがチェックされている場合はフォーム。

クライアント中心

ユーザーの認証を維持し、アクティブなセッションを維持するサーバーがあるかもしれませんが、クライアント側のスクリプトフレームワーク（例： AngularJS 操作とプレゼンテーションロジック操作。このモデルの利点は、デスクトップアプリケーションをプログラムする場合とほぼ同じ方法でWebアプリケーションをプログラミングできることです。クライアントの状態は、ブラウザの現在のページへのナビゲーションによってほぼ同じように存続し、停止します。デスクトップアプリケーションの実行中のプロセスで動作し、停止する方法データベースとの通信では、データベースのプロキシとなることができるサーバー上でステートレスWebサービスを公開できます。

このアプローチに関するいくつかの重要な考慮事項は、クライアントブラウザーのユーザーが、潜在的に危険であり、アプリケーションに未知の例外ケースを導入する可能性のあるJavaScriptの動作を変更または変更できることです。このアプローチを採用する場合は、サーバーとの相互作用に細心の注意を払い、入力を無害化し、行き来するすべてのデータを検証することを強くお勧めします。

概要

要約すると、指定したアプリケーションは非常に古いものです。現在のワークフローをキャプチャし、ユーザーのニーズを評価するために正しい選択をしているようです。次のステップは、アジャイルの原則を試し、それに従い、ユーザーストーリーにビジネス価値を取り込むことです。私は白紙の状態から始めて、ユーザーストーリーでキャプチャされたのと同じビジネス価値を達成できる他の手段とワークフローを発見しようとします。このアプリケーションは非常に古いため、当時のテクノロジーによって、技術的な制約が否定的または古風な方法でユーザーのワークフローに影響を与えていた可能性がありました。基本的には、ビジネスが使用できるより良い方法、より直感的なワークフロー、およびユーザーインターフェイスがあり、同じ最終目標を達成することもできます。

9
maple_shaft

非同期プログラミングについて読む

元のデスクトップアプリは、ユーザーがポップアップから決定を選択するまで機能が継続しないGUIと密接に結合されていたようです。

Webや多くのGUIフレームワークは、このように機能しません。ユーザーの入力を必要とするすべての操作は、処理を続行できるようにデリゲート/コールバックを提供する必要があります。

それほど悪くはありませんが、現在のデザインから大幅に変更されています。 IMO WebまたはGUIツールキットに関係なく、現在の設計を分解して非同期プログラミングをサポートするのは、時間の価値があります。

1
JBRWilkinson

これ http://www.unigui.com/ は関連があるようです。これも近いようです https://forums.embarcadero.com/thread.jspa?messageID=510208&tstart= 。古い「ビジネス層」コードは、C++またはDelphiのいずれかのBorlandツールで記述されていると思いますか？

数十年前、私は16ビットDOS（Turbo Pascal）から16ビットDPMI（Borland Pascal）と32ビットWindows（Borland Delphi）に多​​くのレガシーコードを移植していました。何も壊さずにDOS部分をそのまま移植するために（コードの書き換えはオプションではなく、小さなリファクタリングでした）最初にやらなければならないことは、囲まれたWindows GUI内のコンポーネントとして配置された「DOS端末エミュレータ」を作成することでした32ビットWin32 APIと新しいWindowsコンポーネントなどを使用します。違っているように見えますが、DOSアプリケーションがモーダルダイアログなどを介してユーザー入力を処理する方法は、Windowsイベントキューの機能とはまったく異なります。エミュレーターは、別のスレッドでDOSエミュレーターを実行して物事を調整しました-すべてのユーザーI/O関数はエミュレーションレイヤーにリダイレクトされ、Windowsイベントを待機しているときにDOSスレッドを一時停止しました。 DOSコードとそのロジックはまったく変更（破損）されていません。

あなたの場合、最初に [〜＃〜] jsc [〜＃〜] C＃→JavaScript http：//jsc.sourceforge .net/examples/web/CardGames/fx.FreeCell.htm 。アプリケーションを「ブラウザーで」実行できるようになると、必要な利点（「..モビリティ、販売の可能性SaaSバージョン、最新の外観とコンポーネント...）」を1つずつ追加できます

レガシーのサーバー側言語（GUIに依存するビジネスレイヤー）にどのテクノロジーが最適かわかりません。しかし、ブラウザテクノロジーでの実行はすでにここにあり、asm.jsウェブプロセッサとして。 https://isocpp.org/blog/2013/03/cpp-to-javascript または、ブラウザで実行するレガシーコードを変換するために使用できる非常に長いツールのリスト https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-c​​ompile-to-JS

1
xmojmr

免責事項：私は非常に経験豊富なウェブ開発者ではありません。

ほとんどのブラウザでは、すべてのjsコードが1つのスレッドで実行されるため、JavaScript/Webアプリのクライアント側は通常、このように記述されていないと思います。ただし、 this （これを使用したことがないので、見つけたものにすぎません）のようなものを使用して、この動作をシミュレートし、スレッドを一時停止することができます（疑似コード）。

var stuffIsDone = false

doInAnotherThread(function () {
    // blah blah blah, do stuff, load purchase, talk to server, whatever

    // ...
    stuffIsDone = true
})

// DO NOT PUT THE BLOCKING WHILE LOOP IN THE MAIN THREAD, IT WILL FREEZE THE INTERFACE
doInAnotherThread(function () {
    while (!stuffIsDone) {} // Do nothing until stuff is done

    // stuff has been done, do whatever
})
0
Ari Porad
  > Reworking/rethinking these workflows is not an option

古いワークフローがベースワークフローを変更せずにユーザーの決定を要求するたびに、ワークフローに追加の状態を追加する必要があると思います。

古いシステムの例：

顧客が製品をバスケットに追加します
 ... 
チェックアウト：顧客はバスケットの内容を購入することを決定します
システムが検証を行います
注文記事在庫切れです
メッセージボックス：「（a）注文をキャンセルしますか、（b）この商品を削除しますか、または（c）同等の製品をもう1つ選択しますか？」
（a）... 
（b）... 
（c）...

そのため、メッセージボックスを表示する代わりに、「1つ以上の記事の在庫がなくなりました」という中間ワークフローの状態になります。

または、問題のあるアイテムの追加情報を使用して、中間ワークフロー状態「注文を処理できません」を導入できます。

従来のWebアプリでは、顧客はバスケットの概要ページにリダイレクトされ、問題のある注文アイテムの横にエラーメッセージが表示されます。

0
k3b

@JBRWilkinsonは基本的に正しいです。

WebクライアントのフロントエンドとWebサーバーのバックエンドを持つことは、本質的に非同期性の高いことです。特に、データを動的にロードしたり、物事を検証したりするためにコールバックが機能する場合など。

ただし、アプリ全体を書き直す必要はありません。ワークフローを書き直す必要もありません。 Iを処理する部分でのみ「作業する」必要があります。特に「すべて」のロジックをGUIに結び付けている場合、これはまだ十分に苦痛なため、「のみ」と記述します。フォーム。そこに行って、それをやった。

このプロセスを通じて、UIコードを共有コード部分に引き出し、UIを抽象化することで、優れたエクスペリエンスを実現しました。これらのコード部分は、デスクトップGUIとWebバックエンドの両方から使用されます。 GUIは通常どおりコントロールなどを引き続き使用しますが、Webバックエンドはそれらの情報に基づいて動的にページをレンダリングするか、JSONをクライアントに配信します。クライアントは、Web UIを制御するスクリプトコードの適切な部分で構成されています。

かなりの作業であり、その移行を行うために真剣なリファクタリングを必要としましたが、それだけの価値がありました。そして、あなたはその過程で良いソフトウェアと悪いソフトウェアの設計について多くを学びます、私はそれをあなたに言うことができます。

0
JensG