MAX Family 概述 (或者草稿？)

?? MAX Family全名是基于模型的可扩展应用系列Model-based Application eXtensible Family，是一种MDA的开发方法。MDA（模型驱动应用Modeling Driven Application）是一种革命性的软件设计方法，其本质特征是通过使用动态的对象模型来建立一个新的信息系统。在MAX中，主要体现了两个思想：一是在生成某公司的特定模型时，充分利用最好的实例知识和实践经验，表现在企业参考模型的使用；二是在动态公司中，公司的信息系统能够适应公司环境等的快速变化，表现在MDA工具——MAX Builder的使用。

1?MDA的三个主要优点：
??速度快
　　体现在简短、紧凑的企业建模工具的使用，通过使用预定义业务模板来减小该过程的难度。
??柔性高
MDA的软件结构可以随着企业业务过程的变化而相应改变，而无需更改代码。
??质量好
MDA提高了企业建模的质量，因为它使用了一种简单的方式使其中很复杂的功能可视化。同时避免了直接书写代码而产生Bugs。

2?MAX的四个主要组成部分：
??建模工具MAX Builder
它可以用图形描述业务模型的组织结构、功能特点以及业务过程的先后顺序。
??企业应用模板MAX Progeny
这些模板为各个行业领域内的企业，或者不同的企业应用系统(PDM, CRM, HIS…)，提供了建立本企业模型的参考。这些系统都是由MAX Builder构建的衍生物。
??企业级报表 MAX Report
基于企业应用的柔性报表系统。提供强大、灵活的报表定义工具，以及高效和丰富的报表生成系统。
??企业模型管理工具MAX Configuration
系统管理以及工作流定义与实现。

2.1?建模工具MAX Builder
这一部分是MAX Family与一般企业应用系统的区别所在。一般的企业应用软件都是通过用户定义字段、用户界面个性化等方法来达到客户化的效果。但是，这种自定义的方法不能从根本上来定义一个柔性的系统，只是在现有软件的基础上进行小修小改。当用户的需求与已有的软件差别比较大的时候，还是要通过编写代码来实现业务逻辑。然而，在MAX Builder中，我们采用一系列的可视化工具来让用户“为所欲为”，不仅能自定义字段，还有方法，以及对象和对象间的关系。然后，根据用户定义的类模型来生成软件的界面和数据库结构。生成的用户界面UI还可以被用户按个人喜好进行更改，比如布局，语言等等。
类模型，数据模型和用户界面的定义分别保存为xml文件。类模型和数据模型格式可以参考MS ObjectSpaces中的映射文件格式；UI定义个是可以参考MS XAML的格式（XAML是用在下一个Windows版本中的界面定义语言）。

2.1.1?类模型定义工具
这个工具类似于Rational Rose或者Visio的静态类图定义工具。用户在这个可视化工具里定义各个业务对象的属性、方法、事件，以及各个对象之间的关系。最终的界面应该类似下图：

?
在这个可视化环境中，开发者可以定义类的属性/方法以及它们的类型(Public, Private)，定义类之间的关系(Inherited, Association, Aggregation, Composition)。建模的方法可以借鉴Rational Rose Logic View或者Visio的类图定义方法。应该至少支持Package视图，如果可能，还应该支持类层次图（能清晰地反映类的继承关系）。根据目前的发展方向，确定为仅支持单继承。
对于类的方法和事件，提供脚本编辑器。脚本拟采用VB.NET和C#.NET。这样脚本直接由.NET CLR支持，比较容易实现；而且是编译后执行（不同于解释执行的脚本），执行速度上将有优势。

2.1.2?数据库结构生成
根据类图定义，MAX Builder可以自动产生数据库结构，以及数据表之间的关系。比如，每个类作为一个表，类的属性作为表的一个字段，Object属性作为表的外键连接。
同时，也提供方法让用户来制定数据映射。比如，对于只读的Class，可以映射到View。或者映射到其他的应用系统数据库的一个或多个表中。
这个部分的难点在于如何做到高效而且与数据库平台无关的数据库结构。

2.1.3?用户界面定义
根据用户的类模型定义，系统会生成默认的用户界面。默认的用户界面更具以下原则生成：
??所有的Public属性都对应着可见的控件（比如，String 属性对应TextBox, Boolean 属性对应Checkbox, Object 属性对应Listview，等等）。对于<><>方法，作为属性处理（仅有<>就是只读，仅有<>就是只写）。
生成的界面应该支持多种控件属性。比如，对String类型的属性，应该能让用户指明是否能为空，默认值，是否能重复，最大字符数，是否可编辑等等。
控件按照某种默认的顺序排列（用户定义时的顺序，或者字母顺序？）
??一般的Public方法，对应于该对象窗口上的工具栏按钮和菜单
用户能指定这些方法的顺序和图标，以及快捷键等信息。如果可能，是否可以让用户指定可用/不可用的条件。当工具栏按钮或者菜单被单击时，执行方法脚本。
??事件没有界面，由系统触发调用事件脚本
事件应该包括对象事件和属性事件。
默认的用户界面应该是可以被灵活的修改的。比如，窗口的大小，数据类型（单记录窗口还是多记录窗口），控件的位置，字体，颜色，控件类型（列表框还是弹出按钮？）等等。
下面是一个实例，一个由Customer类自动产生的窗口界面，其中可以看到使用属性窗对CustomerID这个属性进行定义的界面：
?

?

单记录视图

多记录视图

另外，用户在MAX Progeny（由Builder产生的应用系统）中，部分外观也可以进行调整，并且保持在客户端，这样可以实现界面个性化。
可以从上面的图看出，用户通过对类的属性所对应的界面元素进行设置，取得灵活的外观效果。这个界面生成器（也可以叫做UI Factory），可以根据用户的定义，产生相应的UI元素，那么，是否可以产生Web元素从而产生整个Web应用系统呢？我认为可以实现，但是否值得？对于下一个Windows版本（Longhorn，2006年发布），其实B/S模式和C/S模式已经完全混合了，C/S的应用也是无需客户端安装，使用时才从服务器上下载。

2.1.4?代码的生成与编译
定义好了类模型，数据模型和UI后，根据这些定义产生.NET平台的代码，然后编译成.NET IL（中间语言） DLL。代码不是可持久的，只在编译时存在于内存中，生成的DLL存放于服务器上。

2.2?企业应用模板 MAX Progeny
其实，每个不同的行业，或者不同的应用都有其自身的特点。因此，一个完全“通用”的系统是不存在的。即使利用像MAX Builder这样灵活的建模工具，也有很难实现的地方。比如，PDM系统中的文档管理功能，用户会经常上传/下载文件，以及Check in/Check out文件。这些文件操作要求是高性能的，而且和系统的其他模块结合很紧密。如果完全通过建模和脚本来实现这些对象和功能，无疑是困难的。这时候，我们就可以使用“企业应用模板”来解决这个问题了。
我们可以建立一个“PDM应用模板”，在这个模板里，我们事先建立一个内部类“MAXFileControl”，那么，只要和这个FileControl类建立了关联的其他对象，如图档类，文档类，都具有了上传/下载文件，以及Check in/Check out文件的功能。这样，对于这些共同的而且核心的功能，我们都可以通过采用“内部类”来解决问题。
应用模板的另一个功能是，对于用户（开发者）来说，它可能并不清楚一个企业应用具体是什么样的。PDM应该有哪些模块和功能？HIS又该如何架构和构建？如果我们提供的标准应用模板，用户就可以在我们模板的基础上进行开发，而不是从一个空白的模型开始。这里，体现了我们对企业应用的理解，也是系统增值的一部分内容。
这里有一个架构的问题，这些“内部类”如何和我们定义的模型关联，“内部类”的功能如何和整个系统关联，需要进一步的研究，现在暂定为使用.NET自定义属性(Attribute)的方法实现。

2.3?企业模型管理工具MAX Configuration
这一部分是企业应用系统的外围部分，但也是十分重要的。包括的内容有：

2.3.1?系统工具
包括日志管理，用户管理，权限管理，存储管理等各个系统都通用的部分。

2.3.2?工作流定义工具
简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。通过这个可视化的工具，用户定义工作流程，并且映射到模型的类上去。这样，对于类的实例，就可以走一个预定义的流程。工作流的模型可以参考WfMC的标准。
这个工具的开发是一个难点。可能类似下面的界面：
?

2.4?报表设计与输出工具 MAX Report
这也是一个关键的部分。报表的设计应该简单，但同时也能支持复杂的报表设计。报表的输出可以采用第三方的工具（比如Crystal Report, VS Report等），但需要和我们的系统紧密地联结起来，让用户既灵活，又方便的设计和输出报表。这个工具应该屏蔽数据库，用户只会看到模型中的类。
这部分的工作主要是架构问题，由于以前有类似的架构经验，我认为这部分可能会是MAX Family的强项。