阿凡达架构平台（Avatar Architecture Platform）（一） 收藏 此文于2010-01-26被推荐到CSDN首页 就像Avatar中场景，没有地图，没有沙盘，大家都在全息3D的投影下讨论，非常直观，更为重要的，这是可以交互的，你可以点击3D影像中的任何部位，进行信息的检索。
未来的软件架构和设计以及开发会变成怎样？ 大家应当都在同一套系统下工作，参与软件开发的所有人员，都使用同一套系统，只是他们所用的工具可能不大一样，他们完成或使用的是同一个产品的不同部位，或者是同一个产品的不同视图。做产品就像4*100米的接力赛，参与产品的人跑完一段就可以了，但是产品—接力棒，被一棒一棒的传递下去直到终点。从产品第一个设计被创建的那一刻起，软件就能够运行起来，所见即所得，所有人都可以投入工作，开发工程师和测试工程师从项目第一天起就开始工作了；老板和用户从项目的第一天起就知道产品的状态，是如何进展的。研发产品大概只需要两类角色就可以了，一类是架构师（兼任需求、架构、设计），一类是编码人员，甚至后者都可以外包；没有测试吗？不需要测试，系统会确保你100%正确；文档呢，或许需要一名，把文档内容添加到系统中，系统会自动发布为在线帮助。设计好的模型和手工的函数，将被打包在一起，可以在任何地方运行。 阿凡达的主角在现实世界中腿断了，而借助Avatar重新站立起来了，同时也拥有敏捷的身手，与潘多拉星球万物沟通的能力。架构也一样，需要有一个平台来延伸、拓展自己的思维，不被现实的工具所束缚，所以，我理想之中的这套系统就命名为：Avatar Architecture Platform。 不知道是否有时间把这个平台的想法写完全，先写个头吧。
阿凡达架构平台（Avatar Architecture Platform）（二） 收藏 ========================================================================== 开发流程 先回想一下传统的产品/项目开发的基本开发流程： 1） 现场调研->需求规格说明书（包括文字、图表、用例等）； 2） 架构设计->架构设计文档（架构图、类图、数据结构、部署图、UI设计等）； 3） 开发各模块； 4） 单元测试、集成测试、性能测试； 5） 文档、培训、实施。
使用Avatar平台，开发流程又是如何呢？ 1） 现场调研，把用户流程草稿画出来，把用户单据界面画出来，把用户的报表画出来，甚至可以选择用户喜欢的布局、操作方式和界面样式，并当场演示给用户看，直到其满意为止----产品原型阶段。 2） 在原型基础上添加中间层的模型、业务规则、权限规则，调试运行----产品实现阶段。 3） 根据企业的规模、组织架构、软硬件资源、接入终端选择部署方案，另外负责文档、培训以及试运行----产品实施阶段。
如果明确了需求，以上各阶段并无严格的顺序，可以按照想要的组合来进行。也就是说，可以先设计外观，再实现细节；也可以先把细节逻辑实现了，再调整外观；甚至，你可以先实施让用户用一部分，再去设计和开发其他部分。而且，产品实施后用过一段时间，也是可以按照要求来调整的，比如增加功能，比如修改功能等，都非常方便。
团队定义 
这里的团队是使用Avatar平台进行产品开发的团队。逻辑上只需要三类角色，一类是架构师，负责项目管理、需求、设计类的工作；一类是开发工程师，负责函数、组件、规则的设置和编写；一类是实施工程师，负责测试、文档、部署、培训之类的工作。按照这样的定义，架构师应该具有比较广的知识面，比较丰富的经验，比如项目管理，需求分析，架构设计都应该懂一点，是团队的“主治医生”；开发工程师只需要编码熟练就可以了，相当于“主治医生的助理”；而实施工程师，做善后的工作，则相当于“护士”。 实际上，团队从1人到多人都是可以的，只不过1人什么都做就是了，人多可以分工一下，如果按照1：1：1的比例可能比较合适，编码的工作相比较传统开发来说，应该是大大减少，复杂的业务规则才需要编码，因此开发工程师不需要太多。另外，他们之间的工作不需要有非常严格的区分的，可以根据实际情况来调整，但是无论怎样的分工，他们的工作都将直接作用于产品----严格杜绝中间不必须要的过程和产品，这也是Avatar平台的基本理念。
阿凡达架构平台（Avatar Architecture Platform）（三） 收藏 ============================================================================= 设计器（Designer） 设计器提供流程、表单界面、对象界面、报表界面的设计，以及提供编码的简单IDE（可在现成的IDE如Eclipse上做插件）。 设计器将分为两个模式，一个是原形模式，另一个是架构模式，原形模式下功能简化、少量校验，方便快速搭建原形；架构模式下，包含全部功能，校验较多，如Error、Warning等，用于实现产品功能。两种模下设计的是同一种内容。 设计器提供版本控制的功能，类似SVN/CVS，以支持团队协作架构。 设计器提供模板功能，可以把设计好的内容存为模板，模板可以参数化，方便批量设计类似的模型。 设计中的各种控件（比如流程的活动，表单的文本框等）也可以组合为新的控件，存为自定义控件，方便重复使用控件。 设计有调试模拟运行功能，可以在设计好之后马上运行演示、测试。
元数据(Meta) 元数据是用来描述流程、界面、模型、组件、部署等。元数据可以理解为一种规范、一种协议，是连接设计器和真实世界的桥梁。元数据比如工作流可以遵循BPMN的规范，可以根据需要扩展规范，遵循规范的好处是不用重新设计，而不是其他。界面的规范好像也有不少，选择规范可以用别的设计器工具来设计再导入。其他的对象设计（类图）可以裁减UML2.0，但是最好能包含数据库的设计（参考Enterprise Architecture）。 因为从外观上看到的、设计好的内容，都需要通过元数据映射到物理代码。
世界创建器（World Generator） 元数据如何映射的问题上，存在两种观点。一种是虚拟机（解释器）+元数据模式；另外一种是元数据编译成代码的模式。我以前倾向于前一种模式；现在我倾向于后一种。主要原因：代码的性能高、解释器模式实现复杂。 根据元数据，创建目标环境代码，c/java/c#/python等都应该支持。对于多种语言的支持，可以提供不同语言版本的平台库，或者一个语言版本库（c的比较容易封装成java/c#/python）封装成不同的语言的版本。 元数据编译成代码的模式存在两个问题，一个问题是平台本身的升级会影响到生成的代码；另外一个问题是手工的脚本（代码）如何同步模型。第一个问题，可以采取事件机制，提供各种操作的接口，保证接口的稳定。第二个问题，要么只有正向的过程，每次都是在设计器中写好脚本，生成的代码不允许修改；要么只允许在固定的接口中写代码，能反向回去。初级用户用只正向的方式，高级用户能使用反向功能。 自动文档也很有用，可以在设计器中写备注，最后生成使用指南文档。 自动化测试可以仿照Load Runner的脚本录制，记录测试者的点击轨迹，自动生成自动测试脚本，后台的数据也可以自动生成。
部署工具(Deployment Tool) 分布式部署流程、模块、对象，以及管理数据库。维护所有流程、模块、组件、数据的通信方式以及地址。比如采购模块放在虚机1上，库存模块放在虚机2，采购后入库这个流程通过消息管道连接这两个虚机上的模块。既可以按照业务来划分，比如财务、CRM、进销存分开；也可以按照横向的比如业务单据处理、查询报表、流程运行分开；还可以把后台数据大表拆分成多个子表。 部署工具另外一个功能是管理监控服务器的资源，程序的运行情况，如果有资源异常需要调整部署。
消息管道(Message Piple) 提供流程活动间、异构系统间、各模块间的通信，提供长事务。现在流行SOA、SaaS、云计算等概念，分布式部署必不可少，在分布式组件间如何通信就是一个问题。因此，需要具有一个消息通道。异步消息，可以提升系统的可扩展性、伸缩性以及吞吐量。消息应该是点对点的，不需要一个总的控制点，因为总的控制点比较容易成为瓶颈。 消息管道可以采用类似ICE的机制，能够跨平台、多语言。 消息管道要保证数据一定会送到，因此要有故障恢复机制，可能需要消息的序列化；对于事务性的各种消息，要提供分布式事务的机制。 消息管道还有一个功能就是和各种异构系统的连接，如数据库、Http、Soap、Ftp、Socket……，甚至和Oracle、SAP等产品也可以对接。
各种可选部件(Choice Department) 组织架构（Organization Structure）：组织架构、岗位设置等 权限模型（Right Model）：RBAC（Role Base Access Control），功能权限和数据权限 国际化（Internationalization）：多语言、日期、时间、货币、数量等方式 时间表（Schedule）：定时器组件，可以定期执行一些任务，如后台程序、如发消息、短信、预警等 即时通信（IM）：局域网内的即时通信工具 终端适配器（Terminal Adapter）：Http、WAP、短信、IM工具、Mail ====================================================================================
本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/marising/archive/2010/02/03/5286747.aspx (责任编辑：admin) |
