基于工作流图形化系统，高手指教
本人在做一个基于winform的图形化编程系统，基本属于一种工作流系统。
  方法是通过拖拽一定的功能模块，并像visio那样连接，从而按照连接的逻辑顺次产生C代码。模块有前后台分别，前台的一个模块可能对应后台N个模块，利用Composite模式，在后台将这些模块连接起来，然后通过转化成基类对象的方法遍历，从而产生代码。这是我已经完成的部分。
  现在我已经有如下模块：
  树模块：可以建立一棵代码树，提供插入，删除，修改的方法，能够动态的在书中插入，删除，修改结点，提供遍历方法，能够遍历结点，得到代码。
  后台结点模块：一些从统一的基类继承而来的类。利用树模块的方法可以将这些结点模块插入树中，从而建立一棵代码树。利用树模块中的方法遍历结点，即可得到代码。
  前台表现模块：表现模块也是一些从同一的基类继承而来，属于自定义控件。目的是为了从结点模块中得到一些参数，从而在前台页面显示。
   
  现在的问题是这样的。以上我的所有描述都要实现自动化。在前台操纵表现模块，要求能够在后台动态的处理树，按我的思路是打算写一个自动机，但是具体的操作定义我还没有搞清楚。我不知道是否我把这个流程搞复杂了，但是我感觉大体上的方向可能还是对的。如果有人没有明白我想做的是什么，可以了解下NXT—G，大概就是类似的东西。

  以下是我的问题：
   
  设计是否有误？
  是否需要自动机？有无替代解决方案？
  如果需要自动机，能否给一个大致的思路？这个自动机需要哪些部分？如何和前台交互？输入和输出是什么？


  请高手解答，分不是问题

------解决方案--------------------
我对你的自动机设想感觉不太乐观。原因：

功能模块可以说没有一个是标准的，设计没有准确的标准，验收也没有准确的标准。
用户需求无时不在变，业务需求完全一致的两家用户不可能存在。

试图统过一些模块组合形成一套系统，适用所有（或许多）用户也是不现实的。

自动机的整套模型是什么？定不下来。 你的描述更象是特定模块的是代码生成器。


------解决方案--------------------
WEB中
实现页面自定义化，就是要activex控件生成模板
通过数据库等绑定数据到页面
WINFORM也可定义控件
------解决方案--------------------
图形化的设计器倒是容易，难的是工作流的引擎。
我觉个输出来的应该仅仅是工作流定义(XML)，其它的执行什么的都交给引擎。

------解决方案--------------------
看了半天，还是代码生成器。 而且这个东西也并不是树，而是图（虽然图可以用树来表示，但还不能算单纯的树）

实际上这块内容微软已经做了WF引擎就是，不过wf也只是流程代码生成，业务逻辑和界面这块，自己挂委托和事件也可以

如果看不来wf的实现，请下vs sdk，里面有两块内容，一块是DSL Tools(图形自定义领域语言开发工具)，另一块是T4引擎（基于文本dsl的引擎工具，用于生成文件代码）
------解决方案--------------------
你最好抛弃微软WF的方式，你用用户定义“图”的方式来表达一种逻辑处理过程就不要把图编译成程序集，而是根据“图”的过程来运行“图”。

WF3.0中，将流程图编译成程序集是很糟糕的，当“图”变化的时候，你新的程序集就无法适应老的数据，虽然是有解决办法的，但是，你还会遇到各种各样的问题。同时，保留多个编译后程序集的还不如保留多个实例的“图”，实例应该是可以自描述的，既然是自描述的，为什么又要用各种不同版本的程序集来运行它呢？！

WF的这个技巧，看起来很美，实际上非常的不合实际使用场景，属于没事找事类型的。
------解决方案--------------------

探讨

额，说的好复杂，我看了两遍才理解透。是这样的，我们的程序旨在通过“图”的方式来引导用户学习代码，因此图和代码必须都有，这是需求决定的。的确有各种各样的问题，我现在已经比较混乱了，现在比如说前台的两个节点是同一类型的，比如都是“开始函数”（即左括号“（”节点），到了后台识别就会乱了，我在想要不要加个识别机制引用:
你最好抛弃微软WF的方式，你用用户定义“图”的方式来表达一种逻辑处理过程就不要把图编译成程序集，而是根据“图”的过程来运行“图”。

WF3.0中，将流程图编译成程序集是很糟糕的，当“图”变化的时候，你新的程序集就无法适应老的数据，虽然是有解决办法的，但是，你还会遇到各种各样的问题。同时，保留多个编译后程序集的还不如保留多个实例的“图”，实例应该是可以自描述的，既然是自描述的，为什么又要用各种不同版本的程序集来运行它呢？！

WF的这个技巧，看起来很美，实际上非常的不合实际使用场景，属于没事找事类型的。

------解决方案--------------------
看上去挺漂亮，而实际上可以做出来的功能则非常低级。

------解决方案--------------------
而实际上可以做出来的功能则非常低级 --> 而实际上可能做出来的功能则非常低级

这类软件都有这个通病，而且非常容易看出来。看看它的设计，由用户真正在意那些低级的编程语句用什么方式产生了吗？
------解决方案--------------------
你们有没有计划投资几个亿而只是为了模仿vs？如果是，就做吧。如果不是，就不要轻易简单地靠口号就行动，而要在概要设计时把细节做到位然后再行动。
------解决方案--------------------
路过
------解决方案--------------------
我看你现在是没有啥方向，我建议lz

先去www.ucml.com.cn看看，这是一个国内快速开发框架，马马虎虎能用

也可去http://visualstudiogallery.msdn.microsoft.com/zh-ch/ 
看看，老外实际上也做了很多这样的尝试visualstudiogallery上有很多类似的东西
------解决方案--------------------
如果你的解析引擎已经做完，那么可以使用一些Diagram控件，把他们联系起来

我个人一般使用ilog Diagram for .NET 1.6，每个界面都预先设计成Diagram的一个图形单元，然后拖拽生成图形，并生成一个xml型的文本dsl，后台解析引擎负责解析运行该文本dsl成 特定的类即可
------解决方案--------------------