ルールに基づく業務フローの分析
「考えることが少なく、無駄なことが多い」というのが、現在の企業開発の現状です.二ヶ月後、後で面白い流れを分析します.今のプロジェクトの中で一番複雑な流れです.
まずUMLの本の判例を捨てます.それはメニュー、薬味、原料がそろっていて、実際のプロジェクトは荒地です.荒地に行って満漢全席を自分で整えるのは大変だったと思います.
最初にこの流れの説明を聞いたのはもう忘れました.一つのプロジェクトは何度も発送して受信してもいいです.一度送信してもいいです.最後の受信が終わってから、全体の流れが終わります.仕事の相手を定義して、授業を終えて行きましょう.
第1の反応は、送信と受信は2つの異なる処理項目でなければならず、その後、2つの異なる動作を定義しなければならない.完全送信と部分送信.概念は必ず正確に区別しなければならない.
その後、完全な送信と一部の送信については、いくつかのニーズの変化がありますが、プロセスの実行規則に影響はありません.これは私が業務フローの構成文に書いたResponseTask類を形成しました.その時の需要は要求-受信です.だから二つのTaskだけ書きました.その後、受信ごとにもう一つのタスクが意見書を記入するということになりました.すべての意見書が完成したら、新しいタスクを開始します.したがって、要求-受信-応答の三つの操作を行い、ResponseTaskを修正し、ResponseTypeというエニュメレーション値の属性を追加し、終了アルゴリズムを修正しました.現在の流れの実行規則はかなり堅苦しいです.完全にハードコードはエンジン内部にありますので、変えられません.以下はレスキュータイプと実行コードです.
Palel split pattern
Synch ronization pattern
紙とペンを取り出して、この絵を描きました.
考えましたが、この図は完全送信と部分送信の分岐を表現していないので、これに変えました.
今は、選択があります.ユーザが部分的に送信を選択すると、それは図1のフローを通ります.そうでなければ、簡単な2-3-4で終わります.しかし、この時は依然としてものが足りなくなり、4から始まる条件が足りなくなりました.そして、一部の提出と完全提出の唯一の違いは、1を終了するかどうかです.だから、専門的に分岐しなくても、選択とタスク2を同時にタスクとして見なします.彼らは前後関係がないので、インタフェースで操作しても、先に後がありますが、この選択はタスク2の発生を決定することができません.変更:
この計算は比較的満足できる解析モデルである.このモデルによれば、以前のハードコードの実行アルゴリズムは、ControlRuleとして抽象化され、RuleBaseから継承され、上図のフローチャートを表す.このブランチはユーザが実行時に選択したもので、暫定的に名前はChoiceです.
まずUMLの本の判例を捨てます.それはメニュー、薬味、原料がそろっていて、実際のプロジェクトは荒地です.荒地に行って満漢全席を自分で整えるのは大変だったと思います.
最初にこの流れの説明を聞いたのはもう忘れました.一つのプロジェクトは何度も発送して受信してもいいです.一度送信してもいいです.最後の受信が終わってから、全体の流れが終わります.仕事の相手を定義して、授業を終えて行きましょう.
第1の反応は、送信と受信は2つの異なる処理項目でなければならず、その後、2つの異なる動作を定義しなければならない.完全送信と部分送信.概念は必ず正確に区別しなければならない.
その後、完全な送信と一部の送信については、いくつかのニーズの変化がありますが、プロセスの実行規則に影響はありません.これは私が業務フローの構成文に書いたResponseTask類を形成しました.その時の需要は要求-受信です.だから二つのTaskだけ書きました.その後、受信ごとにもう一つのタスクが意見書を記入するということになりました.すべての意見書が完成したら、新しいタスクを開始します.したがって、要求-受信-応答の三つの操作を行い、ResponseTaskを修正し、ResponseTypeというエニュメレーション値の属性を追加し、終了アルゴリズムを修正しました.現在の流れの実行規則はかなり堅苦しいです.完全にハードコードはエンジン内部にありますので、変えられません.以下はレスキュータイプと実行コードです.
using System;
using System.Collections.Generic;
using System.Xml.Serialization;
namespace Microsoft.Applications.ChinaMobilePMS.FlowEngine
{
public class ResponseTask : TaskBase, IComparable<ResponseTask>
{
private int requestNumber = 0;
private ResponseType responseMode = ResponseType.Request;
[XmlAttribute("RequestNumber")]
public int RequestNumber
{
get { return requestNumber; }
set { requestNumber = value; }
}
[XmlAttribute("Mode")]
public ResponseType ResponseMode
{
get { return responseMode; }
set { responseMode = value; }
}
#region IComparable<ResponseTask> Members
public int CompareTo(ResponseTask other)
{
if (this.responseMode < other.responseMode) { return -1; }
else if (this.responseMode == other.responseMode) { return 0; }
else { return 1; }
}
#endregion
}
} using System;
using System.Collections.Generic;
using System.Xml.Serialization;
namespace Microsoft.Applications.ChinaMobilePMS.FlowEngine
{
public class Activity : IActivity
{
//...
public void StartActivity(string actionValue)
{
switch (mode)
{
case TaskMode.Response:
{
responseTasks.Sort();
ResponseTask requestTask = responseTasks[0];
ResponseTask receiveTask = responseTasks[1];
ResponseTask responseTask = responseTasks[2];
if (status == StatusType.Scheduled)
{
status = StatusType.InProgress;
requestTask = responseTasks[0];
requestTask.CreateTask();
}
else if (status == StatusType.InProgress)
{
switch (actionValue)
{
case "CompleteSubmit":
requestTask.Approve += new ApproveHandler(receiveTask.CreateTask);
requestTask.ApproveTask();
receiveTask.RequestNumber++;
break;
case "Submit":
receiveTask.CreateTask();
receiveTask.RequestNumber++;
break;
case "Receive":
receiveTask.Approve += new ApproveHandler(responseTask.CreateTask);
receiveTask.ApproveTask();
receiveTask.RequestNumber--;
responseTask.RequestNumber++;
break;
case "Reject":
receiveTask.Reject += new RejectHandler(requestTask.CreateTask);
receiveTask.RejectTask();
receiveTask.RequestNumber--;
break;
case "Response":
responseTask.ApproveTask();
responseTask.RequestNumber--;
if (((requestTask.Status == StatusType.Completed) && (receiveTask.RequestNumber <= 0) && (responseTask.RequestNumber <= 0)))
{
CompleteActivity();
}
else
{
responseTask.Status = StatusType.InProgress;
}
break;
default:
break;
}
}
}
break;
}
}
}
} Palel split pattern
Synch ronization pattern
紙とペンを取り出して、この絵を描きました.
考えましたが、この図は完全送信と部分送信の分岐を表現していないので、これに変えました.
今は、選択があります.ユーザが部分的に送信を選択すると、それは図1のフローを通ります.そうでなければ、簡単な2-3-4で終わります.しかし、この時は依然としてものが足りなくなり、4から始まる条件が足りなくなりました.そして、一部の提出と完全提出の唯一の違いは、1を終了するかどうかです.だから、専門的に分岐しなくても、選択とタスク2を同時にタスクとして見なします.彼らは前後関係がないので、インタフェースで操作しても、先に後がありますが、この選択はタスク2の発生を決定することができません.変更:
この計算は比較的満足できる解析モデルである.このモデルによれば、以前のハードコードの実行アルゴリズムは、ControlRuleとして抽象化され、RuleBaseから継承され、上図のフローチャートを表す.このブランチはユーザが実行時に選択したもので、暫定的に名前はChoiceです.
<ControlRule Mode="Choice">
<Choice Result="Complete">
<Then />
</Choice>
<Choice Result="Partial">
<Then />
</Choice>
</ControlRule> <ControlRule Mode="Choice">
<Choice Result="Complete">
<Then>
<Task ID="1" Action="End" Mode="auto" />
</Then>
</Choice>
</ControlRule><ControlRule Mode="Choice" />
<ControlRule Mode="Unconditional">
<Task ID="2" Action="Start" Mode="manual" />
</ControlRule> <ControlRule Mode="Conditional">
<Condition>
<Task ID="1" Status="Completed" />
<Task ID="2" Status="Completed" />
<Task ID="3" Status="Completed" />
</Condition>
<Then>
<Task ID="4" Action="Start" Mode="manual" />
</Then>
</ControlRule>