敏捷时代的建模：敏捷团队的扩张除了代码还需要什么?(2)

　　图3,“应保留的”与“临时的”敏捷模型

　　应保留的模型

　　在不同的情况下(人员数量、系统的重要度、需求的稳定程度、是否企业级系统或者嵌入式系统)，应保留的模型种类也不同。基于我的经验来看，以下几种模型可以成为应保留的模型：

　　架构的类图/包图

　　领域模型的类图/实体关系图

　　关键用例的用例图 + 时序图/协作图

　　虽然我们主要使用的是UML方式，但你也不必刻意遵守严格的UML规格。之所以选择它是因为它提供了种类丰富的标准图形，并且关于它的各种教材也已经很多了。另外，用于表现数据与流程的实体关系图(ERD)与数据流图(DFD)也会由于相同的原因而在某些地方使用到。

　　图4以图形方式显示了这三种应保留的模型的角色。简单地说，“架构”表现了系统结构，“领域模型”表现了问题领域中的关键概念，而“关键用例”则为系统的使用方式提供了示例。

　　图4，架构、领域模型以及关键用例

　　接下来我会以我的某个团队中所使用的真实示例与图片，分别解释这三个模型。

　　1. 架构的类图/包图

　　架构是对整个系统的一种结构化展示，它经常以类图或者包图的典型方式显现全局的层次(tier或layer)。举例来说，一个包含用户界面与数据库的应用程序，经常按照从用户界面到数据库进行水平分层，用例将跨越这些层以实现它的功能。

　　像“MVC”(模型-视图-控制器)这样的架构模式也可以作为一个全局架构。图5是某个架构的包图的示例，很显然它是基于某种MVC架构设计的。

　　团队中的每个人都应该理解架构中的各个部件的角色与作用，这样才能保证团队成员所编写的代码处于架构中的正确位置。

　　在这张图的多个包之间显式地表现了“依赖项”的存在，这样做是为了避免不必要的耦合或循环依赖。因为从架构的视角来说，内部包的循环依赖是最糟糕的问题，它会提高测试的难度，并且增加编译的时间。

　　(单击图片以放大)

　　图5，架构的类图/包图(示例)

　　2. 领域模型的类图或实体关系图

　　领域模型描述了应用程序所在的领域中的概念分类。在人员交流的层面上，领域模型的词汇集将成为“Ubiquitous Language”，并且在全体项目相关人员之间使用，包括用户、领域专家、业务分析师、测试与开发者。

　　而在编码的层面上，领域模型对于为各种编程结构选择合适的命名也是非常重要的，包括类、数据、方法以及其它各种协定。概念分类(经常称为“实体”)中的很大一部分会被映射到数据库中的某个持久化数据结构，并且它们的生命周期往往会长于应用程序本身。通常来说，如果你的应用程序选择了某种“MVC”架构，那么你的领域模型(或者说实体)会驻留于你的逻辑架构中的“M”(模型)包内。而在Ruby on Rails类型的应用程序中，实体关系图将会更加适用于表达某个领域模型，因为模型与关系型数据库的关系更加直接与紧密了。

　　还要注意的一点是，领域模型是随着时间进化的。由于领域处于问题理解与通信的核心地带，因此怎样维护在团队中(或更大一些的范围，如整个社区)不断发展的领域模是一个很大的主题，这一点在Eric Evans的领域驱动设计(DDD)一书中进行了详细的讨论。

　　图6是某个以类图方式表现的领域模型示例，它用一张图表现了整个领域。

　　(单击图片以放大)

　　图6，领域模型的类图(示例)

　　3. 关键用例的用例图与时序图/协作图

　　关键用例经常从用户角度表现系统的使用方式，有两个原因让我们决定将它作为保留模型的一部分。首先，开发者经常会钻进解决方案细节中，而遗忘了系统的用户是谁，以及他们想在系统中完成什么任务。用例能够帮助他们回到用户的视角，同时它也是与用户对话的一种良好的方式(其它文档更适合给技术人员看)。

　　其次，用时序图或协作图方式表现关键用例以及它们的运作过程对于开发者来说是一个很好的示范。它们描述了系统架构中不同层次的对象如何协同工作，以完成用户的目标。它表现了一个从用户界面到数据库的纵切面的实际示例，并且告诉你如何在整个架构中实现某个用例。

　　关键用例不必完整到覆盖所有的情况，只需挑选那些典型的用例，并使它们保持简单。

　　(单击图片以放大)

　　图7，关键用例的用例图(示例)

　　(单击图片以放大)

　　图8，关键用例机制???的协作图(示例)

　　图7是用例图的一个示例，它使得系统的用户与经典场景更加清晰化。它不需要非常完整，但应该表现出系统的上下文情况。标为黄色的用例(“创建类图”)被选为某个用例示例，具体的设计分解体现在图8的协作图中。通过这一示例，团队能够将他们对架构图与领域模型图(表现在图5与图6中)如何完成关键用例中所描述的特性的理解进行分享。请再次看看图4中架构、领域模型与关键用例这三者的关联吧。

　　你可以在画这些图时使用工具，以简化维护工作，然后将它们打印到一张大纸上并粘贴到墙上。这面墙就会成为建模研讨会的讨论场所了(我在下一节中会很快讨论到这部分)。

原文转自：http://www.kuqin.com/shuoit/20131123/336470.html