TAO[一] .NET项目开发最佳实践

　　分析、设计、开发、测试及文档化，如果这些可以在同一个开发环境，同步完成，那将会是什么样的项目体验？
　　本文（以及后续的一系列文章，将会给你一个答案与一个完整的实践案例。
　　如果你对于MDD（即模型驱动开发）、TDD（测试驱动开发）等一些概念，还停留在理论上，那么，本系列文章同样可以带你一起来领略，在实际的项目执行过程中，MDD与TDD

是如果被实现的。
　　目前本系列文档我已经完成其英文版初稿，用于公司内部交流，以向公司其它项目组推广此模型。而中文版的工作正在整理中，将根据整理情况，逐步推出，敬请关注。
　　欢迎你与我就本系列文章及本Blog中的其它文章与我交流。同时，如果你希望你在你的工作中引入本系列文章中所涉及到的模型或是经验，也欢迎与我取得联系。
　　MSN: sunht@dopsun.com；QQ:6006839。

　　（一）TAO: Tao All-in-One Model
　　在本系列文章中，重点是讲述了一个我称之为 All-in-One 的模型（以下简称为TAO模型）。其核心就是"分析、设计、开发、测试及文档化在同一开发环境中同步完成"。
　　在TAO模型中，集合了MDD及TDD的优点，并且引入了文档化的方法，从而实现这一目标。
　　本系列文章不打算展开讲述何为MDD及何为TDD，关于这方面的内容，请参见相关技术文档。而在本系列文档中，则重点讲述在实际项目的过程中，如何综合各种工具，使得MDD

及TDD，以至TAO模型得以有效工作。
　　本系列文章中所谈及的内容，都经过实际项目的验证。项目实际执行中，遵循CMM3级标准。实际经验表明，在实际的项目执行过程中，TAO模型有效的解决了原有开发模式中的

很多问题。
　　1.1 各步工作验证难
　　在传统的工作模型中，分析完成之后，出需求文档，设计完成之后，出设计文档，开发完成之后，出代码，等等。所有这些都是普通的文档，它们之间的联系完全通过人的手

工完成。从而造成工作量大，在实际项目执行过程中，往往因为人为的原因，造成互相验证困难。常见的问题包括，在项目后期，修正了前期设计中的一些问题，但是懒得去更新

设计文档等等。
　　模型驱动开发有效地控制了这个问题。在后面的实际案例中，我将会介绍在TAO模型中，分析、设计、开发、测试以及文档化是同步完成的，所以，它们不存在脱节或是不一致

的问题。听起来很玄，具体怎么做，后面会有详细的文档说明。
　　1.2 文档与实际工作脱节
　　文档是一件枯燥而不具有创造性的事。我们都知道，在做分析和开发的时候，我们认为其是创造过程，而文档化只是一个整理过程。所以，在项目执行过程中，往往会被不受

重视。常见的情况是，在项目执行最后，大量的补文档，以至于文档与实际工作其实不一致。拿着代码文档看代码的时候，不一致是常有的事。
　　而在TAO模型中，不存在这样的问题。各步骤是始终同步的，当有任何一处更新之后，文档化是自动完成的。
　　1.3 测试工作得不到有效的重视
　　与文档类似，测试也是一件相对乏味的事。而且对于测试效果的考核本身也比较困难。在国内业界，真正将测试工作做到位的项目比较少。原因是多方面的。其中一些主要原

因是，当开发完成的时候，程序"似乎可用"，这时，老板一般会知道这样的情况，然后，老板会根据这个情况，调整项目的发布期，以至于即使前期有很好的测试计划，在后期也

无法执行了。
　　而在TAO模型中，测试与开发是同步完成的。也就是说，当开发完成的时候，测试同步完成了。
　　1.4 需求及其它变更很难跟踪
　　变更是一个永恒的话题。在项目的任何时刻，都可能发生变化。需求、设计、代码、测试案例等等，都可能发生变化，而这些变化最终都需要反映到文档上。如果管理这些变

化，是一个非常麻烦的过程。
　　而在TAO模型中，一切都是一个动态同步过程。在任何时间点，都可实现同步。也就是说，当需求发生变化的时候，后面所有无素跟着发生变化，然后，同时实现同步。
　　
　　说到这里，或许你会觉得这个TAO模型看起来很美？实际执行能够达到么？这就是后面一系列文档中将会包括的内容。在本系列文档中，一个完整的示例将会一步步给出，当这

些步骤完成之后，你会看到整个过程的全部。

　　（二）工具支持
　　一个好的概念，当然需要一些好的工具的支撑。TAO模型也不例外。不过，在这个模型所使用的工具中，都是业界比较成熟的工具。
　　2.1 Visual Studio .NET
　　Visual Studio .NET是.NET平台上最好的开发工具，而且就其设计而言，也是业界最好的开发平台之一。它的可扩展性与开发性非常好。与之相应的，其相应的文档也是非常

全面。MSDN for VS.NET就是一个很好的选择。独立的MSDN版本或许会更好一些。当然，要想获得最新的更新，在线的MSDN也是一个不错的文档来源。
　　在本系列文档中，使用VS.NET 2003, Enterprise Version, English version.
　　
　　2.2 Rational XDE for .NET
　　Rational 公司在我的心目中是一个伟大的公司。我工作这些年来，对于软件开发方法与项目管理的思考的每一步，都会从它身上吸取一些知识及经验。Rational Rose是我们

熟悉的一个建模工具。而在本系列文档中，我们使用Rational XDE for .NET来实现模型驱动开发。
　　这方面，还有其它几个产品值得介绍一下：Borland Together，也是一个不错的产品。微软公司也已经宣布了类似产品的计划，其项目计划名称为Whitehorse。有兴趣的朋友

可以关注一下。
　　在本系列文档中，使用Rational XDE for .NET 2002作为基础。

　　2.3 NDoc
　　NDoc是一个开源工具，同时也是我见过的在相关领域最成熟的工具之一。事实上，在我认识这个工具之前，我曾经做了一个类似的工作，名为AutoSpec。它是专为TAO模型的文

档自动化设计的。但是，当我看到这个工具之后，我就放弃了我的想法。因为这正是我想要的。
　　在本系列文档中，使用NDoc v1.3. 你可以在http://ndoc.sourceforge.net找到相关的资料。

　　2.4 NUnit
　　与NDoc一样，它也是一个开源工具。事实上，我见过一些商业工具是以它为基础进行二次开发的。这是一个非常好的单元测试工具。
　　在本系列文档中，使用NUnit 2.3。你可以在http://www.nunit.org找到相关资料。

　　（三）背景知识
　　本系列文档，假设你拥有以下方面的一些背景知识。虽然这些背景知识不是必需，但是，如果你拥有这些背景知识，对于理解本文档，还是会有更大的帮助。
　　.NET平台及C#语言：这是本书中完全的案例所使用的平台与语言。
　　UML：它是一个标准化的建模语言。
　　MDD：可以在网上搜索一些关于这方面的文章。目前这方面的文章太多了，所以，在本系列文档中，侧重于如何将这些概念引入实际的项目，而不是理论本身。
　　TDD：同样你可以看到很多关于这方面的评论。本文同样不会展开这方面的理论讨论，而只关注于其应用。

　　（四）案例背景
　　本系列文档中的案例是一个完整而简单的项目。之所以简单，是希望将本系列文档关注于TAO模型本身。而完整则是希望读者你通过本系列文档之后，能够对于TAO模型整体有

一个清晰的认识，从而能够将其引用到你的项目中去。
　　案例中的项目名为EventLog。在某个软件公司的软件产品中，有很多软件模型都支持审核功能，即将用户所做的操作记录到数据库中。而由于各个模块在最初的设计的时候，

并没有考虑到这是通用的需求，以至于各个模块都自己做了一套这样的东西。现在公司希望构建一个组件，来实现这个功能。这就是EventLog组件。
　　EventLog组件要求支持记录：什么人，在什么时候，通过什么应用程序，做了什么样的操作，操作的结果如何。该组件本身不需要有任何界面，这些写进去的日志由另外一个

应用程序（UI程序）通过界面查阅。这有点类似于操作系统中的EventLog。
　　项目的初步需求就是这样的。在后面的文章中，将会从分析开始，通过这个案例，向你展开一个完整的TAO模型，直至完全实现该组件。