当前位置：编程学习 > XML/UML >>
答案： 建模和软件设计又将迎来新一波的高峰。UML和模型驱动架构MDA目前在业界越发引人注目，清晰地进行前置设计（design up front，译者注：这是过去批判得比较多的，是瀑布开发中的思想，在迭代开发中批判较多）也吸引了更多的兴趣。
建模的各种热闹气氛似乎在.NET这边还没有太大影响。和其它程序员一样，.NET开发者想得最多的就是编码。但建模的改进同样发生.NET领域，正如在java领域发生的一样。
软件应用的建模提供了一个辅助保证应用是否和用户需求相吻合的蓝图（blueprint）。在.NET软件开发方面投资的公司当然不愿意看到以下的场景发生：因为最初设计和架构的不合理，每隔几年就要把应用重写一遍。
最近的一些工具上的改进如Borland的Together Control Center和IBM的Rose XDE Developer都在帮助保证底层的代码和UML模型的同步。这些努力使得人们接纳UML，也使得建模事业得以稳步发展。
当然，.NET的复杂性导致了很多建模的挑战。对那些熟悉OO技术的人而言，为.NET建模还不是太困难。但并不是所有的开发人员都熟悉面向对象的，而且，也不是每个人都是设计可重用构件方面的专家。
事实上微软也发现为即将推出的Visual Studio .NET版本提供自己的建模产品是如此重要。这个软件巨人的加入意味着这个领域将变得更加有趣，竞争也更加激烈。
什么驱动模型？
现在而言，对象装配（object assembly）还是需要的。例如，微软新推出的Visual Basic .NET和旧版的Visual Basic是不兼容的，新的Visual Basic .NET要求开发人员要掌握一些新的面向对象的概念。
早在几年前，微软就在Visual Studio box中提供了一个基本的Rational Rose建模工具。并且在购买Visio几年前就在其工具中加入了Visio的一些特性。微软还曾经几次和第三方联合创建有用的开发者仓库。
但遗憾的是，在进入面向对象设计领域时，微软开发者竟然没有一个合适的工具，这不能不说是一个缺陷。现在情况可能会有所改善了，微软正在着手开发代号为“白马（Whitehorse）”的设计工具集。不过，越来越多的迹象显示，微软在进入建模领域的时候似乎并没有采纳UML或者MDA的标准。
模式和实践
为了帮助开发人员可视化OO的概念，为复杂的.NET应用建模。许多工具提供商，包括IBM Rational、Borland、Telelogic、Interactive Objects Software GmbH、 Computer Associates、Compuware、Embarcadero、微软及其它一些公司，要么为Visual Studio .NET开发环境专门推出新的建模工具，要么改进已有的工具。
Pittsburgh-based LogicLibrary公司的创办人之一以及分管技术的副总裁Brent Carlson认为，建模可以由不同层次中的任意多层来驱动，“例如，今天的业务过程建模，在图形环境中它对应为很多的过程工作流，将其转换为需求，这个转换过程并没有必要通过工具实现，但人工实现是需要的”。
“我希望这个情况会得到改变，当然，这需要时间。通常说来，在.NET开发者考虑应用架构之前，很多工作都已经完成了，例如架构模型、.NET组件架构以及微软已经开发的各种模式和实践。”
为此，LogicLibrary和微软建立了伙伴关系，力图使得知识内容更加“可消费（consumable）”。这些都围绕为开发和部署架构定义的模式和实践展开，而且很多都是使用UML、模型驱动的。LogicLibrary管理这些内容并将它们提供给Visual Studio .NET的用户。
微软已经创建了各种参考应用，这些应用不仅包括.NET框架，还包括各种应用模块，它们是设计来解决各种特定问题的基于.NET框架的扩展。这些应用模块都是可以直接使用或者由企业进行扩展的预定义的各种代码段。这些解决方案就象是“包装好的最佳实践（best practices in a box）”。
LogicLibrary过去和微软一起致力于以一种基于模型的形式表示这些参考应用。LogicLibrary的Logidex for .NET产品强调的是Carlson所提的“信息宝藏（the glut of information issue）”，帮助企业更好地组织已有的应用，并和微软发布的参考应用放在一起，发挥作用。
“现在经常发生的情况是，你会发现信息太多而无处下手，” Carlson说，“但是，当一个开发者要开发一个.NET的应用,当他进入Visual Studio后，会看见如何进行数据存储，或者如何进行例外处理、如何在业务层做缓冲以提高性能的例子。这就好像有一个非常好的团队在帮助他，他会有一个飞跃，更快地构建出他的应用。”
IBM继续其.NET策略
Rational软件公司是OMG的UML标准的早期开发者之一，如今它是IBM的一部分。在收购了Rational之后，IBM在其portfolio开发平台的基础上有了一个完整的开发平台，并且包含了对.NET的支持。
IBM历史上一直偏向Java，而不是.NET。IBM 进入开发工具领域的时候就是倚重为其WebSphere中间件服务器等中间件技术服务的工具，显然，WebSphere是对基于Java的开发环境的补充。
Rational早在1999年就与IBM合作开发其Eclipse开发工具。也曾经和微软紧密合作开发for. NET的可视化建模工具。在IBM收购Rational之后，关于Rational是否继续支持微软技术遭到了怀疑，关于这一点，IBM和Rational都声明和微软的关系将不会改变，对微软技术的支持将一如既往。
实际上,IBM Rational提供了for .NET的覆盖面很广的全周期开发平台。其语言无关性保证它们对Java和其它的软件开发都是适用的。
“我们的目标是保证开发软件的我们的用户的成功，” IBM Rational的市场管理总监Roger Oberg如是说，“很显然，用户们对组件技术的选择是多样的。既有使用.NET的项目，同时也有使用Java和其它嵌入式技术的项目，这取决于企业的具体情况。”
Oberg补充说，从某种程度上说，今天的Visual Basic的开发人员明天可能会转向Java。“对软件组织而言，学习UML，并从具体底层的组件技术中抽象出来是一个非常有效的策略，这样做的话，今天为一个.NET项目工作的人员可能明天就可以承担一个Java项目，我们的工具可以应用于这两种不同的组件技术，因此你学习的是如何去建模，UML是可以应用到Java和.NET技术上的。”
IBM Rational的Rose XDE Developer包括了Eclipse IDE，既可以在微软 Visual Studio .NET中运行，也可以在IBM WebSphere Studio中运行。“在一个环境中建模的成果可以重用到其它环境中；显然，我们还没有实现足够高的抽象，还没有将用户与底层的组件技术分开，如果达到那一步的话，用户甚至不需要知道底层技术是用的什么”。
白板，白马（Whitehorse）
自从公司老板Bill Gates宣布之后，微软就开始更新其建模工具，开发现在已经是众人皆知的“Whitehorse”软件。它是面向“为操作设计（design for operations）”的，允许用户在开发过程的早期定义底层的需求逻辑，并进行验证。
微软开发部产品管理负责人，Prashant Sridharan认为， “目前的情况是，在底层架构和架构小组之间几乎没有交流”。而在Whitehorse中，业务底层架构的设计师和服务的设计师是共同工作的。“秘密在于他们如何协作”，Whitehorse将改进不同的软件团队之间的沟通，他认为Whitehorse将和微软Visual Studio .NET的下一版本Whidbey一同推出，发行日期预计是2004年末。
ADT向Sridharan询问Whitehorse对UML建模的支持。回答是，软件内部没有对UML建模的支持，但可以通过插件的形式提供。
“UML只是很多不同的建模环境中的一种。在Whitehorse中采取的方法就稍有差异。我们努力创建一个建模的平台。”，这个平台将包括一个建模引擎以及一个建模框架。他认为这个建模框架将是公共的（“在推出的时候”），而且公司已经和一些选定的第三方在这一点上进行合作。
Sridharan对此寄予厚望，“我们希望开拓建模的新时代，我们坚信模型驱动的开发—当然，我们也相信传统的代码编写。”
他指出，Whitehorse和一些微软的开发人员过去使用的Rose UML工具有所不同。“UML是面向OO的”，Visio同样可以支持传统的OO建模。但是，当面向服务的架构（SOA）成为主流的趋势，系统的分布性越来越强，反应时间和安全等因素必须纳入考虑之中时，OO不一定是最好的解决方案。
和UML的偏离会让一些人感到困惑（在微软早期的Rose插件中是支持UML的），“微软现在要走的道路不是基于各种标准的，”基于San Francisco的设计与建模Embarcadero技术公司的总裁Greg Keller认为，“他们对UML或者MDA并不感兴趣，他们的工具将是好的，有效的，但其中将不包含除XML之外的其它标准。”
合作伙伴们的这些信息是否是从Whitehorse得到的呢？IBM Rational的主管Mike Devlin的回答是“是”。“对于如何建模，微软有自己的看法。我们的看法和他们的看法的差别在于，我们的不是绑定在特定的平台上的。”
微软也在投身于建模事业，仅仅这个事实本身已经说明了很多。Grady Booch这么认为，他是UML的创始人之一，如今是IBM的一员。“他们的进入是非常振奋的一件事情。”他补充说，微软的行动证明了IBM和Rational从90年代中期以来的努力方向是正确的。
.NET本质
.NET环境使用了特有的一些技术来帮助用户创建Web-based以及传统的肥客户端应用。例如，在ADO.NET中的ADO.NET技术和Web service。IBM Rational的Rose XDE Developer建模工具中提供了一个用来在对ADO.NET以及web service应用建模的profile。
“最大的问题在于人们在不知情的情况下试图改变Web service的定义，最后的结果是中断了使用这些Web service的客户端。”IBM Rational的开发主管Kevin Murphey认为，“这里，建模的作用非常关键，它可以帮助用户管理自己的Web service以及基于Web的应用，用户可以为GUI及其后台的代码建模，我们使得用户可以使用UML为这些建模并实现可视化。”
在.NET的程序语言中引入了一些对软件行业而言崭新的概念如代理（delegate）、事件（events）、特性（properties）或者索引（indexers）等，这些概念至少还从未在编程语言中出现过。
通过辅助的建模技术，IBM Rational Rose XDE Developer允许对这些概念还不熟悉的开发人员可视化地使用他们。对理解这些编程概念并且熟练的开发人员来说，还提供了无需掌握复杂的UML细节的的可视化建模支持。
值得一提的是最近正由OMG评审的可重用资产规约。该规约通过一个标准的描述方式提供了创建资产的能力。例如，资产可以是代码，代码以及关于代码的信息，描述代码的作用或者要求、测试的结果、版本历史或者支持可重用资产的关于代码的各种元信息。
IBM Rational的Oberg认为，对软件开发人员而言，这也许会带来巨大的好处。因为有关资产重用的符号已经不是一个新东西了，但却从来没有真正实现过。IBM Rational已经在XDE中加入了有关支持，可以使用这种描述语言搜索并得到需要的组件了。
Java/.NET之谜
随着.NET环境下提供的各种工具和标准越来越多，.NET环境下的建模和开发已经得到了飞速的发展，但.NET和Java之争仍然是一个问题。微软正在将java转换为.NET，但是对很多团队而言，Java还是第一站。当被问及IBM Rational将站在哪一边时，Oberg毫不犹豫地选择了Java。
“Java给用户们带来了太多，这正是为什么Java如今这么流行而且还将更加流行的原因，”Oberg说，“我们的顾客已经成功地使用Java开发了非常复杂和规模庞大的应用。而且具有可扩展性、鲁棒性，并且，Java是一个不被任何一家特定公司所把持的开放的环境。”
“更明确地说，如果有顾客在.NET和Java中间犹疑的话，IBM将会推荐Java，因为我们认为这将给顾客带来最大的利益，但是，如果顾客由于其它原因选择了.NET,我们也将继续帮助他们开发大型的.NET应用。”
在这些建模工具和标准中，适应性已经被证明是一个关键的因素。UML支持很多平台、语言和开发环境。MDA更是允许用户保持模型和代码的同步。另外，MDA还将UML扩展到代码生成和程序生命周期的其它领域；借助其平台无关性，MDA还支持到其它平台的接口。
LogicLibrary的Cralson认为他的团队已经可以很好地构建应用的架构，并且成功地从J2EE环境的应用转换到.NET上。“两个环境下的产品可以共用大部分的源码，因为微软为J#提供了强大的支持，可以直接以J#格式读入Java代码”
“大部分情况下，我们的大部分Java源码都可以以J#格式成功编译并且部署在.NET框架中，这对我的团队而言是个好事，对微软而言也同样如此，因为他们为传统的Java开发者提供了无缝的环境。” 中间的环节呢？
微软还将在建模领域投入更多的注意力，只要他还想维持和Java工具开发商的竞争局面。类似于Visual Studio的各种Java阵营的好用的IDE似乎在建模领域已经占据了优势地位，也就是说，微软现在扮演的是追赶者的角色，建模领域将成为一块即将火热的战场。
“Java社团接受各种建模概念的速度要快得多，工具也要流行的多”，Embarcadero公司的Keller认为，“微软现在拖着包袱在前进，他们的工具－Visual Studio－并没有提供太多清晰的可视化特性。”
“举例说吧，Compuware和其它公司正在竭力将VB开发者吸引到Java阵营中，微软在努力挽留VB的用户，而Java阵营正在争取他们。”
Keller指出，最近建模方面主要关注的是应用开发，有时候明显把数据建模排除在外了。
“大部分的努力都是为了简化应用开发。但并不停留在应用上，也不仅限于中间件上”，他说，“问题在于：如何简化从类到数据库组件的过程，以及中间的环节？”
更广泛使用的.NET
Visual Basic .NET的开发人员可能也想开发移动设备上的应用。总部位于Atlanta的AppForge公司的产品主管Bob Holt说，“打个比方，如果你想为一个Palm手持操作系统、Pocket PC、Symbian或者某些欧洲的智能手机写应用的话，你在Visual Basic上的经验可以继续有效，你可以在Visual Basic Studio .NET写程序，并进行测试，在写好之后，AppForge的MobileVB.NET软件开发平台可以将这些代码编译为这些手持设备上的应用。”
MobileVB.NET使用了for Visual Studio的一个插件。AppForge 的操作将可以从Visual Studio中多出来的一个菜单中得到。用户可以通过和创建桌面应用同样的方式使用各种Form。
按照Holt的说法，为Visual Studio .NET环境开发这些基于UML的插件已经很好地解决了建模的方方面面。在设计好之后，就可以使用Mobile VB.NET。
企业环境中典型的移动应用是具有组合框、连接指示以及数据库逻辑的目录操作。通过无线设备远程操作的用户可以在中央数据库上进行目录分析等工作。
AppForge跨越了包括航空、运输、旅社、医药和财政的多个市场领域。易做图使用AppForge开发的产品，通过手持设备、顾客序列号和连接来统计关于易做图售货机上卖出了什么，什么还没有被卖出。
