第一章绪论
1.1课题研究背景及发展现状
随着社会的发展，信息处理在现代社会中占据着不能替代的作用。例如，在不同地点存放的数据通过网络可以实现本地一样的操作和管理，操作起来不受地域限制，这就是最大的优越性。使用数据库管理系统将所有所要管辖的数据统一管理，从数据库层面显示的是一个单独的整体不是由若干子数据库的组合。基于对数据的存储和保护，对人们提出了更高的要求，所以我们必须保证实时的数据安全和移植保护措施。
近年来，随着软件工程的逐渐普及，开发者认识到必须使用良好血又适合的软件工程来解决网络应用系统的复杂度急剧增加、需求变化的速度在加快、开发效率和质量的要求不断提高等现实性问题。UML、测试驱动开发、业务逻辑模型等概念、技术和相关工具慢慢进入开发者的口常工作中。在Borland/inprise公司进入.Net的开发环境后，Bold团队开发了一个称为ECO(Enterprise Core Objects，中文含义是企业核心对象)的在.Net平台下实现的模型驱动架构/设计驱动架构，以帮助开发者从更高的抽象层次来开发.Net应用程序，提高生产效率。
分布式数据库
从概念上讲，分布式数据库(Distributed Database，简称DDB)给我们的表面上需求是一个整体看不出其有相关的差异，而对相应的内部实质却是由多个数据存储点构造而成。分布式数据库的研究始于20世纪70年代中期。20世纪80年代后，随着网络性能的提高，分布式数据库系统也得到了长足的发展。由于计算机硬件的成批生产，成本大大下降，以致很多家庭都可以购买了计算机，这样在各行企业中基本也都实现了计算机管理阶段，对于大型公司，地域不同，对于数据的处理需要分开处理;还有计算机网络硬件材料的更新和技术的提升，在数据传输上，不论是从速度上还是费用上都有着喜人的前景，特别是对小型机和局域网等的发展，为分布式数据库的发展提供了良好的孕育条件。到上个世纪末的时候，客户机/服务器(Client/Serve动结构出现。对于这种架构，就是服务端与客户端的直接通信，没有中间层的转化，速度特别快，直接进行传递。由于两层结构的模式本身固有的缺陷，使得它不能应用于一些大型的、结构复杂的系统中，由此出现了以二层结构为代表的分布式多层系统，它是在C/S结构基础上增加了处理业务逻辑的中间层。典型的数据库应用可分为表示部分、应用逻辑(或称商业逻辑)部分和数据访问部分。2001年前分布式结构使用的核心大致可分为两种工业标准，一种是MS的COM/DCOM及COM+，另一种是由700个厂商共同提倡的CORBA (Common Object Request Broker Architecture)。前一种是以Windows为中心，而后一种是平台中立的分布式技术，可执行于Windows,Unix,Linux等操作系统。2001年后，随着. NET的出现，MS提供了.NET Remoting技术，它继DCOM/COM+之后基于.NET平台的分布式应用技术框架，它使得分布在不同应用程序、不同过程和不同计算机上的对象可以实现无缝通信。.NET Remoting提供的编程模型和运行时支持功能强大而又易于使用，能够实现透明的交互。
1.2模型驱动架构
统一建模语言(UML)标准在建模方面的实际价值已经得到了业界的广泛认可，常常作为兀模型语言来设计模型。本世纪初的时候，在UML建模语言正在被广大应用者所接受的同时，对象管理组织(OMG)也发布了一种全新的软件开发框架一模型驱动架构(Model Driven Architecture, MDA。它的优越之处在于，在整个软件系统开发的过程中一切行为由模型来驱动，将系统中的功能和实现更细化的分开，在这里UML不仅仅像以前在设计需求中作为设计语言而出现，更多的是以开发编程语言来进行工作，更加严格的区分系统的功能规约与实现细节。
平台无关模型(PiM)与具体的实现技术没有关系，只是针对系统业务模型架构的进一步抽象;它将关注点放在业务问题上，抽象目_精确，更容易理解和验证;而平台相关模型(PSM)则是要看使用什么具体的技术来实现的，是跟平台相关。对于MDA的实现，先是根据业务确定到底要抽象出什么样的平台模型，然后按照一定的模型转换进行定制相应的规则
由于现在大型企业进行软件开发的时候逐渐的应用MDA架构模式，因为对于一个大型软件实施的是否成功，很大程度上不是决定的看程序员编写的代码质量如何，而是更多的看‘需求设计人员在业务逻辑的抽取上建模的档次如何。这样将平台抽取到更到的高度，至于使用什么技术来实现，就显得不是那么重要了，这样我们要做的更多功能是对整个系统业务的逻辑功能性。
在对软件具体的进行实现前更多的要做系统功能的需求分析于设计。随着计算机软件和硬件技术的高速发展给软件产品的开发也带来了强有力的拉动。现在基于MDA模型开发的软件产品比以往的软件有着更强的可移值性和用户、程序员等与计算机之间的互操作性，在口后的维护和管理方面都让人们期盼下一个美好前景的出现。
第三章 基于 ECO 的同花顺纸.......... 23-31
3.1 需求分析.......... 23-24
3.2 用例设计与系统.......... 24-25
3.3 企业逻辑模型 .......... 25-28
3.4 系统的开发环境.......... 28
3.5 ECO 分布式多层数据库.......... 28-31
3.5.1 建立 ECO 服务器.......... 28-30
3.5.2 建立客户端.......... 30-31
第四章 基于 ECO 的同花顺纸牌.......... 31-46
4.1 生成基本数据.......... 31-33
4.2 网络通信.......... 33-36
4.2.1 服务器模型 .......... 33-34
4.2.2 客户端程序模型.......... 34
4.2.3 组件.......... 34-35
4.2.4 应用程序.......... 35-36
4.3 玩家位置选择.......... 36-37
4.4 随机获得牌号.......... 37-39
4.5 发牌.......... 39-42
4.6 玩家纸牌组合.......... 42-46
第五章 系统测试.......... 46-56
5.1 单元测试.......... 46-51
5.1.1 白盒测试.......... 46-48
5.1.2 黑盒测试.......... 48-50
5.1.3 代码测试.......... 50-51
5.2 功能测试.......... 51
5.2.1 网络通信功能.......... 51
5.2.2 随机获得牌号.......... 51
5.2.3 发牌功能.......... 51
5.3 集成测试与系统.......... 51-52
5.4 压力测试.......... 52-56
总结
我们在建立相关的业务模型，开发ECO包(Package)和包的使用、数据库建模的实现和与物理存储的自动转化，EcoSpace，使用ECO开发数据库应用程序的架构和步骤、ECO实现多层数据库开发等等。ECOSpace的另外一个主要的功能是对企业中业务逻辑模型的简历，在应用程序正在执行的时候，ECO对象都存活十ECOSpace中，一切进行需要的服务都有ECO框架提供所支持，对十企业所需要的逻辑业务模型也都包含其内的支持。设计期所有的模型信息我们看做成是兀数据，保存成XML文件，如果数据库中表和数据一样物理的存在。这些东西在程序真正运行起来的时候，可以理解成UML模型在流程活动图中的另一种形式的表达。在对系统中的业务兀素进行建模表示的同时，又要留出一定的空间来对对象的存储。这样的工作人员更多的是对业务逻辑的注重，不需要把更多的时间放到代码的编写。
根据纸牌游戏的特点，应用ECO技术对同花顺网络纸牌游戏进行了分析设计。建立了该系统的多层体系结构开发模式，实现了桌、玩家与纸牌间的业务逻辑模型，根据业务逻辑模型完成了对纸牌数据和人员信息的存储和处理，实现客户程序信息的同步显示，玩家随机获得纸牌、系统发牌、计算胜负结果等功能。