2009-05-08 3 views
1

私は、金融取引をどのように処理するかについて、この非常に長いフローチャート(8ページ)を与えられました。アプリケーションの最も重要な部分。私はあなたがどこにでも線を引いた四角形や二等辺三角形を想像して、データベースのどのフィールドを更新、計算、検索、保存するかなどを記述した詳細シートを分けることができると確信しています。本当に大規模なビジネスプロセスを作成する際には、どのような手順が必要ですか?

誰もがこの事をコーディングするための最善のアプローチについてのヒント/トリック/提案を持っていますか?あなたは、フロー・チャートのような50億のif文から始め、そこからのリファクタリングから始めますか?

ご迷惑をおかけして申し訳ございません。

+2

フローチャートをオブジェクトのやりとりやユースケースに分解すると、おそらくトランザクションタイプごとのユースケースがうまくいくように見えます。 「明らかに関連する決定の周りに円を描く」という方法でオブジェクトに抽象化できるフローチャートの部分がある可能性があります。 フローチャートが実際にオブジェクトインタラクションダイアグラムであれば...話すことが異なる。 –

答えて

3

プロセスが人間とのやり取り(意思決定)を必要とし、長時間実行されているか、類似のビジネスプロセスが多数ある場合は、K2やProcessMakerなどのワークフロー(BPM)製品が適切かもしれません。ビジネスプロセスがデータフローを大きく編成している場合は、BizTalkのような製品が適切かもしれません。

ワークフロープログラミングの重要な学習曲線があることに注意してください(通常、デバッグサポートが貧弱なため)。したがって、ワークフロープログラミングに精通しておらず、迅速な処理が必要な場合は、おそらくこの道を踏み出すことは望ましくありません。

  1. 識別:あなたのタスクは、比較的高速なプロセスを実装する場合

    その後、私は次のようにそれに取り組むだろう(それは一時停止せずに最初から最後まで実行され、人間の相互作用を必要としないという意味)プロセスは、プロセス全体のための各処理ステップと ための(失敗) ユニットテストと共に、プロセス ステップの詳細のいずれかを実施することなく、

  2. コードプロセス の実行可能なシェルステップ。
  3. ビジネスを識別プロセス は
  4. と相互作用するサブシステムを識別するオブジェクト毎 プロセスステップは、データを識別
  5. と相互作用 へとから流れ、各サブシステム
  6. ビジネスと対話 の契約を識別 オブジェクト
  7. 必要な場合は オブジェクトをユニット化し、 の単体テストが最終的に必要です 製品
  8. すべての単体テストが合格するまで、1つのプロセスステップを実行します( )。
  9. デバッグプロセス全体(必要に応じて部 テストを追加)
  10. 統合テスト(必要に応じて をテストするユニットを追加)
  11. 展開
1

私は最初に混乱からビジネスオブジェクトを抽出するのが好きです。典型的な低結合力、高い凝集力のガイドラインを使用して、責任を分けるためのクラスをいくつか考えてみましょう。その後、フロー内の重複を探し、その重複をコードから守る方法を考えてください。

-2

個人的には、私は再利用可能な機能に変わるパターンを探します。しばしば、私が渡すパラメータに応じて、複数のタスクを処理できる非常に汎用的な関数を作成できるいくつかの異なる領域があります。

+0

-1 SRPの露骨な違反のため –

2

あなたは私の同情があります。

言われていることは、あなたが抽象化できるものを探します。類似点を探します。多かれ少なかれ一貫性のあるセクションを取り出し、そこから関数を書く。

あなたがベストを尽くしたら、リファクタリングに多くの時間を費やす準備をしてください。

私は人間が正確な8ページのフローチャートを書くことができないと考えているので、正しく動作しないものについてあなたを非難する人のために準備してください。理想的には、ロジックをフローチャートに戻ってトレースし、少なくともその責任をそらすことができるはずです。残念ながら、これは実際に何かにリファクタリングすることと実際には互換性がありません。

+0

アメンは責任ポイントに! – Micah

2

大きなものには、適切なモデルを用意しておくのがよいでしょう。あなたのビジネスプロセスを見て、俳優、行為者などを特定します。そのモデルをいったん完成させたら、肉体を作り始めます。俳優や行為の面で特定のステップが意味することを理解し、俳優や行為者は、そのやりとりの部分を処理するのに最適な場所です。

これは、大きなフローチャートをSequence Diagramに変換します。これは、フローチャートをコードに変換するのに役立ちます。オブジェクトに必要なメソッドを特定します。最初の場所)。

これは、OOパースペクティブを前提としているため、COBOLでこれを実行していると、あまり役に立ちません。

-1

まずは、しないでください。真剣に、しないでください。

あなたの仕事ではないだけでなく、あなたの専門でもない数百のプロセスの所有権を取得しようとしています。そうすれば、あなたは正しい(私を信じる)ことはできませんし、フルタイムの仕事(または6!)を作って、決してうまく動作しないシステムを修正し維持することになります。

このような大規模なビジネスプロセスを生み出す環境にいる場合は、合理的な資金調達が可能な環境にいることを願っています。あなたが検討したいのは、ビジネスプロセス管理を意味するBPMソフトウェアです。 Captaris、K2、Ultimusなどの企業はすべて、IBMなどの大男と同様に製品を開発しています。これらのツールを使用すると、ビジネスエキスパートにツールを提供できるので、自分が何をしているのかを実際に知っているプロセスの人々は、ドメインエキスパートが自分のドメインを管理しています。 Visioのように(または..それはvisioです!)。あなたは開発者として、部門間のトランスポートを提供し、さまざまなビジネスシステムを結びつける(またはさまざまなソースからデータを引き出す)特殊ロジックを提供します。

BPMソフトウェアは約20Kの範囲から開始され、さらに、あなたが拡張するにつれ、Sharepoint(無料で最大100K + $から始めることができる)やAdobeやInfopathのようなフォームシステムが必要になるでしょうが、

これは愚かな量のように聞こえるかもしれませんが、本当にそうではありません。あなたの要因は、労働コスト、すべての労力です。あなたが会わなければならない様々な人々の費用いくつかの人々のためにフルタイムの仕事を巧みに創り出し、おそらく100%になることはないシステムを作り出しています。

知識の専門家の手元にドメイン固有の知識を持ち、IT固有のタスクをITの手に委ねてください。これは、私が部署を締め出した後にIT部門を見て、貴重な従業員がベビーシッターのレポート作成に高い給与を支払ってしまうところです。正直なところ、私はもう一度言います、しないでください!これは、棚の製品があなたが作ることができるものよりもはるかに優れているそれらの分野の一つです。

(ほとんどの私の例は私の最新の背景を裏切っています。私は.NETの開発チームを持つWindowsのショップです。Unix、LinuxなどのBPMソリューションを簡単に見つけることができます)バックエンドとしてJavaを使用したソースオプション。

編集:ああ、記録のために、あなたが絶対に棚を買うことができないなら、あなたの予算がゼロの場合、ほとんどの商用BPMはバックエンドで駆動されるデータベース(またはスプレッドシート)を備えたゲート式のフローチャート-eqsue構造を備えた、状態ベースのマシンです。あなた自身で行う必要がある場合でも、さまざまなBPMプロバイダーのデモを試してみて、そのアプローチをエミュレートするのに十分役立つでしょう。

EDIT2:リンク。 Captaris

Open Source (ProcessMaker)

トン以上がありUltimus

が、これらは、あなたが開始されます。 BPMソフトウェアは、数千から数百万ドルに及ぶ可能性のあるものの1つであり、潜在的に無料です。私はCaptarisについて話すことができます。私はCaptarisを約3年前に選び、広告として働いています。

1

私は完全にデビッド・Tに同意 - 何の人間が作成することはできません8ページのフローチャートを参照してください。私は基本的に金融取引のライフサイクルを概念図から最終状態に記述した状態図(http://en.wikipedia.org/wiki/State_diagram)に変更します。これはおそらく、プロセスの設計と実装にかかる全体的なアプローチに役立ち、ネストされたif文を大幅に減らします(各ネストはコードの複雑さと脆弱性を指数関数的に増加させます)。ライフサイクルの各ステップが明確に切り離されている場合、他のステップに影響を与えることなく、必要に応じて簡単に変更できます(はい - ビジネスニーズが変化します)。トレーサビリティとデバッグのために、各ステップが明確に記録されていることを確認するために、テストのニーズとログを覚えておいてください。

1

テクニカルデザイン文書なしでどのようにしてフローチャートに到達しましたか?最初の紅潮では、標準に従わなかったように聞こえます(IEEE 12207が気になります)。

私の経験から、UML、ユースケース図、クラス図、およびオブジェクト図が欠落していることがわかりました(OOの観点だけでなく、COBOLでも方向性が必要です)。エンドユーザ/ SME)をこれらの図に追加することができます。

私も決定マトリックスに見てね(もしくはあなたが十分に古いなら - 真理値表)管理しやすいものにそのフローチャートをダウントリムされますどのようなプロセスのパス任意の時間や状況で必要とされている定義します。

私はまた質問する必要があります:誰がこのフローチャートを描いたのですか?それが機能的な流れであると描かれた場合は、それをプロセスフローチャートに変換する必要があります。プロセスステータスマーカー、カウンタなどを追加します。

あなたがプロセスツリー(プロセス名、パラメータ、および説明)を開発し、誰とでも共有している間。

関連する問題